提示词商城
AI 写作
图片
视频
热门角色
热门业务
模型专用
提示词工具
×
¥元
查看详情
首页 / 用户验收标准撰写专家
🔥 会员专享 文生文 其它

用户验收标准撰写专家

👁️ 51 次查看
📅 Dec 11, 2025
💡 核心价值： 本提示词专为系统分析师和产品经理设计，能够根据特定功能需求快速生成结构完整、逻辑严谨的用户验收标准。通过系统化的工作流程，确保验收标准覆盖功能描述、前置条件、测试场景和验收规则等核心要素，有效降低项目交付风险，提升需求沟通效率。适用于软件开发、系统集成和产品迭代等多种业务场景，帮助团队明确验收边界，减少后期返工。

🎯 可自定义参数（4个）

功能名称
需要制定验收标准的具体功能名称
功能类型
功能的分类类型
业务领域
功能所属的业务领域
复杂度级别
功能实现的复杂程度

🎨 效果示例

功能概述

  • 功能目标：支持用户创建售后退款申请，并按三级审批规则进行审核；审批通过后将退款以“原路退回”或“退至平台余额”的方式执行，保障售后流程合规、可追踪、可核对。
  • 业务价值：
    • 降低人工干预，规范退款流程与权限。
    • 提升用户体验与客诉处理效率。
    • 符合财务合规要求，确保资金流与订单状态一致。

前置条件

  • 环境与配置
    • 测试环境：UAT 环境可用，日志与审计功能开启，时间统一为系统时区（如 UTC+8）。
    • 审批规则（本次 UAT 固定配置，用于验证逻辑）：
      • 审批起点固定为一审；若退款金额超过当前级别放行上限，需继续下一审批。
      • 金额阈值：
        • 一审放行上限：≤ 500.00
        • 二审放行上限：≤ 5000.00
        • 超过 5000.00 需三级审批
    • 退款路径能力：
      • 原路退回：仅对支持退款 API 的支付方式开放（例如：信用卡网关 PG1、第三方钱包 PG2）。
      • 余额退回：平台统一的用户余额账户（UAT 环境余额初始为 0）。
    • 支付网关沙箱模拟：
      • 成功用例：交易号 TX-SUCC 返回成功。
      • 失败用例：交易号 TX-FAIL 返回失败（错误码 E-RFD-001，错误信息“Refund declined”）。
  • 角色与账号
    • 买家用户：U1（有可退款订单、余额初始 0）、U2（无权限操作 U1 订单）。
    • 审批人：R1（一审角色）、R2（二审角色）、R3（三审角色）；各自仅能看到本级待办。
  • 测试订单（均为单币种，保留两位小数）
    • O-1001：已支付 100.00，支付方式 PG1（支持原路退），可退款 100.00，交易号 TX-SUCC，无在途售后。
    • O-1002：已支付 300.00，历史已退款 200.00，可退款 100.00，支付方式 PG1，交易号 TX-SUCC。
    • O-2001：已支付 800.00，可退款 800.00，支付方式 PG1，交易号 TX-SUCC。
    • O-9001：已支付 6000.00，可退款 6000.00，支付方式 PG1，交易号 TX-SUCC。
    • O-5001：已支付 50.00，可退款 50.00，支付方式 PG1，存在进行中的退款申请。
    • O-7001：已支付 70.00，可退款 70.00，支付方式 PM3（不支持原路退），交易号 TX-SUCC。
    • O-8001：已支付 120.00，可退款 120.00，支付方式 PG1，交易号 TX-FAIL（用于网关失败场景）。

验收场景

以下场景均要求：界面/接口返回明确状态与错误码，产生审计日志，状态在列表与详情一致，金额精度为两位小数。

S1 全额退款-原路退回-一审放行

  • 测试数据：U1，O-1001，退款金额 100.00，退款路径=原路退回
  • 步骤：
    1. U1 发起退款申请，输入 100.00，选择原路退回，填写原因，提交。
    2. R1 审批通过。
  • 预期结果：
    • 申请创建成功，状态=待一审；可退款金额校验通过。
    • R1 通过后，无需二审三审，状态自动变更为“退款处理中”，调用 PG1。
    • 网关返回成功后，状态=已退款；订单可退款金额更新为 0；U1 余额不变。
    • 生成退款流水号，详情可见退款时间、通道、金额、交易号。

S2 部分退款-余额退回-一审放行

  • 测试数据：U1，O-1001，退款金额 40.00，退款路径=余额退回
  • 步骤：
    1. U1 发起退款申请，金额 40.00，选择余额退回，提交。
    2. R1 审批通过。
  • 预期结果：
    • R1 通过后直接入账余额，状态=已退款；U1 余额增加 40.00。
    • 订单可退款金额变为 60.00；退款流水记录为“余额”。

S3 全额退款-原路退回-二级审批

  • 测试数据：U1，O-2001，退款金额 800.00，退款路径=原路退回
  • 步骤：
    1. U1 提交 800.00 原路退回。
    2. R1 审批通过，状态=待二审。
    3. R2 审批通过，触发网关退款。
  • 预期结果：
    • R2 通过后状态=退款处理中；网关成功后状态=已退款。
    • 订单可退款金额更新为 0；资金未进入余额。

S4 全额退款-原路退回-三级审批

  • 测试数据：U1，O-9001，退款金额 6000.00，退款路径=原路退回
  • 步骤：
    1. U1 提交 6000.00 原路退回。
    2. R1 通过→待二审；R2 通过→待三审；R3 通过→触发退款。
  • 预期结果：
    • 按顺序经过三审；最终网关成功后状态=已退款；可退款金额=0。

S5 一审拒绝

  • 测试数据：U1，O-1002，退款金额 100.00，退款路径=原路退回
  • 步骤：
    1. U1 提交申请。
    2. R1 拒绝（必须填写拒绝原因）。
  • 预期结果：
    • 状态=已拒绝；未触发二审/退款；订单可退款金额仍为 100.00。
    • 拒绝原因在详情与审计日志可见。

S6 二审拒绝

  • 测试数据：U1，O-2001，退款金额 800.00，退款路径=原路退回
  • 步骤：
    1. U1 提交，R1 通过→待二审。
    2. R2 拒绝（填写原因）。
  • 预期结果：
    • 状态=已拒绝；未触发退款；可退款金额仍为 800.00；拒绝原因可见。

S7 申请人撤回

  • 测试数据：U1，O-1001，退款金额 60.00，退款路径=余额退回
  • 步骤：
    1. U1 提交后，在一审处理前执行“撤回”。
  • 预期结果：
    • 状态=已撤回；不可再被审批；订单可退款金额保持不变；审计日志记录撤回人与时间。

S8 并发/重复提交防护

  • 测试数据：U1，O-1001，退款金额 30.00，退款路径=余额退回
  • 步骤：
    1. 在两浏览器会话同时提交相同退款请求（同订单、同金额、同路径）。
  • 预期结果：
    • 仅创建 1 条有效退款申请；另一请求返回明确错误（如“存在进行中的相同申请”）。
    • 列表与详情中不存在重复售后单。

S9 金额合法性校验

  • 测试数据：U1，O-1001
  • 步骤与预期结果：
    • 提交金额 0 或负数：前端/接口校验失败，返回错误码与消息（如 E-AMT-001，“金额必须大于 0”），不创建申请。
    • 提交金额 > 可退款金额（如 200.00）：校验失败，返回错误（E-AMT-002，“超过可退款金额 100.00”）。
    • 提交金额小数位超过 2 位（如 10.999）：校验失败（E-AMT-003，“金额最多两位小数”）。

S10 支付方式不支持原路退回

  • 测试数据：U1，O-7001，退款金额 70.00
  • 步骤：
    1. 进入申请页面。
  • 预期结果：
    • “原路退回”选项不可选或不显示，仅可选择“余额退回”；强行提交“原路退回”被拒绝并返回错误（E-PM-001，“支付方式不支持原路退回”）。
    • 选择余额退回并一审通过后，状态=已退款，余额+70.00。

S11 原路退回-网关退款失败

  • 测试数据：U1，O-8001，退款金额 120.00，退款路径=原路退回（交易号 TX-FAIL）
  • 步骤：
    1. U1 提交；R1/R2 根据金额规则审批直至触发退款。
  • 预期结果：
    • 触发退款后网关返回失败，状态=退款失败；展示错误码 E-RFD-001 与网关信息。
    • 未入账余额；订单可退款金额仍为 120.00；可重新处理由运营另行决策（不在本次用例范围内）。

S12 多次部分退款与余额校验

  • 测试数据：U1，O-1002（可退 100.00）
  • 步骤与预期结果：
    1. 第一次申请 60.00 余额退回：一审通过→已退款；余额+60.00；可退款金额更新为 40.00。
    2. 第二次申请 50.00：校验失败（E-AMT-002，“超过可退款金额 40.00”）。
    3. 第二次改为 40.00：通过并已退款；余额累计+100.00；可退款金额=0。

S13 权限与可见性控制

  • 测试数据：U2 尝试对 U1 的 O-1001 发起退款；R1/R2/R3 审批可见性
  • 步骤与预期结果：
    • U2 对 O-1001 发起：拒绝，返回错误（E-AUTH-001，“无权限操作该订单”）。
    • 审批待办仅对对应级别与分配的审批人可见；非本级审批人无法操作（错误 E-AUTH-002）。

S14 审计与记录完整性

  • 适用：S1～S13 过程中任一条申请
  • 检查点：
    • 申请、审批（通过/拒绝）、撤回、退款执行结果均有日志；包含操作者、时间、动作、备注/原因、金额、路径、网关交易号/错误码（如有）。
    • 日志不可编辑，按时间倒序展示；导出或查询功能返回数据与界面一致。

S15 数据一致性与状态机校验

  • 适用：所有成功退款用例
  • 检查点：
    • 订单可退款金额=初始可退款金额-累计成功退款金额；不出现负数。
    • 退款申请状态流转符合：已提交→待一审→（通过）待二审/退款处理中→（通过）待三审/退款处理中→已退款；或在任一审批拒绝→已拒绝；撤回→已撤回；网关失败→退款失败。
    • 同一订单在存在“进行中”（待审/处理中）退款申请时，再次提交被拒绝（E-DUP-001，“存在进行中的申请”）。

通过标准

  • S1：创建成功；仅一审后原路退回成功；订单可退款金额=0；余额不变；有退款流水与审计。
  • S2：创建成功；仅一审后余额+40.00；订单可退款金额=60.00；有退款流水与审计。
  • S3：一审→二审通过后原路退回成功；订单可退款金额=0；审计链包含两级。
  • S4：一审→二审→三审通过后原路退回成功；订单可退款金额=0；审计链包含三级。
  • S5：一审拒绝；未触发退款；订单可退款金额不变；拒绝原因记录完整。
  • S6：二审拒绝；未触发退款；订单可退款金额不变；拒绝原因记录完整。
  • S7：撤回后状态=已撤回；后续不可审批；订单可退款金额不变；审计包含撤回。
  • S8：并发仅生成 1 条申请；重复请求返回明确错误；无重复数据。
  • S9：非法金额全部被拦截并返回对应错误码与明确文案；未创建申请。
  • S10：不支持原路退回的订单仅可余额退回；强制提交被拒绝；余额退回可成功。
  • S11：网关失败后状态=退款失败；错误码与信息展示；余额与可退款金额均未变；日志记录失败详情。
  • S12：部分退款累计不超过可退款金额；金额动态校正；余额累计与可退款金额准确。
  • S13：越权操作被拒绝并返回错误；待办与操作权限精准。
  • S14：所有关键动作均有不可篡改审计记录，字段完整、时间准确且与业务数据一致。
  • S15：状态机流转不越界、无跳转；累计金额与订单可退款金额一致，无负数与遗漏；在途申请阻止二次提交。

备注说明

  • 技术与合规模块
    • 错误返回：需包含机器可读错误码与可读消息，且在接口与界面一致。
    • 金额精度：输入与展示保留两位小数；内部结算按统一货币与精度处理。
    • 退款路径选择基于支付方式能力标识；该标识来源于支付配置中心或等价配置。
    • 网关交互：UAT 使用沙箱通道；真实通道与风控策略不在本次验收范围。
  • 业务规则边界
    • 本次仅覆盖“退款”流程；涉及“退货退款”的物流与质检不在范围。
    • 已存在进行中退款申请的订单，禁止新建同订单退款申请，直至前一单达到终态（已退款/已拒绝/已撤回/退款失败）。
  • 审批与权限
    • 审批级别、阈值为可配置项；UAT 以“前置条件”中阈值为准进行验收。
    • 审批必须填写拒绝原因；通过无需备注为必填。
  • 可观测性与审计
    • 每次状态变更与资金动作需产生日志；日志至少保留操作者、时间、动作、金额、退款路径、订单号、退款单号、支付交易号（如有）、错误码（如有）。
  • 性能与并发
    • 并发提交流程需具备重复提交防护；以订单+金额+退款路径作为唯一性判定键之一（实现细节不限），保证幂等。
  • 安全
    • 仅订单所属用户可发起退款；审批操作需基于角色与分配策略控制；敏感信息（卡号、token）不可在界面明文展示。

第三方支付对账拉取与差异回传接口（含幂等与重试）用户验收标准

功能概述

  • 功能目标：
    • 支持调用方按对账日（或时间窗口）从第三方支付平台拉取对账数据（汇总与明细），保障分页完整性与数据一致性。
    • 支持调用方将对账差异结果回传第三方，支持全成功、部分成功与失败返回，保证单次差异回传只被处理一次（幂等）。
    • 在网络抖动、瞬时错误等情况下，通过幂等与重试机制确保“至多一次提交、至少一次到达”的业务语义不被破坏。
  • 业务价值：
    • 提升清结算对账数据获取的稳定性与准确性，降低漏账、重账风险。
    • 实现差异闭环处理，支撑资金核对、异常定位与后续业务流转。
    • 降低重试与并发场景下的重复处理成本，保证对账处理可追溯、可验证。

前置条件

  • 环境与账号
    • 已搭建联调/验收环境，调用方与第三方之间的网络连通性正常。
    • 已配置可用的鉴权方式（例如签名/令牌/证书），并提供有效的鉴权凭据。
    • 已开通至少一个支付渠道/商户维度用于测试，具备必要的权限范围。
  • 时区与口径
    • 对账口径与时区已确认（例如以业务约定时区的自然日为“对账日”）；测试所用对账日明确。
  • 测试数据
    • 在目标对账日内预置多类型交易数据（支付成功、退款、撤销、关闭、失败），至少包含：
      • 正常交易若干（≥5笔）、退款/撤销各≥1笔、跨多渠道或多商户≥2个维度。
      • 可控差异样本（如金额不一致、状态不一致、单边交易）各≥1条。
    • 明确该对账日的期望总笔数与总金额（含正负方向），并与第三方口径一致。
  • 接口协定
    • 已提供可机读的错误码与字段说明（或等效的契约定义），包含：
      • 拉取接口必要请求参数：对账日期/窗口、渠道/商户、分页控制（页大小/游标或等价机制）、鉴权要素。
      • 差异回传必要请求参数：对账批次标识、差异明细（含交易唯一标识、差异类型、我方值/对方值、备注）、幂等键或等价机制。
      • 响应最小集：处理状态、批次标识（用于追踪与幂等）、统计摘要（总笔数/总金额/成功条数等）、错误码与可读信息、可继续分页指示（若适用）。
    • 已明确幂等判定依据与有效期（例如基于幂等键+业务唯一键在某有效期内判定），以及可重试错误的判定标准（如网络超时、限流、服务端可重试错误码集合）。
  • 可观测性
    • 能获取接口调用日志/审计记录（至少包含时间、调用方标识、批次ID/请求ID、错误码）。
    • 具备模拟失败的能力（超时、5xx、限流）用于重试与幂等测试。

验收场景

说明：

  • 角色约定：调用方=我方清结算系统，被调方=第三方支付平台接口。
  • 如项目使用的协议/字段命名与以下描述存在差异，需在执行前完成字段映射，确保测试意图一致。

A. 对账拉取—正常流程

  1. 单日单渠道全量拉取（分页）
    • 步骤：以指定对账日与渠道发起拉取，按分页逐页获取直至结束。
    • 期望：响应包含批次标识；各页无重复无丢失；最后一页指示结束；汇总与明细合计一致。
  2. 多渠道/多商户过滤
    • 步骤：以不同渠道/商户各自拉取。
    • 期望：返回仅包含对应过滤维度数据，互不交叉。
  3. 空数据日
    • 步骤：选择无交易的对账日拉取。
    • 期望：返回空集合且统计为0，不报错。
  4. 大数据量分页稳定性
    • 步骤：使用较小页大小进行完整分页。
    • 期望：全量页拼接后与预置期望相符；无重复/遗漏；分页顺序稳定。
  5. 同批次一致性（快照语义）
    • 步骤：开始分页后，期间向对账来源新增/变更交易，再继续分页。
    • 期望：同一批次内后续分页结果不受期间变更影响；多次请求同批次页数据一致。

B. 对账拉取—参数与校验 6. 非法日期格式/不支持的范围

  • 步骤：日期格式错误、跨多日或未来日。
  • 期望：返回明确的参数错误；不产生批次。
  1. 非法渠道/商户
    • 步骤：传入不存在或无权限的渠道/商户。
    • 期望：返回明确的资源/权限错误；不产生批次。
  2. 分页参数异常
    • 步骤：传入非法页大小、过期/伪造分页游标。
    • 期望：返回明确的参数错误或游标失效错误。
  3. 未鉴权/鉴权失败
    • 步骤：缺失鉴权、使用过期/错误凭据。
    • 期望：返回未授权/禁止访问错误；不产生批次。
  4. 历史可拉取窗口外
  • 步骤：请求超出允许拉取的历史窗口（如过久的历史）。
  • 期望：返回明确的范围错误。

C. 对账拉取—幂等与重试 11. 幂等键重复请求（相同业务参数）

  • 步骤：以相同对账日/渠道与相同幂等键重复请求≥3次。
  • 期望：均返回相同批次ID与相同数据片段；不生成新批次。
  1. 无幂等键但业务参数完全相同的重复请求（幂等窗口内）
  • 步骤：连续发起相同业务参数请求但不传幂等键（若允许）。
  • 期望：返回相同批次（或返回幂等冲突的明确错误）；不重复生成/计费。
  1. 可重试错误后的重试
  • 步骤：模拟首次请求超时或服务端可重试错误码；随后重试直至成功。
  • 期望：最终成功返回的批次ID与最初已接收请求一致；只计一次处理。
  1. 限流后退避重试
  • 步骤：触发限流；按约定退避再试。
  • 期望：限流时返回明确错误；后续成功；不产生重复批次。

D. 差异回传—正常与部分成功 15. 全量差异回传成功

  • 步骤：针对某批次提交差异列表，包含差异类型：缺失、金额不一致、状态不一致。
  • 期望：返回批次级成功；回执含条目数与分类统计；第三方记录可查询。
  1. 部分成功（逐条结果）
  • 步骤：在差异列表中混入无效条目（如不存在交易ID）。
  • 期望：返回逐条处理结果；有效条目成功接收；无效条目返回明确错误原因；批次汇总与明细一致。
  1. 空差异确认
  • 步骤：对同一批次回传空差异列表（表示无差异）。
  • 期望：返回成功并记录无差异确认。

E. 差异回传—幂等与冲突 18. 幂等键重复提交（内容相同）

  • 步骤：使用相同幂等键与完全相同内容重复提交≥3次。
  • 期望：返回相同回执/批次处理结果；不重复入库或触发重复业务动作。
  1. 幂等键重复提交（内容不同）
  • 步骤：相同幂等键但差异内容不同。
  • 期望：返回冲突错误，明确指出与历史请求不一致，不进行变更。
  1. 业务唯一键去重
  • 步骤：差异列表内包含重复交易唯一标识。
  • 期望：仅处理一次；回执对重复条目标注去重或已处理。

F. 差异回传—参数与校验 21. 无效/过期的对账批次ID

  • 步骤：使用不存在或过期批次ID提交差异。
  • 期望：返回明确的批次无效错误；不处理明细。
  1. 单项字段校验错误
  • 步骤：金额精度不合法、币种与批次不一致、缺失必填字段。
  • 期望：对应条目返回参数错误；其他合法条目不受影响。
  1. 敏感信息脱敏
  • 步骤：在备注等字段传入可能包含敏感信息。
  • 期望：响应或可查询明细中不回显完整敏感信息；遵守脱敏规则（不出现完整PAN/CVV等）。

G. 安全与反重放 24. 鉴权时效与签名校验

  • 步骤：构造过期时间戳/错误签名请求。
  • 期望：返回未授权/签名无效；不产生任何业务处理。
  1. 重放攻击拦截
  • 步骤：重放历史请求报文（相同时间戳/随机数/签名）超出允许窗口。
  • 期望：返回重放拒绝错误；在允许窗口内若包含幂等参数应返回相同结果，不重复处理。

H. 容错、恢复与审计追踪 26. 服务端内部错误后的重试

  • 步骤：模拟服务端内部错误；随后重试成功。
  • 期望：最终仅一次有效处理；审计记录包含失败与成功的时间线与请求标识。
  1. 网络中断与超时
  • 步骤：在请求发送后断网或超时，再次重试。
  • 期望：若前次已被服务端接收，重试返回与已处理一致的结果；未接收则按正常处理。
  1. 追踪ID与日志可关联
  • 步骤：记录每次请求返回的请求ID/追踪ID；在日志/审计系统中查询。
  • 期望：可基于该ID检索到对应请求与处理结果，字段一致可对齐。

I. 数据一致性与边界条件 29. 汇总一致性

  • 步骤：对账拉取返回的统计摘要与明细累计比对（按约定口径含退款/撤销）。
  • 期望：总笔数、总金额与明细求和一致；币种一致。
  1. 时间边界过滤
  • 步骤：构造发生在对账日边界（开始/结束瞬间）的交易。
  • 期望：归属与约定时区口径一致，不越界。
  1. 金额与精度边界
  • 步骤：0金额、最小/最大允许金额、最大小数位交易。
  • 期望：均能正确表示与校验；不发生四舍五入导致的汇总偏差。
  1. 分页边界
  • 步骤：最小页大小与最大页大小各一次。
  • 期望：都能返回有效分页；超过最大限制返回明确错误或按上限处理。
  1. 差异回传批量边界
  • 步骤：提交接近/超过单次允许的最大差异条目数。
  • 期望：接近上限时成功处理；超过上限时返回明确错误，不部分隐式截断。

通过标准

  • 场景A1–A5：均返回含批次标识的成功响应；分页无重复/遗漏；同批次多次请求数据一致；汇总与明细一致；空数据日统计为0且无错误。
  • 场景B6–B10：对非法参数/非法资源/鉴权失败/范围越界等均返回明确可机读错误码与说明；不产生批次或业务副作用。
  • 场景C11–C14：重复请求在幂等有效期内返回相同批次ID与相同数据；可重试错误重试后仅一次有效处理；限流后退避重试成功；无重复计数或重复扣费。
  • 场景D15–D17：回执包含批次级处理状态、逐条处理结果与统计；数据在第三方侧可查询；空差异被记录为“无差异确认”。
  • 场景E18–E20：相同幂等键+相同内容返回相同结果；相同幂等键+不同内容返回冲突错误且不变更；列表内重复项仅处理一次且回执标注。
  • 场景F21–F23：无效/过期批次ID被拒绝；字段校验错误逐条返回；敏感信息在响应与可查询明细中不以明文出现，符合脱敏要求。
  • 场景G24–G25：签名/时效校验严格，重放请求在窗口外被拒绝；窗口内结合幂等返回一致结果且不重复处理。
  • 场景H26–H28：在内部错误/网络异常后重试，最终仅一次有效业务处理；审计记录可按请求/追踪ID完全关联。
  • 场景I29–I33：汇总口径与明细一致；时区边界归属准确；金额与精度处理无偏差；分页与批量边界行为符合限制；超限有明确错误且无隐式截断。

通用判定要求：

  • 每个成功响应均包含：可追踪的请求/批次标识、状态、必要统计信息（若适用）。
  • 每个失败/部分成功响应均包含：稳定的机器可读错误码、明确的人类可读说明、必要的字段定位信息（不暴露敏感数据）。
  • 在幂等有效期内，多次相同请求（依据幂等键与业务唯一键判定）返回完全一致的结果；超出有效期的行为以项目配置为准，但不得产生数据重复或不一致。
  • 重试仅可在被标记为可重试的错误情况下进行；最终成功后不得产生重复副作用。

备注说明

  • 幂等与唯一性判定
    • 拉取场景：应基于（对账日/时间窗口 + 渠道/商户 + 分页/拉取维度）结合幂等键/批次机制保证同一快照的一致性。
    • 回传场景：应基于（批次ID + 业务唯一键，如渠道/商户 + 交易唯一标识 + 差异类型）与幂等键共同判定重复。
  • 可重试错误与限流
    • 可重试错误码集合、退避策略、最大重试次数由项目配置提供；验收以该配置为准验证“最终一次有效处理”的语义。
  • 时区与口径
    • 对账日的边界与退款/撤销的计入口径须在项目文档中明确；验收以该口径核对汇总与明细一致性。
  • 分页/批量限制
    • 页大小上限、差异回传单批上限由项目配置提供；验收覆盖上限、超限与游标失效情形。
  • 安全与合规
    • 鉴权失败、签名无效、重放、越权访问需有明确错误与无副作用保证。
    • 响应与日志中不得出现敏感信息明文（如完整卡号/CVV）；必要信息应脱敏或散列。
  • 可观测性
    • 请求/批次全程需可追踪；日志/审计信息满足问题定位与合规审计需要，且与响应中的追踪ID可对齐。

以上验收标准覆盖正常流程、异常与边界场景，所有条件均可通过请求输入、响应输出、日志与可查询记录进行验证；不依赖未确认的实现细节，仅基于对外可观测行为进行判定。

用户验收标准文档：住院药品消耗日报与科室成本分摊报表（含异常库存修正）

功能概述

本功能提供住院药品在单个自然日内的消耗统计与按科室的成本分摊结果，支持对“异常库存修正”对消耗与成本的影响进行显式标识与可追溯。该报表面向药学、财务及内控审计场景，用于：

  • 日级监控住院用药数量与金额，支撑成本核算与异常监测
  • 按指定分摊维度（如处方/发药归属科室、病区、成本中心）归集药品成本
  • 区分并可选包含异常库存修正带来的数量/金额影响，确保账实一致与可审计性
  • 支持从汇总到单据明细的追溯，确保数据可验证、可对账

前置条件

  • 组织与基础数据
    • 已配置并有效的：院区/机构、科室/病区、药品主数据（含规格、基础计量单位、转换系数）、在院患者档案。
    • 权限模型生效：测试账号分别具备“药房报表查看（住院）”“科室成本报表查看”“数据导出”权限。
  • 业务规则与参数
    • 报表计算采用“业务日期”（非系统记账/创建时间）。
    • 单位成本取值遵循系统全局参数“药品成本计价规则”（例如移动加权、先进先出等，具体以系统参数为准），报表需显示所用规则名称/编号。
    • 金额保留位数与舍入方式采用系统货币参数；数量保留位数采用药品数量精度参数。
    • 分摊维度与口径由报表参数选择（如：按用药归属科室/病区/成本中心），且该维度在业务单据中有可用字段映射；若记录缺失分摊维度，则归入“未归属”。
    • “异常库存修正”来源于库存模块的标记为“异常修正”的调整单据（或调整明细），可被报表识别并单列展示/统计。
  • 测试数据
    • 至少覆盖：发药、退药、报废（报损）、盘盈、盘亏、内部调拨（入/出）、异常库存修正（正/负向）、零成本与多批次成本场景。
    • 同日内至少含2个以上科室的用药记录；至少1条缺失分摊维度的记录用于校验“未归属”。
    • 至少1笔跨日回填（业务日期在T日，入账在T+1日）用于回溯校验。
  • 技术与运行
    • 报表可筛选参数：业务日期（必填，单日）、机构/药房、分摊维度、是否包含异常库存修正（是/否）、药品筛选、科室筛选。
    • 报表支持分页查看与导出（Excel/PDF至少一种），导出内容与屏幕数据一致。
    • 报表页眉需包含：参数值、生成时间、操作者、数据版本/快照标识（若系统支持）。

验收场景

场景S1：参数与页眉信息展示

  • 步骤
    • 选择业务日期=T日，机构/药房=X，分摊维度=用药归属科室，包含异常库存修正=是。
    • 生成报表。
  • 预期结果
    • 页眉显示：业务日期、机构/药房、分摊维度、是否包含异常修正、计价规则名称/编号、生成时间、操作者、数据版本/快照标识（若有）。
    • 参数显示与实际筛选一致。

场景S2：日消耗与分类口径（单药、单科室）

  • 步骤
    • 准备同一药品在T日的以下明细：发药=100，退药=10，报废=2，盘亏=1，盘盈=3，内部调拨出=5，内部调拨入=5，异常库存修正（正向）=4，异常库存修正（负向）=0；均归属同一科室。
    • 生成报表（包含异常修正=是）。
  • 预期结果
    • 当日消耗数量=发药-退药+报废+盘亏+(异常修正净额)，即100-10+2+1+(4-0)=97。
    • 内部调拨入/出不计入消耗，仅影响库存，不影响消耗统计。
    • 当日消耗金额=当日消耗数量×单位成本（单位成本遵循计价规则），四舍五入按系统货币精度。
    • 报表对该药品/科室行显示：分类数量、当日消耗数量与金额、期初/期末库存数量（期末=期初+入库-出库+调整）。

场景S3：多科室成本分摊与汇总守恒

  • 步骤
    • 准备T日两个科室A、B的发退药记录（含不同单位成本批次），生成报表。
  • 预期结果
    • 各科室消耗金额之和=机构/药房总消耗金额（允许因四舍五入产生的总差异≤最小货币单位；差异处理遵循系统舍入/汇总规则）。
    • 分摊维度变更为“病区/成本中心”后，同一批数据按新维度重分组，汇总金额守恒。

场景S4：异常库存修正包含/排除

  • 步骤
    • 对同一T日数据，分别选择“包含异常修正=是/否”生成报表。
  • 预期结果
    • 仅当“包含=是”时，异常库存修正数量与金额计入“当日消耗”（按正负号计入），并在报表列中单列展示其数量与金额贡献。
    • 当“包含=否”时，异常修正对应的数量与金额不计入消耗，但可在备注/底部说明显示“已排除异常修正”。

场景S5：明细追溯

  • 步骤
    • 在汇总行点击“查看明细”（或通过明细页）查看到单据级清单。
  • 预期结果
    • 明细包含：单据号、业务日期、患者/住院号（脱敏字段符合隐私要求）、分摊维度值、数量、单位成本、金额、来源类型（发药/退药/报废/盘亏/盘盈/异常修正/调拨）、制单与审核信息。
    • 汇总=明细加总；可从明细反查至原业务单据。

场景S6：单位换算与计量

  • 步骤
    • 准备含包装单位与基础单位差异的药品（如1盒=10片），发药按盒，退药按片。
    • 生成报表。
  • 预期结果
    • 报表统一以基础计量单位统计数量；换算系数正确；显示单位一致。
    • 金额计算基于换算后的数量与单位成本。

场景S7：负消耗与退药超发药

  • 步骤
    • 准备T日某药品退药数量>发药数量（无其他调整）。
  • 预期结果
    • 当日消耗数量为负数，金额为负数；汇总守恒；负值以“-”号显示，不做截断或强行置零。
    • 明细追溯可证明负值来源于退药超出发药。

场景S8：跨日回填/补记

  • 步骤
    • 在T+1日录入一笔业务日期为T日的发药单。
    • 分别在T日与T+1日生成报表（同参数）。
  • 预期结果
    • T日重算后包含该笔跨日回填数据；页眉生成时间更新。
    • T+1日报表不包含该笔（因业务日期为T日）。

场景S9：缺失分摊维度与无数据提示

  • 步骤
    • 对存在分摊维度字段缺失的明细生成报表。
    • 对完全无数据的日期生成报表。
  • 预期结果
    • 缺失分摊维度的记录归入“未归属”分组且不被丢弃；“未归属”分组可下钻明细。
    • 无数据时显示明确的空状态提示：“所选条件下无数据”，导出按钮置灰或导出空模板。

场景S10：权限与数据隔离

  • 步骤
    • 使用仅授权科室A的账号生成报表。
  • 预期结果
    • 仅能看到科室A及“未归属但与A相关”的数据；无权访问的科室数据不展示；导出结果与屏幕一致。

场景S11：导出一致性

  • 步骤
    • 将当前报表导出Excel/PDF。
  • 预期结果
    • 导出文件的筛选条件、汇总值、明细行数与屏幕一致；数字精度与格式一致；文件可打开且无损坏。

场景S12：与库存台账对账

  • 步骤
    • 获取T日药房库存台账（或库存结存报表），核对某药品的期初、当日入库、当日出库、调整、期末。
  • 预期结果
    • 报表显示的期初/期末与库存台账一致；当日出库组成（发药、退药、报废、盘亏、异常修正、调拨）分类加总与台账口径一致（调拨不计入消耗但计入出入库分类）。

场景S13：零成本与异常值处理

  • 步骤
    • 准备单位成本=0的明细、极小或极大数量的明细。
  • 预期结果
    • 0成本记录金额=0并在“成本异常”标记列中标注；不影响其他记录计算。
    • 无计算溢出；显示遵循精度设置。

通过标准

  • S1：页眉参数、计价规则名、生成时间、操作者、数据版本显示完整且与输入一致。
  • S2：当日消耗数量按“发药-退药+报废+盘亏+（异常修正入-异常修正出）”计算，内部调拨不计入消耗；金额=数量×单位成本（精度符合系统设置）。
  • S3：各分摊分组金额合计=报表总金额（差异≤最小货币单位且按系统规则处理）；更换分摊维度后总额守恒。
  • S4：当“包含异常修正=是”时，异常修正数量/金额计入并单列；为“否”时不计入且有排除说明。
  • S5：汇总与明细可相互核对；明细含必要字段并可追溯至原单据。
  • S6：数量统一以基础计量单位展示；换算准确；金额按换算后数量计算。
  • S7：退药超发药时显示负数消耗与金额；不得自动置零或隐藏。
  • S8：报表基于业务日期重算；跨日回填计入对应业务日，页眉生成时间变更。
  • S9：缺失分摊维度归入“未归属”且可下钻；无数据时给出明确空状态提示；导出行为与空状态一致。
  • S10：用户仅能查看授权机构/科室数据；导出与屏幕一致；无越权数据泄露。
  • S11：导出文件数值、行数、汇总、精度与屏幕一致；文件可正常打开。
  • S12：期初/期末与库存台账一致；出入库分类与台账口径一致；调拨不计入消耗。
  • S13：0成本记录金额=0并有异常标记；极值数据不导致计算错误或展示异常。

备注说明

  • 数据口径
    • 报表以“业务日期”为准；若系统存在数据锁定/结账机制，则遵循已结账数据不可被重算的规则（该机制的启用与否以系统配置为准）。
    • 当日消耗定义：面向住院使用的实际净耗用，包含发退差异与因报废/盘亏/异常修正导致的净减少；内部调拨不构成消耗。
  • 计价与精度
    • 单位成本严格遵循系统“药品成本计价规则”参数；报表仅引用、不变更该规则。
    • 金额与数量精度按系统全局设置执行；总计与明细存在四舍五入差异时，按系统汇总/差异分摊规则处理。
  • 异常库存修正
    • “异常库存修正”仅指库存模块中标记为异常修正的调整类单据（或明细）；报表读取其标记用于分类与可选纳入。
    • 报表需提供异常修正的数量与金额专列及来源类型，便于审计。
  • 安全与隐私
    • 展示患者相关字段时应满足脱敏/最小化原则；仅展示验收所需最少信息。
  • 非功能说明
    • 报表生成需在系统约定的SLA内完成；性能与并发验证在非功能验收中单独评估。
  • 一致性与可追溯
    • 报表各层级（总计-分组-明细）求和一致；支持从报表明细反查至原业务单据，确保可审计与可复核。

以上验收标准覆盖正常流程、异常场景与边界条件，所有条件均可通过配置、数据准备与操作步骤进行验证。

示例详情

📖 如何使用

⚡ 30秒出活：复制 → 粘贴 → 搞定
与其花几十分钟和AI聊天、试错，不如直接复制这些经过千人验证的模板，修改几个 {{变量}} 就能立刻获得专业级输出。省下来的时间，足够你轻松享受两杯咖啡！
加载中...
💬 不会填参数？让 AI 反过来问你
不确定变量该填什么？一键转为对话模式，AI 会像资深顾问一样逐步引导你，问几个问题就能自动生成完美匹配你需求的定制结果。零门槛，开口就行。
转为对话模式 →
🚀 告别复制粘贴，Chat 里直接调用
无需切换，输入 / 唤醒 8000+ 专家级提示词。 插件将全站提示词库深度集成于 Chat 输入框。基于当前对话语境，系统智能推荐最契合的 Prompt 并自动完成参数化，让海量资源触手可及，从此彻底告别"手动搬运"。
即将推出
🔌 接口一调，提示词自己会进化
手动跑一次还行，跑一百次呢？通过 API 接口动态注入变量，接入批量评价引擎，让程序自动迭代出更高质量的提示词方案。Prompt 会自己进化，你只管收结果。
发布 API →
🤖 一键变成你的专属 Agent 应用
不想每次都配参数？把这条提示词直接发布成独立 Agent，内嵌图片生成、参数优化等工具，分享链接就能用。给团队或客户一个"开箱即用"的完整方案。
创建 Agent →

✅ 特性总结

一键生成结构化验收标准，含目标、前置、场景与通过规则，即刻落地
自动梳理正常、异常与边界情景，确保测试覆盖全面不留空档与风险点可追踪
基于业务语境智能措辞，避免歧义，验收条款清晰可测、可复用，便于评审
按行业场景快速定制，如电商支付、ERP报表、移动登录等一键套用，减少准备时间
内置完备的前置条件与数据准备提示，避免漏项，测试更顺畅，减少返工
为每个场景给出明确通过标准与验证方法，结果一目了然可签收，减少争议
内置完整性自检流程，自动提示缺失规则与边界，保障交付不掉项，提升质量
支持按功能类型、复杂度与业务域参数化调用，团队协作更丝滑，复用效率高
输出即为评审材料，可直接对齐产品、研发与测试，缩短沟通周期，加速上线

🎯 解决的问题

面向产品、研发与测试协同场景，帮助团队在分钟级产出可直接落地的“用户验收标准”，把抽象需求转化为清晰、可验证、可签收的准绳：

  • 明确“什么才算完成”，将业务目标映射为可量化的通过条件
  • 全面覆盖主流程、异常处理与边界情况，减少遗漏与返工
  • 固化统一话术与结构，提升跨部门沟通效率与对齐速度
  • 直接服务测试用例设计与版本签收，降低交付不确定性
  • 适配软件开发、系统集成、产品迭代等多种落地场景

🕒 版本历史

当前版本
v2.1 2024-01-15
优化输出结构，增强情节连贯性
  • ✨ 新增章节节奏控制参数
  • 🔧 优化人物关系描述逻辑
  • 📝 改进主题深化引导语
  • 🎯 增强情节转折点设计
v2.0 2023-12-20
重构提示词架构，提升生成质量
  • 🚀 全新的提示词结构设计
  • 📊 增加输出格式化选项
  • 💡 优化角色塑造引导
v1.5 2023-11-10
修复已知问题，提升稳定性
  • 🐛 修复长文本处理bug
  • ⚡ 提升响应速度
v1.0 2023-10-01
首次发布
  • 🎉 初始版本上线
COMING SOON
版本历史追踪，即将启航
记录每一次提示词的进化与升级，敬请期待。

💬 用户评价

4.8
⭐⭐⭐⭐⭐
基于 28 条评价
5星
85%
4星
12%
3星
3%
👤
电商运营 - 张先生
⭐⭐⭐⭐⭐ 2025-01-15
双十一用这个提示词生成了20多张海报，效果非常好！点击率提升了35%，节省了大量设计时间。参数调整很灵活，能快速适配不同节日。
效果好 节省时间
👤
品牌设计师 - 李女士
⭐⭐⭐⭐⭐ 2025-01-10
作为设计师，这个提示词帮我快速生成创意方向，大大提升了工作效率。生成的海报氛围感很强，稍作调整就能直接使用。
创意好 专业
COMING SOON
用户评价与反馈系统，即将上线
倾听真实反馈，在这里留下您的使用心得，敬请期待。
加载中...
敬请期待...