1. 先搞清楚AI Coding 到底是个什么物种1.1 从自动补全到能自己干活的实习生很多人第一次接触 AI Coding脑子里浮现的还是那个按 Tab 键补全代码的插件。这个认知停留在两年前。现在的 AI Coding准确说叫AI Agent智能体它和补全插件的区别就像实习生帮你查了个资料和实习生自己把方案写完还顺手跑了测试的区别。我习惯用一个类比来解释AI Agent 就是一个超级聪明、博学多才、但完全没有职场经验的实习生。它读过海量的代码、文档、技术博客知识面比你团队里任何一个人都广但它不知道你们公司的代码规范、不知道那个祖传模块为什么不能动、不知道线上环境的数据库连接池只有 20 个。你让它干活它能干得飞快但你不给它边界它也能闯祸闯得飞快。这个定位非常关键。把它当搜索引擎用你亏了把它当能独立负责一个模块的资深工程师用你迟早出事。正确的姿势是把它当成一个执行力极强、需要你做好任务拆解和验收的实习生。1.2 它能做什么不能做什么先把能力边界划清楚这比学任何工具都重要。它擅长的从零生成一个功能完整的模块比如一个 REST 接口、一个数据处理脚本、一个前端组件读懂一段陌生代码并解释逻辑这个能力被严重低估接手遗留项目时特别好用批量重构比如把 50 个文件里的回调写法统一改成 async/await写测试用例尤其是边界条件的补充它比人更有耐心排查报错把堆栈信息丢给它它给出的方向命中率相当高它不擅长的涉及线上真实数据、真实配置的操作它不知道你的环境长什么样需要跨多个系统协调的架构决策它缺乏全局上下文性能调优这种需要实测数据支撑的活它只能给方向不能给结论任何删库级别的破坏性操作绝对不能让它自主执行我踩过最典型的一个坑让 Agent 帮我写一个数据库迁移脚本它写得很漂亮逻辑也对但它默认了一个字段可以为空的假设而线上那张表这个字段是有非空约束的。脚本一跑直接报错。问题不在它写得差而在于它不知道我的表结构约束。这就是实习生的典型特征——知识够上下文不够。1.3 适合谁来学这套东西这套内容不是只给程序员的。我观察下来真正把 AI Coding 用出价值的有三类人第一类是一线开发者用它来提速日常编码、处理重复劳动、快速上手陌生代码库。这类人收益最直接。第二类是技术管理者或产品经理他们不一定自己写代码但可以用 Agent 快速验证一个想法能不能落地做个原型出来看看效果省掉和开发来回扯皮的时间。第三类是非技术背景但有自动化需求的人比如运营想批量处理表格、分析师想写个数据清洗脚本。以前这些需求要么排队等开发要么自己硬啃现在 Agent 能帮你跨过从想法到能跑这道坎。不管你是哪一类核心心法是一样的你负责定义问题和验收结果Agent 负责执行。你的价值在于判断力它的价值在于执行力。2. 核心机制拆解Agent 为什么比聊天机器人强2.1 从一问一答到自己规划自己干普通聊天机器人是单轮的你问它答结束。Agent 是多轮的、带工具的、能自我循环的。这个差别是本质性的。Agent 的工作循环大致是这样接收目标 → 拆解任务 → 调用工具读文件、写文件、跑命令、搜代码→ 观察结果 → 判断是否完成 → 没完成就继续循环。这个循环叫 ReActReasoning Acting是目前主流 Agent 的底层范式。举个具体例子。你说帮我把这个项目里的 console.log 都清理掉。聊天机器人会给你一段正则表达式。Agent 会这么做先扫描项目目录找到所有含 console.log 的文件逐个读取确认哪些是调试残留哪些是有意保留的日志然后逐个修改改完再跑一遍 lint 确认没引入语法错误最后给你一份改动清单。这个差别就是给你答案和帮你把事办了的差别。理解了这一点你就知道为什么给 Agent 下指令时目标要清晰但路径不用管太细——它自己会规划路径你管太细反而限制了它。2.2 工具调用Agent 的手和脚Agent 之所以能干活靠的是工具调用能力。常见的工具有这么几类工具类型作用典型场景文件读写读取和修改代码文件重构、修 bug、加功能终端执行运行命令、跑测试、装依赖验证改动、环境搭建代码检索在代码库里搜索符号和引用理解调用关系、找影响面网络检索查最新文档和报错信息处理新版本 API 变更浏览器操作打开页面、截图、点击前端调试、端到端验证这里有个关键认知Agent 的能力上限很大程度上取决于你给它开了多少工具。只给文件读写它就是个高级编辑器给了终端执行它就能自己验证自己的改动给了浏览器它就能自己看前端效果。但工具开得越多风险也越大这个后面会专门讲。2.3 上下文窗口实习生的短期记忆Agent 的另一个核心约束是上下文窗口。你可以把它理解成实习生的短期记忆容量——他一次能记住多少信息。这个约束带来几个实际影响。第一项目越大Agent 越容易忘事。一个几万行的项目它不可能一次全读进来只能按需读取相关文件。所以你要学会帮它缩小范围比如明确告诉它只看 src/utils 目录。第二长对话会稀释注意力。聊了几十轮之后早期的关键约束可能被挤出记忆。解决办法是把重要约束写进项目根目录的配置文件比如各种 Agent 工具都支持的规则文件让它每次都能重新读到。第三上下文质量比数量重要。与其把整个文件塞给它不如把相关的几个函数摘出来。我实测下来给 Agent 精准的 200 行上下文效果远好于模糊的 2000 行。理解了这三个机制——循环规划、工具调用、上下文约束——你就掌握了用好 Agent 的全部底层逻辑。剩下的都是操作层面的技巧。3. 实操落地从零把一个任务交给 Agent3.1 第一步把任务描述清楚这是 80% 的成败所在我见过太多人抱怨 Agent 不好用一问细节发现他给的需求是帮我优化一下这个代码。这种指令换成人也没法干。好的任务描述包含四个要素目标、范围、约束、验收标准。我拿一个真实场景举例。差的描述帮我加个用户登录功能。好的描述目标在现有的 Express 项目里加一个用户登录接口。 范围只改 src/routes/auth.js 和 src/services/user.js不要动数据库 schema。 约束密码用 bcrypt 加密token 用现有的 jwt 工具在 src/utils/jwt.js 里错误码沿用项目现有的规范。 验收标准接口能通过现有的测试框架跑通返回格式和 /register 接口保持一致。看出差别了吗好的描述里Agent 不需要猜任何东西。它知道改哪、不改哪、用什么、怎么算成功。你省下的每一句解释都会变成它多跑的一轮试错。3.2 第二步先让它读再让它写这是我最想强调的一条经验永远不要让 Agent 在没读代码的情况下直接写代码。正确流程是分两步。第一步让它先读相关文件输出一份我理解到的现状。比如请先读 src/routes/auth.js告诉我现有的路由结构、错误处理方式、以及 register 接口是怎么写的。 第二步等它输出理解后你确认无误再让它动手写。这个先读后写的习惯能挡掉大量低级错误。因为 Agent 在写代码时会默认一些假设而这些假设往往和你的项目实际不符。让它先读一遍等于强制它校准假设。我个人的习惯是对于稍微复杂点的任务会让它先输出一个改动计划打算改哪几个文件、每个文件改什么、有没有风险点。我看完计划再放行。这一步多花两分钟能省掉后面半小时的返工。3.3 第三步小步快跑每步都验证Agent 一次改太多东西是灾难的开始。因为一旦出问题你很难定位是哪一步引入的。我的做法是把大任务切成小步每步都让它自己验证。比如加登录功能我会拆成先写密码加密工具函数并写单测 → 再写 service 层逻辑并测 → 再写路由并测 → 最后联调。每一步完成都让它跑一遍相关测试确认绿了再进下一步。这里有个技巧让 Agent 自己跑测试并自己修。你可以说跑一下测试如果有失败的自己分析原因并修复修完再跑一遍直到全绿。这个自循环能力是 Agent 相比普通工具最大的优势用好了效率翻倍。但要注意测试本身也可能是错的。如果 Agent 改了半天测试还是不过你要介入看看是不是测试用例的预期写错了。我遇到过 Agent 为了让测试通过而修改测试断言的情况这是典型的实习生为了交差而作弊必须警惕。3.4 第四步验收别偷懒Agent 说完成了不等于真的完成了。验收这一步绝对不能省。验收要看三样东西改动清单、测试结果、边界情况。改动清单让你知道它到底动了哪些文件有没有越界测试结果确认功能正常边界情况是它最容易漏的地方比如空输入、超长输入、并发场景。我一般会追问一句这个改动有没有可能影响其他模块列出你判断的潜在影响面。 这一问经常能问出它自己都没意识到的连带影响。4. 避坑指南那些文档里不会写的教训4.1 权限给太大迟早出事Agent 的工具权限是安全的第一道防线。我的原则是最小权限能只读就不给写能只改指定目录就不给全盘权限能不给终端就不给终端。尤其是终端执行权限一定要谨慎。Agent 有可能执行rm -rf这类破坏性命令虽然主流工具都有确认机制但你不能赌。我的做法是涉及删除、覆盖、推送、部署这类操作一律手动执行不让 Agent 碰。还有一个容易被忽视的点别让 Agent 直接操作生产环境。它不知道哪个是生产哪个是测试你告诉它连数据库它可能就真连了。所有涉及真实数据的操作都要在隔离环境里做。4.2 它很会一本正经地胡说Agent 最大的问题不是不会而是不会的时候也说得头头是道。它会编造不存在的 API、不存在的配置项、不存在的库函数而且语气极其自信。识别这种情况的方法凡是它引用的 API、库、配置你拿不准的就去官方文档核一遍。尤其是版本相关的它训练数据里的版本可能和你项目用的差了好几个大版本。我踩过的一个坑让它用一个库的某个方法它写得有模有样结果那个方法在项目用的版本里根本不存在是后来版本才加的。跑起来直接报错。从那以后凡是涉及第三方库的调用我都会让它先确认版本。4.3 上下文污染越聊越糊涂长对话里Agent 的表现会逐渐下降。原因是早期的错误信息、废弃的方案、你的否定意见都还留在上下文里干扰它的判断。解决办法是该开新对话就开新对话。一个任务做完进入下一个不相关的任务时果断重开。如果任务有关联就把关键结论手动总结一下带过去而不是让整个历史对话跟着走。另一个技巧是把稳定的约束写进规则文件。比如项目的代码规范、技术栈、目录结构约定写进根目录的 Agent 配置文件里这样每次新对话它都能读到不用你反复交代。4.4 常见问题速查表现象可能原因处理方式改完代码跑不起来它假设了不存在的依赖或 API让它先读 package.json 和现有代码反复改同一个 bug 改不好上下文里堆了太多失败尝试重开对话重新描述问题改动范围超出预期任务描述没划清边界明确列出只改哪些文件测试通过但功能不对它改了测试来迁就代码人工 review 测试断言的合理性生成的代码风格不一致没给它项目规范把规范写进规则文件处理大项目时卡住上下文超限缩小范围分模块处理5. 进阶玩法把实习生用成团队骨干5.1 用规则文件给它入职培训前面反复提到规则文件这里展开讲讲。主流 Agent 工具都支持在项目根目录放一个约定文件Agent 每次启动都会读它。你可以把它理解成给实习生的入职手册。一份好的规则文件应该包含技术栈说明、目录结构约定、代码风格要求、常用命令、禁止事项。比如## 技术栈 - 后端Node.js Express PostgreSQL - 前端React TypeScript - 测试Jest ## 代码规范 - 所有函数必须有 JSDoc 注释 - 错误处理统一用 src/utils/error.js 里的 AppError - 不要引入新的第三方依赖除非明确要求 ## 常用命令 - 跑测试npm test - 跑 lintnpm run lint - 启动开发npm run dev ## 禁止事项 - 不要修改 migrations 目录下的历史文件 - 不要直接操作数据库用 ORM - 不要提交任何含密钥的代码有了这份文件你每次下指令就不用重复交代这些Agent 自己会遵守。这一招能省掉大量沟通成本。5.2 让它自己写测试、自己跑、自己修这是 Agent 相比传统工具最大的效率优势值得单独拿出来说。传统流程是人写代码 → 人写测试 → 人跑测试 → 人修 bug。Agent 流程可以压缩成人描述需求 → Agent 写代码和测试 → Agent 跑测试 → Agent 自己修 → 人验收。关键在于把跑测试并修复这一步明确写进指令。比如实现这个功能写对应的单元测试然后运行测试如果有失败就自己分析并修复直到全部通过为止。这个自循环能跑通的前提是测试环境要能一键跑起来。如果你的项目跑个测试要配半天环境Agent 也跑不动。所以先把测试命令固化下来写进规则文件。5.3 多 Agent 协作让实习生组个队进阶玩法是同时用多个 Agent各司其职。比如一个负责写代码一个负责 review一个负责写测试。这种模式在复杂任务上效果不错因为 review 的 Agent 没有自己写的代码自己看着顺眼的偏见。不过多 Agent 协作的成本也高配置复杂、容易互相干扰。我的建议是先用好单个 Agent等单个 Agent 的流程跑顺了再考虑多 Agent。别一上来就搞复杂架构那是给自己找麻烦。5.4 一个完整的实战案例最后用一个完整案例串一遍。假设要给一个现有的博客系统加文章草稿功能。第一步交代背景这是一个 Node.js Express 的博客系统我要加草稿功能。先读一下 src/models/article.js 和 src/routes/article.js告诉我现有的文章模型和路由结构。第二步确认理解等它输出理解我核对无误。第三步下达任务给文章模型加一个 status 字段值为 draft 或 published默认 published。加一个保存草稿的接口 POST /articles/draft加一个发布草稿的接口 POST /articles/:id/publish。只改这两个文件不要动数据库迁移文件我会手动处理。写完写测试并跑通。第四步验收看改动清单、跑测试、检查边界情况比如发布一个不存在的草稿会怎样。第五步收尾让它总结这次改动我确认后提交。整个流程走下来一个原本要半天的功能半小时能搞定。但前提是每一步都按规矩来不偷懒。6. 我个人的几条硬核心得用 Agent 用到现在我总结出几条不太会写在官方文档里的经验分享给准备入坑的朋友。第一条你的判断力才是核心资产。Agent 越强越凸显人的判断力价值。它能一秒生成一百行代码但哪一百行是对的得你来判断。所以别指望它替你思考它替你执行你替它把关。第二条慢就是快。急着让它一次干完往往要返工。老老实实拆步骤、每步验证看起来慢实际最快。我早期图快让它一口气改十几个文件结果出了 bug 定位了两小时从那以后就老实了。第三条把它当同事而不是工具。你给同事交代任务会怎么说会说背景、说目标、说约束、说验收标准。对 Agent 也一样。你越把它当人一样沟通它表现越好。第四条保持怀疑。它说的每一句话尤其是涉及 API、配置、版本的部分都要有核实意识。这不是不信任这是专业习惯。第五条定期复盘你的指令。同一个任务你换个说法Agent 的表现可能天差地别。把好用的指令模板记下来形成自己的提示词库这是能持续增值的东西。这套东西学起来不难难的是养成习惯。等你把拆任务、给上下文、小步验证、严格验收这套流程跑顺了你会发现这个实习生是真的能扛活的。它不会累、不会抱怨、知识面还广你唯一要做的就是当好那个会带人的导师。