你的AI需要“伤疤组织”

最昂贵的AI错误不是编码助手第一次搞错了什么，而是明天它又犯了同样的错误。正是这一点逐渐消磨你的耐心——不是因为模型失败了一次，这很正常。令人沮丧的是你已经纠正过它：你解释了仓库的模式，告诉了它那次迁移失败的原因，指出了奇怪的CI问题，展示了之前失败的依赖。AI修复了任务，会话结束。然而两天后，一个新会话又提出了同样糟糕的想法，仿佛一切从未发生过。这就是我最近一直在思考的问题：AI编码助手需要的不仅仅是更大的上下文窗口，它们需要“伤疤组织”。

我所说的“伤疤组织”是指被记住的失败。它不是泛泛的文档，不是庞大的聊天记录，也不是另一个臃肿的AGENTS.md文件——无论是否相关都被塞进每次提示中。伤疤组织是关于什么出了问题、为什么出问题以及不应重复的持久记忆。例如：不要在这个仓库中使用这个迁移模式，它在本地通过但会因为X原因破坏预发布环境；不要替换这个中间件，它看起来冗余但实际上保护了管理路由；不要再使用这个包，我们试过它，由于原生依赖在Vercel上失败了；Stripe的webhook处理器必须保留原始请求体，正常的JSON解析会破坏签名验证；这个测试失败通常意味着模拟用户缺少某个角色，不要先重写认证流程。这类知识非常宝贵，但大多数时候它消失了——存在于某人的头脑中，淹没在Slack里，困在昨天的AI会话中，或藏在再也没人阅读的PR评论里。

很多AI编码工作流仍然把上下文当作万能药：添加更多文件、更多指令、更多文档、更多示例、更多项目历史。最终提示变成了一个杂物抽屉，AI有了更多文本，但不一定有更好的判断力。这正是我关心的区别：上下文告诉AI附近有什么，而伤疤组织告诉AI它从惨痛教训中学到了什么。两者不是一回事。

旧模式是这样的：会话1中AI提出错误方法，开发者纠正，AI修复问题，会话结束；会话2中AI对纠正毫无记忆，再次提出同样错误方法，开发者失去信任。模型并非真的“忘记”了——它从一开始就没有持久记忆，只有临时工作空间。一旦会话结束，教训就消失了。

更好的模式应该是：会话1中AI提出错误方法，开发者纠正，教训作为持久项目记忆被存储；会话2中AI开始类似任务，相关伤疤被检索，AI避免重蹈覆辙。这是一种不同的AI编码工作流——不仅更快、更便宜、消耗更少token，而且更有经验。

编码助手越强大，这一点就越重要。当AI只写小片段时，遗忘只是烦人；现在它们可以触及真实架构：重构文件、生成迁移、编写测试、修改接近生产环境的代码。这让重复错误代价更高。如果AI要在真实代码库中操作，它需要的不仅仅是指令，而是对后果的记忆——记住那些带来伤害的事情。

这正是我通过Empirical探索的用例之一。Empirical是AI工具的记忆层。它不是把每个教训、决策、偏好和警告都塞进一个巨大的提示，而是让AI在需要时检索特定的记忆。对于编码助手，记忆层可以存储：项目决策、仓库约定、失败方法、bug历史、CI/CD怪癖、安全陷阱、依赖警告、“再也不要这样做”的教训。这些通常会在会话之间丢失，也正是让开发者随时间变得更有效的东西。为什么AI编码助手应该有所不同呢？

我不认为编码助手的下一次飞跃仅仅来自更智能的模型。部分进步将来自更好的记忆——不是转录转储，不是“把整个仓库加载到上下文中”，而是作为累积判断力、操作历史、伤疤组织的记忆。因为真正的胜利不仅仅是能够编写代码的AI，而是能记住上次修复为什么失败的AI。