一次 AI Coding 实践：把数字人平台前端生成流程做成 Skill

最近在做一个 AI Coding 相关的小实验。

问题很简单：

AI 能不能不只是生成一个单页 Demo，而是生成一个结构相对完整、可换肤、可验证的业务前端？

很多 AI 编程工具现在已经可以很快生成页面。

比如输入：

帮我做一个数字人管理平台，要有登录、注册、工作台、数字人列表和对话页面。

AI 通常可以生成一个看起来还不错的前端页面。

但如果把它放到真实项目里，会很快遇到一些问题：

页面风格不统一
JS 逻辑容易堆到一个文件里
样式和业务逻辑混在一起
换主题时可能改坏事件绑定
改布局时可能影响接口调用
生成后缺少验证流程

所以这次没有继续写更长的 Prompt，而是尝试把项目结构、模块边界、主题规则和验证流程整理成一个 Skill。

这个 Skill 的目标是：

让 AI Coding Agent 按照约束生成一个数字人管理平台前端。

它不是一个固定模板，而是一套面向 AI 的生成规则。

1. 为什么普通 Prompt 不够？

普通 Prompt 更像是一次性需求描述。

例如：

请帮我生成一个数字人管理后台，包含登录、注册、工作台、数字人列表、数字人编辑、实时对话和 API 文档页面。页面风格要现代，代码结构清晰。

这种方式在简单场景下没问题。

但项目稍微复杂一点，就会暴露出不稳定的问题。

例如你后续补一句：

把页面改成深色科技风。

AI 可能会做几件事：

修改 CSS
修改 HTML 结构
顺手改 JS 事件
重新组织 DOM
改掉接口调用位置
删除一些原有逻辑

也就是说，它不一定只是在“换皮肤”，而可能在“重写页面”。

这对真实前端项目来说风险比较高。

所以我更希望把 AI 的任务边界定义清楚：

Prompt：描述本次要生成什么
Skill：定义应该如何生成

Prompt 是需求。
Skill 是规则。

2. 这个 Skill 生成什么？

当前这个 Skill 面向的是一个数字人管理平台前端。

默认包含 7 个页面：

index
login
register
workspace
ai-agents
standard-agent
api-flowchart

页面功能大致如下：

页面 作用
index 首页 / 产品入口
login 登录页
register 注册页
workspace 工作台
ai-agents 数字人 / AI Agent 列表
standard-agent 数字人编辑与实时对话页
api-flowchart API 流程与开发文档页

除了页面之外，还拆分了 13 个 JS 模块：

config.js
api.js
auth.js
sse.js
websocket.js
decoderWorker.js
rendererWorker.js
login.js
register.js
workspace.js
ai-agents.js
standard-agent.js
index.js

这些模块的职责大致是：

模块 职责
config.js 基础配置，例如接口地址
api.js 请求封装和错误处理
auth.js Token、用户信息、登录状态
sse.js SSE 客户端封装
websocket.js WebSocket 通信封装
decoderWorker.js 数据解码 Worker
rendererWorker.js 数字人渲染 Worker
login.js 登录页逻辑
register.js 注册页逻辑
workspace.js 工作台逻辑
ai-agents.js 数字人列表逻辑
standard-agent.js 数字人编辑与对话逻辑
index.js 首页逻辑

这里重点不是文件数量，而是职责边界。

AI 生成前端项目时，很容易把所有东西写到一个 main.js 里。

短期看没问题，后续维护会比较痛苦。

所以这个 Skill 会尽量让 AI 按模块拆分：

接口请求归 api.js
登录状态归 auth.js
实时通信归 sse.js / websocket.js
页面交互归页面自身 JS
主题样式归 theme.css

这样生成出来的项目更接近真实前端工程结构。

3. 核心设计：换肤只改 CSS

这次实践中，我最关注的问题是：

如何让 AI 换视觉风格时，不要破坏业务逻辑？

所以 Skill 中有一个明确约束：

视觉主题主要通过 theme.css 完成，不随意修改业务 JS。

比如企业蓝主题可以抽象成 CSS 变量：

:root {
--color-primary: #1976D2;
--color-accent: #FF6F00;
--color-bg: #FAFAFA;
--color-surface: #FFFFFF;
--color-text: #1F2937;

--radius-card: 12px;
--radius-button: 10px;

--shadow-card: 0 8px 24px rgba(15, 23, 42, 0.08);
}

如果要换成深色科技风，主要调整变量：

:root {
--color-primary: #0EA5E9;
--color-accent: #38BDF8;
--color-bg: #0F172A;
--color-surface: #1E293B;
--color-text: #E2E8F0;

--radius-card: 12px;
--radius-button: 8px;

--shadow-card: 0 16px 40px rgba(0, 0, 0, 0.35);
}

这样做的好处是：

换颜色，不影响接口请求
换圆角，不影响表单校验
换阴影，不影响登录鉴权
换背景，不影响 SSE / WebSocket
换品牌视觉，不影响业务流程

换句话说，主题变化应该尽量停留在 CSS 层。

AI 可以改视觉，但不应该因为改视觉而重写业务逻辑。

4. 布局可以变，但业务逻辑不能乱变

除了换肤，另一个常见需求是换布局。

比如登录页可以有两种布局：

居中卡片登录

或者：

左侧品牌介绍
右侧登录表单

数字人列表页也可以是：

卡片网格

或者：

表格列表

展示方式可以变化，但业务流程应该保持一致。

登录页换布局后，下面这些东西不应该变：

邮箱字段
密码字段
登录接口
Token 存储
错误提示
登录成功跳转

数字人列表从卡片改成表格后，下面这些逻辑也不应该变：

列表接口
编辑操作
重命名操作
删除操作
状态展示

所以 Skill 中会把布局变化限制在 UI 层。

核心原则是：

结构可以调整
视觉可以变化
业务逻辑不要重写

这也是我认为 Skill 比单次 Prompt 更适合复杂前端项目的原因。

5. 生成流程设计

当前生成流程分成 4 步：

1. 复制全部文件
2. 生成 theme.css
3. 注入样式链接
4. 执行验证门控
   5.1 复制全部文件

先复制基础页面、JS 模块和静态资源结构。

这一步保证项目骨架完整。

5.2 生成 theme.css

根据用户描述生成主题文件。

例如：

Material 企业蓝
深色科技风
赛博朋克风
玻璃拟态风
暖色运营风
5.3 注入样式链接

把主题样式挂到页面中：

<link rel="stylesheet" href="css/theme.css">
5.4 执行验证门控

AI 生成代码后，不能只看它说“完成了”。

至少应该检查：

7 个页面是否可访问
控制台是否有明显错误
theme.css 是否正确加载
业务 JS 是否被误改
关键元素是否有 data-testid
是否避免内联 onclick
基础 Playwright 检查是否通过

这个步骤主要是为了避免一种常见情况：

看起来已经生成完成
实际运行时一堆错误

AI Coding 如果要用于真实工程，验证流程是绕不开的。

6. 使用示例

如果使用的是支持读取项目文件的 AI 编程工具，可以让它读取 Skill 文件，然后给出目标风格。

例如生成一个 Material 企业蓝版本：

读取 sumeruai-digital-human/skill.md，
按步骤生成一个数字人平台前端。

输出目录：h5-site-material

风格：Material Design 3 企业级，elevation 阴影，ripple 点击效果
配色：主色 #1976D2，辅色 #FF6F00，背景 #FAFAFA
圆角：12px
字体：Roboto, system-ui

生成一个深色科技风版本：

读取 sumeruai-digital-human/skill.md，
按步骤生成一个数字人平台前端。

输出目录：h5-site-dark

风格：深色科技后台
布局：登录页使用左右分栏，数字人列表使用紧凑表格
配色：主色 #0ea5e9，背景 #0f172a，卡片 #1e293b，文字 #e2e8f0
圆角：12px
字体：system-ui

生成一个赛博朋克风版本：

读取 sumeruai-digital-human/skill.md，
按步骤生成一个数字人平台前端。

输出目录：h5-site-cyber

风格：赛博朋克，暗色背景，霓虹发光，锐利直角
配色：主色 #00F5FF，辅色 #FF00E5，背景 #070816
圆角：4px
字体：system-ui

从这个过程可以看到，真正重要的不是 Prompt 写得有多长。

真正重要的是 Skill 已经定义好了项目结构和生成边界。

7. 和普通模板有什么区别？

这个问题一开始我也想过。

普通前端模板给的是一个固定结果：

一套已经写好的代码

Skill 更像是给 AI 的生成规则：

应该生成哪些页面
应该拆哪些模块
哪些文件可以改
哪些文件不要乱改
换肤应该怎么做
布局变化要遵守什么边界
生成完成后如何验证

所以同一个 Skill 可以生成多个版本：

企业蓝版本
深色科技版本
赛博朋克版本
玻璃拟态版本
卡片网格版本
表格列表版本
左右分栏登录版本

它不是固定模板，而是可复用的生成规范。

这也是 AI Coding 和传统模板不太一样的地方。

8. 当前限制

这个 Skill 目前主要解决的是前端生成问题，不是完整商业系统。

如果要用于真实项目，还需要继续补充：

真实后端 API 对接
用户权限系统
数字人 SDK 授权
文件上传
音视频流稳定性
日志系统
管理员权限
部署和监控
生成内容标识
安全审计

所以更准确地说，它目前适合这些场景：

数字人平台前端骨架
AI Coding 业务案例
售前 Demo 原型
前端 Skill 实验项目
AI 编程教学案例

而不是直接替代完整的生产系统。

9. 一些实践体会

这次做完以后，我对 AI Coding 有几个感受。

第一，复杂项目不能只靠一句 Prompt。

Prompt 适合描述目标，但不适合承载全部工程约束。

第二，AI 生成代码时，边界越清楚，输出越稳定。

例如哪些文件能改，哪些文件不能改，主题应该放在哪里，验证应该怎么做，这些最好提前写清楚。

第三，AI Coding 要进入真实项目，QA 门控很重要。

AI 说“完成了”只是第一步，能跑、可测、不破坏原有逻辑才更重要。

第四，Skill 可能会成为 AI 编程里的一个重要中间层。

它介于自然语言需求和最终代码之间，用来承载项目经验、工程规范和生成流程。

10. 总结

这次实践的核心思路是：

把业务经验沉淀成 Skill
把工程规范沉淀成 Skill
把主题约束沉淀成 Skill
把验证流程沉淀成 Skill
让 AI 在规则内生成项目

当前这个数字人平台 Skill 主要做了几件事：

生成 7 个页面
拆分 13 个 JS 模块
支持 CSS-only 换肤
支持布局变体
约束换肤时不改业务逻辑
包含 SSE / WebSocket 等实时通信模块
加入基础 QA 验证思路

我觉得 AI 编程接下来会从“让 AI 写代码”，逐步走向“让 AI 按工程规则生成项目”。

这次的数字人 Skill 算是一个小实验。

欢迎大家交流，也欢迎拍砖。

体验地址：https://skill.sumeruai.com/avatars/