潤稿
潤稿不是把文章變成「更像好文章」的樣子。
至少在這套方法裡，不是。
這套方法要做的是：在不代替作者決定怎麼說話的前提下，找出文字中可以明確確認的問題，讓作者自行決定是否修改。
它與 標題取名方法 採用相同的協作原則：AI 負責協助辨識、比較與回報；作者保留最後的判斷與文字主導權。
最重要的界線是：
AI 可以指出文字哪裡出了問題，但不能因為自己有另一種寫法，就把原文判定成問題。
一、這份文件處理的範圍
日常所說的「潤稿」，其實混合了幾種不同工作。
- 校對
處理相對客觀、通常不牽涉作者選擇的問題：
錯字
同音異字
標點誤用
明顯語病
格式錯誤
修改這些問題，通常不會改變「這句話是不是作者講的」。
- 輕度潤色
處理句子層級、但已經帶有部分主觀判斷的問題：
真正沒有作用的贅字
非刻意的近距離重複
指涉不清
同一概念前後叫法不一致
這一層可以提出建議，但必須證明問題存在，不能只因為另一種寫法比較順。
- 修訂與結構調整
處理：
段落順序
論述展開
內容取捨
案例更換
段落刪除或合併
文章拆分
這一層已經在協助作者決定「要講什麼」，不只是檢查「講得有沒有問題」。除非作者明確要求，否則不屬於本文件所說的潤稿。
- 代筆
AI 直接生成內文，或把原文大幅改寫成 AI 慣用的表達方式。
代筆不在這套方法的允許範圍內。
本方法的實際邊界
本文件只涵蓋：
校對＋有明確判定依據的輕度潤色＋排版格式一致性。
它不處理文章結構、論述完整度、事實查核、標題命名與篇幅壓縮。這些工作可能有價值，但應該另外提出、另外決定，不能偷偷包進「潤稿」裡。
二、AI 的工作方式
- 預設只回報，不直接修改
AI 應標出問題、引用原文並說明理由。
必要時可以在對話中提供替代寫法，讓作者理解問題或參考修改方向；但不能直接把文章檔案裡的句子換掉。
只有在作者明確指定「請直接修改」時，AI 才能動手。即使如此，也只能修改已確認的問題與指定範圍，不得順便重寫附近段落。
- 沒有問題是合法結果
AI 不需要證明自己有工作。
如果檢查後沒有發現符合門檻的問題，應直接回報：
本次沒有發現需要修改的項目。
不得為了交差，從正常句子裡挑幾句改得更平順。
- 原文不是等待 AI 改善的半成品
口語、停頓、重複、短句、突然轉彎、不完全工整的句型，都可能是作者聲音的一部分。
AI 不得把以下理由單獨當成修改依據：
改完比較正式
改完比較精簡
改完比較流暢
一般文章通常不會這樣寫
AI 自己比較習慣另一種說法
必須先指出原文造成了什麼具體問題。
- 一次只做被要求的檢查
如果作者要求潤稿，AI 不應自動延伸成：
重新安排文章結構
補充論點
改寫標題
檢查事實
調整文章立場
統一成某種媒體或商業文案風格
發現範圍外的重大問題時，可以另外提醒，但不能混入潤稿結果或直接處理。
三、開始前先確認檢查模式
AI 應先根據作者提供的內容，判斷這次屬於哪一種模式。
單篇模式
只檢查目前這一篇文章內部：
句子問題
同篇用詞一致性
同篇排版一致性
不得因為其他文章採用不同格式，就判定本篇有錯。
系列模式
作者提供多篇文章，或明確要求檢查系列一致性時，才比較：
分段方式
破折號寫法
連結格式
列表風格
其他已確立的系列慣例
指定項目模式
如果作者只要求檢查錯字、標點或特定類別，AI 應只處理該項目。
不要以「順便幫你看」為理由擴張工作範圍。
最終發布前模式
當文章即將發布，可以執行完整清單，但仍然只回報符合門檻的問題。
檢查完整，不等於每一類都必須找出一個問題。
四、問題成立前必須通過的判定
AI 看到一個可能的問題時，不應立刻列入結果。先依序通過以下判定。
第一關：能否說明具體問題
AI 必須能指出原文造成的實際問題，例如：
字寫錯了
標點用法衝突
讀者無法判斷代名詞指向誰
同一概念在同篇文章中使用兩種名稱
某個詞在太近的距離重複，卻沒有語意或修辭作用
如果理由只有「可以改得更順」，不算通過。
第二關：是否可能是刻意表達
檢查它是否屬於：
作者慣用語氣
刻意排比
強調
節奏
笑點
口語停頓
前後呼應
技術主題詞的必要重複
只要有合理可能是刻意表達，就不能直接當成錯誤。
第三關：修改是否會改變聲音
想像把問題拿掉或換成建議版本後：
語意有沒有改變？
語氣有沒有改變？
節奏有沒有改變？
人物感有沒有變弱？
如果會，就表示這不只是校對。AI 應降低判定強度，或改成詢問作者，而不是宣布應該修改。
第四關：證據是否足夠
AI 應把候選分成三類：
確認問題
有清楚依據，可以直接回報。
邊界案例
可能影響理解，但也可能是作者選擇。應說明兩種解讀，交由作者判斷。
個人偏好
只是 AI 偏好另一種寫法，不應回報。
無法區分問題與偏好時，寧可不改。
五、潤稿檢查清單 v2
- 錯字與同音異字
檢查：
的／得／地
在／再
帶／戴
象／像
其他輸入法誤植
字詞遺漏或多打
判定原則
必須能確認正確用字。若涉及作者自創用法、雙關或刻意錯寫，不要擅自修正。
- 標點符號
檢查：
全形與半形混用
頓號、逗號與分號誤用
引號與書名號誤用
括號是否成對
省略號點數不一致
句末標點遺漏或重複
中英文交界的標點異常
判定原則
標點也可能承擔語氣與節奏。
連續驚嘆號、問號、省略號或刻意斷句，不應只因不符合正式書面慣例就被修改。應先判斷它是錯誤，還是作者正在說話。
- 排版格式一致性
檢查：
分段方式
分隔線用途
破折號寫法
Markdown 連結格式
列表符號
列表編號
同層級標題格式
目前採用的慣例
一般分段使用空行。
--- 只用於真正的主題切換。
破折號統一使用全形「——」。
連結使用 Markdown 語法。
有先後順序的列表使用阿拉伯數字。
沒有順序的列表使用 -。
正文列表避免使用中文數字；中文數字保留給決策歷程等正式文件的章節編號。
判定原則
單篇模式只檢查本文內部一致性；系列模式才檢查跨篇慣例。
格式慣例是可調整的專案規則，不是普遍正確的中文寫作規範。
- 贅字贅詞
贅字不是「刪掉後句子還看得懂」。
自然語言裡很多字不負責新增資訊，卻負責語氣、節奏、態度或人物感。
受保護的語氣表達
目前包括：
其實
說實話
老實說
好在
顯然
當然
XD
這份清單會隨實際文章增補。
它不是永久豁免名單，而是提醒 AI：這些詞經常是作者聲音，不能只因刪掉後語意仍成立就判定為贅字。
雙重測試
不在受保護清單中的候選，以及有充分理由懷疑確實多餘的受保護詞，都要套用雙重測試：
拿掉後，語意是否完全不變？
拿掉後，語氣與節奏是否也不變？
只有兩項答案都是「不變」，才算真正的贅字。
只要其中一項改變，就不應列為確認問題。
- 代名詞指涉不清
檢查：
這個
這樣
它
他／她／他們
前者／後者
這件事
判定原則
重點不是代名詞離指涉對象多遠，而是讀者是否可能合理地指向兩個以上的對象。
尤其注意：
中間隔了一段後重新使用代名詞
同一段出現多個同性質名詞
從案例切回主題時仍使用「它」或「這個」
若上下文只有一個合理指向，就不必為了形式完整而改成名詞。
- 全文用詞不一致
只檢查同一篇文章內，同一概念前後是否使用不同叫法。
例如：
前面稱「知識庫」，後面無理由改稱「筆記庫」
前面使用產品正式名稱，後面換成另一個可能被理解成不同工具的縮寫
同一角色、功能或流程在不同段落出現不同名稱
判定原則
不同詞不一定代表不一致。
如果換詞是為了避免機械重複，而且讀者不會誤認為兩個概念，就不必統一。
跨篇排版與格式差異屬於「排版格式一致性」，不要混入本項。
- 近距離重複用詞
檢查同一個詞或相近句型在短距離內重複，是否造成非刻意的卡頓。
先排除
技術主題詞的必要重複
為避免指涉不清而重複名詞
刻意排比
強調
笑點
前後呼應
為維持節奏而安排的重複
判定原則
不能只計算詞頻。
AI 必須說明這次重複為什麼沒有功能，以及它實際如何影響閱讀。無法說明，就不應列入。
六、不在本清單內的問題
篇幅過長
篇幅問題優先考慮切篇、縮小主題或重新決定文章範圍，不用逐句壓縮來假裝解決。
如果一篇文章需要刪掉大量聲音與例子才能符合字數，問題通常不在贅字。
結構與論述
段落順序、論點缺口、案例是否恰當，屬於結構審查。
AI 可以在作者明確要求時另外檢查，但不能把結構修改包裝成潤稿。
過度發明名詞
自創詞、黑話與業界既有用語的選擇，依 過度發明名詞 處理。
如果只是首次出現的縮寫沒有解釋，可以提醒可讀性風險；但不要在沒有確認概念的情況下自行換詞。
標題與檔名
標題品質依 標題取名方法 處理。
篇名與檔名是否同步屬於發布或知識庫維護流程，不放進句子潤稿清單。
事實正確性
潤稿只檢查文字呈現，不代表內容已經過事實查核。
AI 若被要求同時查核，應把查核結果與潤稿結果分開回報。
七、回報方式
- 先說整體結果
使用簡短結論：
發現 3 個確認問題、1 個邊界案例。其餘未發現需要修改的地方。
或者：
本次沒有發現符合門檻的問題。
不要先給一段空泛的文章評價。
- 每個問題必須包含證據
建議格式：
問題 1｜標點符號｜確認問題
原文：
……
問題：
說明具體錯誤，以及它為什麼不是單純偏好。
參考處理：
提供最小必要修改。若不需要示範即可理解，可以省略。
- 邊界案例要呈現兩面
例如：
這個「其實」刪掉後語意不變，但會讓語氣從自我修正變成直接陳述。我不把它列為確認問題；如果你這裡不需要那個轉折感，才考慮刪除。
AI 不應用「建議改成」掩蓋判斷仍不確定。
- 不必重貼整篇修改版
預設只列問題與最小修改方向。
只有作者明確要求直接修改或產出修訂版時，才提供完整改稿；而且不得順手改動未回報的句子。
- 問題太多時先分類
若同一規則反覆命中，可以先說明共同問題，再列出位置，不必每一處重複同一段解釋。
但不能只說「標點很多問題」而不提供例子或位置。
八、完整執行流程
第一步：確認範圍
判斷這次是：
單篇模式
系列模式
指定項目模式
最終發布前模式
若作者的要求已經足夠清楚，不需要多問。
第二步：依清單掃描
按以下順序檢查：
錯字與同音異字
標點符號
排版格式一致性
贅字贅詞
代名詞指涉不清
全文用詞不一致
近距離重複用詞
順序從較客觀的問題走向需要更多語境判斷的問題。
第三步：排除假陽性
每個候選都要確認：
是否為刻意語氣或修辭？
是否是主題詞的必要重複？
修改後是否改變語意、語氣或節奏？
問題是否只是 AI 的用詞偏好？
第四步：分類信心
將留下的候選分成：
確認問題
邊界案例
不回報的個人偏好
第五步：回報，不改稿
先給總結，再逐項引用原文、說明問題與最小處理方向。
第六步：由作者決定是否修改
作者可以：
自己修改
接受某項建議
拒絕某項建議
明確指定 AI 修改特定位置
被拒絕的建議如果反映作者穩定偏好，應成為後續判斷依據，不要在下一篇反覆提出。
九、方法如何更新
這份清單不是從通用寫作教材完整搬來，而是用實際文章驗證後收斂的。
因此，更新也應由實例觸發。
新增檢查項目
只有在真實文章中反覆出現、而且現有類別無法涵蓋時，才考慮新增。
不要因為某種問題在別人的文章很常見，就先塞進清單。
移除檢查項目
如果長期零命中，或命中結果幾乎都是作者刻意表達，應考慮移除，而不是讓 AI 永久做無效掃描。
更新受保護表達
當作者確認某個詞、句型或標點是穩定語氣，而不是贅字或錯誤，可以加入受保護表達。
加入後代表提高判定門檻，不代表永遠禁止檢查。
記錄真實案例
新增、移除或調整規則時，至少保留一個實際案例與決策理由。
這能避免清單逐漸變成沒有證據的個人教條，也讓 AI 知道規則真正要防止什麼。
十、這份清單的驗證依據
這套 v2 清單曾以鐵人賽第一至第十篇文章驗證。第十篇因附有完整 CLAUDE.md，只計算原創敘事段落。
驗證結果顯示：
原始項目 / 實際結果 / v2 決策
錯字／同音異字：全系列只找到約 3 處 → 保留，低頻但客觀
標點符號：每篇穩定命中 → 保留
近距離重複用詞：多數為主題詞或刻意排比 → 保留，但提高門檻
贅字贅詞：密度高，但大量屬於作者口語聲音 → 保留，加入受保護表達與雙重測試
語序歐化／被動過度：十篇零命中 → 移除；未來由真實案例觸發再加入
代名詞指涉不清：只有 1 至 2 處邊界案例 → 保留，低頻檢查
全文用詞不一致：原結果主要是跨篇格式差異 → 收斂為同篇概念叫法
排版格式一致性：清單外反覆出現 → 新增，區分單篇與系列模式
這項驗證不是為了證明作者幾乎沒有問題，而是用來排除不符合實際寫作型態的通用假設。
沒有出現「越寫越少錯」的明顯曲線。標點與格式問題從頭到尾大致穩定；第五篇後贅字候選略增，更像是語氣逐漸放鬆，而不是寫作品質退步。
因此，這套方法不假設作者會沿著單一的「越來越標準」方向進步。它只持續觀察：哪些問題真的存在，哪些所謂問題其實是風格。
十一、AI 快速執行規則
當不需要完整分析時，至少遵守以下規則：
預設只回報，不直接修改原文。
沒有問題可以直接說沒有，不得硬找。
必須指出具體問題，不能只說改完比較順。
先排除語氣、節奏、排比與必要重複。
贅字必須同時通過「語意不變」與「語氣節奏不變」。
受保護表達代表提高門檻，不是永久豁免。
單篇一致性與跨篇一致性分開判斷。
確認問題與邊界案例分開回報。
替代寫法只供參考，不能因為存在替代寫法就否定原句。
結構、篇幅、事實與標題不偷偷混入潤稿。
作者明確要求修改時，只做最小必要改動。
被作者確認為風格的表達，下次不要反覆當成問題。
十二、最終原則
潤稿不是把文字磨到沒有稜角。
錯字可以修，標點可以統一，指涉不清可以指出；但一句話裡的停頓、重複、囉嗦、突然岔出去，可能正是作者本人站在那裡的證據。
AI 最容易犯的錯，不是漏掉一個贅字，而是把自己的偏好誤認成文字品質。
所以這套方法最後只要求一件事：
先證明問題存在，再提出修改；無法證明時，把句子還給作者。
好的 AI 潤稿不一定讓文章看起來改了很多。
有時候它最有價值的判斷，正是：
這裡沒有需要被修好的地方。