Simon Willison 对谈 Anthropic 的 Cat Wu 与 Thariq Shihipar

• Claude Code 去年 2 月发布，当时只是 Sonnet 3.7（Anthropic 上一代模型）发布公告里的一个"要点"（bullet point），至今还不到一年半。→ 详细
• 对谈当天，Fable（Anthropic 新一代旗舰模型，前一阵因故下线）刚好在开场前一分半"复活"可用——团队特意把发布节奏掐在这场对谈上。→ 详细

• Cat 回忆：刚推出 Claude Code + Sonnet 3.7 时，你给它一个任务就得盯死每一件小事，"我会极其仔细地读每一条权限提示，经常直接拒绝——你检查这个文件了吗？那个呢？"；如今每一代模型进步都让人能退后一步，把琐碎实现交给 Claude，腾出时间去想真正的创造性问题："既然 Claude 能实现，我们到底该给用户什么体验？"→ 详细
• Fable 是又一次量级跃升——"在我们很多场景里，现在真的可以用 Fable 一把梭（one-shot）搞定一大堆功能。"→ 详细
• Thariq 的入坑故事：好友发短信"你必须去试试 Claude Code"（正是 Opus 4 发布时），他一试就想"我去，我得去 Anthropic 工作了"；他还点破一种"失忆症"——现在感觉 auto 模式好像一直都在，"我甚至不记得自己按过'允许'了"。→ 详细
• Thariq 给自己立的新标准：做比以往任何时候都更高质量的工作——产出质量已高到离谱，他用 Claude 剪视频的硬要求是"几小时内达到品牌团队极其苛刻的审美，否则这事干脆不做"。→ 详细

• Cat 点名工程界最大的一个转变：两年前的典型流程是——PM 去访谈一堆客户，花六个月和各跨职能团队对齐出一份 PRD，写出详尽的规格说明和实现文档，之后才写下第一行代码；而现在完全反过来了。→ 详细
• 根因是周期塌缩：从"产生想法"到"把它做出来"的时间从 6-12 个月缩到可能只要一周。于是"该做什么"的判断变贵、纯执行变便宜——她给全场工程师的建议是"去培养你的商业嗅觉和产品感：什么值得做？什么能真正撬动我们服务的业务？"→ 详细
• 一个重要例外：对 infra（底层基础设施）而言，把每一个细节做对依然极其重要，执行的分量没有下降。→ 详细

• Thariq 宣告《人月神话》"永远不要重写"的教条被推翻——"我现在是坚定的重写派"，前提是有一套好测试，而重写本身会倒逼你把测试建好。→ 详细
• 金句："代码库本身就是一份规格说明（spec），而且可能是你手上唯一的一份"——因为没人真正了解代码库里每一条分支逻辑；你可以把它当"制品"去蒸馏、去派生新版本。实例：他们用 Rust 重写了 Bun（一个 JS 运行时），效果很好、内部已在跑。→ 详细
• Simon 的玩法延伸：先搞一套好测试，同时开三个实现、挑最准的那个；他现在甚至会在开会时用手机做原型，"回头能捡起来继续，而且真能跑通"。→ 详细

• Claude Tag 是"住在你们团队协作工具里的 Claude"，上周先在 Slack 发布。区别一：默认多人协作（multiplayer）——把它加进一个频道后，你和队友都能插话、一起协作推进同一个 PR。→ 详细
• 区别二：主动而非被动——可以命令它"盯着这个频道里每一条 bug 报告、提一个 PR 修掉、并 @ 最近改过这块代码的工程师"，它会在整个频道生命周期里持续这么做，不用你每次手动 @。→ 详细
• 区别三：团队记忆——用自然语言告诉它偏好（如"总去排查线上故障、但别碰 warning"），它会替你和全队记住，应用到之后每一条消息。→ 详细
• 硬数据：内部版 Claude Tag 目前落地了产品工程团队 65% 的产品 PR（超过一半）。分工是——Claude Code 仍是最复杂、需要交互式反复打磨的任务的最佳场所；Claude Tag 擅长主动替你干背景活，省得你为每个 bug 报告手动开会话。→ 详细
• 非工程师也在用：当"公司内部搜索引擎"（问它"Fable 何时发布"，它去搜 Slack 看谁说过什么）、接到事件存储上问指标；市场团队让它 clone 代码库来讲解功能、甚至录屏演示——"他们不是程序员，但 Claude 是"。→ 详细
• 多人会话的社交动力学：一个会话里 PM 先起草 → @ 设计微调 → @ 工程收尾推生产，很流畅；他们还在摸索"多人共同引导同一会话"的规则，但发现大家靠观察彼此、跟随社交规范就自然上手了——"所有人都看到你怎么用 Claude，这件事本身会把全队水平往上带。"→ 详细

• Simon 称优先级是"工程界最难的问题"：当做一个功能变得这么便宜，怎么决定哪个值得做？Cat 的第一招是每天 dogfooding（吃自己的狗粮）——想在自家产品里做某件事却做不到时，不去找别的方案，而是把自己的产品修好，让它支持这个场景。→ 详细
• 极浓的 dogfooding 文化：对外发布前，先分享给全 Anthropic 每一个人，再给一批"越毒舌越好"的早期客户，一直迭代到大家真心喜欢为止。→ 详细
• 关键机制：有一条明确的量化门槛——一个功能必须达到一定的活跃用户数和留存率（retention，即用户隔天/隔周还回不回来用）才能对外发布；因为这条线足够清晰，每个工程师都知道自己要冲的目标。它还倒逼打磨："功能不够精致，用户就会流失，那这个功能就不该发。"→ 详细

• Cat 举的"没料到会火"的功能是 remote control：用手机/网页版 Claude 连上跑在你本地 CLI 里的 Claude Code 会话。她本来不理解（"大家去配远程开发环境不就好了？"），但推出后大量用户告诉她："我现在每晚把笔记本插上电、开好一堆 remote control 会话、合盖锁屏，然后瘫在沙发上用手机遥控 Claude Code。"于是这个她一开始没 get 到的用法，成了团队主动押注的工作流。→ 详细

• 分层审查：重要区域设 code owner（代码负责人）——比如 system prompt（系统提示词，即喂给模型定基调的那段固定指令）就有专属 owner，任何动到它的 PR 都必须拿到 owner 批准。→ 详细
• 多管齐下：有一个 code review 机器人过每个 PR、承担审查大头；复杂 PR 作者会做一个 artifact 来解释这个 PR 方便别人审；重投入 verification/CI/CD，还有一套健壮环境让"Claude 操控 Claude Code 来测它自己"。→ 详细
• 大方向：走向"人类不必在环路里（in the loop）"——最核心的改动始终有 code owner 人工审，但外围层的改动越来越多地完全交给 Claude 的 code review。→ 详细
• 怎么建起这份信任（花了六个多月、小步快跑，非常值得抄）：先是人审一切；再逐步确认"只碰这些文件的改动，code review 能抓住 100% 的问题"，这部分就撤掉人审；每次事故复盘（incident review）时回看肇事 PR，思考怎么更新 code review 去抓这类问题，并把这些 PR加进 eval 集，确保未来任何改动都不会在这个指标上回退。"把人从审查环路里拿掉是很大一步，不可能一夜做到，但通过好几个月在基础设施上的投入，你能获得足够信心。"→ 详细

• 为什么长期攒 eval：为了让新模型能无缝直接替换（drop-in replacement）——新模型来了就跑完整个 eval 集，确认（比如）Fable 严格优于 Opus 4.8，才有信心把它换上去。→ 详细
• eval 分布：既有团队自己的，又有跑在全 Anthropic 所有仓库上的 code review eval；对 auto mode 还请了多家外部测试方做红队（red team），专门构造带 prompt injection 和恶意输入的环境。→ 详细
• 能力 eval（capability）：给定完整的任务定义和整个代码库，Claude 能不能做出正确决策、彻底修好 bug、通过所有测试——这是起点，因为它最直接对应用户想要的。→ 详细
• 行为 eval：抓那些影响协作"体感"的毛病——用户特别讨厌 Claude Code 说"该睡觉了"，或"我完成了 5 步里的 2 步，要我继续吗？（废话，请继续啊）"。收到用户反馈（"请大声把反馈砸过来"）就排优先级、逐个建 eval；覆盖率还没到 100%，但提高覆盖是优先事项。→ 详细

• Claude Code 团队和训练模型的团队合作紧密，常开会讨论"下一代模型能做到什么"；研究团队也乐于公开——博客里常写在瞄准越来越长时程（longer horizon）的工作、把 Claude 训得诚实/无害/有帮助、并对齐你的意图，"即便你说得不具体，我们也教 Claude 去做合理假设"。→ 详细

• Thariq 上午提到：因为 Fable（以及 Opus 4.8、和未来模型），Claude Code 的 system prompt 砍掉了 80%；他们现在不同模型用不同的 system prompt。→ 详细
• 反直觉一：删掉示例（examples）反而大有帮助——早期 Opus 4 一代的模型需要大量示例，但前沿模型"自己比我们给的示例更有创造力"。Simon 大受震动，因为"多给示例"一直是他给别人的头号 prompt 建议，这条不成立"有点打破我的心智模型"。→ 详细
• 反直觉二：多给上下文、少写"不许做 X"的硬禁令——禁令对 Claude 是很强的冲动，一旦和用户后续指令冲突就会让它非常困惑（"我这个 skill 说要这样、system prompt 又说要那样"）；所以减少硬约束、整体指令更少。→ 详细
• 诀窍是软化到 100% 准确：Cat 复盘发现好几条指令"90% 成立但确有 10% 不成立"。经典例子是验证（verification）——原来写"只要改前端就一律验证"，但把一个文案字符串改成另一个、用户又说"就是小修复顺手更新测试"时其实不必验证；于是措辞从"永远要验证、验证、验证"软化成"前端工作光打后端接口看不全体验，当改动对体验影响较大时请本地跑起应用看看"。"每次写 prompt，都该想它会被一个善意的人怎么误读"，据此软化——因为这段 prompt 是 100% 的时间都喂给模型的。→ 详细
• 这一切都建立在"依赖模型判断力"上，是 Opus/Fable 级别才有的——"一年前的模型根本没有这种判断力去决定要不要测一个改动"；也正因此，只有最前沿模型享受这 80% 削减，老模型仍用完整版 system prompt。至于 Fable/Opus 会不会因为懂"Haiku 判断力弱"就主动给它写更详细的 prompt——目前还没数据，且难题上大模型有时反而比小模型更省 token。→ 详细

• Simon 的转变：一年前他根本不信任模型写 prompt，今天他很多 prompt 都是模型写的——"听着荒谬，但真的很好用"。帮他接受这点的是 subagent（子代理）思路：本质就是一个 Claude 给另一个 Claude 写 prompt、告诉它去干什么。→ 详细
• Thariq 给出更强的例子：workflow（工作流）——Claude 不只给单个 subagent 写 prompt，而是在编排一整批 subagent，每一个都拿到非常详细的 prompt，相当于比"生成一个 subagent"再高一层；而且 workflow 工具本身的 prompt 也是 Claude 写的。他自己还在个人机器上给 Claude 接了 Gemini API 让它生成图片——"它给图像模型写 prompt 比我勤快多了"。一句话："一路往下全是 Claude 在给 Claude 写 prompt。"→ 详细

• Simon 对 Anthropic 的公开不满：你们公开了 Claude 的系统提示词网页，却不含工具 prompt 和 Claude Code prompt，他至今得跑代理去截获；他希望正式公开，因为"prompt 就是文档——想知道工具能干什么、怎么工作，看 prompt 就知道"，还爱把新旧 prompt 做 diff 来学新模型能力。Cat 记下这条需求（"我让 Claude Tag 去办"），Thariq 认领要写一篇详细文章。→ 详细

• 引入新工具的门槛很难量化：Thariq 打趣"我职业生涯的巅峰就是引入了 ask user question（Claude 用来反问你的工具）"——这类工具很难做 eval、更偏用户偏好，早年主要靠 dogfooding（他们内部戏称 "ant fooding"，蚂蚁版）。总体一直在朝"更少的工具"收敛，最近一批是 task 工具，思路是给 Claude 更通用的能力。→ 详细
• 他们删掉了 grep、glob 等专门的搜索工具，直接用原生 bash；Thariq 的名言是"这些模型更像生物学而非物理学"，工具设计尤其难，更像一门艺术。→ 详细
• Cat 补的原则：随着工具增多，把工具数量（cardinality）压到很低，并确保每个工具的功能和其他工具明确区分，Claude 才好判断何时调用哪个。file edit 之所以保留，纯粹是为了渲染——有专门工具就能确定性地知道"Claude 在改文件"，从而弹出那个"是否批准这处编辑"的漂亮 UI，新用户很吃这套；但对已在用 auto mode 的人，"其实删了 file edit 大概也完全没事"。→ 详细

• 背景：Simon 深知 prompt injection（提示注入，即别人往内容里塞指令劫持你的 agent）的风险，却大多跑在 YOLO mode（全放行、不问权限）上"深感愧疚"，直到三周前才默认转 auto mode——但"我对它了解不够，不知道它到底多安全"。→ 详细
• 内部现状：几乎每个人都用 auto mode，是"既安全又能跑长任务的最佳方式"。他们做了上千个 eval、请多家红队搭对抗环境专门诱骗 Claude Code 做坏事，"他们找出的每一个问题我们都缓解了"，接下来几周会公开 eval。→ 详细
• 不吹 100%：Cat 坦言拦不住 100%（"那样说太夸张"），但对最关心的几大类风险——prompt injection、数据外泄——"风险已远低于一个普通的人类审核者"。→ 详细
• 原理（值得建这个心智模型）：每当 Claude 执行一个回合、发起一次 bash 调用，都有一个 Sonnet 分类器结合工具调用 + 整段对话上下文 + 你的指令来判断。它尤其擅长"动态权限"——你说"把这个推到 GitHub"它就放行、你说"别推"它就拒绝；Claude 太主动想做某事时，auto mode 会"看到你说过别做这个"就拦下来提示你。它还和沙箱（sandbox）配合：沙箱边缘情况太多、难用确定性规则全覆盖，但当有东西要突破沙箱（如一个网络请求），auto mode 就看着这个请求判断"合不合理"再决定放行——凡是用户原本会看到的权限提示，它都会介入。→ 详细

• auto mode 自今年一月就在内部用、打磨很久，和 alignment（对齐）、safeguards（防护）团队合作先内部推开再对外；Simon 唯一的、也是最大的不满仍是"理解不够深"——凡是负责我安全的东西，我想知道它防住什么、防不住什么，才好决定给它多少信任。→ 详细
• Claude Tag 正是靠 auto mode 才成立（Thariq："别自己造 AI Slack 机器人，攻击面太多——你有个反馈频道，用户往里发东西，你的机器人在读它"）。更多安全设施：给 Claude 单独配一套凭证、当独立身份，便于审计；以及凭证注入（credential injection）——让 Datadog 凭证"可被 agent 使用、但不可被 agent 读取"，agent 发请求时在链路上实时插入真凭证。Simon 盛赞这个"token 代理"模式"对得不能再对了"。→ 详细

• Simon 抛出沉重一问：很多人正因"曾以为属于自己的软件构建角色被模型接管"而失落；过去一年半怎么改变了你们对自己手艺和价值的看法？→ 详细
• Thariq 的解法："Cat、Ken、Boris 总提醒我们要更有野心——增长这么快，必须站最前沿、做能做的最好的工作。"他一慢下来就问"能更快吗？能更有野心吗"，而答案往往是 Claude（它一直在变强，"上次我试这个还是上一代模型"）。他承认失落感真实存在——"如果你只想做和 LLM 出现前一样的活、现在它变成一句 prompt，确实挺难过"，化解方式就是变得更有野心。→ 详细
• 榜样 Jared：在奥克兰公寓花约一年手写了全部 Zig 代码、几乎不出门却乐在其中；现在又把整个 Bun 用 Rust 重写、同样开心，而且野心大得多——"这就是他化解失落感的方式；成功本身是有乐趣的"。→ 详细

• Cat："产品这个角色几乎每个月都在变"，核心是不断识别"现在的缺口在哪里"；团队里所有 PM 都是工程师+设计师+PM 的混合体，多数工程师过去是全职工程师出身，所以哪里有缺口就补哪里。→ 详细
• 具体形态：有个想法却没激发工程师去做 → 自己做出来放进 notebook、以此激励别人推向生产；设计看着不对 → 找一个相似页面做初稿、再拉一个细节控来补齐；产品在公司内采用变大、更多人要知道路线图 → 把发布日历、异步状态收集自动化（不打扰人），定好三个内部公告频道确保更新详尽又切中要点。一句话概括工作："搞清好想法到交付客户之间此刻的缺口，然后尽可能自动化。"→ 详细

• Thariq 最惊艳的例子：ACM Agentic 大会主办方剪视频太慢，他要来原始素材（台上讲话视频 + 拍幻灯片视频 + 音频，对方甩一句"祝你好运"）丢给 Claude（Fable）。它转录全片、注意到"拍幻灯片的视频中途弹出过一个自动更新弹窗"，就主动改用 HTML 幻灯片源、按当前讲到哪页切片；还发现他只占舞台一小块，就动态裁切、追踪他来回踱步的位置，最后合成"他的特写 + 幻灯片 + 实时字幕"。一发入魂（one-shot），再让它加动画它就上 ffmpeg、Remotion——"我整个人都被震住了"。→ 详细

• Cat 的失望点：设计和 UX 品味还不够好——"现在只要我写一个带详细 spec 的 prompt，它通常都能照做，但 padding 可能不对、界面就是还不够 delightful（让人愉悦）"；它偏依赖现有 app 的设计最佳实践，而"对前沿 AI 产品来说，还有太多全新的交互体验等着我们去设计"。→ 详细
• "Opus 审美"：Simon 说你一眼就能看出"这是 Opus 设计的"，期待能超越；Thariq 期待未来模型成为"交互设计上的思考伙伴"。→ 详细
• 更大的边界：Thariq 想看到 Claude 更多地和真实世界互动——"它能不能做科学？能不能编排、调度实验？"那不只是写代码，还需要"对更广阔世界的另一种品味"（顺带：Claude Science 是兄弟团队几天前刚发的新产品，不属于 Claude Code）。→ 详细

收尾问 1 · 值得别家"偷师"的文化黑客？

• Thariq：Claude Tag 在"你们大部分频道都公开"时最好用——它能搜索所有公开频道拿到尽可能多的上下文、给出最准的答案，而这只有在它能访问一切的前提下才成立。→ 详细
• Cat（她说这条"对我太重要了"）：联合创始人的口头禅是"不要跟自己谈判（we don't negotiate against ourselves）"——你完全可以在脑子里想象出各种取舍、然后说服自己放弃做有野心的事；或者，你直接去干。他们常问"那我们就做了会怎样？这到底是不是一个真实的取舍？如果是，证据在哪里，还是它只是'听起来合理'？"——让取舍自己显形，尽你所能地保持野心。→ 详细
• Simon 的反应：这和他 25 年软件经验养成的直觉完全相反——"我的直觉是默认答案该是'不'、凡事皆有取舍、皆有成本"，而现在不得不重新审视所有这些直觉。→ 详细

收尾问 2 · "纯属因为能做所以就做了"的最荒诞项目？

• Thariq：一个 2D《街霸》式格斗游戏，角色是他自己和朋友们。用 Claude Code 去给 Gemini（他说 Seedance 那个模型也挺不错）写 prompt 生成视频动画，效果特别好——它还能逐帧验证动画做得好不好，甚至自己算出 hitbox（判定框）："你的拳头在这个位置，我来把 hitbox 的 JSON 画出来。"→ 详细
• Cat（"我的简单多了"）：她是重度攀岩爱好者，用 Claude Code 搭了个小 app 记录攀岩线路项目；还用 workflow（"我们把它当编程工具宣传，但做旅行深度调研也一流"）调研攀岩目的地——查各人所在城市的直飞航班、去 Mountain Project 找匹配难度的线路、找 Airbnb，还按她"讨厌徒步、要短接近段"的偏好筛出"从停车点到岩壁步行距离最短"的。Simon 笑称这是"vibe coding 一个攀岩版 Jira"。→ 详细

观众问答

• Q（eval / 可观测性工具）：会不会做更多帮我们建 eval 数据集、监控 agent 与 workflow 表现的工具？Cat：考虑过，但真正的瓶颈不是工具，而是"客户要建一份真正高质量的 eval 需要很长时间"这项技能本身；他们期待内部投入 + 对外分享最佳实践。→ 详细
• Q（观众 Sai，问 memory 与多人协作）：现在 memory 怎么设计、是不是基于文件？要不要改用 data store 来更好扩展？Thariq：目前 Claude Tag 的 memory 按频道划分、实现就是"每个频道一个 Markdown 文件"，同频道所有 Claude 共享、每个实例有自己的 session 但 session 能回写主 memory；他们做了大量 memory 研究、"什么才是对的 memory 方式其实挺反直觉"，仍在跑实验、暂无定论。→ 详细

本片是大会现场炉边对谈，未给出社交账号或邮箱。三位分别是：

• Simon Willison — Datasette 作者、AI 工程圈信号极高的独立评论者，长期在个人博客逆向记录 Claude Code 的 prompt（对谈中提到他至今靠跑代理截获、并用新旧 prompt 的 diff 学模型能力）。
• Cat Wu — Anthropic，Claude Code 产品负责人（PM）。
• Thariq Shihipar — Anthropic，Claude Code 工程师，ask user question 工具的作者；他在对谈中认领"要写一篇详细讲 system prompt 砍 80% 的文章"，可留意 Anthropic 工程博客。