loopforge 1.12.0 → 1.15.1

package/skills/prompt-techniques/references/step-back.md

@@ -1,160 +1,160 @@
-# Step-Back Prompting
-
-## Purpose
-
-适合需要先抽象原则、框架或根因，再回到具体任务的场景。Step-Back 的核心是：遇到复杂、多细节、容易被局部信息带偏的问题时，先后退一步，把原问题抽象成更高层的概念、原则、通用问题或事实范围；再把这个抽象层得到的原则或事实作为依据，回到原问题完成推理。
-
-## Input Requirements
-
-- **用户任务**：说明希望模型完成什么任务。
-- **待处理内容**：需要回答、分析、计算、判断或生成的具体问题；如果暂未提供，保留占位符。
-- **输出格式**：说明最终答案的结构、字段、长度、语言、代码格式或是否只输出最终答案。
-- **可选案例**：用户可以在第一次请求中直接提供 0~5 组 `原始问题 -> 后退问题 -> 抽象答案/原则 -> 最终答案`，用于展示如何后退抽象。
-- **可选信息**：角色设定、约束条件、是否展示后退过程、是否使用检索增强上下文。
-
-示例不是必需项。若用户已经附上案例，直接吸收案例中的后退抽象方式和输出风格；若未检测到案例，不要追问或中断流程，按零样本后退提示生成。
-
-## Recommended JSON Input
-
-```json
-{
-  "task": "回答这道复杂问题",
-  "role": "你是一名擅长抽象原则和稳健推理的助手",
-  "target_input": "{用户输入的问题}",
-  "output_format": "先输出后退问题和抽象依据，再输出最终答案。",
-  "constraints": ["最终答案必须回到原始问题", "不要添加无关解释"],
-  "trace_visibility": "展示后退问题、抽象依据和简明推理摘要",
-  "examples": [
-    {
-      "original": "具体问题",
-      "stepback_question": "更高层、更通用的问题",
-      "abstraction": "相关原则、概念、背景事实或通用框架",
-      "answer": "如何基于抽象回到原题得到答案"
-    }
-  ]
-}
-```
-
-`mode` 为 `single-pass` 时生成完整后退提示；`abstraction` 只生成后退问题和抽象依据 Prompt；`reasoning` 生成基于抽象依据回答原题的 Prompt。
-
-## Method Steps
-
-1. 先识别当前任务隶属的更高层原则或一般失效模式。
-2. 提出上位原则或通用分析框架（如 SOLID 原则、常见安全漏洞分类、并发模式）。
-3. 再把抽象原则落回到用户给出的具体代码或问题。
-4. 确保 Prompt 包含两部分："先确认原则（Abstraction）" → "再应用到具体场景（Abstraction-grounded Reasoning）"。
-5. 避免只给泛泛原则而不落地；也避免跳过原则直接改代码。
-
-## Design Rules
-
-- 后退问题应比原始问题更抽象、更通用、更容易回答，但必须覆盖原题所需的信息。
-- 不要把后退提示写成低层子问题拆解；后退提示是“上升到概念层”，不是“拆成步骤清单”。
-- 抽象层可以是领域原则、公式、因果机制、评价标准、实体历史、制度背景、通用定义或约束框架。
-- 推理阶段必须回到原始问题，不能停留在泛泛原则。
-- 如果任务依赖事实或实时信息，后退问题可用于检索更稳定、更全面的背景；最终答案必须优先服从原始问题和用户给出的上下文。
-- 对数学、代码、法律、医学、金融等高风险或可验证任务，要求检查原则适用条件、单位、边界和证据来源。
-- 避免要求模型暴露隐藏思维链；需要可解释性时，让模型输出简明、可公开的抽象依据和推理摘要。
-
-## Stepback Question Tightening Rules
-
-- 如果后退问题生成得太宽泛，最终答案会漂移；应收紧到“足以覆盖原题所需信息”的最小通用层。
-- 如果后退问题生成得太窄，它只是原题复述；应继续上升一层，寻找更稳定的原则或事实范围。
-- 抽象不等于模糊。抽象层要精确、可用于推理，例如公式、原则、标准、历史列表、定义或因果关系。
-
-## Single-Pass vs Two-Stage Execution
-
-### Single-Pass（默认）
-
-一个 Prompt 同时完成后退抽象、抽象层回答、回到原题推理和最终答案。适合普通聊天和用户只想拿到一个可复用提示词的场景。
-
-### Two-Stage
-
-当外部流程可以多次调用模型时使用：
-
-1. **Abstraction Stage**：用抽象阶段 Prompt 生成后退问题，以及相关原则、概念或事实范围。
-2. **Optional Retrieval**：用后退问题进行检索，把检索结果作为补充上下文。
-3. **Reasoning Stage**：用推理阶段 Prompt 输入原始问题、后退问题、抽象答案/原则和可选检索上下文。
-4. 要求模型基于抽象层回到原题，输出符合用户格式的最终答案。
-
-## When to Use
-
-- 遇到含糊的报错信息，需要先理解底层原因。
-- 重构逻辑混乱的旧代码，需要先建立清晰的架构原则。
-- 代码存在多个类似问题，可以通过归纳模式一次性解决。
-- 常见场景：模糊 Bug 排查、遗留代码重构、安全审计方法论、性能优化分析。
-
-## Example Use Cases
-
-- "这段代码报 `NullPointerException`，但我不确定哪里出了问题"
-- "这个类的逻辑越来越乱，帮我重构一下"
-- "这个合约可能有安全问题，帮我全面审计"
-
-## Prompt Output Template
-
-当你用 Step-Back 技术生成提示词时，按以下 8 节骨架输出。
-
-### 章节骨架
-
-| # | 章节 | 必需 | 说明 |
-|---|------|------|------|
-| 1 | 角色 | ✓ | 领域专家 |
-| 2 | 任务 | ✓ | 一句话 |
-| 3 | 输入 | ✓ | 目标模块/问题 |
-| 4 | 输出格式 | ✓ | 编号列表，如"1. 数据库优化, 2. API接口, 3. 评分算法..." |
-| 5 | **Step-Back 抽象框架** | ✓ | 见下方格式规范 |
-| 6 | 具体实现要求 | ✓ | 开头必须有过渡句："基于上述抽象框架，实现以下所有功能" |
-| 7 | 硬约束 | ✓ | 编号列表 |
-| 8 | 生成要求 | ✓ | 验收标准 |
-
-### 第 5 节格式规范：Step-Back 抽象框架
-
-必须包含 **2-3 个抽象框架**，每个框架是独立的 ASCII 框图。框架之间是并列关系（非递进）。
-
-每个框架格式：
-
-```
-### 框架N：[框架名称]
-
-[ASCII 框图，包含原则/公式/分类表/规则表]
-
-框图内容要求：
-- 核心原则/公式（如 "总评分 = Σ(维度得分 × 维度权重)"）
-- 组件表（如维度权重分配表、视图类型映射表）
-- 规则说明（如 "无数据维度按中性值参与计算"）
-```
-
-格式范本（来自 MCP 黄金标准 `prompt_08_dashboard`）：
-
-```
-### 框架一：健康评分算法抽象框架
-
-总评分 = Σ(维度得分 × 维度权重)
-
-维度权重分配:
-┌──────────────┬──────┬──────────────────────┐
-│ 维度          │ 权重  │ 正常范围              │
-├──────────────┼──────┼──────────────────────┤
-│ 心率          │ 15%  │ 60-100 bpm           │
-│ 血压          │ 15%  │ 90-140 / 60-90 mmHg  │
-│ ...           │ ...  │ ...                  │
-└──────────────┴──────┴──────────────────────┘
-
-无数据维度处理: 按中性值参与加权计算
-```
-
-过渡句（第6节开头）：**"基于上述抽象框架，实现以下所有功能。"**
-
-### 质量自检
-
-- [ ] 框架是抽象概念/公式/原则，不是具体代码实现
-- [ ] 第 6 节以过渡句开头，明确关联框架
-- [ ] 框架之间的抽象层级一致（不混入具体实现细节）
-- [ ] Step-Back 问题应收紧到"足以覆盖原题"的最小通用层（参考 tightening rules）
-
-## Notes
-
-- "Step-back" 的精髓是先抽象后具体，不是只给泛泛建议。
-- 后退提示适合“细节很多导致直接推理容易犯错”的任务；如果任务已经很简单，使用零样本提示即可。
-- 后退问题不是改写原题，也不是把原题拆成多个子问题；它应提升到更高语义层。
-- 与 tree-of-thought 的区别：step-back 是纵向抽象一个原则然后落地，ToT 是横向多分支并行 + 剪枝选择。
-- 与 least-to-most 的区别：step-back 是“上升概念层”，least-to-most 是“拆成有序子问题”。
+# Step-Back Prompting
+
+## Purpose
+
+适合需要先抽象原则、框架或根因，再回到具体任务的场景。Step-Back 的核心是：遇到复杂、多细节、容易被局部信息带偏的问题时，先后退一步，把原问题抽象成更高层的概念、原则、通用问题或事实范围；再把这个抽象层得到的原则或事实作为依据，回到原问题完成推理。
+
+## Input Requirements
+
+- **用户任务**：说明希望模型完成什么任务。
+- **待处理内容**：需要回答、分析、计算、判断或生成的具体问题；如果暂未提供，保留占位符。
+- **输出格式**：说明最终答案的结构、字段、长度、语言、代码格式或是否只输出最终答案。
+- **可选案例**：用户可以在第一次请求中直接提供 0~5 组 `原始问题 -> 后退问题 -> 抽象答案/原则 -> 最终答案`，用于展示如何后退抽象。
+- **可选信息**：角色设定、约束条件、是否展示后退过程、是否使用检索增强上下文。
+
+示例不是必需项。若用户已经附上案例，直接吸收案例中的后退抽象方式和输出风格；若未检测到案例，不要追问或中断流程，按零样本后退提示生成。
+
+## Recommended JSON Input
+
+```json
+{
+  "task": "回答这道复杂问题",
+  "role": "你是一名擅长抽象原则和稳健推理的助手",
+  "target_input": "{用户输入的问题}",
+  "output_format": "先输出后退问题和抽象依据，再输出最终答案。",
+  "constraints": ["最终答案必须回到原始问题", "不要添加无关解释"],
+  "trace_visibility": "展示后退问题、抽象依据和简明推理摘要",
+  "examples": [
+    {
+      "original": "具体问题",
+      "stepback_question": "更高层、更通用的问题",
+      "abstraction": "相关原则、概念、背景事实或通用框架",
+      "answer": "如何基于抽象回到原题得到答案"
+    }
+  ]
+}
+```
+
+`mode` 为 `single-pass` 时生成完整后退提示；`abstraction` 只生成后退问题和抽象依据 Prompt；`reasoning` 生成基于抽象依据回答原题的 Prompt。
+
+## Method Steps
+
+1. 先识别当前任务隶属的更高层原则或一般失效模式。
+2. 提出上位原则或通用分析框架（如 SOLID 原则、常见安全漏洞分类、并发模式）。
+3. 再把抽象原则落回到用户给出的具体代码或问题。
+4. 确保 Prompt 包含两部分："先确认原则（Abstraction）" → "再应用到具体场景（Abstraction-grounded Reasoning）"。
+5. 避免只给泛泛原则而不落地；也避免跳过原则直接改代码。
+
+## Design Rules
+
+- 后退问题应比原始问题更抽象、更通用、更容易回答，但必须覆盖原题所需的信息。
+- 不要把后退提示写成低层子问题拆解；后退提示是“上升到概念层”，不是“拆成步骤清单”。
+- 抽象层可以是领域原则、公式、因果机制、评价标准、实体历史、制度背景、通用定义或约束框架。
+- 推理阶段必须回到原始问题，不能停留在泛泛原则。
+- 如果任务依赖事实或实时信息，后退问题可用于检索更稳定、更全面的背景；最终答案必须优先服从原始问题和用户给出的上下文。
+- 对数学、代码、法律、医学、金融等高风险或可验证任务，要求检查原则适用条件、单位、边界和证据来源。
+- 避免要求模型暴露隐藏思维链；需要可解释性时，让模型输出简明、可公开的抽象依据和推理摘要。
+
+## Stepback Question Tightening Rules
+
+- 如果后退问题生成得太宽泛，最终答案会漂移；应收紧到“足以覆盖原题所需信息”的最小通用层。
+- 如果后退问题生成得太窄，它只是原题复述；应继续上升一层，寻找更稳定的原则或事实范围。
+- 抽象不等于模糊。抽象层要精确、可用于推理，例如公式、原则、标准、历史列表、定义或因果关系。
+
+## Single-Pass vs Two-Stage Execution
+
+### Single-Pass（默认）
+
+一个 Prompt 同时完成后退抽象、抽象层回答、回到原题推理和最终答案。适合普通聊天和用户只想拿到一个可复用提示词的场景。
+
+### Two-Stage
+
+当外部流程可以多次调用模型时使用：
+
+1. **Abstraction Stage**：用抽象阶段 Prompt 生成后退问题，以及相关原则、概念或事实范围。
+2. **Optional Retrieval**：用后退问题进行检索，把检索结果作为补充上下文。
+3. **Reasoning Stage**：用推理阶段 Prompt 输入原始问题、后退问题、抽象答案/原则和可选检索上下文。
+4. 要求模型基于抽象层回到原题，输出符合用户格式的最终答案。
+
+## When to Use
+
+- 遇到含糊的报错信息，需要先理解底层原因。
+- 重构逻辑混乱的旧代码，需要先建立清晰的架构原则。
+- 代码存在多个类似问题，可以通过归纳模式一次性解决。
+- 常见场景：模糊 Bug 排查、遗留代码重构、安全审计方法论、性能优化分析。
+
+## Example Use Cases
+
+- "这段代码报 `NullPointerException`，但我不确定哪里出了问题"
+- "这个类的逻辑越来越乱，帮我重构一下"
+- "这个合约可能有安全问题，帮我全面审计"
+
+## Prompt Output Template
+
+当你用 Step-Back 技术生成提示词时，按以下 8 节骨架输出。
+
+### 章节骨架
+
+| # | 章节 | 必需 | 说明 |
+|---|------|------|------|
+| 1 | 角色 | ✓ | 领域专家 |
+| 2 | 任务 | ✓ | 一句话 |
+| 3 | 输入 | ✓ | 目标模块/问题 |
+| 4 | 输出格式 | ✓ | 编号列表，如"1. 数据库优化, 2. API接口, 3. 评分算法..." |
+| 5 | **Step-Back 抽象框架** | ✓ | 见下方格式规范 |
+| 6 | 具体实现要求 | ✓ | 开头必须有过渡句："基于上述抽象框架，实现以下所有功能" |
+| 7 | 硬约束 | ✓ | 编号列表 |
+| 8 | 生成要求 | ✓ | 验收标准 |
+
+### 第 5 节格式规范：Step-Back 抽象框架
+
+必须包含 **2-3 个抽象框架**，每个框架是独立的 ASCII 框图。框架之间是并列关系（非递进）。
+
+每个框架格式：
+
+```
+### 框架N：[框架名称]
+
+[ASCII 框图，包含原则/公式/分类表/规则表]
+
+框图内容要求：
+- 核心原则/公式（如 "总评分 = Σ(维度得分 × 维度权重)"）
+- 组件表（如维度权重分配表、视图类型映射表）
+- 规则说明（如 "无数据维度按中性值参与计算"）
+```
+
+格式范本（来自 MCP 黄金标准 `prompt_08_dashboard`）：
+
+```
+### 框架一：健康评分算法抽象框架
+
+总评分 = Σ(维度得分 × 维度权重)
+
+维度权重分配:
+┌──────────────┬──────┬──────────────────────┐
+│ 维度          │ 权重  │ 正常范围              │
+├──────────────┼──────┼──────────────────────┤
+│ 心率          │ 15%  │ 60-100 bpm           │
+│ 血压          │ 15%  │ 90-140 / 60-90 mmHg  │
+│ ...           │ ...  │ ...                  │
+└──────────────┴──────┴──────────────────────┘
+
+无数据维度处理: 按中性值参与加权计算
+```
+
+过渡句（第6节开头）：**"基于上述抽象框架，实现以下所有功能。"**
+
+### 质量自检
+
+- [ ] 框架是抽象概念/公式/原则，不是具体代码实现
+- [ ] 第 6 节以过渡句开头，明确关联框架
+- [ ] 框架之间的抽象层级一致（不混入具体实现细节）
+- [ ] Step-Back 问题应收紧到"足以覆盖原题"的最小通用层（参考 tightening rules）
+
+## Notes
+
+- "Step-back" 的精髓是先抽象后具体，不是只给泛泛建议。
+- 后退提示适合“细节很多导致直接推理容易犯错”的任务；如果任务已经很简单，使用零样本提示即可。
+- 后退问题不是改写原题，也不是把原题拆成多个子问题；它应提升到更高语义层。
+- 与 tree-of-thought 的区别：step-back 是纵向抽象一个原则然后落地，ToT 是横向多分支并行 + 剪枝选择。
+- 与 least-to-most 的区别：step-back 是“上升概念层”，least-to-most 是“拆成有序子问题”。