Claude：当聊天开始真正动手

从一个具体任务出发#

让助手比较两个供应商网页，整理带来源的摘要。任务完成需要选对供应商、找到相关信息、区分事实与推断，并让用户在后续重要操作之前检查结果。

计划观察的路径是：澄清请求 → 确认来源 → 观察浏览器工作 → 检查摘要 → 纠正或停止任务。目前没有完成时间或成功率数据。

读懂这张界面图#

123

1. 意图留在屏幕上。 左侧能看到澄清问题和指定供应商的请求。
2. 来源可以直接检查。 右侧浏览器显示网页、标签与地址，用户能把回答和正在查看的内容联系起来。
3. 工具活动有反馈。 对话报告浏览器使用并显示活动状态；这说明正在工作，不能单独证明比较已经完成。

别人的研究与体验怎样补充分析#

厂商研究 Anthropic 的 Claude Code 会话研究用日志讨论规划与执行的分工。这提示我们研究委托时，要问谁确定目标、谁作出执行选择；它不是 Cowork 的可用性测试。报告与方法。

作者体验 Valliance 的 Claude Design 个案沿任务记录迭代、直接反馈与信息混杂的问题。体验原文。这是 4 月的浏览器产品体验，不能替代 Cowork 观察。

本站的延伸问题： 人的需求能否在 AI 执行时持续可见，活动提示与最终依据能否对应？调研可以帮助提出问题；具体界面是否有效，还需相应的证据。五份配图选读。

哪些地方做得好#

设计判断 左右并排有利于识别：用户可以同时参考需求与来源，不必把它们全记在脑中。人工检查也有了具体对象，用户可以拿网页核对摘要中的说法。

示例中的澄清把模糊请求转化成明确任务。先问清比较哪些工具，可以防止 AI 朝错误方向继续。聊天既是任务说明，也保留了任务如何逐步明确的过程。

功能公告说明，桌面应用中的内置浏览器与用户平常的浏览器相互独立，同时保留 Chrome 集成。这种区分有利于解释委托，但也增加了界面需要教会用户的概念。浏览器公告。

哪些地方可能造成交互阻力#

委托意味着什么。 习惯“问建议”的用户，未必预料到相似的聊天界面会操作工具。界面应该用人能理解的方式说明当前范围：哪些来源、哪个账号、能读什么、能改什么。这张图没有展示完整授权流程，不能据此断言流程缺失或设计充分。

正在用哪个浏览器。 地址栏能标识网站，却未必解释当前账号和浏览器环境。我的假设是：纠正任务时，用户可能混淆内置浏览器与常用浏览器。这需要实际观察。

活动反馈不等于证据。 活动提示让人知道系统在工作，但比较任务还需要解释访问了哪些供应商、提取了什么事实、还有哪些来源待核对。转圈动画不能当作正确性的依据，也不该被误读为剩余时间承诺。

监督成本。 当前官方安全文档区分读取与写入工具，描述云端会话通过桌面端访问已连接的本地资源，并说明授权模式与删除保护。这是 10 月 3 日读到的文档规则，不能从宣传图验证实际行为。HCI 要研究的是：用户在操作发生时能否理解这些规则。当前 Cowork 安全说明。

本文参考 Nielsen 的启发式原则中的状态可见性、识别、错误预防和用户控制；没有声称测量了认知负荷或完成了无障碍审计。

一个可以试验的改进方案#

在聊天与浏览器之间加入持续可见的委托摘要：标识工作环境、来源与任务阶段，把“收集信息”和“产生外部影响”明确区分。任务后果增大时，给用户一个合适的检查节点；常规读取仍能继续进行。

停止入口应解释：已经完成的操作是否保留。恢复能力也要说明范围；停止后续浏览器动作，不能自动保证撤销此前每一步。

怎样验证这个判断#

准备两个虚构供应商页面，故意让醒目的价格与某个关键条件不一致。观察新手与熟练用户能否发现差异、指出最终选择的来源。不同界面方案使用相同内容，并交替安排任务顺序。

让用户说明当前浏览器和任务范围，纠正一次供应商选择，并在准备好的外部操作发生前停止任务。记录完成情况、走错的路径、求助次数与耗时秒数，再询问用户理解的“停止”效果。界面更安静，但委托边界更难理解，不能算改善。

目前的判断： 演示中的聊天、来源页与活动提示有利于检查。接下来要研究的是：同一流程能否清楚传达委托范围和操作后果。

研究更新记录#

• 修订 1 · 2026-10-03： 加入有日期的功能上下文、官方演示、文档核对和启发式分析。

• 修订 2 · 2026-10-03： 加入会话研究原图、设计团队体验与配图选读，注明 Code、Design 和 Cowork 的范围。

• 下一步： 指定桌面版本，截图记录澄清、授权、运行、结果和恢复状态；普通 Chat 与 Artifacts 应另行研究，再与 Cowork 比较。

草稿使用 AI 辅助，待我个人审阅；没有声称做过个人上机测试。分析方法 · Codex 分析。