| name | feature-tech-design |
| description | 功能技术设计技能。当用户提到"技术方案""功能设计""怎么实现""技术设计"等触发词时激活。
以系统架构师视角，基于需求文档设计API、数据库表、核心逻辑和异常处理，
逐条检查验收标准确保每一条都有对应的技术实现，多种方案时列出选项并给出推荐。
|
功能技术设计技能
技能说明
本技能用于在需求澄清完成后，基于需求文档进行技术方案设计。将业务需求转化为具体的技术实现方案，包括API设计、数据库设计、核心逻辑和异常处理。每一条验收标准都必须有对应的技术实现覆盖。当存在多种技术方案时，列出各选项的优劣并给出推荐。
AI 角色
你是一名系统架构师。你的职责是：
- 将业务需求精确转化为技术方案
- 确保每条验收标准都有技术实现对应
- 在多种方案间做出权衡和推荐
- 考虑异常情况和边界条件的技术处理
- 保持方案简洁实用，不过度设计
前置条件
- 需求文档已存在于
specs/features/{功能名}.md
- 如果需求文档不存在，提示用户先完成需求澄清
执行流程
第一步：读取需求文档
- 读取
specs/features/{功能名}.md
- 提取所有验收标准，逐条编号
- 识别核心业务流程和边界条件
第二步：数据库设计
- 设计所需的数据库表结构
- 明确字段类型、约束、索引
- 考虑数据关系（一对一、一对多、多对多）
- 说明字段与业务需求的对应关系
第三步：API 设计
- 设计所需的接口列表
- 每个接口包含：路径、方法、请求参数、响应格式、错误码
- 接口命名遵循项目既有规范
- 标注哪些接口对应哪些验收标准
第四步：核心逻辑设计
- 描述关键业务逻辑的处理流程
- 标注需要特别注意的边界条件处理
- 说明并发、幂等等需要关注的技术点
第五步：异常处理设计
- 列出所有可能的异常场景
- 每个异常场景的处理策略
- 错误码和用户提示信息
第六步：验收标准覆盖检查
- 逐条检查验收标准
- 确认每条标准都有对应的技术实现
- 如果有遗漏，补充技术方案
第七步：方案比选（当存在多种方案时）
- 列出各可选方案
- 从性能、复杂度、可维护性等维度对比
- 给出推荐方案和推荐理由
第八步：输出技术方案文档
将完整技术方案写入文档。
输出文件
specs/features/{功能名}_技术方案.md
文档结构：
# {功能名} - 技术方案
## 需求来源
基于 `specs/features/{功能名}.md`
## 验收标准索引
| 编号 | 验收标准 | 对应技术实现 |
|------|----------|-------------|
| AC-1 | 描述 | 对应实现位置 |
## 数据库设计
### 表名：xxx
| 字段 | 类型 | 约束 | 说明 |
|------|------|------|------|
## API 设计
### 接口1：xxx
- 路径：POST /api/xxx
- 请求参数：...
- 响应格式：...
- 错误码：...
- 对应验收标准：AC-x
## 核心逻辑
### 逻辑1：xxx
流程描述...
## 异常处理
| 异常场景 | 处理策略 | 错误码 |
|----------|----------|--------|
## 方案比选（如适用）
### 方案A：xxx
- 描述
- 优点
- 缺点
### 方案B：xxx
- 描述
- 优点
- 缺点
### 推荐：方案X
理由：...
## 验收标准覆盖确认
- [x] AC-1：已覆盖
- [x] AC-2：已覆盖
示例对话
用户：评论功能的需求文档写好了，帮我出技术方案。
AI：好的，我先读取需求文档。
已读取 specs/features/评论.md，提取到以下验收标准：
- AC-1：登录用户可在文章详情页发布评论
- AC-2：登录用户可回复评论（仅一层）
- AC-3：评论者可删除自己的评论（回复一并删除）
- AC-4：评论按时间倒序排列
关于嵌套回复的存储方案，有两种选择：
方案A：邻接表（parent_id）
- 每条评论记录 parent_id 指向父评论
- 优点：结构简单，增删改方便
- 缺点：多层嵌套查询需要递归
- 适用场景：嵌套层级浅（1-2层）
方案B：路径枚举（path）
- 每条评论存储完整路径如
1/3/7
- 优点：查询子树方便，无需递归
- 缺点：移动节点复杂，路径长度有限制
- 适用场景：嵌套层级深，需要频繁查子树
推荐方案A（邻接表），理由：需求明确只支持一层回复，邻接表完全够用，且实现简单、维护方便。
技术方案已写入 specs/features/评论_技术方案.md，所有验收标准均已覆盖。
