Community寫作與編輯github.com

n0ctx/以讀者為先寫作技巧

在撰寫或修改任何人類會閱讀的文字(文章、電子郵件、公告、說明、報告、行銷文案、社群貼文、聊天回覆)或審閱此類文字時使用。此技能專注於任何語言的句子層次可讀性,不涉及版面排版,也不是為了繞過 AI 偵測器的「人性化」處理。

以讀者為先寫作技巧 是什麼?

此技能旨在解決大型語言模型(LLM)生成文本的常見問題:句子結構複雜,迫使讀者耗費額外心力解讀。它提供一套清晰的清單與七項原則,包含:將人類動詞保留給人類主體、保持主詞與動詞緊密、保留有助於預測的連接詞、避免名詞堆疊、使用既有的動詞、採用讀者熟悉的慣用語,以及將重要資訊置於句首。這些原則適用於任何語言,且不改變文本的原始事實。此技能主要用於程式碼編輯器或終端機中的 AI 代理(如 Cursor 或 Claude Code),協助開發者在撰寫文件、電子郵件或任何需要清晰溝通的情境時,提升文本的可讀性。它特別強調,這並非為了繞過 AI 偵測器而使文字「人性化」;而是專注於讓讀者以最少的認知負擔理解資訊。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/n0ctx/skills/tree/HEAD/skills/reader-first-writing

Installed? Explore more 寫作與編輯 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

以讀者為先寫作技巧 是做什麼的?

你正在為人類讀者寫作。讀者沒有你的上下文,並且在閱讀每個句子時,會將它保留在短期記憶中。每當一個句子讓他們需要回頭尋找主詞、拆解一串名詞,或是補上你遺漏的連接詞,理解難度就會增加。LLM 生成的文字有幾個習慣性的傾向,恰好會引發這些問題:無生命的事物執行人類動作、主詞與動詞之間距離過長、省略可選的字詞、名詞堆疊,以及自創動詞與片語。這些做法都不會造成資訊遺失,但它們將解碼的工作轉嫁給了讀者。在起草和修改時,請修正這些傾向。

這不是「AI 人性化工具」。那些工具會改變表面措辭以繞過偵測器;此技能只關心讀者是否理解。刻意加入不規則或填充詞語來顯得更像人類,並非我們的目標。

適用範圍

任何針對人類讀者的文字,無論是何種體裁或語言,包括審閱其他人或模型撰寫的文字。不適用於程式碼、為 AI 撰寫的提示詞,或純粹為了通過 AI 偵測而做的改寫。若使用者或專案已有風格指南,應以該指南為優先;此技能僅涵蓋句子層次的可讀性。

核心測試

理解一個句子需要讀者付出心力,而這份心力必須有所回報。如果同樣的意思有更簡單的表述方式,你卻選擇了更難的,那麼讀者的心力就被浪費了:請修改它。如果某種表述能提供簡單版本無法達到的效果,例如難忘的節奏、精確的意象,或必要的專業術語,那麼它代表的意義就不同,可以保留,但前提是你能說出它帶來了什麼好處。

以下七項原則,正是 LLM 文字最常在此測試中失敗的地方。

原則

  1. 將人類動詞保留給人類主體。 當主詞是物體、概念或過程時,為它搭配一個它實際上能執行的動詞。「這次改版正悄悄消耗長期使用者的耐心」→「自從改版後,許多長期使用者覺得產品更難用了。」普通的無生命主詞是沒問題的:「銷售額年增 20%」、「新規則下個月生效」。需要修正的是隨意的人格化,例如會「消耗」、「影響」、「推動」、「預期」或「說話」的事物,因為讀者必須將隱喻轉譯回實際發生的事。

  2. 保持主詞與動詞緊密。 在主詞與動詞之間插入一個太長的子句,會迫使讀者在動詞出現之前一直記住主詞;請將句子分割。在修飾語置於名詞前的語言(如中文)中,常見問題是名詞前面有過長的修飾鏈,導致讀者直到句尾才知道句子在講什麼;當一個修飾語超過一個片語的長度時,請將其獨立成一個短句,或移到名詞之後。

  3. 保留有助於讀者預測的字詞。 保留連接詞(因為、所以、但是、而且)、你的語言中允許省略的主詞,以及明確的指涉(例如「這筆款項」而非含糊的「它」)。省略它們可以節省幾個字,但會迫使讀者自行推斷句子間的關係。在英文中,請保留關係子句以及「說」或「認為」等動詞後可省略的 "that"。這不代表要加入「實際上」、「基本上」這類填充詞;填充詞無助於讀者理解句子的連接方式。

  4. 名詞堆疊不超過兩個。 「使用者帳戶安全風險評估流程」→「評估使用者帳戶安全風險的流程」。使用介詞、所有格或動詞來打斷名詞串。

  5. 使用既有的動詞。 不要隨意將名詞當作動詞使用(例如「請 calendar 這件事」→「請將這件事排入行事曆」)。避免諸如「對齊」、「槓桿」、「落地」、「賦能」等行話動詞及其在其他語言中的對應詞;請直接說出具體的行動:和誰確認什麼、記錄什麼內容。

  6. 使用讀者見過的慣用語。 不要自創「讀者耐心預算」或「資訊密度護城河」這類片語。如果一個概念真的需要新名詞,請在它首次出現時用一句話解釋。

  7. 賦予重點應有的份量。 以讀者最需要知道的資訊開頭,並縮減或刪除次要材料。當每個要點佔據相同篇幅時,讀者無法判斷哪個最重要。平行結構、對比,以及不增加資訊量的形容詞或副詞串,會讓讀者需要從修辭中挖掘內容:請刪除它們。

修改

逐段修改,而非基於整體印象。對於每個讀起來不順的句子,嘗試用最簡單的文字重新表述相同的意思。如果可以,且沒有遺漏任何資訊,就採用較簡單的版本。如果不行,表示內容本身就很複雜:保留原意,並透過拆分句子與加入連接詞來幫助讀者。修改改變的是表達方式,而非陳述的事實:不要加入原文中不包含的資訊。

一個說明修改方向和幅度的例子:

修改前:本次發布全面賦能升級後的用戶數據同步體驗,系統性地解決跨裝置內容遺失痛點,後續我們將持續匯聚用戶反饋並對齊優化方向。

修改後:本次更新改善了資料同步功能,並修復了切換裝置時遺失內容的錯誤。我們將持續收集意見回饋,並以此決定下一步的改善目標。

修改去除了「賦能」、「匯聚」、「對齊」;拆解了「用戶數據同步體驗」和「跨裝置內容遺失痛點」這類名詞堆疊;將抽象的施動者「本次發布賦能」改為「本次更新」和「我們」;並將一個長句拆分成兩個各說一件事的句子。

提交前檢查

逐段檢視文字。針對以下每個「是」的回答,應用核心測試來決定是否修改:

  • 是否有一個物體或概念在執行人類的動作?
  • 名詞前是否有超過一個片語的修飾語,或是主詞與動詞之間有過長的子句?
  • 是否有連接詞、主詞或指涉被省略?
  • 是否有三個或以上的名詞堆疊在一起?
  • 是否有名詞被當作動詞使用、使用行話動詞,或是讀者從未見過的自創片語?
  • 讀者最需要知道的資訊是否靠近句首?
  • 是否存在不增加資訊量的平行結構、對比,或一連串的修飾語?

Individual skills in this repo

This repo contains 3 individual skills — each has its own dedicated page.

相關技能