Requirement analyzer

需求分析器 (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 命令体系集成

# 在 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 个，保持聚焦。