让 Codex 维护独立站数据，写操作要卡在沙箱边界上

先讲结论：读可以放开，写必须过流程

独立站的日常维护里，有一大堆又碎又必须做的活：改几十个商品的描述、查哪些 SKU 快断货、找出哪些商品因为改过运费实际在亏钱、补齐没写描述的页面。

这些事人做没有难度，只有量。正好是 Codex 的位置。

但这类场景和前面几篇有个本质区别：它是线上店，改错了直接影响成交。

分析类的活最坏结果是结论不对，你看一眼就发现了。改商品数据最坏结果是几百个商品的价格错了，而且客户立刻就能下单。

所以这一篇的重点不是「怎么让它改」，是「怎么让它改得可控」。

三条路，风险完全不同

导出、改完、再导回

后台导出 CSV → 放进本地目录 → Codex 读取、按规则修改、生成新的 CSV → 你自己在后台导入。

最安全，因为最后那一步是人做的，导入前后台通常还会让你确认一次。改错了也有原始文件可以对照回滚。

配置上用 workspace-write 就够，不需要任何网络权限：

sandbox_mode    = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false

缺点是慢，不适合需要频繁执行的任务。

建议：所有批量写操作，第一次都走这条路。

脚本直连接口

给它凭据，让它写脚本直接调后台接口改数据。

快，能自动化，但风险最高——脚本跑起来就是几百个商品同时变。

而且这条路需要开网络，等于同时具备「读工作区文件」和「往外发请求」两种能力。前面讲过，这个组合才是真正需要警惕的。

用这条路的前提是后面那四道流程都建起来了。少一道都不要开。

通过 MCP 连店铺数据

如果有对应的 MCP 服务，可以直接查询店铺数据。

这条路的边界不由你的沙箱决定，而由那个服务提供了哪些能力决定。所以选的时候要看清楚：只读的服务风险很低，带写能力的要单独评估。

原则还是那句：先接只读的。

先做这三件，收益最直接

找出快断货和滞销的 SKU

纯读操作，零风险，可以直接自动跑。

输入是商品和库存导出，加上一段时间的销量。产出是两张表：按当前销速算，多少天后断货；哪些 SKU 超过多少天没动销、占了多少库存金额。

这件事很多人靠感觉，实际一算经常会发现压货比想象中严重。

找出售价低于成本的商品

这一件最容易被忽略，也最容易出真金白银的问题。

促销改过价、运费规则调整过、汇率变了、成本涨了——任何一个都可能让某几个 SKU 变成卖一件亏一件，而后台不会提醒你。

做法是把商品导出（含售价）和你自己的成本表放一起，算出每个 SKU 的毛利，把毛利为负和低于阈值的挑出来。

跑第一遍的时候留点心理准备，多数店都能找出几个。

补齐缺失的页面描述

读操作为主，产出是草稿。

先扫出哪些商品页和集合页没写描述、或者写得过长被截断、或者几十个页面共用同一段。然后按商品资料批量生成草稿，输出成 CSV，你审一遍再导入。

注意是生成草稿，不是直接写回去。

这三件的共同点：**都只需要只读或者本地写，不需要碰线上。**先把这三件跑顺，你会对它的行为有基本判断，再考虑要不要往前走一步。

真要让它直接写，先建四道流程

第一道：预演

任何写操作，先跑一遍不落地的版本，把「将要改哪些商品、从什么改成什么」完整打印出来。

这一步是硬要求，不是可选项。预演清单没看过就执行的批量操作，出事只是时间问题。

写进规则文件：

执行任何批量写操作前，先输出完整的预演清单：
将要修改的商品、每个字段的原值和新值、影响的记录总数。
预演清单必须由人确认后才能执行实际修改。

第二道：限量

给单次操作设上限，比如一次最多改 50 个商品。超过就拆成多批，每批之间人确认一次。

这条能把「脚本写错」的损失从全店缩小到 50 个。

第三道：留原值

执行前把所有将被修改字段的原值存成一份文件。这就是你的回滚数据。

没有这份文件，回滚意味着从备份恢复整个店，代价完全不同。

第四道：分级审批

不是所有字段都一样危险：

价格和上下架不做自动，理由很简单：这两项错了，客户当场就能下单，撤不回来。

其他字段改错了你还有时间发现和修正，这两项没有。

沙箱在这里能帮什么，不能帮什么

Codex 的沙箱在这个场景里的作用要说清楚，别指望它兜住不该兜的。

能帮的：限制它能碰到哪些本地文件。工作区之外的东西它动不了，所以把工作区限定在只放导出文件的目录，本机其他数据是安全的。

不能帮的：一旦你给了它凭据、开了网络，它调接口改线上数据这件事，沙箱管不了。沙箱管的是本机的文件和网络开关，管不了「这次调用该不该发生」。

所以线上数据的安全完全依赖前面那四道流程，而不是沙箱。这一点必须清楚，否则容易产生一种虚假的安全感——「反正有沙箱」。

描述类内容也要人抽查

上面把页面描述归到了「预演后可批量执行」，但还是要人抽查。

原因不是怕它写错语法，是怕写得太像。批量生成最典型的问题是几十个商品的描述结构完全一致，只有商品名不同。这种东西对搜索没有帮助，还会让页面看起来像批量灌水。

抽查的办法很简单：随机挑十条连着读。如果读起来像同一个模板填了不同的空，就回去改规则——让它必须用到每个商品自己的参数和使用场景，而不是套一个句式。

这个问题在批量生成页面时会更严重，下一篇专门讲。

一个实际的目录组织

把前面的规则落到目录上：

ops/shop/
├── .codex/config.toml     workspace-write，不开网络
├── AGENTS.md              口径、阈值、禁止动作
├── data/
│   ├── products.csv       后台导出
│   ├── inventory.csv
│   ├── cost.csv           自己维护的成本表
│   └── sales-90d.csv
├── output/                生成的修改用 CSV
└── reports/               盘点和核查报告

输出的 CSV 有两条要求写进规则：

- 只包含需要修改的行，不要全量导出
- 保留原值列和新值列，两列并排，便于人工核对

第二条很实用。一份只有新值的 CSV，人是没法核对的；原值和新值并排放，一眼就能看出改动是否合理。

下一步

这一篇讲的是维护现有页面。下一篇讲一件更有诱惑也更危险的事：批量生成新页面，以及怎么让它不变成内容负债。

参考资料

• Agent approvals & security
• AGENTS.md
• Config basics