loopforge 1.12.0 → 1.15.1

package/skills/prompt-techniques/references/chain-of-thought.md

@@ -1,207 +1,207 @@
-# Chain-of-Thought (CoT) Prompting
-
-Covers both Zero-Shot-CoT and Few-Shot-CoT.
-
----
-
-## Zero-Shot-CoT
-
-### Purpose
-
-适合需要分析、判断或多步推理，但用户未提供推理示例的任务。在 Prompt 中要求模型"一步一步思考 (Let's think step by step)"，让模型自行展开推理过程。核心技巧是在 Instruction 末尾加入：**"Let's work this out in a step by step way to be sure we have the right answer."**
-
-### Input Requirements
-
-- **用户任务**：说明希望模型完成什么任务。
-- **输出格式**：说明最终答案的结构，通常为"先推理过程，再最终答案"。
-- **可选信息**：角色设定、约束条件、是否隐藏详细推理。
-
-零样本思维链不插入任务级推理示例；如果用户能提供推理示例，应改用少样本思维链。
-
-### Recommended JSON Input
-
-```json
-{
-  "task": "解决这道多步骤数学题",
-  "role": "你是一名严谨的数学推理助手",
-  "target_input": "{用户输入的数学题}",
-  "output_format": "先输出简明推理过程，再输出最终答案。",
-  "constraints": ["检查算术", "最终答案单独成行"]
-}
-```
-
-### Method Steps
-
-1. 在 Prompt 中加入触发语句（如 "请逐步推理"、"Let's think step by step"）。
-2. 要求模型先给出推理过程，再给出最终答案。
-3. 推理过程应简洁、可验证，避免冗长发散。
-4. 区分推理和答案的输出位置，确保最终答案清晰可识别。
-
-### Design Rules
-
-- 保持角色、任务指令、上下文和输出格式明确。
-- 可以提供"示例输出格式"或格式骨架，用于约束结构，但不要把它写成 few-shot-cot。
-- 输出格式应可验证，如字段名、顺序、句数、列表数量、Markdown 样式或 JSON 结构。
-- 使用 `###`、三引号 `"""` 或代码块清晰分隔指令和待处理内容。
-- `{用户输入的文本}` 或 `{text input here}` 必须替换为实际用户文本，或作为待用户后续填入的占位符保留。
-
-### When to Use
-
-- 用户未提供完整推理示例。
-- 任务需要推理但难度中等（不需要多分支探索）。
-- 推理步骤是可预期的线性过程。
-
-### Prompt Output Template (Zero-Shot-CoT)
-
-当你用 Zero-Shot-CoT 生成提示词时，按以下 7 节骨架输出。第 5 节为推理骨架（非示例）。
-
-| # | 章节 | 必需 | 说明 |
-|---|------|------|------|
-| 1 | 角色 | ✓ | 推理型专家角色 |
-| 2 | 任务 | ✓ | 一句话 |
-| 3 | 输入 | ✓ | 目标问题/数据 |
-| 4 | 输出格式 | ✓ | "先输出推理过程，再输出最终答案" |
-| 5 | **推理骨架（Zero-Shot-CoT）** | ✓ | 不是示例，而是格式提示：`请按以下步骤推理：步骤1: [做什么] → 步骤2: [做什么] → ... → 最终答案:` |
-| 6 | 具体实现要求 | ✓ | 按输出格式展开 |
-| 7 | 硬约束 | ✓ | 含触发语如"请逐步推理"、"Let's think step by step" |
-| 8 | 生成要求 | ✓ | 验收标准 |
-
-**质量自检：**
-- [ ] 不含任务级输入/输出示例（那是 Few-Shot-CoT 的事）
-- [ ] 推理骨架只给步骤名，不给具体推理内容
-- [ ] 明确区分推理过程和最终答案的输出位置
-
----
-
-## Few-Shot-CoT
-
-### Purpose
-
-适合用户提供完整推理示例（问题→推理→答案三元组）的任务。让模型模仿示例中的分步推理方式解决新问题。适用于前后功能依赖但任务极难的场景（接力推理）。
-
-Few-Shot-CoT 的关键不是只给 `输入 -> 输出`，而是给出 `问题/输入 -> 推理过程 -> 最终答案` 的示例三元组，让模型模仿示例中的分步推理方式，再解决新的目标问题。若用户没有提供完整推理案例，不追问，自动退回零样本思维链。
-
-### Input Requirements
-
-- **用户任务**：说明希望模型解决哪类问题，如数学应用题、常识推理、符号推理、日期计算、代码逻辑分析等。
-- **目标问题**：用户希望最终处理的真实问题，或 `{用户输入的问题}` 占位符。
-- **可选推理示例**：用户可以在第一次请求中直接提供 1~5 组与目标任务同类型的示例。
-- **少样本思维链案例推荐包含**：问题/输入、推理过程、最终答案。
-- **输出格式**：说明最终 Prompt 应要求模型输出哪些部分，如"推理过程 + 最终答案"、JSON、选项字母、代码块等。
-
-若用户已附上完整推理案例，直接吸收案例中的分步推理方式和答案格式；若未检测到完整推理案例，不要追问或中断流程，按零样本思维链生成。
-
-### Recommended JSON Input
-
-```json
-{
-  "task": "解决小学数学应用题",
-  "role": "你是一名严谨的数学解题助手",
-  "examples": [
-    {
-      "input": "小明有 5 支铅笔，又买了 2 盒，每盒 3 支。他现在有几支铅笔？",
-      "reasoning": "小明原来有 5 支铅笔。2 盒铅笔每盒 3 支，所以新增 2 × 3 = 6 支。总数是 5 + 6 = 11 支。",
-      "output": "11"
-    }
-  ],
-  "target_input": "{用户输入的数学应用题}",
-  "output_format": "先输出推理过程，再输出最终答案。",
-  "constraints": ["推理步骤要简洁", "最终答案单独成行"]
-}
-```
-
-### Case Rules
-
-1. `examples` 可省略；省略时按零样本思维链生成，并在示例区说明原因。
-2. 如果提供 `examples`，校验数量为 1~5，且每组都有非空 `input`、`reasoning` 和 `output`。
-3. 将完整示例格式化为 `示例 N / 问题 / 推理过程 / 最终答案`，插入生成的 Prompt。
-4. 推理示例不要只写"因为显然如此"，要写出关键中间步骤。
-
-### Paper Citations
-
-根据《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》的方法，少样本思维链通过在提示词中提供带有自然语言中间推理步骤的示例，帮助模型处理多步推理任务。核心启发：
-
-- 示例应是三元组：输入、思维链推理过程、最终输出。
-- 推理过程应位于最终答案之前，让模型先分解问题再回答。
-- 自然语言推理步骤比只给公式或只增加 token 更有效。
-- 该方法更适合需要多步推理的任务，如算术推理、常识推理、符号操作和状态追踪。
-- 简单单步任务不一定需要少样本思维链，可使用零样本提示或少样本提示。
-
-### Method Steps
-
-1. 将用户示例格式化为：示例N / 问题 / 推理过程 / 最终答案。
-2. 示例应展示完整的中间推理步骤，不只是"显然如此"。
-3. 在生成的 Prompt 末尾放置目标问题，要求模型模仿示例的推理结构。
-4. 如果示例中推理不完整，退回 zero-shot-cot。
-
-### When to Use
-
-- 用户提供了 1-5 组高质量推理示例。
-- 前后任务高度依赖，需要推理接力。
-- 常见场景：连续的安全审计阶段、多步逻辑模块开发。
-
-### Prompt Output Template (Few-Shot-CoT)
-
-当你用 Few-Shot-CoT 生成提示词时，按以下 8 节骨架输出。第 5 节为推理模式参考。
-
-| # | 章节 | 必需 | 说明 |
-|---|------|------|------|
-| 1 | 角色 | ✓ | 推理型专家 |
-| 2 | 任务 | ✓ | 一句话 |
-| 3 | 输入 | ✓ | 目标问题/模块 |
-| 4 | 输出格式 | ✓ | "1. DDL, 2. API, 3. 业务代码..." |
-| 5 | **推理模式参考（Few-Shot Examples）** | ✓ | 见下方格式规范 |
-| 6 | 具体实现要求 | ✓ | 每个 API 端点附推理链 |
-| 7 | 硬约束 | ✓ | 编号列表 |
-| 8 | 生成要求 | ✓ | 验收标准 |
-
-**第 5 节格式规范：** 必须包含两部分：
-
-**A. 2 组输入→推理→输出三元组**，每组格式：
-
-```
-### 示例 N：[场景]
-
-| 维度 | 内容 |
-|------|------|
-| 输入 | [具体输入] |
-| 输出 | [期望输出] |
-| 推理 | [一句话概括推理方向] |
-
-**推理模式拆解：**
-步骤1: [做什么]
-步骤2: [做什么]
-...
-```
-
-**B. 推理模式迁移规则框**：一个 ASCII 框图，从示例中提取通用推理模式并分层描述（如：参数校验层→业务校验层→业务处理层→数据持久化层→响应组装层）。
-
-格式范本（来自 MCP 黄金标准 `prompt_01_user_system`）：
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│              通用推理模式                                     │
-├─────────────────────────────────────────────────────────────┤
-│  1. 参数校验层 — 检查必填参数、格式、业务约束                  │
-│  2. 业务校验层 — 检查冲突、合法性、权限                       │
-│  3. 业务处理层 — 执行核心逻辑                                 │
-│  4. 数据持久化层 — 写入 DB/缓存，处理事务                     │
-│  5. 响应组装层 — 统一格式，敏感字段脱敏                       │
-└─────────────────────────────────────────────────────────────┘
-```
-
-**质量自检：**
-- [ ] 推理过程写出关键中间步骤，不是"因为显然如此"
-- [ ] 迁移规则框是分层框架，不是单个步骤的复述
-- [ ] 三元组的推理模式与目标任务同类型
-
----
-
-## Common Design Rules (Both CoT Variants)
-
-- 推理过程应优先 2-3 个示例。
-- 对选择题，最终答案应明确选项字母和选项内容。
-- 对数学、日期、状态追踪等任务，推理中要保留关键计算或状态变化。
-- 使用链式推理（CoT）时，要求模型公开简洁可验证的理由，而不是隐藏思维链。
-- 如果用户不希望暴露完整推理，可在生成的 Prompt 中要求输出"简要依据 + 最终答案"，但示例仍应体现推理结构。
-- 输出格式要区分推理过程和最终答案，避免模型把答案埋在推理中。
+# Chain-of-Thought (CoT) Prompting
+
+Covers both Zero-Shot-CoT and Few-Shot-CoT.
+
+---
+
+## Zero-Shot-CoT
+
+### Purpose
+
+适合需要分析、判断或多步推理，但用户未提供推理示例的任务。在 Prompt 中要求模型"一步一步思考 (Let's think step by step)"，让模型自行展开推理过程。核心技巧是在 Instruction 末尾加入：**"Let's work this out in a step by step way to be sure we have the right answer."**
+
+### Input Requirements
+
+- **用户任务**：说明希望模型完成什么任务。
+- **输出格式**：说明最终答案的结构，通常为"先推理过程，再最终答案"。
+- **可选信息**：角色设定、约束条件、是否隐藏详细推理。
+
+零样本思维链不插入任务级推理示例；如果用户能提供推理示例，应改用少样本思维链。
+
+### Recommended JSON Input
+
+```json
+{
+  "task": "解决这道多步骤数学题",
+  "role": "你是一名严谨的数学推理助手",
+  "target_input": "{用户输入的数学题}",
+  "output_format": "先输出简明推理过程，再输出最终答案。",
+  "constraints": ["检查算术", "最终答案单独成行"]
+}
+```
+
+### Method Steps
+
+1. 在 Prompt 中加入触发语句（如 "请逐步推理"、"Let's think step by step"）。
+2. 要求模型先给出推理过程，再给出最终答案。
+3. 推理过程应简洁、可验证，避免冗长发散。
+4. 区分推理和答案的输出位置，确保最终答案清晰可识别。
+
+### Design Rules
+
+- 保持角色、任务指令、上下文和输出格式明确。
+- 可以提供"示例输出格式"或格式骨架，用于约束结构，但不要把它写成 few-shot-cot。
+- 输出格式应可验证，如字段名、顺序、句数、列表数量、Markdown 样式或 JSON 结构。
+- 使用 `###`、三引号 `"""` 或代码块清晰分隔指令和待处理内容。
+- `{用户输入的文本}` 或 `{text input here}` 必须替换为实际用户文本，或作为待用户后续填入的占位符保留。
+
+### When to Use
+
+- 用户未提供完整推理示例。
+- 任务需要推理但难度中等（不需要多分支探索）。
+- 推理步骤是可预期的线性过程。
+
+### Prompt Output Template (Zero-Shot-CoT)
+
+当你用 Zero-Shot-CoT 生成提示词时，按以下 7 节骨架输出。第 5 节为推理骨架（非示例）。
+
+| # | 章节 | 必需 | 说明 |
+|---|------|------|------|
+| 1 | 角色 | ✓ | 推理型专家角色 |
+| 2 | 任务 | ✓ | 一句话 |
+| 3 | 输入 | ✓ | 目标问题/数据 |
+| 4 | 输出格式 | ✓ | "先输出推理过程，再输出最终答案" |
+| 5 | **推理骨架（Zero-Shot-CoT）** | ✓ | 不是示例，而是格式提示：`请按以下步骤推理：步骤1: [做什么] → 步骤2: [做什么] → ... → 最终答案:` |
+| 6 | 具体实现要求 | ✓ | 按输出格式展开 |
+| 7 | 硬约束 | ✓ | 含触发语如"请逐步推理"、"Let's think step by step" |
+| 8 | 生成要求 | ✓ | 验收标准 |
+
+**质量自检：**
+- [ ] 不含任务级输入/输出示例（那是 Few-Shot-CoT 的事）
+- [ ] 推理骨架只给步骤名，不给具体推理内容
+- [ ] 明确区分推理过程和最终答案的输出位置
+
+---
+
+## Few-Shot-CoT
+
+### Purpose
+
+适合用户提供完整推理示例（问题→推理→答案三元组）的任务。让模型模仿示例中的分步推理方式解决新问题。适用于前后功能依赖但任务极难的场景（接力推理）。
+
+Few-Shot-CoT 的关键不是只给 `输入 -> 输出`，而是给出 `问题/输入 -> 推理过程 -> 最终答案` 的示例三元组，让模型模仿示例中的分步推理方式，再解决新的目标问题。若用户没有提供完整推理案例，不追问，自动退回零样本思维链。
+
+### Input Requirements
+
+- **用户任务**：说明希望模型解决哪类问题，如数学应用题、常识推理、符号推理、日期计算、代码逻辑分析等。
+- **目标问题**：用户希望最终处理的真实问题，或 `{用户输入的问题}` 占位符。
+- **可选推理示例**：用户可以在第一次请求中直接提供 1~5 组与目标任务同类型的示例。
+- **少样本思维链案例推荐包含**：问题/输入、推理过程、最终答案。
+- **输出格式**：说明最终 Prompt 应要求模型输出哪些部分，如"推理过程 + 最终答案"、JSON、选项字母、代码块等。
+
+若用户已附上完整推理案例，直接吸收案例中的分步推理方式和答案格式；若未检测到完整推理案例，不要追问或中断流程，按零样本思维链生成。
+
+### Recommended JSON Input
+
+```json
+{
+  "task": "解决小学数学应用题",
+  "role": "你是一名严谨的数学解题助手",
+  "examples": [
+    {
+      "input": "小明有 5 支铅笔，又买了 2 盒，每盒 3 支。他现在有几支铅笔？",
+      "reasoning": "小明原来有 5 支铅笔。2 盒铅笔每盒 3 支，所以新增 2 × 3 = 6 支。总数是 5 + 6 = 11 支。",
+      "output": "11"
+    }
+  ],
+  "target_input": "{用户输入的数学应用题}",
+  "output_format": "先输出推理过程，再输出最终答案。",
+  "constraints": ["推理步骤要简洁", "最终答案单独成行"]
+}
+```
+
+### Case Rules
+
+1. `examples` 可省略；省略时按零样本思维链生成，并在示例区说明原因。
+2. 如果提供 `examples`，校验数量为 1~5，且每组都有非空 `input`、`reasoning` 和 `output`。
+3. 将完整示例格式化为 `示例 N / 问题 / 推理过程 / 最终答案`，插入生成的 Prompt。
+4. 推理示例不要只写"因为显然如此"，要写出关键中间步骤。
+
+### Paper Citations
+
+根据《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》的方法，少样本思维链通过在提示词中提供带有自然语言中间推理步骤的示例，帮助模型处理多步推理任务。核心启发：
+
+- 示例应是三元组：输入、思维链推理过程、最终输出。
+- 推理过程应位于最终答案之前，让模型先分解问题再回答。
+- 自然语言推理步骤比只给公式或只增加 token 更有效。
+- 该方法更适合需要多步推理的任务，如算术推理、常识推理、符号操作和状态追踪。
+- 简单单步任务不一定需要少样本思维链，可使用零样本提示或少样本提示。
+
+### Method Steps
+
+1. 将用户示例格式化为：示例N / 问题 / 推理过程 / 最终答案。
+2. 示例应展示完整的中间推理步骤，不只是"显然如此"。
+3. 在生成的 Prompt 末尾放置目标问题，要求模型模仿示例的推理结构。
+4. 如果示例中推理不完整，退回 zero-shot-cot。
+
+### When to Use
+
+- 用户提供了 1-5 组高质量推理示例。
+- 前后任务高度依赖，需要推理接力。
+- 常见场景：连续的安全审计阶段、多步逻辑模块开发。
+
+### Prompt Output Template (Few-Shot-CoT)
+
+当你用 Few-Shot-CoT 生成提示词时，按以下 8 节骨架输出。第 5 节为推理模式参考。
+
+| # | 章节 | 必需 | 说明 |
+|---|------|------|------|
+| 1 | 角色 | ✓ | 推理型专家 |
+| 2 | 任务 | ✓ | 一句话 |
+| 3 | 输入 | ✓ | 目标问题/模块 |
+| 4 | 输出格式 | ✓ | "1. DDL, 2. API, 3. 业务代码..." |
+| 5 | **推理模式参考（Few-Shot Examples）** | ✓ | 见下方格式规范 |
+| 6 | 具体实现要求 | ✓ | 每个 API 端点附推理链 |
+| 7 | 硬约束 | ✓ | 编号列表 |
+| 8 | 生成要求 | ✓ | 验收标准 |
+
+**第 5 节格式规范：** 必须包含两部分：
+
+**A. 2 组输入→推理→输出三元组**，每组格式：
+
+```
+### 示例 N：[场景]
+
+| 维度 | 内容 |
+|------|------|
+| 输入 | [具体输入] |
+| 输出 | [期望输出] |
+| 推理 | [一句话概括推理方向] |
+
+**推理模式拆解：**
+步骤1: [做什么]
+步骤2: [做什么]
+...
+```
+
+**B. 推理模式迁移规则框**：一个 ASCII 框图，从示例中提取通用推理模式并分层描述（如：参数校验层→业务校验层→业务处理层→数据持久化层→响应组装层）。
+
+格式范本（来自 MCP 黄金标准 `prompt_01_user_system`）：
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│              通用推理模式                                     │
+├─────────────────────────────────────────────────────────────┤
+│  1. 参数校验层 — 检查必填参数、格式、业务约束                  │
+│  2. 业务校验层 — 检查冲突、合法性、权限                       │
+│  3. 业务处理层 — 执行核心逻辑                                 │
+│  4. 数据持久化层 — 写入 DB/缓存，处理事务                     │
+│  5. 响应组装层 — 统一格式，敏感字段脱敏                       │
+└─────────────────────────────────────────────────────────────┘
+```
+
+**质量自检：**
+- [ ] 推理过程写出关键中间步骤，不是"因为显然如此"
+- [ ] 迁移规则框是分层框架，不是单个步骤的复述
+- [ ] 三元组的推理模式与目标任务同类型
+
+---
+
+## Common Design Rules (Both CoT Variants)
+
+- 推理过程应优先 2-3 个示例。
+- 对选择题，最终答案应明确选项字母和选项内容。
+- 对数学、日期、状态追踪等任务，推理中要保留关键计算或状态变化。
+- 使用链式推理（CoT）时，要求模型公开简洁可验证的理由，而不是隐藏思维链。
+- 如果用户不希望暴露完整推理，可在生成的 Prompt 中要求输出"简要依据 + 最终答案"，但示例仍应体现推理结构。
+- 输出格式要区分推理过程和最终答案，避免模型把答案埋在推理中。