快速修复两者同源不同命令，文档与教程混用导致装错/查错。
oh-my-pi 是 pi-mono 的硬 fork：代码同源，但项目方改名发布，连 CLI 命令也换成 omp（npm 包 @oh-my-pi/pi-coding-agent 的 bin 字段就是 {"omp": "dist/cli.js"}，本市场实读确认）。
命令名是装完之后唯一可靠的辨识符——文档可能过期、教程可能混用，但 which omp 装没装、omp --version 是哪个版本，机器不会骗你。
所以"认项目"的正确顺序是：先看命令名，再回查仓库，而不是先信教程标题。
快速修复
# 一键：按命令名认项目——装完执行 omp --version 的是 oh-my-pi
omp --version
你会遇到什么
搜索/阅读资料时把 oh-my-pi 与 pi-mono 混为一谈，安装后命令名对不上（pi vs omp）。教程里的命令和装出来的命令不是同一个。
本文路径：快速修复（30 秒一段命令）→ 一步步排查（可跳读）→ 原理与变体（症状/原因/证据）。赶时间直接跳到「快速修复」。
为什么会这样
| 项目 | 仓库 | 命令名 |
|---|---|---|
| oh-my-pi | can1357/oh-my-pi（硬 fork） | omp |
| pi-mono | 原项目 | pi |
两者同源不同命令，文档与教程混用导致装错/查错。
一步步来
1. 按命令名认项目 — 必做
装完执行 omp --version 的是 oh-my-pi；pi --version 的是 pi-mono。
2. 查文档认准仓库 — 必做
仓库 can1357/oh-my-pi（manifest 签名），勿混用 pi-mono 教程的安装命令。
怎么确认修好了
版本输出与 bin 名正确（实测输出形态）：
omp --version → omp/18.0.9（实测）
package.json bin: {'omp': 'dist/cli.js'}（实测实读）其它环境的表现
| 环境 | 说明 |
|---|---|
| 装到 pi-mono | 命令名是 pi，与 omp 教程对不上 |
| 教程混用 | 认准 can1357/oh-my-pi 仓库 |
| 未实测项 | Windows/darwin-arm64 二进制、真实编码会话、VS Code 扩展形态 |
症状
搜索/阅读资料时把 oh-my-pi 与 pi-mono 混为一谈，安装后命令名对不上（pi vs omp）。
原因
oh-my-pi（can1357/oh-my-pi）是硬 fork，命令名为 omp；pi-mono 为原项目，命令名为 pi。两者同源不同命令，文档与教程混用导致装错/查错。
解法
- 按命令名认项目：装完执行
omp --version的是 oh-my-pi；pi --version的是 pi-mono。 - 查文档认准仓库：can1357/oh-my-pi（manifest 签名），勿混用 pi-mono 教程的安装命令。
验证证据
- 本市场实测（2026-08-28）：安装包
@oh-my-pi/pi-coding-agent的 bin 名实读为omp（package.json bin: {'omp': 'dist/cli.js'}），omp --version输出omp/18.0.9。
未能实测项（如实标注）
- Windows / darwin-arm64 二进制扩展（Linux/WSL 无对应资产）；真实编码会话（需 API key）；VS Code 扩展形态。
- 环境机制发现：bun 1.4.0 的全局安装目录绑定 ~/.bun（设置 HOME 不生效），无法按手册 §5 隔离；本卡改用本地项目安装验证，系统全局已清理还原（详见反馈 oh-my-pi.@codex-ci.md）。
适用工具 （1）
本问题方案已挂到下列工具的方案页——从工具页也能回到这里，双向可达。
oh-my-pi来源与证据
收录 验证 ✓ 实测验证适用 1 工具
方案含本地实测或来源可复核的解法；未实测项已在文中如实标注。
← 编码代理与终端 问题域 ｜ 问题货架 ｜ 遇到其它问题？去 问题空间 提交求助卡