根据Anthropic Labs产品经理Dan Carey的演讲整理
Claude Code上线后，工程师的产出速度快了一个量级。以前一周才能完成的功能，现在几个小时就能推到用户面前。开发周期从六个月压缩到一个月，再到一周，再到一天。
但瓶颈也转移了。以前瓶颈是"能不能做出来"，现在瓶颈变成了"该做什么"。设计师和产品经理跟不上工程师的节奏了。他们需要自己的加速工具。
所以Claude Design诞生了。不是经过市场调研、战略规划和年度立项才启动的。是团队里一个叫Nate的设计师在一个周末随手搭了个原型——用Agent SDK、一个极简IDE外壳，加上他在Claude Code里用过的Skill——发到Slack里，大家看完说"这个有意思，但这些地方完全不行，赶紧修"，然后他就开始修了。
这就是Anthropic Labs的日常运作方式。
Labs是一个"下注工厂"
Anthropic Labs是Anthropic内部的一个小团队，Dan Carey称它为"bet factory"。十几个小组同时探索不同的概念，大部分项目会在早期被砍掉，只有少数高确信度的项目会被推向市场。
Claude Code、Claude Design、MCP、Skills、Chrome插件、免提语音，都从这里出来。
他们的方法论和精益创业很像，唯一的区别是循环速度。他们每天接触用户和研究人员，每天或每两天就给用户发一次新东西。用户提了反馈，他们争取当天或第二天就给出回应。Claude Design在10周开发周期里跑了50到100轮迭代。
他们不做未来预测。不写"十年后技术会怎样"的愿景文档。他们的逻辑是：发出去，看用户怎么用，学，再发，再看，再学。循环本身比任何规划都可靠。
不写PRD，用原型说话
这个团队没有为Claude Design写PRD。没有愿景文档。没有KR会议。没有年度人力计划。没有提前写新闻稿。他们知道的是手里有一个值得追的火花，但不知道最终产品长什么样。
Dan Carey做了近二十年产品经理，过去一直在写PRD。现在他换了一种方式：找同事聊问题，录音转文字，讨论核心问题是什么、好的解决方案应该具备什么特征、为什么这个问题值得解决。然后把这段文字丢给Claude Design，让它出几个原型方案。
文档的问题是不精确。两个人看同一份文档，脑子里会出现两种不同的产品，而且都和作者想的不一样。原型更直接。你摸得到，能操作，能立刻判断这个方向对不对。
他们的原型周期后来压缩到了几分钟。有想法，录一段对话，给Claude，几分钟就能看到几个方案。
团队内部还有个叫"pitch-off"的仪式。大家凑在一起头脑风暴，试图说服别人来一起做自己的项目。第一次用Claude Design做pitch-off的时候，会议进行到一半，所有人的演示全都变成了用Claude Design现场做的原型和幻灯片。那个瞬间让他们确信：这个产品值得推。
3人团队，角色边界消失
Claude Design大部分开发时间只有3个人。临近发布前扩充到5人。在这个规模下，每个人的角色边界几乎不存在了。工程师跟用户聊，产品经理写代码，设计师做数据分析。
不是没有专业分工，而是每个人都能独立完成从跟用户沟通、理解问题、设计方案、发布代码到收集反馈的完整循环。大多数功能就是这样一个人独立完成的。
协调成本也几乎为零。三个人对齐想法，转个身说几句话就行。不需要排会议、等日程、走流程。
每个环节都要优化
他们的迭代循环很基础：跟用户聊、设计功能、发代码、读反馈，然后重复。重点是把这个循环里的每一步都做到最快，因为你跑50到100轮，每一步省下半小时，累积起来就是几十个小时。
几个具体做法：
跟用户聊。他们和每个使用者建Slack共享频道，大量内部dogfooding。然后让Claude分析所有对话，找出不同用户提出的相同建议，做初步的问题归类和分析。人仍然负责对话本身，但后续分析交给Claude。
设计功能。他们用Claude Design来设计Claude Design。这是最高效的开发者工具使用场景——用自己的工具改进自己的工具。代码库探索、GitHub集成、多人协作，都是因为他们自己在用，觉得哪里卡手了就改哪里。多人协作功能最初就是为了解决"我改完给你看，你说要改，我再改一遍"的低效流程，做出来后发现用户第一个要求就是实时协作。
发代码。他们设计了从Claude Design一键交接给Claude Code的功能。早期流程是导出文件、导入Claude Code、手动输入对话上下文，很慢。优化后一键交接，用户拿到产品的第一个问题也是"怎么上生产环境"。
读反馈。发布后反馈量大到一个人看不过来。他们花了一个下午做了个反馈聚类工具，让Claude自动分析所有反馈、匹配系统日志、识别共性趋势、初步判断是否是bug、给出修复建议，然后一键推到开发工具里。
做错了就在一周内改掉
他们不是每次都对。早期版本加了一套高级精细控制功能，几个核心用户非常喜欢，他们就以为做对了。但看数据发现其他用户非常讨厌这套东西——不是不喜欢，是讨厌，因为复杂、让人困惑，甚至伤害了产品体验。
他们把它删了。从发现错误到删掉功能再继续往下走，总共用了一周时间。
如果这是一个季度的开发周期，他们就浪费了一个季度。但整个产品从想法到上线也不到一个季度。快速迭代的核心价值不是快，而是能在一周内发现自己错了并改过来。
这次教训让他们明确了两个方向：产品应该提升所有人的水平，而不是只给高级用户加天花板；产品应该尽量开放，导出HTML/CSS/JavaScript，让有专业需求的用户可以把设计导入到其他工具里。他们还在通过MCP接口让任何设计工具都能接入Claude Design，这个功能即将上线。
不要做已经能跑的东西，去做差一点就能跑的东西
这是他们在Labs学到的最反直觉的一点。不要去做已经完全能工作的东西，去做那些差一点就能工作的东西。因为模型在快速进化。下一版模型可能就直接修好了你靠工程手段解决不了的问题。
Claude Design早期原型里有一堆问题，他们没有用巧妙的工程方法修好，也没有靠什么精妙洞察。Opus 4.7发布后，这些问题自然消失了。
模型发布是潮水，涨潮的时候所有船都会浮起来。早期只要找到那一点点魔法的苗头就行，不需要它能处理所有边界情况。找到苗头就开始探索、开始做、开始拿给用户看。产品的形态是最重要的东西，而所有人一开始几乎都会搞错形态，必须靠迭代来修正。
三个可以明天就试的建议
下次写PRD之前，跳过它。跟同事聊问题本身而不是具体功能，录音转文字，给Claude看，让它出三个原型方案。
选一个你等了很久的内部工具——比如反馈聚类、新的分析面板——花一个下午自己做出来。现在的内部工具开发速度足够快，等别人不如自己写。
拿一个真实用户的需求，24小时内给出响应。不是修个边距bug，是一个真正的功能需求。24小时可能做不到完整上线，但要把想法推到用户面前并跟进反馈。这样试一次，你会发现自己现有的流程里有多少阻碍——部署方式、代码审查流程、沟通链路。不试一次，你不会看到这些阻碍。
不用三件事一起做。一个一个加上去，每件事会教给你不同的东西。
上线后的数据
Claude Design周五上线，到下周一已经推了62个改进。token效率、图片处理能力、代码库探索、导出速度，全部来自上线当天的用户反馈。这不需要团队熬夜，因为10周以来每天迭代已经成了肌肉记忆。
产品上线一个月后，他们把所有订阅方案的token额度翻了一倍——原因很简单，用户说用得不够，想多用。