hoangCreative/skill-upgrade

# skill-upgrade 我原本有一个运行良好的 skill。在大多数情况下它都能胜任工作，当时的诱惑仅仅是 润色一下文字，提升一下版本号，然后称之为“升级”。后来，我把它交给了一群 专门负责挑错的 agent 进行测试，结果我眼睁睁看着它令人信服地履行了 自身的规则，报告自己已达标，但最终依然违背了自己的 准则。那天我才明白，“让它更好看”并不等于升级。 真正的升级，始于指出 skill 崩溃的地方。 这是一个将那个 skill 从“勉强能用”提升至“发布级”乃至更高级别的过程， 我将其记录下来，是为了让它能适用于任何行为类的 skill，而不仅仅是 它最初来源的那个。 ## 贯穿始终的两条规则 1. **升级需要一个明确的目的。** 不要为了粉饰而升级。指出当前 版本错在哪里、谁会受到损害，以及一个“让陌生人也能直接用”的 版本能带来什么。没有明确指出的缺陷，就不算升级。 2. **亲口尝尝自己的狗粮。** 整个过程必须遵循它所升级的 skill 的 准则。要硬化一个验证类的 skill？那么升级过程中的每一项主张 本身也必须有理有据或被明确标记为未经验证。一个如果连应用到 自身的升级过程都撑不过去的 skill，就还没成型。 ## 首先，对 skill 进行分类 在进行任何步骤之前，先对 skill 进行分类：reflex（反射型）、module（模块型）或 engine（引擎型）。这个类别决定了 流程的繁重程度，这样就不会把一个四十行的 reflex skill 强行塞进 与完整的 engine 相同的 pipeline 中。reflex skill 可以跳过正式的测试 库和贡献基础设施；而 engine 则需要全套配置。不要构建 skill 根本用不到的繁杂流程。 ## 七个步骤（步骤 5 至 7 仅在向他人发布时需要） 1. **在落笔前明确缺陷规范，锁定架构。** 2. **大规模压力测试**，召集一个旨在破坏它的 adversarial council（对抗委员会）， 然后划定明确的边界：CUT（删减）、KEEP（保留）、FIX（修复）、ADD（新增）。 3. **重写并扎根于真实的现有成果，优先参考社区资源**，绝不依赖记忆。 将方法论写成带有引用说明的故事，包括它曾经失效的地方。 4. **将通用引擎与受上下文绑定的部分分离开来**，这样特定文化或 领域的内容就不会占据规范化的核心位置。 5. **规范化测试 apparatus**：提供别人也能运行的 fixtures、固定的 regression bank（回归测试库），以及一份简短的 tests README。 6. **构建无需守门人也能维持高标准的贡献基础设施**： 一套强制执行标准的评估准则，以及强制执行机械规则的 CI。 7. **审计、版本控制、打包。** 发布与否由作者亲自把关。 完整的分步指南（每一步背后的详细示例）都在 `SKILL.md` 中。 ## 超越 100% 达到基准线只需前七个步骤。想要超越它，还需要最后一步：找出 基准 skill 做不到而当前 skill 可以做到的事，然后实现它。最强大的 版本是这样一个 skill：它会明确指出自己的能力天花板，说明文字描述的 局限性，并为突破上限设计好对应的 harness（测试套件）。 ## 适用边界 这是一个流程，而不是保证。它能让一个 skill 变得诚实且可复现； 但它无法让一个糟糕的想法变得有价值，而且如果你 跳过了某个步骤，它也无法自我执行。这种准则的效果完全取决于 执行者的用心程度，这就是为什么会有规则二的存在：这个流程本身也必须 能够经受住应用于自身的考验。它是从一次真实的升级中 提炼出来的，所以当你在自己的 skill 上运行它时，它会暴露出 这七个步骤未能预见到的失败。这正是流程在发挥作用，而不是 流程失效了。 ## 不适用场景 如果 skill 没有明确指出缺陷，或者只是一个需要简单编辑就能搞定的琐碎修复， 而非一套流程，就不要运行它。这七个步骤是针对真正的版本跃升的。 ## 安装 ``` cp -R skill-upgrade ~/.claude/skills/ ``` 重新加载你的 assistant。`name` 字段将作为触发器。 ## 作者 Le Cong Hoang (LCH)。采用 Apache-2.0 许可，详见 `LICENSE`。提炼自 what-for-and-how 从 v2 到 v3.1 的升级过程。

标签：AI智能体, DLL 劫持, 人工智能, 大语言模型, 开发流程, 用户模式Hook绕过, 防御加固