AI 越能完成實作，工程師越需要說清楚：我們究竟在解決什麼問題，哪些差異不能省略，又要用什麼標準判斷成果。

我的看法是，AI 時代需要更強的抽象能力，不一定需要更多抽象層。當寫出程式的成本下降，錯誤理解也能更快變成一套看似完整的系統。工程師的責任因此往前延伸到問題定義，也往後延伸到需求驗收。

這篇從 Matt Pocock 相關討論延伸，談的是我對這個責任的理解。付款案例與以下判準都是本文的工程推論，不是他的逐字主張。

抽象要保留會改變決策的差異

「做一個可擴充的付款系統」聽起來有方向，卻還不足以委派工作。擴充哪一種能力？什麼情況算付款完成？哪些錯誤允許重試？這些沒有定義，AI 只能代替我們猜。

先看四個概念。訂單記錄使用者要買什麼；付款嘗試記錄一次支付操作；付款成功需要可確認的依據；結果未知則表示目前還無法判斷那次操作的結果。它們彼此相關，卻不能用同一個「付款狀態」含糊帶過。

假設使用者按下付款，請求送出後連線逾時。此時，我們知道的是沒有收到結果。支付端可能尚未處理，也可能已經完成扣款，只是回應沒有送回來。

若把這兩種情況都壓成「失敗」，系統就可能提示使用者重新付款，開啟另一筆扣款。問題在寫第一行程式之前就已存在：我們把「不知道」錯當成「沒有發生」。

好的抽象會留下這個差異，讓後續的人知道還需要查詢、等待通知或對帳。它也不要求所有人先懂支付 SDK 的細節，才能討論使用者接下來應該看到什麼。

共同語言的價值就在這裡。Matt 的 domain-modeling skill 會追問含糊詞彙，以具體邊界案例檢查概念，再對照既有程式。這種做法能讓分歧提早浮現；詞彙表本身仍然需要人的判斷。domain-modeling 一手文件

AI 也可能忠實完成錯誤的理解

我們容易擔心 AI 沒照要求寫，卻忽略另一種情況：它完全照著錯誤要求完成了工作。

如果規格寫著「逾時就標記付款失敗」，AI 可以補上狀態更新、重試按鈕與測試。測試也會斷言逾時之後出現失敗狀態，然後全部通過。

這套結果在內部可能十分一致，卻沒有回答真正的問題：使用者是否已被扣款？下一次操作會不會造成重複付款？

更多測試不會自動修正錯誤模型。實作更容易委派後，我會把更多心力放在那些會改變行為的定義、前提與例外，而不是急著指定類別名稱。

把逐步指揮改成可驗收的契約

委派付款功能，不必從「先建 service，再加 repository」開始。我更想先確認四件事：

  • 能力：使用者要完成什麼，可以觀察到什麼結果
  • 前提與輸入輸出：接受哪種訂單，結果有哪些可能，各自代表什麼
  • 不可破壞的規則：哪些狀態不能被混用，哪些副作用不能重複發生
  • 驗收：用什麼案例與證據判定這次工作完成

以前面的情境為例，本輪目標可以是「付款逾時後，仍能追查同一筆付款嘗試的結果」。結果未明時，不能直接標示確定失敗，也不能因重新整理頁面就建立另一筆扣款。後續取得可信結果後，訂單才依已確認規則更新。

這仍不是完整的支付規格，但已經指出需要驗證的行為。至於退款、部分付款或更換供應商，可以明確列在本輪範圍之外，避免「可擴充」變成無限加功能的理由。

Spec 與 Story 應保存這些已確認的決策。拆成前端、API 與背景查詢三項任務時，每項都必須帶著同一個限制：結果未知不能被當成失敗。否則任務切得越細，原本的意圖反而越容易消失。

文件的長度不是重點。下一個執行者能否理解決策，並交出對應證據，才是文件有沒有發揮作用的判準。

抽象清楚之後 系統可能更小

我把 PraxisBound 收斂成 Warrant，也是在重新決定哪些責任值得留下。

Warrant 聚焦於人核准的意圖、工作範圍與驗收證據。公開文件把 Story 收成目標、範圍外與驗收條件三段，讓既有工具負責執行，使用 repo 本身的驗證入口檢查結果。它沒有再包一套腳本、CLI 或套件。Warrant 繁中 README

對我而言，這是抽象能力帶來的減法。當一層只增加轉手，卻沒有承擔必要規則、減少理解成本，就值得問：拿掉它之後，真正的責任是否反而更清楚？

這裡也有一條不能省略的界線。文件寫著「不得擴大範圍」，不代表技術上已阻止越界。涉及硬性限制時，仍需要相應的工具權限、執行環境與不可被任意略過的驗證。Warrant 的文件也明示，強制力仰賴採用端的 CI 與人工審查。

規則說明應該怎麼做；我們仍要檢查，環境究竟能擋下什麼。

讓小實作回頭檢查規格

契約需要先確認，卻不能因此被當成永遠正確的答案。規格裡的缺口，常常要走過一小段實作才會出現。

例如我們寫下「稍後查詢付款結果」，實作時才發現既有資料沒有保存查詢所需的付款識別碼。這時應回到模型與範圍確認：要補存哪個識別碼？舊資料如何處理？這輪能做到哪裡？不能讓 AI 為了交差，自行把結果未知改成失敗。

我會用一個小循環開始：先確認一個使用者情境，列出成功、失敗與未知的例子；批准本輪目標和限制；做出足以檢查假設的小實作；再拿結果修正规格。變更涉及原先取捨時，重新確認後再繼續。

驗收也需要另一個參照點。若程式與測試都由同一份誤解生成，它們可能一起通過。因此要把結果對照已由業務確認的案例，以及已確認需要保留的既有行為。舊程式可能有錯，不能不加判斷地把全部現況當成標準。

付款例子至少要涵蓋：逾時後確認成功、明確拒付，以及結果仍未知時使用者再次操作。檢查的是最後的訂單與付款事實，不只是某個函式有沒有被呼叫。換一個 AI 審查也有幫助，但若它仍沿用同一份錯誤前提，就沒有真正獨立的驗收依據。

在問題與證據之間往返

未來重要的能力，是能從使用者問題整理出領域概念，將概念寫成契約與規則，交給實作，再用驗證結果回頭檢查理解。

這不是只往前走的流程。一次驗收可能揭露概念混淆，一小段實作也可能推翻原本的假設。AI 可以協助每個環節，但人不能因為委派了工作，就放棄理解重要取捨與決定驗收標準。

AI 可以幫我們完成更多實作。抽象能力，幫助我們知道什麼值得實作，以及如何判斷它做對了。

下一個交給 AI 的任務，可以先挑一個最容易被混用的概念，寫下正常、例外與結果未知的案例。若還無法說明它們應有的不同行為，就把這個問題留在待確認事項，別讓實作者自行補成答案。

來源與延伸閱讀

資料查核日期：2026-10-04。付款情境是設計示例，不代表已完成的專案或實測。