前阵子听了 The Pragmatic Engineer 的一期播客，主持人 Gergely 和 Codex 负责人 Tibo Sottiaux 聊了一个多小时 ↗。其中有一小段，我听完之后想了很久。
Gergely 问：早期的 Codex 改完代码不会主动跑测试，几个月之后它自己会跑了，你们改的是提示词，还是模型？
Tibo 的回答大意是：Harness（模型外面的那一层工程，下一节会细说）总是比模型领先一点。模型其实有这个能力，只是还不够稳定，他们就先在外面加一句提醒；等下一代模型训练出来，它自己就会了，这句提醒也就可以删掉。时间一长，他们写给模型的说明越来越短，Harness 也越来越小。
节目最后，Gergely 说了一句很实在的话：作为开发者，这听起来有点让人泄气。今天认真做出来的东西，下一版模型自己就会了，然后就可以删掉。
Tibo 描述的这个现象我是认同的，我自己做 Agent 的体会也是这样。但我得出的结论和他们两位都不一样：Tibo 说 Harness 在变小，我看到的是它一直在变大；Gergely 觉得泄气，我反而觉得这正是现在做 Agent 产品最有意思的地方。
这篇文章就借这段对话开头，只聊 Harness 这一件事：它指什么，哪些部分会被模型学走，它现在长到了哪里，以及做 Agent 产品的人该怎么算这笔账。
一、Harness 到底指什么#
我做 Agent 的时候，习惯把它拆成四个部分：大脑、记忆、工具、循环。
大脑就是模型，也是其中唯一一个我不需要做、也没有能力做的部分。我不会去训练一个模型，我能决定的只是调用哪一个。除此之外的全部工作都在模型外面：记忆怎么存，工具怎么接，上下文怎么管理，出错了怎么处理。
模型外面的这一整圈，业内叫 Harness。LangChain 的 Vivek Trivedy 有一个很干脆的说法：Agent = 模型 + Harness，模型之外的一切都是 Harness。
我的理解比这个还要宽一点：只要你在做 Agent 产品，而你又不是训练模型的那家公司，你做的所有东西都是 Harness。 写作 Agent 的编辑器和版本管理是，客服 Agent 接的知识库和工单系统是，你给自己的个人 Agent 写的那份很长的偏好说明也是。更早的 Prompt Engineering 和 Context Engineering 同样属于这个范畴，只是当时还没有人用这个词。
这一圈有多重要？可以看两个例子，它们的共同点是模型没有换，只改了外面。
第一个就是开头那件事。早期的 Codex 改完文件不会跑测试，Tibo 的团队在提示词里加了一句提醒，它就开始跑了。
第二个例子方向相反。Claude Code 的作者 Boris Cherny 今年在 YC Startup School 的分享里提到（官方逐字稿 ↗），Opus 5 发布的时候，他们把 Claude Code 的系统提示词删掉了 80%。原因是其中很多内容是在纠正旧模型的问题，而新模型已经没有这些问题了。他还提到，去掉这些提示之后，模型的表现反而略有提升。
两个例子说明的是同一件事：外面这一圈做对了，模型的能力才发挥得出来；外面这一圈过时了，反过来会拖累模型。很多看起来是「模型不行」的问题，根源其实在 Harness。我自己用某个 coding 模型时就遇到过：它的工具调用经常失败，排查之后发现是参数格式没有对齐，和模型本身的能力没有关系。
二、补上去的东西，模型迟早自己会#
Tibo 描述的这个现象，在过去几年里反复出现过。
2022 年，大家发现只要在提示词末尾加一句「Let’s think step by step」，模型在推理题上的正确率就会明显提高。那两年流行的各种 magic words 都是同样的思路。到 2024 年推理模型出现，「先思考再回答」被直接训练进了模型，这句话也就没有人再写了。
工具调用也是一样。最早的做法是在提示词里约定一种输出格式，由外部程序解析文本、执行、再把结果交还给模型。后来各家把 function calling 做成了模型的原生能力，那一层解析代码就不再需要了。
最近的一个例子来自 Claude Code。团队在 9 月发布过一期 22 分钟的内部对谈 How the Claude Code team uses Claude Code ↗，出镜的是 Thariq Shihipar、Sid Bidasaria 和 Robert Boyce。他们讲到了 Todo List 的来历：大约在 Sonnet 3.5 的阶段，交给模型五件事，它往往做完三件就停了，于是团队加了一个待办列表，效果非常明显。一年之后，这个工具已经基本不需要了。
这一点有版本记录可以印证。8 月 14 日发布的 Claude Code v2.1.233 ↗ 在 release notes 里写明：TodoWrite 等五个待办和任务跟踪工具，在 Opus 4.8、Sonnet 5、Fable 5、Mythos 5 及之后的模型上不再提供，需要的话可以通过环境变量 CLAUDE_CODE_ENABLE_TODO_TOOLS=1 重新打开。原因不难理解：每个工具的定义，模型在每一轮都要读一遍；当模型自己已经能记住要做的事，这个工具带来的成本就超过了收益。
为什么总是先在外面做，之后才进到模型里？因为在外面试错的成本低。 改一句提示词只要几分钟，改一段循环逻辑只要一个下午，效果当场就能看到。训练一个模型要以月为单位，而且得先知道要训练什么。「要训练什么」这个问题的答案，恰恰是在模型外面、在真实用户的使用中一点点试出来的。
Tibo 在节目里也提到了他们内部的做法：发现一个问题之后，研究和工程团队会一起讨论，这个问题应该在 Harness 里解决，还是在模型里解决；如果改模型，需要一个月、三个月还是六个月。有时候他们会决定在 Harness 里什么都不做，直接等模型。
Tibo 把这些补丁比作拐杖，我觉得这个比喻不太准确。拐杖是伤好之后就扔掉的东西，而这些补丁做的事，更像是替下一代模型探路：今天在外面验证过的做法，就是明天模型应该具备的能力。而且探路的不只是模型厂商。「step by step」和早期的工具调用，最初都来自论文和开发者社区。我们平时摸索出来的那些技巧，也是其中的一部分。
哪些东西模型学不走#
那么，模型外面的东西最终都会被学走吗？不会。
我判断的方法很简单，只问一个问题：假如模型已经足够聪明，这段代码还有没有存在的必要？
提醒它跑测试，提醒它不要做到一半就停，这些在足够聪明的模型面前都没有必要了，所以迟早会被学走。但下面这些事情，模型再聪明，也需要有人在外面做：
- 取回真实的结果。「测试通过了」从模型口中说出来只是一句话，真实的退出码要由程序去取。模型越强，它写的完成报告读起来越可靠，也就越难靠读报告发现问题，所以 CI 是红是绿必须由程序来确认。
- 权限和边界。「它会选择不读这个目录」和「它读不了这个目录」是两回事，只有后者才是保证。规则可以让模型起草，执行必须交给沙箱和权限系统。
- 进度和触发。 模型只在被调用的那几秒存在。定时任务由谁触发，进程崩溃之后从哪一步继续，哪些操作已经执行过、不能重复，这些都发生在模型不在场的时候。
- 通往真实世界的接口。 模型再聪明，也接触不到没有接给它的东西：你的数据库、内部系统、IM、邮箱、支付。我之前给自己的 Agent 配了一个邮箱，补的就是这一块。
- 人在哪里介入。 怎么看到它正在做什么，在哪一步可以打断，哪些操作需要人确认。
- 成本。 用哪个模型，同时开几路，预算花到多少应该停。付账的是你，这笔账只能在模型外面算。
- 追查和撤回。 Agent 替你做的事情越多，事后能不能说清楚「它当时做了什么、为什么这么做」，做错了能不能撤回，就越重要。
而且模型越强，这些部分的分量越重。因为模型越强，我们就越敢让它在无人值守的情况下运行更长时间，需要核对的结果、需要管理的权限、需要衔接的断点，都会随之增加。
Boris 在那场分享里的一句话可以作为印证。他说团队每发布一个新模型，就会删掉一轮 harness 里的代码，到今天，Claude Code 的 harness 里剩下的代码，几乎全是安全、权限和静态分析，再加上大量 UI 代码。 安全和权限对应边界，静态分析对应真实的结果，UI 对应人的介入。
最后还有一样学不走的东西，也是后面两节的重点：只属于你、你的组织或企业的上下文。团队为什么这样决定，企业内部的流程为什么是现在这个样子，你的用户说「老样子」指的是什么，什么样的结果在你的场景里才算合格。
拿 Skills 来验证一下#
「假如模型已经足够聪明，它还有没有存在的必要」，这个问题也可以用来看最近很热的 Skills。
Superpowers ↗ 是过去一年最流行的开发流程 Skills 之一：先 brainstorm，再把计划拆成小任务，强制 TDD，做完之后 review，相当于给 coding agent 装上了一整套软件开发方法论。GPT-6 发布之后，我看到很多人不再用它，转向了 Matt Pocock 的 grill-me 系列 ↗。后者轻得多，核心只有一件事：在动手之前反过来追问你，直到方案里每一个没有想清楚的地方都问明白为止。
这个变化和前面讲的是同一件事。Superpowers 补的是模型在「怎么规划、怎么执行」上的判断；模型自己具备了这种判断，这套流程就从帮助变成了负担，很简单的问题也要走完整套流程。grill-me 留下的那一部分，是把只有你知道的信息从你这里问出来，这是模型自己推断不出来的。不过我认为它也未必能留很久：下一代 SOTA 模型出现之后，模型很可能自己就知道什么时候该停下来提问、该问什么，到那时今天大家追捧的 grill-me 同样会被淘汰。
我自己平时不用这类开发流程 Skills。在我看来，Skills 就是外部能力包。怎么开发、需求怎么拆分，这些我自己清楚，直接告诉 Agent 就可以，不需要再装一套流程替我做决定。
Skills 这种形式本身不会被淘汰，但它最后剩下的价值，很可能只有一点：方便传播。一份垂类领域的 know-how 打包成 Skill，别人装上就能用，这一点很难被替代。只不过别人给我一个垂类 Skill 之后，我也不会原封不动地只用它，而是会把它拆开，融进自己的 Agent 和 workflow 里。
把这一节提到的东西放在一起，换几代模型来看，规律会更清楚：
上一批补丁基本都进了模型。右边一项没少，而且每一项都更重了。
Todo List 工具已进模型
- 补的是什么
- 交给模型五件事，它往往做完三件就停了。加一个待办列表，效果非常明显。
- 后来
- 2026 年 8 月的 Claude Code v2.1.233 起，待办工具在新一代模型上默认不再提供。
三、但 Harness 没有变小，它在往外长#
补丁一个个被删掉，Harness 是不是就像 Tibo 说的那样越来越小？
这取决于他指的是哪一部分。Tibo 说的 Harness，是 Codex 团队自己维护的核心部分：沙箱、工具，以及每一轮开头写给模型的那段说明。这一部分确实在变小。
但在同一期节目里，他还讲了另外几件事：OpenAI 内部的 Codex 默认接入了 Slack、全部文档和全部代码，新人遇到问题，会先被问一句「你问过 Codex 了吗」；Codex 的使用场景也从写代码扩展到了 finance、marketing 等领域。这些事情没有一件发生在模型内部。写给模型的那几段话在变短，围绕模型的那一整圈在变厚。
Claude Code 团队在那期视频里说得更直接。讲完 Todo List 的退场之后，另一位成员接着补充：这些功能当初是为了弥补模型的缺陷，模型变好了就可以拿掉；但与此同时，他们交给 Claude Code 的任务变得更大、更难，要在更大的任务上保持连贯，模型又需要新的工具。
删掉一层，能交给 Agent 的任务变大，外面再长出一层。我之前写过 Prompt → Context → Harness → Loop 这条演进线，背后是同一个规律：里面那一层稳定了，大家着手的地方就往外移一圈，而原来那一层并没有消失，只是成了新一层的组成部分。
那么，现在外面这一圈长到了哪里？先说我自己的变化。
无论是工作还是平时自己做开发，我直接面对 coding agent 的时间都在减少。现在更常见的情形是：我拿着手机，或者在电脑上开着一个 IM，在对话框里把事情交代出去。公司里用的是飞书，个人项目用的是 Telegram，QQ 粉丝群里也有一个 Agent。底层干活的依然是 Claude Code、Codex 这些 coding agent，这一点没有变；变的是我和它们之间多了一层，我工作的抽象层高了一级。
Claude Code 团队的情况也类似。视频开头，主持人问大家现在怎么用 Claude Code，一位成员说，他 70%—80% 的工作发生在 Claude Tag 上，这是他们做的一个运行在 Slack 里的 Agent；只有剩下的 20%，他才会打开终端或桌面端去做精细的修改。
为什么把 Agent 放进 IM 之后反而更好用？另一位成员的解释是：它在 Slack 里，可以查到团队的讨论，了解产品的背景和大家之前做过的决定，所以它做出的判断好了很多。他现在交给 Claude Tag 的问题，比「实现这个函数」要复杂得多。
这和我的体会一致。代码仓库记录的是系统现在是什么样，聊天记录里记录的是它为什么是这样。只有前者，Agent 很容易做出局部正确、整体却不合适的修改。
所以在我看来，Harness 已经不能只当成一层来看了。我把它分成三层，图里的每一层都可以点开看细节。
- 团队的决定记在哪里
- Agent 能代表谁发言
- 用户反馈怎么回到它手里
- AGENTS.md
- CI/CD
- 文档
- repo index
- 以前要问同事才知道的事
- Tool
- MCP
- 上下文
- 记忆
- 文中的例子
- 「改完记得跑测试」的提醒、被删掉的 80% 系统提示词、Todo 工具、AskUserQuestion。
- 会被收走的
- 通用的机制：工具调用已经是原生能力，MCP 是公共协议，记忆正在成为各家产品的标配。
- 留给自己的
- 你的工具，以及垂类里才有的做法。设计、剪辑、市场研究这些领域，这一层才刚开始探索。
第一层：产品本身#
这是大家最熟悉的一层。判断一个 Agent 产品的 Harness 做得怎么样，我主要看四件事：Tool 怎么设计，MCP 怎么接，上下文怎么管理，记忆怎么存。前面讲的测试提醒、被删掉的 80% 提示词、Todo 工具，都发生在这一层。
在 coding agent 这个领域，这一层已经相当成熟，其中通用的部分正在被两头挤压。一头是被模型学走：视频里提到 AskUserQuestion 这个工具，作者花了很长时间设计，后来他自己也很少用了，而是直接让 Claude 生成一个带图表的 HTML 页面来向他提问。另一头是被平台做成标配：function calling 已经是原生能力，MCP 是公共协议，记忆也在成为各家产品的内置功能。
但这只是 coding agent 的情况。coding 是现在最热的方向，大部分人和资源都投在这里，能试的东西很快就被试过了，所以这一层剩下的提升空间才显得不大。换到其它领域，设计、剪辑、市场研究，各种垂类 Agent 的 Harness 才刚刚开始探索：一个剪辑 Agent 应该有哪些工具，一份市场研究报告的质量怎么交给程序验证，设计 Agent 的记忆里应该存什么。这些问题现在都没有公认的答案，谁先做出来，谁就能领先一段时间。
第二层：Repo#
这一层是在 coding agent 好用到人手一个之后才出现的。
设想一个 5 人的开发团队，每人配一个 coding agent。每个 Agent 单独看都没有问题，放在一起，新的问题就出现了，而且这些问题换一个更强的模型也解决不了：
- A 的 Agent 刚修改了一个接口的约定，B 的 Agent 并不知道，又按旧的约定写了三处调用。
- 两个 issue 单独看都合理，改的却是同一块逻辑，前提还互相矛盾。两个 Agent 分头做完，到合并的时候才发现冲突。
- 历史遗留的技术问题。这段代码为什么写得这么绕，哪个模块看起来可以删、实际上不能动，哪张表其实有两个地方在写。这些很少有人写下来，从代码里也看不出来。
- 每个 Agent 进入仓库都要重新熟悉一遍：模块怎么划分，入口在哪里，哪些目录是生成的、不需要读。这份成本每个会话都要付一次，再乘以 Agent 的数量。
- 规范只存在于人的脑子里。提交信息怎么写，哪些改动必须先跑 check，哪些文件不能动。人可以靠默契，Agent 只能靠写下来的东西。
在没有 AI 的时候，这些问题是怎么解决的？问同事。看不懂的代码，问一句旁边的人；两个需求可能冲突，开会的时候总会有人提出来。这些知识一直都在，只是存在人的脑子里和聊天记录里，从来不在仓库里。
现在干活的换成了 Agent，它没有可以随口一问的同事。所以要尽可能把这些东西变成 Agent 能读到、能用上的形式，也就是让仓库变得 agent friendly。最基础的是四样：一份 AGENTS.md（在 Claude Code 里是 CLAUDE.md）、CI/CD、文档，以及一份 repo index，也就是给 Agent 看的仓库地图。但需要做的远不止这些：怎么记录「当初为什么这样决定」，怎么让一个 Agent 知道另一个 Agent 正在改什么，怎么处理 issue 之间的依赖和冲突，大家都还在探索。
这些做法看起来很朴素，很多人不会把它们和 Harness 联系起来。但它们在模型外面，又直接决定了模型用得好不好，当然属于 Harness。
我自己这个博客的仓库就是一个例子。CLAUDE.md 里有一条规定：不要直接 push 到 main，先推到分支，等我看过预览再合并。 这条规定是出过一次问题之后才加上的：有一次 Agent 写完一篇文章，直接推到了 main，而 main 是自动部署的，那篇文章在我看过之前就上线了。Agent 并没有做错什么，是我没有告诉它。现在这条规定写在那里，每一个新会话进来都会先读到。
视频里，Robert 说他开发 Claude Tag 时的主要精力也放在这一层。他们大量使用 Claude Tag 来开发 Claude Tag 自己，所以他最关心的是开发环境对 Claude 是否足够友好：它能不能自己把软件运行起来，能不能自己从头到尾完成验证。
Boris 讲的另一件事也说明了这一层的分量。Bun 从 Zig 重写为 Rust：Bun 团队的 Jarred 每逢新一代模型发布，就把这个任务交给它试一次，直到有一代模型做成了。按 Boris 的说法，那是一个 prompt 加上一个调度大量 Agent 的工作流，一共运行了 11 天。这件事能成，关键不在提示词，而在于 Bun 和 Node.js 本来就有一大套现成的测试，结果对不对随时可以验证。「能不能验证」比「指令怎么写」更重要，而能不能验证，取决于仓库这一层。
顺着 agent friendly 再往前想一步。当一个人已经 AI native 了，习惯了把事情交给 Agent 去做，接下来要解决的问题，就是怎么让他所在的组织也变得 AI native。让一个仓库对 Agent 友好，和让一个组织对 Agent 友好，本质上是同一件事：把原来只在人和人之间流动的信息，变成 Agent 也能拿到的信息。区别只是范围从一个仓库，扩大到了整个组织。
第三层：整个组织#
第二层里那些写不进仓库的东西，大部分就留在这一层：团队的聊天记录、文档，还有人的脑子里。这一层涉及的也不再只是开发团队，还包括运营、增长、设计。
我把工作放进飞书、把个人项目放进 Telegram，本质上就是把 Agent 放到这些信息所在的地方。以前遇到问题要去问同事，现在 Agent 和同事在同一个 IM 里，它可以自己去翻之前的讨论，也知道一件事该去找谁。
Thariq 在视频里讲了一个完整的例子。他想做一个内部工具，需要很多人的支持。他先问 Claude Tag：我有这样一个想法，应该找谁聊？拿到名单之后，他让它出 mockup，整个过程都在 Slack 里，用手机就能看。接着由它来实现。他不确定这个工具是否真的好用，于是加了很多埋点，部署到内部；Claude Tag 替他留意，有人反馈就提醒他。后来他从数据里发现用户没有走完整个流程，想要改进。他原本打算直接说「我有个主意，你照着做」，后来改成了「你去想办法改进这个漏斗，给我几个方案」，自己的主意只作为其中一个例子。
在这个例子里，写代码只占中间的一小段。前面是找人、对齐想法，后面是埋点、看数据、收集反馈，这些原本是产品、运营和增长的工作。
到了这一层，Harness 要回答的问题变成了：团队的决定记录在哪里，Agent 能不能读到？它可以代表谁发言，可以主动联系谁？真实用户的反馈通过什么渠道回到它手里？我上一篇讲权限隔离的文章写的就是其中一个问题：同一个人背后的工作 Agent、个人 Agent 和群里的 Agent，各自能看到什么，能对谁说话。
越往外，越是自己的东西#
三层是一层一层叠上去的。单个 Agent 不好用，谈不上五个 Agent 如何配合；仓库这一层没有理顺，让 Agent 在团队里推进事情也无从谈起。
每一层被模型和平台吸收的方式也相同：通用的做法会被收走，只属于你、你的组织或企业的内容会留下来。第一层里，工具调用的机制已经是原生能力，但你的工具是你自己的；第二层里，读仓库、跑 review 会被 coding agent 内置，但团队的规范和历史要自己写；第三层里，运行在 IM 里的 Agent 会成为平台出售的产品，但「当初为什么这样决定」只能由组织自己积累。
区别在于比例。越往外，属于自己的部分占比越高，也就越难被学走。 第三层的主体是一个组织、一家企业自己的决策历史，它不在任何人的训练数据里。
四、做 Agent 产品要算一笔账：Harness 要涨得比模型快#
把前面几节合起来，可以得到一个关于产品的判断。
用户为什么要用你的产品，而不是直接打开 ChatGPT 或 Claude？因为同一件事交给你的产品来做，会更省心，结果也更好。拆开来看，大致是这几样：
- 中途需要人工介入的次数更少，不用每走一步都回来确认。
- 前期不需要花额外的时间沟通需求，它已经了解你的场景和偏好。
- 最后交出来的结果更好，返工更少。
- 有些事情裸模型根本做不了，因为它接不到你的数据和系统。
这些加在一起，就是你的产品相对于裸模型多出来的那一部分。问题在于，模型每隔几个月就会变强一次，这一部分会被它一点点追平。
所以只是「现在比裸模型强」还不够，你的 Harness 必须增长得比模型快。 增长的速度就是斜率：Harness 的斜率要高于底层模型的斜率，否则每过一代模型，你领先的部分就会变薄一些。
示意图。B 的起点可以比 A 还高，但决定结局的是斜率。
Todo List 就是一个例子。在 Sonnet 3.5 的阶段，它带来的领先是实实在在的，有没有它差别很大。但这是一次性的领先，一年之后模型自己追平了。当前领先多少并不说明问题，能不能持续领先才是关键。
斜率由什么决定？我认为主要是三点：
- 试错的成本。 coding agent 的 Harness 这一年发展得这么快，很大程度上是因为代码非常适合试错：输出是文本，可以 diff，可以运行，有退出码，试一次几乎没有成本。
- 有没有别人拿不到的输入。 私有数据、真实用户的反馈、某个行业具体的工作方式。通用的技巧人人都会，也都会被模型学走。
- 多做出来的部分有没有人买单。 也就是有没有增量市场：Harness 每往前做一层，是不是就多出一批原来做不成这件事的用户。如果需求是一块固定的蛋糕，模型每进步一点就替代你一点，那么你增长得再快，也只是在防守。所以做 Agent 产品，一定要找有增量市场的方向。
为什么我不看好 AI 视频的衍生应用#
用这三点去看这半年最热的一类产品：基于 AI 视频、AI 生图做的各种衍生应用，包括做设计的、批量生成短剧的、做营销视频的。其中 To C 的那一大批，我并不看好。原因不是它们现在做得不好，而是它们的 Harness 几乎没有斜率。
先看试错成本。以字节的 Seedance 2.5 为例，它在火山方舟上按 token 计费，不含参考视频输入时每百万 token 70 元。按官方给的公式折算，480p 每秒约 0.67 元，720p 每秒约 1.51 元，比上一代 Seedance 2.0 贵了一半左右。2.5 支持单段最长 30 秒，一条 30 秒的 720p 片子，生成一次就是 45 元左右。coding agent 里「生成、检查、不合格就重来、同时开十路选最好的」这套做法，放到视频上，10 路、重来 3 轮，就是一千三百多元，而最后用上的只有其中一条。
比成本更根本的问题，是质量很难保证。代码改坏了，测试会告诉你；视频的输出是像素，没有 diff，也没有退出码。同一段提示词生成两次，得到的是两条不同的片子。想只改某个镜头里的一个细节，往往要整段重新生成，而重新生成又会带来新的问题：人物的脸变了，场景的光线对不上，前后两段接不起来。「这个镜头好不好」最后只能靠人一条一条地看。上一节说「能不能验证」比「指令怎么写」更重要，视频缺的恰恰就是这一环：没有一个程序能替你判断结果合不合格，「自动检查、不合格就重来」的循环也就转不起来。
结果是这类产品的 Harness 普遍很薄：提示词模板、分镜拆解、素材拼接，再加一个好看的界面。成片质量每一次明显的提升，比如人物一致性、时长、口型，都来自底层模型的换代，而不是产品自身。模型进步带来的好处，所有调用同一个 API 的竞品会同时得到。更麻烦的是，产品里投入最多的那几块工程，比如为了保持人物一致性做的各种变通、为了延长时长做的分段拼接，恰恰是下一代模型最先解决的问题。
再看有没有人买单。To C 这一侧，看一看短剧市场的盈利情况就清楚了。掌阅科技今年 1 月披露了上市以来的第一次年度亏损，当时的报道写得很直接：短剧火爆但难赚钱。这说的是短剧这门生意本身，并不专指 AI 短剧，但它说明下游的利润本来就很薄。AI 确实降低了制作成本，但这个成本是给所有人同时降低的，利润不会留在制作环节。
所以我的判断是：这半年视频生成的热潮里，最大的赢家是模型厂商。 以字节的 Seedance 为例，下游产品无论怎么打折、怎么换算成积分和会员，本质上都是在卖 token；而这些产品本身，并没有在模型之上做出一层足够好的视频生成和编辑 Harness。
生图为什么好一些#
同样的三点放到生图上，情况要好一些。图像 API 比视频便宜得多，能力也成熟得更早，Harness 的可操作空间因此大了很多：一次生成几张再挑选、局部重绘、用各种条件控制构图、搭建节点式的工作流，这些在生图上都试得起，也确实形成了一个规模不小的工具生态。
同样是视频模型，MiniMax-H3 为什么不一样#
所以问题不在「视频」这个品类，而在试错的成本压不压得下来。MiniMax-H3 ↗ 和 Seedance 一样是视频生成模型，但它走了另一条路：公开权重（Hugging Face ↗）。权重在自己手里，就可以量化，可以在低算力的机器上本地部署。按 ComfyUI 官方的说法，量化之后在 RTX 3060 这样的消费级显卡上就能运行。
它的意义在于，把「试一次」的成本从按量付费变成了电费。多路生成再挑选、不合格就重来、围绕自己的素材搭一条流水线，这些在按量计费时算不过来账的做法，现在算得过来了。平民玩家第一次有条件在视频上认真做 Harness，成本也能真正压下来。
需要提醒两点。第一，开放权重的版本原生是 768p、单段最长 15 秒，用的是 MiniMax 自己的社区许可，对地区和商用都有限制，并不是无条件开源，使用之前请自行确认。第二，成本是给所有人同时降低的，它只解决了「试不试得起」的问题；质量怎么验证，有没有别人拿不到的输入，多做出来的部分有没有人买单，这些仍然要自己回答。
哪些情况仍然值得做#
- To B，或者手里有私有数据和流程。 品牌的素材库和视觉规范，电商的商品库，行业的合规规则。这些是别人拿不到的，而且模型越强，它们的价值越大。
- 本来就有 IP 或流量。 这种情况下 AI 只是降低成本的工具，护城河本来就不在 Harness 上。
- 把精力放在可以修改、可以检查的中间产物上，而不是像素上。 剧本、分镜、时间线、图层，这些都是文本和结构，可以 diff，可以检查，可以局部修改。
如果你见过反例，也就是一个 To C 的 AI 视频应用，在底层模型换了几代、竞品都能调用同一个 API 的情况下，依然能持续留住用户并且盈利，欢迎告诉我。
斜率没有办法精确测量，但可以粗略估计。准备一组你自己场景里的真实任务，每次底层模型换代时跑两遍：一遍用完整的产品，一遍用裸模型加最薄的一层封装。把两者的差距连续记录两三代，它是在变大还是变小，就很清楚了。
五、我自己的做法#
模型厂商可以选择「这个先不做，等下一代模型」，因为他们看得到训练计划。我看不到。我用的是别人的模型，不知道哪个问题正在被修复，而我的用户今天就有事情要完成。所以补丁还是要打，只是打法要变。我给自己定了三条。
第一，通用的补丁按短期来做。 从前面的例子看，一块通用的 Harness 能保持价值的时间，大概只有一两代模型，也就是一年左右。这不代表它不值得做：提前一代用上某种能力，在这个行业里就是实实在在的时间窗口。只是我不会再为它投入需要两三年才能回本的工程量。如果发现自己为了绕开模型的某个缺陷，已经写了成千上万行代码，我会先停下来，想一想是不是方向错了。
第二，加补丁的时候，同时留下一个可以重跑的失败案例。 案例要具体：「模型不够主动」没有用，「改完三个文件之后没有跑 check 就报告完成」才有用。新模型发布后，带补丁和不带补丁各跑几遍，不带补丁也能通过，就把它删掉。写给 Agent 的说明文件和 Skills 也一样，隔一段时间就应该清理一遍，而不是只加不减。
删不掉的补丁同样有信息量。很常见的一种情况是「请先向用户确认再执行」，它其实说明权限检查没有在程序里实现，只能写给模型看。这样的补丁不应该删，而应该从提示词移到代码里。
这组案例还有一个用途。我们依赖的平台本身也在变化：Claude Code 那次更新只是一次普通的版本升级，升级之后，Agent 可用的工具就少了五个。底层的模型或平台更新之后，在我自己的任务上是变好了还是变差了，也只能靠这组案例来回答。
第三，把长期的投入放在只属于自己的上下文上：个人的、组织的、企业的。 会被学走的，是几百万用户共有的行为：跑测试、不跑偏、正确使用工具。正面去做一个通用 Agent，没有数据也没有入口，模型一更新，价值就会缩水，这条路我一直不看好。
学不走的，是只属于你、你的组织或企业的上下文：行业里具体的工作方式，团队做过的决定，用户的习惯。这个定时任务为什么设成每小时一次，是为了节省成本，还是因为上游有限流？这些不在任何人的训练数据里，模型再强也推断不出来。智能可以租，上下文只能自己积累。
这也是为什么我认为垂类做得越深，越应该主动接入通用 Agent：把你的 know-how 做成 MCP、插件或者 Skill，接到别人已经在使用的 Agent 上，底层怎么更替都不受影响。前面说 Skill 最后剩下的价值是方便传播，指的就是这种用法。
最后：说回「泄气」#
回到 Gergely 的那句话：今天做的东西，下一版模型自己就会了，让人有点泄气。
我理解这种感受。但它背后有一个没有说出来的前提：一份工作的价值，取决于它产出的代码能存活多久。按这个标准，这一行确实让人泄气，因为模型外面的代码注定存活不了多久。
我不这样衡量。我在模型外面做的东西被模型学走了，说明这件事做对了，说明我比模型早一代看到了这种能力应该是什么样子。代码会被删掉，但「早一代看到」的经验会留在我身上，它还决定了我能不能看到下一层在哪里。亲手做过里面一层的人，最先知道它什么时候稳定了，也最先遇到外面一层的新问题。
视频的最后，Thariq 问另外两位同事是否怀念过去写代码的方式。其中一位说，他以前喜欢打磨 UI 细节，曾经花一整天叠加径向渐变，只为在个人网站上复刻 Mac OS 10.4 的 Aqua 按钮，现在他不会再手工做这样的事了。但他接着说，这让他想起七八岁时想做游戏却不会写代码，只能用 PowerPoint 拼出可以点击的形状；而现在，整个软件工程对他来说都触手可及，不必再因为自己不掌握某项技术就放弃一个想法。
失去的是在某一层上打磨到极致的手艺，得到的是去做更外面一层的能力。
当然，如果你的整个产品只是一块通用补丁，除此之外什么都没有，那么泄气是合理的。它是一个很准确的信号：你的斜率已经落后于模型，该往外走一层，或者往垂类里再深入一层。这句话也是说给我自己的。
所以对 Tibo 的那句话，我的看法是：补丁会被模型追上，这一点我同意，该删就删；Harness 因此在变小，这一点我不同意。变小的只是已经完成使命的那一层，模型之外的工作一直在向外扩展：从一个 Agent，到一个仓库，再到一个组织。你站在哪一层，增长得有多快，决定了你的产品是在被模型取代，还是在被人需要。
如果你手边正好有自己的项目，可以用那个问题检验一下：假如模型已经足够聪明，这一块还有没有存在的必要？欢迎来 QQ 粉丝群讨论： ，群里的那个 Agent 也可以直接 @。
参考#
- The Pragmatic Engineer：Building Codex with Tibo Sottiaux ↗
- Claude Code 团队内部对谈：How the Claude Code team uses Claude Code ↗
- Boris Cherny 在 YC Startup School 2026 的分享：逐字稿 ↗ / 视频 ↗
- Claude Code v2.1.233 release notes ↗
- Skills：obra/superpowers ↗、mattpocock/skills ↗
文中对播客和视频内容的引用均为按原意概括，不是逐字引用。第四节涉及的价格和授权信息变化较快，请以各家官方页面为准。