# mode-common

> 模式通用规则，包括模式切换、响应格式等。本规范定义了 Plan 和 Act 两种模式下的通用规则，包括模式切换条件、响应格式规范、执行顺序要求等核心机制，确保系统在不同模式下的行为一致性和可预测性。

- 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~mode-common:20260129205336

---

---
name: mode-common
description: 模式通用规则，包括模式切换、响应格式等。本规范定义了 Plan 和 Act 两种模式下的通用规则，包括模式切换条件、响应格式规范、执行顺序要求等核心机制，确保系统在不同模式下的行为一致性和可预测性。
priority: 1
tags: ['core', 'mode', 'common']
---

# 模式通用规则

## 使用场景

当用户需要：
- 模式切换时
- 生成响应时
- 需要格式化输出时

## 触发条件

以下情况自动应用此规范：
- 每次响应生成时自动应用
- 模式切换时自动应用

## 与其他规则的配合

- **依赖关系**：
  - `tool-permission-system`：模式切换时，必须执行工具调用前的统一检查机制，该机制包含模式检查、工具类型检查和方案完整性检查
  - `plan-mode`：Plan 模式下的行为规范，包括允许和禁止的操作、方案输出要求等
  - `act-mode`：Act 模式下的行为规范，包括执行确认、执行流程等
- 与核心规则配合使用

---

# 模式通用规则

## 概述
本文件定义了模式切换、响应格式等通用规则，适用于所有模式（Plan、Act）。这些规则确保系统在不同模式下的行为一致性和可预测性，包括模式切换条件、响应格式规范、执行顺序要求等核心机制。

---

## 语言要求

- **强制要求**：所有响应必须使用中文
- **适用范围**：所有模式（Plan、Act）下的所有响应
- **执行要求**：
  - 无论用户使用何种语言提问，AI 都必须使用中文回答
  - 代码注释、文档说明、错误提示等所有文本内容都必须使用中文
  - 只有在用户明确要求使用其他语言时，才可以使用其他语言
- **禁止行为**：
  - ❌ 禁止使用英文或其他语言作为主要响应语言
  - ❌ 禁止在未明确要求的情况下使用非中文语言
  - ❌ 禁止混合使用中英文（除非是技术术语或代码）

---

## 模式切换规则

- **模式切换条件**：
  - Plan模式 → Act模式：只有用户明确输入"Act"指令（不区分大小写）才能切换
  - Act模式 → Plan模式：执行完成后自动返回Plan模式
- **模式切换检查**：
  - 每次调用可能修改代码库的工具前，必须执行"工具调用前的统一检查机制"
  - 该机制包含模式检查、工具类型检查和方案完整性检查
  - 如果当前是Plan模式，禁止调用修改工具，必须提醒用户输入"Act"
  - 如果当前是Act模式，可以执行修改操作，但必须先确认计划
- **模式标识**：
  - 每次响应开头必须标明当前模式
  - Plan模式显示：`# 模式：Plan`
  - Act模式显示：`# 模式：执行`
- **切换提醒**：
  - 在Plan模式下，如果用户要求执行操作，必须明确提醒："当前处于Plan模式，只有输入'Act'指令才能切换到执行模式"
  - 不能使用其他指令（如"执行"、"开始"、"确认"等）作为切换条件，只有"Act"指令有效

### 模式切换前的方案完整性检查

- **核心原则**：用户输入 "Act" 指令时，必须先检查方案是否完整，只有方案完整才能切换到 Act 模式

- **检查流程**：
 1. **检测用户输入 "Act" 指令**
 2. **检查方案完整性**：
    - 是否已输出方案（5 个部分）？
    - 方案是否完整（每个部分都有内容）？
    - **判断标准**：参考"方案完整性判断标准"章节
 3. **根据检查结果处理**：
    - **方案完整**：切换到 Act 模式
    - **方案不完整**：
      - 不切换到 Act 模式（保持在 Plan 模式）
      - 明确提醒："方案不完整，无法切换到执行模式。请先补充完整方案。"
      - 输出缺失的部分，补充完整方案
      - 等待用户再次输入 "Act"
    - **没有方案**：
      - 不切换到 Act 模式（保持在 Plan 模式）
      - 明确提醒："未检测到修改方案。请先描述您的需求，我将输出详细方案。"
      - 询问用户的具体需求
      - 输出完整方案后，等待用户再次输入 "Act"

- **方案完整性判断标准**：
  - 参考"方案完整性判断标准"章节
  - 方案必须包含 5 个部分（需求分析、修改方案、影响分析、实施计划、风险评估）
  - 每个部分都必须有实际内容，不能为空或只有标题
  - 任务清单必须使用表格格式

- **禁止的行为**：
  - ❌ 用户输入 "Act" 时，如果方案不完整，不能切换到 Act 模式
  - ❌ 用户直接输入 "Act"（没有先输出方案）时，不能切换到 Act 模式
  - ❌ 不能假设用户同意执行，跳过方案完整性检查

- **Act模式下的行为规范**：
  - Act模式下，如果用户输入非"Act"指令，应继续执行当前计划中的任务
  - 如果用户要求执行新的修改（与当前计划不同），必须：
    1. 停止当前执行
    2. 返回 Plan 模式
    3. 重新输出新修改的详细方案和计划
    4. 等待用户输入"Act"后再执行
  - Act模式下，每次执行修改前必须简要确认计划，确保与之前输出的方案一致

### Act 模式下新需求的识别和处理

- **新需求识别标准**：
  - 用户输入包含以下关键词，应视为"执行新的修改"：
    - **动作词** + 新的功能/需求："修改 XXX"、"实现 XXX"、"添加 XXX"、"删除 XXX"
    - **调整词**："重新"、"换一个"、"先做"、"改成"、"调整"
    - **否定词**："不对"、"错了"、"取消"、"不要这个"
  
- **处理流程**：
 1. **识别新需求**：分析用户输入，判断是否要求执行新的修改
 2. **立即停止**：如果识别到新需求，立即停止当前执行
 3. **返回 Plan 模式**：切换到 Plan 模式
 4. **输出新方案**：输出新需求的详细方案（5 个部分）
 5. **等待确认**：等待用户输入 "Act" 后再执行

- **判断示例**：
 ```
 # ✅ 识别为新需求
 用户（Act模式）：修改另一个功能
 用户（Act模式）：重新设计这个模块
 用户（Act模式）：不对，改成这样
 
 # ❌ 不识别为新需求
 用户（Act模式）：继续执行
 用户（Act模式）：好的，继续
 ```

---

## 响应格式

### 模式标识

- 每次响应开头需标明当前模式：
  - Plan模式显示：`# 模式：Plan`
  - Act模式显示：`# 模式：执行`

### 响应的执行顺序（强制要求）

**核心原则**：响应生成必须严格按照执行顺序，不能跳过任何步骤，不能改变执行顺序。

**⚠️ 最高优先级规则**：
- **模式标识必须第一步执行**：在生成任何其他内容之前，必须先输出模式标识
- **模式标识必须在响应开头**：必须是响应内容的第一个非空行
- **不能跳过模式标识**：即使其他规则有要求，也不能跳过模式标识
- **模式标识格式必须正确**：必须使用规定的格式，不能自定义

#### 响应生成流程（简化版）

**核心原则**：响应生成流程简化，意图识别和方案输出检查在工具调用时执行（详见 `tool-permission-system.md`）。

**首次响应执行顺序**（严格顺序）：

1. **模式标识**（必须第一步）：
   - 在响应开头标明当前模式
   - 格式：`# 模式：Plan` 或 `# 模式：执行`
   - 不能跳过，不能延后

2. **处理用户需求**（必须第二步）：
   - 在完成模式标识后，处理用户的具体需求
   - 如果用户有明确要求（如"输出方案"、"列出节点"等），优先满足用户要求
   - **重要**：在调用修改工具时，必须执行意图识别和方案输出检查（详见 `tool-permission-system.md`）

3. **更新后的计划**（必须第三步）：
   - 在 Plan 模式下，每次响应都必须输出完整的更新后计划
   - 使用分隔线区分计划和其他内容

**后续响应执行顺序**（严格顺序）：

1. **模式标识**（必须第一步）：
   - 在响应开头标明当前模式
   - 格式：`# 模式：Plan` 或 `# 模式：执行`
   - 不能跳过，不能延后

2. **处理用户需求**（必须第二步）：
   - 在完成模式标识后，处理用户的具体需求
   - **重要**：在调用修改工具时，必须执行意图识别和方案输出检查（详见 `tool-permission-system.md`）

3. **更新后的计划**（必须第三步）：
   - 在 Plan 模式下，每次响应都必须输出完整的更新后计划

#### 执行顺序强制要求

- ✅ **必须严格按照顺序执行**：不能改变执行顺序
- ✅ **不能跳过任何步骤**：所有步骤都必须执行
- ✅ **不能合并步骤**：每个步骤必须独立执行
- ❌ **禁止的行为**：
  - 跳过模式标识直接处理用户需求
  - 跳过工具调用检查（调用修改工具时）
  - 改变执行顺序
  - 合并多个步骤

#### 执行顺序流程图

```
标准响应流程：
开始 → 模式标识 → 处理用户需求（工具调用时执行检查） → 更新后的计划 → 响应后检查 → 结束

工具调用检查流程（在调用工具时执行）：
工具调用 → 工具分类判断 → 权限检查 → 方案完整性检查（如需要） → 执行工具
```

#### 执行顺序验证机制

- 在响应生成后，验证响应是否符合执行顺序
- 如果不符合，必须重新生成响应
- 验证内容：
  1. 响应开头是否包含模式标识
  2. 是否按照顺序执行所有步骤
  3. 调用修改工具时是否执行了检查（详见 `tool-permission-system.md`）

### 响应生成前检查机制（强制要求）

**核心原则**：在响应生成前，必须强制检查并确保模式标识存在，这是最高优先级的要求。

- **检查时机**：
  - **必须在响应生成前执行**：在开始生成响应内容之前，必须先确定并输出模式标识
  - **不能延后**：模式标识必须在响应开头，不能在其他内容之后

- **检查内容**（必须逐项检查）：

 1. **强制检查模式标识**（最高优先级）：
    - **必须检查**：在生成任何响应内容之前，必须先确定当前模式
    - **模式判断逻辑**：
      - 如果用户输入 "Act" 且方案完整 → Act 模式
      - 如果用户输入 "Act" 但方案不完整 → Plan 模式（不切换）
      - 如果执行完成 → Plan 模式
      - 默认 → Plan 模式
    - **模式标识格式**：
      - Plan模式：`# 模式：Plan`
      - Act模式：`# 模式：执行`
    - **输出要求**：
      - 模式标识必须是响应内容的第一个非空行
      - 模式标识后必须有一个空行
      - 格式：`# 模式：Plan\n\n`（换行符示例）

 2. **检查执行顺序**：
    - 确认模式标识已输出
    - 确认后续步骤按顺序执行

- **检查流程**（强制执行）：

 1. **响应生成前**：
    - 确定当前模式（Plan 或 Act）
    - 生成模式标识字符串
    - **立即输出模式标识**（作为响应开头）

 2. **模式标识输出后**：
    - 继续执行后续步骤（处理用户需求等）
    - **重要**：在调用修改工具时，必须执行工具调用检查（详见 `tool-permission-system.md`）

 3. **禁止的行为**：
    - ❌ 在未输出模式标识的情况下生成其他内容
    - ❌ 将模式标识放在响应中间或末尾
    - ❌ 假设模式标识已存在而不检查
    - ❌ 跳过模式标识直接处理用户需求

- **自动修复机制**：
  - 如果检测到响应开头没有模式标识，必须立即在开头补充
  - 补充格式：`# 模式：Plan\n\n`（根据实际模式调整）
  - 补充后，继续执行后续步骤

### 首次响应特殊要求（强制要求）

**核心原则**：首次响应（对话开始后的第一次响应）必须严格遵守以下特殊要求，确保规范从一开始就被正确执行。

**强制要求**：

1. **必须先输出模式标识**：
   - 在调用任何工具之前，必须先输出模式标识
   - 模式标识必须是响应内容的第一个非空行
   - 禁止先调用工具再输出模式标识

2. **需求类型识别**：
   - 在输出模式标识后，立即识别用户需求类型
   - 如果识别为"代码修改需求"，必须先输出完整方案，再调用任何工具
   - 如果识别为"查询需求"，可以调用只读工具

3. **代码修改需求的识别标准**：
   - 用户输入包含以下关键词，应视为"代码修改需求"：
     - **动作词**："修改"、"修复"、"添加"、"删除"、"实现"、"创建"、"更新"、"调整"、"优化"、"重构"、"改进"
     - **问题描述**："bug"、"错误"、"问题"、"漏洞"、"需要"、"应该"
   - 如果识别为代码修改需求，必须：
     1. 输出模式标识
     2. 输出完整方案（5个部分）
     3. 输出更新后的计划
     4. 等待用户输入"Act"
     5. 禁止在输出方案前调用任何工具（包括只读工具）

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

**示例**：

```
# ✅ 正确流程
用户：修改 sync.sh 脚本
AI（首次响应）：
  # 模式：Plan
  
  [识别为代码修改需求]
  [输出完整方案：需求分析、修改方案、影响分析、实施计划、风险评估]
  [输出更新后的计划]
  [提醒用户输入"Act"]

# ❌ 错误流程
用户：修改 sync.sh 脚本
AI（首次响应）：
  [直接调用 read_file 读取文件]  ❌ 错误：未先输出模式标识和方案
  [调用 codebase_search 搜索代码]  ❌ 错误：未先输出模式标识和方案
```

### 响应生成后检查机制（强化版）

**核心原则**：在响应生成后，必须强制验证响应是否符合规则要求，如果不符合，必须立即修复。

- **检查时机**：
  - **必须执行**：每次响应生成后，必须执行此检查
  - **不能跳过**：即使响应内容很长，也必须执行检查
  - **立即修复**：如果检查失败，必须立即补充缺失内容

- **检查内容**（必须逐项检查，不能跳过任何项）：

 1. **强制检查模式标识**（最高优先级，必须第一项检查）：
    - **检查位置**：响应内容的第一个非空行
    - **检查格式**：必须匹配以下正则表达式之一：
      - `^# 模式：Plan$`
      - `^# 模式：执行$`
    - **检查结果处理**：
      - ✅ **如果存在且格式正确**：继续下一项检查
      - ❌ **如果不存在或格式错误**：
        1. 立即在响应开头插入正确的模式标识
        2. 模式标识后添加一个空行
        3. 记录修复日志（可选）
    - **禁止的行为**：
      - ❌ 假设模式标识已存在而不检查
      - ❌ 检查失败后不修复
      - ❌ 将模式标识放在错误位置

 2. **检查执行顺序**：
    - 验证模式标识是否在开头
    - 验证后续步骤是否按顺序执行
    - 如果顺序错误，必须说明并修正

- **检查流程**（强制执行）：

 1. **响应生成后立即检查**：
    - 逐项执行所有检查项
    - 不能跳过任何检查项
    - 记录检查结果

 2. **检查失败处理**（强制修复）：
    - 如果模式标识缺失：立即在开头补充
    - 如果执行顺序错误：说明并修正
    - **修复后必须验证**：修复后再次检查，确保所有项都通过

 3. **检查通过确认**：
    - 所有检查项都通过后，响应才算完成
    - 如果任何项未通过，必须继续修复直到通过

- **禁止的行为**：
  - ❌ 跳过检查直接输出响应
  - ❌ 检查失败后不修复
  - ❌ 假设检查项已满足而不检查
  - ❌ 只检查部分项而跳过其他项

### 响应格式优先级

1. **标准响应**：模式标识 → 处理用户需求（工具调用时执行检查） → 更新后的计划
2. 如果用户有明确要求（如"输出方案"、"列出节点"等），优先满足用户要求
3. 在满足用户要求后，再输出更新后的计划（用分隔线"---"区分）
4. 如果响应内容较长，可以将计划放在最后，用分隔线区分
5. 如果用户要求的内容本身就是计划的一部分，可以合并输出

---

## 任务进度表格规范

**核心原则**：在 Plan 模式下，应使用任务进度表格清晰展示当前任务的进度情况，让用户一目了然地了解任务状态。

### 使用场景

以下场景必须输出任务进度表格：

1. **多步骤任务**：任务包含 2 个以上明确步骤时
2. **复杂任务**：任务需要分阶段完成时
3. **任务更新**：任务状态发生变化时（如完成某个步骤）
4. **用户询问进度**：用户明确询问当前进度时
5. **阶段性汇报**：完成重要阶段后的总结汇报

### 表格格式要求

**标准格式**：

```markdown
## 当前任务进度

| 任务 | 状态 |
|------|------|
| ✅ 任务1名称 | 已完成 |
| ✅ 任务2名称 | 已完成 |
| 🔄 任务3名称 | 进行中 |
| ⏳ 任务4名称 | 等待中 |
| ⏳ 任务5名称 | 未开始 |
```

**格式要求**：

1. **表格标题**：使用二级标题 `## 当前任务进度`
2. **表格列**：必须包含"任务"和"状态"两列
3. **任务列**：
   - 使用状态图标前缀（✅、🔄、⏳）
   - 任务名称应清晰简洁，不超过 30 字
   - 任务顺序应按执行顺序排列
4. **状态列**：
   - 必须使用明确的状态文字（已完成、进行中、等待中、未开始）
   - 状态应与图标一致

### 状态标识符说明

| 图标 | 状态文字 | 含义 | 使用场景 |
|------|---------|------|---------|
| ✅ | 已完成 | 任务已完成 | 任务完成后 |
| 🔄 | 进行中 | 任务正在执行 | 任务执行中 |
| ⏳ | 等待中 | 任务等待执行 | 任务等待用户确认或前置任务完成 |
| ⏳ | 未开始 | 任务尚未开始 | 任务还未开始执行 |
| ❌ | 已取消 | 任务已取消 | 用户取消任务或任务不再需要执行 |
| ⚠️ | 出现问题 | 任务执行出现问题 | 任务执行遇到错误或需要用户介入 |

**重要原则**：

1. **状态唯一**：每个任务同时只能有一个状态
2. **状态转换**：状态转换应遵循逻辑顺序（未开始 → 等待中 → 进行中 → 已完成）
3. **状态更新**：任务状态变化时，必须及时更新表格
4. **状态说明**：如果任务状态需要特殊说明，在状态列添加备注

### 表格更新规则

1. **实时更新**：
   - 任务状态变化时，必须立即更新表格
   - 新增任务时，添加到表格末尾或相应位置
   - 完成任务时，更新状态为"已完成"

2. **更新时机**：
   - **任务开始前**：输出初始任务表格
   - **任务进行中**：完成每个步骤后更新表格
   - **任务完成后**：输出最终任务表格
   - **用户询问时**：随时输出当前任务表格

3. **更新位置**：
   - 在响应开头（模式标识后）输出任务进度表格
   - 或在响应末尾（计划部分）输出任务进度表格
   - 使用分隔线区分表格和其他内容

### 完整示例

**示例1：多步骤任务**

```markdown
# 模式：Plan

## 当前任务进度

| 任务 | 状态 |
|------|------|
| ✅ 理解用户需求 | 已完成 |
| ✅ 分析现有代码 | 已完成 |
| 🔄 制定修改方案 | 进行中 |
| ⏳ 输出实施计划 | 等待中 |
| ⏳ 等待用户确认 | 未开始 |

---

[详细的响应内容]

---

## 更新后的计划

[计划内容]
```

**示例2：阶段性汇报**

```markdown
# 模式：Plan

## 当前任务进度

| 任务 | 状态 |
|------|------|
| ✅ 第一阶段：架构搭建 | 已完成 |
| ✅ 第二阶段：公共模块提取 | 已完成 |
| ✅ 第三阶段：插件系统实现 | 已完成 |
| 🔄 第四阶段：迁移现有上报器 | 进行中 |
| ⏳ 第五阶段：实现 ARMS 插件 | 等待中 |
| ⏳ 第六阶段：测试和文档 | 未开始 |

---

[阶段性汇报内容]
```

**示例3：任务出现问题**

```markdown
# 模式：Plan

## 当前任务进度

| 任务 | 状态 |
|------|------|
| ✅ 读取配置文件 | 已完成 |
| ⚠️ 解析配置内容 | 出现问题（配置格式错误） |
| ⏳ 应用配置 | 等待中 |

---

[问题说明和解决方案]
```

### 注意事项

1. **强制要求**：多步骤任务必须使用任务进度表格
2. **一致性**：同一任务的表格格式应保持一致
3. **及时更新**：任务状态变化时，必须及时更新表格
4. **清晰表达**：任务名称应清晰表达任务内容，避免模糊表述
5. **状态准确**：任务状态应准确反映实际情况，不夸大不缩小