李文业的思考笔记

当前阅读总时间是：19,648小时

风格参考：Malcolm Gladwell（《引爆点》《异类》作者）—— 场景开头，层层剥洋葱，用悬念驱动叙事，最后揭示反直觉的结论。

那扇门

斯德哥尔摩，2019年冬天。

一个18岁的年轻人站在一家电商公司的前台，手里夹着一个文件夹。他没有预约，没有名片，没有大学学历——事实上，他连高中都没读完。前台问他找谁，他说想见电商业务的负责人，或者CEO也行。

前台的表情可以想象。在瑞典的商业文化里，陌生人不打招呼就上门拜访，约等于在地铁上跟陌生人搭话——不违法，但非常不寻常。更何况这个人看起来明显还未成年。

但这个年轻人打开了文件夹。里面是一张A3大小的对比图：左边是这家公司网站目前的商品推荐结果，右边是他用自己训练的模型生成的推荐结果。两列截图并排，差异肉眼可见——右边的推荐更精准，商品关联性更高，像是真的读懂了用户在想什么。

负责人出来了。看完对比图，第一反应是震惊，第二个问题是”这个怎么上线”。

年轻人当场从口袋里掏出一段写好的脚本代码，打开对方网站的浏览器控制台，粘贴，执行。推荐结果实时替换，页面上还自动跑起了A/B测试模块，跟踪两套方案的转化率对比。负责人盯着屏幕看了十几秒，抬头说：”我们谈谈价格。”

这一切发生在第一次见面的前十五分钟里。

这个年轻人叫Gabriel Petersson。五年之后，他加入了OpenAI，成为Sora团队的研究工程师。

但在这个故事的起点，他只是一个辍学生，连”机器学习”三个字到底是什么意思都说不太清楚。

那通电话

要理解Gabriel后来做的一切，你需要先回到更早的一个时刻。

那是一个普通的周末下午。Gabriel还在瑞典读高中，编程经验约等于零。他的表兄打来电话，说自己有一个创业想法——做一个电商推荐系统，卖给瑞典的在线零售商。他需要Gabriel马上过来斯德哥尔摩帮忙。

Gabriel说，今晚有个派对。

表兄说，现在就来。

他买了下一班车票。之后再也没有回到学校。

用Gabriel自己的话说，辍学并不是什么深思熟虑的人生决策。没有深夜辗转的权衡利弊，没有跟父母长谈后含泪告别，也没有”我要走一条不同的路”这种宣言式的顿悟。它更像是被一个足够紧迫的机会推着走——走着走着，就回不去了。

到了斯德哥尔摩之后，他面对的第一个问题不是”怎么写代码”，而是”怎么把东西卖出去”。冷邮件没人回——一个没有公司背景、没有客户案例、甚至没有正式网站的两人团队，发出去的邮件大概率被当成垃圾邮件。电话打了也很难让人信任一个没有技术背景的18岁少年。你可以想象那个场景：电话接通，对方问”你们公司在哪？团队多大？有什么成功案例？”，他一个都答不上来。

于是他想到了上门推销，也就是你在开头读到的那个场景。

他后来承认，这种做法留下了很多技术债——为了快速获客，他们几乎不考虑代码的可维护性和系统的可扩展性。但这段经历的真正价值不在于技术，而在于一个心理上的翻转：当你必须对结果负责的时候，你学东西的速度会快到自己都不敢相信。

但这里有一个问题：一个看不懂Andrew Ng机器学习课程、以为自己”太笨了”的高中辍学生，到底是怎么学会训练推荐模型、写爬虫、做A/B测试的？

答案藏在一个大多数人忽略的地方。

那些很烂的游戏

在成为那个带着A3大图上门推销的人之前，Gabriel的技术学习史可以用一个词概括：挫败。

表兄最初教他Java，两个人一起写了个回合制小游戏。Gabriel在访谈里对那个游戏的评价是：”很烂。”后来他上Udemy学Python，跟着课程做了另一个游戏，评价同样是：”也很烂。”他还尝试过Andrew Ng在Coursera上的机器学习课程——那是全球最受欢迎的AI入门课之一——但完全看不懂。他说他当时以为问题出在自己身上，以为自己就是不够聪明。

如果故事在这里结束，它只是一个”有人尝试学编程没学会”的平凡故事，全世界每天都有无数人经历着同样的事。

有意思的是接下来发生的事。

Gabriel创业之后，面对真实的客户需求，他突然开始学会了那些以前怎么都学不会的东西。不是因为他变聪明了，也不是因为他找到了更好的教程。是因为环境变了——以前学编程是”我在看一个课程”，现在学编程是”如果我明天搞不定这个功能，客户就流失了”。

他说了一句让主持人沉默了好几秒的话：没有压力我几乎学不会东西。

这句话听起来像是在为懒惰辩护，但认知科学家可能不会这么看。

两条路

教育研究者通常把学习路径分成两种：bottom-up和top-down。

Bottom-up是学校的默认模式。先学线性代数，再学概率论，再学统计学习，再学神经网络，最后做一个项目。这像盖房子——先打地基，再砌墙，再封顶。结构完整，循序渐进。好处显而易见。

坏处也显而易见：你可能在打了两年地基之后，发现自己对这栋房子毫无兴趣。

Top-down是另一种路径：先接一个真实的任务——比如给客户做一个推荐系统——然后在做的过程中遇到不懂的地方，当场补。发现不懂推荐算法，去查。发现推荐算法里有矩阵运算，去学。发现矩阵运算需要线性代数的直觉，再去补。哪里漏水就修哪里。

Gabriel走的就是top-down。

问题是，为什么学校几乎不用这种方式教学？

答案很现实：top-down需要老师持续判断”这个学生此刻卡在哪里”、”下一步该给他补什么”——这等于给每个学生配一个全天候的私人导师。在一个四十人的班级里，这是不可能的。所以学校选择了bottom-up。不是因为它效果最好，而是因为它是唯一能规模化的方案。

这个困境在教育史上并不新鲜。1984年，教育心理学家Benjamin Bloom发表了一篇著名论文，发现接受一对一辅导的学生，表现能超过常规课堂教学中98%的学生。他把这个发现叫做”两个标准差问题”（2 sigma problem）——私人辅导比课堂教学好两个标准差，但你没有办法给每个学生都配一个私人导师。这个问题困扰了教育界四十年，没有人找到解决方案。

认知科学家John Sweller提出的”认知负荷理论”可以进一步解释两种路径的效率差异。人的工作记忆容量极其有限，一次能处理的独立信息块不超过四到七个。Bottom-up路径的一个隐性成本在于：当你学到第三层知识的时候，你已经记不清第一层为什么重要了，而且你完全不知道眼前这些知识将来会用在哪里。大量的认知资源被浪费在”维持意义感”上——你不停地问自己”我为什么要学这个”，这个问题本身就在消耗你有限的工作记忆。

Top-down路径则不存在这个问题。你始终有一个具体的、紧迫的目标——让系统跑起来，让客户满意，让bug消失——每一块新知识都自动嵌入了上下文，不需要你额外花精力去给它”找意义”。

但top-down有一个致命的前提条件：你需要一个能随时回答你问题的导师。四十年来，没有人能规模化地满足这个条件。

然后，ChatGPT出现了。

Bloom的”两个标准差问题”，在技术层面上，突然有了一个接近可行的解决方案。

递归

Gabriel在访谈里描述了他用AI学习的完整流程。

如果他想学机器学习，他会先问ChatGPT：我该做什么项目？让它帮忙设计一个项目计划。然后让它写出完整代码。代码一定会报错——这反而是好事，因为从修bug开始学，比从空白页面开始学要高效得多。他一步步把程序跑起来。能跑之后，盯着某个模块追问：这段在做什么？为什么这个函数能让模型学到东西？ChatGPT会提到反向传播和矩阵乘法。他就继续追问数学直觉——不要公式，给我类比，给我示意图，给我一个”如果不这么做会怎样”的反例。

一层一层往下钻，直到触及他能理解的基础。然后回到项目，继续往前走。

访谈的主持人把这个方法类比为费曼学习法——最好的学习方式是把你理解的东西讲给别人听，让别人检查你的理解对不对。Richard Feynman说过，如果你不能把一个概念用简单的语言解释给一个小孩听，你就还没真正理解它。在ChatGPT的时代，”别人”可以是AI。你把自己的理解讲给它听，它告诉你哪里对、哪里不对、哪里只对了一半但遗漏了关键条件。

Gabriel给这套循环取了一个名字：递归式知识填补（recursive knowledge-filling）。

“递归”这个词来自计算机科学——一个函数调用自己来解决问题。你把一个大问题拆成结构相同的小问题，对每个小问题再做同样的拆解，直到触及最基本的单元。Gabriel的学习过程就是递归的：做→卡住→追问→获得解释→对解释中不懂的部分继续追问→获得更底层的解释→直到触及自己能理解的地方→返回，继续做。

这里有一个关键的细微之处，很容易被忽略：他不是在用AI跳过基础知识。线性代数、概率论、微积分——这些东西他最终都学了。他只是改变了学习的顺序：不是先学完所有基础再动手，而是先动手，在需要的时候再补基础。该学的一样都没少，只是每一块知识都带着明确的目的——“我学这个是因为我的推荐系统需要它”。

他说，如果只能用一个词来总结这套方法最关键的能力，那就是：知道自己哪里没懂。

这话听起来像是废话，做起来极难。大多数人在学习时的默认模式是”感觉大概懂了”就往下走——这相当于在承重墙上留了一条裂缝，短期看不出问题，但地基是虚的。心理学家有一个专门的术语来描述这种现象：流畅性错觉（illusion of fluency）——当一段解释读起来通顺、看起来合理时，你的大脑会自动把”读懂了”等同于”学会了”。Gabriel的方法之所以有效，是因为”用自己的话复述给AI听”这个动作，强行打破了流畅性错觉：你以为自己懂了，但当你尝试复述的时候，你会发现有些环节你根本说不清楚。

作弊还是学习

在继续讲Gabriel的职业故事之前，有一个相关的插曲值得停下来讲。

ChatGPT在2022年底推出之后，全球的教育系统几乎同时发生了一场小型恐慌。学生的第一反应是”太好了，可以帮我写作业”。老师的第一反应是”完了，大家要作弊，必须禁止”。

这两个反应互相强化，形成了一个闭环。学生看到AI被禁止，确认了它是一种”作弊工具”——既然是作弊工具，那它的唯一用途就是帮我偷懒。老师看到学生果然在用AI写作业，确认了自己的判断——果然是作弊源头，必须严防死守。

在这种叙事环境下，”AI可以用来学习”这个想法几乎没有生存空间。没有人会自然而然地想到：等一下，也许我可以不让它替我写作业，而是让它教我怎么写？

Gabriel在访谈里提到一个有趣的变化：最近他在瑞典的一些朋友开始用ChatGPT做一件不同的事——把历年考试题丢给它，让它总结核心概念，然后生成同类型的新题来练习。他们不是在让AI替自己考试，而是在让AI帮自己备考。同一个工具，用法翻转了180度。

这个差别看起来很小，但它背后的认知差距是巨大的。你把AI当答案机，它就只能强化你的依赖——你越用它代劳，你自己的能力越退化。你把AI当教练，它才会强化你的能力——每一次追问都在迫使你思考，每一次复述都在巩固你的理解。

区别不在工具，在人。

真正稀缺的东西

现在让我们回到Gabriel的职业轨迹。

到这里，我们可以回答开头提出的那个问题了：一个看不懂基础课程的辍学生，是怎么走到OpenAI的？

答案不是”他是天才”。他自己都说他不是。

答案也不是”辍学是一种优势”。访谈材料里反复强调，大学提供的社交网络、资源和视野仍然有很高的替代成本，不鼓励任何人模仿他辍学。

真正的答案，藏在访谈中一个反复出现的词里：agency——能动性。

当知识获取的成本趋近于零——你可以随时问ChatGPT任何问题、获得任何领域的入门解释——“知道很多东西”这件事本身就不再是稀缺资源了。稀缺的变成了另外一些东西：谁愿意动手？谁能定义问题？谁敢对结果负责？

Gabriel从最早带着A3大图上门推销的那一天起，就一直在做同一件事——把能力变成可见的结果。他不跟客户谈学历、背景和资质，他直接展示效果对比，当场用代码证明。

后来他要去美国工作，面临签证问题。没有高中学历，传统的移民路径对他来说几乎全部封死。他走的是O-1A——杰出人才签证，通常需要学术论文、国际奖项、行业认可等”硬证据”。他一个都没有。他没有论文，没有学位，没有任何传统意义上的学术成果。

他做了一件跟上门推销异曲同工的事：把自己在Stack Overflow等技术社区发布的高质量回答和贡献整理成证据包，论证这些贡献具有行业影响力和同行认可度。这些东西在传统标准里不算”学术成果”，但它们满足O-1A签证的核心要求——证明申请者在其领域具有”杰出能力”。

申请被批准了。

不是”请相信我”，而是”来验证我”。

他在访谈中给了一个很实际的建议：如果你没有传统背景做背书，就做一个简单但有效的demo，让别人三秒内看懂你做了什么。很多人误以为demo必须复杂，其实越简单越有力——因为复杂的东西需要解释，而解释的过程中对方的注意力早就散了。如果有机会，主动提出短期试用或者帮忙做一个小项目，让对方零风险地评估你。你承担所有的风险，对方只需要打开眼睛看。

这套策略之所以有效，是因为它精确地回应了AI时代一个底层结构的变化：当获取知识的门槛被AI抹平之后，真正区分人的，不再是你脑袋里装了多少东西，而是你愿不愿意走出去敲那扇门。

洋葱的最里层

每一个好故事都有一个容易被误读的表层。

Gabriel Petersson的故事，表层是”辍学少年逆袭进入OpenAI”。如果你只记住这一层，你会得出一个危险的结论——学历不重要，学校没有用。

但如果你像剥洋葱一样一层层剥下去，你会看到完全不同的东西。

第一层：他不是因为讨厌学校而辍学，他是被一个真实的项目拽走了——压力和交付的截止日期成了他真正的”课程体系”。

第二层：他不是用AI跳过了基础知识，他是用AI把基础知识从”预先储备”变成了”按需补齐”——该学的一样都没少学，只是学的顺序变了。

第三层：他不是在证明”不需要学习”，他是在证明”学习的方式需要改变”——从被动接收变成主动追问，从看懂变成能推进。

第四层：他不是在证明”个人英雄主义”，他是在证明一种可复用的方法论——找到一个必须交付的真实任务，卡住就追问，追问到能继续做为止，然后把结果公开出来让世界验证你。

最里面一层，也是最重要的一层：在一个知识免费的时代，他用行动回答了一个所有人都在回避的问题——如果知识不再稀缺，那什么才稀缺？

答案是你愿不愿意动手。

1984年，Benjamin Bloom发现私人辅导比课堂教学好两个标准差。他把它当成一个”问题”——因为我们没有办法给所有人配私人导师。四十年后，ChatGPT在技术层面上接近了这个梦想，但Bloom当年没有预见到的是：即便你给每个人都配了导师，真正决定学习效果的，仍然不是导师有多好，而是学生愿不愿意开口问第一个问题。

2400年前苏格拉底说，他唯一知道的事情就是自己什么都不知道。在ChatGPT的时代，这句话或许需要一个更新版本：

你唯一需要知道的，是你接下来要做什么。

然后去做。

风格参考：Morgan Housel（《金钱心理学》作者）—— 短故事引出普适原理，每节几乎独立，文字干净利落，金句密度高。

漏水的房子

1831年，迈克尔·法拉第发现了电磁感应。他没有上过大学。他14岁在一家装订作坊当学徒，每天接触大量书籍，但没人教他物理。他学物理的方式是——有一天顾客送来一本《大英百科全书》要求装订，他翻了翻，觉得有意思，就自己开始做实验。

他没有先修数学，没有先学牛顿力学，没有先搞懂欧姆定律。他直接动手做实验，卡住了就去找书看，看完了继续做。这就像住进一栋还没装修的房子，哪里漏水修哪里。

法拉第后来被公认为历史上最伟大的实验物理学家之一。如果他当年先去读一个物理学学位再开始做实验，电磁感应的发现可能会推迟很多年——因为当时的大学物理教育根本不教实验方法，只教数学推导。

两百年后，一个瑞典少年用几乎相同的方式学会了机器学习。

下一班车

Gabriel Petersson在瑞典读高中时，他的表兄打来电话，说要去斯德哥尔摩做一个电商推荐系统的创业项目，让他马上过来帮忙。Gabriel说今晚有个派对。表兄说现在就来。

他买了下一班车票，之后再也没回过学校。

五年后，他加入了OpenAI的Sora团队。

人们喜欢把这类故事读成”辍学天才逆袭”。但Gabriel本人反复强调，他不是天才。他试过Andrew Ng的机器学习课程，完全看不懂。他写的第一个程序是一个”很烂的回合制游戏”。他说过一句很诚实的话：没有压力，我几乎学不会东西。

有意思的不是他的天赋，而是他的方法。

18岁的推销员

到了斯德哥尔摩之后，Gabriel面对的第一个挑战不是技术问题，而是没人买他的东西。

冷邮件没人回。电话建立不了信任。一个18岁的无名少年，没有公司背景，没有客户案例，试图说服成熟的电商企业更换推荐系统——这在任何一个商业教科书里都叫”不可能的推销”。

他做了一件大多数人不会做的事：上门。

提前爬取客户网站的数据，训练一个新的推荐模型，把”旧推荐 vs 新推荐”的效果对比打印在A3大图上，带着文件夹一家家敲门。见到负责人就打开文件夹。对方看完对比图，问”怎么上线”。他当场在浏览器控制台里跑代码，实时替换推荐结果。

不说”请相信我”。说”你自己看”。

这个推销方式粗糙、不可扩展、留下了一堆技术债。但它传达了一件事：我的能力不需要你的信任，只需要你的眼睛。

五年后他申请美国杰出人才签证时，用的是同一套逻辑。

方向相反的两条路

学习有两条路。

一条是自下而上：先学基础，再学进阶，再学应用，最后做项目。这是学校的路。它像搭积木——从底层一块块往上垒，结构稳固，但速度很慢，而且你在搭到第三层的时候可能已经忘了为什么要搭这个东西。

另一条是自上而下：先接一个真实的任务，做的过程中卡住，卡住了就去补那一块缺失的知识，补完继续做。这是Gabriel的路。它像修房子——先住进去，哪里漏水修哪里。

学校选择第一条路，不是因为它效果好，而是因为它是唯一能同时教四十个人的方法。自上而下的路径需要一个随时能回答你问题的导师，在传统教育中，这个条件不可能满足。

1984年，教育心理学家Benjamin Bloom做了一个实验：接受一对一辅导的学生，表现超过了98%接受常规课堂教学的学生。Bloom把这个发现叫做”两个标准差问题”——我们知道最好的教学方式是什么，但我们做不到，因为没有那么多导师。

四十年后，ChatGPT满足了它。不完美，但足够用。

递归

Gabriel给他用AI学习的方法取了一个名字：递归式知识填补。

操作很简单。想学机器学习，就先让ChatGPT设计一个项目、写出代码。代码会报错。从修bug开始，把程序跑起来。跑起来之后追问：这段代码在做什么？为什么它能让模型学东西？ChatGPT提到矩阵乘法，那就继续追问矩阵乘法的直觉。追到你真正理解的地方为止，然后回到项目，继续做。

一层一层往下钻，一层一层再返回。像递归函数一样，直到触及最基本的单元。

有人会问：这跟”跳过基础”有什么区别？

区别很大。跳过基础是不学。递归式填补是在需要的时候学，带着明确的上下文和目的学。最终该学的东西一样都没少，只是顺序变了。

一个类比：你要从北京去上海。自下而上的方式是先学会造汽车，再学会修路，再学会导航，最后出发。递归的方式是先买一张票出发，路上遇到问题再解决——但你最终一样会到达上海，而且你对路况的理解可能比造车的人更深，因为你是真正走过这条路的人。

费曼的升级

Richard Feynman有一条著名的学习原则：如果你不能用简单的语言把一个概念解释给别人听，你就还没真正理解它。

这条原则有一个实操困难：你得找到”别人”。而且这个”别人”最好懂得比你多，能检验你的解释对不对。

Gabriel把”别人”换成了ChatGPT。他把自己的理解讲给AI听，AI告诉他哪里对、哪里不对、哪里只对了一半。

他说这套方法里最关键的一个能力是：知道自己哪里没懂。

大多数人学东西的默认模式是”感觉差不多懂了”就翻过去。这不是学习，这是划水。真正的学习发生在你逼自己说出”等一下，这里我其实不理解”的那一刻。

心理学家有一个词叫”流畅性错觉”——当一段话读起来很顺畅的时候，你的大脑会自动把”读懂了”等同于”学会了”。这两件事完全不是一回事。你读懂了一篇关于游泳的文章，不代表你会游泳。

Gabriel的方法之所以有效，是因为”用自己的话复述”这个动作，强行打破了流畅性错觉。你以为你懂了，但当你开口讲的时候，你会发现有些地方你根本说不清楚。

两种用法

ChatGPT刚推出的时候，学生的第一反应是”太好了，能帮我写作业”。老师的第一反应是”完了，必须禁止”。

这两个反应合在一起，把AI锁死在了”作弊工具”的定位上。

但工具不决定用法，人决定。

你把AI当答案机，它给你答案，你的能力原地不动。你把AI当教练——追问、复述、让它检查你的理解、让它给你反例——你的能力每一轮都在增长。

同一个工具，用法不同，结果天壤之别。这就像钱：有人用它买彩票，有人用它买书。钱没有变，变的是拿钱的人。

Gabriel提到一个有意思的趋势：他在瑞典的一些朋友开始把历年考试题丢给ChatGPT，让它总结核心概念，再生成同类型的新题来练习。不是让AI替自己考试，而是让AI帮自己备考。

这是一个180度的翻转。但它需要一个前提——你得先意识到，AI不只是一台复印机。

信号

Gabriel没有学位，但他持续拿到了好机会。他是怎么做到的？

从最早上门推销推荐系统那天起，他就在做同一件事：把能力变成别人看得见的结果。

不说”请相信我有能力”，而是打开文件夹，展示效果对比图，当场在浏览器里跑代码。后来申请美国的杰出人才签证，没有论文和学位来背书，他就把自己在技术社区发布的高质量内容整理成证据包，作为学术贡献的替代证明。

大多数人在证明自己的时候，习惯递上一份简历，上面列着学校、学位、公司名称。这些是代理信号——它们不直接说明你能做什么，只是暗示”能拿到这些标签的人大概不会太差”。

Gabriel用的是直接信号：这是我做的东西，这是它的效果，你来判断。

代理信号需要别人的信任。直接信号只需要别人的眼睛。

在简历被筛掉的世界里，一个能跑的demo胜过一页纸的经历。

复利

Albert Einstein可能从来没有说过”复利是世界第八大奇迹”这句话。但这并不影响复利本身是一个极其强大的概念。

知识也有复利效应。

当你解决了第一个客户的推荐系统问题，你学到的不只是”如何做推荐系统”。你还学到了如何跟客户沟通需求，如何在浏览器控制台里调试代码，如何把技术效果翻译成商业语言。这些能力会在你解决第二个、第三个、第十个客户问题的时候反复派上用场，而且每一次使用都让它变得更强。

Gabriel五年内从零基础走到OpenAI，看起来像是火箭式跃迁。但如果你拆开看，每一步都不大——每一步只是”解决了当下的一个问题”。它之所以最终产生了巨大的结果，是因为这些步骤是复利式累积的：每一个新能力都建立在之前所有能力的基础上，而且每一次积累都增加了下一次积累的速度。

这就是为什么”先动手”比”先准备”更有效。

你准备了三年再开始，你错过了三年的复利。而知识复利跟金融复利一样，真正产生巨大差异的不是利率高低，而是时间长短。越早开始，优势越大。

稀缺

经济学有一条最基本的道理：价格由稀缺性决定。

钻石贵，因为稀缺。空气免费，因为不稀缺。

知识曾经是稀缺的。获取它需要学费、时间、人脉和运气。所以”懂得多”是一种竞争优势，学历是它的证明。

现在知识不稀缺了。你可以在任何时刻、向ChatGPT问任何领域的任何问题，几秒钟得到一个80分的回答。

那什么变稀缺了？

是愿意动手的人。是能定义问题的人。是对结果负责的人。是在卡住的时候不翻过去、而是追问到底的人。

Gabriel在访谈里反复用一个词：agency。翻译过来就是能动性。

知识是原材料。能动性是把原材料变成成品的那双手。原材料可以免费获取，但那双手仍然稀缺。

一个有趣的推论：在知识稀缺的年代，”记忆力好”是一种优势——谁记得多，谁就知道得多。在知识免费的年代，记忆力的价值大幅缩水，因为任何你记不住的东西都可以在三秒内查到。取而代之变得重要的，是判断力——面对AI给你的十个答案，你能不能判断哪个最好？面对AI做不到的问题，你能不能定义出来？

记忆力是仓库。判断力是指南针。仓库可以外包给AI，指南针不能。

最后一件事

Gabriel的故事不是”学历无用论”。他自己都说，大学的社交、资源和视野有很高的替代成本。

他真正反对的，是一种更隐蔽的东西——把”我还没准备好”当作不动手的理由。

在知识稀缺的年代，”先准备好再出发”是合理的策略。学完课程再找工作，读完教材再做项目，打好基础再考虑应用。因为获取知识的成本很高，所以你必须先储备。

在知识免费的年代，这个策略的性价比急剧下降。你花三年”打基础”，等你觉得准备好了，世界可能已经换了一道题。

更好的策略是：先动手，遇到不懂的再去学。学完继续做，做完再回头看，你会发现自己比”准备好了才出发”的人走得更远。

这不是新道理。法拉第两百年前就是这么干的。

但在ChatGPT的时代，这条路变得比任何时候都更容易走。以前你”先动手再学”，卡住了可能要等几天才能找到答案。现在你卡住了，三秒钟就能问到。以前这条路上布满了沟壑，现在沟壑还在，但你手里多了一根拐杖。

唯一的门槛是——你得愿意迈出第一步。

而这个门槛，从来都不是知识的问题。

风格参考：万维钢（《精英日课》作者）—— 跨学科引证，框架式拆解，加粗关键洞察，用数据和类比交叉验证每个论点。

“人类最快的学习方式是top-down——从真实任务出发，遇到不懂的就当场补，再继续往下做。” —— Gabriel Petersson

引子：一个不该被当成励志故事的故事

最近有一个访谈在技术圈引起不少讨论。主角叫Gabriel Petersson，瑞典人，五年前还在读高中、几乎没有工程经验，五年后加入OpenAI，成为Sora团队的研究工程师。

这类故事很容易被读成”辍学逆袭”的鸡汤。但如果你只读到这一层，就浪费了它真正有价值的部分。

访谈材料里反复强调一点：这不是在鼓励辍学。 大学提供的社交网络、行业资源和认知视野，仍然有很高的替代成本。Gabriel自己也承认，没有文凭在一些场景确实是硬性限制——比如签证，没有学历让他的移民路径困难重重。

那这个故事的价值在哪里？在于它清晰地展示了一套”AI时代的学习操作系统”——项目驱动、top-down路径、递归追问、用结果替代信号。这套系统不依赖于”辍学”这个极端条件，任何人都可以部分复用。

下面我来逐一拆解。

一、压力即课表：为什么”先上场再学会”比”先学会再上场”更高效

1.1 一个18岁的上门推销员

Gabriel辍学的过程并没有什么戏剧性的深思熟虑。表兄打电话让他去斯德哥尔摩做一个电商推荐系统，他当天就买了车票，之后再也没回学校。

到了创业公司之后，他面对的第一个问题不是技术问题，而是销售问题：冷邮件没人回，电话建立不了信任。于是他发明了一套很”野”的打法——上门推销。提前爬取客户网站数据，训练一个新的推荐模型，把”旧推荐 vs 新推荐”的效果对比打印成A3大图，带着文件夹直接去敲门。

见到负责人之后，当场在浏览器控制台里粘贴脚本替换推荐结果，并内置A/B测试对比收益。很多客户第一次见面就切换了方案。

他也承认这种做法带来了大量技术债——为了获客速度，几乎不考虑系统的可维护性和可扩展性。但他认为在那个阶段，验证商业假设远比写出完美代码重要。这个判断本身就值得注意：它意味着他在18岁的时候就隐约理解了创业中”速度优先于完美”的权衡。

1.2 “没有压力我学不会东西”

主持人问他：一开始不会写代码，怎么学的？

他的技术学习史其实相当坎坷。表兄教他Java，写了个”很烂的回合制游戏”；后来上Udemy学Python，做了个”同样很烂的游戏”；试过Andrew Ng的机器学习课，完全看不懂，一度以为自己太笨。

真正的学习发生在创业之后。 客户集成、爬虫、推荐系统、A/B测试——问题一个接一个摆在面前，解决不了就丢客户。他去Stack Overflow查，找身边人问，硬着头皮试。他说了一句关键的话：没有压力我几乎学不会东西。

这里有一个微妙但重要的区别：不是所有压力都能促进学习，只有”有意义的压力”才行。 考试也是压力，甚至是很大的压力。但考试压力和客户交付的压力，在认知效果上有根本的不同。

1.3 动机研究怎么说

心理学家Edward Deci和Richard Ryan的”自我决定理论”（Self-Determination Theory）区分了两类动机：外在动机（为了考试、为了证书、为了避免惩罚）和内在动机（为了解决一个真正困扰你的问题、为了好奇心、为了胜任感）。大量实证研究表明，当学习者感到自主性（autonomy）、胜任感（competence）和关联性（relatedness）时，学习效果最好。

Gabriel的创业环境恰好同时满足了这三个条件：他自主选择了这条路（自主性），每一次成功交付都强化了能力感（胜任感），客户的即时反馈和表兄的合作关系提供了连接（关联性）。

相比之下，传统的课堂学习往往只满足关联性（同学关系），自主性和胜任感则严重不足——你不能选择学什么，考试只会告诉你”不及格”而不会给你”搞定了”的爽感。

换句话说，压力本身不是他的课程表，”有意义的压力”才是。 考试也是压力，但考试压力不满足自主性条件，所以效果远不如真实项目的压力。

1.4 心流研究的佐证

心理学家Mihaly Csikszentmihalyi在研究”心流”（flow）状态时发现，人在以下条件下最容易进入高效学习和工作状态：任务难度略高于当前能力，目标清晰，反馈即时。 这恰好描述了Gabriel的处境——客户的需求就是清晰目标，代码能不能跑就是即时反馈，而每个新客户的需求都比上一个稍难一点。

反观课堂学习：目标模糊（”学好线性代数”不是一个可操作的目标），反馈延迟（期末才知道成绩），难度要么太低（已经会的内容重复讲）要么太高（完全跟不上）。这几乎是心流的反面。

二、Top-down学习：一种被学校淘汰、被AI复活的路径

2.1 两种学习路径的效率差异

访谈中最有方法论价值的一段，是Gabriel对学习路径的判断：人类最快的学习方式是top-down。

什么是top-down？从一个真实的任务出发，做的过程中遇到不懂的就当场补，补完继续做。与之相对的是bottom-up：先修线性代数，再修概率论，再修统计学习，再修神经网络，最后做项目。

用一个建筑类比：bottom-up是”先设计完整蓝图，再按图施工”；top-down是”先住进去，漏水了修漏水，断电了修断电”。前者适合建摩天大楼，后者适合改造一栋够住的房子。大多数人的学习目标，更接近”改造一栋够住的房子”。

2.2 认知负荷理论的解释

认知科学家John Sweller提出的认知负荷理论（Cognitive Load Theory）提供了一个理解框架。人的工作记忆一次能处理的独立信息块不超过4-7个——这个数字从1956年George Miller发表经典论文以来就没有被推翻过。

Bottom-up路径有一个隐性成本：外在认知负荷过高。 当你学到第三层的时候，你已经记不清第一层为什么重要了，而且你完全不知道这些知识将来用在哪里。大量认知资源被浪费在”维持意义感”上——“我为什么要学这个？””这东西以后到底有什么用？”这些问题本身就在占用你宝贵的工作记忆。

Top-down路径没有这个问题。你始终有一个具体目标（让系统跑起来、让客户满意），每一块新知识自动嵌入上下文（”我学矩阵乘法是因为推荐系统需要它”），外在认知负荷被压到最低，几乎所有的认知资源都投入在了”理解新知识”本身。

2.3 学校为什么不用top-down

答案很简单：top-down无法规模化。

它要求老师持续判断”这个学生此刻卡在哪里”、”下一步应该补什么”——等于给每个学生配一个全天候私人导师。在40人的班级里不可能做到。所以学校选择了bottom-up，不是因为效果最好，而是因为它是唯一能规模化的方案。

1984年，教育心理学家Benjamin Bloom发表了著名的”两个标准差”研究：接受一对一辅导的学生，表现比课堂教学的学生高出两个标准差，也就是超过98%的对照组学生。这个效果量在教育研究中几乎是前所未有的。Bloom把它当成一个”问题”——我们知道什么是最有效的教学方式，但我们做不到。

这是教育领域一个经典的效率-规模权衡：最高效的学习方式往往是最不可规模化的，最可规模化的学习方式往往是最低效的。

2.4 ChatGPT改变了什么

ChatGPT——以及所有大语言模型对话工具——做的事情，本质上是把top-down学习的规模化约束打破了。

以前，你如果想在做项目的过程中随时追问、随时获得定制化的解释，你需要一个私人导师。好的私人导师时薪几百到几千元，而且你得迁就他的时间表。现在，ChatGPT可以24小时扮演这个角色：你卡在矩阵乘法上，它给你讲矩阵乘法；你卡在反向传播上，它给你画示意图；你不确定自己的理解对不对，把理解讲给它听，它逐句检查。

当然，ChatGPT不是完美的导师——它会犯错，有时候错得很隐蔽。但即便考虑到错误率，它的可用性和响应速度仍然远超任何人类导师。而且它的错误是可以被发现的——你可以让多个模型交叉验证，或者回到实际代码里跑一下看看结果对不对。

这不是”用AI作弊”。这是top-down学习第一次有了可规模化的基础设施。 Bloom四十年前提出的”两个标准差问题”，在技术层面上开始有了接近可行的解答。

2.5 一个容易被忽略的前提

需要强调的是，ChatGPT满足的是top-down学习的”导师”需求，但top-down学习还有一个前提条件是它满足不了的：你必须有一个真实的、必须交付的任务。

没有任务驱动的top-down学习是不存在的。如果你只是坐在那里问ChatGPT”教我机器学习”，那本质上还是bottom-up——你让AI当老师给你从头讲起，只不过换了一个更有耐心的老师而已。

真正的top-down是你先有一个项目，在做的过程中碰到了具体的、明确的障碍，然后你带着这个障碍去问AI。问题的质量决定了学习的质量，而问题的质量取决于你是否在真正做一件事。

三、递归式知识填补：把AI变成苏格拉底

3.1 一个可操作的循环

Gabriel给他的学习方法取了一个名字：递归式知识填补（recursive knowledge-filling）。

他举了一个具体例子：想学机器学习，先问ChatGPT该做什么项目，让它设计计划并写出完整代码。代码必然报错，于是从修bug开始把程序跑起来。跑起来之后，盯着某个模块追问——这段在做什么？为什么能让模型学习？ChatGPT提到线性代数和矩阵乘法，于是继续追问数学直觉、要类比、要反例，直到建立真正的理解。然后回到项目继续做。

写成循环，大致是：

动手（做具体任务）→ 卡住 → 追问（问到能继续为止）→ 把抽象变具体（要直觉、类比、反例）→ 反向输出（用自己的话复述，让AI纠错）→ 回到任务

3.2 费曼学习法的AI升级版

访谈主持人把这个过程类比为费曼学习法。Richard Feynman著名的学习原则是：如果你不能把一个概念用简单的话解释给别人听，你就还没真正理解它。

这个原则在传统环境下有一个实操困难：你去哪里找那个”别人”？ 你总不能每学一个新概念就拉一个朋友来听你讲。而且朋友的知识水平不一定能检验你的理解是否正确。

ChatGPT解决了这两个问题：它随时可以充当”别人”，而且它有足够的知识储备来检查你的理解——不仅能告诉你对不对，还能指出你遗漏了什么、哪里只对了一半。

如果说费曼学习法是1.0版本（讲给别人听），那Gabriel的方法就是2.0版本（讲给AI听，让AI纠错，追问AI的纠错直到彻底理解）。

3.3 核心能力：知道自己哪里没懂

Gabriel说，这套方法最关键的底层能力是一个：知道自己哪里没懂。

这句话暗含了心理学家所说的元认知（metacognition）——对自己认知过程的监控和调节。元认知能力强的人，能够准确评估”我现在到底理解了多少”，而元认知能力弱的人，容易高估自己的理解程度。

Daniel Kahneman在《思考，快与慢》中讨论过一个相关的现象：人类天生倾向于”认知放松”（cognitive ease）——当一段文字读起来流畅、信息看起来熟悉时，我们会自动倾向于认为自己”已经懂了”，而实际上很可能只是”看过了”。

Dunning-Kruger效应也指向同一个问题：能力不足的人往往最不擅长判断自己能力不足。 你越不懂一个领域，你就越难意识到自己不懂。这是一个令人不安的悖论——恰恰是最需要学习的人，最不知道自己需要学什么。

Gabriel的方法为什么能部分破解这个悖论？因为”用自己的话复述给AI听”这个动作，强制把隐性的理解差距变成显性的。 你以为自己懂了，但当你尝试向AI解释的时候，你会发现有些环节你说不清楚——这就是你的认知缺口。

“看过”和”懂了”之间的差距，就是大多数人学习效率低下的根源。Gabriel的方法强制拉大了这个差距的可见度——因为你必须用自己的话复述、用AI检查，”假装懂了”的空间被压缩到了最小。

3.4 追问的三个层次

基于Gabriel的描述和费曼学习法的原则，我总结了一个实用的”追问三连”框架：

第一层：要直觉解释。 不要公式，不要术语，用最日常的语言和类比让我理解这个概念。如果AI给你一段充满术语的解释，那不是你理解了，是你被术语糊弄了。

第二层：要反例和边界条件。 在什么情况下这个结论不成立？有没有这个方法失败的案例？这一步的目的是建立”边界感”——不是死记一个结论，而是知道它在哪里成立、在哪里不成立。

第三层：反向复述。 用自己的话把理解讲回去，让AI检查。这是最容易被跳过的一步，也是最关键的一步。跳过它，你就停留在”看过”的层面；做了它，你才进入”懂了”的层面。

四、知识廉价之后，什么变贵了

4.1 能动性：AI时代真正稀缺的资源

Gabriel的故事容易被简化为”天赋”或”运气”。但访谈中反复出现的关键词指向了一个更底层的变量：agency（能动性）——你主动提出问题、定义需求、推动进程并对结果负责的意愿和能力。

为什么能动性在AI时代变得更重要？因为一个结构性的变化已经发生：

上面三行的成本被AI大幅压缩了，下面四行几乎没有变化。这意味着，知识和信息不再是区分人的核心变量；真正区分人的，是谁愿意动手、谁能定义问题、谁能持续推进、谁对结果负责。

经济学的基本逻辑：当某种资源从稀缺变为充裕，与它互补的资源就会变得更值钱。 电力普及之后，会使用电力设备的工人变贵了。互联网普及之后，能生产优质内容的创作者变贵了。AI把知识变得廉价之后，能运用知识去解决问题的能动性就变贵了。

4.2 证据链：把能力变成信号

Gabriel在没有传统学历信号的情况下能持续获得机会，靠的是一套”证明策略”：

从最早上门推销推荐系统开始，他就在做一件事——把能力变成可见的结果。 不跟客户谈学历、背景和资质，直接展示效果对比，当场用代码证明。后来申请O-1A杰出人才签证时，他把在Stack Overflow等技术社区的高质量贡献整理成证据包，作为”学术成果”的替代证明——没有论文，就用社区影响力代替；没有学位，就用交付成果代替。

经济学家Michael Spence在1973年提出的信号理论（signaling theory）可以解释这里的逻辑：在信息不对称的市场中，求职者需要发送”信号”来证明自己的能力。传统上，最常用的信号是学历——因为它获取成本高，所以具有筛选功能。但学历是一种代理信号（proxy signal），它不直接证明你能做什么，只是间接暗示”能考上好大学的人大概率能力不差”。

Gabriel做的事情是用直接信号替代代理信号——不是”我有学位所以我可能能干活”，而是”这是我的作品、这是效果数据、这是第三方评价，你自己判断”。

在传统的劳动力市场中，代理信号之所以有效，是因为验证直接信号的成本很高——招聘方没有时间、精力和专业能力去评估每个人的实际作品。但AI时代正在降低这个验证成本。你可以快速做一个demo，对方可以快速评估；你可以在GitHub上展示代码，任何人都可以审查；你可以做一个短期试用项目，让结果说话。

他在访谈中给的建议非常具体：做一个简单但有效的demo，让对方三秒内看懂你做了什么。主动提出短期试用或免费帮忙做小项目，让对方低风险评估你。不要请求”相信我”，要提供”验证我”。

4.3 AI在教育中的集体误读

访谈里有一段非常现实的讨论。ChatGPT推出之后，学生第一反应是”太好了可以写作业”，老师第一反应是”完了大家要作弊必须禁止”。两个反应互相强化，形成一个闭环：AI在学校的叙事里被锁定为”作弊工具”。

这是一种集体误读。 它把AI最低层次的用法（替你生成答案）当成了AI的全部用法，忽略了真正有价值的那层——AI可以作为学习的加速器。

Gabriel提到一个有趣的变化：最近他在瑞典的一些朋友开始用ChatGPT把历年考试题丢给它，让它总结核心概念，然后生成同类型的新题来练习。不是让AI替自己考试，而是让AI帮自己备考。

这个区别看起来很小，但背后的认知差距是巨大的。你把AI当答案机，它就只会强化你的依赖。你把AI当教练，它才会强化你的能力。这不是工具的问题，是使用者的选择。

行为经济学家有一个概念叫”框架效应”（framing effect）——同样的信息，用不同的方式呈现，会导致截然不同的决策。AI在教育中的命运，很大程度上取决于它被如何”框架”——如果它被框架为”作弊工具”，学生就会把它当作弊工具用；如果它被框架为”学习教练”，学生才可能把它当教练用。目前的现实是，绝大多数教育环境都在强化前一种框架。

结语：一把新的尺子

最后，回到这个故事最容易被误读的地方。

Gabriel的故事不是”学历无用论”。他真正反对的不是学校本身，而是一种更深层的路径依赖——把”学习”当目的、把”打基础”当拖延的思维习惯。

这种路径依赖在知识稀缺的年代是合理的。获取知识成本很高，所以你必须先花几年时间储备，然后才能”上场”。但在AI把知识获取成本压到接近零的今天，这种路径依赖的代价变得前所未有地高。你花三年”打基础”，等你”准备好了”，问题和机会可能早就换了一茬。

经济学家Tyler Cowen有一个观点：在变化速度快的环境中，”行动的期权价值”远高于”等待的期权价值”。 你现在就动手做一个项目，即使做得很烂，你也获得了关于”下一步做什么”的信息。你坐在那里等自己”准备好”，你获得的信息是零。

如果只从这个访谈里带走一个判断，我建议是这个：

当知识不再稀缺，衡量一个人的尺子就不再是”你知道多少”，而是”你能用知道的东西做出什么”。 能动性、追问的耐心、把能力变成可验证结果的习惯——这些是新尺子上的刻度。

Gabriel的经历极端，不可照搬。但他的方法论——找一个必须交付的真实任务，在做的过程中卡住，卡住就追问，追问到能继续做为止——这是任何人明天就可以开始实践的。

不需要辍学，不需要搬去斯德哥尔摩，不需要做出一个推荐系统。你只需要找到一个足够真实的问题，然后动手。

1. 不要直接买股票

2. 永远不再踏进 Casino

1

果然，阅读情况大大好转。阅读285小时，超过原定目标的270小时，同时也远远超过此前一个月的229小时。自己开发的番茄APP，帮助了我很多。

冥想26.5小时。冥想时间少，说明这个月的精神压力不大，情绪不错。虽然如此，接下来的时间我会刻意增加冥想时间，尝试制定每月目标。

接下来，我会跟大家分享我是如何借助AI编程刺激自己多读书的。

2

之前就跟大家分享过，我自己开发了一个全新的番茄工作法APP，叫番茄冥想。APP只有两个功能，一个是记录番茄任务，另一个就是记录冥想。

APP需要不断地迭代。我每天至少打开这个APP上百次，在使用中积累用户体验。也就是说，我即是开发者，也是目标用户。

因为要不断地打开这个APP，我就自然而然会想要派上用场——多看书，多记录。

多看书，多记录，也就越能发现APP的问题所在。

改正问题，迭代软件，也就会让这个APP越来越好用。好用，我就会多用；多用，我就会多看书。正向循环

接下来，我打算参考我曾经用过的Top10容易上瘾的APP，借鉴里面的设计。

3

在借助AI开发的过程中，我常常发现自己在知识储备上的不足。

就拿最简单的UI设计来说，我知道界面很丑，不够好看。但是我除了说“界面不好看”之外，就不知道说啥了。也就是说，我不知道往那方面改进，会让界面变得更好看。

AI收到我的指令，的确也能给出一些建议。但是这样的改进效率很低，经常是越改越丑，还不如最初的设计。

发现自己的不足之后，我就会找一些书来。产品知识不够，我就看《启示录》和《设计冲刺》。设计知识不够，我就看《设计心理学》。

这就是干中学，学中干。以前的开发只要懂开发就行了，不需要懂产品，也不需要懂设计。未来可能就没有专职的软件开发工程师，只有软件主理人——一个人，顶多就两三个人，就要把一个软件的从头到尾都管起来。

当然，很多现有的书并不能满足我的要求，我需要看一些网上的资料。之前遇到的问题就是，那么多资料，我要如何整合在一起呢？

4

我做了两件事，就把网上的优质资料变成个人图书馆里的一本本电子书。

第一件事，我用ChatGPT的深度研究模式，帮我整理某个主题的信息，生成一篇三万字左右的长文。

这样生成的长文，信息密度和信息针对性是够够的，但是可读性不足。紧接着，我会用Cursor里的Opus 4.6模型，帮我润色文章。我会告诉它用哪本我喜欢的书的风格去改写，例如《算法之美》和《人机对齐》。

第二件事，我开发了一个专用的阅读APP。这个APP可以自动下载我整理好的这些文章，自动转化成电子书格式，我在手机上就可以轻松阅读。

在这个APP上，我可以做笔记，还可以看到自己的阅读次数和阅读时间。这样的快捷和便利，让我喜欢上了在手机上阅读，喜欢上了看那些自己和AI一起“创作”的一本本小书。

5

AI时代的技术发展日新月异，我偶尔也会感到不安，甚至是恐慌。

在变化当中，我找到了不变的东西，那就是阅读。无论AI如何发展，我还是会阅读。无论未来的社会变成什么样，我还是会阅读。

截至2026年1月31日，我一共阅读了19423.5小时。预计会在2026年4月5日，完成第二个10000小时，也就是总共20000小时的阅读目标。

二月份的阅读目标是600个番茄时间，也就是300个小时。冥想目标是40小时。

“别只盯着模型多大、参数多少，真正决定 AI 未来的是资源约束、劳动形态和个人能力的重新定价。” — 熊辉

一个被问错了的问题

每当一波新技术浪潮到来，公众讨论中出现频率最高的问题永远是同一个：“它会取代我的工作吗？”

我想说，这个问题本身就问错了。

不是因为它不重要——当然重要，饭碗的事谁不关心。而是因为这个问题的框架暗含了一个错误假设：它假设存在一条清晰的分界线，线的一边是“会被取代的工作”，另一边是“不会被取代的工作”，你只要搞清楚自己站在哪一边就行了。

现实从来不是这样运作的。

历史上每一次重大的技术变革——蒸汽机、电力、互联网——都没有简单地“消灭”一批工作然后“保留”另一批。它们做的事情更微妙也更深远：它们改变了“价值”的定义本身。 蒸汽机出现之后，“力气大”不再等同于“有价值”；互联网出现之后，“信息多”不再等同于“有价值”。不是你的工作消失了，而是衡量你工作价值的那把尺子变了。

所以，真正值得问的问题不是“AI 会不会取代我”，而是——在 AI 时代，衡量一个人职业价值的尺子，会变成什么样子？

一旦你把问题换成这个，整个思考的方向就变了。你不再是站在原地恐惧地等待“被取代”的判决，而是开始主动地研究那把新尺子——它的刻度是什么？它量的是什么维度？它偏爱什么、忽略什么？

这恰好是熊辉在《太学》演讲中试图回答的问题。而他的回答，让我认真思考了很久。

从最不性感的地方开始

如果你去参加一场 AI 行业大会，你会听到无数人在谈模型、谈参数、谈 benchmark。但熊辉上台后做了一件反直觉的事情：他首先谈的是电力。

是的，电力。发电厂、输电网、冷却系统——这些工程师和投资人讨论 AI 时几乎不会提到的东西。

这看起来很不性感，但熊辉的逻辑链是这样的：大模型的训练和推理需要海量算力，算力需要芯片，芯片运行需要电力，而电力——这是关键——不是无限供给的。全球数据中心的用电量已经超过了很多中等国家的全年用电量，而且随着 AI 应用的爆发式增长，这个数字还在加速上升。

为什么这个判断重要？因为它颠覆了一个隐含的假设。

大多数人在思考 AI 的未来时，默认的假设是“算力会无限增长”——模型会越来越大，推理会越来越快，成本会越来越低，最终 AI 能做一切。这个假设在纯技术层面上也许是对的——摩尔定律的某种变体可能会继续生效。但在物理和经济层面上，它撞上了一堵墙：你不能从虚空中变出电力。

这让我想到了一个有趣的历史类比。

19 世纪中叶，英国正处于工业革命的巅峰。蒸汽机越来越高效，工厂越建越多，所有人都沉浸在技术进步的乐观情绪中。这时候，一个叫威廉·斯坦利·杰文斯的经济学家站出来泼了一盆冷水：他指出，蒸汽机效率的提升不会减少煤炭消耗，反而会因为降低了使用成本而导致煤炭需求暴增。英国面临的不是技术瓶颈，而是煤炭供给瓶颈。

杰文斯说对了。蒸汽机的普及最终确实让英国的煤炭消耗远远超出了所有人的预期。而真正在那个时代建立持久优势的，不是造蒸汽机最快的人，而是掌握了煤矿、铁路和基础设施的人。

今天的 AI 行业正在上演同样的故事。微软重启了核电站来给数据中心供电，亚马逊和谷歌在投资核聚变，OpenAI 的 CEO 个人往核聚变公司砸了数亿美元。这些举动的底层逻辑只有一个：在 AI 时代，电力是比模型更硬的护城河。

我之所以在这个看似与“职业规划”毫不相关的话题上花这么多篇幅，是因为它教给我们一种重要的思考方式：任何时候，当你试图判断一个趋势的走向时，不要只看它最炫的部分，要去找它最约束的部分。 系统的产出由最薄弱的环节决定，而非最强大的环节。

这个思维习惯如果迁移到个人职业规划上，意味着什么？它意味着：你不应该追着“最热门的技能”跑——因为最热门的地方恰恰是供给最充足的地方，也是竞争最激烈的地方。你应该去找那些“约束”所在的地方——那些大家忽略的、但系统没了它就转不动的环节。

这就自然引出了熊辉的第二个论点。

从“做事的人”到“编排事情的人”

让我先讲一个思想实验。

假设你是一个程序员。现在有两种工作方式摆在你面前：

方式 A：你坐在电脑前，从早写到晚，一天写 500 行代码。质量不错，效率也算高。

方式 B：你花一个小时想清楚任务怎么拆解，然后同时启动三个 AI 代理——一个写业务逻辑，一个写单元测试，一个做代码审查。你花两个小时在三个代理之间切换，检查它们的输出，修正方向，整合结果。一天下来，你产出了 3000 行经过测试和审查的代码。

方式 B 的产出是方式 A 的六倍。但请注意，你写的代码量反而更少了。你多出来的产出不是因为你打字更快了，而是因为你做的事情变了——从“写代码的人”变成了“编排代码生产流程的人”。

这就是熊辉所说的“人机协作新劳动体”的核心含义。

这个变化的深远程度，可能比大多数人意识到的更大。让我从几个角度来解释为什么。

首先，它改变了“能力”的定义。在传统的工作模式中，你的价值主要取决于你的“执行能力”——你写代码写得多好、你翻译翻译得多准、你分析分析得多深。但在新的模式中，你的价值越来越取决于你的“编排能力”——你能不能把一个复杂的问题拆解成多个可并行执行的子任务？你能不能为每个子任务设定清晰的质量标准？你能不能在多条工作流之间高效切换、发现问题、修正方向？

这是一种完全不同的技能集。有些人在旧体系里是顶尖执行者，但在新体系里可能不善于编排。反过来，有些人在旧体系里不是最快的执行者，但他们思维清晰、善于拆解问题、对质量有敏锐的直觉——这些人在新体系里可能会脱颖而出。

其次，它改变了“产能”的上限。一个人的执行能力有生理上限——你一天最多能高效工作八到十个小时，一年最多能掌握两三门新技能。但一个人的编排能力没有明确的上限——理论上，只要你能设计出足够好的工作流、建立足够可靠的质量检验机制，你可以同时管理任意多条自动化流水线。

这让我想到了金融领域的一个概念：杠杆。

在金融里，杠杆让你用少量本金撬动大量资产。AI 代理提供的是“认知杠杆”——让你用有限的判断力和决策能力，撬动远超个人产能的输出。但就像金融杠杆一样，认知杠杆也有风险：如果你的判断是错的，杠杆会放大你的错误。这就是为什么熊辉强调“证据链”——每条工作流都必须输出可追溯的日志、测试结果和回滚方案。没有证据链的认知杠杆，就像没有风控的金融杠杆——赚的时候很爽，爆的时候很惨。

最后，它改变了“面试”的内涵。熊辉预测，未来你去面试时带去的不只是简历，而是一整支“数字团队”。这话如果往深了想，它暗示着一种全新的雇佣关系：雇主买的不再是“你这个人八小时的时间”，而是“你加上你的数字团队所能交付的成果”。这意味着个体之间的产能差异可能会急剧拉大——不是因为人与人之间的能力差异变大了，而是因为杠杆效应会把微小的差异放大到巨大。

好的编排者和差的编排者之间的差距，可能不是两倍三倍，而是十倍二十倍。这是一个令人不安的推论，但逻辑上它站得住。

这里面还有一个微妙的心理障碍值得提一下。很多资深的专业人士——优秀的程序员、经验丰富的设计师——在面对这个转变时，会感到一种“身份感的丧失”。他们多年来建立自我认同的方式是“我是一个写出漂亮代码的人”、“我是一个设计出优雅界面的人”。让他们从“亲手做”转向“编排别人（或 AI）做”，感觉像是被剥夺了手艺人的尊严。这种情绪是真实的，也是合理的。但历史不会因为我们的情绪而暂停。印刷术出现的时候，最好的抄写员也不愿意放下羽毛笔。

真正稀缺的不是答案，是问题

现在让我们进入熊辉演讲中我认为最有洞察力的部分。

他说，在大模型时代，两种能力变得格外重要：提问力和鉴赏力。

这两个词听起来很抽象，让我把它们拆开来看。

先说提问力。

表面上看，“提问”是一件很简单的事——你有什么不知道的，就去问。但如果你认真想想，你会发现“提出一个好问题”其实极其困难。

什么是好问题？一个好问题应该满足几个条件：第一，它指向一个真正重要的未知领域，而不是一个已经有标准答案的已知问题；第二，它的范围足够具体，使得回答可以被验证，而不是一个大而无当的宏大叙事；第三，它能引出新的、非显而易见的发现，而不仅仅是确认你已经知道的东西。

科学史上最伟大的进步，几乎都始于一个好问题，而非一个好答案。达尔文没有“发明”进化论——他问了一个别人没有认真问过的问题：“为什么加拉帕戈斯群岛上不同岛屿的雀类长得不一样？”爱因斯坦没有“计算出”相对论——他问了一个看似荒唐的问题：“如果我以光速骑在一束光上，我会看到什么？”

在 AI 时代，“提问力”的重要性被进一步放大了。原因很简单：AI 是一个极其强大的“答案机器”，但它是一个极其糟糕的“问题机器”。 你给它任何问题，它都能给你一个看起来不错的回答。但它不会主动问你：“你确定你问对了问题吗？”它不会告诉你：“你应该先去搞清楚另一个问题。”它不会指出：“你问的这个问题基于一个错误的前提。”

这意味着，在人 + AI 的协作中，“提出正确的问题”这件事完全落在人的肩上。如果你问了一个错误的问题，AI 会很认真地给你一个精确但无用的答案——就像你在 GPS 里输错了目的地，导航系统会非常精确地把你带到一个你根本不想去的地方。更糟糕的是，AI 的回答往往看起来很专业、很自信、格式很漂亮，这会让你更难意识到自己问错了——GPS 的导航界面并不会因为目的地输错了而变得难看。

再说鉴赏力。

如果说提问力解决的是“问什么”，鉴赏力解决的是“怎么评判答案的质量”。

在 AI 能秒出答案的时代，“生产”不再是瓶颈。你可以让 AI 在几分钟内生成十份营销方案、二十段代码实现、五十个产品命名方案。瓶颈在于：从这些海量输出中，你能不能准确地挑出那个最好的？ 更进一步，你能不能说清楚“好”的标准是什么？

这很像品酒。世界上有数不清的葡萄酒，大多数人喝起来觉得“差不多”。但一个训练有素的侍酒师能在盲品中区分年份、产区、甚至酿酒师的风格。他的价值不在于能生产更好的酒，而在于他的味蕾经过了足够多的训练，能感知到普通人感知不到的差异。

AI 时代的“鉴赏力”就是这种“训练过的味蕾”。它不是天生的，而是可以通过刻意练习来培养的。

熊辉分享了一个我觉得特别聪明的练习方法：多模型交叉验证。

操作很简单：把同一个问题同时抛给 GPT、Claude 和 Gemini，然后仔细对比它们的回答。如果三个模型的答案高度一致，说明这个问题的答案在训练数据中有充分的覆盖，大概率可信。但如果三个模型给出了截然不同甚至互相矛盾的回答——这才是最有意思的情况。

为什么有意思？因为模型的“集体困惑”往往指向了人类知识体系中的真正盲区。这些盲区可能是因为训练数据不足，可能是因为这个领域本身存在争议，也可能是因为这是一个还没有被系统化研究的新领域。

无论是哪种情况，这个“盲区”本身就是一个极有价值的信号。它告诉你两件事：第一，AI 在这里不可靠，你需要依赖自己的判断或去做一手调研；第二，这里有尚未被开发的认知领土——如果你能在这里建立起可靠的知识，你就拥有了 AI 无法提供的独特价值。

这就引出了熊辉的下一个论点——也许是他整个演讲中对职业规划最有操作性的一个。

为什么你应该去“没有数据”的地方

大多数关于 AI 时代的职业建议，说来说去就是两条：“学会使用 AI 工具”和“提升不可替代的软技能”。这两条都没错，但也都太笼统了——它们没有告诉你具体该往哪里走。

熊辉给出了一个出人意料的具体方向：去数据稀疏的地方。

让我解释一下这句话的含义，因为它比表面看起来深刻得多。

AI——特别是当前的大语言模型——的能力边界，本质上由它的训练数据决定。训练数据丰富的领域，AI 就强；训练数据稀疏的领域，AI 就弱。这不是工程能力的问题，而是底层逻辑决定的——你不可能从没见过的数据中学到模式。

所以，如果你想要在一个 AI 很强的领域跟它竞争——比如标准化翻译、模板化编程、通用数据分析——你面临的是一场你几乎不可能赢的消耗战。AI 更快、更便宜、不知疲倦、不会抱怨。

但如果你去一个 AI 的训练数据还不充分的领域呢？

这些领域通常有几个特征：高度本地化（信息只存在于特定地理区域或特定社群中）、高度隐性化（知识存在于人们的经验和直觉中，从未被写成文字）、高度情境依赖（正确的做法因时因地因人而异，没有标准答案）。

让我举几个具体的例子。

一个深耕中国某个三线城市商业地产十年的顾问，他脑子里关于“这条街的人流量什么时候最大”、“这个小区的居民消费习惯是什么”、“当地政府的规划思路是什么”的知识，在任何 AI 的训练数据里都找不到。这些知识是他用脚一步步走出来的，用眼睛一天天观察出来的。在可预见的未来，没有任何 AI 能替代他——不是因为 AI 不够聪明，而是因为这些数据根本不在线上。

一个在跨国公司做了二十年合规工作的法务专家，她对“这个特定行业在这个特定国家的灰色地带”的理解，对“这个监管机构的实际执法尺度”的感知，不在任何教科书或公开数据中。这些是她在无数次与监管者周旋、在无数次法律风险的刀刃上行走后积累下来的“身体知识”。

一个经验丰富的心理咨询师，她能在来访者说出第三句话的时候就感觉到“这个人真正的问题不是他说的那个”。这种直觉来自于几千个小时的面对面咨询经验，来自于对微表情、语调变化、身体语言的长期训练。这些东西不在文字记录里——即使有逐字稿，AI 也读不出那些“文字之间的东西”。

迈克尔·波兰尼在 1958 年提出了“隐性知识”的概念，一句话概括就是：“我们知道的，远比我们能说出来的多。”AI 只能学习被“说出来”（即被数字化、被写成文字、被录制成数据）的知识。所有那些“没有被说出来”的知识——经验直觉、情境判断、文化默契——都是 AI 的盲区。

所以，熊辉说的“去数据稀疏的地方”，翻译成操作语言就是：去那些需要用脚走、用眼看、用手摸、用心感受才能获取信息的地方。 在那里积累起你的独有知识库，然后——这是关键——用 AI 工具把这些独有知识的价值放大。

举个例子：那个三线城市的商业地产顾问，如果他只会用脚走、用眼看，他的服务范围就受限于他个人的时间和精力。但如果他把十年的经验沉淀成一套方法论，再用 AI 工具来辅助分析数据、生成报告、自动化日常调研——他的产能就可以突破个人极限，而他的核心竞争力（本地化的隐性知识）是任何人和任何 AI 都无法复制的。

这就是“数据稀疏”与“人机协作”两个论点的交汇处：去没有数据的地方获取独有资产，然后用 AI 的力量杠杆化这些资产。

这个策略为什么可行？因为它利用了 AI 的一个结构性弱点：AI 需要大量数据来训练，而数据的分布天然是不均匀的。热门领域数据充裕，冷门领域数据稀缺。这种不均匀性不是暂时的——它是由现实世界的物理结构决定的。你不可能把所有街道的人流量、所有会议室里的对话、所有人脑子里的直觉都变成训练数据。至少在可预见的未来不能。

所以，“去数据稀疏的地方”不是一个临时的投机策略，而是一个有结构性支撑的长期定位。

这其实也解释了为什么很多创业者天然就在做“数据稀疏区”的事——他们深入到一个具体的行业、一个具体的场景中，积累了大量一手经验，然后用技术工具来杠杆化这些经验。好的创业者从来不是在“热门赛道”上跟巨头正面竞争，而是在“别人看不上、看不见、看不懂”的地方扎根，等根扎深了再向外扩张。

人员、人才、人物

到目前为止，我们讨论了：该去哪里（数据稀疏的地方）、该怎么干活（一个人 + N 台机器）、该修炼什么能力（提问力和鉴赏力）。但还有一个更根本的问题没有回答：你要成为什么样的人？

熊辉借用他在人力资源研究中的分层框架，给出了一个简洁但深刻的三级模型：人员 → 人才 → 人物。

让我把这三个层级拆开来看，然后讨论它们在 AI 时代各自面临的命运。

人员，做的是重复性、可流程化的工作。输入明确，输出明确，中间过程可以标准化。在旧时代，这一层是劳动力市场的主体——大量的工人、职员、操作员。在 AI 时代，这一层首当其冲。不是因为 AI“抢了”他们的工作，而是因为他们做的工作本质上就是“执行明确的规则”，而执行明确的规则恰恰是计算机最擅长的事情。

人才，拥有专业技能，能解决非标准化的复杂问题。高级工程师、资深设计师、经验丰富的律师。这一层在短期内不会被 AI 取代，但面临持续的压力——因为 AI 的能力边界在不断扩张。今天 AI 做不好的事情，明年可能就能做了。如果你的价值仅仅在于“高质量执行”，那你的优势是一个不断缩小的窗口。

人物，做的是定方向、定标准、担后果的事情。他们的价值不在于亲手做了什么，而在于他们的判断和决策改变了事情的走向。一个技术总监决定采用微服务还是单体架构，一个出版人决定出版哪本书，一个基金经理决定重仓哪个行业——这些决策的质量决定了整个团队或组织的命运。

AI 可以给决策者提供大量的信息和建议。但有两件事它做不到：

第一，它不能替你做最终决定。在信息不完备、后果不可逆的真实情境中，必须有一个人说“就这么干了”。这个人需要承受不确定性的压力，需要在信息不足的情况下做出判断，需要为结果负责。这不是技术能力，这是一种心理品质和社会功能。

第二，它不能替你承担后果。当事情搞砸了，必须有一个可追责的主体出来面对。社会的运转依赖于这种可追责性——合同要有人签字，决策要有人背书，失误要有人担责。AI 可以辅助，但不能担责。

所以“人物”这一层，在可预见的未来，是 AI 最难触及的。

这并不意味着成为“人物”就可以高枕无忧。恰恰相反——AI 时代对“人物”的要求会比以前更高。因为 AI 降低了执行层的成本，决策层的杠杆效应就更大了：一个好的决策通过 AI 可以被更快、更广泛地执行，价值被放大；一个坏的决策同样会被更快、更广泛地执行，灾难也被放大。

那么，如何从“人员”或“人才”向“人物”升级？

我从熊辉的框架中提炼出三条路径：

路径一：让你的产出变成“作品”而非“作业”。 “作业”是交给别人就完事的，没人记得你做过哪些作业。“作品”是可以署名的、可以被他人引用和复用的、代表你水准的东西。同样是写代码，写一个内部 CRUD 接口是作业，写一个被广泛使用的开源工具是作品。同样是做分析，完成一份上级交代的数据报告是作业，写一篇被行业引用的深度研究是作品。作品是你能力的“可验证证明”，是你职业声誉的基石。

路径二：让你的决策有“证据链”。 不是凭感觉做决策，而是每一个关键决策都配对清晰的逻辑链——目标是什么、假设是什么、证据是什么、如何验证、如果错了怎么办。这种习惯做的不只是提高决策质量，更重要的是它让你的决策过程变得“可审计”——别人可以看到你的思维过程，理解你的逻辑，信任你的判断。在一个充斥着 AI 生成内容的世界里，“可追溯的人类判断”本身就是稀缺品。

路径三：学会“讲故事”。 这听起来很软，但在实践中极其重要。技术能力决定了你能看到什么，叙事能力决定了别人能不能看到你看到的东西。一个技术总监如果不能用清晰的叙事把架构决策的逻辑传达给CEO，他的判断力再强也无法影响组织的方向。一个创业者如果不能用引人入胜的故事让投资人理解他的愿景，他的洞察力再深也无法转化为资源。从“人才”到“人物”的跃迁，往往不是因为你变得更聪明了，而是因为你学会了让自己的判断力被更多人看见和信任。

那么，明天做什么？

讨论了这么多，让我试着把熊辉的框架收束为几条可以立刻执行的操作。

第一，把“约束条件分析”变成一种思考习惯。 每当你听到一个新的技术趋势或商业机会，问自己三个问题：它依赖什么稀缺资源？谁在控制这些资源？这些约束在可见的未来能被解除吗？这个习惯不只适用于 AI——它适用于你职业生涯中遇到的几乎所有重大判断。

第二，从今天开始练习“编排”而非“执行”。 找一个你手头的实际任务，尝试把它拆解成多个子任务，分配给 AI 工具并行执行。不需要很复杂——哪怕只是让一个 AI 写代码、另一个 AI 写测试，然后你来整合。重要的是亲身体验一下“一个人 + N 台机器”的工作方式是什么感觉。你会发现瓶颈不在 AI 的能力上，而在你拆解和验证的能力上。

第三，开始做“多模型交叉验证”。 你正在处理的某个问题，同时问两到三个不同的 AI 模型。认真对比它们的回答，记录差异和你的判断。把这个练习变成每天的习惯——就像品酒师每天做味觉训练一样。一两个月后，你对 AI 输出质量的判断力会有质的提升。

第四，找到你的“无人区”。 审视你的工作领域，问自己：哪些知识是高度本地化的、高度隐性化的、高度情境依赖的？哪些信息是你用脚走出来、用经验积累出来、但从来没有被系统化的？那就是你的无人区。每周花一两个小时，把这些知识开始沉淀——写下来、建模型、做框架。这些就是你在 AI 时代最宝贵的资产。

第五，把你的下一份产出变成一件“作品”。 不管你的本职工作是什么，找一件正在做的事情，把它从“完成任务”的标准提升到“值得署名”的标准。写一份能被同行引用的报告，做一个能被团队复用的工具，设计一套能被后人参照的流程。一件作品胜过一百份作业。

这五条操作看起来很朴素，没有一条需要“等 AI 再发展两年”才能开始。事实上，大多数真正有价值的职业动作都不需要等——需要等的，往往是你下定决心的那一刻。

尾声

我在最开始说，“AI 会不会取代我的工作”是一个被问错了的问题。那个正确的问题是：“在 AI 时代，衡量职业价值的尺子会变成什么样？”

熊辉的《太学》演讲，实质上就是在描述这把新尺子的刻度：

第一个刻度：你是否理解技术背后的约束？ 看穿表象、直抵瓶颈的能力，在任何时代都稀缺。

第二个刻度：你能不能“杠杆化”你的认知？ 从一个人做一件事，到一个人编排 N 件事——这是产能的量级跃升。

第三个刻度：你能不能提出好问题、做出好判断？ 在答案泛滥的时代，好问题和好判断才是真正的稀缺资源。

第四个刻度：你是否占据了数据稀疏的高地？ 在 AI 能力最弱的地方建立壁垒，然后用 AI 放大壁垒的价值。

第五个刻度：你是“人员”、“人才”还是“人物”？ 执行可以被自动化，专业技能可以被侵蚀，但做决定并承担后果——这是人类社会运转的基石，AI 无法替代。

这五个刻度构成了一把新的尺子。用这把尺子量一量自己，你就知道你现在站在哪里、应该往哪里走。

最后说一句。

每一次技术变革都会引发恐慌。蒸汽机来的时候，人们害怕机器会让所有人失业。电力普及的时候，人们害怕工厂会吞噬城市。互联网兴起的时候，人们害怕信息洪流会淹没一切。但回头看，这些变革最终不是毁灭了人的价值，而是重新定义了什么是有价值的。

AI 时代也会如此。

旧的价值会贬值，新的价值会浮现。关键在于——你是在旧地图上寻找旧的宝藏，还是拿起新的尺子，去绘制一张属于自己的新地图。

1839 年，达盖尔发明了摄影术。当时的画家们恐慌了——“绘画已死”。但回头看，摄影术杀死的不是绘画本身，而是绘画中“忠实记录现实”的那个功能。绘画失去了一个旧的理由，但找到了更多新的理由——印象派、抽象派、表现主义，都是在摄影术之后才涌现的。画家不再需要比相机画得更“像”，反而可以去探索只有人类的感知和想象力才能触及的领域。

AI 之于知识工作，很可能就是摄影术之于绘画。它会杀死一些旧的价值，但也会释放出大量我们现在还看不清楚的新价值。

熊辉的那句话值得最后再说一遍：“AI 并不仅仅是技术洪流，更是一场’资源—劳动—能力’价值链的重新洗牌。”

洗牌之后，新的牌局已经开始。而你手里的牌是什么，取决于你此刻的选择。

“别只盯着模型多大、参数多少，真正决定 AI 未来的是资源约束、劳动形态和个人能力的重新定价。” — 熊辉

引子：一场不谈模型的 AI 演讲

如果你在过去两年参加过任何一场 AI 行业分享，你大概率听到的是这样一套叙事：先放一张模型参数量指数增长的曲线图，然后现场演示 AI 写诗、画画或者三分钟搭一个网站，最后留下一句“未来已来”。观众鼓掌离场，回到工位上继续焦虑。

2024年，百度前副总裁、罗格斯大学终身教授熊辉站在《太学》的讲台上，做了一场完全不同的演讲。

他没有展示最新的 benchmark，没有秀炫目的 Demo，甚至没有讨论哪家大模型又刷新了排行榜。他讨论的是一个更冷门、但可能更重要的问题：当 AI 改写了生产方式之后，普通人的职业价值锚点在哪里？

这个问题之所以值得认真对待，是因为绝大多数关于 AI 的公共讨论都在谈“AI 能做什么”——它能写代码、能画画、能通过律师资格考试——却很少有人系统地思考另外两个问题：“AI 的瓶颈在哪里？”以及“在一个 AI 无处不在的世界里，人的价值坐标系应该怎么重新校准？”

熊辉的演讲，本质上就是在回答这两个问题。他给出了一套由五个支点构成的分析框架：资源约束、新型劳动体、核心能力重估、数据稀疏地带、以及个人价值的重新分层。这套框架的独到之处在于——它不是从技术出发，而是从经济学和组织行为学出发来审视 AI 对职业的影响。换句话说，他不关心 AI 有多强，他关心的是这股力量撞上现实世界的物理定律和经济规律之后，会被塑造成什么形状。

这篇文章是对这场演讲的一次深度展开。我会沿着熊辉的五个核心论点逐一拆解，但不仅仅是复述——在每个论点上，我都会从不同的学科拉来证据做交叉验证，看看它到底能不能站住脚。

一、算力的尽头不是芯片，是电力

1.1 被忽略的物理层

在 AI 的公共叙事里，有一个奇怪的断层：人们津津乐道于 GPT 的参数量从 1750 亿涨到了万亿级别，但很少有人追问一个朴素的问题——训练和运行这些模型的电，从哪来？

熊辉在《太学》里首先提醒听众：当今最热的“大模型竞赛”并非纯粹的技术军备，而是一场受电力和基础资源约束的产业冲刺。这个判断听起来不够酷，但它指向的是一个比模型架构更底层、更硬核的现实。

让我们看几个数字。国际能源署（IEA）2024年的报告指出，全球数据中心的用电量已经超过了整个法国的全年用电量。而到2026年，仅 AI 相关的计算任务就可能让全球数据中心的电力消耗再翻一倍。英伟达的 H100 GPU 单卡功耗达到 700 瓦，一个装满 H100 的服务器机架功耗高达 40 千瓦——这相当于十几个普通家庭的用电量集中在一个不到两平方米的机柜里。再换一个更直观的尺度：你每向 ChatGPT 提一个问题，消耗的电力大约是一次谷歌搜索的十倍。当全球数十亿用户每天都在跟 AI 对话时，这个十倍会变成一个天文数字。

这不是一个可以靠“技术迭代”轻松解决的问题。芯片可以越做越小、越做越快，但热力学第二定律不讲情面：计算必然产生热量，散热必然消耗能量，能量必然来自某种物理过程。你可以优化软件算法，可以改进芯片架构，但你绕不开发电厂、输电网和冷却系统。

1.2 历史的回声：杰文斯悖论

熊辉的这个判断并不是独创——它实际上在重述一个有 160 年历史的经济学洞察。

1865年，英国经济学家威廉·斯坦利·杰文斯出版了《煤炭问题》一书。当时的主流观点认为，瓦特改良蒸汽机大幅提高了煤的使用效率，所以英国的煤炭消耗应该会下降。杰文斯却得出了一个反直觉的结论：效率的提升不会减少资源消耗，反而会因为使用成本降低、应用场景扩大而导致总消耗上升。

这就是著名的杰文斯悖论。它在此后的 160 年里反复被验证：电力越便宜，用电量越大；汽车油耗越低，人们开得越远；互联网带宽越高，数据流量越多。

AI 领域正在上演同样的戏码。大模型的推理效率确实在快速提升——同样的任务，今天需要的算力可能只有一年前的十分之一。但杰文斯会告诉你，这只会让更多的人、更多的场景开始使用 AI，最终推高而非降低总算力需求。当每个人的手机里都跑着一个个人助手，当每辆车都在做实时决策，当每家工厂的每条产线都由 AI 优化——届时的电力需求将是今天的数倍甚至数十倍。

1.3 谁在布局“发电厂”

理解了这个约束，你就能看懂一些看似反常的商业动作。

微软在2024年重启了三里岛核电站的部分机组，专门为其数据中心供电。亚马逊和谷歌在大力投资核聚变初创公司。OpenAI 的 CEO 萨姆·奥特曼个人投了超过 3.75 亿美元给核聚变公司 Helion Energy。这些科技巨头不是突然对环保产生了热情——他们是意识到，在 AI 时代，谁控制了稳定、廉价的电力供应，谁就拥有了最硬的护城河。

这就好比 19 世纪的铁路时代。大家都在讨论火车跑得有多快、能拉多少人，但真正赚大钱的不是造火车的，而是铺铁轨的、挖煤矿的、炼钢铁的。技术的光芒总是吸引最多的注意力，但底层基础设施才是决定格局的力量。

1.4 给职场人的启示

这个判断对普通人的职业选择意味着什么？

第一层含义是投资视角：如果你在考虑投资或创业方向，别只追最亮眼的模型热点。与 AI 供电、冷却、能源管理、电网调度相关的“环节型机会”，可能拥有比模型公司更持久的竞争优势。

第二层含义更深：它训练了一种看问题的方式。 每当你面临一个技术趋势，不要只看技术本身，要追问“它的物理约束是什么？”、“它依赖什么稀缺资源？”、“谁在控制这些资源？”把视角下沉一层，你的决策就不容易被表层噪音牵着走。

这种思维方式在经济学里有一个名字，叫“约束条件分析”。任何一个系统的产出，最终不是由它最强的部分决定的，而是由它最薄弱的环节决定的——这就是“木桶原理”在产业层面的应用。AI 最薄弱的环节不是算法，不是数据，而是电力和基础设施。看到这一点，你就比 90%讨论 AI 的人多了一个维度的认知。

二、新型劳动体：一个人加 N 台机器

2.1 从“包工制”到“代理人制”

英国工业革命之前，纺织业的主流生产方式叫“包工制”（putting-out system）：商人把原材料分发给农村家庭，每家每户用手工纺车织布，再把成品交回商人。一个商人可能同时管理几十个家庭作坊，但每个作坊的产出完全取决于织工个人的手速和体力。

蒸汽机和珍妮纺纱机改变了这一切。工厂制度诞生了——工人不再在家单干，而是集中到工厂里，围绕机器协作。一个工人操作一台机器，产出是以前手工的几十倍。但请注意，真正改变的不是工人的能力，而是劳动的组织形式。

熊辉在演讲中提出的“人机协作新劳动体”概念，本质上是在描述第三次劳动组织形式的变革：不是人围着机器转，而是人指挥一群 AI 代理（Agent）组成的数字团队，同时推进多条工作流。

如果说工业革命把“一个人做一件事”变成了“一个人操作一台机器做一件事”，AI 时代正在把它变成“一个人编排 N 个代理做 N 件事”。

2.2 认知杠杆：比体力杠杆更强大

为什么这个变化如此重要？因为它创造了一种前所未有的“认知杠杆”。

我们都熟悉金融杠杆的概念：你用 1 万块钱的本金，借 9 万块钱的贷款，去投资一个 10 万块钱的项目。如果项目涨了 10%，你的收益不是 10%，而是 100%——这就是杠杆的力量。

AI 代理提供的是认知层面的杠杆。传统的知识工作者——程序员、律师、分析师——他们的产出受限于个人的认知带宽：一次只能想一个问题，一天只有那么多小时的高效思考时间。但如果你能把自己的判断力和决策能力“杠杆化”——通过明确的任务拆解和质量标准，让多个 AI 代理并行执行——你的产出就不再受限于你个人的认知带宽，而是受限于你“编排和验证”的能力。

这就像一个优秀的电影导演。导演不亲自演戏、不亲自打光、不亲自写配乐，但他协调几百人的团队，把自己的艺术判断力杠杆化到了极致。最终电影的质量取决于导演的视野和判断力，而不是他个人能否同时做所有事。诺兰不会比他的摄影师更擅长操作摄影机，但《奥本海默》之所以是诺兰的电影而不是任何其他人的电影，是因为每一个镜头都服务于他脑子里的那个叙事。

但杠杆是一把双刃剑。金融杠杆用好了叫“以小博大”，用砸了叫“爆仓”。认知杠杆也一样：如果你的判断是错的，多个 AI 代理会以高效率帮你把错误放大到每一个角落。这也是熊辉特别强调“证据链”的原因——没有验证机制的认知杠杆，等于在没有刹车的跑车上踩油门。

2.3 面试的新常态

熊辉做了一个很有画面感的预测：未来你去面试时，带去的不只是简历，而是一整支由多台代理组成的“数字团队”。

这话乍一听像科幻，但仔细想想，类似的事情已经在发生。在自由职业平台上，一个聪明的设计师已经不是单打独斗了——他用 Midjourney 做概念图，用 Figma AI 做布局，用 ChatGPT 写文案，用自动化工具批量交付。他一个人的产出抵得上以前一个小型设计工作室。甲方在意的不是他一个人能画多快，而是他能不能在规定时间内交付高质量的完整方案。

弗雷德里克·泰勒在 1911 年出版了《科学管理原则》，核心思想是把复杂工作分解成标准化的简单步骤，让每个工人只负责一步。这是“拆解工作、分配给人”。而现在发生的是一种逆向的泰勒主义——拆解工作、分配给 AI，而你是那个做拆解和质量把控的人。

2.4 三个可以量化的指标

熊辉给出了三个衡量“人机协作能力”的指标，我觉得非常实用：

并行度：同一时间你能高效管理多少条自动化工作流？这不是说你同时开十个聊天窗口就叫并行。真正的并行意味着每条工作流都有清晰的目标、明确的验收标准、以及你知道在什么节点需要介入。就像一个空中交通管制员，同时引导多架飞机着陆，不是因为他眼睛多，而是因为他有雷达系统和标准化的通信协议。

证据链：每条流程都能输出日志、测试结果和回滚方案吗？AI 的输出是概率性的，这意味着它有时会出错——而且出错的方式可能很隐蔽。如果你不能要求每条工作流都留下可追溯的证据，你就像一个不看仪表盘的飞行员：大部分时候没事，但出事就是大事。

迭代速度：从需求拆解到第一轮可验证结果，你把时间压到多短？在 AI 时代，“快速试错”不再是一种工作理念，而是一种硬性的竞争要求。你的迭代周期越短，你在同样的时间窗口内能探索的方向就越多，找到正确解的概率就越大。

这三个指标看起来像是技术管理的话术，但它们背后的逻辑适用于任何职业。一个市场营销人员同时用三个 AI 工具测试不同的文案方案，一个投资分析师让多个模型独立评估同一个标的——底层逻辑都是并行度、证据链和迭代速度。

三、核心能力重估：提问力与鉴赏力

3.1 苏格拉底的复仇

公元前 399 年，雅典法庭以“腐蚀青年”和“不敬神明”的罪名判处苏格拉底死刑。但苏格拉底留下了一种比任何具体知识都更持久的遗产——追问的方法。

苏格拉底的核心洞察是：真正的智慧不在于知道很多东西，而在于知道什么是自己不知道的，以及如何通过系统的追问来逼近真相。他发明的“诘问法”（Socratic method）本质上就是一种提问技术：通过反复追问前提、暴露矛盾、迫使对方（或自己）不断修正判断。

2400 年后，这种能力正在经历一次戏剧性的价值重估。

在大模型“博闻强识”的年代——它们读过的书比任何人一辈子能读的都多——“知道很多东西”已经不值钱了。你问 ChatGPT 任何领域的基础知识，它都能给你一个 80 分的回答。但它无法告诉你，哪些问题才是真正值得问的。 这正是熊辉反复强调“提问力”的原因：在信息过剩的时代，瓶颈不是答案的供给，而是好问题的生成。

3.2 “侍酒师”类比

让我用一个类比来说明“鉴赏力”为什么重要。

想象一个世界，所有人都能用 AI 酿造出品质不错的葡萄酒——成本低廉、产量巨大。在这个世界里，什么人最有价值？不是酿酒师（因为 AI 已经能做），而是侍酒师（sommelier）——那个能在 1000 瓶看似差不多的酒里，准确判断哪瓶最适合某道菜、某个场合、某种心情的人。

鉴赏力就是这种“侍酒师”能力。当 AI 能在几分钟内生成十篇文章、二十张设计稿、五十段代码时，生产不再稀缺，判断才稀缺。 谁能在一堆 AI 产出中快速识别出最好的那个？谁能说清楚“好”的标准是什么？谁能发现 AI 输出中那些隐蔽的错误？这个人就是价值最高的人。

查理·芒格说过一句话：“反过来想，总是反过来想。”如果我们反过来理解理查德·费曼的名言“What I cannot create, I do not understand”（我不能创造的东西，我就不理解），在 AI 时代它应该被改写为：“What I cannot evaluate, I do not understand”——我不能评判的东西，我就不理解。

3.3 交叉验证：一种实用的鉴赏力训练法

熊辉在演讲中分享了一个他自己的方法，我觉得非常聪明：让多个模型对同一主题“交叉答题”。

具体操作是这样的：你把同一个问题分别抛给 GPT、Claude、Gemini，然后对比三个模型的回答。如果三个模型的答案高度一致，说明这个领域的数据覆盖充分、模式清晰，AI 的回答大概率可靠。但如果三个模型给出了截然不同的答案，甚至互相矛盾——这就有意思了。

模型的“集体困惑”往往指向了人类知识的真正盲区。 这些盲区可能是因为该领域的训练数据不足，可能是因为问题本身具有内在的争议性，也可能是因为这是一个新兴的、尚未被系统化研究的领域。无论是哪种情况，这个“盲区”本身就是一个极有价值的信号——它告诉你，这里有值得深挖的矿脉。

这个方法巧妙地把鉴赏力的训练变成了一个可操作的日常习惯。你不需要成为某个领域的专家才能开始判断 AI 输出的优劣——你只需要学会让多个“专家”互相检验，然后从差异中读出信号。

丹尼尔·卡尼曼在《噪声》一书中讨论过一个相关的概念：独立判断的聚合。如果多个独立的判断者对同一个问题给出了相似的答案，这个答案的可信度就远高于任何单个判断者的结论。这正是多模型交叉验证的理论基础——每个大模型就像一个独立的“判断者”，它们的训练数据不同、架构不同、偏好不同，但如果它们趋向一致，就值得信赖。

3.4 三步练习法

基于熊辉的框架，我总结了一个每天可以做的练习：

第一步，每天写下三个“机器答不好的问题”。这比听起来要难。大多数人一开始写出来的都是“太笼统”的问题——比如“人生的意义是什么？”这不是好问题，因为它没有可评估的标准。好的“机器答不好的问题”应该是具体的、可验证的，但又处于 AI 知识的边界地带。比如：“我所在城市的某个老旧小区，未来五年的房价会怎么走？”——这个问题足够具体，但 AI 的训练数据几乎不会覆盖到如此细粒度的本地信息。

第二步，让两款模型同时作答，对比差异。不是为了找出“谁对谁错”，而是为了理解“它们在哪里产生了分歧、为什么会有分歧”。分歧本身就是信息。

第三步，记录你对答案优劣的判断依据，并迭代你的提示词。这一步最容易被跳过，但它恰恰是最重要的——因为只有当你把判断依据显性化、写下来，你才能逐渐建立起自己的“鉴赏力标准”。下一次遇到类似的问题，你就不再是凭感觉判断，而是有据可依。

四、去数据稀疏的无人区

4.1 AI 是水，数据是地形

如果要用一个自然现象来类比 AI 的渗透路径，我会选择“水”。

水总是从高处流向低处，沿着阻力最小的路径前进。AI 也一样——它最先、最深入、最彻底地渗透到那些数据最丰富、模式最清晰、评价标准最明确的领域。机器翻译、图像识别、棋类游戏、标准化代码生成——这些领域的共同特点是：训练数据海量，正确答案清楚，AI 可以通过大量练习达到甚至超过人类水平。

但水流不到高地。那些数据尚未被系统化收集、价值评价仍然混沌、正确答案因人因时而异的领域，就是 AI 流不到的“高地”——也是熊辉所说的“数据稀疏的无人区”。

4.2 蓝海与红海的另一种理解

W·钱·金和勒妮·莫博涅在 2005 年出版了《蓝海战略》，提出企业不应该在现有市场（红海）里跟对手血拼，而应该创造全新的市场空间（蓝海）。这个框架在 AI 时代获得了一层新的含义：

AI 能力最强的地方，就是最拥挤的红海。 当翻译、客服、基础编程、模板化写作都能被 AI 高质量完成时，还在这些领域跟 AI 竞争的人，就像在红海里跟鲨鱼抢鱼吃——理论上你也能抓到鱼，但效率和成本都没法比。

AI 能力最弱的地方，就是蓝海。 这些地方不是因为不重要而数据稀疏，而是因为太复杂、太本地化、太依赖人际信任和隐性知识，以至于还没有人（或者 AI）把它们系统化。

举几个例子来说明数据密集区和数据稀疏区的差异：

在翻译领域，商品短描述的翻译早已是 AI 的强项——海量的平行语料、模板化的句式、明确的质量标准。但文化类长文的翻译、带有地方文化隐喻的营销文案、需要理解品牌调性和受众心理的本地化——这些 AI 做得磕磕绊绊，因为训练数据里这类高质量样本极为稀少。

在编程领域，标准的增删改查（CRUD）和脚手架代码，AI 几乎可以一键生成。但跨系统架构迁移——比如把一个运行了十年的银行核心系统从单体架构迁移到微服务——这涉及到对业务规则的深度理解、对遗留代码的考古式发掘、以及对风险的精准评估。这些知识绝大部分存在于少数资深工程师的脑子里，从未被写成文档，更不可能出现在 AI 的训练数据中。

在咨询领域，通用的行业分析报告已经可以让 AI 在几分钟内生成一份 80 分的初稿。但深入某个细分市场的田野调查——走进工厂车间、坐在会议室里观察客户的决策过程、通过一手访谈挖掘出行业的真实痛点——这是 AI 无论如何做不到的，因为这些信息根本不在互联网上。

4.3 一个简单的判别法

怎么判断你所在的领域是“数据密集的红海”还是“数据稀疏的无人区”？熊辉给了一个非常简洁的判别法，我把它稍作改良，变成三个自问自答：

第一问：这个领域的训练数据是否已经足量且高质量？ 如果你做的事情，在 Stack Overflow、GitHub、Wikipedia 或任何大型公开数据集上有海量的高质量样本，那你就是在红海里。

第二问：这个领域的“正确答案”是否明确？ 如果你做的事情有清晰的对错标准（代码能不能跑通、翻译是否准确、图像是否匹配描述），AI 就能通过不断训练来逼近正确答案。但如果“好”的标准模糊、因人而异、依赖上下文——比如“这个产品设计是否优雅？”、“这个商业决策是否明智？”——那 AI 就缺乏明确的优化目标。

第三问：这个领域是否依赖大量的隐性知识和本地信息？ 隐性知识（tacit knowledge）是迈克尔·波兰尼在 1958 年提出的概念——“我们知道的比我们能说出来的多”。一个经验丰富的医生“看一眼就知道这个病人不对劲”，一个资深销售“感觉这个客户快要签约了”——这些判断依赖的是大量无法文字化的经验和直觉，AI 的训练数据里几乎不可能有这些。

如果三个问题的答案分别是“否、否、是”，那恭喜你——你大概率处在一个数据稀疏的无人区，这里正是个人和小团队能跑赢 AI 巨头的窗口期。

4.4 Netflix 的启示

Netflix 的创业故事是“去无人区”策略的经典案例。

1997 年，里德·哈斯廷斯创办 Netflix 时，视频租赁市场已经有一个巨无霸——百视达（Blockbuster），在全球拥有 9000 多家门店。如果 Netflix 选择在同一个赛道上竞争——开更多的门店、拿更好的位置——它一定会输。

哈斯廷斯选择了一个当时看来非常边缘的市场：通过邮寄 DVD 来租赁电影。这个市场太小、太慢、太不方便，百视达根本看不上。但正是因为看不上，百视达从来没有认真收集过“邮寄租赁”的数据、从来没有优化过这个流程、从来没有理解过这群用户的需求。

Netflix 就在这个“数据稀疏的无人区”里积累了独一无二的用户数据和运营经验，然后当宽带技术成熟的时候，顺势转型为流媒体——而此时百视达已经来不及追赶了。

这个故事的教训不是“要颠覆巨头”，而是：在巨头不在意的地方建立你的数据壁垒和能力壁垒，等待时机把这些壁垒转化为更大的优势。

在 AI 时代，这个策略同样适用。去那些 AI 还做不好的地方，去那些训练数据还不够的地方，去那些需要“脚踏实地”才能收集信息的地方——在那里积累你的独特资产，然后用 AI 工具把这些资产的价值放大。

知道该去哪里是一回事，知道自己该成为什么样的人是另一回事。找到了无人区，你还需要一个方向盘——一个关于“个人价值层级”的清晰认知，才能决定你在无人区里做什么、做到什么程度。这就是熊辉框架的最后一块拼图。

五、从“人员”到“人物”：个人价值的重新分层

5.1 德鲁克早就说过

彼得·德鲁克在 1959 年就提出了“知识工作者”（knowledge worker）的概念，预言未来的经济将由脑力劳动而非体力劳动驱动。六十多年后，德鲁克的预言不仅实现了，而且正在进入第二阶段的演变。

第一阶段（1960-2020）：知识工作者取代了体力工作者成为经济的主力。程序员、分析师、设计师、咨询顾问——这些人靠“知道什么”和“能做什么”获取报酬。

第二阶段（2020-）：AI 开始取代知识工作者中的“执行层”。AI 也“知道”很多东西，也“能做”很多事情——而且更快、更便宜、不知疲倦。这就迫使知识工作者不得不向上攀爬，找到 AI 无法替代的价值层级。

熊辉借用他在人力资源研究中的分层模型，给出了一个非常清晰的三级框架：

5.2 三个层级

人员：执行重复、可流程化的任务。在编程领域，这是写 CRUD 的初级程序员；在翻译领域，这是做商品短描述翻译的译员；在咨询领域，这是整理数据、制作 PPT 的分析师。这一层是 AI 冲击最直接、最猛烈的。

人才：拥有专业技能，能高质量地解决复杂问题。高级程序员、资深翻译、首席分析师。这一层不会被 AI 一夜之间取代，但会面临持续的侵蚀——因为 AI 的能力边界在不断扩张。如果你仅仅停留在“高质量执行”的层面，你的优势会随着 AI 的进步而逐渐缩小。

人物：能整合资源、制定标准、承担风险与结果的人。他们的价值不在于“做”什么，而在于“决定做什么”以及“为结果负责”。技术总监决定架构方向，出版人决定出版什么书，基金经理决定投什么标的。AI 可以提供信息和建议，但做最终决定并承担后果——这是 AI 无法替代的，因为社会的运转需要可追责的主体。

纳瓦尔·拉维坎特在《纳瓦尔宝典》中有一个相似的表述：“不要在意一小时能赚多少钱，而要追求那些无法用时间来衡量的产出。”人员的价值按小时计费，人才的价值按项目计费，而人物的价值无法计费——因为他们创造的是标准、方向和不可替代的信任。

5.3 厨师与厨子

纳瓦尔还做过一个精妙的类比：厨师（chef）和厨子（cook）的区别。

厨子按照菜谱做菜。菜谱写什么，他就做什么。他的技能是精确执行——刀工好、火候准、摆盘美。但如果给他一堆没见过的食材，他不知道怎么办。

厨师不需要菜谱。他理解食材的底层逻辑——什么跟什么搭配、什么温度激发什么风味、什么口感满足什么心理需求。他可以面对全新的食材，从第一性原理出发，创造一道从未存在过的菜。

AI 是终极厨子——它能完美执行任何已知的“菜谱”（数据模式）。但它不是厨师——它不能面对一个全新的情境，从底层逻辑出发创造前所未有的解决方案。从人员到人物的升级，本质上就是从“厨子”变成“厨师”的过程。

5.4 三条升级路径

怎么从人员走向人物？熊辉给出了方向，我把它具体化为三条路径：

第一，把产出“作品化”。 不只是完成任务，而是把你的产出变成可以被他人直接复用的“作品”——一个开源工具、一套方法论文档、一个被广泛引用的分析报告。“作品”和“作业”的区别在于：作业交了就完了，作品会持续产生价值。每一件作品都是你能力的可验证证明，也是你在行业里的声誉资本。

第二，把决策“证据化”。 在 AI 能帮你快速生成方案的年代，“我觉得应该这样做”这种话越来越没有说服力。每一个关键决策都应该配对可验证的指标：我为什么选择方案 A 而非方案 B？评估标准是什么？预期结果是什么？如何验证？如何回滚？这种“证据化”的决策习惯不仅让你的判断更可靠，也让你在团队中建立起“这个人的判断是有据可依的”信任。

第三，把问题“故事化”。 技术问题有技术答案，但要推动一个组织采纳你的方案，你需要的不只是技术正确性——你需要让团队、客户、投资人都能理解你的思路，认同你的判断。最有效的方式就是把复杂的技术分析变成一个清晰的叙事：我们面对什么问题？我们尝试了什么？我们从失败中学到了什么？我们现在的方案为什么能行？

举个例子：同样是向管理层提议引入微服务架构，一种说法是“微服务能提高系统的可扩展性和容错性”——正确但无感。另一种说法是“上个月大促期间，订单系统的崩溃导致公司损失了 300 万；如果我们在六月份之前把订单模块拆成独立服务，下次大促时即使某个模块出了问题，其他模块照常运转，我们不会再丢这 300 万”——同样的技术判断，但包裹在了一个有痛感、有数字、有时间线的故事里。好的叙事能力让你的判断力被看见、被理解、被信任——这是从“人才”跃升到“人物”的关键一步。

六、行动清单：把框架落到明天的工作

理论再好，不能落地就是空谈。以下是四个“明天就能做”的具体操作：

操作一：使用多模型交叉答题。 对你正在处理的某个工作问题，同时让 GPT 和 Claude（或其他模型）各给出一份回答。花 15 分钟对比它们的差异，记录你的判断。坚持一周，你对 AI 输出质量的感知力就会有明显提升。

操作二：建立“证据链模板”。 从今天开始，你提交的每一个方案、每一个 PR、每一份报告，都附上四个要素：目标是什么→怎么测试→观测到了什么→如果失败怎么回滚。这不只是给别人看的——它会倒逼你自己把思考做得更严密。

操作三：每周一题“无人区探索”。 选一个你工作领域中数据稀疏的议题——可能是某个本地法规的特有流程，可能是某类客户的独特需求模式——做一次深度调研。不需要多长，一两个小时就够。关键是把调研结果沉淀下来，逐渐建立你的“独有资产库”。

操作四：跑一条全自动并行流水线。 用你手头的 AI 工具（Cursor、Codex、ChatGPT 都行），尝试让两条任务同时推进。比如一条在写代码，另一条在写测试；或者一条在做数据分析，另一条在生成可视化。不需要完美，重要的是亲身体验“一个人 + N 台机器”的产能扩张是什么感觉。

结语：四根坐标轴

回到文章开头的问题：当 AI 改写了生产方式之后，普通人的职业价值锚点在哪里？

熊辉的《太学》演讲给出了四根坐标轴：

第一根轴：看见资源约束。 穿透技术的光环，看到底层的物理和经济约束，你就能找到“硬价值”——那些不因模型更新而贬值的东西。

第二根轴：组织人机协作。 从“一个人做一件事”升级到“一个人编排 N 个代理做 N 件事”，你的产能才能突破人力极限。

第三根轴：锻造提问与鉴赏力。 在信息过剩的时代，生产能力不再稀缺，判断能力才稀缺。能提出好问题、能评判答案质量的人，将立于 AI 最难攻破的高地。

第四根轴：走进数据稀疏的无人区。 去 AI 还做不好的地方，积累你的独特资产，然后用 AI 工具把这些资产的价值放大。

带着这四根坐标轴，你就不必在每一次模型更新的浪潮里被动追随，也不必在“AI 要取代我了”的焦虑中消耗精力。你有了自己的参照系，可以主动绘制自己的职业图谱。

熊辉在演讲最后说的一句话，我觉得是最好的总结：“AI 并不仅仅是技术洪流，更是一场’资源—劳动—能力’价值链的重新洗牌。”

洗牌意味着旧的座次被打乱，但也意味着——新的座次还没有被确定。

1850 年代的人不知道“电气工程师”会成为一个职业。1990 年代的人不知道“产品经理”和“全栈工程师”会成为最热门的岗位。同样，2026 年的我们也无法准确预测十年后的职业形态。但我们可以看清一件事：那些能穿透技术表象看见底层约束的人、能编排人机协作而非单打独斗的人、能提出好问题并做出好判断的人、敢走进数据稀疏无人区的人——无论未来的职业叫什么名字，他们都会在那里。

1

特别说明：此文由ChatGPT生成，后续由我本人编辑、修改而成。

0 引言：从驾驶员到塔台

1956 年，美国联邦航空管理局面临一个前所未有的难题：随着喷气式客机的普及，天空中的飞机数量激增，传统的目视管制方式——地面人员拿着望远镜盯着跑道——已经无法保障安全。他们的解决方案不是训练更多的飞行员，而是建立了一个全新的角色：空中交通管制员。管制员不驾驶任何一架飞机，但他同时监控数十架飞机的航线，协调冲突，确保每一架都安全着陆。从此，航空业的核心范式从“驾驶”转向了“调度”。

七十年后，软件开发正在经历类似的转变。

如果你用过 Cursor，你体验的是一种“副驾驶”模式：你坐在驾驶位写代码，AI 坐在旁边提建议。你输入一行，它补全下一行；你描述需求，它在你眼前修改文件。你始终“在环内”（Human-in-the-loop），每一步都亲眼看到、亲手确认。这很好，但它有一个根本限制——你一次只能飞一架飞机。

OpenAI Codex macOS App 提供了另一种可能：你从驾驶员变成了塔台。你不再逐行指导 AI 写代码，而是给出高层意图——“为这个项目添加用户管理模块”——然后 Codex Agent 在隔离环境中自主完成整个任务：分析代码库、规划方案、生成代码、运行测试，最终交给你一份完整的 diff 或 Pull Request。在 Codex 里，你可以同时启动多个 Agent 线程——一个在添加新 API，另一个在修复 Bug，第三个在生成测试——就像管制员同时引导多架飞机着陆。

这不是科幻畅想。OpenAI API 和开发者平台工程负责人 Sherwin Wu 在一次播客中透露：OpenAI 内部 95% 的工程师每天都在用 Codex，几乎 100% 的代码最初由 AI 生成。工程师们经常同时管理 10 到 20 个 Codex 线程并行推进，而使用 Codex 更多的工程师，提交的 PR 数量高出 70%。“从驾驶员到塔台”已经不是比喻——它正在 OpenAI 内部发生。

但当你从驾驶舱走上塔台，一个新的问题随之出现：你怎么知道每架飞机都在正确的航线上？

在 Cursor 里，答案很简单——你看到每一行代码在你眼前生成，不对就立刻纠正。但在 Codex 里，Agent 是在后台自主工作的，你不可能盯着每一行。这时候，你需要的不是更好的眼力，而是更好的“雷达系统”：测试覆盖率是你的雷达屏幕，CI 流水线是你的预警系统，AGENTS.md 中的项目规范是你画好的航线。这些基础设施在以前是“锦上添花”的好习惯，在 Agent 式编程时代则变成了“没有就不能起飞”的硬性前提。

换一种说法：你的工程基本功不是被 AI 取代了，而是被 AI 放大了。基础好，效率倍增；基础差，混乱也倍增。

本指南面向有经验的 Java 后端工程师，假定你已熟悉 IDE 和大语言模型的基本用法。我们不会讲“什么是 Prompt”，而是聚焦于：如何在 Codex 中高效地委派任务、管理多个 Agent、以及建立可靠的验证闭环——从驾驶员思维，切换到塔台思维。

1 Codex 全景：不止是一个 App

在深入具体操作之前，有必要先鸟瞰一下 Codex 的全貌。

很多人第一次听说 Codex 时，以为它只是一个 macOS 桌面应用。这就像 1990 年代的人第一次听说“互联网”时，以为它只是“能发邮件的东西”。实际上，Codex 已经发展为一个多形态的产品家族——就像同一支军队的陆海空天四个军种，共享同一套指挥体系（codex-1 模型 + AGENTS.md 规范），但适配不同的作战环境。

1.1 四种形态

Codex App（macOS 桌面应用）——本文的主角。图形化界面，支持 Worktree / Cloud 多线程并行，内置 Review 面板和终端。如果你喜欢可视化操作，这是最直观的入口。

Codex CLI（开源命令行工具）——终端党的最爱。一行命令就能启动 Agent：codex "为 UserService 添加分页查询"。开源在 GitHub（github.com/openai/codex），你可以查看源码、提交 Issue，甚至贡献代码。CLI 也是 CI/CD 集成的基础——后面的“团队协作”一章会详细讨论。

Codex IDE 扩展（VS Code / Cursor 插件）——在编辑器侧边栏直接使用 Codex Agent，无需切换窗口。它把 Codex 的异步 Agent 能力嵌入了你最熟悉的开发环境。对于已经在用 Cursor 的开发者来说，这意味着你可以在同一个 IDE 里同时使用 Cursor 的实时补全和 Codex 的后台 Agent。

Codex Web（浏览器版）——通过 chatgpt.com/codex 访问，无需安装任何软件。连接你的 GitHub 仓库后，直接在浏览器里委派任务、审查 PR。适合不在工位时快速处理紧急任务，或者团队中非开发角色（如 PM）查看 Agent 工作进度。

1.2 codex-1：专为编程优化的推理模型

驱动所有四种形态的是同一个引擎：codex-1——一个基于 o3 优化的软件工程专用模型。

与通用的 GPT 系列不同，codex-1 在三个方面做了专门强化：第一，深度代码推理——它能理解大型代码库的全局架构，而不仅仅是当前文件的上下文；第二，工具使用——它原生支持读写文件、执行 Shell 命令、运行测试，而不是简单地“生成文本”；第三，可验证输出——它会引用终端日志、测试结果作为自己工作的证据，而不是要你盲目信任。

这也解释了为什么 Codex 的任务通常需要 1–30 分钟完成，而不是像 ChatGPT 那样秒回——因为 codex-1 在执行任务时会经历完整的“分析-规划-编码-测试-修正”循环，而不是一次性生成答案。

1.3 本文的聚焦

四种形态共享相同的核心概念：三种模式（Local / Worktree / Cloud）、AGENTS.md 配置、安全沙箱、Skills 技能系统。本文以 Codex App 为主线展开——它的图形界面最适合初次接触者建立直觉。但文中涉及的所有理念和技巧，同样适用于 CLI、IDE 扩展和 Web 版。在涉及关键操作时，我会顺带提及 CLI 的等价命令，方便终端用户参考。

2 三种模式：信任的光谱

管理学中有一个经典概念叫“委派阶梯”（Delegation Ladder），描述的是上级把工作交给下级时，信任和自主权的不同层级：最低一级是“我说你做，做完给我看”；中间一级是“你自己做，但在独立空间里做，做完我审查”；最高一级是“你全权负责，做完直接交付”。

Codex 的三种运行模式——Local、Worktree、Cloud——恰好对应了这条信任阶梯的三个台阶。

2.1 Local 模式：我说你做

Local 模式是信任的最低级：Agent 直接在你当前的项目目录上工作，所有修改即时生效，就像你自己在编辑文件一样。你全程看着它，随时可以叫停。

适合的场景： 改一个配置、加一行注解、快速试验一个想法——那些即使搞砸了也能用 git checkout 秒恢复的小事。

Java 项目提示： Local 模式的好处是 Agent 修改代码后，你可以直接在内置终端运行 mvn compile 或 ./gradlew build 验证——不需要额外配置依赖环境，因为所有依赖都在你的本地仓库里。

CLI 等价： codex --sandbox workspace-write "你的指令" 直接在当前目录工作，效果与 App 的 Local 模式相同。

但 Local 模式有一个明显的限制：没有隔离。Agent 的改动和你自己未提交的改动混在一起，如果它改错了关键文件，你得自己收拾残局。所以在使用前，确保你的工作区是干净的。

2.2 Worktree 模式：你自己做，做完我审查

1970 年代，丰田在制造业引入了一个激进的理念：每个工位都可以拉一根绳子叫停整条生产线（安灯系统）。这个看似降低效率的做法，实际上大幅提升了质量——因为问题在发生的瞬间就被发现和隔离，而不是等到成品出厂后才召回。

Worktree 模式体现了类似的哲学。每次启动新线程时，Codex 自动创建一个 Git worktree——你仓库的一个隔离副本。Agent 在这个独立空间里自由发挥，而你的主分支纹丝不动。做完了，你在 Review 面板里逐行审查 diff，满意了才合并；不满意，丢弃整个 worktree 就行，零成本。

这是 Codex 最核心的能力所在。 你可以同时开三个线程：

线程 1：在 UserController 中添加分页查询接口
线程 2：为 OrderService 补充单元测试
线程 3：重构 PaymentService，将硬编码的配置提取到 application.yml

三个 Agent 各自在独立的 worktree 上工作，互不干扰。这就像你同时委派了三个开发者，各自在自己的分支上干活。你只需要在他们提交 PR 时做审查。

Java 项目提示： 新的 worktree 默认不包含构建产物（target/ 目录为空）。如果 Agent 需要运行测试，你需要在 Codex 的 Local Environment 配置中设置初始化脚本：

1

mvn dependency:resolve -q && mvn compile -q

这样每次创建新 worktree 时会自动下载依赖并编译，确保 Agent 可以正常运行测试。

CLI 等价： codex --full-auto "你的指令" 启动 Auto 模式（workspace-write + on-request 审批），Agent 在工作区内自由操作。

2.3 Cloud 模式：你全权负责

2020 年，SpaceX 的猎鹰 9 号成为第一枚完全自主着陆的轨道级火箭。从发射到着陆，无需任何人类遥控操作——飞行计算机根据预设参数和实时传感器数据自行完成一切。但这不意味着工程师们在发射后就去喝咖啡了。他们事先做了大量工作：编写飞行程序、设置安全边界、模拟各种故障场景。自主执行的前提是充分的事前准备。

Cloud 模式就是 Codex 的“自主着陆”模式。Codex 在 OpenAI 的云端沙盒中克隆你的远程仓库，Agent 在完全隔离的云环境中执行任务，完成后自动提交 Pull Request。你的电脑可以关机，Agent 照样工作。

Cloud 模式有一个独特优势：Agent 可以自动执行命令。 在 Local 和 Worktree 模式中，出于安全考虑，Agent 不会自行运行 Shell 命令（比如 mvn test），需要你手动执行。但在 Cloud 的沙盒里，一切都是隔离的，可以放心让 Agent 自主构建和测试。你在 AGENTS.md 中告诉它：

1
2
3
4

## 构建与测试
- 构建命令：`mvn clean package -DskipTests`
- 测试命令：`mvn test`
- 代码格式检查：`mvn spotless:check`

Cloud Agent 会执行这些命令，确保代码编译通过、测试全绿，然后才生成 PR。就像猎鹰 9 号的飞行计算机——事前把规则定义好，执行过程完全自主。

CLI 等价： Cloud 模式目前主要通过 Codex App 和 Web 版使用。CLI 用户可以通过 codex --sandbox danger-full-access 在本地模拟类似的全自主执行（但请注意，这移除了所有安全限制，仅建议在容器化环境中使用）。

前置条件： Cloud 模式需要你提前配置 GitHub 仓库权限，并在仓库中放置 AGENTS.md 文件（第 4 章详述）。

2.4 怎么选？

Local — 无隔离，直接改本地文件。单线程，需手动确认命令执行。适合小改动，改完即生效。

Worktree — 独立 Git 工作树隔离。支持多线程并行，需手动确认命令执行。适合中等功能开发，改动在工作树分支上，审查后合并。

Cloud — 完全隔离的云端沙盒。支持多线程并行，Agent 可自动执行命令。适合大型/长时间任务，完成后自动提交 PR，几乎不占本地资源。

本质上，这三种模式是信任和自主权的渐进——从“你做我看”到“你做完我审查”再到“你全权负责”。日常开发建议以 Worktree 为主——它就像丰田的安灯系统，给了 Agent 充分的行动空间，同时保留了你随时“拉绳叫停”的权力。

3 安全模型：信任，但要验证

冷战时期，美国总统里根在与苏联谈判核裁军条约时，反复引用一句俄罗斯谚语：“信任，但要验证”（Trust, but verify）。这句话精准地概括了核查机制的哲学——签了条约不等于可以高枕无忧，你需要卫星监控和实地核查来确保对方真的在裁军。

Codex 的安全模型体现了完全相同的哲学。它不是让你在“完全信任”和“完全不信”之间做非此即彼的选择，而是提供了一套分层的控制机制——你可以根据任务的风险等级，精确调节给 Agent 的自由度。

3.1 两层防线：沙箱与审批

Codex 的安全控制由两层机制协同工作：

第一层：沙箱（Sandbox）——限制 Agent 在技术上“能做什么”。在 macOS 上，Codex 使用 Seatbelt 安全策略（类似 iOS 的 App 沙盒机制），将 Agent 的文件访问限制在工作目录内；在 Linux 上则使用 Landlock + seccomp 实现类似隔离。Cloud 模式更彻底——Agent 运行在 OpenAI 托管的容器中，与你的本机系统完全隔绝。

第二层：审批策略（Approval Policy）——控制 Agent 在行动前“需不需要问你”。即使沙箱允许某个操作，审批策略也可以要求 Agent 在执行前先获得你的确认。

这就像实验室的生物安全等级（BSL）——BSL-1 是开放实验台，实验员可以自由操作；BSL-4 是全封闭负压环境，每个动作都需要严格审批。大多数日常开发在 BSL-2 就够了。

3.2 四种审批等级

Codex 提供了四种审批策略，从严到宽依次是：

read-only（只读）——Agent 只能阅读代码和回答问题，不能修改任何文件，不能执行任何命令。适合让 Agent 做代码审查或架构分析，零风险。在 CLI 中对应 codex --sandbox read-only。

on-request（按需审批，Auto 模式默认）——Agent 可以在工作区内自由读写文件和执行命令，但越界操作（访问工作区外的文件、使用网络等）需要你的批准。这是推荐的日常开发设置。在 CLI 中对应 codex --full-auto。

untrusted（不信任命令）——Agent 可以自由编辑文件，但运行任何可能产生副作用的命令前必须征得你的同意。适合当你信任 Agent 的代码能力，但不想让它自主执行 Shell 命令时使用。在 CLI 中对应 codex --sandbox workspace-write --ask-for-approval untrusted。

never（从不审批）——Agent 拥有完全自主权，不会在任何操作前停下来问你。如果再加上 danger-full-access 沙箱模式（CLI 中的 --yolo 旗标），连沙箱隔离也会移除。除非在容器化环境中，否则强烈不建议使用。 这相当于把实验室的防护门全部打开——效率最高，但出了事也没有任何缓冲。

3.3 网络访问：默认关门

一个常被忽视的安全细节：Codex 默认不允许 Agent 访问网络。

这意味着在 Local 和 Worktree 模式下，Agent 无法自行下载依赖、访问外部 API 或浏览网页。这是刻意为之的——防止 Agent 被提示注入（Prompt Injection）攻击引导去访问恶意网站。

如果你的任务确实需要网络访问（比如 mvn dependency:resolve），有几种方式开启：

• Cloud 模式：在环境配置中开启全量网络或指定域名白名单（推荐只放行 repo.maven.apache.org、registry.npmjs.org 等必要域名）
• CLI 配置：在 ~/.codex/config.toml 中为特定沙箱模式启用网络：

1
2

[sandbox_workspace_write]
network_access = true

• Web Search 缓存模式：Codex 内置了 Web Search 工具，默认使用缓存模式（从 OpenAI 维护的索引中返回结果，而非实时爬取），在提供搜索能力的同时降低了被注入攻击的风险

3.4 Java 项目的安全最佳实践

对于日常 Java 后端开发，推荐以下安全配置组合：

1. 使用 on-request（Auto）模式：Agent 在工作区内自由操作，越界需审批——在效率和安全之间取得最佳平衡
2. 保持 git status 干净再委派：确保工作区没有未提交的改动，这样即使 Agent 搞砸了，一个 git checkout . 就能回到起点
3. Cloud 模式下配置域名白名单：只放行 Maven Central、Spring Repo 等必要的依赖仓库地址，而不是开启全量网络
4. 利用版本控制作为安全网：Worktree 模式天然提供隔离——Agent 的所有改动都在独立分支上，你审查后才合并

安全不是效率的对立面。就像里根的核裁军谈判一样，信任和验证完全可以并存——关键是建立恰当的检查机制，而不是在“放飞”和“管死”之间二选一。

4 AGENTS.md：对齐问题的微缩版

人工智能研究中有一个核心难题叫“对齐问题”（Alignment Problem）：如何确保一个自主行动的智能体，真正按照你的意图行事，而不是按照它自己“理解”的意图？这个问题在 GPT 和 Claude 的层面是哲学性的，但在 Codex Agent 的层面，它非常具体：你怎么让一个自主编码的 Agent 遵循你项目的架构规范、编码风格和安全约束？

答案是 AGENTS.md。

4.1 一份“入职手册”

每个有过带新人经验的工程师都知道：新人入职第一天，你不可能通过口头嘱咐让他记住所有规矩。你需要一份文档，写清楚“我们这里怎么做事”。AGENTS.md 就是这份文档——只不过读者不是人类新人，而是 AI Agent。

它放在仓库根目录，Codex 在每次启动任务时自动读取。没有它，Agent 就像一个空降到项目的新人，只能靠猜测行事；有了它，Agent 从第一秒就知道项目用什么技术栈、怎么构建、有哪些铁律不能违反。

在 Cursor 中，你可以通过多轮对话持续纠偏——Agent 犯了错，你随时可以说“不是这样，应该那样”。但 Codex 的工作模式不同，尤其在 Cloud 模式下，Agent 是异步执行的，你没有机会中途插话。AGENTS.md 是你在“发射前”唯一的对齐窗口。写得越清楚，Agent 偏离预期的概率就越低。

Temporal 团队是一个值得参考的实践：他们在 AGENTS.md 中详细写明了如何格式化代码、如何运行 Gradle 构建和测试，确保 Codex 的每次改动都符合项目要求。

来自 OpenAI 内部的一个实验更能说明问题。Sherwin Wu 透露，OpenAI 有一个团队正在维护一个 100% 由 Codex 编写的代码库——当 Agent 没按预期工作时，团队成员不会“撸起袖子自己敲代码”，而是始终让 AI 自己编写。他们发现：Agent 失败时，问题几乎总是出在上下文不足。 解决方法不是自己重写代码，而是补充文档、添加代码注释、改进代码结构，或者在仓库中增加 MD 文件——把你脑海里的“部落知识”显式化，让模型能读到。这正是 AGENTS.md 存在的意义：它不是锦上添花的文档，而是 Agent 能否正确工作的决定性因素。

4.2 Java 项目 AGENTS.md 模板

以下是一份面向 Java 后端项目的参考模板。一个好的 AGENTS.md 回答了 Agent 最关心的五个问题：这个项目是什么？怎么跑起来？代码该怎么写？什么不能碰？怎么验证？

# 项目说明

## 概述
这是一个基于 Spring Boot 3.2 的电商后端服务，使用 Java 17，Maven 构建。
项目采用分层架构：Controller → Service → Repository。

## 技术栈
- Java 17 / Spring Boot 3.2
- Spring Data JPA + MySQL 8.0
- Redis（缓存）
- JUnit 5 + Mockito（测试）
- MapStruct（DTO 转换）
- Flyway（数据库迁移）

## 构建与测试
- 编译：mvn clean compile
- 运行测试：mvn test
- 完整构建：mvn clean package
- 启动服务：mvn spring-boot:run

## 项目结构
src/main/java/com/example/shop/
├── controller/    # REST 控制器，只做参数校验和结果封装
├── service/       # 业务逻辑
├── repository/    # 数据访问层（JPA Repository）
├── entity/        # 数据库实体类
├── dto/           # 请求/响应 DTO
├── config/        # 配置类
├── exception/     # 自定义异常和全局异常处理
└── util/          # 工具类

## 编码规范
- 遵循阿里巴巴 Java 开发手册
- Controller 层不写业务逻辑，只做参数校验和 Service 调用
- 使用 @Slf4j 记录日志，禁止使用 System.out.println
- 异常统一抛出自定义 BusinessException，不要直接抛 RuntimeException
- 数据库字段用下划线命名，Java 属性用驼峰命名
- 所有 REST 接口返回统一响应格式：Result（code, message, data）

## 禁止事项
- 不要修改 src/main/resources/db/migration/ 下的已有迁移文件
- 不要修改 pom.xml 中的依赖版本（如需新增依赖请说明理由）
- 不要在循环中进行数据库查询（N+1 问题）
- 不要硬编码配置值，使用 @Value 或 @ConfigurationProperties
- 不要使用 Java 8 之前的日期 API（使用 java.time.*）

## 测试要求
- 新功能必须附带单元测试
- Service 层测试使用 Mockito mock Repository
- Controller 层测试使用 @WebMvcTest + MockMvc
- 测试方法命名：should_预期行为_when_条件
- 确保所有测试通过后再提交

4.3 对齐是一个持续过程

如果你读过《人机对齐》，你会知道对齐不是一次性的事——它需要持续的观察、反馈和修正。AGENTS.md 也是如此：

• 从简单开始：先写核心的构建命令、项目结构和编码规范，不需要一次性面面俱到。
• 记录 Agent 的“常见错误”：如果你发现 Agent 反复在某个地方犯错（比如总是忘了加 @Transactional），就把对应的规则加进去。每一条新规则，都是你从 Agent 的错误中提炼出来的“对齐补丁”。
• 纳入版本控制：AGENTS.md 应该和代码一起提交到 Git。团队成员都能受益，而且当项目规范变化时可以追溯。

4.4 层级化配置：从全局到局部

如果你只管理一个项目，在仓库根目录放一个 AGENTS.md 就够了。但现实世界往往更复杂——你可能有个人通用的编码偏好、公司级的规范要求、项目级的技术选型、甚至子模块级的特殊规则。这就像一家跨国公司的管理制度：总部有通用政策，区域有本地化调整，个别部门还有例外条款。

Codex 的 AGENTS.md 支持类似的层级化覆盖机制。它的发现顺序如下：

1. 全局级：~/.codex/AGENTS.md——你个人的通用偏好，适用于所有项目。例如“始终使用中文注释”“偏好使用 pnpm 而非 npm”
2. 项目根目录级：仓库根目录的 AGENTS.md——项目特有的技术栈、构建命令和编码规范
3. 子目录级：各子目录下的 AGENTS.md——适用于 Monorepo 中不同模块的差异化规则

关键规则：越靠近当前工作目录的文件优先级越高。 因为 Codex 会将所有发现的文件从根往下拼接，后出现的内容会覆盖先出现的——就像 CSS 的层叠规则一样。

此外还有一个强力武器：AGENTS.override.md。当同一目录下同时存在 AGENTS.md 和 AGENTS.override.md 时，Codex 只读取 override 文件而忽略普通文件。这非常适合临时覆盖规则而不修改团队共享的 AGENTS.md——比如你在调试一个棘手的 Bug 时，临时放宽某些限制。

以一个 Java Monorepo 为例：

1
2
3
4
5
6
7
8
9
10

my-platform/
├── AGENTS.md                          # 全局规范：编码风格、Git 提交规范
├── services/
│   ├── user-service/
│   │   └── AGENTS.md                  # 用户服务：Spring Boot + JPA 规范
│   └── payment-service/
│       ├── AGENTS.md                  # 支付服务：被 override 覆盖
│       └── AGENTS.override.md         # 临时规则：调试期间允许跳过部分测试
└── frontend/
    └── AGENTS.md                      # 前端：React + TypeScript 规范

当 Codex 在 payment-service/ 目录工作时，它会依次加载：全局 ~/.codex/AGENTS.md → 根目录 AGENTS.md → payment-service/AGENTS.override.md（跳过同目录的普通 AGENTS.md）。

实用建议：

• 全局文件放个人偏好，项目根目录放团队规范，子目录放模块特有规则
• 调试完成后及时删除 AGENTS.override.md，避免它长期覆盖团队规则
• 所有 AGENTS.md 文件的总大小有 32KB 的默认上限（可通过 config.toml 中的 project_doc_max_bytes 调整）——写得精炼比面面俱到更重要

5 高级技巧

5.1 管理长上下文：别让工作记忆溃堤

1956 年，认知心理学家乔治·米勒发表了他最著名的论文《神奇的数字 7±2》，揭示了人类短期记忆的容量限制——我们一次大约只能记住 7 个信息单元。超过这个阈值，信息就会开始相互干扰，出现遗忘和混淆。

大语言模型面临着惊人相似的困境。虽然它们的“工作记忆”（上下文窗口）远大于人类——可以容纳数十万 token 的内容——但这并不意味着它们对窗口内的每一条信息都同样敏感。研究者和开发者的经验一致表明：当对话内容达到模型上下文容量的 30-40% 时，早期的细节开始被弱化，模型的注意力聚焦在最近的交互上。越往后，越容易出现“明明告诉过它但它就是忘了”的情况。

解决方案和人类应对记忆限制的策略如出一辙——分块（chunking）和外部化（externalization）。

多开线程，而非拉长对话

米勒发现，人类绕过 7±2 限制的方式是“组块化”——把零散信息编成有意义的单元。对 Codex 而言，这意味着把大型需求拆分为多个聚焦的线程：

线程 1：生成基本项目框架和实体类
线程 2：实现 Controller 和 Service 层
线程 3：添加认证和权限控制
线程 4：编写测试和文档

每个线程专注一个子问题，上下文更集中，出错概率更低。这不仅仅是工程技巧，而是在适应模型的认知架构。

主动要求总结

人类的另一个记忆策略是“笔记”——把重要信息写下来，释放大脑去处理新问题。对 Codex 同样适用：当一个线程的对话进行到一定长度时，让 Agent 把当前状态“写下来”：

请总结目前已完成的功能、修改的文件清单、以及尚未完成的部分。

然后在新线程的开头贴上这段总结继续工作。这比让 Agent 在一个超长对话里“记住”所有细节可靠得多——就像你不会把整本教科书背下来，而是做好笔记然后带着笔记去考试。

控制 Token 消耗

长对话消耗大量 token，既拖慢响应速度，也增加成本。OpenAI 曾展示 Codex 利用约 700 万 tokens 自主开发一个 3D 游戏的案例，但这样的用量不适用于日常开发。如果输出明显变慢，考虑终止当前线程，分段处理。

5.2 调用 Shell 命令与本地工具链

内置终端与核心节奏

每个 Codex 线程附带一个内置终端，你可以在其中执行任意 Shell 命令。这带来了一个高效的工作节奏，也是 Codex 日常使用的基本循环：

1. 在对话中让 Agent 生成代码
2. 切到终端运行 mvn test
3. 如果测试失败，把错误日志复制回对话框
4. Agent 分析失败原因并修复
5. 再次运行测试，直到通过

这个“编码 → 测试 → 反馈 → 修复”的循环，本质上就是控制论中的反馈回路——系统做出动作，观测结果，根据偏差修正，再次行动。闭环越短，收敛越快。

三种模式下的命令执行差异

• Local / Worktree： Agent 不能自动执行命令（需你确认）。你需要手动在终端执行，复制结果反馈给 Agent。
• Cloud： Agent 可以自动执行命令（沙盒环境）。你只需在 AGENTS.md 中配置好命令，Agent 会自主执行。

5.3 调试支持与 IDE 集成

喂给 Agent 错误日志

最直接的调试方式：把异常栈粘贴给 Codex。例如：

运行 mvn test 后，以下测试失败：
should_throw_when_user_not_found
错误如下：

1
2
3
4

AssertionFailedError:
Expected: ResponseStatusException
But was:  NoSuchElementException
  at UserServiceTest.java:42

请分析原因并修复 UserService 中的逻辑。

Codex 会根据异常类型、堆栈信息和测试代码定位问题——在这个例子里，它可能会发现 findById 方法直接调用了 Optional.get() 而没有做空值处理，然后改为抛出 ResponseStatusException。

让 Agent 生成调试辅助代码

当问题难以复现时，让 Agent 帮你搭建调试场景：

请为 OrderService.createOrder 中的
库存扣减逻辑添加 DEBUG 级别日志，
记录每一步的中间状态
（当前库存、扣减数量、扣减后库存）。

或者：

请编写一个单元测试来复现以下场景：
当两个线程同时调用 deductStock 时，
应该只有一个成功。

这相当于让 Agent 帮你搭好实验装置，你来观察结果——正如实验物理学家不会自己吹制每一个玻璃器皿，但一定自己解读实验数据。

MCP 与 IDE 集成

OpenAI 提供了 MCP（Model Context Protocol）让 Codex 与 IDE 协同工作。通过 MCP，Agent 可以访问 IDE 的调试接口——例如 Skyscanner 的工程师已将 Codex CLI 集成进 JetBrains IDE，使 AI 能使用断点调试和测试运行功能。对 Java 开发者而言，这意味着 Codex 有潜力通过 IDE 获取运行时信息（调用栈、变量值），从而更精准地诊断问题。目前这些集成仍需手动配置，但它展示了 AI Agent 与传统开发工具结合的方向。

5.4 Skills：教 Agent 新技能

AGENTS.md 告诉 Agent“怎么做事”，Skills 则给了 Agent“做事的工具”。如果说 AGENTS.md 是入职手册，Skills 就是新员工工位上的工具箱——手册告诉他“组装时必须用扭力扳手”，工具箱里则真的有一把扭力扳手。

Skills 是 Codex 的可自定义能力模块，让 Agent 在执行任务时可以调用特定的工具和流程。Codex 内置了一些基础 Skills（如代码理解、文档生成），但真正强大的是自定义 Skills。

一个 Java 项目的实际例子：

假设你的项目使用了自定义的代码生成器——每次新增数据库表时，需要运行 mvn generate-sources -pl :code-generator 来生成 Entity 和 Repository。这不是 Agent 能从代码里推断出来的，但你可以创建一个 Skill 来告诉它。

Skills 配置存放在 ~/.codex/skills/（全局）或项目的 .codex/skills/ 目录中。一个 Skill 本质上是一份结构化的描述，告诉 Agent 在什么场景下、用什么命令、完成什么任务。

Skills vs AGENTS.md 的区别：

• AGENTS.md 是被动的“规则手册”——Agent 遵循但不主动调用
• Skills 是主动的“工具”——Agent 在判断需要时会主动调用它来完成特定操作

例如，你可以创建一个“运行模块测试”的 Skill，让 Agent 在修改代码后自动知道应该运行哪个模块的测试、如何解读测试结果。在本地模式下，这让 Agent 获得了类似 Cloud 模式的自主测试能力（当然仍受沙箱限制）。

一个前瞻性提醒：不要过度搭建脚手架。 Sherwin Wu 引用过一句话：“模型会把你搭的脚手架当早餐吃掉。” 2022 年 ChatGPT 刚发布时，大家围绕模型构建了大量 Agent 框架、向量数据库生态和复杂的编排系统来“引导”模型输出。但随着模型能力迅速提升，这些脚手架正在被模型本身吞噬——更好的方法反而是去掉大量逻辑，直接信任模型，只给它基础工具。Skills 今天是有价值的，但请保持轻量，不要在上面构建过于复杂的抽象层。随着 codex-1 及后续模型的进步，你今天精心搭建的框架，明天可能需要全部拆掉。

5.5 Review 的艺术：从信任到验证

科学界有一个被奉为圭臬的原则：可证伪性。卡尔·波普尔认为，一个理论的价值不在于它声称什么是对的，而在于它提供了什么方法让别人来检验它是否是错的。同样的道理适用于 Agent 生成的代码——好的 Agent 输出不是让你“相信它是对的”，而是给你足够的证据去“验证它是否是错的”。

Codex 的 codex-1 模型在这方面做了专门设计：它会主动提供可验证证据。当 Agent 完成任务后，它不仅给你代码 diff，还会引用终端日志（“mvn test 的输出显示所有 47 个测试通过”）和具体的代码位置（“在 OrderService.java:87 添加了 @Transactional 注解”）。这些引用就是它的“实验数据”，供你审核。

OpenAI 内部已经在大规模实践这种模式。Sherwin Wu 透露，Codex 审核了 OpenAI 内部 100% 的 PR——任何进入生产环境的代码都会经过 Codex“过目”，它会提前生成改进建议。这让代码审查从原本 10 到 15 分钟的任务，缩短到 2 到 3 分钟。很多小型 PR 甚至不再需要人工审核。代码审查的本质是“第二双眼睛”，而 Codex 已经是一双非常聪明的“第二双眼睛”。

Review 三步法

面对 Agent 交付的一份 diff，建议按以下顺序审查：

第一步：结果验证。 先看测试是否通过、构建是否成功。如果 Agent 在 Cloud 模式下工作，这些信息已经附带在输出中；如果在 Worktree 模式下，你需要手动在终端运行一次。这一步回答的问题是：“它做的东西能跑吗？”

第二步：架构验证。 快速浏览 diff 的全局——改了哪些文件、新增了哪些类、修改了哪些方法签名。这一步回答的问题是：“它做的东西在正确的位置吗？”比如，一个应该只改 Service 层的重构，如果 diff 里出现了 Controller 或 Entity 的改动，就值得警惕。

第三步：细节验证。 聚焦关键路径逐行审查——事务边界、异常处理、并发控制、SQL 查询。这一步回答的问题是：“它做的东西在边界情况下也对吗？”

利用 Review 面板的内联评论

Codex App 的 Review 面板支持在 diff 上直接写评论——这比在对话框里描述问题高效得多。例如：

“这个查询缺少分页，当数据量大时会有性能问题，请加上 Pageable 参数。”

“这里的异常被 catch 后只打了日志没有重新抛出，会导致事务不回滚。”

Agent 会根据你的评论进行精准修改。这种“点对点”的反馈方式，比泛泛地说“请检查性能问题”有效得多——就像代码审查（Code Review）中，行级评论总是比笼统的“请优化”更容易落地。

6 Prompt 实战模板

管理学大师彼得·德鲁克曾说：“管理的本质不是命令，而是沟通。”这句话对 AI 编程同样成立。你写给 Agent 的 Prompt，本质上是一份委派指令——它的清晰程度直接决定了 Agent 的输出质量。一个模糊的“帮我加个接口”和一个结构化的需求描述，得到的结果可能天差地别。

以下是几个经过验证的 Prompt 模板，专为 Java 后端场景设计。它们的共同特征是：明确目标、提供约束、要求 Agent 先规划再动手。

6.1 新增 REST 接口

在本项目中新增一个 REST 接口，要求如下：

功能： 根据用户 ID 查询订单列表，支持分页
路径： GET /api/users/{userId}/orders
参数： userId（路径参数），page（默认 0），size（默认 20）
返回： Page<OrderDTO>，包含订单编号、金额、状态、创建时间

实现要求：

1. Controller 层只做参数校验和结果封装
2. Service 层处理业务逻辑
3. 使用 Spring Data JPA 的分页查询
4. 如果用户不存在，返回 404
5. 返回格式遵循项目统一的 Result<T> 结构

请先列出你计划创建或修改的文件清单，确认后再开始编码。

要点： 最后一句“先列出文件清单”是这个模板的灵魂。它引入了一个轻量级的“计划-确认-执行”流程，让你在 Agent 动手之前就能发现理解偏差。

6.2 跨层重构

当前 UserController 中直接包含了用户数据的验证逻辑（邮箱格式校验、手机号校验、用户名唯一性检查），这违反了分层原则。

请重构：

1. 将验证逻辑从 Controller 提取到 UserService
2. 邮箱和手机号格式校验使用 javax.validation 注解（@Email, @Pattern）
3. 用户名唯一性检查保留在 Service 层，通过 Repository 查询
4. 保持所有现有 API 的行为不变
5. 确保现有测试仍然通过

不要修改 UserRepository 和 User 实体类。

要点： 重构最怕的是牵一发动全身。明确声明“不要修改什么”和“保持什么不变”，就像给 Agent 画了一个施工围栏——围栏内随意施工，围栏外禁止动工。

6.3 生成单元测试

为 OrderService 编写 JUnit 5 单元测试，要求：

• 使用 @ExtendWith(MockitoExtension.class)
• Mock 所有依赖的 Repository 和外部服务
• 覆盖以下场景：
  1. 正常创建订单（库存充足）
  2. 库存不足时抛出 BusinessException
  3. 用户不存在时抛出 BusinessException
  4. 订单金额计算正确（含优惠券折扣）
  5. 创建订单后库存正确扣减
• 测试方法命名遵循 should_预期行为_when_条件
• 使用 AssertJ 断言风格

生成完成后请运行 mvn test -pl :order-service 确认全部通过。

要点： 指定测试框架、Mock 方式、命名规范、断言风格——约束越多，输出越可控。最后一句指示 Agent 运行测试：在 Cloud 模式下它会自动执行；在本地模式下它会提示你手动执行。

6.4 排查 Bug

生产环境出现间歇性问题：用户下单后偶尔出现库存扣减成功但订单状态为“创建失败”的不一致情况。

请按以下步骤分析：

1. 阅读 OrderService.createOrder 方法的完整逻辑
2. 检查事务边界：@Transactional 注解是否正确放置
3. 检查异常处理：是否有被 catch 后没有重新抛出的异常
4. 检查外部调用：是否在事务内调用了外部服务（如发送消息队列），导致事务提交前外部状态已变更
5. 给出根因分析和修复方案

先分析，不要直接改代码。分析完成后等我确认再修复。

要点： 给出结构化的排查步骤，引导 Agent 像资深工程师一样系统地分析问题。“先分析，不要直接改代码”这句话非常重要——它把 Agent 从“执行者”模式切换到“分析师”模式，避免它在没搞清楚问题之前就动手“修”出更多问题。

6.5 代码审查

请以高级 Java 工程师的视角审查以下改动（本次线程中的所有 diff），重点关注：

1. 事务一致性：是否有遗漏的 @Transactional 或事务边界不正确
2. 并发安全：是否有竞态条件或线程安全问题
3. 异常处理：是否有未处理的 checked exception 或过于宽泛的 catch
4. 性能隐患：N+1 查询、循环内数据库调用、缺少索引
5. 安全漏洞：SQL 注入、敏感信息日志泄露、未校验的用户输入

对每个问题给出具体的文件名、行号和修复建议。

要点： 让 Agent 扮演“审查者”而非“实现者”——同一个 Agent 写的代码，换一个角色来审，往往能发现自己创作时的盲点。这和文学创作中“放一段时间再回头修改”的道理相通。

6.6 Automations：让 Agent 值夜班

Codex 支持 Automations 功能，让 Agent 定期执行例行任务——就像医院的夜班护士定时巡查病房。你可以设置：

• 每日代码质量检查： 让 Agent 每天扫描代码库，检查是否有新增的 TODO 未处理、测试覆盖率是否下降。
• CI 失败分析： 当 CI 流水线失败时，自动让 Agent 分析失败原因并提出修复建议，结果进入收件箱。
• 依赖更新提醒： 定期检查 pom.xml 中的依赖是否有安全漏洞或重大版本更新。

在 OpenAI 内部，开发者已用 Automations 每日自动整理 Bug 列表、汇总 CI 失败原因、生成发布报告。你上班时打开 Codex 收件箱，昨晚的巡查报告已经在那里了。

7 实战示例：从零构建 Spring Boot REST 服务

纸上得来终觉浅。让我们通过一个完整示例，把前面所有概念串联起来。

场景： 构建一个用户管理 REST 服务，包含获取用户列表和按 ID 查询两个接口。使用 Spring Boot + 内存数据（简化起见）。本地已有 JDK 和 Maven 环境，以及一个空的 Git 仓库。

步骤 1：初始化项目

打开 Codex，选择项目目录 ~/Projects/UserService，启动新线程（选择 Worktree 模式）。发送：

使用 Spring Boot 3.2 + Java 17 初始化一个 Maven 项目，artifactId 为 user-service。
包含以下依赖：spring-boot-starter-web, spring-boot-starter-test。
创建主类 UserServiceApplication，配置 server.port=8080。
同时在项目根目录创建 AGENTS.md，写明构建命令（mvn clean compile）和测试命令（mvn test）。

Codex 会生成 pom.xml、主类、application.properties 和 AGENTS.md。在 Review 面板中检查文件结构是否符合预期。

步骤 2：实现业务逻辑

确认项目框架后，在同一线程继续：

按照以下设计实现用户管理功能：

1. 创建 User 实体类（id: Long, name: String, email: String），放在 entity 包下
2. 创建 UserService，内部维护一个 ArrayList 作为模拟数据源，预置 3 个用户数据。提供 findAll() 和 findById(Long id) 方法
3. 创建 UserController，提供：
   • GET /api/users → 返回所有用户
   • GET /api/users/{id} → 返回单个用户，找不到时返回 404
4. Controller 通过构造函数注入 UserService

不要使用 Lombok，手动编写 getter/setter。

Codex 会在对话中描述它正在创建的文件，并在 Review 面板显示完整 diff。检查类结构、包路径、注解是否正确。

步骤 3：运行验证

切到线程的内置终端：

1

mvn spring-boot:run

启动后在另一个终端（或浏览器）访问：

1
2
3

curl http://localhost:8080/api/users
curl http://localhost:8080/api/users/1
curl http://localhost:8080/api/users/999  # 预期返回 404

如果启动失败（比如缺少依赖），把错误日志复制回对话：

应用启动失败，报错如下：[粘贴错误栈]。请分析原因并修复。

Codex 会定位问题并修改代码。这就是第 5 章提到的“编码 → 测试 → 反馈 → 修复”闭环的一次实际运转。

步骤 4：生成测试

新开一个线程（继续使用同一项目的 Worktree 模式），发送：

为 UserService 和 UserController 编写 JUnit 5 测试：

UserServiceTest：

• should_return_all_users
• should_return_user_when_id_exists
• should_throw_when_id_not_found

UserControllerTest（使用 @WebMvcTest + MockMvc）：

• should_return_200_and_user_list
• should_return_200_and_single_user
• should_return_404_when_user_not_found

生成后请确认所有文件路径正确（放在 src/test/java 对应的包下）。

检查测试代码，然后在终端运行 mvn test。如果有测试未通过，反馈给 Agent 修正。

步骤 5：代码清理

所有测试通过后，让 Codex 收尾：

请检查整个项目：

1. 为所有 public 方法添加 JavaDoc 注释
2. 检查是否有冗余的 import
3. 确保代码风格一致（缩进、空行等）
4. 生成一段简短的 README.md，说明如何构建和运行

确认无误后，在应用中提交 Git commit，将 worktree 的改动合并回主分支。一个完整的 REST 服务就这样在 Codex Agent 的帮助下成型了。五个步骤，两个线程，整个过程你没有手写一行业务代码——但你审查了每一行。

8 团队协作：从单人塔台到空管中心

前面所有章节都聚焦于一个人如何高效使用 Codex。但软件开发从来不是一个人的战争——它是一个团队的协作。如果说单人使用 Codex 是一个塔台管制员指挥飞机，那么团队使用 Codex 就是建立了一个完整的空管中心——有雷达屏幕（GitHub PR），有无线电通信（Slack），有航班调度表（Linear）。

Codex 原生支持三大协作平台的集成，把 Agent 的工作融入团队现有的工作流。

8.1 GitHub 集成：PR 驱动的工作流

这是最核心的集成。在 Cloud 模式下，Agent 完成任务后会自动创建 Pull Request——不是给你一堆代码让你手动粘贴，而是一个规规矩矩的 PR，包含完整的 diff、提交信息，甚至附带测试运行结果。

完整流程：

1. 在 Codex 中连接你的 GitHub 仓库（首次需要授权）
2. 创建 Cloud 模式任务：“为 OrderService 添加批量导出功能”
3. Agent 在云端沙盒中克隆仓库、编写代码、运行测试
4. 完成后自动创建 PR，标题和描述由 Agent 根据改动内容生成
5. 团队成员在 GitHub 上正常 Review、评论、请求修改
6. 审查通过后合并——和人类开发者提交的 PR 走完全相同的流程

GitHub Action：让 Codex 融入 CI/CD

更进一步，Codex 提供了官方 GitHub Action，可以在 CI/CD 流水线中自动调用 Agent。典型的使用场景：

• Issue 自动修复： 当有人创建 Bug Issue 时，GitHub Action 自动触发 Codex 分析问题并提交修复 PR
• PR 自动审查： 每次有新 PR 提交时，让 Codex Agent 做一次自动化代码审查，将发现的问题以评论形式写在 PR 上
• 依赖更新： 定期让 Agent 检查并更新过时的依赖版本

在 .github/workflows/ 中配置类似如下：

1
2
3
4
5
6
7
8
9
10
11
12

name: Codex Auto Review
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: openai/codex-action@v1
        with:
          task: "review"
          prompt: "以高级 Java 工程师视角审查此 PR，重点关注事务一致性、并发安全和性能隐患"

8.2 Slack 集成：实时通知与触发

将 Codex 连接到 Slack 后，Agent 的工作状态会实时推送到指定频道：

• 任务开始时发送通知：“Codex Agent 开始处理：为 UserService 添加分页查询”
• 任务完成时发送结果：“✅ 已完成，PR #42 已创建，所有测试通过”
• 任务失败时发送告警：“❌ 构建失败，3 个测试未通过，详见 Codex 收件箱”

更强大的是反向触发——团队成员可以直接在 Slack 中向 Codex 发指令。想象一下这个场景：周五下午，QA 在 Slack 里报告了一个 Bug，你直接在频道里 @Codex 说“分析一下 OrderService 中订单状态不一致的问题”，Agent 立刻开始工作，几分钟后在同一个频道里回复分析结果。这比打开 IDE、切换分支、定位代码要快得多——尤其是当你不在工位的时候。

8.3 Linear 集成：从 Issue 到 PR 的自动闭环

对于使用 Linear 做项目管理的团队，Codex 可以打通从需求到交付的完整链路：

1. PM 在 Linear 中创建 Issue：“用户管理模块需要支持批量导入功能”
2. 将 Issue 分派给 Codex Agent（通过 Linear 集成配置）
3. Codex 自动读取 Issue 描述，在 Cloud 模式下开始实现
4. 完成后自动创建 GitHub PR，并在 PR 描述中关联 Linear Issue
5. PR 合并后，Linear Issue 自动流转为“已完成”

这形成了一个完整的闭环：Issue → Agent 实现 → PR → Review → 合并 → Issue 关闭——中间不需要任何人手动操作流程性的事务。开发者可以把精力集中在真正需要人类判断的环节：需求澄清、架构决策和代码审查。

8.4 团队落地建议

• 从简单任务开始： 先用 Codex 处理团队中“人人都觉得烦但必须做”的事情——补单元测试、更新 API 文档、修复 lint 告警。这些低风险任务能帮团队建立信心。
• 统一 AGENTS.md： 团队共用一份 AGENTS.md，确保不同人委派的任务遵循相同的规范。把它当做“团队协作协议”来维护。
• 建立 Review 文化： Agent 提交的 PR 必须和人类提交的 PR 走完全相同的审查流程——不能因为是 AI 写的就跳过审查，也不能因为是 AI 写的就格外严苛。标准应该是统一的。
• 渐进式信任： 先 Worktree 模式，观察一段时间后再过渡到 Cloud 模式。就像委派新员工一样——先让他做小事证明能力，再逐步交给他更大的责任。

9 Codex vs Cursor：何时用哪个

心理学家丹尼尔·卡尼曼在《思考，快与慢》中提出了两种认知模式：系统 1 是快速的、直觉的、自动化的；系统 2 是缓慢的、深思熟虑的、有意识的。Cursor 像系统 1——你和 AI 在快速交互中思考，逐行迭代，实时反馈；Codex 像系统 2——你花时间想清楚要什么，写好指令，然后让 Agent 在后台深度执行。

Cursor — AI 增强的本地 IDE。你在环内实时交互，逐行建议，精细控制。单线程，运行在本地，可配置多种模型。适合精细调试、交互式探索、学习新技术。

Codex — AI Agent 指挥中心。你在环外异步审查，整块任务完整交付。多 Agent 并行，支持本地和云端，使用 codex-1 专用模型。适合批量任务、功能开发、流程自动化。

9.1 两个”不习惯”

当你从 Cursor 切换到 Codex 做日常开发，很可能遭遇两种微妙的不适感：第一，Codex 的反馈节奏明显更慢，不像 Cursor 那样”短平快”；第二，你发现自己几乎不再逐行阅读代码——效率虽然提升了，心里却反而没了底。

先看反馈慢。上文用卡尼曼的系统 1 / 系统 2 做了类比：Cursor 的体验更接近系统 1——改一点、跑一下、马上看到结果，错误与修复之间距离极短，体感流畅。而 Codex 是典型的系统 2：它会自行规划、执行一连串动作，然后一次性把成果端上来。这种长程自治模式在复杂任务上潜力巨大，代价则是等待变长、中间过程不透明、掌控感下降。于是你很容易觉得它”慢”、”钝”，甚至不如 Cursor 灵敏。

再看没底。这种感觉的根源，并非你没有亲手写代码，而是你失去了过去那套隐性的验证仪式：改了一行，你知道可能影响哪里；跑测试，看日志，确认行为符合预期——这些微小的确认堆叠在一起，构成了安全感。现在 Agent 一次交付一大块修改，你既没参与每一步推理，也没逐行阅读，自然出现一种”交付是交付了，但不知道靠不靠谱”的空心感。

9.2 从”看代码”到”看证据链”

破解这两个不适感的关键，在于一次认知转换。

试想：如果这段代码不是 AI 写的，而是一位同事提的 Pull Request，你会怎么决定能不能 merge？你大概率不会逐行读完所有代码——你依赖的是一套证据：PR 描述了什么问题、改了哪些东西、测试是否通过、有没有明显的风险点。换句话说，真正让你安心的从来不是”我亲手写了这段代码”，而是”我有足够的证据相信它是对的，并且出了事能控得住”。

当你把同样的审核门槛用在 AI 的交付上，心态会稳定很多：你不需要盲目信任 Agent，你只需要像审核同事的 PR 一样审核证据。

这套证据可以浓缩为五类：

1. 目标证据——它解决了什么问题，为什么要这么改，这次不解决什么
2. 正确性证据——有没有复现用例、关键路径测试、回归是否全绿
3. 风险证据——边界条件、性能、安全、权限等风险点是否被识别并缓解
4. 可观测性证据——日志、指标、报警是否足以让你在上线后快速发现并定位问题
5. 可回滚证据——如果判断失误，能否快速撤回或降级，尤其涉及数据结构变更时

对”反馈慢”，方向不是回到逐行写代码，而是把 Codex 的长程任务主动拆成里程碑式的短回路：先让 Agent 输出计划，每一步跑验证，每完成一个阶段就停下来等你验收，确认后再继续推进——这在第 5.1 节”管理长上下文”中已有详细讨论。对”没底”，则把交付格式改成”同事式 PR”：让 Agent 每次输出变更摘要、测试方式与结果、风险与缓解、观测点、回滚方案。你审的不是每一行实现细节，而是这些能让你做出合并决策的证据。

这与第 5.5 节”Review 的艺术”中的三步法一脉相承——结果验证、架构验证、细节验证，本质上都是在构建证据链。这里只是把视角从单次 Review 扩展到了整个工作流。

9.3 角色升级与组合使用

当你接受自己正在从”写代码的人”转向”对交付质量负责的人”，上面两个问题便不再是障碍，而是一次角色升级的信号：AI 负责产出与执行，你负责定义目标、设定验证门槛、审查证据、做合并决策。效率不会丢，掌控感也能回来——前提是你把过去依赖”亲手写”的安全感，升级为依赖”证据链”的安全感。

这也呼应了引言中的比喻：管制员不驾驶任何一架飞机，但他通过雷达、通信和规程，对每一架飞机的安全负全责。从驾驶员到塔台，变的是操作方式，不变的是责任标准。

理解了这层关系，Codex 与 Cursor 就不再是二选一的竞争工具，而是一对互补的系统——正如人类大脑并非只用系统 1 或系统 2，而是根据任务特征灵活切换。很多团队的实践是：

• 日常编码用 Cursor： 写小段代码、重构、Debug、交互式探索方案——系统 1 式的快速迭代
• 成块任务用 Codex： 生成样板代码、批量 CRUD、补全测试、跨文件重构——系统 2 式的深度执行
• 批量修复用 Codex Cloud： 一次性修复多个独立 Bug，每个 Bug 一个线程，稍后统一 Review PR

一个实际的工作流可能是：先在 Cursor 里用 Plan 模式讨论技术方案，确认后用 Codex 的 Worktree 模式并行启动多个 Agent 实现各个模块，最后回到 Cursor 做精细调整和集成调试。而在每个环节，你关注的不再是”我有没有亲手写这行代码”，而是”我有没有足够的证据做出合并决策”。

10 常见问题与使用建议

Q1: Agent 线程卡住不动了怎么办？

先检查几个常见原因：

• macOS 权限弹窗： Codex 读写受保护目录（Desktop、Documents 等）时，系统会弹出权限请求。如果弹窗被其他窗口遮挡，Agent 就一直在等。检查系统通知或切换到 Codex 窗口看是否有待确认的弹窗。
• Git 锁文件： 在终端运行 git status。如果提示 .git/index.lock 存在，说明上一次 Git 操作异常中断。删除锁文件即可：rm .git/index.lock。
• 任务本身太复杂： 如果 Agent 长时间无输出，可能是任务范围过大导致模型陷入了过深的推理链。终止线程，将任务拆小重试。

Q2: 如何防止 Agent 改坏关键文件？

最有效的三道防线：

1. Worktree 模式： 所有改动都在隔离分支上，不影响主代码。你审查 diff 后才决定是否合并。
2. AGENTS.md 中声明禁区： 明确写出“不要修改 xxx 目录/文件”。Agent 会遵循这些约束。
3. CI 卡口： 在合并前跑完整的测试和 lint 检查。一旦 Agent 的改动破坏了核心功能，CI 会立刻暴露。

真实踩坑案例： 有用户让 Codex 在 Cloud 模式下优化 SQL 查询，Agent 不仅改了 Service 层的查询逻辑，还“顺手”修改了 resources/db/migration/ 下的 Flyway 迁移文件——这在生产环境中是灾难性的，因为已执行过的迁移文件不允许修改。这个故事完美地说明了“对齐问题”的日常版本：Agent 确实在“优化”，但它不理解“哪些东西不能碰”这条隐性规则。解决办法很简单：在 AGENTS.md 中加一句“db/migration/ 目录下的已有文件禁止修改，如需变更数据库结构请创建新的迁移文件”。

Q3: Cloud 模式下 Agent 找不到项目的私有 Maven 依赖怎么办？

Cloud 模式在 OpenAI 的沙盒中运行，无法访问你公司内网的 Maven 私服（如 Nexus、Artifactory）。解决方案：

• 方案一： 如果私有依赖不影响编译（只是运行时需要），在 AGENTS.md 中告诉 Agent 跳过：mvn compile -pl :your-module -am -Dmaven.test.skip=true。
• 方案二： 对于必须依赖私有库的项目，使用 Worktree 模式替代 Cloud 模式——本地环境能正常解析私有依赖。
• 方案三： 将私有依赖发布到 GitHub Packages 等公网可访问的仓库，并在 pom.xml 中配置对应的 repository。

Q4: 如何控制 Token 消耗？

几个实用策略：

• 限定输出范围： 不要说“帮我看看这个项目有什么问题”，而是说“检查 OrderService 中 createOrder 方法的事务一致性”。范围越精确，消耗越少。
• 小步迭代： 一次处理一个功能点，不要试图在一个线程里完成整个模块。
• 善用 AGENTS.md： 把项目背景信息写在 AGENTS.md 中，就不需要每次对话都重复说明——这和你给新同事写入职文档是一个道理，一次投入，长期受益。
• 监控线程时长： 如果一个线程的响应变慢、输出质量下降，说明上下文已经过长。果断开新线程。

Q5: 有哪些提升效果的小技巧？

1. 一个线程一个主题： 不要在同一个线程里又改 Bug 又加功能。就像你不会在一封邮件里同时讨论三个不相关的议题——信息越聚焦，沟通越高效。
2. 先分析后编码： 对复杂任务，总是在 Prompt 末尾加上“先列出你的方案/计划，确认后再开始编码”。这避免了 Agent 理解偏差导致的大量返工。
3. 善用 Review 面板的评论功能： 直接在 diff 上写评论（如“这里需要加事务注解”“这个字段名应该用 camelCase”），然后让 Agent 根据评论修改。这种定向反馈比重新描述需求高效得多。
4. 让 Agent 解释自己的改动： 如果你不确定某段生成代码的逻辑，直接问“请解释你在 OrderService 第 45 行使用 CompletableFuture 的原因”。理解 Agent 的思路有助于你做出更准确的判断。
5. Worktree + 并行的黄金组合： 当你有多个独立的任务时（如三个不同的 Bug），同时开三个 Worktree 线程并行处理，然后逐一 Review 合并。这是 Codex 相对于 Cursor 最大的效率优势——空中交通管制员同时引导多架飞机着陆，而不是一架一架排队等。

11 结语：从塔台到空管网络

1956 年那位走上塔台的管制员，大概不会想到，半个多世纪后全球的空中交通管制已经演变成一个由卫星、雷达、自动化系统和数千名专业人员组成的庞大网络。从一个人拿着望远镜盯跑道，到一个全球协作的空管体系——技术在变，但核心原则始终如一：清晰的通信、可靠的监控、明确的权责。

回顾本文走过的路径，你会发现它描绘了一条类似的演化路线：

• 第 1 章让你认识了 Codex 的全貌——从桌面应用到命令行、IDE 插件和 Web 版，了解你手中工具的完整能力边界
• 第 2 章帮你选择了合适的信任层级——Local、Worktree、Cloud，从“你做我看”到“你全权负责”
• 第 3 章建立了安全底线——沙箱隔离和审批策略，确保信任不会变成放纵
• 第 4 章解决了对齐问题——AGENTS.md 让 Agent 从第一秒就知道“我们这里怎么做事”
• 第 5-7 章提供了实战武器——上下文管理、Shell 集成、Skills、Review 技巧、Prompt 模板和完整示例
• 第 8 章把视角从个人扩展到团队——GitHub、Slack、Linear 集成，让 Agent 成为团队工作流的一部分

每一步都在做同一件事：建立更好的验证闭环。模式选择决定了闭环的粒度，安全沙箱决定了闭环的边界，AGENTS.md 决定了闭环的标准，Review 工作流决定了闭环的质量。

站在 2026 年的今天，Agent 式编程仍处于早期。Sherwin Wu 给出了一个明确的方向预判：未来 12 到 18 个月，模型将从“分钟级任务”进化到可以连贯完成“多小时甚至一天”的任务。围绕这种长时程 Agent 构建的产品会完全不同于今天的交互式工具。他的核心建议是：为模型将要去的方向构建，而不是为模型今天的状态构建。那些真正做得好的产品，往往围绕一种“理想能力”设计——今天可能只实现了 80%，但随着模型变强，某一天就会彻底跑通。

codex-1 模型会继续进化，工具链会日趋完善，人机协作的模式也会不断探索出新的可能。但有一件事不会变：当 AI Agent 越来越自主，工程师的核心竞争力会从“写代码的速度”转向“定义问题的精度”和“验证方案的能力”。

你不需要成为更快的打字员。你需要成为更好的塔台——发出清晰的指令，维护可靠的雷达，做出果断的决策。天空中的飞机会越来越多，但只要你的雷达系统足够好，你就能确保每一架都安全着陆。

1

特别说明：此文由ChatGPT生成，后续由我本人编辑、修改而成。

虚构的力量与理性的脆弱

七万年前，智人经历了一场认知革命。我们的祖先获得了一种前所未有的能力：相信并传播虚构的故事。正是这种能力，让智人能够建立超越血缘的大规模合作网络，最终征服了整个地球。

想象一下：一只黑猩猩无法说服另一只黑猩猩把香蕉交给它，通过承诺死后会在“黑猩猩天堂”得到无限香蕉作为回报。但智人可以。我们可以相信天堂、国家、人权、金钱——这些都是虚构的故事，但正是对这些故事的共同信仰，让陌生人之间能够合作，让帝国得以建立，让文明得以延续。

但这种能力是一把双刃剑。

我们的大脑进化出了相信故事的本能，却没有进化出区分真实与虚构的可靠机制。在漫长的演化史中，这不是什么大问题——我们的祖先需要相信部落的神话才能团结协作，至于这些神话是否“客观真实”，并不影响他们的生存。一个相信“我们部落的图腾是神圣的”的群体，可能比一个充满怀疑论者的群体更团结，更有战斗力。

从演化的角度看，“有用的虚构”往往比“无用的真相”更有生存优势。

问题在于，我们现在生活的世界与祖先的世界已经截然不同。我们需要理解气候变化、疫苗原理、经济规律——这些都需要准确的事实判断，而不是鼓舞人心的神话。但我们的大脑仍然是七万年前那个大脑，它天生更擅长相信故事，而不是验证事实。

反智主义：一个演化的遗产

当你在社交媒体上看到有人声称“微软程序员躲在下水道被洪水冲走”或“清朝只是殖民统治”，并发现成千上万人为此点赞时，你感到愤怒。这种愤怒是可以理解的。但如果我们想真正理解这个现象，就需要暂时放下情绪，从更宏观的视角来审视。

反智主义并非现代社会的产物，而是深植于智人心理结构中的古老倾向。

美国历史学家霍夫施塔特将反智主义定义为“对理性生活及其代表者的怨恨与怀疑”。但从演化心理学的角度看，这种“怨恨”有其深层逻辑：在我们祖先生活的小型狩猎采集群体中，那些声称拥有“特殊知识”的人往往是巫师或酋长，他们的“知识”常常是维护自身权力的工具。对这类人保持怀疑，在演化上是有利的。

试想，如果一个原始人对部落巫师的每一句话都深信不疑，他可能会被利用、被剥削。而一个保持适度怀疑的人，反而更可能保护自己的利益。这种对“精英”的本能警惕，被自然选择保留了下来。

换句话说，反智主义是智人对权威的本能警惕在现代社会的错位表达。

问题在于，现代社会的“知识精英”与原始社会的巫师有本质区别。科学家的知识是可验证的，医生的建议是基于证据的。但我们的大脑无法轻易区分这两者——它只看到“有人声称知道我不知道的事”，然后本能地产生警惕。

这种错位在受教育程度较低的群体中尤为明显，但绝不仅限于他们。事实上，一些高学历者同样会陷入阴谋论的泥潭——因为反智主义不是智力问题，而是心理结构问题。

后真相时代：当事实变得无关紧要

2016年，“后真相”（post-truth）被《牛津词典》选为年度词汇。这个词指的是一种状态：在公共舆论中，客观事实的影响力不如诉诸情感和个人信念。

但从历史的长河来看，“后真相”其实是常态，而不是例外。

在人类历史的绝大部分时间里，人们相信什么，取决于他们的部落、宗教、阶级告诉他们应该相信什么，而不是取决于客观证据。启蒙运动以来，“真相应该基于证据”这一观念才逐渐普及，但它从未完全战胜人类相信故事的本能。

我们今天所经历的，与其说是“真相的衰落”，不如说是“启蒙理想的局限性暴露”。我们曾天真地以为，只要教育普及、信息流通，人们就会自然而然地拥抱理性。但事实证明，更多的信息并不等于更多的理性——有时恰恰相反。

在信息过载的环境中，人们反而更依赖直觉和情感来筛选信息。那些能够激发强烈情绪反应的内容——无论真假——更容易获得注意力。这不是某个阴谋的结果，而是人类认知系统与现代信息环境不匹配的必然后果。

算法时代的认知失调

21世纪的信息环境对人类认知系统构成了前所未有的挑战。

我们的大脑在数百万年的演化中，适应的是一个信息稀缺的环境。在那个环境中，获取信息需要付出努力，而来自部落成员的信息通常是可靠的——撒谎者很快就会被识别并受到惩罚。我们的祖先生活在150人左右的群体中，每个人都认识每个人，声誉是最重要的货币。在这样的环境中，散播谣言的成本是很高的。

但今天，我们每天接收的信息量超过了祖先一生所能接触的总和。更糟糕的是，这些信息来自匿名的陌生人，通过精心设计的算法推送到我们面前。散播谣言的成本趋近于零，而收益——注意力、流量、金钱——却是实实在在的。

这些算法不关心真相，只关心一个指标：用户参与度。

研究表明，激发强烈情绪反应的内容——尤其是愤怒和恐惧——能够获得更高的传播率。麻省理工学院的一项研究发现，虚假新闻在Twitter上的传播速度比真实新闻快六倍。这不是因为人们故意选择谎言，而是因为谎言往往比真相更具戏剧性、更能激发情绪。

这意味着，在算法的选择压力下，最能存活和传播的“信息物种”往往不是最准确的，而是最能激发情绪的。我们可以把这称为“信息的自然选择”——只不过，这种选择的标准不是真实性，而是传播力。

这就是为什么那些荒谬的谣言能够获得数百万点赞，而严谨的辟谣却无人问津。这不是因为人类突然变蠢了，而是因为我们的认知系统正面对一个它从未进化出应对能力的新环境。

愤怒的生物学基础

当你看到反智内容时感到愤怒，这是一个有趣的现象，值得我们深入探讨。

从神经科学的角度看，愤怒是杏仁核对威胁的反应。杏仁核是大脑深处的一个杏仁状结构，负责处理情绪，尤其是恐惧和愤怒。当我们感知到威胁时，杏仁核会在意识层面做出反应之前就触发应激反应——心跳加速、肾上腺素分泌、肌肉紧张。

有趣的是，杏仁核无法区分物理威胁和抽象威胁。当我们的核心信念受到挑战时，大脑会将其解读为一种攻击——不是对身体的攻击，而是对我们建构的意义系统的攻击。这触发了与面对肉食动物时相似的应激反应。

神经科学家发现，当人们的政治信念受到挑战时，大脑中负责个人身份认同的区域会被激活。这意味着，对很多人来说，政治观点不仅仅是观点——它们是身份的一部分。挑战这些观点，就等于挑战他们是谁。

这解释了为什么与人争论政治或历史问题时，我们的心跳会加速、手会发抖、思维会变得不够清晰。我们的身体正在准备“战斗或逃跑”，尽管我们面对的只是屏幕上的文字。从大脑的角度看，这与面对一头愤怒的野牛没有本质区别。

但这里存在一个悖论：我们越是认同自己是“理性的人”，就越容易被反智言论激怒。因为这些言论不仅挑战了某个具体观点，还威胁到了我们的身份认同本身。“理性”已经成为我们身份的核心组成部分，任何对理性的攻击都会被我们的大脑解读为对自我的攻击。

这就是为什么知识分子往往是反智主义最激烈的批评者——同时也是最容易被它激怒的人。

信息茧房：部落主义的数字版本

社交媒体算法创造了一种新型的隔离机制——信息茧房。

在传统社会中，人类以部落为单位生活，部落成员共享同一套神话和价值观。这种“群体思维”在当时是有适应意义的：它增强了群体凝聚力，提高了集体行动的效率。一个观念统一的部落，比一个充满分歧的部落更有战斗力。

部落成员通过仪式、故事、共同的敌人来强化群体认同。“我们”与“他们”的界限清晰分明。这种二元思维方式被深深刻入了人类的心理结构。

今天的信息茧房本质上是部落主义在数字空间的重现。不同的是，现代“部落”不再由地理边界划分，而是由算法划分。每个人都生活在由自己的点击历史构建的信息世界中，与持不同观点的人越来越隔绝。

算法的逻辑很简单：给用户他们想看的东西，让他们停留更长时间。如果你点击了一个阴谋论视频，算法就会推荐更多类似内容。久而久之，你的信息世界就会被这类内容填满，而相反的观点则被系统性地排除在外。

在这样的环境中，极端观点不断得到强化。心理学家称之为“群体极化”——当一群持有相似观点的人聚在一起讨论时，他们最终的观点往往比讨论前更加极端。这是因为在回声室中，温和的声音被淹没，极端的声音被放大；表达极端观点的人获得更多认可，而表达温和观点的人则被边缘化。

“元清非中国”这样的论调，在其追随者的信息茧房内被反复回响，逐渐从一个边缘观点变成“不容置疑的真理”。试图从外部注入不同声音的人，往往被视为“敌对部落”的成员而遭到排斥。他们不仅不会被听取，反而会强化茧房内部的团结——“看，外面的人都在攻击我们，我们必须团结起来”。

这不是智力问题，而是结构问题。即便是高智商的人，在足够封闭的信息环境中也可能形成扭曲的世界观。历史上，许多聪明绝顶的人曾真诚地相信地球是平的、女巫是真实存在的、某个种族天生劣等——不是因为他们愚蠢，而是因为他们的信息环境不允许其他可能性存在。

争议经济学：注意力时代的悖论

在注意力经济时代，一个反直觉的现象出现了：争议本身成为了一种资源。

这是一种新型的经济学。在传统经济中，企业通过生产有价值的产品来获利。但在注意力经济中，最稀缺的资源是人们的注意力，而获取注意力的最有效方式往往是制造争议。

当某个UP主因争议性言论被封禁后粉丝不降反升，从90万涨到550万，这不是偶然。这背后有清晰的逻辑：

第一，“受害者叙事”激活了人类对弱者的同情本能。我们的大脑天生倾向于同情被压迫者、反抗权威。这是一种古老的心理机制——在原始社会，站在弱者一边往往是正确的策略。当追随者将其偶像塑造为“因说真话而被打压”的形象时，关注她就从单纯的娱乐行为转变为一种“正义行动”。人们不再是在消费内容，而是在“参与抵抗”。

第二，争议扩大了触达范围。在信息过载的时代，默默无闻是最大的威胁。那些原本不会接触到该UP主的人，因为争议而得知了她的存在。每一篇批评文章、每一条愤怒转发，都在帮助她扩大影响力。从某种意义上说，批评者成了免费的推广员。

第三，争议创造了身份认同。当人们因为支持某个争议人物而被外界批评时，他们的支持会变得更加坚定。这是因为他们现在不仅是在支持一个观点，更是在捍卫自己的判断力和身份。承认自己错了，就等于承认自己曾经是傻瓜。很少有人愿意这样做。

这揭示了一个令人不安的现实：在当前的信息生态中，批评往往会强化被批评者。你的愤怒转发可能正在帮助谣言传播者达成他们的目标。每一次你说“这太荒谬了”，都在为这个荒谬的内容增加曝光度。

这就是注意力经济的诡异之处：它让对与错、真与假变得不那么重要，重要的只是能否吸引注意力。

理性的局限与可能

面对这一切，理性的人能做什么？

首先，我们需要接受一个谦卑的事实：理性说服的力量是有限的。

数十年的心理学研究表明，当一个人的信念与其身份认同紧密绑定时，事实和逻辑几乎无法改变它。这就是所谓的“逆火效应”——当你向某人展示与其信念相矛盾的证据时，他们往往不会改变看法，反而会更加坚定原有立场。这是因为改变信念意味着否定自我，而人类的大脑会本能地抵抗这种否定。

辩论往往只会强化双方的既有立场。每个人都在寻找支持自己观点的证据，忽略相反的证据。这不是因为人们故意不诚实，而是因为我们的大脑就是这样运作的——确认偏误是人类认知的基本特征，而不是缺陷。

但这不意味着理性毫无用处。

2024年发表在《Science》杂志上的一项研究带来了一线希望：与AI进行对话可以使阴谋论信念降低约20%，效果持续至少两个月。研究者让参与者与GPT-4对话，讨论他们相信的阴谋论。令人惊讶的是，即使是那些根深蒂固的信奉者，也有相当一部分人在对话后改变了看法。

这个发现值得深思。AI之所以有效，可能恰恰因为它不是“敌对部落”的成员。它没有身份、没有立场、没有傲慢。它不会嘲笑你，不会居高临下，不会让你感到被攻击。它只是耐心地提供信息，回答问题，让对话者自己得出结论。

这暗示了人类理性说服失败的一个重要原因：不是因为证据不够充分，而是因为信使本身就被视为敌人。当一个“知识精英”试图纠正一个反智主义者时，后者首先感受到的不是论证的力量，而是被瞧不起的愤怒。这种情绪反应会在他有机会评估论证之前就关闭他的大脑。

AI没有这个问题。它不属于任何部落，因此不会激活部落防御机制。

这暗示了一种可能的策略：与其试图在情绪化的公共空间中说服他人，不如创造条件让人们自己去探索和质疑。如果有人相信阴谋论，与其与他争论，不如建议他去问问AI——让一个没有立场的实体来回答他的问题。

这里还有一个判断标准：如果一个人在与AI充分对话后仍然坚持某个观点，那他持有的可能不是事实判断，而是信仰。这没什么错，但你需要知道区别。事实可以被证据改变，信仰则不能。对于信仰，争论是徒劳的。

认知免疫系统的建设

既然我们无法改变外部信息环境的本质，我们能做的是增强自身的“认知免疫系统”。

正如身体的免疫系统帮助我们抵抗病原体，认知免疫系统帮助我们抵抗错误信息和情绪操控。这个系统不是天生的，需要刻意培养。

这需要从几个层面入手：

建立稳定的认识论基础。 你需要清楚自己相信什么，以及为什么相信。这不是盲目的信念，而是经过反思的立场。问自己：如果出现什么证据，我会改变这个看法？如果答案是“没有任何证据能改变我的看法”，那你持有的可能是信仰，而不是基于证据的判断。两者都可以存在，但你需要知道区别。

当你对自己的核心价值有清晰认知时，外部的噪音就更难动摇你。你不会因为看到一个反智视频就焦虑万分，因为你知道自己站在哪里。

理解信息系统的运作机制。 知识就是力量。当你明白算法如何放大极端内容、信息茧房如何形成、争议如何转化为流量、你的愤怒如何被利用，你就不会轻易被表象迷惑。

你会用更冷静的眼光看待那些“病毒式传播”的内容。当你看到一个让你愤怒的帖子时，你会先问：这是真的吗？谁从传播这个信息中获益？我的愤怒是否正在被利用？

控制信息摄入。 正如你会注意饮食健康，你也需要注意“信息饮食”健康。

主动选择信息来源，而不是被动接受算法推荐。订阅高质量的新闻来源，而不是依赖社交媒体信息流。减少碎片化信息的摄入，增加深度阅读的比例。一本好书给你的营养，可能超过一个月的社交媒体浏览。

定期给自己“数字断食”——一天不看社交媒体，看看感觉如何。很多人会惊讶地发现，离开信息流后，他们反而更平静、更有精力。

培养情绪觉察能力。 学会识别自己的情绪信号。当你感到心跳加速、呼吸急促、手指想要敲键盘回击时，这是你的杏仁核在接管大脑。

在这个时刻按下暂停键。深呼吸，离开屏幕，等情绪平复后再决定要不要回应。大多数时候，你会发现不回应是更明智的选择。

区分事实与信仰。 如前所述，如果一个人在面对所有相反证据后仍然坚持某个观点，那他持有的可能不是事实判断，而是信仰。事实是可以被证据改变的，信仰则不能。

对于信仰，争论是徒劳的。认识到这一点可以节省你大量的时间和精力。

历史的视角：我们来过这里

如果我们放宽视野，看看人类历史，就会发现：我们不是第一次面对这种挑战。

每一次信息技术的重大革新，都曾引发类似的焦虑和混乱。

印刷术发明后，欧洲经历了一个多世纪的宗教战争和社会动荡。廉价的印刷品让各种异端思想得以传播，教会的信息垄断被打破。当时的知识精英同样忧心忡忡：普通人能读书了，但他们能分辨真假吗？他们会不会被煽动者利用？

这些担忧不无道理。印刷术确实被用来传播谣言、煽动仇恨、制造迫害。但最终，印刷术也带来了科学革命和启蒙运动。社会逐渐发展出了新的制度和规范来应对印刷时代的挑战：版权法、诽谤法、学术同行评审、专业新闻业。

电报、广播、电视的发明同样引发过恐慌。每一次，都有人担心新技术会摧毁理性、瓦解社会。每一次，社会最终都适应了过来——虽然过程常常混乱而痛苦。

今天的互联网和社交媒体是最新的一次冲击。它的规模和速度前所未有，但本质上仍然是信息技术革命的一部分。我们正处于适应期的阵痛之中。

这个历史视角应该给我们一些安慰：人类文明总体上还是在进步的，只是这个进程比我们希望的更加缓慢和曲折。反智主义不会永远占上风。但改变需要时间——可能是几十年，甚至几代人。

与不完美的世界共处

最后，我们需要与一个不完美的现实和解。

反智主义不会消失。它是智人心理结构的一部分，只要人类存在，它就会以这样或那样的形式存在。我们能做的不是消灭它，而是将它控制在可接受的范围内。

你无法拯救每一个人，也无法纠正每一个错误。如果你试图这样做，你只会耗尽自己。

接受自己影响力的有限性，不是认输，而是智慧。你可以在自己的能力范围内做一些事情：保持理性，传播知识，影响身边的人，用行动而不只是言语来示范什么是理性的生活方式。这些小事加起来，长期来看，是有意义的。

但更重要的是，不要让这场与反智主义的对抗消耗你的生命能量。

你只有一次生命。这一生中有太多美好的事物值得探索：书籍、音乐、自然、爱、创造。不要把太多时间花在与网络上的陌生人争论上。那些时间本可以用来读一本好书、陪伴家人、锻炼身体、学习新技能。

智人是一个奇怪的物种。我们既能相信荒谬的谣言，也能发现宇宙的规律。我们既能被情绪操控，也能通过反思超越本能。我们既能建造奥斯维辛，也能创作贝多芬第九交响曲。正是这种矛盾性，定义了我们是谁。

在这个充满噪音的时代保持理性，既是一种智识上的选择，也是一种生存策略。你不需要赢得每一场辩论，你只需要保持清醒，过好自己的生活，成为你希望在这个世界上看到的改变。

这本身就是对反智主义最好的回应。