Matt Pocock 发布 writing-great-skills 技能，提出 5 种失败模式自检法
- Skills For Real Engineers 作者 Matt Pocock（152K 关注者）发布了一个专门教人写 Skill 的 Skill，名为 writing-great-skills
- 核心主张：Skill 的目标是让模型行为可预测，减少同类任务时做得细或做得浅的波动
- 提出 model-invoked（模型自动发现触发）与 user-invoked（用户点名触发）两种方式的成本权衡
- 用三层信息结构（步骤 / 参考 / 外部参考文件）做渐进式披露，避免主文件塞满内容稀释注意力
- 定义 5 种常见失败模式（premature completion、duplication、sediment、sprawl、no-op），并给出「删掉这句话模型行为变不变」的 no-op 测试作为判断标准
写 Skill 这件事，现在也有了一份说明书
Skills For Real Engineers 作者 Matt Pocock 最近发布了一个教人写 Claude Skill 的 Skill，名字就叫 writing-great-skills。
原作者 @mattpocockuk 拥有 152K 关注者。这个 Skill 的落点不是又一句「要精简」的建议，而是给出一个能直接判断的动作：删掉某句话后，模型行为到底变不变；并把常见毛病命名成 5 种可对照的模式，逐个能查。
全文的锚点：好 Skill 把内容分三层放，用不到的不占注意力
Skill 写坏了会怎样
Skill 的作用不是当知识库，也不是把提示词一堆堆在一起。它要让模型在某一类任务里走出一条稳定的行为路径。判断好坏的标准很朴素：同一类活儿，这次做得细、下次做得浅，就是没写好。
内容越堆越多，模型每次抓到的重点不一样，做深做浅全凭运气，结果没法预期。
同一类任务每次都走同样的步骤，做到什么程度是可预期的，波动被压下去。
该让 AI 自己发现它，还是等你点名
一个 Skill 怎么被用起来，有两条路，各带各的代价。它把 Skill 分成两类。
Model-invoked
模型自动发现并调用
- 谁来触发
- 模型自己识别任务，主动调它
- 优点
- 用户不用记得它存在
- 代价
- 它的 description 会长期占用上下文注意力
User-invoked
用户点名才触发
- 谁来触发
- 只有用户明确点名才会启动
- 优点
- 零上下文负担
- 代价
- 用户必须记得它存在
不是所有 Skill 都该自动触发。只有当模型确实需要自己识别任务，或别的 Skill 要调用它时，才值得做成 model-invoked；否则默认走 user-invoked，省掉那份注意力成本。
description 不是简介，是开关说明
对 model-invoked 的 Skill，description 的职责不是把功能介绍全，而是准确告诉模型「什么时候该用我」。很多 Skill 写坏，就坏在 description 写成了产品简介，而不是调用条件。
「这是一个功能强大的代码审查 Skill，能帮你发现 bug、优化性能、提升可读性，适合各种项目。」全是自我介绍，没告诉模型何时该用。
触发词前置：「审查 diff、检查改动、找 bug 时使用。只审当前改动，不审全库。」前置关键触发词，只留真正不同的分支，去掉同义重复。
东西不是越全越好，是分层放对地方
好的 Skill 不把所有东西塞进主文件，而是分三层来放。哪层放什么，决定了这个 Skill 读起来清不清爽。
常用、必须、影响流程的内容留在主文件里；分支性、解释性、定义性的内容放到外部文件，需要时才通过一个明确的指针去查。用不到的东西就不占模型的注意力。
就像说明书正文只写操作步骤，型号参数表放在附录里，用不到就不用翻开。
点上面任意一层看它放什么、什么时候加载
怎么让 AI 不会没做完就说做完了
每个步骤都要带一个完成标准。一个步骤不能只写「分析清楚」「完成检查」这种模糊目标，要让模型能自己判断「到底算不算做完了」。
完成标准越清楚，越能挡住模型提前跳到下一步，也就是它说的 premature completion（过早完成）。
过早完成，就像学生只写了作业标题，就说作业写完了。
步骤写「分析清楚这段代码」「完成检查」。模型没法判断到底算不算做完，可能扫一眼就跳到下一步。
步骤写「逐个函数确认输入边界已处理，并在回复里列出每个函数的检查结论」。模型能对着标准判断自己是不是真的做完了。
一个词顶一整段要求
它提出一个概念叫 leading word：找一个模型在预训练里已经很熟、自带一整套行为联想的强概念词，用它替代一长串啰嗦的行为要求。好处有两个，省 token，而且更容易稳定唤起模型已有的那套行为。
说「请像审计员一样检查」，比说「请仔细、严格、逐项、不要遗漏地检查」更省字也更管用，因为「审计员」这个词自己就带着一整套模型已经理解的行为模式。
它也提醒：弱词可能无效。比如写一句「be thorough（要认真）」，如果这只是模型默认就会做的程度，那这句话加了等于没加，需要换一个更有约束力的词。
5 种病，1 句话测出该删哪句
writing-great-skills 把 Skill 常见的毛病命名成 5 种失败模式，配一个统一的判断动作。点下面任意一种，看它的定义、一个写坏的例子和对应修法。
模型在步骤还没真正做完时，就误以为已经完成，提前跳到下一步。
同一个意思出现在多个地方，抬高维护成本，还会让某个概念被模型过度重视。
语言：中文」，三处同义。旧内容留着没人敢删，日积月累，Skill 越来越脏。
--legacy 参数」，但 v1 早就下线了，这句话一直躺着没人动。内容都有效，但主文件太长，注意力被稀释。
看着有用、实际不改变模型行为的句子。
be thorough（要认真）」，但这只是模型默认就会做的程度，加了等于没加。判断一句话该不该留在 Skill 里的方法：把它删掉，看模型的实际行为有没有变化。删了也没变化，说明这句话是废话，该删。
一句话如果删掉后模型行为几乎不变，它就不该留在 Skill 里。 writing-great-skills，via X @shao__meng