项目标题是“Awesome Vibe Coding 资源大全文章、社区与学习路径汇总”。很多人第一次看到“Vibe Coding”这个词都会觉得就是“让 AI 帮我写代码”的另一种说法于是随手收藏几个链接觉得已经了解了。但真到要用的时候才发现收藏夹里那些标题漂亮的文章一大半讲的是三个月前某个模型的脾气剩下的则是“我花二十分钟做了个 App”式的展示看完还是不知道明天上班该从哪一步开始。这篇文章想解决的就是这个落差把散落在各处的资源按“你到底要解决什么问题”重新排一遍把学习路径拆成能落地执行的阶段也把我在这个过程中踩过的坑原样摆出来。不管你是刚接触这套工作方式还是已经用它交付过几个小项目下面这些内容应该都能直接拿去用。1. 先把“凭感觉写代码”这件事说清楚Vibe Coding的真实边界这个词在开发者社群里流传开来的时候带着很浓的实验色彩。它的字面意思是“跟着感觉写代码”但实际指代的是一套更具体的工作方式你用自然语言描述想要的结果由模型生成或修改代码你的注意力从“这一行语法对不对”转移到“这个行为是不是我想要的”。听起来门槛很低实际上它对使用者的判断力要求比传统写码更高——因为你不再逐字敲就必须更快地看出哪里不对。1.1 它省掉的是重复劳动不是判断能力很多人对这套方式的第一个误解是以为它主要服务于“不会写代码的人”。我接触下来的实际情况恰好相反用得最顺手的往往是那些有几年经验、清楚一个功能该长什么样、也知道代码烂在哪里的人。原因很朴素——模型给出的东西对不对你得有能力一眼看出来。一段循环边界写错了、一个异常没捕获、一个数据库查询放在了循环里这些在生成结果里都非常常见而有经验的人扫一眼就知道要打回去重写。所以准确地说Vibe Coding 省掉的是手速成本和样板代码的体力成本不是判断成本。它能让你在半小时内搭出一个能点开看效果的原型但能不能把这个原型变成能上线的东西取决于你自己对工程约束的理解。这个定位想清楚了后面所有资源该怎么筛、路径该怎么走都会顺很多。1.2 三个能力层级玩具、半成品、可交付我把这套方式的使用水平粗略分成三层这个分层会贯穿全文因为你收藏的每一条资源基本都能归到其中某一层去。层级典型产出关键能力常见失败方式第一层玩具单文件脚本、数据清洗、正则生成、命令行小工具把需求讲清楚需求含糊来回改十轮还是不对第二层半成品多文件小应用、带界面的原型、内部工具上下文管理、模块拆分文件越加越多模型开始“忘事”第三层可交付有测试、有版本控制、能交接给别人的项目验收标准设计、回归防护改一个地方悄悄坏掉另一个地方绝大多数人卡在第二层到第三层的过渡上。第一层的资源各种提示技巧、单文件示例遍地都是随便一搜一大把第三层的资源怎么给生成代码写测试、怎么设计可回滚的改动粒度反而少因为这需要真实项目里摔过才写得出来。这也解释了为什么很多人收藏了几百条链接水平却一直停在第一层——他们囤的全是第一层的资源。1.3 什么场景该用、什么场景碰都别碰这一节可能是全文最该记住的部分。我的判断标准很直接错误的代价是否可逆。适合直接上的场景一次性数据处理脚本、内部工具的界面原型、正则和配置文件生成、陌生库的快速试跑、为自己写的小自动化、文档和注释补全、把一段老代码翻译成另一种写法做对照。这些场景有个共同点——搞错了重来一遍的成本很低几分钟的事。需要极度谨慎甚至不建议用的场景涉及资金流转的逻辑、权限与鉴权、并发与锁、性能敏感的热路径、需要长期维护且多人协作的核心模块、任何一行出错会造成实际损失的代码。这些地方的共同点是错误不可逆或者发现得太晚。我在一个内部小工具上就吃过亏让模型生成了一段批量更新数据的分支逻辑测试环境跑得挺顺因为数据量小条件恰好没命中那个写反的比较符。这种事情不是模型“不行”而是它本来就不该承担这种判断。2. 一份能用的资源清单长什么样分类骨架与筛选打分市面上那类以 Awesome 打头的清单仓库我前后翻过不少。它们的通病是只做加法不做减法——收录标准基本是“有人提了 PR 且链接能打开”于是清单越来越长可用性越来越低。你想找“怎么让模型在有十个文件的项目里不乱改代码”翻完三屏全是工具名和一句话简介没有一个回答你的问题。2.1 按“我要解决什么”分类比按首字母排更有效我自己整理清单时用的是问题导向的分类一共六类每一类对应一个具体的卡点概念与观点类讲这套方式适合什么、不适合什么、为什么。作用是校准预期避免高估工具。工作流与提示结构类讲怎么组织需求描述、怎么分步、怎么给上下文。这是第二层的核心资源。工具与集成类编辑器内置助手、终端里的命令式助手、网页对话式生成、本地模型配合插件。按“你在哪写代码”来选不是按排行榜选。实战复盘类别人从零做一个东西的完整记录。价值最高的是那些包含失败段落的。社区与讨论区遇到具体问题时能提问的地方。风险与反思类讲生成代码的安全隐患、许可证问题、可维护性衰减。这类资源冷门但值得专门留一格。这个分类的好处是当你卡住的时候能直接定位到该看哪一格。比如“模型总是改坏我别的文件”答案在第二类“这个生成的依赖库能不能商用”答案在第六类。按首字母排的清单永远给不了这种指引。2.2 四条硬筛选标准不达标就别占收藏位翻资源的时候我会用下面四条快速过一遍两条不满足的基本直接关掉有没有写清楚上下文。用了什么模型、什么版本、什么规模的代码库、给了多少上下文。缺这些信息的“效果惊艳”类内容参考价值接近于零因为模型迭代太快三个月前的结论很可能已经反过来了。有没有讲失败的部分。只讲成功路径的复盘信息密度通常很低。真正有营养的是“我一开始这么写结果它把整个模块重构了后来我改成这样”。有没有可复现的中间产物。哪怕只是一段目录结构、一份项目说明文件的样例、一段提示词原文都比纯文字描述强十倍。是不是还在更新。这个领域半年的变化量顶得上别的领域三年一条两年前的经验如果不标注时间很容易把人带沟里。2.3 我给每条资源打的三个标签除了分类我还会给每条资源打三个标签方便以后检索可复现、讲失败、有日期。前两个是加分项第三个是必需项——没有日期的经验我基本不存因为无法判断它是否还成立。顺带说一句关于“资源大全”这种形式的看法。清单本身的价值不在于它有多长而在于它能不能帮你少看一些东西。一份好的清单应该告诉你“这三条看完就够了剩下的先别管”而不是把两百个链接平铺在你面前。我后来把自己的清单砍到了三十条以内使用频率反而高了很多。3. 从看热闹到真上手四段式学习路径的每一段该干什么资源看多了容易产生一种错觉好像懂了就是会了。我见过太多人把方法论文章读得滚瓜烂熟一上手发现连第一步该开哪个窗口都不确定。路径这件事关键不在于分几段而在于每一段都有明确的毕业标准——你怎么知道自己可以进下一段了。3.1 第 0 段先把回滚能力建起来再谈生成这一段最容易被跳过也最不该跳过。在让任何模型碰你的代码之前先确保三件事到位代码在版本控制里、有一个能一键跑起来的本地环境、知道怎么丢弃全部改动。原因很简单这套工作方式的本质是“高频试错”而试错的前提是错了能退回去。我刚开始的时候图省事在一个没有提交过的工作目录里让模型改文件结果它顺手“优化”了一个本来没问题的配置文件等我发现的时候已经找不到原来的样子了只能凭记忆重写。那次之后我给自己定了个规矩每次开始生成前先提交一次哪怕这次提交毫无意义。这一步花五秒钟能省掉后面半小时的排查。这一段的毕业标准你能在三十秒内把工作目录恢复到任意一次提交的状态并且清楚哪些文件属于“生成区”、哪些属于“手写区”。3.2 第 1 段单文件脚本是练手感的最佳沙盒第一段的练习素材建议全部选单文件、无依赖、跑一次就结束的东西读一份表格算个汇总、把一批文件按规则改名、写个命令行参数解析的小工具、生成一段固定格式的文本。这类任务的好处是边界清楚模型不容易跑偏你能快速感受到它的“脾气”——比如它对边界条件的默认处理是什么、它喜不喜欢自作主张加功能、它写的错误处理是敷衍还是认真。这一段的核心训练目标不是写出多好的代码而是学会怎么描述需求。我自己的经验是同一件事用三种不同详细程度描述一遍对比结果差别这个过程比看十篇提示技巧的文章都管用。具体来说第一遍只说要什么结果第二遍补上输入输出格式和边界情况第三遍再加一句“不要做我没提到的事”。三遍下来你会清楚地看到模型跑偏往往不是能力问题而是我自己的描述留了太多空白让它填。这一段的毕业标准你能一次性描述清楚一个五十行以内脚本的需求生成结果基本不用改就能跑。3.3 第 2 段多文件项目才是真正的分水岭从单文件到多文件难度不是线性增长是跳变的。原因在于上下文窗口的物理限制模型一次能“看见”的内容有限文件一多它就开始忘事——刚跟你确认过的接口签名隔两个文件就变了样明明说好不要动某个模块它还是顺手改了。这一段要练的是三件事。第一是模块划分尽量让每个文件的职责单一改动的影响范围可控这样即使模型理解偏了炸的也只是一小块。第二是项目说明文件在仓库根目录放一份描述性文件写清楚目录结构、技术栈、约定俗成的写法、哪些文件不要动。这个文件每次对话都要带上效果比反复口头强调强得多。第三是改动粒度控制一次只让它改一个关注点改完验收、提交再进下一个。这一段的毕业标准一个五到十个文件的小项目你能在不推翻重来的情况下迭代五轮以上。3.4 第 3 段测试和版本控制是唯一的护栏到了这一层讨论的已经不是“怎么让它生成得更好”而是“怎么保证它改坏的时候我能立刻知道”。答案没什么新鲜的测试。有意思的是测试在这个工作流里有个额外作用——它本身就是最好的需求描述。你写一个测试用例等于用代码精确地告诉模型“这个函数的输入是什么、输出必须是什么、异常情况怎么处理”。比起用自然语言描述半天一段测试用例的沟通效率高得多。我现在的习惯是改动稍微复杂一点的逻辑时先让它按我的描述补测试我审一遍测试对不对再让它改实现。这样顺序反过来出问题的概率低很多。这一段的毕业标准你能在让模型改动一段核心逻辑之后十分钟内通过测试确认没有回归。4. 社区与信息源在噪音里筛出真正能用的几条信息源这件事多不等于好。我有一段时间同时订了七八个周报、十几个讨论区、一堆视频频道结果每天早上光扫标题就花掉四十分钟真正有用的信息一周也就两三条。后来做了大幅精简反而没漏掉什么重要的东西。4.1 三类信息源的性价比排序按我自己的体感性价比从高到低大致是这样信息源类型优势劣势建议投入代码托管平台上的清单仓库与讨论帖有具体代码和上下文能直接复现质量参差需要自己筛高但要挑活跃的技术社区的长文复盘有完整的思考链路和失败记录更新慢时效性弱高优先看带日期的邮件周报帮你过滤一轮节省时间二手信息深度有限中订两三个足够短视频与直播回放直观能看到操作细节信息密度低难以检索低只在学新工具时看泛社交平台的碎片讨论消息快噪音极大容易焦虑极低控制时间这个排序不是绝对的但有个规律值得注意越是能让你动手复现的内容价值越高。一段能跑起来的示例代码胜过十篇“我如何用它提效三倍”的感想。4.2 订阅要少而准别做信息仓鼠有个现象我观察了很久越是刚开始学的人订阅得越多。这其实是一种安全感的替代品——收藏了就等于学会了。但信息摄入是有成本的而且这个成本会累积。你订了十个源每个源都在告诉你“有个新工具出来了”“有个新技巧”你的工作流就会被反复打断。我的做法是给信息源设一个硬上限周报不超过三个、常看的讨论区不超过两个、视频频道不超过两个。超了就砍砍的时候问一句“过去一个月它给我带来过哪怕一条能用的东西吗”答不上来就退订。还有个更狠的办法我自己在用新订阅先观察一个月一个月内没有产生任何实际行动的直接退。这条规则帮我砍掉了八成以上的订阅。4.3 一个可执行的输入、消化、输出回路光输入不输出几乎必然变成仓鼠。我给自己的要求是每看完一条有价值的资源必须留下一样东西形式不限但必须落地一段能跑的最小示例哪怕只有十行一条写进自己项目说明文件的约定一段一百字以内的笔记写清楚“这个方法解决什么问题什么情况下不适用”这三样里我最看重第三条因为它逼着我想明白边界。很多人记笔记只记“怎么做”不记“什么时候不该做”结果下次遇到不适用的场景照样往上套反而更糟。输出这一环也很关键。我会不定期把用过的方法整理成一段文字发到内部群或者自己的笔记里哪怕只有三个人看。写的过程会暴露很多你以为懂了其实没懂的细节——这个“讲不清楚”的地方就是下次该重点补的地方。5. 把清单变成产出一套每天都用得上的协作流程资源看完了路径也清楚了剩下的问题是怎么把它变成每天真正在用的流程。这一节讲的是我自己跑了半年多、反复调整后稳定下来的一套做法不复杂但每一步都有它存在的理由。5.1 项目说明文件给模型写一份“入职手册”如果只能从这篇文章里带走一样东西我建议是这个。在项目根目录放一份说明文件内容大致包含这个项目是干什么的一句话目录结构每个目录负责什么技术栈和版本以及“不要引入新的依赖”这类硬约束命名和代码风格的约定禁区清单哪些文件不要动、哪些接口不要改常用命令怎么启动、怎么跑测试、怎么构建这份文件每次开新对话都带上。我试过很多次带和不带的效果差别非常明显——不带的时候模型会兴致勃勃地引入第三个日志库、把已经定好的目录结构重排一遍带了之后它明显“守规矩”多了。写这份文件本身也是个梳理过程。我写第一版的时候才发现自己项目里有三个地方的功能是重叠的只是之前一直没注意。5.2 一次只改一个关注点改完就提交这是最重要的操作纪律。很多人习惯一次描述一堆需求“加个登录、顺手优化下首页的加载、把那个报错也修一下”。结果模型改完之后你根本分不清哪一处改动导致了新问题。正确的做法是把需求拆到一个改动只对应一件事的粒度改完立刻验证、立刻提交。这样做有三个好处出问题时能精确定位到是哪一次改动可以随时丢弃某次不理想的尝试提交历史本身就是一份可读的变更记录。拆分的粒度怎么把握我的经验是如果一个改动需要你用“顺便”这个词来描述那就该拆。“顺便把变量名改一下”听起来是小改动但它会让 diff 变得难以审阅也会让模型误以为可以自由发挥。5.3 接手生成代码时的六个检查动作拿到生成结果之后我会按顺序过一遍下面这几项。这个过程熟练之后大概两三分钟看它有没有做我没让它做的事。多出来的“优化”和“顺手重构”是最常见的风险源。看边界条件。空输入、单元素、超大输入、异常路径这四类是我必查的。看错误处理是不是敷衍。大量catch之后什么都不做或者直接吞掉异常这种要打回去。看有没有引入新依赖。新依赖意味着新的维护成本和潜在风险。看资源。有没有没关的连接、没释放的句柄、循环里的重复查询。跑一遍测试。没有测试的话至少手动把主要路径点一遍。这六项里第一项和第六项救命次数最多。第一项防的是“它太热心”第六项防的是“它悄悄改坏了别的地方”。5.4 生成失败时的三级降级策略不是每次生成都能成。卡住的时候我会按三级往下退而不是在原地反复重试同一句话第一级补充上下文。大多数失败是因为信息不够。把相关的文件、报错原文、期望的行为补进去往往一次就过了。第二级缩小范围。把任务拆到更小——不是“实现这个功能”而是“先只写这个函数的签名和文档注释”让它一步步来。第三级自己写骨架。如果两轮下来还是不对说明这个部分不适合生成。我会自己把结构搭出来只让模型填其中的具体片段。退到这一步并不丢人很多时候反而是最快的路径。这三级的顺序很重要。我见过不少人一上来就反复重试同一句话换个措辞再试一遍试了七八轮时间全浪费了其实问题在于上下文给少了。6. 收藏了几百条链接还是写不出东西六个真实踩坑这一节讲的都是我自己摔过的不是从别人那儿听来的。每一条后面都写了我后来怎么改的供参考。6.1 坑一把收藏当成学习本身最典型的表现是看到一篇好文章第一反应是存链接而不是立刻试一下里面讲的东西。存完之后有种“我已经掌握了”的错觉实际上什么都没进脑子。我一度有个收藏夹里面躺着两百多条链接重访率大概百分之三。后来改成一个很笨的办法看到有启发的资源当场花十分钟做一个最小验证做不了的就先不存。这个规则执行下来收藏量少了八成但真正用起来的东西多了不少。6.2 坑二上下文越堆越脏越脏越堆对话轮次一多模型的回答就开始跑偏。我一开始的应对是“再解释一遍”结果上下文越来越长它反而更容易抓错重点。后来才明白问题不是它忘了而是历史记录里混进了太多已经被推翻的方案。解决办法很简单一旦发现它开始重复已经否掉的思路直接开新对话把当前的代码状态和最新的需求重新贴一遍。开新对话的成本远低于在一个污染了的上下文里纠缠。我现在基本每完成一个小目标就重开一次。6.3 坑三把“能跑”当成“能用”生成出来的东西能运行就以为完事了直接进了主干。这类代码往往在正常路径上没问题一经受真实数据的折腾就露馅——空值、超长字符串、重复提交、网络抖动随便来一个就挂。我现在会在提交前问自己一个问题如果这段代码在生产环境跑一整晚最可能出问题的地方是哪。想不出来就说明我还没读懂它那就再读一遍。6.4 坑四一口气要一个完整系统新手最容易犯的是一次性描述一个完整应用的需求指望它一把生成。结果通常是得到一个骨架完整但处处细节不对的东西改起来比自己写还费劲。正确的姿势是从最小可运行单元开始一点点往上垒。先让一个按钮能点再让点击之后有反应再让反应的结果能存下来。每一步都验证过再进下一步。这个过程表面上慢实际上快很多因为每出问题都只在一个小范围内一眼就能定位。6.5 坑五不做版本控制就让它改代码前面提过一次但值得单独说因为这是代价最高的一类坑。没有版本控制你失去了“对比”这个最强的手段——你没法看出它到底改了哪几行只能靠肉眼在一堆文件里找不同。而且一旦改坏了回不去。我现在有个不带商量余地的习惯任何会让模型修改文件的动作执行前必须有一次干净的提交。哪怕这个提交只是为了这五秒钟的保险。6.6 坑六每出一个新工具就换一次工作流这个领域新东西出得极快很容易陷入“追新”的循环今天听说这个编辑器插件好用明天听说那个终端工具更聪明折腾一圈下来每个都用了个皮毛没有一个用熟。我后来的判断标准变成了只有当现有流程在某个具体环节上明显拖了后腿才考虑换工具。比如我发现自己在文件间来回跳转浪费太多时间才去找能读整个目录的工具。为了“更新”而更新除了消耗注意力带不来别的东西。最后分享一个我自己一直在用的小习惯每隔一段时间把手里那份资源清单拿出来删掉那些“存了三个月但从没打开过”的条目然后把留下的每一条试着用一句话说清楚“它解决什么问题”。说不清楚的也删掉。清单越薄越好用。这个过程本身比收藏任何一条新链接都更能提高水平。