宝贝入怀前两天接了个急活，朋友公司要做内部活动报名页，设计稿只有一张图，页面不算复杂，但不能用各种框架打包，因为要嵌在现有的CMS模板里。搁以前，这种原生HTML页面我一个下午写完，还得花时间处理各种浏览器兼容。今天我想换个方式——让AI来写，看它能不能在30分钟内搞定。结果它不仅搞定了，还给我留了一堆可以继续讲的东西。本文就还原一下这个过程，聊聊AI生成原生页面时那些值得关注的细节，也分享一个前端老鸟面对“AI编程”时的真实心态。
1. 项目起因：为什么我会用AI生成原生页面
1.1 一个紧急需求
活动报名页这个东西，听起来简单，真正做起来琐碎事一大堆。当时朋友给的需求只有一句：“内部团建活动报名，能填名字、手机号、人数，页面上最好有个倒计时，报名成功后能看到已报名的人。”没有设计规范，没有组件库，甚至没有太严格的视觉要求。唯一麻烦的是页面要嵌在他们公司CMS的富文本编辑器里，不能引入React/Vue，也不能依赖npm构建流程，我必须交付一段可以直接粘贴的HTML。
按照传统方式，我会先搭一个外层容器，再写响应式样式，再写表单校验和交互逻辑。一个不复杂的页面，从结构到联调怎么也要两三个小时。但这次活动比较赶，加上我已经很久没有手写原生三件套了，很多API的边界情况还要翻文档确认。我索性跟朋友说，给我30分钟试试，用AI生成一版，能跑就行。
就是这30分钟，让我对“前端开发”这件事产生了新的判断。AI不是帮你写几行代码那么简单，它能在你描述清楚需求之后，直接给出一整份可运行、结构完整、注释齐全的原生页面。而我要做的，反而变成了“提出更好的问题”和“检查它给出的答案”。
1.2 为什么选“原生页面”而不是框架
很多人会问，现在公司里不都是Vue或者React吗？为什么不直接让AI生成一个Vue组件，然后放进工程里跑？这里面有个很实际的约束：部署环境不允许。CMS后台很多都是老系统，你不可能为了一个报名页去搭一套前端工程化工具链，也不可能要求运营同学去执行npm install。这时原生HTML/CSS/JS就是最稳妥的交付物。
另一个原因是页面规模和状态复杂度。活动报名页只有“表单填写”和“列表展示”两类交互，数据可以存在内存里，后续如果需要接接口，无非是把Mock数据换成fetch请求。用框架反而要额外考虑路由、响应式状态、组件通信，属于杀鸡用牛刀。就像你工具箱里明明有一把趁手的小螺丝刀，非要去开一台数控机床来拧螺丝，没必要。
从另一个角度看，原生页面恰恰是AI目前最擅长生成的类型。大模型训练数据里包含大量静态页面、落地页、表单页面的示例，这些页面的模式非常成熟，标签结构相对固定，CSS属性也基本稳定。相比之下，让AI生成一套完整的微前端架构或者复杂权限系统，它就容易“一本正经地胡说八道”。所以这个项目选择原生页面，既是业务需求，也是让AI发挥最大价值的路径。
1.3 工具选型：Cursor还是别的
这次我用的主力工具是Cursor。AI编程工具带不带来效率提升，试一次就知道。我对比过几款主流的AI编码助手，各有特点，这里先给一张表。
| 工具 | 核心优势 | 明显短板 | 适合场景 |
|---|---|---|---|
| Cursor | 对话能力完整，可整文件生成和重构 | 免费额度有限，需要注册 | 整个页面从零生成、批量重构 |
| GitHub Copilot | 和编辑器结合深，补全很自然 | 更适合“行级补全”，整页生成稍弱 | 在已有代码里写业务逻辑 |
| 通义灵码 | 中文友好，免费额度大 | 生成的代码风格不太稳定 | 中文需求描述、快速原型 |
我用Cursor的主要原因是它的Composer模式可以同时生成HTML、CSS、JS三个文件，并且能根据我的反馈直接修改整个文件，而不是像我以前用Copilot那样，还要自己复制粘贴多轮。当然，工具只是手段，真正决定输出质量的还是提示词。同一段需求，给AI说“做个报名页”和给AI说“移动端优先、无外部依赖、表单校验规则如下”是完全不同的结果。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 30分钟实战：从需求描述到可运行页面
2.1 第一步：把需求翻译成AI能听懂的话
AI不是读心术，它的输出质量高度依赖你的输入信息密度。我写的提示词大概是这样的：
用原生HTML+CSS+JavaScript生成一个活动报名页面，移动端优先，桌面端最大宽度1200px居中。内容包括：顶部活动标题和倒计时，