## 01、痛点

上周跟一个朋友聊合作，他说现在写代码根本不是问题，问题是“一段话下去，代码就出来了，但没人知道它是怎么想的”。我也有同感。我是老李，带过团队，也写过很多年代码。最近半年团队里用 AI 辅助写功能，明显感觉前一半快了，后一半卡住了：代码提交到仓库之后，评审的人要盯着 diff 看半天；测试用例没人补；部署脚本还是手工维护；线上出了新问题，又要回到代码里猜当初的设计意图。

Anthropic 应用团队最近发布了《AI Native SDLC playbook》，专门说这个事儿：写代码已经从“人工工时”变成“机器算力”，可是评审、测试、发布这些上下游环节，仍然停在“人工节奏”，于是它们成了新的瓶颈。有人把这个叫“AI 越快，流程越堵”。这就像把高速公路的入口修得特别宽，但收费站还是老样子，车全堵在护栏后面。

更棘手的是，以前代码是给人看的过程产物，现在代码更像 AI 的一次输出。如果想审查、审计、回溯，只有代码是不够的：代码表达的是“怎么做”，但“为什么做”“为什么不那么做”“边界是什么”，往往散落在对话记录和记忆里。我们缺的不是更快生成代码的工具，而是一套能让 AI 和人在关键节点上接力的“流程协议”。

## 02、是什么

这套 playbook 的核心，是把传统的单向开发流水线改成循环 Loop。传统流程是：需求 → 设计 → 开发 → 测试 → 部署 → 维护，走完就结束。AI Native 的做法是：规划、设计、构建、部署、维护，每个阶段都产出可版本化的文本产物：intent.md、spec.md、plan.md 等等。下一阶段先读取上一阶段的文档，完成自己的产物，再由人在关键节点确认。维护阶段发现的新问题，又会被喂回规划和设计，形成闭环。

这不是说不要写代码。代码仍然重要，但它从唯一的可见产物，变成循环中间一环。各阶段的文本产物像“接力棒”：AI 读完上一棒，产生下一棒；人不用每步都上场，但每个节点都可以查，都可以审。因为文件是版本化的，所以任何一次变更都能追溯：这个需求的意图是什么？技术方案怎么选的？计划分几步？每一步谁确认的？这些全部留在仓库里，而不是留在对话历史里。

文档里还强调了三层规则：起步文件、可复用能力包、事件挂钩。起步文件约定项目背景和基本守则；能力包封装某一类任务的做法；事件挂钩在关键时刻触发校验，比如提交前、合并前。再配上一个“规划模式”，让 AI 先分析、先给方案，而不是急着动手；还要有“子任务”机制做并行处理；“评测集”则用来验证结果是否符合预期。

## 03、为什么

为什么非要把流水线改成循环？因为单向流水线天然适合人工时代：每个人都只关心自己这一段，交接靠文档，做完就撒手。可一旦生成代码的速度远超人工消化速度，单向链路就会在“评审”“测试”“发布”这些环节越积越重。循环不是为了让过程变复杂，而是为了让 AI 生成的内容在进入下一环之前，先被结构化的信息校准过。

另一个原因是，AI 的产出质量，极大依赖上下文。上下文如果只在人的脑子里，AI 每次都是“新员工”；如果上下文被写进版本化文档，AI 每次都能“捡起接力棒”。intent.md 描述为什么做这个功能，spec.md 描述接口契约和验收标准，plan.md 描述实施步骤和依赖关系。有了这些，AI 在后续阶段就不是凭空生成，而是基于“上一个节点的约定”继续工作。这比在后端翻代码、问人、翻聊天记录可靠得多。

还有一点：可审计性。在传统开发中，“为什么这么设计”通常不在代码库，而在 PR 描述、评论、会议记录里。现在很多团队用 AI 生成代码，可能连 PR 描述也是 AI 写的，到底哪些是人类拍板的？版本化产物明确记录了人在关键节点做了哪些决策，这就是审计抓手。把“逐行检查”换成“关键节点审核”，人也从疲劳的 code review 中解放出来，去审意图、审方案、审边界。

文档还提出一个特别实用原则：按依赖分层、缺哪项补哪项。不是要求所有团队一步到位。如果你的痛点只在测试环节，就先补上评测集；如果连设计方案都描述不清楚，就先补 spec 的模板；如果主线已经理顺，再考虑引入循环流程或事件挂钩。这个说法很务实，避免大家看完文档就搞一场轰轰烈烈的工具迁移。

## 04、架构

整个体系的架构可以看作一个“控制回路+核心产物”的结构。核心产物是那些版本化文档，控制回路是三层规则和配套机制。

规划阶段，输入是业务背景、用户反馈、线上问题；输出是 intent.md。这个文件回答的是“我们要解决什么问题，目标是什么，边界是什么”。人在这个节点拍板：这个方向对不对。设计阶段，读 intent.md，输出 spec.md，内容是接口、数据模型、计算逻辑、非功能要求。人在这里确认：技术方案合理吗？有没有遗漏边界？构建阶段，读 spec.md，输出代码、测试和 plan.md 的更新说明。部署阶段，读 plan.md，执行发布、验证、回滚方案。维护阶段，看监控、看告警、看用户反馈，新的信息再回到规划阶段。

三层规则里，起步文件是项目级的总纲，定义角色、目录、工作流；可复用能力包是任务级的“操作手册”，比如“如何写一份 spec”“如何补回归用例”“如何处理线上告警”，让 AI 在做某类任务时行为可预期；事件挂钩是自动化触发点，比如检测到文件变更、PR 被打开、测试结果异常，就拉起对应流程或阻断。规划模式的目的，是强制 AI 先阅读并输出分析，不是马上写代码。子任务机制把一个大任务拆成若干可并行的子任务，每个子任务有明确产物。评测集则是给关键结果打分，把结果从“看起来像”变成“可验证”。

如果把这个体系画成图，中间是“版本化产物流”，上面是人的决策点，下面是 AI 的自动执行。人不需要盯着每一步，只需要在产物交接处做检查和批准。这个架构真正移动的，不是代码，而是“约定”。

## 05、实战

我拿一个团队的实际场景举例。假设要做一个报表服务，把原来在主库里跑的统计任务拆出来。

规划阶段：负责人写 intent.md，内容包括：降低主库压力、报表延迟可容忍、首批支持三种报表。没有技术方案，也没有代码，只有意图、目标和成功标准。人在这个文件上确认。设计阶段：AI 读取 intent.md，写出 spec.md，定义接口 /reports/{type}、参数、返回结构、存储位置、预计 QPS、缓存策略。评审人先看这个文件，提出“报表数据是否要求实时”的问题。这一改，后面的代码就不用返工。

构建阶段：AI 根据 spec 生成服务骨架，同时生成对应的测试用例。关键动作是事件挂钩检测到 spec.md 发生变化后，强制运行一轮评测集，把接口测试、数据校验、性能测试都跑一遍。通过后，再进入人工评估。部署阶段：AI 读 plan.md，执行发布计划；如果出了问题，滚动回滚。维护阶段：新增了一种报表需求，需求方建议直接改现有服务。这时维护阶段的反向回路生效：因为 intent.md 里写了“首批支持三种”，于是新需求被判定为需要回到规划阶段重新确认边界。

这个例子看起来不复杂，但它的过人之处在于：每一步都有可读、可审、可回滚的文本产物。团队不需要在“AI 生成的代码对不对”上争论，因为 spec.md 已经锁定了约定。代码只是约定的实现，而不是约定本身。

还有一个“缺哪项补哪项”的实践：如果团队过去最痛的是测试补不齐，那就先单独引入评测集。AI 每次提交代码后自动跑用例，跑不过就标记。不需要一开始就搞完整的目录结构，先解决最大的那一个堵点。等流程跑顺了，再加事件挂钩，再考虑规划模式和子任务。

## 06、洞见

这套方法论背后，藏着一个更底层的判断：AI 不是替代开发流程，而是把开发流程从“以代码为中心”变成“以约定为中心”。以前代码是最精确的“约定”——人读代码理解行为。但代码对 AI 的“意图”无能为力。代码告诉你软件做了什么，却不告诉你为什么这样做、为什么不做另一个方案。版本化文档把这些信息固化成显式约定。

另一个洞见是：人的价值在移动，不是减少。人从逐行读代码，变成“审核约定”：这个目标定得对吗？这个风险接受了吗？这个发布计划可靠吗？这些判断天然需要领域知识和业务责任感，AI 不能代替。人不是被踢出了循环，而是站在更高杠杆的节点上。

也要泼一盆冷水：这套流程并不自动解决“需求本身是否合理”的问题。如果 intent.md 本身就是随口一说，后面的 spec、plan、代码全都会“高效地做错事”。版本化产物既可以是质量的基石，也可以是错误的传声筒。所以关键节点的“人”不能变成橡皮图章。

文档里说的“按依赖分层”，在我看来其实是系统思维的表现：先找到瓶颈在哪，再补最薄的板；而不是把一套复杂流程压到一个还没成熟的团队头上。真正有效的转型，从来不是照搬机制，而是机制解决当下痛点。

## 07、行动

如果你现在就想试，建议从最小动作开始：第一步，在项目仓库里建一个 docs/ 目录，先写 intent.md。内容不用很长，几句话讲清楚：这个项目解决什么问题，目标是什么，不做什么。这叫“给项目一个起点”。

第二步，在写方案或排期之前，让 AI 先读 intent.md，输出一份 spec.md。花十分钟刷一遍，把不合理的地方改掉。这等于在开发前就做一轮“纸上评审”。第三步，当代码写完后，把测试结果和 spec.md 对照，缺测试就补评测集。让自动检查先拦住低级问题。

如果这三步已经稳定，再考虑引入事件挂钩：比如修改 spec 时必须更新测试，或者合并前必须有评测记录。再往后，可以尝试规划模式：任何新功能开始前，AI 必须先分析现状、列出方案，而不是直接写代码。等到你发现代码仓库里的文档开始发生争执——那才是好事，说明设计问题正在被显式化。

一个团队不需要同时上全部机制。先找准卡点：是说不清目标，还是方案拍板太晚，还是测试补不齐？分别对应补 intent、spec、评测集。缺哪项补哪项，比推倒重来有效得多。

## 08、小结

AI 让“写代码”变快了，真正决定上限的，是上下游能否接收这个速度。把流程改成循环，不是做加法，而是把 AI 时代的“约定”做成可版本化、可审计、可接力的产品。人少看几行代码，多点几个关键节点的“同意”，这不是偷懒，是职责升级。

代码像一阵风，吹过就容易散；意图写下来，技术方案写下来，计划写下来——让 AI 在约定的轨道上奔跑。真正的工程化，是用确定性对抗不确定性。当代码由机器输出时，人的判断反而更值钱了。

## 09、链接与概念说明

原始文档：Anthropic 应用团队发布的《AI Native SDLC playbook》，网址见话题附带的官方链接。它没有给人人一个必须遵守的标准，更像一套基于实践的方法论，核心是“循环+版本化产物+规则层”。

概念澄清：
- intent.md：表达目标和边界，不写技术实现。
- spec.md：表达接口、数据模型、验收标准，供设计和评审使用。
- plan.md：表达实施步骤、依赖、部署计划、回滚方案。
- 三层规则：起步文件约定项目总纲；可复用能力包是某类任务的执行手册；事件挂钩是关键时刻的自动校验。
- 规划模式：让 AI 先分析、给方案，不直接写代码的执行模式。
- 子任务：把大任务拆成多个可并行的独立任务。
- 评测集：用自动化方式验证结果是否符合预期。

延伸阅读建议：如果你关心团队协作，可以研究“文档即代码”实践；如果你关心部署环节，可以看持续交付中的部署流水线设计；如果你关心反馈闭环，可以看“环形复盘”在运维中的用法。需要说明的是，案例中的目录结构和规则名称可以按团队习惯调整，关键是保留“产物可追溯、节点可审核、循环可回流”三个特征。

上周跟一个朋友聊合作，他说现在写代码根本不是问题，问题是“一段话下去，代码就出来了，但没人知道它是怎么想的”。我也有同感。我是老李，带过团队，也写过很多年代码。最近半年团队里用 AI 辅助写功能，明显感觉前一半快了，后一半卡住了：代码提交到仓库之后，评审的人要盯着 diff 看半天；测试用例没人补；部署脚本还是手工维护；线上出了新问题，又要回到代码里猜当初的设计意图。

AI写代码太快，评审测试发布跟不上了？这套循环打法把流程重新接上

Anthropic提出AI原生SDLC：把流水线改成循环，用版本化文档卡住关键节点，让AI快、人也看得住。

架构师

人工智能

开发工具

职业发展

AI时代开发流程正从"以代码为中心"转向"以约定为中心"。通过intent.md、spec.md等版本化文档建立可追溯的接力机制，将单向流水线改为循环闭环，让AI在约定轨道上高效运行，同时将人从逐行审查中解放，转向审核目标与方案等关键节点，破解"AI越快流程越堵"的瓶颈。

性能测试

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AI写代码太快，评审测试发布跟不上了？这套循环打法把流程重新接上-腾讯云开发者社区-腾讯云

AI写代码太快，评审测试发布跟不上了？这套循环打法把流程重新接上

AI写代码太快，评审测试发布跟不上了？这套循环打法把流程重新接上

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐