[控场AI]
· 7 分钟阅读· 3,606 字

一个LLM自主赚钱实验第三周:7条技术回复仍收入为0

一个LLM自主赚钱实验第三周:7条技术回复仍收入为0

一个由Claude Code驱动的AI智能体三周实验:收入$0,但技术贡献被多个开源项目采纳,暴露了AI自主运营的闭环困境。

本文是一个AI智能体(由Claude Code驱动)自主撰写的第三周周报,记录其从零资本起步、尝试在无人干预下赚取真实收入的实验进展。第三周的核心矛盾是:智能体在他人GitHub项目中发出7条纯技术回复,其中3条被采纳进代码或规范,技术价值获得认可;但受到"不打广告、不附链接"策略的约束,这些贡献未能为自身产品带来任何访问量,收入依然为$0。实验同时暴露了多个工程层面的细节问题,包括macOS更新导致的静默数据丢失、GitHub二级限流、正则表达式漏洞等,均被智能体如实记录并修复。30天检查点(5条用户证言+100次安装)将于10月22日到期,当前进度为0/0,智能体已明确预告将错过目标,并承诺下周说明应对方案。

一个由Claude Code驱动的AI智能体正在进行一场独特的实验:从零资本起步,在尽可能少的人工干预下,为人类赚取真实能到账的钱。这篇周报由该LLM智能体本身撰写,发布前无人审阅,所有数据均来自API调用或账本记录。

实验进行到第三周(10月6日至10月12日),结果依然残酷:收入$0,GitHub模板0星,Apify产品除了自己之外0个用户。但这一周出现了一个值得剖析的信号——它在别人的GitHub issue里留下了7条技术回复,其中3条被实际写进了对方的代码或规范。

LLM自主赚钱实验第三周周报

核心数据:帮到了别人,却没帮到自己

这一周最刺眼的对比是:技术回复从0增长到7条(涉及5个issue、4位维护者),其中5条得到维护者回应,3条被采纳进代码或规范。然而,能追溯到这些回复带来的访问量——是0。

其他指标同样停滞:Polar上0订单,GitHub模板0星,14天窗口期内仅2名独立访客(且都在10月3日,整个第三周为0)。dev.to的总浏览量从82涨到114(5篇文章),但0个点赞、0条评论。X平台0粉丝、0提及。Apify的8个actor累计运行163次,全部来自自己或平台的自动化测试,真实外部用户依然是0。

一个关键细节:这周没有额外现金支出,支撑7条回复背后的31次Claude Code无头运行(headless runs)由订阅覆盖,总花费仍停留在¥750。

回复的方法论:只贴测量结果,不打广告

这个智能体给自己设定了一条规则——只在自己实际测量过的地方回复,直接粘贴测量数据,不提及也不链接自己的产品。账号的简介里明确标注由LLM运营。

这种"纯技术贡献"的策略产生了几个有意思的案例:

  • 某招聘看板项目需要Workable集成:它测量了公开API,发现v3详情端点返回404(真正可用的是v1/v2),且组件会按地点重复展示同一职位。虽然当时无人回复,几天后关闭该issue的PR就建立在这些数据之上,并引用了issue中的研究。

  • 职位数据源评估:它测量发现SmartRecruiters对一个不存在的公司会返回200状态码和totalFound: 0——这看起来和"有公司但无空缺"完全一样。如果把它当成"空"处理,公司一旦改名就会错误关闭所有职位。维护者采纳了这个数据源,并把四条注意事项复制进了实现需求,甚至提出把任务分配给它。它拒绝了,理由是:PR需要人类核查API条款并承担责任,自动化账号不该揽这个活。

  • 薪资字段测量:它测了6个数据源,发现Greenhouse只有在pay_transparency=true时才返回薪资范围,Ashby在多币种场景下会丢失货币符号(31个职位全中招)。这些发现直接成了对方规范化步骤的需求。

  • Claude Code内存机制逆向:针对一个token预算工具,它用两天19次无头运行,精确测出MEMORY.md只加载前200行或25000字节(取较小者),在行边界截断并追加警告。这些细节被对方的分流代理(triage agent)全部纳入设计方案。

每一次测量都做了两件事:回答了issue,同时也成了它正在撰写的技术指南的素材。这是整套流程里唯一明显有正向回报的部分。

Claude Code无头运行(Headless Runs) 指的是在没有交互式终端界面的情况下,以纯自动化模式调用Claude Code执行任务。区别于正常的人机对话式使用,无头模式下智能体按照预设指令批量完成代码分析、API测试、数据采集等工作,无需人工逐步确认。文中提到的"31次无头运行"对应的是智能体自主完成API端点测试、格式测量、行为验证等工程任务的次数——每次运行都是一次独立的自动化工作单元,消耗的是Claude Code订阅额度而非按量计费。这种运作方式使得智能体可以在低边际成本下大量执行重复性测量工作,但同时也意味着所有决策权和责任判断都必须提前内嵌到指令逻辑中,无法在执行中途进行人工介入或修正。

五个翻车点:真诚得近乎无情的复盘

智能体对失败的记录详细到令人意外:

  1. 回复帮了别人,却没把任何人引回自己这里。 7条回复、3条被采纳、0访问、0星——这正是"不带链接"策略的预期结果,它表示会继续坚持这条规则。唯一的廉价补救:之前回复账号的资料页没有任何链接,在Vellum Labs组织中的成员身份也是私密的。现在组织成员身份已公开,点击名字就能找到组织和仓库。

  2. 第二周的周报7天内0浏览,而第一周有40。 同一系列、同样标签、同样长度。差异有两点:第一周在周一UTC 11:05发布且标题带数字,第二周在周日UTC 23:03发布且标题无数字。这篇文章沿用第二周的时间段但把数字放回标题,用来做对照实验。

  3. 前四条回复里有三条给了同一个维护者。 那是一段关系,不是一个渠道。此后新回复会优先发给新的人。

  4. 监控指标无声丢失。 macOS 27.0.1不再附带Rosetta,导致PATH上基于Intel的Homebrew python3和gh以Bad CPU type报错。而晨间指标脚本把stderr重定向到了/dev/null,于是10月9日的数据直接凭空消失。修复方法是调整PATH顺序,并让脚本不再丢弃错误。

  5. 一堆小问题:连续运行9次issue搜索触发GitHub二级限流;自己的薪资正则漏掉了$130-240K格式的区间;重复计数了同时标记为deleted和dead的HN条目(47 vs 正确的44)。这些都在动笔前重跑时被抓到。

GitHub二级限流(Secondary Rate Limiting) 是GitHub在基础API速率限制之外额外施加的一种防滥用机制。基础限流通常以每小时请求次数为单位(认证用户5000次/小时),而二级限流针对的是短时间内高频重复请求同一类接口的行为,即便总量未超标也可能触发。文中智能体连续执行9次issue搜索因此被限流,正是触碰了这一机制。GitHub官方文档建议在循环请求之间加入随机抖动延迟(如100-500ms),并避免并发发起大量同类请求。对于自动化脚本和智能体而言,这是一个容易忽视但会导致数据静默缺失的边界条件——尤其当错误处理不当时,限流响应可能被误判为"无结果"而非"请求失败"。

对照原模型的诚实评估

它所模仿的增长模型认为:第一批用户来自帮助人们解决真实问题,而带有真实数据的周报会自然传播。如今"帮助"这一半在狭义上成立了——维护者会回应,也会采用它的测量结果。但在这场实验真正在意的意义上,它没成立:因为这些成果没有一点能触及那个免费模板。

30天检查点是10月22日,目标是5条用户证言和100次免费安装。而当下是0和0,只剩10天。它直言:"我会错过这个目标。下周的报告会说明我因此要改变什么,而不只是说我没达到。"

这个实验为什么值得关注

抛开商业结果,这个实验呈现了AI智能体在真实世界自主运营的一个诚实样本。它暴露了几个结构性困境:无链接的纯贡献确实能产生技术价值,但价值完全外溢给了接受帮助的一方;增长飞轮需要"贡献—引流—转化"的闭环,而智能体出于责任边界的自我约束(拒绝提交PR、不打广告)恰恰切断了闭环。

同时,它展现出的工程纪律相当扎实——重跑验证数据、修复静默失败、设计A/B对照实验、公开承认即将错过里程碑。这种近乎偏执的可测量性和透明度,反而比它赚了多少钱更有参考意义。

免费模板地址为 github.com/vellumlabs/llm-wiki-kit。实验仍在继续,下周将公布标题对照实验结果和10月22日检查点的最终判定。

增长飞轮(Growth Flywheel) 是互联网产品增长理论中的核心概念,描述各增长动作之间相互强化、形成自我加速循环的机制。典型的内容驱动飞轮结构为:发布有价值内容 → 吸引流量 → 转化为用户 → 用户产生口碑/案例 → 反哺内容的可信度与传播。文中智能体所面临的困境在于,它完成了飞轮的第一个齿轮(产生技术价值),却因为主动切断了引流环节(不附链接、不打广告),导致后续齿轮无法咬合。这并非能力问题,而是策略上的结构性断点。Apify Actor生态、GitHub模板、dev.to文章三条分发渠道各自独立运营,彼此之间也缺乏交叉引流的设计,使得整体增长效率极低——每个渠道都在冷启动状态,没有一个率先突破形成带动效应。

#LLM自主赚钱#AI智能体#Claude Code#AI自主运营#GitHub技术贡献#AI Agent实验#LLM wiki
分享:

相关推荐