前阵子帮一个做 SaaS 的团队做技术咨询他们年初就接入了 Claude Code结果三个月过去研发效能不升反降——百分之四十的 PR 会被 reviewer 打回重做。问题不是模型不够强而是他们还在用二十年前的流程组织一个全新的生产力工具。这个场景我想很多人并不陌生。最近社区里讨论最多的 AI 原生 SDLCAnthropic 那本六阶段重构手册恰好就是在回答这个事。它不叫方法论叫“重构手册”核心主张不是“给传统流程加 AI”而是“按 AI 的能力重新设计流程”。整本手册里有两个东西让我觉得最值得落地一个是作为项目唯一事实源的 intent.md另一个是把评测贯穿始终的持续评测机制。这篇文章把我实际拆解和应用的经验完整写出来包括六个阶段怎么走、intent.md 怎么从零写起、持续评测怎么接入 CI以及我在落地过程中踩过的三次真实报错和意图漂移问题。如果你正准备在团队里推 AI 原生开发这篇应该能帮你省掉几周自己摸索的时间。1. 从“给流程加 AI”到“按 AI 重写流程”Anthropic 六阶段手册到底想改变什么1.1 为什么“AI 辅助”路线会卡住先说个反直觉的结论把最强模型塞进传统 SDLC效果往往是负的。我给那个 SaaS 团队做诊断的时候发现他们的典型工作流是产品经理写 PRD技术经理拆分任务工程师领任务后打开 Claude Code 写代码写完提 PRreviewer 看不懂 AI 生成的 diff打回重改改完再提。整个链路里每个环节都“有 AI”但没有任何一个环节是“为 AI 设计的”。结果就是 AI 每十分钟产出一个 PR人类每两小时才能 review 完一个。瓶颈从“写代码”转移到了“审代码”效能反而更差了。这就像把 F1 引擎装进马车车厢——引擎是快的但车架、悬挂、驾驶员的操作方式全都跟不上。1.2 六阶段到底长什么样从 Plan 到 MaintainAnthropic 那本手册给出的方案是把整个软件交付流程重构成六个阶段Plan规划、Design设计、Develop开发、Test测试、Deploy部署、Maintain维护。我把它理解成一个螺旋结构而不是传统的瀑布。六个阶段的职责分配我用自己的话整理成了一张表阶段AI 承担的核心职责人的核心交付物Plan从模糊需求中生成候选方案、用户故事、验收标准确认优先级给出意图描述Design生成架构草案、评估取舍、找出潜在风险拍板做哪些取舍、哪些不做Develop按意图实现功能、写单测、跑自测有意义的 code review判断范围是否合适Test执行回归测试、边界测试、修复失败的用例定义评测集决定哪些问题值得修Deploy生成发布说明、观察灰度指标、提出回滚建议做发布决策和回滚决策Maintain分析线上行为、定位根因、生成改进建议更新 intent定义新的评测基线这个表的要点在于每个阶段都是“人定意图、AI 执行、人做裁决”而不是“人下命令、AI 照做”。区别很微妙但很关键。1.3 为什么这套框架对中小团队反而更现实聊到这里有人会问这套流程听着很好但那是为大公司设计的吧我的看法正相反。六阶段重构对中小团队反而更友好原因有三个。第一中小团队没有庞大的历史流程包袱。传统大厂在 SDLC 里沉淀了几十年的规范、审批流、合规检查每一项都难改而中小团队的流程几乎是一张白纸重构成本极低。第二中小团队的核心瓶颈恰恰是“人太少、事太多”这正适合把执行类工作交给 AI。第三中小团队的决策链路短intent 的决策和更新不需要跨部门协调一个十个人的小组完全跑得起来。我自己实践下来这套东西对 5 到 50 人的技术团队是最舒服的甜点区。人数再少光维护评测集就有点吃力人数再多组织协调的复杂度会反过来盖过收益。2. intent.md 才是整个仓库的“宪法”写什么、怎么写、谁有权改2.1 intent.md 与 PRD、CLAUDE.md 的分工聊六阶段之前我先把这次拆解里最核心的产物说清楚intent.md。很多人第一次看到 intent.md 会问这不就是 PRD 吗还真不是。我把三者的分工用一句话总结PRD 是写给产品看的“我们要做什么”、CLAUDE.md 是写给 AI 看的“你要遵守什么操作规范”、intent.md 是写给整个仓库看的“我们为什么要存在以及如何判断做得好”。实际效果上PRD 往往几千字写完就没人再看了CLAUDE.md 太侧重操作细节管不住“方向”而 intent.md 的作用是让任何人都能在一个文件里看到项目的“为什么”和“验收标准”同时也让 AI 在每一次生成代码、跑测试、提 PR 的时候都有同一个参照系。2.2 一个能直接复制的 intent.md 骨架我结合自己的实践给一个可以直接抄的骨架模板。这份模板的核心原则是短、明确、可验证。不要写形容词要写数据。# Project Intent: 内部工单系统示例 ## Why为什么做 这个系统是为了把一线运维的重复人工操作从每周 15 小时降到 5 小时以内。 它不是“一个工单工具”而是“把人工操作自动化的平台”。 ## What真实目标不等同于功能清单 - 用户可以用自然语言创建工单系统自动识别优先级 - 工单状态变化全程可追溯任何操作留审计日志 - 每类工单的平均处理时长在接入手动流程后有可量化的下降 ## Non-goals明确不做什么 - v1 不做审批流审批逻辑留在线下 - v1 不做移动端适配 - 不做 AI 自动处理工单内容只做自动分拣和流转 ## Constraints约束条件 - 技术栈Node.js 22 React 18 PostgreSQL 15 - 部署单机 Docker Composev1 不上 K8s - 团队规模2 名后端、1 名前端、1 名产品兼职 ## Quality Bar可验证的验收标准 - 工单创建接口 P95 延迟不超过 1 秒 - 审计日志覆盖率达到 100%不允许出现无记录的变更 - 内置评测集 eval/ 中所有 case 通过率 100%后续 AI 改动不得引入 API 行为回归注意看这个模板里我没有写“要做一个友好的界面”“要保证系统稳定”这类废话。所有可验证项都是可检测的。这就是 intent.md 的生命力所在它天生是一份可以被机器执行的测试契约。2.3 迭代纪律什么时候改、谁来改intent.md 最容易被忽视的问题是改动权限。我见过一个团队把 intent.md 放进了仓库里然后 Claude 每次跑任务的时候都会“自作主张”往里面补充内容。两周之后那个文件从一百行膨胀到了两千行核心的 Why 反而淹没在各种细节里没人再看了。我后来定的纪律是intent.md 的修改必须走人工 review并且我建议把这条规则写进 CI 的 CODEOWNERS 里任何不经 review 的改动直接阻塞合并。AI包括 Claude只有建议权没有直接修改权。它在任务中发现 intent 需要更新应该提一个修改建议由人来落地。每周做一次 intent review只问三个问题这周我们有没有偏离 Why评测集里有没有过期用例下周最可能出错的是哪一段这条纪律刚定的时候团队觉得“多此一举”跑了三周之后所有人都真香了——因为再也没有人需要在一堆变形的措辞里去猜“项目到底要什么”。3. 六阶段逐段落地从 Planning 到 Maintenance 的 AI 工作流走法3.1 Planning 与 Design把模糊目标变成可评测的意图Planning 阶段最容易犯的错误是让 AI 直接生成需求文档。错了。AI 在 Planning 阶段最擅长的是“出选择题”而不是“写作文”。实际操作我一般这样走把一个模糊的业务目标丢给 Claude让它产出三样东西——候选用户故事列表、每类用户的验收标准、明确不做的清单。然后人要做的是划掉不合理的项调整优先级把这个结果固化进 intent.md 的 What 和 Non-goals。例如前一段时间我们做一个“报表导出”功能业务方的原话是“能不能把后台数据导出来方便运营看”。我把这句话丢到 Claude它生成了 12 个候选用户故事其中包括“支持按渠道维度筛选后导出”“导出任务失败时自动通知创建人”等等。其中“自动通知创建人”这个点业务方聊需求时完全没想到但实际是导出失败后支持人员最痛的场景。这就是 AI 在 Plan 阶段的价值——不是替你拍板而是帮你把没想到的选择项摆到桌面上。Design 阶段同理。我现在的做法是让 Claude 给出两三个技术方案每个方案附带“选它的理由”和“不选它的理由”最后人只需要做决策。决策的本质是取舍而取舍的依据在 intent.md 里已经写清楚了——约束条件和 Non-goals 就是天然的裁量标准。举个例子constraints 里写了 v1 不上 K8s那任何需要 K8s 才能跑顺的设计方案直接砍掉不需要讨论。3.2 Develop 与 TestAgent 写代码、人写评测到了 Develop 阶段我的体会是这个阶段反而是六个阶段里最短的也是最不该花太多精力的。因为 AI 写代码的速度非常快真正的瓶颈在 Test。我这里想纠正一个常见误区让 AI 写测试不是“偷懒”而是“把人的精力留给判断”。传统开发里人写完功能还要写测试测试是为了证明功能正确但在 AI 原生开发里人是通过“定义什么算坏”来间接控制 AI 的——这就是评测集的意义我会在下一章详细展开。举一个真实的例子。我们在做一个 PDF 解析服务时Claude 在 Develop 阶段生成了一版核心解析代码附带 15 个单元测试。这些测试在它自己看来全绿但合并后第一周就收到了两起客户反馈断行文本被错误合并、加密 PDF 没有提示用户。原因就是它生成的测试用例过于“理想化”全用的是标准输入没有覆盖真实世界的脏数据。后来我们在 Test 阶段做了一件事把评测集里加进了“脏数据专项”用例包括不规则空格、表格混排、扫描件缺页、密码保护文件。从那次之后AI 生成的代码再也没在这几个问题上翻过车。这个教训我复述一遍AI 生成测试的盲区要用人类定义评测集来补齐。你不可能让 AI 替你想清楚所有“坏”的样子但你可以把已知的“坏”全部喂到评测里。3.3 Deploy 与 MaintenanceAI 不是只管到合并很多人以为 AI 原生开发到 PR 合并就结束了其实手册里 Deploy 和 Maintain 阶段才是拉开差距的地方。Deploy 阶段我现在的流程是代码合并进 main 之后CI 自动出发一个部署任务Claude 会基于 git log 和评估报告自动生成一份发布说明内容包括本次变更的行为影响、需要关注的指标、以及它建议的灰度比例。然后人做发布决策。这个流程听起来轻巧但有一个前提——你必须在 CI 里把“变更影响”这个信号做出来否则 Claude 写出来的发布说明就是套话。Maintain 阶段更值得重视。传统团队线上出问题了第一反应是查日志、找代码、定位根因AI 原生团队的 Maintain 阶段是把线上数据拉回评测集里让 AI 分析“这是评测集的盲区还是代码真的改坏了”。举个实例我们有个服务的错误率从 0.1% 涨到 0.4%人肉排查一小时没结果我把最近的监控数据和相关代码 diff 丢给 Claude Case 分析它在三分钟内指出是某个异常类型在上游 API 增加字段后没有被正确兼容并给出修复建议和两条需要补进评测集的回归用例。那次之后我对 Maintain 阶段的定位就从“救火”变成了“扩军”——每次线上问题的产出不只是修复代码还有一个新的评测用例。4. 持续评测不是跑一遍测试那么简单评测集、分数门禁与指标陷阱4.1 评测集的三层构成回归、意图对齐、红队持续评测是 AI 原生 SDLC 里和 intent.md 并列的另一根支柱。如果说 intent.md 定义了“方向”评测集就是定义“什么叫没跑偏”。我实践的评测集分为三层层级内容来源示例更新频率回归用例历史 bug 修复、线上事故PDF 加密文件必须返回明确的错误提示每次事故修复后意图对齐用例从 intent.md 的 What / Quality Bar 抽取工单创建 P95 延迟 1sintent 更新时同步红队用例边界输入、异常输入超大 payload、空值、竞态并发每两周补充一次以我的经验一个小型项目的评测集可以从 20 到 50 条起步之后不要盲目追求数量而应该每一条都问自己“如果这条用例挂了用户真的会感知到吗”如果答案是不会这条用例就该删掉或重写。4.2 把评测结果做成合并门禁评测集建好之后最关键的落地动作是把它接进 CI。我给一个 GitHub Actions 的示例这个配置是我实际在用的逻辑非常简单每次 PR 触发评测任务分数必须超过基线分数才允许合并。name: evals on: pull_request: branches: [ main ] jobs: eval: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 22 - run: npm ci - run: npm test - run: npm run eval env: ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}注意那个npm run eval它背后跑的逻辑是读取当前分支的代码执行评测集把结果和基线分数对比。这里有一个实测中很重要的细节——阈值要设成“允许小波动禁止大倒退”比如基线是 90 分可以容忍 88 到 90 之间的小波动可能只是并发抖动但低于 85 分就必须阻塞合并。因为评测集本身也会有噪声阈值设得太死CI 会天天报红最后大家就不看 CI 了。4.3 那些看起来很漂亮、实际会骗人的指标这部分是我最想提醒的因为评测落地时最容易掉进指标陷阱里。第一个陷阱是passk 套用到长任务上会失真。passk 衡量的是“生成多个候选其中有没有一个能通过测试”这在短小的代码补全场景下有效但 AI 原生 SDLC 里任务是端到端的——让 AI 修改一个服务、补测试、改文档你不可能让同一个任务跑五次看哪次成功。所以不要照搬论文里的评估指标而是要定义“任务完成度”评分我一般用功能行为是否达成、是否有回归、以及代码规范三个维度打分。第二个陷阱是让模型给模型打分。如果你的评测逻辑是“把输出丢回给 Claude 问它写得好不好”那你得到的分数的可信度是很低的——模型对自身输出的偏好偏差大得惊人。我踩过这个坑一开始图省事用 Claude 自评结果所有输出全是 95 分以上完全失去了区分度。后来改成独立编写 checker每个检查项是硬性的规则判断比如断言某个错误信息是否出现、某个接口是否返回预期状态码才真正可用。如果要用模型做评估至少要让另一个 Prompt 完全独立的模型当评委且给它提供明确的行为契约。第三个陷阱是用 token 消耗量或覆盖率当质量指标。token 消耗衡量的是成本不是效果代码覆盖率衡量的是“哪些行被跑过”不是“这些行为是否符合预期”。这两个指标可以作为参考但永远不要作为合并门禁。我见过团队为了把覆盖率从 70% 刷到 90%生成了大量毫无断言的桩测试质量反而下降了。5. 落地过程中的真实报错和长上下文失控三次踩坑记录5.1 unable to connect to anthropic services从网络到密钥的排查顺序第一次把我们整个 AI 原生流程卡死的是 CI 里突然大面积报unable to connect to anthropic services failed to connect to api.anthropic.com。当时第一反应是 API 挂了但实际排查下来发现根因根本不是这么回事。我把排查顺序固化成一套 checklist现在再遇到这个报错两步之内就能定位先看网络链路的出口。很多公司 CI Runner 在隔离网络环境里出公网要走企业的 HTTPS 代理。这时候需要检查环境变量里HTTPS_PROXY是否配置正确、NO_PROXY是否错误地把 API 域名也拦进去了。再看 API Key 本身是否有效可以用一个最简单的 curl 测试通不通。注意如果公司用的统一 LLM 网关比如 LiteLLM、Kong那要检查的就不是 Anthropic 原站 key而是网关的认证配置。这类问题之前我们还遇到过一次非常隐蔽的坑CI 里的环境变量被某个依赖装成了无效的空字符串导致运行时读取到的不是 key 而是空白所有请求全部 401日志里看到的提示却是“connection error”。所以我的建议是检查的顺序永远是“链路通畅性优先密钥有效性次之”因为密钥问题通常有更明确的 401/403 状态码而断连问题往往是黑的没有状态码可看。5.2 expected a gateway model route模型名与路由配置的错位第二个报错doesn’t look like an anthropic model: expected a gateway model route是我们接入企业统一网关时遇到的。这类错误文字看起来很深奥实际原因非常简单代码里请求的模型名和网关路由表里注册的模型名对不上。我们的架构是CI 里的请求统一走 LiteLLM 网关然后由网关转发到 Anthropic API。配置文件里注册的模型名和代码里引用的模型名差了一位版本号比如代码里写的是claude-sonnet-4但网关里注册的是claude-sonnet-4-20250514这个带日期的完整版本名网关匹配不到路由就报出了这个提示。修复方法也很简单在网关配置里同时注册“别名”和“具体版本”两个模型名业务代码里统一用不带日期的别名这样后续模型更新时不用改业务代码。# LiteLLM 网关配置示例 model_list: - model_name: claude-sonnet-4 litellm_params: model: anthropic/claude-sonnet-4-20250514 api_key: os.environ/ANTHROPIC_API_KEY这个错误给我们的教训是AI 原生工作流里模型名是基础设施的一部分它应该像数据库连接串一样被集中管理而不是散落在各个脚本里。只要把“业务侧用别名、网关侧管版本”这个原则定下来这类报错基本不会再出现。5.3 意图漂移AI 把 intent.md 越改越厚第三个坑其实比任何 API 报错都更隐蔽——意向漂移。前面提到过intent.md 如果不设权限AI 会每次迭代都往里加内容。我经历的真实情况是一个内部数据分析平台的 intent.md第六周的时候达到了历史峰值 1800 行其中至少有 60% 的内容来自 AI 自己在完成任务时“合理化”的补充。比如它加了一段“本项目的未来方向是AI自动生成报表”这件事我们团队压根没讨论过但它似乎很有道理。这个问题的根因是AI 的上下文窗口有限一旦 intent.md 本身太长它就会“挑重点”读取而那些被跳过的部分恰恰可能是之前的核心约束。结果就是项目方向在人没有参与的情况下悄然改变——这就是意图漂移。我的解法分三层第一层是结构隔离。intent.md 只保留最核心的 Why、What、Non-goals、Constraints、Quality Bar 五块内容其他所有细节技术方案、会议记录、架构决策记录全部拆到 docs/ 目录下单独维护intent.md 里只留一行链接。第二层是顶层锁定。在文件头部放一个“不可变更的核心意图”段落并在 CODEOWNERS 里设置为只有 Tech Lead 和产品负责人可以修改。AI 可以建议变更但任何自动变更都会被 CI 直接拦截。第三层是本地对照。每次在 Develop 阶段开始前要求 Claude 先将当前 intent.md 的核心内容读一遍并在输出里复述“本项目 v1 不做 X、核心约束是 Y”这样可以强制上下文不漂移。实测这招非常有效它相当于给 AI 一个“锚点”阻止它从上下文深处掏出过期记忆。6. 团队与角色AI 原生模式下工程师到底在做什么6.1 从“写代码的人”到“定义意图的人”最后聊一个绕不开的话题——这个流程落地之后工程师的角色到底变成了什么我的直接观察是最值钱的技能从“写代码快”变成了“定义意图准”。传统开发里工程师的核心产出是代码AI 原生开发里工程核心产出是“告诉 AI 你要什么、定义什么叫做好、审查 AI 是否做对了”。代码本身反而成了中间产物。这带来了很多连带变化。QA 工程师变成了“评测工程师”主要工作是设计评测集和分析失败用例架构师变成了“约束工程师”职责是写出能落进 intent.md 和 CLAUDE.md 的约束条件普通开发者的核心技能变成了批判性阅读 diff——不是“这个代码风格符合规范吗”而是“这段代码的实现是否忠于 Why”。我记得有一次开发组里一个新同学花了一整天训练 Claude Code 去写一个十分复杂的 SQL 存储过程调了很多轮终于跑通了但最后我们发现整个存储过程实现的东西在 intent.md 的 Non-goals 里明确写着“v1 不做”。那一刻团队才真正明白AI 把没人做的事做得再好也抵消不了它做了“不该做的事”带来的返工成本。之后我们的 Development 流程强制加入一步任何新功能开工前先在 intent.md 里确认它不在 Non-goals 列表里。6.2 试点项目的选择标准什么样的仓库最适合先跑如果你也想在团队里推这套流程我的建议是不要一上来就把所有项目全切过去而是先选一个“试点”。我实践下来的筛选标准就三条这个仓库有足够的测试基线。如果连传统测试都没有直接上评测集等于在流沙上盖楼。模块边界足够清晰。领域边界模糊的项目AI 很容易在 Develop 阶段越权修改无关模块导致 review 成本飙升。业务决策人愿意每周花 30 分钟看一次 intent diff。没有这条intent.md 很快就会沦为僵尸文档。我见过最快落地成功的案例是一个 8 人的内部工具团队从决定试点到第一版评测集接入 CI只花了 8 天我也见过大团队推这个东西推了两个月还在打架原因是利益相关方太多光是争论“intent.md 归产品还是归技术管”就吵了两周。所以如果你想推别追求一步到位找出一个小而关键的仓库先把闭环跑通。6.3 三个月内的实施路线图最后给一个可以直接抄的实施节奏我称之为“三个两”前两周只做一件事给仓库写上 CLAUDE.md 和 AGENTS.md搞定最基本的 AI 操作规范。第三到四周写 intent.md 初稿同时整理出第一版 20 条以上的评测用例跑通评测脚本。第五到第八周把评测接进 CI建立合并门禁开始强制“未过评测不得合并”。第八周以后进入常态化迭代每周做一次 intent review每次线上事故修复就给评测集补充新的回归用例。最后一个我个人的实操心得评测集才是 AI 原生 SDLC 真正的“团队记忆”。它比 wiki 更精确比代码注释更可执行而且它天然和 CI 绑定在一起没有人敢无视一个红灯。如果团队只能做一件事来向 AI 原生靠拢我认为不是买最好的模型也不是天天聊 Prompt 技巧而是老老实实把那个“判断什么叫做好”的评测集建起来。有了它六阶段和 intent.md 才是活的没有它一切 AI 原生流程都是纸面功夫。