馒猫子那篇《时代的眼泪，前端的落寞》发出去之后，后台和评论区聊得最热闹的并不是“前端到底惨不惨”，而是另一个特别具体的疑问：你总说AI生成代码效率高，那真有本事让它30分钟给你生成一个能看的原生页面吗？带着这个问题，我上个月特意做了一次实验，在一个“故意不使用任何框架”的轻量需求里，把整个流程完整跑了一遍。结论是：能，而且过程中踩的坑比我预想中少，但需要人盯着的地方也比以前多得多。
我挑选的目标场景，是一个竖屏数据看板，中央放一个罗盘式时钟，旁边环绕当日任务状态，底部再挂三张实时指标卡片。听起来不复杂，纯HTML、CSS、JavaScript三件套就能搞定，但要做得好用、耐看，并不是简单堆代码的事。这篇文章就把这次从0到1的过程拆开来讲，包括怎么向AI描述需求、怎么把AI给的零散代码整合成可维护的小项目，以及整个过程中哪些地方最容易翻车。如果你是那种想在工作中真正把AI用起来、而不是仅仅拿来写Demo的前端，这篇应该能给你一些参考。
1. 为什么我又回头折腾“原生三件套”
1.1 一个被低配环境逼回原点的需求
先说这个需求的来源。团队内部要办一个持续整个月的线上运营活动，需要在活动页上展示每天的数据完成度。活动的周期短、访问量不大、也没有复杂的角色权限。本来这种需求，放在三年前我肯定直接上Vue或React，然后拉一个组件库，配置脚手架，前后端联调后再部署。但这一次不行，因为服务器很旧，内存很小，不能指望上面常驻Node服务，也不允许为一个小活动页引入一堆依赖和构建链路。最稳妥的交付物，就变成一个扔到静态服务器上直接能打开的HTML文件。
一开始我是有点抗拒的，毕竟“只会写原生页面”在现在的面试和业务里都不是什么加分项。但重新冷静下来想，页面结构其实很清晰：一个罗盘核心区，一圈刻度标记，三块数据卡片，一组刷新定时器。如果用原生三件套实现，代码量撑死几百行，问题只是如何快速写出一个还没有太多Bug的初稿。这时我想，为什么不干脆把生成工作交给大模型，自己专注做最该做的拆解和校验工作。事实证明，这个方向是敞亮的，但敞亮不等于能闭眼狂奔，后面踩的坑就集中说明了一点：AI不是不会犯低级错误，而是会用很自信的语气犯低级错误。
1.2 “原生页面”和“AI生成”为什么天然合拍
再说说为什么我坚持选原生，而不是让AI生成一个带Vue单文件组件或React函数组件的项目。最关键的原因是：AI生成的代码未必符合你团队现有的工程规范，但你让它生成一个自包含的HTML文件时，几乎不会触碰框架选型、依赖版本、模块化规范这些问题。
原生页面的三大件之间边界足够清楚：HTML管结构、CSS管样式、JavaScript管交互。大模型对这种分离结构的训练语料极其充足，生成出来的代码往往结构完整、注释丰富，甚至比很多初级工程师写得更有条理。而且因为不涉及构建系统，它的运行结果就是所见即所得，你打开文件就能看到真实效果，省掉了“跑npm install五分钟、查依赖报错十分钟”的时间和情绪消耗。所以，用AI生成原生页面，本质上是一次信息还原度很高的“提效实验”：需求清晰、边界简单、结果可验证。
当然，这也意味着如果你需求描述得含糊，AI就会靠猜来填内容。实际做的时候我发现，AI能不能在第一步就生成让人满意的骨架，取决于我能不能把“信息架构”讲清楚，而不是把“画面感”讲清楚。这可能是整个流程里最容易被低估的一环。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 30分钟落地一个原生页面的完整实操过程
2.1 需求描述不是“画面想象”，而是“信息架构”
很多人让AI写页面，习惯是“帮我生成一个好看的罗盘时钟页面”。这种描述对AI来说太抽象了，因为没有告诉她什么是“好看”，也没告诉她不同区块的优先级。我这次试下来，最有效的办法是像写产品文档一样，把页面从大到小拆成“区块、状态、样式关键词”三层。
给AI的需求描述可以分为五个要素：
- 页面类型和屏幕方向：竖屏数据看板，适合手机端查看
- 页面结构：上半区是罗盘时钟，下半区是三张指标卡片
- 数据来源：先使用模拟数据，后续会替换为接口
- 交互状态：每秒更新指针角度，每5秒刷新一次指标
- 视觉关键词：深色背景、霓虹色点缀、简洁不留过多阴影
下面是我用的实际prompt（经过简化）：