企业官网建设流程全解析

最近我朋友圈里聊最多的一个词就是 vibe coding。代码交给 AI 写，人负责描述需求、复制报错、然后再祈祷一次能过。听起来很爽，但真上手的人都知道，爽不过三天：项目越写越大，AI 开始“失忆”，同一个 bug 修三次，代码能跑但没人敢动，每次合并都像拆弹。我一度被这种失控感折磨得想回到纯手写时代，直到我陆续换上一套开源 App，才慢慢把节奏找回来。这篇就把我实际在用的 9 个开源 App 和背后的工作流讲清楚，适合正在经历 vibe coding 焦虑、想找回掌控感的开发者参考。

1. 先说清楚：vibe coding 的焦虑到底从哪来

1.1 失控感：代码不是你写的，但锅是你的

Vibe coding 最大的错觉，是“我只需要描述需求”。实际上 AI 生成的代码会以不可思议的速度膨胀，而你的理解速度根本追不上它。我试过让 AI 在半小时内写完一个带数据库操作的接口，它确实写完了，功能也能跑，但里面有三个我完全没看过的依赖、两层多余的封装，还有一段像是从别的项目里“缝合”过来的逻辑。

这种体验很像请了一个手脚麻利但记性不好的实习生：它交作业特别快，但你不 review 就心里没底。问题在于，传统团队里你至少知道实习生脑子里想什么，而 vibe coding 里模型对你来说是个黑盒，它为什么这么写、改这一行会不会影响别处，你只能靠赌。焦虑的本质，就是交付速度和掌控力之间的落差越来越大。

1.2 黑盒与上下文爆炸：模型记不住你的项目，你也记不住它

第二个焦虑源更隐蔽，叫上下文爆炸。模型每次只能看到窗口里那点内容，项目一大了，它就“忘了”你三天前定的命名规范、两周前设计的表结构。你必须反复把同一段背景塞给它，否则它就会一本正经地给你提出一个和现有架构冲突的“新方案”。

更要命的是，你也记不住它。你俩的对话历史散落在十几个窗口里，哪个改过、哪个是废弃方案、哪个能落地，全靠脑补。我一度同时开六个聊天窗口，每个窗口里的 AI 都在改同一批文件，最后合并的时候，连我自己都分不清谁是谁。这种“双向失忆”才是 vibe coding 最消耗人的地方。

1.3 我验证过的方法：靠工具重建“可回退、可验证、可追踪”三个锚点

踩了两个月坑之后，我意识到问题不在 AI 强不强，而在流程缺了锚点。解决 vibe coding 焦虑，不能靠“少用 AI”或者“自己全写”，那样等于因噎废食。真正有效的方式，是把工程里早就验证过的三个机制重新捡起来：可回退、可验证、可追踪。

• 可回退：每一次 AI 改动都能从 git 历史里找到，不行就一键回退。
• 可验证：对 AI 的输出有客观判断标准，不能只看“它自己说跑通了”。
• 可追踪：需求、代码、审查记录全都能对上，项目状态一眼看清。

而这三件事，恰好是开源社区里一堆现成工具最擅长解决的。下面这 9 个开源 App，就是我一路筛出来的抗焦虑组合。

2. 9 个开源 App 的选型逻辑：不是越多越好

2.1 我挑选工具的四个原则

在列清单之前，先说说我怎么挑的。Vibe coding 工具圈更新快得离谱，今天装一个，下周就出替代品，如果见啥装啥，焦虑只会更重。我给自己定了四个原则：

第一，本地优先、数据可控。能本地跑就不把关键代码往外传，至少模型商看不见我的全部工程上下文。第二，一个工具只解决一个核心焦虑，不追求“全家桶”式的万能平台。第三，必须开源。不是因为我有多理想主义，而是开源项目出了问题我能看到 issue、能自己改，不至于对着闭源客服干瞪眼。第四，接口要开放，最好有 CLI、插件或 API，能被我串进现有工作流，而不是成为又一个信息孤岛。

2.2 九件套速览：功能和解决什么焦虑

我把最终留下的工具列成了一张表。它们都不是那种“看起来很酷但用不上”的玩具，而是我在真实项目里跑过至少两个迭代的东西。

看这张表你会发现，没有一个工具是“让你的 AI 更聪明”的，它们全都是用来“限制 AI 的破坏力”和“让过程更透明”的。这就是我抗焦虑的核心思路：你不需要一个完美的 AI，你需要一个随时能叫停、能复盘、能兜底的环境。

3. 逐个拆解：从“黑盒生成”到“可审查闭环”

3.1 核心编程链路：Aider + Cline + Continue 怎么配合

先聊最核心的编码环节。Aider 是我目前的主力，它跑在终端里，核心思想是“每次修改都自动提交到 git”。我只要开一个 feature 分支，然后启动aider，它每做一次改动就会自动生成一个提交，改崩了直接/undo，整段回退。这个能力看起来简单，但对缓解焦虑是质的改变——我不用再担心“AI 改坏了我的代码”，因为每个坏版本都留下了清晰的回退点。

实际操作中我会按顺序做三件事：先用 Aider 做大幅度的功能生成，让它把架子搭起来；然后用 Cline 在 IDE 里做精细调整，因为它会明确展示每个文件的 diff，我可以在“accept”之前看清楚 AI 到底动了什么；最后用 Continue 维护项目上下文，把命名规范、架构约定写进 rule 文件，让后面所有 AI 会话都能读到。

这三者不是重复，而是分工：Aider 负责“快”，Cline 负责“看得见”，Continue 负责“记得住”。我建议把 Aider 和 Cline 放在同一个项目里跑，但不要同时让它们改同一组文件，否则很容易互相覆盖。实测下来，先把 Aider 生成完，再切到 Cline 收尾，冲突最少。

3.2 上下文和模型网关：Open WebUI + LiteLLM

很多 vibe coding 翻车，不是因为模型差，而是因为模型换来换去。今天我试 GPT，明天用 Claude，后天又切回国产模型，同一个需求在不同模型里的表现天差地别。你以为自己在“选最优解”，其实在制造混乱。所以我用 Open WebUI 和 LiteLLM 把模型层稳定下来。

Open WebUI 是一个很成熟的开源对话前端，可以接 Ollama 的本地模型，也可以接 OpenAI 兼容接口。我平时拿它做两件事：一是临时跑跑本地小模型，处理一些不方便外发的碎片文本；二是做聊天记录的统一归档，所有和 AI 的讨论都有迹可循，不会像浏览器里的聊天窗口一样被随手关掉。

LiteLLM 则相当于一个模型网关，所有应用都通过它来请求模型，而不是各自直连各家平台。我在一个config.yaml里统一配置模型列表、密钥和限流策略，上层代码只认一个接口。这样即使某个模型服务挂了，我只需要在网关里切换，不用改业务代码。独立开发的时候你可能觉得多此一举，但只要同时用超过两家模型，你就会理解“统一入口”能省掉多少混乱。

3.3 质量验证：Promptfoo 与 git 回退机制

Vibe coding 最常见的死循环是“改 prompt、跑一次、看着还行、再改、跑一次、发现之前好的地方坏了”。因为你全凭感觉调，没有量化标准。Promptfoo 解决的就是这个问题，它本质上是给 prompt 写单元测试。

我项目里有一个prompts/目录，里面维护着一组典型输入和期望输出。每次我调整系统提示词或者换模型，就跑一遍promptfoo eval，把所有用例一次性回归掉。比如我想让 AI 把需求描述转成用户故事，那就准备几条不同风格的需求文本，断言输出里必须包含“作为”“我希望”“以便”三段式结构。

prompts: - "把下面需求写成用户故事：{{feature}}" providers: - openai:gpt-4o - ollama:llama3 tests: - vars: feature: "用户需要一个番茄钟，可以设置25分钟倒计时" assert: - type: contains value: "用户故事" - type: contains value: "作为"

跑完这个评测，我就能用数据说“这版 prompt 比上一版强”或者“这版更差”，而不是靠体感。再搭配 Aider 的自动提交机制，严格做到“每次 prompt 变更都能回退”，生成这件事就不再是不可逆的赌注了。

3.4 协作与管理：Plane + Gitea + Zed

单人 vibe coding 容易飘，多人协作的 vibe coding 则容易乱。Plane 是我用下来最顺手的开源项目管理工具，界面不花哨，但“周期”“模块”“问题”三个概念足够覆盖大多数场景。我习惯把一个大需求拆成若干个小 issue，每个 issue 绑定一个分支，Who、What、Why 都写清楚，AI 才有足够的上下文去生成代码。

Gitea 作为轻量代码托管平台，承担的是最后的把关环节。我给自己定了条规矩：哪怕是一个人开发，也要走 Pull Request，不直接往主分支推代码。PR 的好处是强制你看一遍 diff，而且所有改动都在平台上留痕。Cline 生成的改动我也会在 PR 里逐行看一遍，这一步没办法省，但有了流程保护之后，看代码的心态会放松很多，焦虑感至少少一半。

Zed 是最近才加入组合的编辑器，Rust 写的，启动快，多人协作延迟低。我主要用它做结对 vibe coding：两个人同时打开一个会话，一个人负责描述需求，另一个人负责盯 diff。这种“一个人开飞机、一个人看仪表”的模式，非常有效地防止 AI 跑偏。

4. 把它们串成一条反焦虑工作流

4.1 一条真实任务的完整走查

工具单独摆出来只是清单，串起来才是工作流。我拿一个“番茄钟小工具”的需求举例，完整走一遍现在的日常流程。

第一步，在 Plane 里建一个 issue，描述需求：支持 25 分钟倒计时、到点提醒、历史记录。拆成三个子任务，每个子任务对应一个 feature 分支。第二步，在 Gitea 上创建feature/timer分支。第三步，在终端启动 Aider，让它基于 issue 描述生成倒计时核心逻辑。它每完成一个小片段就自动提交，提交信息写得清清楚楚，方便我再 review 时对照需求。第四步，切到 VS Code 用 Cline 处理“提醒”和“历史记录”的交互细节，逐个文件看 diff，有问题当场改掉。第五步，把“需求转用户故事”的 prompt 改动跑一遍 Promptfoo，防止之前的输出格式被新改动破坏。第六步，推送分支、在 Gitea 开 PR、自己给自己做 code review、确认无问题后合并。合并之后我再回到 Plane 把对应 issue 勾选完成。

整个过程看起来步骤多，但每一步都极短，而且我的心态完全不同。我不再担心 AI 偷偷塞了一段“能跑但看不懂”的代码，因为每一段都被 commit、被 diff、被 PR 审查过。焦虑感来自未知，而这条链路让未知一个一个变成已知。

4.2 五个必须养成的反焦虑习惯

工具到位之后，真正起作用的是习惯。我这几个月总结出五条军规，每条都是从踩坑里长出来的，你直接照着做就行。

第一，每个会话开始前，先用两句话写清楚目标和验收标准。我见过太多“帮我看下这个报错”式的需求，AI 只会大海捞针，最后人也不满意。第二，Aider 自动生成的提交信息，必须能看懂。如果你看到一条 commit 是 “fix stuff”，说明 AI 自己也搞不清改了啥，这种时候要立刻停下来拆任务，而不是继续堆代码。第三，绝不让 AI 直接在主分支上干活。所有生成都发生在 feature 分支，主分支永远是干净可部署的。第四，prompt 不是聊天，而是项目资产。每次改 prompt 都要进 Promptfoo 评测，不能只靠“再跑一次看看”。第五，每个迭代结束，看一眼 Plane 的看板和 Gitea 的 PR 列表，确认“说要做的事”和“实际做的事”对得上。只要对不上，就说明上下文又失控了，要回到规则文件里补背景。

这五条军规不复杂，但它们把 vibe coding 从“AI 带着你跑”变成了“你带着 AI 跑”。方向感一旦回来，焦虑自然就降了。

5. 常见问题与避坑实录

5.1 模型越强越焦虑？用错工具的三种典型症状

如果你配了工具还是觉得焦虑，先看看是不是踩了下面三个坑。

第一种症状是“越换模型越焦虑”。今天听说这个新模型强，明天就换过去，同一段代码在不同模型里反复生成，最后项目里混着三种风格。这种问题的根源不是模型不好，而是缺少统一网关和评测标准。用 LiteLLM 固定接入层，用 Promptfoo 固定验收标准，模型切换才不会变成灾难。

第二种症状是“代码能跑，但没人敢改”。这说明你跳过了 diff 审查。代码能跑不代表结构合理，更不代表别人敢在此基础上迭代。一定要让 Cline 这类工具把改动亮出来，你至少看过一遍，知道它干了什么，才叫掌握主动权。

第三种症状是“项目历史一团乱”。今天这个文件是谁改的，那个功能是哪次提交引入的，完全查不到。这不是 AI 的问题，是流程问题。把 Gitea 的 PR 和 Plane 的 issue 绑起来之后，历史就变成可检索的了。

5.2 两条独家避坑技巧

最后的避坑技巧，算是我自己花了最多时间才想明白的。

第一个技巧：不要在你常用的 IDE 里装太多 AI 插件。我有一段时间同时开了四五个 AI 相关插件，结果它们都在读上下文、都在往同一个目录里写缓存，甚至有几个会抢快捷键。AI 插件之间互相打架，比没有 AI 还让人烦。我的建议是每个阶段只留一个主力：快速生成用 Aider，精细修改用 Cline，上下文规则用 Continue，其他的全部禁用。不同时切换，反而更快。

第二个技巧：给每个项目维护一份全局 Markdown 文档，记录 AI 上下文之外的“硬事实”。比如数据库表结构、接口约定、当前分支改到哪了、下一步要做什么。模型上下文窗口再大，也不如一张写得清楚的结构化文档可靠。每次开启新的 AI 会话之前，我先把这份文档扔给它当背景，效果比在聊天里重复十遍“记住我们之前说的”好太多。这份文档同时也是你自己的记忆备份，就算隔一个月回来，扫一眼就能重新上手。

我在实际使用中还有一个体会：vibe coding 本身没有问题，问题在于我们总想让它替代所有工程流程，而事实上它更适合被当成一个生成速度极快的“同事”，需要有人给它设定边界、检查输出、记录历史。这套开源 App 组合本质上就是给这个“同事”配了一套完善的作业环境。你先别急着一次性把九个全装齐，先从 Aider 加 Gitea 这套最小闭环开始，跑顺后再往下加，焦虑感会随着每一步自动化慢慢消失。