# Good Writing Zh

> 中文好寫作指南：提升中文寫作品質與改寫既有文章。基於 Paul Graham、余光中、王鼎鈞的寫作智慧。 使用時機： - 用戶說「潤稿」「改寫」「rewrite」「讓文字更順」 - 用戶要求「改善文筆」「寫好一點」「高品質中文」 - 用戶提供文章並要求修改或潤飾 - 需要產出高品質中文內容時 技術文件（README、API 文件、CLI 說明）請使用保守模式（見下方模式三），避免改動結構化列舉與術語連綴。 觸發詞：/good-writing、/潤稿、good writing、潤稿、改寫、rewrite、文筆、讓文字更順、技術文件潤飾、conservative 模式

- Skill: `yelban/good-writing-zh` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add yelban/good-writing-zh`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yelban/good-writing-zh/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: yelban (https://skillmd.com/u/yelban)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yelban/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](references/guide.md)。整合自 Paul Graham〈Good Writing〉、余光中、王鼎鈞。*