當實作不再是瓶頸：把「選擇與驗證」工程化

當 coding agent 讓實作成本驟降，組織的稀缺資源從「產出」變成「選擇與驗證」。從 Claude Design 的 Labs 方法論提煉可遷移判斷：原型與 PRD 的不確定性等級、feedback loop 工程化、以及為「差一點就能跑」下注的模型能力債。

江中喬

14 7月 2026 • 11 min read

工程師變快之後，組織並不會自動變聰明。Claude Code 讓「把功能做出來」的成本快速下降，產品時程從數月壓縮到數週、數天，有時甚至幾個小時就能推到使用者面前。於是真正稀缺的東西換了位置：不再是產出代碼的能力，而是弄清楚該做什麼、如何證明它做對了。

這不是抽象趨勢。Anthropic Labs 產品經理 Dan Carey 分享 Claude Design 的開發過程時，幾乎整場都在回答同一個問題：當實作不再是瓶頸，團隊該如何重新設計自己的工作系統。我認為，這場分享最值得帶走的，不是某個 AI 設計工具的功能清單，而是一套可遷移的判斷——把「選擇 → 驗證 → 修正」做成可複利的工程循環。

瓶頸轉移：從 build 到 choose

過去很長一段時間，軟體組織的節奏由開發產能決定。需求排隊、設計等工程、工程等 review，整條鏈的吞吐量卡在「能不能做出來」。當模型與 coding agent 把這一段大幅加速，鏈上的下一節就會立刻露出來：

我們是否真的理解問題？
兩個看起來都合理的方案，該押哪一個？
回饋來了，誰的聲音該權重大、誰只是最吵？
犯錯之後，要多久才能發現自己偏了？

Carey 的表述很直接：工程師速度拉起來之後，設計師與產品經理若跟不上，團隊就只剩兩條路——跳過前期判斷、邊做邊賭，或幫「決定做什麼」的人也配上加速工具與新流程。Claude Design 的誕生，本質上是後者：不是再堆一個畫圖功能，而是回應「選擇本身變慢」的組織問題。

這和「掌控思想，而非代碼」其實是同一條曲線的兩端。工程側，價值上移到 mental model、測試與意圖；產品側，價值上移到問題定義、原型驗證與回饋閉環。兩邊都在說：執行可以被放大，選擇與驗證仍然稀缺。

原型取代 PRD？先問你在哪個不確定性等級

Labs 在探索期刻意不做的事，聽起來很反體制：沒有事先寫好的 PRD、沒有願景長文、沒有為兩年後寫的企劃。原因很務實——他們當時並不清楚要做什麼，只有一個靈感與一絲「這可能行」的熱度。

用原型而不是文件，是因為文件的表徵密度常常不夠。兩個人讀同一份規格，腦中可以是兩種完全不同的產品體驗，而且兩者都未必是作者原意。可操作的原型強迫歧義現身：你點得到、改得到、感覺得到卡頓與直覺是否成立。Carey 甚至把工作流收斂成：錄音討論「為什麼要解這個問題、好解法該具備什麼特徵」→ 轉錄 → 丟給模型要幾個可運行選項。對一個寫了近二十年 PRD 的 PM 來說，這已成為主路徑。

但我不會把這句話收成「PRD 已死」。更精確的說法是：不同不確定性等級，需要不同密度的表徵。

階段	真正的風險	較適合的表徵
方向未定、在找火花	過早寫死錯誤願景	對話、可操作原型、小範圍 dogfood
方向大致清楚、多人協作	各自腦補導致整合爆炸	簡短意圖文件 + 可跑原型 + 驗收標準
不可逆、合規、基礎設施	決策不可追溯、前提未驗證	明確前提、Decision 紀錄、測試與回滾

危險的不是文件，也不是原型，而是兩種偽裝：

假 PRD：寫了很多，卻沒人共享同一套 mental model。
假原型：看起來很完整，卻無法驗證關鍵行為，只是更高成本的投影片。

探索期用原型逼出真實體驗；一旦進入「多人、多系統、要為後果負責」的階段，意圖、邊界與驗收就必須被寫清楚——不是為了儀式，是為了讓下一個 agent 或下一個工程師，能在正確的模型上工作。

真正的技術題：把 feedback loop 工程化

Carey 反覆強調的，不是「我們很敏捷」這種口號，而是一個很工程的事實：在約十週內，他們把「發布 → 觀察 → 學習」跑了數十到上百次。當循環會被執行 50 到 100 遍，循環裡每一步的摩擦力都會被複利放大。

於是問題變成系統設計題：

與使用者交流如何變成世界上最簡單的事？（人會做簡單的事，少做困難的事。）
設計與實作之間有多少重複貼上、重述脈絡、等排程的損耗？
回饋量爆掉之後，人腦是否還能當唯一的分群與初析引擎？

他們的答案很一致：先為自己的痛點造工具，再讓這些工具長成產品能力。 共享頻道與大量內部試用降低「聽使用者」的啟動成本；用模型掃對話找共通點，做初步分析（真正對話仍由人進行）；自建回饋分群，把 bug 初判與修復建議接到開發工具；把設計交接給 coding agent 的路徑打通，避免一次次重灌上下文。多人即時共編同一設計，起初是為了讓三人小隊更快，上線後立刻變成使用者的核心需求。

這對做 AI Agent 或內部自動化的人特別有啟發：Agent 不該只加速「寫一段 code」，而該嵌入整條鏈——

意圖蒐集 → 方案成形 → 實作 → 部署 → 回饋分群 → 下一輪意圖。

若你的系統只優化中間某一節，兩端仍靠人肉搬運，整體吞吐量很快會被最慢的介面卡住。所謂 AI 原生工程，比較接近把這條 feedback loop 做成可觀測、可半自動、可在 24–48 小時內轉一圈的管線。

小而全能：何時需要三人，何時需要議會

Claude Design 開發期多數時間只有三人，加上模型當「好隊友」。幾乎每個 Labs 項目都從一人開始：不是做世界最好的產品，只是尋找短暫的奇妙瞬間——那一絲熱度。多數押注過不了這關就收掉，完全正常；一旦有火花，再把團隊擴到極小而緊密的三人，把協調成本壓到「跟左右鄰居講一句話」。

在這種密度下，角色界線會溶解：工程師訪談使用者，PM 寫程式，設計師碰數據。不是浪漫地取消專業，而是每個人都必須能獨立跑完一小圈循環，否則三人小隊會重新長出大公司的等待。

這裡有一個對多代理、多角色協作很實用的張力：

認知多樣性有價值：不同視角能抓住單一角色的盲點。
協調成本也真實：角色一多，等待、對齊、重述上下文就會吃掉迭代次數。

實務上可以這樣切：找火花與驗證產品輪廓時，偏小而全能；一旦決策不可逆、跨系統、或需要強制異議（安全、治理、架構分岔），再引入第二視角或正式 review。多樣性是手段，不是預設編制。先問「這圈循環還能不能在一天內轉完」，再問「要不要再加一個角色」。

速度的意義是更快發現自己錯了

他們犯過很典型的錯：為進階使用者做了極細的控制能力，少數大聲的 power user 很愛；使用數據卻顯示多數人困惑、甚至痛恨。於是整塊拔掉。關鍵不在「從不犯錯」，而在偏離軌道到修正，大約只要一週。

若迭代單位是季度，同一個錯誤可能吃掉整季——而整個產品從構想到上線，往往還不到一個季度。速度在這裡的定義，比較接近：

用足夠小的賭注，維持足夠高的「發現錯誤」頻率。

這也解釋了為何要同時聽使用者抱怨、看研究人員「最近驚訝什麼」，又堅持看使用數據。發言音量 ≠ 回饋權重。模型可以幫你分群與初析，但「這功能到底抬高所有人，還是只服務最會吵的 5%」這類判斷，仍需要人守住。

最反直覺的一課：為「差一點就能跑」下注

Labs 工作裡有一句我認為最有技術含量的話：你通常不想把力氣花在「已經能順利運作」的東西上；你想為「差一點就能運作」的東西做原型。

原因很冷：模型進步極快。下一代能力，常常直接解掉你用精巧工程暫時無解的問題。Claude Design 早期有一堆沒修完的洞，後來不是靠神奇架構補丁，而是模型能力抬升把船一起抬起來。

這意味著產品與系統設計裡，要明確區分兩類問題：

現在就必須工程硬解的——安全邊界、資料正確性、不可逆操作、使用者信任。
可以當「模型能力債」暫時擱置的——品質上限、某些生成穩定性、特定邊緣體驗。

早期探索要找的是一絲魔力與正確的產品輪廓，不是功能齊全、無 edge case 的完美系統。99% 的價值，往往來自之後數十輪與真實使用者共舞的迭代，而不是第一個週末原型本身有多漂亮。

當然，「差一點」不能變成藉口，把關鍵路徑上的正確性賭給未來模型。可以欠的是上限與打磨；不能欠的是會傷害使用者或讓系統不可治理的部分。

你可以怎麼用（不必等一個 Labs）

把上述收成三件可明天就做的事——重點不在速度表演，而在暴露你自己的系統摩擦：

下次想寫長 PRD 時，先停。 跟人（或模型）只談：為什麼要解、好解法的特徵是什麼、怎樣算驗證成功。然後要幾個可操作選項，用具體體驗對齊 mental model。需要留下文件時，寫短意圖與驗收，而不是先寫按鈕清單。
挑一個你循環裡最痛的內部摩擦，用一個下午自建。 回饋分群、會後初析、設計到實作的上下文交接——這些往往比再開一週會更划算。循環會跑很多次時，工具投資會複利。
選一個真實功能需求（不是修間距），在 24 小時內推到真實使用者面前並收回饋。 你會立刻看到部署、審查、權限、溝通何處在拖慢「選擇與驗證」。第一次的價值是診斷流程，不是證明你很猛。

結語

當實作不再是瓶頸，競爭優勢不會自動屬於「生成最多代碼的人」。它會屬於能更快形成正確選擇、更快驗證、更快承認跑偏、並把這整條鏈嵌進日常系統的人與組織。

原型、小團隊、每天發布，都只是手段。底下那層不變：意圖仍由人定義，後果仍由人承擔；模型與 agent 負責把循環轉得夠快，快到錯誤還很便宜的時候就被看見。

執行可以被放大。選擇與驗證，才是接下來真正要被工程化的部分。