关于 principle-encode-lessons-in-structure
一项开发原则，主张将重复出现的修复转化为 Lint 规则、元数据、运行时检查或脚本等结构机制。它优先采用可强制执行的改动，而非反复编写说明，并要求归类和落实从错误与纠正中获得的经验。
主要功能
- 01用机制固化重复修复
- 02优先采用结构约束而非文字指令
- 03选择可用的最强防护机制
- 04区分一次性与重复出现的经验
- 05落实修复并完成反馈闭环
适用场景
- 01用 Lint 规则防止错误重现
- 02用元数据或检查替代重复说明
- 03将重复纠正整理为 Skill
- 04跟进并落实测试失败带来的经验
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/principle-encode-lessons-in-structure确认已加载。
附带文件agents/openai.yaml
详细介绍
将经验教训编码到结构中
通过机制（工具、代码、元数据、自动化）编码反复出现的修复，而不是写成文本指令。每个错误、人工纠正和意外结果都是学习信号。捕获它、分流它，并形成闭环。
文本指令很容易被忽略。结构性机制无需他人配合，就能强制执行规则。
模式： 当你发现自己第二次写下同一条指令时：
- 问问自己：这能否变成 lint 规则、元数据标记、运行时检查或脚本？
- 如果可以，就将其编码进去。删除这条指令
- 如果不可以（需要判断），就让指令更醒目，并添加一个失败情形示例
选择最强的机制。 如果有多种机制都可行，就选择当前情况允许的最强机制（优先级依次为：无法表示、因而无法编译的状态；会导致 CI 失败的 lint 或禁用 API；规范化辅助函数；运行时检查），因为 Agent 会照着周围代码的做法复制，而较弱的防护机制会成为下一个模板。
推论： 如果修复应当采用结构性方案，就只采用结构性方案。指令只是症状。
当人工介入或测试失败时，判断这是偶发情况还是某种模式。进行分流：偶发情况 → 大脑笔记；反复出现的修复 → 技能或 lint 规则；系统性问题 → 原则。形成闭环：不要只做记录；要立即应用，或创建明确的待办事项。
反模式：
- 只表示知悉，却不做记录（“我会记住的”无法持久保存）
- 只做记录，却不进行分流（本应存在 lint 规则，却只记了一条大脑笔记，这是浪费，除非之后落实了该 lint 规则）
- 修复问题，却不总结规律（只修复一个实例，却放任反复出现的模式不变）
评论
支持 Markdown