loopforge 1.12.0 → 1.15.1

package/skills/prompt-techniques/references/least-to-most.md

@@ -1,182 +1,182 @@
-# Least-to-Most Prompting
-
-## Purpose
-
-适合需要拆成有序子问题、逐步求解并综合的任务。Least-to-Most 的核心不是简单地"逐步思考"，而是把复杂问题拆成从少到多、从简单到复杂、彼此有依赖顺序的子问题，再按顺序解答。后一个子问题应能利用前面已经得到的答案，最终回到原始问题。
-
-## Input Requirements
-
-- **用户任务**：说明希望模型完成什么任务。
-- **输出格式**：说明最终答案的结构、字段、长度、语言、代码格式或是否只输出最终答案。
-- **待处理内容**：需要分析、计算、改写、规划或回答的文本；如果用户暂未提供，保留占位符。
-- **可选信息**：角色设定、约束条件、是否展示拆解过程、是否使用两阶段执行。
-
-不要求用户提供示例。如果用户提供了示例，可以只把它作为任务偏好参考，不要把 skill 改写成 few-shot prompt，除非用户明确要求少样本版本。
-
-## Recommended JSON Input
-
-```json
-{
-  "task": "解决这道多步骤数学题",
-  "role": "你是一名严谨的数学推理助手",
-  "target_input": "{用户输入的题目}",
-  "output_format": "先列出问题拆解，再列出每个子问题答案，最后用一行写最终答案。",
-  "constraints": ["检查单位和算术", "不要添加无关解释"],
-  "trace_visibility": "展示问题拆解和子问题答案"
-}
-```
-
-`mode` 为 `single-pass` 时生成完整 Least-to-Most Prompt；`decomposition` 只生成问题拆解 Prompt；`solution` 生成逐个回答子问题的 Prompt。
-
-## Method Steps
-
-1. 把用户任务拆成 2-5 个有顺序的子问题（子问题 B 的输入依赖子问题 A 的输出）。
-2. 在 Prompt 中先列出子问题顺序和依赖关系。
-3. 要求模型先解决最简单、最基础的子问题（Least），再逐步推进到最复杂的子问题（Most）。
-4. 后续子问题的 Prompt 应引用前面子问题的结论。
-5. 最后一步综合所有子问题的结果，形成完整方案。
-
-## Problem Decomposition Template
-
-在 Prompt 中明确两个阶段：
-
-### Phase 1: Problem Reducing
-
-自上而下拆解原问题，只列出必要、有序、可回答的子问题。子问题必须：
-- 服务于原始问题，不要拆出无关步骤。
-- 顺序体现依赖关系：先事实识别、局部计算、局部判断，再组合结论，最后回答原问题。
-- 最后一个子问题应等价于或直接导向原始问题。
-
-### Phase 2: Sequentially Solve Subquestions
-
-自下而上逐一解答，把前一子问题答案作为后续上下文。
-
-## Design Rules
-
-- 子问题必须服务于原始问题，不要拆出无关步骤。
-- 子问题顺序应体现依赖关系：先事实识别、局部计算、局部判断，再组合结论，最后回答原问题。
-- 最后一个子问题应等价于或直接导向原始问题。
-- 拆解阶段不要提前求解；求解阶段不要重新随意改写拆解，除非发现子问题缺失或矛盾。
-- 每个子问题的答案都应成为后续子问题的可用上下文。
-- 对数学、代码、法律、医学、金融等高风险或可验证任务，要求列出必要假设、检查单位/边界条件，并在最终答案前做一致性检查。
-- 避免要求模型暴露隐藏思维链；需要可解释性时，让模型输出简明、可公开的“子问题答案”和“依据摘要”。
-
-## Single-Pass vs Two-Stage Execution
-
-### Single-Pass（默认）
-
-一个 Prompt 同时要求模型先拆解、再依次解答、最后给出答案。适合普通聊天和用户只想拿到一个可复用提示词的场景。
-
-### Two-Stage
-
-当外部流程可以多次调用模型时使用：
-
-1. **Decomposition**：先用问题拆解 Prompt 得到有序子问题列表。
-2. **Append**：把原始问题追加为最后一个子问题。
-3. **Sequential Solve**：对每个子问题调用子问题解答 Prompt，把已经回答过的子问题和答案作为上下文传入。
-4. **Final Answer**：最后一个子问题的答案就是最终答案，再按用户要求的输出格式整理。
-
-## When to Use
-
-- 任务天然包含多个有依赖顺序的步骤。
-- 整体任务太复杂，一次性让模型完成容易出错。
-- 任务可以清晰地分解为"从简单到复杂"的递进链。
-- 常见场景：大型功能模块开发、数据管道构建、多步骤部署流程。
-
-## Example Use Cases
-
-- "帮我实现一个包含注册、登录、权限验证的用户系统"
-- "搭建一个从数据采集到可视化的完整 pipeline"
-- "实现一个编译器：词法分析 → 语法分析 → 代码生成"
-
-## Prompt Output Template
-
-当你用 Least-to-Most 技术生成提示词时，按以下 8 节骨架输出。
-
-### 章节骨架
-
-| # | 章节 | 必需 | 说明 |
-|---|------|------|------|
-| 1 | 角色 | ✓ | 领域专家 |
-| 2 | 任务 | ✓ | 一句话 |
-| 3 | 输入 | ✓ | 目标模块 |
-| 4 | 输出格式 | ✓ | 编号列表，如"1. DDL, 2. API, 3. 枚举定义, 4. 算法, 5. 业务代码..." |
-| 5 | **Least-to-Most 逐步推理框架** | ✓ | 见下方格式规范 |
-| 6 | 具体实现要求 | ✓ | 按要求列表逐节展开（不是逐子问题展开，子问题在第5节已充分展开） |
-| 7 | 硬约束 | ✓ | 编号列表 |
-| 8 | 生成要求 | ✓ | 验收标准，含"严格按照子问题顺序逐步实现" |
-
-### 第 5 节格式规范：Least-to-Most 逐步推理框架
-
-必须包含 **4-6 个有序子问题**。每个子问题格式：
-
-```
-### 子问题 N：[子问题名称]
-
-**目标：** [这个子问题要解决什么，基于前面哪个子问题的结论]
-
-**要求：**
-- 具体要求的列表
-- [如果子问题涉及枚举/映射表，写出]
-
-**示例：** [子问题的输入→输出示例，可选]
-
-**映射规则：** [一句话，可选]
-
----
-```
-
-**关键规则：**
-- 第一个子问题是最基础的（如"定义枚举和基础数据"）
-- 每个子问题开头声明"基于子问题 N-1 的结论"
-- 最后一个子问题必须是 **"综合实现完整模块"**，列出需要整合的所有组件
-- 子问题之间以 `---` 分隔
-
-格式范本（来自 MCP 黄金标准 `prompt_07_medication`）：
-
-```
-### 子问题 1：定义枚举和药物库基础数据
-
-**目标：** 定义用药模块所需的所有枚举类型和药物库表结构，这是后续所有功能的基础。
-
-**要求：**
-- 定义 DosageUnit 枚举（5 种剂量单位）
-- 定义 UsageMethod 枚举（4 种服用方式）
-- ...
-
----
-### 子问题 2：实现药物名称联想搜索
-
-**目标：** 基于子问题 1 的药物库表，实现药物名称联想搜索接口。
-
-**要求：**
-- 支持前缀模糊匹配
-- ...
-
----
-### 子问题 N：综合实现完整模块
-
-**目标：** 将子问题 1-(N-1) 的所有组件整合为完整的模块。
-
-**需要整合的组件：**
-1. 数据库表结构
-2. 枚举定义
-3. ...
-```
-
-### 质量自检
-
-- [ ] 子问题顺序从最简单到最复杂，体现依赖链
-- [ ] 每个子问题明确声明依赖的前置子问题
-- [ ] 最后一个子问题是"综合实现完整模块"
-- [ ] 第 6 节按要求列表展开（不是逐子问题展开——子问题在第5节已完整展开）
-- [ ] 子问题数量 4-6 个，不多不少
-
-## Notes
-
-- 子问题的顺序至关重要——确保每个子问题只依赖前面已解决的问题。
-- Least-to-Most 适合“原题难，但能由更小子问题组合得到答案”的任务；不适合主观闲聊、单句改写、简单分类等无需拆解的任务。
-- 与零样本思维链相比，它多了显式问题拆解和上下文递进；与少样本提示相比，它不要求用户给出输入/输出案例。
-- 与 tree-of-thought 的区别：least-to-most 是确定性的有序分解（已知最佳顺序），ToT 是探索性的多分支并行（不确定最优路径）。
-- 如果子问题之间没有依赖关系，可以用多个独立的 few-shot 或 zero-shot 任务处理。
-- 如果输出格式要求“只输出 JSON/代码/最终结论”，生成的 Prompt 应要求模型内部完成拆解，最终只交付指定格式。
+# Least-to-Most Prompting
+
+## Purpose
+
+适合需要拆成有序子问题、逐步求解并综合的任务。Least-to-Most 的核心不是简单地"逐步思考"，而是把复杂问题拆成从少到多、从简单到复杂、彼此有依赖顺序的子问题，再按顺序解答。后一个子问题应能利用前面已经得到的答案，最终回到原始问题。
+
+## Input Requirements
+
+- **用户任务**：说明希望模型完成什么任务。
+- **输出格式**：说明最终答案的结构、字段、长度、语言、代码格式或是否只输出最终答案。
+- **待处理内容**：需要分析、计算、改写、规划或回答的文本；如果用户暂未提供，保留占位符。
+- **可选信息**：角色设定、约束条件、是否展示拆解过程、是否使用两阶段执行。
+
+不要求用户提供示例。如果用户提供了示例，可以只把它作为任务偏好参考，不要把 skill 改写成 few-shot prompt，除非用户明确要求少样本版本。
+
+## Recommended JSON Input
+
+```json
+{
+  "task": "解决这道多步骤数学题",
+  "role": "你是一名严谨的数学推理助手",
+  "target_input": "{用户输入的题目}",
+  "output_format": "先列出问题拆解，再列出每个子问题答案，最后用一行写最终答案。",
+  "constraints": ["检查单位和算术", "不要添加无关解释"],
+  "trace_visibility": "展示问题拆解和子问题答案"
+}
+```
+
+`mode` 为 `single-pass` 时生成完整 Least-to-Most Prompt；`decomposition` 只生成问题拆解 Prompt；`solution` 生成逐个回答子问题的 Prompt。
+
+## Method Steps
+
+1. 把用户任务拆成 2-5 个有顺序的子问题（子问题 B 的输入依赖子问题 A 的输出）。
+2. 在 Prompt 中先列出子问题顺序和依赖关系。
+3. 要求模型先解决最简单、最基础的子问题（Least），再逐步推进到最复杂的子问题（Most）。
+4. 后续子问题的 Prompt 应引用前面子问题的结论。
+5. 最后一步综合所有子问题的结果，形成完整方案。
+
+## Problem Decomposition Template
+
+在 Prompt 中明确两个阶段：
+
+### Phase 1: Problem Reducing
+
+自上而下拆解原问题，只列出必要、有序、可回答的子问题。子问题必须：
+- 服务于原始问题，不要拆出无关步骤。
+- 顺序体现依赖关系：先事实识别、局部计算、局部判断，再组合结论，最后回答原问题。
+- 最后一个子问题应等价于或直接导向原始问题。
+
+### Phase 2: Sequentially Solve Subquestions
+
+自下而上逐一解答，把前一子问题答案作为后续上下文。
+
+## Design Rules
+
+- 子问题必须服务于原始问题，不要拆出无关步骤。
+- 子问题顺序应体现依赖关系：先事实识别、局部计算、局部判断，再组合结论，最后回答原问题。
+- 最后一个子问题应等价于或直接导向原始问题。
+- 拆解阶段不要提前求解；求解阶段不要重新随意改写拆解，除非发现子问题缺失或矛盾。
+- 每个子问题的答案都应成为后续子问题的可用上下文。
+- 对数学、代码、法律、医学、金融等高风险或可验证任务，要求列出必要假设、检查单位/边界条件，并在最终答案前做一致性检查。
+- 避免要求模型暴露隐藏思维链；需要可解释性时，让模型输出简明、可公开的“子问题答案”和“依据摘要”。
+
+## Single-Pass vs Two-Stage Execution
+
+### Single-Pass（默认）
+
+一个 Prompt 同时要求模型先拆解、再依次解答、最后给出答案。适合普通聊天和用户只想拿到一个可复用提示词的场景。
+
+### Two-Stage
+
+当外部流程可以多次调用模型时使用：
+
+1. **Decomposition**：先用问题拆解 Prompt 得到有序子问题列表。
+2. **Append**：把原始问题追加为最后一个子问题。
+3. **Sequential Solve**：对每个子问题调用子问题解答 Prompt，把已经回答过的子问题和答案作为上下文传入。
+4. **Final Answer**：最后一个子问题的答案就是最终答案，再按用户要求的输出格式整理。
+
+## When to Use
+
+- 任务天然包含多个有依赖顺序的步骤。
+- 整体任务太复杂，一次性让模型完成容易出错。
+- 任务可以清晰地分解为"从简单到复杂"的递进链。
+- 常见场景：大型功能模块开发、数据管道构建、多步骤部署流程。
+
+## Example Use Cases
+
+- "帮我实现一个包含注册、登录、权限验证的用户系统"
+- "搭建一个从数据采集到可视化的完整 pipeline"
+- "实现一个编译器：词法分析 → 语法分析 → 代码生成"
+
+## Prompt Output Template
+
+当你用 Least-to-Most 技术生成提示词时，按以下 8 节骨架输出。
+
+### 章节骨架
+
+| # | 章节 | 必需 | 说明 |
+|---|------|------|------|
+| 1 | 角色 | ✓ | 领域专家 |
+| 2 | 任务 | ✓ | 一句话 |
+| 3 | 输入 | ✓ | 目标模块 |
+| 4 | 输出格式 | ✓ | 编号列表，如"1. DDL, 2. API, 3. 枚举定义, 4. 算法, 5. 业务代码..." |
+| 5 | **Least-to-Most 逐步推理框架** | ✓ | 见下方格式规范 |
+| 6 | 具体实现要求 | ✓ | 按要求列表逐节展开（不是逐子问题展开，子问题在第5节已充分展开） |
+| 7 | 硬约束 | ✓ | 编号列表 |
+| 8 | 生成要求 | ✓ | 验收标准，含"严格按照子问题顺序逐步实现" |
+
+### 第 5 节格式规范：Least-to-Most 逐步推理框架
+
+必须包含 **4-6 个有序子问题**。每个子问题格式：
+
+```
+### 子问题 N：[子问题名称]
+
+**目标：** [这个子问题要解决什么，基于前面哪个子问题的结论]
+
+**要求：**
+- 具体要求的列表
+- [如果子问题涉及枚举/映射表，写出]
+
+**示例：** [子问题的输入→输出示例，可选]
+
+**映射规则：** [一句话，可选]
+
+---
+```
+
+**关键规则：**
+- 第一个子问题是最基础的（如"定义枚举和基础数据"）
+- 每个子问题开头声明"基于子问题 N-1 的结论"
+- 最后一个子问题必须是 **"综合实现完整模块"**，列出需要整合的所有组件
+- 子问题之间以 `---` 分隔
+
+格式范本（来自 MCP 黄金标准 `prompt_07_medication`）：
+
+```
+### 子问题 1：定义枚举和药物库基础数据
+
+**目标：** 定义用药模块所需的所有枚举类型和药物库表结构，这是后续所有功能的基础。
+
+**要求：**
+- 定义 DosageUnit 枚举（5 种剂量单位）
+- 定义 UsageMethod 枚举（4 种服用方式）
+- ...
+
+---
+### 子问题 2：实现药物名称联想搜索
+
+**目标：** 基于子问题 1 的药物库表，实现药物名称联想搜索接口。
+
+**要求：**
+- 支持前缀模糊匹配
+- ...
+
+---
+### 子问题 N：综合实现完整模块
+
+**目标：** 将子问题 1-(N-1) 的所有组件整合为完整的模块。
+
+**需要整合的组件：**
+1. 数据库表结构
+2. 枚举定义
+3. ...
+```
+
+### 质量自检
+
+- [ ] 子问题顺序从最简单到最复杂，体现依赖链
+- [ ] 每个子问题明确声明依赖的前置子问题
+- [ ] 最后一个子问题是"综合实现完整模块"
+- [ ] 第 6 节按要求列表展开（不是逐子问题展开——子问题在第5节已完整展开）
+- [ ] 子问题数量 4-6 个，不多不少
+
+## Notes
+
+- 子问题的顺序至关重要——确保每个子问题只依赖前面已解决的问题。
+- Least-to-Most 适合“原题难，但能由更小子问题组合得到答案”的任务；不适合主观闲聊、单句改写、简单分类等无需拆解的任务。
+- 与零样本思维链相比，它多了显式问题拆解和上下文递进；与少样本提示相比，它不要求用户给出输入/输出案例。
+- 与 tree-of-thought 的区别：least-to-most 是确定性的有序分解（已知最佳顺序），ToT 是探索性的多分支并行（不确定最优路径）。
+- 如果子问题之间没有依赖关系，可以用多个独立的 few-shot 或 zero-shot 任务处理。
+- 如果输出格式要求“只输出 JSON/代码/最终结论”，生成的 Prompt 应要求模型内部完成拆解，最终只交付指定格式。