AI 付费报告：串联解锁、追问与使用额度

把三种规则分别管理

报告页面不能只依赖一个“是否会员”的开关。已经交付的报告、访问权益和 AI 请求，需要分别记录。报告包含所属用户、状态与版本；权益决定当前用户能否阅读；AI 请求用操作编号记录完成、失败或取消。

例如，用户购买一份饮食周报，包含两次追问。保存的周报是可以保留的结果，两次追问则是新的模型调用额度。如果购买规则允许持续阅读，用完追问次数不应该删除报告。

先定义行为，再设计付费墙

Table Note 网页演示采用简化规则：完成回复扣一次，失败不扣。真实模型服务商可能仍然对中断的生成计费，因此需要先确认这部分成本由谁承担。

追问需要明确的上下文

通过有权限校验的服务端查询，读取所选报告编号、版本和相关章节。不能直接相信客户端传入的报告编号，应检查所属用户。将当前问题与本次回答所需的上下文一起发送给模型。

用户收到报告后修改偏好，要区分原始结果与新的建议。不能因为今天的偏好改变，就悄悄改写之前付费获得的结果。

验收时补上三个容易遗漏的场景

1. 重复重试：生成已完成，但网络断开；使用相同操作编号重试，结果与扣次都不重复。
2. 最后一次额度的并发：同时发起两个请求，由服务端原子地处理额度，不能依赖客户端展示的余额。
3. 重新打开：回复次数为零时关闭并重新打开 App，报告仍按自身的访问条款展示。

AppBento 的 A + B + C 是这个流程的起点。上线方案会明确你项目实际包含的源码、购买集成、后端职责与验收条件。

体验虚构的报告与追问演示。它展示交互行为，不是一次真实商店交易。