moyu-fr

moyu-fr 技能總覽

moyu-fr 是一個給容易過度擴寫的 agent 使用的程式碼編輯護欄技能。它特別適合想要「最小且正確變更」的使用者，尤其是在需求其實只需要改動指定幾行，而不是重寫檔案、增加抽象層，或超出範圍去「順手優化」程式碼的情況。

moyu-fr 適合做什麼

moyu-fr 技能最適合 patch 風格的工作：外科手術式修補、窄範圍重構、一次性 bug 修正，以及使用者明確要求「簡單」「最少變更」或「只改 X」的回覆。它能幫助 agent 回到真正的工作目標：完成指定變更，然後停手。

這個技能有什麼不一樣

和一般提示詞不同，moyu-fr 內建了明確的反過度工程規則。它會抑制新增層級、額外依賴、為不可能情況寫過度防禦的程式，以及無關的文件或測試。當輸出品質的衡量標準是克制而不是廣度時，這個技能就很有用。

最適合與不適合的使用情境

當 repo 或任務對 diff 大小、架構漂移或不必要的清理很敏感時，請用 moyu-fr 來做 Code Editing。若你其實想要的是重新設計、功能擴充、建立測試，或大規模現代化整個程式碼庫，那它就不是最理想的選擇，因為這個技能的目標就是盡量減少變更。

如何使用 moyu-fr 技能

安裝並確認啟用路徑

先依照 repo 的 moyu-fr 技能安裝流程完成安裝，接著確認 agent 能從你的編輯需求中偵測到這個技能。當你的工作流程本來就有嚴格的範圍控制，而且你希望技能能在出現過度工程跡象時自動介入時，moyu-fr install 的決策最有價值。

給它一個狹窄、明確的編輯需求

最好的 moyu-fr usage 模式，是一個有邊界的精準請求。好的輸入會清楚指出目標檔案、確切的行為變更，以及哪些部分不能動。

強而有力的需求範例如下：

• “Edit src/auth.ts to fix the null check in validateSession; do not change error handling or add helpers.”
• “Update only the regex in README.md example; keep the rest of the snippet unchanged.”

模糊的輸入則會很寬泛：

• “Improve the auth flow”
• “Clean up this module”
• “Make it more robust”

這類提示會引發範圍擴張，而這正是這個技能要避免的事。

先讀對的檔案

如果你想把 moyu-fr 用得務實，先從 SKILL.md 開始，再查看 repo 提到的任何連結筆記或任務專用檔案。就這個技能目前的形式來看，最重要的訊號其實就是技能本身，因此最有價值的閱讀路徑是：指令內容、repo tree，以及你打算立即修改的檔案。如果你說不出明確目標和最小可接受 diff，代表提示還是太模糊。

把它當作克制過濾器，不是重寫引擎

這個技能在你已經知道預期結果、但想阻止多餘變更時表現最好。它應該把 agent 的修改方向限制在：

• 最少的行數變動
• 除非要求，否則不新增抽象層
• 除非要求，否則不加額外文件、測試或註解
• 當 patch 就足夠時，不要重寫整個檔案

moyu-fr 技能 FAQ

moyu-fr 只適合 Code Editing 嗎？

是的，moyu-fr 最強的適用情境就是有嚴格範圍控制的 code editing。它對開放式生成、架構規劃，或本來就預期要加上額外支架的任務，幫助比較有限。

它和一般提示詞有什麼不同？

一般提示詞可以說「保持簡單」，但 moyu-fr 會把這個偏好變成更強的操作規則。當 agent 想順手解決相鄰問題、重寫周邊程式碼，或加上根本沒人要求的美化時，這點就很重要。

moyu-fr 適合新手嗎？

可以，只要使用者能描述單一、具體的變更就行。它最好上手的情況，是你能說出檔名、症狀，以及編輯範圍的精確邊界。新手比較常卡住的原因通常是需求太大，而不是這個技能本身太難。

什麼時候不該用 moyu-fr？

當你真的需要重構、測試覆蓋、新抽象層，或系統硬化工作時，不要用它。這些情況下，技能的克制可能會和真正目標衝突，最後產出的結果雖然技術上很精簡，卻不完整。

如何改進 moyu-fr 技能

一開始就給更精確的限制

要讓 moyu-fr 更好，最有效的方法就是先說清楚哪些內容必須維持不變。請包含檔名、目標行，以及像「不要新增函式」「不要額外註解」「不要變動這個區塊以外的格式」這類排除條件。這些限制可以降低猜測空間，也讓這個技能的最小變更行為更穩定。

直接要求最小可接受 diff

如果你想讓 moyu-fr usage 的結果更好，請用 diff 的角度描述成功標準：

• “Change only one branch condition.”
• “Patch the existing function instead of creating a helper.”
• “Preserve the current public API.”

這會讓 agent 清楚知道什麼叫「完成」，也能防止範圍擴張。

注意常見失敗模式

最主要的失敗模式是意外擴充：多做驗證、多加說明，或做出看似有幫助、但其實改動比原需求更多的清理。另一個常見問題是編輯不足，當需求其實需要多個小變更時卻只改了一部分；這時就應該明確列出全部必要修改，避免技能太早停手。

用更窄的後續指令迭代

如果第一次的結果還是太廣，就應該縮緊下一個指令，而不是把同樣的要求再說一次。像是「Keep the same logic and only adjust this condition」就比「make it smaller」更有行動性。對 moyu-fr 來說，更好的輸入通常代表更少的自由度，而不是更多背景。