夜雨聆风会议室里最危险的一句话，通常听起来很轻松。
老板看完一个 AI 问数 Demo，转头问数据团队：“这个我们是不是也能做？”
屏幕上还停着演示页面。输入一句“上周销售额为什么下降”，系统很快给出三段分析，顺手画了一张图，还补了几个建议。业务负责人点头，产品经理说体验不错，技术负责人说模型能力已经够了。
这时候，数据团队的人往往最安静。
不是因为他们不懂 AI，也不是因为他们不想推进。恰恰相反，做过数据的人一眼就能看见屏幕背后那堆没有被问出来的问题：这套销售额用哪个口径？退款扣不扣？区域负责人能不能看到全国明细？答案错了谁改？模型引用的是哪张表？如果它把财务口径和经营口径混在一起，谁来解释？
AI 问数的 Demo 很容易让人兴奋。
因为它把过去笨重的报表入口，变成了一个会说话的界面。用户不用找菜单，不用看维度，不用等分析师排期，直接问一句就有答案。
可真正进入生产以后，AI 问数不是“多一个聊天框”。
它会把公司过去没说清楚的指标、权限、链路和责任，全部搬到一个更像人的界面前。过去报表错了，大家还会怀疑是不是自己看错了；AI 一旦用很笃定的语气说出来，很多人会下意识相信。
这才是数据团队不能急着接模型的原因。
不是反对 AI 问数，而是要先把它从“演示能力”拉回“生产责任”。
Demo 里没有真正的组织压力
Demo 环境很温柔。
它通常只连一小批数据，准备几个固定问题，权限提前开好，指标口径也选了最顺手的一套。模型答得不准，现场可以说“后面再调”；图画得不好，可以说“这只是原型”；问题没覆盖，可以说“先看方向”。
生产环境不是这样。
生产环境里，用户不会按你准备好的问题来问。他会问“华东为什么掉了”“这个客户还能不能跟”“这个员工绩效是不是异常”“下个月预算该不该砍”。这些问题背后可能牵涉经营指标、客户隐私、员工信息、财务口径、区域权限和组织责任。
更麻烦的是，业务不会把 AI 的答案当成一段技术输出。
它会被拿去开会、写周报、做预算、调策略、追责任。
所以 AI 问数一旦上线，就不再只是模型效果问题。它变成了组织承诺：公司允许某些人用自然语言询问某些数据，并相信系统给出的答案可以支撑某些判断。
这个承诺很重。
如果数据团队只负责“把模型接上”，其实是在替组织背一个自己没有参与定义的锅。
我见过一些团队，AI 问数项目刚开始很热闹。第一周演示，第二周接库，第三周老板夸体验好。到了第六周，业务开始质疑答案为什么和 BI 不一致；第八周，权限问题冒出来；第十周，大家发现模型答错时没有反馈入口，错题也没人归档。
最后会议纪要里只剩一句话：模型效果还需要优化。
可真相往往不是模型效果。
是生产责任从一开始就没有被画出来。
第一个问题：这个问数系统服务哪个场景
“做 AI 问数”不是一个需求。
它只是一个愿望。
真正的需求必须回到场景：谁在什么时候问什么问题，问完之后要做什么动作。
经营管理层问数，和销售主管问数，不是一回事。经营管理层可能关心公司级指标、预算偏差、区域对比；销售主管可能关心自己区域的线索、客户、拜访和成交。财务 BP 问数，和运营同学问数，也不是一回事。前者更在意口径、对账和审计，后者更在意活动效果、用户分层和实时反馈。
如果场景不清楚，后面的数据范围、权限粒度、指标口径、回答形式都没法定。
很多 AI 问数项目一开始就说“希望什么都能问”。这句话听起来野心很大，实际很危险。什么都能问，往往意味着没有边界；没有边界，就没有验收标准；没有验收标准，最后只能靠感觉判断好不好。
数据团队应该先把需求改写成更具体的句子。
比如：
经营管理层可以查询 20 个核心经营指标的趋势、异常和口径说明； 区域销售主管可以查询本人负责区域的线索、客户和成交情况； 运营同学可以查询活动复盘相关指标，但不能查看客户明细； 新人分析师可以用问数系统理解指标定义和历史口径变更。
这样的描述看起来没那么酷，但它终于能落地。
因为它说清楚了用户、数据、动作和边界。
AI 问数项目的第一步，不是接模型，而是把“想要一个聊天框”改写成“要服务哪些真实工作场景”。
第二个问题：哪些指标可以被默认回答
AI 问数最容易出事故的地方，往往不是最复杂的问题。
而是最简单的指标。
销售额、订单数、活跃用户、转化率、毛利、留存、新客、复购、ROI，这些词每家公司都在用。问题是，它们未必只有一个版本。
销售额到底按下单算，还是按支付算？退款扣不扣？优惠券算不算？跨境订单是否单独处理？预售尾款归哪一天？
活跃用户按登录算，还是按关键行为算？新客按首次注册算，还是首次支付算？毛利按经营口径算，还是财务口径算？
过去人类分析师在场时，可以解释：“这张图按经营口径看，那张表按财务口径看。”有经验的业务也知道，有些数不能直接横比。
AI 问数没有这种默契。
用户问“上月销售额怎么样”，系统必须选择一个口径。如果系统没有默认规则，它就会从某张表里拿一个数，再用很自信的语气讲出来。
这比报表里两个数字不一致更危险。
报表冲突至少会让人停下来对数。对话式答案会让人误以为已经有人判断过。
所以，在接模型前，数据团队要先做一份“可问指标清单”。
这份清单至少包含四类信息：
可以直接回答的指标：有唯一默认口径，有负责人，有稳定数据链路； 必须提示口径的指标：存在多个版本，回答时要说明当前使用哪一版； 暂不支持的指标：数据不稳定、口径未确认、责任人不清； 只能给说明不能给结论的指标：比如涉及绩效、客户风险、财务敏感判断。
这份清单不是为了拖慢项目。
它是为了避免 AI 把一场口径争议伪装成一个确定答案。
第三个问题：权限到底按什么粒度控制
很多人讨论 AI 问数权限，还停在“能不能 select 一张表”。
这远远不够。
AI 问数里的权限，不只是表权限，也不只是字段权限。它还包括问题权限、答案粒度权限和场景权限。
同样一句“哪些客户风险最高”，不同角色看到的答案应该不一样。
公司负责人可以看整体风险分布；区域负责人只能看自己区域；一线销售可能只能看自己负责的客户；某些敏感原因不能直接返回；某些客户名单不能导出；某些结论只能提示“需要人工复核”。
同样一句“本月员工绩效异常有哪些”，在很多公司就不应该被一个通用问数系统直接回答。它涉及员工信息、管理流程和组织风险，不是模型能不能查出来的问题。
AI 问数的危险之处，在于它把复杂查询变得太容易了。
过去一个人想拿到敏感明细，可能要找人、提需求、走审批。现在如果一个自然语言入口没有边界，他只需要换一种问法。
所以数据团队要提前把权限设计成三层。
第一层，角色边界。不同角色能问哪些主题。
第二层，数据粒度。能看汇总、趋势、分组，还是能看明细、名单、字段。
第三层，动作边界。能不能导出、能不能生成建议、能不能触发下游流程。
这三层如果没设计，AI 问数就不是提高效率，而是在给数据泄漏和误用开一扇更好看的门。
第四个问题：答案错了以后怎么追
生产级系统最怕的不是出错。
最怕的是出错以后没人知道为什么错，也没人知道该改哪里。
AI 问数一定会错。
可能是模型理解错了问题，可能是 SQL 生成错了，可能是检索到了旧文档，可能是指标口径说明不完整，可能是数据任务延迟，可能是用户问法本来就含糊。
如果没有追踪机制，所有错误都会被揉成一句话：模型不稳定。
这句话很方便，也很没用。
数据团队要提前设计答案的证据链。
至少要留下几类记录：
用户问了什么； 系统识别成哪个意图； 使用了哪些表、指标、文档或数据产品； 生成了什么 SQL 或检索条件； 返回了哪些来源； 模型版本、提示词版本和数据版本是什么； 用户是否标记答案有问题； 问题最后被归类成哪种错误。
这些记录不是为了监控用户。
它们是为了让系统能迭代。
如果错误来自指标说明，就补指标契约；如果来自权限规则，就改权限矩阵；如果来自问题表达，就补样例问法；如果来自模型生成 SQL，就加测试集和拦截规则。
没有证据链，AI 问数只能越用越像玄学。
有证据链，它才有机会变成一个能被治理的系统。
第五个问题：数据团队在项目里到底负责什么
很多 AI 问数项目，最开始没有角色分工。
业务说要做，产品说做入口，技术说接模型，数据团队说提供数据。听起来大家都有事做，但责任其实很模糊。
数据团队最容易被放到一个尴尬位置：出了结果，功劳归“AI 项目”；出了问题，大家来问“你们数据是不是不准”。
所以数据团队要在项目早期把自己的责任说清楚。
你可以负责数据供给，但不应该独自承担所有业务解释。
你可以负责指标口径整理，但需要业务和财务确认。
你可以负责权限规则建议，但需要管理层和安全合规共同审批。
你可以负责答案质量监控，但不能替所有用户判断业务动作是否正确。
更具体一点，AI 问数项目至少要有四类负责人：
第一，业务场景负责人。确认这个系统服务什么决策。
第二，指标口径负责人。确认核心指标如何定义。
第三，数据链路负责人。保证数据供给稳定、可追溯。
第四，权限与反馈负责人。处理访问边界、错误反馈和升级机制。
如果一个项目没有这些角色，只靠“数据团队先接一下”，后面大概率会变成长期救火。
数据团队不是给模型喂数据的后勤。
更好的位置，是帮组织把 AI 问数从“想法”变成“有边界的生产系统”。
一张上线前检查清单
如果你现在就遇到类似需求，可以先拿下面这张清单开会。
不要一上来讨论模型。
先问这些问题：
首批用户是谁？他们会在哪些工作场景里使用？ 首批支持哪些问题？哪些问题明确不支持？ 核心指标是否有默认口径？是否有负责人确认？ 数据来自哪些表、任务和数据产品？链路是否稳定？ 不同角色能看到什么粒度的答案？ 哪些敏感字段、敏感问题必须拦截？ 答案是否必须带来源、口径和时间范围？ 用户发现答案错误后，如何反馈？谁处理？ 错误如何分类，如何进入下一轮修正？ 系统上线后，谁负责持续维护？
这 10 个问题答不上来，模型评测再漂亮，也不要急着开放给全公司。
这不是保守。
这是负责。
别让会说话的界面替公司乱说话
我并不反对 AI 问数。
相反，我觉得它会成为很多公司数据入口的一次重要变化。
过去很多人不会用 BI，不知道看哪张报表，也不愿意等分析排期。自然语言入口确实能降低使用门槛，让更多业务问题更快被提出。
但入口越方便，底座越要稳。
一个会说话的界面，会放大信任，也会放大错误。它能让正确答案更快到达业务，也能让错误口径更快流进会议室。
所以老板说要上 AI 问数时，数据团队不该简单回答“能”或者“不能”。
更好的回答是：
“可以做。但在接模型前，我们先把首批场景、可问指标、权限边界、答案证据链和责任人确认清楚。”
这句话可能没有 Demo 里那句“未来已来”好听。
但它能让未来少一点烂尾。
如果你想系统补齐数据治理、AI 应用、指标体系和职业成长这些能力，可以继续看数据从业者全栈知识库[1]。AI 问数不是单点工具，它背后是一整套数据供给、口径治理、权限设计和组织协作能力。
我叫石头，在数据行业里摸爬滚打了十几年，见过太多系统从演示顺利走向生产混乱。AI 问数这件事，我更愿意先把底座讲清楚。这里写的，就是这些教训——我觉得值得说出来的那部分。
关于「拾穗数据」
十来年数据行业里摸爬滚打的一点东西——
周刊、长文、观点，把踩过的坑和看到的局一点点写下来。
都在 ss-data.cc，点下方【阅读原文】去看。
想一起聊？扫码加微信，备注「拾穗」拉你进群：
[1]数据从业者全栈知识库https://pro.ss-data.cc
