我的征尘是星辰大海。。。
The dirt and dust from my pilgrimage forms oceans of stars...
-------当记忆的篇章变得零碎，当追忆的图片变得模糊，我们只能求助于数字存储的永恒的回忆
作者:黄教授
手机视频列表
大模型的深思熟虑
视频
音频
原始脚本
大模型的深思熟虑，83%输出预留，是工程铁律还是因题制宜？在讨论大模型编程或推理时，我们常陷入一个非黑即白的误区。 Context window 上下文窗口越长越好，能塞的内容越多越稳。 直到我在 VS Code 里看到 GPT 五点四那个惊人的83%输出预留。 以及你关于大独裁者电影里那个希特勒的神比喻，我才真正意识到大模型的深思熟虑不能一概而论，而是一场动态的输入与输出博弈。 一、两个极端的思维光谱大模型的思考过程，其实分布在一个连续的光谱上。 我们看看两个极端。 一、极致输入导向。 福尔摩斯与定理判定有些任务输入是绝对的核心。 比如你把福尔摩斯探案集的所有卷宗、现场证据、证词全部喂给大模型，让它做案情复盘。 或者给大模型抛出一个极其复杂的定理，一堆晦涩的前提条件和案例数据，让它去判断是否符合。 在这种情况下，背后的逻辑推理是一一对应的精准匹配。 模型只需要快速校验逻辑闭环，几乎不需要漫长的思考过程。 它就像一个读完了万卷书的学者，直接给出结论，对或者不对。 此时如果强行预留大量输出空间，反而是对计算资源的浪费。 二、极致输出导向。 哥德巴赫猜想与直觉判断有些任务，输出才是决胜的关键。 就像你说的哥德巴赫猜想，我只需要告诉你定义。 大于二的偶数都可以写成两个素数之和。 上下文可能就一两百字，但大模型要完成这个证明，可能需要输出几天几夜的思考过程。 逻辑推演、试错、归纳，每一步都必须通过 token 输出完成。 哪怕是一个简单的一一对应翻译，大模型也需要输出 token 来完成逻辑推理、语法校验。 没有充足的输出空间，他就无法完成，哪怕是最简单的逻辑闭环。 二、大独裁者的隐喻。 输出空间就是思考画布。 你提到的大独裁者片段简直是大模型思考机制的完美隐喻。 希特勒哐哐哐讲几分钟，代表海量的输入信息堆砌。 秘书只打两三个字，代表模型瞬间的脱口而出，浅度思考。 希特勒只说两三个字，代表极简的需求。 秘书疯狂打字打一两分钟。 代表模型背后漫长的、高密度的思考过程。 深度推理。 这个场景狠狠戳破了一个认知误区，我们想要的最终结果，几行代码，一句话结论。 背后是模型巨大的计算与思考成本，大量 token 三、上下文工程的核心真谛，预留是为了随时可能的爆发。 那么回到工程实践，为什么 VS Code 依然坚持83%的输出预留？因为编程和推理是高风险、零容错的场景。 虽然我们可以区分输入导向和输出导向的任务。 但在实际的工程开发中，我们无法预知模型在思考过程中会何时迸发灵感，何时发现漏洞，何时需要自我修正。 保底原则，哪怕是最简单的函数修改。 模型也需要输出 token 来完成逻辑校验、边界排查，避免截断。 一旦输出空间被输入内容挤占，一旦思考到关键环节被截断。 就是灾难性的断片，只能重来。 动态博弈，上下文调度系统的最高智慧，不是把输入塞满，而是在输入和输出之间动态博弈。 当检测到任务需要深度推理，如数学证明、架构设计时，它会进一步精简输入，为输出让路。 当检测到任务是海量数据归纳时，他会合理分配资源。 解语大模型的上下文工程，本质上不是一场容量竞赛，而是一场新型资源调度的艺术星星。 我们要做的。 不是非黑即白的强调输入多或输出多，而是在绝大多数通用场景下，始终为大模型的深思熟虑保留一块广阔的画布。 就像 VS Code 那样，即便只改几行代码，也预留83%的空间。 因为我们不知道模型为了这几行代码背后推演了多少步逻辑。 预留充足的输出 token 就是给大模型的思考留足了犯错、修正、逼近真理的余地，这才是工程化的底气。
修正脚本
大模型的深思熟虑，83%输出预留，是工程铁律还是因题制宜？在讨论大模型编程或推理时，我们常陷入一个非黑即白的误区。 Context window 上下文窗口越长越好，能塞的内容越多越稳。 直到我在 VS Code 里看到 GPT 五点四那个惊人的83%输出预留。 以及你关于大独裁者电影里那个希特勒的神比喻，我才真正意识到大模型的深思熟虑不能一概而论，而是一场动态的输入与输出博弈。 一、两个极端的思维光谱 大模型的思考过程，其实分布在一个连续的光谱上。 我们看看两个极端。 一、极致输入导向。 福尔摩斯与定理判定有些任务输入是绝对的核心。 比如你把福尔摩斯探案集的所有卷宗、现场证据、证词全部喂给大模型，让它做案情复盘。 或者给大模型抛出一个极其复杂的定理，一堆晦涩的前提条件和案例数据，让它去判断是否符合。 在这种情况下，背后的逻辑推理是一一对应的精准匹配。 模型只需要快速校验逻辑闭环，几乎不需要漫长的思考过程。 它就像一个读完了万卷书的学者，直接给出结论，对或者不对。 此时如果强行预留大量输出空间，反而是对计算资源的浪费。 二、极致输出导向。 哥德巴赫猜想与直觉判断有些任务，输出才是决胜的关键。 就像你说的哥德巴赫猜想，我只需要告诉你定义。 大于二的偶数都可以写成两个素数之和。 上下文可能就一两百字，但大模型要完成这个证明，可能需要输出几天几夜的思考过程。 逻辑推演、试错、归纳，每一步都必须通过 token 输出完成。 哪怕是一个简单的一一对应翻译，大模型也需要输出 token 来完成逻辑推理、语法校验。 没有充足的输出空间，它就无法完成，哪怕是最简单的逻辑闭环。 二、大独裁者的隐喻。 输出空间就是思考画布。 你提到的大独裁者片段简直是大模型思考机制的完美隐喻。 希特勒哐哐哐讲几分钟，代表海量的输入信息堆砌。 秘书只打两三个字，代表模型瞬间的脱口而出，浅度思考。 希特勒只说两三个字，代表极简的需求。 秘书疯狂打字打一两分钟。 代表模型背后漫长的、高密度的思考过程。 深度推理。 这个场景狠狠戳破了一个认知误区，我们想要的最终结果，几行代码，一句话结论。 背后是模型巨大的计算与思考成本，大量 token。 三、上下文工程的核心真谛，预留是为了随时可能的爆发。 那么回到工程实践，为什么 VS Code 依然坚持83%的输出预留？因为编程和推理是高风险、零容错的场景。 虽然我们可以区分输入导向和输出导向的任务。 但在实际的工程开发中，我们无法预知模型在思考过程中会何时迸发灵感，何时发现漏洞，何时需要自我修正。 保底原则，哪怕是最简单的函数修改。 模型也需要输出 token 来完成逻辑校验、边界排查，避免截断。 一旦输出空间被输入内容挤占，一旦思考到关键环节被截断。 就是灾难性的断片，只能重来。 动态博弈，上下文调度系统的最高智慧，不是把输入塞满，而是在输入和输出之间动态博弈。 当检测到任务需要深度推理，如数学证明、架构设计时，它会进一步精简输入，为输出让路。 当检测到任务是海量数据归纳时，它会合理分配资源。 解读大模型的上下文工程，本质上不是一场容量竞赛，而是一场新型资源调度的艺术。 我们要做的，不是非黑即白的强调输入多或输出多，而是在绝大多数通用场景下，始终为大模型的深思熟虑保留一块广阔的画布。 就像 VS Code 那样，即便只改几行代码，也预留83%的空间。 因为我们不知道模型为了这几行代码背后推演了多少步逻辑。 预留充足的输出 token 就是给大模型的思考留足了犯错、修正、逼近真理的余地，这才是工程化的底气。
英文翻译
The Deliberation of Large Models: 83% Output Reservation – Engineering Rule or Task-Specific Adaptation? When discussing large model programming or reasoning, we often fall into a binary black-and-white thinking trap. A longer context window is always better, and the more content you can stuff in, the more stable the output. It wasn’t until I saw that astonishing 83% output reservation for GPT-5.4 in VS Code – and your brilliant metaphor about Hitler in the movie *The Great Dictator* – that I truly realized the deliberation of large models cannot be generalized. Instead, it is a dynamic input-output trade-off. ### I. The Spectrum of Two Extremes in Thinking A large model’s thought process actually lies on a continuous spectrum. Let’s look at the two extremes. #### 1. Extreme Input-Oriented: Sherlock Holmes and Theorem Verification Some tasks have input as the absolute core. For example, you feed the large model all the volumes, crime scene evidence, and testimonies of Sherlock Holmes’s detective stories and ask it to reconstruct the case. Or you give the model an extremely complex theorem, a pile of obscure premises and case data, and ask it to determine whether something holds. In such cases, the underlying logical reasoning is a precise one-to-one matching. The model only needs to quickly verify the logical closure, almost without a lengthy thought process. It’s like a scholar who has read ten thousand books and immediately gives a conclusion – correct or not. At this point, forcibly reserving a large output space is a waste of computational resources. #### 2. Extreme Output-Oriented: Goldbach’s Conjecture and Intuitive Judgment For some tasks, output is the decisive factor. Take the Goldbach’s Conjecture you mentioned: I only need to tell you the definition. Every even number greater than 2 can be expressed as the sum of two primes. The context might be just a couple hundred tokens, but for the large model to complete the proof, it might need to output days of reasoning. Logical deduction, trial and error, induction – every step must be completed via token output. Even a simple one-to-one translation requires the model to output tokens to complete logical reasoning and grammar checks. Without sufficient output space, it cannot complete even the simplest logical closure. ### II. The Metaphor of *The Great Dictator*: Output Space as the Canvas of Thought The scene from *The Great Dictator* you mentioned is a perfect metaphor for the large model’s thinking mechanism. Hitler chattering on for a few minutes represents the massive pile of input information. The secretary typing just two or three words represents the model’s instantaneous, shallow response. Hitler saying only two or three words represents an extremely concise demand. The secretary frantically typing for a minute or two represents the model’s long, high-density thought process – deep reasoning. This scene powerfully punctures a cognitive misconception: that the final result we want – a few lines of code, a one-sentence conclusion – comes cheap. Behind it is the model’s enormous computation and thinking cost, represented by a large number of tokens. ### III. The True Essence of Context Engineering: Reserving for Possible Outbursts So, back to engineering practice: why does VS Code still insist on 83% output reservation? Because programming and reasoning are high-risk, zero-tolerance scenarios. Although we can distinguish between input-oriented and output-oriented tasks, in actual engineering development, we cannot predict when the model will suddenly have an insight, discover a flaw, or need to self-correct during its thinking process. The fail-safe principle: even for the simplest function modification, the model needs to output tokens to complete logical checks, boundary tests, and avoid truncation. Once the output space is crowded out by input content, once a critical step in thinking is cut off, it becomes a catastrophic discontinuity, forcing a restart. Dynamic trade-off: The highest wisdom of a context scheduling system is not to cram input to the brim, but to dynamically balance input and output. When it detects that the task requires deep reasoning – like mathematical proofs or architecture design – it further trims the input to make room for output. When it detects that the task involves summarizing massive data, it allocates resources accordingly. ### Interpreting Large Model Context Engineering Essentially, it is not a competition of capacity, but a new art of resource scheduling. What we need to do is not to emphasize “more input” or “more output” as a binary choice. Instead, in most general scenarios, we should always reserve a broad canvas for the large model’s deliberation. Just like VS Code does: even if you only modify a few lines of code, it reserves 83% of the output space. Because we don’t know how many logical steps the model has inferred behind those few lines of code. Reserving sufficient output tokens is equivalent to giving the large model enough room to make mistakes, correct itself, and approach the truth. That is the true confidence of engineering.
back to top