大家好，我是男秀。
最近有个小程序项目需要一个管理后台。作为 Python 工程师，我第一反应是去 GitHub 上找现成的脚手架。很快发现了一个叫 django-vue-admin 的项目，Python + Vue 的技术栈正好匹配。
但翻了几页源码后，一言难尽。在 AI 时代之前，这个项目确实提供了一个不错的开发起点，但放到今天来看，它的目录划分混乱、代码风格不太统一，而且是基于 DRF 进行开发的。
就在这时候，我脑子里跳出一个念头：不如让 AI 按我的想法，生成一个全新的 django-vue-admin？
从这个念头开始，我花了一个周末折腾出来了。最终发到 GitHub 上的不是 Python 源码，而是一份 Skill。
一
我是怎么做的呢？
一开始，我没有直接打开终端让 AI 写代码。我先做了一件事：把我想生成的后台功能，用文档完整地描述出来。
这份开发文档最终写了两万多字，包括项目概述、技术栈选型、模块划分、数据库设计、API 规范、前端架构和部署说明八个章节。它本质上就是一套给 AI 看的「施工图纸」——每个技术决策都写清楚了原因。
举几个里面涉及的具体决策。
第一个，为什么用 django-ninja 而不是 DRF。DRF 在 Django 社区确实是主流选择，但我过去在实际项目中使用过两种框架后，更倾向 django-ninja。它基于 Python 的类型注解自动生成 OpenAPI 文档，开发体验接近 FastAPI——装饰器风格的路由定义比 DRF 的类视图更简洁。同时又能复用 Django 的 ORM、中间件和 Admin 面板。对我来说，这不是选哪个框架的问题，而是「既要 Django 生态的成熟度，又要现代 API 框架的开发效率」。
第二个，主键为什么用自实现的 Snowflake ID 而不是数据库自增。一个原因是 Snowflake ID 全局唯一且时间有序，对 MySQL 主键索引更友好。另一个原因是数据库自增 ID 在分布式场景下会出现冲突，而 Snowflake 通过 worker_id 参数就能区分不同实例。在实现上我参考了 GitHub 的 python-snowflake 仓库，让 AI 在 core/snowflake.py 里实现了一个 Snowflake ID 生成器。
但 Snowflake ID 有一个坑：它是 64 位长整型，最大可以到 17 位十进制数字，而 JavaScript 的最大安全整数是 16 位。这意味着前端处理后端返回的数值型 ID 时，末位精度会丢失——用这个 ID 发回后端就查不到数据了。我对比了两种方案：前端装 json-bigint 第三方包来处理，还是后端在序列化时把超出安全范围的整数转成字符串。我选了后者，因为 ID 以字符串形式过 JSON 边界在语义上是正确的，而且不用每个前端项目都装一次依赖。
第三个，API 架构我用了两个独立的 NinjaAPI 实例。项目里有两条完全不同的链路：B 端管理后台走 JWT + RBAC 认证，C 端小程序走微信 OAuth 认证。如果只用一个 NinjaAPI 实例，需要在一个地方混用两套认证逻辑，Swagger 文档也会全部耦合在 /api/docs 下。拆成两个独立实例后，各自的认证后端、异常处理器和 Swagger 文档物理隔离，B 端 Swagger 在 /api/docs，C 端在 /api/client/docs。而且后续 C 端如果需要独立扩容，也不会影响 B 端。
这些决策单独看都不算大问题，但组合在一起，就是一份能让 AI 理解项目全貌的完整规格。
二
先写开发文档这个动机，一定程度上得益于我之前的两段经历。
一段是在前东家参与需求文档 AI Agent 系统的开发。这段经历让我把需求文档这件事系统地过了一遍：一份合格的开发文档该包含哪些章节、功能描述该写到什么粒度、边界条件和异常路径该怎么表达。以前我觉得文档是交接时候用的，那段经历之后我意识到，好的文档本质上就是把模糊需求转化为精确规格的过程——这和写代码用的是同一种能力。
另一段是去年年末上过开智社群的 AI 产品课。虽然课程内容在这个项目里直接用到的地方不多，最重要的是我学习到了怎么写一份交接给AI的文档。
写完文档之后，我用它驱动 AI 生成了一版完整的后台代码。后端是 Django 5 + django-ninja，前端是 Vue 3 + TypeScript + Element Plus。能跑，功能也基本齐全。
但我没有把这个项目代码直接发到 GitHub 上。原因很简单——如果我开源这个代码模板，和之前早已开源的django-vue-admin项目有什么优势呢？
我认为，真正需要开源的，是那份两万多字的开发文档。它定义的是一个通用的后台管理框架应该长什么样。
三
这不只是我自己的想法。之前看过一篇文章，里面提到 GitHub 上出现了一种新的开源方式：不开源代码，而是开源 Prompt。逻辑不难理解——既然 AI 能高效编写代码了，那描述功能的 Prompt 就变成了比代码更底层、更持久的资产。
代码绑定具体的语言、框架和版本，容易过时。但一份好的规格文档，可以在不同技术栈之间迁移。
于是我把那份开发文档进行了脱敏处理，只保留通用的管理后台框架部分。然后按照 Claude Code Skill 的格式，重新做了结构化拆分。
拆分之后的结构是这样的：一份 150 行的 SKILL.md 作为工作流编排器，定义了三个生成阶段——后端骨架、前端骨架、联调初始化——以及每个阶段需要读取的参考文档。详细的 9 份主题文档放在 references 目录下，分别覆盖数据库设计、后端架构、前端架构、API 规范、编码约定、安全策略、环境搭建和业务模块扩展模板。这些文档不会被一次性塞进 AI 的上下文，而是按需加载——用到哪份读哪份，不被引用的部分不消耗 token。
1 | django-vue-admin-skill/ |
这个拆分思路在设计上有个名字叫渐进式披露，本质上就是把大文档切割成小块，让 AI 在正确的时机看到正确的内容。如果直接把两万多字的文档整块丢给 AI，上下文窗口挤满了细节信息，反而容易导致遗漏。
整个提炼过程加上调整，只是一个周末的时间。
最终产出的 Skill，安装后只需要在 Claude Code 里激活，AI 会先确认几个配置——项目名、数据库类型、要不要 C 端接口——然后分阶段生成完整的后台代码。超级管理员账号、预设菜单结构、字典初始化数据这些也会一并生成好，跑完就能直接登录。
配图dashboard
四
但是，理想和现实之间总有距离。
去年年末，我帮开智社群做过一轮 AI 生成网站的测试。社群的技术专家用 AI 快速搭建了一个课程平台，包含作业提交、评论互动、讨论区发帖等功能。但实际跑起来后问题不少：有些接口的数据没有真正写入数据库，个别接口直接报 500 错误。表面看起来功能齐全，细节上经不起推敲。
这次用我自己写的 Skill 重新生成后台时，同样的事又发生了。我在开发文档里花了一些篇幅描述图形验证码的实现——生成逻辑怎么设计、验证码的 key 为什么不放在 Cookie 里，甚至在文档里专门有一个对比表来论证为什么 key 明文返回比 HttpOnly Cookie 更合适。
但 AI 生成的代码里，图形验证码这个功能似乎被跳过了。不是写错了，是在前端登录页面看不到图形验证码的功能。
这让我更确认了一个观察：你给 AI 提了十个功能点，它可能会扎实完成八个，剩下的两个，它用自己的方式「优化」掉了。
国产模型的现状也能佐证这个观察。我个人判断，国产模型大致比国外顶级模型落后六个月左右——这也是目前 AI 行业比较普遍的共识。按这个推算，今年年中我们手里国产模型的能力，大约相当于去年年末国外模型的水平。所以你现在用 AI 写代码，实际上是在使用「半年前」水平的程序员——能力强，但需要你盯着。
外行看的是「AI 几分钟生成了一个系统」的结果，很震撼。内行看的是这十分钟里 AI 漏掉了哪些东西。
五
回到这个 Skill 本身，它的价值在几个层面。
最直接的，它是一个快速启动工具。任何需要 Django + Vue 管理后台的项目，用它生成骨架，比自己从零搭要快很多。
更深一层，它展示了一种工作方式：把设计意图描述清楚，让 AI 负责落地，人负责审查。这和传统的「先写代码再补文档」是反过来的。我过去的开发习惯是先写代码，文档能省则省。但现在正好倒过来——先把文档写好，因为文档写好了，代码可以让 AI 来补。
这种做法能不能推广到其他场景？我认为可以。组件库、工具函数、甚至一套微服务架构，都可以用相同的思路做成 Skill 文件。代码是具体的实现，规格是抽象的设计——后者可以在语言和框架之间迁移。
最后，也是我体会最深的：AI 生成代码之后，你有能力判断它的质量吗？你能看出它漏掉了什么吗？图形验证码没生成、接口没写数据库落库逻辑、异常处理少了一层——这些问题，AI 不会提醒你，只能靠你自己的经验去发现。
AI 是放大器。你懂的东西，它能帮你做得更快。你不懂的东西，它也会理直气壮地糊弄过去。
六
把多年的开发经验压缩成一份 Skill 文件，让 AI 把隐性的知识显性化——这件事花了不到两天。我不觉得这是 AI 替代了我。恰恰相反，这是我第一次确切地感受到：不是让AI来驾驭我，而是我在驾驭AI，构建自己的方法论。
这大概就是创作者才会体会到的喜悦感。