requirements-analysis

需求分析（英文）

中文版： 请参阅对应的中文技能。

适用场景

• 需要在真实项目背景下进行需求分析。
• 需要可直接用于执行、评审或后续跟进的输出。

工作流

1. 阅读并遵循 Progressive disclosure 中列出的主提示词（覆盖范围、结构、质量标准）。
2. 仅补充会影响结果的项目背景：范围、环境、约束、风险、依赖项、预期交付物。
3. 如果输入不完整，先返回可用的初稿，并明确标注假设和信息缺口。
4. 默认使用 Markdown；仅在用户提出要求时切换格式。

核心约束

• 按风险 / 业务影响确定优先级，不要一视同仁。
• 将已确认的事实与当前假设分开。
• 不要编造用户未提供的端点、字段、环境或根本原因。
• 确保输出可执行：场景具体、优先级明确、后续步骤清晰。

渐进式披露

• 输出前，阅读并遵循 prompts/requirements-analysis.md（最低覆盖要求、输出结构、质量标准）。
• 用户要求 Excel/CSV/JSON/Word 格式时：阅读 output-formats.md 并遵循格式要求。
• 有合适的现成模板时：使用 output-templates/ 下的对应文件。
• 对于深入的框架 / 故障排查 / 架构说明，只阅读 references/ 下相关文件，不要加载整个目录。
• 对于格式转换或辅助检查，优先使用现有的 scripts/，不要重复造轮子。
• 评估 / 回归测试此技能时：使用 evals/ 和 skill-up。

交付前检查清单

• 遵循了主提示词的输出结构
• 最低覆盖重点：范围摘要、业务目标、明确和不明确的需求、缺失规则、边界或异常情况、可测试性缺口、依赖项和影响、风险优先级，……（详见主提示词）
• 覆盖了最低检查清单，或说明了省略项
• 高风险事项标明了明确的优先级
• 未编造用户未提供的细节
• 已标注假设和信息缺口

常见问题

• 范围 / 背景缺失时，不要假装内容完整。
• 不要把所有事项都视为同等重要。
• 不要遗漏假设和信息缺口。
• 不要堆砌与当前工具链无关的通用理论。