如果你现在还把“写代码”这件事，和“要学一门编程语言、啃完几十小时课程、装一堆开发环境”绑在一起，那你大概率会被这个故事震一下。
主角 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：
“可能 vibe coding 不是给我的。”
直到一周后，她用完全不同的姿态重来了一次。
这次她只做了一件事：把目标拆得极其小。
- 1.第一步：
- 2.“写一个 Python 脚本，连接 Twitter API，拉我最近 100 条书签。”
10 分钟搞定。
- 3.第二步：
- 4.“现在从这些书签里提取出推文文本。”
再 10 分钟搞定。
- 5.第三步：
- 6.“根据我给的关键词，把推文按话题分类。”
成功。
- 7.第四步：
- 8.“把结果按分类存成 JSON 文件。”
完成。
不到一个小时，她拿到了一个
比之前耗 4 小时还更好用、也更稳定的版本。
她的总结非常扎心：
差别不是“会不会写代码”，
而是“你是不是逼 AI 一次性做完所有事”。
从这之后，她给自己设了一条铁律：
- 永远不要让 Claude 一口气写“完整系统”
- 只让它先写“能做一件事的最小模块”
- 验证能跑，再往上叠一块
说白了：
vibe coding 最大的敌人，是“贪心”。
五、为什么她最后站在了 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
绝对不要发一句：
“It’s not working.”
而是要：
- 把完整 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”。
改成一套标准动作： - 贴错误
- 贴相关代码
- 讲明自己期望 vs 实际结果
- 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 行杂乱数据的表格。
我要把这些数据清洗干净、找重复项、统一格式、最后再输出一个汇总。
这种任务：
- 手工做要 6 小时
- 如果我会写代码，大概 30 秒
我打开 Claude，只是把我需要的东西说给它听。
不是用代码或者技术语言，而是直接说：
“我有一个乱七八糟的 CSV，其中有些邮箱格式不对，有些是重复的，
我需要一个干净版本：只保留格式正确且不重复的邮箱，
最后再输出一个总数。”
45 秒之后，我拿到了一段 Python 脚本。
我跑了一下，它成功了。
我就那样坐在屏幕前，盯着输出结果发呆：
6 小时的工作，在 1 分钟之内搞定。
而我对代码具体做了什么，一无所知。
那天晚上，我熬夜到了凌晨 3 点，瞎折腾了很多小东西：
- 一个整理下载文件夹的脚本
- 一个从我常用的研究 API 拉数据的小工具
- 一个每天给我发送本领域论文摘要的小自动化
这些东西都不“惊艳”，
但它们全都能跑。
然后我脑子里好像有什么东西被打开了，直到现在都没关上过。
那一刻，我意识到：游戏规则变了。
现在，我在“业余时间”靠 vibe coding 做出来的东西，
比我以前在没有工程背景的情况下能想象到的要多太多了。
5.为什么大多数人在 vibe coding 上会失败
一开始我犯的最大错误，是以为：
vibe coding 的核心是“学会写代码”。
其实……不是。
真正需要学习的是：如何表达清楚。
关键技能不是 Python，也不是 JavaScript 或别的语言，
而是：清晰度（clarity）。
你要能把自己要的东西描述得毫无歧义。
而大多数人在这件事上，做得非常糟糕。
他们只会说一句：
“帮我做一个能干 X 的 app。”
然后奇怪为什么返回的结果一团糟，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：
“帮我做一个 twitter 书签分析工具。”
彻底失败。
Claude 给了我一坨巨复杂的东西：
- 一堆我完全看不懂的 API
- 一堆我装不上的依赖
- 一堆我不知道为什么会报错的错误
我花了 4 个小时尝试让它跑起来，最后彻底放弃（感觉自己蠢爆了）。
那一刻我甚至觉得：
也许 vibe coding 根本不适合我。
重来一次：拆小步走
一周后，我又试了一次。
还是同一个想法，但这次的做法完全不同。
我先说：
“写一个 Python 脚本，连接 Twitter 的 API，并拉取我最近 100 条书签。”
就这一个需求。没有别的东西。
- 它成功了，花了 10 分钟。
然后我说：
“现在把每条书签的推文文本提取出来。”
- 成功了，又是 10 分钟。
再然后：
“现在根据我给定的一组关键词，把这些推文按话题分类。”
- 也成功。
接着：
“现在把结果保存成一个 JSON 文件，按分类组织。”
- 继续成功。
一个小时之内，我就搞出了一个，比我上周那次折腾 4 小时还要好用的东西。
这两次的区别不是“能力”，而是“范围”：
我不再试图一次性做完，而是拆成一个个小步骤，
每一步都先保证能跑通，再往前走。
现在这就是我所有项目的标准流程：
- 我从不一开始就要“一个完整系统”
- 而是先要一个“只做一件事的最小部件”
- 让它先跑起来，保存好
- 然后，再加下一个部件
听上去好像很显然，
但几乎所有人都会忽略这点——
他们上来就想要一整个成品，结果最后什么都没做出来。
8.为什么我最终选择 Claude，而不是其他工具
到现在为止，我几乎能想到的工具都试了一圈：
- ChatGPT
- Cursor
- Copilot
- Gemini
- ……
它们都能用。
但真正让我一直在用来“做东西”的，只有 Claude。
不是因为 Claude 写的代码一定最好（有时候其他家反而代码质量更高，老实讲）。
而是因为：
Claude 会“确认”，而不是“假设”。
“假设” VS “澄清”
在 ChatGPT 那里，我丢一个 prompt，它就直接开始干。
即使我的 prompt 不够清楚，或者本身就不合理，
它也会非常自信地给我一些东西，
然后让我在之后慢慢发现：
哦，原来一开始问题就没说清楚。
Claude 则会这样做：
“为了确认一下，你是想要 X 还是 Y？”
“我在假设你想要 Z，这样对吗？”
这个行为看起来很细微，
但当你根本不知道自己在干什么的时候，
这种澄清问题能帮你省下非常多时间。
不然你会花几个小时去 debug 一段“压根在解决错误问题”的代码。
自带讲解 VS 只给代码
还有一点是：
Claude 会在不用我主动询问的情况下，直接解释它在做什么。
我经常会收到这样一个组合结果：
- 一段代码
- 再加一小段文字，解释它为什么这样写
而 ChatGPT 一般就是：
给你代码，然后就结束了。
对于一个一边做一边想学习的人来说，
这些解释的上下文非常重要。
我从 Claude 的解释中学到的编程概念，
比我从任何教程里学到的都多。
我没有收任何赞助。
这就是我自己乱试一通之后，最后反复回来的工具。
- 大部分时候我用浏览器里的 Claude
- 有时在做更大的终端项目时会用 Claude Code
关于 Cursor：
- 它很强大，但它假设你已经知道自己在干什么
- 它的界面默认你已经懂代码结构
对真正的工程师来说，可能是更好用的工具。
但对像我这样的用户——
只是描述自己想要什么，而不是亲自写代码——
Claude 要简单得多。
9.我现在统一使用的工作流
经过几个月的瞎撞和反复试错，我现在给所有项目用的流程是这样的：
- 1.从“结果”而不是“技术”开始。
不要上来就说：
- 2.“我想用 Python + 某某 API。”
- 3.而是说：
- 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
- 以及那些我踩过的坑——这样你就不用再踩一次
如果你觉得这些东西有用，就继续关注。
如果你在看完这篇之后做出了什么东西，记得告诉我。
我真的很想看看大家都做了些什么。
现在，去做点什么吧。
加入XiaoHu.ai 日报社群 每天获取最新的AI信息
____________
End.
感 谢 阅 读，都看到这了，还不...
点赞，转发，关注关注关注↓↓
