正在加载，请稍候
用内部订单导出项目实测 AIcoding 落地：intent.md 意图文件、42 条评测集与 P0/P1/P2 分档阈值、人工审查保留的 4 个节点，以及把代码审查全交给模型后一周 12 个问题 commit 进主干的反面教训。
2026 年 8 月 21 日，Anthropic 的 Applied AI 团队发布 AI 原生 SDLC 实战手册，核心判断是：当代码不再瓶颈时，规划、审查、部署这些"人速环节"成了新约束。我们拿一个内部订单导出项目试了这套流程，把传统六阶段改成了 intent.md + 持续评测闭环，下面是实操记录，不是手册复述。
传统软件开发生命周期（SDLC）分六阶段：规划、设计、构建、测试、部署、维护。每阶段独立、角色分离——产品经理写需求，架构师做设计，工程师实现，QA 验证，发布团队上线，运维监控。工作靠文档、工单和签批在各阶段之间流转。
这套流程设计初衷是在"写代码最耗时"的年代最大化效率。PRD、估算、产品安全评审，都是为了对齐长达数周甚至数季度的开发工作。今天构建阶段被压缩到数小时，这些环节就变成了拖后腿的地方。
手册给了三个判断：瓶颈转移到构建两侧的规划、审查和部署；逐行审查跟不上智能体产出的 diff；治理成本因例外仍走周会月会而上升。安全团队规模按人类产出配置，智能体把代码产出放大后，要么审查队列积压，要么代码带病发布。
| 阶段 | 传统 SDLC | AI 原生 SDLC |
|---|---|---|
| 规划 | 委员会收集需求，研讨会提炼，人工成文 | 模型直接从源头综合痛点，写入意图文件 |
| 设计 | 分析师写规格，设计师解析 | 需求与设计压缩进单次会话，技能规范引导并纳入 git |
| 构建 | 测试和代码由人工编写 | AI 生成，机构知识以 CLAUDE.md 和技能形式维护 |
| 测试 | 阶段边界设 QA 关卡 | 持续评估贯穿实现过程 |
| 部署 | 人工逐行审查每一行代码 | 多层智能体审查，人工只保留给关键代码，钩子作审批关卡 |
| 维护 | 人工监控生产缺陷 | 智能体监控，超出控制范围诊断后写回新意图文件 |
贯穿右栏的主线是"已提交的工件"。每个阶段结束时把意图、规格、计划、diff 和审查结论写入版本控制，下一阶段从读取工件开始，提交链同时就是审计追踪。
手册对意图文件的定义很直接：一份用提出者自己语言写成的原型规格说明，包含想要什么、为什么想要、在哪些约束条件下。存进版本控制的 intent/ 目录（单仓就是一个目录），产品负责人审查修正后才提交。
传统流程里，一个想法要经过待办条目、用户故事、故事点、细化会议，所有权每次交接都转移，最终到工程团队的内容与提出者本意隔了好几个环节。AI 原生方式把意图只捕获一次，下一阶段直接读取这份文件。
我们改造内部订单导出模块时用的结构是这样的：
# intent: 内部订单导出模块改造\n## 背景与动机\n- 财务每月导出 6 万行订单时浏览器卡死，耗时 40 分钟\n## 目标\n- 支持 10 万行 CSV 分片导出，单次 < 90 秒\n- 导出任务异步化，失败可重试\n## 约束（不可违反）\n- 不引入新中间件，不改变现有订单表结构\n- 兼容旧版导出接口，灰度一周\n## 验收口径\n- 评测集 42 条用例自动回归，通过率 ≥ 95%这份文件人和模型读的是同一份，产品负责人直接改 markdown，不需要先翻译成开发语言再转回业务语言。我们最深的感受是：意图文件减少的不是写文档的时间，而是交接中的失真。
手册第二条做法是把重复性流程编码为技能（skills），连同机构知识维护在版本化的 CLAUDE.md 文件里。口头规范的问题在于：每个人对"代码风格"的理解不一样，模型每次上下文里看到的规范也不一样。
技能把"什么算合格"变成可执行文件。评审技能、安全 API 检查技能、提交信息规范技能，都在 git 里版本管理，改动有记录。我们实测下来这一步最容易被跳过，但回报最直接——标准写进技能文件后，模型产出的 diff 风格一致性明显变好，人工审查从"逐行找问题"变成"看技能是否被违反"。
传统 SDLC 在阶段边界设 QA 关卡，AI 原生流程把测试变成贯穿实现过程的持续评估。工程细节就两个：评测集怎么建、阈值怎么定。
评测集从真实历史缺陷里抽。我们建了 42 条回归用例，覆盖订单金额计算、权限边界、导出格式三个高风险区。每条用例有输入、期望输出、失败时的严重级别。阈值按级别分档：P0（金额、权限类）不允许任何失败；P1（功能类）通过率 ≥ 95%；P2（体验类）≥ 90%。低于阈值该次生成直接打回重做，不进入合入队列。
触发点也关键：每次模型生成 diff 后自动跑一遍，不是等阶段结束。问题在 10 分钟内被发现，而不是 3 天后。AIcoding 落地的质量底线，其实是这套自动回测撑起来的，不是模型本身。
手册明确：多层智能体审查 + 人工只保留给受监管和关键代码。治理在 AI 行动时强制执行，钩子作为审批关卡。我们保留人工的节点有四个：
人工注意力从"逐行看代码"转向"在关卡看智能体标记"。这是手册反复强调的：人类仍对所有需要判断力的决策负责。
我们一开始走得比手册更激进：代码审查也全交给模型，认为多层智能体审查已经足够。第一周确实很顺，合入速度快了一截。
一周后统计：12 个 commit 带着问题进了主干，包括一个金额四舍五入错误（P0 级）和两个权限校验遗漏。都是能靠评测集和人工关卡拦下来的问题。
复盘原因：评测集还没建完就撤了人工关卡，模型审查对自身产出的盲区没有兜底。改回 HITL（人在环）后，人工只在合并前看智能体标记的问题，成本没有回到原来那么高。这是"人类仍对所有需要判断力的决策负责"的注脚——工具越强，关卡越不能省，只是关卡的位置变了。
PRD 是给产品团队评审用的正式文档，流程重、交接多。意图文件是提出者自己语言的意图快照，人和模型都能直接读，下一阶段直接消费，减少翻译损耗。它不替代 PRD，替代的是"需求在交接中失真"这件事。
有必要，但可以轻量起步。20 条用例的评测集加按严重级别分档的阈值，一天就能搭完。评测集最大的价值不是拦 bug，是让模型每次生成都有一个客观通过标准，避免"看起来对"就合入。
不用。手册的 plays 是模块化的，有依赖图，可以从没有前置条件的环节开始。我们就是先从意图文件加持续评测两块切入，其余阶段保持原样，稳定后再动下一块。
更多 AI 原生开发流程的拆解与工具实践见 蓝曜炬辉技术博客；想了解我们对外交付的 AIcoding 落地形态，可以看 AIcoding 落地案例，或者直接 联系我们 聊一次流程改造评估。