硬件 PRD 拆解助手

硬件 PRD 落地时卡在「谁做什么」

一份硬件 PRD 往往同时覆盖主控选型、结构堆叠、产测工装、可靠性指标和 BOM 成本，但文档很少按工程角色写成可直接派工的任务表。结果是评审会上反复对齐边界：结构是否要等 ID 定稿、防水由谁提要求谁验证、模具评估归结构还是成本。本技能把 PRD 当作研发工作流入口，只做拆解与分派，不替你做芯片或方案决策。

工作方式与产出

执行前会先让你选择完整模式或脱敏模式（后者按规则隐去型号、供应商与敏感数字，适合外部分享）。随后按固定流程：摘要 PRD、对照常见章节做完整性检查、判定 ID 定稿状态（已定稿 / 完全缺失 / 仅有形态方向），再把每一项规格映射到五个不可合并的角色：

• 硬件工程师：主控、传感器、交互器件、电源、通信、存储
• 结构工程师：堆叠、装配、公差、防水与材质要求、模具约束（不含 ID 造型与 CMF 本身）
• 工艺工程师：SMT、组装、密封、产测工装
• 品质管理工程师：可靠性、关键指标验证、IQC、合规认证
• 成本分析工程师：BOM 估算、询价清单、模具费用评估

每条任务需带优先级（遵循 PRD 的 P0/P1/P2）、PRD 依据（含原文引用）、交付物；PRD 中的「待确认 / TBD」会原样保留并汇总到全局风险表。同一次运行会生成两份文件：Markdown 供评审存档，Excel（多 Sheet、可填负责人与状态）供任务跟踪，并在文末固定给出与项目排期、BOM 整理、模具寻源等下游技能的衔接建议。

边界与注意点

• 仅适用于含硬件规格的 PRD；纯软件 / App 文档应终止并提示不适用。
• 不臆造规格、不推荐具体芯片（除非 PRD 已写明），也不做「14 天续航能否达成」类深度可行性结论，只列出需验证项。
• 敏感信息流转取决于你的部署环境（公有云 / 私有化）；完整模式会保留 PRD 原文引用，使用前请自行评估合规要求。