moyu-en

moyu-en 概览

moyu-en 是做什么的

moyu-en 是一个面向代码工作的最小改动 skill。它会推动模型只改用户明确要求的部分，避免额外抽象，并尽量把 diff 控制得很小。如果你需要一个 moyu-en skill 来防止模型“好心办坏事”式地过度发挥，它就是为这个问题设计的。

适合哪些人

当你在意精准代码修改、严格控制范围，或者需要审查一个总爱顺手做无关清理的助手时，适合使用 moyu-en skill。它很适合维护任务、修 bug，以及单文件改动——这类场景里的主要风险是范围膨胀，而不是架构缺失。

它的不同之处

它的核心价值是克制：不加新依赖，不重写，不补未要求的文档，不额外加测试，也不为根本不可能发生的路径写防御性代码。也因此，moyu-en 更像一条护栏，而不是通用编程提示词，尤其适合精度比广度更重要的 Code Editing 任务。

如何使用 moyu-en skill

安装 moyu-en

在你的 skills 工作流里使用这个 skill，然后确认 skills/moyu-en 是当前生效路径。仓库没有提供自定义安装命令，所以应把 moyu-en install 理解为目录级的配置步骤，而不是一个特殊的脚本安装器。

给 skill 一个窄范围的修改说明

最好的效果来自那种能点明具体文件、具体改动和具体边界的提示词。例如：“更新 src/auth.ts，让 token refresh 只在 401 响应时运行；不要改 tests 或无关 helper。” 这类输入方式符合 moyu-en 的使用模型，也能让 skill 有足够明确的边界去保持克制。

先读对文件

先看 skills/moyu-en 里的 SKILL.md，因为这个 skill 的说明密度很高，而且并没有 rules/、references/ 或 scripts/ 这类辅助目录可依赖。然后再阅读那些定义目标行为的仓库文件，和目标只有间接关系的文件可以先忽略。

一次只做一个受限的改动

想要更好的 moyu-en 指南式工作流，最好先让它给出“最小可接受补丁”，再在看过 diff 之后请求后续修改。如果你确实需要更大的重构，就把它拆成多个提示词，避免 skill 把一个宽泛目标理解成重写整个代码库的许可。

moyu-en skill 常见问题

moyu-en 只适合 Code Editing 吗？

是的，主要就是如此。这个 skill 的目标是控制编辑冲动，不是头脑风暴、架构设计或大范围代码生成。如果你的任务是“以最小影响范围完成这个精确修改”，moyu-en 很合适。

什么时候不该用 moyu-en？

当你真正需要大范围清理、迁移工作、新抽象，或者重构时，不要用它。如果任务需要多个文件联动更新，那么“只改被要求的内容”这条严格规则反而会变成限制，而不是优势。

它和普通提示词相比有什么不同？

普通提示词仍然可能会引导模型顺手优化风格、添加 helper，或者修补边缘情况。moyu-en 会明确压制这种行为，这在主要失败模式是过度修改时尤其有用。实际使用中，moyu-en skill 会收紧助手的自由度，也让 diff 更容易审查。

moyu-en skill 适合新手吗？

可以，只要用户能清楚描述想要的改动。新手会受益于它能减少意外复杂度，但仍然需要提供具体的目标文件、行为或 bug 描述，skill 才能持续有效。

如何改进 moyu-en skill

明确指出边界

最强的输入会同时说明必须改什么、绝对不能改什么。例如：“修复 parser.ts 里的空值检查，但保持格式、注释和无关函数不变。” 这会让 moyu-en 表现更好，因为它和这个 skill 的反过度工程规则是直接对齐的。

描述最小可接受结果

用一句话告诉模型什么算成功，不要列功能清单。如果你想要一个更克制的 moyu-en usage 结果，就要求它给出“只要能修复 bug 就行”的最小侵入式补丁，并明确哪些文件是禁区。

看 diff，不要只看解释

这个 skill 的目标是产出一个小而可审查的改动。拿到第一次输出后，先确认 diff 是否只碰了要求的区域；如果有偏离，再用更严格的提示词继续收紧。对 moyu-en 来说，质量信号通常是补丁本身，而不是旁边那段说明文字。