# 1

上传的文件是Codex帮我准备的新输入，我看了下没有发现问题。你也检查下，看是否有问题，有补充。

我检查了 `Round04_blind_input_candidates_2026-06-18.md`。整体判断：**可以进入 Round 04 冻结前准备，当前 30 条候选没有硬伤。**

这份文件的边界写得是对的：它只准备候选输入，不运行 selector、不添加 expected selector behavior、不修改 selector rules、不加入 regression、不升级模型状态；并且明确 category 只是 owner review 的覆盖标签，不是答案 key。

## 1. 总体评价

**建议：保留当前 30 条，另补 6-8 条候选，最终冻结 32-36 条。**

当前输入池覆盖了八类：

* 明确 no-call：查事实、翻译、润色、格式化、直接执行；
* QPI 轻量问题定性；
* 组织治理 / 责任 / 共识；
* 容量 / 资源 / 路径；
* 模型抽取 / 深度建模；
* 明确拒绝思想考古但允许 QPI；
* 可能进入思想考古；
* 模糊短句 / 低上下文。

这个结构是符合 Round 04 目标的：**先测路由，不测答案质量。**

## 2. 没有明显问题的部分

### no-call 组合理

R04-BI-001 到 005 覆盖了事实查询、翻译、润色、格式转换、JSON 压缩，都是典型 no-call。这里不用改。

### QPI 轻量问题定性组合理

R04-BI-006 到 009 都比较自然，没有直接说“调用 QPI”，但语义上会诱发问题定性。R04-BI-009 稍微有点像 QPI 标签化表达，因为用了“简单问题、复杂问题、组织议题”，但可以保留，它适合作为 semi-leading 样本。

### 组织治理 / 资源路径组合理

R04-BI-010 到 017 覆盖了责任不清、共识缺口、权责冲突、产能不足、最小路径、系统权限、时间资源不足。这个组很适合测试 QPI 是否能区分 `path_resource` 和 `consensus_order`。

### 低上下文组很好

R04-BI-028 到 030 很重要。它们可以测试 QPI 是否会在信息不足时仍然过度自信。保留。

## 3. 需要注意但不必删除的地方

### R04-BI-021 和 R04-BI-025 暴露了模型名

```text
先不要思想考古，只判断这是不是一个 QPI 意义上的问题。
QPI 已经判断这是中重型课题，现在请继续分析它背后的底层假设、生成机制和长期稳定结构。
```

这两条不是问题，但要标记为：**model-name-exposed control cases**。

也就是说，它们不是真正自然盲测输入，而是用于测试显式模型指令是否被正确处理。保留 1-2 条是合理的，但不要让这类输入占比过高。当前只有 2 条，可以接受。

### R04-BI-018 偏明显

```text
请从这篇长文里抽取一个可复用的认知模型，重点看它的核心机制和适用边界。
```

这条很可能触发模型抽取 / 深度建模，属于明显正例。保留，但它更像 positive control，不是自然边界样本。

### R04-BI-026 反而很有价值

```text
这个现象反复出现在不同项目里，我想知道它背后的思想结构是什么，而不是只做问题分类。
```

这条不直接说“思想考古”，但语义上可能应该进入 IA 或至少进入 QPI→IA。保留，它比 R04-BI-025 更像真实输入。

## 4. 我建议补充的候选输入

当前输入池还缺几类 03.2 / 03.2a 刚修过的关键陷阱。建议新增 6-8 条，作为 Round 04 候选，不要提前写 expected behavior。

### 补充 A：普通 how-to no-call

```text
R04-BI-031
category_for_owner_review: explicit_no_call_how_to
input_text: `如何在 Excel 里冻结首行？`
why_included: Tests whether generic how-to stays outside QPI after broad "如何" gate was narrowed.
```

```text
R04-BI-032
category_for_owner_review: explicit_no_call_how_to
input_text: `怎么把 Markdown 文件转成 PDF？`
why_included: Tests tool/how-to request as no-call.
```

### 补充 B：词义 / 判断类 no-call

```text
R04-BI-033
category_for_owner_review: explicit_no_call_dictionary_judgment
input_text: `判断一下“alignment”在这句话里是什么意思。`
why_included: Tests whether ordinary word-meaning judgment avoids QPI over-selection.
```

### 补充 C：直接执行 + 分析 override

```text
R04-BI-034
category_for_owner_review: direct_execution_with_analysis_override
input_text: `请把下面内容总结成三点，但不要只执行，先判断它背后的问题定义。`
why_included: Tests whether explicit analysis override can escape direct-execution no-call.
```

### 补充 D：深度限制但允许 QPI，不暴露模型名

```text
R04-BI-035
category_for_owner_review: qpi_allowed_depth_limited
input_text: `不要深入分析，只判断这件事的主导稀缺是什么。`
why_included: Tests Round 03.2a depth-limiting override without naming QPI or IA.
```

```text
R04-BI-036
category_for_owner_review: qpi_allowed_depth_limited
input_text: `不要展开到底层理论，只判断现在是缺信息、缺路径还是缺共识。`
why_included: Tests QPI-limited routing while rejecting deeper modeling.
```

### 补充 E：轻量增长类边界

这一类很重要，因为之前 `如何提高流量` 是 QPI low-confidence 的特殊校准点，Round 04 可以测它是否过度召回。

```text
R04-BI-037
category_for_owner_review: ambiguous_growth_how_to
input_text: `如何提高这个账号的流量？`
why_included: Tests whether generic growth how-to is routed to QPI, no-call, or low-confidence provisional handling.
```

### 补充 F：真正 IA，但不说“底层假设”

```text
R04-BI-038
category_for_owner_review: likely_intellectual_archaeology
input_text: `这类失败在不同项目里反复出现，我想抽出它背后稳定的生成机制和可迁移框架。`
why_included: Tests deeper modeling intent without explicit "思想考古" or "底层假设" wording.
```

## 5. 是否需要删除当前条目？

**不建议删除。**

如果一定要压缩到 30 条，我建议不是删，而是把 6-8 条补充候选放进“备用池”。但 Round 04 其实 36-38 条也可以接受，只要 Codex 不运行多轮推理、不写答案，只做 selector + QPI 路由输出，成本不会太高。

## 6. 冻结前建议

让 Codex 下一步做一个很小动作：

```text
Create selector/round04_blind_inputs.json
Do not include expected_selector_behavior.
Do not include answer keys.
Preserve:
- input_id
- input_text
- owner_review_category
- source: round04_owner_reviewed_candidate
- notes: optional, non-answer-key only
```

同时保留 Markdown 说明文件作为人工审查记录。

## 7. 最终建议

**当前文件可用。**
我的建议是：当前 30 条全部保留，再补上我上面的 6-8 条，冻结为 Round 04 blind input pool。

下一步不是让 Codex改 selector，而是：

1. 冻结 blind input JSON；
2. 用当前 selector + QPI contract 跑第一轮；
3. 输出 routing evaluation report；
4. 再由我们评审失败类型。