AI 编程神器真能替掉程序员？我的结论是短期是不可能的，不要停留

                在玩具层面的自嗨。
最近 AIGC、大模型这些东西火得一塌糊涂，尤其是那个 Generative AI（生成式人工智能），特别是里面的 LLM（大语言模型），简直是刷爆了朋友圈和技术圈。

跟很多写代码的兄弟姐妹一样，我也是既兴奋又有点懵。兴奋的是，哇塞，这玩意儿看起来能干好多事啊！懵的是，这……以后咱们程序员这行当，到底会变成啥样？饭碗还稳吗？
今天就先来聊聊最近挺火的 “Agent Coding”（智能体编码）助手。
AI 编程助手：是“神器”还是“麻烦制造机”？
现在市面上涌现了不少号称能“自动编程”的 AI 助手，像 Cursor、Windsurf、Cline 这些工具都推出了所谓的 “Agentic Mode”（智能体模式）。听起来特牛，好像你只要动动嘴皮子，它就能唰唰唰帮你把代码写好。

有些声音甚至喊出：“一年后就不需要程序员了！” 也有人比较担心：“AI 写的代码靠谱吗？新手程序员以后怎么培养啊？”
过去这几个月，我可是没少用这些工具的智能体模式。注意，我主要不是让它们从零开始写个“俄罗斯方块”小游戏（那种演示性质的），而是用它们来修改我们手头已有的、实实在在的项目代码库。
不得不说，最近这些工具跟 IDE（就是咱们写代码的编辑器，像 VS Code、IntelliJ IDEA）的集成做得是真好，进步神速！这种集成让 AI 助手的能力一下子提升了好几个档次：
1. 能跑测试、干杂活： 你让它改代码，它能自己跑测试，发现报错了还能试着自己修。
2. 自动检查代码规范： 什么代码格式不对（Linting）、编译不过去，它都能发现并尝试修复。
3. 会上网查资料： 遇到不懂的，它还能自己上网搜。
4. 有的还能看浏览器效果： 甚至有些工具能集成浏览器预览，帮你检查网页控制台报错，或者看看页面元素对不对。
这么一套组合拳下来，有时候跟 AI 合作起来效率是真的高，感觉嗖嗖地就能搞定一些功能或者解决掉一些疑难杂症，时间快得让人惊喜。
但是！注意，重点来了！
即使是在那些看起来很成功的合作里，我也没闲着。我得不停地介入、纠正、引导 AI 的方向。而且，很多时候，忙活半天，最后我一看，“嗯……这代码还是别提交了”。
为啥呢？今天我就来跟大家唠唠，在我用这些 AI 编程助手的时候，到底在哪些地方需要我这个“老司机”出手“把方向盘”。通过这些具体的例子，咱们来看看，在目前这种“有人监督的智能体”模式下，程序员的经验和技能到底扮演了什么角色。
这些例子也说明了，虽然 AI 进步很快，但要说它能独立自主地搞定稍微复杂点的编程任务，那还差得远呢。同时，我们也能从中看到，未来一段时间内，咱们程序员需要具备哪些硬核技能。这些技能，才是我们需要继续保持和培养的。
AI 编程助手容易在哪些地方“翻车”？
事先声明哈，不是说 AI 工具在下面这些方面“总是”不行。有些问题，你多跟它啰嗦几句（调整 Prompt），或者加点自定义规则，确实能缓解。但注意，只是缓解，不是根治。LLM 这家伙吧，经常不完全听话，你指令写得再细，它也可能“选择性失聪”。而且，一次编程对话越长，它就越容易“抽风”，时灵时不灵。所以，下面我列的这些“坑”，发生的概率绝对不低，不管你 Prompt 写得多牛，集成了多少上下文信息。
我把这些 AI 容易犯错的地方，按照影响范围分了三类，想象成三个同心圆：
1. 影响范围一：拖慢开发速度（Commit 层面）：本来想让它加速，结果帮了倒忙，甚至这代码都没法提交。
2. 影响范围二：给团队添堵（Iteration 层面）：代码倒是提交了，但在当前这个开发迭代周期里，给团队协作带来了麻烦。
3. 影响范围三：埋下技术债（Codebase Lifetime 层面）：短期看没问题，代码也能跑，但给整个项目的长期维护挖了坑。
影响范围越大，问题暴露出来需要的时间就越长，也就越难搞。
坑1：当时就卡壳，还不如自己写 (影响半径：Commit 层面)
这是最直接的翻车现场，AI 没帮上忙，反而碍事了。不过这也是问题最小的一类，因为问题很明显，你大概率不会把这些“残次品”代码提交上去。
• 代码压根跑不起来： 有时候 AI 生成的代码就是有 Bug，跑不通。这时候就得靠我的经验了：要么快速定位问题把它改对，要么及时止损，判断出这路子不行，赶紧放弃，重新跟 AI 沟通或者干脆自己撸起袖子写。
• 问题诊断错误（瞎指挥）： AI 经常会搞错问题的根源，然后在一个错误的方向上使劲。比如有一次，它以为 Docker 构建失败是因为架构设置问题（比如在 M1 Mac 上构建 x86 镜像），然后就去改 Dockerfile 里的平台设置。但实际上呢？问题出在把一个本地环境（比如 M1）npm install 出来的 node_modules 文件夹，错误地拷贝进了目标架构（比如 x86）的 Docker 镜像里。这种问题我遇到过 N 次了，一眼就能看出来，赶紧把它从错误的“兔子洞”里拉回来。如果没经验，可能就跟着 AI 一起绕进去了。
坑2：代码是能跑，但团队要遭殃 (影响半径：Iteration 层面)
这类问题是，如果你不仔细审查、及时干预，代码提交上去后，会在当前的开发周期里给团队其他人带来麻烦。我有多年在不同团队交付的经验，踩过不少类似的坑，所以能在提交前发现并修正。我猜，即使有了 AI，新手程序员可能还是得通过踩这些坑、吃这些亏来学习成长，跟我当年一样。问题是，如果 AI 大大提高了“产出”这些“坑”的效率，团队还能不能扛得住？
• 搞一堆“半成品”（不按步就班）： AI 有时候喜欢“摊大饼”，不是一步步、一小块一小块地实现能跑起来的功能，而是一上来就想搞个大动作。比如，做前端技术栈迁移，它可能尝试一次性把所有 UI 组件全转了，而不是先搞定一个组件，再做通一个包含前后端的完整“垂直切片”。这样做的风险是，可能搞了半天，才发现选的技术路线有问题，或者某个功能需求理解错了，前面的大量工作都白费了。
• 暴力修复不治本： 遇到问题，AI 有时候会用简单粗暴的方法“解决”，而不是去分析问题的根本原因。比如，Docker 构建时报内存不足错误，它可能会直接去调大 Docker 的内存配置，而不是去想想：“为啥这次构建需要这么多内存？是不是代码或者依赖有问题？” 这就把真正的问题掩盖了，留给了后面接手的同事，那时再查问题就更难了，因为缺少了当时的上下文。
• 搞乱开发流程： 有一次，AI 生成的构建流程搞得开发体验极差。比如，本来一个命令就能同时启动前后端服务，它非要搞成两个命令；或者改了代码，页面不能自动刷新（Hot Reload 失效了）；还有搞出一些极其复杂的构建配置，连我和 AI 自己都绕晕了。这些改动一旦提交，立马就会影响到团队其他成员的日常开发效率。
• 还有处理 Docker 构建错误时，没考虑到怎么能在构建早期就发现这些错误，而是等到后面才报错，浪费时间。
• 需求理解错漏： 如果我给的需求描述不够详细，AI 就容易“自由发挥”，做出错误的功能。发现并纠正这个问题不一定需要多深的开发经验，但需要足够细心。但我发现这种情况挺常见的。这恰恰说明了，如果完全让 AI 自主工作，没有开发者在旁边盯着、在早期就介入，很可能会在功能层面跑偏。无论是开发者自己没想清楚，还是完全自主的 AI，这种理解偏差都会在项目后期才被发现，导致大量的返工和沟通成本。
坑3：埋下技术债，以后慢慢还 (影响半径：Long-term Maintainability 层面)
这是最“阴险”的一类问题，因为它的反馈周期最长，可能要过几周甚至几个月才暴露出来。这类代码，眼下能跑，功能也没错，但未来修改起来会越来越难。不幸的是，这恰恰是我这 20 多年编程经验发挥最大作用的地方。
• 测试写得又多又烂： AI 写测试用例有时候挺溜的，但我也经常发现它喜欢创建一堆新的测试函数，而不是在现有的测试函数里加断言（Assertions）。或者加了太多重复的断言，别的测试用例已经覆盖过的点，它又测一遍。对于经验不足的程序员来说，可能会觉得“测试越多越好”，但实际上不是！重复的测试和断言越多，维护起来就越困难，测试代码也越脆弱。最后可能导致，开发者稍微改动一点代码，就有一大片测试失败，增加了巨大的维护负担和挫败感。我试过用自定义指令来约束它，但效果不佳，这种情况还是经常发生。
• 代码不复用（到处复制代码）： AI 生成的代码有时候缺乏模块化思维，导致同样的功能或逻辑在代码库里出现多次。
• 比如，它没意识到某个 UI 组件在别处已经有了，于是又重新实现了一遍，造成代码重复。
• 比如，在写 CSS 样式时，它喜欢用内联样式（inline styles），而不是推荐的 CSS 类（classes）和变量（variables），这让后续的样式统一修改和维护变得困难。
• 代码写得贼复杂（过度设计/冗余）： 有时候 AI 会生成过多、过复杂的代码，我得手动去删减那些不必要的部分。这些代码要么是技术上非必需的，增加了理解和修改的难度；要么是实现了超出当前需求的、用不上的功能，增加了不必要的维护成本。
• 比如，每次让 AI 帮我改 CSS，我事后都得花时间去一行行删除大量冗余的样式规则。
• 比如，有一次让它生成一个 Web 组件来动态展示 JSON 数据，结果它搞了个非常精巧、功能全面的版本出来，但当时我们根本不需要那么复杂的东西。
• 比如，在做代码重构时，它没能识别出项目里已经存在的依赖注入（Dependency Injection）关系，引入了不必要的额外参数，让代码设计变得更脆弱、更难理解。打个比方，它给某个服务的构造函数加了个新参数 value，但这个 value 其实可以通过已经注入的另一个服务 service_a 来获取 (value = service_a.get_value())，完全没必要再传一遍。正确的做法可能是 ServiceB(service_a)，然后在 ServiceB 内部需要时调用 service_a.get_value()。AI 却搞成了 ServiceB(service_a, value=value)，这就画蛇添足了。
那么，AI 到底能不能取代程序员？
基于我上面这些实实在在的踩坑经验，在我个人的想象范围内，一年内 AI 能自主编写 90% 的代码？这绝对不可能。
那 AI 能辅助我们写 90% 的代码吗？ 嗯……也许吧。对于某些团队、某些代码库来说，或许可以。就我目前在一个复杂度中等、规模不算太大（大约 1.5 万行代码）的项目上的体验来看，它大概能在 80% 的情况下给我提供辅助。
注意，是辅助！不是替代。
怎样才能用好 AI 编程助手，同时又避免踩坑？
既然 AI 助手这么“调皮”，我们该怎么做，才能在享受它带来的便利的同时，保护好我们的软件项目和团队呢？
对于咱们开发者个人：
1. 永远、永远仔细审查 AI 生成的代码。 我很少遇到完全不需要修改或改进的 AI 代码。
2. 感觉不对劲就停下来。 如果你觉得 AI 的操作让你看不懂、跟不上，或者场面开始混乱，果断暂停。要么调整你的指令，重新开始一次会话；要么干脆切换回“纯手工编码”模式——我同事 Steve Upton 管这叫“手作代码”（artisanal coding），挺形象的。
3. 警惕“看起来还行”的陷阱。 有些方案 AI 很快就给出来了，好像很完美，但可能隐藏着长期的维护成本。别为了追求速度而牺牲质量。
4. 坚持结对编程（Pair Programming）。 两个人看代码总比一个人强，两个大脑思考也比一个大脑更容易发现问题，不容易自满。
对于团队和组织：
1. 用好代码质量监控工具。 如果还没用上 Sonarqube、Codescene 这类工具，赶紧搭起来。它们能帮你发现代码里的“坏味道”（code smells）。虽然不能发现所有问题，但这是个重要的安全网。特别注意 AI 容易引发的某些问题，比如代码重复，要加强监控。
2. 善用 Pre-commit 钩子和 IDE 集成的代码检查。 尽可能把问题扼杀在摇篮里（Shift-left）。很多工具可以在提交代码前、代码评审时（Pull Request）、甚至在 CI/CD 流水线里检查代码、运行 Lint、进行安全扫描。但在开发过程中就能发现问题，总是最好的。
3. 重温并强调好的编码实践。 针对上面提到的这些坑，以及团队遇到的其他问题，建立一些固定的仪式或活动，反复强调那些能够减少“Iteration 层面”和“Codebase Lifetime 层面”风险的最佳实践。比如，可以搞个“踩坑日志”（Go-wrong log），记录下 AI 代码导致团队摩擦或影响可维护性的事件，每周一起回顾反思。
4. 利用好自定义规则。 大多数 AI 编程助手都支持配置规则集或指令，这些规则会随着你的每个请求一起发送给 AI。团队可以一起维护一套基础的指令，把好的实践固化下来，尝试减少 AI 犯错。但就像前面说的，不能保证 AI 100% 听话，尤其是在长对话中。
5. 营造信任和开放沟通的文化。 我们正处在一个技术剧烈变革的过渡期，每个人都是新手和学习者。拥有信任和开放沟通文化的团队，能更好地学习和应对这种变化带来的不确定感。举个反例，如果组织因为“你们现在有 AI 了”就给团队施加巨大压力，要求更快交付，那么开发者就可能为了赶进度而牺牲代码质量，前面提到的风险就更容易发生。相反，在高信任度和心理安全的团队里，开发者会更愿意分享使用 AI 时遇到的困难，帮助整个团队更快地学习如何最大化利用这些工具。
好了，今天就先跟大家唠这么多。AI 编程助手确实是把双刃剑，用好了能提效，但前提是你得有能力驾驭它，知道它的脾气和局限。技术一直在变，咱们程序员的核心竞争力，可能恰恰在于这种不断学习、适应和掌控新工具的能力。
下次有机会，再跟大家聊聊别的。回见！