/edge-cases: a simple skill to catch missed edge cases

原始來源與檔名：2026-07-07T092603+0800-edge-cases a simple skill to catch missed edge cases.md

SOURCE | 資訊源評估

這是一篇從產品經理 (PM) 及系統工程視角出發的實踐心得，精準地點出在 AI 輔助開發時代 (AI Coding Agents) 下，需求規格書 (PRD) 撰寫模式必須發生的典範轉移。文章邏輯清晰、對比強烈，強烈推薦給正在導入 AI 開發工具的 PM、系統分析師 (SA) 與架構師閱讀。

NAPKIN | 餐巾纸

一句話：在 AI Agent 時代，模糊的 PRD 不再換來工程師的提問，而是換來自信滿滿的錯誤程式碼，因此我們需要系統化的八大邊界測試來防禦。 餐巾紙草圖：

[ 模糊的 PRD ]
      |
      +--> (Human Engineer) --> [ 產生困惑/提問 ] --> [ 釐清邊界條件 ] --> [ 健壯的系統 ]
      |
      +--> (AI Agent)       --> [ 腦補實作/記錄警告 ] --> [ 繼續執行 ]   --> [ 靜默的財務災難 ]

ROUND 1: SKELETON | 骨架掃描

• 核心問題：為何過去看似可行的「半成品」規格書，在交給 AI Coding Agent 後會引發嚴重的系統災難？
• 核心答案：AI Agent 缺乏人類的「困惑機制」(Backstop of confusion) 與主動提問能力。必須在開發前，透過八大類別的結構化掃描，強制作出明確的邊界決策。
• 論證結構：
  1. 現象觀察：以一個真實的 PRD 漏洞（用 😁 帶過錯誤處理）為例，對比人類與 AI 的處理差異。
  2. 根本原因：人類的困惑是天然的防呆機制，但這層機制對 AI 不存在。
  3. 解決方案：執行結構化的八大邊界條件檢查 (Eight-category pass)。
  4. 實例演練：展示三個具體的遺漏案例 (退款、手動標籤、金額不符) 以及 AI 可能的危險實作。
  5. 反思與結論：強調這不是資深工程師的專利，而是 PRD 撰寫者必須在精煉會議 (Refinement) 之前完成的本職工作。

ROUND 2: DISSECTION | 血肉解剖

• 核心論證鏈：模糊的規格 $\rightarrow$ 失去人類的提問防線 $\rightarrow$ AI 盲目自信地實作假定路徑 $\rightarrow$ 發生難以追查的靜默錯誤 (Silent failures) $\rightarrow$ 需將防護前置到規格定義階段。
• 關鍵證據：
  • PRD 原文：「如果加總不等於付款金額，那就是有地方錯了 😁」
  • AI 實作推演：面對金流對帳不攏，AI 不會中斷，只會記錄一行 warning，然後繼續把帳單寫入 QuickBooks。
• 隱形假設與邊界條件：
  • 過去的假設：開發流程中總有一個「會思考的人」作為規格的最後守門員。
  • 邊界條件：當自動化程度極高，需求到程式碼的轉換摩擦力趨近於零時，任何模糊都會被放大為系統風險。

ROUND 3: SOUL | 靈魂提取

• 作者盲點：雖然強調了 PM 必須在事前定義清楚，但並未探討如何讓 AI Agent 本身具備「遇到模糊規格主動反問 (Ask for clarification)」的機制。
• 知識連結：防禦性設計 (Defensive Design)、契約式設計 (Design by Contract)、系統性思考、Prompt Engineering 中的「Zero-shot vs. Interactive prompting」。
• 留白提問：若每次都需要人工執行八大類別檢查，是否可能發展出一個專門用來「審查 PRD 邊界條件」的 Reviewer Agent？
• 跨域映射：如同自動駕駛系統，當移除了人類駕駛（提問者），系統必須具備更嚴苛的防撞感測器（邊界條件定義）。
• 行動觸發：在將任何 Prompt 或 PRD 交給 AI Agent 實作前，強制作為一個審查關卡，檢查「異常狀態下系統該做什麼」。

DEEP READ | 精讀指引

• 推薦段落：“An AI coding agent doesn’t snort… The code compiles, because the tests you didn’t write can’t fail.” (AI 程式代理人不會哼聲…)
• 推薦理由：這段話極其精闢地總結了 AI 時代開發的最大隱患。它點出了「編譯成功」與「測試未寫」所造成的虛假安全感。AI 的高生產力同時也是高風險的放大器，這對架構設計者來說是必須深深刻在腦海的警語。

/edge-cases: a simple skill to catch missed edge cases (Architectural Deep Dive)

前言/背景

本文探討在 AI 輔助開發時代 (例如使用 Claude 或 Cursor)，軟體需求規格書 (PRD) 撰寫方式的根本性變革。過去依賴人類工程師在閱讀模糊規格時產生的「困惑與提問」作為最後防線，但 AI Agent 會忽略這些模糊地帶並直接給出看似合理的實作，這可能導致嚴重的靜默系統故障 (Silent Failures)。為解決此問題，作者提出了一套系統化的八大邊界條件檢查法。

消失的防線：人類工程師的困惑 (The Backstop of Confusion)

作者從一個真實的 Shopify 到 QuickBooks 的 API 串接 PRD 說起，裡面有一段描述：

“there could be 2 or more orders, whose aggregate sum should equal the payout amount. (if it doesn’t then something is wrong 😁)”

在傳統開發流程中，人類工程師看到這個笑臉 (😁) 會產生困惑，並在需求精煉會議 (Refinement) 中提問：「如果金額不符，我們具體該怎麼處理？」這個提問填補了規格的空白。

但 AI 開發代理 (AI coding agent) 的運作邏輯完全不同：

• 不會提問：AI 不會對這個笑臉感到困惑而停下來。
• 盲目自信的實作：它會選擇一個看似合理的策略（例如：記錄一個警告日誌），然後繼續建立那些金額不符的發票，寫下充滿自信的程式碼。
• 靜默失敗：因為你沒有寫針對這種邊界條件的測試，所以程式碼會編譯通過，測試也不會失敗。直到會計發現帳目無法核對時，災難已經發生。

這意味著，寫給 AI 看的規格，其容錯率遠低於寫給人類看的規格。 人類的困惑曾是一道隱形防線，現在這道防線被移除了。

解決方案：八大類別的結構化掃描 (The Eight-Category Pass)

面對這種情況，僅憑一句「要多思考邊界條件」是無效的。作者提出了一種結構化的掃描方法，必須按照固定順序對 PRD 進行檢查：

1. 使用者類型 (User types)
2. 使用情境 (Contexts of use)
3. 預期外的輸入與系統故障 (Unexpected inputs and system failures)
4. 使用者錯誤 (User error)
5. 功能交互作用 (Feature interactions)
6. 系統負載 (Load)
7. 安全與隱私 (Security and privacy)
8. 無障礙設計 (Accessibility)

透過這種固定順序的檢查，可以強迫自己涵蓋那些經常被遺忘的維度。

PRD 掃描實戰：以 Shopify-QuickBooks 串接為例

作者將上述掃描法應用於原本看似完美的 PRD (包含 API 文件連結、一條 $2,000 的正常金流驗收測試)，結果找出了 27 個潛在情境。以下是三個極具代表性的案例對比：

1. 總和不符 (The 😁 line itself)

• 情境：交易總和 $\neq$ 實際付款金額。
• 預期架構行為：中斷該筆付款的入帳流程，在管理介面標示「對帳失敗 (Reconciliation failed)」，顯示雙方數字與差額，通知管理員，且絕對不要將部分吻合的發票入帳。
• AI 可能的實作：寫一行 log，然後全速前進。因為「有地方錯了 😁」並沒有包含「停止 (stop)」的指令。

2. 退款處理 (The Refund)

• 情境：一筆 $2,000 的付款，實際上是由 $2,300 的消費扣除 $300 的退款所組成。
• 預期架構行為：退款應在 QuickBooks 中轉為信用額度 (Credit memo)，並確保（消費 + 退款 + 手續費）在寫入系統前，仍能與總金額核對一致。
• AI 可能的實作：產生一張 $-300 的「負數發票」，或者直接靜默地跳過退款。因為 PRD 提供的測試案例只有乾淨的消費紀錄。

3. 手動標籤狀態 (The Tag)

• 情境：管理員手動在一個未經連接器處理的訂單上加上了「已入帳 (Booked)」的標籤。
• 預期架構行為：連接器不應將此標籤視為單一事實來源 (Source of Truth)，應維護自身的處理狀態帳本 (Ledger)，確保被誤標的訂單仍能正確入帳。
• AI 可能的實作：將該標籤作為狀態判斷依據。只要管理員手滑加上標籤，該訂單就會永遠從入帳流程中消失，且不會有任何報錯。

此外，還有像是缺乏冪等性 (Idempotency) 導致的重複入帳、認證失敗 (Auth failure) 導致的一半寫入卻無檢查點 (Checkpoint)，以及幣別未指定導致的匯率錯亂等問題。

總結與結論 (Key Takeaways)

1. 防護左移 (Shift-Left Defense)：在 AI 輔助開發時代，架構與邊界條件的定義必須極度前置。PM 或架構師不能再依賴工程師的「提問」來補足規格，必須在丟給 AI Context Window 前完成結構化掃描。
2. 明確定義異常行為 (Define Failure Modes)：永遠不要只寫 Happy Path。對於「資料不一致」、「API 斷線」、「非預期輸入」，必須明確給定系統反應（例如：中斷、回滾、重試、告警）。
3. 警惕「編譯通過」的虛假安全感：AI 產生的程式碼通常看起來很工整且能通過編譯，但這往往是因為它默默吞下了錯誤 (Swallowed exceptions) 或跳過了複雜的邊界檢查。
4. 建立防呆的系統架構 (Idempotency & Checkpoints)：在串接外部系統 (尤其是金流) 時，API 的冪等性 (Idempotency) 以及交易的檢查點 (Checkpoints) / 分散式交易補償機制，是無論 PRD 有沒有寫，架構設計上都必須強制的底層基礎設施。