跨产品

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

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

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

能 / 不能速览

✅ 这套平台能做

五个岗位各有一条清晰的工作流：生产语义（Foundry）、消费结论（AIP / Gotham）、保障交付（Apollo）、现场交付与交接（FDE）
角色之间靠对象、指标、报告、期望状态这些"制品"衔接，不用互相等工单
各产品 admin / admin1 独立登录，谁在哪个产品做什么都有权限与审计
决策者只读报告与指标口径，不用碰 SQL 与 YAML

⛔ 这套平台做不了

角色间不能"共享会话 / 工作台"：五个产品各自登录、各自 JWT
数据工程师建的对象不会自动出现在 AIP 里，语义层联动未打通
运维的 Apollo 部署不真实拉起进程（演示 Poller 仅拉取 / 上报）
决策者要的"自动化告警 / 主动推送"属 V2，当前需人工进系统看

适用角色

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

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

能力速览（角色间协作）

制品衔接

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

权限分职

数据工程师管建模、分析师管查询、管理员管审计，各产品 RBAC 隔离；Gotham 图分析接口仅管理员可用。

统一健康

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

审计贯穿

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

调整指南（怎么调整）

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

做得好的场景

角色视角最擅长"让每个岗位只碰自己该碰的层"：

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

限制与不足

以下是明确的边界，使用前先知道：

独立登录：四个产品各自登录（admin / admin1），切换产品要重新登录，用户库不互通。
语义层未打通：Foundry 建的对象 / 指标不会自动同步给 AIP，两套演示数据各自独立。
Apollo 演示局限：Poller 不真实部署进程，跨环境"真分发"需要挂载 ProcManager。
告警缺位：没有主动监控告警（属 V2），异常要靠人主动进 /ops 或各页面发现。

场景故事

故事 1 数据工程师张工的一天：建模、修管道、给 AIP 备地基

场景：数据工程日常角色：数据工程师耗时：上午 9:00 ~ 11:30

背景: 张工周三 9:00 到工位，先在 Foundry 发现昨晚 order 管道跑失败了，接着销售要一个新的 product 对象，下午还约了 IT 对齐 AIP 数据源。他的一天本质是"把数据变成别人能用、AI 能查的语义资产"。

传统做法对比: 以前早上先翻 cron 日志找失败原因，人肉修数据表；新需求要画 ER 图、排接口排期 3~7 天。现在管道失败有质量规则命中明细，建模十几分钟，AIP 数据源注册即用。

角色: 数据工程师（Foundry 建模 / 管道 / 质量 + AIP 数据源管理权限），是价值链"数据"环节的生产者。

操作步骤

Foundry 管道页查看 order 管道失败记录与质量规则命中明细
修正问题后重跑管道，确认状态 succeeded
本体工作台新建 product 对象，映射 product_id / name / price / category
语义检索验证"商品、单价"能命中新对象
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 报告编辑权限）。

操作步骤

AIP /chat 输入"查询本月各区域订单销售额"，看表格与图表
到 Foundry 指标管理核对 total_gmv 的 formula 与 dimensions 是否覆盖"区域"
发现口径疑问时看对象查询结果交叉验证
到 Gotham 报告页，从数据生成一页简报
导出 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 健康页查看权限）。

操作步骤

打开四个产品的 /ops 运维健康页，确认四服务健康卡全部 OK
Apollo 漂移检测对 demo-app 跑 detect，查看 JSON Patch diff
对动态字段配 ignore_paths 后 reconcile 收敛
登记 demo-app v1.1.0 期望状态并激活
发起部署到 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 分钟开完会。

角色: 决策者（只消费结论与报告，不直接操作系统；必要时查看审计日志确认"谁查了什么"）。

操作步骤

看 AIP 查询返回的图表结论，索要对应 SQL 与意图
核对指标口径来自 Foundry 的哪个定义（total_gmv / aov）
看 Gotham 报告的结论与证据链（链路 / 中心度）
确认 Apollo 发布记录与回滚预案
最后过一遍限制综述，明确"哪些不能承诺"

系统响应: 给决策者的是页面与报告，不是 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（唐工，配合拷包与网段）+ 客户业务骨干（林经理，确认口径并接手日常）。

操作步骤

拷包进场，按端口启动五产品并确认各 /ops 健康页 OK
Apollo 登记本地 Git 目录同步目标，隔离网段放 Spoke Agent 出向拉取
Foundry 接入客户数据源、导入元数据、建 customer / order 对象与 total_gmv 指标
Gotham 建源跑 Ingest 与实体解析作业；Swift 部署后看 /license/info 授权自检
培训业务骨干自助查数，整理交接文档后撤场

系统响应

进场部署与定制返回：

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（语义层未打通）；告警推送属 V2，异常靠 /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 现场落地与交接。协作靠制品（对象 / 指标 / 报告 / 期望状态），不靠共享会话；记住边界：独立登录、演示数据不互通、告警缺位属 V2。