独立站运营自动化：系统检查，人来决策

让系统每天、每周、每月自动检查，只把异常、缺少的数据和需要负责人确认的操作交给人。文末附一张可打印的 12 项自查表。

独立站运营最耗时间的，是每天反复打开同一批后台。

每天先看订单和支付，再看广告有没有烧偏；接着核对库存、发货、物流、投诉和退款。后台都看完，半天过去了，真正要处理的可能只有两三件。

更麻烦的是：后台没有出现明显红字，不代表业务真的正常。

有时数据还没更新，有时账号看不到完整信息，有时后台显示“已完成”，实际流程还没结束。比如 Shopify 显示已履约，不代表客户已经收到货；广告显示有转化，也要确认广告页面、转化记录和真实订单能不能对上。

所以我结合实际运营，重新整理成一套店铺运营框架：6-3-3 自动巡检。

为什么是 6-3-3

运营检查最常见的问题，是把每天、每周和每月的事项全塞进同一张表。

订单异常需要当天处理，网站备份不必每小时确认，续费和经营策略也不应该每天重做。频率混在一起，清单越长，真正紧急的事项反而越容易被淹没。

我的做法是按决策周期重新分组：

• 每天 6 项

：守住当天不能出错的地方；

• 每周 3 项

：判断经营系统有没有慢慢变差；

• 每月 3 项

：决定下个月应该调整什么。

这 12 项不是后台菜单的简单罗列。我把运营问题归成 12 类，每一类都能找到负责人、处理期限和核对依据。

每天 6 项：先守住收入和履约

1. 钱：销售、订单与支付

确认销售和订单是否出现异常波动，支付是否成功，是否存在高风险订单、失败交易或对账差异。

2. 站点：购买链路与活动价格

检查首页、商品页、购物车和结账入口是否可用；活动价、折扣和页面承诺是否一致。

3. 流量：广告与流量异常

看广告花了多少钱、带来多少点击和订单，重点找出那些长期花钱却没有真实购买的活动。

4. 风险：平台、支付与合规通知

集中查看 Shopify、广告平台、支付机构和物流平台的风险提醒。

5. 履约：库存、发货与物流

确认库存够不够、是否按时发货、包裹有没有超出预计送达时间。网站显示有货，不代表各个仓库都有库存；Shopify 显示已履约，也不代表客户已经收到货。

6. 客户：投诉、退款与评价

查看还没处理完的客服问题、退款申请、投诉和低分评价，重点看是否处理超时，以及有没有需要负责人马上介入的问题。

每周 3 项：看系统是不是在慢慢变差

7. 核心经营指标

把销售额、订单、转化率、客单价和广告效率放在同一时间范围内比较。周报只回答三件事：哪里变了、影响什么、下周怎么验证。

8. 客户运营与自动化流程

检查购物车未付款提醒、欢迎邮件、复购提醒等自动流程是否真的发出并送达。后台显示“已启用”，不代表每一步都在正常工作。

9. 网站健康与备份

检查关键页面、索引、站点地图、错误链接、网站速度和备份状态。公开网站、Search Console 和浏览器后台看到的内容不同，需要放在一起核对。

每月 3 项：决定下个月做什么

10. 经营复盘与策略

复盘渠道、商品、活动和利润表现，确认下个月继续什么、停止什么、验证什么。月度复盘必须落到负责人和时间，而不是停在“继续优化”。

11. 留存与复购

查看老客户贡献和复购间隔，判断哪些客户值得继续经营，哪些自动消息发了很多却没有带来订单。

12. 性能、订阅与续费

检查网站速度，以及域名、应用、支付工具、数据服务和关键账号是否快到期。关键服务突然过期、导致客户无法付款或下单，属于需要在 24 小时内处理的 P0 风险。

下面这张表可以直接保存或打印。它保留了状态、优先级、负责人、截止时间和证据栏，方便团队自查。

6-3-3 异常运营自查表

我把这套框架做成了一个 Skill

这里的 Skill，可以理解为一套能让 Codex 重复执行的操作流程。清单告诉它查什么，Skill 负责按步骤检查并整理结果。

我把它命名为 run-independent-store-ops。运行时只需说明检查周期和店铺，系统会读取现有文件、已经连接的数据源或客户登录后的后台页面，再生成异常报告。

项目与安装说明已经开源：

GitHub：https://github.com/owensky-dev/run-independent-store-ops-skill

数据怎么接进来：两条路径

自动化能不能长期运行，关键是能否持续拿到数据，而且来源清楚、权限合规。

我通常把数据接入分成两条路径。

路径一：先安装四源增长报告 Skill

如果客户能提供合规的数据权限，建议先安装我另外一个开源 Skill：dtc-growth-data-report。

GitHub：https://github.com/owensky-dev/dtc-growth-data-report

它会把 GA4、Google Search Console、Google Ads 和 Shopify 的数据保存到本地，整理成统一格式，再生成周报和老板看板。

安装后，可以在新的 Codex 任务中输入：

使用 $dtc-growth-data-report 接入 GA4、GSC、Google Ads 和 Shopify，并生成老板周报。

这条路径适合长期使用：每周都能重新拉取数据，时间范围和计算方法也保持一致。四个平台的数据必须全部更新成功，才能生成完整周报；少一个，就直接提示数据不全，不会用旧数据凑结果。

安装 Skill 不等于自动获得账号权限。客户需要在自己的电脑上完成账号授权并保管好密钥，不要把密钥发到对话里，也不要放进截图或公开仓库。

路径二：让 Codex 在已登录后台里只读采集

如果客户暂时拿不到 API 或管理员权限，但本人拥有 Shopify、Google Ads、GA4 或 Search Console 的合法只读访问权限，可以先在自己的浏览器里打开后台，由客户自己完成账号登录。

登录完成后，再告诉 Codex：

允许在我已登录的浏览器中，只读查看 Shopify、Google Ads、GA4 和 Search Console。
只读取本次报告需要的数据，不修改设置、不提交表单、不保存登录信息；看不到的项目标记为未知。

Codex 可以打开相关报表，把页面上能看到的数据整理成本地文件。这适合第一次试用、临时检查或补充少量数据。

登录可能失效，后台页面也会变化，所以这种方式适合半自动检查，不适合长期无人值守。Codex 只查看客户明确授权的账号和页面。

两种方式可以配合使用：平时用 dtc-growth-data-report 稳定取数，缺少的数据再从已登录后台补充，最后交给 run-independent-store-ops 判断哪些正常、哪些异常、哪些需要负责人确认。

准备好当前证据后，在 Codex 中可以这样发起运营巡检：

使用 $run-independent-store-ops 运行今日店铺运营检查，只报告异常、缺少的数据和需要负责人确认的操作。

它会先把杂乱的数据整理成四类结果：

1. 这条数据来自哪里、是什么时间；
2. 当前是正常、异常、缺数据还是不适用；
3. 需要在 24 小时内（P0）、7 天内（P1）还是 30 天内（P2）处理；
4. 哪些操作需要负责人确认后才能执行。

最后交付的不是一堆后台截图，而是一份老板和负责人都能继续处理的异常清单。

“未知”比一个虚假的绿色勾更有价值

自动化运营最危险的做法，是把“没有读到数据”当成“没有问题”。

这个 Skill 的每个结论都要说明依据是什么：

• 有当前数据证明正常，才标记为正常；
• 有数据说明需要处理，才标记为异常；
• 数据缺失、过期或不够，就标记为未知；
• 店铺确实不适用，才标记为不适用，并写明原因。

报告还会告诉你本次检查覆盖了多少项目。只要关键数据还没拿到，就不能说整家店运行正常。

这能避免系统把“缺数据”误判成“没问题”。看到“未知”先补数据；看到“异常”再决定怎么处理。

自动化负责检查，人负责做决定

run-independent-store-ops 默认只读。

它可以建议暂停广告、调整预算、修正价格、补库存或联系客户，但不会直接操作后台。能查看账号，不代表可以修改；系统给出建议，也不代表负责人已经同意执行。

需要改变广告、价格、库存、订单、自动化或网站设置时，报告会把操作单独列出，等负责人确认后再执行。

这也是我理解的运营自动化：

机器负责反复打开页面、核对证据、识别异常和排列顺序；人负责判断影响、确认责任和批准动作。

它不是让 AI 接管店铺，而是把人从重复巡检里解放出来，把注意力留给真正会影响收入和客户的事情。

你可以先从一张表开始

如果暂时还没有接入数据，先用文中的 6-3-3 自查表跑一周。

每次只记四件事：现在是什么状态、依据是什么、谁负责、什么时候处理。一周后就能看出，哪些检查最费时间、哪些数据总是缺、哪些操作每次都要等确认。这些反复发生、规则明确的工作，最适合交给自动化。

清单让团队不漏项，Skill 让系统先筛异常，最终决定仍然留在人手里。

如果你负责独立站运营，可以把这张表保存下来。下次打开一排后台前，先把检查分成每天、每周和每月三类。很多不必天天做的动作，就能直接省掉。