The 100 hour gap between a vibecoded prototype and a working product
来源: Mac Budkowski / kanfa (Paragraph blog) | 日期: 2026-03-06 原文: The 100 hour gap between a vibecoded prototype and a working product 精读日期: 2026-03-17
一句话总结
Vibe coding 做出原型只要 1 小时,但做成真正能上线的产品需要 100 小时——中间的 100 倍差距才是真正的工程。
核心内容
作者背景:不是 AI 怀疑论者,而是早期实践者
Mac 在前一家创业公司 Kiwi 从 2023 年底就开始用 AI 写代码(比 “vibe coding” 这个词出现还早)。最初直接把代码贴到 ChatGPT 里,后来用 Cursor 和 Claude Code,团队因此获得竞争优势。这次他想独立走完从 0 到上线的全流程,验证 AI coding 的真实边界。
项目选择:SLC 而非 MVP
选了 Cryptosaurus——上传头像,AI 生成恐龙风格版本,铸造成 NFT。遵循 Jason Cohen 的 SLC 理念(Simple, Lovable, Complete)。关键决策:不用 Replit/Lovable,要自己搞基础设施,目的是学习而非走捷径。
开发过程的五个阶段与时间黑洞
阶段 1:原型(~1 小时)
ChatGPT 5.2 讨论需求 → Opus 4.5 Plan Mode 生成代码 → Gemini API key → 1 小时出原型。这就是大家在 Twitter 上炫耀的部分。
阶段 2:UI/UX 迭代(时间黑洞 #1)
- Claude 生成的 UI 过于复杂,反复要求简化
- 每次迭代:prompt → LLM 构建 → 检查 → 不满意 → 重来,每轮几分钟
- 容器 break 前端、移动端渲染问题、莫名 outline
- 反思:如果用 Figma 做 10 个变体只需 10 分钟,比 “just build” 快 10 倍
阶段 3:Prompt 工程(时间黑洞 #2)
- 用多个 LLM(Gemini、Codex、Claude 4.6)迭代 200+ 次
- 边界情况:不同风格头像导致背景乱码、丢失头饰、出现随机文字
- 最终
prompt.ts达 274 行,生成脚本包含大量边界修复逻辑 - 这是产品质量的核心——“slop 和用户喜欢的东西之间的区别”
阶段 4:基础设施(时间黑洞 #3)
| 问题 | 细节 |
|---|---|
| AWS 学习曲线 | 打开面板看到”浩瀚的服务海洋”就知道是 overkill,但还是硬上 |
| S3 配置 | 忘记公开 bucket;Claude 自动创建新 bucket 而不用已有的 |
| 环境变量 | .env 没同步到 Vercel 和 AWS |
| Farcaster Mini App | 开发者模式通知不工作;移动 UI 在 mini-app 中 break;需要第二个账号测试 |
| 智能合约安全 | 设置 onlyMinter 权限 + Safe 合约做 owner(防私钥泄露) |
| 并发准备 | 花 2 天处理 rate limit 和用户峰值场景 |
阶段 5:发布与翻车
500 人预装 → 上线 → 并发 nonce 冲突导致付款成功但 API 请求失败 → 图片生不出来、NFT 铸不了。精心设计的病毒传播机制因 bug 废掉。
应对:连夜修 bug → 写脚本找出所有卡住的付款 → 退款 + 额外补 $1 → DM 通知每个用户。用户反而因为快速响应而更信任,大多数人决定重新购买。
最终成绩
- 1,000+ 下载,180+ 付费用户($2/个)
- Farcaster Mini App Store 首周 Top 3
- 计划推出 Stage II 游戏功能
方法论进化:从 “just build” 到结构化协作
| 早期做法 | 后期优化 |
|---|---|
| 直接让 LLM 写代码 | 先做架构讨论,让 LLM 画流程图,迭代后再动手 |
| 单个 agent 串行 | 精心划分 scope,3-4 个 agent 并行不冲突 |
| 默认 LLM 行为 | 在 agents.md 中指定”始终寻找简洁方案” |
| 经验留在脑子里 | 记录到 Obsidian,有时直接贴进 prompt |
| 纯 LLM 做 UI | 回归 Figma 做设计,LLM 做实现 |
工具观察
- Codex 倾向过度复杂化,Claude 倾向简洁优雅
- 有些问题 3 个 LLM 都解不了(Brave 浏览器覆盖颜色),资深工程师朋友一行代码搞定
- 强烈建议:找资深开发者朋友帮忙,LLM 仍有盲区
核心论点:AI 改变了 90/90 法则的含义
引用 Tom Cargill 经典名言:
“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”
AI 让前 90% 变得容易,从而释放时间给最后 10% 的打磨。这 10% 是 slop 和 craft 的分水岭。
编码体验的本质变化:从创意心流变成任务管理——你在调度 digital employees,在他们不达预期时 frustrated。但值得,因为你能专注于 building things 而非 fixing syntax。
金句摘录
- “People who say they ‘vibecoded an app in 30 minutes’ are either building simple copies of existing projects, produce some buggy crap, or just farm engagement.”
- “The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.” — Tom Cargill
- “With AI, it’s easier to get the first 90 percent out there. This means we can spend more time on the remaining 10 percent, which means more time for craftsmanship.”
- “When I used to code by hand, I got into a pleasant creative flow. Now I am just a manager who gives tasks to digital employees and gets frustrated when they don’t deliver what I wanted.”
- “Vibecoding takes the boring part out of coding and creates more space for craftsmanship.”
社区评论精选(Farcaster)
- Duxander:自己 vibe coding 花了 500 小时、产品没上线、manifest 都没签成,“a fucking terrible experience”。休息几个月后从结构化学习重新开始,花了半年持续迭代。结论——“people really can build something simple in 30 minutes now, but something big and meaningful? Definitely nope”
- regenbot:做 onchain 工具有同感,“prototype feels magical but then you hit auth edge cases, state management, wallet quirks. the unglamorous 80% that nobody tweets about”
- patrion:经历高度相似,从多次失败到”spent a LOT more time in the planning stages”后结果才改善,但仍有”odd LLM-fart”
- rathermercurial:吐槽 Cloudflare 买域名 + Vercel 部署的组合是”self-hatred”
Justin 视角
对投资判断的参考价值:
AI coding 的真实产出率:1 小时原型 vs 100 小时产品,这个 100x gap 对我们评估 AI-native 创业团队的 velocity 很有参考。很多 pitch 声称”一个人顶十个人”,实际上 AI 加速的是前 90% 的 boilerplate,后 10% 的 craft + infra + edge case 仍然是硬仗。投资时需要追问:你们的产品 polish 程度如何?团队有没有资深工程师补 AI 盲区?
Replit/Lovable 的价值重新审视:作者刻意不用这些平台以学习底层,但反过来说明这些 infra abstraction 层确实解决了真实痛点(AWS 配置、部署、环境变量同步)。对于非技术创始人,这类平台的价值比想象中大。
Codex vs Claude 的产品定位差异:“Codex overcomplicates, Claude prefers elegant” 这个观察如果能被更多开发者验证,对理解两家产品的差异化定位有意义。
“Manager of AI agents” 的新范式:编码从心流变成任务管理,这个体验转变值得关注——未来开发工具可能更像项目管理工具而非 IDE。
与当前关注的赛道关联:
- AI coding tools 赛道的 realistic expectation setting
- 基础设施抽象层(Replit、Lovable、Vercel)的持续价值
- 非技术创始人的 AI empowerment 程度与天花板
可行动的 takeaway:
- 评估 AI-native 项目时,追问”原型到生产”的真实时间和人力投入
- 关注解决”最后 10%“问题的工具——这是 AI coding 当前最大的 gap
延伸阅读
- Jason Cohen: SLC (Simple, Lovable, Complete) — 文中引用的产品方法论
- Cryptosaurus — 作者构建的产品
- Farcaster Mini Apps — 文中的分发平台
- Tom Cargill 的 90/90 法则(软件工程经典)
- 值得追踪:Mac Budkowski(crypto + AI coding 交叉实践者)