| 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 功能点. |
需求拆解为功能点
将一条或多条需求整理成可执行、可验收的功能点，做到覆盖全面、说人话、不缺失不重复，并显式覆盖边界与逆向情况。
何时使用
- 用户要求「把需求拆成功能点」「整理功能点」「需求覆盖」「出功能点清单」
- 需求文档或需求描述已就绪，需要产出结构化功能点供开发/测试使用
- 需要从需求中识别分支、边界、逆向场景并单独成点
基本原则
- 按分支逐条输出：一个需求分支对应一个功能点，逐条列出、不合并。正向一条、逆向一条；多个分叉就输出多个功能点。禁止把多条分支写进同一段描述或合并成「一堆」内容。
- 覆盖全面：正向主流程、分支流程、异常/逆向、边界值均有对应功能点。
- 人话且可执行：每个功能点有明确输入/触发、条件/校验、输出/结果，读起来像「谁在什么情况下做了什么、得到什么」。
- 边界值：对数量、金额、长度、状态等有上下限或特殊值的，单独列出边界功能点（如：空、零、最大值、最小值、临界状态）。
- 分支不缺失、不重复：基于需求理解所有分支（if/else、多状态、多角色），每个分支至少一个功能点，且不在不同功能点里重复描述同一分支。
- 逆向拆解：明确「逆向」在功能点中的定位——通常指与主流程相反或异常的操作/数据（如：撤销、拒绝、超时、非法参数）。为逆向场景单独一条功能点，并写清触发条件与预期结果，不与正向合并。
- 验证类型标注：每个功能点必须在标题中标注验证类型——【流程验证】 或 【数据验证】，二者含义如下：
| 验证类型 | 含义 | 关注点 | 典型场景 |
|---|
| 【流程验证】 | 验证操作步骤、状态流转、业务链路是否按预期运行 | 步骤顺序是否正确、状态机流转是否合法、多步骤串联是否畅通、角色权限是否拦截 | 下单→支付→发货的主流程；审批链中上级驳回后回退到上一节点；未登录用户访问受限页面被跳转登录页 |
| 【数据验证】 | 验证数据格式、取值范围、计算逻辑、存储一致性是否正确 | 参数格式校验、边界值是否拦截、计算公式是否正确、写库数据是否准确 | 手机号必须为 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 时写外部系统联动型。
生成流程建议
第〇步：判断需求性质（必做）
拿到需求后，先判断再动手，不要直接开始拆功能点。
-
判断输入形式：
- 用户输入的是一段需求描述文字 → 视为新需求，进入下方流程
- 用户输入的是一个文件路径 → 视为对已有功能点文档的修改，读取该文件后按用户要求修改即可，不走新需求流程
-
判断需求是否属于同一业务（仅新需求时）：
- 通读需求内容，判断其中涉及的改动是否属于同一条业务链路 / 同一个业务目标
- 同一业务：即使涉及多个模块，只要这些模块围绕同一个业务目标且存在逻辑前置关系（如「配置开关 → 数据写入 → 列表展示 → 编辑拦截」），就视为一个需求，输出到一份文档
- 多个不相关业务拼装：如果需求中包含多个彼此无业务流程关系的优化/改动（如「模块A的性能优化 + 模块B的新增字段 + 模块C的权限调整」），仍输出到同一份文档，但需主动告知用户这些改动属于不同业务，并在文档中按业务/模块分章节组织，每个业务/模块独立成章，章节内各自按业务推进顺序排列功能点
- 不确定时：主动询问用户，不要自行假设
第〇.五步：查找并读取模块知识（必做）
在正式梳理流程和拆解功能点之前，必须先查找本 knowledge 目录下的 module_knowlege/ 文件夹，读取与本次需求相关的模块知识文档。
-
识别涉及的模块：从需求内容中提取涉及的业务模块关键词（如「AML规则配置」「出金申请」「流水管理」等）。
-
查找匹配的知识文档：在 module_knowlege/ 目录下查找文件名与模块关键词匹配的文档。文件名格式为模块路径用 - 连接（如 业务参数设置-风控规则-AML规则配置.md）。可使用 Glob 或 ls 列出目录内所有文件，再按关键词匹配。
-
读取并内化：
- 找到匹配文档：读取文档内容，作为后续流程梳理和功能点拆解的业务上下文。文档中记录的是该模块的现有业务逻辑和操作流程（即系统现状），需求描述的是在此基础上要做的变更。拆解功能点时须区分「现状」和「变更」，确保不把现有逻辑误写为新功能。
- 未找到匹配文档：正常继续，不阻断流程。但在涉及模块现有逻辑时，应主动向用户确认，避免基于错误假设拆解。
-
需求可能涉及多个模块：如果需求跨多个模块，应查找并读取所有相关模块的知识文档。
第一步：梳理业务流程阶段大纲
确认为同一业务需求后，先梳理出业务推进的阶段/步骤大纲，再开始拆功能点。
-
识别所有阶段：从需求中提取出业务推进的各个阶段。阶段不限于严格的时间线流程，也包括：
- 前置配置/数据准备：如开关设置、初始化表、权限配置等，虽然不是业务流程本身，但必须在前面
- 主流程步骤：按业务实际推进顺序排列（如 下单 → 支付 → 发货 → 收货）
- 依赖关系：模块A的输出是模块B的输入时，A排在B前面
- 收尾/一致性校验：如边界回归、数据一致性检查等，排在最后
-
不确定顺序时主动询问用户：涉及公司内部业务知识、不清楚真实的前后关系时，必须向用户确认流程顺序，不要猜测
-
将阶段作为文档的章节标题：如「一、撤销记录表写入」「二、资金流水展示屏蔽」「三、编辑拦截」「四、边界与数据一致性」
目标：读功能点清单的人，从上往下读就能理解整个业务是怎么推进的，不需要自己在脑子里重新排序。
第二步：在每个阶段内拆分功能点
在每个阶段内，按以下顺序排列功能点：
- 按用户操作顺序排列（最高优先级）：同一阶段内的功能点必须遵循用户实际的操作顺序。如果业务流程是先选 A 再配 B，那 A 相关的验证点必须排在 B 前面。例如：配置流程是「选使用范围 → 选触发时间点 → 选具体指标 → 设命中逻辑」，则使用范围的验证点排在具体指标之前。让读者从上往下读就能跟随操作步骤，而不需要在文档中跳来跳去。
- 正向主流程：该阶段的核心正常路径
- 分支流程：该阶段内的条件分叉
- 逆向/异常：该阶段内的异常、拒绝、超时等
- 边界值：该阶段内的边界场景
上述 1-4 的分类在满足第 0 条「操作顺序」的前提下适用。即：先按操作顺序分组，每组内再按正向→分支→逆向→边界排列。
第三步：编号与自检
- 编号体现流程推进：按章节顺序编号（如阶段一的功能点为 1、1.1、1.2，阶段二为 2、2.1 等）
- 自检：
- 对照需求逐条看是否都有功能点覆盖
- 检查边界与逆向是否都有对应点
- 确认正逆、多分叉均已逐条输出、无合并
- 确认每条功能点标题均已标注【流程验证】或【数据验证】，且标注准确
- 确认功能点整体顺序符合业务推进逻辑，从上往下读能理解业务全貌
- 确认同一章节内的功能点严格遵循用户操作顺序（先选A再选B → A的验证点在B前面），不出现「先验证下游再验证上游」的倒序
输出落盘规则
功能点清单必须写成 markdown 文件落盘，不要仅在对话中输出。
新需求（用户输入的是一段需求描述文字）
- 在
output/testcases/ 下按当天日期新建文件夹：output/testcases/YYYY-MM-DD/，如果当天已有日期文件夹，则使用已有文件夹即可。
- 在日期文件夹下面，根据需求内容自动需求相关的文件夹，要求简洁、能体现需求主题，如
无痕撤销记录表与被撤销流水隐藏
- 在需求文件夹下面，生成需求文件，要求以需求文件夹名 + '_功能点.md' 为名，如
无痕撤销记录表与被撤销流水隐藏_功能点.md
- 将完整的功能点清单写入该文件
修改已有（用户输入的是一个文件路径）
- 读取用户指定的文件
- 按用户要求在原文件上修改/追加
- 直接写回原文件路径，不新建文件
