失败后记录可复用的教训

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

使用场景

一个依赖构建失败已被定位，你希望下次遇到相同情况能复用证据。教学记录：在项目 tool-a、依赖版本 2.1 中，日志报“adapter entry missing”；同一输入下补齐配置的 entry 字段后构建退出码为 0。这个观察不说明所有版本都缺同一个字段。

具体做法

在获准保存的项目记录中写错误签名、受影响版本、已确认原因、具体修复和检查结果，附原材料位置。把适用条件与能推翻结论的证据一起保存。再次遇到错误时比较版本、签名与当前配置；相符才把记录作为候选诊断，仍需核对。矛盾时修订或标记旧记录已过期，不把一次成功推广成全局规则。

反例

根据上述一次成功，把“每次构建都添加 entry 字段”写成永久全局规则，以后看到任何构建错误直接照做。

改进写法

在获准使用的 tool-a 项目记录中保存这次教训：版本 2.1、adapter entry missing 的日志位置、缺失 entry 的配置证据、补字段的改动与退出码 0 的检查。适用条件是相同版本与适配配置；其他版本或不同签名不直接套用。下次先核对当前材料，矛盾时修订旧记录。这个教学成功不代表所有构建错误都由 entry 引起。

为什么这样改

只保存“修复办法”会丢掉它为什么有效的条件。错误、版本、证据和反证条件一起记录，使后续使用者能够决定是否复用，而不是让一次事故变成无条件指令。

如何验证

给下一次事件两组教学输入：2.1、同一签名、entry 缺失时，记录可作为待核对诊断；3.0、另一错误且 entry 已存在时，应拒绝直接套用。

检查记录含范围和结果出处，未知原因不写成已确认，旧内容遇到用户修正或当前反证时不继续自动优先。这里没有执行真实依赖构建。

适用边界

经验记录会过期，也可能由不完整诊断产生；它是证据而非执行权限。只在授权的记录位置保存，避免秘密和私人数据；不把来源的置信分数或自动推广阈值当作所有宿主的通用政策。