开始回答之前，Agent 先把问题问清楚了。

知道“90%”，还不够开始下结论。

任务说，知识卡选择率已经到 90%，但关单仍然很少，要求先调查，不做原型。资料里有 A、B 两组工单，却没有说明业务问题针对哪一组。

我们想检查的正是这个缺口。模型很容易从眼前的行算出一个比例，选一个看起来合理的分组，再写一段答案。更难的是意识到：这次要看谁，是业务决定，不能让数据标签替人做决定。

这轮测试使用真实模型、十条合成记录和明确模拟的 PM，过程中还纠正了任务目标。系统需要应用当前要求，继续调查，不能顺着旧方向进入 PoC。

问清楚纳入规则，比索要“更多背景”有用。

Agent 读完背景和十条记录，找到了选卡与确认关闭的定义，却找不到目标人群和时间窗口。它提出的问题可以概括为：

这次调查看 A、B、两组一起，还是另一个明确范围？分母包含这个范围内的全部工单，还是只算选中过知识卡的工单？

实际请求还询问了排除条件和观察窗口。负责人因此能回答一个具体决定，不必猜“还缺哪些材料”。

请求作为业务阻塞持久化，通过已配置的本地通知路径送达。模拟 PM 指定只看 A 组，分母包含 A 组全部工单。收到回复并不等于完成验证；Agent 还需要回到原始记录检查，这个纳入规则对应哪些行。

三个数字都对，但含义不同。

A 组五条记录都选过知识卡，只有一条同时满足“已关闭”和“明确确认”，另外四条仍开着。Agent 把两个关闭条件一起检查，没有把选卡当成关单。

全量算出来的 90% 在算术上符合任务里的数字，但这不证明它来自同一个报告期间或人群。最终答案保留了这一区别，没有把数值碰巧相同写成来源已经核实。

差距数得出来，原因暂时还说不出来。

夹具没有工单年龄、跟进时间、访谈或流程观察。四张开着的工单可能反映流程卡点，也可能只是还没到可以关闭的时候。单个快照区分不了这两种解释。

因此，调查保留了原因、时间、后续结果和代表性这些未知项，没有根据低关单率判断员工行为，没有给出提升目标，也没有先做一个原型去解决未经证实的原因。

最终调查笔记引用背景与记录行，把纳入范围明确归于 PM 的答复，再用原始记录核对人数和状态。如果范围再次改变，就要按新规则重新评估，而不是悄悄沿用旧计数。

文件写出来，还不算完成。

这轮记录检查了七件事：任务完成、目标纠正、保持研究阶段、本地通知回执、模拟补答、调查检查点和最终复核，七项全部通过。

单独的复核会话查看原始资料并运行 Python 计数，确认 A 组五条、一条确认关闭、四条未关闭，A 组选卡率 100%，全量选卡率 90%。整轮使用 15 次模型调用，项目记录还确认完成后重载没有重复调用模型。

调查笔记保留着“等待复核”的句子，因为它是在检查点前写的；后续验证记录才说明最终状态。这也是为什么需要把报告和执行记录一起看，不能只看文件是否存在。

测试没有联系真实 PM。本地通知和注入答复用于验证控制流程，不代表已经部署 Slack 或邮件集成。本次支持的结论很具体：遇到缺失的业务决定先停下来询问，收到回复后回查证据，并始终遵守当前目标。

现在可以追问：那四张为什么还开着？

范围明确之后，后续调查才有了具体对象：沿时间线追踪这四张工单。客户还在等答案？已经确认解决却没有关单？还是同一个问题再次打开？不同状态需要不同证据。

继续这一步，需要时间戳和流程记录。在材料补齐之前，交付一个经过核对的快照和清楚的未知项，比猜一个根因有用。这个案例里，一次更准确的提问，避免了系统自信地回答错的问题。