用途：在技术设计或编码前使用，适用于涉及后端功能、API、异步任务、存储变更或服务集成的需求，将业务目标转化为后端实现边界。触发场景包括用户说“分析一下这个需求”“帮我梳理需求”或 requirement analysis，以及需求尚未明确、需要转化为后端边界时。
主要能力：按优先级获取需求内容（对话上下文、用户提供路径、自动发现当前工作目录的 PRD/需求文档）；用后端术语重述业务请求；区分已确认事实、假设与未知项；用 EARS 句式（When/While/If/The system shall）消除歧义；拆解领域实体与状态转换、API 或消息契约、读写路径、数据校验、权限与租户隔离、一致性与幂等、失败处理与重试、可观测性、性能与容量、发布回滚约束；输出含核心结论、需求追溯表、目标、范围内外、参与方依赖、领域模型、API 或事件契约、业务规则、非功能需求、验收标准、风险与待确认项的需求文档。
使用方式：需求分析按四步进行——理解请求、拆解后端维度、输出需求文档、定义验收标准。会做现状验证，检查数据可用性、接口可行性、依赖就绪度。自动发现文档时使用：ls -t $(find . -maxdepth 3 ( -name "prd" -o -name "requirement" -o -name "需求" ) -name "*.md" 2>/dev/null) 2>/dev/null | head -5。验收标准需覆盖正常、无效输入、重复请求、依赖失败、权限失败路径，并标注可验证状态（✅/⚠️/❌）。完成后提示可选后续步骤 /go-backend-technical-design 或 /go-backend-architecture，等待用户明确指示，不自动进入下一阶段。
限制：不进入包结构或表结构设计，不写具体 IDL、数据库 schema 或代码片段；需求层只描述需要哪些参数、类型与互斥关系。不隐藏未知项，需求过大时拆分 MVP、加固、规模化三阶段。参考资料快速问题清单见 references/checklist.md。所需数据、接口或基础设施是否已就绪需实际核查，资料未提供具体平台与效果信息。