leikegeek/requirement-intake

---

name: requirement-intake displayName: 需求录入与解析 description: 解析需求文档或口头需求，提取结构化需求要素，建立任务契约。适用于流水线 A 的第一阶段。 triggers: ["需求录入", "需求解析", "开始需求", "/start"] autoTrigger: true version: '1.0.2'

需求录入与解析

技能目标

从用户提供的需求文档或口头描述中，提取结构化的需求要素，并建立任务契约（设计模式），为后续技术方案设计做准备。

核心原则

1. 需求编号推荐：需求编号（SV-ID）是跨团队协作的唯一 key，贯穿技术方案、分支、变更清单、技术参考文档全链路。强烈建议提供，但不强制阻塞——轻量需求可跳过。
2. 结构化提取：无论输入形式如何，最终产出标准化的需求要素。
3. 主动澄清：信息不足时优先提问，不假设不猜测。

需求完整性门禁

进入 A2 技术方案设计前，必须完成需求完整性检查。下表是内部检查清单，用于识别缺口；不要把整张表机械地抛给用户。只有当缺口会影响业务正确性、代码落点、数据口径、权限安全或验收方式时，才形成「待澄清问题列表」并向用户确认；阻断性问题未确认前不得进入技术方案设计。

| 检查项 | 必须明确的内容 | |--------|----------------| | 业务目标 | 要解决的业务问题、目标用户、成功标准 | | 主流程 | 从触发到完成的核心业务步骤 | | 异常流程 | 失败、无数据、重复提交、外部依赖异常等主要分支 | | 边界条件 | 输入范围、状态边界、数量限制、时间窗口 | | 权限与角色 | 哪些角色可操作、是否涉及越权或数据隔离 | | 数据口径 | 关键字段定义、统计口径、状态含义、数据来源 | | 上下游依赖 | 调用方、被调用方、消息、定时任务、第三方系统 | | 验收标准 | 可检查的功能验收、测试方式、非功能要求 | | 兼容与迁移 | 是否影响历史数据、旧接口、已有配置或开关 |

澄清问题应按影响编码决策的优先级排序，优先使用选择题。为控制上下文成本，默认每轮最多提出 3-5 个阻断性问题；非阻断缺口记录为假设或“不在本次范围”，不要反复追问。

输入形式

形式一：带需求编号的正式需求

用户提供 SV-ID 和需求文档（或文档路径）。

形式二：口头需求（无需求编号）

用户用自然语言描述需求，无正式文档。此时需要：

1. 提炼需求要素
2. 提示用户提供需求编号（非阻塞，用户可跳过）

工作流程

1. 解析需求

• 有需求文档时：提取编号、标题、描述、验收标准、约束条件
• 口头需求时：通过对话提炼以上要素，然后建议补充需求编号（用户可跳过）

2. 读取项目上下文

• 优先读取 AGENTS.md 获取项目画像（技术栈、架构模式、模块结构、编码规范）
• 如果 AGENTS.md 信息不足，补充扫描构建文件（pom.xml / build.gradle / package.json）
• 检索与需求相关的已有代码

3. 建立任务契约

输出并确认以下契约：

需求编号：SV-xxxxx（或「无（轻量需求）」，用户确认跳过时）
需求标题：xxx
模式：设计模式
目标：[从需求提取]
范围：[待澄清]
允许写入路径：仅文档目录
禁止项：不修改项目代码、不执行构建命令
验收标准：[从需求提取或对话确认]

4. 输出需求摘要

将提取的需求信息整理为结构化摘要，供后续技术方案设计使用。

5. 完整性门禁判定

• 全部明确：输出「需求完整性门禁：通过」，并列出已确认的关键约束。
• 存在阻断缺口：输出「需求完整性门禁：未通过」，只列出会影响设计/编码的待澄清问题，停止进入 A2，等待用户补充。
• 仅存在非阻断缺口：输出「需求完整性门禁：通过（带假设）」，记录假设或不在范围项，允许进入 A2，但必须在方案中标注。
• 用户确认暂不覆盖：若用户明确表示某项不在本需求范围内，记录为「不在范围」并写入任务契约或需求摘要。

复杂度判定

需求完整性门禁通过后，根据以下条件判定需求复杂度：

轻量需求（满足全部）

• 影响模块数 <= 1
• 无跨系统/跨服务调用变更
• 无新技术组件引入
• 无数据模型重构
• 无接口破坏性变更

标准需求（满足任一）

• 影响模块数 >= 2
• 涉及跨系统/跨服务调用
• 引入新技术组件
• 数据模型重构
• 接口破坏性变更
• 用户明确要求完整方案

判定为「轻量需求」时，A2 走精简路径：

• 跳过 2-3 方案对比，直接输出单方案
• 跳过数据规模澄清（已有需求的简单迭代，数据规模已有定论或不影响方案）
• 仍保留 4 段结构、自评审和硬门禁
• architect 子代理不触发

判定结果向用户展示并确认，用户可覆盖（如将轻量升级为标准）。

缺少需求编号时的处理

如果用户未提供需求编号，提示（非阻塞）：

建议提供需求编号以保证全链路可追溯（技术方案 → 分支 → 变更清单 → 技术参考文档）。

• 如果有正式编号（如 SV-34577），请直接告知
• 如果这是一个小改动且暂无编号，可以跳过，后续产出物以时间戳或简短标识命名

用户确认跳过后，不再追问，继续流程。

产出

• 结构化需求摘要
• 任务契约（设计模式）
• 项目上下文扫描结果