requirement-to-features

name	requirement-to-features
description	Breaks down product/backend requirements into structured functional points (功能点) with full coverage, human-readable wording, clear input/conditions/output, boundary cases, and branch handling. Use when the user asks to 需求拆解、整理功能点、拆功能点、需求覆盖、功能点清单, or to turn a requirement into 功能点.

需求拆解为功能点

将一条或多条需求整理成可执行、可验收的功能点，做到覆盖全面、说人话、不缺失不重复，并显式覆盖边界与逆向情况。

何时使用

• 用户要求「把需求拆成功能点」「整理功能点」「需求覆盖」「出功能点清单」
• 需求文档或需求描述已就绪，需要产出结构化功能点供开发/测试使用
• 需要从需求中识别分支、边界、逆向场景并单独成点

基本原则

1. 按分支逐条输出：一个需求分支对应一个功能点，逐条列出、不合并。正向一条、逆向一条；多个分叉就输出多个功能点。禁止把多条分支写进同一段描述或合并成「一堆」内容。
2. 覆盖全面：正向主流程、分支流程、异常/逆向、边界值均有对应功能点。
3. 人话且可执行：每个功能点有明确输入/触发、条件/校验、输出/结果，读起来像「谁在什么情况下做了什么、得到什么」。
4. 边界值：对数量、金额、长度、状态等有上下限或特殊值的，单独列出边界功能点（如：空、零、最大值、最小值、临界状态）。
5. 分支不缺失、不重复：基于需求理解所有分支（if/else、多状态、多角色），每个分支至少一个功能点，且不在不同功能点里重复描述同一分支。
6. 逆向拆解：明确「逆向」在功能点中的定位——通常指与主流程相反或异常的操作/数据（如：撤销、拒绝、超时、非法参数）。为逆向场景单独一条功能点，并写清触发条件与预期结果，不与正向合并。
7. 验证类型标注：每个功能点必须在标题中标注验证类型——【流程验证】 或 【数据验证】，二者含义如下：

验证类型	含义	关注点	典型场景
【流程验证】	验证操作步骤、状态流转、业务链路是否按预期运行	步骤顺序是否正确、状态机流转是否合法、多步骤串联是否畅通、角色权限是否拦截	下单→支付→发货的主流程；审批链中上级驳回后回退到上一节点；未登录用户访问受限页面被跳转登录页
【数据验证】	验证数据格式、取值范围、计算逻辑、存储一致性是否正确	参数格式校验、边界值是否拦截、计算公式是否正确、写库数据是否准确	手机号必须为 11 位数字；转账金额不得超过单日限额；订单金额 = 商品单价 × 数量 − 优惠；输入 SQL 注入字符被拦截

判断技巧：如果功能点的核心是「能不能走通 / 流程对不对」→ 流程验证；如果核心是「数据对不对 / 值合不合法」→ 数据验证。当一个功能点同时涉及流程与数据时，以主要验证目的为准标注一个类型。

输出结构（每个功能点必遵）

每个功能点必须按以下结构输出，保证人话、可验收。每条功能点单独成块、按分支逐条列出（正逆各一条、多分叉多条），不要将多个分支合并进同一块。

【流程验证】或【数据验证】功能点描述：
前置条件：
输入：
输出：

（若有多条分支，则上述结构重复多次，每条分支一块。）

• 验证类型标签：每条功能点的标题必须以 【流程验证】 或 【数据验证】 开头，紧接功能点描述文字。
• 功能点描述：一句话说清角色、情境、目标。
• 输入：操作入口 + 关键参数或事件，避免模糊的「用户操作」。
• 前置条件：：列出与本功能点相关的校验项，便于与测试用例对齐。
• 输出：成功时的界面/数据变化 + 失败时的提示或错误码；若有写库/发消息等，简要写出。

功能点描述规范

功能点描述需清晰、简洁。根据实际情况自行判断选用下列一种形式，同一批用例内可混用不同形式以更好表达不同测试点。

类型	格式	适用场景	示例
动宾结构型	[验证类型] + [动作] + [对象] + [结果/条件]	逻辑简单、直接的功能点；最常用	【流程验证】登录系统-输入正确账号密码-登录成功；【数据验证】上传头像-选择超过5MB图片-提示文件过大
场景化（User Story）型	[验证类型] + [身份/前提] + [在什么场景下] + [实现什么目标]	需强调业务场景、多角色/身份时	【流程验证】未登录用户-在购物车页面点击结算-强制跳转登录页；【数据验证】VIP会员-购买特价商品-享受折上折优惠金额计算正确
条件判断型	[验证类型] + [前提条件] + [操作] + [结果]	逻辑复杂、多分支/多前置条件的后台算法	【数据验证】余额不足-点击转账-弹出余额补足提醒；【流程验证】网络断开-提交订单-提示网络异常并保存草稿
预期结果导向型	[验证类型] + [预期结果] + [原因/操作]	需在报告或列表中快速定位结论时	【数据验证】【失败】输入框输入非法字符SQL注入攻击；【流程验证】【成功】使用第三方微信授权快捷登录
标准化三段论	[验证类型] + [功能模块] - [测试点] - [预期结果]	模块多、需严格分类、团队规范要求高时	【数据验证】【支付模块】- 银行卡余额校验 - 余额为0时支付置灰；【流程验证】【用户体系】- 手机号注册 - 重复注册拦截并提示

选用建议：主流程/单点验证优先用动宾；多角色/业务场景明显用场景化；逆向、分支、异常条件多用条件判断型；强调通过/失败结论时用结果导向；需求跨多模块或需与模块树强对应时用三段论（可与 modules 路径呼应）。

前置条件编写规范

前置条件需明确「在什么状态下开始执行步骤」，便于复现与理解。根据用例类型自行组合下列类别中的要素，多条用中文分号 ； 分隔。

类型	编写重点	示例
账号权限与身份定义类	角色名称 + 权限状态 + 登录状态	账号已登录，且具有「财务审批」权限；用户为首次注册的非会员用户；账号处于「被冻结」状态
数据与对象状态类	对象唯一标识 + 特定状态	系统内已存在一个状态为「待支付」的订单；银行卡列表中已绑定至少一张有效借记卡；该手机号已在后台黑名单库中
环境与配置开关类	具体的开关名 + 设定值	系统后台「转账限额校验」功能已开启；当前环境模拟网络延迟大于 3000ms；App 权限设置中已禁用「定位服务」
链路路径（上游步骤）类	核心动作的完成结果	用户已进入转账详情页，且已输入合法的收款人信息；商品已成功加入购物车，并进入结算页面

生成前置条件时，按需选用：涉及多角色/审批时必写身份与权限；依赖特定业务数据时写清对象与状态；依赖开关或环境时写清配置；用例处于长流程中间环节时简述上游路径。

输入（Input/Trigger）编写规范

输入不仅是「点个按钮」，而是动作、数据和前置状态的组合。书写功能点的「输入」时，根据场景选用下列类型之一或组合使用。

类型	说明	编写方式	示例
动作触发型 (Action-Based)	用户在界面上的物理操作	[操作组件] + [动作]	点击「确认转账」按钮；向左滑动删除卡片；长按头像 2 秒
数据载入型 (Data-Driven)	强调输入的数据内容、格式和来源	[数据项] + [具体数值/范围]	在金额栏输入 100.05；上传一张 PNG 格式且小于 2MB 的图片
状态变更型 (State-Triggered)	由系统状态或环境变化触发，非人直接操作	[对象] + [达到/变为某状态]	当倒计时归零时；当账户余额低于 10 元时；当定位检测到进入新城市时
组合验证型 (Combined Validation)	多个输入条件并列，用于复杂逻辑校验	[输入 A] + [输入 B] + [校验关系]	输入正确的账号 + 错误的密码；勾选「同意协议」+ 点击「提交」

选用建议：单步操作多用动作触发型；涉及金额、文件、参数时用数据载入型；定时/阈值/地理等自动触发用状态变更型；多条件同时满足才触发时用组合验证型。

输出（Output/Feedback）编写规范

输出必须明确「谁看到了什么」以及「后台发生了什么」。书写功能点的「输出」时，按实际发生的结果选用下列类型。

类型	说明	编写方式	示例
视觉反馈型 (UI/UX Feedback)	用户肉眼可见的界面变化	[组件名称] + [变化效果]	按钮变为置灰不可点击状态；弹出 Toast 提示：发送成功；页面跳转至「结果页」
数据持久化型 (Data Persistence)	后端数据库或缓存的实质性改变（对开发至关重要）	[数据库/字段] + [更新/写入/删除]	订单表状态字段更新为「已支付」；用户积分余额减少 100 分
异常阻断型 (Error/Exception)	逻辑不通时的拦截反馈，覆盖边界值的关键	[报错位置] + [错误文案]	输入框下方红字提示：格式错误；弹出模态框：当前操作频繁，请稍后再试
外部系统联动型 (System Integration)	本系统之外的动作触发	[外部媒介] + [接收内容]	向用户注册手机号发送一条验证码短信；调用微信支付接口拉起支付控件

选用建议：成功路径需同时写清视觉反馈（用户可见）与数据持久化（后台变化）；失败/边界场景必写异常阻断型；涉及短信、支付、第三方 API 时写外部系统联动型。

生成流程建议

第〇步：判断需求性质（必做）

拿到需求后，先判断再动手，不要直接开始拆功能点。

1. 判断输入形式：

   • 用户输入的是一段需求描述文字 → 视为新需求，进入下方流程
   • 用户输入的是一个文件路径 → 视为对已有功能点文档的修改，读取该文件后按用户要求修改即可，不走新需求流程

2. 判断需求是否属于同一业务（仅新需求时）：

   • 通读需求内容，判断其中涉及的改动是否属于同一条业务链路 / 同一个业务目标
   • 同一业务：即使涉及多个模块，只要这些模块围绕同一个业务目标且存在逻辑前置关系（如「配置开关 → 数据写入 → 列表展示 → 编辑拦截」），就视为一个需求，输出到一份文档
   • 多个不相关业务拼装：如果需求中包含多个彼此无业务流程关系的优化/改动（如「模块A的性能优化 + 模块B的新增字段 + 模块C的权限调整」），仍输出到同一份文档，但需主动告知用户这些改动属于不同业务，并在文档中按业务/模块分章节组织，每个业务/模块独立成章，章节内各自按业务推进顺序排列功能点
   • 不确定时：主动询问用户，不要自行假设

第〇.五步：查找并读取模块知识（必做）

在正式梳理流程和拆解功能点之前，必须先查找本 knowledge 目录下的 module_knowlege/ 文件夹，读取与本次需求相关的模块知识文档。

1. 识别涉及的模块：从需求内容中提取涉及的业务模块关键词（如「AML规则配置」「出金申请」「流水管理」等）。

2. 查找匹配的知识文档：在 module_knowlege/ 目录下查找文件名与模块关键词匹配的文档。文件名格式为模块路径用 - 连接（如 业务参数设置-风控规则-AML规则配置.md）。可使用 Glob 或 ls 列出目录内所有文件，再按关键词匹配。

3. 读取并内化：

   • 找到匹配文档：读取文档内容，作为后续流程梳理和功能点拆解的业务上下文。文档中记录的是该模块的现有业务逻辑和操作流程（即系统现状），需求描述的是在此基础上要做的变更。拆解功能点时须区分「现状」和「变更」，确保不把现有逻辑误写为新功能。
   • 未找到匹配文档：正常继续，不阻断流程。但在涉及模块现有逻辑时，应主动向用户确认，避免基于错误假设拆解。

4. 需求可能涉及多个模块：如果需求跨多个模块，应查找并读取所有相关模块的知识文档。

第一步：梳理业务流程阶段大纲

确认为同一业务需求后，先梳理出业务推进的阶段/步骤大纲，再开始拆功能点。

1. 识别所有阶段：从需求中提取出业务推进的各个阶段。阶段不限于严格的时间线流程，也包括：

   • 前置配置/数据准备：如开关设置、初始化表、权限配置等，虽然不是业务流程本身，但必须在前面
   • 主流程步骤：按业务实际推进顺序排列（如 下单 → 支付 → 发货 → 收货）
   • 依赖关系：模块A的输出是模块B的输入时，A排在B前面
   • 收尾/一致性校验：如边界回归、数据一致性检查等，排在最后

2. 不确定顺序时主动询问用户：涉及公司内部业务知识、不清楚真实的前后关系时，必须向用户确认流程顺序，不要猜测

3. 将阶段作为文档的章节标题：如「一、撤销记录表写入」「二、资金流水展示屏蔽」「三、编辑拦截」「四、边界与数据一致性」

目标：读功能点清单的人，从上往下读就能理解整个业务是怎么推进的，不需要自己在脑子里重新排序。

第二步：在每个阶段内拆分功能点

在每个阶段内，按以下顺序排列功能点：

0. 按用户操作顺序排列（最高优先级）：同一阶段内的功能点必须遵循用户实际的操作顺序。如果业务流程是先选 A 再配 B，那 A 相关的验证点必须排在 B 前面。例如：配置流程是「选使用范围 → 选触发时间点 → 选具体指标 → 设命中逻辑」，则使用范围的验证点排在具体指标之前。让读者从上往下读就能跟随操作步骤，而不需要在文档中跳来跳去。
1. 正向主流程：该阶段的核心正常路径
2. 分支流程：该阶段内的条件分叉
3. 逆向/异常：该阶段内的异常、拒绝、超时等
4. 边界值：该阶段内的边界场景

上述 1-4 的分类在满足第 0 条「操作顺序」的前提下适用。即：先按操作顺序分组，每组内再按正向→分支→逆向→边界排列。

第三步：编号与自检

1. 编号体现流程推进：按章节顺序编号（如阶段一的功能点为 1、1.1、1.2，阶段二为 2、2.1 等）
2. 自检：
   • 对照需求逐条看是否都有功能点覆盖
   • 检查边界与逆向是否都有对应点
   • 确认正逆、多分叉均已逐条输出、无合并
   • 确认每条功能点标题均已标注【流程验证】或【数据验证】，且标注准确
   • 确认功能点整体顺序符合业务推进逻辑，从上往下读能理解业务全貌
   • 确认同一章节内的功能点严格遵循用户操作顺序（先选A再选B → A的验证点在B前面），不出现「先验证下游再验证上游」的倒序

输出落盘规则

功能点清单必须写成 markdown 文件落盘，不要仅在对话中输出。

新需求（用户输入的是一段需求描述文字）

1. 在 output/testcases/ 下按当天日期新建文件夹：output/testcases/YYYY-MM-DD/，如果当天已有日期文件夹，则使用已有文件夹即可。
2. 在日期文件夹下面，根据需求内容自动需求相关的文件夹，要求简洁、能体现需求主题，如 无痕撤销记录表与被撤销流水隐藏
3. 在需求文件夹下面，生成需求文件，要求以需求文件夹名 + '_功能点.md' 为名，如 无痕撤销记录表与被撤销流水隐藏_功能点.md
4. 将完整的功能点清单写入该文件

修改已有（用户输入的是一个文件路径）

1. 读取用户指定的文件
2. 按用户要求在原文件上修改/追加
3. 直接写回原文件路径，不新建文件