PlanSuite

核心用法

PlanSuite 是一种文件驱动的项目管理方法论，将传统"边想边做"的混乱模式转化为可恢复、可审计的标准化流程。

三个阶段

• 计划阶段：在 task_plan.md 中拆解任务为子计划（里程碑），明确定义输入/输出、验收标准（DoD）、风险与回滚点
• 冻结阶段：用户确认后标记 STATUS: FINALIZED，建立变更控制基线，防止执行中随意改计划
• 执行阶段：建议用隔离会话运行，每完成子计划更新 progress.md（进度）和 findings.md（决策/坑点/验证命令）

关键约束

• 未 FINALIZED 不得进入执行（最多补充调研）
• 执行中计划不成立时，必须先记录到 findings.md，再提案变更，经用户确认后重新冻结
• 默认每个子计划设置检查点：执行前复述 DoD+风险+回滚，执行后给出验证步骤

显著优点

• 会话可恢复：进度写进文件，随时断点续跑
• 防止上下文污染：推荐隔离会话执行复杂子计划
• 变更可控：冻结机制强制暂停，避免"边做边改"导致的范围蔓延
• 知识沉淀：findings.md 形成项目记忆，减少重复踩坑

潜在局限

• 启动成本高：简单任务可能显得繁琐
• 依赖用户配合：冻结/变更控制需用户主动确认，流程可能阻塞
• 模板维护负担：多项目并行时需管理多组 task_plan/progress/findings 文件
• 无自动化集成：检查点、进度更新需手动执行

适合人群

• 需多会话协作的复杂项目（如多模块开发、调研报告、系统迁移）
• 对"可审计性"有要求的场景（需向第三方展示决策过程）
• 容易"跑偏"的用户或模型（结构化流程强制纠偏）

常规风险

• 文件冲突：多代理同时写入可能覆盖进度
• 冻结僵化：紧急修复时变更流程可能延误时机
• 模板误用：子计划拆分过细导致管理开销大于执行收益

核心用法

PlanSuite 是一套文件驱动的项目管理方法论 Skill，将传统敏捷/瀑布模型压缩为轻量级 Markdown 工作流。核心操作围绕三个文件展开：

• task_plan.md：计划主文档，包含背景目标、范围边界、风险回滚策略及可拆分的子计划（Milestones），每个子计划需定义输入输出、验收标准、预计工具调用和风险回滚点
• progress.md：执行追踪日志，维护 Done/Next/Blockers 状态机
• findings.md：知识沉淀库，记录关键决策、踩坑经验、验证命令和回滚步骤

标准流程遵循「0)初始化 → 1)计划拆解 → 2)冻结确认(FINALIZED) → 3)隔离执行 → 4)变更控制」五阶段闭环。关键约束在于未 FINALIZED 禁止进入执行阶段，防止目标漂移；执行阶段建议通过 sessions_spawn 开启隔离会话，避免主上下文污染。

显著优点

1. 状态机清晰：FINALIZED/DRAFT 双态机制强制变更审批，解决「边做边改」的失控问题
2. 可恢复性强：文件持久化设计支持跨会话续跑，聊天中断后可基于 progress.md 无损恢复
3. 知识留存：findings.md 强制沉淀踩坑记录，避免重复犯错，形成可复用的项目资产
4. 零外部依赖：纯 Markdown 模板，无运行时环境要求，跨平台零成本启动
5. 工具链友好：结构化的子计划定义可直接映射到 GitHub Issues/PR、Notion 看板等下游系统

潜在缺点与局限

• 交互负担重：轻量任务强制走四阶段流程可能显得冗余，适合 30 分钟以上复杂任务，不适合即时问答
• 缺乏可视化：纯文本进度追踪，对习惯看板/甘特图的用户不够直观
• 会话隔离成本：sessions_spawn 虽防污染，但增加了上下文切换成本和用户理解门槛
• 变更冻结僵化：小修小改也需走「findings → DRAFT → 用户确认 → FINALIZED」流程，可能拖慢迭代速度
• 模板字段理解成本：子计划字段（输入/输出/验收标准/预计工具调用）需一定项目管理经验才能填好

适合人群

• 多步骤复杂任务（代码重构、系统迁移、调研报告）的执行者
• 需要可审计交付物的团队场景（外包交付、研究项目、合规审计）
• 希望从 ChatGPT 对话中沉淀结构化项目资产的资深用户
• 对「计划-执行-复盘」方法论有认同感的项目经理型用户

常规风险

• 文件冲突：多会话同时读写三文件可能引发状态不一致，建议单会话独占执行
• 进度与计划脱节：执行中若跳过 findings.md 记录直接修改计划，会导致变更历史不可追溯
• 验收标准模糊：子计划 DoD 定义不清时，执行阶段易产生「做完了但不对」的返工
• 会话恢复遗漏：用户可能忘记基于 progress.md 状态续跑，导致重复执行或跳过步骤