编码Agent实战：掌握任务拆解与代码审查的核心能力

最近吴恩达的《Using Coding Agents》刷了不少技术群。这位在机器学习圈子里影响力很大的老师每次发点跟AI实操强相关的内容几乎都会引发一轮转发和讨论。这次能刷屏我的感觉不单是因为“吴恩达”三个字——内容本身确实踩在一个关键时间点上编码Agent已经从“尝鲜玩具”变成了不少人日常开发流里的常用工具但绝大多数人还没想清楚该怎么用它或者用过几次之后因为体验不佳又退回老路。这篇内容不是长篇论文更像一份个人的经验清单。核心观点一句话可以概括要用好编码Agent靠的不再是传统意义上的“会写代码”而是一整套围绕Agent来重构工作方式的能力。它会告诉你Agent能做规划、能改多文件、能跑测试、能自己修复但前提是任务拆到位、上下文给足、验收标准讲清楚同时你还得有足够的审查能力处理它犯的错。我花了两天时间把这篇内容消化完又拿自己手上一个真实项目做了一遍完整的Agent协作实验。下面把对这篇内容的评价以及我理解中“用好编码Agent需要练的能力”拆开讲。1. 吴恩达《Using Coding Agents》到底讲了什么为什么大家都在转1.1 写的是个人经验小抄聊的却是开发范式大问题先把这篇内容定性它不是教学视频也不是系统课程更像是吴恩达把日常用编码Agent时的真实感受、操作技巧和踩坑记录整理成的一份“实操备忘”。这类内容他以前也发过不少比如关于提示工程、关于教育中AI应用的笔记风格都是提纲挈领、点到即止。但为什么这篇的传播面特别广我认为有三个原因。第一是时机。2025年这个时间点Claude Code、Cursor、Copilot这类编码Agent的能力已经强到能独立完成一个中型功能模块的开发了很多团队都在认真评估要不要把它拉进日常流程但缺少一套可信的方法论。第二是“吴恩达”这个标签自带说服力大家想看一个真正懂AI、懂机器学习的人是怎么用这些工具的。第三是内容本身不空谈他明确给出了“该做什么、不该做什么”的判断这种有立场的实操经验比四平八稳的科普文档耐读得多。1.2 核心观点你的角色从“码农”变成了“任务设计师”这篇内容给我最深的一个印象是吴恩达把 Agent 时代开发者的角色重新定义了一遍。他提到很多人在用编码 Agent 时仍然沿用的是最原始的提示词玩法一句话丢一个需求把返回的代码复制进项目不对就再问一遍。这种做法不能说完全无效但它的上限很低。Agent 只会在你给的非常狭窄的上下文里做局部修改改出来的代码往往和现有工程风格不一致甚至引入新的问题。他反复强调的用法是把 Agent 当做一个带编程能力的新同事给它一个明确的入口任务让它自己去读代码库、自己列出实现计划、自己动手改文件、自己跑测试并修复反馈。人在这个流程里的职责是设计任务管线、准备充足上下文、定义“什么算完成”、在关键节点兜底审查。这句话真正说到了根子上。我以前带过不少刚入行的初级开发最头疼的其实不是他们写不出代码而是他们只会“照着 tiket 描述改函数”不会主动理解整个模块的上下文。编码 Agent 早期的表现和这个状态非常像局部能力强全局理解弱。差别在于它会以极快的速度在错误方向上狂奔所以人如果不在前面把方向定清楚后面的风险是成倍放大的。2. 为什么偏偏是这个时候编码 Agent 成了绕不开的话题2.1 工具成熟度到了一个真正的拐点两三年前我也尝试过把 AI 接进开发流程当时的感觉是能写函数和简单脚本但稍有规模的项目就散架。上下文窗口短、对工程结构理解差、改完A文件忘了B文件做个中间层都能把自己绕晕。所以那阵子我很坚定地认为AI 写代码顶多算“高级点的手段等真正派上用场还需要几年”。但2024年下半年到2025年这段时间编码 Agent 的进步速度确实打破了我之前的预期。核心变化在几个点上上下文窗口大幅扩展能塞进整个项目的结构信息Agent 有了多步规划和工具调用能力可以主动执行命令、读取文件、搜索符号而不再是“一次对话生成一段代码”出现了 Codebase 索引和语义检索Agent 能自己定位函数、接口、依赖关系和编辑器、终端、版本控制工具的集成趋于成熟形成了一套闭环的操作流。这些变化叠加在一起效果是质变。以前你去问 AI“这个函数在哪里被调用”它只能靠猜现在它可以自己 grep、读调用链、画出调用关系再回来告诉你结论。就这么个差异让编码 Agent 从“杰出打字员”变成了“能上手干活的实习生”。2.2 范式变了评判开发者的标准也变了工具变化带来的另一个深层次影响是我们评价一名开发者的标准也在悄悄变化。老规矩里代码写得干净、算法基础扎实、架构设计有一套是硬通货。但当 Agent 能承担一大部分实现工作之后那些“一次性把接口写好、把逻辑写对”的能力相对价值开始下降。真正变得更值钱的是把你的想法拆成 Agent 能执行的任务序列、准确判断 Agent 给出的方案是否存在隐患、在它偏离方向时把它拉回来——这些我以前很少认真训练的能力突然从“软技能”变成了“核心竞争力”。这就像从手动挡切换到自动挡的开车时代。手动挡司机可能很享受换挡的掌控感但对大多数出行场景来说你更需要的是懂得看路况、规划路线、处理意外的能力。编码 Agent 就是那台自动变速箱它把“踩离合换挡”这个层面的操作接管了你能不能开好车取决于你认不认得路。3. 能力一任务拆解把“我想要”变成“请按这个流程做”3.1 为什么不能一句话下需求先说一个我踩过很多次的坑。过去用聊天式AI最顺手的用法是“帮我写个函数实现XX”一次生成一段代码往项目里贴。但把同样的习惯搬到编码 Agent 上结果经常很灾难。原因其实好理解编码 Agent 有行动能力它不只是“回答你的问题”它会真的去改文件、装依赖、跑命令。如果你的指示是模糊的它就会在某个它自己理解的“最佳方案”上狂奔改完三个文件之后你才发现完全南辕北辙而且它自己还很自信地告诉你任务已经完成。吴恩达在内容里有一个观点我深深认同他说给 Agent 安排任务的粒度不应该是“函数级”而应该是“任务级”。一个函数怎么实现让 Agent 自己决定但这个任务的目标、范围、边界、验收标准必须由你来定。打一个更生活化的比方。以前你给外包团队说“帮我做个日历功能”对方给你一个演示Demo你看着不对再提修改来回拉扯三轮才勉强能用。现在你给 Agent 说的是“请按照需求文档里第三部分的规则在 existing-calendar 模块里实现数据联动覆盖周末高亮和跨月场景完成后跑通 test-calendar 套件”。这两者的执行质量和可控性天差地别。3.2 一个看得见的拆解示例加个收藏功能这里放一个我在实战里反复用过的拆解模板方便参考。假设项目是一个前后端分离的 Web 应用需求是“给商品列表加一个收藏/取消收藏功能”。如果直接对 Agent 说“帮我加个收藏功能”它的行为大概率是改几个接口、加一张表、在前端登录态里存个状态看起来什么都能跑但和你的业务模型也许根本不匹配。我建议的拆法如下让 Agent 先读一遍现有的数据库 schema 和数据访问层确定收藏功能应该落在哪张表、关联什么用户标识和商品标识、是否需要唯一索引来防止重复收藏在服务端数据访问层新增收藏记录与取消收藏的方法并补上对应的迁移文件在业务服务层实现两个接口逻辑一个收藏、一个取消外加一个“查询当前用户收藏列表”的接口对接口做参数校验未登录用户能否操作、商品不存在时返回什么、重复收藏是幂等返回还是报错在前端商品列表页增加收藏按钮让按钮状态和服务端数据同步最后补充测试用例包括正常收藏、重复收藏、取消不存在的收藏、未登录访问四个场景跑全量测试和 lint完成后输出变更文件清单与影响面说明。这样拆完Agent 的工作就不再是一个黑盒它会沿着你给的任务列表依次推进。每一步完成之后你都能通过git diff看到具体改动判断是否符合预期。出问题的时候也能精准定位到是哪个环节跑偏了而不至于完全失控。3.3 拆的边界拆到多细才合适任务拆解也不是越细越好。如果每个子任务都细到“在第 82 行加一个 if 判断”那这活儿你自己干就行了让 Agent 参与毫无意义。拆解的真实目的是“设定路标”让 Agent 有足够的自主空间去发挥但每一步都不会脱离大方向。我的经验是三句话拆到你能判断对错的粒度。如果你看到这一步的输出无法判断“是对还是错”说明拆得太粗每一块的边界要互相独立。尽量不要让两个并发任务同时改同一个文件否则 Agent 的任务之间会互相踩脚给每一步配上验证方式。比如“跑这个测试文件”或“启动项目看接口返回”让 Agent 有自检的依据。这三条准则是我从几次惨痛教训里总结出来的。有一次我很偷懒地把“重构用户服务”和“新增短信登录”两个任务丢给同一个 Agent 并发执行结果它把两个功能的代码全都混在一个 Pull Request 里而且有一段公用逻辑被重复实现review 的时候看得我血压飙升。4. 能力二上下文管理给 Agent 一张看得懂的项目地图4.1 好的任务描述长什么样很多人以为编码 Agent 只要给一句“帮我实现 XX”它就会自动理解一切。实际上它对你的项目一无所知除非你能把关键上下文喂进它的视野。这里我把自己的任务描述模板总结一下不一定适合所有场景但对大多数工程问题足够适用。一个高效的 Agent 任务描述大致由五部分构成背景这个项目是什么、核心业务模型是怎样的、本次需求来源目标希望 Agent 最终交付什么必须是能验证的范围允许改动哪些模块、禁止改动哪些模块约束项目里有哪些既有约定比如使用某种协议、某种ORM、禁止引入新依赖验收标准哪些命令跑通了、哪些测试用例过了才算任务完成。拿上一节的收藏功能举例我会在提示词里这样写现在要在项目 backend 目录下新增一个收藏功能。项目是 Express Prisma MySQL 的经典分层结构业务代码集中在 src/services路由在 src/routes数据库模型在 prisma/schema.prisma。请先阅读这三个目录下的相关文件重点理解现有 Product 和 User 模型的关联方式然后参考 src/services/orderService.ts 的现有编码风格实现收藏、取消收藏、查询收藏列表三个方法并在 src/routes 下新增一个 favoriteRoutes.ts最后在 app.ts 中挂载该路由。不要修改 prisma/migrations 中已存在的迁移文件新增迁移文件请用规范命令生成。完成后运行 npm run test:favorites必须确保相关用例全部通过再用 npm run lint 检查代码风格。这段描述看起来很啰嗦但这正是它高效的原因。Agent 不需要猜“项目是什么结构”“该用什么风格”“我能动哪些文件”它可以直接开始干活。我过去一半以上的失败会话都是因为偷懒省略了背景和边界最后 Agent 拿着自己的一套假设在瞎搞。4.2 上下文不是越多越好要分优先级给上下文也有一个反向的坑信息量过载。早期使用 Claude Code 时我试过把整个 README、设计文档、好几个相关模块的源码路径一次性塞进提示词里结果 Agent 在阅读阶段就消耗了大量上下文到真正写代码时反而“失忆”了。我的建议是把上下文按优先级分层第一优先级目标文件和它的依赖文件路径。这个是 Agent 行动的着手点第二优先级项目的约束和既有约定。告诉它哪些规则不能违反第三优先级业务背景和设计文档。这部分往往可以按需提供等 Agent 第一轮阅读完给出理解后你再判断它是否需要补充信息。我自己的默认策略是只给三个东西目标文件的路径、项目的核心技术栈、验收命令。剩下的信息让 Agent 自己去代码库里挖。它需要了解数据模型会自己去读 schema需要了解接口风格会去翻现有的 service 层。你要做的是带它入门不是替它把所有门都开好。4.3 防止上下文被污染的几条铁律上下文管理里还有一个经常被忽视的维度会话长度的失控。编码 Agent 工作的过程是不断累积信息的过程读过的文件内容、执行过的命令输出、修改前后的代码对比都会占用上下文窗口。当累积的信息超过有效容量之后Agent 会开始丢弃早期信息最直接的后果是——它忘了最开始约定的任务目标和边界。我总结出三条铁律来对抗这个问题一个会话只做一件事。如果任务拆成五个子任务就开五个独立会话而不是在同一个会话里让 Agent 连续做五件事关键约束信息要在每轮提醒里重复出现。每条正式指令的结尾都带上“不要改 migrations”“保持现有路由风格”这类固化约束防止被长对话冲淡当 Agent 的行为开始偏离最初目标不恋战直接终结当前会话重开。重发的成本永远低于修复乱码的成本。这三条帮我在实际项目中避免了至少十次“代码改到一半结构崩了”的灾难。5. 能力三验收与代码审查Agent 出错你得兜得住5.1 开工前定好验收标准比事后补审重要编程这件事最别扭的地方在于你要求 Agent 修改的代码你自己必须能看懂并负责。很多人的误区是以为把代码交给 Agent 就不需要懂细节了这种想法在玩具项目里没问题在真实的系统性工程里几乎必然翻车。吴恩达在内容里专门提到了验证的重要性。他建议在 Agent 执行任务的过程中人应该在每个关键节点上停下来验证中间结果而不是等它把成品端上来再一次性审查。这个观点跟我的实战体会完全一致。我现在的习惯是给 Agent 下任务时一定在提示词里显式写清楚验收方式。拿经常用的几类写法举例“完成后执行npm run test确保测试全部通过”“启动服务后访问GET /api/favorites确认返回结构与接口文档一致”“不要只跑新增用例还要跑相关影响模块的用例”。这一步看起来简单但做与不做的差异极大。没有验收标准的 Agent 会“觉得改完了”就停手经常出现代码能编译、但业务逻辑完全不对的假阳性结果。而有了验收标准Agent 至少会进行一轮自我测试和修复循环显著降低你这边 review 的负担。5.2 拿到变更后的检查清单抛开测试不谈代码审查这关没有任何 AI 工具能替人完成。我是用下面这个清单来审查 Agent 编写的代码的变更范围是否在约定边界内有没有偷偷改了不在任务范围内的文件有没有顺手“优化”了不必要的代码命名是否贴合现有工程风格Agent 特别喜欢起语义正确但风格陌生的名字比如项目里全用的getUser它却写一个fetchUserData异常处理是否符合项目惯例它有没有吞掉异常、有没有在错误路径上做合理回调数据一致性是否可靠多表操作里有没有遗漏事务、并发修改时有没有冲突风险安全风险输入校验、权限校验、日志敏感信息有没有处理好是否引入新依赖或新工具链这是我最不想看到的情况Agent 经常会因为贪图省事引入一个库为整个项目增加维护成本。关于最后一点稍微啰嗦一句。我觉得编码 Agent 在解决“局部困境”时特别容易病急乱投医。比如项目里需要解析一个日期字符串现有代码明明自己写了个小工具函数Agent 却在文件的顶部悄悄import dayjs这就是典型的“没读懂项目又想省事”。遇到这种现场我的处理方式是直接把变更打回去并附上一句禁止引入新的第三方依赖请使用项目已有工具。5.3 掌握“看 diff 找问题”的核心节奏在 Agent 开发模式下每天最频繁的操作变成了git diff。它写了几百行代码你不可能从头到尾逐行重新看一遍但你可以通过 diff 快速定位高风险区域。我的节奏是这样的第一眼先看文件列表看它动了哪些文件、新增了哪些文件这个列表是否符合任务范围第二眼看关键文件的 diff重点看有没有大段删除、有没有逻辑被替换、有没有硬编码第三眼扫一眼测试文件看它的测试用例是否覆盖了任务要求是不是只写了“自证正确”的happy path。这种审查方式没法替代全面理解但它的效率非常高能让你在十分钟内判断出“这版代码能不能收”。6. 能力四版本控制与边界控制给 Agent 留好退路6.1 独立分支动手是底线不是建议编码 Agent 跑任务时最怕的不是代码写得差而是它把整个项目搞乱了你还找不到干净的恢复点。在任何一个有真实业务的项目里我都强烈建议遵循一条铁律Agent 工作前先建独立分支绝不在主干上直接开工。我自己的做法是git checkout -b feat/favorite-agent所有 Agent 产生的代码都落在这个分支上。它能成功完成任务代码审查没问题再合并到主干它出了严重问题直接丢弃这次分支或者回退到当初的 commit干净利落不留痕迹。这条准则在很多 Team 里其实是默认的代码协作规范但一旦加上 Agent 这个新变量执行得反而更松了。原因可能是 Agent 太像“自动完成”让人下意识觉得它不会搞坏东西。但实际体验告诉我Agent 出事故的时候远比人类初级开发更果断、更彻底。它可以在一分钟内改掉十几个文件等到你发现不对劲的时候可能已经牵连了一堆无关联的模块。6.2 敏感信息与权限边界编码 Agent 的安全边界也是我在实际使用中最警惕的一环。它的行动能力太强如果不加限制它可能会在某个探索步骤里把环境变量的值打进日志、把调试用的授权 token 写进临时文件、甚至把内部服务的连接信息带进上下文。这些问题在个人项目里最多算狼狈在商业项目里就是事故。我在提示词里长期保留几条底线约束所有密钥和 token 必须从环境变量读取禁止写入代码或配置文件禁止将.env、包含私密信息的日志文件、生产数据库信息写入任何输出或提交记录生产环境相关操作一律 require 人工确认。这不算专业安全审计但至少能挡住绝大多数由 Agent 引发的基础信息泄露问题。6.3 大范围重构先要影响面评估最后还有一种场景Agent 在实现一个看似简单的需求时为了“完美实现”自作主张地顺手重构了相关模块。这种情况在小范围任务里不太危险但当一个任务牵涉面较广时比如改变了一个公共方法的签名、调整了数据模型字段影响面会迅速扩散到其他模块。我现在的应对策略是在关键任务点前额外加一步前置确认。比如 Agent 如果发现“现有 schema 需要新增字段”必须先停下来向我汇报变更方案而不是直接提交迁移。我会在语境里暗示它任何涉及接口签名或数据模型的变更必须在实施前先报告方案。这一步额外操作让 Agent 的行动路径变得可预期也把“意外改动”的爆炸半径控制在单点范围。7. 实操记录一个完整的编码 Agent 工作流7.1 环境准备与仓库初始化理论说得再多不如直接跑一遍。下面分享一个我上周刚完成的实际案例给一个内部 Node.js 数据管理后台增加“导出查询结果为 CSV 文件”的功能。项目背景是 Express Sequelize EJS已有查询页能展示数据列表但没有导出能力。任务是新增一个后端导出接口以及前端一个导出按钮。Agent 选择了 Claude Code 作为执行工具配合 GitHub Copilot 做代码补全代码仓库在本地。开始之前我做了三件准备git checkout -b feat/export-csv git pull origin main yarn install同时把本地环境变量配置好确保 Agent 在跑测试时可以启动服务。这里有一点经验Agent 在执行过程中如果能很快跑起项目并看到实际反馈它的调试效率会高很多。如果项目启动需要复杂的前置步骤Agent 很容易卡在环境问题上把大量时间消耗在猜配置上。7.2 初始任务提示词写法我把下面这段完整提示词喂给了 Agent。项目是一个内部数据管理后台技术栈为 Express Sequelize EJS。现有 /items 查询页展示了列表数据本次需求是新增“导出 CSV”功能。 请先阅读 routes、models、views 三个目录下的相关文件重点了解现有列表接口的路由写法、数据模型字段范围以及当前页面的表单逻辑。然后完成以下任务在现有列表路由同目录新增导出接口支持 GET /items/export参数与列表接口一致返回 CSV 文本并设置 Content-Disposition 响应头为附件下载CSV 的列需要覆盖列表页展示的所有字段字段名为中文数据内容需要处理逗号、引号、换行转义在列表页视图中新增一个“导出CSV”按钮点击即跳转导出接口不需要额外参数如果列表接口本身有筛选条件导出接口必须复用相同的筛选逻辑新增测试用例覆盖字段转义和筛选条件透传完全不修改数据库模型和迁移文件不新增任何第三方依赖完成后运行 npm test 与 npm run lint全部通过为标准。这段提示词包含了我前面说的背景、目标、范围、约束、验收标准五个要素并且在第六点用“完全不修改”“不新增任何第三方依赖”这种把话堵死的写法防止 Agent 自作主张。实际效果相当不错。7.3 观察 Agent 的规划、执行与自修复在 Claude Code 的交互界面里Agent 先自动阅读了 routes 目录下的几个文件然后又去翻了 models 目录确认字段名。大约二十秒后它给出了一版分步计划阅读相关路由与模型确认字段清单新增导出路由在视图中添加按钮编写测试运行测试与 lint。这个计划跟我的预期基本一致。随后它开始逐个执行先创建了新路由文件/routes/exportRouter.js又用fs.createWriteStream拼了一段 CSV 输出逻辑写完后自动在模型里找字段名匹配表头。中途我发现了一个明显问题它的 CSV 转义函数只处理了逗号没处理引号。我没有手动去改它的代码而是在对话里提出质疑“请检查 CSV 转义逻辑是否处理了包含半角引号和换行的单元格”Agent 随即把转义函数升级成完整版本补上了对引号的双写替换和换行符处理然后回来报告已修复。这正是我前面说的“中间节点验证”的实战价值。如果不是在过程中发现问题等它端上来一个成品再来审查一个小小的转义 bug 可能就要靠人肉在几十行 diff 里找成本完全不一样。7.4 审查、测试与合并Agent 最终输出了一份完成报告新增了一个文件、修改了一个视图、新增了两个测试用例。我按自己的审查清单过了一遍diff 文件列表里没有出现任何不相关的文件改动新增路由写得很规矩符合现有模块的命名和挂在 app 上的方式CSV 转义函数经我抽查了几个边界值符合预期测试用例覆盖了基本导出、字段转义、筛选参数透传三个场景npm test全绿npm run lint通过。确认无误后我执行了合并分支和推送。整个流程从开始到上线大约用了四十五分钟其中一半时间花在看 Agent 的执行输出和检查代码上。相比以前自己动手写这些代码时间节省了一半以上而且工程质量并没有下降——这对我来说算是非常理想的 Agent 协作样本了。8. 常见问题与排查技巧实录8.1 Agent 改了不该改的文件这是编码 Agent 翻车时最经典的问题明明只让它加一个导出功能它却顺手格式化了几十个无关文件或者把某个通用组件的样式也改了。排查思路很简单。第一件事就是看git status和git diff --name-only锁定改动文件列表。如果发现无关文件被改动基本只有两种可能一是它在探索代码库时顺手“修正”了它自认为有问题的地方二是因为工具跨格式规范化触发了大量无关修改。处理方式分两级无关文件很少时直接对无关文件做git checkout -- file撤销无关文件很多时重新从干净的 commit 分支重跑不要让 Agent 继续在脏分支上工作。预防的办法也很便宜就是在任务描述里明确圈出“本次允许改动的文件列表”。我给有风险的项目加了一行仅允许改动 routes、models、views 下与本次需求相关的文件其他文件一律禁止触碰。8.2 写到后半段“失忆”编码 Agent 工作过程中还有一个概率不小的现象前十分钟它执行得又稳又准到了后十分钟开始反复在同一个文件里重复创建函数或者反复执行同一个测试命令好像忘记了已经验证过的事实。我把这个现象叫做“上下文漂移”。原因是长时间会话让早期信息被挤压Agent 的注意力越来越集中在最近的上下文里。它可能会在会话里创造一个功能但是因为没有把“该功能已完成”写进自己的状态摘要里就会出现重复劳动。这问题的解法往往不是“继续调试”而是“重启会话”。在一个新的会话里重新喂入关键背景文件和一个精简到只剩核心步骤的任务摘要通常比在旧会话里继续硬修要快也更不容易让问题连锁扩散。8.3 陷入死循环还有一种让人很崩溃的现象Agent 在修复某个测试失败时陷入无限循环。修 A 测试引入了 B 的失败修 B 后又导致 C 失败改完 C回头又把 A 弄挂了。几轮之后它仍然在转圈看起来没有停止的意思。我的经验里这种死循环多数时候不是因为测试设计得太烂而是因为 Agent 在缺乏“全局因果分析”的情况下盲目修症状而不是找源头。遇到这种情况最优解绝不是让它继续死磕。我会直接打断循环在上下文里抛出一条新的硬性指令请在当前状态下停止修改代码先用 5 分钟时间阅读这三个测试用例的完整调用链找出导致循环失败的根本原因然后输出你准备进行的根本性修复方案等确认后再执行。这一步常常能打破闭环让 Agent 从“局部打补丁”的模式跳出来切换成“分析全局后一次修复”的模式。8.4 测试全绿但功能一跑就挂这个场景应该是最令人血压飙升的。Agent 汇报说npm test全绿你往浏览器里一点页面直接 500 或者交互没反应。测试全绿和功能正确之间为什么会出现这么大的鸿沟大概率原因是 Agent 写的测试只是自证假象。它没有模拟真实运行环境或者测试数据是构造出来的实际使用时走了完全不同的分支。比如导出功能它只测了空数据列表的情况但你页面里真正需要导出几千条数据路由超时了、响应头没设置好、编码不一致这些问题在自动化测试里基本都测不出来。我的处理方法是永远把“跑一次真实功能”当作验收的最终一环。自动化测试通过只算“代码级通过”真正算数的验证是手动启动服务、打开页面、点一次按钮、看一眼导出的文件是否正常。Agent 可以帮你大幅减少重复劳动但这个最终验收动作至少当前阶段还是得人来兜底。9. 最后再分享一点我的个人体会如果说这半年高强度使用编码 Agent 带给我最大的改变是什么我觉得不是代码产量提升了多少而是思考方式被迫变得更清晰了。以前写一个功能我脑子里会有一个大概方向动手写的时候再慢慢修正细节边界条件经常写完才发现。但编码 Agent 逼着你在开始之前就得把目标、范围、约束、验收标准全想清楚否则它真的会在奇怪的分岔路上狂奔消耗你的时间精力。吴恩达这篇《Using Coding Agents》里那些观点之所以引起这么多共鸣我想也正是因为这个它讲的不是技术技巧而是一套更成熟的工程协作方式。真正能判断一个 Agent 用得好不好不再是你写了多少行代码而是你能不能让它把活干正确、把错误控制在可接受范围内。对一个从手动挡时代走过来的人这个转变需要一点时间适应但一旦适应你会发现自己关注的焦点从“会不会写”变成了“会不会交付”这个变化我觉得是好事。