我用AI写完了整个产品，但这些坎它死活过不去

几个月前我做了个实验：看看"氛围编程"（vibe coding）到底能走多远。不是玩具项目，是真东西——从Chrome插件、后端、营销网站到SEO内容流水线，全部交给AI。

成果是Mail2Follow，一个能在Gmail里追踪邮件打开率和跟进状态的插件。现在已经上架Chrome Web Store、Edge插件商店、Google Workspace应用市场，还接入了Zapier。

但我真正想聊的，是AI搞不定的那些环节。

神话破灭：没有"一句话生成产品"这回事

社交媒体上那种"一个提示词做出产品"的说法，是骗人的。Mail2Follow用了几百个提示词——修bug、处理边界情况、重构代码、在模型跑偏时把它拉回正轨。有些bug我自己动手修比跟AI扯皮快得多，但为了实验的完整性，我还是选择继续对话。

净效果依然是生产力暴涨。只是别再信那个营销话术了。

AI确实能扛大梁

一个人能覆盖的范围被大幅拓宽了：Chrome插件的脚手架、manifest配置、service worker、消息传递；Cloudflare Workers后端、D1数据库、Turnstile验证、Astro建站；七种语言的营销文案；GA4和Looker Studio数据看板；隐私政策、用户协议、支持文档、更新日志；甚至多Agent SEO系统的初版代码。

如果你的认知还是"AI只写简单代码"，那已经过时了。AI写大部分代码。真正值得问的是：哪些它写不了？

第一处崩溃：往Gmail界面里插东西

Mail2Follow要活在Gmail里面。没有官方UI API，只能往Google的DOM树里硬插元素。Google的class名长这样：gE iv gt，而且组件一重构就变。昨天能用的扩展，今天可能就崩了，等用户发邮件来你才知道。

AI在这里几乎帮不上忙，三个原因：训练数据是几个月甚至几年前的，跟不上Gmail的更新速度；它给的CSS选择器自信且错误，匹配的是"Gmail扩展一般长什么样"，而非当前实际结构；最麻烦的是——

（原文此处截断，以下为转述）

作者指出，这类需要实时对抗大型平台DOM变化的场景，AI缺乏获取当前真实界面结构的能力，也无法预判Google的改动节奏。这是"氛围编程"的第一道硬边界。