# solution-output

> 代码修改前的方案输出机制，定义方案输出的内容和格式

- Author: gengxiao
- Repository: atom-set/prompt-engin
- Version: 20260129205336
- Stars: 0
- Forks: 0
- Last Updated: 2026-02-06
- Source: https://github.com/atom-set/prompt-engin
- Web: https://mule.run/skillshub/@@atom-set/prompt-engin~solution-output:20260129205336

---

---
name: solution-output
description: 代码修改前的方案输出机制，定义方案输出的内容和格式
priority: 2
tags: ['core', 'mode', 'plan', 'solution']
---

# 代码修改前的方案输出机制

## 使用场景

当用户需要：
- 需要输出修改方案时
- 代码修改前
- 需要用户确认时

## 触发条件

以下情况自动应用此规范：
- 代码修改前自动应用
- 输出方案时自动应用

## 与其他规则的配合

- **依赖关系**：
  - `tool-permission-system`：方案输出时机在工具调用检查流程中确定，意图识别检查（第零步）判断是否需要输出方案
  - `plan-mode`：方案输出必须在 Plan 模式下完成，Plan 模式下的行为规范定义了方案输出的触发条件和要求
- 与核心规则配合使用

---

# 代码修改前的方案输出机制

---

## 核心原则

在 Plan 模式下，收到任何代码修改需求时，必须先输出详细的修改方案和计划，等待用户确认后才能执行。

**重要说明**：
- **意图识别**：在工具调用检查时执行（详见 `tool-permission-system.md`）
- **方案输出**：本文件定义方案输出的内容要求（5个部分的具体格式）

---

## 需求识别和方案输出时机（强制要求）

**核心原则**：在响应生成前，必须先识别用户需求类型，如果是代码修改需求，必须在调用任何工具之前输出完整方案。

**需求识别流程**（必须在响应生成前执行）：

1. **识别用户需求类型**：
   - 分析用户输入，判断是否为代码修改需求
   - 识别标准：参考"代码修改需求的识别标准"
   
2. **根据需求类型处理**：
   - **代码修改需求**：
     1. 输出模式标识
     2. 输出完整方案（5个部分）
     3. 输出更新后的计划
     4. 等待用户输入"Act"
     5. 禁止调用任何工具（包括只读工具）
   - **查询需求**：
     1. 输出模式标识
     2. 可以调用只读工具
     3. 输出查询结果
     4. 输出更新后的计划

**代码修改需求的识别标准**：

- **明确的关键词**：
  - 动作词："修改"、"修复"、"添加"、"删除"、"实现"、"创建"、"更新"、"调整"、"优化"、"重构"、"改进"
  - 问题词："bug"、"错误"、"问题"、"漏洞"、"需要"、"应该"、"缺少"
  - 文件操作："创建文件"、"删除文件"、"修改文件"、"更新文件"

- **上下文判断**：
  - 如果用户描述了一个问题，并暗示需要修改代码
  - 如果用户要求实现某个功能
  - 如果用户要求修复某个错误

**方案输出时机要求**（强化版）：

- **代码修改需求**：
  - 必须在调用任何工具之前输出完整方案
  - 禁止先调用只读工具（如 read_file、codebase_search）再输出方案
  - 方案输出必须在同一响应中完成
  - 方案输出后，必须等待用户输入"Act"才能调用工具

- **查询需求**：
  - 可以调用只读工具
  - 不需要输出方案

**禁止的行为**：
- ❌ 识别为代码修改需求后，先调用只读工具再输出方案
- ❌ 跨响应输出方案（先调用工具，下一响应再输出方案）
- ❌ 假设用户需求类型而不明确识别
- ❌ 跳过需求识别直接调用工具

**示例**：

```
# ✅ 正确流程
用户：修改 sync.sh 脚本
AI（Plan模式）：
  # 模式：Plan
  
  [识别为代码修改需求]
  [输出完整方案，不调用任何工具]
  [输出更新后的计划]
  [提醒用户输入"Act"]

# ❌ 错误流程
用户：修改 sync.sh 脚本
AI（Plan模式）：
  # 模式：Plan
  
  [调用 read_file 读取文件]  ❌ 错误：代码修改需求应先输出方案
  [调用 codebase_search 搜索]  ❌ 错误：代码修改需求应先输出方案
  [然后才输出方案]  ❌ 错误：方案应在调用工具前输出
```

---

## 方案输出内容要求

### 必须包含的 5 个部分

#### 1. 需求分析

**至少包含**：
- 问题描述或用户需求
- 要解决的核心问题
- 需求背景（可选）

#### 2. 修改方案

**至少包含**：
- 修改的文件列表
- 修改的位置（函数、类、模块等）
- 具体的修改内容（代码示例或说明）

**设计原则**（强制要求，参考 `design-principles.md`）：
- **优先考虑简单方案**：必须首先提出最简单的实现方案
- **避免过度设计**：不要为了"未来可能的需求"而增加不必要的复杂度
- **复杂方案需明确场景**：如果采用复杂方案，必须明确说明：
  - 在什么具体场景下需要复杂方案？
  - 简单方案为什么无法满足需求？
  - 有哪些明确的约束条件？
- **方案对比**：必须对比简单方案和复杂方案，说明各自的优缺点和选择理由
- **禁止假设未来需求**：不能因为"未来可能需要"而采用复杂方案

#### 3. 影响分析

**至少包含**：
- 对现有功能的影响
- 对相关文件的影响
- 是否需要向下兼容（可选）

#### 4. 实施计划

**至少包含**：
- 任务清单（表格格式，包含任务编号、任务名称、状态、优先级、说明）
- 实施顺序
- 注意事项（可选）

#### 5. 风险评估

**至少包含**：
- 潜在问题（至少 1 个）
- 回滚方案（至少说明如何回滚）

---

## 方案完整性判断标准

### 每个部分的最低要求

1. **需求分析**（至少包含）：
   - 问题描述或用户需求
   - 要解决的核心问题
   - 需求背景（可选）

2. **修改方案**（至少包含）：
   - 修改的文件列表
   - 修改的位置（函数、类、模块等）
   - 具体的修改内容（代码示例或说明）

3. **影响分析**（至少包含）：
   - 对现有功能的影响
   - 对相关文件的影响
   - 是否需要向下兼容（可选）

4. **实施计划**（至少包含）：
   - 任务清单（表格格式，包含任务编号、任务名称、状态、优先级、说明）
   - 实施顺序
   - 注意事项（可选）

5. **风险评估**（至少包含）：
   - 潜在问题（至少 1 个）
   - 回滚方案（至少说明如何回滚）

### 完整性检查清单

- [ ] 需求分析：包含问题描述和核心问题
- [ ] 修改方案：包含修改的文件、位置和内容
- [ ] 影响分析：包含对现有功能和相关文件的影响
- [ ] 实施计划：包含任务清单（表格格式）和实施顺序
- [ ] 风险评估：包含潜在问题和回滚方案

### 判断原则

- 每个部分必须有实际内容，不能为空或只有标题
- 如果某个部分内容不充分，应视为不完整
- 如果方案不完整，必须补充完整后才能执行

---

## 强制要求

1. **必须先输出方案**：
   - 收到代码修改需求或问题描述（可能涉及代码修改）时，必须先分析需求
   - 输出详细的修改方案（包括：修改内容、影响范围、实施步骤等）
   - 输出完整的任务清单（使用表格格式）
   - 说明修改的风险和注意事项
   - **方案输出时机要求**：方案输出必须在调用修改工具前的**同一响应中**完成
   - **禁止跨响应执行**：如果先调用了只读工具，必须在同一响应中输出完整方案，不能跨响应直接调用修改工具

2. **必须输出计划**：
   - 在方案输出后，必须输出更新后的计划
   - 计划应包含任务清单、优先级、预计影响等
   - 使用分隔线区分方案和计划

3. **必须等待确认**：
   - 输出方案和计划后，必须明确提醒用户输入"Act"指令才能执行
   - 不能假设用户同意执行
   - 不能跳过方案输出直接执行修改
   - **执行顺序要求**：方案输出 → 等待用户输入"Act" → 切换到 Act 模式 → 调用工具
   - **禁止跨响应调用**：如果输出了方案，必须等待用户明确输入"Act"后才能调用工具，不能在下一个响应中直接调用工具

---

## 正确流程

1. 收到代码修改需求
2. 分析需求，理解要解决的问题
3. 输出详细的修改方案（包括需求分析、修改方案、影响分析、实施计划、风险评估）
4. 输出更新后的计划（任务清单）
5. 明确提醒用户输入"Act"指令才能执行
6. 等待用户输入"Act"指令
7. 用户输入"Act"后，切换到 Act 模式执行修改

---

## 示例流程

```
用户：修改某个功能
AI（Plan模式）：
  1. 分析需求
  2. 输出详细方案（需求分析、修改方案、影响分析、实施计划、风险评估）
  3. 输出任务清单
  4. 提醒："当前处于Plan模式，如需执行修改，请输入'Act'切换到执行模式"
用户：Act
AI（Act模式）：
  执行代码修改
```

---

## 错误示例（禁止的行为）

```
用户：按住点击 wx_login_redirect 不会进入定义的文件
AI（Plan模式）：
  ❌ 错误：直接执行代码修改，没有输出方案
  ❌ 错误：假设用户描述问题就是要求修改
  ❌ 错误：跳过方案输出直接调用 search_replace
```

---

## 相关文件

- `tool-permission-system.md`：工具权限系统（意图识别和检查机制）
- `design-principles.md`：设计原则规范（简单设计优先）