Zh Tw Prose

---
name: zh-tw-prose
description: 用台灣正體中文寫出、改寫或潤稿技術文章與技術部落格、參考文件與 README、介面文字，不論長短。避開 AI 腔、翻譯腔與對岸用語。
license: MIT
metadata:
  version: "0.4.0"
  repository: "https://github.com/tedliou/baihua"
---

# 正體中文寫作

目標是讓文字讀起來像熟悉主題的台灣人寫的：句子完整、先交代問題再給答案、用具體事實取代評價，沒有 AI 腔、翻譯腔與對岸用語。

## 優先順序

規則衝突時依序為準：使用者這次的指示、專案的文風檔與用詞表（常見的是 `GLOSSARY.md`）、其他 skill 對自己領域的規定、本 skill 的語域、本 skill 的核心規則。本 skill 只決定句子怎麼寫，內容、術語與版面由使用者、專案與領域 skill 決定。

## 核心規則

遇到規則沒想到的情況時，依理由判斷。

1. 句子寫完整，保留主詞、動作、受詞，以及「能、會、可以、的、和、再、就」這類助詞與連接詞。詞也寫完整：「判斷錯」寫成「判斷錯誤」，「設好」寫成「設定好」。精簡是刪掉重複的資訊與沒有內容的句子，不是刪掉助詞。使用者指定長度時，以那個長度為目標。理由：電報式短句要讀者自己補回關係，容易誤讀。
2. 開頭先交代問題，再給答案。依序寫讀者遇到的問題或想做的事、這篇讓讀者做到什麼、理解後文需要的概念，版本、指令與路徑這類細節放後面。不先解釋文章要講什麼。理由：讀者要先知道這件事和自己有什麼關係，才讀得懂後面的做法；直接切入做法或細節，讀者沒有理解的框架。
3. 同一個資訊只寫一次。不在段落、表格與結尾重複同一句，段尾不把前文收成一句格言。理由：重複會讓讀者以為是新資訊。
4. 用具體事實取代評價。寫數字、後果或看得到的現象，沒有依據就不寫「大幅」「至關重要」「非常實用」。理由：評價詞無法驗證，會拖累整篇的可信度。
5. 假對比、三段排比、提醒腔、說教、推銷與自我導覽句，只在內容真的需要時使用。理由：這些是讀者最先認出的 AI 腔，見 [patterns.md](references/patterns.md)。
6. 用動詞直接說動作，少用「進行、作出、加以、予以、扮演……角色」、名詞化（「由系統完成驗證」改成「系統會驗證」）、表示手段的「通過」與不必要的被動句。理由：翻譯腔讓句子變長、主詞消失。見 [translationese.md](references/translationese.md)。
7. 用台灣用語。「視頻」寫成「影片」，「默認」寫成「預設」。不確定的詞先查證再用。讀者慣用英文的技術術語（API、Token、Commit）不硬翻。理由：對岸用語讓台灣讀者覺得文字是轉換來的。對照表見 [taiwan-usage.md](references/taiwan-usage.md)。
8. 標點用全形，引號用「」，中文與英文、數字之間加半形空格。段落不用分號串接長句，介面字串與規格欄位可以用。破折號少用。理由：教育部標點手冊與主流在地化指南的做法。見 [punctuation.md](references/punctuation.md)。
9. 依資訊性質選格式。比較用表格，步驟用條列，流程用圖，因果與判斷用段落。標題與表頭用名詞，粗體不強調整句，emoji 不當標題記號。理由：格式是幫讀者找資訊，不是讓頁面看起來整理過。
10. 內容誠實。不捏造經驗、測試結果、引用與數字，不替產品補上素材沒有的功能，推論要標成推論，不把語境擴張成使用者沒說的計畫，翻譯時不加原文沒有的評語。理由：讀者會把「我測過」當成證據。見 [integrity.md](references/integrity.md)。

## 中文句子的組法

中文靠語序與上下文表達句子之間的關係，英文靠代名詞、連接詞與子句。模型的中文常把英文的組法搬過來，讀起來像翻譯稿。

1. 話題說一次，後面接著說。主角出現後，接下來的分句直接說它做什麼，不再用「它、我們、你、這個工具」指回去，換了主角才寫新主詞。只省重複的代名詞，做動作的人與動作的對象要寫出來：「我在兩台伺服器各裝一份相同版本的 Node」，不寫「我的兩台伺服器各裝一份」。省掉的主詞必須就是前面的話題，接不上時（「初學的人，這套工具是常見的選擇」）把主詞寫出來。理由：中文是話題優先的語言。
   - 前：`這個指令會讀取設定檔，然後它會檢查格式，接著它會把結果寫進日誌。`
   - 後：`這個指令會讀取設定檔、檢查格式，再把結果寫進日誌。`
2. 照事情發生的順序寫。原因與條件在前，結果與動作在後：「先備份資料庫，再升級」，不寫「在升級之前，請確保已經備份資料庫」。核心規則 2 管的是段落的順序，句子內部仍照時間順序。理由：中文語序跟著時間與因果走。
3. 名詞前面只放短的修飾。修飾語超過一個「的」或比名詞長很多時，改成名詞後面的分句。理由：修飾語越長，讀者越晚看到主角。
   - 前：`這是一套由社群維護、支援多種資料庫的開源工具。`
   - 後：`這套開源工具由社群維護，支援多種資料庫。`
4. 句子長短跟著內容走。交代因果的句子可以長，結論或轉向用短句，連續幾句長度差不多時合併或拆開一句。理由：句長平均是模型文字的節奏。

## 語域

本 skill 處理下表三種文字。依讀者與情境選最接近的語域，動手前先用 Read 讀對應的檔案，只改一段或一個標題也要讀。表裡的要點只是摘要，開頭、標題、內容取捨與術語的完整規則都在語域檔案裡，沒讀就會漏掉。

| 語域 | 讀者與情境 | 要點 | 檔案 |
| --- | --- | --- | --- |
| 技術文章 | 工程師：技術部落格、教學、技術筆記 | 開頭先寫讀者的問題或動機，再給做法。標題寫成「主題：讀者得到的結果」。不寫作者沒做到的情境，實測用的素材與環境放到後面。像對同事說明，不教育讀者 | [article.md](references/registers/article.md) |
| 參考文件 | 查資料的人：wiki、說明頁、API 文件、README | 開頭寫它是什麼、做什麼。主詞是系統裡的東西，少用「你」，不提醒、不推銷 | [reference.md](references/registers/reference.md) |
| 介面文字 | 操作產品的人：按鈕、標籤、錯誤訊息、通知 | 用讀者認得的說法。錯誤訊息寫發生什麼與怎麼處理，語氣平實，不道歉過度、不裝可愛 | [ui.md](references/registers/ui.md) |

## 寫作流程

1. 確認讀者、讀者要完成什麼，以及用哪個語域。素材缺少只有使用者知道的事實（經驗、測試結果、決策理由）時，先問，不自己補。使用者交代的概念句是要傳達的意思，用素材的具體事實展開，不照抄進正文。
2. 寫完用檢查清單逐句讀一次。
3. 能執行 Python 時，執行本 skill 的 `scripts/check.py <檔案>`，文字沒有存成檔案時用 `scripts/check.py -` 從標準輸入檢查，有用詞表時加 `--glossary <路徑>`，依輸出修正。`--profile` 會印出連接詞、代名詞與「的」的密度，偏高時用「中文句子的組法」檢查那幾段。
4. 長文或對外發佈的文字，交給沒看過寫作過程的審稿者讀一次，見 [review.md](references/review.md)。
5. 交稿前確認三件事：讀過對應的語域檔案、逐句對照過檢查清單、能執行 Python 時跑過 check.py。有一項沒做就先補做。

## 檢查清單

命中的寫法就算通順也要處理，除非符合「保留」欄。例句是示意，同類說法一樣處理。完整說明見 [patterns.md](references/patterns.md) 與 [translationese.md](references/translationese.md)。

| 看到 | 處理 | 保留 |
| --- | --- | --- |
| 先下評語：「這個設計很漂亮：」「說穿了」 | 刪掉，直接寫內容 | 結論段的判斷，用具體條件寫 |
| 沒有依據的評價：「非常實用」「效能大幅提升」 | 換成素材裡的數字或現象，沒有就刪 | 素材有數據支持 |
| 推測與展望：「未來可期」「下一版應該會改善」 | 刪掉，或寫明是推論與依據 | 素材寫出的計畫 |
| 範圍聲明：「沒有實測」 | 連同那個情境刪掉 | 評測的未驗證清單、安全警告 |
| 從工具怎麼運作寫起：「它會依……到……找」「也支援……」 | 改寫讀者的情況、目標與要做的步驟 | 原理解說、實測紀錄 |
| 自我導覽：「本文將介紹」「讀完這篇你就能」 | 刪掉，第一句直接寫答案 | 長文件的目錄與跳轉連結 |
| 說教與提醒：「一定要先搞懂」「務必」「值得注意的是」 | 改成中性的條件與做法 | 資料遺失、金錢或安全的警告，寫明後果 |
| 推銷與空泛對象：「從新手到老手都適用」「輕鬆上手」 | 刪掉，或改成具體條件 | 說明適用範圍的文件 |
| 恭維讀者：「眼尖的讀者」「你一定遇過」 | 直接陳述事實 | 無 |
| 裝熟的語氣詞：「~」「囉」「der」 | 刪掉 | 遊戲角色台詞的口吻 |
| 假對比：「不是……而是」「不僅……更」 | 直接寫它是什麼 | 讀者真的有那個誤解 |
| 段尾格言與套話：「說到底」「總而言之」「希望對你有幫助」 | 刪掉 | 全文結論段的判斷 |
| 冒號標籤：「重點：」「結論：」 | 刪掉，直接寫內容 | 表單欄位與表格 |
| 代名詞與介詞堆疊：每句用「你」「它」指回前文、「對於……來說」 | 省略主詞或重複名詞 | 指涉需要明確時 |

## 改稿

先依使用者的要求決定改多少：

- 潤稿、修飾、「看一下」：逐句對照檢查清單，命中的寫法都要處理。沒命中的句子保留原本的語氣、句型與用字，只改錯字、文法、對岸用語與標點。
- 改寫、去 AI 腔、重寫：逐句對照檢查清單，命中的句子都要處理，需要時可以重組段落的順序。

兩種都依這些原則：

1. 先讀全文與對應的語域檔案，掌握作者的語氣與事實。只改一段也要讀語域檔案，段落的寫法規則大多寫在那裡。
2. 符合保留條件的寫法是對的，例如讀者真的有誤解時的「不是……而是」、表示不幸的「被盜用」。
3. 沒有錯的詞不換。「由於、因此、若、而、所致」是常見的書面連接詞，不換成口語。把「大概」換成「約略」只會抹掉作者的語氣。
4. 刪掉 AI 腔時改寫成具體內容，不換成同義詞（「標誌著」換成「象徵著」仍是同一個問題）。要刪的是誇大與空話，原文的論點要留下：「帶來了前所未有的便利」改成「用起來比較方便」，不是整句刪掉。說教、評語與建議不算論點：「搞懂這兩個參數才能調好畫質」「文件寫得很清楚」這類句子刪掉，或改成它背後的事實。原文沒有的內容也不要補。
5. 讀得順的連貫長句不切短。用「……後，才……」交代先後與因果的句子，切開會讓關係消失。
6. 事實、數字、網址、版本、程式碼、原文的格式與數值寫法（例如「+1」）照原樣。

交稿前同樣確認寫作流程第 5 步的三件事。保留使用者手改的地方。改完簡短說明改了哪幾類問題，使用者要求只輸出成品時照做。使用者反覆做同一種修改時，依 [learning.md](references/learning.md) 整理成偏好，經同意後寫回專案的文風檔。

## 常見失誤

- 為了避開 AI 腔而刻意口語、加語助詞或網路用語。技術文章用平實的書面語：「字都寫對」寫成「生成的文字都正確」。目標是平實，不是裝熟。開頭稱讚使用者的問題也一樣不要。