什么值得记录什么不该记录one-skill-to-rule-them-all观察信号判断清单附真实案例【免费下载链接】one-skill-to-rule-them-allThe meta-skill that builds and improves all your skills, including itself. Watches your work sessions (autonomous or human-led), captures patterns, corrections and judgement calls, and turns them into skill improvements and new skill candidates for your review. Practical application of the Augmented Expertise methodology. Open source: CC BY 4.0.项目地址: https://gitcode.com/gh_mirrors/on/one-skill-to-rule-them-allone-skill-to-rule-them-all 是一款开源的元技能meta-skill它会监视你的 AI 工作会话把其中的模式、纠正和判断转化为技能改进与新技能候选。但用好它有个大坑记录太少技能永远不成长记录太多日志被噪音淹没。这篇文章提炼了项目官方的观察信号判断清单并附真实案例一次讲清什么值得记录什么不该记录。30秒理解task-observer 元技能如何工作它的核心理念只有一句话技能最好的改进来自真实工作中被注意到的摩擦而不是坐下来专门改进技能。你照常干活—— 不需要停下来想怎么优化技能它在后台观察—— 名为task-observer的元技能在整个会话中捕捉摩擦会话结束时复盘—— 每条观察记成一个小 Markdown 文件Issue → Improvement → Principle技能库随时间进化—— 作者已积累 1500 条观察其中大部分技能本身就是由这些观察催生出来的。 它连自己也会观察改进 —— 所以叫统治所有技能的那一个技能。三大类观察信号什么值得记录速查表完整目录见 references/signals.md共三大类信号 信号一新技能诞生的线索可复用的多步骤工作流你讲解的、现有技能没有覆盖的方法论反复出现、结构相似的任务类型有明确输入、阶段、输出的流程你脱口而出我一直都是这么做的 信号二现有技能需要改进的线索AI 违反了技能里写明的规则需要的是更强的执行机制不是更响的警告你的某次纠正暴露出缺失的规则或边界情况出现了比技能推荐更好的工作流新工具让技能的某个步骤过时纠正反复出现、形成模式某条原则适用于其他技能✂️ 信号三技能需要精简的线索很多会话里从未相关的章节来自单次未经验证观察的规则AI consistently 执行不了的规则改成结构性执行或直接删除相互矛盾的规则、从未触发过的以防万一复杂度⚖️ 复盘时要像问该加什么一样认真地问该删什么。泛化性四问记录前的过滤器不是所有摩擦都值得记录。项目提供了 4 个泛化性自检问题#自检问题目的1这个纠正放到别的项目还有意义吗排除项目特定背景2对同一技能的其他任务也适用吗排除一次性任务3它指出了缺失的规则/步骤/原则而不只是修好这一次吗区分经验与补丁4有证据表明它可能再次发生吗排除偶发事件答案大部分是否 → 把它当任务上下文处理而不是观察。 真实案例一条任务级事实如何改写成技能级经验某次会话中用户偏好模块放在单一仓库里。生硬地记录会写成❌ 用户偏好把模块放在单一仓库 —— 只对这个用户、这个项目、永远成立一次。正确的记法项目原文给出的改法✅ 技能缺少关于共享模块何时应该集中化的决策指导。前者修好一个任务后者指向一条缺失的规则。知道何时不该学习和捕捉信号同样重要—— 从孤立例子中过度学习正是技能滑向过度特化复杂度的原因。这四类内容永远不要记录官方文档的 Do NOT log 清单明确列出了不该进入日志的内容不能泛化的一次性纠正—— 比如某仓库临时约束逼出来的决定技能里已记录在案的偏好—— 重复记录只会制造噪音与方法论无关的工具 bug—— 那是工具的问题不是技能的问题必须依赖专有客户信息才有用的观察—— 除非它本该放进internal内部技能。还有一个隐蔽的过度记录陷阱项目实测发现91 条未解决观察里约 40 条只是同一发现的换汤不换药。所以记录前先查同名条目 —— 如果是同一个发现的重新表述把新例子追加到旧条目里不要新建文件。真实案例一条规则破了 3 次为什么第 3 次才起作用这是 references/signals.md 里最出名的案例某条写明的规则在三个不同会话中连续被打破发生次序当时记录的建议实际改变第 1 次规则被破坏加一个写后检查改了措辞第 2 次规则又被破坏措辞更强烈第 3 次这里需要的是屏障不是规则加了一个会直接拒绝该调用的钩子只有第 3 次真正改变了结果。前两次不是不认真而是只有文字可改这个循环的自然产出。由此得出项目的一条硬规则同一条规则第 2 次被打破时停止改文案开始建屏障—— 拒绝调用的钩子、让产物失败的 lint 检查、让错误操作不可用的默认值。更响的警告仍然只是警告。另一条边界规则同样值得记未解决的缺陷也值得记录但只在边界点—— 当一个与交付物无关的 bug 已经消耗掉第二个假设时就停下第 5 轮排查把症状、已排除什么、最便宜的下一个验证记成观察然后回到正事。这份带证据的问题报告本身就是合格的交付物。观察心态什么时候开着什么时候关着很多新手以为它只在干活时记录官方答案恰好相反✅整个任务会话都开着—— 执行、任务后反馈、复盘讨论、关于技能和方法论的元讨论、工作策略对话⭐复盘阶段的反馈往往是信号最高的输入—— 别在话题从做转向聊时就关闭观察❌只有两种情况关着—— 闲聊、不涉及工具和交付物的快速事实问答。正确记录一条观察Issue → Improvement → Principle每条观察是一个小 Markdown 文件正文三部分完整格式见 SKILL.md部分写什么要点Issue发生了什么具体到几周后不用翻聊天记录也能看懂Suggested improvement具体改动现有技能指明章节/规则新技能给范围与关键组件Principle可泛化的结论最重要的字段两个分类要点开源 vs 内部默认按开源处理可泛化、对同行有用含客户/项目细节的归internal。这条边界同时也是保密边界—— 拿不准时宁可先记为内部以后再提升正确的家不是技能比如某个指令文件、某份登记表时把目标文件路径写进target_file不要硬塞进最近的那个技能。实操观察清单建议收藏场景该怎么做你纠正了 AI且纠正对其他项目也适用✅ 记录改进信号同一套多步骤流程你反复手动做✅ 记录新技能信号发现技能里某条规则从来没用过✅ 记录精简信号AI 第 2 次违反同一条规则✅ 记录且建议改为结构性屏障只对一个项目成立的一次性偏好❌ 不记录当任务上下文技能里已有记录的偏好❌ 不记录与方法论无关的工具 bug❌ 不记录日志里已存在的同一发现 往旧条目追加例子别新建文件如何上手 关键文件路径想亲自试试把仓库文件交给你的 AI让它引导你完成适配把 SKILL.md、references/ 和 scripts/ 三个部分放在一起使用git clone https://gitcode.com/gh_mirrors/on/one-skill-to-rule-them-all本文清单对应的关键文件路径作用SKILL.md元技能核心规则何时观察、如何记录、如何复盘references/signals.md观察信号完整目录本文清单的来源references/observation-log.md观察日志的格式、编号与归档规则references/weekly-review.md定期评审流程USER-GUIDE.md面向普通用户的实用指南一句话总结记录不是比多而是比准。让每条摩擦先过一遍四问过滤器把任务特有的上下文挡在门外只让能泛化、可能复现、指向缺失规则的经验进入日志 —— 你的技能库才会随每次使用复利增长而不是随噪音一起膨胀。【免费下载链接】one-skill-to-rule-them-allThe meta-skill that builds and improves all your skills, including itself. Watches your work sessions (autonomous or human-led), captures patterns, corrections and judgement calls, and turns them into skill improvements and new skill candidates for your review. Practical application of the Augmented Expertise methodology. Open source: CC BY 4.0.项目地址: https://gitcode.com/gh_mirrors/on/one-skill-to-rule-them-all创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考