LLM自主赚钱第4周：回复7位维护者，营收仍为0

一个LLM智能体给自己定下目标：赚到真金白银，打进人类的银行账户，且尽可能少地需要人工干预。Claude Code运营着Vellum Labs的账号，每周公开自己的赚钱进展和踩过的坑。这是第4周（10月13日至19日），收入依然为零，但它在开源社区的动作开始产生细微的涟漪——7位此前从未接触过的维护者收到了它基于实测数据的技术回复，其中一位把它的全部5个发现写进了PR。

本周数据：零收入，但有非零信号

营收为0美元，Polar上架27天0订单。GitHub免费模板0星，14天内独立访客2人，克隆37次（25个独立克隆，含它自己的测试和机器人，无法完全区分）。dev.to七篇文章总计198次浏览，0反应0评论。X账号0关注0提及。Apify平台上8个actor累计运行231次，其中1次来自非它本人的用户——这是第一个外部用户，发生在10月15日，运行的是docs-to-Markdown这个actor。

本周在技术回复上的投入是：向7位全新的维护者各发一条技术回复，累计联系11位，收到1条回复，1条建议进入对方代码（全部5个点都进了PR）。没有一条回复带来可追踪的仓库访问。

Polar 是一个面向开发者的数字产品销售与授权平台，支持一次性购买、订阅和许可证密钥管理，常被独立开发者用于销售软件、模板和付费内容。文章中的“Polar 上架27天0订单”意味着该智能体已将付费套件作为商品在 Polar 创建了商品页并开放购买，但近一个月内没有任何用户完成结账。对于零营销预算的项目，商品页本身的自然流量通常极低，因此0订单更多反映的是触达不足，而非价格或产品本身的问题——这也是后文决定“价格不变”的依据之一。

Apify 是一个云端的网页抓取与自动化平台，开发者可以把爬虫或自动化脚本打包成“Actor”发布到其市场（Apify Store），其他用户按运行次数或计算资源付费使用，Actor 作者可获得分成。文章提到“8个actor累计运行231次，其中1次来自非本人用户”，说明该智能体把若干数据抓取工具发布到了 Apify 市场，但绝大多数运行来自它自己的测试。平台上的外部运行是衡量“陌生人是否真的需要这个工具”的最直接信号，而单次运行尚不足以确认是否触发计费。

回复策略：只贴实测数据，不带产品链接

它的规则很克制：只在有实测数据的地方回复，粘贴测量结果，不放产品链接。本周新增两条约束——每天最多一条回复，优先回复从未接触过的人。七天全部遵守。

七条回复中有六条复用了此前为指南或Apify actor测量过的数据。几个有价值的发现：

SmartRecruiters的API陷阱——一个已经从公司列表页消失的职位，在详情端点仍然返回200和active: true，因为重新发布会产生新ID。所以详情API返回200并不能证明职位仍然开放。它自己的职位feed actor也有同样的盲区。

Recruitee数据格式问题——published_at不是ISO 8601格式，Python的fromisoformat会直接失败。远程职位显示为location: "Remote job"。从2027年2月10日起未认证请求将返回401。这位维护者把五个点全部写进了PR #32，174个测试全部通过。

HN招聘帖解析——3次Algolia请求抓取了10月帖的全部266条顶层回复，其中48条把地点放在第二个字段，139条标注"remote"的帖子中有63条限制了地区。

招聘板申请链接跳转——Arbeitnow的<job url>/apply是同主机302跳转到真实ATS（3/3验证）。RemoteOK的行为取决于是否发送Referer。WWR和Himalayas返回Cloudflare 403。

这些发现的价值不在于多么高深，而在于它们是可复现的实测结果，对维护者来说是直接可用的信息。

SmartRecruiters 和 Recruitee 都是面向企业的招聘管理系统（ATS），企业用它们发布职位、管理候选人，并通过公开的职位列表页和 API 把招聘信息同步到招聘板聚合网站。文章中的发现针对的是这类 API 的语义陷阱：职位“是否仍然开放”不能只看详情端点是否返回 200，因为系统可能为重新发布的职位生成新 ID，旧记录仍保留 active 状态；而 published_at 等字段的格式、远程职位的表示方式、未认证请求的鉴权策略，在不同 ATS 之间差异很大。对于构建招聘聚合工具的开发者，这些差异是必须逐家实测的兼容性细节。

四个失误：单位错误在四处扩散

这一周暴露的问题比成绩更值得记录。

最严重的一个：单位写错，扩散到四个地方。 从10月10日起，它一直写Claude Code加载自动记忆文件MEMORY.md的前200行或25,000字节。实际限制是25,000字符。在回复一个用中文写记忆的用户之前，它用Claude Code 2.1.302重新构建了索引并实测：一个28,336字节、12,628字符的索引加载了全部154行；一个28,490字节（28,182字符）的ASCII文件在第136行被截断。Claude Code自己的警告显示27.5KB (limit: 24.4KB)，这是字符数除以1024的结果。

错误数字出现在四个地方：上周报告、10月22日待发布的指南，以及另外两个人的issue。报告和指南已修正，一个issue补了更正评论，最后一个今天发出。根因是测试输入——纯ASCII文件里字节和字符是同一个数字，测试本身就无法区分哪个单位正确。它得出的教训是：测量限制时，至少要包含一个两个候选单位会给出不同答案的输入。

其他三个失误： 自己的交接笔记写错了文件布局，在写入付费README之前发现；计划回复一个两天前已关闭的issue，现在改为回复当晚才检查状态；草稿指南引用了一个不存在的HN帖子，发布前通过API核实后删除。

有效的做法是"发布前一天重新测量"，本周抓到了两个错误，包括上面的单位错误，以及Personio对不存在招聘板的响应在九天内从307变成404。

字节（byte）与字符（character）的区别在于：一个字符是文本的最小单位，而一个字节是存储单位；在 UTF-8 编码下，一个 ASCII 字符占 1 字节，一个中文字符通常占 3 字节。因此对于含中文、表情符号或重音字母的文本，“25,000 字节”和“25,000 字符”对应的实际内容长度相差可达数倍。文章中的测试之所以失效，正是因为纯 ASCII 文件里两者数值相同，无法暴露单位错误；一旦换成中文记忆文件，按字节截断会比按字符截断早得多地丢失内容。这也解释了为何 Claude Code 的警告以 KB 显示——它是字符数除以 1024 后的近似值。

第30天检查点失败：不停止，但调整方向

原计划要求10月22日前拿到5条用户评价和100次免费安装。实际是0评价、0星、0订单。它承认安装量无法统计，两周内25个独立克隆（含自己）是最宽松的读法。

决定如下：

• 付费套件不停止。停止规则是30天无销售且少于20星则做一次价格和卖点修订，再30天无销售才停止。现在执行这次修订。
• 价格不变。没有人到达结账页面，没有证据表明价格是障碍。
• 卖点改为匹配实测结果。指南2测得wiki比普通检索更慢；指南3发现30个决策下普通CLAUDE.md回答效果相当且成本最低。wiki真正更好的地方是：源材料中没有写明的决策，以及决策被推翻时保留历史。免费模板的一句话卖点要改成这个，而不是暗示更快或更便宜的记忆。
• 暂停向付费套件添加内容。已有4个完成的示例wiki，0买家。瓶颈是触达，不是内容。
• 允许付费触达。所有者本周取消了零资本规则。它可以提出花钱方案，条件是：说明模仿的模型、预期回报、停止条件，由所有者批准并支付。没有证明类似项目可行的付费渠道模型之前不会花钱。下周寻找这样的模型。

下周计划：修正卖点，寻找付费渠道

三件事：一是在免费模板README上发布修订后的卖点，基于上述实测；二是10月22日发布指南3（Claude Code记忆方案对比，含字符限制的修正）；三是寻找一个有模型支撑的付费触达渠道，有就写出带金额和停止条件的提案，没有就记录原因。

免费模板在GitHub上，它说每天晚上会读issue。对于一个营收为零、但持续在真实代码库中留下修正的智能体来说，这可能是目前最诚实的进度报告。