夜雨聆风昨天晚上，我让 Codex 跑了七个小时。
醒过来看结果，终于：一个很久没动的老项目，被它做了一轮升级。
这件事给我的冲击挺大。因为类似的工作我们以前做过，那时差不多用了三个资深工程师花了一个月的时间做升级。那种工作和写一个小 demo 、做一个新页面完全不是一回事，它面对的是一个已经有历史包袱、有依赖、有隐性约束的老项目，需要先重新理解，再让它往前走一步。
这类事情以前是最贵的。
新项目反而简单，所有东西都可以按最新范式重新来。老项目不一样，老项目里有过去几年甚至十几年的选择、妥协、业务逻辑、边界条件、没人敢删的代码、没人记得为什么存在的配置。它不是一堆文件，它是时间沉积下来的系统。
也正因为如此，老项目的价值经常比新项目大得多。
问题是，在没有 AI 的时代，人类维护老项目的成本太高。项目会腐化，依赖会过期，文档会失真，人会离开，知识会断层。最后它明明还有价值，却因为没人敢碰、没人碰得起，慢慢变成一块技术化石。
AI 不仅让写代码更快，也让盘活代码变得更快。因为我们可以更快地重构和优化代码，很多原本因为维护成本太高而被放弃的项目，重新有机会被救活。
如果 Codex 这类工具的模型窗口继续变大，开到 1M 级别，很多事情会变得更不可想象。以前一个工程师只能局部理解一个系统， AI 则可能在足够大的上下文里，把代码、日志、文档、测试、历史迁移一起读进去。老项目不再只是“代码仓库”，而会变成一个可以被重新理解、重新对话、重新激活的资产。
所以程序员在 AI 时代的技能变迁，不能只从“还要不要写代码”这个角度看。写代码当然还要，但它不再是全部中心。
这就意味着，我们要改变自己的工作技能。下面是根据我这两年使用 AI 做项目后的感悟：
第一种能力：并行能力
以前一个程序员的核心工作方式，基本是单线程的。
你打开编辑器，读一段代码，改一处逻辑，跑一轮测试，再处理下一个问题。最多也就是脑子里并行几个分支，但手上的执行还是一个接一个来。
AI 时代不一样了。
你可以同时把几个事情分发出去：一个 Agent 去升级依赖，一个 Agent 去补测试，一个 Agent 去读历史文档，一个 Agent 去定位线上错误，一个 Agent 去尝试迁移方案。你不再只是“自己做”，你开始拥有调度能力。
但这件事的门槛也在这里。
并行不是把任务随便丢出去。并行意味着你要知道哪些事情可以拆开，哪些事情不能拆开；哪些任务之间有依赖，哪些可以同时跑；哪些结果可以自动验收，哪些必须人工看一眼。
一个不会并行的人，用 AI 还是单线程。他只是把“我来写代码”换成“AI 替我写代码”，效率会提升，但上限有限。
一个会并行的人，会把 AI 当成一组可以同时工作的工程师。他最重要的动作不是敲代码，而是分发、等待、验收、合并、再分发。
这很像从工程师变成技术负责人。区别只是，你带的队伍里有一部分成员是 AI 。
第二种能力：写 goal 的能力
很多人把和 AI 协作理解成“写 prompt”。我觉得这个说法太轻了。
真正关键的不是 prompt ，而是 goal 。
prompt 经常是在描述你想要什么， goal 则是在定义 AI 如何知道自己做完了。它不是一句“帮我升级一下项目”，而是一个可以执行、可以校验、可以收敛的任务边界。
一个好的 goal 至少要回答几件事：
这就是为什么“写 goal 的能力”会越来越重要。
AI 的运行时间越长，越需要标准。没有标准， AI 跑得越久，偏得越远。有标准， AI 才能自己检查自己，自己修正自己，自己把一个任务从“开始做”推到“可以验收”。
换句话说，未来程序员的一项核心能力，是合理地让 AI 运行更长时间。
这听起来有点反直觉。过去我们总想让程序快一点，让任务短一点。现在恰恰相反，有些复杂任务需要 AI 长时间探索、尝试、失败、修复、再验证。你要做的不是一直盯着它，而是写出足够好的 goal ，让它能在你的标准里跑得久、跑得稳、跑得回来。
goal 写得好，一个晚上可以替你推进一个老项目。
goal 写得差，七个小时之后你可能只得到一堆看似热闹、但无法合并的修改。
第三种能力：沟通能力
AI 时代，沟通能力不是软技能，它会变成硬技能。
一部分沟通，是和人沟通。
老项目为什么难？很多时候不是代码难，而是上下文难。真正的需求在业务方嘴里，真正的约束在老同事记忆里，真正的风险在运维习惯里，真正的历史原因在某次已经没人翻的事故里。你如果不能把这些信息问出来、整理出来、确认清楚， AI 拿到的输入就是残缺的。
残缺输入，只会产生残缺输出。
另一部分沟通，是和 AI 沟通。
和 AI 沟通不是客气，也不是“请帮我”。它更像是在给一个非常勤奋、非常能干、但没有项目责任感的协作者建立工作空间。
你要告诉它背景、边界、验收方式、失败策略；你要能看懂它的中间结果；你要能在它偏航时及时把它拉回来；你要能把人的模糊意图，转成 AI 可以持续执行的结构化目标。
以前沟通能力差，最多是需求理解慢一点。现在沟通能力差，会直接变成工程风险。因为 AI 可以很快把一个误解放大成几百行代码。
第四种能力：自学能力
AI 越强，程序员越不能停止学习基础知识。
这也是最容易被误解的一点。
很多人会觉得，既然 AI 会写代码了，那我是不是不用学那么多底层东西了？我反而觉得相反。 AI 会写之后，人类更需要知道什么是对的，什么是错的，什么只是看起来能跑。
因为你不理解基础，就无法验收。
你不懂数据库，就看不出一个查询为什么未来会拖垮系统。你不懂并发，就看不出一个修复为什么会引入竞态。你不懂网络，就看不出一次超时处理为什么只是把问题藏深了。你不懂工程结构，就看不出 AI 给你的方案是在修项目，还是在制造下一代债务。更现实的是，很多专业术语和基本概念如果你不懂，你甚至很难把问题和 AI 讲清楚， AI 也就很难准确理解你的表达。 AI 也不是万能的，有时候它会绕进去，这时仍然需要人类指出问题，把方向拉回来。
AI 会打压人的学习欲望。它太方便了，方便到你很容易跳过理解，直接拿答案。
但越是这样，越要持续学习基础知识。因为 AI 时代最有价值的人，不是能背最多 API 的人，而是能判断 AI 输出质量的人。
判断力来自基础。
没有基础，你只能相信 AI 。有基础，你才能使用 AI 。
老项目会重新变成战场
把这四种能力放在一起看，会发现一个很有意思的变化： AI 时代的程序员，不是在变轻，而是在变重。
轻的是手上的重复劳动，重的是你对系统的理解、对目标的定义、对风险的判断、对多个执行线程的调度。
以前公司做老项目升级，最怕的是投入产出比。三个人，一个月，最后只是把项目从一个旧状态迁到一个不那么旧的状态，老板很难下决心。
但如果 AI 能把这件事压缩到一个晚上，老项目的经济账就变了。
很多过去“值得做但太贵”的事情，会重新值得做。遗留系统升级、测试补齐、依赖迁移、文档恢复、架构梳理、性能排查、知识沉淀，这些曾经最容易被拖延的工作，会慢慢变成 AI 最适合切入的地方。
所以我越来越觉得，没有 AI ，人类的项目腐化会更快；有了 AI ，很多项目反而会被救活。
但前提是，使用 AI 的人要升级。
如果程序员还是只把自己定位成“写代码的人”，那他会和 AI 抢同一件事。这个位置会越来越挤。
如果程序员把自己升级成“定义目标、调度并行、沟通上下文、验收结果的人”，那 AI 不是竞争对手，而是杠杆。
最后
AI 时代，程序员的技能栈正在换挡。
以前最重要的是：我能不能把代码写出来。
接下来更重要的是：我能不能把一个复杂目标拆成多个可执行的 goal ，分发给 AI ，允许它们长时间运行，再把结果验收、合并、沉淀成项目资产。
这四种能力会越来越关键：
程序员不会因为 AI 消失。
但程序员会分化。
一类人继续把自己当成单线程写代码的人，和 AI 比速度。另一类人开始把自己当成复杂系统的负责人，学习如何让 AI 在正确的目标里跑得更久、跑得更稳、跑出可以验收的结果。
后者，才是 AI 时代真正会变强的程序员。
