OpenAI API做摘要按钮：输入、输出与合格结果，要算同一笔账

想给自己的网站加一个摘要按钮，我会先把目标写得很小：读完一段正文，返回三条要点，遇到空内容就提示补充。这样的任务容易验收，也容易估计费用。先追着最大的模型接一圈，最后才发现每次回复太长、把全文重复送了好几遍，就有些本末倒置了。

一条摘要里，输入和输出都要算

OpenAI 官方文档将普通输入、缓存输入、缓存写入和输出分别列价，还区分处理模式与上下文档位。以当前 gpt-6.1-sol 的 Standard 短上下文为例，普通输入为 US$2/百万 tokens，输出为10美元/百万；短上下文指单次输入不超过272K tokens。[1]

假设很多条短请求累计用了100万普通输入和20万输出 tokens，按上述费率算文本费是 US$4。这个例子不是一条百万输入的短上下文请求，也没有把缓存、搜索、区域处理和应用资源费用算进去。[1]

能等结果的任务，再看看 Batch

访客点按钮之后等答案，和夜间把一批旧文章做摘要，是两种工作。Batch 适合不需要立刻返回的请求，官方说明有相对同步调用50%的成本折扣和24小时完成窗口；结果按 custom_id 对回原任务，而不依赖文件中的返回顺序。[2]

我会先保留每篇文章的任务编号与状态，把失败项单独整理出来。需要重新处理时，只重做那些项，避免因“整批再跑一遍”重复产生有效任务。这里是接入建议，本文没有上传批次或进行调用测试。

我的起步建议：十条样本和一个明确输出

找十段长短不同的正文，先定义什么叫合格摘要：有没有捏造价格、有没有漏掉限制、能不能在页面里直接读。再记实际输入输出用量和等待时间。质量够用后再比较更低费用或更快模式；用户只是想看三条要点，没必要默认输出一整篇解释。