痛点
你是否经历过这些崩溃时刻？
| 场景 | 结果 |
|---|
| Claude Code Plan Mode 上下文被压缩 | 辛辛苦苦梳理的需求全部丢失，ToDo 永远无法完成 |
| brainstorming + writing-plans 输出一大段计划 | 疯狂冲击上下文，导致计划、状态、验证混在一起，最后谁都不可信 |
| 长任务执行到一半会话中断 | 再次打开时完全不记得做到了哪里，一切从头开始 |
| 项目既有 UI 又有逻辑/存储/协议约束 | 如果没有统一收敛，需求和实现边界会持续互相污染 |
Plan-For-All 的核心不是“多写几个文档”，而是把需求收敛、界面细化、技术计划、执行分解与测试执行拆成 agent 可调度的阶段产物：
brainstorming 负责主管式需求收敛与最终设计契约ui-ux-pro-max 与 writing-plans 是同级阶段，由 brainstorming 调度（有 UI 时先 UI，后 Writing）step-decomposition 负责执行视图提取test-driven-development 负责执行阶段测试优先task_plan.md 负责唯一状态真源
核心思想
Plan-For-All 将大段任务拆解成可恢复的小计划，基于 task_plan.md 统一跟踪当前状态，让 计划是最新状态，让 上下文只承载当前步骤。
flowchart LR
subgraph Traditional[传统方式]
A[全部塞进上下文] --> B[压缩丢失 / 状态漂移]
end
subgraph PlanForAll[Plan-For-All]
C[计划写入磁盘] --> D[按需读取]
D --> E[task_plan 单点统筹]
end
工作流程（Agent 调度）
flowchart LR
subgraph P1[Phase 1: BRAINSTORMING]
A1[对接需求方] --> A2[逐个提问收敛]
A2 --> A3[方案比较与批准 + 写 design.md]
end
subgraph P2[Peer Stages Under Brainstorming]
B1[有 UI 需求?]
B1 -->|是| B2[ui-ux-pro-max 产出 UI 规格]
B1 -->|否| B3[直接进入 writing-plans]
B2 --> B3
B3 --> B4[detail_plan + task_plan.md]
end
subgraph P3[Phase 3: DECOMPOSE + EXECUTE]
C0[step-decomposition 生成 subplan] --> C1[按 subplan 执行]
C1 --> C2[TDD: 先失败测试后实现]
C2 --> C3[更新唯一状态源]
end
P1 --> P2 --> P3
当前版本原则
| 原则 | 说明 |
|---|
task_plan.md 是唯一状态真源 | 状态只在这里更新，findings.md / progress.md 不得夺权 |
| 先收敛，后计划 | brainstorming 先像产品经理一样对接客户，逐个提问、比较方案、收敛整体需求，再写 design doc |
brainstorming 负责整体需求 | 不强行按前端/后端拆思路，一体化项目也先整体收敛 |
ui-ux-pro-max 与 writing-plans 同级 | 都由 brainstorming 调度；有 UI 需求时先 UI 细化，再进入 writing-plans |
writing-plans 是实现交接 | 服务写代码的人/agent，并吸收 UI 阶段输出的界面约束 |
| 先冒烟，后实现 | 非 trivial 任务必须先定义 smoke check 或 failure reproduction |
| TDD 不能后移 | 不再把 TDD 当成“写完代码后提醒一下”的附属动作 |
step_subplan 是执行视图 | 它是对应 phase 的执行视图，并保持 detail plan 该 phase 的原文完整复制（verbatim） |
| Hook 保底护栏保留 | hook 继续负责会话恢复、上下文回放、TDD/验证提醒，但不替代正文约束 |
| 新名词默认强制检索 | 新名词、语义漂移术语、近期新范式默认先查；如果会影响下一问、方案比较或设计假设，必须先查再问，优先官方，无官方则限制查近期高质量来源 |
| Audit 全流程持续生效 | brainstorming / planning / subplan / execute / completion 任一阶段出现新风险词都要重新纳入审计 |
ui-ux-pro-max 的位置
ui-ux-pro-max 与 writing-plans 是 brainstorming 主管下的同级阶段。
它不负责需求收敛主流程，但在存在 UI 需求时必须先于 writing-plans 执行。
只有在下面这类情况下，它才会被 brainstorming 调用：
- 已经确认项目存在用户可见界面
- 页面结构、信息层级、交互质量或视觉质量会明显影响成败
- 用户明确要求界面风格、视觉方向、组件布局、设计系统或体验质量
它负责的是：
- 页面结构细化
- 信息层级细化
- 交互与视觉方向细化
- UI 风险与反模式识别
它不负责的是：
- 替代整体需求收敛
- 决定整个项目到底要做什么功能
- 决定是否拆前后端
- 拥有最终 design doc
用完以后，输出会并入 planning 输入，再进入 writing-plans。
当触发 UI 细化阶段时，必须落盘：
docs/plan-for-all/specs/YYYY-MM-DD-<topic>-ui-spec.md
使用示例
示例一：待办网站（Todo-Web with Login）
输入：
我想要一个待办网站，有登录功能。
自动发生的事：
[plan-for-all] 检测到新项目，进入 Phase 1: BRAINSTORMING
Q1: 这个待办网站是给自己用还是给别人用？
A: 个人使用 / B: 团队协作 / C: 公开访问
后续 brainstorming 会继续逐个提问，收敛：
- goals
- non-goals
- 用户流程
- 页面/模块
- 功能边界
- 约束与验收标准
如果在整体需求已经收敛后，发现这个项目确实需要专门的界面设计细化，brainstorming 才会调用 ui-ux-pro-max 补充：
- 信息层级
- 页面结构
- 交互模型
- 设计方向
- UI 风险与反模式
然后由 brainstorming 统筹把 UI 输出合并到 planning 输入，再交给 writing-plans。
示例二：本地 API Proxy / 中转服务
输入：
帮我规划一个本地 API proxy，把不同 provider 路由到统一入口。
自动发生的事：
Phase 1: AI 先核验协议/兼容性等高风险外部事实
-> 再整体收敛问题定义、协议边界、配置契约、验收标准
-> 写出 design contract
这类项目没有需要专门细化的用户界面，因此：
跳过 ui-ux-pro-max
直接进入 Phase 2: WRITING PLANS
示例三：一体化本地小项目
输入：
我想做一个本地知识库工具，有搜索、标签、笔记编辑和本地存储。
自动发生的事：
Phase 1: AI 先整体收敛用户流程、界面需求、数据存储、搜索行为、编辑功能和本地边界
-> 不强行拆成前端阶段 / 后端阶段
如果收敛后发现需要专门细化界面层，才局部调用 ui-ux-pro-max。否则直接写 design doc，再进入 writing-plans。
文件说明
