6 个月前，我第一次「写」代码。

不是那种跟着教程敲一遍，也不是从 Stack Overflow 复制粘贴。

而是我把需求跟 Claude 描述了一遍，它给了我一段代码，我直接跑起来，居然一次就成功了——而我几乎看不懂那段代码在干嘛。

我的本职工作是做 AI 研究：看论文、测模型、写报告。

我对 AI 的原理理解还算清楚，但从来没真正自己动手做过产品。总觉得会写代码的人和不会写代码的人之间有一道墙，而我永远在墙的另一边。

直到有一天，我在 Twitter 和 Reddit 上看到一堆人开始「发产品」。

很多都是完全没技术背景的普通人，却在做工具、自动化流程、甚至开小公司。他们嘴里反复提到一个词：vibe coding。

一开始我以为又是某种梗，像加密圈那种「装开发者」的玩法。但他们做出来的东西是真实存在的：能用的产品、跑起来的业务。

有天晚上，我遇到一个特别烦人的问题：一个研究项目的表格里有 4000 行脏数据。

我要把它清洗干净、找出重复项、统一格式、最后再生成一个汇总。手动做要 6 小时，如果我会写脚本，大概 30 秒就搞定。

我打开 Claude，直接用自然语言描述需求：

我有一个 CSV，里面的邮箱数据很乱，有的格式不对，有的重复。我想要一个干净的版本，只保留格式正确且唯一的邮箱，最后输出一个统计：总行数、无效的数量、重复的数量。

45 秒后，Claude 给了我一个 Python 脚本。我照着运行了一下——成功了。

6 小时的体力活，在 1 分钟内结束。我却几乎看不懂代码细节。

那天晚上我兴奋到凌晨 3 点：

  • 写了一个整理下载文件夹的脚本
  • 做了个从研究用 API 拉数据的小工具
  • 搞了个每天给我推送领域论文摘要的小自动化

这些东西都不算「厉害」，但它们都能用。那一刻，我脑子里某个开关被彻底打开了。

我突然意识到：游戏规则变了。

现在，我在本职工作之外，靠这种方式做的东西，比我以前想象的「非工程师能做的」多太多。

大多数人为什么「vibe coding」失败

我一开始犯的最大错误，是以为 vibe coding 的核心是「学会写代码」。

其实完全不是。

vibe coding 的关键不是编程，而是沟通。

真正的技能不是 Python、JavaScript，而是：把需求讲清楚的能力。

你要能用一种几乎不留歧义的方式，描述你想要什么。

大部分人都在这一步翻车。

他们会说：

“帮我做个能干 X 的 app。”

然后拿到一堆垃圾结果，再骂 AI 不行。

我自己也踩过这个坑。那段时间我经常对 Claude 说：

  • “帮我优化一下”
  • “不对，再改改”
  • “还是不行，你修一下吧”

来来回回几个小时，项目完全没进展，只想把电脑扔出窗外。

问题根本不在 Claude，而在我——我在让它「读心术」。

差的提示词：

“帮我做一个邮件工具。”

好的提示词：

“写一个 Python 脚本：

  • 输入：一个 CSV 文件
  • 对每一行检查 email 列是否是合法邮箱格式（用正则）
  • 根据 email 列去重
  • 输出：一个新的 CSV，只包含合法且唯一的邮箱
  • 运行结束时在控制台打印汇总：总行数、无效邮箱数量、重复数量。”

这不叫「会写代码」，这只是把自己想要的东西说清楚。

你越具体，Claude 猜的就越少；它猜得越少，结果就越接近你真正想要的。

我现在把 Claude 当成一个「非常聪明、但对你场景一无所知的实习生」。

你不会对实习生说：

“你帮我把数据那块搞一下。”

而是会讲清楚：

  • 是哪份数据
  • 要做哪些具体处理
  • 输出要长什么样

对 Claude 也是一样。每次写提示词，都当自己在给一个聪明但完全不了解背景的人写操作说明。

花了我几周才悟到的错误：别一口气做完

第二个让我浪费了大量时间的坑：一上来就想做「完整系统」。

我第一个「正式项目」是一个 Twitter 收藏分析工具：

  • 拉取我的书签
  • 分析每条推文内容
  • 按主题分类
  • 每周给我一份总结

听起来不复杂，我就直接对 Claude 说：

“帮我做一个 Twitter 书签分析器。”

结果当然是灾难。

Claude 给了我一大坨复杂代码：

  • 一堆我看不懂的 API 调用
  • 一堆装不上的依赖
  • 一堆我完全不知道怎么修的报错

我硬撑了 4 个小时，最后放弃，心里想：

可能 vibe coding 这套不适合我。

一周后，我换了个思路，从同一个想法重新开始：

第一步，只做一件事。

“写一个 Python 脚本，连上 Twitter API，拉取我最近 100 条书签。”

就这一个需求，别的都不管。

10 分钟，跑通了。

接着：

“在刚才的基础上，加一步：把每条书签里的推文文本提取出来。”

又 10 分钟，成功。

再接着：

“现在根据我给的关键词，把这些推文按主题分类。”

成功。

然后：

“把结果按分类存成一个 JSON 文件。”

也成功。

一个小时后，我得到的东西，比一周前那次「一口气做完」的尝试好太多。

区别不在于我突然变强了，而在于：

我把范围缩小了。

  • 每次只做一小步
  • 每一步都先跑通，再往上叠

现在我所有项目都按这个节奏来：

  1. 绝不一开始就要「完整系统」
  2. 先要一个只做一件事的最小版本
  3. 跑通、保存，再加下一块

听起来很常识，但几乎所有人都在犯相反的错：

  • 想一次性要一个「完美成品」
  • 最后什么都没真正跑起来

为什么我最后只用 Claude 来「造东西」

这半年我几乎把主流工具都试了一遍：

  • ChatGPT
  • Cursor
  • Copilot
  • Gemini
  • ……

它们都能用，但真正让我愿意长期用来「做项目」的，只有 Claude。

不是因为它写的代码永远最好（有时候别家写得更精致），而是因为：

Claude 会「问清楚」，而不是「乱猜」。

在 ChatGPT 里，我经常是这样：

  • 提了一个其实不太清楚的需求
  • 它也不问，直接给出一大段看起来很自信的代码
  • 我跑了半天才发现：根本不是我想要的东西

Claude 的习惯是：

  • “为了确认一下，你是想要 X 还是 Y？”
  • “我现在假设你需要的是 Z，这个理解对吗？”

这种小小的澄清，对一个「不懂底层、只会描述需求」的人来说，简直是救命。

它帮我省掉了无数次「调试了半天才发现方向错了」的时间。

还有一点很重要：

Claude 会主动解释它在做什么。

它通常会：

  • 先给你代码
  • 再用一小段文字说明：为什么这么写、关键逻辑在哪

而很多工具只会把代码丢给你就结束了。

对我这种一边做一边想「顺便学点编程」的人来说，这些解释比任何教程都有效。

我没有任何赞助，只是实话实说：

  • 日常在浏览器里用 Claude
  • 做大一点的项目、需要跑命令行时，用 Claude Code

像 Cursor 这种 IDE 类工具，非常强大，但前提是：

  • 你已经对代码结构有基本概念

对真正的工程师来说，它可能更顺手。

但对我这种「只会把需求讲清楚」的人，Claude 的对话式体验更自然。

我现在的固定工作流

折腾了几个月之后，我基本把自己的 vibe coding 流程固定成了这样：

  1. 从结果出发，而不是从技术出发
    不要一上来就说「我想用 Python + 某某 API」。
    而是说：「我想把我的书签整理成一个按主题排序的总结。」
    至于用什么语言、什么库，让 Claude 自己选。

  2. 把需求拆成最小可运行的一步
    任何项目，先问自己：

    • 「如果只做一件事，它会是什么？」 先把这一步做出来、跑通，再考虑下一步。

  3. 频繁测试，不要攒一大坨再跑
    不要等到 200 行代码之后才第一次运行。
    每改一小块、每 20–30 行就跑一下，问题会简单很多。

  4. 出错时，把所有信息都给 Claude
    千万别只说「不行」「报错了」。
    而是：

    • 贴完整报错信息
    • 贴相关代码片段
    • 说明「我本来预期会发生什么」

  5. 随时保存「能跑的版本」
    每次大改之前，都把当前能跑的版本复制一份。
    一旦新改动把一切搞崩，你还能回退。
    （我就是因为没这么做，白白丢过 3 小时的进度。）

  6. 如果可以，公开构建
    我后来开始在 Twitter 上分享自己在做什么。
    别人的反馈、问题和建议，让我的学习速度翻倍。

总结成一句话：

模糊的提示词 = 垃圾输出；具体的提示词 = 可用的代码。

没有什么「神秘技巧」，就是把话说清楚、把事拆小。

6 个月里，我实际做出了什么

很多人问我：

“靠 vibe coding，现实里到底能做出什么？”

过去 6 个月，我用 Claude 做了这些东西：

  • 一个每天自动抓取我 Twitter 书签、按主题分类的脚本，每天早上跑一次，大概帮我省 30 分钟整理时间。
  • 一个 Telegram 机器人，监控指定账号，一发新内容就给我推送，用来追踪我关注的 AI 研究者。
  • 一条处理 PDF 的数据流水线：批量提取文本、生成可搜索的摘要，对做研究来说是质变级别的提升。
  • 一个简单的 Chrome 插件，在网页上自动高亮我关心的关键词，虽然小，但几乎每天都在用。
  • 一个内部报表自动化工具，把原来要 4 小时的手工流程压缩到 10 分钟。
  • 一个价格监控脚本，盯着我想买的东西，一旦价格低于阈值就提醒我，已经帮我省了不少钱。
  • 一个小型网页爬虫，抓我研究需要的数据，自动整理成表格——以前我会为这种活付几百上千块给别人做。

这些东西都不是什么「颠覆世界」的产品，但它们：

  • 真正在跑
  • 每天帮我省时间、省钱

一年前，我会为其中大部分东西去找外包开发，动辄几百上千美金。现在，我可以在一个下午自己搞定。

真正的变化不是我变成了工程师，而是：

  • 即便我现在仍然看不懂很多底层细节
  • 我也能做出解决自己真实问题的工具

这比任何「会不会写代码」的标签都更有价值。

现在这时代，什么人会赢

这半年我和不少真正的工程师聊过：

  • 有多年经验的后端
  • 做基础设施的高手
  • 写底层系统的大神

他们懂的东西远远超过我。

但很有意思的是：

他们当中，有些人实际「发出来的东西」，反而比一些刚开始 vibe coding 半年的新人还少。

原因很简单：

  • 他们习惯从「约束」出发：
    • 这个要做得规范、安全、可扩展
    • 这样做要三个月
  • 而很多非技术背景的人，只是：
    • 把自己想要的效果描述清楚
    • 用 Claude 拼出一个「能跑的原型」

到周二，后者已经有一个能用的版本在跑了。

市场不在乎你有什么头衔，只在乎你能交付什么。

在现在这个时间点：

  • 一个思路清晰、敢快速迭代的人
  • 完全有可能在「产出」上超过一个纠结「最佳实践」的科班工程师

当然，我不是在说 vibe coder 比工程师厉害。

  • 真正复杂、关键、需要高可靠性的系统
  • 你一定需要懂底层原理的专业工程师

但对那 80% 的场景：

  • 内部工具
  • 自动化脚本
  • 简单产品
  • 工作流小改造

你真的不再需要一张工程学位证书。

你需要的是：

  • 把需求讲清楚的能力
  • 把问题拆小、耐心迭代的习惯

如果你想开始 vibe coding，可以这样入门

如果你看到这里，心里在想：

“听起来不错，但我到底该怎么开始？”

我建议你从一件最小的事做起：

  1. 选一个你经常做、又很烦的重复性任务
    不要从「创业点子」开始，也不要从「大产品」开始。
    就选一个每天/每周都在浪费你时间的蠢活。

  2. 像对一个聪明但不了解你工作的人一样，向 Claude 描述它
    讲清楚：

    • 输入是什么（文件？网页？API？）
    • 你现在是怎么手动做的（一步一步）
    • 你希望自动化之后的输出长什么样

  3. 让 Claude 给你一个最小可运行版本
    不要一上来就要「完整系统」，先要一个：

    • 能读入数据
    • 做一件简单处理
    • 输出结果

  4. 直接运行它，接受「第一次大概率会报错」这个事实
    报错是正常的，不代表你不行，也不代表 Claude 不行。

  5. 报错时，给 Claude 全部上下文
    不要说「不行」。而是：

    • 贴完整错误信息
    • 贴相关代码
    • 说明「我本来以为会发生 X，结果发生了 Y」

    你越具体，它越容易一次性帮你修好。

  6. 反复迭代，直到它稳定跑通
    跑通之后：

    • 把这个版本单独保存好
    • 再考虑加下一点小功能

整个过程其实就两件事：

  • 把问题讲清楚
  • 一步一步往前走

模糊的问题，只会换来模糊的答案；具体的问题，往往一两轮就能解决。

最后：从「看别人做」到「自己动手」

现在，想法和成品之间的距离，已经缩短到前所未有的程度。

你不需要：

  • 先学完一整门编程课
  • 再去啃厚厚的框架文档

你只需要：

  • 找到一个真实的问题
  • 把它讲清楚
  • 和 Claude 一起，把它拆成一小步一小步

别再只看别人发项目了，开始自己写提示词。

我会继续在这里分享：

  • 我在用的工作流
  • 真正省时间的提示词写法
  • 我踩过的坑（希望你不用再踩一遍）

如果这些对你有用，可以继续关注。

更重要的是：

如果你因为这篇文章做出了什么东西，真的欢迎告诉我——我真心想看看，大家都在用 vibe coding 做些什么。

现在，去做点什么吧。