当同一指令写第二遍或反复纠正时，把规则固化为机制而非文字

适用于发现自己重复写同一条指令或反复纠正同一类错误时，用工具、代码、元数据或自动化把规则固化下来。

适用场景

解决思路

1. 当你发现自己第二次写同一条指令时，先问：这条规则能否做成 lint 规则、元数据标记、运行时检查或脚本？
2. 如果能，就把它编码进机制里，并删除原来的文字指令。
3. 如果不能（需要人为判断），就把该指令写得更醒目，并补充一个失败模式的示例。
4. 在多种机制都可行时，选择当前情境允许的最强机制，优先级为：让状态无法表示从而编译不过 > 让 lint 或禁用 API 在 CI 中失败 > 提供规范化的辅助函数 > 运行时检查；因为智能体会照抄周围代码的写法，较弱的防护会成为下一个模板。
5. 推论：如果修复是结构性的，就只用结构性修复；文字指令只是症状。
6. 捕获每一次纠正：当人类介入或测试失败时，判断这是一次性事件还是某种模式。
7. 把问题路由到正确的层级：一次性事件 -> 记到 brain note；反复出现的修复 -> 做成技能或 lint 规则；系统性问题 -> 提炼为原则。
8. 闭环处理：不要只记录，要立即应用或创建一个具体的待办事项。
9. 避免反模式：只口头承认不记录（“我会记住的”不会持久）。
10. 避免反模式：只记录不路由（关于本应存在的 lint 规则的 brain note，如果不落地实现就是浪费）。
11. 避免反模式：只修复个例而不泛化（修好一个实例却让反复出现的模式继续存在）。

适用边界 · 注意事项

• 当规则需要人为判断、无法用机制表达时，不应强行编码，而应让指令更醒目并附失败示例。
• 当问题只是一次性事件而非反复出现的模式时，不必固化为机制，记到 brain note 即可。