用途：这是一条工程原则，用于把反复出现的修复与教训编码进结构（工具、代码、元数据、自动化），而不是依赖文字指令。每次错误、人工纠正和意外结果都是学习信号，应被捕获、分流并闭环。
核心理由：文字指令容易被忽略，需要读者注意、记住并遵守；结构性机制（lint 规则、元数据标记、运行时检查、自动化脚本）无需配合即可强制执行规则。
模式：当你发现自己在第二次写同一条指令时，先问：这能否变成 lint 规则、元数据标记、运行时检查或脚本？能则编码它并删除该指令；不能（需要判断）则让指令更醒目，并补充失败模式的示例。选择最强机制：当多种机制都可行时，选情境允许的最强者（无法编译的不可表示状态，其次使 CI 失败的 lint 或禁用 API，再次规范辅助函数，最后运行时检查），因为智能体会复制周围代码已有的做法，较弱的防护会成为下一个模板。推论：若修复是结构性的，就只用结构性修复，指令只是症状。
反馈闭环：捕获每次纠正，当人工介入或测试失败时判断是一次性还是模式；分流到正确层级，一次性→脑内笔记，反复修复→技能或 lint 规则，系统性问题→原则；闭环，不要只记录，立即应用或创建具体待办。
反模式：只承认不记录（“我会记住”不会持久）；只记录不分流（关于本应存在的 lint 规则的笔记，除非规则被实现，否则是浪费）；只修复不泛化（修好一个实例却留下反复出现的模式）。
限制：资料未提供具体安装命令、代码示例、收费或平台信息。