<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Tony Bai &#187; 程序员</title>
	<atom:link href="http://tonybai.com/tag/%e7%a8%8b%e5%ba%8f%e5%91%98/feed/" rel="self" type="application/rss+xml" />
	<link>https://tonybai.com</link>
	<description>一个程序员的心路历程</description>
	<lastBuildDate>Sat, 11 Apr 2026 00:16:11 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>看了 100 小时教程，你为什么依然写不好代码？扒开技术人的“成长环”真相</title>
		<link>https://tonybai.com/2026/03/22/stop-tactical-diligence-start-stretch-zone-growth/</link>
		<comments>https://tonybai.com/2026/03/22/stop-tactical-diligence-start-stretch-zone-growth/#comments</comments>
		<pubDate>Sat, 21 Mar 2026 23:51:52 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[技术志]]></category>
		<category><![CDATA[ActionQuantity]]></category>
		<category><![CDATA[Agent]]></category>
		<category><![CDATA[AgentCommander]]></category>
		<category><![CDATA[AIAgents]]></category>
		<category><![CDATA[AI智能体]]></category>
		<category><![CDATA[ChangeQuantity]]></category>
		<category><![CDATA[CognitiveAwakening]]></category>
		<category><![CDATA[ComfortZone]]></category>
		<category><![CDATA[DifficultyZone]]></category>
		<category><![CDATA[DynamicRadarChart]]></category>
		<category><![CDATA[EdgeEffortRule]]></category>
		<category><![CDATA[FlowState]]></category>
		<category><![CDATA[Go]]></category>
		<category><![CDATA[Golang]]></category>
		<category><![CDATA[KnowledgeAccumulation]]></category>
		<category><![CDATA[LearningQuantity]]></category>
		<category><![CDATA[Minimalism]]></category>
		<category><![CDATA[Programmer]]></category>
		<category><![CDATA[SkillDepreciation]]></category>
		<category><![CDATA[SoftwareEngineering]]></category>
		<category><![CDATA[StrategicLaziness]]></category>
		<category><![CDATA[StretchZone]]></category>
		<category><![CDATA[SystemArchitect]]></category>
		<category><![CDATA[TacticalDiligence]]></category>
		<category><![CDATA[TechnicalDebt]]></category>
		<category><![CDATA[ThoughtQuantity]]></category>
		<category><![CDATA[TutorialHell]]></category>
		<category><![CDATA[动态雷达图]]></category>
		<category><![CDATA[困难区]]></category>
		<category><![CDATA[学习量]]></category>
		<category><![CDATA[心流状态]]></category>
		<category><![CDATA[思考量]]></category>
		<category><![CDATA[战术勤奋]]></category>
		<category><![CDATA[战略懒惰]]></category>
		<category><![CDATA[技术债]]></category>
		<category><![CDATA[技能贬值]]></category>
		<category><![CDATA[拉伸区]]></category>
		<category><![CDATA[改变量]]></category>
		<category><![CDATA[教程地狱]]></category>
		<category><![CDATA[智能体]]></category>
		<category><![CDATA[智能体指挥官]]></category>
		<category><![CDATA[极简主义]]></category>
		<category><![CDATA[知识积累]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[系统架构师]]></category>
		<category><![CDATA[舒适区]]></category>
		<category><![CDATA[行动量]]></category>
		<category><![CDATA[认知觉醒]]></category>
		<category><![CDATA[软件工程]]></category>
		<category><![CDATA[边缘努力法则]]></category>

		<guid isPermaLink="false">https://tonybai.com/?p=6086</guid>
		<description><![CDATA[本文永久链接 &#8211; https://tonybai.com/2026/03/22/stop-tactical-diligence-start-stretch-zone-growth 大家好，我是Tony Bai。 在这个技术大爆炸的时代，我见过了太多极其“勤奋”的程序员： 他们会在各大技术平台上收藏几百篇诸如《Go语言进阶课》、《AI原生开发工作流实战》&#8230; &#8230;的专栏文章，硬盘里塞满了从各种渠道搞来的“AI大模型实战课”视频。他们熬夜看教程、做笔记，甚至在通勤的地铁上都在听技术播客或专栏课程。 但如果你在半年后去问他：“你用 Go 写过什么高并发系统吗？”或者“你开发过什么 AI Agent 吗？” 他大概率会尴尬地挠挠头：“还没，教程太长了还没看完，或者看了感觉太难，平时工作里也用不到……” 为什么看了 100 小时的教程，你依然写不好代码？为什么收藏了无数的技术干货，你的核心竞争力却依然在原地踏步？ 这其实是整个技术圈最普遍、也最隐蔽的陷阱：用“战术上的勤奋”，掩盖了“战略上的懒惰”。 今天，我想跨界借用知名认知作家周岭在《认知觉醒》一书中的核心理论，彻底撕开这层“假性努力”的面纱，带你重新构建一张属于技术人的“动态雷达图”，教你如何真正走出舒适区，在这个 AI 狂飙的时代完成硬核的自我进化。 舒适区与困难区的两极震荡：为什么你总是半途而废？ 在《认知觉醒》中，周岭提出了一个极其精准的人类能力分布模型：“舒适区—拉伸区—困难区”。 这三个同心圆，完美地映射了我们程序员的日常状态： 舒适区（最内层） 在这个区域里，事情对你来说轻车熟路，闭着眼睛都能敲出代码。比如，写一个简单的 CRUD 接口、配置一下 Nginx、复制粘贴一段以前写过的表单验证逻辑。 但问题就在于人类的天性是“避难趋易”的。 长年停留在舒适区，虽然毫无压力，但会让你陷入“无聊而走神”的状态，最终导致技术能力的彻底停滞。在这个区域里，你不是在拥有 10 年经验，你只是把 1 年的经验用了 10 年。 困难区（最外层） 这个区域里的任务，远远超出了你当前的能力边界。比如，你连 Python 都没写熟，就发誓要在一周内从零手搓一个 Transformer 模型；或者你刚学完 Go 基础语法，就想去给 Kubernetes 的底层调度器提核心 PR。 人类的另一个天性是“急于求成，总想一口吃成个胖子”。贸然跨入困难区，你会遇到无数个令人绝望的 Error 报错，巨大的挫败感会瞬间击溃你的自信心，让你产生“我可能不适合干这个”的错觉，最终因畏惧而逃避。 绝大多数技术人的悲剧在于：他们终日在这两极之间做着无效的“钟摆运动”。 平时在公司里做着无聊的 CRUD（舒适区），下班后突然焦虑爆发，立下宏愿要去啃最硬核的底层源码（困难区），被虐得体无完肤后，心灰意冷地退回到继续写 [...]]]></description>
			<content:encoded><![CDATA[<p><img src="https://tonybai.com/wp-content/uploads/2026/stop-tactical-diligence-start-stretch-zone-growth-1.png" alt="" /></p>
<p><a href="https://tonybai.com/2026/03/22/stop-tactical-diligence-start-stretch-zone-growth">本文永久链接</a> &#8211; https://tonybai.com/2026/03/22/stop-tactical-diligence-start-stretch-zone-growth</p>
<p>大家好，我是Tony Bai。</p>
<p>在这个技术大爆炸的时代，我见过了太多极其“勤奋”的程序员：</p>
<p>他们会在各大技术平台上收藏几百篇诸如《<a href="http://gk.link/a/12yGY">Go语言进阶课</a>》、《<a href="http://gk.link/a/12EPd">AI原生开发工作流实战</a>》&#8230; &#8230;的专栏文章，硬盘里塞满了从各种渠道搞来的“AI大模型实战课”视频。他们熬夜看教程、做笔记，甚至在通勤的地铁上都在听技术播客或专栏课程。</p>
<p>但如果你在半年后去问他：“你用 Go 写过什么高并发系统吗？”或者“你开发过什么 AI Agent 吗？”</p>
<p>他大概率会尴尬地挠挠头：“还没，教程太长了还没看完，或者看了感觉太难，平时工作里也用不到……”</p>
<p><strong>为什么看了 100 小时的教程，你依然写不好代码？为什么收藏了无数的技术干货，你的核心竞争力却依然在原地踏步？</strong></p>
<p>这其实是整个技术圈最普遍、也最隐蔽的陷阱：<strong>用“战术上的勤奋”，掩盖了“战略上的懒惰”。</strong></p>
<p>今天，我想跨界借用知名认知作家周岭在《<a href="https://book.douban.com/subject/36906244/">认知觉醒</a>》一书中的核心理论，彻底撕开这层“假性努力”的面纱，带你重新构建一张属于技术人的“动态雷达图”，教你如何真正走出舒适区，在这个 AI 狂飙的时代完成硬核的自我进化。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2026/agentic-software-engineering-qr.png" alt="" /></p>
<h2>舒适区与困难区的两极震荡：为什么你总是半途而废？</h2>
<p>在《认知觉醒》中，周岭提出了一个极其精准的人类能力分布模型：<strong>“舒适区—拉伸区—困难区”</strong>。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2026/stop-tactical-diligence-start-stretch-zone-growth-2.png" alt="" /></p>
<p>这三个同心圆，完美地映射了我们程序员的日常状态：</p>
<ol>
<li><strong>舒适区（最内层）</strong> </li>
</ol>
<p>在这个区域里，事情对你来说轻车熟路，闭着眼睛都能敲出代码。比如，写一个简单的 CRUD 接口、配置一下 Nginx、复制粘贴一段以前写过的表单验证逻辑。</p>
<p>但问题就在于人类的天性是“避难趋易”的。</p>
<p>长年停留在舒适区，虽然毫无压力，但会让你陷入“无聊而走神”的状态，最终导致技术能力的彻底停滞。在这个区域里，你不是在拥有 10 年经验，你只是把 1 年的经验用了 10 年。</p>
<ol>
<li><strong>困难区（最外层）</strong></li>
</ol>
<p>这个区域里的任务，远远超出了你当前的能力边界。比如，你连 Python 都没写熟，就发誓要在一周内从零手搓一个 Transformer 模型；或者你刚学完 Go 基础语法，就想去给 Kubernetes 的底层调度器提核心 PR。</p>
<p>人类的另一个天性是“急于求成，总想一口吃成个胖子”。贸然跨入困难区，你会遇到无数个令人绝望的 Error 报错，巨大的挫败感会瞬间击溃你的自信心，让你产生“我可能不适合干这个”的错觉，最终因畏惧而逃避。</p>
<p><strong>绝大多数技术人的悲剧在于：他们终日在这两极之间做着无效的“钟摆运动”。</strong></p>
<p>平时在公司里做着无聊的 CRUD（舒适区），下班后突然焦虑爆发，立下宏愿要去啃最硬核的底层源码（困难区），被虐得体无完肤后，心灰意冷地退回到继续写 CRUD（舒适区）。</p>
<h2>真正的成长密码：寻找你的“拉伸区”（边缘努力法则）</h2>
<p>那么，破局之道在哪里？</p>
<p>答案就藏在舒适区和困难区中间的那个极其狭窄、却又蕴含着巨大能量的环带——<strong>拉伸区（舒适区边缘）</strong>。</p>
<p>在拉伸区里，任务具有一定的挑战性，你无法靠肌肉记忆直接完成，但只要你稍微踮起脚尖，查一查资料，努努力就能触碰到。</p>
<p><strong>这里既有未知的挑战，又有可达成的成就感。只有在这个区域，你才能进入所谓的“心流（Flow）”状态，获得最快的进步。</strong></p>
<p><img src="https://tonybai.com/wp-content/uploads/2026/stop-tactical-diligence-start-stretch-zone-growth-3.png" alt="" /></p>
<p>但这还不够。为了指导我们如何在拉伸区行动，《认知觉醒》中提出了一个更为深刻的“成长微观规律”，它揭示了学习、思考、行动和改变之间的权重关系：</p>
<blockquote>
<p><strong>改变量 > 行动量 > 思考量 > 学习量</strong></p>
</blockquote>
<p>这简直是为程序员量身定制的“照妖镜”！让我们来对照一下：</p>
<ul>
<li><strong>学习量（权重最低）：</strong> 买了一门极客时间的专栏，看完了 10 个视频。这叫输入，你只是把别人的知识存进了大脑的短期记忆里。</li>
<li><strong>思考量：</strong> 看完视频后，你开始琢磨：“哦，原来 Go 的 Channel 底层是一个带锁的环形队列，怪不得会阻塞。”你不仅看了，还理解了。</li>
<li><strong>行动量：</strong> 你打开 IDE，凭着记忆和文档，自己手敲了一段用 Channel 实现的生产者-消费者模型代码，并成功跑通了。</li>
<li><strong>改变量（权重最高）：</strong> 你发现自己手敲的这个并发模型，正好可以用来优化你们公司那个极其缓慢的“每日数据导出”报表脚本。你把它重构并部署上线了，报表导出速度提升了 5 倍！</li>
</ul>
<p><strong>如果你不盯住内层的“改变量”和“行动量”，那么你在表层投入再多的“学习量”也只会事倍功半。</strong></p>
<p>无数人陷入“教程地狱（Tutorial Hell）”的原因，就是他们只停留在了“学习量”的层面，从未产生过“改变量”。</p>
<h2>实战推演：如何利用“拉伸区”构建你的技术雷达图？</h2>
<p>有了宏观的规律支撑，我们该如何将它落地到日常的技术精进中？</p>
<p>优秀的程序员，脑海中都有一张自己的<strong>“动态技术雷达图”</strong>。这张图不是静止的，而是通过在各个技能维度的“拉伸区”不断向外扩张，最终形成一个巨大的“成长环”。</p>
<p>接下来，我将以个人比较熟悉，也是当前较为受欢迎的两个技能领域——<strong>Go 语言高并发开发</strong> 与 <strong>AI Agent 原生开发</strong> 为例，和大家聊聊如何设计自己的拉伸区项目，完成从“学习”到“改变”的闭环。</p>
<h3>案例一：Go 语言开发者的拉伸区跃迁</h3>
<p><strong>现状诊断（舒适区）：</strong></p>
<p>你已经通过《<a href="http://gk.link/a/10AVZ">Go语言第一课</a>》掌握了 Go 的基础语法，能熟练使用 Gin 框架写 HTTP 接口，能用 GORM 对 MySQL 进行增删改查。每天的工作就是对着产品需求堆代码。如果继续这样，三年后你依然是一个高级的“CRUD 工程师”。</p>
<p><strong>急于求成（困难区-千万别去）：</strong></p>
<p>发誓要用 Go 写一个分布式的关系型数据库，或者直接去扒 Go 语言 runtime 包里垃圾回收器（GC）的三色标记法 Go /汇编源码。你会在无尽的底层细节中崩溃。</p>
<p><strong>精心设计的“拉伸区项目”：构建一个高并发的压测小工具</strong></p>
<p>不要去背八股文了，给自己设定一个能触及“改变量”的拉伸区实战项目：用 Go 实现一个类似 ab (Apache Bench) 的高并发压测工具。</p>
<ul>
<li><strong>步骤 1（思考量）：</strong> 为什么原来的单线程脚本发请求那么慢？Go 的 Goroutine 如何做到极轻量级的并发？</li>
<li><strong>步骤 2（行动量 &#8211; 踏入拉伸区）：</strong>
<ul>
<li><strong>拉伸点 1：</strong> 不用任何第三方库，仅用标准库 net/http 发起请求。</li>
<li><strong>拉伸点 2：</strong> 使用 sync.WaitGroup 来控制并发的启动和等待。</li>
<li><strong>拉伸点 3：</strong> 引入 Channel。当并发量达到 10 万时，无脑 go func() 会导致系统资源枯竭。你必须学习使用带缓冲的 Channel 来实现一个<strong>协程池（Worker Pool）</strong>，限制最大并发数。</li>
<li><strong>拉伸点 4：</strong> 引入 sync.Mutex 或 atomic 包，来安全地统计成功请求数、失败数、平均延迟等数据。</li>
</ul>
</li>
<li><strong>步骤 3（改变量 &#8211; 形成闭环）：</strong> 工具写完了。你把它编译成二进制文件扔给测试团队，告诉他们：“以后压测咱们自己的接口，就用我写的这个工具，不需要装乱七八糟的依赖了。”</li>
</ul>
<p>这个项目完美地避开了极其枯燥的底层源码（困难区），又跳出了无脑的框架调用（舒适区）。在这个拉伸区里，你被迫真实地操作了 Goroutine、Channel、锁和原子操作，你的雷达图在“并发编程”这个维度上，成功向外扩张了一大圈。</p>
<h3>案例二：向 AI 原生开发者进化的拉伸区</h3>
<p><strong>现状诊断（舒适区）：</strong></p>
<p>你每天都在用 Copilot 或 Claude Code帮你写代码、润色邮件。你买了几十块钱的 API，用 Python 写了一个脚本，把用户的输入传给 API，然后把结果打印出来。你觉得自己“懂 AI 开发了”。</p>
<p><strong>急于求成（困难区-千万别去）：</strong></p>
<p>去啃 PyTorch 底层逻辑，买几块 4090 显卡，试图自己微调（Fine-tune）一个千亿参数的大模型，或者试图手搓一个全知全能的超级 AGI。</p>
<p><strong>精心设计的“拉伸区项目”：开发一个带“工具调用（Function Calling）”的本地私有知识库助手</strong></p>
<p>从“AI 使用者”到“AI 架构师”的跨越，不在于你能记住多少 Prompt 魔法，而在于你是否懂得如何将 AI 与外部物理世界连接起来。</p>
<ul>
<li><strong>步骤 1（思考量）：</strong> 大模型是没有记忆的，也没有最新数据。如何让大模型能读取我电脑里今天刚生成的日志文件？</li>
<li><strong>步骤 2（行动量 &#8211; 踏入拉伸区）：</strong>
<ul>
<li><strong>拉伸点 1：告别单轮对话。</strong> 学习使用 LLM 的 API 维护一段连续的记忆上下文（Context Management）。</li>
<li><strong>拉伸点 2：攻克 Function Calling（核心拉伸）。</strong> 仔细研读 OpenAI 或 Anthropic 的官方文档，用代码定义一个工具（比如：search_local_file 函数）。这要求你将大模型的自然语言输出，精确地转换为本地函数的结构化参数输入。</li>
<li><strong>拉伸点 3：拥抱最新协议。</strong> 如果你有野心，可以去挑战去年爆火的 MCP（Model Context Protocol）协议，编写一个属于你自己的 MCP Server，让流行的 Agent 工具（如 Cursor 或 Claude Desktop）能够安全地访问你的本地数据库。</li>
</ul>
</li>
<li><strong>步骤 3（改变量 &#8211; 形成闭环）：</strong> 你不再在网页端复制粘贴代码了。你用 Go 或 Python 跑起了一个常驻终端的服务。当你问它“昨天生产环境的报错主要集中在哪里？”时，你的 Agent 自动调用了本地 grep 命令，分析了日志，并给你输出了一份完美的摘要。你的工作效率得到了实质性的改变！</li>
</ul>
<p>这个项目没有要求你去懂深奥的神经网络微积分（困难区），但它逼着你掌握了 AI 原生开发中最核心的“Agent 工具编排”能力。在这个拉伸区里，你从一个“提示词念稿人”，正式蜕变为了一名“AI 指挥官”。</p>
<h2>小结：复利曲线与舒适区边缘的完美交响</h2>
<p>回过头来看看，那些真正牛逼的顶级技术专家，难道他们天生就拥有超凡的智商吗？</p>
<p>绝大多数情况下并不是。</p>
<p>他们的秘密武器，仅仅是<strong>日复一日地在“舒适区的边缘”进行着微小但坚实的努力。</strong></p>
<p>每一次在拉伸区里解决掉一个陌生的 Bug，每一次将一个跑在命令行的脚本优化成一个稳定的后台服务，每一次将你的所学变成真正提高团队效率的工具（改变量），都是在你的技术雷达图上，刻下的一道深深的成长环。</p>
<p>不要再去囤积那些你永远不会看的几十个 G 的视频教程了。</p>
<p>关掉网页，打开你的 IDE。找出你日常开发中最让你感到繁琐的一件小事，稍微踮起脚尖，用你刚学的一点点新知识去干掉它。</p>
<p>去拥抱你的“拉伸区”吧。因为只有在那里，你才能真正体会到作为一名工程师，掌控系统、改变世界的顶级快感。</p>
<hr />
<p><strong>今日互动探讨：</strong></p>
<p>看完这篇文章，你觉得你目前的日常工作有百分之多少是在“舒适区”？如果你要在今年规划一个自己的“拉伸区”硬核项目，你会选择做什么？</p>
<p>欢迎在评论区分享你的反思与计划！</p>
<hr />
<p>还在为“复制粘贴喂AI”而烦恼？我的新专栏 <strong>《<a href="http://gk.link/a/12EPd">AI原生开发工作流实战</a>》</strong> 将带你：</p>
<ul>
<li>告别低效，重塑开发范式</li>
<li>驾驭AI Agent(Claude Code)，实现工作流自动化</li>
<li>从“AI使用者”进化为规范驱动开发的“工作流指挥家”</li>
</ul>
<p>扫描下方二维码，开启你的AI原生开发之旅。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/ai-native-dev-workflow-qr.png" alt="" /></p>
<hr />
<p>你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？</p>
<ul>
<li>想写出更地道、更健壮的Go代码，却总在细节上踩坑？</li>
<li>渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？</li>
<li>想打造生产级的Go服务，却在工程化实践中屡屡受挫？</li>
</ul>
<p>继《<a href="http://gk.link/a/10AVZ">Go语言第一课</a>》后，我的《<a href="http://gk.link/a/12yGY">Go语言进阶课</a>》终于在极客时间与大家见面了！</p>
<p>我的全新极客时间专栏 《<a href="http://gk.link/a/12yGY">Tony Bai·Go语言进阶课</a>》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。</p>
<p>目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！</p>
<p><img src="https://tonybai.com/wp-content/uploads/course-card/iamtonybai-banner-2.gif" alt="" /></p>
<hr />
<p><strong>原「Gopher部落」已重装升级为「Go &amp; AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！</strong></p>
<p>我们致力于打造一个高品质的 <strong>Go 语言深度学习</strong> 与 <strong>AI 应用探索</strong> 平台。在这里，你将获得：</p>
<ul>
<li><strong>体系化 Go 核心进阶内容:</strong> 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。</li>
<li><strong>前沿 Go+AI 实战赋能:</strong> 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。 </li>
<li><strong>星主 Tony Bai 亲自答疑:</strong> 遇到难题？星主第一时间为你深度解析，扫清学习障碍。</li>
<li><strong>高活跃 Gopher 交流圈:</strong> 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。</li>
<li><strong>独家资源与内容首发:</strong> 技术文章、课程更新、精选资源，第一时间触达。</li>
</ul>
<p>衷心希望「Go &amp; AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！</p>
<p><img src="http://image.tonybai.com/img/tonybai/gopher-and-ai-tribe-zsxq-small-card.jpg" alt="img{512x368}" /></p>
<hr />
<p>商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。</p>
<p><img src="http://image.tonybai.com/img/tonybai/iamtonybai-wechat-qr.png" alt="" /></p>
<p style='text-align:left'>&copy; 2026, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2026/03/22/stop-tactical-diligence-start-stretch-zone-growth/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>代码之外的修炼：Google 资深工程师的 21 条“生存法则”</title>
		<link>https://tonybai.com/2026/01/11/21-lessons-from-google-engineer/</link>
		<comments>https://tonybai.com/2026/01/11/21-lessons-from-google-engineer/#comments</comments>
		<pubDate>Sun, 11 Jan 2026 06:32:31 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[技术志]]></category>
		<category><![CDATA[AddyOsmani]]></category>
		<category><![CDATA[Golang]]></category>
		<category><![CDATA[Google]]></category>
		<category><![CDATA[Google经验]]></category>
		<category><![CDATA[MVP]]></category>
		<category><![CDATA[不凡]]></category>
		<category><![CDATA[不确定性]]></category>
		<category><![CDATA[不负韶华]]></category>
		<category><![CDATA[专家]]></category>
		<category><![CDATA[业务价值]]></category>
		<category><![CDATA[个人品牌]]></category>
		<category><![CDATA[人脉投资]]></category>
		<category><![CDATA[价值体现]]></category>
		<category><![CDATA[优先级排序]]></category>
		<category><![CDATA[信任建立]]></category>
		<category><![CDATA[修炼]]></category>
		<category><![CDATA[修行者]]></category>
		<category><![CDATA[先驱]]></category>
		<category><![CDATA[全球化]]></category>
		<category><![CDATA[全面性]]></category>
		<category><![CDATA[公开演讲]]></category>
		<category><![CDATA[关键绩效指标]]></category>
		<category><![CDATA[兼容性]]></category>
		<category><![CDATA[冲突解决]]></category>
		<category><![CDATA[决策智慧]]></category>
		<category><![CDATA[决策模型]]></category>
		<category><![CDATA[凡人]]></category>
		<category><![CDATA[分布式团队]]></category>
		<category><![CDATA[创新代币]]></category>
		<category><![CDATA[创新管理]]></category>
		<category><![CDATA[创造]]></category>
		<category><![CDATA[刻意练习]]></category>
		<category><![CDATA[匠心]]></category>
		<category><![CDATA[升华]]></category>
		<category><![CDATA[协同失败]]></category>
		<category><![CDATA[卓越]]></category>
		<category><![CDATA[卓越工程师]]></category>
		<category><![CDATA[厚积薄发]]></category>
		<category><![CDATA[原语]]></category>
		<category><![CDATA[参与]]></category>
		<category><![CDATA[反馈循环]]></category>
		<category><![CDATA[变迁]]></category>
		<category><![CDATA[变革管理]]></category>
		<category><![CDATA[古德哈特定律]]></category>
		<category><![CDATA[同理心]]></category>
		<category><![CDATA[启示]]></category>
		<category><![CDATA[哲学家]]></category>
		<category><![CDATA[商业洞察]]></category>
		<category><![CDATA[团队协作]]></category>
		<category><![CDATA[团队文化]]></category>
		<category><![CDATA[境界]]></category>
		<category><![CDATA[复利投资]]></category>
		<category><![CDATA[复利效应]]></category>
		<category><![CDATA[复杂性管理]]></category>
		<category><![CDATA[复杂系统]]></category>
		<category><![CDATA[大师]]></category>
		<category><![CDATA[守护者]]></category>
		<category><![CDATA[宏观视野]]></category>
		<category><![CDATA[宝库]]></category>
		<category><![CDATA[巅峰]]></category>
		<category><![CDATA[工程师心法]]></category>
		<category><![CDATA[工程文化]]></category>
		<category><![CDATA[平衡]]></category>
		<category><![CDATA[底层逻辑]]></category>
		<category><![CDATA[建立共识]]></category>
		<category><![CDATA[建设者]]></category>
		<category><![CDATA[开拓者]]></category>
		<category><![CDATA[开源精神]]></category>
		<category><![CDATA[影响力]]></category>
		<category><![CDATA[影响力扩张]]></category>
		<category><![CDATA[微观操作]]></category>
		<category><![CDATA[心智模型]]></category>
		<category><![CDATA[心理契约]]></category>
		<category><![CDATA[心理安全]]></category>
		<category><![CDATA[心理授权]]></category>
		<category><![CDATA[心理韧性]]></category>
		<category><![CDATA[志存高远]]></category>
		<category><![CDATA[快速反馈]]></category>
		<category><![CDATA[快速迭代]]></category>
		<category><![CDATA[性能优化]]></category>
		<category><![CDATA[情绪智力]]></category>
		<category><![CDATA[战略备忘录]]></category>
		<category><![CDATA[战略思维]]></category>
		<category><![CDATA[执行力]]></category>
		<category><![CDATA[批判性思维]]></category>
		<category><![CDATA[技术债]]></category>
		<category><![CDATA[抽象泄露]]></category>
		<category><![CDATA[持续交付]]></category>
		<category><![CDATA[持续学习]]></category>
		<category><![CDATA[持续改进]]></category>
		<category><![CDATA[指南]]></category>
		<category><![CDATA[指标导向]]></category>
		<category><![CDATA[攀登]]></category>
		<category><![CDATA[改变]]></category>
		<category><![CDATA[敏捷性]]></category>
		<category><![CDATA[敬畏之心]]></category>
		<category><![CDATA[文化适配]]></category>
		<category><![CDATA[文档编写]]></category>
		<category><![CDATA[方案空间]]></category>
		<category><![CDATA[方法论]]></category>
		<category><![CDATA[时代]]></category>
		<category><![CDATA[时间价值]]></category>
		<category><![CDATA[智慧结晶]]></category>
		<category><![CDATA[最佳实践]]></category>
		<category><![CDATA[最小可行产品]]></category>
		<category><![CDATA[未来]]></category>
		<category><![CDATA[极客]]></category>
		<category><![CDATA[架构决策]]></category>
		<category><![CDATA[根基]]></category>
		<category><![CDATA[模型构建]]></category>
		<category><![CDATA[模糊性]]></category>
		<category><![CDATA[沉淀]]></category>
		<category><![CDATA[沟通技巧]]></category>
		<category><![CDATA[泰斗]]></category>
		<category><![CDATA[洞察力]]></category>
		<category><![CDATA[流程优化]]></category>
		<category><![CDATA[流程再造]]></category>
		<category><![CDATA[涌现]]></category>
		<category><![CDATA[清晰性]]></category>
		<category><![CDATA[激情]]></category>
		<category><![CDATA[灯塔]]></category>
		<category><![CDATA[灵魂]]></category>
		<category><![CDATA[生命力]]></category>
		<category><![CDATA[生存法则]]></category>
		<category><![CDATA[用户体验]]></category>
		<category><![CDATA[用户问题]]></category>
		<category><![CDATA[目标对齐]]></category>
		<category><![CDATA[知行合一]]></category>
		<category><![CDATA[知识传递]]></category>
		<category><![CDATA[码农]]></category>
		<category><![CDATA[砥砺前行]]></category>
		<category><![CDATA[社交资本]]></category>
		<category><![CDATA[社区贡献]]></category>
		<category><![CDATA[科学]]></category>
		<category><![CDATA[秘籍]]></category>
		<category><![CDATA[积淀]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[系统思维]]></category>
		<category><![CDATA[系统透视]]></category>
		<category><![CDATA[纯粹]]></category>
		<category><![CDATA[组织动力学]]></category>
		<category><![CDATA[组织调整]]></category>
		<category><![CDATA[终身学习]]></category>
		<category><![CDATA[经验复用]]></category>
		<category><![CDATA[维护成本]]></category>
		<category><![CDATA[综合体]]></category>
		<category><![CDATA[职业成长]]></category>
		<category><![CDATA[职业操守]]></category>
		<category><![CDATA[职业规划]]></category>
		<category><![CDATA[职业道德]]></category>
		<category><![CDATA[职场导航]]></category>
		<category><![CDATA[职场智慧]]></category>
		<category><![CDATA[胶水工作]]></category>
		<category><![CDATA[脚踏实地]]></category>
		<category><![CDATA[自我驱动]]></category>
		<category><![CDATA[艺术]]></category>
		<category><![CDATA[艺术家]]></category>
		<category><![CDATA[范式]]></category>
		<category><![CDATA[蜕变]]></category>
		<category><![CDATA[行业趋势]]></category>
		<category><![CDATA[行为模式]]></category>
		<category><![CDATA[见证]]></category>
		<category><![CDATA[规模化]]></category>
		<category><![CDATA[解决问题]]></category>
		<category><![CDATA[警钟]]></category>
		<category><![CDATA[认知开销]]></category>
		<category><![CDATA[设计哲学]]></category>
		<category><![CDATA[设计师]]></category>
		<category><![CDATA[资深工程师]]></category>
		<category><![CDATA[资源分配]]></category>
		<category><![CDATA[跨界]]></category>
		<category><![CDATA[跨职能协作]]></category>
		<category><![CDATA[路线图]]></category>
		<category><![CDATA[软件定义世界]]></category>
		<category><![CDATA[软件工程]]></category>
		<category><![CDATA[软技能]]></category>
		<category><![CDATA[软硬兼修]]></category>
		<category><![CDATA[运营风险]]></category>
		<category><![CDATA[远程协作]]></category>
		<category><![CDATA[迭代进化]]></category>
		<category><![CDATA[追求]]></category>
		<category><![CDATA[适应力]]></category>
		<category><![CDATA[锚点]]></category>
		<category><![CDATA[锦囊妙计]]></category>
		<category><![CDATA[长期主义]]></category>
		<category><![CDATA[长期回报]]></category>
		<category><![CDATA[问题空间]]></category>
		<category><![CDATA[韧性]]></category>
		<category><![CDATA[顶层设计]]></category>
		<category><![CDATA[领导力]]></category>
		<category><![CDATA[领悟]]></category>
		<category><![CDATA[风险控制]]></category>
		<category><![CDATA[驱动]]></category>
		<category><![CDATA[黄金准则]]></category>

		<guid isPermaLink="false">https://tonybai.com/?p=5706</guid>
		<description><![CDATA[本文永久链接 &#8211; 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. 清晰即资深，聪明是开销 编写“聪明”的代码，是工程师证明能力的本能。 但真正的软件工程，是在时间和团队协作的维度上展开的。 清晰性不是一种风格偏好，而是一种运营风险的降低。 [...]]]></description>
			<content:encoded><![CDATA[<p><img src="https://tonybai.com/wp-content/uploads/2025/21-lessons-from-google-engineer-1.png" alt="" /></p>
<p><a href="https://tonybai.com/2026/01/11/21-lessons-from-google-engineer">本文永久链接</a> &#8211; https://tonybai.com/2026/01/11/21-lessons-from-google-engineer</p>
<p>大家好，我是Tony Bai。</p>
<p>“当我 14 年前加入 Google 时，我以为这份工作就是写出优秀的代码……我只说对了一部分。我待得越久，就越意识到，那些真正茁壮成长的工程师，不一定是最好的程序员——他们是那些懂得如何驾驭代码<strong>周围</strong>一切的人：人、政治、协同和模糊性。”</p>
<p>这段话，出自 Google 资深工程师 Addy Osmani 的一篇深刻反思——《<a href="https://addyo.substack.com/p/21-lessons-from-14-years-at-google">在 Google 14 年的 21 条经验</a>》。这篇文章，如同淬炼了 14 年的智慧结晶，几乎没有谈论任何具体的技术栈，却精准地描绘出了一位卓越工程师的成长画像。</p>
<p>这 21 条“法则”，并非关于某种转瞬即逝的技术，而是关于那些在项目、团队、公司之间反复出现的永恒模式。它们不是一场与外部世界的战争，而是一场<strong>关于自我提升的漫长“修炼”</strong>。这是一份珍贵的“心法”，能帮助我们在这场修炼之路上，走得更远、更稳。本文将为你逐一解读。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2026/distributed-system-guide-qr.png" alt="" /></p>
<hr />
<h2>1. 最好的工程师痴迷于解决“用户问题”，而非“技术问题”</h2>
<p>这是工程师“修炼”之路的<strong>第一心法：放下执念</strong>。</p>
<p>放下对特定技术的迷恋，将自我从“工具的使用者”升华为“问题的解决者”。</p>
<p>“用户痴迷”意味着走出 IDE，去阅读支持工单，去和真实用户交谈，去观察他们如何在你的产品中挣扎。</p>
<p>当你真正理解了用户的“痛”，你往往会发现，那个最优雅的解决方案，远比你最初设想的任何复杂技术都要简单。</p>
<h2>2. 做到正确很廉价，而“一起”做到正确才是真正的修行</h2>
<p>你可以在每一次技术辩论中都“赢”，但最终输掉整个项目。</p>
<p>真正的“修为”，不在于证明自己正确，而在于创造一个安全的空间，让团队能够共同对问题达成一致，并对自己的确定性保持怀疑。</p>
<p>记住：“观点强硬，但立场松动 (Strong opinions, weakly held)。”</p>
<h2>3. 偏爱行动。交付。你可以修改一个糟糕的页面，但无法修改一个空白的页面</h2>
<p>对完美的追求是麻痹剂，是“心魔”。</p>
<p>完美的架构不会在纯粹的冥想中诞生，它诞生于与现实的接触。</p>
<p>先做出来，再做对，再做得更好。</p>
<p>交付那个让你感到“有点尴尬”的 MVP。</p>
<p>一个粗糙的原型所能带来的真实反馈，远超一个月闭门造车的理论辩论。</p>
<h2>4. 清晰即资深，聪明是开销</h2>
<p>编写“聪明”的代码，是工程师证明能力的本能。</p>
<p>但真正的软件工程，是在时间和团队协作的维度上展开的。</p>
<p>清晰性不是一种风格偏好，而是一种<strong>运营风险的降低</strong>。</p>
<p>你的代码，是一份写给未来某个凌晨三点需要维护它的陌生人的“战略备忘录”。</p>
<p>资深的工程师，早已学会在他们的“修炼”中，用清晰性去交换那份无关紧要的“聪明”。</p>
<h2>5. 新奇是一笔贷款，你将在故障、招聘和认知开销中偿还</h2>
<p>像一个预算有限的组织一样，谨慎地对待你的“创新代币”。</p>
<p>只在你拥有独特优势的地方进行创新，其他所有事情，都应该默认选择“无聊”的技术，因为“无聊”意味着失败模式是已知的。</p>
<p>记住，“最好的工具”，常常是那个“在最多场景下最不坏的工具”。</p>
<h2>6. 你的代码不会为你代言，人会</h2>
<p>以为“好的工作会自己说话”，是工程师“修炼”生涯早期最大的错觉。</p>
<p>代码静静地躺在仓库里，它不会在晋升会议上为你辩护。</p>
<p>你需要将你的工作和价值，以一种<strong>可被他人理解和传播</strong>的方式呈现出来：写清晰的文档、做有影响力的分享、主动沟通你的成果。</p>
<h2>7. 最好的代码，是那些你从未写下的代码</h2>
<p>工程文化崇尚创造，但<strong>删除代码往往比增加代码更能改善一个系统</strong>。</p>
<p>你没有写下的每一行代码，都是你永远不必去调试、维护或解释的一行代码。</p>
<p>在动手构建之前，请先用“无为”的智慧拷问自己：“如果我们就是……不这么做，会发生什么？”</p>
<h2>8. 在规模化面前，即使你的 Bug 也有用户</h2>
<p>当用户足够多时，你的系统的每一个可观测行为，无论你是否承诺过，都会成为一种事实上的依赖。</p>
<p>有人正在爬取你的 API，有人正在自动化你的“怪癖”，有人正在缓存你的 Bug。</p>
<p>这意味着，<strong>兼容性本身就是一种产品</strong>。你不能再将修复 Bug 视为“维护”，将开发新功能视为“真正的工作”。</p>
<h2>9. 大多数“慢”团队，其实是“失调”的团队</h2>
<p>当项目拖延时，我们的本能是归咎于执行力：人手不够、技术不行、工作不努力。</p>
<p>但真正的瓶颈，往往在于<strong>协同失败 (Alignment Failure)</strong>——团队在做错误的事情，或者以不兼容的方式在做正确的事情。</p>
<p>资深工程师会花费更多时间去澄清方向、接口和优先级，而不是单纯地“更快地写代码”。</p>
<h2>10. 关注你能控制的，忽略你不能的</h2>
<p>在大型组织中，组织架构调整、管理层决策、市场变化……无数变量都在你的控制范围之外。</p>
<p>为这些事情焦虑，是在浪费你宝贵的精力。</p>
<p>卓越的工程师，会战略性地专注于他们的“影响圈”：你能控制你代码的质量，你能控制你如何响应变化，你能控制你学到了什么。</p>
<p>这是一种<strong>专注的“禅定”</strong>。</p>
<h2>11. 抽象并未消除复杂性，只是将其转移到了你 on-call 的那一天</h2>
<p>每一个抽象，都是一次“我未来不需要理解其底层”的赌博。</p>
<p>有时你会赌赢，但抽象总会泄露。</p>
<p>资深工程师之所以坚持学习底层知识，并非出于怀旧，而是出于对“凌晨三点，当你独自面对一个失效的抽象时”的敬畏。</p>
<h2>12. 写作倒逼清晰。想学得更快，就去教别人</h2>
<p>当你试图向他人解释一个概念时——无论是在文档中、演讲中，还是 Code Review 的评论里——你会立刻发现自己理解上的盲点。</p>
<p>把一个东西教给别人，本质上是在<strong>调试你自己的心智模型</strong>。</p>
<p>这是最高效的“利己”的学习法门。</p>
<h2>13. 那些让其他工作成为可能的工作，无价且无形</h2>
<p>“胶水工作”——文档、新人引导、跨团队协调、流程改进——至关重要。</p>
<p>但如果你无意识地、仅仅出于“乐于助人”去做这些事，它们会吞噬你的时间，让你偏离技术主航道。</p>
<p>诀窍在于，有意识地去做，为它设定时间盒，将它转化为文档、模板、自动化等<strong>可见的成果</strong>，让它成为你明确的影响力，而非模糊的“性格特质”。</p>
<h2>14. 如果你赢得了每一次辩论，你可能正在积累无声的抵制</h2>
<p>当你“赢”得太轻松时，通常意味着事情不对劲了。</p>
<p>人们不再与你争论，不是因为你彻底说服了他们，而是因为他们已经放弃了尝试。</p>
<p>而这份未解的分歧，将会在未来的执行层面，以“神秘的阻力”的形式爆发出来。</p>
<p>真正的协同，需要你真正去理解他人，并有时公开地改变自己的想法。</p>
<h2>15. 当一个指标成为目标时，它便不再是一个好的指标</h2>
<p>古德哈特定律的经典再现。</p>
<p>人类会为了被测量的东西而优化。</p>
<p>资深的做法是，用<strong>一组</strong>成对的指标来响应管理需求（例如，速度 vs. 质量），并坚持<strong>解读趋势</strong>，而非崇拜某个具体的阈值。</p>
<h2>16. 承认“我不知道”，比假装知道能创造更多安全感</h2>
<p>当一个领导者或资深工程师坦诚自己的不确定性时，他实际上是在给予整个团队“提问”和“犯错”的许可。</p>
<p>这会创造一种心理安全的环境，让问题在爆炸前被暴露出来。</p>
<p>反之，一个“永远正确”的领导者，只会培养出一群沉默的下属和一堆隐藏的地雷。</p>
<h2>17. 你的人脉，比你做过的任何一份工作都更长久</h2>
<p>职业生涯早期，我们容易专注于工作本身而忽略人际交往。</p>
<p>这是一个巨大的错误。</p>
<p>那些在公司内外投资于人际关系的同事，在数十年后，会收获巨大的回报。</p>
<p>你的工作不是永恒的，但你建立的信任是。</p>
<h2>18. 大多数性能的胜利，源于“移除工作”，而非“增加聪明”</h2>
<p>当系统变慢时，我们的本能是增加缓存、并行处理、或者换用更聪明的算法。</p>
<p>但更具影响力的胜利，往往来自于问一个更根本的问题：“我们正在计算的这些东西，真的有必要吗？”</p>
<p>删除不必要的工作，远比把必要的工作做得更快要有效得多。</p>
<p><strong>最快的代码，是那段从未运行过的代码。</strong></p>
<h2>19. 流程的存在是为了减少不确定性，而不是为了制造文书工作</h2>
<p>最好的流程，能让协作更容易，让失败的代价更便宜。</p>
<p>而最坏的流程，是“官僚主义戏剧”——它的存在不是为了帮助，而是在出问题时用来甩锅。</p>
<p>如果你无法解释一个流程如何降低风险或增加清晰度，那它很可能就是纯粹的开销。</p>
<h2>20. 最终，时间会比金钱更宝贵。请据此行事</h2>
<p>职业生涯早期，你用时间换金钱。</p>
<p>但在某个临界点之后，这个公式会反转。</p>
<p>时间是唯一不可再生的资源。</p>
<p>答案不是“不要努力工作”，而是“<strong>清楚你在交易什么，并深思熟虑地做出交易。</strong>”</p>
<h2>21. 没有捷径，但有复利</h2>
<p>专业知识，来自于经年累月的刻意练习。</p>
<p>但这里有希望的部分：学习是具有<strong>复利效应</strong>的。</p>
<p>你建立的每一个心智模型，你总结的每一条经验教训，都会成为你未来解决更复杂问题的“可复用原语”。</p>
<p>将你的职业生涯视为复利投资，而非一张张彩票。</p>
<h2>小结：修炼的核心永远是人</h2>
<p>Addy Osmani 的 21 条经验，最终可以归结为几个核心思想：<strong>保持好奇，保持谦逊，并永远记住，修炼的核心是人——你为之构建的用户，以及与你一同构建的队友。</strong></p>
<p>对于我们工程师而言，这意味着，职业生涯的成长，是一场双螺旋式的攀升。</p>
<p>技术能力的“硬实力”是我们的根基，但决定我们最终能达到何种“境界”的，往往是沟通、协作、权衡、同理心这些看似“软”的、关于人的智慧。</p>
<p>这场“代码之外的修炼”，道阻且长，但行则将至。</p>
<p>资料链接：https://addyo.substack.com/p/21-lessons-from-14-years-at-google</p>
<hr />
<p><strong>你的“第22条”法则</strong></p>
<p>读完这21条法则，相信你一定心有戚戚焉。<strong>在你自己的职业生涯中，是否有哪一条“生存法则”是你用惨痛教训换来的？或者，你觉得还有什么重要的经验是这21条没有覆盖到的？</strong></p>
<p><strong>欢迎在评论区分享你的独家心法！</strong> 让我们一起汇聚更多智慧。</p>
<p><strong>如果这篇文章给了你新的启发，别忘了点个【赞】和【在看】，并转发给身边正在迷茫的工程师朋友，也许这就是他破局的关键！</strong></p>
<hr />
<p>还在为“复制粘贴喂AI”而烦恼？我的新专栏 <strong>《<a href="http://gk.link/a/12EPd">AI原生开发工作流实战</a>》</strong> 将带你：</p>
<ul>
<li>告别低效，重塑开发范式</li>
<li>驾驭AI Agent(Claude Code)，实现工作流自动化</li>
<li>从“AI使用者”进化为规范驱动开发的“工作流指挥家”</li>
</ul>
<p>扫描下方二维码，开启你的AI原生开发之旅。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/ai-native-dev-workflow-qr.png" alt="" /></p>
<hr />
<p>你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？</p>
<ul>
<li>想写出更地道、更健壮的Go代码，却总在细节上踩坑？</li>
<li>渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？</li>
<li>想打造生产级的Go服务，却在工程化实践中屡屡受挫？</li>
</ul>
<p>继《<a href="http://gk.link/a/10AVZ">Go语言第一课</a>》后，我的《<a href="http://gk.link/a/12yGY">Go语言进阶课</a>》终于在极客时间与大家见面了！</p>
<p>我的全新极客时间专栏 《<a href="http://gk.link/a/12yGY">Tony Bai·Go语言进阶课</a>》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。</p>
<p>目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！</p>
<p><img src="https://tonybai.com/wp-content/uploads/course-card/iamtonybai-banner-2.gif" alt="" /></p>
<hr />
<p>商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。</p>
<p><img src="http://image.tonybai.com/img/tonybai/iamtonybai-wechat-qr.png" alt="" /></p>
<p style='text-align:left'>&copy; 2026, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2026/01/11/21-lessons-from-google-engineer/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Go 的“浮点数陷阱”将被填平：浮点转整数即将在所有平台上行为一致</title>
		<link>https://tonybai.com/2026/01/11/proposal-float-to-int-conversions-should-saturate-on-overflow/</link>
		<comments>https://tonybai.com/2026/01/11/proposal-float-to-int-conversions-should-saturate-on-overflow/#comments</comments>
		<pubDate>Sat, 10 Jan 2026 23:31:45 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[技术志]]></category>
		<category><![CDATA[amd64]]></category>
		<category><![CDATA[arm64]]></category>
		<category><![CDATA[Compiler]]></category>
		<category><![CDATA[consistency]]></category>
		<category><![CDATA[Conversion]]></category>
		<category><![CDATA[CrossPlatform]]></category>
		<category><![CDATA[DavidChase]]></category>
		<category><![CDATA[exception]]></category>
		<category><![CDATA[FloatingPoint]]></category>
		<category><![CDATA[Go]]></category>
		<category><![CDATA[go1.26]]></category>
		<category><![CDATA[Go1.27]]></category>
		<category><![CDATA[Go1.28]]></category>
		<category><![CDATA[GOEXPERIMENT]]></category>
		<category><![CDATA[Golang]]></category>
		<category><![CDATA[HardwareDifference]]></category>
		<category><![CDATA[IanLanceTaylor]]></category>
		<category><![CDATA[ImplementationDefined]]></category>
		<category><![CDATA[InstructionSet]]></category>
		<category><![CDATA[Integer]]></category>
		<category><![CDATA[NaN]]></category>
		<category><![CDATA[Overflow]]></category>
		<category><![CDATA[PerfectPortability]]></category>
		<category><![CDATA[Performance]]></category>
		<category><![CDATA[Portability]]></category>
		<category><![CDATA[Programmer]]></category>
		<category><![CDATA[RISCV]]></category>
		<category><![CDATA[SaturatingConversion]]></category>
		<category><![CDATA[一致性]]></category>
		<category><![CDATA[可移植性]]></category>
		<category><![CDATA[完美可移植性]]></category>
		<category><![CDATA[实现定义]]></category>
		<category><![CDATA[异常]]></category>
		<category><![CDATA[性能]]></category>
		<category><![CDATA[指令集]]></category>
		<category><![CDATA[整数]]></category>
		<category><![CDATA[浮点数]]></category>
		<category><![CDATA[溢出]]></category>
		<category><![CDATA[硬件差异]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[编译器]]></category>
		<category><![CDATA[跨平台]]></category>
		<category><![CDATA[转换]]></category>
		<category><![CDATA[饱和转换]]></category>

		<guid isPermaLink="false">https://tonybai.com/?p=5703</guid>
		<description><![CDATA[本文永久链接 &#8211; https://tonybai.com/2026/01/11/proposal-float-to-int-conversions-should-saturate-on-overflow 大家好，我是Tony Bai。 你是否知道，同一行简单的代码 int64(myFloat)，在 Intel (amd64) 机器上可能返回一个巨大的负数，而在 ARM64 机器上却可能返回最大正整数？ 在 Go 语言中，浮点数到整数的转换溢出行为长期以来一直属于“实现定义”(implementation-dependent) 的灰色地带。这意味着，代码的运行结果竟然取决于你底层的 CPU 架构。这种不确定性，一直是跨平台开发中一个难以察觉的隐形地雷。 2025年末，Go 编译器团队核心成员 David Chase 提交了一份提案（#76264），旨在彻底终结这种混乱。该提案计划在未来的 Go 版本中，强制规定所有平台上的浮点转整数必须是“饱和”的 (saturating)，从而实现真正的全平台行为一致。 痛点：薛定谔的转换结果 在现有的 Go 规范下，如果你尝试将一个超出目标整数范围的浮点数（例如 1e100）转换为 int64，结果是未定义的。 让我们看看这有多疯狂。假设我们有以下代码： var f float64 = 1e100 // 一个巨大的数 var i int64 = int64(f) fmt.Println(i) 这段代码在不同架构下的运行结果截然不同： ARM64, RISC-V: 返回 9223372036854775807 (MAX_INT64)。这是“饱和”行为，即卡在最大值。 AMD64 (x86-64): 返回 [...]]]></description>
			<content:encoded><![CDATA[<p><img src="https://tonybai.com/wp-content/uploads/2026/proposal-float-to-int-conversions-should-saturate-on-overflow-1.png" alt="" /></p>
<p><a href="https://tonybai.com/2026/01/11/proposal-float-to-int-conversions-should-saturate-on-overflow">本文永久链接</a> &#8211; https://tonybai.com/2026/01/11/proposal-float-to-int-conversions-should-saturate-on-overflow</p>
<p>大家好，我是Tony Bai。</p>
<p>你是否知道，同一行简单的代码 int64(myFloat)，在 Intel (amd64) 机器上可能返回一个巨大的负数，而在 ARM64 机器上却可能返回最大正整数？</p>
<p>在 Go 语言中，浮点数到整数的转换溢出行为长期以来一直属于“实现定义”(implementation-dependent) 的灰色地带。这意味着，代码的运行结果竟然取决于你底层的 CPU 架构。这种不确定性，一直是跨平台开发中一个难以察觉的隐形地雷。</p>
<p>2025年末，Go 编译器团队核心成员 David Chase 提交了一份提案（<a href="https://github.com/golang/go/issues/76264">#76264</a>），旨在彻底终结这种混乱。该提案计划在未来的 Go 版本中，<strong>强制规定所有平台上的浮点转整数必须是“饱和”的 (saturating)</strong>，从而实现真正的全平台行为一致。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2026/distributed-system-guide-qr.png" alt="img{512x368}" /></p>
<h2>痛点：薛定谔的转换结果</h2>
<p>在现有的 Go 规范下，如果你尝试将一个超出目标整数范围的浮点数（例如 1e100）转换为 int64，结果是未定义的。</p>
<p>让我们看看这有多疯狂。假设我们有以下代码：</p>
<pre><code class="go">var f float64 = 1e100 // 一个巨大的数
var i int64 = int64(f)
fmt.Println(i)
</code></pre>
<p>这段代码在不同架构下的运行结果截然不同：</p>
<ul>
<li><strong>ARM64, RISC-V</strong>: 返回 9223372036854775807 (<strong>MAX_INT64</strong>)。这是“饱和”行为，即卡在最大值。</li>
<li><strong>AMD64 (x86-64)</strong>: 返回 -9223372036854775808 (<strong>MIN_INT64</strong>)。这是一个令人困惑的溢出结果。</li>
<li><strong>WASM</strong>: 行为又不一样&#8230;</li>
</ul>
<p>更糟糕的是 NaN (Not a Number) 的转换：</p>
<pre><code class="go">var j int64 = int64(math.NaN())
fmt.Println(j)
</code></pre>
<ul>
<li><strong>ARM64</strong>: 返回 0。</li>
<li><strong>AMD64</strong>: 返回 <strong>MIN_INT64</strong>。</li>
<li><strong>RISC-V</strong>: 返回 <strong>MAX_INT64</strong>。</li>
</ul>
<p>这种不一致性不仅仅是理论问题，它已经导致了准标准库 x/time/rate 中的真实 Bug (<a href="https://github.com/golang/go/issues/71154">#71154</a>)。当你的代码逻辑依赖于转换结果的正负号来做判断时（例如 if i > 0），这种硬件差异就是致命的。</p>
<h2>解决方案：拥抱“饱和转换”</h2>
<p>David Chase 的提案非常直接：<strong>统一行为，拥抱饱和。</strong></p>
<p>所谓“饱和转换”，是指当浮点数超出目标整数的表示范围时，结果应该被“钳制”在目标类型的最大值或最小值，而不是发生回绕(wraparound)或产生随机值。</p>
<p>具体规则如下：</p>
<ol>
<li><strong>正溢出</strong> -> 返回目标类型的 <strong>最大值</strong> (MaxInt)。</li>
<li><strong>负溢出</strong> -> 返回目标类型的 <strong>最小值</strong> (MinInt)。</li>
<li><strong>NaN</strong> -> 返回 <strong>0</strong> (或归一化为 0)。</li>
</ol>
<p>这一改变将使得 Go 代码在任何 CPU 架构上都表现出完全一致的逻辑，彻底消除了这类可移植性隐患。</p>
<h2>深层权衡：一致性 vs. 性能</h2>
<p>为什么 Go 以前不这么做？核心原因在于<strong>性能成本</strong>。</p>
<p>在 ARM64 和 RISC-V 等现代架构上，硬件指令集（如 FCVT）原生支持饱和转换，因此这样做几乎没有额外开销。</p>
<p>然而，<strong>AMD64 (x86-64) 是个“异类”</strong>。它的 CVTTSD2SQ 指令在溢出时不仅返回一个特殊的“不定值”（通常是 MinInt），还会触发浮点异常。为了在 AMD64 上模拟出“饱和”行为，编译器必须插入额外的检查代码：</p>
<pre><code class="go">// 模拟代码逻辑：AMD64 上的额外开销
result = int64(x)
if result == MIN_INT64 { // 可能溢出了
    if x &gt; 0 {
        result = MAX_INT64 // 正溢出修正
    } else if !(x &lt; 0) {
        result = 0         // NaN 修正
    }
}
</code></pre>
<p>Go 核心团队成员 Ian Lance Taylor 在评论中指出，我们必须权衡：<strong>为了消除这种不一致性，值得让 AMD64 上的转换操作变慢吗？</strong></p>
<p>提案作者 David Chase 的回应是：<strong>值得。</strong> 与 FMA (融合乘加) 指令带来的微小精度差异不同，浮点转整数的差异往往是<strong>正负号级别</strong>的（MaxInt vs MinInt），这直接决定了代码逻辑的走向（循环是否执行、条件是否满足）。这种差异带来的 Bug 极其隐蔽且难以调试，其代价远超那几条指令的性能损耗。</p>
<h2>实施计划：温和的演进</h2>
<p>为了避免生态系统的剧烈震荡，提案建议采用分阶段的落地策略：</p>
<ul>
<li><strong>Go 1.26</strong>: 引入 GOEXPERIMENT 标志，允许开发者尝鲜并测试影响。</li>
<li><strong>Go 1.27</strong>: 将其设为默认的实现行为。</li>
<li><strong>Go 1.28</strong>: 正式修改 Go 语言规范 (Spec)，将其确立为标准。</li>
</ul>
<blockquote>
<p>注：Go 1.26当前已经功能冻结，<a href="https://github.com/golang/go/issues/33892#issuecomment-3721268260">该提案依然处于Go语言规范变更审查委员会的讨论状态中</a>，因此即便逻辑，其实际落地时间表也会顺延。</p>
</blockquote>
<h2>小结：Go 向“完美可移植性”迈出的重要一步</h2>
<p>Dr Chase的这个提案不仅是对一个技术细节的修正，更是 Go 语言设计哲学的一次体现：<strong>在工程实践中，可预测性和可移植性往往优于特定平台上的极致微优化。</strong></p>
<p>如果该提案通过，未来的 Gopher 们将不再需要担心底层的 CPU 是 Intel 还是 ARM，int64(NaN) 永远是 0，int64(Inf) 永远是 MaxInt64。这，才是我们想要的“Write Once, Run Anywhere”。</p>
<blockquote>
<p>注：目前Dr Chase也在努力弥合amd64下的性能差距。</p>
</blockquote>
<p>资料链接：https://github.com/golang/go/issues/76264</p>
<hr />
<p><strong>你的跨平台“血泪史”</strong></p>
<p>跨平台开发中的“未定义行为”往往是最难调试的 Bug。<strong>在你的开发生涯中，是否也遇到过因为 CPU 架构或操作系统差异而导致的诡异问题？你支持为了“一致性”而牺牲一点点 AMD64 上的性能吗？</strong></p>
<p><strong>欢迎在评论区分享你的踩坑经历或对提案的看法！</strong> 让我们一起见证 Go 语言的进化。</p>
<p><strong>如果这篇文章让你对底层原理有了新的认识，别忘了点个【赞】和【在看】，并转发给你的硬核伙伴！</strong></p>
<hr />
<p>还在为“复制粘贴喂AI”而烦恼？我的新专栏 <strong>《<a href="http://gk.link/a/12EPd">AI原生开发工作流实战</a>》</strong> 将带你：</p>
<ul>
<li>告别低效，重塑开发范式</li>
<li>驾驭AI Agent(Claude Code)，实现工作流自动化</li>
<li>从“AI使用者”进化为规范驱动开发的“工作流指挥家”</li>
</ul>
<p>扫描下方二维码，开启你的AI原生开发之旅。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/ai-native-dev-workflow-qr.png" alt="" /></p>
<hr />
<p>你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？</p>
<ul>
<li>想写出更地道、更健壮的Go代码，却总在细节上踩坑？</li>
<li>渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？</li>
<li>想打造生产级的Go服务，却在工程化实践中屡屡受挫？</li>
</ul>
<p>继《<a href="http://gk.link/a/10AVZ">Go语言第一课</a>》后，我的《<a href="http://gk.link/a/12yGY">Go语言进阶课</a>》终于在极客时间与大家见面了！</p>
<p>我的全新极客时间专栏 《<a href="http://gk.link/a/12yGY">Tony Bai·Go语言进阶课</a>》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。</p>
<p>目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！</p>
<p><img src="https://tonybai.com/wp-content/uploads/course-card/iamtonybai-banner-2.gif" alt="" /></p>
<hr />
<p>商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。</p>
<p><img src="http://image.tonybai.com/img/tonybai/iamtonybai-wechat-qr.png" alt="" /></p>
<p style='text-align:left'>&copy; 2026, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2026/01/11/proposal-float-to-int-conversions-should-saturate-on-overflow/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>为什么 AI 时代，C++ 和 Rust 反而更火了？Herb Sutter 的硬核解读</title>
		<link>https://tonybai.com/2026/01/03/why-cpp-programmers-keep-growing-fast/</link>
		<comments>https://tonybai.com/2026/01/03/why-cpp-programmers-keep-growing-fast/#comments</comments>
		<pubDate>Fri, 02 Jan 2026 23:49:14 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[技术志]]></category>
		<category><![CDATA[AI]]></category>
		<category><![CDATA[AI时代]]></category>
		<category><![CDATA[C]]></category>
		<category><![CDATA[C++26]]></category>
		<category><![CDATA[C++29]]></category>
		<category><![CDATA[Contracts]]></category>
		<category><![CDATA[EnergyEfficiency]]></category>
		<category><![CDATA[Go]]></category>
		<category><![CDATA[Golang]]></category>
		<category><![CDATA[HerbSutter]]></category>
		<category><![CDATA[MemorySafety]]></category>
		<category><![CDATA[NVIDIA]]></category>
		<category><![CDATA[PerformancePerWatt]]></category>
		<category><![CDATA[Rust]]></category>
		<category><![CDATA[内存安全]]></category>
		<category><![CDATA[契约编程]]></category>
		<category><![CDATA[安全性]]></category>
		<category><![CDATA[性能]]></category>
		<category><![CDATA[摩尔定律]]></category>
		<category><![CDATA[未定义行为]]></category>
		<category><![CDATA[标准库加固]]></category>
		<category><![CDATA[每瓦性能]]></category>
		<category><![CDATA[物理限制]]></category>
		<category><![CDATA[电力瓶颈]]></category>
		<category><![CDATA[硬件算力]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[能效]]></category>
		<category><![CDATA[芯片供应]]></category>
		<category><![CDATA[软件工程]]></category>
		<category><![CDATA[边界检查]]></category>
		<category><![CDATA[长期主义]]></category>

		<guid isPermaLink="false">https://tonybai.com/?p=5656</guid>
		<description><![CDATA[本文永久链接 &#8211; https://tonybai.com/2026/01/03/why-cpp-programmers-keep-growing-fast 大家好，我是Tony Bai。 “软件拿走性能的速度，永远比硬件提供性能的速度要快。” 在 AI 狂热、Python 统治胶水层、硬件算力看似无限增长的今天，C++ 标准委员会主席 Herb Sutter 却抛出了一个反直觉的结论：C++ 和 Rust 正在经历前所未有的高速增长。 这并非幸存者偏差。在他最新的博文《Software taketh away faster than hardware giveth》中，Sutter 结合 2025 年的行业数据、巨头财报和底层物理限制，为我们揭示了一个残酷的真相：我们正面临计算能力的“硬墙”，而高效能编程语言，是撞破这堵墙的唯一工具。 2025 年计算的双重瓶颈——电力与芯片 如果你认为算力增长的瓶颈仅仅是芯片（GPU/TPU）的供应，那你就错了。Sutter 引用了微软、亚马逊和 NVIDIA 财报电话会议的内容，指出 2025 年计算增长的第一大瓶颈是“电力”。 微软 CFO：我们不缺 GPU，我们缺的是把它们放进去的“空间和电力”。 亚马逊 CEO：AWS 过去 12 个月增加了 3.8 吉瓦的电力容量，这相当于他们 2022 年的总容量。 NVIDIA CEO 黄仁勋：1 吉瓦的数据中心就是 1 吉瓦的电力。你的“每瓦性能 (Performance per [...]]]></description>
			<content:encoded><![CDATA[<p><img src="https://tonybai.com/wp-content/uploads/2026/why-cpp-programmers-keep-growing-fast-1.png" alt="" /></p>
<p><a href="https://tonybai.com/2026/01/03/why-cpp-programmers-keep-growing-fast">本文永久链接</a> &#8211; https://tonybai.com/2026/01/03/why-cpp-programmers-keep-growing-fast</p>
<p>大家好，我是Tony Bai。</p>
<p>“软件拿走性能的速度，永远比硬件提供性能的速度要快。”</p>
<p>在 AI 狂热、Python 统治胶水层、硬件算力看似无限增长的今天，C++ 标准委员会主席 Herb Sutter 却抛出了一个反直觉的结论：<strong>C++ 和 Rust 正在经历前所未有的高速增长。</strong></p>
<p>这并非幸存者偏差。在他最新的博文《<a href="https://herbsutter.com/2025/12/30/software-taketh-away-faster-than-hardware-giveth-why-c-programmers-keep-growing-fast-despite-competition-safety-and-ai">Software taketh away faster than hardware giveth</a>》中，Sutter 结合 2025 年的行业数据、巨头财报和底层物理限制，为我们揭示了一个残酷的真相：我们正面临计算能力的“硬墙”，而高效能编程语言，是撞破这堵墙的唯一工具。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/paid/system-programming-in-go-pr.png" alt="" /></p>
<h2>2025 年计算的双重瓶颈——电力与芯片</h2>
<p>如果你认为算力增长的瓶颈仅仅是芯片（GPU/TPU）的供应，那你就错了。Sutter 引用了微软、亚马逊和 NVIDIA 财报电话会议的内容，指出 2025 年计算增长的<strong>第一大瓶颈是“电力”</strong>。</p>
<ul>
<li><strong>微软 CFO</strong>：我们不缺 GPU，我们缺的是把它们放进去的“空间和电力”。</li>
<li><strong>亚马逊 CEO</strong>：AWS 过去 12 个月增加了 3.8 吉瓦的电力容量，这相当于他们 2022 年的总容量。</li>
<li><strong>NVIDIA CEO 黄仁勋</strong>：1 吉瓦的数据中心就是 1 吉瓦的电力。你的“每瓦性能 (Performance per Watt)”直接决定了你的收入。</li>
</ul>
<p>在这个背景下，<strong>能效 (Energy Efficiency)</strong> 不再是一个锦上添花的指标，而是直接关乎成本、收入乃至可行性的<strong>生死线</strong>。</p>
<p>这解释了为什么 C++ 和 Rust 如此重要：它们是目前仅有的、能够提供极致“每瓦性能”和“每晶体管性能”的主流便携式语言。在电力成为硬通货的今天，低效的软件就是在烧钱。</p>
<h2>软件的贪婪与硬件的无奈</h2>
<p>Sutter 提出了一个深刻的观点：<strong>我们对解决更复杂问题的需求，总是超过我们构建更强计算能力的速度。</strong></p>
<ul>
<li>2007 年的 iOS 开启了移动计算时代。</li>
<li>2022 年的 ChatGPT 开启了生成式 AI 时代。</li>
</ul>
<p>每一次硬件性能的飞跃，都会迅速被新兴的、更加“贪婪”的软件需求所吞噬。AI 只是这一长串名单中的最新一员。这意味着，<strong>我们永远不会拥有“足够快”的硬件</strong>，我们永远需要压榨出硬件的最后一滴性能。</p>
<p>因此，C++ 和 Rust 的开发者数量在过去三年（2022-2025）增长最快，这并非巧合，而是行业对高效能计算需求的直接反映。</p>
<h2>C++26 —— 安全与性能的“双重奏”</h2>
<p>面对 Rust 在内存安全方面的挑战，C++ 并没有坐以待毙。Sutter 详细介绍了即将发布的 <strong>C++26</strong> 标准在安全性上的重大突破：</p>
<ol>
<li><strong>消灭未初始化变量</strong>：C++26 将默认消除局部变量未初始化导致的未定义行为 (UB)。这是一个迟到但巨大的进步，直接消灭了一大类常见的安全漏洞。</li>
<li><strong>标准库“加固” (Hardening)</strong>：C++26 将引入标准库的“加固模式”，对常用的操作（如 vector 访问）进行边界检查。谷歌和苹果的实践数据表明，这种检查的开销极低（小于 1%），但能预防数以千计的潜在 Bug。</li>
<li><strong>契约 (Contracts)</strong>：C++26 将引入契约编程（Preconditions, Postconditions），将功能安全提升到语言层面。</li>
</ol>
<p>Sutter 甚至提出了一个大胆的设想：<strong>未来的 C++29 是否应该暂停新特性的开发，专注于“修补漏洞”和“全面硬化”？</strong> 这显示了 C++ 社区在安全性上的决心。</p>
<h2>AI 不会取代程序员，它只是计算器</h2>
<p>针对“AI 将取代程序员”的焦虑，Sutter 给出了一个冷静而乐观的比喻：<strong>AI 之于编程，就像计算器之于数学，或者搜索引擎之于知识。</strong></p>
<ul>
<li><strong>它是乘数，不是替代品</strong>：AI 能极大地减少死记硬背和样板代码的工作，让程序员专注于解决更难、更新的问题。</li>
<li><strong>需求在增长</strong>：即使有了 AI 加持，人类程序员的数量依然在快速增长。Atlassian CEO 指出：“如果软件开发的成本减半，我们不会减少一半的程序员，而是会编写两倍的软件，或者解决更复杂的问题。”</li>
<li><strong>AI 的局限</strong>：AI 只能解决已知的问题（训练数据覆盖的领域），而软件工程的核心价值在于解决<strong>未知的新问题</strong>。</li>
</ul>
<h2>小结：长期主义的胜利</h2>
<p>Herb Sutter 的这篇文章，是对高性能编程语言的一次强力辩护。在摩尔定律放缓、能源危机逼近、AI 需求爆发的今天，<strong>掌握一门能与硬件“对话”、能极致利用资源的语言（无论是 C++ 还是 Rust），不仅没有过时，反而变得比以往任何时候都更加重要。</strong></p>
<p>正如他所说：“软件拿走性能的速度，永远比硬件提供性能的速度要快。” 在这场追逐赛中，高效能开发者将永远是稀缺资源。</p>
<p>资料链接：https://herbsutter.com/2025/12/30/software-taketh-away-faster-than-hardware-giveth-why-c-programmers-keep-growing-fast-despite-competition-safety-and-ai</p>
<hr />
<p><strong>你的“能效”焦虑</strong></p>
<p>在你的日常开发中，是否也感受到了“算力不够用”或者“云成本过高”的压力？<strong>你认为在 AI 时代，掌握一门高性能系统级语言（C++/Rust）是变得更重要了，还是更边缘化了？</strong></p>
<p><strong>欢迎在评论区分享你的看法和职业规划！</strong> 让我们一起探讨如何在算力瓶颈时代突围。</p>
<p><strong>如果这篇文章为你拨开了迷雾，别忘了点个【赞】和【在看】，并转发给身边那些坚持底层开发的“硬核”朋友！</strong></p>
<hr />
<p>还在为“复制粘贴喂AI”而烦恼？我的新专栏 <strong>《<a href="http://gk.link/a/12EPd">AI原生开发工作流实战</a>》</strong> 将带你：</p>
<ul>
<li>告别低效，重塑开发范式</li>
<li>驾驭AI Agent(Claude Code)，实现工作流自动化</li>
<li>从“AI使用者”进化为规范驱动开发的“工作流指挥家”</li>
</ul>
<p>扫描下方二维码，开启你的AI原生开发之旅。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/ai-native-dev-workflow-qr.png" alt="" /></p>
<hr />
<p>你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？</p>
<ul>
<li>想写出更地道、更健壮的Go代码，却总在细节上踩坑？</li>
<li>渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？</li>
<li>想打造生产级的Go服务，却在工程化实践中屡屡受挫？</li>
</ul>
<p>继《<a href="http://gk.link/a/10AVZ">Go语言第一课</a>》后，我的《<a href="http://gk.link/a/12yGY">Go语言进阶课</a>》终于在极客时间与大家见面了！</p>
<p>我的全新极客时间专栏 《<a href="http://gk.link/a/12yGY">Tony Bai·Go语言进阶课</a>》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。</p>
<p>目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！</p>
<p><img src="https://tonybai.com/wp-content/uploads/course-card/iamtonybai-banner-2.gif" alt="" /></p>
<hr />
<p>商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。</p>
<p><img src="http://image.tonybai.com/img/tonybai/iamtonybai-wechat-qr.png" alt="" /></p>
<p style='text-align:left'>&copy; 2026, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2026/01/03/why-cpp-programmers-keep-growing-fast/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>别演了，真实的程序员根本不修电脑：我们左手AI，右手星辰大海</title>
		<link>https://tonybai.com/2025/12/21/real-programmers-dont-fix-computers-ai-stars-and-seas/</link>
		<comments>https://tonybai.com/2025/12/21/real-programmers-dont-fix-computers-ai-stars-and-seas/#comments</comments>
		<pubDate>Sun, 21 Dec 2025 10:57:06 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[技术志]]></category>
		<category><![CDATA[AI]]></category>
		<category><![CDATA[C]]></category>
		<category><![CDATA[ChatGPT]]></category>
		<category><![CDATA[Claude]]></category>
		<category><![CDATA[deepseek]]></category>
		<category><![CDATA[GarbageCollection]]></category>
		<category><![CDATA[github]]></category>
		<category><![CDATA[GMP]]></category>
		<category><![CDATA[Go]]></category>
		<category><![CDATA[Optimus]]></category>
		<category><![CDATA[Programmer]]></category>
		<category><![CDATA[Python]]></category>
		<category><![CDATA[raft]]></category>
		<category><![CDATA[RealProgrammers]]></category>
		<category><![CDATA[Slash]]></category>
		<category><![CDATA[SpaceX]]></category>
		<category><![CDATA[Tiktok]]></category>
		<category><![CDATA[Transformer]]></category>
		<category><![CDATA[人情世故]]></category>
		<category><![CDATA[具身智能]]></category>
		<category><![CDATA[刻板印象]]></category>
		<category><![CDATA[垃圾回收]]></category>
		<category><![CDATA[工具人]]></category>
		<category><![CDATA[技术平权]]></category>
		<category><![CDATA[控制算法]]></category>
		<category><![CDATA[斜杠青年]]></category>
		<category><![CDATA[新人类]]></category>
		<category><![CDATA[星舰]]></category>
		<category><![CDATA[星辰大海]]></category>
		<category><![CDATA[神经网络]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[逻辑思维]]></category>

		<guid isPermaLink="false">https://tonybai.com/?p=5575</guid>
		<description><![CDATA[本文永久链接 &#8211; https://tonybai.com/2025/12/21/real-programmers-dont-fix-computers-ai-stars-and-seas 大家好，我是Tony Bai。 最近陪家人看几部青春都市剧，实在忍不住想吐槽。 无论题材如何变，编剧笔下的程序员永远是那副德行：戴着黑框眼镜，背着双肩包，唯唯诺诺。而他们的戏份，似乎永远逃不开那一幕—— 男主角或者女神的电脑坏了，喊一声：“喂，那个谁，来修一下。” 然后镜头一转，程序员满头大汗地重启电脑，憨厚一笑。 别演了，真的。 都2025年了，大众对程序员的误解依然停留在“修电脑”和“当备胎”的阶段。 今天，我想撕掉这些标签，聊聊真实的程序员到底在做什么，以及为什么我们这群看似“无趣”的人，实则是未来 30 年人类文明的推手。 “没文化”的工具人？一种中国式的误读 在中国人的传统潜意识里，什么是“有才华”？什么是“有智慧”？ 是引经据典，是出口成章，是懂《周易》懂历史，是酒桌上推杯换盏间的人情练达。我们推崇的是“国学”与“人学”。 而程序员呢？ 我们脑子里装的是 GMP 调度模型，是 Transformer 架构，是 Raft 共识算法。 这些知识的认知门槛极高，掌握难度远超背诵几首唐诗。但在大众眼里，这叫“技能”，不叫“学问”；这叫“工具”，不叫“智慧”。 这就造成了一个巨大的荒诞： 一个能徒手写出操作系统内核的顶级工程师，可能因为在饭局上接不上关于“职场厚黑学”的梗，或者不懂得先敬领导一杯酒，就被贴上“木讷”、“情商低”、“读书读傻了”的标签。 我们不是学不会那些，我们只是不Care。 程序员的思维通过了严苛的逻辑训练，我们习惯了用 O(1) 的复杂度直达本质。对于那些充满了冗余、虚伪和 O(n^2) 复杂度的繁文缛节，我们的大脑会自动执行 Garbage Collection（垃圾回收）。 这种对他人的“降噪”处理，让我们在影视剧里看起来像个“怪胎”，但在代码的世界里，这正是我们构建万物的基石。 格子衫已死：新物种的诞生 如果我们把目光从影视剧移开，看一眼身边真实的 95 后、00 后程序员，你会发现那个“木讷”的标签早已过期。 程序员这个物种，正在经历一次剧烈的“版本迭代”。 去看看现在的互联网大厂，那个传说中的“格子衫军团”正在消失。取而代之的，是滑板少年、是汉服爱好者、是玩死亡重金属的贝斯手。 斜杠青年（Slash）： 你以为他只是个写 Go 语言的后端？下班后，他可能是 B 站拥有十万粉丝的科普 Up 主，可能是独立游戏的制作人，也可能是用 AI 生成艺术画作的数字艺术家。 拒绝被定义： [...]]]></description>
			<content:encoded><![CDATA[<p><img src="https://tonybai.com/wp-content/uploads/2025/real-programmers-dont-fix-computers-ai-stars-and-seas-1.png" alt="" /></p>
<p><a href="https://tonybai.com/2025/12/21/real-programmers-dont-fix-computers-ai-stars-and-seas">本文永久链接</a> &#8211; https://tonybai.com/2025/12/21/real-programmers-dont-fix-computers-ai-stars-and-seas</p>
<p>大家好，我是Tony Bai。</p>
<p>最近陪家人看几部青春都市剧，实在忍不住想吐槽。</p>
<p>无论题材如何变，编剧笔下的程序员永远是那副德行：戴着黑框眼镜，背着双肩包，唯唯诺诺。而他们的戏份，似乎永远逃不开那一幕——</p>
<p>男主角或者女神的电脑坏了，喊一声：“喂，那个谁，来修一下。”<br />
然后镜头一转，程序员满头大汗地重启电脑，憨厚一笑。</p>
<p><strong>别演了，真的。</strong></p>
<p>都2025年了，大众对程序员的误解依然停留在“修电脑”和“当备胎”的阶段。</p>
<p>今天，我想撕掉这些标签，聊聊<strong>真实的程序员</strong>到底在做什么，以及为什么我们这群看似“无趣”的人，实则是未来 30 年人类文明的推手。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/paid/api-design-pattern-and-implementation-qr.png" alt="img{512x368}" /></p>
<hr />
<h2>“没文化”的工具人？一种中国式的误读</h2>
<p>在中国人的传统潜意识里，什么是“有才华”？什么是“有智慧”？</p>
<p>是引经据典，是出口成章，是懂《周易》懂历史，是酒桌上推杯换盏间的人情练达。我们推崇的是<strong>“国学”与“人学”</strong>。</p>
<p>而程序员呢？</p>
<p>我们脑子里装的是 <strong>GMP 调度模型</strong>，是 <strong>Transformer 架构</strong>，是 <strong>Raft 共识算法</strong>。</p>
<p>这些知识的<strong>认知门槛</strong>极高，掌握难度远超背诵几首唐诗。但在大众眼里，这叫“技能”，不叫“学问”；这叫“工具”，不叫“智慧”。</p>
<p><strong>这就造成了一个巨大的荒诞：</strong></p>
<p>一个能徒手写出操作系统内核的顶级工程师，可能因为在饭局上接不上关于“职场厚黑学”的梗，或者不懂得先敬领导一杯酒，就被贴上<strong>“木讷”、“情商低”、“读书读傻了”</strong>的标签。</p>
<p>我们不是学不会那些，我们只是<strong>不Care</strong>。</p>
<p>程序员的思维通过了严苛的逻辑训练，我们习惯了用 O(1) 的复杂度直达本质。对于那些充满了冗余、虚伪和 O(n^2) 复杂度的繁文缛节，我们的大脑会自动执行 <strong>Garbage Collection（垃圾回收）</strong>。</p>
<p>这种对他人的“降噪”处理，让我们在影视剧里看起来像个“怪胎”，但在代码的世界里，这正是我们构建万物的基石。</p>
<hr />
<h2>格子衫已死：新物种的诞生</h2>
<p>如果我们把目光从影视剧移开，看一眼身边真实的 95 后、00 后程序员，你会发现那个“木讷”的标签早已过期。</p>
<p><strong>程序员这个物种，正在经历一次剧烈的“版本迭代”。</strong></p>
<p>去看看现在的互联网大厂，那个传说中的“格子衫军团”正在消失。取而代之的，是滑板少年、是汉服爱好者、是玩死亡重金属的贝斯手。</p>
<ul>
<li>
<p><strong>斜杠青年（Slash）：</strong><br />
你以为他只是个写 Go 语言的后端？下班后，他可能是 B 站拥有十万粉丝的科普 Up 主，可能是独立游戏的制作人，也可能是用 AI 生成艺术画作的数字艺术家。</p>
</li>
<li>
<p><strong>拒绝被定义：</strong><br />
如果说上一代程序员的特征是“忍耐”和“沉默”，那么新一代程序员的特征就是<strong>“表达”</strong>和<strong>“重塑”</strong>。他们不屑于酒桌文化，因为他们更崇尚<strong>“技术平权”</strong>和<strong>“透明沟通”</strong>。</p>
</li>
</ul>
<p>这不再是一群只会修电脑的“工具人”，而是一群试图用技术手段去重构生活方式的“新人类”。</p>
<p>他们在 Github 上构建世界，也在小红书和 Tiktok 上分享生活。<strong>他们不是不懂生活，他们是在用代码重新定义什么是“酷”的生活。</strong></p>
<hr />
<h2>左手 AI，右手星辰大海</h2>
<p>影视剧还在忙着刻画我们“修电脑”的窘态，却完全没意识到，这群“配角”，此刻正在现实世界中酝酿着怎样的惊涛骇浪。</p>
<p><strong>我们正站在人类历史最疯狂的转折点上。</strong></p>
<p>当你嘲笑程序员不懂“风花雪月”时，他们正在做上帝的工作：</p>
<ul>
<li>
<p><strong>左手，赋予机器“灵魂”与“肉体”：</strong><br />
那些让你惊叹的 ChatGPT、Claude、DeepSeek，背后是程序员用代码搭建的神经网络。宇树G1/H1，特斯拉的 Optimus等人形机器人，正在走进现实。是程序员将逻辑注入钢铁躯体，让机器人学会行走、抓取，甚至学会思考。<strong>具身智能</strong>的爆发，将彻底重塑物理世界。</p>
</li>
<li>
<p><strong>右手，征服星辰大海：</strong><br />
SpaceX 的“筷子”夹住星舰的那一刻，全球沸腾。那毫秒级的姿态调整，不是靠吟诗作对实现的，而是靠几十万行严密的<strong>控制算法</strong>。</p>
</li>
</ul>
<p><strong>谁才是这个时代的“男一号”？</strong></p>
<p>是那些在剧里谈情说爱的主角吗？不。</p>
<p>是那些在屏幕后，用 Go 语言重构微服务，用 Python 训练大模型，用 C++ 控制火箭姿态的所谓“码农”。</p>
<p><strong>流行文化在消费我们，而我们在重塑流行文化赖以生存的世界。</strong></p>
<p>国学典籍是<strong>面向过去</strong>的接口，它教我们如何维系一个稳定的人情社会；</p>
<p>编程语言是<strong>面向未来</strong>的接口，它教我们如何与硅基生命对话，如何在此刻定义未来 30 年的规则。</p>
<hr />
<h2>小结：致敬时代的推手</h2>
<p>也许在未来的很长一段时间里，影视剧里的程序员依然会是那个戴着眼镜、不懂风情的“路人甲”。</p>
<p>没关系。让我们接受这种“误读”。</p>
<p>因为这种“忽视”，恰恰是一种保护色。它让我们这群人能远离嘈杂的名利场和复杂的人际关系，心无旁骛地坐在屏幕前。</p>
<p><strong>我们不需要修电脑，我们在修补这个世界的 Bug；</strong></p>
<p><strong>我们不需要当偶像剧的主角，我们在编写人类文明的下一个版本。</strong></p>
<p>致敬每一位“不善言辞”，但正在改变世界的程序员。</p>
<hr />
<p><strong>作为程序员，你曾在哪一刻因为“不懂人情世故”或“不关注大众话题”而被误解过？而在那一刻，你脑子里其实正在思考什么硬核的技术问题？</strong></p>
<p>欢迎在评论区，分享你的“社死”与“高光”时刻。</p>
<hr />
<p><strong>未来30年，是属于工程师的黄金时代。</strong></p>
<p>别让你的技能停留在“修电脑”的阶段。想要掌握 <strong>Go 语言在云原生、AI 工程化</strong> 中的核心能力，紧跟 <strong>具身智能</strong> 的浪潮？</p>
<p>加入我的 <strong>「Go &amp; AI 精进营」</strong>。在这里，我们不聊厚黑学，只聊如何拿到通往未来的船票。</p>
<p><strong>[此处放置知识星球二维码]</strong></p>
<hr />
<p>还在为“复制粘贴喂AI”而烦恼？我的新专栏 <strong>《<a href="http://gk.link/a/12EPd">AI原生开发工作流实战</a>》</strong> 将带你：</p>
<ul>
<li>告别低效，重塑开发范式</li>
<li>驾驭AI Agent(Claude Code)，实现工作流自动化</li>
<li>从“AI使用者”进化为规范驱动开发的“工作流指挥家”</li>
</ul>
<p>扫描下方二维码，开启你的AI原生开发之旅。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/ai-native-dev-workflow-qr.png" alt="" /></p>
<hr />
<p>你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？</p>
<ul>
<li>想写出更地道、更健壮的Go代码，却总在细节上踩坑？</li>
<li>渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？</li>
<li>想打造生产级的Go服务，却在工程化实践中屡屡受挫？</li>
</ul>
<p>继《<a href="http://gk.link/a/10AVZ">Go语言第一课</a>》后，我的《<a href="http://gk.link/a/12yGY">Go语言进阶课</a>》终于在极客时间与大家见面了！</p>
<p>我的全新极客时间专栏 《<a href="http://gk.link/a/12yGY">Tony Bai·Go语言进阶课</a>》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。</p>
<p>目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！</p>
<p><img src="https://tonybai.com/wp-content/uploads/course-card/iamtonybai-banner-2.gif" alt="" /></p>
<hr />
<p>商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。</p>
<p><img src="http://image.tonybai.com/img/tonybai/iamtonybai-wechat-qr.png" alt="" /></p>
<p style='text-align:left'>&copy; 2025, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2025/12/21/real-programmers-dont-fix-computers-ai-stars-and-seas/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>给了机关枪，你却非要耍大刀：2025 年末，程序员 All in AI 的生存启示录</title>
		<link>https://tonybai.com/2025/12/09/programmer-all-in-ai-survival-revelation-in-2025/</link>
		<comments>https://tonybai.com/2025/12/09/programmer-all-in-ai-survival-revelation-in-2025/#comments</comments>
		<pubDate>Tue, 09 Dec 2025 00:17:51 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[技术志]]></category>
		<category><![CDATA[2025年末]]></category>
		<category><![CDATA[AgenticTools]]></category>
		<category><![CDATA[AI]]></category>
		<category><![CDATA[AI原生工作流]]></category>
		<category><![CDATA[AllinAI]]></category>
		<category><![CDATA[ChainofThought]]></category>
		<category><![CDATA[ChatGPT]]></category>
		<category><![CDATA[ClaudeCode]]></category>
		<category><![CDATA[ContextInjection]]></category>
		<category><![CDATA[Copilot]]></category>
		<category><![CDATA[Cursor]]></category>
		<category><![CDATA[EditorinChief]]></category>
		<category><![CDATA[Hallucination]]></category>
		<category><![CDATA[Programmer]]></category>
		<category><![CDATA[SDD]]></category>
		<category><![CDATA[SpecDriven]]></category>
		<category><![CDATA[syntax]]></category>
		<category><![CDATA[Windsurf]]></category>
		<category><![CDATA[价值判断]]></category>
		<category><![CDATA[伪精英心态]]></category>
		<category><![CDATA[外骨骼]]></category>
		<category><![CDATA[大刀]]></category>
		<category><![CDATA[思维躺平]]></category>
		<category><![CDATA[总编辑]]></category>
		<category><![CDATA[技术洁癖]]></category>
		<category><![CDATA[智能体]]></category>
		<category><![CDATA[机关枪]]></category>
		<category><![CDATA[概率预测]]></category>
		<category><![CDATA[生存启示录]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[规范驱动开发]]></category>
		<category><![CDATA[认知重构]]></category>

		<guid isPermaLink="false">https://tonybai.com/?p=5502</guid>
		<description><![CDATA[本文永久链接 &#8211; https://tonybai.com/2025/12/09/programmer-all-in-ai-survival-revelation-in-2025 大家好，我是Tony Bai。 最近逛 Twitter 和技术论坛，我发现了一个非常有意思，甚至有些魔幻的现象。 尽管我们已经站在了 2025 年末，距离 ChatGPT 震撼发布已经过去了整整三年，AI 能力早已从“玩具”进化成了“重型武器”。但在评论区里，依然充斥着大量这样的声音： “真程序员谁用 AI 啊，那都是给脚本小子用的。” “用 AI 生成代码没有灵魂，我还是习惯自己掌控每一个字符。” &#8230; &#8230; 看着这些言论，再联想到身边团队和朋友圈中的一些类似的现象，我忍不住在我的知识星球中发了一句感慨： “给了你机关枪，你却非得用大刀。这不仅是不合时宜，简直是暴殄天物” 这三年，AI 不再是那个只会写打油诗的聊天机器人，它是基建，是水电，是程序员的第二大脑。 在这个时间节点，命题早已改变：不再是“要不要用 AI”，而是“你为什么还在用大刀砍柴？” 但在真正 All in AI 之前，我们必须先看清现实中普遍存在的“四大怪象”，并一一打破它们。 现实中的“四大怪象” 如果你仔细观察身边的技术团队，朋友圈或者审视一下自己，可能就会发现我们都在不自觉地陷入以下误区： 怪象一：技术洁癖引发的“伪精英心态” 很多人认为依赖工具是能力退化的表现。他们以“纯手工打造”为荣，认为只有自己敲出来的代码/文字才叫硬核，用 AI 就像是“作弊”。 怪象二：工具依赖导致的“思维躺平” 另一极端是，有了 AI 就不思考了。遇到问题直接扔给 AI，AI 给什么就用什么，不再去探究底层的原理，甚至觉得“反正 AI 会，我不用学了”。 怪象三：盲目信任带来的“埋雷行为” 把 AI 当作真理的化身。直接 Copy &#38; Paste AI [...]]]></description>
			<content:encoded><![CDATA[<p><img src="https://tonybai.com/wp-content/uploads/2025/programmer-all-in-ai-survival-revelation-in-2025-1.png" alt="" /></p>
<p><a href="https://tonybai.com/2025/12/09/programmer-all-in-ai-survival-revelation-in-2025">本文永久链接</a> &#8211; https://tonybai.com/2025/12/09/programmer-all-in-ai-survival-revelation-in-2025</p>
<p>大家好，我是Tony Bai。</p>
<p>最近逛 Twitter 和技术论坛，我发现了一个非常有意思，甚至有些魔幻的现象。</p>
<p>尽管我们已经站在了 <strong>2025 年末</strong>，距离 ChatGPT 震撼发布已经过去了整整三年，AI 能力早已从“玩具”进化成了“重型武器”。但在评论区里，依然充斥着大量这样的声音：</p>
<ul>
<li>“真程序员谁用 AI 啊，那都是给脚本小子用的。”</li>
<li>“用 AI 生成代码没有灵魂，我还是习惯自己掌控每一个字符。”</li>
<li>&#8230; &#8230;</li>
</ul>
<p>看着这些言论，再联想到身边团队和朋友圈中的一些类似的现象，我忍不住在我的知识星球中发了一句感慨：</p>
<p><strong>“给了你机关枪，你却非得用大刀。这不仅是不合时宜，简直是暴殄天物”</strong></p>
<p>这三年，AI 不再是那个只会写打油诗的聊天机器人，它是基建，是水电，是程序员的第二大脑。</p>
<p>在这个时间节点，命题早已改变：不再是“要不要用 AI”，而是<strong>“你为什么还在用大刀砍柴？”</strong></p>
<p>但在真正 All in AI 之前，我们必须先看清现实中普遍存在的<strong>“四大怪象”</strong>，并一一打破它们。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/programmer-all-in-ai-survival-revelation-in-2025-2.png" alt="" /></p>
<hr />
<h2>现实中的“四大怪象”</h2>
<p>如果你仔细观察身边的技术团队，朋友圈或者审视一下自己，可能就会发现我们都在不自觉地陷入以下误区：</p>
<p><strong>怪象一：技术洁癖引发的“伪精英心态”</strong></p>
<p>很多人认为依赖工具是能力退化的表现。他们以“纯手工打造”为荣，认为只有自己敲出来的代码/文字才叫硬核，用 AI 就像是“作弊”。</p>
<p><strong>怪象二：工具依赖导致的“思维躺平”</strong></p>
<p>另一极端是，有了 AI 就不思考了。遇到问题直接扔给 AI，AI 给什么就用什么，不再去探究底层的原理，甚至觉得“反正 AI 会，我不用学了”。</p>
<p><strong>怪象三：盲目信任带来的“埋雷行为”</strong></p>
<p>把 AI 当作真理的化身。直接 Copy &amp; Paste AI 生成的代码上线，不看逻辑，不测边界，结果把 AI 的幻觉（Hallucination）直接变成了线上的 Bug。</p>
<p><strong>怪象四：浅尝辄止的“低效勤奋”</strong></p>
<p>虽然也在用 AI，但只停留在“帮我写个正则”、“解释这段代码”的浅层阶段。手里拿着加特林机关枪，却只把它当烧火棍用。</p>
<hr />
<h2>All in AI 之前的“四重认知突围”</h2>
<p>针对上述怪象，如果想在 2025 年以及未来几年生存并晋级，我们需要进行一次彻底的认知重构。</p>
<h3>认知 1：拒绝羞耻感 —— 它是“外骨骼”，不是“轮椅”</h3>
<p><em>(对标怪象一)</em></p>
<p>越是基本功扎实的老兵，越容易有“技术羞耻感”。请立刻抛弃这种旧思维。</p>
<p>在 2025 年，<strong>能力定义的公式变了</strong>。</p>
<ul>
<li>旧能力 = 记忆力 + 手速 + 经验</li>
<li>新能力 = <strong>(经验 + 洞察) × AI 算力</strong></li>
</ul>
<p>使用 AI 不是因为你“能力不行”需要轮椅，而是为了<strong>放大</strong>你的能力。它让你从繁琐的语法/文书细节（Syntax）中解脱出来，让你的架构设计能力得以十倍级释放。<strong>善用“机关枪”是特种兵的素养，不是逃兵的借口。</strong></p>
<h3>认知 2：拒绝躺平 —— 是“升维”，不是“减负”</h3>
<p><em>(对标怪象二)</em></p>
<p>以为用了 AI 就可以不学习了？大错特错。</p>
<p><strong>AI 时代的学习逻辑发生了倒置：</strong> AI 负责“已知知识的检索与生成”，你负责“未知领域的洞察与判断”。</p>
<p>当 AI 帮你搞定了 80% 的“实现细节（How）”，你必须把节省下来的精力，投入到那 20% 更核心的“价值判断（Why &amp; What）”中。</p>
<p>你不仅不能停止学习，反而要学得更深、更广——否则你甚至不知道该如何向 AI 提问，更不知道如何判断它给出的方案是平庸还是卓越。</p>
<h3>认知 3：坚守底线 —— 做“机长”，不做“乘客”</h3>
<p><em>(对标怪象三)</em></p>
<p>AI 的第一性原理（概率预测）决定了它永远存在“一本正经胡说八道”的可能。</p>
<p><strong>对 AI 输出的成果物进行严苛的审核 (Review)，是任何成果物发布前的必经路径。</strong></p>
<p>你需要从“Writer（撰稿人）”转型为<strong>“Editor-in-Chief（总编辑）”</strong>。</p>
<p>你是机长，AI 是副驾驶。它负责操作仪表盘，但<strong>你负责决定航向，并对每一次降落的安全性负责。</strong> 没有审核的 AI 代码/文档，就是一颗定时炸弹。这意味着你不能只看代码跑通了没有，还要像审查实习生代码一样，去盘问它的逻辑漏洞和边缘情况。</p>
<h3>认知 4：直面竞争 —— 比的是“枪法”，不是“有枪”</h3>
<p><em>(对标怪象四)</em></p>
<p>三年过去，AI 已经祛魅。现在人人手里都有一把“机关枪”（Cursor, Claude Code, Copilot 等）。</p>
<p>竞争的维度变了：<strong>不再是谁有枪（因为大家都有），而是谁的枪法更准。</strong></p>
<ul>
<li><strong>初级枪法：</strong> 单轮对话，只会问简单问题。</li>
<li><strong>高级枪法：</strong> 懂得 Context Injection（上下文注入）、Chain of Thought（思维链）、Spec-Driven（规范驱动开发工作流）。</li>
</ul>
<p><strong>“都用 AI”只是入场券。</strong> 真正的比拼，在于谁用得更深、更精，谁能用这把枪打出“百步穿杨”的效果。</p>
<hr />
<h2>小结：是时候All in AI了！</h2>
<p>技术历史的车轮滚滚向前，残酷性从未改变。</p>
<p>每一次技术范式的转移，都会留下一批抱残守缺的“大刀队”。他们不是不努力，他们甚至比谁都辛苦，每天挥舞大刀砍得汗流浃背，但在“机关枪”的扫射下，这种努力显得苍白无力。</p>
<p><strong>2025 年末，放下你的大刀吧。</strong></p>
<p>去学习怎么校准瞄准镜，怎么控制后坐力，怎么设计交叉火力网。这不丢人。这才是对技术、对自己职业生涯最大的尊重。</p>
<hr />
<p><strong>互动话题</strong></p>
<p>在使用 AI 编程的过程中，你遇到过最让你“细思极恐”的时刻是什么？或者最让你感到“真香”的瞬间是什么？欢迎在留言区分享你的故事。</p>
<hr />
<p><strong>如何练就“百步穿杨”的枪法？</strong></p>
<p>文章里我们说了，“都用 AI”只是入场券，真正的决胜点在于<strong>谁用得更深、更精，谁拥有一套高维度的“AI 原生工作流”</strong>。</p>
<p>如果你已经决定放下“大刀”，拿起“机关枪”，但面对市面上眼花缭乱的工具（Claude Code, Cursor, Windsurf）和碎片化的技巧，感到无从下手；</p>
<p>或者你虽然用了 AI，但发现自己依然陷入在“改 Bug -> AI 生成新 Bug”的低效死循环中；</p>
<p>那么，欢迎加入我的极客时间专栏<strong>《AI 原生开发工作流实战》</strong>。</p>
<p>在这里，我们将深入实战：</p>
<ul>
<li><strong>重构开发范式：</strong> 彻底告别“聊天式编程”，掌握 <strong>SDD (规范驱动开发)</strong> 的核心心法，学会用 Spec 文档精准指挥 AI。</li>
<li><strong>驾驭 Agentic 系统：</strong> 深入剖析 Claude Code 等 <strong>Agentic Tools</strong> 的底层逻辑，把它们变成你忠实的“外包团队”。</li>
<li><strong>构建私有/团队工作流：</strong> 手把手教你搭建一套<strong>“人脑定义目标 + AI 并发执行”</strong>的高效流水线。</li>
</ul>
<p><strong>别让手里的机关枪生锈。</strong> 点击下方卡片，我们一起在实战中进化。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/ai-native-dev-workflow-qr.png" alt="" /></p>
<hr />
<p>你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？</p>
<ul>
<li>想写出更地道、更健壮的Go代码，却总在细节上踩坑？</li>
<li>渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？</li>
<li>想打造生产级的Go服务，却在工程化实践中屡屡受挫？</li>
</ul>
<p>继《<a href="http://gk.link/a/10AVZ">Go语言第一课</a>》后，我的《<a href="http://gk.link/a/12yGY">Go语言进阶课</a>》终于在极客时间与大家见面了！</p>
<p>我的全新极客时间专栏 《<a href="http://gk.link/a/12yGY">Tony Bai·Go语言进阶课</a>》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。</p>
<p>目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！</p>
<p><img src="https://tonybai.com/wp-content/uploads/course-card/iamtonybai-banner-2.gif" alt="" /></p>
<hr />
<p>商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。</p>
<p><img src="http://image.tonybai.com/img/tonybai/iamtonybai-wechat-qr.png" alt="" /></p>
<p style='text-align:left'>&copy; 2025, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2025/12/09/programmer-all-in-ai-survival-revelation-in-2025/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Anthropic 内部报告：程序员的“死”与“生”，效率暴增 50% 的残酷启示</title>
		<link>https://tonybai.com/2025/12/05/how-ai-is-transforming-work-at-anthropic/</link>
		<comments>https://tonybai.com/2025/12/05/how-ai-is-transforming-work-at-anthropic/#comments</comments>
		<pubDate>Fri, 05 Dec 2025 00:16:01 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[技术志]]></category>
		<category><![CDATA[Agentic]]></category>
		<category><![CDATA[AI]]></category>
		<category><![CDATA[AIDevelopmentWorkflow]]></category>
		<category><![CDATA[AI原生工作流]]></category>
		<category><![CDATA[Anthropic]]></category>
		<category><![CDATA[ClaudeCode]]></category>
		<category><![CDATA[ColdStart]]></category>
		<category><![CDATA[Context]]></category>
		<category><![CDATA[ContextManagement]]></category>
		<category><![CDATA[Fullstackization]]></category>
		<category><![CDATA[Opus]]></category>
		<category><![CDATA[PowerUsers]]></category>
		<category><![CDATA[Productivity]]></category>
		<category><![CDATA[Prompting]]></category>
		<category><![CDATA[SoftwareEngineer]]></category>
		<category><![CDATA[sonnet]]></category>
		<category><![CDATA[TrustbutVerify]]></category>
		<category><![CDATA[上下文管理]]></category>
		<category><![CDATA[全栈工程师]]></category>
		<category><![CDATA[冷启动]]></category>
		<category><![CDATA[技能萎缩]]></category>
		<category><![CDATA[指挥家]]></category>
		<category><![CDATA[提示词]]></category>
		<category><![CDATA[效率暴增]]></category>
		<category><![CDATA[生产力]]></category>
		<category><![CDATA[监督悖论]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[职业变革]]></category>
		<category><![CDATA[自主智能体]]></category>
		<category><![CDATA[软件工程]]></category>

		<guid isPermaLink="false">https://tonybai.com/?p=5479</guid>
		<description><![CDATA[本文永久链接 &#8211; https://tonybai.com/2025/12/05/how-ai-is-transforming-work-at-anthropic 大家好，我是Tony Bai。 当我们还在争论 AI 编程是否是“玩具”时，Anthropic 已经把镜头对准了自己。 2025 年 8 月，这家打造了 Claude 的顶尖 AI 公司，对自己内部的 132 名工程师和研究员进行了一次深度“体检”。他们分析了 20 万条 Claude Code（Anthropic 打造的、并同时也在内部使用的 AI 编程 CLI 工具）的使用记录，并进行了深度的定性访谈。 这份刚刚发布的调研报告，揭示了一个既令人兴奋又令人胆寒的真相：在 AI 原生工作流的加持下，工程师的生产力暴增了 50%，但旧时代的“程序员”正在死去，一种全新的职业物种正在诞生。 在我看来，这既是一份内部效率调查报告，更是一份关于软件工程师职业命运的“生死簿”。 “生”的狂欢：效率暴增 50% 后的质变 数据是惊人的，甚至可以说是具有颠覆性的。 与一年前相比，Anthropic 工程师使用 Claude 的频率翻了一倍，自我报告的生产力提升从 20% 飙升到了 50%。在极端的“超级用户”（Power Users，占总数 14%）中，这一数字甚至超过了 100%。 但这种提升并非意味着大家“闲下来”了。报告发现了一个反直觉的现象：在 AI 的辅助下，工程师们花在每个任务上的时间变少了，但产出的总工作量却大幅增加了。 这不仅仅是效率的量变，更是工作内容的质变： 新功能的爆发：在 Claude Code 的帮助下，工程师用于“实现新功能”的时间占比从六个月前的 [...]]]></description>
			<content:encoded><![CDATA[<p><img src="https://tonybai.com/wp-content/uploads/2025/how-ai-is-transforming-work-at-anthropic-1.png" alt="" /></p>
<p><a href="https://tonybai.com/2025/12/05/how-ai-is-transforming-work-at-anthropic">本文永久链接</a> &#8211; https://tonybai.com/2025/12/05/how-ai-is-transforming-work-at-anthropic</p>
<p>大家好，我是Tony Bai。</p>
<p>当我们还在争论 AI 编程是否是“玩具”时，Anthropic 已经把镜头对准了自己。</p>
<p>2025 年 8 月，这家打造了 Claude 的顶尖 AI 公司，对自己内部的 132 名工程师和研究员进行了一次深度“体检”。他们分析了 <strong>20 万条 Claude Code（Anthropic 打造的、并同时也在内部使用的 AI 编程 CLI 工具）的使用记录</strong>，并进行了深度的定性访谈。</p>
<p>这份刚刚发布的调研报告，揭示了一个既令人兴奋又令人胆寒的真相：<strong>在 AI 原生工作流的加持下，工程师的生产力暴增了 50%，但旧时代的“程序员”正在死去，一种全新的职业物种正在诞生。</strong></p>
<p>在我看来，这既是一份内部效率调查报告，更是一份关于软件工程师职业命运的“生死簿”。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/paid/google-adk-in-action-qr.png" alt="" /></p>
<hr />
<h2>“生”的狂欢：效率暴增 50% 后的质变</h2>
<p>数据是惊人的，甚至可以说是具有颠覆性的。</p>
<p>与一年前相比，Anthropic 工程师使用 Claude 的频率翻了一倍，<strong>自我报告的生产力提升从 20% 飙升到了 50%</strong>。在极端的“超级用户”（Power Users，占总数 14%）中，这一数字甚至超过了 100%。</p>
<p>但这种提升并非意味着大家“闲下来”了。报告发现了一个反直觉的现象：<strong>在 AI 的辅助下，工程师们花在每个任务上的时间变少了，但产出的总工作量却大幅增加了。</strong></p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/how-ai-is-transforming-work-at-anthropic-2.png" alt="" /></p>
<p>这不仅仅是效率的量变，更是工作内容的质变：</p>
<ul>
<li><strong>新功能的爆发</strong>：在 Claude Code 的帮助下，工程师用于“实现新功能”的时间占比从六个月前的 14% 激增至 <strong>37%</strong>(如下图)。AI 不再只是写样板代码的助手，而是直接参与核心构建的主力。</li>
</ul>
<p><img src="https://tonybai.com/wp-content/uploads/2025/how-ai-is-transforming-work-at-anthropic-3.png" alt="" /></p>
<ul>
<li><strong>消灭“千纸鹤”</strong>：数据显示，<strong>8.6%</strong> 的 Claude Code 任务是在处理那些长期存在、令人烦恼但优先级不高的“小毛病”。这包括重构糟糕的代码结构、编写缺失的测试、或是构建一个小工具来优化流程。正如一位工程师所言：“通过降低‘激活能量’，AI 让我不再拖延，愿意去解决那些以前觉得‘不值得动手’的麻烦事。”</li>
<li><strong>“第 27%”的创新</strong>：员工估计，<strong>27%</strong> 的 AI 辅助工作是“如果没有 AI 就根本不会做”的。这包括构建交互式数据仪表盘、进行更广泛的探索性测试，或者像一位研究员那样——运行一个拥有“百万马力”的 Claude 实例来测试不同的想法。</li>
</ul>
<p>AI 并没有让工程师“摸鱼”，而是赋予了他们<strong>“三头六臂”</strong>，让他们在同样的时间里，触达了以前无法企及的广度和深度。</p>
<hr />
<h2>边界的消亡：人人都是全栈工程师</h2>
<p>报告中最令人兴奋——也最让传统岗位感到“危机”——的发现之一，是 <strong>AI 开发工作流</strong> 正在打破工程师的技能边界。一种<strong>“全能化” (Full-stackization)</strong> 的趋势正在形成，专业分工的护城河正在被填平。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/how-ai-is-transforming-work-at-anthropic-4.png" alt="" /></p>
<ul>
<li><strong>后端写前端</strong>：一位后端工程师描述了他如何通过提示词（Prompting）构建了一个复杂的 UI：“它做得比我好多了。如果是以前，我绝对做不到，更不可能按时完成。设计师问我‘这是你做的？’我说‘不，是 Claude 做的，我只是负责提示。’”</li>
<li><strong>安全做开发</strong>：安全团队利用 Claude Code 快速理解陌生的代码库，分析不同模块的安全隐患，其使用场景中有 <strong>48.9%</strong> 是为了“代码理解”。</li>
<li><strong>非技术人员写代码</strong>：产品经理和研究员开始自己动手修复 Bug、编写数据分析脚本，填补了技术与业务之间的沟壑。</li>
</ul>
<p>这种变化意味着，软件工程师将不再被特定的语言或框架（如“Go 专家”或“React 大师”）所定义，而是被<strong>解决问题的能力</strong>所定义。<strong>在 AI 原生工作流中，只要有想法，技术栈不再是护城河，而是可以随意调用的工具箱。</strong></p>
<hr />
<h2>信任的进化：从“验证”到“导航”</h2>
<p>随着 Claude Code 及其背后模型的进化（从 Sonnet 到 Opus），工程师们对 AI 的使用方式经历了从“小心翼翼”到“深度协同”的转变。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/how-ai-is-transforming-work-at-anthropic-5.png" alt="" /></p>
<ul>
<li><strong>Agentic（自主智能体化）能力的飞跃</strong>：六个月前，Claude Code 平均只能连续执行 10 个操作；现在，它可以<strong>自主完成约 21.2 个连续的工具调用</strong>（如编辑文件、运行测试、修复错误），期间无需人类干预。</li>
<li><strong>从“谷歌地图”到“自动驾驶”</strong>：一位工程师用“谷歌地图”来比喻这种信任的演变。起初，我们只在熟悉的路段用导航；后来，即使导航给出了一条陌生的路线，我们也愿意相信它是最优解。</li>
<li><strong>信任但验证 (Trust but Verify)</strong>：但这并不意味着盲从。报告指出，工程师们发展出了一套成熟的<strong>AI 协作策略</strong>：对于低风险、易验证的任务（如生成测试数据），直接放手；对于高风险、核心逻辑的任务，则保持高度的“人机协同”。</li>
</ul>
<p><strong>“冷启动”问题</strong>成为了新的瓶颈。一位工程师坦言：“如果我有关于代码库的大量隐性知识，而 Claude 没有，我宁愿自己写，也不想花时间去写完美的 Prompt。” 这也暗示了在 AI 开发工作流中，<strong>上下文管理 (Context Management)</strong> 将成为一项核心技能。</p>
<hr />
<h2>“死”的阴影：残酷的技能萎缩与监督悖论</h2>
<p>然而，硬币的另一面是深深的焦虑。报告极其诚实地记录了工程师们面临的“残酷”现实——旧的生存法则正在失效。</p>
<p><strong>1. “监督悖论”</strong></p>
<p>这是报告中最深刻、最令人不安的洞见之一。高效使用 Claude 需要监督，而监督 Claude 需要高超的编码技能。“如果我不再亲自写代码，不再通过痛苦的调试来建立对系统的直觉，我的技能会萎缩吗？” 如果技能萎缩了，未来谁还有能力去评估 AI 写出的代码是好是坏？</p>
<p>一位资深工程师坦言：“我现在主要用 AI 做我已经知道答案的事情。这种直觉是我通过‘硬核模式’积累的。如果我是现在的初级工程师，我不知道该如何建立这种直觉。”</p>
<p><strong>2. 社交的“原子化”</strong></p>
<p>Claude 成为了“第一咨询对象”。原本需要问同事的问题，现在 <strong>80-90%</strong> 都先问 AI。这虽然减少了对他人的打扰，但也切断了隐性的知识传递。初级工程师失去了向资深工程师提问的机会，团队的凝聚力面临挑战。一位 Tech Lead 感叹：“初级员工不再带着问题来找我了，这让我感到失落。”</p>
<p><strong>3. “把自己淘汰”的担忧</strong></p>
<p>“我觉得我每天上班都在致力于让自己失业。” 这种情绪在访谈中并不罕见。虽然短期内大家对生产力的提升感到兴奋，但对于长期——当 AI 真的能由端到端地完成所有工作时——人类工程师的位置在哪里？</p>
<p>一位工程师的比喻令人深思：“也许我们正在从编写代码，转向编写<strong>英语</strong>作为一种编程语言。未来的核心技能，是擅长让 AI 干活。”</p>
<hr />
<h2>小结：在“副驾驶”与“自动驾驶”之间</h2>
<p>Anthropic 的这份报告，向我们展示了一个正在加速到来的未来：软件工程正在从“手工艺”转向“工业化管理”。</p>
<p>旧时代的“码农”——那些仅仅通过记忆语法和 API 来堆砌代码的人——正在不可避免地走向<strong>消亡</strong>。</p>
<p>而新时代的工程师正在<strong>重生</strong>。他们更像是一位<strong>指挥家</strong>，挥舞着 <strong>Claude Code</strong> 这样的指挥棒，构建高效的 <strong>AI 开发工作流</strong>，调动着成千上万的虚拟算力，去构建前所未有的宏大系统。</p>
<p><strong>“残酷”的真相在于：技术不会淘汰工程师，但“掌握 AI 开发工作流”的工程师将淘汰那些还在徒手搬砖的人。</strong></p>
<p>拒绝 AI 的人，注定无法成为这场变革的指挥家。</p>
<p>要查阅这份报告的更多详情，请访问 <a href="https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic">Anthropic 的研究页面</a>。</p>
<hr />
<p><strong>你感受到这种变化了吗？</strong></p>
<p>看了Anthropic的报告，你是感到兴奋还是焦虑？在你的日常工作中，AI是你的“副驾驶”，还是已经开始接管方向盘了？你担心中断“硬核模式”训练会导致技能萎缩吗？</p>
<p>欢迎在评论区分享你的真实感受和思考！</p>
<hr />
<p>** 想要掌控这套未来的“指挥棒”？**</p>
<p>Anthropic 的工程师们已经向我们证明：效率提升 50% 只是起步。在这个“死”与“生”的转折点，你准备好进化了吗？</p>
<p>你是否也想打破技能边界，从后端迈向全栈，甚至更多？<br />
你是否想知道如何构建自己的 <strong>Context</strong>，解决 AI 的“冷启动”问题，规避“监督悖论”？</p>
<p>我精心打造的<strong>极客时间专栏《AI 原生开发工作流实战》</strong>，正是为你准备的“生存与进化手册”。</p>
<p><strong>别让未来把你抛下。扫描下方二维码，立刻开启你的 AI 原生开发之旅！</strong></p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/ai-native-dev-workflow-qr.png" alt="" /></p>
<hr />
<p>你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？</p>
<ul>
<li>想写出更地道、更健壮的Go代码，却总在细节上踩坑？</li>
<li>渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？</li>
<li>想打造生产级的Go服务，却在工程化实践中屡屡受挫？</li>
</ul>
<p>继《<a href="http://gk.link/a/10AVZ">Go语言第一课</a>》后，我的《<a href="http://gk.link/a/12yGY">Go语言进阶课</a>》终于在极客时间与大家见面了！</p>
<p>我的全新极客时间专栏 《<a href="http://gk.link/a/12yGY">Tony Bai·Go语言进阶课</a>》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。</p>
<p>目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！</p>
<p><img src="https://tonybai.com/wp-content/uploads/course-card/iamtonybai-banner-2.gif" alt="" /></p>
<hr />
<p>商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。</p>
<p><img src="http://image.tonybai.com/img/tonybai/iamtonybai-wechat-qr.png" alt="" /></p>
<p style='text-align:left'>&copy; 2025, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2025/12/05/how-ai-is-transforming-work-at-anthropic/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>从韩立到梅西：顶级“全栈工程师”的修炼之道与生存哲学</title>
		<link>https://tonybai.com/2025/11/23/leo-messi-and-fanren-hanli/</link>
		<comments>https://tonybai.com/2025/11/23/leo-messi-and-fanren-hanli/#comments</comments>
		<pubDate>Sun, 23 Nov 2025 12:22:12 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[技术志]]></category>
		<category><![CDATA[ACM]]></category>
		<category><![CDATA[AI]]></category>
		<category><![CDATA[AI原生开发工作流实战]]></category>
		<category><![CDATA[AI大模型]]></category>
		<category><![CDATA[AI时代]]></category>
		<category><![CDATA[Bug]]></category>
		<category><![CDATA[ClaudeCode]]></category>
		<category><![CDATA[DBA]]></category>
		<category><![CDATA[DevOps]]></category>
		<category><![CDATA[Go]]></category>
		<category><![CDATA[Golang]]></category>
		<category><![CDATA[Go专家]]></category>
		<category><![CDATA[Go熟练工]]></category>
		<category><![CDATA[Go语言第一课]]></category>
		<category><![CDATA[Go语言进阶课]]></category>
		<category><![CDATA[SRE]]></category>
		<category><![CDATA[SystemDesign]]></category>
		<category><![CDATA[Title]]></category>
		<category><![CDATA[tradeoff]]></category>
		<category><![CDATA[一击致命]]></category>
		<category><![CDATA[上帝视角]]></category>
		<category><![CDATA[上线]]></category>
		<category><![CDATA[不确定性]]></category>
		<category><![CDATA[中场]]></category>
		<category><![CDATA[五大联赛]]></category>
		<category><![CDATA[代码健壮性]]></category>
		<category><![CDATA[优化流程]]></category>
		<category><![CDATA[伪九号]]></category>
		<category><![CDATA[伪灵根]]></category>
		<category><![CDATA[低负载运行]]></category>
		<category><![CDATA[体能]]></category>
		<category><![CDATA[侏儒症]]></category>
		<category><![CDATA[保命]]></category>
		<category><![CDATA[修仙读者]]></category>
		<category><![CDATA[修炼之道]]></category>
		<category><![CDATA[偷懒]]></category>
		<category><![CDATA[傀儡术]]></category>
		<category><![CDATA[催熟灵药]]></category>
		<category><![CDATA[全局资源]]></category>
		<category><![CDATA[全栈]]></category>
		<category><![CDATA[全栈工程师]]></category>
		<category><![CDATA[全栈工程能力]]></category>
		<category><![CDATA[全能架构师]]></category>
		<category><![CDATA[内卷]]></category>
		<category><![CDATA[冲刺]]></category>
		<category><![CDATA[凡人]]></category>
		<category><![CDATA[凡人修仙传]]></category>
		<category><![CDATA[制符]]></category>
		<category><![CDATA[前腰]]></category>
		<category><![CDATA[前锋]]></category>
		<category><![CDATA[功耗]]></category>
		<category><![CDATA[加速交付]]></category>
		<category><![CDATA[加速学习]]></category>
		<category><![CDATA[加速试错]]></category>
		<category><![CDATA[助攻]]></category>
		<category><![CDATA[勤奋]]></category>
		<category><![CDATA[单一技能]]></category>
		<category><![CDATA[危险]]></category>
		<category><![CDATA[可维护性]]></category>
		<category><![CDATA[名校]]></category>
		<category><![CDATA[后端]]></category>
		<category><![CDATA[哲学]]></category>
		<category><![CDATA[回滚]]></category>
		<category><![CDATA[复杂问题闭环]]></category>
		<category><![CDATA[外挂]]></category>
		<category><![CDATA[大力神杯]]></category>
		<category><![CDATA[大厂背景]]></category>
		<category><![CDATA[天才]]></category>
		<category><![CDATA[妖兽]]></category>
		<category><![CDATA[容灾演练]]></category>
		<category><![CDATA[射手]]></category>
		<category><![CDATA[岗位]]></category>
		<category><![CDATA[工作流指挥家]]></category>
		<category><![CDATA[工作流自动化]]></category>
		<category><![CDATA[工具]]></category>
		<category><![CDATA[工程化修仙]]></category>
		<category><![CDATA[工程化思维]]></category>
		<category><![CDATA[布阵]]></category>
		<category><![CDATA[底层代码]]></category>
		<category><![CDATA[底层开发]]></category>
		<category><![CDATA[开局]]></category>
		<category><![CDATA[弹性扩容]]></category>
		<category><![CDATA[御虫]]></category>
		<category><![CDATA[成长轨迹]]></category>
		<category><![CDATA[扫描全场]]></category>
		<category><![CDATA[技术人]]></category>
		<category><![CDATA[技术壁垒]]></category>
		<category><![CDATA[持续积累]]></category>
		<category><![CDATA[指数级加速]]></category>
		<category><![CDATA[掌天瓶]]></category>
		<category><![CDATA[摸鱼]]></category>
		<category><![CDATA[放大努力]]></category>
		<category><![CDATA[散步]]></category>
		<category><![CDATA[敬畏]]></category>
		<category><![CDATA[无准备之仗]]></category>
		<category><![CDATA[架构]]></category>
		<category><![CDATA[标签化]]></category>
		<category><![CDATA[核心竞争力]]></category>
		<category><![CDATA[梅西]]></category>
		<category><![CDATA[梵圣真魔功]]></category>
		<category><![CDATA[法修]]></category>
		<category><![CDATA[洞府]]></category>
		<category><![CDATA[活着]]></category>
		<category><![CDATA[深夜Debug]]></category>
		<category><![CDATA[满频运行]]></category>
		<category><![CDATA[漏洞]]></category>
		<category><![CDATA[炫技]]></category>
		<category><![CDATA[炼丹师]]></category>
		<category><![CDATA[炼体]]></category>
		<category><![CDATA[炼气]]></category>
		<category><![CDATA[熔断]]></category>
		<category><![CDATA[环境配置]]></category>
		<category><![CDATA[球王]]></category>
		<category><![CDATA[球迷]]></category>
		<category><![CDATA[瓶颈]]></category>
		<category><![CDATA[生存哲学]]></category>
		<category><![CDATA[盲目堆砌代码]]></category>
		<category><![CDATA[短板]]></category>
		<category><![CDATA[硬通货]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[策略]]></category>
		<category><![CDATA[算法天赋]]></category>
		<category><![CDATA[精准打击]]></category>
		<category><![CDATA[系统]]></category>
		<category><![CDATA[系统可用性]]></category>
		<category><![CDATA[系统架构师]]></category>
		<category><![CDATA[系统稳定性]]></category>
		<category><![CDATA[绿茵场]]></category>
		<category><![CDATA[职业生涯]]></category>
		<category><![CDATA[职业跃迁]]></category>
		<category><![CDATA[胆小]]></category>
		<category><![CDATA[胜利]]></category>
		<category><![CDATA[苟]]></category>
		<category><![CDATA[螺丝钉]]></category>
		<category><![CDATA[观察模式]]></category>
		<category><![CDATA[规范驱动开发]]></category>
		<category><![CDATA[解决问题]]></category>
		<category><![CDATA[试探]]></category>
		<category><![CDATA[谨慎]]></category>
		<category><![CDATA[资源动态调度]]></category>
		<category><![CDATA[资源积累]]></category>
		<category><![CDATA[资源管理]]></category>
		<category><![CDATA[资质平庸]]></category>
		<category><![CDATA[边锋]]></category>
		<category><![CDATA[过人操作]]></category>
		<category><![CDATA[运维]]></category>
		<category><![CDATA[进球效率]]></category>
		<category><![CDATA[远遁千里]]></category>
		<category><![CDATA[逆袭]]></category>
		<category><![CDATA[道祖]]></category>
		<category><![CDATA[金丝雀发布]]></category>
		<category><![CDATA[金刚之躯]]></category>
		<category><![CDATA[长板]]></category>
		<category><![CDATA[防御性编程]]></category>
		<category><![CDATA[防线]]></category>
		<category><![CDATA[阿根廷]]></category>
		<category><![CDATA[非科班]]></category>
		<category><![CDATA[韩天尊]]></category>
		<category><![CDATA[韩立]]></category>
		<category><![CDATA[韩跑跑]]></category>
		<category><![CDATA[顶级技术人]]></category>
		<category><![CDATA[高并发系统]]></category>
		<category><![CDATA[高效工具]]></category>

		<guid isPermaLink="false">https://tonybai.com/?p=5428</guid>
		<description><![CDATA[本文永久链接 &#8211; https://tonybai.com/2025/11/23/leo-messi-and-fanren-hanli 大家好，我是Tony Bai。 刚刚过去的这几个月，我终于“出关”了——一口气读完了《凡人修仙传》的人界、灵界、仙界全本。那一刻，看着韩立终成道祖，我心中涌起的激荡，竟与三年前看着阿根廷夺冠、梅西捧起大力神杯时的热泪盈眶，产生了奇妙的共振。 是的，我是一个《凡人》的读者，也是一个追随阿根廷近20年的死忠梅西球迷。 但与此同时，我在现实世界里还有一个更冷静的身份：一名写了多年代码的程序员。 正是这三种看似毫不相干的身份——修仙读者的热血、球迷的狂热、程序员的理性，在我的脑海中发生了一次剧烈的“化学反应”。 当我摘下“修仙”和“足球”的滤镜，用一个资深技术人的视角去审视韩立与梅西的成长轨迹时，一个惊人的结论浮现在脑海：韩立和梅西，本质上是同一种人——他们是各自领域里，将“全栈工程能力”修炼到极致的终极样本。 在AI技术浪潮冲击每一个程序员饭碗的今天，他们的故事，或许藏着我们打破内卷、实现职业跃迁的“底层代码”。 拒绝“标签化”：做解决问题的“全栈”，而非某个岗位 在职场上，我们习惯给自己贴标签：“我是后端”、“我是DBA”、“我是写Go的”。但在韩立和梅西身上，标签失效了。 韩立：修仙界的DevOps先驱 作为读完全本的读者，我深知韩立有多“杂”。你说他是法修？他却凭着梵圣真魔功的金刚之躯，能硬撼顶级妖兽。你说他是炼丹师？他布阵、制符、御虫、傀儡术样样精通。 在韩立的字典里，没有“这不归我管”或者“我是法修，不扛伤害”。为了生存（项目上线/系统稳定）这个终极目标，他打通了从炼气（开发）、炼体（架构）、阵法（运维）到炼丹（资源管理）的全链路。他是一个人活成了一支队伍的DevOps。 梅西：绿茵场上的全能架构师 看过梅西踢球的人都知道，你说他是前锋？他的助攻数冠绝五大联赛。你说他是中场？他的进球效率让所有射手汗颜。 边锋、伪九号、前腰……他几乎踢过前场所有位置。他既能像底层开发一样做最精细的过人操作，又能像系统架构师一样拥有上帝视角，通过一脚传球调度全局资源。 在AI时代，单一技能的“螺丝钉”最容易被替代。真正的“全栈”，不是会写前端和后端那么简单，而是拥有“解决复杂问题闭环”的能力。不要被Title限制，像韩立一样，哪里有瓶颈就去学什么，把自己打造成一个无法被轻易定义的“系统”。 拥抱“凡人”开局：用“工程化思维”逆袭天才 更扎心的是，这两位大神，开局拿的都不是爽文剧本。 伪灵根与侏儒症：非科班的逆袭 韩立是“四伪灵根”，修仙界的“劝退专业”；梅西年少确诊侏儒症，在对抗激烈的足球世界几乎被判“死刑”。 他们就像我们大多数非名校毕业、非ACM金牌选手的普通程序员。没有惊天的算法天赋，没有显赫的大厂背景。 掌天瓶：高效工具的极致利用 韩立的成功，很大程度上归功于“掌天瓶”这个外挂。但他从未依赖外挂“躺平”，而是利用它指数级地加速资源的积累（催熟灵药）。 对于程序员来说，今天的AI大模型以及相关工具就是我们的“掌天瓶”。普通人用来偷懒，高手用来加速试错、加速学习、加速交付。 承认我们是“凡人”，这不可耻。真正的天赋，不完全是智商，更是“工程化思维”——即如何在资源受限（资质平庸）的情况下，通过引入高效工具（AI）、优化流程（勤奋与策略），构建出超越天才的系统稳定性。 “苟”的哲学：防御性编程与SRE意识 如果说全能是他们的外在，那么“苟”，则是他们立于不败之地的内核。 韩立的“稳”：防御性编程大师 “韩跑跑”的名号响彻修仙界。他从不打无准备之仗，战前必先布阵（环境配置/容灾演练），出手前先试探（金丝雀发布），一击不中远遁千里（熔断/回滚）。 这哪里是胆小？这是最高级别的防御性编程（Defensive Programming）。在充满Bug（危险）的修仙界，他把系统的可用性（活着）放在了第一位。 梅西的“散步”：动态资源调度 梅西在场上的“散步”，常被误解。实际上，这是一种顶级的观察模式。他在用极低的功耗（体能）扫描全场，寻找防线（系统）的Bug（漏洞）。一旦发现，瞬间满频运行（冲刺），一击致命。 这是高并发系统中的资源动态调度——平时低负载运行节省资源，关键时刻弹性扩容，精准打击。 在内卷的环境中，学会“苟”很重要。 不是让你摸鱼，而是学会Trade-off（权衡）。不盲目堆砌代码（瞎跑），而是在动手前先做足System Design（观察）；不追求炫技，而是追求代码的健壮性和可维护性（保命）。活得久（职业生涯长），本身就是一种巨大的胜利。 小结 读懂了韩立和梅西，你就读懂了顶级技术人的生存之道。 他们告诉我们：真正的强大，不是拥有一项举世无双的长板，而是通过千锤百炼，让自己没有短板。 在这个充满不确定性的时代，我们也许无法成为梅西那样的天才，但我们可以学习韩立的“工程化修仙”： 利用工具（AI/掌天瓶），放大你的努力。 保持谨慎（防御性编程），敬畏每一次上线。 持续积累（全栈能力），构建自己的技术壁垒。 无论是躲在洞府里默默催熟灵药的韩立，还是在屏幕前深夜Debug的你，技术，永远是我们立足于任何世界的硬通货。 还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你： 告别低效，重塑开发范式 驾驭AI Agent(Claude [...]]]></description>
			<content:encoded><![CDATA[<p><img src="https://tonybai.com/wp-content/uploads/2025/leo-messi-and-fanren-hanli-1.png" alt="" /></p>
<p><a href="https://tonybai.com/2025/11/23/leo-messi-and-fanren-hanli">本文永久链接</a> &#8211; https://tonybai.com/2025/11/23/leo-messi-and-fanren-hanli</p>
<p>大家好，我是Tony Bai。</p>
<p>刚刚过去的这几个月，我终于“出关”了——一口气读完了《凡人修仙传》的人界、灵界、仙界全本。那一刻，看着韩立终成道祖，我心中涌起的激荡，竟与三年前看着阿根廷夺冠、梅西捧起大力神杯时的热泪盈眶，产生了奇妙的共振。</p>
<p>是的，我是一个《凡人》的读者，也是一个追随阿根廷近20年的死忠梅西球迷。</p>
<p>但与此同时，我在现实世界里还有一个更冷静的身份：<strong>一名写了多年代码的程序员。</strong></p>
<p>正是这三种看似毫不相干的身份——<strong>修仙读者的热血、球迷的狂热、程序员的理性</strong>，在我的脑海中发生了一次剧烈的“化学反应”。</p>
<p>当我摘下“修仙”和“足球”的滤镜，用一个资深技术人的视角去审视韩立与梅西的成长轨迹时，一个惊人的结论浮现在脑海：<strong>韩立和梅西，本质上是同一种人——他们是各自领域里，将“全栈工程能力”修炼到极致的终极样本。</strong></p>
<p>在AI技术浪潮冲击每一个程序员饭碗的今天，他们的故事，或许藏着我们打破内卷、实现职业跃迁的“底层代码”。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/paid/ai-app-dev-primer-qr.png" alt="img{512x368}" /></p>
<h2>拒绝“标签化”：做解决问题的“全栈”，而非某个岗位</h2>
<p>在职场上，我们习惯给自己贴标签：“我是后端”、“我是DBA”、“我是写Go的”。但在韩立和梅西身上，标签失效了。</p>
<ul>
<li>
<p><strong>韩立：修仙界的DevOps先驱</strong><br />
作为读完全本的读者，我深知韩立有多“杂”。你说他是法修？他却凭着梵圣真魔功的金刚之躯，能硬撼顶级妖兽。你说他是炼丹师？他布阵、制符、御虫、傀儡术样样精通。<br />
在韩立的字典里，没有“这不归我管”或者“我是法修，不扛伤害”。为了生存（项目上线/系统稳定）这个终极目标，他打通了从炼气（开发）、炼体（架构）、阵法（运维）到炼丹（资源管理）的全链路。<strong>他是一个人活成了一支队伍的DevOps。</strong></p>
</li>
<li>
<p><strong>梅西：绿茵场上的全能架构师</strong><br />
看过梅西踢球的人都知道，你说他是前锋？他的助攻数冠绝五大联赛。你说他是中场？他的进球效率让所有射手汗颜。<br />
边锋、伪九号、前腰……他几乎踢过前场所有位置。他既能像<strong>底层开发</strong>一样做最精细的过人操作，又能像<strong>系统架构师</strong>一样拥有上帝视角，通过一脚传球调度全局资源。</p>
</li>
</ul>
<p>在AI时代，单一技能的“螺丝钉”最容易被替代。真正的“全栈”，不是会写前端和后端那么简单，而是拥有<strong>“解决复杂问题闭环”的能力</strong>。不要被Title限制，像韩立一样，哪里有瓶颈就去学什么，把自己打造成一个<strong>无法被轻易定义的“系统”</strong>。</p>
<h2>拥抱“凡人”开局：用“工程化思维”逆袭天才</h2>
<p>更扎心的是，这两位大神，开局拿的都不是爽文剧本。</p>
<ul>
<li>
<p><strong>伪灵根与侏儒症：非科班的逆袭</strong><br />
韩立是“四伪灵根”，修仙界的“劝退专业”；梅西年少确诊侏儒症，在对抗激烈的足球世界几乎被判“死刑”。<br />
他们就像我们大多数<strong>非名校毕业、非ACM金牌选手</strong>的普通程序员。没有惊天的算法天赋，没有显赫的大厂背景。</p>
</li>
<li>
<p><strong>掌天瓶：高效工具的极致利用</strong><br />
韩立的成功，很大程度上归功于“掌天瓶”这个外挂。但他从未依赖外挂“躺平”，而是利用它<strong>指数级地加速</strong>资源的积累（催熟灵药）。<br />
对于程序员来说，今天的<strong>AI大模型以及相关工具就是我们的“掌天瓶”</strong>。普通人用来偷懒，高手用来<strong>加速试错、加速学习、加速交付</strong>。</p>
</li>
</ul>
<p>承认我们是“凡人”，这不可耻。真正的天赋，不完全是智商，更是<strong>“工程化思维”</strong>——即如何在资源受限（资质平庸）的情况下，通过引入高效工具（AI）、优化流程（勤奋与策略），构建出超越天才的系统稳定性。</p>
<h2>“苟”的哲学：防御性编程与SRE意识</h2>
<p>如果说全能是他们的外在，那么“苟”，则是他们立于不败之地的内核。</p>
<ul>
<li>
<p><strong>韩立的“稳”：防御性编程大师</strong><br />
“韩跑跑”的名号响彻修仙界。他从不打无准备之仗，战前必先布阵（环境配置/容灾演练），出手前先试探（金丝雀发布），一击不中远遁千里（熔断/回滚）。<br />
这哪里是胆小？这是最高级别的<strong>防御性编程（Defensive Programming）</strong>。在充满Bug（危险）的修仙界，他把<strong>系统的可用性（活着）</strong>放在了第一位。</p>
</li>
<li>
<p><strong>梅西的“散步”：动态资源调度</strong><br />
梅西在场上的“散步”，常被误解。实际上，这是一种顶级的<strong>观察模式</strong>。他在用极低的功耗（体能）扫描全场，寻找防线（系统）的Bug（漏洞）。一旦发现，瞬间满频运行（冲刺），一击致命。<br />
这是高并发系统中的<strong>资源动态调度</strong>——平时低负载运行节省资源，关键时刻弹性扩容，精准打击。</p>
</li>
</ul>
<p>在内卷的环境中，学会“苟”很重要。</p>
<p>不是让你摸鱼，而是学会<strong>Trade-off（权衡）</strong>。不盲目堆砌代码（瞎跑），而是在动手前先做足System Design（观察）；不追求炫技，而是追求代码的健壮性和可维护性（保命）。<strong>活得久（职业生涯长），本身就是一种巨大的胜利。</strong></p>
<h2>小结</h2>
<p>读懂了韩立和梅西，你就读懂了顶级技术人的生存之道。</p>
<p>他们告诉我们：<strong>真正的强大，不是拥有一项举世无双的长板，而是通过千锤百炼，让自己没有短板。</strong></p>
<p>在这个充满不确定性的时代，我们也许无法成为梅西那样的天才，但我们可以学习韩立的<strong>“工程化修仙”</strong>：</p>
<ol>
<li><strong>利用工具（AI/掌天瓶）</strong>，放大你的努力。</li>
<li><strong>保持谨慎（防御性编程）</strong>，敬畏每一次上线。</li>
<li><strong>持续积累（全栈能力）</strong>，构建自己的技术壁垒。</li>
</ol>
<p>无论是躲在洞府里默默催熟灵药的韩立，还是在屏幕前深夜Debug的你，<strong>技术，永远是我们立足于任何世界的硬通货。</strong></p>
<hr />
<p>还在为“复制粘贴喂AI”而烦恼？我的新专栏 <strong>《<a href="http://gk.link/a/12EPd">AI原生开发工作流实战</a>》</strong> 将带你：</p>
<ul>
<li>告别低效，重塑开发范式</li>
<li>驾驭AI Agent(Claude Code)，实现工作流自动化</li>
<li>从“AI使用者”进化为规范驱动开发的“工作流指挥家”</li>
</ul>
<p>扫描下方二维码，开启你的AI原生开发之旅。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/ai-native-dev-workflow-qr.png" alt="" /></p>
<hr />
<p>你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？</p>
<ul>
<li>想写出更地道、更健壮的Go代码，却总在细节上踩坑？</li>
<li>渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？</li>
<li>想打造生产级的Go服务，却在工程化实践中屡屡受挫？</li>
</ul>
<p>继《<a href="http://gk.link/a/10AVZ">Go语言第一课</a>》后，我的《<a href="http://gk.link/a/12yGY">Go语言进阶课</a>》终于在极客时间与大家见面了！</p>
<p>我的全新极客时间专栏 《<a href="http://gk.link/a/12yGY">Tony Bai·Go语言进阶课</a>》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。</p>
<p>目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！</p>
<p><img src="https://tonybai.com/wp-content/uploads/course-card/iamtonybai-banner-2.gif" alt="" /></p>
<hr />
<p>商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。</p>
<p><img src="http://image.tonybai.com/img/tonybai/iamtonybai-wechat-qr.png" alt="" /></p>
<p style='text-align:left'>&copy; 2025, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2025/11/23/leo-messi-and-fanren-hanli/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>白天改Bug，晚上刷视频：你以为在放松，其实在消耗你写出好代码的能力</title>
		<link>https://tonybai.com/2025/11/23/short-form-videos-harm-programmers/</link>
		<comments>https://tonybai.com/2025/11/23/short-form-videos-harm-programmers/#comments</comments>
		<pubDate>Sun, 23 Nov 2025 01:31:12 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[技术志]]></category>
		<category><![CDATA[Attention]]></category>
		<category><![CDATA[Bug]]></category>
		<category><![CDATA[DeepWork]]></category>
		<category><![CDATA[FlowState]]></category>
		<category><![CDATA[Go语言]]></category>
		<category><![CDATA[habituation]]></category>
		<category><![CDATA[InhibitoryControl]]></category>
		<category><![CDATA[PsychologicalBulletin]]></category>
		<category><![CDATA[sensitization]]></category>
		<category><![CDATA[ShallowEntertainment]]></category>
		<category><![CDATA[专注力]]></category>
		<category><![CDATA[习惯化]]></category>
		<category><![CDATA[伪学习]]></category>
		<category><![CDATA[冥想]]></category>
		<category><![CDATA[刷视频]]></category>
		<category><![CDATA[复杂问题排查]]></category>
		<category><![CDATA[心流]]></category>
		<category><![CDATA[快娱乐]]></category>
		<category><![CDATA[慢思考]]></category>
		<category><![CDATA[抑制控制能力下降]]></category>
		<category><![CDATA[改Bug]]></category>
		<category><![CDATA[数字健康]]></category>
		<category><![CDATA[数字领地]]></category>
		<category><![CDATA[时间管理]]></category>
		<category><![CDATA[正念]]></category>
		<category><![CDATA[注意力下降]]></category>
		<category><![CDATA[浅层娱乐]]></category>
		<category><![CDATA[消费模式]]></category>
		<category><![CDATA[深度>工作]]></category>
		<category><![CDATA[深度思考能力]]></category>
		<category><![CDATA[深度编程]]></category>
		<category><![CDATA[物理隔离]]></category>
		<category><![CDATA[状态管理]]></category>
		<category><![CDATA[番茄钟]]></category>
		<category><![CDATA[短视频]]></category>
		<category><![CDATA[碎片化]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[算法]]></category>
		<category><![CDATA[系统设计]]></category>
		<category><![CDATA[致敏化]]></category>
		<category><![CDATA[认知能力]]></category>
		<category><![CDATA[逻辑推理能力]]></category>
		<category><![CDATA[长阅读]]></category>

		<guid isPermaLink="false">https://tonybai.com/?p=5424</guid>
		<description><![CDATA[本文永久链接 &#8211; https://tonybai.com/2025/11/23/short-form-videos-harm-programmers 大家好，我是Tony Bai。 我想请你回想一个再熟悉不过的场景： 白天，你在成千上万行代码的丛林里艰难跋涉，与一个隐藏极深的Bug缠斗了数个小时，心力交瘁。晚上回到家，你只想“犒劳”一下疲惫的大脑，于是瘫倒在沙发或舒服的大床上，划开手机，沉浸在短视频那无穷无尽的信息流里。一个接一个的精彩片段，让你暂时忘记了白天的烦恼。 你以为这是一种高效的放松，一次精神上的“回血”。但一个令人不安的自我观察，或许你也有同感：为什么我们越来越难以长时间专注于一段复杂的代码了？为什么刚想深入思考一个架构问题，大脑就不由自主地渴望一次短暂的“分心”？ 这仅仅是意志力下降了吗？还是我们的认知能力，真的在不知不觉中发生了改变？ 最近，一篇发表在顶级期刊《心理学通报》(Psychological Bulletin)上的系统性回顾与元分析论文——《Feeds, Feelings, and Focus: A Systematic Review and Meta-Analysis Examining the Cognitive and Mental Health Correlates of Short-Form Video Use》，为我们揭示了残酷的科学真相。这份综合了71项研究、覆盖近10万参与者的报告，清晰地指出：我们所以为的“放松”，很可能正在系统性地消耗我们写出好代码的核心能力。 那么，这份报告到底说了什么？它又是如何科学地“实锤”短视频对我们大脑的影响的呢？下面，我们就从这份报告的核心发现开始看起。 科学的“实锤”：短视频到底对我们的大脑做了什么？ 这篇论文用详尽的数据告诉我们，短视频的消费模式，并非无害的娱乐。 首先，它与认知能力的下降显著相关。 论文指出，增加的短视频使用与较差的认知能力存在明确的关联（中等效应，r = -.34）。而受损最严重的领域，恰恰是我们程序员最宝贵的两种资产： 注意力 (Attention, r = -.38) 抑制控制 (Inhibitory Control, r = -.41) 这是什么意思？让我们用程序员的语言来“翻译”一下： “注意力”下降，意味着我们持续跟踪复杂逻辑链条、在庞大代码库中保持上下文的能力正在变弱。你可能刚理清一个函数的调用栈，一个念头闪过就忘了自己刚才想到哪了。 “抑制控制能力”下降，意味着我们抵抗内部或外部干扰的能力正在削弱。无论是同事的一条消息，还是脑子里突然冒出的“看看新邮件”的冲动，都变得越来越难以抗拒。 这两种能力，正是我们进行深度编程、系统设计和复杂问题排查的基石！ 论文中提到的“习惯化与致敏化” (habituation and [...]]]></description>
			<content:encoded><![CDATA[<p><img src="https://tonybai.com/wp-content/uploads/2025/short-form-videos-harm-programmers-1.png" alt="" /></p>
<p><a href="https://tonybai.com/2025/11/23/short-form-videos-harm-programmers">本文永久链接</a> &#8211; https://tonybai.com/2025/11/23/short-form-videos-harm-programmers</p>
<p>大家好，我是Tony Bai。</p>
<p>我想请你回想一个再熟悉不过的场景：</p>
<p>白天，你在成千上万行代码的丛林里艰难跋涉，与一个隐藏极深的Bug缠斗了数个小时，心力交瘁。晚上回到家，你只想“犒劳”一下疲惫的大脑，于是瘫倒在沙发或舒服的大床上，划开手机，沉浸在短视频那无穷无尽的信息流里。一个接一个的精彩片段，让你暂时忘记了白天的烦恼。</p>
<p>你以为这是一种高效的放松，一次精神上的“回血”。但一个令人不安的自我观察，或许你也有同感：<strong>为什么我们越来越难以长时间专注于一段复杂的代码了？为什么刚想深入思考一个架构问题，大脑就不由自主地渴望一次短暂的“分心”？</strong></p>
<p>这仅仅是意志力下降了吗？还是我们的认知能力，真的在不知不觉中发生了改变？</p>
<p>最近，一篇发表在顶级期刊《心理学通报》(Psychological Bulletin)上的系统性回顾与元分析论文——<strong>《<a href="https://doi.org/10.1037/bul0000498">Feeds, Feelings, and Focus: A Systematic Review and Meta-Analysis Examining the Cognitive and Mental Health Correlates of Short-Form Video Use</a>》</strong>，为我们揭示了残酷的科学真相。这份综合了71项研究、覆盖近10万参与者的报告，清晰地指出：<strong>我们所以为的“放松”，很可能正在系统性地消耗我们写出好代码的核心能力。</strong></p>
<p>那么，这份报告到底说了什么？它又是如何科学地“实锤”短视频对我们大脑的影响的呢？下面，我们就从这份报告的核心发现开始看起。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/go-testing-journey-qr.png" alt="" /></p>
<h2>科学的“实锤”：短视频到底对我们的大脑做了什么？</h2>
<p>这篇论文用详尽的数据告诉我们，短视频的消费模式，并非无害的娱乐。</p>
<p><strong>首先，它与认知能力的下降显著相关。</strong> 论文指出，增加的短视频使用与<strong>较差的认知能力</strong>存在明确的关联（中等效应，r = -.34）。而受损最严重的领域，恰恰是我们程序员最宝贵的两种资产：</p>
<ol>
<li><strong>注意力 (Attention, r = -.38)</strong></li>
<li><strong>抑制控制 (Inhibitory Control, r = -.41)</strong></li>
</ol>
<p>这是什么意思？让我们用程序员的语言来“翻译”一下：</p>
<ul>
<li><strong>“注意力”下降</strong>，意味着我们持续跟踪复杂逻辑链条、在庞大代码库中保持上下文的能力正在变弱。你可能刚理清一个函数的调用栈，一个念头闪过就忘了自己刚才想到哪了。</li>
<li><strong>“抑制控制能力”下降</strong>，意味着我们抵抗内部或外部干扰的能力正在削弱。无论是同事的一条消息，还是脑子里突然冒出的“看看新邮件”的冲动，都变得越来越难以抗拒。</li>
</ul>
<p><strong>这两种能力，正是我们进行深度编程、系统设计和复杂问题排查的基石！</strong></p>
<p>论文中提到的“<strong>习惯化与致敏化</strong>” (habituation and sensitization) 双重理论，通俗地解释了这一现象：我们的大脑，在反复经受短视频这种“高刺激、快反馈、强情绪”的内容轰炸后，会逐渐<strong>“习惯”</strong>这种模式。当我们再回到编程这种需要“低刺激、慢反馈、纯逻辑”的深度工作时，大脑会表现出极度的不耐烦和渴望“切换”的冲动，因为它已经被短视频<strong>“致敏”</strong>，期待着下一次即时的高强度刺激。</p>
<h2>程序员的“高危”处境：为何我们更易受其害？</h2>
<p>如果说短视频对普通人的影响是“温水煮青蛙”，那对程序员而言，它更像是一场针对核心技能的“精准打击”。</p>
<ul>
<li><strong>工作性质的根本冲突：</strong> 程序员是典型的“<strong>深度工作 (Deep Work)</strong>” 从业者。我们的价值产出，几乎完全依赖于长时间、不间断的专注。而短视频的消费模式，则是“<strong>浅层娱乐 (Shallow Entertainment)</strong>”的极致，两者在认知模式上水火不容。</li>
<li><strong>从“心流”到“心碎”：</strong> 我们梦寐以求的“心流 (Flow State)”状态，其核心就是高度的专注和对干扰的抑制。短视频的算法和产品设计，其目标恰恰是系统性地、持续地打破我们的专注，用一个又一个的新鲜刺激来捕获我们的注意力。<strong>可以说，短视频正在系统性地摧毁我们进入和维持“心流”的能力。</strong></li>
<li><strong>“伪学习”的陷阱：</strong> 很多开发者，包括我自己，有时也会通过短视频学习一些“技术小技巧”。这看似高效，但往往是碎片化的、不成体系的。这种“伪学习”带来的即时满足感，可能会取代系统性、结构化的深度学习，让我们误以为自己“学到了很多”，实则认知能力的基础正在被侵蚀。</li>
</ul>
<h2>夺回专注力：一个程序员的“数字健康”自救指南</h2>
<p>认识到问题的严重性，并非为了制造焦虑，而是为了找到夺回主动权的路径。结合之前分享过的<a href="https://mp.weixin.qq.com/s/VrpRMTAHhSixlqp5mA8FhA">“状态管理”理念</a>，我们可以尝试以下具体的“自救”策略：</p>
<ol>
<li>
<p><strong>拥抱“状态管理”，而非死磕“时间管理”</strong><br />
承认我们的精力是有限的，不同状态适合做不同的事。将你最宝贵的“高能专注态”严格地留给编程、设计等核心任务。</p>
</li>
<li>
<p><strong>划分“数字领地”，建立清晰边界</strong></p>
<ul>
<li><strong>创建“深度工作”场：</strong> 在需要专注的时段，<strong>将手机物理隔离</strong>（放在另一个房间，或开启飞行模式）。使用番茄钟，关闭电脑上所有不必要的通知。为你的大脑创造一个“无短视频”的纯净空间。</li>
<li><strong>设定“浅层娱乐”场：</strong> 允许自己在“低能碎片态”（如午休后、通勤路上）适度消费短视频，但必须设立<strong>明确的时间边界</strong>。例如，定一个15分钟的闹钟，闹钟一响，立即停止。</li>
</ul>
</li>
<li>
<p><strong>主动“反向训练”你的专注力</strong><br />
既然大脑的专注力可以被“去训练”，那它也可以被“再训练”。</p>
<ul>
<li><strong>刻意练习“长阅读”：</strong> 每天或每周，强制自己进行30分钟以上不间断的、无干扰的阅读。内容可以是技术书籍、深度文章，甚至是高质量的源码。这是对抗碎片化最好的“健身”。</li>
<li><strong>尝试正念或冥想：</strong> 每天花5-10分钟，专注于自己的呼吸。这看似简单，却是科学证明能有效提升注意力和抑制控制能力的强大练习。</li>
</ul>
</li>
<li>
<p><strong>改变消费模式，化被动为主动</strong></p>
<ul>
<li><strong>从“被动投喂”到“主动搜索”：</strong> 有意识地减少在“推荐”页的无尽滑动。将短视频平台当作一个“视频搜索引擎”来使用，带着明确的目的去查找你想看的内容。</li>
<li><strong>关注高质量、长内容的创作者：</strong> 关注那些能引发你深度思考的创作者，让算法为你推荐更有价值的内容。</li>
</ul>
</li>
</ol>
<h2>小结：在“快娱乐”的时代，守护“慢思考”的价值</h2>
<p>短视频作为一种媒介，本身并无原罪。它在娱乐、信息传播甚至某些知识普及方面，都有其独特的价值。</p>
<p>但作为程序员，我们必须清醒地认识到，我们赖以生存和发展的核心资产——<strong>专注力、逻辑推理能力和深度思考能力</strong>——是脆弱的，是需要被刻意守护的。</p>
<p>守护它，就是守护我们的职业未来。</p>
<p>希望我们都能在享受科技便利的同时，成为数字工具的“主人”，而非被算法俘虏的“奴隶”。从今天起，让我们重新审视“白天改Bug，晚上刷视频”的生活模式，为我们宝贵的大脑，留出更多“慢思考”的宝贵空间。</p>
<p>资料链接：https://doi.org/10.1037/bul0000498</p>
<hr />
<p>你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？</p>
<ul>
<li>想写出更地道、更健壮的Go代码，却总在细节上踩坑？</li>
<li>渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？</li>
<li>想打造生产级的Go服务，却在工程化实践中屡屡受挫？</li>
</ul>
<p>继《<a href="http://gk.link/a/10AVZ">Go语言第一课</a>》后，我的《<a href="http://gk.link/a/12yGY">Go语言进阶课</a>》终于在极客时间与大家见面了！</p>
<p>我的全新极客时间专栏 《<a href="http://gk.link/a/12yGY">Tony Bai·Go语言进阶课</a>》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。</p>
<p>目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！</p>
<p><img src="https://tonybai.com/wp-content/uploads/course-card/iamtonybai-banner-2.gif" alt="" /></p>
<hr />
<p>还在为“复制粘贴喂AI”而烦恼？我的新专栏 <strong>《<a href="http://gk.link/a/12EPd">AI原生开发工作流实战</a>》</strong> 将带你：</p>
<ul>
<li>告别低效，重塑开发范式</li>
<li>驾驭AI Agent(Claude Code)，实现工作流自动化</li>
<li>从“AI使用者”进化为规范驱动开发的“工作流指挥家”</li>
</ul>
<p>扫描下方二维码，开启你的AI原生开发之旅。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/ai-native-dev-workflow-qr.png" alt="" /></p>
<hr />
<p>商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。</p>
<p><img src="http://image.tonybai.com/img/tonybai/iamtonybai-wechat-qr.png" alt="" /></p>
<p style='text-align:left'>&copy; 2025, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2025/11/23/short-form-videos-harm-programmers/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>从《凡人修仙传》到《三体》：顶尖程序员的“降维打击”与“法则”之力</title>
		<link>https://tonybai.com/2025/10/24/from-fanren-to-three-body-top-programmers-power/</link>
		<comments>https://tonybai.com/2025/10/24/from-fanren-to-three-body-top-programmers-power/#comments</comments>
		<pubDate>Fri, 24 Oct 2025 14:28:56 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[技术志]]></category>
		<category><![CDATA[Algorithm]]></category>
		<category><![CDATA[Biology]]></category>
		<category><![CDATA[BlindFollowing]]></category>
		<category><![CDATA[Bottleneck]]></category>
		<category><![CDATA[BugExclusion]]></category>
		<category><![CDATA[Bug排除]]></category>
		<category><![CDATA[BuildYourOwnWheel]]></category>
		<category><![CDATA[cache]]></category>
		<category><![CDATA[CacheLine]]></category>
		<category><![CDATA[CartesianProduct]]></category>
		<category><![CDATA[CausalLaw]]></category>
		<category><![CDATA[Classics]]></category>
		<category><![CDATA[cloudnative]]></category>
		<category><![CDATA[code]]></category>
		<category><![CDATA[CompilerPrinciple]]></category>
		<category><![CDATA[Complexity]]></category>
		<category><![CDATA[ComputerArchitecture]]></category>
		<category><![CDATA[ComputerNetwork]]></category>
		<category><![CDATA[ComputerScienceFundamentalLaws]]></category>
		<category><![CDATA[ComputingPower]]></category>
		<category><![CDATA[ConstructionLaw]]></category>
		<category><![CDATA[controller]]></category>
		<category><![CDATA[CorePrinciple]]></category>
		<category><![CDATA[CosmicLaws]]></category>
		<category><![CDATA[Creation]]></category>
		<category><![CDATA[CrossDisciplinaryLearning]]></category>
		<category><![CDATA[CultivatingSkills]]></category>
		<category><![CDATA[CultivationPath]]></category>
		<category><![CDATA[CultivationRealm]]></category>
		<category><![CDATA[Curiosity]]></category>
		<category><![CDATA[Cybernetics]]></category>
		<category><![CDATA[DataStructure]]></category>
		<category><![CDATA[DefineFuture]]></category>
		<category><![CDATA[Desire]]></category>
		<category><![CDATA[DifficultToMigrate]]></category>
		<category><![CDATA[DimensionalityReductionAttack]]></category>
		<category><![CDATA[DistributedTheory]]></category>
		<category><![CDATA[Economics]]></category>
		<category><![CDATA[engineer]]></category>
		<category><![CDATA[FanrenXiuxianzhuan]]></category>
		<category><![CDATA[FirstPrinciples]]></category>
		<category><![CDATA[Fog]]></category>
		<category><![CDATA[framework]]></category>
		<category><![CDATA[GCStoppage]]></category>
		<category><![CDATA[GC停顿]]></category>
		<category><![CDATA[GeekTime]]></category>
		<category><![CDATA[GoLanguage]]></category>
		<category><![CDATA[GoLanguageAdvancedCourse]]></category>
		<category><![CDATA[GoLanguagePrimer]]></category>
		<category><![CDATA[GoSkill]]></category>
		<category><![CDATA[Go技能]]></category>
		<category><![CDATA[Go语言]]></category>
		<category><![CDATA[Go语言第一课]]></category>
		<category><![CDATA[Go语言进阶课]]></category>
		<category><![CDATA[Grandmaster]]></category>
		<category><![CDATA[HashTable]]></category>
		<category><![CDATA[HeavenAndEarthLaws]]></category>
		<category><![CDATA[HighAvailability]]></category>
		<category><![CDATA[HighConcurrency]]></category>
		<category><![CDATA[HighLevelLanguage]]></category>
		<category><![CDATA[Implementation]]></category>
		<category><![CDATA[Insight]]></category>
		<category><![CDATA[Intelligence]]></category>
		<category><![CDATA[KnowWhatButNotWhy]]></category>
		<category><![CDATA[latency]]></category>
		<category><![CDATA[LessonsFromOthers]]></category>
		<category><![CDATA[Light]]></category>
		<category><![CDATA[LoadBalancing]]></category>
		<category><![CDATA[LowCeiling]]></category>
		<category><![CDATA[MachineInstruction]]></category>
		<category><![CDATA[MagicSpell]]></category>
		<category><![CDATA[Mathematics]]></category>
		<category><![CDATA[MemoryManagement]]></category>
		<category><![CDATA[Metaphysics]]></category>
		<category><![CDATA[MicroserviceArchitecture]]></category>
		<category><![CDATA[MonolithicApplication]]></category>
		<category><![CDATA[NestedLoop]]></category>
		<category><![CDATA[OperationsCost]]></category>
		<category><![CDATA[Origin]]></category>
		<category><![CDATA[PerformanceBottleneck]]></category>
		<category><![CDATA[PerformanceOptimization]]></category>
		<category><![CDATA[PersonalVerification]]></category>
		<category><![CDATA[Physics]]></category>
		<category><![CDATA[pipeline]]></category>
		<category><![CDATA[PointerJump]]></category>
		<category><![CDATA[PowerOfLaw]]></category>
		<category><![CDATA[Practice]]></category>
		<category><![CDATA[Principle]]></category>
		<category><![CDATA[PrincipleUnderstander]]></category>
		<category><![CDATA[ProductionEnvironment]]></category>
		<category><![CDATA[Programmer]]></category>
		<category><![CDATA[RaceCondition]]></category>
		<category><![CDATA[ReadSourceCode]]></category>
		<category><![CDATA[RebuildFoundation]]></category>
		<category><![CDATA[RedundantBackup]]></category>
		<category><![CDATA[RefiningMaster]]></category>
		<category><![CDATA[RestartMethod]]></category>
		<category><![CDATA[SanTi]]></category>
		<category><![CDATA[Sect]]></category>
		<category><![CDATA[ServerUpgrade]]></category>
		<category><![CDATA[SettleDownAndLive]]></category>
		<category><![CDATA[SharedVariable]]></category>
		<category><![CDATA[Skill]]></category>
		<category><![CDATA[SkillCultivator]]></category>
		<category><![CDATA[SkilledWorker]]></category>
		<category><![CDATA[SpaceLaw]]></category>
		<category><![CDATA[SpecificMethods]]></category>
		<category><![CDATA[SpiralAscent]]></category>
		<category><![CDATA[StabilizeFoundation]]></category>
		<category><![CDATA[SupremeLaw]]></category>
		<category><![CDATA[SystemDesign]]></category>
		<category><![CDATA[TechnologyCycle]]></category>
		<category><![CDATA[TechnologySelection]]></category>
		<category><![CDATA[ThreadSafety]]></category>
		<category><![CDATA[TimeLaw]]></category>
		<category><![CDATA[tool]]></category>
		<category><![CDATA[TopProgrammer]]></category>
		<category><![CDATA[TrialAndError]]></category>
		<category><![CDATA[TwoDimensionalFoil]]></category>
		<category><![CDATA[UnderlyingPrinciples]]></category>
		<category><![CDATA[UnderstandingPrinciples]]></category>
		<category><![CDATA[UnderstandMagicOrigin]]></category>
		<category><![CDATA[UniversalTruthsAreConnected]]></category>
		<category><![CDATA[Unreliability]]></category>
		<category><![CDATA[UnstableFoundation]]></category>
		<category><![CDATA[三体]]></category>
		<category><![CDATA[不可靠性]]></category>
		<category><![CDATA[二向箔]]></category>
		<category><![CDATA[云原生]]></category>
		<category><![CDATA[亲身证道]]></category>
		<category><![CDATA[他山之石]]></category>
		<category><![CDATA[代码]]></category>
		<category><![CDATA[修仙境界]]></category>
		<category><![CDATA[修术]]></category>
		<category><![CDATA[修术者]]></category>
		<category><![CDATA[修行路线]]></category>
		<category><![CDATA[光芒]]></category>
		<category><![CDATA[共享变量]]></category>
		<category><![CDATA[具体功法]]></category>
		<category><![CDATA[内存管理]]></category>
		<category><![CDATA[冗余备份]]></category>
		<category><![CDATA[凡人修仙传]]></category>
		<category><![CDATA[分布式理论]]></category>
		<category><![CDATA[创造]]></category>
		<category><![CDATA[动手造轮子]]></category>
		<category><![CDATA[升级服务器]]></category>
		<category><![CDATA[单体应用]]></category>
		<category><![CDATA[哈希表]]></category>
		<category><![CDATA[因果法则]]></category>
		<category><![CDATA[复杂度]]></category>
		<category><![CDATA[大道相通]]></category>
		<category><![CDATA[天地法则]]></category>
		<category><![CDATA[天花板低]]></category>
		<category><![CDATA[好奇]]></category>
		<category><![CDATA[宇宙规律]]></category>
		<category><![CDATA[安身立命]]></category>
		<category><![CDATA[宗师]]></category>
		<category><![CDATA[宗门]]></category>
		<category><![CDATA[定义未来]]></category>
		<category><![CDATA[实现]]></category>
		<category><![CDATA[实践]]></category>
		<category><![CDATA[嵌套循环]]></category>
		<category><![CDATA[工具]]></category>
		<category><![CDATA[工程师]]></category>
		<category><![CDATA[底层原理]]></category>
		<category><![CDATA[延迟]]></category>
		<category><![CDATA[微服务架构]]></category>
		<category><![CDATA[心法总纲]]></category>
		<category><![CDATA[性能优化]]></category>
		<category><![CDATA[性能瓶颈]]></category>
		<category><![CDATA[悟道]]></category>
		<category><![CDATA[悟道者]]></category>
		<category><![CDATA[技术周期]]></category>
		<category><![CDATA[技术选型]]></category>
		<category><![CDATA[指针跳转]]></category>
		<category><![CDATA[掌控者]]></category>
		<category><![CDATA[控制论]]></category>
		<category><![CDATA[数学]]></category>
		<category><![CDATA[数据结构]]></category>
		<category><![CDATA[时间法则]]></category>
		<category><![CDATA[智力]]></category>
		<category><![CDATA[本源]]></category>
		<category><![CDATA[术]]></category>
		<category><![CDATA[机器指令]]></category>
		<category><![CDATA[极客时间]]></category>
		<category><![CDATA[构造法则]]></category>
		<category><![CDATA[根基不稳]]></category>
		<category><![CDATA[框架]]></category>
		<category><![CDATA[法则之力]]></category>
		<category><![CDATA[法术]]></category>
		<category><![CDATA[洞察力]]></category>
		<category><![CDATA[洞悉法术本源]]></category>
		<category><![CDATA[流水线]]></category>
		<category><![CDATA[渴望]]></category>
		<category><![CDATA[炼器大师]]></category>
		<category><![CDATA[熟练工]]></category>
		<category><![CDATA[物理学]]></category>
		<category><![CDATA[玄学]]></category>
		<category><![CDATA[瓶颈]]></category>
		<category><![CDATA[生产环境]]></category>
		<category><![CDATA[生物学]]></category>
		<category><![CDATA[盲目跟风]]></category>
		<category><![CDATA[知其然不知其所以然]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[稳固道基]]></category>
		<category><![CDATA[空间法则]]></category>
		<category><![CDATA[竞态条件]]></category>
		<category><![CDATA[笛卡尔积]]></category>
		<category><![CDATA[第一性原理]]></category>
		<category><![CDATA[算力]]></category>
		<category><![CDATA[算法]]></category>
		<category><![CDATA[系统设计]]></category>
		<category><![CDATA[线程安全]]></category>
		<category><![CDATA[经典]]></category>
		<category><![CDATA[经济学]]></category>
		<category><![CDATA[缓存]]></category>
		<category><![CDATA[缓存行]]></category>
		<category><![CDATA[编译原理]]></category>
		<category><![CDATA[至尊法则]]></category>
		<category><![CDATA[螺旋上升]]></category>
		<category><![CDATA[计算机体系结构]]></category>
		<category><![CDATA[计算机科学基础法则]]></category>
		<category><![CDATA[计算机网络]]></category>
		<category><![CDATA[试错法]]></category>
		<category><![CDATA[负载均衡]]></category>
		<category><![CDATA[跨界学习]]></category>
		<category><![CDATA[运维成本]]></category>
		<category><![CDATA[迷雾]]></category>
		<category><![CDATA[道]]></category>
		<category><![CDATA[重修基础]]></category>
		<category><![CDATA[重启大法]]></category>
		<category><![CDATA[阅读源码]]></category>
		<category><![CDATA[降维打击]]></category>
		<category><![CDATA[难以迁移]]></category>
		<category><![CDATA[顶尖程序员]]></category>
		<category><![CDATA[高可用]]></category>
		<category><![CDATA[高并发]]></category>
		<category><![CDATA[高级语言]]></category>

		<guid isPermaLink="false">https://tonybai.com/?p=5304</guid>
		<description><![CDATA[本文永久链接 &#8211; https://tonybai.com/2025/10/24/from-fanren-to-three-body-top-programmers-power 大家好，我是Tony Bai。 在上篇文章中，我们论道了程序员的修仙境界。但一个更深层的问题随之而来：决定一个修士（程序员）最终高度的，究竟是什么？是掌握了更多华丽的“法术”（框架/工具），还是洞悉了其背后的“天地法则”（底层原理）？ 在《凡人修仙传》的后期，韩天尊与道祖们的斗法，早已不是简单的法宝对轰，而是对时间、空间等“至尊法则”的掌控。谁对法则的理解更深，谁就能言出法随，改天换地。 这正如《三体》中的高等文明，它们不屑于用飞船、激光炮甚至核武器，而是直接动用宇宙规律本身作为武器——一张“二向箔”，便能将整个太阳系从三维降至二维，完成终极的“降维打击”。 回到我们的世界，程序员的“降维打击”又是什么？答案是：当大多数人还在钻研“术”（框架、API）的层面时，顶尖高手早已在运用“道”（计算机科学基础法则）的力量，直击问题的本源。 这“术”与“道”的差别，便在程序员的成长之路上，自然而然地分化出了两条截然不同的修行路线。一条是精研万千“法术”，追求招式的极致与华丽；另一条则是追本溯源，探寻那不变的“天地大道”。 接下来，就让我们一同探寻这两条路上的风景，看看它们各自通往何方。 “修术”与“悟道”：程序员的两条修行之路 程序员的成长，往往会分化为两条截然不同的修行路线。 第一条路：“修术”的修士 —— 框架与API的熟练工 在修仙界，他们是勤学苦练各种“法术”的低阶修士，对“火球术”、“御风术”的咒语手诀了如指掌，能在战斗中熟练释放。但他们不知火球为何燃烧，当遇到克制其法术的敌人时，便会束手无策。 在程序员界，他们是这样的： 特征： 精通 Gin/Spring/Vue/React 全家桶，对各种注解、Hook、API 信手拈来，能用极高的效率搭建业务应用。他们是项目中的“突击手”，是团队快速交付的保障。 瓶颈： 知其然，不知其所以然： 遇到深层次问题，如 JVM 内存溢出、GC 频繁、数据库死锁时，他们的“法术”失灵了。因为这些问题触及了“术”背后的“法则”。 根基不稳，难以迁移： 当技术浪潮更迭，新的框架（新的“法术体系”）出现时，他们需要从头学起，过去的经验很大一部分会作废。 天花板低： 他们的工作是“实现”，而非“创造”。他们能用积木搭出华丽的城堡，但无法自己设计和制造积木。 第二条路：“悟道”的宗师 —— 法则与本源的掌控者 在修仙界，他们是韩立后期的境界，乃至道祖。他们不再拘泥于具体“法术”，想用火，便直接调动天地间的火之法则。他们甚至可以“神通自创”，因为他们理解了力量的本源。 在程序员界，他们掌握了那些不变的“法则”： 时间法则 -> 算法与复杂度： 他们深知，程序的性能瓶颈往往不在于硬件快慢，而在于算法的优劣。一个从 O(n²) 到 O(n log n) 的算法优化，胜过十倍的服务器升级。这是对程序“时间流速”的直接掌控。 空间法则 -> 数据结构与内存管理： 他们能清晰地看到数据在内存中的排布，理解缓存行（Cache Line）、指针跳转如何影响性能。他们选择数据结构，如同仙人布置洞府，每一寸空间都物尽其用。这是对计算机“物理空间”的精妙运用。 构造法则 -> [...]]]></description>
			<content:encoded><![CDATA[<p><img src="https://tonybai.com/wp-content/uploads/2025/from-fanren-to-three-body-top-programmers-power-1.png" alt="" /></p>
<p><a href="https://tonybai.com/2025/10/24/from-fanren-to-three-body-top-programmers-power">本文永久链接</a> &#8211; https://tonybai.com/2025/10/24/from-fanren-to-three-body-top-programmers-power</p>
<p>大家好，我是Tony Bai。</p>
<p>在上篇文章中，我们论道了<a href="https://tonybai.com/2025/09/08/fanren-xiuxian-programmer-levels">程序员的修仙境界</a>。但一个更深层的问题随之而来：决定一个修士（程序员）最终高度的，究竟是什么？是掌握了更多华丽的“法术”（框架/工具），还是洞悉了其背后的“天地法则”（底层原理）？</p>
<p>在《凡人修仙传》的后期，韩天尊与道祖们的斗法，早已不是简单的法宝对轰，而是对时间、空间等“至尊法则”的掌控。谁对法则的理解更深，谁就能言出法随，改天换地。</p>
<p>这正如《三体》中的高等文明，它们不屑于用飞船、激光炮甚至核武器，而是直接动用宇宙规律本身作为武器——一张“二向箔”，便能将整个太阳系从三维降至二维，完成终极的“降维打击”。</p>
<p>回到我们的世界，程序员的“降维打击”又是什么？答案是：<strong>当大多数人还在钻研“术”（框架、API）的层面时，顶尖高手早已在运用“道”（计算机科学基础法则）的力量，直击问题的本源。</strong></p>
<p>这“术”与“道”的差别，便在程序员的成长之路上，自然而然地分化出了两条截然不同的修行路线。一条是精研万千“法术”，追求招式的极致与华丽；另一条则是追本溯源，探寻那不变的“天地大道”。</p>
<p>接下来，就让我们一同探寻这两条路上的风景，看看它们各自通往何方。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/paid/go-network-programming-complete-guide-pr.png" alt="" /></p>
<h2>“修术”与“悟道”：程序员的两条修行之路</h2>
<p>程序员的成长，往往会分化为两条截然不同的修行路线。</p>
<h3>第一条路：“修术”的修士 —— 框架与API的熟练工</h3>
<p><img src="https://tonybai.com/wp-content/uploads/2025/from-fanren-to-three-body-top-programmers-power-2.png" alt="" /></p>
<p>在修仙界，他们是勤学苦练各种“法术”的低阶修士，对“火球术”、“御风术”的咒语手诀了如指掌，能在战斗中熟练释放。但他们不知火球为何燃烧，当遇到克制其法术的敌人时，便会束手无策。</p>
<p>在程序员界，他们是这样的：</p>
<ul>
<li><strong>特征：</strong> 精通 Gin/Spring/Vue/React 全家桶，对各种注解、Hook、API 信手拈来，能用极高的效率搭建业务应用。他们是项目中的“突击手”，是团队快速交付的保障。</li>
<li><strong>瓶颈：</strong>
<ol>
<li><strong>知其然，不知其所以然：</strong> 遇到深层次问题，如 JVM 内存溢出、GC 频繁、数据库死锁时，他们的“法术”失灵了。因为这些问题触及了“术”背后的“法则”。</li>
<li><strong>根基不稳，难以迁移：</strong> 当技术浪潮更迭，新的框架（新的“法术体系”）出现时，他们需要从头学起，过去的经验很大一部分会作废。</li>
<li><strong>天花板低：</strong> 他们的工作是“实现”，而非“创造”。他们能用积木搭出华丽的城堡，但无法自己设计和制造积木。</li>
</ol>
</li>
</ul>
<h3>第二条路：“悟道”的宗师 —— 法则与本源的掌控者</h3>
<p><img src="https://tonybai.com/wp-content/uploads/2025/from-fanren-to-three-body-top-programmers-power-3.png" alt="" /></p>
<p>在修仙界，他们是韩立后期的境界，乃至道祖。他们不再拘泥于具体“法术”，想用火，便直接调动天地间的火之法则。他们甚至可以“神通自创”，因为他们理解了力量的本源。</p>
<p>在程序员界，他们掌握了那些不变的“法则”：</p>
<ul>
<li>
<p><strong>时间法则 -> 算法与复杂度：</strong> 他们深知，程序的性能瓶颈往往不在于硬件快慢，而在于算法的优劣。一个从 O(n²) 到 O(n log n) 的算法优化，胜过十倍的服务器升级。这是对程序“时间流速”的直接掌控。</p>
</li>
<li>
<p><strong>空间法则 -> 数据结构与内存管理：</strong> 他们能清晰地看到数据在内存中的排布，理解缓存行（Cache Line）、指针跳转如何影响性能。他们选择数据结构，如同仙人布置洞府，每一寸空间都物尽其用。这是对计算机“物理空间”的精妙运用。</p>
</li>
<li>
<p><strong>构造法则 -> 计算机体系结构与编译原理：</strong> 他们明白每一行高级语言，最终是如何被翻译成机器指令，在 CPU 的流水线上执行的。这种知识让他们能写出“亲和硬件”的代码，榨干硬件的每一分潜力。</p>
</li>
<li>
<p><strong>因果法则 -> 计算机网络与分布式理论：</strong> 他们对网络的延迟、不可靠性有着深刻的敬畏。在设计系统时，他们遵循 CAP、BASE 等“因果铁律”，而不是盲目追求不可能的“既要又要”。</p>
</li>
</ul>
<h2>法则之力：程序员的“降维打击”</h2>
<p>当“修术者”遇到瓶颈时，“悟道者”便会展现出碾压性的“降维打击”。</p>
<h3>场景一：性能优化之战</h3>
<ul>
<li><strong>修术者：</strong> “系统慢了！赶紧加缓存！上 Redis！不行就升级服务器，从4核8G干到16核32G！”</li>
<li><strong>悟道者：</strong> “我先用 profiler 分析一下。哦，原来是这里有一个嵌套循环导致了笛卡尔积。把数据结构换成哈希表，一次遍历解决。”</li>
<li><strong>结果：</strong> <strong>这是智力对算力的降维打击。</strong></li>
</ul>
<h3>场景二：诡异 Bug 排除</h3>
<ul>
<li><strong>修术者：</strong> “这个 Bug 时有时无，只在生产环境高并发下出现！肯定是框架的 Bug！玄学，先重启大法试试。”</li>
<li><strong>悟道者：</strong> “听起来像是线程安全问题。我检查一下这里的共享变量，果然没有加锁，导致了竞态条件（Race Condition）。或者，这可能是 GC 停顿引起的。”</li>
<li><strong>结果：</strong> <strong>这是洞察力对试错法的降维打击。</strong></li>
</ul>
<h3>场景三：技术选型决策</h3>
<ul>
<li><strong>修术者：</strong> “我们要做新项目！必须用现在最火的微服务架构！上 Service Mesh，上云原生全家桶！”</li>
<li><strong>悟道者：</strong> “我们的业务初期流量不大，团队规模也小，强上微服务会带来巨大的运维成本。一个设计良好的单体应用，更能满足当前阶段的需求。要敬畏分布式系统的因果法则。”</li>
<li><strong>结果：</strong> <strong>这是第一性原理对盲目跟风的降维打击。</strong></li>
</ul>
<h2>如何“悟道”：从“术”到“道”的修行之路</h2>
<p>“悟道”之路，注定是艰难而孤独的，但也是回报最丰厚的。</p>
<ol>
<li>
<p><strong>心法总纲：保持好奇，永远追问“为什么？”</strong><br />
当你在用一个注解时，问自己：它背后是通过什么机制实现的？不要满足于“它能工作”，要去探寻“它为何能这样工作”。</p>
</li>
<li>
<p><strong>具体功法：</strong></p>
<ul>
<li><strong>重修基础，稳固道基：</strong> 静下心来，去啃那些“无用”的经典。《深入理解计算机系统》(CSAPP)、《算法导论》、《TCP/IP详解》……这些是刻在石头上的“天地法则”，是所有“法术”的根基。</li>
<li><strong>阅读源码，洞悉法术本源：</strong> 去读 Gin、Spring、Netty、Redis 的源码。看懂它们，就像是亲眼目睹了一位炼器大师如何将基础材料炼制成一件惊世法宝。</li>
<li><strong>动手造轮子，亲身证道：</strong> 尝试自己写一个简单的 Web 服务器、一个 RPC 框架。在这个过程中，你会被迫直面那些“法则”，并想办法去驾驭它们。</li>
<li><strong>跨界学习，他山之石：</strong> 学习数学、物理学、控制论中的思想。你会发现，负载均衡的思想在经济学中有体现，高可用的设计哲学与生物学的冗余备份异曲同工。大道相通。</li>
</ul>
</li>
</ol>
<h2>小结</h2>
<p>从“修术”到“悟道”，不是一条非此即彼的道路，而是一个螺旋上升的过程。我们始于“术”，在实践中不断碰壁，从而激发对“道”的渴望；悟“道”之后，我们能更好地驾驭和创造新的“术”。</p>
<p>在程序员的修行世界里，“修术”可以让你成为一名可靠的工程师，在宗门（公司）里安身立命。但唯有“悟道”，才能让你拥有穿越技术周期、直击问题本质的力量，成为真正定义未来的宗师，施展出属于你的“降维打击”。</p>
<p>愿你我都能在代码的修行中，拨开“术”的迷雾，窥见“道”的光芒。</p>
<hr />
<p>你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？</p>
<ul>
<li>想写出更地道、更健壮的Go代码，却总在细节上踩坑？</li>
<li>渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？</li>
<li>想打造生产级的Go服务，却在工程化实践中屡屡受挫？</li>
</ul>
<p>继《<a href="http://gk.link/a/10AVZ">Go语言第一课</a>》后，我的《<a href="http://gk.link/a/12yGY">Go语言进阶课</a>》终于在极客时间与大家见面了！</p>
<p>我的全新极客时间专栏 《<a href="http://gk.link/a/12yGY">Tony Bai·Go语言进阶课</a>》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。</p>
<p>目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！</p>
<p><img src="https://tonybai.com/wp-content/uploads/course-card/iamtonybai-banner-2.gif" alt="" /></p>
<hr />
<p><strong>想系统学习Go，构建扎实的知识体系？</strong></p>
<p>我的新书《<a href="https://book.douban.com/subject/37499496/">Go语言第一课</a>》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！</p>
<p><img src="https://tonybai.com/wp-content/uploads/2025/go-primer-published-4.png" alt="" /></p>
<hr />
<p>商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。</p>
<p><img src="http://image.tonybai.com/img/tonybai/iamtonybai-wechat-qr.png" alt="" /></p>
<p style='text-align:left'>&copy; 2025, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2025/10/24/from-fanren-to-three-body-top-programmers-power/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
