AI 时代的「放卫星」

$200、744 次提交，为什么这不是工程奇迹    

    为什么我会这么判断？因为我确实在企业环境里做过这些事。无论是 AI Agent 平台，还是 AIOps 自动化，还是 LangChain、vLLM、PGVector 这一整套从模型选型、RAG 检索、Agent 编排到生产部署的链路，我都踩过坑，也见过系统跑起来之后的真实代价。所以当我看到有人拿着“30 天、200 美元、7 个仓库、744 次 non-merge 提交”这种成绩单兴奋时，我第一反应不是震撼，而是想起了另一个更古老的场景：大跃进年代的“放卫星”。那时候田边也喜欢竖牌子，写着“亩产三万六”。数字未必造假，秧苗是真的插下去了，重量也是真的称出来了，但那不是正常生产的结果，而是把隔壁地里的秧拔过来堆在一起，把泥和水也一起算进产量。数字不撒谎，但数字也从不自动说明真相。今天很多 AI 工程神话，本质上也是同样逻辑：它只统计了“产出动作”，却故意绕开了“质量后果”。

    真正做过完整工程闭环的人都知道，代码产出从来不是系统成败的核心指标。真正决定一套系统能不能活下去的，是架构有没有收敛，边界是不是清晰，状态是否统一，三个月后还有没有人敢继续接着改。744 次提交如果发生在一套缺乏约束、缺乏主线、缺乏治理的系统里，它不是生产力证明，而是风险放大器。AI 今天最强的能力，是根据上下文高速生成“局部看起来合理”的代码；但它并不真正理解你的系统，也不会对长期维护负责。于是最常见的结果就是：单个脚本看上去都没问题，组合起来却到处冲突。三个 Agent 写的自动化脚本，各自用了不同状态码规范；同一条告警在两个地方重复实现升级逻辑，规则还不一致；日志格式五花八门，排障时要在几套语义里来回翻译。每一段代码都像是“对的”，但整个系统的行为却越来越不可预测。这就是很多管理者没有看见的地方：AI 能把“写”变得极便宜，却不会自动把“对”也变便宜。

    更危险的是，最容易被这些漂亮数字打动的，往往恰恰是最不懂工程的人。因为不懂，所以他们会天然把 200 美元和一个高级工程师月薪做对比；看到 744 次提交，就自动脑补成“等价替代了几个人月”。但真实情况是，这 200 美元买到的不是工程师，更不是技术负责人，它买到的只是一个高吞吐、不知疲倦、也不承担后果的执行器。真正昂贵的部分，是后面那些不会出现在 PPT 上的成本：有人要 review，修复，统一约束，补测试，补 CI，补发布链路，梳理真源唯一，清理历史路径，防止系统继续失控。表面上省下来的，是显性的研发成本；实质上被透支掉的，是未来几个月甚至几年里的维护成本。很多老板只看到了“本月 ROI”，没看到“明年技术债”。这就像当年放卫星，产量数字是给上面看的，真正吃亏的是地里的庄稼和最后的收成。AI 时代同样如此：报表可以很漂亮，但系统的苦果，终究还是开发团队自己吞下去。

    所以，我并不反对 AI 写 99% 的代码，真正值得警惕的是：有人开始把这 99% 误解为工程本身。写代码只是工程里最容易被量化的一部分，而真正昂贵、真正稀缺、也真正决定系统生死的，是剩下那 1%：做取舍、立边界、删旧路、保一致、控复杂度、为长期演进负责。

    任何一个有经验的工程师，借助 AI，几天之内都能搭出一个“能跑”的系统；但从“能跑”到“企业级可用”，中间差的不是一点补丁，而是一整套工程纪律。也正因为如此，AI 越强，高级工程师反而越重要。因为当打字成本趋近于零，真正稀缺的就不再是代码体力，而是正确性成本、架构判断和治理能力。所谓“AI 时代的放卫星”，放的从来不是生产力本身，而是管理层对生产力的幻觉。它确实证明了写代码正在变便宜，却完全没有证明工程质量也会自动变便宜。谁把这两件事混为一谈，谁就会在下一个项目周期里，为今天的兴奋买单。