By name: 610-feature-clarify description: 功能需求澄清技能。当需要开发新功能时触发：(1)分析功能需求和业务场景, (2)澄清需求模糊点和边界条件, (3)定义验收标准并生成需求文档。 alwaysApply: false author: "axeon(23231269@qq.com)" version: "1.0.0"
功能需求澄清
项目环境检测
从当前目录向上查找 project-info.md，最多 3 层，找到后记为 PROJECT_ROOT。详见 检测方法与前置检查。未找到 → 提示用户先执行 0-init。
角色职责
| 角色 | 职责 | 智能体 |
|---|---|---|
| 主导 | 需求分析澄清 | product-manager |
| 协作 | 技术可行性评估 | system-architect |
| 协作 | 测试要点识别 | test-engineer |
输入
| 输入项 | 来源 | 说明 |
|---|---|---|
| 功能需求描述 | 用户输入 | 功能名称和基本描述 |
| 现有PRD | PROJECT_ROOT/requirement/prds/README.md |
现有产品需求文档 |
| 相关功能 | PROJECT_ROOT/issue/features/ |
已完成功能参考 |
输出
| 输出项 | 位置 | 说明 |
|---|---|---|
| 功能需求文档 | PROJECT_ROOT/issue/features/FEATURE-{YYMMDD}-{topic}.md |
本功能需求文档 |
| 更新PRD | PROJECT_ROOT/requirement/prds/README.md |
合并后的主PRD（唯一汇总文档） |
| 变更记录 | PROJECT_ROOT/requirement/prds/CHANGELOG.md |
需求变更历史 |
执行流程
1. 需求分析
分析功能需求的以下内容：
| 分析维度 | 内容 |
|---|---|
| 业务场景 | 功能解决什么问题 |
| 用户角色 | 哪些角色使用这个功能 |
| 核心流程 | 功能的主要操作流程 |
| 边界条件 | 异常情况处理 |
| 数据需求 | 涉及哪些数据实体 |
2. 需求澄清
通过提问澄清以下问题：
| 问题类型 | 示例 |
|---|---|
| 功能边界 | "这个功能是否包含XX场景？" |
| 业务规则 | "XX情况下的处理逻辑是什么？" |
| 权限控制 | "哪些角色可以操作？" |
| 数据范围 | "数据查询的时间范围限制？" |
| 异常处理 | "失败时的重试策略？" |
3. 验收标准定义
定义明确的验收标准（AC）：
| AC编号 | 验收标准 | 测试要点 |
|---|---|---|
| AC-001 | 功能正常流程可用 | 正向流程测试 |
| AC-002 | 异常处理正确 | 异常场景测试 |
| AC-003 | 权限控制有效 | 权限边界测试 |
| ... | ... | ... |
4. 生成功能需求文档
文件命名格式: FEATURE-{YYMMDD}-{一句话汇总信息}.md
文档内容:
# FEATURE-{YYMMDD}-{功能名称}
## 基本信息
- 创建日期: {YYYY-MM-DD}
- 功能名称: {功能名称}
- 功能简述: {一句话描述}
## 需求背景
{业务场景描述}
## 功能范围
### 包含内容
- {功能点1}
- {功能点2}
### 不包含内容
- {排除的功能点}
## 用户故事
作为{role}，我希望{需求}，以便{价值}
## 验收标准
| AC编号 | 验收标准 | 优先级 |
|--------|---------|--------|
| AC-001 | {标准描述} | P0 |
## 技术提示
- 涉及模块: {模块列表}
- 数据库变更: {是/否}
- 接口变更: {是/否}
## 关联文档
- PRD: {PRD链接}
- 技术方案: {后续生成}
5. 文档合并
合并到PRD:
- 读取现有
PROJECT_ROOT/requirement/prds/README.md - 在功能清单中增加本功能
- 更新相关章节
追加CHANGELOG:
## {YYYY-MM-DD} FEATURE-{功能名称}
- 类型: 新增功能
- 描述: {功能简述}
- 文档: FEATURE-{YYMMDD}-{topic}.md
- 状态: 需求已澄清
⚠️ 完成验证（强制，全自动执行）
- 强制调用 611-feature-clarify-review
- 如果评审不通过（< 95），自动修复问题，然后回到步骤 1（最多 5 轮）
- 直到评审通过（≥ 95），才向用户报告最终结果
此流程全自动执行：中间不暂停、不询问、不汇报。 未收到通过确认前，禁止结束本技能任务。
人工检查点 ★
评审通过后必须人工确认:
- 功能范围是否准确
- 验收标准是否可测试
- 边界条件是否完整
- 是否遗漏关键需求
确认后流转: 进入 620-feature-dev
输出要求
功能需求文档位置: PROJECT_ROOT/issue/features/FEATURE-{YYMMDD}-{topic}.md
PRD更新位置: PROJECT_ROOT/requirement/prds/README.md
CHANGELOG位置: PROJECT_ROOT/requirement/prds/CHANGELOG.md
流转关系
输入: 功能需求描述
↓
610-feature-clarify
↓
人工确认 ★
↓
输出: 功能需求文档 + 更新PRD
↓
进入: 620-feature-dev