企业官网建设流程全解析

最近我把自己的“AI 编码阵地”从前台终端搬到了浏览器里——就是那个叫 Easy Web Vibecoding 的持久化 Web 工作区。它专门服务 Claude Code 和 Codex 这两套命令行编码工具，解决我在日常 AI 编码中遇到的最大问题：会话上下文断裂、多工具配置割裂、以及一次崩溃就丢半天的状态。如果你正在同时用这两套 CLI，或者已经厌倦了在终端里反复拷问 AI“刚才我们说到哪了”，这篇文章应该能帮你少走不少弯路。

什么场景下你会需要它？举个最简单的例子：你上午用 Codex 让 AI 重构了一个模块，下午想用 Claude Code 继续这个任务，传统做法是复制粘贴一堆历史对话，或者干脆重新交代一遍需求。在 EVWB 里，这两个后端共享同一个工作区状态，你随时可以在同一个项目下切换引擎，历史消息、文件改动、任务清单都是连续的。它适合三类人：重度依赖 AI 编程的开发者、需要同时评估多款编码工具的技术选型者、以及想把手里的 CLI 工具改造成团队协作入口的小团队。下面我从设计思路讲起，再给一套可以直接上手的搭建过程。

1. 为什么需要“持久化 Web AI 编码工作区”

1.1 Vibecoding 火起来之后，工具反而成了短板

先聊一个背景。Vibecoding 这个词最近在开发者圈子里出现的频率非常高，说白了就是：你不必逐行写代码，用自然语言把需求、约束、验收标准讲清楚，让 AI 把代码生成出来，你负责审查、纠正、迭代。这个工作方式把程序员的角色从“编写者”变成了“导演和评审”，也因此让 Claude Code、Codex 这类终端 AI 编码工具迅速流行。

但问题也随之而来：这些工具的本质是 CLI 进程，它们生来是无状态的。每次执行完命令，进程退出，对话上下文基本就“清零”了（尽管官方有 resume/continue 之类的机制，但需要你手动带参数或记住 session id）。更别提两款工具各有各的登录态、配置文件和输出格式。我在一个月内同时使用它们做同一个项目，反复在两种终端界面之间切换，很快就受不了了。

1.2 终端编码绕不开的三个痛点

第一个是上下文易失。关掉终端、网络波动、机器重启，任何一次中断都可能让 AI“失忆”。对使用长上下文大模型的场景来说，这种断裂尤其致命，因为你往往已经和 AI 建立了冗长的背景共识，重新来一遍的时间和 token 成本都很高。

第二个是多工具协作差。Claude Code 和 Codex 各自记录各自的历史，彼此不知道对方干了什么。如果一个任务要前半段用 Codex、后半段用 Claude Code，你只能人工做“信息桥接”。我试过把对话导出再手动拼给另一个工具，体验非常痛苦。

第三个是状态不可追溯。任务做到哪一步、改了哪些文件、消耗了多少输入输出，终端里全部散落。没有统一视图，也没有类似“工作区快照”的概念。于是我开始思考：能不能把这两个 CLI 变成后端，前端套一个常驻的 Web 工作区，所有状态落到本地磁盘，这样既能统一管理，又能随时恢复。

1.3 Web 工作区带来的体验变化

简单说，EVWB 的思路是“工具下沉、状态上浮”。Claude Code 和 Codex 继续扮演执行引擎的角色，负责真正地读写代码、运行命令、产出结果；而 Web 工作区负责把它们的输入输出、会话记录、文件变更全部捕获下来，做成可查询、可恢复、可迁移的状态层。浏览器只是这个状态的展示窗口。

这样做有几个实打实的好处：你可以在笔记本和台式机之间共享同一个工作区（服务常驻在某一台机器上）；项目状态不再随着终端关闭而消失；两个 CLI 后端可以任意切换而不丢失上下文；同时还能在界面上做任务清单、会话回放这些终端里做不到的交互。对个人开发者来说它是个效率工具，对小团队来说它甚至可以当做一个轻量的 AI 编码协作面板来用。

2. 整体架构与关键技术选型

2.1 EVWB 的定位是编排层，不是替代层

在设计架构时，我反复提醒自己一件事：不要重新发明一个 AI 编码引擎，也不要试图封装 Claude Code 或 Codex 的全部能力。EVWB 要做的是一个轻量编排层——它通过子进程启动 claude 或 codex，把用户的 prompt 传进去，把返回的流式输出实时回传到浏览器，同时把整个交互过程落盘。

这个决定的理由很实际：命令行工具更新频繁，你封装得越深，跟进上游的维护成本越高。用子进程方式，底层工具的升级、新参数、新模型都会自动继承，工作区只需要处理通用的输入输出。为了稳妥，我还让每个子进程都运行在独立的项目目录里，保证文件系统的隔离和回滚能力。

2.2 技术栈：Node.js 是这类工具的合理起点

我最终把核心服务放在 Node.js + TypeScript 上，前端用一个轻量的 React 单页应用。选 Node.js 并不是因为它性能有多强，而是因为 Claude Code 和 Codex 的生态都深深扎在 npm 里，用 Node 处理子进程、解析 stdout、管理配置最方便。child_process 的 spawn 可以直接对接流式输出，这对编码 AI 的长响应特别关键。

数据层我用了 SQLite，而不是一堆 JSON 文件。原因有两个：一是并发写入时 SQLite 能避免文件互相覆盖的问题；二是按项目、会话、消息做结构化查询太方便了——比如“找出上周所有失败的执行记录”，JSON 文件得写不少遍历代码，SQLite 一条 SQL 就搞定。持久化目录我配置成独立文件夹，方便备份和迁移。

2.3 持久化设计：参考 Redis 的快照加日志双机制

说到“持久化”，很多人第一个想到的是 Redis。Redis 提供 RDB 全量快照和 AOF 追加日志两种方案，前者恢复快、后者丢数据少。EVWB 的会话存储也借鉴了同样的思路，我把它拆成两层。

第一层是操作日志：每次用户发送 prompt、每次 AI 返回一段输出，都会同步追加到当天的日志文件里，这是最细粒度的记录。第二层是会话快照：每个会话结束时（或者达到自动保存间隔时），把完整的状态——消息列表、上下文摘要、相关文件改动记录、当前配置——压缩成一份 JSON 快照。恢复的时候先加载最近的快照，再按日志重放快照之后发生的事件，这样既不用逐条重放全部历史，也不会丢最后几分钟的细节。

2.4 多后端适配：统一抽象是关键

要让两个差异很大的 CLI 协同工作，需要一层适配器。我定义了一套统一接口，比如 execute(prompt, sessionId)、listSessions()、resumeSession(sessionId)、getOutputFormat()。Claude Code 适配器和 Codex 适配器分别实现这些接口，内部处理各自的参数风格和输出解析。

这里还有个小工具值得提一下：社区里的 CC Switch。它的作用是帮你管理这两个 CLI 的供应商配置和凭据，比如从默认的官方端点切到某个第三方模型服务，或者在不同账号之间切换。EVWB 可以在启动时读取 CC Switch 生成的配置，这样一来，你在 Web 界面里选择后端时，实际生效的模型、供应商、密钥就已经就位了。这个组合极大减少了“切工具五分钟、写代码一分钟”的尴尬。

3. 从零到一：搭建 EVWB 并跑通第一个任务

3.1 前置准备：安装 Claude Code 和 Codex CLI

先说环境。EVWB 本质上是套在这两个 CLI 外面的壳，所以第一步是把两个引擎装好。安装方式都很简单，前提是你已经装好了 Node.js（建议 18 以上）。

Claude Code 安装：

npm install -g @anthropic-ai/claude-code claude --version

Codex 安装：

npm install -g @openai/codex codex --version

Windows 和 Ubuntu 上的操作基本一致，Ubuntu 如果 npm 全局目录权限有问题，可以用 nvm 管理 Node.js 版本，避免 sudo 安装全局包。官方也提供了桌面客户端版本，但你如果打算跑 EVWB，我建议还是用标准 CLI，因为工作区直接调用命令行要的是稳定可控的子进程接口。

3.2 初始化工作区与项目绑定

安装好后，把 EVWB 的仓库 clone 下来，进入目录执行 npm install。首次启动会让你指定一个 workspaceDir，也就是所有持久化数据存放的位置。我的习惯是在每个大项目目录下建一个 .evwb/ 子目录，把项目路径关联进去，这样切换项目时不会串上下文。

配置文件 config.json 是核心，我放一个最简示例：

{ "workspaceDir": "./data", "autosaveInterval": 30, "backends": { "claude": { "enabled": true, "model": "claude-sonnet-4-5", "contextWindow": 200000 }, "codex": { "enabled": true, "model": "gpt-5-codex", "contextWindow": 200000 } } }

这里的 autosaveInterval 控制快照保存频率，单位是秒。30 秒是我在绝大多数项目里验证过的平衡值：间隔太长，崩溃时丢的东西多；间隔太短，频繁写盘会让大项目卡顿。

3.3 配置认证与模型供应商

认证方面，Claude Code 默认读 ANTHROPIC_API_KEY 环境变量，Codex 默认读 OPENAI_API_KEY，也可以先跑一遍 claude 或 codex 让它们完成登录流程。如果你用的是官方订阅而非 API Key，直接在终端登录一次即可，EVWB 会复用 CLI 的本地登录状态。

本地模型怎么接？现在不少人在用 LMStudio 这类工具在本地跑模型，它暴露的是 OpenAI 兼容接口。对 Codex，可以在配置里指定 model_provider，把 base_url 指到 http://127.0.0.1:1234/v1。对 Claude Code，通过环境变量指定模型服务的地址也能实现同样的效果。第三方 API 也一样，比如想在 Codex 里用 DeepSeek 的模型，就把 provider 的 base_url 换成 DeepSeek 的 OpenAI 兼容接口地址，model 填 deepseek-chat。这一类兼容接口让 EVWB 的“多供应商”优势更加明显。

3.4 跑通第一个真实会话

配置齐全之后，启动 EVWB 的 Web 服务，浏览器打开本地地址。新建一个项目，绑定到你的代码仓库目录，然后在对话框里输入：

“扫描当前仓库里的 README 和 TODO 文件，列出 TODO 里优先级最高的三项，并分别给出预计改动范围和实现建议；然后针对第一项，生成一个最小可运行的代码变更，附上测试方案。”

我建议第一次任务选得小一点，因为它同时会跑两条链路：EVWB 把 prompt 转发给对应的 CLI 后端，同时把 stdout 的流式输出实时渲染到页面，并在任务结束时写入一条完整日志。你会看到页面左侧是会话列表，右侧是输出区，底部是输入框，整个过程和终端里几乎一样，但多了一个“随时回到任意历史会话”的入口。第一次跑通之后，你就可以把它当主力工具用了。

4. 持久化机制深入剖析

4.1 会话快照里到底存了什么

快照不是简单地把对话文本存起来，它包含四个部分：项目上下文（绑定的目录、仓库分支、相关配置）、会话消息流（用户的 prompt、AI 的完整回复、工具调用记录）、文件变更记录（AI 修改或创建了哪些文件，diff 的摘要）、以及后端运行参数（用了哪个模型、哪个供应商、上下文窗口多大）。这样在恢复时，EVWB 不仅能回到对话现场，还能知道当时项目处于什么状态。

持久化目录我建议这样组织：

data/ projects/ my-app/ snapshots/ 20250612-143000.json 20250612-153000.json logs/ 20250612.log sessions.db config.json

快照以时间戳命名并列存放，日志按天切割，数据库负责会话的快速索引。这套结构的好处是：即使 SQLite 文件损坏了，你依然可以从 JSON 快照和日志里把大部分内容捞回来。

4.2 断线恢复与崩溃恢复的设计细节

断线恢复分成两层。浏览器端和服务端之间用的是 WebSocket，断线重连之后，前端会向服务端请求“从上次收到的消息序号继续发送”，这样刷新页面或短暂断网都不会重复或丢失内容。服务端和 CLI 子进程之间，则是靠完整的会话记录兜底：就算 UI 彻底挂了，子进程还在跑，任务还在执行，重连后能立刻看到最新状态。

崩溃恢复要更谨慎。我让服务端在启动时扫描所有未正常结束的 session，标记为 interrupted，并给用户一个“从最后一次快照继续”的按钮。恢复时先加载最近快照，再重放日志中快照之后的增量。这个流程类似数据库的“检查点 + 重放日志”，虽然实现起来多花了一些功夫，但几次真实崩溃之后的体验证明它非常值得。

4.3 备份、迁移与多机同步

因为所有状态都落在 workspaceDir 里，备份就是打包目录：关掉服务，压缩 data 文件夹，存到任何你觉得安心的地方。迁移也一样——新机器上装好 Node.js 和两个 CLI，解压 data 目录，启动 EVWB，工作区状态原样回来。

如果你和我一样用 Git 管理项目文件，建议把 data/logs 和 data/snapshots 加进 .gitignore，不要和代码混在一个仓库里；快照太大会拖慢 Git 操作。如果有多机同步的需求，用网盘或者内网同步工具把 data 目录同步过去都可以，但要注意同一时间只能有一个 EVWB 实例在写同一个目录，否则会出现并发写冲突。

5. 高频问题排查与避坑手册

5.1 认证和订阅相关的坑

很多人在首次接入时报 Codex 提示 auth token is unavailable。我遇到这个问题的原因通常是环境变量残留或者登录态过期，解决办法很简单：先执行 codex login 重新走一遍认证，再检查系统环境变量里有没有旧的 API Key 覆盖了 CLI 的本地配置。还有一种情况是组织策略限制，比如 Claude 返回 subscription access 被禁用的提示，这通常是管理员在后台限制了成员使用，个人账号直接换成自己的 API Key 就行。

这些看似是运行时报错，实际上绝大多数和 EVWB 无关，问题出在底层 CLI 的认证状态上。排查时我建议你在终端里先手动跑一次 claude 或 codex，确认命令行本身能正常工作，再回到 Web 工作区里重试，这个“自下而上”的排查顺序能省很多时间。

5.2 端点切换和供应商配置问题

如果你用 CC Switch 在多个供应商之间切换，可能会碰到这样的场景：上一次用得好好的，切换 Codex 的 endpoint 之后，请求 /responses 接口直接报 provider 错误。我排查后的结论通常是三类原因：目标服务没有启动或端口不对、切换工具写入了配置文件但 CLI 进程还缓存着旧配置、模型名称没有被目标服务识别。

解决方案也不复杂。第一步，确认你指向的服务确实在运行，并且用 curl 手动请求一次确认响应正常；第二步，切换配置后重启 EVWB 的服务端进程，让 CLI 子进程重新读取配置文件；第三步，检查模型 ID 是否和供应商提供的命名完全一致。代码层面没什么魔法，大多数情况下都是“服务没起”或“配置没换过来”这种低级问题。

5.3 本地模型接入的几件小事

接入 LMStudio 之类的本地模型时，最容易栽的坑有三个：服务没开、端口填错、模型名不匹配。LMStudio 默认的兼容端点是 127.0.0.1:1234，但端口可以在软件里改，所以不要想当然。模型名也不是随便填，要以 API 实际返回的 model 字段为准。

还有一个容易被忽略的点：本地模型的上下文窗口通常没有云端大模型宽，Claude Code 的 1M 上下文能力只在你使用支持那么大上下文的模型时才生效。如果你的本地模型只有 8K 上下文，却给了很长很长的背景说明，后面的请求大概率会报错过长。把上下文精简一下，或者换一个窗口更大的模型，这类问题就消失了。

5.4 工作流层面的一些个人建议

最后聊几个我踩过坑之后总结的工作流习惯。

尽量一个独立项目绑定一个 EVWB 工作区，不要让一个工作区同时挂多个无关代码目录。AI 的上下文是有容量的，塞的东西越多，有效注意力越分散。我在早期就是把所有项目塞进一个工作区里，结果 AI 经常“串台”，改成项目隔离之后情况好了很多。

重大变更前手动触发一次快照。虽然 autosaveInterval 会定期保存，但手动快照在你准备做大重构之前特别有价值——如果 AI 改坏了，你可以一步回到重构前的位置。

控制日志保留策略。日志文件增长很快，长期跑下来磁盘容易爆掉。我在配置里加了日志保留天数，默认 7 天，快照保留最近 20 份，超出部分自动清理。这个动作很小，但能让工作区稳定运行很久。

另外，启动 EVWB 时加一个实例锁，禁止同一个 workspaceDir 被两个进程同时打开。我因为这个吃过亏：一次是在笔记本上开了一个实例忘了关，又在台式机上起了另一个，两边同时写会话数据库，最后不得不手动合并数据。后来在服务端加了一个简单的端口锁文件，这个问题就再也没有出现过。

我个人在实际操作中最大的体会是：持久化的价值不在于“省得重新打一遍 prompt”，而在于它让整个编码任务的上下文变成了可积累的资产。Claude Code 和 Codex 这类工具的模型能力已经很强了，真正决定体验上限的，往往是你有没有一套好用的状态管理和切换机制。EVWB 就是这个思路的一个具体落地，你可以从最小配置开始，跑一两个小任务感受一下，再逐步把聊天历史、快照、多供应商轮换这些功能用起来。最后再分享一个小技巧：把你的常见需求写成模板放在工作区的 prompts 目录里，比如“重构模块并补充测试”“排查 CI 失败原因”“审阅最近三次提交”，每次直接选择模板发起任务，比你临时打字要稳定得多，AI 的输出质量也更可预期。