# 维修台上的 AI， 扎根于你的文档。

> WrenchBoard 如何读懂一块板：约两分钟内从原理图和 boardview 构建设备专属 knowledge pack，运行时零 LLM 调用的确定性故障引擎，以及一个无法凭空捏造元件位号的诊断 agent。

Source: https://wrenchboard.cloud/zh/ai-repair-bench

把原理图 PDF 和 boardview 拖进 WrenchBoard，大约两分钟后，你面对的就是一台系统真正认识的设备：元件已编目，net 已分类，启动时序已梳理，故障规则已审核。这两分钟里发生了什么，以及为什么此后 agent 告诉你的一切都不是碰运气，本页说清楚。

## 从文档到可用知识，*只要两分钟*

一位见过某块板一百次的资深技师，把它的架构装在脑子里。WrenchBoard 在第一支表笔碰到板子之前，就把这个心智模型显式地构建出来。

构建由一组专职 Claude 角色流水线完成：Scout 收集设备已知信息，Registry 固定元件清单，三个 Writer 并行工作（一个绘制板卡地图，一个撰写故障临床图景，一个编纂术语表），Auditor 在入库前审核结果。从原理图 PDF 和 boardview 出发，整个流程约两分钟。

产出不是一篇文章，而是落在磁盘上的、按设备组织的可查询语料。之后的每次诊断会话都从中读取、向其写回：测量值、确认的故障原因、待解的问题。没有什么需要从零开始。

## 原理图变成*一张可以提问的图*

六十页的原理图 PDF 是给有大把时间的人类看的文档。WrenchBoard 用 Claude 的视觉能力逐页编译它，得到一张电气图：有哪些 net、各属于什么类别、上面有哪些元件、启动时序长什么样，并附带一份质量报告，说明文档有多大比例被高置信度读取。

这次编译把「在 PDF 里搜索」变成「向板子提问」。某个元件是干什么的、谁和它共轨、这一启动相位哪些点应该带电：答案几秒内从图里给出，引用的是图，不是模型的记忆。 编译器本身另有[专门的页面](https://wrenchboard.cloud/zh/schematic-to-graph)。

## 推理之下是*确定性引擎*

agent 不猜因果链，它把因果链交给算法。诊断栈的核心是两个纯算法引擎，运行时零语言模型调用：

- **模拟器**逐相推进板卡的启动时序，输出一条时间线：哪些电源轨已死、哪些元件失电、每一相被什么卡住。
- **假设引擎**接收部分观测，也就是你实际做过的那几次测量，枚举能解释它的单点和双点故障候选，按吻合度排序。

确定性意味着可核验：同样的测量永远产出同样的候选，每条因果链都能对照电气图手工检查。agent 的职责是在这副脚手架之上用平实语言推理，并适配[使用它的技师](https://wrenchboard.cloud/zh/learn-microsoldering)的水平，而不是即兴发挥电子学。

## 维修台上的一次会话，*烙铁在你手里*

在维修台上，agent 一边陪你工作一边驾驶 [boardview](https://wrenchboard.cloud/zh/boardview-viewer)：高亮要测的引脚，描出可疑的 net，把测量方案直接标注在板卡上。推理需要眼睛时，它向你的 USB 显微镜请求一帧画面；你也可以把可疑芯片的特写拖进对话。

你测量，它解读，循环继续。每次测量都被记录，每张照片都被保存，整个会话事后可以回放：说了什么、决定了什么、agent 真正看到了什么。[完整的诊断工作流](https://wrenchboard.cloud/zh/motherboard-diagnostics)按资深技师的方式组织，但烙铁从不离开你的手。

## *诚实的*边界

WrenchBoard 在手握原理图和 boardview 时最强；已验证的清单和确定性因果链正是在这里全速运转。缺少这些文档时，它仍会从公开资料构建第一版 knowledge pack：有用，但单薄。这个差距不是软件的局限，而是文档获取的问题，也正是[「太复杂无法维修」背后的真正议题](https://wrenchboard.cloud/zh/too-complex-to-repair)。项目的标准开发目标板是 MNT Reform 主板，选它正因为其文档以 CERN-OHL-S 许可证开放。

## 常见问题解答

### knowledge pack 到底是什么？

系统在任何诊断开始之前为每台设备构建的结构化语料：元件清单、分类后的 net、推断出的启动时序、已知故障规则。它由四类专职 Claude 角色（Scout、Registry、三个并行的 Writer、Auditor）在约两分钟内组装完成，然后落盘存储，供之后每次会话查询和补充。

### 必须有设备的原理图和 boardview 吗？

两者齐备时系统表现最好：确定性引擎正是在这里产出可验证的因果链。缺少文档时系统不会瘫痪，而是从公开资料构建第一版 knowledge pack。两种模式之间的差距，正是维修权立法要弥合的差距。

### 这里说的确定性，具体指什么？

agent 的推理之下有两个引擎：一个启动时序模拟器，逐相推进并输出死轨和断电元件的时间线；一个假设引擎，针对部分观测枚举能解释它的单点和双点故障候选，并按与实测的吻合度排序。两者在运行时都不调用语言模型：同样输入，同样输出，每条链都可以手工核验。

### agent 真的能看到我的板子吗？

能，由你决定。把 USB 显微镜或摄像头接到工作台，agent 在推理需要时请求一帧画面；你也可以随时把微距照片拖进对话。拍摄记录随维修工单持久保存，整个会话可以完整回放：说过的话、做过的决定、agent 看过的照片。

### 如果 agent 引用了一个不存在的元件会怎样？

它无法断言这样的元件。位号查询失败时工具会返回最接近的真实候选，agent 必须从中选择或向你确认。第二道防线是服务端的 sanitizer：它扫描每条输出消息，把无法在已解析的板卡数据中核实的位号显式标记出来，然后才允许文本上屏。