以产物为中心
报告、文档、代码与工单等产物的呈现和迭代。
一句话理解：用户真正要的是产物——报告、工单、代码、表格、邮件——对话只是生产过程；界面应该让产物成为主角，支持定点修改、版本对比，并能真正交付到业务系统里。
想象你让 SEO 诊断 Agent 出一份全站诊断报告。在纯聊天界面里，报告是一条 3,000 字的长消息。接下来的体验往往是这样的：你想让它把第三部分的建议写得更具体，于是在输入框里打字“把第三部分改得具体一点”；Agent 重新输出了一整条 3,000 字的消息，你需要逐段对比才能发现它顺手还改了第一部分的结论；你想把报告发给开发团队，只能复制粘贴，格式全乱。
问题在于，聊天界面把 产物 当成了 消息。消息是一次性的、线性的、不可编辑的；而产物需要被反复修改、被比较、被审核、最终被交付。这一课讲以产物为中心的界面设计。
为什么要以产物为中心
| 维度 | 产物作为消息 | 产物作为一等对象 |
|---|---|---|
| 修改方式 | 用自然语言描述改哪里，整体重新生成 | 选中具体位置，定点修改 |
| 变更可见性 | 需要人工逐段对比 | 自动显示修改前后差异 |
| 版本 | 散落在对话历史里 | 有明确的版本列表，可以回退 |
| 与证据的关系 | 需要翻回对话找依据 | 产物中的结论直接链接到证据 |
| 交付 | 复制粘贴 | 导出为文件，或直接写入业务系统 |
| 协作 | 只有发起人能看到 | 可分享、可评论、可交给他人审核 |
以产物为中心并不意味着取消对话。对话仍然是下达指令和补充要求的主要方式，只是 对话服务于产物，而不是反过来。
不同产物的呈现方式
| 产物类型 | 典型场景 | 呈现方式 | 关键交互 |
|---|---|---|---|
| 报告与文档 | SEO 诊断报告、销售周报 | 结构化文档，章节可折叠，结论带证据链接 | 按章节修改、评论、导出 |
| 数据分析 | 销售下降原因分析 | 表格 + 图表 + 口径说明 + 可展开的查询语句 | 调整维度与时间范围、下载数据 |
| 代码 | Coding Agent 修复 Bug | 文件级 diff + 测试结果 + 变更说明 | 逐文件审查、行内评论、创建 PR |
| 工单与记录 | 售后退款工单 | 表单式预览，字段与业务系统一致 | 编辑字段、提交到工单系统 |
| 消息与邮件草稿 | 订单延迟说明邮件 | 按接收方看到的样子预览 | 修改正文、选择收件人、发送 |
| 问题清单 | SEO 问题列表 | 可排序、可筛选的表格，每项有严重程度与修复建议 | 标记已处理、批量分派给负责人 |
一个细节：预览要尽可能接近最终形态。客户通知要以短信的样子预览，而不是一段 JSON；工单要以工单系统的字段布局预览。用户审核的是“别人最终会看到什么”。
布局：过程与产物分栏
一种被广泛采用的布局是左右分栏：一侧是对话与执行过程，另一侧是产物画布。以 SEO 诊断报告为例（图 1）：
这个布局支持了三个关键行为：
- 定点修改：用户选中第 3 节再提要求，Agent 只修改这一部分，并明确告知“其余未改动”。
- 变更可见：修改后的部分有标记，一键对比上一版本。
- 从产物出发的后续动作：评论、审核、分派，都直接挂在产物上。
迭代与版本管理
产物往往要改好几轮。版本管理的设计要点：
- 每次修改生成新版本，保留修改说明（谁、什么时候、因为什么要求、改了哪里）。
- 支持对比任意两个版本。对文档显示段落级差异，对代码显示行级 diff，对表格高亮变化的单元格。
- 允许锁定已确认的部分。用户确认了“结论摘要”之后，可以锁定它，后续修改不会动到这一节。这解决了“改 A 顺手改坏了 B”的问题。
- 可以回退。新版本不如旧版本时，一键恢复。
- 人工编辑与 Agent 编辑同等对待。用户直接在产物上手动修改后，Agent 要基于修改后的版本继续工作，而不是用自己记忆中的旧版本覆盖。
最后一点在工程上需要特别注意：产物的“单一事实来源”应该是产物存储本身，而不是 Agent 的上下文。Agent 每次修改前读取最新版本，写入时检查版本是否已被他人改动。
从草稿到交付
产物的生命周期不止于“生成完成”。一个完整的状态流转（图 2）：
| 状态 | 含义 | 界面表现 |
|---|---|---|
| 草稿 | Agent 生成或修改中 | 可以自由修改 |
| 待审核 | 等待人审核 | 显示审核人与审核要点 |
| 已批准 | 审核通过，尚未交付 | 显示交付目标与交付按钮 |
| 已交付 | 已发送、已提交、已写入业务系统 | 显示交付凭证：工单编号、PR 链接、邮件发送记录 |
| 已验证 | 确认交付真正生效 | 例如工单系统中能查到该工单、PR 的 CI 通过 |
“已交付”和“已验证”要分开。Agent 调用了创建工单的接口，不等于工单真的创建成功了。交付后读回确认的方法见 各类动作的验证方式，界面上要显示可点击的交付凭证，例如工单编号直接链接到工单系统中的那条记录。
交付到哪里 同样是产品决策。对企业用户而言，产物停留在 Agent 产品里价值有限，真正的价值在于进入他们的业务系统：报告进入知识库、工单进入工单系统、代码进入代码仓库。导出与写入的能力，往往决定了 Agent 能否嵌入真实工作流。
常见误区
- “产物就是 Agent 最后一条回复。” 最后一条回复是产物的一个快照，而不是可管理的对象。
- “用户想改哪里，用对话说清楚就行。” 用自然语言定位修改位置效率低且容易误解。选中即修改更直接。
- “每次都整体重新生成，保证一致性。” 整体重生成会引入用户没要求的改动，破坏已经确认的内容。
- “生成完就算完成。” 产物只有交付到目标系统并被验证，任务才真正完成。
设计要点
- 产物是独立于对话的一等对象，有自己的版本、状态和操作。
- 预览尽可能接近最终形态：短信像短信，工单像工单。
- 支持选中局部定点修改，修改后明确告知改动范围并可对比。
- 版本可对比、可回退、可锁定已确认部分；人工编辑与 Agent 编辑基于同一个最新版本。
- 产物中的结论链接到证据。
- 区分草稿、待审核、已批准、已交付、已验证，并展示可点击的交付凭证。
- 优先支持把产物交付到用户的业务系统，而不只是停留在 Agent 界面中。
练习
为「销售分析 Agent」的周报产物设计交互（30–45 分钟）：
- 画出左右分栏的文字线框，右侧周报包含结论摘要、数据图表、原因分析、建议四个部分。
- 设计一次定点修改：用户选中“原因分析”并要求“补充华南区的对比”，写出修改后界面的变化（标记、提示文案、对比入口）。
- 定义周报从草稿到已验证的状态流转，写清楚交付到哪里、交付凭证是什么、如何验证交付成功。
下一步
报告、工单这类产物通常需要几分钟甚至几小时才能完成，用户不会一直盯着看。下一课「异步任务体验」讲后台运行、通知、恢复与多任务并行。