OpenCharm

发布之后的表现

收入

• indie(TrustMRR)库里没有。按域名 opencharm.dev 和名字都查不到库。这与产品定位一致:它没有收款入口,README 明确说不卖任何东西。

用户 / 下载

• appstore、googleplay、macappstore、chromestore 四个商店库全部没有库。产品只以 GitHub Release 的 dmg / exe 分发,不上商店。
• npm 包 opencharm:最近 30 天(2026-09-30–10-29)下载 3,934 次,但 10-03 至 10-05 三天就占 2,449 次(342 / 469 / 1,638),那正是仓库刚建、CI 在跑的时候;发布日 10-09 只有 61 次,10-22 之后每天 2–12 次,最近一周(10-23–10-29)90 次npm API。
• GitHub Release [email protected](2026-10-14 发布)三个安装包合计下载 34 次(aarch64.dmg 13、x64-setup.exe 14、x64.dmg 7)GitHub API,2026-11-01。这是目前最接近「真实装机量」的数字,量级是两位数。

开发者关注

• github 库里没有这个仓库库。这不是异常:全站名单门槛是 ≥50 星,该库只有 19 星,本来就进不来。
• GitHub 页面(2026-11-01):19 stars、3 forks(fork/star = 15.8%)、99 commits、90 个 tag、0 open issues、最后 push 2026-10-21。fork/star 比偏高,但分子分母都是个位数,不构成刷星信号;90 个 tag 对 99 个 commit 说明是 release-please 自动发版,不是人工堆版本。配套仓库 opencharm-starter 4 stars、0 forks。
• 语言构成:C 1.14 MB、TypeScript 0.93 MB、HTML 0.60 MB、C++ 0.36 MB、Rust 0.20 MBGitHub API——固件 + 桌面端 + 官网三块都真写了代码,不是只有 README 的空壳。

讨论

• hackernews 库里没有:按域名、仓库名、标题词边界三种查法都是 0 条库;用 CLI 搜「opencharm / agentic companion」也只返回同名无关帖。也就是说这个项目从没上过 HN。
• x 本地库(560 人 core 名单)里没有提及,创始人 @mfbzme 也不在名单里库。他本人 X 上 252 关注者、1,082 帖,10-28 发过一条 OpenCharm 相关视频(1 赞),10-19 起主要在为另一个产品 Crocotaste 站台X 公开页。
• PH 发布帖有 8 条评论,内容偏技术问答(比如「怎么区分 agent 卡住和只是慢」),创始人亲自回复PH 页面摘要。

官网动态

• 官网在线,页脚标注「REV 0.1 · 21 OCT 2026」,/version.json 返回 web@unknown (22d44c3),与仓库最后一次 commit 一致官网。没有 changelog 页、没有博客、没有融资或收购消息。GitHub README 的 Status 段自述:macOS 端到端测通(2026-10-03),Windows 构建「未在真机测过」,Codex / Gemini / goose / Hermes / OpenClaw 的预设「用替身 agent 跑过测试,没逐个真机验证」,参考板 10-13 至 10-19 手工验过自报。

自报 vs 实际

没有发现自报数字与库冲突的地方——因为这个产品根本没报过用户数或收入。

为什么成了 / 没成

它没「成」,但也不是失败,更像一个高完成度的个人作品。三个具体证据:

1. PH 票数没转化成开发者关注。 86 票、日榜第 14,换来的 GitHub star 是 19 个,比例约 4.5:1;同期 HN 和 X 核心圈零提及。说明 PH 那波流量是「看个新鲜」,没有落到「我要装一个」。
2. 装机量是两位数。 最新桌面版三个安装包合计 34 次下载,最近一周 npm 90 次。对一个需要用户自己配 Claude Code、自己开终端跑 opencharm init 的工具来说,这个漏斗太窄。
3. 没有商业闭环,也没有社区闭环。 README 明说不卖东西、不接预订;硬件要用户自己买板、自己刷固件、自己承担锂电池风险(README 专门写了免责)。开源项目靠这两条腿走路,一条都没有,就只能靠作者个人热情——而作者 10-21 之后就没再提交了。

它做对的地方也很清楚:定位精准(给已有 agent 加身体,不抢 agent 的活)、设计克制(两个字符当眼睛)、工程扎实(固件/桌面/CLI 三端都真写、CI 出包带 SHA256 和 attestation)。问题在于,这些优点服务的是「已经重度使用 coding agent 的开发者」,而这个人群恰好是最不需要一个实体挂件的人——他们盯着终端就够了。

对想跟的人

别跟「给 agent 做实体挂件」这件事本身:OpenCharm 用 86 票 PH 首页 + 19 个 GitHub star 证明了,这个方向的注意力天花板大概就是四位数曝光、两位数装机。真正值得抄的是它的分发结构——把硬件做成「你自己买 $32 的 Waveshare 板子自己刷」,作者零库存零售后,代价是永远拿不到用户数据、也永远收不到钱。如果你要做,位置在「先做纯软件版验证需求,再决定要不要碰硬件」:OpenCharm 的桌面版(4 MB、2% 单核)本来就是它自己承认的「没有硬件的 charm」,而它连这个软件版都没能让人装起来——34 次下载说明问题不在硬件门槛,在「用户为什么要装」。最大的坑是:这个品类的用户是开发者,而开发者对「多一个常驻进程」的容忍度,比对「多一个好看的摆件」低得多。

没查到的

• indie(TrustMRR):没有。产品无收入,预期之内。
• appstore / googleplay / macappstore / chromestore:四个库都没有,产品不上商店。
• github 库:没有该仓库(19 星 < 50 星门槛),star 曲线只能靠 GitHub 网页单点。
• hackernews 库:0 条,项目从未上过 HN。
• x 本地库:0 条提及,创始人不在 560 人 core 名单内,只能看公开主页。
• 答不了的:真实活跃用户数(只有 npm 下载和 Release 下载两个代理指标)、创始人所在地(只能从 commit 时区 +0200 推断)、PH 发布当天的逐小时票数曲线(库里只有 2026-10-29 的一次回填观测)。