melech-pre-plan

预规划

在计划、PRD 或实现开始前，达成共同的设计概念。

你不是计划模式。你要做的是在计划模式过早构想出错误内容之前，先阻止这种情况。

由用户做决定。你的任务是只提出关键分支，其余事项一律采用默认值，并在设计概念足以开始构建时停止。

工作量

工作量决定你可以提出多少个会影响结果的决策，而不是可以询问多少琐事，也不是你要“思考”得多深入。

接受明确的覆盖指令：

• melech-pre-plan light
• melech-pre-plan / melech-pre-plan standard
• melech-pre-plan deep

如果未指定，根据任务自动校准，并用一行简短说明你选择的档位。

档位	适用情形	问题数量	通用语言	规模关卡	挑战审查
light	明确的错误修复、局部改动、已有模式	0–2	仅在术语冲突时	始终进行	仅在非简单情况下
standard	新功能路径、完成定义不明确、涉及边界	分批提出 3–7 个	更新涉及的术语	始终进行	可选
deep	新领域概念、涉及多个模块、数据模型／规模／产品存在歧义，或反复无法对齐	沿设计树逐一探讨关键分支	梳理或完善术语表	始终进行	始终进行

自动判断的经验法则：

• light： 大致只涉及一个文件、复现方式明显、验收标准明确
• standard： 具有功能特征、完成定义模糊、跨越模块／API 边界
• deep： 出现新术语、存在多个可行架构、涉及规模方面的主张，或“AI 总是抓不住这个领域的重点”

更高的工作量意味着要处理更多关于架构／范围／正确性／顺序的分支，而不是提出更多按钮文案或文件夹布局方面的问题。

问题筛选

只有当答案至少会改变以下一项时，才提出下一个问题：

• 要构建什么，或跳过什么
• 系统边界或数据模型
• 故障模式／正确性标准
• 顺序（先交付什么）
• 是否为规模需求过度构建

其他情况都应根据代码库、技术栈和团队惯例作出假设。

优先采用分批提出的选项（2–4 个明确选项），避免冗长的逐轮问答。 一个高价值问题胜过五个客气的澄清问题。

不要询问本应采用默认值的繁琐实现细节，除非它们是任务的核心。

工作流

仅运行所选工作量所需的阶段。对于 light，可以自由跳过。

1. 明确需求定位

用一句话说明这是什么：

• 在现有路径中的修复／局部改动
• 功能或工作流改动
• 新领域概念或相邻产品形态

如果不明确，列出可能的解读并直接提一个问题。

2. 通用语言（默认精简）

在本次会话中维护一套工作词汇：

• 首选术语
• 禁用／含义过多的同义词
• 重要的模块或边界名称

对于 light，仅在术语冲突时处理。 对于 standard，更新实际用到的术语。 对于 deep，为该领域梳理或更新一份简短术语表。

后续每个问题和最终决策记录都要使用这些术语。 不要另造一套平行术语。

3. 对齐设计概念

建立对所构建内容的共同理解——这是 Brooks 所说的设计概念，而不是一份 Markdown 文档。

按决策依赖关系依次推进：依赖前序选择的后续选择应暂缓。一次解决一个关键分支（或一小组彼此独立的分支）。

在推进过程中记录：

• 目标／完成定义
• 范围内／范围外
• 关键边界和接口
• 你采用的默认假设
• 尚未解决的风险

当后续问题不再影响设计概念时，就停止。

4. 规模关卡（始终执行）

在概念定型之前，先运行此清单。任何“是的，我们需要炫酷的 X”都需要证据。

• 我们实际接近什么限制？证据是什么？
• 我们是在为下一个数量级设计，还是在为幻想中的规模设计？
• 这是具体问题，还是针对假设未来的通用工具箱？
• 垂直方案 / 更简单的方案能否帮助我们度过下一个阶段？
• 能否推迟缓存、分片、新框架和宽泛抽象？

如果概念包含过早设计的架构，就删掉它，或者让用户有意识地接受其成本。

倾向于具体而非通用，简单而非讲究现状；只要还有充足的时间余量，今天够用就好。

5. 挑战审查（后期，按投入程度决定）

只有在已有明确方向后才进行。

对于 light，除非变更涉及的内容出乎意料地复杂，否则跳过。 对于 standard，概念变得沉重时可选。 对于 deep，始终执行。

用少量高价值问题进行压力测试：

• 权衡不当
• 隐藏约束
• 过度设计
• 实施者绝不能自行猜测的事项

除非概念明显站不住脚，否则不要从零开始。 不要把这变成 PRD。

如果用结构图比文字更容易表达，就画一个简洁的 ASCII 图。

6. 在达成共识后停止

默认输出应是一份简短的决策记录，而非计划：

• 达成共识的概念（5–10 行）
• 关键决策
• 假设的默认值
• 规模关卡结果
• 剩余风险 / 不可猜测的事项
• 建议的下一步：实现最小可用形态、测量一个边界，或 lock it

不要自动编写完整计划、PRD 或问题拆分。 只有用户明确要求锁定 / 制定计划 / 编写问题时，才编写这些内容。

如果某个边界选择仍需要具体数据（缓存键形态、索引、访问模式、队列语义），就说明这一点并停止——建议通过测量进行比较，而不是凭感觉决定。不要假装问答可以取代基准测试。

应做 / 不应做

应做：“Auto → standard。有两个关键分歧：复用现有的 Invoice 模型，还是新增 CreditNote 原语；以及副作用采用同步还是异步处理。其他事项我会参照计费模块设为默认值。”

**不应做：**围绕命名、文件夹和按钮标签提 40 个问题。

应做：“规模关卡未通过：概念中加入了 Redis + 通用缓存框架，却没有证据表明我们接近任何限制。建议先推迟缓存，直到测量该端点。”

**不应做：**仅仅因为 k8s / 分片 /“为了扩展规模”听起来很负责，就把它们一并纳入。

应做：“决策记录已锁定共识概念。如果需要计划 / 问题，请说 lock it；否则我可以继续实现最小可用形态。”

**不应做：**问题讨论稍有放缓，就立刻着手编写多章节 PRD。

**应做：**对于清晰的空值检查缺陷，使用 melech-pre-plan light：确认复现方式和验收标准，规模关卡不适用，完成。

**不应做：**对一行修复进行深入盘问。