同一个 Claude，有人 2 倍效率，有人 100 倍——差别在一张索引卡片

我读到这篇文章时，第一反应是“不可能”

最近在 AI 编程圈子里，有一篇文章被反复转发，是YC CEO Garry Tan写的,标题叫《Thin Harness, Fat Skills》。很是深刻，的确一个工具，不同参数传入，得到的效果千差万别。

说实话，我一开始是被 Steve Yegge 那句话吸引的：

用对 AI 编程智能体的人，比用 Cursor 和聊天模式的工程师高效 10–100 倍，比 2005 年的 Google 工程师高效约 1000 倍。

1000 倍？我心想，又一篇夸大其词的标题党。

但读完第一段，我就被按住了。作者说：“2 倍的人和 100 倍的人，用的是同一个模型。差别不在智能，在架构——而且这个架构可以写在一张索引卡片上。”

这句话让我想起自己过去一年的经历：天天盼着 Claude 4、GPT-5，以为模型更强了，我的效率就能翻倍。可实际上，同一个模型，有人写一个 prompt 跑一天，有人搭一套流程跑出 10 倍产出。

差别从来不在智商，而在“套路”。

这篇文章把那个“套路”拆透了。我花了一个晚上反复读了三遍，下面是我提炼出的核心内容。如果你也在用 AI 写代码、做分析、搞知识工作，这可能是 2026 年最值得你收藏的一篇方法论。

核心概念：薄工具链，厚技能

文章的核心就四个词：Thin Harness, Fat Skills（薄工具链，厚技能）。

• Harness（工具链）：跑 AI 的那层壳——循环调用模型、读写文件、管理上下文、执行安全规则。它应该薄到只有 200 行代码。
• Skills（技能）：教模型“如何做某件事”的 markdown 文档。它应该厚，因为它承载了你所有的领域知识、判断流程、操作规范。

绝大多数人的做法正好反过来：工具链堆了 40 多个工具、MCP 往返好几秒、上下文窗口被吃光；而技能几乎没有，只有一次性 prompt。这就是为什么你只有 2 倍，而不是 100 倍。

五个定义，我读完后立刻照抄下来

文章给出了五个定义，每一个都像是直接点醒了我的某个痛点。

1. 技能文件（Skill File）——像方法一样调用

技能文件不是教模型“做什么”（那是用户的事），而是教它“如何做”。
关键是：它可以接受参数。同一个过程，不同参数，产生完全不同的能力。

文章举了 /investigate 的例子：7 个步骤，3 个参数（目标、问题、数据集）。指向安全科学家 + 210 万封邮件 → 变成医学调查员；指向空壳公司 + 备案文件 → 变成反洗钱侦探。

我突然明白了：我以前写的 prompt 都是“一次性用品”，而技能文件是可复用的方法。这不就是软件工程里的函数封装吗？只是现在用 markdown 写，运行时是人类的判断力。

2. 工具链（Harness）——要薄、要快、要窄

工具链就干四件事：跑循环、读写文件、管上下文、强制安全。仅此而已。

反模式是“胖工具链”：一堆工具、god-tools、REST 封装……结果 token 多、延迟高、失败率翻三倍。
正确的做法是：专用、快速、窄接口。比如用 Playwright CLI 在 100ms 内完成一次浏览器操作，而不是花 15 秒等一个 Chrome MCP。75 倍的差距。

我以前总觉得工具越多越好，读完才意识到：少即是多，快即是强。

3. 解析器（Resolver）——自动加载正确的上下文

解析器是一张“上下文路由表”。当出现某类任务时，自动先加载某个文档。

例子：一个开发者改了 prompt，如果没有解析器，他直接上线。有了解析器，模型先读到 EVALS.md，发现里面写着“跑评估套件，准确率掉 2% 就回滚”。他根本不知道有评估套件，但灾难被避免了。

Claude Code 内置了解析器：每个技能的 description 字段就是它的路由表。模型自动匹配用户意图，你永远不需要记住 /ship 这个命令。

更让我震惊的是作者的坦白：他的 CLAUDE.md 曾有两万行——把所有知识都塞进去。结果模型的注意力被搞崩了。修复后只剩 200 行，全部是指向具体文档的指针。知识放在外面，需要时再加载。

4. 隐空间 vs 确定性——把对的工作交给对的地方

这是我最受用的一条。

• 隐空间：判断、综合、模式识别 → 交给 LLM。
• 确定性：SQL、代码编译、算术 → 永远交给确定性系统。

LLM 可以安排 8 个人的饭桌（个性 + 社交），但让它安排 800 人的座位，它会“幻觉”出一张漂亮但完全错误的表。这是确定性问题（组合优化），不该给 LLM。

我回想自己做过多少傻事：让模型去做计算、去排序、去执行精确的规则……结果它一本正经地胡说八道。不是模型不行，是我放错了位置。

5. 话者分离（Diarization）——模型真的去读，然后给你一页判断

这个词之前我没见过。它指的是：模型真正去读几十上百份文档，然后输出一页结构化的判断。

不是 RAG，不是向量检索，不是关键词搜索。是像分析师一样读、对比、综合。

文章举了一个例子：从 GitHub 提交、申请材料、1:1 聊天记录里，模型输出：

“创始人说自己做‘AI 可观测性’，但 80% 的代码在计费模块 → 她实际在做 FinOps。”

这种洞察，任何数据库查询都做不到。这才是 AI 对知识工作的真正价值。

一个让我彻底信服的案例：6000 位创始人自动分组

文章讲了一个 YC 正在做的真实系统。2026 年 7 月，Startup School 有 6000 位创始人。每个人有申请、问卷、聊天记录、GitHub、X 帖子、Claude Code 日志。

传统方法：15 人团队手动看，200 人还行，6000 人崩溃。
AI 的方法：

• /enrich-founder 技能拉取所有数据，话者分离，输出“说的 vs 实际做的”差距。
• 同一个 /match 技能，三次不同参数调用，干三件完全不同的事：小组聚类、跨领域偶遇匹配、现场实时 1:1。
• 模型能做聚类算法做不到的判断：“Santos 和 Oram 都是 AI 基础设施，但不是竞争对手，放同一组。”

最让我震撼的是学习循环：活动结束后，/improve 技能读 NPS 调查，专门分析那些“还行”的反馈（系统差点成功但没成功），提取规律，直接写回技能文件。例如：

当与会者说“AI 基础设施”，但初创公司 80%+ 代码是计费 → 归类为 FinTech。

然后下一次活动，技能自己进化了。7 月“还行”评分 12%，下一次降到 4%。没有一个人重写代码。

这让我意识到：最高级的系统，是能自我进化的系统。而进化的单元，就是技能文件。

我决定把这条纪律贴在自己屏幕上

文章末尾，作者分享了他给自己 AI 助手的一条指令，在推特上被转了上千次：

你不允许做一次性工作。
如果一件事以后还会发生：先手动做 3–10 个例子，给我看输出。
我批准后，把它编成技能文件。
检验标准：一件事我需要问你两次 → 你失败了。

我以前从来不觉得“写一次性的 prompt”有什么问题。反正每次重新写就是了。

但读完这篇文章我才明白：每写一次一次性 prompt，就是在拒绝一次永久升级。
一个技能文件，就是你系统的永久升级。它不退化，不忘记，凌晨 3 点还在跑。下一代模型出来，它还能自动变强。

总结：100 倍效率不在模型，在架构

回到最开头的那个问题：为什么同一个模型，有人 2 倍，有人 100 倍？

答案不是“他们用了更好的模型”，而是：

• Fat Skills, Thin Harness（厚技能，薄工具链）
• 把智能推上技能层，把执行压下确定性层
• 让系统学会重写自己

这篇文章没有教你怎么写 prompt，而是教你怎么设计一个会复利增长的 AI 系统。

构建一次，运行永远。

如果你也受够了“每次都要重新调教 AI”的琐碎和低效，我强烈建议你认真读一遍下面的原文。并且收藏这篇——因为里面的五个定义，值得你反复对照自己的工作流。

你愿意为你的团队引入“技能文件”文化吗？欢迎在评论区聊聊。

附：原文全文（中英对照）

以下为《Thin Harness, Fat Skills》完整原文及中文翻译，由我逐段对照整理。

Thin Harness, Fat Skills
薄型工具链，厚实技能

Steve Yegge says people using AI coding agents are "10x to 100x as productive as engineers using Cursor and chat today, and roughly 1000x as productive as Googlers were back in 2005."
Steve Yegge 说，使用 AI 编程智能体的人“比今天用 Cursor 和聊天模式的工程师高效 10 到 100 倍，比 2005 年的 Google 员工高效大约 1000 倍。”

That's a real number. I've seen it. I've lived it. But when people hear it, they reach for the wrong explanation. Better models. Smarter Claude. More parameters. The 2x people and the 100x people are using the same models. The difference isn't intelligence. It's architecture — and it fits on an index card.
这是一个真实的数字。我亲眼见过，亲身经历过。但人们听到它时，总会去找错误的解释：更好的模型、更聪明的 Claude、更多的参数。实际上，效率 2 倍的人和 100 倍的人用的是同样的模型。差别不在智能，而在架构——而且这个架构可以写在一张索引卡片上。

The harness is the product
工具链即产品

On March 31, 2026, Anthropic accidentally shipped the entire source code for Claude Code to the npm registry. 512,000 lines. I read it. It confirmed everything I'd been teaching at YC: the secret isn't the model. It's the thing wrapping the model.
2026 年 3 月 31 日，Anthropic 意外将 Claude Code 的完整源代码发布到了 npm 仓库，共 51.2 万行。我读了一遍。它证实了我在 YC 一直讲授的一切：秘诀不在模型，而在包裹模型的那个东西。

Live repo context. Prompt caching. Purpose-built tools. Context bloat minimization. Structured session memory. Parallel sub-agents. None of that makes the model smarter. All of it gives the model the right context, at the right time, without drowning it in noise.
实时仓库上下文、提示缓存、专用工具、上下文膨胀最小化、结构化会话记忆、并行子智能体——这些都不会让模型变得更聪明，但它们能在正确的时间给模型提供正确的上下文，同时不让它淹没在噪音中。

That wrapper is called the harness. And the question every AI builder should be asking is: what goes in the harness, and what stays out? The answer has a specific shape. I call it thin harness, fat skills.
这个包裹层就叫工具链（harness）。每个 AI 构建者都应该问的问题是：什么放进工具链，什么留在外面？答案有一个特定的形态。我称之为“薄型工具链，厚实技能”。

Five definitions
五个定义

The bottleneck is never the model's intelligence. Models already know how to reason, synthesize, and write code. They fail because they don't understand your data — your schema, your conventions, the particular shape of your problem. Five definitions fix this.
瓶颈从来不在模型的智能。模型已经知道如何推理、综合和编写代码。它们失败是因为不理解你的数据——你的 schema、你的约定、你问题的特定形态。五个定义解决了这个问题。

1. Skill files
1. 技能文件

A skill file is a reusable markdown document that teaches the model how to do something. Not what to do — the user supplies that. The skill supplies the process.
技能文件是一个可复用的 markdown 文档，它教模型如何做某件事。不是做什么——做什么由用户提供；技能提供的是过程。

Here's the key insight most people miss: a skill file works like a method call. It takes parameters. You invoke it with different arguments. The same procedure produces radically different capabilities depending on what you pass in.
这里有一个大多数人忽略的关键洞察：技能文件就像方法调用。它接受参数。你用不同的参数调用它。同样的过程，根据你传入的内容，会产生截然不同的能力。

Consider a skill called /investigate. It has seven steps: scope the dataset, build a timeline, diarize every document, synthesize, argue both sides, cite sources. It takes three parameters: TARGET, QUESTION, and DATASET. Point it at a safety scientist and 2.1 million discovery emails, and you get a medical research analyst determining whether a whistleblower was silenced. Point it at a shell company and FEC filings, and you get a forensic investigator tracing coordinated campaign donations.

考虑一个名为 /investigate 的技能。它有七个步骤：界定数据集范围、构建时间线、对每个文档进行话者分离（diarize）、综合、论证双方观点、引用来源。它接受三个参数：TARGET、QUESTION 和 DATASET。把它指向一个安全科学家和 210 万封取证邮件，你就得到一个医学研究分析师，判断举报人是否被噤声。把它指向一个空壳公司和 FEC 备案文件，你就得到一个法证调查员，追踪协调好的竞选捐款。

Same skill. Same seven steps. Same markdown file. The skill describes a process of judgment. The invocation supplies the world.
同一个技能，同样的七个步骤，同一个 markdown 文件。技能描述的是判断的过程；调用则提供了世界。

This is not prompt engineering. This is software design, using markdown as the programming language and human judgment as the runtime. Markdown is, in fact, a more perfect encapsulation of capability than rigid source code, because it describes process, judgment, and context in the language the model already thinks in.
这不是提示工程。这是软件设计——用 markdown 作为编程语言，用人类判断作为运行时。事实上，markdown 比僵硬的源代码更能完美地封装能力，因为它用模型已经用来思考的语言描述了过程、判断和上下文。

2. The harness
2. 工具链（harness）

The harness is the program that runs the LLM. It does four things: runs the model in a loop, reads and writes your files, manages context, and enforces safety. That's it. That's the "thin."
工具链是运行 LLM 的程序。它做四件事：循环运行模型、读写你的文件、管理上下文、强制执行安全规则。就这些。这就是“薄型”。

The anti-pattern is a fat harness with thin skills. You've seen it: 40+ tool definitions eating half the context window. God-tools with 2-to-5-second MCP round-trips. REST API wrappers that turn every endpoint into a separate tool. Three times the tokens, three times the latency, three times the failure rate.
反模式是“厚型工具链 + 薄型技能”。你见过这种：40 多个工具定义吃掉一半上下文窗口；万能工具（god-tools）需要 2 到 5 秒的 MCP 往返；REST API 封装把每个端点变成单独的工具。三倍的 token，三倍的延迟，三倍的失败率。

What you want instead is purpose-built tooling that's fast and narrow. A Playwright CLI that does each browser operation in 100 milliseconds, not a Chrome MCP that takes 15 seconds for
screenshot-find-click-wait-read. That's 75x faster. Software doesn't have to be precious anymore. Build exactly what you need, and nothing else.
你想要的恰恰相反：专用、快速、窄接口的工具。比如一个 Playwright CLI，每个浏览器操作只需 100 毫秒，而不是一个 Chrome MCP 花 15 秒去做截图-查找-点击-等待-读取。那是 75 倍的提速。软件不必再那么“娇贵”了。只构建你真正需要的东西，别无其他。

3. Resolvers
3. 解析器（Resolver）

A resolver is a routing table for context. When task type X appears, load document Y first.
解析器是一张上下文的路由表。当出现 X 类型的任务时，首先加载 Y 文档。

Skills tell the model how. Resolvers tell it what to load and when. A developer changes a prompt. Without the resolver, they ship it. With the resolver, the model reads docs/EVALS.md first — which says: run the eval suite, compare scores, if accuracy drops more than 2%, revert and investigate. The developer didn't know the eval suite existed. The resolver loaded the right context at the right moment.
技能告诉模型“如何做”。解析器告诉模型“加载什么、何时加载”。一个开发者修改了 prompt。如果没有解析器，他会直接上线。有了解析器，模型会先读 docs/EVALS.md——里面写着：运行评估套件，比较分数，如果准确率下降超过 2%，就回滚并调查。开发者甚至不知道评估套件的存在。解析器在正确的时刻加载了正确的上下文。

Claude Code has a built-in resolver. Every skill has a description field, and the model matches user intent to skill descriptions automatically. You never have to remember that /ship exists. The description is the resolver.
Claude Code 内置了解析器。每个技能都有一个 description 字段，模型会自动将用户意图与技能描述匹配。你永远不需要记住 /ship 这个命令存在。描述本身就是解析器。

A confession: my CLAUDE.md was 20,000 lines. Every quirk, every pattern, every lesson I'd ever encountered. Completely ridiculous. The model's attention degraded. Claude Code literally told me to cut it back. The fix was about 200 lines — just pointers to documents. The resolver loads the right one when it matters. Twenty thousand lines of knowledge, accessible on demand, without polluting the context window.
坦白说：我的 CLAUDE.md 曾有两万行。每一个怪癖、每一个模式、我遇到过的每一个教训。太荒谬了。模型的注意力被破坏了。Claude Code 直接告诉我把它削减掉。修复后只有大约 200 行——仅仅是指向文档的指针。解析器在需要时加载正确的文档。两万行的知识，按需访问，却不污染上下文窗口。

4. Latent vs. deterministic
4. 隐空间 vs. 确定性

Every step in your system is one or the other, and confusing them is the most common mistake in agent design.
你系统中的每一步，要么属于隐空间，要么属于确定性，而混淆二者是智能体设计中最常见的错误。

Latent space is where intelligence lives. The model reads, interprets, decides. Judgment. Synthesis. Pattern recognition.
隐空间（latent space）是智能所在之处。模型阅读、解释、决策。判断、综合、模式识别。

Deterministic is where trust lives. Same input, same output. Every time. SQL queries. Compiled code. Arithmetic.
确定性（deterministic）是信任所在之处。相同输入，相同输出，每一次都如此。SQL 查询、编译后的代码、算术运算。

An LLM can seat 8 people at a dinner table, accounting for personalities and social dynamics. Ask it to seat 800 and it will hallucinate a seating chart that looks plausible but is completely wrong. That's a deterministic problem — combinatorial optimization — forced into latent space. The worst systems put the wrong work on the wrong side of this line. The best systems are ruthless about it.
一个 LLM 可以安排 8 个人的餐桌座位，考虑到个性和社交互动。让它安排 800 个人，它就会凭空虚构出一张看起来合理但完全错误的座位表。这是一个确定性问题（组合优化），却被强行塞进了隐空间。最糟糕的系统把错误的工作放在这条线的错误一侧；最好的系统对此毫不留情。

5. Diarization
5. 话者分离（Diarization）

Diarization is the step that makes AI useful for real knowledge work. The model reads everything about a subject and writes a structured profile — a single page of judgment distilled from dozens or hundreds of documents.
话者分离是让 AI 对真正的知识工作有用的关键步骤。模型阅读关于某个主题的所有内容，然后写出一个结构化档案——从几十或几百份文档中提炼出的一页判断。

No SQL query produces this. No RAG pipeline produces this. The model has to actually read, hold contradictions in mind, notice what changed and when, and synthesize structured intelligence. It's the difference between a database lookup and an analyst's brief.
没有 SQL 查询能做到这一点，没有 RAG 流程能做到这一点。模型必须真正去阅读，在脑海中同时容纳矛盾，注意到什么变化了以及何时变化，并综合出结构化的情报。这就是数据库查询和分析师简报的区别。

The architecture
架构

These five concepts compose into a simple three-layer architecture.
这五个概念组合成一个简单的三层架构。

Fat skills sit on top: markdown procedures that encode judgment, process, and domain knowledge. This is where 90% of the value lives.
厚实的技能在顶层：编码判断、过程和领域知识的 markdown 流程。90% 的价值在这里。

A thin CLI harness sits in the middle: about 200 lines of code. JSON in, text out. Read-only by default.
一个薄型的 CLI 工具链在中间：大约 200 行代码。JSON 输入，文本输出。默认只读。

Your application sits on the bottom: QueryDB, ReadDoc, Search, Timeline — the deterministic foundation.
你的应用在底层：QueryDB、ReadDoc、Search、Timeline——确定性基础。

The principle is directional. Push intelligence up into skills. Push execution down into deterministic tooling. Keep the harness thin. When you do this, every improvement to the model automatically improves every skill, while the deterministic layer stays perfectly reliable.
这个原则是有方向性的：把智能往上推入技能，把执行往下推入确定性工具，保持工具链薄型。当你这样做时，模型的每一次改进都会自动提升每一个技能，而确定性层则保持完美可靠。

The system that learns
会学习的系统

Let me show you all five definitions working together. Not in theory — in an actual system we're building at YC.
让我展示这五个定义是如何一起工作的。不是理论——而是在 YC 正在构建的一个实际系统中。

Chase Center. July 2026. Six thousand founders at Startup School. Each one has a structured application, questionnaire answers, transcripts from 1:1 advisor chats, and public signals: posts on X, GitHub commits, Claude Code transcripts showing how fast they ship.
Chase Center，2026 年 7 月。创业学校的六千位创始人。每个人都有一个结构化的申请、问卷回答、与顾问一对一聊天的记录，以及公开信号：X 上的帖子、GitHub 提交、显示他们交付速度的 Claude Code 记录。

The traditional approach: a program team of 15 reads applications, makes gut calls, updates a spreadsheet. It works at 200 founders. It breaks at 6,000. No human can hold that many profiles in working memory and notice that the three best candidates for the infrastructure-for-AI-agents cohort are a dev tools founder in Lagos, a compliance founder in Singapore, and a CLI-tooling founder in Brooklyn — all of whom described the same pain point in different words during their 1:1 chats.

传统方法：一个 15 人的项目团队阅读申请，凭直觉判断，更新电子表格。处理 200 位创始人时还管用，到 6000 位就崩溃了。没有人类能在工作记忆中同时容纳那么多档案，并注意到“AI 智能体基础设施”组别中最合适的三个候选人分别是拉各斯的一位开发工具创始人、新加坡的一位合规创始人、布鲁克林的一位 CLI 工具创始人——而他们在 1:1 聊天中都用不同的词描述了同一个痛点。

The model can. Here's how.
模型可以。下面就是方法。

Enrichment. A skill called /enrich-founder pulls all sources, runs enrichments, diarizes, and highlights the gap between what founders say and what they're actually building. The deterministic layer handles SQL lookups, GitHub stats, browser tests on demo URLs, social signal pulls, CrustData queries. A cron runs nightly. Six thousand profiles, always fresh.
丰富化（Enrichment）。一个名为 /enrich-founder 的技能拉取所有来源，执行丰富化，进行话者分离，并突出显示创始人所声称的内容与他们实际构建内容之间的差距。确定性层处理 SQL 查询、GitHub 统计、对演示 URL 的浏览器测试、社交信号拉取、CrustData 查询。一个 cron 任务每晚运行。六千份档案，永远保持新鲜。

The diarization output catches things no keyword search would find:
话者分离的输出能捕捉到关键词搜索永远找不到的东西：

FOUNDER: Maria Santos
COMPANY: Contrail (contrail.dev)
SAYS: "Datadog for AI agents"
ACTUALLY BUILDING: 80% of commits are in billing module.
She's building a FinOps tool disguised as observability.

创始人：Maria Santos
公司：Contrail (contrail.dev)
声称：“为 AI 智能体打造的 Datadog”
实际构建：80% 的提交在计费模块。
她正在构建一个伪装成可观测性工具的 FinOps 产品。

That gap — "says" versus "actually building" — requires reading the GitHub commit history, the application, and the advisor transcript, and holding all three in mind at once. No embedding similarity search finds this. No keyword filter finds it. The model has to read the full profile and make a judgment. (This is the perfect decision to put in latent space!)
这个差距——“声称”与“实际构建”——需要同时阅读 GitHub 提交历史、申请材料和顾问聊天记录，并将三者同时记在脑中。没有 embedding 相似度搜索能找到这个，没有关键词过滤器能找到它。模型必须阅读完整的档案并做出判断。（这正是应该放入隐空间的完美决策！）

Matching. This is where skill-as-method-call shines. Three invocations of the same matching skill, three completely different strategies:
匹配（Matching）。这正是“技能即方法调用”大放异彩的地方。对同一个匹配技能的三个调用，三种完全不同的策略：

/match-breakout takes 1,200 founders, clusters by sector affinity, 30 per room. Embedding plus deterministic assignment. /match-lunch takes 600, does serendipity matching across sectors, 8 per table, no repeats — the LLM invents the themes, then a deterministic algorithm assigns seats. /match-live handles whoever is in the building right now, nearest-neighbor embedding, 200ms, 1:1 pairs, excluding people who've already met.
/match-breakout：处理 1200 位创始人，按领域亲和度聚类，每间 30 人。Embedding 加确定性分配。 /match-lunch：处理 600 人，跨领域做“偶遇匹配”，每桌 8 人，不重复——LLM 创造主题，然后确定性算法分配座位。 /match-live：处理此刻正在楼里的任何人，最近邻 embedding，200 毫秒，1:1 配对，排除已经见过的人。

And the model makes judgment calls a clustering algorithm never could: "Santos and Oram are both AI infra, but they're not competitors — Santos is cost attribution, Oram is orchestration. Put them in the same group." Or: "Kim applied as 'developer tools' but his 1:1 transcript reveals he's building compliance automation for SOC2. Move him to FinTech/RegTech."
而模型能做出聚类算法永远做不到的判断：“Santos 和 Oram 都是 AI 基础设施，但他们不是竞争对手——Santos 做成本归因，Oram 做编排。把他们放在同一组。”或者：“Kim 申请时填的是‘开发者工具’，但他的 1:1 聊天记录显示他正在为 SOC2 构建合规自动化。把他移到 FinTech/RegTech 组。”

No embedding captures the Kim reclassification. The model has to read the entire profile.
没有 embedding 能捕捉到 Kim 的重新分类。模型必须阅读完整的档案。

The learning loop. After the event, an /improve skill reads NPS surveys, diarizes the mediocre responses — not the bad ones, the "OK" ones, where the system almost worked but didn't — and extracts patterns. Then it proposes new rules and writes them back into the matching skills:
学习循环（The learning loop）。活动结束后，一个 /improve 技能读取 NPS 调查，对其中的平庸反馈（不是差评，而是“还行”——系统差点成功但没成功的那种）进行话者分离，并提取模式。然后它提出新规则，并将这些规则写回到匹配技能中：

When attendee says "AI infrastructure"
but startup is 80%+ billing code:
→ Classify as FinTech, not AI Infra.

When two attendees in same group
already know each other:
→ Penalize proximity.
Prioritize novel introductions.

当与会者说“AI 基础设施”
但初创公司 80%+ 代码是计费相关：
→ 归类为 FinTech，而非 AI Infra。

当同一组中的两位与会者
已经认识：
→ 降低接近度权重。
优先安排新的介绍。

These rules get written back into the skill file. The next run uses them automatically. The skill rewrites itself.
这些规则被写回到技能文件中。下一次运行时自动使用它们。技能重写了自身。

July event: 12% "OK" ratings. Next event: 4%. The skill file learned what "OK" actually meant, and the system got better without anyone rewriting code.
七月的活动：12% 的“还行”评分。下一次活动：4%。技能文件学到了“还行”实际意味着什么，系统变好了，而没有人重写代码。

The same pattern transfers everywhere: retrieve, read, diarize, count, synthesize. Then: survey, investigate, diarize, rewrite the skill.
同样的模式可以迁移到任何地方：检索、阅读、话者分离、计数、综合。然后：调查、探究、话者分离、重写技能。

If you want to know what the most valuable loops are in 2026, it's those. We can apply them to every discipline and walk of life of knowledge work in existence.
如果你想知道 2026 年最有价值的循环是什么，就是这些。我们可以把它们应用到知识工作存在的每一个学科和领域。

Skills are permanent upgrades
技能是永久升级

I tweeted an instruction I gave to my OpenClaw recently that resonated more than I expected:
我最近在推特上发了一条我给自己的 OpenClaw 的指令，引起的共鸣超出了我的预期：

You are not allowed to do one-off work. If I ask you to do something and it's the kind of thing that will need to happen again, you must: do it manually the first time on 3 to 10 items. Show me the output. If I approve, codify it into a skill file. If it should run automatically, put it on a cron.
The test: if I have to ask you for something twice, you failed.

你不允许做一次性工作。如果我让你做某件事，而且这件事以后还会发生，你必须：先在 3 到 10 个条目上手动执行一次。把输出给我看。如果我批准，就把它编成技能文件。如果应该自动运行，就把它放到 cron 里。
检验标准：如果一件事我需要问你两次，你就失败了。

A thousand likes and twenty-five hundred bookmarks. People thought it was a prompt engineering trick. It's not. It's the architecture I've been describing. Every skill you write is a permanent upgrade to your system. It never degrades. It never forgets. It runs at 3 AM while you sleep. And when the next model drops, every skill instantly gets better — the judgment in the latent steps improves while the deterministic steps stay perfectly reliable.
一千个赞，两千五百个收藏。人们以为这是一个提示工程的小技巧。其实不是。这就是我一直描述的架构。你写的每一个技能都是你系统的永久升级。它永远不会退化，永远不会忘记，在你睡觉的凌晨 3 点运行。而当下一代模型发布时，每一个技能都会瞬间变得更好——隐空间步骤中的判断力提升了，而确定性步骤依然完美可靠。

That's how you get Yegge's 100x. Not a smarter model. Fat skills, thin harness, and the discipline to codify everything.
这就是你获得 Yegge 所说的 100 倍效率的方法。不是靠更聪明的模型，而是靠厚实的技能、薄型的工具链，以及将一切编成代码的纪律。

The system compounds. Build it once. It runs forever.
这个系统会复利增长。构建一次，永远运行。

如果你读到这里，我相信你已经看到了 AI 编程的下一个阶段。
点个收藏，下次写 prompt 之前翻出来看看——你是在做一次性工作，还是在写永久技能？