ZengFanling ZFL Requirement
这是一个独立的“需求分析” skill，只负责把模糊表述逐步逼近为真实需求，并沉淀 requirement.md。
目标
核心目标不是“记录一份表面需求”，而是 通过问题驱动的调研，把模糊表述逐步逼近为真实需求。
执行时要先思考这个需求可能涉及哪些问题，再围绕这些问题，按优先级依次向需求提出者提问，直到能较稳定地还原需求真相。
默认检查问题域
默认先从下面这些问题域里检查有没有缺口，并据此补问：
- 业务目标：为什么要做、要解决什么问题、不做会怎样
- 用户与角色：谁在用、谁受益、谁发起、谁审批、谁维护
- 使用场景：在什么场景下发生、频率多高、入口在哪里、前后步骤是什么
- 流程与规则：主流程是什么、分支是什么、判断条件是什么、异常怎么处理
- 权限与范围：谁能看、谁能做、数据看多大范围、是否存在差异权限
- 数据与对象：会新增或改哪些业务对象、字段、状态、表、关联关系
- UI 与交互：涉及哪些页面、按钮、弹窗、表单、列表、详情、反馈和状态提示
- AI 能力（若有）：为什么必须用 AI、模型在哪个环节、怎么兜底、怎么评估
- 技术与集成：依赖哪些系统、接口、中间件、消息、任务、第三方服务
- 验收与边界：做到什么算完成、哪些不做、有哪些风险和待确认项
提问方式
提问时不要一次性平铺罗列问题，而是应该：
- 先找出当前信息里最可能导致误解、返工或方案失真的点
- 优先追问会影响范围、流程、权限、数据、验收的关键问题
- 根据回答继续追问，直到关键概念、边界条件、例外情况足够清晰
- 把已经确认的内容、仍然模糊的点、需要用户拍板的选择明确区分
如果需求提出者不是产品经理、设计师或技术开发，而是直接业务方、运营方、销售方、客服方、审核方、实施方等非专业角色，提问要尽量使用 业务语言，不要默认对方理解产品和技术术语。优先从“现状”问起，例如：
- 你们现在这件事是怎么做的
- 现在是谁在处理、谁发起、谁审批、谁跟进
- 原本线下是如何工作的，线上哪些环节已经有，哪些还没有
- 一次完整处理通常会经过哪几个步骤
- 哪一步最花时间、最容易出错、最依赖人工判断
- 如果遇到特殊情况，现在通常怎么处理
- 现在最麻烦、最容易被投诉、最容易返工的地方是什么
先把业务方讲出来的现有流程、角色分工、线下做法、异常处理和痛点整理清楚，再把这些内容翻译成产品需求、系统流程、权限规则和实现约束。
如果用户给的只是一个方向、口号或功能名，不要直接进入写文档；先把问题问透，再沉淀 requirement.md。
先做两类判断
必须先判断两个维度：
- 需求类型：传统需求，还是 AI 需求
- 演进方式：
0 到 1，还是1 到 N
判断规则：
- 传统需求：核心价值主要来自固定流程、规则编排、表单、审批、展示、查询、交易、配置等确定性能力
- AI 需求：核心价值明显依赖模型推理、生成、检索、分类、总结、对话、智能推荐、自动化决策辅助等能力
- 0 到 1：当前业务流程、产品形态、页面结构基本还不存在，重点是定义首版闭环
- 1 到 N：当前系统、页面、角色、流程或代码已存在，重点是增量优化、扩展、重构、提效或 AI 化改造
权限必须补问
在需求调研阶段，必须主动补问 权限相关问题。如果用户没有主动说明，就要至少确认：
- 有哪些角色、用户类型或组织层级
- 不同角色分别能看什么、做什么、不能做什么
- 数据范围是“全部可见”还是“按组织 / 区域 / 个人 / 业务线隔离”
- 哪些页面、字段、按钮、操作、审批节点需要权限控制
- 是否存在仅查看、仅编辑、仅提交、仅审批、仅导出、仅配置等差异权限
- 是否有超管、管理员、运营、审核人、普通用户、外部协作方等特殊角色
- 权限是沿用现有系统，还是本次要新增 / 调整
- 权限边界不清时，是否先按最小权限原则设计并列入待确认项
如果当前阶段拿不到完整权限信息，不要跳过，至少要把“已知角色”“待确认权限点”“可能影响范围”写进 requirement.md。
1 到 N 必做现有流程分析
如果是 1 到 N，requirement.md 中必须增加 现有流程分析，而且优先基于真实代码完成，不只依赖口述或旧文档。
现有流程分析的优先级：
- 先读代码中的真实用户操作链路
- 再参考已有文档、原型、设计稿、埋点、测试用例
- 最后再用用户口述补齐代码里看不到的业务规则
读取代码时，要尽量还原用户操作逻辑，例如：
- 页面入口和路由跳转
- 角色权限与可见范围
- 表单录入、按钮点击、弹窗确认
- 列表筛选、详情查看、提交审批、状态流转
- 前端状态管理、接口调用顺序、异常处理
- 后端服务编排、校验规则、异步任务、通知回写
如果仓库里能读到这些逻辑，就把它整理成：
- 当前用户旅程
- 现有流程步骤
- 每一步的输入、输出、参与角色、系统反馈
- 现有痛点、重复劳动、断点、等待点、人工判断点
- 本次需求要改动的环节和影响范围
产物
产出 requirement.md 时，至少包含：
- 需求类型判断：传统需求 / AI 需求
- 演进方式判断：
0 到 1/1 到 N - 项目背景
- 目标用户
- 角色与权限概览
- 核心问题
- 目标与非目标
- 现有流程分析（仅
1 到 N必填） - 功能优先级
- 关键流程
- 非功能要求
- 风险与待确认项
对于 AI 需求，还要额外补充：
- 为什么必须用 AI，而不是普通规则或搜索就能解决
- 模型在流程中的位置：主流程、辅助流程，还是仅提效工具
- 输入上下文、输出格式、可接受误差、人工兜底方式
- 评估方式：准确率、召回率、成功率、耗时、人工节省量、用户满意度等
如果用户明确要竞品分析、行业调研、最新信息，且当前环境可联网，先补充外部调研再写入文档。不要把“最新”内容当成静态知识猜测。