没有成熟 BI，我用 AI 做了一个“问数 MCP”

🚀 欢迎来到AI产品经理研习之旅 🚀

阅读约 8–10 分钟

过去2天，我用 Codex（现在应该叫ChatGPT哈哈） 和 Supabase 做了一件不算大、但很有意思的事：做了一个可以用自然语言问公司数据的 MCP。

Supabase 是一套带数据库和云端运行能力的服务；MCP 可以先理解为 AI 连接外部系统的一种标准方式。

“能不能帮我把符合这些条件的客户找出来，再看看他们过去的消费情况？”

如果公司已经有成熟的 BI（商业智能）平台，这可能只是一项普通分析。

但我们的数据基础还比较薄弱，没有专业 BI，老业务系统也很难根据临时需求灵活定制。于是我开始想：与其每次都帮业务捞一遍数据，能不能让 AI 在受控范围内自己理解问题、查询数据、解释结果？

01 / 为什么要做一个问数 MCP

业务问题很少一成不变。

这次按时间筛，下次可能增加渠道；这次只看人数，下次又想看消费；刚导出一版，业务又发现“有效客户”的定义需要调整。

人工捞数很容易进入一个循环：

图1：条件一变，人工捞数就很容易从头再来

我没有把 MCP 当成 BI 的替代品。它更像一种阶段性能力：当问题真实存在、条件不断变化，又暂时不值得为每个问题开发报表时，先补一条灵活的问数路径。

02 / 什么是问数 MCP

如果把公司数据比作一个仓库，那么问数 MCP 就是 AI 必须经过的服务窗口。

AI 不能直接进入仓库随便翻。它只能先查看允许使用的数据，再了解字段含义，最后提交一条受限制的只读查询。

图2：MCP 位于 AI 与数据库之间，负责目录、门禁和执行规则

不是让 AI 直接进入数据库，而是在 AI 和数据库之间加一扇有目录、有门禁、有规则、有记录的窗口。

03 / 我和 Codex 是怎么做的

这个项目不是从“我要开发一个 MCP”开始的，而是从一个真实业务问题逐步收敛。

真实业务问题   → 重构产品目标   → 确定数据与权限边界   → Codex 协助实现   → 测试成功与拒绝路径   → 记录未完成项

最初的交付目标只是一份查询结果。继续追问后，它被重构为一条可重复使用的问数路径。

第一版也没有开放整个数据库，只选择少量已经验证、确实能支撑试点问题的数据。

Codex 参与了需求整理、方案比较、权限设计、代码实现、测试和文档检查。但哪些数据能开放、业务口径如何定义、风险是否可接受，仍然由人决定。

当前项目已经完成内部技术验证，可以进入小范围受控试点；真实业务用户验收和长期运营仍需继续完成。技术跑通，不等于业务上线。

04 / 一次问数是怎样流转的

为了让 Agent 不凭记忆猜数据，我们把问数过程拆成三个最小能力。

一个完整请求大致这样流转：

业务问题   → 查看可用数据   → 了解字段与质量   → 生成需求理解卡   → 用户确认   → 执行只读查询   → 返回结果与证据

前三步解决“AI 是否理解了数据”，理解卡解决“AI 是否理解了业务问题”，最后的查询和证据解决“实际执行了什么”。

真正让这个流程稳定下来的，是下面三项设计：MCP 的工程结构、问数 Skill，以及需求理解卡。

05 / 一个能用的 MCP，实际包含什么

如果只是让 AI 执行一条查询，代码可能并不复杂。

但一旦准备交给业务用户，问题会迅速变多：谁能用？能看什么？查询太大怎么办？离职后如何取消访问？升级后怎样证明原有边界没有失效？

下面是经过重新命名和简化后的项目目录：

business-data-mcp/├─ supabase/functions/│  ├─ data-query-mcp/          # MCP 服务入口│  └─ _shared/│     ├─ catalog               # 开放哪些数据│     ├─ auth                  # 谁可以使用│     ├─ sql-guard             # 哪些查询可以执行│     ├─ limits                # 查询多少、查询多久│     └─ logging               # 留下脱敏证据│├─ skills/business-data-query/ # AI 的问数工作方法├─ tests/                      # 权限、安全和查询测试├─ docs/                       # 用户指南、验证和运维└─ config/                     # 客户端配置示例

目录里的每一部分，都对应一个产品问题。

这里最容易被低估的是：防线不能只有一层。

图3：底层权限、执行规则与人机工作流共同构成三层约束

三层不是重复建设。

数据库权限负责“底线”，MCP 负责“执行过程”，Skill 负责“AI 的工作方式”。即使 AI 没有遵循 Skill，它也不能越过 MCP 和数据库权限；即使查询在技术上允许，Skill 仍然要求先让业务人员确认口径。

06 / 为什么有了 MCP，还需要问数 Skill

MCP 解决“AI 能安全地做什么”，Skill 解决“AI 应该怎样完成一次问数”。

Skill 可以理解为给 AI 的标准作业流程。下面是经过通用化处理的核心提示词：

收到新的业务问题后：
1. 查看当前开放的数据源和字段说明；2. 判断用户需要汇总、少量样本还是详细数据；3. 展示“查询理解卡”；4. 等待用户确认或纠正业务口径；5. 确认后执行受控只读查询；6. 返回结果，并说明数据来源、条件和风险。

Skill 不能替代 MCP。

如果只在提示词里写“不要访问敏感数据”，AI 仍然在技术上拥有访问能力；真正的权限必须由 MCP 和数据库强制执行。

同样，MCP 也不能替代 Skill。系统可以保证查询合法，却无法保证 AI 每次都先向用户解释“我准备查什么”。

查询结束后，Skill 还要求返回一份业务人员看得懂的执行说明：

查询结果- 关键结论：……- 指标与数值：……
实际查询说明- 使用了哪些数据：……- 实际筛选和时间范围：……- 返回的是汇总、样本还是明细：……- 结果是否被截断：……- 仍需业务判断的风险：……

这让一次问数形成闭环：查询前确认意图，查询后说明事实。

07 / 为什么一定要有“需求理解卡”

需求理解卡是整套设计里，我认为最值得保留的部分。

自然语言问数最危险的情况，未必是 AI 写出一条报错的 SQL。更危险的是：AI 把问题理解错了，却给出了一个看起来很合理的答案。

“帮我看看近期消费过的客户，以及他们的消费金额。”

这句话里至少藏着六个口径。

如果 AI 自己选择一组定义，它完全可能生成语法正确的查询，却回答了另一个问题。

所以在查询之前，AI 先展示【查询理解卡】：

业务问题：查找近期有消费记录的客户，并统计消费金额。
需要确认：- “近期”具体指多长时间？- 客户范围是否有限定？- 金额使用哪一种业务口径？- 同一客户是否需要去重？- 只返回汇总，还是需要详细数据？- 是否需要返回姓名、电话等敏感信息？
请确认或修改以上口径，确认后再执行查询。

业务人员不需要阅读 SQL，也能发现 AI 是否理解错了。

例如，用户可能这样确认：

确认后的查询口径
- 时间范围：最近三个月- 客户范围：所有已完成交易的客户- 金额口径：实收金额- 去重方式：按客户去重- 输出粒度：只返回汇总，不要客户名单- 敏感信息：不返回姓名和联系方式

图4：把误解拦在执行之前，而不是等错误答案出现后再返工

当数据源、时间范围、指标定义、结果粒度或敏感字段发生明显变化时，理解卡也应该重新确认，而不是沿用上一次的假设。

这项设计把“AI 理解错了”从结果阶段提前到了执行阶段。对业务问数来说，这可能比换一个更强的模型更有价值。

08 / 它的价值，以及接下来做什么

这个项目的价值，不只是“更快查出一个数字”。

问数过程中，原本藏在少数人经验里的问题会不断暴露：同一个概念为什么有多个字段？哪个来源更可信？历史数据从什么时候开始完整？两个金额为什么对不上？

这些问题不是 MCP 制造的。MCP 只是让它们更早、更清楚地出现。

接下来，我准备同步推进两条路线。

图5：一条路线拓宽数据范围，一条路线提高理解精度

第一条路线是继续补齐数据表和历史数据，再围绕更多真实问题进行查询、安全和业务验证。

第二条路线是同步整理数据字典和指标口径。数据字典告诉 AI 字段是什么、来自哪里、有哪些质量问题；指标口径告诉 AI 一个数应该怎么算、由谁最终解释。

👉 点赞+在看+分享，让我们一起探索更多AI前沿技术和产品实践 🌟

也欢迎你在留言区与我互动。