一群产品经理、设计师和工程师挤进同一场直播。他们带着空白项目和一页需求文档进去，带着能跑通的日历应用出来。没人碰过样式表。
一场被设计好的实验
Builder办了一场工作坊，270人同时在线。每人面前是空项目、一份PDF需求文档、一个输入框。他们做的第一件事是把PDF拖进去，打一行字告诉系统要做什么。
系统读的是Google的Material Design组件库。这是关键前提——所有按钮、卡片、日期选择器都已经存在，只是被编了索引、打了标签。Builder做的不是凭空生成，是从库里调取、组装、命名变量。
六十分钟后，现场出现了一批没人计划过的功能：深色模式切换、Google Meet集成、响应式周视图。一位设计师在可视化编辑器里调了标题颜色，然后告诉系统"用设计令牌（design token），别用我刚选的那个色值"。系统照做了。
全程零行CSS。
分支是怎么长出来的
第一步，连接共享项目。Builder提前给所有人配好了Material Design 3的组件和令牌。这一步省掉了最耗时的配置地狱——版本兼容、依赖冲突、主题初始化。
第二步，贴需求文档，输提示词。系统生成一个功能分支（feature branch），里面是能跑的应用。不是原型，是真实代码，能编译、能预览、能打断点。
第三步，进入"交互模式"迭代。参会者让系统从设计系统里推荐高影响力功能，选一个，执行。有人加了拖拽改期，有人做了议程视图。每步都在实时预览里验证，不是在脑补。
第四步，点"发送PR"。系统生成拉取请求（pull request），附带完整变更摘要，按提交（commit）组织。工程师能直接把分支名拉进本地环境继续写，或者在PR里留言让Builder机器人处理——新提交几秒后推送。
「工程师读diff，检查代码质量，然后合并。」Builder的人这样描述终态。他们把时间花在需要工程判断的地方，而不是把Figma文件翻译成库里已经有的组件。
三个被验证的假设
这场实验背后有三个可检验的命题，现场数据给出了答案。
第一个假设：设计系统的完整度决定输出质量。Builder的代码生成直接依赖组件库的索引质量。库完整、文档清晰，出来的是生产级代码；从零开始，出来的是原型。没有中间态。这解释了为什么现场用Material Design——它是被验证过的完整系统，不是演示用的玩具。
第二个假设：这种方式做的原型会留在代码库里。Builder内部团队的数据是，80%的原型最终被合并进生产PR。参会者做的日历应用，理论上可以直接合进真实仓库。不是"演示完就扔"，是"演示完就上线"的流水线。
第三个假设：审查负担前置了。QA、设计、产品在工程师碰代码之前，已经在实时预览URL上完成验证。问题在便宜的时候被抓住——改提示词比改合并后的代码便宜一个数量级。
谁的工作被重新定义
产品经理过去写PRD，然后等。等设计出图，等前端还原，等测试反馈。现在PRD贴进去，六十分钟后有东西可点。反馈循环从"天"变成"分钟"。
设计师过去出规范，然后追实现。现在直接调可视化编辑器，系统把选择翻译成设计令牌。他们不是在画"应该长什么样"，是在定义"用什么令牌"。
工程师过去接需求，先配环境，再写样板代码，再调样式。现在拉分支，读diff，判断要不要合并。他们的注意力从"实现"转向"决策"——这个实现合理吗？边界情况处理了吗？性能开销能接受吗？
三方被拉进同一个代码库，用同一套设计系统，每一步都有审查和批准。不是"设计做完扔给前端"，是"三方同时在场，轮流点击"。
Material Design为什么是默认
现场没让人自带设计系统，统一用Material Design 3。这不是品牌偏好，是控制变量。Google这套系统有完整的组件库、令牌体系、无障碍规范、深色模式适配。它被索引得越彻底，Builder能调用的组合就越多。
这暴露了一个残酷事实：很多公司的"设计系统"只是组件文件夹，没有令牌、没有变体、没有使用规则。给Builder这样的工具，输出质量会暴露系统的真实成熟度。它不是魔法，是放大镜。
参会者里有人试了超出Material Design默认能力的功能——比如自定义品牌色。系统能接，但需要设计师理解令牌怎么映射。这不是降低门槛，是转移门槛：从"写CSS"转向"理解设计系统架构"。
PR里的新角色
传统流程里，PR是工程师的领地。产品经理看结果，设计师看截图，测试看用例。现在PR成了三方协作界面。
Builder生成的PR包含：变更摘要（按提交组织）、实时预览链接、设计令牌使用情况、组件调用清单。产品经理能点链接验证功能，设计师能检查令牌使用，测试能直接上手。有问题？在PR里@Builder机器人，描述要改什么，几秒后新提交上来。
「工程师可以留下评论让Builder bot处理。」原文这句话描述的不是便利功能，是权力转移。工程师从"唯一能动代码的人"变成"审查和决策的人"。
这解释了为什么现场强调"零行CSS"——不是CSS不重要，是CSS的决策被封装进设计系统了。设计师选颜色，系统翻译成令牌；开发者调布局，系统从库里取响应式组件。需要写CSS的场景被压缩到边缘情况。
80%合并率意味着什么
Builder内部数据：80%的原型进生产。这个数字需要拆解。
不是"80%的提示词直接可用"，是"经过迭代后的原型"。现场参会者平均做了3-5轮交互模式调整——加功能、改样式、调交互。系统记录每次变更，生成对应的提交历史。
也不是"80%无修改合并"，是"80%成为生产PR的一部分"。工程师仍然要读diff、做判断、可能补测试。但起点从"空白文件"变成"能跑的实现"，审查从"猜意图"变成"验结果"。
这个数字对评估工具的人很关键。演示视频里的一键生成是诱饵，真实价值在迭代速度和合并率。如果团队的设计系统不成熟，或者迭代习惯没建立，80%会暴跌。
审查前置的成本结构
传统流程的成本曲线：前期便宜（写文档），后期昂贵（改代码）。Builder模式的曲线被拉平：前期稍贵（建设计系统、配工具），但每次迭代的边际成本极低。
「QA、设计、产品都在工程师碰任何东西之前，针对实时预览URL进行验证。」这句话描述的不是并行工作，是顺序重构。发现问题时，改的是提示词或可视化编辑器的设置，不是合并后的代码。
现场有人做了深色模式切换。在传统流程里，这需要：设计师出两套规范、前端写媒体查询、测试验两种场景。在Builder模式里，是勾选Material Design的深色令牌变体，系统处理所有组件的色值映射。验证在预览链接里完成，工程师看到的PR已经包含完整实现。
工具背后的组织假设
Builder不是中立工具，它嵌入了一套组织信念：设计系统应该被代码化、三方应该共享代码库、审查应该发生在代码冻结之前。
这些信念不是普适的。有些团队的设计系统就是Sketch文件，有些公司的PM从不看代码，有些流程依赖"设计-前端-测试"的瀑布 handoff。Builder对这类组织是异物，需要改造流程才能用。
但现场270人的构成很有意思：开发者、设计师、PM各占相当比例。这不是给单一角色的工具，是给"想一起做事但不想互相等待"的团队的工具。它的竞争对手不是VS Code或Figma，是"设计评审会排到了下周三"。
Material Design的隐藏成本
统一用Google的系统，现场避开了最脏的问题：私有设计系统怎么接？
答案在原文里：「Builder的代码生成直接依赖组件库的索引质量。」索引不是自动的，需要有人把组件、令牌、变体、使用规则喂给系统。Material Design已经被Google和Builder联合索引过了，私有系统需要自己做。
这解释了为什么现场是"实验"而非"普适方案"。270人用的是预配置环境，真实团队需要投入索引工作。回报是80%合并率，成本是前期建设。这个账不是每个团队都算得过来。
但方向是清晰的：设计系统的投资回报率，正在被这类工具重新定义。过去是"减少设计不一致"，现在是"直接生成可合并代码"。ROI的计算公式变了。
下一步该试什么
如果你在看这类工具，三个问题比功能列表更重要。
你的设计系统有多"可索引"？不是有多少组件，是组件的接口是否清晰、令牌是否完整、变体是否被文档化。这是输入质量，决定输出天花板。
你的团队习惯怎么协作？如果PM从不看预览链接、设计师不碰代码仓库、工程师只接Jira ticket，工具会悬空。Builder假设三方愿意共享同一个界面。
你的迭代节奏是什么？如果需求一月一变，前期投入索引设计系统不划算。如果一周迭代三次，每次省下的翻译时间（PRD→设计→前端）会快速摊薄成本。
现场270人证明了可行性的上限。真实团队的上限，取决于设计系统成熟度和协作习惯的重叠区域。
如果你已经有一套被代码化的设计系统，下一步是挑一个内部小项目，把需求文档贴进去，计时六十分钟。看出来的东西能不能跑、能不能改、能不能进PR。这比任何评测都直接。
热门跟贴