这篇博客的作者来自Anthropic数据科学与数据工程团队，把重复机械的取数活交给Claude后，他们腾出手，去做因果建模、预测、机器学习等事情。 一个数据模型里有几百个看着都能用的字段，背后可能藏着上百万个。你问「有多少活跃用户」，什么动作算活跃？算不算欺诈账号？回溯窗口取7天还是30天？模型在这堆近义选项里，挑不出对的那个。 数据源、业务定义、表结构天天在变。模型脑子里的知识慢慢「生锈」，开始返回「细微处出错」的答案。这种错最难发现，看着全对，其实早就不对了。 把它和写代码对比，差别一下就清楚了。写代码是开放题，文档和单元测试天然挡着幻觉。数据分析往往只有一个正确答案、一个正确来源，而且没有任何确定性的办法证明它对。 第一层，数据基础层（data foundations）：数据仓库本身，包括数据模型、转换、测试、表，以及描述它们的元数据。核心动作是把同一个概念收敛到唯一一张权威表，专治「概念-实体歧义」，同时也构建了预防数据口径过时的第一道工程防线。 第二层，事实来源（sources of truth）：模型查数时参照的几个权威来源，按可信度从高到低是：语义层＞血缘与转换图＞查询语料＞业务上下文。它的作用就是把用户嘴里模糊的问法，翻译成系统里唯一正确、有人维护的数据口径。 第四层，验证（validation）：离线评测、消融实验、在线验证，再加上维护流程，查出三类错里还有哪一类在漏，也是对抗「数据过时」的主要方式。 他们试过让大模型自动从原始表生成指标定义，结果生成的定义把想消除的歧义又原样编码了回去，在评测里直接成了负分。最后只能改回老办法：Claude起草文档，定义由人来拍板。 事实来源是声明式知识，告诉模型每个指标是什么意思；Skills是程序性知识，告诉它先查哪、按什么顺序查、一份合格分析长什么样。 于是Anthropic团队就把维护当成正经工程来做：Skill文档和数据模型塞进同一个代码仓库，改模型的那个代码合并请求（PR），顺手把对应文档也改了。现在约90%的数据模型改动，都带着一处Skill更新一起提交。 给智能体开了全文检索（grep）权限，让它去翻历史SQL文件，还在运行记录里确认它确实一条条读了。结果准确率上下波动不到1个点。更要命的是，答错的那些题里，约80%的正确答案，其实就躺在它刚读过的语料里。它看见了，还是没用上。