中文去 AI 味寫作指南

去除中文寫作中的 AI 腔調，讓文本像人寫的而非模型生成的。覆蓋博客、技術文檔、推文、發行說明、科學論文等場景。觸發詞：去 AI 味、改寫、潤色、審稿、翻譯腔重、像人寫的、自然一點。

一、核心原則

1. 自然 > 風格化

最高優先級：讀起來自然，而非讀起來像「努力裝人」。

不要爲了去 AI 味而硬塞口語詞（「說白了」「居然」「誰能想到」「太太太」）
不要爲「更像人」把技術文改得像口播稿
如果原句已經自然、準確、清楚，不改

2. 減法優先

去 AI 味是做減法，不是做加法：

先刪：解釋腔、總結腔、多餘轉折、套話填充
再調：句式節奏、標點、用詞口語化程度
不改：代碼字面量、URL、API 路徑、JSON 鍵名、數據庫字段名

3. 保語義 > 去 AI 味

先確認事實、邏輯、因果不變。爲「更口語」改壞原意 = 失敗改寫。

4. 場景決定策略

不同寫作目標有不同標準：

技術文檔：剋制、準確、可掃讀，不用第二人稱
博客/技術長文：自然穩重的工程師口吻，不做報告腔也不做口播腔
社交媒體：有性格，有立場，不列功能清單
發行說明：一句話說用戶效果，條目密度匹配項目風格
科學論文：保持學術正式度但不用空洞套話

二、速查清單（寫完後過一遍）

段末有「這說明」「可以看出」「到這裏」開頭的收尾總結句？→ 刪
有「不是...而是...」對比句式？→ 只說結論
有「隨着...的發展」「在當今...時代」開篇套話？→ 刪
有「賦能」「抓手」「閉環」「拉通」「沉澱」等黑話？→ 替換
用了破折號（—）？→ 逗號或句號替代
有四五個短句連發像打電報？→ 合併或變節奏
章節間有「上面這些講的是...下面我們看...」過渡句？→ 刪
中文和英文/數字之間沒加空格？→ 加
用了「非常」「極其」「值得注意的是」「綜上所述」「例如」？→ 換成「很」「比如」
有昇華句（把技術觀察上升到人生道理）？→ 刪
用了第二人稱「你」「您」？→ 技術文檔應避免；博客可酌情
有「一句話總結」「簡而言之」等總結標籤？→ 直接說結論
無生命事物做了人類動詞（「決策浮現」「數據告訴我們」）？→ 命名真人
濫用三連排比？→ 換二連或一連
自問自答？→ 直接陳述
每個列表項都是 bold 關鍵詞開頭？→ 換格式

三、中文 AI 味模式

3.1 段末收尾總結句（最高頻，優先檢查）

一段剛解釋完某機制，結尾再重述一遍。

信號詞：這說明 / 到這裏 / 可以看出 / 這本身就是 / 通過以上分析 / 由此可見

❌ 「到這裏，我們已經看到了內存分配器在 allocation 路徑上的三個關鍵優化點。」 ✅ 直接刪掉，上一句已經說完。

3.2 昇華句

把具體工程觀察上升到普適人生道理。

❌ 「這其實和產品設計一樣：好的抽象不是爲了炫技，而是爲了讓使用者少犯錯。」 ✅ 直接給具體建議：「所以設計抽象時，先用調用方的視角寫一遍調用代碼，再決定接口長什麼樣。」

3.3 對比句式（「不是...而是...」）—— 硬約束

禁止用否定式對比結構。任何形式的「不是 X，而是 Y」「不是 X，是 Y」「X 本身沒有價值，真正有用的是 Y」「X 已經不是瓶頸，Y 纔是」全部重寫。

❌ 「真正的創新者不是有創意的人，而是五種特質同時拉滿的人。」 ✅ 「真正的創新者是五種特質同時拉滿的人。」

❌ 「這更像創始人篩選框架，不是交易信號。」 ✅ 「這是一個創始人篩選框架。」

❌ 「性能瓶頸已經不是 I/O，而是鎖競爭。」 ✅ 「鎖競爭現在是主要性能瓶頸。」

3.4 講解腔 / 訓人感起手

❌ 「真拆開看...」「這背後是同一個變化...」「真正關鍵的問題是...」 ❌ 「先問問是不是」「你要先明白」 ✅ 直接說。「先確認...」「可以先看...」

3.5 總結腔標籤

不要在結尾前加總結標籤。

❌ 一句話總結 / 簡而言之 / 概括來說 / 總而言之 / 綜上所述 / 總結一下 ❌ 一句話落地 / 一句話講 / 一句話概括 ✅ 直接給 punchline，不加標籤。

3.6 文章開篇套話

❌ 「隨着 AI 技術的不斷發展...」 ❌ 「在當今數字化浪潮中...」 ❌ 「近年來，XXX 受到了越來越多的關注...」 ✅ 直接開頭。「用了不到一個月後...」「先說結論...」「這次想把 X 這條鏈路講清楚...」

3.7 中文黑話 / 互聯網黑話

以下詞默認不用（除非引用原文或行業固定術語）：

絕對禁用：賦能、抓手、閉環、沉澱、對齊、對標、拉通、打通、協同、聯動、洞察、賽道、心智、調性、戰役、鏈路、勢能、兜底
謹慎使用：場景、生態、體系、路徑、觸點、卡點、佈局、矩陣、顆粒度、覆盤、梳理、輸出、提煉

❌ 「通過數據沉澱賦能業務閉環」 ✅ 「積累數據後，業務能形成完整流程」

額外警惕：

過度強調重要性：對普通主題用「至關重要」「意義重大」「關鍵時刻」「轉折點」→ 刪
過度列舉來源：「依據多家媒體報道...」「顯示其於產業中具一定能見度」→ 刪
表面分析附加：用分詞短語附加空洞評論，如「反映了當代中國社會的變遷」→ 刪或給具體證據
推廣語氣：「文化遺產」「文化底蘊」「自然之美」→ 刪
模糊歸因：「據業內人士指出」「有評論認爲」→ 要麼說清誰說的，要麼不說
展望章節套話：「儘管（主題）有其意義，但其面臨的挑戰有...」→ 具體說問題，不給虛無展望

3.8 用詞去正式化

不用用非常 / 極其很值得注意的是（直接說結論）綜上所述（直接收尾）例如比如購買 / 使用買 / 用很多同學 / 不少同學很多人 / 不少人這幾個事這幾件事

3.9 標點規則

使用直角引號「」，不用彎引號 ""
禁止破折號（—），用逗號或分號替代
不用感嘆號（除非推文/社交場景且確有情緒）
中文標點：，。；：！？、「」『』【】
四五個句號連發 = 打電報 → 合成長句或用逗號連
不用 em dash（—），用逗號或句號替代

3.10 中英混排留白

中文和英文之間加空格：CN 文字 EN → CN 文字 EN
中文和數字之間加空格：版本 2.0
不加空格的對象：代碼塊、JSON 鍵名、URL、內聯代碼

3.11 第二人稱

技術文檔：禁用「你」「您」。用「開發者」「技術負責人」等角色詞，或不直接稱呼讀者
博客：可以用「你」，但不要通篇「你會發現」「你需要」「你可以看到」

3.12 翻譯腔套路

❌ 「接住」「擊穿」「鋒利」「不崩」「不爆」「打穿」「扛住」等物理動作動詞用在了抽象認知上 ✅ 換成日常中文：「你這幾條我都收到了」「這個假設不成立」

❌ 抽象名詞做主語：工程上的現實比這些數字難看 ✅ 重寫，人/動作做主語。

3.13 空泛形容詞預判

❌ 「更乾淨：xxx」「邏輯很清晰：xxx」 ✅ 刪掉形容詞預判，直接說 xxx。

3.14 句式節奏

三連排比用太多？→ 換二連或一連。一個三連可以，背靠背的三連是模式識別失敗
用「首先...其次...最後」？→ 換「一方面...另一方面...」
段落結尾都是 punchy 短句？→ 換節奏
bold 小標題 + 句號模式（**xxx**。content）→ 改爲 **xxx**，content，讓 bold 變成承重詞而非獨立標題

四、分場景策略

4.1 技術文檔 / API 文檔 / 產品文案

觸發：「技術文檔」「API 文檔」「產品文案」「界面文案」「幫助文檔」

語氣：剋制、直接、可掃讀
不用第二人稱（「你」「您」）
不用「領先」「強大」「重磅」「顛覆」「震驚」「炸裂」等宣傳形容詞
不用「賦能」「抓手」「閉環」等黑話
不用感嘆號
直角引號「」
中英留白
不改代碼字面量、JSON 鍵名、URL、API 路徑
術語首次出現標註，後續不重複解釋
不用「Hello」「Hi」等問候開篇
目標：說清楚「它是什麼、用來做什麼、下一步看哪裏」

4.2 技術博客 / 長文

觸發：「博客」「技術文章」「技術長文」「寫一篇」「科普」

默認模式：資深工程師給同事講系統的口吻
可以口語，但不俚語化
減少情緒詞、感嘆詞、口頭禪
少用「說白了 / 其實 / 你會發現 / 誰能想到」推進行文
優先追求：清楚、穩、具體、節奏自然
優先做減法：刪解釋腔、刪總結腔、刪多餘轉折
把潤色做成減法，不是重寫
如果原句已經自然，不改
非工程師受衆：先去「不懂技術的同學」等居高臨下詞，去「你必須」等訓人腔，去太深術語。走「我怎麼用的，你試試」路徑，不走「系統綜述 + 框架表 + 長分析段落」

4.3 社交媒體 / 推文

觸發：「推文」「X推文」「twitter」「社交發文」「post」

五規則：

社區先行：開頭用社區錨點（star 數、感謝用戶、誰的反饋推動），改動清單放後面
亮點不全量：挑 2-4 個最有意思的，讀者要故事不是 changelog
用戶感受幀：寫法用「你用它的時候...」「有一種...的感覺」，不是「這個工具做了...」
一條立場：至少一句表明決策原因的意見句
中文節奏：用地道表達，避免翻譯腔和正式詞

結尾用邀請，不用 CTA
身份和敏感信號脫敏
不踩競品
公開前掃三件事：脫敏、不踩競品、用戶感受先於功能清單

4.4 發行說明 / Release Notes

觸發：「release」「changelog」「版本」「發行說明」

結構：Breaking Changes → New Features → Fixes & Improvements → Deprecations
格式：優先匹配目標項目最近一次 release 風格
條目：5-8 條，每條約一句話，只說用戶效果
title：版本號 + 最核心改動或主題，不超過 10 個詞
不要加 emoji（除非項目本身慶祝風格）
不加「不再更新」「final release」「停止維護」等終止信號（除非真實情況）
中英雙語：條目一一對應，不混寫，英文在前

4.5 科學論文 / 學術寫作

觸發：「論文」「abstract」「cover letter」「grant」「manuscript」

保持學術正式度，但刪除空洞套話
用「我們」指自己工作（不用被動躲閃）
引用具體作者，不用「有研究者指出」
不用「長期以來人們認識到...」
給出具體數字而非空泛結論
不用「在當今日新月異的領域中」
不用「這一範式轉變具有深遠意義」
不用「結果表明」「據觀察」

4.6 雙語內容

觸發：「雙語」「中英」「bilingual」「翻譯」

中英字符間加空格
不混用標點：中文用中文標點，英文用英文標點
術語跨全文一致
術語首次出現：保留英文 + 中文註解（或中文前置 + 英文括注）
後續只用中文，不要中英混用
常見可替換：context→上下文、state→狀態、cache→緩存、claim→斷言、runtime→運行時
術語未收斂的（prompt、embedding、tokenizer）保留英文合理
雙語版：條目編號一一對應，確認 EN/CN 意思一致，標記翻譯損失
禁止破折號

五、詞彙替換表（正式 → 口語）

不用用非常 / 極其很值得注意的是直接說結論綜上所述 / 總之直接收尾例如比如購買買使用用擁有有呈現是 / 顯得進行（+動詞）刪掉「進行」，用動詞本身賦能提供 / 幫助抓手關鍵措施閉環完整流程沉澱形成 / 積累對齊統一拉通 / 打通連接 / 貫通洞察分析結論兜底保障機制至關重要 / 意義重大重要褒有有坐落於在致力於努力 / 專注

六、執行流程

先識別場景：博客？技術文檔？推文？論文？確定語氣標準。
先保語義：確認不被改壞。
做減法：先掃段末總結句（中文最高頻 AI 痕跡）再掃對比句式（「不是...而是...」）再掃喉清開場、元評論、強調柺杖再掃副詞、被動語態、假主體再掃黑話、空洞形容詞
再順句子：節奏、標點、中英留白、破折號
最後回讀：優先修不自然處，不強改自然處
輸出：只給改寫後的文本。不加改動清單、解釋、收尾話。除非用戶明確要求。

七、改寫示例

示例 1：中文技術博客

改寫前：

衆所周知，隨着雲原生技術的不斷發展，Kubernetes 已經成爲了容器編排領域的事實標準。值得注意的是，雖然 K8s 本身功能強大，但在實際落地過程中，很多同學會發現它並不是銀彈。本文將從多個維度深入探討企業在落地 Kubernetes 時面臨的挑戰和應對策略，希望能爲正在考慮或已經踏上雲原生之旅的各位帶來一些啓發。

改寫後：