记忆与规则：把踩过的坑变成制度

同一个坑踩第二次的时候，问题通常不在智能体够不够聪明，而在流程里没有东西把它记住。这一年的一个主要习惯是：凡是重复出现的问题，都从"这次怎么解决"升级为"下次怎么不用再解决"。

一、项目规则文件：写下环境的特殊性

每个项目维护一份规则文件，内容不是"项目介绍"，而是这台机器、这个仓库的特殊约束：哪些命令不能用、哪些路径需要转义、哪些工具在这个环境下是坏的、交付前必须跑哪几条检查。

这类信息的特点是：不看就一定会踩，看了就再也不会踩。写在规则文件里，等于每次会话开始时自动加载一份"环境说明书"。

二、项目记忆：跨会话保留结论

规则文件记录"环境是什么样"，记忆文件记录"我们得出了什么结论"：某个方案被验证不可行、某个参数范围确定不适用、某个决定是在什么背景下做的。

没有这层记忆，每个新会话都要重新交代一遍背景；有了这层记忆，新会话可以直接从结论继续。

三、需求总账：把散落的要求收成一份

当会话数量累积到几十上百个之后，会出现一个新的问题：同一条要求散落在多个会话里，每次理解都可能不一致。我为此立了一份"要求总账"：回查历史会话，把提过的要求全部抽出来，去重后写成唯一一份。

更有意思的是总账的生成方式——用智能体去读自己过去的工作记录：让它批量回查历史会话、抽取用户提出的要求、汇总成清单。这比人工回忆准确得多，也顺带完成了"这套协作里我被要求过什么"的复盘。

四、跨设备一致：把记忆放到工具之外

我在多台设备上使用不同的智能体框架，如果记忆只存在于某个客户端里，换个设备就等于失忆。所以记忆与经验被放在工具之外：以文件形式存在于项目目录中，并通过私有仓库在多台设备之间同步。

这条约束决定了长期使用体验：换框架的成本因此大幅下降——因为要迁移的东西变少了，真正的资产（记忆、规则、方法）不在框架里。

五、一条判断标准

写完一条经验，我会问一句："下次遇到同样的事，它会自动起作用吗？"

• 如果答案是"要我自己想起来去翻文档"，那这条经验迟早会失效；
• 只有当它被放在"每次都会被读到"的位置（规则文件、检查清单、自动化脚本），它才算真正变成了制度。

六、体会

把经验制度化听起来很"重"，但它的成本其实很低——写几行规则的时间，远小于重复踩一次坑的时间。真正难的是养成"这个问题要不要升级为规则"的判断习惯：出现一次是意外，出现两次就是流程缺失。