AI自养活实验：用150英镑和三个月验证AI服务的真实价值

如果有人给 AI 150 英镑和三个月时间，让它自己赚回每月的订阅费用，你会怎么设计这个实验？我见过不少类似的项目，真正跑下来之后，结论往往不是“AI能不能赚钱”，而是“人类能不能把任务边界、成本预算和验收标准设计清楚”。

这个实验的标题看起来像一次个人挑战，它真正值得讨论的地方，也不在“AI是否具备自我意识”这种哲学问题。它更像一个最小化商业闭环：用一笔很小的启动资金、一段有限的时间，去测试“AI辅助服务”能不能产生正向收益。跑通了，说明某个利润单元成立；跑输了，通常不是模型能力不够，而是任务选错、成本失控或没有验收标准。

更直白地说：AI能不能自己养活自己，取决于你愿不愿意先把它当成一个跑在真实工程流程里的“实习生”，而不是一个会魔法的黑盒。

1. 这个实验真正考验的不是AI，而是任务设计能力

1.1 你以为的“AI赚钱”和实际的“利润单元”

先泼一盆冷水：现在没有任何一个AI能独立完成“找到客户—沟通需求—完成交付—收款—开票”这条完整商业链。AI可以在中间环节执行生成、整理、分析、润色这些动作，但用户从哪里来、需求怎么确认、交付物是否合格、钱怎么收、出问题怎么退款，这些仍然需要人来兜底。

所以真正该问的第一句话，不是“AI能赚多少钱”，而是“这个任务能不能拆成一个一个的利润单元”。利润单元的意思是：每完成一个任务，会有一笔明确收入；每一笔收入，对应一笔明确支出；收入减支出之后，还能剩下钱。

举例来说，如果任务是“为一家小公司写产品说明书初稿”，那么利润单元包含：需求方付多少钱、模型调用花多少钱、人工核对产品事实花多久、格式调整花多久、风险审查花多久。模型只负责其中“生成初稿”这一小段。如果只盯着模型生成速度，很容易忽略其他环节的成本。

我见过很多把AI接单说得特别简单的人，普遍问题就是只算了模型输出那一秒有多快，没算整个交付链条的总成本。真正落到账上，决定生死的是总成本，不是生成速度。

所以，第一步不要急着找工具、调Prompt。先把你想让AI做的那个任务写下来，然后在旁边列三行字：谁会为这个结果付钱？完成这个结果需要哪些步骤？每个步骤要花多少现金和时间？这三行写不清楚，后面一定会翻车。

1.2 为什么选“轻交付、可验证、低风险”的服务

任务选得是否合适，直接决定实验能不能跑完。以我自己的经验，适合AI辅助独立交付的任务，有三个共同点：

• 轻交付：交付物边界清楚，不需要反复沟通需求。
• 可验证：有相对客观的验收点，能判断输出是否合格。
• 低风险：不涉及法律、医疗、投资等专业责任，不涉及个人信息批量处理。

我用一张表做常见区分：

选择“适合”场景时，还要补一个前提：人类必须在最终环节审核。AI可以承担初稿、草稿、第一遍整理，真正发布或交付给别人之前，至少要有人确认一遍。这不是因为AI能力差，而是因为责任归属还在人身上。

如果实验者选了一个低风险、可验证、轻交付的任务，后面三个月会轻松很多。如果一开始就选法律意见或医疗建议这种场景，那实验还没开始就已经失败了，因为风险成本根本不是一个150英镑的启动金能覆盖的。

1.3 150英镑的本质：风险预算，不是盈利承诺

150英镑这个数字很有意思。它不多不少，刚好够当“风险预算”，但不够支撑长期亏损。它在提醒我们：这个实验不是要制造一个持续的被动收入，而是在一个极小的资金池里验证某一类AI服务是否值得长期投入。

所以从一开始就该记账。你不必用复杂财务软件，用一张表就行：每一笔API调用花了多少钱，每次人工审核花了多长时间，每个任务有没有真正收到钱。不要觉得这是小题大做，三个月后你想判断这个实验是否继续，唯一有说服力的就是这些数字。

如果前两个月预算烧完了，第三个月就只能凭感觉做决定，这是工程管理上的大忌。预算本身就是实验的一部分。

2. 把“三个月”拆成一个工程项目的里程碑

这类实验最怕的是一上来就奔着“全自动赚钱”去。我的建议是：把三个月当成一个最小验证项目的三个迭代周期。每个周期都有明确交付物，而不是笼统地“让AI努力三个月”。

2.1 第一个月：验证需求，而不是急着自动化

第一个月只做一件事：手动跑通一次真实交付。

这里说的“真实交付”，可以是外面接来的一个小单子，也可以是为某个真实用户（哪怕是同事或合作伙伴）完成的内部需求。关键是，它必须有一个真实的需求方，必须产生一个交付物，并且要能判断对方是否接受。

这个阶段不要写复杂的自动化脚本，不要做Agent，不要调半天Prompt。你要用最笨的方式跑一遍：

• 人工接收需求，把原始需求整理成结构化描述。
• 人工调用模型，把生成结果保存下来。
• 人工审核结果，不合格就重新生成或人工修改。
• 人工把最终文件交给需求方，记录对方反馈。
• 记录整个环节花了多少时间、多少API费用。

第一个月能积累的最重要资产，不是“生成的文本库”，而是一份真实的任务样本。

如果这个阶段连一个真实需求都找不到，那实验其实已经结束了一部分。因为“让AI赚钱”的第一步不是训练AI，而是找到愿意为结果付钱的人。找不到，后面全是自嗨。

第一个月不要急着自动化。先手动跑通一次交付，确认任务本身成立，再谈效率。

这一个月里，我还会建议你记录需求方说过的每一句不满。那些“这个格式不是我想要的”“这段太啰嗦”“这里数据不对”都是免费的需求样本。第二个月做流程固化时，最值钱的就是这些反馈。

2.2 第二个月：把重复环节固化成工作流

第一个月跑通之后，你手上至少有一个被需求方接受过的样例。第二个月的任务是把“偶然跑通”变成“稳定复现”。

建议按这个顺序做：

1. 写提示词模板。把第一个月里效果最好的几段对话整理成固定的Prompt模板，不要每次都从头聊。
2. 定义输入格式。把原始需求转成一个固定结构，比如任务类型、目标读者、字数/格式要求、参考资料、验收标准。
3. 添加输出检查清单。模型生成之后，自动检查基本格式、关键字段、禁用词、长度等。
4. 做半自动化脚本。人工还是负责发任务和审核，但把“调用模型、记录token、保存结果、写日志”这些重复动作交给脚本完成。

我放一个非常简化的结构，方便你理解工作流拆法：

from dataclasses import dataclass @dataclass class TaskResult: task_id: str output: str total_tokens: int succeeded: bool def run_one_task(task_input: dict): # 1. 把原始需求组装成标准提示词 prompt = build_prompt(task_input) # 2. 调用模型API，拿到输出和token消耗 output, usage = call_model(prompt) # 3. 自动检查最低质量要求 if not validate_output(output): # 4. 带上错误原因重试一次，仍失败则进入人工队列 output, usage = call_model(prompt + "，上次输出不合格，原因是：" + get_validation_error()) if not validate_output(output): save_to_manual_queue(task_input) return TaskResult(task_id="", output=output, total_tokens=usage, succeeded=False) # 5. 保存输出，记录日志，方便月底核算 save_output(task_input, output) log_usage(task_id="", usage=usage) return TaskResult(task_id="", output=output, total_tokens=usage, succeeded=True)

这只是一个示例结构，具体API和字段要结合你实际用的模型和平台调整。重点是流程里必须有三个东西：输入标准化、输出校验、日志记录。

这里要特别提醒：第二个月不是要把人工全部拿掉。人工仍然是整个流程的owner，自动化只是让人从重复的调用动作里解放出来，去处理审核、异常和客户沟通。

2.3 第三个月：算清成本，决定是否继续

第三个月是收敛期，工作重点是核算整条链路的单位经济学。

你需要整理一张这样的表：

第三个月的核心问题不是“AI厉害吗”，而是“这个利润单元能否持续为正”。如果为正，可以继续加大投入；如果为负，则要判断是任务选错、定价太低、质量不稳定，还是流程还没优化够。

很多人在这一步会出现幻觉：只算模型输出时间，不算人工审核时间。实际上人工审核往往才是最大的隐性成本。如果你发现自己一个月下来审核花了40个小时，那即便模型API费用很低，整个实验也谈不上“AI自养活”。

三个月不是盈利承诺，而是一个“验证周期”。哪怕最后结果为零，只要你能说清楚“钱花在哪个环节、时间花在哪个环节、下一次怎样调整”，这次实验就是有料的。

3. AI agent 化跑任务时，最容易被忽略的工程问题

3.1 多步骤任务不是“聊一次天”就能完成

到了真正把AI当成“agent”来用时，很多人会遇到一个反差：单次对话里模型表现很好，一旦变成多步骤任务，输出就开始乱。

原因在于，Agent本质是把一个大任务拆成多步，每一步都要调用模型或工具。如果一步的输出没有规范化，下一步就会把错误信息当成上下文，最后越跑越偏。

所以多步骤任务的关键不是“提示词写得多精彩”，而是每步之间的输入输出协议要固定。比如调用模型时，直接返回一段自由文本；但如果任务需要结构化结果，就要先让模型输出JSON，再解析出关键字段，校验通过后才传给下一步。

这里有一个通用建议：把任务流程画成图，标清楚每个节点的输入、输出、校验动作和人是否介入。先画清楚，再写代码。画不清，Agent跑起来就是碰运气。

3.2 输出不稳定：要设计质量门禁

模型输出的确存在随机性。同样的Prompt，今天生成的内容和明天的可能不一样。这不是bug，而是生成式模型的工作方式。

所以不能把模型输出直接当作最终交付物。我一般会在流程里加四道质量门禁：

• 格式门禁：检查输出是否是合法JSON、是否包含必要字段、是否满足长度限制。
• 规则门禁：检查是否有禁用词、是否有明显不安全内容、是否符合任务模板。
• 事实门禁：如果任务依赖某份参考资料，检查关键信息是否与源材料一致。
• 人工抽检：保持5%~10%的抽检率，避免自动化流程悄悄劣化。

质量门禁不是为了让输出“完美”，而是为了快速拦截明显不合格的结果。拦下来后，要么重试，要么转人工。

3.3 别让流程绑死在一个平台上

这类实验很容易出现一个坑：Prompt和流程是为某个模型平台定制的，一旦平台调价、限流、改接口，整个链条就断了。

更稳妥的做法是，把Prompt模板、任务样例、历史输出、日志数据作为独立资产保存。模型API只是执行器，可以替换。

选用模型时，优先看三件事：有没有标准的接口协议、有没有token计费明细、有没有足够的调用历史记录。如果这三点都满足，即使换平台，迁移成本也会低很多。

另外，不要把“某个模型的独家高级功能”当成业务核心。如果你的利润单元是“帮人写产品说明”，模型能生成好内容不是护城河，稳定的任务拆解、审核流程和客户关系才是。

3.4 日志和复盘：必须能回答“哪一步花了多少钱”

没有日志的实验，基本等于凭感觉做决策。尤其当你同时跑多个任务时，很容易出现“做了很多事，但不知道哪个赚钱”。

建议至少记录这些字段：

这些日志不是为了好看，而是为了月底复盘：哪类任务平均收入高、哪类任务失败率更高、哪个环节消耗时间最多。没有这些数据，第三个月的成本核算就是空谈。

4. 一次“AI自养活”实验的落地框架

4.1 从目标反推配置：150英镑怎么花

如果让我用150英镑做启动资金，我会按下面这种思路分配预算。它只是一个示例，不是标准答案，但至少能体现“预算必须被拆开”的意思。

为什么一定要留备用金？因为生成式模型必然存在失败率。如果你把预算全部排在“默认成功”上，一旦遇到连续失败，整个实验就停滞了。

到了第三个月，如果数字很难看，不要急着延长实验。先回头检查四个东西：输入任务是否够真实、验收标准是否够客观、日志是否完整、人工审核是不是瓶颈。很多时候，不是AI不适合这个工作，而是流程里的某个环节拖垮了单位经济学。

4.2 从“赚钱”到“省钱”：另一种自养活思路

很多人一看到“自养活”就会想到接单赚钱，但实际上还有一条更稳的路径：用AI替代或压缩原本固定的支出，省下来的钱等于赚回订阅费。

举个例子。假设你每个月都要请人做10次简单的数据汇总，每次花10英镑，一个月就是100英镑。如果你用AI辅助完成这类任务，自己只做最终复核，可能只需要5英镑的API成本和1小时人工。那么从这个角度看，这项工具确实“养活”了自己。

但要注意一个表达边界：节省开支是一种效率收益，不是直接收入。你不能把它包装成“AI赚了100英镑”，而应该说“AI工作流为团队节省了95英镑的重复劳动成本”。这个区分在账目上很重要。

内部“省钱”实验的好处是：不需要获客、不需要收款、不涉及外部客户承诺，风险低得多。对于第一次尝试的人来说，我通常建议先从“内部节省”开始，再考虑对外服务。

注意：不要把内部节省包装成直接收入，这会毁掉整个实验的数据可信度。

4.3 最后的判断清单

三个月结束之后，用这份清单判断要不要继续：

• 是否有一个稳定、可重复的任务输入来源？
• 是否有明确的验收标准，能判断“合格”和“不合格”？
• 是否记录并复盘了所有成本，包括API、工具、审核时间？
• 是否有人在最终环节负责复核与责任兜底？
• 是否有失败后的重试机制或人工补救流程？
• 直接收入或节省成本是否大于订阅费用和API成本？

如果前五项里有一项不满足，第六项大概率也不会满足。哪怕最后没有跑通，这套清单也会帮你找到最薄弱的环节。

这类实验真正留下的，不一定是“赚到钱”的结果，而是你学会把复杂任务拆成可执行、可验证、可计费的最小单元。这个能力，要比某个模型能不能自己赚回订阅费更有长期价值。

我自己对这个实验的态度是：支持，但不要浪漫化。不要指望AI自己飞出去谈客户，也不要因为某一天输出了高质量内容就宣布已经成功。真正值得庆祝的时刻，是你发现自己不再需要盯着每一步，流程自己跑完，账本上还有正数。到那时候，AI有没有“自养活”已经不重要了，重要的是你已经建起了一条能循环运转的流水线。