每次问 AI 都要从头解释，是你的工作还没有留下“说明书”
很多数据分析师和数据开发已经开始用 AI 写 SQL、查资料、整理分析，但每次提问都要重新解释业务背景、指标口径和项目约束。问题不一定是 AI 记性差，而是你的工作没有沉淀成说明书。本文从普通数据从业者视角，讲怎么把反复解释的内容变成可复用的项目说明、指标说明和判断记录。
方法
技术方法与最佳实践
专题
标签
上线前多重放 1 次历史数据，可能少背 3 次锅
很多数据分析师和数据开发上线指标、SQL、模型或同步任务前，只用几条干净样本测试，结果上线后才被历史边界数据打脸。Stripe 用 Apache Spark 做历史流量回放测试提供了一个启发：普通数据从业者也可以在上线前多重放 1 次真实历史数据，提前发现口径、异常和兼容问题。
Spark 任务跑了 3 小时，别急着问 AI 怎么调参
Spark 任务跑了 3 小时，很多数据开发第一反应是问 AI 要不要改 executor、shuffle、分区数。但慢任务不是靠一句调参解决的。本文结合 Expedia 分析 Spark SQL Plan 的实践，说明普通数据开发为什么要先拿出执行计划、运行指标和业务上下文这 3 份证据。
PRO 让分析报告不再变成一页截图：数据人的结论交付模板
很多数据分析报告最后只剩一页截图：几张图、几行字、一个模糊建议。业务看完不知道该怎么行动，过几天也没人记得结论。本文给一套 Pro 结论交付模板，帮助数据分析师把活动复盘、渠道分析和经营异常报告拆成问题、证据、判断、选项、风险、责任和下一步。
PRO 数据分析师的坏消息表达模板：怎么把问题讲清楚又不背锅
数据分析师经常要汇报坏消息：指标下滑、活动无效、渠道变差、数据异常、老板期待的结论站不住。问题不是能不能说，而是怎么说。本文给一套 Pro 表达模板，帮助数据从业者把坏消息拆成事实、影响、原因、边界、选项和建议，讲清楚问题又不把责任全背到自己身上。
PRO 语义层不是新名词，是 AI 时代的数据说明书
很多数据团队一听语义层，就想到老 BI、指标平台和数据治理文档。但 Power BI、Databricks、MIT 和 Lyft 最近都在重新谈 semantic layer。对数据分析师和数据工程师来说，真正的问题是：怎么从 20 个高频业务问题开始，把指标、维度、权限、质量和拒答规则写成 AI 能调用的数据说明书？
业务改了 3 次口径，真正该问的不是 SQL
数据同学最怕业务反复改口径：今天按下单，明天按支付，后天又要排除退款。很多人第一反应是改 SQL，但真正该问的是业务到底要用这个指标做什么。本文从一次复购指标争议讲起，拆解口径反复背后的 4 个问题，以及一张指标变更卡应该记录什么。
AI 问数 Demo 很顺，为什么一上线就翻车？
AI 问数和 Text-to-SQL Demo 往往很顺：输入一句话，模型生成 SQL，图表立刻出现。但一到真实企业上线，就会遇到权限、口径、表名、脏数据和责任边界。本文从一次上线评审讲起，拆解 AI 问数翻车的 4 个原因，以及上线前必须补的 5 个基础动作。
面试官问项目细节，90% 的人输在证据链
很多数据分析师和数据开发写简历时会写项目背景、技术栈和指标结果，却在面试官追问细节时说不清证据。项目价值不是一句提升效率，而是一条能复原现场的证据链。本文从一次面试追问讲起，拆解数据项目证据链的 5 个环节，帮候选人把普通需求讲成可信项目。
面试官问数据质量，别只背 3 类规则
很多候选人回答数据质量，只会背空值、重复、波动 3 类规则。但面试官真正想听的是：你怎么判断业务真的下滑还是链路出错，怎么定义影响面，怎么把规则放进数据链路，怎么处理业务责任。本文用一个面试现场拆解数据质量问题的 5 层回答方式，适合数据开发和数据分析师准备面试。
48 小时修完数据事故，真正该补的不是告警
一次数据事故从周五晚上拖到周日，团队 48 小时修完任务、补跑数据、恢复看板，但复盘时才发现真正缺的不是告警，而是影响面、修复记录、责任边界和上线验证。本文用 5 个问题拆解数据事故复盘，帮数据开发和数据治理团队避免下次重复摔在同一个地方。
一个指标改了 3 次后，我才明白业务要的不是 SQL
业务一句“帮我看下复购”，数据分析师连续改了 3 次口径：按首购用户算、按下单用户算、按支付用户算，最后才发现问题不在 SQL，而在需求没有被翻译成判断任务。本文用对象、动作、时间窗口和决策用途 4 个问题拆解模糊数据需求，帮你在写 SQL 前少返工、少改口径。
PRO 高质量数据集不是文件夹：企业内部怎么做成可复用供给
企业内部做高质量数据集，不能只是建一个文件夹或上传一批样本。真正可复用的数据集需要设计使用场景、字段说明、版本记录、质量验收、权限边界、调用登记和反馈机制，才能成为 AI 应用、业务分析和数据产品可以反复使用、长期持续维护的稳定数据供给能力。
一个普通数据需求，怎么做成能写进简历的证据链？
很多数据分析师和数据开发不是没有项目，而是把日常需求做完就散了。本文用一个普通取数、报表和口径排查需求，拆解如何从问题背景、业务动作、数据处理、结果影响、复盘材料五个环节沉淀证据链，让普通工作变成简历和面试里讲得清楚、有证据支撑的真实项目。
MAX 企业 AI 数据合规入门：数据人必须懂的四条边界
企业 AI 应用上线前，数据团队不能只说“先接数据试试”。本文从生成式 AI 暂行办法、AI 生成合成内容标识和个人信息保护要求出发，给数据开发、数据治理负责人和 AI 产品经理一套四条数据边界检查法：来源授权、敏感信息、模型使用、输出追溯。
PRO 别把数据治理做成填表：从一次指标口径争议开始
数据治理不是让全公司补字段表，而是从真实业务争议里建立可维护机制。本文用一次转化率和销售额口径冲突，拆解数据分析师、数据开发和业务负责人如何沉淀指标定义、责任分工、变更记录、下游影响和通知流程，把治理做成业务会继续使用、后续能持续维护的方法。
PRO 数据要素项目接不接？一套给数据人的内部判断清单
当公司要求数据团队参与数据要素、数据资产入表、公共数据授权运营或“数据要素×”项目时，数据开发和数据分析师不能只看项目名。本文给出一套可直接用于内部评审的 6 维判断清单、18 个澄清问题、红黄绿灯判断标准和交付物模板，帮助你判断哪些项目值得接，哪些边界必须提前写清楚。
PRO 业务想上 AI 问数，数据开发应该先画哪三张图？
业务部门提出 AI 问数需求时，数据开发不要急着接库和写接口。先画清数据流向图、指标口径图和权限责任图，才能判断这个需求能不能上线、哪里会出错、哪些问题不能交给模型背锅。本文给出三张图的画法、评审问题和上线前检查清单。
MAX 数据从业者的 AI 能力地图：从取数报表到智能应用负责人
AI 时代，数据从业者不能只学提示词、Agent 框架或问数 Demo。真正长期保值的能力，是从指标口径、可信数据供给、AI 工作流、应用评估到权限治理，逐层把自己从取数报表的人，升级为智能应用的业务数据负责人。本文给出能力分层、自测清单和 30 天练习路径。
PRO 领导突然要高质量数据集：这不是标注任务，而是业务资产工程
当领导突然要求建设高质量数据集，数据团队不能只把它理解成标注任务。真正可落地的高质量数据集，需要从业务场景、字段定义、样本边界、质量验收、版本管理和责任分工一起设计，否则很容易变成一个没人敢用的共享文件夹。遇到类似需求时，应该先问什么、留什么证据？
PRO 公司开始提“数据资产”，数据团队第一件事不是盘表
当公司开始提“数据资产”，很多团队第一反应是盘表、填台账和补字段。但对数据开发、数据治理负责人来说，真正重要的是先判断哪些数据能在经营、AI 应用和合规场景中持续产生价值，并把使用者、责任人、质量规则和结果证据说清楚。遇到类似需求时，应该先问什么、留什么证据？