moyu-strict

moyu-strict 技能概覽

什麼是 moyu-strict

moyu-strict 是一個用於程式碼編輯的防護技能，專門強化嚴格的反過度設計行為。它適合你想要「最小且安全的變更」，而不是一個打磨得很漂亮的重構時使用。它的核心工作，是在滿足需求的同時，避免代理去碰不相關的檔案、加抽象層，或對無關程式碼做「順手優化」。

誰適合使用

moyu-strict 最適合審查者、維護者，以及在既有程式碼庫中處理範圍很小修正的代理。如果你在意最小差異、可預期的審查流程，以及避免誤觸副作用，moyu-strict for Code Editing 會很合適。它比較不適合探索性重構、架構工作，或大範圍清理任務。

它的不同之處

它真正的差異在於「執行力」。moyu-strict 不是一個泛用的「把程式寫得更好」提示詞；它重點放在範圍控制、編輯紀律與克制。最強的訊號來自明確規則集：編輯前先確認範圍、避免新增抽象層、不要加入未要求的文件／測試／相依套件，若變更開始膨脹到超出需求，就立刻停下來。

如何使用 moyu-strict 技能

安裝並啟用它

先依照儲存庫的技能安裝流程執行 moyu-strict install，然後在你預期會有程式碼變更、而且範圍必須很窄時載入它。如果你的環境是用指令式安裝器，重點是要在模型開始編輯之前先掛上 moyu-strict，讓限制條件從第一版草稿就開始生效，而不是只在審查階段才介入。就 moyu-strict usage 而言，只要任務是定點修正，而不是設計討論，就應該啟用它。

先讀對的檔案

先看 skills/moyu-strict/SKILL.md，因為那裡就是嚴格規則與啟用行為的來源。這個儲存庫只有單一技能檔，沒有輔助腳本、參考檔或規則資料夾，所以不需要去追一棵隱藏的工作流程樹。使用者真正需要的是規則文字本身，而不是一趟擴充式的儲存庫導覽。

把模糊任務改寫成嚴格提示

這個技能最好用在需求已經明確指出目標與邊界時。好的輸入會像這樣："Fix the null crash in src/parser.ts and only edit that file; do not add tests, comments, or refactoring."。差的輸入會像："Improve this module."。前者讓 moyu-strict 有東西可以約束；後者則很容易導致範圍漂移。

用在「先確認再編輯」的流程裡

一個好的 moyu-strict guide 是：先辨識受影響的檔案或函式，說清楚預計修改什麼，確認不需要動到其他檔案，然後再開始編輯。如果任務看起來需要更大範圍的變更，就先停下來，詢問是否可以接受更小的版本。這正好符合這個技能最嚴格的價值：在過度延伸變成 diff 之前，先把它顯性化。

moyu-strict 技能 FAQ

moyu-strict 只是一般提示詞嗎？

不是。一般提示詞可能只要求程式簡潔，但 moyu-strict 明確是用來強制編輯邊界的。當主要風險不是邏輯錯誤，而是不必要的額外修改時，它最有價值。

什麼情況不該用它？

當任務真的需要協同重寫、新抽象層、文件更新，或建立測試框架時，不要用 moyu-strict。如果結果本來就應該包含較大範圍的清理，這個技能偏向「最小 PR」的傾向，反而可能和真正目標衝突。

它對新手友善嗎？

友善，因為規則簡單又具體。新手最常犯的錯，是丟出一個模糊需求，卻期待技能自己猜出邊界。moyu-strict 在使用者能清楚說出「要改什麼」以及更重要的「不要改什麼」時，效果最好。

它和一般程式碼編輯提示詞有什麼不同？

一般提示詞通常偏向完成任務。moyu-strict 則偏向克制。它會要求代理對範圍外擴保持警覺、避免裝飾性修改，並把 diff 控制在能快速審查的大小。這讓它更適合維護工作，而不是功能擴充。

如何改善 moyu-strict 技能

明確指定精確的編輯邊界

提升品質最大的方式，就是一開始就把檔案、函式與預期結果講清楚。不要只說「整理一下」，而要說「只修改 src/auth.ts 來處理空 token，其餘部分都不要動」。這能幫助 moyu-strict 把回應收斂到最窄的範圍。

說明哪些事情是禁止的

因為 moyu-strict 本身就是建立在排除項上，所以你應該直接說不要加什麼：不要新增 helper、不要加註解、不要加測試、不要改相依套件、不要只做格式調整。這很重要，因為這個技能的價值在於拒絕不必要的加料，而不是替你發明一個更大的解法。

留意最常見的失敗模式

最常見的失敗，是一個原本很小的需求，悄悄膨脹成重構。這種情況下，最好的改善不是「寫得更漂亮」，而是把任務縮小。先要求最小可接受的修補，再視需要迭代。這能讓 moyu-strict 技能維持在它的嚴格 diff 限制與最小變更哲學之內。

先從極小的第一版修補開始迭代

如果第一次輸出範圍太大，就把提示詞收緊到一個症狀、一個檔案、一個結果。如果第一次輸出太淺，就只補上最關鍵、缺少的限制，例如「不要改函式簽章」或「不要動呼叫端」。對 moyu-strict skill 使用者來說，結果通常來自更精準的邊界，而不是更長的指令。