moyu-lite

moyu-lite 技能概覽

moyu-lite 的用途

moyu-lite 是一個給程式碼編輯用的輕量級 guardrail 技能。它會幫助 agent 守住使用者的明確需求，避免額外重構、新抽象、大範圍改寫，以及那些「看起來很幫忙」但其實會改動過頭的副作用調整。如果你要的是一個偏向最小 diff、而不是追求巧妙設計的 moyu-lite Code Editing 技能，這個就很適合。

適合誰使用

當主要風險是「改過頭」時，就該用 moyu-lite：例如修了一個問題，卻不小心改到不相關的檔案、架構或行為。它特別適合維護工作、小型 bug 修正、局部檔案編輯，以及使用者明確說出「只改 X」、「保持簡單」或「不要重構」的需求。

它優化的是什麼

這個技能的核心有三條規則：只改被要求的部分、先選最簡單的解法、拿不準就先詢問。這讓 moyu-lite 在「正確性來自克制，而不是發明」的情境中特別有價值。它著重的不是產出一大包程式碼解法，而是控制作用範圍；而這往往才是程式碼編輯流程裡真正的卡點。

如何使用 moyu-lite 技能

安裝並啟用 moyu-lite

在執行 moyu-lite install 時，把這個技能從你的環境中的 repo 路徑加入，然後在開始編輯前先確認 agent 有讀到技能檔。來源中示範的一個典型安裝指令是：
npx skills add uucz/moyu --skill moyu-lite

先給它一個很明確的編輯需求

最好的 moyu-lite usage，一開始就會說清楚目標、預期結果與邊界。好的輸入像是：「更新 src/auth.ts，讓登入可以接受 email alias；不要改其他 auth 邏輯或檔案結構。」相對地，像「改善 auth」這種模糊指令，會讓範圍失控，也逼 skill 去猜。

先讀對的檔案

先看 SKILL.md，再查看任何連結的 repo 指引，例如 README.md、AGENTS.md、metadata.json，或是如果存在的話，像 rules/、references/、resources/、scripts/ 這些資料夾。在這個 repo 裡，訊號設計得刻意精簡，所以仔細讀 skill 文字，比起到處找額外輔助檔更重要。

把它當成編輯政策，不是改寫提示

moyu-lite 最適合在模型開始寫程式前就先套用：請它保留現有結構、限制 diff 範圍，並在需求擴大時先停下來確認。這讓它很適合用在既有程式碼的修補；在那種情境下，對的答案通常是「最小且安全的改動」，而不是「更好的架構」。

moyu-lite 技能 FAQ

moyu-lite 只適合很小的改動嗎？

不是。只要是使用者重視狹窄、可控變更的 Code Editing 任務，都適合用。即使是大型功能，只要指令是要維持最小 diff、避免未授權的重構，moyu-lite 也一樣能派上用場。

這和一般 prompt 有什麼不同？

一般 prompt 可能只描述任務，但仍會留給模型空間去「優化」程式碼。moyu-lite 則多加了一層明確的克制規則：如果需求沒有授權去改某件事，skill 就會把那件事視為超出範圍。當你希望 agent 像一位謹慎的編輯，而不是重設計助手時，這會更可靠。

什麼情況下不該用 moyu-lite？

當你其實想要探索、重新設計，或大範圍整理時，就不要用它。如果目標是重構架構、統一模式，或把這次任務當成改善周邊程式碼的機會，moyu-lite 可能會太保守。

moyu-lite 對新手友善嗎？

友善。因為規則很容易套用：少改一點、更早發問、優先選擇最小但正確的修改。新手最需要記住的是，這個技能要防的，通常就是那些「看起來很幫忙」的額外工作。

如何改進 moyu-lite 技能

把編輯邊界講清楚

最強的 moyu-lite guide 輸入，會直接指出精確的檔案、區段與可接受範圍。請把必須保持不動的內容也寫出來，例如「不要改 tests」、「不要新增依賴」或「保留目前 API」。這樣可以降低歧義，也能幫助 skill 用克制原則來執行，而不是自己猜意圖。

說出最小可接受結果

使用者通常在意的是輸出安全，而不是美不美觀。請直接定義最低成功條件：像是「修掉失敗的 branch」、「把硬編碼路徑換掉」或「調整這個函式，但不要改呼叫端」。如果你希望 moyu-lite for Code Editing 發揮效果，就要給它一個可以用單一、受限 diff 達成的目標。

留意常見失誤模式

當 prompt 很模糊、程式碼庫很亂，或任務聽起來像是在邀請模型去順手改善附近程式碼時，這個 skill 最容易跑偏。如果第一次結果加了抽象層、碰了不相關檔案，或改寫的內容超出需要，就要收緊指令，重新說清楚邊界，再要求第二輪。

透過縮小範圍迭代，不要擴大範圍

如果第一次結果太廣，就不要加碼更多要求；改成縮小需求：指定要保留不變的精確行、檔案或行為，然後只要求補上缺少的那一小段修改。對 moyu-lite 來說，更好的結果通常來自更強的約束，而不是更多背景。