硅谷資深工程師：不止是 AI 產品，Coding 也需要好的 taste

我們知道，一個好的「品味（taste）」對于做好 AI 產品，很重要。但對于技術，「品味」也同樣重要。

對于工程師來說，技術的品味與技術能力是兩碼事。有人可能技術能力強但品味差，或者技術弱但品味好。培養一個「好」的技術品味，有時會讓結果超出原有的技術能力。

那么，略顯「玄妙」的技術品味的核心是什么？硅谷資深工程師 sean goedecke 給出的答案是：「為當前項目選擇適配的工程價值觀」的能力。

因為在軟件工程領域，絕大多數的決策，核心都是在不同目標之間進行權衡。很少會遇到一個選項在所有方面都絕對優于另一個選項的情況。這時候，有一個好的工程價值觀就特別重要。

如何建立一個好的工程價值觀，都在 sean goedecke 的這篇經驗帖里了。

sean goedecke：Github 高級工程師

個人主頁介紹：https://www.seangoedecke.com/my-engineering-values-2025/

原博客鏈接：https://www.seangoedecke.com/taste/?utm_campaign=what-is-good-taste-in-software-engineering-6267&utm_medium=email&utm_source=seangoedecke

超 14000 人的「AI 產品市集」社群！不錯過每一款有價值的 AI 應用。

邀請從業者、開發人員和創業者，飛書掃碼加群：

進群后，你有機會得到：

• 最新、最值得關注的 AI 新品資訊；
  

• 不定期贈送熱門新品的邀請碼、會員碼；
  

• 最精準的AI產品曝光渠道

你可以技術能力強但品味差，或者技術弱但品味好。就像我們通常所說的「品味」一樣，技術品味有時會超過你的能力：就像不用會做飯也能分辨食物好壞，你可以在具備構建軟件的能力之前就知道你喜歡什么樣的軟件。你可以通過學習和重復來發展技術能力，但良好品味的養成方式則更加「玄妙」一些。

以下是判斷技術品味的幾個參考方向：

• 在你眼中，什么樣的代碼「看起來優雅」？什么樣的代碼「看起來粗糙」？

• 哪些設計決策會讓你由衷覺得出色的，而哪些只是「勉強合格」？

• 哪些軟件問題會讓你格外困擾，甚至在工作之外還惦記著？哪些問題你能輕松拋在腦后？

在我看來，品味的核心是「為當前項目選擇適配的工程價值觀」的能力。

01
為什么品味不等于能力？

難道上述的判斷方向不正是技術能力的一部分嗎？比如，「看起來優雅的代碼」不就是優質代碼本身嗎？我并不這么認為。

舉個例子：對我個人而言，用map和filter實現的代碼，看起來比for循環更簡潔優雅。人們很容易覺得，這是我在工程判斷上「直白且正確」的體現，畢竟map和filter通常基于純函數，這類函數更易推導邏輯，還能避免一整類「差一錯誤」（off-by-one）的迭代漏洞。我甚至會下意識覺得，這不是品味問題，而是我正確而其他工程師錯誤的情況。

但實際情況要復雜得多。像 Golang 這樣的語言，出于原則性考量，完全沒有map和filter功能。從性能角度來看，for循環的迭代邏輯更易評估，并且也更直接地擴展到其他迭代策略（比如一次取兩個項）。我對「支持map和filter的理由」的重視程度，遠高于「支持for循環的理由」，這也是我很少寫for循環的原因。但如果因此就說「偏愛for循環的工程師能力更弱」，那就太傲慢了。很多時候，這些工程師具備我沒有的技術能力，他們只是在意的優先級和我不同而已。

換句話說，我們的分歧本質上是價值觀的差異。我曾在《我不懂如何開發軟件，你也不知道》（https://www.seangoedecke.com/confidence）這篇文中提到過這個觀點：即使技術大辯論確實有明確的答案，也沒有一個在職的軟件工程師能夠知道這些答案是什么，因為一個人在職業生涯中只能積累有限的經驗。我們都或多或少都依賴自己的個人經驗，依賴自己特有的一套工程價值觀。

02
技術品味的本質是什么？

軟件工程中的幾乎每一個決策都是一種權衡。你很少會遇到「一個選項絕對優于另一個」的情況，相反，每個選項都有其優勢和短板。很多時候，你必須在不同工程價值觀之間做艱難取舍：比如超過某個臨界點后，要提升性能就難免會損害代碼的可讀性。

作者注：當然，情況并不是總是這樣。有時也會出現雙贏的局面，讓你能夠同時提升幾個通常相互沖突的價值維度。但多數時候，我們無法奢求這樣的好事。

在我看來，真正理解這一點，是軟件工程領域「成熟度」的最大標志。不成熟的工程師對自己的決定很固執。他們認為做 X 或 Y 總是更好的。成熟的工程師往往更愿意考慮決策的兩面，因為他們知道兩個方面都有不同的好處。關鍵不在于決定技術 X 是否比 Y 更好，而在于在這個特定情況下，X 的好處是否超過了 Y。

換句話說，不成熟的工程師對自己的品味過于固執。他們知道自己喜歡什么，但錯誤地將這種喜好視為一個原則性的工程立場。那么，是什么定義了一位特定工程師的品味呢？

在我看來，一個人的技術品味，由他最看重的那套工程價值觀構成。比如：

• 彈性（Resiliency）：如果基礎設施組件故障（服務宕機、網絡中斷），系統還能正常運行嗎？能否在無需人工干預的情況下恢復？

• 運行速度（Speed）：軟件的運行速度與理論極限差距有多大？核心流程中是否存在非必需的運算步驟？

• 可讀性（Readability）：軟件是否一目了然，新工程師能否快速上手？函數是否簡潔、命名是否清晰？系統文檔是否完善？

• 正確性（Correctness）：系統是否可能出現無效狀態？通過測試、類型檢查、斷言等手段，系統的安全性是否足夠高？測試中是否用到模糊測試（fuzzing）等技術？極端情況下，是否通過 Alloy 等形式化方法驗證了程序正確性？

• 靈活性（Flexibility）：系統是否能輕松擴展？做出變更的難度有多大？如果需修改某個功能，要涉及程序中的多少模塊？

• 可移植性（Portability）：系統是否依賴特定運行環境（如微軟 Windows、亞馬遜 AWS）？如果需部署到其他環境，是否無需大量改造就能實現？

• 可擴展性（Scalability）：如果流量增長 10 倍，系統會崩潰嗎？增長 100 倍呢？系統是否必須過度配置資源，還是能自動擴展？哪些瓶頸需要通過工程改造解決？

• 開發效率（Development Speed）：如果要擴展系統功能，多久能完成？大多數工程師都能參與開發，還是必須依賴領域專家？

除此之外，還有很多其他工程價值觀，如：優雅性（elegance）、現代性（modern-ness）、開源使用（use of open source）、維持系統運行的貨幣成本（monetary cost）等等。所有這些都很重要，但沒有哪個工程師會同等地關心所有這些事情。你的品味，取決于你把哪些價值觀排在優先位置。比如：

• 如果你更看重「運行速度」和「正確性」，超過「開發效率」，那你可能更偏愛 Rust 而非 Python；

• 如果你更看重「可擴展性」超過「可移植性」，那你可能會主張大力投入，充分利用托管平臺（如 AWS）的特有功能和工具；

• 如果你更看重「彈性性」超過「運行速度」，那你可能會希望將流量分配到不同的區域。

作者注：正如前文所述，不同的項目自然需要遵循不同的價值準則。但負責這些項目的工程師們終究需要在某處劃定界限，而劃定界限的依據，是他們自身的品味。

這些價值觀還可以進一步細化。比如兩位同樣重視「可讀性」的工程師，可能因「一位偏愛簡短函數」而「另一位偏愛簡短調用棧」產生分歧；兩位同樣重視「正確性」的工程師，也可能因「一位依賴全面測試套件」而「另一位依賴形式化方法」持有不同觀點。但核心邏輯不變：值得關注的工程價值觀有很多，且它們之間常存在沖突，因此每個工程師都必須有所側重。

03
如何識別「壞品味」？

我說過，所有的工程價值觀都很重要。即便如此，糟糕的品味依然存在。在軟件工程領域，糟糕的品味意味著你偏好的價值觀并不適合你正在從事的項目。

我們大多數人都有與這類工程師合作的經驗。他們加入項目后，就極力推崇某樣東西：形式化方法、用 Golang 重寫代碼、Ruby 元編程、跨區域部署等等。只因為這些方法在他們過去的工作中奏效過。無論是否適合當前項目，他們都會極力主張采用，僅僅是因為「這是他們喜歡的方式」。不知不覺中，不知不覺中，你就在確保你的內部指標儀表板有五個九的可靠性，而代價是讓任何初級工程師都無法理解它。

換句話說，大多數壞品味都來源于「僵化」。我永遠不信任那些通過說「這是最佳實踐」來為決策辯護的工程師。沒有任何工程決策在「所有場景下」都是「最佳實踐」。你必須根據當前面臨的具體問題，做出最適合的選擇。

這一點帶來的有趣結果是：品味糟糕的工程師，就像壞掉的指南針。要是你恰好站在正確位置，它或許還能指向北方；但一旦你開始移動，它就會帶你偏離方向。同樣，很多品味糟糕的工程師，在「自己的偏好與項目需求匹配」的特定領域里，可能表現得相當出色。可一旦換項目、換工作，或項目性質發生變化，問題就會立刻暴露。沒有哪個工作能長期不變，尤其是在 2021 年后這個充滿變數的時代。

04
如何識別「好品味」？

相比技術能力，好品味要難識別得多。因為技術能力可以通過具體的指標來衡量，而好品味的本質是「為特定技術問題選擇適配的工程價值觀」的能力。因此，判斷一個人是否有好品味并不容易：你無法通過「玩具問題」（toy problems）或「技術常識提問」測試，必須結合一個真實問題，以及問題背后所有復雜的現實背景才能判斷。

如果你的項目成功了，你可以說自己有好品味。如果你沒有對項目的設計做出有意義的貢獻（也許你只是在做任務工單），但你認同的的項目進展順利，你不認同的項目磕磕絆絆，也可以說自己有好品味。

重要的是，你需要經歷一系列不同類型的項目。如果只有一個項目，或者反復進行同一種類型的項目，你可能只是適合那個項目。即使你經歷了許多不同類型的項目，這也并不能保證你在不太熟悉的專業領域同樣具備好品味。

作者注：我確實認為好品味在某種程度上是可以遷移的。關于這一點，我個人經驗不多，但我想，如果你在 A 領域能夠展現出靈活性和對細節的洞察力，那么在 B 領域，你很可能也能做到同樣出色。

05
如何培養良好品味？

這很難給出確切的標準答案，但我建議你：

1. 多嘗試不同類型的工作，仔細觀察哪些項目（或項目的哪些部分）做起來輕松，哪些部分是困難重重的；

2. 注重靈活性，盡量避免對軟件開發的正確方式形成絕對化認知。

我自己的好品味也是慢慢積累起來的，但這并不意味著它一定需要長期沉淀，我相信有些人可以快速養成。就像其他領域有超越經驗的天才一樣，編程領域也一定有品味遠超自身經驗的天才。

轉載原創文章請添加微信：founderparker