moyu-ja

moyu-ja 技能總覽

moyu-ja 是一個用於程式碼編輯的日文技能，能在變更需求很窄時，幫助 AI 嚴格維持最小改動。它特別適合想要小而精準的 diff，而不是「自作主張」大改寫的開發者，尤其是你已經知道目標檔案、功能或行號範圍時。

moyu-ja skill 的真正工作重點是範圍控制：只改使用者要求的部分、選擇最簡單且可行的修法，並在需求含糊或可能牽連到無關檔案時先停下來。這讓它很適合維護工作、修 bug，以及以 review 為導向的編輯，因為這些情境最大的風險就是過度工程。

它的主要差異化在於克制。這個技能的設計，是要在沒有被要求時，盡量避免額外抽象、額外依賴、額外測試與額外文件說明。如果你希望模型保留既有設計，且改動越少越好，moyu-ja 會很合適。

moyu-ja 的程式碼編輯用途

當任務是「改這裡，不要動那裡」時，就用 moyu-ja。它適合那些最安全輸出就是最小輸出的程式碼編輯工作：一行修正、定點替換，或是在已知檔案中的受限 patch。

這個 skill 擅長什麼

• 將改動限制在使用者明確提出的範圍內
• 避免不必要的重構與包裝層
• 優先沿用既有程式路徑，而不是建立新結構
• 當需求說得不夠清楚時，先要求確認

什麼情況下不適合

如果你要的是架構整理、大範圍重構，或是順手回頭重看整體設計的解法，moyu-ja 會顯得過於保守。它不是為了「既然都在這裡了，就順便把整個模組改好」這種需求而設計的。

如何使用 moyu-ja skill

安裝並啟用 moyu-ja

先把 moyu-ja skill 安裝到你的 skills 環境，接著在你需要克制型編輯的任務中啟用它。這個 repo 裡常見的安裝指令是：

npx skills add uucz/moyu --skill moyu-ja

當你的提示詞包含明確界定的編輯需求時，就使用 moyu-ja，例如修正一個函式、調整一個條件，或套用很小的行為變更。

提供窄範圍的編輯說明

最好的 moyu-ja 用法，是從一個明確指出目標與限制的提示詞開始。好的輸入會說清楚要改什麼、在哪裡改，以及哪些地方不能動。

強提示詞範例：

• “In src/auth.ts, only change the token parsing logic. Do not touch unrelated validation.”
• “Update this component so it handles empty input, but keep the current structure and avoid new files.”
• “Make the smallest possible fix for the failing case in PaymentForm; do not add new abstractions.”

弱提示詞範例：

• “Improve this code.”
• “Make it cleaner.”
• “Refactor this module.”

以正確順序閱讀來源內容

使用這個 skill 時，先看 SKILL.md，再檢查 repo tree 中是否有鄰接的指引檔，且這些檔案有從 repository 連過來。若專案裡有 README.md、AGENTS.md、metadata.json，或像 rules/、resources/、references/、scripts/ 這類支援資料夾，就只在需要釐清範圍與限制時再讀。

重點不是把所有內容都讀完。moyu-ja 最有效的方式，是先找出安全編輯所需的最少上下文，然後就停。

能帶來更好結果的工作流程

1. 找出要修改的精確檔案與行為。
2. 用一句話說明你要的結果。
3. 當限制重要時，加上像「minimal diff」、「no new files」或「no new dependency」這類條件。
4. 先要求「最小可接受修正」。
5. 如果模型提出釐清問題，就直接回答，不要把任務擴大。

這個流程和 moyu-ja guide 的精神一致：輸入要精準、範圍要最小、不要猜。

moyu-ja skill 常見問答

moyu-ja 只適合日文工作流程嗎？

不是。雖然這個 skill 的內容是日文，但它強制的編輯行為是通用的：保持最小、保持在範圍內、避免不必要的改動。即使你的 repo 和提示詞都是英文，moyu-ja 仍然有用。

這跟一般提示詞有什麼不同？

一般提示詞也可以要求小心編輯，但 moyu-ja 是把這種紀律預設成行為基準。這一點很重要，因為模型有時會想「幫忙」做太多：重寫過頭、加抽象層，或碰到相鄰檔案。

moyu-ja 適合初學者嗎？

適合，前提是你的目標是學會怎麼做更小、更安全的改動。它對容易過度修正程式碼、或額外加上其實不需要層次的初學者尤其有幫助。

什麼時候不該用 moyu-ja？

當真正的任務是重新設計、跨多個檔案整理，或更廣泛的改善時，就不要用 moyu-ja。若你希望模型重新評估架構，功能更廣的 coding skill 會更合適。

如何改進 moyu-ja skill

給更明確的範圍訊號

最重要的改進，是把編輯邊界講清楚。指定檔案、函式、行區間，或精確行為。邊界越明確，skill 越不容易過度延伸。

說明真正重要的限制

如果你在意保留原本的實作風格，就直接說。如果你不想要新 class、新 helper、新依賴、註解、測試或文件，也要直接說。moyu-ja 最強的時候，就是提示詞把「少做一點」這條規則講得很具體。

先要求最小可接受修正

一個實用的 moyu-ja 改進迴圈，是先要求最小可行 patch，然後只有在那個 patch 沒滿足需求時才擴大範圍。舉例來說，可以先從「用最小 diff 修掉這個 bug」開始，再只在第一次答案漏掉真正需求時迭代。

注意過度工程的失敗模式

這個 skill 最想防止的失敗模式，就是 scope creep：改到無關檔案、為一次性修補新增抽象，或針對使用者根本沒要求的情況加入防禦式程式碼。如果真的發生了，就把提示詞再收緊到精確的編輯範圍，並重申禁止額外工作。