最近一年，一个很明显的变化是：工程实现越来越快，真正拖慢团队的，开始不是“写不出来”，而是“还没想清楚该写什么”。这段题为《Designing with Claude: From prompt to production》的分享，讲的就是这个变化。Anthropic 的 Dan Carey 介绍了 Claude Design 这款产品，也顺手把他们内部的一套产品开发方法抖了出来。原视频：https://www.youtube.com/watch?v=Uvl-tRga98g
这段分享表面上在讲一个设计工具，实际上讲的是另一件更重要的事：当 Claude Code 让工程师的产能暴涨之后，产品经理、设计师和研究团队也必须拥有自己的加速器。否则，团队里最慢的那一段，很快就会从“开发”变成“判断”。
他们做的不是设计工具，而是给非工程角色补一台发动机
Dan Carey 一开始就把问题说得很直接。Claude Code 让工程师变快以后，原先六个月、一个月、一周的开发节奏，被压缩到了一天，甚至几个小时。工程不再是主要瓶颈，新的瓶颈变成：到底该做什么、怎么验证、怎么让想法尽快落地。
这也是 Claude Design 出现的背景。它并不是一个传统意义上的“设计软件替代品”。按视频里的说法，它更像是一个让人用自然语言和 Claude 一起生成可交付视觉产物的工具，产出可以是原型、演示稿、单页设计，也可以继续交给 Claude Code 往生产环境推进。
这个判断很重要。因为很多人看到这类产品，第一反应还是“AI 终于能帮我画图了”。但 Anthropic 这支团队显然不是这么想的。他们看到的不是画图效率，而是产品定义效率。工程已经快了，剩下的人如果还在写 PRD、开会、等原型、传文件，整条链路还是慢。
Anthropic Labs 的核心方法，不是高明，而是回路特别短
视频里对 Anthropic Labs 的描述很有意思：它是 frontier lab 里的一个 lab，但更准确的说法，是一个“bet factory”。小团队同时探索很多方向，快速下注，跑实验，看什么有效，再把资源压到有效的方向上。
这套方法本身不新。Dan Carey 也直说了，它和 Lean Startup 没有什么本质上的神秘差别。真正的区别在于速度。他们会每天和用户交流，也会每天和研究员交流。前者用来听抱怨，后者用来听“最近什么东西让你意外”。在他们看来，这两类信息都很值钱，因为抱怨常常意味着需求，惊讶常常意味着新的产品机会。
更狠的是，他们希望几乎每天都把变化发到用户手里。用户今天提了意见，团队最好今天或者明天就回一个版本。整个 Claude Design 项目 10 周里，这样的“ship → watch → learn”回路，大概跑了 50 到 100 次。
这件事单独看只是勤快，放到产品方法论里看，就不是了。它说明他们根本不想靠前置规划预测未来，而是靠高频试错逼近正确答案。
他们刻意不写那些“大公司正确动作”
分享里最刺耳、也最值得反复咀嚼的一段，是他列举他们没做什么：
- 没有先写 PRD
- 没有 vision doc
- 没有 OKR 会议
- 没有年度 staffing plan
- 没有两年路线图
- 没有先写 press release
他不是说这些东西永远没用。他的前提是：在你还不知道自己到底要造什么的时候，这些文档的价值很低。因为文档太容易制造一种“我们已经想清楚了”的幻觉。
他给出的替代方案很朴素：先做出能玩的原型。文档是抽象的，原型是具体的。两个人看同一份文档，很可能脑子里是两个产品；两个人用同一个原型，讨论的才是同一件东西。
这和你知识库里前两天沉淀的几篇笔记是能对上的。
一篇讲 Claude skill 的文章，把 skill 定义成“可阅读的程序性记忆”，重点不是 prompt 多漂亮，而是怎么把做事方式稳定下来。另一篇 Anthropic 工程师配置笔记，核心也是类似的：不要把 AI 当聊天机器人，而要把它嵌进 workflow 里，把 CLAUDE.md、skills、fresh session、review 分工这些东西变成系统。再加上那篇“Claude 11 经验”，主判断同样是：能力提升不是来自某一句 prompt，而是来自围绕模型搭系统。
这次视频讲的，其实是同一个思想在产品设计链路里的展开版：当上下文、原型、handoff、反馈分析都被模型吃进去以后，组织里的很多“信息传输损耗”就开始下降了。
Claude Design 的起点很小，小到只有一个周末原型
Claude Design 不是从战略规划里长出来的，而是从一个设计师的周末 hack 长出来的。视频里说得很清楚：Nate 之前做过 Claude Code 相关工作，亲眼见过工程团队变快以后，其他角色怎么被拖在后面。于是他用一个周末，拿 agent SDK、一个很薄的 IDE wrapper，再加一个已有 skill，拼出了最早的版本。
这很像 Labs 的典型起手式：
- 一个人
- 一个周末
- 一个 screen recording
不是先立项，而是先把一点“魔法感”做出来，再丢到团队里看反应。Slack 里大家一边说哪里有希望，一边说哪里完全不能用。最初几周，他们做的事也不是全面展开，而是挑出哪些地方值得继续押注，哪些问题必须先修。
我觉得这里最值钱的一句，不是“快”，而是“只需要先看到一点 promise”。他们并不要求早期原型已经完整、稳定、可规模化。它只要能证明一件事：这个方向也许是对的。
原型不是交付物，而是团队内部的思考接口
视频里有个细节很有启发。Dan Carey 说，过去自己写了快二十年 PRD，现在很多时候直接不写了，改成先和同事聊，把录音转写成 transcript，再把 transcript 丢给 Claude Design，让它先给几个原型方向。
这里的重点不是“AI 代写原型”，而是把“模糊问题”先压成一个能讨论的具体物。你不必一开始就说清楚按钮在哪、页面怎么排。你只要能说清楚：
- 你想解决什么问题
- 为什么这件事值得解决
- 一个好解法应该有什么特征
剩下那一段，把抽象意图翻成可见界面，Claude 可以先帮你做第一层。这相当于把产品经理的思考出口，从文档改成了原型。
这也是他们在内部 pitch-off 里真正被说服的地方。最开始大家还只是口头讲想法，后面很快就变成：会议下半场的提案，几乎全是现场用 Claude Design 做出来的 slides 和 prototypes。不是因为设计精度已经完美，而是因为讨论效率一下子高了。
三个人的团队为什么能做十周上线
Claude Design 大部分开发阶段，团队只有三个人。视频里他说得很干脆：好在 Claude 也是个不错的 team member。
但这句话背后不是玩笑，而是一种组织假设：每个人都得能做更多跨角色的事。
- 工程师要能去聊用户
- PM 要能写代码
- 设计师要能做分析
Claude 把很多以前需要专门角色才能启动的动作，降成了“任何人都可以先做第一步”。这样一来，团队里角色边界不是消失了，而是软化了。你还是有专长，但你不必在每个环节都等别人接球。
这直接降低了协调成本。很多功能可以一个人从发现问题、设计方案、做到发给用户试用，整个过程独立跑完。实在需要三个人对齐，也只是和左右两边的人讲清楚，而不是发起一次正式 alignment meeting。
这件事听起来像“创业团队老生常谈”，但 Claude 在这里起到的作用，是把“全栈型产品成员”的门槛拉低了。
他们优化的不是某一个工具，而是整条迭代链路
这场分享另一个值得记的点，是他们不是只做了一个对外产品，而是顺手把内部回路一段段都自动化了。
比如用户反馈。
他们本来就会每天和用户聊，但后来又把 Claude 拉进这些对话之后的分析环节：
- 看多个用户对话里有没有共性
- 做第一轮归因和问题归类
- 把人工原本要做的初筛、初查、初分析先跑一遍
他们没有让 Claude 代替人与用户交流，但让 Claude 代替了大量反馈整理工作。
再比如设计分享。
最开始他们用 Claude Code 做完原型，只能录视频，或者让同事拉 branch 自己跑。后来 Claude Design 自己变成了分享和协作界面，于是“我做了个东西，你要不要试一下”这件事变轻了很多。多人协作能力，也是他们在自己使用过程中逼出来的。
再比如 handoff 到 Claude Code。
一开始要把设计导出来，再导进 Claude Code，再把多轮上下文重新补一遍，过程很慢。于是他们把 handoff 变成产品内一等能力。这个动作不是从市场需求清单里来的，而是从“我们自己嫌麻烦”来的。
再比如反馈聚类工具。
他们发现反馈太多，一个人根本读不过来，就在一个下午里做了自己的 clustering tool。也就是说，很多所谓“流程问题”，在他们那里不会被视为一个长期等待的组织议题，而会被视为一个值得马上写掉的内部工具缺口。
这也是我从这段视频里看到的核心：他们不是在用 AI 优化某一步，而是在持续压缩整条 loop 里的摩擦。
快不是因为总是对，而是因为改错足够便宜
视频里专门讲了一个做错的例子。早期他们做过一套很高级的精细控制，面向 power users，几个核心测试用户也很喜欢，于是团队一度以为方向对了。结果看使用数据发现，除了那几个重度用户之外，其他人几乎都讨厌这个东西，觉得复杂、困惑、甚至伤害产品体验。
所以他们一周之内就把它砍掉了。
这段很重要。因为很多团队谈“快速迭代”，最后还是掉进另一种幻觉：以为快意味着少犯错。Anthropic 这边给出的答案更现实：快的价值，不是保证你总是对，而是保证你一旦错了，不会错一个季度。
Claude Design 整个产品 10 周上线，如果中间有一项关键判断错上一个季度，这个产品基本就废了。高频迭代的真正意义，是把错误控制在小周期内暴露和回收。
他们最后想做的是开放工具，而不是封闭工作台
那个失败案例还带出另一个判断：Claude Design 不该只是少数高手的精细操作台，而应该是让更多人整体提高 craft 水平的工具。
所以他们最后选择更开放的路线。
视频里提到几点：
- 导出给用户的是 HTML、CSS、JavaScript
- 会做更多和其他工具的集成
- 未来希望任何设计工具都能通过现有 MCP 接到 Claude Design / Claude Code 的链路里
这说明他们并不想把它做成一个所有人都必须困在里面的闭环系统，而是把它当作一个前端探索和生产衔接层。对普通人来说，它应该足够简单；对重度用户来说，它又应该足够开放，允许你把成果带走、接进自己的工具栈里。
这个方向和你知识库里沉淀的 MCP、skills、agent workflow 其实是一条线上的：真正值钱的，不是单点功能，而是能不能接进别人的工作流里，成为更大系统的一个可编排节点。
最反常识的一点：先做“差一点能成”的东西
我最喜欢的是最后这部分。Dan Carey 说，一个反直觉经验是：不要优先做那个今天已经完全可行的东西，而要多盯着“差一点就能成”的东西。
原因很简单，模型能力还在涨。你今天解决不了的问题，未必需要你用更聪明的工程办法去硬啃，下一代模型可能直接把其中一半问题抹平。
Claude Design 早期原型里有一堆问题，最后并不是靠什么惊人的工程技巧逐一修掉的，而是新模型出来以后，很多原先不够好的地方自然变好了。视频里甚至直接举了一个例子：他们有些问题，最终是靠 Opus 4.7 的发布解决的。
这背后的判断非常像现在做 agent、做 AI 产品最关键的一条经验：早期别把主要精力花在打磨局部 edge case 上，而要先抓住那个“如果模型再涨一截，这个产品就会突然成立”的结构机会。
说白了，你找的不是一个今天已经百分之百成立的流程，而是一个已经出现魔法感、并且模型进步会继续放大的方向。
这段分享给普通团队最有用的三条建议
视频结尾给了三个非常具体的动作，我觉得都值得记下来。
第一，下一次想写 PRD 时，先别急着写。先和 Claude、和同事把问题聊透，把 transcript 交给 Claude 做三个原型方向。重点不是描述按钮，而是描述问题和好解法的特征。
第二，挑一件你一直在等别人帮你解决的内部工具问题，用一个下午先做出来。可能是反馈聚类，可能是分析工具，可能是别的。别再把内部工具当成遥远项目。
第三，拿一个真实用户请求，试着在 24 小时内做出可看的版本再回给他。这样做的意义不只是追求更快，而是把你流程里所有真实的障碍逼出来：部署慢、评审慢、上下文传递慢、职责边界卡住，都会立刻暴露。
我的看法
这段视频最值得看的，不是 Claude Design 这个产品本身，而是它背后那种很完整的产品组织观。
以前很多团队说“AI 提效”，理解还停留在让工程师写代码快一点。但这场分享已经把问题推到下一层了：当工程端先被提速后，设计、产品、反馈分析、协作交接、内部工具这些环节，如果还按老节奏走，整条链路依旧快不起来。
所以 Claude Design 真正命中的，不是“AI 做设计”这个表层需求，而是“非工程角色也需要一台和 Claude Code 对称的加速器”。
从这个角度看，这个标题里的 from prompt to production 也可以换一种理解。它不是单指一个设计稿如何进生产，而是在说：从最初模糊意图，到原型，到反馈，到迭代，再到正式交付，这整条链路都在被重写。
如果把这段分享压成一句话，我会这样说：AI 时代真正拉开差距的，不是谁更会写 prompt，而是谁能把组织里的判断回路、原型回路和反馈回路压得更短。
我的补充
这套方法当然不是放之四海而皆准。
如果你做的是硬件、重合规系统、强审批流程、或者跨十几个团队的大项目，Anthropic 这种三个人十周起飞的节奏，不可能原样照搬。视频里他们自己也说了，这未必是适合所有人的 loop。
但它至少说明了一件事：很多团队今天的问题，已经不是缺方法论，而是默认把太多中间环节当成不可压缩。PRD 必须长、对齐必须多、handoff 必须靠人肉、反馈整理必须靠专人，这些假设正在一条条失效。
所以更现实的做法，不是迷信“全盘照抄 Anthropic”，而是先问自己：
- 我们链路里最慢的是哪一段
- 那一段到底是本质上慢，还是习惯上慢
- 有没有可能先用一个很粗糙、但能跑的 AI 工具，把那一段先缩短一半
很多时候，真正值得做的，不是再优化工程师写代码的最后 20%，而是把工程之外那些一直没人动过的摩擦面，第一次系统性削掉。