我用 Claude Code 构建了一个根因分析工具，又写了一个验证器来抓住模型“自信地犯错”——真实数据：60% / 20%

我一直在开发 AeroTrace-RCA，一个小工具：输入一次飞行的传感器读数（CSV 格式），它会尝试解释到底出了什么问题。工作原理： - 每个传感器有 5 个检测器来标记异常 - 它会回溯到每个问题真正开始的时间点 - 一个本地模型（通过 Ollama 运行的 Qwen 2.5 14B）会给出可能的根因 - 一个独立的验证器会丢弃任何数据无法支撑的归因 验证器从不提出任何假设，它只能说“不”。 我是用 Claude Code 作为结对程序员来构建这个工具的。我真正在意的是让 AI 保持诚实：工具内部的模型提出原因，然后由一个独立的验证器加上严格的留出集评测来决定是否采信它。这跟我与 Claude Code 协作的方式是一样的：让它生成，但要有一个能说“不”的存在。 数据，直白地说： - 在我调优所用的 6 次飞行上：6/6 全中 - 在一个盲测留出集的 5 次飞行上：top-1 正确 3/5（60%） - 在严格的“全对或全错”评分下完全正确：1/5（20%） 这个差距正是重点。如果你用调优时用过的样本给 AI 打分，它看起来会完美无缺。 验证器为什么有两条规则： 被归咎的部件必须在它自己的子系统内有证据支撑。跨子系统的归因只允许一跳。任何东西在几跳之内都会和所有东西耦合在一起，如果允许链式归因，任何故事都会被批准通过。 仍然会出错的地方：耦合检查测试的是一条链接“是否可能”，而不是它“是否真的发生”。在 5 次盲测飞行中，有 2 次它把两个独立的故障合并成了一个。这是目前最大的已知弱点。 先说清楚局限：数据是合成的，只有一种机型配置，n=5，从未在真实飞行数据上运行过。与任何发射服务商无关联。共有 162 个测试，使用假的 LLM 客户端运行，因此结果是确定性的。 给所有构建 agent 的人的经验：当 AI 替你写了大量代码、当一个 LLM 就坐在你的产品内部时——一定要留出数据、严格评分，并且把那个难看的低分公布出来。 欢迎提问，仓库链接见评论区。