把 AI 生成的 HTML 发布到 WordPress，真正容易出错的地方不是“粘贴代码”这一步，而是边界没有处理清楚：生成器给的是完整网页，WordPress 需要的是正文片段；预览看起来正常，发布后却可能被主题 CSS、用户权限、缓存或资源路径改变。稳妥做法是把流程拆成六个门：生成、截取、清理、隔离、验证、发布后复查。任何一门没有通过，都先停在草稿或预览状态。
目录
先判断：你手里的是完整网页，还是正文片段？
可以先用 AI HTML 生成器 根据需求生成第一版结构，但不要把生成结果直接等同于可发布内容。先看代码里是否包含 <!doctype html>、<html>、<head> 和 <body>。如果有，它是一个完整文档；WordPress 文章正文通常只需要 <body> 内部的片段。
把第二套 <html>、<head> 或 <body> 塞进文章内容，会形成嵌套文档。浏览器可能尝试纠正它，所以“能显示”不代表结构正确；主题、编辑器和缓存插件再次处理后，结果也可能变化。
<!-- 适合粘贴到文章正文的片段 -->
<section class=‘article-demo‘>
<h2>代理连接状态</h2>
<p>先检测出口 IP，再开始自动化任务。</p>
<a href=‘https://example.com/check‘>运行检查</a>
</section>如果需要程序化提取正文，可以用浏览器原生解析器读取 body.innerHTML。但要牢记：解析只负责建立 DOM，不负责安全清理。
function extractBodyFragment(fullDocument) {
const parsed = new DOMParser().parseFromString(fullDocument, ‘text/html‘);
return parsed.body.innerHTML;
}
const fragment = extractBodyFragment(aiOutput);发布前必须处理的五类风险
| 风险 | 常见表现 | 处理原则 |
|---|---|---|
| 脚本与事件 | <script>、onclick、onerror |
默认删除；确有交互需求时改成经过审核的主题或插件代码 |
| 全局样式 | body、p、.button 等宽泛选择器 |
所有规则限制在文章专属包装器下 |
| 外部资源 | 相对图片路径、本地字体、第三方 CDN | 改成受控的 HTTPS 地址，并核对授权、可用性与尺寸 |
| 表单与嵌入 | 登录框、上传框、iframe、远程表单 action | 文章内默认移除；需要时使用站点批准的块或插件 |
| 无障碍结构 | 跳级标题、无 alt 图片、只有颜色的状态提示 | 补齐语义、替代文本和可理解的状态文案 |
最危险的误区是用一条正则表达式“清理所有 HTML”。正则可以辅助查找明显模式，却不能可靠理解浏览器如何修复畸形标签、属性引号、嵌套节点和编码实体。对于来自用户、外部 API 或未知模型的内容，应在可信服务端使用明确的允许列表；在 WordPress 插件开发里，可用核心提供的 KSES 系列函数按允许标签过滤，同时还要单独完成权限、Nonce、来源和输出转义检查。
WordPress 的 Custom HTML 官方文档明确说明：不同用户能力会影响 HTML 的保存结果，缺少相应能力的用户可能遇到 script、iframe 等不允许标记被过滤。因此，同一段代码用管理员预览正常，不代表交给编辑或投稿者保存后仍完全相同。发布流程必须用实际发布账号做一次草稿回读。
CSS 要隔离，不要和主题抢控制权
AI 生成器很容易输出整页 CSS，例如直接设置 body 背景、重置所有链接，或者覆盖站点已有的 .container、.card、.button。这些名称在主题和插件里出现频率很高。最小风险做法是给文章模块一个独特包装器，再把每条规则限定在这个包装器内部。
<div class=‘shluqu-html-demo‘>
<div class=‘demo-card‘>
<h3>HTML 发布检查</h3>
<p>结构、链接、移动端和缓存都通过后再发布。</p>
</div>
</div>
<style>
.shluqu-html-demo { max-width: 760px; margin: 1.5rem auto; }
.shluqu-html-demo .demo-card { padding: 1.25rem; border: 1px solid #d8dee9; }
.shluqu-html-demo .demo-card h3 { margin-top: 0; }
</style>如果站点会过滤 <style>，不要反复提高账号权限来绕过。把少量、稳定、经过审查的样式放进子主题或站点批准的自定义 CSS 区域；一次性演示才考虑受控的内联样式。任何方案都不要修改站点全局标签样式来迁就一篇文章。
把资源路径变成可发布资产
生成器预览中的 ./images/hero.png、/assets/app.css 或电脑上的本地文件路径，只在原环境里成立。发布前逐项处理：
- 图片上传到 WordPress 媒体库或站点批准的对象存储，替换为公开 HTTPS URL。
- 为内容图片写与画面对应的
alt；纯装饰图使用空替代文本，而不是堆关键词。 - 为大图提供合理尺寸，避免用 CSS 把超大原图硬缩成缩略图。
- 删除无法解释来源的字体、统计脚本、聊天部件和第三方追踪代码。
- 检查所有外链的协议、目标和跳转结果；新窗口链接补上
rel=‘noopener noreferrer‘。
如果代码包含 JavaScript 组件，不要假设文章编辑器是部署应用的地方。需要状态、网络请求或长期维护的交互，应封装为受版本控制的块、短代码或插件；文章正文只保留内容和调用入口。这样既能控制权限，也能避免缓存/压缩插件重排内联脚本。
用一份最小测试文档检查结构
WordPress 中最终粘贴的是片段，但验证工具通常更适合接收完整文档。可以临时用下面的外壳包住片段，然后提交到 W3C Nu HTML Checker。修正未闭合标签、重复 ID、错误嵌套和无效属性后，再移除测试外壳，只保留 <main> 内部内容。
<!doctype html>
<html lang=‘zh-CN‘>
<head>
<meta charset=‘utf-8‘>
<meta name=‘viewport‘ content=‘width=device-width,initial-scale=1‘>
<title>HTML 片段测试</title>
</head>
<body>
<main>
<!-- 把待发布片段放在这里 -->
</main>
</body>
</html>校验器通过也不等于 WordPress 验收完成：它检查的是 HTML 结构，不知道你的主题 CSS、用户权限、插件过滤规则、登录状态或缓存层。它是一个门，不是终点。
WordPress 中的安全发布顺序
- 新建草稿：先填写标题和固定链接，不覆盖已有文章。
- 插入自定义 HTML：只粘贴已经清理的正文片段，不带文档外壳。
- 保存并重新打开：比较保存前后的源代码，确认标签和属性是否被过滤。
- 桌面预览：检查标题层级、表格、代码块、链接、图片和长字符串是否溢出。
- 移动端预览：至少覆盖约 360px 手机宽度和 768px 平板宽度，特别留意表格与
<pre>。 - 公开页验证：发布后从未登录状态打开最终 URL，重新检查资源、外链、控制台错误与响应状态。
- 缓存复查：如果站点启用了页面缓存或 CDN，只清理目标文章相关缓存，再确认无缓存访问结果。
自动化发布也应遵守同样顺序。HTTP 接口返回“成功”只能证明请求被接受；还要从 WordPress 后端回读文章 ID、slug、分类、作者和特色图，再检查公开页面。遇到超时不要立刻重发，因为第一次请求可能已经创建文章；先按预期 slug 查询，避免重复发布。
一份可以直接执行的发布前清单
- 正文不包含第二套
html/head/body。 - 没有未经审核的
script、事件属性、iframe、表单或远程追踪代码。 - CSS 全部限制在唯一包装器下，没有覆盖主题全局选择器。
- 所有图片与资源使用可访问的 HTTPS 地址，不含本机路径或临时预览地址。
- 标题层级连续；图片 alt、链接文本、表格表头和键盘访问符合内容需要。
- HTML 结构检查无阻断错误；保存后源码与预期一致。
- 桌面、手机、未登录公开页都完成复查。
- 自动发布已回读文章、分类、作者和图片证据；超时先查重再重试。
这套流程的核心不是“让 AI 写出一次就完美的 HTML”，而是把生成结果当作待审代码：先把文档边界切对，再用允许列表和权限规则控制风险，用命名空间减少样式冲突，最后以真实 WordPress 保存结果和公开页面为准。这样，AI 负责提速，人和发布系统负责定义可接受边界。