优化 4 个细节,AI 驾驭 GitHub 开源工具稳了

上一篇我试了一下：

👉 我试着让 AI 自动用这个字幕工具，居然跑通了

最终结果很现实：

✔ 流程能跑通

❌ 但极不稳定，经常乱选开源工具、直接翻车

😅 一个很真实的问题

我一开始以为：

只要把 GitHub 开源工具列表丢给 AI，它就能自动看懂、精准匹配、乖乖调用。

真正落地实践才发现完全不是一回事：

👉 一堆 GitHub 开源工具摆在面前，AI 胡乱匹配

👉 明明有现成开源工具不用，偏要自己瞎编答案

👉 调用开源工具时参数乱填、格式崩坏，程序直接解析失败

根本达不到日常自动化使用的标准。

实测踩坑：用 AI 调度 GitHub 开源字幕神器——Video-subtitle-extractor，3 个致命问题

1️⃣ 放着 GitHub 开源工具不用，AI 硬偷懒

给任务：

帮我给这个视频生成字幕

明明有 GitHub 开源工具 extract_subtitle 可以直接用。

但 AI 经常耍小聪明：

不调用任何开源工具，直接凭空编一段假字幕，完全脱离实际工具能力😂

2️⃣ 多 GitHub 开源工具扎堆，AI 疯狂选错

当我一次性放入多个常用 GitHub 开源工具：

extract_subtitle 视频字幕提取
translate_text 文本翻译
summarize_text 内容总结

问题瞬间暴露：

明明要调用字幕类开源工具，偏偏跑去选翻译工具
需求稍微复杂，就乱混搭各种 GitHub 工具完全没有匹配逻辑。

3️⃣ 调用 GitHub 工具参数乱写一通

就算侥幸选对了开源工具，参数照样翻车：

少必填字段
参数名拼写错误
JSON 格式错乱换行

后端根本识别不了，GitHub 开源工具再好用也白搭。

一句话总结：别高估 AI，它根本不会自动理解、适配你的 GitHub 开源工具池。

🧠 优化 4 个细节，AI 驾驭 GitHub 这个开源工具稳了

针对以上问题，我没有更换模型，而是从 Prompt 工程和工具定义上下手，做了以下改进：

1. 工具描述要“精准化”，拒绝模糊

最开始我图省事，描述写得很简单：

extract_subtitle：处理视频

这种模糊描述，AI 根本无法匹配适用场景。后来我改成了精准定义 + 输入输出 + 适用场景的结构化描述：

工具名：extract_subtitle功能：从视频文件中提取原始字幕文本输入参数：video (string, 必填) - 视频文件路径输出结果：带时间戳的 SRT 格式文本适用场景：当用户需要获取视频中的文字内容、制作双语字幕或进行视频内容分析时，必须优先使用此工具。

改动后，工具的语义匹配准确率直接翻倍。

2. 硬性约束：设立“防火墙”

在 System Prompt 中加入一条强规则，治好了 AI“偷懒编答案”的毛病：

你必须严格从给定的工具列表中选择工具来解决问题。严禁在没有调用工具的情况下直接回答用户关于视频内容的具体问题。如果你不知道如何操作，请返回错误信息，而不是编造数据。

这一步强制 AI 走工具调用流程，杜绝了幻觉。

3. 固定输出格式：只认 JSON

不再让 AI 自由发挥，强制限定唯一的输出结构，并要求只输出纯 JSON，不包含 Markdown 标记（如 json ... ）或任何解释性文字。

这样后端程序可以直接 JSON.parse，无需正则清洗，极大提升了系统的鲁棒性。

4. 给标准调用示例，AI 照抄就不会错

这是最关键的一点。AI 很擅长模仿，直接给它一个标准的 Few-Shot 示例：

用户输入：帮我提取 demo.mp4 的字幕预期输出：{  "action": "extract_subtitle",  "args": {    "video": "demo.mp4"  }}

有了这个“样片”，AI 出错率大幅下降。

📈 改完之后的效果

✔ 基本能选对工具
✔ 很少再乱输出
✔ 稳定性提升很多

当然：

👉 还不算“智能”，但已经能用了

我现在有个很直观的感受：

很多时候不是模型不行，而是工具定义、Prompt 规则、输出约束没设计好。往后做 AI Agent，工具描述+规则设计本身就是一门硬核技术。

🚀 下一步准备做什么

接下来我准备试一个更有意思的东西：

👉 不只调用一个工具

而是：

提取字幕
自动翻译
最后输出整理好的内容

也就是：

👉 让 AI 一次完成多个步骤

如果能跑通，那基本就不是“单工具”了 👀

（如果你也在尝试让 AI 用工具，这一步应该也会踩到这些坑）