moyu-strict

moyu-strict 技能概览

什么是 moyu-strict

moyu-strict 是一个用于代码编辑的 guardrail 技能，专门强制执行严格的反过度设计规则。它适用于你只想做最小且安全的改动，而不是把代码顺手“顺一遍”做成更精致的重构。它的核心任务，是在满足需求的同时，阻止 agent 去碰额外文件、引入抽象层，或者擅自“优化”无关代码。

适合谁使用

moyu-strict 适合审查者、维护者，以及在现有代码库里处理边界很清晰的修复工作的 agent。如果你在意最小 diff、可预测的审查过程，以及避免误伤副作用，moyu-strict for Code Editing 会非常合适。它不太适合探索性重构、架构调整或大范围清理任务。

它有什么不同

真正的差别在于“强约束”。moyu-strict 不是一个泛泛的“把代码写得更好”的 prompt；它的重点是范围控制、编辑纪律和克制。它最强的信号来自明确的规则集：编辑前先确认范围，不要新增抽象层，不要添加未要求的文档/测试/依赖，并且一旦改动开始变得比需求更大，就立刻停下来。

如何使用 moyu-strict 技能

安装并启用它

按照仓库里 moyu-strict install 的技能安装流程来装好它，然后在你预期会有代码改动、而且改动必须保持很小的时候加载它。如果你的环境使用的是基于命令的安装器，关键点是在模型开始编辑之前就挂上 moyu-strict，这样约束会先影响第一版输出，而不只是后续审查。对于 moyu-strict usage，只要任务是定点修复而不是设计讨论，就应该启用它。

先读对文件

先从 skills/moyu-strict/SKILL.md 开始读，因为这里就是严格规则和启用行为的来源。由于这个仓库只有一个 skill 文件，没有辅助脚本、引用文件或规则目录，所以不需要去追隐藏的 workflow 树。用户真正需要的是规则文本本身，而不是一趟额外的仓库导览。

把模糊任务改写成严格 prompt

这个技能最有效的前提，是请求里已经明确写出目标和边界。好的输入可以像这样：“修复 src/parser.ts 里的空值崩溃，只能改这个文件；不要加测试、注释或重构。” 不好的输入则像：“把这个模块优化一下。” 前者给了 moyu-strict 可约束的空间，后者只会让范围继续漂移。

在编辑确认流程里使用它

一个合适的 moyu-strict guide 流程是：先识别受影响的文件或函数，说明要改什么，确认不需要动其他文件，然后再编辑。如果任务看起来需要更大范围的变更，就停下来问一句：是否接受更小的版本。这正是这个技能最严格的价值所在——在过度扩张变成 diff 之前，把它显性地暴露出来。

moyu-strict 技能 FAQ

moyu-strict 只是普通 prompt 吗？

不是。普通 prompt 可能会要求代码简洁，但 moyu-strict 的重点是强制编辑边界。它最有价值的场景，不是逻辑容易写错，而是最容易多改一堆不必要内容的时候。

什么时候不该用它？

如果任务确实需要协同重写、新抽象、文档刷新或测试脚手架搭建，就不要用 moyu-strict。如果结果本来就应该包含更大范围的清理，这个技能偏向“最小 PR”的倾向反而会和真实目标冲突。

它适合新手吗？

适合，因为规则简单而具体。新手最常见的错误，是提一个很模糊的请求，却期待技能自己推断边界。moyu-strict 更适合那种能明确说出“必须改什么”和“绝对不能改什么”的场景。

它和普通代码编辑 prompt 有什么区别？

普通 prompt 往往优化的是“完成任务”。moyu-strict 优化的是“克制”。它会要求 agent 挑战范围膨胀，避开装饰性改动，并把 diff 控制在足够快审的规模内。对维护工作来说，这比做功能扩展更合适。

如何改进 moyu-strict 技能

明确具体的编辑边界

最大的质量提升，来自一开始就把文件、函数和预期结果说清楚。不要说“把这个整理一下”，而要说：“只修改 src/auth.ts 以处理空 token，其他部分保持不动。” 这样能帮助 moyu-strict 把响应收紧到最小范围。

说明哪些内容是禁止的

因为 moyu-strict 本身就是围绕排除项来设计的，所以你应该直接写清楚不要加什么：不要新 helper，不要注释，不要测试，不要改依赖，不要只为了格式而改代码。之所以重要，是因为这个技能的价值在于拒绝不必要的新增，而不是替你发明一个更大范围的方案。

留意最常见的失败模式

最常见的失败，是请求一开始很小，后来却悄悄扩成了重构。遇到这种情况，最有效的改进不是“再提高代码质量”，而是缩小任务。先要一个最小可接受的 patch，再按需要迭代。这样能让 moyu-strict 技能始终对齐它严格的 diff 限制和最小改动理念。

从一个很小的首版补丁开始迭代

如果第一版输出太宽，先把 prompt 收紧到一个症状、一个文件、一个结果上。如果第一版输出太浅，再只补上最关键的那条约束，比如 “不要改签名” 或 “不要修改调用点”。对于 moyu-strict skill 用户来说，更好的结果通常来自更清晰的边界，而不是更长的说明。