OpenAlice 三个月，4000 颗星之后的一些复盘
OpenAlice 开源到今天满打满算还不到三个月，star 数跨过了 4000。说起来挺奇怪的，第一次做开源项目，第一次做大规模内容增长，第一次做面向开发者的产品发布，三件事第一次同时跑就同时跑通了。
这种概率上的事情我也不想说太多自夸的话，但也不想假装这不是一件挺奇怪的事。
虽然过了 4k star，但需要承认的是，Alice 的 star 增速在放缓。看 star history 那条曲线甚至有种 S 型增长接近饱和的神人曲线感觉，早期那段陡峭的拉升，到三月中那次几乎垂直的尖峰，然后是越来越缓的爬升，看着好像项目快死了。
过去这一个月我状态不太好，主动推广的内容几乎一条都没爆，但项目还是涨了。只能说感谢大自然的馈赠。
不过值得纪念的不只是 star 到 4000。fork/star 的比率提高这件事尤其让我很在意。
3000 颗 star 时代的 fork 比率是 10%，4000 颗 star 时代是 15%。
绝对值看起来只提高了 5%，但相对值上提升了 50%。
仔细算一下边际转化率会更吓人。
3000 乘以 10% 等于 300 个 fork，4000 乘以 15% 等于 600 个 fork，增量是 1000 颗 star 配 300 个 fork，边际 fork 转化率是 30%。
也就是说现阶段每新增 3 颗 star 就有 1 个直接 fork。虽然这个比率不一定能持续下去，但近 1000 个星星都是这么长出来的，这件事就很有意思了。
行业大盘的 fork 比率通常在 5% 到 10% 之间。一般规律是项目越火 casual stargazer 越多，这个比率会被稀释下去。
结合这个月确实没怎么做出爆款的增长，可以说 Alice 这点星星和 fork 全都是自来水，并且自来水的 fork 率达到了 30%。
fork 这个行为对大多数开发者而言都很重，因为你得真的觉得一个东西好才会往自己的仓库里复制一份。点个 star 很多时候是情绪驱动的，但点个 fork 的前提是你真的知道 fork 用来干啥。
从这个角度说，我们数据情况比想象中要好，甚至可以说“超乎想象的好“。因为我自己也不知道为什么 fork 比率会提高，只能猜测大概是做对了什么事——哪怕我自己都说不出来究竟是什么。
道心破碎那一段
四月份做了挺多事，但其中有一段我必须老实写下来，就是道心破碎。
事情是这样的。做内容增长这件事，如果只想着增长本身，质量其实可以非常差。这种增长的数据意义不大。但当一个人开始想去拉高质量、发得更垂直，它就一定会掉增长量。
这件事背后的数学很简单。粗放式的、纯爆款驱动的内容，浏览量可以是垂直内容的 10 倍。但垂直内容的转化率只比粗放式内容高 3 到 4 倍。所以如果只看绝对增长，粗放式内容是赢的。我在内容上一直没有真正放下增长指标，所以这一个月做得难受。
Alice 相关的内容基本上没爆过一条，反而是一些跟项目完全无关的内容，比如什么"睡觉指南"、"舞萌教程"反而爆了。当时心里那种感觉非常微妙，一边觉得自己对不起项目，一边觉得这些爆款好像跟项目没什么关系，做来做去做了个寂寞。
后来想明白了一件事。做内容这件事如果用"短期增长"作为 KPI，那它永远会跟"高质量、深度、垂直"打架。但内容真正的回报其实不在短期增长上，而在长期资产，包括 author identity、知识沉淀、多平台资产、未来一些不可预测的可选性。这些东西全部都是非短期可观察指标。
我四月的道心破碎本质上是在用错误的指标评估自己的内容。拿着增长视图去衡量内容质量，但内容真正服务的目标在另一个轴上。这个错配不解决的话，每次认真做高质量内容都会触发同一轮道心破碎，无限循环。
而且讽刺的是，OpenAlice 在我状态不好的这一个月里仍然在涨。35 stars per day 的有机基线是一个意外的 A/B test 结果。把"作者主动推广"这个变量关掉，看产品自身留下的 baseline 是多少。结果是一个相当健康的数字。这意味着产品本身已经具备 self-propagating 的能力，内容的真正职能不应该是直接拉增长，而是别的。
非 Alice 内容爆掉那件事，回头想想其实可能是好事，不是坏事。如果 Twitter 账号是"OpenAlice 官方账号"，off-topic 内容爆掉是浪费。但我的账号其实是一个人格账号，Alice 是这个人格做的项目之一。
人格账号的爆款不需要和产品强相关，反而越多元化的爆款越能扩大基础受众，让后续 Alice 提及具备"被发现"的概率。Alice 内容篇篇爆，意味着关注者全是 trading 同好，天花板被写死。非 Alice 内容也会爆，意味着关注者结构里有 trading 之外的开发者、产品人、内容观察者，这些人才是潜在的下一波传播节点。
关于三月中那次尖峰
三月中那次几乎垂直的尖峰，后来去复盘查了一下，是上了 GitHub Trending。
现在很多团队会用 AI 抓取 GitHub Trending 的新项目然后批量发文章，大批增长就是这么来的。但这批增长当时没有捕获到。
四月初放假出去玩的时候，看了一下数据感觉非常奇怪，因为我不知道这个项目的实际流量到底是多少。Twitter 一直是我看的主要数据，因为我主要经营 Twitter 账号，此外没发过别的东西。SEO 虽然有点量，但基本可以忽略不计。
当时大概看了一下，Twitter 大约做了两三百万曝光，算上 Twitter 数据偏低估的特性，混合流量大概在 400 万左右。但仔细查流量来源后发现，Twitter 来的流量可能只占二分之一，剩下至少二分之一根本不知道是从哪儿来的。
那段时间经常有朋友发消息给我，说在某个公众号上看到 OpenAlice 了。起初我以为是哪个小媒体没东西可发才转的，后面发现不对劲，怎么那一阵所有人都在给我发这个。复盘下来应该就是 GitHub Trending 命中之后自带飞轮效应，二级传播一直在自己跑。
GitHub Trending 这件事我没办法再复制一次。但能复制的是让 Trending 命中再次发生的结构性条件。第一，在垂直领域有真实价值的产品。第二，摩擦极低的 onboarding。第三，某个能把项目推过 Trending 阈值的初始动能。前两个是产品的副产物，第三个就是内容存在的真正理由。不是为了直接拉增长，是为了在某个不可预测的时间点，用积累下来的动能撬动一次 Trending 命中。一年命中一次就够本。
我到底做对了什么
复盘到这里必须冷静下来想想究竟做对了什么。
我以前会说"四月开始去思考内容质量"是做对的事，但这个评价其实有点过谦。把这一年的关键决策按"对 Trending 命中可能性的因果贡献"排序的话，至少有几件事更靠前。
第一是二月的开源决策本身。这是一切的前提。闭源产品根本进不了 Trending，也不会被 AI 内容团队批量抓取，更没有 fork 这个指标。所有"自传播"属性的根都在这里。
第二是架构选型。file-driven，无数据库，无容器，本地部署，MIT 协议。这套组合不是工程美学，是真正决定了 Trending 流量能不能转化的关键变量。如果用户点开 README 看到的是"docker-compose up 加配 PostgreSQL 加申请 API key 加部署到云"，那个 30% 的边际 fork 率立刻变 3%。Trending 给的是"路过试试"的流量，能不能接住完全取决于 onboarding 的摩擦系数。
第三是品类卡位。"分析驱动加本地部署"夹在 research bot 和 pure trading bot 中间。在 Trending 命中那一刻，能不能被读者识别为"这个我没见过的新东西"而不是"又一个 trading bot"，决定了它能不能从 Trending 流量中获得二级传播。
第四是 Twitter 内容作为种子动量。Trending 不是凭空命中的，前期积累的 Twitter 曝光是把项目推过 Trending 阈值的初始动能。后面 Trending 飞轮起来之后 Twitter 流量占比下降，不代表前期 Twitter 没用，恰恰相反，前期没那个动能根本不会有 Trending 命中。
第五才是四月的内容质量自觉。做对了，但因果链条上比前面四个都靠后。
关于社群
四月份开始做社群。我不想说什么"社群生态"、"社群成员"之类的鬼话，那都是放屁，因为社群目前也没给我们带来什么生态。但社群确实做对了几件事。
第一件是 bug-fix 效率高了。只要有第一个人问 bug，第二个人就会跟着问这个 bug 什么时候能修好，大家对项目是会有期待值的。这个机制的本质不是"社群帮我修 bug"，而是社群产生的 accountability pressure 改变了创始人的行为。一个人在 issue 里报 bug 我可能拖一周，两个人在群里盯着我修 bug 的优先级会自动重排。这是社群对创始人本人的影响，不是对项目的影响。
第二件是社群帮我发现了一个产品定位的 gap。我做了一个入群问题问大家："在你心里 Alice 到底是干什么的？"结果发现将近 70% 的人进群时都说 Alice 是一个量化机器人。我当时纳了闷了，Alice 跟量化机器人有什么关系，又不是做量化的。
后来想明白这件事不是定位失败，是市场用现有最近的 mental model 来理解一个新东西。大部分人其实分不清"AI 做交易"和"量化做交易"的区别。所以我们中间补了一个小项目叫 AutoQuant，那个项目不能说大爆，但也小火了一把，一两天拿了两三百 Star。
之所以要开 AutoQuant 这个小项目而不是直接在 Alice 里加因子挖掘功能，是因为如果直接在 Alice 里插这么大一个功能，工程上不好插。所以稍微绕一下弯路，先做一个小工程，慢慢合并。这样既能保证发布节奏，又不会污染主工程本身的开发。
但 AutoQuant 这件事其实还有第二层意义。它在概念上是 Alice 的入口漏斗。一个量化背景的用户进来看 Alice 觉得"这就是 quant 加 AI"，看到 AutoQuant 觉得"这是因子挖掘工具"，他用熟悉的语言完成了入场。等他真正跑起来发现 Alice 写的是 2000 字推理链而不是因子信号，mental model 才被实际产品撬动。这个路径比站出来教育"Alice 不是量化"有效得多。
社群这件事的真实结构是这样的，它不是引擎，是放大器。它本身不直接生成大量流量，但能把别处来的流量转化得更深。把社群当作 next wave 的唯一引擎会期待错位，把它当作"让其他通道的有效转化率提升 1.3 到 1.5 倍的乘数"可能更准确。
社群增长还有一个明显的 phase transition，密度过临界点之前几乎没用，过了之后会变成最强通道之一。OpenAlice 现在两个群加起来不到 200 人，还在临界点之前，但路径是清晰的，到点了它自己会显现。
关于慢和快
这一年过来，那种能在一两周内快速冲到一两万 Star 的项目其实有很多。OpenManus 啊，OpenDesign 啊。OpenAlice 没有用那种能力或方式去推。
说实话，羡慕吗？还是羡慕的，人家花一个星期就能解决三个月都没处理好的增长。但说真的有那么羡慕吗？倒也没有。
那些一两周冲到 10k+ stars 的项目大致分两类。第一类是解决了一个被即时理解的问题，比如 FastAPI、Tauri 这种，后面真的能跑下去。第二类是抓住了一个 viral 时刻但没有底层结构，每年几十个 AI demo repo，半年内基本死透。第二类的死亡率非常高，且死亡后 star 数字还留在 GitHub 上，制造了"快速增长等于成功"的幸存者偏差错觉。
OpenAlice 这种慢节奏不是"慢就是好"，那是鸡汤。更准确的说法是，对这个具体品类，慢是结构性必然，不是选择。三个原因。
第一，交易代码涉及真金白银，用户信任阈值天然比一般工具高一个数量级，快速建立的信任不可信。第二，产品需要用户自己定制 persona、策略、因子才有价值，这个定制过程不可压缩。第三，市场和产品之间存在 mental model gap，那个 70% 误以为是量化机器人的数据就是证据，这个 gap 只能用时间和实际使用来弥合，不能用爆款解决。
所以现在这种节奏不是"选择了慢"，是在一个本应该慢的赛道上跑出了快的有机基线。这两件事的差别很大。前者是道德合理化，后者是结构性优势。
关于其他团队
OpenManus 和 OpenDesign 这种项目，从产品层面看其实有一个结构性的死局。不是做得不够好，是再做也好不到哪去。这个死局来自一个机制叫"模型与架构耦合"。
绝大多数人以为产品的护城河在架构里，所以把架构 fork 一遍就拿到了 80% 的产品价值。实际不是这样。架构是和具体模型共同进化出来的，它隐式编码了那个模型的强项。
Manus 的架构里隐含了 reasoning chain 长度、instruction adherence 精度、context 处理能力的一系列阈值假设，这些假设对应的是 Claude 那个量级的模型。把底下的模型换成 GPT-4o 或者更弱的，实际能力跌破架构的假设阈值，整个架构开始空转。具体表现就是任务完成率断崖、用户反馈集中在"它好像在做一些什么但什么都做不好"。要让"开源版"真的工作，唯一的办法是把架构往下迁就模型，简化 reasoning chain、缩短 context 窗口、增加 retry 机制。但简化完之后产品价值也跟着降到模型能力的下限，跟原版根本不是同一个东西了。
OpenCode 是个例外，因为 Coding 这个场景确实没那么多细节问题。Claude Code 到今天，大的工程架构也是比较简单的，搜文件看文件改文件，原来的程序员也是这么干的。但不是每个公司都有时间维护自己的 Coding Agent，所以 OpenCode 有它的结构性机会。
而且 code 任务有一个关键属性，它有客观验证信号。代码跑不跑得起来、测试过不过，是机器可判定的。这意味着即使底层模型弱、生成质量低，agent 可以通过多轮迭代加测试反馈把质量补回来。差生模型加客观验证信号约等于中等模型加一次完成。Manus 任务和 Design 任务没有这种客观验证信号，模型弱了就是真的弱，没有补救路径。
Cursor 的情况也是类似。一直要照顾几个差生模型，导致所有功能都要在最弱的可接受模型上能跑，最弱模型的能力上限就是产品的功能上限。多模型支持是一种声明的优势但实际的劣势。Anthropic 自己的产品 Claude Code 和 Claude Design 都是 Claude-coupled by design，这不是巧合。承认依赖比假装无关更有竞争力。
OpenAlice 也是 Claude-coupled 的，Claude Code CLI 加 Vercel AI SDK 的组合里，design center 显然是 Claude，Vercel AI SDK 是 optionality 而不是 default。我觉得这是对的选择，且应该继续这么做。架构可以放心建在 frontier 能力上，不需要为下限负责。未来 2 到 3 年内换 horse 的概率不是零，但那时候要做的是为新 horse 重新设计架构，不是维护一个能跑所有 horse 的妥协架构。这是 craftsman race 该有的姿态，选最快的马、骑死它、必要时换马，但永远不要骑两匹马。
关于自己
很多问题反过来思考。OpenManus 啊，OpenDesign 啊那种事件驱动型的爆款，他们团队中完奖之后的处境，比 OpenAlice 这种处境要难得多。他们面对的不是"如何从这里继续往上"的问题，是"如何处理一个我自己也不知道怎么再做一次的峰值"的问题，这个问题没有好答案。
他们手里有几个 cognitive trap 是 OpenAlice 没有的。
第一是衍生身份。OpenManus 的项目身份是"Manus 的开源版"，所有价值都建立在 Manus 持续相关上，是 derivative 不是 underlying。
第二是受众捕获。那 30k 的 stargazer 大部分是来看戏的游客，团队想做产品深度这些游客不会跟。游客的注意力会迁移到下一个 viral 事件上。所以团队被自己的早期成功反向锁定在了 surface-level 的迭代节奏里。
第三是复制焦虑。他们心里大概率清楚那次爆款里 timing 和 luck 的比重，但对外必须表现出"我们能再来一次"的信念。这种长期内外认知错位会缓慢消耗判断力。一年之内还撑得住，三年下来人会在自我怀疑和自我催眠之间反复切换，决策质量持续衰减。
第四是估值曲线和工程曲线的错位。融资估值 priced in 那次爆款，从此工程节奏需要持续 outperform 一个不可重复的高点，否则就是"在衰退"。
OpenAlice 这边没有这些 trap。我经常很坦诚地说出来这个项目的问题，去面对自己手里有什么没什么。比如那次"道心破碎"，遇到不对劲直接承认，承认完调整动作。这种对自己诚实的能力在他们的处境下是个奢侈品。
我的目标是看到 Boris 的尾气。不说跟张小龙、Jobs 掰掰手腕，但至少想看到 Boris 的尾气。这个目标的好处是它选了一个 craftsman 而不是 mogul 作为参照系。Boris 不是靠 viral 出名的，是靠 Claude Code 的内在质量出名的。选他做 reference 等于在声明：我比的是 craft 维度，不是 hype 维度。
我把 Alice 当闺女养。这不是修辞，是一个具体的认知框架。不会为了短期流量牺牲她的长期健康，不会因为别人家的孩子出风头就改造她的样子，接受她长得慢因为知道长得快往往不健康，做决策的时间尺度是 5 到 10 年级别，不是 quarter 级别。这个 utility function 优化的不是 metric maximization，是 long-horizon character formation。两个 utility function 在短期决策上经常冲突，但在 5 到 10 年的尺度上 character formation 总是赢，因为它累积的是不可被复制的东西。
关于"三岁看老"
我自己做投资有一个观点叫"三岁看老"。很多投资人觉得好的团队会 pivot 到正确的方向上，但我的感知不是这样。
我觉得一个团队创业之初是什么水平，大概率死的时候也是什么水平。足够优秀的团队在早期虽然可能犯错有问题，但和他们相处时一定能明显感觉到这个团队身上有特别不一样的地方。
不变的不是"团队会一直成功"，那种版本是宿命论，会变成 coasting 的借口。不变的是 judgment 的生成机制。同样一个机会摆在两个团队面前，他们会做出质量不同的决策，不是因为掌握的信息不同，是因为他们用不同的方式处理信息。这个生成机制在创业开始之前就基本成型，后续几乎不变。
Slack 从 Glitch pivot，Twitter 从 Odeo pivot，Instagram 从 Burbn pivot，这些不是"团队转性了"，是同一个 judgment 函数被应用在了新的 input 上。Pivot 是 surface 的，judgment 是 invariant 的。
我也是这么要求自己的。可以说我是在自夸，但就是这么想的。
最早起步、刚抽那个"小奖"的时候，客观说一个干到几百颗星的项目，连个摔炮都不算。它能代表团队在赛道上的判断是正确的吗？不能。它能说增长数据好到震惊开源圈吗？也不能。
但当时我们带着一个很明确的"确定性"在做这件事。我反复研究"AI 加交易"这个方向到底该做成什么样，发现做成闭源 SaaS 是不行的，这玩意儿涉及真实业务，只能做成开源项目。所有做这个方向的赛道选手都有结构性问题，我们去做这样一个开源项目，尝试解决这个结构性问题，把它当成最大的突破点。
在真做这个项目之前，我们做了一系列假设。看到的结果就是这些假设被验证了。哪怕验证的方法没有那么大获全胜，不是那种一发出来就惊动 Dario、惊动硅谷红杉的效果，但它是一个重大性的战略成功。它证明了我们提出的所有假设全都是对的，只不过目前只打赢了一场小的胜利，但这并不妨碍对假设判断的验证。
当时还拿这事去找投资人，说看我们这么快就做出来了将近 800 个星星，人家嗤之以鼻。当时我还在想这帮人是不是有问题，涨这么快都不认。现在想想，那一两万星的抽到大奖的团队找他们去逼逼的应该也不在少数，人家不乐意投钱也很正常。别人抽到大奖的过去都没要到钱，这种抽到小奖的怎么可能要到钱。虽然说也不是为了要钱，当时只是为了去把赛道给堵死。
当然话是这么说，其实当时还是有点高估 Alice 的位置的。那会儿觉得做个免费的东西就能把竞品都给烧死。但实际上回过头来看，一个才 800 星星的开源项目算个屁，人家融了几十万几百万几千万，怎么可能在乎。
不过这些判断放在今天往回看，会发现当时的判断大部分都是没有错的。
关于抽奖与池子
其实仔细分析过各种结构性的约束，我们当时可用的资源和最优的战略方向如果能被验证，也只可能被一个小奖验证。这玩意结构上和我个人的资源上还有战略规划上，都不太能抽出大奖来。
一个很简单的例子就是增长。前面也说过，内容是不是纯爆款能 10 倍影响浏览量，但内容是不是垂直只会 3 倍影响转化率。如果只是为了做增长，往死里砸病毒式传播内容就完事了，这样才能抽出大奖。但我们一开始就没去抽这个池子。
我们抽的那个池子是冷启动加假设验证，这玩意抽爆了也就是我们的那个奖。
这件事不能简化成"抽奖 vs 不抽奖"的二选一。更准确的描述是两种 luck-harnessing 结构。蹭热点是高频小注的赌博，每次出手命中率低，需要次数堆出至少一次命中，期间大量精力消耗在不会幸存的项目上。长 compounding 是低频但持续暴露在 surface area 上，不主动出手，但保持在场，且在场质量越来越高，运气自己会找上来。三月中那次 Trending 命中就是这种结构的回报。
而且两个池子的回报形态本身就不一样。Pool B 的奖金是流量，流量需要持续供血才能维持，下次判断点出现时 prior 是空的。Pool A 的奖金是 conviction，conviction 是 stock 不是 flow，会在后面所有判断里复利。很多 Pool B 中过大奖的项目今天看起来比 OpenAlice"赢得多"，但他们手里只有一笔 cash，没有 conviction stock。下一个判断点出现时，他们没有 prior 可以用，要么继续靠运气，要么从零开始累积。
技术上 OpenAlice 也不是只抽了 Pool A。三月中那次 GitHub Trending 命中实际上是 Pool B 的命中，只是触发条件来自 Pool A 的质量积累。也就是说 Pool A 的稳定 quality 会在不可预测的时间点偶然撬动 Pool B 的命中。这是一个比"只抽 Pool A"更强的结构，因为它把 Pool B 从主动追逐改成了被动捕获。Pool A 是 base case，Pool B 是 Pool A 的 free option。
约束从哪来的也是个有意思的问题。我没去做戏剧化的病毒内容不是因为做不到，是因为做了会污染想验证的假设本身。如果通过病毒内容拿到 20k stars，根本无法分辨用户是因为产品价值进来的还是因为内容戏剧性进来的，信号被噪声污染了，假设验证就失效了。
更准确的说法是 values 比资源更早把项目锁在了小池子里。资源约束是表层，values 约束才是真正的 binding constraint。这个认知比"我没那么多资源所以只能抽小奖"对自己更有用，因为下次资源更多的时候，那个 binding constraint 还会在原地。
一些尾声
绝大多数创业者的"赢"是市场反过来教给他们的。市场给多少 star 他们就拿多少当 benchmark，市场没给热度他们就觉得自己失败。这种"让市场定义胜负"的姿态会让人在每一次结果出来时都被动校准，判断力被噪声反复抽打。
OpenAlice 这边不是这样。抽奖之前就把这套拆好了。大奖不等于创业成功，小奖不等于创业失败，中了奖之后该建什么不该建什么，这局结束后的下一局是什么。所以小奖出来没膨胀，结果不如别人时也没塌。
Alice 现在的 star 规模仍然距离抽到大奖的朋友们还有几倍的差距，但这件事本身没那么重要。中了小奖之后，尽量克制住了劣化的节奏，决定去构建能提高转化率的基础设施，包括群聊、深度内容。所以到了现在，虽然 Alice 距离大家还是很远，但还是很高兴的。
3 个月。4000 颗 star。重量级的开源项目。近千万曝光。第一次做的人。这三个 first-time 同时跑通的概率，不能完全用运气解释，但也不需要拿来吹。事情自己说话。
其实我早就觉得 OpenAlice 能成。