代码在跑。代码崩了。代码就是生产环境正在用的东西。
文档和规格说明能帮上忙，但往往会过时。所以我们学会了别太依赖它们。代码有一种诚实，是文档不具备的。它可能是错的，但它做什么就是做什么。
但信任代码还有另一个原因。很长一段时间里，代码是手工活。我们自己写，花时间打磨。我们不只是敲语法，而是在写的过程中思考整个系统。思考和实现几乎是同一件事。
这就是为什么代码值得这种级别的信任。不是因为代码完美，它并不完美。而是因为代码承载了创造它的人的大量判断。
到了智能体编程时代，事情变复杂了。
作为个人贡献者，我现在能飞快地推进。打开Claude Code或类似工具，给个方向，就能在项目搭建过程中不断调整。可能从一份粗略的规格说明甚至只是一个想法开始，但真正的决策往往发生在实现阶段。我试一下，看看代码，发现原来的想法不太对，调整，智能体再试一版。
这并不坏。实际上，这是这种方式最好用的部分之一。实现给出反馈，有时候代码会告诉你规格说明本该是什么样。
所以"代码优先"很诱人。它保持速度，保持心流，尤其在掌舵智能体的人脑子里装着全局时特别好用。
但这也是问题所在。
在这种情况下，真正的真相来源既不是代码，也不是规格说明，而是那个有经验的人。
他们知道边界情况。知道依赖关系。知道哪个接口脆弱。知道某些奇怪行为为什么存在。知道生成的代码技术上正确但实际有问题。他们在持续填补空白。
智能体并不是在根据完整的规格说明工作，而是在和一个携带缺失上下文的人协作。
这能运转，前提是系统能装进一个脑子里。
但真实的系统不会一直这样。它们膨胀，被拆分，团队分裂，有人离开，新人加入。有的工程师懂产品不懂架构，有的懂架构不懂领域，有的是新人，有的在赶进度。而智能体只知道我们给了它什么，加上它能推断出来的。
到这时候，记忆就成了糟糕的真相来源。
我们会忘记依赖关系，忘记边界情况，忘记为什么某个东西造得很奇怪，忘记哪个下游系统依赖某个行为。不是因为人不行，而是因为我们是人。
智能体不会神奇地解决这个问题。如果什么东西没被描述，它们会即兴发挥，选一个看起来合理的方案。而"合理"往往足以通过第一轮审查。
人对人也是一样。如果什么东西没被明确说明，我们不该期待它完全按想象运行。
我想"规格说明"这个词被误解了。它不只是前期写的一份文档，不只是瀑布流程的产物。它是任何能填补空白的东西——让智能体或人类能在没有持续监督的情况下做出正确决策。
这可以是代码注释、测试用例、架构决策记录、用户故事，甚至一段精心设计的提示词。关键是它得存在，得更新，得在需要的地方被找到。
智能体编程不会消除对规格说明的需求，而是改变了它的形态。当实现变得廉价，设计决策的价值反而上升。因为错误的决策现在可以被更快地执行，放大得也更快。
代码仍然是诚实的，但它诚实的是它做了什么，而不是它应该做什么。这个差距，在一个人能全程盯着的项目里很小，在多人协作的系统里会被放大。
所以问题不是选代码还是选规格说明。问题是：当系统的真相不再能装进任何一个人的脑子时，我们把它存放在哪里？
热门跟贴