好久没发推了，今天读到Claude Code团队的一个播客，极其有共鸣，也深受启发，忍不住要上来冒个泡和大家分享！可以说，这是近期我读到的最好且没有之一的产品思考！！！

这期播客提出了一个非常重要的观点：「工具的终极形态是消失」。

团队没有具体讲功能设计，而是讨论了几个非常本质的问题：

• 当模型每3个月就吞噬掉你的脚手架，什么该被保留？什么该被删除？
  
• 工具的终极形态是什么？
  
• 当人和AI共享同一个界面、同一套工具，人的角色是什么？
  
  今天我们又走到了一个新的分叉口，从单纯的chatbot走向multi-agent的orchestration，对自己而言，这就像是一个没有尽头的打怪升级，是一个复杂系统的无限游戏，太享受了！
  
  以下是这期播客转写的文章，enjoy👇👇
  
  【工具的终极形态是消失】
  
  一个被"误用"出来的范式
  
  Boris 手写了入职后的第一个 PR。代码审查被拒："你居然手写代码？用 Claude。"
  
  那时候 Claude 还叫 Clyde，启动要一分钟，索引跑很久。Boris 输入任务描述，等了五分钟，它一次搞定——虽然还要手动修几处错误，但某个念头冒出来了：也许根本不需要 IDE。
  
  几个月后，Boris 在终端搭了个小聊天应用。随手给模型加了几个工具。然后魔法发生了：模型疯狂使用工具，自己写 bash，写 AppleScript，像天生就会。
  
  Claude Code 就这么出来了。不是规划的产物，是"意外"演化的。它干掉了文本编辑器，让 AI 直接面对终端。
  
  这个激进决定背后藏着更深的洞察：最好的工具，就是没有工具。
  
  Bash 的胜利
  
  任何人构建 AI agent，第一反应都是创建一堆工具：find_file、open_file、search_code……
  
  Claude Code 只给模型一样东西：bash。而且出奇好用。
  
  团队每周都在删工具。上周删了 OS 工具，因为在 bash 层面搞定了权限控制。两周前又删一个，因为新模型不需要了。现在保留的少数工具存在只有两个理由：更好的 UX，或者权限管理。
  
  原则很简单：减少模型的选择，就是增加模型的能力。
  
  Bash 是通用接口。工程师能做的，Claude 都能做。没有中间层。人类和 AI 看同样的输出，说同样的语言，共享同一个现实。
  
  这催生了意外的用法。比如"bash 模式"——感叹号开头直接执行命令，Claude 能看到完整输出。这不是预先设计的，是某天 Boris 觉得在两个终端切换太烦，随口让 Claude 想办法，它就想出来了。Pink 的感叹号，简洁好用，现在成了标配。
  
  Boris 最近从系统提示里删了 2000 个 tokens，因为 Sonnet 4.5 不再需要。Opus 4.1 需要的东西，Sonnet 4.5 已经内化了。
  
  这叫"模型吞噬脚手架"——曾经的外部辅助，逐渐被模型吸收。
  
  删除不是妥协，是进化。
  
  双重用户：当人和 AI 共享界面
  
  传统软件的用户是人类。Claude Code 有两个用户：工程师和模型。
  
  Cat 说得精准："过去工具为工程师设计，现在平等地为工程师和模型设计。"
  
  为人类设计的，模型也能用。/commit 命令，你手动调，Claude 自动调，逻辑共享，没冗余。
  
  再看 /feature-dev：引导 Claude 逐步构建功能——先问清需求，制定计划，创建 to-do list，然后一步步实现。它既是给 Claude 的工作流脚本，也是工程师可以手动触发的向导。
  
  不要为"人机交互"和"机器行为"建两套系统。
  
  这延伸到每个细节。比如"thinking"功能——最初想做按钮切换思考模式，后来发现只要告诉 Claude "think"或"don't think"，它就懂。为了防止误触，加了视觉高亮。输入"ultra think"时，thinking 过程显示为彩虹色——Sonnet 4.5 已经不需要这个，但团队保留了，纯粹因为"情怀"。
  
  双重用户设计最深的含义在于：它模糊了"使用工具"和"成为工具一部分"的边界。
  
  当工程师在终端跟 Claude 协作，他们不是在"指挥"AI 助手，而是在跟一个共享工作环境的同事配对编程。Claude 看到的就是你看到的，它能用的就是你能用的。
  
  这种对称性，是 Claude Code 感觉"自然"的根本原因。
  
  潜在需求法则：从滥用到产品
  
  Cat 说过一个老产品理念：latent demand（潜在需求）。把产品做得开放、可破解，让用户"滥用"它，然后观察这些滥用模式，产品化它们。
  
  Claude Code 就是这么进化的。最初是编程工具，后来数据科学家在用、市场团队在用、有人拿它管理邮件、做市场研究、整理 Obsidian 笔记。"非编程"用例多到无法忽视，于是重新定位：通用 agent SDK。
  
  Cat 自己就是滥用大户。她搭了个报销系统：下载信用卡记录，启动两个 sub-agent——一个代表她，一个代表公司——让它们"对战"决定哪些能报。这个"对抗处理器"模式后来启发了 sub-agent 架构的思考。
  
  看内部用例。有工程师搭日记系统：每完成任务，让 Claude 写日记记录"做了什么、试了什么、为什么失败"，甚至让 AI 定期综合这些日记，提炼"观察"。这是记忆系统的雏形。
  
  另一个是前端测试。Cat 搭了个 sub-agent，用 Playwright 抓客户端错误，自动化测试应用。虽然还不完美，但"有生命迹象"，可能会进插件市场。
  
  最激进的滥用在哪？内部。越来越多员工每月花超过 1000 美元 credits，用 Claude Code 跑大规模代码迁移：主 agent 生成巨大 to-do list，然后启动 10 个 sub-agent，并行处理框架迁移、lint 规则更新、测试框架切换。
  
  这种"swarm"模式还在探索，但它揭示了未来：AI 不再是单线程助手，而是可以大规模并行的认知劳动力。
  
  潜在需求法则要求建设者保持谦逊：你不可能预知用户真正需要什么。所以要做的是铺设基础设施（bash、sub-agents、slash commands、hooks），然后退后，观察用户如何破解系统。
  
  删除的勇气
  
  Boris 说他最喜欢看到的 diff 是红色的——代码删除。
  
  这不是玩笑，是产品哲学。
  
  在 AI 时代，构建速度太快了。Claude Code 团队可以在一天内做 20 个原型，每个功能几小时就能上线。这带来新问题：产品容易变成"功能垃圾场"，到处是按钮、标签、小功能，缺乏组织原则。
  
  传统公司的解决方案是"移动到次级位置"——Facebook 式做法，把没人用的功能藏到溢出菜单里，永远不真正删除。Boris 在 Instagram 学到了不同的原则：如果一个功能的 weekly active users 不到 50%，直接删掉，然后想办法做一个能被更多人用的东西。
  
  Claude Code 继承了这种激进主义。团队每周都在评估：哪些工具可以删？哪些系统提示可以压缩？哪些功能已经被新模型内化，可以 unship 了？
  
  但删除有社会成本。没人想告诉同事"你做的东西我们要删了"。所以团队的原则是：如果要 unship 某个功能，必须同时 ship 一个更好的替代品，满足相同的意图。
  
  更微妙的挑战在于：删除的时机。计划模式（plan mode）可能会被删掉，因为未来的模型会自己判断什么时候需要先规划。Thinking 模式的切换词（"ultra think"）已经大部分被 unship，因为新模型理解得更自然。但现在删还是再等等？边界一直在移动。
  
  这种持续删减塑造了独特的产品节奏：不是"越来越丰富"，而是"越来越纯粹"。每一代模型发布，Claude Code 都会变得更简单，因为复杂性转移到了模型内部。
  
  团队甚至讨论过：也许有一天，Claude Code 本身都会被删掉——当模型强大到不需要任何外部工具，能够完全自主地理解意图、规划任务、执行验证，那时候还需要 harness 吗？
  
  答案可能是：工具的终极形态，就是消失。
  
  当模型吞噬脚手架
  
  Sonnet 4.5 比 Opus 4.1 更强，这不仅意味着它能解决更难的问题，还意味着它不再需要某些外部辅助。
  
  以前需要"计划模式"的任务，现在可以 one-shot。以前需要明确指令的地方，现在模型自己会主动做正确的事——比如卡住的时候去翻 git history，或者自发地使用 bash 查找信息。
  
  每一代模型都在把外部的工程化实践内化为自己的能力。这对产品设计提出了一个哲学问题：该建什么？
  
  一种策略是"等待"——既然下一代模型会做得更好，那就不要在当前模型上花时间搭脚手架。但 Claude Code 团队选择了相反的路径：构建所有能改善用户体验的东西，即使知道三个月后可能要删掉。
  
  Cat 的解释很直接："我们希望它会在三个月后被删掉。"
  
  团队的目标不是构建持久的基础设施，而是提供"此刻最好的体验"。如果某个功能让 Sonnet 4.5 工作得更好，那就做，即使 Sonnet 5.0 可能不需要它。
  
  这种态度背后是对 AI 演化速度的深刻认识。Boris 提到，他们测试新模型时，在普通的 Claude 聊天界面里很难判断模型是否变好了，但在 Claude Code 里立刻就能感受到差异。
  
  原因在于：harness 放大了模型能力的边界效应。一个复杂的 agentic 工作流，会把模型推到极限，此时微小的能力提升会带来质变。
  
  这种紧密耦合带来了另一个优势：研究员也在用 Claude Code。当他们看到什么工作、什么不工作，可以直接改进模型。产品和模型在一个快速迭代的闭环里共同演化。
  
  但这也意味着持续的不确定性。Boris 坦承："我们真的不知道接下来会怎样，我们只是在跟所有人一起摸索。"
  
  终端可能不是最终形态，CLI 可能会被别的东西取代。随着模型自主工作的时长从小时延伸到天（最新模型已经可以自主运行 30 小时），人类的角色也在改变——从"操作者"变成"监督者"，从"指令发出者"变成"目标设定者"。
  
  当 AI 可以并行运行、互相监督、持续工作数天，界面会是什么样？会不会是某种"Claude 监控 Claude"的仪表盘？还是说，界面本身会消失，留下纯粹的意图层？
  
  没人知道。但可以确定的是：下一代工具不会通过"加功能"诞生，而是通过持续删减、持续简化，直到只剩下本质。
  
  复合工程：让每个功能都让下一个功能更容易
  
  Boris 和 Cat 在采访前聊到了一个现象：Every 团队在用 Claude Code，而且他们发明了一个词——"复合工程"（compounding engineering）。
  
  传统工程是这样的：每添加一个功能，代码库就复杂一点，下一个功能就更难做。
  
  复合工程反过来：每添加一个功能，要让下一个功能更容易做。
  
  怎么做到的？把每次实现功能的过程——计划怎么制定的、哪些部分需要修改、测试时发现了什么问题、哪些地方容易遗漏——全部记录下来，编码回所有的 prompts、sub-agents、slash commands。
  
  这样下次别人做类似功能时，系统会自动提醒："注意，上次这里有个坑。"
  
  结果是：新人可以在完全不熟悉代码库的情况下，第一天就开始提交有质量的 PR。不是因为他们懂代码，而是因为代码库自己"记得"所有的经验。
  
  这是一种新的知识管理方式。以前，知识在人脑里，或者在文档里。现在，知识在工具链里，在 Claude 的上下文里。
  
  Boris 听到这个很兴奋，因为他们在 Anthropic 内部也看到类似现象。经理 Fiona 十年没写代码了，加入团队第一天就开始提交 PR。不是因为她重新学会了编程，而是因为 Claude Code 里积累了所有团队的实践经验。
  
  当有人在 PR 里犯错，团队会说："@claude，把这个加到 claude. md 里，下次就不会再犯了。"或者："@claude，给这个写个测试，确保不会回归。"
  
  Claude Code 内部几乎 100% 的测试都是 Claude 写的。坏的测试不会被提交，好的测试留下来。Lint 规则也是 100% Claude 写的，每次有新规则需要，直接在 PR 里说一句："@claude，写个 lint 规则。"
  
  这解决了一个古老的问题：如何让团队的隐性知识显性化？
  
  答案不是写文档，因为没人看。答案是把知识编码进工具，让工具在正确的时刻主动提醒你。
  
  终端不是终点
  
  团队内部有个共识：CLI 不是最终形态。但他们也不知道最终形态是什么。
  
  目前 Claude Code 已经有多个界面：CLI、IDE 扩展（传统界面）、新的 GUI 扩展（更亲民）、GitHub 上的 @claude 集成（在 PR 里直接调用）、Web 版、移动版。
  
  Boris 在红灯前用手机刷 GitHub issue，随手 @claude 让它修 bug。这种无处不在的可访问性，是在试探不同场景下的最优形态。
  
  但更深层的问题是：当模型可以自主工作几天甚至几周，人类怎么介入？
  
  现在的范式是"人在循环中"——Claude 做一步，你检查，批准，它继续。这在几分钟到几小时的任务里运作良好，但如果任务跨度是几天呢？
  
  Boris 提到一个痛点：他在笔记本上跑 DSPY 提示优化，整个过程要跑很久，所以他不得不一直开着电脑，走到哪带到哪，因为"不想关机打断它"。客户也一样，有人开会时抱着笔记本，因为 Claude Code 正在运行。
  
  这暴露了一个架构问题：计算不应该在本地。但云端容器又失去了本地开发的诸多优势——访问你的 git 历史、你的配置文件、你积累的 slash commands 和 sub-agents。
  
  更激进的变化可能在交互模式。当 AI 开始"proactive"（主动），它不再等你提问，而是会说："嘿，我觉得你可能想试试这个功能，我写了第一版代码，基于这些假设，对吗？"或者："根据团队目标和你的 git commit 历史，我觉得接下来应该优先做 X。"
  
  这时候，"终端"作为一个输入输出设备，可能就不够了。你需要的是某种认知管理界面，能让你快速浏览 AI 的建议、批准或调整方向、监控多个并行任务。
  
  团队正在实验，但保持着谦逊。Cat 说："我们对产品的未来保持谦逊，因为我们真的不知道。我们只是在尝试跟上变化。"
  
  唯一确定的是：下一个界面不会是"终端加更多功能"，而是某种更根本的转变。也许是从"工具"到"同事"，从"界面"到"合作关系"，从"你指挥 AI"到"你和 AI 共同决策"。
  
  但无论形态如何演变，有一条原则可能会延续：最好的界面，是让人和 AI 看到同样的东西，使用同样的工具，共享同样的现实。
  
  不需要翻译，不需要抽象层，不需要"人机交互"这个概念——因为从根本上说，你们在做同一件事。
  
  这就是"双重用户"思维的终极延伸：当界面完美时，你分不清自己是在用工具，还是在跟同事协作。
  
  从文档到演示的文化转变
  
  Cat 提到一个有趣的现象：Anthropic 内部的货币不再是文档，而是演示。
  
  你想让人兴奋？不要写 10 页 PRD，给他们看 15 秒演示。
  
  这背后是构建速度的根本变化。以前，你有个想法，要说服别人这个想法值得做，然后才能开始做。现在，你直接做出来，让别人看。
  
  不用花时间说服，花时间迭代。
  
  Boris 提到，计划模式（plan mode）他们做了三次。每次都推翻重来。To-dos 功能，Sid 做了三四个原型，然后 Boris 又做了 20 个版本，在一天内。
  
  这种速度带来的副作用是：原型思维取代了文档思维。
  
  以前你会仔细写文档，因为写文档成本低，写完再决定要不要做。现在直接做原型成本更低，而且原型能传递文档传递不了的东西——"感觉"。
  
  Cat 说得很清楚："文档再好，也传递不了 vibe。但你做出来，别人一看就懂这是什么感觉。"
  
  这也解释了为什么 Claude Code 团队可以保持极小的规模（核心团队不到 10 人），但产出速度惊人。他们不需要开会对齐，不需要写文档同步，不需要漫长的审批流程。有想法，做出来，内部 ant-fooding（dogfooding 的 Anthropic 版本），收集反馈，迭代。
  
  循环周期从"月"压缩到"天"，甚至"小时"。
  
  这种文化转变不仅仅发生在产品开发，也在创作领域蔓延。以前拍电影要先写剧本，拍出来才知道效果。现在可以用 Sora 生成视频，低成本快速迭代，直到找到你想要的感觉。
  
  从"说服"到"展示"，从"文档"到"演示"，从"规划"到"原型"。
  
  这是 AI 时代的新工作方式。
  
  产品极简主义：删到只剩本质
  
  Boris 提到一个他们团队的设计原则：新用户不应该需要"用户教育"。
  
  所有东西都应该直观到，你第一次用就知道怎么用。
  
  这个原则听起来简单，但执行起来极其困难。因为每个功能都有学习成本，而 AI 工具的功能特别容易堆积。
  
  你可以加一个按钮让用户切换思考模式，但更好的方法是让用户直接说"think"。你可以加一个菜单列出所有 slash commands，但更好的方法是输入"?"就能看到提示。你可以做一个复杂的权限管理界面，但更好的方法是让权限在 settings.json 里配置，团队共享。
  
  每次想加功能时，Boris 会问自己："如果我是个普通工程师，没有疯狂的 Vim 配置，没有定制的 tmux，我会用这个功能吗？"
  
  如果答案是"可能不会"，那就不加。
  
  这种自我限制创造了一种奇特的产品美学：Claude Code 的核心功能极少，但每个功能都被打磨到极致，而且都是"双重用户"的——人类和 AI 都能用。
  
  更激进的是，团队不仅删功能，还删"元语言"。
  
  什么是元语言？就是那些"关于工具的语言"，比如"使用本工具的十个技巧"、"如何优化你的工作流"、"高级用户指南"。
  
  Claude Code 团队的目标是：让工具本身就是文档。
  
  当你在 Claude Code 里卡住了，你可以直接问 Claude："我怎么做 X？"它会告诉你，因为它能访问自己的文档。当你想学习新功能，可以让 Claude 演示给你看。
  
  工具教你如何使用工具。
  
  这是产品设计的一种范式转变。以前，产品和文档是分离的。现在，当产品本身是一个 AI，产品和文档可以合二为一。
  
  你不需要写"用户手册"，因为用户手册就是对话本身。
  
  提示工程不会消失，只会变得隐形
  
  采访中有个小细节很有意思。
  
  有人说 Claude Code 生成的代码有时候比较冗长，Boris 的回应是："你可以直接跟它说'simplify it'，它就懂了。"
  
  这个回应很轻描淡写，但它揭示了一个深层现象：提示工程不会消失，只是会变得越来越隐形。
  
  几年前，"提示工程师"是个热门职位。人们花大量时间研究怎么写 prompt 让模型表现更好。现在，这个职位"不存在了"，但这不意味着提示不重要了。
  
  恰恰相反，提示变得更重要了，只是它融入了日常对话。
  
  "simplify it"就是一个提示。"think"是一个提示。"plan first"是一个提示。它们看起来像自然语言对话，但本质上是在精确地控制模型行为。
  
  区别在于：以前你需要学习一套"提示语法"，知道哪些词有魔力。现在，你只需要清楚地表达你的意图，模型会自己理解。
  
  但这不意味着"怎么说"不重要了。Cat 提到，即使是研究员，有时候也卡在不知道可以直接跟模型说"simplify it"。他们以为需要重新生成代码，或者手动修改，没想到一句话就能解决。
  
  这种"微技能"会随着每一代模型变化。Opus 4.1 需要的提示方式，Sonnet 4.5 可能不需要了。这让产品设计变得微妙：你要给用户多少"提示技巧"？
  
  Claude Code 团队的答案是：尽量少。
  
  他们的策略是让模型自己教用户。当 Claude 在执行任务时，终端底部会滚动显示"tips"。当用户可能需要某个功能时，界面会给出提示："按 Ctrl+O 查看完整 transcript"。
  
  更聪明的是，用户可以看到 Claude 自己使用 slash commands。当你看到 Claude 调用 /commit 时，你会想："哦，我也可以这么做。"模型通过示范教你使用工具。
  
  这是一种新的"用户教育"：不是通过文档，而是通过观察 AI 如何使用工具，然后模仿它。
  
  人类向 AI 学习如何使用 AI。
  
  这个循环很有意思。它暗示了未来的交互范式：也许最好的学习方式，就是跟一个已经精通工具的 AI 配对工作，看它怎么做，然后逐渐理解工具的逻辑。
  
  结语：工具消失的那一天
  
  采访快结束时，有人问了一个问题："CLI 是最终形态吗？"
  
  Boris 的回答很诚实："肯定不是。但我们不知道最终形态是什么。"
  
  他们在做各种实验：CLI、IDE 插件、Web 界面、移动端、GitHub 集成。每个都在试探边界。
  
  但有一个趋势很清晰：模型的自主工作时间越来越长。
  
  上一代模型可以自主工作几小时。这一代可以工作 30 小时。下一代可能是几天。再下一代呢？
  
  当模型可以工作一周，你的角色是什么？你不可能一直盯着终端看它干活。你需要的是一种"认知管理系统"，让你可以设定目标、监控进度、在关键节点介入。
  
  界面会从"输入输出设备"变成"协作仪表盘"。
  
  更激进的可能性是：也许根本不需要界面。
  
  当 AI 足够聪明，能够理解你的意图、自主规划、执行验证、处理意外，你只需要在早上说："我想完成 X"，晚上回来看结果。
  
  中间的过程？它自己处理。
  
  这就是"工具消失"的含义。不是工具不存在了，而是工具变得如此无缝，你感受不到它的存在。
  
  就像现在你用搜索引擎，不会想"我在使用一个信息检索系统"。你只是在找答案。工具隐形了。
  
  Claude Code 正在走向这个方向。从 IDE 到 CLI，是第一步简化。从 CLI 到自然语言对话，是第二步。从对话到意图理解，是第三步。
  
  最后一步可能是：你不再"使用" Claude Code，你只是在思考问题，而 Claude Code 自己知道该做什么。
  
  那时候，工具就真的消失了。
  
  剩下的只有你的意图，和实现意图的结果。
  
  中间的一切，都隐形了。
  
  这可能就是所有工具的终极形态。
  ---
  
  原始视频👉👉: https://t.co/nOxW9WTa51