该文章由一位资深前端开发者撰写，回顾了 AI 从 AlphaGo 到 ChatGPT 的爆发历程。作者结合自身成功将 ChatGPT 套壳为桌面应用（获得 54k+ Stars）的实践经验，深刻洞察并分享了对 AI 发展趋势的思考。文章首先批判了当前“AI 泛滥”现象中存在的利用信息差和贩卖焦虑的行为。随后，作者将 AI 形态分为模型和使用两部分，重点分析了 AI 应用从网页到桌面应用、CLI 工具，直至 AI 浏览器的演进，指出其核心趋势是“深度集成，弱化权限边界”。在技术实现层面，作者详细比较了 Electron 与 Chromium 二次开发在构建 AI 浏览器时的优劣，并提出未来需要一套“为 AI 量身定制的浏览器 API 层”。最后，文章针对信息过载时代如何有效学习给出了建议，强调问题驱动、靠近一手信息源和主动输出的重要性。

---

文章很长，大致分为背景、“AI” 泛滥、AI 形态 & 技术实现（重点阅读此部分，它才是这篇文章最想写的东西）、如何学习等部分，大家可以先挑拣自己喜欢的部分阅读。当然我还是更建议大家顺序阅读，因为它是层层递进的关系。我已经很久没有写过大跨度的思考类文章了，要是录成视频，感觉两小时也说不完，文字我已在尽最大可能压缩。

背景

AI 发展几度沉浮，太久远的不提，说点近的，比如 AlphaGo^[1] 在围棋领域因击败人类世界冠军，而震惊世界（从盲目自信到一败涂地，人们才逐渐开始正视那个被人创造出来的玩意）。但之后似乎又回归平淡，没啥动静了。

柯洁这段视频蛮有意思，对 AI 的态度也是 180 度大转弯。只能说，曾经年少轻狂，大意了...

📌 AlphaGo

是 Google DeepMind 开发的围棋 AI 程序，基于深度神经网络和蒙特卡洛树搜索（MCTS），通过学习大量人类棋谱并自我对弈训练而成。它在 2015 年以 5:0 战胜欧洲冠军樊麾，2016 年在首尔以 4:1 击败世界冠军李世石，引发全球关注；随后以 “Master” 账号在网络上对世界顶尖棋手取得 60 连胜，并在 2017 年乌镇峰会上以 3:0 战胜当时被认为世界最强的柯洁。AlphaGo 的这些代表性战绩，标志着人工智能在复杂博弈领域第一次全面超越人类顶尖高手，也被视为现代深度学习时代的重要里程碑之一。

直到 2022 年 11 月 30 日， ChatGPT^[2] 的出现打破了平静，让 AI 这把火一直燃烧到现在，而且没有要熄灭的迹象。11 月 30 日是官方正式发布日期，其实在这之前 GPT 已经在社区开始流传了（到今天也是刚过 3 周年，我写这篇文章似乎又有了特别的意义）。

我第一次接触到它，是在微信朋友圈（技术圈子还是好使，更容易接触到前沿信息）。开始的几天常被它刷屏，自以为又是噱头，主要是国内一惊一乍的表达方式让人有后遗症了。最终在好奇心的驱使下，我尝试点开了它。这才发现“不简单”，国内既无法访问，又无法注册（需要海外手机验证码）。当时真没少折腾，在搞定注册后，我甚至专门写了篇《ChatGPT 注册教程》，万万没想到这会成为我开始接触 AI、学习 AI、表达 AI 的起点，这一天是 12 月 5 号（我只是一名普通前端开发，对 AI 更是一窍不通）。 2 天后，也就是 12 月 7 号下午，我决定用正在探索学习的 Tauri^[3] 技术（基于 Rust^[4] + 系统 Webview 实现的跨平台开发框架），为 ChatGPT 开发一个套壳桌面应用（期间发生了很多趣事，对此故事线感兴趣的朋友可以细看“技术背景”部分，其中微信截图我最大限度保留了当时对话的核心上下文，也算是记录一个顶级开源项目的诞生吧）。

关于项目，我写过两篇文章，建议大家去读读，都是些掏心窝子的经验：

• 流量密码：ChatGPT 开源的一些思考（如何快速将产品落地）
• 开源揭秘：35k+ Stars ChatGPT 桌面应用（深度技术揭秘）

其中一些话，我特别想再次分享出来：

• 技术是死的，而人是活的。技术要想产生价值必须要依附于所能解决的问题。发散式思维：在了解一个新技术或事物后，一定要去了解它的生态和周边，这些生态都将是你灵感和开发的源泉。
• 做一件事情时，身边必然会出现不和谐声音，但他们的观点并不可以左右你的行动。就个人而言，我不喜欢被束缚，因为提 PR 就意味着你必须按照别人的想法去做，事情会变得不可控（通过/拒绝）。我创建项目的初衷并不是为了服务于人（也没想着会火），主要是为验证自己的一些想法。迈出第一步，你将拥有无限可能。遇到问题解决问题，一个问题会衍生出一个新问题，这些实战会让你迅速成长。
• 在我看来价值是一个很抽象的东西，但人们往往又喜欢用结果去衡量一个东西的价值（比如有多少用户，赚了多少钱等等）。举一个简单的例子：我经常混迹在 GitHub 社区，也看到过许多很牛的项目，是它们撑起了海量的上层应用，但是它们的关注度却不高，你觉得它们有价值吗？也有许多博眼球项目，含金量不高，却获得了巨大的关注度，你觉得它们价值高吗？在这个以结果为导向的世界里，不管做什么事情，都避免不了被问到：“你做这个东西有什么价值？”。
• 当你有了比较心，得失心，在做一件事情时就会变得畏手畏脚，甚至不屑去做。想的多不是坏事，当你在试图最大化利益时，往往也会丢掉许多可能性。人们常说的机遇是什么？我认为它就是：一个人在积累知识，学习技能的同时，善于用发展的眼光去观察这个快速变化的世界，当你有能力去解决某个问题时，它对你来说就是一次机遇。

“AI” 泛滥

这里的 AI 我特别打了个引号，此 AI 非彼 AI。两年半前我在《AI 浪潮下的一些浅思》中就提过，它特指一类现象。比如：

• 做第三方服务：卖账号，代充值，做镜像站点，小程序机器人等。
• 纯利用信息差：打着自研旗号，售卖各种开源工具，框架等。
• 贩卖人性焦虑：利用盲从心理贩卖焦虑，创建各种付费群，星球等知识付费平台。
• 利用工具收割：AI 技巧速成，利用 AI 赚钱的教程也比比皆是。

总结一下：其目的基本一致，利用信息差，贩卖人性焦虑。以此来营造一种“在 AI 来临的时代，你再不学 AI，就要被淘汰了。AI 将取代大部分打工人，现在你只需要花费很少的钱，就可以领先所有人一大步”。但是事实真的如此吗？三年过去了，AI 仍在快速发展，但远未达到取代人的地步，尤其是高精度工作，可靠性仍需人来保证。

当然，最疯狂的还要数自媒体，两天一小嗨，三天一大嗨，读者几乎每天都在震惊中度过。最可笑的是，昨天文章还在夸 xxx 牛逼，结果今天就发打脸文（看似打脸，实则没有一点不好意思，毕竟流量真香）。

信息泛滥成灾，尤其是在 AI 的加持下，产垃圾速度也是呈指数上升趋势（图中元素关系不准确，但大概意思没错）。

在国内聊 AI，出海似乎是绕不开的话题。人人都在搞 AI 创业出海，总让人产生应用比人多的错觉，这里就不做评价了。可以聊聊我看到的一些红海现象，出现一个不错的 idea，就会被无数次翻版复刻。产品数量要远大于想法，不知是人的锅，还是 AI 的锅，毕竟大家都在 vibe coding。在 AI 的加持下，技术小白也开始指点江山（如果 AI 是人，不知道会不会在心里骂上两句）。

📌 Vibe Coding

技术和 AI 的关系是相辅相成的，如果纯小白不想学编程，只想用 AI 解决问题，在我看来有点痴人说梦，不现实。如果自己都不知道边界，又怎么能设计出有边界的产品（边界是指技术的边界，知道技术边界在哪里，才能设计出最大化利用边界能力的系统）。

在编程中，盲人摸象是有点可怕的。vibe coding 可以帮你快速出一版 demo，但很难持续迭代。在开发某个功能时，如果自己都不知问题所在，是很难将它描述给 AI 的（中间会产生无数沟通成本）。比如下面这个例子，虚拟滚动几乎是大数据量渲染的必备技能，没有此方面经验，你会在门外久久徘徊。说它是大坑一点也不夸张，元素动态高度会牵扯到布局位置计算，ai coding 很难一次完美实现，基本都需人工介入。即使让 ai 用一些 lib，遇到麻烦配置，也是一堆问题。

想法被翻版是其次，冲击最大的仍是大模型自我迭代。我一直就有的想法，不能做大模型战略发展规划上的事。比如 PDF 总结，翻译，随着基础模型能力的提升，会让一切技术优化手段都失效（甚至整个需求都将消失）。Prompt 工程、LLM 微调既重要又不那么重要（有时间窗口，在某个时间内，需要帮大模型补齐短板）。真要建议，我认为可以根据大模型能力做差异化：大模型能力的延伸（如本地知识库），构建 ai 补充生态位（连接第三方，属于脏活累活，比如 n8n），更符合 ai 交互的产品（ai 的本质还是服务于人，交互体验会直接决定用户的去留）...

前段时间我也写过《浅谈产品、流量、编程...》，其中就涉及到项目冷启动、流量、产品、打榜的一些看法，也可以读读。最让我佩服的还是国人的 PH 打榜能力，和多年前的淘宝刷单如出一辙（穷人靠变异，富人靠科技）。

AI 形态

AI 用一句话来说，就是将电力 + 算力转化为智力的过程。理论上，算力、电力无限，就可以源源不断产出智力（从能量利用效率上说，肯定不如人，但胜在可批量生产，不知疲倦，7x24 小时工作）。

AI 形态是一个很大的话题，我们可以展开细聊。我自己把它分为模型和使用两部分：

• 模型形态：多模态，如文字、图像、音频、视频生成等。
• 使用形态：网页、应用、命令行、浏览器、机器人等。

模型形态

模型多模态能力，这几年一直在稳步提升，没啥特别要强调的。值得一提：尽管它在整体感知、常识和长期一致性上与人类还有明显差距，但这并不妨碍它在一些特定场景里“替代人完成工作”，尤其是高危和高度标准化的重复性任务。

• 高危行业：在高危场景中由 AI/自动化系统替代人类，本身就具有极高价值——哪怕部署和运维成本暂时高于人力，也依然划算。
• 流水线行业：凡是能被拆解为标准化流程的岗位，本质上就是机械性重复，是最容易被 AI + 自动化改造的部分；流程越容易被量化成“AI 操作手册”，越适合被替代。反过来说，越难量化的领域越难被 AI 完全取代。
• 创意类行业：这一块边界很模糊。AI 拥有接近「世界级资料库」，但如何选择、组织和编排内容，目前还不存在一条确定、可控的路径（尤其在主流 Transformer 架构下，“幻觉”问题仍然难以根除）。这种不确定性让“快速生成大量创意”变得容易，却也让“稳定地产出高度精确、可控的结果”变得异常困难。
• ...

使用形态

如果让你设计一个东西来承载 ai 的能力，你认为最理想的容器是什么？问题可能有点宽泛，我们可以限制在电脑、或者手机上（暂不讨论机器人）。在正式回答这个问题前，我们先列几个事件节点：

• 网页 Chat：AI 早期形态，大部分 AI 都以此形态和大模型交互（文本交互为主，Prompt 工程出现）。
• 应用 Chat：与网页版没有太大区别，甚至功能不如网页版丰富，但它提供网页所不具备的一些能力（如系统权限）。
• 大模型上下文协议 MCP：这是 AI 能力的一个重要分水岭，它通过规范化协议来教会模型如何使用工具，拓展自身能力，大大降低了 Agent 开发门槛（了解更多 深度解析：Anthropic MCP 协议、浅谈 Agent、MCP、OpenAI Responses API）。
• Code CLI：如果说 MCP 为 AI 能力插上了翅膀，那程序员就是将 MCP 进一步发扬光大的重要群体。虽然没有明确证据，但程序员绝对是最先将 MCP 应用于开发工作流的群体（坊间甚至流传这样一句话：MCP 开发者比用户还多）。
• AI 浏览器：Agent 能力集大成者，在此之前，还有各种 AI 工作流（如 n8n、dify 等）。核心是 AI 能力，而非浏览器本身，它只是 Agent 的一个载体罢了。
• ...

AI 还有很多重大事件，但以上几个标志性节点已经可以帮我们梳理出这样一个趋势：深度集成，弱化权限边界。

📌 说人话

从使用形态来看，AI 这几年经历了一个看似分散、实则有迹可循的演化过程：从网页 Chat，到桌面 / 移动 App，再到 CLI、MCP 协议和 AI 浏览器。表面上只是壳子不同，背后其实是一条清晰的趋势：多模态输入输出 + 更深的系统集成 + 更弱（更细粒度）的权限边界。

早期的网页 Chat 是主流入口，大部分面向普通用户的生成式 AI 产品都以网页对话为核心形态，交互以文本为主，Prompt 工程也在这个阶段成型。随后出现的应用 Chat 在交互上与网页差别不大，但开始拿到通知、文件访问、剪贴板等系统能力，为后续更深的集成打基础。

大模型上下文协议（MCP） 则是能力结构上的分水岭：通过一套规范，把“工具使用”和“外部系统”纳入模型可见的上下文，让 AI 不再局限于对话，而是可以通过统一协议调用各种工具，极大降低了 Agent 开发的门槛。

在此之上，Code CLI 成为开发者最自然的承载形态之一（代表有 Codex^[7]、ClaudeCode^[8]、GeminiCLI^[9] 等）：MCP + 命令行，使得模型可以直接嵌入到本地开发 / 运维工作流，包括文件操作、构建、测试和部署等。与之相对，AI 浏览器（代表有 Dia^[10]、Atlas^[11]、Comet^[12] 等）更像是面向终端用户的 “Agent 总控台”：它本身不是重点，重点是通过浏览器这个入口把网页内容、Web 应用和多模态能力都接给 Agent 使用。

把这些节点连起来看，会发现一条清晰的趋势：随着多模态的成熟，AI 不再满足于停留在单一网页对话，而是不断向操作系统和应用层延伸，借助 MCP、CLI 和浏览器等不同容器，逐步实现对工具、数据和权限边界的更深集成。CLI 和浏览器的区别在于：前者主要服务开发者和自动化脚本，后者则成为普通用户跨网站、跨应用使用 Agent 的统一入口。

📌 CLI vs 浏览器

CLI 是“机器给机器看”的界面，浏览器是“机器给人看”的界面。前者服务的是 AI 执行回路，后者服务的是人类的感知与决策。

所以在我看来，CLI 和浏览器的出现都是必然，它们服务的“终端用户”有明显不同：CLI 更像是 AI 的工作现场，浏览器则是人类的观察与干预界面。

对 AI 来说，完成自动化任务并不需要窗口、按钮或图标，一条稳定的文本流就足够支撑它思考、调用工具、产出结果。命令行正好符合这种“纯符号”工作方式：协议清晰、可脚本化、易于编排，是最接近 AI 内在形态的外部壳。只要任务是端到端自动完成的，CLI 几乎不需要顾及任何人类交互体验。

一旦把人拉入环路，事情立马复杂起来。人类需要结构化排版来阅读，需要图像、视频、音频来理解，需要拖拽、点击、表单来参与决策。浏览器刚好站在这个交叉点上：它天生支持多模态展示，又能向操作系统借用文件读写、摄像头、麦克风等能力，于是成了人类与 Agent 共处一屏的默认容器。

所以，CLI 的回归不是开历史倒车，而是 AI 时代的一种“底层复位”：在那块黑底终端里，唯一的用户是程序本身，自由度最高；而对绝大多数普通用户而言，没有浏览器这样的可视化中介，AI 的能力既难以被理解，也难以被信任。当任务都可以无人值守地闭环执行时，人类不再需要频繁“看一眼”，或许 CLI 才可能成为唯一界面吧。

技术实现

我不是 AI 专业，所以在大模型的问题上，没啥发言权。但 Ilya 有，刚好前几天还写过一篇关于他的播客《Ilya Sutskever：AI 研究、泛化与未来之路》，事后一些观点被人错误解读，在科技圈引起巨大关注，让 Ilya 被迫下场澄清（在我看来，他的观点本身没啥问题，或许是扛不住资本舆论的压力吧，毕竟 AI 泡沫不能就这样破了）。

大模型技术不能聊，还是可以聊点我知道的东西。我这两年一直在开发 Noi（AI 浏览器），所以对 AI 应用层面上的思考更多一些。如果你正在开发类似产品，这些经验或许会让你少走些弯路。

框架选型

AI 浏览器是近半年最卷赛道之一，前有 Dia，后有 Comet、Atlas 等，还有一些国内公司也在做。但在我看来仍是千篇一律，前段时间在《ChatGPT Atlas 发布，AI 浏览器大乱斗...》、《浅谈 AI 浏览器》里聊过。这次我想再深一点，从技术实现层面聊聊。

最近刚好有人咨询过我类似问题，团队想做 AI 浏览器，推荐什么技术选型。其实目前主流框架就两个（Electron^[13] 和 Chromium^[14]），认真来说，就一个 Chromium（Electron = Chromium + Node.js）。Tauri 之类的基于系统 webview 框架，在我看来，压根排不上号。

在选 Chromium 框架作为 AI 浏览器核心，也有两个选择，且十分重要：

• Electron：对技术要求相对较低（主要写 nodejs 代码），API 升级平滑，但定制化程度稍低（chromium 内核版本随着 electron 的升级而升级）。
• Chromium：在源码基础上二次开发（主要写 c++ 代码），相当于 fork 版本，之后源码的一系列更新（新特性、修 bug 都需要手动去 merge 代码），会让维护难度指数上升。属于走钢丝级别，任何一个小失误，都可能玩崩（无法构建、或跨平台不一致等）。

为啥说系统 webview 连上桌的机会都没有（tauri）？主要是跨平台一致性很难保证（当系统 webview 出现 bug 时，很难去 fix，只能等待系统升级，但用户很难买账），其次是难以复用 Chrome 插件体系（生态小了很多）。

📌 原生开发 vs 跨平台方案

“原生还是跨平台？”和 “vue 还是 react？”一样，是编程界永恒的引战话题。与其上来就站队，不如先承认一个现实：它们解决的问题不一样，适合的团队和阶段也不一样。

如果只看浏览器类应用，用 chromium 二开当然诱人：你能从内核层面定制一切——进程模型、渲染策略、权限边界、协议栈…，理论上可以打造一套“属于自己”的浏览器内核，性能上限和自由度都极高。但代价也写在招人 JD 里了：

• 要有懂浏览器架构、C++、多进程、多平台打包和安全沙箱的人；
• 能够排查解决各种性能问题、内存泄露等；
• ...

内核性能好 ≠ 你写的应用一定稳，原生只是把“造轮子”的底线拉得更低，工程质量好不好，仍然取决于团队。很多团队在做技术选型时，容易只盯着“技术纯度”和“理论性能”，忽略了其它成本：

• 招人难度和培训成本
• 需求变化带来的重构成本
• 各平台适配、发布、升级的运维成本

一个更接地气的例子：假设你要做一个“超大数据量渲染 + 富交互”的列表应用，如果用原生来写，你要从底层解决绘制性能、重排重绘、虚拟列表、缓存策略，甚至还要考虑音视频解码、渲染管线等一系列细节，多个平台还得各写一遍。而如果你用 web 技术栈：

• 浏览器本身就是一个“小型操作系统”，帮你封装好了文本布局、滚动、表单、音视频播放。
• V8^[15] / JSCore^[16] 这些引擎已经极其成熟，配合合理的架构和虚拟滚动，性能完全够用。
• web 生态自带整套轮子：虚拟列表、图表、富文本、音视频播放器…，你更多是在“选配件”，而不是“自己开矿炼钢”。

这也是为什么我们会看到一个非常有意思的现象：许多 AI 产品的网页版远比 App 版更强。深度用过的用户大概都有感觉：

• 网页端有插件、工作流、复杂可视化、实验性功能；
• App 端经常是一个“精简壳”，只保留对话和少量系统集成功能。

根本原因不是团队“偏爱 web”，而是原生把每一项复杂能力都变成一笔真实成本：

• 要重写 UI 组件和交互逻辑；
• 要重新处理多媒体、文件系统、沙箱权限；
• 要适配 macOS / Windows / Linux / iOS / Android 各自的坑。

对快速迭代的 AI 应用来说，这些成本往往直接让很多功能“在原生上根本来不及做”，所以没必要迷信 “原生 = 高级，跨平台 = 将就”。更现实的看法是：

• 原生适合极致性能、深度系统集成、安全要求极高的核心场景（比如视频编解码引擎、游戏内核、Driver 级工具）。
• Web / 跨平台适合需要快速试错、频繁更新、依赖生态组件的产品形态（尤其是 AI 应用、工具类产品、面向多平台的创作工具）。
• 很多成熟产品的长期形态，往往是：“整体跨平台 + 关键路径原生化”，而不是一开始就全盘原生。

技术栈只是载体，作为软件构建者，我们更应思考的是：在你的团队规模、产品阶段和资源约束下，哪种方案能 以更低成本、更快速度，把“电力 + 算力”尽快变成对用户可见的“智力体验”。这才是选型时应该反复追问的本质问题。

产品形态

大模型公司去卷“浏览器形态”，几乎是必然。因为从产品视角看，浏览器就是当下 Agent 能力最合适的载体。早期我们只能在网页里做一点半自动的 Agent 功能，或者靠插件去勉强扩展；一旦牵扯到系统权限、跨页面操作、长流程任务，这套东西立刻就捉襟见肘。

把 Agent 拆开看，并不神秘，本质是：“感知页面 → 做出决策 → 驱动浏览器自动操作”。滚动页面、点击按钮、填写表单，这些动作本身和 AI 一点关系都没有——没有大模型，你照样可以写脚本、写 RPA 去完成。AI 真正带来的增量在于：谁来决定下一步做什么——是点 A 还是点 B？是继续翻页还是去搜索框改一下关键词？这部分从“写死的脚本逻辑”升级为“概率化、上下文相关的智能决策”，准确率和泛化能力才真正拉开差距。

📌 RPA

RPA 就是 用软件机器人去替人干重复的电脑操作。全称 Robotic Process Automation，直译为“机器人流程自动化”，但这里的“机器人”不是实体机器人，而是跑在电脑里的程序。它擅长：

• 盯着屏幕 / 窗口
• 模拟人点击、输入、复制粘贴
• 按设定好的流程，把“一遍一遍重复的活”自动做完

典型场景有：

• 每天从邮件里下载附件 → 重命名 → 丢到某个文件夹
• 从 ERP/CRM 里查数据、导出报表
• 在网页上填一堆表单、点来点去做业务流程

跟“脚本 + 宏”的区别是：

• RPA 更偏业务人员能配置的工具（流程图式可视化配置）；
• AI 不一定参与，很多 RPA 完全是“死规则 + 固定流程”。

往下一个阶段看，我认为真正缺的是：一套为 AI 量身定制的浏览器 API 层，而不是割裂的 AI 浏览器应用（太多了，根本装不完）。现在主流做法都是基于 CDP^[17]（Chrome DevTools Protocol），在浏览器底层暴露出点击、滚动、输入、截屏、获取 DOM 等能力，大部分所谓“AI 浏览器”其实都是在这层之上包了一层 Agent（大部分都在基于 playwright^[18]、puppeteer^[19] 实现）。理想状态下，这套 API 应该对“任意大模型”是统一的、高度抽象的：

• 上面一层是语义化的动作描述（如 “点击主内容区的第一个购买按钮”）；
• 下面一层是稳定、可观测、可回放的浏览器控制接口。

当这种 “AI 友好型浏览器 API” 成熟之后，浏览器不再只是跑网页的壳：

• 一个既对人类友好，又对大模型友好的“双栖运行环境”；
• 人和 Agent 可以在同一块屏幕上协同操控同一套界面，这才是浏览器形态真正有意思的地方（支持切换模型，而非切换浏览器）。

如何学习

这是一个信息过量、注意力稀缺的时代，终身学习似乎早已无法避免。面对 AI 生成式的信息洪流，我们又当如何？此方面，我也写过一些文章：

• AI 能否代替思考？
• 关于 AI 编程的一些浅思
• 关于 AI 时代的一些思考
• 致而立之年的自己

先要承认一个现实：知识是学不完的。你从 1+1 开始，后面还有加减乘除、代数、微积分、再往后还有无穷无尽的新概念。对大部分人来说，如果不做研究工作，加减乘除已经足以覆盖日常生活；但身在某个圈子里，很容易产生错觉——“这个也必须懂、那个也不能落下”。视野越局限，越容易把一切都当成“刚需”，随之而来的，就是持续的知识焦虑。

与此同时，我们被碎片化输入包围：短视频、信息流、标题党推送，让人连一篇几千字的文章都难以读完，更别说安静地思考、推理或输出了。没有信息会焦虑，信息太多同样让人焦虑。更隐蔽的问题在于，碎片化输入会制造一种“我好像一直在学习”的幻觉：你的大脑被刺激得很忙，但知识结构并没有真正长出来。

更健康的学习方式，是从恐惧驱动转向问题驱动——用到什么学什么，让“真实问题”来决定学习路径，而不是凭空给自己加一堆“应该会”的清单。一个更可靠的模式是：先遇到具体问题，再去追溯信息源，结合自己的已有知识和经验慢慢扩展，而不是为了缓解焦虑胡乱囤积概念。

信息的选择同样重要。尽量靠近一手信息源，关注长期深耕的领域大牛、官方文档、原始数据，而不是只吃被剪碎、被包装过的二手内容。二手信息往往带着延迟、偏差和噪音，信息差、智商税和弯路基本都长在这里。学习未知知识，更像是“扩展阅读 + 靠近源头 + 叠加已有认知 + 自己推演”的过程，而不是简单刷过几条短视频就算掌握。

“卷”本身是一把双刃剑。完全躺平、不学习，会被行业淘汰，这是现实；但一味用碎片化输入麻醉自己，只是换一种方式原地打转。更好的做法，是把内卷用在“思考和输出”上：保持持续输入，同时逼自己多写、多讲、多做 demo，在输出的过程中重组和校正自己的理解。真正的成长，往往不是“看了多少”，而是“你能说清楚多少，亲手做成多少”。

如果一定要给“如何学习”下一个极简公式，大概可以是：成长 ≈ 高标准要求自己 × 持续学习 × 主动思考 × 尽量多一点输出。学什么、学到什么程度，因人而异；不过度焦虑、不盲目贪多、不放弃思考，你将一直在路上！

📌 GEO vs SEO

这里举个 GEO 和 SEO 的例子，也是前几天被人问到。作为技术外行，很容易被 GEO 这类新词语所迷惑。SEO 大家都知道是针对搜索引擎优化技术（结构、内容、链接等），目的是让搜索引擎更好地收录并在结果页里把网站排前一点。而 GEO（Generative Engine Optimization）也类似，希望被大模型更好的收录，可以在回答问题时被作为信息源推荐。如果你有了解大模型爬虫原理，会发现一点也不神秘，本质上还是配置爬虫抓取规则，只不过是针对 AI 机器人罢了。

所以在 GEO 这个层面，和传统 SEO 没有本质断代：依然要用高质量、结构清晰的内容去打动“机器”，只是机器从“搜索引擎排序算法”升级成了“检索 + 大模型生成”。需要重视的部分是更偏 Agent / LLM 视角的页面优化，比如：更语义化的结构、更好的无障碍支持、更清晰的元素标记和动作入口，让模型更容易理解、定位和操作页面。这类实践我在《ChatGPT Atlas 发布，AI 浏览器大乱斗…》的拓展阅读里有讲，有兴趣可以结合一起看。

简言之：SEO 让你在搜索结果里被看见，GEO 让你在大模型回答里被引用。底层逻辑没变，只是“评审你的机器”和“使用你的场景”换了一代而已。

References

[1]

AlphaGo:https://deepmind.google/research/alphago

[2]

ChatGPT:https://openai.com/index/chatgpt

[3]

Tauri:https://tauri.app

[4]

Rust:https://rust-lang.org

[5]

webAssembly:https://webassembly.org

[6]

rsw-rs:https://github.com/rwasm/rsw-rs

[7]

Codex:https://github.com/openai/codex

[8]

ClaudeCode:https://github.com/anthropics/claude-code

[9]

GeminiCLI:https://github.com/google-gemini/gemini-cli

[10]

Dia:https://www.diabrowser.com

[11]

Atlas:https://chatgpt.com/atlas

[12]

Comet:https://comet.perplexity.ai

[13]

Electron:https://www.electronjs.org

[14]

Chromium:https://www.chromium.org

[15]

V8:https://v8.dev

[16]

JSCore:https://developer.apple.com/documentation/javascriptcore

[17]

CDP:https://chromedevtools.github.io/devtools-protocol

[18]

playwright:https://github.com/microsoft/playwright

[19]

puppeteer:https://github.com/puppeteer/puppeteer