前几天看到一篇文章《how to vibe code w/ claude code》https://x.com/elenakvcs/article/2008228601980985550 🔗，作者 Elena 是一位 AI 研究员，每天读论文、测模型、写报告，理解 AI 的工作原理，却从没自己写过代码。直到有一天她用自然语言向 Claude 描述了一个需求，45 秒后拿到一段 Python 脚本，运行，成功。原本要花 6 小时手动清理的 4000 行数据，一分钟搞定。
她完全不懂那些代码是什么意思。但它跑起来了。
这就是 vibe coding：不是学会编程，而是学会“说清楚你要什么”。
失败的人都栽在同一个坑里
大多数人对 vibe coding 有个误解：以为要先学点 Python 或 JavaScript 才能开始。
不是的。
vibe coding 的核心技能是沟通能力，是你能不能把需求描述得足够具体、足够清晰，让 AI 没有猜测的空间。
看这两段提示词的区别：
模糊版： “帮我做个邮件工具”
具体版： “写一个 Python 脚本，读取一个 CSV 文件，检查每一行的邮箱格式是否正确，去掉重复的，输出一个只包含有效邮箱的新 CSV，最后打印处理了多少行、多少无效、多少重复”
第一段提示词，AI 只能猜你想要什么，大概率猜错。第二段提示词，AI 不需要猜你想要什么，清楚的明白你想要什么，能按照你的需求生成代码，甚至还能帮你验证代码是否能满足要求。
这不是编程，这是把需求说清楚。
Elena 有一个比喻：把 AI 当成一个非常聪明但对你的情况一无所知的实习生。你不会跟实习生说“把那个数据处理一下”，你会说清楚是哪个数据、做什么处理、输出成什么样。对 AI 也一样。
怎么把需求说清楚？几个实用技巧：
- 说清楚处理逻辑（每一步做什么、先做什么后做什么、有什么特殊规则）
- 说清楚输出（结果长什么样、存到哪、要不要打印摘要）
你不需要懂技术术语，但你得像写工作交接文档一样，把每个细节想清楚写明白。
小步迭代：软件工程验证过的最佳实践
Elena 分享了一个典型的翻车经历。
她想做一个 Twitter 书签分析器：拉取书签、分析内容、按主题分类、生成周报。听起来不复杂。
第一次尝试，她直接告诉 Claude：“帮我做一个 Twitter 书签分析器”。
结果拿到一堆看不懂的代码，各种 API 调用、依赖安装、报错信息。折腾了 4 小时，放弃了。
一周后她换了个思路，同样的目标，完全不同的方法。
第一步： “写一个 Python 脚本，连接 Twitter API，拉取我最近的 100 条书签”。就这么多，不加别的。10 分钟，跑通了。
第二步： “把每条书签的推文内容提取出来”。又 10 分钟，跑通了。
第三步： “按我定义的关键词给它们分类”。跑通了。
第四步： “把结果保存成按分类整理的 JSON 文件”。跑通了。
一小时，她做出了比之前 4 小时失败版本更好的东西。
这是软件工程中被反复验证的最佳实践。
有一张经典的图对比两种开发方式。错误方式：先做轮子，再做车架，再做车身，最后组装成车。中间任何一步，用户拿到的都是一堆零件，什么都干不了。正确方式：先做滑板，能滑了；再加个把手变滑板车，能骑了；再升级成自行车，再升级成摩托，最后变成汽车。每一步用户都能得到一个“能用”的东西。
vibe coding 也是一样。不是每次迭代“一部分功能”，而是每次迭代“一个能跑的小版本”。哪怕只是最简陋的版本，只要它能独立运行、给你反馈，你就能知道方向对不对，然后在这个基础上继续加功能。
这就是为什么“一次性要完整系统”总是失败，而“每次只做一件事”总能成功。前者你得等到最后才知道对不对，后者你每一步都在得到正反馈。
让 AI 主动问你，而不是猜你
Elena 试过 ChatGPT、Cursor、Copilot、Gemini，最后固定用 Claude。
不是因为 Claude 写的代码更好，有时候其他工具写得更好。
是因为 Claude 会问。
用 ChatGPT 的时候，不管你的提示多模糊，它都会直接给你一个答案，让你自己发现哪里不对。而 Claude 经常会说：“确认一下，你是想要 X 还是 Y？”“我假设你要的是 Z，对吗？”
对于不懂代码的人，这个差别至关重要。那些澄清问题帮她省下了无数小时，本来可能在调试一个解决错误问题的代码。
不过，这个习惯是可以主动培养的。不管用什么工具，你都可以在交代任务时主动加一句：
- “请提供 2-3 个方案让我选择，说明各自的优缺点”
- “在开始写代码之前，先用自然语言描述你的实现思路”
如果你用 Claude Code 或者类似的 AI 开发工具，还可以把这些要求写进配置文件（比如 CLAUDE.md 或系统提示词），这样每次对话都会自动遵循。
另一个区别是 Claude 会解释它为什么这么写。不用问，它就会告诉你为什么选择这个方案。对于想边做边学的人来说，这些解释比任何教程都有用。
能做什么，不能做什么
六个月里，Elena 用 vibe coding 做了这些东西：
- 一个把 4 小时报表工作压缩到 10 分钟的内部工具
这些东西都不会改变世界。但它们都能跑，都在省时间或省钱。
一年前，这里面大多数要找开发者做，几百到几千美元一个。现在一个下午搞定。
这就是 vibe coding 真正的价值：不是让你变成工程师，而是让你能自己解决自己的问题。
但要清醒地认识边界。
适合 vibe coding 的场景： 个人自动化工具、一次性脚本、快速验证想法的原型、不涉及敏感数据的内部工具。
不适合的场景： 金融、医疗等需要高可靠性的系统；需要长期维护迭代的产品；多人协作的代码库；涉及用户隐私和安全的应用。
Elena 自己也说了：做复杂的、关键的东西，还是需要真正懂代码的人。但对于剩下那些场景：内部工具、自动化、简单产品、工作流优化，你不再需要工程学位。你需要的是清晰的思考和耐心。
从一个烦人的任务开始
Elena 这句话说的挺有道理：
“我到现在也不懂自己跑的代码在干什么。但我能做出东西来解决我的问题，这比任何证书都有用。”
这不是说编程不重要了。编程当然重要，尤其是当你想做更复杂、更可靠、更大规模的东西时。
但有了 AI，你不需要等到“学会了 Python”才开始。你可以先动手，边做边学。
如果你想试试，别从创业想法开始，别从产品开始。找一个你经常做、觉得烦、重复性高的任务。
比如说：
- 下载文件夹乱成一团，让 AI 写个脚本按类型、日期自动归档
- Excel 里一堆格式不统一的数据，批量处理、去重、格式化
- 每天要看好几个网站的更新，写个脚本自动抓取汇总发给你
- 经常要把 Markdown 转成别的格式，一键搞定
- 某个商品降价、某个账号发帖、某个日期到了，自动通知你
- 重命名几百个文件、给图片加水印、提取 PDF 里的文字，等等
然后像给一个什么都不知道的聪明人解释一样，把它描述出来：输入是什么，每一步要做什么，输出应该是什么样。
第一次大概率跑不通。别说“不行”，把报错信息贴上去，把相关代码贴上去，说清楚你期望发生什么、实际发生什么。
模糊的问题得到模糊的回答，具体的问题一轮就能修好。
反复修，直到能跑。保存。然后加下一个功能。
“我有想法”和“我做出来了”之间的距离，从没有这么近过。
