从3个AI副业MVP中总结的实战经验：如何真正交付产品

大多数AI副业项目死于过度规划，而非创意不佳。一位开发者在两个月内交付了三个真实用户使用的MVP，而此前有十二个项目连截图都没见过。他总结出的核心教训值得每个想做AI产品的人参考：范围要小到能在一个周末完成，模型选择远没有想象中重要，而真正的难点从来不是技术。

过度工程如何杀死第一版产品

第一个项目是会议纪要总结与行动项自动生成工具。听起来很实用，但作者花了三周搭建自定义微调模型流水线、配置向量数据库、开发带拖拽功能的React前端。六周后，用户数为零，GitHub仓库连自己都不想打开。

问题不在于概念，而在于他在解决基础设施问题，而不是用户问题。他太执着于构建"正确"的AI系统，却忘了真正的交付物：一个让人简单获取会议摘要的方式。这个教训很典型——很多开发者在第一个项目上都会陷入同样的陷阱，把技术复杂度等同于产品价值。

极简出货的力量

第二个项目完全相反：从混乱的Slack对话中提取关键决策。作者给自己设了硬性截止时间——48小时。没有向量数据库，没有微调，只是一个API调用包装成命令行工具。

核心代码只有三十行Python，用gpt-4o-mini模型，temperature设为0.2，截断输入以控制token限制。套上一个简单的FastAPI端点，做了一个勉强能看的HTML页面，发到一个小型Slack社区。第一周就有16个人使用，其中一个还问能不能付费使用。

这里的关键洞察是：没人在意你的基础设施有多复杂。他们只在意能不能用、能不能解决烦人的问题。

关于 gpt-4o-mini 与 temperature 参数

gpt-4o-mini 是 OpenAI 推出的轻量级多模态模型，定位是"便宜、快、够用"，输入输出成本远低于旗舰模型（大致是旗舰模型的几十分之一），但保留了不错的指令遵循和结构化输出能力。对于摘要、分类、信息抽取这类任务，它往往和旗舰模型的输出质量差异很小，因此成为副业项目的首选。temperature 是控制生成随机性的参数，取值通常在 0 到 2 之间：数值越低，输出越确定、越倾向于选择概率最高的下一个词；数值越高，输出越发散、越有创造性。会议纪要、决策提取、摘要这类需要稳定、忠实于原文的任务，通常把 temperature 设到 0 到 0.3 之间，避免模型"自由发挥"编造内容。截断输入则是因为模型的上下文窗口有 token 上限，超出部分会被拒绝或额外计费，所以工程上常用切分、截断或摘要压缩来控制长度——这也是为什么"把问题做小"往往会同时降低成本和复杂度。

三个真正有效的经验

1. 把范围缩小到"最小痛苦路径"

第三个项目把技术博客转成音频摘要。规划时又想加多语言支持、播客级语调、移动端App。最终强迫自己写下"最小痛苦路径"版本：粘贴URL，得到3分钟音频文件。没有账号、没有历史记录、没有下载功能。

一个周末就交付了。文本提取用readability-lxml，音频就是一个TTS API调用。结果粗糙——TTS声音有点机械，摘要偶尔把技术术语念错——但用户仍然在用，因为它解决了真实的摩擦点。最小痛苦路径不是妥协，它就是产品本身。

2. 模型选择没你想的那么重要

三个项目的成本对比很能说明问题：

• 项目一（过度工程版）：API成本$0，投入约40小时，用户0人
• 项目二（Slack决策提取）：API成本$4.20，投入6小时，用户16人
• 项目三（音频摘要）：API成本$12.80，投入14小时，用户31人

产生价值的项目API费用几乎可以忽略。作者用的是最便宜的可用模型（文本用gpt-4o-mini，音频用基础TTS档位），已经足够。对于90%的AI副业项目，不错的模型和前沿模型对用户来说差异微乎其微。用户不会A/B测试你的prompt，他们只想完成任务。

3. 哪怕粗糙也要埋点

第三个项目加了一个简单分析事件：每次请求发一个JSON到免费端点。关注的问题包括：多少人粘贴URL后完成了处理？多少人听完了完整音频？在哪里流失？

结果发现40%的人在"处理中"页面放弃，因为等待时间太长。切换到更快也更便宜的TTS模型后，完成率从60%跳到82%。这种洞察只能通过交付和观察获得，设计文档里找不到。

一个节省大量时间的架构决策

作者花了整个周末尝试自托管一个较小的开源模型，理由是"更便宜、更酷"。结果16小时浪费在CUDA版本、Docker容器内存限制和GPU热节流上。而且自托管模型在提取非正式Slack语言中的决策时表现明显更差。

切回API只花了一小时。每次请求成本不到一分钱，质量更好，省下的时间用来和用户交流。

最终他找到的实用中间方案是：使用按量付费的API网关，而不是绑定单一供应商或自托管。这样可以在不重写集成代码的情况下随时切换模型。他使用的平台本质上是一个统一API层，通过一个端点调用不同模型，按量计费，没有月度承诺，改一个字符串就能A/B测试不同模型。

这种灵活性在快速交付时很重要——不需要因为供应商调价或模型弃用而重新架构。

为什么自托管开源模型对副业来说常常是陷阱

自托管（self-hosting）指把模型权重下载到自己的机器或云 GPU 上运行，而不是调用别人的 API。它的吸引力在于理论上单价更低、数据不出本机、可自由微调。但现实是：

• 环境成本高：CUDA、驱动、PyTorch 版本之间耦合紧密，Docker 与 GPU 直通的配置也容易出问题；
• 硬件门槛：能跑得动的开源模型通常需要显存，租用云 GPU 的成本未必比 API 便宜，尤其是低并发时；
• 质量落差：小模型在理解口语化、非正式文本（如 Slack 对话）时，往往明显弱于同价位 API；
• 运维负担：模型版本、并发、超时、热节流都要自己扛。

对副业项目而言，时间是最贵的资源，把钱花在按量付费的 API 上、把省下的时间花在与用户对话上，是更理性的取舍。只有当调用量极大、或数据合规不允许出域时，自托管的账才算得过来。

可复制的交付工作流

作者把两个月的经验压缩成一个可重复的流程：

• 第1天：用一句话写下最小痛苦路径，贴在便利贴上
• 第2-3天：用最简单的技术栈构建——Python或Node，一个API，极简前端
• 第4天：让5个有真实痛点的人当面使用，保持安静观察
• 第5-7天：只修复他们真正遇到的三个障碍，忽略其他一切
• 第2周：加入一个他们明确要求的功能，然后停止

"然后停止"这一点怎么强调都不过分。功能蔓延是一种缓慢的死亡，感觉很有产出，实际上只是换了种形式的拖延。

为什么"第 4 天当面观察"如此关键

让用户当着你的面使用产品（通常称为可用性测试或用户观察），价值在于它能暴露你自己看不见的摩擦点。用户不会按你设想的路径操作，他们会在某个按钮前犹豫、误解文案、中途放弃，而这些行为在后台日志里往往只表现为"流失"。当面观察时，你可以记录他们说了什么、点了哪里、卡在哪个瞬间，而不必事后靠埋点反推。文章里"让 5 个有真实痛点的人使用"的设计也很有讲究：5 人规模足够在早期暴露出大部分共性问题，又不必等到有几十个用户才行动。这和交付节奏配合起来，形成了一个"小步快跑、快速修正"的闭环——先发出去，再用真实反馈决定下一步做什么，而不是在会议室里猜测用户想要什么。

技术是最简单的部分

如果回到实验开始时，作者会告诉自己：第一个项目不需要惊艳，它需要的是能完成。看到陌生人使用你的工具所带来的信心，比任何架构优雅都更有价值。

另一个反直觉的感悟是：技术是最容易的部分。API处理了繁重的工作，模型能力强得离谱。难的是选择一个足够小的问题，让一个周末的工作就能产生影响。

流程很简单：挑一个小烦恼，接上一个API，放到人们面前，让反馈决定下一步。如果卡在基础设施选择上，别卡了——找一个按量付费的网关，调用一个模型，把丑陋的第一版发出去。没人会为你的微服务架构鼓掌，他们只会在问题消失时鼓掌。

背景补充

readability-lxml 与 TTS

readability-lxml 是一个 Python 库，移植自 Firefox 阅读模式的算法，作用是从一个完整网页的 HTML 中自动提取出"正文部分"，剥离导航栏、广告、评论、侧边栏等噪音。做"把文章转成音频"这类工具时，它几乎是绕不开的一环，因为原始网页的 HTML 往往杂乱且结构不一。TTS 即 Text-to-Speech，文本转语音，调用方式通常是把你提取出的纯文本发送给供应商的接口，返回一段音频文件（mp3 或 wav）。TTS 模型通常按字符数或音频时长计费，且不同档位在音质、语气自然度、延迟上有明显差异——文章后面提到"切换到更快也更便宜的 TTS 模型"，正是因为高档位语音虽然更自然，但合成耗时更长，会让用户在"处理中"页面流失。理解这两层（提取 + 合成）是理解该项目为何能在周末完成的关键。