已付款、已交付、已观察到 Plus：三种状态怎样分开核验
已支付不自动等于交付完成，交付完成也不能替代本人账号的套餐核验。AIXiamo 恢复这份原 A 库离线示例：把付款状态、交付状态与人工记录的账号套餐放在不同字段，再决定下一步查付款、等交付还是补证据。所有订单和账号代号均为构造数据；程序只在内存运行，不连接真实订单、不登录 ChatGPT、不获取任何密码或 Token。
先看结论
付款证据是否确实付款或退款查看原支付渠道，不用套餐截图替代账单
交付证据pending、processing 或 completed来自原订单，不与付款状态合并
账号证据正确账号的近期套餐观察缺失、陈旧或另一账号的记录仍需复核
先读输入，再运行离线样例
给记录使用本地代号
用 O04、A04 等虚构订单和账号键理解关联；实际资料不要放在公开评论或上传到练习仓库。
分别记录付款和交付
paid、refunded 等付款记录与 pending、processing、completed 等交付记录来自各自原渠道，不把一个字段补成另一个字段。
补充同一账号的人工观察
记录实际观察时间和套餐文字；只有订单目标账号与观察账号一致，且时间满足样例规则，才继续判断。脚本不会自动读取官方账号。
下载完整三个运行文件
把 reconciliation.sql、expected.tsv、verify.py 放在同一独立练习目录，阅读源码后运行 python3 verify.py。Python 3 标准库即可，不需要网络或数据库密码。
按结果回原渠道处理
需要确认付款就查付款，需要交付进度就查原订单，证据未知则补证据。不要为了得到完成结果而选择有利的旧记录。
完整文件与可复现输出
这份示例来自原 A 库 2026 年 9 月 8 日发布的源码。2026 年 10 月 12 日恢复到自建教程站时，用 SQLite 3.51.2 实跑通过：9行完整预期输出逐列一致，另有11项边界断言。迁站不是一笔新的真实订单实验。
python3 verify.py
# OK: 9 core + 11 boundary scenarios; SQLite 3.51.2
# 只查看构造数据的结果，需要本机 sqlite3 命令：
sqlite3 -header -column :memory: < reconciliation.sql9个案例到底证明什么
原始 expected.tsv 保留所有5列结果，而不是只列成功案例。构造情形包括未确认付款、交付处理中、缺少证据、近期 Plus、过期证据、另一账号、已退款、近期 Free 与未来观察。
plus_observed 仅表示输入记录在所述时间观察到目标账号为 Plus。它不能证明续费新增期限、持续可用性、某笔付款造成状态变化，也不能替代原支付系统确认。
- confirm_payment：先确认付款；套餐观察不会自动把未知付款改成已付。
- delivery_processing：继续核对交付，不把处理中当完成。
- review_evidence：账号、套餐或时间证据还不能支撑结论。
- refund_review：先核对退款，即使仍存在 Plus 观察。
时间规则和适用边界
本例全部时间采用同一个北京时间墙钟格式，固定核验时刻为 2026-09-08 12:00:00，不做时区转换。近期窗口为11:30:00至12:00:00，包含两端；观察也必须不早于付款确认。30分钟是示例证据新鲜度，不是到账时间承诺。
查询和验证器仅演示小规模状态分离。用于自己的应用前，需要另外规范非法日期、部分退款、重复付款事件与同秒冲突观察；不要直接把练习查询接到生产财务数据库。需要判断续费期限时，继续查看下一份独立的有效期核验教程。
安全与事实检查
- 付款、交付和账号套餐使用独立字段。
- 不要公开真实订单号、邮箱、付款资料或账号凭据。
- 固定样例日期与30分钟规则不冒充实时账号数据或到账 SLA。
- 正式订单仍回原订单渠道查询，脚本不能决定扣款、退款或发货。
常见问题
脚本会读取 ChatGPT 账号或商家数据库吗？
不会。两个输入集合直接写在样例 SQL 的 CTE 中，验证器仅通过 Python 标准库在内存运行查询，启用 query_only，不联网、不读取凭据、不登录账号。
输出 plus_observed 就能确认续费足额到账吗？
不能。它只确认输入中存在满足样例条件的 Plus 观察。新增期限需要付款前基线、付款后有效期和本次约定的目标到期时间，另由续费有效期示例比较。
官方参考
产品功能、方案名称、用量与地区可用性以 OpenAI 当前官方页面为准。
AIXiamo 购买、交付与售后条件以对应实时商品页和原订单为准，不是上述官方文档的服务承诺。内容维护与纠错