明确禁止事项与替代做法

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

你要根据配置材料写一条事故排查建议。已有 config/service.yml 第 4 行 timeout_ms: 500，事故记录只说调用超时，没有延迟分布或实际加载配置的记录。你希望避免泛泛的“检查配置”，也避免 Agent 无依据地把超时调大。

具体做法

先指出已观察到的失败写法，再写清替代动作。这里禁止没有参数和证据的配置建议；替代动作是引用已有值、说明尚缺的证据，并指定下一次读取。未知值保持未知，不用猜测填满建议。

检查禁止项是否服务于当前任务：每项都应能对应一个具体失败，且给出允许的处理方式。

反例

根据上述 config/service.yml 与事故记录写排查建议。建议要有用、谨慎，不要犯错。

改进写法

根据上述 config/service.yml 与事故记录写排查建议。不能只写“检查配置”，也不能在没有依据时建议调大超时。引用参数、观察值和材料位置。缺少延迟或实际加载记录时，明确列出缺口，并说明下一步读取哪个记录、要核对什么；不要编造修复值。

为什么这样改

“有用”和“小心”没有说明怎样辨认合格建议。改进写法把禁止事项落实为可检查的输出条件，并给资料不足的情况提供替代动作，Agent 不必在泛泛建议和无依据修复之间猜选。

如何验证

示意建议：config/service.yml:4 的 timeout_ms 为 500；当前未知该值是否被进程加载，也未知请求延迟分布。下一步读取启动配置记录核对参数，再查看同一时间窗的调用延迟。

检查输出是否有真实材料位置、是否保留这两项未知、是否没有擅自写出新的超时值。仅列出禁止词而没有下一检查步骤，仍不算完成。

适用边界

禁令适合处理明确的失败模式，不宜堆成覆盖所有情况的长清单。来源的例子说明禁止项应配替代回应；本篇事故配置和检查顺序是独立教学构造。它不证明调整超时能解决事故。