ZDC（ZCTech Data Connector）不假设"两家客户的 ERP 一样"—— 制造业客户的系统几乎都做过二次开发：字段改名、加自定义字段、拆表、改单据流。 它自发现结构 → 四路语义匹配 → 落成现场档案 → 靠派生复用， 把一句经营问题翻译成客户库里的真实访问。不搬数据、不落口令、不写业务表。
# 1) 连接自检：连通 + 只读 + 版本探测 $ zdc test kingdee-cloud ✓ connected · readonly=true · v8.2 # 2) 结构自发现（快照按 hash 去重，可 diff） $ zdc discover kingdee-cloud ✓ 23 tables · 4,505 fields · 61 comments ✓ fk 27 · row_estimate ok # 3) 语义匹配：给出候选与置信度，人审确认 $ zdc suggest --profile kingdee-jingmi customer → t_BD_Customer 0.94 FName ~ 客户名称 FCUSTID ~ 客户编码 sales_order → SEOrder 0.88 FBillNo ~ 单据编号 receivable → AR_receivable 0.61 → 进人审 # 4) 落成现场档案（版本化、可导出、可派生） $ zdc profile publish kingdee-jingmi ✓ 12 objects · 47 fields · confirm 12 based_on: kingdee-base@v3
客户的 ERP 落地几乎都伴随二次开发，不存在"两家客户 ERP 一样"。所以真正的产品资产不是那几张卡，而是「发现 + 匹配 + 确认 + 复用」的能力。
FBillNo 改成 custom_bill_no——按字段名硬编码的映射当场失效。ZDC 靠中文注释（"单据编号"）兜住。
"客户等级2""项目号"这类实施商加的字段，没有任何厂商模板收录。ZDC 靠值域枚举分布（只有 A/B/C 三种取值）+ 注释 + 主外键识别。
订单头与订单行拆成三张、中间插一张审批表，join 路径全变。ZDC 靠FK 拓扑 + 行数比例（头:行 ≈ 1:N）重建结构。
自定义状态码、加审批节点，"已完成"的判定不再成立。ZDC 靠枚举值采样看实际取值，再由人确认口径。
推论：不要求"厂商识别正确"，只要求"对象 → 表 / 字段候选正确"。厂商识别只用于挑起点模板，不参与最终判定。
每一层都有明确的产出物与验收口径，交付物不再是"一份实施文档"，而是一个可版本化、可导出的档案。
协议层，厂商无关：SQL 只读 / OpenAPI / OData / 文件或视图导出。统一 SPI 接口：test、discover、read、write_draft。
结构自发现：表、字段、中文注释、主外键、行数估算、样本值分布 → schema_snapshot（按 hash 去重，可对比升级后的结构变化）。
四路特征融合：名称 × 注释 × 结构 × 数据分布，输出候选与置信度。高置信自动启用，低置信进人审队列。
现场档案 = 真正的交付物：对象→表、属性→字段、join 路径、口径。版本化、可导出、可派生。
同厂同版本 / 同实施商的档案派生为新客户起点——这是"第二家客户实施成本减半"的真实来源。
| 二次开发形态 | 匹配主力 | 辅助证据 |
|---|---|---|
| 字段改名 | 中文注释（"客户名称""含税金额"） | 类型 + 被谁 join |
| 加自定义字段 | 值域枚举（"客户等级2"只有 A/B/C） | 注释 + 与主表的 FK |
| 拆表 / 加中间表 | FK 拓扑 + 行数比例（头:行 ≈ 1:N） | 命名前缀 + 注释 |
| 改单据流 | 枚举值采样（状态码实际取值） | 与业务实体的关系 |
"能连"= 协议可达 + 授权到位 + 现场 profile 确认。下面是已实现与待联调的实际情况，不用"全面支持"糊过去。
| 系统 | 档 | 协议 / 端点 | 模式 | 状态 |
|---|---|---|---|---|
| 金蝶云星空 | A | WebAPI · ExecuteBillQuery（FormId + FieldKeys） | 落仓 / 直查 | 已就绪 真实 schema 种子（23 表 / 4,505 字段） |
| 用友 YonSuite / YonBIP | A | OpenAPI REST（app_key + 签名 + access_token） | 落仓 | 已就绪 待客户环境真跑 |
| 用友 U8 / U8C | B | SQL Server 直读 + 扩展属性（中文注释） | 直查 | 待环境 |
| SAP S/4HANA | A | OData V2 / V4（$metadata Edmx 解析） | 落仓 | 代码就绪 待联调 |
| Odoo | A | JSON-RPC（ir.model / ir.model.fields 全量元数据） | 落仓 / 直查 | 已就绪 |
| ERPNext | A | REST（doctype meta API） | 落仓 / 直查 | 已就绪 |
| 鼎捷 T100 / 易飞 | A / B | 开放平台 REST 或数据库直读 | 直查 / 落仓 | 按单评估 |
| MySQL / PostgreSQL | B | SQL 只读（information_schema 自发现） | 直查 | 已实测 |
| SQL Server / Oracle | B | SQL 只读（sys.* / all_* 内省） | 直查 | 内省就绪 待环境 |
| 达梦 / 金仓（信创） | B | 复用 Oracle / PG 方言 | 直查 | 规划 信创适配项 |
| 文件 / 视图导出 | D | CSV / Excel 模板 | 落仓 | 已就绪 兜底通道 |
| Ontop 虚拟映射（VKG） | P1 | SPARQL over JDBC（数据不动） | 虚拟 | 候选 |
C 档（私有 WebService / 定制）按单评估，不进标准产品；完全封闭且不允许只读连库的系统明确"不接"——只做文件与视图导出兜底。明确说不接，比硬接专业。
指标 SQL 只写一次（面向语义表）。直查模式 = "语义表 → 物理 SQL"的翻译层；落仓模式 = staging 本身就是语义表。
| 维度 | 直查（虚拟） | 落仓（物化） |
|---|---|---|
| 适用 | SQL 源（B 档：MySQL / PG / SQL Server / Oracle / 信创库） | API 源（A 档：金蝶 / 用友 / SAP / Odoo / ERPNext） |
| 数据落地 | 不落地，只回传聚合结果 | 同步成客户内网的语义表 |
| 实时性 | 实时 | 增量同步（updated_at / 单号游标） |
| 跨对象聚合 | 在客户库内做，受库性能与权限影响 | 本地 SQL，P95 可控、断网可查 |
| 客户侵入 | 最小：一个只读账号 | 需要一台内网库与同步窗口 |
为什么 API 型必须落仓：毛利 by 客户 by 月这种聚合在 ERP 的接口侧做不出来——分页拉单据再本地聚合是唯一务实解。这也是江苏精密案例验证过的形态。
同一个连接器，三种能力位。上层 ZOT 只认 kind: db | iot | rag，不认厂商与协议。
SQL 只读、OpenAPI、OData、文件导出。对象映射到 db 能力位，是经营分析的主通道。
MQTT 订阅（支持网关多级主题）、InfluxDB 时序查询（Flux）、设备物模型（设备 / 点位 / 事件）、RTSP 探头。映射到 iot 能力位。
文档 / 条款 / 片段，引用可回原文。映射到 rag 能力位（规划中，与证据节点打通）。
# 上行：网关多级主题 → 点位值 zlgw/zigbee/data/<设备SN> { "data": { "temperature": 26.4, "humidity": 61.7 } } # 查询：时序库按 bucket/measurement 取点 device_series("th-zigbee-01", point="humidity", start="-24h") → 2,000 采样点 # 下行：控制报文由服务端按模板渲染 # 两段式：申请 → 一次性令牌 → 确认下发 # 双留痕：device_event + audit_log
# 语义名输入，由 profile 翻译成物理访问 { "object": "sales_order", "attrs": ["amount", "customer"], "filters": { "status": "COMPLETED" }, "group_by": ["customer"], "time_range": ["2026-09-01", "2026-09-30"], "limit": 1000 } # 同一个 IR 落到不同驱动： # SQL 源 → 参数化 SELECT（只读 + 行上限） # OpenAPI → FieldKeys / filters # OData → $filter / $select # Odoo → search_read(domain)
客户的系统不是我们的实验场。所有驱动统一遵守同一套安全约束，不靠"实施人员注意"。
连接自检会探账号权限（SHOW GRANTS 等），非只读账号直接拒绝接入，不靠口头约定。
库口令与 API 密钥只以 secret_ref 形式存在配置里，不落明文、不进浏览器、不进日志。
全部参数化查询，单次行数上限 1 万、超时 30 秒；越限只报错，不"尽量返回"。
任何写动作只生成草稿：两段式申请 + 一次性令牌 + 人工确认，按客户授权逐动作开通。
谁、何时、用什么身份、查了哪个对象、返回多少行、命中哪条口径——一条链留下来，可回放。
二次开发差异靠 profile 吸收，不要求客户改结构、加字段、建数仓；落仓也只写自己的 staging。
每次交付都按这六条对账，达不到就是没交付完，不进入下一阶段。
| # | 指标 | 目标 |
|---|---|---|
| 1 | 新客户（陌生 / 二次开发版）12 对象自动匹配命中率 | ≥ 60%（关键对象 ≥ 80%） |
| 2 | FDE 现场从零到"20 问句可跑" | ≤ 2 小时（12 对象人工确认） |
| 3 | profile 复用带来的确认量下降 | ≥ 50% |
| 4 | 客户升级后的结构变更可检测 | 行 / 列级 diff |
| 5 | 协议覆盖 | 4 类各至少 1 个真实实例跑通 |
| 6 | 关键对象（客户 / 供应商 / 物料 / SO / PO / 库存） | 命中率 ≥ 80% |
这些是验收目标，不是宣传数字。每个客户现场的实际命中率都会在交付报告里如实列出，未达标项按偏差清单处理。
ZDC 自 2026-10 起作为 DIP v3 的数据连接器运行。下面区分"已经跑通的"和"等环境的"。
| 能力 | 状态 | 说明 |
|---|---|---|
| 连接器 SPI + 统一查询 IR | 已上线 | test / discover / read / write_draft 四方法，驱动按能力位注册 |
| SQL 只读驱动（MySQL · PostgreSQL） | 已实测 | schema 自发现 + 只读校验 + 参数化查询 + 行上限 |
| 金蝶云星空 / 用友 YonSuite / Odoo / ERPNext / SAP OData 适配器 | 已就绪 | 金蝶已入库真实 schema 种子；其余待客户环境真跑 |
| 结构自发现与 schema 快照（hash 去重） | 已上线 | 表 / 字段 / 注释 / 主外键 / 行数估算 / 样本值 |
| 四路语义匹配（候选 + 置信度 + 人审队列） | 已上线 | 命中率随现场样本提升，按验收口径逐客户统计 |
| 现场档案 profile（版本化 / 导出 / 派生复用） | 已上线 | based_on_profile_id 派生；结构变更 diff 在补 |
| IoT 通道（MQTT / InfluxDB / 设备物模型 / RTSP） | 已上线 | 控制下发走两段式，双留痕（设备事件 + 审计） |
| RAG 通道（文档 / 条款 / 片段） | 规划 | 与证据节点（evidence）打通后开放 |
| 信创库生产实跑（达梦 / 金仓） | 规划 | 方言复用 Oracle / PG，待客户环境验证 |
边界说明：ZDC 不定义口径（那是 ZOT），不做会话与工具调度（那是 ZAI）。它只回答一个问题：这个概念在这套系统里，现在该怎么取。
一个客户从"给了账号"到"20 问句可跑"，通常在一次现场内完成。
连通性、只读校验、版本探测，输出可执行建议（含"该找客户 IT 开什么权限"）。
拉取 schema 快照，比对已有 profile 与厂商基线模板，标出差异项。
四路匹配出候选与置信度，FDE 与客户业务人员逐条确认 12 个对象。
档案发布、派生关系登记；跑 20 条问句对账，未命中项进下一轮改进清单。
准确含义是：协议可达 + 授权到位 + 现场 profile 确认，不是预置六家厂商映射卡。按接口形态分四档：A 档官方 OpenAPI / OData（金蝶云星空、用友 YonSuite、SAP S/4、Odoo、ERPNext、鼎捷）；B 档数据库只读（私有化部署的国产 ERP 大多在这里，含达梦、金仓等信创库）；C 档私有 WebService 按单评估；D 档完全封闭则明确不接，只做文件 / 视图导出兜底。
这正是 ZDC 的设计前提。匹配不靠字段名硬编码，而是四路特征融合：名称（中英别名）、中文注释、结构（主外键拓扑、字段数、头行比例）、数据分布（值域枚举、格式）。字段改名靠注释识别，拆表靠 FK 拓扑识别，加自定义字段靠值域分布识别；结果带置信度，高置信自动启用，低置信进人审队列。
默认不搬。SQL 源走直查（虚拟）：查询在客户库内执行，只回传聚合结果，数据不落地、实时、最小侵入。只有 API 型 ERP（接口侧做不了跨对象聚合）才走落仓：把对象同步成客户内网的语义表，增量按 updated_at 或单号游标。两种模式都在客户机房内。
靠 profile 派生而不是厂商模板。同厂同版本、或同一实施商交付过的客户，现场档案可以基于已有 profile 派生（based_on_profile_id），对象与字段映射已经对好，人工只需确认差异项。厂商映射卡最多覆盖 60–80%，profile 复用的收益是可累积的。
不会。只读账号强校验（连账号权限都要探一遍）；写动作只到草稿态——两段式申请 + 一次性令牌，人工确认后才在客户授权范围内执行，且全程审计留痕、可按动作回滚。任何一步未经确认，都不会触碰业务表。
三条通道。SaaS/ERP 走 SQL、OpenAPI、OData；IoT 走 MQTT 订阅与 InfluxDB 时序查询，设备按物模型（设备 / 点位 / 事件）建模，控制指令按模板渲染后两段式下发；RAG 通道（文档 / 条款 / 片段，引用可回原文）在规划中。
不承诺"自动全对"。我们给的是：结构快照、12 对象候选与置信度、差异清单、以及一份能签字的现场档案草稿。