# 指标口径

很多公司做 AI 问数时，先关心模型会不会写 SQL，却忽略了一个更普通的问题：公司有没有一本能说明指标口径、数据来源、权限边界和适用场景的指标说明书？对数据分析师和 BI 同学来说，AI 最先暴露的往往不是模型能力，而是组织没有把业务语义写下来。

数据同学最怕业务反复改口径：今天按下单，明天按支付，后天又要排除退款。很多人第一反应是改 SQL，但真正该问的是业务到底要用这个指标做什么。本文从一次复购指标争议讲起，拆解口径反复背后的 4 个问题，以及一张指标变更卡应该记录什么。

很多数据分析师和 BI 同学越做报表越忙，老板却仍然在群里问数、要截图、临时拉人解释。问题不一定是报表不够多，而是报表没有回答决策、口径和责任。本文从一次经营会前的临时取数讲起，拆解 3 类低信任报表和 4 个让看板重新被使用的动作。

AI 问数和 Text-to-SQL 正在进入数据团队，但数据分析师、数据开发和 BI 同学真正要担心的，不是模型不会写 SQL，而是它写得太顺、错得太像对。本文从一次指标复盘会讲起，拆开 AI 写 SQL 的 3 类背锅风险、1 段 SQL 对照、10 项上线检查和 20 个高频问题模板。

业务一句“帮我看下复购”，数据分析师连续改了 3 次口径：按首购用户算、按下单用户算、按支付用户算，最后才发现问题不在 SQL，而在需求没有被翻译成判断任务。本文用对象、动作、时间窗口和决策用途 4 个问题拆解模糊数据需求，帮你在写 SQL 前少返工、少改口径。

一个数据团队做了 10 张经营看板，老板却仍然在微信群里反复追问 GMV、复购和渠道转化。问题真的是看板不够多吗？本文从指标入口、业务语境、签字感和责任边界拆开，帮数据分析师判断下一张看板到底该不该做、该先补页面、补共同口径，还是减少一次反复问数和临时 SQL。

数据治理不是让全公司补字段表，而是从真实业务争议里建立可维护机制。本文用一次转化率和销售额口径冲突，拆解数据分析师、数据开发和业务负责人如何沉淀指标定义、责任分工、变更记录、下游影响和通知流程，把治理做成业务会继续使用、后续能持续维护的方法。

数据团队经常抱怨业务反复改指标口径，但很多口径变化不是业务不专业，而是目标、责任、考核和决策动作还没有对齐。本文从一次销售额口径争议讲起，说明数据分析师和数据开发如何把口径变更从临时改 SQL，变成有场景、有确认、有版本、有通知的协作机制。

企业想做 AI 问数时，数据团队最容易被拉去选模型、接数据库和做 Demo。但真正决定成败的，是指标口径、权限边界、数据链路、答案审计和责任机制。本文从一个常见会议场景拆起，说明数据团队在接模型前应该先问哪 5 个问题、留下哪些证据。

很多数据团队的宽表一开始只是为了提效，后来却变成无人敢改的巨表。本文从主题边界、粒度边界和口径边界三个角度，解释数据建模为什么会失控，以及数据开发如何让宽表重新可维护。

业务同事说“帮我看一下用户流失”，数据分析师和数据开发应该马上写 SQL 吗？这篇文章用一个真实工作场景，拆解模糊需求澄清、指标口径、分析边界和交付确认，让数据工作少返工。