Opus 4.6 级别的 AI 真的可以取代程序员吗？
背景
因为自 Opus 4.6 以来的 AI 能力快速提升，使得自己效率得到了充分提高，便开启好几个 AI Agent 同时进行各种各样的 Project（曾经梦想着毕业后带一个团队来干很多心里认为有趣的idea，结果在 AI 时代提前低成本实现了），有自己论文的完善，也有新论文的实现以及探索，还有一些大工程性质的玩具。然而，我很快发现，如果当前 AI 的上下文能力或者记忆能力不能在现在的 Baseline 上指数级提升，对复杂的任务依然只有加速能力而非完全的取代能力。
曾经在电视上看到过脑部受伤，海马体受损无法产生新记忆的人（如“笔记本男孩” 10分钟记忆人生），而现在的 AI 就有点类似于这样的可怜人。
AI 还记得多少曾经告诉过它的内容
每个体验过 Vibe Coding 的人应该都会感叹，在给出一个大 Markdown 的设计之后，AI 写代码和 Debug 的速度非常地快，甚至会用很多复杂的工具去 debug 最终完成目标。
但是，我却发现了一些问题，上下文本身就是一个巨大瓶颈。
例如我自己有几台机器在局域网里 share 同一个 NFS，但仅有特定机器有特定硬件（例如 AVX512 的支持，CUDA 的支持，ROCm 的支持等等），亦或是某个 benchmark 必须在某一台机器跑来获得一致的结果，我会告诉 AI 一个 Markdown 说执行某个任务的时候需要 ssh 到某个机器，但随着 Context Window 压缩几轮，往往这些会忘记，直到 AI 发现错误后自己通过种种方式阅读脚本与先前的 Prompt 才会想起来，最后我的解决方法就是把这些步骤都打包成脚本，这样 AI 只要执行脚本即可。
执行任务时这个问题更严重，我通常观测到 AI 去做了一个错误的解决问题的方向后会及时纠正，或让 AI 先去解决另一个更严重的问题，而过一段时间重新回来解决该问题时，AI 往往又会重新走一次这个错误的方向，直到自己发现问题 / 我纠正才会回到正确的路上。
针对这些问题其实有一些解法，例如开多个独立 Context 的 AI，有的负责编写，有的负责 Review，有的观测进度，让 AI 进行互相的沟通。但我觉得最靠谱的方法其实是：让未来 AI 更加能模拟人类大脑权重的不断更新，而非仅仅存储一个很小的 Context Window。
代码的维护能力
在一个大型项目中，代码的维护能力是十分重要的。经验丰富的人在写代码时往往每一行都有自己的 Consideration ，这些 Consideration 往往对 Maintainability 、 Performance 、 Function 进行了 Trade-off。比如，我们可能会考虑软件某一个位置是否需要一个 mutex_lock（我们未来会不会有PL层面的解决方案呢，类似现在的safe rust解决内存安全一样？），会考虑 CPU 的 LSU 设计与 Cache 配合会不会出现 Memory-Order Violation ，会考虑编译器某一个优化 Pass 会不会导致其他优化 Pass 失效或引入 Bug 等等。而在过去人类为主的现实开发中，往往的流程是：
- 读透别人的代码 （git blame 找到对应的 commit，把整个 commit 读完）
- 自己在试错中习得经验
- 发送 PR / patch 的时候提醒与当前修改有相关的人进行 Review （git blame 找到相关人士）
而大量 Vibe Coding 改变的是：
- 试错中习得的经验会随着 Context Window 填满而消失，维护时重复犯错。
- 如果与当前修改有相关的人是让 AI 代劳完成的代码，自己并不清楚当时写代码的 Consideration ，那么会遇到一个非常恐怖的问题：Review 并不来自一个过去经验丰富的人，并没有指出其问题的能力。
未来的就业市场的工业界 / 学术界会如何变化
我认为，AI 固然能在很多事情上提升效率（例如自动进行设计空间探索，优化性能，Debug等等）。但人理解 AI 在做的事情，并提供巨大的 Context 能力依然必不可少。否则很容易发生不停的重构，就像许多企业小团队换一拨人就会对代码进行一次重构一样。同时，这些基础软硬件提供了现代计算机的基座，可靠性与确定性仍然是必不可少的一部分，在 Context Window 无法指数级增加前，我们不应该完全信赖 AI 提供的能力，否则我们往往无法从过去探索的经验中习得教训，而这一部分工作，只要 Context Window 无法大幅增加，依然需要能跟上 AI 节奏的人的脑力来辅助完成。在这种情况下，我也认为 企业对人力贡献评估需要的也许不是 OKR，而是评估一个人在 long-term 下提高效率与降低风险的贡献，同时能否提出新的思路来让企业生出更好的产品。
而且，如果我是企业管理，其实相比裁员，我会更愿意用 AI 提效后发展更多的业务，或者在已有业务上尽快追上甚至超越竞争对手，做更加先进的产品，否则这就是员工已有 Context 的巨大损失。至少目前 Context Window 的限制，让 AI 提效的前提依然是了解代码的人来驾驭。
但是对于新的 Junior ，我确实持有一些悲观态度。因为我看到了一些朋友会为了完成上级任务去使用 AI 完成自己完全不熟悉的东西，似乎自己成了一个 完全 不理解 AI 在做什么的转发器。又容易因为其自身的完全不了解，对 AI 的输出没有任何的判断能力。而过去，这样的人往往拿不到行业的入场券，而现在，也许他们在 AI 的加持下获得了一定的捡漏空间。
说完了工业界，那学术界呢？因为大多数情况下，学术界编写的代码通常只使用一次，对 long-term maintainability 没有要求，甚至往往代码还不一定做到了 General ，只要方法理论上是 General 的即可，AI 确实能起到大幅的加速效果。但我担心这个世界将出现劣币驱逐良币，认真 review AI 生成的代码，保证代码与论文中的描述一致的人，在数篇数的学术市场中被淘汰。
而对于学术圈，我一个很大的建议是：去优先做那些只有自己接触到的 Context 才会想到的 idea，如果只是看到一个很多人都能看到的问题，并提出一个 AI 都能分析出来的解法，非常容易 idea 撞车，也非常容易在激烈竞争中被随机淘汰。在我看来，科研的意义是 push the human race forward，而不是去抢占谁最先做出来某一个大家很容易发现的解决方法。如果自己不是全世界为数不多发现这个问题，并且能想到解决方法，并找到一个好场景的人，那么请慎重去做。
未来的 AI 能力
我认为上下文压缩、RAG 等等技术不应该是面对这些问题的终极解决方案。
暴论：现有 LLM Benchmark 缺失的部分正是人类还能高效进行的智力劳动部分。因为现有的 Benchmark 往往只评估 AI 能不能完成某一件事情，而难以评估 Long-term 下 AI 执行多个任务的速度、能力以及 potential 带来的 Bug 、 Security 等等这些短时间难以量化的能力。
而人脑大概是什么样呢？我们接触到一个信息，脑子很容易直接联想起这个信息有关联的一切，直接完成推理，而不是一个 explicit 的插入数据库与搜索的过程。这就有点像，我们接触到的信息直接改变了模型的权重。也许未来是否可能，每个人都有一个客制化的 AI，是在已有的模型权重上叠加了一层客制化的 diff，在实践中不断修改自身的权重，最终变得更像人类。
我想随着大家在 Opus 4.6 这样的模型中不断踩坑，发现同样问题的人越多，我们应该更快能迎来全新的 AI 能力与新的 Context 管理方式。
同样，我们如果在现有 AI 能力的基础上研究更多的类似 AGENTS.md 、RAG 作为 work-around ，是否也可以同样应用于海马体受损的可怜人，让他们有更好的生活质量。