本文永久链接 – https://tonybai.com/2026/01/17/ai-era-cognitive-friction-as-your-last-moat

大家好，我是Tony Bai。

我们正在经历一场前所未有的知识通胀。

在 AI 时代，获取答案的成本已经降到了零。遇到 Bug？粘贴报错给 AI。写不出周报？给个主题让 AI 生成。想学新框架？让 AI 总结核心概念。

一切都变得无比丝滑，无比高效。

但你有没有发现，在这种“顺滑”的表象下，一种隐秘的症状正在蔓延：

• 离开 AI，你甚至很难完整地写出一个 500 字的逻辑闭环的观点。
• 面对一个稍微复杂的空白项目，如果不先问问 AI，你甚至不知道第一行代码该从哪里下笔。
• 你的思维变得越来越“平”，越来越像那个永远正确但毫无生气的标准答案。

《纽约时报》畅销书《五种财富》的作者Sahil Bloom 将这种症状称为 “AI Brain”（AI 大脑）。

这并不是说你变笨了，而是说你变钝了（Dull）。

就像一个长期坐轮椅的人，腿部肌肉必然会萎缩。当我们习惯了 AI 这种“认知轮椅”，我们大脑中负责深度思考、构建逻辑、处理混乱的那些神经连接，正在慢慢断开。

AI 消除了“摩擦”，但人类的智慧，恰恰诞生于“摩擦”之中。

摩擦的价值：为什么痛苦是必要的？

我们一直被教育要追求效率，要消除阻力。但在认知科学领域，这个逻辑是反的。

真正的学习和创造，发生于“First-pass Thinking”（第一遍思考）的挣扎中。

当你面对一个复杂的架构难题抓耳挠腮时，当你面对一张白纸试图构建文章结构感到挫败时，请珍惜这种痛苦。

这正是你的大脑在“举铁”，神经突触正在高强度地建立新的连接。这种不适感，是你正在突破认知边界的信号。

如果你在这个时刻按下了 AI 的生成键，它确实给了你一个完美的答案，就像剥好了的送到嘴边的虾肉。但你失去了什么？

你失去了咀嚼、消化、甚至感受饥饿的机会。你跳过了“构建心理模型”的过程，直接快进到了结果。

外包了痛苦，也就外包了成长的机会。

拯救大脑：4 条反直觉的“反内卷”法则

那么，我们该如何对抗这种“认知萎缩”？并不是要扔掉 AI 回归原始，而是要主动设计“认知摩擦”。

Sahil Bloom 基于个人洞察，为我们总结了 4 条适合技术人的自救法则：

法则一：拥抱“第一遍思考” (Embrace First-Pass Thinking)

原则： I write before I refine.（先写再润色，而不是先生成再修改。）

不要一上来就让 AI 写代码或写草稿。

强迫自己写出那个烂透了的初稿，强迫自己先在白板上画出架构图的草图。

因为 AI 只能基于概率生成“平均值”，只有你的“第一遍思考”才带有“方差”——也就是你的原创性（Originality）和个性。

下次写文档，不妨先自己写 300 字的大纲，再让 AI 补充；而不是让 AI 生成大纲，你来修改。

法则二：人为制造“认知摩擦” (Preserve Cognitive Friction)

原则： I sit with problems.（让问题飞一会儿。）

遇到难题，不要通过条件反射式地 Alt+Tab 切到 与大模型聊天的页面。

允许自己困惑，允许自己焦虑，允许自己在那里发呆 10 分钟。

这种“滞后”是必要的。它给了你的大脑后台进程运行的时间（思考脑启动）。很多深刻的洞察，往往是在你“卡住”的时候涌现的。

不妨设定一个“无 AI 时间窗口”。比如每天上午的头 2 小时，强制断开 AI 助手，只靠自己的大脑工作。

法则三：做少，但做深 (Do Less, But Deeper)

原则： One kick 10,000 times.（不怕千招会，只怕一招精。）

AI 让我们能做 100 件事：能写前端、能写后端、能画图、能剪视频。但每件事我们都只能做到 60 分的平庸水平。

既然 AI 把广度的成本降到了零，那么深度就成了唯一的护城河。

试试利用 AI 帮你处理那些琐碎的、低认知的杂事，然后把节省下来的精力，全部投入到那个 1% 的核心领域中去。钻研到连 AI 都无法回答的深度。

法则四：回归“物理世界” (Do More Human Things)

原则： Stay anchored.（保持锚定。）

AI 没有身体，没有痛感，没有疲惫。

人类的直觉、审美和同理心，建立在我们肉身的经验之上，这是 AI 永远无法模拟的底色。

动起来！去面对面交流，去感受代码运行在真实物理设备上的延迟，去用身体感受世界。这些“肉身经验”是你作为人类的最后防线。

小结：你的未来，取决于你拒绝让 AI 做什么

我们正在进入一个“分化”的时代。

• 一类人把 AI 当作拐杖，离了它就寸步难行，最终沦为算力的附庸。
• 另一类人把 AI 当作外骨骼，他们依然拥有强壮的肉体（核心思考力），AI 只是放大了他们的力量。

区别在于边界的划分。

Your future is defined by what you refuse to let AI do.
（你的未来，取决于你拒绝让 AI 做什么。）

请守住你的“思考领地”。

我可以让 AI 帮我优化代码，但我决不允许它替我设计架构；
我可以让 AI 帮我润色文字，但我决不允许它替我定义观点。

在这个充满“灰度”和“平庸”的 AI 生成世界里，请保持你大脑的“色彩”和“锋利(Sharp)”。

Don’t become dull.

你的“戒断”计划

读完这篇文章，你是否也意识到了自己对 AI 的过度依赖？如果让你现在关掉 AI 助手，你能独立完成手头的工作吗？你打算如何找回自己的“认知摩擦”？

欢迎在评论区立下你的 Flag，或者分享你的“人机边界”思考！让我们一起守护大脑的锋利。

如果这篇文章戳中了你的痛点，别忘了点个【赞】和【在看】，并转发给身边那些“沉迷 AI”的朋友，给他们提个醒！

深度实战：构建“以人为本”的 AI 工作流

在 AI 原生开发中，我们同样强调：User 必须是机长，AI 只是副驾驶。

如何在利用 AI 提效的同时，还能迫使自己进行深度的架构思考？

如何在 Spec-Driven Development (SDD) 中，保留人类的“第一遍思考”权利，让 AI 只做执行者？

欢迎关注我的极客时间专栏《AI原生开发工作流实战》。

在这里，我们不教你如何偷懒，我们教你如何利用 AI 进行更高维度的认知进化。

扫描下方图片二维码，开启你的进化之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2026/01/11/21-lessons-from-google-engineer

大家好，我是Tony Bai。

“当我 14 年前加入 Google 时，我以为这份工作就是写出优秀的代码……我只说对了一部分。我待得越久，就越意识到，那些真正茁壮成长的工程师，不一定是最好的程序员——他们是那些懂得如何驾驭代码周围一切的人：人、政治、协同和模糊性。”

这段话，出自 Google 资深工程师 Addy Osmani 的一篇深刻反思——《在 Google 14 年的 21 条经验》。这篇文章，如同淬炼了 14 年的智慧结晶，几乎没有谈论任何具体的技术栈，却精准地描绘出了一位卓越工程师的成长画像。

这 21 条“法则”，并非关于某种转瞬即逝的技术，而是关于那些在项目、团队、公司之间反复出现的永恒模式。它们不是一场与外部世界的战争，而是一场关于自我提升的漫长“修炼”。这是一份珍贵的“心法”，能帮助我们在这场修炼之路上，走得更远、更稳。本文将为你逐一解读。

1. 最好的工程师痴迷于解决“用户问题”，而非“技术问题”

这是工程师“修炼”之路的第一心法：放下执念。

放下对特定技术的迷恋，将自我从“工具的使用者”升华为“问题的解决者”。

“用户痴迷”意味着走出 IDE，去阅读支持工单，去和真实用户交谈，去观察他们如何在你的产品中挣扎。

当你真正理解了用户的“痛”，你往往会发现，那个最优雅的解决方案，远比你最初设想的任何复杂技术都要简单。

2. 做到正确很廉价，而“一起”做到正确才是真正的修行

你可以在每一次技术辩论中都“赢”，但最终输掉整个项目。

真正的“修为”，不在于证明自己正确，而在于创造一个安全的空间，让团队能够共同对问题达成一致，并对自己的确定性保持怀疑。

记住：“观点强硬，但立场松动 (Strong opinions, weakly held)。”

3. 偏爱行动。交付。你可以修改一个糟糕的页面，但无法修改一个空白的页面

对完美的追求是麻痹剂，是“心魔”。

完美的架构不会在纯粹的冥想中诞生，它诞生于与现实的接触。

先做出来，再做对，再做得更好。

交付那个让你感到“有点尴尬”的 MVP。

一个粗糙的原型所能带来的真实反馈，远超一个月闭门造车的理论辩论。

4. 清晰即资深，聪明是开销

编写“聪明”的代码，是工程师证明能力的本能。

但真正的软件工程，是在时间和团队协作的维度上展开的。

清晰性不是一种风格偏好，而是一种运营风险的降低。

你的代码，是一份写给未来某个凌晨三点需要维护它的陌生人的“战略备忘录”。

资深的工程师，早已学会在他们的“修炼”中，用清晰性去交换那份无关紧要的“聪明”。

5. 新奇是一笔贷款，你将在故障、招聘和认知开销中偿还

像一个预算有限的组织一样，谨慎地对待你的“创新代币”。

只在你拥有独特优势的地方进行创新，其他所有事情，都应该默认选择“无聊”的技术，因为“无聊”意味着失败模式是已知的。

记住，“最好的工具”，常常是那个“在最多场景下最不坏的工具”。

6. 你的代码不会为你代言，人会

以为“好的工作会自己说话”，是工程师“修炼”生涯早期最大的错觉。

代码静静地躺在仓库里，它不会在晋升会议上为你辩护。

你需要将你的工作和价值，以一种可被他人理解和传播的方式呈现出来：写清晰的文档、做有影响力的分享、主动沟通你的成果。

7. 最好的代码，是那些你从未写下的代码

工程文化崇尚创造，但删除代码往往比增加代码更能改善一个系统。

你没有写下的每一行代码，都是你永远不必去调试、维护或解释的一行代码。

在动手构建之前，请先用“无为”的智慧拷问自己：“如果我们就是……不这么做，会发生什么？”

8. 在规模化面前，即使你的 Bug 也有用户

当用户足够多时，你的系统的每一个可观测行为，无论你是否承诺过，都会成为一种事实上的依赖。

有人正在爬取你的 API，有人正在自动化你的“怪癖”，有人正在缓存你的 Bug。

这意味着，兼容性本身就是一种产品。你不能再将修复 Bug 视为“维护”，将开发新功能视为“真正的工作”。

9. 大多数“慢”团队，其实是“失调”的团队

当项目拖延时，我们的本能是归咎于执行力：人手不够、技术不行、工作不努力。

但真正的瓶颈，往往在于协同失败 (Alignment Failure)——团队在做错误的事情，或者以不兼容的方式在做正确的事情。

资深工程师会花费更多时间去澄清方向、接口和优先级，而不是单纯地“更快地写代码”。

10. 关注你能控制的，忽略你不能的

在大型组织中，组织架构调整、管理层决策、市场变化……无数变量都在你的控制范围之外。

为这些事情焦虑，是在浪费你宝贵的精力。

卓越的工程师，会战略性地专注于他们的“影响圈”：你能控制你代码的质量，你能控制你如何响应变化，你能控制你学到了什么。

这是一种专注的“禅定”。

11. 抽象并未消除复杂性，只是将其转移到了你 on-call 的那一天

每一个抽象，都是一次“我未来不需要理解其底层”的赌博。

有时你会赌赢，但抽象总会泄露。

资深工程师之所以坚持学习底层知识，并非出于怀旧，而是出于对“凌晨三点，当你独自面对一个失效的抽象时”的敬畏。

12. 写作倒逼清晰。想学得更快，就去教别人

当你试图向他人解释一个概念时——无论是在文档中、演讲中，还是 Code Review 的评论里——你会立刻发现自己理解上的盲点。

把一个东西教给别人，本质上是在调试你自己的心智模型。

这是最高效的“利己”的学习法门。

13. 那些让其他工作成为可能的工作，无价且无形

“胶水工作”——文档、新人引导、跨团队协调、流程改进——至关重要。

但如果你无意识地、仅仅出于“乐于助人”去做这些事，它们会吞噬你的时间，让你偏离技术主航道。

诀窍在于，有意识地去做，为它设定时间盒，将它转化为文档、模板、自动化等可见的成果，让它成为你明确的影响力，而非模糊的“性格特质”。

14. 如果你赢得了每一次辩论，你可能正在积累无声的抵制

当你“赢”得太轻松时，通常意味着事情不对劲了。

人们不再与你争论，不是因为你彻底说服了他们，而是因为他们已经放弃了尝试。

而这份未解的分歧，将会在未来的执行层面，以“神秘的阻力”的形式爆发出来。

真正的协同，需要你真正去理解他人，并有时公开地改变自己的想法。

15. 当一个指标成为目标时，它便不再是一个好的指标

古德哈特定律的经典再现。

人类会为了被测量的东西而优化。

资深的做法是，用一组成对的指标来响应管理需求（例如，速度 vs. 质量），并坚持解读趋势，而非崇拜某个具体的阈值。

16. 承认“我不知道”，比假装知道能创造更多安全感

当一个领导者或资深工程师坦诚自己的不确定性时，他实际上是在给予整个团队“提问”和“犯错”的许可。

这会创造一种心理安全的环境，让问题在爆炸前被暴露出来。

反之，一个“永远正确”的领导者，只会培养出一群沉默的下属和一堆隐藏的地雷。

17. 你的人脉，比你做过的任何一份工作都更长久

职业生涯早期，我们容易专注于工作本身而忽略人际交往。

这是一个巨大的错误。

那些在公司内外投资于人际关系的同事，在数十年后，会收获巨大的回报。

你的工作不是永恒的，但你建立的信任是。

18. 大多数性能的胜利，源于“移除工作”，而非“增加聪明”

当系统变慢时，我们的本能是增加缓存、并行处理、或者换用更聪明的算法。

但更具影响力的胜利，往往来自于问一个更根本的问题：“我们正在计算的这些东西，真的有必要吗？”

删除不必要的工作，远比把必要的工作做得更快要有效得多。

最快的代码，是那段从未运行过的代码。

19. 流程的存在是为了减少不确定性，而不是为了制造文书工作

最好的流程，能让协作更容易，让失败的代价更便宜。

而最坏的流程，是“官僚主义戏剧”——它的存在不是为了帮助，而是在出问题时用来甩锅。

如果你无法解释一个流程如何降低风险或增加清晰度，那它很可能就是纯粹的开销。

20. 最终，时间会比金钱更宝贵。请据此行事

职业生涯早期，你用时间换金钱。

但在某个临界点之后，这个公式会反转。

时间是唯一不可再生的资源。

答案不是“不要努力工作”，而是“清楚你在交易什么，并深思熟虑地做出交易。”

21. 没有捷径，但有复利

专业知识，来自于经年累月的刻意练习。

但这里有希望的部分：学习是具有复利效应的。

你建立的每一个心智模型，你总结的每一条经验教训，都会成为你未来解决更复杂问题的“可复用原语”。

将你的职业生涯视为复利投资，而非一张张彩票。

小结：修炼的核心永远是人

Addy Osmani 的 21 条经验，最终可以归结为几个核心思想：保持好奇，保持谦逊，并永远记住，修炼的核心是人——你为之构建的用户，以及与你一同构建的队友。

对于我们工程师而言，这意味着，职业生涯的成长，是一场双螺旋式的攀升。

技术能力的“硬实力”是我们的根基，但决定我们最终能达到何种“境界”的，往往是沟通、协作、权衡、同理心这些看似“软”的、关于人的智慧。

这场“代码之外的修炼”，道阻且长，但行则将至。

资料链接：https://addyo.substack.com/p/21-lessons-from-14-years-at-google

你的“第22条”法则

读完这21条法则，相信你一定心有戚戚焉。在你自己的职业生涯中，是否有哪一条“生存法则”是你用惨痛教训换来的？或者，你觉得还有什么重要的经验是这21条没有覆盖到的？

欢迎在评论区分享你的独家心法！ 让我们一起汇聚更多智慧。

如果这篇文章给了你新的启发，别忘了点个【赞】和【在看】，并转发给身边正在迷茫的工程师朋友，也许这就是他破局的关键！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。