1. AI 编码工具到底改变了什么1.1 从补全到代理的跨越这两年我身边不少同行都在讨论一个话题AI 写代码越来越强自己还有没有存在的必要。尤其是各种 Agent 工具出现之后从最早的代码补全到后来能读懂整个仓库、能自己跑测试、能提交 PR变化速度快得让人有点喘不过气。但我想先把一个概念理清楚因为很多人把两件事混为一谈。代码补全解决的是“这一行怎么写”的问题它本质上是一个更聪明的输入法。你敲一个函数名它帮你把参数和常见实现补上。而Agent解决的是“这个任务怎么完成”的问题它会自己拆解步骤、调用工具、读取文件、执行命令、根据结果调整下一步。这两者的差距就像计算器和会自己算账的会计之间的差距。我自己的感受是补全工具提升的是打字速度而 Agent 提升的是任务吞吐量。前者让你写得更快后者让你能同时推进更多事情。理解这个区别是讨论程序员价值的前提因为如果你只把自己定位成“写代码的人”那确实会被补全工具挤压但如果你能驾驭 Agent 去完成一整条任务链你的价值反而被放大了。1.2 被替代的到底是什么热搜里有个词叫“AI 或将取代初级程序员”这个说法我部分认同但需要拆开看。被取代的不是“初级”这个身份而是初级工作里那些高度模式化、缺乏判断的部分。比如照着设计稿写一个标准表单、把接口返回的字段映射到前端模型、写一个 CRUD 的增删改查这些确实越来越容易被自动化。但初级程序员成长过程中真正重要的东西——理解业务为什么这样设计、判断一个需求是否合理、在多个方案之间做取舍——这些恰恰是 AI 目前最不擅长的。我见过太多人把 AI 当成“帮我写完这段代码”的工具结果代码是写完了但没人能说清楚为什么这么写。这种用法等于主动放弃了自己最该积累的判断力。所以我的结论是AI 淘汰的不是初级程序员而是只会执行、不会思考的工作方式。你越早从“写代码的人”转向“定义问题、拆解任务、验收结果的人”就越安全。1.3 一个真实的心理转变我记得第一次用 Agent 自动修完一个 bug 并跑通测试的时候心里其实是有点慌的。那种感觉就像你苦练多年的手艺突然有人告诉你机器做得比你快。但冷静下来之后我发现Agent 修的那个 bug 是我定位的测试用例是我写的验收标准是我定的。它只是执行了中间那段最机械的部分。这个转变很关键从“我来做”变成“我来定义怎么做、做到什么程度算好”。一旦你站到这个位置上你会发现需要你操心的事情反而更多了——任务怎么拆、上下文怎么给、结果怎么验证、边界情况怎么覆盖。这些恰恰是 AI 做不了、也最需要人来兜底的地方。2. 程序员的新价值锚点在哪里2.1 定义问题的能力比解决问题更稀缺以前我们常说“程序员的核心能力是解决问题”但在 AI 时代解决问题的能力正在被工具快速商品化。真正稀缺的是定义问题的能力。什么叫定义问题就是把一个模糊的业务诉求翻译成一组清晰、可验证、边界明确的技术任务。举个例子产品说“用户反馈搜索太慢”。这句话本身没法直接交给 AI因为它太模糊了。你需要把它拆成是接口响应慢还是前端渲染慢是数据量大还是索引没建好是偶发还是必现慢到什么程度算不可接受这些问题的答案决定了后面所有工作的方向。AI 可以帮你优化 SQL但前提是你得先知道要优化哪条 SQL、优化到什么程度。我自己的习惯是在把任何任务交给 AI 之前先写一段“任务定义”包括目标、约束、验收标准、已知边界。这段文字往往比代码本身更有价值因为它逼着我把问题想清楚。很多时候写着写着就发现原来我以为的问题根本不是真正的问题。2.2 上下文组织是新的核心竞争力Agent 再强也需要你给它足够的上下文。它不知道你的项目历史、不知道哪些坑踩过、不知道哪些约定俗成的规矩不能破。这些信息如果不由你来组织AI 就会按它自己的理解去猜结果往往南辕北辙。我踩过的一个坑是让 Agent 去重构一个模块结果它把一段看起来“冗余”的代码删了而那段代码其实是为了兼容某个历史版本的客户端。它没有这个上下文所以做出了在它看来完全合理的决定。从那以后我养成了一个习惯在给 AI 任务之前先整理一份“背景说明”把不能碰的边界、必须保留的兼容逻辑、相关的历史决策都写清楚。这份背景说明的写法也有讲究。不能太长太长 AI 抓不住重点不能太短太短它又会漏掉关键约束。我的经验是控制在几百字以内用条目式列出“必须做”“不能做”“参考什么”。这其实就是在做上下文工程而这个能力目前来看是程序员相对 AI 的明显优势。2.3 验收与兜底的责任无法外包AI 可以写代码但它不能为代码负责。线上出了问题背锅的是人不是模型。所以验收能力变得前所未有的重要。你得能看懂 AI 写的代码能判断它有没有引入新的风险能设计出覆盖边界情况的测试。我见过一些团队用 AI 生成代码之后直接合并测试也不补结果上线后各种奇怪的问题。这不是 AI 的错是人的失职。AI 是一个执行力很强但判断力有限的助手它需要一个人来把关。这个把关的人就是程序员新的价值所在。具体来说验收包括几个层面逻辑是否正确、边界是否覆盖、性能是否可接受、安全是否有隐患、可维护性是否达标。每一项都需要你有足够的功底去判断。所以我说AI 时代不是不需要程序员了而是对程序员的要求从“会写”变成了“会判断”。3. 把 Agent 用出价值的实操方法3.1 任务拆解的颗粒度控制用 Agent 最忌讳的就是给一个太大的任务。你让它“重构整个用户模块”它大概率会给你一堆看起来合理但实际没法用的东西。正确的做法是把任务拆到单个可验证的单元。我的经验颗粒度是一个任务最好能在一次对话内完成产出的结果能用一条命令或一个测试验证。比如“把用户查询接口的响应时间从 800ms 降到 200ms 以内不能改变返回结构”这就是一个合格的任务。它有明确的目标、明确的约束、明确的验收标准。拆解的时候我会问自己三个问题这个任务的输入是什么输出是什么怎么判断做完了如果这三个问题答不上来说明任务还没拆到位。这个习惯看起来简单但能省掉大量来回沟通的成本。3.2 给 Agent 喂什么、不给什么上下文不是越多越好。给太多无关信息反而会干扰 AI 的判断。我的做法是分层给核心约束必给参考信息按需给无关信息坚决不给。核心约束包括技术栈版本、不能改动的接口、必须遵守的规范、已知的坑。这些是硬性边界必须让 AI 知道。参考信息包括相关的代码文件、类似功能的实现、相关的文档。这些可以帮助 AI 理解风格和模式但不是必须的。无关信息就是那些跟当前任务没关系的模块和文件给了只会增加噪音。我一般会先给核心约束然后让 AI 自己去读它需要的文件。现在的 Agent 大多有文件读取能力与其我手动贴一堆代码不如告诉它“去看 src/user 目录下的实现”。这样既省事又能保证它拿到的是最新的代码。3.3 迭代式推进而不是一次性交付很多人用 AI 的误区是希望一次对话就拿到完美结果。实际上迭代式推进的效果要好得多。我的做法是先让 AI 给一个粗略方案我看方向对不对方向对了再让它细化细化之后再让它补测试测试通过之后再让它优化。这个过程中每一步我都在做判断和纠偏。如果方向错了早发现早调整成本很低。如果等到最后才发现问题返工的成本就高了。这其实跟带新人的逻辑是一样的你不能指望新人一次就把事情做对但你可以通过及时的反馈让他快速逼近目标。我常用的一个话术是“先给我一个最小可行方案不要考虑优化能跑通就行。”这样 AI 不会过度设计我也能快速看到核心逻辑。等核心逻辑确认了再逐步加约束、加优化。3.4 让 AI 自己验证自己Agent 的一个强大之处是它能执行命令。这意味着你可以让它自己跑测试、自己看结果、自己修问题。我经常用的一个模式是让 AI 写完代码后自己运行测试如果失败就自己分析原因并修复直到测试通过为止。这个模式能省掉大量来回。但前提是测试必须可靠。如果测试本身写得有问题AI 就会在一个错误的方向上越走越远。所以我在让 AI 自验证之前会先确认测试用例是有效的、覆盖了关键路径的。测试是 AI 的“眼睛”眼睛不准它就会瞎走。4. 那些没人告诉你的坑4.1 AI 会自信地写出错误代码这是我最想强调的一点。AI 生成的代码语法通常没问题逻辑看起来也通顺但它可能是错的。而且它错的时候往往非常自信不会主动告诉你“这里我不确定”。我遇到过好几次AI 写的代码在正常路径下没问题但边界情况直接崩了。所以我的原则是AI 写的代码必须经过验证才能用。验证的方式包括跑测试、手动构造边界用例、代码审查。不要因为代码看起来漂亮就信任它。漂亮和正确是两回事。4.2 上下文丢失导致的“失忆”长对话中AI 会逐渐忘记前面的约束。你一开始告诉它“不要用某个库”聊到后面它可能就忘了又给你用上了。这不是它故意的是上下文窗口的限制。我的应对方法是关键约束反复强调。在每次让它产出代码之前把核心约束再列一遍。或者在项目里放一个约定文件让它每次先读这个文件。这样能大幅降低“失忆”带来的问题。4.3 过度依赖导致的技能退化这个坑比较隐蔽但影响深远。如果你长期只做“定义任务”和“验收结果”中间的实现过程全部交给 AI你自己的编码能力会慢慢退化。而编码能力恰恰是你做判断的基础——你没法验收你看不懂的东西。所以我的建议是保持一定比例的手写代码。尤其是核心逻辑、复杂算法、关键模块自己写一遍保持手感。AI 可以用来处理那些重复性的、模式化的工作但不要让它完全替代你的思考过程。4.4 安全问题不能交给 AI 判断AI 对安全问题的判断并不可靠。它可能会生成有注入风险的 SQL、可能会把敏感信息写进日志、可能会忽略权限校验。这些都需要人来把关。我一般会在验收清单里专门列一条安全检查包括输入校验、权限控制、敏感信息处理、依赖库漏洞。5. 常见问题速查问题可能原因解决思路AI 生成的代码跑不通上下文不足或版本不匹配补充技术栈版本和依赖信息让它先读相关文件AI 改坏了原有功能缺少边界约束明确列出不能改动的接口和行为长对话后 AI 开始跑偏上下文丢失关键约束反复强调或使用约定文件AI 写的测试覆盖不全没给测试要求明确要求覆盖正常路径、边界、异常代码看起来对但有隐患缺乏验证必须跑测试、做代码审查、检查安全AI 过度设计任务描述太宽泛要求先给最小可行方案再逐步优化6. 我自己的日常做法说了这么多分享一下我现在的日常工作流。早上到公司先花十几分钟把当天的任务列出来每个任务写清楚目标、约束、验收标准。然后挑出那些模式化的、重复性的部分交给 AI 去处理。核心的、需要判断的部分我自己来。AI 处理的过程中我不会干等着而是去推进其他任务。等它产出结果我集中做一轮验收跑测试、看代码、检查边界。有问题就打回去让它改没问题就合并。这样下来我一天能推进的事情比以前多了不少而且质量并没有下降。关键是我清楚哪些事该交给 AI哪些事必须自己扛。定义问题、组织上下文、验收结果、兜底责任这四件事我从来不外包。剩下的执行层面能交给 AI 的就交给 AI。这个分工让我既享受了效率提升又没有丢掉自己的核心竞争力。最后说一个我踩过的坑有一次我让 AI 去改一个涉及金额计算的逻辑它改完之后测试也过了我就直接合并了。结果上线后发现它在某个边界情况下用了浮点数运算导致金额出现了几分钱的误差。测试没覆盖到那个边界我也没仔细看。从那以后凡是涉及金额、权限、数据一致性的代码我一定逐行看不管 AI 说它有多确定。这种地方信任是有代价的。
