瘦Harness，胖Skill：100倍AI生產力的真正來源

原文標題：Thin Harness, Fat Skills
原文作者：Garry Tan
編譯：Peggy，BlockBeats

編者按：當「更強模型」成為行業的默認答案，這篇文章給出了一個不同的判斷：真正拉開 10 倍、100 倍甚至 1000 倍生產力差距的，並不是模型本身，而是圍繞模型構建的一整套系統設計。

本文作者 Garry Tan，現任 Y Combinator 總裁兼 CEO，長期深耕 AI 與早期創業生態。他提出「fat skills + thin harness」這一框架，將 AI 應用拆解為技能、運行框架、上下文路由、任務分工與知識壓縮等關鍵組件。

在這一體系下，模型不再是能力的全部，而只是系統中的執行單元；真正決定輸出質量的，是你如何組織上下文、沉澱流程，以及如何劃清「判斷」與「計算」的邊界。

更重要的是，這套方法並非停留在概念層面，而是在真實場景中得到驗證：面對數千名創業者的數據處理與匹配任務，系統通過「讀取—歸整—判斷—寫回」的循環，實現了接近人類分析師的能力，並在無需重寫代碼的情況下持續自我優化。這種「會學習的系統」，讓 AI 從一次性工具，轉變為具備複利效應的基礎設施。

由此，文章給出的核心提醒也變得清晰：在 AI 時代，效率差距不再取決於你是否使用最先進的模型，而在於你是否構建了一套能夠持續積累能力、自動進化的系統。

以下為原文：

Steve Yegge 說，使用 AI 編程代理的人，「效率是那些只用 Cursor 和聊天工具寫程式碼工程師的 10 倍到 100 倍，大約是 2005 年 Google 工程師的 1000 倍。」

注：Steve Yegge 是一位在矽谷頗有影響力的軟體工程師、技術部落客和工程文化評論者，以犀利、長篇、帶有強烈個人風格的技術文章聞名。他曾在 Amazon、Google 等公司擔任資深工程師；後來加入 Salesforce，再到初創公司與 AI 相關領域；同時也是早期 Dart 專案的推動者之一。

這不是誇張的說法。我親眼見過，也親身經歷過。但人們一聽到這樣的差距，往往會歸因到錯誤的方向：更強的模型、更聰明的 Claude、更多的參數。

實際上，效率提升 2 倍的人和提升 100 倍的人，用的是同一套模型。差別不在「智能」，而在「架構」，而且這種架構簡單到可以寫在一張卡片上。

Harness（運行框架）才是產品本身。

2026 年 3 月 31 日，Anthropic 一次意外，把 Claude Code 的完整源代碼發布到了 npm 上——總計 51.2 萬行。我通讀了一遍。這驗證了我一直在 YC（Y Combinator）講的那件事：真正的秘密不在模型，而在「包裹模型的那一層」。

實時的代碼倉庫上下文、Prompt 緩存、為特定任務設計的工具、盡可能壓縮冗余上下文、結構化的會話記憶、並行運行的子代理——這些都不會讓模型變得更聰明。但它們能在「正確的時間」給模型「正確的上下文」，同時避免被無關訊息淹沒。

這一層「包裹」，就叫做 harness（運行框架）。而所有 AI 構建者真正應該問的問題是：哪些東西應該放進 harness，哪些應該留在外面？

這個問題其實有一個非常具體的答案——我稱之為：薄框架（thin harness），厚能力（fat skills）。

五個定義

瓶頸從來不在模型的智能上。模型其實早就知道如何推理、綜合信息、寫代碼。

它們之所以會失敗，是因為它們不理解你的數據——你的 schema、你的約定、你這個問題具體是什麼形狀。而下面這五個定義，恰恰就是為了解決這個問題。

1、Skill file（技能文件）

技能文件，是一份可復用的 markdown 文檔，用來教模型「怎麼做一件事」。注意，不是告訴它「要做什麼」——那部分由用戶提供。技能文件提供的是過程。

大多數人忽略的關鍵點在於：技能文件其實就像一次方法呼叫。它可以接收參數。你可以用不同的參數去呼叫它。同一套流程，因為傳入參數不同，就能展現出截然不同的能力。

舉個例子，有一個叫 /investigate 的技能。它包含七個步驟：定義數據範圍、搭建時間線、為每份文件做 diarize、綜合歸納、從正反兩面論證、引用來源。它接收三個參數：TARGET、QUESTION 和 DATASET。

如果你把它指向一位安全科學家和 210 萬封取證郵件，它就會變成一個醫學研究分析員，去判斷一位吹哨人是否遭到了壓制。

如果你把它指向一家殼公司和美國聯邦選舉委員會（FEC）的申報文件，它又會變成一名法務取證調查員，去追踪協同行動式的政治捐款。

還是同一個技能。還是同樣七個步驟。還是同一份 markdown 文件。技能描述的是一種判斷流程，而真正把它落到現實世界裡的，是調用時傳入的參數。

這不是 prompt engineering，而是軟體設計：只不過這裡用 markdown 當編程語言，用人的判斷力當運行時環境。事實上，markdown 甚至比剛性的源代碼更適合封裝能力，因為它描述的是過程、判斷和上下文，而這些恰恰是模型最「懂」的語言。

2、Harness（執行框架）

Harness，就是驅動 LLM 執行的那層程式。它只做四件事：讓模型在迴圈中執行、讀寫你的檔案、管理上下文，以及執行安全約束。

就這些。這就是「thin（薄）」。

反面模式則是：胖 harness，瘦 skills。

你一定見過這種東西：40 多個工具定義，光說明就吃掉一半上下文視窗；一個全能 God-tool，跑一趟 MCP 來回要 2 到 5 秒；再或者，把 REST API 的每個 endpoint 都包成單獨工具。結果就是，token 用量變成三倍，延遲變成三倍，失敗率也變成三倍。

真正理想的做法，是使用為目的而生、快速且窄功能的工具。

比如一個 Playwright CLI，每個瀏覽器操作只花 100 毫秒；而不是一個 Chrome MCP，做一次 screenshot → find → click → wait → read 要 15 秒。前者快了 75 倍。

現在的軟體已經沒必要再「精雕細琢到臃腫」了。你該做的是：只構建你真正需要的東西，而且僅此而已。

3、Resolver（解析器）

resolver，本質上就是一張上下文路由表。當任務類型 X 出現時，優先加載文件 Y。skills 告訴模型「怎麼做」；resolvers 告訴模型「什麼時候該加載什麼」。

比如，一個開發者改了某條 prompt。沒有 resolver 的時候，他可能改完就直接發版了。有 resolver 的時候，模型會先去讀 docs/EVALS.md。而這個文件裡寫著：先跑評估套件，對比前後得分；如果準確率下降超過 2%，就回滾並排查原因。這個開發者原本甚至不知道還有評估套件的存在。是 resolver 在正確的時刻，把正確的上下文加載了進來。

Claude Code 內置了一個 resolver。每個 skill 都有一個 description 字段，模型會自動把用戶意圖與 skill 的描述進行匹配。你根本不需要記住 /ship 這個技能是否存在——description 本身就是 resolver。

坦白說一句：我以前的 CLAUDE.md 足足有 2 萬行。所有怪癖、所有模式、所有我遇到過的經驗教訓，統統塞了進去。荒唐至極。模型的注意力質量明顯下降。Claude Code 甚至直接讓我把它砍掉。

最後的修復方案，大概只有 200 行——只保留若干文檔指針。真正需要哪份文檔，就讓 resolver 在關鍵時刻去加載哪一份。這樣一來，2 萬行知識仍然可以隨取隨用，卻不會污染上下文窗口。

4、Latent 與 deterministic（潛在空間與確定性）

你的系統裡，每一步不是屬於這一類，就是屬於那一類。而把這兩者混淆，是 agent 設計裡最常見的錯誤。

·Latent space（潛在空間），是智能所在的地方。模型在這裡閱讀、理解、判斷、決策。這裡處理的是：判斷、綜合、模式識別。

·Deterministic（確定性），是可信性所在的地方。相同輸入，永遠得到相同輸出。SQL 查詢、編譯後的代碼、算術運算，都屬於這一側。

一个 LLM 可以幫你給 8 個人安排晚宴座位，同時考慮每個人的性格和社交關係。但你要它給 800 個人排座位，它就會一本正經地胡編出一張「看起來很合理、實際上完全錯誤」的座位表。因為那已經不是潛在空間該處理的問題了，而是一個被硬塞進了 latent space 的決定性問題——組合優化問題。

最糟糕的系統，總是在這條分界線兩邊把工作放錯地方。最好的系統，則會非常冷酷地劃清邊界。

5、Diarization（文件歸整 / 主題畫像）

diarization 這一步，才是真正讓 AI 對現實知識工作產生價值的關鍵。

它的意思是：模型把一個主題相關的所有材料都讀一遍，然後寫出一份結構化畫像。用一頁紙，把幾十份甚至上百份文件中的判斷濃縮出來。

這不是 SQL 查詢能產出的東西。這也不是 RAG 流水線能產出的東西。模型必須真的去讀、把相互矛盾的信息同時放在腦子裡、注意到哪些東西發生了變化、什麼時候發生了變化，然後把這些內容綜合成結構化的 intelligence。

這就是資料庫查詢和分析師簡報之間的區別。

這套架構

這五個概念，可以組合成一個非常簡單的三層架構。

·最上層是厚技能（fat skills）：用 markdown 寫成的流程，承載判斷、方法論和領域知識。90% 的價值，都在這一層。
·中間是一層薄的 CLI harness：大約 200 行代碼，輸入 JSON，輸出文本，默認只讀。
·最底層是你的應用系統：QueryDB、ReadDoc、Search、Timeline——這些是決定性的基礎設施。

核心原則是有方向的：把「智能」儘量往上推到 skills；把「執行」儘量往下壓到決定性工具；讓 harness 保持輕薄。

這樣做的結果是：每當模型能力提升，所有技能都會自動變強；而底層的決定性系統，始終保持穩定可靠。

會學習的系統

下面我用一个我们在 YC 正在构建的真实系統，來展示這五個定義是如何一起工作的。

2026 年 7 月，Chase Center。Startup School 有 6000 名創始人參加。每個人都有結構化申請材料、問卷回答、與導師 1:1 對話的轉錄，以及公開信號：X 上的發帖、GitHub 提交記錄、Claude Code 的使用記錄（可以看出他們的開發速度）。

傳統做法是：15 個人的專案團隊逐份閱讀申請，憑直覺判斷，然後更新一張表格。

這個方法在 200 人規模時還能運轉，但在 6000 人時就徹底失效了。沒有人類能在腦中同時容納這麼多畫像，並意識到：AI agent 基礎設施方向最優秀的三個候選人，分別是拉各斯的開發工具創始人、新加坡的合規創業者、以及布魯克林的 CLI 工具開發者——而他們在不同的 1:1 對話中，用完全不同的表述描述了同一個痛點。

模型可以做到。方法如下：

Enrichment（資訊增強）

有一個技能叫 /enrich-founder，它會拉取所有數據源，做資訊增強、diarization，並標出「創始人說的」和「實際在做的」之間的差異。

底層的確定性系統負責：SQL 查詢、GitHub 資料、Demo URL 的瀏覽器測試、社交信號抓取、CrustData 查詢等。一個定時任務每天運行一次。6000 個創始人畫像始終保持最新。

diarization 的輸出，能捕捉到關鍵詞搜索完全無法發現的信息：

創始人：Maria Santos 公司：Contrail（contrail.dev） 自述："AI agent 的 Datadog" 實際在做：80% 的代碼提交集中在計費模塊 → 本質是在做一個披著可觀測外衣的 FinOps 工具

這種「說法 vs 實際行為」的差異，需要同時閱讀 GitHub 提交歷史、申請材料和對話記錄，並在腦中整合。沒有任何 embedding 相似度搜索能做到這一點，關鍵詞過濾也不行。模型必須完整閱讀，然後做出判斷。（這正是應該放在 latent space 的任務！）

匹配（Matching）

这是「技能 = 方法调用」发挥威力的地方。

同一个匹配技能，调用三次，可以产生完全不同的策略：

/match-breakout：处理 1200 人，按领域聚类，每组 30 人（embedding + 确定性分配）

/match-lunch：处理 600 人，跨领域「偶然匹配」，每桌 8 人且不重复——由 LLM 先生成主题，再由确定性算法安排座位

/match-live：处理现场实时参与者，基于最近邻 embedding，200ms 内完成 1 对 1 匹配，并排除已经见过的人

而模型还能做出传统聚类算法无法完成的判断：

「Santos 和 Oram 都属于 AI 基础设施，但不是竞争关系——Santos 做成本归因，Oram 做编排。应该放在同一组。」
「Kim 申请时写的是开发者工具，但 1:1 对话显示他在做 SOC2 合规自动化。应重新归类到 FinTech / RegTech。」

这种重新分类，是 embedding 完全捕捉不到的。模型必须读完整个画像。

學習循環（learning loop）

活動結束後，一个 /improve 技能會讀取 NPS 調研結果，對那些「還行」的反饋做 diarization——不是差評，而是「差一點就好」的那些——並提取模式。

然後，它會提出新規則，並寫回匹配技能中：

當參與者說「AI infrastructure」，但其代碼 80% 以上為計費模塊：
→ 分類為 FinTech，而非 AI Infra

當同組兩人已經認識：
→ 降低匹配權重
优先引入新關係

這些規則會被寫回 skill 文件。下一次運行時自動生效。技能在「自我改寫」。7 月活動，「還行」評分佔 12%；下一場活動降到 4%。

skill 檔案學會了「還行」意味著什麼，而系統在沒有人重寫程式碼的情況下變得更好。

這種模式可以遷移到任何領域：

檢索 → 閱讀 → diarize → 計數 → 綜合

然後：調研 → 調查 → diarize → 重寫 skill

如果你要問 2026 年最有價值的迴圈是什麼，就是這一套。它可以應用到幾乎所有知識工作場景。

技能是永久升級

我最近在 X 上發過一條給 OpenClaw 的指令，反應比預期大：

Prompt：你不允許做一次性工作。 如果我讓你做一件未來還會重複的事，你必須： 第一次先手動處理 3 到 10 個樣本，給我看結果； 如果我認可，就把它寫成一個 skill 檔案； 如果它應該自動運行，就加到定時任務裡。判斷標準是：如果我需要問第二次，就說明你失敗了。

這條內容獲得了上千點讚和兩千多收藏。很多人以為這是 prompt engineering 的技巧。

其實不是，這就是前面講的那套架構。你寫下的每一個 skill，都是對系統的永久升級。它不會退化，不會遺忘。它會在凌晨三點自動運行。而當下一代模型發布時，所有 skill 會瞬間變強——latent 部分的判斷能力提升，而 deterministic 部分依然穩定可靠。

這就是 Yegge 所說的 100 倍效率的來源。

不是更聰明的模型，而是：厚技能、薄框架（Thin Harness, Fat Skills），以及把一切固化為能力的紀律。

系統會複利增長。搭建一次，長期運行。

[原文連結]