企业官网建设流程全解析

vibe coding 玩了半年，我差点被自己的冲动劝退。口号很性感，结果面对一堆 AI 生成代码时，焦虑一点也不性感。代码能跑，但没人能说清它为什么能跑；问 AI 要个重构方案，它热情地改完十几个文件，留下几百行我看不懂的 diff；辛辛苦苦把项目推到服务器上，环境又崩了。后来我换了思路：与其指望 AI 变得更可靠，不如围绕开源 App 搭一条可检视、可回滚、可重复的流水线。于是就有了这篇文章里这 9 个开源项目的组合，它们治好了我的 vibe coding 焦虑。

1. vibe coding 焦虑从哪里来：失控的代码与不确定的产出

先说清楚一件事，我口中的 vibe coding，指的是用自然语言向 AI 描述需求，让它生成代码、补全逻辑、修报错，甚至让它在多个文件里做大规模改动。这种开发方式最大的问题不在于“代码是 AI 写的”，而在于“代码是黑盒状态产生的”。你不需要理解每一行，但你至少得能在出问题时把它推翻重来。我的焦虑基本都来自下面几个地方：

• 代码质量不可控。AI 会为了通过当前报错疯狂打补丁，生成一堆any、// TODO: fix later，甚至复制粘贴一段错误逻辑到三个文件里。你问它“这段逻辑成立吗”，它永远说“看起来没问题”。
• 上下文断裂。AI 只看到当前文件或当前对话，对项目整体结构、历史决策、依赖关系没有感知。你让它加功能，它在 A 文件改了一处，却不告诉你 B 文件里还有个硬编码值没动。
• 运行环境不确定。“在我机器上明明能跑”这句话，从同事嘴里说出来烦，从 AI 嘴里说出来更烦。AI 给你的部署步骤，经常少一个环境变量，或者用了一个已经废弃的依赖版本。
• 过程不可回溯。聊天记录不能当 diff 看，回滚也只能回到整份文件，而不是回到“改了这三行之前”的状态。一次改动出了问题，你根本不知道是 AI 动了哪只手。

这 9 个开源 App 不是要取代 AI，而是给 AI 编程套上一条“工程装订线”。我按照一个 vibe coding 项目从想法到上线的完整路径，把工具分成了四层：模型层、编码层、代码仓与终端层、部署层。下面这张表是我目前的实际选型：

2. 第一层防线：把模型拉回本地（Jan + Cherry Studio）

2.1 Jan：不依赖在线服务的本地对话环境

Jan 是一个开源的桌面端 AI 助手应用，支持 Windows、macOS、Linux，底层可以接本地推理引擎，也可以接 OpenAI 兼容的 API 服务。我对它的定位很简单：让 AI 对话不依赖某个网页窗口。

之前我 vibe coding 时，聊天上下文都散落在浏览器标签页里。项目没做完，标签页一关，整个决策过程就丢了。Jan 把“和模型对话”变成了和本地文件、本地模型一样的常驻应用，所有历史会话存在本地，不绑账号，不绑云端。对我这种有轻度隐私强迫症的人来说，和代码有关的讨论放进本地应用，心理负担小很多。

实际操作上，Jan 的使用门槛很低。安装后进入设置，添加模型时可以从 Hugging Face 拉 GGUF 格式的模型文件，也可以直接连 Ollama 库的模型名。我笔记本是 16GB 内存，日常跑qwen2.5-coder:7b和deepseek-coder-6.7b-instruct的 Q4 量化版，生成速度大概在每秒 20 到 35 个 token，聊思路、解释报错、写小工具足够用了。

2.2 Cherry Studio：把多模型服务收敛到一个窗口

Jan 给我的本地模型一个固定座位，但实际开发中我还会用云端的 API 模型来兜底复杂任务。每个模型一个网页或应用，切来切去实在太烦。Cherry Studio 解决的就是这个问题。

Cherry Studio 是开源的多模型聚合桌面客户端，支持 OpenAI 协议、Anthropic API、Ollama、以及各种兼容端点。我可以在一个窗口里同时开两个对话：左边用本地模型检查代码风格，右边用云端模型做大规模重构。两个对话的上下文互不干扰，但都保存在同一个本地知识体系里。

我最常用的功能是“多助理预设”。比如我建了一个“代码审查员”助理，预设指令是：只输出问题列表，不输出修改代码；再建了一个“Docker 排错师”，让它遇到 Compose 文件报错时，先让我看 volumes 和 ports 配置。这样不用每次重复写提示词，AI 的行为边界相对固定，vibe coding 的随机性就少了一大截。

2.3 本地模型够不够用？聊聊我的量化与显存经验

很多人在本地跑模型之前，最纠结的是硬件。我试过的组合很杂，从 RTX 3060 12GB 到 Apple Silicon 都有。以 7B 到 14B 参数量的代码模型来说，关键在于量化方式和上下文长度。

我用得比较多的是 GGUF 的 Q4_K_M 量化，7B 模型文件大概 4 到 5GB，14B 模型大概 9 到 10GB。16GB 内存的机器跑 7B 比较宽裕，能同时开 Cherry Studio 和 IDE；想要跑 14B 并保持 8K 上下文，建议 24GB 以上内存或独立显卡。我的观点是：本地模型不需要追求“和云端旗舰一样聪明”，只要它能完成代码解释、单元测试生成、配置文件修正这三类工作，就已经能解决很大一部分 vibe coding 的失控感。

当然，本地模型也不是没有坑。有些 GGUF 文件在不同推理后端上表现差异很大，同一份模型在 llama.cpp 和 MLX 里出来的结果可能完全不一样。如果发现模型输出重复话、漏代码，优先看看是不是量化层次太低，或者上下文长度设得太小。

3. 编码辅助的工程化：让 AI 的输出真正进入项目

3.1 Continue：装在 IDE 里的开源副驾

模型层解决了“和谁聊”的问题，但 vibe coding 真正的主战场还是 IDE。Continue 是我用过最顺手的开源编码助手，它作为 VS Code 和 JetBrains 的插件运行，架构上允许你自由选择底层模型，本地 Ollama、OpenAI 兼容 API、甚至公司内部服务都能接。

它的配置写在~/.continue/config.yaml里。下面是我接本地 Ollama 的简化配置：

name: Local Continue version: 0.0.1 schema: v1 models: - name: qwen2.5-coder:7b provider: ollama model: qwen2.5-coder:7b apiBase: http://localhost:11434 roles: - chat - edit - autocomplete

配置好之后，Cmd+I可以选中代码片段做行内修改，Cmd+L打开对话，输入框下面直接带着当前文件的路径和选区内容。和网页聊天最大的区别是，Continue 的上下文始终贴着你的代码，AI 的回复不是孤立的建议，而是可以直接应用或拒绝的 diff。

用 Continue 之后，我给自己定了一条规则：凡是影响超过三个文件的修改，必须先让 AI 输出一份执行计划，我再手动确认每一步。之前让 AI 直接跨文件改代码，它经常改到一半陷入死循环，反而是让它先生成计划更省时间。

3.2 Dify：把“聊天记录”变成可复用 Agent

很多 vibe coding 的问题其实不是代码写不出来，而是同样的需求、同样的规范反复让 AI 理解。Dify 就是来解决这个问题的。

Dify 是开源的 LLM 应用开发平台，你可以通过可视化界面编排 Agent、知识库、工作流，然后把编排结果发布成 API 或 Web App。我把项目规范、编码约定、常用组件文档都扔进 Dify 的知识库里，再创建一个“项目顾问”Agent 绑定这些知识库。之后在任意聊天窗口里问问题，AI 的回答都会先参考我预设的文档，而不再是一张白纸。

我特别推荐会在团队里协作的人试试这个思路：把 Dify 发布的 API 地址接到 Cherry Studio 或 Continue 里，整个团队用同一套提示词和知识库，避免出现“你问 AI 得到的答案和我问 AI 得到的答案完全不一样”的割裂感。知识库的分段大小我一般设为 512 到 1024 个 token，太短检索不全，太长则命中不准。

3.3 Langflow：可视化工作流处理“复杂业务”

如果说 Dify 偏向“应用和知识库”，Langflow 就更偏向“流程编排”。它是一个可视化工具，把提示词、模型、工具函数、条件判断这些节点用连线串起来。初看有点复杂，但处理需要多步推理的 vibe coding 任务时特别好用。

举个例子。我经常需要一个“需求拆解员”流程：把一段产品需求文本输入进去，经过关键词提取、技术栈判断、任务切分三个节点，最后输出一份可供 AI 逐条执行的任务清单。以前我在聊天窗口里反复让 AI 做这件事，每次格式都不一样。在 Langflow 里拉好节点之后，每次输入都是同一个出口，输出结构稳定，后面接 Continue 或 Dify API 也方便。

要提醒的是，Langflow 不适合一上来就搭特别复杂的图。节点太多、数据流太绕，排查问题比手写代码还累。我目前只用它处理一两个固定场景，更多时候还是走 Dify 的知识库 + Agent。

4. 上下文、终端与代码仓：把整个开发过程放进闭环

4.1 Tabby：换个趁手的终端，给 AI 对话和环境一个“固定座位”

vibe coding 不只是写代码，还有跑命令、查日志、看 Git 状态。默认终端一旦窗口一多就乱成一锅粥。Tabby 是我长期在用的开源终端模拟器，跨平台，支持 Windows、macOS、Linux，界面现代，配置文件是可读的 JSON 或 YAML，窗口分割、标签页分组、全局快捷键这些该有的都有。

对我这种 AI 重度使用者，Tabby 最大的价值是“把 AI 生成的命令放在一个可控环境里跑”。AI 给我一串docker compose命令、一个迁移脚本，我不会直接复制进系统默认终端，而是先在 Tabby 里开一个指定项目目录的标签页，检查命令内容，再执行。窗口标题会显示当前路径和运行状态，一眼就知道自己在哪个项目上下文里，不会在多个目录间迷路。

Tabby 还支持插件。我装了简单的主题和字体插件，没有装太多花哨的东西。终端这种工具，稳定和顺手比功能多更重要。

4.2 Termux：在手机上运行完整工具链

vibe coding 最容易被低估的场景是移动端。偶尔在地铁上突然想到一个改动点，或者线上服务告警需要看日志时，我不想打开笔记本电脑。Termux 解决了我这个需求。

Termux 是 Android 上的开源终端模拟器，不需要 root，通过 F-Droid 安装后就能获得一个完整的 Linux 环境。我在里面装了python、nodejs、git、openssh，还有gh工具链。用 Termux 可以做三件很实际的事情：查看 Gitea 仓库的最新提交、远程 SSH 到服务器执行部署命令、甚至跑一些简单的 Python 脚本验证思路。

要注意，Termux 一定要从 F-Droid 或者 GitHub Release 安装，Google Play 上的版本已经停止维护很久了。另外，在手机上写代码不是主流操作，我更推荐把 Termux 当“移动运维终端”而不是“移动 IDE”。

4.3 Gitea：构建自己的代码仓库，不怕 AI 写的代码无人托管

AI 生成了大量代码之后，最难受的是没有一个结构化的地方看版控历史。我用 Gitea 自建了一个内部代码仓库，它非常轻量，内存占用小，一台低配服务器就能跑起来，但 Git 的能力和 GitHub 没有本质差别。

Gitea 最大的价值在于让我对 AI 产生的代码保持“可审查、可回滚”。我的基本工作流是这样的：每次让 AI 改动功能前，先在本地创建一个新分支，名字叫ai/xxx-feature，接着让 Continue 或 Cherry Studio 里的大模型完成修改，本地跑通测试后，推到 Gitea 上的对应分支，再通过 Merge Request 合并到主分支。

为什么要专门走这一步？因为 AI 写的代码不能直接进主干。它在分支上可以被随意推翻、反复修改、甚至整个丢弃，而主分支始终是稳定版本。Gitea 同时支持轻量的 Gitea Actions 和 Webhook，我配了一个简单的 CI，每次推送都跑一遍pytest或npm test，这样 AI 提交的坏代码会在合并前就被拦下来，而不是在上线时才爆雷。

5. 部署不焦虑：Portainer 与容器化的“可回滚”底线

5.1 为什么 vibe coding 项目特别需要容器化

代码能在你机器上跑，不代表能在服务器上跑。vibe coding 项目尤其明显，因为 AI 生成代码时不会考虑你服务器上有什么依赖、什么 Python 版本、哪个端口被占用了。我经历过太多次“我本地好好的，服务器一跑就挂”的场景，后来强制所有服务都容器化，问题少了一大半。

容器化给 vibe coding 项目兜了一条底：环境配置本身也变成代码，可以被审视和回滚。AI 生成的 Dockerfile 和 docker-compose.yml 虽然不一定完美，但它们是文本，可以在 Gitea 里 diff、审查和回退。这就把“服务器环境坏了怎么办”从玄学变成了工程问题。

5.2 Portainer 的操作入门

用容器部署，不能全靠 SSH 敲命令。Portainer 是一个开源的容器管理面板，提供了 Web UI，可以管理 Docker 主机、镜像、容器、网络、卷和堆栈。对我来说，它最大的好处是把所有服务的状态放在一个可视化面板里看，日志、端口、资源占用一目了然。

Portainer 本身也用容器部署，下面的 Compose 文件可以直接用：

version: "3.8" services: portainer: image: portainer/portainer-ce:latest container_name: portainer restart: unless-stopped ports: - "8000:8000" - "9443:9443" volumes: - /var/run/docker.sock:/var/run/docker.sock - portainer_data:/data volumes: portainer_data:

部署完成之后，浏览器访问https://服务器IP:9443，第一次启动设置管理员密码就行。之后所有服务的 docker-compose.yml 都可以在 Portainer 的“堆栈”功能里管理。我一般在 Gitea 里用deploy/目录统一存放 Compose 文件，任何改动先提交 git，再到 Portainer 里拉取和更新。

5.3 我的“三个环境”策略：本地连模型、容器跑服务、Gitea 存代码

我把整个 vibe coding 的项目分为三个环境，物理上隔离，逻辑上串成一条线：

1. 本地开发环境：Jan + Cherry Studio + Continue，负责对话、写代码、跑测试。
2. 服务运行环境：服务器上的 Docker，通过 Portainer 管理，负责正式跑 Web 服务、数据库、定时任务。
3. 代码托管环境：Gitea，负责所有代码和配置文件的版本管理，同时通过 Webhook 触发 CI。

这样设计的好处是，本地环境无论怎么折腾都不会影响线上；部署配置出了问题，直接回滚 Compose 文件；AI 写坏了代码，Gitea 的 Merge Request 阶段就能拦截。vibe coding 的“失控感”就是这样被一层一层兜住的。

6. 这套组合跑三个月后的经验与避坑

最后分享几个实际使用中的教训。这些坑我踩过，希望你能绕开。

• 不要把本地模型和云端模型混在一起用而忘了分组。我在 Cherry Studio 里一开始把所有模型堆在一个列表里，经常在对话中选错模型，导致回答风格完全不一致。后来按“本地”“云端”分组，并给每个模型写了用途备注，情况好多了。
• Continue 的自动补全不是越强越好。自动补全模型如果太激进，会在打字中途插进来一大段代码，打断思路。我最后把 tab 补全改成了手动触发，只在需要时唤出，反而感觉更可控。
• Dify 知识库的分段大小直接影响检索效果。我刚开始用了 200 个 token 的分段，检索经常漏掉关键内容；调整到 800 左右才稳定。不同文档类型可能要调不同参数，不要一刀切。
• Termux 要认准 F-Droid 版本。从其他渠道装可能缺失核心组件，或者版本旧到没法安装 Python。
• Portainer 的卷不要只放在默认目录却不备份。数据库容器一旦重建，如果卷数据没有单独备份，损失会很大。我现在会把关键服务的卷单独映射到服务器磁盘，并做定时快照。
• 不要一开始就把九个工具全装上。我推荐的叠加顺序是：先 Jan + Continue，让 AI 在本地产出代码；再加 Gitea，把 AI 的修改纳入版本控制；最后才上 Dify、Langflow、Portainer。一步到位看似高效，实际上排查问题时很容易分不清是哪个环节出了问题。

我个人的体会是，vibe coding 焦虑本质上是“黑盒不确定性”带来的焦虑。你不再焦虑，不是因为你相信 AI 不会犯错，而是因为你有一套开源工具链让每次犯错都能被看见、被理解、被回滚。AI 负责天马行空，工具链负责落地生根，这才是能长时间稳定使用 vibe coding 的模式。