一个人也能做产品！写给设计师的 Vibe Coding 入门指南

一、全文速览图

你是不是也有过这种纠结：

刷到别人用 AI 几小时搭出网站，心里痒得不行；可真上手时，面对一堆 AI 生成的代码，只剩“这改啥？哪错了？下一步干嘛？”的懵圈。

别慌，我懂——作为设计师，我从去年开始把Vibe Coding揉进工作流（维护公司前端组件库），踩过的坑、攒下的经验，会在今天的文章中进行分享。

二、Vibe Coding 到底是什么

1. 核心概念：一句话说明白

Vibe Coding 是 OpenAI 联合创始人 Andrej Karpathy 在 2025 年 2 月提出的概念，核心理念就三个字：

见 → 说 → 跑

1. 见：你看到一个问题或者想要的功能
2. 说：用自然语言描述给 AI 听
3. 跑：AI 生成代码，你直接运行

简单说，就是你从「写代码的人」变成了「描述需求的人 + 审核代码的人」。

这个概念来到国内后，就有了一个很浪漫的名字——「氛围编程」，也是大概从去年开始，作为设计师的我，在日常的工作中逐步接触和将一些写代码的事情融入到我的工作流程当中。甚至由于所从事的工作和公司级组件库相关，乃至于目前我有相当一部分的时间是用在，修改和维护公司级组件库上。因此，我想借助这个案例向大家介绍一下我的实践中踩的坑和沉淀的一些经验。

首先，我先向大家介绍一下我目前介入的项目。出于 AI 充分介入工作流的需要，我逐步参与并维护和优化调整一个基于 Vue3.x 的框架构建的前端组件库，并对其进行调整和优化。因此，在最初的时候，我对于组件的调整大部分是一些偏向前端的 css 属性的调整，随着相关工具和大模型的成熟和发展，我开始逐步尝试针对组件的源码进行调整和修复。在当前的这个项目中，我收获的第一个点是，需要了解整个代码的提交和审核的流程，目前我使用的流程大致如下：

当前在其中，相当多的节点，比如：测试，打包等环节目前还是需要真正的前端开发人员介入审核以保证输出的代码可以直接使用。在不断的尝试中，我总结了一些经验，与大家进行分享。

我见过太多人满怀信心地开始，然后一脸懵地放弃。问题不是他们不够聪明，而是他们或许忽略了这两个底层的逻辑。

❌ 底层逻辑一：以为可以完全不用懂代码

原型阶段可以不懂，但如果你想做出能上线的产品，必须能读懂 AI 写的代码。

AI 生成的代码可能有 bug、可能有安全隐患、可能有逻辑漏洞 —— 这些都需要你来审核。你不需要会写，但必须能看懂。在最开始的时候，我只初步掌握了html，css 和JavaScript这样的初级语言，而几乎完全不懂得vue的代码框架，所以在最终打包部署之前又真正有经验的前端大佬负责审核代码才尤为重要。

❌ 底层逻辑二：以为一句话能搞定一切

如果你还在幻想"给 AI 一句话，它给我一个完美的网站"，醒醒吧。

Karpathy 本人都说了：

"mega prompt 时代结束了，战略分解时代来了。"

复杂任务需要拆解、需要迭代、需要一步一步来。怎么说呢，“五彩斑斓的黑”是不存在的，如果你敢对 AI 提一个极其简单的需求，那 AI 就敢给你一个极其抽象的结果。

非程序员有效 Vibe Coding 的方法

好了，踩坑的事说完了，现在说正经的。

这部分是方法论的核心，我会讲：用什么工具、怎么提问、怎么组织项目、什么时候该收手。

2. 工具选择：按你的背景来

不要跟风选最火的，选最适合自己的。

我的配置：使用 Trae 搭配 GLM5.1 模型。

3. 五步工作流（这是核心方法）

不管你用什么工具，这套流程都适用：

Pick → Describe → Iterate → Test → Ship

选问题 描述需求 迭代构建 测试 部署发布

第一步：Pick —— 选一个你熟悉的问题

不要一上来就做"参考微信或者是钉钉，给我做一个类似的软件。"。选一个你日常遇到的、具体的小问题。

✅ 好例子：

"我想做一个每周读书清单的管理工具"

"我想做一个团队吃饭投票的小程序"

❌ 坏例子：

"我想做一个社交平台"（太大了，你会被淹没）

"我想做一个 SaaS 产品"（太模糊了）

第二步：Describe —— 用自然语言描述，但要具体

关键点：给目标，不给实现路径。

❌ 低效说法："做一个用户管理系统"

✅ 高效说法："做一个用户管理系统，需要支持邮箱注册、登录、修改密码。注册需要验证邮箱格式，密码至少8位。"

你需要告诉 AI：

1. 要什么功能
2. 有什么设计偏好（颜色、布局风格）
3. 有什么约束（必须支持手机端、加载不超过3秒）

第三步：Iterate —— 小步迭代，一次改一个问题

这是最最重要的方法论。

当你发现 AI 生成的东西有问题，不要一次性说 10 个修改意见。
每次只说一个，等 AI 改完，你测试，确认没问题，再提下一个。

❌ 错误示范：

"把这个按钮改成蓝色，表格加一列，用户名改成显示头像，表单加个验证..."

✅ 正确做法：

"先把按钮改成蓝色" → 测试确认 → "再加一列到表格里" → 测试确认 → ...

第四步：Test —— 马上测试，像用户一样使用

不要相信"看起来没问题"。你要真的去点、去输错、去断网。

问自己：

1. 按钮点下去真的有用吗？
2. 输入框空着提交会怎样？
3. 手机上显示正常吗？

第五步：Ship —— 部署分享，收集反馈

做出第一个版本就发布，别憋着。真实用户的反馈比你在家里想一百遍都有用。

4. 提示词五条铁律

这部分是实操中的技巧，直接拿去用。

铁律一：给目标，不给实现路径

❌ "用 React 的 useState 和 useEffect 写一个计数器组件"

✅ "页面顶部显示一个数字，点了按钮数字会增加"

让 AI 找方案，你来决定要什么。

铁律二：复杂任务先让 AI 做计划

当你有一个复杂需求时，先说：

"先别写代码，先给我一个实现计划，包含需要几步、每个文件大概做什么。"
这样你能从全局把握，不被 AI 带着跑偏。

铁律三：一次只做一件事

不要一次塞 10 个需求。你累，AI 也累，结果两边都不满意。

铁律四：设定角色和约束

❌ "写一个登录页面"

✅ "作为资深 React 工程师，要求：不用 any 类型，所有输入必须验证，响应式布局优先移动端"

给 AI 一个人设，它的表现会稳定很多。

铁律五：让 AI 审查自己

写完代码后，让 AI 换个角色做 code review：

"请以安全审计员的角色，检查这段代码有没有安全漏洞。"

AI 写代码时可能忽略的问题，换个角色审视时更容易发现。

5. 安全铁律（必须遵守）

这是底线，没有例外。

铁律一：认证和支付永远不要 Vibe Code

什么意思？

登录、注册、支付这些功能，必须用成熟的解决方案，不要让 AI 从头写。

✅ 正确做法：

1. 认证用 Supabase Auth、Clerk、Auth0
2. 支付用 Stripe、微信支付 API

❌ 错误做法：

"帮我写一个用户登录注册功能"（除非你只是学习）

铁律二：AI 输出 = 不受信任的代码

不管 AI 多么自信地说"这段代码完全安全"，你都要：

1. 自己读一遍
2. 至少跑一个安全扫描（当然，一般这个时候都是请公司的测试同事帮忙的）

铁律三：基础设施层做兜底

别指望代码层面的安全能挡住所有攻击。在基础设施层面加上保护：

1.  Cloudflare Zero Trust（WAF 防护）
2. 限流（防止被刷）
3. 监控告警（第一时间知道被攻击）

三、什么项目适合你，什么不适合

✅ 适合非程序员做的项目

❌ 不适合非程序员做的项目

一个判断标准：如果这个系统出问题会影响真实世界的金钱、健康、安全，就别用 Vibe Coding 自己做了。

四、什么时候该老实学代码

不是说学会写代码才能用 AI，但是遇到以下情况，你需要考虑系统学习：

信号一：调试时间 > 构建时间

如果你花 80% 的时间在修 bug，只有 20% 的时间在加功能，说明你的代码已经失控了。

信号二：需要深度定制

AI 能帮你生成标准功能，但当你想做独特的设计、复杂的交互时，你需要懂代码才能微调。

信号三：想做专业级产品

如果你想把这个东西当成正经产品来运营，终究需要理解底层逻辑。

信号四：AI 频繁犯错

如果同一个问题 AI 说了好几次都改不对，说明你们之间的沟通已经出现鸿沟了，你需要学基础才能指导 AI。

最后说几句

Vibe Coding 是个好东西，它让很多人第一次意识到：原来我可以做出自己的工具。

但它也有局限。AI 不是银弹，复杂的系统问题终究需要人的判断。

你需要的不是"会不会写代码"，而是"懂不懂你在做什么"。

懂需求、懂用户、懂业务 —— 这些你本来就擅长。加上 AI 的力量，你可以做出很棒的东西。

所以，别怕，去试试。