最近读到 Y Combinator 掌门人 Garry Tan 的一篇长文，聊的是 AI 编程效率差异背后的真正原因。Steve Yegge 说，现在用 AI 编码 Agent 的人，生产力是用普通 AI 聊天工具的 10 到 100 倍，是 2005 年谷歌工程师的大约 1000 倍。Garry Tan 说，这个数字他亲眼见过，也亲身经历过。但大多数人听到这个数字的时候，第一反应都是：一定是模型更聪明了吧？参数更多了吧？

不是这样的。那些效率提升 2 倍的人和提升 100 倍的人，用的是同一个模型。差距的根源在于架构，而且这个架构的核心思想简单到可以写在一张卡片上。

一、秘密藏在「包裹模型的那层壳」里

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

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

这层壳，叫做 harness（缰绳）。每一个做 AI 产品的人都应该问自己一个问题：什么东西该放进缰绳里，什么东西该留在外面？

Garry Tan 给出的答案有一个非常明确的形状，他管它叫：thin harness, fat skills。薄缰绳，厚技能。

二、五个关键定义，撑起整套架构

文章的核心框架由五个概念组成，每一个都值得细说。

1. Skill 技能文件：教 AI「怎么做事」的说明书

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

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

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

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

这个思路其实对我们每个人都很有启发。很多人用 AI 的方式是每次都从零开始描述需求，但如果你把自己反复做的事情提炼成一套固定流程，每次只需要换掉里面的具体内容，效率会有质的飞跃。这就好比一个经验丰富的律师，他处理每个案子用的分析框架是一样的，变的只是案件事实。

2. Harness 缰绳：越薄越好

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

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

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

3. Resolver 路由器：让 AI 在对的时间看到对的文档

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

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

Garry Tan 坦白说，他自己的 [CLAUDE.md](http://t.cn/AXLo0vJd) 曾经写了两万行，把他遇到过的每一个坑、每一个模式、每一条经验全塞进去了。结果完全适得其反，模型的注意力严重退化，Claude Code 甚至直接告诉他：你得砍掉这些内容。最后他精简到大约 200 行，只放指向各个文档的索引。Resolver 在需要的时候才加载对应的内容。两万行知识，按需调用，不污染上下文窗口。

这个教训特别值得记住。很多人写提示词恨不得把所有要求一股脑全塞进去，觉得说得越多 AI 就越听话。实际上恰恰相反，当所有内容都被标记为「重要」的时候，等于什么都不重要了。给 AI 一张地图，比给它一本千页手册有用得多。

4. 潜在空间 vs 确定性空间：把对的工作交给对的一方

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

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

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

Garry Tan 举了一个特别生动的例子：让大模型给 8 个人安排一桌晚餐座位，考虑性格和社交关系，它做得非常好。但让它给 800 个人安排座位，它会编造出一个看起来合理但完全错误的方案。因为 800 人的座位安排本质上是一个组合优化问题，属于确定性空间的工作，硬塞给潜在空间来做，一定会出问题。

最差的系统就是把错误的工作放在错误的一边。最好的系统对这条线毫不含糊。

5. Diarization 档案化：让 AI 真正「读懂」一个对象

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

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

三、三层架构：一张图看懂全局

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

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

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

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

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

四、一个真实案例：6000 个创业者的活动匹配

Garry Tan 用了一个 YC 正在做的真实项目来展示这套架构的威力。

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

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

但模型可以。

首先是档案化。一个叫 /enrich-founder 的 skill 拉取所有数据源，做深度画像，并且标注创始人「说的」和「实际在做的」之间的差距。比如：

Maria Santos，公司叫 Contrail，她说自己在做「AI Agent 的 Datadog」，但 80% 的代码提交都在计费模块里。她实际上是在做一个披着可观测性外衣的 FinOps 工具。

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

然后是匹配。同一个匹配 skill 的三次不同调用，产生三种完全不同的策略：分组讨论匹配 1200 人按行业聚类，午餐匹配 600 人做跨行业的随机碰撞，实时匹配处理当前在场的人做最近邻配对。

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

最精彩的是学习闭环。活动结束后，一个 /improve skill 读取满意度调查，重点分析那些评价「还行」的反馈，提取模式，然后把新规则写回匹配 skill 里。比如：当参会者说「AI 基础设施」但创业项目 80% 以上是计费代码时，归类为金融科技。当同组的两个人已经认识时，降低他们的匹配权重，优先安排新的连接。

这些规则被写回 skill 文件，下一次运行自动生效。第一次活动 12% 的「还行」评价，下一次降到了 4%。skill 自己学会了「还行」到底意味着什么，系统变强了，没有人重写过任何代码。

五、一条铁律：不允许做一次性的工作

Garry Tan 分享了他给自己 AI 助手定的一条规矩，在社交媒体上引起了很大的共鸣：

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

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

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

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

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