建構很便宜，爭論很昂貴

資料來源#

Running an AI-native engineering org

摘要#

Fiona Fung 對技術辯論的準則是：當代理式程式設計讓產出幾乎不花成本時，「在技術辯論中，程式碼勝出——建構很便宜，爭論很昂貴。」 當你能在安排白板會議所需的時間內產生三種真實實作，就不再爭論各種做法，而是開始比較它們。Claude Code 的相應規範是：製作原型並親自試用，而不是撰寫設計文件；減少深入的規劃文件，改以 PR 和原型進行討論。

產生三個 PR 的做法#

Fung 分享了一段親身經歷：剛開始使用 Claude Code 時，她和 Boris Cherny 討論重構做法。過去的直覺反應是：「我們去會議室用白板討論吧。」這次她改為：「多虧了 Claude，我產生了三個不同版本的 PR」——這讓技術辯論更有成效，因為她不只可以比較程式碼的實作方式，還能比較對呼叫端的影響。產出物（真實、可執行的 PR）承載的資訊比討論（白板上的抽象概念）更多，而現在製作它的成本很低。

以原型取代設計文件#

相同的成本變化也改寫了原型製作的方式。以前，原型製作會讓團隊分成兩派——一派認為它能快速取得回饋，另一派則認為這是走捷徑，最後卡在交付無法擴充的拋棄式程式碼。有了 Claude，第二種顧慮就沒那麼有力了：「原型製作是很好的起步方式，因為我們可以反覆迭代、從中學習，接著更快地把原型擴展到正式環境。」所以 Claude Code 的規範是：有個想法 → 製作原型 → 親自試用 → 再做決定。（參見 prototype：「用一次性的原型把設計具體化」的做法。）

減少什麼：設計文件#

團隊減少的是：「非常深入的規劃與設計文件。我們大多數的討論實際上都在 PR 或原型中進行。」這是 Verification as the New Bottleneck 帶來的後續影響——當工程產能不再稀缺，過去為了保護產能而存在的大量前期規劃，也就失去了理由。重構與架構整理過去常在「什麼時候才有時間做？」的預算角力中落敗，如今也不再是瓶頸。

必須兼顧的張力#

這項規範與知識庫中以規劃為先的概念形成良性的張力。Design Concept Grilling（Matt Pocock）和 Vertical Slice Tracer Bullets 主張，開始建構之前必須先對設計概念取得共識。兩者的調和方式是：「建構很便宜」並未取消設計思考，而是改變了設計思考發生的位置。你仍然需要品味與規格（Outsource Your Thinking, Not Your Understanding），但你是透過比較已建構的產出物來得出它們，而不是抽象地爭論。建構成本低，讓原型成為設計的媒介，而不是設計的替代品。（Karpathy 在 Vibe Coding vs. Agentic Engineering 中也取得相同平衡：規格仍由人類負責。）

尚待解答的問題#

什麼情況下「產生三個版本再比較」會變得浪費？決策的重要性達到什麼程度時，直接認真討論（或撰寫設計文件）仍比製作三種實作便宜？
如果設計討論都發生在 PR／原型中，未來的讀者要去哪裡找決策理由？「我們為什麼這樣選」的知識能否留存？還是也會遇上 Code as Source of Truth 的過時問題？部分已有答案：Where Does the Why Live?——答案是無法留存：埋在已合併 PR 中的討論，對未來讀者而言形同失聯，而且目前沒有任何候選位置能長期保存這些理由。尚未解決的是，部分補救方式（內容更豐富的計畫產出物、編譯後的知識庫）是否能在團隊規模下實際奏效。

衍生文章#

The PRD-Replacement Spectrum at AI-Native Speed — 以建構來做決策是光譜中的中間位置；本頁提出的理由失聯問題，是光譜上第一項尚未解決的債務
Where Does the Why Live? — 針對本頁的決策理由問題提供深入回答：在 PR 中討論會埋沒決策理由，而目前沒有任何候選位置能長期保存它

資料來源#

Running an AI-native engineering org

建構很便宜，爭論很昂貴

資料來源#

摘要#

產生三個 PR 的做法#

以原型取代設計文件#

減少什麼：設計文件#

必須兼顧的張力#

延伸閱讀#

尚待解答的問題#

衍生文章#

資料來源#