不懂代码也能做工具？Vibe Coding 新手避坑指南
什么是 Vibe Coding？
简单来说，Vibe Coding 就是用大白话告诉 AI 你想要什么，然后让它帮你写代码。这个说法由 Andrej Karpathy 在 2025 年初提出，后来甚至被《柯林斯词典》评为年度词汇。
虽然能做的事情多到让人眼花缭乱，但我目前最推荐的用法，还是给自己或团队做内部工具和工作流。我知道有些比我聪明得多的人已经用 Vibe Coding 做出了面向用户的产品，但如果你没有工程背景，我建议还是谨慎一点——先学会走，再想着跑。
另外，有些事情即使只是给自己或少数几个人用，也最好别碰。比如处理真实的金钱、存储他人的敏感信息，或者任何涉及法律合规的东西（医疗、金融、以及一堆 GDPR 义务相关的，统统不要碰）。
从小处着手，从安全的地方开始。
这篇文章里可能会出现一些你不熟悉的术语。我会尽量在文中解释，但文末也附了一份词汇表，需要更详细的说明时可以随时查阅。
在哪里 Vibe Coding：你需要的工具箱
Vibe Coding 需要的工具其实少得惊人。但在决定用什么方式做（用哪个 AI 工具来搭建）之前，你得先决定在哪里做。
一个有趣的事实：做自己的工具，并不一定需要把它放到互联网上或者“托管”在某个地方。它完全可以只存在于你的设备上。代价是你没法方便地在手机上打开它，而且这种方式可能需要稍微高级一点的 AI 工具。
基于这一点，你有两个选择：
浏览器端 vs. 笔记本电脑端
浏览器端搭建意味着一切都在一个网页应用里完成。你登录、描述你想要什么、看着它搭建、点击发布。这是门槛最低的方式，连托管都包含在内，你可以直接部署到一个网址上，完全不用操心。代价是你的作品存在于别人的平台上。
笔记本电脑端搭建意味着文件存在你的电脑上（至少一开始是这样），你电脑上的一个工具会跟这些文件打交道。设置更麻烦，但控制权更大。代码和你的工具可以永久保存在本地。但如果你需要让工具在其他设备上访问、或者分享给别人，你可以把项目连接到一个托管平台，推送到一个网址上（这些我们后面都会讲到，我保证）。
两种方式没有优劣之分。在笔记本电脑上搭建可能感觉更安全，但确实更偏技术一些。
要理解为什么，我们需要先了解一下……
两种类型的 Vibe Coding 工具
按使用所需的技术门槛从低到高排列：
1. 一体化应用搭建工具
这些是专门为 Vibe Coding 设计的浏览器端 AI 工具，自带托管功能。Lovable、Bolt 和 Replit 大概是这个类别里最知名的几个。你告诉它们你想要什么，它们就帮你搭建：前端、后端、数据库、托管，全在一个窗口里搞定，你的应用几分钟就能上线。
我就是从 Lovable 开始的，强烈推荐新手用它入门。它非常用户友好，还有大量的安全检查机制。代价是平台锁定——你的工具会住在那里。如果你离开，代码可以带走，因为 Lovable 会同步到 GitHub，但你得在其他地方重新接上数据库和托管。
💡 如果你完全没接触过编程，先从一体化应用搭建工具开始。 它会是一个用户友好的安全空间，让你在第一个项目中熟悉所有流程。这也意味着你暂时不用操心 GitHub、托管或终端。
2. AI 编程代理
这些是笔记本电脑端的。你描述你想要什么，代理就会处理你电脑上的文件：写文件、移动文件、运行文件、测试文件。Claude Code、OpenAI 的 Codex、Cursor、Devin Desktop 和 Gemini CLI 是主要的几个。我大部分时间都花在这里（目前主要用 Claude Code）。
有些代理住在终端里——终端就是你电脑上的一个纯文本窗口（我马上会详细解释，其实远没有听起来那么可怕）。你用英文输入，代理写代码，你完全不需要打开任何文件，除非你自己想看。Claude Code、Codex 和 Gemini CLI 最初都是这样的。
另一些，比如 Cursor 和 Devin Desktop，住在代码编辑器里，文件就摆在屏幕上，代理工作时你能看到它们实时变化。
现在大多数工具两种模式都支持，所以这个选择没有看起来那么重要。你只需要根据一点来决定：看到代码被写出来，是让你觉得更有掌控感，还是让你有点懵。
你还需要哪些其他工具
也就是：配角阵容。根据你上面选的方式，你可能还需要熟悉几个其他工具。如果你打算用第一种方式（比如 Lovable 这样的工具）做前几个项目——我强烈建议你这么做！——可以跳过这一节。
GitHub
如果说有什么词能让做营销的 Vibe Coder 心头一紧，那大概就是“GitHub”了。我一开始也觉得很吓人，直到有人跟我打了个比方：
GitHub 其实就是代码版的 Google Drive 或 Dropbox。
那为什么不直接用那些呢？技术上来说，你也可以。但 GitHub 特别的地方在于，它会保留所有记录。
它保存你项目的每一个版本，所以如果出了什么问题，你可以轻松回退到之前的版本。（做这件事的系统叫“git”，GitHub 是建立在它上面的网站。更多内容见词汇表。）这是你可能想把文件存在 GitHub 而不是本地的首要原因。
它还能防止你的文件在某个不幸的日子被一杯蛋白粉奶昔浇到笔记本电脑上时彻底消失。（如果你觉得这个例子太具体了不像是编的，你说得对。）
怎么用？
使用 GitHub 需要一个（免费的！）GitHub 账号，几分钟就能注册好。
注册完成后，你的代理需要获得代表你操作的权限。问它：“带我一步步安装 GitHub CLI 并登录。”这是一次性设置，没有它你的代理就没法帮你创建仓库——只会报错。
之后，开始一个新项目只需要提示：“把这个设置为一个 git 仓库，并创建一个私有的 GitHub 仓库。”让它去做就行。
（如果这一步现在对你来说还是太超前，你可以自己在 github.com 上创建一个空的私有仓库，然后告诉你的代理用那个。）
GitHub 的两条铁律：
- 不要提交你的密钥。 密钥 = API key、密码、任何你不想公开的东西。确保它们都不会进入 GitHub（即使你在私有仓库里工作）。
- 默认使用私有仓库。 你以后可以把项目改成公开的，当你想要反馈或做作品集时，公开是很好的。但那是“未来的你”要操心的事。
托管平台
如果你想在笔记本电脑以外的设备上使用你的应用或工具，或者分享给别人，它就需要住在互联网上的某个地方。
这时候就需要托管平台了。Vercel、Netlify 或 Replit 都是不错的免费选择。
怎么用： 同样，注册账号，然后把你的编程代理指向它就行。你的代理可能需要你偶尔手动做一些事情（主要是复制粘贴）。如果卡住了，问你的代理。
存放数据的地方
当你的工具需要在两次访问之间记住一些东西——保存的条目、你添加的列表——它就需要一个数据库。Supabase 通常是默认选择。如果这仍然感觉太超前，Airtable 或 Google Sheet 对于小型的个人工具来说也能胜任。两者都需要 API key，所以下面的安全规则同样适用。
怎么用： 创建一个免费的 Supabase 账号，把你的代理指向它。
终端
你电脑上那个可以用來运行命令的小黑框。Mac 上叫 Terminal，PC 上叫 Windows Terminal。
怎么用： 你不需要学命令，但偶尔可能需要打开它来粘贴一些东西。在本地搜索栏里输入 terminal 就能打开。同样，如果卡住了，让你的代理帮忙。别害怕在聊天里分享截图！
Node.js
某个时刻，可能会有工具让你安装 Node。它是在你自己机器上运行 JavaScript 项目的引擎，而这些工具搭建的大部分东西都是 JavaScript。
怎么用： 安装一次，然后永远不用再想它。你的代理没法帮你点击安装程序或输入管理员密码，但它可以一步步指导你。如果你用的是 Claude Code、Cursor 或 Codex，你可能想在开始搭建任何东西之前就提前搞定这件事。“带我一步步在我的笔记本电脑上安装 Node”是一个很好的第一个提示。
把环境设置好
想象你在跟一个私人助理合作，让他们处理几个需要文件的项目。你不太可能直接扔过去 12 个乱七八糟的文件夹，没有任何结构。你肯定会确保所有东西都命名规范、组织合理（你又不是花钱请他们整理 /downloads 文件夹的，对吧？）。
跟编程代理合作也是一样的。最好的部分是——你给它一个有条理、有逻辑的结构，它就会帮你保持下去。
- 创建一个“projects”文件夹。 建议你在搭建任何东西之前就做好。放在显眼的地方，比如 Documents/projects，或者桌面上，都行。
- 一个项目，一个子文件夹，每次都这样。 在你的主 projects 文件夹里，每个作品、工具或应用都应该有自己的子文件夹。忍住在一个已经能用的项目里做实验的冲动。如果是新想法，就给它一个新文件夹。
- 给子文件夹起好名字。 app、test、final 和 final-v2 可不是你想要的，朋友。如果你需要手动添加什么东西，用有逻辑的名字。
Vibe Coding 时的提示词最佳实践
给 AI 代理提示来搭建应用，跟让它帮你找便宜机票或起草营销报告其实差不多。以下是我发现能带来好结果的几个要点：
- 告诉它你不是工程师。 如果你的代理还不知道这个背景，值得在聊天里说明一下，否则你可能会一上来就被一堆让人困惑的术语砸晕。“我不是工程师。请用尽可能简单的方式解释，不要用技术术语。”
- 先让它帮你做规划。 这个对话是一场马拉松，不是短跑。先说明你想要什么，然后特别加上：“在你写任何代码之前，先帮我规划。用通俗的英语带我过一遍结构和我们需要哪些文件。”然后评估这个计划并迭代。代理很可能会对你的需求做很多假设，先确保它理解正确。
- 具体说明你想要什么。 不要说“给我做个内容工具”。试试：“我想要一个小网页，我把一段文字粘贴进去，它告诉我这段话在 LinkedIn 上大概会有什么效果——标出术语、标出企业腔、标出开头一堆 emoji 的。”
- 先功能，后形式。 这是一个过来人的教训——我在检查工具是否真的能用之前，花了大量时间反复重新设计 UI 和品牌。先确保工具按你想要的方式工作，然后再开始美化它。
- 小口吃。 我知道很诱人，但尽量忍住一次要求五个不同功能的冲动。搭建一个，测试一个，再继续下一个。
- 原样分享错误信息（最好带截图）。 如果出现错误，把完整的错误信息复制进去，包括那些看起来像象形文字的部分。你甚至可以分享你看到的截图。错误信息携带的信息比你想象的要多，总结会恰好丢掉识别问题的那部分。
- 直接问。 如果你觉得卡住了或者不确定下一步做什么，就问。如果你不喜欢某个东西目前的工作方式，就说出来，即使你不知道怎么修。代理可以给你提供无穷无尽的替代方案。
- 让它审查自己的代码。 当你的搭建进展不错时，让你的代理审查代码。“扮演一个高级工程师，审查这段代码”是我最喜欢的收尾步骤之一。
编程语言怎么办？
简短回答：工具会选。你会看到 TypeScript、JavaScript、Python、React 和 HTML 这些词滚过去。你不需要在它们之间做选择。Web 应用最终都是某种 JavaScript——现在通常是 TypeScript 和 React——而脚本和自动化最终都是 Python。
不过，值得知道的是它们不能互换。如果你从 Python 开始，然后决定想要一个漂亮的前端，这比听起来要麻烦得多，因为这些工具在项目坚持用一种技术栈时表现好得多。
这也是让工具在搭建之前先做规划的另一个好理由。随着计划推进，该用哪种语言会变得更清晰。除非有人给了你理由，否则不要直接点名要求某种语言。
安全：非开发者需要知道的事
对你搭建的东西要有分寸，特别是如果它不是纯本地、只给你自己用的应用。以下是一些安全最佳实践，帮你保护数据安全。
永远不要把 API key 放在代码里（或你的 AI 工具里）
如果你的应用需要连接另一个应用或服务才能工作——就像我 Vibe Coding 的内容日历连接 Buffer 那样——你需要一个叫 API key 的东西（很多工具，甚至大多数社交平台都提供）。API key 让你的应用能跟另一个服务对话，功能有点像密码。
它被称为“密钥”。你不希望这个 key：
- 出现在你的代码里
- 出现在 GitHub 上
- 出现在你的 AI 工具里
API key 应该放在一个叫 .env 的文件里，我建议你手动粘贴进去。
你的 AI 代理可能会让你把它粘贴到聊天里。相反，我建议在需要连接外部应用或服务时，用这个提示：
“我想保持我的 API key 安全，把它存在
.env文件里，而不是代码里。带我一步步操作。另外，确保不要把这个 key 暴露给浏览器。把调用放在服务端函数里。”
锁好前门
如果你把应用部署到一个网址上，即使只有你一个人知道这个网址，也值得锁上。但要具体说明怎么锁，因为“给它加个密码保护”并不像听起来那么万无一失。
如果任由代理自己发挥，它通常会把密码直接写进页面里。你会得到一个看起来像登录界面的东西，但密码就躺在代码里，任何人都能读到，而且完全可以被绕过。不太理想！
有两件事可以帮你解决这个问题：
- 最简单的办法是在托管平台上开启密码保护。Vercel 和 Netlify 都提供站点级别的密码保护，不需要写代码。（如果你不知道怎么操作，问你的代理要说明。）
- 另一种方式是要求真正的身份验证。提示词：“使用 Supabase Auth 设置正规的身份验证。我不希望密码存在于前端代码里。”
覆盖所有安全基础
使用密码管理器，因为你即将创建大量账号。设置强密码，并在 GitHub、托管平台和 AI 工具上开启双重验证。
Vibe Coding 创意：先做什么
开始最难的部分往往是选择。我经常因为可能性太多而不知所措，结果……什么都没做。
所以对于咱们这行的人，我给的规则是：做点能解决你自己工作流中一个小烦恼的东西。有没有你每天重复做的任务？或者你希望有某种方式来看报告？
如果你需要一些灵感，以下是我搭建过的一些最有用的东西的完整列表：
- Buffer 内容团队日历： 一个“主”日历，把我们所有的博客、新闻通讯、视频和社交帖子拉到同一个日历里（它还能通过 Buffer 的 API 排期！）
- 一个邮件应用，把我所有收件箱的邮件拉到一个中心，分类，并标记出需要我采取行动的。
- Kite Kids： 一个覆盖南非儿童活动的活动指南。（我和我丈夫一起做的，我希望这能变成一个有趣的副业！）
- Burrow： 一个任务整合器，把我所有工具里的待办事项拉到一起，还有一个勤劳的土豆桌面宠物（完成任务就能“喂”它）。
- 一个健身仪表盘，让我追踪训练和 PR。
还有一些来自 Buffer 团队的想法：
- Brandon 做了一个内容引擎，每周产出 21 条帖子
- Miguel 做了一个 MacOS 应用，总结他保存的待读文章
- Joe 做了一个应用，把他的宝可梦卡牌加到店里并通过 Buffer 推广
来自我们社区的：
- Shivani 做了一个内容库，让她可以搜索、分析并再利用她的 Buffer 帖子
- 她还做了自己的 LinkedIn 内容指挥中心
- Violeta 做了一个 AEO 内容工作流，找到 LinkedIn 上的空白并起草帖子到 Buffer
- Fahad 做了一个创意引擎，找到热门话题并在 Buffer 里排期
接下来怎么走
你不需要在第一天就做完所有这些。你不需要尝试这个列表上的每一个工具，不需要背下词汇表，也不需要在下一次晚宴上聊什么“repo”（实际上，我强烈建议你不要）。
你需要的，是愿意当几个小时的初学者——以及不断让你的代理修复、指导或解释的坚持。这就是我的速成课。
如果你做出了什么东西，我很想看看。来 Threads 找我，给我看看！
更多 Vibe Coding 资源
- 如何从 Claude 发布到社交媒体
- 社交媒体最佳 MCP 服务器
Vibe Coding 词汇表
API — Application Programming Interface 的缩写。它是一个应用打开的门，让另一个应用能跟它对话。我的内容日历通过 Buffer 的 API 拉取帖子。如果你的作品需要访问任何其他应用或服务的数据或功能，你就需要一个 API。
前端和后端 — 前端是你看到和点击的部分：按钮、文字、布局、颜色。后端是背后发生的一切：存储数据、做计算、跟其他服务对话。一个简单的工具可能只有前端。任何能在两次访问之间记住东西的，两者都有。
GitHub — 一个免费网站，你的项目文件住在那里，连同你保存过的每一个版本。本质上就是代码版的 Google Drive，但记忆力好得多。当你想要上线时，Vercel 和 Netlify 这样的托管平台也期望在那里找到你的项目。
Git — GitHub 所基于的版本追踪系统。Git 做实际记录每次保存的更改的工作；GitHub 是存储这些记录并展示给你的网站。你会在命令和代理的回复中看到这个词，但你其实不需要直接学它。
Repo — repository 的缩写。它是你项目在 GitHub 上住的文件夹。一个项目，一个 repo。除非有特别理由，否则保持私有。
Commit — 一个存档点。每次你 commit，git 就会把你项目当时的样子存一个快照，附上一小段关于改了什么的话。那个快照保存在你电脑上，直到你把它 push 到 GitHub，所以这两件事通常是一起做的。如果明天的版本出了问题，你可以回退到上一个能用的 commit。每当有东西能用了就 commit，不要等到你觉得做完了才 commit。
Secrets — 编程世界的密码：API key、数据库密码、任何能让陌生人进入你东西里的东西。密钥永远不进代码，永远不进 GitHub，最好也永远不要粘贴到你和代理的聊天里。
.env — 一个住在你项目文件夹里的小文件，存放你的密钥，跟其他代码分开。开头的点告诉你的电脑把它当作隐藏文件。搭配 .gitignore——一个告诉 GitHub 跳过哪些文件的文件——你的 key 就能安全地留在互联网之外。
