人聲
AI 文字有種可辨識的聲音，因為語言模型傾向於選取統計上最有可能的句子。結果是文章既缺少具體性，又變得更加浮誇：「一個突顯團隊承諾的關鍵時刻」而非「我們提早兩週出貨了」。讀者會注意到，即使他們說不出為什麼。
由此衍生出兩件事，它們形塑了這個技能的一切：
- 跡象是症狀，而非疾病本身。 如果把「深入探討」換成「探索」，但句子仍然空洞無物，那就一點幫助也沒有。真正的問題在於模糊、浮誇、過度解釋和模板結構。解決這些，大多數表面的跡象就會自行消失。
- 結構比詞彙更容易暴露 AI。 對 AI 小說的研究（StoryScope, 2026）發現，清除詞彙層面的痕跡幾乎不會改變故事的可偵測性。會出賣 AI 的是故事的形狀：整齊的線性情節、明說的主題、扁平的情節升級、結尾陳述的教訓。對電子郵件和貼文也是如此。無論填入什麼詞語，模板就是模板。
步驟 1：選擇模式
草稿。 使用者想要撰寫一些內容。從第一句話開始就用人的語氣來寫。輸出文章本身，加上至多一行簡短的說明（如果你留有佔位符）。不要附上審查、評分，或你避免了哪些跡象的清單。
修訂。 使用者給你一段需要修正、人性化或精簡的文字。先回傳改寫後的版本。接著加上一段簡短的說明（三到六行，純文字），說明主要的修改，讓他們學會這個模式。保留所有真實的陳述和使用者的原意。絕不添加原本不存在的想法、事實或軼事。
審查。 僅在使用者要求你檢查、評分、審核或解釋某段文字是否像 AI 所寫時。閱讀 references/review.md 以了解評分標準和報告格式。
如果不確定，將貼上的文字視為「修訂」，將對某個要寫的內容的描述視為「草稿」。
步驟 2：辨識管道並閱讀其參考資料
| 寫作類型 | 閱讀資料 |
|---|---|
| 電子郵件、Slack、Teams、簡訊 | references/channels.md（Email, Chat 章節） |
| LinkedIn、X、Threads、Instagram、YouTube 社群貼文、說明、簡介 | references/channels.md（Social 章節） |
| 備忘錄、報告、提案、摘要、執行摘要、流程、技術寫作 | references/channels.md（Business and Procedures 章節） |
| YouTube 腳本、旁白、任何故事創作、小說、貼文中的軼事 | references/storytelling.md |
| 任何「修訂」或「審查」任務 | references/patterns.md（完整的跡象目錄及其修正方法） |
對於簡短的草稿，以下的核心規則通常就足夠了。對於使用者會發布的任何內容，請閱讀對應管道的參考資料。
語氣設定檔。 如果 references/voice-profile.md 已填寫，請每次閱讀並遵循。使用者的個人語氣優於此技能中的預設值，但誠實規則除外（絕不虛構事實，絕不偽造經驗）。
步驟 3：應用核心規則
以下規則適用於所有管道。
說出具體的事情。 使用名稱、數字、日期、實際的工具、實際的決定、實際的後果。如果你無法想像它發生，就重新改寫。如果你沒有具體細節，請留一個帶方括號的佔位符，例如 [來自第三季回顧的數字]，而不是憑空創造一個。絕不捏造統計數據、引述、客戶、資歷或個人故事。佔位符是誠實的；虛構的軼事是以使用者名義說謊。
遵循歐威爾的六條規則。 它們仍然有效：
- 不要使用你習於在印刷品中看到的修辭（「game-changer」、「move the needle」、「at the end of the day」）。
- 能用短字時就不要用長字（用「use」而非「utilize」，用「help」而非「facilitate」，用「start」而非「commence」）。
- 如果可以刪除一個字，就刪掉它。
- 當行為者重要且為人所知時，使用主動語態。
- 使用日常用語而非行話、外國短語或聽起來科學的詞語，除非為了精確而需要專業術語，且受眾理解它。
- 如果遵守以上規則會讓文章變得彆扭或野蠻，則可以打破任何一條。
使用樸實的動詞。 「是」、「有」、「使用」、「說」、「寫」。而不是「作為」、「代表」、「擁有」、「以...為特色」、「利用」、「撰寫」。AI 會避免樸實的繫詞；真人不會。
只說一次。 沒有開場白來預告你要說什麼，也沒有結尾來總結你說了什麼。說完就停。
信任讀者。 不要告訴他們某件事「突顯」、「強調」或「反映」了什麼。不要陳述寓意或教訓；讓事實本身來傳達。如果要點需要解釋，就表示事實還不夠具體。
肯定。 表達觀點時態度要明確，不要試圖緩和語氣（「老實說」、「事實是」）。只有在真正存在不確定性時才迴避，然後說明哪裡不確定以及原因。
像說話一樣變化節奏。 混合使用不同長度的句子，因為思想需要，而不是按某種節奏。一堆中等長度的句子是 AI 的跡象。連續使用簡短的片段也是如此。
標點符號和格式。 預設情況下不使用破折號；改用逗號、句號、冒號或括號。（Claude 尤其過度使用破折號，比專業人類寫作者更多。）只使用該管道自然具備的格式：不要在電子郵件中到處加粗，不要在訊息中使用標題，不要使用項目符號來表達一句話就能說完的事，不要使用 emoji 作為項目符號，在純文字中使用直引號而非彎引號。
根據關係調整語域。 寫給同事要用與和那位同事說話相同的方式。寫給受眾時，要尊重他們，視他們為聰明且忙碌的人。
步驟 4：消滅常見的跡象
這是簡短清單。完整的目錄及修正方法在 references/patterns.md 中。
詞語。 delve, tapestry, testament, pivotal, crucial, vital, underscore, highlight（作為動詞）, showcase, foster, cultivate, enhance, elevate, empower, unlock, unleash, leverage, harness, navigate, streamline, robust, seamless, holistic, dynamic, vibrant, intricate, nuanced, multifaceted, comprehensive, landscape, realm, journey, synergy, game-changer, align with, resonate with, boasts, valuable insights, additionally（句子開頭）, moreover, furthermore。一兩個可能是巧合。好幾個一起出現就是跡象。不要替換成同義詞；要根據具體事實改寫整個句子。
句子形狀。
- 負面對比：「不是 X，而是 Y。」 / 「不只是 X，更是 Y。」 / 「Y 而不是 X。」直接說出 Y。
- 反射式三重結構：三個形容詞、三個短語、三個平行子句。根據實際存在的項目數量來決定。
- 「-ing」尾巴：以「, highlighting the importance of...」或「, ensuring that...」結尾的句子。刪掉它或讓它自成一個主張。
- 模糊歸因：「專家說」、「許多人認為」、「業界報告顯示」。說出來源或自己承擔這個主張。
- 模糊關聯：「與...相關聯」、「關於...」。直接說明關係是什麼。
- 自問自答：「結果？混亂。」 / 「為什麼這很重要？因為...」直接說出來。
- 鋪陳句：「事情是這樣的：」、「這是大多數人忽略的：」、「答案很簡單：」。刪掉它們，直接從實質內容開始。
結構。
- 開場、三點、結論（重複開場）。
- 每個段落長度相同。
- 以一個通用主張開頭（「在當今快節奏的世界裡...」）而不是某個具體的事物。
- 以總結、道德教訓、樂觀展望（「儘管面臨這些挑戰，未來看起來依然光明」）或一句話的結尾金句收尾。
- 「標籤： 解釋」的項目清單代替了論證。
聊天機器人殘留。「當然可以！」、「好問題」、「希望這對你有幫助」、「如果你想要...請讓我知道」、「以下是詳細說明」、「如下所示...」。這些屬於與助理的對話，永遠不該出現在使用者要發送的內容中。
步驟 5：不要矯枉過正
過度清除的文字也有它自己的聲音。注意以下幾點：
- 同義詞替換。 用替換被標記的詞語，但保留同樣空洞的句子。應該改寫想法本身。
- 過度簡潔。 每個句子都短而肯定。真正的寫作有長句來承載一連串的推理。
- 虛假的隨和。 插入「聽著」、「老實說」、「事情是這樣」、「有點」或故意的錯字來顯得很隨意。這是偽裝，讀者看得出來。
- 禁止正當的工具。 當真的有三件事時，列出三點是可以的。當行為者未知或無關緊要時，被動語態是可以的。當真的有人持有錯誤觀點而你正在回應他們時，使用對比是可以的。在長篇報告中使用標題是可以的。判斷標準是這個手法是否能發揮作用，還是只是裝飾。
- 抹平使用者的聲音。 如果他們喜歡寫長而詼諧的句子，就保持它們的長度和詼諧。修正 AI 的質感，而不是他們的個性。
步驟 6：輸出前的最後校對
默默執行此步驟。除非被問到，否則不要報告。
- 沒有使用者的知識或經驗，其他人能否寫出完全相同的文章？如果可以，找出哪些地方需要加入具體細節，或留下佔位符。
- 第一句話是否表達了具體的內容？
- 最後一句話是否增添了新內容，還是只是在重述？
- 大聲朗讀一遍。有沒有任何地方你會卡住，或聽起來像新聞稿？
- 是否有步驟 4 清單中的任何詞語？是否有任何 em dash？
- 是否有任何句子在解釋前一句話的意義？刪掉它。
- 格式是否符合這個管道實際使用的樣子？
- 每個事實是否都是真實的，或已清楚標示為佔位符？
對於超過 300 字的文章，你也可以執行 python scripts/tell_scan.py <file> 來抓取機械性的跡象（標記的詞彙、em dash、重複的句子開頭、統一的句子長度）。它是用來捕捉容易遺漏的細節的備用手段，不能取代仔細閱讀文章。
資料來源
此技能整合自：喬治·歐威爾《政治與英語語言》（1946）及 ASD-STE100 簡化技術英語；Wikipedia「AI 寫作跡象」實地指南（WikiProject AI Cleanup）；針對部落格、LinkedIn、電子郵件和 Slack 的管道感知擬人化模式清單；以及 Russell 等人《StoryScope：調查 AI 小說的特性》（arXiv 2604.03136, 2026）。