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