編譯 | 核子可樂、Tina

這不是一篇教你寫更好代碼的文章，而是告訴你：在大廠里，代碼往往不是決定你走多遠的關鍵因素。作者 Addy Osmani 是一位來自愛爾蘭的資深工程領導者，現(xiàn)任 Google Cloud AI 總監(jiān)，負責推動開發(fā)者與企業(yè)落地 Gemini、Vertex AI 和 Agent Development Kit（ADK）。在此之前，他在 Chrome 團隊深耕近 14 年。如今他的工作橫跨 Google DeepMind、工程、產(chǎn)品與開發(fā)者關系，專注把研究與工程落地連起來。

也正因為經(jīng)歷過一線開發(fā)、平臺級產(chǎn)品、以及大型組織協(xié)作的完整周期，他回頭復盤谷歌十四年職場才意識到：那些在谷歌“如魚得水”的工程師，未必是最強程序員，而是更懂得駕馭人際關系、政治博弈、目標對齊與組織灰度。技術會迅速迭代，但這些規(guī)律會在項目推進、團隊更替中反復出現(xiàn)。

你將看到：

• “最強工程師”并不等于“最會寫代碼的人”：真正拉開差距的，是對用戶、目標、協(xié)作與組織運行邏輯的理解。

• 技術理想主義為何常常輸給現(xiàn)實工程？：贏下技術爭論很容易，推動事情落地卻極難；立場堅定不如態(tài)度靈活。

• 為什么“清晰”比“精巧”更像資深工程師的標志？：代碼是寫給凌晨兩點接手系統(tǒng)的陌生人的“戰(zhàn)略備忘錄”。

• 刪代碼，比寫代碼更高級：多數(shù)性能優(yōu)化與穩(wěn)定性提升，來自消除冗余，而不是不斷疊加新功能。

• 在大廠，代碼不會為你發(fā)聲，只有人會：再好的實現(xiàn)，如果沒人理解、沒人轉述、沒人提及，就等于不存在。

• 抽象不是解藥，只是延期付款：技術棧越高，越需要保留對底層故障模式的敬畏。

• 用戶足夠多時，連 bug 都會被當成“特性”依賴：真正難的不是修 bug，而是怎么不把用戶一起“修沒了”。

這不是成功學清單，而是一位長期身處 Google 核心工程體系，在反復碰壁與被點醒之后寫下的“少走彎路說明書”。如果你正身處大廠、規(guī)?；瘓F隊，或正在思考AI 時代工程師真正不可替代的能力是什么，這篇文章很可能會讓你不斷點頭，也偶爾刺痛。

以下為原文翻譯：

谷歌十四年，我學到的“二十一條軍規(guī)”

十四年前剛加入谷歌那會，我以為自己的工作很簡單——寫出優(yōu)秀代碼。其實這種理解倒也沒錯，但待得越久我越意識到那些在谷歌如魚得水的工程師未必就是最強程序員——相反，他們在代碼之外更懂得駕馭其他：人際關系、政治博弈、目標對齊以及灰色地帶。

我真希望自己能早點醒悟，這樣我就能少遭受一點挫折、少辜負些許韶華。這些跟具體技術無關，畢竟技術迭代太快，根本沒那么重要。最關鍵的是那些在項目持續(xù)推進、團隊不斷更新當中反復顯現(xiàn)出的規(guī)律。

好在曾有前輩高人對我點撥，讓我受益匪淺，所以我決定把這些整理出來。希望這份善意能給大家一點幫助、一點啟發(fā)。

1. 最優(yōu)秀的工程師，癡迷于解決用戶痛點。

沉迷于某項技術，并四處尋找應用場景確實是種強烈的、難以抵抗的誘惑。曾經(jīng)的我是這樣，人人也都是這樣。但那些善于創(chuàng)造最大價值的工程師會采取逆向思維：他們癡迷于深刻理解用戶痛點，而解決方案會自然從洞察當中浮現(xiàn)。

這種用戶至上的心態(tài)，讓他們沉浸在支持工單當中、與用戶對話、觀察用戶的掙扎，不斷追問“為什么”直到觸及核心。真正洞悉問題本質的工程師們常常發(fā)現(xiàn)：優(yōu)雅的解決方案往往比任何高手的純粹思想實驗都更加簡單。

而先有答案再去找問題的工程師，會永遠在構建復雜性的過程中拼命為自己尋找合理化依據(jù)。

2. 堅持己見易如反掌，攜手求真方為正途。

我們可以贏盡所有技術爭論，卻輸?shù)粽麄€項目。我見過太多才華橫溢的工程師，他們永遠是會議室里最聰明的參與者，卻只能默默積攢怨氣。問他們?yōu)槭裁唇Y果總是不好，回答只有“執(zhí)行不力”和“抵觸太強、推動不了”。

真正的本事不在于堅持己見，而在于參與討論時聚焦問題本質，同時注意為他人留出空間、對自身觀點保持懷疑。

立場堅定、態(tài)度靈活絕不是缺乏信念，而是一種清醒的認識：在無數(shù)不確定性當中做出決策時，千萬不要把對事的爭論跟對人的反感混為一談。

3. 行動為先，快速發(fā)布。糟糕的頁面可以修改，空白的頁面卻無法優(yōu)化。

追求完美只會讓人動彈不得。我見過工程師們拿出幾十天去討論從來沒能實現(xiàn)的理想架構。完美方案很少源自純粹思考，更多誕生自與現(xiàn)實的碰撞。而 AI 在這方面將大有可為。

所以行動為先、再完善，最后優(yōu)化。別害怕把丑陋的原型展示給用戶，別害怕寫出凌亂的設計初稿。勇于發(fā)布那些讓自己難堪但至少已經(jīng)可行的產(chǎn)品。拿出一周獲取真實反饋，遠勝過連續(xù)一個月的純理性爭論。

動能會讓事實清晰，沉迷分析只會讓人身心俱疲后無力作戰(zhàn)。

4. 清晰即資歷，精巧成負擔。

工程師們都希望編寫出精巧的代碼，仿佛這就是對自身能力最直接的證明。

但軟件工程本身就是時間與協(xié)作的產(chǎn)物。在此等開發(fā)場景之下，追求清晰絕非風格偏好，而是在切實降低運營風險。

這里我把話再得明白些：我們的代碼，就是發(fā)給陌生人的戰(zhàn)略備忘錄，供他們在凌晨兩點面對系統(tǒng)故障時參考以接手維護。所以優(yōu)化的目標應該是更好地適應他們的理解力，而非代碼本身是否精巧。我最敬重的資深工程師們，都明白當清晰與精巧對立時選擇前者。

5. 不要為了新奇而新奇——這是一筆將用宕機、人才流失和認知負擔償還的債務。

在選擇企業(yè)時，一定關注他們是否對技術選型是否敬畏，是否意識到自身能夠消化的“新奇配額”極其有限。每次采用非標方案，就會消耗掉其中一部分額度，直至不堪重負。

關鍵并不在于“停止創(chuàng)新”，而在于“僅在被賦予獨特創(chuàng)新價值時才追求新奇”。其余選擇則應越中庸越好，這樣才能保證潛在后果更可確定、可把控。

所謂“最佳工具”，更多是“在多種場景下最不差的工具”。與之對應，如果你的系統(tǒng)本身已經(jīng)復雜得如同動物園，那管理的成本可想而知。

6. 代碼不會為你發(fā)聲，只有人會。

在職業(yè)生涯早期，我曾以為杰作自會證明價值。事實證明這是錯的。代碼只會靜默躺在代碼庫里，而主管能在會上提到你、也可以只字不提；同事能推薦你參與項目，也可以提名他人。

在大型組織里，重大決策很可能發(fā)生在你未能參與的會議中、基于不由你撰寫的摘要，由那些時間緊迫、任務繁重的決策者拍板。如果你不在聲，如果無人闡明你的價值，你的存在必然淪為可有可無的選項。

這并非單純的自我推銷，而是讓價值鏈更清晰地展現(xiàn)在所有人——包括我們自己——面前。

7. 不需要寫出來的代碼，才是最好的代碼。

我們頌揚工程文化中的創(chuàng)造精神。刪除代碼不會獲得晉升，但刪除卻往往比添加更能提升系統(tǒng)效率。每一行不必寫出的代碼，都代表著少了一份調試、維護或者解釋的負擔。

在構建之前，請務必認真思考：如果干脆不做，結果會怎樣？如果答案是“其實差不多”，那就勇敢放棄。

問題并不在于工程師能不能把這部分代碼交給 AI 生成。相反，很多工程師編寫代碼的本領太過精湛，以致于忘記審視“有沒有必要編寫”這個根本問題。

8. 只要規(guī)模夠大，連 bug 都有受眾。

當用戶基數(shù)足夠龐大，一切可觀察行為都將轉化為依賴關系?？傆腥藭ト∧愕?API、自動化你的特殊邏輯，甚至把 bug 也緩存起來。

這就是獨屬于專業(yè)人士的知覺：兼容性工作并不只是“維護”，新功能也不一定就更“正經(jīng)”。相反，兼容性本身就代表著產(chǎn)品。

因此在設計棄用方案時，請盡可能傾注更多時間、工具和同理心。千萬別讓“API 設計”淪為“API 清退”。

9. 大多數(shù)“低效”團隊的軟肋，在于目標錯位。

項目拖延時，人們習慣把問題照片于執(zhí)行層：員工不夠努力啦、技術選型失誤啦、工程師人手不足啦。但這些往往并非真正的問題。

在大廠當中，團隊是并行工作的基本單元。但隨著團隊數(shù)量的增加，協(xié)調成本也呈幾何級增長。大部分效率低下實際是協(xié)同失敗的體現(xiàn)——要么是開發(fā)了錯誤的功能，要么是實現(xiàn)的正確功能之間相互沖突。

資深工程師們花在厘清方向、接口和優(yōu)先級上的時間，要遠多于“加快編程速度”，而真正的區(qū)別也在于此。

10. 專注可控之事，忽略不可控之事。

在大型企業(yè)中，無數(shù)變量終將超出掌控范圍——組織架構調整、管理決策、市場波動、產(chǎn)品轉型等皆在此列。過度糾結只會徒增焦慮，卻又無能為力。

要保持理智高效，工程師們需要專注于自身影響力范圍。我們無法控制重組是否發(fā)生，但可以掌控工作質量、應對方式并學習收獲。在面對不確定性時，應努力將問題拆分為可控的具體行動。

這并非消極妥協(xié)，而是強調戰(zhàn)略聚焦。耗費在無法改變之事上的精力越多，本該投入可控之事的能量就越少。

11. 抽象化不會消除復雜性，只會推遲問題爆發(fā)的時間。

每一次抽象化，都是對“無需理解底層原理”的一次重復和豪賭。有時候我們會贏，但我們終歸會辦理——等到問題出現(xiàn)，大家最好想清楚自己該如何應對。

即使面對日益高聳的技術棧，資深工程師們仍然持續(xù)鉆研“底層”知識。這不是在懷舊，而是對抽象失效時刻的敬畏——他們只是不想凌晨三點獨自面對系統(tǒng)崩潰。

因此，請善用技術棧，同時務必保留對底層故障模式的深刻認知。

12. 寫作讓思路更清晰，學習新知識的最快途徑就是向他人表達。

寫作會迫使我們保持清醒。在向他人闡釋概念時——無論是文檔、演講、代碼審查評論還是跟 AI 對話等形式——我總能發(fā)現(xiàn)自身理解中的漏洞。幫助其他人理解的過程，恰恰也讓我自己更好地認清本質。

這不只是在慷慨地分享知識，更是一種非常有益的學習捷徑。如果你自認為弄懂了某事，請嘗試簡要概括——在哪里卡殼了，那里就是大家最需要鞏固的部分。

表達和指導，是對自我思維模式的調試。

13. 支撐其他業(yè)務的幕后工作雖無價，但往往隱形。

粘合性質的工作——比如編寫文檔、帶新人、跨團隊協(xié)調、流程優(yōu)化等——特別特別特別重要。但也千萬別陷得太深，它會阻滯技術成長并耗盡精力。所以別把這事理解成“樂于助人”，而應有意識地創(chuàng)造可量化、有邊界且有影響力的成果。

設定明確的時間框，輪換執(zhí)行人員，并把努力轉化為可復用的形式：文檔、模板、自動化工具等，確保其價值以“影響”而非“善良”的形式呈現(xiàn)。

14. 如果每次都是你的意見勝出，反抗的力量可能正在積蓄。

我學會了對自身堅持的東西保持警惕。當“勝利”來得太輕松，背后往往藏有代價。對方停止爭論并不是被說服，而是懶得繼續(xù)——他們會把抗議體現(xiàn)在行動中，而非會議室里。

建立真正的共識需要更長時間。大家必須真正理解他的視角、采納反饋意見，甚至甚至得公開改變自己的立場。

壓倒他人的短期滿足感，其價值遠遠不及與有意愿的合作者建立起長期而穩(wěn)固的信任。

15. 當量化標準本身淪為目標，它就失去了衡量的功能。

能讓上司們看到的每項指標，最終都會淪為空架子。這倒不一定出于惡意，而是人類天生就會刻意迎合這些量化標準。

如果以代碼行數(shù)論英雄，那代碼量必然膨脹；如果以開發(fā)速度為指標，時間表將不再可靠。

資深工程師們會把各項指標匹配起來，綜合加以考量。如果其中一項衡量速度，就必須有另一項衡量質量或風險。借此解讀趨勢，而非盲目認可數(shù)據(jù)。畢竟這些績效只是為了積累洞察，而非強加監(jiān)控。

16. 開誠布公比不懂裝懂更能創(chuàng)造安全感。

資深工程師在說“不知道”時并非示弱，而是在爭取更大的空間。當領導者承認存在不確定性時，其實也在向團隊傳遞安全信號，提醒大家可以積極質疑。若非如此，就會形成不懂裝懂的集體文化，問題終將被掩蓋直至集中爆發(fā)。

我接觸過那種嘴巴特硬的資深從業(yè)者，也見證過因此造成的危害。無人敢于發(fā)問，因此企業(yè)誤以為不存在問題。

勇敢展現(xiàn)好奇心，整個團隊都將洋溢熱烈的學習氛圍。

17. 人脈網(wǎng)絡比任何工作崗位都更持久。

在職業(yè)生涯早期，我專注工作而忽視了人脈積累。現(xiàn)在看來這肯定是個錯誤。那些注重維系人際關系的同事會持續(xù)收獲回報：他們率先知曉機會、更多建立聯(lián)系、獲得職位推薦，甚至與多年來建立信任的共同創(chuàng)立企業(yè)。

崗位終有盡時，人脈卻能永續(xù)。當然，請以好奇與慷慨之心經(jīng)營，而非功利算計。

在邁入人生的新階段時，人脈往往就是那塊敲門磚。

18. 多數(shù)性能提升源自消除冗余，而非添加功能。

系統(tǒng)變慢時，人們總想添加緩存層、并行處理或者更智能的算法。當然這也不是錯，但我見過的更多優(yōu)化其實是“我們是不是塞了太多不必要的東西？”

刪除冗余部分幾乎總要引入加速機制更有效。不需要運行的代碼，才是最快的代碼。

因此在優(yōu)化前，請認真考慮這部分代碼是否應該存在。

19. 流程的本質是降低不確定性，而非“事過留痕”。

最好的流程應該簡化協(xié)調并降低失敗成本，而最差的流程則是官僚大舞臺——其存在不是為了解決問題，而是為了出錯時可以推卸責任。

如果沒法解釋一套流程如何降低風險或提升清晰度，那它很可能只是冗余和負擔。

當人們耗費更多時間記錄工作、而非真正解決問題時，系統(tǒng)肯定是出了大問題。

20. 終有一天，時間會比金錢更珍貴，請牢記這點。

在職業(yè)生涯早期，用時間換取金錢是沒問題的。但轉折點終將到來，大家會逐漸意識到：時間才是不可再生資源。

我見過資深工程師為了晉升而透支生命，只為爭取微薄的薪酬提升。少數(shù)人如愿以償，但事后往往會捫心自問“這值得嗎？”

我并不是想否定“努力工作”，而是希望大家認清交易的本質、審慎做出權衡。

21. 沒有捷徑，只有復利效應。

專業(yè)能力源自努力練習，持續(xù)突破現(xiàn)有能力的邊界、反思并不斷重復，數(shù)十年如一日。沒有速成之道，完全沒有。

好消息是：學習和創(chuàng)造的新可能會產(chǎn)生復利效應。比如為了厘清思路而寫作，構建可復用的基礎模塊，將教訓轉化為價值滿滿的實戰(zhàn)寶典。

只有將職業(yè)生涯視為復利累積，工程師們才能獲得更遠大的成就。

這二十一條心得看似繁多，但也可快速歸納為三條核心：保持好奇、保持謙遜，并謹記工作的本質——以人為本，以用戶為本，以并肩作戰(zhàn)的隊友為本。

工程師的職業(yè)生涯足夠漫長，容得下無數(shù)次錯誤。我最敬佩的工程師并非事事完美之人，而是那些善于從失敗中汲取教訓、分享成果并始終堅持前行的人，他們終將脫穎而出。

若諸位剛剛踏上征程，請相信歲月會讓這份沉淀愈發(fā)豐盈；若大家早已深耕其中，也愿這些感情能與你產(chǎn)生共鳴。

https://addyosmani.com/blog/21-lessons/

會議推薦

InfoQ 2026 全年會議規(guī)劃已上線！從 AI Infra 到 Agentic AI，從 AI 工程化到產(chǎn)業(yè)落地，從技術前沿到行業(yè)應用，全面覆蓋 AI 與軟件開發(fā)核心賽道！集結全球技術先鋒，拆解真實生產(chǎn)案例、深挖技術與產(chǎn)業(yè)落地痛點，探索前沿領域、聚焦產(chǎn)業(yè)賦能，獲取實戰(zhàn)落地方案與前瞻產(chǎn)業(yè)洞察，高效實現(xiàn)技術價值轉化。把握行業(yè)變革關鍵節(jié)點，搶占 2026 智能升級發(fā)展先機！