1. 从写代码到写意图AI原生SDLC到底改了什么这两年大家都在聊AI编程但多数讨论还停留在用Copilot补全几行代码的层面。真正把AI当成研发流程的一等公民之后你会发现一个反直觉的事实最难的从来不是让AI写代码而是让AI准确理解你到底想要什么。Anthropic提出的六阶段重构手册核心价值就在于它把意图表达这件事从隐性变成了显性用一个叫intent.md的文件把需求、约束、验收标准全部固化下来再配合持续评测机制让AI在整条软件开发生命周期SDLC里始终不跑偏。我最初接触这套方法论的时候第一反应是又一个流程规范。但实际跑了两三个项目之后才意识到它解决的恰恰是AI编程最要命的痛点上下文漂移。你让AI改一个函数它顺手把隔壁模块也重构了你让它加个日志它给你换了一套日志框架。这些问题的根源不是模型能力不够而是你从来没有把边界和意图讲清楚。intent.md就是干这个的。这篇文章我会把六阶段拆开讲透重点落在intent.md怎么写、持续评测怎么落地、以及我在实操中踩过的那些坑。适合已经在用AI辅助开发、但总觉得AI不听话的工程师也适合想给团队建立AI原生研发规范的Tech Lead。读完你应该能直接在自己的项目里跑起一套最小可用的流程。2. 六阶段重构手册的骨架每个阶段到底在解决什么问题2.1 为什么是六个阶段而不是三个很多人会问SDLC不就是需求、设计、开发、测试、部署吗为什么要拆成六个我一开始也觉得是过度设计直到我把Anthropic的六阶段和传统五阶段做了个对照才发现多出来的那一个阶段恰恰是关键。传统流程里需求和设计是混在一起的产品经理写个PRD工程师看完直接开干。但在AI原生流程里意图Intent和规格Spec必须分开。原因是AI对模糊描述的容忍度极低——你说优化一下性能它可能给你加缓存也可能给你改算法还可能把异步改成同步。所以六阶段的第一阶段专门用来沉淀意图第二阶段才把它翻译成可执行的规格。我整理了一张对照表方便你理解每个阶段的输入输出阶段核心动作输入输出谁负责1. 意图捕获明确为什么做和不做什么业务诉求、用户反馈intent.md产品Tech Lead2. 规格翻译把意图转成可验证的约束intent.mdspec.md 验收清单Tech Lead3. 上下文装配给AI准备精准的代码上下文spec.md 代码库context bundle工程师4. 生成与迭代AI产出代码人做reviewcontext bundle可运行代码AI工程师5. 持续评测自动化验证意图是否被满足代码评测集评测报告工程师6. 反馈回流把偏差写回intent.md评测报告更新后的intent.md全员这张表我贴在团队白板上贴了三个月新人来了先看这个基本半天就能理解整套流程在干嘛。2.2 阶段一到阶段二意图和规格的边界在哪里这是最容易混淆的地方。我的经验法则是意图回答是什么和为什么规格回答怎么做和怎么验。举个例子。业务方说用户反馈搜索太慢。这句话进不了intent.md因为它太模糊。经过意图捕获阶段我们把它写成## 意图提升搜索响应速度 - 目标P95延迟从800ms降到200ms以内 - 约束不引入新的外部依赖不改动现有索引结构 - 非目标不做搜索相关性优化不做UI改动 - 验收在10万条数据的测试集上P95延迟达标注意这里的非目标极其重要。AI最大的问题不是做不好而是做太多。你明确告诉它不做相关性优化它就不会去动排序算法。这一条我踩过坑早期没写非目标结果AI为了提升搜索速度把相关性排序给简化了速度是快了但搜索结果质量暴跌被业务方骂了一顿。到了规格阶段才把上面的意图翻译成技术方案用哪个缓存层、索引怎么建、压测怎么做。规格是可以被AI直接执行的意图不行。2.3 阶段三到阶段四上下文装配是被低估的环节大部分团队跳过阶段三直接让AI写代码这是效率最低的做法。我做过对比实验同一个需求直接丢给AI和先装配上下文再丢给AI代码一次通过率差了将近40%。上下文装配的核心是只给AI需要的不给它可能乱用的。具体做法是把相关的文件路径、函数签名、数据结构整理成一个context.md明确标注哪些文件可以改哪些只能读附上项目里已有的相似实现作为参考范例我通常会用一段脚本自动生成这个上下文包把intent.md、spec.md和代码库里的相关片段拼在一起。这样AI拿到的信息是精准的不会因为看到无关代码而手痒去改。3. intent.md 的写法一份能落地的模板和三个真实案例3.1 为什么intent.md不能用PRD代替PRD是给人看的intent.md是给AI看的。这个区别决定了它们的写法完全不同。PRD可以有大段的背景描述、用户故事、竞品分析但intent.md必须是结构化的、无歧义的、可验证的。我见过有团队直接把PRD丢给AI当intent用结果AI把提升用户体验理解成了重写整个前端。问题就出在PRD里的形容词太多AI没法判断边界。intent.md的黄金法则是每一句话都要能被验证。提升用户体验没法验证首屏加载时间小于1.5秒可以验证。前者是PRD语言后者是intent语言。3.2 一份我用了半年的intent.md模板下面这个模板是我从三个项目里迭代出来的直接可以抄# Intent: [功能名称] ## 背景 [一句话说明为什么要做这件事不超过50字] ## 目标 - [可量化的目标1] - [可量化的目标2] ## 约束 - [技术约束不能引入什么、不能改动什么] - [业务约束不能影响什么功能] ## 非目标 - [明确不做什么1] - [明确不做什么2] ## 验收标准 - [ ] [可自动验证的标准1] - [ ] [可自动验证的标准2] ## 相关上下文 - 参考实现[文件路径] - 相关文档[链接或路径]这个模板的关键在于非目标和验收标准两节。前者防止AI过度发挥后者让持续评测有据可依。3.3 三个真实案例从模糊需求到精准意图案例一给订单系统加一个超时取消功能模糊需求是订单太久没支付就取消。我把它写成## 目标 - 订单创建后30分钟未支付自动取消 - 取消后释放库存发送通知 ## 约束 - 不改动现有订单状态机 - 复用现有的消息队列不引入新中间件 ## 非目标 - 不做退款逻辑未支付订单无退款 - 不做用户主动取消的改动 ## 验收标准 - [ ] 创建订单31分钟后状态变为cancelled - [ ] 库存数量在取消后1秒内恢复 - [ ] 通知消息成功入队案例二优化一个慢查询接口这个案例让我印象最深因为AI差点把整个数据层重构了。加了非目标之后才收敛## 非目标 - 不改变接口的返回结构 - 不引入缓存层本次只做SQL优化 - 不修改数据库表结构案例三给后台加一个数据导出功能这个案例的坑在于数据量。AI默认写了个全量查询直接把内存打爆。后来在约束里加了必须分页导出单次不超过1000条问题解决。4. 持续评测让AI的产出始终对齐意图4.1 为什么一次性测试不够传统测试是写完代码跑一遍但AI原生流程里代码是持续生成的意图也可能迭代。如果只在最后测一次你根本不知道是哪次改动引入了偏差。持续评测的核心思路是把intent.md里的验收标准转成自动化测试每次AI产出代码都跑一遍。这样偏差在第一时间就被发现而不是等到上线前。我现在的做法是每写一条验收标准就同步写一个测试用例。这两件事必须一起做否则验收标准就是空话。4.2 把验收标准转成评测集的实操方法具体怎么转我拿案例一举例。验收标准是创建订单31分钟后状态变为cancelled对应的测试可以这样写def test_order_auto_cancel_after_30min(): order create_order() # 模拟时间推进31分钟 with freeze_time(2024-01-01 00:31:00): run_cancel_job() assert order.status cancelled assert get_stock(order.sku) initial_stock 1关键在于时间要可控。用freeze_time这类工具把时间冻结测试才能稳定复现。我早期没用时间控制测试跑一次要等半小时根本没法持续跑。评测集的组织方式我推荐按意图分组evaluations/ intent_order_cancel/ test_timeout.py test_stock_release.py test_notification.py intent_search_speed/ test_p95_latency.py这样每次改动某个意图相关的代码只跑对应的评测集速度快定位准。4.3 评测报告怎么读三个关键指标跑完评测不能只看通过/失败我通常关注三个指标通过率直接反映意图满足程度低于100%就要查偏差类型是功能没实现还是实现了但越界了回归数量本次改动导致多少原有测试失败偏差类型这个指标特别有用。如果AI总是越界说明intent.md的非目标写得不够狠如果总是没实现说明目标描述不够具体。根据偏差类型反推intent.md的改进方向这是持续评测最大的价值。5. 反馈回流让intent.md越用越准5.1 偏差不是bug是intent.md的改进信号很多人把AI产出偏差当成AI不行其实大部分时候是intent.md没写清楚。我现在的习惯是每次评测发现偏差先不改代码先改intent.md。比如有一次AI给一个接口加了限流但intent.md里没提限流。这算越界吗严格说算但仔细想想限流其实是合理的。于是我把它写进了intent.md的约束里下次AI就会主动加。这就是反馈回流。5.2 一个季度迭代下来的intent.md长什么样我手上有个项目跑了三个月的AI原生流程intent.md从最初的20行涨到了80行。多出来的60行几乎全是非目标和边界条件。这些内容不是一开始能想到的都是被AI的偏差教出来的。这个过程有点像带新人。新人第一次做错你告诉他边界在哪第二次做错你再补充一条。几次之后他就知道分寸了。AI也一样intent.md就是它的分寸手册。5.3 团队协作中intent.md的版本管理intent.md必须进版本控制而且要和代码一起review。我见过有团队把intent.md放在共享文档里结果代码改了intent没改评测跑出来的结果和实际意图对不上。我的做法是intent.md和对应的代码放在同一个PR里。改代码必须同步改intent否则PR不通过。这条规则执行了两个月团队的意图表达质量明显提升。6. 实操中踩过的坑和几条硬经验6.1 坑一intent.md写太细AI反而不会干活我一开始走极端把intent.md写得像伪代码结果AI完全不动脑子就照着字面翻译遇到没写到的边界情况直接崩。后来我调整了粒度意图层面写清楚实现层面留空间。比如用缓存优化查询就够了不用写用Redis的String类型存JSON。6.2 坑二评测集维护成本被低估持续评测听起来很美但评测集本身是要维护的。意图变了评测要跟着变代码重构了测试可能要调整。我建议初期只对核心意图做持续评测边缘功能还是用传统测试。全量持续评测的维护成本小团队扛不住。6.3 坑三把AI当执行者而不是协作者这是心态问题。如果你把AI当成一个只会听指令的工具intent.md就会写成命令清单。但AI其实更像一个需要理解上下文的协作者intent.md应该写成背景目标边界的组合。心态变了写法就变了产出质量也跟着变。6.4 三条我现在的硬规则规则一任何AI生成的代码必须能追溯到某条intent。追溯不到的要么补intent要么删代码。规则二intent.md的每次修改都要有理由理由来自评测偏差或业务变化不能凭感觉改。规则三新项目第一周不写代码先把intent.md和评测集搭起来。磨刀不误砍柴工这一周能省后面一个月。这套流程我跑了半年最大的感受是AI原生SDLC不是让AI替你做决定而是逼你把决定想清楚。intent.md写明白的那一刻其实需求就已经想透了AI只是帮你把它变成代码。持续评测则是那道保险确保想清楚的东西真的被做出来了。至于工具选型、模型选择这些反而是最不重要的——流程对了换哪个模型都能跑。