X Article · 工程实战 · 2026-06-26

Lindy 把 Claude 换成 DeepSeek,砍 90% 成本——他们是怎么做到用户无感的?

一篇被掩盖在"换个便宜模型"标题下的工程方法论长文。真正的活儿不是选模型,是用证据赢得挪动流量的资格。拆解它的七阶段迁移流水线、GEPA prompt 优化、供应商量化陷阱,以及原文沉默的地缘风险。

90%推理成本下降幅度(迁移路径上)
7 阶段eval → 横评 → 放量 → ramp 流水线
3 个候选GLM 5.1 / Kimi K2.6 / DeepSeek v4 Flash
18.2 万原文阅读量 / 引用讨论 26 条

一、全文翻译

原标题 Migrating from Claude to DeepSeek。作者 Lindy(CEO Flo Crivello)。忠实翻译,不加观点,观点放解读部分。

Lindy 的定价模式,只有在推理(inference)持续变便宜的前提下才成立。这就是业务上的硬约束。Lindy 是一个通用 AI 助手——它写邮件、管日历、准备会议、做跟进,还有一长串每天都必须"靠得住"的小活儿。模型是它的发动机,同时也是公司最大的成本项之一。

所以 Lindy 从第一天起,就把定价建立在一个押注上:模型变便宜的速度,会快到让我们能把用户顺着成本曲线往下挪,而产品不会变差。你不需要上帝来替你写邮件。

好几个月里,中国不断冒出头条,声称以几分之一的价格达到了前沿级性能。这些大多都是噪音。然后到了五月和六月,这个声称对 Lindy 来说不再是噪音了。他们把大部分托管型 agent 的模型流量——包括 Claude/Sonnet 支撑的路径,以及剩下的 Gemini/Google 路径——都迁移到了运行在 Atlas Cloud 上的 DeepSeek v4 Flash。当用户显式选择 Sonnet,或某条路径需要更高智能时,Sonnet 仍然可以运行。在迁移过去的这部分流量上,推理成本下降了约 90%

改一个模型名字很容易。难的是证明用户依然会信任这个助手——这才是真正的活儿。

Changing a model name was easy. Proving that users would still trust the assistant took the work.

把这当成"换个下拉选项",才是真正的错误

最天真的迁移版本只要五分钟:挑个更便宜的模型,跑几个 prompt,宣布胜利。这个版本做出来的,就是一个更差的助手。单个 prompt 几乎说明不了任何问题。真正有用的测试是:这个模型能不能扛住几千个微小的产品瞬间?能不能做到这一切,而不让用户觉得"自己的助手一夜之间被换了大脑"?

这最后一句不是比喻。Lindy 在这次选型里试过 Kimi K2.5。它离线评测表现不错。然后推到一小片真实流量上,它几乎立刻就没通过"感觉测试"。一个用户反馈说,感觉他的 Lindy 一夜之间做了脑部手术

怎么选中 DeepSeek 的

Lindy 先建了一大堆离线评测,然后跑了 GLM 5.1、Kimi K2.6 和 DeepSeek v4 Flash 几个候选。还在不同的推理供应商上测了同一个模型。让人头疼的是:供应商本身有影响。同一个名义上的模型,由不同的人来服务,打分可能不一样。最合理的猜测是:有些供应商在提供量化版本,或它们的推理栈本身有问题。

你测的是【一个模型 + 一个供应商 + 一个推理栈 + 你自己的 prompt】这整套作为一个系统。

You tested a model, a provider, an inference stack, and your own prompts as one system.

DeepSeek v4 Flash 在关心的那些工作负载上胜出。然后 Lindy 调 prompt,直到离线分数大致追平旧方案——这时候 GEPA prompt 优化循环派上了用场。只有到这一步,才开始放量。

真正重要的,是那个放量过程

Lindy 从一小撮用户(含内部用户)开始。内部流量很关键,因为员工抱怨得快、且细节有用——如果助手突然变笨了,你会在图表"客气到足以说话"之前就听到反馈。然后盯两件事:在线评测(抓住离线集漏掉的古怪输入)和留存(更慢更诚实——如果产品微妙变差,用户不会提工单,只会用得少)。只要信号撑得住,就继续放量,最终 DeepSeek 跑到目标流量的 100%。

有意思的活儿不是"我们把流量逐步挪到新模型"——那只是管道工程。有意思的活儿,是去"赢得"挪动这些流量的资格。

The interesting work was not "we gradually moved traffic." That is plumbing. The interesting work was earning the right to move the traffic at all.

学到的规则 · 对 labs 的意义

不要问一个更便宜的模型在抽象意义上是不是"一样好",要问它在哪里够用。这套流程砍掉了约 90% 成本,且没让用户操心模型路由。用户不该操心是哪个模型替他写的邮件,他只该注意到——Lindy 还是那个 Lindy 的感觉。

关于 labs 是否会沦为商品:诚实的回答是部分会,但这跟"完蛋"不是一回事。航空业是出了名的残酷生意,但达美依然值几百亿美元。一门商品化的生意,只要市场足够大,照样可以非常庞大。压力压的是利润率,不是相关性。前沿下方那一档在持续变便宜,每一次它对某一类工作变得"够用",应用层公司就有强烈动机把那类工作顺着成本曲线下移。

二、工程级解读

这是工程实战长文(模型选型 + 推理供应商 + 评测体系 + prompt 优化 + 放量),按"是什么→在哪跑→怎么测→手搓对比→选型决策→诚实限制"六层拆解。读完你应该能在自己的 AI 产品里复刻这套"换发动机"流水线。

1. 是什么 → 在哪跑:Lindy 的运行时分层

很多人读完只剩"Lindy 把 Claude 换成了 DeepSeek"。这个理解差了三层。真实运行时是这样的分层结构,迁移动的不止"模型层"一个动作:

角色这篇文章动了哪里
应用层Lindy 产品(iMessage 助手:邮件/日历/会议)没动,用户无感
托管 Agent 层Lindy 自己管理的 agent 编排迁移主战场,流量大头
模型路由层按智能需求 + 用户显式选择决定走哪个模型新增"默认 DeepSeek、按需 fallback Sonnet"
模型层DeepSeek v4 Flash(默认)/ Sonnet(高智能)默认模型从 Anthropic 切到 DeepSeek
推理供应商层Atlas Cloud 承载 DeepSeek;同模型不同供应商表现不一选定 Atlas Cloud,发现量化缩水
评测/优化层离线/在线 evals + GEPA prompt 优化"赢得迁移资格"的真正功臣
关键洞察:迁移不是"模型层"一个动作,而是模型 + 路由 + 供应商 + 评测四层联动。"DeepSeek-v4-Flash@供应商A(量化版)"和"@供应商B(FP8)"可能是两个不同的模型——这就是为什么 Lindy 把"供应商选择"和"模型选择"放在同一层来测。

2. 核心架构:七阶段迁移流水线

离线评测建设

把真实任务录成可回放 eval set。失败则无法横向对比,只能拍脑袋。

候选横评

GLM 5.1 / Kimi K2.6 / DeepSeek v4 Flash 同台跑。选错全白干。

供应商横评

同模型 × 多供应商,找分数最高组合。检测量化缩水。

Prompt 重优化

用 GEPA 把 prompt 调到分数追平旧方案,避免假阴性。

内部放量

先给员工/小比例用户,靠"抱怨速度"做预警 canary。

在线评测

生产环境抓离线集漏掉的奇怪输入,补长尾盲区。

留存 + 全量 ramp

盯几周 retention,稳了再推到 100%。防静默流失。

阶段屏障语义(编排类内容最易读漏):阶段之间是顺序屏障——当前阶段信号"撑得住"才放行下一个;阶段内部是并发——比如候选横评和供应商横评可并行。这不是"逐步挪流量"的管道工程,是"逐步赢得挪流量资格"的信任工程。

3. 内部机制:GEPA 与 Kimi 为什么挂

GEPA 的内核:把 prompt 当待优化代码、把 eval set 当测试套件,让一个 LLM 作为 optimizer 自动生成 prompt 变体、打分、保留高分变体、再变异——本质是遗传算法用在 prompt 上。它解决"在黑暗里手改 prompt"的问题(改一个 case 可能弄坏另外三个,且你不知道)。

GEPA 循环

  • 反馈来源:完整 eval set 的客观分数
  • 收敛性:朝评分函数单调改进
  • 可复现:每轮变体可回放对比
  • 适用:模型替换等系统性重构

手改 Prompt

  • 反馈来源:工程师直觉 + 几个 case
  • 收敛性:越改越歪,按起葫芦浮起瓢
  • 可复现:改动无版本化因果
  • 适用:单点 hotfix

Kimi K2.5 为什么挂:离线评测"表现不错",真实流量却"脑部手术"。这是经典的分布偏移——离线集是"干净典型"任务,真实流量是"混乱长尾"任务。一个模型可以在典型分布上追平 Sonnet,却在长尾上崩盘(语气突变、人格不连贯、判断边界漂移)。这正是 Lindy 坚持三层"真实环境验证"的原因:离线评测能淘汰坏的,但证明不了好的。

4. DIY 对比:手搓版 vs Lindy 工程化版

环节手搓版(大多数团队)Lindy 这套(产品级)
评测集10-20 个手工 case 存 Notion录制真实任务,可回放、并发跑
模型对比拍脑袋 + A/B标准化 eval set 跨模型同台打分
供应商默认走官方 API横评供应商,检测量化缩水
Prompt手动调,改坏不知道GEPA 自动对着 eval 优化
放量直接全量切,出事回滚内部→小流量→留存→全量 ramp
失败检测靠用户投诉工单内部抱怨 + 在线 eval + retention 三重

省的到底是什么:不是省"选模型的时间"(那本来就只要五分钟),而是省"选错模型的代价"——一次贸然全量切换可能导致 retention 静默下跌几个点,几周后才从财报发现,已流失一批用户。这套流水线把"选错"的代价从事故级压到评测阶段就拦截。

5. 选型决策框架:应该用什么模型

场景推荐档位理由
邮件/日程/会议简报等日常可靠任务DeepSeek v4 Flash 这档不需要上帝,成本敏感,量大
用户显式要"最强" / 高难度推理Sonnet / 前沿档保留溢价智能,按需触发
强视觉/多模态(图片理解)谨慎 DeepSeek评论实测 vision 偏弱
低延迟 + 频繁 tool calling谨慎 慎选供应商评论实测 tool calling 延迟可能飙升
严格合规/数据主权评估 地缘风险中国模型 + 第三方云,见限制

不要问"更便宜的模型是不是一样好",要问"它在哪些地方够用"。

Do not ask whether a cheaper model is "as good" in the abstract. Ask where it is good enough.

这句话的本质:把布尔判断(一样好/不一样好)换成分段判断(在 A 任务够用、B 不够用)。前者让你在"平均值"上做错误决策,后者让你把流量按"够用边界"切成路由表——能下移的下移,不能下移的留在前沿档。这是全文最值得偷走的东西。

6. 诚实限制:原文沉默的几个坑(压力测试发现)

"100% 迁移"措辞矛盾:托管 agent 默认流量切 DeepSeek,但保留手动选 Sonnet + 高智能 fallback。读"100%"要加限定。
视觉短板(评论实测):DeepSeek 除 vision 外表现好,多模态场景要单独验证。
Tool calling 延迟陷阱(评论实测):工具调用/重试在 OpenRouter 上延迟大幅增加,重交互场景供应商选择影响被放大。
地缘与供应链风险(原文一字未提):中国模型 + Atlas Cloud 第三方托管。出口管制、量化不确定性、供应商单点——产品命脉押在这三个风险上。
"成本曲线持续下降"是押注不是定律:scaling law 触顶或能源成本反转,整个定价模式承压。文章当既定事实,它是赌注。
留存窗口可能不够:几周 retention 稳,不等于一年后稳。长期质量漂移要几个月才显现。
为什么原文没说:这篇文章本质是"工程能力展示 + 招聘广告 + 成本叙事"的混合体(结尾两节直接是招聘 + 行业判断),有动机把故事讲得干净漂亮。方法论要学,但"沉默的证据"得读者自己补上。

三、精选评论

两条反向证据(vision 弱、tool calling 延迟)价值最高——正好补上原文沉默的限制。

@samarthg1911

成本降了 100 倍 🫣

DeepSeek 性价比很好,大多数事不需要上帝,几乎哪儿都能塞——除了需要 vision 的时候。我把 discovery 和 synthesis agent 迁过去,成本降了 100x。
100x 比 Lindy 官方的 90% 还激进,说明特定工作负载(偏文本归纳)降本上限更高。

@nimsbh_ai

Tool calling 延迟陷阱

切换到 DeepSeek V4 Flash 是不错的替代,但工具调用和重试让延迟大幅增加——至少在 OpenRouter 上是这样。
原文没提的限制。重交互场景,"供应商=推理栈"的影响被放大。

@mikehealthai1

智能在商品化,信任没有

智能正在从超算中心到终端设备的各个层级变成商品。不是商品的,是引导和信任——也就是 Lindy 在做的事。以前驯化数据,现在驯化智能。

四、苏格拉底对话

从一个直觉反应开始,逐步逼出"换发动机"的真正难度。

尾巴

这不就是"Lindy 发现 Claude 太贵,换了个便宜的国产模型"吗?这有啥值得写长文的?

Cloudcold

那我问你,假如明天你自己的 AI 产品也这么换,你敢不敢直接全量切?

尾巴

……应该不敢。万一用户觉得变笨了呢。

Cloudcold

对了。那"万一变笨"你怎么测?你能列出现在用的模型,在哪几类任务上"绝不能换"吗?

尾巴

老实说列不出来,我现在连一个正式的 eval set 都没有,就是凭感觉用。

Cloudcold

这就是这篇文章真正的价值——它不是讲"DeepSeek 便宜",它在讲你怎么科学地证明一个更便宜的模型在你的场景里够用。你注意到他们把"内部员工先抱怨"当成独立阶段吗?

尾巴

看到了,说员工"抱怨得快且细节有用"。挺反直觉的,一般都觉得内部反馈不重要。

Cloudcold

因为员工是你最快的脏数据探测器。图表要等几天才有统计意义,员工用一下觉得"今天怪怪的"当天就反馈。它在"图表还没礼貌到能说话之前"给你预警。这是拿人当金丝雀。

尾巴

那 Kimi 离线过线、上线翻车,是不是说明离线评测没用?

Cloudcold

不是没用,是不够。离线集是典型分布,真实流量是长尾分布。离线评测能淘汰坏的,但证明不了好的——好模型是"在生产环境里活下来"才能证明的。

尾巴

反过来问——Lindy 这么依赖 DeepSeek,万一断供呢?文章好像完全没提。

Cloudcold

这正是这篇文章最大的沉默。把命脉押在一个中国模型 + 一个第三方推理云上,地缘、量化缩水、供应商单点,三个风险原文一字未提。方法论要学,"沉默的证据"得你自己补——这条够单列一个待办了。

五、个性化洞察

基于 QA 工程师背景、重度 Claude Code 用户、关注 AI 行业/美股/创业方法论的画像,提炼 5 条可执行发现。

美股视角

AI lab 估值逻辑的一手信号

Lindy 是真实付费 B 端客户,从 Anthropic/Google churn 到 DeepSeek 砍 90%——这是"frontier-below 吃掉 lab 利润率"的活体证据。HN 称 DeepSeek 成本是 Sonnet 的 3%。盯"应用层客户模型采购结构"这个先行指标,看 Anthropic 溢价叙事的新支撑点(前沿智能/合规/多模态)。

工程方法论

偷走七阶段迁移 SOP

离线 eval → 模型横评 → 供应商横评(99% 的人忽略)→ GEPA → 内部 canary → 在线 eval → 留存 ramp。现在就给你的产品搭一个最小 eval set,哪怕 30 条真实任务——它是未来换模型的决策依据。eval 要固定供应商,否则打分不可比。

QA 优势变现

"供应商=推理栈"的量化陷阱

"同模型不同供应商分数不同"本质是未声明的版本差异——典型测试不可复现问题。QA 出身的你把"供应商 + 量化配置 + 推理栈"当显式变量记录,每个供应商跑同一套 eval 对比方差。这是 QA 思维在 LLM 选型上的直接变现。

技术自媒体

"模型迁移经济学"稀缺选题

同时满足:当事人亲述、90% 硬数据、反直觉(Kimi 翻车、DeepSeek 击败 GLM5.1)、地缘张力。可做横向对比系列(Lindy/Cursor/各 coding agent 的模型采购决策)。读者最想看的不是"DeepSeek 强",是别人怎么科学地决定换不换

风险备忘

别犯 Lindy 没说的错

地缘断供、量化缩水、供应商单点——对你这种"自己当老板"的产品是致命的。用中国模型做核心链路,默认配置 fallback 路由(DeepSeek 挂了切回 Sonnet/GLM),并把路由成本写进定价。别让单一供应商 + 单一模型成为产品单点故障。

定价模式

"够用边界"是产品定价工具

"在哪里够用"不仅是模型选型工具,也是定价工具——按"够用边界"切路由表,能把大部分量下移到廉价档,少数高端需求按溢价计费。这套思路能让你在保持体验的前提下把边际成本压到行业十分之一。