吴恩达最近发了一篇文章谈AI编码智能体里面有两个关键词特别抓人技能地图、短迭代。他明确说了一件事——AI编码智能体应该走短迭代人工把关的路线而不是去追求全自动一把梭。这个观点放在当下“AI写代码”口号喊得震天响的节点算是给行业泼了盆冷水但泼得很有道理。我做AI辅助编程这件事已经有大几年了从早期的代码补全工具一直用到现在的智能体工作流算是看着这个领域从“玩具”变成“生产力”的。最近大半年我几乎天天泡在AI Agent编码工作流里踩过的坑不比写过的代码少。看到吴恩达这篇东西的时候我第一反应是终于有人把这件事说透了。今天我就结合自己的实操经验拆一拆他说的这张技能地图到底怎么理解以及把“短迭代人工把关”真正落到自己工作流里的具体方法。这篇文章不聊虚的全是能直接拿去用的东西。1. AI编码智能体的技能地图到底在画什么1.1 技能地图不是一张图而是一套能力分层吴恩达提到的技能地图我理解下来核心是把AI编码这件事从“一个黑盒”拆成“一组可评估、可训练、可组合的技能”。现在市面上大多数团队用AI编码的方式还停留在“把需求丢给AI让它给我生成一个完整功能”的阶段。这相当于你让一个刚毕业的实习生直接负责整个模块他不翻车谁翻车。技能地图的核心逻辑是把编码任务按照认知难度和上下文依赖程度分层然后针对每一层配置不同的AI使用策略。我根据自己的实践把AI编码的能力大致分成这么几个层次第一层是代码补全与局部建议。这就是Copilot早期干的事根据上下文帮你补全下一行、下一个函数。这一层AI的可靠性最高因为它只做局部推断不需要理解整个系统的设计意图。第二层是单文件级任务。比如“帮我把这个函数改成异步的”“给这个类补充单元测试”“修复这个正则表达式”。这一层AI需要理解单个文件的完整内容但不需要跨文件追踪调用关系。这类任务AI做起来已经相当靠谱了前提是你把文件内容完整给它。第三层是多文件级功能开发。比如“新增一个用户注册接口包含参数校验、数据库写入、日志记录”“把订单模块从单表改成读写分离”。这一层AI需要理解跨文件的调用链、数据模型、项目规范。坦白说这一层AI经常翻车翻车的原因不是它不会写代码而是它对项目的理解不够全面。第四层是仓库级架构决策。比如“当前项目该不该引入消息队列”“这个模块的边界应该怎么划分”“如何设计一个可扩展的插件机制”。这一层目前的AI更多是提供参考建议真正的决策还得靠人。第五层是全自动开发。也就是把需求往那一放AI自己拆任务、自己写代码、自己跑测试、自己修bug、自己上线。这一层目前还处于理想阶段也是吴恩达说“不要追求”的那一层。1.2 为什么要把能力拆开看拆开看的最大好处是让你对AI的输出质量有一个合理的预期管理。我见过太多团队的通病用AI生成了一个多文件功能跑起来有问题就得出“AI写代码不靠谱”的结论。但实际情况往往是他们让AI去做了第四层甚至第五层的事情却用第二层的标准去要求它。这就像你让一个实习生去设计系统架构然后用“代码有没有bug”来考核他——考核维度和任务难度完全错位。有了技能地图之后你的使用策略就很清晰L1、L2层的任务可以放心交给AI去跑跑完简单看一眼就行L3层的任务需要你提供足够的上下文并且在几个关键节点做人工确认L4层以上的任务AI只用来做信息收集和方案对比决策权一定要攥在自己手里。这个分层还有一个隐藏价值它能帮你判断该买什么工具、该给AI配什么权限。如果你们团队90%的需求是L2级别的那一个轻量的编码助手就够用了如果大量需求是L3级别的那就需要上支持多文件上下文、能跑命令、能主动读代码库的智能体工具。1.3 技能地图的边界AI什么时候该“闭嘴”我自己的经验是AI在L3层有一个非常典型的表现它特别自信地生成一大段代码但你仔细一看它自己造了一个并不存在的工具函数或者调了一个已经被废弃的API。这就是典型的“上下文幻觉”——它知道个大概但不了解细节。所以在技能地图的框架下我们需要给AI设定一个“能力边界”它能做什么你不能让它做什么。我在团队里定的规矩是这样的允许AI自主完成变量重命名、格式化、生成测试数据、写单元测试、修编译错误。允许AI建议但必须人工确认引入新依赖、修改数据库结构、改动公共接口签名、调整核心业务逻辑。禁止AI自主执行改动安全相关代码、操作生产环境配置、删除代码、大规模重构。这个边界画出来之后AI的使用效率反而更高了。因为它不再需要在我没给它明确授权的情况下“猜”哪些能碰哪些不能碰我也不用担心它一个顺手把不该改的也改了。2. 为什么短迭代才是真王道而不是全自动2.1 全自动的诱惑与陷阱每次聊到AI编码总有人问能不能让AI把这个需求从头到尾全做了我在旁边喝咖啡等结果就行。我的回答一直是如果你想等来一个能直接上线的功能大概率要失望如果你想等来一个“看起来很完整但其实到处是雷”的功能那AI绝对能让你满意。为什么全自动路线容易翻车我总结有三个核心原因第一个是上下文断裂。AI的上下文窗口是有限的哪怕现在主流工具都做了上下文压缩它也不可能像一个人一样记住项目里每一个细节。当它处理一个跨越多个文件、多个模块的需求时常常出现“前面刚确认的方案后面就忘了”的情况。这不是它笨是它的工作记忆机制决定的。第二个是错误累积。编码是一个错误累积敏感的过程——前面一个错误的假设会传导到后面所有的代码里。如果你让AI一口气生成一个完整功能中间一旦有一个设计假设是错的后面的代码全都建立在这个错误假设上。你检查的时候会发现AI代码写得挺整齐但方向完全跑偏了返工成本比你自己写还高。第三个是反馈延迟。全自动模式下AI写完一段代码距离你发现问题、给出反馈、让它修正中间隔了很长一段时间。这段时间里它可能又基于错误代码“创作”了几百行新代码。反馈越晚修正的成本越高这是软件工程的基本定律AI时代依然成立。2.2 短迭代的工程学逻辑吴恩达强调的短迭代本质上是把上面三个问题逐个击破。短迭代的意思不是“让AI多跑几轮”而是把一个大任务拆成一系列足够小的子任务每个子任务做完之后立刻给AI反馈确认无误后再进入下一个子任务。这就像写文章一样与其让AI一口气写一万字然后推翻重来不如让它先写大纲、再写首段、你审完首段再写第二段。每一步都有检查点错误就不会滚雪球。我自己在实践中的经验是一次短迭代的任务量控制在“一个文件改动、或者跨两到三个文件、但改动逻辑单一”的粒度最合适。比如“新增一个接口”这个任务我会把它拆成下面几个子任务AI先写参数校验逻辑。我检查校验规则是否完整边界条件是否考虑到。AI写DTO和实体类的映射。我检查字段映射是否正确类型是否匹配。AI写数据库查询逻辑。我检查SQL条件、索引使用、事务边界。AI写接口的实现和异常处理。我检查业务逻辑和错误码设计。AI补测试用例。我检查覆盖率和断言是否正确。每一步之间AI的上下文是干净的、任务是聚焦的而我有机会在每一个检查点及时纠偏。这个模式看起来比“一句话丢给AI”要多花很多轮交互但总耗时反而更短因为你几乎不需要返工。2.3 一个关键的心态转变从“交付驱动”转向“过程驱动”短迭代要求你转变一个心态不要纠结于AI“这一轮产出了多少代码”而要关注“这一轮的任务边界是否清晰、这一轮的结果是否正确”。我最早用AI编码的时候总喜欢一次给它一个大需求看着它哗哗生成几百行代码觉得特别爽。后来踩了几次大坑之后我总结出一个规律AI生成代码的数量与最终可用代码的比例在任务越大的时候越低。一个20行的小函数AI写出来基本能用一个200行的模块AI写出来大概三分之一能留一个2000行的完整功能AI写出来的东西最后可能全删了。所以我现在用AI编码的核心动作只有一个把任务拆到足够小。具体拆多小我有一个判断标准让AI做一件事这件事做完之后你能明确判定“做对了”还是“做错了”。如果一件事做完之后你还需要思考半天才能判定对错说明任务拆得还不够小。3. 人工把关AI是副驾驶不是自动驾驶仪3.1 把关的四个关键环节吴恩达强调人工把关这个“关”到底卡在哪里我根据自己的实操总结出四个必须人工介入的关键节点。第一个节点是意图把关。AI理解的“用户注册”和你想要的“用户注册”可能是两码事。你要的是手机号验证码注册它可能给你整了个邮箱密码注册你要的是注册后自动登录它可能给你返回一个401让你手动登录。这个节点不把关后面全白做。我每次给AI下任务之前都会先自己写一遍验收标准然后把这些标准直接贴在提示词里。比如“新增用户注册接口使用手机号和验证码登录注册成功后自动创建登录会话并返回token手机号已存在时返回业务错误码1001而不是抛出数据库异常。”这样AI跑出来的东西至少大方向不会偏。第二个节点是架构把关。AI非常擅长在局部写出“合理但不利于整体”的代码。比如为了完成一个查询功能它可能直接在Service层里写原生SQL而不走现成的Mapper为了给前端返回数据它可能直接在Controller层拼装视图对象而不是复用已有的DTO。代码能跑但它破坏了项目的架构约束。这个环节你必须看不然代码库会以肉眼可见的速度腐化。第三个节点是安全把关。AI默认的安全意识是不够的。它可能把用户ID直接拼进SQL语句、把日志里输出完整的手机号、把生产环境的数据库密码硬编码在配置里、甚至给你写一个不校验权限的接口。我在代码审查中专门加了一条规则凡是涉及用户输入、权限验证、敏感数据的代码AI改完之后必须人工逐行过一遍不能直接信任。第四个节点是质量把关。编译通过、测试通过不代表代码质量好。AI写的代码往往存在过度设计、耦合度过高、命名误导等问题。我审查AI代码的时候会刻意问自己一个问题这段代码如果半年后需要改需求改起来费不费劲如果答案费劲那不管它现在跑得好不好我都会让AI重新设计。3.2 “焦虑但高效”才是人机协作的正确姿势吴恩达在文章里提到一个很有意思的说法AI编码智能体的使用感受应该是“焦虑但高效”而不是“闲得发慌”。我非常认同这句话。如果你用AI编码的时候感觉很闲、什么都不用管、喝着咖啡等结果那大概率后面有一个大坑在等你。相反如果你用AI编码的时候一直在看它的输出、一直盯着它的推理过程、时不时打断它纠偏那你才是真正在“用”AI而不是被AI“带跑”。我自己工作时的状态是这样的AI干活的时候我并不是在发呆而是在想下一步的任务拆解、在检查上一步的输出、在维护整个需求的技术清单。AI负责把想法变成代码我负责判断想法对不对、边界在哪里、下一步做什么。我们各司其职节奏飞快但又各不越界。才这提醒一点把关不是“找茬”不是为了证明AI不行而是为了最后的交付质量。我见过一些朋友把大量精力花在“让AI背锅”上——AI写错了就疯狂吐槽AI。这没有意义。AI写错了说明你的上下文没给够或者任务拆得不够细把它当成一次系统优化机会反而更有价值。3.3 把关的工具与方法人工把关这件事光靠“人肉看代码”效率太低。我有几个趁手的方案第一是让AI自查。在提示词里要求AI写完代码后自己列一个检查清单比如“我改动的文件有哪些”“我新增了哪些依赖”“我有没有改动公共接口”“有没有处理边界条件”。让AI自己先过一遍能过滤掉不少低级问题。第二是diff审查法。AI每次改完代码我都不会直接点“接受全部”而是先看一遍diff。这个习惯救了我太多次了。因为AI经常会在你指定的文件之外顺手改一些别的东西——它给你重构函数的时候可能顺带把配置文件里的空格都改了让整个diff变得难以阅读。第三是按需使用系统工具。像Claude Code这类智能体工具有一个看代码库的能力。你可以让它“搜索项目中所有使用这个接口的地方”“查看这个模块的测试覆盖情况”它会自己去读文件、汇总信息。这个功能在把关阶段特别好用相当于让AI先帮你把需要人工审查的重点圈出来你再针对性地细看。4. 落地一套“短迭代人工把关”的AI编码工作流4.1 工具选型不同层次的需求匹配不同的工具要落地这套工作流工具选型是关键一环。我不推荐“听风就是雨”地装一堆AI工具而是建议根据你实际的编码层次需求来选。如果你70%以上的需求在L1、L2层那一个轻量级的编码插件就够了。这类工具的核心价值是补全及时、支持单文件级别的理解、能快速生成测试和修复问题。它们不需要特别强的项目级理解能力但要求响应快、插拔方便。如果你的需求和团队正处于高速迭代期大多数任务集中在L3层那我建议上完整的智能体工具。这类工具的核心特征是能主动读取多个文件、能执行命令、能跨文件修改代码、支持你把整个项目结构作为上下文喂给它。我最近用Claude Code比较多它在多文件修改和命令执行能力上做得比较成熟配合短迭代的工作方式体验相当稳。还有一个方向是自建工作流。如果你用的是Dify这类智能体平台可以把“短迭代人工把关”固化成一条流水线需求输入→任务拆解→子任务分发→每个子任务输出后经人工确认→确认通过才进入下一步。团队里不同角色可以用统一的模板和流程来协作减少个人操作习惯带来的质量波动。4.2 上下文管理学会给AI“划重点”短迭代能不能跑通很大程度取决于你给AI的上下文质量。这是我实操中体会最深的一点。很多人抱怨“AI不懂我的项目”其实不是AI不懂是你没给它懂的机会。把一个几千个文件的仓库直接丢给AI让它“自己看”它看完也是一头雾水。更好的做法是你作为人类工程师先做一遍信息筛选然后只把“当前子任务需要的上下文”精炼地提供给AI。具体来说我在给AI下编码任务时提示词里会包含四个部分第一是任务目标一句话说清楚要做什么事。第二是技术约束比如“必须使用项目已有的XX组件”“不允许引入新的依赖”“遵循项目的分层架构”。第三是相关文件路径明确告诉AI它应该读哪些文件、改哪个文件。第四是验收标准列出几条可判定的完成条件。这四个部分写清楚AI的输出质量会有一个很大的提升。我在实践中的一个发现是与其把大量的代码内容粘贴进上下文不如把“这些文件的路径它们在项目中的作用”写清楚然后让AI自己去读。像Claude Code这类工具支持直接读文件配合一个清晰的路径列表AI对项目的理解比我手动贴代码片段要全面得多。这里还要提一句热词里提到的Claude Code硬编码了cache_control参数的问题。这个现象的本质是AI工具在上下文管理上还在做硬性的参数设置而不是根据任务动态调整。这也提醒我们不要过度依赖工具自带的“记忆”能力把重要的上下文写进提示词里或者维护一个项目的说明文档让AI每次都读取比指望工具自动记住要可靠得多。4.3 一个完整的短迭代任务示例我拿最近做的一个实际任务来演示一下完整的“短迭代人工把关”流程。任务是给一个订单系统新增“取消订单”接口要求只有待支付状态的订单可以取消取消后释放库存并向用户发送站内通知。我把它拆成了四个子任务子任务一AI先梳理现有订单模块的结构。让它找出订单实体、订单状态枚举、库存扣减逻辑、消息通知服务的文件位置并输出一个调用链分析。这一步是我人工把关的重点——如果AI理解的调用链是错的后面的代码全都要推翻。子任务二AI在订单服务中新增cancelOrder方法。限定条件是“只写这个方法以及必要的参数校验逻辑不改动其他代码”。AI完成后我检查状态流转逻辑是否正确以及是否复用了现有的库存扣减服务。子任务三AI新增HTTP接口层代码从Controller到DTO的映射。我重点检查参数校验、错误码映射、权限注解是否到位。子任务四AI补测试用例包括“待支付订单取消成功”“已支付订单取消被拒绝”“订单不存在时返回错误”三个场景。我检查测试覆盖和断言是否准确。每个子任务之间我会明确告诉AI“上一个任务验收通过现在开始下一个任务”这个信号很重要——它能帮助AI清空上一个任务的上下文缓存避免新旧任务之间上下文干扰。整个过程跑下来从开始拆解到所有子任务验收通过大概花了40分钟。对比之前我“一句话丢给AI”然后花两小时调试的错误结果效率提升已经不需要再解释什么了。4.4 验收标准怎么定让AI自己先过一遍“验收关”人工把关不是让你当AI的“免费测试员”。我习惯让AI在交付每个子任务后自己先运行一遍本地测试、过一遍lint然后把结果直接汇报给我。Claude Code这类工具天然支持在编码过程中跑命令写完代码之后让AI执行测试命令、把输出结果贴回来。你直接看测试结果就能知道这一轮迭代是否通过不需要亲自动手敲命令了。我的提示词模板大概是这样的“完成上述修改后运行项目的单元测试和静态检查确认没有引入新的错误如果有测试失败请分析原因并在不改变任务目标的前提下进行修复修复后重新运行测试直到通过为止。最后把你的改动清单和测试结果汇报给我。”这样一整轮下来我给AI的指令、AI的执行过程、AI的自查结果都在对话记录里我只需要做“终审”而不是“逐行排查”。5. 常见问题与排查技巧实录5.1 AI改动了方案之外的代码这是我遇到最多的问题。你让它改一个函数它连带着把调用方、配置文件、甚至注释里的空行都改了。不仅diff乱糟糟还容易引入意外行为。排查方法很简单养成“只接受指定文件的更改”的习惯。在提示词里明确写“只允许修改以下文件列表其他文件一律不许动”。如果AI仍然越界说明它的上下文指令遵循能力有问题直接撤回重来。我还会定期检查diff发现异常立即指出来这让AI在后续迭代里会更克制。5.2 上下文被“塞爆”AI开始胡言乱语短迭代模式下如果连续跑了很多个子任务对话太长之后AI仍然可能出现上下文遗忘的问题。表现就是它把新任务的验收标准忘了开始按照历史任务里的模式写代码。我的处理方式是重要子任务之间开启一个新的对话窗口。因为编码工具现在都支持把项目上下文作为全局参数所以新开对话不会损失“项目级记忆”损失的只是旧对话里的“任务级记忆”——而这正是我们想要的。我还会把每个子任务的验收标准写在一个单独的项目笔记里每次给AI下指令时都复制最新的版本进去确保它永远基于当前任务的标准来执行。5.3 AI的测试“假通过”AI写测试有个典型毛病为了“让测试通过”它会写出很弱的断言。比如只检查接口返回200、不检查返回体里的具体值只验证“没有抛异常”、不验证数据库里真的多了记录。这种测试等于白写。我现在的对策是在验收标准里明确“必须包含正向场景、逆向场景、边界场景三种测试用例并且断言必须验证返回值或状态的实质变化而不是仅仅验证没有报错”。如果AI交上来的测试用例全是弱断言我会打回重写。这个要求会让AI在写测试的时候更有针对性。5.4 什么时候不该用AI编码最后说一个很多人不太愿意面对的问题AI编码不是所有场景都适用。我总结了几种不建议用AI的情况供你参考。涉及敏感权限的代码改动比如权限校验、支付流程、数据导出这类场景除非你的把关能力特别强否则不建议让AI动手。系统刚启动、还没有建立统一技术规范的项目AI无法通过模仿现有代码来学习规范出来的风格会很随意。遗留系统的维护性改造这类项目往往历史包袱重、隐藏依赖多AI靠上下文理解很难把握全部约束容易改一处坏一处。这不是说AI在这些场景里完全没用而是说它只能当“顾问”不当“主力”。在传统模式下我们写代码以前会先做设计文档、画架构图、定接口规范到了AI时代这些前置工作不仅没有失去意义反而变得更加重要。你对需求的理解越深、对技术的判断越准AI替你写代码的效率就越高。回到吴恩达那个观点上他说的短迭代与人工把关本质上是在强调一件事AI编码智能体最理想的使用状态不是你完全放手而是你更加主动每一个决策点、每一个验收环节都由你来掌控。AI负责把“你想做的”变成“能跑的”而你负责搞清楚“到底该做什么”。这套思路真正用起来之后你会发现自己写代码的速度反而变慢了——因为花在思考、拆解、把关上的时间变多了但代码的整体质量和最终交付速度实打实地提升了。最后再分享一个我最近养成的习惯每次给AI下达编码任务之前我会先强制自己用三五句话把任务描述完。如果描述不出来说明我对任务的理解还不够透这时候硬上AI浪费的是我的时间。想清楚再让AI干AI会给你惊喜没想清楚就丢给AIAI会还你一个惊吓。这个习惯帮我避开了至少一半无效编码也让我对“短迭代人工把关”这八个字的理解越来越深。