AI 驱动的界面设计：当 AI 承担任务时的用户协作模式

上周，我们阐述了AI Native产品的交互设计指南，但是往往讨论 AI 产品的交互设计时，很容易讲空。真正落到产品里，用户面对的不是“透明、可控、协同”这些概念，而是更具体的问题：

我把任务交给 AI 之后，它会先做什么，什么时候来问我，结果出来后我该怎么确认，如果它理解错了，我又该怎么接回来。

这也是任务型 AI 产品和传统工具的根本区别。传统软件是“用户操作，系统响应”；

任务型 AI 更像“用户交办，系统执行，人在关键节点裁决”。

因此，界面设计的重点不再只是输入和输出，而是把这条协作链路设计完整：

用户发起任务 → AI 理解任务 → AI 执行任务 （异常时可接管）→ 用户确认结果

这一篇我们将以一项财务审计任务设计实践为例，来探讨AI Native产品的交互设计应该是什么样子的~

任务场景描述：

企业年度审计中，审计人员上传了总账明细、科目余额表、应收账款账龄表、销售合同、发票附件和部分回款凭证，希望 AI 先完成一轮初步风险分析，重点关注三件事：应收账款是否异常波动，收入确认与回款节奏是否匹配，哪些客户值得进一步抽样。

这个任务并不复杂，但足以把整条交互链路串起来。

这类财务审计B端 AI 产品，通常不会是一个单纯的聊天界面，而是一套围绕任务协作组织起来的工作台。

因为审计人员不是来和 AI 聊天的，而是来交办一项工作：上传资料、明确目标、等待系统执行，再对结果做判断。所以，这样的界面至少要同时承载五件事：任务上下文、AI 沟通、执行状态、结果查看和人工确认。

一个更合理的界面通常包含四个部分： 顶部是任务上下文，左侧是任务区（也是历史记录），中间是协作区，右侧是同步的工作台。

其中最关键的组织原则是：中间负责沟通与确认，右侧负责结果与依据。

从视觉上看，它是左中右三栏结构；但从交互逻辑上看，它其实是一套明确的人机协作分工。

在这个场景里，用户表面上只是上传资料并点击“开始分析”，但从交互设计角度看，他交出去的不是一句问题，而是一项任务委托。

因此，任务入口不应只有一个空白输入框，而应同时承载三件事：资料上传、任务目标选择、AI 将执行内容的摘要。用户提交后，系统最好立刻把任务对象、分析范围和预期输出组织成一段可读描述，例如：“基于 2024 年度总账、账龄表、销售合同和回款凭证，对收入与应收账款执行初步风险分析。”

这一步的重点不是让用户“说得更自由”，而是让系统接到一项可执行任务。在任务型 AI 产品里，交互的起点不是“用户输入了什么”，而是“系统是否接住了一项可以继续推进的工作”。

任务发起页 / 资料上传

用户发起任务，不等于 AI 已经理解任务。所以系统拿到资料后，不应立刻进入深度分析，而应先生成一张“任务理解确认卡片”。

在这个例子里，这张卡片至少应包含：企业名称、审计期间、已识别模块、系统理解到的任务目标，以及仍待确认的问题，比如“资料期间存在交叉”“部分回款附件缺失”。

这里最重要的，不是展示 AI 识别了多少字段，而是让用户一眼看见哪里轮到自己判断。高确定性信息可以直接预填；低确定性信息不必显示抽象置信度，而更适合转译成界面状态，如“待确认”“待补充”“发现冲突”。

任务理解阶段真正要解决的，不是“系统有没有输出”，而是“系统有没有和用户对齐”。因为在专业场景里，高效地做错，通常比慢一点做对代价更高。

用户待确认

任务范围确认后，系统才真正开始执行：解析账龄表、匹配合同与回款记录、识别高账龄异常客户、生成抽样建议。

这时用户最怕的不是慢，而是静。一个只显示“分析中”的界面，会让人无法判断系统是否还在工作、现在进行到哪一步、是否遇到了阻塞。

因此，执行阶段至少要让用户看到两层信息：一层是总状态，例如“执行中、待补资料、已完成”；另一层是步骤状态，例如“正在匹配回款记录”“正在生成抽样建议”。对于耗时较长的任务，还应明确转入后台执行，并保留任务入口或委派卡片，让用户知道可以离开，但任务不会中断。

执行中如果发现关键资料缺失，也不应等到最后统一报错。

比如系统发现两家客户缺少完整回款凭证，就应该即时提醒“相关判断将基于现有资料生成，建议后续补充附件”，并给出“现在上传”或“稍后补充”的动作入口。让边界尽早暴露，本身就是高风险场景里重要的交互责任。

执行过程中的步骤状态与进度播报

分析完成后，系统可能识别出几类结果：应收账款周转率异常上升、部分客户账龄偏高但收入增长明显、期末收入确认与回款节奏不匹配，并给出优先抽样建议。

很多 AI 产品走到这里就结束了，输出一段总结。但在B端业务场景里，结果页不应是“AI 报告”，而应是一张待处理工作台。

更合适的结构是：

这样，结果就不只是被阅读，而是被处理。这里有一个关键边界：AI 可以解释和建议，但不能自动改结论。解释的作用是帮助用户理解依据、完成判断，而不是替代判断本身。对于审计这类专业任务来说，结论必须能追溯、能复核，也必须保留人工确认的位置。

风险总览与异常清单

真实工作不会完全按预设流程推进。

在这个例子里，审计人员可能会把某条异常的风险等级从“高”改成“中”，加上一句“长账期渠道，需结合历史回款复核”；也可能在任务进行中突然插问一句：“顺便看下前五大客户的回款集中度有没有异常。”

这些都说明，任务型 AI 的成熟度不只体现在主流程，而体现在异常流程。更好的设计，不是把用户强行拉回原路径，而是支持局部修正、保留上下文，并让 AI 原判断与人工裁决并列留痕。对于中途插问，系统也不必一律拒绝，而可以让用户选择“作为当前任务的补充分析”或“新建子任务”。

好的异常处理不是减少偏航，而是保证偏航后仍能继续前进。系统可以出错，流程可以变化，但用户不能被晾在原地。

当 AI 开始替用户干活时，界面设计的重点就变了。它不再只是把结果展示出来，而是要把交办、执行、确认、接管这条协作链路组织清楚。

对财务审计这类专业场景来说，真正决定产品可用性的，往往不是模型有多强，而是用户是否始终知道：系统理解了什么，系统正在做什么，结果基于什么依据，出了问题下一步怎么办。

这也是任务型 AI 界面最核心的设计目标：让 AI 能执行，让用户能判断，让协作过程始终可见、可控、可恢复。

1. Microsoft HAX Toolkit：Disambiguate before acting

微软 HAX 工具集：操作前先明确语义 / 消除歧义

2. Progress Indicators Make a Slow System Less Insufferable

尼尔森・诺曼集团：进度提示可缓解系统卡顿带来的体验不适

3. Google PAIR：Explainability + Trust

谷歌 PAIR 团队：可解释性 + 信任度