AI 生成的单文件网页如何可靠交付

让 Claude、ChatGPT 或 Cursor 生成一个计算器、数据看板不难，难的是交给产品经理或客户后，对方真能打开、看懂、继续使用。作者整理了发送单文件 HTML 前的七类检查，核心结论是：生成页面只是第一步，依赖、运行环境和分享方式同样属于交付。

这份清单适合临时内部工具和数据报告。它的实用之处是把「我这里能跑」拆成了具体检查项；不过，后半部分明显围绕 dochost 展开，需要把通用建议与产品推荐分开看。

一个 HTML 文件，为什么还会缺东西

文件后缀是 .html，不代表它能独立运行。模型可能生成 <img src="chart.png">，也可能把样式放在 styles.css。这些文件留在作者电脑上，收件人拿到的就只是一个空壳。

作者用下面的命令，在发送前筛查常见的本地资源引用：

grep -nE '(src|href)="(\./|\.\./|[a-zA-Z0-9_-]+\.(png|jpg|svg|css|js))' report.html

注意正则中的扩展名列表：它覆盖了部分常见写法，并不是完整的依赖检查器。没有匹配结果，也不能证明页面完全独立。

发现引用后，可以把资源嵌入 HTML，或改为自己控制的绝对 HTTPS URL。两者有区别：后者解决了路径问题，却仍然需要网络。小图片可以转为 data URI，原文给出的命令是 printf 'data:image/png;base64,%s' "$(base64 -w0 logo.png)"；SVG 图标则直接内联 <svg>，避免再包一层 base64。

CSS 和 JavaScript 也要收进 <style>、<script>。给模型的需求应提前写清楚：只返回一个 HTML，内联全部样式和脚本，不需要构建步骤，不导入本地文件。

外部依赖同样要盘点。Chart.js、Tailwind Play CDN、D3 看起来已经「写进页面」，实际仍靠 CDN 下载。作者建议锁定 chart.js@4.4.1，不要使用 chart.js@latest，避免日后升级改变已发送报告的行为。import x from "lodash" 这种裸模块名也不能直接照搬到普通浏览器页面，应改用完整 URL 或移除依赖。

单文件交付的关键，是让依赖变得明确。

能在浏览器打开，不代表能在对方环境运行

企业 Wiki 和文件查看器可能把 HTML 放进受限的 iframe，或使用严格的内容安全策略（CSP）。这类规则决定页面能执行哪些脚本、加载哪些资源，不由 HTML 作者单方面控制。

作者建议使用 addEventListener 绑定事件，避开内联 onclick=""，并减少对 eval、远程字体和内部接口的依赖。但这不是通行证：如果宿主连内联 <script> 都禁止，换了事件绑定方式也无济于事。

对于一次性报告，作者倾向于把数据写成 const DATA = {...}，直接嵌入文件，不再通过 fetch() 请求内部 API。这样读者不必连 VPN，报告也不会因为接口变化而变样。代价是数据停留在生成时刻，需要更新时重新制作。

发布前还要搜索 key、token、Bearer，检查密钥、令牌和内部 URL。模型可能把提示词里的真实凭证一起写进产物。不过，关键词搜索只能辅助检查；数据快照里包含什么，也需要人工确认。

离线退路也值得提前设计。作者提到 <noscript> 和图表下方的普通 HTML 表格，这里要补一个边界：<noscript> 用于脚本被禁用等情况，不能普遍兜住 CDN 加载失败。对于数据报告，直接保留可阅读的表格更可靠。

分享链接之前，先处理手机、体积和更新

桌面上漂亮的页面，到了手机上可能只剩横向溢出。作者要求补上这个基础标签：

<meta name="viewport" content="width=device-width, initial-scale=1">

注意 width=device-width，它让布局视口适配设备宽度，但不会自动修复固定宽度的图表。仍需在 Chrome DevTools 中按 375px 检查：宽表格是否有 overflow-x: auto，图表容器是否写死像素，提示信息是否只能靠 hover 触发。

发送方式也会影响结果。作者指出，邮件网关可能拦截或隔离 .html 附件，手机也可能直接下载文件。因此，他更倾向于发送 URL。

原文列出的选项包括单文件托管、Netlify Drop、GitHub Pages 和邮件变通方案。对于长期运行、带后端的应用，作者建议正常部署；对于本周只给少量读者使用的页面，他选择 dochost。按原文描述，它支持直接提交 HTML 或 Markdown，无须账户即可获得链接，也提供可接入 Claude Code、Cursor、Codex 的 MCP server，让助手执行发布。

体积和后续修订则容易被忽略。作者举例，四张截图就可能让看板超过 1 MB，所以应压缩 PNG、优先使用 SVG、去掉闲置字体，并检查托管平台的免费额度。原文没有给出各平台的具体上限。

更新时最好保留原 URL，避免 Slack 中同时流传多个版本。原文称 dochost 的匿名页面会附带私密编辑链接，可以修改内容并保持分享地址；这个编辑链接需要妥善保存。

我的判断

这份清单最有价值的地方，是把临时 HTML 当作需要验收的交付物。对计算器、静态报告、小范围演示来说，内联资源、固定依赖和内嵌快照，确实能减少环境问题。

但原文没有提供故障率、平台对照测试，或「检查十分钟能节省多少沟通」的数据。它是作者的经验清单，不能当作经过验证的通用收益结论。

托管部分也有明显前提。链接容易打开，不等于访问权限合适；原文没说清访问控制、数据保存规则等问题。含内部数据的报告，应先确认这些条件。已有 GitHub Pages 或部署流程的团队，也未必需要另找服务。

单文件适合边界清楚的临时产物，长期应用仍需要持续维护的工程流程。

能拿来做什么

• 下次让 AI 生成临时计算器或报告时，把单文件、内联资源、依赖版本和禁止写入凭证直接列入需求，减少生成后的返工。
• 发送数据看板前，同时检查断网可读性和 375px 布局，确保图表失效时仍有表格，触屏上也能获取必要信息。
• 把本地资源扫描、凭证检查、文件体积和原址更新能力纳入交付清单，并在发布前确认托管环境是否允许页面执行脚本。