企业官网建设流程全解析

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 页 PDF，A 需要切段喂，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 三家能力画像对照

这张表我建议你只当参考，因为“通过率”这个指标高度依赖任务设计。真正该学的是怎么自己造这么一张表——下面第三节我把方法拆开讲。

3. 六个真实工作流的实测记录，赢家经常出人意料

3.1 长文档研读：切段策略比选模型更重要

这是我最常干的活，也是最容易踩坑的。手头经常有几十上百页的规范、白皮书、招标文件，需要提炼成两页纸的摘要加一份要点清单。

最初的笨办法是整份丢进去。结果发现，即便是号称超长上下文的 B，在处理 180 页文档时，开头 20 页和结尾 20 页的信息保留得很好，中间章节的细节丢失严重。这个现象业内叫“中间遗忘”，不是你提示词写得不好，是模型注意力分布的问题。

我后来固定成一套流程，实测效果提升明显：

1. 先用工具把 PDF 按章节切成 8 到 12 个块，每块控制在 15 页以内；
2. 每块单独做一次“要点抽取”，要求输出固定格式（章节标题、三条核心结论、两个关键数字、一个待确认问题）；
3. 把所有块的抽取结果拼成一个约 3000 字的中间稿；
4. 拿中间稿做第二轮“合并去重 + 逻辑重排”；
5. 最后单独做一次“反查”，把摘要里的每个数字回原文核对。

这套流程里，第 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。三家的表现：

结论很清楚：批量任务选 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 我的账单拆解与优化前后对比

省下来的 280 刀里，最有效的两招是“两级策略”和“砍席位”。

两级策略的意思是：批量任务先用便宜的小模型跑一遍，输出打个分（可以用规则判断，比如长度是否合规、关键词是否齐全、JSON 是否能解析），不合格的才转给贵的大模型重跑。实测下来，大约 85% 的条目小模型就能搞定，成本直接降了四成，质量只掉了不到两个百分点。

砍席位这件事我犹豫了很久，怕影响协作。实际换成一个共享工作区之后，除了没法看各自的对话历史，其他功能都够用。对话历史这东西，说实话一个月也没人翻几次。

提示：在砍订阅之前，先做一件事——导出你过去一个月的使用记录，看看每个工具的实际使用天数。我当时发现 B 的个人订阅一个月只用了 6 天，那 20 刀纯属心理安慰。

4.3 那些看起来省钱实际更贵的做法

有几个坑我必须提醒。

第一个是“为了省钱用免费版跑正式任务”。免费版的限流会让你在关键时刻卡住，而且模型版本可能落后，输出质量不稳定。我试过一次用免费额度赶一个急活，中途被限流，最后加班两小时，省下的 20 刀换来的是两小时和一堆火气。

第二个是“过度压缩提示词省 token”。提示词从 800 字压到 200 字，token 是省了，但输出质量下降导致返工，总成本反而上升。我的经验是：系统提示词该长就长，它是一次性成本，摊到每次调用上微不足道；真正该省的是把无关的上下文塞进对话历史。

第三个是“不做缓存重复跑”。同一个背景资料，每次任务都重新上传一遍，token 哗哗地烧。现在我的做法是把常用背景资料整理成一个精简版（通常能压到原文的三分之一），固定放在每次对话的开头，长对话里不再重复粘贴。

5. 选型决策表与踩坑速查

5.1 按角色和场景的选型矩阵

如果你不想看前面那么多分析，直接照这张表选：

5.2 踩过的坑速查表

5.3 几条用血换来的心得

第一条，不要迷信“最强模型”这个词。我早期犯的错就是什么活都丢给当时评测分最高的那个，结果在批量任务上翻车。模型的能力是分维度的，写作强不代表格式服从度高，推理强不代表输出稳定。选型的第一步永远是搞清楚你的任务属于哪个维度。

第二条，评估要用你自己的任务集，不要用别人的榜单。我一开始照着各种评测榜单选，选出来的模型在我的实际任务上表现平平。后来自己攒了一个 50 条的小任务集（涵盖我最常干的六类活），每次有新模型或者版本更新，就跑一遍，记录通过率。这个小任务集现在是我最有价值的资产之一，比任何榜单都准。

第三条，提示词的投入回报率远高于换模型。同一批任务，我把提示词从“帮我改一下这段”改成“角色+约束+输出格式+一个正例+一个反例”，三家的一次通过率平均提升了 20 个百分点以上。这个提升幅度，换模型换不来。

第四条，留一条人工兜底线。不管模型多强，涉及对外发布、涉及数字、涉及承诺的内容，一定要有人过一遍。我给自己定的规矩是：模型产出的东西，只要是给别人看的，我必须逐字读一遍。四个月里这条规矩至少帮我拦下了五六次足以尴尬的错误。

最后分享一个我最近才想明白的事。这 600 刀花下来，最大的收获其实不是“哪个模型更好用”，而是我终于搞清楚了自己的工作流里，哪些环节是真正需要智能的，哪些环节只是需要“快”和“稳”。搞清楚这一点之后，很多环节我干脆不用大模型了——正则表达式、固定模板、几个写好的脚本，比调模型快得多也便宜得多。模型该用在那些“每次都不一样、需要判断”的地方，用在做重复劳动上，纯属浪费。

现在我们团队的账单从 600 降到了 320 左右，任务完成时间反而缩短了。这个结果有点反直觉，但仔细想想很合理：钱花在刀刃上，注意力也花在刀刃上。