设计原则
- 先定义能力，再设计页面。
- 页面结构来源于功能清单，而不是直接设计 UI。
- Design System 为所有页面提供统一的设计规范。
- 系统设计基于最终确认的原型，而不是功能清单。
- OpenAPI 基于系统设计生成，作为前后端统一接口契约。
- 文档保持最小化，只维护真正影响后续开发的内容。
- 修改哪个阶段的产物，就从哪个阶段开始更新，而不是重新走完整流程。
开发流程
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| 产品定位（Product Overview, 可选）
ChatGPT
↓
功能清单（Feature List）
ChatGPT
↓
页面结构 (Page Structure)
ChatGPT
↓
设计语言系统（Design System）
ChatGPT
↓
原型设计（Prototype）
Figma Make + ChatGPT (评审)
↓
系统设计（System Design）
Claude Code, Effort: High + ChatGPT (评审)
↓
接口设计（API Design）
Claude Code, Effort: High + ChatGPT (评审)
↓
编码实现（Implementation）
Claude Code, Effort: Medium / High + Warp (环境搭建、部署)
====================
根据需要，贯穿整个开发流程：
技术调研（Research）
Claude Code, Effort: Max (结合项目分析) + Perplexity (实时) + ChatGPT (评审)
|
产品定位（Product Overview，可选）
目的
明确产品目标及边界。
提示词示例
1
2
3
4
| 根据我的产品想法，生成产品定位文档 docs/00-product-overview。
要求：
- 包括产品目标、用户画像、产品边界及核心价值
|
功能清单（Feature List）
目的
梳理产品能力。
提示词示例
1
2
3
4
5
| 根据产品定位文档 docs/00-product-overview 生成功能清单文档 docs/01-feature-list。
要求：
- 不涉及页面和 UI，输出 Markdown Table
- 列包括 | 一级模块 | 二级模块 | 功能 | 功能说明 | 优先级 | 备注 |
|
页面结构（Page Structure）
目的
根据功能清单设计页面及导航结构。
提示词示例
1
2
3
4
5
6
7
| 根据功能清单文档 docs/01-feature-list 生成页面结构文档 docs/02-page-structure。
要求：
- 输出 Markdown 表格，列包括 | 一级菜单 | 页面 | 页面类型 | 页面说明 | 包含模块 | 关联功能 |
- 所有功能均有对应页面
- 所有页面均可通过导航访问
- 页面职责清晰，无重复设计
|
设计语言系统（Design System）
目的
统一产品视觉风格，为原型生成提供设计规范。
提示词示例
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| 根据 docs/ 下所有设计文档生成设计语言系统文档 docs/03-design-system。
要求：
- 包括
- 设计理念
- 配色规范
- 字体规范
- 布局规范
- 间距规范
- 图标规范
- 组件规范
- 页面视觉风格统一
- 可直接作为原型的设计约束
- 适合企业级后台
|
原型设计（Prototype）
目的
高保真原型。
提示词示例
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
| 根据设计文档生成高保真原型。
文档说明：
- 01-feature-list.md：定义系统功能，请确保所有 P0/P1 功能均体现在页面中。
- 02-page-structure.md：定义页面结构，请严格按照页面划分生成页面，不要新增或删除页面。
- 03-design-system.md：定义视觉风格、设计规范、组件规范，请严格遵循。
设计要求：
- 生成可继续编辑的专业页面，而不是低保真线框图。
- 风格采用现代企业级网络安全产品设计。
- 深色主题。
- 界面专业、克制、简洁，以信息展示效率为优先。
- 保持统一的组件、间距、颜色、字体和图标风格。
页面要求：
- 根据 page-structure.md，为每个页面生成一个独立 Frame。
- 所有页面保持统一 Header、Sidebar、内容区布局。
- 页面之间保持统一导航。
- 所有列表页使用统一的数据表格样式。
- 所有详情页采用"基础信息 + 关联信息"布局。
- Dashboard 使用统计卡片、图表、最近任务等常见布局。
数据要求：
- 使用业务数据进行填充，而不是 Lorem Ipsum。
- 字段符合真实网络安全产品。
- 图表、统计数据、表格数据均保持一致，不要出现逻辑冲突。
设计目标：
- 生成一套可以直接用于客户演示和后续开发的高保真原型，而不是概念稿。
|
原型生成完毕后把链接放入 docs/04-prototype。
原型评审（Review）
目的
确认原型满足产品需求，并进行必要调整。
提示词示例
1
2
3
4
5
| 根据 docs 下所有设计文档，评审当前原型，提出优化建议。
要求：
- 确认是否满足产品需求
- 确认是否可直接作为开发依据
|
系统设计（System Design）
目的
确定系统整体实现方案，为前后端开发提供统一技术设计。
提示词示例
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
| /sc:document
生成系统设计文档 `docs/06-system-design.md`。
开始前阅读 docs/ 下所有已有文档，包括 Prototype 文档中引用的设计稿。
要求：
- 描述系统如何实现，而不是产品需求。
- 不重复 Feature List、Page Structure、Design System 和 Prototype 的内容。
- 不新增、不删除任何功能。
- 面向整个系统，而不是仅限前端。
- 如存在多个实现方案，保留推荐方案并将未确定项标记为「待确认」，不要自行假设。
文档重点包括：
- 总体架构
- 技术栈
- 项目结构
- 模块划分
- 数据模型
- 核心业务流程
- 数据流
- 前后端职责划分
- 状态管理
- 权限模型（可预留）
- 异常处理
- 日志设计
- 安全设计
- 部署方案
- 可扩展性设计
API 设计边界：
- System Design 仅描述 API 架构、设计原则及模块之间的交互关系。
- 可以说明各模块提供哪些能力，例如「任务模块提供任务创建、查询和停止能力」。
- 不编写具体接口路径、HTTP Method、请求参数、响应字段、Schema、状态码或示例。
- 所有具体接口契约统一维护在 `docs/07-openapi.yaml`。
- 如需引用接口，仅描述接口能力，并注明「具体接口定义见 docs/07-openapi.yaml」。
数据模型边界：
- 描述领域模型及实体关系。
- 不等同于数据库表结构，也不直接照搬前端 TypeScript 类型。
- 前端模型、后端 DTO 和数据库模型允许根据职责进行适当拆分。
设计原则：
- API 采用 RESTful 风格。
- 前端统一通过 `/api/v1` 相对路径访问接口，不允许硬编码后端 IP、端口或域名。
- 开发环境通过 Vite Proxy，生产环境通过 Nginx 反向代理。
- 轻量风险探测与漏洞扫描系统职责分离，不将风险项描述为漏洞。
- 对尚未确定的技术方案明确标注「待确认」，不要自行假设。
文档应作为后续 OpenAPI 设计和前后端开发的依据。
完成后：
- 列出需要进一步确认的技术决策。
- 检查是否与其他设计文档存在职责重叠，如存在请指出并说明建议的归属文档。
|
接口设计（OpenAPI）
目的
定义前后端统一接口契约。
提示词示例
1
2
3
4
5
6
7
8
9
10
11
12
13
| /sc:document
根据 `docs/06-system-design.md`, 生成接口设计文档 `docs/07-openapi.yaml`。
要求：
- 使用 OpenAPI 3.1。
- 保持与系统设计一致，不新增功能。
- API 采用 RESTful 风格。
- 前端统一使用 `/api/v1` 相对路径，通过反向代理访问后端，不允许硬编码任何 IP、端口或域名。
- 定义完整的 paths、schemas、responses、examples 和 security。
- 兼容 Swagger UI、OpenAPI Generator 和 Mock Server。
- 最后检查 YAML 合法性、引用完整性和 operationId 唯一性。
|
编码实现（Implementation）
目的
根据设计文档完成编码实现。
提示词示例
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
| /sc:implement
开始前阅读 docs/ 下所有文档，并将其作为唯一事实来源（Single Source of Truth）。
重点参考：
- docs/02-feature-list.md
- docs/03-page-structure.md
- docs/04-design-system.md
- docs/05-prototype.md
- docs/06-system-design.md
- api/openapi.yaml
要求：
- 严格按照设计文档实现，不新增、不删除任何功能。
- 页面布局、交互和视觉效果保持与 Prototype 一致。
- 接口严格遵循 OpenAPI，不自行修改接口定义。
- 代码符合 System Design 中的项目结构、模块划分和开发规范。
- 保持组件职责单一，避免重复代码。
- 优先复用已有组件，不重复造轮子。
- 使用 TypeScript 强类型，避免 any。
- 不在业务代码中硬编码数据、接口地址或配置。
- 前端统一通过 `/api/v1` 相对路径访问接口，不允许硬编码 IP、端口或域名。
- 所有 HTTP 请求统一通过 API Client 封装。
- 完成后确保项目能够正常构建、运行，并通过 TypeScript 类型检查。
开发过程中：
- 若发现文档之间存在冲突，以 System Design 为准，并指出冲突，不要自行修改设计。
- 若发现设计存在缺失，先列出待确认事项，不自行扩展业务需求。
- 每完成一个阶段，汇报完成内容、剩余工作及存在的问题。
|
技术调研（Research）
目的
针对设计以及实现过程中遇到的不确定问题进行调研，为后续决策提供依据。
提示词示例
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
| /sc:research
开始前阅读 docs/ 下所有文档，理解当前项目背景。
调研以下问题：
<问题>
输出独立调研文档 docs/research/<topic>.md。
要求：
- 不急于给出结论。
- 优先调研当前主流方案和最佳实践。
- 结合当前项目分析，不仅介绍技术本身。
- 分析每种方案的优缺点、适用场景和复杂度。
- 说明对当前项目的影响，包括开发成本、维护成本、性能、安全性和扩展性。
- 最后给出推荐方案及推荐理由。
- 如存在明显风险或待确认事项，单独列出。
文档建议包含：
- 问题背景
- 方案对比
- 推荐方案
- 推荐理由
- 对当前项目的影响
- 风险与待确认事项
|
选定方案后集成进系统设计文档：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| /sc:document
将 docs/research/<topic>.md 的调研结论整合到系统设计文档。
要求：
- 更新调研文档中的「最终决策」章节。
- 仅更新受影响章节。
- 保留 System Design 的整体结构。
- 不复制整个调研报告。
- 不保留方案对比过程，仅保留最终设计决策。
- 将最终方案写入对应章节。
- 如有需要，在文档中引用对应的调研文档，例如：
详见：docs/research/<topic>.md
- 完成后输出：
- 修改了哪些章节
- 采用了哪些设计决策
- 是否仍有待确认事项
|
