Kirrito-k423 需求分析
目标
输出一份服务于立项、范围确认、技术选型、排期和验收的开发前决策合同。报告必须回答：
- 客户和用户真正需要什么；
- 需求由哪些业务、用户、功能、质量、接口和约束组成；
- 现有技术为什么不满足，有哪些候选方案，为什么推荐某条路线；
- 项目在技术、数据、资源、交付、运营和合规上是否可行；
- 需要多少工作量，价值是否大于成本和风险；
- 每条需求如何定义、如何验收、由谁批准。
固定叙事时点
无论输入发生在开发前还是开发后，最终需求报告都冻结在正式开发决策发生前。
| 可以写 | 不可以写 |
|---|---|
| 系统应、必须、拟采用、计划验证 | 已实现、已支持、已通过、已上线 |
| 候选方案、PoC 结论、预期收益和风险 | 完成率、提交清单、测试结果、线上效果 |
| 验收对象、环境、步骤、阈值和证据形式 | 验收通过/失败结论 |
| 工作量区间、依赖和置信度 | 根据实际耗时倒填的“原估算” |
| 推荐、拒绝、延后或继续调研 | 因为代码已经这样写，所以选择该方案 |
如果用户提供已完成代码、测试、基准或日志：
- 把它们放入分析工作底稿，用于识别当前接口、约束、异常场景、技术成熟度和估算依据；
- 不用代码结构定义用户需求，不用测试名证明客户价值；
- 将实测数字视为候选基线或 PoC 证据，只有在环境、统计口径和阈值责任人确认后才能进入验收计划；
- 正文不描述实现完成状态，不建立“需求—已完成代码—测试结果—上线结果”矩阵；
- 若材料暴露出需求冲突，回到用户、场景和决策条件请求确认，不以当前实现自动覆盖需求。
强制规则
- **先识别需求，再研究方案。**新模型、新算法、新算子或新硬件只是机会信号，不自动构成需求。
- **区分需求与解决方案。**客户提出的按钮、模型、接口或框架是候选手段，必须追问其任务、影响和期望结果。
- **技术调研必须由需求驱动。**每个候选方案都用同一组需求、质量、成本和风险准则评价。
- **估算必须表达不确定性。**记录范围假设、证据、区间、依赖、风险缓冲和失效条件，不输出伪精确人天。
- 需求必须可验收。“更快、稳定、易用、精度无损、成本低”等词必须转换为有环境边界的可观察阈值。
- **只用必要方法。**每种方法都要对应一个待消除的不确定性，禁止为了显得专业机械堆叠术语。
- **不得虚构。**不编造客户、访谈、业务损失、预算、阈值、候选方案、审批或历史决策。
- **保护无关工作。**遵循仓库中的
AGENTS.md，记录 Git 状态，不修改实现代码或无关文件，除非用户另行要求。
输入与就绪条件
先收集用户已提供的材料，再只定位完成报告所需的上下文。
最小输入
- 一个问题、机会、客户诉求或技术机会；
- 目标产品、系统或能力的大致边界；
- 预期报告路径或交付形式。
强支持输入
- 客户访谈、工单、事故、日志、业务数据、现行流程和绕行方式；
- 用户角色、决策者、运维者、维护者和受影响团队；
- 当前架构、接口、性能基线、代码、测试、实验和技术文档；
- 候选方案、预算、时间窗、人员能力、依赖、合规和资源约束；
- 指标责任人和最终验收人。
材料不足时不要停在“信息不完整”。先生成待确认的问题清单、假设、所需证据和可继续推进的分析部分；只有缺少的选择会实质改变目标、范围、方案或立项结论时，才向用户请求决策。
工作流程
阶段零：建立分析合同
- 定义产品层级、分析对象、决策问题、报告读者、时间边界和明确非目标。
- 记录当前已知事实、假设、未知项、资料来源和责任人。
- 确认报告采用开发前语态；将代码、测试和运行材料标记为内部技术证据。
- 从
references/method-selection.md选择能消除当前不确定性的方法。
**输出：**分析范围、决策清单、材料清单、假设与待确认项、方法选择记录。
**评审门：**能够说明“这份报告要支持哪个决定”，而不是只知道“公司要求补一份文档”。
阶段一：识别客户真实需求
- 建立干系人地图：客户、直接用户、决策者、运维、维护、测试、安全/合规和受影响团队。
- 根据场景选择访谈、现场观察、需求工作坊、问卷、文档/现有系统分析。
- 使用 JTBD 或运行场景描述触发、用户任务、期望进展、当前绕行和不可接受结果。
- 使用 5 Whys、问题树或假设驱动分析区分症状、直接原因、系统性原因和竞争假设。
- 量化问题覆盖面、频率、严重度、成本、时间和不做的后果；无法量化时记录测量计划。
- 用目标树连接业务/工程结果、用户能力和系统能力。
**输出：**干系人表、场景/JTBD、现状流程、问题陈述、根因假设、目标树、成功结果。
**评审门：**目标用户、触发场景、当前差距、期望结果和不做的后果均已定义或显式待确认。
阶段二：拆解需求组成
- 使用系统上下文图确定控制边界、外部参与者、依赖和接口。
- 按问题选择业务流程/泳道、用例、状态机、时序图、DFD、领域模型或数据血缘。
- 按用户能力进行功能分解，不按源码目录分解。
- 建立稳定需求类型和 ID：
BR-*：业务或工程价值；UR-*：用户需要完成的任务；FR-*：系统功能行为；QR-*：性能、可靠性、安全、兼容、可用、可维护、可观测、成本等质量要求；IR-*：用户、系统、模块、硬件和数据接口；CON-*：平台、资源、进度、合规和设计约束。
- 主动覆盖正常、边界、无效输入、部分失败、超时、重试、恢复、回退、升级、维护和退役场景。
- 记录范围内、范围外、依赖、冲突和隐含假设。
**输出：**Context、流程/场景模型、功能树、需求目录草案、接口与约束、非目标。
**评审门：**每个目标能下钻到用户任务和系统要求；正常、异常、质量、接口和约束没有无意遗漏。
阶段三：调研并选择技术方案
- 建立现有技术基线：当前能力、瓶颈、测量环境、适用边界和不改变时的上限。
- 扫描标准、论文、官方文档、竞品、开源代码、内部复用、采购、集成、自研和流程优化路径。
- 至少保留“不做/维持现状”和“最小改造”作为比较基准。
- 对每个候选记录：原理、需求覆盖、成熟度、依赖、性能/精度上限、兼容、维护、成本、风险和可逆性。
- 只为会改变决策的关键未知设计 PoC；冻结模型、数据、硬件、软件、精度、并行、样本、预热、重复和统计口径。
- 使用价值—成本—风险矩阵；架构质量冲突明显时使用 ATAM 风格效用树和质量场景。
- 形成技术决策记录：推荐方案、拒绝方案、理由、假设、代价、技术债和重审触发器。
**输出：**技术基线、候选清单、PoC 计划/证据、权衡矩阵、技术决策记录。
**评审门：**推荐方案满足所有 Must 需求；关键未知已验证或有明确验证计划；选择理由不依赖“已经实现”。
阶段四：评估可行性、工作量和值不值得做
分别评估：
- 技术可行性：原理、能力、性能、精度、规模、兼容和成熟度；
- 数据可行性：数据存在性、质量、代表性、许可和隐私；
- 资源可行性：算力、存储、网络、环境、预算和供应；
- 交付可行性：团队能力、跨团队依赖、工期、关键路径和组织边界；
- 运营可行性：部署、观测、支持、回退、升级和维护；
- 合规可行性：安全、隐私、许可证、行业规则和供应链。
工作量评估：
- 按用户能力和交付物建立 WBS，包含设计、开发、数据、测试、集成、迁移、运维、文档与协作；
- 结合类比估算、自下而上估算和三点估算；
- 对高未知工作先执行 Spike/PoC；
- 记录 O/M/P、范围假设、依赖、风险缓冲、证据和置信度；
- 使用关键路径判断工期，不把总人天简单除以人数。
价值判断：
- 用户/业务结果、工程阻塞、复用价值和战略依赖；
- 不做或晚做的延迟成本；
- 研发、迁移、运行、运维、升级、学习和退出的全生命周期成本；
- 风险、收益置信度、最坏影响和可逆性；
- 使用 MoSCoW、RICE、WSJF 或价值—成本—风险时，说明选择理由和数据边界。
**输出：**六维可行性结论、WBS 与估算区间、价值—成本—风险表、Go / No-Go / 延后 / 继续调研建议。
**评审门：**建议有成立条件，工作量有区间和证据，价值有基线和责任人，阻塞性不可行项已有处置。
阶段五：定义需求与验收
每条需求必须包含：ID、类型、规范性陈述、场景/理由、范围、优先级、责任人、验收方法、条件、阈值和容差。
- 一条需求只表达一个必要行为或约束，使用“系统应/必须”。
- 功能要求覆盖主流程和异常行为，不提前限定无必要的内部实现。
- 质量要求使用“刺激来源 → 刺激 → 环境 → 对象 → 响应 → 阈值”的质量属性场景。
- AI/模型/算法/算子需求冻结任务与人群边界、模型/数据/代码版本、许可证、baseline/candidate、硬件软件精度、seed/采样、预热/重复、能力/系统/业务/护栏指标、回归预算、接管和 fallback。
- 使用 Given-When-Then 表达用户或外部系统可观察的验收场景。
- 规定验收证据形式和签字人，但不填写通过、失败或完成比例。
**输出：**批准需求目录、质量场景、AI 评测合同、验收场景和验收计划矩阵。
**评审门：**所有 Must 需求都可观察、可量化、可追踪，并有验收责任人；没有裸露的模糊形容词。
阶段六：确定优先级并建立基线
- 结合价值、依赖、风险、工作量和延迟成本确定优先级，避免所有需求都为 Must。
- 切分能够独立验证核心价值的最小版本，保留必要的测试、观测和回退。
- 明确当前版本的非目标、外部依赖、风险、停止条件和重审触发器。
- 建立开发前追踪链：
问题/机会 -> 干系人与场景 -> 目标 -> BR/UR
-> FR/QR/IR/CON -> 技术决策 -> 验收场景
- 检查两个方向：每条需求能回到真实问题，每个 Must 都能前向到验收。
- 建立变更规则：需求、阈值、范围或约束变化时，重新评估方案、工作量、价值和验收。
**输出：**优先级、首版范围、非目标、开发前追踪矩阵、未决问题和审批条件。
**评审门：**首版能够形成价值闭环；所有 Must 需求双向可追踪；未决问题和假设没有被隐藏。
生成报告
读取并填写 references/report-template.md。使用 references/method-selection.md 选择方法，不机械执行所有方法。
如果仓库没有指定位置，默认写入：
docs/requirements/<feature-slug>-requirements-analysis.md
最终报告至少包含：
- 开发前视角的执行摘要和立项建议；
- 客户、用户、场景、问题、影响、根因和目标；
- 系统边界、需求拆解、质量、接口、约束和非目标；
- 技术基线、候选方案、PoC、权衡和技术决策；
- 可行性、WBS、工作量区间、价值—成本—风险；
- 需求目录、质量/AI 评测合同和验收计划；
- 优先级、版本范围、依赖、风险、追踪、未决问题和审批条件。
质量检查
出现任一情况时拒绝交付：
- 正文从已完成实现开始叙述，或包含完成率、测试结果和上线效果；
- 新技术或客户提出的功能被直接当成真实需求；
- 用户、场景、问题影响、不做后果或成功结果缺失；
- 按代码模块拆需求，或用测试名证明用户价值；
- 候选方案没有统一评价准则，或缺少维持现状/最小改造基线；
- 可行性只评估技术，不评估数据、资源、交付、运营和合规；
- 工作量没有范围假设、区间、依赖、风险缓冲和证据；
- 价值判断没有基线、延迟成本、生命周期成本和风险边界；
- 质量需求使用模糊形容词而没有环境与阈值；
- PoC 结果被直接当作正式验收结果；
- Must 需求没有验收条件、责任人或开发前追踪链；
- 报告包含“实现对应、已完成代码、测试通过状态、线上业务结果”等复盘章节。
交付前运行相关 Markdown 校验，并报告：
- 报告路径和分析边界；
- 真实需求、需求条目、候选方案和验收场景数量；
- 可行性结论、工作量区间和立项建议；
- 未确认假设、阻塞项和最小责任人问题；
- 已执行的验证。