接手旧站或准备投流，不必再拿着清单逐页翻查。现在可以让 AI 按转化闭环、投流承接、SEO 基础和移动端体验自动采证、评分，并告诉你先修什么。
前几天看到一段很有共鸣的视频。
一个运营刚从广告投放转到独立站，接手前同事留下的网站。打开后台以后，她马上遇到三个问题：
哪里不合格？应该从哪里改？怎么避免改少了没效果、改多了又把网站改崩？
这是接手旧站时最常见的困境。
很多人第一反应是换主题、改配色、重做首页。可独立站是否合格，首先看的不是颜值，而是它能不能把流量顺畅地变成订单。
网站再漂亮，如果付款链路卡住、广告落地页对不上、手机端找不到购买按钮，投进去的流量还是会白白流失。
一套有效的检查顺序
视频里给出了一套很实用的四步排查法。
第一步是转化闭环。
拿手机模拟一次真实购买，从商品页、加购、填写信息一直走到付款页。重点看购买按钮是否明显、能否访客结账、支付方式是否齐全，以及中途有没有报错或异常跳转。
第二步是投流承接。
检查移动端打开速度，广告里的商品、优惠和最终落地页是否一致，首屏能不能看到对应商品，页面有没有评价、物流和退换承诺，以及用户放弃结账后是否有基础挽回机制。
第三步是 SEO 基础。
检查核心页面的 Title、Meta Description、图片 Alt、Sitemap 和 Search Console。它们不一定马上带来订单，却决定了网站以后积累自然流量时，是从零开始补课，还是已经有一个合格起点。
第四步是移动端和基础体验。
检查错位、溢出、遮挡、破图、死链，以及 Shipping Policy、Refund Policy、Contact 等基础页面是否齐全。
转化 35、投流 30、SEO 20、移动端 15
这个顺序的价值在于：先修最影响收入的问题，再处理流量积累，最后才轮到视觉优化。
但真正执行时，新的问题又出现了。
页面要一张张打开，购物流程要一步步模拟，SEO 标签要逐个查看，后台状态还分散在 Shopify、Google Ads 和 Search Console 里。每次改完以后，还要重新跑一遍。
如果完全依赖人工，不但耗时，也很容易漏项。
所以，我把这套独立站合格标准做成了一个 Skill：`audit-dtc-store。
不再手动一项项查
现在只需要给出站点地址，Skill 会先完成公开页面的只读诊断。
它会自动收集首页、商品页、购物车、站点地图和政策页等公开证据，检查页面是否可访问，以及 Title、Meta Description、Canonical、图片 Alt、Product 结构化数据等基础项。
需要模拟真实用户操作时，它会继续使用浏览器检查手机端布局、加购入口、Guest Checkout、付款链路和主流支付方式，但会在填写联系方式、地址和付款资料之前停止。
也就是说，它能验证“购买通道是否走得通”，但不会替用户创建账户，更不会提交真实订单。
过去是拿着清单逐项打勾。
现在是发起一次诊断，由 Skill 自动采证、归类并生成报告。运营人员把时间留给判断和整改，而不是反复复制 URL、翻找设置和整理表格。
自动化不等于乱下结论
站点诊断最怕的，不是少查一项，而是把没有证据的事情说成已经通过或已经失败。
所以这个 Skill 不只输出一个总分，还会同时给出：
已验证评分；
检测覆盖率；
严格下限和潜在上限；
P0、P1、P2 问题；
尚未验证的项目和补证方法。
转化闭环、投流承接、SEO 基础和移动端体验的权重分别是 35、30、20、15。只要存在一个 P0 问题，例如无法结账、支付缺失或关键购买流程不可用，就不能判定站点合格。
如果覆盖率低于 70%，报告只会给出“部分诊断”。公开页面无法证明的项目会被标记为 `unknown，而不是把“没查到”直接当成失败。
Core Web Vitals 也一样。
普通网络响应、Lighthouse 实验室数据和真实用户字段数据是三类不同证据。这个 Skill 不会拿一次网页响应时间冒充 LCP，也不会因为 PageSpeed API 返回 429，就编造一个性能结论。
必要后台，也可以授权核验
有些问题只看公开页面无法确认。
例如：
Google Ads 当前使用的最终 URL，是否真的落到了正确商品和优惠；
Shopify 的弃购邮件自动化，后台到底有没有启用；
Search Console 是否已经验证，Sitemap 是否提交，索引和 Core Web Vitals 当前是什么状态。
遇到这些项目，客户可以在自己的真实浏览器里亲自登录并完成 MFA，再授权 Agent 进行只读核验。
密码、验证码、Cookie 和访问令牌都不需要交给 Agent。登录授权也不等于修改授权：Skill 只查看状态，不启停自动化，不修改广告，也不提交站点配置。
如果要实际制造一条弃购记录或触发测试邮件，则必须另外逐项授权，并使用专用测试身份。这个动作不能伪装成“全程只读”。
这不是为了把流程变复杂，而是让每一个结论都有证据边界。
真正的优势，是可以反复重跑
完成这个skill的创建之后，我对服务的一个家居类独立站复测时，诊断指出广告落地页匹配和 Shipping Policy 的问题，而这2个问题我之前确实没有检查到。
网站完成修复后，再运行同一个 Skill，系统会重新读取当前页面和后台证据，更新检查状态和问题清单。已经修好的项目不再沿用旧结论，新的风险也不会被历史报告掩盖。
这比一次性的“网站体检表”更有价值。
因为独立站不是检查一次就永远合格。换主题、改商品、调整广告 URL、安装新应用，都可能重新影响购买链路和页面表现。
同一套标准可以用于：
接手旧站时摸清底数；
投流前判断网站能不能承接流量；
改版后检查关键功能有没有被改坏；
修复问题后重新验收；
向客户或团队交付一份可追溯的整改报告。
AI 并没有替运营负责人做最终商业判断。
它只是先接管了那些重复、耗时又容易遗漏的工作：打开页面、收集证据、核对标准、计算覆盖率、排列整改顺序。
运营真正需要做的，是看懂问题对收入的影响，并决定先修哪一个。
如何使用
这个 Skill 已经发布到 GitHub：
https://github.com/owensky-dev/audit-dtc-store
安装后，在 Codex 中输入：
使用 $audit-dtc-store 对 https://example.com 进行只读独立站合格标准诊断
需要补充后台证据时，可以继续说明：
```text
允许在我已登录的真实浏览器中，只读查看 Google Ads、Shopify 和 Search Console。
如果你正准备接手一个旧站，或者下一轮广告马上要上线，不妨先跑一次自动体检。
先确认网站能不能顺畅赚钱，再决定把多少预算投进去。
你在检查独立站时，最容易漏掉的是付款链路、广告落地页，还是后台自动化？欢迎留言聊聊。
拓展阅读:
[我把独立站增长周报做成了一个 Codex Skill，连接 GA4、GSC、Google Ads 和 Shopify](https://mp.weixin.qq.com/s?__biz=MzcwNDM3ODE1MQ==&mid=2247483660&idx=1&sn=c4f7896e8df7f889a7f78a9a69902e94&scene=21#wechat_redirect)
