複利迴圈優化

資料來源#

• Designing with Claude: From prompt to production

摘要#

Dan Carey 闡述了 Claude Design 背後的營運引擎：一個基本的建置迴圈——與使用者交談 → 設計功能 → 交付程式碼 → 閱讀回饋 → 重複——「在十週的過程中執行了大約 50 到 100 次」，而且其中每個反覆出現的步驟都經過積極優化或自動化。團隊對每個步驟提出的核心問題是：「為什麼要做 Claude 可以替你做的工作？為什麼還沒建立自己的工具？」 回報是乘法式的：你從迴圈中移除的任何摩擦，都會被移除 50–100 次，因此便宜的內部工具——其中許多在一個下午就能建立——會複利成足以讓三個人在十週內交付產品的速度。Carey 明確表示，具體是哪個迴圈並不重要（「如果你在做硬體，這就是錯誤的迴圈」）；可轉移的重點是把自己的迭代迴圈視為需要優化的對象，並以此思考。

為什麼優化會產生複利#

移除規劃拖力（以原型取代 PRD，原型優先於 PRD）和協作拖力（小型團隊，工程師與 PM 的融合）就能讓你「相當快」。更進一步的做法，是優化其他每一個步驟：

「你在迴圈上做的每一點優化，只要你在一個專案中執行它 50 到 100 次，就會回饋給你相應的成果。」

這是帶有 AI 原生轉折的精實新創迴圈：建置用來優化迴圈的工具之成本已經大幅下降。現在的推動問題不再是「我們能不能負擔建立這個內部工具？」而是「我們為什麼還沒建立它？」

四個步驟，各自都經過儀表化#

與使用者交談——讓它成為世上最容易的事#

「我們是人。我們會做容易的事。」因此，團隊移除了與使用者交談時的每一絲摩擦：讓所有產品使用者都加入共享 Slack 頻道，並大量進行內部 dogfooding。接著，他們把 Claude 加到對話背後作為分析層（絕不介入對話之間）：Claude 讀取每段客戶對話，找出其中的共同點——因為兩位隊友可能從不同使用者那裡聽到同一個建議，否則永遠不會把它們連結起來。「我們是進行對話的人……但我們讓它完成所有分析。」

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

自我託管：「我們想用 Claude Design 來設計 Claude Design。」這是最純粹的 dogfooding 案例（參見 Dogfooding 作為產品紀律）。multiplayer（即時共同編輯）等功能，直接源自觀察自身工作流程中的摩擦，之後成為產品第一個由使用者提出的功能。

交付程式碼——消除交接摩擦#

交接至 Claude Code 的功能之所以存在，是因為團隊一直得在不同工具之間重新輸入他們從一段漫長的 Claude Design 對話中累積的所有脈絡，只為了把設計帶入 production。他們將自己的摩擦自動化；這成了使用者要求度第二高的功能（「那現在我要如何把它帶入 production？」）。

閱讀回饋——建立你正在等待的工具#

產品上線時，團隊收到的回饋多到任何一個人都無法全部閱讀。因此，他們「在一個下午內」建立了回饋聚類工具（「我們不會等它準備好」）。現在，Claude 會先處理所有進入的回饋：將其與系統監控器和追蹤記錄配對、尋找趨勢、執行初步錯誤分析、建議修正方式，並提供一個按鈕，直接將修正推送至開發工具中——每一項新增功能，都是人們過去必須手動完成的一個步驟。

「直接建立它」——按需打造內部工具#

Carey 提出的第二個「明天就試試」行動，是本頁核心論點的指令形式：

「挑一件你一直在等待的事……然後就在一個下午把它建立起來。現在內部工具的開發……很快速，大家不必再等待工具。去解決你自己的痛點吧。它很快就會回本。」

這與 問題—解決方案契合度紀律 所記錄的相同經濟效益（「一個下午做出原型」）一樣，只是轉向內部工具；這也是為什麼 Cat Wu 報告 Anthropic 團隊正在為「個人化工作流程」建立「自訂內部應用程式」。

緊密迴圈也能快速抓出錯誤賭注#

頻繁執行迴圈的另一半好處，是你能快速發現自己錯了。團隊交付了進階的像素級控制功能，深受高聲量進階使用者喜愛——接著卻發現「其他所有人都討厭它們」，於是把它們整個移除。總耗時：一週。「如果我們採用季度開發週期……我們就會整整一季都偏離軌道。」Carey 得出的教訓不是「永遠要快」，而是「永遠以足夠短的週期迭代，讓你能快速發現自己何時錯了」——這是 run-experiments 紀律在上線後的應用，也是產品工藝上的結論：工具應該為所有人提高底線，而不只是為進階使用者提高上限（參見 Claude Design）。

相關連結#

• 拋光不再代表已準備就緒 — 產生精緻探索的速度快到足以讓人對看似 production 的原型過度錨定
• Dan Carey — 闡述這套紀律
• Claude Design — 以此方式打造的產品；其許多功能都是迴圈優化的結晶
• 原型優先於 PRD — 對規劃步驟的優化；本頁則將相同直覺應用於其他每一個步驟
• AI 原生產品節奏 — 這個迴圈所在的團隊與流程節奏；Carey 是 Anthropic 的第二個佐證
• Dogfooding 作為產品紀律 — 「與使用者交談，讓它成為最容易的事」和「使用自己的工具」都是 dogfooding；Claude 輔助的對話分析則是它的擴展形式
• 產品速度作為護城河 — 持續優化迴圈的外部回報：從週五到週一交付 62 項改進；速度成為差異化因素
• 問題—解決方案契合度紀律 — 緊密迴圈讓你能在一週內，而不是一季內，發現錯誤賭注（進階使用者控制項）
• 為下一個模型打造 — 持續執行迴圈的另一個原因：下一次模型發布會彌補工程無法彌補的缺口
• 經理也是 IC — 建立自己的工具，預設每個人都能寫程式；扁平且由 IC 主導的組織就是其基礎
• 模型進步下的 Harness 縮減 — 隨著模型原生吸收更多步驟，迴圈的內部工具會縮減／改變
• Agent 品質飛輪 — 將agent 開發中的閱讀回饋／修正步驟產品化：Google 將 eval 等級的分析與修正流程作為可安裝迴圈交付，這是「為什麼還沒建立自己的工具？」的供應商版本

開放問題#

• 這個迴圈假設團隊就是（或幾乎就是）使用者。當使用者與建造者不同，而「與使用者交談」無法在同一個房間進行時，複利優勢還能保留多少？
• 值得投入的內部工具與無止境的琢磨之間，界線在哪裡？Carey 的「一個下午」門檻是啟發式準則，但 Cat Wu 警告，過度客製化設定「會變成干擾」。
• Claude 作為所有回饋的第一輪處理者，是否會過濾掉那些無法聚類的罕見訊號？自動化分流能優化常見情況；令人意外的賭注往往來自尾端案例。

資料來源#

• Designing with Claude: From prompt to production