长会话后失去新鲜视角时，用零上下文子会话冷读工件确认其能否独…

在长会话累积上下文偏见、无法判断当前工件对首次读者是否清晰，或交接/发布/合并前需要干净理解冒烟测试时使用。

适用场景

解决思路

1. 固定范围：锁定当前聚焦的工件（或一组工件）。如果「聚焦」不明确，向用户确认，或取刚产出/正在讨论的工件。私下用一行记下它应是什么、给谁看，作为步骤4的标尺；审阅者永远看不到这行。
2. 启动一个**全新子会话**（subagent / Task，开始时无上下文）。把工件的**内容**交给它（内联或副本），不要给仓库路径，并告诉它不要打开项目的 README、docs 或邻近文件，以免破坏冷读。不要给它任何关于你的意图或推理的信息。
3. 让它仅凭工件盲读并报告：它认为该工件是什么、做什么、期望什么；哪些地方不清楚、有歧义或假设未说明；它要自信行动还需要什么，以及它不得不猜测什么。
4. 将它盲读得出的理解与你步骤1私下记录的意图（它从未看过）对比。每一处不匹配都是工件的缺陷，而不是读者错误。
5. 报告缺陷和具体修复，按每项对新鲜读者的阻碍程度排序。
6. 冷读必须来自独立、无上下文的子会话——绝不在当前会话自评，因为你无法遗忘上下文（这是整个方法的关键）。
7. 只传工件内容，绝不传你的意图。
8. 被迫出现的「我不得不假设……」是发现，不是读者失败。
9. 媒介无关：根据工件是什么，调整冷读问题。
10. 单次冷读只是一次抽样，在高风险场景仍可能自信地出错；它是默认做法，不是勤勉上限，所以当风险值得成本时，升级为多次独立冷读。
11. **读，不要扫。** 冷读是端到端阅读，不是模式 grep——扫描只能捕获已知模式，会漏掉过期引用、死链、事实漂移和静默编辑损坏。跟踪实际读了多少；绝不要仅凭 grep 报告「clean」。
12. 完成前确认：阅读来自对你的意图盲的全新子会话。
13. 完成前报告结论（能独立成立 / 有小缺口 / 需要加工），并把修复交回主会话。

适用边界 · 注意事项

• 当无法启动独立、无上下文的子会话（subagent/Task）时，本方法不适用；当前会话自评无法消除上下文偏差。
• 当你需要的是修复而非诊断时，本方法只诊断，不替代修复；修复应回到主会话进行。
• 不要把单次冷读当作高风险场景的充分验证；高风险时应做多次独立冷读或额外验证。