| 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 命令体系集成
/skill requirement-analyzer
2.3 自进化机制
技能执行完毕后，自动触发以下自学习流程：
- 记录对话深度：统计本次需求澄清的轮数和覆盖率
- 识别遗漏模式：如果项目后期因需求不清而返工，分析是哪个维度的澄清不足
- 优化提问模板：针对项目领域（Web/ML/嵌入式等）调整默认提问集
- 更新触发词：根据用户实际使用的触发短语扩展
triggers 列表
可通过 Hermes 的 /curator run 触发技能优化审查。
2.4 身份感知 (SOUL.md)
读取 Hermes 的 SOUL.md 身份配置（如果存在），根据 Agent 的人设调整沟通风格：
- 如果 SOUL.md 定义 Agent 为 "严谨的架构师" → 输出更正式的结构化文档
- 如果 SOUL.md 定义 Agent 为 "敏捷教练" → 输出更口语化、迭代式的需求卡片
- 如果 SOUL.md 不存在 → 使用默认中立的分析师语气
3. 门禁标准
任务完成前必须通过以下检查点：
4. 常见逃避借口与反驳
| 借口 | 反驳 |
|---|
| "这个需求很简单，不需要分析" | 历史上 80% 的返工源于 "简单" 需求的隐性假设不一致。花 5 分钟写下来能省 5 小时。 |
| "用户没说清楚，我先猜着做" | 猜测是浪费的根源。使用 clarify 工具向用户提问，比猜错了重做高效 10 倍。 |
| "我是 AI，不需要问这么多" | 正因为是 AI，才更需要结构化澄清——你没有人类的直觉来填补空白。 |
| "等做完再回头改需求文档" | 需求文档不是事后记录，而是事前的灯塔。没有灯塔的航行注定偏航。 |
| "问了太多问题用户会烦" | 用户更烦的是交付了一个不是他们想要的东西。每轮问题不超过 3 个，保持聚焦。 |
