自从有了 AI，我已经很久没写博客了。
倒不是完全没有东西可写，只是过去那些需要专门记录的问题，如今大多可以直接丢给 AI。问题解决了，答案也留在对话里，我便渐渐觉得没什么值得再整理成博客。
最近，我折腾了一圈 AI 编程工具，又从 IDE 一路走进终端，最后还用 pi 给自己写了个插件。这些经历未必需要被当成知识保存下来，但其中确实有一些有趣的东西值得分享。于是，我又打开了这篇博客。
从 IDE 插件开始
2026 年 4 月以前，我一直在用 AI 辅助编程。
那时的 AI 还不太值得完全信任，我也不敢把整个项目交给它，只会让它做一些边界明确的工作，比如补全一个函数、实现一段局部逻辑。这样即使它写偏了，我也能把影响范围控制在一个方法之内。
我是 Java 开发，最初用的是 IntelliJ IDEA 里的通义灵码，后来换成了 Qoder。
到了 4 月初，我明显感觉到 AI 编程发生了翻天覆地的变化。它不再只是一个更聪明的补全工具，而是开始具备理解项目、拆解任务、调用工具和连续完成工作的能力。继续把它限制在 IDE 的侧边栏里，多少有些浪费。
与此同时，我也越来越难以忍受 IDEA 在 AI 编程体验上的滞后，以及它庞大的内存开销。于是我转向了 Qoder 客户端。它一眼看上去就是 VS Code 的亲戚；说白了，从那一刻起，我也算正式投入了 VS Code 的怀抱。
装上一系列插件以后，开发体验并不逊色于 IDEA。
从 Qoder 到 Claude Code，再到 OpenCode
真正的改变发生在 Qoder 涨价之后。
我先尝试了 Trae，但它又卡又慢，使用体验并不理想。至于 CLI 工具，我此前一直没有认真尝试，原因也很简单：看不到足够明确的边界，总担心自己难以掌控 AI 写下的代码。
但工具在变，模型也在变，我的工作流不可能永远停在原地。到了这个阶段，我开始认真思考：如果 AI 已经能够承担越来越完整的编码任务，那么我是否还需要把 IDE 当作整个开发流程的中心？
于是，我换成了 VS Code + Claude Code CLI。
用了一段时间后，新的问题又出现了：模型切换不够方便。虽然有 CCSwitch，但同时使用多个厂商时，配置和切换依旧麻烦。后来，我又被 OpenCode Go 相对便宜的套餐吸引，再加上出于我个人对 A/ 的一点偏见——虽然他们的实力确实很强——最终转向了 OpenCode。
有了 Plannotator 插件以后，我越来越少直接编写代码，VS Code 也渐渐只剩下“打开项目看一眼”的作用。到这里，我忽然发现：IDE 还在舞台中央，但真正的主角早就换人了。
当 IDE 不再是中心
于是我又转向了 Neovim。
一方面，我需要一个启动更快、更轻量的编辑器；另一方面，经过这段时间的摸索，我也逐渐形成了一套属于自己的 AI 编码方式。我的主要工作不再是逐行输入代码，而是描述目标、补充约束、审查结果，并在 AI 偏离方向时及时纠正。
AI 的代码生成速度当然重要，但任务如何拆分、上下文如何提供、结果如何验证，才是开发者必须掌握的部分。
AI 编程减少了很多重复、琐碎的“垃圾时间”，也确实提升了我的工作效率，但它并没有缩短我的工作时间，反而让我投入得更久了。区别在于，以前有限的时间常常被消耗在机械劳动上；现在，我可以把省下来的时间用来尝试一些原本只停留在脑海里的想法。对本就没有太多空闲时间的我来说，这可能才是 AI 编程最实际的价值。
体验过 Neovim 极致的个性化以后，我越来越确信：工具应该适应人，而不是反过来要求人适应工具。恰好这时，OpenCode 的启动速度也越来越慢，于是我开始寻找一个更轻、更自由，也更容易改造成自己想要模样的 AI 编程工具。
最后，我遇到了 pi。
为什么是 pi
pi 对自己的定位很克制：一个极简的终端编程代理框架。
它默认只提供必要的能力，让模型读取文件、执行命令、精确编辑或写入代码；同时支持多家模型供应商，可以在终端里直接切换模型和思考等级。会话会自动保存，还能通过树状历史回到任意节点继续，长会话也可以压缩上下文。
但这些都不是最吸引我的地方。
pi 真正让我喜欢的，是它没有试图替所有人规定一套“正确工作流”。很多工具会把计划模式、子代理、权限确认、待办列表等功能全部内置进去；pi 则选择保持核心简洁，把决定权留给使用者：需要什么，就通过扩展、技能、提示词模板和主题加上什么。
它不要求所有人接受同一种使用方式，而是提供足够开放的接口，让每个人都能按照自己的需求继续改造。
它的扩展系统能做什么
pi 的扩展本质上是 TypeScript 模块，不需要修改 pi 源码，也不必先经历一套复杂的编译流程。把扩展放到全局的 ~/.pi/agent/extensions/，或者项目里的 .pi/extensions/，就可以自动加载；开发过程中还可以通过 /reload 热重载。
扩展能做的事情很多，例如：
- 注册新的工具，让模型能够调用你自己的能力；
- 注册命令和快捷键，改造交互方式；
- 监听会话、模型、消息和工具调用等事件；
- 在危险命令执行前增加确认，或者保护敏感路径；
- 在编辑器上下方增加组件，替换状态栏、页脚甚至编辑器本身；
- 自定义上下文压缩、Git 检查点、远程执行和沙箱；
- 实现计划模式、子代理，甚至在等待模型时运行游戏。
官方文档里有一句很能概括 pi 的态度：让 pi 适应你的工作流，而不是让你的工作流适应 pi。
这也是我从 IDEA、Qoder、Claude Code、OpenCode、Neovim 一路折腾过来，最后真正想要的东西。它不是功能最多的那个，却给我留下了最多可以自己决定的空间。
我给自己写了一个插件
当然，选择一个高度自由的工具，也意味着你迟早会开始给它添东西。
在使用 pi 的长会话时，我遇到了一个很具体的问题：对话一长，AI 的回答和工具输出会占据大量屏幕空间。我经常看到某段回答，却一时想不起它对应的是我的哪一个问题，只能向上翻找。
于是我写了 current-question，一个把最近问题固定显示在编辑器上方的 pi 扩展。
它默认展示最近 5 条问题，每条只占一行；过长的内容会自动截断，并正确处理中文这类双宽字符。通过 Vim 风格的快捷键，可以在历史问题之间切换，也可以展开某一轮，查看完整问题和对应回答。
除了查看，它还支持：
- 复制选中轮次的完整问题与回答；
- 带着这段问答上下文打开外部编辑器，继续组织下一条回复；
- 根据终端高度自动调整展开区域，避免长内容让界面抖动；
- 在
/tree、会话压缩等操作之后，继续与当前会话状态保持一致。
安装也很简单：
# 全局安装
pi install npm:@zzs-fun/current-question
# 或仅安装到当前项目
pi install -l npm:@zzs-fun/current-question
这个插件并不复杂，也不是什么能“重新定义 AI 编程”的宏大项目。它只是解决了我每天都会遇到的一点不便。
但这恰好就是 pi 最吸引我的地方：当工作流里出现一粒沙子时，我不必等待官方某天把它列进路线图，也不用 fork 整个项目。我可以直接告诉 pi 自己需要什么，再和它一起把扩展写出来。
从发现问题到拥有工具，中间不再隔着一个版本周期。一个困扰自己的小问题，也可以很快变成真正可用的工具。
最后
回头看，我并不是单纯地从一个编辑器换到另一个编辑器，也不是从一个 AI 客户端换到另一个 AI 客户端。我真正改变的，是自己在编程过程中的位置。
以前，我负责写代码，工具负责辅助；现在，我更多地负责定义问题、提供上下文、约束过程和验收结果，而 AI 负责执行其中越来越多的步骤。
这并不意味着开发者不再需要编码能力。恰恰相反，只有真正理解代码，才能判断 AI 是在可靠地解决问题，还是只是看起来信心十足，却悄悄把 bug 藏进下一次提交。
如果你也在用 pi，或许你也不必急着寻找一套别人定义好的“最佳实践”。先从自己工作流里最不舒服的那个细节开始，写一个命令、一个快捷键，或者一个小插件。
毕竟，最适合你的工具，未必是功能列表最长的那个。
它应该是最像你自己的那个。
P.S. 文字由 AI 整理，内容来自我。AI 只是替身，意志属于本体。
