Claude 正在从简单的聊天工具向全能工作台进化，这背后隐藏着产品经理必须掌握的新逻辑：任务拆解、工作流设计和权限管理才是AI落地的关键。本文通过Anthropic工程负责人Felix的实战案例，揭示如何让AI真正融入工作场景——从户型图自动建模到承诺追踪系统，从日报仪表盘到硬件权限设计，这些案例展现了AI产品从'聊天框思维'向'系统思维'的跃迁。

最近看了一期视频，嘉宾是 Anthropic 工程负责人 Felix Rieseberg。

我原本以为这会是一期很典型的 AI 工具分享：怎么写 Prompt，怎么用 Claude Code 提效，怎么把日常工作省出一点时间，看完之后发现，重点根本不在这，Felix 这期真正打到我的地方，是 Claude 正在从一个聊天框，变成一个能读材料、接数据、写代码、跑任务、做界面的工作台。

这件事对产品经理挺关键，因为过去我们聊 AI 产品，经常卡在两个问题上：模型够不够强？Prompt 怎么写得更好？

但 Felix 的案例反复说明，影响结果的不是某一句神奇提示词，而是你有没有把任务放进一个更合适的工作流里，说白了，别再只问 Claude 能不能替你移动鼠标了。

更应该问的是：这件事能不能让它在后台跑？上下文能不能让它自己读？结果能不能变成一个可复用的小工具？需要我判断的时候，它能不能再叫我回来？

一、入口多不是混乱，是任务还没收敛

Felix 负责的产品离用户很近，包括 Claude Co-work、Claude Code、Claude for Chrome，以及 macOS 和 Windows 的 Claude 桌面应用。

主持人问他最常用哪个入口，他选了 Co-work。

这个回答挺有意思，对工程师来说，Claude Code 很顺手，终端、文件、代码仓库都能接上。但 Felix 说，很多人看到终端就紧张，第三个标签页已经让他们有压力。

所以我觉得，Anthropic 现在不是在纠结到底留哪个入口，而是在用不同入口承接不同任务状态：

• 快速问答：你只是想得到一个答案。
• 深度工作：你希望 AI 持续读材料、组织上下文、做一件完整的事。
• 工程工作：你需要它改文件、运行代码、接工具、处理真实环境。

产品团队不用先迷信某一个终极 AI 工作台，更实际的做法，是先把团队里的任务拆出来，看它们分别处在哪种状态，比如产品经理每天会遇到三类事情：查一个概念、读一堆材料后输出方案、改页面或跑脚本。它们看起来都叫用 AI，但其实需要的入口完全不一样。

很多人觉得 AI 不稳定，其实是把三类任务混在一起了，你让聊天框长期记住一堆上下文，它当然会累。你让代码工具回答泛泛的战略问题，也会有点别扭。

入口的选择，其实是在给任务选工作环境，这个判断比争论哪个工具最强更有用。因为工具不是越全越好，而是要让用户在对的状态里开始。

二、他厉害的不是会用 AI，而是会把任务往上抽

Felix 分享了一个搬家的案例，他拿到一张房产中介给的户型图，但图上没有单位。

正常人会怎么做？可能是自己估算比例，或者让 AI 帮忙量一下某个房间大概多宽。

Felix 做得更彻底，他把披露文件、贷款信息、户型图和房屋记录放进一个文件夹，交给 Claude Co-work，让它找出户型图的单位，并重新生成一张带尺寸的图，Claude 后来在文件里找到了车库许可，用车库尺寸反推出整套房子的比例，到这里已经挺实用了，但后面的动作更关键。

Felix 原本想让 Claude 给几个室内设计方案，写到一半改口。他不想要几张静态建议图，他想要一个可以拖动家具的交互式规划器，于是 Claude 分析二维平面图，生成了一个 3D 房屋模型。Felix 可以在里面移动家具、切换视角，像玩一个很粗糙但刚好够用的室内规划游戏。

这不是炫技，值得产品经理记下来的，是 Felix 怎么把一个小需求一路往上抽：

1. 帮我识别户型图单位。
2. 帮我重新生成带尺寸的图。
3. 帮我做几个家具摆放方案。
4. 直接做一个可交互的 3D 家具规划器。
5. 再让它从邮件购买记录里找家具尺寸。

这里最重要的不是 Claude 会不会 3D 建模，重要的是 Felix 没有停在帮我完成一个动作，而是把任务往上抽成了帮我搭一个能持续解决问题的小系统。

这就是很多人用 AI 的差距，我们经常只让 AI 帮忙填一个格子、写一段话、搬一次数据。Felix 的用法是：如果这件事还会反复发生，那就别只做一次，直接让 AI 把它做成工具。

对产品经理来说，这个思路很适合迁移到工作里，比如你要做用户访谈分析，不要只让 AI 总结一份访谈纪要。可以直接往上问一层：

1. 读取所有访谈录音和文字稿。
2. 按用户角色、场景、痛点自动归类。
3. 建一个可筛选的洞察表。
4. 每次新增访谈后自动更新。
5. 输出本周最值得进入需求池的 5 个问题。

你只是少写一份纪要，这叫省时间，你把访谈分析变成一个持续刷新的系统，这才叫改变工作方式。

三、别把 Opus 当万能药

Felix 在户型图任务里用的是 Sonnet，他的判断很直接：大多数日常任务，Sonnet 已经足够好。

找公开网站、识别单位、读文件、重新生成图纸，这些任务并没有碰到模型能力天花板。需要 Opus 的场景，是人还没想清楚自己到底要问什么。

这个判断很适合产品团队，很多时候，我们会把两件完全不同的事混在一起：

1. 我还不知道问题是什么，需要你帮我一起想清楚。
2. 我已经知道要什么，需要你把它执行出来。

这两类任务对模型的要求不一样，如果你的输入、输出、边界和验收标准都很清楚，那就没必要每次都上最强模型。更快、更便宜、更稳定的模型反而更适合执行。

但如果你在做产品方向、客户问题拆解、复杂调研、战略判断，问题本身还没有成形，那就应该把更强的模型用在前面。

它像一个更贵的顾问，价值不是把 PPT 做漂亮，而是先帮你判断这个 PPT 到底该不该做、该讲给谁听、该从哪里开始讲。

所以我会更倾向于这么分：探索期用更强模型帮你重构问题，定义期让模型帮你拆任务，执行期再交给更快的模型批量处理。

很多团队觉得 AI 表现忽高忽低，不一定是模型不行，更常见的原因是，你让同一个提示词同时承担了探索、定义和执行，这谁能顶得住啊。

四、真正改变结果的，是它能读到什么

Felix 还讲了一个承诺追踪器，他经常在 Twitter 上答应别人，发我日志，我帮你看。问题是这些承诺散落在私信里，时间一久就容易忘。

于是他让 Claude 读取消息，记录自己答应过谁、什么时候该跟进，并且要求它别每次都重新读所有消息。

Claude 自己建了 SQLite 数据库，也建了一堆文本文件，Felix 没有纠结这些实现细节。因为这个工具只服务他个人，只要两周后能提醒他该兑现承诺，就够了。

这个细节特别产品，过去我们做工具，很容易被标准化、权限、架构、工程质量这些东西带着走。

它们当然重要，但在个人工作流和小团队内部场景里，有很多工具的评价标准其实很朴素：

它有没有减少一个反复发生的小摩擦？

如果有，它就有价值。不服务一百万人，也不影响它在当下很好用，Live Artifacts 也是这个方向。

Felix 现场让 Claude 做个人日报仪表盘，接入 Spotify、Gmail、Calendar、Notion 等连接器。重点不是日报本身，而是这个界面可以基于同一组授权持续刷新。

这意味着报告、仪表盘、Pitch Deck、项目周报，都可以从静态文件变成可更新的工作界面。

对产品团队来说，这里最该看的不是界面多酷，而是数据源变了，AI 的上限不只取决于 Prompt，还取决于它能不能拿到正确上下文。

日历、邮件、工单、客户记录、代码仓库、设计系统、销售进展，这些东西才是业务里的真实入口，我之前看很多 AI 工具，最容易感到别扭的地方就是，它们好像很聪明，但总是在空转，让你复制材料进去，让你补上下文，让你一遍遍解释业务背景。

这不叫工作台，这叫一个很聪明但刚入职的新同事。你每次都得重新带他熟悉公司。

好用的 AI 产品，应该反过来，它先问你要权限，然后自己去该读的地方读。读完之后，再把结果做成一个你愿意每天打开的东西，这里的产品壁垒，不只是模型，而是上下文入口和刷新机制。

五、别把等待当成失败，盯着它跑才是失败

这期访谈里还有一个很容易被忽略的点：延迟。

AI Agent 做复杂任务时，很难永远秒回。它要读文件、跑代码、调用工具、等网络、等权限。产品设计上如果还按传统聊天框思路处理，用户就会一直盯着屏幕，看它一步步动。

这很累，也很反直觉，如果 AI 最后还是要我全程盯着，那它只是把我的手解放了，没把我的注意力解放出来。

Felix 提到 Slack 早期的经验。以前发消息会立刻成功或失败，网络一抖用户就看到错误。后来 Slack 会先重试几次，过一会儿还是不行再提醒用户，iMessage 也类似。在信号不好的地方发消息，系统会自动稍后重试。

AI 产品也需要这种异步感，用户不是不能等，用户不能接受的是，不知道它在干什么，也不知道自己什么时候要介入。

所以 Agent 产品里，进度反馈应该从我正在努力变成更具体的状态：

1. 我读了哪些文件。
2. 我准备调用哪些工具。
3. 我下一步会改哪些地方。
4. 哪些操作需要你批准。
5. 如果失败，我会怎么重试或回滚。

这也是为什么 Claude Code、Co-work、桌面端这些形态很重要，它们不是在做一个更大的聊天框，而是在补齐工作流里的中间状态、权限确认和后台执行。

对用户来说，理想状态不是坐在电脑前看 AI 移动鼠标，理想状态是，你把任务交代清楚，然后去干别的。等它需要你判断时，再把你叫回来。

六、权限不是弹窗，是信任设计

这期里最有画面感的部分，是 Felix 做了一个 19 美元的小硬件。

它有屏幕、Wi-Fi、Bluetooth 和一点存储空间。Felix 把设备接到电脑上，告诉 Claude Code：我想让一个小 Claude 住在里面。每次我做得好，它就鼓励我。每次 Claude 需要我批准操作，请求就出现在这个大按钮上。

Claude Code 一次就完成了，现场演示时，他让 Claude 创建一个 hello world.txt。需要写入磁盘时，硬件发出提示，他按下按钮，权限就通过。

这个例子看起来像玩具，但它背后其实是非常严肃的产品问题，Agent 进入工作场景后，权限会变成体验的一部分，过去权限设计更多是弹窗、复选框、授权页。到了 Agent 时代，权限可能会变成：

1. 一个硬件按钮。
2. 一个审批队列。
3. 一个 dry run 预览。
4. 一份执行计划。
5. 一条桌面通知。
6. 一段可追溯的操作日志。

产品经理要重新理解确认这个动作，它不是打断用户，而是在关键节点让用户重新拿回判断权。

好的权限设计，会让人敢把任务交出去，也知道自己仍然握着方向盘，这个点我觉得会越来越重要。因为 Agent 越有能力，用户越需要知道边界在哪里。不是所有事情都要实时批准，但高风险动作一定要让人心里有数。

七、出错时，先别急着骂模型

主持人最后问 Felix，如果 Claude 走偏，他会怎么提示。

Felix 的做法很工程，他会把预期结果讲清楚，让 Claude 回溯自己在哪一步理解错了，再一起讨论下次如何避免同类问题。

很多时候，问题不在模型能力，而在工作流：

1. 数据源太脏。
2. 任务起点太模糊。
3. Prompt 结构不清楚。
4. 缺少 dry run。
5. 权限边界没有提前讲明白。
6. 中间结果没有可检查节点。

这点我很认同，现在很多团队试 AI，一失败就得出结论：这个工具不行，有时候确实是不行。但更多时候，是任务入口设计得太粗。

如果你把它当作一个工作台，而不是一次性聊天，复盘方式就会不一样。

你会问：

1. 它读的材料对吗？
2. 它有没有先写执行计划？
3. 它有没有在动手前列出会改什么？
4. 它有没有保留日志？
5. 它有没有在高风险动作前停下来问人？

这比单纯改 Prompt 有用得多，Agent 不是一次写完的自动化脚本，它更像一个会持续学习团队偏好的工作流系统。每一次 thumbs up、thumbs down，每一次人工纠偏，每一次 dry run，都在帮这个系统长出边界。

八、产品经理要补的，不是 Prompt 模板

这期最后还有一个小片段我很喜欢。

Felix 提到，有人把孩子手绘的小动物拍下来，交给 Claude 做成 jump-and-run 或 Flappy Bird。主持人的 9 岁孩子每天用 Claude，一边开终端一边研究网络安全。

成年人记得太多电脑过去做不到的事，所以会自动收缩需求，孩子不会。他们直接问：能不能做？

这也是产品经理最需要补的一块肌肉，不是背更多 Prompt 模板，而是重新训练自己，把一个模糊需求说成一条可执行的工作流。

比如不要只说：

帮我整理一下用户反馈。

而是说：

读取这周飞书群、客服工单和应用商店评论，按用户角色、问题场景、影响程度归类。先给我一份执行计划，不要直接改任何文件。确认后生成一个可筛选表格，并标出最值得进入下周需求评审的 10 个问题。

不要只说：

帮我做竞品分析。

而是说：

读取这 5 个竞品的官网、帮助文档和公开更新日志，按核心用户、主路径、收费方式、AI 功能入口、最近 3 次更新做对比。输出一份表格和一个结论页，结论页只保留我们该学什么、不要学什么、需要验证什么。

这不是提示词技巧，这是产品经理把任务定义清楚的基本功，AI 变强之后，很多过去只能写在需求文档里的东西，现在可以直接变成一个可运行的小系统，你的表达越接近工作流，AI 就越容易进入真实工作。

写在最后

Felix 这期访谈给我的最大提醒是，别再把 AI 产品理解成一个更聪明的输入框。

聊天框只是入口，变化发生在后面：它能读你的资料，接你的数据源，生成临时工具，在后台执行，遇到权限问题再叫你回来。

下次你发现自己在复制数据、整理材料、等待工具跑完，可以先停一下，这件事是不是不该只做一次？它能不能变成一个可刷新的界面？能不能让 AI 自己去读上下文？能不能先 dry run，再执行？能不能只在需要判断的时候打断我？

这个动作练熟了，AI 才开始从工具变成工作方式。