拓冰网站定制 
FastAdmin 社区最近有个很典型的现象开发者用 AI 写插件得到一大段 PHP看起来格式完整复制到addons/目录后点“安装”就报错或者页面 404。问题通常不在 PHP 语法而是 FastAdmin 是一个很吃“约定”的框架——目录结构、类名大小写、数据库前缀、后台菜单规则、前端表格 URL 都得对齐。AI 没有这些上下文时写出来的代码就是“代码层面正确、工程层面不可用”。这篇文章想分享的不是又一段泛泛的 prompt而是一种把 FastAdmin 插件开发规则沉淀成 AI Skill 的实践。我把 FastAdmin 的目录规范、字段约定、SQL 规范和安装检查项写进一个skill.md让大模型在“聊插件需求”时直接按规则输出。整套流程跑顺之后生成一个可安装的后台管理插件只需要一次对话、一次文件复制再在 FastAdmin 后台点一次安装。下面会讲清楚 Skill 的设计思路、规则怎么写、完整示例和排错方法。1. 先给结论FastAdmin 插件开发天生适合做成 AI Skill先说判断FastAdmin 这种以“约定生成”为核心的 PHP 后台框架比普通 PHP 项目更适合用 AI 来生成代码前提是你要把框架约定完整交给模型。如果你是刚接触 FastAdmin 的开发者可能觉得 AI 对话生成插件已经很方便。但真正在项目里工作过的人会发现FastAdmin 的插件开发难点从来不是“写逻辑”而是“守规矩”。比如插件主类文件名必须和目录名形成驼峰对应关系控制器里方法名必须和前端 URL 通过固定规则绑定数据库表通常要支持__PREFIX__占位符避免默认前缀变动导致 SQL 失败后台页面返回 JSON 的字段格式要和前端table.js预期一致菜单与权限规则要在auth_rule表里注册。这些规矩在官方文档里分散在不同页面而大模型在训练时会把 FastAdmin 和其他 ThinkPHP 项目混在一起。你在对话框里说“帮我写一个插件”模型只能凭概率推断结果经常会生成一套通用 ThinkPHP 代码而不是 FastAdmin 可安装插件。因此我更推荐用 Skill 解决“场景缺失”的问题。Skill 的本质是一份长期复用的任务协议它把项目背景、命名规范、输出结构和自检清单固化下来每次对话都让 AI 从这份协议出发而不是从“大模型的模糊记忆”出发。2. FastAdmin 插件到底难在哪里约定比语法更重要2.1 一个标准插件包的文件结构长什么样FastAdmin 的 addons 插件一般有固定的目录骨架。简单理解插件就是一个带安装、卸载、配置能力的模块目录。我第一次把插件需求交给 AI 时模型生成的目录和 FastAdmin 实际需要的目录经常对不上。FastAdmin 项目里插件目录的结构看起来类似your-fastadmin-project/ ├── addons/ │ └── demo_notice/ │ ├── DemoNotice.php │ ├── config.php │ ├── bootstrap.js │ ├── install.sql │ ├── uninstall.sql │ ├── controller/ │ ├── model/ │ └── view/ ├── application/ ├── public/ └── docs/其中DemoNotice.php是插件主类它负责声明插件的名称、版本、描述并在安装/卸载时提供逻辑入口。install.sql和uninstall.sql处理数据库变更。bootstrap.js通常用于让前端模块感知插件存在。如果这些文件缺失或名称大小写不一致后台插件管理列表可能根本识别不出这个插件识别出来也会在安装阶段报错。很多 AI 生成工具会忽略config.php和bootstrap.js只给你一个控制器文件。控制器没问题但插件系统无法把它当可用插件加载这就是“聊出的代码不能落地”的一个重要原因。2.2 表格AI 写 FastAdmin 插件时最容易出问题的位置容易出错的位置常见错误后果插件主类类名和目录名驼峰形式不一致插件无法被识别SQL 前缀直接写死fa_没有使用__PREFIX__换了表前缀就报错控制器命名空间把插件控制器写成app\admin\controller路径不匹配路由 404AJAX 返回格式随意返回数组或字符串列表页表格数据解析失败菜单规则没有提供权限规则初始化逻辑插件安装后后台看不到入口卸载脚本直接删除表没有考虑已有数据生产环境误删风险高2.3 稳定插件的 5 个维度在把 “稳定” 作为 Skill 生成目标之前我先定义了什么是“稳定”。这里不是指代码 bug 少而是指以下五个维度都过关能识别插件目录放在addons/后后台插件管理列表能看到。能安装安装 SQL 能正确执行表前缀被正确替换。能访问生成的后台页面 URL 和控制器路由一致不出现 404。能操作列表、新增、编辑、删除等操作的数据格式符合 FastAdmin 前端容器预期。能回滚卸载脚本不会报错且不会误删非授权数据。这个定义很关键。因为 AI 无法判断自己生成的代码是否“稳定”Skill 的价值就在于把上述维度变成可执行的检查清单。3. Skill 和普通提示词的区别不是“上下文”而是“工作流”很多人以为 Skill 就是把一大段背景知识塞给 AI类似自定义系统指令。但其实 Skill 更接近“工作流定义”而不只是“角色设定”。举个例子普通提示词可能是这样的你是一个 FastAdmin 开发专家帮我写一个公告管理插件。这种提示词的缺点很明显模型只能依赖内部知识无法保证它记得 FastAdmin 的表前缀规则也无法保证它输出的控制器符合 FastAdmin 前端表格 JS 的调用格式。每次对话都要重新描述一次项目里的新成员也无法复用同一套经验。而 Skill 可以是一个结构化文件。它不仅有“背景知识”还定义了模型接到需求后的处理顺序比如先解析用户的功能需求整理出需要的数据库字段根据install.sql模板生成建表语句按控制器输出格式生成 PHP 逻辑输出安装检查清单。这一个流程对应的就是人类开发者写插件的真实习惯先建表再写控制器再接入前端最后验证。AI 在 Skill 的约束下不再“想到哪写到哪”而是按一套已验证的步骤工作。如果用一句话概括提示词是让模型“知道”Skill 是让模型“做到”。FastAdmin 和 Skill 的组合之所以高效是因为 FastAdmin 的核心工作方式就是“把重复开发流程标准化”。FastAdmin 的一键生成 CRUD本质上就是把建表、生成控制器、生成视图、生成 JS 的流程自动化。AI Skill 做的事情与它同构只不过把规则从 FastAdmin 源码里搬到了模型提示上下文中。4. 环境准备让 AI 拥有插件开发的“项目语境”在动手写 Skill 之前需要先准备两个环境。4.1 FastAdmin 项目环境本文不限定具体版本请以你自己的 FastAdmin 项目为准。 FastAdmin 基于 ThinkPHP 5运行环境通常需要 PHP 7.x同时要能够正常配置伪静态和后台登录。你可以先准备一个干净的本地测试项目不要在正式生产环境直接做插件安装实验。如果你使用的 AI 客户端可以读取项目目录建议把 FastAdmin 项目的源码目录加入 AI 的工作区。这样模型可以直接查看addons/目录下已有插件的真实结构生成的代码会更有参考性。4.2 Skill 文件存放目录Skill 是一个纯文本目录不依赖 FastAdmin 自身的插件机制。为了便于用 git 管理推荐放在项目中如下位置your-fastadmin-project/ └── docs/ └── skills/ └── fastadmin-plugin/ └── skill.md把 Skill 放进项目仓库有几层好处团队其他人拉取代码后可以直接复用同一套插件生成规则FastAdmin 版本升级后可以提交增量修改AI 客户端在工作区里能读取该文件不需要每次复制粘贴一大段内容。不同 AI 工具对 Skill 目录的读取方式不一样。如果你的工具不支持自动读取最简单的方式是把skill.md的完整内容作为首条系统提示发送给模型。效果差别不大核心在于内容质量。5. 开发 Skill 的核心过程把 FastAdmin 经验变成规则文件下面是我整理一个 FastAdmin 插件生成 Skill 时的主要流程。你也可以按这个逻辑改造出适合作者自己项目的 Skill。5.1 第一步收集项目里的“硬性约定”所谓硬性约定是指那些一旦写错就会导致插件不可用的规则。我在自己的skill.md里至少固定了以下内容插件标识只能使用小写字母、数字、下划线主类文件名必须由插件标识驼峰化后得到插件表 SQL 中的前缀必须使用__PREFIX__占位后台管理页面中模型保存失败时要返回模型错误而不是简单返回false控制器继承自 FastAdmin 提供的后台基类确保权限、登录态、日志等能力可用。你不需要一开始就写全所有规则可以从报错中逐步补充。比如“AI 生成的插件在安装时提示表不存在”就把“SQL 前缀规则”加入 Skill“AI 生成的页面列表 URL 不对”就把“前端列表 URL 生成规则”加入 Skill。5.2 第二步给模型定义输出格式FastAdmin 插件不像普通 GitHub 项目那样只有代码还需要生成 SQL、控制器、模型、视图、JS。如果模型分不清先后顺序输出就会乱。我习惯让模型在生成前先输出一个“文件清单”结构大致如下addons/demo_notice/ ├── DemoNotice.php ├── config.php ├── install.sql ├── uninstall.sql ├── controller/ │ └── Notice.php ├── model/ │ └── Notice.php └── view/ └── notice/ ├── index.html ├── add.html └── edit.html先让模型列出文件结构有助于检查它是否理解了需求。这个文件结构本身也可以作为一个模板固化成 Skill 里的“默认工程结构”。5.3 第三步设置自检清单Skill 文件最后要包含一个“交付前自检”清单。AI 生成完代码后必须逐项确认插件主类名是否和插件目录名一致SQL 文件中的表前缀是否使用了__PREFIX__控制器中定义的 URL 是否和前端 JS 中的 URL 一致是否提供了安装和卸载方法视图文件是否存在于对应的目录代码中是否没有包含删除生产数据的危险逻辑。这一步非常重要。有了自检清单AI 在生成代码时就会主动规避明显问题而不是等开发者安装时才发现。6. 完整示例用一份 Skill 生成公告管理插件下面我会演示一个比较典型的 FastAdmin 插件开发场景生成一个公告后台管理插件。这里的重点是展示 Skill 如何约束 AI让最终生成结果具备“可安装”基础。6.1 用户与 AI 的对话输入在配置好 Skill 的 AI 客户端里只需要输入一句话需求 FastAdmin插件开发：用AI Skill固化约定，一次生成可用插件
FastAdmin 社区最近有个很典型的现象开发者用 AI 写插件得到一大段 PHP看起来格式完整复制到addons/目录后点“安装”就报错或者页面 404。问题通常不在 PHP 语法而是 FastAdmin 是一个很吃“约定”的框架——目录结构、类名大小写、数据库前缀、后台菜单规则、前端表格 URL 都得对齐。AI 没有这些上下文时写出来的代码就是“代码层面正确、工程层面不可用”。这篇文章想分享的不是又一段泛泛的 prompt而是一种把 FastAdmin 插件开发规则沉淀成 AI Skill 的实践。我把 FastAdmin 的目录规范、字段约定、SQL 规范和安装检查项写进一个skill.md让大模型在“聊插件需求”时直接按规则输出。整套流程跑顺之后生成一个可安装的后台管理插件只需要一次对话、一次文件复制再在 FastAdmin 后台点一次安装。下面会讲清楚 Skill 的设计思路、规则怎么写、完整示例和排错方法。1. 先给结论FastAdmin 插件开发天生适合做成 AI Skill先说判断FastAdmin 这种以“约定生成”为核心的 PHP 后台框架比普通 PHP 项目更适合用 AI 来生成代码前提是你要把框架约定完整交给模型。如果你是刚接触 FastAdmin 的开发者可能觉得 AI 对话生成插件已经很方便。但真正在项目里工作过的人会发现FastAdmin 的插件开发难点从来不是“写逻辑”而是“守规矩”。比如插件主类文件名必须和目录名形成驼峰对应关系控制器里方法名必须和前端 URL 通过固定规则绑定数据库表通常要支持__PREFIX__占位符避免默认前缀变动导致 SQL 失败后台页面返回 JSON 的字段格式要和前端table.js预期一致菜单与权限规则要在auth_rule表里注册。这些规矩在官方文档里分散在不同页面而大模型在训练时会把 FastAdmin 和其他 ThinkPHP 项目混在一起。你在对话框里说“帮我写一个插件”模型只能凭概率推断结果经常会生成一套通用 ThinkPHP 代码而不是 FastAdmin 可安装插件。因此我更推荐用 Skill 解决“场景缺失”的问题。Skill 的本质是一份长期复用的任务协议它把项目背景、命名规范、输出结构和自检清单固化下来每次对话都让 AI 从这份协议出发而不是从“大模型的模糊记忆”出发。2. FastAdmin 插件到底难在哪里约定比语法更重要2.1 一个标准插件包的文件结构长什么样FastAdmin 的 addons 插件一般有固定的目录骨架。简单理解插件就是一个带安装、卸载、配置能力的模块目录。我第一次把插件需求交给 AI 时模型生成的目录和 FastAdmin 实际需要的目录经常对不上。FastAdmin 项目里插件目录的结构看起来类似your-fastadmin-project/ ├── addons/ │ └── demo_notice/ │ ├── DemoNotice.php │ ├── config.php │ ├── bootstrap.js │ ├── install.sql │ ├── uninstall.sql │ ├── controller/ │ ├── model/ │ └── view/ ├── application/ ├── public/ └── docs/其中DemoNotice.php是插件主类它负责声明插件的名称、版本、描述并在安装/卸载时提供逻辑入口。install.sql和uninstall.sql处理数据库变更。bootstrap.js通常用于让前端模块感知插件存在。如果这些文件缺失或名称大小写不一致后台插件管理列表可能根本识别不出这个插件识别出来也会在安装阶段报错。很多 AI 生成工具会忽略config.php和bootstrap.js只给你一个控制器文件。控制器没问题但插件系统无法把它当可用插件加载这就是“聊出的代码不能落地”的一个重要原因。2.2 表格AI 写 FastAdmin 插件时最容易出问题的位置容易出错的位置常见错误后果插件主类类名和目录名驼峰形式不一致插件无法被识别SQL 前缀直接写死fa_没有使用__PREFIX__换了表前缀就报错控制器命名空间把插件控制器写成app\admin\controller路径不匹配路由 404AJAX 返回格式随意返回数组或字符串列表页表格数据解析失败菜单规则没有提供权限规则初始化逻辑插件安装后后台看不到入口卸载脚本直接删除表没有考虑已有数据生产环境误删风险高2.3 稳定插件的 5 个维度在把 “稳定” 作为 Skill 生成目标之前我先定义了什么是“稳定”。这里不是指代码 bug 少而是指以下五个维度都过关能识别插件目录放在addons/后后台插件管理列表能看到。能安装安装 SQL 能正确执行表前缀被正确替换。能访问生成的后台页面 URL 和控制器路由一致不出现 404。能操作列表、新增、编辑、删除等操作的数据格式符合 FastAdmin 前端容器预期。能回滚卸载脚本不会报错且不会误删非授权数据。这个定义很关键。因为 AI 无法判断自己生成的代码是否“稳定”Skill 的价值就在于把上述维度变成可执行的检查清单。3. Skill 和普通提示词的区别不是“上下文”而是“工作流”很多人以为 Skill 就是把一大段背景知识塞给 AI类似自定义系统指令。但其实 Skill 更接近“工作流定义”而不只是“角色设定”。举个例子普通提示词可能是这样的你是一个 FastAdmin 开发专家帮我写一个公告管理插件。这种提示词的缺点很明显模型只能依赖内部知识无法保证它记得 FastAdmin 的表前缀规则也无法保证它输出的控制器符合 FastAdmin 前端表格 JS 的调用格式。每次对话都要重新描述一次项目里的新成员也无法复用同一套经验。而 Skill 可以是一个结构化文件。它不仅有“背景知识”还定义了模型接到需求后的处理顺序比如先解析用户的功能需求整理出需要的数据库字段根据install.sql模板生成建表语句按控制器输出格式生成 PHP 逻辑输出安装检查清单。这一个流程对应的就是人类开发者写插件的真实习惯先建表再写控制器再接入前端最后验证。AI 在 Skill 的约束下不再“想到哪写到哪”而是按一套已验证的步骤工作。如果用一句话概括提示词是让模型“知道”Skill 是让模型“做到”。FastAdmin 和 Skill 的组合之所以高效是因为 FastAdmin 的核心工作方式就是“把重复开发流程标准化”。FastAdmin 的一键生成 CRUD本质上就是把建表、生成控制器、生成视图、生成 JS 的流程自动化。AI Skill 做的事情与它同构只不过把规则从 FastAdmin 源码里搬到了模型提示上下文中。4. 环境准备让 AI 拥有插件开发的“项目语境”在动手写 Skill 之前需要先准备两个环境。4.1 FastAdmin 项目环境本文不限定具体版本请以你自己的 FastAdmin 项目为准。 FastAdmin 基于 ThinkPHP 5运行环境通常需要 PHP 7.x同时要能够正常配置伪静态和后台登录。你可以先准备一个干净的本地测试项目不要在正式生产环境直接做插件安装实验。如果你使用的 AI 客户端可以读取项目目录建议把 FastAdmin 项目的源码目录加入 AI 的工作区。这样模型可以直接查看addons/目录下已有插件的真实结构生成的代码会更有参考性。4.2 Skill 文件存放目录Skill 是一个纯文本目录不依赖 FastAdmin 自身的插件机制。为了便于用 git 管理推荐放在项目中如下位置your-fastadmin-project/ └── docs/ └── skills/ └── fastadmin-plugin/ └── skill.md把 Skill 放进项目仓库有几层好处团队其他人拉取代码后可以直接复用同一套插件生成规则FastAdmin 版本升级后可以提交增量修改AI 客户端在工作区里能读取该文件不需要每次复制粘贴一大段内容。不同 AI 工具对 Skill 目录的读取方式不一样。如果你的工具不支持自动读取最简单的方式是把skill.md的完整内容作为首条系统提示发送给模型。效果差别不大核心在于内容质量。5. 开发 Skill 的核心过程把 FastAdmin 经验变成规则文件下面是我整理一个 FastAdmin 插件生成 Skill 时的主要流程。你也可以按这个逻辑改造出适合作者自己项目的 Skill。5.1 第一步收集项目里的“硬性约定”所谓硬性约定是指那些一旦写错就会导致插件不可用的规则。我在自己的skill.md里至少固定了以下内容插件标识只能使用小写字母、数字、下划线主类文件名必须由插件标识驼峰化后得到插件表 SQL 中的前缀必须使用__PREFIX__占位后台管理页面中模型保存失败时要返回模型错误而不是简单返回false控制器继承自 FastAdmin 提供的后台基类确保权限、登录态、日志等能力可用。你不需要一开始就写全所有规则可以从报错中逐步补充。比如“AI 生成的插件在安装时提示表不存在”就把“SQL 前缀规则”加入 Skill“AI 生成的页面列表 URL 不对”就把“前端列表 URL 生成规则”加入 Skill。5.2 第二步给模型定义输出格式FastAdmin 插件不像普通 GitHub 项目那样只有代码还需要生成 SQL、控制器、模型、视图、JS。如果模型分不清先后顺序输出就会乱。我习惯让模型在生成前先输出一个“文件清单”结构大致如下addons/demo_notice/ ├── DemoNotice.php ├── config.php ├── install.sql ├── uninstall.sql ├── controller/ │ └── Notice.php ├── model/ │ └── Notice.php └── view/ └── notice/ ├── index.html ├── add.html └── edit.html先让模型列出文件结构有助于检查它是否理解了需求。这个文件结构本身也可以作为一个模板固化成 Skill 里的“默认工程结构”。5.3 第三步设置自检清单Skill 文件最后要包含一个“交付前自检”清单。AI 生成完代码后必须逐项确认插件主类名是否和插件目录名一致SQL 文件中的表前缀是否使用了__PREFIX__控制器中定义的 URL 是否和前端 JS 中的 URL 一致是否提供了安装和卸载方法视图文件是否存在于对应的目录代码中是否没有包含删除生产数据的危险逻辑。这一步非常重要。有了自检清单AI 在生成代码时就会主动规避明显问题而不是等开发者安装时才发现。6. 完整示例用一份 Skill 生成公告管理插件下面我会演示一个比较典型的 FastAdmin 插件开发场景生成一个公告后台管理插件。这里的重点是展示 Skill 如何约束 AI让最终生成结果具备“可安装”基础。6.1 用户与 AI 的对话输入在配置好 Skill 的 AI 客户端里只需要输入一句话需求