设计产品交互：让用户理解、控制并接续工作

系统会做任务，不代表用户能用它完成工作。用户还需要找到入口、给出信息、理解正在发生什么、辨别结果、修改错误，并在失败后继续。交互设计应让这些动作成本可见，否则“模型准确率提高”可能只换来更多审阅负担。

本章决定的是产品入口和结果形态。聊天适合开放意图、追问和调查；表单适合稳定字段与明确约束；业务页面内的建议适合当前对象相关任务；批量队列适合高频审阅。它们不是互斥产品类型。商品运营可以从列表批量进入，在侧栏追问缺失资料，最后在结构化差异表中确认。

先设计交付物，再设计对话

Finch的公开体验不只输出聊天答案，还在Slack显示进度、交付摘要与Google Sheet链接，并允许追问。这说明任务结果可以是可继续工作的产物。Uber工程文章 Shopify Flow则把自然语言需求变成能够继续编辑的流程草稿；转换和验证服务于既有产品格式，生成草稿与启用流程是不同责任。Flow工程文章

商品建档应交付“草稿及差异”，而非一段“已帮你整理”的回复。沿用实操包的CATALOG-01 / CAT-017、供方SUP-08 / SKU-017，正常材料支持500 ml、PP、黑色和120 g；用户需要逐字段打开A/B原句核对，不能把绿色检查状态当成含义正确。supported只表示当前材料支持候选，尚不表示人已接受。材料缺项或冲突时，也要让未决项留在产物中。

这是原创交互参考图，不是企业界面截图。可编辑SVG。箭头表示任务次序，不表示某一步通过就完成业务。图中形成候选的装配练习使用预录响应或窄语法规则；既有页面直接运行规范化facts规则，二者都没有测真实模型理解。

产品不必展示模型隐藏推理，应该展示可核对的事实、变更和未解决项。一个“置信度92%”不足以替代来源和冲突说明。能保存缺项草稿也不代表可以发布；本练习没有发布动作，不能靠按钮改名取得发布权限。

交互合同连接界面与执行

页面上下文必须包含明确对象。用户切换商品后，旧任务不能悄悄写入新商品。确认按钮应绑定对象、具体字段差异、资料版本和候选revision。商品净重若在A中为120 g、B中为150 g，界面应并排保留两来源，候选留空并标conflict，不能默认较新文件或较高置信度胜出。业务允许时，可以先确认并保存带未决项的草稿；这与解决冲突是两个动作。

在连续修订练习中，先确认r1但不保存；收到file-C/r1明确确认150 g并替代旧净重后，候选成为r2，r1确认失效。用户应看见净重为何改变，以及容量、材质、颜色、对象与不发布边界没有改变，再确认r2。这样同意才对应实际审阅过的内容，而不是一张无限使用的许可。

用户提交的是意图和确认，不是身份权限。应用取得可信身份并维护提案与版本，候选适配器提出字段，校验器核格式和已知约束；真实后台须在原子写入点复查授权、业务对象版本和幂等，界面呈现业务结果及未完成责任。本地revision不能替代共享后台的object_version；他人已改对象时，应展示冲突并重新审阅。可用并发迁移题检查这种设计，现有Map演示没有实现后台并发。

“正在保存”不等于成功。丢回执时显示write_unknown、保留原请求键，查询不可用就继续未知；恢复后核对保存证据，而不是换键新建。若始终无法核对，携带任务、请求、候选及已查结果交负责人。用户取消意味着停止本次动作，不应让模型换条工具路径继续；已经发出的写操作能否取消则由后台协议决定。演示仅用页面内Map，刷新即清空，不能据此证明进程重启后可恢复。

OpenGov公开演示提供页面记录解释、前端对象高亮、选题表单和待批准调用等不同交互。这些片段支持嵌入式业务助手，但不能拼成未经披露的预算审批全链。选题是补充输入，接受工具调用是执行决定，两者不应共用一个含义含糊的approved字段。官方演讲

正常、含糊、失败都要能继续

正常任务显示草稿、依据及保存结果；含糊输入只询问影响决定的缺失事实，比如“500的单位是什么”，不要要求用户重填全部材料；失败任务说明已完成什么、当前阻塞和恢复入口。转人工时携带任务对象、已收集事实和未执行动作，不能只提供一段聊天历史，让接管者重新调查。

等待也需要设计。短查询可显示进度状态；耗时任务应允许离开并回来；可取消的任务要说明取消是否能阻止已经发出的写操作。进度宜反映真实阶段，如“匹配商品”“检查字段”，不展示与执行无关的伪百分比。

试用时请目标用户完成三类合成任务，观察是否发现缺失事实、理解草稿与发布的区别、拒绝错误修改、从超时恢复。让未看答案的人解释“有来源却未确认”“确认后资料改版”“已写入却没回执”的下一步，并操作一次；可按商品演示操作指令准备。测量任务成功和审阅耗时，不只询问“是否喜欢”。若用户接受了错误值，应定位是模型错、证据展示不足、默认选择诱导，还是任务压力使其跳过检查。没有真人参与时，只报告检查设计或模拟走查，不宣称已改善使用性。

长任务如何显示进度并提供有效控制

招聘者给出岗位条件后，寻源与逐人评估可能持续到离开网页之后。LinkedIn的应用工程将GraphQL返回的业务数据整理成带显示信息的视图模型，通过会话级实时通道更新进度、候选结果和通知。平台另有消息持久化与重试。这说明一个关键分工：界面消费可恢复的业务状态，模型文字只是其中一种内容；断开流式连接不应等于工作被丢弃。Hiring Assistant应用工程、平台工程

假设以下招聘任务为合成教学例：寻找“有B2B销售经验、上海工作”的候选人，英语是加分项。第一批候选已出现，用户把城市改成苏州。界面应保留已完成的候选证据，并说明哪些结果仍按旧条件形成，等待按新版本复核；不应将新条件直接覆盖旧标题，使旧候选看起来已经满足新要求。可以用以下原创视图合同解释这一点：

{
  "task_id": "SYN-HIRE-07", "requirements_revision": 4,
  "state": "review_needed", "last_event_seq": 38,
  "results": [{"candidate_id": "SYN-C12", "evaluated_revision": 3,
               "needs_recheck": true, "evidence_refs": ["profile-2"]}],
  "actions": ["review_results", "pause_sourcing"],
  "message": "城市条件已改变，旧结果需重新核对；尚未外联"
}

这不是LinkedIn接口。它让前端能拒绝旧事件倒退状态，并在重新打开任务时先读取当前快照，再接续新事件。简单同步任务可以只返回一个结果；多端、可离开、可修改条件的任务才需要这样的恢复契约。UI允许“暂停寻源”也不代表能够撤回已发送消息，按钮说明必须对应执行边界。运行设计见长任务专题。

历史偏好进入界面时同样需要转换。CMA官方示例给出可勾选的岗位条件建议，并区分必备与加分；HLTM论文研究的是按账户、招聘者、项目归属组织记忆与检索，两者不是同一篇材料。把“此招聘者过去常选英语候选人”呈现为建议，允许审阅，比自动改成当前岗位硬条件更稳妥；用户拒绝也可能只是本岗位例外，不能直接删除长期记忆。CMA工程文章、HLTM v3 §3

交付物不同，审阅动作也不同

Morgan Stanley的Debrief将会议记录、行动项、后续邮件草稿与Salesforce接续，并由顾问编辑和决定是否发送；其知识助手Assistant是另一类任务。公开材料支持这种产品分工，没有交付全部保存与发送协议。官方发布

对会议记录工具，一句合成原话“我周五发清单，地址等客户确认后再改”至少形成三个不同对象：有执行者和期限的待办、地址未决事实、尚未发送的邮件草稿。用户审阅时应能分别改动作、核对原文、确认客户对象。一个统一“完成”按钮若同时保存纪要、创建待办并外发邮件，会把不同风险和恢复路径绑在一起。若CRM客户同名且未确定，仍可交付待核对草稿，但应阻止关联写入。

研报与经营报告则多一个可执行产物层。FinSight将分析中间数据与图表存入变量空间，生成短分析片段，再按提纲组合文字、图表标识和引用，后处理渲染成报告。此机制说明“最终文本看起来完整”还不够：图表引用能否解析、文件是否打开、单位与正文是否一致，都是交付检查。它是研究框架，不证明报告结论可直接用于投资决定。FinSight v1 §2.3–2.5

一个合成报告审阅界面可以展示“本节营业额采用万元、图轴误写元”的冲突，允许回到数据表与绘图代码，而不是只给“优化语言”的按钮。用图文报告时测用户能否发现错轴、断引用和未生成文件；纯文本备忘任务不必引入整套变量空间。选择产物形态，是根据下游怎样继续工作，而不是为了增加多模态能力。

本章完成后，团队应能画出关键界面，并对应目标流程的真实状态。下一章把界面依赖的事实、定义和权限整理成数据与知识合同。

参考资料

• Uber Finch、Shopify Flow（2026-04-22）、OpenGov：可继续工作的产物及嵌入交互。
• LinkedIn应用工程、CMA及HLTM v3，§3：异步交互、偏好建议与记忆，分别使用。
• Morgan Stanley Debrief发布：会议产物与人审；FinSight v1，§2.3–2.5：图文装配研究。
• Reimagined（2024），Ch07提炼笔记：可编辑输出、控制与渐进披露；属二手参考。

继续使用

上一章：设计人机目标流程 · 下一章：组织数据与知识 · 五篇阅读目录。相关工具：审阅、修改和恢复交互。

对照案例：Zalando商品建档。