“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 的任务都按这个格式写效果还算稳定你可以在自己项目里直接套用。栏目内容示例目标实现订单 CSV 导出支持按渠道筛选输入数据库表 orders 的查询条件最多返回 10 万条期望输出CSV 文件字段顺序固定内存占用可控边界条件空数据时生成只有表头的文件查询超时返回明确错误禁止事项不允许直接修改数据库表结构不允许引入新的重量级依赖验证方式本地运行pytest tests/test_export.py -x3 分钟内通过允许修改的文件app/services/export.pyapp/handlers/export_handler.py把这个模板放进项目管理工具的工单描述里再配合代码地图使用AI 返回的代码质量会稳定很多。5.2 代码地图内容清单维护AI_CONTEXT.md时我会保持下面的固定结构避免越写越散项目简介解决什么问题整体架构风格。目录结构核心模块和各自职责。数据模型主要实体、字段含义、关系。关键流程主流程、异常分支、定时任务入口。环境配置需要哪些环境变量、依赖服务。常见命令启动、测试、构建、部署。坑点记录哪些位置容易踩坑历史上有哪些隐患。内容要短、指向要准。一旦代码变动相关段落就必须同步更新。我见过很多团队把这个文件写成“僵尸文档”内容停留在半年之前反而误导 AI那还不如不写。5.3 验证闭环检查表在让 AI 修改代码前我会快速过一遍这张清单确保验证机制真的可跑、可判断[ ] 是否能在本地跑通测试命令且时间在 5 分钟内[ ] 是否有关键路径的集成测试覆盖核心调用链[ ] 是否有明确的断言和预期值而不是只检查代码能否运行[ ] 是否有编译或类型检查避免低级错误[ ] 是否有针对本次改动的增量验证方案[ ] 是否有回滚方案比如独立提交或 feature branch 分支保护这些问题全部通过后我才会把任务分配给 AI。这样做的原因很简单如果一个任务连人都不清楚如何验证AI 又怎么可能在正确的反馈下迭代到正确的方向最后再分享一点个人体会。把六步准备法跑过几轮之后我对 AI 编程最大的认知变化是别让 AI 去对抗一个混沌的代码库先用准备把它变成能看懂、能验证、能回退的局面。真正快的不是 AI而是 AI 和人都能在同一个稳定项目里起步的协作机制。你先把“准备”做到位剩下的速度是自然而然的副产品。
AI改代码快但项目慢？Anthropic六步准备法让项目真正提速
“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 的任务都按这个格式写效果还算稳定你可以在自己项目里直接套用。栏目内容示例目标实现订单 CSV 导出支持按渠道筛选输入数据库表 orders 的查询条件最多返回 10 万条期望输出CSV 文件字段顺序固定内存占用可控边界条件空数据时生成只有表头的文件查询超时返回明确错误禁止事项不允许直接修改数据库表结构不允许引入新的重量级依赖验证方式本地运行pytest tests/test_export.py -x3 分钟内通过允许修改的文件app/services/export.pyapp/handlers/export_handler.py把这个模板放进项目管理工具的工单描述里再配合代码地图使用AI 返回的代码质量会稳定很多。5.2 代码地图内容清单维护AI_CONTEXT.md时我会保持下面的固定结构避免越写越散项目简介解决什么问题整体架构风格。目录结构核心模块和各自职责。数据模型主要实体、字段含义、关系。关键流程主流程、异常分支、定时任务入口。环境配置需要哪些环境变量、依赖服务。常见命令启动、测试、构建、部署。坑点记录哪些位置容易踩坑历史上有哪些隐患。内容要短、指向要准。一旦代码变动相关段落就必须同步更新。我见过很多团队把这个文件写成“僵尸文档”内容停留在半年之前反而误导 AI那还不如不写。5.3 验证闭环检查表在让 AI 修改代码前我会快速过一遍这张清单确保验证机制真的可跑、可判断[ ] 是否能在本地跑通测试命令且时间在 5 分钟内[ ] 是否有关键路径的集成测试覆盖核心调用链[ ] 是否有明确的断言和预期值而不是只检查代码能否运行[ ] 是否有编译或类型检查避免低级错误[ ] 是否有针对本次改动的增量验证方案[ ] 是否有回滚方案比如独立提交或 feature branch 分支保护这些问题全部通过后我才会把任务分配给 AI。这样做的原因很简单如果一个任务连人都不清楚如何验证AI 又怎么可能在正确的反馈下迭代到正确的方向最后再分享一点个人体会。把六步准备法跑过几轮之后我对 AI 编程最大的认知变化是别让 AI 去对抗一个混沌的代码库先用准备把它变成能看懂、能验证、能回退的局面。真正快的不是 AI而是 AI 和人都能在同一个稳定项目里起步的协作机制。你先把“准备”做到位剩下的速度是自然而然的副产品。
