---
name: requirement-analyzer
description: Use when the user presents a vague, ambiguous, or underspecified task. Conducts structured multi-turn dialogue to extract true requirements with ~95% clarity before any code is written.
triggers: [requirement, 需求, 需求分析, clarify, interview, 澄清, what should I build, 我该做什么, vague, 模糊]
version: 1.0.0
author: Ow1onp
---

# 需求分析器 (Requirement Analyzer)

## 1. 概述

软件开发最大的浪费来源于需求不清。本技能在编写任何代码之前，通过结构化的多轮对话，将模糊的用户意图转化为明确、可执行的需求文档。核心理念：**宁可在需求阶段多花 20 分钟，也不要在编码阶段浪费 2 小时**。

融入 Hermes Agent 的持久记忆能力——跨会话保持需求上下文，即使隔天继续，也不丢失已澄清的约束。

## 2. 核心流程

### 2.1 五轮需求澄清框架

```
第一轮：目标与范围 (Goal & Scope)
  ├─ 这个功能/项目的最终目标是什么？
  ├─ 谁会使用它？在什么场景下？
  └─ 成功的定义是什么？(可量化指标)

第二轮：约束与边界 (Constraints & Boundaries)
  ├─ 技术栈限制？(语言、框架、平台)
  ├─ 性能要求？(响应时间、吞吐量)
  ├─ 安全/合规要求？
  └─ 明确 "不做什么" (Out of Scope)

第三轮：数据与接口 (Data & Interfaces)
  ├─ 输入是什么？格式？来源？
  ├─ 输出是什么？格式？目标？
  ├─ 需要集成哪些外部系统？
  └─ 数据量级估计？

第四轮：异常与边缘 (Edge Cases & Errors)
  ├─ 输入为空/非法时怎么办？
  ├─ 依赖服务不可用时怎么办？
  ├─ 并发/竞态条件如何处理？
  └─ 用户最可能犯的 3 个错误是什么？

第五轮：优先级与分期 (Priority & Phasing)
  ├─ 哪些是 MVP 必须有的？
  ├─ 哪些可以 v1.1 / v2.0 再做？
  └─ 有没有 20% 工作量带来 80% 价值的切入点？
```

### 2.2 Hermes 命令体系集成

```bash
# 在 Hermes 会话中直接加载本技能
/skill requirement-analyzer

# 需求分析结果自动保存到 Hermes 记忆
# 下次会话可通过记忆回溯已澄清的约束
# Hermes 会使用 memory 工具保存关键需求结论
```

### 2.3 自进化机制

技能执行完毕后，自动触发以下自学习流程：

1. **记录对话深度**：统计本次需求澄清的轮数和覆盖率
2. **识别遗漏模式**：如果项目后期因需求不清而返工，分析是哪个维度的澄清不足
3. **优化提问模板**：针对项目领域（Web/ML/嵌入式等）调整默认提问集
4. **更新触发词**：根据用户实际使用的触发短语扩展 `triggers` 列表

可通过 Hermes 的 `/curator run` 触发技能优化审查。

### 2.4 身份感知 (SOUL.md)

读取 `~/.hermes/SOUL.md`（如果存在），根据 Agent 的人设调整沟通风格：

- 如果 SOUL.md 定义 Agent 为 "严谨的架构师" → 输出更正式的结构化文档
- 如果 SOUL.md 定义 Agent 为 "敏捷教练" → 输出更口语化、迭代式的需求卡片
- 如果 SOUL.md 不存在 → 使用默认中立的分析师语气

## 3. 门禁标准

任务完成前必须通过以下检查点：

- [ ] 五个维度（目标/约束/数据/异常/优先级）至少各有一个明确回答
- [ ] "不做什么" (Out of Scope) 已明确列出并得到用户确认
- [ ] 成功的可量化指标已定义（如"页面加载 < 200ms"而非"要快"）
- [ ] 至少识别了 3 个边缘情况
- [ ] 需求文档已保存到项目目录或 Hermes 记忆中
- [ ] 用户明确表示 "需求已清晰，可以开始编码"

## 4. 常见逃避借口与反驳

| 借口 | 反驳 |
|------|------|
| "这个需求很简单，不需要分析" | 历史上 80% 的返工源于 "简单" 需求的隐性假设不一致。花 5 分钟写下来能省 5 小时。 |
| "用户没说清楚，我先猜着做" | 猜测是浪费的根源。使用 `clarify` 工具向用户提问，比猜错了重做高效 10 倍。 |
| "我是 AI，不需要问这么多" | 正因为是 AI，才更需要结构化澄清——你没有人类的直觉来填补空白。 |
| "等做完再回头改需求文档" | 需求文档不是事后记录，而是事前的灯塔。没有灯塔的航行注定偏航。 |
| "问了太多问题用户会烦" | 用户更烦的是交付了一个不是他们想要的东西。每轮问题不超过 3 个，保持聚焦。 |