自动生成插件开发

如果您已经知道插件系统怎么工作，但不想每次都从空文件开始手写，那么“自动生成插件”就是最适合的开发入口。

它不是一个泛用聊天窗口，而是一个专门面向 Saber Translator 插件系统的 AI Agent。它会围绕当前插件契约、当前插件目录和当前任务目标来工作。

---

这项功能更适合什么时候用

比较适合的场景：

• 想快速生成一个小型后处理插件原型
• 已经知道要改哪个步骤，但不想从零手写
• 想修改现有插件，并保留原有目录结构
• 想先让 Agent 帮您搭骨架，再自己微调

不太适合的场景：

• 需求本身还非常模糊
• 想一次生成一个很大的复杂系统
• 想让插件替换整套主程序逻辑

简单理解：

• 需求越明确，Agent 越容易一次生成接近预期的代码
• 目标越小、越具体，成功率通常越高

---

它的工作方式

从使用流程看，自动生成插件大致会经历这几步：

1. 选择模式：新建插件或修改现有插件
2. 配置 Agent 的服务商、API Key、模型与调用参数
3. 用自然语言描述需求
4. Agent 先给出方案说明
5. 您确认后锁定目标插件
6. Agent 在该插件目录内执行
7. 系统做结构校验
8. 刷新插件列表

为什么要先锁定目标

这是为了让 Agent 只围绕当前插件目录工作，减少误改其他插件的风险，也让生成结果更稳定。

---

两种工作模式怎么选

模式	适合场景
新建插件	从零做一个新插件
修改现有插件	在已经存在的插件上继续改动

推荐经验：

• 如果您只是想验证一个新思路，优先用“新建插件”
• 如果您已经有一个能跑的插件，只想扩展它，优先用“修改现有插件”

---

怎么描述需求更容易成功

最推荐的描述模板是：

要做什么 + 作用在哪个步骤 + 在哪些模式下生效 + 具体规则 + 结果要怎么体现

例如：

• 做一个 after_ocr 插件，在 standard 和 hq 模式下，把每条 OCR 文本首尾空格去掉，并把中文省略号统一成三个点
• 做一个 after_translate 插件，只在 standard 模式下，把译文中的“你这家伙”统一替换成“你这人”
• 做一个 before_render 插件，在所有模式下强制开启描边，并把描边颜色统一成黑色
• 修改现有插件，保留原来的逻辑，只额外支持 proofread 模式

这样写的好处是：

• Agent 更容易选对步骤
• 更不容易把 translate 和 ai_translate 混淆
• 您后续也更容易检查生成结果是否符合预期

---

新建插件时的推荐流程

第一次使用时，建议按下面这个顺序来：

1. 先做一个很小的插件
2. 只改一个步骤
3. 只让它影响一个明显可见的结果
4. 先在少量图片上测试
5. 确认流程跑通后，再逐步增加复杂规则

推荐的第一批练手目标：

• after_translate 追加测试后缀
• after_ocr 去掉首尾空格
• before_render 强制开启描边
• after_ai_translate 给 HQ 结果追加标记

---

生成后先检查什么

不要把“生成完成”直接等同于“可以投入正式使用”。

推荐至少检查下面这些点：

1. 元数据是否完整

优先看：

• plugin_id
• display_name
• supported_steps
• supported_modes
• failure_policy

2. 步骤选得对不对

例如：

• 普通翻译后处理应该更偏向 after_translate
• 高质量翻译或 AI 校对后处理应该更偏向 after_ai_translate
• 样式统一通常更偏向 before_render

3. 返回值是否符合契约

重点看：

• before_* / after_* 是否返回 None 或 dict
• 是否误返回字符串、数组等不兼容类型

4. 改的是不是规范字段

例如：

• 改 OCR 结果时，优先看 original_texts 与 ocr_results
• 改普通翻译结果时，优先看 translated_texts
• 改 HQ 结果时，优先看 results 里的气泡 translated

5. 是否真的在正确模式下触发

例如：

• after_translate 不适合拿 hq 去测
• after_ai_translate 不适合拿普通翻译去测

---

什么时候建议改回手写

如果出现下面这些情况，建议把 Agent 产出的代码当作草稿，再自己接着写：

• 需求已经变得很复杂
• 一个插件里开始同时处理很多步骤
• 您需要非常细致地控制字段和错误处理
• 您已经知道自己想怎么实现，只是想先让 Agent 搭骨架

比较稳的方式通常是：

1. 让 Agent 先生成第一版
2. 自己检查步骤、模式和字段
3. 再手动补充细节
4. 刷新插件并做小范围验证

---

推荐把 Agent 当成什么

更准确的理解不是“让 AI 全自动写完插件”，而是把它当成：

• 插件脚手架生成器
• 当前契约下的代码助理
• 帮您快速搭第一版结构的工具

它最擅长的是：

• 快速建目录和基本模板
• 根据需求先选出合适 Hook
• 生成最小可运行版本
• 在现有插件上做局部修改

它不一定最擅长的是：

• 一次生成非常复杂的完整业务逻辑
• 替您做最终质量判断

---

一条很实用的建议

如果您希望 Agent 更稳定，描述需求时尽量直接写出步骤名。

例如相比：

• 帮我做一个插件，优化翻译结果

更推荐：

• 帮我做一个 after_translate 插件，只在 standard 模式下，把译文中的“……”统一改成“...”

前一种说法需要 Agent 先猜您的意图，后一种说法已经把目标边界说得很清楚了。

---

继续深入

如果您想把自动生成插件和手写开发结合起来，建议这样读：

1. 插件开发总览
2. 从零创建第一个插件
3. Hook 与数据契约
4. 再回到这一页，用 Agent 做更高效的迭代

这样效果通常会比“完全不了解契约就直接让 Agent 写”稳定很多。