技术圈的品味比代码能力更难学：一份来自资深工程师的反思

一位在硅谷资深工程师博客上写过一篇文章，里面有一句很反常识的话：「技术能力到一定阶段之后，决定你走多远的不是你会多少门语言，而是你的品味。」这位作者在公司做了一次内部技术评审，发现一个让人意外的事实：那些被认为「代码味道」差的项目，几乎都不缺能写代码的人，反而缺的是有审美的眼睛。

这句话和大多数人对技术能力的理解是相反的。按照常理，工程师的成长路径应该是：先学会语法，再熟悉框架，最后深入架构。审美和品味这种偏主观的维度，应该排在最后。这位作者却告诉我们，对很多团队来说，真正卡脖子的不是工程师写不出好的实现，而是工程师看不出哪种实现是「好」的。

品味这个词在程序员圈子里并不陌生，但很少有人愿意正式讨论它。一方面，品味听起来像玄学，不像性能优化那样有数据支撑；另一方面，承认自己品味差，比承认自己技术差还要难。但这位作者的案例说明，这种回避正在让团队付出真实的代价。

他的公司有一个内部工具项目，先后换过三拨人开发。每拨工程师在接手前都自信满满，觉得自己能写出一个更好的版本。结果三拨人写出来的工具，界面和交互都差不多糟糕。最后用户不愿意用，工具被废弃，整条产品线也跟着拖慢了节奏。

为什么会出现这种重复失败？作者复盘后发现，三拨工程师有一个共同点：他们都没用过几个真正好用的同类产品。一个好的内部工具，本来应该参考行业里最成熟的解决方案。但是工程师们平时都把时间花在了写代码上，很少花时间去看别人写的东西。他们的视野被自己的项目困住了，结果每个团队都在重新发明一个本来已经存在的好设计。

这个观察其实点出了一个更深的问题：品味不是天生的，它是从大量「见过好东西」的经验里沉淀出来的。一个人如果只看自己公司的代码，最多只能做到「不丑」，但很难做到「漂亮」。要跨越这个坎，需要主动去看行业里被公认做得好、但跟当前工作无关的项目。这些项目的代码可能永远不会用到，但它们会在脑子里形成一个「好」的标准。

作者在文章里提到了一个具体的练习方式：每周花一个小时，访问那些被开发者社区公认做得好的开源项目或商业产品，只看不写。研究它们的界面节奏、状态变化、错误处理方式。这种练习不会直接提高你的代码能力，但会让你在下一次做技术评审时，多一根判断「这个设计到底好不好」的尺子。

品味这个东西一旦建立起来，会反过来影响很多原本被认为是纯技术的工作。比如代码审查。作者发现，有品味的工程师在审查别人代码时，更容易看出「这段逻辑虽然能跑通，但读起来很别扭」这种问题。这种直觉不是靠死记硬背《代码大全》能学到的，而是在看过几百个写得好的项目之后自然形成的。

作者还观察到一个反直觉的现象：技术能力很强的人，往往更容易被自己的技术能力困住。他举了一个具体的例子，公司里有一位资深工程师，写了一个性能极强的内部工具。这个工具的功能完全够用，速度也很快，但用户都不喜欢用它。原因是它的界面非常难用，每次操作都要点五六次。这位工程师反复说「界面又不是不能用」，但用户就是不用。

后来这位工程师去别的公司交流了一圈，回来之后主动重写了界面。新的界面在性能上没有做任何妥协，但操作路径从五六次点击降到了两三次。工具的使用率立刻翻倍。这位工程师后来反思，他之前不愿意改界面，表面上是因为「改界面没技术含量」，本质上是害怕承认自己原来写的版本不够好。

这个故事里有两个值得注意的细节。第一个细节是，重写界面之后，工具的功能和性能完全没有变化，改变的只是审美。这意味着，公司花了几周时间做的性能优化，其实远远比不上几天的界面优化给用户带来的价值。第二个细节是，工程师承认自己的品味差，比承认技术能力差要难得多。这种心理阻力如果不主动克服，会一直阻挡着团队做出更好的产品。

作者给出的最终建议只有一句：在你做下一个项目之前，先花点时间去看 10 个公认做得好的同类产品。不需要分析，只需要看。看完之后你会发现，自己再写代码的时候，手里多了一根看不见的尺子。这根尺子不会告诉你怎么写最省代码，但会告诉你哪种写法最让人舒服。

品味这个东西看起来很虚，但它在团队里造成的影响是实实在在的。一个团队做出来的东西好不好，最终用户会用脚投票。技术能力强可以让产品不崩溃，品味好可以让产品被人喜欢。这两者都重要，但在大多数公司里，技术能力一直被过度强调，品味一直被忽视。这是一个值得每个工程师反思的盲区。

（来源：Hacker News 2026 年 8 月技术博客文章《Taste Is All That's Left》）

个人成长方法论，上乌鸦部落。

创业找资源，上乌鸦部落。