逼AI當(dāng)山頂洞人！Claude防話癆插件爆火，網(wǎng)友：受夠了AI廢話

新智元報道

編輯：元宇

【新智元導(dǎo)讀】一個讓AI像原始人一樣說話的插件，在HN上一夜爆火，沖破2w星。它的核心只是一條簡單粗暴的prompt：刪掉冠詞、客套和一切廢話，號稱能省下75%的輸出token。它能火，說明開發(fā)者已經(jīng)受夠AI話癆了。

最近，一個叫「caveman」（穴居人）的Claude Code插件，在Hacker News炸了。

先看一張圖。

從這條GitHub star增長曲線來看，「JuliusBrussee/caveman」在最初很長一段時間里幾乎只是緩慢爬升，隨后陡然上揚(yáng)：

短短半天左右，star數(shù)從幾十一路沖到500，目前已沖破2w！

「穴居人」省Token技能爆紅！

caveman一夜爆火背后，其實是一次典型的社區(qū)情緒共振。

它意味著「AI Yap（廢話連篇）」，這個看上去很小、卻讓無數(shù)人早已破防的痛點(diǎn)，再次被人精準(zhǔn)地捅破了。

很快就有網(wǎng)友把caveman稱作「2026年最厲害的提示詞技巧」，稱它能夠砍掉浪費(fèi)在「我很樂意幫你」這種禮貌和鋪墊上的token。

這個插件干的事其實很簡單：讓AI agent像洞穴人一樣說話。

刪掉「the」「please」「thank you」……刪掉一切不影響技術(shù)含義、卻不斷吞噬token的「人類客套」。

https://github.com/JuliusBrussee/caveman

項目出自開發(fā)者Julius Brussee之手，GitHub倉庫名為「JuliusBrussee/caveman」。

Julius在README里拋出的核心問題也非常直接：為什么少量token能說清楚的事，要用那么多token去說？

這是一款同時適配「Claude Code」和「Codex」的技能/插件。

它的核心思路是讓智能體像「原始人」一樣開口，在不犧牲技術(shù)準(zhǔn)確性的前提下，把輸出壓縮到極致，并聲稱可將token消耗降低約75%。

問題也隨之而來：刪掉冠詞和禮貌用語，真的就能為用戶省掉四分之三的錢嗎？

扒開SKILL.md

網(wǎng)友傻眼，就這？

caveman到底怎么「省」的？

打開它的核心文件SKILL.md，內(nèi)容確實不長。

https://raw.githubusercontent.com/JuliusBrussee/caveman/main/skills/caveman/SKILL.md

文件frontmatter直接把它定義成「Ultra-compressed communication mode」（超壓縮通信模式）。

并寫明：

通過像洞穴人一樣說話，在保持技術(shù)準(zhǔn)確性的前提下，目標(biāo)是把token用量壓到更低。

當(dāng)用戶說出「caveman mode」「talk like caveman」「use caveman」「less tokens」「be brief」，或調(diào)用「/caveman」時啟用。

當(dāng)用戶明確要求更高token效率時，也可自動觸發(fā)。

它節(jié)省「token」的規(guī)則也非常簡單粗暴：別用冠詞，別說廢話，別客氣；技術(shù)術(shù)語和代碼塊保留，其他能砍就砍。

刪除以下內(nèi)容：冠詞、語氣填充詞、客套話、猶豫性表達(dá)。

允許使用短句、碎片句。

優(yōu)先使用更短的同義詞，比如說「大」而不是「龐大」，說「修」而不是「實施一個解決方案」。

技術(shù)術(shù)語必須保持精確。

代碼塊不改。

報錯信息必須原樣引用。

推薦句式：[問題][動作][原因]。[下一步]。

比如，不要這樣寫：「當(dāng)然！我很樂意幫你。你遇到的問題，很可能是由……引起的……」

而是要這樣寫：「Bug在認(rèn)證中間件。Token過期判斷用了<，沒用<=。改這里：」

它支持三檔強(qiáng)度級別：lite、full（默認(rèn)）、ultra。

• lite：去掉填充詞和猶豫表達(dá)。保留完整句子和正常書面感。專業(yè)、簡潔；

• full：進(jìn)一步壓縮表達(dá)，可省略部分虛詞，允許碎片句，使用短詞替代。典型caveman風(fēng)格；

• ultra：大量縮寫，如DB、auth、config、req、res、fn、impl；盡量去掉連接詞；用箭頭表達(dá)因果，如「X→Y」；能用一個詞說明，就不用兩個詞。

舉個例子：

lite：「連接池會復(fù)用已經(jīng)打開的數(shù)據(jù)庫連接，而不是每次請求都新建一個，從而避免重復(fù)握手開銷。」

full：「連接池復(fù)用已打開的DB連接。不是每個請求都新建。省掉握手開銷。」

ultra：「連接池=復(fù)用DB連接。跳過握手→高并發(fā)更快。」

當(dāng)然，遇到安全警告、不可逆操作確認(rèn)、多步驟流程、或用戶明顯已經(jīng)困惑時，清晰表達(dá)仍然優(yōu)先。這也是SKILL.md里明確寫出的例外邏輯。

沒有模型架構(gòu)改動，沒有推理機(jī)制層面的壓縮，caveman的本質(zhì)就是一條精心編寫的system prompt，約束的是AI的輸出風(fēng)格。

更關(guān)鍵的一點(diǎn)：作者Julius Brussee本人在HN討論帖里主動澄清了，這個skill不針對hidden reasoning tokens和thinking tokens。

模型在后臺「想」的過程并不會因為caveman自動變短，它主要壓縮的是最后說出來的那部分。

Anthropic官方文檔也提到，skills的名稱和描述本身會占用上下文預(yù)算。

換句話說，加載caveman這個skill本身就要消耗token。

所以端到端的真實成本節(jié)省，未必等于README里那個醒目的「75%」。

因此，caveman很可能顯著壓縮了可見輸出長度，但這不應(yīng)被直接理解為同等比例的總成本下降。

README里的75%，到底靠不靠譜？

從倉庫公開內(nèi)容看，作者確實提供了benchmark腳本，也在README里列出了若干任務(wù)的token對比，區(qū)間從22%到87%，平均65%。

但截至目前，公開倉庫里能直接看到的是測試腳本和示例表格；外界仍難以僅憑倉庫當(dāng)前內(nèi)容完整復(fù)核每一項結(jié)果的復(fù)現(xiàn)實驗鏈條。

作者在HN帖子里表示：這只是初步測試，不是嚴(yán)格的基準(zhǔn)測試。

不過，「簡潔表達(dá)是否會傷害AI性能」這個問題，學(xué)術(shù)界確實有人研究過。

https://arxiv.org/pdf/2401.05618

2024年的論文《The Benefits of a Concise Chain of Thought on Problem-Solving in Large Language Models》顯示：

當(dāng)研究者要求模型使用更簡潔的推理鏈時，GPT-3.5和GPT-4的平均回答長度下降了48.70%，而整體解題能力幾乎沒有明顯下降；但在數(shù)學(xué)題上，GPT-3.5的表現(xiàn)平均下降了27.69%。

2026年的論文《Brevity Constraints Reverse Performance Hierarchies in Language Models》則更進(jìn)一步指出：

在部分基準(zhǔn)上，對大模型加入簡潔約束，準(zhǔn)確率可提升26個百分點(diǎn)，甚至可能改變不同規(guī)模模型之間原本的表現(xiàn)排序。

https://arxiv.org/pdf/2604.00025

以上兩篇論文，為「簡潔未必傷性能」提供了研究背景。

但必須說清楚：它們研究的是brevity作為通用提示策略的效果，不是對caveman這個GitHub倉庫的專項評測。

README引用這些研究，最多只能說明它的思路并非毫無理論背景，不能直接當(dāng)作對項目自身效果的嚴(yán)格驗證。

Claude Code的插件生態(tài)

開始起來了

caveman能火，還有一個背景原因：

Anthropic已經(jīng)為Claude Code提供了相對完整的skill與plugin機(jī)制。

https://code.claude.com/docs/en/skills

根據(jù)Anthropic官方文檔，開發(fā)者只需創(chuàng)建一個SKILL.md文件，Claude就能把它識別為skill；其中description用來決定何時自動加載，name則會變成可直接觸發(fā)的斜杠命令。

官方文檔還明確寫了plugin級skill的路徑結(jié)構(gòu)是 /skills/ /SKILL.md 。

而caveman倉庫中，確實能看到.claude-plugin、plugins/caveman、skills/caveman等目錄，說明它不是一個停留在「幾句提示詞」層面的玩具，而是按照Claude Code的skill/plugin機(jī)制包裝出來的擴(kuò)展。

這也意味著，開發(fā)者確實可以通過一個SKILL.md，在不改模型底層的前提下，改變Claude Code在特定任務(wù)中的調(diào)用方式和輸出風(fēng)格。

某種意義上，這已經(jīng)有點(diǎn)像早期VS Code擴(kuò)展生態(tài)：

先有一批看起來輕量、甚至帶點(diǎn)玩笑感的擴(kuò)展冒出來，隨后才逐漸長成更嚴(yán)肅、更細(xì)分的工作流工具。

開發(fā)者苦AI廢話久矣

回到那個最初的問題：caveman到底有沒有用？

如果把它當(dāng)成一個嚴(yán)格意義上的「省錢工具」，那就需要更謹(jǐn)慎。

它壓縮的只是可見輸出文本，并不觸及hidden reasoning tokens，而后者往往才是Claude Code成本的大頭。

再加上skill本身也會占用上下文，端到端算下來，真實節(jié)省大概率到不了75%。

真正想優(yōu)化token成本，關(guān)鍵也不在這里。模型分層調(diào)用、上下文窗口管理、prompt工程、緩存策略，這些才是真正的主戰(zhàn)場。

但caveman真正值得關(guān)注的地方，不在于它是不是開出了一劑完美藥方，而在于它本身就是一個信號。

當(dāng)一個開發(fā)者把「讓AI少說廢話」這件事做成插件，放到GitHub上，被上千人認(rèn)真討論，在HN上爆火，事情的重點(diǎn)就已經(jīng)變了。

它說明，AI工具的冗長，不再只是一個可以忍受的小毛病，而是嚴(yán)重到用戶開始自己動手修正的程度。

實際上，開發(fā)者們在情緒上早就已經(jīng)破防了：去各大社區(qū)看一眼，滿屏皆是對AI 廢話的哀嘆抱怨：

我只需要兩行正則代碼，它非要給我寫5個自然段的正則歷史散文；

求求你別再對我說「Certainly! Here is the……」了，直接給我報錯或者給我代碼不行嗎？

在Hacker News上，這種哀嘆和抱怨更是與使用成本掛鉤：

我簡直是在花15刀/100萬Token的價錢，來閱讀AI對我的道歉和寒暄。

只因為要改一個標(biāo)點(diǎn)，它竟然把整個800行的文件重新輸出了一遍，看著API余額肉眼可見地往下掉，我都快破產(chǎn)了。

當(dāng)大家寧愿讓AI像「山頂洞人」一樣說話，也不愿意繼續(xù)為冗余輸出多付token成本時，真正應(yīng)當(dāng)反思的也許是那些主流AI大廠。

為什么直到今天，他們還沒有把「克制」做成一種基礎(chǔ)能力。

不要別總盯著算力生意，而是要認(rèn)真想想，用戶到底為什么越來越受不了這些沒必要的輸出。

參考資料：

https://github.com/JuliusBrussee/caveman

https://code.claude.com/docs/en/skills

https://news.ycombinator.com/item?id=47647455