# 热门搜索 #
大模型
人工智能
openai
融资
chatGPT
还记得前段时间分享了2026年如何把AI全流程纳入软件工程的那位谷歌工程师吗？他是谷歌 Cloud AI 负责人Addy Osmani。这一回，他又写了一篇博客文章，分享了自己在谷歌工作14年总结的21条教训。
Addy Osmani是一名爱尔兰软件工程师，目前担任谷歌 Cloud AI 的总监，专注于帮助开发者和企业通过 Gemini、Vertex AI 和代理开发套件（ADK）取得成功。他在谷歌曾参与 DevTools、Lighthouse 和 Core Web Vitals 的开发，拥有 25 年构建网络技术的行业经验，同时也是《超越Vibe编程》《学习 JavaScript 设计模式》《图像优化》等多本畅销书的作者。
就在2天前，Addy Osmani发布了一篇最新的博客文章，总结了自己作为一名软件工程师在谷歌工作14年得出的经验教训。他写道：
“大约 14 年前我加入 Google 时，我以为这份工作的核心是写出优秀的代码。这只有部分是对的。”
Addy表示，自己在谷歌待得越久，越意识到那些能够持续成长的工程师，未必是写代码最厉害的人，而是那些搞清楚了“代码之外的一切”的人——包括人、组织政治、目标对齐、以及模糊和不确定性。
他分享了21条“希望自己能更早知道”的经验教训，这些经验有的能帮你少走几个月弯路，有的则花了他好几年才真正想明白。这些经验几乎都不涉及具体技术——因为技术变化太快了，而是那些在一个个项目和团队中反复出现的共性模式。小编读完整篇文章，感觉 Addy 确实掏心窝子地分享了不少作为工程师的职场干货，其中也有一些很反直觉的观察：
有意思的是，Addy总结的经验也引起了不少打工人的共鸣，帖子一度被顶到Hacker News首页前三的位置。
小编整理了 Addy 的经验之谈，一起来看看这位资深软件工程师究竟是如何看待这份职业的吧！
爱上一项技术，然后再到处寻找它的应用场景，这种诱惑几乎所有工程师都经历过——我也不例外。但真正创造最大价值的人，往往是反着来的：他们先深入、反复地理解用户的问题本身，再让解决方案从理解中自然浮现。
所谓“以用户为中心”，并不是一句漂亮的口号，而是要花时间去翻支持工单、直接和用户交流、观察用户卡在哪些地方，不断追问“为什么”，直到触及问题的底层逻辑。真正理解问题的工程师，常常会发现：最终的解决方案，远比所有人一开始设想的要简单；而那些一开始就带着“现成方案”的人，往往会不断往系统里堆复杂性，只是为了给方案找一个合理性。
你完全可以赢下每一次技术争论，却输掉整个项目。我见过不少极其聪明的工程师，因为总是房间里最聪明的那个人，慢慢积累了大量无声的抵触情绪，而这些问题往往会在之后以“执行效率低”“莫名其妙的阻力”等形式显现出来。
真正重要的能力，不是证明自己正确，而是在讨论中先对齐问题本身，给他人留下参与空间，同时对自己的确定性保持警惕。所谓“强观点，弱立场”，并不是没有立场，而是因为在高度不确定的环境中，任何决策都不该和自我认同死死绑在一起。
对完美的追求极其容易让人陷入停滞。我见过工程师花好几周争论一个他们从未真正实现过的“完美架构”。但现实是：完美方案几乎不会仅靠思考诞生，它来自与现实的反复碰撞——在这一点上，AI 其实能起到很大的推动作用。
先做出来，再做对，最后再做好。把丑陋的原型尽快交到用户手中，写下潦草但真实的第一版设计文档，发布一个让你略感羞愧的 MVP。来自真实世界的一周反馈，往往胜过一个月的理论争论。行动会带来清晰，而过度分析只会带来空转。
几乎所有工程师都经历过迷恋“聪明代码”的阶段，那看起来像是一种能力证明。
但软件工程并不是“单人写代码”，而是“时间 + 他人维护”叠加后的结果。在这种环境中，清晰并非审美偏好，而是实实在在的风险控制手段。
你的代码，本质上是写给未来某个凌晨 2 点、在故障中接手系统的陌生人的说明书。你应该优化的是他们的理解成本，而不是自己的技巧展示。我最尊敬的那些资深工程师，几乎每一次都会毫不犹豫地用“清晰”换掉“聪明”。
对待技术选型，可以把自己想象成一个只有少量“创新代币”的组织。每引入一种明显非主流的技术，就花掉一个代币，而你永远花不起太多。
关键并不是“永远不要创新”，而是只在你被明确付费去创新的地方创新。其他地方，默认选择无聊的方案，因为无聊意味着失败模式是已知的。很多时候，“最适合某一个场景的工具”，反而不如“在很多场景下都不太糟的工具”，因为维护一个技术动物园，才是真正长期的成本。
我职业生涯早期一直相信，好工作自然会被看到。事实证明，我错了。
代码安静地躺在仓库里，而你的经理是否在会议中提到你、同事是否推荐你参与关键项目，才真正决定了影响力。
在大型组织中，许多决策发生在你不在场的会议里，基于你没有写过的总结，由只有五分钟时间、却背着十几个优先级的人做出。如果你不在场时，没有人能清楚地说出你的贡献，那你的影响力在现实中几乎等于“可选项”。这并不完全是自我营销，而是让价值链对所有人，包括你自己——变得清晰可见。
工程文化极度推崇“创造”，却几乎没人因为“删除代码”而获得奖励，尽管删除往往比新增更能改善系统。你不写的每一行代码，都是你永远不用调试、维护和解释的一行代码。
在动手之前，先把这个问题问到极致：“如果我们什么都不做，会发生什么？”有时答案是“什么坏事都不会发生”，那这本身就是最好的解决方案。问题从来不在于工程师不会写代码或不会用 AI 写，而在于我们太擅长写了，以至于忘了问：这件事到底该不该存在。
用户一多，任何可观察到的行为都会变成事实上的依赖——无论你是否承诺过。
有人在爬你的 API，有人在自动化你的怪癖，也有人在依赖你的 bug。于是你会发现：兼容性工作并不是“维护”，而是产品本身。
弃用设计时，应当把它当作一次迁移，而不是一次删除，需要给予时间、工具和足够的同理心。事实上，大多数所谓的“API 设计”，真正的难点都在“API 如何退休”。
项目拖延时，人们往往下意识责怪执行力、技术选型或人手不足，但在大公司中，这些往往都不是根本原因。团队是并发的基本单元，而协调成本会随着团队数量呈几何增长。很多所谓的“慢”，其实是大家在做错误的事情，或用彼此不兼容的方式做正确的事情。
这也是为什么真正资深的工程师，会把大量时间花在澄清方向、接口和优先级上，而不是单纯追求“写代码更快”，因为真正的瓶颈通常就藏在那里。
在大公司里，太多事情不在你的掌控范围内：组织调整、管理决策、市场变化、产品转向。反复纠结这些，只会制造焦虑，却不会带来行动空间。
那些能长期保持理性和高效的工程师，会把注意力牢牢放在自己的影响半径内。你无法控制是否发生重组，但你可以控制工作的质量、自己的反应方式，以及从混乱中学到什么。这不是消极接受，而是一种高度理性的战略聚焦。
每一层抽象，本质上都是一次赌注：赌你不需要理解底层。
有时你赢了，但总会有东西泄漏，而当它泄漏时，你往往会在凌晨 3 点独自面对系统。
真正的资深工程师，即便工作在高层技术栈，也会持续学习底层原理。这不是怀旧，而是对现实的尊重——尊重那个抽象失效、只剩你和系统的时刻。你可以充分利用技术栈，但必须理解它的失败模式。
每当我尝试向他人解释一个概念，无论是写文档、做分享、写代码评审，甚至只是和 AI 讨论，我都会发现自己理解中的漏洞。把事情讲清楚给别人听，会让它对自己也更清晰。
这并不仅仅是分享精神，而是一种极其高效、甚至有些“自私”的学习方法。如果你觉得自己已经理解了某件事，试着用最简单的方式解释它；你卡住的地方，往往正是理解最浅的地方。教学，本质上是在调试自己的心智模型。
文档、入职引导、跨团队协调、流程改进，这些工作至关重要，但如果你是无意识地承担它们，它们会拖慢你的技术轨迹，甚至耗尽你的精力。真正的陷阱，是把这些工作当成“个人好心”，而不是有边界、可衡量的影响力。
解决方式是：给它们设定时间边界，轮换责任，把经验沉淀为文档、模板或自动化工具，并让这些成果以“影响力”的形式被看见，而不是作为性格标签存在。无价又隐形，对职业发展来说是非常危险的组合。
我已经学会对自己的确定性保持警惕。当我“赢”得太轻松时，往往意味着哪里出了问题。人们不再反驳你，可能不是被说服了，而是放弃了。而这些不同意，最终会在执行中爆发，而不是在会议上。
真正的对齐需要时间，你必须理解其他视角，吸收反馈，甚至在公开场合改变自己的想法。短期“我对了”的满足感，远不如长期和愿意合作的人一起把事情做成来得重要。
你向管理层展示的任何指标，最终都会被“优化”。这不是恶意，而是人类对被衡量事物的本能反应。衡量代码行数，你会得到更多代码；衡量速度，你会得到被抬高的估算。
更成熟的做法是：对每一个指标，都配对一个。一个衡量速度，一个衡量质量或风险；坚持看趋势，而不是迷信阈值。指标的目的应当是洞察，而不是监控。
敢于说“我不知道”的资深工程师，并不是在示弱，而是在为整个团队创造空间。当领导者承认不确定性时，团队才会觉得提问是安全的。相反，在一个没人承认困惑的环境里，问题只会被压到爆炸那一天。
我见过从不承认不懂的资深者给团队带来的伤害：没人提问、假设无人挑战、初级工程师保持沉默。示范好奇心，团队才会真正学习。
我职业早期过度专注于工作本身，而忽略了建立关系，事后看这是个明显的错误。那些长期投入关系的人，无论公司内外，往往能在几十年里持续受益：他们更早听到机会、更快搭起合作桥梁，更容易被推荐，甚至一起创业。
工作不是永久的，但关系是。用好奇和慷慨去经营它，而不是用功利的交易心态。当你真正准备离开时，往往正是关系，为你打开下一扇门。
系统变慢时，工程师的直觉往往是加东西：缓存、并行、复杂算法。有时这是对的，但更多时候，最大的性能收益来自一个简单的问题：“我们为什么要算这个？”
删掉不必要的工作，几乎总是比把必要工作做快更有效。最快的代码，是根本不运行的代码。在优化之前，先确认这件工作是否真的应该存在。
好的流程让协作更轻松，让失败更便宜；坏的流程只是官僚表演，为出问题时甩锅而存在。如果你说不清一个流程如何降低风险或提升清晰度，它大概率只是负担。
当人们花在“记录自己工作”的时间，已经超过真正做工作的时间时，系统往往已经严重失衡。
职业早期，用时间换钱是合理的；但某个阶段之后，你会发现时间是不可再生的资源。我见过太多资深工程师为了下一个晋升等级透支自己，有些人成功了，但更多人在事后怀疑：这真的值得吗？
答案并不是“不努力”，而是清楚地知道你在交换什么，并且有意识地做出选择。
专业能力来自长期、刻意的练习：不断稍微超出舒适区、反思、再重复。没有压缩版本。但好消息是，当学习带来的是“新选择”而不是零散知识时，它会产生复利效应。
写作不是为了流量，而是为了清晰；构建可复用的能力模块；把踩过的坑整理成操作手册。把职业当成复利来经营的人，通常会比靠运气下注的人走得远得多。
这 21 条经验听起来很多，但本质上都指向几个核心原则：保持好奇、保持谦逊，并记住这份工作始终是关于人——你服务的用户，以及与你并肩工作的同伴。
工程师的职业足够漫长，允许你犯很多错误，依然走得很好。我最敬佩的工程师，不是从未犯错的人，而是那些从失败中学习、愿意分享经验、并持续前行的人。
如果你还在早期，请相信这条路会随着时间变得越来越有深度；如果你已经走了很远，希望其中有些内容，能与你产生共鸣。
“你的bug也会有用户”——这条经验说到了不少开发者的心坎里，在Hacker News评论区，很多网友也分享了自己的相关经历。
网友trescenzi分享，自己在工作中优化了软件的加载时间，反而导致了客户的负面反应——因为这样把他们10分钟喝咖啡聊天的时间给省掉了！
网友Aurornis也表示，他在做自动化工作的时候，让技术部分变得越高效，客户能坐着聊天的时间就越少，自己的工作反而越不受欢迎。
网友ehnto则分享，自己在开发软件的过程中，软件的计算速度太快导致用户不信任计算结果，他们还不得不加了30秒左右的人为延迟。
——看来这样啼笑皆非的例子在软件开发中并不少见。
那么评论区的各位大佬们，
你觉得Addy有哪些经验说到你心坎里去了呢？
你在日常工作中有哪些经验之谈？
欢迎在评论区写下你的看法。
参考链接：
https://addyosmani.com/blog/21-lessons/
文章来自于“51CTO技术栈”，作者 “听雨”。
