@huaqiu/dsh-kicad 0.4.13 → 0.5.2

package/lib/index.mjs

@@ -131,6 +131,11 @@ const KICAD_SKILLS = {
 		id: "hardware-design-brief",
 		summary: "Turn a market need into verifiable hardware requirements: clarify them through staged questioning and write the market MRD, the hardware PRD and the schematic/PCB design inputs. Use when defining requirements for a new board project.",
 		ownsScripts: false
+	},
+	"pcb-initial-placement": {
+		id: "pcb-initial-placement",
+		summary: "Produce a Phase-1 initial placement for a KiCad PCB that has a netlist but no layout yet: functional clustering, anchor placement, zone partitioning, overlap-free packing and a handover report; prefer applying the result to the open board through the KiCad IPC API, falling back to an offline board file only when IPC is unavailable. Suited to 20–200 components on a single, mostly single-sided board.",
+		ownsScripts: false
 	}
 };
 /** The bundled skill ids, in registration order. */

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@huaqiu/dsh-kicad",
-  "version": "0.4.13",
+  "version": "0.5.2",
   "type": "module",
   "main": "./lib/index.mjs",
   "types": "./lib/index.d.mts",
@@ -22,7 +22,7 @@
     "@deepseek-ai/dsh-tools": "^0.1.0-rc.0"
   },
   "dependencies": {
-    "@huaqiu/dsh-plugin-log": "0.4.13"
+    "@huaqiu/dsh-plugin-log": "0.5.2"
   },
   "files": [
     "lib",

package/skills/hardware-design-brief/SKILL.md

@@ -1,55 +1,89 @@
 ---
 name: hardware-design-brief
-description: "通过分阶段提问澄清硬件产品需求，生成市场 MRD、硬件 PRD，以及原理图和 PCB 设计输入；适用于新电路板项目的需求定义。"
+description: "面向团队与 Maker，将产品想法或已有需求转成 MRD、硬件 PRD，以及可指导原理图和 PCB 设计的硬件方案；完成核心器件选型、电路拓扑、接口与引脚规划、电源预算和多 PCB 分解。支持文档审核与变更追溯，不直接代替 EDA 绘图和布局布线。"
 ---
 
-# 硬件产品需求与设计输入
+# 硬件产品需求与方案定义
 
-帮助工程师把市场需求逐步转成可验收的产品要求，再转成原理图和 PCB 设计输入。按用户实际请求生成其中一份或整套文档，不强制补齐未请求的阶段。
+帮助工程师回答“为何做、做到什么程度、选什么、怎样连接、如何验证”。默认终点是**完成可供原理图展开、并指导后续 PCB 的硬件实施方案**：后续工程师无需重新选择核心器件、设计主要接口或重新决定模块连接。方案完成不等于实测通过或生产放行。
 
-## 本技能与同包能力的配合
+## 先确定范围与深度
 
-安装 `@huaqiu/dsh-kicad` 后，本技能随该插件一起可用，无需单独安装技能。
+先读已有资料，识别产品/单板边界、当前阶段、目标产物、关键约束及项目目录。信息足够时直接工作；不要要求用户重新填写已有信息。
 
-本技能是**知识型技能**：它不注册任何工具，只提供提问流程、文档结构和“已确认 / 有来源 / 建议 / 假设 / 待确认”的区分口径。同包内的 `kicad-ipc` 技能负责把本技能产出的设计输入落到实际 PCB 上，并提供一组 `kicad_pcb_*` 工具（新建走线、过孔、铜区、移动/旋转封装、删除选中对象等）。
+按项目风险、复杂度和协作需要裁剪，不按用户资历增加文档：
 
-两者的分工是：
+| 情况 | 使用方式 |
+| --- | --- |
+| Maker、学习验证、一次性工装、明确用途的小改版 | 精简管理文档：可将背景、需求与完整实施方案合成一份；选型、电路、连接和预算深度与企业项目相同，不要求市场规模或销量 |
+| 新产品、商业化、小团队多人协作 | 标准：MRD、硬件 PRD、硬件方案；选型理由、假设、验证与风险在对应文档内说明 |
+| 多 PCB /跨团队项目 | 按整机→单板→板间接口分解，给每块自研 PCB 独立的需求分配和实施方案；小项目可按章节拆分，复杂项目分文件 |
+| 关键技术不确定、后果严重或受监管的产品 | 加深关键试验、接口和证据；有关键缺口时交付受限草案，不冒称方案完成 |
+| 已有 PRD、仅审核/修改某份文档 | 从当前阶段进入；补必要前提和缺口，不倒推编造 MRD，不自动重做整套文档 |
 
-| 阶段 | 归属 | 产出 |
-| --- | --- | --- |
-| 市场需求、产品要求、设计输入 | 本技能 | `docs/01-MRD.md`、`docs/02-hardware-PRD.md`、`docs/03-design-brief.md`、`docs/decisions.md` |
-| 把设计输入落到 PCB（读取、修改、验证、保存） | `kicad-ipc` 技能 + `kicad_pcb_*` 工具 | 实际板卡改动 |
+精简的是管理开销，不是电路方案。Maker 采用现成模块时，要明确模块型号/版本、实际引脚、电源和互连，不能只写“用一个传感器模块”。对新手解释选择及连接方法，不把选型工作以问题清单推回给用户。
 
-当讨论进入“具体要在板上做什么”时，参照 `kicad-ipc` 技能：任何改动前先用 `kicad_ipc_diagnose` 确认 KiCad 可连接，改动后重新读取受影响的状态确认，保存由 `save` 参数显式控制。
+## 主流程与阶段边界
 
-`references/` 下的三份指南按需读取（见下文），它们是本技能的一部分，不会自动全部加载。
+```mermaid
+flowchart LR
+    A[需求来源：市场 / 用户任务 / 已有产品] --> B[MRD 或精简立项说明]
+    B --> C[产品需求与硬件 PRD]
+    C --> D[硬件实施方案：分板 / 选型 / 电路 / 互连 / 预算]
+    D --> E[原理图展开与 PCB 设计]
+    D --> F[关键假设验证或概念原型]
+    F --> C
+    F --> D
+    C --> B
+```
+
+MRD 回答谁需要、为何值得做；PRD 定义整机结果、验收及已有板级边界；硬件方案确定实现路线、核心器件、电路连接和板级分配。可行性分析可提前介入；新增分板决策反馈 PRD，不能把主流程当作不可回退的瀑布。
+
+**完整方案必须同时有图、有选型、有电路、有连接、有预算**。至少有系统框图和电源树（简单项目可合图），每块自研 PCB 有板内模块连接与电路说明，多板还必须有板间互连表。采用采购模块时落实其外围和实际接口，不要求重设计模块内部电路。方案的章节和技术粒度统一参考 [交付结构与验收清单](references/solution-deliverable.md)，不因 Maker 身份降级成宏观简报。
+
+本阶段要给出推荐封装、关键外围及参数依据、保护/驱动/复位/烧录方案、连接器与信号分配、布局布线约束。层数、板厚和外形应有已知约束或有依据的建议；涉及阻抗、隔离和散热时给设计目标。完整原理图绘制、全部位号/焊盘、最终叠层及布线、制造装配文件仍由后续落实。具体划分见 [阶段边界指南](references/stage-boundaries.md)。
+
+## 最小文档集合
 
-## 文档位置与关系
+生成文件放在**项目根目录的 `docs/`**，不要放进 skill 的 `references/`。用户已有命名与目录时沿用；已有明确工作目录时直接使用，不专门询问保存位置。确实无法判断目标目录时再询问，内容编写可继续。
 
-把生成的项目文档放在**项目根目录的 `docs/`**，与本 skill 的 `references/` 分开。整套文档使用以下文件名；用户已有命名约定时沿用其约定，不另建重复文件。
+标准模式默认使用：
 
 ```text
 docs/
-├─ 01-MRD.md                 市场需求：目标客户、场景、机会与商业边界
-├─ 02-hardware-PRD.md        硬件产品需求：产品必须达到什么、如何验收
-├─ 03-design-brief.md        原理图和 PCB 设计输入：如何落实已确认要求
-└─ decisions.md              假设、未决问题、决策及变更依据
+├─ 01-MRD.md                 市场/立项依据、场景、成功目标与范围
+├─ 02-hardware-PRD.md        整机/板级需求分配、接口边界、验收方法
+└─ 03-design-brief.md        整机方案与单板实施方案，或多板方案索引
 ```
 
-MRD 说明“谁需要、为何需要”；PRD 定义“产品必须达到什么”；design brief 将已确认的 PRD 要求转成可供原理图和 PCB 开工的约束与选择。使用稳定编号串联：MRD 为 `M-001`，PRD 为 `H-001`，PRD 标注来源的 MRD 编号，design brief 引用相关 PRD 编号。只给可追溯的需求编号，避免给普通叙述逐句编号。
+**默认不创建或维护独立的 `decision.md` / `decisions.md`，也不建立决策编号、签核或逐阶段确认流程。** 选型理由写在选型处，假设注明在相关参数旁，关键未决项集中在受影响文档末尾。只有用户明确要求独立决策日志，或已提供的团队规范明确要求时才使用。既有日志保留历史和必要引用，不因其存在自动恢复逐项确认或要求用户批准迁移。
+
+保留 `03-design-brief.md` 文件名以兼容旧项目，标题与内容改为“硬件方案设计”。更新旧文件时保留仍有效的详细约束，并标注阶段归属，不擅自删除工程输入。
+
+精简模式默认生成 `docs/project-brief.md`，以章节承载完整需求和实施方案；不以“简报”为由省略选型或电路。多板项目在 MRD 中识别已知产品组成，在 PRD 中分配整机/单板要求，在方案中明确每种 PCB 的稳定编号、数量、边界和互连，并逐板展开。通常增加 `docs/boards/B01-名称.md` 等单板文件和 `docs/interfaces/board-interconnects.md`；用户只要一个文件时改为独立板级章节和公共互连表。详见 [多 PCB 指南](references/multi-board-guide.md)。
+
+非市场驱动项目不要求单独 MRD；用户仅请求一份文件时只交付该文件，把前提、板级分解、风险和待办内嵌。
+
+不要以文件数量判断完整性。核心选型表和工程 BOM/成本估算是本阶段产物；用于投产的完整 BOM、EDA 文件、实测报告和生产装配包由后续形成。每项信息保持唯一维护位置并建立引用。
+
+## 工作方式
 
-## 对话与生成
+1. **选择入口**：记录本次阶段、采用的文档深度和已有输入。审核时先报告缺陷及影响，再在授权范围修改；小改动只更新受影响项。
+2. **仅询问真正需要用户判断的缺口**：先利用已有输入和可查资料。只有无法据此确定、无法用可接受假设继续，且会实质改变产品目标、硬约束或关键方案的问题才询问；尽量合并一次提出，附推荐及影响。普通选型、可计算参数、文档结构与下一阶段是否继续，由模型在授权范围内直接处理。新问题出现时再补问，不将问答轮数当作流程。
+3. **主动完成工程决策**：对已有充分条件的模块核对资料、选定推荐基线、规划连接并计算参数，直接用于后续文档，不逐项请求批准。可逆且不影响核心要求的缺口使用明示假设继续；真正缺少的关键外部条件只限制相关部分。资料核实、计算或试验任务由相应工作解决，不转换成让用户逐条“确认”的问题。缺少关键证据时如实标明范围，不编造完成状态。
+4. **建立证据**：分别标明用户确认、外部资料事实、工程推算、建议、假设和待确认。核对当期竞品、价格、器件能力/供货及适用标准时记录链接、资料版本或查询日期；无法查证时说明局限。目标、计算估计与实测结果分别记录。
+5. **连续编写和自检**：请求整套文档时按 MRD → PRD → 方案连续完成，阶段检查由模型内部执行，不在每份文件结束时停下要求确认。缺上游文件时引用用户输入或已有规格；冲突若已有优先级或授权可据此处理，否则只对确实需要用户取舍的部分提问，其他工作继续。
+6. **检查并交付**：按交付清单核对需求→板卡→器件/电路→接口→验证，检查封装/引脚、资源与存储容量、电源兼容、板间针脚、成本加总、图表一致性。报告可进入原理图的具体板卡/模块与阻塞范围。仅有框图、候选类别和待办清单不算完成硬件方案。
 
-1. 先阅读用户提供的背景和已有文档，确认项目根目录、目标交付物及已知约束。若项目位置明确，直接使用；不要重复询问已给出的信息。
-2. 按影响决策的程度分批提问，每轮只问少量相关问题，允许部分回答或填写“暂不确定”。先解决会改变目标市场、产品范围、核心功能、供电、接口、尺寸、层数或成本的问题。
-3. 区分**已确认**、**有来源的事实**、**建议**、**假设**和**待确认**。市场数据、竞品参数和器件能力若未核实，不写成事实；关键未知不能用臆测填满。遇到互相冲突的要求，指出冲突并请求取舍。
-4. 生成用户要求的文档；若用户要求整套文档，按 MRD → PRD → design brief 的依赖关系编写，并在 `docs/decisions.md` 记录会影响后续设计的假设和未决事项。缺少上游文档时，也可先做下游草案，但应标注其市场或产品前提。
-5. 检查各文档中数值、单位、状态和编号是否一致。下游文档不能把上游的假设或待确认事项升级为已批准要求。对更新过的要求，指出受影响的后续条目。
+用户只想讨论时先讨论，不强制落盘。只要没有新的实质冲突，不重复确认用户已给出的信息或已授权的选择，也不以“请确认后再生成下一份文档”收尾。文档保留版本/日期、来源和实际证据状态；“未由用户签核”本身不阻塞编写、推荐选型或方案交接，不能据此新增审批。不得把工程建议冒充用户要求，或把未执行试验写成通过。用户明确要求阶段审批时才按其要求暂停。
 
-按当前任务读取对应指南，不必一次加载全部：
+## 按需读取
 
-- 创建或更新 MRD：阅读 [references/mrd-guide.md](references/mrd-guide.md)。
-- 创建或更新硬件 PRD：阅读 [references/hardware-prd-guide.md](references/hardware-prd-guide.md)。
-- 创建或更新原理图与 PCB 设计输入：阅读 [references/design-brief-guide.md](references/design-brief-guide.md)。
+- MRD 或精简立项说明：[mrd-guide.md](references/mrd-guide.md)。
+- 产品需求及硬件 PRD：[hardware-prd-guide.md](references/hardware-prd-guide.md)。
+- 每次生成或审核完整硬件方案，读取 [design-brief-guide.md](references/design-brief-guide.md) 和 [solution-deliverable.md](references/solution-deliverable.md)。后者将用户提供案例的深度转成通用交付规范，并链接案例全文。
+- 多 PCB 或产品组成尚需分板决策：[multi-board-guide.md](references/multi-board-guide.md)；MRD、PRD 和方案阶段均适用。
+- 判断 PCB/装配细节是否属于当前阶段，或准备详细设计交接：[stage-boundaries.md](references/stage-boundaries.md)。
+- 整套文档、审核及跨文档变更的内部一致性与验证检查：[project-controls.md](references/project-controls.md)，不据此增加审批流程。
 
-用户只想讨论方向时先讨论；用户只要求一份文件时仅创建或修改该文件，必要的未决问题可直接列在该文件末尾。
+只加载本次工作相关指南。单文件任务也应保留最小追溯：稳定的需求编号（MRD 为 `M-001`，PRD 为 `H-001`）、来源、验收依据、未决项；普通叙述无需逐句编号。

package/skills/hardware-design-brief/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
-  display_name: "硬件需求与设计输入"
-  short_description: "通过提问生成市场 MRD、硬件 PRD 与电路板设计输入"
-  default_prompt: "使用 $hardware-design-brief 帮我梳理市场需求、硬件产品需求和电路板设计输入。"
+  display_name: "硬件需求与方案设计"
+  short_description: "为团队与 Maker 生成可指导原理图的选型、电路及互连方案，支持多 PCB 分解"
+  default_prompt: "使用 $hardware-design-brief，基于已有需求完成可供原理图和 PCB 设计使用的硬件方案，明确核心器件与封装、电源和接口电路、模块及板间连接、预算和验证；若有多块 PCB，请逐板拆分。"

package/skills/hardware-design-brief/references/design-brief-guide.md

@@ -1,16 +1,89 @@
-# 原理图与 PCB 设计输入
+# 硬件实施方案：原理图和 PCB 的主要设计依据
 
-本文件将已确认的产品需求转成开工约束，保持简练。先从 PRD 和已有设计资料提取信息，再追问会影响电路架构和 PCB 实现的事项：
+方案必须落实到“选什么器件、怎么连接、采用什么电路、关键参数多少、为什么可行”。适用于 Maker 和企业；差别在管理形式、规模和验证强度，不在电路内容是否具体。每次完整方案同时读取 [交付结构](solution-deliverable.md)，多板项目再读取 [多 PCB 指南](multi-board-guide.md)。
 
-- 电源输入、各电源轨、电流/功率预算、负载、时序和保护。
-- 核心器件及所需计算、存储、外设、封装、供货和软件/工具链条件。
-- 有线/无线接口、连接器、电平、速率、线缆长度、隔离、调试与测试接口。
-- 板外形、板厚、安装孔、禁布区、器件高度、连接器位置和方向。
-- 层数、叠层、铜厚、阻抗、高速/模拟/大电流/天线区域、散热和 EMI 约束。
-- 制造、装配、检测、维修、环境及适用标准的设计输入。
+## 输入和完成深度
 
-建议将 `docs/03-design-brief.md` 组织为：项目目标与适用 PRD 编号、原理图设计要求、PCB 设计要求、关键器件表、待确认与验证。原理图部分说明功能分区、核心器件、电源、接口、保护和测试点；PCB 部分说明尺寸、层数、机械、布局与工艺约束。每项关键设计要求引用相关 `H-` 编号；若是工程建议而非 PRD 硬性约束，标明“建议”。
+先提取 PRD 版本、用途、硬约束、产品组成和已有设计。无 PRD 时在方案内建立最小需求表，不强制补未请求的市场文件。给每种 PCB 稳定编号，明确自研板、采购模块和非 PCB 组件，避免把整机描述误当单板方案。
 
-区分**指定器件**、**候选器件**和**待选**。具体候选需有足够的功能、电气、封装和供应信息支撑，并说明选择依据与待核实项；未经核对的候选不可写成批准选型。PCB 尺寸、层数、板厚、铜厚和阻抗优先记录明确边界；若用户需要建议，可基于密度、速率、阻抗、电流、散热、EMI、成本及制造能力提出建议值。未知参数写“待确认”，不虚构精度。
+目标是形成**单一、可实施的推荐基线**。比较路线后应选出主方案；用户批准、供应商承认、实测验证分别记录。重要外部输入缺失时可以形成条件化分支，但不能将核心器件和接口全部留待原理图阶段。无法核实资料的器件只能作为待核实候选，相关模块不能宣称已具备完整设计输入。
 
-对安规、EMC、热、信号完整性及可制造性，列明需要计算、仿真、打样或测试的验证事项。design brief 是设计输入，不代表这些项目已经满足要求。
+推荐基线一旦有充分依据，直接用于电路、互连、预算及后续文档；不逐个询问用户是否同意料号、外围值或模块划分。理由写在对应选型/参数旁，不另建决策日志。资料、供应商或试验尚待核实不等于必须让用户回复“确认”；只有无法代决的关键需求冲突才需要询问。
+
+## 系统框图、电源树与工作过程
+
+完整方案至少包含系统框图、电源树，以及各板板内功能连接。简单单板可以合图；多板必须标出板界、板号、实例数量及板间连接编号。图中显示实际推荐器件或模块、电源轨和信号类型，不能只有抽象的“控制/显示/电源”。电源树给输入、保护/开关、变换级、供电域、负载及使能/时序关系。
+
+配套说明数据流、上电/复位、启动、自保持/休眠/关机（适用时）、正常工作和关键异常状态。需要锁存、隔离、热插拔或掉电保存时，用简化电路/逻辑图或明确的连接表说明路径，不能仅写“采用保护电路”。方案中的电路示意无需替代完整 EDA 原理图，但必须能指导其绘制。
+
+核对图、器件表、信号表和预算中的名称、板号、电压和状态一致。每个有源模块有真实供电路径；隔离两侧分别说明电源和地，调试或线缆不能无意跨接隔离域。
+
+## 核心器件选型必须完成
+
+至少落实决定电路和接口的主控、传感/采集、存储、通信、显示/驱动、电源转换、关键保护/监控、连接器和定制组件；不适用的模块不添加。逐项给：
+
+| 板号/模块 | 主选厂家及完整型号/版本 | 封装与关键规格 | 选择依据/资源余量 | 必需外围及资料 | 备选与替换影响 | 状态 |
+| --- | --- | --- | --- | --- | --- | --- |
+
+- 型号必须对应确切的器件变体和封装；资料记录原厂链接、版本及页码/章节，器件电气能力以原厂资料为准。定制件用受控组件规格/版本和供应接口，不能只给其内部芯片型号。
+- 核对正常供电范围、温度、性能、接口、电平、引脚、复用、资源和实现条件；不能用绝对最大额定值论证正常工作。对 MCU 核查 Flash/RAM、工具链和关键软件库需求。
+- 模块路线明确模块 SKU/硬件版本、原理图/引脚资料、板载稳压/上拉/电平转换；芯片规格不自动等于模块行为。
+- 主选是本方案拟采用的具体实现，不是“一类芯片”。备选非必需；有备选则区分可直接替换、需重布板、需改固件/校准，不能将接口或封装不同的器件列为无条件替代。
+- 工程师能依据资料选定的内容由模型完成，不要求用户替模型查手册或选封装。关键资料不可得时保留明确缺口，不能编造型号、引脚号或供应商承诺。
+
+## 逐模块电路方案
+
+每个实际功能模块给出：承担的需求、主器件、拓扑/参考设计、关键连接、关键外围及初值/范围、计算或手册依据、异常行为、PCB 注意事项。不要逐模块重复泛化口号。
+
+| 模块（按实际适用） | 应达到的电路指导深度 |
+| --- | --- |
+| MCU 最小系统 | 各供电脚/电源域、去耦、时钟、复位/启动模式、调试烧录、关键外设与 GPIO 分配；独立时钟或内部时钟的选择依据 |
+| 电源及电池 | 选定变换拓扑和料号、输入/输出及容差、反馈/电感/电容关键参数、使能和启动条件、保护/反接/锁存、掉电与欠压策略；检查 VIN 跨 VOUT 时是否仍可稳压 |
+| 传感/模拟采集 | 激励、偏置、调理/滤波、参考电压、ADC 输入与保护、测量范围/误差分配、连接与接地；数字探头也要说明接口外围和供电控制 |
+| 通信和板间接口 | 收发/电平转换/隔离主选、端接/偏置/上拉的位置和值或计算范围、默认状态、保护/回流和线缆边界 |
+| 显示/负载驱动 | 控制器到驱动器的实际信号、驱动器到负载连接、段码/通道映射、限流及 MOS/三极管驱动、负载峰值和保护；不只列显示器件 |
+| 存储与校准 | 容量和地址分区、写保护、记录长度/数量、CRC/双副本/元数据空间、擦写寿命、页写限制与掉电一致性；合计后核对所选器件容量 |
+| 人机、检测与调试 | 按键/检测的有效极性、上下拉/消抖、断线/短路处理、蜂鸣和背光驱动、烧录测试接口及防反灌策略 |
+
+关键阻容、阈值和外围不是全部后置：能由规格与参考设计确定的给推荐初值并注明依据，需依实物调整的给范围、计算和验证条件。最终全部阻容位号和 EDA 网表可在原理图阶段完善；不能用“后续计算”代替本阶段足以决定选型和连接的计算。
+
+## 接口、信号和引脚规划
+
+按实际连接输出信号表：
+
+| 板号/连接编号 | 信号名 | 源器件/模块及引脚 | 目的器件/模块及引脚 | 方向/类型 | 电压域/电气范围 | 速率/地址/时序 | 上下拉/端接/保护/默认状态 |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+
+关键 MCU 外设分配到具体实例与可用引脚，检查复用、调试、启动脚和模拟限制。对已选封装给经手册核实的脚名/脚号；简单非关键 GPIO 可给临时映射，但须已证明资源无冲突，并标清可调整范围。不得仅以 GPIO 总数量充足替代引脚复用检查。
+
+协议名不能代替接口实现。例如显示驱动器的 CS/WR/DATA 不应被省略成“LCD 接 MCU”；RS-485 还要明确收发器、线制、方向控制、协议约定、端接与隔离；I²C 要明确开漏、地址/速率、上拉电源和集中位置、总电容及上升时间。给电阻初值时说明适用条件，不能把通用示例数值直接冻结。
+
+每条跨板连接增加两端连接器及配对型号、针序/针脚映射、视图方向、地/屏蔽、线缆/FPC 规格、供电方向、电流和压降、热插拔/掉电状态。板上器件脚号和连接器针号不可混淆。细则见多 PCB 指南。
+
+## 电源、性能与资源预算
+
+影响方案的预算必须有可复核的数值、单位、工况、数据来源/假设、需求上限、余量/缺口和验证动作。缺一项外部数据时可参数化该项，不把全部预算仅写成公式。不要编造估算精度，也不固定套用统一裕量百分比。
+
+- **电源**：按轨列负载、典型/最大及启动峰值、并发场景、转换效率、稳压与保护能力；开机/待机/关机分别计算，关机漏电包括检测、上拉和调试接口等真实路径。不同电压轨先转功率，避免重复统计变换级。
+- **续航**：工作模式互斥且覆盖周期，并行活动按组合计入；平均电池侧功率 = 各模式电池侧功率×占比之和，续航约为可用电池能量/平均功率。注明温度、截止点、容量降额和损耗边界。
+- **资源/存储**：具体外设、GPIO 复用、总线地址、存储分区与记录长度、代码/RAM/缓冲区、计算和吞吐；总需求不得超过所选型号能力。估计的软件体量需通过编译/原型验证，但不能省略初步容量核算。
+- **测量/控制性能**：多级误差、分辨率、噪声、响应时间与控制时序要分配到器件/模块；器件标称性能不能替代整机指标。
+- **热/空间/互连**：器件损耗与散热路径、模块尺寸/器件高度、隔离/天线/连接器空间；多板还要检查线缆压降、回流与供电顺序。支路地线可能同时承载模块负载与信号灌电流，按实际最坏路径核算，不能只看模块供电脚电流。
+
+## 工程 BOM、成本和采购依据
+
+按板列关键物料和已知外围、封装/型号、数量、估价/报价、来源与日期、批量口径；未细化普通阻容可作为有范围的估算项，但不能宣称完整生产 BOM。汇总每块 PCB 的实例数量、线束/连接器、定制件、结构、电池、装配/测试/校准及相关费用，说明是否包含工具、税费、运费、损耗和一次性投入，避免模块与内部器件重复计价。
+
+检查“单价×数量”、范围上下限及总计；有相关条件的情景成本与独立区间求和分开解释，不能凭感觉写更低汇总。采购链接优先已核对的商品页；搜索链接仅标为“检索入口”，不是可购买、现货、报价或供应稳定的证据。若资料不可得，明确为预算分配或未核实估算。
+
+## PCB、结构和实现约束
+
+给出各板层数/板厚/尺寸的约束或推荐及依据、主要功能分区、热/噪声源分离、关键器件靠近关系、回流/地策略、保护器件位置、测试与烧录可达性。对相关接口列阻抗/长度/电流/隔离目标及待实现条件。线宽和最终叠层需结合制造参数求解，但布线人员应已知道要实现什么。
+
+手焊能力、定制 LCD/连接器配合、探头热隔离、板间线束走向等可以直接决定方案；不能以“属于装配”为由省略。精确布线、全部器件坐标、完整焊盘库、钢网/回流工艺和生产数据仍是后续工作，见 [阶段边界](stage-boundaries.md)。
+
+## 验证与原理图交接
+
+验证计划覆盖选型/原理图审查、PCB 审查、样机及适用的后续验证，关联具体需求、器件、电路或板间接口，写判据、时机和证据状态。不是要求方案期完成所有实物试验。
+
+按 [交付清单](solution-deliverable.md) 作最终检查。可以交付尚有阻塞项的草案，但必须逐板/逐模块声明可启动和受限范围；不得把“已完成宏观架构”包装成“完整硬件方案已完成”。