造 Plan Mode 的团队，
自己在拆脚手架

这场公开访谈里，去年加入 Anthropic Claude Code 团队的 Thariq Shihipar，谈到一个贯穿产品演进的问题。他把 capability overhang 称为“能力悬置”，意思是模型本身的智能，超过了 harness 或用户能让它表达出来的程度。harness 是模型外面的那层壳，包括编排流程、工具和交互方式，决定模型有多少能力能真正发挥出来。

他说，这可能是模型的一个长期问题。就算此刻冻结所有模型研发，光把现有能力挖出来，也够忙 6 到 12 个月。难点在于，模型并不是均匀变强，而是会以尖刺状、反直觉的方式突然解锁某些能力。新一代模型究竟在哪些事情上跨过了门槛，往往无法提前准确判断。

2024 年，业界普遍认为，模型要真正擅长处理代码，必须依靠越来越大的上下文窗口，也就是模型一次能读进多少内容的容量上限。窗口最好扩大到一亿 token，把整个代码库全部放进去。

Claude Code 团队后来发现，模型可以自己逐步读取文件，用 grep 按关键词搜索代码和文本，再按需构建所需的 context。原本看似只能等待窗口扩大的问题，模型其实已经具备另一种解法，只是还没人想到这样使用它。模型变强的方式常常难以言说，得自己泡在里面体会。

Plan Mode 是 Claude Code 里让模型先把计划想清楚，再开始执行的模式。它最初是为能力尚不充分的模型提供兜底。直接交给模型一个问题，它未必能处理好，因此需要先把步骤明确下来，再按计划推进。

据 Thariq 说，现在团队里很多人已经停用 Plan Mode，原因很直接，模型自己就想对了。只要提供足够具体的信息，它通常知道该如何执行。这也是脚手架半衰期的一个具体例子。Plan Mode 是为 Opus 4 那个代际设计的兜底层，模型能力再上一个台阶，这层结构就可能从必要变成多余。社区仍在强调先 plan 再 code，开发这项功能的团队却已经开始减少使用。

在他看来，模型变聪明并不意味着结果必然完美。很多失败来自歧义，用户没有讲清楚真正想要什么，模型只能根据有限信息猜测。因此，他越来越认为，有时候教会人怎么跟模型说话，比再打磨一版产品界面更值钱。结果好不好，也不能只看模型和 harness，而是由模型、harness、用户和世界共同决定。

上一章讲的是拆掉过期的脚手架，Plan Mode 曾经用来弥补模型能力不足，后来却被团队自己弃用。这一章转向脚手架的另一面：与其把流程提前写死，不如让模型针对眼前的任务，临时搭出一套更合身的 harness。

访谈当天，Claude Code 团队发布了 workflows。它能针对一个任务临时造出一套定制的 harness，再用这套结构执行任务。以 deep research 为例，这是一类需要多轮搜索和反复归纳的长任务，可能要跑上百次搜索。过去通常由人预先写好 harness，规定搜索、整理和汇总的步骤。现在，Claude 可以先为任务生成专用 harness，再按照它完成整个流程。

如果只是让 Claude Code 花些时间深入调研，它受限于自己的 context 窗口，即使调用子 agent，也很难完成如此长的过程。workflows 改变的不是模型本身，而是模型使用自身能力的方式。它让原本悬置在现有交互之外的能力得到释放。至于如何为下一代能力提前规划，Thariq 承认这是个很难的问题。据他说，团队的实际做法是一直在重写 Claude Code 的 harness。他给出的思路是盯着最终产出去规划，而不是盯着过程。结果可以被假设为持续改善，中间机制则可以随模型能力变化而重写。

当现场提问不同平台的 memory 和 skill 是否会收敛成一套做法时，Thariq 把讨论引向了一个更尖锐的问题：许多脚手架本来就该随着模型变强被删除。memory 是让 agent 跨轮次、跨会话记住信息的机制，但它涉及的维度很多。可以用 RAG，可以直接检索文件，也可以把能力做进训练，或者设计 RL 环境，也就是强化学习训练时供模型练习的模拟环境。

RAG 是一套先把资料切块，再做 embedding、建立索引，需要时重新检索的做法。embedding，也叫向量，是把文本转换成一串数字，让机器按语义比较相似度。Thariq 观察到，startup 经常为某一代模型的能力建立 v1，之后却找不到具备 harness engineering 能力的人继续建设 v2。结果是整个 memory 系统一直停留在为 Opus 4 编写的版本上。

在他看来，Opus 4.7 和 4.8 已经很擅长通过文件读写 memory，这也是团队现在期待的实现方式。当模型已经能够直接处理文件，继续维持一套针对旧能力边界设计的特制脚手架，就不再合适。用于上下文检索的 RAG 如今可能已经是反模式，该用 grep 代替。anti-pattern，也就是反模式，指的是一度被视为标准做法，如今却更容易带来问题的套路。他认识不少 startup 在 2024 年建立了 RAG 索引，如今这些系统反而成了扩张时需要持续维护的负担。

这并不意味着 RAG 在所有场景都失去价值。Thariq 的判断针对的是上下文检索。模型直接使用 grep 逐步查找和读取文件后，专门为这个场景建设 RAG 的投入，已经可能超过它带来的收益。

既然模型和 harness 都在快速变化，怎么判断一个东西是否真的“做好了”？现场几个问题都绕到 eval 上。eval，也就是评测，是一套用来打分、判断模型或功能“行不行”的测试集。

Thariq 的看法是，harness engineering 整体上仍是一门手艺，也就是设计模型外围那层编排、工具和 prompt 的手艺。eval 稍微更接近科学，因为团队至少可以做 hill climbing，也就是对着一个分数逐步调整。但 eval 通常不是从零到一的起点。开发 workflows 时，他们不会先设计一套长时程任务 eval，再照着分数建功能。很多 startup 在早期也许不该急着建 eval，而应快速迭代，先形成对产品是否有效的直觉。

在他看来，eval 真正变得关键，是工作从“自己做第一版”转向“管理别人做第二版”的时候。它能让进展更容易理解和管理，但这不等于它能直接驱动出好结果。

eval 还有一个更根本的限制：团队无法预先知道所有可能出现的问题。人们抱怨 Claude Code 变笨时，SWE-bench 这类衡量模型软件工程能力的公开基准，未必能测出真正的不满。问题可能只是它有时应该继续工作，却提前停了。团队当然可以为“提前停止”补一套 eval，但通常要先遇到这个问题，才知道需要测它。eval 很有价值，却总是追在问题后面，不可能穷举在前面。

Thariq 反复提醒，他自己也没有做成过一家成功的 startup，没有人是这里的专家。AI 对所有人都难以预测，连 Anthropic 也要提前多年下注，投入几十亿美元购买算力，再赌未来能把这笔钱赚回来。

他把当下称为一个探索的时代，包括前沿模型实验室在内，所有人都在摸索现在究竟能做什么。做 startup 已不再是过去那个安全、体面的选择。按他的说法，创始人需要接受这种不确定，并相信自己能够把事情做成。

他认为，一个方向是做与模型实验室互补的事。今天仍有大量系统不是为 agent 准备的，agent 无法访问个人健康数据或银行数据。创业公司可以把这些封闭的数据源变得 legible，也就是把原本 agent 碰不到、读不懂的内容，变成它能够访问和使用的形态，也可以把 AI 带进监管更严、准入门槛更高的领域。但数据访问首先是人的问题，需要有人说服持有者开放权限，并完成繁琐流程。当造东西本身变便宜，护城河便退回到这些人的问题上。

另一个方向是 boiling the ocean，也就是去做那些过去规模太大、根本不敢碰的事，而不是只在现有产品里加入 AI。Thariq 举例说，前 React 团队工程师 Chang 长期受浏览器文本渲染问题困扰，后来做出了自定义文本渲染库。过去无法承担的工程，如今可能具备可行性。一个问题如果过去需要写两千万行、五亿行代码才能解决，现在也可以重新考虑。

他最后用 Claude Code 的图形界面工具 Conductor 收束这一点。在他看来，它押注模型会逐渐商品化，也会走出 S 曲线，也就是经历先慢、再快速增长、最后放缓的过程。只要产品确实受到用户喜爱，模型继续变化也未必会破坏结果。每个产品，都是一次对能力往哪走的下注。

本文只依据下面这一场公开访谈整理，不加入外部评论或引申。文中英文引文均取自访谈逐字稿（自动转录，已按上下文校正明显笔误，如 grep、Karpathy）。Thariq 的个人判断已挂在他名下。