你让AI改一个文件名，它可能改了文件本身，却漏掉其他地方的引用；程序崩溃后，它也可能只会反复加打印语句猜原因。oh-my-pi（OMP）想解决的正是这种“会写代码，却看不清整个工程”的问题：把IDE——集编辑、跳转、检查和调试于一体的开发工具——直接接进编码Agent的执行循环。
所谓执行循环，就是模型不断观察、规划、调用工具，再检查结果。IDE能力进入其中后，Agent不仅能读写文本，还能根据代码关系、编译错误和程序运行现场调整下一步。这个方向值得关注，因为它把竞争焦点从“模型会不会生成代码”，推向“模型能否像开发者一样使用完整工作台”。本文数字与功能均来自项目仓库截至供稿时的自述，尚无独立信源交叉验证。
不只搜索文本，还要理解代码关系
OMP由Stencil Labs开发，fork自Mario Zechner的Pi。AIE Talks与Der Standard Podcast提供的故事材料显示，Pi原本强调极小、易读、方便改造的核心；OMP则走向另一端，把IDE、调试器和大量工具装回Agent循环。同一个起点，由此分出“极简可塑”和“开箱全配”两条路线。
项目自述支持60多家模型提供方，内置31个工具、14项LSP操作和28项DAP操作，Rust核心约8万行。LSP（Language Server Protocol）是编辑器获取定义跳转、引用关系和错误诊断的通用协议。借助它，Agent执行重命名时，可以在文件移动前处理重新导出、汇总文件和别名引用，而不是只做字符串替换。
DAP（Debug Adapter Protocol）则让编辑器连接不同调试器。按仓库给出的例子，OMP可以连接lldb检查崩溃的C程序，连接dlv查看卡住的Go服务，或通过debugpy暂停并检查Python进程。说白了，它试图让Agent进入“案发现场”，而不是隔着日志猜问题。
编辑格式也会决定模型表现
OMP还强调一个容易被忽略的变量：工具怎样把修改任务交给模型，以及怎样接收修改结果。仓库宣称，其编辑格式让Grok Code Fast 1的一项未命名指标从6.7%升至68.3%；Gemini 3 Flash相对str_replace提高5个百分点；Grok 4 Fast因减少错误diff引发的重试，token用量下降61%；MiniMax在相同权重和prompt下，pass rate达到2.1倍。
这些数字提示，编码Agent的效果不只取决于模型本身。工具接口若让模型频繁输出无效修改，再强的模型也会把时间和token耗在返工上。不过，仓库没有说明这些测试的benchmark、样本规模、模型具体版本、运行参数和统计方法，“metric”与部分pass rate的含义也不清楚，因此不能把它们当作已获独立验证的普遍结论。
为什么现在值得看
OMP展示的是一种更完整的产品形态：代码理解、调试、持久化Python与Bun运行环境、多Agent分工、独立审阅模型、协作会话和网页搜索，被收进同一个执行界面。它还支持macOS、Linux和Windows，要求Bun不低于1.3.14，并提供安装脚本、Homebrew、Bun、Nix和mise等安装方式。bash、zsh与fish的补全脚本则根据实时命令和参数元数据生成，避免文档与实际命令脱节。
项目的开放方式也在试验中。OMP曾要求贡献者获得“担保”后才能提交Pull Request，目前暂时向所有人开放，未来是否恢复尚未确定。这不只是管理细节，也反映出编码Agent普及后，开源项目如何接纳贡献、同时控制低质量提交的新难题。
局限与未知
- “冲榜”只有单日新增371星的编辑部选题依据；材料没有提供具体榜单、名次、统计日期或第三方数据，不能据此断言OMP已登上某个榜单。
- 功能数量、代码规模与效果数字都来自项目仓库自述，可能随版本快速变化。
- 四组模型效果缺少可复现实验细节。它们适合视为产品团队给出的方向性证据，而非模型能力排名。