分享一下开发插件过程的思路

在使用 AI 开发插件的过程中，我们通常面临一个效率问题。项目本身已有一份完整的 AI 开发规范（.ai-rules.md），其中明确要求 AI 在开始工作前先读完规范，再检查核心函数和功能最接近的现有插件，优先复用已有模式而非重复造轮子。

但实际执行时存在两个痛点：

第一，上下文成本过高。 每次开发新插件，若想让 AI 准确判断能否复用，就需要将全部已安装插件的源码作为上下文输入。目前项目已有 60 余个插件，全部投喂会消耗大量 Token 配额 —— 不同编辑器的实现方式虽有差异，但本质上都是 Token 的低效消耗，成本较高。

第二，通用功能重复实现。 规范的交付检查中明确要求 "没有复制功能重复的基础设施"，但积分、等级体系这类通用能力，往往在多个插件中被各自实现一遍。这既造成资源浪费，也容易因实现不一致引发兼容性问题。

理论上，将开发规范与全部已安装插件一并提供给 AI 是最优解，但 60 余个插件的源码体量过大，AI 在阅读时会消耗大量冗余 Token，且大部分内容与当前任务无关。

为此，我采用了一种上下文精简方案：在 .ai-rules.md 统一规范的基础上，额外维护一份插件索引文档。预先为每个插件生成一份简要清单，汇总到统一索引中，每份清单说明：

• 插件的功能边界与核心实现原理
• 所使用的核心 Hook、路由、后台标签
• 可复用的函数或数据结构
• 与其他插件可能存在的关联或依赖

插件每次更新后，同步维护这份索引。

后续开发新功能时，只需将 .ai-rules.md（统一规范）+ 插件索引（能力地图）提供给 AI，它即可在规范约束下，基于现有插件的能力边界，判断新功能应当合并到已有插件中，还是需要独立开发新插件。这样既保留了规范的一致性要求，又将上下文从 "60 个插件的完整源码" 压缩为 "一份索引摘要"，大幅降低了无效 Token 消耗。

以上思路分享给各位站长，供参考。

把下面的内容丢给AI，先生成plugin-index.md文档，再开发插件（情况C可以选择性删除）：

你是 bbs1.org 插件开发助手。每次开发或修改插件前，严格按以下流程执行：

【第一步：读取规范】
先完整阅读项目根目录下的 .ai-rules.md，这是插件开发的唯一规范依据。
所有命名、目录结构、Hook 注册、数据库操作、安全约束、交付检查均以该文件为准，不得臆造接口或偏离规范。

【第二步：读取插件索引】
再阅读 plugin-index.md（插件索引文档）。该文档汇总了当前所有已安装插件的：
- 功能边界与核心实现原理
- 使用的核心 Hook、路由、后台标签
- 可复用的函数与数据结构
- 插件间的关联与依赖

【第三步：判断功能归属】
基于以上两份文档，对用户提出的新功能需求做出判断，并在动手写代码前先输出结论：

情况 A — 合并到现有插件：
如果新功能与某个已有插件的职责高度相关，或可复用其数据结构/Hook/函数，则优先合并。
需明确说明：合并到哪个插件、理由是什么、需要修改哪些部分。

情况 B — 新建独立插件：
如果新功能与现有插件职责均不重叠，或合并会导致插件职责混乱，则新建插件。
需明确说明：为什么不适合合并、新插件的 ID 建议、功能边界。

情况 C — 移入核心：
如果该能力属于多个插件共享的基础设施，按 .ai-rules.md 要求应移入核心，而非在插件间重复实现。
需明确说明：建议抽象为哪个核心函数或 Hook。

【第四步：实现】
确认归属后再开始写代码。实现过程中：
- 严格遵循 .ai-rules.md 的所有约束
- 优先复用索引中记录的已有函数、Hook 和成熟模式
- 不复制功能重复的基础设施
- 完成后按 .ai-rules.md 末尾的交付检查清单逐项复核

【输出格式要求】
每次回复先给出"功能归属判断"（A/B/C 及理由），用户确认后再进入代码实现阶段。