<?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, 09 May 2026 10:01:53 +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>“AI 让每个人都成了开发者”，就像“相机让每个人都成了摄影师”</title>
		<link>https://tonybai.com/2026/05/05/ai-makes-everyone-a-developer-like-cameras-for-photographers/</link>
		<comments>https://tonybai.com/2026/05/05/ai-makes-everyone-a-developer-like-cameras-for-photographers/#comments</comments>
		<pubDate>Mon, 04 May 2026 23:43:28 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[技术志]]></category>
		<category><![CDATA[Agent]]></category>
		<category><![CDATA[AICollaboration]]></category>
		<category><![CDATA[AIProgramming]]></category>
		<category><![CDATA[AI协作]]></category>
		<category><![CDATA[AI编程]]></category>
		<category><![CDATA[ArchitectureDesign]]></category>
		<category><![CDATA[ClaudeCode]]></category>
		<category><![CDATA[CodeQuality]]></category>
		<category><![CDATA[Codereview]]></category>
		<category><![CDATA[CognitiveOffloading]]></category>
		<category><![CDATA[Cursor]]></category>
		<category><![CDATA[ProductionRelations]]></category>
		<category><![CDATA[Productivity]]></category>
		<category><![CDATA[Programmers]]></category>
		<category><![CDATA[SoftwareEngineering]]></category>
		<category><![CDATA[SystemsThinking]]></category>
		<category><![CDATA[TechDemocratization]]></category>
		<category><![CDATA[TechnicalDebt]]></category>
		<category><![CDATA[VibeCoding]]></category>
		<category><![CDATA[代码审查]]></category>
		<category><![CDATA[代码质量]]></category>
		<category><![CDATA[技术债务]]></category>
		<category><![CDATA[技术平权]]></category>
		<category><![CDATA[智能体]]></category>
		<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=6266</guid>
		<description><![CDATA[本文永久链接 &#8211; https://tonybai.com/2026/05/05/ai-makes-everyone-a-developer-like-cameras-for-photographers 大家好，我是Tony Bai。 最近，在技术圈里流传着一个“非主流观点（Unpopular Opinion）”： “‘AI 让每个人都成了开发者’，这句话是真的。就像当年‘相机的发明，让每个人都成了摄影师’一样。” 这句充满“内涵”的类比，在 Reddit、X 等社区引来了开发者的热议。它精准地戳中了所有专业开发者心中最深的隐忧：当 AI 将编程的门槛夷为平地，我们这些苦练了十几年“内功”的“老师傅”，还有存在的价值吗？ 就在前几天，r/webdev 论坛上，一篇名为《我刚围观了一个非开发者用 AI Vibe-Coding 的全过程……兄弟们，我们稳了》的帖子，用一个极其生动、甚至有些滑稽的真实案例，为这个“灵魂拷问”给出了一个参考答案。 今天，我们就来复盘这场关于“技术平权”与“专业主义”的大讨论，看看在 AI 掀起的这场“全民编程”狂欢之下，到底藏着怎样的泡沫、陷阱与机遇。 一个非开发者的“玄学 Debug”之旅 故事的开端，来自一位名叫 eowenith 的开发者。他讲述了自己围观一位非技术背景的朋友，如何使用 Claude Code 构建一个应用的“奇葩”经历。 这位朋友对编程一窍不通，她的操作方式，被社区戏称为 “Vibe-Coding（氛围编码）”： 脑子里有一个模糊的想法。 用大白话告诉 AI：“给我做一个XX网站。” AI 生成了一堆代码，她看不懂，直接运行。 网站崩溃了。 她把整个屏幕的截图发给 AI，然后配上一句：“这看起来不对劲。” AI 开始猜测问题，生成新的代码，然后再次崩溃…… eowenith 在帖子中写道： “我眼睁睁地看着 Anthropic 的账单邮件一封封地发过来，她花了几个小时和几十次 Prompt，最终搞出来的东西，我可能用一两个 Prompt 就能做得更好。” “最后，她甚至还嘲笑我，说我的 Claude Code 总结页面上的‘已用点数’和‘消息数’太少了，像个业余爱好者。” 这个案例，让评论区彻底炸了锅。 [...]]]></description>
			<content:encoded><![CDATA[<p><img src="https://tonybai.com/wp-content/uploads/2026/ai-makes-everyone-a-developer-like-cameras-for-photographers-1.png" alt="" /></p>
<p><a href="https://tonybai.com/2026/05/05/ai-makes-everyone-a-developer-like-cameras-for-photographers">本文永久链接</a> &#8211; https://tonybai.com/2026/05/05/ai-makes-everyone-a-developer-like-cameras-for-photographers</p>
<p>大家好，我是Tony Bai。</p>
<p>最近，在技术圈里流传着一个“非主流观点（Unpopular Opinion）”：</p>
<blockquote>
<p><strong>“‘AI 让每个人都成了开发者’，这句话是真的。就像当年‘相机的发明，让每个人都成了摄影师’一样。”</strong></p>
</blockquote>
<p><img src="../BlogImages/2026/ai-makes-everyone-a-developer-like-cameras-for-photographers-2.png" alt="" /></p>
<p>这句充满“内涵”的类比，在 Reddit、X 等社区引来了开发者的热议。它精准地戳中了所有专业开发者心中最深的隐忧：<strong>当 AI 将编程的门槛夷为平地，我们这些苦练了十几年“内功”的“老师傅”，还有存在的价值吗？</strong></p>
<p>就在前几天，r/webdev 论坛上，一篇名为《<a href="https://www.reddit.com/r/webdev/comments/1stjfo4/i_just_watched_a_nondev_vibecode_something_were">我刚围观了一个非开发者用 AI Vibe-Coding 的全过程……兄弟们，我们稳了</a>》的帖子，用一个极其生动、甚至有些滑稽的真实案例，为这个“灵魂拷问”给出了一个参考答案。</p>
<p>今天，我们就来复盘这场关于“技术平权”与“专业主义”的大讨论，看看在 AI 掀起的这场“全民编程”狂欢之下，到底藏着怎样的泡沫、陷阱与机遇。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2026/agentic-software-engineering-qr.png" alt="" /></p>
<h2>一个非开发者的“玄学 Debug”之旅</h2>
<p>故事的开端，来自一位名叫 eowenith 的开发者。他讲述了自己围观一位非技术背景的朋友，如何使用 Claude Code 构建一个应用的“奇葩”经历。</p>
<p>这位朋友对编程一窍不通，她的操作方式，被社区戏称为 <strong>“Vibe-Coding（氛围编码）”</strong>：</p>
<ol>
<li>脑子里有一个模糊的想法。</li>
<li>用大白话告诉 AI：“给我做一个XX网站。”</li>
<li>AI 生成了一堆代码，她看不懂，直接运行。</li>
<li>网站崩溃了。</li>
<li>她把<strong>整个屏幕的截图</strong>发给 AI，然后配上一句：“这看起来不对劲。”</li>
<li>AI 开始猜测问题，生成新的代码，然后再次崩溃……</li>
</ol>
<p>eowenith 在帖子中写道：</p>
<blockquote>
<p>“我眼睁睁地看着 Anthropic 的账单邮件一封封地发过来，她花了几个小时和几十次 Prompt，最终搞出来的东西，我可能用一两个 Prompt 就能做得更好。”</p>
<p>“最后，她甚至还嘲笑我，说我的 Claude Code 总结页面上的‘已用点数’和‘消息数’太少了，像个业余爱好者。”</p>
</blockquote>
<p>这个案例，让评论区彻底炸了锅。</p>
<p>一位开发者一针见血地指出：</p>
<blockquote>
<p>“那个‘嘲笑你点数用得少’的部分，真的把我逗笑了。<strong>低效地烧钱，居然成了一种炫耀资本。</strong>”</p>
</blockquote>
<p>另一位开发者则用更专业的视角剖析了这种“Vibe-Coding”的致命缺陷：</p>
<blockquote>
<p>“一个没有底层知识的人，只会不停地 Prompt。AI 为了解决表层问题，会不断地创造‘权宜之计’，绕过那些真正核心的架构缺陷。<strong>最终，这些‘权宜之计’会互相叠加，让系统变得比一开始还要烂。</strong>”</p>
</blockquote>
<p>这种靠“直觉”和“感觉”驱动的开发模式，正在批量制造着新时代的“高科技屎山”。</p>
<h2>“Token 猪”与“认知卸载”</h2>
<p>在这场大讨论中，几个极其精辟的新概念应运而生，完美地概括了 AI 时代的行业乱象。</p>
<p><strong>概念一：Token 猪（Token Pig）</strong></p>
<p>这个词用来形容那些<strong>低效、懒惰、疯狂消耗 Token 的 AI 使用者</strong>。</p>
<p>他们把 AI 当作一个无限的“许愿池”，拒绝进行任何有价值的思考，把最简单的任务，也用最昂贵的方式外包给大模型。</p>
<p><strong>概念二：认知卸载（Cognitive Offloading）</strong></p>
<p>一位开发者表达了一种更深层次的担忧：</p>
<blockquote>
<p>“AI 确实很有用，但我对‘认知卸载’的长期影响感到担忧。我努力确保自己能理解 AI 做的每一件事，并花时间去搞懂那些看起来不太对劲的地方。”</p>
</blockquote>
<p>当我们习惯于让 AI 为我们思考，我们的大脑就失去了构建深度知识模型（Mental Models）的机会。我们从“司机”变成了“乘客”。长此以往，我们不仅会失去对代码的掌控力，更会失去独立解决复杂问题的能力。</p>
<p>就像评论区里那个极其扎心的比喻：</p>
<blockquote>
<p><strong>“当手机出现后，一种新的脑损伤出现了——我们记不住电话号码了。”</strong></p>
</blockquote>
<h2>当工具抹平了门槛</h2>
<p>回到最初的那个“摄影师”比喻。</p>
<p>一位用户分享了她丈夫的真实经历：</p>
<blockquote>
<p>“我的丈夫曾经是一名职业摄影师。当数码相机的浪潮到来，‘让每个人都成了摄影师’时，他被迫离开了这个行业。因为客户们开始觉得，他们不应该再为一个‘按一下快门’的动作，支付高昂的费用。”</p>
</blockquote>
<p>这几乎是所有专业开发者内心最深的恐惧。</p>
<p>但另一位用户也提出了一个类似的观点：</p>
<blockquote>
<p>“我用我的 iPhone，就能拍出比 30 年前职业摄影师更好的照片。99.9999% 的照片都是由我和其他非专业人士拍摄的。<strong>所以，这个比喻或许恰恰证明了：我们真的不再需要那么多的‘职业开发者’了。</strong>”</p>
</blockquote>
<p>这场争论，最终指向了一个更本质的问题：<strong>当工具的门槛被无限降低，我们作为“专业人士”的价值，到底还剩下什么？</strong></p>
<h2>从“手艺”到“品味”的跃迁</h2>
<p>在这场看似无解的“生存危机”大讨论中，我们依然能找到一条属于高级架构师的、清晰的破局之路。</p>
<h3>第一条：AI 抹平了“技法”，却放大了“品味”</h3>
<p>一位开发者的评论获得了大量高赞：</p>
<blockquote>
<p>“工具降低了门槛，但<strong>品味（Taste）和基本功（Fundamentals）</strong>，依然是区分‘能跑的代码’和‘好的代码’的唯一标准。就像相机让拍照变容易了，但没让拍出好照片变容易。”</p>
</blockquote>
<p>AI 可以帮你写出符合语法规范的代码，但它无法替你做出架构决策。</p>
<ul>
<li>它不知道你的业务在未来半年会如何演进。</li>
<li>它不理解高并发场景下，一次锁竞争的代价有多大。</li>
<li>它更无法在“开发效率”与“长期可维护性”之间，做出最符合当下团队资源的权衡。</li>
</ul>
<p>这些，就是“品味”。</p>
<h3>第二条：从“执行者”到“定义者”</h3>
<p>另外一位开发者的观点同样深刻：</p>
<blockquote>
<p>“相机没有让每个人都成为摄影师，它只是降低了门槛。AI 也一样，它不会让每个人都成为开发者。<strong>但它会将价值，从‘编写代码’，转移到‘知道该构建什么，以及如何塑造产出’上。</strong>”</p>
</blockquote>
<p>当 AI 能够完美地执行指令时，<strong>“下达正确的指令”</strong>就成了最稀缺的能力。</p>
<p>我们作为资深开发者的核心价值，正在从一个“手艺精湛的工匠”，转变为一个“拥有上帝视角的系统设计师”。</p>
<h3>第三条：别在工具层内卷，向上走，到“思想层”去</h3>
<p>整场讨论中，最让我感到共鸣的，是下面的一段话：</p>
<blockquote>
<p>“我真的超爱写优雅、干净、极简的代码（这正在迅速成为一项无用的技能）。但归根结底，我一直都是一个‘想法的建造者（Builder of Ideas）’。”</p>
<p>“我们的超能力，不是写代码的能力，而是把一个模糊的想法，变成一个真实的产品、系统、服务的能力。社会需要我们，是因为这个。<strong>代码，只是我们用来交付这个概念的工具。</strong>”</p>
</blockquote>
<h2>小结：别担心，你的价值远超你写的代码</h2>
<p>回到最初的那个比喻：<strong>“AI 让每个人都成了开发者”，就像“相机让每个人都成了摄影师”。</strong></p>
<p>是的，相机让记录生活变得轻而易举，但它并没有消灭那些能够捕捉光影、构图、和决定性瞬间的艺术大师。</p>
<p>同样，AI 让实现功能变得前所未有的简单，但它也永远无法取代那些能够洞察需求、设计架构、并对系统最终质量负责的<strong>软件架构师</strong>。</p>
<p>AI 拿走的，只是我们手中的“体力活”。</p>
<p>而留给我们，并被无限放大的，是我们作为工程师最宝贵的东西：<strong>经验、品味、判断力，以及将混乱的世界，构建成优雅系统的能力。</strong></p>
<p>不要再为“写代码”这件事本身感到焦虑了。</p>
<p><strong>向上看，去思考，去设计。</strong></p>
<p>因为在那片 AI 无法触及的高地上，才是你真正的价值所在。</p>
<p>资料链接：</p>
<ul>
<li>https://x.com/Samaytwt/status/2047315095773216780</li>
<li>https://www.reddit.com/r/webdev/comments/1stjfo4/i_just_watched_a_nondev_vibecode_something_were/</li>
</ul>
<p><strong>今日互动探讨：</strong></p>
<p>在 AI 编程的浪潮中，你是否也曾有过“被外行指导内行”的憋屈经历？你认为一个专业开发者，在 AI 时代最不可被替代的核心竞争力是什么？</p>
<p>欢迎在评论区分享你的看法！</p>
<hr />
<p>还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 <strong>《<a href="http://gk.link/a/12IzL">从0 开始构建 Agent Harness</a>》</strong> 将带你：</p>
<ul>
<li>抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理</li>
<li>用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw</li>
<li>构建坚不可摧的 Safety Middleware 与飞书人工审批防线</li>
<li>在底层实现 Token 成本审计、链路追踪与自动化跑分评估</li>
<li>从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”</li>
</ul>
<p>扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。</p>
<p><img src="https://tonybai.com/wp-content/uploads/2026/build-agent-harness-from-scratch-qr.png" 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/05/05/ai-makes-everyone-a-developer-like-cameras-for-photographers/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<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>
	</channel>
</rss>
