🧐 我用 Vibe Coding 从 0 到 1 打造 AI 产品，上线一个月效果如何？有什么心得？

前言

一个月前，我上线了我的第一个 Vibe Coding 产品 Text-Well，这是一个一站式的 AI 文本工作台，功能包括错别字语法检查、文案润色、模拟评审、对照翻译、标题生成、文章配图。

当前网站数据

我在七月底将包含基础检查功能的初版网站上线，然后以 build in public 的方式迭代。截止至九月五日:

总活跃用户为 3218，数据源来自 Google Analytics
注册用户共 550 个，数据源来自 supabase 后台
收入为 0，还没有做商业化，但是订阅和额度管理的机制已经预留好了

做了哪些宣传？

由于我最初的定位就是做出海的站点，所以还是得靠 SEO 或者运营海外的社媒来进行宣传，但是在早期我还是得靠熟悉的国内渠道先推广一下，让网站有一个基本的访问量，这样也容易被搜索引擎收录，所以我是国内国外两手抓。关于宣传我做了哪些事情呢？

投稿阮一峰周刊，获得了初期的六七百个访问量，以及大几十个注册用户

在技术社区发布长文章，例如 medium，少数派，掘金，CSDN 等

在社媒分享网站功能介绍视频，例如 x，小红书等

在海外的一些 AI 、SaaS 分享平台进行投递，国内还投递了 founder park 和观猹，还有一些产品的体验用户自发帮我宣传（感动）

为网站做 SEO 优化，标题、描述、关键词都做到位，每个功能都有独立的落地页和对应的关键词，开发了博客页面，用 AI 归纳产品功能写文章

在刚刚上线时是基本0流量的，毕竟作为一个新站，自己也不是什么大v。前面的二十几天曝光量基本都在十几到几十，但从这一周开始有一些页面被索引后曝光量每天有八百多了，是一个好的开始！

开发的节奏是怎么样的？

文章的标题提到，这是一个纯 Vibe Coding 的项目，我除了自己微调样式，其他一行代码都没写，我开发使用的工具是 claude code 和 cursor，模型用的都是 claude 4 sonnet，从零开始构建的功能或者相对解耦的功能我会使用 claude code，需要一些精细调整时，或者需要明确指定参考文件时就会用 cursor。

关于产品功能、技术方案的设计、宣传文章的初稿我会使用 AI Studio 的 gemini 2.5 pro， gemini 2.5 pro 的理解能力和文本水平还是比 claude 4 sonnet 更强的，而且 AI Studio 可以免费使用，非常良心。

通常工作日我在下班后会开发四到五小时，因为是 Vibe Coding 所以我只需要打字或者语音输入提要求，然后让 AI 自己写代码就好了，过程中并不需要非常专注，所以也没有那么累。周末的话我基本一整天都会进行开发，同样是一边做其他事情一边让 AI 写代码。

项目技术栈

前端：Next.js + Shadcn
后端：Next.js
数据库：Supabase
项目部署：Vercel
域名 + CDN：CloudFlare

我认为 Next.js 是做出海网站最方便的一个框架，开发时开箱即用，且可以实现一些不复杂的后端逻辑，搭配 Supabase 可以快速实现用户登录注册功能，接入 Google 登录和邮箱登录也非常简单。

前端UI方面，可以选用 Shadcn/ui，它提供了一系列可复用的组件，能够用来搭建界面。针对多语言的需求，Next.js 内置了国际化路由功能，可以根据不同地区的用户展示对应的语言内容。

整个项目开发完成后，可以直接部署在 Vercel 平台，流程很顺畅。域名和 CDN 服务则使用 CloudFlare，可以为网站提供全球加速和安全防护。这样一套技术栈组合，可以让个人开发者或者小团队快速构建和上线一个面向全球用户的网站。

Vibe Coding 的使用技巧

不论是 Claude、Code Interpreter，还是 Cursor，我都没有配置任何全局规则，觉得对我来说不太用得上，很多所谓的外部 MCP 和黑科技 prompt 我都没有用。我对于 AI 编程工具的唯一使用方式就是直接和他们对话，这种方式我称之为"Vibe Coding"。

在使用 AI 工具的时候，可以多利用他们的联网查询能力，基于真实的互联网数据可以避免 AI 瞎编。例如，在学习一个新技术或解决一个不熟悉的库的报错时，我会让 AI 去搜索最新的官方文档或相关的 GitHub issue，这样得到的信息更靠谱。同时，可以在项目内部维护一个动态更新的特性文档，每开发一个新功能，就让 AI 总结一下这个功能的介绍和使用流程，并添加到这个文档里。这样，当后续我们开启新一轮对话的时候就不用重复强调项目背景了，而是直接让它参考那个维护功能的文档。

上下文管理

我们可能都遇到过这样的情况：在一个 AI 的对话窗口里，连续聊了很久之后，它的表现开始越来越拉跨。比如让它基于前面的讨论写一段代码，结果它把最开始提的需求给忘了。或者它会开始重复之前给过的错误答案，整个对话的质量明显下降。

其实我们可以把AI想象成一个记性一般但脑子很快的人。当我们和它对话时，它需要把我们说的每一句话（也就是上下文）都记住，才能理解我们最新的问题。但它的记忆方式和我们不一样。它依赖一个叫做"注意力机制"（Attention Mechanism）的东西来决定在生成新回答时，应该重点关注上下文中的哪些部分。

问题就出在这里。当对话变得非常长，上下文信息越来越多时，就会出现几个问题：

注意力分散，关键信息被稀释：试想一下，你刚看完一本几百页的小说，马上被问第三章一个细节，能答出来吗？AI也类似。在一个超长的对话中，充满了大量的代码、报错信息和反复修改的细节，AI的"注意力"就被稀释了。它很难在海量的信息中精准地找到你当前问题最关键的那几句上下文，导致它可能会忽略掉一些重要的前提条件。
(Lost in the Middle) 现象：不少研究都发现，大模型处理长文本时，开头和结尾记得最牢，中间部分却容易'丢'。如果你的一个关键需求是在对话的中段提出的，那么在经过几轮新的讨论后，这个需求很可能就被模型忽略了。这就解释了为什么有时候它会忘记你之前设定好的某个重要约束。
计算资源的限制：AI处理的上下文越长，需要的计算量就越大，这不仅仅是速度变慢的问题。因为算力有限，模型会压缩或舍弃一些早期信息，关键细节就这么丢了。

所以啊，虽然保留上下文能帮AI理解你，但聊得太久反而会拖累它。一个更有效的使用方式是，当你要开始一个相对独立的新任务，或者发现AI的回答开始变得不着边际时，不妨"另起炉灶"，新开一个对话窗口。这样能保证它接收到的是一个干净、专注的上下文环境，从而给出更精准有效的回答。

Bug 描述

在描述问题时，尽量不要让 AI 发挥创意。排查 Bug 的时候要说清楚：

当前的问题：清晰地描述错误的现象是什么，比如"点击按钮后页面崩溃了"或者"API 返回了 500 错误"。
预期中的效果：明确告知 AI 在正常情况下，程序应该如何工作，比如"点击按钮后应该弹出一个提示框"或"API 应该返回包含用户信息的 JSON 数据"。
额外的补充信息：提供尽可能多的上下文，例如相关的代码片段、完整的错误日志、浏览器的控制台报错截图、网络请求的响应内容等等。信息给得越全，AI 定位问题的准确率就越高。

除了解决 Bug，在日常开发中，我也会把 AI 当作一个结对编程的伙伴。比如，在写一个新功能前，我会先用自然语言和它聊聊我的实现思路，让它帮我评估这个方案是否可行，或者有没有更优的实现方式。在代码写完后，我会把代码交给它，让它帮忙 Code Review，检查一下有没有潜在的逻辑漏洞、性能问题或者不符合规范的写法。

对于一些重复性的工作，比如为函数编写单元测试、生成文档注释、或者将一段复杂的代码进行重构，AI 也表现相当不错。你只需要向它说明你的需求，它就能快速生成对应的代码，这能省下不少时间。

说到底，"Vibe Coding"的核心就是把 AI 当作一个有技术背景、能上网、但需要清晰指令的同事来沟通。不用去学习复杂的 Prompt 工程，而是通过直接、准确的对话来发挥它的作用，让它真正融入到你的开发流程中。

Vibe Coding 的一些问题

同质化、AI 味儿的页面风格

用 AI 写代码最头疼的，就是页面风格总像一个模子里刻出来的。因为在 AI 的"审美"里，或者更准确地说，在它学习的海量数据中，"精致好看"的样式往往就是几种最流行、最安全的设计模式的集合。这导致它生成的页面会反复出现以下几个特征：

大圆角，带阴影的容器。这几乎成了 AI 设计的"标配"。卡片式布局配上柔和、弥散的阴影，用来营造一种悬浮的层次感。这种风格在 Dribbble、Behance 等设计社区非常流行，AI 自然也就把它当成了最优解。
渐变色的按钮。特别爱用从左上到右下的线性渐变，颜色通常是明亮的蓝到紫，配上白字。这种按钮在视觉上非常突出，是许多SaaS产品和初创公司网站的经典设计，因此也被AI频繁复制。
用不同背景色或边框来区分模块。比如，当你想在落地页中并排展示三个产品特性时，AI 很大概率会给这三个特性卡片设置不同的、柔和的背景色，或者用不同颜色的左边框来做区分。这是一种常规的视觉分区手段，但 AI 会不假思索地默认采用，缺少创意。
滥用 emoji 或通用图标库。当需要图标时，AI 倾向于使用简单易懂的 emoji（比如 ✨, 🚀, ✅）或者像 Font Awesome、Heroicons 里的基础图标。虽然用起来快，但用多了，所有界面都像用了一套模板，缺了品牌味。
喜欢自己添油加醋地增加描述文案。这一点非常典型。一个齿轮图标，没文字你也能懂，但AI偏要加个'设置'标签。或者一个 todo 列表，它总喜欢在列表最上方加上一个大标题------"我的待办事项列表"，生怕你不知道这是个什么列表 🤷‍♀️。这种过度解释，源于它在训练数据中学到的"明确性"原则，但却常常忽略了设计中的"简洁性"和意境。

为什么会这样？

这种现象的根本原因，不在于 AI 有自己固定的"审美"，而在于它的学习机制。AI 模型是通过学习海量的现有网页、UI 设计稿和代码库来生成内容的。它学到的是一种统计学上的最大公约数------哪些设计元素最常出现、最被普遍认为是好看的。因此，它给出的方案，往往是当前设计流行趋势的一种平均化、模式化的体现，而不是真正有创意的设计。它会倾向于最安全、最常见的解决方案，从而抹平了许多设计的个性和独特性。

说白了，AI 没有自己的审美，它只是在模仿。它看过的网页、设计稿太多，自然就记住了最常见、最安全的那几种样式。所以它生成的东西，其实是'流行趋势的平均值'------看起来不错，但千篇一律，少了点个性。

这是我让 AI 直接生成的网站首页：

如果在 AI 出现之前，这样的风格其实也很好看，但是现在这样风格的网站其实已经很多了，我不想自己的首页有太强的 AI 味儿，这是我自己实现的页面：

既然知道有这些特征，那么我们就要尽可能的避免这些特征，在描述一些页面设计的时候，不要告诉 AI："帮我改的精致一点"，"帮我改的好看一点"，而是要具体描述，比如把"布局调的紧凑一点"，"整体圆角调小点"，"按钮颜色改成黑色"。但是这一切都是建立于你自己对于什么是好看的界面有一个基础概念，如果自己都不知道怎么设计，单纯依赖 AI 往往会让人比较失望。

代码耦合问题

如果我们没有对代码的实现有任何要求，AI 通常会把所有的功能都聚合在一个文件中，在 Text-Well 开发了大概两三周后，我的代码里有一个 TextEditor.tsx 组件就已经有三千多行代码，各种业务功能都被聚合在了这个文件中，而且里面还有很多冗余的代码。

对于完全没有经验的小白来说，可能真的没有解耦，逻辑分离这样的概念，当功能越来越多，一旦出现一个 Bug，排查起来就非常困难，尤其是用 AI 来排查 Bug ，每次要读取的代码量都特别大，不仅排查效率低，而且 token 消耗也是蹭蹭的涨。

因此，我们每完成几个功能的开发，就可以要求 AI 帮我们检查一下代码中是否有冗余逻辑，是否有单个文件过大的情况，让 AI 自己检查自己修复，我们只要确保功能不被破坏就好了。如果你自己有技术基础，那就更好了，直接告诉 AI 你想按照什么角度去拆解文件，以前端为例，一个大的页面可能可以拆分为多个可复用的函数，hook，组件，类型描述。如果你觉得组件间的参数传递的越来越多，而且很多都是重复的，那么你可以引入一个全局状态管理的功能来重构一下页面。

我自己就花了一个周末的时间让 AI 把项目里的状态管理和状态持久化，从原本的页面内部自己维护，通过 props 传参改为使用 jotai 进行状态维护，还把所有的类型定义都抽离到了统一的目录中进行维护。

这里有一些可以遵循的最佳实践技巧：

先规划结构，再填充代码。 动手前先让 AI 帮你画个文件结构图比如你直接跟 AI 说：'我要做个用户个人资料页，帮忙列下需要的文件结构' 这样 AI 就能帮你把代码各归其位，不乱堆乱放
单一职责原则。 说白了，就是每个文件只干一件事你可以跟 AI 说：'检查这个文件，看它是不是只管用户输入。要是还掺和数据或样式，就把它拆出去' 这能让代码的职责变得非常清晰。
定期进行代码检查。 每隔一两个功能迭代，别忘了来一次代码检查把整个组件的代码扔给 AI，问一句：'看看这段代码，有啥能改的？重点看能不能复用、可读性强不强、文件别太大'
将重构作为开发流程的一部分。 只要发现某端代码反复出现，就是该动手重构的信号了比如发现好几个页面都在显示登录用户信息，这时候就该考虑用全局状态了这时候就能让 AI 帮你接入 Jotai 之类的状态管理工具，把用户信息统一管起来，或者抽离为单独组件。

冗余文件/代码问题

这个问题在 cursor 早期很严重，基本上每完成一个功能就要写一个文档，告诉你他做了什么事情，在当前版本前几轮对话还好，对话次数多了之后也是爱写文档，claude code 就好很多，如果我们没有明确说明或者不是完成了一个很重大的变更，他就不会主动写文档。

如果我们没有主动去删除 AI 写的文档，系统里的文档就会越堆越多。以 Text-Well 作为例子，最开始我的用户额度设置是基于文本的字符数量的，但是后来发现这对英文的用户不太公平，因为英文的字符数量比较多，后续我把额度机制迁移为基于 Token 进行计算，但我在实现额度机制的时候已经有很多存量的文档都是与字符额度有关的，导致后续 AI 一旦参考到这些过期的文档就容易误改代码，把我的一部分逻辑又改回基于字符数量进行计算。

这种现象的深层原因，可以看作是一种上下文污染 (Context Pollution)。

AI 模型不像人一样有判断力，分不清哪些文件是新的、权威的，已经过时在它的眼里，所有被纳入上下文的文本文件，无论新旧，都是描述项目当前状态的依据。

这种情况还可能以其他方式发生：

过时的架构设计文档： 比如，一份早期的文档里描述了项目使用 REST API，但后来你已经将核心部分重构为了 GraphQL。当 AI 在上下文中读到这份旧文档时，它可能会给你生成调用 RESTful 接口的代码
被废弃的功能说明： 文档里描述了一个你早就放弃、根本不存在的功能模块当你让 AI 添加一个新功能时，它可能会试图去调用或集成这个根本不存在的"幽灵模块"。
临时写的注释或 TODO 项 有时我们会写一些临时的注释，比如 // TODO: 暂时硬编码 user_id，后续从认证服务获取。如果这个注释一直没有被清理，当 AI 在几个月后修改这段代码时，它可能会误解这是一个现行规则，从而继续保留硬编码，而不是采用你已经实现好的认证逻辑。

所以定期清理无用文档，才能让 AI 别被旧信息带偏除了及时删除无用文档，还可以建立一个明确的规则：在项目中创建一个核心的、始终保持更新的架构文档（例如 ARCHITECTURE.md）。在与 AI 对话时，可以主动引导它："请参考 ARCHITECTURE.md 里的描述来实现这个功能"。这相当于给了 AI 一个单一信息源，告诉它当信息冲突时，应该以哪个文件为准，从而大大降低被过期信息误导的风险。

一些总结思考

开发者是乐于创造，乐于挑战的，但一个项目中往往会有很多琐碎、麻烦、无聊的小事需要去做。比如，为 API 编写完整的类型定义，根据产品需求生成几十个单元测试用例，或者将一个复杂组件的文档注释补全。这些工作对保证项目质量很重要，但它们很少能带来创造的乐趣。

但有了 AI 编程之后，我们可以将很多这类琐碎的小事交给 AI 来完成，自己可以更专注于功能的设计和实现。这不仅仅是节省了时间，更是开发者角色的一次转变。我们不再需要把大量时间花在堆砌实现细节上，而是可以把更多精力投入到更高层次的思考中：比如梳理业务逻辑的核心流程，设计更优雅的数据结构，或者构思如何让用户体验更加流畅。当遇到一些真正棘手的疑难杂症时，我们再自己动手去深入排查。这种人机协作的方式，对于开发者实现自己天马行空的想法有很大的帮助。

很多时候，一个想法之所以没有被实现，不是因为它不可行，而是因为从零到一的启动成本太高。AI 极大地降低了这个启动成本，让我们可以快速验证一个想法的原型，用最低的成本去试错和迭代。

在开发和分享 Text-Well 时，我学到了很多。我对如何构建一个真正可用的 AI 应用，以及如何通过 vibe coding 与 AI 高效协作的有了更深的理解。在这个过程中，我还认识了许多优秀的开发者，我们一起交流的不仅是代码，更多的是如何与 AI 一起开发的经验和心得。如果你也想用 vibe coding 开发应用，欢迎一起聊聊。

这篇文章有很多地方都用了 Text-Well 来进行校对润色，包括标题和首图也是 Text-Well 生成的，最后给大家看看 Text-Well 中的评审人对于我现在的这篇文章的看法，我觉得写的很好：