生成式 AI 对出版内容的使用正在从模糊的授权讨论，走向可以计量和结算的商业流程。Cloudflare 推出的 Pay Per Use 目前处于 beta 阶段：AI 公司报告自己使用了哪些出版商内容，Cloudflare 负责账单、付款和报表，让内容提供方能够按实际使用量获得收入。
这项机制的关键不只是“收费”，而是把内容使用转化为可核对的业务记录。只有使用量、计价规则和付款结果能够对应起来，出版商与 AI 公司之间的授权关系才可能长期运行。
从一次性授权转向按使用量结算
传统内容授权通常采用固定期限、固定费用或整体内容库打包的方式。它适合使用规模相对稳定的场景，却不容易反映 AI 系统的动态需求：某些内容可能被频繁使用，另一些内容则几乎没有进入实际工作流。
Pay Per Use 所描述的模式把流程拆成三个部分：
- AI 公司报告内容使用情况：使用记录成为结算依据。
- Cloudflare 处理账单与付款：平台承担计费、收款和向出版商支付的流程。
- 双方通过报表核对结果：出版商可以了解使用量以及对应收入。
对于出版商，这意味着收入有机会与实际需求关联，而不是只依赖广告、订阅或一次性授权。对于 AI 公司，按量模式也能降低预先购买大规模内容许可的压力。不过，最终成本是否更低，仍取决于使用频率和定价方式。
真正困难的是定义“使用一次”
按次付费听起来直观，落地时却必须先回答计量问题。例如，下面这些行为是否属于同一种使用：
- 抓取页面并建立索引；
- 将内容用于模型训练或微调；
- 在检索增强生成流程中召回一个段落；
- 使用内容生成答案，但最终没有展示引用；
- 同一篇文章被同一用户会话多次检索；
- 缓存命中后再次生成答案。
来源摘要只说明 AI 公司负责报告使用情况，并未给出具体计量单位、价格结构或争议处理规则。因此，接入前不能只确认“每次多少钱”，还应明确以下字段：
| 问题 | 建议写入规则的内容 |
|---|---|
| 计费单位 | 页面、文档、片段、请求还是生成结果 |
| 去重方式 | 按请求、用户会话或时间窗口去重 |
| 内容身份 | URL、出版商内容 ID 或内容版本 ID |
| 使用类型 | 训练、检索、摘要或回答生成 |
| 无效记录 | 重试、测试流量和失败请求是否收费 |
| 价格版本 | 调价后如何区分新旧费率 |
| 对账周期 | 日、周或月，以及何时锁定报表 |
如果这些定义不稳定，即使平台能够自动付款，出版商内部仍可能无法把报表与自己的内容系统对应起来。
可以这样实践：建立本地对账脚本
下面是一个可直接运行的最小示例。它不代表 Cloudflare 官方 API 或正式报表格式，而是假设平台能够导出包含 usage_id、content_id、used_at 和 status 的 CSV。脚本会去重、排除未接受的记录，并按内容统计预计收入。
运行前只需要修改 UNIT_PRICE_USD，并在真实接入时把 CSV 字段映射为实际报表字段。
mkdir -p pay-per-use-demo && cd pay-per-use-demo
cat > usage.csv <<'CSV'
usage_id,content_id,used_at,status
u-1001,article-42,2025-02-01T10:00:00Z,accepted
u-1002,article-42,2025-02-01T10:05:00Z,accepted
u-1002,article-42,2025-02-01T10:05:00Z,accepted
u-1003,article-77,2025-02-01T11:00:00Z,rejected
u-1004,article-77,2025-02-01T12:00:00Z,accepted
CSV
cat > reconcile.py <<'PY'
import csv
from collections import Counter
from decimal import Decimal
UNIT_PRICE_USD = Decimal("0.0200")
seen_usage_ids = set()
accepted_by_content = Counter()
with open("usage.csv", newline="", encoding="utf-8") as file:
for row in csv.DictReader(file):
usage_id = row["usage_id"]
if usage_id in seen_usage_ids:
continue
seen_usage_ids.add(usage_id)
if row["status"] != "accepted":
continue
accepted_by_content[row["content_id"]] += 1
total_uses = 0
total_amount = Decimal("0")
print("content_id,accepted_uses,estimated_amount_usd")
for content_id, uses in sorted(accepted_by_content.items()):
amount = UNIT_PRICE_USD * uses
total_uses += uses
total_amount += amount
print(f"{content_id},{uses},{amount:.4f}")
print(f"TOTAL,{total_uses},{total_amount:.4f}")
PY
python3 reconcile.py
预期输出如下：
content_id,accepted_uses,estimated_amount_usd
article-42,2,0.0400
article-77,1,0.0200
TOTAL,3,0.0600
真实系统还应保存原始报表文件的校验值，并避免直接覆盖历史记录。例如可以为每个结算周期保存一份不可变快照：
sha256sum usage.csv > usage.csv.sha256
mkdir -p archive/2025-02
cp usage.csv usage.csv.sha256 archive/2025-02/
这样，当财务金额与内容后台统计不一致时，团队可以确认当时究竟使用了哪一版数据。
接入前应同时检查商业规则与数据治理
Pay Per Use 解决的是使用报告、账单、付款和报表之间的流程衔接，但平台自动化不能替代合同与内部治理。出版商在 beta 阶段尤其应该关注：
- 是否能按内容 ID、日期和使用类型导出明细；
- 使用记录由谁生成，如何处理迟到、重复或撤销事件；
- 费率是否按出版商、内容类别或使用方式区分；
- 报表金额、发票金额和实际付款能否形成一一对应关系；
- 内容删除或授权终止后，后续使用如何处理；
- 是否存在最低付款额、退款、税务或币种转换规则；
- 发现异常使用量时，出版商通过什么流程提出争议。
内部架构上，最好使用稳定的内容 ID，而不是只依赖 URL。URL 可能因为改版、栏目迁移或参数变化而改变；内容 ID 加版本号则更适合长期对账。
是否值得采用：先用小范围内容验证
对于希望把 AI 使用转化为新收入来源的出版商，Pay Per Use 提供了一条比自行建设计费和付款系统更直接的路径。但它仍处于 beta 阶段，计量口径、报表完整性和内部对账成本都需要实际验证。
更稳妥的采用方式是选择一个内容分类或一组明确授权的文章进行试点，并在首个结算周期检查四件事：使用事件能否追溯、重复记录能否识别、费率能否复算、付款能否与报表匹配。只有这四条链路都成立，按次付费才不只是一个定价概念，而是一套可以审计和扩展的内容商业模式。