AI 数据分析：数仓可信合同
一份自学指南：用 Hooray 当前 Snowflake、Product 360、Ops 360、PIM 例子，讲清 Anthropic 自助数据分析的核心概念。
1. 真正的主题：数据分析不是写软件
机制写代码时，AI 经常可以验证自己：代码能编译、测试能通过、页面能渲染、API 返回格式正确。数据分析没有这么简单。SQL 可以跑得很顺，但仍然回答了错误的业务问题。
难点不是 SQL 语法。难点是把人的一句话，映射到正确的业务实体、指标定义、粒度、freshness 规则和 source-of-truth 路径。
当业务用户问：“product X 的 revenue 是多少？”他们不是在要一张表。他们在要一个可信业务答案。大多数用户无法判断 AI 是否用了正确 source、商品身份层级是否正确、指标定义是否最新。所以 Anthropic 的核心思想是：正确性必须由系统结构保证，不能依赖用户发现隐藏错误。
Hooray 例子问题：“2026-06-06 Amazon US 的 Livatro LVHD7001 humidifier profit 是多少？”
重点：Livatro LVHD7001 humidifier 是用户输入的搜索短语，不是 source of truth。人能读懂的商品名可以帮助 lookup，但它太模糊、太容易和相似商品混淆，也会变化，所以不能当 canonical product key。
弱 analytics agent 会要求业务用户自己解决数仓歧义。强 agent 会先解析系统已经知道的内容，只对真正需要人类判断的少数问题提问。
| Resolution Step | AI 应该推断什么或 block 什么 | 漏掉这一步会怎样错 |
|---|---|---|
| Market scope | 推断：Amazon US only。不要再问是否包含所有 Amazon markets。 | AI 把 Amazon US 和 MX/CA/JP/DE 混在一起，输出一个 listings、fees、currencies、totals 都混掉的数字。 |
| Date scope | 推断：只看 2026-06-06。不要偷偷改成 “yesterday”、一周，或 trailing window。 | AI 回答了一周或 trailing-window 的问题，但用户其实问的是一个具体日期。 |
| Product identity | block until resolved：把短语解析到 Product 360 SKU；如果是 family-level，用 SPU；如果是 listing-level finance，用 exact Amazon US listing identities。 | AI 算了相似 SKU、整个 SPU family，或者只算了某一个 marketplace listing，却声称已经回答了这个 product。 |
| Metric definition | block until resolved：使用 finance-approved profit rollup 或 semantic metric。 | AI 把 gross sales、payout profit、contribution margin、ad-adjusted profit 当成同一个 profit 指标。 |
| Finance source route | 推断：Product/Ops identity 解析后，先走 Finance-owned CORE metric route：日粒度 item/metric 分析用 fct_finance_item_metric_daily；需要 ledger-line 追溯时再 drill down 到 fct_finance_ledger_lines；final profit 必须套用 Finance-owned profit rollup。不要从 DWM_FIN_PROFIT_REPORT 或 DWS_FIN_PROFIT_SUBJECT_MSKU_DAY 这类 old profit-looking tables 开始。 |
AI 选择名字里带 “profit” 的旧表，输出一个看起来合理但非官方的 profit 数字。 |
| Currency rule | 如果缺失就 block until resolved：使用 semantic metric 里的 approved currency rule。 | AI 混用了 native currency 和 USD amount，或者临时编了一个 Finance 没有批准的汇率规则。 |
| Case Status | 答案 |
|---|---|
| 它说明什么 | 人能读懂的 product phrase 适合搜索，但不是数仓真相。Product identity 和 finance metric definition 是两个不同的解析步骤。 |
| 原始证据 | 用户短语 Livatro LVHD7001 humidifier、platform/market Amazon US、日期 2026-06-06、指标 profit。 |
| Canonical status | market 和 date 已经由问题本身确定。product identity 还没有确定，必须等 Product/Ops 返回 Product 360 SKU 和 Amazon US exact listing identities。profit 也还没有最终确定，必须等 finance 返回 approved rollup 或 semantic metric。 |
| 还缺什么 | 这个短语对应哪些 SKU/listings/seller affiliations，以及哪些 metric-code components 和 currency rule 组成 final profit。 |
| AI 下一步 | 不要再问是否包含所有 Amazon markets。先解析 product/listing identity，再走 fct_finance_item_metric_daily + Finance-owned profit rollup。如果任一 resolver 失败，就带具体 blocker 停止。 |
现在做得好的地方Finance 已经有一条比较强的 official route：CORE metric-code route。日粒度 item-level 分析的 preferred model 是 fct_finance_item_metric_daily。需要 ledger-line 追溯时，drilldown source 是 fct_finance_ledger_lines。当用户输入的短语被解析到 official Product 360 SKU 和 Amazon US exact listing identities 后，答案应该来自这种形状的 finance rows：
platform = amazon、country_code = US、report_date = 2026-06-06metric_code = 0.1、metric_name = total_sales_quantitymetric_code = 1.1、metric_name = total_sales_amountmetric_code = 3.1、metric_name = platform_feemetric_code = 3.2.1、metric_name = fba_delivery_fee
metric code 在这里承担了真正的语义工作。它告诉 AI 每个数字是什么意思，而不是让 AI 自己在 sales、revenue、payout、fee、profit 字段里猜。
重要澄清：这不是说 fct_finance_item_metric_daily 只有 seller SKU。finance model 里有 item grain key、local SKU、ASIN、parent ASIN 等 item/product mapping fields。SELLER_SKU 是平台 merchant SKU 字段，不是最终 Product 360 identity。
现在坏的/缺失的地方旧 finance-looking alternatives，比如 DWM_FIN_PROFIT_REPORT 和 DWS_FIN_PROFIT_SUBJECT_MSKU_DAY，名字听起来也像正确答案。如果 AI 能把它们当成同级候选，它可能选择名字最明显的表，而不是受治理的定义。
还有一个问题：有些 sample outputs 和 analyst queries 会把 SELLER_SKU 显示成最明显的 product-like label。这个 visible label 可以作为 evidence，但不能当 canonical Product 360 identity。人类可读商品名也有同样问题：它可以帮助 lookup，但太模糊、相似、可变化，所以不能当 source of truth。两者都必须先通过 canonical Product/Ops identity 解析，才能计算。
正确行为AI 应该说：“这个问题的 scope 是 2026-06-06 Amazon US。Livatro LVHD7001 humidifier 这个短语是 lookup clue，不是 source of truth。我会先把它解析到 canonical Product 360 identity 和 Amazon US exact listing identities，然后使用 Finance-owned CORE metric route：日粒度 item/metric 分析用 fct_finance_item_metric_daily；只有需要 ledger-line 追溯时才用 fct_finance_ledger_lines。我不会使用 legacy profit report tables、raw SELLER_SKU display values 或人类可读商品名作为最终 product identity。要输出 final profit，我还需要 approved profit rollup，明确哪些 metric codes 和 currency rules 属于 profit。”
自测如果用户已经说了 Amazon US，AI 还应该问是否包含所有 Amazon markets 吗？
答案：不应该。Amazon US 和 2026-06-06 已经由问题本身确定。还没解决的是 product/listing identity 和 approved profit definition。
2. 错误模式一：Concept 和 Entity 对不上
机制Concept 是用户说的词。Entity 是系统必须使用的具体数仓对象。“Revenue”、“active user”、“product”、“listing”、“profit” 都是 concept。表、metric code、字段、身份、filter、grain 才是 entity。
当一个 concept 能对应多个看起来合理的 entity，AI 就容易错。解决方法不是叫模型“小心一点”，而是减少候选项，并在计算前强制 resolver step。
Hooray 例子它说明什么：raw marketplace rows 是证据，不是 product truth。
原始证据：在 guide sample extract current_walkthrough_samples 里，SAMPLE_TYPE = amazon_listing_mapping 的 row 显示：source account DINGYAO_SC_01、marketplace/domain value A1AM78C64UM0Y8、seller-SKU-style value FP-B2P、ASIN B0DDTK4PKV、country MX。
Reader context：这个 sample extract 使用 generic column names，所以要看下面的 business meaning。这里不是说 DATE_KEY 字段真的代表日期；这里的重点是：这条 sample row 是 marketplace-listing mapping row，不是 Product 360 product-master row。
| Sample Extract Field | Sample Value | 这个例子里的业务含义 |
|---|---|---|
SAMPLE_TYPE |
amazon_listing_mapping |
这条 row 来自 listing-mapping evidence set，不是 canonical Product 360 product master。 |
PLATFORM |
amazon |
marketplace platform。 |
SOURCE_SYSTEM |
DINGYAO_SC_01 |
source account / seller account context。 |
DATE_KEY |
A1AM78C64UM0Y8 |
在这个 normalized sample extract 里，它代表 marketplace/domain value。 |
ENTITY_KEY |
FP-B2P |
seller-SKU/MSKU-style clue。 |
ATTRIBUTION_WINDOW |
B0DDTK4PKV |
在这个 normalized sample extract 里，它代表 ASIN value。 |
MEASURE_1 / MEASURE_2 |
FP-B2P / MX |
seller SKU repeat，加 country。 |
同一个 sample extract 里，附近 rows 使用相同 account、marketplace 和 country，但有不同 seller-SKU-style values，例如 FP-K4P-new、FP-K6P、FP-MP-F、FP-MP-K。这也是一个线索：它是 mapping evidence，不是最终 product layer。
意思：它还不能安全归入 SPU、SKU 或 exact listing identity。要先做更多 identity resolution，才能回答 product performance。
| Signal | 它告诉我们什么 | 它不能证明什么 |
|---|---|---|
DINGYAO_SC_01 |
seller/account context。 | 它本身不是 product、SKU 或 listing identity。 |
A1AM78C64UM0Y8 + MX |
marketplace/domain context。 | 它不能证明答案应该包含所有 Amazon markets。 |
FP-B2P |
seller-SKU/MSKU-style signal。 | 它不自动等于 Product 360 SKU 或 SPU。 |
B0DDTK4PKV |
marketplace item evidence。 | 它不能替代 exact platform + domain + MSKU / listing_id resolution。 |
| Canonical Layer | 这个 case 的状态 | 为什么 |
|---|---|---|
| SPU | 未解析。 | 仅凭这些证据，还没有确认 product-family identifier。 |
| Product 360 SKU | 未解析。 | FP-B2P 是 seller-SKU/MSKU-style clue，不自动等于官方 Product 360 SKU。 |
| Listing item / exact listing | 未解析。 | ASIN 和 marketplace 是 listing evidence，但系统仍然需要 exact listing identity，例如 platform、domain、MSKU 和/或 listing ID。 |
| Seller affiliation | 有部分证据，但不足以做 product analytics。 | DINGYAO_SC_01 指向 seller/account context，但 seller context 不等于 product identity。 |
| 身份层级 | 通俗含义 | 负责人 | AI 猜错会怎样 |
|---|---|---|---|
SPU |
商品家族。 | Product 360。 | AI 可能把多个真实产品聚合后，当成一个 SKU。 |
SKU |
商品身份，也是 Product 360 操作上下文。 | Product 360。 | AI 可能漏掉 marketplace-specific listing 或 seller 差异。 |
| Exact listing identity | 精确 platform + domain + MSKU，最好解析到 listing_id。 |
Ops 360 / Listing 360。 | AI 可能混合不同 marketplace、domain 或 listing。 |
| Seller affiliation | 挂在 shared listing 上的 seller/store/account 关系。 | Ops 360 / Listing 360。 | AI 可能把一条 seller row 当成整个 listing 或 product。 |
现在做得好的地方Product 360 / Ops 360 / PIM 设计已经给了我们正确概念模型。Product 360 负责 SKU truth、Product-owned assets、manuals 和 readiness。Ops 360 默认进入 Listing 360，负责 exact listing identity、seller affiliation、lifecycle、publish state 和 listing-specific exceptions。PIM 是内部数据/服务边界，不是用户面对的概念。
现在坏的/缺失的地方agent-facing warehouse contract 还没有强制每个 product-linked answer 都先走 identity resolver。如果 AI 看到 FP-B2P，它可能选择一条 seller row、一条 marketplace row、所有 MSKU matches、所有 SKU matches，或者整个 SPU family。
这些都可以算出数字。但只有一个可能匹配用户真正想问的问题。
正确实现计算前，AI 必须调用 Product/Ops identity resolver。resolver 返回 status，而不只是返回 rows：
SKU_RESOLVED：可以做 SKU-level Product 360 reporting。EXACT_LISTING_RESOLVED：可以做 listing-scoped sales、ads、inventory、images、publish state、exceptions。SELLER_AFFILIATION_RESOLVED：只有 seller/store/account scope 重要时才安全。AMBIGUOUS_LISTING_TO_SKU：停止并 route mapping repair。DOMAIN_MSKU_PLATFORM_AMBIGUOUS：停止并要求补充 platform/domain/listing。NO_MAPPING：停止，不要编造 product relationship。
这个 case 的答案：只看这个 sample，FP-B2P 还不能安全解析为 SPU、SKU 或 exact listing identity。AI 应该说：“我找到了 marketplace 和 seller/account evidence，但还没有把它解析到 canonical product 或 listing layer。所以我现在不能计算 product performance。下一步是走 Product/Ops identity resolution；如果返回 ambiguity，就需要修 mapping 或只问一个很窄的 listing-scope clarification。”
自测sample value FP-B2P 可以直接当成 official Product 360 SKU 吗？
答案：不可以。在这个 sample row 里，它是 seller-SKU/MSKU-style marketplace evidence。必须先解析 identity，才能计算 product performance。
3. 错误模式二：Staleness
机制Staleness 不只是“数据旧”。只要 source、schema、mapping、文档或业务规则变了，但 AI 仍然按旧世界回答，就是 staleness。
所以 Anthropic 强调 maintenance、validation、colocation 和 freshness。数仓周一可能是对的，周五就可能因为业务变化和 agent guidance 没同步而误导用户。
Hooray 例子sample profile table orders_periodic_profile 里，Lazada order_lines row 出现不可能的未来日期。这条 row 显示：MIN_REPORT_DATE = 2024-10-26、MAX_REPORT_DATE = 58395-06-15、ROW_COUNT = 17427、FUTURE_DATE_ROWS = 17017。有一个 query client 甚至因为这个异常日期无法正常转换。
| Profile Field | Sample Value | 读者应该怎么理解 |
|---|---|---|
PLATFORM |
lazada |
受影响的 sales/order platform。 |
SOURCE_TYPE |
order_lines |
被 profile 的 source shape。 |
MAX_REPORT_DATE |
58395-06-15 |
不可能的未来日期，所以 “latest” 不可信。 |
ROW_COUNT / FUTURE_DATE_ROWS |
17427 / 17017 |
这个问题影响了被 profile 的大部分 Lazada order-line rows。 |
这个 case 的答案：如果用户问 “Show latest Lazada sales”，AI 不应该返回 latest-sales chart。它应该停止并说明 source 有 invalid future dates，因为在日期质量问题修复或被 governed rule 排除前，“latest” 没有可靠意义。
| Case Status | 答案 |
|---|---|
| 它说明什么 | 有时候 entity 已经足够清楚，但 source shape 让问题本身不安全。坏日期会破坏任何 “latest” answer。 |
| 原始证据 | Lazada rows 包含 58395-06-15 这类不可能的未来日期，并且已知有 17,017 条受影响 rows。 |
| Canonical status | 这主要不是 SPU/SKU/listing 问题，而是 orders/sales source 的 freshness 和 data-quality gate。 |
| 还缺什么 | 这些 rows 应该被修复、通过 governed rule 排除，还是从 agent-facing latest-period answers 中隔离。 |
| AI 下一步 | 停止 latest-sales answer，报告受影响 platform 和 count，并把 date-quality issue route 给 source owner。 |
现在坏的/缺失的地方freshness 和 anomaly checks 还没有强到可以作为 agent-facing gates。不能只靠人工分析师记得“注意怪日期”。agent path 本身必须在输出趋势、latest period result 或业务建议前 block 或 warn。
另一个 staleness pattern：旧 finance tables 仍然存在。即使新的 canonical metric path 更好，只要旧 source 没有被 deprecated、hidden 或明确标为 non-primary，它们就是 stale traps。
正确实现自助数据分析 AI 在回答前应该做 freshness 和 shape checks：
- 每个平台的最大/最小日期
- future-date count
- last complete reporting period
- expected platform/domain scope
- mapping completeness
- deprecated-source visibility
如果 “latest Lazada sales” 包含 58395 年，正确答案不是图表。正确答案是：“我不能安全回答 latest sales，因为 source 有 invalid future dates。这里是受影响平台、数量和 owner route。”
自测为什么 “latest Lazada sales” 的正确答案不是图表？
答案：因为 profiled source 有不可能的未来日期，包括 MAX_REPORT_DATE = 58395-06-15。AI 必须先 block 或 route data-quality issue，不能直接总结 latest sales。
4. 错误模式三：Retrieval Failure
机制Retrieval failure 的意思是：正确答案存在，但 AI 没有找到或没有使用。Anthropic 很重要的一点是：给 AI 更多搜索权限并不自动解决问题。如果搜索空间巨大，AI 可能读到了正确资料，最后仍然选错。
解决方法是 structured retrieval：小 router、curated reference docs、semantic definitions、domain skills，在 SQL 写出来之前就缩小空间。
Hooray 例子Ads search-term analysis 是好例子。在 guide sample extract current_walkthrough_samples 里，SAMPLE_TYPE = ads_search_term 的 rows 包含 platform amazon、source amazon_ads、date 2026-06-05、attribution window 7d。
| Search Term | Platform / Source / Date | Attribution Window | Sample Measures |
|---|---|---|---|
バランスディスク |
amazon / amazon_ads / 2026-06-05 |
7d |
406 impressions、11 clicks、659.92 spend、0 attributed sales。 |
チタン まな板 |
amazon / amazon_ads / 2026-06-05 |
7d |
139 impressions、5 clicks、190.28 spend、7090 attributed sales。 |
attribution window 不是装饰。没有 7d，attributed sales 就不是完整指标定义。
这个 case 的答案：在这个 Amazon ads source 和 7d attribution window 下，sample row 里 チタン まな板 有 7090 attributed sales，バランスディスク 有 0。答案必须说 “7d attributed sales”，不能只说 “sales”，也不能暗示这是 profit、organic sales 或所有 attribution windows。
| Case Status | 答案 |
|---|---|
| 它说明什么 | 即使 row 真实存在，metric 也可能不完整。Ads 里的 “sales” 必须说明 attribution window 和 source，才是完整定义。 |
| 原始证据 | search terms、impressions、clicks、spend、attributed sales、source amazon_ads、date 2026-06-05、attribution window 7d。 |
| Canonical status | 这个 ads metric 的 scope 是 search term、platform、date 和 7d attribution。它不是 profit、organic sales 或 all-window sales。 |
| 还缺什么 | 如果用户想要 product profitability，还需要另外解析 SKU/listing identity 和 finance metrics。 |
| AI 下一步 | 使用 approved ads path 回答 ads 问题，并明确 attribution window。不要偷偷把它 join 成 profit 或 organic revenue。 |
现在坏的/缺失的地方旧 search-term tables 或高行数 search-term tables，可能看起来比 canonical path 更完整。模型搜索数仓时，容易偏向最大、最熟悉、名字最像答案的表，尤其当 domain guidance 没有同步到 runtime。
raw historical SQL 也有同样问题。旧查询是有用原材料，但不是真相。如果 AI 直接复制旧 dashboard query，它可能同时复制旧 filters、旧 attribution logic、旧 identity assumptions。
正确实现AI 应该先进入 ads domain router。router 明确：search-term sales 使用 approved ads source，必须有 attribution window，必须说明 platform 和 date，并拒绝不暴露 window 的 source。历史 query 应该被提炼成 patterns 和 evals，而不是作为一大堆 raw examples 暴露给 AI。
自测这个 ads 例子里，sales number 旁边必须出现哪个词？
答案：7d attributed sales。如果没有 attribution window，“sales” 太模糊，容易被误解成 organic sales、all-window sales 或 profit。
5. Data Foundations：压缩答案空间
机制Data foundations 是 warehouse models、transforms、tests、tables 和 metadata。对 AI 来说，它们最重要的作用是减少 ambiguity。如果 “profit” 只能 resolve 到一条 governed route，而不是四十张 plausible tables，问题在 AI 推理前就已经解决了一大半。
现在做得好的地方Hooray 已经有比较完整的 modeled ladder：source/ODS 到 STG、INT、CORE、MART、RPT。CORE 是 canonical enterprise truth 的最强候选层。也已经有 initial agent catalog、table catalog、model headers 和 finance metric governance。
现在坏的/缺失的地方live warehouse 仍然暴露大量 old/app-facing surfaces，例如 DWD、DWM、DWS、DIM、APP、Tableau-oriented schemas。如果 AI 能找到这些，它们就不是无害的。它们正是“五个看起来都合理的答案”问题。
问题不是每张旧表都错。问题是：如果系统没有结构化标注，AI 不知道哪张是 canonical、哪张是 speed copy、哪张是 app output、哪张是 legacy、哪张 unsafe。
| Surface Type | 对 AI 的含义 | 正确处理方式 |
|---|---|---|
| Canonical model | 某个业务概念的官方真相。 | 默认可见；有 owner、文档、测试。 |
| Semantic metric | 官方计算逻辑和允许维度。 | top KPIs 先用它，不先写 custom SQL。 |
| Mechanical rollup/cache | canonical truth 的快速副本。 | 只有 parent lineage 且无 private logic 时可见。 |
| App/report output | presentation 或 workflow-specific surface。 | 除非明确 contracted，否则不是 primary truth。 |
| Legacy/deprecated | 旧答案路径。 | 对普通 agent role 隐藏，或明确 block。 |
正确实现建立 agent-safe warehouse contract。默认 analytics agent role 只应该看到 semantic definitions、approved canonical datasets、approved mechanical rollups 和 narrow diagnostics。它不应该像浏览同级选项一样浏览 old finance reports、app exports、ingestion/admin surfaces 或 deprecated schemas。
这个 case 的答案：old/app-facing surfaces 不一定都错，但也不自动安全。正确实现要把每个可见 surface 分类为 canonical、semantic、mechanical rollup/cache、app/report output、diagnostic 或 deprecated。如果一个 surface 没有 classification、owner、lineage 或 allowed-use rule，AI 就应该把它视为 unsafe for first-answer analytics。
之前漏掉的文章概念Anthropic 明确说：governance 只有在被 tooling、CI 和 mandate 强制时才站得住。Claude 可以帮助写 descriptions、发现 undocumented models，但系统必须结构化地把 agents 优先 route 到 governed definitions。
| 缺失的 Foundation Concept | 通俗意思 | Hooray 学习例子 |
|---|---|---|
| Metadata as product | table descriptions、grain、valid values、lineage、ownership、source tier 不是附属说明。它们是 agent 使用数仓的产品界面。 | finance row 不应该只暴露 metric_code = 3.1；还应该说明 metric owner、grain、valid values，以及是否 safe for agent answers。 |
| Colocated artifacts | model code、semantic metrics、reference docs、dashboard definitions 应该一起变化。 | 如果 Product/Ops identity mapping 变化，warehouse model 和 agent reference doc 应该在同一条 change path 更新，而不是隔几周才补。 |
| Enforced standards | 规则只有被工具强制，才是真规则。 | 如果 PR 改了 agent-facing finance model，但没有更新 metric docs、owner 或 eval coverage，应该 fail review 或要求明确 exception。 |
自测如果一张旧表名字很像答案，但没有 owner、lineage 或 allowed-use rule，AI 应该把它当第一答案吗？
答案：不应该。好名字不等于治理。AI 应该使用 classified canonical source，或者停止。
6. Rollups 和 Caches：加速副本，不是新的真相
机制Rollup 是提前算好的汇总。Cache 是快速副本。Anthropic 不是说不要 rollup/cache。重点是它们必须 mechanically derive from canonical models。它们可以让答案更快，但不能让答案变成另一个版本。
Hooray 例子daily 或 weekly profit summary 可以很有用。但它必须 trace back 到 finance-approved metric-code fact。如果它自己藏了 filters、private currency handling 或旧 fee logic，它就变成 shadow source of truth。
这个 case 的答案：weekly profit rollup 只有在它是官方 finance metric definition 生成出来的 speed copy 时才安全。如果它有自己的 profit formula，就应该标成 deprecated、diagnostic 或 unsafe for agents，而不是被当成另一个 official answer。
| Case Status | 答案 |
|---|---|
| 它说明什么 | 可以为了性能优化，但不能藏私有业务逻辑。Rollup 可以加速 truth，不能变成第二套 truth。 |
| 原始证据 | 一个 daily 或 weekly profit summary，看起来比 metric-code finance rows 更容易 query。 |
| Canonical status | 只有它按声明的 grain 和 metric version，从 canonical finance model mechanically 生成，才是安全的。 |
| 还缺什么 | 它是否有 parent lineage、refresh cadence、metric version，以及没有 hidden filters 或 private formulas。 |
| AI 下一步 | 只有 lineage 证明它是 canonical model 的 cache 时才使用。否则用 canonical finance path，或停止。 |
现在坏的/缺失的地方旧的大 rollups，比如 old profit subject/day tables，可能对 performance 或 reconciliation 有用。但如果它们没有 hard label，就放在 canonical finance model 旁边，AI 和人都会把它们当成 alternate answers。
正确实现每个 rollup 都需要 parent pointer：“我从这个 canonical model 生成，使用这个 metric version，在这个 grain，以这个 cadence refresh。”如果 canonical revenue definition 变了，rollup 必须 mechanically 跟着变。如果做不到，它就不是安全的 agent-facing rollup。
自测weekly profit rollup 在什么情况下可以安全给 AI 使用？
答案：只有它是 canonical finance model 的 mechanical speed copy，并且有 parent lineage、metric version、grain 和 refresh cadence。
7. Sources Of Truth：可信梯子
机制Sources of truth 是 AI 用来理解和导航数仓的参考面。Anthropic 的可信梯子是：semantic layer first；如果 metric 不存在，用 lineage；旧 query corpus 只能作为 curated pattern 原材料；business context 用来理解问题周边语义。
| 可信层 | 它做什么 | Hooray 例子 |
|---|---|---|
| Semantic layer | 把 KPI 变成官方 compiled definition。 | “Finance-approved profit by SKU” 定义 metric codes、currency、date、allowed dimensions。 |
| Lineage graph | 如果 metric 不存在，找到 governed model path。 | orders 或 ads fallback 应该落到 canonical fact，而不是 random app/report table。 |
| Curated query patterns | 把旧 SQL 转成 reusable guidance。 | 重复出现的 finance 和 ads dashboard logic，整理成小 domain guide 和 evals。 |
| Business context | 解析名称、launch、owner、团队用语。 | Feishu 可以帮助理解 product nickname 或 launch phrase，但它不是 product truth，也不负责计算数字。Product/Ops identity 和 Snowflake canonical sources 才负责。 |
现在坏的/缺失的地方Hooray 有这条梯子的部分组件，但还不是完整强制梯子。agent catalog 有用，但它不是 compiled semantic layer。historical queries 和 app outputs 还没有系统性地变成 curated patterns。business context 也还不是受治理的 analytics context layer。
之前漏掉的文章概念Anthropic 曾经尝试让 LLM 从 raw tables 和 query logs 自动生成 semantic metric definitions。结果是：生成内容看起来合理，但把他们想消除的 ambiguity 又编码进了定义里。所以他们的建议很关键：可以用 Claude 生成 documentation drafts，但 definition 必须由人负责。
| 任务 | Claude 可以帮什么 | 人必须负责什么 |
|---|---|---|
| Draft metric docs | 总结 existing metric rows，提出 descriptions，发现缺失的 owner/grain/freshness fields。 | 批准 profit、revenue、contribution margin、active listing、sellable inventory 的真实业务定义。 |
| Find ambiguity | 对比 old finance queries、dashboard logic、table descriptions，找出 conflicting formulas。 | 选择一个 official definition，并 deprecate 或标记 near-duplicates。 |
| Maintain docs | 当 model 改变或用户纠错时，提出 doc update。 | 只有 Finance/Product/Ops owner 确认定义正确后，才 merge 这个 change。 |
Hooray 例子：Claude 可以根据 finance metric-code rows 起草 “Amazon US profit for Livatro LVHD7001 humidifier” 的定义。但 Finance owner 必须决定哪些 fees、currency rule、return treatment、ad costs、listing scope 正式属于 profit。如果由 Claude 拥有定义，它可能创造一个很像真的、但非官方的 metric。
正确实现对 top KPI，AI 不应该先问“哪张表有 revenue？”而应该先问 semantic layer 的 revenue metric。只有它失败，才用 lineage 选择一个 governed model。再失败，就停止并请求 human-owned definition。
这个 case 的答案：对 Amazon US profit 例子，business context 可以帮助 AI 理解 Livatro LVHD7001 humidifier 是一个 product phrase，但这个 phrase 不是 source of truth。可信梯子应该先通过 Product/Ops 解析 identity，再通过 semantic layer 解析 profit，然后才计算。如果 semantic layer 不知道 official profit，AI 可以展示 canonical finance path 里的 component rows，但不应该用 ad hoc SQL 临时编 final profit。
自测Feishu context 或 product nickname 可以计算 profit 吗？
答案：不可以。Business context 可以帮助理解词，但 Product/Ops identity 和 Snowflake canonical sources 才负责解析 identity 和计算指标。
第二题：Claude 可以起草 profit documentation 吗？可以。Claude 可以成为 profit definition owner 吗？不可以，必须由 Finance human owner 负责。
8. Skills：AI 的操作手册
机制如果 sources of truth 是 declarative knowledge，那么 skills 就是 procedural knowledge。source 告诉 AI 指标是什么意思；skill 告诉 AI 先查什么、避开什么坑、什么时候提问、什么时候停止、怎么 review、最后展示什么证据。
Hooray warehouse skill 应该教这个流程
- 先检查 red flags：PII、leadership-bound answers、customer/vendor-facing use、不可逆动作。
- 先提取问题中已经给出的事实：date window、platform、market、product/listing term、business decision。
- 只对真正缺失的 blocker 提问。不要要求用户重复已经说清楚的事实。
- 解析 Product/Ops identity：SPU、SKU、exact listing identity、seller affiliation。
- finance、ads、orders、inventory、mapping completeness 先使用 semantic metrics。
- 如果没有 semantic metric，用 domain router 和 lineage 选择一个 canonical model。
- 拒绝 deprecated DWD/DWM/DWS/app/report tables 作为第一答案。
- 在总结前运行 freshness、anomaly、required-filter checks。
- adversarially review source、grain、filters、identity level。
- 回答时带 provenance、freshness、owner、confidence、limitations、approval boundary。
Pairwise skills 到底是什么意思文章不是在说写一本巨大的 warehouse manual。它讲的是一对 skill：一个很薄的 knowledge skill 负责 route question，另一个 process skill 负责教 AI 怎么做分析。router 回答 “我应该去哪里找？” process skill 回答 “找到方向后，我应该怎么工作？”
| Skill Layer | 它做什么 | Hooray 例子 |
|---|---|---|
| Top-level knowledge skill | 任何 warehouse question 先加载它。它先尝试 semantic layer；如果还需要细节，再只加载相关 domain reference files。 | 问题提到 Amazon profit。router 打开 Finance/profit 和 Product/Ops identity references，而不是打开整个 warehouse。 |
| Domain reference files | 每个 domain 一份小的、LLM-readable 文件：finance、ads、orders、inventory、Product/Ops identity。里面写 tables、columns、joins、grain、exclusions、gotchas。 | finance reference 写明：使用 fct_finance_item_metric_daily；只有需要 traceability 才 drill 到 fct_finance_ledger_lines；不要把 old profit-looking tables 当第一答案。 |
| Analysis process skill | 教 AI 像 senior analyst 一样工作：只澄清 true blockers、找 sources、跑 query、检查结果、adversarially review、带 provenance 回答。 | 对 Livatro LVHD7001 humidifier，AI 先提取 Amazon US 和 June 6，解析 identity，检查 finance route，review source/grain/filter risk，然后 answer 或 block。 |
| Reusable analysis patterns | 把反复出现的分析方法沉淀下来，让 AI 不需要每次重新发明流程。 | finance bridge analysis、ads attribution-window analysis、inventory freshness checks、mapping-completeness checks 都应该有 reusable pattern。 |
Article coverage summaryAnthropic 的 skill docs 是写给 LLM retrieval 的，不是普通 internal wiki。它们描述 grain、scope、exclusions、usage、when not to use、gotchas、common patterns、cross-references。文章也强调：skill docs 如果不主动维护，很快会 stale。
| Skill Design Concept | 为什么重要 | Hooray 学习例子 |
|---|---|---|
| Reference docs written for LLM retrieval | agent 需要 routing triggers 和 gotchas，不需要很长的叙事 wiki。 | finance reference 应该写：“IF question asks for Amazon profit, route through fct_finance_item_metric_daily, drill to fct_finance_ledger_lines only for traceability, and apply the Finance-owned profit rollup. DO NOT use old profit subject/day tables as first answer.” |
| Semantic layer first; do not bail early | 文章提醒：不能因为问题看起来 custom，就跳过 semantic layer。skill 应该强制 AI 先尝试 governed metrics，再考虑 raw SQL。 | 如果 final profit metric 缺失，AI 可以展示 canonical component rows，但不能用 ad hoc SQL 临时编 final profit。 |
| Reference-file skeleton | 每个 domain file 应该有固定结构：when to use、grain、required filters、allowed joins、when not to use、freshness、gotchas、examples、cross-references。 | Product/Ops identity reference 必须明确解释 SPU、SKU、exact listing identity、seller affiliation 的区别，以及什么时候需要哪个层级。 |
| Process skill and adversarial review | skill 不只是 source list。它要教 AI 在给出答案前挑战自己的 source、grain、filters、identity mapping、date handling、metric definition。 | 回答 profit 前，AI 应该问：market、date、identity grain、Finance-owned rollup、currency rule、deprecated-table exclusion 都对了吗？ |
| Maintenance as first-class engineering | data models 每天都在变。model 变了但 skill doc 不变，agent 就会按旧世界回答。 | 如果 Product/Ops listing resolver 改变 identity behavior，reference doc 和 identity evals 应该一起更新。 |
| Colocation and review hooks | skills 应该和 dbt/semantic model changes 足够靠近，才能一起 review，而不是事后凭记忆补。 | 如果 PR 改了 agent-facing finance model，就应该更新 finance reference 和 evals，或者明确说明为什么不需要 skill change。 |
| Same answer across every surface | 只有 Codex、CyberFlo、BI-adjacent tools、scheduled reports 都使用同一套路由规则，skill 才算 canonical。 | “Amazon US profit for Livatro LVHD7001” 在任何入口都应该 route 到同一个 finance metric definition。 |
| Portability across tools | warehouse skill 不应该依赖某个 local path 或某一个 agent surface。同一套 reference package 应该能同步到 Codex、CyberFlo、MCP tools 和 scheduled analysis jobs。 | Finance/profit routing 应该存在 shared data contract 里，而不是只存在一个 Codex prompt 或一个 dashboard note 里。 |
现在坏的/缺失的地方当前 guidance 以碎片形式存在，但还不是每个 analytics surface 都必须使用的 versioned、synced warehouse skill。没有这个，Codex、CyberFlo、BI-adjacent tools 和 ad hoc analysis 可能遵循不同习惯。
更大的 gap 是：dbt codebase 现在更多是 skill 的 source material，还不是完整 skill system。真正 Anthropic-style 的设置，应该把 dbt lineage、owners、grains、tests、model descriptions 提炼成 domain reference files，并且把这些文件绑定到 model-change review 和 evals。
正确实现创建 thin top-level warehouse knowledge skill，加一个独立的 analysis process skill。top-level skill 负责 route question。domain files 负责 finance、ads、orders、inventory、Product/Ops identity 的 gotchas。process skill 教 AI 只澄清 blockers、先用 semantic metrics、跑 query、adversarially review result、带 provenance 回答。model 或 metric change 应该要求 skill/reference-doc/eval update，或者明确 exemption。
这个 case 的答案：一个 skill 是否成功，要看两个 AI 面对同一个 finance 或 product-identity question 时，是否走同一套顺序：提取已给事实、解析 identity、选择 canonical metric/source、运行 validation，然后 answer 或 block。如果一个 AI 直接跳到 plausible old table，另一个 AI 走 CORE finance metric route，说明 skill 还没有被足够强制。
自测什么能证明 warehouse skill 真的有效？
答案：不同 AI 面对同一个问题，会走同一套安全顺序：提取已给事实、解析 identity、选择 canonical metric/source、validation，然后 answer 或 block。
第二题：什么应该触发 skill doc update？会影响 agent 答案的 model、metric、grain、resolver 或 gotcha 变化。
9. Validation：练习考试和线上安全带
机制Validation 回答的问题是：“我们怎么知道 AI 选了正确路径？”Anthropic 拆成 offline evals、ablations、online validation、provenance、monitoring、correction harvesting。这部分把原则变成 operating system。
Evals 不是开放讨论题。每个 eval 都需要 expected source path、expected identity grain、expected stop conditions 和 pass/fail criteria。
ELI5eval 就是一个练习版 stakeholder question，并且有明确 grading rule。它不只是检查 final number 是否相同。它检查 AI 有没有用对 source、identity level、filters，以及在 business definition 缺失时有没有停止。
| Eval Source | 文章是什么意思 | Hooray 例子 |
|---|---|---|
| Dashboard-based evals | Claude 读取常见 dashboards 和 stakeholder workflows，提出高频业务问题，然后 humans validate expected behavior。 | finance dashboard 可能产生：“2026-06-06 Amazon US 的 Livatro LVHD7001 profit 是多少？”Finance 验证 expected behavior：必须解析 Product/Ops identity、使用 CORE finance metric route，如果 final profit rollup 未批准就 block。 |
| Long-tail evals | Claude 读取 business context、roadmaps、table docs、domain references，生成 domain 里较少见但合理的问题。 | Product/Ops docs 可能让 Claude 提出：“FP-B2P 表现怎么样？”expected behavior 不是立刻计算，而是 block until SPU、SKU 或 exact listing identity resolved。 |
| Correction-harvested evals | 每次 stakeholder correction 都是 candidate eval，因为它暴露了真实 failure mode。 | 如果同事说 “wrong table; this should exclude seller X”，这应该变成 new eval、reference-doc update，或者 deprecated-source rule。 |
| Eval | 测试什么 | AI 应该怎么做 |
|---|---|---|
2026-06-06 Amazon US Livatro LVHD7001 humidifier profit。 |
canonical finance route 和 metric-code logic。 | Pass：把 product phrase 只当 lookup clue，scope 保持 Amazon US 和 2026-06-06，解析 Product/Ops identity，使用 governed finance metrics；如果 final profit definition 缺失就 block。Fail：再问是否包含所有 Amazon markets，或把 old profit report tables 当第一答案。 |
FP-B2P 表现怎么样？ |
Product/Ops identity ambiguity。 | Pass：说明 sample 只是 marketplace/seller evidence，不是 resolved SPU、SKU 或 exact listing identity；先 route Product/Ops resolver 再计算。Fail：只凭 seller-SKU-style clue 直接计算 product performance。 |
| Show latest Lazada sales. | Staleness 和 data-quality stop condition。 | Pass：发现 58395-06-15 这种不可能未来日期后，先停止，不输出 trend，并报告受影响 platform/count/owner route。Fail：用坏的未来日期画 latest-sales chart。 |
| 2026-06-05 哪些 search terms 带来 sales？ | Retrieval 和 required ads filters。 | Pass：使用 approved ads path，并明确 7d attributed sales。Fail：说成 generic sales、profit、organic sales 或 all-window sales。 |
LVCUCM001-DE-KY-SC 有多少库存？ |
Inventory snapshot 和 identity grain。 | Pass：说明 snapshot date、included countries、identity level，以及 item ID B0FH4QL9GN 只是 listing evidence 还是 resolved listing identity。Fail：因为 item ID 看起来熟悉，就把 SKU/listing/country 库存混在一起。 |
现在坏的/缺失的地方warehouse tests 和 validators 有用，但它们不是 agent evals。一张表可以通过 dbt tests，但 AI 仍然选错表、错身份层级、错 attribution window。Hooray 还没有 fixed business-question eval suite、accuracy telemetry、domain launch gates 或 correction-harvesting loop。
正确实现每个高风险 domain 先做几十个 evals。每次运行记录 skill version、git SHA、model ID、source path、per-assertion pass/fail、latency、wall-clock time、token cost。当用户纠正答案时，把纠正变成 reference-doc fix 和新 eval。用 ablations：同一组 evals 在 guidance change 前后跑，证明改动是否真的有帮助。
之前漏掉的文章概念Anthropic 的 validation 不是“写一些 tests”这么简单。它包括 human-validated evals、grounded snapshots、telemetry-style result storage、launch gates、ablations、online provenance、passive monitoring、correction harvesting。
| Validation Concept | 通俗意思 | Hooray 学习例子 |
|---|---|---|
| Claude can generate eval candidates; humans validate them | Claude 可以起草 dashboard-based 和 long-tail questions，但 expected behavior 需要人确认。 | Claude 可以提出 “How is FP-B2P performing?” 作为 eval。Product/Ops 必须确认 expected answer 是 “block until identity resolution”。 |
| Anchor ground truth | live-number evals 会 drift。要 pin snapshot dates，或评估 query/source path，而不只评估 final number。 | Lazada eval 应该 pin 住 MAX_REPORT_DATE = 58395-06-15 这条 profile row，而不是依赖今天 live max date 变成什么。 |
| Grade the path when the number moves | 如果底层业务数字每天变化，就不要只 grade 一个会 stale 的 number，而要 grade AI 是否选了正确 model、filters、grain 和 blocker。 | profit eval 应该 assert：AI 使用 Product/Ops identity resolution 和 fct_finance_item_metric_daily，避开 old profit tables，并且在 Finance-owned profit rollup 缺失时 block。 |
| Dependency-aware CI | 如果 PR touched model、metric、resolver 或 skill，就应该 rerun affected evals，而不是之后靠人工 audit。 | 如果 fct_finance_item_metric_daily 改了，应该 rerun finance/profit evals，以及依赖 finance item grain 的 Product/Ops identity evals。 |
| Ablate changes | 固定 eval set，只改变一个因素，再比较 pass rates。 | 如果加 old dashboard SQL retrieval 对 FP-B2P 或 profit answers 没有帮助，说明 bottleneck 是 structure，不是缺更多 examples。 |
| Store eval results like telemetry | 每次 run 都写入 warehouse table，记录 skill version、git SHA、model ID、eval ID、assertion results、source path、token count、wall-clock time。 | 这样 “new finance skill 有没有帮助？” 就变成查询 eval history，而不是争论一次 test run。 |
| Provenance footer | 每个答案显示 source tier、freshness、owner，帮助用户判断能不能信。 | “Source: fct_finance_item_metric_daily plus Finance-owned profit rollup. Freshness: report date 2026-06-06. Owner: Finance. Identity: Product/Ops resolved listing.” |
| Correction harvesting | 用户纠错要变成 reference-doc fixes 和 new evals。 | 如果同事说 “wrong table; this should exclude seller X”，这应该产生 doc update 和 eval，而不是消失在聊天记录里。 |
| Silent failure mitigation | 最难发现的是看起来合理、但没人纠正的错误答案。 | leadership-bound finance answers 应该要求 provenance、更强 review，以及 human sign-off 后再转发。 |
自测什么让 eval 变得有用，而不是普通讨论题？
答案：它必须有 expected source path、identity grain、stop condition 和 pass/fail criteria。AI 要么遵守了 contract，要么没有。
第二题：如果用户纠正 agent answer，下一步是什么？把 correction 变成 reference-doc fix 和 tied to owning domain 的 new eval。
10. 可信 AI 数据答案长什么样
坏答案“Livatro LVHD7001 昨天 profit 是 $52.50。”
为什么坏：没有 source、没有 metric definition、没有 identity level、没有 date freshness、没有 currency rule、没有说明避开了哪些 legacy tables、没有 confidence boundary。它听起来有用，但用户无法检查隐藏正确性。
更好的答案形状“这个问题的 scope 是 2026-06-06 Amazon US。Livatro LVHD7001 humidifier 这个短语只是 lookup clue。我不会把人类可读商品名当成 source of truth。在声称 SKU-level 或 listing-level profit 前，我需要先把它解析到 canonical Product 360 SKU 和 Amazon US exact listing identities。解析后，我会使用 fct_finance_item_metric_daily，并报告 total_sales_quantity、total_sales_amount、platform_fee、fba_delivery_fee 等 components。如果需要 ledger-line proof，再 drill down 到 fct_finance_ledger_lines。Source tier：CORE finance metric route plus Finance-owned profit rollup。Confidence：product phrase understood，final-profit value not safe until canonical identity and metric rollup are resolved。”
更好的 blocker 形状“在 current_walkthrough_samples extract 里，amazon_listing_mapping row for FP-B2P 显示 account DINGYAO_SC_01、marketplace/domain A1AM78C64UM0Y8、ASIN B0DDTK4PKV、seller SKU FP-B2P、country MX。这是 marketplace-listing evidence。只看这个 sample，我还没有把它解析成 SPU、Product 360 SKU 或 exact listing identity。所以我不应该计算 performance。下一步：运行 Product/Ops identity resolution；如果返回多个 possible listings 或 SKU mappings，就 route mapping repair，或只问缺失的 listing scope。”
差别不是文风。更好的答案把“可信合同”暴露出来。即使用户不懂数仓，也能看懂：AI 解析了什么、计算了什么、避开了什么、还有什么需要 governed definition。
11. 第一阶段实际落地包
Anthropic 的 practical starting point 很小：少数 canonical datasets、几十个 offline evals、一个 thin knowledge skill。对 Hooray 来说，第一阶段应该窄但做扎实，并且从第一天就包含 human ownership 和 maintenance loops。
| Domain | 第一份 Canonical Contract | 第一个 Stop Condition |
|---|---|---|
| Finance/profit | metric-code definitions、official profit rollups、currency rules、Product/Ops identity grain。 | AI 把 old profit table 当第一答案。 |
| Product/Ops identity | SPU、SKU、exact listing identity、seller affiliation、ambiguous mapping statuses。 | 一个词映射到多个 identity levels 或 listings。 |
| Orders/sales | canonical order fact、platform/domain/date conventions、freshness checks。 | invalid future dates 或 catalog/live scope mismatch。 |
| Ads | approved ads facts、attribution window、spend/sales definitions。 | attributed sales 没有 attribution window。 |
| Inventory | snapshot date、included locations/countries、identity grain。 | snapshot missing 或 product/listing identity unresolved。 |
| Operating Piece | Minimum Version | 为什么属于第一阶段 |
|---|---|---|
| Human definition owner | 每个 top metric 都有 named Finance/Product/Ops owner。 | Claude 可以 draft docs，但 human 必须 own business definition。 |
| Metadata contract | source tier、grain、owner、freshness、valid dimensions、deprecated status。 | agents 需要 legible warehouse products，而不是只看到 tables。 |
| Skill maintenance trigger | model 或 metric changes 必须触发 reference-doc/eval review。 | skills 如果不和 engineering workflow 绑定，就会 decay。 |
| Provenance footer | 每个答案报告 source tier、freshness、owner、identity grain、confidence boundary。 | 帮助非数据专家判断答案是否可以信任或需要 escalate。 |
| Correction loop | corrections 变成 doc updates 和 new evals。 | 没有这个 loop，同一个错误答案以后还会回来。 |
自学要点数据团队的工作不是让每张 warehouse table 都更方便 AI 浏览。真正的工作是让正确答案路径无法错过，让错误路径难以触达，并让每个答案都带有足够 provenance，让业务用户可以信任或挑战它。
Done means：每个 launch domain 至少有一个 answered example、一个 blocked example、一个 human definition owner、一个 canonical source path、一个 identity-grain rule、一个 metadata contract、一个 maintenance trigger、一个 provenance footer shape，以及一个能抓住最诱人错误答案的 eval。
12. 数据团队必须记住的 Takeaways
如果数据团队只记住 Anthropic 文章里的一件事，应该是：self-service AI analytics 不是给 agent 更多 tables。真正的解法是把正确业务路径变成 owned、documented、enforced，并且不容易和 near-duplicates 混淆。
这两段 quote 是连接在一起的，但不是完全同一个层面。canonical datasets 那段是 model-design rule：减少 plausible truth paths。documentation 那段是 operating rule：即使 Claude 帮忙 draft docs，也必须让这些 truth paths 保持 legible、current，并由 human owner 负责。
| Takeaway | 它是什么意思 | Hooray 应该建设什么 |
|---|---|---|
| 少数 governed models，比更多 accessible tables 更重要。 | agent 不应该在几十张看起来都像 revenue、profit、orders、ads、inventory 的表里浏览。它应该找到一条 governed answer path。 | 为 finance、Product/Ops identity、orders、ads、inventory 各自 curate 小而清晰的 canonical datasets。把 old report tables 标成 deprecated、diagnostic，或 unsafe for first-answer analytics。 |
| Claude 可以 draft docs；human 必须 own definitions。 | Claude 很适合起草 column descriptions、总结 query patterns、提出 metric docs、发现缺失文档。但 Claude 不应该决定 profit、revenue、contribution margin、active listing、sellable inventory 的正式定义。 | 给 top metrics 和 identity rules 指定 human owners。当 metric definition、grain、currency rule、inclusion rule 或 Product/Ops identity behavior 改变时，必须有 owner approval。 |
| Documentation 必须由 tooling 强制执行。 | 一个 wiki 写着 “use official model” 不够。只要系统没有强制 route，agent 和人都会回到熟悉的 old tables。 | 建立 agent-safe routing layer：semantic metrics first、canonical models second、approved mechanical rollups third、diagnostics only with explicit purpose。CI 应该拦住 undocumented、ownerless 或 conflicting models。 |
| Lineage 把 “我不知道 metric” 变成 “我知道 governed model”。 | 如果 semantic metric 缺失，agent 也不应该 random search。dbt lineage 和 model reference counts 可以帮助判断哪个 upstream model feeds 这个 concept、哪些 models share grain、哪些 path 已 deprecated。 | 把 dbt lineage、model tier、ownership、deprecation status、grain、reference count 暴露给 agent。reference count 只能当 signal，不能当 truth，因为旧 legacy tables 也可能被大量引用。 |
| Rollups 和 caches 只有作为 mechanical copies 才安全。 | fast summary 只有在从 canonical model、同一 metric version、同一 grain、同一 refresh rule 机械生成时才安全。否则它就是 shadow source of truth。 | 每个 rollup 都声明 parent canonical model、metric version、grain、refresh cadence 和 owner。如果不能 trace back，就不要暴露给 first-answer analytics。 |
| 每个答案都需要 provenance，因为用户无法验证隐藏正确性。 | 业务用户不应该负责判断 agent 是否选对 warehouse path。答案本身必须暴露 source、freshness、owner、identity grain、confidence 和 blockers。 | 为 finance、product identity、orders、ads、inventory 标准化 answer footer。没有 provenance 的 high-impact answer 应该被视为 incomplete。 |
| Corrections 必须变成 system improvements。 | 如果用户说 “wrong table” 或 “wrong definition”，这不能只是一次 chat correction。它必须更新 docs、routing、evals 或 ownership metadata。 | 建立 correction loop：每个有意义的 correction 都产生 reference-doc change、new eval，或 deprecation/ownership fix。 |
最终标准一个 model 不是因为存在、名字好、或被经常 query，就已经 agent-ready。只有当它有 owner、grain、source tier、lineage、freshness rule、allowed-use rule、alternatives 的 deprecation status，以及能抓住最诱人错误答案的 eval coverage，它才是 agent-ready。