每次问题解决后，都可以写下一句“以后不要再这样”。但如果所有经验都变成常驻说明，AI 每次工作要读的东西会越来越多，真正关键的要求反而更难找到。

我的选择是先问：这句话会改变下一次行动吗？它应该由文字承担，还是更适合交给代码与检查？

一条具体约束，先说明为什么

本站有一条已确认的 UI 约束：桌面搜索入口始终相对整个视口水平居中。

不同页面可能有不同的侧栏与正文布局。如果把搜索框的定位参照换成正文容器，搜索位置就可能随着内容区域偏移。于是，规则需要保留的是“以视口为参照”这个意图，以及检查时必须覆盖不同布局的原因。

具体选择哪种 CSS 写法，应由当前实现承担。把某一版选择器也抄进规则里，下次调整结构时就多了一份需要同步的事实。

先判断谁最适合保存它

遇到的信息	更合适的去处
可以稳定自动判断的行为	代码、测试或确定性检查
跨任务始终成立的项目约束	项目入口或相关规范
特定类型任务才需要的步骤	按条件使用的工作流或 Skill
当前任务还没完成的部分	当前任务状态
已经结束且无需常读的过程	必要历史，而非每次加载

先复用现有位置。没有明确的下次用途，就不必为一次经历新建一份永久文档。

写清条件，比写长清单有用

“所有改动都要执行全部检查”容易理解，却可能把一次小文案修正也变成沉重流程。更有用的说明是：什么变化触发什么检查，哪些不变量不能被削弱。

共享规则也要放在恰当层级。一个项目的目录名称和部署习惯，不应该顺手变成所有项目必须遵守的约束。复用的是判断方法，具体事实仍留在所属项目。

下一次用不上，就重新审视

当行为已经能由代码可靠检查，原来的长篇操作说明可以缩短成入口。当方案被替代，过时规则应修改或退出，而不是继续与新做法并存。

这不要求删掉有必要保留的历史。历史说明当时发生了什么；当前规则说明今天该怎样做。把它们分开，AI 接续任务时才不用先裁决几份相互冲突的说明。

积累的标准，是下一次更容易做对

值得留下的经验，可以很小：一个清楚的约束、一个可复现的检查、一段有适用条件的工作流。它不需要因为写成了 Skill，就自动获得长期价值。

下一次遇到同类问题时，检查它是否真的帮助了判断与行动；没有帮助，就修改。让规则接受结果检验，也是 AI 开发体系的一部分。