代碼不再是瓶頸。這句話從 Anthropic 官方嘴里說出來不是愿景是現狀——Claude Code 工程主管 Fiona Fung 在 Code w/ Claude SF 2026 上說得很直白默認每個 commit 都是 Claude 輔助的最近四個月我沒見過一個非輔助提交。你八成也見過同樣的錯位寫代碼突然變便宜了可流程沒變。同樣的評審閘門、交接、策略照樣卡在 agent 生成的代碼上。2026-08-21Anthropic Applied AI 團隊把他們的內部做法整理成《The AI-Native SDLC playbook》公開了講的就是一件事當代碼不再是瓶頸軟件開發流程該怎么重造。這篇我按官方 playbook 拆到底再補一層官方工程組織怎么改的Fiona Fung 那場演講最后落到你從哪開始。傳統 SDLC 是為「寫代碼最貴」設計的先看清楚要改的東西長什么樣。傳統 SDLC 六階段——規劃、設計、構建、測試、部署、維護——每一段都是獨立階段、不同角色所有。產品經理寫需求架構師把需求變設計工程師把設計寫成代碼QA 驗證發布團隊上線運維盯著生產。階段之間靠文檔、ticket、簽認傳遞。這套流程本質是為一個前提設計的最貴最耗時的是寫代碼。PRD、估時儀式、產品安全評審這些東西存在的意義是讓動輒幾周幾個月的開發工作在動手前強制對齊。等代碼本身變便宜了問題就出來了。官方 playbook 給了三個必然結果瓶頸移到 build 左右兩側。plan、review/test、deploy 還在人速build 塌縮到幾小時。控制對不上現實。一行行人工 review 的前提是代碼是某個人寫的一旦 agent 寫出大部分 diff這套東西就跟不上了。治理成本上升。例外照樣要過周會月會的委員會。拿安全舉個例子就懂了。安全團隊是按人速配置的agent 把代碼產出翻倍結果要么 review 隊列積壓要么代碼在沒看夠的情況下上線。受監管的組織兩條路都不能接受。核心轉變線性流 → 循環artifact 鏈即審計鏈AI-native SDLC 不是把傳統流程里每個環節替換成 AI是換了一套組織邏輯。傳統 SDLC 是線性流這個階段結束、蓋章、交給下個階段。AI-native 變成一個環AI 嵌在每個點上階段間靠自動化交接。每個階段結束都往版本控制里提交一個 artifact下一個階段讀它啟動從 Plan 到 Deploy前幾個階段的 artifact 是.md文件——因為產品負責人和 agent 能讀同一個文件、在上面同一個意思上工作。從 Build 開始artifact 變成代碼和它的記錄。提交鏈就是審計鏈誰要了什么、agent 產出了什么、誰批準了什么全在 git 歷史里。人沒有被排除。官方反復強調需要判斷的決策永遠由人負責只是人的注意力跟著要審查的 artifact 走集中在閘門上而不是每個階段從頭再來一遍。Stage 1-2 Plan Design想法一次成型需求與設計壓縮成一個 session傳統流程里一個想法進 backlog過用戶故事、story points、細化會議每次交接所有權轉移一次到工程手里已經離原意好幾層。AI-native 的第一步是讓想法以提出人自己的話記錄下來存成intent.md——一個人類可讀、機器可執行的 proto-spec。做法是提想法的人直接跟 Claude 頭腦風暴描述現狀哪里不行、誰受影響、更好的樣子是什么、哪些不做。Claude 會像分析師那樣追問范圍、用戶、約束、成功標準。然后按組織模板可編碼成 skill寫成intent.md本人糾正 Claude 誤解的部分提交到共享的 intent 目錄。長這樣# Intent: claims status self-service Author: J. Ortiz (claims operations). Status: draft. ## Problem Customers phone the contact center to ask where their claim is. Handlers spend roughly a third of call time on status-only queries. ## Proposed outcome Customers see claim status, next step and expected date in the portal. ## Affected users and systems Claims handlers, portal team, claims-core API. ## Constraints No new PII in the portal session. Existing authentication only. ## Open questions Do third-party loss adjusters need access too?產品負責人批準后進入 DesignClaude 讀intent.md產出需求加設計合一的spec.md。注意這里是同一個 session 完成需求分析和設計——傳統流程里分析師把想法寫成需求、設計師再把需求解讀回設計分離是為了追責但慢且有損。AI-native 讓 policy 在寫 spec 的時候就被應用品牌、安全、合規、UX 標準以 skill 形式存在作為約束參與生成。產品負責人審 spec但不寫 spec。Governance 的要點spec、生成它的 prompt、生效的 skill 版本全進版本控制。產品負責人逐個解決被標記的 concern這些是分析師會升級的問題再決定是否進入 build——高風險事項咨詢技術負責人但進不進入 build永遠由人拍板。接受 spec 的 merge 或 review 就是啟動 build 的觸發。Stage 3 Build沒有驗收的計劃不實現機構知識變成文件Build 這一章信息量最大官方給了一整套配套機制。plan mode 是默認起點。工程師開 Claude Code 就進 plan mode把spec.md交給 Claude讓它先產出實施計劃再動手。傳統做法是工程師讀完設計直接寫碼改動哪些文件、先做哪步、測什么全在工程師腦子里。plan mode 強制把計劃落成plan.md——文件清單、工作順序、風險、證明——提交進版本控制之后的 PR review 拿 diff 跟它比對。對計劃要審訊式提問這個改動可能破壞什么哪步風險最高Claude 選了哪些別的方案但沒做改到「一個沒見過對話的工程師光看計劃就能實現」為止。然后接受計劃讓 Claude 實現——計劃扎實的話往往一次通過。實現偏離計劃時同一個 commit 里更新plan.md甚至用 hook 強制兩者同步。guardrail 成熟后routine 工作可以開auto mode工程師批準計劃Claude 每個改動不再逐次詢問。配套的 CLAUDE.md 收攏上下文、skills 編碼策略、hooks 擋危險動作、測試套件能跑auto-accept 就成了默認。CLAUDE.md 是給 agent 的入職文檔。用/init在倉庫里生成初稿然后砍到一頁——構建/測試/lint 命令、真正要緊的約定、Claude 經常搞錯的事。規則很樸素Claude 同一個錯誤犯兩次就把修正寫進 CLAUDE.md。一頁是因為 Claude 每個 session 開頭全量讀它任何過時的內容都在浪費上下文。Skills 是機構知識。官方給了一條判斷規則必須一致執行的知識寫成 skill屬于 CLAUDE.md 或提示詞的東西別寫成 skill。skill 是一個帶SKILL.md的文件夾frontmatter 寫明什么時候觸發正文寫該做什么。觸發要測換著法子讓 Claude 做相關任務確認 skill 每次都加載。策略變了改 skill 讓 policy owner 簽認工程師下一個 session 自動拿到新版本。Hooks 是 build 期的護欄。skill 是建議性控制——讓違反變罕見hook 是確定性層——讓違反幾乎不可能。build 階段 hook 最多擋掉對生成類、凍結包的修改文件編輯后自動跑格式化與 lint防止憑據進 diff。原則是 build 期 hook 要快、只盯改動的文件重活全套測試放 commit 或 PR。并行 session subagent。一個工程師可以同時開幾個 Claude Code session各自在獨立 worktree 里做獨立任務重復出現的子任務固化成 subagent.claude/agents/*.md定義寫明何時用、能碰哪些工具。官方建議從兩三個 session 起步上限取決于你 review 跟不跟得上。工程師的活從打字變成編排——官方原話最終變成構建和維護 loop。Stage 4 Test讓 agent 自檢把評測變成 CI傳統流程里代碼好不好的信號來得很晚——CI 要幾分鐘、測試人員要幾天、生產要幾周。agent 時代這個信號晚到意味著一個人得查所有輸出這人就成了瓶頸。官方第一條給 Claude 反饋環。一個make test、一次構建、一張截圖 diff讓 session 在給你看之前先自己檢查、自己修。UI 工作給 Claude 瀏覽器或截圖工具實現→截圖→對比→調整兩三輪很正常。還要把「驗證」寫進 done 的定義報告完成前先跑測試把輸出貼出來。寫 bug 修復要先寫失敗的測試。讓 Claude 把 bug 復現成測試、跑、確認它按你預期的原因失敗提交這個測試。然后才讓它改到通過并且不許碰測試文件——用 test-file hook 強制。一個修之前就存在、agent 又改不了的測試就是 bug 已修的證據。反饋環本身也要保護修代碼的 agent 不能削弱檢查它的東西。Continuous evals 是 agent 時代的 stage-gate QA。平臺工程師收集 20-50 個最近的真實任務及驗收結果每個寫成 evalprompt 定義可接受的檢查。套件在 CI 上非交互跑并且在 CLAUDE.md、skills、hooks 變更時也跑——配置在指揮 agent該像代碼一樣被回歸測試。一次生產事故寫成一個 eval進套件當回歸測試由事故所屬團隊寫。這就是「評測取代 PRD」的落法別寫冗長需求文檔輸出評測集。Stage 5 DeployReview 是雙車道治理在 agent 行動時執行Deploy 的核心是兩條AI 進 PR review 環hooks 變成審批閘門。AI 雙向 review。Claude 既按組織策略審進來的 PR也回應自己 PR 上的評論。技術負責人寫REVIEW.md定義審查的 passes——bugs 邏輯錯誤、security 漏洞、compliance對照spec.md/plan.md/設計原則——以及什么算 Important、什么算 Nit、什么跳過。Claude 審完給分級發現但發現本身不批準也不阻擋 PR分支保護仍要求 code owner 審批。review 里 claude 一條評論Claude 回應并推送修復PR 線程記錄請求和變更。發現的錯誤犯第二次就寫進 CLAUDE.md從下一個 PR 起被抓住。人從讀每一行上移一層這個改動是不是計劃要做的、風險接不接受。Hooks 是審批閘門。build 期 hook 允許或阻止動作、不需要人還有一種 hook 會暫停動作等人批準這就是發布閘門。平臺工程師把必須保留的人工審批變更管理簽認、發布授權、編輯受保護路徑逐條表達成 hook腳本在 Claude 行動前運行返回 allow / ask / block。team hook 進.claude/settings.json入庫不可協商的 hook 進托管設置單個人關不掉。block 要能解釋自己攔下的動作、原因、審批路徑都出現在 Claude 輸出里。CI/CD 集成。Claude Code 非交互跑在流水線里干「需要判斷」的活——triage 一次構建失敗、總結 flaky 測試、寫 changelog。執行要沙箱化容器 網絡策略 短時作用域 token默認不持有生產憑據。部署工具通過 MCP 暴露成工具按環境分級開發環境 agent 自由部署生產環境 agent 準備發布、release manager 授權、hook 強制生產閘門staging 居中。rollback 是流水線里最該演練的路徑——單命令、agent 能跑、定期在 staging 演練。一條原則貫穿全部agent 可以走到生產閘門前但過不去。Stage 6 Maintain閉環自己轉起來前面每階段都要人啟動。Maintain 把環關上觸發無需人在調用路徑上agent 診斷完把發現寫成intent.md重新進 Plan。實現是個確定性檢測腳本選一個基線穩定的指標CI 測試失敗率、post-deploy 5xx、PR cycle time滾動窗口算均值和標準差用 Western Electric 之類規則既能抓尖峰也抓慢漂移。腳本本身版本控制、單元測試、完全不涉模型。分級配置在bands.yamlmetric: ci_test_failure_rate baseline: rolling_30d rules: western_electric tiers: 1sigma: { action: log } 2sigma: { action: diagnose, tools: Read,Grep,Bash(gh run view *) } 3sigma: { action: propose, routes: [pull_request, runbook:rollback-deploy] }1σ 只記日志2σ 只讀診斷3σ 可以行動——但只限于開 PR 進 review gate 或觸發預先批準的 runbook。agent 無頭、無狀態地跑CI runner 上非交互 step或沙箱容器里的 Agent SDK 服務環能開始也能結束不需要任何人啟動。agent 診斷寫成 Plan 格式的intent.md異常是什么、證據、提議的產出、受影響系統、開放問題。on-call 工程師 triage修、排期、忽略——忽略在調 band 降噪。修復上線時為這個事故加一條 eval。同一章還有兩塊Claude Security定期跑代碼庫掃描調度而非事件findings 逐個驗證并帶置信度單個 PR 放得下的走 review gate、更大的寫成 intent.md和Claude Tag讓 Claude 進 Slack 頻道當 incident 第一響應人指標回基線了在 thread 里確認、post-mortem 寫進版本化 lessons 文件channel 就是審計鏈。組織實踐驗證、審查、安全成了新瓶頸Fiona Fung 那場演講補齊了機制之外的視角寫代碼、寫測試、重構很少再拖慢團隊了但驗證、code review、安全取而代之。她講了四個被重寫的規范。Planningroadmap 改成 just-in-time。六個月的路線圖三個月就過時干脆不預設那么多。規劃儀式從設計文檔挪到 PR 里的討論和原型里先原型、放一批內部用戶用、按反饋迭代。Context gathering先問 Claude再問作者。以前查代碼問題先找寫代碼的人?，F在 PR 都是 Claude 輔助的「誰改的」這個問題不夠用了。你想知道的是更深的層誰導致回歸誰懂這個客戶問題這個決策的上下文是什么把這些問 Claude它經常能直接答還帶著更多數據和上下文。然后習慣性多問一句這事能自動化嗎Code reviewtrust but verify。Claude 包掉 style、lint、PR 反饋請求、提交前抓 bug 和補測試。人留在真正需要 expertise 的地方法務審核、信任邊界和安全敏感代碼、產品 sense 和 taste。而且這個平衡要持續評估——下一個模型出來你需要人做的東西可能又不一樣。Team makeup角色在模糊。PM 在寫代碼工程師開始接手內容與設計。她招人重點放在兩類有產品 sense 的 creative builder和有深系統功底的工程師。原話是「raw throughput 不是我要的模型處理那個。」三個指標她建議每個工程負責人現在就開始盯onboarding ramp time 降、PR cycle time 降、Claude-assisted commits 升。最后那條注意別誤解——吞吐不是成功能解決問題的吞吐才是。其實之前的系列我也寫過這套東西我不陌生。我此前寫過一組《復雜軟件系統的 Vibe Coding 實踐》系列——第一篇《從需求到規格》就是 superpowers 實操跟官方 Stage 1-2 的 brainstorming→spec 是同一條路第二篇《拆計劃與 TDD 實現》對應 Stage 3-4 的 plan 化 先寫失敗測試第三篇《工具配置與迭代收尾》講的就是把流程固化成 CLAUDE.md、skill、hook跟 Stage 3 的機構知識文件化一個意思。差別在粒度。官方 playbook 是組織級機制與治理誰簽認、哪些審批閘門必須保留、配置怎么托管、度量怎么算。我的實操系列是一個人或小團隊能照走的路徑命令、skill、hook 怎么落地。社區把它進一步固化成流水線——claude-sdlc 用 15 個角色 skill 覆蓋每個 SDLC 階段kickoff 到 production monitoringuctm 用五個專職 agentorchestrator/specifier/planner/builder/verifier跑 spec-driven 開發加獨立驗證sdlc-framework 用 worktree 并發和模型分級。方向一致都在復刻官方這套「artifact 鏈 人在閘門」。你從哪開始官方給了一個極樸素的起點Fiona 也說了同一句挑你團隊最吵鬧的那個 workflow——最貴的、最讓你頭疼的、大家最不想參加的。問它還在不在服務它的目的。如果不在問能不能自動化。我按這套邏輯給你一條漸進路線別一口氣全上先 artifact 化。選一個項目把想法、規格、計劃落成 intent.md / spec.md / plan.md 進 git。這一步不碰任何 agent 配置先讓「提交鏈即審計鏈」成立。再開 plan mode。讓工程師的 Claude Code 默認從 plan 開始計劃落盤實現不偏離。加 feedback loop。給 Claude 自檢手段報告完成前跑測試貼輸出。這是性價比最高的一步。再上 review 雙車道。REVIEW.md 三 pass claude 修評論人上移一層。最后才碰自動化閘門。hooks、CI/CD 集成、evals——這些是前面的機制跑順之后加速用的不是起點。單人開發者可以直接從第 1、2 步開始連團隊都沒有artifact 鏈本身就是你的記憶和回看依據。結論這篇文章真正想說的不是「AI 能寫代碼」。那是 2025 年的話題了。Anthropic 官方這份 playbook 說的是更硬的東西代碼不再是瓶頸之后你的流程必須按新成本結構重造重造的錨點是提交的 artifact重造的目的是把人的判斷留在它該在的閘門上。環形流程轉起來之后人的位置很明確——在環的上方。用官方一句話收尾The loop keeps running. Human judgement stays above it.如果你也在重寫團隊的流程現在卡在哪一環最痛plan、review 還是 deploy評論區報個階段名我下一期就按它展開。覺得這份官方作業值得抄的點贊收藏不迷路這個系列我會繼續拆 agent 時代的工程方法論。