Onepage/ Spec hardening
George / PM OS · X Article
AI 寫程式前，規格該先跑一次 edge-case pass
過去，一份不完整的規格通常會被工程師的追問補起來；交給 coding agent，沉默的地方卻可能直接變成一個看似合理、實際錯誤的實作。真正要補的不是「更認真想」，而是一個可重複的邊界情境檢查。
Published: 2026-07-06Author: George / @nurijanianSource: X Article
01 / 失去的安全網
人類會追問，agent 不會「皺眉」
人類工程師讀到模糊條件，往往會在 refinement 時問清楚。Agent 則傾向選一個 plausible 的行為、寫完程式並繼續往下走。
02 / 真正風險
空白會變成隱性產品決策
規格未定義的錯誤處理、退款、重跑與狀態來源，不會因此消失；它們會在 code generator 的預設選擇裡被定義。
03 / 可執行解法
每次都跑同一套八類檢查
使用者、情境、輸入與系統失敗、人為錯誤、功能交互、負載、安全隱私、無障礙，讓常被遺漏的角落有固定席位。
Case study
一個笑臉，遮住了應該被定義的失敗行為
PRD
「訂單總和應等於撥款；不等就有問題 😁」
文章以 Shopify → QuickBooks connector 的真實 PRD 為例。它明說金額可能對不上，卻沒說系統該停止、標記、通知，還是繼續入帳。
Agent
程式可編譯，不表示帳能對上
在沒有明確預期行為時，agent 可能只記一筆 warning、照樣建立發票。因為測試只涵蓋乾淨的 happy path，這個決定不一定會立刻失敗。
Shift
規格的讀者換了，失效模式也換了
人類讀到不完整 spec 的結果是追問；agent 讀到不完整 spec 的結果可能是錯誤功能被完整交付。規格因此需要承擔更多「先定義行為」的工作。
Signals
一次檢查找到的，不是罕見 bug，而是未定義的決策
Scenario 01
不對帳
應停止該筆撥款、顯示差額並通知管理員，而不是處理能對上的部分。
Scenario 02
退款
退款應作為 credit memo；費用、退款與扣款總額仍要先完成 reconciliation。
Scenario 03
手動標籤
UI tag 不該成為唯一真相；connector 需有自己的 processed ledger。
Other misses
3 more
重跑重複開票、授權失敗的半完成狀態，以及幣別未定義，都從同一份 spec 浮出。
The eight-pass
在 refinement 前，把八個方向逐一變成問題
使用者類型與使用情境不同權限、不同角色、非典型流程會如何改變預期？
意外輸入與系統失敗資料不一致、API 超時、token 失效時，是否有明確的停止、重試與呈現方式？
使用者錯誤與功能交互錯誤操作、手動覆寫、功能同時作用時，哪一個狀態才是來源真相？
負載、安全隱私與無障礙規模變大、敏感資料與不同能力使用者出現時，行為與保護措施是否仍被定義？
Practical takeaway
把「可能有問題」改成可驗收的行為
輸出 scenario table，而不是泛泛的提醒每列至少有情境、預期行為與未定義處；這比「記得處理 edge cases」更能帶進 refinement。
先定義停止條件與狀態真相尤其是金流、同步與寫入系統：何時不得繼續？從哪裡判定已處理？重跑會發生什麼？
把它放在 agent context 之前目的不是取代資深工程師的判斷，而是讓原本靠他們臨場補上的問題，在 agent 開始產碼前就成為明確決策。
References