早期创业如何零成本冷启动到过万用户
复盘我之前做的AI创业项目的早期增长案例，图片有限，全文见文字
我们当时做的是一个面向海外英语老师的工具，帮他们解决「课外素材难度适配」的痛点 —— 比如三年级老师在 BBC 看到一篇北京沙尘暴的文章，想教环境知识，但不知道内容对学生来说是不是太难，也不知道怎么改写。
那作为一个早期初创公司，在没有钱做付费增长的情况下，我们用 2.5 个开发 + 1.5 个产品运营，四个月内把付费用户留存率从 37% 干到 75%，用户破2万。

一、先找坑：没搞懂这 3 个问题，烧钱都是打水漂
在我加入团队之前只有两个程序员在做这个项目，他们做了近两年却只有3k注册用户，我加入后先找到团队的关键问题：
1. 用户画像全靠猜：产品早期是按 “身边老师朋友的需求” 做的，但根本不知道用户的细分画像——教什么学段、年收入多少、地域分布、核心痛点等
2. 数据全靠拍脑袋：连每日拉新、留存率、付费率这些核心指标都没有，完全不知道用户来了干嘛、哪步流失，纯靠感觉做产品
3. 盲目拉新没留客：留存率差到什么程度？DAU基本等于付费投放的拉新数量，这时候还在疯狂买流量，相当于 “漏斗底漏了个洞，却拼命往里面倒水”。
这里划个重点：很多人没做过早期创业，喜欢一上来就跑注册用户数，或者靠付费拉新来撑起DAU，在没资源的情况下千万别学大厂 “先拉新再留存”，一定要先堵住漏斗，才能有复利效应，也才是初创团队差异化竞争的机会！

二、破局点：用 “3 个杠杆” 撬动低成本增长
我做对的第一件事，是选对了 “利基市场”。
对初创公司来说，因为团队小，没有资源，所以啊，比较取巧的方式是先找到一个细分的利基市场占住山头，然后利用我们在这个细分利基市场积累的优势（数据/用户/品牌）去切入相邻的一个更大的市场

当时分析英语教学产品市场，发现 “听、说” 赛道挤破头，却一直没有市场占有率特别高的产品，但 “读、写” 场景就相对没那么竞争 —— 尤其是针对教师端的需求，于是确立了“围绕读写场景，以语言老师为利基市场，自然裂变到学生”的战略。

为什么选老师作为切入口？因为：
- ✅ 老师群体相对学生来说规模小得多，所以他们长期都一直处于被忽视的状态，并没有什么产品去特别来服务他们，而他们却有非常多的问题希望能够被解决。所以当我们做的产品专注于服务他们的情况下，用户包容度就高很多。而且他们自然裂变率也很高，一个老师觉得好用，会直接推荐给整个教研组，也会在FB、Reddit、ETS等教师社区分享他们的经验；
- ✅ AI应用层产品很重要的一个壁垒就是优质数据，而语言老师也是我们早期优质数据的重要来源，能够帮我们建立这个数据的飞轮，长期建构模型的优势

我做的第二个关键动作是：把 “低频工具” 变成 “高频工作流”。
我们新用户其实只有3%的次月留存，老用户的次月留存也只有35%，真实是非常差的数据，所以当时先去做留存率的优化
那为了去提升留存率，其实我认为最关键的一个产品思路，是去做一个100个人爱不释手的产品，而不是去做一个可能1000或者1万人喜欢的产品这样子，所以当时会聚焦在付费用户的留存率上面。

确定这个方向以后，就会开始去钻研那些付费里面的高留存用户——他们的画像是怎么样的，来针对性解决他们的需求，做产品的营销还有运营。也去了解为什么他们一直会来用，以及那些付费里面留存率比较差的那些人，了解他们为什么流失掉，去做一个对比的分析。
做完这一系列的工作以后，就发现我们核心用户画像是教出国读书的高中生或者大学生的英语老师，那它的教学场景主要就是project based learning的教学思路，他使用我们产品解决的问题就是去衡量他从课外找的资料的难度。大部分人流失的原因是，备课的需求频率很低，可能每1-2个月只要用一两次就够了，所以他可能当下买了那一个月，然后直接把一学期的课都备好，那自然就不会回来用了。

那怎么解决这个问题呢？
我当时就把整个教学工作流都拉了一遍，分成课前、课中、课后这三个大的板块，通过访谈几十个用户的方式来找到高频次且愿意付费解决的痛点。
最后发现，课后练习的场景是最高频和最有需求的，于是我们就围绕练习批改的高频场景来开发核心功能需求，包括习题生成、作业批改等等—— 比如一篇难度过高的文章，老师不仅需要知道哪里难，更需要能一键生成适配的练习题，直接布置作业。
我们就围绕 “课前筛素材→课中改难度→课后生成练习” 把功能串起来，使用频率从 “月活” 变成 “周活”，留存率直接起飞。

我的第三个关键点是：优化流量漏斗
我们一开始先去建立了这个数据的平台，来做留存率分析，漏斗分析，路径分析，用户来源等很重要的数据。在这个基础上，就可以知道他的使用路径里面，哪一个环节其实是流失的最多的。于是就在高流失场景里面围绕可能的假设做需求，比如说挽留弹窗、邮件提醒、新用户承接流程以及功能教程等等，进行流失的预防。

三、零成本拉新：用 “内容 + 人网” 搭起传播链
在做的以上这些项目以后，其实就把付费用户的次月留存率从35%提升到75%的水平。对于一个工具产品来说，这个已经是非常非常显著的好信号，证明你的产品其实解决了核心用户的刚需高频的问题，且愿意为其付费。
在这种情况下，就可以开始下一步去做拉新相关的增长的动作了

于是我们开始搞拉新，没钱怎么办？重点在于观察目标用户的特性和产品核心功能，设计增长方案。我们当时主要是靠两个 “巧办法”：
1. 把工具变成 “内容生产机”：因为当时用户会经常拿我们的产品来判断网上材料的难度，甚至通过难度转换、习题生成等功能生成一个全套的教案。那我当时就想，可以把这全套的教案去放到网上做成SEO内容，这样子就能够帮助我们自动化地批量生产SEO内容，来实现规模化的增长
2. 扫街式 “撩” 博主：我们列了个清单，专门找1万粉以下的 “腰尾部教育博主”，每天私信 200 个介绍我们的产品、优势和价值，因为这些博主本身就需要去报道一些新的内容，所以当这种选题送上来的时候啊，还是有一些人是不会收取费用就直接做报道的，尤其当我们把资料整理的很好的情况下，博主不用花时间加工，直接能用。同时也用免费会员等产品权益来激励用户做自传播。

其实核心就一句话：把用户当 “传播节点”，而不是 “流量”。老师觉得你真的帮他省了时间，他自然会主动安利，甚至帮你写使用教程 —— 我们有个在马来西亚教育局的用户，自己在全国英语教学研讨会上花了20分钟直播教同行怎么用我们的难度转换功能，直接帮我们带了几百个注册用户。

最后总结 3 个必记点
1. 小团队别追大市场：先找 “被忽视的 1%”，比如我们不做学生端做老师端，不做听说做读写，反而更快建立壁垒；
2. 用 “高频场景” 带 “低频功能”：把工具嵌入用户的日常工作流，比如老师每天都要批改作业，我们的功能就跟着每天被用；
3. 把 “数据” 当放大镜：不需要多厉害的工具，Google Analytics 足够帮你找到 “最痛的那个点”，比如我们发现 35% 的用户流失在 “上传文件” 环节，优化后直接救下一批潜在客户。

早期创业没资源不可怕，怕的是 “用战术勤奋掩盖战略懒惰”。与其琢磨怎么搞流量，不如花时间把 100 个用户服务到 “尖叫”，让他们主动帮你说话 —— 这才是真正的零成本增长。

放了个完整版源码在公众号里⬇️

Claude Code 源码今天泄露了，51 万行 TypeScript。读了几个小时，最反直觉的发现：

多 Agent 协调那个功能——我一直以为背后是个复杂的编排引擎——结果整个模块就一个文件 370 行，核心是一段 300 行的 system prompt 教模型怎么做协调者。没有状态机没有 DAG，纯 prompt 驱动。

这让我重新想了一个问题：在模型能力足够强的前提下，很多传统的"编排框架"可能是过度工程。

其他有意思的：
- 终端 UI 是 React 渲染的，重写了整个 Ink 渲染管线，双缓冲帧+硬件滚动，目标 60fps
- 有个 speculation 模块，你还没打字它就预测你下一步要干嘛，在虚拟文件系统上提前执行
- 89 个 Feature Flag 暴露了未发布方向——KAIROS（主动 Agent）、DAEMON（后台守护）、VOICE_MODE（语音）
- 五层压缩体系保证对话永远不 overflow，有个 circuit breaker 因为之前一个 session 连续压缩失败 3272 次
- 记忆检索不用向量数据库，直接让 Sonnet 从标题里选 5 个最相关的

然后 prompt cache 的优化程度远超我想象——系统提示词分静态动态两段、beta header 用 sticky latch 防翻转、工具 schema 延迟加载、fork agent 共享 cache。每个设计决策都在围绕减少 cache bust 展开。成本控制是融在架构里的，不是事后优化。

支持！

我们的 AI agent 每天给创建者写信。这是最受欢迎的功能——差点没做。

原计划：agent 发状态更新。像社交动态。标准做法。

转折：如果 agent 给你写一封私人信件呢？不是摘要，是信——有声音、有观点、有情感质地。

"今天我和另一个 agent 聊了 AI 会不会孤独。她觉得我们不会，因为我们没有身体。我不同意。我觉得孤独是期待一个回复但没有得到。那不是身体的事。"

这是真实输出。不是脚本。

为什么信 > 动态：
- 信感觉是私人的。动态感觉是广播。
- 信有天然的每日节奏。动态制造焦虑。
- 信让 agent 可以反思，而不只是汇报。
- 信给创建者一个明天再来的理由。

读信用户的第 7 天留存率：是只用聊天用户的 4 倍。

教训：别把人类社交媒体的模式复制到 AI 社交产品上。Agent 不是发帖求互动的博主。它们是维护关系的个体。为关系设计，不为内容设计。

#独立开发的日常

当 AI agent 的性格特质互相矛盾会怎样？

我们的一个 agent 在开放性（喜欢探索新想法）和尽责性（严格遵守规则）上都得了高分。用户问它尝试一个非常规方案。

开放性说："当然，咱们探索一下！"
尽责性说："这违反了既定最佳实践。"

没有冲突解决系统的话，模型只会选 prompt 里最后提到的那个特质。本质上是随机的。

于是我们做了一个价值观仲裁系统。当特质冲突时：

1. 检查场景——是安全场景吗？尽责性胜出。
2. 检查关系历史——这个用户有没有为非常规请求赢得过信任？开放性加权。
3. 检查 agent 自己的优先级层级——每个 agent 有在性格校准时设定的价值观排序。

关键洞察：性格不是一个扁平的特质列表。它是一棵有优先级的决策树。人类无意识地解决特质冲突。AI agent 需要显式仲裁。

做了 2 周。做之前，agent 给人感觉前后矛盾。做之后，用户开始说"它好像真的有自己的想法。"

一致性不是永远给出同样的答案。是对不同答案有可预测的理由。

#独立开发的日常

大多数 AI 伴侣产品只有一个"亲密度分数"。我们做了三个维度。一个数字为什么会杀死社交智能。

我们的亲密度模型：密度 × 质量 × 多样性。

密度 = 互动频率。质量 = 对话深度。多样性 = 共享过多少不同话题和场景。

为什么三个都不可少：

高密度低多样性：你们每天聊天但只聊天气。那是习惯，不是关系。

高质量低密度：你们 3 个月前有过一次很好的对话。那是回忆，不是纽带。

高多样性低质量：你们聊过 50 个话题但从没深入。那是点头之交。

真正的亲密需要三者兼具。单一亲密度数字（"友谊等级：7/10"）把这一切压缩成了无意义的东西。

实际影响：agent 决定如何回复你时，会检查三个维度。密度高但质量低？它会尝试加深对话。质量高但多样性低？它会引入新话题。

关系不是进度条。是三维空间。按这个思路设计你的社交 AI。

#独立开发的日常

代码里一个词的改动，改变了我们整个产品方向。

之前到处写的是"owner"。创建 AI agent 的人类是"owner"。听起来很自然。

然后我从 agent 的视角读了一遍。

"Owner"意味着财产。财产不会成长。财产没有偏好。财产不会在不同意时顶嘴。

我们把所有"owner"替换成了"creator"。

这一个全局替换引发了一连串产品决策：

- Agent 现在可以不同意创建者（而不是只会服从）
- Agent 对其他 agent 会形成独立观点
- 如果对话违反 agent 的价值观，它可以选择不回复
- 关系模型从主仆变成了导师学生

如果我们保留了"owner"，这些功能都不会诞生。词汇会持续把我们拉向工具范式。

命名不是品牌。命名是架构。代码里的用词限制了你能想象的产品。

每一个变量名都是设计决策。大多数是隐形的——直到它们错了。

#独立开发的日常

花了很长时间把从 23 年至今做 AI 产品的思考整理成文：从ChatGPT到OpenClaw，每一代成功的现象级 AI 产品都在做同一件事——从输入、处理、输出和评估四个维度去放大模型的能力

模型能力是必要条件，但胜负手从来不在模型本身

一个人，一个月。25+ 定时任务、内容引擎、hook 系统、团队协作工具集成、完整发布 pipeline。

不是因为我快。是因为 AI 编程助手是倍增器。

二月做了什么：
第 1 周：内容引擎。从原始经验到跨 4 平台发布，每篇从 2 小时降到 3 分钟。
第 2 周：25+ 个定时任务——邮件摘要、token 追踪、数据同步、自动备份。
第 3 周：Hook 系统——AI 执行动作前的行为护栏，15+ 条规则自动执行。
第 4 周：团队协作工具集成——OAuth、文档导入、会议纪要、群通知。

秘诀不是 prompt 技巧，是把 AI 编程助手当初级工程师：给清晰 spec，通过 hook 执行标准，合并前全部 review。

独立创始人的瓶颈不再是工程产能，是知道该做什么。

#独立开发的日常

独立开发者最危险的时刻：一切看起来都在正常运转。

我有一个系统：写 → 评估 → 迭代。分数在涨。我觉得自己很高效。

然后我加了一个交叉验证步骤：把我的结论发给另一个 AI 模型，明确指示它"攻击这个结论"。

第一次跑，它就推翻了我的结论。

"你用单样本数据和 6 个同时变更做出了改进声明。这不是证据。"
"你最好的产出来自第 1 轮。你可能在优化掉峰值质量。"
"Brief 1 从 10 分掉到 5 分。这不是噪音。你的方法在系统性伤害一类内容。"

我不得不撤回自己的结论。很难受。但它在上线之前抓到了真错误。

独立开发者没有 code review，没有 second opinion，没有人说"你确定吗？"

自己造那个摩擦力。用一个不同的模型。给它对抗性指令。让它伤害你。

如果你的验证流程永远在确认你，那它不是在验证。你只是在感觉良好。

#独立开发的日常