一支造工具的团队，为什么把七成工作搬进了 Slack？
这场访谈的受访者是 Claude Code 团队三位工程师：Thariq Shihipar、Sid Bidasaria 和 Robert Boyce，由 Claude 官方频道在 2026 年 9 月播出。下面的比例、周期和功能存废都出自他们本人的讲述。
入口变了，任务层级也一起抬高。团队成员 Sid Bidasaria 称自己 70%–80% 的工作发生在 Slack 里的 Claude Tag上，剩下约 20% 才打开终端界面或桌面应用做微调。
按团队自述，工作方式从逐行监督、逐个批准权限提示和关注每次工具调用，转向给出目标让模型自主实现。住进 Slack 也是设计的一部分：agent 可以查到产品决策、团队对产品形态达成过哪些共识等额外上下文，因此决策质量会好很多。这个因果是团队自述，没有对照实验或指标。
Sid 把变化总结为视角的拉远：过去很在意对话记录、每一次工具调用和模型做出的每一个决定；现在则是「我有一个目标，我想实现这个目标，然后把这个目标交给模型去实现」。
类比Claude Tag 住在 Slack 里像团队群里多了一位同事：他看得到群里所有讨论和决定，自己去把活干了，干完回来汇报。
入口迁移只是表象，真正的推力是底层模型的变化速度。
为什么他们说对产品的理解每两个月就要重写一次？
因为在他们看来，产品底层技术的保质期已经被压到了月级别。Thariq Shihipar 的说法是：过去技术保质期以年为单位，做一个产品可以有很高信心它在未来几年都有意义；但在 AI 模型领域，技术每两个月就在脚下发生一次根本性转变，而这个周期可能还在被压缩。
「每两个月」是他的主观观察，不是测量出来的指标，「根本性跃迁」也没有明确定义。他拿来对照的「传统软件保质期 2–5 年」同样只是量级说法，不是统计数据。
类比技术保质期压缩到两个月像你在造船，但海水的温度和盐度每两个月彻底变一次，今天设计的船体明天可能就不适配。
模型变化速度如果真按两个月计，写在它上面的功能就会很快过期。
他们为什么删掉自己写的 to-do list？
因为在他们眼里，这类功能是对当前模型缺陷打的补丁。模型一变强，补丁就可能从资产变成负担。
Thariq 解释得很直白：他们构建进 harness里的很多东西，本质上只是为了覆盖当前模型状态下的失败模式；模型变好之后，团队就有了自由说「所有这些我们构建的功能都不再相关了，可以把它们去掉」。
to-do list 是最完整的例子。Sonnet 3.5时代模型做不了长程工作，访谈里的说法是「给它五件事，它可能做三件就放弃」。团队于是给它一个待办清单，效果非常好；Thariq 说那是他第一次有骑在浪尖上的感觉。而约一年后，这个功能从 Claude Code 中消失了，因为模型有了更复杂的记忆状态可以依赖。
AskUserQuestion 工具走的是同一条曲线：Robert 花了很长时间设计，让 Claude 好好调用它非常困难；后来 Claude 越来越擅长调用，而他最近自己反而很少用了——他改成创建一个 HTML artifact，artifact 会用图表和原型的形式向他提问。
这种删除不是浪费：现在他们做的任务更大、更有挑战性，需要的工具形态本来就变得不一样了。
类比harness 功能是对模型缺陷的补丁像给长身体的孩子做衣服：今天在膝盖处缝的补丁，半年后孩子长高了，补丁反而磨得慌，得拆掉——不能因为是自己亲手缝的就舍不得。
to-do list 的完整生命周期：从必需品到历史遗迹
Sonnet 3.5 时代，团队发现模型无法可靠完成多步骤长程任务：给它五件事，它可能做三件就放弃。
- 发现问题
团队观察到模型在长程任务中会中途放弃，给 5 件事只做 3 件。
you would give it like five things to do, and it would do three things and just give up
- 设计补丁
团队尝试给模型提供 to-do list 功能，帮助它追踪并完成所有任务。
maybe you give it a to do list and it'll do really well
- 效果显著
to-do list 效果非常好，团队称第一次感受到「骑在浪尖上」，认为这正是当时需要的东西。
it did really well. It was just like, whoa, this is exactly the thing we need for this moment in time
- 功能消失
约一年后，模型有了更复杂的记忆状态可以依赖，to-do list 不再被需要，功能消失。
a year from then, like, it's disappeared, like you don't really need the to do list anymore
结果：to-do list 从不可或缺的核心功能变成不再需要，整个生命周期不到一年，成为团队「必须对自己构建的东西非常不执着」的核心论据。
这是团队内部的产品决策，不能证明所有 AI 编程工具的 to-do list 类功能都会以同样速度消失；团队也没有说这个功能上线和移除的具体版本或日期。
AskUserQuestion：从设计困难到我自己不用了
Robert Boyce 想让 Claude 具备交互能力，即向用户提问。
- 最初定位
他一开始把这个功能放在规划阶段之后。
- 改为模型可调用的工具
后来他改变思路：如果它只是一个模型可以调用的工具呢。
- 设计困难
设计这个工具花了很长时间，让 Claude 很好地调用它非常困难。
- 模型变得更擅长
工具设计完成后，Claude 越来越擅长调用它。
- 使用者弃用
最近 Robert 自己甚至不怎么用这个工具，而是创建 artifact，用 HTML 形式向他提问，里面还有图表和原型。
结果：该工具经历「几乎做不到 → 能做到 → 我自己不用了」的快速更替，被 Robert 用作 Claude Code 内部工具频繁更换的例子。
这是团队内部工具史的口述，官方文档里没有 AskUserQuestion 的记载，时间点无法外部核对，也不能用来推断其他工具的更新节奏。
旧补丁被删掉之后，团队需要一套新的信任机制。
扇出、三角度对抗审查、再聚合：信任是怎么被造出来的？
起点是一次 code review。Thariq 说，代码审查是他们做大规模扇出（fan out）的地方——问题不再是重读一段代码，而是「你怎么找到每一个 bug」。
做法是：先大规模扇出搜索潜在问题，把结果聚合（coalesce）起来；对每一个 bug，可能再做一次对抗性审查，让 Claude 从三个不同角度判断它是否真的存在。效果是把误报过滤掉，只把最需要人类关注的那批结果交上来。
Thariq 把这个模式总结为一个 MapReduce问题，团队称其为 test-time compute：用更多推理时间和计算量，换更高的答案置信度。同一套模式也能用在性能问题甚至旅行规划上——Sid 举例说，可以让 Claude 发十个不同的搜索请求去找 Tahoe 的住宿、Airbnb 和景点，再由若干 agent 排序、验证，最后给一个结果。
另一点让 Sid 特别有信任感：agent 是通过写确定性代码来编排子 agent 的。比如一个 for 循环遍历所有条目，「这个 for 循环不会跳过任何一条」；确定性的代码行为与 agentic 的模型行为混在一起，他知道 Claude 确实在做他想让它做的事。
「三个角度」是他的说法。官方 ultrareview 文档只承诺每个上报的发现都会被独立复现与验证，没有写角度数量，也没有给出效果数字。
类比fan-out 加聚合像派十个探员分头找线索，每条线索再派三个人从不同角度验证真伪，最后只把十条关键线索交给警长——警长不需要看一万条原始线索。
扇出—对抗审查—聚合：code review 演化出的工作流
- 1大规模并行找候选
派出多个子 agent 并行搜索，目标是「怎么找到每一个 bug」，而不是重读某一段代码。
- 2从三个角度验证真伪
对每一个 bug 做一次对抗性审查，从三个不同角度判断它是否真实存在，过滤误报。
- 3排序并压缩成可消费的摘要
把验证过的结果按重要性聚合，类似 MapReduce 的 Reduce 阶段，避免人直接读扇出输出。
- 4在更高的抽象层级上判断
人不再逐行挑毛病，而是看更大图景：为什么这样设计、边界为何这样划分。
这些扇出、验证、聚合的能力，最终被团队描述为沉淀进一个产品形态。
看不见模型的内部独白，为什么反而更敢放手？
落到产品上，最明显的变化是界面：Claude Tag 是运行在 Slack 中的原生 agent，Robert 说它第一次让用户界面与对话记录（transcript）更完全地解耦。你在 Slack 里看到的每条消息，都是它通过调用某个工具发出来的，内部独白基本不可见，虽然有链接可以查看完整对话记录。
他形容这种抽象一开始有点吓人——「我不能在 Claude 思考的时候看到它在想什么了」，但也非常自由，甚至成了一种强制功能，逼着你让 Claude 自己去做饭（let Claude cook）。
最能说明这种放手程度的是：团队正在用 Claude Tag 来构建 Claude Tag 本身。Robert 重点工作之一，就是确保开发循环对 Claude 足够好用，让它能做人类开发者需要做的一切事并端到端测试。
Sid 则走完了一个完整闭环。他做新工具需要多人支持，于是先问 Claude Tag 该找谁谈；接着做原型和实现，全部在 Slack 里完成，他甚至能在手机上看。因为不确定工具是否好用，他加了很多事件追踪，然后内部部署，由 Claude Tag 持续监控使用情况；有人给反馈时它会 tag 他，让他能及时回复。到了改进转化漏斗时，他没有直接下指令，而是先让 Claude 出主意、把自己的想法作为示例。他说这是真正让他「点击」的时刻，即在更高层级上和模型协作。
验证也没被省略：Claude 开 PR 时会测试并发截图给他看效果；Sid 也会让 Claude 录下终端操作，自己克隆下来做一次 sanity check，但他觉得最终他可能连克隆都不再做了。
从验证、代码审查、反馈、workflows 到 routines攒成 Claude Tag，这条因果是访谈整理稿的归纳，不是受访者的原话。官方文档能确认 Claude Tag 以组织共享身份被 @ 调用、并从线程里读上下文，却证明不了团队真的用它开发了它自己。
类比界面与对话记录解耦像你请了一位厨师：以前站在厨房门口看他切每一片菜、放每一勺盐，现在你坐在餐厅里，他只在需要你定夺时出来问一句，然后把菜端给你。
一个新内部工具，从找支持者到改进漏斗全在 Slack 里跑完
团队成员 Sid Bidasaria 想开发一个新内部工具，需要获得多人支持和 buy-in。
- 找利益相关者
他先问 Claude Tag 应该找谁谈、谁可能对这个想法感兴趣，得到利益相关者名单。
I'm thinking of this idea, who should I talk to who might be interested in it
- 做原型和实现
Claude Tag 在 Slack 里完成原型制作和代码实现，他甚至在手机上查看原型。
it makes mocks up for me. It does the implementation
- 加事件追踪并部署
因为不确定工具是否好用，他让 Claude Tag 加了很多事件追踪，然后内部部署。
I add a lot of like events to it. And then I deploy it internally
- 监控和收集反馈
Claude Tag 持续监控使用情况，有人给反馈时会 tag 他，使他能及时介入回复。
Claude tags me when someone else gives me feedback about it
- 在更高层级协作改进漏斗
想改进转化漏斗时，他没有直接下指令，而是让 Claude 出主意，把自己的想法作为示例。
let me ask Claude to improve the funnel... I want to sort of, like, work with it at that higher level
结果：一个新工具从想法、找支持者、原型、实现、埋点、部署、监控到迭代的完整闭环全部在 Slack 的 Claude Tag 中完成；人类负责设定方向、在关键节点介入、在更高层级协作。他称这是真正「点击」了的时刻。
这是单个团队成员的个人工作流案例，工具是内部工具，不能证明所有类型的软件开发都能以同样方式完成；涉及外部依赖、安全审查或复杂硬件交互的场景可能需要更多人工介入。
以上说法大多来自团队自述，下面把可佐证与不可佐证分开。
这些说法里，有多少能被官方文档佐证？
能佐证的只有产品形态，佐证不了团队的工作方式。官方 Claude Tag 文档确认它以组织共享身份出现在团队频道里，任何人都可以把 @Claude 拉进线程并指派任务；Slack 文档确认可以「View Session」打开完整会话、并会从线程与近期频道消息中收集上下文。这支持了「界面与完整记录并存」的描述，不过官方那套描述对应的是更早的 Claude Code in Slack，两套说法是否完全一致，官方文档没有明说。
差距最大的地方有三处。第一，routines 在官方文档里明确标注为 research preview，「行为、限制与 API 可能变化」，而这场访谈的叙述没有提这个状态。第二，ultrareview 是研究预览阶段的付费功能，分支审查默认上限 500 个改动文件、8000 行改动，单次通常 5–10 分钟，Pro 和 Max 账户有一次性 3 次免费额度、之后通常按用量计费约 5–25 美元；这些成本和限制，访谈里一句都没提。第三，70%–80% 的工作比例、每两个月一次能力跃迁、to-do list 的上线与消失、团队用 Claude Tag 构建自身，官方文档里没有任何对应内容，目前只能说「团队这样讲」。
访谈所说的 workflows 与官方文档中的 Dynamic workflows（由 Claude 写脚本运行多个 subagent 并返回单一结果）名称相近，但是否为同一个功能，两份材料没有明确对应。这些说法目前只有团队自述一个来源，没有第三方独立验证，也就没有可交叉核对的效率或性能结论。
访谈说法在官方文档中的佐证程度
| 对象 | 官方文档佐证 | 访谈新增信息 | 不能推出 |
|---|---|---|---|
| Claude Tag 调用形态 | 有 | 组织共享身份、可被 @ 派活 | 不能证明团队用它构建自身 |
| Slack 会话与完整记录 | 有 | 界面与对话记录解耦 | 官方描述对应 Claude Code in Slack，是否等同未明示 |
| routines 云端定期执行 | 有（研究预览） | 突破单次会话边界的自动化 | 官方标注研究预览：行为与 API 可能变化，访谈叙述里没有提到这一状态 |
| 审查时验证每个发现 | 有（付费预览） | 三角度对抗审查 | 官方未确认角度数，也未给出效果指标 |
「有」表示官方文档明确描述该形态；「研究预览/付费预览」表示官方标注状态可能变化。
矩阵比对的是访谈说法和官方文档的覆盖程度，不评价产品质量；比例类数字在官方文档里没有对应内容，产品能力也不等于团队内部的实际用法。
边界划清后，回到团队自述里最可迁移的一条：人的注意力该转向哪里。
当模型越写越多，人该把精力放在哪？
放在设定目标、建立验证标准，以及判断什么值得做上——这是这场访谈里最可迁移的一条。Thariq 说他过去从性能工程里获得很多乐趣，那意味着真正钻进去把系统性能提上去，而「Claude 现在在这方面比他强得多」；他的注意力因此转向更快地把想法变成原型和产品。
Sid 自认是个注重细节的人。他曾给自己的个人网站做过一次极其细致的 CSS 复刻，还原 Mac OS 10.4 的 aqua 按钮，可能花一整天精确调整径向渐变的每一层——这种事他现在不会再手动做了。但这让他想起七八岁时想做一个电子游戏又不会写代码，只能用 PowerPoint 摆可点击元素和形状；如今他不用再说「我没有技术技能，我解决不了这个问题」，而是可以说「这是我想实现的，让我们一起拆解」。
Thariq 给出更宏观的视角：软件工程本来就是变化的职业，一二十年前人们手写 JavaScript、还没有框架。Sid 的补充把话题拉回问题本身——「你在解决不同的问题，但你仍然在解决问题」。
这套判断建立在团队的自我描述之上。如果模型能力进展放缓，或者你的工作强依赖外部依赖、安全审查、复杂硬件交互，「放手」的程度就要相应收回。对任何具体工具功能，都值得留着一种它可能很快被替代的心态；但这不是让你把所有工具都当成一次性用品。
类比从深入细节到设定目标像从亲手雕刻每个零件的工匠，变成设计整座建筑的建筑师：手艺没有浪费，只是被提到了更高层级。
什么条件下该放手到什么程度
- 条件任务边界清晰、可在本地或内部环境端到端验证结果团队报告可以把实现、埋点、监控整条链路交给 agent，人只看结果与关键节点可以怎么做先从这类任务开始放手，用截图、测试和事件数据当验收证据
- 条件涉及外部依赖、安全审查或复杂硬件交互结果涉及外部依赖、安全审查和硬件交互时，通常需要更多人工介入可以怎么做保留人工复核节点，不要让 agent 独立完成外部动作
- 条件你依赖的某个功能只是为补当前模型缺陷而存在结果模型变强后它可能从资产变成复杂度负担，团队的做法是主动删掉可以怎么做不要在它上面搭深度工作流，提前准备替代路径
- 条件模型能力进展放缓，或平台仍标注研究预览/付费预览结果“每两个月”和“能力沉淀为产品形态”的判断会失去前提，官方限制（配额、时长、计费）会直接生效可以怎么做把这类能力当试验性投入，不要写进依赖稳定性的生产计划
条件来自访谈与官方文档，比例与周期数字均为团队自述；这几条行动建议是在此基础上的延伸，不是来源里写好的规则。
