# Vibe Coding求助 **URL:** \ **Category:** 问题求助\ **Tags:** 编程, ai, llm\ **Created:** [2026 年3 月 15 日 02:46 UTC](https://meta.appinn.net/t/topic/82627 "2026-03-15T02:46:00Z")\ **Posts on this page:** 13\ **Page:** 1
作者： ![AkariSam](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/a/2bfe46/32.png) [@AkariSam](https://meta.appinn.net/u/AkariSam)\ 发布日期： [2026 年3 月 15 日 02:46 UTC](https://meta.appinn.net/t/topic/82627/1 "2026-03-15T02:46:00Z")
导师让我下周给新进来的同学们讲一下Vibe Coding。 但是我本人其实不会Vibe Coding，是古墓派Copy-Paste型LLM-Aided Coding。就是把代码copy-paste给LLM，再写上prompt，让LLM帮我debug，返回的代码再copy-paste给IDE。 咨询各位几个问题： 1、各位是如何Vibe Coding的？请包含一些细节，例如：用哪个AI IDE？用哪个LLM？ 2、Vibe Coding，有哪些必须讲的内容。有哪些小tricks？ 3、Vibe Coding，界限在哪里？哪些任务是目前的Vibe Coding无法完成的？ 感谢各位解答我的问题。 相关帖子：[有什么好用的ai编程应用 - 讨论分享 - 小众软件官方论坛](https://meta.appinn.net/t/topic/74023) ---
作者： ![Seamee](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/seamee/32/55824_2.png) [@Seamee](https://meta.appinn.net/u/Seamee)\ 发布日期： [2026 年3 月 15 日 02:52 UTC](https://meta.appinn.net/t/topic/82627/2 "2026-03-15T02:52:10Z")
我也是古墓派vibe coding，现在还在用vscode+cline+GLM5，现在应该用claude code的比较多吧，配合cc switch可以使用其他一些便宜第三方模型 别的vibe coding不清楚，我在用的cline会把任务自动拆分，先设置plan，会不停追问直到他提出的方案满足你的需求，他会按步骤写清楚每一步做什么供你审阅，然后再进入act模式进行操作 vibe coding最适合做的就是小型项目，脚本、糊个前端之类的，但凡稍微复杂一些就四处漏风，也许更好的agent能缓解这个问题吧，具体我就不知道了 ---
作者： ![jark006](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/jark006/32/58289_2.png) [@jark006](https://meta.appinn.net/u/jark006)\ 发布日期： [2026 年3 月 15 日 03:51 UTC](https://meta.appinn.net/t/topic/82627/3 "2026-03-15T03:51:10Z")
以trae cn为例（目前还免费） 进入它的solo模式，对于从零开始的不复杂任务，给它提需求，它会完成包括项目各个源文件的建立/实现代码，编译/运行，它会根据运行结果继续编辑代码，重复到基本完成要求，或者无法实现就停止。 对于现有的项目，它也会根据要求继续完善或修改。记得提前备份或有git纪录，不然改乱了，难恢复。 而正常编辑模式，大概像高级的自动补全，例如你的代码正写着，它会根据你的上下文推测你要干嘛，直接给你补全后续几行到几十行代码（你也可以不接受，继续自己写）。 再就是项目旁边有个AI对话框，可直接跟它交流和项目的各种东西，也可以叫它帮你改或实现某某功能。 然后不同的模型智商不一样，越贵就越聪明（不过trea cn目前免费，优秀国内模型要排队）。想用国外顶级模型就换cursor之类的，不同套餐就价格不同 ---
作者： ![micalee](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/m/db5fbb/32.png) [@micalee](https://meta.appinn.net/u/micalee)\ 发布日期： [2026 年3 月 15 日 04:40 UTC](https://meta.appinn.net/t/topic/82627/4 "2026-03-15T04:40:47Z")
我使用 Claude Code 来编程，现在代码已经是 100% 由 AI 生成了。 我使用 Claude Code 的方式： 1. 开启计划模式，然后描述自己的需求。比如我要做一个什么样子的工具、或者我想要进行什么样的重构。 2. 阅读 Claude Code 生成的计划，看看有没有要改的 3. 让 Claude Code 执行计划 4. 检查完成后的效果。如果还有要改的，就继续跟它聊；如果没有，就提交代码到 git 里。 必讲的内容的话，我觉得有一点要说，就是 Claude Code 不仅仅只能用来写代码，它实际上是个很万能的工具，比如： 1. 使用浏览器自动分析目标网站的页面、代码结构等，用来写爬虫简直神器 2. 自动通过 SSH 连接到服务器，帮助我判断服务器的安全状况、有没有漏洞等 3. 搭配上 Skill，它可以帮我完成一些我平时需要重复做、但没法通过代码来自动做的事情，比如有一些网站的反爬手段太厉害，通过代码的方式很难拿到数据，这时候我可以用 Skill 告诉它，我需要它用浏览器访问某个网站，然后让它分别进入哪些页面、获取哪些数据。 还有一个就是，AI 模型的选择会极大程度的影响完成度，我在试用了多个模型之后，最后发现Opus 4.6 是目前最智能的模型，在上面这些任务中，只有它的完成效果是最好的。但是 Opus 4.6 的官方价格太贵了，可以看看我做的一个价格排行，找一些便宜的渠道用 [claude-opus-4-6 价格比较 - GetCheapAI](https://www.getcheapai.com/zh-cn/claude-opus-4-6?view=coding) 界限的话，Claude Code 或者说 AI 目前最大的界限就是设计稿的还原度很低。你用它来从 0 开始生成一个网站，那很好，但现在大部分公司其实还是有专门的设计师做好了设计稿，这时候你让它从图片还原、或者接入 Figma 的 MCP 来还原，还原度都是不够的，还是得靠人工来做。 ---
作者： ![SmallPackage](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/smallpackage/32/57958_2.png) [@SmallPackage](https://meta.appinn.net/u/SmallPackage)\ 发布日期： [2026 年3 月 15 日 06:02 UTC](https://meta.appinn.net/t/topic/82627/5 "2026-03-15T06:02:31Z")
某种意义上来说, vibe coding就是营销话术，一种用于创造独特感和话题度的技巧。暗示你你在做编程工作, 但实际上并非如此; 实际体验来说, 如果你是写代码的那个人, 需要关注具体的代码质量, 实现逻辑等, 那么各种agent用的越多其实你就越会感觉到挫折，最后陷入一种是不是自己没用最强模型和最好的工具，所以做不到大家说的这么好的自我怀疑，然后你真的买了，似乎有所改善，但并不能真的彻底解决。 而只有你真的越过了这个阶段，其实你才能真正搞清楚这套东西想要兜售的模式是什么。说到底，目前即便是最强的模型，也是有极限的，如果意识到vibe coding从一开始就完全不是传统coding，是完全不一样的范式。那么很多问题就会迎刃而解了. 我觉得我会补充这么一些观点。 核心其实就是，如果你是复制粘贴，手写代码的朋友，真的在意代码写了什么，所谓vibe coding其实挺让人恶心的。给人的感觉像是在和agent工具搏斗. 而一旦你放弃关注技术落地的细节，只要得到的东西能用，那么很多事情就会不一样了。 具体到使用上, 其实可以说就和一些朋友提到的一样, 对于 claude code这类工具, 其实你应该以所谓产品经理的视角, 而非程序员的视角去使用和交互; 不需要太过关心技术实现细节, 而是去关注功能实现情况; ---
作者： ![Qingwa](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/qingwa/32/58632_2.png) [@Qingwa](https://meta.appinn.net/u/Qingwa)\ 发布日期： [2026 年3 月 15 日 06:22 UTC](https://meta.appinn.net/t/topic/82627/6 "2026-03-15T06:22:11Z")
> [@SmallPackage](#): > > vibe coding就是营销话术 的确是这样，有点好笑。 现在编程变成语文课了，说清楚比会编代码重要多了 ---
作者： ![jerryc](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/j/3e96dc/32.png) [@jerryc](https://meta.appinn.net/u/jerryc)\ 发布日期： [2026 年3 月 15 日 06:23 UTC](https://meta.appinn.net/t/topic/82627/7 "2026-03-15T06:23:31Z")
vscode里面装个gemini扩展，然后输入你想要的东西，等生成后自己点运行代码，有问题就把错误信息复制到输入框，循环以上步骤直至运行成功 ---
作者： ![Sworld](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/sworld/32/47330_2.png) [@Sworld](https://meta.appinn.net/u/Sworld)\ 发布日期： [2026 年3 月 15 日 07:14 UTC](https://meta.appinn.net/t/topic/82627/8 "2026-03-15T07:14:46Z")
我不是古墓派，我现在70%+的代码都是 AI CLI 工具写的了，分享一下。 **1. 我如何vibe coding** 我会使用VSCode Insiders或Zed + Copilot CLI或Codex CLI，其中VSC/Zed只参与我手动编写的部分，其余在CLI中完成，LLM正常我只使用Claude 4.6 Opus和GPT 5.4。 我都会给任务先写好对应的Issue，将Issue内容复制到Agent CLI工具的规划模式中，附加上我认为AI可能遗漏的内容，讨论多轮再执行，Opus和GPT都能比较好的满足需要，其区别是我认为Opus比较发散，适合产品初期或探索阶段，GPT适合执行定义明确的任务，不需要模型自己发挥。 在CLI中，我不会配置过多的工具，MCP工具我一般会扩展以下几种（各一个）： - GitHub获取类（Grep-app，如果用Copilot CLI的话它自带官方的就不用配置了） - 搜索类（主用tavily，也用过exa、brave，感觉没什么区别） - 文档获取类（曾经主要用Context7，因上下文占用问题替换为了Ref tools） Skills我会配置前端相关的一些，只有前端任务我会指定为Gemini 3.1 Pro。 在完成编程阶段后，我审查如果没发现明显的问题，就在GitHub上提交PR，此时会有AI Reviewer进行审查，我会判断是否存在问题并反馈给本地CLI，重复多轮直到我和AI都挑不出什么毛病。 **2. 必须讲的内容** 我觉得主要是四点： - 规划非常重要，除了能除了能给AI一个完成标准外，更重要的是能整理清楚你想要什么 - Review会非常疲惫，而且重复多轮，但是这是必要的，除非你不介意拉屎山，另外最好是AI完成任务后再review，中途看到不好的立刻改可能会导致AI注意力出问题 - 不要把时间和token浪费在水平不好的模型上，现在最简单的任务我也会给sonnet或gpt 5.3 codex来做，因为较差的模型会严重损坏代码库的可维护性，或是干脆浪费你的时间 - 不要过度配置MCP工具、Skills、Agent记忆系统等，上下文窗口是很宝贵的，AI的注意力也是有限的，以前我用了一段时间oh-my-opencode等工具，它可以实现长达六七小时的连续执行，但是在浪费了大量金钱后我才发现目前AI的长时间工作产出还是非常不理想的，繁杂的工具也会让AI注意力涣散 **3. 界限** - 上一条的最后一点其实就是很重要的，AI只有在项目早期能完成全局性的任务，一旦代码库发展到一定的规模，他就会失去控制能力，合理的任务拆分需要人高度介入 - 现在很多工具支持并行agent，但是现阶段真的没法追求特别高的并行度，对我来说本地跑2个，云端跑一个（跑完了review）已经是极限了，而且会把人搞的非常疲惫，如果需要并行尽量是特别小的任务 - AI长期记忆是比较难解决的问题，目前很多RAG方案、记忆注入等方案其实都不太理想，因此我还是坚持手动输入我认为重要的仓库信息，但是这样既会有遗漏，也会存在我的偏见 ---
作者： ![yazii](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/yazii/32/13871_2.png) [@yazii](https://meta.appinn.net/u/yazii)\ 发布日期： [2026 年3 月 15 日 09:35 UTC](https://meta.appinn.net/t/topic/82627/9 "2026-03-15T09:35:25Z")
看需求的复杂程度吧。 之前搞了几个比较复杂的东西，用trea 和 谷歌反重力还有什么平台的plan模式，先规划plan，修改plan，然后执行。但是这plan他给你标记完成了，也不见得真的通过验收了，后边还是一轮一轮对话解决问题、增加功能。 一个错误持续出现不能解决，就该找AI分析逻辑，然后尝试手动修复了；或者手动修修。 上下文压缩真要不得，对话轮数太多得开新会话；最好是一个功能完成之后就去git commit并且开新会话。 简单的东西可以用Ask模式，先找AI做下技术评估，订好方向AI直接开淦，plan模式都没用。 Agent的效用在我这里反正没有体现出来，模型切换的多一点，skill也用的少基本是用来填补基本功能的。 ---
作者： ![shadows](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/shadows/32/17001_2.png) [@shadows](https://meta.appinn.net/u/shadows)\ 发布日期： [2026 年3 月 15 日 12:43 UTC](https://meta.appinn.net/t/topic/82627/10 "2026-03-15T12:43:10Z")
我现在已经完全不自己写了，业余水平边搜边写太费时间。 古墓派是要不得的，提供的信息太片面，顶多适合单文件的小项目。 IDE和各种cli大同小异，如果只要结果，不看代码的话，用cli工具就行，每一家的模型最好用自家的工具，claude用claude code，gpt用codex，其他的模型不推荐，除非是很低级的任务(业余水平)，除非你真的时间很多，愿意不断地纠错。IDE的话，我没用过，就不推荐了。 需要注意的是，十分建议先使用plan/计划模式，和ai一起把方案确定好，把需求和边界限制都说明白，开个好头。如果方案没问题，ai的智力也不差的话，基本就差不多了，写完后最好必须要求它跑通测试/验证成功后才能结束，然后还要让另一个ai或者子agent来审修改，避免它欺瞒你 至于技巧，真的很多，什么skill mcp 全局提示词 角色设定 节省token的技巧，…但是这些都比不过模型自身的水平，不要浪费时间在垃圾模型上！ 需要注意的：千万注意不要给ai所有权限，它犯错时真的可能把你的盘和仓库一起删干净的！尤其是有沙箱功能的工具，强烈建议启用沙箱，但沙箱也不保险，还是自己注意吧 ---
作者： ![zanktx](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/z/ecc23a/32.png) [@zanktx](https://meta.appinn.net/u/zanktx)\ 发布日期： [2026 年3 月 15 日 15:18 UTC](https://meta.appinn.net/t/topic/82627/11 "2026-03-15T15:18:19Z")
赞同！刚开始都还不知道是啥 查了些才知 ---
作者： ![a523084467](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/a523084467/32/7534_2.png) [@a523084467](https://meta.appinn.net/u/a523084467)\ 发布日期： [2026 年3 月 15 日 19:26 UTC](https://meta.appinn.net/t/topic/82627/12 "2026-03-15T19:26:41Z")
我写个字少的，以从头做个小东西为例： 1. 自己写个简单的需求文档（PRD.md），网页 AI 改进，存进项目文件夹 2. AI 写详细计划（Plan.md），存进项目文件夹（以上两个文档记得亲自审核修改） 3. 正式开始让 AI 干活：`请阅读当前文件夹的 RPD.md 和 Plan.md，完成 Plan.md 的阶段 1` 4. 验收上面成果，通过则 GIT 提交，然后视当前上下文长度，在当前会话继续完成阶段 2，或新开一个会话继续；没通过，也是视当前上下文长度，在当前会话或新会话解决问题 5. 重复 3 和 4 上下文长度是个比较玄学的东西，像比较好白嫖的 GLM-5 上下文长度有 200k，但一般 150k 时就比较注意力涣散了 对于现有大项目，我认为有必要准备一个架构文档（Architecture.md），相当于项目的目录，避免瞎读一堆文件占用大量上下文，也避免读的不够多导致完全自由发挥瞎写 界限我想主要在于测试的自动化，很多东西是没考虑和人类以外的东西交互的，没有现成自动化工具的，搓一个不如人工测试更方便 ---
作者： ![Fay](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/f/7993a0/32.png) [@Fay](https://meta.appinn.net/u/Fay)\ 发布日期： [2026 年3 月 16 日 03:34 UTC](https://meta.appinn.net/t/topic/82627/13 "2026-03-16T03:34:04Z")
我的感觉吧， 1. 越独立或者目标单一的功能，或者解耦得很彻底的模块，AI是非常好用的。例如写个小工具完成特定需求。 2. 要使用自己的框架，或者有上下文时，上下文越多框架越复杂，AI犯蠢的几率越高。 所以要Vibe，最好这个项目从头就是Vibe，自己都不用Review，只用验收功能，这样就很快。至于Vibe能实现的具体边界在哪，我也不知道。我心中大概的边界是，网上有开源实现类似功能的，应该都可以。