Anthropic 最近採訪了 15 家正在大規模使用 Agentic Coding 的科技公司，其中包括 ClickHouse、Harvey、Cognition、Clay 等明星公司。Cognition、ClickHouse 和 Harvey 的估值都已超過 100 億美元，也是目前採用 AI 程式設計最積極的一批公司。
基於這些訪談，Anthropic 整理出了一份實操指南。所謂 Agentic Coding，就是讓 Agent 深度參與程式碼開發。指南雖然以 Claude Code 為主，其中提到的技能、計畫模式和 worktree 也都是 Claude Code 的功能，但背後的工作方法同樣適用於其他 Agentic Coding 工具。
https://claude.com/blog/claude-code-guide-for-startups
這篇文章按教學結構重新組織：五條規則是什麼，為什麼順序不能打亂，每條怎麼做，以及那裡容易踩坑。
一、當程式碼不再稀缺，舊研發流程還成立嗎？
傳統公司的研發流程是為稀缺設計的。程式碼評審、需求排期、架構規劃、分階段放量，這些機制的存在前提是工程師時間稀缺。評審要排隊，排期要協商，規劃要謹慎，因為每個環節消耗的都是稀缺資源，浪費不起。
程式碼生產的邊際成本掉下來之後，這些機制的前提就不成立了。ClickHouse 報告功能交付量提升了 30%，Artemis Security 一周合併 6000 多個 PR，Clay 把缺陷分診（bug triage，指對 bug 分類、定優先順序、分派處理）全部交給了 agent。
這些數字看著像用了 AI 所以更快。真正的變化是成本結構。做資料庫的 ClickHouse 敢讓 agent 成為主力貢獻者，是因為測試覆蓋率是它的稀缺項，而 agent 修測試的邊際成本已經低於人修。
稀缺項變了，流程就得跟著重設計，下面五條規則是流程重設計之後產生的。
五條規則分別是：人人皆可交付、自動化繁瑣工作、信任但驗證、為重構而建構、原型自用產品化。
二、先釋放生產力：讓更多人交付，讓 Agent 接管重複勞動
1、讓最懂問題的人直接做出第一版
降低交付門檻，讓真正理解問題的人直接產出第一版。
做醫療 AI 的 Heidi 描述了一個"傳話遊戲"問題。一個新想法過去要走一條鏈：提出想法的人告訴產品經理，產品經理告訴設計師，設計師再告訴工程師。到上線的時候往往已經不是當初那個東西了，而且要花幾周。
agentic coding 工具去掉了這條鏈上的中間環節。真正理解問題的人可以直接提 PR，只在需要專業能力的地方把設計師和工程師拉進來。
做 AI 律所的 Crosby 把 agent 接到了律師日常在用的工具上。負責人的說法是，律師有最好的產品洞察，因為他們就是使用者。
分工並沒有消失。市場部還是做市場，開發還是做開發。發生變化的是從 0 到 1 這一步，也就是把想法變成可運行原型的環節，對所有人開放了。
要把這件事做成機制，靠三個配套動作。
接上工具和資料來源。agent 看不到的東西就無法理解。給它接上團隊日常在用的系統，讓它和工程師在同一份事實基礎上工作。有成熟命令列工具的場合，直接走命令列接入往往更省 token。
給創意開一條進入排期的通道。產品經理的創意天然能進正式排期，其他人的不能。做銷售自動化平台的 Clay 每季度做一次原型評審，原型式創意可以由此進入正式路線圖。做商業智能的 Omni 則開了一個專門放 agent 生成原型的 Slack 頻道，貢獻者包括資深技術人員。
把團隊標準沉澱成共享的技能庫。原型式的東西多了之後，拼起來容易變成一堆互不相關的碎片。技能（skill）是可復用的指令檔案，把設計規範、公司上下文、常見工作流程寫進去，agent 每次接任務時讀取。新人第一天就能用上，產出的東西也能保持一致。做應用建構平台的 Emergent 的做法是接受上下文檔案略微過期，只要 agent 能自己驗證和糾正。
2、把重複勞動交給 Agent
讓 agent 接管生命周期裡機械的那部分，工程師把時間留給真正需要判斷的部分。
做資料庫的 ClickHouse 把幾乎每個研發階段都做成了自動循環。兩個專門修不穩定的測試（flaky test，指有時通過有時失敗的測試）和補測試覆蓋率的 agent，現在是倉庫的第 2 和第 3 大貢獻者。
做醫療資訊化的 Commure 展示了平行的規模。一個工程師發起約 13 個工單，每個工單派一個 subagent 平行處理，每個 subagent 擁有自己的工單和 PR。subagent 是從主 agent 派生出來的子 agent。這種平行度在傳統流程裡不可能出現，因為它要求有人同時盯 13 條線。
多個 agent 一起幹活，需要編排模式。原文給了六種可復用的工作流模式，包括分類執行、扇出綜合、對抗驗證、生成過濾、錦標賽、循環直到完成。
分類執行適合任務類型已知、處理路徑不同的場合。扇出綜合適合需要多角度覆蓋的場合。對抗驗證讓多個審查者互相挑錯，適合程式碼審查這類容易自我確認偏差的場合。生成過濾是先生成一批候選，再用過濾器篩掉不合格的。錦標賽讓候選兩兩比較，逐輪淘汰。循環直到完成則適合停止條件明確的場合，agent 反覆迭代直到達標。
三、程式碼越容易生成，驗證就越昂貴
產能提上去之後，問題換了個位置。寫程式碼不再是瓶頸，驗證變成了瓶頸。
驗證環節以前是附屬的。產能上去之後，它變成了主要瓶頸。寫程式碼的成本掉了，驗證的成本沒掉。Artemis Security 一周合併 6000 多個 PR，人工評審的吞吐不會跟著產能一起漲。產能越往上提，驗證越跟不上。
沒有驗證能力，產能提升只會讓問題積累得更快。
1、驗證不是抽查，而是一套閉環
做醫療編碼的 Cainex 是一個極端的場景。它用 agent 讀病歷並生成計費編碼，聯合創始人兼 CTO 先說了一個約束條件："醫療編碼裡，一個錯誤的編碼不是筆誤，是計費和合規事件。這一條事實決定了我們怎麼建構。"
這個約束決定了他們不能接受"agent 生成，人抽查"。他們建了一條完整的檢查流程。
第一步，agent 批次處理，審計員審查輸出。審查的對象不只是編碼結果，還有模型的推理過程，審計員對兩者都批註。所有內容版本化、可審計。
第二步，agent 讀回原始預測和所有批註，找出是那一段指令出的錯。每條批註都按編碼類型打了標籤，agent 據此判斷自己在看的是診斷問題、手術問題還是其他類別，直接跳到對應那一類的指引。
第三步，改指令本身，不改具體案例。他的表述是"修復原則，不修復案例"。每次改動都在版本化的指令集上進行，並且在之前出錯的記錄上做測試。
第四步，回測。醫療記錄可能存在多個可接受編碼，所以不能做字串匹配。檢查結合語義匹配和一個判定器，判定器是專門用來判斷對錯的模型，它要回答的問題是"這是一個真錯誤，還是一條不同的合法路徑"。改動要在一組驗證過的問題答案對（golden set）加上隨機樣本上跑一遍，把回歸情況報告出來才允許上線。
返回給工程師的是一份短清單：建議的修改、無法判定的記錄、需要回答的問題。
這條流程是一個循環：agent 處理一批任務，評估模型檢查結果是否達標，達標就結束，不達標就打回去重做。停止條件要寫得足夠明確，agent 才能自己判斷什麼時候該停。
修不穩定的測試是最適合做成循環的場景，因為停止條件清晰且自包含：agent 改完程式碼，重跑測試，通過了就停。
2、Cainex 踩過的坑：補案例不等於修規則
Cainex 的聯合創始人兼 CTO 交代了第一版是怎麼失敗的：
"一開始沒這麼幹淨。我們的第一版過擬合了。它靠編碼具體案例來'修復'問題，結果只是在攢補丁，沒有變得更聰明。我們改了方法，強制它走通用原則，並且限制一次改動裡能進入多少具體細節。"
過擬合，指只記住了見過的具體案例，換個新案例就不會了。
這套流程最重要的是它背後的那條規則：改原則，不改案例。
這段話說明這條流程不是一次設計出來的，是從一個失敗版本改過來的。失敗的原因是審計員的批註被直接寫成了規則，規則越來越多，系統沒有獲得任何泛化能力。改法是強制走通用原則，並且給單次改動的具體細節設上限。
這條規則落到執行上：不要讓人工反饋直接變成規則。反饋要經過抽象這一步，變成原則，才能進指令集。
3、給 Agent 劃出不能越過的邊界
做醫療資訊化的 Zingage 早期給 agent 完全自主權，"它做了 AI 會做的事，快速產出了看起來能跑的程式碼。問題是它在一些看起來正確、實際不符合架構的地方偏離了原設計"。
他們的應對是把所有不變數寫下來。不變數就是必須始終成立的條件，包括怎麼框定問題、什麼必須成立、怎麼證明一件事有效。這些全部寫下來是 567 行，Victor 把它稱作"這個團隊如何思考"。
不變數要寫在 agent 每次會話都會讀的檔案裡，架構規則、安全邊界、不可妥協的條款跟著每一次會話走。寫不下來的部分，等於沒有約束。
四、能驗證，才有資格推倒重來
驗證能力建起來之後，一件以前不敢做的事變得可行了。
第四條規則：為重構而建構。模型能力在持續變化，幾乎沒有什麼是永久的。
做銷售自動化平台的 Clay 的說法是："你在 Clay 做的事是，建一次，再建一次，再建一次。第四次你建的時候，你就知道需要什麼了，你能做對。"
做醫療資訊化的 Commure 補充了一條判斷：重建完成不是新路徑上線的時候，是新路徑上線且舊路徑消失的時候。他舉了個例子。feature flag 是功能開關，用來控制某個功能是否對使用者開放。以前拆除舊程式碼這件事永遠在優先順序排序裡輸掉，因為它繁瑣而且不交付功能。現在一個工程師只要呼叫一個技能，說"給每個已經全量發佈的功能開關開一個 PR，把開關和關聯程式碼一起刪掉"，然後審查返回的結果。以前要吃掉大量開發周期的遷移，現在是一個計畫加一次平行分發，幾個小時做完。
做法律 AI 的 Harvey，其應用研究負責人說："如果你六個月前來問我我們的架構長什麼樣，我會給出一個和今天完全不同的答案。"
這幾句說的是同一件事：重建的難度一直沒變，變的是重建的風險。以前沒有評估測試（evals，用來量化改動的影響），重建完不知道是變好了還是變壞了，那就只能不重建。
驗證能力補上之後，重建這筆帳就變了。保留舊架構以前是為了降低風險，現在只會積累惰性。重建的邊際成本已經低於保留成本。
1、把重建變成一次可控實驗
用 worktree 在倉庫的獨立副本裡做重建，當前版本不受影響。
worktree 是倉庫的獨立副本，可以和主版本平行存在。v2 和 v1 平行跑，評估測試對比，新的贏了才合併。這就是"建四次"變便宜的原因。
複雜一點的重寫，在動手之前進計畫模式，讓 agent 先探索程式碼庫、提出重建方案，人批准或糾正。計畫模式是 Claude Code 裡的一種模式，agent 唯讀程式碼、給方案，不動檔案。這是最便宜的把關點。
一次重構完成的標準定為舊路徑消失，避免新舊兩套長期共存。
五、寫在最後：一份可以照著做的清單
第五條規則是原型自用產品化。先用 agentic coding 工具搭內部用的 agent，內部自用，驗證通過再推給客戶。
這一條可以看作是前面四條都成立之後的自然結果。內部 agent 自用，等於在自己的真實場景裡跑驗證。驗證通過再推給客戶，等於重建的風險已經在小範圍裡消化過了。
如果要挑三件事先做。
把不可變的東西寫下來。架構規則、安全邊界、團隊的工作方式，寫成 agent 每次會話都會讀的檔案。
給關鍵場景建驗證集。每次改動都拿它回測，防止回歸分不出來。
算一下重建成本。如果一次重構要花掉一個開發周期，那說明驗證能力還沒跟上。 (Datawhale)