Skip to content

component-sourcing.zh.md

Latest commit

 

History

History
145 lines (101 loc) · 7.14 KB

component-sourcing.zh.md

File metadata and controls

145 lines (101 loc) · 7.14 KB
Raw

English | 简体中文

选型调研：从需求到料号

本文讲整条链路最前面的一段：手里只有电路需求，怎么变成一份带立创 C 编号的 BOM。 这一段没有脚本可跑，它是调研工作，本仓库提供的是提示词模板—— 把模板交给任意一个具备联网检索能力的 AI，让它按统一的证据标准产出候选， 再用一份核验清单把结果收口。

模板是 AI 无关的：不写「你是某某模型」，不假设执行者了解你的项目，占位符用〈尖括号说明〉标出。 换一个 AI 接手，同一份模板照样用。

在整条链路中的位置

需求规格化          ← 把电路需求写成可检索的参数表
      │  prompts/component-sourcing-brief.zh.md
      ▼
选型调研            ← AI 检索候选, 出主选 + 备选对照表
      │  prompts/part-number-verification.zh.md
      ▼
料号落定 / BOM      ← 逐条核验后才写进 BOM 的 Supplier Part 列
      │  tools/tel2json_netlist.py
      ▼
网表重建导入        ← docs/netlist-import.zh.md
      │
      ▼
PCB / 几何整改 / 下单

为什么把选型单独作为一个阶段。 后面整条自动化链路都建立在一个假设上：BOM 里的 Supplier Part 是对的。这个假设一旦不成立，后面每一步都在把错误传播得更整齐—— tel2json_netlist.py 会忠实地把错编号写进网表，导入会忠实地按错编号放上错器件， fix_supplier_ids.py 会忠实地把错编号刷得更一致。整条链路里没有任何一步会告诉你编号本身错了。

所以选型阶段的产出质量，决定了后面自动化的价值。

两份模板

prompts/component-sourcing-brief.zh.md — 选型调研任务书

给 AI 的任务书。你填需求规格（电气参数、封装、温度范围、成本上限、装配工艺约束、目标产线、供货要求）， 它按固定的证据要求产出候选对照表。

模板里写死的几条硬约束：

  • 每个候选必须给出可查证的供应商编号 + 厂商型号（MPN），两者缺一不可。
  • 每个参数结论必须追到厂商数据手册，注明来源与在手册中的位置。
  • 库存与价格必须标注读取时间和渠道。
  • 严禁凭记忆给编号；没实际检索命中的一律进「未核验」小节单列。
  • 参数不达标就说不达标，写清差在哪一项、差多少、放宽哪一条约束能解决，不许为了凑答案降标准。
  • 输出必须包含「待确认问题」和「未核验项」两节，后者可以为空但不能省略。

对照表要求逐项填，包括库别（基础库 / 扩展库）与上料费影响—— 在嘉立创 SMT 服务里，基础库器件通常不额外收上料费，扩展库按型号收一次性上料费。 同规格多个候选时，这一项对小批量总成本的影响往往超过单价。

prompts/part-number-verification.zh.md — 料号核验清单

写进 BOM 之前的收口。核心是一条强制纪律：

任何 C 编号，必须在器件库中实际检索命中之后才算数。命中 = 检索确实返回了这个编号对应的器件 ＋ 库存 > 0 ＋ 封装与关键参数逐项对上。严禁凭记忆、印象或"看起来像"给出编号。

之所以要把这条写成纪律，是因为元器件编号对语言模型来说是一类特别危险的内容： 格式规整、长度固定，很容易生成出一个格式完全正确但根本不存在、 或者存在但对应完全不同器件的编号。而这类错误在导入之前没有任何症状。

清单按六组逐条打勾：存在性、库存、封装、参数、商务与工艺、一致性。 最后要求输出「未通过项」和「未核验项」。

英文版：component-sourcing-brief.en.md、part-number-verification.en.md，内容对等。

核验的两条通道

通道 A：网页库检索

在立创商城 / 嘉立创元件库的网页界面按编号或厂商型号查。不需要装任何东西，任何人都能用。

通道 B：经桥在 EDA 客户端内查库

如果已经按 README 装好了桥和 run-api-gateway 扩展，可以直接查 EDA 客户端连着的器件库。 好处是查到的就是导入时会用的那个库，不存在"网页上有、客户端库里没有"的偏差。

仓库里的 examples/30_library_search.js 就是这条通道：

# 改脚本里的 KEY(关键词) 或 LCSC_IDS(要核验的 C 编号), 然后
python tools/eda_bridge.py run examples/30_library_search.js

它用的两个 API（签名取自官方 easyeda-api-skill 的 LIB_Device 参考）：

eda.lib_Device.search(key, libraryUuid?, classification?, symbolType?, itemsOfPage?, page?)
eda.lib_Device.getByLcscIds(lcscIds, libraryUuid?, allowMultiMatch?)

检索结果里能拿到厂商、厂商型号、供应商编号、封装、库存、价格，以及库别 （"standard" = 基础库，"extend" = 扩展库）。

字段位置有个坑。 官方参考里，商业类字段（库存、价格、库别、供应商编号、厂商） 在顶层已标记为 obsolete，说明改到 otherProperty 里；顶层字段可能仍在，也可能为空。 所以 30_library_search.js 会同时打印 otherProperty 的原始键名和归一化结果—— 先看一眼你这个版本实际返回了什么再写解析，别照抄别处的字段名。这条和本仓库其它地方一个原则： 不确定就先探一下，别凭文档想当然。

交接约定：选型产出怎么对接后面的流程

调研确认之后，主选的字段按下面这张表填进 BOM。 tools/tel2json_netlist.py 读的就是这些列名（列名有多个兼容写法，下表是推荐写法）：

BOM 列名 取值 后续用途
Designator 位号，支持 R1,R2 逗号列表与 R01-R08 范围 与 .tel 里的位号对齐
Footprint 封装名 参与二级匹配（封装 + 数值）
Value 电气值 参与二级匹配
Manufacturer Part 厂商型号（MPN） 写进网表的 device_name；编号下架时靠它找替代
Supplier Part 立创 C 编号 唯一参与库匹配的字段

tel2json_netlist.py 用三级兜底把位号和料号对起来：精确位号 → 封装 + 数值 → 封装唯一。 三级都配不上的会列出告警而不是猜一个——看到告警就回头补 --override， 别让它带着空编号往下走。

与 fix_supplier_ids.py 的关系

导入之后，器件的 SupplierId 常被设成厂商型号而不是 C 编号，触发 DRC 的「供应商不符」。 tools/fix_supplier_ids.py 按位号从网表把编号批量刷回去。

但要清楚它做的和不做的：

  • 它做的是：保证 EDA 里的 SupplierId 与你网表里写的编号一致。
  • 它不做的是：判断那个编号本身对不对。网表里的编号错了，它只会把错的刷得更整齐。

同理，tools/compare_netlist.py 只校验导入忠实度（编号有没有被正确传递），不校验编号正确性。

编号本身的正确性，只有选型阶段的核验清单能保证。这是把选型写进本仓库的原因。