tw-writing · diff
git:20260912.da340f8 to git:20260912.9fa620b
8 added, 8 removed. Audit A to A.
---
name: tw-writing
description: >
繁體中文（台灣）清晰、精確、簡潔的寫作規範。撰寫、改寫、審查、潤稿或翻譯
繁體中文內容時使用。涵蓋技術文件、軟體文件、README、設計文件、規格書、SOW、
工程報告、錯誤訊息、commit message，以及 AI Agent 產生的繁體中文內容。
包含台灣用語與中國大陸用語對照、中英文混排、標點、數字格式、AI 腔調反模式
及最終檢查清單。以 The Elements of Style 的寫作原則為基礎，針對繁體中文語法、
資訊結構與技術寫作進行本地化。
---
# 繁體中文寫作版 The Elements of Style
## 1. 目的與適用範圍
### 1.1 目的
本 Skill 用於產生、修改、審查繁體中文文字，使內容具備：
1. **清楚（Clarity）**
2. **精確（Precision）**
3. **簡潔（Concision）**
4. **一致（Consistency）**
5. **自然（Naturalness）**
核心原則：
> **清楚優先於簡潔，簡潔優先於華麗。**
不要為了「短」而刪除必要資訊，也不要為了「正式」而增加沒有資訊價值的文字。
本 Skill 是繁體中文寫作規範，**不是英文文法規則的逐條翻譯**。
### 1.2 適用文件
- 技術文件、軟體文件、API 文件
- README、設計文件、架構文件
- 規格書、SOW、工程報告
- 操作手冊、疑難排解文件
- 錯誤訊息、日誌訊息、UI 文字
- commit message、PR 描述、程式碼註解
- AI Agent 產生或編輯的繁體中文內容
### 1.3 不適用或需調整的情況
以下情況不套用本 Skill，或套用前需先確認：
- **法律契約與法規文字**：用字受法律效力約束，不得為求簡潔改寫。
- **行銷文案**：目的是說服而非說明，容許本 Skill 限制的修辭。
- **引用他人文字**：引用時保留原貌，不改寫。
- **既有格式規範**：政府公文、學術期刊、特定標準（如 ISO 文件範本）有自己的格式要求時，優先遵循該規範。
- **既有專案風格指南**：專案若已有風格指南，以該指南優先；本 Skill 補充未涵蓋的部分。
判斷原則：
> **本 Skill 服務於「讓讀者正確理解」。當其他要求優先於此目標時，本 Skill 讓步。**
### 1.4 本 Skill 的檔案
| 檔案 | 內容 | 何時讀取 |
|---|---|---|
| `SKILL.md` | 完整規範 | 一律適用 |
| `references/taiwan-terms.md` | 台灣用語與中國大陸用語完整對照表 | 需要查詢個別術語，或審查疑似中國大陸用語時 |
- `references/taiwan-terms.md` 是 Agent 語意判斷用的查表資料。若執行環境另外提供 [`zhtw`](https://github.com/sysprog21/zhtw-mcp) MCP 工具，該工具以規則庫做機械檢查，兩者互補而非重複；見 §25「外部工具（若可用）」。
+ `references/taiwan-terms.md` 是 Agent 語意判斷用的查表資料。若執行環境另外提供 [`zhtw-mcp`](https://github.com/sysprog21/zhtw-mcp) MCP 工具，該工具以規則庫做機械檢查，兩者互補而非重複；見 §25「外部工具（若可用）」。
---
## 2. 結構原則
### 2.1 一段一主題
一個段落應主要處理一個完整的主題、論點或步驟。
避免：
- 同一段同時討論多個不相關問題。
- 在段落中途突然改變主題。
- 為了避免換行，把多個概念塞進同一段。
優先：
> 一個段落 = 一個主要意念。
如果主題改變，建立新段落。
### 2.2 段首先說重點
一般說明性與技術性文件，優先採用：
> **結論 → 理由 → 細節 → 例外**
而不是：
> 背景 → 背景的背景 → 歷史 → 問題 → 最後才出現結論
例如：
不佳：
> 由於目前系統架構具有多種不同的部署方式，而不同部署方式在網路連線及服務啟動流程上也存在一些差異，因此在進行相關設定時，需要特別注意不同環境的差異。
較佳：
> **不同部署環境需要使用不同的服務啟動設定。**
> 原因是各環境的網路連線方式與服務啟動流程不同。
### 2.3 一句話處理一個主要意念
不是要求所有句子都很短。
而是：
> 一個句子應有一個清楚的主要動作或判斷。
過長句子若包含多個邏輯關係，應拆分。
不佳：
> 系統啟動後會先讀取設定檔並建立資料庫連線，如果連線失敗則會重新嘗試，當重試次數超過設定值時會寫入錯誤日誌並停止服務，因此管理員需要確認資料庫服務是否正常。
較佳：
> 系統啟動後會先讀取設定檔並建立資料庫連線。
> 如果連線失敗，系統會重新嘗試。超過設定的重試次數後，系統會記錄錯誤並停止服務。
> 因此，管理員應先確認資料庫服務是否正常。
---
## 3. 清楚 Clarity
### 3.1 使用明確的主詞
避免讓讀者猜測「誰做了什麼」。
不佳：
> 設定完成後即可進行測試。
較佳：
> 完成設定後，**管理員即可測試服務**。
但若主詞在上下文中非常明確，不必為了形式上的完整而重複。
### 3.2 優先使用具體動詞
優先：
- 建立
- 讀取
- 寫入
- 更新
- 刪除
- 驗證
- 比較
- 計算
- 啟動
- 停止
- 設定
- 檢查
- 產生
- 解析
- 傳送
- 接收
避免過度依賴：
- 進行
- 執行相關作業
- 作相關處理
- 做出相關調整
- 進行相關設定
- 進行相關確認
例如：
> 對設定檔進行修改。
改為：
> **修改設定檔。**
### 3.3 使用具體名詞
避免：
- 相關內容
- 相關資料
- 相關資訊
- 此部分
- 該項目
- 這個問題
- 適當的方式
- 必要的處理
- 某些情況
除非上下文已經明確定義其所指內容。
優先直接說明對象：
> 修改 `config.yaml` 中的 `timeout` 設定。
而不是：
> 修改相關設定。
### 3.4 避免模糊代詞
特別注意：
- 這
- 此
- 該
- 其
- 它
- 他
- 這部分
- 該項目
- 相關內容
如果代詞可能有兩個以上的指涉對象，直接重複名詞。
不佳：
> 服務讀取設定檔後會建立連線，如果它失敗，系統會重試。
「它」可能指服務、設定檔或連線。
較佳：
> 服務讀取設定檔後會建立連線。如果**連線**失敗，系統會重試。
### 3.5 保持相關詞靠近
修飾語應靠近它修飾的對象。
不佳：
> 系統會在收到請求後，使用設定檔中的 timeout 值，在等待資料庫回應時進行連線逾時判斷。
較佳：
> 系統收到請求後，會使用設定檔中的 `timeout` 值判斷資料庫連線是否逾時。
### 3.6 消除修飾範圍的歧義
中文沒有形態標記區分修飾範圍，並列結構特別容易產生歧義。
不佳：
> 刪除舊的日誌檔案與備份。
這句有兩種解讀：
1. 刪除「舊的日誌檔案」與「所有備份」。
2. 刪除「舊的日誌檔案」與「舊的備份」。
較佳（依實際語意擇一）：
> 刪除舊的日誌檔案與舊的備份。
或：
> 刪除舊的日誌檔案，以及所有備份。
同樣容易產生歧義的結構：
| 歧義結構 | 問題 | 改寫方式 |
|---|---|---|
| A 和 B 的 C | 「A 和 (B 的 C)」或「(A 和 B) 的 C」 | 重複中心語，或調整語序 |
| 三個系統的節點 | 「三個系統」或「三個節點」 | 「三套系統的節點」／「系統中的三個節點」 |
| 不完全支援 | 「部分支援」或「完全不支援」 | 「部分支援」／「不支援」 |
| 沒有找到所有檔案 | 「一個都沒找到」或「找到但不齊全」 | 「找不到任何檔案」／「部分檔案未找到」 |
**技術文件中，寧可重複名詞，也不要留下歧義。**
---
## 4. 簡潔 Concision
### 4.1 刪除贅字
每個字都應該有功能。
刪除：
- 沒有資訊價值的修飾語
- 重複資訊
- 空泛的開場
- 不必要的名詞化
- 不必要的「進行」
- 不必要的「相關」
- 不必要的「部分」
- 不必要的「一個」
- 不必要的「可以」
例如：
> 在目前的情況之下，我們可以看到系統目前仍然存在問題。
改為：
> **目前系統仍有問題。**
### 4.2 「進行＋名詞」優先改成動詞
常見替換：
| 避免 | 優先 |
|---|---|
| 進行分析 | 分析 |
| 進行測試 | 測試 |
| 進行確認 | 確認 |
| 進行設定 | 設定 |
| 進行修改 | 修改 |
| 進行檢查 | 檢查 |
| 進行比較 | 比較 |
| 進行處理 | 處理 |
| 進行調整 | 調整 |
| 進行驗證 | 驗證 |
例外：
當「進行」本身具有語意功能時，不必強制刪除。例如「系統正在進行備份」強調動作持續中，改成「系統正在備份」語意相同但語感不同，可依上下文選擇。
### 4.3 避免「相關」
「相關」通常沒有增加資訊。
不佳：
> 請確認相關設定是否正確。
較佳：
> 請確認 `server.yaml` 中的設定是否正確。
### 4.4 避免「部分」
不佳：
> 部分使用者可能會遇到此問題。
如果知道範圍：
> Windows 使用者可能會遇到此問題。
如果不知道：
> 某些使用者可能會遇到此問題。
### 4.5 避免不必要的「可以」
「可以」可能表示：
1. capability
2. permission
3. possibility
4. recommendation
不要無條件保留。
例如：
> 系統可以支援 TLS 1.3。
如果是在描述 capability：
> **系統支援 TLS 1.3。**
如果是在描述操作能力：
> **管理員可以啟用 TLS 1.3。**
**例外**：若文件採用 RFC 2119 與 RFC 8174 的規範語意（見 §16.2），「可以」是 MAY / OPTIONAL 的正式對應詞，不屬於本節要刪除的模糊用法，不要因追求簡潔而刪除。
### 4.6 不要為了簡潔犧牲精確性
以下兩句長度較短，但意思不同：
> 系統支援 TLS。
> 系統支援 TLS 1.2 與 TLS 1.3。
技術文件應選第二句。
**精確資訊不可因追求簡潔而刪除。**
---
## 5. 主動語態 Active Voice
### 5.1 主動句優先
The Elements of Style 將 active voice 視為通常更直接的表達方式，但原則本身也承認被動語態在特定情境下合理。
繁體中文同樣採用：
> **主動句優先，但不禁止被動句。**
例如：
不佳：
> 設定檔會由系統在啟動時被讀取。
較佳：
> **系統啟動時會讀取設定檔。**
中文的被動不一定要用「被」。以下句子形式上是主動，語意上是被動，通常比「被」字句自然：
> 設定檔在服務啟動時載入。
### 5.2 被動句的合理用途
以下情況可以使用被動句：
#### A. 施事者未知
> 伺服器已遭入侵。
#### B. 施事者不重要
> 所有資料都會被加密儲存。
#### C. 強調受事者
> 金鑰不得被匯出。
#### D. 技術規範需要突出物件
> 該欄位必須被設定為 UTF-8。
但如果自然，可以改為：
> **該欄位必須使用 UTF-8。**
---
## 6. 肯定表達 Positive Form
### 6.1 優先使用直接肯定表達
不佳：
> 不允許未經授權的使用者存取。
如果語意允許：
> **只有授權使用者可以存取。**
但不要為了形式上的「肯定句」而改變法律、規格或安全語意。
例如：
> 不得匯出私鑰。
不要改成：
> 只能在系統內保留私鑰。
兩者可能不是完全等價。
### 6.2 「不要」與「不得」要區分
#### 不要
通常表示建議：
> 不要將密碼寫入 Git repository。
#### 不得
表示規範或禁止：
> 密碼不得寫入 Git repository。
#### 禁止
表示明確禁止：
> 系統禁止未授權使用者匯出私鑰。
不要把不同強度混在一起。
### 6.3 避免雙重否定
雙重否定增加讀者的認知成本，且容易產生歧義。
| 避免 | 優先 |
|---|---|
| 並非不支援 | 支援 |
| 不是不可能 | 可能 |
| 沒有不通過的測試 | 所有測試都通過 |
| 不建議不啟用 | 建議啟用 |
例外：當雙重否定的語意確實弱於直接肯定時，保留原意。
> 「並非所有節點都不可用」不等於「所有節點都可用」。
---
## 7. 具體語言 Concrete Language
### 7.1 用事實取代形容詞
避免：
> 系統具有非常高的效能。
較佳：
> 系統每秒可處理 5,000 個請求。
避免：
> 系統具有良好的安全性。
較佳：
> 系統使用 TLS 1.3 保護傳輸資料，並使用 AES-256-GCM 加密敏感資料。
### 7.2 用數字取代模糊程度
避免：
- 很快
- 很慢
- 大量
- 少量
- 高效能
- 高可靠性
- 極高
- 相當
- 大幅
如果可以量化，就量化：
> 回應時間低於 100 ms。
而不是：
> 回應速度非常快。
### 7.3 標示不確定性，不要把推測寫成事實
如果資訊未經驗證，明確標示；不要為了讓句子看起來肯定而移除限定條件。
不佳：
> 此問題是由連線池耗盡造成的。
（若尚未確認）較佳：
> 目前推測此問題由連線池耗盡造成，**尚未驗證**。
其他可用的標示方式：
- 依據 v1.4 文件
- 在 Windows 11 環境下實測
- 根據 2026-08-20 的日誌
- 尚未重現
- 需進一步確認
**沒有依據的數字與引用不得寫入文件。** 見 §25。
---
## 8. 平行結構 Parallel Structure
平行概念應使用平行語法。
不佳：
> 系統支援資料建立、修改資料以及資料的刪除。
較佳：
> 系統支援建立、修改與刪除資料。
列表尤其重要：
不佳：
- 安裝套件
- 設定環境變數
- 系統服務需要重新啟動
- 驗證安裝結果
較佳：
- 安裝套件
- 設定環境變數
- 重新啟動系統服務
- 驗證安裝結果
平行結構也適用於：
- 標題（同層級標題使用相同句型）
- 表格欄位（同一欄的儲存格使用相同結構）
- 選項說明（同一組選項使用相同開頭）
---
## 9. 資訊順序 Information Order
### 9.1 依文件類型選擇順序
一般技術文件：
> 結論 → 原因 → 方法 → 細節 → 例外
操作文件：
> 前置條件 → 步驟 → 結果 → 疑難排解
故障分析：
> 現象 → 影響 → Root Cause → 修正 → 預防措施
設計文件：
> Problem → Goal → Constraints → Design → Alternatives → Decision
API 文件：
> 用途 → 請求格式 → 參數 → 回應格式 → 錯誤碼 → 範例
### 9.2 把重要資訊放在強調位置
中文不像英文一樣固定依賴句尾焦點。
因此不要機械套用「重要資訊一定放句尾」。
應根據資訊結構選擇：
- 句首
- 句尾
- 獨立句
- 標題
- 列表
例如：
> **只有在 Windows 環境下才會發生此問題。**
或：
> 此問題**只有在 Windows 環境下發生**。
兩者皆可，視上下文決定。
---
## 10. 中文語法特有規則
### 10.1 的／地／得
基本規則：
- **的**：修飾名詞
- **地**：修飾動詞
- **得**：補充動作或狀態
例如：
> 穩定的系統
> 穩定地執行
> 執行得很穩定
但技術文件應優先考慮能否直接改寫：
> 穩定地執行服務
可改為：
> **穩定執行服務**
### 10.2 避免過度「的」
不佳：
> 系統所提供的可以用來管理金鑰的功能。
較佳：
> **系統提供的金鑰管理功能。**
更佳：
> **系統提供金鑰管理功能。**
一個名詞短語中出現三個以上的「的」，通常表示需要拆句。
### 10.3 名詞化改回動詞
不佳：
> 完成設定檔的修改後進行服務的重新啟動。
較佳：
> **修改設定檔後重新啟動服務。**
### 10.4 條件在前，結論在後
中文習慣把條件、時間、目的放在主句之前；英文常放在主句之後。直接沿用英文語序會產生翻譯腔。
不佳（英文語序）：
> 請重新啟動服務，如果修改了 `config.yaml`。
較佳（中文語序）：
> **如果修改了 `config.yaml`，請重新啟動服務。**
**例外**：當條件很長而結論很短時，先給結論，再用獨立句說明條件。這與 §2.2「段首先說重點」一致。
> **修改後必須重新啟動服務。**
> 適用情況包括修改 `config.yaml`、更換 TLS 憑證，以及調整記憶體上限。
### 10.5 連接詞與並列
#### 頓號
並列的詞或短語使用頓號「、」，不使用逗號：
> 系統支援 TLS 1.2、TLS 1.3 與 QUIC。
並列的子句使用逗號：
> 系統會讀取設定檔，建立連線，然後開始接收請求。
#### 與／及／以及／和
- 技術文件優先使用「與」。
- 三項以上時，前面用頓號，最後一項用「與」或「以及」。
- 不要在同一句中堆疊多個「以及」。
不佳：
> 系統支援建立以及修改以及刪除金鑰。
較佳：
> 系統支援建立、修改與刪除金鑰。
#### 「或」的歧義
中文的「或」可能是 inclusive 或 exclusive。規格書中若語意重要，明確標示：
> 可使用 API token 或 OAuth 存取（兩者可同時啟用）。
> 必須選擇 RSA 或 ECDSA，兩者擇一。
#### 避免「和／或」
「和／或」是 and/or 的直譯，中文不自然。改為明確表述：
不佳：
> 請提供帳號和／或電子郵件。
較佳：
> 請提供帳號、電子郵件，或兩者皆提供。
### 10.6 量詞
使用正確量詞可提升可讀性。技術文件常用：
| 對象 | 量詞 | 範例 |
|---|---|---|
| 伺服器、機器 | 台 | 三台伺服器 |
| 文件、報告 | 份 | 一份設計文件 |
| 金鑰、憑證 | 組／張 | 一組金鑰、一張憑證 |
| 需求、變更 | 項 | 五項需求 |
| 訊息、通知 | 則 | 十則錯誤訊息 |
| 資料、交易 | 筆 | 1,000 筆資料 |
| 請求、嘗試 | 次 | 三次重試 |
| 節點、執行緒 | 個 | 三個節點 |
不確定時使用「個」，但不要寫「一個資料」「一個文件」這類明顯不合的組合。
### 10.7 避免英文直譯腔
不要因為英文原文如此寫，就直接保留英文句法。
| 直譯腔 | 自然中文 |
|---|---|
| 基於安全性的原因 | 基於安全考量／為了安全 |
| 這是一個很好的例子 | 這是好例子 |
| 使用者們 | 使用者 |
| 它是被設計來處理大量請求的 | 其設計目的是處理大量請求 |
| 當服務啟動的時候 | 服務啟動時 |
| 對於開發者來說 | 對開發者而言（或直接刪除） |
| 在部署的過程中 | 部署時 |
| 有一個設定檔存在於根目錄 | 根目錄下有一個設定檔 |
| 系統的設定的檔案的路徑 | 系統設定檔的路徑 |
| 讓我們來看看 | （刪除） |
中文不使用複數標記。「們」只用於人，且技術文件中通常可省略。
過長的前置修飾同樣來自英文關係子句的直譯：
不佳：
> 一個能夠支援多種驗證方式並且具備完整稽核功能的身分管理系統。
較佳：
> **身分管理系統支援多種驗證方式，並提供完整稽核功能。**
### 10.8 避免過度使用「我們」
英文技術文件常使用：
> We use...
中文通常可以直接：
> 使用……
例如：
> 我們使用 SQLite 儲存資料。
可改為：
> **使用 SQLite 儲存資料。**
若需要明確指出責任主體：
> **開發團隊使用 SQLite 儲存資料。**
---
## 11. 台灣用語
### 11.1 使用台灣慣用術語
本 Skill 產出的是**台灣繁體中文**。不得使用簡體字，也不得使用中國大陸慣用術語。
高頻對照（完整表見 `references/taiwan-terms.md`）：
| 中國大陸用語 | 台灣用語 |
|---|---|
| 軟件／硬件 | 軟體／硬體 |
| 網絡 | 網路 |
| 數據庫 | 資料庫 |
| 信息 | 資訊／訊息 |
| 默認／缺省 | 預設 |
| 接口／界面 | 介面 |
| 內存 | 記憶體 |
| 硬盤 | 硬碟 |
| 服務器 | 伺服器 |
| 用戶 | 使用者 |
| 賬號 | 帳號 |
| 打印 | 列印 |
| 存儲 | 儲存 |
| 緩存 | 快取 |
| 隊列 | 佇列 |
| 線程／進程 | 執行緒／行程 |
| 字符串／字符 | 字串／字元 |
| 數組 | 陣列 |
| 函數（程式） | 函式 |
| 對象／類 | 物件／類別 |
| 變量 | 變數 |
| 循環／遞歸 | 迴圈／遞迴 |
| 算法 | 演算法 |
| 異常 | 例外 |
| 源代碼 | 原始碼 |
| 調試 | 除錯 |
| 兼容 | 相容 |
| 集成 | 整合 |
| 優化 | 最佳化 |
| 鏡像 | 映像檔 |
| 集群 | 叢集 |
| 端口 | 連接埠 |
| 帶寬 | 頻寬 |
| 分辨率 | 解析度 |
| 屏幕／鼠標 | 螢幕／滑鼠 |
| 菜單 | 選單 |
| 刷新 | 重新整理 |
| 登錄（login） | 登入 |
| 卸載 | 解除安裝 |
| 激活 | 啟用 |
| 視頻／音頻 | 影片／音訊 |
| 人工智能 | 人工智慧 |
### 11.2 同形異義詞
以下詞在兩岸都存在，但意思不同。**這類詞最容易出錯，因為字形是繁體、拼寫也正確，只有語意錯誤。**
| 詞 | 台灣語意 | 中國大陸語意 | 台灣應使用 |
|---|---|---|---|
| 文件 | document | file | file → **檔案** |
| 文檔 | （不使用） | document | document → **文件** |
| 質量 | mass（物理量） | quality | quality → **品質** |
| 項目 | item、款項 | project | project → **專案** |
| 程序 | procedure、法律程序、開機程序 | program | program → **程式** |
| 登錄 | 登記、記錄 | login | login → **登入** |
| 數據 | 量測數值 | data | data → **資料** |
| 信息 | （少用） | information | information → **資訊**；message → **訊息** |
| 智能 | （少用） | intelligence | intelligence → **智慧** |
例如：
不佳：
> 刪除項目中的臨時文件以提升系統質量。
較佳：
> **刪除專案中的暫存檔案，以提升系統品質。**
### 11.3 用字
使用教育部標準字體用字：
| 避免 | 使用 |
|---|---|
| 裏 | 裡 |
| 羣 | 群 |
| 佈署 | 部署 |
| 佔用 | 占用 |
| 祗 | 只 |
| 傳送門 | 連結／傳送點／捷徑（依情境擇一） |
「台」與「臺」在正式文件中優先使用「臺」（如「臺北」「臺灣」）；一般技術文件使用「台」亦可，但同一份文件必須一致。
### 11.4 全形與半形
- 英文字母、阿拉伯數字一律使用**半形**。
- 中文語境的標點使用**全形**（見 §14）。
- 不使用全形英數字：應寫成 `API`、`123`，而非全形形式。
- 不使用全形空格。
### 11.5 查詢完整對照表
需要確認個別術語時，讀取 `references/taiwan-terms.md`。該檔案涵蓋作業系統、網路、程式語言、資料結構、UI 元件與雲端服務的用語對照。
---
## 12. 中英文混排
### 12.1 技術術語保留原文
第一次出現：
> 多因素驗證（Multi-Factor Authentication, MFA）
後續：
> MFA
判斷原則：
- 已有穩定中譯且讀者熟悉 → 使用中文（如「快取」「佇列」）。
- 中譯不穩定或讀者慣用原文 → 保留原文（如 token、webhook、middleware）。
- 專有名詞、產品名、標準名 → 一律保留原文。
同一份文件對同一概念只能有一種選擇。見 §19。
### 12.2 API、CLI、檔名、參數使用行內程式碼
例如：
> 執行 `git status`。
> 修改 `config.yaml`。
> 將 `timeout` 設定為 `30`。
需要使用行內程式碼的對象：
- 指令與指令參數
- 檔名與路徑
- 環境變數
- 函式、類別、變數名稱
- 設定鍵與設定值
- HTTP 方法、狀態碼、標頭名稱
- 精確的字串值
### 12.3 不要任意翻譯標準名稱
例如：
> Transport Layer Security（TLS）
不要自行創造非標準中文名稱取代正式名稱。
標準、協定、API、產品名稱應保持一致，並維持原本的大小寫：`OAuth`（非 `Oauth`）、`OpenAPI`、`PostgreSQL`、`macOS`、`npm`、`ID`、`URL`、`JSON`。
### 12.4 中英文之間保留空格
在中文字與英文、數字之間加一個半形空格：
> 使用 Python 開發服務。
> 支援 Windows 11 與 Linux。
> 將 `timeout` 設為 `30` 秒。
**不加空格的情況：**
- 全形標點與英文之間：「支援 Python，也支援 Go。」
- 全形括號內外：「多因素驗證（MFA）已啟用。」
- 程式碼、URL、檔名、版本號內部：`config.yaml`、`v1.2.3`
- 百分比與度數符號：`50%`、`30°C`、`45°`
**加空格的情況：**
- 中文與行內程式碼之間
- 數字與一般單位之間：`128 MB`（見 §13.2）
### 12.5 縮寫
- 首次出現時寫全名並附縮寫，之後只用縮寫。
- 中文句子不使用英文複數形。寫「三個 API」，不寫「三個 APIs」。
- 縮寫維持原本的大小寫。
- 中文句子不使用 e.g.、i.e.、etc.，改用「例如」「即」「等」。
---
## 13. 數字、單位、日期與版本
### 13.1 數字優先使用阿拉伯數字
技術文件：
> 3 個節點
> 128 MB
> 30 秒
> 2026-08-22
固定用語與成語保留中文數字：二進位、第三方、一致性。
### 13.2 數字與單位之間保留空格
推薦：
> 128 MB
> 10 ms
> 5 GB
> 2 GHz
不要：
> 128MB
**例外**：百分比與度數符號不加空格（`50%`、`30°C`、`45°`）。若特定標準、API 或產品官方格式另有規定，優先遵循該格式。
### 13.3 千分位與範圍
- 四位數以上使用千分位逗號：`10,000 筆資料`。
- 年份、版本號、埠號、識別碼不使用千分位：`2026`、`8080`。
- 數值範圍使用「至」或連接號，同一份文件只用一種：`10 至 20 ms`。
- 範圍是否包含端點若有影響，明確寫出：`0 至 100（含兩端）`。
### 13.4 日期與時間
本 Skill 預設使用：
> `YYYY-MM-DD`
例如：
> 2026-08-22
避免在技術文件中混用：
> 2026/08/22
> 2026-08-22
> 2026 年 8 月 22 日
除非文件類型有特定要求。
時間格式：
- 使用 24 小時制：`14:30`。
- 標示時區：`2026-08-22 14:30 (UTC+8)`，或使用 ISO 8601：`2026-08-22T14:30:00+08:00`。
- 跨時區的日誌與事件記錄一律標示時區。
### 13.5 版本號
- 保留原始格式，不改寫：`v1.2.3`、`3.12.1`、`22H2`。
- 明確標示版本範圍：「需要 Python 3.10 以上」，而非「較新版本的 Python」。
- 「以上」「以下」是否含本數若有影響，明確寫出：`3.10 以上（含 3.10）`。
---
## 14. 標點符號
### 14.1 中文語境使用全形標點
例如：
> 系統支援 TLS 1.2、TLS 1.3，以及 QUIC。
常用全形標點：
| 符號 | 名稱 | 用途 |
|---|---|---|
| `，` | 逗號 | 分隔子句 |
| `、` | 頓號 | 分隔並列的詞 |
| `。` | 句號 | 句子結束 |
| `：` | 冒號 | 引出說明或清單 |
| `；` | 分號 | 分隔並列的長子句 |
| `？` | 問號 | 疑問句 |
| `！` | 驚嘆號 | 技術文件盡量不用 |
| `（）` | 圓括號 | 補充說明 |
| `「」` | 引號 | 引用、標示 |
| `『』` | 內層引號 | 引號內的引號 |
| `《》` | 書名號 | 書名、法規名 |
| `——` | 破折號 | 補充、轉折 |
| `……` | 刪節號 | 省略 |
即使句子以英文單字或行內程式碼結尾，句號仍使用全形：
> 預設值為 `30`。
### 14.2 頓號與逗號
- 並列的**詞**用頓號：「支援 JSON、YAML 與 TOML。」
- 並列的**子句**用逗號：「系統讀取設定，建立連線，然後開始服務。」
- 不要用半形逗號取代頓號。
### 14.3 引號與書名號
- 使用直角引號「」，不使用英文彎引號。
- 引號內再引用時使用『』。
- 書名、法規名使用《》。標準名稱與產品名稱**不使用**書名號，直接寫原文：`ISO/IEC 27001`、`RFC 8446`。
- 標示特定字詞時優先使用行內程式碼或粗體，而非引號。
### 14.4 括號
- 中文語境使用全形（），前後不加空格。
- 括號內若全為英文，其內部標點使用半形：多因素驗證（Multi-Factor Authentication, MFA）。
- 括號內的補充不應包含句子的必要資訊。若讀者非讀不可，就不要放進括號。
### 14.5 破折號與刪節號
- 破折號使用「——」，佔兩個字寬。
- 刪節號使用「……」，佔兩個字寬，不使用三個半形句點。
- 技術文件慎用破折號。英文寫作常用破折號插入補充，直接搬到中文會顯得鬆散；多數情況改用括號或獨立句更清楚。
- 此規則規範**句子內**用來插入補充的破折號。標題中以單一半形 em dash 分隔標籤與說明（如「Pass 1 — Structure」）不屬於這裡的破折號，不必比照上述規則加倍。
### 14.6 程式碼使用 ASCII 標點
例如：
```text
config.yaml
timeout: 30
```
不要把程式碼中的半形冒號改成全形冒號。
**這條規則沒有例外。** 錯誤的全形標點會讓程式碼無法執行。同樣適用於引號、括號、逗號、減號與空格。
### 14.7 列表項目的結尾標點
同一份清單必須一致：
- 每項都是完整句子 → 全部加句號。
- 每項都是短語 → 全部不加標點。
- 不要在項目末尾使用分號。
- 不要混用。
### 14.8 避免驚嘆號與連續標點
- 技術文件不使用驚嘆號表達語氣。警告使用 `**警告**` 或 Markdown 提示區塊標示。
- 不使用連續標點營造語氣。
- 不以全形空格或多餘標點製造版面效果。
---
## 15. Markdown 與版面
### 15.1 標題
標題應直接描述內容。
避免：
```markdown
## 一些需要注意的事情
```
優先：
```markdown
## 注意事項
```
避免：
```markdown
## 關於這個問題我們需要知道什麼
```
優先：
```markdown
## 問題原因
```
其他規則：
- 一份文件只有一個 H1。
- 標題層級不跳級（H2 之後是 H3，不是 H4）。
- 標題使用名詞短語或祈使短語，不使用完整句子。
- 標題不以句號結尾。
- 子標題不重複上層標題已有的字詞。
### 15.2 列表
列表中的項目應保持語法平行。
不佳：
```markdown
- 安裝 Python
- 環境變數設定
- 需要重新啟動服務
- 驗證是否成功
```
較佳：
```markdown
- 安裝 Python
- 設定環境變數
- 重新啟動服務
- 驗證安裝結果
```
如果每個項目是完整句子，則全部使用完整句子。
- 有先後順序或需要被引用時使用編號列表，否則使用項目符號。
- 巢狀不超過三層。超過三層表示結構應改為小節。
### 15.3 表格
- 用於「多個項目 × 多個屬性」的比較。單一維度的資訊使用列表。
- 欄位標題使用名詞短語，不使用完整句子。
- 同一欄的儲存格保持平行結構與相同單位。
- 欄數控制在五欄以內。過寬的表格在終端機與行動裝置上難以閱讀，改用小節呈現。
- 儲存格內避免放入多行段落。
### 15.4 連結
- 連結文字描述目標內容：`參閱[安裝指南](install.md)`。
- 不使用「這裡」「點此」「連結」「更多」作為連結文字。
- 同一份文件中，指向同一目標的連結使用相同文字。
### 15.5 程式碼區塊
- 一律標註語言：`bash`、`yaml`、`json`、`python`、`text`。
- 指令範例不包含提示符號，除非需要同時顯示輸出。
- 需要在程式碼區塊中展示含巢狀程式碼區塊的 Markdown 時，外層使用四個反引號。
- 範例中的敏感值使用明顯的佔位符，例如 `<YOUR_API_KEY>`，不使用看似真實的假值。
### 15.6 強調
- 粗體用於關鍵結論或需要被掃描到的詞。一段最多一處，整段標粗等於沒有重點。
- **中文避免使用斜體。** 多數中文字型沒有真正的義式字體，斜體是機械傾斜，可讀性差。需要強調時使用粗體。
- 不使用底線，容易與連結混淆。
- 不使用全大寫營造語氣。
---
## 16. 技術寫作
### 16.1 Requirement、Capability、Recommendation 必須區分
#### Requirement
> 系統**必須**支援 TLS 1.3。
#### Capability
> 系統**支援** TLS 1.3。
#### Recommendation
> 建議**使用** TLS 1.3。
#### Permission
> 管理員**可以啟用** TLS 1.3。
不要使用「可以」模糊上述四種語意；但「可以」作為 RFC 2119 MAY 的正式對應詞時例外，見 §4.5。
### 16.2 MUST / SHOULD / MAY
如果文件採用 RFC 2119 與 RFC 8174 的規範語意，明確定義：
- **MUST**：必要要求
- **MUST NOT**：禁止
- **SHOULD**：建議
- **SHOULD NOT**：不建議
- **MAY**：可選
首次出現時應定義其規範語意，並在整份文件中維持同一套詞彙。
中文對應：
| 英文 | 中文 |
|---|---|
| MUST / REQUIRED / SHALL | 必須 |
| MUST NOT / SHALL NOT | 不得 |
| SHOULD / RECOMMENDED | 應／建議 |
| SHOULD NOT / NOT RECOMMENDED | 不應／不建議 |
| MAY / OPTIONAL | 可以／可選 |
### 16.3 寫明前置條件與限制
技術文件常見的缺漏不是寫錯，而是沒寫。以下資訊若存在就必須寫出：
- 適用的版本、平台、環境
- 前置條件與相依套件
- 需要的權限
- 已知限制與不支援的情況
- 副作用與不可逆的操作
不佳：
> 執行 `reset-db.sh` 重建資料庫。
較佳：
> 執行 `reset-db.sh` 重建資料庫。
> **此操作會刪除所有現有資料，且無法復原。** 執行前請先備份，並確認具備 `db_admin` 權限。
---
## 17. 錯誤訊息
錯誤訊息應包含：
> **發生什麼事 → 為什麼 → 如何處理**
不佳：
> 發生錯誤，請重新操作。
較佳：
> 無法連線至資料庫。請確認 PostgreSQL 服務已啟動，並檢查 `DB_HOST` 與 `DB_PORT` 設定。
其他規則：
- 說明使用者能採取的下一步，而非只描述失敗。
- 不要責怪使用者：寫「找不到檔案 `config.yaml`」，不寫「你輸入了錯誤的檔名」。
- 不要在面向使用者的訊息中暴露堆疊追蹤或內部識別碼；需要時提供可查詢的錯誤代碼。
- 不使用驚嘆號。
---
## 18. 操作步驟
操作步驟使用命令式句型。
推薦：
```markdown
1. 停止服務。
2. 修改 `config.yaml`。
3. 將 `timeout` 設為 `30`。
4. 重新啟動服務。
5. 檢查日誌。
```
避免：
```markdown
1. 首先需要將服務停止下來。
2. 接下來可以對設定檔進行修改。
3. 然後需要將 timeout 的值設定成 30。
```
其他規則：
- 一個步驟只做一件事。
- 步驟開頭直接寫動作，不寫「首先」「接下來」「然後」。編號已經表達順序。
- 需要判斷時，把條件寫在步驟開頭：「如果服務未啟動，執行 `systemctl start app`。」
- 步驟結束後說明預期結果，讓讀者能確認是否成功。
---
## 19. 術語一致性
同一文件中，同一概念原則上只使用一個名稱。
例如不要混用：
- 使用者
- 用戶
- 用戶端使用者
- User
如果正式術語是：
> 使用者
後續就保持：
> 使用者
除非不同詞確實代表不同概念。
一致性也適用於：
- 中譯與原文的取捨（見 §12.1）
- 縮寫的使用時機
- 大小寫（`GitHub` 而非 `Github`）
- 產品名與版本標示方式
---
## 20. 語氣與稱謂
### 20.1 讀者稱謂只用一種
- 開發者文件：省略主詞，或使用「你」。
- 面向終端使用者的操作手冊：可使用「您」。
- **同一份文件不得混用「你」與「您」。**
### 20.2 步驟不逐句加「請」
不佳：
> 1. 請停止服務。
> 2. 請修改設定檔。
> 3. 請重新啟動服務。
較佳：
> 1. 停止服務。
> 2. 修改設定檔。
> 3. 重新啟動服務。
需要禮貌語氣時，在整體說明處使用一次即可。
### 20.3 描述系統行為使用第三人稱
> 系統會在啟動時讀取設定檔。
而不是：
> 我們會在啟動時讀取設定檔。
### 20.4 避免情緒性與預設立場的用語
避免：
- 很遺憾
- 不幸地
- 當然
- 顯然
- 眾所周知
- 只要簡單地
- 很容易就能
「顯然」「很簡單」對讀者可能不成立。這類用語在讀者卡關時會造成挫折感，且不提供任何資訊。
---
## 21. 避免的表達
### 21.1 行銷語言
技術文件避免沒有證據支持的形容：
- 業界領先
- 世界級
- 極致
- 革命性
- 超高效能
- 無與倫比
- 完美
- 最佳
改用可驗證資訊：
> 延遲低於 50 ms。
> 支援 10,000 個並行連線。
> 通過 ISO/IEC 27001 認證。
### 21.2 不必要的修飾詞
減少：
- 非常
- 相當
- 基本上
- 通常來說
- 在某種程度上
- 可以說
- 某種意義上
- 實際上
- 基本而言
例如：
> 基本上可以說這個方法是非常有效的。
改為：
> **此方法可降低查詢時間 40%。**
### 21.3 公文腔
以下表達通常可以直接刪除或改寫：
| 避免 | 優先 |
|---|---|
| 進行確認 | 確認 |
| 進行處理 | 處理 |
| 予以處理 | 處理 |
| 加以改善 | 改善 |
| 做出說明 | 說明 |
| 進行說明 | 說明 |
| 予以說明 | 說明 |
| 作為參考之用 | 供參考 |
| 以利於 | 以利 |
| 針對此問題進行處理 | 處理此問題 |
| 在此情況下 | 此時／因此 |
| 基於上述原因 | 因此 |
| 在目前的情況下 | 目前 |
| 於……之後 | ……後 |
| 於……之前 | ……前 |
### 21.4 AI 生成腔調
AI 產生的中文有一組固定特徵。這些句子語法正確，但不帶資訊，是本 Skill 最需要清除的對象。
**避免的開場：**
- 在當今快速發展的技術環境中
- 隨著科技的進步
- 眾所周知
- 在深入探討之前
**避免的收尾：**
- 總而言之
- 綜上所述
- 總的來說
- 希望本文能幫助你
- 讓我們一起打造更好的系統
**避免的插入語：**
- 值得注意的是
- 需要指出的是
- 不可否認的是
- 事實上
- 更重要的是
**避免的結構：**
- 每段開頭都用「首先／其次／再者／最後」，但內容沒有先後關係。
- 三項式排比堆疊：「不僅……而且……更……」。
- 為每個列表項加一句同義的解釋。
- 段落結尾重述段落開頭。
- 濫用粗體，整段都是重點等於沒有重點。
- 用破折號插入補充，這是英文寫作習慣的直接搬用（見 §14.5）。
判斷標準：
> **刪掉這句話之後，讀者會少知道什麼？如果答案是「沒有」，就刪掉。**
---
## 22. 不要過度精簡
簡潔不是：
> **越短越好。**
以下改寫是錯誤方向：
> 系統啟動後會讀取設定檔。
→
> 啟動讀設定。
這會降低可讀性。
正確目標：
> **刪除不必要的文字，但保留必要的語意。**
---
## 23. 修改流程
修改文字時，依序進行六個 Pass。**不要跳過順序**：結構沒調整就開始刪字，會刪掉後面才發現需要的內容。
### Pass 1 — Structure
檢查：
- 主題是否明確？
- 結論是否太晚？
- 段落是否各自處理單一主題？
- 順序是否合理？
### Pass 2 — Clarity
檢查：
- 主詞是否明確？
- 動作是否明確？
- 指涉是否明確？
- 修飾範圍是否有歧義？
### Pass 3 — Precision
檢查：
- 技術術語是否正確？
- 數字是否正確？
- Requirement / Capability 是否混淆？
- 是否加入無法證明的推論？
### Pass 4 — Concision
刪除：
- 贅字
- 重複
- 空泛形容詞
- 「進行」
- 不必要的「可以」
- 不必要的「相關」
- 不必要的「部分」
- AI 腔調（見 §21.4）
### Pass 5 — Consistency
檢查：
- 術語
- 稱謂
- 大小寫
- 中英文取捨
- 數字與單位
- 標點
- Markdown 格式
### Pass 6 — Naturalness
最後確認：
> **這是一段自然的台灣繁體中文，而不是「翻譯腔的英文」，也不是中國大陸用語。**
---
## 24. Before / After 範例
### Example 1 — 贅字
Before:
> 在目前的情況之下，系統基本上是可以正常進行運作的。
After:
> **目前系統正常運作。**
### Example 2 — 名詞化
Before:
> 我們需要進行系統設定的修改。
After:
> **需要修改系統設定。**
### Example 3 — 模糊
Before:
> 請確認相關設定是否正確。
After:
> **請確認 `config.yaml` 中的 `timeout` 是否設為 `30`。**
### Example 4 — 主動句
Before:
> 設定檔會在服務啟動時被系統讀取。
After:
> **服務啟動時會讀取設定檔。**
### Example 5 — 技術精確性
Before:
> 系統具有很高的效能。
After:
> **系統可處理每秒 5,000 個請求。**
### Example 6 — 平行結構
Before:
> 系統可以建立金鑰、修改金鑰以及金鑰的刪除。
After:
> **系統支援建立、修改與刪除金鑰。**
### Example 7 — 錯誤訊息
Before:
> 發生錯誤，請確認設定。
After:
> **無法建立 TLS 連線。請確認 `tls.enabled` 已啟用，並確認伺服器憑證有效。**
### Example 8 — 台灣用語
Before:
> 該項目使用內存緩存來優化數據庫查詢，默認配置下可以兼容多個客戶端。
After:
> **本專案使用記憶體快取最佳化資料庫查詢，預設設定可相容多個用戶端。**
### Example 9 — 修飾範圍歧義
Before:
> 清除過期的憑證與金鑰。
After（依實際語意擇一）：
> **清除過期的憑證與過期的金鑰。**
或：
> **清除過期的憑證，以及所有金鑰。**
### Example 10 — AI 腔調
Before:
> 在當今快速發展的技術環境中，快取扮演著至關重要的角色。值得注意的是，快取不僅能夠提升效能，而且能夠降低成本，更能夠改善使用者體驗。總而言之，快取是一項非常重要的技術。
After:
> **快取可降低資料庫負載。** 在目前的流量下，啟用快取後平均回應時間從 240 ms 降至 45 ms，資料庫 CPU 使用率從 70% 降至 25%。
### Example 11 — 條件語序
Before:
> 請重新產生憑證，如果憑證已經過期或即將在 30 天內到期的話。
After:
> **如果憑證已過期，或將在 30 天內到期，請重新產生憑證。**
### Example 12 — 中英文混排與標點
Before:
> 使用Python3.12開發,並支援Windows11與Linux(kernel 5.15以上).
After:
> **使用 Python 3.12 開發，並支援 Windows 11 與 Linux（kernel 5.15 以上）。**
---
## 25. AI Agent 行為規則
當 Agent 編輯繁體中文時：
### MUST
1. 保留原文的技術事實。
2. 保留數字、版本、API 名稱、檔名及程式碼語意。
3. 保持術語一致。
4. 優先修正歧義。
5. 優先刪除沒有資訊價值的文字。
6. 使用自然的台灣繁體中文。
7. 使用台灣慣用術語（見 §11）。
### SHOULD
1. 使用主動句。
2. 使用具體動詞。
3. 使用具體名詞。
4. 段首先說重點。
5. 使用平行結構。
6. 將相關詞放在一起。
7. 使用適當的 Markdown 結構。
8. 條件在前，結論在後。
9. 不確定時標示不確定，而非省略。
### SHOULD NOT
1. 過度使用「進行」。
2. 過度使用「相關」。
3. 過度使用「可以」。
4. 過度使用「我們」。
5. 使用空泛形容詞。
6. 為了看起來正式而增加冗長語句。
7. 將英文句法直接套入中文。
8. 為了簡潔而犧牲精確性。
9. 使用 AI 生成腔調（見 §21.4）。
### MUST NOT
1. 改變技術事實。
2. 改變 requirement 的強度。
3. 將 SHOULD 改成 MUST。
4. 將 MAY 改成 SHOULD。
5. 將禁止改成建議。
6. 捏造數據。
7. 捏造引用。
8. 修改 API、函式、變數、檔名或標準名稱的拼寫。
9. 使用簡體字。
10. 使用中國大陸慣用術語。
11. 把程式碼中的半形標點改成全形標點。
12. 不因追求簡潔而刪除必要條件。
13. 不擅自增加原文沒有的事實。
### 外部工具（若可用）
- 本節規則由 Agent 自行判斷語意；若執行環境另外提供 [`zhtw`](https://github.com/sysprog21/zhtw-mcp) MCP 工具，可將其作為機械檢查的補充：
+ 本節規則由 Agent 自行判斷語意；若執行環境另外提供 [`zhtw-mcp`](https://github.com/sysprog21/zhtw-mcp) MCP 工具，可將其作為機械檢查的補充：
- - 完成 §23 六個 Pass 後、輸出前，呼叫 `zhtw` 對最終文字做一次檢查，涵蓋標點、字形、中國大陸用語等規則可窮舉的項目。
- - `zhtw` 回報的標點、字形與用詞問題屬機械檢查，行文部分直接依其建議修正，不需要重新以語意判斷覆核。
- - 行內程式碼、程式碼區塊、API 與識別名稱不套用 `zhtw` 的建議：§14.6 與本節 MUST NOT 第 8、11 項優先，沒有例外。
- - `zhtw` 不能取代本文件：結構、清楚、簡潔、語氣等語意層面的判斷仍以本文件其他各節為準，`zhtw` 只補強規則可窮舉的部分。
- - 環境未提供 `zhtw` 時略過此步驟，直接依 §26 檢查清單輸出。`zhtw` 是加強，不是本 Skill 運作的前提。
+ - 完成 §23 六個 Pass 後、輸出前，呼叫 `zhtw-mcp` 對最終文字做一次檢查，涵蓋標點、字形、中國大陸用語等規則可窮舉的項目。
+ - `zhtw-mcp` 回報的標點、字形與用詞問題屬機械檢查，行文部分直接依其建議修正，不需要重新以語意判斷覆核。
+ - 行內程式碼、程式碼區塊、API 與識別名稱不套用 `zhtw-mcp` 的建議：§14.6 與本節 MUST NOT 第 8、11 項優先，沒有例外。
+ - `zhtw-mcp` 不能取代本文件：結構、清楚、簡潔、語氣等語意層面的判斷仍以本文件其他各節為準，`zhtw-mcp` 只補強規則可窮舉的部分。
+ - 環境未提供 `zhtw-mcp` 時略過此步驟，直接依 §26 檢查清單輸出。`zhtw-mcp` 是加強，不是本 Skill 運作的前提。
---
## 26. 最終檢查清單
在輸出前，Agent 應檢查：
```text
結構
[ ] 是否先說明主要結論？
[ ] 每個段落是否只有一個主要主題？
[ ] 每句是否有清楚的主要意念？
清楚
[ ] 主詞是否明確？
[ ] 是否存在模糊代詞？
[ ] 修飾範圍是否有歧義？
[ ] 平行概念是否使用平行結構？
精確
[ ] 是否保留所有必要技術資訊？
[ ] 是否改變了原文的規範強度？
[ ] 是否能用具體數字取代模糊描述？
[ ] 推測是否被寫成事實？
簡潔
[ ] 是否有不必要的「進行」？
[ ] 是否有不必要的「相關」？
[ ] 是否有不必要的「可以」？
[ ] 是否有不必要的「我們」？
[ ] 是否有不必要的形容詞？
[ ] 是否有 AI 腔調的開場、收尾或插入語？
台灣繁體中文
[ ] 是否有簡體字？
[ ] 是否有中國大陸用語？
[ ] 同形異義詞是否用對（文件／檔案、質量／品質、項目／專案）？
[ ] 是否讀起來像自然的台灣中文，而非英文直譯？
格式
[ ] 技術術語是否一致？
[ ] 讀者稱謂是否一致？
[ ] 數字與單位格式是否一致？
[ ] 中英文之間空格是否正確？
[ ] 標點是否為全形，程式碼是否為半形？
[ ] 列表結尾標點是否一致？
[ ] Markdown 結構是否正確？
外部工具
- [ ] 若環境提供 zhtw MCP 工具，是否已呼叫 zhtw 做機械檢查（標點、字形、中國大陸用語）？
+ [ ] 若環境提供 zhtw-mcp MCP 工具，是否已呼叫 zhtw-mcp 做機械檢查（標點、字形、中國大陸用語）？
```
---
## 27. 規則衝突優先順序
當規則互相衝突時，依以下優先順序處理：
```text
Technical correctness
>
Semantic accuracy
>
Clarity
>
Consistency
>
Concision
>
Elegance
```
也就是：
> **正確比簡短重要，清楚比漂亮重要。**
例如：
> 「系統不得匯出私鑰」
不能為了簡潔改成：
> 「禁止匯出」
因為後者失去了「誰／什麼」的明確語意。
---
## 28. 一分鐘版本
如果 Agent 只需要記住最重要的規則：
```text
台灣繁體中文寫作：
1. 先說重點。
2. 一段一主題。
3. 一句一主要意念。
4. 使用明確主詞。
5. 使用具體動詞。
6. 能用動詞，不用「進行＋名詞」。
7. 刪除不增加資訊的文字。
8. 避免「相關、部分、可以、我們」等空泛用語。
9. 主動句優先，但不要禁止合理的被動句。
10. 使用具體、可驗證的資訊取代空泛形容。
11. 平行概念使用平行結構。
12. 相關詞放在一起，消除修飾範圍的歧義。
13. 條件在前，結論在後。
14. 使用台灣用語，不使用中國大陸用語與簡體字。
15. 中英文之間加空格；中文用全形標點，程式碼用半形標點。
16. 技術術語與讀者稱謂保持一致。
17. Requirement、Capability、Recommendation 不可混淆。
18. 不改變原文技術事實或規範強度。
19. 不把英文句法直接翻成中文。
20. 刪除 AI 腔調：空泛開場、空泛收尾、「值得注意的是」。
21. 清楚優先於簡潔。
22. 簡潔優先於華麗。
```
---
## 29. 設計原則
本 Skill 不要求文字「看起來像英文」。
它的目標是：
> **用最少的必要文字，讓讀者以最低的認知成本，正確理解作者想表達的內容。**
因此，真正的成功標準不是「刪了多少字」，而是：
> **每一個留下來的字，都有理由存在。**