计划工坊

解决什么问题

像 Vue 升级、需求上线、系统迁移这类任务，约束条件分散在团队经验、现有代码和排期里，很难在一轮对话里表达完整。如果直接让模型"写个方案"，通常会得到一份看似完整、实际缺少关键决策点的大纲：技术选型没比较，资源和时间没对齐，风险要么被忽略，要么只是列一串"需要注意"。

plan-workshop 不替你执行迁移或上线，也不生成可跑的脚本。它把规划本身当成主任务，通过交互式拆解和多维验证，产出可追溯的多文件计划目录，减少做到一半才发现遗漏的情况。

如何工作

核心流程是两级拆解：先拆出阶段，再在每个阶段里拆出步骤。每一轮拆解不会一次性给出全量计划，而是先列出本轮需要用户拍板的决策点，确认后再进入下一轮，直到覆盖全部范围。这样能避免模型凭经验补齐所有细节，也避免把尚未确认的假设写进最终计划。

拆解循环结束后进入六步验证：技术可行性、资源、时间、成本、风险、执行顺序。验证不通过时，技能会回到拆解或决策记录中沟通调整，而不是直接输出结论。所有中间状态都会落到文件中，包括每一步的状态、决策选择和遗留问题。

输出目录

最终交付物不是单条消息，而是当前工作目录下的任务目录。任务名称从用户输入中提取，目录内使用固定文件名：

• README.md：计划入口与概览
• plan.md：阶段到步骤的执行计划
• decisions.md 与 decision-log.md：关键决策及其记录
• status.md：进度与状态
• issues.md：遗留问题
• logs/：过程日志

若同名目录已存在，策略是追加更新，不覆盖已有内容；中断后可以用已有目录恢复上下文。

路由

用户说"帮我规划"、"拆解"、"生成计划"时走 W1，创建新计划；说"加载计划"、"继续计划"、"恢复计划"，且输入里包含已有计划目录名时走 W2，加载已有计划。路由判断基于是否包含目录名，创建和恢复不会混在一起。

适用边界

适合任务复杂度超出单轮对话能覆盖、且过程中会反复出现需要拍板决策点的场景。不适合简单任务，比如"帮我建个文件夹"，也不适合步骤已经完全确定、不需要验证的线性任务。

这是纯 LLM 驱动的交互式规划工具，不包含执行脚本。所有拆解、决策提取和验证都在对话中完成，文件写入通过 Write 工具执行。外部搜索只作为可选的技术调研补充，失败时会标注"信息待补充"，不阻塞流程。如果用户输入过于模糊，技能会先追问澄清，不会猜测；文件写入失败时会在对话中报错并提示检查磁盘空间。

人审终审是设计前提：拆解方向、决策选择和验证结果最终由用户确认。它降低的是规划遗漏和假设失控的风险，不是替代执行团队的判断。