变现、定价与“成本 ↔ 质量”实验

1. 为什么现在就要考虑变现

在此之前的核心问题是“这玩意儿到底能不能跑起来？”。现在我们把难度再往上加一层：“能不能回本？”。

对 LLM 应用来说这点尤其“疼”：可变成本（LLM tokens、rerank 模型、embedding）完全不同于你习惯的“20 美元的服务器和 15 美元的 Postgres”。忽视这些——月底你会收到一张来自 OpenAI 的账单，和房贷差不多。

因此今天有三大主题：

1. ChatGPT App，尤其是我们的 GiftGenius，可以采用哪些变现模型。
2. 如何把 pricing ↔ cost_per_task 关联起来，避免卖出“1 美元 100 次礼物推荐”，而一次推荐本身就要 0.15 美元。
3. 如何开展A/B 实验“成本 ↔ 质量”：更换模型、调整 prompt、优化 UX，并以正确的日志方式记录，从而在几周后基于数据而不是感觉做决策。

同时我们也为下个模块的 LLM‑evals 与 quality_score 埋下伏笔，但暂不深入到代码。

2. ChatGPT App 的变现模型：B2C、B2B、免费增值与加售

撇开 LLM 魔法，这里的变现模型与常见的 SaaS 和移动应用很相似。但对对话式界面有个细节：用户常常感受不到“哪里免费，哪里付费”，需要在 UX 中精心设计。

我们以 GiftGenius 来看几个主流选项。

B2C：普通用户与送礼

这里你的客户是普通人，他们在 ChatGPT 里说：“给一个太空迷挑份 50 美元的礼物”。你不一定卖自有商品，可以只做礼物挑选。

典型 B2C 模式：

1. 一次性购买。
   用户为具体场景付费。例如：免费 3 个点子，之后——购买一个“包”，为同一收礼人再给出 10 个点子。
2. 订阅。
   按月付费。对 GiftGenius 来说可以是“每月最多 100 次挑选”或“高频送礼者不限次数挑选”。
3. 免费增值（free vs paid tiers）。
   基础场景免费（每月至多 N 次、功能受限），付费层提供更高额度、更强模型、额外的挑选格式和历史记录。这是 ChatGPT App 最常见的模式：“在 ChatGPT 里基础免费，高级能力要付费”。
4. App 内加售（Upsell）。
   用户先做一次免费的基础挑选，看到结果不错，你再温和地提出：“要不要花 $X 来做一次深度挑选，结合愿望清单、社媒等？”或者“直接购买礼品卡吧”。

B2B：团队、公司与企业礼品

这里会涉及 HR、市场部，以及“负责员工/客户礼品的人”。

常见组合：

• 按席位授权（per seat）。
  例如“HR‑Team”计划 10 人版，每人可使用 GiftGenius，并提供礼品与预算报告。
• 按公司授权（per company）。
  “最多 500 名员工，按月固定价格，公司内部不限次数挑选”。
• 额外 enterprise 能力。
  独立管理后台、与 HRIS/CRM 集成、自定义报表、SLA 等。

在这两种情况下，你不再按“一次挑选多少钱”来算，而是计算 cost_per_user_per_month 或 cost_per_tenant_per_month，并与授权价比较。

如何为 GiftGenius 选择模型

避免陷入纯理论，可以先从一个简单的起步方案开始：

• B2C：免费增值。
  每月 3 次免费挑选；之后——每月 $5 订阅，不限次数，并使用高级模型。
• B2B：按公司计费。
  “HR‑团队”套餐 $99/月，包含最多 500 次员工礼物挑选，与 HR 系统集成和报表。

当你拿到真实的 cost_per_task 和转化数据后，再不断调优。事实上这些数字目前只是“拍脑袋”：看起来合理，但我们还没验证一次完整场景到底花多少钱。下一节我们会把这些定价与真实成本——cost_per_task——对应起来。

3. 价格与成本的关系：什么是 cost_per_task

现在进入最关键的部分：如何避免把自己做成 GPT‑5 慈善基金。

直觉：价格 ≥ cost_per_task × 利润系数

在上一话题你已经见过 cost_per_task：它是一个成功场景的总成本——从“用户开始挑选”到“拿到结果”（以及可能发生的支付）。

它包含：

• LLM 成本（tokens × 入/出 price_per_token，可能包含 rerank 模型、embedding 等）；
• 单个 task 分摊的基础设施成本（服务器、DB、队列、MCP 网关）——通常按聚合数据折算；
• 可选——交易成本（Stripe 手续费、风控），如果你把 cost_per_task 计算到“实收净额”之前。

理念很简单：单次场景或订阅的定价应高于“单次场景平均成本 × 利润冗余”。

极度简化就是：

price_per_task >= cost_per_task * ( 1 + margin )

我们不会拿一堆百分比把课程塞满，重要的是这个直观规则。

GiftGenius 示例

假设你已经接入了上一讲的成本日志，并且有一份聚合报告：

• 平均 cost_per_task（一次完成的礼物挑选）＝ 0.15 USD；
• 其中已包含 LLM tokens（多次调用 suggest_gifts、rerank 与最终 summary）以及基础设施分摊。

然后看一个用户行为路径：

• 免费用户做了挑选，偶尔会买一张 50 美元的礼品卡；
• 在完成挑选的场景中，假设 5% 转化为购买。

先不做全量单元经济学，但可大致估算：如果 100 次挑选中：

• 成本是 100 × $0.15 = $15；
• 其中 5 次完成了 $50 的结账；
• 营收 5 × $50 = $250。

看起来不错：粗略地说 ($250 – $15)，再加上 Stripe 手续、税费等。但要注意，若订阅过于“慷慨”（比如 1 美元包 100 次挑选），你会轻松陷入亏损。

迷你代码示例：在 TypeScript 中保存 cost_per_task

假设你有一个 MCP 工具能完成挑选流程并拿到总成本：

// 场景最终指标的类型
type TaskMetrics = {
  taskId: string;
  userId: string;
  costPerTaskUsd: number;
  modelName: string;
  completedAt: string;
};

// 记录指标的示例函数
async function logTaskMetrics(metrics: TaskMetrics) {
  console.log(JSON.stringify({ 
    level: "info",
    event: "workflow_completed",
    ...metrics,
  }));
}

// 在完成礼物挑选的处理器中某处：
await logTaskMetrics({
  taskId: context.taskId,
  userId: context.userId,
  costPerTaskUsd: context.costEstimateUsd, // 由 tokens 计算得出
  modelName: context.modelName,
  completedAt: new Date().toISOString(),
});

这种日志之后很容易在仪表盘里聚合，以查看不同模型、用户、场景的 cost_per_task 分布。

4. 定价：如何把 cost_per_task 映射为真实价格

既然已经有了 cost_per_task，接下来要决定向用户按什么收费、收多少。

B2C 的简单规则

对 B2C 可以用一个经验规则：

“我们愿意把 LLM+基础设施成本控制在营收的最多 X%。”

例如你决定不希望在 LLM 成本上超过营收的 20%。那么：

• 如果 cost_per_task = $0.15，那么单次付费场景的最低价格应 ≈ $0.75，使得 0.15 约为 0.75 的 20%；
• 如果卖订阅，就要估算每个订阅者每月会用多少平均场景数，再据此相乘。

先“凭感觉”起步完全没问题，等有了真实数据再调整（剧透：不会立刻就有）。

B2B 的简单规则

B2B 通常关注：

• cost_per_user_per_month 或 cost_per_tenant_per_month；
• 客户愿意为你解决的问题付多少钱（痛点大小）。

例如，如果 HR 团队通过 GiftGenius 每年分配价值数万美元的礼品，即便你的 LLM 成本对这一团队每月只有 10 美元，卖 99 美元/月的订阅也并不夸张。关键是不要陷入 不想看到的局面：cost_per_tenant = $80，而订阅价只有 $50。

而这种事会发生，如果你抱着“我们是 AI，先免费着，之后再说”的想法。

服务端一个小“护栏”函数

你可以直接在代码里放一个简单的“guard”，帮助你在定价时快速判断成本是否超出合理范围：

function checkPricingSafety(params: {
  avgCostPerTaskUsd: number;
  plannedPricePerTaskUsd: number;
  maxCostShare: number; // 例如 0.3 = 30%
}): boolean {
  const share = params.avgCostPerTaskUsd / params.plannedPricePerTaskUsd;
  return share <= params.maxCostShare;
}

// 示例：
checkPricingSafety({
  avgCostPerTaskUsd: 0.15,
  plannedPricePerTaskUsd: 0.75,
  maxCostShare: 0.3,
}); // true —— 没问题，20% < 30%

这不能替代财务模型，但能提供快速的“理性检查”，尤其当你在频繁试验价格时。

5. “模型/代理 vs 成本与转化”的实验

现在来到最有意思的部分：A/B 实验。

直觉很简单：

• 方案 A——昂贵模型 / 更复杂的 workflow；
• 方案 B——便宜模型 / 更简化的 workflow；
• 我们希望同时理解它对以下方面的影响：
  • cost_per_task，
  • 结果质量（用户感受与未来的 LLM 评分），
  • 业务指标（转化、营收）。

到底对什么做实验

三条主要轴：

1. 模型。
   例如 GPT‑5 vs GPT‑5‑mini 或完全不同的型号。通常昂贵模型质量更好且 cost_per_task 更高；便宜模型相反。
2. 代理逻辑 / prompt。
   更细的步骤、更长的 prompt、更复杂的推理——质量可能更好但更贵；极简逻辑——更便宜，有时质量几乎不输。
3. UX 形式。
   冗长的向导、丰富提示 vs 快速 inline 模式。即便模型相同，token 数和步骤次数也可能相差数倍。

这些变化你都可以实施，关键是把它们包装成带日志的实验。

实验需要记录哪些字段

在已有成本日志字段（tokens、model、cost_estimate、user_id、request_id 等）之上，加入实验字段：

• experiment_id——实验的唯一标识（例如 "gift_model_ab_2025_11"）。
• variant——用户所在分支："A"、"B"、"control"、"treatment" 等。
• model_name 或 agent_version——避免日后回忆具体配置。
• 场景结果：
  • 是否 workflow_completed；
  • 是否 checkout_success；
  • 最终的 cost_per_task。
• 可选——quality_score（稍后详谈，它是通往 LLM‑evals 模块的桥）。

实验事件的 JSON 日志示例

典型日志事件如下：

{
  "level": "info",
  "timestamp": "2025-11-21T20:15:03.123Z",
  "event": "experiment_task_result",
  "experiment_id": "gift_model_ab_2025_11",
  "variant": "A",
  "user_id": "user_123",
  "task_id": "task_456",
  "model_name": "gpt-5.2",
  "workflow_completed": true,
  "checkout_success": false,
  "cost_per_task_usd": 0.18,
  "quality_score": null,
  "request_id": "req_abc",
  "trace_id": "trace_xyz"
}

这类记录非常利于在分析系统里做聚合：你可以构建“A vs B 在 cost/转化/收入上的对比表”。

代码示例：在 MCP‑tool 中记录实验

设想你的 MCP 服务器已经算出该场景的成本（cost_per_task），也知道用户在实验的哪个分支：

type ExperimentContext = {
  experimentId: string;
  variant: "A" | "B";
};

async function logExperimentResult(params: {
  ctx: ExperimentContext;
  userId: string;
  taskId: string;
  modelName: string;
  costPerTaskUsd: number;
  workflowCompleted: boolean;
  checkoutSuccess: boolean;
}) {
  const event = {
    level: "info" as const,
    event: "experiment_task_result",
    timestamp: new Date().toISOString(),
    experiment_id: params.ctx.experimentId,
    variant: params.ctx.variant,
    user_id: params.userId,
    task_id: params.taskId,
    model_name: params.modelName,
    cost_per_task_usd: params.costPerTaskUsd,
    workflow_completed: params.workflowCompleted,
    checkout_success: params.checkoutSuccess,
  };

  console.log(JSON.stringify(event));
}

在更上层，你会决定用户属于哪个分支（基于 user_id、tenant_id 或随机），并将 ExperimentContext 传入 workflow 处理器。到这个层面，我们已明确要为实验记录哪些字段、在哪里记录。接下来会讨论如何把这些实验转化为清晰的产品假设与定价决策，而不是一堆日志。

6. 再聊聊 quality_score 与 LLM‑evals

更详细的内容会在第 20 个模块展开。现在只给出核心概念：quality_score 是对答案/方案质量的评分，比如 0 到 10，通常由单独的 LLM “法官”给出。关于 LLM‑as‑judge 我会在第 20 模块详细说明。

实现细节当下不重要——那是下一模块的主题——关键是先理解理念：

• 除了钱，我们还想衡量质量；
• 我们可以让人或者第二个模型来评估：“GiftGenius 的礼物挑选有多好，按 10 分制打分？”；
• 之后可以观察 quality_score 与以下指标的相关性：
  • 购买转化；
  • 用户留存；
  • 付费意愿（willingness‑to‑pay）。

从日志角度看，它只是又一个字段：

type ExperimentResultEvent = {
  experiment_id: string;
  variant: string;
  user_id: string;
  task_id: string;
  cost_per_task_usd: number;
  quality_score?: number; // 0-10，可能为 undefined
};

本讲先到这里：LLM‑evals、golden cases 与“LLM‑as‑judge”的细节会在后面展开。现在只需明确，把这个 score 接入到实验里的意义——它能避免“只按成本优化”的经典错误：通过数字化方式看清我们是否已经过度降本而开始损失质量，从而连带丢掉转化和营收。

7. 如何用实验服务于定价与变现

我们不只是记录实验日志，而是把它们变成有明确成功指标、能影响变现的业务假设。仅记录 experiment_id 远远不够：关键是把产品变更表述为带清晰成功指标的假设。

假设示例：昂贵模型 vs 便宜模型

以 GiftGenius 的一个实验为例：

• 方案 A——昂贵模型（GPT‑5）、更丰富的推理、较长的向导。
• 方案 B——便宜模型（GPT‑5‑mini）、略简的 prompt，较短的对话。

假设：将模型替换为便宜版本会让 cost_per_task 至少下降 50%。同时用户感受与 LLM 评分（我们的 quality_score）的质量下降不超过 5–10%，而购买转化不下滑。

技术上，对每个 task 记录与第 5.2 节相同的字段：

• experiment_id = "gift_model_ab_2025_11"；
• variant = "A" 或 "B"；
• model_name；
• cost_per_task_usd；
• workflow_completed；
• checkout_success；
• quality_score（当接入 LLM‑evals 后）。

一两周后你可以：

• 比较 A 和 B 的平均 cost_per_task；
• 比较 checkout‑rate（含成功支付的场景占比）；
• 比较平均 quality_score（如果已接入）。

如果 B 的质量几乎不输、但成本低一半，你可以：

• 切到 B，提高利润率；
• 或者维持成本，降低用户订阅价（以加速增长）。

假设示例：高质量加售

另一个假设：在给出 3 个免费点子之后，展示一个高端加售“完整礼物报告 + 贺卡文案建议”，售价 $4.99；购买转化至少提升 2 个百分点（2 p.p.）。同时 cost_per_task 增加不超过 $0.05。

这里的实验与其说是模型，不如说是UX 与产品逻辑。但技术上仍然相同：

• 用 variant 区分不同 UX；
• 按场景记录成本和收入；
• 分析 uplift（新逻辑带来了多少增收，且没有炸掉成本）。

代码示例：记录任务级别的简单营收

有时把成本与营收并排记录很方便：

type RevenueEvent = {
  taskId: string;
  userId: string;
  experimentId?: string;
  variant?: string;
  revenueUsd: number;
  checkoutSuccess: boolean;
};

async function logRevenue(event: RevenueEvent) {
  console.log(JSON.stringify({
    level: "info",
    event: "task_revenue",
    timestamp: new Date().toISOString(),
    ...event,
  }));
}

随后将 task_revenue 与 experiment_task_result 通过 taskId 关联起来，就能为每个分支计算：

• 平均 revenue_per_task；
• 平均 cost_per_task；
• 并据此构建最简单的 ROI。

8. 实战练习：GiftGenius 的 A/B 实验

为了把理论落地，我们来走一遍 GiftGenius 的“昂贵 vs 便宜模型”的实验流程，逐步说明，作为实战练习。

我们改什么

• 方案 A：
  • 模型 gpt-5；
  • 更细的 system‑prompt 与代理步骤；
  • 可能更多中间推理调用。
• 方案 B：
  • 模型 gpt-5-mini；
  • 稍紧凑的 prompt；
  • 更少的辅助 tool 调用，更简的流程。

如何将用户分配到分支

最简单的方式——对 user_id 取 hash：

function assignVariant(userId: string): "A" | "B" {
  const hash = Array.from(userId).reduce((acc, ch) => acc + ch.charCodeAt(0), 0);
  return hash % 2 === 0 ? "A" : "B";
}

这样可保证相对均匀分配，且同一用户始终落在同一分支。

记录什么

在礼物挑选 workflow 结束时，记录与前面（5.2 与 7.1）相同的一组字段，并补充营收：

• experiment_id = "gift_model_ab_2025_11"；
• 来自上述函数的 variant；
• 实际使用的 model_name；
• cost_per_task_usd，即 tokens 与基础设施的总成本；
• workflow_completed（true/false）；
• checkout_success（true/false）；
• revenue_usd（0 或实际购买金额）。

可选（稍后课程中）加入 quality_score。

这些数据会进入你的日志/分析，并可整理成如下表格：

从表中可见，B 的收入几乎相同，但成本低一半——这是选择 B 的强力论据。

9. 可视化：成本 ↔ 质量 ↔ 变现 的闭环

为便于整体把握，我们画一张“小而全”的数据流示意：

flowchart TD
    U[ChatGPT 中的用户] --> A["ChatGPT App (GiftGenius)"]
    A --> E[实验模块
分配 variant A/B]
    E --> AG[Agent / MCP tools
使用不同模型]
    AG -->|LLM 调用| L[usage & cost 日志]
    AG -->|挑选结果| UI[组件 / 聊天回复]
    UI -->|行为：点击、购买| BE[Commerce backend]

    L --> M[指标: cost_per_task,
cost_per_user]
    BE --> M
    M --> D[定价与实验仪表盘]

    subgraph "后续模块 20"
      J[LLM 法官
quality_score]
      J --> M
    end

现在你正处在这张图的正中央：已经能记录成本与营收，并在此基础上加入实验与定价。下个模块会登场“法官德瑞德”（LLM 法官）。

10. 变现与实验中的常见错误

有了整体框架，就更容易识别常见的坑。下面是一个清单式的错误集，做变现与成本实验时可随手对照。

错误 №1：只盯成本，忽略质量。
常见场景：你换成更便宜的模型，看到 OpenAI 账单更友好了，就宣布胜利。一个月后发现，用户更少购买礼品卡、回访率更差、支持反馈变多“给的建议很离谱”。如果既不记录 quality_score，也不记录最起码的代理指标（点子点击、收藏、转化），很容易陷入“便宜但没用”的状态。

错误 №2：只按 LLM 算 cost_per_task，忽略基础设施与支付。
工程师有时精确统计了 tokens，却忘了 Redis、队列、外部 API、Stripe 手续费等。结果 cost_per_task 被严重低估，定价看起来比实际更从容。基础设施通常按聚合数据折算，但它的分摊也必须计入场景成本。

错误 №3：在没有明确 experiment_id 和 variant 的情况下更改模型/UX。
“我们稍微改了下 prompt，好像更好了”——一个月后没人记得具体何时改、基于哪些数据、带来什么影响。没有在日志里明确标注实验（experiment_id、variant）并与具体版本绑定，很难做回溯并证明改进不是偶然。

错误 №4：样本太少或过早下结论。
实验跑了两天，你基于 10 笔订单就裁决“模型 B 更划算”，这是典型统计噪声。至少要有一个最小时间窗口——一周更好——以及足够的场景数，才能比较均值与转化。我们不会在本讲深入统计学，但“不要用 5 个事件下结论”这个规则值得谨记。

错误 №5：定价很复杂，但没有简单的心智规则。
可以设计三层套餐、不同币种、各种折扣，但如果没有简单的产品规则，比如“LLM 成本不超过营收的 X%”或“单次场景价格不得低于平均 cost_per_task 的 3 倍”，就很容易丢掉利润而不自知，直到月底结账才发现。

错误 №6：忘了把变现与营销增长挂钩。
定价与变现不在真空中：订阅越贵，流失越高、转化越低；价格越低，对成本优化的要求越高。错误做法是只看“我们现在赚了多少”，却不把它与获客/激活/留存指标关联——这些会在本模块后续主题里展开。最好用与质量和成本实验一致的方式来记录定价实验，这样才能看到全貌。