业务故事站
跨产品

角色视角：五类角色的一天

同样的平台，不同的人用法完全不同：数据工程师把表变成对象、业务分析师一句话查数、运维把能力分发到各环境、决策者只看结论与边界、FDE 把产品装进客户现场并教会客户自理。看完这 5 个故事，你就知道"我的岗位该从哪里入手"。

数据工程师 业务分析师 运维工程师 决策者 FDE 前沿部署工程师 工作流 共 5 个故事

能 / 不能速览

✅ 这套平台能做
  • 五个岗位各有一条清晰的工作流：生产语义（Foundry）、消费结论（AIP / Gotham）、保障交付（Apollo）、现场交付与交接（FDE）
  • 角色之间靠对象、指标、报告、期望状态这些"制品"衔接，不用互相等工单
  • 各产品 admin / admin1 独立登录，谁在哪个产品做什么都有权限与审计
  • 决策者只读报告与指标口径，不用碰 SQL 与 YAML
⛔ 这套平台做不了
  • 角色间不能"共享会话 / 工作台"：五个产品各自登录、各自 JWT
  • 数据工程师建的对象不会自动出现在 AIP 里，语义层联动未打通
  • 运维的 Apollo 部署不真实拉起进程（演示 Poller 仅拉取 / 上报）
  • 没有覆盖业务指标的主动巡检告警：Apollo 的告警 / 自愈只管部署与配置健康，业务异动仍要人工进系统看
  • AIP 无自助找回密码，忘记密码只能由管理员在用户页重置
  • AIP 自动化节点是基础类型（查询 / 分析 / 条件 / 通知 / 调用），没有审批 / 循环 / 并行等高级节点

适用角色

本主题按岗位切分视角，五个角色分别对应价值链上的生产、消费、交付、决策与现场落地五类工作：

  • 数据工程师：Foundry 建模 / 管道 / 质量 + AIP 数据源，是语义资产的生产者。
  • 业务分析师：AIP 查数 + Foundry 指标口径核对 + Gotham 报告，是结论的消费者。
  • 运维工程师：Apollo 部署 / 漂移 / 回滚 + 各产品 /ops 健康页，是交付的保障者。
  • 决策者：只消费报告与口径，评估投入产出与边界，是价值链的出资人。
  • FDE 前沿部署工程师：把五产品装进客户现场、接入数据定制本体、培训交接后撤场，是"最后一公里"的落地者。

能力速览（角色间协作）

制品衔接

对象 / 指标（Foundry）、NLQ 结论（AIP）、情报报告（Gotham）、期望状态（Apollo）就是角色间传递的"工件"，不用口头对口径。

权限分职

数据工程师管建模、分析师管查询、管理员管审计，各产品 RBAC 隔离；Gotham 图分析接口仅管理员可用。AIP 的权限目录还能从导入的元数据自动派生（表 → 表访问 / 行级过滤，字段 → 字段访问），批量替换只覆盖这三类资源，功能 / 动作权限不受影响。

统一健康

每个产品都有 /ops 运维健康页（四服务健康卡轮询），运维在浏览器里就能看四个后端的存活状态。

审计贯穿

AIP 每次 NLQ 查询落审计（NLQ_QUERY）、Apollo 部署留痕、Foundry Action 写回审计——"谁在何时做了什么"全程可查。

界面操作指引（不写代码怎么用）

下面按「打开哪个页面 → 点哪里 → 填什么 → 看到什么」把五类角色的一天各走一遍，业务用户照做即可。每步末尾的「API 等价」是给工程师对照用的，可以忽略。

1 数据工程师：修管道、建对象、做语义验证 Foundry 控制台（18081）→ 管道构建 / 数据质量 / 本体工作台 / 语义检索
  • 怎么做：登录 Foundry，进「管道构建」（/foundry/pipelines）看失败记录与质量规则命中明细，修好后重跑；到「本体工作台」（/foundry）新建 product 对象、映射 product_id / name / price / category；到「语义检索」（/foundry/search）输入「商品、单价」验证能命中新对象。
  • 会看到：管道状态变 succeeded 并给出步骤耗时；质量规则列出命中行（如 amount 为负）；对象创建返回 version 1；语义检索命中新对象。

API 等价：POST /api/v1/pipelines/:id/run、GET /api/v1/quality/rules、POST /api/v1/ontology/objects、POST /api/v1/ontology/semantic-search

2 数据工程师：把 AIP 侧数据源与元数据备好 AIP 控制台（18080）→ 左侧菜单「数据源管理」（/datasources）
  • 怎么做：登录 AIP，在「数据源管理」确认 aip_demo_warehouse 已注册并点「导入元数据」；如果之前导过，先清理旧列防残留表名误导查询。
  • 会看到：数据源列表显示表 / 字段数量，元数据可用于 NLQ 路由与权限目录派生。

API 等价：GET /api/v1/datasources、POST /api/v1/datasources/:id/import-metadata

3 业务分析师：一句话查数 + 核对口径 + 出简报 AIP「智能查询」→ Foundry「指标管理」→ Gotham「情报报告」
  • 怎么做：在 AIP「智能查询」（/chat）输入「查询本月各区域订单销售额」看表格与图表；到 Foundry「指标管理」（/foundry/metrics）核对 total_gmv 的 formula 与 dimensions；有疑问到 Foundry「对象查询」（/foundry/query）交叉验证；最后到 Gotham「情报报告」（/gotham/reports）从数据生成一页简报并导出 HTML。
  • 会看到：聚合表格 + 图表推荐；指标定义可查；报告文件可下载（HTML / PDF / DOCX）。

API 等价：POST /api/v1/chat、GET /api/v1/metrics、GET /api/v1/reports/:id/html

4 运维工程师：看健康、治漂移、发版本 「运维状态」（/ops）→ Apollo「部署与漂移」
  • 怎么做：点顶部导航「运维状态」（/ops）看五张服务健康卡；到 Apollo「部署与漂移」（/apollo/deployments）用「漂移检测」表单跑一次 detect 看 JSON Patch diff；把动态字段配进 ignore_paths；到漂移事件列表点「收敛」（reconcile）；再点「发起部署」登记 demo-app v1.1.0 并用「推进」推到 synced。
  • 会看到：健康卡正常；diff 精确指向被改字段；收敛后部署回到 synced；DAG 分批放行（db → web）。

API 等价：GET /health、POST /api/v1/drift/check、POST /api/v1/drift/:id/reconcile、POST /api/v1/deployments/start

5 决策者：只看结论、口径与边界 AIP 图表 → Foundry「指标管理」→ Gotham「情报报告」→「运维状态」授权信息卡
  • 怎么做：让团队把 AIP 查询的图表与 SQL 拉出来；核对口径来自 Foundry 哪个指标定义；看 Gotham 报告的证据链（路径 / 中心度）；到「运维状态」（/ops）看授权信息与有效期；最后过一遍「限制综述」明确不能承诺的边界。
  • 会看到：图表 + SQL、指标定义、报告证据链、授权状态与有效期——都是页面与报告，决策者无需登录碰接口。

API 等价：GET /api/v1/metrics、GET /api/v1/license/info

6 权限分职与审计贯穿：谁在哪个产品做了什么 Apollo「平台管理」组；AIP 顶部「管理后台 ▾」
  • 怎么做：管理员在 Apollo 左下「平台管理」组进「用户管理」（/apollo/admin/users）与「角色管理」（/apollo/admin/roles）配权限，在「审计日志」（/apollo/admin/audit-logs）看部署与回滚留痕；AIP 侧点顶部「管理后台 ▾」进「用户管理」（/admin/users）、「角色与权限」（/admin/roles）与「审计日志」（/admin/audit），核对 NLQ 查询与 Foundry Action 写回记录。
  • 会看到：各产品角色 / 权限独立配置；审计日志可按用户 / 事件过滤，「谁在何时做了什么」全程可查。

API 等价：GET /api/v1/audit/logs

提示：五个产品各自登录、独立 JWT，admin / admin1 只是各自默认账号，用户库不互通；角色之间靠"制品"（对象、指标、报告、期望状态）衔接，而不是共享会话。以上是五条真实角色工作流，单看某一步也可独立演示。

调整指南（怎么调整）

  • 数据工程师：管道失败先看质量规则命中明细，再重跑；建模前先语义检索看看有没有现成对象，避免重复造。
  • 业务分析师：重要数字先到 Foundry 指标管理核对口径，再到 AIP 复问一遍；问不出就换直白关键词。
  • 运维工程师：漂移检测记得配 ignore_paths 忽略动态字段；发布窗口期用部署策略里的 auto_rollback 兜底。
  • 决策者：要数字先问"口径来自哪个指标定义"；要结论先问"这个结论在哪个产品、谁查的、SQL 是什么"。
  • FDE 前沿部署工程师：进场先规划端口与网段；数据接入前先清理旧元数据；交接前把"哪些不能承诺"写进文档，撤场靠制品不靠人。

做得好的场景

角色视角最擅长"让每个岗位只碰自己该碰的层"：
  • 分工不抢戏：分析师不写 SQL、运维不写业务代码、决策者不碰 YAML，各层职责清晰。
  • 衔接靠制品：对象、指标、报告、期望状态都是落地的产物，角色间交接有据可查。
  • 认知门槛低：业务人员 10 分钟学会查数，运维 15 分钟学会部署，不用学整套平台。

限制与不足

以下是明确的边界，使用前先知道：
  • 独立登录：五个产品各自登录（admin / admin1），切换产品要重新登录，用户库不互通。
  • 语义层未打通：Foundry 建的对象 / 指标不会自动同步给 AIP，两套演示数据各自独立。
  • Apollo 演示局限：Poller 不真实部署进程，跨环境"真分发"需要挂载 ProcManager；页面请求固定作用于项目 1（PROJECT_ID 硬编码），多项目切换未实现，多数列表也没有服务端分页。
  • 告警只覆盖部署侧：Apollo 有告警汇总 / 自愈 / 通知渠道，但只管部署与配置健康；没有覆盖业务指标的主动巡检告警，业务异常要靠人主动进 /ops 或各页面发现。
  • AIP 无自助找回密码：忘记密码只能由管理员在用户页重置，系统不提供邮件 / 短信找回链路。

场景故事

故事 1 数据工程师张工的一天：建模、修管道、给 AIP 备地基
场景：数据工程日常 角色：数据工程师 耗时：上午 9:00 ~ 11:30
背景
张工周三 9:00 到工位，先在 Foundry 发现昨晚 order 管道跑失败了，接着销售要一个新的 product 对象，下午还约了 IT 对齐 AIP 数据源。他的一天本质是"把数据变成别人能用、AI 能查的语义资产"。
传统做法对比
以前早上先翻 cron 日志找失败原因，人肉修数据表；新需求要画 ER 图、排接口排期 3~7 天。现在管道失败有质量规则命中明细，建模十几分钟，AIP 数据源注册即用。
角色
数据工程师（Foundry 建模 / 管道 / 质量 + AIP 数据源管理权限），是价值链"数据"环节的生产者。
操作步骤
  1. Foundry 管道页查看 order 管道失败记录与质量规则命中明细
  2. 修正问题后重跑管道，确认状态 succeeded
  3. 本体工作台新建 product 对象，映射 product_id / name / price / category
  4. 语义检索验证"商品、单价"能命中新对象
  5. AIP 数据源页确认 aip_demo_warehouse 已注册并导入元数据
系统响应
管道返回运行状态（succeeded）与步骤耗时；质量规则返回命中行明细（如 amount 为负）；product 对象创建返回 version 1；AIP /datasources 返回数据源列表与表结构数量。
结果洞察
上午 10:40，管道恢复、product 对象上线、AIP 地基就绪。重点是：他造的所有"工件"（对象、指标、元数据）都会被分析师、NLQ 甚至情报分析复用——一次建模，处处受益。
调整建议
给属性加同义词提升语义检索命中；给敏感字段打 PII 标记；导入 AIP 元数据前先按 table_schema_id 清理旧列，防残留误导。相关阅读：Foundry 管道、数据质量、AIP 数据源接入。
动手试一试
登录：Foundry http://127.0.0.1:18081（admin / admin1）。操作：管道页重跑 order 管道；本体工作台新建 product 对象。预期结果：管道 succeeded、product 对象 version 1 可在对象查询里取数。
限制提示
跨数据源管道未实现（单数据源 SQL 步骤）；质量规则是 SQL 校验不拦外部脏数据；Foundry 建的对象不会自动同步给 AIP——两个产品语义层当前未打通。
故事 2 业务分析师王姐的一天：一句话查数、核对口径、出报告
场景：分析日常 角色：业务分析师 耗时：上午 9:30 ~ 10:10
背景
王姐周四 9:30 被销售总监问"本月华东 vs 华北哪个好"。她不用写 SQL：先到 AIP 用一句话查数，再到 Foundry 指标管理核对口径，最后把结论用 Gotham 报告模板出一页简报发给领导——这是价值链"智能 + 决策"环节的典型消费者。
传统做法对比
以前提工单等 1~2 天，拿回来还要怀疑口径对不对；自己写 SQL 又容易把 GROUP BY 写错，一份对比报表折腾半天。现在一句话 30 秒出数，口径有指标定义可查，报告模板一键导出。
角色
业务分析师（AIP /chat 查询 + Foundry 指标只读 + Gotham 报告编辑权限）。
操作步骤
  1. AIP /chat 输入"查询本月各区域订单销售额"，看表格与图表
  2. 到 Foundry 指标管理核对 total_gmv 的 formula 与 dimensions 是否覆盖"区域"
  3. 发现口径疑问时看对象查询结果交叉验证
  4. 到 Gotham 报告页，从数据生成一页简报
  5. 导出 HTML 发给总监
系统响应
AIP 返回 intent / confidence / sql / result / chart_type；Foundry 指标返回 metric 定义（formula、dimensions）；Gotham 报告返回简报内容与导出格式（HTML / PDF / DOCX）。
结果洞察
10:05 结论出炉：数字口径可解释、有 SQL 可核对、报告可交付。诚实提示：AIP 与 Foundry 是两套演示库，跨库对不上时要用各自库的关键词分别查，不能指望一次查询横跨两库。
调整建议
常用问题沉淀成团队模板，让同事直接复用；口径争议到指标管理查定义，不要口头对。相关阅读：AIP 复杂分析、指标语义层、Gotham 报告。
动手试一试
登录：AIP http://127.0.0.1:18080（admin / admin1）。输入："查询各区域订单销售额"。预期结果：返回聚合表格 + 图表推荐；再到 Gotham 报告页从数据生成一页简报。
限制提示
AIP 意图识别是关键词规则，复杂问法命中率不稳；AIP 一次只查一个数据源；Gotham 报告 PDF 导出无中文字体时退化为 ASCII，正式排版能力有限。
故事 3 运维陈工的一天：看健康、治漂移、发版本
场景：运维日常 角色：运维工程师 耗时：上午 10:30 ~ 12:00
背景
陈工周五值班。早上先在四个产品的 /ops 健康页看服务是否存活，接着发现演示环境的配置被同事手改产生了漂移，中午还要把 demo-app 升到 v1.1.0。他的工作围绕"交付"环节：状态一致、可回滚、全程留痕。
传统做法对比
以前逐个 SSH 登录看进程、人肉 diff 配置文件，凌晨发布心惊胆战，回滚靠记忆。现在 /ops 一页看健康、漂移检测自动 diff、reconcile 收敛，发布走 DAG + 自动回滚，出了问题一键退。
角色
运维工程师（Apollo 部署 / 漂移 / 回滚 + 各产品 /ops 健康页查看权限）。
操作步骤
  1. 打开四个产品的 /ops 运维健康页，确认四服务健康卡全部 OK
  2. Apollo 漂移检测对 demo-app 跑 detect，查看 JSON Patch diff
  3. 对动态字段配 ignore_paths 后 reconcile 收敛
  4. 登记 demo-app v1.1.0 期望状态并激活
  5. 发起部署到 spoke-01，看 DAG 分批放行并推进到 synced
系统响应
/ops 返回各服务状态与轮询结果（健康卡每秒刷新）；漂移检测返回 patch 列表（如 port 8081 → 8080）；reconcile 返回"已收敛"；部署返回组件状态与 DAG 分层推进。
结果洞察
上午处理完漂移、中午部署完成，全程留痕、可回滚。关键认知：Apollo 是"控制面"，演示 Poller 只拉取 / 上报，真要拉起进程需要挂载 ProcManager——演示环境讲清楚这一点就不会被误导。
调整建议
漂移忽略规则优先配 ignore_paths 而非直接改期望状态；发布前做 bundle 验签演练。相关阅读：漂移检测、DAG 部署、回滚与部署锁。
动手试一试
登录：Apollo http://127.0.0.1:18082（admin / admin1）。操作：漂移检测对 demo-app detect → reconcile；发起部署到 spoke-01。预期结果：diff 展示 → 收敛闭环 → 组件推进到 synced。
限制提示
/ops 只轮询健康状态，不做告警推送（监控 / 告警属 V2）；演示 Poller 不真实部署进程；"Git 即真相源 + 自动 PR"属 P2。
故事 4 决策者李总的视角：不看操作，只看结论、口径与边界
场景：管理视角 角色：业务决策者 耗时：例会 30 分钟
背景
李总是分管销售的 VP，他在周一例会上听三份汇报：AIP 查出的区域销售结论、Gotham 产出的大客户关系研判、Apollo 的版本发布记录。他不碰 SQL、不碰 YAML，只关心三件事：数字口径一致吗、结论可信吗、边界在哪。
传统做法对比
以前各部门 PPT 各讲各的，同一指标三个数，会上吵 40 分钟对不上账；审计"谁查的、SQL 是什么"要翻聊天记录。现在口径有指标定义、结论有报告与审计、边界有明确文档，30 分钟开完会。
角色
决策者（只消费结论与报告，不直接操作系统；必要时查看审计日志确认"谁查了什么"）。
操作步骤
  1. 看 AIP 查询返回的图表结论，索要对应 SQL 与意图
  2. 核对指标口径来自 Foundry 的哪个定义（total_gmv / aov）
  3. 看 Gotham 报告的结论与证据链（链路 / 中心度）
  4. 确认 Apollo 发布记录与回滚预案
  5. 最后过一遍 限制综述，明确"哪些不能承诺"
系统响应
给决策者的是页面与报告，不是 API：AIP 图表 + SQL、Foundry 指标定义、Gotham 简报、Apollo 发布历史；审计日志可以按用户 / 事件过滤，"谁在何时查了什么"一查便知。
结果洞察
价值链的价值对决策者是"口径一致 + 结论可追溯 + 边界明确"。投入产出比：单机可演示、数小时上手，对标 Palantir 数月部署、数百万美元起步，试点验证足够快、足够省。
调整建议
要数字先问"口径来自哪个指标"；要结论先问"哪个产品、谁查的、SQL 是什么"；要承诺先读限制综述。部署决策看 迁移指南 评估上线路径。
动手试一试
不操作也能看：让团队跑一次 综合演示，你只负责提问与看结果；再打开任一产品的 /ops 健康页看服务状态。30 分钟即可建立全貌。
限制提示
各产品独立登录、用户库不互通；演示数据重启重建，演示结论不能当生产结论；AI 结论（NLQ / 实体解析）需人工核对；Swift 为仿真域 PoC（模拟数据非真实在轨），不能进入任何真实投产承诺。
故事 5 FDE 阿凯的一天：进场部署、定制本体、培训交接
场景：现场交付 角色：FDE 前沿部署工程师 耗时：交付周期一周
背景
阿凯是 FDE 前沿部署工程师，周一进场：先在隔离内网把五产品装好（AIP=18080 / Foundry=18081 / Apollo=18082 / Gotham=18083 / Swift=18084），再把客户的 Excel 与旧库接进 Foundry 建成本体，周四跑通 Gotham 实体解析与 Swift 授权自检，周五把查数 / 报表 / 权限交给业务骨干并整理交接文档。他的工作围绕"最后一公里"：产品落地、数据语义化、客户自理。
传统做法对比
对标 Palantir 的 FDE 常驻客户现场 6~12 个月，靠重人工定制撑起交付；本项目轻交付：一套 YAML + GitOps 一周装完五产品、两天数据接入建本体、两周培训，撤场后客户自运转——驻场半年压缩到一周交付。
角色
FDE 前沿部署工程师（进场部署 / 数据接入 / 本体定制 / 培训交接）+ 客户现场 IT（唐工，配合拷包与网段）+ 客户业务骨干（林经理，确认口径并接手日常）。
操作步骤
  1. 拷包进场，按端口启动五产品并确认各 /ops 健康页 OK
  2. Apollo 登记本地 Git 目录同步目标，隔离网段放 Spoke Agent 出向拉取
  3. Foundry 接入客户数据源、导入元数据、建 customer / order 对象与 total_gmv 指标
  4. Gotham 建源跑 Ingest 与实体解析作业；Swift 部署后看 /license/info 授权自检
  5. 培训业务骨干自助查数，整理交接文档后撤场
系统响应
进场部署与定制返回：
GET /api/v1/agent/pull?agent=prod-zone3-node01
{ "desired_state": { "app": "demo-app", "version": "1.0.0" },
  "bundle_digest": "sm3:...", "has_update": true }

GET /api/v1/license/info
{ "authorized": false, "shutdown_scheduled": true,
  "shutdown_tier": "hard",
  "shutdown_deadline": 1760000000 }
指标查询返回 total_gmv=6470.5；实体解析 stats 返回 matched_pairs ≥1。
结果洞察
五产品一周装进隔离内网、客户数据两天变成平台对象、授权到期能优雅关停——FDE 交付的全部"工件"（期望状态、本体 YAML、指标口径、交接文档）都是落地产物，撤场后客户靠制品自运转，不依赖个人。轻交付的本质是"产品驱动增长"，而不是"人肉驻场"。
调整建议
进场先做端口与网段规划；导入元数据前先清理旧列防残留；漂移忽略规则配 ignore_paths；交接文档写清"哪些不能承诺"。相关阅读：FDE 交付全流程、Spoke Agent、本体建模。
动手试一试
登录：各产品 http://127.0.0.1:18080~18084（admin / admin1）。操作：Apollo 登记一个本地 Git 同步目标并激活；Foundry 建一个对象；Swift 打开 /license/info 看授权自检。预期结果：期望状态 active、对象 version 1、/license/info 展示 shutdown_scheduled 与倒计时。
限制提示
Git 仓库为本地目录模拟；演示 Poller 不真实部署进程；Foundry 对象不会自动同步到 AIP（语义层未打通）；Apollo 告警只管部署侧，业务异常靠 /ops 与各页面主动巡检发现。

常见问题

我该从哪个产品开始？

按岗位定：数据工程师从 Foundry（建模 / 管道）与 AIP 数据源入手；业务分析师从 AIP /chat 入手；运维从 Apollo 与各产品 /ops 入手；决策者从 价值链闭环 与 限制综述 入手。

五个角色能共享同一个会话吗？

不能。各产品独立登录、独立 JWT、用户库不互通。角色间传递的是"制品"——对象定义、指标口径、报告、期望状态——而不是共享会话。

为什么说 Foundry 建的对象不会自动到 AIP？

因为当前两套演示数据各自独立（foundry_demo_warehouse 与 aip_demo_warehouse），语义层联动（Foundry 对象 / 指标 → AIP OAG）是设计契约（SemanticSearch / Action 执行）但尚未落地打通。数据工程师需要分别准备两边的元数据。

决策者需要会 SQL 吗？

不需要。决策者只消费 AIP 图表、Gotham 报告与指标定义；甚至不需要登录系统，让分析师跑好再汇报即可。需要"查证"时再让团队把 SQL 与审计记录拉出来。

主题小结

一句话：同一个平台，五类角色各取所需——数据工程师生产语义、分析师消费结论、运维保障交付、决策者评估边界、FDE 现场落地与交接。协作靠制品（对象 / 指标 / 报告 / 期望状态），不靠共享会话；记住边界：独立登录、演示数据不互通、AIP 无自助找回密码、Apollo 告警只覆盖部署侧、页面固定作用于项目 1。