第二天问题

2026-07-02

其实即便在当前这个阶段，使用最强的模型进行 coding，我们也会发现一个现象。

以我自身为例，我在开发一个项目时，往往在第一天，我和 Agent 之间的讨论中，Agent 是占上风的。因为它见多识广，在很多技术细节上都能压我一头，提出的方案往往比我提出的更符合生产环境（production），也更符合最佳实践（best practice）。

但是，从第二天开始——有时候甚至不需要到第二天，可能也就是半天的时间（如果一天开发 14 个小时，前 8 个小时可能是它在教我）——这种关系就会翻转过来。几乎所有的讨论都变成了我在教它做事，它在关于这个特定项目的代码知识上，已经没有办法和我相比了。

两条曲线

如果用曲线来表示：

人类的成长曲线：在特定项目上，我们拥有的知识和能力是不断增长的，是一个单调递增的曲线。虽然在某些情况下（比如你对项目不够重视，或者项目比较平庸、曲折）增长会比较平缓，甚至可能因为遗忘而出现降低，但在严肃的软件工程项目中，人的记忆力和直觉成长是非常快的，而且上限很高。

Agent 的能力曲线：如果按照目前这种非 Spec-driven 的一般开发方式，Agent 对代码库的知识和了解往往是没有进步的，它的能力曲线是一条水平线。

所以，到了第二天、第三天，我在这个项目上的能力就远远超过了 Agent。这时 Agent 就会显得越来越"蠢"，因为它处理的信息超出了它的分布。要知道，让它直接去"吃"整个代码库或者堆叠的代码文件，其困惑度（Perplexity）肯定远高于去读一份完好的文档，或者"50% 文档 + 50% 代码"的组合。（关于这一点，我们确实可以做实验来计算一下 Perplexity。）

归根结底，目前最适合做长程任务的还是人类。人类不管是体力还是智力，都是非常强的"长跑选手"，而现在的 Agent 很难做到这一点。

我们这一套 Spec-driven 的方式，本质上就是为了补足 Agent 在这种真正的长程任务上的能力。我们定义的"长程任务"不是几个小时，而是长达一周甚至一个月的工作任务。

隐藏知识与"坍缩"

意图是一个很重要的东西。原始意图是一个非常珍贵的资产，它在代码里面无法完全显示。

其实有很多东西都是隐藏知识。就比如说，有时候我们会拒绝使用一个方案而选择另一个方案，很多时候这样的选择是不平凡的。但是，如果是 Agent 来接手这个代码库，由于它不知道之前的设计决策，就会不断地犯一个错误，也就是"坍缩"：它会坍缩到自己习惯的、觉得一眼看上去更自然的那种方法上。

这其实会给开发者带来非常大的沮丧。明明我们选择某条技术路线是有着非常充分的理由的，但结果 Agent 在修某个 bug 的时候，可能就会因为思维定式，把这个架构又故意改了回去。因为它受限于训练语料库，习惯了用那种通用的方法，就没有办法改过来，也没法去适应当前的代码库。它不知道代码背后有很多弯弯绕绕，更不知道当初选择这个方案到底经历了多少决策过程。

带着保护措施攀岩

其实我现在已经体会到了另一边的快感：有 spec 的这种编程非常舒服。

当你代码库变复杂之后，你不用太担心 Agent 会完全误解你最初的意图。这种感觉就像是你带着很多安全的保护措施在攀岩；而没有 spec 的代码开发或项目开发，就像是没有任何保护措施的徒手攀岩。你生怕自己的一个错误会导致之前的某个功能被改坏，更生怕 Agent 在它看似漫不经心的一个设计选择中，让你之前一系列精密的、好不容易才 work 的设计直接瘫痪了。

还有一个很明显的点：我们每次都启动这种 Fresh Context Agent，它比那种用了很久、舍不得关掉的老 Agent 其实更不容易过拟合。一个全新上下文的 Agent 从 spec 出发，而不是从一段陈旧对话的沉积物出发。

为什么做 SpexCode

SpexCode 就是把这套想法做成了工具。每一次改动都以带版本的 spec 节点落地，原始意图和代码背后的设计决策就留在代码旁边、可以被读到；每个任务都由一个 Fresh Context Agent 在自己的 worktree 里完成，它的起点是 spec 树，而不是一段旧聊天。我们要做的，就是把 Agent 那条水平线掰弯向上——让它在第二天、第三十天，还能和你一起沿着这个项目的曲线往上爬。