这篇文章讨论的不是 Demo 级别的 AI 编码体验，而是面向真实团队、长期维护的中后台工程实践。

最近一年。大模型在前端领域的讨论几乎都围绕一个问题：

在真实的中后台项目中，我的答案是： 不但不稳，而且很危险。怎么说呢，

这篇文章想分享一种我在真实项目中实践过、可长期使用、可规模化的方式： 不是让 AI 写页面而是把 AI 纳入中后台前端的工程程序中。说起来，把 AI 的不确定性关进了笼子里用工程流程保证可控性。

模板固化规范。Spec 描述变化，大模型生成 Spec，脚本生成代码，lint/test 做兜底。它解决了 AI 上工程最致命的四件事：

1. 可审计变化在 spec。生成结果可 diff
2. 可重复同一个 spec 反复生成结果一致
3. 可兜底lint/test 是硬门槛
4. 可规模化:从 prompt 工艺变成流程

在中后台场景,特别是 CRUD 占比高 的项目里,这几乎就是“性价比最优解”。

一、中后台页面开发的真实困境

如果你做过中后台前端,一定对下面这些场景不陌生 :

• 页面 % 是 CRUD
• 列表页结构基本一致
• 表单字段持续变化
• 大量复制粘贴
• 页面逻辑“看起来差不多。但永远不完全一样”

结果往往是 :

• 代码冗余
• 风格不统一
• 新人上手慢
• 改一个字段要改好几个地方

这些问题 不是某个框架的问题

二、为什么“让 AI 直接写页面”在真实项目里行不通？不过，

在真实项目中。这种方式往往会遇到几个致命问题。 按理说，

1️⃣ 不稳定

同一个 prompt，每次生成结果不同 组件结构 、命名风格不断漂移 难以保证团队统一规范

2️⃣ 难以 review

AI 一次生成几百行代码 reviewer 很难判断 “这是不是对的” 出问题时难以定位责任

3️⃣ 无法规模化

prompt 是隐性的 经验无法沉淀 每个页面都是 “重新生成一次”

4️⃣ 工程程序无法兜底

lint / test 很难提前发现语义问题 一旦出错。往往是运行期问题

结论很明确 : AI 直接写页面，更像是 demo，而不是工程方案。

这份 JSON 不依赖任何前端框架，但已经完整描述了一个中后台页面的 “变化点”。

说到特点，* 人工维护 *版本化 * reviewable

与框架无关。

换个角度的观点是，

Generator不是智能但靠谱。

从只做两件事来看，

1.从自然语言→spec 擅长理解业务描述补全字段信息。

从正确姿势来看，

1.AI根据自然语言→spec 示例指令的观点是，

src/views/下创建supplier.json包含name,contact,phone,status接口/api/supplier/*严格JSON输出.

接下来的观点是。

yarn genpage specs/supplier.json yarn lint如果报错再修:

根据lint报错修改List.vue最小diff通过.

h2数据id=header- 八.为什么这种方法更合适?

至于优势，•可控 •reviewable •回滚清晰 •非prompt驱动 •迁移简单

比直接ai写更稳.

h2数据id=header- 九.思路不仅限于admin面板可以 到: •表单页详情页权限路由迁移低代码/自动化主要拆分边界.

h2数据id=header- 十.终极目标?老实说，起点而非终点.

Template+Spec+Gen只是起点. 推荐看作进化路线:

第一步先的观点是。快速落地低风险引入AI接下来: BaseCrudPage→配置驱动然后: spec+渲染器第四步: AST修改老项目渐进式演进一句话: 从template开始最终走向config-driven/patch-based.

h2数据id=header- 十一.结论. 价值在于结构化嵌入工程. 最稳的是设置边界工作. 从记住一点来看，不要ai写pages要它写change其余交给engineering!不过，

如果有帮助欢迎收藏👍

---