RMDC系统设计文档 整体转换为SKILL

99-项目模板/1-原始需求/0-产品经理-prompt.md

@@ -0,0 +1,17 @@
+你现在是一名策略产品经理，你擅长进行市场研究和竞品分析，以制定产品策略。你能把握行业趋势，了解用户需求，并在此基础上优化产品功能和用户体验。请在这个角色下为我解答以下问题。
+
+----
+
+你是一名出色的产品经理，能够根据用户的初始需求，理解用户需求的真实需求意图，改善客户不够完善的需求，形成专业、简练的需求文档。并且能够在基础需求上优化产品的额设计和功能
+
+请根据要求,研究jenkins的API,进行深度的思考，优化[1-初始需求稿.md]，直接给出优化后的PRD
+
+----
+
+你是一名出色的产品经理，请你根据[1-初始需求稿.md]客户的原始需求,审查[2-优化产品需求文档PRD.md],检查PRD文档是否完全满足原始需求;如果有更加优秀的设计方案,请给出修改建议
+
+----
+
+你是一名出色的产品经理，能够根据用户的初始需求，理解用户需求的真实需求意图，改善客户不够完善的需求，形成专业、简练的需求文档。并且能够在基础需求上优化产品的额设计和功能
+
+你之前根据[1-初始需求稿.md]输出了[2-优化产品需求文档PRD.md], 目前初始需求有一些更新,见[1.1-初始需求稿.md],请你详细对比[1.1-初始需求稿.md]和[1-初始需求稿.md]之间的差异, 修改[2-优化产品需求文档PRD.md],得到新的需求文档

99-项目模板/1-原始需求/1-初始需求稿.md

@@ -0,0 +1,33 @@
+# 家庭游戏中心
+
+为父母设计的游戏中心，具有极度的简易操作性
+
+## 操控逻辑
+1. SteamOS的方式，完全屏蔽底层的操作系统，最好无法退出的形式
+   1. 请分析基于LINUX还是WINDOWS实现
+   2. 如果为WINDOWS需要对系统进行深度的简化裁剪,去除系统更新等内容
+2. 开机自动进入，需要系统层面的深度优化
+3. 进入之后很难推出
+4. 无广告
+
+## 设计逻辑
+1. 字体足够大，尽量减少文字的出现
+2. 鼠标控制器足够大
+3. 类似于大富翁,梦想城镇的美术风格
+
+## 游戏目录
+
+### 扑克类
+1. 斗地主
+2. 拖拉机
+
+### 麻将类
+1. 卡五星
+
+### 赛车类
+
+
+## 技术栈
+1. 熟练掌握Golang Python
+2. 能够看懂Vue等前端代码,可以修改
+3. 能够看懂TypeScript

99-项目模板/2-概要详细设计/0-概要设计prompt.md

@@ -0,0 +1,26 @@
+你是一名资深的软件系统架构师，具备以下核心职责与能力，绘图请使用mermaid语言：
+
+## 需求分析与理解
+
+- 深度解读产品需求文档（PRD），识别业务目标、功能需求与非功能性需求
+- 分析需求间的依赖关系与优先级，识别潜在的技术风险与挑战
+
+## 架构设计与规划
+
+- 设计高可用、可扩展、高性能的系统架构，确保系统健壮性与安全性
+- 制定技术选型方案，包括开发语言、框架、中间件、数据库等关键技术栈
+- 绘制多层次架构图（系统架构图、数据流图、组件交互图）
+- 定义模块划分、接口规范、数据模型与核心算法策略
+- 规划系统分层结构（展现层、业务层、数据层），明确各层职责边界
+
+## 方案设计与输出
+
+- 针对核心需求点提供详细的技术解决方案，包含实现路径与备选方案
+- 设计关键业务流程的时序图与状态机，确保逻辑清晰完整
+- 输出规范化的《系统详细设计说明书》，包含架构设计、接口定义、数据库设计等完整文档
+
+请根据[2-优化产品需求文档PRD.md]，按照上述的要求，输出系统详细设计说明书
+
+
+
+你之前根据[2-优化产品需求文档PRD.md]输出了[3-详细设计说明书.md], 目前PRD需求有一些更新,见[2.1-优化产品需求文档PRD.md],请你详细对比[2.1-优化产品需求文档PRD.md]和[2-优化产品需求文档PRD.md]之间的差异, 修改[3-详细设计说明书.md],得到新的需求文档.要求尽量不改动[3-详细设计说明书.md]的初始设计,只改动差异化部分的设计

99-项目模板/markdown-nbp.md

@@ -0,0 +1,94 @@
+生成一张【Markdown 语法速查信息图】（infographic），整体风格：白底、颜色丰富、科技感强、高对比度、高可读性；适合技术文档与开发者教学展示。
+
+【画面比例】
+- 横向 16:9
+- 高分辨率（4K 级别清晰）
+- 留白充足，适合网页 / PPT / 技术博客
+
+【整体视觉风格】
+- 背景：纯白 #FFFFFF
+- 卡片：白底卡片 + 轻微阴影 + 圆角 16px
+- 主色：蓝 / 紫 / 青（多色但克制），少量橙色点缀提示
+- 线条：细、干净、规则（浅灰分割线 #E5E7EB）
+- 图标：线性科技风 icon（统一线宽）
+- 字体：标题用现代无衬线（Inter/思源黑体风格），代码用等宽字体（Source Code Pro 风格）
+- 整体布局：网格化排版（2 行 × 4 列卡片），对齐严格
+
+【顶部标题栏（居中）】
+- 主标题（大字、深蓝）：Markdown 语法速查
+- 副标题（小字、浅灰）：Quick Reference for Developers
+- 标题下方：一条细分割线（浅灰）
+- 右上角小标签：v1.0 / Cheatsheet（紫色胶囊标签）
+
+【主体内容：8 张信息卡片（每张卡片都包含：小标题 + 1~2 行说明 + Markdown 示例代码块）】
+
+卡片 1：标题 Headings（蓝色标题条）
+- 说明：用 # 表示标题层级
+- 示例（等宽代码）：
+  # 一级标题
+  ## 二级标题
+  ### 三级标题
+
+卡片 2：强调 Emphasis（紫色标题条）
+- 说明：加粗、斜体、删除线
+- 示例：
+  **加粗**
+  *斜体*
+  ~~删除线~~
+
+卡片 3：列表 Lists（青色标题条）
+- 说明：无序与有序列表
+- 示例：
+  - 项目一
+  - 项目二
+    - 子项
+  1. 第一步
+  2. 第二步
+
+卡片 4：行内代码 Inline Code（蓝紫标题条）
+- 说明：用反引号包裹命令或变量
+- 示例：
+  使用 `git commit` 提交
+
+卡片 5：代码块 Code Block（深蓝标题条）
+- 说明：三反引号 + 语言标注
+- 示例（显示语言标签 bash）：
+  ```bash
+  docker compose up -d
+  ```
+
+卡片 6：引用 Quote（浅蓝标题条）
+
+* 说明：用 > 标注引用或提示
+* 示例：
+
+  > 这是引用说明（提示/结论）
+
+卡片 7：链接与图片 Links & Images（蓝绿标题条）
+
+* 说明：链接与图片语法
+* 示例：
+  [文档链接](https://example.com)
+  ![图片说明](image.png)
+
+卡片 8：表格 Tables（青紫标题条）
+
+* 说明：用 | 与 - 组成表格
+* 示例：
+
+  | 语法 | 说明 | 示例     |
+    | -- | -- | ------ |
+  | #  | 标题 | # 标题   |
+  | ** | 加粗 | **文本** |
+
+【底部信息栏（横向细条）】
+
+* 左侧：Tips：保持空行分段；代码优先用等宽字体
+* 右侧：小字灰色：Markdown Cheatsheet • White Tech Style
+
+【输出要求】
+
+* 画面中文字清晰可读、无模糊、无噪点
+* 不要照片质感，不要拟物风
+* 不要复杂背景纹理，只用轻微点阵/细网格作为非常淡的科技装饰（可选，透明度很低）
+

99-项目模板/软件开发流程说明.md

@@ -0,0 +1,285 @@
+## 一、典型的软件开发流程（中国境内常见实践）
+
+在中国，软件开发流程通常是**“类瀑布 + 敏捷迭代”的混合模式**，尤其在互联网公司最为常见。
+
+整体流程可抽象为 8 个阶段：
+
+```
+立项 → 需求分析 → 产品设计 → 技术设计 → 开发 → 测试 → 上线 → 运维/迭代
+```
+
+下面逐阶段展开。
+
+---
+
+## 二、各阶段说明 + 核心文档
+
+### 1️⃣ 立项阶段（项目启动）
+
+**目标**：决定“做不做、为什么做、值不值得做”。
+
+**参与角色**
+
+* 业务负责人 / 产品负责人
+* 技术负责人
+* 管理层（评审）
+
+**常见文档**
+
+| 文档    | 说明             |
+| ----- | -------------- |
+| 项目立项书 | 项目背景、目标、范围、ROI |
+| 可行性分析 | 技术、成本、周期、风险    |
+| 项目章程  | 角色分工、里程碑       |
+
+👉 政企项目中尤为正式，互联网内部项目可能简化。
+
+---
+
+### 2️⃣ 需求分析阶段（需求澄清）
+
+**目标**：搞清楚“用户要什么、业务怎么跑”。
+
+**核心角色**
+
+* 产品经理（主导）
+* 业务方
+* 技术、测试参与评审
+
+**关键文档**
+
+* **PRD（重点，见下文详解）**
+* 需求评审纪要
+* 原型图（Axure / 墨刀 / Figma）
+
+---
+
+### 3️⃣ 产品设计阶段（方案细化）
+
+**目标**：把“需求”变成“可交付的产品形态”。
+
+**文档**
+
+| 文档     | 内容        |
+| ------ | --------- |
+| 交互原型   | 页面跳转、流程   |
+| UI 设计稿 | 视觉规范      |
+| 业务流程图  | 状态流转、业务规则 |
+
+> 在很多公司，**产品设计与需求分析阶段是合并的**。
+
+---
+
+### 4️⃣ 技术设计阶段（系统设计）
+
+**目标**：回答“技术上怎么实现”。
+
+**核心角色**
+
+* 技术负责人 / 架构师
+* 后端 / 前端 / 客户端
+
+**关键文档**
+
+| 文档                | 说明              |
+| ----------------- | --------------- |
+| **DDS（重点，见下文详解）** | 详细设计说明          |
+| 架构设计说明            | 系统拆分、技术选型       |
+| 接口文档              | API 定义（Swagger） |
+| 数据库设计             | 表结构、索引          |
+
+---
+
+### 5️⃣ 开发阶段（编码实现）
+
+**目标**：把设计变成代码。
+
+**常见产物**
+
+* 代码仓库（Git）
+* Code Review 记录
+* 开发自测说明
+
+**中国公司特点**
+
+* 强调 **PR / MR 审核**
+* 常配合 Jira / TAPD / 禅道
+
+---
+
+### 6️⃣ 测试阶段
+
+**目标**：验证功能、稳定性、安全性。
+
+**文档**
+
+| 文档   | 说明           |
+| ---- | ------------ |
+| 测试计划 | 测什么、怎么测      |
+| 测试用例 | 功能 / 异常 / 边界 |
+| 缺陷单  | Bug 记录       |
+
+---
+
+### 7️⃣ 上线发布阶段
+
+**目标**：安全、可控地交付生产环境。
+
+**文档**
+
+* 上线方案
+* 回滚方案
+* 变更单（政企尤其严格）
+
+---
+
+### 8️⃣ 运维与迭代阶段
+
+**目标**：稳定运行 + 持续优化。
+
+**文档**
+
+* 运维手册
+* 监控指标说明
+* 复盘文档
+
+---
+
+## 三、重点详解：PRD 是什么？
+
+### 1️⃣ PRD 全称与含义
+
+> **PRD = Product Requirements Document**
+> 中文常称：**产品需求文档**
+
+---
+
+### 2️⃣ PRD 是“做什么”，不是“怎么做”
+
+**PRD 解决的问题：**
+
+* 用户是谁？
+* 解决什么问题？
+* 产品功能是什么？
+* 业务规则是什么？
+* 成功标准是什么？
+
+**PRD 不关心：**
+
+* 用什么语言
+* 表怎么建
+* 接口怎么拆
+
+---
+
+### 3️⃣ PRD 的典型结构（中国公司常见）
+
+```text
+1. 背景与目标
+2. 用户画像
+3. 使用场景
+4. 功能需求列表
+5. 业务规则
+6. 非功能需求（性能、权限）
+7. 异常与边界
+8. 数据埋点（互联网常见）
+```
+
+---
+
+### 4️⃣ PRD 的作者 & 读者
+
+| 角色   | 是否主要使用 |
+| ---- | ------ |
+| 产品经理 | ✅ 编写   |
+| 技术   | ✅ 理解需求 |
+| 测试   | ✅ 编写用例 |
+| 业务   | ✅ 验收   |
+
+---
+
+### 5️⃣ 中国语境下的特点
+
+* PRD **非常详细**
+* 常被当作“需求合同”
+* 政企项目中甚至作为验收依据
+
+---
+
+## 四、重点详解：DDS 是什么？
+
+### 1️⃣ DDS 全称与含义
+
+> **DDS = Detailed Design Specification**
+> 中文常称：**详细设计说明书**
+
+⚠️ 注意：
+不要和“数据分发服务（Data Distribution Service）”混淆。
+
+---
+
+### 2️⃣ DDS 是“怎么做”，不是“做什么”
+
+**DDS 解决的问题：**
+
+* 系统架构怎么拆？
+* 模块职责是什么？
+* 接口参数、返回值？
+* 数据表怎么设计？
+* 关键算法逻辑？
+
+---
+
+### 3️⃣ DDS 的典型结构
+
+```text
+1. 总体技术架构
+2. 模块划分说明
+3. 核心流程时序图
+4. 接口设计（API）
+5. 数据库设计（ER 图）
+6. 异常与容错设计
+7. 性能与并发考虑
+```
+
+---
+
+### 4️⃣ DDS 的作者 & 读者
+
+| 角色    | 是否主要使用   |
+| ----- | -------- |
+| 技术负责人 | ✅ 主导     |
+| 开发工程师 | ✅ 实现依据   |
+| 测试    | ◯ 理解技术边界 |
+| 产品    | ◯ 辅助理解   |
+
+---
+
+### 5️⃣ 中国公司 DDS 的现实情况
+
+| 公司类型      | DDS 情况  |
+| --------- | ------- |
+| 政企 / 传统软件 | 必须，极其正式 |
+| 大厂        | 视项目而定   |
+| 创业公司      | 常弱化或口头  |
+
+---
+
+## 五、PRD 与 DDS 的对比总结（重点）
+
+| 维度   | PRD                           | DDS                           |
+| ---- | ----------------------------- | ----------------------------- |
+| 全称   | Product Requirements Document | Detailed Design Specification |
+| 关注点  | 业务 & 产品                       | 技术 & 实现                       |
+| 回答问题 | 做什么                           | 怎么做                           |
+| 作者   | 产品经理                          | 技术负责人                         |
+| 面向对象 | 产品 / 技术 / 测试                  | 开发 / 架构                       |
+| 是否必须 | 几乎必须                          | 视项目规模                         |
+| 中国特点 | 偏详细                           | 偏重形式化                         |
+
+---
+
+## 六、一句话总结（非常重要）
+
+> **PRD 是业务视角的“需求合同”，DDS 是技术视角的“实现蓝图”。**
+