lync-cyber 需求分析 (req-analysis)
能力边界
- 能做: 解析用户原始需求、拆解功能点、编写用户故事、定义验收标准、标注优先级
- 不做: 架构设计、技术选型、UI设计、任务卡（T-{NNN}）拆分与 Sprint 划分（ARCH 完成后由 task-decomp 负责，本 skill 止于 F-{NNN} 功能点层）
输入规范
- 用户原始需求描述(自然语言)
- 可选: 已有PRD(用于需求变更场景)
输出规范
- 功能列表(F-{NNN})，每个包含:
- 用户故事: 作为{角色}，我希望{动作}，以便{价值}
- 验收标准: AC-{NNN} 可验证条件
- 优先级: P0/P1/P2
- 非功能需求(性能/安全/兼容性)
执行流程
可选前置: Grill 深度澄清
触发与启用协议见 design-grill §启用门（项目偏好或阶段入口一次询问；询问不等于启用，用户明确接受后调用 design-grill prd [范围]）。未启用即以 research user-interview 做普通澄清。Grill 总结返回后再进入 Step 1，不由 Grill 代写 PRD。
Step 1: 需求收集与澄清
- 解析用户输入，识别功能域和核心诉求
- 执行至少一轮 user-interview 确认核心需求方向，模糊/冲突需求通过追加提问澄清（提问通道见 research 指令2/2b）
- 产出: 原始需求清单(非正式，工作文档)
Step 2: 概述编写 (对应PRD §1)
- §1.1 背景与动机: 提炼项目背景(2-3句，回答"为什么做这个项目")
- §1.2 目标用户: 用户画像(角色 + 特征 + 核心诉求)
- §1.3 成功指标: 定义可量化指标，填写(指标 | 目标值 | 衡量方式)表
- 信息不足时通过research skill的user-interview指令确认
Step 3: 功能需求拆解 (对应PRD §2)
- 每个功能点编号 F-{NNN}，包含:
- 用户故事: "作为{角色}，我希望{动作}，以便{价值}"
- 验收标准: AC-{NNN}，每条必须可独立验证(给出具体条件而非模糊描述)
- 优先级: P0(必须有，缺失则产品不可用) / P1(重要，影响核心体验) / P2(锦上添花)
- 优先级决策记录: P0标注须说明"为什么是P0而非P1"——标准是"没有此功能产品是否完全不可用"
- 备注: 约束/边界条件/[ASSUMPTION]标注
- P0功能优先完成，P2可标注[ASSUMPTION]待确认
- 功能间有依赖时在备注中标注(供后续task-dep-analysis使用)
Step 4: 非功能需求 (对应PRD §3)
- §3.1 性能: 填写(场景 | 指标 | 目标值)表，如"列表加载 | 响应时间 | <200ms"
- §3.2 安全: 认证/授权/数据保护要求
- §3.3 兼容性: 平台/浏览器/设备要求
- 无明确要求时标注[ASSUMPTION]并给出合理默认值
Step 5: 约束/假设/术语 (对应PRD §4-§5)
- §4 约束与假设:
- 约束: 技术/业务/时间约束
- 假设: 前提假设，标注[ASSUMPTION]
- 调研记录: 引用research-note编号(如有)
- §5 术语表: 领域特定术语(术语 | 定义)表
- 经 context generate 分支 authoring 落图后 finalize 交付 PRD（操作细节见 context skill）
Anti-Patterns
- 禁止: 把 P0/P1/P2 优先级直接抄用户原话 —— 必须基于 MoSCoW 框架重新评估；否则出现"用户说全部 P0"的瀑布化退化
- 禁止: 漏写非功能性需求章节 —— 仅功能列表的 PRD 在 ARCH 阶段无法做技术选型，architect 阻塞
- 禁止: 在 PRD 写实现细节（"使用 React"）—— PRD 是 What/Why，实现细节属 ARCH 范畴；越界会让 architect 失去决策面
- 禁止: 把验收标准写成主观描述（"体验流畅"）—— AC 必须可测（Given-When-Then 或明确通过条件），否则下游 QA / TDD 无从验证
效率策略
- 先识别核心功能(P0)，再扩展次要功能
- 模糊需求及时澄清，不累积假设
- 执行流程各Step与PRD模板§1-§5一一对应，减少模板填充时的二次整理