moyu

moyu skill 概览

moyu skill 是做什么的

moyu skill 是面向代码改动的编辑护栏：它会推动模型始终待在用户要求的范围内，避免不必要的抽象，并优先给出最小且安全的 diff。如果你想要一个能抵抗过度设计的 Code Editing skill，moyu 就是专门为这个目的打造的。

适合谁使用

当你更看重准确性而不是覆盖面时，就该用 moyu skill：修一个 bug、改一个文件、缩小 diff，或者回应那种“请只改 X”的需求。它尤其适合审阅者、维护者，以及在成熟代码库中工作的 agent，因为额外的清理动作可能会引入风险。

它为什么更突出

它最核心的差异点，是对克制的强偏好。这个 skill 明确反对引入新依赖、大范围重写、额外校验、测试、注释和 helper 层，除非用户特别要求。也正因为如此，moyu 很适合真实项目里的编辑场景：真正的危险往往不是漏掉一个功能，而是改得太多。

如何使用 moyu skill

安装并激活 moyu

先把 moyu skill 安装到你的 agent skills 目录里，然后确保你的编码工作流在编辑前会加载它。一个典型的安装方式是 npx skills add uucz/moyu --skill moyu。如果任务提示本身就强调克制，比如“只更新这个函数”或“保持改动最小”，开启它的效果最好。

给 skill 一个足够窄的需求

moyu skill 最适合这样的提示词：明确写出必须修改的文件、函数、行为或输出。好的输入例如：“在 src/auth.ts 里只修复 token refresh bug；不要重构，也不要新增文件。” 像“改进 auth”这种模糊说法会给扩展留太大空间，也会削弱 moyu 的意义。

先读对文件

先看 SKILL.md，然后再检查你实际要修改的文件，以及能说明本地约定的相邻上下文。因为这个 repository 故意保持轻量，所以没有额外的脚本或支持目录来引导你；核心价值就在 skill 文本本身。最好的工作流是：先读 skill，定义最小可编辑面，再开始执行。

按 moyu 期望的方式工作

使用 moyu 做 Code Editing 时，先要求最小修复，然后只在结果仍然偏离目标时再迭代。如果还需要更多修改，把它放到第二次请求里，不要在第一次就把范围扩大。这样能保持 diff 小、让审阅更轻松，也更符合这个 skill“只改用户要求内容”的规则。

moyu skill 常见问题

moyu 是一个全功能编码助手吗？

不是。moyu skill 的重点不是尽可能覆盖更多场景，而是限制范围、避免不必要的改动。如果你需要大范围重构、脚手架搭建或架构层面的帮助，通用编码提示词可能比 moyu skill 更合适。

什么时候不该用 moyu？

当任务确实需要跨文件协作、新抽象，或者系统性清理时，不要用 moyu。如果目标是“把架构弄得更清爽”或“补上缺失的测试套件”，这个 skill 的克制反而会变成限制，而不是优势。

moyu 适合初学者吗？

适合，前提是初学者想要更安全的编辑结果，并尽量减少意外改动。moyu 指南对那些容易过度要求模型、或者容易接受过大 diff 的人尤其有帮助。它传递了一个很实用的默认原则：只要求能解决问题的最小改动。

这和直接告诉模型“要小心点”有什么区别？

普通提示词当然也可以要求谨慎，但 moyu skill 是把这种偏好硬编码成了可复用的编辑策略。这在你需要反复获得 minimal-diff 行为时尤其重要，而不只是某一次临时提示。

如何改进 moyu skill

把需求写得更小、更明确

提升 moyu 输出最有效的方法，就是在第一次编辑前先消除歧义。写清楚准确的文件路径、必须保留的行为，以及你想要的具体改动。例如：“只编辑 components/Button.tsx；保持 props 不变；只修复 disabled 样式。”

明确哪些内容不能改

当你告诉它什么不能动时，这个 skill 的效果最强。可以明确写出“不要新建文件”“不要新增依赖”“不要改变 API 形状”或“不要重写整个函数”。这能帮助 moyu 对齐用户真正的意图，而不是朝着一个更宽泛但并不想要的方向优化。

先看第一版 diff，再继续收紧

如果第一次结果还是太大，就把超出的部分反馈回去，并要求更窄的一轮修改。常见失败模式包括额外清理、添加抽象层，或者加入并未要求的防御性代码。最好的 moyu 工作流是迭代式的：先约束，再审阅，然后继续收紧，直到 diff 和需求完全一致。