Good Writing Tw

---
name: good-writing-tw
version: "1.2.1"
description: |
  中文好寫作：依 Paul Graham、余光中、王鼎鈞的原則改寫既有中文，處理氣口、句長錯落、句尾、贅字與強動詞，讓文字更順、更有節奏。
  使用時機：使用者說「潤稿」「改寫」「讓文字更順」「改善文筆」，或提供文章要求潤飾。技術文件（README、API 文件）走保守模式，不動結構化列舉與術語。去 AI 味與中國用語交給 humanizer-tw。
  觸發詞：/good-writing-tw、/潤稿、潤稿、改寫、文筆、技術文件潤飾。
user-invocable: true
argument-hint: "<article text or file path to rewrite>"
---

# 中文好寫作

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

---

## 觸發詞與模式速查

- 觸發詞：/good-writing-tw、/潤稿、good writing、潤稿、改寫、rewrite、文筆、讓文字更順、改善文筆、寫好一點、高品質中文、技術文件潤飾、conservative 模式。使用者提供文章要求修改或潤飾，或需要產出高品質中文內容時也適用。
- 技術文件（README、API 文件、CLI 說明）用模式三保守模式，避免改動結構化列舉與術語連綴。

## 節奏規則

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

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

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

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

---

## 改寫技法

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

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

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

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

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

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

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

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

### 三、拆長句

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

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

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

**拆句 ≠ 連發造勢（cross-guard）**：拆長句的目的是因果清晰與節奏，不是製造戲劇感。連續三個以上短促斷句堆疊語勢（「沒有人停下。沒有人回頭。一切都變了。」）是新一代 AI 文的 tell（humanizer-tw 類別十三「短句連發戲劇腔」）。拆完的句子要長短相間：一兩個短句收束可以，整段拆成等短斷句即失敗——那不是節奏，是把一種 AI 味換成另一種。

### 四、砍開頭

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

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

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

### 五、還原強動詞

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

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

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

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

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

---

## 防過度矯正（完整模式也適用）

節奏規則的數字（氣口 15–20 字、句長差 > 5 字、單句 30 字）是**預設值，不是鐵律**。硬套數字上限的失敗模式是把作者的風格也剷平——比漏改更糟：

1. **作者刻意的風格不算違規**：有內部停頓、念得出口的長句（余光中式綿長句）、刻意的排比、刻意的重複——能看出作者「為什麼這樣寫」的地方保留，不硬拆。判準同 humanizer-tw 的防誤殺：寧可漏改，不可錯改。
2. **別把全文改成同一種節奏**：每句都卡在 15–20 字、每句句長都精準差 5 字，改出來是節拍器不是文章——均質化本身就是新的 AI tell。規則用來抓「明顯單調」，不是把每句校準到公差內。
3. **風格樣本優先於預設數字**：使用者提供過自己的書寫樣本、或前一步 humanizer-tw 已做個人風格校準時，氣口／錯落／句尾的目標**對齊樣本**，不套本檔預設值。樣本作者愛寫長句，就別把成品全改成短句——串接的目的是保住使用者的聲音，不是覆蓋它。

---

## 檢查清單

改寫完成後逐項檢查：

1. 原則上沒有超過 30 字的句子（緊密條件句、排比句、術語連綴除外，但需有標點停頓）
2. 沒有連續三個「的」
3. 相鄰句長差異 > 5 字，無 3 句以上等長（±3 字）
4. 開頭沒有填充廢話
5. 句尾沒有連續相同類型（連續「的」「了」「呢」）
6. 「進行」「實施」「加以」能刪的都刪了
7. 「弱動詞＋抽象名詞」已還原為強動詞，被動語態已轉主動
8. **改過頭？** 拆句後沒有連續短促斷句造勢；作者刻意的長句／排比／重複沒被剷平；全文不是同一種節奏（見「防過度矯正」）

---

## 工作流程

### 模式一：改寫既有文章

依序輸出三個區塊：

**`<diagnosis>`** — 逐句掃描原文，列出所有違規：
- 哪些句子超過 30 字
- 哪裡有連續「的」
- 哪些開頭是廢話
- 哪些「弱動詞＋名詞」可還原
- 節奏是否單調（連續等長句）

**`<planning>`** — 對每個違規擬定修改策略：
- 在哪裡斷句、刪哪個贅字、怎麼還原動詞
- 確保拆句後邏輯仍連貫（必要時補銜接詞）

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

**輸出前回掃（兩頭都查）**：**改過頭？**——對照「防過度矯正」三條，把誤拆的風格句還原；**改不夠？**——對照檢查清單 1–7，補漏。

> `<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〉、余光中、王鼎鈞。*