1. Vibecoding 最烦的不是代码写得差是上下文说丢就丢如果你和我一样这两年已经习惯了用 Claude Code、Codex 这种 AI 编码终端来写代码大概率也对 Vibecoding 这个词不陌生。Vibecoding 说白了就是顺着 AI 的节奏往下写你负责给方向和边界AI 负责出代码、跑测试、改文件然后你看到结果再继续喊下一句。刚开始用这套流程我确实很爽但真正坐在电脑前一整天之后我感受最深的是一个反直觉的事实vibecoding 最耽误时间的不是 AI 写错了而是上下文说丢就丢。1.1 一次把三小时状态全部冲走的“事故”有次我在 Claude Code 会话里调一个支付回调的幂等问题聊了大概三四十轮。AI 已经帮我把整个调用链捋清楚日志格式、异常分支、甚至哪几个文件要改都已经在上下文里沉淀好了。中途我合上笔记本去吃饭回来发现终端进程被系统清理掉了。重新打开claude它确实还在那个项目目录但一切都回到了初始状态。我试着让它“接着刚才的思路继续”它不是不行而是我把那三十分钟上下文重新描述了一遍之后AI 输出的方案已经和之前产生了明显偏移。这就是 CLI 型 AI 编码工具的硬伤会话状态只活在进程内存里。关闭终端、重启电脑、切换网络真的一切都能归零。代码本身有 git 兜底但当时讨论出来的设计决策、权衡取舍、还没落地的中间方案这些“过程资产”全部跟着进程一起消失了。1.2 CLI 会话天然不持久Codex 也是一样Codex 的 CLI 同样有这个毛病。它和 Claude Code 一样本质是一个交互式 REPL每一轮都在跟模型 /responses 端点对话但对话历史是保存在会话进程内部的。你一旦退出codex再进来就是一个新会话。哪怕你只是在里面跑了两个小小的重构下次也得重新 cue 一遍背景。另外这种本地 CLI 还有一种别扭的边界它和“当前这台机器”强绑定。你在公司电脑上聊了一半的需求回家换成笔记本想继续同一个思路做不到。想给同事看一段完整的排查过程也做不到。你只能把终端内容截图然后让他自己从头跑一遍。这个问题在个人开发者身上还不明显一旦涉及到多人协作、跨设备办公、或者需要把项目状态挂后台持续跑的场景就会非常难受。1M 上下文窗口、再聪明的模型都解决不了这个问题。因为窗口再大它也是跟某个临时会话绑定的窗口关闭一切作废。这也是为什么我会花力气去折腾“持久化工作区”。1.3 “工作区”到底解决什么问题Easy Web Vibecoding 这个项目要解决的就是上面这些事。它本质上是一个跑在浏览器里的 Web AI 编码工作区专门给 Claude Code / Codex 这类工具做外层封装核心就两个字持久化。具体能做什么你可以这么理解把 Claude Code 或 Codex 当后台引擎把聊天界面、会话管理、任务状态全部搬到浏览器里。所有会话记录、关键操作、文件变更痕迹都同步到 Redis你关掉浏览器也好电脑重启也好第二天打开同一个 URL点一下“继续”之前的整个工作现场就回来了。对已经习惯 vibecoding 的人来说它解决的是“断点续跑”的问题对还在观望的新手来说它把 AI 编程从“命令行的临时对话”变成了“有存档的完整工作区”这个概念和玩法会更接近你平时熟悉的 IDE 或项目管理工具。下面我会从架构思路、部署接入、持久化机制到实际排错把整套方案拆开来讲。2. 架构思路Web 壳、CLI 内核、Redis 底座最早我想做这个东西的时候第一个念头是直接写个网页把 Claude Code 的输入框搬到浏览器里不就行了但真正动手才发现这件事没有想象中那么简单。Claude Code 和 Codex 都提供了比较完整的 CLI 交互体验但它们的会话状态不对外暴露成 API你没有办法用两三个接口调用就把它们变成可持久化服务。所以最终我采用了“Web 壳 CLI 内核 Redis 底座”的三层结构。2.1 三层结构里的数据流第一层是浏览器里的 Web UI负责展示会话、历史记录、文件变更、任务状态。这一层可以做得比较轻不需要自己去理解模型上下文它只是用户和 CLI 进程之间的中间人。第二层是 Node 服务端进程它负责拉起和管理 Claude Code / Codex 的子进程把用户在页面上的每一次输入转成 CLI 的标准输入同时捕获 CLI 的标准输出和标准错误。第三层是 Redis 持久化它把所有交互记录、关键事件、恢复所需的 checkpoint 结构存下来。实际跑起来的数据流大概是这样的用户在浏览器输入一条指令Web 端通过 WebSocket 发给 Node 服务服务把指令写进 Claude Code / Codex 子进程的 pty伪终端输入CLI 引擎开始思考、调用工具、输出文本服务捕获输出一边实时推送给浏览器一边把结构化记录写入 Redis这里用 pty 而不是简单的child_process.exec是有原因的。Claude Code 这类 CLI 在非交互环境下会认为自己是流水线模式很多富交互能力会被关闭输出格式也会变化。只有给它一个伪终端它才愿意展示进度、颜色、交互按钮这些完整信息并且能正确处理那些需要确认的指令。2.2 会话在 Redis 里的存取模型先明确一个态度会话不仅是“聊天记录”。聊天记录只是表面真正值钱的是时间里累积起来的任务上下文。所以我在 Redis 里存的不是简单字符串列表而是一套带类型的事件日志。每条会话事件大致长这样{ sessionId: sf_894213, sequence: 1024, role: assistant, type: text, content: 已找到问题所在建议修改 payment_service.go 第 87 行, command: cat payment_service.go | head -100, file_edit: payment_service.go:87, checkpoint: abstract-payment-issue-v3, ts: 1732345678.123 }这个结构的好处是前端拿到它既可以渲染富文本也可以在会话回放时精确定位某个工具调用。工作区服务重启后Redis 可以直接按照 sessionId 和 sequence 顺序把状态推送到新页面你看到的不再是一段黑底白字的终端回放而是一条完整的操作链。Redis 内部我用 Hash 存“会话元信息”用 ZSet 存“带时间戳的事件序列”过期策略打开。这样等于同时享受了 Hash 的 O(1) 读取以及 ZSet 按时间范围切片的能力。2.3 为什么不用 SQLite 或纯文件做持久化有人可能会问你这场景用 SQLite 不也够吗确实够但有几个让我放弃的细节。首先是并发读写的形态。vibecoding 工作区经常会有多个会话同时在跑每个会话都在高频产生事件。SQLite 虽然支持并发但写锁冲突在高频写入时很容易成为瓶颈。Redis 的写性能明显更理想而且它自带 pub/sub节点服务的状态变化可以直接通知到前端不需要自己再实现一套消息推送协议。其次是恢复机制的灵活性。Redis 的所有操作都可以设置 TTL、做集合运算、按分数区间提取我可以很自然地为事件日志做“保留最近 30 天”这类策略SQLite 就要定期自己写清理任务。另外将来如果要跨机器部署、多实例共享同一份状态Redis 的访问方式也要比文件锁和独立 SQLite 数据库简单得多。这里强调一下Redis 在这个项目里承担的是“会话工作区状态存储”不是“唯一数据源”。最终的代码和文档仍然回到 git 和文件系统。也就是说Redis 负责让 AI 会话、工作过程、临时计划可以被重建git 负责让最终代码资产被保存。两者各管一摊不互相替代。3. 部署与接入实操从安装到端点的完整配置闭环聊完架构下面进入动手环节。我按自己实际部署时的顺序来写尽量让每一步都能直接照做。3.1 环境准备与服务端安装机器上先确认 Node.js 版本。这个项目基于 Node 20 以上开发更低版本会遇到部分 WebSocket 库兼容问题。安装完成后直接通过 npm 全局安装node -v npm install -g easy-web/vibecoding装好后初始化工作区目录vibecoding init --workspace ~/vibeworkspace初始化命令会生成一份.easy-web.yaml内容大概是这样的engine: claude redis: host: 127.0.0.1 port: 6379 port: 3000 session_ttl_days: 30这里比较关键的是engine字段。它表示当前默认使用哪个 CLI 引擎可以填claude或codex。同一个工作区可以同时配置两个引擎实际使用时在页面上按会话维度切换。比如要求 Claude Code 做代码主流程要求 Codex 做另一个独立的快速验证两者互不干扰各自有各自的状态。3.2 对接 Claude Code 与 Codex 的登录鉴权引擎本身需要鉴权这个环节最容易让新手懵。我的建议是在启动工作区之前先在命令行里把两个 CLI 都跑通一次。Claude Code 的登录通常在安装后第一次启动时完成它会要求你登录账号或者配置 API Key。登录成功后凭据会缓存在用户目录下的配置文件中。工作区进程启动时继承当前用户的环境变量和配置文件所以你在命令行里能跑通被工作区拉起的子进程通常也能直接复用这份身份。Codex 的逻辑类似要么执行codex login要么直接设置OPENAI_API_KEY环境变量。有一点要注意Codex 的 CLI 对 API Key 的环境变量名比较敏感不同版本可能要求OPENAI_API_KEY还是CODEX_API_KEY。遇到codex auth token is unavailable这类报错第一件事不是重装而是检查你当前 shell 到底有没有把这个变量正确导出。env | grep -i api_key3.3 cc-switch 的端点路由与一键切换实际用的时候我不会永远只连一家官方端点。可能上午用 Claude 的官方服务下午想试试某个开源模型或者想切到一个默认模型以外的供应商。这时候就需要有一层配置切换器。cc-switch 是我在这种场景下常用的工具它可以把不同的模型服务端点以配置的方式管理起来然后用非常简单的方式切换。我比较常遇到的一个报错信息大致是cc-switch 在对 codex endpoint /responses 做本地转发时失败。看到这句话不用慌它描述的是链路上某一环出了问题但没告诉你具体是哪一环。按照下面的顺序排查一般十分钟内能定位检查项操作现象本地端点是否在监听ss -ltnpgrep 我对应用的端口中间层是否正常响应curl -i http://127.0.0.1:端口/v1/models401/404 说明认证或路径配置有问题上游服务是否可达curl -i https://你配置的上游服务地址超时或 403 说明网络或授权有问题模型名是否匹配看 cc-switch 里配置的模型名和 Codex 请求的模型名名字不一致会导致找不到模型我最常栽在最后一栏。给 Codex 配了一个自定义 provider但 provider 里的模型列表是旧的选中的那个模型名并没有被上游服务支持结果就是 /responses 一转发就被上游拒绝。调整模型名之后整个链路立刻恢复。3.4 Codex 接 DeepSeek、Claude Code 调 LMStudio 本地模型除了官方端点这个工作区最常见的两种接入场景一个是 Codex 接 DeepSeek一个是 Claude Code 调用 LMStudio 跑本地模型。这里分别给出可以照抄的配置。Codex 接入 DeepSeek大多数情况下需要你自定义一个 provider。在~/.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启动工作区时确保DEEPSEEK_API_KEY已设置然后 Codex 就会通过自定义 provider 去请求 DeepSeek 的兼容接口。deepseek-chat和deepseek-reasoner我都在跑个人感受是日常改代码用deepseek-chat速度更舒服处理复杂推理问题时切到reasoner更稳一些。Claude Code 调用 LMStudio 本地模型走的是 Anthropic 兼容协议。LMStudio 默认在本地 1234 端口开一个 OpenAI 风格服务但 Claude Code 需要 Anthropic 风格的/v1/messages接口。这时候可以在启动工作区之前设置两个环境变量export ANTHROPIC_BASE_URLhttp://localhost:1234/v1 export ANTHROPIC_AUTH_TOKENnot-needed这两个变量会把 Claude Code 的请求方向指向本地模型服务让 Claude Code 这个壳去驱动本地模型。需要注意本地模型对上下文长度的限制通常比云端模型小工作区里把单次会话的 history 截断阈值调低一些否则请求会直接因为超长被模型拒绝。3.5 让 Web 界面常驻后台服务端不会因为浏览器关掉就退出。我用 systemd 把它注册成常驻服务这样重启机器后工作区自动恢复。一个简化版的服务定义[Unit] DescriptionEasy Web Vibecoding Afterredis.service network-online.target [Service] Userdev WorkingDirectory/home/dev/vibeworkspace ExecStart/usr/bin/vibecoding serve --config /home/dev/vibeworkspace/.easy-web.yaml Restartalways RestartSec5 EnvironmentNODE_ENVproduction [Install] WantedBymulti-user.target浏览器访问方面默认监听本机 3000 端口。如果要在内网其他设备上用建议前面再套一层 HTTPS 反向入口并用环境变量开启鉴权令牌。别直接把 3000 裸奔到局域网否则任何拿到 IP 的人都能打开你的 AI 工作区会话数据不设防是一件非常危险的事情。界面语言我也顺手做成了可配置的中文语言包。因为团队里有些同事对英文终端的动态输出不敏感页面上的按钮、状态提示、会话面板切换成中文之后协作时的沟通成本低很多。这个不是核心功能但在实际落地时很容易成为别人愿不愿意用它的第一道门槛。4. 持久化不是简单“落盘”RDB/AOF 与会话恢复策略“持久化”是这个项目的核心卖点但如果你只是打开 Redis 的默认持久化开关那其实还远远不够。要把“持久化”变成“可恢复”必须同时处理存储、快照、恢复重放这三个层面的问题。4.1 为什么 Redis 持久化了会话仍然会丢如果去年你和我一样对 Redis 的理解停留在“一个高性能内存缓存”那可能你会觉得只要 Redis 开着数据就不会丢。但真实情况是Redis 持久化和“AI 会话可恢复”并不是同一个概念。Redis 持久化保护的是 Redis 自己的数据也就是我上面说的那些事件记录、会话状态。可是 Claude Code / Codex 子进程的业务状态比如当前正在执行的工具链、还没完成的文件修改、已经加载进模型上下文的那几轮对话这些不在 Redis 里。如果你在 AI 正在思考的过程中突然杀死工作区节点进程恢复之后它就只能看到 Redis 里最近一次同步的进度。Redis 还活着但那个没处理完的请求上下文已经没了。所以我的原则是不给“实时状态”做恢复承诺给“最近一个可恢复检查点”做恢复承诺。工作区服务会定期把当前会话的关键上下文压缩成 checkpoint然后连同最近一批事件写入 Redis。下次恢复时把 checkpoint 作为起始上下文而不是逐字逐句重放全部历史。4.2 RDB 与 AOF 的取舍以及我的配置Redis 提供两种持久化机制RDB 和 AOF项目里我两个都开而且建议你也这样做。RDB 是定期生成内存快照恢复速度极快但可能丢失最近几次快照之间的数据。AOF 是追加每一条写命令丢数据少但积累起来文件巨大重启恢复时需要重放全部命令。两者的特点大致是下面这样维度RDB 快照AOF 追加日志数据丢失量最多丢最近一段时间的全部变更最多丢最近一次 fsync 间隔内的变更恢复速度快慢需要逐条重放文件体积紧凑大需要定期重写适合场景冷备份、快速恢复高可靠性、低丢失容忍具体配置我在redis.conf里改了这么几项save 900 1 save 300 10 appendonly yes appendfsync everysec这组配置的意思是有至少一次写入时900 秒后做一次 RDB 快照有至少 10 次写入时300 秒后做一次快照AOF 默认打开并且每秒钟同步一次磁盘。everysec是性能和数据安全之间的一个平衡点极端情况下最多丢一秒的数据对 AI 会话场景完全可接受。如果希望进一步减少重放时间Redis 4.0 以上可以开启 AOF 混合持久化也就是 RDB 开头加 AOF 尾部恢复时先加载 RDB 再补增量。项目里我是直接开着的实测一个几十万条事件的 Redis纯 AOF 模式恢复要稳定 30 秒以上混合模式几秒就搞定。4.3 会话 checkpoint 的落地结构checkpoint 是恢复机制里最重要的概念。它不能简单理解成“把最后几条消息存下来”而是要把能延续对话的压缩结构存下来。我实际使用的 checkpoint 长这样{ sessionId: sf_894213, summary: 用户正在修复支付回调幂等根因是状态表缺少唯一约束已决定改用分布式锁本地状态变更记录, currentGoal: 完成 payment_service.go 第 87 行修改并补单元测试, changedFiles: [payment_service.go, payment_service_test.go], lastCommand: go test ./payment/..., createdAt: 1732345678.123 }恢复时服务会做三件事。第一从 Redis 取出最近的 checkpoint。第二把 checkpoint 里的 summary、currentGoal 和 changedFiles 拼接成一段“背景提要”作为新会话的第一条用户消息投递给 Claude Code / Codex。第三检查这个 session 是否对应一个 git 分支如果有未提交的修改先确认改动状态然后让 AI 在现有工作区继续操作。这样做虽然丢弃了很多历史细枝末节但换来的是恢复后上下文窗口完全干净模型不会被几十轮无关对话拖累。实际用下来恢复后的 AI 行为和服务重启前基本一致因为它真正需要记忆的是目标和当前文件状态不是每一句历史。4.4 备份、日志与运维细节Redis 本身有持久化但我不信任单一副本。项目里我加了一个简单的冷备份策略每小时把/var/lib/redis/dump.rdb复制到工作区目录的backups/文件夹保留最近 24 份再交给云备份工具做异地同步。冷备耗时非常短因为 RDB 文件是压缩快照体积通常不大。日志方面请不要让 Node 服务的输出直接写到/dev/null。vibecoding 工作区天然有海量日志这些日志既是排查问题的第一手资料也是后期做会话分析的数据来源。我建议把工作区节点服务的运行日志和 AI 子进程的原始输出分开存放比如一个server.log一个session/*.log。还有一个小坑Redis 磁盘写满时AOF 的写操作会直接失败表现为整个 AI 工作区看起来还能打开但所有会话事件都无法更新。排查这种问题是先看 Redis 日志再检查磁盘不要一上来就重启服务。这类问题我在项目初期就踩过一次重启之后 Redis 加载不了差点把已经存好的会话状态一起弄丢。5. 实测的一天、翻车记录与后续想法说完了配置和原理这章我想更接地气一些讲一讲完整跑一遍的感受、真实翻车经历以及我后面还在计划优化的地方。5.1 用工作区完整跑一次需求修改有天下午我需要在一个旧仓库里给用户模块增加“手机号校验失败三次后锁定两小时”的逻辑。我没有直接打开终端而是开了浏览器进入工作区新建一个 Codex 会话给它描述需求。整个过程中我故意做了几次“断开连接”的测试。第一次是切到另一个页面让 WebSocket 断开大约五分钟后再回来。恢复后所有历史还在Codex 子进程也没有因此中断因为它挂在节点服务侧并不依赖我浏览器这边。第二次我直接关掉电脑出门办事两个小时后回来打开工作区 UI点了一下继续。Codex 很快就从 checkpoint 接上了它甚至还记得我中途在另一个文件里粘贴过一段日志格式要求。单纯说“记忆好”其实还不够准确。真正有价值的是我在移动端浏览器上也能看到同一个会话的上下文并且能继续追加指令。这种体验是本地 CLI 给不了的。跑完整个需求Codex 改了四个文件我 review 了一遍提交差异整体逻辑没大问题只手动调整了边界条件的判断顺序。整个流程大概花了一个多小时但实际上我用于“重新找回上下文”的时间基本为零。5.2 cc-switch 转发 codex endpoint 失败的排查链路翻车记录里最值得写的是一个 cc-switch 相关的疑难问题。起因是某天我给某个供应商更新了 access token但忘记同步到 cc-switch 的配置文件。启动 Codex 会话后第一轮请求就报错提示 cc-switch 在本地转发 codex endpoint /responses 时失败。我当时没有直接去看那个报错本身而是先列了一个怀疑清单本地监听是否正常、配置文件是否被改坏、上游服务是否真的可用、请求头里带过去的 token 是否过期。第一步ss -ltnp看端口进程在。第二步直接curl那个本地的 codex 端点返回了 401这说明中间层本身活着但认证不通过。第三步用同样的 curl 请求上游结果上游正常返回。这样一排除就锁定了是 cc-switch 配置文件里的 token 没有更新。改完文件重启 cc-switch再跑 Codex问题消失。整个排查链路最怕的就是“看到报错就重启”。cc-switch 本身只是一个转发端点这类工具报错时你重启它一百次也救不回来一个过期 token。把链路拆开分别验证每一段才是效率最高的方式。5.3 账号权限、本地模型时断时续这类摩擦实践里还会有一些不那么技术、但非常影响体验的摩擦。一个是账号权限边界。如果你的账号没有 Claude Code 的订阅访问权限或者被企业策略限制CLI 启动时可能直接报错大意是“你的组织已禁止 Claude 订阅访问”。这通常不是工具问题是账户权限问题反复重装 CLI 没有任何帮助要么找管理员开权限要么换成你自己有调用权限的上游服务。另一个是本地模型时的断连问题。用 LMStudio 这类本地模型跑 Claude Code 时如果模型推理速度特别慢而 HTTP 客户端的超时时间设置得不够大就会看到请求中途断开的假象。解决方法并不是盲目调大超时而是先看本地模型的吞吐量是不是确实在正常输出。如果模型本身已经排队排满了比如同时有多个会话在跑那就需要限制工作区的并发会话数避免本地模型被一次性打爆。5.4 我计划继续做的三个扩展方向最后聊一点个人计划。Easy Web Vibecoding 目前已经能日常使用了但我心里还有几个想继续折腾的方向。第一把每个会话的历史记录自动归档成 Markdown 文件。现在记录都在 Redis 里虽然恢复方便但难以直接搜索。我想每天定时把当天会话压缩成“决策日志”落到工作区目录里方便以后回溯一个需求从讨论到落地全过程。第二给会话增加文件索引。现在 AI 是能改文件但改完之后的文件关系和影响范围没有整合。我希望能自动生成会话和文件的关联图方便在多个并行会话之间看出冲突。第三做一个更灵活的 checkpoint 触发机制。当前是基于事件数量和时间间隔我想改成可配置的策略比如代码保存后、测试跑完后都自动打点让恢复粒度更细。工具永远不可能替你思考但好的工具可以让你不用反复做无效的重复思考。做这个项目的核心体会也正是持久化带来的那种踏实感——AI 编码这件事开始变得可以存档、可以复盘、可以继续。