新智元報導
編輯：元宇
【新智元導讀】一個讓 AI 像原始人一樣說話的外掛，在 Hacker News 上一夜爆紅，衝破 2 萬顆星。它的核心只是一條簡單粗暴的提示詞（prompt）：刪掉冠詞、客套和一切廢話，號稱能省下 75% 的輸出 token。它能火，說明開發者已經受夠 AI 話嘮了。
最近，一個叫「caveman」（穴居人）的 Claude Code 外掛，在 Hacker News 炸了。
先看一張圖。
從這條 GitHub star 增長曲線來看，「JuliusBrussee/caveman」在最初很長一段時間裡幾乎只是緩慢爬升，隨後陡然上揚：
短短半天左右，star 數從幾十一路衝到 500，目前已衝破 2 萬！
「穴居人」省 Token 技能爆紅！
caveman 一夜爆紅背後，其實是一次典型的社群情緒共鳴。
它意味著「AI Yap（廢話連篇）」，這個看上去很小、卻讓無數人早已崩潰的痛點，再次被人精準地捅破了。
很快就有網友把 caveman 稱作「2026 年最厲害的提示詞技巧」，稱它能夠砍掉浪費在「我很樂意幫你」這種禮貌和鋪墊上的 token。
這個外掛乾的事其實很簡單：讓 AI 代理程式像洞穴人一樣說話。
刪掉「the」、「please」、「thank you」……刪掉一切不影響技術含義、卻不斷吞噬 token 的「人類客套」。
https://github.com/JuliusBrussee/caveman
專案出自開發者 Julius Brussee 之手，GitHub 倉庫名為「JuliusBrussee/caveman」。
Julius 在 README 裡拋出的核心問題也非常直接：為什麼少量 token 能說清楚的事，要用那麼多 token 去說？
這是一款同時適配「Claude Code」和「Codex」的技能/外掛。
它的核心思路是讓智慧體像「原始人」一樣開口，在不犧牲技術準確性的前提下，把輸出壓縮到極致，並聲稱可將 token 消耗降低約 75%。
問題也隨之而來：刪掉冠詞和禮貌用語，真的就能為用戶省掉四分之三的錢嗎？
扒開 SKILL.md
網友傻眼，就這？
caveman 到底怎麼「省」的？
打開它的核心檔案 SKILL.md，內容確實不長。
https://raw.githubusercontent.com/JuliusBrussee/caveman/main/skills/caveman/SKILL.md
檔案 frontmatter 直接把它定義成「Ultra-compressed communication mode」（超壓縮通訊模式）。
並寫明：
透過像洞穴人一樣說話，在保持技術準確性的前提下，目標是把 token 用量壓到更低。
當用戶說出「caveman mode」、「talk like caveman」、「use caveman」、「less tokens」、「be brief」，或調用「/caveman」時啟用。
當用戶明確要求更高 token 效率時，也可自動觸發。
它節省「token」的規則也非常簡單粗暴：別用冠詞，別說廢話，別客氣；技術術語和程式碼區塊保留，其他能砍就砍。
刪除以下內容：冠詞、語氣填充詞、客套話、猶豫性表達。
允許使用短句、碎片句。
優先使用更短的同義詞，比如說「大」而不是「龐大」，說「修」而不是「實施一個解決方案」。
技術術語必須保持精確。
程式碼區塊不改。
報錯訊息必須原樣引用。
推薦句式：[問題][動作][原因]。[下一步]。
比如，不要這樣寫：「當然！我很樂意幫你。你遇到的問題，很可能是由……引起的……」
而是要這樣寫：「Bug 在認證中介軟體。Token 過期判斷用了 <，沒用 <=。改這裡：」
它支援三檔強度級別：lite、full（預設）、ultra。
- lite：去掉填充詞和猶豫表達。保留完整句子和正常書面感。專業、簡潔；
- full：進一步壓縮表達，可省略部分虛詞，允許碎片句，使用短詞替代。典型 caveman 風格；
- ultra：大量縮寫，如 DB、auth、config、req、res、fn、impl；盡量去掉連接詞；用箭頭表達因果，如「X→Y」；能用一個詞說明，就不用兩個詞。
舉個例子：
lite：「連接池會複用已經打開的資料庫連接，而不是每次請求都新建一個，從而避免重複握手開銷。」
full：「連接池複用已打開的 DB 連接。不是每個請求都新建。省掉握手開銷。」
ultra：「連接池=複用 DB 連接。跳過握手→高併發更快。」
當然，遇到安全警告、不可逆操作確認、多步驟流程、或用戶明顯已經困惑時，清晰表達仍然優先。這也是 SKILL.md 裡明確寫出的例外邏輯。
沒有模型架構改動，沒有推理機制層面的壓縮，caveman 的本質就是一條精心編寫的 system prompt，約束的是 AI 的輸出風格。
更關鍵的一點：作者 Julius Brussee 本人在 HN 討論帖裡主動澄清了，這個 skill 不針對 hidden reasoning tokens 和 thinking tokens。
模型在後台「想」的過程並不會因為 caveman 自動變短，它主要壓縮的是最後說出來的那部分。
Anthropic 官方文件也提到，skills 的名稱和描述本身會佔用上下文預算。
換句話說，加載 caveman 這個 skill 本身就要消耗 token。
所以端到端的真實成本節省，未必等於 README 裡那個醒目的「75%」。
因此，caveman 很可能顯著壓縮了可見輸出長度，但這不應被直接理解為同等比例的總成本下降。
README 裡的 75%，到底靠不靠谱？
從倉庫公開內容看，作者確實提供了 benchmark 腳本，也在 README 裡列出了若干任務的 token 對比，區間從 22% 到 87%，平均 65%。
但截至目前，公開倉庫裡能直接看到的是測試腳本和示例表格；外界仍難以僅憑倉庫當前內容完整複核每一項結果的複現實驗鏈條。
作者在 HN 帖子裡表示：這只是初步測試，不是嚴格的基準測試。
不過，「簡潔表達是否會傷害 AI 性能」這個問題，學術界確實有人研究過。
https://arxiv.org/pdf/2401.05618
2024 年的論文《The Benefits of a Concise Chain of Thought on Problem-Solving in Large Language Models》顯示：
當研究者要求模型使用更簡潔的推理鏈時，GPT-3.5 和 GPT-4 的平均回答長度下降了 48.70%，而整體解題能力幾乎沒有明顯下降；但在數學題上，GPT-3.5 的表現平均下降了 27.69%。
2026 年的論文《Brevity Constraints Reverse Performance Hierarchies in Language Models》則更進一步指出：
在部分基準上，對大模型加入簡潔約束，準確率可提升 26 個百分點，甚至可能改變不同規模模型之間原本的表現排序。
https://arxiv.org/pdf/2604.00025
以上兩篇論文，為「簡潔未必傷性能」提供了研究背景。
但必須說清楚：它們研究的是 brevity 作為通用提示策略的效果，不是對 caveman 這個 GitHub 倉庫的專項評測。
README 引用這些研究，最多只能說明它的思路並非毫無理論背景，不能直接當作對項目自身效果的嚴格驗證。
Claude Code 的外掛生態
開始起來了
caveman 能火，還有一個背景原因：
Anthropic 已經為 Claude Code 提供了相對完整的 skill 與 plugin 機制。
https://code.claude.com/docs/en/skills
根據 Anthropic 官方文件，開發者只需建立一個 SKILL.md 檔案，Claude 就能把它識別為 skill；其中 description 用來決定何時自動加載，name 則會變成可直接觸發的斜槓命令。
官方文件還明確寫了 plugin 級 skill 的路徑結構是 <plugin>/skills/<skill-name>/SKILL.md。
而 caveman 倉庫中，確實能看到 .claude-plugin、plugins/caveman、skills/caveman 等目錄，說明它不是一個停留在「幾句提示詞」層面的玩具，而是按照 Claude Code 的 skill/plugin 機制包裝出來的擴展。
這也意味著，開發者確實可以透過一個 SKILL.md，在不改模型底層的前提下，改變 Claude Code 在特定任務中的調用方式和輸出風格。
某種意義上，這已經有點像早期 VS Code 擴展生態：
先有一批看起來輕量、甚至帶點玩笑感的擴展冒出來，隨後才逐漸長成更嚴肅、更細分的工作流工具。
開發者苦 AI 廢話久矣
回到那個最初的問題：caveman 到底有沒有用？
如果把它當成一個嚴格意義上的「省錢工具」，那就需要更謹慎。
它壓縮的只是可見輸出文字，並不觸及 hidden reasoning tokens，而後者往往才是 Claude Code 成本的大頭。
再加上 skill 本身也會佔用上下文，端到端算下來，真實節省大概率到不了 75%。
真正想優化 token 成本，關鍵也不在這裡。模型層級調用、上下文視窗管理、prompt 工程、快取策略，這些才是真正的主戰場。
但 caveman 真正值得關注的地方，不在於它是不是開出了一劑完美藥方，而在於它本身就是一個訊號。
當一個開發者把「讓 AI 少說廢話」這件事做成外掛，放到 GitHub 上，被上千人認真討論，在 HN 上爆火，事情的重點就已經變了。
它說明，AI 工具的冗長，不再只是一個可以忍受的小毛病，而是嚴重到用戶開始自己動手修正的程度。
實際上，開發者們在情緒上早就已經崩潰了：去各大社群看一眼，滿屏皆是對 AI 廢話的哀嘆抱怨：
我只需要兩行正規表示式程式碼，它非要給我寫 5 個自然段的正規表示式歷史散文；
求求你別再對我說「Certainly! Here is the……」了，直接給我報錯或者給我程式碼不行嗎？
在 Hacker News 上，這種哀嘆和抱怨更是與使用成本掛鉤：
我簡直是在花 15 刀/100 萬 Token 的價錢，來閱讀 AI 對我的道歉和寒暄。
只因爲要改一個標點，它竟然把整個 800 行的檔案重新輸出了一遍，看著 API 餘額肉眼可見地往下掉，我都快破產了。
……
當大家寧願讓 AI 像「山頂洞人」一樣說話，也不願意繼續為冗餘輸出多付 token 成本時，真正應當反思的也許是那些主流 AI 大廠。
為什麼直到今天，他們還沒有把「剋制」做成一種基礎能力。
不要別總盯著算力生意，而是要認真想想，用戶到底為什麼越來越受不了這些沒必要的輸出。
參考資料：
https://github.com/JuliusBrussee/caveman
https://code.claude.com/docs/en/skills
https://news.ycombinator.com/item?id=47647455
秒追 ASI
⭐ 點贊、轉發、在看一鍵三連 ⭐
點亮星標，鎖定新智元極速推送！