调查结论需要转化为具体的设计或规程变更
别名: 可执行整改建议 · 设计整改 · safety recommendation
概念解释
可执行调查建议（actionable investigation recommendation）把已识别的失效机制映射到明确的界面、设备、程序、资源或治理改变，并附带验证标准。判定一条建议是否可执行的标准很具体：它是否指向一个具体的、事后能够核实是否完成的动作——改一处界面、加一处联锁、改一条规程条款——而不是"加强培训""提高警惕""增强责任心"这类不改变任何系统条件、事后也无法验证是否真正落实的空泛措辞。
机制
抽象结论容易被所有部门同意，却无法分配设计责任，也没法测试有没有做到——"加强意识"没有说明谁在什么时候用什么方式改变了什么，自然也没有一个可以核实的完成标志。具体改变则不同：它通过移除诱因、增加可探测性或恢复一道屏障，切实改变了下一次相同情境下人能看到什么、能选什么。如果建议与原因之间没有因果对应，培训往往被拿来补偿本该改进却没有改进的界面，新增的警告又会制造新的报警负荷，问题没有解决，只是换了一种方式存在。
这类空泛建议之所以反复出现，还有一层组织层面的原因：它们写起来容易，也容易在报告审核里被认定为"已经回应"，不需要投入工程资源就能让报告结案；而具体的设计或规程变更往往需要跨部门协调、需要预算、需要走变更管理流程，阻力大得多。两种建议在报告里看起来同样"完成"，实际付出的组织成本完全不对等，这个不对等本身就是空泛建议长期存在的驱动力。
怎么研究
对建议做机制—措施—指标的映射，评估可执行性、干预所处的控制层级和实施后的实际效果；把候选措施放到贴近真实压力的场景里比较，看错误路径和副作用是否真的改变了。一个具体的分类办法：把过去一段时间内的建议清单按"能否找到对应的验收记录或变更工单"分成具体与空泛两类，统计比例。不能只按结案率或按期关闭率评价建议质量——按期关闭率高，衡量的只是行政流程走得快，不是系统条件真的变了。
边界
调查组未必有权限指定唯一的技术方案，更现实的做法是定义应当达到的安全功能和用来验证是否达到的证据，把具体工程实现留给有资质的部门。紧急情况下的临时措施可以先降低风险，但需要设定到期时间并转入长期的设计方案，不能让"临时"变成永久的默认状态。规程变更也不是所有问题的默认答案：如果失效机制的根源在于设备本身不可靠或界面本身不可用，仅仅要求操作者更严格地遵守规程，只是把系统层面的缺陷转移给了执行层面，下一次同样会失效。判断一条看似"软性"的建议是否空泛，标准不是它听起来严格不严格，而是它能否被核实——例如"向同型号设备的使用单位通报此问题"如果指定了通报对象和时限，就是具体的，不因为它不涉及硬件改动就被归为空泛。
怎么落地
- 每条建议后面附一个"完成判据"字段，判据必须是结案时能用工单号、验收记录或测试结果核实的东西，不能是一句总结性的措辞。
- 优先考虑消除危险源或采用工程控制，其次才是提示、程序和培训；如果最终确实只能依赖培训，要求补充可核实的行为指标（例如现场抽查的操作合规率），而不是只统计签到率。
- 在正常、异常和有时间压力的场景中分别测试提出的措施，检查它是否把负担转移给了其他角色或其他环节。
- 结案审核环节对空泛建议一律打回，要求提出具体化版本，或者如果确实受限于资源、技术条件而无法具体化，把这个限制本身写清楚记录下来，而不是用模糊措辞掩盖做不到的事实。