用途：把语义层接入 nao 智能体，让指标查询以语义层为权威来源，而不是让智能体从原始表直接计算指标。仅当 nao test 显示智能体在指标可靠性上有问题后才添加，不要提前加。它能提升可靠性与稳定性（每个指标只有一种定义），但会缩小可回答问题的范围，层外问题更难甚至无法回答；若失败集中在 schema 缺失或日期逻辑，应先修 RULES.md。语义层是智能体读取后自行写 SQL 的文件（md/yaml），指标存储则是通过 API 调用（如 query_metric(...)）由框架转 SQL，dbt MetricFlow Cloud 属指标存储。
选型：dbt MetricFlow（已启用 dbt Cloud 语义层）；Snowflake 视图/原生语义视图；nao 语义文件（无现成层时用轻量仓库内 YAML）；其他如 Looker/LookML、Cube、AtScale。
用法：dbt MetricFlow 需在 .claude/mcp.json 加 dbt-mcp，命令为 uvx，参数为 dbt-mcp，并配置 DBT_HOST、MULTICELL_ACCOUNT_PREFIX、DBT_TOKEN、DBT_PROD_ENV_ID 等环境变量；DBT Token 放 shell 而非文件；重启会话后用 list_metrics 验证 MCP。dbt Core 本地版不支持。Snowflake 需加 mcp-server-snowflake，配置 SNOWFLAKE_ACCOUNT、SNOWFLAKE_USER、SNOWFLAKE_PASSWORD、SNOWFLAKE_WAREHOUSE、SNOWFLAKE_DATABASE、SNOWFLAKE_SCHEMA、SNOWFLAKE_ROLE；原生语义视图用 Cortex MCP 变体并设 SEMANTIC_VIEW。无现成层时用 semantics/semantic.yaml 单文件，先列维度（名称、类型、描述、分类值）再列核心指标（名称、定义、来源表列与聚合、粒度、维度、过滤），模板为 templates/semantic.yaml。
验证与后续：确认每个关注指标在 RULES.md 有路由规则，用 nao chat 验证使用语义层，再用 nao test 与接入前基线通过率对比。无测试则 create-context-tests；可靠性下降则 audit-context；否则 write-context-rules。限制：不要直接写 RULES.md，需交由 write-context-rules；凭证不要写入 .claude/mcp.json，用 ${ENV_VAR}，敏感内容加入 .gitignore；Path D 不要虚构指标，只编码用户定义的内容；一次只用一个语义层。