Codex 的成本怎么算，本地模型什么时候值得用
判断值不值得，不能只看每月花多少，要看这件事一年重复多少次、每次省多少时间、错误率降了多少。真正的成本大头是把流程写清楚和后续维护，而这部分投入就算不用任何 AI 也有价值。推理强度和子代理是两个直接影响消耗的开关，判断类任务调高、整理类调低，子代理只在原始材料会撑爆主上下文时才划算。本地模型适合数据敏感和网络受限的场景，按目录分流比全部本地化更实际。
先讲结论：订阅费是最小的一块
这是导入前最容易算错的一笔账。很多人只算订阅费，然后得出「很便宜」或者「不值」，两个方向都容易错。
真实的成本构成大概是这样，从大到小：
- 把流程写清楚：口径、阈值、输出格式、禁止动作，从人脑里挖出来写成文件
- 资料整理：把数据整理到它能读的状态，建目录、定命名、理清哪份数据在哪
- 流程改造：设计审批点，并让团队真的按流程走
- 持续维护：规则变了、平台政策变了、模板换了，都要跟着改
- 第三方数据：如果要接竞品数据、销量估算这类服务，多数单独收费
- 订阅和模型消耗
第一项通常是最大的一块，也是最没人预期到的一块。
但这里有个反直觉的地方：第一项的投入，就算你最后没用任何 AI 工具，也是有价值的。
写规则这件事本身就值钱
写 AGENTS.md 的过程里，多数团队会发现一件事：很多口径其实从来没定过。
同一个 ACoS，运营 A 算的是含广告外销售，运营 B 算的是只看广告订单；同一个「滞销」，有人说 30 天没动，有人说 60 天。平时没人对过，各写各的表，所以从来没暴露。
一旦要写成一份给机器执行的规则，就必须定下来。
所以这笔投入不该全部算在 AI 头上。它更像是「把运营流程标准化」的成本——你迟早要付的，只是 AI 这件事把它提前了，而且给了你一个必须做完的理由。
两个直接影响消耗的开关
推理强度
model_reasoning_effort 控制它想多深，直接影响耗时和消耗。
分法很实际：
- 需要判断的活调高：从几百条差评里归纳产品问题、判断某个类目值不值得进、从模糊的客户来信里判断真实诉求
- 整理类的活调低：按固定格式汇总数据、批量改文件格式、把表格转成报告
判断标准是：**这个活如果给一个新人做，他需要动脑子还是照着做？**需要动脑子的调高，照着做的调低。
如果某类任务经常要返工，先试着调高这一项，再考虑改规则——有时候不是规则不清楚，是它想得不够深。
子代理
每个子代理都在做自己的模型调用和工具调用，拆成 20 个分支不是把一份工作分成 20 份，而是跑了 20 份各自完整的工作。
判断划不划算有个简单标准：
- 值得拆的：单个分支的输入很大（每个竞品几百条评论），输出很小（一条结论）。这种情况拆开反而省，因为原文不进主上下文
- 不值得拆的：每个分支的活本来就很轻。拆的开销比省下的多
一句话：**如果某个子任务的原始材料不拆的话会占掉主上下文的很大一块，那就值得拆。**否则先别拆。
另外并发数要设上限，它直接等于同时在消耗的分支数。
判断值不值得，看三个数
不要看「每月花多少」，看这三个：
- 这件事一年重复多少次
- 每次省多少时间
- 错误率降了多少
第三个最容易被忽略，但在跨境场景里往往是最大的一块。一个漏掉的负毛利 SKU、一次错过的断货、一条写错参数的 Listing，代价可能比一整年的工具费用还高。
这三个数跑不出来，就说明还没到扩大投入的时候。所以前面几篇一直建议：先跑一个月，记四个数——原来多久、现在多久、错了几次、哪一步仍然必须人来判断。
什么时候本地模型值得用
Codex 的配置里内置了本地模型的服务商 ID（ollama、lmstudio），也就是说跑本地模型是官方支持的一条路径，不用自己拼配置。
三种情况下它值得考虑。
数据敏感
客户名单、财务表格、供应商合同、带个人信息的客服记录——这类数据你本来就不想传出去。
用本地模型的话，整条链路不出本机。这不是「更省钱」的问题，是「能不能做」的问题。
网络或账号受限
前面讲过，OpenAI 对可用的国家和地区有名单限制。如果这一层过不去，本地模型是不依赖外部账号的一条路。
量大而简单的活
有些活量很大但规则很死：批量改格式、批量分类、批量抽字段。这类活对模型能力要求不高，用本地模型跑可以显著降低消耗。
本地模型的代价要说清楚
不能只讲好处。本地模型和云端的差距是真实存在的，主要在三处：
- 多步任务的规划能力：需要它自己拆解步骤、中途调整的活，差距最明显
- 长上下文的处理：材料一多就容易丢信息
- 工具调用的准确度：该调用哪个工具、参数怎么填，出错率更高
还有一层现实成本：本地模型要占机器资源，跑起来的时候机器会明显变慢，这对一台还要干别的活的办公电脑是有影响的。
所以合理的用法不是全部本地化，而是分流。
按数据敏感度分流
分流可以直接落到目录上，这也是前面几篇一直在用的组织方式：
ops/
├── reports/ 常规报表分析 → 云端，只读
├── content/ 内容生成 → 云端，工作区可写
├── research/ 竞品调研 → 云端，开网络
└── sensitive/ 客服邮件、财务 → 本地模型，只读，不开网络
sensitive/ 目录的 .codex/config.toml 里指向本地服务商，其他目录用云端。
**进哪个目录干活，用的就是哪套配置。**你不用每次动手前想「这个数据能不能传出去」——目录已经替你做了这个判断。
这个设计的好处是它把一个需要每次判断的问题，变成了一个只需要判断一次的问题。而人在重复判断上是不可靠的，在建立一次规则上是可靠的。
一个务实的推进顺序
如果你现在要开始，建议这个顺序：
第一个月：挑一件只读的活（广告报表诊断或者库存盘点），手动导数据，用云端跑，把口径和规则写对。记那四个数。
第二个月：如果第一件确实有用，再加一到两件。这时候开始建目录结构，把权限按类型分开。
第三个月：把跑得最稳的那件改成定时任务。同时评估要不要接数据源省掉手动导出。
之后：涉及敏感数据的活单独走本地模型；量大的活考虑用子代理拆。
这个顺序的逻辑是：**先验证价值，再投入建设。**很多人反过来，一上来就搭一套完整体系，结果发现最核心的那件事其实用不上。
什么情况下应该放弃
也要说反面。有几种情况，不管工具多好都不该硬上：
- 这件事一年做不了几次：写规则的时间比自己做还长
- 规则写不出来：全靠经验和临场判断的活，硬套规则只会让输出更差
- 结果没法验证：做完你也不知道对不对，那自动化只是把不确定性放大了
- 没人维护：规则会过时，没人负责更新的话，半年后它按旧标准干活比不干还糟
最后一条最现实。**自动化不是一次性投入，是一个需要有人负责的东西。**如果团队里没人认领这件事，那不如不做。
下一步
最后一篇讲工具选型：Codex 和同类工具的差别到底在哪、按什么标准选、能不能混着用，以及整个系列的收尾。
