现在让AI写一个网页，它经常直接给你一个HTML文件。CSS写在 <style> 里，JS写在 <script> 里，所有东西都塞在一个文件里。
很多人一看，就说：以前学HTML，老师总讲要把CSS和JS拆出去，现在AI时代不一样了，单文件才是主流。
这个说法，对了一半。
对的一半是：AI确实更爱生成单文件。
不对的一半是：这不等于单文件在运行时更优，也不等于传统拆分架构过时了。
真正要分清楚的是两件事：
单文件HTML，是AI生成时的默认格式，不是Web运行时的默认架构。
一、AI为什么爱生成单文件？
不是因为单文件一定传输更快、打开更快，而是因为AI写起来更顺。
大语言模型是在一个上下文里生成内容的。如果它要同时写三个文件：index.html、style.css、app.js，它就得记住：
- HTML里用了哪些类名；
- CSS里定义了哪些选择器；
- JS里绑定了哪些元素和函数；
- 它们之间有没有对得上。
文件一多，AI就容易“忘了前面写过什么”。改一处，可能漏掉另一处。
单文件把这些东西放在同一个视野里，AI不用来回翻文件，生成、修改、复制、分享都更省事。你让AI生成一个小工具，它直接给你一个HTML，你双击就能打开，不用配环境，不用装依赖，也不用管文件路径。
所以，单文件在AI时代流行，核心原因是：它降低了生成和交付的摩擦。
但这只是生成侧的优势。
二、生成方便，不等于运行更优
以前把CSS和JS拆开，不是为了好看，而是有实际好处。
比如缓存。浏览器可以把CSS和JS文件长期缓存起来。你下次打开同一个页面，如果HTML变了，但CSS和JS没变，浏览器只用重新下载那一小段HTML，CSS和JS直接从缓存里拿。
单文件就不一样了。所有东西捆在一起，HTML文档本身通常不会像独立JS、CSS那样被长期缓存。结果就是：你每次打开，可能都要重新下载整个文件。
文件小的时候，感觉不明显。
文件一大，里面塞了图表库、编辑器、大量样式和逻辑，问题就来了：第一次打开慢，重复打开也慢。
你可能会说：那用懒加载不就行了？
懒加载能缓解“第一次打开太大”的问题，但它解决不了“缓存粒度”的问题。拆开的资源可以只更新变化的部分，单文件往往只能整个重来。
除了缓存，拆分还有这些好处：
- 多人协作时，各改各的文件，冲突少；
- 代码审查时，diff清楚；
- 增量更新时，不用每次动整个页面；
- 长期维护时，结构更清楚。
单文件把这些都压扁了。它把复杂度从“文件之间的关系”，转移到了“一个文件内部的组织”。文件小的时候，这是好事；文件大了，复杂度还会回来。
三、到底该用单文件还是拆分？
不要一刀切。关键看这个页面是什么。
适合单文件的场景：
- 一次性工具，用完就关；
- 原型、小demo、教学示例；
- 低频使用的小页面；
- 需要离线分发，发给别人双击就能打开；
- AI直接生成的小工具、小页面。
这些场景里，单文件非常合理。生成快，分享快，打开快，没有部署负担。
更适合拆分或混合的场景：
- 用户高频访问的页面；
- 包含大型依赖，比如图表库、富文本编辑器；
- 需要长期维护的产品页面；
- 多人协作开发；
- 需要精细缓存、增量更新、代码审查的项目。
这些场景里，传统拆分架构的优势并没有消失。AI能生成单文件，不代表产品就该用单文件上线。
四、中间路线：单文件结构 + 外链依赖
还有一个容易被忽略的办法：单文件不一定非要“把所有东西都内联”。
你可以让AI生成一个HTML文件，但大型依赖仍然通过CDN引入。比如样式框架、轻量JS库，用外链加载。这样既保持了单文件的结构简单，又避免把几MB的库塞进HTML里。
另一个办法是：AI先生成单文件，部署时再拆成多文件，或者走构建流程。
也就是说，单文件可以是起点，不必是终点。
五、真正要分开看的，是两个问题
第一个问题：怎么让AI写得顺、改得快、分享方便？
答案常常是：单文件。
第二个问题：怎么让浏览器加载快、缓存好、维护稳？
答案要看场景。很多时候，拆分仍然更好。
我们容易犯的错，是把生成侧的最优解，当成运行侧的最优解。AI爱生成单文件，是因为它在一个上下文里工作更自洽。但浏览器和用户不关心AI怎么写，它们关心的是加载、缓存、更新和维护。
结论
单文件HTML是AI时代的默认格式，但不是Web的默认架构。
以前老师讲CSS和JS要分开，讲的是运行时架构。现在AI爱生成单文件，变的是生成工作流。两者不是替代关系，而是不同阶段的选择。
小工具、原型、一次性页面，用单文件，没问题。
产品页面、长期维护、多人协作、高频访问，别因为AI爱生成单文件，就放弃拆分。
判断标准其实很简单：
这个工具会被用几次？
用一次，单文件很香。
用很多次，就要认真想想缓存、维护和架构了。
AI给的是一个起点，不是终点。