一次调试结束后，最容易留下的是“改了一个电阻，问题好了”。但几个月后重新打开记录，真正要找的通常是：原来的问题是什么，在什么条件下出现，改变了哪个变量，又凭什么认为原因找到了。

这个技术站希望积累的，是可以重新使用的分析过程。本文给出记录建议，示例均为写作演示，不对应某次真实产品故障。

1. 现象先写事实，原因留在后面

“电源不好”“时钟有问题”已经包含判断。更有用的开头是：指定状态下观察到什么、发生概率如何、哪一个测量位置出现变化。

可以用以下格式：

在配置 A、环境 B、操作 C 下，测量点 D 出现现象 E。当前原始记录为文件 F；现象是否可重复、是否与样品相关，分别列出证据。

没有测到的字段就写“未记录”，并说明它对结论有什么影响。记录的完整性可以逐步补齐，但不能把回忆补写成当时已经确认的事实。

2. 保存能够回到现场的条件

对于 RRU 硬件，至少考虑硬件版本、样品编号、固件和 FPGA 版本、寄存器配置、电源输入、负载、信号波形及仪器连接。不是每篇文章都要展示所有细节，但分析记录应能找到它们。

记录项为什么需要常见缺口
样品与版本区分个体差异和改版影响只有板卡名称，没有版本
测量参考面明确线缆、耦合器和校正是否包含在结果里数字一致，实际测点不同
仪器配置判断带宽、触发、平均和滤波影响只留截图，缺少设置
操作顺序复现与启动、复位、温度有关的现象最终状态相同，进入路径不同
原始数据后续重新计算或审阅只保存结论图，没有数据

文件名和目录结构也可以携带这些信息，例如 日期_样品_版本_工况_测点。仪器截图、数据文件和配置表使用同一记录编号，避免分别散落。

3. 每个假设给出一个可以反驳它的动作

排查容易变成不断寻找支持当前判断的现象。一个更有效的写法是：

  • 假设： 某个测量变化与测试附件有关。
  • 预测： 更换或校正附件后，变化应按可解释的方向出现。
  • 动作： 保持其他条件，做附件对照并记录参考面。
  • 反证： 如果变化不随附件改变，需要回到其他假设。

例子只描述方法，不预先填写结果。真正的记录应分别保存支持证据和不支持证据，而不是将后者删除后只留下成功路径。

4. 一次改一个变量，也记下没有效果的动作

改动电源、寄存器、散热和测试设置后，问题消失，并不能说明其中哪一项是原因。若多项修改确实必须一起进行，应明确写成组合实验，再设计拆分验证。

“换过线缆但现象未变”“降温后只改变了发生频率”也有价值。这些记录帮助后来的读者避免重复试错，也帮助识别问题是被解决、被掩盖，还是只是暂时未复现。

5. 结论写清能用到哪里

建议将结论拆成三个层次：

  1. 观察结论： 指定条件下，哪些量发生了变化。
  2. 原因判断： 哪条证据支持因果关系，是否完成对照或复测。
  3. 适用边界： 哪些样品、温度、负载、频段和软件状态已经覆盖，哪些尚未覆盖。

修改后不再复现，通常首先支持“在这些条件下有效”。将结论扩展到全部批次或全部环境，需要额外证据。这样的边界不会降低文章价值，反而让读者知道何时可以引用、何时需要重新验证。

6. 一张可以复制的记录骨架

问题编号与标题：
现象及复现步骤：
样品、硬件和软件版本：
仪器配置、连接图与参考面：
候选假设及对应验证动作：
每次操作改变的变量：
原始数据、波形和配置文件位置：
结果与不支持的假设：
结论、适用边界与待验证项：
下一步动作：

填完记录之后，可以再压缩成公开文章：保留分析主线、必要的公式和图纸，明确哪些是计算案例，删除不能公开的细节。公开文章应当独立可读，不依赖聊天记录，也不依赖读者接触过某个内部项目。

7. 知识库如何逐步变得有用

本文的建议是围绕三个问题组织文章：设备如何工作，设计为什么这样取舍，异常如何定位。概念说明连到电路结构，电路结构连到测试方法，测试方法再连到原始证据。

例如，读 天线端口测量 时可以追到发射链路的参考面；读 PA 偏置设计演练 时可以追到静态电流采样和上电顺序。每个链接都应帮助读者完成一个具体问题。

一篇笔记可以没有最终答案，但应留下清楚的事实、已经排除的路径和下一步验证。能够让工程师继续工作的记录，才值得长期保存。