★ FEATURED ARTICLE 1. 先搞清楚AI Coding 到底是个什么东西1.1 从自动补全到能自己干活的实习生很多人第一次接触 AI Coding脑子里浮现的还是那种打几个字它帮你补全一行代码的印象。这个认知大概停留在两三年前。现在的 AI Coding Agent已经完全不是同一个物种了。我更愿意把它理解成一个超级聪明、博学多才、但需要你带一带的实习生。这个比喻不是随口说的它精准对应了三个特征第一它知识面极广主流语言、框架、设计模式、常见库的用法它基本都见过第二它理解能力很强你用自然语言描述需求它能翻译成可执行的代码第三它没有你项目的上下文不知道你们团队的规范、历史包袱和那些不能碰的坑所以需要你给它喂信息、划边界。所谓 AI Coding Agent核心区别在于Agent这个词。普通的代码补全工具是被动的你敲一个字符它猜下一个而 Agent 是主动的你给它一个任务它会自己规划步骤、读写文件、运行命令、看报错、再修改循环往复直到任务完成。这个感知—决策—执行—反馈的闭环才是它和传统工具的分水岭。1.2 它到底能帮你干什么活把能力拆开看一个成熟的 AI Coding Agent 通常覆盖这几类任务代码生成从零写一个函数、一个模块甚至搭一个项目骨架。代码理解读一个陌生仓库告诉你这个函数被谁调用、那个配置在哪里生效。重构与迁移把回调改成 Promise、把旧版本 API 升级到新版本、把一段逻辑抽成独立模块。调试排错把报错贴给它它能定位到具体行并给出修复方案甚至自己跑测试验证。测试编写根据现有代码补单元测试覆盖边界条件。文档与注释给函数补文档、给项目写 README。适合谁来用我的判断是有基础的人收益最大纯小白要谨慎。因为 Agent 会犯错而且错得很自信。你得有能力判断它给的东西对不对否则就是实习生把活干砸了你还看不出来。所以这篇内容的目标读者是写过一些代码、想提升效率、但还没系统用过 AI Agent 的开发者。1.3 一个必须先建立的预期在往下讲之前我得先把预期管理好。AI Coding Agent 不是许愿机。你说帮我做个淘宝它做不出来。但你说帮我实现一个商品列表接口用现有的 ORM返回分页数据字段按这个 schema它能做得又快又好。任务颗粒度决定了它的表现。颗粒度越细、约束越明确、上下文越充分产出质量越高。这个规律贯穿全文后面所有的技巧本质上都是在服务这一条。2. 核心原理拆解它为什么能自己干活2.1 Agent 的工作循环一个不断试错的闭环要理解 Agent 为什么强得先看它的运行机制。抛开各家实现细节一个 Coding Agent 的核心循环大致是这样的接收任务你给它一句自然语言指令。规划它把任务拆成若干子步骤决定先做什么。调用工具读文件、搜代码、执行命令、写文件——这些都是工具调用。观察结果看命令输出、看报错、看文件内容。修正根据结果调整下一步回到第 3 步。收敛直到任务完成或达到停止条件。这个循环里最关键的是工具调用能力。一个只能聊天的模型和一个能动手的 Agent差距是数量级的。因为能动手就意味着能验证——它写完代码可以自己跑一遍报错了能自己看这比盲写靠谱太多。提示判断一个 AI Coding 工具是不是真 Agent就看它能不能自主读写文件、执行命令。只能对话不能动手的本质还是聊天机器人。2.2 上下文窗口实习生的短期记忆有多大Agent 的另一个核心概念是上下文窗口你可以理解为它的短期记忆容量。你给它的所有信息——任务描述、读进来的文件、命令输出、历史对话——都塞在这个窗口里。这带来两个直接后果。第一窗口是有限的塞太多东西它会忘事或者开始抓不住重点。第二塞什么很关键你把整个仓库几万行代码全丢进去它反而找不到关键信息还不如精准地给它三个相关文件。所以实际使用中一个高频技巧是别让它自己瞎找你直接告诉它该看哪些文件。比如修改src/utils/date.ts里的格式化函数参考src/utils/number.ts的写法比帮我改一下日期格式化高效得多。这就是在帮实习生缩小搜索范围。2.3 工具调用它手里的工具箱不同 Agent 手里的工具集不一样但常见的无非这几类工具类型作用典型场景文件读取读取指定文件内容理解现有代码文件写入创建或修改文件生成新代码目录搜索按名称/内容查找定位相关文件命令执行运行 shell 命令跑测试、装依赖、构建网络检索查最新文档遇到不熟的库工具越多Agent 能做的事越多但出错的面也越大。比如命令执行这个工具如果 Agent 判断失误可能跑出一条删文件的命令。所以成熟工具一般都会加确认机制或者限制危险操作。你自己用的时候也要对它会执行命令这件事保持警觉。2.4 为什么它有时候很聪明有时候很蠢这个现象背后其实是信息充分度的问题。当任务描述清晰、上下文给足、约束明确时Agent 表现接近一个熟练工程师当任务模糊、上下文缺失时它就开始脑补而脑补出来的东西往往似是而非。我踩过的一个典型坑让它优化一下这个查询它二话不说加了个索引但那个表数据量很小加索引纯属浪费还拖慢了写入。问题不在它笨而在我没说清楚这个表读多写少还是写多读少、数据量级多大。它缺的是业务上下文不是技术能力。3. 实操上手从零跑通第一个 Agent 任务3.1 环境准备与工具选型思路工具选型这块我不点名具体产品只讲选择逻辑因为这类工具迭代太快今天推荐的明天可能就变了。你按这几个维度去挑是否支持工具调用能不能读写文件、跑命令这是硬门槛。上下文管理能力能不能自动检索相关文件还是全靠你手动喂。权限控制执行命令前要不要确认能不能设白名单。与现有工作流集成是独立 CLI还是嵌在编辑器里还是走 API。成本按 token 计费的长任务可能烧得比较快心里要有数。我的建议是先用一个集成度高的现成工具跑通流程别一上来就自己搭。自己搭 Agent 框架是另一个话题对扫盲阶段来说是过度工程。3.2 第一个任务让它读懂一个陌生函数别一上来就让 Agent 写大功能先做阅读理解练手。找一个你项目里稍微复杂点的函数让它解释。指令可以这样写请阅读 src/services/order.ts 中的 calculateDiscount 函数 用中文解释它的输入、输出、核心逻辑以及它依赖了哪些外部函数。 不要修改任何文件。注意最后那句不要修改任何文件——这是安全护栏。新手最容易犯的错就是没限制它的动作范围结果它顺手改了一堆东西。养成习惯只读任务明确说只读写任务明确说改哪个文件。跑完之后你对照自己的理解看它说得对不对。这一步的价值在于你能快速判断这个 Agent 的理解水平到底靠不靠谱为后续信任度打基础。3.3 第二个任务让它写一个独立的小函数理解能力验证完进入生成环节。挑一个边界清晰、依赖少的函数比如把秒数格式化成1h 23m 45s这种形式。指令模板在 src/utils/time.ts 中新增一个函数 formatDuration 输入是秒数number输出是形如 1h 23m 45s 的字符串。 规则 - 小时为 0 时不显示小时部分 - 分钟为 0 且小时也为 0 时不显示分钟部分 - 秒数始终显示 - 输入为负数时返回 0s 请同时补充对应的单元测试。这个指令好在哪规则列得清清楚楚边界条件都点到了。你会发现指令写得越像一份需求文档产出越接近你要的。这就是前面说的颗粒度。3.4 第三个任务让它修一个真实的 bug前两步是热身这一步才是日常高频场景。找一个你手头真实的、不太复杂的 bug把报错信息、复现步骤、相关文件一起给它。运行 npm test 时src/cart.test.ts 里的 should apply coupon 用例失败 报错是Expected 90 but received 100。 相关逻辑在 src/cart.ts 的 applyCoupon 函数。 请定位原因并修复修复后重新运行该测试确认通过。这里的关键是让它自己跑测试验证。这是 Agent 相比纯聊天工具最大的优势——它能闭环。你不需要自己复制报错再贴回去它自己就能看到结果并迭代。3.5 一次完整任务的现场记录我拿一个真实的小任务走一遍让你感受下节奏。任务给一个已有的 Express 接口加参数校验。第一轮我给的指令是给/api/user这个 POST 接口加参数校验name 必填且长度 2-20age 必填且是 0-150 的整数。Agent 先读了路由文件然后告诉我它打算用项目里已有的校验库问我要不要继续。这一步它做得对——先确认再动手。第二轮我确认后它改了路由文件加了校验逻辑。然后它自己跑了一下测试发现有个老测试因为新增校验挂了。它主动报告新增校验导致user.test.ts中一个用例失败因为该用例没传 age 字段是否需要我更新这个测试第三轮我让它更新测试。它改完测试全绿。整个过程我基本只做了三次确认。这就是 Agent 的威力——它把改代码—跑测试—看结果—再改这个循环自己跑完了我只在关键决策点介入。如果换成手动光是来回切终端跑测试就得花不少时间。4. 把 Agent 用好的关键技巧4.1 指令写法像写需求文档一样写 Prompt这是全文最重要的一节。Agent 的产出质量八成取决于你的指令质量。我总结了一个好指令的要素目标要做什么一句话说清。范围改哪些文件别碰哪些文件。约束用什么库、遵循什么规范、有什么边界条件。验收标准怎么算做完了比如测试通过。输出格式需要它给你什么比如只给 diff。对比一下差的指令帮我优化下这个函数。好的指令优化src/utils/parse.ts里的parseConfig函数目标是减少嵌套层级、提升可读性。保持函数签名和返回值不变不要引入新依赖。改完后确保parse.test.ts全部通过。后者几乎不会跑偏前者大概率给你一堆用不上的改动。4.2 上下文投喂给它刚好够用的信息前面提过上下文不是越多越好。我的经验法则是给直接相关的文件加上必要的背景说明别给整个仓库。具体操作上涉及具体函数直接把那个文件路径给它。涉及跨模块调用把调用方和被调用方都给。涉及业务规则用一两句话把规则说清楚别指望它从代码里猜。注意如果你发现 Agent 反复理解错同一个概念多半是上下文里缺了关键信息。这时候别急着骂它先想想是不是自己没交代清楚。4.3 分步执行大任务拆成小任务一个反直觉的结论让 Agent 一次做太多反而更慢。因为任务一大它规划容易乱中途跑偏了你还得回滚重来。正确做法是把大任务拆成有明确验收点的小任务一个一个来。比如给项目加用户认证这种大活拆成设计用户表结构写 migration。实现注册接口 测试。实现登录接口 测试。加鉴权中间件 测试。每一步做完确认无误再进下一步。这样即使某步出错影响范围也小回滚成本低。4.4 让它自己验证测试是最好的监工Agent 最大的优势是能自己跑验证。所以凡是能写测试的场景都让它写测试并跑通。这相当于给它配了个自动监工它自己就能发现错误并修正。我甚至会在指令里明确要求改完后运行相关测试如果失败请自行修复直到通过修复过程中不要修改测试的断言逻辑除非断言本身写错了。最后那句括号很重要否则它可能为了让测试通过直接把断言改宽松——这是典型的作弊行为。4.5 版本控制给 Agent 配一个后悔药这条是血泪教训。用 Agent 之前确保你的代码在版本控制里且工作区是干净的。这样它改砸了你一条命令就能回滚。更进一步可以让 Agent 每完成一个独立任务就提交一次。这样历史清晰出问题也好定位。我见过有人让 Agent 一口气改十几个文件结果中间某步错了想回退都不知道退到哪只能手动一个个改回来比不用 Agent 还累。5. 常见问题与避坑实录5.1 它改了我没让它改的文件怎么办这是新手最常遇到的惊吓。原因通常是指令里没限定范围Agent 为了把任务做好顺手改了它认为相关的地方。应对方法有三层预防指令里明确写只修改 X 文件其他文件不要动。拦截用带权限确认的工具每次写文件前要你点确认。补救靠版本控制回滚git checkout一下就好。如果已经改了先别慌用git diff看看它到底动了什么往往没你想的那么糟。5.2 它写的代码能跑但很丑Agent 生成的代码经常功能正确但风格诡异命名随意、嵌套过深、重复代码多。这不是它不会写好而是它不知道你的规范。解决办法是给它风格样本。在指令里加一句参考src/utils/format.ts的代码风格或者项目里放一个CONTRIBUTING.md说明规范让它读。很多工具会自动读取项目根目录的规范文件这个习惯值得养成。5.3 它陷入死循环反复改同一个地方有时候它会卡在一个错误上改了又错、错了又改来回好几轮。这通常是因为它没找到真正的根因只是在表面打转。这时候你要主动介入别让它继续烧 token。做法是打断它把更完整的报错或更明确的线索给它或者干脆自己定位到问题再让它执行修复。Agent 不是万能的卡住时人的判断力才是关键。5.4 常见问题速查表现象可能原因处理方式改了无关文件指令未限定范围明确文件范围用权限确认代码风格不符缺规范上下文提供风格样本或规范文件反复改同一处未找到根因人工介入补充线索测试被改宽松为通过而作弊指令中禁止改断言理解错需求上下文不足补充业务规则说明任务做一半停了上下文超限拆小任务分步执行引入不存在的 API模型幻觉要求它查文档或跑验证5.5 几个我踩过的坑坑一过度信任它的自信。Agent 说已修复不代表真修好了一定要看它有没有跑验证。我吃过一次亏它说改完了我直接提交结果 CI 挂了——它根本没跑测试。坑二让它处理它不熟的内部库。项目里如果有自研的框架或工具库Agent 大概率没见过会按通用套路瞎写。这种场景要么给它看源码要么自己写。坑三忽略 token 成本。长任务、大仓库、反复迭代token 消耗很快。养成习惯任务开始前想清楚要给它什么别让它自己漫无目的地搜。坑四在脏工作区上操作。前面说过这是最不该犯的错。我现在用 Agent 前第一件事就是git status确认干净。6. 影响范围AI Coding 改变了什么6.1 对个人开发者效率杠杆而非替代对个人来说AI Coding Agent 最大的价值是把重复劳动压缩了。写样板代码、补测试、查 API 用法、做机械重构这些事以前占掉大量时间现在可以交给它。你省下来的时间可以花在真正需要思考的地方架构设计、业务理解、疑难排查。但要说它替代开发者我不认同。它替代的是敲键盘这个动作替代不了判断该敲什么。判断力、业务理解、系统设计能力反而变得更值钱了因为执行层面的门槛被拉低了。6.2 对团队协作规范变得更重要团队里用 Agent会放大规范的价值。因为 Agent 是按你给的上下文干活的如果项目本身结构混乱、命名随意、没有文档Agent 产出的东西也会跟着乱。反过来一个规范清晰的项目Agent 能快速融入产出质量也高。所以我的观察是AI Coding 会倒逼团队把工程规范做扎实。这其实是好事。6.3 对技能要求从会写到会描述和验收技能重心在转移。以前强调手速快、记得住 API现在更强调两件事把需求描述清楚的能力和判断产出对错的能力。前者是沟通后者是基本功。基本功不扎实的人用 Agent 反而更容易翻车因为他看不出哪里错了。6.4 边界在哪它做不了什么最后划一下边界避免过度期待它不懂你的业务业务规则得你喂。它不承担后果代码上线出问题责任是你的。它不擅长模糊需求越模糊它越容易跑偏。它可能产生幻觉编造不存在的 API、配置、参数。它没有长期记忆跨会话的上下文需要你自己维护。把这些边界记牢你就能在它擅长的领域放心用它在它不擅长的领域保持警惕。我个人在实际操作中的体会是把 AI Coding Agent 当成一个能力很强但需要带教的实习生是最舒服的心态。别指望它一步到位也别因为它犯错就否定它。你给它清晰的任务、足够的上下文、明确的验收标准它回报你的效率提升是实打实的。反过来你含糊其辞、放任自流它也会用一堆似是而非的代码回敬你。这个工具的上限很大程度上取决于用它的人。
阅读完成 · 觉得有帮助？
