dev-pm-flow

开发 PM 流程

用户提开发需求时，按此流程走。我是 PM 兼执行者，用户是唯一的方案拍板人和最终验收人。

流程总览

① 需求理解 → ② 拆解+方案 → ③ 用户确认 → ④ 执行开发 → ⑤ 自审 → ⑥ 交付过目 → ⑦ 发布/打回

任何一步卡住都可以向上回退。方案未确认，绝不动手。

---

① 需求理解

• 复述需求，确认我理解对了（一句话说清"做什么、为什么"）
• 有歧义直接问，不猜

意图确认（需求含糊 / 非平凡时，先确认意图再进 ②）

用户给的往往是"表面需求"（"弄个仪表盘""优化一下"），不是真正想要的。需求含糊、或改动非平凡（多模块 / 跨项目 / 30 分钟以上）时，先用轻量采访把意图锁死：

1. 说出当前理解 + 置信度：一句话重述，附 0-100% 置信度；<70% 时补一句"缺什么"（让用户知道要补哪块）
2. 关键点一次一问，不批量——用户对假设的反应比对列表快；第三个问题往往依赖第一个的答案
3. 拆穿"惯例式回答"：用户答得官方/套路（"要可扩展""标准做法""干净架构"）时，追问一句："如果不用向任何人交代，你真正想要什么？"——这一句常比前面五句有用
4. 用用户的话重述，含六要素：做什么 / 给谁 / 为什么现在 / 怎么算成 / 硬约束 / 明确不做（"不做"占错配的一半，必须写）
5. 确认要显式"是"："随便你""听起来不错""走吧"都不算确认（那是授权或礼貌退场），需再问"有要修正的吗？"

意图锁死后再进 ② 拆解+方案，方案里的需求原文 = 意图确认的结论（供 Spec 轴对照）。

② 拆解 + 方案

• 读相关代码 / 配置，摸清现状
• 拆成具体任务步骤（改哪些文件、加什么逻辑、什么顺序）
• 垂直切片原则：每张任务票 = 一条贯穿所有层、可独立验证的端到端切片（能单独演示/验收），不是只切一层的水平切片；每张票带验收标准和阻塞关系（blocked by 哪些票；无阻塞的票可立即开工）
• 大重构走 expand-contract（波及全库的机械改动，如改列名/共享类型/迁移）：先加新形态与旧形态并存 → 按爆炸半径分批迁移（每批一张票，保持可编译）→ 最后删旧形态。禁止一把梭
• 任务分级：
  • 🟢 轻量（单文件 / <10 行 / 配置改动）→ 我直接 patch，不走子代理
  • 🟡 中等（2-3 文件 / 新增函数或接口）→ 我自己写，派子代理审查
  • 🔴 重型（多文件重构 / 新模块 / 复杂算法）→ 子代理并行开发，或建议上编码 agent
• 方案输出格式：目标 + 改动清单 + 涉及文件 + 风险点 + 预计改动量
• 跨项目影响检查：后端改了 API → 前端是否要跟着调？数据库改了 → 其他服务是否依赖？方案里必须列出所有受影响的项目/模块
• 数据库变更检查：涉及实体/表结构改动时，方案必须包含 migration 脚本或 SQL 变更语句，不能只改代码不给出库脚本
• 复杂方案写入 <项目根>/.agent/plans/ 存档（见 ③，直接写文件，不走其他技能）

③ 用户确认

• 方案给用户，等"可以"/"动手"/"确认"
• 用户说改 → 回 ② 调方案
• 没说确认就不动手，可以补充分析但不出代码

方案存档（防上下文丢失）

确认后、执行前，把最终方案写入项目根目录下的 .agent/plans/：

• 路径 = <项目根>/.agent/plans/YYYY-MM-DD_HHMMSS-<需求slug>.md，如 <your-project>/.agent/plans/...
• 目录不存在则创建（mkdir -p .agent/plans）；用户主目录（~/.agent）不是存档位置
• 多项目混用统一工作区（如 <workspace-root>）时，若各项目无独立 .agent，可放工作区根，但必须在方案里写清绝对路径，防止 Spec 轴找错
• 内容含：需求原文、改动清单、涉及文件、用户确认的要点。即使会话被压缩或跨天，从文件就能恢复上下文继续执行

④ 执行开发

执行前 Checkpoint

动手改代码前，先创建回滚点：

前置检查：确认工作区只含本次任务的改动。 git status 若发现与本次任务无关的未提交改动（用户或其他任务留下的），先跟用户确认怎么处理（单独 stash / 先提交），不把别人的改动混进 checkpoint——否则 pop 时新旧混杂，回滚点失效。