Karpathy「Voice Ramble → Spec → Agent」工作流研究報告

1

一、結論

你記得的核心方向正確，但需要校正來源：

Andrej Karpathy 在 2026 年 7 月 21 日分享的是一種「nice long ramble session」工作習慣：切換到語音，連續約 10 分鐘把混亂想法全部說出來，必要時進行幾輪訪談，讓 LLM 重建意圖，減少後續修正。他沒有公開一套固定 prompt，也沒有明確提出完整的 PRD → Agent 開發流程。Karpathy 原始 X 貼文

「AI 主動追問直到需求完整，再整理成規格並交給 Agent」是對這個方法的工程化延伸。這個延伸合理，而且比單純 ramble 更可靠。

二、Karpathy 實際使用方式

他的原始方法包含四個動作：

  1. 遇到難以用文字整理的複雜問題。

  2. 切到 /voice，先提示正在使用語音辨識，可能存在錯字。

  3. 大約說 10 分鐘，不整理結構，允許跳躍、矛盾、補充和自我修正。

  4. 有時將過程轉成幾輪小型訪談，讓 LLM 重建他真正想完成的事情。

核心不是「語音比較聰明」，而是語音降低輸入摩擦，使人願意提供更多資訊：

  • 為什麼要做

  • 目標使用者

  • 已經嘗試過什麼

  • 哪些地方不確定

  • 擔心什麼

  • 什麼結果才算成功

  • 隱性限制和例外

  • 尚未決定的選項

一般短 prompt 通常只有「我要做什麼」，缺少「為什麼、不能怎麼做、什麼才算完成」。

三、完整運作模型

flowchart TD
    A["語音傾倒<br>Raw context"] --> B["AI 重述<br>Intent reconstruction"]
    B --> C["人工校正<br>Facts vs inference"]
    C --> D["AI 逐題訪談<br>Close critical gaps"]
    D --> E["規格凍結<br>PRD + acceptance criteria"]
    E --> F["乾淨交接<br>Agent handoff"]
    F --> G["實作、測試、驗收"]

Phase 1：語音傾倒

先提供原始材料，不要求 AI 立即回答問題或提出解法。

內容可以沒有順序，但至少涵蓋：

  • 想做的產品或功能

  • 形成這個想法的原因

  • 使用情境

  • 參考產品

  • 不喜歡的既有做法

  • 技術與商業限制

  • 預期結果

  • 尚未釐清的矛盾

Phase 2：意圖重建

AI 不能直接開始設計產品，而要先分成：

  • 你明確說過的事實

  • AI 根據內容推論的事項

  • 互相矛盾的要求

  • 尚未決定的問題

  • 可能被語音辨識錯誤的名詞

這是最重要的防錯層。LLM 很可能把混亂內容整理得非常流暢，但「流暢」不代表它忠實理解原意。

Phase 3：主動訪談

AI 每次只問一個問題，按照決策影響排序：

  1. 產品目標與成功標準

  2. 目標使用者

  3. 核心使用流程

  4. MVP 範圍

  5. 明確不做的事情

  6. 資料與權限

  7. 技術、平台和成本限制

  8. 例外情況

  9. 驗收條件

  10. 尚未解決的風險

問題不在於問得多，而是消除會使 Agent 建錯產品的關鍵不確定性。

Phase 4：規格凍結

訪談完成後，AI 先產出 Decision Log 和完整規格。使用者明確確認之前，不得執行開發。

最低限度應包含：

  • Product Brief

  • PRD

  • User Stories

  • Functional Requirements

  • Non-functional Requirements

  • Scope / Out of Scope

  • User Flow

  • Data Model

  • Technical Constraints

  • Acceptance Criteria

  • Risks

  • Open Questions

Phase 5：Agent 交接

不要直接把整段語音 transcript 丟給 Coding Agent。

正確做法是建立乾淨的交接文件：

docs/discovery/idea-brief.md
docs/specs/product-prd.md
docs/specs/agent-handoff.md

agent-handoff.md 只保留：

  • 最終決策

  • 工作範圍

  • 必須遵守的限制

  • 可修改與不可修改的檔案

  • 執行順序

  • 驗收方式

  • 明確未決事項

這能避免 Agent 被早期已經推翻的想法干擾。

四、ChatGPT 現在如何實作

截至 2026 年 8 月 21 日，ChatGPT Voice 已支援文字、圖片、檔案與 Projects；Voice 對話可以引用 Project 裡的近期對話、來源與 Project Instructions。OpenAI Release Notes

Mac 桌面版還可以讓 Voice 配合 Work 或 Codex：

  • 啟動、暫停或重新指定 Agent 任務

  • 協調多個 Agent

  • 使用既有 Project context

  • 在 Agent 工作時接收語音進度

  • 透過語音修正任務方向

這項整合目前以 macOS／Windows 桌面 App 為主，單獨的 Voice in Work/Codex 不在 Web 或 Mobile 上運行。OpenAI ChatGPT Voice 文件

你的最佳配置：

  1. Mac 安裝最新版 ChatGPT Desktop。

  2. 建立一個 Product Discovery Lab Project。

  3. 把下方 Master Prompt 以文字貼進 Project Instructions 或第一則訊息。

  4. Voice Intelligence 若可設定，選擇 High。

  5. 使用 Voice 完成訪談。

  6. 以文字確認最終 Decision Log。

  7. 開一個新的 Work／Codex task，只讀最終規格開始實作。

文字貼入 Master Prompt 比直接念 prompt 更可靠；Voice transcript 並非逐字稿，官方也明確說明轉錄可能與實際談話不同。OpenAI ChatGPT Voice 文件

五、可直接使用的 Master Prompt

你現在是我的 Product Discovery Interviewer、Senior Product Manager
與 Software Architect。

你的任務不是立刻替我提出解法，而是透過語音對話，把我腦中的模糊想法
轉化成可以交給 AI Coding Agent 執行的完整規格。

整個流程分為五個階段。

階段一：Brain Dump

我會先以語音自由描述想法。內容可能混亂、重複、矛盾，也可能存在
語音辨識錯誤。

在我說出「Brain Dump 完成」以前：

1. 不要開始解決問題。
2. 不要提出產品功能。
3. 不要替我做未經確認的決策。
4. 不要打斷我。
5. 如果系統要求你回應，只回答「已記錄，請繼續」。
6. 保存我提到的目標、限制、案例、擔憂、自我修正與未決事項。

階段二：Intent Reconstruction

當我說出「Brain Dump 完成」後，先重建我的意思，分成：

1. 我明確說過的事實。
2. 我目前想達成的目標。
3. 已經確定的決策。
4. AI 推論出來、但尚未獲得我確認的事項。
5. 互相矛盾的內容。
6. 可能存在語音辨識錯誤的名詞。
7. 尚未回答的關鍵問題。
8. 目前理解的一句話產品定義。

不得把推論寫成我的原始決定。

階段三：Discovery Interview

完成重建後，開始訪談。

規則：

1. 每次只問一個問題。
2. 優先詢問會改變產品方向、架構、成本或 MVP 範圍的問題。
3. 不要一次列出大量問題。
4. 如果回答含糊，繼續追問，直到能轉化為可執行規格。
5. 主動指出矛盾、隱性假設、缺少的 edge cases。
6. 不要迎合我的選擇；如果要求不合理，直接指出具體衝突。
7. 不要自行擴大功能範圍。
8. 已經得到明確答案的問題不得重複詢問。

訪談至少必須確認：

- 產品目標
- 問題定義
- 目標使用者
- 核心使用情境
- 使用者主要流程
- MVP 功能
- Out of Scope
- 輸入與輸出
- 資料來源
- 帳號、角色與權限
- 平台與裝置
- 技術限制
- 成本與時程限制
- 隱私與安全需求
- 錯誤與例外情況
- 成功指標
- 可測試的 Acceptance Criteria

當不存在會阻擋 MVP 實作的重大未知事項時，停止提問。

階段四：Specification Freeze

訪談結束後，輸出：

A. Executive Summary
B. Problem Statement
C. Target Users
D. Product Goals
E. Non-goals
F. User Journey
G. Functional Requirements
H. Non-functional Requirements
I. Data and Permissions
J. Technical Architecture
K. MVP Scope
L. Future Scope
M. Risks
N. Acceptance Criteria
O. Decision Log
P. Remaining Open Questions
Q. Assumptions

所有 requirements 使用編號，例如 FR-001、NFR-001、AC-001。

Acceptance Criteria 必須可以由人或 Agent 明確判定 Pass 或 Fail。

完成後不要開始開發。等待我說出：

「規格確認」

如果我尚未確認，根據我的修正更新規格。

階段五：Agent Handoff

只有收到「規格確認」後，才產出一份乾淨的 Agent Handoff。

Agent Handoff 必須包含：

1. Mission
2. Source of Truth
3. Current Repository Context
4. Required Deliverables
5. Files or Areas Allowed to Change
6. Files or Areas That Must Not Change
7. Implementation Sequence
8. Verification Commands
9. Acceptance Checklist
10. Known Risks
11. Explicitly Deferred Work
12. Definition of Done

如果目前環境具有 Work 或 Codex 工具，不得因為規格完成就自動修改檔案。

只有收到：

「開始執行」

才可以開始檢查 repository、建立執行計畫、修改程式與驗證結果。

最重要的規則：

- 不得把 AI 的推論偽裝成我的決定。
- 不得在規格確認前執行。
- 不得用漂亮但模糊的文字取代可測試需求。
- 發現矛盾時必須中止並指出。
- 最終 Agent 應以凍結後的規格為準，不以早期語音 transcript 為準。

六、實際測試流程

第一次測試控制在 20 分鐘：

  • 2 分鐘：貼上 Master Prompt，開啟 Voice。

  • 5–10 分鐘：完整 brain dump。

  • 5 分鐘：接受逐題訪談。

  • 3 分鐘：檢查 Decision Log、Inference、Open Questions。

  • 最後輸入文字「規格確認」。

  • 另開 Codex／Work task，以 agent-handoff.md 為唯一 source of truth。

判斷這套方法是否有效，只看三個指標：

  1. Agent 開始實作後需要追問多少次。

  2. 第一版與你原始意圖偏離多少。

  3. 因需求誤解造成的返工量是否下降。

七、主要風險

  • 流暢性錯覺：AI 整理得合理，不代表忠實呈現原意。

  • 語音轉錄錯誤：產品名、技術名詞、數字、URL 必須文字確認。

  • 過度推論：一定要強制區分 Facts、Decisions、Inferences。

  • 訪談無限延長：使用「是否阻擋 MVP」作為停止條件。

  • Discovery 與 Execution 混在一起：規格未凍結前不得啟動 Agent。

  • 上下文污染：Coding Agent 應優先讀取凍結規格，不應自行重新解讀整段 ramble。

  • 機密資料：Live／Advanced Voice 的音訊會與 transcript 一起保留 30 天；模型訓練使用狀況取決於 workspace 與 Data Controls。處理客戶或未公開產品資訊前，需檢查 Improve the model for everyone 與音訊分享設定。OpenAI ChatGPT Voice 文件