moyu-fr

moyu-fr 技能概览

moyu-fr 是一款面向容易过度实现的 agent 的代码编辑护栏技能。它专为那些希望获得“最小且正确改动”的用户设计，尤其适用于只需修改被点名的几行，而不是重写文件、增加抽象层，或在超出范围的地方“顺手优化”代码的场景。

moyu-fr 适合做什么

moyu-fr 最适合补丁式工作：外科手术式修复、局部重构、一次性 bug 修补，以及用户明确要求“简单”“最小改动”或“只改 X”的响应。它能帮助 agent 始终对齐真正要完成的任务：完成请求中的改动，然后停下。

这个技能为什么不一样

和通用 prompt 不同，moyu-fr 编码了明确的反过度工程规则。它会抑制新增层级、额外依赖、为不可能发生的情况写防御性代码，以及无关的文档或测试。这让它特别适合以克制而不是覆盖面作为质量标准的场景。

最适合的人群与不适合的场景

当代码库或任务对 diff 大小、架构漂移或不必要清理很敏感时，用 moyu-fr 做代码编辑最合适。若你真正想要的是重设计、功能扩展、创建测试，或大范围的代码库现代化，那么它就不太匹配，因为这个技能的优化目标就是尽量减少改动。

如何使用 moyu-fr 技能

安装并确认激活路径

先按仓库提供的技能安装流程安装 moyu-fr，然后确认 agent 能从你的编辑请求中识别到这个技能。只要你的工作流本来就强调严格的范围控制，并希望技能在出现过度工程信号时自动介入，那么 moyu-fr install 的收益就最明显。

给它一个窄而清晰的编辑说明

moyu-fr usage 最理想的用法，是边界明确的精确请求。好的输入会写清目标文件、具体行为变化，以及哪些内容不能变。

强请求示例：

• “编辑 src/auth.ts，修复 validateSession 里的空值检查；不要改错误处理，也不要加 helper。”
• “只更新 README.md 示例里的正则表达式；其余代码片段保持不变。”

弱请求通常很宽泛：

• “改进认证流程”
• “整理这个模块”
• “让它更健壮”

这类 prompt 很容易引发范围扩张，而这正是这个技能要避免的。

先读对文件

如果你想按实战方式使用 moyu-fr，先从 SKILL.md 开始，再查看仓库里链接的任何说明或任务专用文件。在这个技能当前形态下，最主要的信号就在技能正文里，所以最有价值的阅读路径就是：说明文档、仓库目录结构，以及你马上要修改的那些文件。如果你连目标是什么、最低可接受 diff 是什么都说不清，说明 prompt 还是太模糊。

把它当作克制过滤器，而不是重写引擎

这个技能最好在你已经知道期望结果、只想阻止多余改动时使用。它应该把 agent 的编辑方向约束到：

• 最少的行级改动
• 除非明确要求，不新增抽象层
• 除非明确要求，不额外加文档、测试或注释
• 补丁足够时，不重写整个文件

moyu-fr 技能常见问题

moyu-fr 只适合代码编辑吗？

是的，moyu-fr 最强的适用场景就是带有严格范围控制的代码编辑。它对开放式生成、架构规划，或本来就预期会增加额外支架的任务帮助不大。

它和普通 prompt 有什么区别？

普通 prompt 可以说“保持简单”，但 moyu-fr 会把这种偏好变成更强的运行规则集。当 agent 容易顺手解决相邻问题、重写周边代码，或者加入原本并未要求的润色时，这一点尤其重要。

moyu-fr 适合新手吗？

适合，只要用户能描述一个具体改动。只要你能说清文件名、症状和编辑边界，它就很好用。新手最容易卡住的地方，通常是需求太宽，而不是这个技能本身难。

什么时候不该用 moyu-fr？

当你确实需要重构、测试覆盖、新抽象，或系统加固时，不要用它。在这些情况下，技能的克制可能会和真实目标相冲突，最后产出虽然“改动最小”，但并不完整。

如何改进 moyu-fr 技能

一开始就给出更严格的约束

提升 moyu-fr 的最好办法，是明确哪些内容必须保持不变。把文件名、目标行，以及“不要新增函数”“不要加额外注释”“不要改动这个 block 外的格式”等排除项写出来。这些约束能减少猜测，让技能的最小改动行为更稳定。

直接要求最小可接受 diff

如果你想让 moyu-fr usage 的结果更好，就用 diff 的语言来描述成功：

• “只改一个分支条件。”
• “修补现有函数，不要新建 helper。”
• “保留当前公开 API。”

这样 agent 就知道什么叫“完成”，也能避免范围膨胀。

留意常见失败模式

最常见的失败模式是无意扩张：多加校验、多写解释，或者做一些看起来有帮助但实际上改动超出需求的清理。另一个常见问题是改动不足：当请求确实需要多个小改动时，技能可能过早停下；这时应把全部必要修改明确列出来，让它不要停得太早。

用更窄的追问持续迭代

如果第一次结果还是太宽泛，就收紧下一条指令，而不是重复同一句请求。比如，“保持相同逻辑，只调整这个条件”比“把它改小一点”更有操作性。对于 moyu-fr 来说，更好的输入通常意味着更少的自由度，而不是更多上下文。