讓 AI 寫出自然日語的技巧

語法正確，但讀起來很累。看到一半就想睡。第一行就讓人意識到「啊，這是 AI 寫的」。

讓 AI 寫出自然的中文（或日文）所帶來的獨特違和感，至今仍是許多人的挑戰。很多人透過實驗，發展出了各種技能和系統來解決這種不適感。

在這篇文章中，我整理了透過日常寫作與社群成果驗證過的實用洞察，並從以下四個角度進行歸納：

• 模型選擇：為什麼選對模型比優化框架（harness）更重要
• 推薦寫作流程：五個步驟，降低讀者認知負荷並創造句子節奏
• 推薦技能：前輩們開發的必備工具，用於控制句長並防止讀者迷失方向
• 實際寫作環境：克服「規則加越多，AI 味越重」這道牆的倉庫結構

首先，我想明確指出，「模型選擇」的效果遠勝於提示詞（prompts）或鉤子（hooks/harnesses）。

截至 2026 年，在中文寫作方面，Gemini 3.8 Flash 遙領群雄，其次是 Kimi K3。Claude 過去曾因文筆自然而備受讚譽，但因專精於程式碼生成，其文字風格已變得明顯生硬且棱角分明。ChatGPT 則表現平平，段落長度過於均勻、結構像教科書，留下了最明顯的 AI 痕跡。

然而，僅依賴模型的原始輸出會導致句子節奏單一化，並將認知負擔轉嫁給讀者。我們需要流程和系統來發揮模型固有的優勢。

推薦寫作流程

整合當前的知識，我們現在應該採取的寫作流程可以歸納為這五個步驟。

1[步驟 1] 資訊篩選與刪減（捨棄不必要的體貼）
2   ↓
3[步驟 2] 設計讀者的心智地圖（全局順序與連結）
4   ↓
5[步驟 3] 設計語調與變化（刻意分配熱度）
6   ↓
7[步驟 4] 分離寫作與機械檢查（透過 PostToolUse Hook 拒絕不合格內容）
8   ↓
9[步驟 5] 人類潤飾最後的 10%（記錄差異以回饋至規則中）

步驟 1. 寫作前的資訊篩選與「刪減」

AI 文本難以閱讀的最大原因是「轉嫁認知負荷」（Tsubota-san / @tsubotax）。它將前提、補充說明和預防性的安撫塞進單一句子裡。鐵律是：在讓 AI 開始寫作之前，先刪減那些不屬於「對方下一步該做什麼」的資訊。

• 在前兩行確定「這是寫給誰看的，以及需要做出什麼決定」
• 每個段落只賦予一個角色，例如「選項差異」、「決策材料」或「驗證方法」，並刪除不符合任何角色的段落
• 移除所有若刪除也不影響決策的括號內補充說明

步驟 2. 不破壞讀者「心智地圖」的全局設計

正如 Keiichiro Shikano (@golden_lucky) 所指出的，文本崩潰源於「讀到後面才清楚意圖的伏擊」或「與前一段缺乏連結」。請準備好路徑，以免讀者迷路。

• 首次引入概念時，安排順序讓讀者僅依序閱讀即可辨識類型與角色
• 在引入新資訊前，先在讀者心中預留接收它的空間
• 標題後務必緊接一句與前一段落相連的句子

步驟 3. 刻意嵌入「偏差（變化）」

AI 傾向以相同的溫度討論所有話題，但人情味的本質在於「偏差」（Natsu-san / @art_reflection）。對有趣的話題喋喋不休，對前提則一句帶過。在結構階段刻意分配熱度強度。

步驟 4. 分離寫作與機械檢查

你在提示詞中列出的禁令越多，模型就越縮手縮腳、句子越短。讓它自由書寫，然後在檔案輸出後立即透過 Hook 進行機械檢查。若發現違規，不要只是替換單字——要求它重寫包含問題的整個句子。 分離寫作與檢查是維持節奏的關鍵。

步驟 5. 人類潤飾最後的 10%

不要指望單靠 AI 就能拿到 100 分。將 90% 的骨架交給 AI，由人類調整剩餘 10% 的呼吸感與質感。記錄修正內容，並將其回饋至未來的提示詞或檢查規則中。

推薦技能

我也介紹一些源自社群、能提升中文文件品質的必備工具和技能，這些是我目前自己也在使用的。

natural-japanese (@techtalkjp**

一項基於「AI 味更多體現在節奏而非詞彙」這一洞察而誕生的 Agent Skill (GitHub Repo / 說明文章)。它基於人類與 AI 文本的測量語料庫，機械式地偵測句長的變化（burstiness），拋棄了如「名詞結尾不足」或「句首重複較少」等傳統假設。

https://x.com/techtalkjp/status/2076808889371443679

japanese-tech-writing (@golden_lucky**

一項從商業書籍編輯視角轉化為提示詞的技能 (Gist / 部落格文章)。它消除了 LLM 那種沒有增加論點卻誇張立場的語氣，例如 handle directly、dig deeper 或 nothing less than ~，並規範順序與主語位置，讓讀者能依序理解。

https://x.com/golden_lucky/status/2066751852088336698

Hooks × lint with good patterns (@yugen_matuni**

一個利用 AI 編碼工具 Hook 功能（PostToolUse）在檔案寫入後立即進行檢查的系統。對於 NG 表達方式，它不僅標記問題，還提供具體的修正模式（good），例如「真正的價值在於～」，並促使重寫整個句子。

https://x.com/yugen_matuni/status/2088251220452679951

我的寫作環境

在我的寫作專案中，我曾經歷過「規則加得越多，句子越縮水，AI 味反而回來了」的失敗。 添加慣例會讓 AI 退縮到安全、簡短的句式。

由此，我得出了一個設計原則：「不是減少規則，而是分離規則的位置。」

1[整體寫作流程]
2
3[輸入] style-guide / voice-samples / edit-patterns (僅限判斷標準)
4     ↓
5[執行寫作] writer (Gemini 3.8 Flash)
6     ↓
7[自動檢查] PostToolUse Hook (透過 detect-ai-smell.js 拒絕不合格內容)
8     ↓
9[品質評估] reviewer (基於 rubric.md 的客觀評估)
10     ↓
11[最終潤飾] 人工調整與發布 (將差異回饋至規則)

1kgsi-note-documents_v2/
2├── CLAUDE.md              # 操作政策、寫作模式、Agent 權限
3├── GOVERNANCE.md          # 參考資料的大小限制、三個儲存位置
4├── style-guide.md         # Kogiso 的寫作風格（僅限判斷描述，最多 4,500 字）
5├── references/
6│   ├── voice-samples.md   # 風格樣本（按功能分類的段落摘錄）
7│   ├── edit-patterns.md   # 人工修正帳本（修改前→修改後）
8│   └── rubric.md          # Reviewer 評估標準（距離基準）
9├── human-bench/           # 5 篇過去人類撰寫的文章（writer 不讀取；機器檢查的門檻）
10├── scripts/
11│   ├── detect-ai-smell.js # 機器檢查閘門（regex、密度檢查，含 'good' 模式）
12│   ├── clean-japanese-spacing.js # 自動移除中日文與西文之間的半形空格
13│   └── hooks/             # PostToolUse Hooks 等腳本
14├── editor/                # 本地筆記風格預覽與修訂編輯器
15└── note/                  # 文章正文（最終草稿）

這是我自訂本地編輯器（note-editor）的畫面。左側的編輯會即時反映在中間等同於 Note 製作的預覽上，右側面板則可對選定範圍進行部分 AI 修訂。

自訂編輯器。透過 /note-editor 指令啟動

三個儲存位置與權限分離

1. 內化層（writer 讀取）：style-guide.md、voice-samples.md。僅薄薄地描述 writer 的判斷標準（最多 4,500 字）。
2. 機器層（Hook 自動掃描）：scripts/detect-ai-smell.js。無字數限制。匯總可用 regex 偵測的禁令與修正策略（good）。
3. 判斷層（reviewer 讀取）：references/rubric.md。由獨立的 Agent 評估完成稿與目標之間的差距。

為了防止膨脹，當指南超過限制的 80% 時，我們會刪除與新增規則數量相當的舊規則。

實際檔案摘錄

以下是從實際運作中的檔案摘錄的核心部分。

`GOVERNANCE.md`（位置與限制管理原則）

1如果 writer 和 reviewer 讀取的資料膨脹，句子會試圖遵循規則而縮水，AI 味就會回來。
2在此環境中，原則是「規則不是被減少，而是被重新安置」，並為每個位置設定限制。
3
4[三個儲存位置]
5- 內化層（writer 讀取）：style-guide.md, voice-samples.md, edit-patterns.md
6  → 保持精簡。僅限判斷描述。不要清單化
7- 機器層（Hook 自動掃描）：scripts/detect-ai-smell.js 中的檢查項目
8  → 無限制。所有可用 regex 撰寫的禁令都放在這裡
9- 判斷層（reviewer 讀取）：references/rubric.md, references/voice-samples.md
10  → 距離標準為摘錄。僅在混亂時每種類型保留一個範本

`scripts/detect-ai-smell.js`（機器檢查與 'good' 對比）

1// detect-ai-smell.js 摘錄
2const CHECKS = [
3  {
4    name: "迴避性表達 / 模稜兩可的態度",
5    patterns: [/一概來說|優點和缺點都有|各有利弊|視情況而定|可以說|認為可能/g],
6    limit: 1,
7    gate: true,
8    good: "選邊站並堅定陳述，隨後立即放上一句證據。不要用呈現雙方觀點來收尾",
9  },
10  {
11    name: "預告式開場白『重要的是...』",
12    patterns: [/重要的是|關鍵在於/g],
13    limit: 1,
14    gate: true,
15    good: "直接寫出內容而不做預告。『重要的是 X』→『X 是。因為～』",
16  },
17  {
18    name: "抽象對比的招牌",
19    patterns: [/這樣的構圖|設計思考/g],
20    limit: 1,
21    gate: true,
22    good: "將對比寫成誰做了什麼的動作。『A 和 B 的結構』→『A 做～。B 不做～』",
23  },
24];

`style-guide.md`（給 writer 的前提指示）

1這份指南不是檢查清單。如果你在寫作時問自己「我有違反規則嗎？」，AI 味就會回來。
2當我寫文章時，這些作為內化的前提運作。
3
4開始前，請口頭化以下幾點：
51. 我現在是以誰的身份寫作（例如：實際接觸 AI 的設計者）
62. 我要寫關於什麼反應（期待 → 現實 → 落差）
73. 我將如何收尾（留下未解的問題或斷言立場並總結）
84. 語調設計。哪些章節要強調，哪些要一句帶過

結論

無論框架多麼精緻、選擇的模型多麼優秀，如果人類寫作者內部沒有「原始的具體性」，文本就無法站立。

AI 吐出陳腔濫調，是因為人類沒有提供「他們經歷了什麼、感覺哪裡不對」這類素材。抽象的指令只會產生抽象的套話。

「當我實際觸碰時，發現比預期簡單，令人失望」

「深夜 PR 通過時，我感到一絲釋然」

只有當存在著血肉般的觀察、數字和專有名詞的种子時，Gemini 3.8 Flash 的表現力和基於 Hook 的自動檢查才能真正發光。

AI 寫作不是偷懶的自動化，而是一項編輯嘗試，旨在將你自己的不適感高效地傳遞給讀者。試著從審視你剛寫下的那一行開始吧。

註：這篇文章本身是基於文中所述的寫作環境撰寫的。