PCB assets - 执念 - Ivan's Blog

Definition

PCB assets 表示仓库把 PCB 设计文件、板级资产或硬件工程输出当成真相源之一来维护，而不是只把它们当附件。这里的重点是电路板资产与固件/文档的同步关系，而不是“仓库里有几个截图”。

它通常会和 C firmware、Device mono-repo 一起出现，但不替代这些 Topic：PCB assets 解释板级资产的维护边界，其他 Topic 解释固件或设备整体结构（projects/whisker-breeze.md）。

当 project snapshot、目录结构或文档明确表明仓库把 pcb/、板级设计文件、制造输出或相关硬件资产与固件一起维护时使用。若只是少量图片、原理图截图或外链，不应命中。

如果一个改动会影响 pinout、板级连线、制造/装配输入、硬件版本关联或固件与板级资产的一致性，就应该命中本 Topic。

Co-locating PCB + firmware simplifies correlating hardware and software changes (projects/whisker-breeze.md)
把 PCB 与 firmware 共仓能降低板级变更和软件变更脱节的风险，但前提是 Topic 里要写清哪些文件才是板级真相源。
回答此 Topic 时，应优先说明板级资产如何影响 pinout、接口和 bring-up，而不是只说“有 pcb 目录”。
硬件版本、板修订或制造输出若会影响固件配置，就应在知识库里显式留下关联；否则后续很容易拿错板/拿错资产。
默认应把板级资产当成“会反向约束软件”的输入来读：例如电源轨、接口走线、触控/显示/风扇连接、debug header 和测量点，这些都决定 firmware 的 pin 定义、初始化顺序和 bring-up 手册该怎么写，而不是等软件调不通了才回头看原理图。
若仓库同时维护制造输出、装配说明或板修订记录，回答里应明确哪些文件是设计源、哪些只是导出物。把 Gerber、截图和最终 BOM 全混成一个层次，会让后续维护者不知道该改哪里才算真正修改了硬件。

projects/whisker-breeze.md：直接样本。它说明 PCB 资产不是旁支材料，而是与固件和文档一起组成板级真相的长期维护面；当仓库把整机、控制板和软件放在一起时，板级资产会直接影响 pinout、bring-up 和后续板修订沟通方式。
skills/style-pcb-assets/SKILL.md：对应 group Skill 证明这类知识在消费时不会停留在“有硬件文件”这一层，而会要求 Agent 回答板级资产怎样约束软件、文档和维护动作。对窄样本 Topic 来说，这个反向消费面本身也是重要证据。

只因为仓库里有几张硬件图片就打 PCB assets，会把真正的板级真相源和展示材料混在一起。
把 PCB assets 当成整个仓库的总括标签，忽略 C firmware、Device mono-repo 等相邻 Topic，会让后续 Agent 无法判断真正该看的是板级资产、固件入口还是整机结构。
不写板修订、pinout 关联和制造输入，会让 PCB 资产存在却无法指导维护动作。
把 PCB 目录当静态附件不回读，也会让板级变更与固件语义发生长期漂移。