将分散信息组织为调查流程
- 问题
- 指标、发布记录、用户反馈与业务文档分散,调查人员需要反复拼接上下文。
- 选择与取舍
- 将信息组织为证据、假设与建议,并保留关联关系;增加结构化维护成本,换取可追溯的判断依据。
- 运用能力
- 问题定义 · 业务流程设计 · 信息架构
OpsPilot · 业务调查Operational Investigation
AI 运营调查与执行系统
把业务调查从证据整理推进到人工审批、任务执行与结果观察,让每一步都有明确的责任边界。

公开演示使用确定性回放数据;受控模型评测用于验证调用过程与流程可靠性,不用于评价模型能力。
我负责业务调查场景的研究归纳、产品定义、核心流程与界面设计,并推进原型和系统验证。
01 · 问题
本案例基于公开社区与案头研究、合成用户画像定义场景,不将其描述为真实企业访谈。复杂业务调查需要一条可追踪的决策链,让团队能够从发现问题推进到判断和行动。
业务调查必须继续回答
02 · 产品定义
Investigation 是承载调查过程的工作对象,证据、假设、审批、任务和结果保存在同一条可追踪链路中。
AI 负责理解、整理证据和提出建议。权限、审批、任务执行和结果记录由确定性流程控制。
03 · 调查流程
以 INV-024 激活转化率异常为例:先检查数据质量与变化范围,再收集业务上下文、形成假设,最后给出可由业务人员判断的行动建议。
检查指标质量、变化周期与受影响人群。
从指标和业务信息中整理可追溯的证据。
提出可能原因,同时保留反向证据和缺失信息。
基于当前调查提出建议,由业务人员判断是否采取行动。
04 · Evidence ≠ Hypothesis
搜索结果不会自动成为事实。系统区分支持判断的证据、限制判断的证据和当前缺失的信息。

移动端是主要受影响分群;表单版本变更与异常时间相邻,相关客服反馈增加。
桌面端同期基本稳定,限制“全站故障”的解释。
当前材料支持调查假设,尚不足以确认根因。
05 · V1 → V2 产品演进
V2 将待处理事项从单个调查中扩展到跨调查的统一工作队列,让行动、审批与任务拥有清晰、连续的处理路径。
V1 · 调查内行动

V2 · 统一工作队列

产品信息结构的变化工作入口从单次调查内的行动,扩展为跨调查的统一工作队列;任务来源、审批与结果仍能回到原调查。
07 · 结果复盘
结果复盘用于记录任务之后的指标变化和数据质量;这些观察不能单独证明某项任务导致了变化。

行动后的指标变化只作为结果观察记录;没有对照实验时,不归因于某一项任务。
08 · 可靠性验证
这里验证的是工作流可靠性:当规则、运行环境或输出解析遇到异常时,系统是否能够按预期继续、重试或停止。
验证审批安全、状态流转和重复执行保护。
验证输出结构、异常处理和运行轨迹。
通过模型运行评测验证模型调用、结构解析与运行状态记录。

09 · 知识处理
已实现文档导入、文件处理、内容分段与版本记录。当前检索使用 Replay 数据集,不代表完整生产级知识检索。

当前检索使用回放数据,不代表完整生产级知识检索。
模型运行信息在独立评测中记录;公开演示中的知识检索仍使用 Replay 数据。
10 · 原型范围与限制
当前页面展示的是可运行的产品原型与受控评测,使用策展演示数据,不代表真实企业数据或生产部署。
共享演示环境 Shared Demo Workspace
从一次激活转化率异常开始:运行调查 → 查看假设 → 创建行动 → 人工审批 → 观察结果OpsPilot 是桌面工作台,建议使用桌面端体验完整 Demo。
正在加载 OpsPilot…
可以继续等待,或在独立窗口打开 OpsPilot。
在新窗口打开 OpsPilot ↗可以在独立窗口继续体验 OpsPilot。
在新窗口打开 OpsPilot ↗重置共享环境