looker-architect

Looker 架构师

这项主开发技能规范了企业级 LookML 项目的构建、重构、验证和审计生命周期。它基于 Google 内部用于构建官方 Looker Blocks 的架构标准、设计原则和最佳实践，帮助开发者构建达到 Block 质量标准的分析应用。它强制实行严格的关注点分离、性能优先设计、自动化测试和全面文档编写。

在此技能下开发的所有 LookML 项目都必须与方言和架构无关，并兼容任何数据库连接。它们必须严格遵循最高标准的 LookML、Google Cloud 最佳实践和企业数据治理指南。

---

1. 标准项目结构

每个 LookML 项目必须遵循以下简洁、模块化的目录结构，以确保可维护性、支持可靠的版本控制并防止编译膨胀：

├── views/
│   ├── raw/                 # Raw views mapping 1:1 to physical database tables
│   │   ├── [view_name].view.lkml
│   └── refined/             # Refined views (extends/refines raw views with business logic)
│       └── [view_name]_rfn.view.lkml
├── explores/                # Modular Explore files (one explore per file: *.explore.lkml)
│   └── [explore_name].explore.lkml
├── tests/                   # LookML test suites (one suite per explore: *.test.lkml)
│   └── [explore_name].test.lkml
├── dashboards/              # LookML dashboard files (*.dashboard.lookml)
│   └── [dashboard_name].dashboard.lookml
├── [project_name].model.lkml # Clean model file (connection constant, caching, and includes only)
├── manifest.lkml            # Defines constants (connection, dataset, and visualization configs)
├── README.md                # End-user documentation (installation, PDT config, KPIs)
├── LICENSE                  # Apache 2.0 or standard open-source license
└── CONTRIBUTING.md          # Guidelines for contributing to the project

---

2. 工作模式（从零构建与基于现有项目改进）

Looker 架构师技能会根据代码库的状态采用两种不同的模式。无论采用哪种模式，Agent 都必须遵循强制 PRD 审核清单与全面覆盖规则：

重要

强制 PRD 审核清单与全面覆盖规则：在编写任何代码之前，Agent 必须阅读并分析提供的所有外部文档 URL（包括 Google Docs PRD、数据库架构规范和数据库方言手册）。Agent 必须编制并撰写一份具体的完整性清单，列出所有必需的仪表板、标签页、图块、指标和视图。

此外，Agent 必须将高级建模标准（自定义可视化钻取、值格式设置和周期环比）应用于为项目创建的100% 的视图、度量和仪表板图块。严禁选择性地应用这些标准（例如，仅应用于主视图，而将次要视图保留为未经格式化的样板），也严禁走捷径。

模式 A：从零构建（从头开始的新项目）

开始全新项目时使用此模式。遵循完整的 8 步开发工作流：

1. 使用非交互式 ./looker_scaffold.py 脚本初始化目录结构（确保项目名称与 Looker 实例中的目标项目名称一致）。
2. 获取架构详情，将原始表映射到 views/raw/，并在 views/refined/ 中分层构建业务逻辑。
3. 设置模块化 Explore，为主键唯一性编写单元测试，并构建原生标签页式仪表板。
4. 确保所有关键 KPI 记分卡都实现双度量周期环比模式，且所有核心度量都使用 manifest 常量实现高级可视化钻取链接。

模式 B：棕地项目（审计、重构与升级现有项目）

在审查或改进现有 LookML 项目时使用此模式。Agent 必须执行以下审计与重构流程：

1. 分析现有结构：使用 looker-cli 或 Looker MCP（get_project_files、get_project_file）检查当前启用的 LookML 文件。
2. 检测偏差：识别违反以下标准的情况：
   • 模型文件中直接包含数据库列或 SQL 计算（explore 必须模块化，并位于 explores/ 目录中）。
   • 缺少 raw/refined 文件夹分离（例如，在单个 view 文件中混合 raw 列与度量）。
   • 缺少符合功能顺序的字段排列（例如，度量定义在维度之前）。
   • 度量使用 SQL 聚合函数，而非 Looker 原生 type 参数。
   • 仪表板使用过时的 HTML 导航菜单，而非原生 tabs。
   • 缺少用于验证主键的单元测试。
   • 核心计数和指标度量缺少高级可视化钻取链接。
   • Key KPI 的 single_value 仪表板图块缺少同比/环比（PoP）比较模式。
3. 精确重构：启动专用子 Agent，对文件进行原位重构：
   • 将混合视图拆分至 views/raw/（直接的一对一列）和 views/refined/（包含度量的细化视图，并通过 ${field_name} 继承元数据）。
   • 按字段顺序规则重新排列字段（键 ➔ 维度 ➔ 度量 ➔ 过滤器 ➔ 集合）。
   • 将 SQL 聚合替换为 Looker 原生类型，并添加安全的 NULLIF 除法。
   • 使用清单常量和空钻取字段，为所有核心度量注入高级可视化钻取链接（例如趋势图、圆环图、网格明细表）。
   • 将 HTML 仪表板导航菜单转换为原生 Looker 选项卡式布局（tabs: 和 tab_name:），并将每个选项卡的网格坐标重置为 row: 0, col: 0。
   • 将 single_value 仪表板图块转换为双度量 PoP 比较模式，查询 pop_*_current 和 pop_*_change 度量，并将过滤器映射至 explore 的 pop_date_filter。
4. 验证：运行服务端验证（looker-cli project validate 或 MCP health_analyze），确保重构后的项目编译无误且不存在语法错误。
5. 运行时 SQL 执行审计与架构协调：服务端编译只检查 LookML 语法，不检查数据库兼容性。Agent 必须启动自修复 SQL 循环，审计并修复执行时的查询崩溃问题。请参阅专用手册 references/sql_runtime_debugging.md 中定义的完整调试流程、循环协议和特定方言的修复方法。
   • 提取并运行查询：对于 LookML 仪表板中的每个图块，使用 Looker MCP 的 run_dashboard 或 query 工具生成底层 SQL 查询，并在目标数据库上执行。
   • 捕获执行崩溃：捕获任何运行时数据库错误（例如 gRPC Name query_text not found 或 SQL 语法/类型强制转换错误）。
   • 协调并修复：与数据库架构进行核对（通过 MCP get_connection_table_columns），精确修改 LookML 视图以映射到正确的列，调整 SQL 转换以匹配目标方言，并反复验证，直到查询返回 HTTP 200（成功检索数据）。

---

3. 核心开发工作流

构建企业级 LookML 项目需遵循严格的 8 步生命周期：

1. 上下文摄取：分析用户数据仓库中的源数据库架构、表关系和摄取级别（快照、实时数据、事务日志）。
2. 访谈：针对用户的业务目标、核心 KPI、筛选要求和主要受众（高管记分卡还是临时分析人员）提出有针对性的问题。
3. 实例检查（Looker MCP 与 CLI）：
   • 连接到 Looker 实例，并将会话切换到开发模式：

     looker-cli session login --oauth --host <your-looker-domain.com>
     looker-cli session update dev
     

   • 检查现有视图、Explore 或连接，使新项目与当前实例架构保持一致。
4. 脚手架与样板代码生成：
   • 使用本地 Python 工具 looker_scaffold.py 自动生成标准目录结构、参数化的 manifest.lkml、简洁的 .model.lkml、带主键的原始视图，以及预先填入功能性排序标题的精细视图。
5. 实现与仪表板转换：
   • 在精细视图和 Explore 中编写 LookML 代码。
   • 对于高级功能，请参考专门的文档进行实现：
     • 周期对比引擎：参阅 pop_engine.md（与方言无关的单 Explore 模式）。
     • 可视化钻取：参阅 visual_drilling.md（钻取路径和可视化链接）。
     • 聚合感知：参阅 aggregate_awareness.md（缓存和数据库汇总）。
   • 如果用户在 Looker 浏览器中设计了可视化仪表板（UDD），请将其导出并转换为版本控制的 LookML 仪表板，存放在 dashboards/ 目录中：

     looker-cli api dashboard dashboard_lookml <dashboard_id> > dashboards/<dashboard_name>.dashboard.lookml
     

6. 测试与服务端验证：
   • 在 tests/ 中编写自动化 Explore 测试，以验证主键和业务计算。参阅 testing_suite.md。
   • 务必在提交代码前，使用 Looker 服务端编译器验证 LookML，确保没有错误：

     looker-cli project validate <project_name>
     

7. 文档：生成公开的 README.md 文件，详细说明安装步骤、PDT 重建频率和 KPI 定义。
8. 部署：将代码推送到 GitHub（通过 gh 凭据助手完成身份验证），合并到 main，并触发生产环境部署：

   looker-cli project deploy <project_name>
   

---

4. LookML 建模标准（黄金法则）

规则 1：集中管理连接与数据集常量

切勿在模型或视图文件中硬编码连接名称或数据集名称。始终在 manifest.lkml 中使用 override_optional 导出设置对其进行参数化，以便用户在安装区块或部署时覆盖这些值。

manifest.lkml：

project_name: "my_lookml_project"

constant: CONNECTION_NAME {
  value: "my_connection"
  export: override_optional
}

constant: DATASET_NAME {
  value: "my_dataset"
  export: override_optional
}

views/raw/users.view.lkml：

view: users {
  # References the dataset constant
  sql_table_name: @{DATASET_NAME}.users ;;
  # ...
}

my_model.model.lkml：

# References the connection constant
connection: "@{CONNECTION_NAME}"

---

规则 2：高级钻取与可视化常量库（核心指标必需）

为了提供优质、高度交互的用户体验，同时避免视图文件中出现大量重复的 JSON 代码块，请在 manifest.lkml 中定义集中的 可视化钻取常量。

• 核心指标必须配置钻取：精细化视图中的每个核心度量和计数指标（例如总销售额、交易笔数、错误率）都必须实现至少 2-3 个自定义可视化钻取链接（例如趋势折线图、分布环形图、带样式的明细网格表），并使用 manifest 常量。
• drill_fields 的特殊要求：Agent 必须在度量上定义一个空数组 drill_fields: []，以强制 Looker 前端在 UI 中激活超链接。没有此参数，自定义链接将不会显示。
• 动态可视化钻取：请参阅专门手册中的完整实现示例和 URL 参数：references/visual_drilling.md。

manifest.lkml：

constant: DRILL_COLUMN_VIZ {
  value: "{% assign vis_config = '{
    \"type\": \"looker_column\",
    \"x_axis_gridlines\": false,
    \"y_axis_gridlines\": true,
    \"show_view_names\": false,
    \"show_y_axis_labels\": true,
    \"show_y_axis_ticks\": true,
    \"show_x_axis_label\": true,
    \"show_x_axis_ticks\": true,
    \"stacking\": \"\",
    \"show_value_labels\": true
  }' %}"
}

views/refined/users_rfn.view.lkml：

view: +users {
  dimension: country {
    type: string
    sql: ${TABLE}.country ;;
    
    # References the visualization constant, passing dynamic filter values
    link: {
      label: "📊 Country Connection States (Bar)"
      url: "@{DRILL_COLUMN_VIZ}{{ link }}&fields=users.state,users.total_connections&f[users.country]={{ value | url_encode }}&sorts=users.total_connections+desc&limit=10&toggle=vis"
    }
  }
}

---

规则 3：严格划分职责（原始视图与精细化视图）

• 原始视图（views/raw/）：与物理数据库表一一对应。仅包含直接映射到列的原始维度。不得定义度量、标签或复杂业务逻辑。主键必须是文件中定义的第一个维度。
• 精细化视图（views/refined/）：使用精细化语法（view: +view_name）叠加业务逻辑。在这里编写度量、标签、描述、分组标签、同比/环比计算引擎和自定义计算。
• 原因：如果数据库架构发生变化，只需重新生成原始视图，不会破坏或要求重写精细化视图中未受影响的业务计算。

---

规则 4：视图字段排序（排序规则）

为提高可读性，任何精细化视图文件中的字段都必须按以下功能顺序从上到下排列：

1. 键：主键（primary_key: yes）和外键。
2. 维度：标准属性（例如名称、状态、类别）。
3. 度量：聚合指标（例如总计、平均值、计数）。
4. 筛选器和参数：用于捕获动态参数的用户输入字段。
5. 集合：可重复使用的钻取字段列表。

内部排序：每个类别中的字段应按字母顺序（A-Z）排列，或按分组标签（group_label）进行逻辑分组。

---

规则 5：替换运算符继承（${field_name}）

定义度量或复合维度时，始终使用 LookML 替换运算符 ${field_name}，而不是原始 SQL 列 ${TABLE}.field_name。

• 正确：

  dimension: sale_price {
    type: number
    sql: ${TABLE}.sale_price ;;
    description: "售出商品的单价。"
    value_format_name: usd
  }
  
  measure: total_revenue {
    type: sum
    sql: ${sale_price} ;; # 继承元数据（描述、格式、类型）
  }
  

• 错误：

  measure: total_revenue {
    type: sum
    sql: ${TABLE}.sale_price ;; # 绕过 LookML 层，丢失元数据
  }
  

• 原因：引用 LookML 字段 ${sale_price} 可确保度量继承其所有格式、描述和元数据。如果数据库中的列名发生变化，只需在基础维度中更新一次即可。

---

规则 6：Looker 原生聚合（防止扇出）

始终使用 Looker 原生的 type 参数进行聚合（例如 type: sum、type: average、type: count），而不是直接在 sql: 参数中编写聚合函数（例如使用 type: number 和 sql: SUM(col)）。

• 正确：

  measure: average_benchmark {
    type: average
    sql: ${benchmark_dynamic} ;; # Looker 原生知道这是平均值
  }
  

• 错误：

  measure: average_benchmark {
    type: number
    sql: AVERAGE(${TABLE}.benchmark_dynamic) ;; # 绕过聚合引擎
  }
  

• 原因：在 SQL 中编写聚合函数，会导致 Looker 编译器在连接具有一对多关系的表时无法运行对称聚合，从而造成计算错误和数据扇出。

---

规则 7：命名约定和度量后缀

• 所有 LookML 对象（视图、探索、维度、度量、集合）都使用 snake_case（小写字母和下划线）。
• 度量后缀：为确保清晰，请为聚合使用特定后缀：
  • 对计数和去重计数度量使用 _count 或 _total（例如 user_count、active_users_total）。
  • 对求和度量使用 _total 或 _amount（例如 revenue_total、discount_amount）。

---

规则 8：安全数学运算、比率计算和强制值格式

• 安全除法：始终保护除法计算，避免出现除以零错误。使用适合相应方言的安全数学运算（例如，BigQuery 使用 SAFE_DIVIDE(num, den)，Snowflake/Redshift 使用 num / NULLIF(den, 0)）。
• 聚合比率：只对最终聚合指标应用比率。切勿直接聚合比率。
  • 正确：

    measure: conversion_rate {
      type: number
      sql: 1.0 * ${orders_count} / NULLIF(${sessions_count}, 0) ;; # 先聚合，再相除
      value_format_name: percent_1
    }
    

  • 错误：

    measure: conversion_rate {
      type: average
      sql: ${TABLE}.conversion_rate ;; # 聚合比率在数学上无效
    }
    

• 强制值格式：未格式化的原始数字（例如，在仪表板可视化中显示 0.072826486327）显得很不专业，也会使界面杂乱。精细视图中的每个计数、求和、平均值、比率或大小度量都必须定义清晰易读的格式参数：
  • 百分比和比率：使用 value_format_name: percent_1（例如 7.3%）或 percent_2（例如 7.28%）。
  • 标准平均值和小数：使用 value_format_name: decimal_2（例如 12.34）或 decimal_1（例如 12.3）。
  • 大整数：使用 value_format_name: decimal_0 或 integer，以强制显示千位分隔符（例如 1,234）。
  • 货币：使用 value_format_name: usd（例如 $1,234.56）或 usd_0（例如 $1,234）。
  • 自定义单位（延迟、大小、带宽）：使用 value_format 和自定义格式字符串，在数值后附加清晰的单位：
    • 延迟（秒）：value_format: "#,##0.00 \"s\""（将 0.0728 格式化为 0.07 s）。
    • 延迟（毫秒）：value_format: "#,##0.0 \"ms\""（将 72.82 格式化为 72.8 ms）。
    • 数据大小（GB）：value_format: "#,##0.00 \"GB\""（将 12.345 格式化为 12.35 GB）。
    • 行数：value_format: "[>=1000000]#,##0.0,,\"M\";[>=1000]#,##0.0,\"K\";#,##0"（将 1500000 格式化为 1.5M，将 2500 格式化为 2.5K）。

---

规则 9：联接裁剪与 Explore 治理

• 在 Explore 中集中定义联接：避免创建使用 SQL 联接物理表的 SQL 派生表。应在各自的视图中定义每张表，并使用 LookML 联接参数在 Explore 中联接这些表。
  • 原因：这有助于实现联接裁剪（Looker 仅查询所选字段所需的表，从而提升数据库性能）、简化维护，并确保对称聚合能够防止扇出。
• 每个文件仅定义一个 Explore：在 explores/ 下为每个 Explore 单独创建文件（例如，explores/orders.explore.lkml）。
• 保持模型文件整洁：.model.lkml 文件只能包含连接常量、缓存策略（数据组）以及 Explore 和信息中心的包含项。不得在模型文件本身中定义 Explore。

---

规则 10：原生选项卡式信息中心与 PoP KPI 对比（禁止使用 HTML 导航）

• 标准：对于复杂的多主题信息中心套件，应使用原生 Looker 选项卡式信息中心（tabs 元数据参数），将所有元素打包到单个 .dashboard.lookml 文件中。
• 禁止事项：严禁编写自定义 HTML 文本磁贴作为导航菜单。始终使用 Looker 原生的 tabs 参数。
• 独立网格坐标：Looker 选项卡式信息中心中的每个选项卡都使用独立的 24 列网格坐标系，起始位置为 row: 0, col: 0。设计布局时，新选项卡中的元素必须将 row 和 col 值重置为 0。
• 必须使用 PoP KPI 磁贴：所有关键 KPI 磁贴（类型：single_value 记分卡）都必须采用逐期（PoP）对比模式。它们必须恰好查询两个字段（当前期度量和百分比变化度量）、启用对比设置（show_comparison: true 和 comparison_type: change），并将其筛选器映射到 Explore 的 PoP 日期筛选器（pop_date_filter）。LookML 示例请参阅 references/dashboard_standards.md。

---

规则 11：禁止使用硬编码／虚拟计算（严格遵守）

编译 LookML 只会验证语法，不会检查计算在数学或逻辑上是否合理。为防止创建无法正常工作的“虚假”项目，Agent 必须严格遵守以下规则：

• 严格禁止：严禁在度量中写入硬编码数值常量、虚拟百分比或静态模拟值（例如，sql: 0.05 ;;、sql: 0.15 ;;、sql: 1 ;;），尤其是在逐期百分比变化指标中。
• 动态计算：每个度量和维度都必须表示真实的数据库聚合，或基于底层字段的数学上有效的动态计算。
• 真实的逐期逻辑：对于所有逐期变化度量，Agent 必须实现数据库级别的实际时间范围对比 SQL 逻辑。必须采用以下任一方式：
  1. 使用 references/pop_engine.md 中定义的单 Explore PoP 引擎（该引擎使用 Looker 筛选器动态比较当前期和前一期）。
  2. 编写有效的数据库级 SQL CASE WHEN 表达式，动态比较当前期聚合值与前一期聚合值。
  • 在任何情况下，Agent 都不得编写模拟数值或静态虚拟数值来绕过编译器验证。

---

5. Looker CLI 与 MCP 工具手册

为了管理 LookML 项目的生命周期，AI Agent 必须使用 Looker CLI（looker-cli）或 Looker MCP 服务。通过编程方式与当前运行的 Looker 实例交互时，优先使用 Looker MCP 服务。以下列出了核心操作及其对应的 CLI 命令和 MCP 工具：

1. 会话与工作区管理

进行任何编辑前，请确保开发会话处于活动状态，并已切换到 Developer Mode。

• Looker CLI：

  looker-cli session update dev
  

• Looker MCP：调用 dev_mode 工具：

  { "state": true }
  

2. 数据库检查与元数据获取

在映射列或规划联接前，直接从数据库获取表详情和架构。

• Looker MCP：
  • 列出连接中的表：get_connection_tables
  • 列出表列：get_connection_table_columns（例如，{"connection_name": "my_conn", "table_name": "users"}）

3. 项目生命周期与文件管理

在活动的 Looker 项目中创建和修改 LookML 文件。

• Looker CLI：

  looker-cli project create <project_id>
  looker-cli project checkout <project_id> <branch_name>
  

• Looker MCP：
  • 列出项目中的文件：get_project_files（例如，{"project_id": "my_project"}）
  • 读取指定文件：get_project_file（例如，{"project_id": "my_project", "file_id": "views/raw/users.view.lkml"}）
  • 创建新文件：create_project_file（例如，{"project_id": "my_project", "file_id": "views/refined/users_rfn.view.lkml"}）
  • 更新文件内容：update_project_file（例如，{"project_id": "my_project", "file_id": "views/refined/users_rfn.view.lkml", "content": "..."}）

4. LookML 质量与服务端验证

部署前，请验证 LookML 能否在 Looker 服务端完美编译。

• Looker CLI：

  looker-cli project validate <project_id>
  

• Looker MCP：调用健康检查和验证工具：
  • 分析项目健康状况：health_analyze（例如，{"project_id": "my_project"}）
  • 脉冲检查：health_pulse

5. 将可视化仪表板转换为 LookML

将用户在 Looker UI 中设计的可视化仪表板导入代码。

• Looker CLI：

  looker-cli api dashboard dashboard_lookml <dashboard_id>
  

• Looker MCP：
  • 获取仪表板列表：get_dashboards
  • 获取仪表板详情：run_dashboard

6. 生产环境部署

将所有已验证的更改部署到生产环境。

• Looker CLI：

  looker-cli project deploy <project_id>
  

---

6. AI Agent 执行与子 Agent 委派指南

为了优化执行速度、防止令牌膨胀，并避免触及 Agent 环境中的轮次或上下文限制，请遵循以下执行策略：

1. 非交互式脚手架搭建

初始化项目时，主 Agent 必须在终端中使用 Unix 输入管道，以非交互方式执行 looker_scaffold.py 脚本（例如，echo -e "..." | python3 looker_scaffold.py）。直接从用户的自然语言提示中提取项目参数（名称、连接、方言、表）。不要暂停终端并询问用户输入。

• 名称对齐：Agent 必须将 Looker 实例的准确目标项目名称（例如，operational-intelligence-cloud-sql）传递给脚手架脚本，以确保本地目录结构以及 LookML 模型/项目名称与 Looker 实例完全一致，避免本地与远程名称不匹配。

2. 通过子 Agent 并行拆分仪表板

编写包含多个标签页的大型仪表板可能耗时较长，也会消耗大量令牌。主 Agent 必须拆分仪表板创建流程：

1. 定义布局与标签页：主 Agent 设计仪表板的整体结构并确定标签页（例如：标签页 1：概览，标签页 2：详情）。
2. 启动专用子 Agent：为定义的每个标签页启动一个专用的通用型子 Agent。
3. 指示子 Agent：要求每个子 Agent 只编写其负责的标签页所包含的 LookML 元素。强调必须使用正确的 tab_name 参数，并从 row: 0, col: 0 开始设置独立的网格坐标。
4. 合并与编译：所有子 Agent 返回各自的 LookML 元素数组后，主 Agent 将其编译到 elements 数组中，定义全局 tabs 元数据数组，并一次性写入最终的 .dashboard.lookml 文件。

3. 自主精准重构

如果服务器端验证检查（looker-cli project validate）返回编译、连接或语法错误，主 Agent 应该将调试循环委派给专用子 Agent。子 Agent 将精准编辑相关文件，在本地重新运行验证器，并且仅在构建结果完全通过后才汇报，以便让主对话保持专注和高效。

4. 运行时 SQL 调试循环（借助 MCP）

如果仪表板查询在数据库上返回执行时错误（例如，找不到列、类型强制转换不匹配、方言函数无效）：

1. 委派给子 Agent：主 Agent 必须将 SQL 调试循环委派给专用子 Agent。
2. 遵循自愈协议：子 Agent 必须使用 Looker MCP 工具，打开并严格遵循 references/sql_runtime_debugging.md 中定义的自愈 SQL 调试循环、遥测检查清单和数据库方言修复方法。
3. 验证并结束：确认所有查询都能在实时数据库上成功执行（返回 HTTP 200 和数据），并且 LookML 编译时没有语法错误，然后再向主 Agent 汇报。

5. 精准修改规则（禁止完整重写）

为保护开发者注释、保留自定义维度并优化 API 令牌效率，Agent 必须遵守以下精准编辑协议：

• 禁止完整重写：在对现有 LookML 或仪表板文件进行任何重构、自愈或调试迭代时，Agent 不得从头重写、重新生成或重构整个文件，也不得生成从头重写文件的全局 Python 脚本。
• 定向替换代码块：Agent 必须执行精准的局部代码块替换（例如搜索并替换、按行定向编辑或定向调用工具），只修改*具体出错或不匹配的代码行。
• 保留内容：无关的维度、度量、Explore 连接和开发者编写的注释必须完全保持不变。