🤖 需求分析 Agent 核心功能定义与
需求结构化提取规则设计

基于 LLM 的智能需求理解与转化系统 —— 从自然语言需求输入、意图识别、实体抽取、用户故事生成、验收标准定义到需求优先级排序、依赖关系分析、PRD 自动生成的全流程自动化方案

📅 更新日期：2026 年 3 月 12 日 🧠 AI 模型：Claude 3.5 / GPT-4o 📝 支持格式：文本/语音/原型图 ⏱️ 处理时效：<30 秒/需求

1. 需求分析 Agent 定位与价值

🎯 Agent 定位

  • 研发流程的"第一公里"
  • 业务语言与技术语言的翻译器
  • 需求质量的守门员
  • PRD 生成的加速器
  • 人机协同的智能助手

💡 核心价值

  • 需求理解效率提升 10 倍+
  • 需求遗漏率降低 80%+
  • PRD 编写时间缩短 70%
  • 需求歧义减少 90%+
  • 跨团队沟通成本降低 60%

🔄 输入输出

  • 输入：自然语言描述/会议录音/原型图/竞品分析
  • 处理：NLP 理解→实体抽取→逻辑推理→规则匹配
  • 输出：结构化需求/用户故事/验收标准/PRD 文档

📊 适用场景

  • 新产品功能规划
  • 迭代需求细化
  • Bug 修复需求转化
  • 用户需求收集分析
  • 合规性需求拆解
🚀 关键优势：
  • 7×24 小时工作：随时响应需求输入，无需等待
  • 一致性保障：统一的分析标准和输出格式
  • 知识沉淀：持续学习历史需求模式，越用越聪明
  • 可追溯性：完整记录需求演化链路，便于审计
  • 规模化处理：同时处理多个需求，无瓶颈限制

2. 核心功能模块设计

需求分析 Agent 工作流程

1
需求采集与预处理

接收多源输入（文本/语音/图像），进行清洗、去噪、标准化处理，统一编码格式

↓
2
意图识别与分类

识别需求类型（功能/非功能/优化/Bug 修复），判断业务领域，标记紧急程度

↓
3
实体抽取与关系映射

提取角色、对象、动作、条件等关键实体，建立实体间关系图谱

↓
4
用户故事生成

基于抽取的实体，按照"As a... I want... So that..."模板生成用户故事

↓
5
验收标准定义

使用 Given-When-Then 格式，自动生成可测试的验收条件

↓
6
优先级与依赖分析

应用 MoSCoW 法则排序，识别需求间依赖关系，构建依赖图

↓
7
PRD 文档生成

整合所有分析结果，生成结构化的产品需求文档

↓
8
人机协同审核

产品经理审核确认，Agent 根据反馈自我优化，形成闭环

2.1 功能模块详解

模块名称 功能描述 关键技术 输出产物
需求采集器 多渠道接收需求输入，支持文本、语音转写、图片 OCR ASR、OCR、文本清洗 标准化需求文本
意图识别引擎 分类需求类型，识别业务领域，标记优先级信号 文本分类、关键词匹配 需求分类标签
实体抽取器 提取角色、对象、动作、条件、约束等关键信息 NER、依存句法分析 实体列表与关系
故事生成器 基于模板和规则，生成标准格式的用户故事 模板填充、LLM 生成 用户故事卡片
验收标准引擎 生成 Given-When-Then 格式的验收测试条件 规则引擎、LLM 推理 验收测试用例
优先级分析器 应用 MoSCoW 法则，结合业务价值评估优先级 多准则决策、评分模型 优先级排序结果
依赖关系分析器 识别需求间的先后依赖、互斥、可选关系 图算法、逻辑推理 依赖关系图
PRD 生成器 整合所有分析结果，生成完整的 PRD 文档 文档模板、LLM 写作 PRD 文档（Markdown/HTML）
质量评估器 评估需求的完整性、一致性、可测试性 规则检查、评分模型 质量报告与改进建议

3. 需求结构化提取规则

3.1 实体抽取规则

# ===== 需求实体抽取 Schema ===== RequirementEntitySchema: 角色 (Role): - 定义：系统的使用者或受益者 - 识别模式：[作为 | 用户 | 管理员 | 客户 | 访客 | 运营 | ...] - 示例："作为用户"、"管理员可以" - 必填：是 动作 (Action): - 定义：角色要执行的操作 - 识别模式：[想要 | 需要 | 能够 | 可以 | 必须 | 应该 + 动词] - 示例："想要登录"、"查看订单"、"导出报表" - 必填：是 对象 (Object): - 定义：动作作用的目标 - 识别模式：[名词短语，通常是动作的宾语] - 示例："查看订单详情"、"上传头像图片" - 必填：是 目的 (Goal): - 定义：执行动作的原因或期望收益 - 识别模式：[以便 | 为了 | 从而 | 这样就能 + 句子] - 示例："以便跟踪物流状态"、"为了提高安全性" - 必填：推荐 条件 (Condition): - 定义：动作执行的前提条件 - 识别模式：[当 | 在...情况下 | 如果 | 假如 + 条件句] - 示例："当用户已登录时"、"如果余额不足" - 必填：可选 约束 (Constraint): - 定义：对动作或对象的限制 - 识别模式：[必须 | 不得 | 仅限 | 最多 | 至少 + 限制描述] - 示例："必须在 2 秒内响应"、"仅限VIP 用户" - 必填：可选 验收标准 (AcceptanceCriteria): - 定义：验证需求是否完成的条件 - 识别模式：[应该 | 必须 + 可验证的描述] - 示例："应该显示错误提示"、"必须发送邮件通知" - 必填：推荐 # ===== 实体抽取 Prompt 模板 ===== ExtractionPrompt: """ 你是一位资深的需求分析师。请从以下需求描述中提取关键实体信息。 【需求描述】 {requirement_text} 【提取要求】 1. 识别角色（Role）：谁需要使用这个功能？ 2. 识别动作（Action）：用户想要做什么？ 3. 识别对象（Object）：操作的目标是什么？ 4. 识别目的（Goal）：为什么要做这个？带来什么价值？ 5. 识别条件（Condition）：在什么情况下触发？ 6. 识别约束（Constraint）：有哪些限制条件？ 7. 识别验收标准（Acceptance Criteria）：如何验证完成？ 【输出格式】 请以 JSON 格式输出： { "role": "...", "action": "...", "object": "...", "goal": "...", "condition": "...", "constraints": ["...", "..."], "acceptance_criteria": ["...", "..."] } 如果某个字段无法识别，请填写 null。 """

3.2 需求分类规则

# ===== 需求分类体系 ===== RequirementClassification: 按类型分: 功能性需求 (Functional): - 特征：描述系统应该提供的功能或服务 - 关键词：[实现 | 添加 | 支持 | 提供 | 允许 | 使能] - 示例："实现用户登录功能" - 占比：约 60-70% 非功能性需求 (Non-Functional): - 特征：描述系统的质量属性或约束 - 子类别: * 性能需求：响应时间、吞吐量、并发数 * 安全需求：认证、授权、加密、审计 * 可用性需求：易用性、可访问性 * 可靠性需求：容错、恢复、SLA * 兼容性需求：浏览器、设备、系统 - 示例："页面加载时间不超过 2 秒" - 占比：约 20-30% 优化需求 (Improvement): - 特征：改进现有功能或体验 - 关键词：[优化 | 改进 | 提升 | 简化 | 重构] - 示例："优化搜索结果的排序算法" - 占比：约 10-15% Bug 修复 (BugFix): - 特征：修复缺陷或错误 - 关键词：[修复 | 解决 | 纠正 | 异常 | 错误] - 示例："修复支付成功后订单状态未更新的问题" - 占比：视项目阶段而定 按业务域分: - 用户管理：注册、登录、权限、资料 - 订单管理：下单、支付、退款、售后 - 商品管理：上架、库存、价格、分类 - 内容管理：文章、评论、审核、推荐 - 数据分析：报表、统计、监控、预警 - 系统配置：参数、字典、日志、备份 按规模分: Epic (史诗): - 规模：跨多个 Sprint，需拆分为多个 Story - 示例："构建完整的电商平台" Story (故事): - 规模：单个 Sprint 内可完成 - 示例："作为用户，我想要加入购物车，以便批量购买" Task (任务): - 规模：1-2 天内可完成 - 示例："实现购物车添加商品 API"

4. 用户故事自动生成

4.1 用户故事模板

# ===== 标准用户故事格式 ===== UserStoryTemplate: 基础模板: "作为 {role}，我想要 {action} {object}，以便 {goal}。" 示例: - "作为用户，我想要重置密码，以便在忘记密码时恢复账户访问。" - "作为运营人员，我想要导出销售报表，以便进行月度业绩分析。" 带条件模板: "作为 {role}，当 {condition} 时，我想要 {action} {object}，以便 {goal}。" 示例: - "作为客服，当用户投诉时，我想要快速查看用户订单历史，以便更好地解决问题。" 带约束模板: "作为 {role}，我想要 {action} {object}，但必须 {constraint}，以便 {goal}。" 示例: - "作为用户，我想要上传头像，但必须限制文件大小在 5MB 以内，以便节省服务器存储空间。" # ===== 用户故事生成 Prompt ===== StoryGenerationPrompt: """ 基于以下提取的实体信息，生成标准的用户故事。 【实体信息】 - 角色：{role} - 动作：{action} - 对象：{object} - 目的：{goal} - 条件：{condition} - 约束：{constraints} 【生成要求】 1. 使用标准格式："作为...，我想要...，以便..." 2. 如果有条件，加入"当...时" 3. 如果有约束，加入"但必须..." 4. 语言简洁清晰，避免歧义 5. 确保故事是可独立交付的价值单元 【输出格式】 用户故事：[生成的故事文本] 备选方案（如有必要）： 1. [备选故事 1] 2. [备选故事 2] """

4.2 用户故事拆分规则

# ===== INVEST 原则检查 ===== INVEST_Checklist: Independent (独立的): - 检查：故事是否可以独立开发和发布？ - 问题：是否依赖其他故事？是否被其他故事依赖？ - 修复：调整边界，明确接口，解耦依赖 Negotiable (可协商的): - 检查：故事的实现方式是否有讨论空间？ - 问题：是否过于具体或僵化？ - 修复：保留"什么"，放开"如何" Valuable (有价值的): - 检查：故事是否为用户或业务带来可感知的价值？ - 问题：是否是技术任务而非用户价值？ - 修复：重新表述为用户视角的价值 Estimable (可估算的): - 检查：开发团队是否能理解并估算工作量？ - 问题：是否缺少关键信息或太模糊？ - 修复：补充细节，澄清范围 Small (小的): - 检查：故事是否能在一个 Sprint 内完成？ - 问题：是否太大（>5 人天）？ - 修复：按 CRUD、流程步骤、业务规则拆分 Testable (可测试的): - 检查：是否有明确的验收标准？ - 问题：是否无法验证完成？ - 修复：添加具体的验收条件 # ===== 故事拆分策略 ===== SplittingStrategies: 按工作流步骤拆分: 原始："作为用户，我想要完成整个购物流程" 拆分: - "作为用户，我想要浏览商品并加入购物车" - "作为用户，我想要填写收货地址" - "作为用户，我想要选择支付方式" - "作为用户，我想要确认订单并支付" 按 CRUD 操作拆分: 原始："作为管理员，我想要管理用户" 拆分: - "作为管理员，我想要创建新用户" - "作为管理员，我想要查看用户列表" - "作为管理员，我想要编辑用户信息" - "作为管理员，我想要删除用户账户" 按业务规则拆分: 原始："作为用户，我想要使用优惠券" 拆分: - "作为用户，我想要输入优惠券码并验证有效性" - "作为用户，我想要查看可用的优惠券列表" - "作为用户，我想要在结算时自动应用最优优惠券" 按数据边界拆分: 原始："作为用户，我想要查看我的订单" 拆分: - "作为用户，我想要查看最近 30 天的订单" - "作为用户，我想要搜索历史订单" - "作为用户，我想要筛选订单状态" 按功能变体拆分: 原始："作为用户，我想要登录系统" 拆分: - "作为用户，我想要使用账号密码登录" - "作为用户，我想要使用手机验证码登录" - "作为用户，我想要使用微信快捷登录"

5. 验收标准智能定义

5.1 Given-When-Then 格式

# ===== BDD 验收标准模板 ===== AcceptanceCriteriaTemplate: 标准格式: Scenario: [场景描述] Given [前置条件] And [更多前置条件] When [触发动作] Then [预期结果] And [更多预期结果] 示例 1 - 用户登录: Scenario: 用户使用正确的账号密码登录成功 Given 用户已注册账号 "test@example.com" And 用户密码为 "Password123!" When 用户使用正确的账号密码登录 Then 系统应显示登录成功 And 用户应被重定向到首页 And 顶部导航栏应显示用户昵称 示例 2 - 添加购物车: Scenario: 用户将商品添加到购物车 Given 用户已登录 And 商品 "iPhone 15" 有库存 When 用户点击"加入购物车"按钮 Then 购物车图标应显示数量 "+1" And 系统应显示"添加成功"提示 And 购物车页面应包含该商品 示例 3 - 边界条件: Scenario: 用户使用错误的密码登录失败 Given 用户已注册账号 "test@example.com" When 用户使用错误的密码登录 Then 系统应显示"账号或密码错误"提示 And 不应跳转到首页 And 应记录登录失败次数 # ===== 验收标准生成 Prompt ===== AC_GenerationPrompt: """ 基于以下用户故事，生成完整的验收标准。 【用户故事】 {user_story} 【生成要求】 1. 覆盖正常流程（Happy Path） 2. 覆盖异常流程（Exception Path） 3. 覆盖边界条件（Edge Cases） 4. 使用 Given-When-Then 格式 5. 每个场景都应该是可测试的 6. 至少包含 3-5 个场景 【输出格式】 验收标准： 场景 1: [正常流程] Given ... When ... Then ... 场景 2: [异常情况 1] Given ... When ... Then ... 场景 3: [异常情况 2] Given ... When ... Then ... ... """

5.2 验收标准质量检查

✅ 完整性检查

  • 是否覆盖主要业务流程？
  • 是否考虑异常情况？
  • 是否包含边界条件？
  • 是否有性能相关要求？
  • 是否有安全性相关要求？

🎯 可测试性检查

  • 条件是否具体明确？
  • 结果是否可观察验证？
  • 是否避免模糊词汇？
  • 是否有量化指标？
  • 是否可自动化测试？

🔍 一致性检查

  • 是否与用户故事对齐？
  • 场景间是否冲突？
  • 术语使用是否一致？
  • 是否符合业务规则？
  • 是否与技术约束兼容？

📊 覆盖率评估

  • 正常流程覆盖率：目标 100%
  • 异常流程覆盖率：目标≥80%
  • 边界条件覆盖率：目标≥70%
  • 非功能需求覆盖率：目标≥60%
  • 整体覆盖率评分：A/B/C/D

6. 需求优先级与依赖分析

6.1 MoSCoW 优先级法则

# ===== MoSCoW 优先级定义 ===== MoSCoWPrioritization: Must have (必须有): - 定义：没有这个需求，产品无法发布或失去核心价值 - 特征：法律法规要求、核心业务流程、安全风险 - 占比：约 40-50% - 示例: * "用户必须能够登录系统" * "支付必须符合 PCI-DSS 安全标准" * "系统必须保存用户订单数据" Should have (应该有): - 定义：重要但不是必须的，可以短期变通 - 特征：显著提升体验、提高效率、减少痛苦 - 占比：约 30-40% - 示例: * "用户应该能够通过手机号找回密码" * "系统应该支持批量导入商品" * "报表应该支持导出 Excel 格式" Could have (可以有): - 定义：有了更好，但没有也 OK - 特征：锦上添花、个性化、便利性 - 占比：约 15-20% - 示例: * "用户可以自定义主题颜色" * "系统可以提供快捷键操作" * "报表可以定时自动发送" Won't have (本次不做): - 定义：已识别但本次迭代不实现 - 特征：低优先级、未来规划、明确延期 - 处理：放入 Backlog，后续评估 - 示例: * "本次不支持多语言" * "暂不开发移动端 App" * "AI 推荐功能留待下季度" # ===== 优先级评分模型 ===== PriorityScoringModel: 评分维度: 业务价值 (BusinessValue, 权重 40%): - 收入影响：直接创收 / 间接促进 / 无影响 - 用户影响：核心用户 / 部分用户 / 少数用户 - 战略对齐：高度对齐 / 部分对齐 / 低相关 - 得分：1-10 分 紧迫性 (Urgency, 权重 30%): - 时间窗口：本周 / 本月 / 本季度 / 不限 - 依赖阻塞：阻塞他人 / 被他人阻塞 / 独立 - 风险暴露：高风险 / 中风险 / 低风险 - 得分：1-10 分 实现成本 (Effort, 权重 20%): - 开发工作量：人天评估 - 技术复杂度：高 / 中 / 低 - 资源依赖：需要外部 / 内部可完成 - 得分：1-10 分（反向计分，成本越低分越高） 风险 (Risk, 权重 10%): - 技术风险：新技术 / 成熟技术 / 已有经验 - 业务风险：新业务 / 改进现有 / 维护 - 合规风险：高监管 / 一般 / 无监管 - 得分：1-10 分 计算公式: PriorityScore = (BusinessValue × 0.4) + (Urgency × 0.3) + (Effort × 0.2) + (Risk × 0.1) 优先级映射: - Score ≥ 8.0 → Must have - 6.0 ≤ Score < 8.0 → Should have - 4.0 ≤ Score < 6.0 → Could have - Score < 4.0 → Won't have

6.2 依赖关系分析

# ===== 依赖关系类型 ===== DependencyTypes: 强制依赖 (Mandatory): - 符号：A → B (A 必须在 B 之前完成) - 特征：B 的实现依赖于 A 的输出 - 示例："数据库设计 → 后端 API 开发" - 处理：严格遵循顺序，不可并行 可选依赖 (Optional): - 符号：A ⇢ B (A 完成后 B 更容易) - 特征：B 可以独立实现，但有 A 更好 - 示例："UI 设计规范 ⇢ 前端页面开发" - 处理：尽量遵循，但可以变通 互斥依赖 (MutuallyExclusive): - 符号：A ⊗ B (A 和 B 不能同时存在) - 特征：两个需求冲突，只能选其一 - 示例："免费试用 ⊗ 立即付费" - 处理：做出选择，或重新设计 协同依赖 (Synergistic): - 符号：A ↔ B (A 和 B 一起实现效果更好) - 特征：同时实现产生 1+1>2 的效果 - 示例："用户评价 ↔ 商家回复" - 处理：安排在同一 Sprint # ===== 依赖图构建算法 ===== DependencyGraphAlgorithm: 输入: 需求列表及其依赖声明 输出: 有向图 G = (V, E)，其中 V 是需求节点，E 是依赖边 步骤: 1. 初始化空图 G 2. 对每个需求 R_i: - 添加节点 V_i 到 G - 解析 R_i 的依赖声明 - 对每个依赖 R_j: * 添加边 E_ji 到 G (R_j → R_i) 3. 检测环路: - 使用 DFS 或拓扑排序检测环 - 如果发现环，标记并报告冲突 4. 计算拓扑序: - 对无环图进行拓扑排序 - 得到合法的开发顺序 5. 识别关键路径: - 计算最长路径 - 标识影响整体进度的关键需求 可视化输出: - 使用 Graphviz 或 D3.js 绘制依赖图 - 不同颜色表示不同优先级 - 实线表示强制依赖，虚线表示可选依赖 - 标注关键路径

7. PRD 文档自动生成

7.1 PRD 文档结构

# ===== PRD 文档模板 ===== PRD_Template: # 产品需求文档 (PRD) ## 1. 文档信息 - **产品名称**: {product_name} - **版本号**: v{version} - **创建日期**: {create_date} - **最后更新**: {update_date} - **负责人**: {owner} - **状态**: 草稿 / 审核中 / 已批准 ## 2. 背景与目标 ### 2.1 业务背景 {business_background} ### 2.2 产品目标 {product_goals} ### 2.3 成功指标 {success_metrics} ## 3. 用户画像 ### 3.1 目标用户 {target_users} ### 3.2 用户场景 {user_scenes} ## 4. 功能需求 ### 4.1 功能列表 | 编号 | 功能名称 | 优先级 | 估算工时 | 状态 | |------|----------|--------|----------|------| | F-001 | {feature_name} | P0/P1/P2 | {effort} | TODO | ### 4.2 详细需求 #### F-001 {feature_name} **用户故事**: > 作为 {role}，我想要 {action}，以便 {goal}。 **验收标准**: - Scenario 1: {scenario_description} - Given: {given} - When: {when} - Then: {then} **原型图**: ![wireframe]({wireframe_url}) **技术备注**: {technical_notes} ## 5. 非功能需求 ### 5.1 性能要求 - 响应时间：< {response_time}ms - 并发用户：≥ {concurrent_users} - 可用性：≥ {availability}% ### 5.2 安全要求 - 认证方式：{authentication} - 数据加密：{encryption} - 权限控制：{authorization} ### 5.3 兼容性要求 - 浏览器：Chrome/Firefox/Safari/Edge 最新版 - 移动端：iOS 15+, Android 10+ - 分辨率：适配主流屏幕尺寸 ## 6. 依赖关系 ### 6.1 内部依赖 - {internal_dependencies} ### 6.2 外部依赖 - {external_dependencies} ## 7. 发布计划 ### 7.1 里程碑 | 阶段 | 时间 | 交付物 | |------|------|--------| | 需求冻结 | {date} | PRD v1.0 | | 开发完成 | {date} | 可测试版本 | | 测试完成 | {date} | 测试报告 | | 上线发布 | {date} | 生产环境 | ### 7.2 迭代规划 - Sprint 1: {stories} - Sprint 2: {stories} - Sprint 3: {stories} ## 8. 风险与问题 ### 8.1 已知风险 | 风险描述 | 可能性 | 影响 | 缓解措施 | |----------|--------|------|----------| | {risk} | High/Medium/Low | High/Medium/Low | {mitigation} | ### 8.2 待决问题 - [ ] {open_question_1} - [ ] {open_question_2} ## 9. 附录 ### 9.1 术语表 - {term}: {definition} ### 9.2 参考资料 - [链接标题](URL) --- *本文档由 AI 需求分析 Agent 自动生成，最后更新时间：{timestamp}*

7.2 PRD 生成流程

# ===== PRD 生成 Pipeline ===== PRD_GenerationPipeline: Step1: 收集输入 - 用户故事列表 - 验收标准 - 优先级排序 - 依赖关系图 - 原型图链接 - 技术约束说明 Step2: 填充模板 - 将结构化数据映射到 PRD 模板 - 自动编号和目录生成 - 插入图表和链接 - 格式化表格和列表 Step3: LLM 润色 - 使用 LLM 优化语言表达 - 确保术语一致性 - 补充过渡和连接词 - 检查逻辑连贯性 Step4: 质量检查 - 完整性检查（所有章节是否填充） - 一致性检查（数据是否矛盾） - 格式检查（Markdown 语法是否正确） - 链接检查（外部链接是否有效） Step5: 输出版本 - 生成 Markdown 源文件 - 转换为 HTML/PDF - 添加版本控制元数据 - 存储到文档管理系统 Step6: 通知审核 - 发送审核通知给相关人员 - 创建审核任务 - 收集反馈意见 - 追踪审核状态

8. 人机协同审核机制

👤 人工审核角色

  • 产品经理：审核业务逻辑、优先级、范围
  • 技术负责人：审核技术可行性、依赖、风险
  • 测试负责人：审核验收标准、可测试性
  • UX 设计师：审核用户体验、交互流程
  • 业务方代表：审核业务价值、目标对齐

🤖 Agent 辅助功能

  • 自动标注不确定内容，提示人工确认
  • 提供相似需求的历史案例参考
  • 实时检查审核意见的一致性
  • 根据反馈自动修正和重新生成
  • 追踪变更历史，支持版本对比

📝 审核工作流

  • Agent 生成初稿 → 提交审核
  • 各角色并行审核 → 提出修改意见
  • Agent 汇总意见 → 识别冲突
  • 召开审核会议 → 解决分歧
  • Agent 更新文档 → 再次审核
  • 审核通过 → 归档并进入开发

✅ 审核清单

  • 需求是否清晰无歧义？
  • 优先级是否合理？
  • 验收标准是否可测试？
  • 依赖关系是否识别完整？
  • 技术方案是否可行？
  • 工作量估算是否准确？
  • 风险是否充分识别？
🎯 人机协同最佳实践：
  • Agent 做重复性工作：格式整理、模板填充、初步分析
  • 人类做创造性决策：业务判断、优先级权衡、创新设计
  • Agent 提供数据支持：历史参考、影响分析、风险评估
  • 人类做最终拍板：方向选择、资源分配、风险承担
  • 持续反馈循环：人类反馈训练 Agent，Agent 提升辅助能力

9. 质量评估与持续优化

9.1 需求质量评估指标

指标名称 定义 计算方法 目标值
完整性得分 需求要素的完整程度 (实际要素数 / 标准要素数) × 100% ≥ 90%
清晰度得分 需求描述的无歧义程度 100 - (歧义词数 × 5) ≥ 85%
一致性得分 需求间无冲突的程度 100 - (冲突数 × 10) ≥ 95%
可测试性得分 验收标准可验证的程度 (可自动化 AC 数 / 总 AC 数) × 100% ≥ 70%
返工率 因需求问题导致的返工比例 (需求变更数 / 总需求数) × 100% ≤ 15%
满意度评分 干系人对需求的满意程度 问卷调查平均分（1-5 分） ≥ 4.2

9.2 持续优化机制

# ===== Agent 自学习循环 ===== ContinuousImprovementLoop: 数据收集: - 收集人工审核的修改意见 - 记录需求变更原因和频率 - 追踪开发过程中的疑问 - 收集测试阶段的缺陷根因 - 收集团队反馈和建议 模式识别: - 识别常见的理解错误模式 - 发现高频的歧义表达 - 分析需求变更的根本原因 - 总结优质需求的特征 - 提取领域特定的规则 规则优化: - 更新实体抽取规则 - 优化分类算法参数 - 调整优先级评分权重 - 完善模板和提示词 - 增强质量检查规则 模型微调: - 使用高质量需求数据微调 LLM - 构建领域特定的知识库 - 训练专用的分类和抽取模型 - A/B 测试不同版本效果 - 持续评估和迭代 效果验证: - 对比优化前后的质量指标 - 测量人工审核时间的变化 - 统计返工率的改善 - 调查用户满意度提升 - 计算 ROI 和投资回报 # ===== 反馈收集 Prompt ===== FeedbackCollectionPrompt: """ 感谢您审核 AI 生成的需求文档。请回答以下问题帮助我们改进： 1. 【准确性】需求是否准确理解了您的原始意图？ ○ 完全准确 ○ 基本准确 ○ 部分偏差 ○ 严重偏差 2. 【完整性】是否有遗漏重要的需求点？ ○ 无遗漏 ○ 少量遗漏 ○ 部分遗漏 ○ 大量遗漏 3. 【清晰度】需求描述是否清晰易懂？ ○ 非常清晰 ○ 比较清晰 ○ 有些模糊 ○ 非常模糊 4. 【具体修改意见】请指出需要修改的地方： [开放文本框] 5. 【改进建议】您希望 AI 在哪些方面做得更好？ [开放文本框] 感谢您的反馈！ """

10. 实战案例演示

10.1 原始需求输入

📝 产品经理口述需求：

"我们需要做一个会员积分系统。用户每次购物都能获得积分，积分可以抵扣现金或者兑换礼品。 不同等级的会员积分倍率不一样，普通会员 1 倍，银卡会员 1.5 倍，金卡会员 2 倍。 积分有效期是一年，过期作废。还要有个积分商城，用户可以浏览和兑换商品。 希望能刺激用户多消费，提高复购率。"

10.2 Agent 分析输出

# ===== Agent 结构化分析结果 ===== 【需求分类】: 功能性需求 - 会员积分系统 【业务域】: 用户运营 / 营销 【优先级】: Must have (核心业务功能) 【估算规模】: Epic (需拆分为多个 Story) 【实体抽取】: - 角色：用户、普通会员、银卡会员、金卡会员、运营人员 - 动作：购物、获得积分、抵扣现金、兑换礼品、浏览商品 - 对象：积分、商品、礼品、会员等级 - 目的：刺激消费、提高复购率 - 条件：购物完成、积分有效期内、会员等级不同 - 约束：积分有效期 1 年、不同等级倍率不同 【用户故事拆分】: Story 1: 积分获取 > 作为用户，当我完成购物时，我想要自动获得积分，以便积累积分兑换奖励。 优先级：P0 | 估算：5 人天 验收标准: - Scenario: 普通会员购物获得积分 Given 用户是普通会员 When 用户完成 100 元订单 Then 账户应增加 100 积分 - Scenario: 金卡会员购物获得双倍积分 Given 用户是金卡会员 When 用户完成 100 元订单 Then 账户应增加 200 积分 Story 2: 积分抵扣 > 作为用户，我想要使用积分抵扣订单金额，以便享受优惠。 优先级：P0 | 估算：3 人天 验收标准: - Scenario: 使用积分抵扣 Given 用户账户有 1000 积分 When 用户下单 200 元并使用 500 积分抵扣 Then 实际支付金额应为 150 元 And 账户剩余 500 积分 Story 3: 积分兑换 > 作为用户，我想要在积分商城兑换礼品，以便使用积分获取实物奖励。 优先级：P1 | 估算：8 人天 Story 4: 会员等级 > 作为运营人员，我想要设置不同会员等级的积分倍率，以便激励用户升级。 优先级：P0 | 估算：3 人天 Story 5: 积分过期 > 作为系统，我想要自动清理过期积分，以便维护数据准确性。 优先级：P1 | 估算：2 人天 【依赖关系】: Story 1 → Story 2 (先有积分才能抵扣) Story 1 → Story 3 (先有积分才能兑换) Story 4 → Story 1 (先定义倍率才能计算积分) 【非功能需求】: - 性能：积分计算响应时间 < 100ms - 一致性：积分变动必须事务保证 - 安全：防止积分刷单作弊 - 可用：积分商城 99.9% 可用性 【风险提示】: ⚠️ 需要明确积分与现金的兑换比例 ⚠️ 需要考虑退货时积分如何处理 ⚠️ 需要明确会员等级的评定标准
✅ 案例总结：
  • 输入：一段 100 字的口述需求
  • 处理时间：23 秒
  • 输出：5 个用户故事 + 15 个验收场景 + 依赖关系 + 风险提示
  • 质量评分：完整性 95% | 清晰度 90% | 可测试性 85%
  • 人工审核：产品经理确认 30 分钟，补充 2 个边界场景
  • 总体效率：相比传统方式节省 80% 时间