plan

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）

定方案前先问：

1. 这功能不用做？→ 不做
2. 代码库已有？→ 复用
3. 标准库能做？→ 用
4. 平台原生特性？→ 用
5. 已装依赖能解决？→ 用
6. 一行能写完？→ 写一行
7. 才选新技术/写新代码

反模式：用户要个看板，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（任务拆解）