最近我朋友圈里聊最多的一个词就是 vibe coding。代码交给 AI 写人负责描述需求、复制报错、然后再祈祷一次能过。听起来很爽但真上手的人都知道爽不过三天项目越写越大AI 开始“失忆”同一个 bug 修三次代码能跑但没人敢动每次合并都像拆弹。我一度被这种失控感折磨得想回到纯手写时代直到我陆续换上一套开源 App才慢慢把节奏找回来。这篇就把我实际在用的 9 个开源 App 和背后的工作流讲清楚适合正在经历 vibe coding 焦虑、想找回掌控感的开发者参考。1. 先说清楚vibe coding 的焦虑到底从哪来1.1 失控感代码不是你写的但锅是你的Vibe coding 最大的错觉是“我只需要描述需求”。实际上 AI 生成的代码会以不可思议的速度膨胀而你的理解速度根本追不上它。我试过让 AI 在半小时内写完一个带数据库操作的接口它确实写完了功能也能跑但里面有三个我完全没看过的依赖、两层多余的封装还有一段像是从别的项目里“缝合”过来的逻辑。这种体验很像请了一个手脚麻利但记性不好的实习生它交作业特别快但你不 review 就心里没底。问题在于传统团队里你至少知道实习生脑子里想什么而 vibe coding 里模型对你来说是个黑盒它为什么这么写、改这一行会不会影响别处你只能靠赌。焦虑的本质就是交付速度和掌控力之间的落差越来越大。1.2 黑盒与上下文爆炸模型记不住你的项目你也记不住它第二个焦虑源更隐蔽叫上下文爆炸。模型每次只能看到窗口里那点内容项目一大了它就“忘了”你三天前定的命名规范、两周前设计的表结构。你必须反复把同一段背景塞给它否则它就会一本正经地给你提出一个和现有架构冲突的“新方案”。更要命的是你也记不住它。你俩的对话历史散落在十几个窗口里哪个改过、哪个是废弃方案、哪个能落地全靠脑补。我一度同时开六个聊天窗口每个窗口里的 AI 都在改同一批文件最后合并的时候连我自己都分不清谁是谁。这种“双向失忆”才是 vibe coding 最消耗人的地方。1.3 我验证过的方法靠工具重建“可回退、可验证、可追踪”三个锚点踩了两个月坑之后我意识到问题不在 AI 强不强而在流程缺了锚点。解决 vibe coding 焦虑不能靠“少用 AI”或者“自己全写”那样等于因噎废食。真正有效的方式是把工程里早就验证过的三个机制重新捡起来可回退、可验证、可追踪。可回退每一次 AI 改动都能从 git 历史里找到不行就一键回退。可验证对 AI 的输出有客观判断标准不能只看“它自己说跑通了”。可追踪需求、代码、审查记录全都能对上项目状态一眼看清。而这三件事恰好是开源社区里一堆现成工具最擅长解决的。下面这 9 个开源 App就是我一路筛出来的抗焦虑组合。2. 9 个开源 App 的选型逻辑不是越多越好2.1 我挑选工具的四个原则在列清单之前先说说我怎么挑的。Vibe coding 工具圈更新快得离谱今天装一个下周就出替代品如果见啥装啥焦虑只会更重。我给自己定了四个原则第一本地优先、数据可控。能本地跑就不把关键代码往外传至少模型商看不见我的全部工程上下文。第二一个工具只解决一个核心焦虑不追求“全家桶”式的万能平台。第三必须开源。不是因为我有多理想主义而是开源项目出了问题我能看到 issue、能自己改不至于对着闭源客服干瞪眼。第四接口要开放最好有 CLI、插件或 API能被我串进现有工作流而不是成为又一个信息孤岛。2.2 九件套速览功能和解决什么焦虑我把最终留下的工具列成了一张表。它们都不是那种“看起来很酷但用不上”的玩具而是我在真实项目里跑过至少两个迭代的东西。工具类型定位主要解决哪种焦虑Aider终端 AI 编程工具基于 git 的 AI 结对编程改坏了不敢回退、提交历史混乱ClineIDE 插件可视化 AI 助手可审查 diff黑盒生成、不敢 reviewContinueIDE 插件上下文管理与规则定制模型失忆、项目规范丢失Open WebUI本地 AI 对话前端统一管理本地和远端模型数据隐私、模型切换混乱LiteLLMAPI 网关统一接入各家模型接口API 密钥分散、账单爆炸PromptfooPrompt 评测工具给提示词写回归测试改了又改、效果倒退Zed开源编辑器低延迟协作 Agent 面板编辑器卡顿、结对效率低Plane项目管理平台轻量 issue 和迭代管理需求混乱、任务无跟踪Gitea代码托管平台自托管 git 与代码评审合并失控、流程不透明看这张表你会发现没有一个工具是“让你的 AI 更聪明”的它们全都是用来“限制 AI 的破坏力”和“让过程更透明”的。这就是我抗焦虑的核心思路你不需要一个完美的 AI你需要一个随时能叫停、能复盘、能兜底的环境。3. 逐个拆解从“黑盒生成”到“可审查闭环”3.1 核心编程链路Aider Cline Continue 怎么配合先聊最核心的编码环节。Aider 是我目前的主力它跑在终端里核心思想是“每次修改都自动提交到 git”。我只要开一个 feature 分支然后启动aider它每做一次改动就会自动生成一个提交改崩了直接/undo整段回退。这个能力看起来简单但对缓解焦虑是质的改变——我不用再担心“AI 改坏了我的代码”因为每个坏版本都留下了清晰的回退点。实际操作中我会按顺序做三件事先用 Aider 做大幅度的功能生成让它把架子搭起来然后用 Cline 在 IDE 里做精细调整因为它会明确展示每个文件的 diff我可以在“accept”之前看清楚 AI 到底动了什么最后用 Continue 维护项目上下文把命名规范、架构约定写进 rule 文件让后面所有 AI 会话都能读到。这三者不是重复而是分工Aider 负责“快”Cline 负责“看得见”Continue 负责“记得住”。我建议把 Aider 和 Cline 放在同一个项目里跑但不要同时让它们改同一组文件否则很容易互相覆盖。实测下来先把 Aider 生成完再切到 Cline 收尾冲突最少。3.2 上下文和模型网关Open WebUI LiteLLM很多 vibe coding 翻车不是因为模型差而是因为模型换来换去。今天我试 GPT明天用 Claude后天又切回国产模型同一个需求在不同模型里的表现天差地别。你以为自己在“选最优解”其实在制造混乱。所以我用 Open WebUI 和 LiteLLM 把模型层稳定下来。Open WebUI 是一个很成熟的开源对话前端可以接 Ollama 的本地模型也可以接 OpenAI 兼容接口。我平时拿它做两件事一是临时跑跑本地小模型处理一些不方便外发的碎片文本二是做聊天记录的统一归档所有和 AI 的讨论都有迹可循不会像浏览器里的聊天窗口一样被随手关掉。LiteLLM 则相当于一个模型网关所有应用都通过它来请求模型而不是各自直连各家平台。我在一个config.yaml里统一配置模型列表、密钥和限流策略上层代码只认一个接口。这样即使某个模型服务挂了我只需要在网关里切换不用改业务代码。独立开发的时候你可能觉得多此一举但只要同时用超过两家模型你就会理解“统一入口”能省掉多少混乱。3.3 质量验证Promptfoo 与 git 回退机制Vibe coding 最常见的死循环是“改 prompt、跑一次、看着还行、再改、跑一次、发现之前好的地方坏了”。因为你全凭感觉调没有量化标准。Promptfoo 解决的就是这个问题它本质上是给 prompt 写单元测试。我项目里有一个prompts/目录里面维护着一组典型输入和期望输出。每次我调整系统提示词或者换模型就跑一遍promptfoo eval把所有用例一次性回归掉。比如我想让 AI 把需求描述转成用户故事那就准备几条不同风格的需求文本断言输出里必须包含“作为”“我希望”“以便”三段式结构。prompts: - 把下面需求写成用户故事{{feature}} providers: - openai:gpt-4o - ollama:llama3 tests: - vars: feature: 用户需要一个番茄钟可以设置25分钟倒计时 assert: - type: contains value: 用户故事 - type: contains value: 作为跑完这个评测我就能用数据说“这版 prompt 比上一版强”或者“这版更差”而不是靠体感。再搭配 Aider 的自动提交机制严格做到“每次 prompt 变更都能回退”生成这件事就不再是不可逆的赌注了。3.4 协作与管理Plane Gitea Zed单人 vibe coding 容易飘多人协作的 vibe coding 则容易乱。Plane 是我用下来最顺手的开源项目管理工具界面不花哨但“周期”“模块”“问题”三个概念足够覆盖大多数场景。我习惯把一个大需求拆成若干个小 issue每个 issue 绑定一个分支Who、What、Why 都写清楚AI 才有足够的上下文去生成代码。Gitea 作为轻量代码托管平台承担的是最后的把关环节。我给自己定了条规矩哪怕是一个人开发也要走 Pull Request不直接往主分支推代码。PR 的好处是强制你看一遍 diff而且所有改动都在平台上留痕。Cline 生成的改动我也会在 PR 里逐行看一遍这一步没办法省但有了流程保护之后看代码的心态会放松很多焦虑感至少少一半。Zed 是最近才加入组合的编辑器Rust 写的启动快多人协作延迟低。我主要用它做结对 vibe coding两个人同时打开一个会话一个人负责描述需求另一个人负责盯 diff。这种“一个人开飞机、一个人看仪表”的模式非常有效地防止 AI 跑偏。4. 把它们串成一条反焦虑工作流4.1 一条真实任务的完整走查工具单独摆出来只是清单串起来才是工作流。我拿一个“番茄钟小工具”的需求举例完整走一遍现在的日常流程。第一步在 Plane 里建一个 issue描述需求支持 25 分钟倒计时、到点提醒、历史记录。拆成三个子任务每个子任务对应一个 feature 分支。第二步在 Gitea 上创建feature/timer分支。第三步在终端启动 Aider让它基于 issue 描述生成倒计时核心逻辑。它每完成一个小片段就自动提交提交信息写得清清楚楚方便我再 review 时对照需求。第四步切到 VS Code 用 Cline 处理“提醒”和“历史记录”的交互细节逐个文件看 diff有问题当场改掉。第五步把“需求转用户故事”的 prompt 改动跑一遍 Promptfoo防止之前的输出格式被新改动破坏。第六步推送分支、在 Gitea 开 PR、自己给自己做 code review、确认无问题后合并。合并之后我再回到 Plane 把对应 issue 勾选完成。整个过程看起来步骤多但每一步都极短而且我的心态完全不同。我不再担心 AI 偷偷塞了一段“能跑但看不懂”的代码因为每一段都被 commit、被 diff、被 PR 审查过。焦虑感来自未知而这条链路让未知一个一个变成已知。4.2 五个必须养成的反焦虑习惯工具到位之后真正起作用的是习惯。我这几个月总结出五条军规每条都是从踩坑里长出来的你直接照着做就行。第一每个会话开始前先用两句话写清楚目标和验收标准。我见过太多“帮我看下这个报错”式的需求AI 只会大海捞针最后人也不满意。第二Aider 自动生成的提交信息必须能看懂。如果你看到一条 commit 是 “fix stuff”说明 AI 自己也搞不清改了啥这种时候要立刻停下来拆任务而不是继续堆代码。第三绝不让 AI 直接在主分支上干活。所有生成都发生在 feature 分支主分支永远是干净可部署的。第四prompt 不是聊天而是项目资产。每次改 prompt 都要进 Promptfoo 评测不能只靠“再跑一次看看”。第五每个迭代结束看一眼 Plane 的看板和 Gitea 的 PR 列表确认“说要做的事”和“实际做的事”对得上。只要对不上就说明上下文又失控了要回到规则文件里补背景。这五条军规不复杂但它们把 vibe coding 从“AI 带着你跑”变成了“你带着 AI 跑”。方向感一旦回来焦虑自然就降了。5. 常见问题与避坑实录5.1 模型越强越焦虑用错工具的三种典型症状如果你配了工具还是觉得焦虑先看看是不是踩了下面三个坑。第一种症状是“越换模型越焦虑”。今天听说这个新模型强明天就换过去同一段代码在不同模型里反复生成最后项目里混着三种风格。这种问题的根源不是模型不好而是缺少统一网关和评测标准。用 LiteLLM 固定接入层用 Promptfoo 固定验收标准模型切换才不会变成灾难。第二种症状是“代码能跑但没人敢改”。这说明你跳过了 diff 审查。代码能跑不代表结构合理更不代表别人敢在此基础上迭代。一定要让 Cline 这类工具把改动亮出来你至少看过一遍知道它干了什么才叫掌握主动权。第三种症状是“项目历史一团乱”。今天这个文件是谁改的那个功能是哪次提交引入的完全查不到。这不是 AI 的问题是流程问题。把 Gitea 的 PR 和 Plane 的 issue 绑起来之后历史就变成可检索的了。5.2 两条独家避坑技巧最后的避坑技巧算是我自己花了最多时间才想明白的。第一个技巧不要在你常用的 IDE 里装太多 AI 插件。我有一段时间同时开了四五个 AI 相关插件结果它们都在读上下文、都在往同一个目录里写缓存甚至有几个会抢快捷键。AI 插件之间互相打架比没有 AI 还让人烦。我的建议是每个阶段只留一个主力快速生成用 Aider精细修改用 Cline上下文规则用 Continue其他的全部禁用。不同时切换反而更快。第二个技巧给每个项目维护一份全局 Markdown 文档记录 AI 上下文之外的“硬事实”。比如数据库表结构、接口约定、当前分支改到哪了、下一步要做什么。模型上下文窗口再大也不如一张写得清楚的结构化文档可靠。每次开启新的 AI 会话之前我先把这份文档扔给它当背景效果比在聊天里重复十遍“记住我们之前说的”好太多。这份文档同时也是你自己的记忆备份就算隔一个月回来扫一眼就能重新上手。我在实际使用中还有一个体会vibe coding 本身没有问题问题在于我们总想让它替代所有工程流程而事实上它更适合被当成一个生成速度极快的“同事”需要有人给它设定边界、检查输出、记录历史。这套开源 App 组合本质上就是给这个“同事”配了一套完善的作业环境。你先别急着一次性把九个全装齐先从 Aider 加 Gitea 这套最小闭环开始跑顺后再往下加焦虑感会随着每一步自动化慢慢消失。