GPT88 / API Docs
ब्लगमा फर्कनुहोस्

FDE 可信取数实践：先定义业务口径，再让 AI 调用 MCP Tool

AI 工作流2026-11-0314 मिनेट पढाइFDE可信取数MCPTool CallingElasticsearch数据分析AI 工程

FDE 可信取数案例文章封面

来源与口径：本文整理自拉布拉卡（@ruixue258）于 2026 年 11 月 2 日发布的 X 帖及 X Article《FDE 第二步：让 AI 自己查数据库，为什么踩完四个坑都落到 MCP + Tool》。该文进一步讨论了 Miles Ma 的 X 帖和 X Article《FDE 实战案例：可信取数（AI 工具选型与四次踩坑复盘）》。下文会区分 Miles Ma 的案例、拉布拉卡对案例的解释及其虚构数据 demo；demo 的数值不是客户实测，也未经本文独立复现。

可信取数不是“查询没有报错”

企业希望 Agent 每天回答一个看似简单的问题：过去 30 天，某款精华在小红书和抖音上的口碑如何？用户主要谈保湿、抗老、肤感还是香味？负面评价集中在哪里？

这类问题要落到可复核的数字，至少需要回答几个具体问题：

  • “某款精华”包含哪些正式名称、别名和简称？
  • “过去 30 天”按帖子发布时间还是数据入库时间计算？
  • 统计原帖、评论，还是两者都包括？
  • “负面”指整篇文本的情绪，还是用户对目标产品本身的评价？
  • 报告是否需要列出原文证据供分析师抽查？

这些条件没有写清楚时，查询可以正常执行，报表也可能出现看起来合理的数字，却回答了另一个问题。可信取数的核心，是把业务口径、数据范围和证据要求变成系统里可见、可检查的条件。

四种可运行的办法，为什么仍会出错

Miles Ma 的案例比较了四类实现路径。拉布拉卡的分析指出，它们的共同问题是：业务问题里未说出口的条件没有明确归属，最后只能由模型、固定模板、网页状态或前端逻辑临时补全。

做法能解决什么常见失真来源
让 AI 直接写 Elasticsearch 查询灵活，能快速回答简单问题一条内容同时谈到多款产品时，整篇情绪可能被错误归到目标产品；别名、时间字段和统计范围也可能猜错
预先准备查询模板查询结构稳定，较容易检查“声量”“负面占比”等词的业务定义可能随问题变化；模板会把未确认的口径固定下来
让 AI 用 Computer Use 操作分析页面可以复用现有系统界面筛选器、页面加载和上一轮状态会影响结果，模型读到的可能不是预期范围
直接调用现有业务 API执行快，能复用已有服务API 可能依赖前端隐式维护的项目、数据源和字段组合；这些上下文没有成为模型明确提供的参数

四种路径各有适用场景，关键不是简单判定哪个工具“更差”，而是检查：会改变结果的业务条件是否显式表达，执行过程能否验证，输出是否携带足够证据。

MCP + Tool：把隐含口径变成显式参数

在案例作者提出的方案里，现有业务 API 仍负责真正的查询与统计；MCP 提供 Agent 发现和调用工具的连接方式，业务 Tool 则定义哪些输入是必需的、如何验证、怎样执行，以及结果应包含什么。

例如，一个口碑查询 Tool 可以要求调用方明确传入：

目标产品：精华A
产品别名：小绿瓶、A精华、绿瓶精华
平台：小红书、抖音
时间范围：2026-10-01 至 2026-10-31
时间字段：帖子发布时间
统计对象：帖子 + 评论
口径：负面评价数 / 有效评价总数
证据要求：返回可抽查的原帖链接与命中片段

这里的重点不是字段名，而是让会影响答案的选择明确可见。若“统计原帖还是评论”没有答案，工具应返回缺少必要参数并让 Agent 追问；不应偷偷选一个默认值，再把数字包装成确定结论。

MCP 本身不会自动提高数据准确性，也不会替业务团队定义“负面”或“声量”。它解决的是工具如何交给模型调用；可信规则仍要由业务、数据和工程共同确定，并落实在 Tool 的参数、权限、测试与结果结构中。

用合成数据展示错误为何隐蔽

拉布拉卡在原文中用脚本生成了一份示例数据：400 条帖子、1,200 条评论，并加入产品别名、补采旧帖和一条内容同时提及两款产品等难例。作者比较朴素查询与带明确规则的 Tool，报告的负面比例分别为 31.6% 和 18.6%。

作者将差异拆成三类：朴素查法遗漏 62 条只出现别名的帖子，把 28 条窗口外但后来补采的旧帖纳入统计，并把 28 条针对另一款产品的差评算到目标产品上。这些数字来自作者构造的虚构样本，只用于说明错误类型；它们不是任何真实品牌的口碑结论，也不代表准确率提升幅度。

原文还展示了“声量”口径的差异：只统计原帖、统计帖子加评论、或按参与者计算，能得到不同的比例。若报告没有说明分子、分母和统计对象，多个数值都可能是各自计算正确，却没有回答同一个问题。

这类 demo 的教学价值在于暴露隐蔽错误：系统不一定报异常。上线前应将这些难例改造成自动化测试，并使用真实业务认可的定义、脱敏数据和人工复核结果来建立验收基准。

让结果能被业务复核

可复核的取数工具至少要把四层信息保留下来：

  1. 业务定义：指标名称对应的计算公式、分母、时间范围和排除规则。
  2. 数据范围：项目、平台、来源、对象别名，以及实际使用的时间字段。
  3. 执行依据：调用参数、工具版本、查询时间、筛选条件和执行状态。
  4. 证据样本：支持摘要或分类判断的原帖、评论或记录标识，便于抽样检查。

遇到目标名称无法识别、数据不完整或没有匹配记录时，也需要区分“没有结果”和“无法确定”。返回零值会被误读为已经验证过的结论；返回候选项、缺失字段或数据更新时间，才便于用户判断下一步。

FDE 在这个流程里做什么

FDE（Forward Deployed Engineer，前线部署工程师）要把客户一句自然语言需求变成能运行、能解释、能验收的工具。这个案例展示的工作不只包括写查询，还涉及：

  • 发现业务口径：把“口碑怎么样”追问成目标对象、平台、时间、统计对象、指标和证据要求；
  • 理解数据结构：选择数据存储与查询方式，确认别名、时间字段及内容关联关系；
  • 设计执行工具：把业务约束做成明确参数和输入校验，而不是依赖提示词提醒；
  • 设定权限范围：限制账号、项目和可执行操作，记录每次调用；
  • 建立评测与交付：用难例检查结果，说明每个数字的口径，提供抽查路径。

因此，FDE 的价值不是单纯把数据库“接给 AI”，而是把客户的模糊问题转成系统能够执行、业务能够确认的契约。模型可以帮助编写代码，但业务术语、默认值和验收标准仍需要人负责确定。

七天练习：从每周手动查数到可复核的小工具

原文给出了一条面向个人练习的路线。它是学习 demo 的计划，不是企业生产上线清单：

日期练习目标当天产物
第 1 天：选问题找一个每周重复出现的查数问题，写清查谁、时间范围、数据来源、计算方式、是否需要证据一页问题定义；不清楚的字段列为待确认项
第 2 天：准备数据用小型公开数据或合成数据，放进 SQLite 或 DuckDB，并故意加入别名、时间边界和多对象记录等难例可重复使用的小数据集
第 3 天：定口径给“声量”“负面”等业务词写下分子、分母、时间字段、纳入与排除规则业务口径表；先不写代码
第 4 天：实现 Tool把口径表变成函数参数；对影响结果的字段要求显式输入，查不到时返回候选，结果回显实际条件可直接测试的本地函数
第 5 天：做难例测试至少整理 20 个案例，覆盖别名、时间范围、一个内容提及多对象、空结果等情况自动化测试集和预期结果
第 6 天：接入 MCP用 MCP SDK 包装本地函数，让常用客户端调用，并测试缺少参数时是否会先追问本地 MCP Tool demo
第 7 天：写交付说明记录工具能回答什么、每个数怎么算、结果怎么抽查、哪些情况无法回答一页使用和验收说明

这条路线把“先写 Prompt”往后放。先理解问题、口径和难例，再编写函数与 MCP 接入，能减少模型调用看似正常、输出却不可解释的风险。

从练习 demo 到生产系统，还差哪些环节

生产环境不能只把练习里的 SQLite 函数换成线上数据库。至少还要补上：

  • 只读账号和最小权限，按项目或租户隔离数据；
  • 输入校验、查询超时、结果条数上限和敏感字段过滤；
  • 调用审计、失败告警、数据新鲜度与版本记录；
  • 业务方签认指标口径，并能追踪规则变更；
  • 持续运行的回归测试、抽样人工复核和异常时的人工接管。

尤其不能把生产库访问权直接交给模型，再期待 Prompt 约束住所有风险。业务 Tool 应限制可执行动作；底层数据库权限也应独立限制 Agent 能够读取的范围。

结语

可信取数的基本顺序是：先问清业务问题，再定义指标和数据范围，然后实现 Tool、连接 MCP，最后用难例与真实证据验证结果。MCP 是连接层，Tool 承载规则，评测证明规则是否符合业务；三者不能互相替代。

对正在学习 FDE 的人来说，最小的练习不是搭一个复杂 Agent，而是挑一个重复查数问题，写出无歧义的口径，让模型调用一个受限函数，并证明输出可以被人复核。

参考来源