1. 从一份内部手册说起AI 原生 SDLC 到底在解决什么问题第一次看到“AI 原生 SDLC”这个说法我脑子里蹦出来的不是兴奋而是怀疑。过去两年团队里试过把 Copilot 塞进 IDE、试过让大模型写单元测试、试过用 Agent 自动改 Bug结果呢代码是写快了但评审成本、返工率、上下文丢失的问题反而更严重。直到我认真拆解了 Anthropic 那份六阶段重构手册尤其是其中intent.md和持续评测这两个抓手才意识到之前的路子走偏了——我们一直在用 AI 加速旧流程而不是围绕 AI 重新设计流程。这篇文章想聊的就是这套“AI 原生 SDLC”的实战落地逻辑。核心关键词包括AI、SDLC、Anthropic、intent.md、持续评测。我会把六阶段拆开讲清楚重点落在intent.md这个意图契约文件怎么写、持续评测体系怎么搭、以及我在实际项目中踩过的坑。适合正在把 AI 引入研发流程的技术负责人、一线开发、测试工程师也适合对 AI 工程实践感兴趣的产品同学。不管你是刚接触还是已经试过一轮都能从下面的拆解里找到可以直接抄作业的部分。先说结论AI 原生 SDLC 不是“用 AI 写代码”而是把 AI 当作流程中的一等公民重新定义需求、设计、实现、验证、交付、运维六个阶段的输入输出。intent.md解决的是“AI 到底要干什么”的歧义问题持续评测解决的是“AI 干得对不对”的验证问题。这两个抓手立不住后面全是空中楼阁。2. 六阶段重构手册的整体设计思路拆解2.1 为什么是六个阶段而不是传统 SDLC 的五阶段传统 SDLC 一般是需求、设计、开发、测试、运维五个阶段。Anthropic 这套手册把它拆成六个多出来的那一个叫“意图对齐”放在需求和设计之间。这个改动看起来小实际上是整套方法论的地基。我一开始也觉得多此一举直到在一个真实项目里吃了亏。当时我们用 AI 生成一个订单导出模块需求文档写的是“支持按时间范围导出订单”AI 理解成“导出所有订单再前端过滤”结果数据量一大直接超时。问题出在哪需求文档是给人看的人会自动补全“时间范围应该下推到查询层”这个隐含意图但 AI 不会。intent.md就是把这个隐含意图显式化变成 AI 能读懂的契约。所以六阶段是意图对齐、需求细化、方案设计、实现、持续评测、交付运维。意图对齐独立成阶段是因为它是 AI 原生流程里唯一不能省的人工介入点。后面五个阶段都可以高度自动化但意图必须由人定义清楚。2.2 AI 原生和 AI 辅助的本质区别这两个词经常被混用但差别很大。AI 辅助是在旧流程里加一个工具比如用 AI 补全代码、用 AI 生成测试用例。流程本身没变AI 只是个更快的打字机。AI 原生是把 AI 当作流程的参与者每个阶段的产出物都要考虑“AI 能不能读懂、能不能执行、能不能验证”。举个具体例子。AI 辅助模式下需求文档是 Word 或 Confluence 页面开发自己看完写代码。AI 原生模式下需求文档要同时产出两份一份给人看的 PRD一份给 AI 看的intent.md。后者是结构化的、带约束的、可被程序解析的。这不是形式主义而是因为 AI 在长链路任务里会丢失上下文只有把意图固化成文件才能在每个阶段重新注入。2.3 方案选型背后的三个考量我在落地这套流程时重点权衡了三个问题。第一上下文成本。大模型的上下文窗口有限把整个代码库塞进去不现实。六阶段的设计让每个阶段只加载必要的上下文比如实现阶段只加载intent.md和相关模块代码评测阶段只加载测试用例和变更 diff。这样单次调用的 token 消耗可控成本不会失控。第二可验证性。AI 生成的东西必须能被自动验证否则人工评审成本会吃掉所有效率收益。持续评测阶段就是为此设计的它不是一个可选项而是流程的强制环节。每次 AI 产出代码都要跑一遍评测集通过率不达标就回退。第三可回滚性。AI 原生流程里AI 的产出是批量化的一旦方向错了影响面比人工写代码大得多。所以每个阶段都要有检查点和回滚机制。intent.md一旦确认就冻结后续阶段只能读不能改要改必须走变更流程。3. intent.md 的核心细节与实操写法3.1 intent.md 到底是什么和 PRD 有什么区别intent.md是一份用 Markdown 写的意图契约文件放在项目根目录或模块目录下。它和 PRD 最大的区别是PRD 描述“用户想要什么”intent.md描述“系统应该做什么、不做什么、边界在哪”。PRD 可以有模糊表述intent.md必须精确到可执行。我通常把intent.md分成五个部分目标、输入输出、约束条件、验收标准、反例。目标用一句话说清楚这个模块要解决什么问题输入输出定义清楚数据结构和格式约束条件包括性能、安全、兼容性要求验收标准是可量化的指标反例是明确列出“不要做什么”防止 AI 过度发挥。3.2 一份可直接复用的 intent.md 模板下面是我在实际项目中反复打磨的模板你可以直接拿去改。# Intent: 订单导出模块 ## 目标 支持运营人员按时间范围导出订单数据导出文件为 CSV 格式单次导出不超过 10 万条。 ## 输入 - 时间范围start_time, end_time格式 ISO8601 - 导出字段order_id, user_id, amount, status, created_at - 调用方运营后台通过 HTTP POST /api/order/export ## 输出 - 成功返回 CSV 文件流Content-Type: text/csv - 失败返回 JSON 错误码和消息 ## 约束 - 查询必须下推到数据库层禁止全量加载后内存过滤 - 单次导出耗时不超过 30 秒 - 导出操作必须记录审计日志 - 不支持跨年查询超过 365 天返回错误 ## 验收标准 - 10 万条数据导出耗时 30s - 时间范围过滤在 SQL 层完成可通过慢查询日志验证 - 审计日志包含操作人、时间范围、导出条数 ## 反例 - 不要在前端做时间过滤 - 不要导出用户敏感字段手机号、身份证 - 不要支持无时间范围的导出这份模板的关键在于“约束”和“反例”两部分。约束是正向要求反例是负向边界。AI 在生成代码时如果没有反例很容易“好心办坏事”比如自动帮你加上手机号字段因为它觉得导出应该完整。3.3 写 intent.md 的三个实操心得第一用 AI 来写 intent.md 的初稿。我通常先把 PRD 丢给大模型让它生成intent.md初稿然后人工逐条审核。这样比从零写快很多而且 AI 会补充一些你没想到的边界条件。但审核环节不能省因为 AI 会编造不存在的约束。第二约束条件要可验证。写“性能要好”没用要写“10 万条导出耗时小于 30 秒”。写“注意安全”没用要写“不导出手机号和身份证”。可验证的约束才能进入持续评测环节。第三intent.md 要版本化。每次变更都要记录在文件头部的变更日志里包括变更原因、影响范围、审批人。这样当 AI 产出不符合预期时可以追溯到是哪次意图变更导致的。注意intent.md一旦进入实现阶段就冻结。如果中途要改必须回到意图对齐阶段重新评审不能直接改文件让 AI 重新生成。否则会出现“边写边改”的混乱AI 的上下文会前后矛盾。4. 持续评测体系的搭建与落地4.1 为什么持续评测是 AI 原生 SDLC 的生命线人工写代码评审靠人看。AI 写代码评审必须靠自动化。原因很简单AI 的产出速度是人的十倍如果评审还是靠人逐行看瓶颈立刻转移到评审环节整体效率不升反降。持续评测就是把评审自动化让 AI 的每次产出都能在秒级得到反馈。我在项目里把持续评测分成三层单元评测、集成评测、意图评测。单元评测验证函数级正确性集成评测验证模块间协作意图评测验证是否满足intent.md的约束和反例。前两层是传统测试的延续第三层是 AI 原生流程新增的。4.2 意图评测怎么写把 intent.md 变成测试用例意图评测的核心思路是intent.md里的每一条约束和反例都要对应至少一个测试用例。比如约束“查询必须下推到数据库层”对应的测试用例是检查生成的 SQL 是否包含 WHERE 时间条件反例“不要导出手机号”对应的测试用例是检查 CSV 表头是否包含手机号字段。下面是一个意图评测的示例用 Python 写import pytest from order_export import export_orders def test_time_filter_pushed_to_sql(): 验证时间过滤在 SQL 层完成 sql build_export_sql(2024-01-01, 2024-01-31) assert WHERE in sql assert created_at in sql assert 2024-01-01 in sql def test_no_sensitive_fields(): 验证不导出敏感字段 csv_header get_export_header() assert phone not in csv_header assert id_card not in csv_header def test_max_export_limit(): 验证单次导出不超过 10 万条 with pytest.raises(ExportLimitError): export_orders(2024-01-01, 2024-12-31)这些测试用例不是传统意义上的功能测试而是意图测试。它们不关心具体实现只关心intent.md里的约束是否被满足。AI 每次生成代码后先跑这一组测试通过率 100% 才进入人工评审。4.3 持续评测的触发时机和门禁策略持续评测不能只在提交时跑要在多个节点触发。我的做法是AI 生成代码后立即跑意图评测提交 PR 时跑单元和集成评测合并到主分支后跑全量评测。任何一层不通过直接阻断流程。门禁策略上我设置了三档意图评测通过率低于 100% 直接拒绝单元评测覆盖率低于 80% 拒绝集成评测有失败用例拒绝。这三档是硬性门禁没有例外。一开始团队觉得太严但跑了一个月后线上事故率下降了七成大家就服了。4.4 评测集本身的维护评测集不是写完就完了它需要跟着intent.md一起演进。每次intent.md变更对应的评测用例必须同步更新。我通常把评测集和intent.md放在同一个目录下用命名关联比如intent.md对应intent_test.py。这样变更时不容易漏。另外评测集要定期做“有效性检查”。有些用例可能因为实现变化而失效比如断言了具体的 SQL 字符串但实现换了 ORM 后字符串变了。这类用例要改成断言行为而不是断言实现否则会变成维护负担。5. 六阶段完整实操流程与关键环节5.1 意图对齐阶段人和 AI 的第一次握手这个阶段的目标是产出冻结的intent.md。流程是产品写 PRD我让 AI 基于 PRD 生成intent.md初稿然后拉上产品、开发、测试三方评审。评审的重点是约束和反例确保没有遗漏。评审通过后intent.md打上版本号并冻结。冻结的意思是后续阶段只能读不能改。如果实现过程中发现意图有问题必须走变更流程重新评审。这个规矩听起来死板但能避免大量返工。5.2 需求细化阶段把 intent.md 拆成任务这个阶段是把intent.md拆成可执行的任务列表。我通常让 AI 基于intent.md生成任务拆解然后人工调整。任务粒度控制在半天以内每个任务都有明确的输入输出和验收标准。任务列表确定后每个任务会关联到intent.md的具体条目。这样在实现阶段AI 只需要加载当前任务相关的意图条目不用加载整个文件节省上下文。5.3 方案设计阶段AI 出方案人做决策这个阶段让 AI 基于任务和intent.md生成技术方案包括数据结构、接口设计、关键算法。AI 通常会给出多个方案人负责选型。选型的依据是intent.md里的约束比如性能约束会排除某些方案。方案确定后会生成一份设计文档同样放在项目目录下。这份文档也是 AI 后续实现的上下文来源。5.4 实现阶段AI 写代码人做评审实现阶段是 AI 主力输出的环节。每个任务AI 基于intent.md、设计文档、相关代码上下文生成代码。生成后立即跑意图评测通过后进入人工评审。人工评审只看两点是否符合意图是否有明显缺陷。符合这两点就合并。这个阶段的关键是上下文管理。我通常把相关文件路径和intent.md条目一起喂给 AI而不是把整个代码库塞进去。这样既节省 token又减少干扰。5.5 持续评测阶段自动化门禁前面已经详细讲过这里补充一点持续评测的结果要可视化。我通常用一个简单的看板展示每次提交的评测通过率、覆盖率、失败用例。这样团队能直观看到 AI 产出的质量趋势。5.6 交付运维阶段AI 辅助监控和回滚交付后AI 继续参与运维。比如用 AI 分析日志、定位异常、生成回滚方案。这个阶段我还在探索目前主要用 AI 做日志聚类和异常摘要效果不错。6. 常见问题与排查技巧实录6.1 AI 产出不符合 intent.md 怎么办这是最常见的问题。排查思路是先检查intent.md是否写清楚了再看 AI 加载的上下文是否完整最后看评测用例是否覆盖了这条约束。大部分情况是intent.md写得太模糊AI 理解偏了。我的经验是intent.md里的每一条约束都要问自己这句话能不能变成一个测试用例如果不能说明写得太虚要改。6.2 评测通过但线上出问题这说明评测集有盲区。我遇到过一次评测全过但线上导出超时。排查发现是评测数据量太小只有 1000 条没触发性能问题。后来把评测数据量加到 10 万条问题就暴露了。所以评测集的数据要贴近真实场景不能只用小样本。6.3 AI 生成的代码风格不一致这是上下文管理的问题。如果每次生成时加载的代码上下文不同风格就会飘。我的做法是维护一份代码规范文件每次生成时都加载同时在评测里加一条风格检查。6.4 常见问题速查表问题排查方向解决方法AI 产出偏离意图intent.md 是否模糊把约束改成可验证的表述评测通过但线上失败评测数据是否真实用生产数据采样做评测集代码风格不一致上下文是否统一加载统一代码规范文件上下文超限加载内容是否过多按任务加载相关文件评测维护成本高用例是否断言实现改成断言行为6.5 几个踩过的坑第一个坑是intent.md写得太长。一开始我把所有细节都写进去结果 AI 加载时上下文超限反而丢失了关键约束。后来学会分层核心约束放intent.md细节放设计文档。第二个坑是评测用例写得太死。断言了具体的 SQL 字符串结果换 ORM 后全挂。后来改成断言行为比如检查查询是否包含时间条件而不是检查具体字符串。第三个坑是忽略回滚。有一次 AI 批量生成了 20 个文件方向错了回滚花了半天。后来每个阶段都加检查点用 Git 分支隔离回滚成本降到分钟级。7. 工具链选型与团队协作建议7.1 工具链怎么选核心工具就三类大模型、版本控制、评测框架。大模型我建议选支持长上下文和函数调用的具体哪家看团队预算和合规要求。版本控制用 Git 就行关键是分支策略要配合六阶段。评测框架用 pytest 或 jest 都可以重点是意图评测要单独组织。7.2 团队协作的调整AI 原生 SDLC 对团队协作方式有影响。产品要学写intent.md开发要学写意图评测测试要学维护评测集。一开始会有阻力建议先在一个小项目试点跑通了再推广。7.3 我个人在实际操作中的体会这套流程跑下来最大的感受是AI 原生 SDLC 的瓶颈不在 AI而在人。intent.md写得好不好评测集覆盖得全不全直接决定 AI 产出的质量。AI 只是个放大器人的意图清晰它就产出清晰人的意图模糊它就产出混乱。最后分享一个小技巧每次 AI 产出不符合预期时不要急着改代码先回去改intent.md或评测用例。改完再让 AI 重新生成通常一次就过。这个习惯能帮你把问题消灭在源头而不是在下游反复打补丁。