| name | plan |
| description | 当用户要定技术方案、技术选型、架构设计，或 spec 需求规约完成后使用。基于需求产出 plan.md（技术栈/架构/接口/数据模型）。关键词：技术方案、架构、选型、plan、怎么做、设计。
|
plan — 技术方案（怎么做）
触发词
技术方案、架构、选型、plan、怎么做、设计、技术设计、模块划分、接口设计
概述
基于 spec.md 的需求，定技术实现方案：用什么技术栈、分几个模块、接口怎么设计、数据表长什么样。这一步才轮到技术。
SDD 四台阶的第 2 阶。产物存 .agents/specs/{feature}/plan.md。
何时该用
- spec.md 已对齐，需要定技术方案
- 已有 plan 但技术方案要调整
前置条件
.agents/specs/{feature}/spec.md 已存在且用户已确认- 若无 spec，先回 grill-me/spec，不要跳过需求直接定技术
工作流
1. 读 spec.md
完整读一遍需求规约，确认要解决什么问题。技术方案必须服务于需求，不是炫技。
2. 跑 7 级决策阶梯（见 coding_principles.md）
定方案前先问：
- 这功能不用做？→ 不做
- 代码库已有？→ 复用
- 标准库能做？→ 用
- 平台原生特性？→ 用
- 已装依赖能解决？→ 用
- 一行能写完？→ 写一行
- 才选新技术/写新代码
反模式：用户要个看板，agent 上来就"用 React + Node + Express + SQLite + Redis"。正确做法是先看项目里已有什么、标准库够不够。
3. 产出 plan.md
在 .agents/specs/{feature}/plan.md 写入：
# {功能名} 技术方案
## 技术栈
- 前端：{选型 + 理由}
- 后端：{选型 + 理由}
- 数据存储：{选型 + 理由}
- 关键依赖：{列出 + 为什么需要，每引一个新依赖要说明}
## 模块划分
- 模块 A：职责 / 对外接口
- 模块 B：职责 / 对外接口
## 接口设计
### 接口 1：{方法} {路径}
- 入参：
- 返回：
- 错误码：
## 数据模型
### 表/集合 1：{名称}
- 字段 | 类型 | 约束 | 说明
## 关键技术决策
- 决策 1：为什么选 X 不选 Y
- 决策 2：...
## 风险与对策
- 风险 1：... → 对策
4. 让用户过目
把 plan.md 路径告诉用户，请用户确认技术选型和架构。不认同的地方直接改。
5. 用户确认后，主动建议进 tasks
plan.md 已对齐。下一步建议进入 tasks 把方案拆成可执行的任务清单。要现在开始吗？
坑点清单（Gotchas）
- 没读 spec 就定方案：技术方案脱离需求 = 炫技。先读 spec。
- 不跑 7 级阶梯就引新依赖：项目已有/标准库能解决的，不要引新依赖。每引一个新依赖都要说清"为什么已有的不够"。
- 过度设计：用户要个内部小工具，agent 设计了微服务 + 消息队列 + 分布式缓存。YAGNI。
- 不写理由：技术选型只写"用 React"不写理由，用户无法判断是否合理。
- 接口设计不对照需求：接口没覆盖 spec 里的某个功能 = 漏了。
- 数据模型缺约束：字段没写类型/约束/索引，实现时全靠猜。
关键规则
- 必须先读 spec.md 再定方案。
- 必须为每个技术选型写理由（为什么选它、为什么不选替代）。
- 必须跑 7 级决策阶梯，优先复用已有/标准库/平台特性。
- 绝不引入需求没要求的功能（YAGNI）。
- 必须存到
.agents/specs/{feature}/plan.md。
- 必须让用户确认后才进 tasks。
参考
.agents/rules/coding_principles.md 第二章 7 级决策阶梯- 上游 skill：
spec（需求规约）
- 下游 skill：
tasks（任务拆解）
