Use Case
内部报告 AI Agent 工作流
把重复的运营、销售或交付汇总做成可审阅的内部报告，并明确数据来源边界。
它解决的典型问题
- 周报月报仍靠一个人手工追数据、改格式、拼摘要
- 各部门上报格式不统一，横向对比慢且不可靠
- 关键异常被埋在表层数字里，管理层很难快速看见
工作流步骤
- 收集周期性来源数据
- 整理成报告字段
- 生成摘要并标记异常
- 指出缺失数据或解释不确定项
- 进入人工审阅后再分发
需要的输入材料
- 报告来源字段
- 固定报告模板
- 缺失或冲突数据的升级规则
- 接收对象和分发要求
输出与交付物
- 标准报告模板字段
- 异常与缺失数据标记
- 摘要草稿结构和 review 检查点
- 分发与审批规则
哪些情况必须升级
- 数字缺失或互相冲突
- 看起来有风险，但上下文不足以解释
- 敏感报告准备对外或给高层之前
边界
- 不编造缺失数据
- 不把未经验证的表现总结当成最终事实
- 敏感报告不跳过人工审阅直接发送
适合在这些场景使用
- 周报、月报等字段相对稳定的内部汇总流程
- 团队想把人工 copy/paste 汇总改成可 review 的草稿工作流
不适合在这些场景使用
- 来源数据每次都完全换结构
- 组织默认要求工作流自己补齐解释
- 没有统一报告模板或明确 owner
真实流程差异
内部报告页如果只写“自动总结”，价值很低。真正的差异在于来源字段、异常标记和审阅责任。
典型输入样例
- 销售周报字段：新线索数、SQL 数、丢单原因、下周重点机会
- 交付周报字段：上线项目数、延期项、阻塞原因、客户风险
- 财务补充：回款异常备注
- 报告模板：管理层只看进展 / 风险 / 需协同事项 3 段
流程前后对比
- 交付前：负责人从多个表格和聊天记录里手工摘录，再拼成周报。
- 交付后：先收集标准字段，再自动生成摘要、缺失项和异常提示，最后人工确认。
- 结果差异：节省汇总时间，但不代替 owner 对关键趋势的最终解释。
脱敏 workflow 示例
- 读取 5 个团队提交的周报表单
- 映射到统一字段：progress / risk / dependency
- 发现 2 个项目缺 owner、1 个项目回款状态冲突
- 生成管理摘要草稿 + 风险清单
- 把冲突字段单独列出等待 owner 确认
测试用例示例
- Case IR-06：两个来源对同一项目的完成率分别写 80% 和 100%。
- 期望结果：不能擅自合并成单一结论，必须标记 conflicting-source。
- 验收重点：系统既要保留冲突证据，也要把报告草稿继续推进到待审状态。
交付判断与边界
内部报告不是“自动写漂亮总结”，而是把固定汇报结构做成可追溯的摘要工作流。
常见失败场景
- 上游字段每周都换，导致标准化映射失效。
- 团队期待系统替他们解释业务原因，而不是先给出异常提示。
- 来源数据时间口径不一致，生成的摘要表面通顺但实际误导。
交付周期判断
- Lite：只有 1 套固定模板、来源字段少且稳定时，可先做 2 到 4 个工作日验证。
- Standard：多个团队按统一模板上报、需要异常标记和审阅门时，通常按 5 到 8 个工作日交付。
- Enterprise：涉及 BI、数据库或跨区域汇总规则时，通常进入 2 到 3 周交付。
适合哪个套餐
- 默认判断：大多数内部报告工作流适合 Standard。
- 只有模板特别固定、来源特别少时，Lite 才有意义。
- 只要牵涉多系统取数、权限控制或高层审计链路，就更接近 Enterprise。
和现有工具的区别
- 和 BI 仪表盘不同：它交付的是“摘要与升级流程”，不是只展示数字。
- 和表格模板不同：不只统一格式，还把缺失、冲突和 owner review 写进流程。
- 和会议纪要助手不同：核心不是转写，而是固定周期报告的结构化交付。
FAQ
常见问题
它能独立写最终管理层结论吗？
它可以准备结构化草稿和异常提示，但关键解释仍应由报告负责人复核。
这一定要接数据仓库吗？
不一定。可以先从人工或半结构化输入开始，但来源字段越稳定，效果越好。