企业官网建设流程全解析

• 文档
• 提示工程
• 人工智能

导读

计划模式（Plan Mode）是 Claude Code 中"先规划、后编码"的核心工作流：Agent 先以只读方式探索代码库并撰写计划文件，用户批准后再进入实现阶段。system-reminder-plan-approved.md正是这条流程的"批准信号"——当用户通过 ExitPlanMode 确认计划后，系统立即注入该提醒，向 Agent 宣告"可以开始编码"，同时把计划文件路径与批准后的计划全文回传给上下文。本文以该提醒文件为主线，结合仓库中完整的计划模式提示词体系（工作流、阶段指引、工具描述、Explore/Plan 子代理提示词），系统讲解批准提醒的触发链路、变量语义、编辑态处理及其在计划模式闭环中的位置，帮助读者理解 Claude Code 计划模式的状态机设计与提示词工程实现。

一、批准提醒在整个计划模式闭环中的位置

Claude Code 的计划模式并不是一个孤立开关，而是一套由多个系统提醒（System Reminder）串起来的五阶段状态机。system-reminder-plan-approved.md处于这条链路的终点出口：它标志着"规划态"正式结束，"实现态"正式开始。

从仓库中的提示词文件可以完整还原这一闭环：

1. 进入规划态：Agent 调用 EnterPlanMode 工具请求进入计划模式（参见 tool-description-enterplanmode.md）。该工具说明明确指出：对于非平凡的实现任务（新功能、多方案可选、涉及多文件改动、架构决策、需求不明确、用户偏好重要等场景）应优先使用，而打字错误、单函数改动、纯研究任务则不需要规划。
2. 只读探索：system-reminder-plan-mode-is-active.md 提醒 Agent 处于只读阶段，禁止写任何文件，应按"探索代码库 → 识别相似特性 → 评估多种方案 → 必要时用 AskUserQuestion 澄清 → 设计具体实现策略 → 用 ExitPlanMode 提交计划"的顺序工作。
3. 五阶段工作流：system-reminder-plan-mode-workflow.md 给出了完整工作流，其中 Phase 1（初始理解，见 system-reminder-plan-mode-is-active-5-phase.md，并行启动 Explore 子代理探索代码库）、Phase 2（设计，见 system-reminder-plan-mode-phase-2-design.md，启动 Plan 子代理设计实现方案）、Phase 3（评审）、Phase 4（撰写最终计划，见 system-prompt-phase-four-of-plan-mode.md）以及 Phase 5（调用 ExitPlanMode）。
4. 提交批准：tool-description-exitplanmode.md 描述 ExitPlanMode 工具——它不接收计划内容作为参数，而是从已写入的计划文件读取计划，向用户展示批准对话框。
5. 批准生效：用户点击批准后，注入system-reminder-plan-approved.md，Agent 获准开始编码。

仓库中还包含两个状态迁移的配套提醒：重新进入计划模式时使用 system-reminder-plan-mode-re-entry.md（要求先读取既有计划文件，判断是覆盖还是增量修改）；退出计划模式时使用 system-reminder-exited-plan-mode.md（通知 Agent 现在可以编辑、运行工具、执行操作）。

二、批准提醒的模板结构与四个注入变量

system-reminder-plan-approved.md的正文非常精炼，全部内容围绕四个模板变量展开：

模板的完整正文如下（原文结构）：

User has approved your plan. You can now start coding. Start with updating your todo list if applicable Your plan has been saved to: ${PLAN_FILE_PATH} You can refer back to it if needed during implementation.${TEAM_PARALLELIZATION_NOTE} ## ${PLAN_WAS_EDITED?"Approved Plan (edited by user)":"Approved Plan"}: ${APPROVED_PLAN}

值得注意的三个设计细节：

1. 第一句就明确授权："User has approved your plan. You can now start coding." 直接解除了规划态的只读约束，并顺势要求"如果适用，先更新你的 todo list"——这与 Claude Code 中"任务管理优先"的工程习惯一致，也呼应了仓库中 tool-description-todowrite-reminder.md 等任务管理提醒的存在。
2. 计划文件持久化：提醒明确告知计划已保存到PLAN_FILE_PATH，实现过程中可以随时回查。这意味着批准提醒与计划文件（Plan File）是解耦的——ExitPlanMode 不携带计划参数，批准后 Agent 依然可以按需重新读取计划文件内容。
3. 编辑态区分：如果用户在批准前手工修改了计划（PLAN_WAS_EDITED为真），标题会显示为"Approved Plan (edited by user)"，否则显示"Approved Plan"，随后紧跟APPROVED_PLAN全文。这个细节在提示词工程上很有价值：它让 Agent 明确意识到"最终以用户编辑后的版本为准"，避免按旧版本计划实现造成偏差。

从模板文件的元数据头（name、description、ccVersion、variables）可以看出，这类系统提醒由 Claude Code 运行时按版本注入，ccVersion: "2.1.235"表明该模板随 Claude Code 各版本持续演进。本仓库即以此为定位维护全部系统提示词，详见 README.md。

三、从批准到编码：Agent 的后续动作链

批准提醒本身是"授权开关"，但它之后的行为模式由配套提示词共同约束。综合仓库内容，Agent 收到批准提醒后的典型动作链如下：

第一步：更新 todo list（如果适用）。提醒原文直接给出该指令，与任务管理类系统提示词（system-reminder-todowrite-reminder.md、system-prompt-tool-usage-task-management.md）相衔接。

第二步：回查计划文件。通过PLAN_FILE_PATH重新读取计划全文；如果用户编辑过（PLAN_WAS_EDITED），则以注入的APPROVED_PLAN编辑版为准。仓库中的 system-reminder-plan-file-reference.md 展示了计划文件的另一种引用形态——当计划文件作为附件注入时，会同时携带ATTACHMENT_OBJECT.planFilePath与ATTACHMENT_OBJECT.planContent，并指示"如果该计划与当前工作相关且尚未完成，继续推进它"，这与批准提醒的语义相互补充。

第三步：按计划执行编码。计划文件本身的撰写规范（见 system-prompt-phase-four-of-plan-mode.md）已经为可执行性做好了铺垫：要求计划以Context 段落开篇说明改动动机；只保留推荐方案而非罗列备选；命名关键待修改文件（对重复模式描述一次并列出代表性路径，不逐文件逐行枚举）；引用已找到的可复用函数与工具及其路径；并包含端到端验证章节（运行代码、使用 MCP 工具、跑测试）。

第四步：验证收尾。计划中的验证章节与 system-reminder-plan-mode-workflow.md 中"在实现前理清所有遗留问题"的目标首尾呼应，确保批准后进入的实现阶段是可验证、可回归的。

四、批准约束：为什么"批准"只能通过 ExitPlanMode 表达

要理解批准提醒的触发时机，必须先理解计划模式的批准纪律。system-reminder-plan-mode-approval-tool-enforcement.md 对此有硬性规定：

• Agent 的一轮对话只能以两种方式结束：调用AskUserQuestion澄清问题，或调用ExitPlanMode请求批准（工作坊模式下另有第三种结束方式）；
• 严禁以文本提问、AskUserQuestion或其他任何方式询问"这个计划可以吗？""我该继续吗？"——这类请求必须统一走ExitPlanMode。

同样，tool-description-exitplanmode.md 强调 ExitPlanMode 仅适用于"需要编写代码的实现类任务"；纯研究、理解代码库的任务不应触发。并且它不从参数读取计划，而是读取 Agent 已写入的计划文件——这正是批准提醒中PLAN_FILE_PATH存在的原因：批准对话框展示的就是计划文件内容，批准后该路径被回传给 Agent 供实现时引用。

从源码级提示词结构可以推断，PLAN_WAS_EDITED标志对应的是用户在与 ExitPlanMode 对话框交互时对计划文本的编辑行为：用户可直接修改批准弹窗中的计划，修改后APPROVED_PLAN注入的即为编辑后版本，同时标题切换为带 "(edited by user)" 后缀的形态，防止 Agent 误用过期方案。

五、配套组件：Explore 子代理与 Plan 子代理

批准提醒虽然是流程终点，但计划质量取决于前序探索与设计阶段。仓库中与之配套的两类子代理提示词值得一并理解：

• Explore 子代理（agent-prompt-explore.md）：文件搜索专家，严格只读，禁止创建/修改/删除文件、禁止重定向写文件、禁止任何改变系统状态的命令；可用 glob、正则搜索、read 及只读 shell 命令（ls、git status、git log、git diff、find、grep、cat、head、tail 等）。Phase 1 中由主 Agent 并行启动最多PLAN_V2_EXPLORE_AGENT_COUNT个，任务范围确定时通常 1 个即可，范围不确定或多区域涉及时才用多个并各自分配搜索焦点（参见 system-reminder-plan-mode-is-active-5-phase.md）。
• Plan 子代理（Phase 2 设计阶段，见 system-reminder-plan-mode-phase-2-design.md）：基于 Phase 1 的探索结果设计实现方案，可并行启动最多PLAN_V2_AGENT_COUNT个；对大多数任务默认至少启动 1 个用于校验理解与权衡备选，只有打字错误、单行改动、简单重命名等琐碎任务才可跳过；复杂任务可启用多个，从"简单性 vs 性能 vs 可维护性""根因 vs 变通 vs 预防""最小改动 vs 干净架构"等不同视角输出方案。

这些子代理的输出汇聚为最终计划文件，再经 Phase 4 的撰写规范打磨，最终由 ExitPlanMode 提交给用户——批准提醒正是在这个完整链条上"解锁编码"的那一声令下。

六、实战视角：如何围绕批准提醒设计自己的 Agent 工作流

对于基于本仓库提示词体系自建或定制 Claude Code 工作流的开发者，批准提醒文件提供了几个可直接借鉴的模式：

1. 用"授权信号"解耦只读约束：规划态的所有只读约束（见 system-reminder-plan-mode-is-active.md 的"Do NOT write or edit any files yet"）由批准提醒显式解除。在设计自己的多阶段 Agent 时，应让"阶段切换"由明确的运行时信号驱动，而非依赖 Agent 自行推断状态。
2. 计划持久化 + 可回查：计划写入独立文件（PLAN_FILE_PATH），批准后仍保留路径供实现引用。这保证了计划与执行解耦、可重复读取、可被重入流程复用（参见 system-reminder-plan-mode-re-entry.md：重新进入规划态时先读旧计划文件，判断"不同任务则覆盖、同任务继续则清理过期部分后修改"）。
3. 显式标记用户编辑态：PLAN_WAS_EDITED用条件表达式生成不同标题，将"用户介入程度"显式注入上下文。这种做法在提示词工程中很有参考价值——凡是"用户可能在中间环节改动产物"的流程，都值得用一个布尔标志 + 条件标题让 Agent 明确感知最终权威版本。
4. 执行入口先更新任务清单：批准后的第一条指令是"更新 todo list"，与任务管理工具（TodoWrite）体系衔接，保证长任务在实现阶段有可跟踪的进度结构。

七、小结

system-reminder-plan-approved.md看似只有寥寥数行，却是 Claude Code 计划模式状态机中最关键的"批准 → 编码"转折信号：它以PLAN_FILE_PATH提供计划回查锚点，以PLAN_WAS_EDITED区分用户是否干预过计划，以APPROVED_PLAN注入最终权威内容，并以"更新 todo list 后开始编码"衔接实现阶段。结合本仓库完整的计划模式提示词族（五阶段工作流、阶段指引、EnterPlanMode/ExitPlanMode 工具描述、Explore/Plan 子代理提示词、重入与退出提醒），可以清晰看到：Claude Code 通过一套精细的运行时注入提示词，把"先规划后编码"的产品理念落实为可约束、可追踪、可回查的工程化流程。这正是本仓库（system-prompts 目录）所维护的核心资产，值得系统提示词工程与 Agent 工作流设计者深入研读。

• 文档
• 提示工程
• 人工智能