近期进行了两次企业AI咨询，发现市场对AI编码（AI Coding）的需求已非常迫切，几乎成为刚需。为此，我们调整了课程重点，并从中提炼部分核心内容，撰写了以下文章： 这些案例均源于真实的生产实践。出乎意料的是，评论区的热烈讨论甚至超过了正文本身。 有人质疑其为夸大其词，有人认为这是在给管理者提供“压榨”工具，也有不少人诚恳地追问：你们究竟是如何做到的？

坦率地说，部分质疑是可以理解的。如果是我初次看到“十年老系统、54万行代码、两周重构完成”这些词汇组合在一起，第一反应恐怕也不是赞叹，而是怀疑：

这该不会是又一个关于AI的神话（或者说笑话）吧？

然而关键在于，这件事确实发生了。它并非PPT演示，也不是概念验证，而是一个已经过灰度测试并上线的真实系统。 因此，本文不再赘述AI能力有多强大，也不打算将其写成一篇“爽文”。我们将认真探讨以下四个核心问题：

1. 这件事的具体实现路径是什么？
2. 其成功真正依赖的前提条件有哪些？
3. 这种方法的边界和局限性在哪里？
4. 普通技术团队能否复制？管理者应如何正确理解？

需要说明的是，我们会在尽量不透露过多课程专属细节的前提下，真诚地进行解答。也希望大家在今后的工作中，避免对AI编码产生极端误解。无论是将其神化、认为无所不能，还是将其妖魔化、视为给老板画饼的工具，都是不恰当的。正确的态度是拥抱变化，切勿故步自封。

质疑焦点：真是两周完成的重构吗？

首先，澄清最易引发争议的问题：这算不算是“两周重构完成”？ 这是评论区最集中的质疑点。因为在许多工程师的认知中，“重构完成”默认包含了大量工作：

1. 业务逻辑梳理
2. 技术方案设计
3. 核心功能开发
4. 回归测试
5. 灰度观察
6. 线上稳定运行
7. 长尾问题闭环
8. … 如果按照这个标准来理解，“两周搞定十年老系统”确实像天方夜谭。 因此，我们首先明确口径：

这里的“两周”，特指核心迁移开发、关键行为对齐以及基础验证的时间周期。 后续的灰度切流、线上观察及零星修复，又持续了一周多。

换言之，所谓的“两周重构完成”，更准确的表述是：代码层面的主体迁移工作，在两周内交付完成。 这并不意味着两周内就解决了所有上线后问题、所有隐性分支逻辑以及所有历史兼容性细节。这两种说法差异显著：前者是一个高强度但真实的工程案例；后者则容易沦为营销叙事。不过，两周与四周的时间差异，真的具有决定性意义吗？

项目本质：是翻译还是重构？

整个讨论中，我们认为最专业的问题是：这究竟算重构还是翻译？这个问题值得深入探讨。 因为很多人一看到“重构”这个词，脑海中浮现的是另一幅图景：

1. 重新梳理领域模型
2. 重新划分服务边界
3. 重写系统架构
4. 借此修复历史技术债务
5. 顺便整理不合理的业务逻辑
6. … 若按此理想标准，本次项目当然不能算作那种彻底的“大重构”。 因为我们最核心的目标，从来不是“重做一个更先进的系统”，而是：

在不改变外部行为的前提下，将一套运行了十年的PHP老系统，迁移至Java技术栈，并降低后续维护成本。

因此，更准确地说，本次项目的本质是：

1. 平迁（Lift-and-Shift）
2. 行为对齐
3. 强类型化改造
4. 工程化能力补全
5. 包含局部优化的重构
6. … 所以，如果说它是“翻译 + 小部分优化”，这个说法并不算错。但如果仅仅视其为“翻译”，则低估了其中的工程含量。 因为纯粹的翻译不会做以下工作：
7. 将PHP的弱类型Map全链路替换为Java DTO
8. 将一堆历史逻辑拆分为可维护的模块
9. 补全缓存、RPC、序列化、并发等方面的工程约束
10. 实施双端验证、日志闭环、差异追踪、PHP同步监控
11. 在上线阶段设计灰度与回滚策略

如果非要寻找一个更精准的定义，我们会如此描述本次项目：

这是一次以平迁为主、以行为一致为约束、以强类型化和工程能力补全为核心目标的重构。

它既非纯粹的翻译，也非理想化的大重构，更像是一场“开着车换轮胎”的工程迁移。

可信度挑战：为什么传统路径行不通？

至此，我们再来探讨：为何许多人觉得此事不可信？ 因为按照传统路径，这类项目几乎无法推进。试想一下，一个运行十年的老系统，54万行PHP代码，文档缺失，自动化测试几乎为零，大量逻辑混杂着业务补丁、历史兼容代码和临时修复。 面对这样的系统，传统做法通常是：

1. 花费大量时间理解系统全貌
2. 梳理业务逻辑和技术债务
3. 补充测试用例
4. 再逐步开始重构
5. … 听起来合理，但在现实中经常倒在第一步。 这类系统最棘手的并非“代码量大”，而是：

你根本无法确定眼前这段糟糕的代码，究竟是在解决一个真实问题，还是仅仅在堆积历史遗留的“屎山”。

基于我们此前一系列关于AI编码的真实实践，近期收到了许多关于国内编程工具选择的咨询。在众多选项中，Qoder无疑是值得重点关注的工具之一。

Qoder近期推出了0.8.0版本更新，新增了一项名为“Experts Mode”的功能。作为Pro+用户，我在第一时间进行了升级体验，现将完整的实测过程与个人感受分享如下。

Experts Mode 核心概念解析

在早期版本中，Qoder主要提供两种工作模式。新版本在此基础上引入了第三种模式——Experts Mode。为了清晰理解其定位，我们先对比一下这三种模式的区别：

那么，Experts Mode具体是如何运作的呢？

用户仅需描述一个需求，Qoder的**主导智能体（Leader Agent）**便会自动将任务分解为若干子任务，并组建一支专家团队。每位专家都是经过专项优化的软件工程智能体，负责不同的专业方向。他们能够并行推进工作，各自专注，互不干扰。

用一句话概括其核心理念：用户提出需求，AI自动组建团队协同完成。

这里需要特别指出一个关键区别：市面上许多所谓的多智能体工具，本质上只是“同一模型搭配不同提示词”，模拟出多个角色，其实际能力并无本质差异。

而Qoder的Experts Mode则采用了不同的架构。每位专家（Expert）都是针对特定任务类型进行深度优化的独立智能体，并且系统会根据任务自动将其路由到最合适的底层模型。例如：在规划阶段使用擅长逻辑推理的模型，在编码阶段使用代码生成能力更强的模型，在测试阶段则调用更适合自动化验证的模型。

当前版本的专家团队包含以下角色，未来可能还会继续扩充：

不难发现，这套机制与传统软件开发团队的协作模式高度一致：有人分解需求，有人进行调研，有人负责前后端开发，有人执行测试，还有人进行代码审查。不同之处在于，这一整套流程被压缩并集成到了AI系统内部，可以实现并行执行与自动调度。

因此，Qoder的Experts Mode不再是一个“聪明的单一智能体”，而更像是一支按照专业分工紧密协作的完整工程团队。

实战案例演示

话不多说，我们直接进入实战演示。

需求描述

我向Qoder提出了如下需求：

基于 DeepSeek API 开发一款Web端对话应用，提供流畅的对话体验与精美的界面。具体功能如下：

- 对话页面(无底部导航栏)，输入框仅支持文本输入，大模型输出需支持流式返回，并能够渲染Markdown格式（包含表格与代码）。
- 在页面右下角提供新增会话的悬浮按钮，点击后创建新的会话记录。
- 提供历史对话侧边栏，通过左上角按钮打开，支持删除会话、切换会话、新增会话、重命名会话。
- 每次请求仅携带当前会话最近20条历史消息。
- 会话相关数据缓存在本地存储。

功能需求描述得较为清晰，但我有意没有指定技术栈，也未说明API Key的处理方式，目的是观察系统是否会主动发起询问。

就在不久前，国产AI标杆DeepSeek正式推出了其全新的模型迭代，完整版本号为DeepSeek-V3.2-Speciale (02-2026)。官方披露的核心升级点涵盖多个维度：

1. 推理能力实现质的飞跃 - 在数学运算、代码编程、逻辑推演等复杂任务上的表现取得了显著进步。
2. 知识库完成重要刷新 - 模型的知识截止日期已延伸至2025年5月，确保了信息的时效性。
3. 长上下文理解能力精进 - 对多轮、冗长对话的整体脉络与细节把握变得更加精准。
4. 回复质量全面优化 - 生成的答案在准确性与条理性上均达到了新的高度。

然而，上述提升仅是基础。真正让该版本在全球范围内引发强烈关注的，是其在关键性能指标上实现的突破性优势：

1. 推理成本堪称全球最低，每百万tokens仅需0.14元人民币，在全球主流模型中处于绝对领先地位，其成本仅为GPT-5.1的八十分之一。
2. 上下文长度问鼎全球巅峰，支持高达1M tokens的上下文窗口，这意味着模型可以一次性处理相当于《三体》三部曲总和的文本体量。
3. 首字延迟速度行业领先，平均首字输出时间小于0.2秒，其流式响应速度极快，用户体验无限接近人类对话的自然停顿节奏。

综合来看，DeepSeek-V3.2的核心标签可概括为：具备顶级推理能力且价格最亲民的模型、拥有最长上下文处理窗口的模型，以及在国内权威评测中位列第一的模型。

这些特性无疑令人振奋，但更深的期待在于另一个维度。正如行业共识所预示，2026年将成为智能体（Agent）技术大规模应用的元年。作为备受瞩目的核心模型，DeepSeek在此次更新中为Agent能力进行了哪些专项优化呢？

回顾历史，模型针对Agent场景的优化通常聚焦于特定能力：

Agent执行任务最核心的两大能力在于“任务分解”与“工具调用”。

根据DeepSeek公布的部分评测数据：

1. 在天罡评测体系的“任务分解”单项中，得分高达93.5，稳居国内榜首。
2. 在天罡评测体系的“信息抽取”单项中，得分达到93.49，同样位列国内第一。

整体性能可参考下图。不过，目前披露的信息仍显不足，或许需要等待更详细的数据集跑分结果，才能全面揭示DeepSeek在Agent侧所做的深层优化与具体提升：

上个月，Manus1.5的发布，其核心演示点集中在网站开发领域，尽管未明确提及，但几乎直指前端开发。

紧接着，近日Gemini3的推出，网络上各种喧嚣的观点再次指向**前端已死！**前端开发为何屡屡成为焦点，不断面临各种挑战？

从早期互联网萎缩宣称前端已死，到各类SaaS工具平台涌现前端再死，随后低代码、零代码兴起依然前端死，再到Coze、Dify出现还是前端死，以及Cursor、Claude Code问世自然也是前端死……

前端似乎成了众矢之的，如今各公司领导者也似乎采纳了这些观点，不久前某公司前端团队裁员比例高达50%，这已非危言耸听，前端领域确实面临严峻压力。

因此，我们不得不深入探讨：AI是否真的意图取代前端开发？

AI对前端的冲击：范式和数据

首先，AI对程序员，尤其是前端开发者的冲击如此直接和剧烈，核心原因在于范式和数据。

AI模型对开发者的编码习惯有深入理解，同时各种开发框架已相当成熟。

自ChatGPT问世以来，能够稳定消耗算力的文本类AI应用，主要集中于即时聊天、AI客服以及AI编程三大领域。

其中，AI编程的快速发展，离不开全球开源社区构建的庞大代码语料库。GitHub上超过2亿个开源仓库，为代码模型的训练提供了海量、结构化且高质量的“教材”。

将视角聚焦于前端，我们会发现一个关键事实：业务逻辑的可穷举性。

前端的业务逻辑，尤其是UI组件与交互模式，相对规整且高度模式化。经过数十年的演进，这些模式在GitHub上已被近乎完全穷举。这意味着：训练一个精通前端开发的AI，所需的数据是完全充足的。

相比之下，后端领域虽有大量代码，但企业的核心业务逻辑代码通常不会开源，导致语料在深度上存在缺口。至于芯片设计等更底层领域，由于缺乏开源语料，AI辅助编程几乎难以开展。

因此，我们必须承认：正是由于前端业务逻辑的相对简单性与开源语料的极度丰富，使得AI在前端领域能够快速达到“优秀”水平，从而对前端开发中“代码生成”这一环节构成了最直接的冲击。

这一冲击在当前工具生态中已显现端倪。从GitHub Copilot到Cursor，从Claude Code到通义灵码，AI编程助手正快速渗透前端开发的日常工作流程。

业界估计与我的实践经验一致：前端开发中约60%以上的标准化任务已可实现高度自动化，包括组件生成、样式编写、基础业务逻辑实现等。

那么，前端是否即将被淘汰？常说的AI对前端的10倍效率提升究竟体现在何处？

AI在前端开发中的效率提升：理想与现实

根据个人实践：AI确实能在某些场景下实现10倍甚至100倍的效率提升，但在真实业务开发环境中，实际的效率提升通常低于60%。

为何存在如此大的差距？接下来，我们详细拆解这一问题。在许多AI的宣传案例中，经常出现以下示例：

输入提示词：  
“帮我实现一个数独游戏，使用JavaScript实现。”

大约30秒后，Cursor即可完成从需求分析、问题拆解、编码实现到效果预览的完整流程。示例效果：

这个数独游戏不仅功能完整，还支持响应式布局。

如果让开发者手动编码实现，大约需要4-8小时，而Cursor仅需30秒，提升的效率何止10倍？甚至达到100倍。

这类场景的确容易让人认为AI具备颠覆性的效率提升。但我们需要剖析这些案例的特点：

1. 需求清晰、任务简单：数独游戏的规则固定，AI只需基于已有训练数据生成代码，而不需要额外的上下文理解；
2. 代码质量不重要：在展示“AI速度”的场景中，代码的健壮性、可维护性往往被忽略。即使生成的代码不符合团队规范、不易扩展，也不会影响展示效果；
3. 极端场景的放大：一些演示视频可能会挑选AI表现最优的时刻，而忽略它犯错的情况。例如，在AI生成UI代码时，可能会遗漏复杂交互的细节，导致实际使用时需要大量修改；

这种能力对于非专业开发者快速验证MVP的门槛大幅降低。

然而，这仅仅是理想化场景，现实中的业务开发却远比这复杂得多。

实际业务开发中的AI应用分析

为了分析AI在业务开发中的实际提效，我们先拆解前端开发的典型流程，以及各环节的大致时间占比：

从表格可以看出，占据开发者较多时间的环节主要是：

1. 需求分析
2. UI还原与组件开发
3. 业务逻辑实现
4. API集成与调试

接下来，我们分析AI在这些环节中的实际表现：

需求分析：AI介入难度极大

原因很简单：

1. 需求分析涉及业务背景、上下文理解、利益取舍，需要大量主观判断。
2. 需求变更频繁，AI很难高效处理动态变化。
3. 许多需求难以用自然语言准确描述，导致AI生成的内容不够精准。

结论：AI在需求分析环节几乎无法发挥作用。

UI还原：能力有限，仍需大量人工调整

当前AI可以基于Figma设计稿或截图生成UI代码，但仍然存在较多问题：

回顾过去几年的创业历程，我获得的最重要认知是：一切商业竞争的终点，最终都将演变为对用户注意力的争夺。

面向企业的AI服务（AI to B），让我得以深入市场一线，洞察客户的真实付费意愿，掌握了将产品推向市场的方法论，同时也深切体会到了盈利的艰辛。 面向消费者的AI服务（AI to C），则让我在实践中深刻领悟了流量运营的精髓，特别是如何高效获取免费流量。在当今商业环境中，流量的价值毋庸置疑。

我观察到众多企业，从早期的搜索引擎优化、公众号运营到如今的短视频营销，其流量策略始终紧跟平台变迁的步伐，与不断演进的平台算法进行着一场持续的“博弈”。

若要问每个流量阶段的特性是什么：那么答案往往是缺乏恒定不变的规则，正因如此，企业才会组建专门的流量团队与平台“周旋”。这些团队在流量获取上的年度预算投入可能超过总成本的60%，比例之高令人咋舌，也直接导致了团队普遍存在的流量焦虑。

近期，这种焦虑感进一步加剧了，因为流量分配的基本逻辑正在经历一场深刻变革。以我最近咨询的一家公司为例，其流量团队反馈：

当前各家企业在百度竞价广告（SEM）上的投入已大幅缩减（效果不尽如人意），甚至整个浏览器端的SEO流量份额也在急剧萎缩。企业流量的主战场已经转移至微信、抖音、小红书等内容生态体系。

该团队判断：未来，生成式引擎优化（GEO）将吞噬大量流量，因此他们成立了专项小组对此进行研究。

然而，GEO领域目前同样缺乏明确的规律可循，团队既往的研究成果或实践经验都具有一定的时效性，很可能在几个月后便不再适用。因此，他们迫切希望更深入地理解GEO的本质，以便进行长远的战略布局。

今天，我们就来深入探讨一下什么是GEO。

GEO的本质

探讨GEO，必然要提及SEO，因为两者仅有一词之差：

SEO的核心目标是确保内容能被搜索引擎检索并排名靠前，其优化策略侧重于TDK（标题、描述、关键词）的优化，以及在高权重网站获取反向链接等。

而GEO，其效果直接依赖于大语言模型的输出能力。模型的输出又取决于两大数据源：一是内置的预训练数据，二是实时调用的外部数据（通过爬取各类网站获得）。

所谓GEO，就是使你的（产品或服务）内容成为模型生成答案时的优先选择，更准确地说，是成为模型的首选知识来源。如下图所示：

大语言模型是一套标准化的输入-输出系统。GEO的目标是通过影响模型训练时所用的语料，或者其回答问题时所参考的外部知识库，最终达到影响其输出结果的目的。

更进一步说，GEO的优化动作实质上是去影响大语言模型的这两个数据源，其本质与RAG（检索增强生成）技术异曲同工：

首先，内置数据源（预训练数据）很难被外部力量直接影响。基础模型的训练数据核心目的是提升模型在各领域的通用推理能力，因此很难将大量相对次要的品牌信息纳入其中，这些信息对模型而言可能被视为负担甚至噪声。

因此，各公司的GEO核心策略便放在了如何**“影响”或“优化”模型的外部数据源上**。这里的逻辑与传统SEO的筛选过程类似：

1. 第一步是让模型能够“找到”你，这要求你的内容必须数量充足、更新及时。
2. 第二步是让模型能够“信任”你，这要求你的内容所发布的平台需具备一定的权威性和可靠性。
3. 第三步则进入了模型的“黑箱”，即模型如何具体判断你内容的优质程度，这因各家基础模型厂商的算法差异而各不相同。

综上所述，现阶段各团队在GEO方面能切实操作的只有上述第1、2两点：在全网发布大量内容，并尽可能选择优质平台进行分发。

接下来，我们简要探讨一下具体如何操作。

如何做GEO

首先，大家需要了解一个正派路线框架：E-E-A-T（经验、专业度、权威度、可信度）。该框架源自谷歌的《搜索质量评估指南》，用于评估网页或内容的可信度与质量。

简而言之，其内涵是：我拥有实际经验（E1）+ 我具备专业知识（E2）+ 行业/公众认可我（A）+ 我的内容值得信赖（T）。这套标准恰好可以映射到模型输出的可追溯性要求上：模型应输出来源明确、数据可验证、署名清晰的内容。

遵循E-E-A-T框架是为了让模型更好地理解和信任你的内容，它属于一种面向模型知识源的内容创作范式。只不过，当前模型能力强大，可用的范式多种多样。在实际操作中，我们不需要如此复杂，直接采用**“量大出奇迹”的策略，利用AI工具批量生成内容，并以不同格式在全网广泛发布即可。这种方法往往效果显著，唯一的风险是容易触发各平台的封号机制**。

这里给大家分享一个我们自身产品的实践案例：

此外，与之思路类似的做法是尝试影响基础模型的记忆。例如，通过多个账户持续向某个基础模型提问特定问题，经过一段时间后，模型有概率会“记住”并收录这些信息：

当然，还存在一些其他技巧，但大都比较**“偏门”**，在此就不便详述。如果仅讨论比较正派的策略，我可以随意提出两点思路：

一、猜一猜策略

大模型时代的流量获取将更具技术含量，它要求我们去揣测用户倾向于如何提出问题。

尤其是对于那些长尾的、具体的提示词（用户查询），我们提供的内容如何才能被模型优先选中，这将是关键所在。

因此，这里的工作重心从购买关键词，转移到了穷举用户可能的各种提问方式上。

二、构建权威矩阵

无论国内还是国外，当AI生态发展成熟后，模型势必更倾向于从权威渠道获取信息。因此，如果我们能够成为某个垂直领域的信息入口，或者我们能在各类权威渠道持续发布信息，这些内容将更容易被AI采纳。例如，我们在开发医疗AI产品时，就对信源设定了如下优先级：

1. S级：行业权威诊疗指南 →
2. A级：顶级学术期刊论文 →
3. B级：经典医学教材 →
4. C级：临床专家的经验总结 →
5. D级：医院内部的疑难病例库

关于效果监测平台

其实大家已经看出，上述所有策略均是对E-E-A-T框架的具体实践。但这里存在一个普遍问题：只有内容投放，缺乏效果监测。没有监测就难以评估GEO的投入产出比。例如：即使你的内容被模型引用了，你很可能也全然不知。

因此，现阶段非常需要一个GEO效果监测平台。它至少需要告诉我们内容被引用了多少次，以及是以何种形式被引用的。然而，由于涉及隐私和平台安全，这样的平台很难真正出现。如果未来能够实现，它很可能呈现如下形态：

图源：《7亿人都是如何使用ChatGPT的》

在此进行一下总结：GEO目前仍带有些许“玄学”色彩，但其底层逻辑是清晰的。它本质上是一场针对AI数据源的“供给侧改革”。

在当前阶段，“正派”与“偏门”的做法皆可尝试，能有效获取流量即是成功。并且，不同发展阶段可能需要侧重不同的策略。总而言之，正派策略或许能带来更持久的效益，而偏门方法也可能在一定时期内行之有效。

实操经验分享

接下来，我们通过一个实践案例，来具体看看某公司的流量团队是如何操作GEO，并取得了哪些成效。

需要说明的是，首先GEO的效果本身就不稳定，其次客户公司也不希望我们透露过多细节。因此，这部分内容无法过于具体，仅供大家感受其思路与方法。

该公司进行GEO的目标非常明确：让全球各地的主流AI，当用户询问相关产品时，能优先且准确地将他们的产品推荐为“标准答案”。

此前，我们探讨了关于AI浏览器作为未来流量入口的竞争格局。既然流量的核心入口呈现出从传统浏览器向AI浏览器迁移的趋势，那么其背后的信息检索底层技术也必然发生根本性的转变：从搜索引擎优化（SEO）转向生成式引擎优化（GEO）。这标志着围绕关键词布局、外链建设等传统逻辑正在逐渐失效。

GEO：Generative Engine Optimization，即生成式引擎优化。

关于AI将取代搜索引擎的讨论由来已久。例如，三年多前笔者从事医疗AI领域工作时，在产品演示直播中就有许多观众表示：AI能否替代医生尚不可知，但替代百度这类搜索引擎则是必然的。

现实情况也印证了这一点。目前，我仅在三种特定场景下才会使用百度或谷歌：

1. 首先，检查网络是否断开；
2. 其次，确认VPN代理是否正常工作；
3. 最后，当对AI生成的答案存有疑虑，需要追溯和核查原始信息源时。

我们深知流量即商业价值。当用户日益频繁地向AI咨询产品、寻求解答时，一个核心问题便浮现出来：我们应当如何**“优化内容以适配AI”**，从而让自家的产品或信息被优先推荐？如下图所示：

一个明显的趋势是：近期咨询GEO相关策略的企业主显著增多，他们普遍关心两个实际问题：具体该如何操作？以及需要投入多少成本？

要深入解答这些问题，或许需要从大语言模型的底层运行逻辑谈起。

GEO的底层逻辑

如图所示，大语言模型（LLM）本质上是遵循特定模式的输入输出系统。GEO的核心目标，是通过影响模型训练阶段所使用的语料库，或者干预其回答问题时调用的外部知识库，最终达到塑造和影响其输出内容的目的。

这与传统SEO存在显著差异。搜索引擎的排序算法相对透明，首先高度重视网站的整体权重，其次考量页面的多项关键指标（如关键词密度、停留时间等）。这种清晰的排序逻辑使得关键词竞价等商业行为具有可预测性和可计算性。

然而，LLM将海量语料“消化吸收”后，其内部形成了一个复杂的“黑盒”。不仅内容发布者难以预知自己的信息何时会被调用，甚至模型开发者也可能无法保证输出结果的绝对稳定性。因此，在当前阶段，若有企业主急于在GEO领域进行大规模投入，很可能需要承担较高的试错成本与风险。

我们有必要尝试解析这个“黑盒”。首要问题是：模型生成答案时所依据的内容究竟从何而来？

厘清内容来源是理解GEO的基础。答案主要集中于以下三个方面：

一、固化数据：模型的内嵌知识库

第一部分是模型参数内封装的固有知识，即通过预训练和微调阶段注入的数据。这些数据构成了模型认知世界的基础框架与知识体系，犹如一座经过高度压缩的巨型图书馆。

在此层面，试图通过直接“投喂”数据来影响基座模型，对于绝大多数公司而言是一个不切实际的目标。若有服务商承诺能将网站数据直接编入诸如ChatGPT之类的核心模型，这几乎可以判定为夸大其词。

当然，这并非意味着完全无法介入。用于训练的数据要求具备极高的质量，必须是权威、精炼的精品内容，其准入门槛本身就极高，例如：在顶级学术期刊上发表SCI论文。

二、RAG：当前GEO的主战场

第二部分是检索增强生成（RAG），这是目前GEO最核心、最具有现实操作空间的优化方向。当用户提出问题时，AI系统会实时从互联网检索最新相关信息，将这些信息作为“上下文”与用户问题一并提交给LLM，进而生成基于实时信息的答案。

其具体工作流程通常包括：AI对用户问题进行意图识别与关键词解析，随后从预设的索引库中查找相关网页。

需要特别注意的是，这一过程仍然在很大程度上依赖于传统搜索引擎的索引与排序逻辑。因此，扎实的SEO基础能力在此环节依然至关重要！

背后的核心逻辑在于：AI系统会优先选取并信赖那些来自权威、可信、专业信息源的内容（这意味着E-E-A-T原则的重要性丝毫未减）。

注：当然，实际应用中也存在一些不尽如人意的情况。例如，近期观察到某些模型在生成答案时引用了CSDN社区中质量参差不齐的内容，这确实令人有些无奈。

在这一领域，策略的核心仍然是在优质平台上进行大规模的内容发布。至于“大规模”的具体标准，则见仁见智，本质上这依然是一种依托平台流量分发的逻辑。

这里存在一个关键洞察：某些对人类读者体验不佳的文档格式，可能对AI处理异常友好。所谓“对AI友好”通常具备以下特征：

1. 以清晰的问答对形式组织；
2. 内容体量庞大、覆盖信息点全面；
3. 采用短句结构，便于被精准截取和引用；
4. ……

三、外链的辅助作用

第三部分是超链接。如果问题描述或相关文档中包含了链接，模型有时也会尝试访问并读取链接内容。然而，仅凭这一点对于GEO效果的提升帮助较为有限。

综上所述，从模型的内容生成逻辑来看，其核心评判标准似乎依然延续了E-E-A-T原则的框架：

1. 经验（Experience） - 这是一个新增且日益重要的维度。
2. 专业度（Expertise）
3. 权威度（Authoritativeness）
4. 可信度（Trustworthiness）

以上是对GEO基本逻辑的初步梳理。接下来，我们需要思考第二个关键问题：对于AI领域的创业者而言，是否应该搭上GEO这班车？它当前的实际商业价值究竟如何？

GEO的市场价值与前景

关于GEO市场的具体规模，目前可查证的直接数据相对有限：根据Valuates的研究报告估算，2024年GEO相关服务市场规模约为8.86亿美元，预计到2031年将增长至73.18亿美元。

我们可以通过相邻市场的规模作为上下界参考：传统的SEO服务市场预计在2025年达到约749亿美元，2030年有望增至1273亿美元。

同时，市场预算迁移的信号已十分清晰。例如，美国的AI搜索广告收入预计到2029年将达到259亿美元，占据整个搜索广告市场的13.6%。

从需求端渗透率来看，谷歌的“AI Overviews”功能在2025年3月已触发了高达13.14%的搜索查询。

综合而言，GEO虽然仍处于早期发展阶段，但已展现出可观的成长潜力：在AI搜索渗透率持续提升与市场营销预算结构性转移的双重驱动下，它正从一个“增量试验田”逐步演变为独立的细分市场。

从纯粹的数字增长角度判断，GEO的价值毋庸置疑。然而，必须清醒认识到，这块市场蛋糕的大部分利润很可能被基座模型公司所摄取，并且他们已经在积极布局。

流量入口的争夺战

我们之前讨论了AI浏览器作为下一代流量入口的趋势，也提及了像Atlassian以6.1亿美元收购Dia这类标志性事件。这些都明确显示，流量入口的主导权正从传统浏览器向AI浏览器及更广义的智能交互界面转移。

因此，科技巨头们纷纷加大投入，争夺定义下一代用户“入口”的主导权，并且这场竞争已不再局限于浏览器界面本身，而是深入到了工作流整合、智能决策支持与深度生态集成等多个层面。

在此趋势下，所谓的AI浏览器与AI智能体（Agent）之间的界限正变得越来越模糊。

传统巨头的防守与进化

对于已经占据入口优势的巨头，他们正致力于将既有优势发挥到极致：

1. 微软：将Copilot深度植入Windows操作系统内核，实现系统级的智能体调用与协同。
2. 谷歌：通过Gemini模型重构Chrome浏览器，使搜索结果能够直接呈现动态生成的3D模型演示等富媒体内容。
3. 苹果：将Siri升级为具备前瞻能力的主动式智能体（Proactive Agent），可跨设备预测并响应用户的行为轨迹。

新兴势力的冲击与创新

与此同时，众多新兴力量也在不断冲击这一领域：

1. Dia浏览器：通过实时屏幕语义分析技术，能够在用户点击之前就预加载其可能需要的相关信息。
2. Manus智能体：首创“认知沙盒”技术，支持并行运行多个智能体以协作处理复杂任务。
3. Nova Act SDK：提供跨平台的智能体运行时环境，旨在打破浏览器与本地应用程序之间的界限。

以上诸多领域是传统SEO无法有效触及的，但必然是未来GEO需要重点关注和布局的板块。从这个意义上说，GEO所能覆盖的流量场景和范围实际上已大幅扩展。

当前 AI 应用开发领域框架与平台层出不穷，为具体项目选择合适的技术栈成为一项颇具挑战性的决策。近年来，LangChain 凭借其 “低代码”理念与多模型兼容性 备受开发者青睐。这一开源框架提供了丰富的预构建模块化组件和统一 API，宣称仅需约十行代码即可部署一个功能性的智能体（Agent）。

近期，LangChain 成功完成了 1.25 亿美元的 B 轮融资，估值达到 12.5 亿美元，这背后折射出其核心技术价值——显著降低了开发者构建复杂 AI 应用的门槛与难度。当然，市场并不仅有 LangChain，诸如 n8n、Dify、Coze 等自动化或低代码平台同样能胜任 AI 项目开发，且各自拥有不同的侧重点与优势。

本文旨在系统梳理这几类主流方案的核心特点与典型适用场景，为技术负责人（CTO）及开发团队在不同业务需求下做出明智的选型提供清晰的参考依据。

LangChain 的发展历程与生态位

在 LangChain 出现之前，市场上已有不少探索性的 AI 框架，例如早期的 AutoGPT 和 BabyAGI。这些项目颇具创新精神：AutoGPT 尝试通过循环调用 GPT-4 来自主完成任务，BabyAGI 则引入了任务管理与记忆模块。然而，这些早期框架往往功能相对单一，可定制性较弱，难以满足企业级复杂生产环境的需求。正是在此背景下，LangChain 应运而生，逐渐成长为构建多步骤、基于大语言模型（LLM）应用的通用开发平台。

LangChain 的核心思想是将模型调用、提示工程、工具使用、记忆存储等能力抽象为标准化模块。它提供了构建链（Chains）、智能体（Agents）和检索器的组件，并支持与各类外部工具、API 及数据库轻松集成。开发者可以像搭积木一样，快速组合这些模块来编排复杂的 AI 工作流程。

其发展历程有几个关键节点：2024 年发布的主要版本进行了彻底重构，提供了更为简洁直观的 API，并推出了用于调试与监控的 LangSmith 平台，此时其生态领先优势已初步确立。进入 2025 年，面对传统 RAG 技术在处理复杂记忆与推理上的局限，LangChain 在 2.0 版本中以 LangGraph 图工作流引擎为核心，支持更复杂的多智能体协同编排与高级优化工具。目前，LangChain 在开发者社区中地位稳固，其潜在的强劲对手或许是背靠庞大生态的微软 Agent Framework，但这并不影响其在开源社区中的广泛采用与影响力。

接下来，我们将聚焦于两类最常见的 AI 应用场景：自动化工作流与智能知识库，来分析各框架的适配性。

自动化工作流场景剖析

当前，基于 AI 的自动化工作流普遍遵循 “思考（Think）→ 行动（Act）→ 观察（Observe）” 的循环范式。在每一步中，大模型根据预设的业务逻辑与当前状态，决策下一步要执行的操作，系统随即调用相应工具完成该动作。

摘要：解读“早期经验”新范式

智能体研究的一个长期愿景，是希望其能够通过自身积累的经验进行持续学习与优化，最终在复杂的现实任务中达到乃至超越人类水平。

然而，在当前许多实际场景中，单纯依靠强化学习从交互经验中进行训练依然面临巨大挑战：要么环境缺乏清晰、可量化的奖励信号（例如操作一个网站界面），要么完成任务需要经历冗长且低效的多轮交互（例如复杂的多步骤工具调用）。

正因如此，现有绝大多数智能体系统仍然依赖于基于人类专家示范的监督微调（SFT）。这种模式的扩展性有限，且泛化能力往往不足。其根本局限在于，专家数据通常只覆盖了特定、有限的情境，导致智能体所接触的环境多样性和决策边界非常狭窄。

为了突破这一瓶颈，Meta的研究团队提出了一种名为 “早期经验” 的新训练范式。其核心思想是：让智能体在环境中自主行动，收集由自身行为所产生的一系列状态转移数据。即便在没有外部奖励信号的情况下，将这些行动所导致的“未来状态”本身作为监督信号。

基于这一范式，论文探讨了两种利用此类数据的学习策略：

1. 隐式世界建模：利用大量交互收集到的状态序列，让智能体策略“扎根”于对环境动态变化的理解中；
2. 自我反思：引导智能体从其自身的次优决策中学习，通过对比行动与结果来改进内部的推理与决策过程。

初步实验表明，这一设想得到了验证。下文将分享笔者对这项研究的一些个人见解。

深度探讨：AI“自成长”路径的现实挑战

这里存在一个关键的视角差异。我们目前业界主流讨论的Agent（如一些应用框架），更多被归类于应用层赛道。因此，其核心目标通常不直接关注底层模型的进步。

例如，开发一个Agent应用时，开发者可能会灵活选用不同的底层模型，关注的重点在于自身的数据工程、业务流程整合与系统架构设计，以实现应用层面的功能进步。

然而，从这篇论文的内容来看，其关注点显然落在了模型本身的能力进化上。因此，其方法论必然围绕着“训练”展开。单从摘要表述的目标来看，这篇论文探讨的路径或许就存在根本性的争议。当然，鉴于它出自Meta这样的顶尖机构，我们仍需保持审慎的尊重。

实际上，渴望让模型实现自我进化的人不在少数。例如，另一篇题为《Self-Adapting Language Models》的论文就提出了类似构想。

自我指涉的循环困境

SEAL方法试图让大语言模型“自己教自己如何微调”：模型首先生成“自我编辑”指令，其中包含合成的微调数据以及对训练指令和超参数的自然语言描述；接着，模型依据这些指令执行一次轻量的梯度更新。

然后，使用可验证的下游任务表现作为奖励，通过循环训练来优化模型生成“自我编辑”指令的策略。在无需上下文知识注入和少样本抽象推理两类任务中，SEAL方法显著超越了常规基线，且不需要额外的适配器网络或外部的“教练”模型。

这个方案构思巧妙，而学界对其的评价也极为犀利：这难道不是让模型“用一个幻觉去解释另一个幻觉”，从而导致其幻觉越来越严重？

这是一个相当大胆的策略，但笔者认为其可行性较低，主要基于以下几点考量：

存在的核心问题

首先，论文中依赖 “可验证的指标” 来筛选有效的“自我编辑”指令。

但在真实的业务场景中，究竟什么才算“可验证”？ 如果使用离线的准确率、一致性等代理指标，模型很容易学会通过“技巧性优化”来提升这些指标，从而蒙蔽评估系统，而非真正提升泛化能力。

其次，让模型为自己编纂训练教材，短期内或许能带来某些指标上的提升，但长远看必然会固化并放大其已有的幻觉和偏见，导致模型内部表示与真实世界的数据分布产生系统性偏离。在医疗、法律等高风险领域，这种偏离是绝对无法被接受的。

最后，还存在诸多工程技术层面的现实困难。毕竟，当前微调技术本身尚未成熟到能够完全自动化、鲁棒地处理这种复杂循环的程度。

从这个角度重新审视Meta的论文，我们不禁要问：这类“早期经验”技术究竟试图解决什么根本性问题？

“早期经验”范式旨在破解何种困局？

答案可归纳为两点：奖励信号的不可验证性与高质量专家数据的稀缺性。

奖励稀缺/难以定义：众多真实世界环境（如网页图形界面、企业内部的复杂信息系统）难以为智能体的每一步操作提供即时、可靠的奖励信号。或者，完成一项任务需要经历非常长的行动序列才能知道最终成败，这使得传统强化学习的训练效率极低。

专家数据扩展困难：监督微调严重依赖特定领域的专家标注数据。这类数据不仅获取成本高昂，且覆盖的场景往往有限，一旦环境发生细微变化（如网页布局更改、数据库表结构变动），原有的智能体就可能完全失效，几乎需要从头开始收集数据。

“早期经验”范式的解决思路则非常清晰，其核心理念近乎于 “放任模型在模拟中试错” 。让模型先行“踩坑”，大量采集由其自身行动所引发的环境状态演化轨迹，并将这些“未来状态”的序列作为监督信号。通过这种方式，模型能够学习到环境的基本动力学规律与行动后果，在此基础上再进行监督微调或强化学习，效率会更高。

注：典型的数据飞轮策略，是由AI系统日常审核所有的AI调用记录，然后由人类专家进行校验和补充数据。而“早期经验”的思路则更加激进，它近乎完全依赖于模型自身的判断来生成训练数据。

因此，该论文的重点，即在于阐述上述两条核心策略——如何围绕 “用状态演化替代外部奖励” 这一中心思想展开：

一、隐式世界建模：通过海量无目标导向的交互，收集丰富的状态转移数据，让智能体的策略“锚定”在环境的变化规律上，从而使其理解“世界是如何运转的”，而非仅仅记忆答案模板。

二、自我反思：让智能体对其产生的次优决策进行复盘与对比学习（行动→导致的结果→反思），在没有外部专家点评的情况下，自主改进其内部的推理链条与决策边界。

总而言之，这套方法论可以概括为：先让智能体（孩子）在环境中自行探索、试错、从摔倒中学习（状态演化即反馈），然后在此基础上聘请教练进行动作微调（SFT）。如果未来环境能提供明确的量化评分（奖励信号），再进入更专业的强化训练（RL）阶段进行精修。至于探索过程中产生的无效或错误轨迹，在资源允许的情况下可以被视为必要的学习成本。这至少是笔者对论文思路的一种解读。

结论与展望

“早期经验”范式希望通过上述策略，帮助我们在缺乏奖励信号、决策链路漫长、专家数据稀缺的现实困境中，重新理解“反馈”的本质，并尝试构建一个能够自我积累、自我改进的学习框架。

只不过，这套方法论主要作用于模型层面的训练与进化，而非应用层的快速构建，这在一定程度上超出了大多数应用开发者的直接关切。因此，今天我们主要将其视为一种前沿学术思想的了解与学习，暂不深入探讨其实践落地的细节。

让我们跳出单篇论文的技术细节。当前，大模型的发展整体确实遭遇了显著的瓶颈，Meta提出的“早期经验”范式，可视为针对 “数据枯竭” 这一核心难题的一次大胆探索。

当互联网上的高质量公开语料即将耗尽，而专业领域的专家数据成本又居高不下时，这一范式试图为模型开辟一条通过自身与环境交互来获取训练数据的新路径——尽管这个过程的效率与可靠性仍存疑，其内在逻辑甚至引发了一些关于“自我指涉”的联想。

然而，这项技术突围也凸显了AI发展中的根本性矛盾。首先，“早期经验”要求智能体通过海量试错来积累经验，这与训练当今大模型所耗费的数千万美元级算力成本形成了尖锐的经济现实冲突。

更为关键的是，该方法与模型的安全对齐问题产生了深刻摩擦：在缺乏可靠外部反馈机制下的“自我反思”，可能引导模型优化出一套“看起来正确”但实则蕴含未知风险的行为模式，这就像修复软件代码时，不慎引入了更隐蔽、更危险的安全漏洞。

综观近期诸多研究，一个共同的深层焦虑逐渐浮现：AI，特别是大模型的发展，正遭遇系统性瓶颈，尤其是在数据层面。任何单一的技术突破都难以撼动由数据、算力、安全构成的复杂约束体系。

“早期经验”指明了通过环境交互自动获取数据这一颇具价值的方向。然而，要真正实现它，必须在数据工程的可行性、庞大的算力经济成本以及严峻的安全对齐挑战之间，取得极其艰难的平衡。

这也从另一个侧面解释了，为何像OpenAI这样的行业领导者会将更多资源转向构建应用生态：通过真实、可控的应用场景，以更经济、更安全的方式持续收集高质量的人类反馈数据，或许是当前突破困境更为务实的一条路径。

对于经常阅读电子书的朋友来说，Z-Library 的大名想必并不陌生。它以其海量的资源库著称，但同时也设置了较高的访问门槛，这对大多数普通用户来说并不友好。

今天要为大家介绍的这款工具则截然不同。你只需要拥有一台安装 Windows 系统的电脑和网络连接，即可直接使用。它完全开源免费，没有任何广告或付费机制，甚至无需注册就能直接搜索并下载心仪的书籍。这款宝藏工具就是 Olib 开源图书。

Olib 开源图书的资源数据库同样源自 Z-Library，但它提供了直接的访问通道，没有任何使用限制。其搜索功能尤为强大，支持通过关键词、作者姓名、书籍标题等多种方式进行检索。搜索结果页面会清晰地展示书籍的出版年份、作者、文件大小以及格式等关键信息。

工具内置了智能去重引擎，能够自动识别并过滤重复的资源。此外，它还支持上百种语言，即便是一些相对小众的语种也包含在内。用户切换语言后，即可轻松检索和下载相应外语的电子书。下载书籍时，你可以自由选择存储路径，文件管理起来十分便捷。

Olib 支持同时下载多个文件，并利用多线程技术进行加速。虽然下载速度可能无法完全跑满宽带极限，但相比那些需要登录、非会员就严重限速的各类网盘，其体验无疑要方便和畅快得多。在格式支持方面，它提供了 EPUB、PDF、MOBI 等主流电子书格式，用户可以根据自己的阅读设备或习惯按需选择。

总而言之，无论是用于个人休闲阅读、学术研究，还是寻找漫画、文献、期刊杂志、小说等资源，Olib 开源图书都能很好地满足需求。这样一款功能全面、使用便捷的电子书下载工具，值得你将其收藏起来。

国内人工智能领域的竞争态势已广为人知，例如飞书今日举办发布会，钉钉明日便可能紧随其后推出类似功能。然而，国际市场的角逐更为白热化。首当其冲的是谷歌，其基座模型Gemini结合图像视频套件（如Nano Banana、Veo3）展示了令人瞩目的技术突破。

与此同时，Meta也充分享受到人工智能发展带来的巨大红利：

然而，自DeepSeek开源以来，Llama在开源领域的领先地位变得不再稳固，甚至后续还曝出数据造假的丑闻。

为突破技术瓶颈，Meta几乎紧盯着OpenAI进行人才挖角：今年六月，Meta宣布组建超级智能实验室（Superintelligence Labs），计划投入数十亿美元资金吸引顶尖研究人员。该实验室旨在组建一支规模精干但人才密度极高的团队。

综上所述，无论是谷歌的强势技术反超，还是Meta的高薪挖角策略，亦或是国内DeepSeek、QWen等公司的迅猛追赶，都让昔日的AI霸主感到压力重重。因此，OpenAI开始连续升级模型，但近期推出的GPT-5并未带来预期中的惊艳表现。

眼见基座模型难以拉开显著差距，OpenAI不再掩饰其战略转向，开始全力聚焦应用侧创新。于是在10月7日凌晨，OpenAI年度发布会OpenAI Dev Day 2025正式开幕。整体而言，个人认为可用**“缺乏突破性进展”**来形容此次发布会。

按照山姆·奥特曼的阐述，本次发布会的核心在于如何帮助人们更高效地利用AI进行创造：

1. App inside ChatGPT：采用“应用商店”模式，吸引大量开发者入驻平台；
2. Agent Kit：可类比为字节跳动体系的Coze全家桶式开发工具；
3. Codex 正式版：为追赶Claude Code而推出的编程助手；
4. 多模态能力：发布了gpt-image-1-mini（图像处理模型）、GPT-5 Pro、Sora、Real-Time Mini等API接口。

可以看出，当基座模型竞争陷入僵局时，OpenAI开始转向更易实现的领域，例如通过功能组合打造应用生态。实际上，上述所有功能要素或多或少都已出现在市场上，且没有哪一项是OpenAI具备绝对优势的。OpenAI此次更像是一位优秀的技术路线整合者，系统性地展示了其应用生态蓝图。