企业 AI 助手的产品设计复盘——从聊天界面到嵌入业务流程的演进

一、聊天界面不是企业 AI 的终局

2024 年到 2025 年，大量企业级 AI 产品以聊天机器人形态上线。界面统一是左侧对话列表、中间聊天窗口、底部输入框，用户在对话中提问，AI 流式回复。这套体验对通用场景（知识问答、文案生成）是合理的，但在企业管理场景中却暴露出明显的问题。

首先是上下文断层。用户在处理一个业务问题时（例如审批采购单），需要先切换到 AI 助手、输入问题、等待回答、再切回业务系统执行操作。中间的过程割裂，操作路径变长。其次是交互效率低。许多企业场景下用户的需求是"帮我把这张表格里的 500 条数据清理一遍"或"根据上个月的数据自动生成报表"，而不是"我打字问你，你打字告诉我"。聊天模型无法承载这种对结构化操作的诉求。

我们的产品在 2025 年中经历了一次重大的设计方向调整：从独立的聊天界面，向嵌入式业务助手转型。核心理念是 AI 不再是一个需要用户"走过去用"的工具，而是"就在你手边"的业务能力。

二、嵌入业务流的产品架构

在审批页面中，AI 助手不是一个独立窗口，而是以侧边栏或面板的形式嵌入页面的右侧。当用户打开一张采购审批单时，AI 自动分析审批内容并展示：该供应商的历史合作记录、同类采购的平均价格对比、异常项高亮提示和审批建议。用户无需提问，AI 已经完成了上下文感知的分析。

在数据报表页面中，AI 提供自然语言查询入口。用户输入"上个月销售额前 10 的商品是哪些"，AI 将其转化为查询语句，在页面上直接展示结果。这不是一个孤立功能，而是嵌在报表页面内的一个组件。

这种嵌入式设计的关键优势是上下文自动注入。AI 知道用户当前在哪个页面、查看什么数据、扮演什么角色，不需要用户每次手动描述上下文。减少了交互摩擦的同时，提高了 AI 回应相关性和准确度。

三、三阶段产品迭代路径

第一阶段的定位是"问答助手"，提供独立聊天页面，用户向它提问。这个阶段的核心指标是用户活跃度和问题解决率。大多数产品的初版都在这个阶段，技术难度最低，但价值天花板也最低。

第二阶段的定位是"任务助手"，AI 不仅能回答问题，还能执行操作："帮我生成一份上周的销售周报"、"帮我把这三条数据标记为异常"。后台集成了业务 API 编排能力，AI 根据用户指令调用业务接口执行操作。这个阶段需要处理权限、操作审批和回滚机制。

第三阶段的定位是"场景助手"，不再需要用户显式下指令。AI 根据页面上下文自动分析并推送建议。在采购审批页面上，它自动对比价格、检查合规性；在库存管理页面上，它自动预警补货建议；在客服工作台上，它自动推荐回复话术。

@Service
public class SceneAwareAssistant {
    private final ContextCollector contextCollector;
    private final LlmService llmService;
    private final SuggestionRegistry suggestionRegistry;

    public List<SceneSuggestion> generateSuggestions(PageContext pageContext) {
        // 1. 采集当前页面上下文
        SceneContext scene = contextCollector.collect(
            pageContext.getPageType(),
            pageContext.getBizData(),
            pageContext.getUserRole()
        );
        if (scene == null || scene.isEmpty()) {
            return Collections.emptyList();
        }
        
        // 2. 获取该场景注册的建议策略
        List<SuggestionStrategy> strategies = suggestionRegistry
            .findStrategies(pageContext.getPageType());
        
        List<SceneSuggestion> suggestions = new ArrayList<>();
        for (SuggestionStrategy strategy : strategies) {
            try {
                SceneSuggestion suggestion = strategy.analyze(scene, llmService);
                if (suggestion != null && suggestion.getConfidence() > 0.7) {
                    suggestions.add(suggestion);
                }
            } catch (Exception e) {
                // 单条建议生成失败不影响其他建议
                log.warn("建议生成失败, strategy={}, error={}", 
                    strategy.getClass().getSimpleName(), e.getMessage());
            }
        }
        
        // 3. 按优先级和置信度排序，截断 Top-N
        suggestions.sort(Comparator
            .comparingInt(SceneSuggestion::getPriority)
            .thenComparingDouble(s -> -s.getConfidence()));
        return suggestions.stream().limit(5).collect(Collectors.toList());
    }
}

四、嵌入过程中的权限与安全边界

嵌入式 AI 助手面临的安全挑战比独立聊天页面大得多。关键原因是它在业务流程内部运行，需要访问敏感业务数据。权限设计上必须满足：AI 的可见数据范围等于用户的数据权限范围，不能越界；AI 的操作权限需要在后台逐接口审批，默认所有操作需要用户二次确认。

一个具体的做法是：AI 的所有业务 API 调用都通过一个代理网关，网关在每次调用前校验当前用户的 Session 权限。如果 AI 尝试调用用户没有权限的接口，网关直接拦截。这种设计确保 AI 的操作权限永远不会超出用户的权限边界。

另外需要做好操作审计。AI 助手生成建议、执行操作、修改数据，每一步都在操作日志中记录操作者标识（区分"用户操作"还是"AI 建议→用户确认"），便于后续追溯。一旦发现 AI 引入了错误，完整的操作链路可以快速定位回滚范围。

五、度量与持续迭代

嵌入式 AI 助手的效果度量不应只看"对话次数"，而要看对业务效率的实际影响。关键指标包括：目标页面的操作完成率（有 AI 辅助前后的对比）、页面停留时间变化（辅助降低了信息检索时间）和业务决策质量指标（如审批驳回率变化）。

数据驱动的迭代也很重要。统计哪些场景的建议被采纳率高、哪些场景的建议被频繁忽略，可以指导下一阶段的优化方向——对高采纳场景加强 AI 能力，对低采纳场景缩减 AI 干预。保持"AI 不干扰正常工作流"是产品体验的底线。