开发者如何提升产品品味？

近期Lenny’s Podcast 访谈了 Claude Code 和 Cowork 的产品负责人 Cat Wu，聊 Anthropic 的产品团队如何做到比谁都快。她说，product taste 是现在最值钱的技能。类似的观点 Ilya 也表达过。以至于业界调侃：code is cheap, show me your taste.

我同意这个判断，但”品味”这个词太抽象了，很容易变成玄学。我想通过这篇文章跟大家探讨，以及表达我对产品品味的看法。

一、代码成本暴跌，”做什么”比”怎么做”更重要

在 Anthropic，工程师和产品经理的边界正在模糊。Cat Wu 说他们的产品团队全部都有开发经验，更倾向于招有产品品味的工程师。PM 和设计师都用 Claude Code 写代码，觉得没问题就直接提 PR，不需要等工程师排期。

开发工程师则对 AI 的态度更复杂，一方面 AI Coding 极大提升了自己的效率，另一方面看到 AI 能力这么强肯定免不了焦虑，也在思考职业生涯转型。

对此我的建议是：开发者需要从”解决问题”转向”定义问题”。不论技术职级，谁能发现并定义真正的问题，谁就能创造业务价值，也能在AI时代找到自己的位置。

二、品味的本质是判断力

很多开发者听到”产品品味”，第一反应是设计感，按钮的圆角多大、配色好不好看。但其实并不是，现在最火爆的 AI 工具，Claude Code 是 CLI 形式，审美直接回到上世纪 60 年代。

产品品味的本质是判断力。这个功能为什么要做，那个功能为什么不做？为什么先做这个后做那个？这些都需要判断，判断的背后是产品负责人的品味。

做一个产品 demo 很容易，但做一个持续迭代的软件，还是不容易的。代码的实现成本下降，更加凸显品味的重要性。

三、开发者怎么提升自己的产品品味？

下面我从自己的经验出发，谈谈自己的想法。

1、深度使用自己的产品，为结果负责

很多开发者最大的问题是自己只做产品，但不用产品。企业内部的测试平台，很可能测试覆盖率最低。稳定性平台的高可用，很可能是最差的。还有一些团队把答疑外包出去，看似省了时间，但丧失了跟用户的连接。这些站在平台视角的”答疑”，天然就是用户视角的”痛点”。

Anthropic 的做法值得参考。他们内部叫 antfooding（员工自称”ants”），每个功能先让内部工程师用，反馈频道几乎全天都有人在发消息，反馈的密度很高。

光是”用”还不够，你还要为结果负责。假如功能已经上线了，如何运营推广？如何阐述业务价值？不能再靠产品经理或Team Leader了。以终为始去思考，承担决策之后的结果。我之前也经历过这个过程，虽然很痛苦，现在回过头看，却是绕不开的成长路径。

2、学会建模，而不是堆菜单

我见过太多产品经理和开发者设计出来的产品，菜单混乱、概念模糊。混乱的背后，是对底层模型以及模型之间关系没有想清楚。好看的界面建在模糊的概念上，就像是建立在沙子上的城堡。

比如，我之前接手企业内部的成本管控平台，有一个概念叫”资源盘点人”，这个词让用户很困惑，”盘点”是动作，并不是角色属性。其实这个人是负责每个月把技术资源账单盘点给业务方，把账单算清楚。我后来把文案改成了”资源归属人”，用户一看就懂了。

一个词的改动看起来很小，但它反映的是你对业务模型的理解深度。我的做法是：把系统里所有出现的名词和动词都列出来，明确每个概念的含义和它们之间的关系。名词是实体或者属性，动词是流程或是动作，实体与实体之间是什么关系，这些想清楚了，产品结构大概率不会差。你再想想，这不就是UML吗？

3、用demo沟通需求，而不是PRD

Anthropic的产品已经从 PRD 驱动转向原型（demo）驱动。PRD描述的是静态的产品，而demo则可以有更丰富的交互呈现。尤其是，AI 产品的很多体验没法用文字描述清楚。

Anthropic的发布节奏已经从按月变成按天，除非是重大的迭代还会写PRD，普通的功能都是直接用demo来验证想法了，这也是AI时代更快速达成共识的方式。

对开发者来说，这其实是好消息。你本来就会写代码，现在又有 AI 工具加速，做原型的速度比写 PRD 还快。与其花两天写一份需求文档说服别人，不如花半天做一个可运行的原型让别人体验。原型自己会说话，而且一个能跑的原型已经证明了可行性。

4、通过写 Eval 量化品味

Cat Wu认为构建评测集（evals）是一个被严重低估的技能。我在前段时间听notebookLM的产品经理分享，Google做AI产品的产品经理也非常注重写 Evals。

为什么写eval跟产品品味有关？我认为写eval的过程，本质上是在定义”好是什么”。你得想清楚：在你的场景里，什么结果是好的，什么是勉强可以接受的，什么是不能容忍的。

很多开发者做 AI 产品时，可以很快上线一个demo，但迭代时就会遇到问题：你很难通过跑几个 case 来判断这一版比上一版更好。Eval把品味从主观判断变成了可复用的资产。你写过一次好的eval，后面每次模型升级、每次 prompt调整，都可以用同一套标准来检验。这比每次都靠人肉vibe check 高效得多。

四、多跟顶级模型讨论你的产品

最后一个建议，也是我自己最近在做的事：多找 SOTA 模型讨论你的产品思路，让它帮你出谋划策。几十刀就能”雇佣”世界顶尖的模型为你服务，这个性价比没啥好犹豫的。

同样的道理也适用于做 AI 产品：原型阶段先用最强的模型、给足Token，去验证功能的上限。确认体验是好的，再考虑用更便宜的模型优化成本。很多团队一上来就选便宜模型，但整体产品效果可能会大打折扣，甚至本身就是落后的设计。

说白了，你得用过好东西、见过好东西，才能做出来好东西。

---

本文部分观点来自 Cat Wu 在 Lenny’s Podcast 的访谈（2026年4月）。关于如何从用户行为中发现潜在需求（Latent Demand），可以参考我之前写的关于 Boris Cherny 方法论的文章。