anian0/tech-design

技术方案设计

基于需求文档产出完整技术方案。核心原则：文档先行；前后端并行；测试聚焦单元与必要集成。

<HARD-GATE> 1. **必须有需求文档**：从 `workplace/1.X/requirements/` 读取；否则停止并提示先做 requirements-workshop。 2. **技术文档必须先行**：参考文档存入 `workplace/1.X/references/` 之前不得进入设计。 3. 不得写代码、不得创建项目结构、不得进入实现阶段。 </HARD-GATE>

版本号约定

1.X 为占位符，详见 requirements-workshop/SKILL.md。真实路径必须替换为具体数字（如 workplace/1/references/）。

前后端联合设计原则

技术方案必须同时覆盖：

• 后端：架构、数据模型、API、服务、权限
• 前端：页面结构、路由、组件、状态管理、API 接入、关键交互
• 测试：后端单元/集成测试（pytest）、前端审查清单（subagent）

需求文档"页面/界面清单"必须在技术方案中逐项有对应前端设计。遗漏前端是审核必拒项。

工作流程（9 步）

1. 读取需求文档 → 需求理解确认
2. 现状分析与变更识别：分析当前代码状态 → 产出变更清单（Delta）→ 创建功能点清单（FP-N）→ 用户确认变更范围与功能点
3. 区分新/旧功能 → 准备技术文档（新功能：参考文档；旧功能：技术栈说明）→ 存入 workplace/1.X/references/
4. 设计架构 → 架构确认
5. 设计数据模型 → 数据模型确认
6. 设计 API → API确认
7. 设计前端（路由/页面/组件/状态/API 接入，逐页确认）→ 前端逐页确认
8. 制定测试策略 + 创建测试点清单（TC-N）+ 风险评估（单元为主，必要集成；识别技术/兼容/资源风险）
9. 产出技术方案 → 自检 → 用户确认 → 产出交接清单 → 进入 implementation-planning

---

第一步：读取需求文档 + 需求理解确认

从 workplace/1.X/requirements/ 读取最近的需求文档。

• 若不存在：提示用户先做 requirements-workshop 或提供文档路径
• 若有多个：列出最近 3 个让用户选择

提取功能清单、页面清单与测试关注标记后，向用户确认理解：

我已读取需求文档，理解如下：

核心目标：[一句话概括]

功能清单摘要（共N个功能）：

• 功能1：[名称] - [用户入口] → [闭环终点]
• 功能2：...

页面清单摘要（共N个页面）：

• 页面1：[名称] ([路由]) - 对应功能X
• 页面2：...

测试关注标记摘要：

• 后端关注点：X个（[列出各功能的[后端]标记]）
• 前端关注点：Y个（[列出各功能的[前端]标记]）

关键验收标准：

• [主要验收点]

特别关注点：[从需求文档附录 7.1 节提取用户强调的内容]

请确认我的理解是否准确？是否有遗漏或需要补充的重点？

等待用户确认后才进入下一步。若用户指出理解偏差，调整理解后重新确认。

---

第二步：现状分析与变更识别（Delta 分析）

这一步是技术方案质量的关键。没有 Delta 分析，方案就会退化为对已有功能的复述。

2.1 分析当前代码状态

针对需求文档中的每个功能点，探索现有代码：

• 相关模块/文件在哪里？核心函数/组件是什么？
• 当前的数据模型、API 接口、前端页面是怎样的？
• 哪些部分可以直接复用，哪些需要修改，哪些是全新的？

方法：用 Glob/Grep/Read 探索项目结构 → 用 Explore agent 深入复杂模块 → 与用户确认关键发现。

2.2 产出变更清单（Delta 清单）

变更清单是后续所有设计工作的唯一输入。它回答一个核心问题：从当前状态到目标状态，具体要改什么？

## 变更清单

### 后端变更
| 编号 | 变更类型 | 目标模块/文件 | 当前状态 | 目标状态 | 具体修改 |
| B-1 | 修改 | src/api/user.ts:getUser() | 返回字段不含 avatar | 返回字段含 avatar | 在 SELECT 中添加 avatar 字段；更新响应 DTO |
| B-2 | 新增 | src/api/user.ts | 无此接口 | 新增上传头像接口 | 新增 POST /user/avatar，处理 multipart 上传 |
| B-3 | 修改 | src/models/user.sql | 无 avatar 列 | 新增 avatar VARCHAR(255) | ALTER TABLE 添加列；编写迁移脚本 |

### 前端变更
| 编号 | 变更类型 | 目标模块/文件 | 当前状态 | 目标状态 | 具体修改 |
| F-1 | 修改 | src/pages/profile.vue | 无头像展示区域 | 顶部展示圆形头像 | 添加 avatar 展示组件；绑定 store 中的 avatar 数据 |
| F-2 | 新增 | src/components/AvatarUpload.vue | 无此组件 | 头像裁剪+上传组件 | 新建组件，集成 cropper.js + 上传 API |

### 数据模型变更
| 编号 | 变更类型 | 实体 | 变更内容 |
| D-1 | 修改 | User | 新增 avatar 字段 (VARCHAR(255), 可空) |

变更类型的含义：

• 新增：当前代码中不存在，需要从零创建
• 修改：当前代码存在但需要改动，必须说清"改哪里、改成什么"
• 删除：当前代码存在但需要移除
• 重构：功能不变但结构调整（如拆分函数、迁移模块）

2.3 创建功能点清单（FP-N）

基于第一步提取的测试关注标记和第二步识别的变更项，创建功能点清单。功能点是连接需求与变更的桥梁，也是后续验收的基础。

创建规则：

• 需求中的每个 [后端] 测试关注标记至少产生一个后端脚本功能点（FP-N）
• 需求中的每个 [前端] 测试关注标记至少产生一个前端审查功能点（FP-N）
• 每个功能点关联对应的变更项编号（B-N / F-N / D-N）
• 功能点描述必须具体可验收（不是"实现XX功能"，而是"XX场景下YY行为"）
• 功能点编号全局唯一（FP-1, FP-2, ...），后续阶段统一引用

示例：

| 功能点编号 | 来源需求功能 | 来源测试关注 | 功能点描述 | 涉及变更 | 测试方式 | |-----------|-------------|-------------|-----------|---------|---------| | FP-1 | 功能1 | [后端]正常流程 | 正常创建工单 | B-1, D-1 | 后端脚本 | | FP-2 | 功能1 | [后端]参数校验 | 空标题校验 | B-2 | 后端脚本 | | FP-3 | 功能1 | [前端]成功反馈 | 创建成功页面反馈 | F-1 | 前端审查 |

创建后，将功能点编号补充到变更清单的"关联功能点"列。

2.4 用户确认变更范围

变更清单与功能点清单已完成。请确认：

• 变更范围是否完整？有没有遗漏的功能点？
• 每个变更的"当前状态"描述是否准确？
• 每个变更的"具体修改"是否是你想要的？
• 功能点是否覆盖了需求的所有测试关注标记？
• 变更项与功能点的关联是否正确？

确认后才进入下一步。 变更清单和功能点清单共同构成后续设计的约束——架构、数据模型、API、前端设计都必须围绕变更清单展开，不得脱离变更清单描述无关内容。

---

第三步：准备参考文档

3.1 区分功能类型

| 分类 | 定义 | 文档要求 | |------|------|----------| | 新功能 | 项目无类似实现，引入新技术/模块 | 必须有参考文档 | | 旧功能扩展 | 基于现有代码扩展 | 必须有技术栈说明 | | 旧功能复用 | 直接调用现有功能 | 无需额外文档 |

判断方法：搜索现有代码 → 检查技术栈 → 与用户确认。

3.2 输出技术文档需求清单（用户确认后再继续）

## 技术文档需求清单

### 新功能（需要参考文档）
| 功能 | 文档类型 | 来源建议 | 状态 |

### 旧功能扩展（需要技术栈说明）
| 功能 | 涉及模块 | 文档要求 | 状态 |

### 文档存放位置：workplace/1.X/references/
- 参考文档：`{技术名}-reference.md`
- 技术栈说明：`{模块名}-techstack.md`
- 前端 UI 库参考：`{库名}-frontend-reference.md`

3.3 收集 / 整理文档

新功能参考文档模板（核心字段）：基本信息（链接/版本/引入方式）、核心概念、API 参考（用途/参数/返回/示例）、最佳实践、注意事项、与本项目关联。 收集方式：Context7 MCP / WebFetch/WebSearch / 用户提供 / 现有代码探索。

旧功能技术栈说明模板：模块定位、代码结构、数据模型、API 接口、依赖关系、扩展点、注意事项。

3.4 验证清单

| 检查项 | 要求 | |--------|------| | 目录存在 | workplace/1.X/references/ 已创建 | | 新功能文档 | 每个新功能都有参考文档 | | 旧功能文档 | 每个旧功能扩展都有技术栈说明 |

通过后宣布：> 技术文档准备完成，开始技术方案设计。

---

第四步：架构设计 + 架构确认

核心原则：以变更清单为输入，每个设计项必须对应变更清单中的编号。设计的是"改什么"而非"是什么"。

4.1 架构设计

| 章节 | 内容 | |------|------| | 系统架构图 | 模块划分、层次、依赖（Mermaid graph） | | 技术选型 | 各模块技术栈与理由 | | 部署架构 | 部署方式、网络拓扑（如适用） | | 数据流向 | 数据在模块间流转 |

4.2 架构确认

产出架构设计后，向用户确认：

架构设计已完成：

系统架构图：[简述分层结构]

技术选型：

• 后端：[技术栈]
• 前端：[技术栈]

数据流向：[关键数据流]

这个架构是否符合你的预期？技术选型是否可接受？

等待用户确认后才进入下一步。若用户提出调整，修改架构设计后重新确认。

---

第五步：数据模型设计 + 数据模型确认

每个实体描述字段（名/类型/必填/默认/说明）、约束、索引、迁移计划（若有）。

### {实体名}
| 字段 | 类型 | 必填 | 默认 | 说明 |
| id | UUID | 是 | 自动 | 主键 |

5.1 数据模型确认

产出数据模型后，向用户确认：

数据模型设计如下：

新增/修改实体（共N个）：

| 实体 | 变更类型 | 关键字段 | 说明 |

请确认：

• 实体划分是否合理？
• 关键字段是否完整？
• 是否有遗漏的业务属性？

等待用户确认后才进入下一步。若用户提出调整，修改数据模型后重新确认。

---

第六步：API 设计 + API确认

接口清单 + 每个接口的：路径与方法、描述、认证、请求参数表、请求示例、响应字段表、响应示例、错误码。

6.1 API确认

产出API设计后，向用户确认：

API接口清单（共N个新增/修改）：

| 接口 | 方法 | 路径 | 对应功能 | 说明 |

请确认：

• 接口覆盖是否完整？
• 接口设计是否符合前端调用需求？
• 是否有遗漏的业务场景？

等待用户确认后才进入下一步。若用户提出调整，修改API设计后重新确认。

---

第七步：前端设计 + 前端逐页确认（强制，基于变更清单）

针对需求文档"页面/界面清单"，逐项给出前端实现设计。任何遗漏都会让需求功能在实施阶段消失。

与变更清单的关系：前端变更清单（F-* 编号）是前端设计的输入。每个前端设计项必须标注对应的变更清单编号。

7.1 设计内容

| 章节 | 内容 | |------|------| | 路由结构 | 所有路由及层级（含权限/守卫） | | 页面设计 | 每页布局、组件、数据来源、状态机 | | 组件清单 | 复用组件、第三方组件库选型 | | 状态管理 | 方案选型（Pinia/Redux/Zustand）+ store 划分 | | API 接入 | 调用哪些后端接口、错误处理、loading/重试 | | 关键交互 | 表单校验、上传下载、分页等 |

7.2 前端逐页确认

前端设计采用逐页确认方式：

现在进行前端设计，我将逐页与你确认。

---

页面1：[页面名]（路由：[path]）

• 对应需求功能：[功能编号/名称]
• 布局结构：[简述]
• 关键组件：[列表]
• 状态机：初始 → 加载中 → [结果态]

这个页面设计是否符合预期？

[用户确认后继续下一页]

---

页面2：[页面名]...

每页确认后才继续下一页。若用户提出调整，修改该页设计后重新确认。

7.3 页面设计模板

### 页面：{页面名}（路由：{path}）
- **对应需求功能**：[功能编号/名称]
- **布局**：[结构示意]
- **关键组件**：[列表]
- **数据来源**：[API/本地状态]
- **状态机**：初始 / 加载中 / 空 / 错误 / 成功
- **交互细节**：[校验、跳转、二次确认]
- **权限**：[未登录/无权限处理]

7.4 覆盖核查表（必做）

列一张表：左列=需求文档"页面清单"每一行，右列=本方案"页面设计"对应章节锚点。任意缺失即返工。

---

第八步：测试策略 + 风险评估

8.1 测试目录规范（强制）

workplace/1.X/test/
├── backend/
│   ├── unit/<module>/         # 后端单元测试（核心）
│   └── integration/<module>/  # 后端集成测试（仅关键 API/数据库交互）
├── review/                    # 前端审查清单（subagent 逐项检查）
├── fixtures/                  # 共享测试数据
└── README.md                  # 运行命令矩阵 + 覆盖率目标

约束：

• 业务源码内不得存放测试文件（不在 src 旁放 .test.ts/test_.py），测试与源码分离便于版本归档
• 跨模块复用的 mock/fixture 集中放在 test/fixtures/
• 以单元测试为主；集成测试仅覆盖关键路径（如核心 API + 数据库写入）；不做端到端测试
• test/README.md 列出运行命令：单测、集成、覆盖率

8.2 测试策略内容

| 章节 | 内容 | |------|------| | 测试范围 | 哪些功能需要测试（前后端均需列出） | | 测试类型 | 后端单元测试（主）+ 关键集成测试 + 前端审查清单 | | 测试数据 | fixtures 准备方式 | | 覆盖率目标 | 后端/前端分别的目标 | | 运行命令 | 各类测试命令（写入 test/README.md） |

8.3 测试分类

| 类型 | 覆盖 | 目录 | 工具 | |------|------|------|------| | 后端单元 | 业务逻辑、工具函数 | test/backend/unit/<module>/ | pytest | | 后端集成 | 关键 API + 数据库 | test/backend/integration/<module>/ | pytest | | 前端审查 | 页面级功能验证（subagent 逐项检查） | test/review/ | 审查清单 |

本套 skill 的前端测试统一使用 subagent 审查清单，不使用 Vitest / Jest / Vue Test Utils / RTL 等自动化组件测试框架。

本套 skill 不做端到端测试。如确有强需求，由用户单独提出后另行规划，不在本方案默认范围内。

---

8.4 创建测试点清单（TC-N）

基于功能点清单（Step 2.3），为每个功能点创建测试点。测试点是验收的直接依据。

创建规则：

• 每个功能点（FP-N）对应一个测试点（TC-N）
• 后端测试点 = 一个可执行的 py 脚本路径 + 测试内容摘要
• 前端测试点 = 一个审查清单文件路径 + 检查内容摘要
• 测试点编号全局唯一（TC-1, TC-2, ...）
• 后端脚本路径格式：workplace/1.X/test/backend/unit/{module}/{module}_test.py 或 workplace/1.X/test/backend/integration/{module}/{module}_test.py，同一模块的所有测试点共享同一验收脚本
• 前端审查清单路径格式：workplace/1.X/test/review/{module}_checklist.md，同一模块的所有测试点共享同一审查清单
• 路径中的 {module} 占位符在实施计划阶段由模块分配确定，技术方案阶段不替换

示例：

| 测试点编号 | 对应功能点 | 测试脚本/清单路径 | 测试内容摘要 | |-----------|-----------|------------------|-------------| | TC-1 | FP-1 | workplace/1.X/test/backend/unit/{module}/{module}_test.py | 有效数据创建工单，返回201 | | TC-4 | FP-4 | workplace/1.X/test/review/{module}_checklist.md | 成功Toast、跳转列表 |

---

8.5 风险评估

基于变更清单和设计决策，识别三类风险：

| 风险类别 | 识别内容 | 示例 | |----------|----------|------| | 技术风险 | 引入新技术/新依赖、复杂算法、未验证的方案 | "首次使用 WebSocket，需验证服务端推送稳定性" | | 兼容风险 | 变更影响现有功能、数据迁移、接口变更 | "ALTER TABLE 在大表上可能锁表" | | 资源风险 | 工时不确定、外部依赖、并行开发冲突 | "依赖第三方 API 尚未提供测试环境" |

每项风险说明：风险描述、影响范围、应对措施。

---

第九步：产出技术方案文档 + 交接清单

按以下顺序组装技术方案文档（使用 9.2 模板）：

1. 确认记录（Step 1-7 各确认环节）→ 填入文档开头"确认记录"章节
2. 功能点与测试点清单（Step 2.3 FP-N + Step 8.4 TC-N）→ 填入 §一
3. 变更清单（Step 2.2 变更清单 + Step 2.3 功能点关联）→ 填入 §二
4. 架构设计（Step 4）→ 填入 §三
5. 数据模型（Step 5）→ 填入 §四
6. API 设计（Step 6）→ 填入 §五
7. 前端设计（Step 7）→ 填入 §六
8. 测试策略（Step 8.1-8.3）→ 填入 §七
9. 需求-方案映射核查表：逐项核对需求功能→测试关注→功能点→测试点→变更项 → 填入 §八
10. 风险评估（Step 8.5）→ 填入 §九
11. 附录：特别关注点（来自需求文档 §7.1）+ 参考文档清单 + 术语表 → 填入 §十

9.1 命名与存储

命名：YYYY-MM-DD-{需求名称}-技术方案.md 存储：workplace/1.X/tech-design/

9.2 模板

# {需求名称} 技术方案

> 需求文档：[路径]
> 技术参考：workplace/1.X/references/

## 确认记录

> 记录关键步骤的用户确认情况。

| 步骤 | 确认内容 | 状态 |
|------|---------|------|
| 需求理解确认 | 已确认核心目标、功能清单、页面清单、测试关注标记、特别关注点 | ✅ |
| 变更范围确认 | 已确认变更清单（B-N/F-N/D-N）和功能点清单（FP-N）完整且关联正确 | ✅ |
| 技术文档确认 | 已确认参考文档/技术栈说明准备完毕 | ✅ |
| 架构确认 | 已确认系统架构图、技术选型、数据流向 | ✅ |
| 数据模型确认 | 已确认实体划分、关键字段 | ✅ |
| API确认 | 已确认接口覆盖、设计合理性 | ✅ |
| 前端逐页确认 | 已确认每页布局、组件、状态机 | ✅ |

---

## 一、功能点与测试点清单

> 基于需求文档的"测试关注"标记拆分。每个功能点对应一种测试方式（后端脚本 / 前端审查），每个测试点有唯一编号。这是后续计划和验收的基础。

### 1.1 功能点清单

| 功能点编号 | 来源需求功能 | 来源测试关注 | 功能点描述 | 涉及变更 | 测试方式 |
|-----------|-------------|-------------|-----------|---------|---------|
| FP-1 | 功能1 | [后端]正常流程 | 正常创建工单 | B-1, D-1 | 后端脚本 |
| FP-2 | 功能1 | [后端]参数校验 | 空标题校验 | B-2 | 后端脚本 |
| FP-3 | 功能1 | [后端]参数校验 | 重复标题校验 | B-3 | 后端脚本 |
| FP-4 | 功能1 | [前端]成功反馈 | 创建成功页面反馈 | F-1 | 前端审查 |
| FP-5 | 功能1 | [前端]失败反馈 | 创建失败页面反馈 | F-1 | 前端审查 |
| FP-6 | 功能1 | [前端]加载状态 | 提交加载态 | F-2 | 前端审查 |

**规则**：同第二步 2.3 功能点创建规则。

### 1.2 测试点清单

| 测试点编号 | 对应功能点 | 测试脚本/清单路径 | 测试内容摘要 |
|-----------|-----------|------------------|-------------|
| TC-1 | FP-1 | workplace/1.X/test/backend/unit/{module}/{module}_test.py | POST /api/tickets有效数据，返回201，数据库有记录 |
| TC-2 | FP-2 | workplace/1.X/test/backend/unit/{module}/{module}_test.py | POST /api/tickets空标题，返回400，数据库无记录 |
| TC-3 | FP-3 | workplace/1.X/test/backend/unit/{module}/{module}_test.py | POST /api/tickets重复标题，返回409 |
| TC-4 | FP-4 | workplace/1.X/test/review/{module}_checklist.md | 成功Toast、跳转列表、列表有新数据 |
| TC-5 | FP-5 | workplace/1.X/test/review/{module}_checklist.md | 错误标红、不跳转、按钮恢复 |
| TC-6 | FP-6 | workplace/1.X/test/review/{module}_checklist.md | 按钮loading、disabled、提示文字 |

**规则**：同第八步 8.4 测试点创建规则。

## 二、变更清单（Delta 清单）

> 这是本方案的核心。后续所有设计都必须围绕此清单展开。
> 每个变更项必须标注关联的功能点编号，确保可追溯。

### 2.1 后端变更
| 编号 | 关联功能点 | 变更类型 | 目标模块/文件 | 当前状态 | 目标状态 | 具体修改 |
| B-1 | FP-1 | 新增 | src/api/ticket.py | 无此接口 | 新增创建工单接口 | 添加POST /api/tickets，请求体校验，写入tickets表 |
| B-2 | FP-2 | 新增 | src/api/ticket.py | 无校验逻辑 | 添加参数校验 | 添加@validate_body，空标题返回400 |
| B-3 | FP-3 | 修改 | src/models/ticket.sql | 无唯一约束 | 添加title唯一索引 | ALTER TABLE添加UNIQUE INDEX |

### 2.2 前端变更
| 编号 | 关联功能点 | 变更类型 | 目标模块/文件 | 当前状态 | 目标状态 | 具体修改 |
| F-1 | FP-4, FP-5 | 新增 | src/pages/TicketCreate.vue | 无此页面 | 添加工单创建页 | 表单组件、提交逻辑、成功/失败处理 |
| F-2 | FP-6 | 新增 | src/components/SubmitButton.vue | 无loading状态 | 添加loading态 | props: loading，disabled当loading=true |

### 2.3 数据模型变更
| 编号 | 关联功能点 | 变更类型 | 实体 | 变更内容 |
| D-1 | FP-1 | 新增 | Ticket | id/title/content/status/created_at |

### 2.4 变更汇总
- 新增：X 个（列出编号）
- 修改：Y 个（列出编号）
- 删除：Z 个（列出编号）

## 三、架构设计
### 3.1 系统架构图（含前后端分层）
### 3.2 技术选型
### 3.3 部署架构（如适用）

## 四、数据模型
### 4.1 实体定义（仅列出变更涉及的实体）
### 4.2 关系图
### 4.3 索引设计

## 五、API 设计
### 5.1 接口清单（仅列出变更涉及的接口）
### 5.2 接口详情

## 六、前端设计
### 6.1 路由结构
### 6.2 页面设计
### 6.3 组件清单
### 6.4 状态管理
### 6.5 API 接入与错误处理
### 6.6 覆盖核查表（需求页面清单 → 本章节锚点）
| 需求页面 | 路由 | 对应章节 |

## 七、测试策略
### 7.1 测试目录（workplace/1.X/test/，后端按 unit/integration 分类，前端用 review 审查清单，不做 E2E）
### 7.2 测试范围（前后端分别列出）
### 7.3 测试类型与工具
### 7.4 覆盖率目标
### 7.5 运行命令

## 八、需求-方案映射核查表

| 需求功能 | 测试关注标记 | 功能点 | 测试点 | 变更项 |
|---------|-------------|--------|--------|--------|
| 功能1 | [后端]正常流程 | FP-1 | TC-1 | B-1, D-1 |
| 功能1 | [后端]参数校验 | FP-2, FP-3 | TC-2, TC-3 | B-2, B-3 |
| 功能1 | [前端]成功反馈 | FP-4 | TC-4 | F-1 |
| 功能1 | [前端]失败反馈 | FP-5 | TC-5 | F-1 |
| 功能1 | [前端]加载状态 | FP-6 | TC-6 | F-2 |

**核查规则**：
- 左列（需求功能）必须逐项出现
- 每个需求的测试关注标记必须在功能点列有对应
- 每个功能点必须在测试点列有对应
- 每个功能点必须在变更项列有对应
- 任一缺失即需返工

## 九、风险评估
### 9.1 技术风险
### 9.2 兼容风险
### 9.3 资源风险

## 十、附录
### 10.1 特别关注点

> 来自需求文档附录 7.1 节，后续阶段务必注意。

- [各关注点]

### 10.2 参考文档清单
### 10.3 术语表

9.3 自检（一次 subagent 审查）

读取 references/tech-design-reviewer-prompt.md，将 [TECH_DESIGN_FILE_PATH] 和 [REQUIREMENTS_FILE_PATH] 替换为实际路径后派发 subagent。

| 状态 | 处理 | |------|------| | 通过 | 进入用户确认 | | 发现问题 | 修复后无需重审 |

9.4 用户确认

技术方案已完成。请确认：

• 功能点清单是否覆盖需求的所有测试关注标记？
• 测试点清单是否为每个功能点定义了明确的验收方式（后端脚本/前端审查）？
• 变更清单是否完整且具体？每个变更是否关联了功能点编号？
• 架构与数据模型是否合理？
• API 是否满足需求？
• 前端设计是否覆盖需求页面清单的每一项？
• 需求-方案映射核查表是否逐项对齐？

9.5 产出交接清单

确认后，产出交接清单并宣布进入 implementation-planning：

技术方案已完成并确认。进入 implementation-planning 时请携带以下信息：

交接清单：

• 技术方案路径：workplace/1.X/tech-design/YYYY-MM-DD-xxx.md
• 功能点数量：N个（列出FP编号）
• 测试点数量：M个（列出TC编号，后端脚本X个、前端审查Y个）
• 变更数量：后端A项、前端B项、数据模型C项
• 前端页面数量：N个（列出编号）
• 特别关注点：[已记录于技术方案 §10.1，源自需求文档附录 7.1 节]

implementation-planning 第一步应确认对功能点和测试点的理解，并基于功能点创建任务和验收标准。

---

特殊情况

• 需求过大：建议拆分子方案，先做哪个？
• 技术选型分歧：列对比表给出 2-3 方案，让用户选
• 文档无法获取：用户提供 / 探索现有代码 / 推迟该功能
• 现有代码复杂：聚焦核心接口与数据模型，忽略实现细节；分层探索（接口 → 数据 → 业务）

关联 skill

| Skill | 关系 | |-------|------| | requirements-workshop | 本 skill 的输入来源：读取需求文档的功能清单、页面清单、测试关注标记 | | implementation-planning | 本 skill 的下游：技术方案确认后，由 implementation-planning 拆分为可执行的任务模块 | | issue-troubleshooting | 排查大修时引用已有技术方案（只读），不得创建新的技术方案文档 |