oh-my-pi：AI 编码的胜负手，正在从模型转向 harness

can1357/oh-my-pi 把一个容易被忽略的问题摆到了台面上：AI 编码工具的质量并不只由模型决定。读文件方式、patch 格式、LSP 接入、浏览器观测、调试器、子任务管理、上下文压缩，每一层都会改变模型最终能交付什么。

这类项目的价值不在“又多一个 CLI”，而在展示一套完整 harness 如何把模型接到真实工程现场。模型负责推理，harness 负责让推理接触到正确事实，并把修改安全地落到文件系统和测试结果里。

harness 是工程控制面

传统评测喜欢比较模型回答；真实开发更关心修改是否一次落地、错误能否定位、重构是否保持引用、长任务能否不中断。oh-my-pi 的 README 和文档把这些问题拆成工具层：read、search、edit、LSP、debug、browser、Python/Bun worker、MCP、skills、memory。

这说明它的产品判断更接近“编码运行时”，不是“模型聊天壳”。工程团队评估它时，也应该按运行时评估：权限、可观测性、可恢复性、工具失败策略、上下文成本，而不是只看界面是否顺手。

为什么 LSP 和 debugger 重要

Agent 改代码最危险的地方，是把语言语义降级成字符串替换。LSP 可以把引用、重命名、诊断、符号跳转重新带回来；debugger 可以把运行时证据带回来。两者共同减少“看起来像对的 patch”。

这会改变工作分配。简单修文案用任何工具都可以；跨文件重命名、并发 bug、前端布局错位、Go 服务 hang、Python 数据处理异常，则需要 Agent 能调用 IDE 和 debugger 级别的工具。

组织采用建议

• 先在非生产仓库试运行，观察 diff 质量、测试习惯和失败恢复。
• 把可写目录、shell 权限、浏览器权限、凭据注入边界写清楚。
• 要求每个任务留下 evidence：改了哪些文件、跑了什么命令、失败重试原因。
• 关注 release 频率带来的升级收益和回归风险，必要时 pin 版本。

结论

oh-my-pi 的意义是把 AI 编码从“模型调用”推进到“开发者工具系统”。未来更强的 coding agent 很可能不是单点模型，而是模型、语言服务、调试器、浏览器、记忆和安全策略组合出来的工作台。