# 薄缰绳，厚技能（Thin Harness, Fat Skills）

YC 的 CEO Garry Tan 发了一条推特长文章，叫：《Thin Harness, Fat Skills》，我感觉很有价值，说的很有道理，在这里原封不动的翻译给大家。

原文如下：

Steve Yegge 说，现在用 AI 编码 Agent 的人，生产力是用 Cursor 和普通聊天式 AI 的 10 到 100 倍，大约是 2005 年谷歌工程师的 1000 倍。

这个数字是真的。我亲眼见过，也亲身经历过。但大多数人听到这个数字，第一反应都想错了方向：模型更强了，Claude 更聪明了，参数更多了。事实上，效率翻 2 倍的人和翻 100 倍的人，用的是同一个模型。差距不在智能，在架构。而且这个架构的核心，一张卡片就能写完。

2026 年 3 月 31 日，Anthropic 不小心把 Claude Code 的全部源码发到了 npm 上，总共 51.2 万行。我读了。它印证了我在 YC 一直在教的东西：秘密不在模型本身，在于包裹模型的那层东西。

实时的代码仓库上下文、提示词缓存、专门定制的工具、上下文膨胀控制、结构化的会话记忆、并行的子 Agent……这些东西没有一个能让模型变聪明，但它们能确保模型在每一步推理时，看到最精准的信息，同时不被噪音淹没。

这层包裹叫做 harness，也就是「缰绳」。每一个做 AI 的人都该问自己：什么该放进缰绳里，什么该留在外面？这个问题有一个很明确的答案。我管它叫：thin harness, fat skills。薄缰绳，厚技能。

瓶颈从来都不是模型的智力。模型已经会推理、会综合、会写代码了。它之所以会失败，是因为它不了解你的数据，你的数据结构、你的代码规范、你这个问题特有的形状。以下五个定义可以解决这个问题。

## 1. Skill 技能文件

Skill 是一份可以反复使用的 markdown 文档，它教模型怎么做一件事。注意，它教的是方法和流程，具体做什么由用户来定。

这里有一个大多数人没想到的关键点：一个 skill 文件的工作方式就像一个函数调用。它接受参数，你用不同的参数去调用它，同一套流程就能产生截然不同的能力。

举个例子。有一个叫 /investigate 的 skill，总共七个步骤：界定数据范围、建立时间线、为每份文档做摘要标注、综合分析、正反两面论证、标注引用来源。它接受三个参数：调查对象（TARGET）、调查问题（QUESTION）、数据集（DATASET）。把它指向一个安全科学家和 210 万封内部邮件，它就变成了一个医学研究分析师，判断一个举报人是否被打压。把它指向一个空壳公司和联邦选举委员会的财务申报，它就变成了一个法务调查员，追踪协调的竞选捐款。

同一个 skill，同样的七个步骤，同一个 markdown 文件。Skill 描述的是一套判断流程，调用时传入的参数决定了它面对的世界。

这不是提示词工程。这是软件设计，只不过用 markdown 当编程语言，用人类的判断力当运行时。事实上，markdown 比死板的源代码更适合封装能力，因为它用模型本身就在思考的语言来描述流程、判断和上下文。

## 2. Harness 缰绳

Harness 就是运行大模型的那个程序。它只做四件事：循环运行模型、读写你的文件、管理上下文、确保安全。就这些。这就是「薄」的含义。

最常见的反面教材是缰绳很厚、技能很薄。你肯定见过这种情况：40 多个工具定义吃掉了一半的上下文窗口，一个「万能工具」每次调用要花 2 到 5 秒的 MCP 往返，每个 REST API 端点都被包装成一个单独的工具。三倍的 token 消耗，三倍的延迟，三倍的失败率。

你真正需要的是专门定制的、快速的、窄的工具。比如一个 Playwright 命令行工具，每个浏览器操作 100 毫秒搞定，对比一个 Chrome MCP 截图加查找加点击加等待加读取要花 15 秒，快了 75 倍。在这个时代，软件不需要做得多精致。做到刚好够用就行，多一点都不要。

## 3. Resolver 路由器

Resolver 是一张上下文的路由表。当出现 X 类型的任务时，先加载 Y 文档。

Skill 告诉模型怎么做，Resolver 告诉模型该先看什么、什么时候看。比如一个开发者改了一段提示词，没有 Resolver 的话他可能直接就提交了。有了 Resolver，模型会先去读 docs/EVALS.md，里面写着：先跑评估测试，对比分数，如果准确率下降超过 2% 就回滚并排查。开发者可能根本不知道有这个评估流程，但 Resolver 在对的时刻加载了对的上下文。

Claude Code 内置了一个 Resolver。每个 skill 都有一个描述字段，模型会自动把用户的意图和 skill 的描述做匹配。你根本不需要记住 /ship 这个命令的存在，描述本身就是路由。

说个真事：我的 [CLAUDE.md](http://t.cn/AXLo0vJd) 曾经写了两万行。我遇到过的每一个坑、每一个模式、每一条经验全塞在里面了。荒谬至极。模型的注意力严重退化，Claude Code 甚至直接跟我说：你得砍掉这些内容。最后我精简到大约 200 行，只放指向各个文档的索引。Resolver 在需要的时候才加载对应的内容。两万行知识，按需调用，不污染上下文窗口。

## 4. 潜在空间 vs 确定性空间

你系统里的每一个步骤，要么属于潜在空间（latent），要么属于确定性空间（deterministic）。搞混这两者，是 Agent 设计中最常见的错误。

潜在空间是智能所在的地方。模型阅读、理解、判断、综合、识别模式，这些都是它的主场。

确定性空间是信任所在的地方。同样的输入，永远产生同样的输出。SQL 查询、编译后的代码、数学运算，这些该交给传统程序来做。

大模型可以给 8 个人安排一桌晚餐座位，把性格和社交关系都考虑进去，做得非常好。但让它给 800 个人安排座位，它会编造出一个看起来合理但完全错误的方案。因为这本质上是一个组合优化问题，属于确定性空间的工作，硬塞给潜在空间来做，一定会出问题。最差的系统就是把错误的工作放在错误的一边，最好的系统对这条线毫不含糊。

## 5. Diarization 档案化

Diarization 是让 AI 在真实知识工作中发挥价值的关键步骤。模型把关于一个对象的所有资料全部读完，然后写出一份结构化的画像，把几十甚至上百份文档浓缩成一页判断。

没有任何 SQL 查询能产出这个东西，没有任何 RAG 检索管道能产出这个东西。模型必须真正去阅读，在脑子里同时容纳矛盾的信息，注意到什么东西在什么时候发生了变化，然后综合出结构化的洞察。这就是数据库查询和分析师简报之间的差别。

## 三层架构

这五个概念组合在一起，形成了一个简洁的三层架构。

最上面是厚技能层：用 markdown 编写的流程文档，编码了判断力、工作流程和领域知识。90% 的价值都在这里。

中间是薄缰绳层：大约 200 行代码。JSON 进，文本出。默认只读。

最下面是应用层：数据库查询、文档读取、搜索、时间线构建，这些确定性的基础设施。

原则是有方向性的：把智能往上推到技能层，把执行往下推到确定性工具层，让缰绳保持轻薄。这样做的好处是，每次模型升级，所有技能都自动变强，而确定性层始终稳定可靠。

## 实战：YC 的 6000 人活动匹配

下面用一个我们在 YC 正在做的真实项目，展示这五个概念如何协同运作。

Chase Center，2026 年 7 月，6000 个创业者参加 Startup School。每个人都有结构化的申请表、问卷回答、一对一顾问聊天记录，还有公开信号：X 上的帖子、GitHub 提交记录、Claude Code 的使用记录（能看出他们出活有多快）。

传统做法：15 个人的团队读申请、凭直觉判断、更新表格。200 个人的时候还行，6000 个人就彻底崩了。没有人类能在工作记忆里同时装下这么多画像，然后发现最适合「AI Agent 基础设施」分组的三个人，分别是拉各斯的开发工具创始人、新加坡的合规创始人和布鲁克林的命令行工具创始人，而他们三个在各自的一对一聊天中用不同的词描述了同一个痛点。

但模型可以。方法如下。

**档案化。** 一个叫 /enrich-founder 的 skill 拉取所有数据源，做深度画像，并且标注创始人「说的」和「实际在做的」之间的差距。确定性层负责 SQL 查询、GitHub 统计、对 demo 网址做浏览器测试、社交信号抓取、CrustData 查询。定时任务每晚跑一次，6000 份画像，始终保持最新。

档案化的输出能捕捉到任何关键词搜索都找不到的东西：

> 创始人：Maria Santos \
> 公司：Contrail (contrail.dev）\
> 自述：「AI Agent 的 Datadog」\
> 实际在做的：80% 的代码提交都在计费模块。她其实是在做一个披着可观测性外衣的 FinOps 工具。

这种「说的」和「做的」之间的差距，需要同时读 GitHub 提交历史、申请表和顾问聊天记录，然后在脑子里把三者对照起来才能发现。向量相似度搜索找不到这个，关键词过滤也找不到。模型必须读完整份画像，然后做出判断。（这恰恰是最适合放在潜在空间的决策！）

**匹配。** 这里就是 skill 作为函数调用的精彩之处。同一个匹配 skill 的三次不同调用，三种完全不同的策略：

/match-breakout 处理 1200 个创始人，按行业亲和度聚类，每间会议室 30 人。向量嵌入加确定性分配。/match-lunch 处理 600 人，做跨行业的随机碰撞匹配，每桌 8 人，不重复。大模型负责发明主题，然后确定性算法负责分配座位。/match-live 处理当前在场的人，最近邻向量匹配，200 毫秒出结果，一对一配对，排除已经见过面的人。

模型还能做出聚类算法永远做不到的判断：「Santos 和 Oram 都是 AI 基础设施方向，但他们不是竞争对手，一个做成本归因，一个做编排，应该放在同一组。」或者：「Kim 申请的时候写的是『开发工具』，但他在一对一聊天里透露他其实在做 SOC2 的合规自动化，应该归到金融科技/监管科技组。」

没有任何向量嵌入能捕捉到 Kim 的重新分类。模型必须读完他的完整画像。

**学习闭环。** 活动结束后，一个 /improve skill 读取 NPS 调查，重点分析那些评价「还行」的反馈。注意，不是差评，是「还行」，也就是系统差一点就做好了但没做到的地方。它从中提取模式，然后把新规则写回匹配 skill 里：

> 当参会者说「AI 基础设施」但创业项目 80% 以上是计费代码时：归类为金融科技，不归 AI 基础设施。\
> 当同组的两个人已经认识时：降低匹配权重，优先安排新的连接。

这些规则被写回 skill 文件，下一次运行自动生效。Skill 自己改写了自己。

7 月的活动：12% 的「还行」评价。下一次活动：4%。Skill 文件学会了「还行」到底意味着什么，系统变强了，没有人重写过任何代码。

同样的模式可以迁移到任何地方：检索、阅读、档案化、计数、综合。然后：调查、诊断、档案化、改写 skill。

如果你想知道 2026 年最有价值的循环是什么，就是这些。它们可以应用到所有知识工作的每一个领域和场景。

## 不允许做一次性的工作

我之前在推特上分享了一条我给自己 OpenClaw 定的规矩，引起的共鸣超出了我的预期：

> 你不许做一次性的工作。如果我让你做一件事，而这件事以后还会再做，你必须：先手动做 3 到 10 个样本，给我看结果。如果我认可，就把它固化成一个 skill 文件。如果它应该自动运行，就挂到定时任务上。检验标准是：如果我需要跟你要同一个东西第二次，你就失败了。

一千个赞，两千五百个收藏。很多人以为这是一个提示词技巧。不是的。这就是我一直在讲的这套架构。你写的每一个 skill 都是对系统的永久升级。它不会退化，不会遗忘，凌晨三点你睡着的时候它照样在跑。等下一代模型发布，每个 skill 里的判断步骤自动变强，而确定性步骤依然稳如磐石。

这就是 Yegge 说的 100 倍效率的来源。靠的不是更聪明的模型，靠的是厚技能、薄缰绳，以及把一切都固化下来的纪律。

系统会复利增长。搭建一次，永远运转。

#科技先锋官##How I AI#