最近新上了 Opus 4.6 ，它又给我们这帮老程序员上了一课。

在一个近一年没有迭代（指没有被封）的程序员群里，有大佬分享了如下的案例：

团队有个复杂遗留系统，典型「多线程 + 历史包袱 + 不敢动」组合。模型先给了一个方案：加锁、等待、条件变量、再加一层保护，几百行代码，逻辑像一团湿毛线。能跑，理论上也对，但你让我把这玩意儿上线？我不敢。

我让它「再想想，能不能避免这些锁和等待」。它又跑了很久，最后给了一个极简方案：之前那些锁啊等待啊都删了，思路干净到让我怀疑它刚才在干嘛。

那一刻我脑子里冒出来的不是「AI 真强」，而是一个更别扭的问题：

我到底起了什么价值？

背景上下文？它从代码库里能 infer 掉绝大多数。设计约束？很多也能从调用关系、线程模型、运行时指标推出来。所谓「design taste」？我甚至可以写成 Markdown 规则让它照做。

过去资深开发的硬价值之一是 reasoning 的过程：拆问题、找不变量、选折中、落地细节。现在模型也能做，还能做得很快。

我绕了一圈，最后落在一个很不体面的结论上：人的价值被压缩到极小概率的「否决权」里。

99% 的时候，我是在给 AI 的解「盖萝卜章」：嗯，看起来没错。
剩下那 1% 的时候，我得站出来说：不行，这条路走不通，换解空间里的另一个点。

这个角色像保险。你买的时候就知道大概率用不上，但真出事的时候要能扛住。更像现在的 L2-L4 自动驾驶：人坐在方向盘前，99.9% 的时间无事可做，为了那 0.1% 的「可能发生也可能不发生」。

问题来了：这 1% 会不会也被另一个 agent 替掉？再给一个「专职 reviewer」去 challenge 写代码的 agent，让它把那 1% 找出来。

那人还剩什么？

以及这会把程序员的岗位推向哪里。

很多讨论卡在「AI 写代码快，所以程序员要失业」这种口号里。工程上更真实的变化是两条曲线的剪刀差：

• 代码生成成本下降得很快：写一段能跑的实现、补齐样板、迁移接口、写单元测试骨架，这些都接近「文本补全」。
• 承担后果的成本上升：上线事故、性能回退、并发死锁、数据一致性破坏、合规风险、供应链安全。AI 让改动频率变高，系统的「变更面」变大，出事概率跟着涨。

我现在看 AI 产出的 patch，经常有一种荒诞感：
改动本身很漂亮，解释也很漂亮，真正要命的点藏在「系统级不变量」里，而那部分恰好最难被 prompt 描述清楚，也最难被静态检查覆盖。

所以讨论「程序员价值」别从「写代码」切入，从「为系统负责」切入。写代码只是责任链条里最便宜的一环。

聊回到前面大佬分享的案例。

为什么模型会先给「复杂加锁方案」，再给「极简方案」

这不是模型「变聪明了」，更像搜索策略切换。

我自己复盘过很多次类似现象，模型第一次给复杂方案，常见原因有几类：

• 目标函数不清：模型默认把「不出错」权重大幅拉高，并发问题里，模型的默认倾向是「保守」：能锁就锁，能等就等。因为它无法确认你的系统允不允许重构线程模型，也不知道你能承受多少延迟和吞吐损失。一句「能不能避免」其实是在改目标函数：把「简单性」和「可维护性」的权重抬起来，把「局部可证明正确」的偏好压下去。

• 它没拿到关键不变量：并发优化的核心不是技巧，是不变量。例如：哪些数据必须线性一致，哪些允许最终一致；哪些操作必须串行化，哪些可以交换；线程间共享状态的「所有权」到底属于谁；是否存在天然的「单 writer」路径。模型第一次通常拿不到这些，它会用锁把未知包起来。你追问一次，相当于逼它去反推不变量，或者提出重构以创造不变量。

• 在「局部最优」里打转：遗留系统经常有局部约束：你动不了某个模块，改不了调用方，不能引入新队列，不能改变线程亲和性。

人的价值最终会被压到 1%

这事已经发生了。

如果把「写实现」交给模型，人还剩什么？

我现在更愿意把角色拆成四层，分别看哪些会被自动化吃掉：

1. 执行层：写 CRUD、搬接口、补样板、按规范改文件结构
   这层基本被吃穿。
2. 局部推理层：读一段代码、定位 bug、做局部重构
   这层大幅被压缩，速度优势在模型。
3. 系统推理层：跨模块不变量、性能上界、故障模式、发布策略、回滚路径
   这层短期很难完全自动化，原因是信息不完备且目标冲突。
4. 责任层：线上事故谁背、合规谁签、业务损失谁扛
   这层本质是组织结构问题，不是智能问题。

很多资深工程师过去主要靠第 2 层吃饭：你会拆、会想、会写出「更优雅」的实现。现在模型把这层的边际价值压得很薄，于是人的价值看起来就剩「在模型犯错时否决」。

这就引出一个很工程的问题：能不能用另一个 agent 把「否决」也自动化？

答案是：能覆盖很大一部分，但永远留洞。洞的大小取决于你怎么搭系统。

那 1% 到底是什么：哪些场景必须有人类 override

我现在把「必须 override」的场景分成几类，每一类都对应一套工程信号。我们可以用这些信号去训练 reviewer agent，也可以用来提醒自己别当「只会点 approve 的人」。

• 需求语义存在空洞，代码再正确也没意义：常见现象： PR 描述是「修复偶现 bug」，但没有可复现条件，没有失败判据；业务方说「按之前逻辑」，但「之前逻辑」存在灰度分支、历史例外。这类问题 AI 很难凭空补齐。它会把空洞当成「默认值」，然后写出一份自洽的实现。你看起来也挑不出毛病，直到线上行为偏了。override 的动作往往不是改代码，而是卡住合并，逼需求补齐验收条件和反例。
• 系统级不变量被破坏，局部看不出，全局会炸：典型不变量：

  • 计费、库存、资金流的幂等与去重
  • 订单状态机的单向性
  • 写路径单 writer，读路径可并发
  • 缓存一致性策略：写穿、失效、双写窗口
  • SLA 约束下的超时与重试预算

模型能理解这些词，但它很难知道「你们公司真实的不变量是什么」。很多不变量写在事故复盘里，写在某个老同事的脑子里，写在那段「不要动」的注释里。

override 的动作通常是把不变量显式化：写进 ADR（架构决策记录）、写进测试、写进发布 checklist。写完再让模型改。

• 代价函数冲突：延迟、吞吐、成本、可维护性互相打架这些对尾延迟很要命。你让它「简单化」以后，它可能会走向另一个极端：过度重构，侵入面太大，风险高得离谱。这类冲突靠 prompt 很难一次调对，得靠基准测试 + 真实流量回放。人类 override 的价值在于：你知道线上哪条曲线最敏感，知道预算是多少，知道哪里可以牺牲。

• 生产环境的「脏现实」：测试覆盖不到 包括但不限于：

• 时钟漂移、时区、闰秒
• 依赖服务的抖动、限流、半开连接
• 数据脏写、历史脏数据格式
• 热点 key、倾斜分片、长尾用户行为
• 灰度期间的双版本共存

AI 可以写出很干净的逻辑，干净得像从未上过线。

人类 override 的价值在于：你知道哪些脏东西真实存在，知道一旦触发会损失多少钱。

• 安全与合规：模型会「帮你越线」

安全问题里最阴的是「看起来像优化」：

• 为了排查问题把敏感字段打进日志
• 为了方便把权限校验挪到上层，结果漏掉某些调用路径
• 为了提高命中率调整缓存 key，结果造成跨租户数据串读

这类问题 reviewer agent 能抓一部分，靠规则匹配和数据流分析。但组织里真正要命的合规约束往往来自外部：合同、监管、审计口径。模型很难内建你们的合同条款。

只留了 1%，那么大公司删人游戏才刚开始，接下来组织会怎么变？有前司裁员了一半。

AI 带来了两件具体的事：

• 单位时间的变更量上升
• 对稳定性与合规的要求不会下降

组织会自然把资源往两端挤压：

• 一端是「产出变更」的能力：更少的人能产出更多 patch
• 另一端是「控制风险」的能力：测试、发布、SRE、安全、平台工程会更吃香

中间那层「靠手写实现体现资深」的位置，会被挤得很难受。我们会看到更多岗位变成：

• 平台/工具链负责人
• 质量与发布工程负责人
• 架构与技术治理（不变量、规范、依赖治理）
• 领域负责人（把业务语义写成可执行的约束）

如果还把价值押在「我写得快、我写得优雅」，会被模型直接碾过去。

那我们该何去何从？

我更建议把自己训练成「系统负责人」，别训练成「提示词手艺人」

很多人看到 AI 就去卷 prompt。prompt 当然有用，但它属于「表达能力」，不属于「护城河」。

我更建议把成长路线拆成三条，按你自己的背景选一条主线，另外两条补短板。

路线 A：系统与可靠性（适合后端、架构、TL） 要能回答这些问题：

• 这个系统的核心不变量是什么？写在哪里？谁维护？
• 出了事故，最可能的故障模式是哪几类？怎么提前打点？
• 一次改动上线，回滚点在哪里？数据怎么保证不被写坏？

这条路线的硬技能是：可观测性、故障注入、容量规划、发布治理、数据一致性策略。
AI 会让这条路线更值钱，因为改动变多，风险更高。

路线 B：平台与工具链（适合喜欢搞基建的人） 把「盖章」自动化掉。

要能把下面这些做成产品：

• 代码生成与改动的规范化输入（任务模板、约束模板）
• 自动化评审（多 agent + 规则 + 静态分析 + 安全扫描）
• 针对你们域的测试体系（尤其是并发、回归、流量回放）
• 一键灰度、一键回滚、发布可视化

这条路线的本质是：把工程经验固化成流水线能力。模型越强，平台越重要。

路线 C：领域语义与业务工程（适合对业务理解深的人） AI 最弱的地方之一是「公司特有的业务语义」。能把语义变成约束，价值就会变硬。

要能做的是：

• 把业务规则写成状态机与不变量
• 把验收条件变成测试与监控
• 把历史例外收敛掉，减少「口口相传」

这条路线听上去不像「技术」，但在 AI 时代，它会决定你是不是不可替代的那批人。

我不押「永远需要人」这种安全说法。我更愿意给一个工程化的判断：

• 在约束清晰、环境封闭、回滚容易的系统里，人类接管的概率会持续下降。很多内部工具、数据管道、非核心链路会率先做到「几乎无人值守」。
• 在约束隐含、环境开放、后果昂贵的系统里，1% 会长期存在。典型是资金、合规、核心交易链路、跨组织协作系统。这里的问题从来不只是智能，还包括责任与审计。

更关键的一点：就算模型能覆盖 99.99%，组织也未必允许完全无人。原因很现实：责任链条需要一个签字的人。

我写到这里，还是没法给一个让人舒服的答案。AI 把很多我们曾经引以为傲的能力变成了廉价品，这是事实。难受也正常。

但工程世界一向认结果。模型写得再快，只要系统一炸，组织就会把注意力拉回到「谁能把它跑住」。把自己训练成能跑住系统的人，价值就不会跟着 token 价格一起下跌。

以上。