OpenCompanion

发布之后的表现

收入:库里没有。 indie(TrustMRR)按域名、名字、创始人其它域名(eksis.io、psikoteskerja.com)查,均无记录库。产品本身免费开源,没有收款入口,所以「库里没有」与「没赚钱」在这里是一致的,不是覆盖问题。

用户 / 下载:库里没有。 它是 Windows/Linux/macOS 桌面应用,不上 App Store / Google Play / Mac App Store / Chrome 商店,四个商店库按名字和 app_id 查均无结果库。官网给的安装包体积:Windows .exe 16.1 MB、macOS .dmg 16.8 MB、Linux AppImage 92.8 MB官网。没有下载量数据。

开发者关注:弱。 GitHub 库名单门槛是 ≥50 星,该仓库 12 星,不在库里库。现查 GitHub API(2026-11-02):12 stars、2 forks、0 open issues、0 watchers、147 commits、MIT、Rust、建库 2026-09-25、pushed_at 2026-10-02官网 API。fork/star = 16.7%,超过 15% 的警戒线,追查后解释:两个 fork(Nabilkarem911、cpiprint)都创建于 2026-10-01 发布当天,pushed_at 与上游完全相同、无任何改动,是「收藏式 fork」而非刷星,样本只有 12 星,比例本身没有统计意义。仓库有完整 README、CHANGELOG、CONTRIBUTING、SECURITY、CI、e2e 测试,不是「只有 README」的空壳。两个 release:v0.1.1(2026-09-30)、v0.2.1(2026-10-01)官网。

讨论:库里没有。 hackernews 库按域名 opencompanion.vercel.app 和仓库名查,0 条故事库;x 本地库按名字、创始人 handle 查,0 条提及库。全网搜索只找到一条第三方报道:AIToolly 2026-10-02 的 AI 新闻摘要,一句话转述了 PH 发布(https://aitoolly.com/ai-news/2026-10-02),没有评测、没有讨论。

官网动态:停在发布周。 官网 2026-11-02 仍可访问,但下载按钮指向 v0.1.1,而 GitHub 最新 release 是 v0.2.1官网——说明发布后没再维护落地页。CHANGELOG 最后一条是 0.2.1(2026-10-01),之后 [Unreleased] 为空官网。AppImage 官方目录的收录 PR #9612 由机器人于 2026-10-01 自动提交,测试报错「AppRun.wrapped: Permission denied / 应用 11 秒内退出」,至今 open、未合并、作者未回应官网 PR。无融资、无收购、无 changelog 更新。

自报 vs 实际

没有收入、用户数、下载量的自报数字,所以没有可对账的「100 万用户」类宣称。

为什么成了 / 没成

没成,原因不在产品完成度,在分发和持续性。

产品本身做得相当扎实:147 次提交、CI 覆盖三平台、e2e 测试、完整的 CHANGELOG 和已知限制清单,甚至主动列出「macOS 从没人在真机上打开过」这种自曝。它切的问题也真实——同时跑几个 Claude Code 会话、每个都在等权限确认,确实是 2026 年的日常痛点。

但三个数字说明它没接住:PH 64 票 → GitHub 12 星,转化率不到 20%,说明看客多、动手装的人少;12 星 → 2 fork 且都是发布当天的收藏式 fork,说明没人真的改它;发布后 31 天零提交,说明作者自己也没继续。免费开源 + 无账号 + 无云端的定位,意味着它天然没有收入模型,只能靠「用的人多 → 有人贡献 → 有人赞助」这条路,而这条路需要持续运营社区,单人副业项目很难撑。

更根本的是赛道拥挤。同类里 BloopAI/vibe-kanban 有 28,552 星库,Traycer 约 1.6k 星官网,awesome-cli-coding-agents 列表,还有 opencode-monitor 等一批。OpenCompanion 的差异化(手机批准、本地网络、无云端)是真实的,但在一个已经有 2.8 万星头部项目的品类里,12 星的新项目没有可见度。

对想跟的人

这个方向还有位置,但位置不在「再做一个多 CLI 会话面板」——vibe-kanban 的 28,552 星已经把通用编排吃掉了,你拿 12 星去正面撞没有意义。真正没被填的是 OpenCompanion 自己写进 CHANGELOG 的那几条「已知限制」:Codex CLI 的 headless 成功运行「从未被观察到」、Gemini CLI「检测到但没跑通」、macOS「没人在真机上打开过」。这些是跨 CLI 的权限协议适配,谁把 Codex / Gemini / Cursor 的权限提示也做成统一的 Approve/Deny,谁就拿到了这个品类真正的护城河——因为每家的 hook 机制都不一样,这是脏活,也是头部项目懒得做的活。最大的坑是:这类工具的用户是开发者,他们自己会写,你的功能一旦被上游 CLI 官方吸收(Claude Code 已经在做多会话管理),你就没了;所以别做「面板」,做「协议层」。

没查到的

• indie(TrustMRR):库里没有。产品免费开源,无收款入口,预期不会有。
• appstore / googleplay / macappstore / chromestore:四个库都没有。它是桌面原生应用,不上这些商店,属正常。
• hackernews / x 本地库:都没有。没有 Show HN,没有 X 提及。
• GitHub 库:12 星低于 50 星门槛,不在库里;star 走势、fork/star 历史曲线无法从库内取,只能用 GitHub API 的当前快照。
• 答不了的:真实下载量(官网无统计、无商店数据)、实际活跃用户数、创始人是否已放弃(只能从 31 天零提交推断)、PH 那 2 条评论的内容(PH 页面被 Cloudflare 拦截,抓不到)。
• 数据包里的 PH / indie / appstore 段落是按 domain = github.com 匹配的,把 GitHub 官方产品等 30 个无关条目捞了进来,本档案已按产品名和仓库名重新点查,未采用那些结果。