聊个最近被朋友反复问过的问题用 vibe coding 写了几个小项目刚开始挺爽为什么越写越慌模型乱换、上下文记不住、改来改去把项目自己都绕晕了、API费用还逐月上涨——说实话这半年我自己也焦虑过。后来把一整条工作流里的关键工具都换成了开源 App焦虑反而没那么重了。这篇文章就把我实测下来、真正每天都在用的 9 个开源 App 列出来说清楚它们各自解决什么问题我又是怎么把它们串成一套完整工作流的。文章不会堆概念都是能直接落地、可复现的配置和操作。1. vibe coding 的焦虑到底出在哪1.1 模型选择多反而没法安静写代码vibe coding 的爽感很大程度来自“想到就让AI写出来”。最开始用官方聊天页面和商业IDE的补全体验很顺手。但随着项目变大问题开始一个个冒出来今天用 A 模型写出的代码明天换 B 模型接口调用的写法全变得重新适应。官方对话界面一次只能管一个会话项目背景要反复粘贴每次都在浪费 token。调用多了以后账单爆炸月底看到费用明细才傻眼但又没法精确查到是哪段功能消耗的。在商业IDE里只能用官方预设的模型自己的私有化部署模型根本接不进去。这些问题的根因其实是一件事你把代码的“生产方式”交到了别人手里自己却没有一个统一的管理层。开源 App 的第一个意义就是把这一层的控制权拿回来。所以我在筛选工具时第一个要求就是“模型入口必须可控”编辑器、网关、终端这些关键节点都不能被单一厂商卡死。1.2 上下文断裂是 vibe coding 最大的隐形负债vibe coding 让写代码的成本变低但“忘记之前怎么想的、为什么这么写”的成本反而变高了。真正让人崩溃的不是 AI 写错而是两天后不知道哪个版本改了哪里、为什么改、当时用的是什么 prompt、需求文档在哪儿。这种“项目失忆”在快速迭代时尤其致命。我试过用 Markdown 记录项目脉络效果确实不错。但 Markdown 散落在各个项目目录里时间一长就乱。后来我意识到光有文件不够还需要让文件之间能互相链接、能被索引、能被结构化展示。这就是“全局MD文档”要解决的问题也是后面专门留一整章讲 Logseq 和文档目录组织方式的原因。上下文管理得越好vibe coding 的风险就越低。1.3 我的开源选型标准与工具总览在列具体 App 之前先说一下我筛东西的原则这决定了下面的清单是否适合你本地优先数据尽量留在本地不强迫上传到某个私有云。开放协议能用 HTTP、Markdown、Git 等标准格式交互不搞封闭格式。可替换性任何一环都有替代品不会被一个厂商锁死。更新活跃社区持续维护有 issue 响应不至于用着用着没人管。基于这几条我选了下面 9 个开源 App正好对应 vibe coding 的四个常用环节模型接入、编码环境、需求上下文、调试与设计。环节开源 App解决的焦虑点模型接入Continue编辑器里自由选择模型写代码不用来回切页面模型接入LiteLLM统一网关管理所有模型 API切换模型只改配置编码环境Zed启动快、不打扰适合长时间沉浸写代码编码环境Tabby终端连接清晰高效部署和运行状态一眼掌握需求上下文Logseq双向链接 Markdown 知识库全局记忆不丢需求上下文NocoDB需求、接口、样例表格化项目数据结构一眼看清调试与设计Bruno离线优先 API 调试接口脚本进 Git 可回溯调试与设计GitButler虚拟分支并行开发改一半也不怕乱调试与设计Penpot开发者也能快速出线框稿设计沟通不再干等看到表格你会发现这些工具不是孤立的而是一条流水线上的不同工位。下面我从“模型接入”开始逐个拆解它们在我的工作流里到底怎么用。2. 模型接入与编码环境先把手指和模型理顺2.1 Continue编辑器里直接聊代码、改代码Continue 是我目前使用频率最高的开源 AI 编程助手。它不是一个独立 IDE而是 VS Code、JetBrains 等编辑器里的扩展接入到你的编辑环境中。它最核心的价值是“模型不锁死”你可以在配置里自由选择远程 API、本地模型、开源网关所有请求路径自己掌握。配置方式以 VS Code 为例安装 Continue 扩展后会读取项目里的.continue/config.json。我的基础配置长这样{ models: [ { title: Local Ollama, provider: ollama, model: qwen2.5-coder:14b, apiBase: http://localhost:11434 }, { title: OpenAI Compatible, provider: openai, model: gpt-4o-mini, apiBase: https://your-gateway.example.com/v1, apiKey: sk-your-key } ] }很多人看到配置会问为什么要搞两套模型因为不同任务对模型的要求完全不同。日常补全、简单重构用快模型就够了成本低、延迟低复杂架构调整、跨文件重构才需要强模型。Continue 支持在会话里通过/model命令随时切换这比“改代码换模型”舒服太多。另一个我离不开的能力是代码库索引。Continue 会把当前项目的代码做 embedding 向量化当提问“这个状态管理的逻辑在哪”时它能自动把相关代码片段找出来作为上下文传给模型。这个能力对 vibe coding 尤其重要因为我们经常问的是“那段改到一半的逻辑在哪里”而不是“帮我写一个排序算法”。使用上我最常用两个入口一是cmdI呼出内联编辑直接选中一段代码让 AI 改改完再人工 review二是cmdL打开 Chat 面板把当前文件作为上下文传进去。注意如果模型的上下文窗口不大不要一次性把整个项目塞进去。打开 codebase 索引让 AI 先检索再回答效果会好很多。这个习惯能帮你省大量 token也避免模型被无关代码干扰。2.2 LiteLLM给所有模型调用套一个统一网关如果说 Continue 解决的是编辑器的入口问题那 LiteLLM 解决的就是模型供应商的出口问题。它是一个开源的大模型统一接入层能把几十家模型服务统一暴露成 OpenAI 兼容的接口。项目只需要配一个 base_url 和一个 key后面无论接哪家模型都从这个网关走模型切换、成本统计、限流都在网关里统一控制。我用 LiteLLM 的 proxy 模式最多。安装和启动基本是这样pip install litellm[proxy] litellm --model openai/gpt-4o --port 4000但真实环境里你不会只挂一个模型而是写一个 config 文件把常用模型都注册进去model_list: - model_name: gpt-main litellm_params: model: openai/gpt-4o api_key: os.environ/OPENAI_API_KEY - model_name: deepseek-main litellm_params: model: deepseek/deepseek-chat api_key: os.environ/DEEPSEEK_API_KEY启动之后所有支持 OpenAI 协议的应用只要把base_url指向http://localhost:4000/v1、key 填任意一个有效值就能在gpt-main和deepseek-main之间切换。我不需要改业务代码只需要在请求里传不同的 model 名或者在网关层做路由策略。为什么这对 vibe coding 很关键因为 vibe coding 会产生大量的“生成式调用”一旦某个模型涨价、限流或者质量下降如果所有代码都硬编码了厂商 SDK替换成本高到让人想放弃项目。有了网关切换只改一处配置。我个人习惯是为不同用途分配不同模型日常补全用快模型复杂重构用强模型。LiteLLM 的日志会把每次调用的模型、token 数、耗时都记下来月底对账一目了然心里踏实很多。2.3 Zed安静、快、不打扰的编辑器底子Zed 是近两年给我惊喜最大的一款编辑器。它由 Atom 团队部分核心成员开发底层用 Rust 编写启动速度和输入延迟控制得非常理想。在 vibe coding 场景里我们需要的是一个“能长时间沉浸、不会因为卡顿打断思路”的环境Zed 在这件事上做得很好。Zed 最打动我的三个点第一是 GPU 加速渲染大量文件和长行代码基本不卡第二是多人在线协作两个人同时在一个 Buffer 里改代码修改实时同步对“两个人一起 vibe coding”很友好第三是内置终端和 LSP 支持配置好settings.json后rust-analyzer、typescript-language-server 这些东西开机即用。{ theme: One Dark, autosave: on_focus_change, languages: { TypeScript: { language_servers: [typescript-language-server, !vtsls] } } }有一点要说明Zed 主仓库是开源的但它协作服务器不是全部开源如果你只是本地单人使用影响不大团队要用云协作的话需要按自己的接受度评估。我通常把 Zed 和 Continue 的 HTTP 模式一起用Continue 跑在本地服务编辑器调用同一套 API。这样我就不被某个特定 IDE 绑定哪天换回 VS Code 也顺滑。2.4 Tabby终端才是 vibe coding 最后的归宿很多“高级操作”最后都会回到终端跑测试、查日志、看数据库、部署预览。Tabby 是一个开源跨平台终端模拟器我选它主要是为了把一大堆服务器连接、配色方案和快捷键统一起来。它能保存 SSH 连接双击就能连上开发机支持自定义键位绑定我把它调成和 Zed 基本一致的复制粘贴快捷键切换时基本零适应成本。实际工作中我习惯把 vibe coding 项目分成三块编辑器写代码、浏览器看结果、Tabby 管部署和日志。线上出了问题先开 Tabby 看日志很多“AI 写出问题”的线索都藏在里面。Tabby 本身没有内置 AI 功能但我反而觉得这是优点终端工具最重要的是稳定不能因为一个终端里嵌了 AI 功能就动不动崩溃。如果你确实想在命令行里用 AI可以在另一个 Tab 里跑 Continue 的 CLI或者配一个 shell 层的小工具清爽还不干扰主流程。对经常操作多台服务器的人来说Tabby 的连接管理功能能省很多记忆成本不用每次输ssh userhost双击连接多开会话每个会话独立配色一眼就能分辨线上和测试环境。3. 需求上下文与全局MD文档别让项目“失忆”3.1 Logseq用双向链接把碎想法变成上下文库vibe coding 最需要的是“连续记忆”。AI 可以帮你写函数但没法替你记住两天前的需求变化除非你有一个随时可查、结构良好的上下文库。Logseq 是我目前用来维护这类上下文的主要开源工具。Logseq 是本地优先的笔记工具所有内容默认以 Markdown 文件存放在本地目录。它最大的特点是块级双向链接你把一个想法写成一个块然后在另一篇笔记里引用它两个地方就会自动建立关系。对项目来说我会建一个VibeProject/文件夹里面放三个文件Background.md项目背景、Prompts.md历史 prompt 与效果、Decisions.md关键决策记录。写代码时遇到“为什么这里用了 Redis 而不是内存缓存”这种问题就在 Decisions.md 里补一个块顺便链接到对应代码文件。这种方法的价值在几周后尤其明显。vibe coding 项目迭代快代码注释经常跟不上但只要 MD 文档坚持随手写几行搜索起来极其方便。Logseq 默认按 journals 生成日志每天花两分钟把当天的改动原因记一条就形成了一条按时间线索引的全局 MD 档案。注意同步Logseq 支持使用本地 Git 仓库同步也可以配合网盘。用 Git 同步时如果多台设备同时在写同一个文件会产生冲突后面常见问题里我会专门说怎么处理。3.2 NocoDB把需求、接口和测试样例变成可检索的表格光有 MD 文件还不太够有些数据天然适合结构化保存比如“接口清单”“模型配置”“需求状态”。如果全写在 Markdown 里列表会越来越长查起来也不方便。NocoDB 就是用来处理这类问题的它是开源的在线表格数据库部署后可以像用电子表格一样操作数据同时底层是标准数据库还能对外生成 REST API。部署也不复杂本地用 Docker 起一个实例docker run -d -p 8080:8080 \ -e NC_DBsqlite3:///data/nocodb.db \ -v ./nocodb-data:/usr/app/data \ nocodb/nocodb:latest起来之后我通常会建三张表requirements需求标题、描述、优先级、状态、关联日志链接。apis接口路径、方法、请求示例、响应示例、负责人。model_calls模型名称、使用场景、请求量、费用估算。这些表格和 Logseq 里的 MD 形成了互补MD 负责叙事和推演NocoDB 负责状态和枚举。因为 NocoDB 本身有 API如果后续想把表里的数据自动喂给 AI 做项目看板也完全可行。对 vibe coding 来说它带来的最大改变是你不用靠“印象”管理项目了需求、接口、模型调用这些关键数据都被结构化沉淀下来。3.3 我的“全局MD文档”具体怎么组织前面提到全局 MD 文档是 vibe coding 的一项刚需。这里分享我整理过的一版可复制目录结构它不复杂但规矩很重要project-root/ ├── docs/ │ ├── 00-index.md # 项目索引写清各文件入口 │ ├── 01-background.md # 背景、目标、非目标 │ ├── 02-prompts.md # 常用 prompt 模板与版本记录 │ ├── 03-decisions.md # 决策记录格式日期/背景/决策/原因 │ └── 04-changelog.md # 每天改了什么配合 Logseq journals ├── src/ └── ...在02-prompts.md里我会把高频 prompt 存成带编号的条目比如“P01生成 CRUD 接口”“P02重构这个函数并解释原因”。下次要用直接复制不用现场重编。03-decisions.md每一条都写成四行日期、背景、决策、原因。这个习惯让项目即使放三个月后再捡起来也能快速恢复核心上下文。这套规则不依赖任何特定软件用 VS Code 打开 Markdown 就能读写。配合 Logseq 的话还能在 MD 之间做链接和回溯体验会更好。要是团队做“全局MD文档”越做越重最后变成一堆没人看的文档那就不是工具的问题是组织方式的问题。文档的价值不在量在于“需要时能不能三秒找到”。所以宁可短不可乱。4. 调试、设计与版本控制把过程中的不确定性压到最低4.1 Bruno离线优先的 API 调试工具vibe coding 项目通常是前后端一起改必然要频繁调试接口。我过去一直用 Postman但它的配置和账户体系越来越重请求集的存储方式也比较封闭。Bruno 是我后来换成的开源方案核心特点是“离线优先、文件即配置”。每一个接口请求都保存成一个.bru文本文件存放在 Git 仓库里随项目一起版本控制。一个简单的 GET 请求文件长这样meta { name: Get User type: http seq: 1 } get { url: http://localhost:3000/api/users/1 body: none auth: none }因为是纯文本你可以直接在代码里查看、diff、review。对 vibe coding 流程来说这意味着接口调试记录不会丢团队协作也不需要导出导入 collectiongit pull一下就全都同步了。Bruno 还支持环境变量可以把base_url抽出来在本地和测试环境之间切换不用改每个文件。我的个人经验是把 Bruno 和 OpenAPI 规范配合使用先在项目里维护一份openapi.yamlBruno 的请求尽量按同样的路径和字段组织。这样接口一旦变化文档、测试、代码可以在同一轮改动里同步起来避免“后端改了接口但前端还在调旧字段”的经典事故。对 vibe coding 这种快速迭代模式少一条这类 bug 就是多保住一段完整的开发节奏。4.2 GitButler虚拟分支让多线改动不打架vibe coding 里有个很有代表性的场景正写着功能 A产品突然来了一个紧急需求 B。你不想把 A 改了半天的逻辑丢掉又不想开分支切来切去。GitButler 提供的“虚拟分支”就是针对这个场景设计的它允许你在同一个工作目录下同时管理多个功能分支每个分支对应一组文件和改动提交时可以按分支归类和汇总。实际体验上它有点像给 Git 加了一层分拣缓存。你正常写代码文件改动默认进入当前虚拟分支发现有些改动其实属于另一个任务直接在 GitButler 界面里把文件拖到另一个虚拟分支即可。等某个分支的功能准备好了再单独推送。这样你就没必要频繁git stash、git checkout大大减少了改到一半被迫切换的恐惧感。要提醒一句虚拟分支最终落地时还是和远程仓库交互的所以你不能完全不懂 Git 基础概念。GitButler 解决的是“本地多线开发”的组织问题而不是替代 Git 本身的逻辑。如果你正在用git worktree管理多分支可以把 GitButler 当成一个可视化替代品来评估。4.3 Penpot不会画图的人也能快速出线框稿vibe coding 里有个隐藏需求动手前最好先有个草稿不然和需求方沟通全靠脑补。Penpot 是开源的设计和原型工具定位和 Figma 有重叠但代码和资源可自托管。对我来说它不一定要画得多精致只要能把页面结构、按钮层级、交互流程表达清楚就足以让 AI 生成代码时少走很多弯路。实际使用中我最常用的是“九宫格草图法”把页面拆成导航、内容、侧边、状态区等几个区域画成带颜色的矩形框再加几条连接线表示跳转关系。然后把这个线框截图放到 Logseq 的 MD 文档里作为 prompt 的一部分喂给 AI“按这张草图的布局生成首页组件。”这样比直接说“帮我做个首页”要可靠得多因为 AI 能明确看到区域划分。Penpot 还能把设计稿里的颜色、字体间距导出成 CSS 变量。虽然直接在代码里定义 design token 也可以但有一个可视化的设计源头能让非前端同事也参与讨论。对 vibe coding 团队来说少一份“描述偏差”就少一次返工这是省钱省时间最简单的方式。5. 实测中踩过的坑与排查清单5.1 模型接入层最常翻车的几个细节先说模型接入这块坑最多。第一个坑是 API 地址写错。很多自建网关的路径是http://host:port/v1补全时通常还要带/chat/completions有的模型兼容的是/completions。最稳妥的做法是先用 curl 测一遍通不通再填到配置里。第二个坑是上下文长度。vibe coding 对话一长很容易触碰上下文窗口上限表现就是模型突然“失忆”或者直接报错。处理办法是启用编辑器的 codebase 检索减少系统提示与无关代码的注入同时在网关层给不同模型设置合理的max_tokens。第三个坑是 key 管理。网关里的 key 如果写在明文配置文件里容易被误传。建议用环境变量注入并定期轮换。开源工具下载也一样不要随便在第三方渠道搜“app 下载”尽量从官方 GitHub 仓库或官网获取避免遇到套壳或被篡改的版本。5.2 全局MD文档与知识库同步的冲突Logseq 本地优先多设备同步是个现实问题。我最初直接用网盘同步结果两台电脑同时改一个文件冲突直接出现在日志里把文件搞乱。后来我改用 Git 仓库同步并约定“同时只在一台设备上做当天的 journal 记录”冲突率降到很低。如果还是遇到冲突可以用 Logseq 的冲突文件恢复机制把内容打开比较保留较新版本。更重要的是养成“过一遍再提交”的习惯不要在完全没看的情况下直接 push。NocoDB 则要格外小心数据库迁移。如果你直接在宿主机上docker run升级镜像前一定要备份NC_DB或挂载的 SQLite 文件。我遇到过升级后版本不兼容、表结构异常的问题后来固定了镜像版本非必要不升级升级前先备份。5.3 一套可以长期用的避坑清单我把日常容易踩到的场景整理成了一张表方便你直接对照现象常见原因处理方式编辑器 AI 请求超时网关地址填的是 localhost但编辑器在远程容器里把 base_url 改成宿主机可达 IP并确认网关端口已放通补全质量突然下降模型上下文被项目文件塞满打开 codebase 索引精简注入片段换更专注的 prompt接口调试时 token 频繁过期测试环境的鉴权没走统一入口在 Bruno 里设置环境变量统一维护 token 请求脚本GitButler 分支状态混乱远程基础分支合并逻辑没理清先只建一个虚拟分支练手熟悉后再并行两个Logseq 文件丢失多设备同步冲突或误删启用 Git 同步设置本地备份每个设备操作前先 pull 再写这份清单不是什么高深理论都是踩过之后才总结的教训。vibe coding 最重要的不是快而是出问题后能快速定位和恢复。工具再多看不懂日志、找不到文档照样会焦虑。最后说点个人体会。这轮把工具换成开源 App 之后我最大的变化不是省了钱而是终于能看懂自己这套工作流的每一个环节模型走哪个网关、上下文存在哪个 MD 文件里、改动落在哪个虚拟分支上、接口数据从哪张表里来。焦虑的根源往往是失控开源工具提供了一个“即使出问题我也能自己下场修”的可能性。如果你也在 vibe coding 的路上觉得心里没底不用一次上齐这 9 个先试试 Continue 和 Logseq把模型入口和上下文记忆理顺那种发慌的感觉就会小很多。工具不在多能让你心里有底的那套才是好工具。