跨产品

综合演示：一个业务事件贯穿多系统

"华东销售额下滑"——这个业务事件如何在四款产品间流转：AIP 先发现异动（智能），Foundry 定位口径变化（数据），Gotham 追查客户关系异常（决策），Apollo 部署修复配置（交付）。看完这 4 个故事，你就掌握了"一次业务事件的多系统作战"打法。

业务分析师数据工程师情报分析师运维工程师销售异动共 4 个故事

能 / 不能速览

✅ 这套平台能做

一个业务事件从"发现 → 定位 → 研判 → 修复"四个环节各由一个产品承接
每环节都有真实 API / 页面返回：AIP 的 SQL 与图表、Foundry 的血缘与口径、Gotham 的链路与聚类、Apollo 的部署与 diff
环节之间靠"人"串起来：分析员把结论传给数据工程师，再传给情报与运维
全程留痕：NLQ 审计、Action 写回审计、部署记录都能回溯

⛔ 这套平台做不了

环节之间没有自动编排：AIP 发现异动不会自动触发 Gotham 或 Apollo（无工作流引擎）
跨库数据不能自动关联：AIP 的张三和 Foundry 的张三要人工比对
Apollo 演示 Poller 不真实拉起进程，"修复"是配置层面的收敛不是服务重启
监控 / 告警 / 自动推送属 V2，异动要靠人查出来，不是系统主动报

适用角色

一次异动作战需要四类角色接力：

业务分析师：AIP 查数发现异动，是"发令枪"。
数据工程师：Foundry 血缘 / 口径定位"数字为什么变了"。
情报分析师：Gotham 图谱追查"是不是客户 / 渠道出了问题"。
运维工程师：Apollo 部署新配置，把修复推下去并防漂移。

能力速览（事件作战）

发现（AIP）

一句话查各区域销售额，聚合 + 对比图表 30 秒出数，异动一眼可见，SQL 可核对。

定位（Foundry）

指标血缘四级链路（源 → 管道 → 对象 → 指标 → 报表）+ 版本历史 diff，定位口径变化而非真实下滑。

研判（Gotham）

把下滑区域大客户放进图谱做展开 / 最短路径 / 中心度，找共同联系人、异常渠道，形成证据链。

修复（Apollo）

新配置作为期望状态版本登记、激活、部署，DAG 门控 + 漂移 reconcile + 失败自动回滚。

调整指南（怎么调整）

换口径重查：AIP 换了问法、Foundry 改了指标，记得重新核对结论，别拿旧数字开会。
扩研判深度：Gotham 展开限 3 度 1000 节点，深挖时分批展开；图分析接口仅管理员可用。
修配置迭代：Apollo 每次修复都发新期望状态版本（单调版本号），保留历史可回滚，不要原地改线上。
人肉衔接：环节之间结论靠人传递，建议把"发现 → 定位 → 研判 → 修复"沉淀成团队 SOP 文档。

做得好的场景

综合演示最擅长"把一次跨系统作战讲成有过程、有依据、有闭环的故事"：

每环节可演示：四步都有真实页面与 API 返回，演示时不会冷场。
定位不是猜：AIP 只是"发现数字变"，真正"为什么变"由 Foundry 血缘与口径回答。
决策有证据：Gotham 的链路与中心度让"大客户有问题"可引用，不是拍脑袋。
修复可回退：Apollo 版本化部署，改坏了一键回滚。

限制与不足

以下是明确的边界，演示前先知道：

无自动编排：四个环节靠人接力，没有工作流引擎把事件自动往下推。
跨库不互通：AIP / Foundry / Gotham 三套演示库人名相近但数据独立，跨库比对需人工导数据。
Apollo 不真拉起进程：演示 Poller 只拉取 / 上报，配置收敛不等同服务重启。
demo 数据每次启动重建：异动数字、修复结果重启后还原，适合演练不适合留档。

场景故事

故事 1 发现：王姐在 AIP 查各区域销售额，华东明显下滑

环节：发现角色：业务分析师耗时：约 30 秒

背景: 7 月销售例会前，王姐在 AIP /chat 输入"查询最近一周各区域订单销售额"，本想例行过一遍数字，结果华东的柱子明显比上周矮一截。她意识到这不是常态，异动作战就此打响。

传统做法对比: 以前等周报 Excel 汇总，异动被发现时往往已过两周；想对比上周还要手工 VLOOKUP。现在一句话 + 图表 30 秒出对比，异动当天就能被发现。

角色: 业务分析师（AIP /chat 查询权限）；她把"华东异动"这个事件作为发令枪，依次传给数据、情报、运维。

操作步骤

登录 AIP（18080，admin / admin1）
/chat 输入"查询最近一周各区域订单销售额"
看返回图表，华东数值显著低于华北 / 华南
复制返回的 SQL 与数字，同步给数据工程师张工

系统响应

返回结构示例：

{
  "intent": "aggregate",
  "sql": "SELECT region, SUM(amount) FROM orders WHERE created_at >= date('now','-7 day') GROUP BY region",
  "result": [{"region":"华东","total":8600.0},
             {"region":"华北","total":12900.0},
             {"region":"华南","total":11400.0}],
  "chart_type": "bar"
}

同时写入审计（NLQ_QUERY）。

结果洞察: 华东 8600 vs 华北 12900，异动实锤。但 AIP 只回答"数字变了"，不回答"为什么变"——这正是下一个环节（Foundry 定位）的活。

调整建议: 把查询条件说全（时间范围、区域）减少意图歧义；异动判断可对比"本月 vs 上月"双查询。相关阅读：AIP 复杂分析。

动手试一试: 登录：http://127.0.0.1:18080（admin / admin1）。输入："查询各区域订单销售额"。预期结果：返回各区域聚合数字与 bar 图表，可肉眼对比区域差异。

限制提示: AIP 意图识别是关键词规则，问法太绕可能查偏；一次只查一个数据源；demo 订单日期相对启动时刻生成，重启后"最近一周"范围会变。

故事 2 定位：张工在 Foundry 用血缘 + 版本历史找到口径变化

环节：定位角色：数据工程师耗时：约 15 分钟

背景: 王姐把华东异动发给数据工程师张工。张工不急着信"销售下滑"，先去 Foundry 看 total_gmv 的血缘和 order 对象的版本历史——数字波动很多时候是口径变了，不是业务变了。

传统做法对比: 以前口径变更靠群消息通知，改没改全凭记忆；对不上账就互相甩锅，反复排查大半天。现在血缘图一眼看到指标链路，版本历史里有 change_diff，定位口径变化只要十几分钟。

角色: 数据工程师（Foundry 血缘 / 版本 / 指标管理权限）。

操作步骤

登录 Foundry（18081，admin / admin1）
打开血缘图，查看 total_gmv 的四级链路（源 → 管道 → 对象 → 指标 → 报表）
到指标管理核对 total_gmv 的 formula 与过滤条件
打开版本历史看 order 对象最近一次变更的 change_diff

系统响应: 血缘返回链路节点列表；指标返回 formula（如 SUM(amount) WHERE status='shipped'）；版本历史返回 change_diff 与影响分析（指出受影响指标 total_gmv / aov）。

结果洞察: 真相大白：order 对象最近一次合入把 status 过滤条件从"全部订单"改成了"仅 shipped"，未发货订单被排除，华东"销售下滑"其实是口径变化，不是业务崩了。事件从"发现"进入"定位"。

调整建议: 口径变更必须走版本合入并通知消费方；把影响分析结果同步给分析师，避免拿着旧结论开会。相关阅读：数据血缘、版本治理。

动手试一试: 登录：http://127.0.0.1:18081（admin / admin1）。操作：血缘页选 total_gmv 看链路；版本历史看 order 的变更记录。预期结果：看到四级血缘与带 diff 的版本记录。

限制提示: 血缘是"浓缩版"（四级模型），不是逐字段级全量血缘；跨数据源管道未实现；demo 数据每次启动重建，版本与审计保留在平台库但源表改动还原。

故事 3 研判：苏雯在 Gotham 追查华东大客户背后的渠道与关系

环节：研判角色：情报分析师耗时：约 20 分钟

背景: 口径排查确认数字可信后，真正的业务疑点浮现：华东下滑区域的大客户名单里，有几个名字同时出现在某个异常渠道的名单上。苏雯把这些名字放进 Gotham 玄武集团关系网络，看它们是不是同一伙人、有没有共同联系人。

传统做法对比: 以前名单人肉比对 + Excel VLOOKUP，2000 条关系比对 3 天，链路对不对靠肉眼，报告没人复核。现在导入图谱 2 度展开 + 最短路径 + 中心度，链路清晰可引用。

角色: 情报分析师（图分析接口需 admin 角色）；合规顾问可配合实体解析做跨源归并。

操作步骤

登录 Gotham（18083，admin / admin1）
把华东大客户名单经数据接入导入图谱（CSV / 手工节点）
对关键节点做 2 度展开，看邻居与共同联系人
用最短路径跑"大客户 A → 异常渠道 B"的关联
用中心度排名确认枢纽节点，形成结论

系统响应: 展开返回邻居节点列表并高亮；最短路径返回路径数组；中心度返回排名榜单；实体解析返回聚类（≥0.90 自动合并、0.70~0.90 待审）。

结果洞察: 多名"独立"大客户通过同一联系人节点相连，且该联系人与异常渠道直接关联——"感觉有关"升级为可引用的证据链。诚实提示：Gotham 演示数据是玄武集团网络，与 AIP / Foundry 的客户库不同源，名单导入是手工映射，不自动关联。

调整建议: 图分析接口仅管理员可用，可给情报员开只读图谱权限；跨源归并交给实体解析作业，别手工猜。相关阅读：多源融合、实体解析。

动手试一试: 登录：http://127.0.0.1:18083（admin / admin1）。操作：图工作台对玄武集团展开 2 度；最短路径张远 → 赵敏。预期结果：邻居高亮、路径链路高亮。

限制提示: 图存储单机（内存邻接表 + JSON 落盘）、展开限 3 度 1000 节点；实体解析 AI 增强默认关闭仅相似度算法；跨产品数据不互通，需人工导入。

故事 4 修复：陈工用 Apollo 部署新配置，收敛整条链路

环节：修复角色：运维工程师耗时：约 15 分钟

背景: 事件闭环的最后一环：把修复动作推下去。陈工把"修正后的查询路由配置 / 指标过滤配置"登记为 demo-app 的新期望状态版本 v1.1.0，激活、部署到 spoke-01，再防一手漂移，全程留痕可回滚。

传统做法对比: 以前登录服务器手工改配置、重启服务，改错了靠记忆回滚，环境被手改只能靠人肉 diff，一次修复小半天。现在配置走期望状态版本化声明，部署走 DAG 门控，失败自动回滚，收敛有 reconcile。

角色: 运维工程师（Apollo 期望状态登记 / 部署 / 回滚权限）。

操作步骤

登录 Apollo（18082，admin / admin1）
登记 demo-app 新期望状态 v1.1.0（含修复后的配置项）并激活
发起部署到 agent=spoke-01，看 DAG 分批放行（web 依赖 db）
推进组件到 synced，漂移检测确认无 diff
保留 v1.0.0 历史版本作为回滚点

系统响应: 部署返回组件状态与 DAG 分层（db 先 ready → web 放行）；漂移检测返回 JSON Patch diff 列表；收敛后返回"已对齐期望状态"；版本列表新增 v1.1.0（单调版本号递增）。

结果洞察: 修复配置按依赖顺序分发完成、全程留痕、可回滚。至此"发现 → 定位 → 研判 → 修复"四环节闭环。诚实提示：演示 Poller 只拉取 / 上报不真实拉起进程，这是配置层面的收敛；真环境需挂载 ProcManager。

调整建议: 发布前对 bundle 做验签（SM3 清单 + SM2 签名 + 签名者白名单信任锚）；动态字段配 ignore_paths 减少漂移误报。相关阅读：GitOps 入门、bundle 验签。

动手试一试: 登录：http://127.0.0.1:18082（admin / admin1）。操作：发起部署 demo-app 到 spoke-01；漂移检测 detect → reconcile。预期结果：DAG 分批放行、组件推进到 synced、无残留 diff。

限制提示: 演示 Poller 不真实部署进程；"Git 即真相源 + 自动 PR"属 P2；监控 / 告警 / 自愈属 V2——真环境还需要一套告警来"主动发现"下一次异动。

常见问题

四个环节能自动串联吗？

不能。当前没有工作流引擎把事件自动往下推：AIP 发现异动不会自动触发 Gotham 或 Apollo。四步靠人接力，建议把"发现 → 定位 → 研判 → 修复"沉淀成团队 SOP，配合各产品页面手动操作。

为什么华东下滑最后查出来是口径问题？

因为 AIP 只回答"数字变了"，不回答"为什么变"。Foundry 的血缘与版本历史能定位到 order 对象最近合入把 status 过滤改成了"仅 shipped"——数字波动往往是口径或数据问题，先排查再信业务下滑。

三套演示数据为什么不打通？

AIP（aip_demo_warehouse）、Foundry（foundry_demo_warehouse）、Gotham（玄武集团网络）是三套独立演示数据，人名相近但字段不同、互不联通。跨域追查需手工导数据，这是当前最真实的集成边界，也是后续语义层联动的目标。

这个综合演示适合给谁看？

适合给业务决策者和客户做产品演示：一个"华东销售异动"事件，四步走完发现 / 定位 / 研判 / 修复，每步都有真实页面与返回，是五产品协同叙事最直观的开场。

主题小结

一句话：一个业务事件的跨系统作战 = AIP 发现（智能）→ Foundry 定位（数据）→ Gotham 研判（决策）→ Apollo 修复（交付）。四步都能演示、都有依据、都可回退；但记住：无自动编排、跨库不互通、Apollo 演示不真拉起进程、告警属 V2。