给编程 Agent 补上上线后的网站巡检

AI 编程工具能把网站做出来，却未必能判断它上线后是否可用。页面能渲染、构建通过、部署成功，都无法证明生产域名上的跳转、收录规则、表单和移动端体验没有问题。

Webskan 这篇文章提出的办法，是给 Agent 补上部署后的外部审计：扫描真实网站，把问题交给 Agent 修改，再部署复查。值得借鉴的是这套反馈流程；至于工具效果，原文更多是产品说明，没有提供对照实验。

为什么构建全绿，网站仍然会出问题

Agent 通常围绕任务里的验收条件工作：页面做完了，构建通过了，部署平台也报成功。如果验收停在这里，生产环境中的缺陷就容易漏过去。

第一类是代码合法、内容却不合格。例如页面还挂着「Create Next App」「Vite + React」「My Astro Site」，或者全站共用一个 title 和 description。把 /pricing 改为 /plans 后，导航更新了，页脚、FAQ 和博客里的旧链接仍然返回 404，构建也不会因此失败。

第二类取决于部署配置。预览环境需要的 noindex 或阻断性 robots.txt 被带到生产，网站能打开，却可能无法被搜索引擎正常收录。CDN 后的真实响应，也可能缺少 Content-Security-Policy、Strict-Transport-Security、X-Content-Type-Options、Referrer-Policy、Permissions-Policy 等安全响应头。

域名还有另一层问题：www 和裸域同时返回 200，*.pages.dev、*.vercel.app 又能被索引，可能造成重复内容和信号分散；未配置完整的域名变体还可能出现证书警告。

第三类需要实际操作或测量。输入框没有 label，提交按钮用 div 模拟，联系表单请求了只在本地存在的接口，都可能藏在一个漂亮页面里。性能同样如此：原文举的是 4 MB 首屏大图、字体重复加载四次，以及已删除组件遗留的第三方脚本。在中端手机和 4G 网络下，最大内容绘制可能拖到四秒以后。这些是问题示例，不是作者公布的测试样本。

构建通过，只验证了交付链路中的一部分。

Webskan 怎样让审计结果进入修复流程

Webskan 提供远程 Model Context Protocol（MCP）服务，让 Agent 调用外部检查工具。作者称审计过程是确定性的、只读的，内部没有语言模型；发现问题靠检查程序，理解和修改问题由调用方 Agent 完成。

四个工具负责不同环节：

• scan_website 检查单页的 HTTPS、跳转、安全响应头、服务端版本泄露和移动端 Lighthouse，约 30 秒。
• audit_website 最多审计 30 页，通常耗时 1–5 分钟，覆盖内外链、逐页 SEO、移动端与桌面端 Lighthouse、基于 axe 的 WCAG 检查、TLS、robots、sitemap，以及菜单、搜索、表单和 404 页面等用户路径。
• get_audit 获取结果，可以按严重程度过滤。
• recheck_website 重新审计，返回已修复、仍存在、新出现的问题差异。

原文称它支持超过 60 类发现，并附具体修复建议；无障碍结果还带 CSS selector，方便 Agent 定位元素。

下面这条命令把远程服务加入 Claude Code：

claude mcp add --transport http webskan https://webskan.com/mcp

要留意 --transport http，这里连接的是远程服务。Cursor、Windsurf 等客户端使用标准 mcpServers 配置，其中 webskan.url 指向同一地址；Codex 则在 ~/.codex/config.toml 中配置 [mcp_servers.webskan] 和 url。原文还提到 VS Code 配置、Claude Code plugin，以及用 curl 直接调用 JSON-RPC 的示例，但没有给出这些内容的具体写法。

接入后，任务可以写成：审计生产网站，修复仓库中所有 high 和 medium 问题，部署后复查，再列出未解决项。

下面的结果展示了 Agent 能直接处理的问题结构：

{
  "id": "seo.title.duplicate",
  "severity": "medium",
  "title": "Same <title> on 6 pages",
  "area": "seo",
  "detail": "“Example – Home” – search engines cannot tell which page to show. Give every page its own title.",
  "pages": ["/", "/pricing", "/about", "/blog", "/blog/hello", "/contact"]
}

关键是 id 和 pages：前者用于识别问题类型，后者列出受影响页面。不过，这只是缩短后的结果示例，原文没有展示完整报告或一次真实修复的前后记录。

复查能不能证明问题已经解决

作者强调，要审计生产 URL。预览域名与正式域名的响应头、跳转和 robots 规则可能不同，检查 *.vercel.app 无法替代检查正式站点。

修复也应落到共同原因上。六个页面标题相同，可能是共享模板的问题；40 处链接还指向 /pricing，作者建议通过一条重定向规则处理。执行时仍应确认目标地址和迁移意图，避免为了消除告警而随意跳转。

复查设计里，有两个处理值得肯定。Lighthouse 分数存在运行波动，所以分数变化单独报告，不会仅凭它判断问题「已修复」或「新出现」。如果某页在复查时抓取失败，对应发现会标为「could not verify」，而非已修复。

但稳定的 ID 只能帮助追踪，不能独自保证比较完整。不同页面上的同类问题如何区分、抓取范围变化如何影响差异，原文没有展开。

免费额度也影响这套流程：每个 IP 每天可做 2 次全站审计，每个 host 每天 1 次，同 host 重复调用会返回已有报告；快速扫描每小时 10 次。**原文没有说清 recheck_website 是否单独计费或计入额度，以及同日如何获得更新后的全站结果。**使用免费计划前，这一点需要确认。

我的判断

我认同把生产环境审计加入 AI 编程流程。它把「上线后再看看」变成了明确步骤，也让 Agent 得到可以继续行动的反馈。

Webskan 的价值在于整合。Lighthouse、axe-core、linkinator 和安全响应头检查器本来就能完成各自的任务；统一爬取、结构化输出和修复后比较，可以减少人工搬运结果。已有这些检查的团队，未必需要换工具，也可以沿用现有流程组织反馈。

不过，原文来自 Webskan 自家博客，没有误报率、修复成功率或与独立工具的对照数据。「首次通常出现少量 medium 和更多 low」属于作者经验，不能据此判断你的网站质量。

自动检查也有覆盖边界。工具声称检查表单和用户路径，但没有说明是否验证邮件送达、搜索结果正确等业务结果。无障碍部分列出了 alt、标题层级、键盘操作，以及低于 4.5:1 的对比度问题；这些发现不能直接充当合规证明。作者提到 European Accessibility Act 自 2025 年 6 月起适用于商店和预订网站，但没有展开适用条件。

服务只接受公开网站，拒绝私有 host、localhost 和受限 IP 范围。它保存审计地址与结果 30 天，快速扫描保存 7 天，客户端 IP 的单向哈希保存 24 小时用于限流。原文另有 $69 的深度审计，交付 PDF、修复优先级和修复后复查，不能把这项服务与免费 MCP 的额度混为一谈。

能拿来做什么

• 给 AI 编程任务增加明确的上线验收：检查正式域名上的 metadata、robots、跳转、响应头和主要交互，修复部署后再复查，并保留未验证项。
• 前端重构路由或页面模板后，重点检查旧链接和逐页 SEO。发现多个页面重复报错时，先查共享布局、metadata 生成逻辑和迁移规则。
• 把自动审计与人工业务验收配合使用。表单仍需确认最终提交结果，移动端菜单仍需检查键盘操作，Lighthouse 分数则应结合具体问题阅读。
• 小型公开站点可以先验证免费服务是否覆盖自己的页面和复查频率；已有 Lighthouse、axe-core、linkinator 的团队，可以先让 Agent 消费现有结果，再决定是否引入远程 MCP。