企业官网建设流程全解析

说实话，vibe coding 这个词火起来之后，我一开始是挺爽的。坐在电脑前，一个需求描述甩给 AI，代码哗哗地出，一天能写以前一周的增量。可用了差不多三个月，某天晚上盯着编辑器里刚生成的那一坨接口调用，我突然开始心慌：这段逻辑是哪来的？这个依赖是从哪个包管理器里拖的？如果 AI 的上下文窗口一塌，我是不是就彻底失忆了？

这种焦虑不是矫情。vibe coding 真正的痛点，不是"代码写不写得出来"，而是"代码写出来了，你敢不敢对它负责"。后来我花了大概两周时间，把整个工作流里的工具全部换成了开源方案，一共 9 个 App，不是一个一个堆功能，而是每个都精准解决了我在 vibe coding 过程中的一类具体焦虑。

下面逐个说。每个工具我都会讲清楚"为什么选它"以及"实际怎么落地"，不是单纯罗列下载链接。

1. 先搞清楚焦虑的来源，再谈用什么工具治

在开始换工具之前，我先花了一晚上把自己"到底在怕什么"列了一遍。不把焦虑拆解清楚，看到别人推荐什么就装什么，最终只会从一个坑跳进另一个坑。

我的焦虑大概有四类。

第一类是失控感。vibe coding 最大的特点是你不太看每一行代码，但你依然要为最终产物负责。AI 给你的 500 行代码里，可能突然混进来一个废弃 API、一个糊涂的业务判断，或者一个你自己都看不懂的抽象层。这种"代码不是自己写的但报错要找自己"的感觉，时间久了很消磨人。

第二类是黑箱感。闭源工具和云端服务最大的问题是：你永远不知道它在背后做了什么。模型返回的代码是从哪些仓库学的？它在后台收集了什么信息？你的代码片段是不是被拿去当训练数据了？这些问题一旦开始想，就很难停下来。

第三类是失忆感。AI 对话窗口有上限，项目稍微大一点，前面聊过的架构决策就被"忘了"。很多人用 vibe coding 最大的崩溃瞬间，就是改一个需求，AI 把另外三个已经稳定的模块都破坏了，而且你还说不出为什么被破坏。

第四类是孤立感。写代码本来是一项工程活动，但 vibe coding 把重点全放在了"对话-生成-复制粘贴"上，导致你离数据库、离接口、离版本库都越来越远。一旦 AI 生成的代码要联调，你就得重新面对那些工具，结果发现自己连表结构都记不清了。

这四类焦虑，正好对应我后面要讲的 9 个工具。你可以对照自己的情况看缺哪块，不必全套照抄，但相信我，这套组合的覆盖面和可维护性，比我之前用的混合方案强得多。

2. 底座双雄：WezTerm 和 VSCodium，先把工作台铺稳

先说一个很多人忽略的事实：vibe coding 一天里真正花在"编辑代码"上的时间，其实远没有花在"让 AI 生成的东西跑起来"上的时间多。装依赖、起服务、看报错、改配置，全都是终端活。而且 AI 生成的代码对运行环境非常敏感，终端不行，体验就直接崩盘。

2.1 WezTerm：GPU 加速的终端，跑 AI 命令不卡

我换 WezTerm 之前用的是系统自带终端和 iTerm2 混着来。说不上难用，但有两个点很烦：一是启动慢，二是分屏能力弱。vibe coding 的典型工作场景是：左边开一个窗口跑 dev server，右边开一个窗口查日志，再开一个窗口执行数据库迁移脚本。窗口一多，标签页就容易乱得找不到北。

WezTerm 解决这两个问题的方式非常彻底。它底层走 GPU 加速渲染，刷大量日志的时候不会卡到打不出字；分屏用的是内置的SplitPane功能，完全通过快捷键和布局配置完成，不需要装额外的窗口管理器。我最喜欢的是它支持把整个界面布局写成 Lua 配置，开机一启动，三个分屏自动铺好，各自跑各自的命令。

# macOS 上可以直接用 Homebrew 装 brew install --cask wezterm

装完之后，只需要在~/.wezterm.lua里写一个简单的分屏配置：

local wezterm = require 'wezterm' local config = {} config.color_scheme = 'Catppuccin Mocha' config.font_size = 14.0 -- 启动时自动打开三个 Tab config.launch_menu = {} wezterm.on('gui-startup', function(window) local tab, pane, args = window:mux_window():spawn_tab_with_pane({ cwd = '~/work' }) end) return config

当然，这个配置只是抛砖引玉。实际用下来，我最重要的心得是：WezTerm 的 SSH 支持是原生内置的，连远程开发机不需要额外配复杂的转发，直接wezterm ssh user@host就能连，对于 vibe coding 生成的分布式/微服务项目调试来说非常省事。

2.2 VSCodium：去掉遥测的 VS Code

编辑器这块，我挣扎了很久。VS Code 本身确实好用，扩展生态也牛，但它终究是微软家的产品，有一些遥测组件和账号体系，让我心里不踏实。于是我把目光转向 VSCodium——它是 VS Code 的开源补丁版本，把微软的遥测、品牌标识、自动更新全给去了，保留的是同一个编辑器内核和几乎一样的扩展体系。

迁移成本极低。你不需要学习新操作方式，快捷键、布局、settings.json、keybindings.json 全都沿用 VS Code 的惯例。直接在官网或 GitHub Releases 下载对应平台安装包即可：

# macOS brew install --cask vscodium

装完第一件事，是把 VSCodium 里 Open VSX 的扩展源用好。微软的扩展市场 VSCodium 是不能直接用完整版的，但 Open VSX 上收录了绝大部分热门扩展，包括我后面要配合 Ollama 用的 Continue 插件。关键扩展装好之后，VSCodium 的体感和 VS Code 几乎没差，但每次打开它，我都知道这个编辑器里没有隐藏的遥测后台，这种确定感本身就是对焦虑的治愈。

3. 给工作流加一个"本地大脑"：Ollama 加 Logseq

vibe coding 最大的焦虑源，其实是你把"思考"外包给了云端大模型。代码是 AI 写的，检查也是 AI 做的，一旦网络断了、服务商改了策略、或者关键对话记录被清空，整个项目就变成一盘散沙。所以我的第二步，是让本地拥有一个可用的模型和一套可追溯的笔记系统。

3.1 Ollama：本地模型，解除对云端服务的依赖

Ollama 是本地跑开源模型最省心的方案。它把模型权重、推理服务、命令行工具全打包好了，一条命令就能把一个大模型跑起来。

# macOS / Linux curl -fsSL https://ollama.com/install.sh | sh # 拉取一个适合代码补全/生成的模型，比如 qwen2.5-coder ollama pull qwen2.5-coder:7b # 启动服务，默认端口 11434 ollama serve

我在实际 vibe coding 流程里，让 Ollama 承担三件事。

第一件事是本地补全。把 Continue 扩展接到本地 Ollama 上，AI 补全就完全不出网了。虽然响应速度比云端大模型慢一点，但胜在稳定，没有 token 计费压力，断网也能继续干活。

第二件事是代码解释。AI 生成了一段我不理解的逻辑时，我直接选中代码，右键让 Continue 用本地模型解释。这个场景不需要最强模型，7B 参数已经足够，而且本地推理不存在隐私问题，可以把完整的项目代码片段贴进去。

第三件事是生成 commit message。我写了一个小脚本，把git diff的输出管道给 Ollama，让它总结提交信息。Vibe coding 的提交量很大，每次都手写 commit message 确实想死，而本地模型做这种格式化输出绰绰有余。

git diff | ollama run qwen2.5-coder:7b "根据以下 diff 生成一个简洁的 commit message"

这段命令我现在几乎每天用。别小看这个习惯，当你提交历史清晰了，回滚、排查问题、向别人解释项目变更，都会轻松很多——这本身就是对"失控感"最直接的缓解。

3.2 Logseq：给"AI 失忆症"建一座本地档案库

我观察到一个规律：大部分 vibe coding 翻车，不是 AI 能力不行，而是"AI 忘得太快"或者"你自己忘得太快"。今天让 AI 生成了某个接口的调用逻辑，下周再改需求时它完全不记得了；你自己也记不住当时为什么做了某个取舍。唯一能对抗这种失忆的，是建立一个可检索的本地档案。

Logseq 是我用下来最合适的工具。它底层就是纯 Markdown 文件，存放在你指定的本地目录，自带双向链接、标签、查询功能，不需要注册账号，不需要云端同步，文件随便复制迁移。

我的用法是建一个专门的 "vibe-notes" 目录，里面按日期命名文件（Logseq 的 journal 模式就是按日期组织的），每天做三件事：

• 把当天跟 AI 对话的关键结论粘贴进去，标注"为什么这么做"。
• 把生成的重要代码片段存成代码块，标注对应的项目路径。
• 把踩过的坑、AI 犯过的错误，用bug和pitfall两个标签统一管理。

等到项目进行到一半，你回头看这些笔记，会发现它们比 AI 的上下文窗口可靠一万倍。而且因为 Logseq 支持全文检索，当 API 突然报错或者需求变化时，我只需要在笔记里搜索"订单状态"或"超时时间"，就能知道当初 AI 是用了什么逻辑实现，然后快速定位修改点。

4. 数据与接口都可视化：DBeaver 和 Bruno

vibe coding 很容易让人产生一个错觉：只要对话写得足够清楚，AI 生成的代码就能完美衔接数据库和外部接口。但现实是，AI 生成的 SQL 十次有八次会把表名字段名搞错，生成的接口调用也经常缺参数。问题是它报错的时机往往很晚——你根本不知道它生成的代码为什么连不上库，为什么请求超时。

4.1 DBeaver Community：数据库可视化，不再盲猜表结构

DBeaver Community 是一个纯开源的数据库客户端，支持 MySQL、PostgreSQL、SQLite、Oracle、SQL Server 几乎你能想到的所有主流数据库。它能让"看数据库"和"写 SQL"变成一件像用 Excel 一样直观的事情。

最实用的功能是 ER 图。AI 生成的一堆建表语句，你不用挨个读字段定义，直接在 DBeaver 里把它连上数据库，点一下生成实体关系图，表之间的关系一目了然。这在做联表查询的时候尤其救命——AI 经常以为两张表能JOIN，实际上外键根本不存在，你在 DBeaver 里看一眼就能确认。

# macOS 安装 brew install --cask dbeaver-community

连接数据库后，我一般先跑一个"任务清单"式的审查流程：

1. 查看表结构，核对 AI 用的字段名是否存在。
2. 手动执行 AI 生成的关键 SQL，看有没有语法或逻辑错误。
3. 用 DBeaver 的数据导出功能，把少量真实数据导出成 CSV，喂给 AI 做后续生成参考。

这套流程下来，AI 生成的 SQL 出错率直线下降。尤其是步骤 3，如果你能先把表里的真实数据样例发给 AI，它生成的查询条件往往会准确得多，因为 AI 终于能"看见"数据长什么样了，而不是纯靠猜。

4.2 Bruno：Git 友好的 API 调试器

Postman 很强大，但它是闭源商业软件，而且近几年的新版本强制要求登录、云同步，让我越来越不舒服。Bruno 是我换掉的替代品，核心优势一句话就能说清楚：它把每一个 API 请求都保存成一个纯文本文件，可以提交到 Git 仓库，也可以随便用文本编辑器打开和修改。

这对 vibe coding 的意义非常大。因为 AI 生成接口代码之后，你需要一个工具来测试，而测试用例本身也应该是可以版本化的项目资产。Bruno 里保存的 collection 是目录 + 文件结构，任何项目成员 clone 下来就能直接用，不需要导入导出、不需要云端账号。

基本用法很简单：新建一个 collection，添加请求，设置环境变量（baseUrl、token这些），点发送就行。最有用的功能是它支持脚本做断言，你可以在请求后执行一段 JS 代码，自动检查状态码、响应字段。这样 AI 每次改接口，我只需要重新跑一遍测试集，通过就是通过，失败会明确指出是哪个断言挂了，不用再肉眼看一遍响应体。

Bruno 本身是离线优先的，不联网也能完整工作，数据全部保存在本地~/.bruno目录里。对于重视隐私或经常在隔离环境工作的人来说，这比云同步的调试工具安心得多。

5. 版本库自己管：Gitea 治"代码说没就没"的焦虑

vibe coding 时代，代码仓库的地位比传统开发更高，因为 AI 每一次迭代都可能对项目做大规模改动，没有版本控制，你就是在悬崖边跳舞。但我不太想把每个私人项目都推到 GitHub 上——哪怕私有仓库，心里也总悬着一根弦，代码是自己的，凭什么让第三方平台当唯一存档。

5.1 部署 Gitea，三分钟拥有自己的 Git 服务

Gitea 是一个极轻量的自托管 Git 服务，用 Go 写的，资源占用极小，一台 1 核 512M 的小服务器就能跑得非常顺畅。它提供和 GitHub 类似的 Web 界面、Issue、Pull Request、Webhook 功能，但数据完全掌握在自己手里。

最省心的部署方式是用 Docker：

services: gitea: image: gitea/gitea:latest container_name: gitea environment: - USER_UID=1000 - USER_GID=1000 restart: always volumes: - ./gitea:/data - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro ports: - "3000:3000" - "2222:22"

docker compose up -d

启动之后，在浏览器里打开http://你的服务器IP:3000完成初始化，填一下仓库根路径、数据库类型，一分钟就能建好第一个仓库。之后本地git remote add origin http://你的服务器IP:3000/用户名/项目名.git就能正常推送拉取。

我自己的使用习惯是：GitHub 只放最终要公开分享的项目，所有进行中的、内部的、实验性的项目全部推到 Gitea。这样心理负担小很多，因为 Gitea 的备份方案完全由我自己控制——每周把整个 data 目录打包备份到另一块硬盘，一旦出问题随时恢复。

5.2 AI 协作的分支策略

光有 Gitea 还不够，vibe coding 需要有和传统开发不同的分支策略。我踩过一个大坑：直接在main分支上让 AI 改代码，结果一次改动把三个文件毁得面目全非，想回滚都分不清哪段是好代码、哪段是 AI 犯病。

现在我的策略很简单，就三条：

1. 每次新需求或新功能，从main拉一个feature/xxx分支。
2. AI 生成的所有改动先提交到feature/xxx分支，提交信息必须写清楚"这次改了什么"，方便后续看 diff。
3. 在分支上做完验证（跑通测试、接好接口、数据库确认无误）之后，再合回main。

这个策略听起来循规蹈矩，但配合 vibe coding 的高频迭代节奏，它保证了一件事：AI 犯的任何错误都被隔离在分支里，不会污染主分支。哪怕它把某个分支改得完全不能用了，删掉重建一个分支的成本也很低，但主分支永远保持可用状态——这种"地基稳定"的感觉，是最有效的定心丸。

6. 把真实信息喂给 AI：ShareX 与 MinerU 的上下文增强流水线

vibe coding 的输入质量，直接决定输出质量。很多人的 prompt 写得也不差，但 AI 总是答非所问，核心原因是你喂给它的信息太模糊了。比如 AI 生成的前端样式错位，你光说"样式有问题"它根本定位不了；但如果你截一张图给它，再附上相关代码片段，它的准确率可能直接翻倍。

所以我的第 6 组工具，专门解决"如何高效地把真实世界信息转成 AI 能理解的结构化文本"。

6.1 ShareX：截图、GIF、录屏三合一

ShareX 是一个功能极其强大的开源截图工具，但它不只是截图。它包含屏幕录制、滚动截图、OCR 文字识别、区域拾色器、图像标注、自定义上传脚本等一整套功能，基本覆盖了日常和 AI 协作时所有需要抓取信息的场景。

官方提供绿色版，下载解压就能用，也可以走安装包：

# Windows 用 winget winget install ShareX.ShareX

我更想强调的是它的 workflow 集成能力。以前我遇到 bug，要手动截图、存文件、再拖进 AI 对话框，非常麻烦。ShareX 支持截图后自动执行一系列动作——截图 → 自动保存到指定目录 → 复制到剪贴板 → 跑一个 OCR 识别文字 → 最后把一个带文字的截图信息粘贴到剪贴板里。三秒内我就能把一张截图连同识别出的错误代码喂给 AI。

如果你愿意折腾一点，可以让 ShareX 截图后自动调用一个脚本，把图片转成 Base64、把 OCR 结果存成临时 Markdown 文件，然后一句 prompt 就把这些内容全部发送给本地 Ollama 模型，让它帮忙分析。这种"现场信息 → 结构化文本 → AI 分析"的流水线，才是 vibe coding 的高阶玩法。

6.2 MinerU：PDF 变 Markdown，AI 阅读效率翻倍

我用 vibe coding 时还有一个高频需求：把官方文档、论文、技术 PDF 里的内容直接扔给 AI 作为参考。但 PDF 本身的结构化程度很低，直接粘进去，AI 读到的是乱序文本、公式错乱、表格全丢，效果很差。MinerU 就是解决这个问题的开源项目，它能把 PDF、图片里的复杂版式解析成干净的 Markdown 格式，保留标题层级、表格、公式，甚至支持扫描件的 OCR。

# 安装 pip install mineru # 命令行解析 PDF，输出 markdown mineru -p input.pdf -o output/

跑完之后，MinerU 会生成一个.md文件和相关图片资源，你再把这份 Markdown 粘贴给 AI。一个 30 页的技术文档，AI 一下子就能理解全貌，后续生成代码时对 API 的把握也会准得多。

我在处理官方 SDK 文档时特别受益。直接把 SDK 的 PDF 文档转成 Markdown，然后让 AI 基于这份文档生成代码，生成的代码质量明显上了一个台阶，因为它终于不用再凭记忆编造 API 了。

7. 跑了一周之后，焦虑少了大半，但也暴露了开源工具的真相

把上面 9 个工具全部接入工作流，我完整跑了一周。先说结论：vibe coding 的焦虑确实被有效缓解了，但方式和我预想的略有不同——不是某一个工具有多神奇，而是整套组合让我重新找回了"确定性"。

最直观的变化，是我不再怕项目变大。以前一听到"新需求"就头疼，因为知道 AI 又会把代码搅得天翻地覆。现在，需求来了先在 Logseq 里记录上下文，然后拉一个 feature 分支，让 AI 在 Gitea 的防护网里折腾，接口有问题就用 Bruno 跑测试定位，数据库疑惑就用 DBeaver 直接查。每一步都知道自己手里有什么、下一步该做什么，这种掌控感是任何云计算服务都给不了的。

第二变化是离线能力。因为 Ollama 在本地，补全、解释、生成 commit message 这些高频操作完全不出网；Bruno 和 DBeaver 的数据都在本地；Logseq 是本地 Markdown；Gitea 的仓库也在自己的服务器上。有一次我断网忙了整个下午，写完一个新模块，代码、测试、文档全齐，完全没有以前那种"断网等于停工"的恐慌。

当然，开源工具也不是没有代价。最典型的问题有三个，提前给你提个醒。

第一个坑是"配置时间超乎想象"。WezTerm 的 Lua 配置、Ollama 的模型调优、MinerU 的依赖处理，都要花不少时间去折腾。它不是装完就能完美运行的商业软件，而是需要你花一小时换来后面长期的舒适。我的建议是别追求一步到位，先把最核心的流程跑通，后面再逐步加功能。

第二个坑是"扩展生态不完全是原汁原味"。VSCodium 用 Open VSX 扩展源，有一部分 VS Code 商店里的扩展不存在或更新滞后，偶尔会遇到"网上教程说装 A 插件，但 VSCodium 里搜不到"的情况。这时候多用关键词变体搜索，或者干脆找替代插件，通常都能解决。

第三个坑是"自托管要自己负责备份"。Gitea 确实好，但如果你的服务器挂了，数据没备份，那比 GitHub 崩了还惨，因为没人帮你恢复。我用一个很土的办法：每周写个 cron 脚本把 Gitea 的 data 目录 rsync 到本地磁盘，再备份一份到移动硬盘。土但可靠。

接下来我还想继续折腾两个方向。一个是给 Ollama 加一个本地 RAG 服务，把 Logseq 里的 Markdown 笔记都变成可向量化检索的知识库，这样 AI 在回答问题时能直接引用我本地积累的所有项目和踩坑记录。另一个是把 ShareX 的截图流水线和 MinerU 的解析结合起来，做一个"截图即喂给 AI"的完整工具链，尽量减少复制粘贴的中间步骤。

至少到目前为止，这 9 个开源工具帮我建立的不是一条"无痛开发"的捷径，而是一条"不管 AI 怎么飞，线始终在我手里"的安全绳。挺值的。