Tony Bai - 一个程序员的心路历程

薄驾驭，厚技能：YC 掌门人揭秘拉开 1000 倍效率差距的 AI 工程化心法

四月 19, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/04/19/thin-harness-fat-skills

大家好，我是Tony Bai。

在过去一年，你有没有想过，为什么同样用着 GPT 或 Claude 等大模型以及Claude Code这样的Coding Agent，有的人生产力只提升了 2 倍，而有的人却能爆发出 100倍、甚至 1000倍 的惊人能量？

就在前几天，硅谷创投界的大佬、Y Combinator 的 CEO Garry Tan，发表了一篇阅读量高达 70万+ 的长文，极其犀利地揭开了这个“效率鸿沟”背后的残酷真相。

他引用了 Google 前员工 Steve Yegge 的一个惊人论断：

“使用 AI 智能体（Agent）的人，比现在用 Cursor 和聊天窗口的人效率高 10-100 倍，比 2005 年的 Google 工程师效率高 1000 倍。”

Garry Tan 写道：“这不是吹牛，我亲眼见过，我亲身经历过。”

他甚至爆出一个猛料：2026 年 3 月 31 日，Anthropic 意外地将 Claude Code 的全部 51.2 万行源码泄露到了 npm 仓库。他读完了。

“这次泄露证实了我在 YC 一直教导的东西：秘密根本不在大模型本身，而在那个包裹着模型的‘驾驭层（Harness）’！”

今天，我们就来读读 Garry Tan 这篇文章，看看硅谷最顶尖的玩家，是如何通过 “薄驾驭，厚技能（Thin Harness, Fat Skills）” 的架构哲学，来榨干大模型的每一滴潜能的。

你的“胖驾驭”，正在杀死你的 AI

在文章的开头，Garry Tan 就毫不客气地指出了当下大多数 Agent 框架的“原罪”：臃肿的驾驭层，和孱弱的技能。

我们大多数人是怎么做的？我们给 AI 挂载了 40 多个 Tool Calls，每一个工具都对应一个外部 API。结果就是，光是这些工具的定义，就吃掉了上下文窗口（Context Window）的一半！

大模型每次行动前，都要在几十个工具中艰难地做选择题，不仅推理速度慢得像乌龟，出错率更是高得离谱。

Garry Tan 给出的架构哲学恰恰相反：

推崇“薄驾驭（Thin Harness）”：驾驭层（Harness）只做四件事——循环运行模型、读写文件、管理上下文、执行安全策略。代码量可能只有 200 行。
推崇“厚技能（Fat Skills）”：将所有复杂的业务逻辑、判断力、领域知识，全部封装成一个个可复用、可参数化的 Markdown 文件，即“技能（Skill）”。

“反面教材就是一个臃肿的驾驭层，配上一堆孱弱的技能。……你想要的是专为特定目的打造的、快速且狭窄的工具。”

五大心法：从“写 Prompt”到“编程 AI”

Garry Tan 认为，大模型的瓶颈从来不是智商。它天生就会推理、综合、写代码。它之所以频繁失败，是因为它不理解你的数据、你的规范、你问题的具体形态。

而下面这五个定义，正是修复这个问题的“架构级补丁”，也是“薄驾驭，厚技能”哲学的具体体现。

心法一：技能文件（Skill Files）—— 用 Markdown 写“方法调用”

这是最颠覆认知的一点。Garry Tan 认为，优秀的 Skill 文件，工作起来就像一个函数调用（Method Call）。它接受参数，并且根据不同的参数，产生完全不同的能力。

他举了一个名为 /investigate 的技能为例。这个 Skill 只有 7 个步骤：圈定数据集、构建时间线、标注文档、综合信息、正反方辩论、引用来源。

当你把这个 Skill 指向一个安全科学家的 210 万封邮件，它就变成了一个医学研究分析师。
当你把它指向一家空壳公司和 FEC 的文件，它就变成了一个法务调查员。

“这根本不是提示词工程。这是软件设计。你用 Markdown 作为编程语言，用人类的判断力作为运行时。”

心法二：解析器（Resolvers）—— AI 的“智能路由表”

技能文件告诉模型“怎么做”，而解析器告诉模型“在什么时候，加载什么上下文”。

Garry Tan 坦白，他自己曾经写过一个长达 20000 行的 CLAUDE.md 文件，里面塞满了各种他遇到过的奇技淫巧。结果导致模型注意力严重下降，甚至 Claude 自己都“告诉”他让他删掉点。

最终的解决方案，是把这个巨大的文件，拆成了一个只有 200 行的“指针”文件，和一个解析器（Resolver）。

“当一个开发者改了代码，没有解析器，他直接提交了。有了解析器，模型会先去读取 docs/EVALS.md，这个文件说：先跑评测套件，对比分数，如果准确率下降超过 2%，就回滚并调查。”

解析器就像一个智能的“路由表”，在不污染上下文的情况下，按需加载最精准的知识。

心法三：潜在空间 vs. 确定性—— 别让 AI 做数学题

这是 Agent 设计中最常见的错误：让 AI 去做它不擅长的事。

潜在空间（Latent Space）：这是 AI 的主场。它负责阅读、理解、判断、综合、模式识别。
确定性（Deterministic）：这是传统代码的主场。SQL 查询、代码编译、数学计算。

“一个 LLM 可以帮你安排 8 个人的晚宴座位，它会考虑每个人的性格和社交关系。但你让它去排 800 个人的座位，它会幻觉出一个看似合理、但完全错误的座位表。因为这是一个确定性的组合优化问题，应该交给传统算法。”

最牛逼的系统，对这条边界的划分是冷酷无情的。

心法四：倾向分析 —— 让 AI 拥有“判断力”

这是让 AI 从“数据库”进化为“分析师”的关键一步。

倾向分析，就是让模型读取关于一个主题的所有信息，然后写出一份结构化的、浓缩了判断力的简介。

Garry Tan 以 YC 内部正在构建的、管理 6000 名创始人的 AI 系统为例：

传统的关键词搜索，根本无法发现一个伪装成“可观测性”工具的 FinOps 项目。

但通过倾向分析，AI 读取了创始人的所有 GitHub 提交、访谈记录、公开帖子后，会给出一个惊人的洞察：

“创始人：Maria Santos。公司：Contrail。声称在做：‘给 AI Agent 用的 Datadog’。实际在做： 80% 的代码都在写账单模块。她其实在做一个伪装成可观测性的 FinOps 工具。”

这种“判断力”，是任何 RAG 管道都无法产生的。模型必须真正地去“阅读”和“思考”。

心法五：技能即永久升级

这是 Garry Tan 架构哲学的最终闭环。

他给自己团队的 AI Agent 下了一条铁命令：

“你绝不被允许做一次性的工作。如果我让你做一件事，而这件事未来可能需要再做一遍，你必须：第一次手动在 3-10 个样本上完成它，把结果给我看。如果我批准了，你就必须把这个过程固化成一个 Skill 文件。如果它应该自动运行，就把它加到定时任务里。测试标准：如果我需要为同一件事第二次开口，你就失败了。”

每一次你写下的 Skill，都是对你的 AI 系统的一次永久性升级。它永不衰退，永不遗忘。当下一代更强的模型发布时，你所有的 Skill 都会在一夜之间变得更聪明。

小结

Garry Tan 的这篇文章，为所有在 AI 时代感到迷茫的开发者，提供了一套极具实操性的架构蓝图。

它告诉我们，当大模型的能力趋于同质化时，真正的护城河，不在于你拥有哪个模型的 API 访问权限，而在于你为这个模型构建了怎样一个高效、智能、且能源源不断自我进化的“外部大脑”。

这个“大脑”，就是你沉淀下来的“厚技能（Fat Skills）”资产。

不要再沉迷于寻找那些能一键生成整个项目的“魔法按钮”了。慢下来，像一个真正的软件设计师一样，去思考你的流程、你的判断、你的领域知识。然后，把它们一一固化成 Markdown。

构建一次，它将永远为你运行。

资料链接：https://x.com/garrytan/status/2042925773300908103

今日互动探讨：

看完 YC 掌门人的这套“薄驾驭，厚技能”心法，你对自己目前开发 Agent 的方式有什么新的反思？你认为用 Markdown 来“编程”AI 的想法，是天才还是异端？

欢迎在评论区分享你的看法！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

告别低效，重塑开发范式
驾驭AI Agent(Claude Code)，实现工作流自动化
从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

img{512x368}

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

从“开源英雄”到“社区公敌”，Ollama 到底做错了什么？

四月 18, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/04/18/ollama-from-open-source-hero-to-community-enemy

大家好，我是Tony Bai。

两年前，在本地大模型的蛮荒时代，Ollama 曾如一道神光，照亮了无数普通开发者的探索之路。

凭借那句魔咒般的 ollama run llama3，它以一种近乎“降维打击”的优雅，将普通人与本地 AI 之间的天堑夷为平地。

一时间，Ollama 被盛赞为“本地 AI 的 Docker”、“开源精神的典范”，几乎成了无数技术布道者口中的“开源英雄”。

但就在几天前，一篇名为《本地大模型生态系统不再需要 Ollama》的文章，在技术社区 Hacker News 上，引发了一场“社区公审”。

文章详细罗列了 Ollama 在享受了社区的赞誉之后，犯下的种种“罪行”：从对核心依赖 llama.cpp 长达 400 多天的“选择性遗忘”，到试图用私有模型格式“绑架”用户，再到其背后若隐若现的“VC 商业化”套路……

一夜之间，Ollama 的形象从“屠龙少年”，变成了那条它曾经挑战的“恶龙”。

今天，我们就来深度复盘这场顶级社区的大讨论，看看这位曾经的“开源英雄”，究竟是如何一步步走向“社区公敌”的深渊的。

第一宗罪：对生身之父的“背叛”与“除名”

Ollama 之所以能如此快速地在各种平台上运行大模型，其背后最大的功臣，是一个名为 llama.cpp 的 C++ 开源库。llama.cpp 是真正负责模型推理的底层引擎。

Ollama 的 v0.0.1 版本，在其 README 中曾明确写道：“一个用 Go 编写的快速推理服务器，由 llama.cpp 驱动。”

Ollama 的本质，是一个基于 llama.cpp 构建的、优化了用户体验的“包装器（Wrapper）”。

然而，随着 Ollama 的声名鹊起，llama.cpp 的名字，却在其官网和宣传中，被刻意地、系统性地抹去了。

在 Hacker News 的帖子中，有用户愤怒地指出：

“这根本不是开源礼仪的问题。MIT 协议只有一个核心要求：包含版权声明。Ollama 没有做到。”

“社区注意到了。GitHub Issue #3185 在 2024 年初就被提出，要求 Ollama 遵守协议。这个 Issue 在 400 多天里，没有得到任何维护者的回应。”

直到社区忍无可忍，发起了 PR，Ollama 的联合创始人才最终在 README 的最底部，加上了一行极其微小的致谢：“llama.cpp 项目由 Georgi Gerganov 创建。”

这种对核心上游项目近乎“羞辱性”的冷处理，被社区视为一种赤裸裸的“背叛”，激怒了所有信奉开源精神的开发者。

第二宗罪：用“私有格式”构建“数据监狱”

比忘记致谢更让开发者无法容忍的，是 Ollama 为了“锁定用户”，而精心设计的私有化模型存储格式。

如果你用过 Ollama，你一定经历过这样的困惑：

你用 ollama pull 下来的模型文件，被存储在你的 Home 目录下，文件名是一串毫无意义的哈希值。你根本无法将这个 GGUF 文件，直接分享给其他工具（比如 LM Studio 或 Jan）使用。

Hacker News 的一位用户一针见血地指出了这个设计的“阴险”之处：

“我停止使用 Ollama 的原因就在于此。我能理解他们可能是为了做去重（Deduplication），但这使得我无法与其他工具共享同一个模型。每个工具都只能指向它自己的文件。无论他们的意图如何，这都在客观上，让你极难尝试其他工具。”

更糟糕的是，Ollama 会在下载模型时，对原始的 GGUF 文件进行一些“魔改”，并使用自己的一套私有配置。这导致了另一个灾难：性能下降。

有人在评论中分享道：“我最近开始使用 Jan，然后用 llama.cpp 和本地的 Ollama 跑同一个模型，llama.cpp 的速度明显更快。”

用更差的性能、更封闭的格式，换取所谓“简单”的用户体验。这背后，是典型的“建立围墙花园”的商业化思维。

第三宗罪：“VC 死亡陷阱”的经典复刻

Ollama 为什么要这么做？

一位用户在评论中扒出了 Ollama 创始团队的“前科”，让所有人恍然大悟。

“Ollama 是一家由 Y Combinator 支持的创业公司，其创始人之前构建了一个被 Docker 收购的 Docker GUI 工具。这个剧本太熟悉了：
1. 包装一个现有的开源项目，做一个用户友好的界面。
2. 建立用户基础，获得社区信任。
3. 融资，然后想办法商业化。
4. 最小化对上游的致谢，让产品看起来是自给自足的。
5. 创造锁定，用私有格式和哈希文件名，让用户无法迁移。
6. 推出闭源组件（GUI App）和云服务，开始收割。”

这套从 Docker 时代的 Kitematic 延续而来的“VC 死亡陷阱”，正在本地大模型领域被完美复刻。

社区的反击：大逃杀与“去 Ollama 化”

在这场社区的“公审”中，愤怒之余，开发者们也给出了大量极具建设性的“替代方案”。一场“去 Ollama 化”的大逃杀正在上演。

方案一：回归 llama.cpp 本身，王者归来

很多用户惊讶地发现，在他们唾弃 Ollama 的这段时间里，llama.cpp 自身已经进化成了一个极其强大的“完全体”。

它现在不仅自带了现代化的 Web UI（通过 llama-server），支持 OpenAI 兼容的 API，甚至还推出了“路由模式”，可以实现模型的“热插拔（Hot-swapping）”。

方案二：拥抱真正开放的“包装器”

社区推荐了大量同样易用，但秉持着真正开源精神的替代品，比如：

LM Studio：自带强大的 GUI，底层使用 llama.cpp，暴露所有可调参数，支持任何 GGUF 模型，不搞“锁定”。
Jan (jan.ai)：另一个开源的桌面应用，界面清爽，设计本地优先。
llamafile：由 Mozilla 支持，可以将模型和 llama.cpp 本身打包成一个“单一可执行文件”，真正实现“一键启动”，且完全开放。

小结：当便利性遭遇开源精神

Ollama 的故事，是近年来开源商业化领域最值得深思的一个案例。

毫无疑问，Ollama 解决了本地大模型领域一个极其真实的痛点：极致的易用性（Ease of use）。它就像当年的 Docker，让无数普通人跨越了复杂的门槛。

但在追求极致 UX 的同时，它却似乎忘记了自己赖以生存的根基——那个由 Georgi Gerganov 等无数开源贡献者用爱发电构建起来的 llama.cpp 生态。

Hacker News 上的这场论战，并没有全盘否定 Ollama 的价值。但它向所有试图通过“包装开源”来构建商业帝国的创业者，提出了一个极其严肃的警告：

用户体验的简化，永远不能以牺牲“开放性”和对上游社区的“尊重”为代价。

你可以站在巨人的肩膀上，但你不能在站上去之后，假装那个巨人不存在。

作为开发者，我们享受着开源带来的巨大红利。但在选择工具时，除了便利性，我们或许也应该多一份清醒：去看看它的背后，是否隐藏着一个正在试图关上的“围墙花园”。

资料链接：

https://news.ycombinator.com/item?id=47788385
https://sleepingrobots.com/dreams/stop-using-ollama/