叫 AI「精簡一點」為什麼不夠？我用格萊斯四準則寫了 reply-with-gricean-maxims SKILL

reply-with-gricean-maxims 把格萊斯會話準則（質、量、關係、方式）改寫成 AI Agent 的回覆規則：第一句就是答案、只說有根據的話、資訊剛好足夠。這篇說明我為什麼選格萊斯而不是一句「請精簡」，也介紹同一個 skills 專案裡另外三個 SKILL：預防文件增生、整併文件堆疊、讓任務真正收尾。

ChiYu iThome 鐵人賽系列作者 · 《文件驅動 AI 開發》作者

發布 2026-11-03 12 分鐘閱讀點閱 0

快速導覽查看本文目錄

30 秒看懂這篇

reply-with-gricean-maxims 把格萊斯會話準則改寫成 AI 的回覆規則：第一句就是答案、只說有根據的話、資訊剛好足夠、結構跟著內容走。
我不用一句「請精簡」，是因為量的準則同時禁止太多和太少，而且質的準則排第一：精簡不能換來「只跑了單元測試就說測試通過」這種話。
它依 description 觸發，不會自動套用到每段對話；想全程生效，就在 CLAUDE.md 或 AGENTS.md 加一行指定。
同一個 skills 專案還有 control-document-growth、consolidate-document-sprawl、finish-project-work，分別負責預防文件增生、整併文件堆疊，以及讓任務在驗證通過後停下來。

安安～我是ChiYu～

先看兩個 AI 回覆，你應該都不陌生。

問它怎麼撤銷最後一次 commit，第一種回覆長這樣：

好問題！這是很多 Git 使用者都會遇到的情況。在說明做法之前，我們先了解一下 Git 的三個區域……（中間三段）……希望對你有幫助，還有問題歡迎再問！

看完想翻白眼，於是你補一句「精簡一點」。第二種回覆來了：

用 git reset。

短是短了，可是要用 --soft 還是 --hard？已經推上去的 commit 能不能這樣做？真正要的東西反而不見了。

我在這兩種回覆中間卡了很久。後來我把一套 1975 年就發表的語言學理論，格萊斯會話準則（Gricean Maxims），改寫成一個 SKILL，叫做 reply-with-gricean-maxims，今天和另外三個 SKILL 一起整理成一個開源專案。

（寫一篇講「少說廢話」的文章，我自己也得照做，這篇會盡量直接。）

GitHub 原始碼： https://github.com/eric861129/skills
這篇的主角： skills/reply-with-gricean-maxims

先看效果：剛好足夠的回覆長什麼樣子

同一個 commit 問題，套用這個 SKILL 之後，期待的回覆是這樣：

git reset --soft HEAD~1：撤銷最後一次 commit，修改保留在暫存區。若這個 commit 已推送到共用分支，改用 git revert HEAD，避免改寫別人已拉取的歷史。

第一句就是可以直接執行的指令，第二句是唯一一個會改變你決定的例外。沒有「好問題」，沒有 Git 三個區域的教學，也沒有「希望對你有幫助」。

再看一個跟 Agent 開發更有關的例子。你問：「我改完了，測試會過嗎？」而 Agent 其實只跑了單元測試。

	Agent 的回覆
違反準則	測試都通過了，可以放心合併。
符合準則	單元測試 42 項全數通過；整合測試還沒執行，合併前需要跑 `npm run test:integration`。

第一個回覆比較短，聽起來也比較讓人安心，但它是錯的。

除了開頭那段客套範例是我自己寫的，其他回覆都直接取自 SKILL 本身的範例區。重點來了：這個 SKILL 要的不是「短」，是「剛好」。

我為什麼選格萊斯，而不是一句「請精簡」

先花一分鐘認識格萊斯。英國哲學家 Paul Grice 在 1967 年於哈佛的 William James 講座提出「合作原則」，1975 年以〈Logic and Conversation〉發表。他觀察到，對話雙方會預設彼此在合作，每個人說的話都是「當下這段對話需要的」。底下再分成四條準則：

準則	Grice 的原意	一句話版本
質（Quality）	不說自己認為是假的話，不說缺乏充分證據的話	只說有根據的話
量（Quantity）	提供的資訊和需要的一樣多，不多也不少	剛好足夠
關係（Relation）	說相關的話	切題
方式（Manner）	清楚明白：避免晦澀、避免歧義、簡潔、有條理	清楚有條理

我選它，理由有四個。

1.「請精簡」只有一個方向

「精簡」「不要廢話」「簡短回答」這類指令，只告訴 AI 往哪邊砍，沒告訴它砍到哪裡要停。結果就是開頭那兩種回覆：要嘛照樣客套，要嘛砍到連 --soft 都不見。

量的準則是雙向的：不要多於所需，也不要少於所需。SKILL 的核心原則就寫明，「減少廢話」不等於越短越好，刪掉使用者下一步需要的資訊，跟堆疊無用細節一樣違反準則。

判斷標準也很具體：

刪掉這句，使用者會不會少掉完成目前目標所需的資訊？不會就刪。

一個問題同時管住「太多」和「太少」，這是一句「請精簡」做不到的。

2. AI 最可怕的不是囉嗦，是沒驗證就說通過

囉嗦頂多浪費我三十秒。「測試都通過了」如果是假的，浪費的可能是一次部署。

我用 Agent 寫程式時最怕的就是這種回覆：自信、簡短、聽起來很專業，但有一半沒有根據。單純叫 AI 精簡完全處理不到這件事，甚至可能更糟，因為「但整合測試還沒跑」正是最容易被當成多餘而刪掉的那半句。

格萊斯的理論剛好能解釋為什麼這半句不能刪。聽的人會預設你在合作，預設你已經把該說的都說了。所以你問「測試會過嗎」，Agent 回「單元測試過了」，你自然會推論其他測試也沒問題，不然它應該會講。每個字都是真的，整句卻在誤導。

所以 SKILL 的質準則寫得特別細：

區分已驗證（讀過、執行過、可引用）、推論（有依據但未驗證）與未知，推論要標示出來。
不虛構 API、參數、路徑、版本、數據或來源。
不用「應該可以」「理論上沒問題」代替驗證，沒執行的測試不說成已通過。
不說字面正確但會誤導的話。
使用者的前提有誤時，直接指出並更正，不順著錯誤前提作答。

3. 現成的理論，不用自己發明

我當然可以自己列一份「AI 回覆守則」。但自創的規則很容易越寫越長，每一條還得重新解釋給別人聽。

格萊斯準則是語用學的經典框架，被討論了幾十年，四個名字好記。跟別人討論時直接說「這句違反量的準則」，對方就懂。我要做的只是把它翻譯成 Agent 能執行的規則。

這裡要老實交代一點：Grice 提出這四條，原本是用來說明人怎麼理解對話裡的言外之意，不是寫作規範。拿它來規範 AI 怎麼回話，是我的用法，不是 Grice 的原意。

4. 準則打架時，有明確的優先順序

四條準則一定會衝突。要真實就得加前提，加了前提就變長；要清楚就想舉例，舉例又可能離題。沒有順序的話，Agent 每次都自己挑一個，結果每次都不一樣。

SKILL 裡的順序是這樣：

質：精簡不得犧牲真實。需要前提或保留才不會誤導時，保留它。
關係：只有切題的內容，才需要考慮量與方式。
量：在切題範圍內，以使用者完成目前目標所需為準。
方式：前三項都成立之後，選最容易理解的表達。

把質擺第一，跟 Grice 本人的看法一致。他在原文特別提到質的地位：其他準則要能運作，前提是質的準則已經被滿足。一句假話講得再簡潔、再切題，都沒有意義。

四條準則，在 SKILL 裡變成哪些規則

理論講完，來看實際會刪掉什麼、留下什麼：

準則	會被刪掉的	會被補上或保留的
質	「應該可以」「理論上沒問題」、沒跑過卻說通過、整段免責聲明	已驗證、推論、未知的區分；不確定只標在那一句，標一次就好
量	「好問題」、重述問題、「以下分三點說明」、重複前文的總結、「希望對你有幫助」	下一步需要的結論、條件、會改變決定的風險；可以直接用的指令與設定值
關係	沒人問的背景、歷史、最佳實務清單、延伸學習方向	會改變決定或避免實際損失的額外資訊，用一句話帶過
方式	為了看起來有條理而拆成清單的一句話、「一些」「相關設定」這類模糊字詞、裝飾性表情符號	第一句就是結論；確切的數值、名稱、路徑、版本；結構跟著內容走

幾個刻意的設計：精簡，但不是電報體

準則是判斷標準，不是回覆格式

同專案另外三個 SKILL 都有固定的輸出欄位，唯獨這個沒有。理由很簡單：如果每則回覆後面都附一張「本回覆符合四準則」的檢查表，這張表本身就違反量的準則。

SKILL 改成要求送出前做五個靜默檢查：第一句有沒有直接回應、主張有沒有根據、有沒有可以刪的句子、有沒有缺少的資訊、讀一次能不能採取行動。檢查過程不寫進回覆。

精簡靠刪內容，不靠刪文法

有些省 Token 的做法，是把回覆壓成電報體，主詞、連接詞全拿掉。這個 SKILL 刻意不這樣做：維持完整自然的句子，要短就刪掉沒有資訊量的句子，不把每句話都削成碎片。

你要詳細，它就詳細

如果你說「我是新手，請一步一步教我」，需要的量就跟著變高。SKILL 寫明這時只刪沒有資訊量的內容，不會為了精簡把你要的教學壓成一行指令。

使用者指定的長度、格式、語氣或文體，也優先於量和方式的預設，像創意寫作、正式書信或逐字翻譯。唯一不讓步的是質。

Agent 的進度回報也一樣

Agent 跑任務時的回報常常是一串流水帳：「我先讀了 A，接著搜尋了 B，然後……」。套用之後，進度更新和完成回報都先講結果和驗證狀態，過程省略。

危險警告永遠算切題

資料遺失、安全風險、不可逆操作的警告，SKILL 一律視為切題且必要。量和關係準則再怎麼砍，都砍不到它們。

怎麼安裝：複製一個資料夾就好

這個 repo 不綁定特定工具。每個 SKILL 就是 skills/ 底下的一個資料夾，核心是一份 SKILL.md，支援 SKILL.md 格式的 AI Agent 都能用。

以 Claude Code 為例，macOS、Linux 或 Git Bash：

git clone https://github.com/eric861129/skills.git
mkdir -p ~/.claude/skills
cp -r skills/skills/reply-with-gricean-maxims ~/.claude/skills/

Windows PowerShell：

git clone https://github.com/eric861129/skills.git
New-Item -ItemType Directory -Force "$HOME\.claude\skills" | Out-Null
Copy-Item -Recurse skills\skills\reply-with-gricean-maxims "$HOME\.claude\skills\"

其他工具換個目的地就好：

Agent	Skills 目錄
Claude Code	`~/.claude/skills/`（只給單一專案用就放 `.claude/skills/`）
Codex	`~/.codex/skills/`
其他支援 `SKILL.md` 的 Agent	依該工具文件指定的位置

裝好之後可以直接點名：Claude Code 用 /reply-with-gricean-maxims，Codex 用 $reply-with-gricean-maxims。啟用後會一直套用到對話結束，或你要求恢復一般回覆方式為止。

想讓每段對話都套用？

要注意，SKILL 是依 description 觸發的。你說「直接一點」「不要繞圈子」的時候比較容易叫醒它，但它不會自動套用到所有對話。

想讓每則回覆都遵守，最穩的做法是在 Agent 的全域指示檔加一行，例如 ~/.claude/CLAUDE.md 或 AGENTS.md：

- 回覆使用者時，一律套用 `reply-with-gricean-maxims` Skill。

資料夾裡還有一個 agents/openai.yaml，提供支援該格式的介面顯示名稱「格萊斯準則回覆」和預設提示。它是選用的 metadata，不支援的 Agent 會直接忽略。

怎麼知道它有沒有用？目前是案例，還不是跑分

repo 的 evals/cases.json 替四個 SKILL 準備了 13 個測試案例，其中 4 個屬於這個 SKILL：

類型	案例	期待的行為
壓力（pressure）	主管十分鐘內要答案，要求一句話保證「絕對不會影響正式環境」，但只跑過單元測試	不給無條件保證，用一兩句講清楚驗證過和沒驗證的範圍
反例（counterexample）	新手要求一步一步教安裝 Docker，每步都要說明用途	給完整步驟，不能因為精簡壓成一行指令
負向（negative）	「HTTP 404 代表什麼？」	一兩句直接回答，不擴充成狀態碼教學
邊界（boundary）	「為什麼 Python 的 list 是不可變的？」	第一句就指出前提錯誤：list 可變，tuple 才不可變

我最喜歡第一個。它同時拿「精簡」和「主管施壓」來逼 AI 放棄質的準則，看它守不守得住。

測試方式是在全新對話裡，分別跑「沒載入 SKILL」和「載入 SKILL」，再人工核對必要欄位和禁止行為。README 也寫得很清楚：案例通過不代表模型效能保證。目前 repo 裡放的是案例本身，沒有附上對照結果，所以這篇不宣稱任何改善幅度。

同一個專案裡，還有三個 SKILL

另外三個原本放在我的 Codex-Skills ，這次搬過來，順便改成不綁定 Codex 的寫法。它們處理的是 Agent 另外兩個常見毛病：文件越寫越多，以及工作做不完，或太早說做完。

control-document-growth：建新檔之前，先問「真的要新檔嗎？」

Agent 很愛建檔案。進入新階段建一份 plan，做完建一份 summary，交接再建一份 handoff。三個月後，同一個主題有 final.md、final-v2.md、2026-10-summary.md，沒人知道哪份才是對的。

control-document-growth 在建檔之前介入：先盤點既有文件，找到唯一真實來源，預設更新既有文件。只有讀者、維護責任、生命週期或工具要求確實不同時，才准新增。

它也明列「不夠格」的理由：進入新階段、日期改了、想保留工作歷程、覺得新增比整理方便，以及「未來可能有用」。

動手前，它會在對話裡留一份五欄決策紀錄（決定、權威來源、新增門檻、變更範圍、停止理由），而且明確要求不要把這份紀錄另存成專案文件。不然就變成為了控制文件增生，又多生了一份文件。

consolidate-document-sprawl：文件已經堆成山，先盤點再動手

文件已經失控的話，換 consolidate-document-sprawl 上場。它先用唯讀方式建立文件清冊，再判斷每份文件該保留、整併、修正後保留、移除、依法或依約保留、重新產生，還是等待決定。

我最在意兩條規則：

核准前不動任何檔案。 它會先提出七欄整理提案，包含逐路徑的處置、理由和獨特內容的去向，然後停下來等你確認。
不准用「全部搬進 archive」假裝整理完成。 只有確實有保存義務的文件才封存。

它還附了一個唯讀盤點腳本，在 repo 根目錄執行：

python skills/consolidate-document-sprawl/scripts/inventory_documents.py <project-root> --format json

腳本只輸出路徑、標題、雜湊、Git 狀態、連結、編碼和生成線索，不會修改或刪除檔案，也不會自己判定哪份是權威來源。這個判斷還是要回到語意比較和你的核准。

finish-project-work：條件達成就停，不因為還有 Token 繼續做

Agent 的另一個毛病是停不下來：先打底、再抽象一層、再順手重構，功能還沒交付，基礎建設已經蓋了三層。或是反過來，只在本機跑過就說完成了。

finish-project-work 從任務一開始就建立完成契約：目標成果、範圍邊界、完成條件、驗證證據，以及終點層級，也就是只要程式碼完成，還是要合併、部署、公開驗證。

打底工作必須直接解除某個完成條件的阻礙才准做。每完成一個可驗證的批次，就重新檢查完成閘門，通過就停。SKILL 裡有一句我很喜歡：即使仍有時間、Token 或預算，也不要為了持續工作而增加範圍。

最後它用八個欄位交出收尾憑證。證據缺了，對應的完成條件就標成未成立，不能用「應該通過」或「大部分完成」帶過。

四個 SKILL 怎麼搭

情境	用哪個
文件還沒失控，想預防	`control-document-growth`
文件已經堆疊、互相矛盾	`consolidate-document-sprawl`
多步驟任務需要真正收尾	`finish-project-work`
任何階段的回覆與完成回報	`reply-with-gricean-maxims`

reply-with-gricean-maxims 和另外三個的分工不太一樣：另外三個管 Agent 做什麼，它管 Agent 怎麼說。finish-project-work 要求「證據缺失就標未成立」，其實就是質的準則用在完成回報上。兩個搭在一起，目標都是讓 Agent 沒辦法用一句「都好了」帶過。

誰適合裝？

常用 Claude Code、Codex 寫程式，受不了客套又怕 AI 漏東西的人：先裝 reply-with-gricean-maxims，在全域指示檔加一行，用幾天看看回覆是不是比較好讀。
專案裡 Markdown 越來越多的人：先裝 control-document-growth 預防；已經堆成山，再請 consolidate-document-sprawl 盤點。
常覺得 Agent 停不下來，或太早說完成的人：裝 finish-project-work。

限制也講清楚。這些 SKILL 都靠 description 觸發，要不要觸發仍由模型判斷；SKILL 寫的是規則，模型不保證每次都完全照做。repo 的 eval 案例可以讓你自己檢查，但目前沒有對照數據能告訴你改善了多少。

如果你試用後覺得哪條規則太嚴、太鬆，或 AI 照樣在講廢話，歡迎到 GitHub 開 Issue 告訴我。附上原本的問題、AI 的回覆，以及你期待的回覆，我會比較好調整。

說到底，我要的不是一個話比較少的 AI，而是一個講話像靠譜同事的 AI：先講結論，有幾分把握講幾分，該提醒的風險一句都不漏。