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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意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 建起来跑通一次完整流程再逐步把它复制到其他后台管理模块上。先花时间把一个最小流程走扎实比一次性追求复杂模板更重要。最后留一句我自己排查时的习惯插件目录能识别、安装能通过、数据表能生成只代表代码结构没问题。真正决定这个插件是不是稳定的永远是你对业务边界、权限分配和异常输入的检查是否到位。