给 AI 立规矩，本质上是在逼自己把所有的"心照不宣"变成白纸黑字。

前言

最近在 opencode 的配置上花的时间，说实话大概不比真正写代码的少。

起因很蠢——我发现自己在每个新会话里，都要花不少口舌去解释同一套约定：注释要用英文、改脚本不能直接覆写源文件、遇到选择题必须停下来等我拍板……这些话说了又说，下次开窗又是一张白纸。就好像公司来了一个新同事，智商很高，但每天早上来上班都不认识你。你每天的第一件事，就是重新做自我介绍。

opencode 支持放一个全局配置文件，每次会话启动时自动加载，充当约法三章。我一开始也是这么用的——往里面塞规则，一条一条加。直到有一天，我发现那个文件已经长到光是滚动完就要一会儿了，才意识到事情开始有点不对劲。

文件胖了，就得拆

一个文件承载所有约定，结果是什么都在、什么都找不到。

所以我重构了一遍：把那个总文件降格成目录，具体规则全部抽到单独的文件里，按性质分成三类：人格设定类（personality-*）、硬规则类（rule-*）、流程规范类（workflow-*）。总文件只负责索引，真正的内容在各自的文件里。

这个改动说起来简单，但效果是实在的。要改某条规则，直接知道去哪里找；要新增规则，不用担心塞进哪儿合适，按类型放就行了。

有一个坑一定要提：文件拆出去之后，别忘记把新路径追加到主配置的加载列表里。文件放在磁盘上但没有被加载，规则就是白写的，会话里完全不生效，而且你完全感知不到——AI 不会报错说"有个文件没读到"，它只是不知道有那条规则存在而已。我就栽在这里过一次。

注：加了新规则文件，一定记得更新加载列表，否则是静默失效。

规则太多，人脑记不住，AI 也一样

规则拆开放好了，但又来了一个新问题。

规则有十几条、二十几条之后，你会发现 AI 并不是装载了规则就等于时刻都在遵守。上下文长了，或者执行到比较后面的步骤，它很容易忘掉早先加载的某条规定。不是它偷懒，是注意力有限这件事对 AI 同样成立。

我的解决办法是加了一张速查卡，放在总文件的最开头。格式很简单：触发条件是什么、对应的规则是什么、该怎么做。不是规则全文，是足够触发记忆的提示。

速查卡不追求完备，只覆盖那些最常触发、最容易忘、忘了代价最高的规则。一张被认真读的短卡片，远比一份被跳过的长文档有用。

注：速查卡是路牌，不是规则本身。别把完整规则都塞进去，塞满了就失去速查的意义了。

触发词映射：让规则在该出现的时候出现

光有速查卡还不够，还有另一个问题——AI 看到关键词时，不一定会想到去翻规则。

所以我维护了一张触发词表：对话里出现什么词，应该去检索哪条规则（我给每条规则编了 ID，比如 R03 是草稿模式规则，R06 是必须等我做选择才能继续的规则）。比如：

  • 说到修改脚本、改代码这类词，AI 应该想起草稿模式相关的规则（R03）
  • 说到选项、方案、怎么选，应该想起不能自作主张的规则（R06）
  • 说到状态机、闭包、作用域，应该想起不能打补丁必须整体重构的规则（R15）

规则 ID 不是什么系统机制，只是我自己给文件加的编号，方便索引和引用。

这套映射的本质是助记，而不是技术上的热词检测。但效果是真实的——在没有这张表之前，我遇到过 AI 明显知道某条规则、却在该用的时候没想到用的情况；有了触发词映射之后这种情况少多了。

注：触发词表要和规则同步维护。新加规则，补触发词；废弃规则，把触发词也清掉。不同步的话，某天一个词触发了一条早就不该用的规则，很难排查。

规则要分等级

这个是我后来才意识到的问题：把所有规则放在同一层级，AI 在权衡的时候容易出错。

有些规则是不能违反的硬约束，违反了会造成实质性的麻烦——比如不能直接覆写源文件这条，因为那样就丢失了草稿审阅的环节，出问题时可能已经来不及了。这类规则必须明确标注，没有灵活处理的空间。

另一些是效率层面的最佳实践，偶尔绕开代价可以接受——比如新会话开始时先翻一下历史记录恢复上下文，这一步省掉的话顶多是 AI 凭空假设，但不会搞坏东西。

这两类如果放在一起不加区分，AI 容易把硬约束当成建议、把建议当成铁律，怎么处理都不对劲。我现在的做法是在文件结构里把硬约束单独列一节，并且在每条规则里写清楚违反会发生什么——不是为了吓人，只是让权重透明。

注：规则要有牙齿，但牙齿要分场合咬。把所有规则都设成高压线，AI 在该灵活的地方也会卡住，这和没有规则同样糟糕。

规则会腐烂

写规则比维护规则容易得多，这是我踩过的最大的坑。

规则是对某个时间点的工作方式的描述。但项目在变，工具在升级，当时的解法可能半年后已经不再适用——甚至变成了阻碍。如果旧规则没有及时清掉，新旧描述同时存在，AI 在解读的时候就会出现微妙的困惑，或者干脆在两条矛盾的规则之间取了个平均值，出来的东西不伦不类。

同样的问题也出在记忆里。我用另一个工具做项目记忆，同一个主题下的条目越积越多，几条记录来自不同阶段、逻辑相互矛盾，AI 检索出来不知道该信哪一条。

解决办法说来也简单：定期做合并。同一个主题下的记录积累到一定数量，就触发一次整理——删掉中间过程，只保留最新阶段的描述。有点麻烦，但不做这件事的代价更大。

注：规则文件和技术债一样，不主动维护就会以利息的形式反噬。每过一段时间翻一遍规则，把失效的删掉，比新加十条更值钱。

一个真实的反面案例

大概两周前，我在推进一个 UI 改版任务。

按照我自己定的流程，应该先拿到原始需求文档，再去检查实际的 UI 节点结构，确认所有模糊的地方之后再开始规划。

那天可能是心里有点急，我跳过了确认语义歧义那一步，直接让 AI 进入规划阶段。它根据某个节点的命名猜测了这个区域的用途——猜错了，把"武器专属技能展示区"理解成了"武器类型选择器"。

结果就是整个规划方向偏了，花了两三轮才纠回来。

事后复盘，规则是存在的，流程也是对的，问题只有一个：是我自己允许了那一次灵活处理。

这件事让我对规则体系有了一个新的理解：规则的真正价值，不是让 AI 变聪明，而是在我自己偷懒的那个瞬间，帮我兜住那个疏漏。写规则是给 AI 看的，但其实也是写给我自己的。

写在结尾

折腾这套规则体系前前后后大概有一两个月了，期间其实也没少怀疑自己是不是在用配置文件的时间比省下来的时间还多。

但最后的感受是：这件事的核心是对自己工作方式的一次整理。把所有理所当然、从来都是这么做的东西逐字逐句翻出来审视一遍，本身就是有价值的事，跟 AI 用不用没什么关系。

还有一些没想清楚的地方，比如规则怎么在多人协作里共享，规则文件本身怎么做版本管理。等有空了再琢磨。

感谢你看完了我的这点絮叨。