做了一阵子 vibe coding我最大的体会是Claude Code 和 Codex 这代 CLI Agent 是真的能干活但干活的环境还停留在“本地开个终端”的原始阶段。这个矛盾在我连续半个月两头跑、经常换设备之后彻底爆发——电脑合上上下文断了刚才还聊得火热的 agent 转头就忘了自己要干嘛。所以我把自己的工作区整个重做了一遍做成了一套跑在服务器上的持久化 Web AI 编码工作区我管它叫 Easy Web Vibecoding。简单说就是Claude Code 和 Codex 都在云服务器上常驻我用浏览器从任何设备接入文件、会话、进程全都不会因为关电脑而消失。这篇文章会把我从零搭建的过程整个摊开来讲包括为什么必须持久化、为什么偏偏选这两个 CLI、具体怎么部署、两个 agent 怎么在同一工作区长期协作以及我在安装、认证、切换模型端点时踩过的一串坑。不管你是刚看完 claude code 安装教程的新手还是已经在折腾 codex 配置的老玩家应该都能在里面找到对应的答案。1. Vibecoding 的房间里的大象会话说没就没Vibe coding 这个玩法的核心是“连续对话”。你给 agent 描述需求、它给方案、你拍板、它改代码、你跑测试、发现问题再丢回去。这个过程里最值钱的不是某一次回答而是累积下来的那几十轮上下文——里面有你做的所有技术取舍有 agent 对项目结构的理解有已经被否掉的方案。但传统终端默认给了你一个巨大的隐藏成本上下文是活的进程却是脆的。这几乎是所有第一次长期使用这类 CLI 工具的人都会撞上的墙。1.1 我的翻车现场一个写了一半的需求和一台没电的笔记本有段时间我在做一个工具类小项目核心功能已经讨论得差不多了。当时 Claude Code 在对话里给我拆好了三个阶段的实施计划我也确认了选型——数据库用 SQLite、任务队列先用进程内的方案、前端不引框架。我关了电脑准备第二天继续。第二天我在另一台设备上打开终端发现昨天的会话根本没同步过来。我试图靠记忆重建那几十轮对话的结论结果写了十分钟需求描述agent 给出的方案还是跑偏了因为它在关键取舍点上没有上下文我也没有耐心逐条重新交代。更尴尬的是跑了一半的迁移脚本、临时写的测试数据、还没提交的改动全都散在那台没电的笔记本里。那一刻我意识到vibe coding 的瓶颈早就不是模型能力而是工作区的连续性。所以我把重心从“怎么提示词调优”挪到了“怎么把环境变成持久化的”Easy Web Vibecoding 就是这套思路的落地。1.2 持久化工作区到底“持久”在哪里我理解里一个真正称得上持久化的 AI 编码工作区至少要兑现下面三个“不丢”文件不丢所有项目代码都在服务器磁盘或容器卷里而不是某台笔记本的本地目录。会话不丢agent 的对话历史、tmux 里的进程、跑了一半的测试全都常驻在服务器上。接入不丢通过 Web 终端访问换设备只是换个浏览器标签不改变工作现场。把这三点放到一起看常见的几种方案差距就出来了方案文件持久化会话持久化跨设备接入多 Agent 隔离本地终端本机无无无tmux 本地本机有无一般Web 工作区本文方案服务器有浏览器随手开按会话/目录隔离有人会问tmux 不就解决了会话持久化吗对tmux 解决了“进程活着”的问题但没解决“换个地方还能连上”和“多台设备环境一致”的问题。而这两点在团队协作、跨设备切换、甚至是临时出门用手机看一眼进度的时候都是刚需。Easy Web Vibecoding 把这三层一起做掉了。提示搭建之前先想清楚自己到底需要哪一层。如果平时只在一台电脑上写代码tmux 就够了没必要上 Web 终端如果你和我一样频繁换设备、或者想让队友随时接入再往 Web 化走。2. 为什么偏偏是 Claude Code 和 CodexCLI 原教旨工作流才是 Web 化的前提市面上能做 AI 编码的工具太多了编辑器插件、云 IDE、独立 Agent 应用各有各的拥趸。但我最终把底座压在 Claude Code 和 Codex 两个命令行工具上不是顺手而是因为它们有几个 Web 化绕不开的特性。首先是无头运行。CLI 工具不依赖图形界面跑在 tmux 里、重定向到日志文件、通过环境变量注入配置全部可行。其次是可脚本化。我可以把密钥、模型端点、工作目录全部写进配置任何一台新服务器 clone 一遍配置就能复现同样的工作环境。这两点决定了它们能放进一个“服务器 Web 终端”的架构里不会像 GUI 工具那样别扭。2.1 两个 CLI Agent 的分工一个管重活一个管快活Claude Code 和 Codex 虽然都是命令行 Agent但性格差异挺明显。Claude Code 在长上下文推理、仓库级重构、规划拆解上更毛糙也更聪明适合做需要反复斟酌的活儿Codex 的指令执行更利落适合做边界清晰、验证路径明确的活儿比如按 issue 修 bug、批量补测试、调用 API 写胶水代码。我在同一个工作区里给它们分了工能力项Claude CodeCodex CLI安装方式npm i -g anthropic-ai/claude-codenpm i -g openai/codex身份认证claude login / API keycodex login / API key项目指令文件CLAUDE.mdAGENTS.md会话恢复--continue / --resumeresume session_id扩展能力Skills、hooks、subagents配置精简、专注执行实际项目里我一般让 Claude Code 负责整体规划和核心业务代码让 Codex 负责独立的后台任务——比如在另一个分支上修一揽子 linter 报错、生成单元测试、适配第三方 API。因为分属不同分支两个 agent 在同一份代码上并行的冲突被降到了最低。2.2 我也给 Cursor 和浏览器版 IDE 留过位置但最后还是放弃不是它们不好。Cursor 的 Tab 补全和 Diff 界面确实丝滑日常在本地用很舒服。但放到服务器场景里它有三个问题一是它本质上是给单机交互设计的多人接入同一项目时体验会乱二是它的扩展系统和命令面板适合人类手动操作不适合脚本化驱动三是资源占用比 CLI 大一个量级在 2G 内存的小服务器上跑会很难受。Continue 这类 VS Code 插件同理它们解决的是“编辑器里的 Copilot”不是“常驻的编码 Agent”。CLI 的好处在于无头部署、tmux 托管、日志重定向、环境变量注入、配置文件完全可复现。这对 Web 化、持久化、多用户共享是最友好的形态。所以 Easy Web Vibecoding 选择了 Claude Code 和 Codex 作为底座而不是再包一层 IDE。3. Easy Web Vibecoding 的搭建全过程从空目录到双 Agent 并行这套东西本质上不复杂核心就三件事让两个 CLI 能跑、让它们常驻在服务器上、让浏览器能接进来。下面按我实际操作过的顺序走一遍。3.1 组件三件套Web 终端、tmux、持久卷我选用的组件非常朴素一台 Linux 服务器2 核 4G 起步Claude Code 和 Codex 都只是远程调 API服务器本身不需要跑模型CPU 主要花在文件索引、git 操作和终端渲染上。Node.js 20 LTS两个 CLI 都是 npm 包Node 版本太老会出现各种诡异的语法报错。ttyd 作为 Web 接入层单二进制、占用低、把 tmux 会话直接映射成浏览器里的终端。想用图形界面的话可以换 code-server但纯编码工作流里 ttyd 更省心。tmux 作为会话托管层负责让进程跨浏览器刷新、断网、重启后都活着。Nginx 或 Caddy 做访问控制套一层 TLS 和密码避免裸端口暴露在公网。目录结构上我会建/workspace作为所有项目的根目录每个项目一个子目录。这个目录就是“持久卷”所有代码、依赖、临时文件都在里面换设备不影响。3.2 从零开始部署完整命令与说明以 Ubuntu 22.04 为例核心命令如下# 1. 安装 Node.js 20 LTS curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt-get install -y nodejs # 2. 安装两个 CLI npm install -g anthropic-ai/claude-code npm install -g openai/codex # 3. 安装 tmux 和 ttyd sudo apt-get install -y tmux sudo apt-get install -y ttyd # 4. 创建工作区 sudo mkdir -p /workspace sudo chown -R $USER:$USER /workspace装完后配置 ttyd 的 systemd 服务让它开机自启、异常退出自动拉起# /etc/systemd/system/ttyd.service [Unit] DescriptionWeb Terminal [Service] Useryouruser ExecStart/usr/bin/ttyd -p 7681 -t titleFixedworkspace tmux new -A -s main Restartalways [Install] WantedBymulti-user.targettmux new -A -s main这行是灵魂-A表示如果名为 main 的会话已经存在就不重复创建直接 attach。这样无论你从哪台设备的浏览器打开看到的都是同一个工作现场而不是一个新空会话。我强烈建议把这一行记下来它比任何伪持久化方案都简单直接。3.3 模型接入配置官方 API 与兼容端点Claude Code 默认读 Anthropic 官方 APICodex 默认读 OpenAI 官方 API。如果你在环境变量里指定了对应的 base URL两个工具都会把它当作更优先的端点去请求。这就是模型接入的核心原理也是对接第三方模型的基础。对中文开发者来说DeepSeek 是注册、充值比较顺滑的 OpenAI 兼容服务之一而且它同时提供了两套兼容端点可以分别接 Claude Code 和 Codex。Claude Code 接 DeepSeek靠的是它兼容 Anthropic 的端点export ANTHROPIC_BASE_URLhttps://api.deepseek.com/anthropic export ANTHROPIC_AUTH_TOKENsk-你的deepseek-key export ANTHROPIC_MODELdeepseek-chatCodex 接 DeepSeek则在~/.codex/config.toml里定义一个自定义模型源model deepseek-chat model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY这里env_key的作用是告诉 Codex去读取名为DEEPSEEK_API_KEY的环境变量作为令牌。这个细节在 5.1 节的报错排查里会再出现。提示兼容端点不是免费午餐。切到第三方模型后Claude Code 里一些依赖官方模型能力的功能比如部分工具调用策略、缓存机制行为和官方不完全一致。我的建议是日常探索用兼容模型省钱重要重构和上线前检查切回官方模型认真跑一遍。3.4 安装阶段最容易翻车的三件事第一npm 全局命令找不到。装完 claude 或 codex 后输入命令提示 not found十有八九是 npm 全局 bin 目录不在 PATH 里。用npm prefix -g查看实际目录再把它加进~/.bashrc就行。第二环境变量残留。我碰到过的最典型场景是某次调试时在.bashrc里把一个指向本机端口的转发变量导了出去之后那个端口上的服务一直没启动结果 claude 和 codex 连 API 全部超时。查了半天才发现是这条残留配置在作怪。排查网络问题时第一步永远是env | grep -i -E http|https|no_proxy看有没有不该存在的东西。第三无浏览器环境下的登录。codex login和claude login默认都要打开浏览器授权。服务器上如果没有图形界面可以用它输出的“一次性验证 URL”在任意设备浏览器里打开确认即可如果连这一步都嫌麻烦就直接用 API key 环境变量绕开交互登录。对我这种多机接入的场景API key 方案反而更省事。4. 两个 Agent 长期共处一室的持久化细节部署只是第一步。真正让这套工作区好用是靠一系列“持久化细节”堆出来的。下面这几个习惯是我用了几个月后觉得最值得保留的。4.1 会话掉线后如何无缝恢复浏览器刷新、网络断开、甚至服务器重启后恢复工作现场的完整链路是三层递进tmux 恢复进程CLI 恢复对话最后靠文件恢复结论。# 第一层tmux 恢复进程进到同一个会话 tmux new -A -s main # 第二层Claude Code 恢复上一次对话 claude --continue # 或者列出所有历史会话手动挑一个 claude --resume # Codex 类似会话 id 会在每次对话结束时打印出来 codex resume session_id这三层里最容易被忽略的是第三层。恢复对话后 agent 虽然记得上下文但它对“你离开之后发生了什么”一无所知。所以我在每个项目根目录放了一个NOTE.md任何一次操作结束都会把当前进度、已验证结论、下一步计划写进去。这相当于给所有恢复机制兜了个底。4.2 目录分工让两个 agent 在同一个仓库里不打架两个 AI 同时写同一个仓库最怕的是互相覆盖。我的做法很简单同一个仓库不同分支。# Claude Code 走业务分支 git checkout -b feature/claude/pay-page # Codex 走另一个分支 git checkout -b feature/codex/ci-fix两个 agent 各自在独立分支上工作冲突至少隔了一个 merge 层处理起来跟普通多人协作一样。同时在仓库根目录维护两份指令文件Claude Code 读CLAUDE.mdCodex 读AGENTS.md。两者内容并不完全一样但最顶部都会写一段“当前正在进行的任务、禁止碰的目录、约定的提交风格”。这相当于给两个 agent 立了块告示牌它们开工第一件事就是读这块牌子。我试过让它们共享同一个分支也试过完全分目录最后发现“分支隔离 指令文件同步”是冲突最小的组合。如果你也打算让多个 agent 并行建议直接按这个模式来。4.3 长会话的上下文管理1M 上下文不是免死金牌很多人看到“1M 上下文”就兴奋觉得可以让 agent 把整个仓库都背下来。我实测下来的感受是大上下文有用但要克制。上下文越长单次请求越慢、费用越高而且模型在中段容易“迷失”反而抓不住最新指令。我的习惯是每个可交付的小功能做完就进 Claude Code 面板执行/compact把几百轮对话压成一段执行摘要换任务时直接/clear。Codex 那边同理它的会话恢复机制虽然方便但我不依赖它记全部历史而是把关键结论落进NOTE.md和代码注释里。真正需要 1M 上下文的时候也有——比如让 Claude Code 对整个代码库做一次架构审计。那种场景我会临时开大窗口审完再切回默认。日常改 bug、补测试默认上下文绰绰有余。5. 我踩过的那几个坑附完整排查链路下面这些问题基本都对应着搜索热词里的高频话题我在搭建 Easy Web Vibecoding 的过程中都亲手踩过。这里不给“一步到位”的答案而是把完整排查思路写出来你照着走一遍基本能自己定位。5.1 codex auth token is unavailable 的全过程排查有一次我改了config.toml之后重启 Codex直接报出auth token is unavailable。当时第一反应是账号掉了但重登了两次都没用。我的排查链路是这样的先看环境变量。echo $DEEPSEEK_API_KEY、echo $OPENAI_API_KEY确认对应 provider 的 key 到底有没有注入到当前 shell。再看配置文件。打开~/.codex/config.toml确认model_provider指向的自定义 provider 里env_key是否和我实际导出的变量名一致。确认会话层。如果你是在 tmux 的多窗口里切换注意每个窗口的 shell 环境可能不同在窗口 A export 的 key窗口 B 里未必存在。我这次的根因是把 provider 从官方切到 DeepSeek 之后env_key指向DEEPSEEK_API_KEY但我在另一个 tmux 窗口里启动 codex那个窗口的 shell 根本没加载这个变量。修起来很简单把 API key 统一写进~/.bashrc新开窗口就会自动带上。提示在无头服务器上API key 这类敏感信息建议集中放在~/.codex/.env或 systemd override 的 Environment 段里不要散落在各个 shell 的临时 export 里否则换个窗口就丢排查起来非常累。5.2 切换模型端点时报错的真正根因用切换器比如 ccswitch 这类工具在多个模型端点之间来回切是我推荐的省事做法但它也带来过一个问题某次把 Codex 切到新 provider 后本地转发服务在处理 codex 的/responses接口时直接挂了Codex 那边立刻报出一串不知所措的错误。我的完整排查过程分四步先确认本地转发服务进程是否还活着。用pgrep -f ccswitch或者直接 curl 本地端口如果服务已经退出问题大概率出在这。重启服务看日志。当时日志里露出了 401说明请求带着旧凭据打到了新端点被对方拒绝了。检查端点路径。Codex 走的是/responsesResponses APIClaude Code 走的是/v1/messages。如果切换器把路径映射错请求会直接落到不存在的路由上。这个可以在日志里看实际 URL。最后更新config.toml里的凭据和env_key让新 provider 真正接管。问题根因本质是本地转发服务拿着旧 provider 的令牌去请求新端点被 401 拒绝后异常退出导致 Codex 侧请求无人接应。修复不算难但如果不按“进程 — 日志 — 路径 — 凭据”这个顺序查很容易在错误的方向上折腾半天。5.3 不同系统上安装与登录的差异我在 Ubuntu 和 Windows 上都折腾过这两个 CLI差异还是挺明显的整理成一张表方便对照现象可能根因处理方式npm 全局命令 not foundbin 目录不在 PATHnpm prefix -g查路径加进 shell 配置codex login 无法完成服务器无浏览器用一次性验证 URL在任意设备完成授权或改用 API key 环境变量文件权限报错工作区目录 owner 不对统一chown给当前用户避免 root 与普通用户互相踩Windows 本机跑 codex 不顺官方优先支持 WSL服务器统一用 LinuxWindows 只当接入端浏览器打开工作区即可这套工作区的好处恰恰在这里不管你本机是 Windows、macOS 还是手机只要浏览器能打开 ttyd 的地址工作环境就是同一套。平台差异只存在于搭建阶段搭完之后反而被抹平了。6. 这块工作区还能怎么往下长搭好、跑顺之后我开始往团队和效率两个方向扩展发现空间比想象中大不少。6.1 从单人工作区变成团队编码间tmux 天然支持双人 attach 同一个会话——你在改同事在看输入实时同步很像早年两个人挤一台机器干活的感觉。配合 ttyd 前置的密码校验把 URL 发给队友就是一间临时对拍室。团队做 code review 的时候我经常直接说“你进来看我把这段跑一遍”比截图拉群高效太多。另一个实用扩展是把终端输出重定向到文件。ttyd 支持把会话内容完整落盘配合 cron 每周归档一次。这样 agent 跑过的每一条命令、每一次输出、每一次报错都留在服务器上。哪天想复盘某个需求是怎么做出来的翻日志比翻聊天记录靠谱得多。6.2 我现在的日常工作流长这样早上打开浏览器进工作区tmux里直接claude -c接着昨天的任务Codex 在另一个窗口跑独立的后台任务比如批量修测试。中午出门用手机看一眼进度。晚上下班前在 git 里过一遍所有改动提交顺手在CLAUDE.md顶部更新当天的工作日志。第二天继续。以前最怕的“换设备丢上下文”问题现在彻底不存在了。我也不再依赖某个特定电脑才能写代码——在哪儿都一样打开浏览器就是我的开发环境。最后分享一个我自己的小习惯我在每个项目的CLAUDE.md最顶部放一段三行工作日志每次结束时把当天结论写进去。第二天无论哪个 agent 接手第一件事就是读这段文字上下文就自然续上了。这比任何会话恢复命令都可靠——agent 会断线文件不会。