AI 替代程序员，先别急着转岗

我注意到一个有意思的细节。这次中国软件行业协会副理事长兼秘书长吕卫锋回应“AI 替代程序员”，用了“高度重视”，也提到支持从业人员向高附加值岗位转型。放在行业语境里，这更像把问题从“模型能不能写代码”往前推了一步，推到岗位、组织、产业分配。这个方向值得投入，但投入之前，得先把组织账算清楚。

我带过百人团队，现在也还在看 AI 平台、CI、测试流水线和算力成本。过去一个月，我把 Copilot、Claude Code、Kimi K3、腾讯混元 Hy3 这些工具接进日常研发流程，这几天又把测试流水线挂到 CI 上跑。结果很直接，代码生成速度确实上来了，但团队并没有因此轻松。很多返工并没有消失，只是换了位置。以前是人写错逻辑，现在是 AI 给出一个看起来合理、边界条件却没人兜底的实现。以前是需求没对齐，现在是需求没对齐的情况下，代码量明显增加，评审压力也上来。

这就是为什么我不太愿意把“AI 替代程序员”理解成岗位消失。更准确地说，它先替代的是工程流程里模糊、重复、缺少验收的部分。梅宏院士那个判断我觉得有分量，历史上编程方法和工具一直在演变，每一轮都改变过分工。AI 这轮不同在于，它开始进入“实现”本身，把原本靠经验堆出来的初阶编码、样板代码、接口胶水，压到很低成本。于是组织里稀缺的，是能把业务规则、系统边界、风险责任、验收标准说清楚的人。

所谓高附加值岗位，不能只停留在口号里。我这边看下来，至少有三类工作会被抬起来。一类是需求与领域规则的 owner。金融、医疗、工业、车企里的隐性规则，模型很难自己补全。它能把一个函数写得像那么回事，但不知道一个审批流为什么不能跳步，也不知道某个灰度策略为什么会让下游系统雪崩。另一类是评测和验收体系的设计者。我上周写过一篇单人 AI 开发，标题大意是先别急着当团队模板，原因也在这里。一个人靠 AI 跑通 demo，不等于团队可以照搬。团队要的是可复现的测试、可追溯的缺陷、可量化的上线门槛。还有一类是 AI 时代的平台工程。权限、算力、日志、观测、回滚、成本，这些看起来不性感，却决定 AI 能不能从玩具变成生产力。

所以看新闻里“向高附加值岗位转型”，我更关心企业怎么落地。很多公司一听 AI，先问能不能减少人头。这个问法太粗。我更关心 ROI 算过没有。如果 AI 只是让初级工程师少写一些样板代码，却让资深工程师花更多时间做安全审查，那它可能只是把成本从编码挪到了维护。反过来，如果团队能借 AI 把接口文档、测试用例、需求追踪、发布检查表整理下来，哪怕人头不减，交付周期和事故率也可能改善。管理上看，前者是省小钱亏大钱，后者是慢功夫，但方向对。

我最近也看到不少岗位焦虑，讨论哪些开发先被替代。说实话，这种排序容易把问题简化。先被压缩的，往往是某类工作方式，比如只等明确需求、只做 CRUD、只靠复制粘贴、不碰线上责任、不写验收标准、不做复盘。AI 对这类工作的效率提升很快，因为输入输出边界如果清楚，模型确实能替人跑完。但一旦输入模糊，输出又需要承担责任，AI 就不那么好用。它会把人推到更不舒适的位置，逼着人把脑子里的“差不多”变成机器能执行的规则。

对企业来说，这个变化对组织结构的要求比对个人更高。以前很多知识锁在老员工脑子里，需求、历史包袱、灰度策略、客户口头承诺，都靠人传。AI 来了以后，这些隐性知识如果继续不显性化，就会变成事故来源。我甚至觉得，未来团队管理要像管多 Agent 系统一样，给每个角色设边界、权限、验收和失败归责。否则，多 Agent 协作听着先进，实际只是成本放大器。这个判断也适用于人。组织不会因为你用了几个模型，就自动变聪明。

从个人角度，我也不建议一听到转型就急着去报一堆课程。先把当前工作里的价值链条拆开看。你现在产出的到底是代码，还是决策，还是信任。如果只是代码，AI 确实会压价。如果你能定义问题，能判断风险，能让业务和技术对上，能让系统上线后不出大事，那转型空间就在眼前。高附加值要看自己能否把判断力变成团队可复用、可验证、可追责的资产。

这件事往后看，不会很快有统一答案。行业协会表态“高度重视”，说明它已经超出技术圈内部讨论，进入产业预期和人才政策层面。对企业来说，更务实的是别把 AI 当裁员理由，也别把它当万能药。先从一个项目、一条流水线、一组验收标准开始。跑得通，再扩大。跑不通，先补组织课。AI 替代的是那些没有被清晰定义、没有验收边界、没有责任归属的工程动作。