最近小半年我写代码的方式彻底变了。需求丢给 AI它给我吐出一整段能跑的逻辑我修修补补就上了线。这种干法就是大家现在说的 vibe coding。一开始我是真的爽任务完成速度快到有点作弊的感觉。但爽了两周之后我开始睡不踏实模型到底跑在谁家服务器上我的代码片段是不是被拿去当训练数据了AI 为了凑出功能给我塞进来的那个依赖包到底是谁在维护万一它哪天爆出漏洞我可能连它在我项目里哪个位置都说不清。这种焦虑的本质不是AI 写代码不可靠而是我的工具链变成了一个巨大的黑盒。闭源补全插件、云端 IDE、自动生成的依赖、AI 自己加的注释……一切都很顺滑但我对项目的掌控感消失了。后来我做了个决定把能替换的环节全部换成开源工具凡是能落在自己手里的数据绝不放去别人的服务器。前后折腾了一个多月换成 9 个开源 App 之后vibe coding 才真正从赌博变成了可预期。这篇就是把我的焦虑复盘、选型逻辑、实操步骤和踩过的坑整理出来。这里的 App 我按广义理解桌面工具、命令行工具、IDE 插件、自托管服务都算反正都是日常开发里能直接用上的开源项目。1. 先说清楚我到底在焦虑什么1.1 vibe coding 的失控感来自四个具体场景第一个场景是代码片段上传。我在编辑器里每敲一个字符补全插件几乎都会把当前文件和上下文发给云端。我写的是公司内部项目很多代码本身就出不了内网但工具是闭源的我根本没得选。第二个场景是依赖失控。AI 帮我写了个下载图片的功能它自己 import 了一个我从没听过的库还顺手帮我装了。这个库有没有人维护、有没有漏洞、License 是什么当时我完全不知道。第三个场景是环境不一致。AI 项目在它训练过的环境里跑得很顺可我换台电脑就各种缺依赖报错信息像天书。第四个场景是没有项目记忆。我当时的习惯是边聊边写问答记录全散落在 AI 工具的会话列表里两周后再看当时的代码连为什么这么设计都想不起来。这些场景有个共同点环节越多、越自动风险越不可见。等出了问题你连排查的起点都找不到。1.2 为什么换开源能对症开源解决的不只是免费问题而是把不可见变成可见。第一代码透明一个补全服务是否会把数据外传你可以直接读它的源码或者干脆自己部署一份第二链路可控本地模型、本地补全、本地知识库整条链路都在自己手里第三生态持久一个开源项目就算原开发者弃坑代码还在社区可以继续 fork项目不会因为某家公司关停就彻底蒸发。对于 vibe coding 这种本身就很依赖工具链的工作方式工具链越透明你的安全感越足。1.3 九个开源工具的一页总览我先把我最终保留的工具列成一张表后面逐个展开安装过程和避坑经验。焦虑来源开源工具它解决什么运行形态AI 模型在别人服务器上Ollama本地跑开源大模型数据不出门本地服务补全插件上传代码Tabby自托管代码补全服务自托管服务被某个 AI IDE 锁死Continue开放协议连接模型与 IDEIDE 插件AI 代码有隐藏漏洞Semgrep本地静态安全扫描CLI / 插件依赖版本失控Renovate自动化依赖更新与检查机器人 / 自托管项目环境复现不了DevPod一键创建可移植开发容器CLI / 桌面端项目没有记忆Logseq本地 Markdown 知识库桌面 / 移动 App文档散成一堆 MDDocusaurus把 Markdown 生成文档站静态站点生成器信息输入过载Legado开源阅读器统一信息输入Android App这个组合是我实际用下来的结果不是拍脑袋凑数。下面逐个拆。2. 把会思考的那部分留在自己手上本地模型与自托管补全2.1 Ollama一行命令养一个本地模型服务先说我为什么第一个换它。vibe coding 最核心的是模型模型跑在哪、数据去了哪决定了整条链路的信任基准。我需要的不是最强模型而是能在自己机器上跑、行为可预期、API 兼容 OpenAI 的模型服务。Ollama 满足这个需求而且简单到不像个本地模型平台。安装分平台macOS 直接brew install ollamaLinux 用官方安装脚本curl -fsSL https://ollama.com/install.sh | sh装完拉一个适合代码生成的模型ollama pull qwen2.5-coder:14b ollama run qwen2.5-coder:14b第一次会下载几个 GB 的权重文件耐心等。之后 Ollama 会在本地localhost:11434起一个服务同时提供原生 API 和 OpenAI 兼容端点任何支持自定义 base URL 的客户端都能直接接进去。选模型这块我有一些实测经验。14B 是我能接受的最小区间但至少要 16G 内存8G 显存只能勉强跑量化版本。日常闲聊用 7B 或 8B 就够但要正经做代码生成14B 起步比较稳。32B 需要 24G 以上显存或内存不然慢到没法用。如果机器实在跑不动也不要硬扛可以优先选那些你能确认数据用途的开源模型而不是把敏感代码交给完全黑盒的云端接口。踩坑提醒笔记本内存低于 16G 时别硬上 14B 默认量化版一个模型动辄占十几 G 内存再同时开着 IDE 和浏览器机器基本卡死。我后来给 Ollama 设置了OLLAMA_MODELS环境变量把权重文件挪到外置 SSD系统盘一下就轻松了。如果想让局域网里其它设备也访问可以设OLLAMA_HOST0.0.0.0:11434但注意局域网内任何人都能调用开发环境最好加一层访问限制或者干脆只在本机用。2.2 Tabby把补全服务也搬回家Ollama 解决的是对话和续写但编辑器里的实时补全我原来用的是闭源插件。闭源插件的隐患不是它一定干了坏事而是你没法验证它到底有没有把代码传出去。Tabby 是我的替代方案开源、自托管可以在自己机器上跑一个补全服务也可以把本地模型当后端。我当时的部署命令大致长这样但因为 Tabby 官方 model zoo 会持续更新模型 ID建议以官方文档为准docker run -it --gpus all -p 8080:8080 \ -v $HOME/.tabby:/data \ tabbyml/tabby serve --model StarCoder2-3B没有 N 卡就把--gpus all去掉用 CPU 跑 3B 模型也能出效果只是响应会慢一些。服务起来之后在 VS Code 装 Tabby 插件填上http://localhost:8080和一个访问 token补全就通了。我的体会是补全模型不是越大越好3B 到 7B 的补全速度比聪明重要。补全建议是实时弹出来的延迟超过半秒我就基本不看它了。Tabby 跑在我自己的机器上代码不出内网这让我很踏实。部署完我做的第一件事就是卸载旧插件按一下 Tab 键再也不用猜代码去了哪。注意一个坑Tabby 新版本对访问认证更严格要求明确指定 token不配置的话服务默认不开启认证部署在局域网或公网容易被别人蹭算力。如果放在云主机上认证必须作为第一步配置别跳过去。2.3 Continue用一个开放客户端摆脱 IDE 锁死用上 Ollama 和 Tabby 之后我还剩一个不满不同 AI 工具的会话格式、模型接入方式和快捷键全都不通用。今天用 A 工具明天 B 工具出新功能又得切整个工作流慢慢被一家公司的体验绑架。Continue 是开源 IDE 插件把模型接入做成一份配置文件彻底解开了我被锁死的焦虑。Continue 支持 VS Code 和 JetBrains 系。装完插件在项目根目录放一个.continue/config.yamlmodels: - name: Qwen2.5-Coder 14B provider: ollama model: qwen2.5-coder:14b roles: - chat - edit - apply tabAutocompleteModel: - name: Qwen2.5-Coder 7B provider: ollama model: qwen2.5-coder:7b这份配置可以直接提交进 git 仓库团队成员拉下来就是同一套模型和行为配置。它也能配provider: openai然后填 baseUrl 指向 Ollama 的 OpenAI 兼容端点。我的实际感受是Continue 并不比某些商业插件更聪明但它把选择权还给了我。今天想用本地模型就用本地模型明天想切云端 API 就改一行配置工作流不再依赖任何一家公司的良心。有个小坑值得说Continue 的自动补全如果走 Ollama建议把补全模型和聊天模型分开。补全用一个更快的 7B 专门处理 inline suggestion聊天和编辑用 14B延迟压力会分散很多体感上明显更跟手。3. 给 AI 生成的代码做安检扫描、依赖与环境复现3.1 SemgrepAI 代码里的安全雷扫出来再说AI 生成的代码最大的问题不是编译不过而是看起来太像正常代码。它可能把eval用于动态执行用户输入可能把路径拼接成目录穿越也可能把密钥硬编码进常量。这些问题我人工 review 漏过至少两次最后都是 Semgrep 扫出来的。Semgrep 是开源静态分析工具底层能解析真实语法结构不是朴素字符串匹配。安装很简单brew install semgrep对项目做一次常规扫描semgrep scan --config auto它会按热度下载规则并在本地执行。如果不想每次联网拉规则可以先用semgrep scan --config p/security-audit跑本地规则集合。我习惯在 CI 里加这一步semgrep scan --config auto --sarif semgrep.sarif配合 GitHub Code scanning可以在 PR 页面直接看到扫描结果不用专门打开一个页面去查。自定义规则才是它真正厉害的地方。比如我想禁止所有eval和类似动态执行就在项目里放一个.semgrep/rules.yamlrules: - id: no-eval pattern: eval($ARG) message: Do not use eval on dynamic input languages: - python severity: WARNING看着报错列表的时候你能明显感觉到 Semgrep 在干一件人应该干但容易漏掉的事。我的使用顺序是先用默认规则扫一遍底再针对 AI 生成最多的模块写一两条自定义规则比如禁止未经验证的subprocess调用、禁止把 token 打到日志里。别一上来就写几百条规则那样会被误报淹没。还有一点扫描结果不代表一定有问题但每一条都值得点开确认。确实误报的规则写进.semgrepignore或规则例外里而不是假装看不见。否则过两周你看到几十条告警干脆不看了工具就失去意义。3.2 Renovate治住依赖版本失控AI 生成代码时为了让功能跑起来经常会把一堆依赖直接塞进项目。我见过它自动把版本写成通配符*的也见过它把 Python 依赖写进requirements.txt却完全没验证兼容性的。短期能跑长期就是定时炸弹。Renovate 解决的是让依赖始终处于可控状态这件事。Renovate 是开源机器人持续监测依赖清单发现新版本或安全更新就自动开 PR。GitHub 上可以直接按 GitHub App 方式安装到仓库也可以自托管。自托管的方式通常是配一个定时任务跑容器docker run --rm \ -e RENOVATE_TOKENyour_github_token \ -e LOG_LEVELdebug \ renovate/renovate仓库根目录放一个renovate.json{ $schema: https://docs.renovatebot.com/renovate-schema.json, extends: [config:recommended], automerge: true, automergeType: pr, major: { automerge: false } }上面的配置会让小版本自动合并大版本单独开 PR 等人 review。这样一来AI 随手写的依赖就变成一条条可追踪的更新记录版本来源、发布时间、兼容性变化都在 PR 里摆着。我的教训是Renovate 刚接入时会把项目里囤了半年没更新的依赖一股脑全部提 PR噪音巨大。开局可以把separateMajorMinor打开并给每个 PR 打上标签先在 staging 分支跑两周再上 default 分支。别一上来就 automerge 所有东西尤其是 AI 项目里那些来源不明的包先人工过一遍材料再说。3.3 DevPod把我这儿能跑变成可复现事实vibe coding 最崩溃的场景是什么我这边跑得好好的一换机器就编译失败、环境变量没有、系统库版本不对。以前我会写一篇三页长的环境配置文档然后发现根本没人照着做。后来我用 DevPod 把环境问题彻底容器化。DevPod 是开源开发环境管理工具把 devcontainer 规范从 VS Code 里独立出来。安装后进入项目brew install devpod devpod up . --provider docker --ide vscode它会在隔离容器里构建开发环境本机只保留一个轻量入口。我在项目里放了一个devcontainer.json{ name: vibe-project, image: mcr.microsoft.com/devcontainers/python:3.12, postCreateCommand: pip install -e .[dev] pre-commit install, customizations: { vscode: { extensions: [continue.continue, semgrep.semgrep] } } }别人拿到项目后不用手工配环境一条devpod up就能进入可复现的开发环境。DevPod 支持的 provider 也很多Docker、Podman、SSH 远程机都可以。实际用下来我最大的感受不是部署方便而是环境可复现之后AI 生成代码里那些怪异依赖会立刻暴露在干净容器里因为 devcontainer 每次都是从零构建的。如果你在用云端 IDE 或远程开发DevPod 也能把 workspace 状态打包带走不再被某一家云厂商的账号体系绑死。一个提醒devcontainer 镜像体积很容易膨胀。image尽量选官方基础镜像把 AI 项目里那些杂七杂八的 apt 包收敛进构建脚本并注明来源。如果你想验证AI 项目在干净机器上到底能不能跑DevPod 是我见过最快的复现工具。4. 给 vibe 项目补齐记忆与信息源4.1 Logseq把 AI 对话沉淀成可检索的本地知识库复盘时我发现vibe coding 项目让我心虚很大程度是过程没有沉淀。AI 帮我改了三轮逻辑每一轮为什么改、改完引入了什么假设全遗留在聊天窗口里项目代码只保留最终结果。一旦出现诡异 bug我没法追溯是哪一轮被带进来的。Logseq 帮我把这个断点接上了。Logseq 是开源、本地优先的 Markdown 大纲笔记工具数据就是本地文件夹里的一堆 MD 文件。我的用法是每个项目建一个页面每天在 Journal 里按固定模板记## 任务 - 需求xxx - 使用模型qwen2.5-coder:14b - 提示词摘要xxx ## 结果 - 改动文件a.py, b.py - 测试结果通过/失败 ## 问题 - 其中 xxx 逻辑依赖了旧接口 ## 下一步 - 等 Semgrep 扫描结果这个模板让我在两周后仍然能看懂当时的决策链路。因为所有笔记都是本地 Markdown我还可以直接把整个目录放进 git 仓库跟代码一起版本化。隐私方面也放心不联网照样能用。相比之下把项目决策记录存在别人服务器上这件事本身就会变成新的焦虑源。我踩过的坑是一开始太想整理得漂亮结果维护成本太高坚持不了三天。后来放弃完美主义只保留能搜索这一个标准。Logseq 全文搜索很快内容乱一点没关系只要记了事后总能找到。4.2 Docusaurus把散装 Markdown 变成真正的项目文档Logseq 管过程Docusaurus 管结果。vibe coding 项目迭代太快README 根本赶不上代码变化更别提把 AI 生成的模块边界讲清楚。为了让协作者不在散装 MD 里迷路我把所有项目文档统一迁到 Docusaurus。Docusaurus 是开源文档站点生成器把一个目录下的 Markdown 变成结构化静态网站支持搜索、版本化、MDX 组件。初始化很快npx create-docusauruslatest docs-site classic把 Logseq 导出的 Markdown或者直接复制放到docs/目录再在sidebars.js里配置目录结构就行。我给每个 AI 生成模块建了一页AI 产物地图写清楚这个模块由哪个模型、哪个会话生成审查状态人工 review 过 / 静态扫描过 / 未处理涉及的关键依赖及用途。这些 Docusaurus 页面和代码在同一个仓库里CI 构建后自动发布到内部站点。项目里再也没人需要问这个模块当初怎么写的答案就在文档站里。我的建议是别一上来就把 Docusaurus 用得太重不需要配一堆插件。先把docs目录跑起来让文档和代码同步合入一个 PR养成改完代码顺手更新文档的习惯这比任何文档规范都有效。4.3 Legado信息输入端的开源清噪方案最后这个 App算是我给信息输入减负的补充。vibe coding 焦虑里很大一块来自信息过载GitHub 上每天冒出新项目、技术公众号天天推送、AI 工具周周更新我一度生怕错过什么结果碎片信息越攒越多真正读完的技术文档没几篇。Legado开源阅读是 Android 上的开源阅读器数据规则由用户自行配置支持导入书源和订阅源也能导入本地电子书和 HTML 文档。我把它当技术资料统一入口用把源码分析、设计数据、经典技术书 EPUB 都丢进去通勤时集中读。读的时候随手把要点记到 Logseq形成输入到沉淀再到输出的小循环。这里必须提醒书源和订阅源本质是第三方规则导入之前一定确认来源合规、内容合法别为了省事导入不明来路的源。开源工具本身是干净的但规则由谁维护、内容指向哪里使用者要对自己负责。我一般只拿它读自己已经下载的电子书和文档或者官方提供的 RSS 类订阅这样既安全又省心。选择 Legado 作为第 9 个工具还有一层原因它证明了开源生态里长出来的东西可以比商业 App 更懂用户。自定义规则、纯净无广告、数据完全本地这种掌控感和 vibe coding 焦虑的对立面是同一种气质。5. 替换清单、避坑与我的真实体会5.1 一页纸的选型与落地顺序如果让我重来一遍我不会一次换 9 个。一次性引入太多工具本身就是新的焦虑源。我建议按这个顺序推进先跑 Ollama Continue。用本地模型替代闭源 API立刻解决数据去哪了的底层焦虑改动最小收益最大。再加上 Semgrep。用扫描兜底让 AI 生成的代码在你心里过了安检。然后是 Renovate 和 DevPod。依赖和环境可控之后vibe coding 项目才敢拿去团队协作。最后补文档线Logseq 记过程Docusaurus 出文档Legado 管输入。每个阶段至少跑两周确认没有引入新的问题再进下一步。我见过有人一天之内换全套结果第二天就在新工具的组合拳里迷路了反而更焦虑。5.2 三个我最想提醒的坑第一本地模型不是万能的。14B 的本地模型和最新云端模型比生成质量确实有差距。我的策略是简单重复的活交给本地模型复杂架构设计仍然可以先在云端大模型上讨论只是不把敏感代码或数据喂进去。别因为隐私焦虑过度牺牲效率关键是要分场景。第二扫描和依赖工具需要维护成本。Semgrep 规则、Renovate 的 PR 如果你不看它们就是新的噪音源。我每周抽固定时间处理这些机器提醒五分钟清空 inbox让工具替我盯着而不是让工具每天轰炸我。第三自托管的身份认证要当回事。Tabby、Renovate、Ollama 只要暴露到局域网或公网就必须带上 token 或网关保护。我见过有人把没设密码的补全服务跑在云主机上三天后日志里全是别人的请求。开源工具的安全边界最终靠使用者自己守住。5.3 治好的不是代码焦虑而是失控感换工具这件事听起来是更换技术栈做完之后才发现真正被治愈的是那种代码不是我写出来的所以我不敢改的失控感。现在我这里的每个环节都有日志可查、有环境可复现、有决策可追溯。AI 仍然在写大部分代码我也仍然要 review、要扫描、要补文档但整个流程是开放的我能随时看到链条上的每个节点。我也更愿意把 AI 生成的内容当成协作的初稿而不是外部黑盒的产物。这套开源组合拳未必适合所有人但它实实在在帮我找回了对项目的基本掌控。如果你也在 vibe coding 的过程中隐隐不安不妨先从最让你不安的那个环节开始换。换完之后你会发现焦虑的源头从来不是 AI 太强而是工具链对你太不透明。