| 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 个,保持聚焦。 |