几个月前我带着团队正式切换到 AI 原生 SDLC 的工作方式核心参照就是 Anthropic 那份六阶段重构手册。当时全网都在讨论 AI 编程能不能进生产环境但真正把 AI 写代码变成一条稳定流水线的人并不多。今天我不打算讲概念就跟大家拆透两件事一个是手册里最关键的 intent.md 到底怎么落地另一个是持续评测这套机制怎么设计才不会变成摆设。如果你正在犹豫要不要让 AI Agent 深度参与开发流程或者已经试过但总是被AI 写出了看起来对、一上线就崩的问题困扰这篇实战拆解应该能给你一些参考。先说结论这套方案真正改变的不是写代码的方式而是软件开发里意图表达和质量验证这两个环节。intent.md 把需求从一段对话变成一份可审查、可执行、可回归的文件持续评测则把AI 改坏了东西从上线后才发现提前到每次提交代码时就能自动拦住。整个六阶段流程本质上是给 LLM 的不确定性套上了一层工程化护栏。1. 内容整体设计与思路拆解1.1 为什么 AI 原生 SDLC 的核心是 intent.mdAnthropic 手册里最反直觉的一点就是它不把重点放在提示词上而是放到一个叫 intent 的文件上。我一开始也觉得这有点小题大做直到真正用了两个月才明白传统开发里需求通过 Jira ticket 或者产品文档传递这些信息是给人类看的人的大脑会自动补全上下文、推断边界条件。但 LLM 没有这个能力它只会线性地读取你给它的所有 token你写得不明确它就自己编一个合理的实现——而 AI 编出来的合理往往跟业务实际想要的合理差着十万八千里。所以 intent.md 不是一份简单的需求文档它是给 LLM 的开发契约。打个比方以前的软件需求像是一张手绘地图人类开发者知道哪条路能走、哪里有坑而 AI 原生 SDLC 下intent.md 要的是一份 GPS 坐标导航路线图每一步都得标清楚。这个文件里面写的不是做一个用户登录功能这种笼统描述而是要写清楚用户是谁、边界条件是什么、哪些情况明确不做、验收标准怎么判断。把模糊的需求翻译成机器能执行的精确描述这才是 AI 时代工程师最核心的工作。我那段时间把团队里三分之一的沟通成本都转移到了 intent 撰写和 review 上。效果很直接原来用 AI 写代码十个 PR 里有七八个要大幅修改引入 intent 流程之后AI 一次生成的代码可用率明显提高。这背后不是提示词变厉害了而是输入信息质量变高了。1.2 六阶段流程的设计逻辑把不确定性变成可通行流程Anthropic 手册把 AI 原生 SDLC 拆成了六个阶段具体是 Explore、Validate、Plan、Implement、Evaluate、Release。很多人第一次看会觉得这就是传统瀑布流程换了层皮其实差别非常大。传统流程是人写代码机器执行这六个阶段的核心是人在每个关键节点做决策AI 在受控范围内自主行动。这里的关键设计在于六个阶段里并没有让 AI 一路狂奔到上线而是在 Validate 和 Evaluate 这两个节点放入了强制的人类检查点。为什么要这样因为 LLM 最大的特点就是每次响应都有随机性哪怕你给完全相同的输入两次生成的结果也可能不同。如果不做阶段隔离AI 可能把 Explore 阶段跑偏的理解一路带到 Implement 阶段最后生成的东西完全不是你要的。这种错误的修复成本极高而且是在代码量变大之后才爆发。我落地时把这六个阶段映射到了具体的 PR 流程上Explore 和 Validate 阶段的产物合并成一个意图 PRPlan 阶段单独提交设计 PRImplement 阶段才是真正的代码 PREvaluate 和 Release 则挂在 CI/CD 流水线上。每个 PR 都有一个明确的 review 重点人类只看方向对不对AI 负责执行快不快。这种分工让我意外地发现团队里最资深的工程师反而更愿意参与代码 review 了因为终于不用再逐行看那些简单但繁重的业务代码了。2. 核心细节解析与实操要点2.1 intent.md 的标准结构每个字段背后都有坑我一开始按自己的理解写 intent.md踩了不少坑最后对照手册和其他团队的实践整理出了一份我们内部使用的标准结构。这个结构不是死的但每个字段都有它存在的理由目标 (Objective)一句话说清楚这个任务要解决什么问题必须写业务价值而不是技术动作。比如让用户能在 5 分钟内完成身份认证并进入首页是目标实现一个登录接口不是目标。范围与边界 (Scope Boundaries)明确列出哪些功能要在本次实现哪些明确不做。AI 特别擅长自由发挥所以明确不做这一个字段能省掉大量返工。技术约束 (Technical Constraints)依赖的框架版本、既有代码规范、性能基线。这个字段要写得像高铁的轨道一样硬因为 AI 有时候会贸然引入你完全没装过的依赖。验收标准 (Acceptance Criteria)必须能用程序判断的清单。比如接口响应时间 200ms覆盖率新增 10%不存在明文密码存储。避免用用户体验良好这种人类都说不清的话。关键决策记录 (Decision Log)记录这个需求讨论过程中被否决的选项以及原因。这个字段很多人忽略但它能防止 AI 在另一个分支上重复走老路。这些字段之间其实有先后顺序目标决定了边界边界决定了约束约束决定了验收标准。我见过不少团队把 intent.md 写成了填空题每一字段堆了一大段话结果 AI 读完之后还是不知道先干什么。后来我给团队定了一条规则每个字段如果超过 5 行一定还没想清楚真正的 intent 应该像一份精炼的工程简报而不是一篇散文。2.2 从一句话想法到可执行 intent的四步法这里分享一个我们惯用的从原始需求到最终 intent 的处理流程它避免了最常见的问题——拿着半截想法就开始让 AI 生成代码先甩给 AI 一段毫无结构的原始需求让它在 Explore 阶段帮忙列出所有的功能选项、可能的边界情况、需要确认的问题清单。人类对 AI 列出的清单做增删补充业务侧的真实情况。这一步最关键因为 AI 不会知道你公司里哪个老系统还不能下线哪个部门的审批流程是灰色地带。把整理好的清单再喂给 AI让它在 Validate 阶段生成一份逆向验收标准——也就是假设实现完成后自动化测试会怎么验证这个功能。这一步相当于让 AI 自己出考题。人类 review 这份考题通过后填入 intent.md冻结为这一迭代的实现依据。我们用了两周就发现这个流程实际上替代了原先一分钟都停不下来的需求澄清会议。以前产品经理要拉着开发反复确认细节现在这些沟通都被写进了 intent 文件里而且变成了异步协作每个人按自己的节奏 review 就好了。这里有一个很实操的技巧intent.md 必须纳入版本管理和代码一起进仓库每个 PR 同时包含 intent 变更和代码变更。我们试过只在文档站点上维护 intent结果不到一周就出现了 intent 与实现脱节的问题。放在同一个 PR 里reviewer 自然会把两件事对照看一致性有了保障。3. 实操过程与核心环节实现3.1 六阶段流水线的工程化落地以 Claude 为例这六个阶段听起来挺理论落到实际操作中就是一套人机协作流水线。我把每个阶段在工程上的配置和产物写一下方便你直接参考Explore探索把现有代码库索引和用户原始诉求一股脑塞给 AI让它输出可能的技术方案、相关文件的定位、潜在风险点。产物是一份探索报告。Validate验证让 AI 把探索报告里的每个方案批判一遍重点挑出依赖升级、性能瓶颈、测试路径不完整的地方。产物是验证结论推荐的实现路径。Plan规划要求 AI 基于验证结论生成分步骤的实施计划每个步骤都要标明涉及的文件、改动类型、预计风险。这个阶段我不让 AI 碰代码只做任务分解。Implement实现AI 按计划逐模块实现代码每完成一个模块自动运行对应的单元测试。这一步要配置好沙箱环境防止 AI 乱装依赖或者访问不该访问的文件。Evaluate评测新生成代码统一进入评测流水线跑静态检查、单元测试、集成测试和一组专门针对该功能的意图验证用例。这是整个流程里最重要的一环后面我会展开讲。Release发布评测通过后AI 自动生成 release notes 并提交给人工复核复核通过才允许合并主干、部署上线。在我们的工程环境里用的是 Claude Code 作为 Agent 载体配合 GitHub Actions 做 CI。六阶段不是一个人在命令行里跑而是把每个阶段封装成了一个可调用的任务模板。举个例子实现阶段我们会给 Agent 一个高度受限的系统提示只能修改 /src 下的文件不许动配置文件不许执行rm命令每次修改前必须先读取对应的 intent.md 片段。这些限制不是为了防止 AI 使坏而是为了让最终的 diff 尽可能小便于人工 review。3.2 持续评测流水线的搭建评测集是资产不是工作量持续评测这段是我最想重点分享的因为这是整套方案里最容易被轻视、但价值最大的部分。我们搭的评测流水线分三层第一层是轻量冒烟评测每次 PR 触发跑静态检测lint type check、单元测试以及少量核心路径用例目标是五分钟内告诉开发者这次改动有没有把项目的基本盘炸掉。第二层是意图回归评测每一份 intent.md 在被冻结时会连同验收标准一起被转换成一组可执行的测试用例。这些用例进入一个意图回归集之后每个 PR 都会跑一遍。如果 AI 在迭代某一个模块时意外破坏了另一个模块早期的验收标准这层评测会立刻拉响警报。这就是我们对抗AI 改一处崩一处的最主要武器。第三层是深度评测只在发布合并前或每日定时触发会跑全量集成测试、性能基线、Mock 响应一致性校验、以及一组对抗性用例——这些用例专门挑那些最容易让 AI 出错的地方比如未登录访问受保护接口、请求参数类型错误、并发指标突变。深度评测的时间开销比较大但胜在覆盖完整适合做门禁。三层流水线搭配起来效果非常明显。团队原来最怕的就是我明明只改了一行配置为什么用户反映整站报错而这类问题几乎全被第二层评测拦截了。从产品视角来说持续评测就是给 AI 生成的海量代码装上了一圈又一圈的实弹靶场虽然每一次开火都有成本但绝对比没打中靶心再回头修要省钱得多。3.3 评测指标与评测基准的量化选择说几个我们踩过坑后确定的评估指标。对于代码生成型任务核心指标有这么几个pass1单次生成直接通过评测的比例、passk生成 k 个候选里至少一个通过的比例、平均 token 成本生成一个可用方案平均要花费多少 token、完整任务耗时。其中 pass1 尤其值得关注因为它代表AI 一次做对的能力直接反映 intent 质量和模型能力如果你的 pass1 低于 40%说明 intent 还没写到位不要急着骂模型先回去改 intent。在选评测基准时我强烈建议不要一上来就做全量代码仓库的评测集那个维护成本太高了我见过几个团队就是死在这里。比较好的做法是挑选一两个核心业务模块人工构造 2030 条高质量用例先把流水线跑起来。等团队的 intent 写作水平稳定了再逐步扩充评测集。评测集要视同资产而不是额外工作——因为它的价值不在于建设的时候而在于几个月后某次回归时帮你保住线上环境。我还想提醒一个容易踩坑的点LLM 评测里最危险的是评测集被污染。如果评测用例是用 Claude 的某次生成的理想答案反向构造出来的那你评测同一型号的新版本时结果会虚高因为它可能只是在靠训练记忆背答案。我们现在的做法是评测数据必须来自真实线上请求、历史 bug 报告、以及人工 review 中发现的高价值问题禁止直接从模型的理想输出批量转成测试用例。4. 常见问题与排查技巧实录4.1 六阶段落地初期最容易踩的五个坑坑一intent 写得太短AI 开始自由发挥。比如只写了一句修复 user 表索引问题结果 Agent 顺手把整个数据库连接池配置都改了。我现在给团队的死规矩是关键业务路径的 intent 少于 80 行不给评审通过这个冷冰冰的数字能逼着大家把边界、风险、验收标准都写清楚。坑二持续评测全部依赖 LLM-as-a-judge结果评分虚高。让一个 AI 模型去评判另一个 AI 模型生成的代码确实可行但必须做两件事先固定评分标准rubric而且评分标准要具体到是否处理了 null 输入是否有事务包裹这样的刚性点再引入两个不同的裁判模型做交叉评分不一致时默认按低分处理。如果你只有一个裁判时间一长它就会变成好好先生给你所有结果都打高分。坑三评测用例太顺都是 happy path。正常的业务逻辑代码肯定能通过评测的价值全在被历史 bug 反向锤炼过的用例上。我们整理了开发日志里所有线上事故把每一个事故对应最小复现用例放进回归集这些用例才是整个流水线里最值钱的资产。坑四Agent 权限给得太大。保证代码逃离 AGENTS 束缚的铁律是所有网络访问默认禁止、所有文件写入白名单化、生产环境凭据即便放在 .env 里也不允许读取。很多团队在这条上栽了无数跟头尤其是 Agent 一通操作把package.json改得面目全非的时候。坑五人工 review 流于形式。AI 写代码速度太快reviewer 很容易走神变成划水式阅读。我的建议是建立反向 review checklist有没有意料之外的文件被修改修改是否在 intent 声明范围内有没有删除历史代码中的兼容分支这三个问题通常能挡住一半以上的质量问题。4.2 一个典型的持续评测失败案例与定位过程分享一次印象非常深的排查过程。当时我们有一轮深度评测跑挂了失败信息指向一个时间相关的函数——某个模块的缓存在特定时区边界上出现了偏差。第一反应是 AI 生成的代码有问题但我们把失败用例和最近通过的用例一对比发现测试输入是一种特殊的边界情况当地时区切换夏令时的那一天而此前评测集里没有这个用例。再追根下去才发现其实是上一次迭代里人为调整了时区处理逻辑导致缓存键的计算方式变了。这个案例典型在于它提醒我们——持续评测不光测代码还在测你的评测集本身。有些失败不是代码 bug而是评测环境与生产环境的配置漂移。所以我在流水线里额外加了一个步骤每次评测之前先跑一个环境自检脚本确认依赖版本、时区配置、测试数据库 schema 都符合预期。没有这一步你可能花半天时间在追一个根本不存在的代码 bug。另外一个常遇到的坑是跑评测时用了太多并行任务直接把 CI 机器的 CPU 打满导致所有用例都因超时失败。这种假失败比真失败更伤人因为它会消耗团队的信任。我给并行度设置了上限并且把单用例超时秒数作为全局配置统一管理人工可以在必要的时候临时调整但默认值绝不轻易放松。4.3 排查技巧速查表现象优先排查方向处理建议评测集明明没改却突然大量失败环境配置漂移、依赖版本变化跑环境自检脚本对比上轮通过的依赖锁文件AI 生成的代码可用率突然下降intent 质量下滑 / 评测集被污染检查最近的 intent 是否变短核对评测集是否混入模型理想产出冒烟评测 5 分钟内卡死测试并行的资源竞争限制并行度检查是否有测试互相争用磁盘/端口线上回归问题但评测没拦住评测集缺口缺真实线上场景立即用线上事故构造复现用例纳入深度评测层人工 review 效率低生成的 diff 过大给 Agent 增加指令按模块分 PR单个 PR 不超过 500 行5. 工具选型解析与人机协作模式5.1 工具链不是越多越好关键是接口清晰聊一下我们在实际操作中用到的工具链以及选型时的一些思考。整体分为三类Agent 主体、流程编排、评测基础设施。Agent 主体用的是 Claude Code它的主要优势是原生支持组织代码仓库的上下文索引也有很明确的工具调用接口让我们比较容易在沙箱环境里做权限控制。流程编排用的是 GitHub Actions 加一组自定义 Shell 脚本放在.workflow/目录里确定每个阶段的启动条件和输入输出物。测评基础设施我们用了 pytest 作为基础 runner配合一层 LLM judge 封装。其实不用迷信什么大而全的平台自己组合这些开源工具反而可控性更好。关键是每个工具之间的接口要清晰Agent 的输入一定是 intent.md 相关代码上下文输出一定是标准格式的 diff评测的输入一定是代码仓快照 评测集清单输出一定是 JSON 格式的指标报告。接口清晰带来的好处是你可以随时替换任何一个组件。比如今天我们用的是 Claude Code如果哪天别的模型能力更强或者成本更低只要它的输入输出能对齐这份接口约定整个流水线不用重写。这种可替换性对变化极快的 laaS 生态来说非常重要。5.2 人机协作的新角色意图工程师与评测审核员这套流程真正落地之后团队角色会发生非常微妙的变化。最明显的是新出现了一个意图工程师的角色。他不一定是最资深的程序员但一定是最理解业务边界、最擅长把模糊需求拆解成精确条款的人。这个人有点像传统的架构师加系统分析师的结合体。他会花大量时间在跟业务方对话、梳理业务流程上而不是沉浸在写代码的细节里。另一个隐形角色叫评测审核员。说实话没有人一开始就想做这个角色但一旦开始做你就会发现它的价值远远超出预期。评测审核员负责定期审查评测集质量剔除冗余用例、补充新的边界情况、监控评测数据的有效性指标比如用例通过率是否高到没有意义。我们团队里这个角色由一位有丰富测试经验的同事兼任在运行两个月后深度评测那层的无效放过现象显著减少。这也回答了很多人问我的问题AI 都开始写代码了程序员会不会失业我的观察恰恰相反程序员不是没了而是从自己写代码变成了定义 AI 怎么写代码、判断 AI 写得好不好。能留下来的团队都是那些意图表达能力和质量判断能力更强的人。AI 夺走的只是体力活但交付责任的重量始终还是在人身上。5.3 增量落地的建议别做一夜切换这种傻事最后一个实打实的劝告不要试图一个周末就把整个团队切换到 AI 原生 SDLC。我们的成功路径是先从一个小型内部服务开始完整跑通六阶段流程跑了两周磨合 intent 写法和评测集设计再逐步扩展到生产核心模块。强行全量切换的下场就是团队成员集体陷入混乱既学不会新流程又把老的工程习惯丢了。分步落地有个额外好处你能逐步积累可信的评测数据。比如你会慢慢知道在你们的具体业务下什么样的 intent 措辞能让 pass1 从 40% 升到 70%什么样的边界用例最容易反复出错。这些经验一旦沉淀下来就是团队在新流程里的护城河。我个人觉得这套 AI 原生 SDLC 真正教会我们的不是怎样更高效地让 AI 写代码而是怎样更清晰地表达我到底想要什么。写 intent 的过程逼迫着我去直面很多以前靠默契带过的模糊地带。这些模糊地带以前由某个老程序员的心智模型承担现在则被白纸黑字固化成团队资产这本身就是一种隐性价值的提升。如果你也要开始走这条路我建议从写好第一份 intent.md 和第一批评测用例开始这两件事做扎实了后面的一切都会水到渠成。