Posts

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

AI 问数和 Text-to-SQL Demo 往往很顺：输入一句话，模型生成 SQL，图表立刻出现。但一到真实企业上线，就会遇到权限、口径、表名、脏数据和责任边界。本文从一次上线评审讲起，拆解 AI 问数翻车的 4 个原因，以及上线前必须补的 5 个基础动作。

很多数据分析师和数据开发写简历时会写项目背景、技术栈和指标结果，却在面试官追问细节时说不清证据。项目价值不是一句提升效率，而是一条能复原现场的证据链。本文从一次面试追问讲起，拆解数据项目证据链的 5 个环节，帮候选人把普通需求讲成可信项目。

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

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

本期数据周刊关注 Data Engineering Weekly #274 里的 5 个信号：Anthropic 的 Claude 自助分析、Airbnb 多产品数据架构、Uber 数据抽象层、LinkedIn Agent 语义检索，以及 Capital One 的 DataAgents。AI 数据产品真正缺的是什么？

很多数据从业者每天写日报，一周 5 份，写了需求、SQL、看板和会议，却在绩效沟通时发现领导仍然不知道自己的价值。问题不一定是你没做事，而是日报只记录动作，没有翻译成影响。本文拆解 3 种低效日报和 4 个改写方法，帮数据分析师把日常工作变成可复盘的证据。

很多候选人回答数据质量，只会背空值、重复、波动 3 类规则。但面试官真正想听的是：你怎么判断业务真的下滑还是链路出错，怎么定义影响面，怎么把规则放进数据链路，怎么处理业务责任。本文用一个面试现场拆解数据质量问题的 5 层回答方式，适合数据开发和数据分析师准备面试。

一次数据事故从周五晚上拖到周日，团队 48 小时修完任务、补跑数据、恢复看板，但复盘时才发现真正缺的不是告警，而是影响面、修复记录、责任边界和上线验证。本文用 5 个问题拆解数据事故复盘，帮数据开发和数据治理团队避免下次重复摔在同一个地方。

一次 AI 问数 Demo 里，模型把 LEFT JOIN 改成 INNER JOIN，SQL 看起来更短、更顺，却让未转化用户被悄悄排除。AI 写 SQL 的风险不只是语法错误，而是错得很像对的。本文拆解生成错误、业务逻辑错误和可信问数系统的边界，并自然介绍 Forge。

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

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

本期数据周刊关注 4 个生产信号：Gorgias 的 Flink 账单系统、Cloudflare 的 ClickHouse 查询计划瓶颈、Netflix 的 Cassandra 时间序列分区，以及 Snowflake Summit 后的数据团队 Agent 成本讨论。数据工程师该从这些案例里看到什么？

数据资产入表不是把数据估个价格写进报表，而是要求企业能证明数据来源、权属、质量、成本、使用场景和收益逻辑。本文结合财政部企业数据资源会计处理规定，解释普通公司为什么卡在资产识别、成本归集、质量治理、合规证明和业务闭环这些长期的数据基础能力上。

企业内部做高质量数据集，不能只是建一个文件夹或上传一批样本。真正可复用的数据集需要设计使用场景、字段说明、版本记录、质量验收、权限边界、调用登记和反馈机制，才能成为 AI 应用、业务分析和数据产品可以反复使用、长期持续维护的稳定数据供给能力。

很多数据分析师和数据开发不是没有项目，而是把日常需求做完就散了。本文用一个普通取数、报表和口径排查需求，拆解如何从问题背景、业务动作、数据处理、结果影响、复盘材料五个环节沉淀证据链，让普通工作变成简历和面试里讲得清楚、有证据支撑的真实项目。

AI 合规不只是法务问题。随着生成式 AI、深度合成标识、拟人化互动等监管要求逐步落地，数据分析师、数据开发和数据产品经理需要知道数据来源、授权范围、敏感信息、输出标识、日志追溯和责任分工这些工作边界，避免把企业 AI 项目做成不可追溯的生产黑箱。

企业 AI 应用上线前，数据团队不能只说“先接数据试试”。本文从生成式 AI 暂行办法、AI 生成合成内容标识和个人信息保护要求出发，给数据开发、数据治理负责人和 AI 产品经理一套四条数据边界检查法：来源授权、敏感信息、模型使用、输出追溯。

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

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

很多数据分析师和数据开发仍把机会想象成互联网大厂的增长、推荐和用户分析。但 2026 年数据要素、工业互联网与人工智能融合、高质量数据集、医保和公共数据场景正在把需求推向制造、医保、政务等真实产业。本文说明数据从业者如何判断这些机会、迁移旧能力，并留下能证明价值的项目证据。