如何让大语言模型进行数学推理而非文本生成？re!think协议实测对比

引言：过度工程化问题

当今IT行业在使用大语言模型（LLM）时存在一个巨大的矛盾。

There is a huge contradiction in how the IT industry uses LLMs today.

模型拥有百万级的上下文窗口，它们完美地理解代码、数学和逻辑。但我们做了什么？我们把它们当作愚蠢的文本生成器。我们用数十万行外部Python代码——LangChain、多智能体框架、RAG检查器、语义路由器——将它们包裹起来。我们建造了一个庞大的工厂，只是为了钉一颗钉子。

Models have million-token context windows. They understand code, math, and logic perfectly. But what do we do? We treat them like dumb text generators. We wrap them in hundreds of thousands of lines of external Python code — LangChain, multi-agent frameworks, RAG checkers, and semantic routers. We build a massive factory just to hammer a nail.

我想测试一种不同的方法：我们能否通过将整个逻辑构建在上下文窗口内部，来获得同样稳定的结果？

I wanted to test a different approach: Can we get the same stable results by building the whole logic inside the context window?

这个实验最初是用纯俄语（完整版和紧凑版）进行的，然后是英语（完整版和紧凑版——英语紧凑版大约1300个token）。

It started as an experiment in plain Russian (full and compact versions), then English (full and compact versions — the English compact came in at around 1,300 tokens).

当我审视自己提示词的内部结构时，我意识到我直觉地将7个重量级的后端机制打包进了一个单一的.md文件中。

When I looked under the hood of my own prompt, I realized I had intuitively packed 7 heavy backend mechanics into a single .md file.

下面就是我发现的内部机制。

Below is what I found inside.

---

核心机制：企业级脚手架 vs. 上下文内逻辑

为了保持一致性，下面的每个概念都从相同的三个角度进行阐述：

For consistency, every concept below is broken into the same three angles:

• 它是什么 —— 简短描述，让你知道我们在讨论什么问题 (What it is — a short description so you know what problem we're talking about)
• 行业通常如何实现 —— 这部分是与LLM作为研究伙伴共同组装的；它们分析了现有方法并给出了自己的看法，我只为呈现清晰度做了调整 (How the industry does it — this part was assembled with LLMs as research partners; they analyzed existing approaches and gave their take, I only adjusted for clarity of presentation)
• re!think 如何实现 —— 这个机制如何在协议内部实现，尽可能简洁 (How re!think does it — how this mechanic is implemented inside the protocol, as concisely as possible)

如果你想看看所有这些是如何在协议本身内部解释的——包含了完整的推理和构建逻辑——文章末尾有一个链接。

And if you want to see how all of this is explained inside the protocol itself — with the full reasoning and construction logic baked in — there's a link at the end of the post.

---

1. 意图路由在LLM应用流程中，系统理解用户请求意图并选择相应处理路径的机制。re!think协议通过上下文内的IF/THEN逻辑块实现，与传统基于向量嵌入和外部代码的路由方式形成对比。 (⬡ ROUTER)

它是什么： 在做任何事情之前，系统需要理解用户想要什么（例如，精确搜索 vs. 创造性头脑风暴）并选择正确的路径。

What it is: Before doing anything, the system needs to understand what the user wants (e.g., exact search vs. creative brainstorming) and choose the right path.

行业通常如何实现： 据我所知，标准设置类似于：通过嵌入模型运行提示词，比较向量，通过Python路由到正确的LLM链。我自己没有构建过这个技术栈——但它在LangChain自己的指南中有详细记载，所以我姑且相信。

How the industry does it: From what I've read, the standard setup is something like: run the prompt through an embedding model, compare vectors, route to the right LLM chain via Python. I haven't built this stack myself — but it's well documented in LangChain's own guides, so I'll take it at face value.
(Verdict: slow, heavy, a separate network call before the actual work even starts).

re!think 如何实现： 在系统提示词中设置严格的 PROT_A / PROT_B / C_BYPASS IF/THEN 块。模型会静默地对请求进行分类，并立即切换分支。

How re!think it does it: A strict PROT_A / PROT_B / C_BYPASS IF/THEN block right in the system prompt. The model silently categorizes the request and switches branches instantly.

• 主要缺点： 对于非常令人困惑的提示词，它可能会出错。工业级方法更准确。 (Main drawback: It can make a mistake on very confusing prompts. The industrial way is more accurate.)
• 绝对优势： 零延迟。零外部代码。它有一个显式的旁路 (C_BYPASS)，因此简单问题不会被重量级的推理框架处理。 (Absolute win: Zero latency. Zero external code. It has an explicit bypass (C_BYPASS) so simple questions don't get processed by heavy reasoning frameworks.)

关于路由的补充说明：将这一步委托给一个轻量级模型，就像让一个初级经理负责一个专家团队——有人决定谁做什么，但并不完全理解每个人实际在做什么。路由是流程中最关键的步骤之一。如果出错，超过一半的路径从一开始就变得毫无意义。真正的思维灵活性始于对工具的深思熟虑的选择——以及关于如何应用它的同样深思熟虑的决定。

A side note on routing in general: delegating this step to a lightweight model is like putting a junior manager in charge of a team of specialists — someone who decides who works on what, but doesn't fully understand what anyone actually does. Routing is one of the most consequential steps in the pipeline. Get it wrong, and more than half your trajectories become meaningless from the very start. Real flexibility of thinking begins with a thoughtful choice of tool — and an equally thoughtful decision about how to apply it.

2. 预生成门控一种在LLM生成最终答案前进行的验证机制。当检测到上下文与目标之间存在关键信息缺口时，强制模型停止生成并请求澄清，旨在防止幻觉。re!think协议通过内嵌的数学公式Δ = Goal − (Context + Tools)来实现。 (HARD STOP)

它是什么： 如果系统缺少关键数据，它必须停止并询问。它不应该为了给出快速答案而猜测（产生幻觉）。

What it is: If the system is missing critical data, it must stop and ask. It shouldn't guess (hallucinate) just to give a fast answer.

行业通常如何实现： 据我理解——编写验证代码，让LLM输出JSON，运行外部脚本（Pydantic似乎是标准）来检查缺失字段。或者进行第二次LLM传递来审查第一次的结果。

How the industry does it: As best I understand it — write validation code, have the LLM output JSON, run an external script (Pydantic seems to be the standard) to check for missing fields. Or do a second LLM pass to review the first one.
(How it works in practice: the LLM generates garbage, then you try to catch it downstream. At least that's what it looks like from the outside.)

re!think 如何实现： 模型在回答前会解一个简单的数学公式：Δ = Goal − (Context + Tools)。如果 Δ 太大——意味着我对你情况的了解存在关键缺口——模型就会触发 HARD STOP。它必须提出一个清晰的问题。不是一个。不是一个列表。一个能填补最重要缺口的问题。没有第二次运行，没有JSON解析，没有外部验证器。

How re!think it does it: The model solves a simple math formula before answering: Δ = Goal − (Context + Tools). If Δ is too big — meaning there's a critical gap in what I know about your situation — the model hits a HARD STOP. It must ask exactly 1 clear question. Not two. Not a list. One question that closes the most important gap. No second runs, no JSON parsing, no external validator.
(Main drawback: it relies on the model being honest about what it doesn't know. The code-based check is more reliable on paper. But it's also slower, more brittle, and costs extra calls. The in-context version is much faster — and in practice, it works.)

3. 动态用户画像

它是什么： 系统适应用户的技能水平和限制，而无需每次都询问。

What it is: The system adapts to the user's skill level and limits without asking every time.

行业通常如何实现： 据我所知，是RAG。某些服务读取聊天记录，构建用户画像，保存到向量数据库，稍后取出。细节因技术栈而异——我简化了。

How the industry does it: RAG, as far as I know. Some service reads the chat, builds a profile, saves it to a Vector DB, pulls it out later. The details vary by stack — I'm simplifying.

re!think 如何实现： 模型从聊天中动态提取变量：S_R（角色），S_T（信任级别），S_V（边界）。这些不仅仅是为了“调整语气”。它们作为推理过程的严格数学限制。

How re!think it does it: The model extracts variables from the chat on the fly: S_R (Role), S_T (Trust level), S_V (Boundaries). These aren't just for "fixing the tone". They act as strict mathematical limits for the reasoning process.
(Verdict: Great for one long chat session. But it won't remember you tomorrow. For long-term memory across days, Vector DB wins).

对我来说，这里的主要想法不是“对所有东西进行画像”。而是：有意识地选择你的画像参数，并提前思考每个参数将如何塑造推理过程——而不仅仅是回答的语气。S_R 不仅仅是调整词汇。它缩小了模型被允许探索的整个解空间。这就是我希望你从本节中学到的东西。

The main idea for me here wasn't "profile everything." It was: choose your profile parameters deliberately, and think in advance about exactly how each one will shape the reasoning — not just the tone of the response. S_R doesn't just adjust the vocabulary. It narrows the entire solution space the model is allowed to explore. That's what I want you to take from this section.

4. 对抗“平庸”答案（反质心过滤器re!think协议中用于对抗模型生成“统计平均”或“安全”答案的机制。基于集合论规则（M_filtered = M - {P_centroid}），强制模型摒弃最显而易见的初始答案，探索非标准或反直觉的解决方案路径。）

它是什么： 如何阻止模型给出无聊的、统计上平均的、“安全”的答案。

What it is: How to stop the model from giving boring, statistically average, "safe" answers.

行业通常如何实现： 主要是在服务器层面调整Temperature。还有一些惩罚算法，明确抑制高频token——但我真的不确定这些在多大程度上部署在生产环境中，而不仅仅是在论文中描述。

How the industry does it: Temperature tweaking at the server level, mostly. There are also penalty algorithms that explicitly suppress high-frequency tokens — but I'm honestly not sure how widely those are deployed in production versus just described in papers.

re!think 如何实现： 提示词中的一个集合论规则：M_filtered = M - {P_centroid}。我明确告诉模型：“扔掉你脑海中出现的第一个默认答案。” 此外，它被迫生成至少3条标准路径和1条完全反直觉的路径。

How re!think it does it: A set theory rule in the prompt: M_filtered = M - {P_centroid}. I explicitly tell the model: "Throw away the first default answer that comes to your mind." Plus, it is forced to generate at least 3 standard paths and 1 completely counter-intuitive path.

这更像是受控的想象力，而非随机的创造力。如果你只是调高Temperature，你会得到疯狂且不可行的想法——伪装成新颖性的噪音。但是，如果你在仍然在合理想法空间内搜索的同时，明确移除默认答案，你会得到更有用的东西：非显而易见的、实际上值得测试的假设——或者至少值得与用户讨论。

This is closer to controlled imagination than random creativity. If you just crank up the Temperature, you get wild and unfeasible ideas — noise dressed up as novelty. But if you explicitly remove the default answer while still searching within the space of plausible ideas, you get something more useful: non-obvious hypotheses that are actually worth testing — or at least worth running by the user.

5. 上下文内垃圾回收在长对话中管理LLM注意力漂移的机制。re!think协议采用严格的指针系统（如C.0014 := C.0005），规定变量在超过一定消息数（如10条）后必须被重写至新的消息块中，以强制刷新其在模型注意力中的活跃度。器 (Pointer GC)

它是什么： 阻止注意力漂移。在长对话中，模型会简单地忘记早期的规则和变量。

What it is: Stopping attention drift. In a long chat, the model simply forgets the early rules and variables.

行业通常如何实现： 据我所见，是记忆智能体。它们持续读取历史记录并生成摘要。或者公司直接购买200万token的上下文窗口，把所有东西都扔进去。两者都很昂贵。这两种方法是否真的解决了漂移问题，还是只是推迟了它——老实说，我不知道。

How the industry does it: Memory Agents, from what I've seen. They read the history continuously and produce summaries. Or companies just buy 2M-token context windows and throw everything in. Both are expensive. Whether either actually solves the drift problem or just postpones it — I honestly don't know.

re!think 如何实现： 一个严格的指针系统 (C.0014 := C.0005)。规则很简单：一个变量的生存期不能超过10条消息。在第11步，模型必须将变量重写到新的消息块中。这是手动垃圾回收。我们迫使模型在指针掉出活跃注意力区域之前刷新它。

How re!think it does it: A strict pointer system (C.0014 := C.0005). The rule is simple: a variable cannot live longer than 10 messages. On the 11th step, the model MUST rewrite the variable into the new message block. It's manual trash collection. We force the model to refresh the pointer before it falls out of the active attention zone.
(Bonus: Absolute transparency. Because the model prints these variables in a technical header every time, you can audit exactly what data it is using to think).

6. “锚点”（注意力锚定一种通过特定触发短语（如“re!think protocol”）在每次响应生成前将LLM的注意力重新聚焦到核心系统指令上的技术。旨在缓解长对话中初始提示影响力衰减的问题，成本低廉（仅几个词元）。）

它是什么： 当对话拉长时，如何保持模型的专注。到第100条消息时，原始系统提示词的影响力下降到接近零，模型开始忽略指令。

What it is: How to keep the model focused when the dialogue stretches. By the 100th message, the influence of the original system prompt drops to near zero, and the model starts ignoring instructions.

行业通常如何实现： 定期重新注入系统提示词。或者只是相信原生的注意力机制能把事情整合在一起。第二种选择似乎比我预期的更常见。

How the industry does it: Re-inject the system prompt periodically. Or just trust the native attention mechanism to hold things together. That second option seems more common than I would expect.
(Verdict: expensive. And from everything I've read — fundamentally unreliable at scale).

re!think 如何实现： 每一条技术日志都严格以触发短语 re!think protocol 开头。我最初这样做只是为了在视觉上分隔日志——它与注意力机制无关。但事实证明，它起到了认知锚点的作用。模型在采取任何行动之前，物理上必须打印这些词。打印这些词会立即将其注意力拉回到核心规则上，然后才生成响应。这不是一个技巧。这就是注意力实际工作的方式——你专注于你刚刚接触过的东西。

How re!think it does it: Every single technical log strictly begins with the trigger phrase re!think protocol. I did this originally just to separate logs visually — it had nothing to do with attention mechanics. But it turns out it acts as a cognitive anchor. The model physically has to print these words before doing anything. And printing them drags its attention back to the core rules immediately before it generates the response. It's not a hack. It's how attention actually works — you focus on what you just touched.
(Cost: 3 tokens. Effect: a non-stop "System 2" wake-up call. Instead of hoping the model stays obedient, we force it to touch the rule-set before every single action.)

完全披露：这不是一个完整的解决方案。它延长了系统提示词的工作寿命——但在非常长且离题的对话中，它仍然可能失效。一个真正稳健的解决方案需要基于数千个协议驱动的对话来训练模型，这样推理逻辑就会被烘焙到基础权重中。一旦实现，每一步的锚定就会成为一种反射——就像你走路时不会思考平衡一样。在此之前，这个锚点是一个有用的补丁，而不是治愈方法。真正的目标是拥有一个不需要“记住公式”的模型——因为它已经知道如何思考。

Full disclosure: this isn't a complete solution. It extends the working life of the system prompt — but it can still break down in very long, digressive conversations. A truly robust fix would require training the model on thousands of protocol-driven dialogues, so that the reasoning logic gets baked into the base weights. Once that happens, anchoring at each step becomes a reflex — the same way you don't think about balance when you walk. Until then, this anchor is a useful patch, not a cure. The real goal is a model that doesn't need to "remember the formula" — because it already knows how to think.

7. 结构化数学 vs. “意识流”

它是什么： 如何控制实际的逻辑流程，确保模型解决任务，而不是在无尽的循环中自言自语。

What it is: How to control the actual logic flow, ensuring the model solves the task instead of just talking to itself in endless circles.

行业通常如何实现： 思维链。告诉模型“一步一步地思考”。它生成一堵文字墙。

How the industry does it: Chain-of-Thought.

常见问题（FAQ）

re!think协议一种约1300词元的提示词设计框架，旨在将复杂的推理逻辑（如路由、验证、分析）直接嵌入大型语言模型的上下文窗口内，教导模型进行结构化、数学化的思考，减少对外部代码框架的依赖。与传统企业级框架的主要区别是什么？

re!think协议一种约1300词元的提示词设计框架，旨在将复杂的推理逻辑（如路由、验证、分析）直接嵌入大型语言模型的上下文窗口内，教导模型进行结构化、数学化的思考，减少对外部代码框架的依赖。通过约1300词元的提示词将七种核心推理机制直接嵌入LLM上下文窗口，实现高效的内置逻辑，而传统方法依赖大量外部代码构建复杂框架。

re!think协议一种约1300词元的提示词设计框架，旨在将复杂的推理逻辑（如路由、验证、分析）直接嵌入大型语言模型的上下文窗口内，教导模型进行结构化、数学化的思考，减少对外部代码框架的依赖。如何解决LLM过度工程化的问题？

它主张将逻辑构建在上下文窗口内部，教导模型进行数学推理而非文本生成，避免使用数十万行外部Python代码包裹模型，实现更简洁高效的解决方案。

re!think协议一种约1300词元的提示词设计框架，旨在将复杂的推理逻辑（如路由、验证、分析）直接嵌入大型语言模型的上下文窗口内，教导模型进行结构化、数学化的思考，减少对外部代码框架的依赖。中的意图路由在LLM应用流程中，系统理解用户请求意图并选择相应处理路径的机制。re!think协议通过上下文内的IF/THEN逻辑块实现，与传统基于向量嵌入和外部代码的路由方式形成对比。是如何实现的？

在系统提示词中设置严格的PROT_A/PROT_B/C_BYPASS IF/THEN块，模型会静默地对用户请求进行分类并立即切换分支，无需外部向量比较和网络调用。