企业官网建设流程全解析

OpenMetadata Connector 深度可靠性审计技能（connector-audit）：从 7 轮侦查到可执行修复的完整工作流

【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata

本文系统讲解 OpenMetadata 仓库内置的connector-audit审计技能：它如何以 7 个独立提示词（P0 环境准备、P1–P5 并行侦查、P6 综合、P7 实施）对一个 connector 做小时级的深度可靠性审计，并产出评级、file:line 证据、根因聚类与 PR 实施计划。读完你将领会该技能的设计哲学（静态预检打底、并行侦查、用户评审门禁、根因聚类、dry-run 先行），并能直接用它审计 MySQL、Snowflake、Tableau 等任意 connector，或把这一套"分级标准 + 乐观陷阱清单 + 评级校准规则"迁移到自己的数据管线质量体系中。

技能定位：connector-audit 与 connector-review 的分工

OpenMetadata 的技能目录中，connector 质量检查分成了两套互补体系。connector-audit面向"深度可靠性调查"（Deep reliability audit），适合在对一个 connector 做重大改动之前，用小时级分析把问题查清楚；而connector-review面向 PR 的广度检查，用 5 个并行 Agent 在几分钟内扫一遍变更文件。两者的区别在 SKILL.md 中有明确的对照表：

触发与参数

当用户要求"审计某个 connector""做可靠性审计"或"深入调查 connector 质量"时，激活本技能。支持以下参数（见 SKILL.md）：

• connector 名称（如mysql、snowflake、tableau）：执行完整 7 提示词审计；
• --prompt N：只运行第 N 个提示词（1–7），适合修复后重跑单项；
• --prompts N,M：只运行指定提示词子集；
• --from N：从第 N 个提示词跑到 7，适合完成 P1–P5 后继续；
• --setup-only：只做环境准备（写入 connector-audit.json）；
• --dry-run：仅与 P7 配合，产出详细实施计划（before/after diff、测试、风险标记）供评审，不写任何代码。

典型调用：

/connector-audit mysql /connector-audit mysql --prompt 3 /connector-audit mysql --from 6 /connector-audit mysql --setup-only /connector-audit mysql --prompt 7 --dry-run

第一步：陈旧结果检查（必须先做）

技能的第一步是强制的陈旧结果门禁（Step 1）：无论用户想做什么，激活技能后必须先列出.claude/audit-results/（若存在）与.claude/connector-audit.json（若存在），展示给用户并询问"这些文件来自之前的审计，保留哪些、删除哪些？"，等待用户回答后才能继续。

这条规则背后是严格的执行纪律：绝不允许对既有结果做摘要、声称"审计已完成"、或暗示用户无需再跑。用户既然激活了技能，就必须真正执行审计，而不是复用旧结论。

工作流总览：Setup → P1–P5（可并行）→ P6 → P7

Setup → P1-P5 (investigation, parallelizable) → P6 (synthesis) → P7 (implementation)

整个流程分五个阶段，审计对象是ingestion/src/metadata/ingestion/source/{service_type}/{connector}/目录下的 connector 实现，同时会延伸阅读同服务类型的基类与共享框架代码。

Phase 1：环境准备（P0）

P0（00-setup.md）负责建立审计上下文：

1. 若参数未给出 connector 名称，先询问用户；
2. 在ingestion/src/metadata/ingestion/source/下定位源码目录，按服务类型（database、dashboard、pipeline、storage、messaging、search、mlmodel、api）归类；
3. 从目录结构确定 service type；
4. 写入上下文文件.claude/connector-audit.json：

{ "connector_name": "<name>", "service_type": "<type>", "source_path": "ingestion/src/metadata/ingestion/source/<type>/<name>/" }

5. 创建.claude/audit-results/目录（若不存在）；
6. 向用户确认 connector 名称、服务类型、源码路径及目录内发现的文件。

后续所有提示词（P1–P7）都会读取这个 JSON 获取[CONNECTOR_NAME]与[SERVICE_TYPE]占位符。

Phase 2：静态预检

运行 connector-review 技能附带的静态分析器，建立机械性基线（机械可查的问题先扫出来，提示词不再重复劳动）：

python skills/connector-review/scripts/analyze_connector.py {service_type} {name} --json

该脚本位于 analyze_connector.py，输出会被保存并在后续提示词中引用；P7 实施完成后还会再次运行它来验证修复效果。

Phase 3：侦查阶段（P1–P5，可并行）

P1–P5 五个提示词相互独立、可任意顺序执行，为提升效率可按如下配对并行派发：

• Pair A：P1（元数据与摄取）+ P2（错误处理）；
• Pair B：P3（连接与认证）+ P4（血缘）；
• Solo：P5（规模与性能）。

每个提示词的执行模式一致：读取connector-audit.json→ 通过/connector-standards加载 connector 标准 → 深读真实源码做分析 → 向用户展示摘要 →用户批准后才把报告写入.claude/audit-results/（固定文件名）。这道"用户评审门禁"是为了让错误在早期被拦截，而不是一路传导到 P6。

Phase 4：综合阶段（P6）

P6（06-refactor-plan.md）读取.claude/audit-results/下全部报告，做交叉验证（跨提示词矛盾消解、文件覆盖率检查）、根因聚类（把同根因的多个发现归并）、git 历史检查（git log --oneline -20 -- <connector_path>判断是否处于活跃开发期、避免动到进行中的代码），最终产出带优先级与 PR 拆分的实施计划。

Phase 5：实施阶段（P7）

P7（07-implementation.md）读取 P6 计划并执行修复——写代码、跑测试、提交 commit；配合--dry-run时只产出详细计划（before/after diff、完整测试代码、风险标记、commit message），不落任何代码。

七大提示词：职责、聚焦点与对应标准

每个提示词都是一份自包含的侦查指南，存放在prompts/目录：

P1：元数据与摄取完整性

P1（01-metadata-ingestion.md）是整个审计中最重的一环，核心观点是：connector 的元数据抽取分散在多个位置，必须全部检查，包括：

1. connector 专属代码：metadata.py、models.py、queries.py、service_spec.py（注册各管线类型对应的类）；
2. 连接 schema：openmetadata-spec/src/main/resources/json/schema/entity/services/connections/{service_type}/{connector}Connection.json，沿$ref追踪可用配置与元数据类型；
3. 服务类型基类（关键）——大量元数据能力在共享基类里：
   • Database：common_db_source.py（文件）— 表/视图抽取、列元数据、描述、属主、标签、yield 模式；
   • Dashboard：dashboard_service.py— yield_dashboard、yield_dashboard_chart、数据模型列；
   • Pipeline：pipeline_service.py— yield_pipeline、yield_pipeline_status、任务抽取；
   • Storage / Messaging / Search / ML Model / API 各有对应的 yield_* 方法；
4. Profiler / Sampler（Tier 3 元数据在这里，不在元数据摄取里）：ingestion/src/metadata/sampler/sqlalchemy/{connector}/与ingestion/src/metadata/profiler/；
5. 共享工具：ingestion/src/metadata/utils/filters.py（schema/table/topic 过滤）、ingestion/src/metadata/ingestion/models/topology.py（TopologyRunnerMixin 实体迭代）。

评估分为两大部分：

Part 1 — 按层级评估元数据覆盖（对每类元数据判定：是否抽取、在哪抽取 file:line、来源是 connector 代码/基类继承/独立管线/不支持、完整性、局限）：

• Tier 1 核心（不可妥协）：实体层级（database→schema→table、dashboard→chart、pipeline→task）、实体类型区分（表/视图/物化视图/外表等是否全部识别）、列/字段元数据、数据模型列（dashboard 类）、描述（实体级+列级，须来自源系统而非用户添加）、运行状态（pipeline 类）、表级血缘、列级血缘；
• Tier 2 预期：属主信息、标签/分类（注意区分源系统无原生标签的情况）；
• Tier 3 差异化：使用统计、Profiling 列统计、数据质量、样本数据（sampler 管线是否支持该 connector）。

Part 2 — 摄取完整性（Standard 1），对每个实体类型逐一核验：分页是否覆盖全部列表操作（含标签、描述、属主、存储过程、视图）、是否存在静默丢弃（continue无日志、except: pass、无警告的条件过滤）、是否使用生成器（而非先全量收集到内存）、用户过滤器是否正确应用、是否支持增量摄取与markDeletedEntities。

**评级校准与"乐观陷阱"**是这套技能最有迁移价值的产出：

• "存在分页"——是否覆盖所有操作？不能只看表；
• "基类处理了"——检查 connector 是否覆写基类方法导致丢分页或丢实体抽取；
• "有 LIMIT"——LIMIT 而无 offset 循环 = 静默丢弃，是硬上限，不能算分页。文档给出的例子：查询日志表LIMIT 1000而系统每天 5 万条查询，默认配置下 98% 的查询被静默丢弃——即便"可配置"，大多数用户从不改默认值，因此摄取完整性评级最低只能是 ⚠️；
• 评级规则：任一列表操作用硬上限且默认值在生产中可能被超过，则摄取完整性不能给 ✅；给元数据类型打 ✅ 前要验证功能真的正确工作，"代码存在"不等于"抽取完整且正确"。

P1 报告的结论要包含元数据覆盖表（层级 × 类型 × 状态 × 来源位置）、带证据的摄取完整性评级、file:line 引用的问题清单、与源系统实际能力对比的缺口，以及Source system constraints（因源系统不提供而被评为 N/A 的项，帮助读者区分"connector 缺口"与"源系统限制"）。

P2：错误处理、容错与可观测性

P2（02-error-handling.md）对照三条可靠性标准展开：

Standard 4 错误清晰度：对 connector 专属代码中的每一个try/except 块分类——✅ 使用 Either 模式（实体名 + 操作 + 堆栈）、⚠️ 在 WARNING/ERROR 级别记录足够上下文、❌ 裸 except / except:pass / except:continue / 吞异常 / 用 DEBUG 记录操作级失败。同时要扫描本应有错误处理却没有的代码路径（裸 SQL 执行、外部 API 调用、文件 I/O 不在 try/except 内）——缺失的处理往往比写得差的处理危害更大。

Standard 5 容错：检查重试逻辑（@retry、tenacity、backoff，注意连接池重连不算查询重试）、每次操作超时（SQLAlchemyconnect_args与 HTTP 客户端超时；"框架默认 300s/查询 × 大量查询 = 数小时"不算有效超时）、令牌刷新（IAM/OAuth 临时凭证的令牌生命周期：在哪生成、存哪、是否过期、长任务中是否刷新）、资源清理（try/finally、上下文管理器、引擎泄漏）、优雅降级（非关键操作如拉标签失败时，核心抽取是否继续）。

Standard 7 可观测性：日志级别是否正确（操作失败在 WARNING/ERROR，例行进度在 INFO，冗长细节在 DEBUG）、是否存在捕获异常后静默返回默认值的"静默回退"、运维能否从日志看出正在处理哪个实体、处理/跳过/失败各多少、失败能否归因到具体实体与原因、凭据/令牌/连接串是否被意外写入日志。

P2 的输出分两个区段：Section A——connector 专属问题（try/except 全量分类表 + 各标准评级 + 按严重度排序的问题 + 修复建议）；Section B——继承的基类问题（影响该 connector 的共享代码问题，标注哪些其他 connector 同样受影响，明确修复是 connector 专属还是共享代码）。

P3：连接与认证

P3（03-connection-auth.md）对照 Connection Setup 标准（Standard 3），关注三个层面：

认证方式覆盖：先调研源系统官方支持的认证方式（用户名/密码、OAuth 2.0/SSO、API key/令牌、服务账号/服务主体、IAM 角色、密钥对、Kerberos/LDAP、证书认证），再对照本仓库连接 schema 的authType的oneOf变体（沿$ref追踪connections/、security/credentials/下的认证 schema），产出对比表：| 认证方式 | 源系统 | 我们的 schema | 状态 | 备注 |。schema 字段类型也需核验（密码是否 SecretStr、枚举是否正确）。

Test Connection 校验：逐步骤审查test_connection_steps()——真正校验的是连通性还是实际访问权限？是否用配置的认证方式测试？是否校验读权限（能否列出 schema/表）？错误信息是否具体、可操作？

SSL/TLS 支持：schema 是否可配置 SSL/TLS、能否提供自定义 CA 证书、是否有verifySSL选项、连接实现是否真的用上了这些设置。技能特别强调死代码检查的纪律：在判定某配置字段（如sslConfig）是死代码前，必须追踪完整初始化链路（__init__、共享工具如ssl_manager.py、pre-engine 钩子）——字段可能由共享基础设施消费（如SSLManager.setup_ssl()把值注入connectionArguments），而非 connector 自己的connection.py。

乐观陷阱："支持 BasicAuth"——大多数源系统有 3–5 种认证方式，只有 BasicAuth 至多评 ⚠️；"test_connection 通过"——真的发了查询还是只开了 socket？TCP 连通不等于有读权限；"支持 SSL"——是可配置 + 可传自定义 CA，还是默认关闭的布尔开关？"schema 字段齐全"——类型对吗、password 是 SecretStr 吗、描述有用吗？

P4：血缘准确性

P4（04-lineage.md）对照 Lineage Accuracy 标准（Standard 2），强调血缘在 OpenMetadata 中同样横跨多层，必须逐层检查：

1. connector 专属血缘：lineage.py、queries.py（取查询日志的 SQL）、models.py；
2. 服务类型基类：Database 类有lineage_source.py（文件）的 yield_table_lineage、yield_procedure_lineage 与query_parser_source.py（文件）的查询日志处理；Dashboard 有 yield_dashboard_lineage_details、Pipeline 有 yield_pipeline_lineage；
3. 共享血缘框架（列级血缘在这里）：ingestion/src/metadata/ingestion/lineage/parser.py（LineageParser、列级抽取）、sql_lineage.py（文件，内含get_lineage_by_query与 FQN 解析、跨服务搜索）、lineage_processors.py（跨数据库血缘、service_names 扩展）；
4. 管线配置：databaseServiceQueryLineagePipeline.json中的processCrossDatabaseLineage开关与服务名配置；
5. service_spec.py：血缘管线类型注册了哪些类。

评估维度包括：SQL 方言是否正确配置（能否处理 Snowflake FLATTEN、BigQuery UNNEST、Redshift COPY 等特殊语法）、查询日志来源（系统表/API/审计日志）与时间窗过滤、表级血缘的 FQN 解析与大小写归一化、跨库引用、临时表过滤、视图解析、列级血缘（SELECT *、别名SELECT a AS b、表达式列SELECT a + b AS c、子查询与 CTE、UNION 分支、函数内列追踪）、跨服务血缘（数据库的 processCrossDatabaseLineage 与 yield_cross_database_lineage、dashboard 的多库查询、pipeline 的任务级血缘边），以及边缘情况（CTE 是否产生幻影实体、动态 SQL 是否检测/跳过、视图链 A→v1→v2→table 是否完整解析、存储过程血缘 mixin 是否注册、schema 迁移后血缘是否断裂）。

评级上 N/A 有明确边界：源系统根本不提供数据的血缘类型（无执行历史表、无审计日志）评 N/A，无论 connector 代码是否存在；而静态分析定义（如解析存储过程体 SQL）是可实现的，缺失时应评 ⚠️ 而非 N/A。乐观陷阱包括："血缘存在"——可能只有表级，列级完全坏的；"FQN 能解析"——同库内而已？跨 schema、跨库是另一条代码路径；"共享解析器处理了"——方言对吗？泛用解析器可能毁掉 LATERAL FLATTEN、PIVOT、QUALIFY；"存储过程血缘能用"——StoredProcedureLineageMixin 真的在 service_spec.py 里注册了吗？很多 connector 继承了 mixin 却从未注册管线。

P5：规模与性能

P5（05-scale-performance.md）对照 Scale 标准（Standard 6），从四个维度解剖：

内存模式：对 connector 专属代码中的每一个数据收集分类——✅ 有界（固定大小/封顶）、⚠️ 线性（随数据量成比例增长，万级可管理）、❌ 无界（无上限或跨迭代累积，如把所有查询日志收进 list、缓存所有列元数据到永不清空的 dict）。重点找：先收集全部结果再处理的 list（应改生成器）、随实体增长且 schema 间不清理的 dict/缓存、无大小检查的文件读取（整份查询日志读进内存）、循环内字符串拼接。

分页完整性：对每个取实体列表的 API 调用/SQL 查询核验：是否分页、页大小是否可配置、超限后怎么办、是否有无溢出检测的硬上限。乐观陷阱：分页结果被收集进 list 再处理，就失去了分页的意义；LIMIT/TOP 无 offset 循环或游标续接不是分页，是硬上限，直接拉低评级。

生成器使用：所有实体迭代方法是否都用yield；拓扑 runner 是边 yield 边处理还是先收集；标签、描述、属主等次要操作是否也流式处理。

查找复杂度：是否存在 O(n×m) 嵌套循环（两重循环都随数据量增长）；列元数据查找是否应该按表名建索引；血缘匹配是否应改用 FQN dict；循环内重复 API 调用能否批量。

连接管理：是否用连接池（pool_size、max_overflow）；是否每个 schema/数据库建新引擎（应共享或妥善 dispose；"每 schema 一个池 × 100 个 schema = 100 个池"）；游标是否关闭、大结果集是否用服务端游标；出错路径是否泄漏连接。

规模场景推演（这是 P5 最出彩的部分）：10,000 表 × 100 列 = 100 万列元数据对象；500 个 dashboard × 50 图 = 2.5 万 chart 对象；100 万条查询日志的血缘解析内存与耗时；200ms 网络延迟 × 顺序 API 调用次数；100 个 schema 时的逐 schema 操作放大。逐场景识别瓶颈路径、内存增长点、顺序调用时间瓶颈与 O(n²) 操作。

P6：交叉验证、根因聚类与 PR 拆分

P6（06-refactor-plan.md）是"侦查 → 行动"的枢纽，流程清晰：

1. 输入：读取.claude/audit-results/下所有.md（排除旧版 06/07 文件），逐条发现记录"错在哪、file:line、严重度 ❌/⚠️、违反哪条标准、影响哪个 Metadata Tier（Tier 1 缺口致命，Tier 3 可缓）"；
2. 交叉验证：扫描矛盾（一个报告说 SSL 没接线、另一个假定 SSL 可用？同一代码路径严重度冲突？）；做文件覆盖率检查——列出 connector 目录每个文件，确认至少一个提示词实质分析过它，未被覆盖的文件可能藏着没人发现的问题；
3. 根因聚类：多个发现是否回溯到同一代码模式（10 处缺 Either 模式 = 1 个根因）？是否源于架构选型错误（基类选错、缺 mixin）？一个共享代码改动能否同时修好本 connector 和其他 connector？
4. Git 历史检查：git log --oneline -20 -- <connector_path>、gh pr list确认是否有人在活跃改动，避免动进行中的代码；
5. 分类决策框架：单 connector 干净代码中的 bug →就地修复（低风险）；3+ connector 同款 bug →修共享基类（中等风险，需更广测试）；可用但难读 →仅在顺手时重构；跨 connector 重复逻辑 →先抽取共享逻辑再修（中等风险）；基类选错或缺 mixin →先重构再对标（高风险架构变更）；审计发现的缺失功能 →新功能，单独定范围；
6. 工作量与风险评估：Effort S(<1h) / M(1–4h) / L(4h+)；Risk 低（限本 connector）/ 中（触及共享代码）/ 高（架构变更）；Testing 策略（仅单测 / 集成 / 手动验证）；
7. PR 拆分：一个 PR 只解决一个关注点（bug 修复与重构分开、connector 专属与共享代码分开）；共享代码改动先行（一个基类修复惠及多个 connector 就先做）；按依赖排序。

输出包含：合并发现表（# / 发现 / 严重度 / 标准 / Tier / File:Line / 根因聚类）、源系统约束清单（N/A 项不进实施计划）、有序实施计划、推荐的 PR 序列、延期项及理由。

P7：实施或 dry-run

P7（07-implementation.md）执行 P6 计划，两种模式：

默认模式（实施）：

1. 开工前确认在 worktree（git branch应处于task/[connector]-reliability），先跑既有测试建立基线：cd ingestion && python -m pytest tests/unit/[relevant_test_files] -v，预先存在的失败不在这条 PR 里修；
2. 按优先级（先 ❌ 缺口，再 ⚠️ 部分改进）逐项修复：先解释改动，再最小化实现；行为变更必须配完整可运行的 pytest 测试（plainassert，不用 TestCase，含 imports/fixtures/断言，禁止占位注释和伪代码）；改完在 ingestion 目录跑make py_format && make py_format_check；
3. 提交策略：一个逻辑变更一个 commit，格式fix([connector]): [what]或refactor([connector]): [what]；共享代码改动（如common_db_source.py、builders.py）单独 commit；
4. 多 connector 修复：共享代码只修一次，注明惠及哪些 connector、哪些还需专属跟进；不在本 PR 修其他 connector，每个 connector 自己的 PR；
5. 收尾：跑全量测试、lint、与基线对比确认无回归，并提议评级更新（哪些标准从 ⚠️ 升 ✅，逐一说明理由）；
6. 最终产出 before/after 摘要（如Before: 5.8/10 — 3 blockers, 6 warnings, 4 suggestions→After: 8.6/10 — 0 blockers, 1 warning, 2 suggestions），逐条列出发现与处置（如#1 HIGH SSL config not wired to driver → FIXED: added ssl_args extraction in connection.py），重跑静态分析器验证，保存实施报告到.claude/audit-results/07-implementation.md。

--dry-run模式：对每个工作项产出精确的 before/after diff（含文件路径与行号）、完整可运行测试代码、风险标记及缓解措施、commit message；不写任何代码、不创建 commit，计划保存为.claude/audit-results/07-dry-run-implementation.md。这是"先评审再动手"的关键护栏。

What NOT to Do 清单（执行纪律）：不为风格偏好改动正常工作的代码；不给没改过的代码加注释；不重构与发现无关的代码；不在本 PR 修其他 connector 的问题；不跳过测试——测不了就标记为手动验证。

报告输出结构与模板

整个审计的产物集中在一个目录下，命名固定、便于后续提示词读取：

.claude/ ├── connector-audit.json # Connector 上下文（P0 写入） └── audit-results/ ├── 01-metadata-ingestion.md # P1 报告 ├── 02-error-handling.md # P2 报告 ├── 03-connection-auth.md # P3 报告 ├── 04-lineage.md # P4 报告 ├── 05-scale-performance.md # P5 报告 ├── 06-refactor-plan.md # P6 综合计划 └── 07-implementation.md # P7 实施报告（--dry-run 时为 07-dry-run-implementation.md）

每份报告遵循 audit-report.md 模板，关键段落包括：

• 头部：connector 名称、提示词编号、评估的标准、评级；源码路径统一为ingestion/src/metadata/ingestion/source/{SERVICE_TYPE}/{CONNECTOR_NAME}/；
• 发现表：| # | 严重度 | 发现 | 文件 | 行号 |，全部要求 file:line 引用；
• 评级依据：什么做得好（带 file:line 的正向发现）、什么需要修（问题 + file:line）；
• 问题汇总表：按严重度排序；
• 修复建议：按客户影响优先级 P0/P1 排序，必要时带代码示例；
• 源系统约束（Source System Constraints）：被评 N/A 的项——这不是 connector bug，而是明确"源系统不可能提供什么 vs connector 漏了什么"，防止把"源系统做不到"误报为"connector 没实现"。

标准存放位置与配套资源

所有提示词通过/connector-standards加载连接器标准，标准文件存放在：

• skills/connector-review/standards/— 共享标准（main.md、patterns.md 等）；
• skills/connector-review/standards/source_types/— 按服务类型的标准；
• 静态分析器skills/connector-review/scripts/analyze_connector.py提供机械检查，与各提示词的深度人工分析互补。

设计精华总结

通读整套技能，最值得迁移的设计决策有四点：

1. "先查旧账再干活"的门禁：任何复用旧结论的冲动都被 Step 1 硬性拦截，保证每次激活都是真审计；
2. "机械检查打底 + 深度侦查分工"：静态分析器扫掉机械问题，提示词专注需要读源码、推理因果的深度分析，避免重复劳动；
3. "评级校准 + 乐观陷阱"双清单：把"有 LIMIT 不等于分页""连接池重连不等于查询重试""TCP 连通不等于有读权限""代码存在不等于功能正确"这类反模式显式化，防止审计被表面实现误导——这是整套评级可信度的根基；
4. "用户评审门禁 × 每步一存"：P1–P7 每步先展示摘要、获批后才落盘，错误被尽早拦截而非传导；固定文件名让 P6/P7 可以机械依赖上游产物，也让整套工作流天然支持--prompt N、--from N的断点续跑。

对于 OpenMetadata 这样拥有数百个 connector 的仓库（每个 connector 横跨 connector 专属代码、服务类型基类、共享血缘框架、schema 定义四层），这套"分级标准 → 并行侦查 → 根因聚类 → dry-run 先行 → 单 PR 单关注点"的审计方法论，既是 connector 可靠性改进的实操手册，也是一份可直接借鉴的"大规模代码库质量审计"工程模板。

【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata