我准备用 AI 二开 shadcn-admin，做一个可交付的后台管理系统模板

最近我在做一个长期项目，叫 WebGold。

它的核心目标不是"从零造轮子"，而是把优秀的开源项目二开成真正能交付的产品资产：

能跑起来
能截图展示
能打包发版
能卖源码
能录制课程
能继续二开
能形成商品化包装

第一期我选的项目是一个非常优秀的开源后台模板：shadcn-admin。

它本身基于 React、TypeScript、Vite、shadcn/ui、Tailwind，技术栈现代，UI 质量也不错，非常适合作为前端后台模板的二开起点。

为什么不是从零写一个后台？

很多人做后台管理系统，第一反应是：

我自己从零搭一个模板。

但从商业化和效率角度看，这并不一定是最优解。

一个真正能交付的后台模板，远远不只是几个页面这么简单。它至少包含：

模块	内容
工程结构	路由、布局、组件、状态管理
UI 体系	表单、表格、弹窗、菜单、主题
开发体验	TypeScript、Lint、构建配置
测试体系	单元测试、E2E 测试、截图测试
文档体系	README、运行说明、二开说明
交付体系	release 包、版本说明、截图目录

如果这些全部从零做，成本很高。

所以我的思路是：优先选择成熟开源项目，然后做 AI 友好的二次开发和商品化包装。

WebGold 的二开原则

我给自己定了一条铁律：

二开不是推倒重来，而是在尊重上游架构的前提下，把它改造成可交付资产。

所以在二开过程中，我不会轻易做这些事：

不轻易换技术栈
不把 React 改 Vue
不把 Vue 改 React
不强行把前端模板改成全栈项目
不随便重构上游目录结构
不破坏上游构建方式
不污染主分支

真正要做的是这些：

加品牌
加业务页面
加 mock 数据
加默认演示账号
加 README
加真实截图
加自动化测试
加 release 说明
加商品化包装

这才是开源二开的重点。

这次二开的项目：如意Admin

这次我把 shadcn-admin 二开成了一个 mock 版本的后台模板，产品名叫：

如意Admin / Ruyi Admin

它的定位是：

一个面向 AI 二开、源码交付、课程实战的现代后台管理系统模板。

当前版本不是为了直接接后端，而是先做一个完整的前端 mock MVP。

也就是说，它的第一阶段目标很明确：

先能演示
先能截图
先能打包
先能交付
后续再接 Django / FastAPI / Gin 等后端版本

技术栈

当前项目技术栈如下：

技术	用途
React	前端框架
TypeScript	类型系统
Vite	构建工具
shadcn/ui	UI 组件体系
Tailwind CSS	样式系统
Playwright	E2E 测试与截图
pnpm	包管理

这套技术栈的优势是：

前端体验现代；
UI 质量比较高；
适合做 SaaS 后台；
适合 AI 辅助二开；
适合后续拆成课程案例。

我改了什么？

这次二开不是大改架构，而是做了一个"可交付 mock 版本"。

主要改动包括：

1. 品牌统一

项目里所有核心展示统一成：

如意Admin
Ruyi Admin
大鹏AI教育
ruyi

登录页标题、副标题、侧边栏团队名称、Dashboard 欢迎语、用户头像、favicon 都做了统一。

2. 默认演示账号

后台模板如果要交付，默认账号非常重要。

当前默认演示账号是：

复制代码

账号：ruyi
密码：ruyi888

登录页和 README 里都写清楚了，方便演示、录课和源码交付。

3. 固定开发端口

为了后续统一管理多个 WebGold 项目，我给每个项目分配固定端口段。

如意Admin 作为第二个正式项目，使用：

makefile 复制代码

dev:     11200
preview: 11201

这样以后录课、截图、文档、自动化测试都不会乱。

4. 自动截图

一个可卖的后台模板，不能只说"页面好看"。

必须有真实截图。

当前已经生成了这些截图：

bash 复制代码

docs/screenshots/01-sign-in.png
docs/screenshots/02-dashboard.png
docs/screenshots/03-products.png
docs/screenshots/04-orders.png
docs/screenshots/05-shop-settings.png

这些截图不是伪造的，而是通过 Playwright 自动跑出来的真实页面截图。

5. 自动化测试

一个项目能不能交付，不能只看页面能不能打开。

还要看测试能不能过。

当前验证项包括：

bash 复制代码

pnpm exec tsc -b
pnpm lint
pnpm build
pnpm test
pnpm test:e2e

这一步对商品化非常关键。

因为源码交付最怕的问题是：

买家一运行就报错。

所以发版前必须保证类型检查、Lint、构建、单测、E2E 都通过。

为什么要做 mock 版本？

很多后台系统一上来就想接后端。

但我这次故意先做 mock 版本。

原因很简单：

前端模板的第一价值，是展示、演示、复用和二开，而不是一开始就绑定某个后端。

mock 版本的好处是：

没有数据库依赖；
没有后端部署门槛；
买家可以直接运行；
适合截图展示；
适合录课；
后续可以扩展多个后端版本。

未来路线可以是：

版本	方向
mock 版	纯前端演示模板
Django 版	适合 Python 后端用户
FastAPI 版	适合 AI 应用后端
Gin 版	适合 Go 后端用户
SaaS 版	接真实业务数据

这样一套前端模板，可以衍生出多个产品版本。

AI 在这个项目里负责什么？

这个项目很适合 AI 编程，但不是让 AI 随便乱改。

我的协作方式是：

角色	职责
我	项目 Owner，决定方向
ChatGPT / 如意	产品经理、架构协调、任务拆解、验收
Claude / Codex / Gemini	执行端全栈工程师

AI 最适合做这些事：

阅读项目结构
修改文案和品牌
补 README
写测试
写截图脚本
修构建错误
生成 release 文档
做版本验收清单

但 AI 不适合没有边界地"自由发挥"。

所以每个任务都必须写清楚：

项目路径
当前分支
目标版本
禁止事项
验收命令
输出文件
commit 信息
release 路径

这也是我觉得 AI 编程真正重要的地方：

不是会不会写代码，而是能不能把任务拆到 AI 可以稳定执行。

这次发版包会包含什么？

一个可交付的 release 包，不能只有源码 zip。

我计划让它包含：

arduino 复制代码

源码.zip
release.json
版本说明.md
核心功能与特色.md
README.release.md
screenshots/

其中 release.json 记录版本元信息，例如：

json 复制代码

{
  "project": "shadcn-admin",
  "product_name": "如意Admin",
  "line": "mock",
  "version": "v0.1.0",
  "branch": "ruyi/mock/v0.1.0",
  "dev_port": 11200,
  "preview_port": 11201,
  "demo_username": "ruyi",
  "demo_password": "ruyi888",
  "brand_owner": "大鹏AI教育"
}

这样做的好处是，后续不管是自己维护、卖源码、录课程，还是继续二开，都有清晰的版本记录。

我对开源二开的一个判断

过去很多人做开源二开，容易犯两个错误。

第一个错误是：只改页面，不做交付。

页面看起来改了，但没有 README，没有截图，没有测试，没有 release 包，最后还是一个半成品。

第二个错误是：一上来就大重构。

把原项目的技术栈、目录结构、构建方式全部改掉，结果上游更新吃不到，维护成本也越来越高。

我的判断是：

真正适合个人开发者和 AI 编程的方式，不是重造项目，而是把优秀开源项目变成标准化资产。

这个资产可以卖，可以讲，可以录课，可以继续扩展。

总结

这次如意Admin mock v0.1.0 的意义，不只是改了一个后台模板。

更重要的是，它验证了一个流程：

arduino 复制代码

开源项目选择
→ AI 辅助二开
→ 品牌改造
→ mock 数据演示
→ 自动化测试
→ 自动截图
→ release 打包
→ 商品化包装

这就是我正在做的 WebGold 方法论。

后续我会继续记录这个项目的发版过程，包括：

如何打包 release
如何写版本说明
如何做截图验收
如何规划 v0.1.1
如何引入 i18n
如何接 Django / FastAPI 后端

如果你也想用 AI 做开源项目二开，我建议不要一开始就追求"大而全"。

先选一个好项目。

先跑起来。

先改出一个可演示版本。

先打一个真正能交付的 release 包。

这一步完成之后，项目才真正从"代码"变成了"资产"。