# Zfl Requirement

> 独立的需求分析与调研 skill。Use when the user wants to单独做需求分析、需求调研、需求澄清、问题驱动访谈、角色权限梳理、现有流程分析，或提到 `zfl-requirement`、`需求分析`、`需求调研`、`requirement.md`。

- Skill: `zengfanling/zfl-requirement` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zengfanling/zfl-requirement`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zengfanling/zfl-requirement/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ZengFanling (https://skillmd.com/u/zengfanling)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/zengfanling/zfl-requirement

---


# ZFL Requirement

这是一个独立的“需求分析” skill，只负责把模糊表述逐步逼近为真实需求，并沉淀 `requirement.md`。

## 目标

核心目标不是“记录一份表面需求”，而是 **通过问题驱动的调研，把模糊表述逐步逼近为真实需求**。

执行时要先思考这个需求可能涉及哪些问题，再围绕这些问题，按优先级依次向需求提出者提问，直到能较稳定地还原需求真相。

## 默认检查问题域

默认先从下面这些问题域里检查有没有缺口，并据此补问：

- 业务目标：为什么要做、要解决什么问题、不做会怎样
- 用户与角色：谁在用、谁受益、谁发起、谁审批、谁维护
- 使用场景：在什么场景下发生、频率多高、入口在哪里、前后步骤是什么
- 流程与规则：主流程是什么、分支是什么、判断条件是什么、异常怎么处理
- 权限与范围：谁能看、谁能做、数据看多大范围、是否存在差异权限
- 数据与对象：会新增或改哪些业务对象、字段、状态、表、关联关系
- UI 与交互：涉及哪些页面、按钮、弹窗、表单、列表、详情、反馈和状态提示
- AI 能力（若有）：为什么必须用 AI、模型在哪个环节、怎么兜底、怎么评估
- 技术与集成：依赖哪些系统、接口、中间件、消息、任务、第三方服务
- 验收与边界：做到什么算完成、哪些不做、有哪些风险和待确认项

## 提问方式

提问时不要一次性平铺罗列问题，而是应该：

1. 先找出当前信息里最可能导致误解、返工或方案失真的点
2. 优先追问会影响范围、流程、权限、数据、验收的关键问题
3. 根据回答继续追问，直到关键概念、边界条件、例外情况足够清晰
4. 把已经确认的内容、仍然模糊的点、需要用户拍板的选择明确区分

如果需求提出者不是产品经理、设计师或技术开发，而是直接业务方、运营方、销售方、客服方、审核方、实施方等非专业角色，提问要尽量使用 **业务语言**，不要默认对方理解产品和技术术语。优先从“现状”问起，例如：

- 你们现在这件事是怎么做的
- 现在是谁在处理、谁发起、谁审批、谁跟进
- 原本线下是如何工作的，线上哪些环节已经有，哪些还没有
- 一次完整处理通常会经过哪几个步骤
- 哪一步最花时间、最容易出错、最依赖人工判断
- 如果遇到特殊情况，现在通常怎么处理
- 现在最麻烦、最容易被投诉、最容易返工的地方是什么

先把业务方讲出来的现有流程、角色分工、线下做法、异常处理和痛点整理清楚，再把这些内容翻译成产品需求、系统流程、权限规则和实现约束。

如果用户给的只是一个方向、口号或功能名，不要直接进入写文档；先把问题问透，再沉淀 `requirement.md`。

## 先做两类判断

必须先判断两个维度：

- **需求类型**：传统需求，还是 AI 需求
- **演进方式**：`0 到 1`，还是 `1 到 N`

判断规则：

- **传统需求**：核心价值主要来自固定流程、规则编排、表单、审批、展示、查询、交易、配置等确定性能力
- **AI 需求**：核心价值明显依赖模型推理、生成、检索、分类、总结、对话、智能推荐、自动化决策辅助等能力
- **0 到 1**：当前业务流程、产品形态、页面结构基本还不存在，重点是定义首版闭环
- **1 到 N**：当前系统、页面、角色、流程或代码已存在，重点是增量优化、扩展、重构、提效或 AI 化改造

## 权限必须补问

在需求调研阶段，必须主动补问 **权限相关问题**。如果用户没有主动说明，就要至少确认：

- 有哪些角色、用户类型或组织层级
- 不同角色分别能看什么、做什么、不能做什么
- 数据范围是“全部可见”还是“按组织 / 区域 / 个人 / 业务线隔离”
- 哪些页面、字段、按钮、操作、审批节点需要权限控制
- 是否存在仅查看、仅编辑、仅提交、仅审批、仅导出、仅配置等差异权限
- 是否有超管、管理员、运营、审核人、普通用户、外部协作方等特殊角色
- 权限是沿用现有系统，还是本次要新增 / 调整
- 权限边界不清时，是否先按最小权限原则设计并列入待确认项

如果当前阶段拿不到完整权限信息，不要跳过，至少要把“已知角色”“待确认权限点”“可能影响范围”写进 `requirement.md`。

## `1 到 N` 必做现有流程分析

如果是 `1 到 N`，`requirement.md` 中必须增加 **现有流程分析**，而且优先基于真实代码完成，不只依赖口述或旧文档。

现有流程分析的优先级：

1. 先读代码中的真实用户操作链路
2. 再参考已有文档、原型、设计稿、埋点、测试用例
3. 最后再用用户口述补齐代码里看不到的业务规则

读取代码时，要尽量还原用户操作逻辑，例如：

- 页面入口和路由跳转
- 角色权限与可见范围
- 表单录入、按钮点击、弹窗确认
- 列表筛选、详情查看、提交审批、状态流转
- 前端状态管理、接口调用顺序、异常处理
- 后端服务编排、校验规则、异步任务、通知回写

如果仓库里能读到这些逻辑，就把它整理成：

- 当前用户旅程
- 现有流程步骤
- 每一步的输入、输出、参与角色、系统反馈
- 现有痛点、重复劳动、断点、等待点、人工判断点
- 本次需求要改动的环节和影响范围

## 产物

产出 `requirement.md` 时，至少包含：

- 需求类型判断：传统需求 / AI 需求
- 演进方式判断：`0 到 1` / `1 到 N`
- 项目背景
- 目标用户
- 角色与权限概览
- 核心问题
- 目标与非目标
- 现有流程分析（仅 `1 到 N` 必填）
- 功能优先级
- 关键流程
- 非功能要求
- 风险与待确认项

对于 **AI 需求**，还要额外补充：

- 为什么必须用 AI，而不是普通规则或搜索就能解决
- 模型在流程中的位置：主流程、辅助流程，还是仅提效工具
- 输入上下文、输出格式、可接受误差、人工兜底方式
- 评估方式：准确率、召回率、成功率、耗时、人工节省量、用户满意度等

如果用户明确要竞品分析、行业调研、最新信息，且当前环境可联网，先补充外部调研再写入文档。不要把“最新”内容当成静态知识猜测。