别再只盯着 SKILL.md 格式，Skill 真正难的是内容设计
这条帖子如果只被读成“又有五个 Skill 模式可以背”，价值会很有限。它真正点破的一件事是：当 SKILL.md、frontmatter、references/、assets/ 这些规范逐渐被多种 Agent 工具接受之后，Skill 的难点已经从“怎么打包”转成“怎么组织内容和控制失真”。
所以我不想把这篇文章再写成五种模式逐条科普。更有用的读法是，先判断你的 Skill 到底是哪一种失控，再选对应模式，最后再谈怎么组合。
原帖列出的五种模式其实分别对应五种常见失控点：
- agent 一进入某个技术域就容易乱写，缺的是领域边界，用
Tool Wrapper。 - 每次都能产出，但结构总在漂，缺的是输出骨架，用
Generator。 - 审查标准会变，流程却不该反复重写，缺的是规则与流程分离，用
Reviewer。 - 输入信息明显不够，agent 却急着往下猜，缺的是前置澄清，用
Inversion。 - 多步骤任务经常跳步漏检，缺的是阶段门禁，用
Pipeline。
这样看，五种模式不是五个并列的“写法”，而是五种不同的控制点。你先看见的是哪一种失真，才知道该把控制力放在哪里。
Tool Wrapper 控制的是知识边界。适合把框架约定、团队规范、领域术语放进 references/ 按需加载，目的不是让 agent 更博学，而是别在特定场景里偏离共识。
Generator 控制的是输出形状。模板放在 assets/，风格和缺失字段规则放在 Skill 正文或参考资料里，重点是把方差压下去，而不是追求文风自由。
Reviewer 控制的是审查一致性。把 checklist 和 rubric 当独立资产维护，Skill 负责跑审查流程，这样标准变了只换规则，不用重写整套审查协议。
Inversion 控制的是假设扩散。它要求 agent 先问清楚目标、约束、环境、非功能要求，再继续生成，适合那些一旦脑补就会把错误一路放大的任务。
Pipeline 控制的是执行顺序。关键不是步骤多，而是每一步都要有 gate，前一步没过，后一步就不能开始。
原帖最后真正重要的一点，是这些模式本来就应该组合使用，而不是互斥选择。
比如变量很多的生成任务，往往先用 Inversion 把输入补齐，再用 Generator 填模板；高风险流程则常常用 Pipeline 控制顺序，再在尾部接一个 Reviewer 做交付前检查；Tool Wrapper 也完全可以只作为大流水线中的一个阶段，为某一步提供领域知识。
这背后的工程含义很直接：Skill 不是一段更长的 prompt，而是一组可拆分、可组合、各自负责一种失真的结构件。你如果试图用一段大说明文同时解决知识、模板、评审、提问和门禁，最后往往五件事都做不稳。
这条帖子真正有价值的地方，不是教你记住五个名词，而是给了一个更实用的设计顺序：
- 先判断当前 Skill 最容易在哪个环节失控。
- 为这个失控点选最小模式，不要一开始就全都上。
- 只有在单一模式不够时，再通过组合增加知识、模板或门禁。
Skill 设计已经越来越像内容工程，而不是格式工程。今天真正拉开效果差距的，不是谁更会写 YAML，而是谁更会先给问题分型，再给对应的失真点上控制。