1. 硬件文档为什么总是写不好先弄清它到底要解决什么问题做硬件这些年我最大的感受是硬件文档不是写给归档部门看的是写给三个月后的自己、接手项目的同事、以及产线上的工程师看的。很多人写不好硬件文档不是因为不会写而是根本没想清楚这份文档到底要为谁服务、要解决什么冲突。先讲一个真实的例子。我之前做过一款带无线通信模块的采集终端硬件方案定型时电源部分选了某款国产DC-DC芯片当时选型理由很简单价格低、供货稳、手册上的效率曲线也漂亮。结果到了小批量试产产线上的工程师照着BOM物料清单贴片却发现芯片丝印和采购回来的批次对不上追问下来才知道原厂中途换了封装引脚定义旧版手册和新版手册对不上而我们的原理图库、封装库、BOM注释里全是旧信息。这个问题的根子不在生产在文档。电源选型、封装版本、引脚定义这些信息如果只存在于某一次邮件沟通里那它就是一次性的信息不是文档。硬件文档的本质是把整个生命周期里产生过的关键决策、变更、踩坑记录变成可检索、可追溯、可复用的资产。没有这套资产每一次换人、换批次、换方案都等于重新交一遍学费。那硬件文档到底应该包含什么我现在的习惯是把它拆成五个维度后面几节逐个展开需求与方案文档为什么做这个硬件、功能边界在哪里、关键指标怎么定下来的设计与实现文档原理图、PCB、结构、热设计、EMC电磁兼容设计这些具体怎么做物料与供应链文档BOM、替代料、PCN产品变更通知、停产风险测试与验证文档测了什么、怎么测的、结果如何、还有哪些已知问题调试与复盘记录实验室里踩过的坑、改过的线、飞过的线、留下过的临时方案这五块不是互相独立的它们之间是强关联的。比如你改了一版原理图那么BOM要跟着变测试用例也要跟着变调试记录里还应该注明这次改动解决了什么问题。文档之间一旦脱节硬件项目就会出现设计图上看着没问题、实际做出来全是问题的经典翻车现场。2. 需求到方案这一步文档就要开始介入而不是等画完原理图再补2.1 需求文档不是抄需求清单是把约束条件一次说清很多硬件工程师的习惯是拿到需求直接开画原理图画到一半发现某个功能做不了再回头找产品经理改需求。这种做法在快速原型阶段还行但只要有量产、有认证、有成本控制的需求就会出大问题。我现在的做法是在动手画原理图之前先写一份一页纸的硬件需求确认表里面必须包含这几项供电方式与电源预算电池供电还是适配器输入电压范围整机功耗上限工作环境约束温度范围、湿度、是否有振动、是否户外长期暴露接口与通信协议需要哪些外部接口各自的电平标准和协议版本成本与供货约束目标BOM成本、关键元器件的供货渠道、有无禁售或限购风险认证与合规要求需要过什么认证EMC、安规、无线型号核准等交付节奏原理图、PCB、样机、试产的各个时间节点这份确认表不需要写得很长但一定要和需求方逐条过一遍确认无误后签字。这一步的价值不是走过场而是把后续所有可能出现扯皮的模糊地带提前用文字固定下来。比如设备需要支持远程升级这句话如果不进一步拆解到了硬件设计阶段就会面临选择要不要预留外部Flash、MCU微控制器的Flash容量要多大、升级失败怎么回滚。这些如果不提前确认等画完PCB再改代价就完全不一样了。2.2 系统框图与接口定义是整个硬件文档体系的骨架需求确认之后紧接着要做一件事画系统框图。不要觉得这一步简单框图画清楚了后面所有文档都好写。系统框图至少要体现三层信息电源树、信号流、通信链路。电源树要标注每一路电源从哪里来、电压多少、最大电流多少、给哪些负载供电信号流要标注主控和各外设之间的通信方式I2C、SPI、UART、CAN等、速率、是否隔离通信链路要标注对外接口的物理形态和协议。这里我特别想提醒的是接口定义表。很多项目画框图画得很快接口定义表却拖到最后才补结果就是PCB Layout阶段发现两个接口的丝印位置冲突或者结构工程师拿着接口尺寸图来对的时候发现定义和外壳开孔对不上。接口定义表应该从系统框图阶段就开始维护每一版都要和结构、软件同步不要当成事后文档。接口定义表里面我最关注这几列接口名称、物理类型插座型号/引脚定义、电气规格电压/电流/信号电平、通信协议、对应软件模块、备注比如是否支持热插拔、是否有ESD防护要求。有了这张表结构设计和软件开发的同事就都有了一个统一的参照物讨论问题的时候不用再翻聊天记录。3. 原理图与PCB阶段的文档管理真正拉开工程师差距的地方3.1 原理图库和封装库的规范化比画图本身更重要原理图阶段最容易忽略的文档工作是元件库的标准维护。我见过太多项目原理图库里的元件符号画得随心所欲引脚顺序不按实际封装来标导致画原理图的时候觉得逻辑清晰到了PCB Layout时才发现引脚定义对不上只能回头改库连带改原理图。现在我的元件库维护原则是三条原理图符号的引脚编号必须和实际封装完全一致且按功能分区排列电源引脚放上面地引脚放下面信号引脚按接口顺序排列每个元件必须关联完整属性制造商、制造商型号、封装名、耐压/电流/精度等关键参数、替代料型号新元件入库必须过一道审核核对数据手册上的引脚定义和封装尺寸不能直接照搬别人的库文件这三条看起来死板但能省掉后面无数排查时间。尤其是引脚定义因为不同厂家、不同批次的同一功能芯片引脚顺序可能完全不同比如最常见的MOS管和二极管封装不同厂牌的引脚排列就各有差异不加核对直接画轻则飞线重则烧板。3.2 BOM表不是Excel堆物料是供应链风险的前置排查工具BOM表的重要性怎么强调都不过分。但在实际项目里BOM表往往是最不受重视的文档常常是画完PCB之后才匆匆整理而且只包含物料名称、型号和数量。这个信息量远远不够。一个合格的硬件BOM至少要包含这些字段字段作用说明位号原理图中的唯一标识比如R1、C3、U2物料描述完整参数比如10kΩ ±1% 0402 0.1W 厚膜电阻制造商首选厂牌比如Yageo、Murata、TI制造商型号准确到原厂完整型号不能只写通用编码封装0402/0603/SOT-23等必须和PCB封装一致关键参数精度、耐压、温度系数、ESR等效串联电阻等替代料至少1~2个可用的替代物料及匹配参数生命周期状态量产/停产/即将停产/有PCN风险备注特殊要求比如仅限A供应商需手工焊接为什么替代料这么重要因为硬件产品一旦进入量产最容易卡脖子的就是物料停产或缺货。如果在BOM阶段就提前标注替代料采购和生产部门在遇到原物料缺货时可以立刻按照替代方案走验证流程而不是临时抱佛脚再去找料、找样品、做测试。还有一个很实用的习惯每次硬件改版BOM一定要同步生成新版本并且保留旧版本存档。很多时候项目做到一半发现某个器件出了问题需要回溯上一版用的什么料、这个料是从哪个版本开始换的如果没有历史BOM存档这个排查基本无从下手。3.3 PCB设计说明文档把布局布线的思路固定下来PCB板子画完很多人就觉得文档工作结束了但其实PCB阶段恰恰是最该写文档的时候。我一般会在PCB设计完成之后花30分钟写一份PCB设计说明内容包括板卡尺寸、层数、板材、板厚、表面处理工艺关键布局思路电源模块放哪里、晶振为什么放那个位置、高速信号走线的阻抗控制要求关键的布线约束差分对、等长、回流路径、开窗散热区域生产相关标注工艺边、拼板方式、Mark点位置、特殊焊接要求这份说明最大的用处是下次改版或者做衍生型号的时候不需要重新对着板子拆一遍才能理解当初为什么这么设计。硬件设计里很多当时觉得理所当然、过后完全想不起来的决策都值得用文字记录下来。比如某个电容放在芯片引脚旁边是因为去耦效果最好某个电阻选0402而不是0603是为了省空间但牺牲了功率余量——这些决策如果不写下来下一版很可能被优化回去然后又踩一遍同样的坑。4. 测试与调试记录硬件文档里最容易被低估的两块内容4.1 测试报告要能回答测了哪些、结果如何、还有哪里没测硬件测试报告的痛点通常是两个极端要么写成流水账只记录功能正常要么写成学术论文几十页测试数据和波形图但没有人总结结论。我的建议是测试报告的核心结构固定为两部分测试结论摘要 详细测试记录。结论摘要放在最前用两三句话说明本次测试的整体结论、是否通过、有无遗留问题让产品经理和生产部门不用读全文就能拿到答案。详细测试记录放在后面包含每项测试的方法、条件、仪器、原始数据、判定标准。判定标准和实际数据一定要对应着写。比如做电源纹波测试不能只写纹波20mV要写明测试条件输入电压、负载电流、示波器带宽限制是否开启、探头是用的什么方式测量——换一个测量条件纹波数值可能天差地别不写清楚条件数据就失去了可比性。还有一点容易被忽略测试报告里要明确记录未覆盖项或已知风险项。比如测试时间有限高低温循环只做了20个周期没有做满100个或者ESD测试因为实验室设备排期没做。这一块如果不在测试报告里白纸黑字写出来后面被遗忘的风险很大等产品到了现场出现问题回查测试记录才发现当时根本没测过那才是真正的管理漏洞。4.2 调试记录是写给未来的自己看的别怕写得丑调试记录和测试报告不一样它不需要给任何人交代什么格式规范它就是写给自己的一个踩坑日志。但恰恰是这份看起来最随意的文档在关键时刻的作用最大。我在实验室里的习惯是每次调试发现问题当场写下几个要素——现象、环境、猜测原因、验证过程、结论。不用整理不用过度修饰甚至可以用接线的拍照加文字标注代替长篇描述关键是记录要及时。我见过太多人调出一个问题当时觉得这个我记住了结果过两周就忘得一干二净等到第二次遇到同样的问题又从头查一遍。举一个很典型的例子。有一款产品在低温环境下偶尔出现无法开机的问题一开始大家都怀疑是电池低温放电能力不足排查了半个月换了三款电池都没根治。后来翻旧调试记录才发现早在三个月前的一次实验室调试中就有过一次类似现象的记录当时因为温度回升后问题消失就没有深究。而这个现象背后指向的真正根因是电源管理芯片的欠压锁定阈值设置过高低温时电池内阻增大导致启动瞬间电压跌落触发了锁定。如果当初那份调试记录当时就同步给了软件团队这个半个月的排查周期完全可以压缩到两三天。所以我的建议是调试记录不用追求漂亮但要保证三件事——实时记录、带上条件、定期回看。实时记录就是问题一发生就写不要攒带上条件就是记录当时的温度、电压、固件版本、接线方式定期回看就是每次项目节点或者排查谜题时先翻一遍旧记录而不是直接从零开始查。4.3 复盘文档把偶然调通变成可复现的能力硬件调试里最怕的一种状态是这次板子莫名就好了但不知道为什么好的。这种运气如果不转化为文档就无法成为团队的能力。我自己的习惯是每个项目告一段落之后写一份简短的复盘文档聚焦两个问题这个项目里最耗时的三个问题是什么根因在哪里不用长篇大论三个问题够了。比如仿真时ESR参数填错导致电源纹波计算偏差巨大、PCB走线过长导致I2C信号完整性出问题、FLASH擦写次数耗尽了没设计磨损均衡每一个都是拿血泪换来的经验。复盘文档写成之后存放在团队共享的文档库里并且要和原理图、教训相关的文件建立关联。新同事进来的时候先看这些复盘文档而不是直接扔一份原理图让他自己琢磨。这个过程看起来慢实际上是最快的带人方式。一份好的复盘文档能把一个团队几年踩坑积累的经验压缩到几页纸里传递给后来者。5. 版本管理与变更记录硬件文档里最容易被口头沟通毁掉的一环5.1 原理图和BOM一定要做到一版本一归档硬件项目改版是常态但改版过程中的版本管理很多团队做得非常随意。最常见的乱象原理图存在不同人电脑里各有各的修改最后PCB画的是其中一个人的版本但谁也说不清和另一个人的差在哪里。我现在的要求是原理图、PCB、BOM三项必须同版本号同步更新、同步归档。比如V1.2版本就是原理图V1.2、PCB V1.2、BOM V1.2三者内容必须一致。任何一项有修改版本号都要跳不许只改其中一项。这看起来是极简单的约束但真正做到之后能避免掉几乎所有因为文档不一致导致的返工。版本变更记录表是另一个容易被忽视的文件。每次改版都要在变更记录表里写清楚这次改了什么、为什么改、涉及哪些位号、是否经过验证。变更原因尤其重要因为改版有两种一种是因为新需求加的改动一种是因为发现了缺陷修的改动这两种在后续追溯时价值完全不同。5.2 对接软件和结构工程师时文档比口头沟通更可靠硬件工程师的日常工作里和软件工程师、结构工程师的沟通非常频繁而这种跨专业沟通恰恰是所有信息失真最严重的地方。硬件工程师说这个引脚我换了定义软件工程师点头说好的记住了结果软件那边按照旧定义写驱动新板子一上电就通信失败——这种事情几乎每天都在发生。解决办法不是让大家少说话而是把信息同步的动作固定到文档里。比如引脚定义调整之后除了在原理图里改还要同步更新一份引脚定义对照表并发到团队共享文档里软件工程师开发时以此为准。这种对照表的形式很简单就三列原来的定义、现在的定义、变更时间及原因。但它的价值是让每一次变更都有据可查就算沟通时忘了说文档也会替你把信息传递到位。结构的配合也一样。板卡尺寸、接插件位置、接口高度这些信息只要发生过一次变更就应该同步更新结构对接文档并且通知结构工程师重新核对。我遇到过最痛的一次是因为一个电源插座的高度参数调整了0.5mm硬件那边以为就0.5mm无所谓结构那边不知情结果整机装配时发现外壳压住了插座装机装不进去只能重新开模。0.5mm的代价是几万块的模具费和两周的交期延误。文档里多个0.5mm报价单上就少几个零。5.3 供应商与产线的文档对接做好DFM反馈记录硬件文档除了服务研发内部还有一个重要用户供应商和产线。原理图、PCB、BOM发出去之后产线的工艺工程师会反馈一系列问题比如某个封装焊盘间距太小容易连锡、某个器件布局离板边太近影响分板、某种物料上锡不良率偏高。这些反馈如果只停留在微信群里等于没反馈。我现在每个项目都有一个专门的DFM反馈记录文档产线每提一条意见就记一条注明反馈来源、问题描述、影响范围、是否采纳、采纳后如何修改。这份文档的价值是双向的对产线来说他们会更认真提意见因为知道提了会被记录和跟踪对硬件工程师来说这是一份极其宝贵的工艺经验积累比任何教科书都贴近实际。我发现一个新同事加入团队之后最应该看的就是这份DFM反馈记录因为里面记的都是产线上真实发生过的工艺问题比如0402电阻在回流焊时容易立碑建议换成0603连接器的焊盘设计需增加散热过孔否则焊接不饱满TOP层走线离定位孔太近分板时容易伤线这些全是付费买来的经验。6. 把文档体系落到日常工具选型、模板设计和工作流整合6.1 文档存放与协作工具的选择思路工具选型这个问题很容易走两个极端要么觉得随便用个共享文件夹就行要么一上来就上一套复杂的PLM系统产品生命周期管理系统结果大家都不爱用变成摆设。我的建议是根据团队规模来定。十几人以内的小团队一个支持版本管理的云盘加一套命名规范就够用了。目录结构建议这样划分01_需求与方案 02_原理图与PCB 03_BOM与供应链 04_测试与验证 05_调试与复盘 06_产线与DFM每个目录下按项目名和版本号命名文件比如采集终端_V1.2_原理图_20240510.sch。命名规范这一条看起来微不足道但能直接决定你三个月后能不能快速找到需要的文件。我见过很多团队的共享文件夹像垃圾堆一样文件名叫最终版终极版打死不改版这种文档管理等于没有管理。团队规模大了之后再考虑引入带审批流的PLM或者硬件管理软件因为那时候需要的不只是存放和分享还有权限控制、变更审批、物料生命周期管理等系统化能力。但核心逻辑没有变先想清楚流程再上工具不要反过来让工具定义流程。6.2 文档模板怎么设计才不会被工程师抵触文档模板太繁琐工程师会抗拒填写太简单写了等于没写。我设计模板的原则很朴素一张A4纸能写完的绝对不设计成两页能勾选的绝对不让人填空。拿硬件需求确认表举例我的第一版设计是纯开放式文本框让工程师逐条描述结果大家反馈不知道写多细才算够。后来改成表格加预填选项的方式供电方式给几个常用选项勾选温度范围给一个区间填空接口类型用多选框这样填起来就快多了。还要注意一个细节模板里的空栏目要预设默认值或者示例。比如工作环境湿度这一栏我在模板里预填了5%~90%RH无凝露作为参考值工程师如果没特殊要求就直接沿用有特殊要求再改。模板的定位不是告诉别人必须怎么写而是降低写的门槛让不擅长文档的人也能写出生效的文档。6.3 文档维护习惯把写文档嵌入到项目节点里而不是事后补最后想说的是习惯问题。硬件文档最大的敌人不是规范不够而是拖延。所以我建议把文档更新动作绑定到项目节点上像打卡一样需求评审结束 - 更新需求确认表原理图定稿 - 更新原理图库、BOM初版PCB投板前 - 完成PCB设计说明样机组装完成 - 建立测试记录表每轮测试结束 - 更新测试报告和问题追踪表每次硬件改版 - 同步更新版本记录和变更记录按这个节奏来文档工作是分散到日常里的每次花个十几二十分钟负担不大。但如果攒到项目结束再补面对几百个元件的BOM和几十页的测试数据任谁都会想放弃。实际执行中还有一个技巧每一份文档最上面加一个最近更新栏记录日期和更新人。这样不仅方便追溯也在心理上给了一个暗示——这份文档是活的是需要持续维护的而不是一次写完就扔进文件夹吃灰的。等到一个项目完整走下来你再回头看那堆文档时会发现它们记录的不仅是一块板子的诞生更是整个团队经验和决策的沉淀这种积累会在下一个项目里直接变现成效率。
1. 硬件文档为什么总是写不好先弄清它到底要解决什么问题做硬件这些年我最大的感受是硬件文档不是写给归档部门看的是写给三个月后的自己、接手项目的同事、以及产线上的工程师看的。很多人写不好硬件文档不是因为不会写而是根本没想清楚这份文档到底要为谁服务、要解决什么冲突。先讲一个真实的例子。我之前做过一款带无线通信模块的采集终端硬件方案定型时电源部分选了某款国产DC-DC芯片当时选型理由很简单价格低、供货稳、手册上的效率曲线也漂亮。结果到了小批量试产产线上的工程师照着BOM物料清单贴片却发现芯片丝印和采购回来的批次对不上追问下来才知道原厂中途换了封装引脚定义旧版手册和新版手册对不上而我们的原理图库、封装库、BOM注释里全是旧信息。这个问题的根子不在生产在文档。电源选型、封装版本、引脚定义这些信息如果只存在于某一次邮件沟通里那它就是一次性的信息不是文档。硬件文档的本质是把整个生命周期里产生过的关键决策、变更、踩坑记录变成可检索、可追溯、可复用的资产。没有这套资产每一次换人、换批次、换方案都等于重新交一遍学费。那硬件文档到底应该包含什么我现在的习惯是把它拆成五个维度后面几节逐个展开需求与方案文档为什么做这个硬件、功能边界在哪里、关键指标怎么定下来的设计与实现文档原理图、PCB、结构、热设计、EMC电磁兼容设计这些具体怎么做物料与供应链文档BOM、替代料、PCN产品变更通知、停产风险测试与验证文档测了什么、怎么测的、结果如何、还有哪些已知问题调试与复盘记录实验室里踩过的坑、改过的线、飞过的线、留下过的临时方案这五块不是互相独立的它们之间是强关联的。比如你改了一版原理图那么BOM要跟着变测试用例也要跟着变调试记录里还应该注明这次改动解决了什么问题。文档之间一旦脱节硬件项目就会出现设计图上看着没问题、实际做出来全是问题的经典翻车现场。2. 需求到方案这一步文档就要开始介入而不是等画完原理图再补2.1 需求文档不是抄需求清单是把约束条件一次说清很多硬件工程师的习惯是拿到需求直接开画原理图画到一半发现某个功能做不了再回头找产品经理改需求。这种做法在快速原型阶段还行但只要有量产、有认证、有成本控制的需求就会出大问题。我现在的做法是在动手画原理图之前先写一份一页纸的硬件需求确认表里面必须包含这几项供电方式与电源预算电池供电还是适配器输入电压范围整机功耗上限工作环境约束温度范围、湿度、是否有振动、是否户外长期暴露接口与通信协议需要哪些外部接口各自的电平标准和协议版本成本与供货约束目标BOM成本、关键元器件的供货渠道、有无禁售或限购风险认证与合规要求需要过什么认证EMC、安规、无线型号核准等交付节奏原理图、PCB、样机、试产的各个时间节点这份确认表不需要写得很长但一定要和需求方逐条过一遍确认无误后签字。这一步的价值不是走过场而是把后续所有可能出现扯皮的模糊地带提前用文字固定下来。比如设备需要支持远程升级这句话如果不进一步拆解到了硬件设计阶段就会面临选择要不要预留外部Flash、MCU微控制器的Flash容量要多大、升级失败怎么回滚。这些如果不提前确认等画完PCB再改代价就完全不一样了。2.2 系统框图与接口定义是整个硬件文档体系的骨架需求确认之后紧接着要做一件事画系统框图。不要觉得这一步简单框图画清楚了后面所有文档都好写。系统框图至少要体现三层信息电源树、信号流、通信链路。电源树要标注每一路电源从哪里来、电压多少、最大电流多少、给哪些负载供电信号流要标注主控和各外设之间的通信方式I2C、SPI、UART、CAN等、速率、是否隔离通信链路要标注对外接口的物理形态和协议。这里我特别想提醒的是接口定义表。很多项目画框图画得很快接口定义表却拖到最后才补结果就是PCB Layout阶段发现两个接口的丝印位置冲突或者结构工程师拿着接口尺寸图来对的时候发现定义和外壳开孔对不上。接口定义表应该从系统框图阶段就开始维护每一版都要和结构、软件同步不要当成事后文档。接口定义表里面我最关注这几列接口名称、物理类型插座型号/引脚定义、电气规格电压/电流/信号电平、通信协议、对应软件模块、备注比如是否支持热插拔、是否有ESD防护要求。有了这张表结构设计和软件开发的同事就都有了一个统一的参照物讨论问题的时候不用再翻聊天记录。3. 原理图与PCB阶段的文档管理真正拉开工程师差距的地方3.1 原理图库和封装库的规范化比画图本身更重要原理图阶段最容易忽略的文档工作是元件库的标准维护。我见过太多项目原理图库里的元件符号画得随心所欲引脚顺序不按实际封装来标导致画原理图的时候觉得逻辑清晰到了PCB Layout时才发现引脚定义对不上只能回头改库连带改原理图。现在我的元件库维护原则是三条原理图符号的引脚编号必须和实际封装完全一致且按功能分区排列电源引脚放上面地引脚放下面信号引脚按接口顺序排列每个元件必须关联完整属性制造商、制造商型号、封装名、耐压/电流/精度等关键参数、替代料型号新元件入库必须过一道审核核对数据手册上的引脚定义和封装尺寸不能直接照搬别人的库文件这三条看起来死板但能省掉后面无数排查时间。尤其是引脚定义因为不同厂家、不同批次的同一功能芯片引脚顺序可能完全不同比如最常见的MOS管和二极管封装不同厂牌的引脚排列就各有差异不加核对直接画轻则飞线重则烧板。3.2 BOM表不是Excel堆物料是供应链风险的前置排查工具BOM表的重要性怎么强调都不过分。但在实际项目里BOM表往往是最不受重视的文档常常是画完PCB之后才匆匆整理而且只包含物料名称、型号和数量。这个信息量远远不够。一个合格的硬件BOM至少要包含这些字段字段作用说明位号原理图中的唯一标识比如R1、C3、U2物料描述完整参数比如10kΩ ±1% 0402 0.1W 厚膜电阻制造商首选厂牌比如Yageo、Murata、TI制造商型号准确到原厂完整型号不能只写通用编码封装0402/0603/SOT-23等必须和PCB封装一致关键参数精度、耐压、温度系数、ESR等效串联电阻等替代料至少1~2个可用的替代物料及匹配参数生命周期状态量产/停产/即将停产/有PCN风险备注特殊要求比如仅限A供应商需手工焊接为什么替代料这么重要因为硬件产品一旦进入量产最容易卡脖子的就是物料停产或缺货。如果在BOM阶段就提前标注替代料采购和生产部门在遇到原物料缺货时可以立刻按照替代方案走验证流程而不是临时抱佛脚再去找料、找样品、做测试。还有一个很实用的习惯每次硬件改版BOM一定要同步生成新版本并且保留旧版本存档。很多时候项目做到一半发现某个器件出了问题需要回溯上一版用的什么料、这个料是从哪个版本开始换的如果没有历史BOM存档这个排查基本无从下手。3.3 PCB设计说明文档把布局布线的思路固定下来PCB板子画完很多人就觉得文档工作结束了但其实PCB阶段恰恰是最该写文档的时候。我一般会在PCB设计完成之后花30分钟写一份PCB设计说明内容包括板卡尺寸、层数、板材、板厚、表面处理工艺关键布局思路电源模块放哪里、晶振为什么放那个位置、高速信号走线的阻抗控制要求关键的布线约束差分对、等长、回流路径、开窗散热区域生产相关标注工艺边、拼板方式、Mark点位置、特殊焊接要求这份说明最大的用处是下次改版或者做衍生型号的时候不需要重新对着板子拆一遍才能理解当初为什么这么设计。硬件设计里很多当时觉得理所当然、过后完全想不起来的决策都值得用文字记录下来。比如某个电容放在芯片引脚旁边是因为去耦效果最好某个电阻选0402而不是0603是为了省空间但牺牲了功率余量——这些决策如果不写下来下一版很可能被优化回去然后又踩一遍同样的坑。4. 测试与调试记录硬件文档里最容易被低估的两块内容4.1 测试报告要能回答测了哪些、结果如何、还有哪里没测硬件测试报告的痛点通常是两个极端要么写成流水账只记录功能正常要么写成学术论文几十页测试数据和波形图但没有人总结结论。我的建议是测试报告的核心结构固定为两部分测试结论摘要 详细测试记录。结论摘要放在最前用两三句话说明本次测试的整体结论、是否通过、有无遗留问题让产品经理和生产部门不用读全文就能拿到答案。详细测试记录放在后面包含每项测试的方法、条件、仪器、原始数据、判定标准。判定标准和实际数据一定要对应着写。比如做电源纹波测试不能只写纹波20mV要写明测试条件输入电压、负载电流、示波器带宽限制是否开启、探头是用的什么方式测量——换一个测量条件纹波数值可能天差地别不写清楚条件数据就失去了可比性。还有一点容易被忽略测试报告里要明确记录未覆盖项或已知风险项。比如测试时间有限高低温循环只做了20个周期没有做满100个或者ESD测试因为实验室设备排期没做。这一块如果不在测试报告里白纸黑字写出来后面被遗忘的风险很大等产品到了现场出现问题回查测试记录才发现当时根本没测过那才是真正的管理漏洞。4.2 调试记录是写给未来的自己看的别怕写得丑调试记录和测试报告不一样它不需要给任何人交代什么格式规范它就是写给自己的一个踩坑日志。但恰恰是这份看起来最随意的文档在关键时刻的作用最大。我在实验室里的习惯是每次调试发现问题当场写下几个要素——现象、环境、猜测原因、验证过程、结论。不用整理不用过度修饰甚至可以用接线的拍照加文字标注代替长篇描述关键是记录要及时。我见过太多人调出一个问题当时觉得这个我记住了结果过两周就忘得一干二净等到第二次遇到同样的问题又从头查一遍。举一个很典型的例子。有一款产品在低温环境下偶尔出现无法开机的问题一开始大家都怀疑是电池低温放电能力不足排查了半个月换了三款电池都没根治。后来翻旧调试记录才发现早在三个月前的一次实验室调试中就有过一次类似现象的记录当时因为温度回升后问题消失就没有深究。而这个现象背后指向的真正根因是电源管理芯片的欠压锁定阈值设置过高低温时电池内阻增大导致启动瞬间电压跌落触发了锁定。如果当初那份调试记录当时就同步给了软件团队这个半个月的排查周期完全可以压缩到两三天。所以我的建议是调试记录不用追求漂亮但要保证三件事——实时记录、带上条件、定期回看。实时记录就是问题一发生就写不要攒带上条件就是记录当时的温度、电压、固件版本、接线方式定期回看就是每次项目节点或者排查谜题时先翻一遍旧记录而不是直接从零开始查。4.3 复盘文档把偶然调通变成可复现的能力硬件调试里最怕的一种状态是这次板子莫名就好了但不知道为什么好的。这种运气如果不转化为文档就无法成为团队的能力。我自己的习惯是每个项目告一段落之后写一份简短的复盘文档聚焦两个问题这个项目里最耗时的三个问题是什么根因在哪里不用长篇大论三个问题够了。比如仿真时ESR参数填错导致电源纹波计算偏差巨大、PCB走线过长导致I2C信号完整性出问题、FLASH擦写次数耗尽了没设计磨损均衡每一个都是拿血泪换来的经验。复盘文档写成之后存放在团队共享的文档库里并且要和原理图、教训相关的文件建立关联。新同事进来的时候先看这些复盘文档而不是直接扔一份原理图让他自己琢磨。这个过程看起来慢实际上是最快的带人方式。一份好的复盘文档能把一个团队几年踩坑积累的经验压缩到几页纸里传递给后来者。5. 版本管理与变更记录硬件文档里最容易被口头沟通毁掉的一环5.1 原理图和BOM一定要做到一版本一归档硬件项目改版是常态但改版过程中的版本管理很多团队做得非常随意。最常见的乱象原理图存在不同人电脑里各有各的修改最后PCB画的是其中一个人的版本但谁也说不清和另一个人的差在哪里。我现在的要求是原理图、PCB、BOM三项必须同版本号同步更新、同步归档。比如V1.2版本就是原理图V1.2、PCB V1.2、BOM V1.2三者内容必须一致。任何一项有修改版本号都要跳不许只改其中一项。这看起来是极简单的约束但真正做到之后能避免掉几乎所有因为文档不一致导致的返工。版本变更记录表是另一个容易被忽视的文件。每次改版都要在变更记录表里写清楚这次改了什么、为什么改、涉及哪些位号、是否经过验证。变更原因尤其重要因为改版有两种一种是因为新需求加的改动一种是因为发现了缺陷修的改动这两种在后续追溯时价值完全不同。5.2 对接软件和结构工程师时文档比口头沟通更可靠硬件工程师的日常工作里和软件工程师、结构工程师的沟通非常频繁而这种跨专业沟通恰恰是所有信息失真最严重的地方。硬件工程师说这个引脚我换了定义软件工程师点头说好的记住了结果软件那边按照旧定义写驱动新板子一上电就通信失败——这种事情几乎每天都在发生。解决办法不是让大家少说话而是把信息同步的动作固定到文档里。比如引脚定义调整之后除了在原理图里改还要同步更新一份引脚定义对照表并发到团队共享文档里软件工程师开发时以此为准。这种对照表的形式很简单就三列原来的定义、现在的定义、变更时间及原因。但它的价值是让每一次变更都有据可查就算沟通时忘了说文档也会替你把信息传递到位。结构的配合也一样。板卡尺寸、接插件位置、接口高度这些信息只要发生过一次变更就应该同步更新结构对接文档并且通知结构工程师重新核对。我遇到过最痛的一次是因为一个电源插座的高度参数调整了0.5mm硬件那边以为就0.5mm无所谓结构那边不知情结果整机装配时发现外壳压住了插座装机装不进去只能重新开模。0.5mm的代价是几万块的模具费和两周的交期延误。文档里多个0.5mm报价单上就少几个零。5.3 供应商与产线的文档对接做好DFM反馈记录硬件文档除了服务研发内部还有一个重要用户供应商和产线。原理图、PCB、BOM发出去之后产线的工艺工程师会反馈一系列问题比如某个封装焊盘间距太小容易连锡、某个器件布局离板边太近影响分板、某种物料上锡不良率偏高。这些反馈如果只停留在微信群里等于没反馈。我现在每个项目都有一个专门的DFM反馈记录文档产线每提一条意见就记一条注明反馈来源、问题描述、影响范围、是否采纳、采纳后如何修改。这份文档的价值是双向的对产线来说他们会更认真提意见因为知道提了会被记录和跟踪对硬件工程师来说这是一份极其宝贵的工艺经验积累比任何教科书都贴近实际。我发现一个新同事加入团队之后最应该看的就是这份DFM反馈记录因为里面记的都是产线上真实发生过的工艺问题比如0402电阻在回流焊时容易立碑建议换成0603连接器的焊盘设计需增加散热过孔否则焊接不饱满TOP层走线离定位孔太近分板时容易伤线这些全是付费买来的经验。6. 把文档体系落到日常工具选型、模板设计和工作流整合6.1 文档存放与协作工具的选择思路工具选型这个问题很容易走两个极端要么觉得随便用个共享文件夹就行要么一上来就上一套复杂的PLM系统产品生命周期管理系统结果大家都不爱用变成摆设。我的建议是根据团队规模来定。十几人以内的小团队一个支持版本管理的云盘加一套命名规范就够用了。目录结构建议这样划分01_需求与方案 02_原理图与PCB 03_BOM与供应链 04_测试与验证 05_调试与复盘 06_产线与DFM每个目录下按项目名和版本号命名文件比如采集终端_V1.2_原理图_20240510.sch。命名规范这一条看起来微不足道但能直接决定你三个月后能不能快速找到需要的文件。我见过很多团队的共享文件夹像垃圾堆一样文件名叫最终版终极版打死不改版这种文档管理等于没有管理。团队规模大了之后再考虑引入带审批流的PLM或者硬件管理软件因为那时候需要的不只是存放和分享还有权限控制、变更审批、物料生命周期管理等系统化能力。但核心逻辑没有变先想清楚流程再上工具不要反过来让工具定义流程。6.2 文档模板怎么设计才不会被工程师抵触文档模板太繁琐工程师会抗拒填写太简单写了等于没写。我设计模板的原则很朴素一张A4纸能写完的绝对不设计成两页能勾选的绝对不让人填空。拿硬件需求确认表举例我的第一版设计是纯开放式文本框让工程师逐条描述结果大家反馈不知道写多细才算够。后来改成表格加预填选项的方式供电方式给几个常用选项勾选温度范围给一个区间填空接口类型用多选框这样填起来就快多了。还要注意一个细节模板里的空栏目要预设默认值或者示例。比如工作环境湿度这一栏我在模板里预填了5%~90%RH无凝露作为参考值工程师如果没特殊要求就直接沿用有特殊要求再改。模板的定位不是告诉别人必须怎么写而是降低写的门槛让不擅长文档的人也能写出生效的文档。6.3 文档维护习惯把写文档嵌入到项目节点里而不是事后补最后想说的是习惯问题。硬件文档最大的敌人不是规范不够而是拖延。所以我建议把文档更新动作绑定到项目节点上像打卡一样需求评审结束 - 更新需求确认表原理图定稿 - 更新原理图库、BOM初版PCB投板前 - 完成PCB设计说明样机组装完成 - 建立测试记录表每轮测试结束 - 更新测试报告和问题追踪表每次硬件改版 - 同步更新版本记录和变更记录按这个节奏来文档工作是分散到日常里的每次花个十几二十分钟负担不大。但如果攒到项目结束再补面对几百个元件的BOM和几十页的测试数据任谁都会想放弃。实际执行中还有一个技巧每一份文档最上面加一个最近更新栏记录日期和更新人。这样不仅方便追溯也在心理上给了一个暗示——这份文档是活的是需要持续维护的而不是一次写完就扔进文件夹吃灰的。等到一个项目完整走下来你再回头看那堆文档时会发现它们记录的不仅是一块板子的诞生更是整个团队经验和决策的沉淀这种积累会在下一个项目里直接变现成效率。
