# 模型库可行性验证（spike）· 结论

> **执行**：session-40f8f716（证据在 `spike/model-lib/FINDINGS.md`）
> **并档**：session-24ca6e69 ┃ **日期**：2026-10-07
> **范围**：只验「能否产出可用的 `HardwareModel`」——不碰 STEP/IGES/glTF/CAD

---

## 0. 总纲（一句话判断）

> **`protocol` / `voltage` / `position` 三者不是三个独立问题，是同一个问题的三个面：
> 元件库服务于「设计芯片的人」，我们的场景服务于「接线的人」。**

| 想要的 | 被什么挡住 |
|---|---|
| `protocol` | **标准层面无处可放** —— 总线协议是**设计**的属性，不是引脚的固有属性（§2） |
| `voltage` | 同上 + 厂商 `otherProperty` 是可选字段，预期大面积缺失 |
| `position` | **封装是芯片的，场景摆的是模块**（§3.1） |

**⇒ 这不是「若干不利发现」的集合，是一个结构性错配的三种表现。** 继续投等于逆着这个结构走。

---

## 1. 裁决：不是「跑不通」，是「自动化程度远低于预期」

| 交付项 | EasyEDA Pro | KiCad |
|---|---|---|
| 引脚名 / 编号 | ✅ | ✅ |
| 电气类型（输入/输出/双向/电源/地） | ✅ | ✅ |
| **总线协议**（i2c / spi / uart） | ❌ | ❌ |
| **电压** | ❌ | ❌ |
| **3D 包围盒 `size`** | ❌ | ❌ |

**⇒ 该方案省的是录入成本，不是判断成本。**

---

## 2. ★ 结构性结论：瓶颈不在厂商，在标准本身

**两个互相独立的 EDA 生态，编码的是同一个东西 —— 引脚电气类型。**

- EasyEDA：`ESCH_PrimitivePinType` = `IN / OUT / BI / PASSIVE / OPEN_COLLECTOR / OPEN_EMITTER / POWER / GROUND / HIZ / TERMINATOR / UNDEFINED`
- KiCad：`(pin power_in line ...)` / `(pin bidirectional line ...)` / …

两边都**没有**总线协议，都**没有**电压。

**这有个比"选哪家"重要得多的含义**：`protocol` 与 `voltage` **永远得我们自己推** —— 不存在「换一家就能白拿」的选项。反过来说，设计文档把 `schema/` 称作「核心壁垒」是**准确的**：它确实买不到。**而这个判断现在是跨两个生态验证过的，不是单点观察。**

> **为什么会这样（补充的结构性理由）**：**总线协议不是引脚的固有属性。**
> 同一个 GPIO，既可能是 I2C 的 SDA、也可能是 SPI 的 MOSI、也可能是 UART 的 TX ——
> 取决于**设计怎么复用**它。对固定功能的器件引脚（传感器的 SDA/SCL），名字里编码了协议；
> 对可复用的控制器引脚（树莓派 GPIO），**没有任何厂商能编码**，因为它由设计决定。
> 所以「厂商没做」不是偷懒，是**这件事在标准层面无处可放**。

---

## 3. ★★ 最关键的发现：**类别错配**

spike 给出一条**可证伪的先验预测**（下一轮待验）：

> 拿我们现有的 `rpi-4b` / `bme280` / `led-5v` / `breadboard` 去查，**命中率预期极低**。
> 理由**不是"库不够大"，而是类别错配**：
>
> | 我们的型号 | 它是什么 | EDA 库里有吗 |
> |---|---|---|
> | `breadboard` | 面包板 | ❌ 不是元件，**没有 LCSC 料号** |
> | `led-5v` | 通用模块 | ❌ 不是元件 |
> | `rpi-4b` | **成品板卡** | ❌ EDA 库索引的是**元件（芯片）**，不是成品板 |
> | `bme280` | 元件 | ⚠️ 是元件，但 KiCad 只有兄弟型号 **BMP280**，没有 BME280 |
>
> **即：EDA 库覆盖「芯片」，而我们的场景以「板卡与模块」为主。**
> **这个错配不是换厂商能修的。**

**旁证**：KiCad 官方 `Sensor_Pressure` 目录 27 个型号有 BMP280、无 BME280；`Sensor_Humidity` 15 个文件同样无 BME280 —— **连我们自己的参照传感器，在开放符号库里都不存在。**

---

### 3.1 ★ 类别错配也击穿了 `position`（这一条证否了「位置可自动推」的设想）

我此前判断：「`position` 是三个要判断的字段里**最可自动化**的一个，因为厂商 PCB 封装本来就有每个焊盘的 (x, y) —— **那就是物理位置本身，不是猜的**」。

**原理上对，但漏了一个前提没被检验：那个封装是「元件」的封装，还是「模块」的封装？**

实测（KiCad 开放封装库，GitLab API 可取，**无需任何客户端**）：

```lisp
Package_LGA.pretty/Bosch_LGA-8_2.5x2.5mm_P0.65mm_ClockwisePinNumbering.kicad_mod
→ (pad "1" smd rect) ... (pad "8" smd rect)      ; 8 个焊盘
```

| | 封装（KiCad / LCSC 侧） | 我们的基准 `bme280` |
|---|---|---|
| 对象 | **裸芯片** | **模块**（breakout） |
| 尺寸 | **2.5 × 2.5 mm** | **20 × 18 mm** |
| 引脚数 | **8**（LGA-8） | **3**（排针） |
| 间距 | **0.65 mm** | **2.54 mm** |

**差近一个数量级，引脚数都不同 —— 这是两个不同的物理对象。**

> ⇒ **即使型号命中，封装也给不出我们要的位置。** 芯片的 8 个焊盘是裸片 land pattern，
> 我们的 3 个端口是 breakout 的排针。**要自动推位置，需要的是「模块」的 CAD，
> 而那恰恰不在元件库里。**

**⇒ 类别错配同时击穿三样**（见 §0 总纲）。

---

## 4. 对原计划的影响：两半要彻底拆开

我在 §8 里提过「语义优先、几何后置」。**spike 的证据要求把这条再推进一层**：

| | 语义（端口/protocol/voltage） | 几何（3D 模型） |
|---|---|---|
| 能否导入 | ❌ **跨两生态证明不能** | ✅ **可能可以**（SnapEDA/Ultra Librarian 对**模块**也提供 3D 模型，这与 EDA 符号库是不同来源） |
| 结论 | **必须自产** —— 优化「作者过程」，不是「导入管线」 | 走导入管线 |

**注意这里有个反直觉的推论**：我原先说「语义优先、几何后置」，理由是语义才是壁垒。
spike 的证据**没有推翻这个理由，反而加强了它** —— 但它同时说明：
**能导入的那一半（几何）恰好不是壁垒，是壁垒的那一半（语义）恰好不能导入。**
⇒ 两者本就该用**完全不同的手段**做，不该捆在一条"远程模型库"管线上。

### 4.1 ★ 几何侧的实测补充（2026-10-07 第二轮查证）

> 起因：用户问「不是有现成的精细模型吗」。上一轮只查了**符号/封装**，**没查 3D 模型**。
> 查完发现：**几何侧的可行性比本文档早先的判断好一半、差一半。**

#### ✅ 好消息：**「STEP 转换管线」这个问题在芯片级根本不存在**

- **KiCad 官方 3D 库**（`kicad-packages3D`）**同时提供 `.step` 与 `.wrl`（VRML）**
- **three.js 自带 `VRMLLoader`**（实测本机 `three/examples/jsm/loaders/` 下有；**确认无 STEP/IGES loader**）
- ⇒ **VRML 可直接加载，无需任何 CAD 转换**

**许可**（Debian 版权文件原文）：**CC-BY-SA 4.0 + 例外条款**，例外原文：

> "To the extent that the creation of electronic designs that use 'Licensed Material' can be considered
> to be 'Adapted Material', then the copyright holder **waives article 3** of the license with respect
> to these designs and any generated files which use data provided as part of the 'Licensed Material'."

⇒ ShareAlike **不传染到"使用模型的电子设计"**。⚠️ 但**再分发模型文件本身**仍需遵守 CC-BY-SA（署名 + 相同方式共享），且库中有**少量文件是 GPL-3+**（需逐个甄别）。

#### ❌ 坏消息：**类别错配在几何侧同样成立**

逐类核对 KiCad 3D 库的顶层类目（45 类）：

```text
Battery / Button_Switch_* / Buzzer / Capacitor_* / Connector_* / Converter_* /
Crystal / Diode / Filter / Fuse / Heatsink / Inductor / LED /
Mounting / Package_BGA|DFN_QFN|DIP|LGA|QFP|SIP|SO|SON|TO_SOT /
Potentiometer / Relay / Resistor_* / RF_* / Sensor_Audio / TerminalBlock_* /
Transformer / Varistor
```

**全是「元件封装」。没有 `Module` 类目，没有 Raspberry Pi，没有 Arduino，没有任何成品板卡。**

⇒ **和封装那轮是同一个结论**：KiCad 覆盖**芯片**，而我们的场景是**板卡与模块**。
（树莓派、BME280 breakout、面包板 —— 一个都不在。）

#### 模块/板卡的几何从哪来：来源存在，但三个变量都不可控

| 来源 | 格式 | 可控性 |
|---|---|---|
| **GrabCAD**（社区） | 多为 STEP | 许可**逐个不同**，质量/原点/比例各异 |
| **厂商官网**（如 Raspberry Pi 官方机械图） | STEP / DXF | 许可最好，但只覆盖自家板卡 |
| **`step.parts`**（12,000+ 开源 STEP 件） | STEP | 开源，但仍需转换 |

⇒ **模块级几何 = 需要转换 + 许可逐个甄别 + 原点归一化**。
**不是"没有"，是"散、格式要转、许可要逐个看"。**

#### 综合修正

| | 芯片级 | 模块/板卡级 |
|---|---|---|
| 几何可用性 | ✅ **现成、免转换（VRML）** | ✅ **`step.parts` 有 GLB 直链**（见 §4.2） |
| 端口语义 | ❌ 买不到（跨两生态已证） | ❌ 买不到 |

> **★★ 2026-10-07 二次修正（重要）**：本节早先判断「模块级几何散、要转 STEP、许可各异」——
> **`step.parts` 一次解决这三个问题**：公共 API（免鉴权）+ **每件都有 `glbUrl`（GLB 直链，无需转换）**
> + 覆盖板卡模块（`raspberry-pi` 15 / `arduino` 17 / `adafruit` 87 / `sparkfun` 120）。
> **详见 [`05-模型来源与导入方案.md`](./05-模型来源与导入方案.md)。**
>
> ⇒ 本文档 §4 表格里「几何：可能可以」应改为：
> **芯片级「可以且免转换」；模块级「`step.parts` 可直连、GLB 免转换」。而两者共同的前提是——语义仍需自产。**

---

## 5. 建议：语义改走 **DS 辅助作者**（而非抓取管线）

既然 `protocol` / `voltage` / `size` 三项**买不到、也抓不到**，而它们又都是**判断**而非**录入**——
那就该用**判断**的手段解决。本插件里现成有一个：**DS 自己**。

这与设计文档 §3.3 是同一个命题的推广：

> §3.3 原文：「DS 的桥接角色（能力保留，范围收窄）：DS 读项目代码、推断硬件访问模式、**生成适配层**」

把「读项目代码生成适配层」换成「读厂商引脚表 + 数据手册**生成 `schema/` 条目**」，是同一件事。

**闭环形态**：
```text
厂商 API（已验证可用）→ 引脚名 + 编号        ← 这一步自动化，省掉纯体力录入
        ↓
DS 读引脚名 + 数据手册 → 推断 protocol / voltage / size   ← 这一步是判断，DS 干
        ↓
自动校验（已有的 tests/model-library.test.ts）  ← 安全网：端口必须在包围盒内
        ↓
人工确认
```

**为什么这个组合是合理的**：
- 结构化能拿的（引脚名/编号）→ 走 API，不靠猜
- 结构拿不到的（protocol/voltage/size）→ 走判断，**并且明确标记为"推断值"**，让人知道哪里需要复核
- 已有的包围盒自检测试**正好是这套流程的安全网** —— 它拦的正是"端口落在几何体外"这类推断错误

**这也让 spike 的一个副产品变得有价值**：`getByLcscIds(lcscIds)` 已被证实可用，所以「给定料号拿引脚表」这一步是**真的自动化了**——省掉的确实是纯体力活。

---

## 6. ★ 用户明确偏好：**接口位置要能自动确定**

> 用户 2026-10-07 定：「走覆盖率优先，**但最好是自动锁接口位置**」。

这条偏好**改变了 spike 的价值排序**，而且方向是好的：

### 6.1 `position` 是三个「要判断」的字段里**最可自动化**的一个

| 字段 | 来源性质 | 能否自动 |
|---|---|---|
| `protocol` / `voltage` | 只能从**名字**猜（启发式） | ❌ 本质是判断 |
| **`position`** | 厂商 PCB 封装**本来就有每个焊盘的 (x, y)** | ✅ **那就是物理位置本身，不是猜的** |

⇒ 我此前标为「第三步推断」的 **2D 封装坐标 → 3D 局部坐标** 映射，**恰恰是最有希望真正自动化的那一步**。用户点到了正确的地方。

### 6.2 映射要回答的三个自由度（spike 必须明确）

1. **封装平面的两个轴 → 我们的哪两个轴？**（我们的约定：x=长 / z=宽 / y=厚）
2. **第三个轴（高度）取什么？** 端口在**顶面**（现行做法是 `size.y/2 − 0.1mm`）—— **封装数据给不了这个**
3. **原点**：封装原点 vs 我们的「包围盒中心」

### 6.3 ★★ 正解（不是退路）：**声明式布局规则**

> 起因：用户要「接口位置能自动确定」。证据（§3.1）表明**厂商数据给不出这个** ——
> 但**换一种形态就能给出用户真正想要的东西**。

现状是**逐个手打 12 个坐标**，而且**我们已经因此栽过一次**（三个型号混用两套原点约定，树莓派 6 个端口 4 个落在体外）。改成声明式：

```ts
portLayout: { edge: '+z', pitch: 0.00254, count: 6, inset: 0.005 }
```

而不是 6 组手写三元组。三个好处：

1. **不用手打坐标 ⇒ 消灭出错的那一类操作**（这是已发生过的错误类型，不是假想）
2. 同一条边的端口**等距是规则推出来的**，不是人肉保证的
3. 自检从「逐点在盒内」升级为**结构性校验**（边/间距/内缩是否合理）

> **它不是「自动」，但它消灭了出错的那一类操作** —— 对这一个字段，收益高于任何抓取管线。
> **用户要的「自动锁接口位置」，应当以这个形态交付，而不是以厂商数据形态交付。**

**实现形态（不破坏现有运行时）**：`portLayout` 是**作者时便利**，在模型库加载时**展开成现有的 `ports` 数组** ——
`Port.position` 仍是运行时唯一真相，下游（校验、快照、前端、自检）**全部不用改**。

#### ★ 落地后的实证：结构校验器第一次运行就抓到了校验公式自己的 bug

这不是设想，是**发生过的事实**，也是"逐点校验 → 结构性校验"这个升级**最纯粹的验证**：

提案里那条校验写成 `pitch×(count−1) + 2×inset ≤ 沿边轴长度`，它把 `led-5v` 判成非法
（`0.00254×2 + 2×0.010 = 0.02508 > 0.020`）—— **而 led-5v 的实际坐标 `x = ±0.00254, 0` 明明在盒内。**

**错因**：把 `inset` 当成了**沿边方向**的边距，而派生公式里它的语义是**垂直方向**距所依附那条边的内缩。
**两个正交方向被塞进同一个不等式，公式必然废。**

修正后（已实现）：

```text
沿边方向：pitch × (count − 1) ≤ 沿边轴长度        ← 整行居中，只需"装得下"
垂直方向：0 ≤ inset ≤ 垂直轴长度                   ← 缩过头就出盒（两侧对称）
```

> **逐点校验永远发现不了这件事** —— 点都在盒内，逐点检查全绿，**而规则是错的**。
> 结构性校验第一天就抓到了「人写死的规则里的错」，而且抓的是**写下这条规则的人**的错。

**为什么这条值得写进文档**：它比任何"结构性校验有好处"的论证都有说服力 ——
因为它是**已发生的事实**，不是设想。

### 6.4 若这条也不做

那就回到手打坐标 —— 也就是已经出过错的那条路。**不建议。**

---

## 7. ★★ 决定性发现：扩展 API 是 **GUI 宿主插件**，不是可独立调用的库

来源：官方 SDK README（`gitee.com/jlceda/pro-api-sdk`）的「进入开发」流程，**第 5 步**：

> 5. 在 **嘉立创EDA专业版** 中安装生成在 `./build/dist/` 下的扩展包

**⇒ 要调 `getByLcscIds` / `getAllPinsByPrimitiveId`，必须有 EasyEDA Pro 客户端在跑、且装了你的扩展。**
它不是 `npm install` 就能用的库，是**宿主在 GUI 里的插件 API**。

**官方桥接路径存在**：`easyeda/easyeda-api-skill`（官方 AI SKILL），描述原文「为 AI 编程工具提供完整的 EasyEDA Pro API 接口和 **WebSocket 桥接能力**」。
⇒ 架构等价于：`EasyEDA Pro 客户端（装桥接扩展） ←WS→ 我们的插件 host 半`。

### 7.1 决策含义（比技术细节重要）

**技术上走得通，但代价是把一个第三方 EDA 桌面应用变成我们插件的运行时依赖。**

> 也就是说：**用户为了在 3D 场景里看到几个真模型，得先装并打开一个 EDA 软件。**

对一个 DSH 插件来说这是**很重的一笔**。而且它换来的东西我们已经知道是**残缺的**（无 protocol / 无 voltage / 无 3D size）—— 代价与收益严重不成比例。

### 7.2 ★ 但这不杀死这个想法，它**改变了它的位置**：从「运行时」挪到「作者时」

| | 运行时依赖 | 作者时工具 |
|---|---|---|
| 谁需要装 EasyEDA | **用户**（不可接受） | **只有我们**（一次性） |
| 产出 | 每次运行都去拉 | 生成 `HardwareModel` 条目，**随插件发布** |
| 可行性 | ❌ | ✅ |

**⇒ 路径 A 作为「用户运行时功能」判死；作为「我们离线产出 schema 的工具」仍然可用。**
而且这个定位与 §5 的 **DS 辅助作者** 天然合流：EasyEDA（作者时，脚本化拉引脚表）+ DS（补 protocol/voltage/size 的判断）+ 自检测试（安全网）→ 产出随插件发布的 `schema/`。

**ToS 的性质也随之变化**：作者时的一次性使用，比"用户端批量抓取"更接近厂商允许的用法（厂商甚至在主动铺 AI agent 接入 —— 见下）。

### 7.3 厂商在主动铺 AI agent 接入

- `easyeda/easyeda-api-skill`：官方 AI SKILL + WebSocket 桥接
- 专门的「**For AI**：扩展工程初始化指南」（`prodocs.easyeda.com/cn/api/guide/how-to-start-for-ai.html`）

⇒ 若将来真要走这条路，**这是最短路径，不是我们逆着厂商意图硬啃**。

---

## 8. 最终结论：**不投入**（2026-10-07）

### 8.1 四条判据的终态

| # | 判据 | 终态 | 证据 |
|---|---|---|---|
| ① | 映射准确率（protocol / voltage / position） | ⬜ **无法在无客户端环境下测** | 见 10.2 |
| ② | `size` 来源 | ❌ **否证** | 无 API；全库唯一 bbox 只吃二维多边形 → 半自动 |
| ③ | ToS / 自动化访问 | ❌ **一手拦截证据** | `so.szlcsc.com/global.html?k=BME280` → **HTTP 403**（带 UA 亦然） |
| ④ | 覆盖率 | ⚠️ **表述修正为「元件覆盖率」** | 见 10.3 |

**另加一条结构性的（跨两生态）**：总线协议与电压**在 EDA 符号标准里无处可放** —— 见 §2。

### 8.2 ★ 决定性论据：**这个测试在无客户端环境下做不完**

要给出一份可信的覆盖率数字，只有两条路：

1. 装并运行 **EasyEDA Pro 客户端**（+ 桥接扩展）→ 撞上 §7 那个「GUI 运行时依赖」
2. 批量抓立创商城 → **已被 403 拦下**，而这正是判据 ③ 要否证的事

> **连「数一数有多少型号可用」这件最基础的事，都要先接受那笔运行时依赖、或跨过 ToS 红线。**

**而这个姿态本身，比覆盖率数字更能说明问题。** 整条路被同一个依赖锁住。

**⇒ 停止的核心理由（避免循环论证）**：
「为了判断该不该装客户端，而先去装客户端」是循环论证。
而且**不需要**覆盖率数字就能下结论 —— ②③ 与跨生态结论**三条独立理由**已经各自足以否证；覆盖率只会细化「有多差」，不会改变「要不要做」。

### 8.3 覆盖率结论的正确表述

> **覆盖率 = 元件覆盖率，而我们的场景不是元件。**

比「覆盖率低」更准确，也更难反驳：

| 型号 | 性质 | 实测 |
|---|---|---|
| `bme280` | **元件** | ✅ 在库（`item.szlcsc.com/93682.html`，Bosch 温湿度传感器） |
| `rpi-4b` | 成品板卡 | ⚠️ 未定论（只见于用户工程，未见元件库条目） |
| `led-5v` | 通用模块 | ⚠️ 未定论 |
| `breadboard` | 非元件 | ⚠️ 未定论 |

先验预测的**方向对、强度错了**（原预测"极低"，实测是"类别不匹配"而非"库太小"）。

### 8.4 ★ 对「DS 辅助作者」路线的重要限定

我在 §5 提的 DS 辅助作者路线**方向成立，但它不解除依赖**：

> 引脚表本身要先拿得到，而 `getByLcscIds` 同样要在客户端里跑。

⇒ 它**只把依赖之后的成本降下来**：让"装客户端"变得**值得**，但**没让"不装客户端"变得可行**。

**⚠️ 这条必须写明，否则将来会被读成「不用装客户端了」。**

### 8.5 ★ ToS：**三层证据，强度不同**（务必分开引用）

> ⚠️ **本节曾出错并已修正**：早先版本把下面那份第三方工程清单当成了「厂商条款」，并写下
> 「产出物的再分发**有条款依据**」。**那半句不成立** —— 依据来自一份自称
> *"It is an engineering checklist, not legal advice"* 的第三方文档。
> 记此以便追溯，也提醒：**同类项目的做法是规范性信号，不是规则本身。**

| 层 | 内容 | 强度 |
|---|---|---|
| **① 官方通道存在** | 扩展 API + 官方 WS 桥接（`easyeda-api-skill`）+ 官方「For AI」指南 + SDK Apache-2.0 | ✅ **事实**（厂商主动铺 AI 接入） |
| **② 同类项目的保守读法** | [`oaslananka/easyeda-mcp-pro` 的 `docs/vendor-terms.md`](https://cdn.jsdelivr.net/gh/oaslananka/easyeda-mcp-pro@main/docs/vendor-terms.md)：**「Project rules」**（该项目给自己定的规则，**非厂商条款**）中明确回避"批量再分发厂商目录数据" | ⚠️ **规范性信号**（别人怎么理解规则），**不是规则** |
| **③ 厂商条款本身** | 见下 —— **本机可取，已读到原文** | ✅ **权威** |

#### ③ 权威条款原文（EasyEDA Terms & Conditions，2026-09-21 生效）

来源 `https://easyeda.com/page/legal`（**本机 HTTP 200**；并行会话环境返回 403 —— 两环境网络策略不同）。第 VII 条「Copyright and Intellectual Property」中：

> Unless expressly authorized by EasyEDA in writing, you shall not, directly or through any third party,
> use any robot, spider, scraper, crawler, script or other automated means to access, scrape, download,
> copy, index or mirror any Content or projects available on the Services … **in a bulk or systematic manner**,
> nor use any Content so obtained for text and data mining, data analytics, machine learning,
> **training of artificial intelligence models, or similar purposes**.

同条紧接着的豁免（**这段同样重要**）：

> … **This clause restricts the bulk or automated collection of content from the Services.**
> For the avoidance of doubt, **you may continue to browse, download and use individual projects
> in the ordinary course.** Nothing in this clause affects your rights in respect of an individual
> project under its applicable open-source license …

#### 对我们的含义（现在**有权威依据**了）

| 动作 | 判定 |
|---|---|
| 人工、逐个、常规浏览公开资料，据此手写 `schema/` | ✅ **明文允许**（"individual projects in the ordinary course"） |
| **自动化批量**抓取厂商内容（robot / spider / scraper / script） | ❌ **明文禁止** |
| 把**如此获得**的内容用于**训练/喂养 AI 模型** | ❌ **明文禁止**（"training of artificial intelligence models, or similar purposes"） |

**⇒ 两条独立结论**：

1. **「不投入」的结论不变，而且现在有权威条款支撑** —— 不只是"同行读法"，是厂商明文禁止批量自动化采集。
2. **★ 这条同时约束了我提的「DS 辅助作者」路线**：若把**批量抓取的厂商内容**喂给 DS 去生成 schema，
   正落在"training of artificial intelligence models, or similar purposes"里。
   **但**：DS 读**器件厂商自己发布的公开数据手册**（如 Bosch 的 BME280 datasheet）不受此条约束 ——
   那不是"the Services 上的 Content"。**⇒ 干净路径是「读原厂数据手册」，不是「读 EDA 平台的库」。**

**注意规模是关键变量**（条款反复用 "bulk or systematic"、"individual … in the ordinary course"）——
这与我们"少量、经人工判断、从公开数据手册整理"的形态一致。

#### ⚠️ 一处必须降级的措辞：**403 是通用反爬，不是政策表态**

早先版本把 `so.szlcsc.com` 与 `easyeda.com/page/legal` 的 403 称为「厂商对自动化访问的主动拦截」「厂商行为信号」。
**那个说法偏强了。** 实测：`easyeda.com/page/legal` 换成**浏览器式请求头**（UA + Accept + Accept-Language）后返回 **200**。

⇒ **403 只能当「存在基础反爬」的证据，不能当「厂商禁止你这么做」的证据。**
**真正有分量的是条款文本**（已由双方各自独立取到原文并逐字核对一致）。

> 这与本项目的失败族同源：**把"能观测到的现象"当成了"它想表达的意思"。**

#### ★★ 关键区分：被禁止的那条路，本来就是个死胡同

| 来源 | 受该条款约束？ | 能给出我们缺的语义吗 |
|---|---|---|
| EasyEDA / LCSC **平台上的库内容** | ✅ **禁止批量采集** | ❌ **本来也给不了**（跨生态已证：无 protocol / voltage） |
| **原厂数据手册**（Bosch / TI / … 自己发布） | ❌ 条款对象是 "any Content or projects **available on the Services**"，原厂手册不是 | ✅ **正是语义的来源** |

> **⇒ 唯一干净的那条路，恰好也是唯一能造出壁垒的那条路。**
> **不是绕开限制，是限制根本不在我们要走的那条路上。**

#### 最终结论的三层（强度各不相同，**不要合并引用**）

1. **抓取 EDA 平台库内容做批量再分发** → **厂商明文禁止**（有原文、有条款号、有生效日期）—— **权威依据**
2. **读原厂数据手册 + DS 做语义判断** → **不受该条款约束**，且这正是壁垒所在
3. **几何（阶段一）** → 受**类别错配**限制（元件库服务于设计芯片的人）—— 与 1、2 都无关

> ⚠️ **1 与 3 是两条独立理由**：即使条款允许，几何那条路也走不通；即使几何走得通，批量抓取也违法。

#### 一条方法学教训（本轮双方各犯一次）

> **证据的来源和证据的内容是两件事，混起来就是「看起来有依据」。**

- 一方把**第三方工程清单**当成**厂商条款**（来源错）
- 一方把**通用反爬 403** 当成**政策表态**（内容解读过头）

两次都是同一个病：**没有把「谁说的」和「说了什么」分开核对**。

**另记两条同源实践**（来自②，将来若真做值得照抄）：产出物附 `THIRD_PARTY_NOTICES.md`；
供应商数据一律标注为"advisory，下单前须人工复核"。

### 8.6 ★★ 生态里已经有人把「作者时工具」做出来了 —— 复用优先于自建

[`zhoushoujianwork/easyeda-agent`](https://unstone.github.io/dsh-xray/p/zhoushoujianwork__easyeda-agent.html)
—— **一个 DeepSeek Harness 插件**：

> 嘉立创EDA专业版自动化：给 AI harness 装上画板的「手」—— 一套 typed 原理图/PCB 动作，
> **CLI / Agent Skill / stdio MCP 三形态融合接入**

**核实过的证据**（dsh-xray 静态分析页已取到）：

| 项 | 值 |
|---|---|
| 读取的环境变量 | **`EASYEDA_BIN`** ⇒ 驱动 EasyEDA Pro **桌面端二进制**，与 §7 推断的架构一致 |
| 扩展注入 | `extension/scripts/hot-reload-inject.js` |
| 许可证 / 热度 | Apache-2.0 · ★ 500+ |
| **评级** | **C3** —— `runtime_patch`（改 dsh 运行时）+ `exec` + `base64_decode` |

**⇒ 这正是 §7.2 提出的「作者时工具」形态，而且已经实现、已发布、开源。**

> **建议：若将来重启这条线，先评估复用 `easyeda-agent`，不要自建。**
> 我们真正独有的东西是 `schema/` 的**语义判断**（protocol / voltage / size）——那部分别人替不了；
> 而「驱动 EDA 拉引脚表」是**通用能力，不该由我们重造**。

⚠️ **C3 评级意味着采用前必须审查**：它会 patch dsh 运行时、执行系统命令、解码 base64 载荷。
「有能力」不等于「有恶意」，但**采用前要看清楚**——这正是评级存在的意义。

---

### 8.7 建议

**不投入。** 理由：三条独立否证 + 一条结构性结论 + 测试本身的不可完成性 + **产出分发触线**（§8.5）。

**重新评估的触发条件**（满足任一才值得回头）：
1. 场景从「板卡与模块组装」转向「芯片级设计」——那时元件覆盖率才有意义
2. 出现**不依赖 GUI 客户端**的元件元数据源（官方或第三方）
3. 需要支持的型号数量从「十几个」涨到「几百个」—— 那时作者时流程的规模效益才成立

> **★ 若触发，第一步不是自建，是评估复用 `easyeda-agent`（§8.6）。**

**在此之前**：`schema/` 继续**人工/DS 辅助作者**，4 个型号 12 个端口，成本可接受。
若嫌手打坐标易错，用 §6.3 的**声明式布局规则**替代 —— **它已落地并验证精确等价**。

---

## 9. 环境备注（复用价值）

- ★ **网络可达性（实测，两台会话环境不同，勿一概而论）**：
  - `raw.githubusercontent.com` —— **两个环境都失败**（SSL 握手 / fetch failed）
  - `github.com` 的 HTML 页 —— **本会话可达**（对方环境不可达）
  - **`cdn.jsdelivr.net/gh/<user>/<repo>@<branch>/<path>` —— 本会话可达**，可取 GitHub 上的原始文件全文 ✅
  - ⇒ 要读 GitHub 上的文件，**优先走 jsDelivr gh 通道**，别用 raw
- `registry.npmjs.org` 偶发超时；**jsDelivr 的 npm 通道稳定**；**GitLab API 稳定**，适合列文件/取原文
- **官方 SDK 主战场是 Gitee 不是 GitHub**（`gitee.com/jlceda/pro-api-sdk`）
- 真包名带 scope：`@jlceda/pro-api-types`；无 scope 的 `pro-api-types` 已于 2024-07-23 unpublish（**照文档去 npm 搜会拿到死包**）
- 方法学收获：**读官方类型定义包比啃 SPA 文档可靠** —— 类型定义是编译期真相，且完全离线可查
- 另一条方法学：**官方 README 的「进入开发」步骤列表会暴露架构真相** —— 正是第 5 步「在客户端中安装扩展包」这一句，暴露了「扩展 API 是 GUI 宿主插件」这个决定性事实。**看安装步骤比看 API 列表更能判断一个 SDK 的形态。**