持久化Web AI编码工作区：Claude Code与Codex的会话管理实践

1. 为什么需要一个持久化的 Web AI 编码工作区

1.1 从“终端里跑一下”到“随时打开就能用”的转变

我最早用 Claude Code 和 Codex 这类 AI 编码工具的时候，习惯很简单：打开终端，cd 到项目目录，敲命令，聊几句，改几行代码，关掉。下次再想用，重新来一遍。这个流程在单个项目、单次会话里没什么问题，但只要项目一多、会话一长，麻烦就来了。终端的历史记录是散的，上下文是断的，换个设备或者换台机器，之前聊到一半的编码思路基本找不回来。更别说有时候只是想快速问一句“这个函数改成异步的怎么写”，结果还要先等 CLI 启动、加载配置、确认工作目录，一套流程走完，思路已经凉了。

Easy Web Vibecoding 这个项目要解决的就是这件事。它的核心定位很直接：给 Claude Code 和 Codex 这类 AI 编码工具做一个持久化的 Web 工作区。所谓持久化，不是简单地把终端输出存成日志，而是把整个编码会话的状态——包括项目上下文、对话历史、文件变更记录、工具调用结果——都保留在一个可以随时通过浏览器访问的界面里。你关掉浏览器，明天再打开，之前的工作区还在，对话还在，项目状态还在。这听起来像是一个很小的体验改进，但实际用下来，它改变的是你和 AI 协作编码的节奏。

适合谁来参考这个方案？三类人。第一类是日常用 Claude Code 或 Codex 做主力开发的人，项目多、会话频繁，需要一个统一的管理入口。第二类是在多台设备之间切换的人，比如办公室一台机器、家里一台机器，或者本地开发加远程服务器，Web 工作区天然适合这种场景。第三类是想把 AI 编码能力分享给团队的人，Web 界面比终端更容易让不熟悉命令行的同事上手。如果你只是偶尔用一次 AI 写个脚本，那终端确实够了；但只要你开始把 AI 编码当成日常工作流的一部分，持久化工作区的价值就会立刻显现出来。

1.2 终端模式的三个硬伤

在深入拆解 Easy Web Vibecoding 的设计之前，有必要先把终端模式的问题说清楚。这不是为了贬低 CLI，CLI 有它的优势，启动快、脚本化方便、和本地文件系统零距离。但它在三个场景下确实吃力。

第一个硬伤是会话状态的易失性。Claude Code 和 Codex 的 CLI 会话本质上是一个进程，进程结束，内存里的上下文就没了。虽然有些工具支持--resume或者会话文件，但恢复出来的往往只是对话文本，项目里的文件变更、工具调用的中间结果、当前分支的状态，这些都不在恢复范围内。你恢复了一个对话，但恢复不了一个工作现场。

第二个硬伤是多项目切换的成本。每个项目一个终端窗口，窗口一多就乱。更麻烦的是，不同项目的 Claude Code 配置可能不一样，有的用本地模型，有的走 API，有的有特殊的权限设置。终端模式下，这些配置散落在各个 shell 的启动脚本或者项目目录的配置文件里，没有一个统一的视图。

第三个硬伤是协作和分享的困难。终端输出很难直接分享给同事，截图不完整，复制文本丢格式。如果想让同事看看 AI 是怎么一步步改代码的，终端模式基本做不到。Web 工作区天然解决了这个问题，一个链接或者一个屏幕共享，整个编码过程一目了然。

Easy Web Vibecoding 的设计思路，就是在这三个硬伤上做文章。它没有试图取代 CLI，而是把 CLI 的能力包装成一个持久化的 Web 层。你可以理解为，它在 Claude Code 和 Codex 外面套了一个“工作区外壳”，这个外壳负责保存状态、管理项目、提供 Web 访问入口，而真正的编码能力还是由底层的 AI 工具提供。

1.3 核心关键词在方案中的位置

把热搜词里那些零散的需求串起来看，会发现它们其实都指向同一个方向。claude code安装、codex安装教程、vscode配置claude code这些是入门阶段的搜索，用户还在解决“怎么跑起来”的问题。claude code 调用lmstudio的本地模型、codex接入deepseek、claude code接入deepseek这些是进阶需求，用户想让 AI 编码工具连接不同的模型后端。cc switch local proxy failed while handling codex endpoint /responses、codex auth token is unavailable这些是故障排查，用户在实际使用中遇到了配置和认证问题。claude code桌面版、codex安装桌面版、claude code desktop国内下载这些则反映了用户对图形化、持久化界面的明确需求。

Easy Web Vibecoding 恰好落在最后这一类需求上。它不解决模型接入的问题，也不解决安装问题，它解决的是“装好之后怎么用得舒服”的问题。持久化 Web 工作区把安装、配置、模型接入这些底层细节屏蔽掉，让用户通过浏览器就能管理多个 Claude Code 和 Codex 会话。对于已经跨过安装门槛、开始日常使用的人来说，这是从“能用”到“好用”的关键一步。

2. 工作区的整体架构与核心模块拆解

2.1 三层结构：前端工作区、会话管理层、AI 工具适配层

Easy Web Vibecoding 的架构可以拆成三层来看，每一层的职责边界很清楚。

最上面是前端工作区，也就是你在浏览器里看到的界面。它负责展示项目列表、对话历史、文件树、代码 diff、终端输出这些内容。前端不直接和 Claude Code 或 Codex 通信，它只和中间层打交道。这样做的好处是前端可以做得比较轻，换一套 UI 框架不影响底层逻辑。

中间是会话管理层，这是整个项目的核心。它维护每个工作区的状态，包括当前打开的项目路径、活跃的 AI 会话、历史对话记录、文件变更快照。会话管理层还负责生命周期管理，比如一个会话空闲多久之后挂起、挂起之后怎么恢复、多个会话之间怎么隔离资源。这一层通常会用一个小型数据库或者结构化文件来持久化状态，SQLite 是比较常见的选择，因为单文件、零配置、够用。

最下面是AI 工具适配层，它封装了 Claude Code 和 Codex 的调用细节。Claude Code 和 Codex 虽然都是 AI 编码工具，但它们的调用方式、输出格式、配置参数并不完全一样。适配层的作用就是把这些差异抹平，对上提供统一的接口。比如“发送一条消息给 AI 并获取回复”这个操作，在适配层里是一个方法，但底层可能分别调用 Claude Code 的某个命令和 Codex 的某个接口。

这三层之间的通信方式，常见的有两种。一种是前端通过 HTTP 或 WebSocket 和会话管理层通信，会话管理层再通过子进程或者本地 socket 和 AI 工具通信。另一种是把会话管理层和适配层合并成一个本地服务，前端直接和这个服务通信。Easy Web Vibecoding 更接近后者，因为它的定位是一个“工作区”，而不是一个分布式系统，本地单服务的形式更简单、更可靠。

2.2 持久化到底存了什么

“持久化”这个词在这个项目里不是虚的，它具体存了四类东西。

第一类是工作区元数据。每个工作区对应一个项目目录，元数据里记录了项目路径、创建时间、最后活跃时间、使用的 AI 工具类型（Claude Code 还是 Codex）、模型配置的引用。这些信息决定了你打开一个工作区时，系统知道该去哪里找项目、该用哪个 AI 工具、该加载哪套配置。

第二类是对话历史。这包括用户发的每一条消息、AI 的每一条回复、工具调用的请求和结果。对话历史不是简单的一串文本，它是有结构的。每条消息有角色（用户/AI/工具）、有时间戳、有对应的会话 ID。这样前端才能正确地渲染出对话流，也才能支持搜索和回溯。

第三类是文件变更快照。AI 编码工具在会话过程中会修改文件，这些修改需要被记录下来。快照不一定是完整文件副本，更常见的做法是记录 diff 或者变更前后的哈希值。这样既能追溯“AI 到底改了什么”，又不会让存储膨胀得太快。对于需要回滚的场景，快照就是救命稻草。

第四类是工具调用日志。Claude Code 和 Codex 在执行任务时会调用各种工具，比如读文件、写文件、执行命令、搜索代码。这些调用的输入输出日志被保存下来，一方面用于排查问题，另一方面也用于审计和复现。比如你发现 AI 某一步做错了，翻出工具调用日志，就能看到它当时读到的文件内容是什么、执行的命令返回了什么。

这四类数据的存在，让工作区真正做到了“关掉再打开，一切还在”。终端模式下，这些数据要么不存在，要么散落在各处；Web 工作区把它们集中管理，这是体验差异的根本来源。

2.3 为什么选择 Web 而不是桌面应用

这里有一个很自然的问题：既然要做持久化工作区，为什么不做成桌面应用，而是做成 Web？桌面应用不是更贴近本地文件系统吗？

这个选择背后有几个实际考量。第一，跨平台成本。Web 天然跨平台，Windows、macOS、Linux 上只要有浏览器就能用。桌面应用要为每个平台单独打包，还要处理不同平台的路径、权限、依赖问题。对于个人项目或者小团队项目来说，Web 的维护成本低得多。

第二，远程访问的便利性。Web 工作区可以部署在本地，也可以部署在一台常开的机器上，然后从其他设备通过浏览器访问。比如你把工作区跑在家里的迷你主机上，在公司用笔记本浏览器就能继续之前的编码会话。桌面应用要做到这一点，需要额外做远程桌面或者同步机制，复杂得多。

第三，和现有工具的集成。Web 界面更容易和 VS Code 的 Web 版、代码托管平台的 Web 界面、在线文档工具集成。你可以在工作区里直接嵌入一个 Web 版的编辑器，或者把对话记录导出成 Markdown 贴到文档里。桌面应用在这方面受限较多。

当然，Web 方案也有代价。最大的代价是文件系统访问。浏览器不能直接读写本地文件，所以必须有一个本地服务在中间做代理。这个本地服务就是前面说的会话管理层。它跑在用户机器上，监听一个本地端口，前端通过这个端口和它通信。这个架构决定了 Easy Web Vibecoding 的部署方式：先启动本地服务，再打开浏览器访问。

提示：本地服务监听的端口建议不要暴露到公网，只绑定 127.0.0.1。如果确实需要远程访问，走一层反向代理并加上认证，不要直接把服务端口开放出去。

2.4 与 Claude Code、Codex 的对接方式

适配层怎么和 Claude Code、Codex 对接，是这个项目里最需要仔细处理的部分。Claude Code 和 Codex 都提供了 CLI 形式的调用入口，适配层最直接的做法就是通过子进程调用这些 CLI，然后解析输出。

以 Claude Code 为例，它支持非交互式的调用方式，你可以把一条指令传进去，它执行完输出结果。适配层需要做的是：构造正确的命令行参数、管理子进程的生命周期、捕获标准输出和标准错误、解析输出中的结构化信息（比如工具调用、文件变更）。Codex 类似，但参数格式和输出格式可能不同，适配层要分别处理。

这里有一个关键设计决策：是每次消息都启动一个新的子进程，还是维持一个长驻的会话进程。每次启动新进程的优点是隔离性好，一个会话崩了不影响其他会话；缺点是启动开销大，而且上下文需要每次重新加载。长驻进程的优点是响应快、上下文连续；缺点是进程管理复杂，一个进程卡死可能影响整个工作区。

Easy Web Vibecoding 更倾向于长驻会话进程的方案，因为持久化工作区的核心价值就是上下文连续。如果每次消息都重启进程，那和终端里手动敲命令没什么区别。长驻进程配合会话管理层的心跳检测和超时重启机制，可以在保持连续性的同时控制风险。

另一个决策点是输出解析的粒度。Claude Code 和 Codex 的输出里既有自然语言，也有结构化的工具调用信息。如果只把自然语言展示给用户，那工具调用的细节就丢了；如果全部原样展示，界面又会很乱。常见的做法是分层展示：默认只显示自然语言和关键的工具调用摘要，用户点击展开可以看到完整的工具调用详情。这样既保持了界面的清爽，又保留了排查问题所需的信息。

3. 从零搭建一个持久化 Web 工作区的实操路径

3.1 环境准备与依赖选择

动手搭建之前，先把环境理清楚。这个项目本质上是一个本地 Web 服务，所以需要的东西不多：一个运行时环境、一个 Web 框架、一个持久化存储、以及 Claude Code 和 Codex 本身的 CLI。

运行时环境我推荐 Node.js 或者 Python。Node.js 的优势是和前端同语言，前后端可以共享一些类型定义；Python 的优势是子进程管理和文本处理比较顺手。两者都可以，看你更熟悉哪个。如果选 Node.js，建议用 LTS 版本，避免用最新的实验性版本，因为子进程管理和文件监听这些功能在不同版本之间偶有行为差异。

Web 框架方面，Express（Node.js）或者 FastAPI（Python）都够用。这个项目的接口不复杂，主要是 REST 加一个 WebSocket 用于实时推送对话流。不需要上重型框架，轻量级的选择反而更容易调试。

持久化存储用 SQLite 最合适。单文件、零配置、支持事务，对于工作区这种读多写少的场景完全够用。如果你不想引入数据库依赖，用结构化的 JSON 文件加文件锁也能做，但并发写入的时候容易出问题，SQLite 更稳妥。

Claude Code 和 Codex 的 CLI 需要提前装好并确认能正常运行。这一步很关键，因为适配层是建立在 CLI 能正常工作的前提上的。如果 CLI 本身有问题，比如认证失败、模型不可用，工作区层面再怎么处理也没用。建议先在终端里手动跑通一次完整的编码会话，确认 Claude Code 或 Codex 能正常读写文件、执行命令，然后再开始搭工作区。

注意：Claude Code 和 Codex 的 CLI 版本更新比较频繁，适配层的参数构造和输出解析可能会因为版本变化而失效。建议在适配层里加一个版本检测，把支持的 CLI 版本范围写清楚，遇到不支持的版本时给出明确提示，而不是静默失败。

3.2 会话管理层的核心数据结构

会话管理层是整个项目的骨架，它的数据结构设计决定了后续功能的扩展性。我建议从三个核心表开始设计。

第一个表是workspaces，记录工作区的基本信息。字段包括：id（主键）、name（工作区名称）、project_path（项目目录的绝对路径）、tool_type（claude_code 或 codex）、model_config（模型配置的 JSON 字符串）、created_at、last_active_at。这个表的数据量很小，但它是所有其他数据的入口。

第二个表是sessions，记录会话信息。一个工作区可以有多个会话，比如你可以在同一个项目里开多个对话，分别处理不同的任务。字段包括：id、workspace_id（外键）、title（会话标题，可以从第一条消息自动生成）、status（active / suspended / archived）、created_at、updated_at。会话状态的设计很重要，它决定了资源怎么分配。active 的会话保持子进程运行，suspended 的会话释放子进程但保留数据，archived 的会话只保留数据不参与任何计算。

第三个表是messages，记录对话消息。字段包括：id、session_id（外键）、role（user / assistant / tool）、content（消息内容）、tool_calls（工具调用的 JSON 数组，可选）、created_at。这个表的数据量会随着使用增长，需要加索引。常用的查询是“按 session_id 取最近 N 条消息”，所以(session_id, created_at)的联合索引是必要的。

除了这三个核心表，还可以加一个file_snapshots表来记录文件变更。字段包括：id、session_id、file_path、change_type（create / modify / delete）、diff_content、created_at。这个表让“AI 改了什么”变得可追溯。

数据结构设计好之后，会话管理层的逻辑就清晰了：收到前端请求，根据 workspace_id 找到对应的工作区和会话，把消息写入 messages 表，然后通过适配层调用 AI 工具，把返回结果也写入 messages 表，最后通过 WebSocket 推送给前端。整个过程是同步的，但 AI 调用可能是异步的，所以需要处理好异步回调和超时。

3.3 适配层的参数构造与输出解析

适配层是连接会话管理层和 AI CLI 的桥梁，它的核心工作是两件事：构造正确的调用参数，解析返回的输出。

先看参数构造。以 Claude Code 为例，非交互式调用通常需要指定几个东西：工作目录、要执行的指令、模型选择、权限模式。工作目录决定了 AI 能看到哪些文件，这个必须和 workspace 的 project_path 一致。指令就是用户输入的消息。模型选择可以从 workspace 的 model_config 里读取。权限模式决定了 AI 能不能自动执行命令、能不能写文件，这个需要根据用户的安全偏好来设置。

参数构造里最容易出问题的是转义和引号处理。用户的消息里可能包含引号、换行、特殊字符，如果直接拼接到命令行里，很容易出错。稳妥的做法是用参数数组的形式传递，而不是拼接字符串。比如在 Node.js 里用spawn而不是exec，把参数作为数组传进去，让运行时处理转义。

再看输出解析。Claude Code 和 Codex 的输出格式不完全一样，但通常都包含几类信息：自然语言回复、工具调用记录、文件变更摘要、错误信息。解析的目标是把这些信息分离出来，分别存储和展示。

自然语言回复直接作为 assistant 消息的内容。工具调用记录需要解析成结构化的 JSON，存到 messages 表的 tool_calls 字段。文件变更摘要可以结合 file_snapshots 表来验证，比如 AI 说它修改了某个文件，你可以检查文件的实际修改时间是否匹配。错误信息需要单独标记，前端要能高亮显示，方便用户快速定位问题。

解析过程中最常见的坑是输出格式不稳定。AI 工具的输出有时候会包含额外的日志、警告、进度条，这些内容会干扰解析。我的经验是，不要试图用正则去匹配所有情况，而是先按行分割，找到明确的标记行（比如工具调用的开始和结束标记），然后按标记分段解析。对于无法解析的行，归入“原始输出”类别，原样展示，不要丢弃。

3.4 前端工作区的关键交互设计

前端工作区是用户直接接触的部分，它的交互设计决定了这个工具好不好用。有几个关键点需要仔细考虑。

第一个是工作区列表和会话列表的层级关系。用户打开页面，首先看到的是工作区列表，每个工作区显示项目名称、最后活跃时间、当前状态。点击一个工作区，进入会话列表，显示这个工作区下的所有会话。点击一个会话，进入对话界面。这个三层结构清晰，但要注意导航的便捷性，用户应该能随时切换工作区，而不是一层层退回去。

第二个是对话界面的实时性。AI 的回复是流式的，前端需要实时显示。WebSocket 是必须的，轮询会有延迟。流式显示的时候要注意处理 Markdown 渲染，因为 AI 的回复里经常包含代码块、列表、表格。建议用成熟的 Markdown 渲染库，并且在流式更新时做节流，避免频繁重渲染导致卡顿。

第三个是文件变更的可视化。AI 修改了文件之后，用户需要直观地看到改了什么。一个常见的做法是在对话流里嵌入 diff 视图，显示修改前后的对比。diff 视图要支持折叠，因为有时候变更很大，全部展开会淹没对话内容。另外，diff 视图应该和文件树联动，点击 diff 里的文件名可以跳转到文件树对应位置。

第四个是工具调用的展示粒度。前面提到过，工具调用的细节默认折叠，只显示摘要。摘要的格式可以是“读取了 src/utils.ts”、“执行了 npm test”、“修改了 3 个文件”。用户点击摘要可以展开看到完整的输入输出。这个设计在信息量和界面清爽之间取得了平衡。

提示：前端的状态管理建议用一个轻量的方案，比如 Zustand 或者 Pinia。不要用 Redux 这种重方案，工作区的状态虽然多，但结构清晰，轻量方案足够，而且调试起来更直观。

3.5 启动流程与日常使用节奏

搭好之后，日常的使用流程大概是这样的。首先启动本地服务，通常是一条命令，比如npm run start或者python server.py。服务启动后会监听一个本地端口，比如 3000 或者 8000。然后打开浏览器访问这个端口，看到工作区列表。

第一次使用需要创建一个工作区，指定项目目录和 AI 工具类型。创建之后，工作区会初始化，加载项目文件树，建立和 AI CLI 的连接。这个过程可能需要几秒钟，取决于项目大小和 CLI 启动速度。

之后就可以在对话界面里输入消息，和 AI 协作编码了。AI 的回复会实时显示，工具调用会以摘要形式展示，文件变更会以 diff 形式展示。你可以随时切换会话，或者回到工作区列表创建新的工作区。

关闭浏览器不会影响工作区的状态，因为状态存在本地服务的数据库里。下次打开浏览器，之前的工作区和会话都还在。如果本地服务也关掉了，重新启动服务后，状态依然能恢复，因为数据是持久化的。

这个流程和终端模式最大的区别是节奏感。终端模式下，你每次都要重新进入状态；Web 工作区模式下，你打开浏览器就回到了之前的工作现场，思路是连续的。这个差异在长时间、多任务的开发场景里非常明显。

4. 实际使用中容易踩的坑与排查思路

4.1 会话恢复失败：状态在但进程没了

这是最常见的问题。你关掉浏览器，第二天打开，发现工作区和会话都在，但发消息没反应。原因通常是本地服务重启了，或者 AI CLI 的子进程因为超时被回收了，但会话状态还标记为 active。

排查思路是这样的。先看本地服务的日志，确认服务本身是否正常运行。如果服务正常，再看会话的 status 字段，如果还是 active 但子进程已经不存在，说明状态和实际不一致。解决方法是加一个健康检查机制，服务启动时扫描所有 active 会话，检查对应的子进程是否存活，不存活的就标记为 suspended，并在前端提示用户“会话已挂起，点击恢复”。

恢复的逻辑是重新启动子进程，并从数据库里加载最近的对话历史作为上下文。这里要注意，不是所有 AI CLI 都支持从历史恢复上下文。有些工具需要你把历史对话重新喂给它，有些工具支持会话 ID 恢复。适配层需要根据工具类型分别处理。如果工具不支持恢复，那就只能重新开始一个会话，但保留历史记录供参考。

注意：会话恢复时不要一次性把全部历史都加载进去，那样上下文会太长，既慢又可能超出模型的上下文窗口。建议只加载最近 N 条消息，N 根据模型的上下文窗口大小来定，一般 20 到 50 条比较合适。

4.2 工具调用卡住：超时与死锁的处理

AI 编码工具在执行某些操作时可能会卡住，比如执行一个需要交互的命令、等待一个永远不会返回的网络请求、或者陷入死循环。表现出来就是对话界面一直显示“正在执行”，没有后续输出。

处理这个问题需要两层机制。第一层是超时。适配层在调用 AI CLI 时设置一个合理的超时时间，比如 5 分钟。超时后强制终止子进程，把会话标记为异常，并在前端显示错误信息。超时时间不能太短，因为有些代码生成任务确实需要几分钟；也不能太长，否则用户会一直等。

第二层是心跳检测。对于长驻会话进程，会话管理层定期发送心跳，如果连续几次心跳没有响应，就认为进程已经卡死，主动重启。心跳间隔可以设为 30 秒，连续 3 次无响应就触发重启。

还有一个特殊情况是工具调用死锁。比如 AI 调用了某个工具，工具又在等待 AI 的输入，形成循环等待。这种情况比较少见，但一旦发生，超时机制也能兜底。关键是超时后的错误信息要足够清晰，让用户知道是哪个工具调用出了问题，而不是笼统的“执行失败”。

4.3 文件变更冲突：AI 改了我也改了

持久化工作区的一个副作用是，AI 的会话可能持续很长时间，期间你可能也在用其他编辑器修改同一个项目。当 AI 再次修改文件时，就可能覆盖你的改动，或者产生冲突。

避免这个问题有几个做法。第一，在 AI 修改文件之前，检查文件的最后修改时间是否和会话记录的一致。如果不一致，说明文件被外部修改过，此时应该暂停 AI 的操作，提示用户确认。第二，对于关键文件，可以在修改前自动创建备份，备份文件放在一个隐藏目录里，出问题时可以恢复。第三，在文件变更快照里记录变更的来源（AI 还是用户），这样追溯的时候能分清责任。

实际使用中，我建议养成一个习惯：当 AI 会话处于活跃状态时，尽量不要用其他编辑器直接修改同一个项目里的文件。如果必须修改，先在会话里告诉 AI“我要手动改一下某个文件”，让 AI 知道这个变更，避免它基于旧的文件内容做决策。

4.4 常见问题速查表

4.5 几个我踩过的坑和对应的经验

第一个坑是过早优化存储。一开始我想把每次工具调用的完整输出都存下来，结果数据库膨胀得很快，查询也变慢。后来改成只存摘要和关键字段，完整输出写到单独的文件里，按需读取。这个改动让数据库保持轻量，查询速度明显提升。

第二个坑是忽略 CLI 的版本差异。Claude Code 和 Codex 的 CLI 在不同版本之间参数格式有变化，我一开始没做版本检测，结果用户升级 CLI 之后适配层直接报错。后来加了版本检测和兼容层，对不同版本用不同的参数构造逻辑，问题就少了。

第三个坑是前端状态和实际状态不一致。前端显示会话是 active，但后端子进程已经挂了。这种不一致会让用户困惑。解决办法是前端定期向后端拉取会话的真实状态，而不是只依赖 WebSocket 推送。WebSocket 推送可能丢失，轮询虽然笨但可靠。

第四个坑是没有处理并发写入。多个会话同时写数据库的时候，偶尔会出现锁等待。SQLite 默认的锁模式在并发写入时表现一般，后来改成了 WAL 模式，并发性能好了很多。如果你的工作区会有多个会话同时活跃，WAL 模式是必须的。

5. 这个工作区还能怎么扩展

5.1 多模型后端的统一接入

现在的工作区主要对接 Claude Code 和 Codex，但热搜词里能看到很多用户想接入其他模型，比如本地模型、DeepSeek 等。扩展的方向是在适配层之上再加一层模型抽象层，把“AI 编码工具”和“模型后端”解耦。

具体做法是，适配层不再直接绑定 Claude Code 或 Codex，而是绑定一个统一的“编码代理”接口。这个接口定义了发送消息、接收回复、执行工具这些操作。不同的模型后端实现这个接口，工作区层面不关心底层用的是哪个模型。这样用户就可以在工作区配置里选择模型后端，比如“Claude Code + 本地模型”或者“Codex + DeepSeek”。

这个扩展的难点在于不同模型后端的工具调用能力不一样。有些模型支持函数调用，有些只支持文本生成。适配层需要处理这种差异，对于不支持工具调用的模型，可能需要用提示词工程来模拟工具调用，或者降级为纯对话模式。

5.2 团队协作与权限管理

个人使用的工作区和团队使用的工作区，需求差别很大。团队场景下，需要权限管理、需要操作审计、需要多人同时访问同一个工作区。

权限管理可以分角色：管理员可以创建工作区、配置模型、管理成员；开发者可以在工作区里进行编码会话；观察者只能查看对话和文件变更，不能发消息。操作审计则是把每个用户的操作都记录下来，包括创建会话、发送消息、恢复会话、删除工作区。这些记录对于排查问题和合规审查都有用。

多人同时访问同一个工作区，需要处理并发问题。最简单的做法是同一时间只允许一个人操作，其他人只读。更复杂的做法是支持多人同时对话，但需要处理消息顺序和冲突。这个复杂度比较高，建议先从只读共享开始，逐步演进。

5.3 与代码托管平台的集成

工作区里的编码会话最终要落到代码上，所以和代码托管平台的集成是很自然的需求。集成的方向有几个：会话结束后自动创建分支和提交、把对话记录作为提交信息的一部分、在代码托管平台的 Web 界面里嵌入工作区入口。

自动创建分支和提交这个功能，需要在会话结束时收集所有文件变更，生成一个提交。提交信息可以从对话历史里自动生成，比如提取用户和 AI 讨论的关键点。这个功能能省去手动提交的麻烦，但要注意不要自动推送到主分支，应该创建一个新分支，让用户确认后再合并。

在代码托管平台的 Web 界面里嵌入工作区入口，需要工作区支持被嵌入。这涉及到跨域和认证的问题，实现起来比本地使用复杂。一个折中方案是提供一个分享链接，链接里包含会话的只读视图，同事打开链接就能看到对话和变更，但不能操作。

5.4 离线优先与本地模型

持久化工作区的一个天然优势是适合离线场景。如果模型后端是本地模型，整个工作区可以完全离线运行，不依赖任何外部服务。这对于网络不稳定或者对数据隐私有要求的场景很有价值。

离线优先的设计要点是：所有状态都存在本地，所有计算都在本地完成，网络只用于可选的同步和分享。本地模型的接入需要适配层支持本地推理接口，比如常见的本地模型服务提供的 HTTP 接口。工作区层面不需要关心模型是本地还是远程，只需要知道接口地址和调用方式。

本地模型的性能是瓶颈。本地推理速度通常比远程 API 慢，所以工作区的交互设计要适应这个特点。比如，流式输出要做得更细粒度，让用户看到进度；工具调用的超时时间要设得更长；对于耗时的操作，要提供后台执行和通知机制。

5.5 我个人的使用体会

用了一段时间之后，我最大的感受是，持久化工作区改变的不只是工具，而是工作方式。以前用终端跑 AI 编码，每次都是“开一个会话，解决一个问题，关掉”。现在有了工作区，我会同时维护几个长期会话，一个处理主项目的功能开发，一个处理零散的脚本任务，一个用来探索新技术。这些会话各自独立，但都在同一个工作区里，切换成本很低。

另一个体会是，持久化让 AI 编码从“一次性工具”变成了“持续协作伙伴”。因为上下文是连续的，AI 能记住之前讨论过的设计决策、代码风格、项目约束。你不需要每次重新解释背景，AI 的回复质量会随着会话的深入而提升。这个体验在终端模式下很难获得，因为终端会话的生命周期太短。

当然，持久化也带来了新的管理成本。会话多了之后，需要定期清理不再需要的会话，否则数据库会越来越大。我的做法是给会话加标签，比如“进行中”、“待整理”、“已归档”，定期把已归档的会话导出成 Markdown 然后从数据库里删除。这样既保留了记录，又控制了数据库大小。

最后分享一个小技巧：工作区的项目路径不要直接指向生产环境的代码目录，而是指向一个克隆出来的开发目录。这样即使 AI 误操作，也不会影响生产代码。等 AI 的变更确认无误后，再手动合并到主目录。这个习惯能避免很多意外，尤其是在 AI 权限设置比较宽松的时候。