AI 编程周记回顾：
三个月后，哪些判断经住了时间

2026 年 4 月，EP.81 记录了当时的三个信号：Epoch AI 与 METR 联合发布的 MirrorCode 基准显示，Claude Opus 4.6 在没有源码的情况下完整重新实现了一个 16,905 行的 Go 工具，四位工程师估算人类需要 2-17 周；GrandCode 在 Codeforces Div 1 实时竞赛中超越所有人类选手；App Store 新增应用激增 84%。三个信号拼在一起，当时给出的判断是："AI 编程的时间视野从分钟跨到了周"，并预测 18-24 个月的窗口期。

三个月后回看，这个"周级"刻度站得住脚，但已经不是最前沿的坐标了。本站同期发布的《长时程任务前沿》记录了 FrontierSWE、SWE-Marathon 等基准如何把评测单位重新切到"小时"；《Agent 工程进化论》记录了 Kimi K2.6 的 12 小时连续自主运行、MiniMax M2.7 的百轮无人干预自我修改。MirrorCode 引以为傲的"2-17 周"案例，在三个月后的语境里，更像是"给定极长预算、单次执行"的上限案例，而不是"持续、多轮、跨会话自主工作"的常态——后者才是行业接下来真正比拼的维度。EP.81 当时也不是没有察觉这一点：它援引 Epoch AI 的说法"更大规模项目不是不可能，只是需要更大的推理预算"，只是没料到窗口收窄的速度比自己给出的"18-24 个月"要快得多。

EP.84 记录了同一周里两种截然不同的企业 AI 原生战略：Amazon 选择扩能路径——向全体员工推广 Claude Code 和 Codex，不裁员，让每个工程师穿上"Karpathy 意义上的 Iron Man 外骨骼"，保留人类判断、放大执行力；Coinbase 选择重建路径——裁员 14%，组织架构压缩到 5 层以内，重建为"一人多能 AI 原生小组"，赌 AI 能承担多人工作量。同期还记录了 Simon Willison 对"vibe coding 与 agentic engineering 边界消融"的不安，以及 Tom Tunguz 的警告——3 人团队驱动 20 个 Agent，一位离职即损失 33% 机构记忆。

三个月后，vault 里没有任何后续数据能判定这两种组织赌注谁更优——这本身就是一个诚实的信号：组织战略的回报周期，远长于一篇周记能验证的窗口。但当时提出的分析框架依然成立：扩能路径假设人类判断力稀缺、AI 是杠杆；重建路径假设工作量可被替代、人力成本是变量。这条分叉线并没有随时间消失，反而在 2026 年下半年变得更普遍——几乎每一家认真投入 AI 编程的公司，都要在这两条路径之间做选择，只是没有一个案例已经跑出足够长的时间来证明自己是对的。Robert Glaser 当时提出的更隐蔽问题——"个人效率提升不等于组织能力积累"——目前看依然是悬而未决、且可能永远悬而未决的结构性矛盾，而不是一个会被下一次模型升级解决的技术问题。

EP.85 记录的信号看起来最"技术琐碎"：k10s 项目作者用 Claude 花 30 个周末构建一个 Kubernetes 仪表盘，效率一度是手写的 10 倍，但 Model 层膨胀到 1690 行后没人能再安全修改，最终作者放弃、回归手写；软件工程专家 James Shore 同期提出框架——AI 工具宣传的 ROI 通常只算"生成速度"，却忽略软件真实成本 60% 来自维护；RPCS3 等开源项目公开抱怨 AI 生成的"垃圾 PR"涌入，审查成本暴涨而真正有价值的贡献比例下降。三个案例共同指向一句话："我们在用 AI 生产代码，但没有用 AI 管理代码债务。"

三个月后回看，这恰恰是三篇周记里最经得起时间的判断——因为它不是在描述某个正在加速的能力曲线（会被下一次发布超越），而是在描述一个结构性权衡（生成变快，审查和维护的瓶颈不会自动跟着变快）。它甚至可以说提前命名了一个后来才被明确概念化的现象：本站《循环工程》一文里，Google Addy Osmani 提出的 comprehension debt（理解债）——当一个无人值守的循环在仓库里改了几百行代码，软件生成的速度超过团队 review 的能力，开发者继承了一个"底层设计决策、结构依赖、边界情况全是空白"的代码库。EP.85 用 k10s 一个具体项目的溃败讲的是同一件事，只是当时还没有这个名字。这提示一个规律：周记类快照里，最容易被证伪的是"进展有多快"，最容易被证实的是"哪里会出问题"——前者随每次模型发布刷新，后者是工程学的常识，不太会过期。