整整一天工作结束之后，彼得·杨打开了电脑。
他不是要回邮件，不是要看报告。他要从头开始，做一个移动端健身追踪App。
两小时之后，他做完了。
这个App可以创建自定义训练计划，添加动作、设置组数和次数，实时追踪训练进度，在每组结束后触发休息计时，最后把所有训练记录到日历里。
之前，做这个东西需要一整支产品团队：工程师、设计师、产品经理，可能还要几个月时间。
现在不需要了。
工作流的核心：三个阶段，不要一口气搞定
彼得做事情有一个习惯，他反复强调：不要想着一次性生成所有东西。
「我喜欢分三个阶段来做，这样我可以一边做一边测试，而不是试图一口气把所有东西生成出来然后祈祷它能用。」
第一阶段：用Claude定义需求
一切从一次对话开始。彼得打开Claude，告诉它他想做什么——一个健身追踪App，需要哪些功能，有什么约束条件。
这一步的目标不是让Claude写代码，而是让Claude帮他把需求整理清楚，生成一份spec.md文档。
这份文档是整个工作流的起点。它像一份合同，明确了App要做什么，设计和开发阶段都要参照它来执行。
这个步骤本身只需要几分钟，但它决定了后面两个阶段能不能高效推进。很多人跳过这一步，直接上来就让AI写代码，然后发现代码写出来了，但不是自己想要的东西，又要反复修改。
把需求先搞清楚，才能把后面的工作交出去。
第二阶段：用Pencil设计界面
有了需求文档，彼得打开了另一个工具：Pencil。
Pencil是一个AI设计工具，它可以根据文字描述或者现有的设计稿，生成App的界面原型。彼得说，这个工具「太难以置信了」——他把spec.md喂进去，一轮迭代之后，界面设计就出来了，质量超出预期。
设计阶段完成之后，所有的界面文件都保存在Pencil里。这很重要，因为下一步要用到它们。
第三阶段：用Claude Code连接一切
最后一步是打开Claude Code，把spec.md复制进去，然后通过Pencil的MCP插件，让Claude Code直接访问Pencil里已经做好的设计文件。
这一步的效果是：Claude Code可以「看到」设计稿，然后严格按照设计稿写代码，而不是自己发明一套界面。
彼得同样分三个小阶段来做这部分：先搭出App的基础框架，测试可以跑通；再添加核心功能，测试可以跑通；最后做细节打磨，再测一遍。
每个阶段结束，他都用Expo Go在真实手机上测试。Expo Go是一个可以直接预览React Native应用的工具，不需要先编译打包，改完代码扫码就能看到效果。
「三阶段而不是一口气搞定」这个原则，贯穿了整个工作流。
App长什么样
最终做出来的东西，彼得在视频里走了一遍。
创建训练：命名一个训练计划，比如「彼得的训练」。
添加动作：「杠铃深蹲」，三组八个，再加一组热身组。「杠铃俯身划船」，同样配置。「杠铃卧推」，加进来。保存。
开始追踪：点开这个训练计划，逐项完成。每个动作做完打勾，休息计时自动触发。全部完成之后，这次训练会自动记录到日历里。
点开日历，看到今天做的是「彼得的训练」，点进去可以查看所有动作记录。
还有设置页面：可以切换磅和千克，可以开关休息计时器。
「你们可以看到，这是一个功能相当完整的App，对吧？」
没有借口了
彼得在结尾说了一句话，直接的程度有点让人意外：「如果我在下班后的几小时就能做出这个App，那你们真的没有理由不去做点什么了。这件事变得无比简单，也无比好玩。我们都应该成为建造者。」
这个判断背后有一个更大的变化。
做一个App，曾经意味着你要会Swift或者Kotlin，要理解状态管理，要懂UI设计原则，要熟悉各种打包和发布流程。普通人的入场门槛，不是时间不够，是技能树太长。
现在呢？你需要的是：知道自己想做什么，能把需求说清楚，会用几个工具，愿意分阶段测试而不是一口气祈祷。
这不是消除了技能要求，而是把技能要求的重心从「执行」移到了「定义」。定义清楚了，执行可以外包给AI。定义不清楚，AI帮不了你，什么工具都帮不了你。
彼得的三阶段工作流，本质上是一套「如何清晰定义然后高效执行」的结构。它不只适用于做App，适用于任何可以被拆分成需求定义、设计原型、代码实现的项目。
两小时的意义
两小时不是一个厉害的速度记录，它是一个信号。
它说明建造一个可以用的移动端产品，现在不再是「有想法的工程师」才能做的事，而是「有想法的任何人」都可以尝试的事。
你可以下班之后做，可以在周末做，可以在等飞机的时候想，在坐地铁的时候定义需求，在睡前让Claude Code跑完第一个阶段。
「不要等别人来解释它，直接去问Claude，自己搞清楚。」
这句话有一种奇特的平静。它没有说「AI改变了世界」之类的大词，它只是说：工具在这里，机会在这里，剩下的是你愿不愿意开始。