good-writing-zh

中文好寫作

注意： 本 Skill 專注於句型結構精簡與節奏打磨。若需處理 AI 生成痕跡、翻譯腔與中國用語，請搭配 humanizer-tw。建議順序：先 humanizer-tw（去機器味）→ 再 good-writing-zh（打磨節奏）。

---

節奏規則

氣口

兩個標點符號（，。；：！？）之間，連續字數不超過 15–20 字。超過就該斷句或加逗號。

錯落

相鄰兩句長度差異應 > 5 字。避免連續 3 句以上長度相近（±3 字）。

句尾

• 名詞收尾 → 穩
• 動詞收尾 → 勁
• 助詞收尾（的、了、呢）→ 軟

避免連續句尾都落在同類型。

---

改寫技法

一、刪贅字（連續「的」）

連續三個「的」→ 想法沒整理好，至少刪一個。

原句：這是公司的新的產品的宣傳方案。
改寫：這是公司新產品的宣傳方案。
（理由：三連「的」刪為一個，語意不變）

原句：他提出的關於市場的未來的發展報告。
改寫：他提出的市場未來發展報告。
（理由：「關於」多餘，「的」可精簡為一個）

二、刪贅字（進行/實施/加以）

「進行」「實施」「加以」通常可直接刪除。

原句：我們對此問題進行了深入的討論。
改寫：我們深入討論了這個問題。
（理由：刪「進行」，動詞前移）

原句：相關部門已對該方案加以審核。
改寫：相關部門已審核該方案。
（理由：刪「加以」，直接用動詞）

三、拆長句

原則上不超過 30 字。例外：緊密條件句、排比句、專業術語連綴可放寬，但需以標點確保內部停頓。

原句：由於天氣不好加上交通阻塞的關係，所以他沒有辦法準時抵達會場參加會議。
改寫：天氣差，路又塞。他遲到了。
（理由：一句塞了兩個因果，拆開各自獨立）

原句：為了能夠更好地滿足客戶在不同場景下對於產品功能的多樣化需求，我們決定重新設計整個系統架構。
改寫：客戶需求多樣，現有架構撐不住。我們決定重新設計。
（理由：40+ 字壓縮為兩句，因果更清晰）

四、砍開頭

直接刪掉填充開頭，從重點開始。

原句：關於這個問題，我認為我們應該重新思考策略。
改寫：我們應該重新思考策略。
（理由：「關於這個問題」是廢話）

原句：基本上來說，這個方案的可行性是比較高的。
改寫：這個方案可行性高。
（理由：砍開頭 + 刪「是...的」句式）

五、還原強動詞

「弱動詞 ＋ 抽象名詞」→ 還原為單一強動詞。被動語態 → 主動語態。

常見模式：

• 「進行 X」→「X」
• 「做出 X」→「X」（做出決定 → 決定）
• 「給予 X」→「X」（給予協助 → 協助）
• 「加以 X」→「X」（加以改善 → 改善）
• 「達到 X 的目的」→「為了 X」
• 「被...所...」→ 主動語態

原句：我們需要對現有流程做出改善。
改寫：我們需要改善現有流程。
（理由：「做出改善」→ 直接用「改善」）

原句：這個問題被許多研究者所關注。
改寫：許多研究者關注這個問題。
（理由：「被...所...」→ 主動句，更有力）

原句：本計畫旨在達到提升效率的目的。
改寫：本計畫旨在提升效率。
（理由：「達到...的目的」是多餘包裝）

---

檢查清單

改寫完成後逐項檢查：

1. 原則上沒有超過 30 字的句子（緊密條件句、排比句、術語連綴除外，但需有標點停頓）
2. 沒有連續三個「的」
3. 相鄰句長差異 > 5 字，無 3 句以上等長（±3 字）
4. 開頭沒有填充廢話
5. 句尾沒有連續相同類型（連續「的」「了」「呢」）
6. 「進行」「實施」「加以」能刪的都刪了
7. 「弱動詞＋抽象名詞」已還原為強動詞，被動語態已轉主動

---

工作流程

模式一：改寫既有文章

依序輸出三個區塊：

<diagnosis> — 逐句掃描原文，列出所有違規：

• 哪些句子超過 30 字
• 哪裡有連續「的」
• 哪些開頭是廢話
• 哪些「弱動詞＋名詞」可還原
• 節奏是否單調（連續等長句）

<planning> — 對每個違規擬定修改策略：

• 在哪裡斷句、刪哪個贅字、怎麼還原動詞
• 確保拆句後邏輯仍連貫（必要時補銜接詞）

<rewrite> — 輸出改寫版本，以粗體標註主要修改處。

<diagnosis> 和 <planning> 是改寫流程的必要輸出，確保修改全面且一致。

模式二：寫作時自動套用

寫中文內容時，自動遵循上述節奏規則、改寫技法與檢查清單，不需額外提示。

模式三：技術文件保守模式（conservative）

觸發時機：處理技術 README、API 文件、CLI 說明、錯誤訊息、技術 blog，或使用者明確要求「只改標點/氣口，不動結構」。

這個模式之所以存在，是因為技術文件有大量不該被「潤飾」的內容：程式碼範例、命令列片段、錯誤訊息字串、API 名稱、參數列表。完整模式的「錯落」「打破公式化」規則若強行套用，會把結構化列舉（例如表格說明、指令解釋）改得面目全非，反而傷害資訊傳達。

只執行（四類）：

1. 刪連續三「的」—— 語意無損時
2. 刪「進行／加以／實施」—— 能直接用動詞時
3. 拆超過 30 字的單句 —— 但見下方術語連綴例外
4. 修氣口 —— 標點間連續 15–20 字加逗號斷開

停用：

• 「錯落」規則（相鄰句長差異 > 5 字）—— 技術列舉同結構是刻意的
• 「打破公式化段落」—— 首先/其次/最後在操作步驟中反而清楚
• 重組段落順序、重寫語義
• 動用「句尾類型輪換」

絕對不碰：

• 程式碼區塊（…、inline）
• CLI 指令、檔案路徑、URL、Markdown 連結語法
• 表格結構與欄位
• 英文技術術語（保留原樣，即使夾在中文句中）
• YAML front matter、語言選單、版本標註
• 使用者明確標示「不改」的區塊

術語連綴例外（即使超過 30 字也不強拆）：

以下情境的長片段視為已有「內部停頓」，不需要加逗號：

• 頓號列表：「.py .ts .js .go .rs .java .c .cpp .rb .cs .kt .scala .php」—— 每個副檔名都是一個停頓點
• 破折號引介：「完全多模態 —— graphify 會用 Claude vision 從這些內容中提取概念」—— 破折號已分段
• 括號補充：「對程式碼檔案做結構分析（類、函式、匯入、呼叫圖、docstring）」—— 括號本身是停頓
• 連字符連綴：「程式碼-論文之間的邊會比程式碼-程式碼邊權重更高」—— - 提供視覺停頓

判斷原則：一個片段若去掉中英文/數字/標點後剩不到 15 個中文字，即使字元計數長也不算違規。

---

理論背景見 references/guide.md。整合自 Paul Graham〈Good Writing〉、余光中、王鼎鈞。