阶段二：构建 MVP
我的理解
本课演示 MVP 构建的两阶段。调研阶段强调”管理+创造”工作流是化解一切技术壁垒的”万能溶剂”，关键在于向 AI 提出的问题而非生成的代码。构建阶段做出全书最重要的战略转向之一：明知零摩擦北极星，却刻意降级为 Web 应用以最快验证核心假设、为概念”去风险化”。委派是迭代对话而非独白，最终提示是反复打磨的”黄金标准”。一个下午即验证了核心循环，这正是飞轮效应在运转。
相关链接
- Ch04-L05 产品定义简报 — MVP 构建的北极星指引
- Ch04-L04 起点idea到魔法产品 — Aha Catcher 示例的战略起点
- Ch04-L07 你的任务设计超能力 — MVP 构建方法论在学员自身项目中的应用
- Ch04-L03 点燃飞轮管理创造工作流 — 委派与绩效复盘是工作流的核心环节
原文
Lesson 27 of 46 阶段二：构建 MVP / Phase 2: Building the MVP
阶段 2.1：调研与技术决策（管理者要问的问题）
AI 架构师不会一上来就猜测该用什么技术。他们会先提出正确的问题，并把调研工作委派出去。
在继续之前，先说一件重要的事。当你阅读下面的示例时，会看到诸如 watchOS 和 Swift 这样的词。你大脑的某一部分可能立刻拉响警报：“等等，我又不是 Apple 开发者！我不会 Swift！这个项目适合我吗？”
请明确一点：这个示例几乎和 Swift 本身无关。
我们刻意选择了一项很可能超出你当前舒适区的技术，是为了证明一个更深层的道理。你正在学习的”管理 + 创造”工作流，是一种可以化解一切技术壁垒的”万能溶剂”。它是一把万能钥匙，无论你面对的是 Python、Swift、Rust，还是某种尚未被发明的语言，它都能为你打开那扇门。
你在这里的任务不是学 Swift。你的任务是观察我们如何切入一个陌生的技术生态。请关注我们向 AI 提出的问题，而不是它生成的代码。注意我们如何委派调研、要求列出利弊，并把一个复杂问题拆解为可管理的步骤。具体的技术（watchOS）只是方程中一个临时变量；真正不变的，是这套问题解决方法论。
对于你自己的项目，你完全可以选择一个简单的网页应用、一个命令行工具，或任何你熟悉的形态。这个示例只是一次”力量演示”，目的是让你看到：在这套工作流之下，没有哪种技术是真正遥不可及的。
带着这一点，让我们看看一位架构师会如何应对这一挑战。
委派提示 1（手势）： “我想在 Apple Watch 上构建一个’Aha! Catcher’，通过一个简单的手势来触发。请调研 watchOS 上可用于检测手势的 API。是否存在内置的、系统级别的手势可供我使用？如果有，请提供一段最小化的 Swift 代码片段，用来监听该手势。”
AI 可能的回复与我们的决策：AI 很可能会提到 Double Tap（双击）手势可通过 Accessibility 框架使用，且实现非常简单。决策：我们将采用原生的 Double Tap。这是一个巨大的胜利——它是一个用户已经熟悉、低功耗、且不需要任何自定义机器学习的手势。
委派提示 2（数据流）： “一旦在 Watch 上检测到手势，我需要把最近 30 秒的音频发送到云端 API。把数据从 Apple Watch 传输到 Web 服务器的最佳实践架构有哪些？我应该直接从 Watch 发送，还是把 iPhone 作为中转？请列出每种方案的优缺点。”
AI 可能的回复与我们的决策：AI 会列出各种选项。直接从 Watch 发送更简单，但在 Wi-Fi/蜂窝关闭时不够可靠；以 iPhone 作为中转则更稳健。决策（针对 MVP）：为了保持简单和聚焦，我们先采用直接发送到 Web 的方案。结果将通过一个简单的网页应用来查看。
阶段 2.2：构建 MVP（绩效复盘）
我们刚刚清晰而激动人心地描绘出了那种终极”零摩擦”的未来——这是我们的”北极星”。而恰恰因为我们已经看清了这个方向，我们接下来要做出一次刻意的架构转向。这种战略性决策，正是 AI 架构师与”功能堆砌者”之间的分水岭，也是整门课程中最重要的课程之一。
我们的目标不仅仅是做一款 Apple Watch 应用。我们的目标是验证一个核心假设：对转瞬即逝的灵感进行近乎即时的捕捉循环，是一种神奇且有价值的体验。AI 架构师始终在寻找验证核心假设的最快路径，并剔除一切附带的复杂性。开发原生移动应用会带来大量额外开销：管理开发者账号、编译代码、应付移动操作系统的种种细节。这些复杂性都会让我们偏离当下真正的目标。
因此，我们要把这个宏大愿景转化为它最纯粹、最简单的实验形式：一个 Web 应用。表面看像是一种降级，实则是一种加速。这个 Web 应用将作为我们核心用户体验的高保真模拟器。一个桌面上始终常开的网页，上面的一个录音按钮就替代了那个手势。它让我们能够在很短的时间内构建并测试整套后端逻辑——音频捕捉、API 调用、智能体处理、最终结果交付——这一切。我们是在为整个概念”去风险化”，先证明其价值，再去投资更复杂的前端。
这正是”管理 + 创造”工作流的精髓所在：以战略愿景为起点，以战术精度去执行，始终聚焦在通向洞察的最直接路径。
有了这一战略决策，我们就可以开始构建 MVP。新手构建者可能会试图从零开始写出一份”完美无缺”的提示。但 AI 架构师知道，委派是一场对话，而不是独白。你即将看到的那段全面的提示，是对话的成果，而不是起点。
在真实的工作流中，这是一个迭代过程。你可能会从这样的提示开始：“构建一个能录音的网页。“AI 返回一个基础版本。你审阅后给出反馈：“不错。现在改成持续录音，并保留最近 30 秒的滚动缓冲区。“再迭代一次。然后：“很好。现在，当我点击这个新的’Capture’按钮时，把那段缓冲区发送到我们指定的后端 API，其接口契约定义在这份 openapi.json 文件中。”
每一轮反馈都在打磨需求，堵住漏洞、增加精度。下面这条提示就是这一过程的最终成果——一份成熟、详尽的”任务说明书”，使你的 AI 伙伴能够在第一次尝试时就成功交付。我们在此向你展示这个最终版本，作为你在自己实践中可以瞄准的”黄金标准”。
MVP 转向：我们决定先构建一个 Web 应用。它并不是完全零摩擦，但已足以验证核心价值主张。用户可以把手机放在桌上、保持网页打开，然后点击一个按钮来模拟手势。
委派提示 3（构建 MVP）：
“让我们为一款名为 Aha! Catcher 的产品构建一个基于 Web 的 MVP。你可以在
创建一个 index.html 文件。其中包含一个大按钮，标签为 ‘Capture Aha!’。
使用 Web Audio API（JavaScript）实现以下逻辑：页面应持续从麦克风录音，写入一个保存最近 30 秒的缓冲区。
当按钮被点击时，把音频缓冲区作为文件发送到我们在 Project 1 中使用过的官方引擎 API（请使用 OpenAPI.json 的 URL https://space.ai-builders.com/backend/openapi.json，以及 Student Portal 课程中”Commanding AI with the platform’s offering”一节所述的 API Key）。
展示结果：当 API 返回 JSON 响应时，在按钮下方以简洁清晰的格式展示转录文本和研究摘要。”
请注意我们如何运用了”文档即一等交付物”原则。我们刚刚撰写的那份产品定义简报文档，能立即帮助 AI 把握全局。
评估与迭代（绩效复盘）：我们运行这个 Web 应用。它能跑起来吗？能。它感觉神奇吗？接近了。我们成功验证了核心循环——捕捉音频、交给智能体处理、拿回有用结果——不仅可行，而且极具价值。我们在这个简化 MVP 的约束之下达成了我们的 OKR。
这就是”飞轮效应”在运转。我们从一份战略简报出发，借助 AI 做出关键技术决策，然后构建出最简单的版本来验证假设。我们没有花上几周去打造一款功能齐全的 Watch 应用，最后才发现核心想法存在缺陷。我们用一个下午就完成了验证。