工程结论的边界：怎样写清证据支持到哪里

技术记录里最容易被后续误用的，是一句没有条件的“问题解决了”。读者可能将它用于另一个温度、功率、版本或测点，而原记录并未覆盖这些状态。结论应该包含证据范围，让复用者知道哪些条件相同、哪些需要重新验证。

1. 结论需要完成什么

一条结论至少回答：观察到了什么，什么证据支持解释，结论适用于哪些对象，还有哪些未覆盖条件。它不需要比证据更强，也不需要为显得完整而补写未做过的实验。

2. 在 RRU 工程记录中的位置

RF、偏置和热状态相互关联。工作频率相同而波形、TDD窗口、温度历史或 DPD状态不同，结论可能无法直接迁移。报告末尾应连回输入配置与原始数据，而不只重复“满足要求”。

本文只讨论记录方法，下面所有场景均为假设写作练习，不对应作者经历或真实台架结果。

3. 一条结论的结构

对象与版本 + 规定条件 + 观测与不确定度 + 判断依据 + 适用边界 + 未覆盖项

可以分成两段：先写结果和证据，再写边界。若根因尚未确认，把已观察事实与候选解释分别写出。

4. 从观察到推广的三个层次

“未再次出现”首先是观察。样品少、运行短或触发条件变化时，不能直接写成“全部批次永久解决”。多项同时改变之后恢复，需要进一步拆分验证才能解释单项因果。

把“测量值小于阈值”写成合格之前，还要说明测量方法、修正、不确定度与采用的判定规则。NIST 的结果报告指导要求说明不确定度及其评估方式，使用扩展不确定度时要说明覆盖因子；不能给一个带 ± 的数字却省略其意义。NIST：Reporting Uncertainty

写作假设： 若表中某项写“43.0 dBm ±0.5 dB”，需要解释 ±0.5 是容差上限、标准不确定度还是扩展不确定度，是否包含线缆损耗修正。本文没有实际测量，也不利用这组数字判断任何产品通过。

5. 最低信息清单

对于资料分析，改成列明型号、资料版本、厂家保证条件与设计假设；对于计算示例，列明输入、模型、单位与忽略项。资料、计算和实测之间的证据性质不能靠标题模糊过去。

6. 公开文章怎样保留价值

不能公开的项目细节可以删去，但要保留能够支撑方法的边界。若删去的信息会改变结论，应把内容降为一般分析或明确标为设计演练，不把脱敏后的假设数字称为实测。

同时保留失败路径与未确认项。例如“排除了连接附件，尚未验证温度历史”比单写“疑似热问题”更方便下一位工程师继续工作。更新结论时保留原判断的依据与变更原因，让读者理解新证据如何改变解释。

7. 发布前的复读方法

1. 把结论单独复制出来，检查缺少正文时是否仍能识别对象和适用条件。
2. 找每一个“因此”“证明”“已解决”，核对它前面的证据是否支持该强度。
3. 检查有无将典型参数、假设计算或短时观察写成厂家保证或长期可靠性。
4. 为未覆盖温度、波形、样品及失效状态留出明确说明，必要时安排下一步验证。
5. 让未参与分析的人按结论找到原始证据；找不到就补引用或降低判断强度。

完整的结论可以保留未解决项。准确表达证据支持到哪里，才能让知识库长期可用。