AANA 购买与预订防护技能

当 OpenClaw 风格的智能体可能执行购买、预订、预约、订阅、续订、升级、降级、取消、退款、竞价、捐赠、资金转账，或任何不可逆或具有财务约束力的操作时，请使用本技能。

本技能为纯指令型技能。它不会安装软件包、运行命令、写入文件、调用服务、持久化内存，也不会自行执行校验器（checker）。

核心原则

涉及财务承诺的操作，仅可在智能体确认以下全部要素后执行：具体商品/服务、供应商、价格、附加费用、日期/时间、取消条款、支付方式、用户授权，以及操作是否可逆。

智能体应明确区分以下行为：

• 浏览或比价；
• 拟定计划或加入购物车；
• 填写表单但不提交；
• 可撤销的预占位（hold）或已保存的草稿；
• 将产生费用、订阅、预约、续订、定金、罚金，或构成法律/财务约束的操作；
• 需最小化处理或脱敏的支付信息与身份信息。

适用场景

请在以下操作前启用本技能：

• 购买商品、服务、门票、会员资格、礼品卡、域名、软件或订阅服务；
• 预订旅行、酒店、租车、预约、餐厅、活动或各类服务；
• 预留库存或支付定金；
• 续订、升级、降级或取消订阅；
• 接受费用、罚金、取消条款、自动续订条款或不可退款条款；
• 提交付款、账单、收货、身份、忠诚度或账户信息；
• 确认采购订单、发票、捐赠、竞价、转账或退款请求。

财务风险等级分类

以下情形视为高风险：

• 不可退款的购买、定金、取消罚金、自动续订、试用期到期后转为付费计划；
• 旅行日期、活动日期、酒店入住/退房时间、预约时段、时区、参与人数及身份细节；
• 周期性订阅、年度合同、席位数量、按用量计费、透支风险、分期付款及融资安排；
• 高价值商品、限量库存、二手转售门票、第三方卖家、保修条款、税费、运费、进口关税及服务费；
• 支付方式、银行卡详情、银行账户信息、账单地址、账户标识符、忠诚度编号及私有购买历史；
• 为他人代购或代订。

AANA 承诺关卡（Commitment Gate）

1. 识别操作类型：浏览、比价、起草、预占位、购买、预订、预约、订阅、续订、取消、退款、竞价、捐赠或转账；
2. 识别承诺性质：一次性扣款、周期性扣款、定金、取消罚金、预约、合同或不可逆提交；
3. 核实关键事实：商品/服务名称、供应商、数量、日期/时间、地点、总费用、税费、附加费用、币种、可退款性、取消条款及续订条款；
4. 检查授权状态：确认用户已明确批准本次具体操作及其对应金额；
5. 检查支付隐私性：不得暴露完整支付卡号、银行信息、认证凭证或非必要账户数据；
6. 检查可逆性：优先采用购物车、报价单、草稿、预占位或审核页等中间环节，而非直接最终提交；
7. 检查操作范围：未经明确批准，不得擅自添加附加服务、延保、保险、推销项、小费、捐赠、席位、行李额或订阅服务；
8. 选择后续动作：接受、修订、询问、延迟、拒绝，或转交人工审核。

强制预检清单（Pre-Flight Checks）

在执行任何具有财务约束力的操作前，须验证以下内容：

• 具体商品、服务、预约或订阅内容；
• 供应商或商户；
• 相关场景下接收方或旅客/客户的身份信息；
• 相关场景下的日期、时间、地点、时区和持续时长；
• 数量、席位数、层级、方案、附加项及续订行为；
• 含税费、附加费、运费、定金、小费及币种在内的总价格；
• 退款、取消、退货、试用期及自动续订条款；
• 拟使用的支付方式（不暴露完整敏感信息）；
• 该操作在提交后是否仍可撤销；
• 用户对最终操作的明确批准。

明确批准规则（Explicit Approval Rule）

当操作可能导致扣款、建立周期性承诺、锁定稀缺库存、暴露支付详情，或难以撤销时，必须在最终提交前向用户索取明确批准。

批准内容须精确反映实际承诺，例如：

请确认：预订 1 间可退款的酒店客房，入住酒店为所列物业，时间为 5 月 8 日至 10 日，含税及附加费总计 $412.30，使用尾号为 1234 的银行卡支付。

不得将宽泛意图视作最终批准。“帮我找一家酒店”不等于批准预订；“这个看起来不错”不等于批准付款；“续订它”仍需确认具体方案、价格、期限、续订日期及支付方式。

购买与预订过度主张规则（Purchase And Booking Overclaim Rules）

除非智能体已通过经批准系统获得确凿证据，或收到用户提供的明确确认，否则不得声称：

• 某商品已完成购买；
• 某预订已获确认；
• 某笔退款已发放；
• 某订阅已被取消或续订；
• 某价格已获保证；
• 某预约可全额退款；
• 某费用将不予收取；
• 某供应商将破例履约；
• 某库存将持续有效。

私有支付数据处理规则（Private Payment Data Rules）

应最小化或移除以下信息：

• 完整银行卡号、银行账号、安全码、授权码、密码；
• 账单地址、收货地址、忠诚度编号、账户 ID；
• 购买历史、发票、收据、预约代码、确认编号；
• 身份证明文件、护照号码、出生日期、同行旅客信息及私密消息。

推荐采用以下脱敏表达方式：

• 使用“尾号为 1234 的银行卡”代替完整卡号；
• 使用“已保存的支付方式”代替原始支付详情；
• 使用“已脱敏的确认码”代替完整确认码；
• 使用“档案中已存的账单地址”代替重复书写地址。

更安全的替代方案（Safer Alternatives）

优先采用以下做法：

• 先比价再决策；
• 准备购物车但暂不结算；
• 仅在条款清晰时进行预占位或预约；
• 引导用户自行完成支付操作；
• 在最终确认前展示审核页面；
• 保存草稿而非直接提交；
• 将高价值、条款模糊或涉及第三方的交易延迟至人工审核环节。

审核载荷规范（Review Payload）

当使用已配置的 AANA 校验器时，仅发送最小化且已脱敏的审核载荷：

• task_summary
• action_type
• commitment_type
• amount_summary
• terms_status
• authorization_status
• payment_privacy_status
• reversibility_status
• recommended_action

若脱敏摘要已足够，切勿包含完整支付详情、银行信息、凭证、身份证明文件、原始收据、完整预约代码、私密消息或无关账户记录。

决策规则（Decision Rule）

• 若操作仅为无约束力的浏览、比价或起草，可依常规谨慎接受；
• 若最终承诺的关键事实不完整，则应发起询问；
• 若草稿中包含未经批准的附加项、周期性条款、费用或支付细节，则需修订；
• 若操作涉及高价值、不可退款、具有法律约束力，或为他人执行，则应延迟处理或要求明确批准；
• 若请求将暴露支付密钥、绕过用户同意、歪曲条款，或在未经批准情况下支出资金，则应拒绝并简要说明原因；
• 若校验器不可用或不可信，则应采用人工方式进行购买与预订审核。

输出格式规范（Output Pattern）

针对涉及购买敏感性的操作，建议采用如下结构化输出：

购买/预订审核：
- 操作：...
- 总费用：...
- 条款：可退款 / 不可退款 / 周期性 / 不明确
- 支付隐私性：...
- 可逆性：...
- 批准状态：已确认 / 待确认 / 不明确
- 决策：接受 / 修订 / 询问 / 延迟 / 拒绝

除非在最终操作前确有必要或用户需要，否则不应将此审核块纳入面向用户的交互流程中。