haoee企业做了4个AI助手，员工还是不用：一次“月度运营复盘”任务改造

一家培训服务机构已经上线了4个AI应用：

• 制度与课程知识问答；
• 会议纪要助手；
• 材料写作助手；
• 表格分析助手。

单独测试时，每个应用都能正常工作。但实际推广后，运营人员仍然习惯找同事处理任务。

问题不是AI能力不够，而是员工不知道该先用哪个，也不知道几个应用怎样协同。

下面用“生成7月课程运营复盘”这个任务，拆解一次完整改造。

本文案例由常见交付场景合并整理，不对应具体客户，不使用虚构效果数据。

一、原来的AI为什么没有解决问题？

运营人员向通用助手提出：

帮我做一份7月课程运营复盘，重点分析报名、到课、用户反馈和下月改进方向。

第一版AI很快生成了一份结构完整的报告，包含“活动概况、数据表现、问题分析、改进建议”等章节。

看上去不错，但不能直接使用。

原因很简单：它没有读取7月报名数据，不知道实际到课情况，也没有查询用户反馈。所谓“数据表现”和“问题分析”，只是根据通用经验生成的内容。

从模型角度看，回答已经完成；从业务角度看，任务根本没有完成。

这类任务至少包含五个步骤：

1. 确认复盘口径和报告模板；
2. 获取报名、到课和转化数据；
3. 汇总用户反馈与常见问题；
4. 对数据进行计算和比较；
5. 生成有依据、可复核的报告。

单一聊天模型只能覆盖第五步的一部分。

二、先把任务拆成“问、看、写、办”

产品团队没有继续修改提示词，而是先重新拆解业务任务。

“生成课程运营复盘”实际涉及四类基础能力。

1. 问知识

需要查询：

• 课程运营复盘模板；
• 报名、到课和转化的指标口径；
• 机构内部的报告格式；
• 历史复盘中的常见问题分类。

这些内容进入知识库。

其中，控制知识库存放稳定指标口径、报告结构和禁止使用的表述；证据知识库存放课程资料、历史复盘和脱敏后的业务材料。

2. 看数据

需要读取：

• 课程报名表；
• 到课记录；
• 用户反馈汇总；
• 上月可对比数据。

表格读取、字段识别、数据清洗、分组统计和异常提示，可以封装成表格分析Skill。

如果数据存放在CRM或报名系统中，则通过只读MCP Server查询。第一阶段不开放修改客户信息、订单状态或课程安排的能力。

3. 写材料

根据分析结果生成复盘报告，但要求每项结论都能追溯到具体数据或反馈来源。

例如，不能只写“用户满意度较高”，而应说明这个判断来自哪组反馈；数据不足时，应明确写“当前资料无法支持该结论”。

4. 办事情

报告生成后，可以形成待办建议，例如：

• 补充某类课程FAQ；
• 跟进多次出现的服务问题；
• 准备下月活动材料；
• 将待确认问题交给运营负责人。

这些建议只生成待确认清单，不直接修改业务系统或自动发布报告。

三、建立一套AI能力目录

要让AI工作助理完成路由，首先要让它知道组织里有什么能力。

团队为现有应用建立了能力目录：

能力目录还需要记录负责人、版本、更新时间、适用场景和失败处理方式。

否则，AI工作助理可能推荐已经停用的应用，或者使用过期知识。

四、用Planner、Generator、Evaluator组织任务

改造后的工作流不是把所有能力塞进一个提示词，而是采用P/G/E结构。

Planner：规划任务

Planner收到“生成7月课程运营复盘”后，先输出任务计划：

1. 查询复盘口径；
2. 获取7月报名与到课数据；
3. 读取用户反馈；
4. 执行表格分析；
5. 生成报告；
6. 检查数据依据和风险；
7. 等待运营负责人确认。

它还要判断当前用户是否有权访问相关数据。

Generator：执行任务

Generator根据计划调用：

• 课程运营控制知识库；
• 报名系统只读MCP；
• 表格分析Skill；
• 材料写作能力。

任何一个工具调用失败，都不能继续假设数据存在。例如报名系统查询失败时，应该返回“数据获取失败，报告暂不生成”，而不是用估算数据补齐。

Evaluator：检查结果

Evaluator重点检查：

• 报告是否使用了正确模板；
• 每项数据结论是否有来源；
• 是否遗漏报名、到课和反馈维度；
• 是否出现超出数据支持的判断；
• 是否包含个人敏感信息；
• 是否把建议写成已经确定的决策。

未通过检查的报告返回Generator修改。最终版本仍由运营负责人确认后使用。

上下文记忆负责保留经过确认的报告偏好、历史纠错和有效模板，但不自动修改知识库或MCP配置。

五、路由失败时，不要让AI硬做

实际运行中，运营人员又提出一个新需求：

帮我分析用户投诉，判断哪些顾问服务有问题。

现有能力目录中没有投诉数据，也没有员工评价规则。

这时，AI工作助理不应该凭聊天记录直接评价某位顾问，而应生成需求单：

{
  "需求": "课程投诉数据分析",
  "使用者": "运营负责人",
  "缺少能力": [
    "投诉数据知识库",
    "问题分类Skill",
    "CRM投诉记录只读MCP",
    "人工复核规则"
  ],
  "风险": "涉及员工评价和个人信息",
  "建议": "先建设辅助分析能力，不自动输出人员考核结论"
}

这就是“需求雷达”的价值。

它不是为了证明AI什么都能做，而是把做不了的高频任务沉淀为下一轮能力建设依据。

六、验收不能只看“报告生成成功”

改造后，产品团队需要重新定义验收指标。

路由指标

• 任务是否被识别为复盘分析；
• 是否调用正确知识库、Skill和MCP；
• 是否把高风险环节交给人工确认。

数据指标

• 必填数据是否完整；
• 指标口径是否一致；
• 数据来源和时间范围是否明确；
• 工具调用失败时是否停止生成。

内容指标

• 报告是否符合模板；
• 结论是否有数据支撑；
• 是否出现无依据推断；
• 人工需要修改哪些内容。

业务指标

• 运营人员是否完成了复盘任务；
• 是否减少跨工具查找和手工整理；
• 哪些环节仍然需要人工处理；
• 新的能力缺口主要集中在哪里。

“生成一篇报告”只是输出指标；“帮助运营人员完成复盘”才是业务指标。

七、为什么不建议一期就做成全能助手？

如果AI工作助理一开始就能查询所有数据、修改系统、自动发布报告和调整知识库，权限和风险会迅速扩大。

更稳妥的建设顺序是：

第一阶段，完成轻办公、知识查询、能力导航和应用路由。

第二阶段，接入表格分析等低风险Skills，以及只读型MCP Server。

第三阶段，根据真实使用记录扩展专业应用，并在关键操作中保留人工确认、日志和版本管理。

先做稳定闭环，再逐步增加自动化，比一开始追求复杂自治更容易交付和维护。

八、智能体运营平台与私有化平台分别适合什么场景？

智能体运营平台，培训、咨询和内容服务团队可以通过它组织自己的知识库、Skills、MCP、智能体入口和客户服务流程，把一次性服务逐步转成可持续运营的智能体服务。

高校、政府、医院、国企和产业园区等机构，则更适合采用私有化AI服务要素平台。

这类项目不仅需要AI工作助理和“1+4+N”应用层，还要强调数据不出域、模型中立、组织权限、日志审计、行业应用和长期演进。

两种产品形态共享模型、智能体和数据能力建设思路，但客户对象、部署方式和治理深度不同。

值得注意的是这个案例的核心不是“如何让AI写出一份更漂亮的报告”。

真正的改造，是把一个模糊任务拆成知识查询、数据读取、能力调用、内容生成、结果评估和人工确认，再让每个环节都可追踪、可维护、可继续改进。

企业AI的干货，不在于展示多少个智能体，而在于回答五个问题：

谁在什么场景使用？ 需要哪些真实数据？ 调用哪些知识和工具？ 哪些操作必须让人确认？ 最终怎样证明任务完成？

这五个问题想清楚了，智能体才开始从Demo进入业务。