编者按：当「更强模型」成为行业的默认答案，这篇文章给出了一个不同的判断：真正拉开 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 倍。」

这不是夸张的说法。我亲眼见过，也亲身经历过。但人们一听到这样的差距，往往会归因到错误的方向：更强的模型、更聪明的 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 的输出，能捕捉到关键词搜索完全无法发现的信息：

这种「说法 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 engineering 的技巧。

其实不是，这就是前面讲的那套架构。你写下的每一个 skill，都是对系统的永久升级。它不会退化，不会遗忘。它会在凌晨三点自动运行。而当下一代模型发布时，所有 skill 会瞬间变强——latent 部分的判断能力提升，而 deterministic 部分依然稳定可靠。

这就是 Yegge 所说的 100 倍效率的来源。

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

系统会复利增长。搭建一次，长期运行。