moyu

moyu 技能總覽

moyu 技能的用途

moyu 技能是一種針對程式碼變更的編輯護欄：它會推動模型嚴格停留在使用者要求的範圍內，避免不必要的抽象，並優先採用最小且安全的 diff。如果你在找一個適用於 Code Editing、又能抵抗過度工程化的 skill，moyu 就是為這個目的而設計的。

適合誰使用

當你更重視精準度而不是完整度時，就該用 moyu 技能：例如修一個 bug、改一個檔案、縮小 diff，或回應「請只動 X」這類需求。它特別適合審查者、維護者，以及在成熟程式碼庫中工作的 agent，因為多餘的整理很可能反而帶來風險。

它為什麼特別

它最突出的差異化優勢，是對克制的強烈偏向。這個 skill 明確不鼓勵新增相依套件、大規模重寫、額外驗證、測試、註解或 helper 層，除非使用者有明確要求。這讓 moyu 非常適合真實世界中的編輯情境：真正的風險往往不是少改到功能，而是改得太多。

如何使用 moyu 技能

安裝並啟用 moyu

先把 moyu 技能安裝到你 agent 的 skills 目錄，接著確認你的程式編輯流程會在修改前載入它。典型安裝方式像是 npx skills add uucz/moyu --skill moyu。若想要最佳效果，請把它用在提示詞本來就要求克制的任務上，例如「只更新這個 function」或「保持變更最小」。

給 skill 一個範圍很窄的需求

moyu 技能在提示詞明確指出必須變更的精確檔案、function、行為或輸出時，效果最好。好的輸入像是：「在 src/auth.ts 裡，只修 token refresh 的 bug；不要重構，也不要新增檔案。」像「改善 auth」這種模糊要求，會留下太多擴寫空間，直接削弱 moyu 的用途。

先讀對的檔案

先看 SKILL.md，再檢查你真正打算修改的檔案，以及能說明在地慣例的附近內容。因為這個 repository 的設計本來就很精簡，沒有額外的 scripts 或支援目錄可以作為導引；核心價值就是 skill 文字本身。也就是說，最好的工作流程是：先讀 skill，定義最小可編輯範圍，然後直接執行。

依照 moyu 的期待方式工作

在使用 moyu 做 Code Editing 時，先要求最小修正，只有在結果仍未命中目標時才迭代增加。若真的需要更多變更，請用第二次請求補上，不要把第一輪需求越寫越大。這樣能保持 diff 夠小、讓 review 更容易，也更符合這個 skill「只改使用者要求的內容」的規則。

moyu 技能 FAQ

moyu 是完整功能的程式輔助工具嗎？

不是。moyu 技能重點不在於擴大涵蓋範圍，而在於限制範圍、避免不必要的修改。如果你需要的是廣泛重構、腳手架或架構層面的協助，一般的 coding prompt 可能比 moyu 技能更適合。

什麼情況下不該用 moyu？

當任務真的需要跨檔案協調、新抽象層，或系統性整理時，就不要用 moyu。如果工作內容是「把架構整理得更乾淨」或「補上缺少的 test suite」，這個 skill 的克制反而會變成限制，而不是優點。

moyu 適合初學者嗎？

適合，前提是初學者想要更安全的修改、也不想被意外變更嚇到。moyu 指南對於常常把需求開太大、或很容易接受過大 diff 的人特別有幫助。它教的是一個很實用的預設值：只要求能解決問題的最小變更。

這和只是叫模型小心一點有什麼不同？

一般提示詞可以要求謹慎，但 moyu 技能把這種偏好硬編成可重複使用的編輯政策。當你需要的是跨任務、反覆出現的 minimal-diff 行為，而不只是單次提示時，這個差異就很重要。

如何改進 moyu 技能

把需求縮小並說得更明確

要讓 moyu 的輸出更好，最有效的方法是在第一次編輯前先消除模糊性。請提供精確的檔案路徑、必須保留的精確行為，以及你要它做的精確變更。例如：「只編輯 components/Button.tsx；props 保持不變；只修 disabled 樣式。」

明確說出哪些不能改

當你告訴它哪些東西要保留不動時，這個 skill 的效果最強。像是「不要新增檔案」、「不要新增相依套件」、「不要改 API 形狀」或「不要整個 function 重寫」這類限制，都能幫助 moyu 更貼近使用者真正的意圖，而不是為了更廣義、但其實不需要的改善而優化。

先看第一版 diff，再繼續收斂

如果第一版結果還是太大，就把超出的部分回饋回去，再要求更窄的一輪修改。常見失誤模式包括額外清理、加入抽象層，或新增原本沒要求的防禦性程式碼。最好的 moyu 工作流程是逐步迭代：先收斂、再檢視，接著再修剪，直到 diff 和需求完全對齊。