# Sch2dsl

> Parse Altium Designer .SchDoc files into verified SCH-DSL and use the generated schematic document to answer component, pin, net, power, CAN, signal-path, and topology questions. Use whenever a user provides an Altium schematic, asks for netlist extraction, pin connectivity, circuit-topology interpretation, or wants an LLM-readable schematic representation.

- Skill: `wuwuzhazha/sch2dsl` (Agent Skill)
- Install (CLI): `npx skillmds@latest add wuwuzhazha/sch2dsl`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wuwuzhazha/sch2dsl/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: wuwuzhazha (https://skillmd.com/u/wuwuzhazha)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/wuwuzhazha/sch2dsl

---


# SCHDoc → SCH-DSL → LLM 解读

## Skill 定位

这是一个证据优先的原理图分析工作流，不是截图识别，也不是凭器件型号猜电路。

核心链路：

```text
.SchDoc
  ↓ Rust release parser（优先）
.schdsl
  ↓ 按查询范围读取与交叉核验
事实、网络路径、器件拓扑、带证据的工程解释
```

输出必须区分：

- **事实**：SCH-DSL 中可以直接定位的内容。
- **推导**：由器件类型、引脚名、网络成员和路径组合得到的结论。
- **假设**：文件没有表达、需要结合数据手册或人工确认的内容。

不要把推导或假设写成文件事实。

## 触发条件

用户出现以下任一意图时使用本 Skill：

- `.SchDoc`、Altium、原理图、网表、Netlist
- 器件/引脚/网络/连通关系/电源树
- “某器件接到哪里”“CAN 总线怎么走”“某引脚是否连接”
- “把原理图给 LLM 理解”“生成可检索的原理图文本”

## 0. 输入确认

1. 找到目标 `.SchDoc` 的绝对路径。
2. 找到 Rust 项目：`sch2dsl/Cargo.toml`。
3. 不读取旧的 JSON、中间网表或历史报告作为事实源。当前项目的规范产物是 `.schdsl`。
4. 如果输入不是 `.SchDoc`，先说明不能直接套用本 Skill。

**路径基准**：本 Skill 中所有路径均相对**仓库根目录**（即包含 `sch2dsl/`、`src2xml/`、`docs/` 的目录）。若当前工作目录不是仓库根，先用 `Get-ChildItem -Recurse -Filter Cargo.toml -Depth 2` 等方式定位仓库根，或让用户提供 `.SchDoc` 绝对路径后再推导。

**权威规范**：SCH-DSL 语言规范见仓库根 `docs/SCHDSL-SPEC.md`。本 Skill 与规范冲突时，以规范为准。

## 1. 生成 SCH-DSL

### 1.1 Rust release 二进制优先

优先检查 release 二进制是否已构建：

```powershell
Test-Path .\sch2dsl\target\release\sch2dsl.exe
```

返回 `True` 则直接调用，不要重复编译：

```powershell
& .\sch2dsl\target\release\sch2dsl.exe `
  .\src2xml\input.SchDoc `
  .\src2xml\input.schdsl
```

将 `input.SchDoc` 替换为真实文件名。

如果 release 二进制不存在，且本机有 Cargo，才执行一次构建：

```powershell
cargo build --release --manifest-path .\sch2dsl\Cargo.toml
```

构建完成后重新查找并调用二进制。不要在每次用户查询时重复执行 `cargo build`；编译是安装/部署步骤，不是解析步骤。

### 1.2 生成后检查

解析命令成功后检查：

- 输出文件存在且非空。
- 第一行包含 `#schdsl 1.1`。
- `devices/pins/nets` 统计存在。
- Rust 输出打印 `components/pins/nets/connected/nc`。
- 若统计或校验失败，停止解读，不要用不完整文件推断拓扑。

## 2. SCH-DSL 语义模型

SCH-DSL 由四个固定节组成：

| 节 | 内容 | 读取方式 |
|---|---|---|
| `Types` | 库引用、描述、封装、引脚号和引脚名模板 | 先由器件行的 `@TID` 反查 |
| `Devices` | `位号@类型编号` | 建立器件实例表 |
| `Params` | 实际型号、值、厂商、MPN 等 | 覆盖通用库引用的不足 |
| `Nets` | 网络名、成员数、网络种类、`位号.引脚` 成员 | 直接回答连通关系 |

基本引用规则：

```text
U6@34
T34 ... pins 5,8,1,4,3,2,7,6 names VIO,STB,TXD,RXD,VCC,GND,CANH,CANL
T34!cmt=... mpn=... val=...: U6 U8
CAN0HJ[5]: C604.2 J2.3K R602.2 T601.2 U6_1.4
```

其中：

- `U6.7` 表示位号为 `U6` 的第 7 脚。
- `U6_1.4` 是另一个器件实例，不是 `U6` 的第 1 脚。
- `kind=pwr/gnd/earth` 只在 DSL 明确给出时使用。
- 没有 `kind` 不代表普通信号一定没有电气属性，只代表文件中没有可确认的 PowerPort 类型。
- NC 引脚不出现在 Nets 节，需要用类型引脚集合减去网络成员集合得到。

## 3. 查询工作流

### 3.1 器件查询

回答“某器件是什么、有哪些脚、实际料号是什么”时：

1. 在 `Devices` 找位号。
2. 在 `Types` 找对应类型。
3. 在 `Params` 找真实值、厂商和 MPN。
4. 输出完整引脚表：引脚号、引脚名、网络名。
5. 对缺失参数明确写“DSL 未提供”，不要用库引用猜测实装型号。

### 3.2 网络查询

回答“某网络连接了什么”时：

1. 在 `Nets` 精确匹配网络名。
2. 列出全部 `位号.引脚` 成员。
3. 对每个成员反查 `Types`，补充引脚名和器件类型。
4. 如果网络名有相似前缀，逐字精确区分，例如 `CAN0HJ`、`CAN1HJ`、`CAN2HJ` 不能合并。

### 3.3 路径/拓扑查询

回答“信号从哪里到哪里”时，使用交替路径：

```text
器件.引脚 → 网络 → 器件.引脚 → 网络 → ...
```

每一步都必须来自 Nets 成员。遇到匿名网络（如 `Net_U6_7`）保留匿名名，并说明它是无显式网络标号的物理连通分支。

### 3.4 电源和地查询

- `kind=gnd`：报告为原理图明确标记的地网络。
- `kind=pwr`：报告为原理图明确标记的电源网络。
- `kind=earth`：报告为接壳/保护地类网络，不等同于普通 `GND`。
- 不要因为网络名包含 `GND`、`VDD`、`CAN` 就擅自改变 `kind`。

### 3.5 CAN/差分总线查询

对 CAN、差分信号和隔离器件采用以下顺序：

1. 找收发器引脚名（`CANH`、`CANL`、`TXD`、`RXD`）。
2. 分别查这些引脚的网络，不能只按器件前缀猜。
3. 如果中间存在共模扼流圈、TVS、终端电阻或连接器，逐个展开两侧网络。
4. 明确区分：
   - MCU 侧逻辑信号，如 `CAN6TX-C`、`CAN6RX-C`。
   - 收发器总线侧，如匿名网络 `Net_U6_7`、`Net_U6_6`。
   - 过滤/保护/连接器侧网络，如 `CAN0HJ`、`CAN0LJ`。
5. 只有当同一个网络行同时包含两个引脚时，才能说两者直接连通。
6. “共模扼流圈两侧隔离”是由两组不同网络成员推导出的拓扑结论，不要把器件符号名当作事实证据。

## 4. 解读输出模板

对器件或局部电路使用以下结构：

```markdown
## 结论
<一句话结论；标明这是事实、推导还是假设>

## 直接事实
- <来自 Types / Params / Nets 的内容>

## 连接路径
- <器件.引脚> → <网络> → <器件.引脚>

## 工程推导
- <由多个直接事实组合得到的解释>

## 未确定项
- <SCH-DSL 没有表达或无法唯一确定的内容>

## 证据
- `T...`
- `Params: ...`
- `Net: ...`
```

回答整板摘要时至少包括：

1. 器件数量、引脚数量、网络数量。
2. 主要电源、地、接壳网络。
3. 主要控制器/收发器/连接器及其关键网络。
4. 关键跨器件信号路径。
5. 未连接引脚或匿名网络的数量和影响。
6. 明确列出无法从 `.SchDoc` 确认的事项。

## 5. 证据等级

| 等级 | 含义 | 写法 |
|---|---|---|
| L1 直接 | 同一行或类型表直接给出 | “文件明确显示……” |
| L2 组合推导 | 多条网络/类型事实组合 | “由……可推导……” |
| L3 外部假设 | 需要数据手册、PCB 或人工确认 | “可能……但当前文件无法确认” |

默认只把 L1/L2 写入确定性结论；L3 必须单独放在“未确定项”。

## 6. 反模式

禁止以下行为：

- 用截图坐标代替 SCH-DSL 网络成员。
- 把 `U6`、`U6_1`、`U6_2` 按前缀合并。
- 把不同网络名但相似字符串的网络合并。
- 把 `U6.7` 直接写成 `CAN0HJ`，除非 Nets 明确包含该成员。
- 把器件库引用当成实际制造商型号。
- 把 `T601` 的器件名当成“串联”或“并联”结论；必须展开它的各个引脚网络。
- 把匿名网络自动改名为熟悉的信号名。
- 把“文件没有记录”说成“电路一定不存在”。
- 只列网络名而不列完整成员，导致拓扑无法复核。
- 解析失败、统计不一致或网络成员校验失败时继续给出确定性拓扑结论。

## 7. 质量门禁

提交解读前检查：

- [ ] 解析器成功运行。
- [ ] `.schdsl` 头部版本和统计存在。
- [ ] 生成工具的校验通过。
- [ ] 每个引用的器件位号在 `Devices` 中存在。
- [ ] 每个网络成员的引脚号在对应类型中存在。
- [ ] 关键结论至少有一条 `Nets` 证据。
- [ ] 区分直接事实、组合推导和外部假设。
- [ ] 没有把匿名网络或相似位号错误合并。
- [ ] 对 CAN/差分/电源路径逐跳列出。

## 8. 可选性能策略

- 单张和批量原理图统一使用 Rust release 解析器。
- 不要为了读取一个局部网络而重复生成文件；一次生成后按节和网络名检索。
- 当前 Rust release 版本对示例图的端到端结果约 64 ms；速度不是降低证据要求的理由。