如果你现在还把“写代码”这件事，和“要学一门编程语言、啃完几十小时课程、装一堆开发环境”绑在一起，那你大概率会被这个故事震一下。
主角 Elena，本职是AI 研究员：
每天看论文、测模型、写报告，懂算法、懂模型原理，看 paper 没问题。
但一提到“动手做个工具”，她的直觉反应是：
“那是工程师的事，我是站在代码世界外面那一侧的人。”
直到有一天，她用 Claude Code，写下了人生第一“行”代码。
更准确说：她只是把需求讲清楚，Claude 帮她写完了代码。
这件事，直接把她的人生划了一道分界线。
下面这篇，就是她的“自救故事”，也是一套很适合普通人照抄的vibe coding 生存手册。
一、Vibe Coding 到底是什么？
先把这个看起来有点“互联网黑话”的东西，讲人话。
vibe coding：不是学写代码，而是学会怎么跟 AI 把事说清楚，让它替你完成“编码”这一步。
传统模式是这样的：
想法 → 自己学编程 → 自己动手写代码 → 慢慢试错
vibe coding 模式则是：
想法 → 把需求描述清楚 → Claude / ChatGPT 自动写代码 → 你只负责跑和调整
你不是在变成工程师，而是在变成一个
“懂自己要什么 + 会清晰表达需求”的项目 owner。
Elena 的身份很典型：
她懂 AI，但是不写代码，只会用工具。
在她眼里，世界被分成了两类人：
- 能写代码、能把想法变成产品的
- 不能写代码、永远在门外看的
她一直觉得自己是第二类，直到有一天她被现实教育了。
二、第一个转折点：4000 行垃圾表格，被 45 秒脚本救了
事情是这样开始的。
她有一个研究项目，核心痛点是：
一个表格，4000 行杂乱数据：
邮箱有的格式错了，有的重复，有的空缺。
她需要一个干净版本，再带一个汇总统计。
如果你做过运营、研究、产品分析，应该对这种表格有点 PTSD。
- 手工清洗：大概 6 小时
- 如果你会写脚本：半分钟左右
Elena 的做法没有任何“技术含量”：
- 1.打开 Claude
- 2.用完全自然的表达方式，把问题讲清楚：
- 3.“我有一个 CSV，里面有乱七八糟的数据，
一些邮箱格式不对，一些是重复的。
我需要一个干净的版本，只保留合法且不重复的邮箱，
最后顺便输出一个总数。”
- 4.Claude 回了她一段 Python 脚本
- 5.她复制、运行
几十秒后，脚本跑完了。
那一刻，她的描述是：
“我就那样坐在屏幕前，盯着输出结果发呆。
6 小时的工作，在 1 分钟内结束。
而我完全看不懂代码到底在做什么。”
这就是 vibe coding 的第一层冲击：
那天晚上，她直接上头：
- 写脚本整理下载文件夹
- 写工具从研究用的 API 拉数据
- 写自动化每天发论文摘要给自己
这些东西都很“小”，甚至谈不上产品。
但它们有一个共性：
解决的是她真实的日常问题，并且
以前她需要“找工程师帮忙”，现在她自己搞定了。
从这一步开始，她意识到：
“也许我不必永远站在那堵‘写代码的人和不会写代码的人’之间的墙外面。”
三、vibe coding 的真正难点：不是技术，而是表达
很多人在这一步就会误解：
“那我是不是要系统学 Python / JavaScript 才算开始 vibe coding？”
Elena 的答案非常明确：
No。vibe coding 的技能，不是编程语言，而是“清晰表达”。
她总结了一个典型现象：
- 大多数人都以为自己在“提需求”
- 实际上只是丢出一个模糊愿望
比如这种：
“帮我写个邮件工具。”
“做一个帮我管理书签的脚本。”
“给我做一个自动化工作流。”
然后，他们得到一个半残成品，抱怨 AI 水平太差。
问题并不在 Claude，也不在 ChatGPT。
问题出在你的 prompt 根本不够具体。
她用一个对比举得很形象：
坏 prompt：
“Build me an email tool.”
好 prompt：
“写一个 Python 脚本，从 CSV 读取数据；
对每一行，用 regex 检查邮箱格式是否合法；
用邮箱字段去重；
输出一个新 CSV，只保留合法且唯一的邮箱；
并在终端打印：
你会发现：
后者听起来“像在写代码”，
但其实本质上是：把需求拆解得足够具体。
她给这个能力起了一个更贴切的名字：
Clarity：把自己想要的东西解释到不可能被误解。
这时，AI 写代码的过程，才真正变成“翻译问题为程序”，而不是“编一个你也不知道要干嘛的功能”。
四、一个让她浪费几周的坑：一次性要一个“完整系统”
第二个致命问题，是范围管理。
她第一次想做的“正式项目”，是一个 Twitter 书签分析工具：
听起来很合理，非常适合产品人 / 研究者。
她当时的 prompt 很直觉：
“Build me a Twitter bookmark analyzer.”
结果 Claude 给了她一个“工程师级”的答案：
- 一长串她看不懂的 API 调用
- 一堆需要安装的依赖
- 一堆她读不懂的错误信息
她干了 4 个小时，
最后只能关掉 terminal，内心 OS：
直到一周后，她用完全不同的姿态重来了一次。
这次她只做了一件事：把目标拆得极其小。
- 2.“写一个 Python 脚本，连接 Twitter API，拉我最近 100 条书签。”
10 分钟搞定。
- 4.“现在从这些书签里提取出推文文本。”
再 10 分钟搞定。
- 6.“根据我给的关键词，把推文按话题分类。”
成功。
不到一个小时，她拿到了一个
比之前耗 4 小时还更好用、也更稳定的版本。
她的总结非常扎心：
差别不是“会不会写代码”，
而是“你是不是逼 AI 一次性做完所有事”。
从这之后，她给自己设了一条铁律：
- 永远不要让 Claude 一口气写“完整系统”
- 只让它先写“能做一件事的最小模块”
- 验证能跑，再往上叠一块
说白了：
五、为什么她最后站在了 Claude 这一边？
她并不是只用一个模型。
她把主流工具几乎都试了一遍：
- ChatGPT
- Cursor
- Copilot
- Gemini
结论反而很冷静：
大家都能用，都有各自的强项。
但如果是“我要用它来造东西”，
她最后留在手上的，是 Claude（特别是 Claude Code）。
她给的理由挺有意思，不是那种“模型分数更高”之类，而是两个很“人”的点。
1.1Claude 会“确认”，而不是“瞎做”
她发现一个模式：
- 有些模型，你说一句话，它就直接干
- Prompt 不清楚、逻辑有问题，它也不会问
- 结果就是：
- 你拿到一段很自信的代码，
过几个小时才发现这玩意儿在解决一个完全错误的问题
Claude 的行为则更像一个负责任的人类同事：
- “为了确认一下，你是想要 X 还是 Y？”
- “我假设你期望的是 Z，这样对吗？”
对新人来说，这种“澄清问题”的步骤，能节省非常多调错时间。
1.2Claude 会顺便“教学”，而不只是扔代码
第二个是学习体验。
Claude 经常会这么回复她：
对一个“边做边学”的人来说，这非常关键：
你不是在背函数，而是在一点点形成“对程序的直觉”。
她甚至说：
“我从 Claude 的解释里学到的编程概念，比从任何教程里学到的都多。”
Cursor 在她眼里更像是：
- 对懂代码的人极其强大
- 对不熟悉代码结构的人，门槛偏高
她的结论是：
真工程师：Cursor 可能更爽
非工程师 / 刚上手的人：Claude 更友好
六、她沉淀出来的一套“vibe coding 工作流”
如果你只打算带走这篇文章的一部分，那就带走这一节。
Elena 把自己试错几个月后的经验，浓缩成了一套流程：
1）从“结果”开始，而不是从“技术栈”开始
不要上来就说：
“我想用 Python 写一个调用某某 API 的脚本。”
应该说的是：
“我想：
把我的 Twitter 书签，整理成按话题分类的摘要，
每周给我一份。”
技术选型这件事，让 Claude 去考虑。
你只负责定义你想要的世界终态。
2）永远从最小版本开始
任何一个需求，都先问自己：
比如：
先做这一件，再加下一件。
3）频繁测试，别憋一大坨再跑
她的操作基本是这样的：
- 每写 20–30 行代码就跑一次
- 不会让错误积累成“你也不知道从哪里开始查”的状态
这其实是把“软件工程的最佳实践”，
用一种自然的方式移植进了新手工作流。
4）报错时，把所有信息都给 AI
绝对不要发一句：
而是要：
- 把完整 error message 贴上来
- 把相关代码段贴上来
- 说明：
你的问题越具体，Claude 越能一步到位地帮你修好。
5）永远备份“当前能跑的版本”
她吃过一次很惨的亏：
- 连续改了很久代码
- 一次改动改崩了
- 没有“上一版的备份”
- 直接损失 3 小时
后来的原则是：
每次做大改之前，都复制一份当前版本，
像“保存检查点”一样存起来。
6）如果可以，就在公开场合构建（build in public）
她开始在 Twitter 上公开分享自己在做什么。
这个有两个效果：
- 会逼着你把需求讲清楚（不然没人看懂）
- 会收获一些“你没想到的反馈和点子”
七、6 个月里，一个“非工程师”用 vibe coding 做出了什么？
她给了一份很诚实的清单：
- 自动抓取书签并分类的脚本：
每天早上跑一遍，帮她省掉 30 分钟 - Telegram 机器人：
监控特定研究者发帖，有更新就提醒她 - PDF 处理管线：
批量处理几百份 PDF，提取文本，生成可搜索的摘要 - Chrome 插件：
浏览网页时高亮特定关键词，看 paper /文章时更高效 - 内部报表自动化工具：
原本 4 小时的工作，现在 10 分钟 - 价格监控器：
盯着关心的商品价格，跌到阈值就提醒 - 简单爬虫：
把她研究需要的数据爬下来，整理进表格
这些都不是“独角兽级别产品”，
但它们有两个共同点：
- 1.都在真实地节省她的时间、精力和钱
- 2.一年前，这些东西她大概率会选择“找工程师做 + 付费外包”
现在，它们变成了一种新的路径：
非工程师 + Claude Code + 清晰表达，
一个下午就能搞定一个原本要花几百美金的小工具。
八、这对普通人意味着什么？
Elena 在后半部分讲了一个很现实但有点刺耳的观察：
她认识很多真正的工程师，
有多年经验，有很深的技术背景。
但在“实际出活”这件事上，
有时候他们反而不如刚学 vibe coding 半年的新人。
原因不是他们不够聪明，
而是思维惯性不同：
在一个 AI 把编码成本快速压低的时代，
市场更在意的是：
你能不能交付一个“解决问题的东西”，
而不一定是一个“架构完美的系统”。
她并不是在拉踩工程师。
相反，她讲得非常清楚：
- 复杂系统、关键基础设施、对安全性要求极高的东西
仍然必须由真正懂底层的人来做 - 但那 80% 的需求——
内部工具、自动化、简单产品、数据处理脚本……
已经不再需要工程学位
你需要的是：
九、如果你现在想开始 vibe coding，可以这样动手
如果你看完已经有点心痒，又不知道从哪开始，
可以直接照抄她的起步建议：
- 1.不要从“创业项目”开始
从一个你每天都在做、但觉得很烦的重复任务开始：
- 整理表格
- 重命名文件
- 转格式
- 拉数据汇总
越“蠢”的事情，越适合做起点。
- 2.像对一个聪明人解释流程那样讲给 Claude 听
- 我今天要做什么
- 输入是什么
- 中间大概要经历哪些步骤
- 最终输出长什么样
- 3.第一次跑，一定会出错，接受它
出错时，别说 “It’s not working”。
改成一套标准动作： - 4.只做最小版本，跑通，再加一点点需求
不要让 Claude 一次写完所有东西，
每次只多走一步。 - 5.记得保存每一个“能跑的版本”
你会感谢这些“存档点”。
走完这一轮，你就会真切体验到：
“我有个想法” 和 “我真的做出了一个能跑的东西” 之间，
现在只隔着几条好的 prompt。
十、写在最后：从“看别人做”到“我也能做”
Elena 在这篇长推的结尾写了一句话，我很喜欢：
“Stop watching. Start prompting.”
别再只是看别人造东西，
从自己写一个具体的 prompt 开始。
如果你是那种：
- 有很多想法，但总觉得“我不会写代码算了”
- 工作里被各种重复表格、报表、数据整理折磨
- 想搞点小自动化，又不想先学半年编程
那么 vibe coding 本质上是在告诉你：
你不一定要变成“工程师”，
才配拥有“自己造工具的能力”。
你要做的，
只是换一个起点：
从“学会语言再说”
变成“学会把事说清楚，让 Claude 帮你写语言”。
如果你愿意，我们其实可以把 Elena 的这套方法，
进一步改写成一门《7 天 vibe coding 入门小课》：
- 每天一个真实任务
- 每天一套 prompt 模板
- 每天一个“能跑的小工具”
你也许会惊讶地发现：
你需要的，从来不是一门语言，
而是一场“我也能做”的体验。
以下是全文翻译
如何使用 Claude Code 进行编码
原文：https://x.com/elenakvcs/status/2008228601980985550
1.我的第一行代码
6 个月前，我写下了人生中第一行代码。
这里的“写”，不是指跟着教程照抄；
也不是指从 Stack Overflow 上复制粘贴。
而是：
我把自己想要的东西描述给 Claude，
它给了我一段代码，
我跑了一下，然后它就成功运行了。
那些代码在做什么，我完全看不懂。
2.我的背景：会懂 AI，不会写代码
我的本职工作是做 AI 研究。
每天都在看论文、测试模型、写报告。
我在概念层面懂 AI 的工作原理，
但我从来没有亲手构建过任何东西。
总觉得会写代码的人和不会写代码的人之间有一道墙，
而我永远站在“错误”的那一边。
3.在 X / Reddit 上看到的“vibe coding”
然后我开始在 Twitter 和 Reddit 上，看到一堆人真的在上线产品。
@levelsio
我在 Node JS 环境下，只用了 2 小时就 "Vibe code"（凭感觉敲）出了我自己月费 4.99 美元的社交媒体截图服务
以前我每个月大约要在截图服务上花500 美元，因为我手头有很多网站，而且我喜欢把截图用作每个页面的社交媒体分享图（Social Media Images）。比如用户个人资料页、招聘贴、城市页面、Photo AI 上的照片包，甚至是 Nomads 和 Remote OK 上各种标签的筛选组合页。
我是个PHP 小子（PHPboi），所以我从来没在服务端写过纯 JS 的东西。老实说，如果没有 AI，我甚至不知道从何下手。但在 Cursor 的加持下，这事儿变得相当简单。
这个服务叫url2og.com，因为你只要输入一个 URL，它就会返回一张用于社交媒体的 Open Graph 图片。
我现在已经把自己所有的网站都切换到这个服务上了。它现在每天生成104,480张截图，也就是说每个月要生成超过300 万张。
技术栈细节：它运行在月费 4.99 美元的 Hetzner VPS 上，使用 Express 和 Node，并配合 PM2 进行进程管理。为了安全起见，它被隔离在独立的服务器上。核心功能使用 Puppeteer 和 Chromium 来进行截图，支持 Apple 表情符号（emojis），并使用 BullMQ 作为队列系统。
再说一次，我完全不知道这里面很多东西的原理是啥，也不知道我的做法对不对，但它确实能正常工作，所以我就把它部署到我所有的网站上了。
真的就是一些完全没有技术背景的随机路人，
在做工具、自动化工作流、上线创业项目。
他们不断提到一个词：vibe coding。
一开始我以为这是个梗，
类似 crypto bros 假装自己是开发者那种玩笑。
但他们做出来的东西都是真的：
能跑的产品、真正的生意。
4.那个让我熬夜到 3 点的小表格
有天晚上，我遇到一个很蠢的问题：
一个研究项目里，有一个包含 4000 行杂乱数据的表格。
我要把这些数据清洗干净、找重复项、统一格式、最后再输出一个汇总。
这种任务：
我打开 Claude，只是把我需要的东西说给它听。
不是用代码或者技术语言，而是直接说：
“我有一个乱七八糟的 CSV，其中有些邮箱格式不对，有些是重复的，
我需要一个干净版本：只保留格式正确且不重复的邮箱，
最后再输出一个总数。”
45 秒之后，我拿到了一段 Python 脚本。
我跑了一下，它成功了。
我就那样坐在屏幕前，盯着输出结果发呆：
6 小时的工作，在 1 分钟之内搞定。
而我对代码具体做了什么，一无所知。
那天晚上，我熬夜到了凌晨 3 点，瞎折腾了很多小东西：
- 一个整理下载文件夹的脚本
- 一个从我常用的研究 API 拉数据的小工具
- 一个每天给我发送本领域论文摘要的小自动化
这些东西都不“惊艳”，
但它们全都能跑。
然后我脑子里好像有什么东西被打开了，直到现在都没关上过。
那一刻，我意识到：游戏规则变了。
现在，我在“业余时间”靠 vibe coding 做出来的东西，
比我以前在没有工程背景的情况下能想象到的要多太多了。
5.为什么大多数人在 vibe coding 上会失败
一开始我犯的最大错误，是以为：
其实……不是。
真正需要学习的是：如何表达清楚。
关键技能不是 Python，也不是 JavaScript 或别的语言，
而是：清晰度（clarity）。
你要能把自己要的东西描述得毫无歧义。
而大多数人在这件事上，做得非常糟糕。
他们只会说一句：
然后奇怪为什么返回的结果一团糟，lmao。
gaut @0xgaut
“I just vibe coded this, it works flawlessly”
"我就这样随性写了这个代码，它运行完美无缺"
6.学到的第一课：你的问题太“懒”，AI 不是读心术
这件事对我来说一点都不轻松。
我是被现实毒打之后才明白这一点的：
我曾经在一个项目上花了好几个小时，一直没有任何进展，只因为我的 prompt 太敷衍了：
来来回回重复这些话，直到我想把电脑直接扔出窗外。
问题不在 Claude。
问题在于我——我在让它读心术。
“坏 prompt” vs “好 prompt”
糟糕的 prompt：
好的 prompt：
“写一个 Python 脚本，从一个 CSV 文件读取数据，
检查每一行的邮箱字段是否符合 regex 邮箱格式；
根据邮箱字段去重；
输出一个只包含格式合法且唯一邮箱的新 CSV；
并且在终端打印一份摘要：
- 总共处理了多少行
- 有多少行格式非法
- 有多少行是重复的。”
这不是在写代码，
这只是在非常具体地说明：我到底想要什么。
你说得越具体，Claude 猜的就越少。
它猜得越少，你越有可能得到一个真正能工作的结果。
像对实习生写说明书那样写 prompt
我现在把这件事类比成：
你在给一个非常聪明但完全不了解你的上下文的实习生做任务拆解。
你不会对实习生说一句：
就结束了。
你会告诉 TA：
- 到底是哪份数据
- 你要对它做什么处理
- 你希望最后的结果长什么样
Claude 也是一样。
每一条 prompt，你都要当成是在给一个聪明人写操作说明书：
聪明，但完全不了解你的背景。
7.那个让我浪费了几周时间的错误
第二个我花了超久才明白的问题是：
我的第一个“正式项目”就是个灾难。
我想做一个工具，可以：
- 拉取我的 Twitter 书签
- 分析这些推文内容
- 按话题分类
- 给我一份每周总结
听起来挺简单的。
于是我上来就写了这样一个 prompt：
彻底失败。
Claude 给了我一坨巨复杂的东西：
- 一堆我完全看不懂的 API
- 一堆我装不上的依赖
- 一堆我不知道为什么会报错的错误
我花了 4 个小时尝试让它跑起来，最后彻底放弃（感觉自己蠢爆了）。
那一刻我甚至觉得：
重来一次：拆小步走
一周后，我又试了一次。
还是同一个想法，但这次的做法完全不同。
我先说：
“写一个 Python 脚本，连接 Twitter 的 API，并拉取我最近 100 条书签。”
就这一个需求。没有别的东西。
然后我说：
再然后：
“现在根据我给定的一组关键词，把这些推文按话题分类。”
接着：
“现在把结果保存成一个 JSON 文件，按分类组织。”
一个小时之内，我就搞出了一个，比我上周那次折腾 4 小时还要好用的东西。
这两次的区别不是“能力”，而是“范围”：
我不再试图一次性做完，而是拆成一个个小步骤，
每一步都先保证能跑通，再往前走。
现在这就是我所有项目的标准流程：
- 我从不一开始就要“一个完整系统”
- 而是先要一个“只做一件事的最小部件”
- 让它先跑起来，保存好
- 然后，再加下一个部件
听上去好像很显然，
但几乎所有人都会忽略这点——
他们上来就想要一整个成品，结果最后什么都没做出来。
8.为什么我最终选择 Claude，而不是其他工具
到现在为止，我几乎能想到的工具都试了一圈：
- ChatGPT
- Cursor
- Copilot
- Gemini
- ……
它们都能用。
但真正让我一直在用来“做东西”的，只有 Claude。
不是因为 Claude 写的代码一定最好（有时候其他家反而代码质量更高，老实讲）。
而是因为：
“假设” VS “澄清”
在 ChatGPT 那里，我丢一个 prompt，它就直接开始干。
即使我的 prompt 不够清楚，或者本身就不合理，
它也会非常自信地给我一些东西，
然后让我在之后慢慢发现：
Claude 则会这样做：
“为了确认一下，你是想要 X 还是 Y？”
“我在假设你想要 Z，这样对吗？”
这个行为看起来很细微，
但当你根本不知道自己在干什么的时候，
这种澄清问题能帮你省下非常多时间。
不然你会花几个小时去 debug 一段“压根在解决错误问题”的代码。
自带讲解 VS 只给代码
还有一点是：
Claude 会在不用我主动询问的情况下，直接解释它在做什么。
我经常会收到这样一个组合结果：
而 ChatGPT 一般就是：
给你代码，然后就结束了。
对于一个一边做一边想学习的人来说，
这些解释的上下文非常重要。
我从 Claude 的解释中学到的编程概念，
比我从任何教程里学到的都多。
我没有收任何赞助。
这就是我自己乱试一通之后，最后反复回来的工具。
- 大部分时候我用浏览器里的 Claude
- 有时在做更大的终端项目时会用 Claude Code
关于 Cursor：
- 它很强大，但它假设你已经知道自己在干什么
- 它的界面默认你已经懂代码结构
对真正的工程师来说，可能是更好用的工具。
但对像我这样的用户——
只是描述自己想要什么，而不是亲自写代码——
9.我现在统一使用的工作流
经过几个月的瞎撞和反复试错，我现在给所有项目用的流程是这样的：
- 4.“我想把书签整理出来，并得到一个按类别排序的摘要。”
- 5.技术选型让 Claude 自己决定，你不需要替它选。
- 6.把任务拆成“最小第一步”。
无论你要造什么东西，先找到那个“只做一件事的最小版本”。
先做它，先让它能跑。 - 7.立刻测试。
不要写 200 行代码再跑。
每写 20～30 行就跑一次。
越早发现错误，越容易解决。 - 8.出错时，把所有信息都给 Claude。
不要说一句“它不工作”。
而是：
- “我遇到了这个错误”（把完整 error 粘贴上来）
- “这是相关代码”（贴对应的代码段）
- “我本来期望的行为是 X，实际发生的是 Y。哪里出了问题？”
- 9.不断保存“能跑的版本”。
每次大改动之前，都把当前能跑的版本复制存一份。
如果新逻辑把一切搞砸，你还有退路。
我就是因为没这么做，丢过 3 小时的工作量，才学乖的。 - 10.如果可以，尽量在公开场合构建。
我开始在 Twitter 上分享自己的小项目，
这些反馈让我的学习速度直接翻倍。
那个“具体性”的原则值得再重复一次，因为它就是全部：
模糊的 prompt → 模糊的输出。
具体的 prompt → 更大概率拿到可用结果。
没有什么魔法技巧，就是这么朴素。
10.这 6 个月里，我实际做出来了什么
被问得最多的问题是：
过去 6 个月里，我自己做了这些：
- 一个脚本，自动抓取我的书签并按类别整理。每天早晨跑一遍，每天节省我 30 分钟。
- 一个 Telegram bot，监控特定账号发帖，一有更新就提醒我。我用它追踪一些我关注的 AI 研究者。
- 一条数据流水线，可以处理上百份 PDF，提取文本，并生成可搜索的摘要。对我的研究工作来说是质变。
- 一个 Chrome 插件，在我浏览网页时高亮特定关键词。功能简单，但我几乎一直在用。
- 一个公司内部工具，把一个过去要花 4 小时的报告流程，压缩成 10 分钟。
- 一个价格追踪器，监控商品价格，一旦低于某个阈值就提醒我。帮我以更低价格买到本来就要买的东西。
- 一个简单的爬虫，抓取我研究需要的数据，并整理成表格。如果找人做，成本可能要几百美金。
这些东西都不会“改变世界”，
但它们都好用、都在实际节省我的时间或金钱，或者两者兼有。
一年前，如果我想要这些工具，大概率得请一个开发者来做，每个项目要付几百甚至几千美金。
现在，我只需要一个下午，就能自己把它们做出来。
真正的改变不是“我变成了工程师”（我没有）。
我到现在仍然看不懂自己跑的很多代码。
改变在于：
我能够自己做出真正解决问题的东西了。
这比任何履历或头衔都更有价值。
11.现在到底能做到什么程度
让我至今仍然感到震惊的一件事是：
我和很多“真正的工程师”聊过——
那些有着多年经验、懂一堆我听不懂概念的人。
其中一些人的“出活效率”，
甚至不如 6 个月前才开始 vibe coding 的人。
原因在于：他们的思维先看到的是约束。
看到一个问题，就会想：
“如果要按正规的工程方式做好这个东西，恐怕得花三个月。”
与此同时，另一个完全没有技术背景的人，只是把自己想要的效果描述清楚，
到了周二就已经有一个可用的原型了。
市场根本不在乎你的头衔或年限。
它只在乎你能交付什么。
而现在，一个思路清晰、迭代速度快的人，
完全可以在出活效率上超过一个纠结于“是不是最佳实践”的 CS 毕业生。
我不是在说 vibe coder 比工程师更强，我们并不是。
凡是复杂的、对安全性或可靠性要求极高的东西，
你还是需要真正懂底层的人来做。
但对那 80% 的场景呢？
这些东西现在真的不再需要工程学位了。
12.你应该如何真正开始
如果你看到这里，心里在想：
第一步：挑一件让你烦的重复性任务。
不要从一个创业点子开始。
也不要从一个大产品开始。
从一个让你觉得：
的小任务开始就行。
描述任务，而不是“下命令”
像对一个聪明但对你情况一无所知的人那样，把这件事讲给 Claude 听：
然后，运行它给你的代码。
第一次大概率不会成功。
出错时，别只说一句：
而是：
- 把完整的错误信息粘上来
- 把出错的代码段粘上来
- 说明你本来期待发生什么，以及实际发生了什么
模糊的问题会得到模糊的回答。
具体的问题，往往一条回复就能修好。
不断迭代，直到它可以跑通。
把这个“能跑的版本”保存下来。
然后，再加下一点点新功能。
就这样。
整个流程就是这么简单。
“我有一个想法” 到 “我做出了一个东西” 之间的距离，
从来没有像现在这么短过。
别再只看别人做。开始自己写 prompt。
13.最后：如果你也开始 vibe coding……
我会继续在这里分享我在做什么、学到了什么：
- 那些真正好用的工作流
- 那些真的省时间的 prompt
- 以及那些我踩过的坑——这样你就不用再踩一次
如果你觉得这些东西有用，就继续关注。
如果你在看完这篇之后做出了什么东西，记得告诉我。
我真的很想看看大家都做了些什么。
