关于 principle-encode-lessons-in-structure
面向编码 Agent 的技能，指导将反复出现的修正转化为结构性防护，而非依赖重复的文字说明。它介绍如何将经验落实为 lint 规则、元数据和运行时检查等机制。
主要功能
- 01将重复修正转化为机制
- 02选择可行的最强防护措施
- 03按类型处理偶发及系统性经验
- 04落实修复或建立具体待办以闭环
适用场景
- 01用 lint 规则防止常见错误
- 02通过元数据约束规范
- 03为重复故障添加运行时检查
- 04将人工纠正沉淀为持久防护
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/principle-encode-lessons-in-structure确认已加载。
附带文件LICENSE
详细介绍
将经验编码到结构中
通过机制（工具、代码、元数据、自动化）而非文本指令来编码反复出现的修正。每个错误、人工纠正和意外结果都是学习信号。记录下来，将其路由到合适的层面，并形成闭环。
原因： 文本指令很容易被忽略。读者必须注意到、记住并遵守指令。结构性机制（lint 规则、元数据标记、运行时检查、自动化脚本）无需他人配合即可强制执行规则。
模式： 当你发现自己第二次写下同一条指令时：
- 问问自己：这能不能变成 lint 规则、元数据标记、运行时检查或脚本？
- 如果能，就将其编码进去。删除该指令。
- 如果不能（需要判断），就让指令更加醒目，并添加一个展示故障模式的示例。
选择最强的机制。 当不止一种机制可行时，选择当前情境允许的最强机制（先是无法表示、因而无法编译的状态；其次是会导致 CI 失败的 lint 或禁用 API；再其次是规范化辅助函数；最后是运行时检查），因为 Agent 会照搬周围代码已有的做法，而较弱的防护措施会成为下一个模板。
推论： 如果修正是结构性的，就只使用结构性修正。指令只是症状。
反馈闭环：
- 记录每次纠正。 人工介入或测试失败时，判断这是个例还是一种模式。
- 路由到合适的层面。 个例 → 记入脑内备忘。反复出现的修正 → 技能或 lint 规则。系统性问题 → 原则。
- 形成闭环。 不要只做记录。立即落实，或创建一项具体的待办事项。
反模式：
- 只表示知道，却不做记录（“我会记住的”并不能让信息留存）
- 只做记录，却不进行路由（应当存在 lint 规则，却只记在脑内备忘中；如果不落实 lint 规则，这样做就毫无意义）
- 只修正，却不总结推广（修正一个实例，却让反复出现的模式继续存在）
评论
支持 Markdown