硅谷资深工程师：不止是 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. 注重灵活性，尽量避免对软件开发的正确方式形成绝对化认知。

我自己的好品味也是慢慢积累起来的，但这并不意味着它一定需要长期沉淀，我相信有些人可以快速养成。就像其他领域有超越经验的天才一样，编程领域也一定有品味远超自身经验的天才。