氛围编程的后遗症
作者：Sabrina Albert, Vivek Ramaswami (Madrona) | 来源：SandHill.io #283
在一个任何人都可以发布任何东西的世界里，产品品味和设计工艺成为了关键的护城河。
AI 让发布产品变得比以往任何时候都容易，这并不令人惊讶。如果你问任何一位创始人或产品经理（PM）在过去十八个月里他们的工作最大的变化是什么，你都会听到某个版本的同一个答案：我们现在发布的速度快多了。最优秀的工程师也会说同样的话。工程师的效率提高了 10 倍，非技术背景的 PM 甚至在自己编写功能代码。将产品呈现给用户的门槛已经崩塌。
由此得出的自然假设是，如果每个人都能更快地发布产品，那么谁发布得最快谁就赢了。将更多代码倾注到生产环境中，更快地迭代，在功能上超越竞争对手。速度就是战略。虽然这在过去确实是一种假设，但我们认为，单靠这一点将无法成为未来的制胜战略。当整个行业的发布速度趋于平同时，瓶颈并没有消失，而是转移了。
我们预计，这种转变将指向拥有深刻的产品理解力。大多数团队并没有准备好很好地回答这个问题，而解决这个问题的公司将拥有持久的优势。那些没有解决这个问题的公司，将会非常迅速地发布大量平庸的产品。
速度现在只是准入门槛
Cursor 的付费用户已突破 100 万。Claude Code 正被各种规模公司的工程团队使用。非工程师正在提交生产代码。结果是发布的“功能供应量”呈爆炸式增长，但用户的注意力和用户的喜爱程度并没有成比例地扩大。世界上的产品变多了，人们对糟糕的东西或“AI 垃圾（AI slop）”的耐心却变少了。
当每个竞争对手都能在一个周末内启动一个工作原型时，功能列表就不再是差异化因素。将人们实际使用的产品与他们只尝试一次的产品区分开来的，是比技术栈更难复制的东西。
这个抽象的概念可以定义为品味（Taste）。这是一种对用户在产品中需要什么的真实的、发展完善的观点。不仅仅是他们要求什么，而是他们实际上想要什么、以什么形式、在什么时刻。这种判断力无法通过提示词生成。它必须被培养出来，并且必须存在于组织内部的某个地方。
当每个人都能构建产品时，问题不再是“你能发布它吗？” 问题变成了“你应该发布它吗？以什么形式发布？”
非确定性系统打破了所有旧规则
传统软件有一个简单的设计契约：用户采取行动 → 系统产生可预测的输出。点击按钮返回一个结果。提交表单记录一条数据。查询从数据库返回一行。产品设计师和 PM 花了三十年的时间在这个契约内进行优化。输出是固定的；工作就是让通往输出的路径尽可能清晰和顺畅。
AI 系统完全打破了这个契约。输出几乎可以是任何东西。每次用户查询 AI 产品时，模型都必须直觉地判断他们的意思——而产品必须预先决定输出甚至应该是什么样子。这个决定不会自动发生。必须有人为产品中每一个有意义的交互表面预先、明确地做出决定。Linear 的 CEO Karri Saarinen 很好地阐述了这一点：
“设计的困难部分在于，你要对问题有足够深入的理解，才能知道什么东西应该存在，以及应该如何存在……风险在于仅仅生成了形式，就误以为问题已经解决。”
你现在可以在一个下午启动一个工作界面。但这并不等同于思考了这是否是解决该问题的正确界面。AI 使得产品想法的执行变得异常便宜。它使得关于构建什么以及如何呈现它的决策变得比以往任何时候都更加重要。非确定性不仅仅是这些系统的一个技术属性——它是一个必须被刻意解决的产品设计挑战，否则它将被偶然地解决，而且通常解决得很糟糕。
涌现出的新产品问题
在许多方面，AI 产品拥有以前的软件从未有过的东西：个性。它们不仅仅是回应，它们还在解释、推断和发展自己的声音。这令人兴奋，但也引入了一系列新的产品设计挑战：
一些在这方面思考深刻的公司：
Linear 是如何在实践中实现这一点的最清晰的公开阐述者。他们没有构建一个对话优先的界面并在其上叠加结构，而是构建了一个功能齐全的应用程序，然后将 AI 融入其中。
Harvey 深入探讨了在高风险垂直领域“信任”应该是什么样子。Harvey 的设计团队将透明度构建到了产品的核心：每一个推理步骤都被展现出来，每一次引用都是可审计的。
- Cursor 围绕着一个单一问题构建了它的产品：什么时候建议 vs. 什么时候提问——什么时候自动完成 vs. 什么时候暂停。
结论
在氛围编程（vibe coding）时代的风险，正是错把输出当成了设计。你可以发布很多东西，但这并不等同于以正确的形式、带着正确的护栏发布正确的东西。
在一家 AI 优先的公司里，PM 和产品职能变得更加重要。有人必须对 AI 的输出形式有独到的、具体的见解。这种直觉越来越成为将人们每天使用的产品与他们演示一次就忘记的产品区分开来的东西。
