如果说前两年大家还在争论 AI 能不能写代码那我身边现在已经没人争了——大家都在 vibe coding。所谓 vibe coding说人话就是你只负责描述需求、接收结果、纠正方向代码主体交给 AI 来生成整个人处于一种“跟着感觉走”的状态。但我得诚实说一句这玩意儿爽归爽焦虑起来也真要命。最典型的一种场面AI 一口气给你生成 800 行代码你看着编辑器里一大片新增内容心里冒出的第一个念头不是“哇好厉害”而是“这到底改的是啥别人问起来我怎么讲清楚万一挂了怎么回滚”我把这种状态叫 vibe coding 焦虑。我缓解焦虑的办法有点笨把身边能换的工具全部换成开源 App。听着像反方向折腾但实际用下来效果出乎意料。这篇文章就把我这套“开源工具箱”完整列出来一共 9 个覆盖从写代码、改代码、跑代码到沉淀经验的全过程。如果你也正在被 vibe coding 折磨建议先收藏再一个个装回来试用。1. 先把焦虑说透vibe coding 为什么会让人心慌工具只是治标先把病根找出来才知道该往哪个方向使劲。所以这一章不急着列清单先把 vibe coding 的焦虑来源拆干净。1.1 vibe coding 到底是什么为什么它能火vibe coding 这个词最早流行起来是形容一种高度依赖 AI 生成代码的写代码方式人不太关心每一行代码的具体实现更关注“整体感觉对不对”“跑起来是不是我想要的”然后让 AI 不断修改调整。你可以理解为把写代码的重心从“亲手敲字”转移到了“喂需求 验收结果”。这种模式能火是因为它真的把入门门槛和单点产出效率拉高了。以前写一个爬虫、写一个小页面、做一个内部工具可能要从语法开始查现在丢给 AI 几十秒就能出来一个能跑的版本。很多非专业出身的人也能靠着 vibe coding 做出自己的自动化脚本、小型网站、数据看板这是好事。但问题也随之而来。传统写代码的时候哪怕水平再差你至少清楚某一段代码是你自己写的、为什么要这么写。vibe coding 不一样它经常会出现“AI 写完了我却看不懂”的荒诞场景。这个荒诞感如果累积起来就会变成一种持续的心慌严重的时候会让人连打开编辑器的欲望都没有。1.2 焦虑究竟从哪来五个真实来源我把自己的焦虑来源拆成了五类你可以对照一下自己的情况。第一是黑盒焦虑。AI 为什么用这个方案、为什么给这个函数加了个奇怪的参数、为什么选择这种数据结构它不会主动跟你解释。一旦代码出了问题你连排查的起点都找不到只能反复把报错信息再喂回给 AI像在跟一个记性不太好的同事反复掰扯。第二是失控焦虑。vibe coding 经常是“改这里、再改那里”改到后面项目变成了一个比原来大好几倍的状态。你不知道哪些文件是 AI 新加的、哪些是它顺手改过的更不知道这些改动之间有没有隐藏的耦合。想撤销不敢不撤销又怕埋雷。第三是复现焦虑。昨天跑得好好的功能今天再启动就报错聊天记录一关当时给 AI 喂了哪些上下文、用了哪个提示词全都没了。这类问题碰到一次就够让人抓狂因为它是“无法复现的灵异事件”。第四是隐私和信任焦虑。很多 vibe coding 场景会把代码、数据库结构、业务逻辑直接贴给云端 AI。代码本身可能不敏感但一个项目长期处于“什么都被 AI 看过”的状态多少会让人心里打鼓。再加上闭源工具哪天突然调整策略、改价格、关功能你完全没有任何左右局势的空间。第五是工程质量焦虑。AI 生成代码的速度太快了快到 human review 根本跟不上。于是代码里经常出现重复的依赖、硬编码的配置、没人用的函数。等回头想重构你会发现改动面巨大根本不敢动。1.3 为什么开源是解药而不是新的折腾开源解决的不是“代码写得更好”而是“你对项目还有掌控感”。开源 App 最核心的两个特性正好对着上面的焦虑来。第一是透明核心代码你都能看理论上所有行为都可以被审查不存在真正的黑盒。第二是可控你可以改、可以导出、可以离线使用、可以把配置放进 Git 管理工具的命运不完全掌握在别人手里。更重要的是开源工具的配置文件基本都以纯文本形式存在。这听着好像没什么但对 vibe coding 场景来说是巨大的优势。因为纯文本意味着可 diff、可版本管理、可追溯。你的 AI 助手配置、API 请求集合、画图源文件、终端方案全部都能像代码一样纳入 Git 管理。这种“一切修改都有痕迹”的工作方式本身就是对失控感的直接对冲。不是说装了开源工具焦虑就消失了而是焦虑从“不可名状的慌”变成了“一个个具体的技术问题”。具体的问题就有具体的解法这是我这套方案的核心逻辑。2. 9 个开源 App 的选型逻辑我是按工作流补工具不是按排行装软件很多人找工具喜欢搜“最好用的开源软件”然后装一堆回来吃灰。我自己的方法不太一样先把自己的工作流画出来找到每个环节最让人焦虑的痛点再针对痛点选工具。这样选出来的清单也许不是最热门的但一定是最顺手的。2.1 我心中的 vibe coding 工作流长什么样我把一次完整的 vibe coding 过程拆成六个环节写、改、跑、画、藏、存。写就是让 AI 生成和修改代码对应的是 AI 助手和编辑器。改是对 AI 的改动进行审查和回滚对应的是 Git 工具。跑是把代码跑起来、调接口、查数据库对应的是终端、接口客户端和数据库客户端。画是把 AI 生成出来的结构可视化成架构图对应的是绘图工具。藏是让隐私代码不离开本机对应的是本地模型运行时。存是把过程中的需求、文档、问题处理经验沉淀下来对应的是知识库工具。这六步里任何一个环节失控都会让 vibe coding 变得很难受。所以我的选型不是追求某一个工具大而全而是希望每个环节都有可靠的开源方案兜底。2.2 我的选型标准不额外增加心智负担定标准比列清单更能帮到你因为我筛掉了大量看起来很酷但实际不实用的东西。必须开源这是底线。能做到底层代码可审查的才值得长期投入。优先离线可用网络条件好的时候用云端模型没问题但工具本身不能离开网络就没法用否则焦虑会变成另一个形态。配置必须是文本文件所有设置、请求集合、工作区信息都能保存成纯文本可以进 Git可以 diff这是可追溯的基础。上手成本不能太高一个工具如果光配置就要折腾一下午那它就不是缓解焦虑而是制造焦虑。不搞 All-in-one宁可几个小工具各管一段也不想被一个超级复杂的全家桶绑架。按这个标准筛下来能留在清单里的基本都不是花架子。2.3 9 个开源 App 一览表工具类型负责环节入选理由Continue.devAI 代码助手写上下文透明、模型可切换、配置可进 GitVSCodium编辑器写纯开源构建去掉遥测扩展生态完整lazygitGit 终端客户端改用键盘快速审查 diff让回滚变成肌肉记忆BrunoAPI 客户端跑请求集以文本存储和项目仓库天然同步DBeaver数据库客户端跑直接验证 AI 生成的 SQL 和 ORM 逻辑diagrams.net绘图工具画把 AI 方案画成图图形化审查系统结构Ollama本地模型运行时藏代码不出本机隐私敏感场景的兜底WezTerm终端模拟器跑跨平台、配置统一给命令行操作建立秩序AnythingLLM知识库 AI 问答存把 vibe coding 经验和文档沉淀成个人库后面我会逐个讲它们到底怎么用、在什么时候能救我一把。这不是广告式的功能介绍而是我踩坑之后真实留下的用法。3. 逐个拆解9 个开源 App 的定位、用法与心得这一章是全文的干货大头。我会按工作流的顺序讲先讲“写”的环节再讲“改”“跑”“画”“藏”“存”这样你跟着读下来就能得到一整套可以落地的组合方案。3.1 Continue.dev让 AI 的“判断依据”不再是个谜Continue.dev 是一个开源 AI 代码助手以 IDE 插件的形式为主也提供 CLI。它支持 VS Code、JetBrains 系列能够接入 OpenAI 兼容接口、Anthropic 接口以及 Ollama 这类本地模型。也就是说你既可以用它连云端大模型也可以让它操作完全本地的模型。我选择它的关键原因只有一个上下文管理透明。用某些闭源助手的时候你永远不知道它到底读了你哪些文件、为什么突然改了某个不相干的地方。Continue.dev 提供了一个清晰的上下文面板你可以在 conversations 里看到当前对话引用了哪些文件、哪些代码片段还能手动增删。这意味着 AI 的“判断依据”是可以被追踪的。它的配置也是纯文本 JSON通常放在项目目录的.continuie/config.json下。一个最小可用的配置长这样{ models: [ { title: Local Ollama, provider: ollama, model: qwen2.5-coder:7b, apiBase: http://localhost:11434 }, { title: Cloud API Compatible, provider: openai, model: gpt-4o-mini, apiBase: https://api.example.com/v1 } ] }这个配置文件可以被提交进 Git换电脑、换项目、换团队都能共享同一套 AI 配置不再出现“你的助手设置和我这边不一样”的问题。我在实际使用中还有一个心得不要只用一个模型。复杂业务逻辑用云端强模型解释代码、补注释、写单元测试草稿用本地小模型两者配合成本和隐私都能兼顾。3.2 VSCodium把编辑器本身也变成可审查的一部分VSCodium 是微软 VSCode 的社区开源构建版本去掉了微软的遥测和品牌相关内容代码更干净。如果你对“编辑器到底往外面发了什么数据”这件事有洁癖VSCodium 是一个非常好的选择。有人可能会问那和直接用 VSCode 有什么区别区别在于掌控感。vibe coding 场景下你常年开着 AI 插件、贴入各种代码片段如果编辑器本身就是一个闭源黑盒那你的隐私焦虑永远消除不了。VSCodium 的二进制可以从源码构建所有行为都有代码可查至少你在“工具层”没有后顾之忧。它和 VSCode 的扩展生态基本兼容Continue.dev 完全可以正常安装使用。也就是说你不需要改变任何操作习惯只是把脚下的地板从“不知道什么材质”换成了“木板底下有什么都看得见”。使用心得上有一条很实用在 VSCodium 里把“自动保存”关掉改成CtrlS手动保存。vibe coding 的时候 AI 改文件频繁如果自动保存开着lazygit 里的 diff 会一直跳动根本看不清改动。手动保存能让你在最舒服的时机审视 AI 的修改这一步后面配合 lazygit 非常好用。3.3 lazygit让“回滚 AI 的乱改”变成肌肉记忆lazygit 是一个终端里的 Git 客户端界面是 TUI 风格没有鼠标操作所有动作靠快捷键。我第一次用时觉得完全没必要用了两周后才发现它是整个工作流里最提神的一个环节。vibe coding 最大的痛点之一是你不知道 AI 改了啥。传统做法是回编辑器里点开 diff 一个个看效率很低。lazygit 把这个问题压缩到几个快捷键里按空格暂存某个文件按回车展开文件内的具体改动按c提交按p推送。整个过程全键盘操作手不用离开终端思考也不用跳出代码状态。最实用的场景是“带过滤地提交”。AI 可能一次改了十几个文件但你只想提交其中三个。lazygit 可以精确到 hunk 级别去暂存你不用复制粘贴代码也能只把想要的部分纳入提交。这个能力对 vibe coding 来说太重要了它让你从“AI 给什么我吃什么”变成“我决定哪些改动可以进入历史”。我在使用中发现一个小技巧每次让 AI 改东西之前先开一个 lazygit 终端按s把当前状态 stash 掉或者用git tag打一个快照。这样如果 AI 改出了不可收拾的局面一条命令就能回到干干净净的起点。这种“随时能跑路”的安全感才是治焦虑的特效药。3.4 Bruno让接口请求像代码一样存在项目里Bruno 是一个开源 API 客户端设计理念是 offline-first 和 git-friendly。它不像 Postman 那样把请求集合存在云端账号里而是把每个请求保存为一个.bru文件放在项目目录下天然适合纳入版本管理。vibe coding 过程中AI 经常生成一堆接口代码你需要快速验证。用 Bruno 的好处是你写完一个请求它就是一个文本文件你可以和代码一起提交。下次再看这个接口最初的设计参数、请求头、环境变量全都能从文件里读出来不再依赖“我记得当时填过什么”。举个例子一个最简单的.bru文件长这样meta { name: Get User Info type: http seq: 1 } get { url: http://localhost:8000/api/user/42 body: none auth: none }和普通 API 客户端一样Bruno 也支持环境变量、断言、脚本但这些都不是我最看重的。我最看重的是“可读的历史”接口从 v1 改到 v2每次改了什么git diff 说得清清楚楚。对 vibe coding 用户来说接口请求集合不再是工具里的私有数据而是项目资产的一部分。3.5 DBeaverAI 说“这样查最快”不如你自己看一眼执行计划DBeaver 是开源数据库客户端支持 MySQL、PostgreSQL、SQLite、SQL Server 等常见数据库界面友好功能足够日常开发使用。我把它放进清单是因为 vibe coding 里有一个高频死法AI 生成的 SQL 或 ORM 查询逻辑没毛病但性能奇差或者根本没查到自己想要的数据。DBeaver 让我能在不写代码的情况下直接连上数据库查看表结构、浏览数据、执行自定义 SQL、分析执行计划。拿到 AI 生成的一长串 join 查询先扔进 DBeaver 跑一遍看返回行数是不是真的符合预期再看执行计划里有没有全表扫描心里立刻有数。一个真实例子AI 给我写了一套“统计用户订单总额”的查询逻辑看起来天衣无缝但跑出来数据翻倍了。我用 DBeaver 拆开每一步 join发现源表里存在重复订单号原因是前一个版本的脚本曾经把相同订单写入两次。这个坑靠“读代码”很难发现靠“看数据”一眼就能定位。所以我的使用习惯是DBeaver 永远和编辑器并列开着。AI 出 SQL 我贴进 DBeaver 实践一遍AI 出 ORM 代码我手动执行对应的原生查询对比结果。这一步多花五分钟能省掉后续三四个小时的排查。3.6 diagrams.net把 AI 画出来的架构“画”回人脑里diagrams.net 就是曾经的 draw.io是一个开源绘图工具支持绘制架构图、流程图、UML 图、思维导图等。源文件默认是 XML 格式同样可以存进 Git方便追溯每次架构调整。为什么绘图能治 vibe coding 焦虑因为当 AI 生成的代码越来越多你的大脑其实跟不上它的结构。你可能知道 A 模块调了 B 模块但说不清 B 模块还依赖哪些数据表、外部接口、消息队列。这种“只见树木不见森林”的感觉正是失控感的来源。我的做法是每完成一个阶段性功能就让 AI 结合代码生成一份模块关系说明然后我盯着代码在 diagrams.net 里画出实际的结构图。有时候画着画着就会发现哪里不对劲——比如两个模块互相引用、某个中间层被绕过、数据流方向跟预期相反。这些都是纯读代码时很难快速察觉的问题。画完的图还有一个妙用作为后续 AI 对话的上下文。下次你再让 AI 加功能可以先丢一句“当前系统结构如图请基于这个结构修改 xxx”AI 的理解会比只丢一堆文件路径更准确。图其实就是你和 AI 之间共享的一份“系统心智模型”。3.7 Ollama把隐私代码留在本机敏感项目也能 vibeOllama 是一个本地模型运行时支持在本地运行 Llama、Qwen、DeepSeek 等一系列开源模型。它通过一个简单的 HTTP 接口提供服务默认端口是 11434可以被 Continue.dev、AnythingLLM 等工具直接调用。我强烈建议所有做 vibe coding 的人都在本机装一个 Ollama哪怕你日常主要用云端模型。原因只有一个总有一些代码不合适贴给外部服务。比如涉及到未公开的业务逻辑、客户数据、内部工具的认证信息你不可能把这些原样塞给云端 AI。这时候 Ollama 就是兜底方案。启动一个本地模型很简单ollama pull qwen2.5-coder:7b ollama run qwen2.5-coder:7b接着在 Continue.dev 里配置provider: ollama它就会被当成一个普通的模型源来使用。本地小模型写复杂业务确实不如云端大模型但用来做代码解释、变量命名、生成测试数据、整理注释这类偏“杂活”的任务完全够用而且实时性非常好。使用心得方面有两条。第一注意内存占用。7B 模型跑起来大约需要 8GB 内存如果你同时开着浏览器、编辑器、数据库客户端机器会明显变卡。建议挑量化版本比如qwen2.5-coder:7b-instruct-q4_K_M能省不少资源。第二不要指望本地模型能一步到位生成大段业务代码把它当作一个离线可用的辅助大脑而不是主力开发心态会平和很多。3.8 WezTerm终端也要能搜索、能分屏、能被配置文件管起来WezTerm 是一个开源终端模拟器跨平台支持 Windows、macOS、Linux使用 GPU 加速渲染配置基于 Lua。它看起来没有某些网红终端那么惊艳但长期用下来反而是稳定感最强的。vibe coding 离不开命令行跑起项目看日志、执行 git 操作、启动本地服务、查看端口占用。系统自带终端也不是不能用但当你同时开着四五个标签页、频繁切换日志和命令执行窗口时一个称手的终端能明显降低烦躁感。WezTerm 的多标签、多分屏、快捷键配置都非常成熟。配置文件是一个 Lua 文件你可以把字体、主题、快捷键、启动命令全部写进去然后把这个文件放进 dotfiles 仓库。换一台电脑拉下仓库、装好 WezTerm整个终端环境 10 分钟内恢复。这种“环境可以精确复现”的感觉本身就是对不可控感的消除。一个我常用的配置片段local wezterm require wezterm return { font_size 13.0, color_scheme Catppuccin Mocha, enable_tab_bar true, keys { { key t, mods CTRL, action wezterm.action.SpawnTab CurrentPaneDir }, { key n, mods CTRL, action wezterm.action.SplitVertical { domain CurrentPaneDomain } }, }, }我一般会把 WezTerm 和 lazygit 搭配起来左半屏跑日志右半屏开 lazygit中间再开一个小的、专门用来跑测试命令的面板。整个 vibe coding 过程像在操纵一个属于自己的控制台而不是在一个陌生的黑框里碰运气。3.9 AnythingLLM把聊过的问题都沉淀成自己的知识库AnythingLLM 是一个开源的知识库 AI 对话应用有桌面版和 Docker 版。你可以把文档、Markdown、文本内容拖进某个 workspace它会自动做切分和向量化之后你说的话、问的问题都可以基于这些资料进行回答。它内置多种向量存储方式默认的 LanceDB 不需要额外配置桌面版拿来即用。这个工具解决的是 vibe coding 里最隐蔽的焦虑经验无法沉淀。你跟 AI 聊了半天终于解决了某个奇怪的报错然后聊天记录一关下次遇到同样的坑又要从头喂一遍上下文。这种重复劳动特别消耗耐心而且让人觉得自己一直在原地打转。我的做法是每解决一个值得记录的问题就把当时的需求背景、报错信息、解决步骤整理成一段 Markdown丢进 AnythingLLM 的一个专用 workspace。比如“连接池报错”“端口被占用”“依赖版本冲突”这类高频问题积累几周之后再提问它几乎能直接给出可用的步骤。相当于给过去的自己装了一个问答接口。AnythingLLM 也可以配置本地模型作为聊天后端和 Ollama 配合起来整套知识库是离线可用的。这样你沉淀的不仅仅是知识还有一种“以后这个问题不用再慌”的安全感。4. 一套可以抄作业的 vibe coding 工作流工具列完关键是把它们串起来用。这一章我以“给一个 Django 小项目新增一个离线查询接口”为例展示一次完整的、不会让人心慌的 vibe coding 流程。4.1 从想法到提交一次完整的 vibe coding 实操第一步在 Continue.dev 里把需求描述清楚要求 AI 先生成方案而不是直接写代码。比如我会说现在有一个 Django 项目我想新增一个接口它接收用户 ID返回该用户最近的订单列表要求只查数据库不调外部服务。你先给一个实现方案确认后我再让你写。这一步能很大程度避免 AI 跑偏。第二步AI 给出方案后打开 diagrams.net 简单确认模块关系。不用画得多精致只需要画出“视图层 → 服务层 → 数据访问层 → 数据表”这么一条链确认 AI 对现有结构的理解有没有错误。有问题就直接在这个阶段纠正而不是等写完 500 行代码再返工。第三步确认无误后让 AI 动手写。这时候在 VSCodium 里关掉自动保存等 AI 改完先手动CtrlS然后切到 lazygit逐个文件看 diff。我会重点看三件事有没有改动无关文件有没有硬编码的配置有没有明显的安全隐患。这个过程不能省它决定了这次提交是“可控的演进”还是“埋了个雷”。第四步本地验证。终端里用 WezTerm 启动 Django 开发服务器python manage.py runserver 0.0.0.0:8000然后在 Bruno 里新建一个请求调用新增的接口确认返回数据和预期一致。如果接口数据有问题再打开 DBeaver直接查数据库里的订单表确认是 SQL 逻辑写错了还是源数据本身就有问题。第五步把这次的经验沉淀下来。无论这次开发是否顺利我都会在 AnythingLLM 里补一段 Markdown记录这次接口设计的思路、遇到的问题、以及最终采用的方案。尤其是“AI 第一次给出的方案为什么不行”这个信息对后续开发特别有价值。第六步提交代码。在 lazygit 里暂存本次所有改动写上清晰的提交信息推送前再看一眼 diff 有没有漏掉敏感信息。到这里整个流程才算画上句号。4.2 提交前的自检清单每次提交之前我会对着这份清单过一遍大概花三分钟但能避免 90% 以上的返工是否只包含本次任务相关的文件lazygit 里一眼就能看到有没有多余改动。是否有硬编码的 IP、密钥、数据库密码这个必须检查AI 非常喜欢把配置写死在代码里。是否能本地复现启动命令是否写在 README 里如果下次打开终端就想不起来怎么跑那这次提交还不完整。是否理解核心实现哪怕不是每一行都懂至少要能说清楚“这个接口经历了哪几步”。如果自己都讲不清楚说明需要 AI 补充注释和说明。是否回滚得掉当前状态打标签了没有我个人的习惯是git tag backup-before-xxx一条命令的事但能救命。这套流程看起来比“直接让 AI 一顿改”多花了一些时间但换来的是每一段代码都有清晰的来路和退路。对我这种容易焦虑的人来说这笔时间花得值。5. 常见问题与避坑实录工具用久了必然会碰到一些和 vibe coding 场景强相关的问题。这里挑几个我真实踩过的坑整理成速查表也把排查思路一并写出来。5.1 问题速查表症状可能原因排查方式与解决Continue.dev 始终连不上模型 APIbaseUrl 配错、key 失效、本地模型端口没起先检查config.json里的apiBase再确认 Ollama 或云端服务是否能正常访问本地 gradio 或开发服务起不来报127.0.0.1:7860相关错误端口被占用或服务启动依赖的版本冲突用lsof -i:7860查看端口占用kill 掉旧进程重启终端再试前端报app is not definedJS 变量作用域写错、脚本加载顺序不对检查 script 标签顺序确认全局变量确实挂在了window上lazygit 里发现提交了不该提交的文件提交前没有精细挑选改动重新 checkout 该文件重做一次用空格键逐 hunk 暂存Ollama 跑起来后电脑卡顿内存不足或模型没有用量化版本换成 4bit 量化模型限制OLLAMA_NUM_PARALLEL并发数AnythingLLM 回答总是答非所问文档切分粒度过大、嵌入模型不合适调整 chunk size换成更强嵌入模型或把文档拆成多个更小的片段AI 改完代码后原有功能崩了没有控制好修改范围立即切到 lazygit 查看改动文件列表使用git stash或git checkout回滚项目跑起来了但不知道用的哪个端口配置分散、环境变量不一致统一用.env管理端口并把这套变量文件纳入 Git 模板5.2 独家避坑心得最后分享几条纯粹来自个人实践的心得希望你能少走弯路。第一不要从头到尾让 AI 一口气写完一个完整功能。把任务拆成“设计 → 骨架 → 函数实现 → 联调”四步每一步让 AI 只负责当前层。这样每部分的代码量都在你的理解范围内review 负担小很多。第二把工具配置全部放进 dotfiles 仓库。WezTerm 的 Lua 配置、Continue.dev 的 JSON 配置、lazygit 的配置文件、Bruno 的请求集全部纳入 Git。换一台电脑10 分钟恢复整套环境这种“无论在哪我都认识我的工具”的感觉对缓解焦虑有奇效。第三给项目定期打 tag尤其是进入新阶段之前。先git tag pre-xxx-${date}然后放心让 AI 折腾。打 tag 的成本几乎为零但每次自责“早知道就该备份一下”的时候一条命令就能回到干净状态。第四不要全信 AI 对报错原因的判断。AI 有时候会把完全不相干的两个问题硬凑到一起。至少用 DBeaver 或终端日志独立验证一遍再决定改哪里。工具不是用来增加信任的而是用来验证信任的。我个人在实际操作中的体会是开源工具并不会让你的 coding 变得完全不焦虑它把焦虑从“无法掌控的慌”变成了“一个个具体的问题”而具体的问题永远有具体的解法。9 个工具凑在一起最终形成的不是一套高精尖武器库而是一条让人踏实的流水线。如果你现在正处于被 vibe coding 折磨的状态不妨从 lazygit 和 Ollama 这两个装起它们成本最低见效却最快。