当原型可以搜索、提交和显示结果，产品评审会更像一次真实使用。它也带来一种新风险：大家很容易因为页面运行顺畅，就跳过更重要的问题——用户是否因此更容易完成任务？
Figma 在 11 月 4 日发布的工作流示例中，将现有代码、Agent 生成的方案和团队讨论放到同一画布。代码让设计更容易被体验。接下来，团队需要决定用这份原型证明什么，以及证明到哪一步值得继续投入。
第一轮评审，应当帮助团队做出选择
设想团队要改进地址填写。用户究竟是找不到地址、不会选择搜索结果，还是选对之后不敢确认？三个问题可能需要不同方案。若一开始就让 Agent 生成完整表单，团队会得到很多界面，却未必知道应该解决哪个障碍。
更有效的起点，是先选一个需要回答的问题。例如，用户能否区分名称相同、位置不同的地址？原型只需让人完成这项选择，再观察他依据什么判断，在哪里犹豫。
这会改变对“完成”的理解。一份原型即使没有接通全部服务，只要帮助团队排除了错误方向，就产生了价值。相反，完整页面若只是让同事确认“看着不错”，仍没有减少产品决策的不确定性。
第二轮才把交互承诺接到业务结果
方向选定后，再检查真实数据如何变化。用户选中一个地址，修改门牌后提交，最终保存的是哪一份？断网重试后，会不会产生两条订单？此时，画面中的反馈要与服务端的结果一起观察。
这两轮投入应当有所区别。前一轮追求低成本比较方案，后一轮追求可信的行为。过早补齐全部接口，会为尚未选定的方向花费开发时间；一直停留在模拟数据，又可能让关键问题推迟到上线前。
评审可以采用三个明确的结论：保留这个方向、继续验证这个假设、准备进入开发。每个结论对应不同材料。方向需要使用反馈，假设需要可重复的任务，开发交接则需要代码版本和已确认的行为。
这样，设计师不必为每次探索背上完整实现的负担，研发也能知道哪些决定已经成立，哪些仍然可以改变。
一项改动也可以有停止投入的条件。如果用户仍然无法辨认正确地址，就先修改信息呈现，而非继续补齐支付或登录。原型帮助团队减少无效开发，靠的是及时改变投入方向。
共享运行环境，让反馈真正落到同一个对象
代码原型的协作还有一个容易被忽略的条件：大家是否在体验同一份东西？依赖、演示数据和代码版本变化后，同一个链接可能呈现不同结果，昨天的讨论也就失去了明确对象。
在需要自行运行原型时，PPIO 沙箱提供独立运行环境，支持安装依赖、执行代码与浏览器工作流。团队可以固定一份代码和数据，生成共同访问的预览，再从选定版本继续修改。
这种环境最有价值的用途，是降低比较成本。两个地址选择方案可以使用同一组数据，测试失败路径时也能回到一致的起点。原型不再只由截图保留，而是成为能继续操作、修改和复查的工作材料。
速度的价值，在于更早放弃错误方向
生成工具缩短了做出一个页面的时间，团队便更有条件尝试不同方案。但尝试次数多，并不会自动带来更好的决定。每个方案都需要对应一个真实问题，否则更多原型只会带来更多评审。
可以在评审结束时回答三个问题：这次改变了哪项决定，依据是什么，下一笔开发投入用来解决什么。它们让快速探索与正式开发接在一起，也能避免把“生成得快”误当作“产品已经成熟”。
Figma 让团队更容易围绕可运行的设计交流。真正值得保留的工作方式，是让每一次运行都减少一点不确定性，让下一位接手者能够直接使用已经得到的答案。