DotMD如何審查 AI 撰寫的規格：代理程式開發前的檢查表。
AI 代理程式一分鐘就能寫出自信又整齊的規格。這正是危險之處：就算錯了，讀起來也很順。這份檢查表告訴你，在叫代理程式動工之前該看什麼。
需要 macOS 14 或以上版本。閱讀免費；編輯與審閱為一次付費。
快速解答
審查 AI 撰寫的規格，就像審查 pull request：先確認它解決的是對的問題，再找缺漏。依序檢查範圍與非目標、邊界情況、資料與遷移、測試與回復，並在代理程式寫任何程式碼之前，對你想修改的每個段落留言。
- [ ] Scope matches what I asked for
- [ ] Non-goals are listed
- [ ] Edge cases and errors are covered
- [ ] Data and migrations are explicit
- [ ] Tests prove each requirement
- [ ] There is a rollback·
為什麼 AI 規格需要不同的審查
人在起草規格時，往往會在不確定的地方留下空白。模型則會為所有內容寫出流暢的文字，包括它猜測的部分。因此弱規格的一般徵兆，如含糊的措辭與明顯的漏洞，都不見了，問題藏在自信的句子裡。請審查好作者本來會去問的事情。
檢查表
-
範圍：它解決的是你要求的事嗎？
把第一段與你的請求對照。找找是否解決了不同的問題，以及沒有人要求的功能。
-
非目標：它不會做什麼？
沒有非目標的規格沒有邊界。把你不想要的額外功能補上。
-
假設：它猜了什麼？
留意「大概」、「可能」，以及任何把它可能沒讀過的程式碼或資料當作事實的陳述。請它列出引用的檔案。
-
邊界情況：出錯時會怎樣？
空輸入、極大輸入、沒有權限、沒有網路、兩位使用者同時操作、同一個動作做兩次。
-
資料：儲存、變更或刪除了什麼？
欄位、格式、誰能讀取，以及既有的紀錄會怎麼樣。
-
遷移：舊資料如何移轉？
結構的變更需要步驟順序、中途失敗的因應計畫，以及可以安全執行兩次的方法。
-
介面：還動到什麼？
API、畫面、排程工作、其他團隊的程式碼。規格有改動卻沒有列出的東西，之後都會變成意外。
-
安全與隱私：誰能做什麼？
新的權限、離開系統的新資料、記錄中的機密。
-
測試：如何知道它能運作？
每項需求都應對應一個檢查。如果某項需求無法測試，就改寫它。
-
上線與回復：如何撤銷？
一個旗標、分階段上線、一條退路。「我們之後再往前修」不是計畫。
-
未解決的問題：誰來決定？
誠實的規格會列出它不知道的事。如果一個都沒有，就要懷疑。
有效的留言
含糊的意見只會得到含糊的改寫。好的審查留言會指向一個段落，說明哪裡有問題，以及你想要什麼：
> The export runs when the user taps Export.
Missing: what happens with a 2 GB file? Add a limit (R4) and an
error message, and say whether the export can be cancelled.把留言和規格文字分開，讓檔案保持乾淨，並集中處理：先把整份規格讀完一遍再留言，這樣代理程式只需改寫一次，而不是十次。
審查循環
-
先從頭讀到尾
留言之前，先確認你理解整份計畫。
-
在確切的段落上留言
每則留言只談一個問題。
-
讓代理程式修訂
它會處理每則留言並產生新版本。
-
檢查改了什麼，而不是整份文件
閱讀差異。修正可能弄壞原本沒問題的部分。
-
檢查表全部通過才核准
接著讓它依據編號需求開發。
當一個代理程式審查另一個代理程式的規格時，同一份檢查表也適用。請審查者以規格中的引文回答每一項。
常見錯誤
- 只審查風格，不審查實質。整齊的規格仍然可能是錯的。
- 因為很長就核准。長度不等於涵蓋範圍。
- 略過非目標與回復，這是模型最常寫得單薄的兩個區段。
- 修改程式碼而不是規格。如果計畫有誤，先修正計畫。
- 沒有再看一遍。代理程式修訂之後，請檢查差異。
關於審查 AI 撰寫規格的常見問題
如何審查 AI 撰寫的規格？
先確認它解決的是對的問題，再找缺漏：非目標、邊界情況、資料與遷移、測試與回復。對每個段落留言，並在它寫程式碼之前讓代理程式修訂。
規格審查檢查表應該包含什麼？
範圍、非目標、假設、邊界情況、資料、遷移、介面、安全、測試、上線與回復，以及未解決的問題。
一個 AI 代理程式可以審查另一個代理程式的規格嗎？
可以。把檢查表交給審查者，請它以規格中的引文回答每一項。要接受什麼，仍然由你決定。
為什麼不直接讀程式碼？
到那時決定都已經做了，要改的代價很高。錯誤的假設，在規格階段修正最便宜。