AI Coding 還需要寫 PRD 嗎？需求越模糊，Agent 替你決定的越多（2026 完整指南）

只丟一句「幫我新增登入功能」給 Agent，交回來的東西卻和你想的不一樣？這篇帶你看懂 Plan 這一段要寫到多清楚，什麼時候又可以不寫！

把「幫我新增登入功能」交給 Coding Agent，它多半能開始工作，幾分鐘後交出一個能登入的畫面。我想把這句話當成一張待批改的任務卡：如果只交出這 8 個字，Agent 還得替團隊決定多少事？

它可能選擇帳密登入，也可能沿用現有的第三方登入；可能讓所有角色看到同一頁，也可能自行補上一套權限；錯誤訊息可能寫「查無此帳號」，也可能寫「帳號或密碼錯誤」。每種做法在局部都說得通，卻未必符合這個產品。

它也很少停下來問你。一篇收錄在 ICLR 2026 的研究，把真實 GitHub issue 的關鍵資訊拿掉，再交給模型處理，結果是模型很難分辨一份指令講清楚了沒有；讓它能回頭問人、補到缺的資訊之後，成績最多提高 74%。Anthropic 寫給 Claude Code 使用者的文件說得更白：Claude 能推測你的意圖，但讀不了你的心。

ICLR 2026 論文原圖：六個模型在三種條件下解決真實 GitHub issue 的比例。藍色 Hidden 是拿掉關鍵資訊，每個模型都最低；橘色 Interaction 是可以回頭問人，例如 Claude Sonnet 4 從 40.00% 升到 61.40%；綠色 Full 是資訊一開始就給齊，每個模型都最高 — 同一批 issue，拿掉關鍵資訊後每個模型的解決率都下滑；能回頭問人就追回一大截，但仍比不上一開始就寫清楚。（圖片來源：Vijayvargiya 等人〈Interactive Agents to Overcome Ambiguity in Software Engineering〉，經 Sunny DataScience 中文重點標註）

所以我的判斷很明確：沒寫下的決定，Agent 就會替你做。它不會留白，也很少舉手，它會挑一個最像答案的選項，然後繼續寫下去。PRD（產品需求文件）在 AI coding 裡的用處，就是把這些決定收回來。

快速回答 把一句任務交給 Coding Agent，沒寫下的決定，Agent 就會替你做：它很少停下來問，會挑一個最像答案的選項繼續寫。所以寫給 Agent 的 PRD（產品需求文件）不必厚，但驗收條件要寫在任務卡上。哪些要寫，看 Agent 猜錯時，你看程式改動（diff）一眼看不看得出來：權限、錯誤訊息、資料怎麼存看不出來，一定要寫；Anthropic 建議，一句話就能描述完的小改動，直接跳過計畫。

只給一句「新增登入功能」，Agent 會自行替你做下 5 個未言明的邊界決定

假設既有產品已有帳號系統，這次只做「已註冊使用者以電子郵件與密碼登入」。下面這張圖左邊是那 8 個字，中間是 Agent 沒人告訴它、只好自己選的五個地方，右邊是任務卡上要寫下的決定。

對照圖：左邊是交出去的一句話「幫我新增登入功能」；中間虛線框是 Agent 沒人告訴它、只好自己選的五個地方，例如帳密還是第三方登入、錯誤訊息寫「查無此帳號」還是「密碼錯誤」、畫面跳轉了算不算完成；右邊是任務卡對應寫下的五個決定：誰能進來、成功後去哪裡、錯誤怎麼呈現、權限何時生效、什麼叫完成，其中「什麼叫完成」以藍色標出 — 只給一句模糊指令，未說明的五個邊界決定都會被 Agent 自行填補；任務卡必須清楚寫下驗收條件，才能避免實作偏離預期（Sunny DataScience 整理）。

我會在任務卡上逐行補：

誰能進來。僅既有、啟用中的一般使用者可登入；停用帳號不可登入。這一行防止 Agent 把註冊、管理員登入或重設密碼一起做掉。
成功後去哪裡。驗證成功後建立有效 session，回到原本要求登入的頁面；若沒有原頁面，回到首頁。這一行讓前端與後端有共同的完成狀態。
錯誤怎麼呈現。帳號不存在、密碼錯誤、帳號已停用，一律給相同的泛用提示；逾時則顯示可重試訊息，保留已輸入的電子郵件。OWASP 的認證檢查表把這條寫成「必須」：登入失敗時，不論是帳號錯、密碼錯，還是帳號被停用，都要回同一句話，否則等於告訴攻擊者哪些帳號存在。逾時那半句則避免網路問題被誤報成密碼問題。
權限何時生效。只有伺服器確認 session 有效後，受保護頁面才可載入；登出或 session 失效後再次開啟，必須回到登入頁。這一行擋住「畫面看起來登入了」卻能繞過權限的實作。OWASP 的 Session 管理檢查表也要求，登出與逾時時，至少要在伺服器端讓 session 失效。
什麼叫完成。正確帳密能到指定頁；錯誤帳密不建立 session；停用帳號被拒；過期 session 無法讀取受保護資料。這些可由測試和人工操作共同檢查。

規格不必替 Agent 決定表單狀態怎麼寫、函式叫什麼名字，但產品邊界與可觀察的結果必須由團隊決定，尤其是錯誤訊息、資料存取與角色權限。PRD 範本裡常見的 Problem、Persona、Scope 等欄位，如果沒有落到這五行這種程度的具體判斷，就只是讓文件看起來完整而已。

規格演進 50 年：當 Agent 缺乏當面發問的能力，驗收條件就必須直接寫進任務卡

需求文件寫多厚，這幾十年一直在擺盪，擺盪的理由其實只有一個：讀文件的人，能不能回頭問寫文件的人。

1970 年，Winston Royce 寫了那篇後來被當成瀑布式開發源頭的論文。他問「文件要寫多少？」，自己的答案是「相當多」，多到大部分工程師放著不管就不會願意寫的程度。我的理解是，在那種開發方式裡，寫需求的人和寫程式的人往往分屬不同團隊，中間隔著幾個月，讀的人很難回頭問，所以每一個決定都得先寫進文件。

2001 年，敏捷宣言把「可以運作的軟體」放在「詳盡的文件」之前。同一年，Ron Jeffries 把 user story 拆成三個 C：Card、Conversation、Confirmation。卡片只是「代表這個需求的記號」，需求本身靠客戶和工程師當面對話傳遞；最後由客戶定義驗收測試，證明這張卡做對了。卡片可以很短，因為有人坐在旁邊，隨時可以問。

現在讀規格的換成了 Agent。它讀得很快，但前面那篇研究說了，它連自己缺了哪些資訊都很難察覺，更別說回頭問。

年代規格寫給誰沒寫的部分誰補文件的重心

1970 年代起：瀑布式

規格寫給誰: 幾個月後才讀的下游團隊
沒寫的部分誰補: 沒人補，只好寫得很完整
文件的重心: 完整

2001 年起：user story

規格寫給誰: 坐在旁邊的工程師
沒寫的部分誰補: 當面問（Conversation）
文件的重心: 一張卡加驗收測試

2025 年起：AI spec

規格寫給誰: Coding Agent
沒寫的部分誰補: Agent 自己猜
文件的重心: 邊界與驗收條件

這張表是我讀 AI coding 規格的方式。User story 的三個 C 裡，Conversation 那一段在 Agent 身上最弱，所以卡片得自己帶著 Confirmation 走：寫給 Agent 的規格不必回到瀑布式的厚度，但驗收條件要寫在卡片上，不能留在對話裡。

規格工具要求先寫再做：格式能保證規格可測試，但決策對錯依然得由人把關

工具廠商顯然也看到了同一件事，過去一年多，幾家都把「先寫、再做」放進了產品。

Claude Code 的 plan mode（2025 年 6 月）：Agent 先讀程式、提出計畫，你同意了才動手改檔案。
AWS 的 Kiro（2025 年 7 月預覽）：每個功能產生三份文件，需求寫在 requirements.md，驗收條件用一種叫 EARS 的句型，格式是「WHEN 某個情況，THE SYSTEM SHALL 做某件事」，官方文件說這樣寫「不含糊、可測試」，容易轉成測試案例。
GitHub 的 Spec Kit（2025 年 9 月開源）：把開發切成規格、計畫、任務、實作四段，目前這一段沒驗證過，就不往下走。
OpenAI Codex 的 plan mode（2026 年 2 月起預設開啟）。

工具還在往前走。iThome 在 2026 年 5 月報導，Kiro 新增需求分析，會在動手前找出需求裡的歧義與衝突。報導舉的例子很好：需求寫著「移除紀錄」，可能是永久刪除，也可能是保留資料、只標記為刪除，Kiro 會把這類歧義整理成選項，讓開發者確認。日本 @IT 在 2025 年 10 月把「規格驅動開發」收進 AI 用語辭典時，也把它定位成 vibe coding 的對照組：先講清楚要做什麼，規格成為唯一的依據。

這些工具有一個共同點：它們能逼你寫、能幫你找出沒寫清楚的地方，但決定還是你的。Kiro 自己文件裡的需求範例就是一個例子：「WHEN 使用者用一個已經存在的 email 註冊，THE SYSTEM SHALL 顯示『Email already registered』」。這句話完全符合 EARS 格式，可測試、不含糊，但它告訴任何人某個 email 有沒有註冊過；OWASP 對註冊流程的建議，是同樣可以改用不透露帳號存在與否的泛用訊息。格式保證規格可以測，不保證規格是對的。

把需求拆成可觀察行為：同時寫出正例與反例，人和測試才能判斷是否真正完成

回到登入。最容易漏掉的是驗收條件。像「使用者能順利登入」仍不足以測試：使用者是哪種角色？輸入正確後應發生什麼？錯誤時哪些資料不能出現？

我會挑其中幾條，寫成正反兩面。用 EARS 的句型寫，是這個樣子：

WHEN 已啟用的一般使用者輸入正確的電子郵件與密碼
THE SYSTEM SHALL 建立 session 並導向原本要求登入的頁面；重新整理後仍保持登入，直到登出或 session 到期

WHEN 已停用的帳號輸入正確的密碼
THE SYSTEM SHALL 不建立 session，並顯示和密碼錯誤相同的提示

WHEN 使用者以已過期的 session 開啟受保護頁面
THE SYSTEM SHALL 回傳未授權，並導向登入頁

第一條是正例，後兩條是反例。有了反例，測試能檢查 session、導向與資料存取，畫面跳轉只是最表面的訊號。句型不一定要用 EARS，重點是每一條都說清楚「什麼情況下，系統要做什麼」，讓人和測試都能判斷做到了沒有。

若團隊對 session 保存方式、逾時長度或登入失敗幾次要鎖帳號還沒決定，任務卡應標成待決事項，由負責人定案。不要把未知藏在「依最佳實務處理」裡；那句話等於請 Agent 替你決定。若 Agent 讀取的 repo 缺少現有認證規則，先補齊可找到的文件與測試再交任務，這部分可以接著讀〈Context Engineering 是什麼？Agent 一直犯同樣的錯怎麼辦？（2026 完整懶人包）〉。

還有一個實作上的界線：任務卡可以允許 Agent 自行決定表單狀態怎麼寫，但要明列不得改動密碼儲存方式、既有權限檢查與其他登入入口。審查時就能把 diff 對回這條界線。如果它為了讓測試通過而刪掉原本的權限檢查，測試再綠也不能算完成。

Plan 階段實務四步驟：讓 Agent 訪談補齊細節，審查假設清單再轉成測試

Plan 在整個流程裡的位置，我在〈Plan、Build、Verify、Ship 是什麼？AI 寫程式變快後，進度要怎麼算？（2026 完整懶人包）〉講過。這裡只講 Plan 這一段的內容要寫到什麼程度。我的做法有四步。

一、先讓 Agent 問你。Anthropic 建議，較大的功能先請 Claude 用提問工具訪談你，問技術實作、介面、邊界情況和取捨，問完寫成一份規格檔，再開一個新的 session 照著做。這等於把 user story 少掉的 Conversation 補回來，只是發問的換成 Agent。

二、規格要能獨立讀懂。同一份文件說，最有用的規格會寫出牽涉到哪些檔案和介面、哪些不在這次範圍內，最後附上一個從頭到尾證明功能可用的驗證步驟。對照前面的任務卡：五行決定、不得改動的界線、正反兩面的驗收條件，剛好就是這三樣。

三、把 Agent 的計畫當成它的假設清單來讀。Plan mode 交出來的計畫，是 Agent 寫的。裡面每一個你沒寫過的決定，都是它替你選的。逐條讀，同意的留下，不同意的改掉（Claude Code 在 plan mode 下按 Ctrl+G 可以直接在編輯器裡改計畫）。這一步最容易被跳過，因為計畫看起來很專業。

四、穩定的條件變成測試，未定的留在文件。驗收條件一旦確定，就請 Agent 先寫成測試；還在權衡的事，留在文件裡並註明誰來決定。文件與測試各管一半，日後需求變了，才知道該改哪裡。

5 分鐘自我檢測：請 Agent 列出「自己假設」的清單，清查任務卡漏掉的決定

這個檢查不需要額外的工具，任何能切到 plan mode 或能下「先不要改檔案」指令的 Coding Agent 都能做。拿一個你下一個要交出去的任務，先只給它一句話：

先不要改任何檔案。針對下面這個任務，列出你為了完成它必須做的每一個決定。
每一條標出來源：任務卡上寫的、從哪個檔案讀到的，或是你自己假設的。
任務：幫我新增登入功能

數一數標成「自己假設的」有幾條。逐條問自己三個問題：我同意嗎？我看 diff 時看得出它選了什麼嗎？選錯了要多久才會發現？同意的，寫進任務卡；不同意的，改；不知道的，標成待決，找能決定的人。

接著把補好的任務卡貼給它，再跑一次同一段指令。「自己假設的」應該變少，剩下的那些，就是你刻意留給 Agent 決定的事。這張清單本身就是很好的審查依據：上線後出了問題，先回頭看是不是在這張清單上。

何時可以跳過規格：一句話能說完的小改動，以及看 diff 一眼就能抓錯的實作

小改動不值得一張任務卡。Anthropic 的建議裡有一句很實用的判準：如果這次的改動一句話就能描述完，跳過計畫。改錯字、加一行 log、改變數名稱，直接做。

過度規格化也有代價。Thoughtworks 的 Birgitta Böckeler 在 2025 年 10 月試用 Kiro 和 Spec Kit 後寫道，用 Kiro 修一個小 bug，「像拿大鎚敲核桃」；Spec Kit 產出的 Markdown 冗長，審起來很累，她寧可審程式碼。iThome 的報導也提到，功能範圍已經明確、或幾項工作彼此獨立時，先寫規格可能拖慢流程。

我的判準是：如果 Agent 猜錯了，你看 diff 時一眼看得出來嗎？看得出來的，按鈕文字、版面、內部函式怎麼拆，讓它猜，猜錯了改回來的成本很低。看不出來的，要寫：權限、錯誤訊息、資料怎麼存、刪除是真刪還是標記刪除。這類決定藏在畫面背後，測試沒寫到就不會有人發現，直到出事。前面 Kiro 那個「移除紀錄」的例子就是典型，兩種實作在畫面上長得一模一樣。

破除三個常見誤解：規格不是越長越準，工具生成的計畫不等於人確認過

「規格寫越長，Agent 越準」。剛好相反。Anthropic 談專案規則檔時提醒，檔案太長，Claude 會忽略一半，重要的規則淹沒在雜訊裡；Böckeler 也觀察到，Agent 常常沒有照著規格裡的每一條做。規格要短到每一行都有用，判斷方法很簡單：刪掉這一行，Agent 會不會做錯？不會，就刪。

「開了 plan mode、用了 Spec Kit，就有規格了」。工具產生的計畫和規格，是 Agent 寫的。GitHub 介紹 Spec Kit 時寫得很清楚：AI 產出這些文件，你負責確認它們是對的。沒有讀過、改過的計畫，只是把 Agent 的假設換了一個比較正式的格式。

「規格要替 Agent 決定程式怎麼寫」。規格要決定的是做什麼、不能碰什麼、怎樣算做完。要動哪些檔案和介面可以寫，那是邊界；表單狀態怎麼管、函式怎麼命名，交給 Agent。寫得太細，你會花更多時間維護規格，Agent 也少了照既有程式慣例去寫的空間。

結論：規格寫到能判斷範圍與驗收就可以停，任務卡上的空白都會由 Agent 代勞

PRD 寫到能讓人判斷範圍與驗收，就可以停。重複描述按鈕顏色、列出一長串不影響交付的形容詞，容易擠掉真正的限制。

拿你手邊一段 PRD 試一次：刪掉一段不會影響任何測試或決策的文字，再補上一條目前缺席的錯誤路徑。若補不出來，先問清楚誰能決定它。

需求越模糊，Agent 替你決定的越多。任務卡上每一個空格，都是你交給 Agent 的決定。

驗收條件寫好之後，下一步是讓檢查的那一方和寫程式的那一方分開，可以接著讀〈AI 寫的測試全過，為什麼功能還是錯的？驗證閉環完整懶人包（2026）〉。

常見問題

什麼是規格驅動開發（Spec-Driven Development）？

先講清楚要做什麼，再讓 AI 寫程式，規格是唯一的依據；日本 @IT 在 2025 年 10 月把它定位成 vibe coding（先讓 AI 寫、邊做邊決定）的對照組。代表工具有 AWS 的 Kiro（需求和驗收條件寫成文件）與 GitHub 的 Spec Kit（分成規格、計畫、任務、實作四段，這一段沒驗證過就不往下走）。

Claude Code 的 plan mode 是什麼？

Agent 先讀程式、提出計畫，你同意了才動手改檔案，2025 年 6 月推出；OpenAI Codex 的 plan mode 從 2026 年 2 月起預設開啟。計畫是 Agent 寫的，裡面每一個你沒寫過的決定，都是它替你選的。逐條讀，不同意的改掉，Claude Code 按 Ctrl+G 可以直接在編輯器裡改。

驗收條件怎麼寫，Agent 和測試才判斷得了？

每一條寫清楚「什麼情況下，系統要做什麼」，正例和反例都寫。Kiro 用的 EARS 句型是一種寫法，例如「WHEN 已停用的帳號輸入正確的密碼，THE SYSTEM SHALL 不建立 session」。有了反例，測試才檢查得到登入狀態（session）、導向和資料存取。格式保證規格可以測，不保證規格是對的。

給 Agent 的規格寫得越長越好嗎？

剛好相反。Anthropic 談專案規則檔時提醒，檔案太長，Claude 會忽略一半；Thoughtworks 的 Birgitta Böckeler 也觀察到，Agent 常常沒有照著規格的每一條做。每一行都問：刪掉它，Agent 會不會做錯？不會就刪。表單狀態怎麼管、函式怎麼命名，交給 Agent。

參考資料

規格的來歷

Winston W. Royce, Managing the Development of Large Software Systems（Proceedings of IEEE WESCON, 1970-08） https://faculty.washington.edu/hazeline/misc/reserve/royce_waterfall.pdf
Kent Beck et al., Manifesto for Agile Software Development（2001） https://agilemanifesto.org/
Ron Jeffries, Essential XP: Card, Conversation, Confirmation（2001-08-30） https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/

Agent 與模糊需求

Vijayvargiya, S., Zhou, X., Yerukola, A., Sap, M., & Neubig, G., Interactive Agents to Overcome Ambiguity in Software Engineering（arXiv 2502.13069，ICLR 2026） https://arxiv.org/abs/2502.13069
Anthropic, Best practices for Claude Code（2026-10-16 檢視） https://code.claude.com/docs/en/best-practices

Spec-driven 工具

GitHub, Spec-driven development with AI: Get started with a new open source toolkit（Den Delimarsky，2025-09-02） https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/
Kiro, Requirements-First Workflow（Kiro 文件，2026-10-16 檢視） https://kiro.dev/docs/specs/feature-specs/requirements-first/
OpenAI, Codex CLI release rust-v0.94.0（2026-02-02，plan mode 預設開啟） https://github.com/openai/codex/releases
iThome,〈AWS Kiro加入需求分析，AI實作前先找出需求歧義與衝突〉（李建興，2026-05-14） https://www.ithome.com.tw/news/175820
@IT（ITmedia）,〈仕様駆動開発（Spec-driven development）とは？〉（AI・機械学習の用語辞典，2025-10-07，日文） https://atmarkit.itmedia.co.jp/ait/spv/2510/07/news022.html
Birgitta Böckeler, Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl（martinfowler.com，2025-10-15） https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html

登入與 Session 安全

OWASP Cheat Sheet Series, Authentication Cheat Sheet（"Authentication and Error Messages" 一節） https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
OWASP Cheat Sheet Series, Session Management Cheat Sheet（"Session Expiration" 一節） https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html