Corey Rosamond · 2026/10/5 · 约 5 分钟阅读
本文为英文原文的简体中文译文。资料和事件日期保留原文发表时的语境；代码示例保持原样。 Read in English
我不想反复给你的软件写提示词，我只想把事情办好。如果我要办理退货、修改送货日期或查看订单，应用应该让我看清楚它需要哪些信息。一个空白聊天框，却让我在开始之前先琢磨这些问题。
对话很适合探索问题。但如果问题已经明确，同一个人每天需要重复完成同一项任务二十次，对话的吸引力就会下降。当企业准备花钱给应用加入 AI 时，这个区别值得认真考虑。
来自聊天工具开发者的及时提醒
在 9 月 24 日介绍 GitHub Copilot 应用的文章中，Burke Holland 介绍了 canvas：让人们通过一个小型应用与智能体协作，而不必只靠对话的界面。这是一篇产品介绍，不是对各种界面的受控比较。不过，这个方向很有意思。即使产品本身围绕 AI 助手构建，也有理由为用户提供消息框以外的操作方式。
对企业负责人来说，更有用的问题是：工作中的哪些部分值得通过对话完成，哪些应该已经由软件理解并处理好？
从一次普通的退货申请说起
假设一位店员正在处理客户退货。这是用来说明问题的流程示例，不是客户项目的实录。店员手里有订单号、两件商品和客户的简短说明。他需要找到原订单，确认退回哪些商品，并记录拟采用的处理方式。
以聊天为主的设计，可能让店员先发一段消息描述这些信息。助手接着询问是哪笔订单、客户是否想换货，以及应使用哪个地址。它或许完全有能力完成任务，但店员必须通过一轮轮回复，逐步发现系统究竟需要什么。
一个围绕任务设计的页面，可以同时展示订单搜索、已购商品、可选处理方式和相关政策。选中商品后，数量清晰可见。某个选项不可用时，界面解释原因。点击审核按钮后，在任何变更发生之前，页面会列出即将记录的内容。
AI 仍然可以发挥作用。例如，把客户的长邮件整理成简短说明草稿、建议分类，或查找相关政策段落。店员可以结合真实订单检查这些建议，而不必为了进入下一步，再组织一条新的指令。
空白输入框里隐藏的工作
常规界面可以直接展示可执行的操作。对话则常常要求用户询问可以做什么、记住已经确认了什么，并用文字描述修改。这种灵活性在任务不明确时很有价值；对于重复办理的业务，它也可能变成产品本来可以替用户省掉的工作。
比如，修改某一件商品的数量。在表单里，店员可以直接修改具体数值，同时看到其他信息。在对话里，他可能需要先说明指的是哪件商品，再确认修改是否影响了申请的其他部分。设计良好的聊天界面，可以用可编辑卡片等控件解决这些问题。而此时，真正承担产品功能的，正是这些控件。
好的表单同样需要设计。一个页面塞进三十个没有说明的字段，并不会更好。W3C 的表单指南建议，只询问完成流程所必需的信息，并提供清晰的标签和说明。它的通知指南还强调，应让错误信息容易理解，并确认操作是否成功。加入 AI 并不会消除这些需求。
把对话留给真正需要它的地方
我会把开放式输入留给真正开放的问题：描述特殊情况、探索不同方案，或者针对结果继续提问。复杂的说明，不应该被硬塞进无法表达它的下拉选项里。
当系统掌握了足够的信息，可以提出具体操作时，就应当用稳定、可编辑的视图展示该操作。在退货示例中，这意味着订单、商品、数量和处理方式始终可以一起查看。店员修改信息后，审核页面也应同步更新。
GOV.UK 设计系统的答案检查模式提供了一个实用参考：展示用户即将提交的内容，允许修改，并明确最终操作。这个模式并不是为 AI 发明的，但当模型代填了部分信息时，同样的基本思路依然有用。
应用仍然必须在服务器端执行权限检查和业务规则。一个友好的按钮并不是安全边界，聊天记录也不能证明变更已经成功。提交之后，界面应展示实际记录的结果，或者给出店员能够处理的具体失败信息。
让真正做这项工作的人试一试
在投入完整聊天机器人开发之前，先选一项高频任务，对比对话式原型和围绕任务设计的页面。给使用者贴近实际的例子，包括缺少一项信息、以及中途需要修改的情况。不要在旁边教他们使用助手所期待的那套措辞。
观察他们是否正确完成任务、在哪里犹豫、重复输入了多少信息，以及能否解释系统到底改了什么。把纠错时间也算进总用时。短期试用不能证明长期可靠性，但可以在大量开发之前，暴露出界面方向选错的问题。
有时对话会胜出。有时，一个表单、一张表格，或者放在恰当位置的按钮，就能让工作更轻松。实用的产品可以把它们结合起来，而不必让客户关心哪些部分使用了模型。
如果你的团队总是在向软件重复解释同一套工作流程，Rosecraft 可以帮助你把它做成专注于实际业务的应用。告诉我们，哪项任务总让大家回到聊天、邮件或电子表格中继续处理，我们可以一起讨论，更好的页面究竟需要完成什么。