从 Claude Code 看 AI-Native 产品设计

这种不同，我认为可以归结为两个核心的范式转移：

• 原型先行、设计后置： 产研协作方式从「PRD驱动、设计先行」的蓝图式开发，转向「先做原型验证效果、再看看怎么设计UI」的灵活开发，一种「先开枪，后瞄准」的产品哲学。

• 角色融合，人人开发：传统的产品研发设计测试的职能分工正在被打破，所有人都是 Builder。工程师有想法可以直接做出原型落地，产品经理和产品经理也可以直接通过 Claude Code 直接动手修改代码。

Claude Code 是如何设计和迭代产品的？原型先行，设计后置

在移动互联网的黄金时代，我们习惯于线性的、职责分明的开发流程：产品经理制定详尽的需求文档（PRD），设计师据此绘制高保真原型与视觉稿，工程师再进行工程实现。这是一个经典的、环环相扣的链条，稳定而可靠，但也意味着每一步都牵一发而动全身。

然而，Claude Code 的工作流彻底颠覆了这一点，它更像一个有机的、自下而上涌现的生态系统。

首先，是小团队驱动的快速原型。

Claude Code 核心团队规模非常小，通常一个新功能的火花不是等产品经理的灵光一现，而是由一两个工程师提出并迅速制作出原型。这个原型并不追求完美的交互或视觉，而是聚焦于核心功能和产品价值。

就像是在战场上，一支突击队快速穿插，直捣核心——目标明确，不恋战。

这可能是最关键、最难、也最容易被忽略的一步，对团队单兵能力、协同能力的要求极高。

接着，是全员内测验证价值。

原型一旦完成，便会立刻部署给 Anthropic 全员在日常工作中使用，让产品的创造者同时成为了最挑剔的用户。

因为深度浸淫在产品场景中，他们能提供最真实、也最关键的反馈。一个功能是否具备真正的生命力，在这个内部生态中将得到最快的检验——只有在内部被验证是有效、好用的功能，才会被正式产品化。

这一步的前提是团队本身就是产品的目标和深度用户。

最后，才是设计后期的点睛之笔。

只有当一个功能被内部证明“行之有效”后，才会进行用户体验（UX）的打磨和优化。

这时，设计师的角色才真正介入。设计不再是开发的「上游」，而是在功能价值被验证后，为其进行后期制作的环节。设计师和团队会一起思考，如何通过打磨用户体验和界面，让这个已经被验证的功能变得更加好用和优雅。

这一步可能对大部分习惯了移动互联网开发范式的团体（尤其是设计师）来说，是最「反直觉」和「不适」的。对这个原则能否达成充分共识，是实际执行成本和最终效果的关键。

有一个值得跟设计师强调的点是：这并非意味着设计被降级，恰恰相反，它让设计回归了本质。比如 Claude Code 的设计师就提出了这样的原则：

• 界面简洁： 命令行界面（CLI）空间有限，设计必须克制，以帮助用户专注于核心任务，而非被繁杂的界面分散精力。

• 模型为王： 设计的终极目标，是用最薄、最透明的“包装”，让用户能最直接地感受到 Claude 模型本身强大的能力——这一点非常关键，和 Agent 工程架构设计原则是不谋而合的。

看了 Claude Code 团队的介绍，我也结合过去一年的探索，总结了一下 AI 产品的迭代范式和传统移动互联网的差异，道理可能很简单，背后却是很多坑和泪（以后有机会可以展开讲讲）：

读到这里，有人可能会说了：这不就是互联网经典方法论「MVP」、「Eat Your Own Dog Food」、「设计服务于功能」嘛？所谓 AI-Native 产品方法论，不就是回归到任何一个技术浪潮早期要坚持敏捷迭代、快速行动的老一套嘛……

怎么说呢……首先，警惕所有一看到新技术新事物就说「这不就是」的人吧。

当然，更重要的问题是：如果真的是经典复兴，那为什么我们很少在其他团队观察到类似现象——只有 Claude Code 在过去几个月用令人瞠目的「迭代速度」创造了史上ARR 增长最快的产品？

用过 Claude Code 的都知道他们更新速度有多快，比迭代更快的是收入增长：Claude Code 2025 年 5 月上线，3 个月内用户增长超10倍，ARR突破5亿美元。作为对比，Cursor 花了 6-9个月才从零冲到1亿美元ARR，Lovable 用8个月实现1亿美元ARR。

这就涉及到背后的人和团队协作了，毕竟流程好改，本性难移。

Claude Code 团队是如何协作开发的？角色融合，人人开发

在 Claude Code 的团队中，工程师、设计师和产品经理之间的界限，正在变得模糊和流动。

工程师被赋予了更大的创造自主权，成为了名副其实的「产品工程师」。任何一个闪光的想法，都能被迅速转化为原型，直接接受用户群体的检验，无需等待冗长的排期与审批。

而设计师和产品经理，也正在演变为「设计工程师」。他们手中的核心工具，不再局限于 PRD 文档、 Figma 或 Axure，Claude Code 本身，成为了他们将想法注入产品的有力杠杆。

你也许和我一样好奇，Claude Code 的设计师和产品经理是怎么用他们自己的产品的？

Meaghan 在访谈中就分享了她作为设计师，如何用 Claude Code 拓展自己的能力边界：

• 产品设计阶段：与 AI 成为创意共鸣者。 在构思新功能时，她会直接与 Cloud Code 对话，探讨“常见用例”、“边缘情况”，甚至寻求设计的初步建议。AI 在此成为了一个永不疲倦、知识渊博的思考伙伴。

• 方案评估阶段：获得量化的决策依据。 当设计稿完成后，她可以将图片直接展示给 Cloud Code，并询问实现它所需的大致工作量。这让设计师在与工程师的沟通中，拥有了更坚实的工程学依据。（哈哈哈太鸡贼了……

• 产品发布前夜：亲自上手改代码，捍卫体验的“最后一公里”。 这是最颠覆的一点。在传统流程中，那些优先级不高（P2 级别）的视觉瑕疵或体验微调，常因资源紧张而在上线前被无奈妥协。而现在，设计师可以亲自进入生产环境的代码中，修复和优化这些细节，亲手打磨好产品的最终品质。

这不仅是效率的飞跃，更是一场关乎“创造”本身的变革。它意味着，拥有产品洞察和设计审美的人，第一次可以如此顺畅地将自己的构想直接注入最终产品，极大地缩短了从想法到实现的路径。

这对 AI Native 团队意味着什么？

我觉得至少有 2 个点是值得探索（以及更重要的，磨合）的：

1. 重新思考协作模式

产品开发中的角色边界正在变得更加流动：设计师可以实现前端细节，PM 可以直接验证技术可行性，工程师能更深度地参与设计决策。这不是角色的消失，而是协作的深化。

2. 建立新的团队文化

鼓励研发更多做 Demo 快速验证；为设计师和 PM 提供学习 Claude Code/ Cursor的支持（比如搞定该死的代码环境配置）；建立清晰的代码审查规范与边界；

当然，最重要也最难的是，从文化上打破边界，鼓励跨职能的学习与协作。

结语

Vibe Coding 的兴起让编程/做原型不再成为壁垒，似乎产品设计/迭代也变得更容易了，毕竟PRD、代码，甚至设计稿都能让 AI 写了……

其实很可能不是，实际情况是问题转移了，甚至更难了。

嗯……这么说：

作为产品经理，我过去一年已经很少写 PRD，每次跟人提到这，对方都会惊讶：「啊，产品经理不写 PRD 也太轻松了吧？」「真就一句话需求？」

虽然我很难不同意写 PRD 很辛苦，但我总是很认真地说：

确实对过程性的东西要求更少了，但对结果的要求更高了。有点回到这个岗位最开始的含义了：产品经理是要对产品负责的。