用自动检查为AI网站修改建立安全边界

AI可以在很短时间内修改大量页面，但速度越快，越容易把一个局部要求扩散到全站。标题重复、内链失效、Schema日期错误、移动端表格溢出，往往不会阻止开发者看到一个“能打开”的页面，却会在正式发布后影响用户和搜索平台。

我们最近一周的做法，是把发布检查从最后的人工提醒，变成正式上线前必须通过的质量门槛。AI可以负责修改和修复，但不能自行降低这些门槛。

先把要求拆成可以验证的事实

“把页面优化好”无法直接测试。更可执行的写法是：第16、17篇不能存在页面或Sitemap记录；新增文章必须使用指定URL；作者实体复用现有页面；内链在新标签页打开；详情页只显示一个有价值的时间。

每条要求都应该能够对应一种证据：页面文本、路由状态、HTML属性、JSON-LD字段、Sitemap记录或构建日志。无法验证的形容词可以继续用于设计方向，但不能成为唯一验收标准。

同时要把禁止事项写进检查，例如不得编造案例和效果、不得重复渲染Markdown一级标题、不得新增专题入口。负向边界如果只留在对话里，很容易在后续修改中丢失。

构建成功只是第一层

正式发布前至少需要经过内容编译、代码规范、自动测试和静态站点检查。内容编译确保Frontmatter和正文可以进入统一数据结构；代码规范帮助发现明显实现问题；自动测试验证关键业务规则；静态检查则遍历生成后的HTML，寻找断链、缺失资源和SEO异常。

这些检查不能互相替代。页面能生成，不代表Canonical正确；测试通过，不代表图片在移动端没有溢出；没有断链，也不代表作者和来源被正确展示。

在最近一次发布中，完整检查覆盖了56项自动测试和299个静态HTML页面。这里重要的不是数字本身，而是检查范围随新增内容一起扩大，避免新文章只被当作几份Markdown文件处理。

把SEO字段当作页面功能验证

Title、Description、Canonical、robots、Open Graph和Article Schema都属于正式页面的一部分。新增文章需要验证Canonical唯一且指向最终URL，Schema中的标题、作者、图片和日期与页面事实一致，作者`@id`复用官网现有实体，Sitemap包含正式地址但不包含已取消页面。

内链也不能只检查“链接存在”。需要确认它指向最终路由、锚文本表达上下文，并符合网站已经确认的新窗口打开规则。涉及外部来源时，还要保留安全的`rel`属性。

把这些内容写成自动断言，比上线后逐页查看源代码更稳定，也更适合持续更新的网站。

关键失败要真正阻断发布

如果构建失败、出现站内断链、Schema无法解析，或某个被明确取消的URL重新出现，流程应立即停止，不覆盖线上版本。修复之后要重新运行完整检查，而不是只重跑刚才失败的一步。

并非所有警告都需要阻断发布。已有项目可能存在历史代码提示，但流程必须区分旧警告与本次新增问题，不能因为“以前就有警告”而放过新错误。可接受警告、必须修复错误和人工复核项应该提前定义。

搜索平台通知失败则要根据风险单独处理：如果网站本身已经正确上线，可以保留线上版本并重试通知；如果Sitemap生成错误，则仍属于发布内容不完整，应先停止。

上线后仍需核验真实页面

自动检查通过以后，还要核验正式域名的HTTP状态、标题、Canonical、Schema、Sitemap和关键入口。CDN缓存可能让本地构建与用户实际看到的版本不同，线上核验可以确认发布链路最后一段没有失效。

AI建设网站真正需要的不是更慢，而是一条不会因为速度而省略证据的工作流。把安全边界固化以后，团队可以让AI承担更多重复修改，同时把最终是否上线的判断留在一套稳定、可复查的标准里。

请根据下面的网站修改任务，为正式发布设计一套自动质量门槛。

任务要求：［填写］
新增或修改页面：［填写］
不能改变的内容与事实：［填写］
SEO与结构化数据要求：［填写］
部署方式：［填写］

请输出：
1. 内容事实与页面结构检查
2. 路由、内链、404和重定向检查
3. Title、Description、Canonical、robots和Schema检查
4. Sitemap与搜索平台通知检查
5. 桌面端和移动端的关键验收项
6. 哪些失败必须停止覆盖线上版本
7. 可接受警告与必须修复错误的边界
8. 上线后的最小核验清单

不要因为旧项目已有警告就忽略本次新增错误，也不要用“构建成功”代替页面和SEO验证。