我们做的 AI 朋友圈平台，核心业务就是调用大模型 API 给用户生成文案、海报、视频，再配上会员和积分体系变现。这篇记录的是**”开发 AI 业务”和”用 AI 写代码”完全不同的那些坑**——从调用大模型 API 到商业化的工程心得。

1. 大模型 API 不是普通 API，要当”不可靠服务”对待

调大模型 API 和调自己公司的接口完全是两码事：

• 慢：生成一张图、一段视频可能要几十秒，普通接口超时设置根本不适用；
• 贵：每次调用都在烧钱，用户多调一次就是一份成本；
• 不稳定：超时、限流、报错、内容不达标，什么幺蛾子都有；
• 无状态：同一个 prompt 两次调用，结果可能完全不一样。

工程上的应对：

1. 超时分层：HTTP 超时设长（60s+），但业务层要有自己的兜底
2. 重试策略：对可重试的错误（超时/限流）做指数退避重试
3. 异步化：生成任务丢进队列（process/task），用户不阻塞等待
4. 状态追踪：每个生成任务有状态流转（排队→生成中→成功/失败）
5. 结果校验：返回的内容做合法性校验，不达标自动重试或降级

心得：大模型 API 的正确打开方式是异步任务 + 队列 + 状态机，而不是同步请求等待。

2. 成本控制：积分系统是刚需，不是锦上添花

做 AI 业务，不控成本就是做慈善。我们做了会员 + 积分体系：

• 不同等级的会员有不同次数/额度；
• 每次生成消耗积分，积分可购买、可任务奖励；
• 免费用户限频限次，防止被薅。

工程上要配套：

- 调用前先扣积分（防并发超扣）
- 生成失败要退积分（用户不能白花钱）
- 限流器按用户维度限频（Redis 计数）
- 后台看板统计：按模型、按时段统计调用量和成本

心得：积分扣减和退还要做成事务，生成失败退积分这事最容易出 bug，也最容易引起投诉。

3. 消息/作品类型设计：先定好数据结构

平台的作品不只是图片，还有文案、视频、链接，甚至作品之间的引用。我们把内容类型统一成一套结构（chat.json 里定义）：

text       # 文案
image      # 图片
link       # 链接
video      # 视频
work_link  # 引用其他作品

每种类型有统一的字段规范（url、cover、duration 等），前后端、H5、分享页都按这一套结构解析。设计时多花一小时，后面少改一个月。

心得：AI 生成的内容形态会越来越多，内容模型要按”类型 + 通用字段”设计，别为某一种形态写死。

4. Prompt 也要工程化：模板管理 + 版本控制

文案、海报的生成效果全靠 prompt，但 prompt 不是写一次就完的：

• 同一个功能要跑 A/B 测试，比较不同 prompt 的效果；
• 用户反馈”生成效果差”，你得能回退到上一版 prompt；
• 不同会员等级可以给不同质量的 prompt（比如更高阶的模型/更细致的指令）。

我们把 prompt 做成了模板表，存数据库，后台可改，带版本号。改 prompt 不用发版，后台点一下就行。

心得：prompt 是 AI 业务的核心资产，必须模板化、版本化、可运营。

5. 用户对”AI 生成”的预期管理

产品层面的心得：用户对 AI 生成结果的预期，直接决定口碑。

• 生成慢的时候给进度反馈（排队中/生成中），别让用户干等；
• 失败时给友好提示 + 自动退积分，别让用户觉得被骗了；
• 生成结果支持”再生成一次”（同一 prompt 结果不同，用户会想再试）。

这些细节做没做到位，用户留存差距很大。

6. 广告变现：聚合平台 SDK 对接的坑

平台还接了广告变现（Taku 广告聚合）。这块和 AI 关系不大，但有个通用心得：聚合类 SDK 的对接，一定要让运营先在后台配好参数（应用 ID、广告位 ID、广告源），技术再联调。 我们第一次对接时两边并行推进，结果互相等对方，白耗了两天。

总结

做 AI 业务平台，技术难点不在”调通大模型 API”，而在围绕 API 的成本控制、异步架构、内容建模和运营体系：

大模型 API 只是发动机，发动机好开，车好不好开全看底盘——异步、重试、限流、计费、内容结构，这些才是核心竞争力。