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 - 明确不做的Wont 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频繁生成代码的场景下极其重要。评测层次评测对象执行频率主要工具意图一致性方案、设计文档每次方案变更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的验收标准做关联验收标准变更时自动标记相关用例需要复核。常见问题典型表现排查方向解决手段意图漂移生成内容逐渐偏离检查intent.md更新记录建立意图同步机制评测假阳性通过但实际有问题抽样人工复核提高断言严格度上下文超限生成质量下降记录上下文长度与质量建立优先级机制评测维护成本高用例越积越多统计用例有效率生命周期管理6.5 团队协作中的意图理解偏差不同角色对intent.md的理解可能不一致。业务方关注功能技术方关注实现测试方关注验证三方对同一条意图声明的解读可能完全不同。排查思路在意图评审阶段做解读对齐让每个角色用自己的话复述对意图的理解看是否存在偏差。解决方法在intent.md里为每条意图声明附上解读示例用具体场景说明这条意图在实际中意味着什么。解读示例不需要覆盖所有情况但至少要覆盖最容易产生歧义的情况。7. 我在这套方法上踩过的坑和总结的经验先说一个最反直觉的体会这套方法最大的价值不在于让AI生成得更好而在于让团队想得更清楚。我一开始以为intent.md是写给AI看的后来发现它更大的作用是逼着团队把意图想明白。很多团队在写intent.md的过程中才发现原来大家对这个系统要做什么的理解根本不一致。第二个体会是持续评测的投入产出比在前期是负的在后期是正的。前两轮迭代你会觉得评测拖慢了速度因为要写用例、要跑评测、要分析报告。但从第三轮开始评测拦下来的问题开始超过它带来的开销ROI就转正了。关键是熬过前期的负收益期。第三个体会是不要追求一步到位。我见过团队试图一次性把六个阶段全部落地结果每个阶段都做得半吊子。正确的做法是先落地意图定义和持续评测这两个最核心的环节跑通一轮完整迭代再逐步补齐其他阶段。第四个体会是工具是次要的纪律是主要的。这套方法用Excel也能跑用最朴素的Markdown也能跑。真正难的不是工具是坚持每轮迭代都更新intent.md、都跑评测、都做回顾。我见过太多团队工具链很先进但纪律松散最后效果还不如用Excel但纪律严明的团队。最后一个实用建议从一个小项目开始试点。不要一上来就在核心项目上搞找一个边界清晰、周期短、风险低的小项目先跑一轮。跑通了有了体感再往大项目上推。我在一个小工具项目上跑了三轮把流程磨顺了之后才推到主项目上省了很多沟通成本。这套东西后续还可以这样扩展把intent.md和需求管理工具打通实现意图的自动同步把评测结果和项目管理工具打通实现问题的自动创建和跟踪把意图偏差报告和迭代回顾会议打通实现改进项的自动提取。每一步扩展都不难难的是先把基础流程跑顺。
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 - 明确不做的Wont 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频繁生成代码的场景下极其重要。评测层次评测对象执行频率主要工具意图一致性方案、设计文档每次方案变更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的验收标准做关联验收标准变更时自动标记相关用例需要复核。常见问题典型表现排查方向解决手段意图漂移生成内容逐渐偏离检查intent.md更新记录建立意图同步机制评测假阳性通过但实际有问题抽样人工复核提高断言严格度上下文超限生成质量下降记录上下文长度与质量建立优先级机制评测维护成本高用例越积越多统计用例有效率生命周期管理6.5 团队协作中的意图理解偏差不同角色对intent.md的理解可能不一致。业务方关注功能技术方关注实现测试方关注验证三方对同一条意图声明的解读可能完全不同。排查思路在意图评审阶段做解读对齐让每个角色用自己的话复述对意图的理解看是否存在偏差。解决方法在intent.md里为每条意图声明附上解读示例用具体场景说明这条意图在实际中意味着什么。解读示例不需要覆盖所有情况但至少要覆盖最容易产生歧义的情况。7. 我在这套方法上踩过的坑和总结的经验先说一个最反直觉的体会这套方法最大的价值不在于让AI生成得更好而在于让团队想得更清楚。我一开始以为intent.md是写给AI看的后来发现它更大的作用是逼着团队把意图想明白。很多团队在写intent.md的过程中才发现原来大家对这个系统要做什么的理解根本不一致。第二个体会是持续评测的投入产出比在前期是负的在后期是正的。前两轮迭代你会觉得评测拖慢了速度因为要写用例、要跑评测、要分析报告。但从第三轮开始评测拦下来的问题开始超过它带来的开销ROI就转正了。关键是熬过前期的负收益期。第三个体会是不要追求一步到位。我见过团队试图一次性把六个阶段全部落地结果每个阶段都做得半吊子。正确的做法是先落地意图定义和持续评测这两个最核心的环节跑通一轮完整迭代再逐步补齐其他阶段。第四个体会是工具是次要的纪律是主要的。这套方法用Excel也能跑用最朴素的Markdown也能跑。真正难的不是工具是坚持每轮迭代都更新intent.md、都跑评测、都做回顾。我见过太多团队工具链很先进但纪律松散最后效果还不如用Excel但纪律严明的团队。最后一个实用建议从一个小项目开始试点。不要一上来就在核心项目上搞找一个边界清晰、周期短、风险低的小项目先跑一轮。跑通了有了体感再往大项目上推。我在一个小工具项目上跑了三轮把流程磨顺了之后才推到主项目上省了很多沟通成本。这套东西后续还可以这样扩展把intent.md和需求管理工具打通实现意图的自动同步把评测结果和项目管理工具打通实现问题的自动创建和跟踪把意图偏差报告和迭代回顾会议打通实现改进项的自动提取。每一步扩展都不难难的是先把基础流程跑顺。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
