假設你把一份季度報告貼給助手，說：「第三段那個金額的單位寫錯了，幫我改一下。」它交回整份。單位改好了，另外第二段的語氣變順了，第四段的兩句合成了一句，表格標題也換了說法。每一處讀起來都比原本好，直到你發現第四段合併的時候，「預估」兩個字不見了，原本是預估的數字，現在讀起來像已經確定。
你本來只要確認一個單位。現在得把整份逐段對回原稿，才知道它還動了哪裡。
多改的那幾處，沒有人會去看
改稿交辦最麻煩的是檢查的範圍跟著變大。你心裡預期它只動一處，所以只看那一處；它多動的地方，你不會想到要去看。你沒交辦、也就沒打算檢查的那幾處改動，最容易把對的內容改壞。
這個傾向在官方文件裡也看得到。Anthropic 的提示寫法指南有一節叫「Overeagerness」，說 Claude Opus 4.5 和 Opus 4.6 有過度設計的傾向，會多建檔案、加上不必要的抽象層、做出沒人要求的彈性。它附的建議提示詞裡有一句：只做直接被要求、或明顯必要的改動。下面還有一句很具體：修一個錯誤，不需要把周圍的程式碼也整理一遍。
Sonnet 5.5 那一頁講得更細。它說這個模型即使沒被要求，也傾向加上測試、說明文件和小型的輔助檔案，每一種努力程度都會，設得越高加得越多；被要求的那個改動本身，則仍貼近原本的要求。文件也說，多數團隊會歡迎這些附加的東西。如果你只要明確要求的改動，它建議在系統提示裡寫：要求的事做完並檢查過就停下來回報，沒被要求的功能、測試、檔案、文件或重構都不要加；覺得哪一項有幫助，寫在最後提出來，不要直接做。
這兩頁講的都是寫程式。我的判斷是，改報告、改簡報會遇到同一種情況，因為對它來說，把旁邊的句子順一順和把旁邊的程式碼整理一下是同一類「改善」。另外，開源的除錯技能集 superpowers 在修錯的階段也寫了三條：一次只改一處、不做「既然在這裡就順便」的改善、不夾帶重構。
改稿的範圍要說到哪
官方文件還提到一個跟用詞有關的地方：你說「可以建議一些修改嗎」，它有時候只會給建議而不動手；說「把這個改掉」，比較容易直接動手。這段原本在講工具的使用，我的推論是改稿也適用：你要它改，就說清楚改哪裡、改到什麼程度；你只想看看還有什麼可以改，就說「列出來給我，不要改」。
下面這張表是改稿時要交代的範圍，從最小的改法排到最大的：
| 你要的改法 | 允許它動的 | 一定不准動的 | 交回時要附 |
|---|---|---|---|
| 改錯字、改一個數字或單位 | 你指出的那幾個字 | 其他所有字、標點、格式 | 改了哪幾個字，原文與改後 |
| 改一段的語氣或說法 | 指定那一段的句子 | 那段的事實、數字、限定詞；其他段落 | 那一段的改前改後 |
| 調整一節的結構 | 指定那一節的段落順序與小標 | 內容與結論；其他節 | 每一處搬動的位置 |
| 整份潤稿 | 句子的寫法 | 數字、人名、專有名詞、引文、結論、限定詞 | 完整的改動清單 |
作者整理，非官方。每一列的「一定不准動」都有限定詞，指的是「預估」「約」「可能」「截至某日」這一類字。我的判斷是，它們很短，潤稿的時候容易被當成贅字拿掉，拿掉之後整句的意思就變了。「預估」「約」「可能」這類限定詞，每一種改法都要列進不准動的範圍。
範圍外想改的，先寫成建議
範圍寫清楚了，交回來的東西還是要核對。官方那兩頁給了兩個可以直接借用的界線：只做被要求的、或明顯必要的改動；覺得還有別的地方值得改，寫在最後提出來，不要直接做。superpowers 那句「不做既然在這裡就順便的改善」，講的也是同一條線。
我把它套到改稿上，請它交回時附一張改動清單，每一處改動一行：位置、原文、改後，以及這一處落在哪一堆。
交回的每一處改動
│
▼
在你指定的位置和改法之內？
│是 ──→ 保留，照常檢查這一處
│否
▼
是算錯、錯字這類明顯的錯？
│是 ──→ 先還原，列進「建議修改」
│ 由你決定要不要改
│否
▼
語氣、合併句子、換說法 ──→ 還原
官方的提示詞允許它做「明顯必要」的改動。改報告的時候，我的判斷是這一類也交回給你決定，因為它覺得明顯的錯，可能是你刻意的寫法，例如引用原文時保留的錯字。範圍外的改動，就算看起來是對的，也先還原，它找到的問題寫在最後的建議清單裡，你看過再決定。
清單是它自己填的，可能漏列。重要的稿子，可以再用文書軟體的「比較文件」功能，把原稿和改後稿放在一起比，凡是清單上沒有、比較結果卻標出來的地方，就是它多改又沒說的。
動手做
下次交辦改稿，在你的要求後面接上這一段：
【改稿範圍】 這次只改：（位置，例如「第三段第二句的金額單位」） 改到什麼程度：（只改錯字／只調這一段的語氣／整份潤稿） 不准動：上面指定範圍以外的所有文字、標點、格式；範圍內的數字、人名、專有名詞、引文、結論，以及「預估」「約」「可能」「截至」這類限定詞。 看到範圍外的問題：就算你認為非改不可，也不要改，寫在最後的「建議修改」清單，每項附位置與理由。 交回時：先列一張改動清單，每一處改動一行，欄位是「位置／原文／改後」。清單之外不應該有任何改動。 要改的內容：（貼上）
只想貼一句的時候，用這句：「只改我指定的地方，其他地方就算你覺得可以更好也不要動，寫在最後的建議清單；交回時列出你改過的每一處，附原文和改後。」
這週交出去的第一份改稿，在要求最後補上「範圍外的寫成建議，交回時列出你改過的每一處」，收到後先看清單有幾行，再看有沒有哪一行落在你指定的範圍外。
站內延伸
- 交辦的五格怎麼填 → 交辦前先填五格
- 會動手做事的 AI 要管的動作邊界 → 交辦時沒寫「不准做什麼」，它就自己決定
- 兩個版本逐處比對 → 找方法AI 文件比對
來源： Anthropic：Prompting best practices（Overeagerness 一節：Opus 4.5 與 Opus 4.6 過度設計的傾向、建議提示詞「Avoid over-engineering. Only make changes that are directly requested or clearly necessary」「A bug fix doesn't need surrounding code cleaned up」；Tool usage 一節：「can you suggest some changes」有時只給建議，「Change this function」較能直接改）；Anthropic：Prompting Claude Sonnet 5.5（Steer initiative and scope 一節：未要求也傾向加測試、文件與輔助檔案，努力程度越高越多；每種努力程度都會、多數團隊會歡迎；被要求的改動本身貼近要求；「If you think one would help, mention it at the end instead of doing it」）；obra/superpowers：systematic-debugging（MIT；ONE change at a time、No "while I'm here" improvements、No bundled refactoring）。改稿範圍表與改動清單的分流為作者整理；官方文件談的是程式，套用到改稿是我的推論。2026-10-25 查證。