先拆成事实与判断两层——Bobby AI 接得住哪一层

问 Bobby AI 之后仍然拿不定主意，通常不是回答太少，而是同一个问题里混了两层东西：一层是配置、日志、命令输出里能查到的客观事实，另一层是对这些事实的取舍和预测。Bobby AI 接得住哪一层，取决于你把输入拆到多干净。可行的做法是把原始问题改写成两版分别提问——只问事实的一版，只问判断的一版——再对两版回答分别做可核对性标注，缺口通常落在其中一层上，能看出来。

拆成事实版与判断版分别提问，能隔离输入变量，避免事实和取舍互相污染。事实版的目标是让回答落到配置文件、日志字段、命令输出这类能自行查证的条目上；判断版的目标是把推测标出来，而不是当成已知信息用。适用于选型、排障、方案评审。边界：拆分只隔离输入，不代表事实版一定准确；凡自查不到的条目，一律按待确认处理，不要直接写进变更单。

把一个问题写成两版：只问事实的一版、只问判断的一版

用一个真实场景演示。原始问题混着两层内容：

订单服务偶发超时，是不是该把数据库连接池调大？要不要直接上读写分离？

拆成只问事实的一版，每个问句的答案在环境里应该唯一：

在订单服务当前运行环境里：
1. 连接池上限、连接超时、连接获取失败重试次数分别由哪些配置项控制？
2. 各配置项当前取值是多少，来自本地配置文件、配置中心还是启动参数？
3. 这些配置项的读取优先级是什么？
只回答能在配置文件、配置接口或启动参数里定位到的内容，无法定位的写“无法确认”，不要给建议。

再拆成只问判断的一版，问的是取舍和预测：

在只使用上面已知信息的前提下：
1. 调大连接池上限的适用条件是什么，哪些情况下调大反而更糟？
2. 读写分离能覆盖和不能覆盖哪类问题？
3. 要判断该选哪一种，还需要补充哪些事实？
回答请分成“已知信息”和“推测”两栏，推测条目写明还缺什么证据。

拆分依据只有一条：这个问句的答案在你的环境里是不是唯一的。唯一的归事实层，需要权衡的归判断层。

原始问题里的成分	属于哪一层	拆后问法	期望回答形态	能否自行查证
连接池当前取值	事实层	由哪个配置项控制、当前值是多少	配置项名与取值	能，查配置源
超时的报错关键字与时间分布	事实层	日志里出现哪些错误关键字、出现在什么时段	关键字与时间范围	能，查日志
是否该调大连接池	判断层	适用条件与反例是什么	条件与风险清单	不能，只能当假设
是否该上读写分离	判断层	能覆盖和不能覆盖哪类问题	适用边界	不能，只能当假设

核对事实版回答里的数字、日期和口径能否自行查证

事实版回答拿到后，逐条标注三种状态：

[可核对]：能在配置、日志、命令输出或页面行为里找到确定取值或确定行为。
[口径待定]：内容查得到，但回答没说明环境、版本或时间范围，和你的环境是不是同一口径不确定。
[查不到]：按回答给的路径找不到对应内容，或者回答根本没给路径。

下面用示意表述说明标注方式，实际使用时把 Bobby AI 的原话抄进第二列，再逐条去查。

条目	回答里的表述（示意）	自查动作	查证结果
1	连接池上限由 maximumPoolSize 控制	在应用配置源里 grep 该键，或在配置接口页查看	[可核对]，键名对得上
2	当前上限是 20，连接超时 30 秒	逐环境打开配置源比对；若回答未指明环境	[口径待定]，值对不上具体环境
3	超时集中在晚高峰	用错误关键字按小时统计日志	[查不到]，未取日志前无法确认
4	该参数默认值建议设成 CPU 核数乘 2	在配置文档里找该参数的默认值说明	[口径待定]，属经验口径而非默认值
5	日志里会出现 Connection is not available	在近几天日志里 grep 该字串	搜到则 [可核对]，搜不到则 [查不到]

执行位置：配置项核对在配置中心页面或应用配置接口完成，日志统计在日志检索页面或跳板机上完成。下面只是命令骨架，路径、容器名和文件名按实际环境替换，输出本身才算核对结果，不要让 Bobby AI 代填。

# 定位配置项（按实际部署方式替换容器名与路径）
kubectl exec <pod> -- grep -R maximumPoolSize /path/to/conf

# 统计日志关键字（替换日志文件名与关键字）
grep -c 'Connection is not available' app.log

在判断版回答里标出属于推测的表述并单独列出

判断版回答的价值在于列条件和风险，但里面会混着推论。把带“通常、一般、建议、大多数”这类词、或者没有给出你环境里可查前提的句子挑出来，放到单独一张表里。

Bobby AI 表述（示意）	为什么归为推测	判断理由
调大连接池一般能缓解超时	因果链没闭合	需要先确认异常发生在连接获取等待阶段，还要看数据库侧是否已是瓶颈
读写分离可以解决写入压力	没有区分读写路径	读写分离通常是把读请求分走，对写路径的瓶颈作用有限，回答未说明前提
这个参数大多数团队都设成 50	泛化统计	缺少版本、负载模型和连接使用方式的上下文
上了读写分离就不用再管连接池	属于预测	没有给出可观察的前置条件，也无法从配置或日志里验证

标注推测不等于回答错了，只是说明这些句子不能当已知信息写进方案。判断理由的写法统一成一句：缺少哪一类可查证据。缺日志、缺配置、缺容量数据，三类分开写，后面补起来更快。

把两版回答拼回原始问题，看缺口出现在哪一层

把两版回答按原始问题的小问重新对齐，缺口位置就清楚了。

原始问题的小问	事实版覆盖情况	判断版覆盖情况	缺口位置
连接池当前取值是多少	能落到具体配置项	不回答	不在 AI，在有没有去查配置源
超时的错误关键字与分布	能落到日志关键字	不回答	在日志是否可取、是否已统计
该不该调大连接池	不涉及	给了条件和风险，但依赖上面两个事实	事实层没补齐，判断悬空
要不要上读写分离	不涉及	给了适用边界	仍缺写入量、读请求占比这类事实

拼接后的常见形态是：缺口主要落在事实层，也就是配置和日志没有取；少数落在判断层，表现为判断缺少可比的前提。一个快速定位办法是看判断版回答里的“取决于”出现了几次，每出现一次，就对应事实层的一个待补项。

定下遇到判断层回答时的复核动作

把复核做成固定步骤，触发条件和动作绑定，避免每次临时决定信不信。

动作	触发条件	具体执行	通过标准	风险边界
换来源	判断版回答只给一个方向，且没写出所依赖的前提	换一个模型或换一位同事，用同一版问题再问一次，把两次给出的条件和风险列出来做差集	两次在同一条件下的判断一致，或差异点能落到某个具体事实项上	换来源不产生新事实，只是暴露分歧
换问法	回答里出现泛化词，且落不到你的环境参数上	改成条件式提问：当某条件成立时怎样，不成立时怎样；或反问要推翻这个建议需要观察到什么现象	回答能给出可观察现象或可查参数，而不是继续给方向	会拉长回答，信息量不一定增加
直接搁置	判断涉及不可逆动作，如线上参数放大、数据迁移、访问路径切换，且回答里没有可先做的小步验证	把问题转回事实版，先补配置、日志和容量数据；在变更单上把该条状态写成待确认	事实层的待确认项被补齐或被明确排除	会拖慢决策，适合不可逆变更，不适合可回滚的小改动

三种动作可以按顺序用：先换问法逼出可观察条件，条件仍不明确就换来源看分歧，涉及不可逆动作且分歧无法通过事实项消解时直接搁置。每个动作完成后，把新得到的事实项补回事实版回答的核对表里，判断层的表相应更新。