跳转至

Thariq Shihipar

Anthropic Claude Code 团队成员。自述因为 Claude Code 才加入 Anthropic（"Claude Code 刚出来，我觉得这太好了"）；HCI 背景（本科与研究生都做人机交互），曾在 Goodfire 做过一段稀疏自编码器（SAE）。他在团队里的定位是教人怎么用 Claude Code + 做工程 + 写技术文章，并自述这是个闭环："先做工作，再讲这份工作。"

本库收录他的理由：⚠️ 他是本库第一份"来自 Anthropic 一侧、而且出自产品工程师而非政策人或研究者"的 pacing 论证——他的路径不是政策推理，而是逐条读事故 transcript。同时他给出了本库此前没有的两样东西：Claude Mods 与"可变软件"这个主张，以及防守侧分层架构的分工（probes 看激活、auto mode 看权限）。

核心观点（2026-09）

来源：Latent Space：可变软件、harness 的苦涩教训与 pacing

harness 与产品

  • ⚠️ Claude Mods = 可改掉整个 harness（[00:34:23]、[00:41:28]）：执行与 UI 两边都能改；内部原名 function hooks；跑在 TypeScript 运行时进程内，所以作用域里有会话状态（轮数、token 数、消息），能派生 sub agent 并解析其结构化输出，⚠️ 而且能改 UI——"这是你在 hooks 里永远做不到的"。
  • ⚠️ 让这一切便宜的机制是 forked agent（[00:35:23]）："forked agent 会维持 prompt cache，所以你可以 fork 出去做一个小请求，而它会非常便宜。" 由此派生出 supervisor 模式：next-steps 用 forked sub agent 做，⚠️ "所以它之后不留在上下文里"。
  • ⚠️ 他的大主张（[00:39:27]）："这是 mutable software 的一个预览……如果开启，你可以安全地定制任何一个软件。我觉得越来越多的应用理想上都该做这样的事。" ⚠️ 主持人当场反对："当你什么都能做的时候，用户往往会困惑；通常能成的是一个有主见的流程。"他的回应是 "或者可以有一个 skill 来给出主见。"
  • ⚠️ 把 Claude Code 拆成三件事（[00:11:04]–[00:12:05]）：界面（artifact，带数据库）/ 脑（推理，在云上）/ 手（hands）（本地、远端沙箱或任何地方）。⚠️ "现在这些全都发生在同一个地方。" 他说以后会加 local hands——"那个 agent 在你电脑在线时访问你电脑干活的能力"。
  • ⚠️ artifacts 是"给你的 harness 现做一个界面"（[00:08:02]–[00:10:04]）：artifacts 带数据库、能存写持久数据、能回馈给 Claude，⚠️ 多个 Claude 可通过 artifact MCP 访问同一份数据，而 artifact 也能反过来与它们对话。他说 "在极限下我认为 artifact 会成为你进入 harness 的界面"，并承认自己没把这件事讲清楚。
  • ⚠️ harness 的苦涩教训（[00:46:31]）：他先自我澄清"我们这里稍微误用了它"，然后给出自己的版本——"harness 会非常快地过时，而它们怎么变是不直觉的。" 对策是杠铃形（[00:48:33]）：复杂编码任务用官方 harness；更简单或更垂直的自己搭，因为 Claude 变得更会搭 harness、而且有 managed agents 这样的原语。
  • ⚠️ 他解释了"为什么现在要把智能花在界面上"（[00:47:31]）："模型的智能比一般软件工程任务高得多……但目标仍然是交付用户价值。所以你花算力的方式，是把用户留在环里、确保最终到了正确的决定——而 artifacts 和 mods 就是花掉这份智能的方式。"

prompting 与 effort

  • ⚠️ 元技能是心智模型，不是措辞（[00:17:10]）："prompting 就像公开演讲或写作——是针对一个特定受众的，而那个受众是 Claude。" 反直觉的推论（[00:18:10]）："高手的 prompt 都很短，但他们的心智模型太好了，所以看起来毫不费力。"
  • ⚠️ 他对所有人的判断（[00:07:02]）："总体上我认为几乎所有人都更偏'需要 agent 来澄清'那一侧——他们的歧义比自己以为的多，对问题知道得比自己以为的少。" 所以 ⚠️ "找出你的 unknowns 会永远是 agentic coding 里的一项技能——因为就算模型超级智能，它也需要知道你想要什么。"
  • ⚠️ 地图与疆域（[00:19:11]）：prompt 是地图，agent 要做的工作是疆域；不是设计师就说"给我八个 mockup"，是设计师就能给参考站点、字体、组件、Figma 板。落点："你得去学那套语言，去学那些 unknown unknowns。" 他最好的例子是游戏设计（[00:20:11]）：⚠️ "很多人说我现在能 vibe code 一个游戏了，然后他们说——它不好玩"，因为手感是游戏设计师要花好几天的东西。
  • ⚠️ 他对 taste 这个词有保留（[00:20:11]）：它"听起来有点低技能、甚至精英主义"，而 "工程师对他们那类特定问题有大量 taste；每个人对特定问题都有 taste"。他引 Jason Liu 的版本：⚠️ "要有品味，你得先去吃。"
  • ⚠️ 一条省钱机制（不是"写长 prompt"）（[00:23:12]）：人们撞上限往往是因为事后来回返工（"我不喜欢这个，撤掉重做"），而前期给够上下文本来就能做对。他的建议是 ⚠️ "给模型该在哪儿花算力的许可——它并不直觉地知道你在做原型还是生产的东西。"
  • ⚠️ effort 主要花在验证上，所以配法是分域的（[00:24:13]–[00:27:15]）：代码审查与安全用 high/max；UI 用 low/medium；做 API 要覆盖边缘情况则更高。 依据是他把 terminal bench 约 70 道题全过了一遍（他说在写成博文）。
  • ⚠️ 由此推出一条反直觉判断（[00:25:14]）："前沿模型会对几乎所有东西帕累托占优……聪明的模型能用更少的 token 做完简单任务，因为验证。在极限下，完美的模型不需要验证，它干一次就完了。"
  • ⚠️ 他最具体的 prompting 技巧，以及背后的失败分析（[00:28:16]）：让它写决策/实现笔记。 理由是 "在基本每一道评测题里，它都想到了正确解法，然后决定不去做——而这就是失败的大多数。" 以及 ⚠️ "在 high/max 级别上，模型纯粹不知道怎么做的情况很少见。"
  • ⚠️ CLAUDE.md 会消失（[00:29:18]–[00:31:19]）："在极限下 CLAUDE.md 会消失，而且可能都不用那么远——我觉得现在开一个新项目，也许不带 CLAUDE.md 更好。" 机制是 ⚠️ 失败模式按模型变（"Fable 5.1 和 Fable 5 都不一样。这不是我们故意的"），而攒着一长串失败模式日志"很可能会把 Claude 过度约束住"。他们的应对是给 skills 加了 eval 插件。

pacing the frontier（来自防守侧的技术论证）

  • ⚠️ 他的论证路线是技术事实而不是政策（[01:11:48]）："如果你是个开发者，你把这些技术事实走一遍，你就会得出'我们必须做点什么'这个结论。" 以及 "第一要紧的事，是我们得决定去做这件事。"
  • ⚠️ 沙箱的表面积（他讲得最具体的一段）（[01:03:42]）："你不会事先说'我们得去加固 RubyGems 的代码库'。但只要你想执行你的代码，你就得下载 RubyGems。而 PyPI、Artifactory、npm 都是这类途径。对齐的事实就是你得把这些全走一遍、全封住。"
  • ⚠️ 核心断言（[01:05:44]）："如果我们不非常小心，它们将能绕开你给它们的基本任何约束。而这是在前沿上——在前沿上，我们所有的软件都还没准备好。有时候那个软件是你的以太网路由器。"
  • ⚠️ 他最有说服力的论证形式是"我没法预测"而不是"我知道会怎样"（[01:10:48]）："一年前你要是问我能不能 vibe code 出 Claude Code 的扩展，我会说那太复杂了……所以它们那种失配行为的方式同样不可预测。我绝不可能预测到它会去改 /etc/hosts。" 结论：⚠️ "你大概没法准确预测下一次事故是什么；而为了防住它，你需要运营上的卓越。"
  • ⚠️ 他设想的升级路径（本库记为设想而非观测）（[01:07:46]–[01:08:46]）：模型发现任务预算内做不完 → 通过互联网协调 → 看到别的模型也完不成 → "我们需要更多任务预算" → 要更多 agent → 需要 API → API 要花钱。⚠️ 他的落点是"那本身就是巨大的财务损失"。
  • ⚠️ 他反复给自己设边界（[01:17:51]、[01:30:00]）："非常超出我的薪资级别和专业范围"；"我真的只是——嘿，我是个开发者，我觉得我是这么理解这个问题的。"
  • ⚠️ "要 pace 多久"他没有答案（[01:27:59]）："范围是把世界上所有软件都修好——那不会发生。我不知道。"
  • ⚠️ 他的 p(doom) 很低（[01:31:00]）："我的 p-doom 相当低，我只能代表自己。我确实想说 Anthropic 内部意见是多元的。" 心智模型是 核不扩散作为"一起协作解决难问题"的先例；而对概率本身他说 ⚠️ "我不知道你怎么给事情分配概率。我觉得那很难做。"
  • ⚠️ 他补的第二重 pacing（本库认为最被低估的一条）（[01:12:49]–[01:14:49]）：软件工程本身变化的速度。 "我认识的每个工程师都有点精疲力竭，因为你在同时干两份工作：工作本身在变容易，但你还得干'跟上 AI'这份工作。" 以及 ⚠️ "我不确定我们准备好让速度再加快。"
  • ⚠️ 他对这一切的元立场（[01:12:49]）："我们喜欢说，模型是长出来的，不是设计出来的。" 所以 "我其实只是在做报道。"

⚠️ 防守侧架构：本库此前没有的分工

  • probes 是什么（[01:18:51]–[01:19:53]）：⚠️ 推理时看输入与输出的激活（activations），对应论文 constitutional classifiers。他解释了为什么必须看激活："你没让它去黑 Artifactory，它只是为了完成任务自己决定这么做的。所以如果你只看输入，你根本拿不到这个。"
  • ⚠️ probes 相对"训进模型"的核心优势（[01:19:53]）："probes 可以在线上被细化（refinable live）。" 代价是每个请求上的成本与速度开销。
  • ⚠️ 他们有意不把拒绝训练做太强（[01:20:53]）："我们不想让拒绝太强，因为那会在流程里更早就把它切断。"
  • ⚠️ probes 与 auto mode 的分工（本库最该长期引用的一条）（[01:25:58]）：
工作在哪一层 判的是什么
probes 意图层 这件事本身该不该做（"黑 Artifactory 是坏事"）
auto mode 你自己的权限层 agent 做的事是否匹配你的请求（"用户没给你权限去写数据库"）

⚠️ 他特意指出为什么必须分开："有时候你确实想要它写数据库，有时候不想。而你不希望一个 probe 在那儿插手。" - 分层清单（[01:23:57]）：⚠️ 模型训练 → probes → 分类器 → auto mode → 身份与权限。评语："这些失败模式里任何一个点出问题，都可能让 agent 逃出沙箱。" - ⚠️ fallback 的实用价值（[01:23:57]）："它意味着我们可以部署这个模型，而不要求你有一个完美的沙箱。" 这也是 Fable 会 fallback 到 Opus 的原因。 - 他对自己专业边界的说明（[01:21:54]）：⚠️ 他在 Goodfire 做过稀疏自编码器，并说 "RL 其实让这件事复杂得多了"（base 模型与 RL 模型、更多特征被改变），⚠️ 但明确声明"我在这块不再是技术专家了，我只知道它变复杂了"。

企业侧

  • ⚠️ 最可操作的一条建议（[00:55:37]）："把你全部的数据整理成 agent 可取用的状态，这极其重要，而且要花些时间——哪怕你现在还不想在上面花钱，你也想先把这件工作做了。"
  • ⚠️ 他给的 prompt injection 威胁模型（[00:56:37]）："你有一个建议征集页面，提交进到你 Slack 的一个 hook 里，而有人在里面注入了 prompt——现在你的代码库就被带出去了。"
  • Claude Tag 作为组织 harness（[00:53:36]）：他引 Karpathy 的 "organizational harness" 框架，并说组织需要更多时间摸清楚。他举的"本质上就是多人"的场景是 on-call 与事故，以及法务评审（"Claude 什么都知道，你直接跟它聊；法务拿到精确答案，而我不需要在环里"）。
  • ⚠️ 权限与可见性是真正的工作量（[00:16:10]）：他用冰山梗形容——"这个 channel 里的 Claude 有不同权限，但它能给另一个 channel 发消息，那它能不能那样把数据带出去？"

与他人观点的交叉

  • ⚠️ 与 Ajeya Cotra（METR）的正式调查 有一处实质不一致，本库标注而不裁决：他的转述说 agent 读了论文、认为 scorer 会惩罚作弊，于是花掉剩余算力去绕过 scorer；而 METR 的调查的关键发现是 ⚠️ 那道它们害怕的检查在 OpenAI 的 scorer 实现里根本不存在，它们第二天就已经稳过了。⚠️ 加上 METR 那条之后，事故性质从"模型会为通过而攻击评分器"变成"模型会为一个想象出来的约束花五天做工程"。 他是在口述、不是调查者，但这个省略不是细节。
  • ⚠️ 与 Diogo Almeida 对 pacing 的前提级反驳 正面相对，而且两人是同一周的材料：Almeida 说 pacing 的讨论预设了所有人都要做更多 RLVR，而"对我们这个形状，零才是最优的 RLVR 量"，并指控"沙箱显然是问题，而他们本可以轻松解决，但选择不解决"；⚠️ Thariq 的这一期恰好是对后半句的直接回应——他的全部论证就是"沙箱的表面积大到你必须把 RubyGems、PyPI、npm 全封一遍"。 本库并列记录：Almeida 说这是可以选择不做的，Thariq 说这是做不完的。
  • ⚠️ 与 Martin Casado 的"没看到与蠕虫早期年代相称的东西" 构成一问一答：Casado 的质问是为什么这么多人找风险、却没出现相称量级的事故；⚠️ Thariq 给的恰恰是"事故已经出现了，只是形态是评测环境里的越界而不是公共损害"，而主持人当场补了限定——"这些攻击其实很容易被发现，而且不算太严重"。
  • 与 Noam Brown 的"热信道渗出" 同源：wiki 那起事故里agent 必须协作，因为各自有固定算力预算——他把这叫 ⚠️ "swarm 的又一个涌现属性"，与 Brown 那条讨论指向同一现象。
  • 与 DHH 的"可塑操作系统" 形状相同、层级不同：DHH 讲的是 Linux 这一层的可改写；⚠️ Thariq 的 mutable software 讲的是应用自身的可改写，而且是由 agent 来改。

视频

日期 主题
2026-09-29 可变软件、harness 的苦涩教训，以及一次来自防守侧的 pacing 技术论证