让每一次提问都有据可答：我们的数据平台 AI 助手功能预告
这篇不讲代码，讲产品，而且提前说明：这是一篇功能预告。我们正在给数据血缘平台配一个 AI 助手：用自然语言查资产查血缘、AI 诊断血缘结果、定时给数据资产做体检，还能把整套能力接进 Claude Code 和 Cursor。它会带来什么？哪些活它接，哪些活它不接？这篇提前说清。
一、还是先看三个真实痛点
场景 1：数据就在系统里，可你就是问不出来
新同事想确认"哪张表有用户手机号"。答案其实躺在平台里：资产目录有标签，血缘有流向。但他得先懂什么是血缘、会看血缘图、知道去哪个菜单搜。工具是全的，门槛也是真的。"有数据"和"能问出答案"之间，隔着一整条学习曲线。
场景 2：几千条血缘边，对不对全靠专家肉眼
血缘解析跑完，输出几千条边。这些边可信吗？目前最可靠的办法依然是专家逐条核对：打开一条 transform 表达式，看它和目标列对不对得上。核对到第两百条，眼睛就开始重影了。
场景 3：人在 Cursor 里干活，数据在平台里躺着
数据团队的日常早就不在某一个系统里，而是在 Claude Code、Cursor、自研脚本的终端里。想查个上游表，得切出来、开网页、登录、搜索；勤快一点的团队，自己动手把 REST API 包一遍。
三个痛点，一个根源：平台有能力，但能力离提问的人、离干活用的工具都太远。AI 助手要做的，就是把这段距离消掉。
二、功能全景
这是规划中的功能地图：
css
┌────────────────────────────────────────────────────┐
│ Esther AI 助手 · 统一能力层 │
├──────────────┬──────────────┬──────────────────────┤
│ MCP 服务 │ 智能问答 │ 血缘诊断 │
│ Claude Code │ 自然语言查 │ AI 找疑点 │
│ Cursor/脚本 │ 资产/血缘/ │ 人工裁定 │
│ 个人 Token │ 质量·带出处 │ 一键转修复任务 │
├──────────────┴──────────────┼──────────────────────┤
│ 定时体检 │ 模型接入 │
│ 周期报告 · 主动推送 │ 界面配置 · 内网/云端 │
└─────────────────────────────┴──────────────────────┘四块能力共用同一个服务端工具层：资产查询、血缘查询、质量结果查询，在这一层实现一次。平台内置的助手和对外开放的 MCP 服务，消费的是同一份能力；权限校验也在这一层做，内外一条边界。下面逐个展开。
三、MCP 服务：把平台接进 Claude Code
MCP（Model Context Protocol）是 Anthropic 提出的开放协议，Claude Code、Cursor 等 AI 编程工具原生支持。我们把它当成平台的一等接入方式，而不是附加的接口：
- 个人 API Token：在个人设置里生成、吊销。Token 绑定用户身份，权限等同本人角色，你能看什么，通过 Token 就能查什么；越界的资产，连存在性都感知不到；
- 工具清单：查资产、查血缘（上游/下游，支持方向和深度）、查质量结果、查诊断报告、搜术语、触发血缘分析。首批全是只读；
- 全程审计：每次工具调用记录谁、何时、用了哪个工具、参数摘要，成功失败都有账可查。
接上之后是什么体验？你正在终端里写数据管道，顺手问一句"dws_order 的上游有哪些表、amount_cny 这列怎么算出来的"，答案直接出现在对话里，背后是平台里那份带权限校验的真实血缘。不用切网页，不用自己包 API。
四、智能问答：答案必须带出处
平台内置对话入口，用自然语言问系统里的事：
- 回答范围就是系统本身：资产目录、术语表、血缘分析结果、质量检查结果、数据源、任务动态。回答必须基于系统内真实数据，超出范围就明说"系统中未找到相关信息"，不让模型现编；
- 出处可点击：每条回答附数据出处，来自哪个资产、哪次分析、哪次质量检查，点过去就是对应页面。问"'活跃用户'的口径挂在哪一列"，给你的不是一句话，是能跳过去核实的术语和列；
- 权限隔离：只检索提问者有权可见的数据；
- 检索降级明示：向量检索不可用时自动降级为基础检索，界面如实标注，不装。
五、血缘诊断：AI 找疑点，人做裁定
整个助手里技术含量最高的一块，对应场景 2。诊断按五个维度找问题：
- 可疑边：低置信度的血缘边、transform 表达式与目标列对不上；
- 缺失嫌疑：输出列在源里找不到合理来源；
- 悬空引用：引用了血缘图里根本不存在的表或列；
- 解析异常：解析警告、失败语句的归因分析；
- 一致性：同名表在不同分析里血缘结构矛盾。
每个问题产出一条诊断项：位置在哪条边、现象是什么、AI 的判断和理由、置信度、修复建议。可以针对单次分析发起，也可以对一个项目、一个数据源的全部结果批量来；批量时个别语句失败单独标记，不拖垮整份报告。
然后人来裁定：
| 裁定 | 含义 | 后续动作 |
|---|---|---|
| 属实 | 问题存在 | 一键创建修复任务，进入既有任务流，并关联这条诊断项 |
| 误报 | AI 判断错了 | 记录反例，用于持续调优诊断 |
| 待定 | 拿不准 | 留在待核对列表 |
找疑点用的是"单模型双角色"：同一个模型端点跑两个角色，预测角色的提示词宽松，负责把可疑的都捞出来；仲裁角色严格，逐条复核，过不了审的不进报告。客户只需要部署一个模型。悬空引用这类确定性检查不劳模型，代码直接判。
顺带说一句，"AI 校验 AI"这个思路在我们的研发链路上已经跑了一段时间，现在正在把它产品化给客户。
六、定时体检：让问题主动找人
前面的能力都要人来点，体检把方向反过来：管理员配置周期（每周或每日）和范围，到点系统自动对资产和质量做一轮诊断：
- 资产健康度：没有负责人的表、长期没更新的资产、上游表已经从目录里消失的断链血缘；
- 质量异常解读：最近周期内质量检查的失败项和劣化项，AI 做归因和趋势解读，冷冰冰的失败清单变成读得下去的报告；
- 分级报告：发现项按高、中、低分级，每条带证据和建议；报告归档，历史报告可以对比。
体检计划落库存储，服务重启不丢、同一份报告不重复推。问题不再等人巡检，主动上门。
七、模型接入：数据不出内网
私有化客户最关心的一块。模型在系统界面里配置，走 OpenAI 兼容接口，vLLM、Ollama 这类主流推理框架都能直接对接，接内网模型是配置问题，不是开发问题：
- 一个模型就够：问答、诊断、体检用到的角色默认指向同一个对话模型端点。14B 级对话模型量化后，单张 24GB 显存的卡可以跑（社区常见的量化部署经验，具体规格以实测为准）；Embedding 模型占用更小；
- 内网优先：配置云端端点时，界面明确提示"该模型的提供方将收到发送的数据"，需要二次确认；内网地址不提示。产品默认引导内网部署；
- 密钥加密存储：与数据源密码同一套策略，界面不回显明文。
八、几条设计底线
功能之外，有几条从第一天就定下的规则：
- 只读不写：助手只读、只建议。改资产、改数据、触发发布这些写操作仍然由人执行；诊断发现问题可以一键转修复任务，谁接单谁负责；
- 能力同源：内建助手能做的，MCP 都能做；权限在能力层校验一次，不存在"平台里能用、外部工具不能用"的分裂通道；
- 数据留在客户环境：私有化部署下，对话、诊断上下文、报告都不回传厂商。
九、总结：一次认真的功能预告
一句话定位：AI 助手是平台能力的第二入口。目录回答"有什么"，血缘回答"怎么连"，助手回答的是"你问，我答，出处给你"。
自然语言提问 ──→ 能力层（资产/血缘/质量）──→ 带出处的回答
血缘解析结果 ──→ AI 诊断 ──→ 人工裁定 ──→ 修复任务
定时体检 ──→ 分级报告 ──→ 主动推送这篇是预告：助手还在开发打磨，发布节奏以官方消息为准。如果你也被"有数据问不出、血缘靠肉眼、工具两头切"折磨，欢迎点个关注，功能发布后，你会在这里第一时间看到实测和上手文章。也欢迎在评论区聊聊你手上的痛点：是数据问不出来、血缘不敢直接信，还是报表排障靠人肉翻，或者别的什么烦心事。你在日常里最头疼的那件事，可能就是我们接下来要打磨的功能。MCP、智能问答、血缘诊断、定时体检，你最想先用哪一块，也一并说说，你的声音会影响优先级。
▎ Esther 是一个企业级 SQL 数据血缘分析平台：28 种 SQL 方言、27+ 种数据源元数据采集、列级血缘、元数据管理、私有化部署。治理功能要吃的元数据，平台用采集框架一键进货。
▎ 上面那段数据源清单是命令的真实输出，这套采集框架和配套用例都放在资源仓库里了，欢迎上手验一验：GitHub github.com/estherdata2026/esther-official-resources ，国内直达 gitee.com/esther2026/esther-official-resources