“AI 改代码快了，为什么项目还慢？”这个问题，最近快成团队晨会上的保留节目了。我自己也用 Claude 这类工具写了快一年代码，感受非常分裂：单看一次修改，AI 确实快，一个边界条件修复、批量重命名、补单元测试，转眼就完成；但把一个迭代从头跑到尾，该延期还是延期，改出的代码甚至要人工返工好几轮才能合入。

后来我把 Anthropic 团队分享的“六步准备法”完整落地到项目中，才发现问题并不在 AI 手速，而在于项目根本没有进入“可被 AI 加速”的状态。这篇文章我会把这套方法掰开揉碎讲清楚，结合我用 AI 写 Python 量化策略、改命令行工具、维护后台系统的实际经历，说说每一步到底怎么操作、为什么有效，以及最容易踩的坑。适合正在用 AI 编程助手、但又觉得交付速度没有明显提升的开发者和管理者。

1. 为什么AI手速快，项目却还在原地打转？

1.1 从“单点加速”到“系统提速”的鸿沟

我拿一个很典型的例子来说：让 AI 修复快速排序代码里的边界条件，比如数组为空、只有一个元素、全部元素相等，它能在一分钟内给出完整可运行的版本，甚至有注释、有测试用例。这种“单点修改”的速度，确实远超人类工程师，但项目整体卡不卡，几乎和这个无关。

项目的交付速度是一个系统结果，不是某个环节的结果。它由需求清晰度、代码库可读性、测试覆盖率、联调成本、部署流程共同决定。AI 加速的只是“写代码”这一个环节，如果代码写完之后，需求理解错了，或者改动破坏了其他模块，那么“写”得越快，“返工”也越快。类比来说，跑车引擎确实比拖拉机猛，但早高峰堵在城市环路上，引擎再猛也只能跟着车流挪动；真正需要解决的是路网规划、交通信号和拥堵路段，而不是发动机排量。

这就是我最早犯的错误：给 AI 提出乱七八糟的需求，让它快速生成一堆代码，结果合入后问题层出不穷。表面看 AI 帮我省了一半开发时间，实际把另一半时间都烧在了验收、排查和修复上，项目交付节奏甚至比以前更乱。

1.2 项目变慢的三个真正原因

我复盘了自己和身边团队的项目，发现凡是“AI 改得飞快、项目照样拖延”的场景，基本都有下面三个问题。

第一，目标不清晰。很多需求只有一句“优化登录模块”或“把那个查询改快一点”，没有给出具体的输入输出、边界条件和不允许的行为。AI 面对模糊目标，只能基于概率去猜。它可能猜到一个看起来合理的实现，但这个实现不是产品经理要的，也不是用户真正需要的。等代码出来后再反复沟通，时间就白白花了。

第二，上下文断层。一个大型代码库里，函数之间的调用链、数据结构的流转、历史决策的原因，都不会写进单个文件的注释里。AI 在没有上下文的情况下修改代码，只能盯着当前文件“局部最优”，很容易忽略调用方的约定。我见过一次 AI 改一个返回码，从字符串改成整数，结果下游十几个模块全部报错，因为没有人提前告诉它这个函数被谁调用。

第三，验证缺位。如果改完代码没有快速反馈机制，你就只能靠肉眼评审或者等 CI 跑很久。可一旦反馈周期太长，AI 生成的错误代码会在项目里潜伏好几天，积累成更大的问题。比如一个迭代里连续改了几十个函数，到提测前一天才发现某条链路断了，根本不知道是哪次 AI 修改造成的。这种状态下，团队会本能地不敢用 AI，最终又回到手写模式。

1.3 准备，才是AI时代的交付杠杆

所以真正的杠杆不是让 AI 更快，而是让项目在 AI 介入之前就已经“准备完毕”。Anthropic 在内部推进 AI 辅助开发时，逐渐总结出六步准备法：定义可验收结果、建立上下文索引、拆分工单边界、构建快速验证闭环、约定人机审查规则、用度量驱动迭代。这套方法的目标，是把项目变成一个 AI“敢上手、能上手、上完手可以快速确认对错”的状态。

我第一次完整跑完这六步，是在一个内部数据报表项目上。那段时间项目里充斥着历史遗留代码，维护文档几乎为零，团队已经很久没有顺畅交付过新功能。我花了两天时间做准备，包括整理模块地图、写验收标准、搭快速测试脚本，之后再用 AI 改代码的效果非常明显——一次修改被直接采纳的比例高了很多，返工率也降下来了。接下来，我把六步拆开详细讲，每一句话都是实操过后的经验。

2. Anthropic六步准备法：把项目调到“可被AI加速”的挡位

2.1 第一步：把需求写成可验收的结果

这一步看起来最简单，也最反直觉。很多人给 AI 提需求时，倾向于写“帮我实现一个订单导出功能”，然后期望 AI 自动把所有细节补齐。但 AI 不是业务分析师，它更擅长的是“在给定边界内做工程”，而不是从零推断复杂业务规则。

我的经验是，需求至少要包含四类信息：

• 输入条件：代码会拿到什么数据、什么参数、什么前置状态。
• 期望输出：成功后应该返回什么，失败时抛出什么异常。
• 边界情况：空值、超时、并发冲突、恶意输入怎么处理。
• 禁止事项：不允许访问哪些模块、不允许改哪些字段、不允许引入哪些依赖。

举个例子，我让 AI 写一个 Python 量化交易策略的示例代码，如果只说“写一个策略”，它很可能给你一段看起来专业、但无法回测的伪代码。但如果我把目标写成“给定 pandas DataFrame 格式的日线数据，包含 open、high、low、close、volume 字段，计算 20 日移动平均线，当收盘价上穿均线时输出买入信号，下穿时输出卖出信号，返回一个单独的信号列，且不允许修改原始 DataFrame”，AI 生成的代码基本可以一次通过。

为什么这一步有效？因为大模型本质上是概率系统，给它越明确的目标，它的注意力就越集中，输出被判定为“正确”的概率也越高。如果连“什么算作完成”都不定义，后面所有验证都无从谈起。

2.2 第二步：建立代码库的“活地图”与上下文索引

项目里真正慢的部分，往往不是写代码，而是“搞清楚代码在哪里”。尤其是一个经历了多轮迭代的代码库，目录结构复杂、模块相互耦合、路径依赖严重，AI 每次改代码都像是在没有地图的城市里导航。

准备法里的第二步，是建立一份可供 AI 阅读的“代码地图”。这个地图不是传统意义上那种写完就没人看的架构文档，而是一份持续更新的、服务型文本，告诉 AI 和人类开发者下面几件事：

• 项目的顶层模块划分，每个模块的职责边界。
• 关键数据模型和接口定义，包括数据流向。
• 环境配置方式，比如环境变量、数据库连接、第三方服务。
• 常见命令，如测试、构建、lint、启动脚本。
• 已知坑点，比如某个历史实现为何存在、哪个区易出故障。

我的做法是在仓库根目录维护一个AI_CONTEXT.md文件。每当要启用 AI 修改代码时，我会先让 Claude 读取这个文件，再结合具体工单做修改。单是这一步，就让我给 AI 下达指令后的准确率有了明显提升。以前它在多个模块之间“犹豫”，经常改错文件；读完地图后，它基本能准确落在被允许的范围内。

这个地图必须保持“活”的状态。每次合入代码时，顺手更新地图中受影响的部分。不要试图一次写全面，而是让地图跟着项目演进来积累。AI 时代有一个反直觉的事实：给 AI 的文档不是越厚越好，而是要精准、结构清晰、指向明确。

2.3 第三步：拆分工单，划定依赖边界

我在项目里最深的体会是：一个工单越大，AI 改代码的失败率越高。因为大工单通常涉及多个文件、多个模块，彼此之间存在调用关系，AI 无法在一次上下文中完整掌握所有细节。即使它生成了整体方案，人类工程师也需要花大量时间审查和微调，效率并不比手写好多少。

所以准备法的第三步，是把大任务拆成独立的小工单，并明确每个工单的边界。一个理想工单应该满足：

• 只改动一个逻辑区域或一个功能模块。
• 改动涉及的文件有限，最好不超过 5 个。
• 清楚地列出允许修改的文件，以及禁止触碰的模块。
• 每个工单可以独立验证，不依赖同一批次的其他修改。

我在做 AI 辅助开发时，会把一个完整原型拆成多个子任务。比如“实现一个命令行扫盘工具”，拆成四个子任务：目录遍历模块、文件过滤逻辑、结果格式化输出、单元测试与性能基准。每个子任务单独交给 AI，单独验证，再组装到一起。这样做还有一个额外的好处：如果某一步 AI 生成的结果不合格，只需要回滚这一步，不会影响整体。

当然，拆分粒度要因地制宜。如果代码库内部耦合极深，过度拆分反而会让人工组装成本变高。我的经验是，先画出模块依赖图，确认哪些模块可以独立修改，再按“可独立验证”的粒度拆。宁可拆得稍细一点，也不要让一个工单变成“黑箱”。

2.4 第四步：构建5分钟内跑完的验证闭环

AI 生成代码的最大风险，不是你不知道它写得好不好，而是你往往要很久之后才知道。验证闭环的价值，就是把这个“知道”的时间缩短到分钟级。准备法第四步，要求团队在让 AI 改代码之前，先确保项目里存在一套能快速运行的验证机制。

这套验证机制通常包含：

• 单元测试和关键集成测试。
• 编译或类型检查。
• Lint 与格式检查。
• 数据契约或接口测试。

最重要的是，这些验证一定要快。我一直把“5 分钟”作为一个硬性指标——本地跑完基础测试的时间不应超过 5 分钟，否则 AI 生成的代码一旦有误，你很难在短时间内判断问题出在哪。如果项目测试套件很大，就要做分层：提交前跑核心用例，CI 上跑完整用例。让 AI 的每一次修改都能在几分钟内得到反馈，你的使用频次和对它的信任度都会迅速上升。

为了让这套验证闭环真正有效，我还会让 AI 参与生成测试用例。用 AI 编写单元测试，再用这些测试去约束 AI 的主逻辑修改，形成一个“AI 写测试、AI 改代码、测试反馈结果”的循环。这种做法在“AI 测试开发”领域已经很常见了，关键是测试必须真正跑进 CI，而不是放在文档里当摆设。

2.5 第五步：定义人机协同的审查与回滚规则

即使有了清晰的上下文、任务边界和快速验证，AI 生成的代码仍然需要人来看，只是看的方式和以前不一样。准备法第五步，是提前约定人工审查的层级和回滚的规则，免得每次改动都让团队陷入“过度评审”或“完全不看”两个极端。

我是这样划分审查等级的：

• 低风险改动：新增注释、重命名局部变量、补充测试用例，这类改动可以由 AI 自测加 CI 验证后直接合入，人只做抽样检查。
• 中风险改动：修改单个模块的业务逻辑、新增接口，需要至少一位熟悉该模块的工程师做代码评审，并保留与 AI 的对话记录。
• 高风险改动：核心链路重构、数据库操作、安全相关逻辑、跨模块接口变更，除代码评审外，还要准备明确的回滚方案，最好有独立的 feature branch。

在 Git 操作上，我习惯要求 AI 生成的所有改动都集中在一个独立的提交里，不要和人工改动混在一起。一旦出现问题，可以直接 revert 这一个提交，而不影响其他进度。

这套规则既不是信任 AI，也不是不信任 AI，而是把人类工程师的注意力放在最有价值的地方：设计决策是否合理、边界条件是否覆盖、长期维护成本是否可控。让 AI 去做它擅长的快速产出，让人类去做它擅长的判断和取舍。

2.6 第六步：用度量数据驱动下一轮准备

准备法不是一次性的开工仪式，而是一套持续改进的循环。第六步要求你建立几个简单的度量指标，每周或每两周回顾一次，看准备是否真的起了作用。

我常用的指标包括：

• AI 生成的代码在一次修改内被直接采纳的比率。
• 一次修改通过 CI 验证的比率。
• 从工单准备完成到进入提测的平均时间。
• 返工比例和缺陷率。

当你发现某类工单的返工率一直偏高时，说明对这个区域的准备还不够。可能是上下文地图缺失，也可能是接受标准写得太模糊，还可能是验证闭环没有覆盖到关键路径。这时就要回到前面的步骤，针对性补齐。

举个例子，我第一次引入六步法时，发现“定时任务相关工单”的返工率高得惊人。后来排查发现，代码地图里没有定时任务框架的说明，AI 根本不知道任务注册在哪里，每次生成的代码都要人工调整。补上了这段上下文后，返工率立刻回落。

3. 六步法落地实录：一次迭代演练与三个常见坑

3.1 一次迭代里的“准备-加速”全过程

为了让你更直观地理解这套方法，我描述一次真实迭代的经过。那是一个后台管理系统，需求是新增一个“导出按渠道汇总的订单报表”功能。按照六步走，我做了下面这些事。

先花 20 分钟写清楚验收标准：输入是包含订单状态、渠道、金额的数据库表，输出是一个 CSV 文件，字段顺序有明确要求，超过 10 万条时要按批次查询防止内存溢出，不允许慢查询直接跑在交易库上。然后把代码地图里和订单相关的模块更新了一遍，标明数据访问层、导出服务、定时任务注册入口这几个关键位置。

接着把任务拆成三个子工单：订单查询逻辑、CSV 生成与字段映射、导出任务接线。每个子工单都列出了允许修改的文件和依赖接口。之后我补了一条集成测试原始脚本，能在本地 3 分钟内跑完核心链路，并把测试命令写进工单说明。

这些准备工作大约花了一个上午。下午我开始让 AI 逐个子工单实现。最终，三个子工单第一次提交就有两个直接通过全部验证，第三个字段映射有一点问题，但我根据报错信息让它修改后也通过了。晚上做了一次人工代码评审，调整了几个命名后合入。整个迭代从开发到提测，比以往快了一天半。换作以前，光是“看懂订单模块的既有实现”可能就需要大半天。

3.2 最常见的三个误区

第一，把准备做成了文档。有人把六步法简单理解成“多写文档”，结果写了一堆 UML 图和长篇大论，AI 根本不会读，团队也没人持续维护。准备不是文档层级的问题，而是“让正确的人在正确的时间拿到正确的上下文”。我现在的原则是：一切准备素材都要能被 AI 直接读取，且篇幅精简到核心问题上。一个AI_CONTEXT.md超过 200 行，就该考虑做目录和索引了。

第二，把验证做成了摆设。有些团队虽然配置了测试环境，但测试用例没有断言，或者跑一次需要 40 分钟，大家根本不会在 AI 改完代码后主动去跑。于是 AI 产生的错误只能在数小时后的 CI 里暴露。准备法里的验证闭环，必须做到“高频、快速、无歧义”。如果某个验证环节无法提供明确的对错判断，宁可拆掉重做。

第三，把审查做成了卡点。有一段时间，我们要求所有 AI 生成的改动都必须经过两个以上的人开会评审，结果流程变重，一个改动从提交到合入要等两天。AI 的优势完全被流程吃掉了。后来我们按照风险等级分层审查，低风险改动直接合入，中高风险走异步评审，不再开无谓的会议。改动流转速度立刻上来，团队压力也小了很多。

3.3 不同规模的团队怎么调整

个人项目和大型团队落地这套方法，具体形式可以很不一样。我自己维护的个人开源项目，准备环节被压缩成三个文件：AI_CONTEXT.md、工单说明、一套快速测试命令。没有那么多评审角色，但验证闭环一点都没少，甚至更严格，因为没人替 AI 把关。

小团队可以把准备纳入迭代规划会。每个工单的负责人花十分钟更新上下文索引和验收标准，AI 修改后由另一位工程师做快速评审。不需要专门引入新角色，只要统一规则就行。

中大型团队则要借助工具。比如用语义检索工具为代码库建立索引，让 AI Agent 在修改代码前能自动检索相关模块，而不是依赖人肉整理地图。再配合监控流水线和回滚平台，让验证和回滚自动化。Anthropic 的方法论最核心的部分，就是它同时考虑了工具层面和协作层面的准备，而不是单方面追求“模型更强”。

4. 准备法背后的底层逻辑：让AI少猜、快验、可回退

4.1 准备的本质是降低AI的试错成本

大模型生成代码时，本质上是在一个巨大的概率空间中选择输出。当任务条件不清晰时，这个概率分布在多个可行方案之间漫游，生成结果即便看起来合理，也可能不符合项目真实约束。准备的目的，就是通过输入条件、代码地图、任务边界，把概率分布“压”到正确的区域附近，让 AI 的试错成本显著降低。

我用一个类比来理解这件事：给刚入职的工程师安排任务时，如果只是丢给他一个仓库地址，让他自己看代码，他前几周效率必然很低。但如果你给他一份项目手册、一个明确的开发环境、一条可运行的验证命令，他很快就能产出有效代码。AI 也一样，区别只是它消化上下文的速度更快，准备带来的收益也更明显。

4.2 反馈闭环决定AI的可用性

AI 改代码的另一个特点，是它的错误模式比较“均匀”：可能在一个文件里 99% 没问题，但最后 1% 忽略了某个边界条件，导致整体功能失效。没有快速反馈时，这种错误很容易被忽视，直到后续环节才暴露。验证闭环的存在，就是把这个 1% 的错误在几分钟内显形。

我越来越觉得，AI 编程助手能不能融进团队，不取决于它能生成多少代码，而取决于你对它输出的“反馈频率”和“反馈质量”。一套好的验证闭环，能在每个小步都给出清晰的是非判断；反过来，反馈足够快，你就会更愿意让 AI 多改几次，形成良性循环。这也是我在团队里反复强调“把测试跑进 CI、跑进本地”的原因。

4.3 组织和工具的双重准备

准备法表面上是一堆动作，背后其实是组织方式的调整。工具层面，你需要有代码库索引、自动化测试、快速 CI；组织层面，你需要有明确的目标定义、分级审查规则、复盘机制。很多团队只买了工具、接入了大模型，但组织层面还在沿用“人肉维护一切”的旧模式，自然得不到理想效果。

Anthropic 的六步准备法最有价值的地方，是它同时回答了两个问题：项目如何被 AI 理解，以及项目如何被团队管控。前者靠地图、边界和验证，后者靠评审、回滚和度量。两者缺一不可。只做前者，会出现“AI 很自由但没人敢合入”；只做后者，会出现“流程很规范但 AI 寸步难行”。

5. 可以直接拿走的准备模板与检查清单

5.1 工单准备模板

我给内部团队做了一个通用模板，每次交给 AI 的任务都按这个格式写，效果还算稳定，你可以在自己项目里直接套用。

把这个模板放进项目管理工具的工单描述里，再配合代码地图使用，AI 返回的代码质量会稳定很多。

5.2 代码地图内容清单

维护AI_CONTEXT.md时，我会保持下面的固定结构，避免越写越散：

• 项目简介：解决什么问题，整体架构风格。
• 目录结构：核心模块和各自职责。
• 数据模型：主要实体、字段含义、关系。
• 关键流程：主流程、异常分支、定时任务入口。
• 环境配置：需要哪些环境变量、依赖服务。
• 常见命令：启动、测试、构建、部署。
• 坑点记录：哪些位置容易踩坑，历史上有哪些隐患。

内容要短、指向要准。一旦代码变动，相关段落就必须同步更新。我见过很多团队把这个文件写成“僵尸文档”，内容停留在半年之前，反而误导 AI，那还不如不写。

5.3 验证闭环检查表

在让 AI 修改代码前，我会快速过一遍这张清单，确保验证机制真的可跑、可判断：

• [ ] 是否能在本地跑通测试命令，且时间在 5 分钟内？
• [ ] 是否有关键路径的集成测试，覆盖核心调用链？
• [ ] 是否有明确的断言和预期值，而不是只检查代码能否运行？
• [ ] 是否有编译或类型检查，避免低级错误？
• [ ] 是否有针对本次改动的增量验证方案？
• [ ] 是否有回滚方案，比如独立提交或 feature branch 分支保护？

这些问题全部通过后，我才会把任务分配给 AI。这样做的原因很简单：如果一个任务连人都不清楚如何验证，AI 又怎么可能在正确的反馈下迭代到正确的方向？

最后再分享一点个人体会。把六步准备法跑过几轮之后，我对 AI 编程最大的认知变化是：别让 AI 去对抗一个混沌的代码库，先用准备把它变成能看懂、能验证、能回退的局面。真正快的不是 AI，而是 AI 和人都能在同一个稳定项目里起步的协作机制。你先把“准备”做到位，剩下的速度，是自然而然的副产品。