企业官网建设流程全解析

最近小半年，我写代码的方式彻底变了。需求丢给 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 九个开源工具的一页总览

我先把我最终保留的工具列成一张表，后面逐个展开安装过程和避坑经验。

这个组合是我实际用下来的结果，不是拍脑袋凑数。下面逐个拆。

2. 把"会思考的那部分"留在自己手上：本地模型与自托管补全

2.1 Ollama：一行命令养一个本地模型服务

先说我为什么第一个换它。vibe coding 最核心的是模型，模型跑在哪、数据去了哪，决定了整条链路的信任基准。我需要的不是最强模型，而是能在自己机器上跑、行为可预期、API 兼容 OpenAI 的模型服务。Ollama 满足这个需求，而且简单到不像个本地模型平台。

安装分平台，macOS 直接brew install ollama，Linux 用官方安装脚本：

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_HOST=0.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.yaml：

models: - 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 Semgrep：AI 代码里的安全雷，扫出来再说

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.yaml：

rules: - 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_TOKEN=your_github_token \ -e LOG_LEVEL=debug \ 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-docusaurus@latest 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 个。一次性引入太多工具，本身就是新的焦虑源。我建议按这个顺序推进：

1. 先跑 Ollama + Continue。用本地模型替代闭源 API，立刻解决"数据去哪了"的底层焦虑，改动最小，收益最大。
2. 再加上 Semgrep。用扫描兜底，让 AI 生成的代码在你心里"过了安检"。
3. 然后是 Renovate 和 DevPod。依赖和环境可控之后，vibe coding 项目才敢拿去团队协作。
4. 最后补文档线：Logseq 记过程，Docusaurus 出文档，Legado 管输入。

每个阶段至少跑两周，确认没有引入新的问题再进下一步。我见过有人一天之内换全套，结果第二天就在新工具的组合拳里迷路了，反而更焦虑。

5.2 三个我最想提醒的坑

第一，本地模型不是万能的。14B 的本地模型和最新云端模型比，生成质量确实有差距。我的策略是：简单重复的活交给本地模型，复杂架构设计仍然可以先在云端大模型上讨论，只是不把敏感代码或数据喂进去。别因为隐私焦虑过度牺牲效率，关键是要分场景。

第二，扫描和依赖工具需要维护成本。Semgrep 规则、Renovate 的 PR 如果你不看，它们就是新的噪音源。我每周抽固定时间处理这些机器提醒，五分钟清空 inbox，让工具替我盯着，而不是让工具每天轰炸我。

第三，自托管的身份认证要当回事。Tabby、Renovate、Ollama 只要暴露到局域网或公网，就必须带上 token 或网关保护。我见过有人把没设密码的补全服务跑在云主机上，三天后日志里全是别人的请求。开源工具的安全边界，最终靠使用者自己守住。

5.3 治好的不是代码焦虑，而是失控感

换工具这件事，听起来是更换技术栈，做完之后才发现，真正被治愈的是那种"代码不是我写出来的所以我不敢改"的失控感。现在我这里的每个环节都有日志可查、有环境可复现、有决策可追溯。AI 仍然在写大部分代码，我也仍然要 review、要扫描、要补文档，但整个流程是开放的，我能随时看到链条上的每个节点。

我也更愿意把 AI 生成的内容当成"协作的初稿"，而不是"外部黑盒的产物"。这套开源组合拳未必适合所有人，但它实实在在帮我找回了对项目的基本掌控。如果你也在 vibe coding 的过程中隐隐不安，不妨先从最让你不安的那个环节开始换。换完之后你会发现，焦虑的源头从来不是 AI 太强，而是工具链对你太不透明。