loopforge 1.1.1 → 1.3.0

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

@@ -0,0 +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 是“拆成有序子问题”。

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

@@ -0,0 +1,191 @@
+# Tree-of-Thought (ToT) Prompting
+
+## Purpose
+
+适合需要多路径探索、比较、剪枝和选择最佳方案的高风险任务。ToT 的核心不是让模型"多想一点"，而是把问题求解视为对多个候选思路的搜索：每个节点是一个可公开的中间思路或部分解；模型在每一步生成多个候选、评价候选、保留最有希望的分支、必要时剪枝或回溯，最后用最优路径或综合结果给出答案。
+
+## On the "3 Experts" Prompt Pattern
+
+"Imagine three different experts..." 可以体现 ToT 的一部分思想：多候选、多人视角、逐轮共享、发现错误后退出、迭代改进。它们适合作为直观的"专家协作式思维树"简化提示。
+
+但它们还不等于完整 ToT。缺少的关键控制包括：
+- 明确定义每个 `thought` 是什么粒度：一句策略、一个公式、一个计划段落、一个部分答案等。
+- 限制分支数和最大深度，避免输出失控。
+- 明确每轮如何评价候选：分数、等级、投票、可行/不可行、风险。
+- 明确如何保留、剪枝、回溯或合并分支。
+- 明确最终决策规则：最高分路径、投票获胜、综合多个优秀分支，或在冲突时使用评估标准裁决。
+- 明确输出格式，尤其是表格字段和最终答案位置。
+
+所以，生成的提示词应保留"专家协作"的可读性，同时补上 ToT 的搜索控制结构。
+
+## Input Requirements
+
+- **用户任务**：说明希望模型完成什么任务。
+- **待处理内容**：需要推理、规划、选择、创作、排错或生成的具体问题；如果暂未提供，保留占位符。
+- **输出格式**：说明最终答案的结构、字段、长度、语言、代码格式或是否只输出最终答案。
+- **可选案例**：用户可以在第一次请求中直接提供 0~5 组 `任务 -> 候选分支/专家思路 -> 评估/剪枝依据 -> 最终合并结果`。
+- **可选信息**：专家角色、分支数、最大深度、搜索策略、评价标准、剪枝规则、是否展示树过程。
+
+## Recommended JSON Input
+
+```json
+{
+  "task": "为复杂问题生成思维树提示词",
+  "role": "你是一名严谨的多路径问题求解助手",
+  "target_input": "{用户输入的问题}",
+  "output_format": "先输出思维树过程表，再输出最终答案。",
+  "examples": [
+    {
+      "task": "示例任务",
+      "branches": ["候选路径 A", "候选路径 B", "候选路径 C"],
+      "evaluation": "根据可行性、风险和目标一致性剪枝",
+      "final": "整合最佳分支后形成最终答案"
+    }
+  ],
+  "constraints": ["每轮最多 3 个候选", "最多 3 轮", "最终答案必须简洁"],
+  "branch_count": 3,
+  "max_depth": 3,
+  "keep_count": 2,
+  "search_strategy": "beam",
+  "evaluation_criteria": ["正确性", "可行性", "约束匹配", "风险"],
+  "decision_rule": "选择最高分路径；若两个分支互补，则综合后给出一个答案。"
+}
+```
+
+`examples` 可省略；省略时按零样本思维树提示生成。
+
+## Thought Unit Granularity
+
+根据任务类型选择 `thought` 的粒度：
+
+| 任务类型 | 思维单元定义 | 示例 |
+|---------|------------|------|
+| **Math / Symbol** | 一步操作、一个中间式、一个局部解 | 一个公式变形、一个中间计算结果 |
+| **Writing / Creative** | 一个写作计划、一个段落方案、一个叙事方向 | 一个开头策略、一个故事转折方案 |
+| **Decision / Planning** | 一个策略、一个行动方案、一个风险处理路径 | 一个部署方案、一个架构选择 |
+| **Code / Debug** | 一个假设、一个诊断步骤、一个修复方案 | 一个 Bug 根因假设、一个重构方案 |
+
+## Search Strategy Selection
+
+| 策略 | 说明 | 适用场景 |
+|------|------|---------|
+| **Beam（宽度优先近似）** | 每轮生成多个候选，保留前 `b` 个继续展开 | 规划、创作、数学搜索和多数通用任务 |
+| **DFS（深度优先近似）** | 优先深入最高分分支，遇到不可行或低分时回溯 | 谜题、约束满足、排错 |
+| **Expert-Panel（专家协作）** | 3+ 个专家各自产生候选，再相互评价和修正 | 用户喜欢可读讨论过程的场景（仍需加入分支数、深度、评分和决策规则） |
+
+## Method Steps
+
+1. 要求模型生成 2-4 个候选思路或方案分支。
+2. 对每个分支，按用户定义的约束评估可行性、安全性和效率。
+3. 剪枝：淘汰明显不成立或有严重缺陷的分支。
+4. 保留最优 1-2 个分支，深入展开。
+5. 给出最终方案及其选择理由。
+6. 限制分支数量和探索深度，避免搜索过程撑爆上下文。
+
+## Design Rules
+
+- `thought` 是可公开的中间语义单元，不是隐藏思维链。要求模型输出"候选思路/方案摘要/评估理由"，不要要求暴露完整内部推理。
+- 每轮必须先生成多个候选，再评价，再保留/剪枝；不要一条路走到底。
+- 输出必须有明确状态表：轮次、分支编号、候选思路、评分/判断、保留或剪枝原因。
+- 分支数和深度必须有限制（默认 branch_count=3, max_depth=3, keep_count=2），防止 ToT 提示词变成无限展开。
+- 专家角色可用于增强多样性，但专家不是 ToT 的必要条件；关键是分支搜索与状态评价。
+- 如果任务有硬约束，评价标准必须把硬约束放在第一位。
+- 如果所有分支都低质量，允许回溯到上一轮重新生成候选。
+- 在输出评估与剪枝过程时保持精简。对于明显违背物理常识或分布式原理的劣质分支，可直接在内部思维链中抛弃，仅输出具备高可行性的候选分支进行对比。
+- 对严格格式输出任务，树搜索过程可以内部完成，最终只输出用户指定格式。
+
+## When to Use
+
+- 任务存在多个可能的解决方案，需要比较权衡。
+- 结果质量非常重要（安全、性能、正确性），不能只靠单一路径。
+- 功能完全独立（不依赖前序上下文）且认知负载高。
+- 常见场景：核心算法实现、加密/签名验证、Assembly 操作、安全审计关键路径。
+
+## Example Use Cases
+
+- "用纯 Assembly 手写一个防重放攻击的默克尔树签名校验函数"
+- "实现一个高性能的并发哈希表，对比锁策略"
+- "设计合约升级方案，评估 delegatecall vs UUPS vs 钻石标准"
+
+## Prompt Output Template
+
+当你用 Tree-of-Thought 技术生成提示词时，按以下 8 节骨架输出。
+
+### 章节骨架
+
+| # | 章节 | 必需 | 说明 |
+|---|------|------|------|
+| 1 | 角色 | ✓ | 多路径问题求解专家，可引入"3 位专家"角色 |
+| 2 | 任务 | ✓ | 一句话 |
+| 3 | 输入 | ✓ | 高风险的复杂问题 |
+| 4 | 输出格式 | ✓ | "先输出思维树过程，再输出最终答案/方案" |
+| 5 | **思维树探索框架** | ✓ | 见下方格式规范 |
+| 6 | 具体实现要求 | ✓ | 按输出格式展开 |
+| 7 | 硬约束 | ✓ | 含分支数、深度、剪枝规则、安全/性能约束 |
+| 8 | 生成要求 | ✓ | "先探索多路径，再选择最优方案" |
+
+### 第 5 节格式规范：思维树探索框架
+
+必须包含以下三个子块：
+
+**A. 搜索策略声明：**
+
+```
+搜索策略: [beam / dfs / expert-panel]
+分支数(branch_count): 2-4
+最大深度(max_depth): ≤3
+每轮保留数(keep_count): 1-2
+```
+
+**B. 评估标准表：**
+
+| 标准 | 权重 | 说明 |
+|------|------|------|
+| 正确性 | 最高 | 逻辑/数学正确 |
+| 可行性 | 高 | 可实际编码运行 |
+| 约束匹配 | 高 | 满足硬约束 |
+| 性能 | 中 | 时间/空间效率 |
+| 安全性 | 最高 | 无漏洞/无越权 |
+
+**C. 思维树状态表格式（要求模型按此格式输出）：**
+
+```
+| 轮次 | 分支 | 候选方案 | 评估 | 决策 |
+|------|------|---------|------|------|
+| 1    | A    | [方案描述] | 评分/判断 | 保留/剪枝 |
+| 1    | B    | [方案描述] | 评分/判断 | 保留/剪枝 |
+| 1    | C    | [方案描述] | 评分/判断 | 保留/剪枝 |
+| 2    | A1   | [深入展开] | ... | ... |
+| 2    | B1   | [深入展开] | ... | ... |
+| ...  | ...  | ...       | ... | ... |
+
+最终选择: [最优方案 + 选择理由]
+```
+
+### 搜索策略选择指南
+
+根据任务类型选择策略（详见上文 Search Strategy Selection 表）：
+- **Beam（默认）**：规划、创作、数学搜索 — 每轮生成多个候选，保留前 b 个
+- **DFS**：谜题、约束满足、排错 — 优先深入最高分分支，遇到不可行时回溯
+- **Expert-Panel**：用户喜欢可读讨论过程的场景 — 3+ 专家各自生成候选，相互评价
+
+### 质量自检
+
+- [ ] 分支数 2-4，深度≤3（防止 token 爆炸）
+- [ ] 评估标准表包含正确性、可行性、约束匹配三项以上
+- [ ] 状态表格式明确（轮次/分支/方案/评估/决策）
+- [ ] 从现有 design_rules 中选择合适的搜索策略
+- [ ] 硬约束在评估标准中排在第一位
+- [ ] 不是"3 位专家随便聊聊"——有明确的分支数、深度、评分和剪枝规则
+- [ ] 结尾要求模型输出最终选择和理由
+
+## Notes
+
+- ToT 成本通常高于 CoT，因为它要生成和评价多个分支；只有复杂任务值得使用。
+- 限制分支数量（2-4 分支，深度 ≤ 3 层），避免 token 爆炸。
+- 剪枝标准必须在 Prompt 中明确写出。
+- 不要把"专家人数"误当成 ToT 的核心。核心是：候选生成、状态评价、搜索/剪枝、最终选择。
+- 与 step-back 的区别：ToT 是横向多分支并行 + 剪枝选择，step-back 是纵向抽象一个原则然后落地。
+- 与 least-to-most 的区别：ToT 是探索性的（不确定最优路径），least-to-most 是确定性的（已知最佳顺序）。
+- 如果用户同时有 step-back 意图和 ToT 需求，将 step-back 作为每个候选分支评估前的抽象步骤。
+- 用户提供案例时，可以作为少样本参考嵌入提示词，但案例服务于分支生成、评估、剪枝和合并风格，不应削弱思维树结构。

package/skills/prompt-techniques/references/zero-shot.md

@@ -0,0 +1,97 @@
+# Zero-Shot Prompting
+
+## Purpose
+
+适合目标清晰、无需示例或复杂推理的直接提示词生成。用于简单的代码解释、格式化、修改变量名、增删注释、调整代码风格等低负载、高连续性任务。
+
+## Input Requirements
+
+- **用户任务**：说明希望模型完成什么任务。
+- **目标输入**：待处理的代码、文本或数据。
+- **输出格式**：说明最终答案的结构、字段、长度、语言或代码格式。
+- **可选信息**：角色设定、约束条件、目标用户或使用场景。
+
+零样本提示不插入任务级输入/输出示例；如果需要示例引导，应改用少样本提示。
+
+## Recommended JSON Input
+
+```json
+{
+  "task": "将文章总结为 3 个关键要点",
+  "role": "你是一名专业内容摘要员",
+  "target_input": "{用户输入的文章内容}",
+  "output_format": "使用 Markdown 列表，只输出 3 条，每条一句话。",
+  "format_example": "- 要点 1\n- 要点 2\n- 要点 3",
+  "constraints": ["不要添加额外解释", "输出语言为中文"]
+}
+```
+
+## Method Steps
+
+1. 直接围绕用户任务、输出格式和约束组织最终 Prompt。
+2. 确保 Prompt 包含清晰的：角色设定（Role）、具体任务描述（Task）、输出格式要求（Output Format）。
+3. 避免加入不必要的推理框架、阶段历史或示例——保持轻量。
+4. 一次只给一条指令，不要在一个 Prompt 中混合多个不相关任务。
+
+## Design Rules
+
+- 保持角色、任务指令、上下文和输出格式明确。
+- 零样本提示不插入任务级输入/输出示例；如果需要示例引导，应改用少样本提示。
+- 可以提供“示例输出格式”或格式骨架，用于约束结构，但不要把它写成 few-shot 示例。
+- 输出格式应可验证，如字段名、顺序、句数、列表数量、Markdown 样式或 JSON 结构。
+- 使用 `###`、三引号 `"""` 或代码块清晰分隔指令和待处理内容。
+- `{用户输入的文本}` 或 `{text input here}` 必须替换为实际用户文本，或作为待用户后续填入的占位符保留。
+- 对于复杂推理任务，可考虑 CoT 技术；对于已有示例的任务，可考虑少样本提示。
+
+## When to Use
+
+- 任务简单直接，不需要多步推理。
+- 用户输入已经清晰完整，只需整理格式。
+- 上下文连续性高（修改已有代码的局部细节）。
+- 常见场景：代码格式化、变量重命名、添加注释、简单 CRUD、配置文件修改。
+
+## Example Use Cases
+
+- "把这段代码的变量名从 `x` 改为 `userCount`"
+- "给这个函数添加 JSDoc 注释"
+- "把这个 JSON 格式化为缩进 2 空格"
+- "写一个简单的 hello world 页面"
+
+## Prompt Output Template
+
+当你用 Zero-Shot 技术生成提示词时，按以下 **7 节骨架**输出（第 5 节约略——Zero-Shot 不需要示例或推理框架）。
+
+### 章节骨架
+
+| # | 章节 | 必需 | 说明 |
+|---|------|------|------|
+| 1 | 角色 | ✓ | 简明角色设定，如"专业前端工程师，精通 React" |
+| 2 | 任务 | ✓ | 一句话 |
+| 3 | 输入 | ✓ | 目标代码/数据/文件 |
+| 4 | 输出格式 | ✓ | 具体产出格式说明，可用"格式示例"骨架（如 `{ "field": "value" }`），但不要写成 few-shot 示例 |
+| 5 | — | 省略 | Zero-Shot 不插入示例或推理框架 |
+| 6 | 具体实现要求 | ✓ | 简洁的要点列表 |
+| 7 | 硬约束 | ✓ | ≤5 条最关键的规则 |
+| 8 | 生成要求 | ✓ | 简短验收标准 |
+
+### 格式说明
+
+- 整体保持轻量，总长度通常 ≤ 100 行
+- 不加入任何 "示例 1/示例 2" 或 "推理步骤" 类章节
+- 输出格式可给出格式骨架（如 JSON 结构），但不能写成带具体值的 few-shot 示例
+- 一次只给一条指令，不混合多个不相关任务
+- 如果用户提供了示例，应改用 few-shot，不要强行压缩进 zero-shot
+
+### 质量自检
+
+- [ ] 不含 "示例" 或 "Few-Shot" 章节
+- [ ] 不含推理框架（那是 CoT 的事）
+- [ ] 不含多分支探索（那是 ToT 的事）
+- [ ] 输出格式是骨架（字段名），不是带具体值的示例
+- [ ] 总长度 ≤ 100 行
+
+## Notes
+
+- 不要给简单任务添加过度复杂的推理框架。
+- 如果任务涉及安全、加密或并发，考虑升级到 tree-of-thought 或 step-back。
+- 零样本提示是所有其他技术的 Prompt 结构骨架——其他技术（CoT、Step-Back、Least-to-Most）在其基础上叠加特定的推理或分解结构。