Vibe Coding 方法论：不会编程的人如何用 AI 写出能跑的代码

Vibe Coding 方法论：不会编程的人如何用 AI 写出能跑的代码 Vibe Coding 方法论：不会编程的人如何用 AI 写出能跑的代码 Modified January 10 Elena 有一个比喻：把 AI 当成一个非常聪明但对你的情况一无所知的实习生。你不会跟实习生说“把那个数据处理一下”，你会说清楚是哪个数据、做什么处理、输出成什么样。对 AI 也一样。 怎么把需求说清楚？几个实用技巧： • 说清楚 输入 （数据从哪来、什么格式、文件在哪） • 说清楚 处理逻辑 （每一步做什么、先做什么后做什么、有什么特殊规则） • 说清楚 输出 （结果长什么样、存到哪、要不要打印摘要） • 说清楚 边界情况 （遇到空值怎么办、格式不对怎么办） • 给个 例子 （比如输入是 A，输出应该是 B） 你不需要懂技术术语，但你得像写工作交接文档一样，把每个细节想清楚写明白。 小步迭代：软件工程验证过的最佳实践 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 做了这些东西： • 自动整理书签的脚本，每天早上跑一遍，省半小时 • 监控特定账号发帖的 Telegram 机器人 • 处理几百个 PDF 并生成可搜索摘要的数据管道 • 一个简单的 Chrome 扩展 • 一个把 4 小时报表工作压缩到 10 分钟的内部工具 • 价格监控器 • 数据抓取脚本 这些东西都不会改变世界。但它们都能跑，都在省时间或省钱。 一年前，这里面大多数要找开发者做，几百到几千美元一个。现在一个下午搞定。 这就是 vibe coding 真正的价值：不是让你变成工程师，而是让你能自己解决自己的问题。 但要清醒地认识边界。 适合 vibe coding 的场景： 个人自动化工具、一次性脚本、快速验证想法的原型、不涉及敏感数据的内部工具。 不适合的场景： 金融、医疗等需要高可靠性的系统；需要长期维护迭代的产品；多人协作的代码库；涉及用户隐私和安全的应用。 Elena 自己也说了：做复杂的、关键的东西，还是需要真正懂代码的人。但对于剩下那些场景：内部工具、自动化、简单产品、工作流优化，你不再需要工程学位。你需要的是清晰的思考和耐心。 从一个烦人的任务开始 Elena 这句话说的挺有道理： “我到现在也不懂自己跑的代码在干什么。但我能做出东西来解决我的问题，这比任何证书都有用。” 这不是说编程不重要了。编程当然重要，尤其是当你想做更复杂、更可靠、更大规模的东西时。 但有了 AI，你不需要等到“学会了 Python”才开始。你可以先动手，边做边学。 如果你想试试，别从创业想法开始，别从产品开始。找一个你经常做、觉得烦、重复性高的任务。 比如说： • 下载文件夹乱成一团，让 AI 写个脚本按类型、日期自动归档 • Excel 里一堆格式不统一的数据，批量处理、去重、格式化 • 每天要看好几个网站的更新，写个脚本自动抓取汇总发给你 • 经常要把 Markdown 转成别的格式，一键搞定 • 某个商品降价、某个账号发帖、某个日期到了，自动通知你 • 重命名几百个文件、给图片加水印、提取 PDF 里的文字，等等 然后像给一个什么都不知道的聪明人解释一样，把它描述出来：输入是什么，每一步要做什么，输出应该是什么样。 第一次大概率跑不通。别说“不行”，把报错信息贴上去，把相关代码贴上去，说清楚你期望发生什么、实际发生什么。 模糊的问题得到模糊的回答，具体的问题一轮就能修好。 反复修，直到能跑。保存。然后加下一个功能。 “我有想法”和“我做出来了”之间的距离，从没有这么近过。 Elena 有一个比喻：把 AI 当成一个非常聪明但对你的情况一无所知的实习生。你不会跟实习生说“把那个数据处理一下”，你会说清楚是哪个数据、做什么处理、输出成什么样。对 AI 也一样。 怎么把需求说清楚？几个实用技巧： • 说清楚 输入 （数据从哪来、什么格式、文件在哪） • 说清楚 处理逻辑 （每一步做什么、先做什么后做什么、有什么特殊规则） • 说清楚 输出 （结果长什么样、存到哪、要不要打印摘要） • 说清楚 边界情况 （遇到空值怎么办、格式不对怎么办） • 给个 例子 （比如输入是 A，输出应该是 B） 你不需要懂技术术语，但你得像写工作交接文档一样，把每个细节想清楚写明白。 小步迭代：软件工程验证过的最佳实践 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 做了这些东西： • 自动整理书签的脚本，每天早上跑一遍，省半小时 • 监控特定账号发帖的 Telegram 机器人 • 处理几百个 PDF 并生成可搜索摘要的数据管道 • 一个简单的 Chrome 扩展 • 一个把 4 小时报表工作压缩到 10 分钟的内部工具 • 价格监控器 • 数据抓取脚本 这些东西都不会改变世界。但它们都能跑，都在省时间或省钱。 一年前，这里面大多数要找开发者做，几百到几千美元一个。现在一个下午搞定。 这就是 vibe coding 真正的价值：不是让你变成工程师，而是让你能自己解决自己的问题。 但要清醒地认识边界。 适合 vibe coding 的场景： 个人自动化工具、一次性脚本、快速验证想法的原型、不涉及敏感数据的内部工具。 不适合的场景： 金融、医疗等需要高可靠性的系统；需要长期维护迭代的产品；多人协作的代码库；涉及用户隐私和安全的应用。 Elena 自己也说了：做复杂的、关键的东西，还是需要真正懂代码的人。但对于剩下那些场景：内部工具、自动化、简单产品、工作流优化，你不再需要工程学位。你需要的是清晰的思考和耐心。 从一个烦人的任务开始 Elena 这句话说的挺有道理： “我到现在也不懂自己跑的代码在干什么。但我能做出东西来解决我的问题，这比任何证书都有用。” 这不是说编程不重要了。编程当然重要，尤其是当你想做更复杂、更可靠、更大规模的东西时。 但有了 AI，你不需要等到“学会了 Python”才开始。你可以先动手，边做边学。 如果你想试试，别从创业想法开始，别从产品开始。找一个你经常做、觉得烦、重复性高的任务。 比如说： • 下载文件夹乱成一团，让 AI 写个脚本按类型、日期自动归档 • Excel 里一堆格式不统一的数据，批量处理、去重、格式化 • 每天要看好几个网站的更新，写个脚本自动抓取汇总发给你 • 经常要把 Markdown 转成别的格式，一键搞定 • 某个商品降价、某个账号发帖、某个日期到了，自动通知你 • 重命名几百个文件、给图片加水印、提取 PDF 里的文字，等等 然后像给一个什么都不知道的聪明人解释一样，把它描述出来：输入是什么，每一步要做什么，输出应该是什么样。 第一次大概率跑不通。别说“不行”，把报错信息贴上去，把相关代码贴上去，说清楚你期望发生什么、实际发生什么。 模糊的问题得到模糊的回答，具体的问题一轮就能修好。 反复修，直到能跑。保存。然后加下一个功能。 “我有想法”和“我做出来了”之间的距离，从没有这么近过。 🔗 原文链接： https://mp.weixin.qq.com/s/md idd3K... https://mp.weixin.qq.com/s/md idd3K... 原创 宝玉 宝玉AI2026年1月10日 13:31 美国 前几天看到一篇文章《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 不需要猜你想要什么，清楚的明白你想要什么，能按照你的需求生成代码，甚至还能帮你验证代码是否能满足要求。 这不是编程，这是把需求说清楚。