ScriptIrc 新手开发指南

——如何把想法变成 AI 真正能执行的提示词

如果你是第一次接触 ScriptIrc，很可能会有一个感觉：

“我知道我想要什么，但我不知道该怎么跟 AI 说。”

这其实是很正常的。
因为 ScriptIrc 不是在考你会不会写代码，而是在考一件更偏工程的事情：

你能不能把需求说清楚。

---

一、先转一下思维：你不是在写代码

用 ScriptIrc 时，有一个非常关键的心态转变：

• 你不是在“实现功能”
• 你是在“定义规则”

你描述的不是 if else、不是事件监听、不是数据结构
而是：

• 什么时候
• 谁
• 在什么条件下
• 允许 / 不允许 / 发生什么

只要你能把这些说清楚，剩下的实现细节，本来就该交给 AI。

---

二、开发提示词，本质是一份“规则说明”

一个好的 ScriptIrc 开发提示词，读起来应该像这样：

“我在给另一个开发者交代需求”

而不是：

“我在给机器下指令”

所以语气上完全可以是自然的、有上下文的，而不是冷冰冰的命令。

比如你可以放心写：

• 我希望这个功能是可配置的
• 管理员需要有单独的权限
• 普通玩家和管理员的行为不一样

这些话对人有意义，对 AI 也一样有意义。

---

三、提示词要“结构化”，但不是“死板模板”

你不需要写成严格的文档格式
但一定要有逻辑层次

一个很实用的思路是：
从“是什么”到“谁能用”再到“能不能关”

一个通用的脑内顺序

你在心里可以按这个顺序想：

1. 这个插件 / 脚本是干嘛的
2. 哪些玩家会被影响
3. 有没有例外（管理员、权限）
4. 有没有配置项
5. 有没有开关 / 指令

你不需要真的编号写出来
但内容上要覆盖到

---

四、关键词要“少而稳”，不要一次塞太多细节

ScriptIrc 非常吃 关键词质量，但不吃关键词数量。

这里有一个很好用的原则：

一个关键词 = 一个“变化点”

什么是变化点？

• 是否开启 / 关闭
• 数值是否可配置
• 行为是否因权限不同而不同

比如你提到：

• 敏感词
• 发言频率
• 禁言
• 记录

这些都不是“实现细节”，而是系统维度

你只需要点出来
AI 会自动补齐合理实现

---

五、提示词要“多条件，少细节”

这是 ScriptIrc 非常重要的一点。

什么叫多条件

多条件指的是 规则分支，比如：

• 普通玩家 vs 管理员
• 开启状态 vs 关闭状态
• 满足条件 vs 不满足条件

这些一定要说清楚
因为它们决定了行为边界

---

什么叫少细节

少细节指的是：

• 不限定具体实现方式
• 不绑定具体 API
• 不写“如何判断”“怎么存”

你只需要说：

• 需要记录
• 需要判断
• 需要限制

AI 天然就会往“合理插件实现”去靠。

---

六、提示词“序列化”，不是“碎片化”

这里的序列化不是指 JSON
而是指：

你的描述是可以被拆成一条一条规则的

一个好的提示词，AI 在内部大概会拆成：

• 一条监听规则
• 一条权限判断
• 一条配置读取
• 一条指令逻辑

如果你写得足够清晰
AI 自然就能拆对

一个很实用的小技巧

你可以在心里问自己一句话：

“我这段话，能不能拆成几条‘如果……那么……’”

如果能
那大概率是一个好提示词

---

七、不要怕“留白”，这是给 AI 发挥的空间

很多人会下意识想：

“我是不是要把所有情况都想全？”

其实不用。

ScriptIrc 的优势就在于：

• AI 会补齐常见边界
• AI 会遵循服务器插件的常识
• AI 会主动生成合理的指令结构

你只需要把你真正关心的规则说清楚。

---

八、插件开发提示词示例（可直接套用思路）

这些示例不是功能成品，而是**“提示词成品”**。
目标只有一个：让 AI 在插件层面理解你的需求边界。

---

示例一：聊天管理类插件（基础规则型）

我需要开发一个聊天管理插件

插件用于在玩家发送聊天消息时进行统一管理

功能需要对普通玩家生效，拥有指定权限的玩家不受影响

插件需要提供一个总开关指令，用于开启或关闭该功能

相关规则与提示内容需要支持在配置文件中修改

这个提示词没有限定实现方式
但已经清楚说明了：

• 插件类型：聊天管理
• 影响范围：玩家维度
• 权限分层：普通 / 特权
• 控制方式：指令 + 配置

---

示例二：带时间限制的插件（冷却 / 频率类）

我想实现一个用于限制玩家行为频率的插件

当玩家在短时间内重复触发指定行为时，插件需要阻止本次行为

行为冷却时间需要支持配置

管理员或拥有指定权限的玩家不受该限制

插件需要提供指令用于开启或关闭该限制功能

被限制时仅提示玩家当前操作过于频繁，不产生其他影响

这种提示词非常适合：

• 发言频率
• 指令冷却
• 交互防刷

---

示例三：带记录能力的插件（数据型）

我需要一个用于记录玩家行为的插件

插件需要在玩家触发指定行为时进行记录

记录内容需要与玩家身份关联

插件需要提供查询指令

普通玩家只能查看与自己相关的记录

管理员可以查看所有玩家的记录

记录数据需要持久化保存，并在服务器重启后依然有效

这里你已经把 数据生命周期 交代清楚了
AI 会自然选择合理的存储方式。

---

示例四：带状态与自动处理的插件

我想开发一个具备状态管理能力的插件

插件需要为玩家维护某种状态信息

状态可以被添加、移除、查询

状态信息需要记录到配置或数据文件中

当状态满足特定条件时，插件需要自动触发对应处理逻辑

管理员可以通过指令查看所有玩家的状态列表

这类提示词非常适合：

• 禁言
• 黑名单
• 白名单
• 限制状态

---

九、插件开发提示词模板（推荐直接套用）

下面是一个高度通用的插件提示词模板，适合 80% 的 ScriptIrc 插件需求。

---

通用插件提示词模板

我需要开发一个 【插件类型】 插件

插件主要用于 【核心功能描述】

该插件需要对 【目标玩家范围】 生效

拥有 【权限节点】 的玩家不受限制 / 具备额外功能

插件需要提供指令用于 【开启 / 关闭 / 管理 / 查询】

插件的关键参数需要支持在配置文件中进行调整

当触发相关规则时，插件需要给予玩家明确的提示反馈

你只需要把【】里的内容换掉
一个合格的插件提示词就完成了。

---

十、进阶模板：多条件插件提示词结构

当插件开始复杂起来，可以使用“条件块”思路：

插件需要根据不同条件产生不同行为

对普通玩家与管理员行为不同

在功能开启与关闭状态下行为不同

在满足与不满足规则条件时处理方式不同

所有条件判断结果需要有明确的玩家提示

这种写法对 AI 非常友好
因为它天然就是插件逻辑结构。

---

十一、一句经验总结

写 ScriptIrc 插件提示词时，你只需要记住一句话：

描述“规则边界”，而不是“实现步骤”

当你的提示词读起来像一份插件需求说明
而不是一段伪代码
那它大概率就是一个高质量提示词。