很难写歪

两台布道

今年秋天，编程界最响亮的声音分成了两台布道。一台是 DHH，他在 Rails World 上对着上千名开发者说：手写代码已经结束了，在经济上不再可行，为此悲观是 loser 的事。另一台是一群老手的警告：谁让 AI 去读 stack trace、让 AI 写任何陌生东西的第一稿，谁就在悄悄变得可替代——系统的模型必须长在你脑子里，否则你就完了。

这两台布道共享一个我不接受的假设：系统的模型非得住在人的脑子里。

第三个答案

我的模型不住在我脑子里。它住在沉淀里——工作发生的地方积累下来的书面记录：提交历史、规格、我自己的网站赖以回答问题的 corpus。人脑会忘、会累、会退休，而且没法被搜索。沉淀会复利。它可以被我读、被协作者读、被下一个打开这个仓库的 agent 读——凌晨三点、我不在场，读到的都一模一样。

这不是我事后发明的比喻，记录本身已经长这样了。我的主仓库里有五个月攒下的 2,050 条提交，其中 96% 带正文，正文中位数约一千字。一条修复提交记的是：症状在生产上出现的样子（带日期和引出它的那次报告）、造成它的机制、现有的测试为什么没拦住、以及现在钉住它的那份规格——先写到能红为止。规则就写在变更发生的那个提交里，比如："部署文件只携带接线和生成的密钥，永远不放所有者的设置。"日后任何人——或任何 agent——问"为什么是这样"，答案在记录里，不在我的记性里。

为什么写不歪

有人问，我怎么敢让 agent 写掉大部分代码，还相信交付出去的东西。老实说，agent 的自由度在它动笔之前就被三面夹死了。架构先定好，其中一部分在启动时断言：接线接错了，系统拒绝启动，根本轮不到测试出场。每个要紧的行为都有一份即规格的测试，先写到红再修。而测试基准是按"能真红"造的——测试替身故意做故障注入，因为一套红不了的套件不是安全网，是屏保。

在这个框里，留给模型写错的空间大多是局部的，而局部的错误机械上可见。让 agent 在虚空里自由发挥时，是模型决定质量；约束给足之后，是系统决定质量——模型只决定速度。

所以，是的，stack trace 就该让 AI 读。trace 是整个回路里结构化程度最高的产物，不让最强的解析器读它，那是迷信。我在这个回路里的活不是阅读，是裁决。

老实交代剩下的部分

有两个弱点是真的，我不打算布道着绕过去。沉淀的质量等于写它的习惯——一个 log 里写了两千遍"fix bug"的仓库，没有值得查阅的记忆，而大多数仓库正是那样。其次，历史天然少记被否决的路：被放弃的设计留下的痕迹远少于被选中的那个，所以记录更知道发生了什么，不太知道备选为什么死。这两个毛病都能在习惯内部修——把否决也写下来，写在做决定的地方，跟写规则一样。

但这两个毛病都构不成"还是把模型装回脑子里"的理由。今年这场争论真正的题眼，从来不是机器能不能写代码，而是它写的时候，知识住在哪里。我的知识住在哪我很清楚——不在我的脑壳里，在记录里，写给下一个来读的，不管它是人还是什么。