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