AI 写完了功能，谁来为凌晨两点的报警负责？

晚上十点四十七分，一位后端同事把一个需求丢给 AI：

“给订单接口加一个优惠券能力。沿用现有鉴权，补单测，别改支付链路。”

十几分钟后，AI 给出了一个分支：接口有了，表结构有了，单测也绿了。更顺手的是，它还补上了接口文档，PR 描述写得比不少人都要像样。

现在已经不稀奇了。Claude Code、Codex、Cursor 这类 Agent 工具，正在把开发从“问一句，补一段”推进到“给一个任务，交一个结果”。读仓库、查文档、改多文件、跑测试、提 PR，已经成为很多开发者的日常体验。

但真正让人停下来思考的，是同事接下来问的那句话：

“它写得这么快，我到底该看什么？”

这不是一个关于工具熟练度的问题。它指向了 AI 编程时代，每一个技术人心里那份共同的、不安的共鸣：如果代码可以被批量生成，程序员会不会变成最后那个只负责点“合并”按钮的人？如果不看每一行，我们怎么知道它没有埋雷？如果还要一行行看，那 AI 带来的效率又在哪里？

一个更深层的感受是，AI 编程真正改变的，不是写代码的速度，而是软件团队里“责任”这个词的含义。

代码生成得越快，工程判断越不能省

先说一个结论：AI 已经足够强，强到任何技术团队都不该再把它只当作自动补全工具；但它还远远没有强到可以被当作一个无需管理的“数字员工”。

问题在于，AI 的能力，太像一个效率极高的同事了。它会查资料、会模仿项目风格、会解释报错、会补测试。你很容易在第一轮结果里产生一种错觉：既然它做得这么完整，那我是不是只要验收结果就够了？

可软件工程最麻烦的部分，从来就不在“把正确代码写出来”这一步。

它在那些代码表面看不见的地方：优惠券和退款同时发生时，金额怎么算；一个消息重复投递三次，库存会不会扣三次；外部依赖超时后，数据是在重试、降级还是悄悄丢掉；新表上线后发现字段设计错了，能不能回滚；一段看似无害的查询，在高峰期会不会把数据库拖死。

这些问题并不神秘。每一个做过线上系统的人都遇到过。只是以前它们藏在人工开发的疏漏里，现在，它们可能被 AI 用更快的速度扩散到更多文件、更多服务里。

这正是 Agent 编程和传统代码补全最本质的区别。补全工具犯错，通常是一段代码错了；Agent 犯错，可能是一条任务链路在一个看似合理的计划下整体跑偏了。

Anthropic 在 2026 年初发布的《Agentic Coding Trends Report》里，把这种转变描述为 AI 从辅助工具向可委派协作者迁移。这个判断没有太多悬念。悬念在于，当“可委派”成为现实，我们是否已经准备好把任务说清楚、把边界画清楚、把验收做扎实。

AI 擅长执行。工程师要负责判断什么值得执行，以及执行错了会发生什么。

“能跑”这两个字，可能是 AI 编程里最危险的赞美

Vibe Coding 这个概念，火得很快，并非偶然。

把一个模糊想法说出来，几分钟看到界面、接口和数据流，确实让人上瘾。以前要排期、开会、等资源的内部小工具，现在一个人就能做出原型。以前卡在“我不会前端”或“我不会写脚本”的业务同事，也第一次拥有了把问题变成产品的机会。

这不是该被嘲笑的能力。它实实在在地降低了创造的门槛。

但我也见过，或者说，事实上，已经有不少案例：一个页面很好看、功能也能演示的产品，上线两周后开始出现重复数据；又过一周，用户发现自己能看到不该看到的信息；最后，团队发现没人知道那段权限逻辑为什么这么写，因为从需求到代码的中间过程，全被“AI 帮我搞定了”。

问题不在于代码来自 AI。问题在于，团队把“能跑”误当成了“可以交付”。

做原型时，最重要的是验证“这个需求值不值得做”；进生产时，最重要的是验证“它在异常、并发、攻击和变化面前还能不能活下来”。这两种工作需要的不是同一套标准。

这并非反对 Vibe Coding。恰恰相反，它应该被更认真、更审慎地使用：

它适合用来探索产品、验证方案、生成内部工具、补齐测试、处理边界清楚的改动；当它开始碰用户数据、金额、权限、支付、核心业务规则时，团队必须把它放回工程流程里。要有代码审查，要有自动化测试，要有安全扫描，要有发布门禁，也要有能找到责任人的变更记录。

这听起来很“慢”。但真正慢的，从来不是多跑一次测试，而是上线后花两周解释一场本可以避免的事故。

以后最值钱的，不是会不会写 Prompt，而是能不能给 AI 正确的上下文

过去一年，大家收藏了很多所谓“万能 Prompt”：怎么让 AI 写得更优雅，怎么让 AI 分步思考，怎么让 AI 自动修 Bug。

这些技巧当然有用。但进入真实项目后，你会发现，决定结果的往往不是那句提示词，而是 Agent 在动手之前，到底知道什么。

它知不知道这个项目的领域术语？知不知道某个接口虽然老旧却被三个下游系统依赖？知不知道为什么这里宁可多一次查询也不能读缓存？知不知道哪段逻辑绝对不能碰？知不知道“测试通过”在这个仓库里到底意味着什么？

举个例子，同一个模型，放进一个目录清楚、文档可信、测试完整的仓库里，像一个反应很快的新同事；放进一个约定散落在聊天记录、依赖互相咬住、谁都不敢动的仓库里，它就会变成一个异常自信的陌生人。

这就是 AI 编程最容易被忽略的成本：它没有消灭历史包袱，只是用一种更诚实、更让人无法回避的方式，暴露了这些历史包袱。

以前代码乱，资深工程师还能靠记忆和直觉勉强撑住。现在如果希望 Agent 真正替团队提速，就得把那些只存在于某个人脑子里的规则，变成能被读取、被校验、被继承的工程资产。

架构决策要写下来，接口契约要写下来，关键业务的反例要写下来，线上事故的教训也要写下来。不是为了把文档写得好看，而是为了让下一个人，或者下一个 Agent，不必靠猜。

Prompt 是一次性指令，上下文才是可复用的组织能力。

我们害怕的，或许不是 AI 写代码，而是自己突然不知道还能靠什么证明价值

这部分，我们不必假装轻松。

对刚入行的人来说，焦虑是具体而真实的：过去可以靠写 CRUD、修小 Bug、跟着项目把基本功练出来，现在这些任务被 AI 拿走了，成长路径会不会被截断？

对工作几年的人来说，焦虑同样具体：曾经花很多年形成的编码熟练度，会不会在几个月里变成一种不再稀缺的技能？

至于管理者，问题更直接：既然一个 Agent 能完成过去半天的活，是不是该少招人、少配人？

这些不是杞人忧天。AI 确实会压缩一部分重复劳动，也会重写一些岗位的入门任务。任何假装“完全没有影响”的乐观回答，都不够诚恳。

但从技术现场看，价值不是消失了，而是在往更靠近结果的地方移动。

今天真正稀缺的人，是能把一句模糊的业务诉求切成可执行任务的人；是能看出“看起来合理”的代码为什么会在边界条件下出错的人；是能设计监控、灰度、回滚，让系统出问题时仍有余地的人；也是在进度、成本、性能、安全之间，敢做取舍并且愿意承担后果的人。

AI 可以在一分钟生成几百行代码。但它无法替你判断一个需求到底该不该做，无法替你对用户数据签字，也无法替你在凌晨两点面对报警时说“这件事我来处理”。

程序员不会因为代码生成而失去价值。真正会被淘汰的，是只把自己定义为“把需求翻译成语法”的人。

别急着全员上 Agent，先把这件小事做对

如果你是技术负责人，最不建议的做法，是开一个会、买一批账号，然后宣布“从今天开始全员 AI 编程”。那只会让团队很快堆出一批更难维护的代码。

更务实的做法，是挑一个两周内能闭环的试点。比如：给历史模块补测试；把重复的运营配置流程做成内部工具；修复一类边界清楚的缺陷；同步接口文档。它应该允许回滚、验收标准明确、业务风险可控。试点结束后，不要先数“AI 写了多少行代码”。这个数字最漂亮，也最没意义。

不如问四个更不好回答的问题：交付周期真的缩短了吗？返工有没有变少？缺陷是更早发现了，还是被推迟到线上才发现？原本需要资深同事反复讲的知识，有没有被沉淀进仓库和流程里？

如果答案是肯定的，再扩大范围。否则，先修流程，再谈规模。

因为 AI 的上限，很大程度上，就是团队工程能力的上限。一个没有测试、没有边界、没有责任链路的团队，拿到再强的 Agent，也只是更快地把问题放大。

最后，别把方向盘交出去

AI 编程还会继续进化。Agent 会读更长的上下文，会调用更多工具，会完成更复杂的任务。未来我们敲的代码可能更少，审的方案、写的约束、做的判断会更多。

这既不是悲观，也不是鸡汤。这是软件工程本来就该有的样子：代码只是交付物的一部分，真正的工作，是在不确定里做出可靠的系统。

所以，别因为 AI 生成得快，就轻易把方向盘交出去；也别因为它会犯错，就假装这场变化不存在。

把 AI 当作速度，把工程当作护栏，把责任留在人手里。

这不是最酷的姿势，却是一个技术团队在热潮里不失速的方式。这，是一个值得每个技术团队认真思考的问题。