第 3 章 洞察：别急着相信结果，先看结果怎么来的

当系统开始稳定运行后，人最容易犯的错反而是“太快下结论”。 输出一长段看起来很专业的文字，我们就下意识点头：不错，应该对。

费曼会在这时打断你：你能不能解释“它为什么对”？如果你讲不清，那不是洞察，只是被语言说服。

在 EvoScientist 里，这个问题有很具体的解法。stream/formatter.py 的 ToolResultFormatter 不是为了美观，它是在帮你做证据分层：成功、失败、JSON、Markdown、文本会被区别对待。换句话说，系统在提醒你：不同输出，证据等级不同。结构化结果和自然语言总结，不能放在同一个篮子里。

因此你读结果时，顺序应该反过来。先看工具层有没有失败信号，再看结构化返回，再看最终总结。只看最后一句“总结得很好”是最危险的习惯，因为它会掩盖中间的错误分支。

偏差通常来自三条线，而且每条线都能在代码里找到根：配置线（模型、审批、ask-user 开关）、工具线（MCP 的连接和路由）、交互线（中途人工澄清导致路径变化）。当你知道偏差是“哪条线先动了”，你就从“猜测问题”升级为“定位问题”。

你可以把这一章的核心方法记成三个追问：这次和上次哪里不同？不同是故意的还是意外的？这个差异能不能被同事重放验证？如果三问里有一问答不上，结论就先别定稿。

真正的洞察不是一句漂亮判断，而是一条能被别人沿着同样证据重新走到终点的路径。这也是为什么我们要坚持证据先于表达：表达能打动人，证据才能说服时间。