Cumulative Reasoning

1) 这项提示词技术是什么：Cumulative Reasoning（累积式推理）

核心思路：把“解题/推理”当成一个可迭代的流程，而不是一次性生成最终答案。每一轮分三步：

1. 生成候选步骤：先让模型提出多个“可能的下一步/推理步骤”（不是直接给最终答案）。
2. 评估并筛选步骤：再让模型（同一个或另一个“评审”角色）对这些候选步骤逐条审查，决定接受/拒绝，只保留靠谱的步骤加入“已确认步骤集合”（cumulative，累积起来）。
3. 检查是否完成：判断是否已经能得出最终答案；若不能，就在已确认步骤的基础上继续下一轮，直到完成或达到迭代上限。

它和常见的 Chain-of-Thought 的区别在于：

• CoT 往往是“一条链写到底”；
• Cumulative Reasoning 是“多候选 → 审核 → 累积 → 再迭代”，更像带自我审计的逐步搜索。

你给的描述中提到它在逻辑推断与数学问题上提升明显：原因通常是“候选生成带来探索”，而“审核机制”降低了错误步骤被一路带偏的风险。

---

2) 适合的应用场景（建议用）

1. 数学/算法题、符号推理
   • 例如：方程求解、数列、组合计数、概率推断、复杂单位换算。
2. 多跳逻辑推断、规则推理
   • 例如：条件很多的题干、法律条文/制度规则的逐条适用、逻辑谜题。
3. 需要可控“逐步验证”的任务
   • 例如：推导公式、证明思路、排错（debug）中每一步要检查是否违反约束。
4. 对错误成本敏感的输出
   • 例如：财务计算、投标报价校验、工程计算（仍建议最终做外部校验）。

---

3) 不适合的应用场景（不建议用或收益不大）

1. 开放式创作类
   • 小说、文案、诗歌：不存在明确“步骤对错”，评审的 accept/reject 容易变成主观偏好，收益有限。
2. 强依赖外部事实/最新信息的任务
   • 比如“今天某公司股价”“最新政策”：Cumulative Reasoning 不能替代检索与事实核验，反而可能“越推越自信地错”。
3. 步骤很短、直接回答更好
   • 例如：简单翻译、改写、生成标题。引入多轮会增加成本与时延。
4. 需要严格可复现的形式化证明/验证
   • 模型评估步骤仍可能误判；关键场景应结合定理证明器/计算器/单元测试等外部验证工具。

---

4) 提示词怎么写：一个通用模板

你可以把它写成“两个阶段/两个角色”：

• 生成器（Proposer）：给出多个候选下一步
• 评审（Verifier/Judge）：逐条验收，并输出“已确认步骤 + 下一轮要做什么”

建议在提示词里明确：

• 每轮输出格式（候选步骤编号、审核结论）
• 验收标准（是否与已确认步骤一致、是否有跳步、是否引入未证明假设、计算是否正确）
• 迭代上限（防止死循环）
• “只累积被接受的步骤”

---

5) 至少 3 个中文实战例子（含可直接复制的提示词）

下面给你 3 个不同类型任务的写法示范。你可以直接复制到对话里用。

---

例子 1：数学题（方程求解）——多候选 + 审核 + 迭代

任务：解方程 ((x-2)(x+3)=0)

Prompt（可复制）：

你将使用“累积式推理”来解题。
规则：每一轮分为【候选步骤生成】、【步骤审核】、【累积步骤】、【完成检查】。

• 【候选步骤生成】：提出 3 条“下一步可能的推理/计算步骤”，用 S1/S2/S3 编号。
• 【步骤审核】：逐条判断 Accept/Reject，并给一句理由（只允许基于已确认步骤和基础数学规则）。
• 【累积步骤】：只列出被 Accept 的步骤，作为“已确认步骤”。
• 【完成检查】：如果已能得到最终解，输出最终答案；否则进入下一轮。
• 最多 3 轮，避免无限循环。
  题目：解方程 ((x-2)(x+3)=0)。

为什么有效：会先提出“零积定理”等候选步骤，再由评审确认，降低直接计算时的粗心错误。

---

例子 2：逻辑/规则推断（制度适用）——避免漏条件

任务：公司报销规则推断

• 规则：
  1. 单笔 ≤ 500 元：部门经理审批即可
  2. 500 < 单笔 ≤ 2000：部门经理 + 财务审批
  3. 单笔 > 2000：部门经理 + 财务 + 总经理
  4. 若为“招待费”，无论金额多少都需额外“合规”审批
• 问：小王报销 1800 元招待费，需要哪些审批？

Prompt（可复制）：

请用“累积式推理”回答。
你每轮先生成 4 个可能的“下一步判断”（例如：先判断金额区间、再判断费用类型、再合并审批要求等），然后自我审核 Accept/Reject。
审核标准：

• 不允许跳过规则条件；
• 不允许遗漏规则 4 的特殊条款；
• 结论必须能由已接受步骤推出。
  当能得出完整审批链时停止。
  输入：报销金额 1800 元，费用类型=招待费。规则如上。输出最终需要的审批角色列表。

为什么有效：这类题最常见错误是“按金额走完就忘了特殊条款”，累积式审核能专门把“是否遗漏例外规则”当作验收点。

---

例子 3：程序 Debug（逐步提出修复思路并筛选）——把拍脑袋改代码变成可审计流程

任务：找出 Python 代码错误并修复

def avg(nums):
    s = 0
    for i in range(len(nums)):
        s += i
    return s / len(nums)
print(avg([1,2,3]))

预期输出应该是 2.0

Prompt（可复制）：

你是代码审查员，请用“累积式推理”修复 bug。
每轮：

1. 生成 3 个“可能的下一步定位/修复步骤”（候选可以包括：指出可疑行、构造反例、解释变量含义、提出修改方案）。
2. 对每个候选步骤进行 Accept/Reject，并说明理由（要基于代码语义与预期输出）。
3. 累积所有 Accept 的步骤，直到可以给出最终修复后的代码与解释。
   约束：最终给出一段可运行的修复代码，并用一句话说明 bug 根因。最多 3 轮。

为什么有效：模型往往会“直接给答案”，但容易漏掉根因说明或修复不彻底；候选 + 审核让它先定位“s += i”是否应为“s += nums[i]”，再确认边界。

---

###（可选增强）工程实践建议：把“评审”外置成第二次调用或第二个角色 在生产环境中，你可以：

• 第一次调用：只生成候选步骤（更发散）
• 第二次调用：只做评审（更收敛、严格按规则）
  这种分离常比“同一轮自评”更稳定。

---

如果你愿意，我可以再补一套更工程化的模板：包含“评分量表（0-2 分）”“拒绝时的修正建议”“迭代停止条件（置信度/一致性/外部校验通过）”，并给你一个适合你业务场景的版本。你更关心数学题、逻辑规则，还是代码/数据分析？