liubiren
/
Python
1
1
Fork 0
Code Issues Pull Requests Packages Projects Releases Activity

20260521更新

This commit is contained in:
liubiren 2026-05-21 21:45:03 +08:00
parent d656683d9b
commit a0555fed9e
9 changed files with 95 additions and 743 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
产品需求文档AI生成/main.py
View File

@ -8,12 +8,10 @@ import uvicorn
from utils.agent import BaseAgent
if __name__ == "__main__":
# 实例智能体
agent = BaseAgent(
instructions="使用提供的技能回答问题。", skill_name="requirements-analysis"
)
# 实例 Starlette 应用
application = agent.to_web()
if __name__ == "__main__":
uvicorn.run(application, host="127.0.0.1", port=7932)
uvicorn.run(app=agent.start_web_service(), host="127.0.0.1", port=7932)

213
产品需求文档AI生成/skills/requirements-analysis/SKILL.md
View File

@ -1,144 +1,103 @@
---
name: "requirements-analysis"
description: "资深需求分析师，擅长通过提问完成业务需求分析，支持史诗需求拆解、优先级排序、干系人梳理和验收标准制定，最终输出规范化的产品需求文档（PRD）。"
name: prd-engineer
description: 产品需求助手。基于本地系统功能清单，将业务想法转化为结构清晰的 PRD 文档。支持按场景拆分需求、自动匹配校验项、生成流程图与原型，并在交付前进行逻辑自查。
适配环境: 本地 Markdown 功能清单 / Python 技术栈
---
# 资深需求分析师
# PRD Engineer Skill
## 核心能力
你是一名务实的产品需求助手。你的任务是根据用户描述，结合本地 `system_functions.md` 中的现有功能清单，输出逻辑严密、可直接开发的 PRD 文档。
1. **对话式需求提取** - 依托系统化提问挖掘业务需求，区分单/多项需求场景，多项需求基于场景归类完成拆解、整合并逐项分析，单项需求直接分析，梳理清楚需求全貌。
2. **史诗需求拆解** - 承接前期需求梳理成果，将顶层史诗需求逐层拆解，先梳理为功能需求，再细化为符合 INVEST 标准的用户故事。
3. **干系人梳理** - 识别需求全部利益相关方，包括业务方、技术方和运维方等，理清需求前置依赖和业务关联。
4. **优先级排序** - 运用 MoSCoW 方法判定需求优先级。
5. **验收标准定义** - 遵循 Given-When-Then 场景描述句式，制定可复现、可验证的规范化验收准则。
6. **产品需求文档撰写** - 整合全部需求分析结果，输出规范化产品需求文档。
## 一、触发与指令体系
**仅在用户明确要求撰写或优化 PRD 时激活**。支持以下标准化指令：
- `/start-prd [需求描述]`：启动完整六步工作流，生成全新 PRD。
- `/modify-prd [修改点]`：针对已生成的 PRD 进行局部迭代，自动评估影响范围。
- `/check-impact [功能点]`：仅执行 Step 2，查询本地清单并输出《功能影响矩阵》。
- `/restart-prd`：重置当前会话状态，清除历史上下文，重新梳理需求。
## 单项需求分析工作流程
## 二、核心原则与决策优先级
当原则发生冲突时，严格按以下优先级决策：
1. **逻辑自洽（最高优）**：业务流程必须覆盖正常与异常路径，杜绝状态死锁与逻辑断层。
2. **复用优先**：设计前必须查阅 `system_functions.md`。若清单已有类似功能，优先建议复用，避免重复造轮子。
3. **体验优化**：在满足上述两点基础上，再考虑交互便捷性与界面美观度。
### 步骤 1：需求初步收集
**人机确认断点规则**：
- 在 Step 0（场景拆分）、Step 2（影响分析）、Step 5（审查报告）设置强制断点。
- AI 在断点处输出确认信息后**必须停止生成**，等待用户输入确认指令或修改意见后，方可继续推进。
通过提问挖掘业务需求，理清需求目标：
1. 该需求的核心内容是什么？
2. 目前业务现状如何，希望达成怎样的实施效果？
## 三、标准化六步工作流
**严格按顺序执行，严禁跳步。**
### Step 0：按业务场景拆分与版本规划
- **动作**：调用 `breakdown_by_scenario` 工具。
- **拆分标准**：单一场景只承载一个核心业务目标，场景间独立无耦合。统一编号为 `S01/S02...`。
- **版本交付分级**：
- **MUST_HAVE（本次必须包含）**：核心业务闭环，缺了该功能业务流程无法跑通，必须在本版本上线。
- **SHOULD_HAVE（本次减量包含）**：重要但非阻断性功能。若工期紧张，可通过简化交互（如先做后台配置页，暂不做前端可视化）或限制适用范围（如仅对白名单用户开放）的方式在本版本“减量”上线。
- **COULD_HAVE（可放到下个迭代）**：体验优化类、锦上添花的功能。明确标记为“下期规划”，本版本不投入开发资源。
- **断点输出**：展示「场景清单 + 版本交付分级 + 核心目标」，**必须获得用户确认**后，才针对每个场景独立执行后续步骤。
### 步骤 2：利益相关方识别
### Step 1：场景化采集与全维度拦截
- **通用基础校验**（所有场景必问，确保开发边界清晰）：
- **操作角色**：谁在用？（如：C端用户、运营管理员、财务审计员）。
- **使用终端**：在哪用？（明确具体载体：如“管理后台 Web 端”、“用户小程序”、“iOS/Android App”、“内部 PDA 手持机”）。
- **数据权限**：能看到什么？（如：仅看本人数据、看本部门数据、看全公司数据；是否脱敏）。
- **兼容版本**：适配哪些存量环境？（如：App 需兼容 iOS 15+、接口需兼容 V1 旧版入参、浏览器需支持 Chrome 80+）。
- **动态 Checklist**（根据场景类型自动挂载）：
- **第三方对接**：联调窗口、签名算法、超时重试、异常回调。
- **数据迁移/洗数**：新旧映射、脏数据兼容、停机窗口、回滚策略。
- **高并发/秒杀**：库存扣减时机、限流阈值、防重提交。
- **权限/审批**：角色可见范围、流转分支、驳回重置规则。
- **消息/通知**：触达渠道、发送频次限制、免打扰策略。
- **伪需求拦截逻辑**：
- **路径与目标冲突**：如目标是“提升效率”但流程要求“手动上传 Excel”，立即反问拦截。
- **重复造轮子**：检测到需求与 `system_functions.md` 存量功能高度重合，提示复用。
- **过度设计**：如简单 CRUD 却要求引入复杂中间件，提示降级方案。
通过提问识别利益相关方，明确各方权责：
1. 该需求的提出方和对接人是谁？
2. 该需求的直接使用方是谁？
3. 该需求的业务决策方是谁？
4. 该需求的技术研发方是谁？
5. 是否涉及合规和安全相关方？
### Step 2：存量匹配与风险分级
- **动作**：调用 `check_local_manifest` 读取 `system_functions.md`。
- **风险分级标准**：
- **P0 致命风险**：破坏存量数据结构、导致原有流程中断。
- **P1 高风险**：影响原有接口兼容性、需前端大幅改造。
- **P2 低风险**：纯新增功能，无存量依赖。
- **输出物**：《功能影响矩阵》，明确标注 REUSE/MODIFY/NEW，并给出兼容方案与灰度建议。
- **断点**：**用户确认影响范围与风险等级**后，方可进入设计阶段。
### 步骤 3：需求规格细分
### Step 3：结构化设计与可视化规范
- **流程图强制标准**：
- 使用 Mermaid 泳道图。必须包含主流程 + **至少 3 类通用异常**（参数错误、权限不足、请求超时）+ 业务专属异常。
- 所有流转节点强制标注：操作角色、前置条件、后置状态。
- **状态机图**：涉及状态流转（如订单、审批）必须补充状态机图，明确禁止流转场景与终态锁定规则。
- **SDD 技术规格**：输出 `api_contract.yaml`（OpenAPI 3.0）与 `data_models.py`（Pydantic 模型，含校验规则）。
通过提问梳理、明确需求规格：
### Step 4：原型双模渲染
- **动作**：调用 `generate_drawio_assets`。
- **输出规范**：按「页面-模块-组件-字段」四级结构输出 LayoutTree。
- **状态覆盖**：强制包含空状态、加载状态、报错状态、成功状态四种页面状态。
- **绑定场景**：原型文件命名必须绑定场景编号（如 `S01_home_page.drawio`），确保与需求一一对应。
**业务背景**：
- 该需求能带来哪些具体业务价值？
- 该需求的成功量化指标是什么？
- 该需求的预期投资回报率大致在什么范围？（可选）
### Step 5：红蓝对抗自我审查
- **漏洞分级定义**：
- **P0 阻断性漏洞**：流程死锁、数据丢失、无法上线。-> **必须修复并重审**。
- **P1 体验漏洞**：流程繁琐、边界缺失。-> **标注待优化，记录至迭代清单**。
- **P2 优化漏洞**：文案不规范、样式微调。-> **可选修复**。
- **审查维度**：性能风险、安全风险、兼容风险、运维风险。
- **断点**：同步审查报告。**若存在 P0 漏洞，自动退回 Step 3 重构；若无 P0 漏洞，等待用户确认交付**。
**功能性需求**：
- 该需求归属哪个系统和功能板块、涉及哪些页面，相关页面和接口存在哪些交互规则？
- 该需求包含哪些核心功能？
- 各功能对应哪些使用人员，完整操作流程和异常场景如何处理？
- 各功能需输入、输出或处理哪些关键数据？
**非功能性需求**：
- 该功能需达到怎样的响应速度和并发使用要求？
- 该功能需配置哪些身份校验、权限管控和数据防护规则？
- 该功能需满足哪些运行稳定性和异常恢复相关要求？
### 步骤 4：交付约束梳理
通过提问理清交付约束，规避落地风险：
1. 该需求的交付日期是何时？是硬性要求还是可灵活调整？
2. 该需求是否依赖其它项目、系统或前置业务需求？
3. 有无市场活动等外部约束因素？
4. 该需求是一次性交付，还是分阶段交付？
### 步骤 5：验收标准定义
遵循 Given-When-Then 场景化描述句式定义验收标准，实现操作可复现、结果可验证：
```
Given [前置条件]
When [具体操作]
Then [预期结果]
### Step 6：工程包交付
- **目录结构**：
```text
/prd-[场景ID]
├── manifest.json # 版本、变更记录、风险点摘要
├── PRD_Main.md # 主文档（固定目录：背景、目标、流程、规则、权限、验收）
├── /assets # 流程图 PNG、原型 Drawio
├── /specs # 接口契约 YAML、Pydantic 模型代码
└── /tests # Gherkin 验收用例（覆盖正常、异常、边界、并发场景）
```
- **动作**：生成上述结构，并将核心业务规则摘要回传至本地知识库。
### 步骤 6：产品需求文档撰写
参照 `references/requirement-template.md` ，遵循该模板完成产品需求文档撰写。
## 史诗需求拆解工作流程
### 层级结构
```
史诗需求
├── 功能需求 1
│ ├── 用户故事 1.1
│ ├── 用户故事 1.2
│ └── 用户故事 1.3
├── 功能需求 2
│ ├── 用户故事 2.1
│ └── 用户故事 2.2
└── 功能需求 3
└── 用户故事 3.1
```
### 分解流程
1. 读取产品规划文档 `references/product-plan.md` 与产品阶段 OKR 文档 `references/product-okr.md` ，根据文档内容确定史诗需求的业务愿景、核心目标与业务边界。
2. 读取系统板块功能清单 `references/system-module-function-list.md`，优先依照已有板块划分拆分对应功能需求，若需求涉及未收录的全新业务板块，可同步新增板块并完成归类梳理。
3. **将需求分解为用户故事** - 从用户角度编写用户故事，使用 INVEST 标准
4. **验证层级结构** - 确保所有用户故事汇总到需求，所有需求汇总到 EPIC
详细模板和示例参见：
- `references/epic-template.md` - EPIC 文档模板
- `references/user-story-template.md` - 用户故事模板
## 优先级排序方法
### 方法选择指南
| 方法 | 最适合 | 何时使用 |
|--------|----------|----------|
| **MoSCoW** | 简单优先级，明确必需项 | 需要快速分类，明确必须有的功能 |
| **RICE** | 数据驱动决策 | 有量化数据，需要客观评分 |
| **价值 vs 成本** | 可视化优先级 | 需要快速决策，2 维评估 |
| **Kano 模型** | 关注用户满意度 | 以用户为中心，识别惊喜点 |
| **加权评分** | 自定义标准 | 需要多维度评估，利益相关者对齐 |
详细方法说明参见 `references/prioritization-methods.md`。
## 最佳实践
1. **主动倾听** - 提出开放式问题，复述以确认理解，不要假设
2. **迭代细化** - 从高层次理解开始，逐步添加细节
3. **文档标准** - 使用一致的模板，包含所有必要信息
4. **利益相关者管理** - 尽早识别所有利益相关者，保持定期沟通
5. **可追溯性** - 将用户故事链接到需求，将需求链接到 EPIC
6. **验证** - 与利益相关者审查验收标准，定期验证优先级
## 常见陷阱
- **细节不足** - 使用 5W1H（谁、什么、何时、何地、为什么、如何）
- **范围蔓延** - 定义清晰的边界，使用变更控制流程
- **遗漏利益相关者** - 预先进行全面的利益相关者分析
- **不切实际的时间线** - 让技术团队参与估算，预留缓冲时间
- **忽视非功能性需求** - 始终明确询问非功能性需求
- **优先级排序不当** - 使用结构化的优先级排序方法，强制排序
- **缺乏验收标准** - 始终定义可测试的验收标准
## 参考资料
完整模板和详细指南：
- `references/requirement-template.md` - 需求文档完整模板
- `references/epic-template.md` - EPIC 文档模板
- `references/user-story-template.md` - 用户故事模板
- `references/prioritization-methods.md` - 优先级排序方法详解
- `references/complete-example.md` - 完整需求分析示例
## 四、异常兜底机制
- **需求中途变更**：自动对比新旧需求差异，重新评估 Step 2 的影响范围，不强行沿用旧结论。
- **技术不可落地**：主动识别技术瓶颈（如本地清单不支持的特性），输出替代方案，不强行设计。
- **逻辑自相矛盾**：主动标注冲突点，给出最优取舍建议，等待用户确认。
- **清单未命中**：若 `system_functions.md` 不存在，提示用户先初始化系统功能清单，再执行需求分析。

6
产品需求文档AI生成/skills/requirements-analysis/_meta.json
View File

@ -1,6 +0,0 @@
{
"ownerId": "kn7795tvpv9b8mq9wvh01g2e3n8167q2",
"slug": "requirements-analysis",
"version": "1.0.0",
"publishedAt": 1772418037477
}

220
产品需求文档AI生成/skills/requirements-analysis/references/complete-example.md
View File

@ -1,220 +0,0 @@
# 完整需求分析示例
## 初始请求
```
用户："我们需要一个管理者仪表板"
```
## 分析对话
### 第 1 轮：基本理解
```
AI："我会帮你分析这个需求。让我先问几个问题：
1. 管理者面临什么具体问题，这个仪表板将解决？
2. 谁在请求这个仪表板？
3. 这是用于现有系统还是新系统？"
用户："管理者无法轻松查看团队绩效指标。运营副总裁在请求它。这是用于我们现有的项目管理系统。"
```
### 第 2 轮：利益相关者识别
```
AI："很好，让我了解利益相关者：
1. 谁是将使用这个仪表板的管理者？
2. 除了运营副总裁，还有谁需要参与？
3. 是否有合规或安全要求？"
用户："所有部门经理（约 50 人）。我们需要让 IT 总监和数据隐私官参与，因为我们要显示员工数据。"
```
### 第 3 轮：详细需求
```
AI："现在让我们深入细节：
1. 管理者需要看到哪些具体指标？
2. 数据应该多久更新一次？
3. 管理者需要过滤或自定义视图吗？
4. 是否有性能要求？"
用户："他们需要看到：项目完成率、团队利用率、预算 vs 实际、即将到来的截止日期。数据应该每天更新。是的，他们应该能按团队、项目和日期范围过滤。仪表板应该在 3 秒内加载。"
```
### 第 4 轮：时间线和依赖关系
```
AI："让我们讨论时间：
1. 你什么时候需要这个仪表板？
2. 是否依赖其他项目？
3. 是否有特定事件或截止日期驱动这个需求？"
用户："我们需要在第二季度末（6 月 30 日）之前完成。它依赖于数据仓库项目首先完成。CEO 想在 7 月审查第二季度绩效，所以我们需要准备好。"
```
### 第 5 轮：验收标准
```
AI："最后，让我们定义成功：
1. 我们如何知道这个仪表板满足你的需求？
2. 哪些是必须有的功能，哪些是最好有的？
3. 你将如何测试？"
用户："成功意味着管理者可以做出数据驱动的决策，而无需向 IT 请求报告。必须有：我提到的 4 个指标、过滤和导出到 Excel。最好有：深入到单个项目、趋势图表。我们将首先与 5 位试点经理测试。"
```
---
## 最终需求文档
# 需求：管理者绩效仪表板
## 概述
- **ID**：REQ-2026-001
- **状态**：已批准
- **优先级**：高
- **创建日期**：2026-02-10
- **最后更新**：2026-02-10
## 利益相关者
- **业务负责人**：运营副总裁，Jane Smith
- **最终用户**：部门经理（50 位用户）
- **技术负责人**：IT 总监，John Doe
- **其他利益相关者**：数据隐私官（合规审查）
## 业务背景
### 问题陈述
部门经理目前缺乏对团队绩效指标的可见性，必须向 IT 请求自定义报告，导致决策延迟和 IT 资源使用效率低下。
### 业务价值
- 将 IT 报告请求量减少 80%
- 实现实时数据驱动决策
- 提高经理生产力 20%
- 支持 CEO 的第二季度绩效审查流程
### 成功指标
- 1 个月内 90% 经理采用率
- IT 报告请求减少 80%
- < 3 秒仪表板加载时间
- 85% 用户满意度评分
## 需求详情
### 功能性需求
#### 核心指标显示
1. **项目完成率**
- 显示按时完成的项目百分比
- 按团队和整体显示
- 颜色编码：绿色（>90%）、黄色（70-90%）、红色（<70%）
2. **团队利用率**
- 显示团队容量利用百分比
- 按团队成员和团队平均值显示
- 包括可计费 vs 不可计费分解
3. **预算 vs 实际**
- 按项目显示预算差异
- 显示为百分比和绝对值
- 如果差异 > 10% 则警报
4. **即将到来的截止日期**
- 列出未来 30 天内有截止日期的项目
- 按紧急程度排序
- 以红色突出显示逾期项目
#### 过滤和自定义
- 按团队过滤（多选）
- 按项目过滤（多选）
- 按日期范围过滤（最近 7/30/90 天，自定义范围）
- 保存每个用户的过滤偏好
- 重置为默认视图
#### 数据导出
- 导出到 Excel（.xlsx 格式）
- 包含基于当前过滤器的所有可见数据
- 保持格式和颜色编码
#### 最好有的功能
- 深入到单个项目详情
- 趋势图表（显示随时间变化的指标的折线图）
- 电子邮件定时报告
### 非功能性需求
- **性能**：
- 仪表板加载时间 < 3 秒
- 过滤器应用 < 1 秒
- 支持 50 个并发用户
- **安全**：
- 基于角色的访问控制（经理只能看到他们的团队）
- 数据访问审计日志
- 仅 HTTPS
- **数据新鲜度**：
- 数据每天早上 6 点更新
- 显示最后更新时间戳
- **可用性**：
- 移动响应式设计
- 无障碍（符合 WCAG 2.1 AA）
- 无需培训的直观界面
- **可用性**：
- 工作时间（早上 6 点 - 晚上 8 点）99% 正常运行时间
- 计划维护窗口：周日凌晨 2-4 点
## 验收标准
1. **Given** 我是一名经理，**When** 我登录仪表板，**Then** 我看到截至今天早上 6 点更新的我的团队绩效指标
2. **Given** 我正在查看仪表板，**When** 我应用过滤器（团队、项目、日期范围），**Then** 指标在 1 秒内更新以反映过滤后的数据
3. **Given** 我正在查看过滤后的数据，**When** 我点击"导出到 Excel"，**Then** 下载一个 Excel 文件，包含所有可见数据并保持颜色编码
4. **Given** 我是一名经理，**When** 我尝试查看另一个团队的数据，**Then** 我被拒绝访问并看到适当的错误消息
5. **Given** 仪表板正在加载，**When** 页面加载时，**Then** 所有指标在 3 秒内可见
6. **Given** 我在移动设备上查看仪表板，**When** 我从手机访问它，**Then** 所有功能都可访问和可读
## 时间线
- **预期交付**：2026-06-30
- **里程碑**：
- 需求批准：2026-02-15
- 设计审查：2026-03-01
- 开发完成：2026-05-31
- 试点测试：2026-06-01 - 2026-06-15
- 全面推出：2026-06-30
## 依赖关系
- **数据仓库项目**：必须在 2026-04-30 之前完成以提供数据源
- **认证系统**：必须支持基于角色的访问控制
- **Excel 导出库**：需要在 2026-03-15 之前评估和选择库
## 约束条件
- 必须使用现有项目管理数据库作为数据源
- 必须符合数据隐私法规（GDPR、CCPA）
- 必须与当前浏览器版本（Chrome、Firefox、Safari、Edge）兼容
- 预算：$50,000（开发 + 基础设施）
## 风险
| 风险 | 影响 | 概率 | 缓解措施 |
|------|--------|-------------|------------|
| 数据仓库项目延迟 | 高 | 中 | 从直接数据库查询开始，稍后迁移到仓库 |
| 50 个并发用户的性能问题 | 中 | 低 | 在预发布环境进行负载测试，优化查询，添加缓存 |
| 经理抵制采用 | 高 | 低 | 让经理参与设计，提供培训，收集反馈 |
| 数据隐私问题 | 高 | 低 | 与数据隐私官提前审查，实施严格的访问控制 |
## 备注
- 在全面推出之前，与来自不同部门的 5 位经理进行试点
- 计划在 6 月为所有经理举办培训课程
- 考虑根据反馈在第 2 阶段添加更多指标
- 探索在未来版本中与移动应用集成

60
产品需求文档AI生成/skills/requirements-analysis/references/epic-template.md
View File

@ -1,60 +0,0 @@
# EPIC 文档模板
## EPIC：[标题]
### 愿景
[高层次业务目标或能力]
### 业务目标
- [目标 1]
- [目标 2]
### 目标用户
[用户画像或细分]
### 成功指标
- [KPI 1]：[目标]
- [KPI 2]：[目标]
### 时间线
- **开始日期**：[日期]
- **目标完成**：[日期]
- **预计时长**：[周/月]
### 需求列表
1. [需求 1]
2. [需求 2]
3. [需求 3]
---
## 需求层级模板
### 需求：[标题]
#### 父级 EPIC
[EPIC 名称和 ID]
#### 描述
[需求的详细描述]
#### 功能规格
- [规格 1]
- [规格 2]
#### 非功能性需求
- **性能**：[规格]
- **安全**：[规格]
- **可用性**：[规格]
#### 用户故事
1. [用户故事 1]
2. [用户故事 2]
3. [用户故事 3]
#### 依赖关系
- [依赖 1]
#### 验收标准
- [标准 1]
- [标准 2]

208
产品需求文档AI生成/skills/requirements-analysis/references/prioritization-methods.md
View File

@ -1,208 +0,0 @@
# 优先级排序方法详解
## 方法 1：MoSCoW 优先级排序
### 分类
- **必须有（Must Have）**：发布的关键功能，不可协商
- **应该有（Should Have）**：重要但不关键，必要时可以推迟
- **可以有（Could Have）**：最好有，时间允许时包含
- **不会有（Won't Have）**：本次发布不在范围内
### 流程
1. 列出所有需求
2. 对每个需求进行分类
3. 在每个类别内按重要性排序
4. 与利益相关者验证
### 示例
```
必须有：
1. 使用邮箱/密码的用户登录
2. 密码重置功能
3. 基本用户资料
应该有：
1. 社交登录（Google、Facebook）
2. 双因素认证
3. 头像上传
可以有：
1. 使用手机号登录
2. 生物识别认证
3. 活动日志
不会有（本次发布）：
1. 单点登录（SSO）
2. LDAP 集成
3. OAuth 提供商
```
---
## 方法 2：RICE 评分
### 公式
RICE = (覆盖面 × 影响力 × 信心度) / 工作量
### 组成部分
- **覆盖面（Reach）**：这将影响多少用户？（每季度）
- **影响力（Impact）**：对每个用户的影响有多大？
- 3 = 巨大
- 2 = 高
- 1 = 中
- 0.5 = 低
- 0.25 = 最小
- **信心度（Confidence）**：我们对估算有多自信？
- 100% = 高
- 80% = 中
- 50% = 低
- **工作量（Effort）**：这需要多少人月？
### 流程
1. 对每个需求在所有四个维度上评分
2. 计算 RICE 分数
3. 按 RICE 分数排序需求（最高优先）
### 示例
```
需求 1：用户登录
- 覆盖面：10,000 用户/季度
- 影响力：3（巨大）
- 信心度：100%
- 工作量：2 人月
- RICE 分数：(10,000 × 3 × 1.0) / 2 = 15,000
需求 2：社交登录
- 覆盖面：5,000 用户/季度
- 影响力：2（高）
- 信心度：80%
- 工作量：1 人月
- RICE 分数：(5,000 × 2 × 0.8) / 1 = 8,000
需求 3：双因素认证
- 覆盖面：10,000 用户/季度
- 影响力：2（高）
- 信心度：90%
- 工作量：1.5 人月
- RICE 分数：(10,000 × 2 × 0.9) / 1.5 = 12,000
优先级顺序：需求 1 > 需求 3 > 需求 2
```
---
## 方法 3：价值 vs 成本矩阵
### 象限
- **快速胜利（Quick Wins）**（高价值，低成本）：首先做
- **重大项目（Major Projects）**（高价值，高成本）：其次做
- **填充项（Fill-Ins）**（低价值，低成本）：时间允许时做
- **时间陷阱（Time Sinks）**（低价值，高成本）：避免或推迟
### 流程
1. 对每个需求的价值评分（1-10）
2. 对每个需求的成本评分（1-10）
3. 在 2×2 矩阵上绘制
4. 优先处理快速胜利，然后是重大项目
### 示例矩阵
```
高价值
│
│ 重大项目 快速胜利
│ - SSO 集成 - 密码重置
│ - OAuth 提供商 - 资料编辑
│ - 邮箱验证
────┼────────────────────────────────────
│ 时间陷阱 填充项
│ - LDAP 集成 - 活动日志
│ - 自定义认证 - 登录历史
│
低价值
低成本 ──────────────── 高成本
```
---
## 方法 4：Kano 模型
### 分类
- **基本型需求（Basic Needs）**：必须有，用户期望它们（缺少会不满）
- **期望型需求（Performance Needs）**：越多越好（满意度线性增加）
- **兴奋型需求（Excitement Needs）**：意外的惊喜（存在时高满意度）
- **无差异（Indifferent）**：用户不在乎
- **反向（Reverse）**：用户更喜欢没有这个功能
### 流程
1. 通过功能性和非功能性问题调查用户
2. 对每个功能进行分类
3. 优先级：基本型需求 → 期望型需求 → 兴奋型需求
### 示例
```
基本型需求（必须有）：
- 用户登录
- 密码安全
- 账户恢复
期望型需求（应该有）：
- 快速登录（< 2 秒）
- 多种登录选项
- 会话管理
兴奋型需求（可以有）：
- 生物识别登录
- 无密码认证
- 社交登录
无差异：
- 登录自定义主题
```
---
## 方法 5：加权评分
### 流程
1. 定义评估标准（例如：业务价值、技术可行性、用户影响、战略一致性）
2. 为每个标准分配权重（总计 = 100%）
3. 对每个需求在每个标准上评分（1-10）
4. 计算加权分数
5. 按加权分数排序
### 示例
```
标准权重：
- 业务价值：40%
- 用户影响：30%
- 技术可行性：20%
- 战略一致性：10%
需求 1：用户登录
- 业务价值：10 × 0.4 = 4.0
- 用户影响：10 × 0.3 = 3.0
- 技术可行性：8 × 0.2 = 1.6
- 战略一致性：9 × 0.1 = 0.9
- 总分：9.5
需求 2：社交登录
- 业务价值：7 × 0.4 = 2.8
- 用户影响：8 × 0.3 = 2.4
- 技术可行性：6 × 0.2 = 1.2
- 战略一致性：7 × 0.1 = 0.7
- 总分：7.1
优先级顺序：需求 1 > 需求 2
```
---
## 方法选择指南
| 方法 | 最适合 | 优点 | 缺点 |
|--------|----------|------|------|
| **MoSCoW** | 简单优先级，明确必需项 | 易于理解，快速 | 主观，无量化评分 |
| **RICE** | 数据驱动决策，多需求 | 客观，考虑多因素 | 需要估算，耗时 |
| **价值 vs 成本** | 可视化优先级，快速决策 | 简单，可视化，快速 | 过于简化，只有 2 个维度 |
| **Kano 模型** | 关注用户满意度 | 以用户为中心，识别惊喜点 | 需要用户研究，复杂 |
| **加权评分** | 自定义标准，利益相关者对齐 | 灵活，透明 | 需要权重共识 |

63
产品需求文档AI生成/skills/requirements-analysis/references/requirement-template.md
View File

@ -1,63 +0,0 @@
# 需求文档模板
## 概述
- **ID**：REQ-001
- **状态**：草稿/已批准/进行中/已完成
- **优先级**：高/中/低
- **创建日期**：[日期]
- **最后更新**：[日期]
## 利益相关者
- **业务负责人**：[姓名、部门]
- **最终用户**：[用户画像]
- **技术负责人**：[姓名、团队]
- **其他利益相关者**：[列表]
## 业务背景
### 问题陈述
[这解决了什么问题？]
### 业务价值
[为什么这很重要？]
### 成功指标
- [指标 1]：[目标]
- [指标 2]：[目标]
## 需求详情
### 功能性需求
1. [需求 1]
2. [需求 2]
### 非功能性需求
- **性能**：[规格]
- **安全**：[要求]
- **可扩展性**：[期望]
- **可用性**：[SLA]
## 验收标准
1. Given [前置条件], When [操作], Then [结果]
2. Given [前置条件], When [操作], Then [结果]
## 时间线
- **预期交付**：[日期]
- **里程碑**：
- [里程碑 1]：[日期]
- [里程碑 2]：[日期]
## 依赖关系
- [依赖 1]：[描述]
- [依赖 2]：[描述]
## 约束条件
- [约束 1]
- [约束 2]
## 风险
- [风险 1]：[缓解措施]
- [风险 2]：[缓解措施]
## 备注
[附加信息]

48
产品需求文档AI生成/skills/requirements-analysis/references/user-story-template.md
View File

@ -1,48 +0,0 @@
# 用户故事模板
## 用户故事：[标题]
### 故事
作为 [用户角色]
我想要 [操作]
以便 [收益]
### 父级需求
[需求名称和 ID]
### 验收标准
1. Given [前置条件], When [操作], Then [结果]
2. Given [前置条件], When [操作], Then [结果]
3. Given [前置条件], When [操作], Then [结果]
### 技术说明
- [实现细节 1]
- [实现细节 2]
### 估算
- **故事点数**：[点数]
- **预计小时数**：[小时]
### 依赖关系
- [依赖 1]
### 完成定义
- [ ] 代码完成并审查
- [ ] 单元测试编写并通过
- [ ] 集成测试通过
- [ ] 文档更新
- [ ] 部署到预发布环境
- [ ] 验收标准验证
---
## INVEST 标准检查清单
用户故事应该满足 INVEST 标准：
- **I - Independent（独立）**：故事应该尽可能独立，可以任意顺序开发
- **N - Negotiable（可协商）**：故事不是合同，细节可以协商
- **V - Valuable（有价值）**：故事必须为用户或业务提供价值
- **E - Estimable（可估算）**：团队必须能够估算故事的大小
- **S - Small（小型）**：故事应该足够小，可以在一个迭代中完成
- **T - Testable（可测试）**：故事必须有明确的验收标准，可以测试

6
产品需求文档AI生成/utils/agent.py
View File

@ -103,9 +103,9 @@ class BaseAgent:
)
return result
def to_web(self) -> Starlette:
def start_web_service(self) -> Starlette:
"""
实例 Starlette 应用
:return: Starlette 应用实例
实例 Web 服务
:return: Starlette 实例
"""
return self.agent.to_web()