moyu-ko
作者 uuczmoyu-ko 是一套代码编辑技能，强调把改动控制得尽量小、尽量聚焦、尽量便于审查。它通过只修改被要求的文件、优先采用最简单的修复方式，以及在范围不明确时先提问，来帮助避免过度工程化。若你想要精确的 diff、聚焦的 bug 修复，以及一份面向纪律化代码修改的实用 moyu-ko 指南，就适合使用这个 skill。
这个 skill 的评分是 68/100，说明它可以上架，但更适合被定位为一个专注、带明确观点的工作流辅助，而不是那种各方面都打磨完善的通用安装项。对目录用户来说，它的使用场景很清晰——防止代码改动过度工程化——但仓库缺少配套文档和操作资产，因此在采纳前仍会有一定的理解成本。
- 触发条件非常明确：frontmatter 明确写出，当检测到过度工程化模式时会激活，并且还提供了详细的 9 条触发列表。
- 操作意图很强：正文定义了以最小 diff、范围受控的改动，以及在扩展工作前先询问为核心的具体编辑理念。
- 对小众目标用户的安装决策价值高：这个 skill 对适用场景和行为约束都说得很具体。
- 支撑性基础设施较少：除 `SKILL.md` 外，没有脚本、参考资料、资源、规则或 readme 来进一步说明用法。
- 说明文字非常短，而且仓库缺少工作流示例，用户需要自己推断 agent 在真实任务中应如何应用这套策略。
moyu-ko 技能概览
moyu-ko 的用途
moyu-ko 是一款代码编辑技能，目标是在过度设计还没开始前就把它拦住。它帮助 AI 只做最小且正确的改动，保持在用户要求的范围内，并避免额外引入抽象、测试、文档或依赖，除非用户明确要求。
适合安装的人群
如果你经常希望 AI 在现有代码上打补丁、修一个局部 bug，或者做一次不重写的最小修改，那么就适合安装 moyu-ko skill。它尤其适合重视精确 diff、评审效率，以及尽量降低实现变动的团队。
它的不同之处
和那种只会说“简洁一点”的通用提示词不同，moyu-ko 内置了明确的护栏：只改要求中的文件，优先最简单的实现，需求不清楚时就停下来追问。这让它在 moyu-ko for Code Editing 这类需要控制范围、而不是大刀阔斧重构的场景里特别有用。
如何使用 moyu-ko skill
安装并激活
按目录里的标准流程完成 moyu-ko install 这一步，然后把它用在一个明确属于代码编辑的任务上。比较合适的触发方式是这样的提示词：“Use moyu-ko to make only the minimal change needed to fix this bug in src/auth.ts.”
给技能一个有边界的任务
moyu-ko usage 的最佳效果来自清晰的边界说明，最好明确写出：
- 要修改的具体文件或路径
- 期望的行为变化
- 哪些内容不能改
- 已知约束，例如“no new dependencies”或“do not add tests”
更好的输入：
Update
src/cart.tsso the discount only applies to logged-in users. Do not change other pricing logic or create new files.
不够好的输入：
Improve the checkout flow.
先读对的文件
如果想要最顺手的 moyu-ko guide 工作流，先看 SKILL.md，再检查仓库里定义变更边界的那些文件。由于这个技能仓库刻意做得很小，它的核心价值在于理解行为规则，而不是去找一堆额外的支持文件夹。
明确要求最小 diff
如果你希望这个技能发挥得好，要直接要求“尽可能小的修改”，并说明任何硬性限制。例如：
Use moyu-ko to patch
api.ts. Change only the validation branch, avoid new helpers, and ask before touching any other file.
moyu-ko skill 常见问题
moyu-ko 只适合代码编辑吗？
是的，这就是它的设计用途。moyu-ko skill 面向的是有纪律的编辑，不是广泛的规划、架构设计，或从零搭建脚手架。如果你需要的是重构设计，普通提示词可能更合适。
什么时候不该用 moyu-ko？
当你其实希望 AI 探索多种方案、补充测试，或者顺手清理相邻代码时，就不该用 moyu-ko。它的价值在于控制范围，所以面对开放式重构时可能并不匹配。
它对新手友好吗？
如果你能把要改什么说清楚，那它是友好的。这个技能的规则并不复杂，但只有在请求本身已经有边界时，它的表现才最好。新手想拿到好结果，最重要的是写清文件名、行为目标和“不要碰什么”。
它和普通提示词有什么不同？
普通提示词也可以要求最小改动，但 moyu-ko 把这变成了默认工作模式。这样一来，当你只是想做一次聚焦修改时，就能显著降低误改、额外抽象或多生成文件的概率。
如何改进 moyu-ko skill
把范围指令收紧
提升质量最明显的一步，就是收窄编辑面。明确写出具体文件、要改的最小片段，以及你期望的结果。要求越精确，moyu-ko 就越不容易因为要澄清而卡住，也越不容易改过头。
加上明确边界
如果有内容必须保持不动，就直接说明。实用的边界包括：
- “no new helper functions”
- “no new dependencies”
- “do not change public APIs”
- “keep the diff under 10 lines if possible”
这些约束能帮助 moyu-ko for Code Editing 输出更适合评审的结果。
任务不明确时，接受它提问
一种常见失败模式，是把目标说得太少，却希望模型自动补全剩下的内容。如果请求可能影响其他文件，或者需要新的抽象，moyu-ko 就应该先停下来追问。这是特性，不是缺陷。
先迭代第一版补丁，不要先扩大战略
如果第一次输出范围太大，不要把任务越改越大，而是收紧下一条指令。比如，要求“only the line that parses the input”，而不是“clean up the module”。这样才能让 moyu-ko usage 始终贴合它的最小改动设计。