AI 1
AI Vibe Spec 對話指南小白如何把想法說給 AI 聽
BEFORE MASTER SPEC

不用先會寫規格，先學會跟 AI 把事情講清楚

小白不需要一次寫出完整 SPEC。先在 ChatGPT Chat 把真實想法告訴 AI，再透過補充、糾正、比較與確認，逐步形成一份自己看得懂、Work 與 Code 都能執行的共識。

從一句想法到共識 SPEC

每一次修正，都是在幫系統框架變得更準確。

與 AI 討論 SPEC 的循環使用者先說真實需求，AI 重述理解，使用者糾正或補充，AI 整理已確認與待確認內容，最後形成共識 HTML。說出真實想法不用先整理得很漂亮AI 重述理解確認是不是同一件事糾正與補充加入例外與真正目的整理共識已確認／待討論／後續共識 HTML人確認後才交 AI 2還不準確就回到對話，不急著寫程式

容易改歪的做法

  • 只說「幫我做一個名片 CRM」
  • AI 一提出介面就立刻開始 Coding
  • 想到一個功能就直接插入程式
  • 沒有確認資料、例外與完成標準
  • 讓同一個 AI 自己猜需求、開發又驗收

比較穩健的做法

  • 先在 Chat 說目的、使用者與真實情境
  • 要求 AI 重述理解，主動糾正誤解
  • 討論例外、規則與未來完整藍圖
  • 用共識 HTML 讓人先看懂並確認
  • 確認後轉 Work 執行，Code 進入同一資料夾協作

七段白話對話

使用這次「名片 → KM → CRM → BI」的真實討論作為案例。

小白可以直接說的句子

不用技術名詞，只要幫 AI 知道你現在想做哪一件事。

能力重疊，工作情境不同

Chat 先形成共識；確認 SPEC 後，再依主要成果選擇 Work、Code，或讓兩者協作。

Chat、Work 與 Code 的情境分流Chat 用於對話與 SPEC 共識。人工確認後，可分流至以大型語言模型與 MCP 為重心的 Work，或以 RPA 與程式碼優化為重心的 Code；兩者能力重疊並可雙向協作。 不是三段固定流水線，而是三種工作重心 Chat白話討論 · 釐清需求 · 形成 SPEC 人工確認 SPEC Cowork／WorkLLM ＋ MCP ＋ 知識工作研究、分析、文件、報表與內容產出串接資料來源及可用的 AI 工具主要目標：把一項工作完整交付 Code／CodexRPA ＋ 程式實作 ＋ 程式碼優化操作自動化、測試、除錯與維護理解並改善既有程式與專案主要目標：讓軟體與流程穩定運作 能力重疊、雙向協作 Claude：Chat／Cowork／Code　　ChatGPT：Chat／Work／Codex

偏向 Work 的情境

  • 需要大量運用 LLM 推理與生成
  • 透過 MCP 串接多種資料與工具
  • 成果是研究、文件、教材、簡報或報表
  • 程式只是完成知識工作的其中一種工具

偏向 Codex 的情境

  • 需要 RPA 或 Computer Use 操作流程
  • 成果是程式、系統、自動化或測試結果
  • 理解、修正及優化既有程式碼
  • 研究與工具調用服務於軟體工程目標
兩者可以使用同一個專案資料夾
SPEC／參考資料／Work 產出／程式碼／測試結果
Work 可以整理需求、資料與成果；Codex 可以建立工具、自動化及程式。誰先誰後並不固定，應由當下要交付的成果決定。
課堂判斷句：主要想把「一項知識工作」完成，偏向 Work；主要想讓「一個軟體或操作流程」運作得更好，偏向 Codex。

先做同廠商內部比較

同一家公司旗下的模式共享部分模型與生態，但不代表工具、權限及執行環境完全相同。

Anthropic Chat、Cowork 與 Claude Code 比較Anthropic 的 Chat 偏向對話與共識，Cowork 偏向知識工作與 POC，Claude Code 偏向程式、自動化與 MVP。三者共享部分 Claude 生態，但 MCP、Plugin、權限與執行環境不保證完全相同。Anthropic 產品組Claude Chat ／ Cowork ／ Claude CodeChat對話、理解與發想SPEC、建議、共識以對話 Context 為中心Cowork知識工作與完整交付研究、文件、分析、POC檔案、應用程式、MCP 與工具Claude Code軟體工程與自動化程式、測試、工具、MVP專案、終端與程式執行環境共享部分 Claude 模型、Skills、Plugins 與 MCP 生態可用清單、安裝方式、讀寫權限、沙箱及操作能力仍可能不同
OpenAI Chat、Work 與 Codex 比較OpenAI 的 Chat 偏向對話與共識，Work 偏向多工具知識工作與 POC，Codex 偏向軟體工程、RPA 與 MVP。三者共享部分 ChatGPT 生態，但 Apps、Plugins、Skills、權限與執行環境不保證完全相同。OpenAI 產品組ChatGPT Chat ／ Work ／ CodexChatGPT Chat對話、理解與發想SPEC、建議、共識以對話 Context 為中心Work多工具知識工作與交付研究、文件、分析、POCLLM、MCP、Apps 與生成工具Codex軟體工程、RPA 與優化程式、測試、自動化、MVP工作區、終端與程式執行環境共享部分 ChatGPT 模型、Apps、Plugins、Skills 與 MCP 生態方案、角色、App 啟用狀態、來源權限及執行環境仍可能不同
正確的比較順序
先比較 Anthropic 內部三種模式，再比較 OpenAI 內部三種模式；最後才討論兩家公司如何切分工作情境。MCP 是共同連接標準，不代表兩個平台提供完全相同的工具組合。

SaaS 團隊需要懂的 POC 與 MVP 分流

主流程有先後順序，但 Work／Cowork 與 Code／Codex 在執行中持續雙向協作。

從 Vibe Spec、POC 到 MVP 的雙向協作Chat 形成 Vibe Spec，人工確認後由 Work 建立 POC，再由 Codex 建立 MVP。Work 與 Codex 透過共同資料夾交換需求、資料、工具、程式與測試結果，形成雙向協作。ChatVibe Spec把需求談清楚人工確認方向與邊界避免盲目消耗Work／CoworkPOCLLM＋MCP＋多工具探索通常需要較多 Token價值關卡可行、有用、值得決定是否產品化Code／CodexMVP穩健實作與測試Work → Codex：需求、資料、POC 與驗證成果Codex → Work：工具、技術限制、測試與修正結果SPEC 清楚、技術成熟時，也可直接進入 MVP共同資料夾：SPEC／參考資料／Work 產出／程式碼／測試結果交付有順序，協作是雙向；任何一方發現問題，都能回傳並更新下一輪成果

SaaS 團隊需要懂的 POC 與 MVP 分流

探索階段追求快速證明價值；產品階段追求邊界、穩定與可驗證。

從 Vibe Spec、POC 到 MVP 與功能測試Chat 形成 Vibe Spec，經人工確認後，可由 Work 使用較高資源建立 POC，通過價值與可行性確認後，再由 Codex 依明確規格建立 MVP，最後進入功能測試。ChatVibe Spec把需求談清楚人工確認方向與邊界避免盲目消耗Work／CoworkPOCLLM＋MCP＋多工具探索通常需要較多 Token價值關卡可行、有用、值得決定是否產品化Code／CodexMVP穩健實作與測試SPEC 清楚、技術成熟時，可直接進入 MVP，不必為形式強制製作 POCPOC 證明「做得到而且有價值」；MVP 證明「使用者已經可以開始用」

Work：探索型資源投入

  • 高度運用 LLM、MCP、資料來源及生成工具
  • 允許比較方案、反覆推理與快速組合
  • Token 與工具調用量通常較高
  • 適合先證明需求、技術及商業價值

Codex：工程型穩健實作

  • 依確認的 SPEC、版本與指定範圍開發
  • 可查看程式差異並重複執行測試
  • 重視錯誤處理、權限、安全與可維護性
  • 適合建立可操作、可驗收及可持續改善的 MVP
SaaS 員工的成本與風險觀念
Work 的高 Token 使用應換來更快的探索與更完整的 POC，不是沒有邊界地嘗試；Codex 的穩健來自明確 SPEC、版本管理、測試與驗收，也不代表一定比較省 Token。選擇模式時，要同時考慮成果、成本、資料權限、可追溯性及後續維護。
完整課堂路徑：Chat 完成 Vibe Spec → 人確認 → Work 建立 POC → 人確認價值 → Codex 建立 MVP → AI3 Functional Testing。這是建議路徑，不是不可跳過的固定流程。

Google 如何形成自己的三種主流模式？

Gemini 負責對話、NotebookLM 負責知識、Spark 負責行動；Antigravity 隱藏在下方提供 Agent 執行能力。

Google AI 產品與 Antigravity 執行底座Gemini 是對話與個人入口，NotebookLM 是來源與知識空間，Gemini Spark 是全天候行動代理。三者可運用下方的 Antigravity Agent Harness、Gemini 模型、MCP、Workspace、瀏覽器及程式執行能力。Google 沒有明顯拆成 Chat／Work／Code 三個產品而是以三個使用入口，共用底層模型、Agent 與 Google 生態Gemini對話與個人 AI 入口發想、理解、詢問與日常協助原生多模態 ContextNotebookLM來源、知識與研究空間整理文件、證據、研究與深入分析與 Gemini Notebooks 同步Gemini Spark全天候任務與行動 Agent背景執行、排程、Workspace 與 MCP台灣版本由 Gemini 3.6 Flash 驅動Antigravity Agent Harness多 Agent／Sub-agent · 長任務 · 工具調用 · 雲端環境 · 程式執行 · 驗證不是流程中的一格，而是藏在不同產品下方的共同執行底座Gemini 模型＋MCP＋Google Workspace＋Browser＋Code模型提供理解；Harness 負責規劃、執行、協作與驗證

台灣最新案例｜2026/7/29

  • Gemini Spark 將陸續開放台灣 Google AI Pro 與 Ultra 用戶
  • 支援繁體中文及英文
  • 由 Gemini 3.6 Flash 驅動，可在雲端背景持續工作
  • 整合 Gmail、文件、試算表等 Workspace 服務
  • 付款、寄信等重要操作會先要求使用者同意

閱讀自由財經報導

為什麼像「三合一」？

  • Gemini 提供 Chat 與原生多模態理解
  • NotebookLM 提供知識、來源與研究工作空間
  • Spark 提供類似 Work 的背景 Agent 與跨工具行動
  • Antigravity 同時具備 Agent 管理、工具及 Coding 執行能力
  • Google 將能力整合在生態內，不強制使用者先選工作模式
Antigravity 官方資料
初代 Antigravity：Agent-first 開發平台
Antigravity 2.0：多 Agent、Sub-agent 與 Managed Agents

原生多模態是模型基因

  • Gemini 從預訓練階段納入文字、圖片、聲音、影片與程式碼
  • 不同媒介可以交錯進入同一個 Context
  • 有利於知識、行動與開發場景共用同一套理解能力

多 Agent 是產品架構

  • Antigravity 從一開始就強調 Agent 自主規劃及驗證
  • 可由多個 Agent 或 Sub-agent 平行分工
  • Gemini 與 Antigravity 深度最佳化，但兩者不是同一層概念
Google 路線一句話：Gemini 負責理解，NotebookLM 累積知識，Spark 負責行動；Antigravity 則在底層讓多個 Agent 真正把事情做完。

Gemini 為什麼看起來更像原生混合模式？

除了產品介面不同，還要回到模型一開始如何被設計與訓練。

Gemini 原生多模態模型概念Gemini 從預訓練階段就納入文字、圖片、聲音、影片與程式碼，使不同類型資訊可以進入共同脈絡，再延伸至 Gemini App、Google AI Studio、Workspace 與 Antigravity。Gemini 的模型基因：從一開始就以多模態為核心文字圖片聲音影片程式碼Gemini原生多模態預訓練不同媒介進入共同 Context理解交錯的文字、影像與聲音跨模態推理與工具運用同一核心向不同產品延伸Gemini App生活助理與多模態對話Google AI Studio模型實驗、API 與快速原型Google Workspace文件、郵件、資料與工作流程Google AntigravityAgent、工具、瀏覽器與程式開發

Gemini 的核心差異

  • 不是先建立純文字 LLM，再把各種媒介當成外掛功能
  • 從預訓練階段納入不同模態的資訊
  • 文字、圖片、聲音、影片與程式碼可交錯進入 Context
  • 同一套模型能力自然延伸到助理、辦公、開發與 Agent

教材需要保留的精準度

  • 其他主流 AI 現在也具有強大的多模態能力
  • 差異不宜簡化成「只有 Gemini 能看圖或聽聲音」
  • Gemini 的特色是從品牌與模型架構起點就主打原生多模態
  • 工作模式是產品分類；多模態則是模型設計分類
一張圖分清楚兩個比較維度
Chat／Work／Code＝依工作情境分類
原生多模態＝依模型如何理解資訊分類
因此 Antigravity 的混合感，不只來自介面，也延續了 Gemini 將不同資訊放進同一個 AI Context 的設計思路。

從聊天共識到實際完成

同一份 SPEC，交給不同介面做它最擅長的工作。

Claude 與 ChatGPT 三種工作狀態對照兩個平台都可分成對話、工作執行與程式開發三種狀態。Claude 對應 Chat、Cowork、Code；ChatGPT 對應 Chat、Work、Codex。同一個 AI 協作流程，為什麼分成三種狀態？1 · THINK TOGETHER2 · DO THE WORK3 · BUILD WITH CODE一起想清楚持續完成作業進入專案實作ClaudeChatGPTChat討論、理解、形成共識Cowork依目標執行多步驟工作Code讀取專案並開發程式Chat討論、理解、形成共識Work依 SPEC 使用工具完成工作Codex在共同資料夾協助開發不是能力高低，而是把「對話、執行、開發」放進適合的工作環境
01 · DISCUSS

ChatGPT Chat

用白話提出構想，請 AI 重述、比較選項、找出矛盾，反覆討論到雙方對完整系統有共識。

02 · CONFIRM

SPEC 共識版

把討論結果寫成 Markdown 或互動式 HTML。人先確認目標、範圍、規則、階段與驗收方式，再交付執行。

03 · EXECUTE

Work

依 SPEC 持續完成任務，使用較多 Token 進行研究、整理、產生素材，並調用當下可用的 AI 工具。工作過程仍受 SPEC 與人工確認點約束。

04 · BUILD

Codex

與 Work 使用同一個專案資料夾，讀取相同 SPEC 與產出，協助建立程式、修正問題、執行檢查及準備測試版本。

共用資料夾就是交接中心
專案資料夾／SPEC／素材／程式碼／測試結果
Chat 先形成共識；Work 依共識推進；Codex 不必重新猜需求，直接讀取同一資料夾內的 SPEC 與最新成果。

Work 適合負責

  • 長時間、分步驟的完整作業
  • 研究、整理及大量內容產出
  • 依需求調用可用工具與模型
  • 持續更新專案檔案與進度

Codex 適合負責

  • 讀取 SPEC 並建立可執行版本
  • 處理 HTML、GAS、API 與資料結構
  • 修正錯誤並執行程式檢查
  • 與 Work 共用檔案，避免重複交代
課堂重點：Token 用得多不是目的。真正的價值是先用 Chat 把方向談準，再讓 Work 把資源花在已確認的任務上，最後由 Codex 精準協助實作。

什麼時候可以請 AI 產生共識 SPEC？

不是每個細節都要完成，但整體框架不能互相矛盾。