大模型到底在改变什么？一个 GEO 从业者的日常观察

大型语言模型被包装成"第四次工业革命"喊了两年了，每次有新的旗舰模型发布，互联网上就掀起一轮新的"失业焦虑"讨论。作为一个从 2023 年初就开始用大模型做 GEO 内容生产和 SEO 优化的编辑，我认为这些讨论大部分都跑偏了——焦点一直被放在"AI 会不会取代人类"这个空洞的问题上，而真正值得关注的是：在现阶段的具体工作中，哪些环节大模型确实能帮上忙，哪些环节目前仍然是白费力气。

过去两年，我们团队在 GEO 内容生产中系统性地尝试了各种大模型的应用场景——内容生成、代码辅助、数据分析、知识检索。这篇文章不打算从 Transformer 架构开始科普（那样的技术综述你随手就能搜出上百篇，而且大半也是 AI 写的），我直接说我们试过的、踩过坑的、和最终沉淀下来的经验。如果你也是做内容或者技术团队的负责人，这篇文章应该比那些泛泛而谈的行业报告更有参考价值。

先说我这两年最大的一个感悟：大模型确实是生产力工具，但它更像是一个能力很强的实习生——能干活，但你得检查、得把关、得告诉它你要什么。完全不审查就用 AI 输出的内容直接上线，和完全不培训就让实习生去面对客户一样，都是不负责任的做法。

编辑实测记录

场景一：GEO 内容生产——AI 写的文章到底能不能排上名？

2024 年我们做过一个对比实验：用大模型批量生成 SEO 文章和人工编辑写的文章同时发布到我们的站点上，观察搜索排名的差异。这个实验持续了大约三个月，覆盖了 50 篇 AI 生成文章和 30 篇人工编辑文章，关键词分布在 GEO、AI 工具和编程教程三个类目。

结论可能会让你意外：大模型写的文章本身质量不差——文笔通顺、结构清晰、关键词布局合理——但问题是"没有信息增量"。Google 和百度的搜索算法越来越聪明，批量生成的模板化内容即使语言质量过关也无法获得好的排名，因为这些内容没有提供搜索引擎认为有价值的新信息。在实验中，AI 生成文章的平均搜索排名比人工编辑文章低了大约 60%，其中有 5 篇 AI 文章在发布三个月后仍然没有任何搜索展现。

我们最终沉淀下来的流程是：用大模型做初稿的结构编排和素材整理，然后由真人编辑做核心观点注入和事实核查。具体来说，编辑负责：选题方向的判断（这个主题值不值得写）、数据来源的确认（文章中的数据和引用是否来自可靠来源）、核心观点的提炼（这篇文章要传达什么独特的见解）、以及最终表达风格的把控。这一套流程下来，一篇长文的制作时间从原来的 6 小时缩短到 3 小时左右，但编辑的时间分配从"写稿"变成了"改稿"——角色变了，不是说编辑的工作量减少了，而是工作的性质变了。

在我们评测过的模型中，针对中文 GEO 场景的表现排序如下：DeepSeek 性价比最高，生成稳定，尤其是 5000 字以上的长文本生成连贯性不错；通义千问的中文理解和指令遵循能力突出，但在处理长文本时偶尔会在中间段落跑偏主题；豆包的中文用户界面友好度最高，但 API 接口不够成熟，自动化接入的成本较高。英文 GEO 场景我们主力用 Claude 配合 GPT-4 做交叉验证。

另外我们还测试了不同内容类型对大模型的适配度。技术教程类内容 AI 生成效果最好，因为这类内容结构固定、逻辑性强、知识更新频率低。产品评测类内容效果次之，需要编辑补充大量实际使用体验。观点评论类内容效果最差——AI 生成的观点文章缺乏真正的立场和深度，即使使用"以某领域专家的口吻撰写"这样的提示词修饰也没用，读者能感觉到文章缺乏真实的见解支撑。

场景二：RAG 检索增强生成将外部知识检索与大语言模型生成相结合的技术，通过向量数据库存储和检索相关信息来增强模型的准确性和时效性。——从论文宣传到生产落地之间的距离

我们搭建了一套基于 LangChain 的 RAG 系统，用于给编辑团队提供历史文章的检索参考和素材支持。技术选型如下：向量数据库用 FAISS，向量模型用 BAAI/bge-large-zh（这是一个在中文语义检索场景表现不错的国产模型）。文档分块策略我们试过 256、512、1024 token 三种规格，测试了大约 200 次检索查询，最终结论是 512 token 在召回精度和信息完整性之间取得了最好的平衡。分块大小不是越大越好，也不是越小越好：256 token 的分块会把一段完整的论述拦腰截断，导致检索时丢失关键的上下文信息；1024 的块混入了太多不相关内容，精确定位的能力反而下降。

在检索策略上，我们采用了 BM25 关键词检索和向量语义检索的混合策略。简单来说，就是用 BM25 做精确匹配兜底，用向量检索做语义扩展，最后用加权融合的方式综合排序。测试表明混合策略的召回率比单一检索方式高出约 15-20 个百分点，代价是检索延迟增加了 50 到 100 毫秒，在大多数应用场景下可以接受。

但说实话，RAG 在实际生产环境中的表现没有论文和演示 Demo 里说的那么完美。我们在实际测试中发现几个问题：第一，检索到的文档片段和用户问题的相关性经常不够理想，尤其是在用户提问带有背景假设的情况下；第二，大模型在生成答案时经常"自行补充"一些不在检索结果中的内容——这就是大家常说的幻觉问题，在 RAG 场景下虽然没有完全开放生成那么严重，但仍然存在。编辑观点：RAG 在内部知识库场景下确实有价值，比如帮助编辑快速找到站点上之前发过的相关内容，但如果直接用 RAG 生成的答案面向用户输出，就必须做严格的内容审查。

还有一个细节值得注意：文档的格式对检索质量有显著影响。我们测试了 PDF、Markdown 和纯文本三种格式的检索精度。Markdown 格式的文档检索效果最好，因为其结构化的标题层级可以帮助分块策略更好地识别文档的语义边界。纯文本效果次之。PDF 最差，因为在文本提取过程中常出现乱码和段落错位。如果你正在搭建 RAG 系统，建议先把文档统一转换为 Markdown 格式。

另外提一句成本：RAG 系统的硬件开销经常被低估。向量索引需要占用内存，embedding 模型的推理需要 GPU 或者至少是高效的 CPU 实现，再加上 LLM 本身的推理成本，一套在生产环境可用的 RAG 系统每月至少需要几百到几千元的运行成本，具体取决于查询量和文档库规模。小团队在规划预算时要把这笔账算清楚。

场景三：代码辅助——提效工具的合理定位

这个场景我们在那篇 DeepSeek V4 的详细测试文章中有系统的数据，这里只说在实际 GEO 站点开发中的核心结论。AI 编程助手在日常编码中确实能提升效率——写单元测试、处理样板代码、搜索 API 用法这些重复性工作上的提升非常明显。我个人的体验是，使用 AI 辅助编程后，日常开发任务的平均完成时间缩短到了原来的 50-60%。但需要注意一个关键区别：大模型主要提升的是"写代码"的速度，而不是"想代码"的质量。架构设计决策、安全性审查、边界条件判断、以及业务逻辑的正确性验证这些环节，目前还是得靠有经验的工程师来把关。

我们在内部建立了一个审查流程：所有由 AI 生成的代码都必须经过人工 Review，流程包括三层——语法检查、逻辑验证和安全性评估。这个流程看起来多了一步，但实际上比完全不使用 AI 辅助时节省了大约 30% 的整体开发时间，因为 AI 生成初稿的环节节省了大量的键盘敲击时间。

场景四：数据分析——异常检测的实践测试

测试场景：把 GEO 网站 30 天约 50 万条访问日志交给大模型做初步分析，让它识别流量异常模式。具体操作是写了一个脚本，将日志按日期和 URL 聚合后形成结构化数据，再通过 API 交给模型分析。

测试结论：大模型对"剧烈"的异常——比如某天流量突然暴增 5 倍，或者某个页面突然从搜索引擎来源中消失——能很快识别并给出可能的解释。但对于"温水煮青蛙"式的渐变问题——比如某个关键词在搜索结果中的排名连续六周缓慢下滑——大模型基本无感。编辑观点：大模型适合做数据初筛的辅助工具，但远不适合做数据监控的主力工具。最好的工作流是让大模型做第一轮标记，再由人工分析师做深度研判。

场景五：多模型横向对比测试

过去两年我们陆续测试了 10 个以上的大模型在 GEO 内容生产中的表现，这里给出一些简短的观察：

• Claude Sonnet 4.6：英文内容生成的质量目前最好，逻辑连贯性最强，适合做高质量英文文章的主模型。
• DeepSeek V3/V4：中文内容性价比最高，生成稳定，API 延迟低，适合中文内容的大规模生产流程。
• GPT-4：综合能力最均衡，但在中文场景下有时会出现语义偏差，适合做交叉验证的参照模型。
• 通义千问（Qwen）：中文指令理解最好，适合做需要精确遵循格式的批量任务，但长文本推理能力弱于 DeepSeek。
• 豆包：界面友好，但在生产自动化方面的接口灵活度不够，更适合个人使用而非团队协作。

Transformer 架构的真正价值——编辑视角

我不打算长篇大论地科普 Transformer，因为这方面的教程已经太多了。但有一个关键点值得单独提出来说：2017 年 Google 提出的 Transformer 架构之所以能取代 RNN 成为大模型的基础架构，核心原因不是它更"智能"，而是它可以并行计算。RNN 需要按顺序逐个处理序列中的元素，就像你读一句话时必须一个字一个字地读。而 Transformer 的自注意力机制Transformer架构的核心组件。它允许模型在处理序列数据时，为序列中每个位置分配不同的注意力权重，从而能够同时关注并捕捉序列中所有位置之间的依赖关系，无论距离远近。可以一次性看到整个序列中的所有词，并计算它们之间的相互关系。

这个差异的工程意义是巨大的：并行意味着可以用更多的 GPU 同时训练，可以用更多的数据训练更大的模型。大模型在过去几年表现出来的"智能"飞跃，很大程度上是"算力堆砌 + 数据扩展"带来的规模效应，而不是架构层面的颠覆性创新——这个角度在绝大多数技术科普文章中都被忽略了。理解这一点有助于我们更理性地看待大模型的能力边界：它在模式匹配和信息重组方面非常强大，但在需要真正理解因果关系和进行类比推理的任务上，目前所有的模型都还停留在"高级模式匹配"的阶段。

中国市场观察

在中国做大模型相关的应用有几个和美国很不一样的情况。

第一，监管环境。国内对 AIGC 内容有明确的管理要求，不是所有模型都能随意做面向用户的直接内容生成。这在短期内限制了一些应用场景——比如自动化客服和完全无人干预的内容生产。但从长期来看，合规要求反而可能淘汰低质量的 AI 内容生产商，促使从业者更关注内容质量和信息可信度。对于做 GEO 的团队来说，这意味着"AI 辅助 + 人工审核"的模式不仅是在当前技术条件下的最优解，也是符合监管要求的选择。

第二，模型价格战。DeepSeek、通义千问、豆包等国产模型之间的价格竞争已经白热化，呈现出远超国际市场的降价幅度。对中小型团队来说这是一个巨大的利好——过去用 GPT-4 API 每月几万元的调用成本，现在用国产模型可能只要几千元甚至几百元。但从我们实际的对比测试来看，国产模型和 Claude、GPT-4 之间在复杂推理能力和多轮对话一致性方面还有可见的差距。做内容生产时，国产模型处理基本的改写、摘要、翻译任务已经很好，但涉及到需要深度推理的任务——比如从多篇长文中提取矛盾观点并进行对比分析——时，表现不如海外前沿模型。

第三，开发者生态差异。中国开发者群体对工具的价格敏感度更高，对中文技术术语的处理能力有硬性需求。在我们的读者调研中，约 70% 的个人开发者表示每月 AI 工具的预算是 100 元以下。这个数字可以帮助海外模型厂商理解为什么免费或低价的国产模型在中国市场更具竞争力——不是技术能力更强，而是价格门槛决定了用户基础的规模。

第四，中文内容的特殊性。中英文在语言结构和表达习惯上的差异很大，决定了直接套用英文场景下的 AI 工作流必然会有适配问题。比如，中文的段落结构通常比英文更短、更灵活，中文的标点使用习惯也和英文不同，搜索引擎对中文内容的 E-E-A-T 评估标准也与英文不同。这意味着面向中文场景的 AI 内容工具需要做针对性的训练和调优，不能简单地把英文方案翻译过来用。我们测试过用英文提示词生成的 SEO 方案直接套用到中文站点上，效果远不如使用专门优化过的中文提示词。比如，中文的段落结构通常比英文更短、更灵活，搜索引擎对中文内容的 E-E-A-T 评估标准也与英文不同。这意味着面向中文场景的 AI 内容工具需要做针对性的训练和调优，不能简单地把英文方案翻译过来用。

使用大模型做内容质量评估的测试

除了用大模型生成内容，我们还试过用大模型做"质量评估工具"——让模型给文章打分并提出改进建议。测试了两种方案。

方案一：写一个详细的评估 prompt，从信息密度、逻辑连贯性、语言流畅度、原创性、SEO 友好度五个维度打分，每项 1-10 分。测试了 30 篇文章，发现大模型的评分和人工评分的相关性大约在 0.6-0.7 之间（即中等正相关），在信息密度和逻辑连贯性两个维度上一致性较高，在原创性上完全不可靠——大模型会把一些常见的表达方式误判为抄袭。

方案二：让模型扮演读者的角色，对文章提出"读完后还有哪些疑问"。这个方案的意外效果很好——模型提出的一些问题确实能帮助编辑发现文章中的逻辑漏洞和表达不清之处。编辑观点：用大模型做"读者测试"比用大模型做"评分工具"更有实际价值。

第三，开发者生态差异。中国开发者群体对工具的价格敏感度更高，对中文技术术语的处理能力有硬性需求。海外模型在中文技术语境中的术语理解——比如"熔断""降级""限流""背压"这些在中文技术社区中常用的词汇——往往不如国产模型准确。这意味着在工具选型时，不能只看国际基准测试的排名，还要考虑实际业务场景下的语言和文化的适配度。

编辑的实践建议

如果你是一个正在考虑用大模型做内容或开发的中小团队负责人，我的建议有三条。

第一，不要追求全自动化。从我们两年多的经验来看，大模型最适合做辅助工具而不是替代工具。把它用在你可以快速验证和纠错的环节——比如写作初稿、代码初稿、数据初筛。而不是用在需要高度可靠和安全性的环节——比如面向用户直接发布的最终内容、运行在生产环境的代码、以及关键的业务决策依据。目前的技术水平下，"完全自动化"是大模型应用中最大的陷阱。

第二，建立多模型组合工作流。我们团队现在同时使用 DeepSeek（主力中文内容生产）、Claude（英文内容和代码审查）和通义千问（批量格式化任务），不同的任务交给不同的模型。目前市面上没有任何一个模型在所有场景下都表现最好，单模型依赖的风险比很多人意识到的要大——一旦模型厂商调整 API 定价、更新模型导致行为变化、或者出现服务中断，依赖单一模型的团队会面临严重的业务风险和不可控的切换成本。

第三，建立你自己的评估体系。大模型行业的变化速度是我见过最快的技术领域——半年前还领先的模型，半年后可能就被反超了。不要迷信任何第三方评测报告的结论，因为它们评测的基准测试很可能和你的实际使用场景完全不相关。花一点时间建立你自己的评估标准和测试集，用你自己真实业务场景的数据定期做对比测试，这比看任何行业报告和评测文章都更靠谱。

第四，做好人工审核环节的流程设计。许多团队在使用 AI 工具后忽略了一个问题：人工审核变成了效率瓶颈。如果你的流程设计是"AI 做 100 件事，人工逐一审核"，那人工反而变成了最慢的环节。正确的做法是设计分级制度——低风险的内容（如格式调整、简单的重写）走快速通道，高风险的内容（如面向用户的核心文章、涉及数据的分析报告）走深度审核通道。把 AI 应用于产生最大效率增益的环节，同时不让人工审核的负担抵消掉 AI 带来的效率提升。

第五，重视成本控制。不同模型的 API 价格差异巨大，而且价格和性能之间并不总是正相关。DeepSeek 生成一篇 3000 字文章的成本大约比 GPT-4 低一个数量级。如果你的内容产量大，建议建立一个成本监测机制，定期评估每个模型在每项任务上的投入产出比。"最便宜的模型"不一定是最优选择，但"最贵的模型"也未必带来相应的价值提升。