菜单
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 功能点.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Generates functional test cases only (normal flow, reverse flow, boundary) in Markdown for securities backend requirements. Use when the user asks for 功能测试用例、功能性用例、正向/逆向/边界用例. Output uses fixed table format and project module tree for 所属模块.
分析输入的需求文档，判断是否需要新增或更新 module_knowledge/ 中的业务流程知识条目，并执行对应操作。Use when the user asks to 更新知识库、新需求入库、同步流程、知识库更新, or inputs a PRD / 需求描述 / 变更说明.
基于 SOC 职业分类
| 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 功能点. |
将一条或多条需求整理成可执行、可验收的功能点，做到覆盖全面、说人话、不缺失不重复，并显式覆盖边界与逆向情况。
| 验证类型 | 含义 | 关注点 | 典型场景 |
|---|---|---|---|
| 【流程验证】 | 验证操作步骤、状态流转、业务链路是否按预期运行 | 步骤顺序是否正确、状态机流转是否合法、多步骤串联是否畅通、角色权限是否拦截 | 下单→支付→发货的主流程；审批链中上级驳回后回退到上一节点；未登录用户访问受限页面被跳转登录页 |
| 【数据验证】 | 验证数据格式、取值范围、计算逻辑、存储一致性是否正确 | 参数格式校验、边界值是否拦截、计算公式是否正确、写库数据是否准确 | 手机号必须为 11 位数字；转账金额不得超过单日限额；订单金额 = 商品单价 × 数量 − 优惠；输入 SQL 注入字符被拦截 |
判断技巧：如果功能点的核心是「能不能走通 / 流程对不对」→ 流程验证；如果核心是「数据对不对 / 值合不合法」→ 数据验证。当一个功能点同时涉及流程与数据时，以主要验证目的为准标注一个类型。
每个功能点必须按以下结构输出，保证人话、可验收。每条功能点单独成块、按分支逐条列出（正逆各一条、多分叉多条），不要将多个分支合并进同一块。
【流程验证】或【数据验证】功能点描述：
前置条件：
输入：
输出：
（若有多条分支，则上述结构重复多次，每条分支一块。）
【流程验证】 或 【数据验证】 开头，紧接功能点描述文字。功能点描述需清晰、简洁。根据实际情况自行判断选用下列一种形式，同一批用例内可混用不同形式以更好表达不同测试点。
| 类型 | 格式 | 适用场景 | 示例 |
|---|---|---|---|
| 动宾结构型 | [验证类型] + [动作] + [对象] + [结果/条件] | 逻辑简单、直接的功能点；最常用 | 【流程验证】登录系统-输入正确账号密码-登录成功；【数据验证】上传头像-选择超过5MB图片-提示文件过大 |
| 场景化（User Story）型 | [验证类型] + [身份/前提] + [在什么场景下] + [实现什么目标] | 需强调业务场景、多角色/身份时 | 【流程验证】未登录用户-在购物车页面点击结算-强制跳转登录页；【数据验证】VIP会员-购买特价商品-享受折上折优惠金额计算正确 |
| 条件判断型 | [验证类型] + [前提条件] + [操作] + [结果] | 逻辑复杂、多分支/多前置条件的后台算法 | 【数据验证】余额不足-点击转账-弹出余额补足提醒；【流程验证】网络断开-提交订单-提示网络异常并保存草稿 |
| 预期结果导向型 | [验证类型] + [预期结果] + [原因/操作] | 需在报告或列表中快速定位结论时 | 【数据验证】【失败】输入框输入非法字符SQL注入攻击；【流程验证】【成功】使用第三方微信授权快捷登录 |
| 标准化三段论 | [验证类型] + [功能模块] - [测试点] - [预期结果] | 模块多、需严格分类、团队规范要求高时 | 【数据验证】【支付模块】- 银行卡余额校验 - 余额为0时支付置灰；【流程验证】【用户体系】- 手机号注册 - 重复注册拦截并提示 |
选用建议：主流程/单点验证优先用动宾；多角色/业务场景明显用场景化；逆向、分支、异常条件多用条件判断型；强调通过/失败结论时用结果导向；需求跨多模块或需与模块树强对应时用三段论（可与 modules 路径呼应）。
前置条件需明确「在什么状态下开始执行步骤」，便于复现与理解。根据用例类型自行组合下列类别中的要素，多条用中文分号 ； 分隔。
| 类型 | 编写重点 | 示例 |
|---|---|---|
| 账号权限与身份定义类 | 角色名称 + 权限状态 + 登录状态 | 账号已登录，且具有「财务审批」权限；用户为首次注册的非会员用户；账号处于「被冻结」状态 |
| 数据与对象状态类 | 对象唯一标识 + 特定状态 | 系统内已存在一个状态为「待支付」的订单；银行卡列表中已绑定至少一张有效借记卡；该手机号已在后台黑名单库中 |
| 环境与配置开关类 | 具体的开关名 + 设定值 | 系统后台「转账限额校验」功能已开启；当前环境模拟网络延迟大于 3000ms；App 权限设置中已禁用「定位服务」 |
| 链路路径（上游步骤）类 | 核心动作的完成结果 | 用户已进入转账详情页，且已输入合法的收款人信息；商品已成功加入购物车，并进入结算页面 |
生成前置条件时，按需选用：涉及多角色/审批时必写身份与权限；依赖特定业务数据时写清对象与状态；依赖开关或环境时写清配置；用例处于长流程中间环节时简述上游路径。
输入不仅是「点个按钮」，而是动作、数据和前置状态的组合。书写功能点的「输入」时，根据场景选用下列类型之一或组合使用。
| 类型 | 说明 | 编写方式 | 示例 |
|---|---|---|---|
| 动作触发型 (Action-Based) | 用户在界面上的物理操作 | [操作组件] + [动作] | 点击「确认转账」按钮；向左滑动删除卡片；长按头像 2 秒 |
| 数据载入型 (Data-Driven) | 强调输入的数据内容、格式和来源 | [数据项] + [具体数值/范围] | 在金额栏输入 100.05；上传一张 PNG 格式且小于 2MB 的图片 |
| 状态变更型 (State-Triggered) | 由系统状态或环境变化触发，非人直接操作 | [对象] + [达到/变为某状态] | 当倒计时归零时；当账户余额低于 10 元时；当定位检测到进入新城市时 |
| 组合验证型 (Combined Validation) | 多个输入条件并列，用于复杂逻辑校验 | [输入 A] + [输入 B] + [校验关系] | 输入正确的账号 + 错误的密码；勾选「同意协议」+ 点击「提交」 |
选用建议：单步操作多用动作触发型；涉及金额、文件、参数时用数据载入型；定时/阈值/地理等自动触发用状态变更型；多条件同时满足才触发时用组合验证型。
输出必须明确「谁看到了什么」以及「后台发生了什么」。书写功能点的「输出」时，按实际发生的结果选用下列类型。
| 类型 | 说明 | 编写方式 | 示例 |
|---|---|---|---|
| 视觉反馈型 (UI/UX Feedback) | 用户肉眼可见的界面变化 | [组件名称] + [变化效果] | 按钮变为置灰不可点击状态；弹出 Toast 提示：发送成功；页面跳转至「结果页」 |
| 数据持久化型 (Data Persistence) | 后端数据库或缓存的实质性改变（对开发至关重要） | [数据库/字段] + [更新/写入/删除] | 订单表状态字段更新为「已支付」；用户积分余额减少 100 分 |
| 异常阻断型 (Error/Exception) | 逻辑不通时的拦截反馈，覆盖边界值的关键 | [报错位置] + [错误文案] | 输入框下方红字提示：格式错误；弹出模态框：当前操作频繁，请稍后再试 |
| 外部系统联动型 (System Integration) | 本系统之外的动作触发 | [外部媒介] + [接收内容] | 向用户注册手机号发送一条验证码短信；调用微信支付接口拉起支付控件 |
选用建议：成功路径需同时写清视觉反馈（用户可见）与数据持久化（后台变化）；失败/边界场景必写异常阻断型；涉及短信、支付、第三方 API 时写外部系统联动型。
拿到需求后，先判断再动手，不要直接开始拆功能点。
判断输入形式：
判断需求是否属于同一业务（仅新需求时）：
在正式梳理流程和拆解功能点之前，必须先查找本 knowledge 目录下的 module_knowlege/ 文件夹，读取与本次需求相关的模块知识文档。
识别涉及的模块：从需求内容中提取涉及的业务模块关键词（如「AML规则配置」「出金申请」「流水管理」等）。
查找匹配的知识文档：在 module_knowlege/ 目录下查找文件名与模块关键词匹配的文档。文件名格式为模块路径用 - 连接（如 业务参数设置-风控规则-AML规则配置.md）。可使用 Glob 或 ls 列出目录内所有文件，再按关键词匹配。
读取并内化：
需求可能涉及多个模块：如果需求跨多个模块，应查找并读取所有相关模块的知识文档。
确认为同一业务需求后，先梳理出业务推进的阶段/步骤大纲，再开始拆功能点。
识别所有阶段：从需求中提取出业务推进的各个阶段。阶段不限于严格的时间线流程，也包括：
不确定顺序时主动询问用户：涉及公司内部业务知识、不清楚真实的前后关系时，必须向用户确认流程顺序，不要猜测
将阶段作为文档的章节标题：如「一、撤销记录表写入」「二、资金流水展示屏蔽」「三、编辑拦截」「四、边界与数据一致性」
目标：读功能点清单的人，从上往下读就能理解整个业务是怎么推进的，不需要自己在脑子里重新排序。
在每个阶段内，按以下顺序排列功能点：
上述 1-4 的分类在满足第 0 条「操作顺序」的前提下适用。即：先按操作顺序分组，每组内再按正向→分支→逆向→边界排列。
功能点清单必须写成 markdown 文件落盘，不要仅在对话中输出。
output/testcases/ 下按当天日期新建文件夹：output/testcases/YYYY-MM-DD/，如果当天已有日期文件夹，则使用已有文件夹即可。无痕撤销记录表与被撤销流水隐藏无痕撤销记录表与被撤销流水隐藏_功能点.md