Andrej Karpathy 的文章，让我感受到，未来的交互中枢是 AI，那现在很多服务都需要提供 AI 友好的交互形式，很多能力都值得重新做一遍。
就像搜索引擎时代，会有专门的 SEO 岗位。
移动互联网时代，所有的能力，都需要兼容手机的形态。
AI 时代，所有的能力也需要跟上新的交互形态。
每当我走进餐厅翻开菜单时，总会有种深深的困惑感。Pâté到底是什么？Tagine又是怎样的料理？Cavatappi…是意大利面的一种吧？甜面包听起来很诱人（毕竟我是个甜食控）。但有时候菜单描述实在令人摸不着头脑。”用陈年凝乳折叠油封根茎，最后浇上榛子黄油汁”——这到底是什么东西？我这辈子花了太多时间在谷歌搜索食物图片，所以当最近有机会参加一场 vibe 编程黑客松时，我知道终于可以开发出自己心心念念却遍寻不获的应用程序了。现在它真实地呈现在眼前，我称之为… 🥁🥁🥁 …MenuGen
MenuGen非常简单实用。你只需拍摄菜单照片，它就能为所有菜品生成对应图片。虽然不能百分百还原餐厅实际出品，但能让你对菜式有基本认知：哪些是沙拉、哪道是鱼类料理、哪款是汤品等等。在黑客松期间完成本地测试版后（当时第一版还只能在本地运行），我继续通过 vibe 编程完善了部署流程，添加了身份验证和支付功能，最终将其打造成真正的产品。欢迎下次外出用餐时体验：menugen.app！
作为我的首个全流程 vibe 编程应用，这个项目见证了一个只会摆弄代码（几乎没有正经Web开发经验）的人，从零开始打造出真正的产品——用户可以注册、付费使用并获得价值，而我则能获得10%的合理利润分成。这种感觉非常酷。但除了应用本身的价值，MenuGen对我来说更是一次关于现代 vibe 编程可行性的探索。整个项目我没有直接编写任何代码，所有代码都由Cursor+Claude完成，从传统开发视角来看，我其实并不清楚MenuGen的具体运作原理。现在项目”完成”（指第一版能正常运行），我想分享这次独特的开发体验——在202X年，一个非专业开发者如何通过 vibe 编程打造Web应用。
首先是本地版本开发。如同多数 vibe 编程项目的典型经历，在本地机器上运行的首个原型开发耗时极短。借助Cursor和Claude 3.7，我简单描述应用构想，AI就快速生成了所有React前端组件，构建出精美的网页——流畅的渐变色字体、精致的CSS动画、响应式设计一应俱全，只是缺少后端功能。看到网站雏形如此迅速成型，确实令人兴奋。当时我以为完成了80%的工作量，但现实可能更接近20%（此处埋下伏笔…）
OpenAI API集成。从这里开始遇到首个挑战。我需要调用OpenAI API来实现菜单图片的OCR文字识别。获取API密钥的过程需要穿越层层”项目”设置和权限迷宫。Claude不断推荐已弃用的API接口和过时的模型名称，输入输出规范也因近期更新而频繁变动。经过反复粘贴文档内容与AI沟通，问题才得以解决。当API调用终于成功时，又立即遭遇严格的速率限制——每10分钟只能发起少量请求。
Replicate API整合。下一步是根据菜品描述生成图片。注册新Replicate API密钥后很快遇到类似问题：由于LLM知识库未及时更新导致查询失败，更糟的是官方文档也因API近期改动而部分过时——现在返回的已不是直接JSON数据，而是某种连我和Claude都无法理解的流式对象。调试过程中又遭遇API限速，后来得知这是服务商为防止欺诈采取的常规措施，但对新手确实不够友好。听说Replicate即将改用预购信用点的模式，或许能改善现状。
Vercel部署。虽然本地运行正常，但部署首个版本时再遇挑战。注册Vercel账户、添加项目、配置指向GitHub仓库、推送代码到master分支后…部署失败。日志显示存在未使用变量等基础lint错误，但由于本地运行正常，只能通过推送调试性伪提交来强制重新部署。修复这些问题后，网站仍无法运行。求助Claude、ChatGPT、查阅文档、谷歌搜索一小时后，终于发现低级错误——存储API密钥的.env.local文件被正确列入.gitignore，但需要手动在Vercel项目设置中添加环境变量。虽然较快发现问题，但完全可以想象新手会在此处卡壳许久。部署成功后，Vercel自动生成的公开URL也让我吃惊——未完成的私有代码库就这样暴露在可猜测的公开域名下。
Clerk身份验证。采用Claude建议的Clerk进行身份验证，注册配置后获取API密钥。此时Claude生成了约千行基于旧版API的废弃代码，不得不反复粘贴文档内容逐步修正。将开发环境转为生产环境时，发现Clerk要求必须使用自有域名（menugen.vercel.com无效），于是购买menugen.app域名，配置DNS记录，选择Google作为OAuth提供商，又陷入谷歌云平台的新建项目、创建OAuth凭证、审核等待等系列配置。期间几乎想放弃项目，所幸次日重拾精神继续攻关。
Stripe支付集成。添加支付功能意味着再战新平台：注册Stripe账户，选择Next.js后端，复制入门代码片段后遭遇错误——原代码是JavaScript而项目使用TypeScript。每次粘贴都会引发linter报错，多次要求Claude”修复错误”并以转用ChatGPT相威胁后才逐步解决。在Stripe仪表板创建产品、定价、获取价格密钥（非产品密钥！）的过程中，发现Claude提议的通过邮箱匹配支付与账户的方案存在严重漏洞（用户支付时填写的邮箱可能与其Google账户不同），及时指出后AI道歉并改用用户ID元数据方案。测试通过后，再将开发环境转为生产环境，重新创建产品、定价，在本地和Vercel设置中更新密钥…终于大功告成。
数据库与任务队列？目前所有处理都是实时完成，没有缓存或存储机制。当菜单项目过多或API延迟时，请求可能超时中断，刷新页面也会丢失所有数据。理想方案应连接Supabase PostgreSQL等数据库记录任务状态，配合Upstash等队列服务处理请求。但想到需要管理更多服务、API密钥和配置文档，最终决定将这些改进留作未来工作。
总结来说，MenuGen的本地原型开发充满趣味，但完整部署过程却痛苦重重。构建现代应用就像组装宜家未来风家具——各种云服务、文档、API密钥、配置项、开发/生产环境、团队安全功能、速率限制、定价层级让人应接不暇。而LLM的知识滞后性、关键设计疏漏（细究之下）、以及偶尔的幻觉式解决方案，都增加了开发难度。最有趣的是，真正的编码工作占比很小，大量时间都消耗在浏览器标签间穿梭，配置拼接这个由多服务组成的”弗兰肯斯坦”。这些配置状态甚至无法被LLM直接操作——用这种方式如何在2027年前实现社会自动化？
展望未来，这次零基础 vibe 编程的体验让我既惊叹于可能性（确实比传统方式更快更简单！），又对现状略感沮丧。部分痛点源于现有基础设施并非为这种开发方式设计，目标用户仍是专业开发团队而非 vibe 编程的独立开发者。要让MenuGen这类简单应用更易创建，或许需要：
- 全集成式应用开发平台：与Vercel应用市场相反，预置域名托管、身份验证、支付、数据库等基础功能，开箱即用
- LLM友好型服务：提供CLI工具、curl配置接口、Markdown文档等更适合LLM交互的抽象层
- 回归简约技术栈：考虑采用HTML/CSS/JS + Python后端（FastAPI + Fly.io），避开”现代Web开发”的无服务器复合宇宙
- 重新思考应用形态：或许MenuGen本不需完整应用架构，本质上只是调用GPT进行OCR识别，循环生成菜品图片并优雅展示——类似OpenAI的GPT应用商店中的定制GPT，甚至可能通过精心设计的提示词实现
无论如何，能将自己首个定制应用推进到可分享、可盈利的阶段已足够令人欣喜。感谢所有使用过的云服务提供商。从原理上说，这个应用完全可能被动创收——正如@levelsio倡导的数字游民理想。虽然当下用 vibe 编程开发重要应用仍不够可靠，但伟大变革的曙光已现。我期待见证应用开发门槛趋近于零的未来，届时人人都能像制作TikTok视频般轻松创建应用，让这种超级定制化自动化成为人类创造力的全新画布。