用AI+Skill约束，5分钟生成Fastadmin后台插件-平芜编程栈

Fastadmin 插件开发能不能通过 AI 对话直接搞定？能，但前提不是让 AI 自由发挥，而是先给它一份针对 Fastadmin 的 Skill 约束。我把平时做 Fastadmin 后台插件时最容易遗漏的开发规范整理成一个 Skill 文件，然后让 AI 按这套规范直接生成插件。实测下来，一个单表后台管理插件从需求描述到可安装文件，理想情况下确实可以压到 5 分钟左右。下面把这套 Skill 怎么设计、和 AI 怎么对话、生成之后怎么验证，逐步拆开说。

先说清楚一件事：这里的 Skill 不是玄学，也不是某个神秘脚本。它就是把 Fastadmin 插件开发过程中那些“你应该知道、但每次都会忘”的规则，整理成一份可复用的开发约束。AI 本身不会凭空知道什么是好的 Fastadmin 插件，但只要约束给够了，生成结果会稳定很多。

1. 为什么 Fastadmin 插件开发会从“写代码”变成“聊需求”

1.1 Fastadmin 插件开发最耗时的环节是“重复确认”

用 Fastadmin 做过后台管理系统的人应该都有体会：单独一个后台模块本身并不难，无非是列表、表单、删除、状态修改。但真正耗时间的反而是那些重复的工程化动作。

新建一个后台管理插件时，你需要处理插件目录结构，准备入口文件，写安装和卸载逻辑，设计数据库表，配置后台菜单，注册权限节点，再写控制器、模型和视图。如果插件里还涉及附件上传、富文本内容、回收站、批量操作，那么要确认的点还会翻倍。

这些问题单独拿出来都不复杂，但组合在一起就很容易出错。最典型的是类名和目录名不一致，导致后台插件列表识别不到；还有菜单权限漏写，导致插件安装成功但普通管理员根本看不到入口。

这部分工作，恰恰是 AI 最适合接手的部分。它不是高难度逻辑，而是“规则明确、产出物固定、重复度高”的体力活。

1.2 Skill 解决的真正问题是“把规则变成长期记忆”

同样是让 AI 写代码，为什么有人生成完就能跑，有人生成完到处报错？

核心差别往往不在模型的智商，而在上下文里有没有给它完整的开发规范。默认情况下，AI 对 Fastadmin 的理解是比较模糊的。它可能知道 Fastadmin 基于 ThinkPHP，但不一定知道你当前项目的插件机制、目录命名、权限表结构、安装脚本格式。

每次对话都在新开一个聊天窗口，AI 不会自动记住你上次是怎么让它写插件的。Skill 的角色，就是把这些规则变成一份可以被重复加载的长期记忆。

我把 Skill 理解成三层内容：

背景层：告诉 AI 你的项目是 Fastadmin，不是裸的 ThinkPHP。
规范层：插件目录、命名、表前缀、菜单权限、安装卸载逻辑都按什么约定来。
校验层：生成完之后，哪些点必须人工复查。

有了这三层，AI 的输出就不是“看起来像 ThinkPHP 的代码”，而是“符合 Fastadmin 工程习惯的插件”。

1.3 这个方法适合谁，不适合谁

先说适合的人群。已经能独立跑通 Fastadmin 本地项目、但不想在重复插件结构上浪费时间的开发者；用 Fastadmin 做公司内部管理系统或外包项目的同学；还有需要频繁交付单表管理功能的场景，这套方式会明显提高效率。

再说不适合的情况。完全不会 PHP，也没搭过本地环境，直接指望 AI 聊天生成一套复杂系统，这不行。需要处理支付回调、复杂审批流、多商户分账、消息队列这类高业务复杂度功能时，也不应该让 AI 一次性生成。AI 输出的代码可以作为参考，但离稳定交付还差很多。

我一直强调一个判断：AI 生成插件能有多稳，取决于你对这个插件的验收标准有多清楚。

2. 想稳定产出，先把环境和需求定义好

2.1 Fastadmin 本地环境至少要能跑通

这条说起来像废话，但实际项目里很多人就是卡在这一步。AI 帮你生成插件后，总要在某个 Fastadmin 环境里安装验证。如果本地 Fastadmin 本身都没有一个能打开的站点，后面所有验证都无从谈起。

我的建议是最少确认这几项：

PHP 和 MySQL 已经启动，能访问 Fastadmin 后台。
当前项目使用独立的测试数据库，不要拿线上数据库直接试装。
addons 目录或插件目录可写，服务器用户有权限创建文件。
后台能正常登录，能打开已有的任意一个管理页面。
能看到项目日志目录，或者至少知道日志输出在哪里。

很多“插件装不上”的问题，根本原因不是 AI 生成的代码有问题，而是本地环境本身缺依赖、目录不可写、或者数据库连接不对。

2.2 选工具：网页对话、IDE 插件还是 Agent

我现在试下来，不同工具适合不同阶段。

直接用网页版对话，也可以完成流程，但每次都要把 Skill 内容手动粘进去，复制生成的多个文件也比较麻烦。这种方式适合临时验证，不适合高频开发。

用支持 AI 能力的 IDE 或编辑器，体验会好一些。你可以把 Skill 文件放到项目的配置目录里，让 AI 工具自动读取。生成代码时直接在编辑器里新建文件、保存，路径不容易错。

命令行型的编程 Agent 是另一种选择。它往往能直接扫描项目目录、创建多个文件、执行命令，适合批量生成插件和后续调试。不过它对 Skill 格式的兼容性、对本地环境的理解，需要提前测试。

选型标准不用太复杂：只要能稳定加载你的 Skill，能访问本地文件，生成的代码你能快速审查，就够用。不用为了追新工具不停换。

2.3 Skill 文件里应该放什么信息

Skill 文件不需要写得像论文，关键是让 AI 在拿到之后能按统一标准输出。

我一般会放这几类内容：

任务定义：这个 Skill 是用来生成 Fastadmin 后台插件的。
输入要求：开写之前必须先确认哪些信息。
输出格式：先给文件结构，再给建表语句，最后分段给代码。
Fastadmin 约定：目录、命名、权限、安装卸载、表前缀这些关键规则。
禁止事项：哪些写法不能出现，哪些场景不要硬编。
验证清单：插件生成后，从安装到功能需要核对哪些项。

第 5 章会给一个简化模板，你可以直接改着用。

2.4 用一个“公告管理”插件做演示

为了让下面的流程更具体，我拿一个最常见的后台管理功能举例子：公告管理。

需求可以描述成：在 Fastadmin 后台做一个公告管理插件，管理员可以查看公告列表，新增公告，编辑公告，把公告设为启用或停用，也支持删除。公告要有标题、内容、状态、发布时间等字段。内容编辑时使用简单的文本域即可，不引入复杂富文本。

为什么选这个例子？因为它足够小，但已经覆盖了 Fastadmin 插件最常见的完整闭环：列表、新增、编辑、删除、状态切换、菜单权限。这样一个功能如果能稳定生成，那大多数单表后台管理插件也都可以走同一套链路。

3. 和 AI 对话生成插件的完整流程拆解

3.1 第一轮：先交代边界，不急着写代码

我的习惯是，第一轮对话只讲业务边界，不让 AI 先写代码。

比如我会这样描述：

“我要在 Fastadmin 里新增一个公告管理插件。只做后台管理，不做前台展示。管理员可以查看公告列表、新增公告、编辑公告、删除公告、切换启用状态。公告字段需要包含标题、内容、状态、创建时间。请先确认插件名称、数据库表名和功能范围。”

如果 AI 直接开始给代码，我会要求它停下来，先输出理解和文件计划。这一步是为了防止业务理解偏掉之后，代码全部返工。

Fastadmin 里插件名称和表名一旦定错，后续改起来很痛苦。比如插件名用中文、表名里带大写字母，都会在 Linux 环境踩坑。先让 AI 用英文标识符确认，能省不少事。

3.2 第二轮：让 AI 先输出文件清单和建表语句

需求确认完，第二步不是写代码，而是让 AI 先输出两样东西：文件结构清单、建表语句。

下面是我在项目里常看到的插件结构示意：

addons/notice/ ├── Notice.php 插件入口文件 ├── config.php 插件配置 ├── install.sql 安装时执行的 SQL ├── uninstall.sql 卸载时执行的清理 SQL ├── controller/ 后台控制器目录 │ └── Notice.php ├── model/ 模型目录 │ └── Notice.php └── view/ 模板目录 ├── index.html ├── add.html └── edit.html

这里要特别说明：不同版本的 Fastadmin、不同二开项目，插件物理目录结构可能不完全一样。你本地如果有已经能用的插件，最好的办法是让 AI 先模仿现有插件的目录来生成，而不是照抄网上任意一篇教程。

建表语句也需要先看。我最常用的一种写法类似下面，但表前缀一定要改成自己项目实际配置：

CREATE TABLE `fa_notice` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `title` varchar(255) NOT NULL DEFAULT '', `content` text, `status` tinyint(1) NOT NULL DEFAULT '1', `createtime` int(10) NOT NULL DEFAULT '0', `updatetime` int(10) NOT NULL DEFAULT '0', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

注意fa_只是示例前缀。Fastadmin 的数据库表前缀通常可以在配置文件里改，如果 AI 直接写死fa_，而你项目用的是fast_或mysite_，安装就会出问题。让 AI 统一读取项目配置，而不是在代码里假定前缀。

3.3 第三轮：按文件清单逐段生成插件代码

文件结构和 SQL 确认通过之后，再让 AI 开始生成代码。

我不推荐在同一个回复里要求 AI 一次性输出一个超大压缩包式的完整代码。分段生成更可控。

先让 AI 生成插件入口文件、安装卸载脚本。再让它生成控制器和模型，最后生成视图页面。每生成一段，就在本地新建对应文件并保存。

如果是在支持 Agent 的开发环境里，可以让它自己创建文件，但你要检查路径。如果用的是普通网页对话，那就把不同文件分别复制到正确位置，复制前先确认目录路径。

还有一个容易踩的坑：文件编码。Fastadmin 对 PHP 文件编码比较敏感，特别是中文插件名或中文注释可能导致页面报错。尽量让 AI 生成普通的 UTF-8 无 BOM 文件。

3.4 第四轮：把安装步骤和权限注册单独拎出来复查

代码生成完，不要急着宣布成功。

我通常会让 AI 专门解释一遍安装流程，同时把菜单注册和权限注册的逻辑指着给我看。Fastadmin 这类后台框架，插件安装时往往不只是把文件放到目录里，还需要在权限表、菜单表里写入记录，这样后台角色才能看到入口。

如果 AI 给出的插件没有包含菜单和权限注册，那么就算安装成功，实际进入后台也可能只能通过 URL 手动访问，普通管理员账号根本看不到菜单。这个问题在初次测试时特别容易忽略。

另外还要看卸载脚本。如果卸载脚本只是删除文件，没有清理菜单和权限，那么反复安装卸载之后，后台权限表会越来越脏。

把安装、卸载、菜单、权限这四个点单独拎出来复查，能避开大部分由 AI 生成带来的隐性缺陷。

3.5 5 分钟到底从哪里挤出来的

很多人听到“5 分钟聊出一个插件”会觉得夸张。实际上这个时间不是指所有插件，而是指一类结构清晰、单表管理、没有复杂业务逻辑的后台插件。

手动开发一个这样的插件，经验丰富的开发者可能也要 20 到 30 分钟，新手可能要更久。耗时主要花在：

想清楚目录结构和类名规范
手写重复的增删改查代码
注册菜单和权限
处理安装脚本和表单视图

而用 Skill 约束后，AI 负责把重复部分快速产出，省掉的主要是打字和查规范的时间。你真正要花时间的，是第一步把需求描述准确，以及最后一步把生成结果验证一遍。

所以合理的理解是：5 分钟是“需求明确 + 规范可复用 + 插件结构简单”情况下的收益，不是所有场景都能复制。

4. 生成的插件不能只看“安装不报错”，要按四步验证

4.1 安装环节：先确认能被后台识别

第一步验证很简单：把生成的插件目录放到项目对应的插件目录下，刷新 Fastadmin 后台的插件管理页面，看能不能识别到。

识别不到是最常见的问题。此时不要急着改代码，也不要重复刷新。先做三个检查：

插件目录名和入口文件里的类名是否一致。
入口文件所在路径是否符合本项目的插件规范。
文件和目录权限是否正常，尤其是 Linux 服务器。

如果本地开发环境是 Windows，权限问题通常不明显，但一旦部署到 Linux，目录不可写、类文件大小写不匹配这类问题就会立刻暴露。

识别到之后，点击安装。安装成功后要确认数据库表是否创建，后台菜单是否有新增，权限规则表里是否出现了对应节点。如果这些都没有发生，基本可以判断安装脚本没生效。

4.2 功能环节：把增删改查逐个点一遍

安装完成不代表功能可用。我把这一步叫“最小路径测试”。

至少要按顺序验证：

列表页能不能打开。
新增一条公告，保存后列表是否出现。
编辑这条公告，修改内容后能否保存。
把状态从启用切换到停用。
删除这条公告。

测试时建议使用一些特殊字符和超长文本。比如在内容里输入包含英文引号、中文引号、换行、HTML 标签的文本，再观察保存和展示是否正常。

如果页面提交后报 500，先去看 Fastadmin 的运行日志和 PHP 错误日志。不要只看前端报错，很多问题出在 SQL 字段名与表单字段名不一致。

4.3 权限环节：让普通管理员也看一下

这一步容易被漏掉，因为超级管理员账号通常会绕过很多权限判断。

如果你只想自己用，可能忽略也没关系。但只要这个插件要给其他管理员用，就必须验证权限。

Fastadmin 的按钮和菜单通常会根据权限节点来控制显示。即使插件安装成功，普通管理员如果没有拿到对应权限，进入列表页后可能看不到新增、编辑、删除按钮。

我一般会用两个账号测试：一个是超级管理员；一个是新建的普通管理员，并只给它分配这个插件相关的权限。然后看普通管理员能不能完成完整操作。

如果普通管理员看不到菜单，先检查角色权限分配是否勾选了新节点。如果看到菜单但按钮缺失，那多半是控制器里没有给每个操作方法注册正确的权限标识。

4.4 代码环节：检查硬编码和隐藏风险

AI 生成的代码还有一个需要注意的点：容易把只在当前环境成立的假设写死。

安装 SQL 里直接写死fa_表前缀，模板里写死http://localhost绝对地址，控制器里引用当前环境存在但项目里并没有引入的类，这些都是我实际碰到过的问题。

我会用文件搜索功能快速查一下几个关键词：

fa_：确认表前缀有没有被写死。
localhost或127.0.0.1：确认地址是否绝对化。
file_put_contents、shell_exec、eval：确认有没有多余的命令执行逻辑。
require和include：确认引用的路径是否存在。

生成代码里出现安全敏感函数不一定是坏事，但如果一个简单公告管理插件用不上这些函数，那更可能是 AI 在多此一举。

5. 把经验沉淀成可复用 Skill 的模板思路

5.1 Skill 不是越智能越好，而是“约束越明确越好”

很多人以为 Skill 应该是一段长篇大论，写得越多 AI 越懂。我实际测下来的感觉恰恰相反，约束比篇幅更重要。

所谓约束，是你明确告诉 AI 什么能做、什么不能做、先做什么、后做什么、输出必须包含什么。比如“先输出文件结构，不要直接给代码”就是一种强约束。AI 遵守这类约束后，结果稳定性会明显上升。

Skill 的真正价值不在于让 AI 更聪明，而在于减少试错次数。同样的需求，没有 Skill 时可能要来回改四五十次；有 Skill 之后可能两三轮就能定型。

5.2 Skill 里值得维护的六个模块

我建议用六个模块来组织 Skill。

模块	作用	示例
角色定位	让 AI 明确自己的工作身份	你是熟悉 Fastadmin 插件机制的后台开发助手
开发目标	明确本次任务交付物	生成一个可以直接安装的 Fastadmin 管理插件
输入要求	写代码前必须先确认哪些信息	插件英文名、表名、字段列表、是否含前台
输出规范	代码输出要遵守什么格式与顺序	先文件结构，再 SQL，再分段代码
禁止事项	哪些地方不许乱写	不要写死表前缀，不要省略权限注册
验证清单	安装和功能验收标准	安装成功、菜单出现、增删改查可用

每个模块不用很长，写清楚核心规则就行。这个文件的维护成本才是重点。

5.3 一个简化版 Skill 文件示例

下面是一份简化模板，适合作为起步版本。你可以直接复制到 Markdown 文件里，再根据自己项目的 Fastadmin 版本来调整。

# Fastadmin Plugin Skill Template ## Role 你是熟悉 PHP 和 Fastadmin 后台插件机制的高级开发助手。 ## Goal 根据用户的业务描述，生成一个可以安装的 Fastadmin 后台管理插件。 ## Input Required 开始写代码前，先让用户确认： - 插件英文标识 - 数据库表名 - 业务字段列表 - 是否需要前台展示 - 是否需要附件、权限细分、操作日志 ## Output Rules 1. 先输出文件结构和数据库表设计，确认后再写代码。 2. 插件文件按照项目现有可运行插件的目录规范组织。 3. 数据表前缀使用项目配置，不要直接写死。 4. 数据库时间字段建议包含 createtime 和 updatetime。 5. 后台菜单和权限节点必须在安装脚本中注册，卸载时清理。 6. 控制器、模型、视图按照 Fastadmin 的路由和目录约定命名。 ## Forbidden - 不要输出只适合普通 ThinkPHP 项目的代码。 - 不要遗漏安装、卸载逻辑。 - 不要在模板中使用绝对后台链接。 - 不要在安装 SQL 中假设所有项目都使用 fa_ 前缀。 ## Verification Checklist - 插件能出现在后台插件列表中并成功安装。 - 数据表创建成功，菜单和权限节点出现。 - 新增、编辑、删除、状态修改全部可用。 - 普通管理员分配权限后能看到入口并完成操作。 - 卸载后菜单、权限、数据表能按预定逻辑清理。

请把上面内容当成骨架，而不是固定标准。不同 Fastadmin 项目对插件目录、权限注册方式、数据库配置的做法可能略有不同，你要以本地项目作为最终校准标准。

5.4 Skill 要跟着项目迭代

Skill 不是写一次就完事。我的习惯是每次用 AI 生成完一个插件后，把新踩到的坑沉淀成一条规则加进去。

比如某次发现 AI 生成的视图里引用了不存在的静态资源，我就会在禁止事项里加一条：“不要引用项目里不存在的静态文件路径。”再比如某次 AI 把表单提交地址写成了绝对 URL，我就加一条：“后台链接和表单提交必须使用项目相对地址。”

持续维护一段时间后，Skill 会越来越贴合你手头的 Fastadmin 项目，后续开发同一个类型的插件，返工率会明显下降。

6. 翻车点与排查顺序

6.1 先看现象，再动代码

遇到问题，不要第一反应让 AI 重新生成全部代码。很多问题不是代码写错了，而是缓存、权限、路径或环境导致。

Fastadmin 项目在安装插件后，如果菜单没刷新，你可以先清缓存再看。如果 Linux 下文件权限不对，再好的代码也跑不起来。如果表前缀配错，SQL 执行时就会报错。

我把这类问题叫“假 Bug”：现象看起来是代码质量差，实际是环境或前置条件没准备好。

6.2 常见问题清单

下面是我生成 Fastadmin 插件时遇到频率最高的问题，按现象整理成一张表。

现象	常见原因	优先排查方向
后台插件列表看不到新插件	目录名、入口文件类名不一致，目录放错位置	路径、类名、大小写
点击安装直接报错或 404	插件目录权限不足，入口文件依赖缺失	目录权限、PHP 日志
安装成功但数据表没创建	install.sql 未正确执行，表前缀不一致	安装脚本、数据库前缀
安装成功但后台菜单没出现	菜单注册逻辑缺失或权限缓存未刷新	安装脚本、缓存更新
页面能打开但样式全乱	静态资源目录未复制，路径引用错误	资源文件、模板地址
新增内容后列表为空	字段名不一致，控制器 read 方法筛选错误	表单字段、控制器逻辑
删除或状态操作无权限	权限节点未注册或角色未分配	权限规则、角色配置

6.3 通用排查顺序

如果真的翻车了，我一般按下面这个顺序排查，基本能定位 90% 的问题：

先看后台和 PHP 错误日志，确定是代码报错还是功能逻辑不对。
清缓存、刷新权限，排除旧数据干扰。
检查插件目录是否被正确识别，文件路径与入口类名是否一致。
检查数据库表前缀和字段名，看 SQL 是否正常执行。
在浏览器里打开列表页和表单页，看 URL 是否符合 Fastadmin 路由规范。
对照项目里一个已经能用的插件，逐个对比差异。

这套顺序不复杂，但能帮你避免“反复让 AI 改代码却仍然无效”的情况。

6.4 让 AI 帮你排查时的提问方式

如果你决定把报错内容交给 AI 分析，不要只贴一句“页面报错”或“500”。

比较好的提问方式是包含这些信息：

Fastadmin 版本或项目的大致来源。
插件目录结构是怎么组织的。
报错页面 URL 和操作步骤。
后台日志里的完整报错信息。
是安装失败、菜单不出现，还是增删改查某个环节失败。

给的信息越完整，AI 越容易判断问题。否则它也只能一边猜一边改，效率很低。

7. 边界与优化建议

7.1 AI 生成的是“初稿”，不是“交付物”

用 AI 生成 Fastadmin 插件，最舒服的一点是省掉了大量重复劳动，最危险的一点是你可能因为省事而放弃人工复核。

我现在依然会把 AI 生成的代码当作初稿，而不是直接投入生产。安装能跑通、页面能展示，只代表这个插件在测试环境里过了基础链路，不代表它已经适合你的真实业务场景。

真实场景里还有前端权限控制、字段校验、数据过滤、附件处理、操作日志、并发提交等问题。这些工作可以交给 AI 辅助，但最终把关的应该是你自己，或者有经验的同事。

7.2 哪些任务不适合先交给 AI

如果插件涉及复杂的表单联动、多表事务、审批流、订单状态机、财务管理，我建议先不要用“聊一个插件”的方式整体生成。

这类业务的问题在于需求本身需要不断澄清，AI 在初始对话中很难完整理解。一旦业务逻辑产生偏差，返工成本远高于你手动开发。

更合理的做法是：把复杂任务拆细，先让 AI 生成其中确定的那部分，比如字典管理、文件上传组件、日志列表。复杂业务的核心逻辑，仍然由人工先设计好，再让 AI 按设计实现。

7.3 真正值得投入时间的地方

用了一段时间之后，我最大的感受是：能稳定压缩开发时间的，不是 AI 聊天本身，而是你沉淀下来的 Skill 和需求整理能力。

如果你也准备在 Fastadmin 项目里引入 AI 工作流，我会建议先从一个小插件开始，把 Skill 建起来，跑通一次完整流程，再逐步把它复制到其他后台管理模块上。先花时间把一个最小流程走扎实，比一次性追求复杂模板更重要。

最后留一句我自己排查时的习惯：插件目录能识别、安装能通过、数据表能生成，只代表代码结构没问题。真正决定这个插件是不是稳定的，永远是你对业务边界、权限分配和异常输入的检查是否到位。