最近一直在针对自己的使用场景配置 gptel，写了一些 gptel-tools，分享一下自己的使用经验。
先说一下不适合使用 tools 的场景。一般来说，如果 LLM 不需要用户返回结果，就不要用 tools，比如我之前一直在用的：
我现在就觉得不太好用，也不知道是不是我 prompt 的原因，涉及到调用 tools 的时候，LLM 智商都不太高 
，很容易瞎 / 不调用 tools，所以能不用 tools 就不用 tools。
这种情况完全可以自己用 gptel-request 糊一层胶水处理返回的消息。
一些需要用户返回信息的例子就是 fetch 类的 tools，其中我觉得比较好用的是这个 read-documentation。不知道是不是 elisp 训练量没有特别大，LLM 很容易瞎编函数。如果在 prompt 里面加入 “You should actively read the documentation in Emacs to check your code." 之类的字眼配合这个 tool，LLM 就会自动读 Emacs 的文档看这次的主要函有没有调用对。
另一类我觉得可以发掘潜力的是 debug 类，大概就是执行程序 + 返回 debug log 让 LLM 去 debug，不过我没太去深究这部分。
然后关于写 tools 方面，最好把 tools 写成场景化的大函数，然后自己在 elisp 里面拆分逻辑。这样做主要是，LLM 似乎不太会链式调用 tools，比如说有 get_project_root 和 list_directory 这两个 tools，我告诉 LLM 可以用 get_project_root 来获取项目根目录，然后再递归地用 list_directory 来获取整个项目的结构，但它就不会调 
。
这时候最好写一个 get_project_tree 的大 tool，再在 elisp 里面自己拆分逻辑。不要一下子拆成 get_project_root list_directory 两个 tools。
关于模型方面，我觉得比较好的是 Gemini 2.5 Pro，Gemini 2.0 Flash 会频繁瞎调 tools。
一些题外话：
- 为了用 LLM，我改变了一些习惯。比如说我以前喜欢把文件都分得很细，现在基本把大功能都放在同一个文件，在里面再抽象，这样比较方便直接把 buffer 当 context 发出去。现在我 Emacs 配置都在一个
init.el里面 - 还在用 aider，但如果 gptel 功能都糊得差不多可能就弃了，感觉 aider 跟 Emacs 联动不太紧密。比如说我得告诉 aider 在哪个档案改哪个函数，感觉不如我
find-file然后 gptel 顺手，但感觉 repomap 这个可以抄抄（Emacs 不也有内置 treesit）。