diff --git a/产品需求文档AI生成/main.py b/产品需求文档AI生成/main.py
index f6c245d..5e39aaa 100644
--- a/产品需求文档AI生成/main.py
+++ b/产品需求文档AI生成/main.py
@@ -8,12 +8,10 @@ import uvicorn
 
 from utils.agent import BaseAgent
 
-# 实例智能体
-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)
+    # 实例智能体
+    agent = BaseAgent(
+        instructions="使用提供的技能回答问题。", skill_name="requirements-analysis"
+    )
+    uvicorn.run(app=agent.start_web_service(), host="127.0.0.1", port=7932)
diff --git a/产品需求文档AI生成/skills/requirements-analysis/SKILL.md b/产品需求文档AI生成/skills/requirements-analysis/SKILL.md
index 77ca863..1e9e491 100644
--- a/产品需求文档AI生成/skills/requirements-analysis/SKILL.md
+++ b/产品需求文档AI生成/skills/requirements-analysis/SKILL.md
@@ -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 漏洞，等待用户确认交付**。
 
-**功能性需求**：
-- 该需求归属哪个系统和功能板块、涉及哪些页面，相关页面和接口存在哪些交互规则？
-- 该需求包含哪些核心功能？
-- 各功能对应哪些使用人员，完整操作流程和异常场景如何处理？
-- 各功能需输入、输出或处理哪些关键数据？
+### Step 6：工程包交付
+- **目录结构**：
+    ```text
+    /prd-[场景ID]
+    ├── manifest.json          # 版本、变更记录、风险点摘要
+    ├── PRD_Main.md            # 主文档（固定目录：背景、目标、流程、规则、权限、验收）
+    ├── /assets                # 流程图 PNG、原型 Drawio
+    ├── /specs                 # 接口契约 YAML、Pydantic 模型代码
+    └── /tests                 # Gherkin 验收用例（覆盖正常、异常、边界、并发场景）
+    ```
+- **动作**：生成上述结构，并将核心业务规则摘要回传至本地知识库。
 
-**非功能性需求**：
-- 该功能需达到怎样的响应速度和并发使用要求？
-- 该功能需配置哪些身份校验、权限管控和数据防护规则？
-- 该功能需满足哪些运行稳定性和异常恢复相关要求？
-
-### 步骤 4：交付约束梳理
-
-通过提问理清交付约束，规避落地风险：
-1. 该需求的交付日期是何时？是硬性要求还是可灵活调整？
-2. 该需求是否依赖其它项目、系统或前置业务需求？
-3. 有无市场活动等外部约束因素？
-4. 该需求是一次性交付，还是分阶段交付？
-
-### 步骤 5：验收标准定义
-
-遵循 Given-When-Then 场景化描述句式定义验收标准，实现操作可复现、结果可验证：
-```
-Given [前置条件]
-When [具体操作]
-Then [预期结果]
-```
-
-### 步骤 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` - 完整需求分析示例
\ No newline at end of file
+## 四、异常兜底机制
+- **需求中途变更**：自动对比新旧需求差异，重新评估 Step 2 的影响范围，不强行沿用旧结论。
+- **技术不可落地**：主动识别技术瓶颈（如本地清单不支持的特性），输出替代方案，不强行设计。
+- **逻辑自相矛盾**：主动标注冲突点，给出最优取舍建议，等待用户确认。
+- **清单未命中**：若 `system_functions.md` 不存在，提示用户先初始化系统功能清单，再执行需求分析。
\ No newline at end of file
diff --git a/产品需求文档AI生成/skills/requirements-analysis/_meta.json b/产品需求文档AI生成/skills/requirements-analysis/_meta.json
deleted file mode 100644
index a5cbf18..0000000
--- a/产品需求文档AI生成/skills/requirements-analysis/_meta.json
+++ /dev/null
@@ -1,6 +0,0 @@
-{
-  "ownerId": "kn7795tvpv9b8mq9wvh01g2e3n8167q2",
-  "slug": "requirements-analysis",
-  "version": "1.0.0",
-  "publishedAt": 1772418037477
-}
\ No newline at end of file
diff --git a/产品需求文档AI生成/skills/requirements-analysis/references/complete-example.md b/产品需求文档AI生成/skills/requirements-analysis/references/complete-example.md
deleted file mode 100644
index eee76b4..0000000
--- a/产品需求文档AI生成/skills/requirements-analysis/references/complete-example.md
+++ /dev/null
@@ -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 阶段添加更多指标
-- 探索在未来版本中与移动应用集成
diff --git a/产品需求文档AI生成/skills/requirements-analysis/references/epic-template.md b/产品需求文档AI生成/skills/requirements-analysis/references/epic-template.md
deleted file mode 100644
index 382f0aa..0000000
--- a/产品需求文档AI生成/skills/requirements-analysis/references/epic-template.md
+++ /dev/null
@@ -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]
diff --git a/产品需求文档AI生成/skills/requirements-analysis/references/prioritization-methods.md b/产品需求文档AI生成/skills/requirements-analysis/references/prioritization-methods.md
deleted file mode 100644
index e79361d..0000000
--- a/产品需求文档AI生成/skills/requirements-analysis/references/prioritization-methods.md
+++ /dev/null
@@ -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 模型** | 关注用户满意度 | 以用户为中心，识别惊喜点 | 需要用户研究，复杂 |
-| **加权评分** | 自定义标准，利益相关者对齐 | 灵活，透明 | 需要权重共识 |
diff --git a/产品需求文档AI生成/skills/requirements-analysis/references/requirement-template.md b/产品需求文档AI生成/skills/requirements-analysis/references/requirement-template.md
deleted file mode 100644
index 68bb7e7..0000000
--- a/产品需求文档AI生成/skills/requirements-analysis/references/requirement-template.md
+++ /dev/null
@@ -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]：[缓解措施]
-
-## 备注
-[附加信息]
diff --git a/产品需求文档AI生成/skills/requirements-analysis/references/user-story-template.md b/产品需求文档AI生成/skills/requirements-analysis/references/user-story-template.md
deleted file mode 100644
index ee405a9..0000000
--- a/产品需求文档AI生成/skills/requirements-analysis/references/user-story-template.md
+++ /dev/null
@@ -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（可测试）**：故事必须有明确的验收标准，可以测试
diff --git a/产品需求文档AI生成/utils/agent.py b/产品需求文档AI生成/utils/agent.py
index af5a9c4..43d7c22 100644
--- a/产品需求文档AI生成/utils/agent.py
+++ b/产品需求文档AI生成/utils/agent.py
@@ -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()