1. 从"能跑就行"到"意图驱动"：AI原生SDLC到底在重构什么

过去两年，我参与过好几个把大模型塞进研发流程的项目，绝大多数都卡在同一个地方：Demo阶段惊艳，一进真实迭代就崩。原因不复杂——我们习惯性地把AI当成一个"更聪明的代码补全器"，而不是把它当成研发流程里的一等公民。直到我系统性地研究了一套六阶段重构方法论，才意识到问题的根子在于：我们从来没有把"意图"当成可交付物来管理。

这套方法论的核心，是把传统软件开发生命周期（SDLC）从"需求→设计→编码→测试→部署→运维"的线性流水线，改造成一个以意图为中心、以持续评测为反馈回路的闭环系统。它把整个流程拆成六个阶段，每个阶段都有明确的输入、输出和验收标准，而贯穿始终的两个关键抓手，一个是intent.md这个看起来平平无奇的Markdown文件，另一个是持续评测（Continuous Evaluation）机制。

先说清楚这套东西解决什么问题。传统SDLC里，需求文档写完就锁进Wiki吃灰，代码评审靠人肉记忆，测试用例和需求之间是弱关联。一旦需求变更，你根本不知道哪些代码、哪些测试、哪些文档需要跟着动。AI介入之后，这个问题被放大了十倍——因为AI生成的内容速度极快，如果没有一个稳定的"意图锚点"，它会朝着你意想不到的方向狂奔，而且跑得越远越难拉回来。

intent.md就是那个锚点。它不是需求文档的替代品，而是一个机器可读、人类可维护的意图声明。它用结构化的方式描述"这个系统要做什么、不做什么、边界在哪里、验收标准是什么"，并且随着项目演进持续更新。持续评测则是围绕这个意图锚点建立的自动化验证体系，确保AI每次生成的产物都还在意图范围内。

这套方法适合谁？我的判断是：已经在用AI辅助开发、但感觉"越用越乱"的团队，以及准备把AI深度嵌入研发流程、但不想重蹈覆辙的团队。如果你还在单文件脚本阶段，这套东西可能有点重；但只要你开始面对多模块、多轮迭代、多人协作的场景，它带来的秩序感会让你觉得前期投入完全值得。

2. 六阶段重构手册的整体设计思路拆解

2.1 为什么是六个阶段而不是三个或十个

我一开始也怀疑过，六个阶段是不是为了显得完整而硬凑的。实际拆下来发现，这个数字是有讲究的。阶段太少，颗粒度不够，AI在每个阶段能做的事情太宽泛，容易失控；阶段太多，交接成本高，每个阶段的上下文都要重新建立，反而拖慢速度。

六个阶段的划分逻辑是这样的：意图定义 → 上下文构建 → 方案生成 → 实现落地 → 验证评测 → 反馈迭代。前三个阶段是"想清楚"，后三个阶段是"做扎实"。每个阶段之间都有明确的交付物，而且这些交付物是下一个阶段的输入。这种链式结构的好处是，任何一环出问题，你都能快速定位到是哪个阶段的交付物不合格，而不是笼统地说"AI生成的东西不行"。

我特别想强调的是，这六个阶段不是瀑布式的。它们更像是一个螺旋，每一轮迭代都会回到意图定义阶段做微调。intent.md在这个过程中扮演的是"活文档"的角色，而不是一次性写完就冻结的规格说明书。

2.2 意图优先：为什么把intent.md放在最前面

传统开发里，需求文档通常是给人和流程看的。但AI原生SDLC里，intent.md要同时服务三个读者：人类开发者、AI生成引擎、评测系统。这就要求它的写法必须兼顾自然语言的可读性和结构化数据的可解析性。

我见过太多团队把intent.md写成散文，结果AI解析的时候抓不住重点，评测系统也没法从中提取验收标准。正确的做法是采用"分层结构"：顶层用自然语言描述业务意图，中间层用结构化列表定义功能边界，底层用可执行的断言描述验收条件。

提示：intent.md里的每一条意图声明，都应该能回答"如果这条不满足，系统算不算失败"这个问题。如果回答不了，说明这条意图写得太模糊，需要拆解。

2.3 持续评测为什么不能等到最后再做

这是我最想纠正的一个认知误区。很多团队把评测当成"最后一道关卡"，代码写完了跑一遍测试就完事。但在AI原生流程里，评测必须是贯穿始终的，因为AI生成的内容不确定性太高，你必须在每个阶段都设置检查点。

持续评测的核心思想是：把验收标准前置到意图定义阶段，然后在每个后续阶段都用这些标准来验证产物。比如，在方案生成阶段，评测系统会检查生成的方案是否覆盖了intent.md里定义的所有功能点；在实现落地阶段，评测系统会检查代码是否违反了意图里声明的边界条件。

这种做法的好处是，问题在最早的可能时间点被发现。我实测下来，把评测前置之后，返工成本大概能降低六成以上——因为大部分问题在方案阶段就被拦住了，不会流到编码阶段才暴露。

3. intent.md 的写法与核心细节解析

3.1 intent.md 的最小可用结构

一个能用的intent.md，至少应该包含四个部分：意图声明、边界条件、验收标准、变更记录。我下面给一个简化版的模板，你可以直接抄去改。

# 意图声明 ## 核心目标 - 系统需要完成什么（一句话描述） - 服务的核心用户是谁 - 成功的定义是什么 ## 功能边界 - 必须做的（Must have） - 应该做的（Should have） - 明确不做的（Won't have） ## 验收标准 - 标准1：可量化、可验证的描述 - 标准2：... ## 变更记录 - 日期 | 变更内容 | 变更原因 | 影响范围

这个结构看起来简单，但每一条都有讲究。"核心目标"必须是一句话能说清楚的，如果一句话说不清楚，说明意图本身还没想明白。"功能边界"里的"明确不做的"这一项，很多人会忽略，但它恰恰是防止AI跑偏的关键——你不告诉它边界在哪里，它就会自由发挥。

3.2 意图声明的颗粒度怎么把握

这是实操中最难拿捏的地方。颗粒度太粗，AI理解不了具体要做什么；颗粒度太细，intent.md就变成了伪代码，失去了"意图"层面的抽象价值。

我的经验是：一条意图声明对应一个可独立验证的功能单元。什么叫可独立验证？就是你能为它写出一条明确的通过/失败判定条件。比如"系统支持用户登录"这个颗粒度就太粗，因为登录涉及密码校验、会话管理、错误处理等多个子功能。拆成"系统在收到正确凭证时返回有效会话令牌"和"系统在收到错误凭证时返回明确错误码且不泄露用户存在性"就合适了。

注意：不要试图在intent.md里描述实现细节。意图层只回答"做什么"和"做到什么程度算好"，"怎么做"是后续阶段的事情。把实现细节写进意图里，会导致意图和实现耦合，后续变更时两边都要改，维护成本翻倍。

3.3 让AI读懂intent.md的三个技巧

intent.md写好了，怎么让AI真正"读懂"它，是另一个问题。我踩过的坑是：直接把整个文件丢给模型，结果它抓不住重点，生成的内容偏离意图。

第一个技巧是分节投喂。不要一次性把整个intent.md塞进上下文，而是根据当前阶段的需要，只投喂相关章节。比如方案生成阶段，重点投喂"核心目标"和"功能边界"；验证评测阶段，重点投喂"验收标准"。

第二个技巧是用显式引用代替隐式理解。在提示词里明确说"请参考 intent.md 中的第X条验收标准"，而不是笼统地说"请参考 intent.md"。显式引用能大幅提升AI的遵循度。

第三个技巧是给意图声明加上唯一标识符。比如给每条验收标准编号AC-001、AC-002，这样在后续的评测报告和变更记录里，都能精确追溯到具体是哪条标准出了问题。

4. 持续评测体系的落地实操

4.1 评测体系的三个层次

持续评测不是简单地跑单元测试。在AI原生SDLC里，评测至少分三个层次：意图一致性评测、功能正确性评测、回归安全性评测。

意图一致性评测回答的是"生成的东西还是不是我们想要的东西"。这个层次的评测往往需要人工参与，或者用另一个AI模型来做裁判。功能正确性评测就是传统的单元测试、集成测试那一套，但用例要从intent.md的验收标准里自动生成。回归安全性评测确保新变更没有破坏已有功能，这个层次最容易被忽略，但在AI频繁生成代码的场景下极其重要。

4.2 从验收标准自动生成测试用例

这是持续评测里最省力的一环，也是最容易做砸的一环。省力是因为一旦intent.md的验收标准写得足够结构化，生成测试用例就是水到渠成的事。容易砸是因为如果验收标准写得模糊，生成的测试用例就是一堆废纸。

我的做法是：验收标准必须包含"输入-操作-预期输出"三要素。比如"系统在收到错误凭证时返回明确错误码"这条标准，三要素拆解后是：输入=错误凭证，操作=调用登录接口，预期输出=返回非200状态码且响应体包含错误码字段。有了这三要素，生成测试用例就是模板化的工作。

# 从验收标准生成测试用例的简化示例 def generate_test_case(acceptance_criterion): return { "name": acceptance_criterion["id"], "input": acceptance_criterion["input"], "action": acceptance_criterion["action"], "expected": acceptance_criterion["expected_output"], "assertion": build_assertion(acceptance_criterion) }

这段代码只是示意，实际落地时你需要根据自己团队的技术栈做适配。核心思路是：验收标准的结构化程度，决定了测试用例的自动化程度。

4.3 评测结果如何反哺意图迭代

评测不是为了打分，而是为了驱动迭代。每次评测跑完，结果应该自动汇总成一份"意图偏差报告"，列出哪些验收标准没通过、偏差程度如何、可能的原因是什么。这份报告是下一轮意图迭代的直接输入。

我习惯在每轮迭代结束时做一次"意图回顾"，把评测报告和intent.md放在一起看。如果某条验收标准连续多轮不通过，要么是标准本身定得不合理，要么是实现方案有系统性问题。这时候就需要回到意图定义阶段，重新审视这条标准是否还成立。

提示：意图偏差报告不要只给结论，要给证据。比如"AC-003未通过"是结论，"AC-003未通过，实际返回500错误，预期返回400错误，错误发生在输入校验环节"是证据。有证据的报告才能驱动有效决策。

5. 六阶段逐阶段实操要点与避坑指南

5.1 意图定义阶段：最容易被低估的阶段

这个阶段看起来只是写文档，但实际上它决定了后面五个阶段的天花板。我见过太多团队在这个阶段草草了事，结果后面反复返工。

实操要点：先做意图访谈，再做意图建模，最后写 intent.md。意图访谈是跟业务方、用户、技术负责人分别聊，把不同视角的期望收集起来。意图建模是把这些期望整理成结构化的意图树，区分核心意图和衍生意图。最后才是落笔写intent.md。

避坑指南：不要一个人闷头写intent.md。意图是共识，不是个人理解。我建议至少三个人参与意图评审：一个业务视角、一个技术视角、一个测试视角。三个视角都认可了，意图才算立住。

5.2 上下文构建阶段：给AI喂什么、怎么喂

这个阶段的核心任务是：为AI准备一个干净、相关、充足的上下文包。上下文包的质量直接决定生成质量。

我的做法是把上下文分成三类：领域上下文（业务知识、行业术语）、项目上下文（代码库结构、已有实现、技术栈）、任务上下文（当前要解决的问题、相关意图声明）。三类上下文分开管理，按需组合。

避坑指南：上下文不是越多越好。我实测过，当上下文超过模型有效窗口的七成时，生成质量反而下降，因为模型开始"分心"。正确的做法是精准投喂，只给当前任务真正需要的信息。

5.3 方案生成阶段：如何让AI给出可落地的方案

这个阶段最容易出现的问题是：AI给出的方案看起来很漂亮，但落不了地。原因通常是方案里缺少对现有约束的考虑。

实操要点：在提示词里明确列出约束条件，包括技术栈约束、性能约束、兼容性约束、时间约束。约束越明确，方案越可落地。

避坑指南：不要接受第一个方案。让AI生成至少三个方案，然后从可行性、成本、风险三个维度做对比。我通常会让AI自己先做一轮对比分析，然后人工再复核一遍。

5.4 实现落地阶段：代码生成的质量控制

这个阶段的核心矛盾是：生成速度和质量之间的平衡。AI生成代码很快，但快不等于好。

实操要点：建立"生成-评审-修正"的小循环。每生成一个功能单元，立刻做意图一致性检查，通过了再进入下一个。不要一次性生成一大堆代码再统一评审，那样问题会堆积。

避坑指南：AI生成的代码必须过静态检查。我见过太多因为AI生成了看似合理但实际有安全漏洞的代码而翻车的案例。静态检查工具要配置成强制门禁，不通过不允许合并。

5.5 验证评测阶段：让评测真正跑起来

这个阶段的关键是自动化。如果评测还需要人工触发、人工判断，那它就不可能持续。

实操要点：把评测集成到CI/CD流水线里，每次提交自动触发。评测结果自动生成报告，自动通知相关人。

避坑指南：评测用例要定期维护。AI生成的代码在变，评测用例也要跟着变。我建议每轮迭代都花一点时间清理过时的评测用例，保持评测套件的有效性。

5.6 反馈迭代阶段：让每一轮都比上一轮好

这个阶段是闭环的收口。核心任务是从评测结果中提取可行动的改进项，并把这些改进项分配到下一轮的相应阶段。

实操要点：建立"改进项看板"，把评测报告里的问题转化成具体的改进任务，标注优先级和负责人。

避坑指南：不要试图一次性解决所有问题。每轮迭代聚焦解决最关键的三个问题，比撒胡椒面式地修修补补有效得多。

6. 常见问题与排查技巧实录

6.1 意图漂移：AI生成的内容越来越偏离初衷

这是最高频的问题。表现是：前几轮生成的内容还符合意图，越往后越跑偏。根本原因通常是intent.md没有及时更新，或者上下文包里混入了过时的信息。

排查思路：先检查intent.md的变更记录，看最近一次更新是什么时候。如果超过两轮迭代没更新，大概率是意图漂移了。然后检查上下文包，看是否包含了已经被废弃的旧方案或旧代码。

解决方法：建立"意图同步"机制，每轮迭代开始前强制更新intent.md，并清理上下文包里的过时信息。

6.2 评测假阳性：测试通过了但实际有问题

这种情况通常是因为评测用例覆盖不全，或者断言写得太宽松。比如只检查了接口返回200，没检查返回内容是否正确。

排查思路：对通过的评测用例做抽样人工复核，看是否存在"通过了但不对"的情况。

解决方法：提高断言的严格程度，增加边界用例和异常用例。我习惯在每轮迭代里随机抽10%的通过用例做人工复核，这个比例可以根据项目风险等级调整。

6.3 上下文超限：信息太多导致生成质量下降

前面提过，上下文不是越多越好。当上下文超过模型有效窗口的一定比例时，生成质量会明显下降。

排查思路：记录每次生成时的上下文长度和生成质量评分，找出质量下降的拐点。

解决方法：建立上下文优先级机制，只投喂高优先级信息。低优先级信息可以摘要化处理，或者放到外部知识库里按需检索。

6.4 评测套件维护成本过高

这是持续评测落地后的常见问题。评测用例越积越多，维护成本越来越高，最后没人愿意维护，评测就名存实亡了。

排查思路：统计评测用例的"有效率"，即最近N轮迭代中真正发现过问题的用例比例。有效率低于某个阈值的用例，考虑归档或删除。

解决方法：建立评测用例的生命周期管理机制，定期清理低效用例。同时，把评测用例和intent.md的验收标准做关联，验收标准变更时自动标记相关用例需要复核。

6.5 团队协作中的意图理解偏差

不同角色对intent.md的理解可能不一致。业务方关注功能，技术方关注实现，测试方关注验证，三方对同一条意图声明的解读可能完全不同。

排查思路：在意图评审阶段做"解读对齐"，让每个角色用自己的话复述对意图的理解，看是否存在偏差。

解决方法：在intent.md里为每条意图声明附上"解读示例"，用具体场景说明这条意图在实际中意味着什么。解读示例不需要覆盖所有情况，但至少要覆盖最容易产生歧义的情况。

7. 我在这套方法上踩过的坑和总结的经验

先说一个最反直觉的体会：这套方法最大的价值不在于让AI生成得更好，而在于让团队想得更清楚。我一开始以为intent.md是写给AI看的，后来发现它更大的作用是逼着团队把意图想明白。很多团队在写intent.md的过程中才发现，原来大家对"这个系统要做什么"的理解根本不一致。

第二个体会是：持续评测的投入产出比在前期是负的，在后期是正的。前两轮迭代你会觉得评测拖慢了速度，因为要写用例、要跑评测、要分析报告。但从第三轮开始，评测拦下来的问题开始超过它带来的开销，ROI就转正了。关键是熬过前期的"负收益期"。

第三个体会是：不要追求一步到位。我见过团队试图一次性把六个阶段全部落地，结果每个阶段都做得半吊子。正确的做法是先落地意图定义和持续评测这两个最核心的环节，跑通一轮完整迭代，再逐步补齐其他阶段。

第四个体会是：工具是次要的，纪律是主要的。这套方法用Excel也能跑，用最朴素的Markdown也能跑。真正难的不是工具，是坚持每轮迭代都更新intent.md、都跑评测、都做回顾。我见过太多团队工具链很先进，但纪律松散，最后效果还不如用Excel但纪律严明的团队。

最后一个实用建议：从一个小项目开始试点。不要一上来就在核心项目上搞，找一个边界清晰、周期短、风险低的小项目先跑一轮。跑通了，有了体感，再往大项目上推。我在一个小工具项目上跑了三轮，把流程磨顺了之后才推到主项目上，省了很多沟通成本。

这套东西后续还可以这样扩展：把intent.md和需求管理工具打通，实现意图的自动同步；把评测结果和项目管理工具打通，实现问题的自动创建和跟踪；把意图偏差报告和迭代回顾会议打通，实现改进项的自动提取。每一步扩展都不难，难的是先把基础流程跑顺。