我用 Codex CLI 造了一个 Claude Code 桌面客户端

从一句「要是有个 GUI 就好了」到 8000 行代码的 Electron 应用


起因

我用 Claude Code 写代码有大半年了。终端里 claude 一敲,确实好用。但每次切项目要重新指定路径、想回顾之前的对话只能翻终端滚动条、想在多个会话之间切换得开好几个终端 Tab —— 体验上总觉得差了点东西。

某个周五下午,我盯着终端里密密麻麻的 stream-json 输出,突然想:

「要不,给它套个壳?」

这个念头本来应该像大多数 side project 一样,在周末过去后自然消散。但这次不一样 —— 我打开了 Codex CLI,开始了一场彻底的 Vibe Coding 之旅。


初见雏形

在这里插入图片描述

Claude Code Desktop 运行截图 —— 左侧会话列表、中间聊天面板、右侧文件浏览器与 Markdown 预览


为什么用 Codex CLI?

市面上有很多 AI 编程工具,我选择 Codex CLI 的原因很简单:

  1. 终端原生 —— 不依赖 IDE,直接在你的项目目录里跑,跟 Claude Code 的使用方式一致
  2. 全流程自主 —— 从读文件、编辑代码、运行测试到 git 提交,它自己搞定
  3. 透明的思考过程 —— 每一步都能看到它在想什么、要改什么、为什么这么改
  4. 零配置 —— 装好就能用,不需要配置 agent、不需要选模型、不需要写 prompt template

在四天的开发中,我几乎没自己写过一行代码。全程通过自然语言跟 Codex CLI 对话,让它理解需求、生成代码、修复 bug、重构架构。


使用人群

Claude Code Desktop 不是为所有人设计的,它有非常明确的用户画像:

核心用户

用户群 使用场景 痛点
AI 重度开发者 每天使用 Claude Code 写代码 4h+ 终端切换会话繁琐、无法回溯对话历史、缺乏可视化工具调用
Vibe Coder 通过 AI 辅助快速原型和迭代 需要同时管理多个上下文(项目),纯终端不够直观
技术写作者 / 学习者 用 AI 辅助学习、写文档、做笔记 需要对照文件浏览器和聊天内容,分屏工作流更高效
开源维护者 多项目并行,频繁切换上下文 项目级会话组织、跨窗口操作、代码审查集成

设计原则

  • 不取代 CLI —— 只是给 CLI 加了一层 GUI,底层还是 claude 命令
  • 本地优先 —— 所有数据存在 SQLite 里,不上传、不分析、不分享
  • 键盘驱动 —— 能用快捷键绝不点鼠标,⌘N 新建、⌘K 搜索、⌘B 切换侧边栏
  • 透明可审计 —— 所有 AI 操作都在右侧面板可见,没有隐藏的自动化

产品设计理念

1. 会话优先(Conversation-First)

绝大多数 AI 编程工具是「文件优先」的 —— 你先打开一个项目,然后在里面跟 AI 对话。Claude Code Desktop 反过来:会话是一等公民

每个会话可以绑定一个项目文件夹,也可以不绑定。会话按项目自动分组,置顶、搜索、重命名、删除 —— 就像你的聊天软件管理对话一样管理你的 AI 编程会话。

2. 两种模式,一个核心

应用提供两种交互模式:

  • Agent 模式:通过 @anthropic-ai/claude-agent-sdk 直接调用 SDK,工具调用可视化,权限审批流,适合全自动工作流
  • Chat 模式:通过子进程启动 CLI,解析 NDJSON 流式输出,适合轻量对话

两种模式共享同一个 SQLite 数据库,你可以在 Agent 模式下开始一个对话,切换到 Chat 模式继续,反之亦然。数据永不丢失。

3. 工具可见性

AI 编程最大的痛点之一是 「不知道它在干什么」。Claude Code Desktop 的右侧面板解决了这个问题:

  • Activity:实时查看 AI 的思考过程和工具调用
  • Files:浏览项目文件,MD 文件支持 Markdown 渲染
  • Terminal:查看 AI 执行的命令和输出
  • Review:审查 AI 的代码变更

每一个工具调用、每一次文件修改、每一行命令输出,都可以在右侧面板实时追踪。

4. 设计美学:精致的工具感

UI 设计参考了 Hermes Desktop 的审美语言:

  • 深色为主,紫色点睛 —— 暗色基底减少视觉疲劳,紫色强调色传递「AI 工具」的品牌感
  • 玻璃质感 —— backdrop-filter: blur(20px) 的毛玻璃效果,让界面有层次感而不沉重
  • 信息密度适中 —— 侧边栏、聊天面板、文件浏览器三栏布局,每栏各司其职
  • 微交互动画 —— 按钮 hover、面板切换、消息出现都有平滑过渡,不突兀
  • SF Pro 字体 —— 原生 macOS 字体渲染,跟系统界面无缝融合

第一天:从零到能跑

Vibe Coding 的第一原则:别想太多,先让它动起来。

我没画架构图,没写 PRD,甚至没想清楚最终要长什么样。直接开了个 Electron + React + TypeScript + Vite 的模板项目,然后开始跟 Codex CLI 对话:

“帮我写一个 Electron 应用,左边是会话列表,右边是聊天窗口,点会话能加载历史消息。”

Codex CLI 噼里啪啦生成了第一版代码。我跑起来一看 —— 丑,但能用。左侧边栏列着会话,右侧是空白的聊天区域。

然后我继续:

“加一个输入框,按 Enter 发送消息,调用 claude CLI 子进程获取回复。”

“消息要流式显示,就像 ChatGPT 那样一个字一个字出来。”

“加 SQLite 持久化,重启不能丢消息。”

“把会话按项目文件夹分组,展开折叠那种。”

每一轮对话,Codex CLI 生成几十到几百行代码,我跑一下,看效果,不满意就回退重来。这种感觉就像在跟一个 7×24 小时在线的、永远不会不耐烦的结对程序员一起工作。


第二天:从能跑到能用

第二天,应用已经能用了。Codex CLI 推荐了 better-sqlite3 做持久化、node-pty 做伪终端、xterm.js 做终端渲染。技术栈越来越丰满了:

Electron 31 + React 18 + TypeScript 5
Vite 5 + Tailwind CSS 3 + Zustand
better-sqlite3 + node-pty + xterm.js
@anthropic-ai/claude-agent-sdk

但那天晚上我几乎全在修 bug。

Codex CLI 生成的代码不是完美的。它经常:

  • 忘记处理异步边界条件(竞态、重入、闭包过期)
  • 生成类型定义但忘了导出
  • 写出优雅的代码但完全不处理错误
  • useEffect 的依赖数组写错导致无限循环

我花了大量时间在调试、看日志、读 Codex CLI 生成的代码、然后指出问题让它修复。这其实是一种新的协作模式:

我负责「知道什么是对的」,AI 负责「怎么实现」。


第三天:Agent SDK 集成

第三天是最有意思的。Anthropic 发布了 @anthropic-ai/claude-agent-sdk,一个可以直接在代码中调用 Claude 的 SDK。

这意味着我可以跳过 CLI 子进程的方式,直接通过 SDK 让 Claude 在应用里运行 —— 工具调用、权限审批、文件修改,全部可以可视化。

我让 Codex CLI 读了 SDK 的文档,然后说:

“集成这个 SDK,取代现有的 CLI 子进程模式,但保留 CLI 模式作为备选。”

Codex CLI 花了大概 20 轮对话,生成了两个模式共存的架构:

  • Agent 模式:通过 SDK 直接调用,支持工具调用可视化和权限审批流
  • Chat 模式:通过子进程启动 CLI,解析 NDJSON 流式输出

两种模式共享同一个 SQLite 数据库,通过 Electron IPC 通信。用户可以在右上角一键切换。


发现的问题:AI 代码的盲区

三天的密集开发后,我让 Codex CLI 做了一个全面的代码审计。结果让我吃了一惊 —— 发现了 26 个 Bug,其中 9 个是高严重度。

一些印象深刻的:

消息重复发送

// 两个 if 同时满足,handleSend 被调用两次
if (e.key === 'Enter' && !e.shiftKey) { handleSend(); }
if (e.key === 'Enter' && (e.metaKey || e.ctrlKey)) { handleSend(); }

Cmd+Enter 在 macOS 上同时触发 EntermetaKey,两条 if 都命中,消息发了两遍。

状态机永久卡死

Codex CLI 设计了一个流式状态机:IDLE → SENDING → THINKING → STREAMING → STOPPED → IDLE。但这个状态机从 ERROR 状态只允许 RESETSEND 事件。如果正常 stream:end 事件到来时状态是 ERRORSTOPPED 事件被忽略,输入框永久禁用。

内容持久化错位

Chat 模式下,Codex CLI 只把 text 类型的 chunk 写入了数据库。thinkingtool_usetool_resultdiff 这些内容在重启后全部丢失。用户重启应用后只能看到半截对话。


第四天:UI 重构

功能稳定后,我开始关心长相。

原来的 UI 是 Codex CLI 用 Tailwind 默认配置生成的 —— 能用,但说不上好看。我决定参考 Hermes Desktop(Nous Research 的桌面客户端)的设计语言,做一次全面的 UI 升级。

改了什么:

  • 设计系统:重新定义了 CSS 变量体系,从颜色到阴影到圆角到动画曲线
  • 玻璃质感:加入了 backdrop-filter: blur(20px) 的毛玻璃效果
  • 骨架屏:用 shimmer 动画替代了简单的 spinner 文字
  • 设置弹窗:从单块布局改为 4 Tab 设计(General / API / Shortcuts / About)
  • 快捷键面板:把所有快捷键列出来,让用户知道 ⌘K 是搜索、⌘B 是切换侧边栏
  • 空状态:每个面板在无数据时显示友好的空状态提示
  • Logo 重设计:从星星图标换成了终端提示符 SVG
  • MD 阅读模式:文件预览支持 Markdown 渲染

CSS 体积从 35KB 增长到 39KB,但视觉上完全是两个世界。


一些数字

  • 项目周期:4 天(其实只有一个周末 + 两个晚上)
  • 代码行数:约 8000 行(TypeScript + CSS)
  • Codex CLI 生成占比:估计 90%+ 的代码由 AI 生成
  • Bug 数量:审计发现 26 个,9 个高严重度
  • 技术栈:Electron 31 + React 18 + TypeScript 5 + Vite 5 + Tailwind CSS 3 + better-sqlite3 + node-pty + @anthropic-ai/claude-agent-sdk

关于 Vibe Coding 的几点思考

1. AI 擅长「写」,不擅长「想」

AI 可以在一分钟内写出 100 行代码,但它不会主动思考「这个状态机有没有死锁路径?」、「这个 IPC 通道需不需要异常处理?」。这些需要人来想。

2. 代码审查从未如此重要

当 90% 的代码来自 AI 时,代码审查不再是「看看有没有 bug」,而是唯一的质量控制手段。每一段 AI 生成的代码都要经过人脑的编译。

3. 架构决策还是得自己来

AI 善于实现,但架构层面它容易:

  • 做出局部最优但全局糟糕的决策
  • 生成过度设计的抽象
  • 忽略非功能需求(性能、安全性、可维护性)

4. Vibe Coding 的门槛并没有降低

很多人以为 AI 写代码 = 人人都是程序员。但我的经验是:Vibe Coding 的能力下限取决于你读代码的能力,而不是写代码的能力。 如果你看不懂 AI 生成的代码,你就无法判断它是对是错,无法修复它,无法改进它。


项目地址

如果你对这个项目感兴趣(或者想看看 Codex CLI 写的 8000 行代码长什么样):

https://github.com/d2025440304-ops/Claude-code-GUI


后记

写这篇文章的时候,我正在用这个 GUI 跟 Claude 对话,让它帮我润色这篇文章的措辞。

Vibe Coding 没有终点,只有下一个迭代。


2026 年 8 月 3 日
Dai

更多推荐