夜雨聆风
45分钟、76KB:这款AI协作App把我看懵了
先说结论：这事最值得看的，不是“45分钟做完App”，而是一个人把“想法→可上台使用”这条链路压短到了惊人的程度。
很多人看到这种案例，第一反应是“AI太神了”。但真相往往是：AI把执行速度拉满，人的经验决定上限。
一晚做完，还真在现场用了
这次案例来自 Simon Willison。背景很清楚：他要去做一场关于 LLM 近况的分享，前一晚临时做了一个叫 Present 的 macOS 演示应用。
核心信息有三个：
-
• 开发方式：以 prompt 驱动的快速迭代（vibe coding） -
• 体积：应用约 355KB，压缩后约 76KB -
• 可用性：第二天就用于真实演讲场景
一句话：这不是“代码仓库里放个demo”，而是直接拿去打实战。
来源：
-
• https://simonwillison.net/2026/Feb/25/present/
这App到底解决了什么痛点
如果你经常做技术分享，会秒懂这个痛：
-
• 用浏览器标签页串讲网页很灵活 -
• 但浏览器一崩，现场直接翻车
Present 的设计很克制：
-
把演示定义为“一个URL序列” -
左侧管理顺序，右侧实时预览 -
一键全屏，方向键切换 -
自动保存状态，崩了也能恢复
看起来朴素，但每一条都对准“上台不能翻车”这个唯一目标。
真正有意思的一刀：手机远程控场
后续他又加了个网页遥控页：手机上点上一页/下一页，就能控制电脑上的演示。
这一步很关键。因为它把“能演示”升级成了“能掌控节奏”，对讲者体验完全不是一回事。
更现实一点说，这种功能过去通常要你：
-
• 找现成软件 -
• 适配自己流程 -
• 反复折腾
现在变成：
-
• 先描述需求 -
• 先跑出最小可用版本 -
• 再按现场需求追加功能
45分钟神话，普通人到底能不能抄
能抄一部分，不能全抄。
能抄的是方法：
-
• 用AI先拿到“能跑起来的骨架” -
• 把需求写得非常场景化（比如“演讲模式”“键盘切换”“崩溃恢复”） -
• 用真实任务倒逼迭代，而不是空想完美产品
不能盲抄的是背景：
-
• 作者本身有长期工程经验 -
• 对演讲场景有大量一线使用经验 -
• 知道什么功能是“必须先做”
一句话：AI在放大你的判断力，不在替代判断力。
这对内容团队和产品团队意味着什么
如果你是内容团队：
-
• 你可以把“写完稿→做配套工具”当成同一流程 -
• 很多过去不值得开发的小需求，现在值得做
如果你是产品团队：
-
• 更应该建立“当天可验证”的小循环 -
• 先拿可用版本，再做结构性重构
如果你是个人创作者：
-
• 别一上来问“能不能做大而全” -
• 先问“明天要上台，我今晚最小要做什么”
最后一句判断
这次案例最大的信号不是“又一个AI炫技帖”，而是：
个人软件生产力，已经从“会不会开发”，转向“会不会把真实场景写成可执行需求”。
谁先掌握这件事，谁就会在下一轮内容与工具竞争里先跑一步。
快问快答
Q：这是不是在鼓吹“人人都能45分钟做App”？A：不是。45分钟是个高经验用户样本。真正可复制的是“先做可用、再迭代”的方法。
Q：这种方式最大的风险是什么？A：把“能跑”误当“可维护”。上线前至少要做一次结构检查和风险兜底。
Q：普通团队今天就能做什么？A：挑一个本周反复出现的小痛点，限定2小时，用AI做最小工具并在真实流程里试用一次。
