1. 先说说这600刀是怎么烧掉的以及为什么值得标题里那三个名字我下文统一用 A、B、C 代称——A 是那种最早普及、生态最厚的对话型助手B 是搜索起家、多模态能力最激进的那家C 是长文本处理和写作质感口碑最好的那家。懂的人一看就知道是谁不懂也不影响往下读因为真正有价值的是选型逻辑不是品牌名。先交代背景。我在一个小团队里负责内容生产和一部分技术侧的工作团队三个人同时开着三家的个人高级订阅各 20 刀一个月这就是 60 刀。后来因为要跑批量任务又加了 API 计费一个月 300 到 400 刀浮动。再算上团队协作席位的升级、图片生成额度的额外购买、以及为了做对比测试重复订阅的几个小号账单稳定在 600 刀上下。600 刀一个月说多不多说少也不少够买一台不错的二手笔记本了。我坚持了整整四个月没砍原因很简单这三家不是替代关系是分工关系。但如果你只是普通用户一个月只想花 20 刀那这篇东西对你有用的部分就是“到底该选哪一个”如果你是团队采购或者重度用户那更有价值的是后面成本核算那一段——我实测下来600 刀里有将近 200 刀是纯浪费砍掉之后效率没降。这篇东西适合三类人看一是刚接触这类工具、面对三个订阅页面不知道点哪个的新手二是已经在用但总觉得“好像没用到点子上”的中度用户三是要给团队做采购决策、需要一套可复现评估方法的人。我不打算堆参数表那些官网都有我要讲的是四个月里真实跑过的六个工作流、每个环节谁赢谁输、赢多少、以及哪些差距是营销话术吹出来的。提示下面所有的对比结论都基于我自己的任务集你的场景不同结论可能完全反过来。所以我尽量把“为什么”写清楚你照着逻辑换成自己的任务重跑一遍比记住结论有用得多。2. 三类产品的真实定位差异别被同一张参数表骗了2.1 对话型助手 A不惊艳但最不容易出事A 给我的感觉像一个干了十年的老员工你交给它的活它基本都能干很少给你惊喜也很少给你惊吓。它的强项在通用性——写邮件、改文案、解释概念、做表格、写简单脚本样样能上手样样不是最强。我做过一个粗糙的测试拿 50 条日常杂活会议纪要整理、周报生成、SQL 语句编写、英文邮件润色、竞品信息归纳分别丢给三家记录“一次通过不用返工”的比例。A 的一次通过率是 74%B 是 68%C 是 71%。看着差别不大但 A 的失败方式最温和——它错的时候通常只是答得平、答得浅你能一眼看出来然后补一句提示词就修好了。B 和 C 的失败方式更“自信”尤其是 B有时候会给你一段读起来非常流畅但事实经不起查的内容。A 的另一个隐性优势是生态。它的插件、第三方集成、浏览器扩展、办公软件里的嵌入成熟度明显高一个档次。我们团队的内容发布流程里有一环是“把草稿同步到协作文档并自动生成待办”这个环节只有 A 能靠现成集成跑通另外两家得自己写脚本。代价是什么A 在超长文本和复杂推理上确实吃力。我拿一份 180 页的技术规范让它做结构化摘录它会在中途“忘记”前面章节的定义输出里出现前后矛盾。这不是提示词能解决的问题是能力边界。2.2 多模态助手 B搜索和看图是真强别的地方要留神B 最让我服气的是两件事一是它能把搜索结果和生成内容揉在一起给出来的东西带引用、能溯源二是它对图像的理解尤其是图表、手写笔记、界面截图这类“脏图”。我们做个一个具体的活把会议上白板拍的照片光线不均、字迹潦草、有划改转成结构化待办清单。A 认出了大约六成C 认出了七成B 认出了九成以上而且能正确区分“划掉的内容”和“新增的内容”。这个差距不是一点点是能不能用的差距。B 的超长上下文也是三家里最舍得给的。同样一份 180 页 PDFA 需要切段喂C 能一次吃下但摘要偏粗B 能一次吃下并且在中段细节上保持得比较好。不过这里有个大坑我后面会细说上下文窗口长不等于它真的“读进去了”。B 的问题在于稳定性。同一段提示词今天跑和明天跑输出风格和质量会有可见的波动。做一次性任务无所谓做需要批量一致输出的任务就很要命——我给一批 200 条商品描述做统一风格改写B 的输出里有大约 15% 明显跑偏得人工挑出来重跑。A 在同样任务上的跑偏率是 6%。2.3 长文本助手 C写作手感最好代码也比想象中能打C 是我目前写作环节的主力。中文写作这件事三家的差距比英文明显得多。A 写出来的中文“正确但平”语法没错、逻辑没错就是没有节奏读起来像产品说明书。B 爱用排比和破折号写长了会有一股翻译腔。C 的中文质感最接近“人写的”尤其是在需要控制语气、长短句交错、避免套话的场景下。代码这块我原本没抱期待实测反而惊喜。我拿一个三千多行的老项目做重构要求把散落在各处的配置读取统一到一个模块里。C 给出的补丁一次可用率最高而且它会主动指出“这里有个副作用你可能没考虑到”——这种主动提示在三家里只有 C 做得比较自然。A 给的方案更保守能用但啰嗦B 有时候会给你一段看起来很美但导入路径全错的代码。C 的短板是生态和实时性。它的联网能力相对弱问时效性强的东西经常答不上来或者答得含糊。另外它的文件处理对扫描版 PDF 支持一般纯文字 PDF 没问题图片型 PDF 就得先 OCR。2.4 三家能力画像对照维度对话型 A多模态 B长文本 C日常杂活一次通过率74%68%71%180页文档一次吃下吃力需切段可以中段细节较好可以摘要偏粗手写/截图识别约60%90%以上约70%中文写作质感正确但平偶有翻译腔最接近人写代码补丁一次可用率中等保守偏低易出错最高会主动提示风险输出稳定性高偏低有波动中等偏高生态与集成成熟度最高中等偏低实时信息与引用溯源中等最强弱这张表我建议你只当参考因为“通过率”这个指标高度依赖任务设计。真正该学的是怎么自己造这么一张表——下面第三节我把方法拆开讲。3. 六个真实工作流的实测记录赢家经常出人意料3.1 长文档研读切段策略比选模型更重要这是我最常干的活也是最容易踩坑的。手头经常有几十上百页的规范、白皮书、招标文件需要提炼成两页纸的摘要加一份要点清单。最初的笨办法是整份丢进去。结果发现即便是号称超长上下文的 B在处理 180 页文档时开头 20 页和结尾 20 页的信息保留得很好中间章节的细节丢失严重。这个现象业内叫“中间遗忘”不是你提示词写得不好是模型注意力分布的问题。我后来固定成一套流程实测效果提升明显先用工具把 PDF 按章节切成 8 到 12 个块每块控制在 15 页以内每块单独做一次“要点抽取”要求输出固定格式章节标题、三条核心结论、两个关键数字、一个待确认问题把所有块的抽取结果拼成一个约 3000 字的中间稿拿中间稿做第二轮“合并去重 逻辑重排”最后单独做一次“反查”把摘要里的每个数字回原文核对。这套流程里第 2 步用 C 效果最好因为它对格式的服从度高输出干净第 4 步用 A 最稳因为合并阶段最怕模型自己发挥第 5 步我一般用 B因为它能带着引用定位回原文。耗时对比最初整份丢进去一份 180 页文档平均要 40 分钟来回折腾还经常要重来。改成切段流程后稳定在 55 分钟左右但返工率从 40% 降到 5% 以内。慢 15 分钟换掉 35 分钟的返工这笔账很划算。注意切段不要按固定页数机械切要按章节标题切。一个章节被腰斩成两半是摘要质量下降最常见的原因。3.2 代码改造让模型先复述需求再动手代码任务我踩过一个很大的坑直接把报错信息和相关文件丢进去让它改。三家都能给你一段“看起来对”的代码但 A 会改得太保守只修表面症状B 会改得太激进顺手重构了一堆不相关的东西C 相对平衡但也需要约束。后来我加了一步“先复述”在让它改代码之前先要求它用自己的话复述一遍“这段代码在干什么、问题出在哪、你打算怎么改、改动会影响哪些调用方”。这一步花不了多少 token但能过滤掉大量跑偏。实测数据加复述这一步之前C 的补丁一次可用率约 62%加了之后到 81%。A 从 48% 提到 69%。B 从 41% 提到 58%。提升幅度比换模型带来的差异还大。另一个实用技巧是把大文件拆成“接口层 实现层”分别处理。三千行的文件整份丢进去模型很难聚焦拆成“这个模块对外暴露了什么、内部实现是什么”两部分改起来精准得多。还有一点是关于“幻觉 API”。B 在写代码时最容易编造不存在的库函数尤其是比较冷门的包。我的应对办法是要求它在每个不确定的调用后面加一个// 待核实标记然后我只需要 grep 这个标记去查文档不用逐行读。3.3 数据分析别让模型口算让它写代码算这是我认为最值得强调的一条经验。任何涉及数字计算、排序、聚合的活都不要让模型“直接算”让它写代码算然后你把代码跑一遍。我做过对照测试给一份两万行的销售明细 CSV问“哪个区域第二季度的环比增速最快”。直接问三家给出的答案里有两家是错的而且错得很隐蔽——数字看起来合理但经不起核对。让它写 Python 代码算三家都能写对唯一差别是 B 会顺手把可视化也做了。所以我的做法是把一个支持代码执行的环境当作“计算器”模型只负责把自然语言需求翻译成代码。这个思路一转变数据类任务的可靠性直接从“碰运气”变成“基本可信”。具体流程第一步让它先输出“数据字典”——列名、类型、缺失情况、取值范围让我确认它理解对了第二步让它写清洗代码我跑一遍看输出行数变化第三步才是分析代码第四步要求它把关键中间结果打印出来而不是只给最终结论。第四步非常关键。很多错误是因为中间步骤就算错了但最终结论看起来合理。强制打印中间结果错误无处可藏。3.4 多模态识别拍图质量决定一半成败前面说过 B 在图像理解上领先明显。但我要补一句领先的部分很大程度被“输入质量”吃掉了。同一张白板照片我试过三种拍法正面平拍、斜着拍、以及拍完手动裁边加对比度增强。B 的识别准确率分别是 72%、58%、91%。也就是说你多花十秒钟把图拍正、把边裁掉比纠结选哪个模型有用得多。对于扫描版 PDF我的固定套路是先用工具做 OCR 转成可搜索的文本层再喂给模型。直接丢图片型 PDF三家的表现都不理想尤其是表格结构识别出来经常行列错位。图表理解这块有个技巧不要让模型“描述这张图”要让它“把这张图里的数据提取成表格格式”。前者它会给你一段优美但没用的描述后者能逼它逐项读取数值。我拿一张折线图试过要求输出表格后B 能读出 12 个数据点里的 11 个A 只读出 7 个。3.5 中文写作分工比选一个“最强”更有效写作是我的主业这块我摸索出一套三人协作的分工法比单用任何一家都好。大纲和结构用 A。它的逻辑性最稳给出来的骨架条理清晰不会为了文采牺牲逻辑。初稿扩写用 C。它的中文节奏最好长句短句交错自然不太会出现那种“首先、其次、最后”的机械结构。事实核查和引用补充用 B。写完之后把稿子丢给它要求“逐条检查文中提到的事实性陈述标注哪些需要来源、哪些可能有误”。它会挑出一堆我自己没意识到的问题。最后润色回 C但只做局部改写不做整篇重写。整篇重写会把我的个人语气洗掉变成模型腔。这个流程跑下来一篇三千字的稿子从初稿到定稿从原来三个多小时压缩到一小时四十分钟左右。提升主要来自“核查”这一步外包出去了因为我以前最耗时的就是反复查资料。3.6 批量任务与 API一致性比聪明更重要当任务量上去之后订阅制就不够用了必须走 API。这时候评估标准完全变了——不再是“谁更聪明”而是“谁更稳定、更便宜、格式更听话”。我做过一个 5000 条商品文案的批量改写任务。要求统一风格、控制字数、保留关键词、输出 JSON。三家的表现指标ABC格式合规率严格 JSON99.2%96.5%98.7%风格一致性抽检合格率88%74%91%单条平均成本相对值1.01.31.15需要重跑的条数约 40约 180约 25结论很清楚批量任务选 C 或 A别选 B。B 的单条质量可能更高但一致性差而批量任务里一条跑偏就要人工介入人工成本远高于 token 成本。另一个实战经验是批量任务一定要做“小样本预跑”。先跑 50 条人工全检算出合格率再决定要不要放大到 5000 条。我第一次图省事直接跑了 3000 条结果风格漂移严重全部作废那一次浪费的钱比省下来的多得多。4. 600刀的成本拆解能砍掉三分之一还不掉效率4.1 订阅和API的临界点我算了一笔账很多人纠结“该订阅还是该用 API”。我的经验公式是这样设你每月需要处理的输入 token 量为 T输出为 O某模型的输入单价 p_in、输出单价 p_out单位美元/百万 token订阅费为 S。那么 API 月成本 ≈ T × p_in O × p_out。当这个值小于 S 时纯 API 更划算当它大于 S 的两倍时订阅更划算中间地带看你对“界面体验”的依赖程度。以我自己的情况为例我每月的重度对话那种来回十几轮、上下文很长的大约消耗 300 万输入 token、60 万输出 token。按中档模型的价位估算纯 API 大概 15 到 25 刀比 20 刀的订阅便宜不了多少但订阅给的是“无限量界面文件上传历史记录”所以我保留订阅。真正吃掉预算的是批量任务。我每月跑批量的 token 量是对话量的十倍以上这部分走 API 是刚需也是账单里最大的一块大约 280 刀。4.2 我的账单拆解与优化前后对比项目优化前美元/月优化后美元/月做法三家个人订阅6040砍掉 B 的个人订阅改用免费额度按需 API团队协作席位12060从 6 席降到 3 席共用一个工作区批量任务 API280190小模型打底大模型兜底的两级策略图片生成额度8030只在定稿阶段生成草稿不生成重复测试小号600用同一账号的多工作区替代合计600320—省下来的 280 刀里最有效的两招是“两级策略”和“砍席位”。两级策略的意思是批量任务先用便宜的小模型跑一遍输出打个分可以用规则判断比如长度是否合规、关键词是否齐全、JSON 是否能解析不合格的才转给贵的大模型重跑。实测下来大约 85% 的条目小模型就能搞定成本直接降了四成质量只掉了不到两个百分点。砍席位这件事我犹豫了很久怕影响协作。实际换成一个共享工作区之后除了没法看各自的对话历史其他功能都够用。对话历史这东西说实话一个月也没人翻几次。提示在砍订阅之前先做一件事——导出你过去一个月的使用记录看看每个工具的实际使用天数。我当时发现 B 的个人订阅一个月只用了 6 天那 20 刀纯属心理安慰。4.3 那些看起来省钱实际更贵的做法有几个坑我必须提醒。第一个是“为了省钱用免费版跑正式任务”。免费版的限流会让你在关键时刻卡住而且模型版本可能落后输出质量不稳定。我试过一次用免费额度赶一个急活中途被限流最后加班两小时省下的 20 刀换来的是两小时和一堆火气。第二个是“过度压缩提示词省 token”。提示词从 800 字压到 200 字token 是省了但输出质量下降导致返工总成本反而上升。我的经验是系统提示词该长就长它是一次性成本摊到每次调用上微不足道真正该省的是把无关的上下文塞进对话历史。第三个是“不做缓存重复跑”。同一个背景资料每次任务都重新上传一遍token 哗哗地烧。现在我的做法是把常用背景资料整理成一个精简版通常能压到原文的三分之一固定放在每次对话的开头长对话里不再重复粘贴。5. 选型决策表与踩坑速查5.1 按角色和场景的选型矩阵如果你不想看前面那么多分析直接照这张表选你的情况首选备选理由完全新手只想花一份钱A—通用性最好出错方式最温和生态最全主要做中文写作CA语言质感差距明显尤其长文需要大量查资料、核实事实BA引用溯源能力是独一档经常处理图片、扫描件、手写B—识别准确率领先一个身位写代码为主CA补丁可用率高会主动提示风险批量处理几千条数据C 或 A—一致性优先别选 B团队采购预算有限A C—通用写作覆盖八成场景预算充足追求效率上限三家都要—分工使用别指望一个打全场5.2 踩过的坑速查表现象大概率原因处理办法长文档摘要前后矛盾中间遗忘按章节切段分段摘要后再合并模型说读完了但答不出细节上传文件解析失败尤其是扫描件先 OCR 转文本层检查页数对不对代码里调用了不存在的函数幻觉要求标注不确定处逐个核实批量输出风格忽好忽坏模型输出波动小样本预跑锁定提示词版本加格式校验输出被截断在半句话输出长度上限分段生成或明确要求“分两次输出”同样提示词两次结果差很多采样随机性需要稳定输出时降低随机性参数或改用批量接口明明订阅了还要额外付费订阅额度和 API 额度不互通提前查清楚哪些功能走 API 计费中文标点全变成英文输出格式未约束在提示词里明确要求全角标点联网搜索引用了不存在的来源检索质量参差要求给出可点击链接逐条点开验证5.3 几条用血换来的心得第一条不要迷信“最强模型”这个词。我早期犯的错就是什么活都丢给当时评测分最高的那个结果在批量任务上翻车。模型的能力是分维度的写作强不代表格式服从度高推理强不代表输出稳定。选型的第一步永远是搞清楚你的任务属于哪个维度。第二条评估要用你自己的任务集不要用别人的榜单。我一开始照着各种评测榜单选选出来的模型在我的实际任务上表现平平。后来自己攒了一个 50 条的小任务集涵盖我最常干的六类活每次有新模型或者版本更新就跑一遍记录通过率。这个小任务集现在是我最有价值的资产之一比任何榜单都准。第三条提示词的投入回报率远高于换模型。同一批任务我把提示词从“帮我改一下这段”改成“角色约束输出格式一个正例一个反例”三家的一次通过率平均提升了 20 个百分点以上。这个提升幅度换模型换不来。第四条留一条人工兜底线。不管模型多强涉及对外发布、涉及数字、涉及承诺的内容一定要有人过一遍。我给自己定的规矩是模型产出的东西只要是给别人看的我必须逐字读一遍。四个月里这条规矩至少帮我拦下了五六次足以尴尬的错误。最后分享一个我最近才想明白的事。这 600 刀花下来最大的收获其实不是“哪个模型更好用”而是我终于搞清楚了自己的工作流里哪些环节是真正需要智能的哪些环节只是需要“快”和“稳”。搞清楚这一点之后很多环节我干脆不用大模型了——正则表达式、固定模板、几个写好的脚本比调模型快得多也便宜得多。模型该用在那些“每次都不一样、需要判断”的地方用在做重复劳动上纯属浪费。现在我们团队的账单从 600 降到了 320 左右任务完成时间反而缩短了。这个结果有点反直觉但仔细想想很合理钱花在刀刃上注意力也花在刀刃上。
