付费功能定价：先花几毛钱真测，再定额度价

一、为什么写这篇

我是 Hugozen。给付费功能定价，我早期的做法是拍脑袋：参考同类产品，凑一个看着合理的数。这个做法的问题是，只要功能背后每次调用都有真实成本，比如调用模型，定价就必须建立在实测的单次成本上。拍脑袋定的价格，要么亏钱，要么吓跑人。

所以我现在的规矩是：先花几毛钱真测，再定价。 这篇讲两件事：怎么用很小的预算测出成本和质量，以及功能真正上线时，生产数据库迁移该走什么流程。

先说明边界。我不写这个功能在哪个站，不写参与对比的具体模型和评测细节，也不写具体价格。我只写方法，因为方法能复用，细节没有复用价值。

二、小额真测：几毛美元级就够

举个例子：我给一个站做过一个「识别图片中文字」的付费功能，也就是 OCR 一类的能力。要不要做、怎么定价，当时我心里没底。做法如下。

1. 先定两个候选方案。 我拿两个模型来比，一个偏便宜，一个偏贵。问题不是「哪个更强」，而是「便宜的那个够不够用」。如果便宜的够用，利润空间就是另一个量级。

2. 准备一小批真实样本。 样本要贴近用户真实会传的东西，不要只挑好看的。我故意放进一些不太友好的输入，比如拍得歪的、光线差的、版面杂的。样本量不用大，能覆盖典型情形就行。

3. 总预算压在几毛美元级。 整轮对比花掉的钱，是几毛美元级别。这个数字有两层意义：一是它足够小，输了也不心疼；二是它足够用，因为你要的是「单次成本的量级」和「质量差距明不明显」，不是统计显著性。

4. 记录两样东西：质量和单次成本。 质量我是人工逐条看，标出「能直接用」「要小改」「不可用」三档。单次成本用总花费除以调用次数，再留出重试和失败的余量。

5. 再决定定价形态。 定价形态要和使用频率匹配：用户的使用是持续的还是间歇的，决定了更适合按额度收，还是按周期收。额度价则是按实测单次成本加上余量、再加上我愿意留的毛利来倒推的。具体数字我不写。

测试也要用该站专用的封顶 key

这一条我踩过边缘，所以单列。

做测试的时候，最省事的办法是随手借用另一个站已经在用的 key。我不这么做。每个站有自己专用的 key，并且设了花费上限，测试也只用这个。 原因有两点：

• 借用别站的 key，测试的花费会混进别站的账里，之后你根本分不清哪笔钱是哪个功能烧的，成本核算就废了。
• 万一测试脚本写错了、陷入重试循环，封顶的专用 key 最多烧到上限就停；借来的 key 没有这层保护，还可能连累别站的正常服务。

我之前在文章里提过，对 bot 要「有边界和预算意识，不允许无限重试」，这里是同一个原则落到 key 上。

三、生产数据库迁移：三步，顺序不能乱

功能要上线，通常要改数据库结构，比如加表、加字段。这类改动是不可逆风险最高的一环，所以我固定走下面的流程。

第一步：留后路。 迁移前做两件事：

• 打一个时间点回滚书签，记下迁移开始前的那个时间点。出事时可以直接回到这个点。
• 另外做一次导出备份，存到本地。回滚书签依赖平台的能力，我不想把全部退路都押在同一个地方，所以再加一份自己手里的备份。

第二步：迁移。 只执行迁移本身，不在同一个动作里顺手改别的。迁移完先自己查：表结构对不对，旧数据还在不在，关键查询能不能跑。

第三步：打开功能开关。 迁移成功之后，才把功能开关打开。代码可以先部署，但功能在开关关闭时对用户不可见。这样「数据库改动」和「用户看到新功能」是两个独立的动作，哪一步出问题都能单独退。

这个顺序的好处是：每一步都有明确的退路，而且每一步的失败都不会连带下一步。

新功能先保持支付关闭

这里还有一条我特别强调的：新功能上线时，支付先保持关闭。

功能开关打开以后，我先自己用、先观察，确认功能本身表现正常，再去开收款。理由很直接：如果功能有 bug，而支付已经开了，那就是用户付了钱拿到坏结果，要处理退款，还伤口碑。反过来，功能先跑稳、支付后开，最坏情况只是一个免费 bug。

另外，没准备好的付费选项不要摆在定价页上。一个灰掉的「还没开放」按钮，既劝退用户，也量不到有效点击；不如直接改成 coming soon，或者干脆不展示。

支付、数据迁移这类动作，我都要求自己批准、自己深审，不交给 bot 自动做。这条和我在 Agent 协作那篇 里讲的验收原则一致：把「相信」换成「核对」。

四、踩坑与取舍

• 别用旗舰模型当默认。 贵的模型质量更好，但如果便宜的在你的真实样本上够用，定价空间差很多。是否够用，要靠样本说话，不要靠印象。
• 样本别只挑好的。 只拿漂亮输入测，会得到过于乐观的单次成本，因为真实世界里重试和失败更多。
• 成本要留余量。 实测的单次成本是均值，不含波动。额度价里要给失败重试、偶尔的异常输入留出缓冲。
• 测完别急着发布。 我曾经想测完直接开支付，后来改成「迁移 → 开关 → 自测 → 再开支付」，多出来的这几步，省过不少返工。

五、可执行清单

1. 先定「候选方案」，把问题定成「便宜的够不够用」，不是「谁更强」。
2. 准备一小批贴近真实、包含不友好输入的样本，量不用大。
3. 整轮对比预算压在几毛美元级，用该站专用且设了花费上限的 key，不借别站的。
4. 记录两项：质量分档（可直接用 / 要小改 / 不可用）和单次成本（含重试余量）。
5. 按实测成本倒推额度价，并选与使用频率匹配的定价形态。
6. 迁移前先打时间点回滚书签，再做一份本地导出备份。
7. 先迁移、自查，再打开功能开关；两个动作分开做。
8. 新功能上线先保持支付关闭，自己跑稳再开收款；没准备好的付费选项不要摆出来。

六、链回旗舰

这篇讲的是「功能级」的定价和上线流程。如果你还在想站点整体该走广告、一次性收款还是订阅，可以看我的商业化旗舰：独立站变现方法。那篇讲的是路径选择，这篇讲的是路径选好之后，一个具体付费功能怎么测、怎么定、怎么稳妥地上线。

我的内容分成三条线：Agent 协作、SEO·出海、商业化，可以通过 RSS（/posts）订阅，新文章会按线更新。