企业官网建设流程全解析

先交代一个背景：vibe coding 这个词最近在技术圈刷屏刷得很凶。简单说就是打开 AI 编码工具，用自然语言描述想法，让 AI 大段大段生成代码，人只负责"顺着感觉走"——跑通了就继续，跑不通就丢给 AI 改。一开始确实爽，原本要憋一晚上的功能，半小时就出来了。但爽了大概两周，我开始整夜睡不着：那个 AI 帮我写的模块，到底在底层做了什么？我给不了答案。

这个问题不敢细想，一想全是坑。依赖链安不安全、改了一个需求会不会牵连另外三个功能、下周再看这堆代码还认不认得出来、团队里别人怎么接手……这些焦虑全是"失控感"。我花了两个多月，把身边的开源工具认认真真筛了一遍，靠 9 个开源 App 搭了一条安全带。核心思路不是放弃 vibe coding，而是让它从"脱缰野马"变成"戴着笼头跑马"。这篇就把我的完整方案、部署细节和踩坑过程全部写出来。

1. 先想明白：vibe coding 的焦虑到底从哪来

1.1 什么是 vibe coding，为什么它这么容易上瘾

vibe coding 最早流传开来，是说"写代码不再需要逐行思考，你只要描述意图、让 AI 输出、然后复制粘贴调试"。它本质上是把编程从"手工艺"变成"指挥艺术"。对很多人来说，这极大地降低了起步门槛，也让原型验证这件事变得极快。

它的上瘾点非常直白：即时反馈。你提需求，AI 给你结果，跑一下，报错了继续丢回去，改一改就通。这个循环比任何游戏都容易让人沉迷。尤其是做过传统开发的人，受够了启动一个项目的心理摩擦，vibe coding 直接把这个摩擦抹平了。我当时的第一感受就是，终于不用再被空白的编辑器吓退了。

但问题也藏在这里。正因为反馈来得太快，你根本不会停下来看一眼中间过程。一天下来你"写了"上千行代码，但如果你追问自己：这几百行代码用了什么依赖、有哪些隐藏副作用、有没有明显的安全问题？大概率答不上来。所谓焦虑，就是从这种答不上来的瞬间开始的。

1.2 焦虑清单：失控感可以拆成六件具体的事

我把自己的焦虑拆了一下，发现根本不是笼统的"怕"，而是六件非常具体的技术问题。

第一是黑盒焦虑。AI 生成的函数、模块，我看不懂也说不清，出问题只能靠猜。第二是回归焦虑。让 AI 改 A 需求，结果 B 功能悄悄坏了，且没有迹象。第三是供应链焦虑。AI 让我装了什么包就用什么包，这些依赖有没有漏洞、有没有后门，我完全没把门。第四是上下文焦虑。需求、讲解、取舍全部散落在聊天记录里，第二天新鲜出炉的文档等于没有。第五是质量焦虑。代码能跑，但变量命名稀烂、函数长到几百行、错误处理缺失，后面接手的同事会骂人。第六是协作焦虑。几个人同时在 vibe coding，各自改各自的，最后合并成一锅粥。

如果你也在用 vibe coding，对照一下这六项，至少中一半。这不是个人能力问题，是流程里缺了约束和反馈机制。

1.3 为什么我优先选开源工具，而不是商业 SaaS

解决这些焦虑，我用的是清一色开源工具，有三个原因。第一个是透明度。vibe coding 本身就是"别人替你写代码"，如果连检查代码的工具都是黑箱，焦虑不但不缓解，还会更严重。开源工具至少我能看到扫描规则、识别逻辑、存储方式，心里踏实。第二个是数据可控。AI 生成的业务代码往往敏感，我不太想把半成品的仓库、数据库结构、需求文档全都交给第三方平台。自托管开源工具把数据全部留在自己的服务器或电脑上，没有外传风险。第三个是成本。这 9 个工具加起来，软件授权成本是零，只要能跑 Docker 或装个桌面客户端就行，对个人项目和小团队非常友好。

2. 工具链全景：一个焦虑配一个解药

2.1 选型思路：不是收藏夹式堆砌，而是按焦虑分类找工具

我见过不少人看推荐帖就下载一堆工具，结果每个都用一下然后吃灰。我这次反过来做：先把上一章的六类焦虑写下来，再逐个去开源社区里找"恰好能解决这个具体问题"的工具。标准有四个：一是活跃度，仓库要有人在维护，issue 有人回；二是部署成本，个人能跑起来；三是能融入现有工作流，不是让我改变习惯去适应它；四是用户文档足够清晰，新手上路不费劲。

最终选出的 9 个工具，里面有代码托管、Git 客户端、代码质量平台、安全扫描器、代码搜索引擎、AI 编程助手、协作文档库、数据库管理客户端和团队看板。它们不是同一类产品，而是各管一段的组合拳。

2.2 一张表看清 9 个工具和它们破解的焦虑

这套组合的选型逻辑是"小而美"，我没有刻意去选全家桶式的一体化平台，因为 vibe coding 本来就是轻量、碎片化的工作方式，工具链太重反而会产生新的焦虑。

3. 逐个拆解：9 个开源工具的实操心得

3.1 Gitea：给 AI 代码一个不慌的"仓库"

我最早解决的焦虑是"代码没地方放"。vibe coding 期间代码频繁变动，几十个文件散落在本地目录，今天改了明天就忘。Gitea 是个极轻量的 Git 托管服务，官方说 1 核 2G 内存的小机器就能跑得很舒服，非常适合个人或小团队。我直接在一台闲置的老服务器上用 Docker 起了一个，项目仓库、团队账号、Web 钩子全都有了。

实际部署很简单，一条命令的事：

docker run -d --name=gitea \ -p 3000:3000 -p 2222:22 \ -v /opt/gitea:/data \ gitea/gitea:latest

注意 SSH 端口我特意映射成 2222，避免和宿主机 22 端口冲突。刚上手时记住一件事：只要 AI 帮你写完一段能通过编译、能跑起来的功能，就立刻 commit 并 push 到 Gitea，哪怕代码写得很丑。那是一个恢复点，是你在 vibe coding 快车道上系上的第一根安全带。后面所有工具都会围绕这个仓库展开，它是整个工作流的锚点。

3.2 GitButler：把 AI 乱改的分支掰回正轨

用传统 Git 工作流来做 vibe coding 会特别痛苦，因为你经常想让 AI 同时改两个不相干的事情，结果所有改动都堆在工作区里，最后分不清哪块属于哪个需求。GitButler 是我用过的开源 Git 桌面客户端里，最契合 vibe coding 场景的一个。它的核心是虚拟分支，你在一个工作副本里同时开多个"虚拟分支"，然后像整理文件一样把某个文件的改动拖到对应分支里，提交时互不干扰。

举个例子：我让 AI 同时优化登录逻辑和修改支付页面文案，这两个需求都在一个代码库里产生了改动。在 GitButler 里，我会建两个虚拟分支，把登录相关文件的改动拖进分支 A，把支付页面的改动拖进分支 B，然后分别提交、推送。整个过程可视、可控，彻底告别"一团乱麻"。

有几个细节要注意：GitButler 的虚拟分支操作不会立刻改变工作目录，它是在后台安全整理的，所以不要误以为项目文件没变化。另外，如果某个分支提示冲突，不要硬来，先把工作区暂存甚至备份，再还原回基础分支处理。它内置了 AI 提交信息生成，但我通常自己写，提交信息是给人看的，AI 写的版本有时候浮夸不准确。

3.3 SonarQube：给"能跑"的代码加一道质量闸门

vibe coding 最大的隐性问题是"能跑"和"可维护"是两个维度。AI 生成的代码里，容易出现超级长函数、明显逻辑重复、公开方法没注释、异常被吞掉等问题，短时间感受不到，三个月后 debug 时欲哭无泪。SonarQube 社区版是开源的质量管理平台，能把这些问题量化成一条条规则，给出严重级别和修改建议。

我部署的时候直接用了官方 Docker 镜像：

docker run -d --name sonarqube \ -p 9000:9000 \ -e SONAR_ES_BOOTSTRAP_CHECKS_DISABLE=true \ sonarqube:lts-community

注意这台机器至少要有 2GB 可用内存，否则 Elasticsearch 起不来。扫描项目用 sonar-scanner 命令行：

sonar-scanner \ -Dsonar.projectKey=my_vibe_project \ -Dsonar.sources=. \ -Dsonar.host.url=http://localhost:9000 \ -Dsonar.token=你生成的token

刚开始跑一个 AI 写的项目，issue 数量会非常吓人，几十上百条都正常。我的建议是不要追求存量清零，只在提交时看新增代码和本轮改动的问题就行。重点是让 SonarQube 拦住那些 Blocker 和 Critical 级别的问题，比如明显的空指针风险、未处理异常、潜在注入点。另外社区版对 C/C++、Objective-C 这类语言支持有限，但 vibe coding 常用的是 Python、JavaScript、TypeScript、Java，这些都没问题，够用了。

3.4 Trivy：扫描依赖里的"隐藏地雷"

vibe coding 时我会不停让 AI 添加依赖，习惯性跑一句 npm install 或者 pip install，装完了根本不知道依赖树上有什么。Trivy 是个用 Go 写的开源安全扫描器，能扫容器镜像、文件系统、Git 仓库和 SBOM，最关键的是它速度快、规则全、命令行友好，而且可以完美嵌入 CI。

实际操作很简单，在项目目录下直接扫：

trivy fs --scanners vuln,secret,config .

如果已经打了镜像，也可以直接扫镜像：

trivy image myapp:latest

我一般在 Gitea Actions 里加一个任务，每次 push 都会自动扫一遍依赖和密钥，一旦发现 Critical 级别的漏洞就给出警告。配置片段大概是这样的：

jobs: security-scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: aquasecurity/trivy-action@master with: scan-type: fs scan-ref: . format: table exit-code: '1' ignore-unfixed: true

ignore-unfixed这个参数很重要，它能过滤掉那些目前没有修复版本、只能默默观察的漏洞，避免每次构建都因为历史遗留问题报警。你的核心目标是识别"当前项目里可被直接利用且能修复"的高危项。

3.5 Sourcegraph：AI 代码的"人肉搜索引擎"

vibe coding 项目发展到中后期，代码量变多之后，我经常出现这种情况：记得项目里某个地方处理过类似逻辑，但完全不记得在哪。传统 grep 只能搜单仓库、单目录，跨仓库、跳定义、查调用关系，还得靠更专业的工具。Sourcegraph 就是面向代码的搜索引擎，支持全文搜索、正则搜索、跨仓库代码导航，还能理解符号之间的引用关系。

私有仓库场景下我选择自托管，官方提供了 docker-compose 部署方式，启动后把 Gitea 作为代码源接进去。需要提醒的是，这东西比 Gitea 和 SonarQube 都吃内存，我建议分配至少 4GB 内存给它。如果机器不够，可以先只做纯文本搜索，关闭部分代码导航索引，至少让"全局搜代码"这件事跑起来。

我自己最常用的场景是"打断"AI：当 AI 又打算重复造轮子时，我先在 Sourcegraph 里搜一下这是不是已经存在相同实现；当 AI 改动影响到某个函数时，我搜一下这个函数的调用链，评估影响面。这一步治的是"让自己的项目变成陌生项目"的恐慌。

3.6 Continue：让 vibe coding 重新"看得见"

传统 vibe coding 最大的问题不是 AI 写不好，而是你管不住它的思考过程。Continue 是一个开源的 AI 编码助手，作为 IDE 插件运行，最大特点是"透明可控"——模型用哪个、提示词是什么、上下文包含哪些文件，全部写在配置文件里，可以像代码一样版本化管理。

我的配置思路是：把项目的编码规范、架构约定、注意事项写进一个AGENTS.md文档，然后在 Continue 的配置里指定它作为项目上下文。这样每次 AI 生成代码前都会先读到约定，减少乱写一气的情况。它支持云模型服务，也支持本地部署的模型。如果你对数据敏感，完全可以把模型跑在本地，通过 Ollama 这类工具加载，配置类似这样：

models: - name: Local Coder provider: ollama model: qwen2.5-coder:7b roles: - chat - edit - autocomplete

用 Continue 之后，我最大的感受是"AI 瞎编"的概率下降了很多。因为它能提前读到项目里的模块划分、命名规范、数据库表结构，生成的结果更贴合现状，而不是每次都拿通用模板糊弄我。这让 vibe coding 从"盲飞"变成"至少能看到仪表盘"。

3.7 AFFiNE：把聊天记录沉淀成结构化上下文

vibe coding 最伤不起的是上下文丢失。我和 AI 在聊天工具里来回对话，把需求从模糊聊到明确，但第二天打开 IDE，面前的 AI 又是一个"新朋友"，什么都不记得。AFFiNE 是开源的一体化协作平台，把文档、白板、数据库整合在一起，可以自托管。

我现在的习惯是：每次开工前，先在 AFFiNE 里写一页"需求上下文"，内容包括这个功能要解决什么问题、主要用户是谁、有哪些边界条件、和现有系统的哪些模块有关系。写完以后，把它复制进 Continue 的项目上下文里，这样 AI 在生成代码前就带着需求背景，而不是只盯着当前文件瞎猜。

AFFiNE 的自托管也比较轻，一条 Docker 命令就能启动：

docker run -d --name affine \ -p 3010:3010 \ -v /opt/affine:/data \ ghcr.io/toeverything/affine:stable

对我来说，它治的焦虑是"聊天记录不等于文档"。把零散对话沉淀成结构化文字，成本很低，收益却非常大。特别是在隔几天再继续一个项目时，这份文档能让你在十分钟内重新进入状态，而不是对着 IDE 发呆半小时。

3.8 DBeaver：可视化拯救混乱的数据库

vibe coding 时 AI 特别喜欢直接建数据库表，而它建的表结构经常出问题：字段类型不合理、缺索引、命名不统一、外键关系混乱。等你发现性能问题时，数据已经写了一堆，迁移成本很高。DBeaver 社区版是一款开源的多数据库管理工具，支持 MySQL、PostgreSQL、SQLite、SQL Server、Oracle 等几乎所有常见数据库，不仅能跑 SQL，还能直接看 ER 图。

我的工作流是：让 AI 生成建表 SQL 后，先在 DBeaver 里连上开发库，执行一遍再看 ER 图。一张图胜过千行 SQL，表关系是否合理、有没有孤立表、字段命名风格是否统一，一眼就能看出来。配合内置的执行计划查看功能，还能快速发现 AI 生成的 SQL 哪里缺索引。

新手容易忽略的一点是驱动问题：DBeaver 连接新版数据库时，默认驱动可能太旧导致连不上。遇到报错，先去"数据库驱动管理器"里检查版本，在可用的驱动列表里选新版下载。这个坑我踩过很多次，最后都是升级驱动解决的，不是数据库配置错误。

3.9 Planka：团队协作不靠口口相传

把 vibe coding 从个人体验扩展到团队时，最尴尬的是"每个人都在写，但没人知道对方在写什么"。Planka 是一个开源看板工具，类似 Trello 的轻量替代品，功能包括项目列表、卡片拖拽、标签、成员和截止日期，界面清爽，没有花哨功能。

我的用法是：每个 vibe coding 任务建一张卡片，从"需求收集"到"进行中"到"待验收"到"已完成"逐步流转。卡片上会附上对应的 Gitea 仓库地址、分支名、AFFiNE 文档链接，这样团队成员随时能知道当前进行到哪一步、改动涉及哪段代码。每天下班前花两分钟把状态更新一遍，信息同步的成本极低。

Planka 部署同样简单：

docker run -d --name planka \ -p 5000:1337 \ -v /opt/planka:/data \ -e BASE_URL=http://你的地址:5000 \ -e SECRET_KEY=随便写一个长随机串 \ ghcr.io/plankanban/planka:latest

它治的焦虑不是代码层面，而是人与人之间的协作层面。vibe coding 的产出速度快，如果不加一层"看板来沉淀协作痕迹"，团队很快就会变成各写各的、合并时互相踩脚。

4. 组合拳怎么落地，才不会把自己耗死

4.1 一套可以照抄的 Docker 启动配置

9 个工具里，最核心的自托管服务是 Gitea、SonarQube、AFFiNE、Planka 这四个。我习惯用 docker-compose 把它们放在一台机器上统一管理。不需要顶配服务器，4 核 8G 的机器跑这四个服务加两个小型扫描任务完全够用。

大致结构是这样的：

services: gitea: image: gitea/gitea:latest ports: - "3000:3000" - "2222:22" volumes: - ./gitea:/data sonarqube: image: sonarqube:lts-community ports: - "9000:9000" environment: SONAR_ES_BOOTSTRAP_CHECKS_DISABLE: "true" volumes: - ./sonarqube/data:/opt/sonarqube/data - ./sonarqube/extensions:/opt/sonarqube/extensions affine: image: ghcr.io/toeverything/affine:stable ports: - "3010:3010" volumes: - ./affine:/data planka: image: ghcr.io/plankanban/planka:latest ports: - "5000:1337" environment: BASE_URL: "http://localhost:5000" SECRET_KEY: "换成你自己的随机字符串" volumes: - ./planka:/data

GitButler、Continue、DBeaver 是桌面应用，装在自己电脑上。Sourcegraph 因为内存占用大，我建议按需启动，不用常驻。Trivy 作为一个命令行工具，既可以本地跑，也可以放进 CI 里自动跑，平时不需要常开。

4.2 我目前每天都在跑的完整流程

工具齐了以后，关键在于把流程理顺。我现在每天实际的节奏是：早上先打开 AFFiNE，看一眼昨天的文档和今天的任务清单，把需要让 AI 实现的需求写成一页上下文。然后打开 IDE，用 Continue 加载这份上下文，开始 vibe coding。

代码推上前，先在 GitButler 里看一眼所有改动，把不同需求拆到不同虚拟分支，提交信息写清楚。接着 push 到 Gitea，Gitea Actions 会自动触发 Trivy 扫描和 SonarQube 质量检查。等结果出来，我重点看报告中 Critical 级别的问题，能改就让 AI 照着建议改，改完再提交一轮。

涉及数据库改动时，用 DBeaver 连开发库，跑 SQL 后看 ER 图，确认 AI 建的表结构符合预期。最后把项目进度更新到 Planka 的卡片上，把今天踩过的坑和关键结论补回 AFFiNE 的文档里，作为明天的上下文。整个流程跑下来差不多大半天的功夫，但项目一直是"有感知"的状态，不会突然失控。

4.3 团队落地建议：别一上来就上全套

如果你想把这套组合推广到团队，我的建议是从轻到重逐步来，千万别要求所有人第一天就学会用九个工具。我自己推的时候分了三步。

第一步只上 Gitea 和 Planka，要求所有人把代码放仓库、把任务放看板。这两件事学习成本极低，几乎不需要改变编码习惯。第二步再引入 SonarQube 和 Trivy，把它们挂在 CI 里自动跑，不要求人工看界面，只在合并前看报告。第三步才考虑让每个人用 GitButler 和 Continue，这部分涉及个人操作习惯，适合小范围试点后再推广。

这么做的原因是，工具链本身也会有"上手焦虑"。如果第一周就让大家面对九个工具，极大概率激起抵触情绪。先解决最痛的"代码没地方放"和"协作没着落"，后面自然水到渠成。

5. 实操中的常见问题和排查速查

5.1 高频问题速查表

5.2 我从这些坑里总结的几条独特建议

第一条是不要追求存量归零。SonarQube 和 Trivy 第一次跑出来的问题数量肯定很难看，尤其面对 AI 生成的代码。不要幻想清零，把它们当成"新增代码的门禁"才是合理用法。第二条是别让 AI 一次改太多文件。你可以在 Continue 的提示词里明确写"本次只修改指定文件，不要动其他模块"，这会大幅减少 GitButler 分支冲突和 SonarQube 的误报范围。第三条是定期生成"项目说明书"。每隔一周，让 AI 结合 AFFiNE 文档和 Sourcegraph 的搜索，生成一份项目结构总结，放到文档库里。这能有效缓解"隔几天再看像陌生项目"的焦虑。

还有一条很反直觉但很有效的经验：vibe coding 的时候，反而要加强备份意识。代码越容易生成，越容易让人忽视版本管理。我经历过一次 AI 误操作把整个目录覆盖，还好 Gitea 上有前一个小时的版本，一条命令就恢复了。从那以后，我宁可多 push 几次，也不让本地目录里的代码成为唯一版本。

6. 用这套组合两三个月后的真实感受

6.1 对比：以前是"开快车无刹车"，现在是"有仪表盘的自动驾驶"

回想一下用这套组合前后，最大的变化不是代码质量立刻提高了多少，而是"项目状态是否随时可知"。以前 vibe coding，我像在一条看不清前方的路上狂踩油门，看着功能一个接一个跑通，心里却知道这车没刹车。现在每个环节都有反馈：代码进了仓库可以回溯，依赖被扫描过滤了高危项，质量报告标出了问题区域，数据库结构可视化可检查，团队进度看板一目了然。

这种"可感知"本身就极大地治焦虑。它不会阻止你翻车，但会在翻车之后让你快速知道问题出在哪，知道怎么回退，知道下一次怎样才能少踩同一个坑。

6.2 我的使用原则和最后一个实用技巧

如果让我总结这套工作流的核心，那就是"让 AI 负责写得快，让开源工具负责兜住底"。不要把 vibe coding 当成绕过工程流程的捷径，而要把它当成"草稿能力增强器"。它生成的代码永远是草稿，质量门禁、安全扫描、版本管理、团队看板这些才是最终交付的保障。

最后一个实用小技巧，是我每天结束前雷打不动的动作：花十分钟，打开 Planka 把卡片状态更新完，再在 AFFiNE 里写三到五行今天的进展和明天的计划。这十分钟的"闭环动作"，比任何工具本身都更能让你睡个安稳觉。AI 写代码再快，节奏感还是要自己掌握。如果你也正在被 vibe coding 的失控感折腾，建议先从 Gitea、Continue、Planka 这三件套开始，跑通以后再慢慢加。你会发现，让 AI 写得开心不是本事，能收得住、接得上、交付得出去，才是真正治焦虑的办法。