WebCode：把 AI CLI 变成可协作的 Web 工作台

你有没有遇到过这种情况：在服务器上跑着 Claude Code 处理一个大项目，但 SSH 断线了，所有会话状态全丢；或者团队里五六个人都在用各自的 Claude Code 实例，项目上下文散落在各处，想共享一个会话历史比登天还难。

WebCode 正是为解决这些痛点而生的。

WebCode 主界面

图1：WebCode 主界面 — 所有 AI CLI 会话集中在一个浏览器标签里管理。

一、背景：为什么需要把 CLI 搬上 Web

2024 年下半年，AI 编程工具迎来爆发式增长。Anthropic 的 Claude Code、OpenAI 的 Codex、Google 的 Jules……每一款都声称能让开发者效率翻倍。但这些工具清一色是跑在本地终端的命令行程序，存在三个根本性限制：

第一，网络依赖导致会话管理困难。 Claude Code 需要稳定的网络连接来调用 API，断线意味着上下文中断。而大多数开发者的工作场景并不总是"全程稳定网络"——出差途中、客户现场、网络受限环境，SSH 一断，工作成果说没就没。

第二，本地运行难以团队协作。 传统的 AI 编程工具是单用户工具，你的会话历史在你的机器上，队友看不到，也无法接入。你用 Claude Code 做的代码审查结果，只能截图分享，无法直接共享会话链接。

第三，部署和分发成本高。 想让团队里不懂命令行的同事用上 Claude Code，你需要配置复杂的远程开发环境，或者花大量时间教他们用终端。而 Web 应用几乎是零门槛的解决方案。

WebCode 的作者（shuyu-labs）敏锐地捕捉到了这个需求空白，用 .NET Blazor Server 构建了一个将 AI CLI 能力 Web 化的平台。项目在 GitHub 上迅速获得 279 颗星，并在 trendshift.io 的 AI coding 分类中占据一席之地。

二、核心技术架构

WebCode 基于 Blazor Server + .NET 10 构建，这是一个值得展开讲的技术选择。

Blazor Server 是微软 .NET 生态里的明星框架，它用 SignalR 维护一个持久的 WebSocket 连接，所有 UI 交互都在服务端渲染，客户端只需要接收渲染后的 DOM diff。这意味着：

无需 JavaScript 框架：整个前端用 C# 编写，后端工程师可以无缝上手，不需要学习 React/Vue
会话状态天然在服务端：AI CLI 的运行上下文天然保存在服务端，不会因为客户端网络抖动而丢失
SSR 性能优越：相比 SPA 方案，首屏加载更快，对低配设备友好

项目的核心代码组织如下：

目录	说明
`WebCodeCli/`	Blazor Server 主应用，包含 UI 组件（Components/）、页面（Pages/）、控制器（Controllers/）
`WebCodeCli.Domain/`	核心业务逻辑，AI CLI 适配器层（Service/Adapters/）
`cli/`	各 CLI 工具的接入文档（Claude Code、Codex、OpenCode 等）
`docker/`	Docker 部署脚本和 Codex 配置模板
`installer/`	Windows 安装包发布脚本

适配器模式是架构的核心亮点。Adapters/ 目录下为每款 CLI 工具（Claude Code、Codex、OpenCode 等）各自维护了一个 CliExecutorService.cs，定义统一的执行接口：执行命令、解析输出、管理会话生命周期。这样新增一款 CLI 工具只需要实现适配器，无需改动核心逻辑。

文件管理页面

图2：WebCode 的文件管理页面 — 在浏览器里直接浏览工作区、上传文件、复制路径。

三、核心功能详解

3.1 多 AI CLI 统一接入

WebCode 不绑定单一 AI 工具，而是同时支持 Claude Code、Codex 和 OpenCode 三种主流 CLI 工具。用户在 WebCode 中可以选择当前会话使用哪款 CLI，系统会自动注入对应的环境变量和 API 配置。

以 Claude Code 为例，接入过程非常简洁：只需在 .env 中配置 ANTHROPIC_BASE_URL 和 ANTHROPIC_AUTH_TOKEN，WebCode 就会在后台启动 Claude Code 进程，所有输入输出通过 WebSocket 实时推送到浏览器。

Codex 的接入更复杂一些，因为 Codex CLI 支持沙箱模式和审批策略。WebCode 在 docker/codex-config.toml 中预设了完整的配置模板，支持 CODEX_SANDBOX_MODE、CODEX_APPROVAL_POLICY 等细粒度控制。对于企业场景，审批策略可以设为 suggest（建议确认）或 always（必须审批），让 AI 的代码修改行为在受控范围内。

3.2 会话管理与上下文恢复

传统 CLI 会话的痛点在于：一旦终端关闭，会话上下文就消失在内存里。WebCode 通过两层机制解决这个问题：

第一层：WebSocket 持久化。 Blazor Server 的 SignalR 连接本身就是持久化的，刷新页面或短暂断网不会丢失会话状态。

第二层：外部会话导入。 WebCode 支持导入用户本地已有的 Claude Code/Codex 会话 transcript 文件，恢复完整的对话历史继续使用。这意味着你可以把本地开发了一周的 Claude Code 会话导入到 WebCode，在任何设备上继续工作。

会话管理支持创建、切换、关闭、隔离和清理操作，每个会话可以绑定独立的工作区目录，实现了项目级的上下文隔离。

3.3 多端统一入口

WebCode 支持三类访问入口：

桌面 Web：完整功能，支持文件管理、会话控制、模型切换
移动端：抽屉式界面，支持会话操作、文本和图片消息提交
飞书：会话卡片交互，支持 AI 回复的飞书文档化（AI 回复自动生成飞书在线文档链接，支持手机端音频播放）

这个设计解决了远程办公场景下的一个真实痛点：在地铁上用手机查看 AI 编程进展，或在飞书群里直接把 AI 的分析结论沉淀为团队知识库。

项目管理页面

图3：项目管理页面 — 为每个会话配置独立工作区和项目目录，支持历史会话切换。

四、部署体验：Docker 一键启动

WebCode 的部署体验在同类工具中属于顶级水准。项目提供完整的 Dockerfile（多阶段构建）+ docker-compose.yml，一个 docker-compose up -d 就能把整个系统跑起来。

Dockerfile 的构建流程值得细看：

第一阶段（build）：基于 mcr.azure.cn/dotnet/sdk:10.0，安装 Node.js 20.x，还原 NuGet 包，构建 TailwindCSS，最后 dotnet build + dotnet publish 输出应用
第二阶段（final）：基于 mcr.azure.cn/dotnet/aspnet:10.0，安装 Rust（含科大镜像加速国内下载）、Python3、必要的系统工具，最终交付一个同时包含 .NET 应用和 Claude Code / Codex CLI 的镜像

多阶段构建把构建工具链排除在最终镜像之外，最终产物非常干净。运行时容器内同时跑着 .NET ASP.NET Core 应用（端口 5000）、Claude Code CLI（通过环境变量注入 API Key）和 Codex CLI（带配置文件和沙箱支持）。

docker-compose 中通过 network: host 模式确保容器内的 CLI 工具能正常访问宿主机网络，数据库文件映射到 /app/data/ 持久化存储。

对于 Windows 用户，项目还提供 installer/windows/ 目录下的 NSIS 安装包生成脚本，打包为 WebCode-Setup-vX.Y.Z-win-x64.exe 一键安装。版本号由 Directory.Build.props 管理，更新版本只需修改一个文件。

五、技术栈与代码质量

维度	结论
主语言	C# (.NET 10)
前端框架	Blazor Server（SignalR）
样式	TailwindCSS（npm 构建）
数据库	SQLite（生产可切换 PostgreSQL）
架构模式	每款 CLI 独立 ExecutorService 适配器
容器化	Dockerfile（多阶段）+ docker-compose
测试	`WebCodeCli.Domain.Tests/` 单元测试

代码质量方面，项目采用标准的 .NET 解决方案结构（.sln），模块边界清晰（Domain 与主应用分离），配置管理通过 appsettings.json 和环境变量分层注入。文档质量极高——README 同时提供中英文版本，docs/ 目录下有详尽的部署指南、CLI 配置说明和故障排除文档。不过需要注意的是，项目目前没有自动化的 CI/CD 流水线（没有 GitHub Actions workflow），Windows 安装包的发布依赖手动执行 PowerShell 脚本。

六、使用门槛与适用场景

WebCode 的上手门槛中等偏高，主要用户群体是：

AI 开发者/高级用户：熟悉命令行、了解 API Key 管理、有远程开发需求的程序员。他们会把 WebCode 作为 Claude Code 的"远程控制台"来用，键盘还在手里，只是把交互界面换成了浏览器。

小团队协作场景：团队内有人擅长用 AI CLI，有人在学习阶段。通过 WebCode，资深开发者可以把会话结果分享给团队成员，降低全员学习 AI 编程的门槛。

远程/跨设备工作：在不同机器之间切换时，通过 WebCode 保持会话连贯，无需每次都从零开始。

不太适合的场景：完全没有命令行经验的用户（他们更适合直接用各 AI 厂商的 Web UI）；大规模企业部署（目前没有 LDAP/SSO 集成，多用户权限控制较基础）。

七、行业意义与局限

WebCode 代表了一个有趣的趋势：把 AI 工具从"个人效率软件"升级为"团队协作平台"。它的出现说明 AI 编程工具正在经历从 CLI 向 Web 的范式迁移，类似当年 Git 从命令行走向 GitHub Web 的过程。

主要局限：

Blazor Server 的 SignalR 依赖：需要始终保持 WebSocket 连接，不适合高度间歇性的网络环境
CLI 工具本身的能力边界：WebCode 只是外壳，Claude Code 能做到的事情决定了 WebCode 的上限
飞书集成深度依赖飞书开放平台：功能稳定性受飞书 API 变更影响
多用户权限体系较基础：生产级别企业使用可能需要自行扩展

总结

WebCode 是一款将 AI CLI 工具 Web 化、可协作化、可远程访问的创新平台。它用 .NET Blazor Server 构建了一个优雅的中间层，把 Claude Code、Codex、OpenCode 这些强大的命令行工具包装成团队可共享的 Web 应用。Docker 一键部署、多端统一入口、飞书深度集成，使其在"让团队高效使用 AI 编程工具"这个赛道上具有鲜明特色。如果你或你的团队已经在用 Claude Code 或 Codex，并且有远程协作需求，WebCode 是一个值得认真评估的解决方案。