最近读到 Y Combinator 掌门人 Garry Tan 的一篇长文，主题是 AI 编程效率差异背后的真相。Steve Yegge 曾提到，如今使用 AI 编码 Agent 的开发者，其生产力是仅用普通 AI 聊天工具的 10 到 100 倍，更是 2005 年谷歌工程师的约 1000 倍。Garry Tan 对此表示认同，这个数字他亲眼见过，也亲身经历过。但当大多数人听到这个数字时，第一反应往往是：一定是模型更聪明了吧？或者参数更多了吧？
事实并非如此。那些效率提升 2 倍的人和提升 100 倍的人，很可能使用的是同一个模型。差距的真正根源在于系统的架构，而且这套架构的核心思想简单到可以写在一张卡片上。
一、秘密藏在「包裹模型的那层壳」里
2026 年 3 月，Anthropic 意外地将 Claude Code 的全部源代码（总计 51.2 万行）发布到了 npm 上。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 的文档，其中规定：先运行评估测试，对比分数，如果准确率下降超过 2% 就回滚并排查。开发者可能根本不知道有这个评估流程存在，但 Resolver 在对的时刻加载了对的上下文。
Garry Tan 坦言，他自己的 CLAUDE.md 曾经写了两万行，把他遇到过的每一个坑、每一个模式、每一条经验全塞了进去。结果适得其反，模型的注意力严重退化，Claude Code 甚至直接告诉他：你得砍掉这些内容。最后他精简到大约 200 行，只存放指向各个文档的索引。Resolver 在需要时才加载对应的内容。两万行知识，按需调用，绝不污染宝贵的上下文窗口。
这个教训值得牢记。很多人写提示词时，恨不得把所有要求一股脑全塞进去，以为说得越多 AI 就越听话。实际上恰恰相反，当所有内容都被标记为“重要”时，就等于什么都不重要了。给 AI 一张清晰的地图，远比给它一本千页手册有用得多。
4. 潜在空间 vs 确定性空间：把对的工作交给对的一方
你系统中的每一个步骤，要么属于潜在空间（latent），要么属于确定性空间（deterministic）。混淆这两者是 Agent 设计中最常见的错误。
潜在空间是智能（Intelligence）居住的地方。模型在此进行阅读、理解、判断、综合、识别模式——这些都是它真正擅长的领域。
确定性空间是信任（Trust）居住的地方。同样的输入，必须永远产生同样的输出。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 中所包含的判断步骤会自动变得更强大，而那些确定性的执行步骤则依然稳如磐石。
这就是那些实现百倍效率的开发者所掌握的秘密。 不依赖更聪明的模型，而是依靠“厚技能、薄缰绳”的架构设计，以及将一切有价值流程固化下来的纪律。
系统会以复利的方式持续增长。搭建一次，即可永久运转。
原文地址：https://x.com/garrytan/status/2042925773300908103
发表于 4 小时前
|
查看: 4|
回复: 0
