00:00:00旧的构建流程中有一层已经不复存在了。
00:00:03大多数团队还没搞清楚该用什么来取代它，所以他们仍凭着
00:00:06肌肉记忆运行着旧的那一套。
00:00:08本周，Jenny Wen 在 Lenny 的播客上发布了一段访谈。
00:00:11她是 Anthropic 公司 Claude 的设计负责人，此前曾担任 Figma 的
00:00:16设计总监。
00:00:17在节目中，她谈到了设计流程如何“已死”，以及究竟是什么
00:00:21正在取代它。
00:00:22所以我们要剖析发生了什么变化、原因何在，然后逐步演示
00:00:26取代它的具体流程。
00:00:27要理解是什么取代了它，你必须先理解它为什么存在。
00:00:31在旧流程中，你会先定义需求，然后设计师会把这些需求带入
00:00:35Figma，制作出应用预期外观的模型。
00:00:38那个 Figma 文件就是需求方与开发实现之间的交付文档。
00:00:43接着，前端工程师会把那个文件转换成代码。
00:00:46与此同时，后端工程师也在并行开发，因为 API 规范
00:00:51已预先定义，所以双方可以同步推进，最后汇合衔接。
00:00:55Jenny 将其描述为设计师视如“仪式”般的流程。
00:00:58这曾是整个行业的标准。
00:01:00大多数解释其变化的人，都忽视了它最初存在的原因。
00:01:05Simon Willison 是一位开发者，他撰写着该领域阅读量最高的
00:01:09技术博客之一。他在一月记录了 Jenny 在柏林的演讲，并补充了
00:01:14她演讲中暗示但未明说的见解。
00:01:16利用 AI 构建产品，显著降低了“造错东西”的成本。
00:01:19在 AI 出现之前，方向性错误意味着数月的工程时间浪费。
00:01:23前端的一个小错误，在实施过程中可能意味着 10 倍的工作量。
00:01:27因此，团队必须为每一步辩护。
00:01:28研究、画像、用户旅程、线框图、需求文档。
00:01:33这一切都是为了防止大规模地构建错误的东西。
00:01:36那么，流程中到底改变了什么？
00:01:38首先改变的是工程速度。
00:01:40它的变化速度超出了大多数人的反应速度。
00:01:42Jenny 说几年前，她作为设计师有 60% 到 70% 的时间花在模型和原型上。
00:01:48现在这个比例是 30% 到 40%。
00:01:49这并非她决定改变工作方式。
00:01:51而是她身边的工程师开始并行启动多个 Agent（智能体），突然间
00:01:55瓶颈不再是工程开发了。
00:01:58工程先变，设计被迫跟进。
00:02:00愿景的时间线也改变了。
00:02:02设计过去常产出 2 到 5 年的远景规划。
00:02:04现在技术迭代太快，3 到 6 个月才是现实的规划范围。
00:02:09而且它不一定再是一份 PPT 了。
00:02:11而是一个为人们指明方向的原型。
00:02:13翻译（交付）环节也发生了同样的事情。
00:02:15当 Agent 能够根据需求文档直接构建工作界面时，就不再需要
00:02:19中间的转换层了。
00:02:20Agent 直接写代码。
00:02:22不需要翻译 Figma 文件，因为压根就没用到 Figma 文件。
00:02:25另外，如果你喜欢我们的内容，请考虑点击“hype”按钮，因为这能
00:02:29帮助我们创作更多此类内容并触达更多受众。
00:02:33当我们承接客户项目时，这正是我们必须做出的转变。
00:02:36现在设计流程变了，但没变的部分是“需求”。
00:02:40糟糕的需求会毁掉整个构建过程。
00:02:42而大多数团队会直接跳到技术规格。
00:02:44那是错误的顺序。
00:02:45当你构建原型时，不需要技术栈或 API 规范。
00:02:48你需要了解足够的信息来构建一个看起来、用起来像真产品的东西，
00:02:52以便展示给人看，并得到“行”或“不行”的反馈。
00:02:56所以在动原型之前，先从“参与者”（Actor）开始。
00:02:58参与者是指与系统交互的人。
00:03:01一个带着特定目标的特定的人。
00:03:03“谁在使用”决定了系统“需要做什么”。
00:03:06如果你有提交内容的人和审核内容的人，那就是
00:03:10两个不同的界面，有着两个不同的首屏。
00:03:12然后看视图在哪里分流。
00:03:13在大多数产品中，两个不同的参与者访问同一个 URL 却会
00:03:18看到完全不同的内容。
00:03:19管理员看到的是管理面板。
00:03:21普通用户看到的是他们的仪表盘。
00:03:22最后一点是约束条件。
00:03:24不要告诉 Agent 该用什么工具。
00:03:26告诉它什么不能做，以及成本上限是多少。
00:03:28这也会让后续的技术决策变得容易得多。
00:03:32现在我们将所有这些特定规则集成到了这个“创建 PRD”提示词中，它
00:03:37基本上会扮演 PRD 面试官的角色，根据规则采访你，
00:03:42询问你一系列不同的问题。
00:03:44最后，你会得到一个 PRD Markdown 文件，它将用于
00:03:48后续的流程阶段。
00:03:49那个 PRD 文件是所有后续工作的基石。
00:03:52下一步是将其转化为前端的结构。
00:03:55为此，我们使用这个“分层提示词”，它本质上是让 Agent 查看 PRD，
00:04:00（再次强调，这并非包含所有技术要求的完整 PRD）并产出两样东西。
00:04:04它要求产出原型所需的页面和弹窗，
00:04:08以及用户流程。
00:04:09显然，页面和弹窗对结构至关重要，这样 Agent 需在
00:04:14前端实现的一切都能预先规划好。
00:04:17我们一直在强调“谋定而后动”的重要性，以及它对
00:04:21Agent 和上下文窗口的意义，所以这里就不再赘述了。
00:04:24但对于用户流程，定义每个参与者的动作非常关键。
00:04:28既然我们已经专注于参与者而非功能，定义用户流程
00:04:32也很重要，这样 Agent 才能实现正确的交互状态
00:04:36和完整的 UI 原型导航。
00:04:40最终我们得到了两个文件，其中 architecture.md 包含了
00:04:45我们讨论的页面、弹窗和用户流程。
00:04:46之后，我们让它安装一个 Next.js 应用，因为那是我们
00:04:50常用的技术栈，即 Next.js 配合 Supabase。
00:04:53这就是它实际生成的成果。
00:04:55总体来看设计非常出色，这背后是有特定原因的。
00:04:58另外，之前没提到，这次构建的是一个包含频道、
00:05:03产品和课程的社区平台。
00:05:04基本上有两个参与者：成员和创作者。创作者
00:05:08拥有所有的管理功能，例如创建频道、添加产品
00:05:12或上传课程，以及查看各项统计数据。
00:05:15我们认为，对于生成的第一个原型来说，设计感已经很棒了。
00:05:19但 UX（用户体验）还没那么好，因为通常我们不想要这样的仪表盘。
00:05:23而这正是重点所在。
00:05:24这类修改过去要耗费数天，现在只需几分钟。
00:05:27因为 AI 可以非常迅速地完成这些调整。
00:05:30由于此时还没有后端，它也不必处理那些额外的琐事，
00:05:34它只是一个前端原型。
00:05:36通常 AI 生成的网站和界面并不怎么好看。
00:05:40之所以这个看起来不错，是因为我们使用了 Anthropic 在其
00:05:44一篇博客中提供的“通用前端技能”提示词。
00:05:46我们强烈建议在实现 UI 之前使用它。
00:05:50只需将其保存为快捷指令或技能，以便你的 Agent 调用。
00:05:53现在如果你是为客户工作，只需展示这个原型，
00:05:57它在功能上配合 Mock 数据是完全可以运行的，因为它
00:06:01目前还不涉及数据库。
00:06:02你可以向客户展示，获得批准，如果不满意就修改，然后再
00:06:06继续后续的构建。
00:06:08任务清单是我们现在能让这些 Agent 制作
00:06:12功能完备原型的核心原因之一。
00:06:14归功于任务清单、任务持久化以及一切
00:06:17都是结构化的。
00:06:18这就是为什么编写 architecture.md 文件至关重要，因为它能让
00:06:23Agent 生成完美优化的任务清单，从而避免产生幻觉。
00:06:28之后我们进入后端实现环节。
00:06:30通常有两种做法。
00:06:32你可以保留 Next.js，让前端保持独立，然后将
00:06:36后端作为一个独立的 Python 服务来实现。
00:06:39但这取决于你正在开发的应用类型。
00:06:42对于大家构建的大多数项目，Next.js 就足够了。
00:06:46只有当你需要 Next.js 中没有的大量库，或者需要
00:06:50严肃的后台任务编排来优化站点或其功能时，
00:06:55才特别需要一个独立的 Python 后端。
00:06:57在这种情况下，你可能需要独立的后端。
00:06:59否则，Next.js 的后端功能基本能满足你的所有需求。
00:07:03在动手写后端之前，我们需要知道前端究竟需要什么。
00:07:07所以我们让 Agent 查看前端代码、PRD 和架构文件，
00:07:11并编写一份 API 规范。
00:07:12之后，我们让它利用这三个文档创建完整的 Supabase Schema，
00:07:17因为我们前端使用的是 Supabase 加 Next.js。
00:07:20它基本上需要创建用于存放应用数据的模式（Schema）。
00:07:25通常如果你问 Agent，它会让你先去数据库获取
00:07:28API 密钥，然后手动粘贴 SQL 语句来创建表。
00:07:33但你不该这么做，而应使用 Supabase MCP。
00:07:36无论你使用什么服务，务必尝试使用 MCP，因为它能
00:07:40自动化处理很多事情。
00:07:41例如，在这里我们甚至不需要查看项目。
00:07:43它自动创建了项目，运行了 Schema 查询，并自动
00:07:48执行了数据库迁移。
00:07:49所以我们基本上什么都不用做。
00:07:51数据库设置好后，你就要把前端连接到数据库。
00:07:55这里同样有一个明显的区别。
00:07:57你不需要将后端连接到数据库，因为它已经集成在
00:08:00前端中了。
00:08:01前端直接与数据库通信，使得集成和整体复杂度
00:08:06大幅降低。
00:08:07本视频我们与 Warp 达成了合作，他们最近发布了 OZ，这是一个
00:08:11针对不同云端 Agent 的编排平台。
00:08:14这些云端 Agent 非常适合那些你想委派的任务，而且你确定
00:08:19Agent 能够独立完成这些任务。
00:08:21到目前为止，Agent 已经将前端连接到了数据库，应用
00:08:26基本上据此正常运行。
00:08:27但为了添加支付处理、新通知、频率限制或网站分析
00:08:32等功能，我们确实需要一个专门的后端 API 层来整合这一切。
00:08:37为此，我们使用 OZ 创建了一个环境并运行了一个云端 Agent，
00:08:41要求它构建那个专门的后端层。
00:08:43大约 15 分钟后，任务完成，整个架构就准备就绪了。
00:08:47要让它真正上线并开始接收用户，剩下的工作
00:08:51只剩 Google 登录、Stripe 集成以及一些需要修复的小细节了。
00:08:56现在你已经看过了完整流程，提示词也都在屏幕上展示了。
00:09:00但如果你想要将这些提示词作为一套分步工作流来直接用于
00:09:04自己的项目，我们将这些内容放在了 AI Labs Pro 中。
00:09:06对于不了解的人，那是我们的社区，你可以获得即插即用的
00:09:10模板，用于本视频及以往所有视频的项目。
00:09:14如果你觉得我们的内容有价值并想支持这个频道，这是
00:09:18最好的方式。
00:09:19链接就在简介里。
00:09:20本期视频就到这里。
00:09:22如果你想支持本频道并帮助我们继续制作此类视频，
00:09:26可以通过下方的 Super Thanks 按钮进行支持。
00:09:28一如既往，感谢观看，我们下期再见。