Compounding Loop Optimization

資料來源#

• Designing with Claude: From prompt to production

摘要#

Dan Carey 描述了 Claude Design 背後的營運引擎：一個基本的建置循環——與使用者交談 → 設計功能 → 交付程式碼 → 閱讀回饋 → 重複——在十週內執行了「大約 50 到 100 次」，而且循環中的每個重複步驟都經過積極最佳化或自動化。團隊對每個步驟都會問的核心問題是：*「為什麼要做 Claude 能替你做的工作？為什麼還沒打造自己的工具？」*效益會層層累積：從循環中移除的任何阻力，都等於移除了 50 到 100 次，因此成本低廉的內部工具——許多只花一個下午打造——累積成推動三人團隊在十週內交付產品的速度。Carey 明確指出，具體的循環並不重要（「如果你在做硬體，這就不是適合你的循環」）；真正可轉移的是把自己的迭代循環視為最佳化對象的思維方式。

為什麼最佳化會產生複利#

減少規劃阻力（以原型取代 PRD，Prototype Over PRD）和協作阻力（精簡團隊，Engineer PM Convergence）就能讓你「相當快」。更上一層的做法，是最佳化其他每個步驟：

「你在循環上做的每一點最佳化，只要你在一個專案中執行它 50 到 100 次，就會帶來回報。」

這是精實新創循環加上 AI 原生的轉變：打造用來最佳化循環的工具，成本已大幅降低。推動行動的問題不再是「我們負擔得起打造這個內部工具嗎？」而是「為什麼我們還沒打造？」

四個步驟，每個都加上儀表#

與使用者交談——讓這件事變得極其簡單#

「我們都是人。人會做容易的事。」因此團隊移除了與使用者交談時每一絲阻力：建立所有產品使用者都在其中的共用 Slack 頻道，大力推動內部自家試用。接著在對話之後（絕不介入對話之間）加入 Claude 作為分析層：Claude 讀取每段客戶對話，找出其中的共通點——因為兩位隊友可能分別從不同使用者那裡聽到相同建議，否則永遠不會把兩者連結起來。「對話是由我們來進行……但我們讓它負責所有分析。」

設計功能——使用自己的工具#

自行託管：「我們想用 Claude Design 來設計 Claude Design。」這是最純粹的自家試用案例（參見 Dogfooding as Product Discipline）。多人協作（即時共同編輯）等功能，直接源自觀察自身工作流程中的阻力，之後成為產品第一個由使用者提出的功能。

交付程式碼——消除交接阻力#

交接給 Claude Code 的功能之所以存在，是因為團隊總得在不同工具之間重新輸入長時間 Claude Design 對話中累積的所有背景資訊，才能把設計投入正式環境。他們把自身遇到的阻力自動化；這成了使用者第二常要求的功能（「那我要怎麼把它放進正式環境？」）。

閱讀回饋——打造你正在等的工具#

產品推出時，團隊收到的回饋多到沒有任何一個人讀得完。因此他們花一個下午打造了回饋聚類工具（「這不是我們打算等待的事情」）。現在 Claude 會先處理所有收到的回饋：將回饋與系統監控指標和追蹤資料比對、尋找趨勢、進行初步錯誤分析、提出修正建議，並提供按鈕，讓人直接把建議送進開發工具——每一項新增功能，都是先前由人手動完成的一個步驟。

「直接打造」——按需提供內部工具#

Carey 第二個「明天就試試」的行動，正是本文主旨的直接指引：

「挑一件你一直在等的事……花一個下午直接把它打造出來。大家都在等工具，但到了現在，內部工具……打造起來很快。去解決你自己的痛點吧。它很快就會回本。」

這與 Problem-Solution Fit Discipline 提到的相同經濟效益（「一個下午做出原型」），只是應用在內部工具上；這也說明了為什麼 Cat Wu 提到 Anthropic 團隊會打造「供個人化工作流程使用的自訂內部應用程式」。

緊密循環也能迅速抓出錯誤決策#

反覆執行循環的另一項效益，是能很快發現自己錯了。團隊推出進階的像素級控制功能，深受熱情的重度使用者喜愛，後來卻發現「其他所有人都討厭它們」，於是把功能移除了。總共只花了一週。「如果我們採用季度開發週期……就會整整一季都偏離方向。」Carey 得出的教訓不是「永遠要快」，而是「永遠要用夠短的週期迭代，才能迅速發現自己何時做錯」——把進行實驗的紀律應用在產品推出之後；而產品工藝的結論是，工具應該為所有人提升下限，而非只為重度使用者拉高上限（參見 Claude Design）。

延伸閱讀#

• Polish No Longer Signals Readiness — 快速產出精緻探索成果的速度，可能讓人對看起來像正式產品的原型過度錨定
• Dan Carey — 闡述這套紀律
• Claude Design — 以這種方式打造的產品；其許多功能都是循環最佳化的結晶
• Prototype Over PRD — 規劃步驟的最佳化；本文把相同思路套用到其他每個步驟
• AI Native Product Cadence — 這個循環所在的團隊與流程節奏；Carey 是支持這套做法的第二個 Anthropic 案例
• Dogfooding as Product Discipline — 「與使用者交談，讓這件事變得最簡單」和「使用自己的工具」都是自家試用；Claude 輔助的對話分析則是規模化的做法
• Product Velocity as Moat — 徹底最佳化循環帶來的外部效益：週五到週一交付 62 項改進；速度成為差異化優勢
• Problem-Solution Fit Discipline — 緊密循環讓你能在一週內發現錯誤決策（重度使用者控制項），不用等上一季
• Build for the Next Model — 持續執行循環的另一個理由：下一次模型發布會補上工程能力無法彌補的缺口
• Managers as ICs — 打造自己的工具，前提是每個人都會寫程式；以 IC 為主的扁平組織就是其基礎
• Harness Shrinkage as Models Improve — 隨著模型原生地承接更多步驟，循環中的內部工具會縮減或改變
• Agent Quality Flywheel — 將代理程式開發中的閱讀回饋／修正步驟產品化：Google 將評估、分析、修正做成可安裝的循環，正是「為什麼還沒打造自己的工具？」的廠商版本

尚待解答的問題#

• 這個循環假設團隊本身就是（或接近）使用者。當使用者和建造者不同，而且「與使用者交談」無法在同一個空間進行時，這種複利優勢還能保留多少？
• 值得打造的內部工具與無止境的小事之間，界線在哪裡？Carey 設定的「一個下午」門檻是判斷準則，但 Cat Wu 警告，過度客製化設定「會變成干擾」。
• Claude 負責第一輪處理所有回饋，會不會漏掉未形成群聚的罕見訊號？自動化分類能最佳化常見情況；令人意外的決策往往來自少數案例。

資料來源#

• Designing with Claude: From prompt to production