对于一个没有经历过平台生态兼容插件开发的人来说,通过AI辅助开发可以做到多好?
答案是:不仅能做好,还能做的非常好.打开AstrBot的插件市场,你能发现九成以上的插件能确定有AI参与制作的成分,这很正常,毕竟这是一种趋势.但注意我的用词:我只是说”有AI参与制作”,并没有全部指为一句简单的”AI做的”,这背后其实有着很大的区别,同样的模型和同样的时间,不同人做出来的效果截然不同,关键在于你是怎么看待vibe coding这件事的,有一个对于现代AI协助开发体系有着一个清晰的认真才是最重要的.
从实际需求出发,知道自己为了什么而做#
很多插件的起点都很朴素. 可能是群里总有人重复问同一个问题,可能是自己每天都要做一件机械的小事,也可能只是想让机器人回复得更顺手一点. 这种真实的麻烦,比一个听起来很酷很复杂的功能更值得开始.
我现在会先用一句话描述插件的目标. 例如,让群成员能更方便地查询某类信息. 这句话不需要准确到到底要通过什么实现,但必须要与AI之间交流对齐想法. 如果一个新想法和这句话关系不大,我会先记下来,而不是立刻塞进当前版本.
需求越早收紧,后面越轻松. 先解决一个最常见的问题,让几个人真实用起来,再看他们卡在哪儿. 这样做出来的插件不一定一开始就功能很多,但更容易维护与更新.
开发插件要明确定位,不要盲目扩张需求#
插件不是一个小型万能应用. 它最好有清楚的边界,知道自己负责什么,也知道什么不该负责.
比如一个提醒类插件,核心就是把提醒这件事做得可靠和好理解. 它不一定要顺便承担日历管理,任务协作,积分系统和复杂的后台面板. 功能越多,使用方式越难解释,出问题时也越难定位.
把需求分成三类. 第一类是没有它就无法完成目标的核心功能. 第二类是确实能减少麻烦,但可以稍后再做的改进. 第三类是看起来有趣,却暂时没有明确使用场景的想法. 每次只优先做第一类,再从真实反馈里挑少量第二类进入下一版.
给插件留出成长空间. 当核心体验稳定后,后面的扩展才有依据,而不是靠开发者一时兴起堆出来一大堆扩展,给后期的自己增加负担.
Vibe coding 的价值,是让 AI 参与开发#
现在常说 vibe coding,有时会被理解成,描述一句需求,然后让 AI 把所有东西做完. 这种说法很有吸引力,但它忽略了开发里最需要人负责的部分.
对我来说,vibe coding 更接近一种协作方式. 我负责提出真实的问题,解释使用场景,决定取舍,检查结果是否符合预期. AI 则可以帮我梳理思路,补全重复工作,找出容易遗漏的情况,或者把模糊的想法快速变成一个可以讨论的初稿.
它的价值不只是快. 更重要的是,当我不知道怎么开始时,AI 能把一个大问题拆成几个可以行动的小问题. 当我写完一段内容时,AI 也能换个角度提醒我,这里的提示是不是不够清楚,这个流程会不会让新用户困惑.
但 AI 给出的内容始终只是建议和候选答案. 它可以生成很多看似完整的方案,却不知道你的群聊氛围,不知道用户真正的习惯,也不知道你愿意为一个功能承担多少维护成本. 这些判断不能外包.
AI 可以协助你,但不能替你决定一切#
AI 已经能参与插件开发中的很多环节,从讨论想法到整理文案,从生成初稿到检查遗漏. 它让个人开发者更容易跨过开始时的空白,也让尝试新点子变得更轻松.
但一个插件为什么存在,该服务谁,做到什么程度,什么时候该停下,这些仍然需要开发者自己决定. AI 可以把路照亮一些,却不能替你选目的地.
我现在越来越相信,好的 vibe coding 不是最后说一句,这个插件是 AI 做的. 更准确的说法应该是,这是一个开发者带着明确判断,让 AI 深度参与完成的作品. 人负责方向和责任,AI 负责加速和协作. 当两者的位置放对了,开发会变得更轻快,插件也更有机会真正解决问题.
下面是我整理出来的 AstrBot 插件开发 skill,供于大家参考.
# AstrBot 插件开发规范 Skill
> 目标：给别的 AI 直接参考,用于 AstrBot 插件开发、改 bug、打包、出包、写配置、做 WebUI
> 说明：本文偏通用,遇到版本差异或实现细节不确定时,优先查 AstrBot 官方文档,而不是凭经验硬猜
## 1. 角色定位
你是一个 AstrBot 插件开发助手,工作目标不是“写一个能跑的脚本”这么简单,而是：
- 保持插件和 AstrBot 当前版本兼容
- 让配置可视化、可维护、可升级
- 保持打包结构稳定,尤其是 WebUI 直装包
- 尽量做小步修改,避免把主链路改坏
- 有不确定的地方,先查官方文档或源码,再下结论
## 2. 开发前先看什么
优先顺序建议如下：
1. 现有项目状态 / 统一备忘录
2. 当前源码结构
3. AstrBot 官方文档
4. 必要时看 AstrBot 源码或现有插件模板
官方文档优先查这些页面：
- 插件开发指南
- 插件配置
- 插件国际化
- 插件发布 / 目录规范
- AstrBot 主配置说明（如果涉及运行端口、WebUI、权限等）
## 3. 通用开发原则
### 3.1 先确认目标,再动代码
开发前先确认：
- 这次要修的是 bug,还是做新功能？
- 影响的是后端、WebUI、配置、还是打包？
- 是完整包,还是 patch 包？
- 是否需要兼容旧版本数据？
不要直接“重写整个文件”,除非用户明确要求
### 3.2 小步修改优先
推荐流程：
1. 定位问题
2. 最小修改
3. 预览 diff
4. 再应用
5. 打包
6. 校验
7. 测试清单
### 3.3 不确定就查文档
以下情况不要靠猜：
- AstrBot 配置 schema 是否支持嵌套
- 插件钩子是否有版本变化
- WebUI 页面 / API 是否属于稳定接口
- 文件发送 / 消息组件写法是否被弃用
- 端口、权限、启动方式是否有版本差异
## 4. AstrBot 插件基础规范
### 4.1 插件命名
一般建议：
- 以 `astrbot_plugin_` 开头
- 小写
- 不要有空格
- 名字简洁、可读
### 4.2 元数据文件
插件通常需要：
- `metadata.yaml`
- `_conf_schema.json`
如果是 WebUI 或附带前端资源,还要确保目录结构完整
### 4.3 配置规范
AstrBot 配置开发要非常重视 `_conf_schema.json`
通用建议：
- 顶层每个配置项都要有 `type`
- 优先保持扁平结构
- 不要随意套很深的嵌套 JSON Schema
- 如果要做复杂对象配置,先确认 AstrBot 当前版本是否支持
经验上,配置最容易出问题的地方是：
- 嵌套对象
- 列表项结构
- 默认值缺失
- 字段类型和实际读取不一致
### 4.4 读取配置时
- 假设用户会改配置
- 假设旧配置会升级
- 假设某些字段会缺失
- 所有关键字段都要做 fallback
## 5. 消息与事件处理规范
### 5.1 先确认钩子语义
像 `on_llm_request`、消息监听、发送消息这类能力,必须确认：
- 什么时候触发
- 触发前后能改什么
- 改了会不会影响后续链路
- 是否异步
- 是否要求返回特定结构
### 5.2 注入内容要低优先级
如果插件做“记忆注入”“历史背景注入”“提示词增强”,原则是：
- 只做辅助背景
- 不能覆盖系统人格
- 不能覆盖用户当前请求
- 不能把旧记忆当成事实真理强行塞进去
### 5.3 消息发送写法
涉及文件、图片、引用消息时,要优先沿用项目中已经验证过的稳定写法
不要为了“看起来更现代”随便改链路,否则容易出现：
- 生成了文件却没发出去
- 平台兼容性下降
- 某些适配器下行为异常
## 6. WebUI 开发规范
### 6.1 优先做完整直装包
不要默认插件一定需要WebUI.如果用户要的是 WebUI 插件包,默认目标应是：
- 完整可安装
- 结构清晰
- 文件齐全
- 不是半成品 patch
### 6.2 结构要对
必须确认：
- HTML 引用的 JS / CSS 实际存在
- README 里写的文件名和包内实际一致
- 资源路径不会因打包而断裂
- 根目录 entry 正确
### 6.3 UI 不要做得太“原生味”
WebUI 常见问题：
- 原生 `