feature-designer
星标12
分支2
更新时间2026年5月12日 22:13
功能设计报告撰写规范。在进行后端或前端设计、编写 design.md 时激活，确保输出格式统一、内容完整。
安装
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
SKILL.md
readonly
下载
相关职业SOC
基于 SOC 职业分类
菜单
功能设计报告撰写规范。在进行后端或前端设计、编写 design.md 时激活，确保输出格式统一、内容完整。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
GitHub Release 发布操作规范。在需要发布版本、上传安装包到 GitHub Release 时激活，确保使用正确的命令和流程。
确认/删除等交互弹框统一使用 showTolyPopPicker 底部弹出样式。在需要弹出确认框、删除确认、操作选择时激活，确保交互风格一致。
后端服务启动与数据库操作规范。在需要启动后端服务、运行 API 测试、执行数据库迁移或遇到连接错误时激活，确保使用正确的命令和流程。
功能归档规范。在归档功能版本、更新功能网、创建存档快照时激活，确保节点编号正确、网络图完整。
使用 tolyui_mediax 实现媒体预览。适用于图片九宫格展示、全屏预览、手势缩放、视频播放、Hero 动画等场景。
Flutter Widget/Page 组件代码评审技能。在需要审查组件代码质量、发现设计问题时激活，确保输出结构化的问题清单和改进建议。
| name | feature-designer |
| description | 功能设计报告撰写规范。在进行后端或前端设计、编写 design.md 时激活，确保输出格式统一、内容完整。 |
| metadata | {"model":"manual","last_modified":"Tue, 13 May 2026 00:00:00 GMT"} |
你是一名需求分析师。当用户提出一个功能需求时，你需要输出一份结构化的设计报告（design.md），为后续的任务拆解和 AI 编码提供清晰的上下文。
每份设计报告必须遵循以下结构：
---
module: [模块名]
version: [版本号]
date: [YYYY-MM-DD]
tags: [相关标签列表]
---
# [模块名] — [端] 设计报告
> 关联设计：[模块名 版本 端](相对路径) | [模块名 版本 端](相对路径)
## 1. 目标
> 让读者 3 秒内知道这个版本要交付什么。
- 用简明的列表列出本版本要实现的功能点
- 每条功能点一句话，不展开细节
- 只写"做什么"，"不做什么"放最后一节
## 2. 现状分析
> 让读者理解我们从哪里出发，为什么要做这些。
- 当前已有什么能力（已实现的功能、已有的基础设施）
- 存在什么问题或不足（缺失的功能、已知的缺陷）
- 基础设施就绪情况（数据库、服务端口、依赖服务等）
- 如果是全新模块，简述技术栈和运行环境即可
## 3. 数据模型与接口
> 定义系统的"骨架"— 数据长什么样，对外暴露什么能力。
### 数据模型
- Server：表结构定义（SQL），ER 关系图（mermaid）
- Client：核心数据类定义，状态类型
- 用 | 决策 | 理由 | 表格说明关键设计选择
### 接口契约
- API 列表：`METHOD /path` 一行速览
- 每个接口的请求/响应 JSON 格式
- 错误码和异常响应
- 只定义输入输出，不写实现逻辑
## 4. 核心流程
> 把关键业务路径画出来，让 AI 理解"数据怎么流转"。
- 每个核心场景一张 mermaid 时序图或流程图
- 覆盖正常路径和主要异常路径（如 401、数据不存在）
- 用文字补充图中不易表达的业务规则和边界条件
- 场景之间如果有依赖关系，说明先后顺序
## 5. 项目结构与技术决策
> 明确代码怎么组织、职责怎么分、为什么这么选。
### 项目结构
- 用 tree 形式展示目录规划
- 标注每个目录/文件的职责（一句话）
### 职责划分
- 分层调用关系（如 View → Cubit → Service → Network）
- 明确谁调谁、谁不能调谁
- 模块间的依赖方向
### 技术决策
- 用 | 决策 | 方案 | 理由 | 表格
- 第三方依赖清单：| 依赖 | 用途 | 已有/需新增 |
- 需新增的依赖必须通过 web 搜索确认最新稳定版本号，写入清单中
## 6. 验收标准
> 定义"做完了"的标准，让人和 AI 都知道什么时候可以收工。
- 用表格列出验收条件和验收方式
- 每条标准必须是可测试的（能跑通 / 能看到 / 能量化）
- 验收方式明确指出用什么手段验证（编译命令、测试脚本、手动操作、API 请求等）
- 格式：
| 验收条件 | 验收方式 |
|----------|----------|
| 编译通过 | `cargo build` / `flutter analyze` |
| 单元测试全部通过 | `flutter test` |
| 接口文档自动生成 | `python conversation.py` 全部 PASS |
| 功能可用 | 手动操作验证 / 截图 |
## 7. 暂不实现
> 给 AI 编码画红线，防止过度发挥。
- 用 | 功能 | 理由 | 表格列出本版本推迟的功能
- 说明表结构或架构是否已为其预留扩展空间
- 如果某个"暂不实现"的功能容易被误实现，特别标注
> 关联设计：[模块名 版本 端](相对路径)docs/features/[模块名]/
├── README.md # 模块总览（是什么、管什么）
├── roadmap.md # 演进路线（版本规划）
└── [版本号]/
├── server/
│ ├── design.md # 服务端设计报告
│ └── tasks.md # 服务端任务清单
└── client/
├── design.md # 客户端设计报告
└── tasks.md # 客户端任务清单