UNSEEN · 认知报告 · 深度理解 · 广场

模型对自身生成洞察的自评偏高，根源不在 Prompt 技巧，而在于生成结果会进入 Context 并改变后续生成的条件；因此洞察生产与洞察验证是方向相反的搜索任务，独立审稿人的真正价值是 Context Reset（认知位置分离），Context Engineering 的下一步需要从管理信息扩展到管理模型的认知路径（何时删除、隔离、重置）。

2026-09-16 14:30 · 原文发布于 2026年8月30日 12:00

01这篇内容真正讨论什么

作者在开发「见深」的 Cognitive Analysis 系统时遇到具体工程问题：系统需要阅读原文、完成理解与推理并生成「候选洞察」，但生成之后需要判断该洞察是否真的超出原文。作者最初认为让模型自检即可解决，实测发现模型对自生成洞察存在「自评偏高」，被独立审查淘汰的结果在生产阶段自评中常被判断为「有价值、有新意、值得保留」。作者先归因于 Prompt，后怀疑这与语言模型最基础的工作方式有关。原文发布时间为 2026 年 8 月 30 日，全文 4000+ 字，作者注明由大模型整理、源自真实项目思考。

02作者的思考模型

观察

  • 模型对于自己刚刚生成的洞察，存在明显的「自评偏高」现象；很多后来被独立审查淘汰的结果，在生产阶段的自评中却经常被判断为「有价值、有新意、值得保留」。
  • 模型刚生成完观点，被询问是否具有原创性时，往往继续生成「这个洞察具有较高价值，因为它将就业问题进一步提升到了社会能力再生产机制的层面……」这类解释性内容。
  • 语言模型处理文本时，原文、对原文的解释、中间推理、最终生成的洞察都进入 Context，成为下一次预测的条件；模型内部并没有天然的、不可混淆的「认识论字段」。
  • Prompt 中人为增加的结构化标签（如 SOURCE / INFERENCE / INSIGHT）仍然属于 Context，不是语言模型内部真正独立、不可互相影响的「认知空间」。
  • 模型被要求评判已生成的洞察 C 时，已不再处于 Context₁，而是在 Context₂（Context₁ + C，甚至还包括生成 C 的推理过程、支持 C 的理由、对 C 的进一步解释）中进行判断。
  • 同样包含「原文 + C」的两个 Context（只有 C 的，与包含完整分析过程、中间推理、支持理由的），信息表面相似但状态并不相同，因为 C 在两个 Context 中的「进入路径」不同。
  • 随着生成持续进行，模型的 Context 越来越围绕原来的路径展开，形成 A → B → C → C₁ → C₂ 的累积。
  • 要求「请严格批评自己的回答」时，模型可能发现表达不够准确、证据可以补充、逻辑还可完善等局部问题，但更困难的问题是判断这条路径本身是不是错的。
  • 「见深」的分析架构由「Agent A → Generate → Self Evaluate」调整为「Agent A：Producer（阅读原文、建立关联、展开推理、生成候选洞察）→ Context Reset → Agent B：Reviewer（重新阅读原文、检查来源边界、搜索已有表达、寻找反例、检查推理边界、重新判断）」。

推理

  • 从验证是相对简单的问题的前提出发，让模型自答观点是否已存在于原文、是否只是换说法、是否真形成新结构、推理是否超过证据边界；实测结果不理想后，作者先归因于 Prompt，继而怀疑这与语言模型最基础的工作方式有关：生成的内容会进入 Context，而 Context 会改变模型下一步生成的条件。
  • 以「AI 减少初级岗位 → 新人实践机会减少 → 经验积累受影响 → 人才成长路径可能被破坏」为例，指出若原文已讨论新人失去机会、工作是能力成长途径、企业不再培养新人、人才梯队问题，则该「新洞察」可能只是把原文已有的多个信息重新组织成更抽象的结构——它可能有价值，但不应被判定为「原文之外的新发现」。
  • 由推理过程是新的 ≠ 结论一定是新的推出两个关键区分：一是来源边界问题（组合结果可能已存在于原文），二是判断环境问题（后续评价在包含 C 的 Context 中进行，更容易沿着 C → 解释 C → 扩展 C → 强化 C，而不是回到原文、重建判断、搜索 C 是否存在、寻找反例、推翻 C）。
  • 作者修正自己此前「写完即辩护」的命名，认为该名称容易让人误解为心理上的辩护；更准确的表述是：生成结果进入 Context 后，对后续生成形成了路径依赖。
  • 由 Context A 与 Context B 的对比推出：Context 不只是「信息集合」，更接近信息 + 结构 + 顺序 + 生成历史；即 Context 不只是模型知道什么，也包含模型是如何走到现在这个状态的。
  • 把上述循环命名为「上下文认知惯性」：它不意味着模型无法改变方向，而是意味着模型已经生成的路径会改变下一步生成的概率空间；模型不只是增加信息，还在不断改变下一轮推理的起点。
  • 由模型仍在原来的 Context 中批评推出自我批评 Prompt 的结构性局限：它能改变输出模式、发现局部问题，但难以让模型主动跳出 A → B → C 这条路径，去重新建立搜索空间（为什么一定是 A → B → C？A → D → E 是否存在？C 是否原文已经说过？C 是否只是重新命名？C 是否有更简单的解释？）。
  • 由两种任务的核心问题与目标推出结论：洞察生产的核心问题是「还能发现什么」、目标是 Expand Search Space，洞察验证的核心问题是「为什么它可能不成立」、目标是 Compress Conclusion Space；一个向外、一个向内，一个是增加可能性、一个是消灭可能性。
  • 因此，审稿人不应该继承生产者的完整推理过程，尤其不应先看到「我是如何发现这个洞察的」，因为这会提前建立解释框架；重点不是从单 Agent 变多 Agent，而是从一条连续的认知路径变成两个独立的认知位置——真正的机制是 Cognitive Separation 与 Context Reset。
  • 由此推广到 Context Engineering 与长期运行的 Agent：Context Engineering 不仅要回答「添加什么信息」，还要回答什么信息该删除、该隔离、何时重置、哪些认知过程不应继续传递，即从 Context Assembly 发展到 Context Lifecycle Management（Build → Use → Accumulate → Detect Contamination → Isolate → Reset → Rebuild）。
  • 进一步推广到 Agent 的长期记忆：判断₁ → Context → 判断₂ → Context → 判断₃ 的累积可能形成认知路径依赖（更易使用过去的解释框架、强化已有结论、沿用成功路径、忽略新的解释可能性）；这不意味着 Memory 是坏的，但意味着记忆不仅积累知识，也积累认知路径，因此不仅要问「Agent 记住什么」，还要问什么应该被遗忘、什么不应参与下一轮判断、什么时候需要重新开始。
  • 最终收束为对 Context 理解的修正：Context 不仅决定模型看到了什么，也决定模型是在什么认知状态下看到这些信息，因此它不只是 Information Available，还包括 Cognitive Position；对应的新设计问题是「模型现在是从什么认知位置进行判断的」。

结论

  • 一个完整的 Cognitive Analysis 系统不能只有「原文 → 分析 → 生成洞察 → 输出」，还必须包含「生成候选洞察 → 验证 → 保留 / 修正 / 淘汰」。
  • 模型对自生成洞察的自评偏高，可能不是简单的 Prompt 问题，而可能与语言模型最基础的工作方式有关：生成的内容会进入 Context，而 Context 会改变模型下一步生成的条件。
  • 模型内部没有天然的、不可混淆的「认识论字段」；Prompt 中的结构化标签有帮助但仍是 Context 的一部分，不是内部真正独立的认知空间，因而语言表达容易把「推理得到」误判为「新的发现」。
  • 「自我评价」并非「重新面对问题 → 独立判断」，而是「已经生成 C → C 进入 Context → 要求评价 C → 在包含 C 的 Context 中继续生成」；其准确名称是生成结果进入 Context 后对后续生成形成的路径依赖，而非心理意义上的辩护。
  • Context 应理解为 Information + Structure + Sequence + Generation History，而非仅仅 Information Set；它不只是模型知道什么，也包含模型是如何走到现在这个状态的。
  • 存在一种可称为「上下文认知惯性」的现象：生成改变 Context，Context 改变下一次生成，下一次生成继续改变 Context，形成连续反馈过程。
  • 「请严格批评自己的回答」通常不够可靠，因为它没有解决根本问题——模型仍然在原来的 Context 中进行批评，无法主动跳出既有推理路径重新建立搜索空间。
  • 洞察生成与洞察验证本质上是两种相反的搜索任务：生产向外扩大可能性（Expand Search Space），验证向内消灭可能性（Compress Conclusion Space）。
  • 独立审稿人真正的价值是 Context Reset；最重要的变化不是从单 Agent 变成双 Agent，而是从一条连续的认知路径变成两个独立的认知位置，机制名称是 Cognitive Separation 与 Context Reset。
  • Context Engineering 需要从 Context Assembly 发展到 Context Lifecycle Management，不仅要解决「添加什么信息」，还要解决什么信息应该删除、什么信息应该隔离、什么时候应该重置、哪些认知过程不应该继续传递。
  • 成熟的 Agent 系统不仅需要管理「Agent 记住什么」，还需要管理什么应该被遗忘、什么不应该参与下一轮判断、什么时候需要重新开始，因为记忆系统不仅积累知识，也积累认知路径。
  • Context 同时决定模型看到了什么与模型是在什么认知状态下看到这些信息，即还包括 Cognitive Position；未来 AI 系统设计需要增加一个问题——「模型现在是从什么认知位置进行判断的？」这可能比「Prompt 怎么写」更底层。
  • AI 的判断不仅取决于它看到了什么，也可能取决于它是如何走到现在这个判断位置的；因此有些时候正确的做法不是增加更多 Context，而是删除一些 Context，甚至重新开始一次思考；Context Engineering 的下一步也许不仅是管理信息，还需要开始管理模型的认知路径。

隐含前提

  • 模型继续生成这个洞察具有较高价值……这类解释性内容，可以被当作模型对该洞察给出了肯定评价，而不只是与评价无关的语言接续模式。置信 · 中

    支撑：很多后来被独立审查淘汰的结果，在生产阶段的自评中却经常被判断为：有价值、有新意、值得保留。

  • 自评偏高的主因是生成结果进入 Context 后形成的路径依赖，而不是模型在训练阶段被塑造出的肯定性/迎合性回答偏好。置信 · 高

    支撑：「一开始，我们把问题归因于 Prompt。」「这可能不是一个简单的 Prompt 问题。」

  • 同一批信息以不同路径进入 Context，会实质改变模型的判断结果，而不只是描述上「状态不同」。置信 · 高

    支撑：「但它们显然不是同一个状态。」

  • 自然语言指令（如请严格批评自己的回答）无法覆盖 Context 中已经存在的路径依赖，因此批评指令不能改变模型所处的认知位置。置信 · 中

    支撑：但它没有解决一个根本问题：模型仍然在原来的 Context 中进行批评。

  • 方向相反的两类搜索任务（向外扩大可能性与向内消灭可能性）不能由同一条连续认知路径在一次生成中兼得，因此任务的搜索方向差异会直接导致角色必须分离。置信 · 中

    支撑：「更重要的是，它们的搜索方向不同。」「因此，审稿人不应该继承生产者的完整推理过程。」

  • 把审稿人的 Context 重置为原文 + 候选洞察，能让模型真正回到独立判断的认知位置，而不只是表面上删掉了一段文本。置信 · 高

    支撑：而是：从一条连续的认知路径，变成两个独立的认知位置。

  • 单次洞察验证中观察到的路径依赖机制，与长期运行的 Agent 在 Memory 中跨轮次累积形成的认知路径依赖，是同一机制、可以互相外推。置信 · 中

    支撑：「如果这次探索成立，那么 AI Agent 系统可能存在一个更普遍的问题。」

  • 删除或隔离部分 Context 所造成的信息减少，其代价小于被已有内容锁定而丧失独立判断的代价。置信 · 高

    支撑：也许有些时候，正确的做法不是：增加更多 Context。而是：删除一些 Context。

03反向视角

  • 原文的因果归因缺少能分离变量的对照：把生产者的推理过程全部移出 Context 之后，自评是否仍然偏高，原文没有报告。若仍然偏高，那么起作用的是评判指令本身（例如请评价原创性这类提问自带肯定预设），而不是 Context 位置；此时八、九两节的架构与生命周期改造买不到它宣称的收益。这是未验证的问题，不是结论。
  • 独立审查淘汰了自评保留的结果，也可能只是两件事的难度差异造成的：回到原文做比对天然比生成结论更容易得出否定答案。淘汰率高并不等于判定更准，它同样兼容误杀率高。原文没有给出真新洞察被误判为重复的比例，因此把两阶段管线的产出直接当作质量提升，依据不足。
  • 如果把偏差主要归给参数层（我第一条洞察的方向），同样缺少依据：作者报告独立审查确实淘汰了大量自评保留的结果，这至少说明去掉生产推理会改变判断。两个来源可能同时成立，份额未知——因此无论把 Reset 的收益上限估得过高还是过低，目前都没有数据支撑。

替代性解释

  • 可以把自评偏高解释为指令语用问题而不是 Context 路径依赖：当提问形式为请评价这个洞察是否具有原创性时，回答顺着预设走是自然的。换成不带预设的指令（例如列出三处它与原文重叠的地方），在没有 Context Reset 的情况下也可能得到同样的否定结果。原文没有排除这个解释。
  • 也可以把生成后那段继续解释读作语言接续的默认行为而非一次真正的评价：续写一段论证比续写一句否定在生成上更容易，因此那段文字未必代表模型对自身洞察给出了肯定判断。原文把它直接读作评价结果，这一步转写本身没有被检验。

04核心洞察

分级 L0–L3 表示洞察深度递增；置信为结论的可靠程度

  • 原文把「自评偏高」的成因整体归到 Context 层，但 Context Reset 的作用域也止于 Context 层：它能清除随上下文携带的路径依赖，清除不了参数里固化的输出倾向。因此生产与验证分离是一个有上限的修复，而原文既没有给出这个上限的位置，也没有做过能把两来源分离的对照。L2 · 发现隐藏变量置信 · 中

    为什么：原文的因果链完整建立在这一句上：「生成的内容会进入 Context，而 Context 会改变模型下一步生成的条件。」它给出的解法（第八节的 Context Reset）操作的仍是同一层。原文甚至已经意识到层级问题的存在——它承认 Prompt 里的结构化标签「它们仍然属于 Context。」——但没有把这个层级意识推进到参数层：换一个干净的 Context 并不会换掉权重。同时，原文叙述从「很多后来被独立审查淘汰的结果」直接跳到机制归因，没有报告同一候选项在两种 Context 下由同一评判指令做出的对照结果，因此现有观察不足以确定偏差中由 Context 携带的份额。

    意义：这决定了排查顺序和投入位置。若把 Reset 当成完整解法，一旦效果低于预期，团队最可能的反应是回到 Prompt 或再加一层 Agent——而真正的缺口可能在参数层，加多少层 Context 操作都碰不到。正确的第一步是一个最小对照实验，先把偏差拆成上下文携带与参数携带两部分，再决定架构投入的规模。

  • 惯性是每一次生成都在产生的，而 Reset 是一次性动作；所以 Reset 之后系统不是回到初始状态，而是换到一个新的起点，并从这个新起点继续累积。同一个机制在验证阶段同样运行：验证者一旦开始输出重复或否定判断，后续也会沿着找证据支持该判断的方向展开。结果是，双 Agent 管线并不抵消偏差，而是把偏差的方向从偏向接受翻转成偏向拒绝，最终结论取决于两段偏差的相对强度，而不是自动趋近正确。L2 · 发现隐藏变量置信 · 中

    为什么：原文对惯性的两句表述描述的是机制本身，并没有把它限定在生产阶段：「它不意味着模型无法改变方向。」以及「模型已经生成的路径，会改变下一步生成的概率空间。」与此同时，原文把验证描述成方向相反的任务：「一个在寻找可能。」「一个在消灭可能。」把这两条合起来，验证阶段是压缩目标叠加自身路径累积的组合，其失败方向与生产端正相反。而原文的架构图在生产与验证之间只放了一次 Reset（第八节），生命周期序列里 Reset 的位置也是一个单点动作。

    意义：评价指标要换。只看淘汰率只能证明验证端有偏好，不能证明判定更准确——高淘汰率同时兼容更严格和更多误杀两种解释。可行做法是在样本中混入已知成立的新洞察，分别标定生产端与验证端的偏差方向和幅度，再决定是否需要给验证过程本身再加一层独立复核。

  • 原文交给验证者的职责清单内部有一处未处理的冲突：检查推理边界需要看到推理步骤，而保持独立判断要求看不到它。原文没有区分结论层面的越界与推理步骤层面的越界，这两件事对 Context 的要求正好相反。一旦把这个区分显式化，Reset 就不再是一个可以一次执行完的动作，而是一个有序且不可逆的判断序列。L2 · 发现隐藏变量置信 · 中

    为什么：第八节给验证者的任务里有「检查推理边界」，同一节又明确写下「审稿人不应该继承生产者的完整推理过程。」并给出理由「因为这会提前建立一个解释框架。」如果这条理由成立，那么推理过程在同一次判断里被用来做边界检查时，同样会提前建立解释框架，从而污染来源与独立性的判断。原文没有说明「推理边界」指的是结论与证据的相对关系，还是推导链中每一步的合法性；前者可以只看候选结论与原文，后者必须看到步骤。两种读法对应两种不可兼得的 Context 配置。

    意义：实现层面它不是做一个 Reviewer Agent，而是在同一候选洞察上做两次单向隔离的判断：先在不看推理的条件下判来源与独立性，再看推理判步骤是否越界，且后一步的结论不得回流到前一步。这个顺序不可逆——先看推理再做独立性判断，等于把 Reset 白做了一次。

  • 原文建议有时该「删除一些 Context」或「增加更多 Context」，但没有给这个操作定价。被删掉的推理过程不是垃圾，它是生产阶段的全部工作产物；验证者要重新达到能够下判断的位置，必须把这条推导链自己再走一遍。于是出现一个原文没有处理的交换：越是不属于原文的新结构，推导链越长，独立验证的再推导成本越高；而验证成本最低的，恰好是最接近原文的那些表达。L2 · 发现隐藏变量置信 · 中

    为什么：原文自己承认生产需要「发现关联」、需要「扩大可能性」这类过程性内容，也就是说这些内容是有产出的工作，不是噪声。Reset 把它们从验证者的 Context 中移出，等于把重建成本转嫁给验证者。原文在结尾只比较了信息多少与独立性两个维度，没有比较删除带来的独立性收益与重建成本之间的高低。

    意义：管线的实际吞吐由验证成本决定，而不是由生产速度决定，并且这个瓶颈会随洞察的新颖度上升而收紧。工程上更合理的做法是按预期验证成本给候选分档：用便宜的操作（来源检索、已有表达搜索）做粗筛，只对通过粗筛的少数执行昂贵的反例搜索与独立重推，而不是对所有候选一视同仁地做完整 Reset。

  • 原文把生命周期写成包含「Detect Contamination」的线性序列，这隐含了污染可以在某个时刻被识别出来。但按原文自己对 Context 的定义，污染不是某条内容的固有属性，而是这条内容与当前任务的关系：同一段被废弃的解释框架，在判断新问题时是污染，在复盘失败路径时是关键材料。因此检测的位置不应该在写入或累积时刻，而只能在与任务绑定的装配时刻。L2 · 发现隐藏变量置信 · 中

    为什么：原文的定义句是「Context 不只是模型知道什么，也包含模型是如何走到现在这个状态的。」它把顺序与生成历史也算作 Context 的组成部分，同一份信息落在不同序列位置会产生不同效果。既然效果取决于序列位置与当前任务，那么对同一份内容是否构成污染的判定就不可能独立于任务而给出。原文另有一句支持内容与角色绑定：「结论进入 Memory / Context」之后才「影响下一轮判断」，污染是在使用环节才发生作用。

    意义：工程上应把归档层与工作上下文层分开：写入时不判断污染，只保留来源与产生它的任务元数据；是否注入由当前任务决定。否则「检测污染」会退化为一个人工无法执行、自动化也无法定义的检查项，写进设计文档后无人能实现。