plan-work

规划工作

目标

制定的计划应：

• 立足于代码仓库的实际情况（调研）
• 明确决策和风险（分析）
• 不留任何未解决的问题（实施步骤前先进行问答）

需要询问的输入（如缺失）

• 预期结果／验收标准（怎样才算“完成”）。
• 限制条件：时间、向后兼容性、性能、安全性、数据迁移。
• 目标环境：本地／预发布／生产；是否需要功能标志或分阶段发布。
• 非目标（不需要做什么）。

工作流程（调研 -> 分析 -> 问答 -> 实施）

1. 调研（当前状态）
   • 先阅读代码仓库指南：AGENTS.md、README.md、docs/（仅在需要时）。
   • 确认入口点和负责人（后端／前端／基础设施）。
   • 查找相关代码路径和模式：
     • 使用 rg 搜索符号、端点、配置键、错误字符串
     • 不确定时，使用 git log -p / git blame 查看历史记录和意图
   • 如果计划依赖外部行为（框架／库／工具），请查阅官方文档、发行说明或 context7（并说明版本／假设）。
   • 用简短要点记录发现，并附上文件路径。
2. 分析（要改什么以及为什么）
   • 重述需求和假设。
   • 列出备选方案（1-3 个）及其权衡；选择一个并说明理由。
   • 识别风险／边界情况，以及用于覆盖这些情况的测试。
   • 汇总未解决的问题。
3. 问答关卡（不可跳过）
   • 如果存在未解决的问题，请先提问并暂停。
   • 在用户回答（或明确接受假设）之前，不要提出实施步骤。
   • 首轮提问：提出 1-5 个问题，以排除整类工作分支。
   • 总问题数不必限制为 1-5 个；继续提问，直到制定妥当实施计划所需的信息全部明确。
   • 问题应便于快速浏览：编号、简短，尽可能采用选择题。
   • 提供默认值／建议以及快速回复方式（例如回复“defaults”）。
     • 不要在选项列表中将任何选项标为默认值；如有需要，请在单独的说明中列出默认值。
   • 有助于降低回答难度时，可提供“还不确定”选项。
   • 主要利弊明显时，可在选项后添加简短的方括号说明。
   • 能减少回答负担时，将问题分为“必须了解”和“可选了解”。
   • 选项应便于简短作答（例如“1b 2a 3c”），并用通俗语言重述所选内容。
   • 收到必要回答前暂停：
     • 不要运行命令、编辑文件，也不要制定依赖未知信息的计划。
     • 允许进行低风险调研，但不得因此确定方向（只读、不做承诺）。
   • 收到回答后，用 1-3 句话重述需求（限制条件 + 成功标准），然后继续。
4. 实施计划（仅限完成问答后）
   • 按合理顺序拆分为小步骤。
   • 指明可能需要修改的文件／目录。
   • 列出验证变更所需运行的测试（单元／集成／构建）。
   • 如果变更涉及多个模块，请列出协调步骤（契约变更、客户端重新生成、版本管理）。

问答模板（简短功能计划）

开始前，我需要了解：（1）问题（2）问题（3）问题。 以下是初始问题；我会继续追问，直到制定妥当的实施计划所需信息全部明确。

必须了解 1) a) b) c) 2) a) b) c) 3) C a) b) c) d)

可选了解 4) a) b) c)

请回复：“1a 2b 3c 4a”（或回复“propose”，让我选择并请你确认）。

交付物

使用 references/plan-template.md 并填写。