跳到主要内容

Spec-Driven Development（SDD）

06 Agentic Engineering 第 2.2 节强调"提前规划"。05 Parallel Agents 提到 "Architect → Implementor" 模式。本篇把这条线走深 —— AI 时代的开发流程，应该是"先写规范，再让 Agent 实现规范"。这是 GitHub、Anthropic 等公司在 2025-2026 年都在推的核心工作流。

学前说明​

软件工程里"规范驱动"不是新概念。瀑布、TDD、契约编程、DDD 都强调"先想清楚再写代码"。但实际工作中很少落地——因为人类工程师"想"和"写"是同时进行的，写边写边想成本最低。

这个等式被 AI Coding Agent 改变了：

  • 想清楚的成本没变（还是要花脑子）
  • 写代码的成本 ≈ 0（Agent 几分钟就出来）

平衡彻底改变。不想清楚的代价变得不可接受——你会让 Agent 飞速生产几千行错误的代码。

所以 2025-2026 年业界开始把"规范驱动开发"重新提上议程，但这次不是为了瀑布，而是为了和 Agent 高效协作。

GitHub 在 2025-2026 年推出了 Spec Kit，明确推 SDD（Spec-Driven Development）作为 AI 时代的标准工作流。

学习目标​

  • 理解 SDD 与传统规范驱动的区别
  • 掌握 SDD 的 4 阶段：Specify → Plan → Tasks → Implement
  • 写出 Agent 能高效执行的 spec.md
  • 应用 GitHub Spec Kit 的 /specify /plan /tasks 命令模式
  • 区分 Spec、Plan、Task 三个抽象层次
  • 建立团队级 SDD 规范

与现有知识的衔接​

  • 06 Agentic Engineering 第 2.2 节：提前规划（前置）
  • 05 第六章：Architect → Implementor 模式（前置）
  • 07 Agentic Loop：SDD 把"目标"做得更精确
  • 02 Skills 体系：Spec 可以变成可复用的 Skill

第一章：什么是 Spec-Driven Development​

1.1 简洁定义​

Spec-Driven Development（SDD）：在让 AI Agent 实现任何非平凡功能前，先用结构化文档明确需求、约束、验收标准，然后让 Agent 按这份文档实现。

最简单的形式：

你 → 想做 X
↓
你 → 写 spec.md（说清楚 X 是什么、不是什么、怎么验证）
↓
你 → review spec.md（自己想清楚）
↓
Agent → 按 spec.md 实现
↓
你 → 用 spec.md 的标准验收

1.2 与传统规范驱动的对比​

维度传统规范驱动（瀑布、TDD）Spec-Driven Development
编写者架构师 / 产品工程师自己（你写自己的 spec）
详细程度极详细（200 页 PRD）适度（半页到几页）
周期项目级（几周-几月）任务级（几小时-几天）
实现者工程师手写AI Agent 加速
修改频率改一次成本极高改 spec → 重新派 Agent，便宜
验收项目结束验收每次迭代验收

关键区别：SDD 不是"先想 3 周再写 3 月"，是"想 30 分钟，让 Agent 写 30 分钟"。

1.3 为什么 AI 时代它特别有效​

不写 spec 的代价：

  • AI 自己理解需求 → 50% 概率偏离你的真实意图
  • AI 写完后你才发现方向错了
  • 已经生成 800 行代码，回滚成本高
  • 你重新 prompt 解释，AI 再写 800 行
  • 循环 → 浪费时间和 token

写 spec 的收益：

  • 自己被迫想清楚（spec 的副作用）
  • review spec 比 review 代码快 10x
  • spec 改一句话，code 改 50 行
  • spec 是后续维护的活文档
  • 可以用来评估实现的"是否合规"

1.4 Spec、Plan、Task：三个抽象层次​

GitHub Spec Kit 明确区分三个层次：

SPEC（规范）：要做什么、为什么
  ↓
PLAN（计划）：怎么做、技术选型、架构
  ↓
TASKS（任务）：具体执行步骤
  ↓
IMPLEMENTATION（实现）：实际代码
层次内容谁写长度评审重点
Spec需求、约束、成功标准你 + AI 辅助1-3 页业务正确性
Plan技术方案、架构、依赖AI 起草 + 你审2-5 页技术合理性
Tasks步骤列表，每步可独立完成AI 拆分 + 你审1-2 页可执行性
Implementation代码Agent 执行看具体code review

每一层都是上一层的"展开"。改 Spec → 重生成 Plan → 重生成 Tasks → 重新执行。

第二章：SDD 的 4 阶段流程​

GitHub Spec Kit 把流程命名为 4 个 slash command：

2.1 阶段 1：Specify（明确做什么）​

目标：用结构化文档表达"我要的是什么"。

输入：你的模糊想法、用户故事、痛点。

输出：spec.md。

实战：

# 在 Claude Code / Cursor 里
> /specify

# Agent 会引导你填写：
> 这个 feature 解决什么用户问题？
> 涉及哪些用户角色？
> 关键的用户流程是什么？
> 边界 case 有哪些？
> 不在范围内的是什么？
> 成功的标准是什么？

模板：

# Spec: <Feature Name>

## 问题陈述
（一段话说清楚要解决什么问题）

## 用户故事
- 作为 <角色>，我想 <做什么>，以便 <达到什么目的>
- ...

## 关键流程

### 主流程
1. 用户...
2. 系统...
3. 用户...

### 异常流程
- 当 X 发生时，系统...

## 范围

### 包含
- 功能 A
- 功能 B

### 不包含
- 功能 C（下个版本）
- 功能 D（永久不做）

## 约束

### 性能
- 响应时间 < 200ms
- 支持 1000 并发

### 兼容性
- 必须支持 Safari 16+
- 必须兼容现有 API v2

### 安全
- 用户数据加密
- 操作有审计日志

## 验收标准

### 功能性
- [ ] 用户能完成主流程
- [ ] 异常流程有合理提示
- [ ] ...

### 质量
- [ ] 测试覆盖率 > 80%
- [ ] 无 P0 / P1 bug
- [ ] 文档完整

## 开放问题
- 问题 1（待和 X 确认）
- 问题 2（待数据验证）

关键原则：

  • Spec 不写"怎么实现"——那是 Plan 阶段的事
  • 每条都要可验证——不能写"用户体验好"
  • 明确"不做什么"和"做什么"一样重要

2.2 阶段 2：Plan（怎么实现）​

目标：基于 Spec，决定技术方案。

输入：spec.md。

输出：plan.md。

实战：

> /plan

# Agent 基于 spec.md 起草，回答：
> 用什么技术栈？
> 数据模型怎么设计？
> API 接口长什么样？
> 关键的算法/流程是什么？
> 依赖什么外部系统？
> 风险在哪？

模板：

# Plan: <Feature Name>

> 基于 [spec.md](./spec.md)

## 技术选型

### 前端
- 框架：现有 Next.js 14
- 状态管理：扩展现有 Zustand store
- UI：参考现有 Button/Modal 模式

### 后端
- 现有 NestJS API
- 新增 routes: POST /api/x, GET /api/x/:id
- 用现有 PostgreSQL，新增 1 张表

### 第三方
- 邮件：Resend（已集成）
- 文件存储：现有 S3

## 数据模型

### 新增表：feature_x
```sql
CREATE TABLE feature_x (
  id UUID PRIMARY KEY,
  user_id UUID REFERENCES users(id),
  status VARCHAR(20) NOT NULL,
  created_at TIMESTAMP DEFAULT NOW(),
  ...
);

修改：users 表加字段​

  • feature_x_enabled BOOLEAN DEFAULT false

API 设计​

POST /api/feature-x​

  • Request: { name: string, options: ... }
  • Response: { id: UUID, status: 'pending' }
  • Error: 400 if invalid input

GET /api/feature-x/:id​

  • ...

关键算法​

流程 A​

  1. 接收请求
  2. 验证用户权限（用现有 auth middleware）
  3. 写入 DB（事务保护）
  4. 异步发邮件（用现有 queue）
  5. 返回 ID

依赖​

  • pnpm add zod — 用于输入校验（如果还没有）
  • 修改 src/lib/email.ts — 加新模板

风险​

风险概率影响缓解
邮件发送失败中用户体验差加重试 + 死信队列
数据库锁竞争低性能加索引 + 用乐观锁

与 Spec 的对应​

Spec 验收点Plan 中如何实现
响应时间 < 200ms用现有缓存层；DB 加索引
1000 并发NestJS 默认够用；DB 连接池 50
......

**关键原则**：

- **Plan 必须能映射回 Spec 的每条要求**
- **Plan 暴露技术风险，让你知道哪里要小心**
- **Plan 不写代码，只描述"会写什么样的代码"**

### 2.3 阶段 3：Tasks（拆解执行步骤）

**目标**：把 Plan 拆成可执行的小任务。

**输入**：plan.md。

**输出**：tasks.md（或 issues 列表）。

**实战**：

```bash
> /tasks

# Agent 基于 plan.md 拆分，每个 task：
> - 独立可完成
> - 有明确验收
> - 大小适中（半天内完成）

模板：

# Tasks: <Feature Name>

> 基于 [plan.md](./plan.md)

## 任务列表

### Task 1: 创建数据库迁移
- 文件：`migrations/202606XX_add_feature_x.sql`
- 内容：plan.md "新增表 feature_x" 章节
- 验收：`pnpm db:migrate` 跑通；`pnpm db:rollback` 也能跑通
- 预计：30 分钟
- 依赖：无

### Task 2: 创建 schema 类型
- 文件：`src/types/feature-x.ts`
- 内容：从 DB schema 派生 TypeScript types
- 验收：`pnpm typecheck` 通过
- 预计：15 分钟
- 依赖：Task 1

### Task 3: 实现 POST /api/feature-x
- 文件：`src/api/feature-x/create.ts`
- 内容：plan.md "API 设计" 章节
- 验收：
  - 单元测试覆盖正常 + 异常 case
  - `pnpm test:api -- feature-x` 通过
  - 用 curl 手动验证一次
- 预计：2 小时
- 依赖：Task 1, 2

### Task 4: ...

## 执行策略

### 并行化
- Task 1, 2 必须串行
- Task 3, 4, 5 可以并行（不同模块）
- Task 6 必须等 3, 4, 5 完成

### 派发建议
- 推荐：Task 1, 2 自己手做（建立熟悉度）
- Task 3, 4 派给两个并行 Agent（参考 05）
- Task 5 (写测试) 用 TDD + AI 模式

### 完成判定
所有 task 都通过 + e2e 测试通过 + 部署 preview 验证 = 整个 feature done

关键原则：

  • 每个 task 半天内能完成——大了拆，太小了合
  • 每个 task 有明确入口、出口、验收
  • 明确依赖关系——便于并行
  • 派发建议——告诉自己/团队哪些适合 Agent、哪些自己做

2.4 阶段 4：Implement（执行）​

目标：让 Agent 按 task 实现。

输入：tasks.md 中的具体 task。

输出：代码 + PR。

实战：

# 派 Agent 做某个 task
> 请完成 tasks.md 中的 Task 3。
> 严格按 plan.md 中 "API 设计" 章节的接口规范。
> 完成后必须满足 task 描述的所有验收标准。
> 不要做 task 范围外的事（比如改其他文件）。

Agent 执行时：

  • 看 spec.md（理解为什么）
  • 看 plan.md（理解怎么做）
  • 看 tasks.md 中的具体 task（理解做哪一块）
  • 写代码、跑测试、迭代到验收通过

2.5 4 阶段的循环关系​

不是单向流，是循环：

每一层都可能让你回到上一层修订。这是好事——说明你及时发现了问题。

第三章：spec.md 的写作艺术​

3.1 好 spec 的 5 个特征​

1. 业务清晰，技术中立

✅ 好：用户能在 5 秒内找到他最近 30 天的订单
❌ 坏：实现一个 React 组件，用 useQuery 加载订单数据

Spec 是"做什么"，技术细节是 Plan。

2. 边界明确

## 范围
### 包含
- 浏览器登录
- 移动 web 登录

### 不包含
- iOS / Android 原生 App 登录（用现有 SDK）
- SSO / SAML（下个 quarter）
- 找回密码（独立 feature）

3. 验收可测

✅ 好：用户提交后 200ms 内看到响应
❌ 坏：响应要快

4. 明确"不做"

明确"不做"和明确"做"一样重要。它防止 Agent / 你自己在做的过程中范围蔓延。

5. 写下"你的犹豫"

## 开放问题
- 是否需要支持游客查看？倾向是不需要，但需要和 PM 确认
- 排序规则：按时间还是按相关度？数据不足，先按时间，后续 A/B 测试

把不确定的事写下来 = 让 Agent 不会乱猜。

3.2 spec.md 模板的取舍​

GitHub Spec Kit 提供完整模板，但实际用要根据任务大小裁剪：

任务大小spec.md 长度必有章节
小（一天以内）半页问题陈述、验收标准
中（2-5 天）1-2 页+ 用户故事、关键流程、约束
大（1-2 周）2-4 页+ 范围、风险、开放问题
巨（> 2 周）拆不应该有这种 task，先拆

原则：spec 不为了"详细"而详细。够用就行。

3.3 Spec 与 PRD 的关系​

很多团队已经有 PRD（Product Requirements Document）。SDD 的 spec.md 不是替代 PRD，是工程师视角的 PRD 翻译：

PRD（产品视角）:
- 商业目标、用户价值
- 优先级、roadmap
- UI mockup

spec.md（工程视角）:
- 技术上"做什么"、"不做什么"
- 验收标准（可测）
- 边界 case
- 性能/安全约束

PRD 不变，但每个工程任务必须写 spec.md。

3.4 用 AI 帮你写 spec​

矛盾的事：spec 是"AI 之前的事"，但 AI 也能帮你写 spec。怎么用：

你：我要做一个购物车 feature。用户能加商品、改数量、删除、结算。

Claude：好的，让我帮你起草 spec.md。我有几个澄清问题：
1. 是否支持游客购物车（未登录）？
2. 商品库存不足时如何提示？
3. 跨设备同步是否需要？
4. ...

你：[回答]

Claude：[输出 spec.md 草稿]

你：[review，改 30%]

AI 不是替你想，是逼你想——它问的每个问题都是你之前没想过的角落。

第四章：实战案例​

4.1 案例 1：小任务（半天）​

任务：给现有列表加排序功能。

spec.md（极简版）：

# Spec: 订单列表排序

## 问题
当前订单列表只能按时间倒序。用户反馈想按金额、状态排序。

## 验收
- [ ] 用户能选择排序字段（时间、金额、状态）
- [ ] 排序方向可切换（升/降）
- [ ] 切换排序时不重新加载页面（前端排序）
- [ ] 排序选择持久化到 URL（可分享、可刷新）
- [ ] 移动端布局合理

## 不做
- 服务端排序（数据量目前不大，前端够）
- 多字段排序（YAGNI）

plan.md（极简版）：

# Plan: 订单列表排序

## 实现位置
- 修改 `src/components/OrderList.tsx`
- 修改 `src/hooks/useOrderList.ts`（加 sort state）

## URL 同步
- 用 Next.js useRouter 读写 query：?sort=amount&order=desc
- 默认值：sort=createdAt, order=desc

## UI
- 列表头部加 dropdown 选择排序字段
- 升降序用 ↑↓ 图标按钮

## 风险
- 无（小改动）

tasks.md：

- [ ] Task 1: 修改 useOrderList hook，加 sort/order state + URL sync
- [ ] Task 2: 修改 OrderList 组件，加 dropdown UI
- [ ] Task 3: 写单元测试
- [ ] Task 4: 手动测三种 case（首次访问、URL 带参数、切换排序）

总耗时：写 spec/plan/tasks 30 分钟 + Agent 实现 1 小时 + review/合并 30 分钟 = 2 小时。

不写 spec 直接 prompt 的耗时：可能 1 小时但做错方向，重做 → 总共 3-4 小时。

4.2 案例 2：中等任务（3 天）​

任务：迁移用户认证从 cookie 到 JWT。

这种任务绝对不能没有 spec 直接做。

spec.md 重点：

# Spec: 认证机制迁移 cookie → JWT

## 为什么
- 当前 cookie 在跨域场景下问题多
- 团队决定统一用 JWT（其他 service 已经用了）
- 商业目标：支持 SDK 集成（cookie 不行）

## 范围
### 包含
- Web 主站
- Admin 后台
- API 调用

### 不包含
- 移动 App（已用 JWT）
- 第三方集成（用 OAuth）

## 兼容性
- 老用户必须无感升级（不要求重新登录）
- 必须支持 30 天过渡期（cookie + JWT 双轨）

## 安全要求
- JWT 必须用 RS256（不用 HS256）
- 必须实现 refresh token
- token 不能存 localStorage（用 httpOnly cookie 存 refresh）
- 必须实现 token revocation（黑名单或短期 access token）

## 验收
- [ ] 老用户不需要重新登录
- [ ] 新用户用 JWT 登录
- [ ] refresh token 流程正确
- [ ] revocation 在 5 分钟内生效
- [ ] 渗透测试通过

## 风险（高）
- 迁移期间登出大量用户 → 业务影响大
- 安全漏洞 → 公司危机

## 开放问题
- session storage：用 Redis？现有架构没有，要不要新增？
- token 长度：access 15 分钟还是 1 小时？需要 SRE 评估

注意：spec 已经标了"高风险"和"开放问题"。这个任务不应该派给 Agent 自主做——这是 architect 模式的场景，人类必须深度参与。

4.3 案例 3：什么时候不要 SDD​

不是所有任务都要 spec。下面这些直接做就好：

  • 修一个明确的 bug（看 issue 直接修）
  • 加一个 ESLint 规则
  • 升级依赖（除非 major）
  • 重命名变量
  • 写一个一次性脚本

判断：spec 写了 5 分钟还没说清问题 → 这事比你想的复杂，应该写 spec。 3 行就能说清楚 → 不需要正式 spec。

第五章：GitHub Spec Kit 实战​

5.1 Spec Kit 是什么​

GitHub 在 2025-2026 年推出的开源工具：

# 安装
npm install -g @github/spec-kit

# 在项目根初始化
spec-kit init
# 这会创建 .specify/ 目录

提供 4 个 Slash Command：

  • /specify — 引导你写 spec.md
  • /plan — 基于 spec 生成 plan.md
  • /tasks — 基于 plan 生成 tasks.md
  • /implement — 派 Agent 执行 task

5.2 与 Claude Code / Cursor 集成​

Spec Kit 的命令兼容主流 Coding Agent：

# 在 Claude Code
> /specify
# Claude 用 spec-kit 的模板引导你

> /plan
# 基于 .specify/spec.md 生成 plan

或者你可以完全不装 Spec Kit，自己手写 spec.md / plan.md / tasks.md，效果一样。Spec Kit 只是结构化模板。

5.3 项目目录布局​

推荐结构：

your-project/
├── .specify/                    # Spec Kit 配置
│   └── templates/
├── specs/                       # 所有 feature 的 spec
│   ├── 2026-Q2/
│   │   ├── auth-jwt-migration/
│   │   │   ├── spec.md
│   │   │   ├── plan.md
│   │   │   ├── tasks.md
│   │   │   └── postmortem.md   # 完成后的复盘
│   │   └── order-sorting/
│   └── archive/                 # 完成的 feature
└── src/

每个 feature 一个目录。Spec / Plan / Tasks 三个文件 + 完成后的 postmortem。

5.4 Spec 的版本控制​

Spec 不是写完就丢，要进 git：

git add specs/2026-Q2/auth-jwt-migration/
git commit -m "spec(auth): JWT migration spec v1"

# spec 改动也走 PR 流程
# Reviewer 在 spec 阶段就拦下问题，比 review 代码效率高 100x

第六章：团队级 SDD 规范​

6.1 何时必须 SDD​

不是所有任务都要 SDD。但下面这些强制要求：

  • 跨多个文件的改动（> 5 个文件）
  • 涉及核心流程（auth、payment、user data）
  • 估计耗时 > 1 天
  • 多人协作的 feature
  • 涉及不可逆操作（数据迁移、删除）

6.2 Review 流程​

Spec 评审（30 分钟会议或异步）：
├── PM/产品 review 业务正确性
├── Tech Lead review 技术可行性
└── 安全/合规 review 关键约束

→ 拍板，进 Plan 阶段

Plan 评审（异步 PR review）：
├── Tech Lead review 架构
├── 可能涉及的模块 owner review

→ 拍板，进 Tasks

Tasks 评审（异步）：
├── 你自己 review（这个 OK）
└── 必要时和 reviewer 确认拆分

→ 进 Implementation

6.3 度量 SDD 的有效性​

指标目标含义
Spec 阶段就发现的问题数越多越好早发现成本低
Implementation 阶段返工到 Spec 的次数< 1 次/feature太多说明 spec 不够清楚
Feature 上线后 bug 数下降spec 帮助提前考虑
估时准确率> 70%spec 帮助估时

6.4 文化建设​

反面正面
"写 spec 是浪费时间""spec 是想清楚的工具"
"我会做的，不需要 spec""team 需要看懂我在做什么"
"PM 没给 PRD 我也写不了 spec""spec 是工程师视角的，不依赖 PRD"
"AI 自己会理解""AI 没有上帝视角，需要被告知"

第七章：常见反模式​

7.1 Spec 写成 Plan​

❌ Spec 里出现这样的内容：
"使用 React Hook Form + Zod 校验"
"用 PostgreSQL 的 JSONB 字段存储"
"用 Redis 做缓存"

这些是 Plan 阶段的事。Spec 说"做什么"，不说"怎么做"。

7.2 Spec 太长​

50 页的 spec → 没人会读完 → 写了等于没写

控制在：
- 小任务：1 页
- 中任务：2-3 页
- 大任务：3-5 页（再大就拆）

7.3 写完 spec 不维护​

spec 写完没更新，几周后 spec 和实现完全不一致。

对策：
- spec 改动也走 PR
- 实现中发现 spec 错了，必须先改 spec 再继续
- feature 完成后，spec 进 archive（不要删）

7.4 Agent "假装"按 spec 做​

你：按 spec.md 第 3.2 节实现
Agent：好的，[输出代码]

实际上 Agent 没看 spec.md，凭"该怎么做"的直觉写。

对策：
- 让 Agent 在开始前**复述** spec 的关键点
- review 时对照 spec 逐条检查
- 大任务用 architect → implementor 模式（参考 05）

7.5 不该 SDD 的也 SDD​

"修一个 typo" 也写 spec？荒谬。

对策：
- 简单任务直接做
- 见第 4.3 节的判断标准

第八章：进阶模式​

8.1 Spec 模板复用​

某类任务高频重复时，提炼模板：

specs/templates/
├── new-api-endpoint.md
├── new-frontend-page.md
├── data-migration.md
├── third-party-integration.md

每次新任务 copy 模板，填空。10 倍速度。

8.2 Spec 作为 Onboarding 文档​

新人加入时不让他读代码，让他读 specs/。

specs/2024-Q1/  → 看一年前做了什么
specs/2024-Q2/
specs/2025/...

每个 feature 的 spec.md 就是它的"为什么和是什么"。比代码注释清楚 100 倍。

8.3 Spec 驱动的产品演进​

每个 quarter 的 spec 集合 → 看团队这个 quarter 做了什么。比 PR / commit 历史更清晰。

可以基于 spec 做：

  • Quarterly review
  • Roadmap 规划
  • 技术债 tracking

8.4 Spec 作为 Skill 模板​

参考 02 Skills 体系。常见 spec 类型可以做成 Claude Skill：

.claude/skills/
└── new-feature-spec/
    └── SKILL.md
---
name: new-feature-spec
description: 引导用户写 feature spec.md
---

当用户说"我要做一个 feature"或"帮我写 spec"时：

1. 先问澄清问题（参考第 3.1 节的清单）
2. 用模板生成 spec.md 草稿
3. 让用户 review 和补充

第九章：未来方向​

9.1 Spec → Plan 的自动化​

GitHub 在测试：直接从 spec.md 自动生成 plan.md。

挑战：

  • LLM 不知道你团队的技术约定（要喂 CLAUDE.md）
  • 不知道现有代码模式（要做 codebase search）
  • 不知道历史决策（要喂 ADR / postmortem）

2026 年逐渐成熟。

9.2 Spec 的可执行化​

把 spec 写成"可被验证"的格式：

# spec.yaml
acceptance_criteria:
  - id: AC1
    description: 用户能登录
    verify:
      type: e2e
      script: tests/e2e/auth/login.spec.ts
  - id: AC2
    description: 响应时间 < 200ms
    verify:
      type: performance
      target_p95: 200

CI 自动跑验证，确保 spec 中所有 AC 都有对应测试。

9.3 多模态 Spec​

Spec 不只是文字。结合：

  • Mermaid 流程图
  • Figma mockup（嵌入图片）
  • API schema（OpenAPI YAML）
  • DB schema（SQL）

让 Agent 看到完整的"是什么"。

9.4 Spec 中的不确定性管理​

明确表达"已知 vs 未知"：

## 已知
- 性能要求 < 200ms

## 未知（决策点）
- 数据存储：A 方案 vs B 方案 [需要在 Plan 阶段决定]

## 假设（需要验证）
- 假设 1：用户量 < 10k
- 假设 2：数据增长 < 100GB/year

让 Agent 知道哪里能自己决定、哪里要问。

权威资料​

核对日期：2026-06-12