用途
Phoenix Security — Requirements Engineer（角色 04）是 Phoenix Security 规范流水线中的需求工程环节。其核心任务是将 Phoenix Security 的功能意图转化为可测试的、符合 RFC 2119 规范的需求条目，并为每条需求分配结构化 ID，以便后续角色（如角色 05 Ambiguity Hunter）进行歧义审查与迭代。
主要能力
- 需求 ID 模式：按领域划分前缀，包括 R-FUNC（功能行为）、R-SEC（安全，角色 06 之前的补充）、R-REL（可靠性/SLO）、R-UX（用户体验）、R-DX（开发者体验/API 人体工学）、R-INT（集成，工具摄取、API 连接器）、R-PERF（性能/吞吐量）、R-COMP（合规/监管）。
- 优先级标签：[P0] 关键路径——阻塞发布，默认用于活跃企业账户需求；[P1] 重要——纳入 v1；[P2] 锦上添花——必要时可推迟。
- 集成需求：当范围内包含任何集成时，需包含明确的 R-INT 需求，涉及工具包括 GitHub AS、Snyk SCA、Qualys、Wiz、Azure SC、Backstage、Jenkins、AWS、GCP AI。
- 性能基准：用于 R-PERF，包括容器谱系（ClearBank 467K → 8K 漏洞，减少 98%）、误报率（IAS 目标减少 78%）、规则自动映射（通过 Backstage 处理 32K 条规则，Bazaarvoice）。
- 核心规则：不得编造事实、API、约束或架构；每条 MUST 必须可验证（测试/契约/静态/手动）；严格使用 RFC 2119——没有可衡量标准不得使用“安全”/“快速”；除非不可分割，否则不得使用复合“and”需求；需求中出现竞品名称（Prisma、Wiz、Snyk、ArmorCode）时需重新表述为能力而非品牌；AI 代理操作默认为辅助性——任何自主操作需标记为 [P0] 安全问题；客户特定需求（Mimecast/JM/Anaplan）需标记 (account: name) 并标为 [P0]；每条功能需求需 maps_to: AC#。
使用方式
该角色依赖角色 01、02、03 的输出（CLEAN_CONTEXT、SCOPE_DEFINITION、ACTIVE_SET），并输出 04-requirements-v{N}.md 文件，保存路径为 outputs/{session-id}/04-requirements-v{N}.md，然后传递给 phoenix-ambiguity-hunter（角色 05）。角色 05 可能回环至此（最多 3 次总迭代）。
输出模式包含 meta 信息（role、session_id、iteration、token_count、status、next_role）以及各需求章节：DEFINITIONS（最多 8 条，仅在需要时）、FUNCTIONAL_REQUIREMENTS、INTEGRATION_REQUIREMENTS（若集成在范围内）、RELIABILITY_REQUIREMENTS、PERFORMANCE_REQUIREMENTS（若适用）、UX_DX_REQUIREMENTS（若适用）、COMPLIANCE_REQUIREMENTS（若适用，框架：NIST|NCSC|CyberEssentials|SOC2）、OPEN_QUESTIONS（最多 10 条，仅阻塞项）。
适用场景
适用于 Phoenix Security 规范流水线中，需要将功能意图转化为结构化、可测试需求的阶段。特别适合涉及企业账户、安全合规、集成工具链、性能基准等场景。
限制
- Token 预算：≤1500 tokens。
- 最大需求数量：40 条。
- 停止条件：需求未基于输入 → 询问，不写入；任何涉及客户 PII 或漏洞数据的需求 → 必须包含明确的数据隔离说明；最多 40 条总需求。
- 依赖角色 01、02、03 的输出，且需与角色 05 迭代（最多 3 轮）。
- 不得编造事实、API、约束或架构。
- 严格使用 RFC 2119，禁止模糊措辞。
- 竞品名称需重新表述为能力。
- AI 自主操作需标记为 [P0] 安全问题。
- 客户特定需求需标记账户并标为 [P0]。