“先生不应该专教书，他的责任是教人做人；学生不应该专读书，他的责任是学习人生之道。”。——陶行知

https://github.com/pingdotgg/t3code

T3 Code：把编码代理请进一个极简 GUI 里

有些工具一上来就想做“大而全”，恨不得把编辑器、协作、部署、面板、插件市场一股脑全塞进来。T3 Code 给人的感觉却完全不同——它先把姿态压低，只做一件很明确的事：给编码代理提供一个极简的 Web GUI。

这份克制反而很醒目。因为在“AI 编码工具”越来越热闹的今天，越是复杂，越容易失焦；而 T3 Code 选择的，是一个更直接的切口：先把代理接进来，让界面变成入口，让使用者尽快开工。

项目地址：https://github.com/pingdotgg/t3code

它是什么，README 开头就说得很坦白

README 的第一句非常简洁：

T3 Code is a minimal web GUI for coding agents

这句话已经把项目的身份交代得很清楚了。它不是一个泛化的“AI 平台”，也不是一个试图重新定义开发流程的全家桶，而是一个面向编码代理的极简 Web 图形界面。

而且，README 紧接着还给出了当前支持的对象：

  • Codex
  • Claude
  • Cursor
  • OpenCode

同时还补了一句：more coming soon。这说明它并没有把自己绑定在某一个单一代理生态上，而是在尝试成为一个多提供方的接入界面。

它最讨喜的一点，是先让你能用，再谈别的

README 的安装部分写得很务实。它没有绕很多概念，而是先提醒一个前提：在使用之前，至少需要安装并认证一个 provider。

对应方式分别是：

  • Codex：安装 Codex CLI，并运行 codex login
  • Claude：安装 Claude Code，并运行 claude auth login
  • Cursor：安装 Cursor CLI，并运行 cursor-agent login
  • OpenCode：安装 OpenCode，并运行 opencode auth login

这个要求本身并不复杂，但它很重要，因为它清楚表明了 T3 Code 的角色：它是一个 GUI 层，不是这些 provider 的替代品。换句话说，它依赖底层代理工具已经准备就绪，然后把它们组织进一个更统一、更容易使用的界面中。

最快的开始方式，就像顺手敲下一条命令

README 给出的最直接方式是：

1
npx t3@latest

这是一种非常轻快的入口。你不需要先经历冗长的本地安装流程，也不需要一开始就理解很多内部结构。先跑起来，再决定要不要深入，这本身就很符合“minimal”这两个字的气质。

README 还专门提示：

1
npx t3@latest --help

可以查看完整 CLI reference。

这种安排很聪明：先把主路径压缩到最短，把进阶说明交给 --help，避免第一次接触时信息量过大。

如果你更喜欢桌面分发方式，它也准备好了

除了直接运行，README 还给出了桌面应用的安装方式。可以从 GitHub Releases 获取最新版本，也可以通过熟悉的包管理渠道安装。

Windows

1
winget install T3Tools.T3Code

macOS

1
brew install --cask t3-code

Arch Linux

1
yay -S t3code-bin

这组信息很有意思，因为它说明 T3 Code 虽然把自己定义成一个 minimal web GUI，但在分发方式上并不单一。既可以走临时启动的 npx 路线，也可以走更接近“日常软件安装”的桌面路径。对于不同使用习惯的人来说，这种选择空间很实用。

这个项目现在还很早，它没有掩饰这一点

README 里有一句很直白的话：

We are very very early in this project. Expect bugs.

这句表态很朴素，但也很真诚。它没有把项目包装成已经完全稳定、边角全部打磨过的成品，而是直接告诉你：它还处在很早期的阶段，遇到 bug 不奇怪。

另一句也同样鲜明：

We are not accepting contributions yet.

这说明项目当前虽然公开，但并没有把外部贡献入口彻底打开。它选择先把自己的节奏掌握在团队手里。

这两句放在一起，反而让整个 README 更有可信度。因为它没有急着制造一种“万事俱备”的幻觉，而是清楚划出了当前阶段的边界：项目已可见、已可用，但仍在早期，而且贡献策略也还没有开放。

它没有独立文档站点，但文档并没有缺席

README 明确提到：There’s no public docs site yet，不过可以查看 docs 目录里的各种 markdown 文件。

紧接着，它列出了一组文档入口：

  • Getting started
  • Remote access
  • Keeping T3 Code in sync
  • Architecture overview
  • Provider guides
  • Operations
  • Reference

这份目录虽然只是入口列表，但已经很能说明问题。至少从 README 能看出来，T3 Code 不是一个只靠首页几句话撑场面的仓库，它已经把“快速开始”“远程访问”“同步”“架构”“提供方指南”“运维”“参考资料”这些维度拆开整理了。

换句话说，哪怕还没有公开文档站，它的文档组织意识已经存在了，而且分类相当明确。

如果你执意想参与，它也把前置条件说清楚了

README 有一节标题甚至带着一点半开玩笑的语气：

If you REALLY want to contribute still…. read this first

但内容其实很认真。

先安装 vp

README 说明，T3 Code 使用 Vite+，因此需要先安装全局 vp 命令行工具。

macOS / Linux：

1
curl -fsSL https://vite.plus | bash

Windows：

1
irm https://vite.plus/ps1 | iex

随后安装依赖：

1
vp i

这一部分其实很重要。它不只是告诉你“怎么装依赖”，也顺手说明了项目在开发工具链上的选择：这里的关键入口不是传统意义上的一串通用命令，而是围绕 Vite+ 和 vp 建立起来的工作流。

README 还要求在打开 issue 或 PR 之前先阅读 CONTRIBUTING.md。哪怕仓库前面已经说“暂不接受贡献”，这里依然把准备路径写清楚了。某种意义上，这更像是一种“如果你真的已经走到这一步，至少请先按规矩认识这个项目”。

仓库里一些额外的 README，也透露出了项目的另一面

如果只看主 README，T3 Code 像一个早期但明确的 GUI 项目；而仓库中的其他 README，则让人看到更多内部组织上的细节。

.plans/README.md：它显然在认真思考可维护性

.plans/README.md 的标题是 Maintainability Plans，下面列出了一串计划项，包括：

  • shared model normalization
  • typed IPC boundaries
  • split codex app server manager
  • split chatview component
  • zod persisted state validation
  • provider logstream lifecycle
  • ci quality gates
  • precommit format and lint
  • event state test expansion
  • unify process session abstraction
  • version control phase 1
  • version control phase 2

这份列表本身就很能说明问题。它并不是功能宣传，而是面向维护性的规划目录。也就是说，项目不仅在想“做什么”，也在想“以后如何继续长大而不失控”。

尤其是这些标题里的关键词——typed、validation、quality gates、test expansion、abstraction——很容易让人感受到一种偏工程治理的倾向。对于一个 README 已经明确说自己还很早期的项目来说，这种维护性计划反而显得格外有价值：早，不代表没有结构意识；相反，它已经在为未来的复杂度提前腾位置。

assets/README.md：连图标资产都被写成了一套规矩

assets/README.md 的标题是 Brand icons。别看只是图标资源说明，里面其实有相当细的规则。

README 指出，三个 Icon Composer 项目是完整应用图标的 source of truth：

  • dev/app-icon.icon
  • nightly/app-icon.icon
  • prod/app-icon.icon

每个项目使用 text.svg 作为 T3 标记，在背景是矢量层时使用 background.svg，其他附加层使用能表达角色和位置的语义化命名。

接着，README 说明可以在仓库根目录运行：

1
vp run icons:export

用来重新生成 iOS、Linux、Windows 和 Web 资源。开发环境的 Web 导出还会复制到 apps/web/public。

这里有一种很明显的“细节控制欲”，但它是良性的那种。它说明项目连品牌资产的来源、导出方式和目标位置都做了固定约束，而不是让图标文件随意漂流在仓库各处。

它对 macOS 图标导出甚至精确到了尺寸与安全区

assets/README.md 中还有一大段专门讨论 macOS exports。

README 提到，Icon Composer 的命令行导出器不暴露 macOS pre-Tahoe preset，而普通命令行 macOS 导出是 full bleed，不适合桌面应用。因此，导出脚本不会替代这一部分原生导出流程。

随后它列出了需要在 Icon Composer 中手动使用的设置：

  • Platform：macOS pre-Tahoe
  • Appearance：Default
  • Size：1024pt
  • Scale：1×

并且规定三种导出的保存位置：

  • dev/app-icon.icon -> dev/blueprint-macos-1024.png
  • nightly/app-icon.icon -> nightly/nightly-macos-1024.png
  • prod/app-icon.icon -> prod/black-macos-1024.png

README 还进一步规定结果必须是 1024×1024 PNG，并具有经典 macOS safe area：不透明图标主体为 824×824，四周各内缩 100 像素，超出部分只允许存在 Icon Composer 原生阴影。

这种精细程度相当能说明问题。T3 Code 并不把图标当作随便糊上去的装饰件，而是把它们视为有明确工艺要求的正式资产。

它甚至给出了“让 Codex 帮你导出图标”的任务文本

同一份 assets/README.md 里，还贴出了一段可以直接粘贴给任务的文本，用来让 Codex 借助 @Computer 和 Icon Composer 应用，完成三套 macOS app icon 导出，并验证尺寸与安全区要求。

这很有意思。因为这个仓库本身就是一个“为编码代理服务的 GUI 项目”，而在资产维护说明里，它又反过来给出了如何让代理协助完成设计资产导出的提示。某种程度上，这种写法本身就带着一点项目气质：人和代理一起做事，不只是代码，也包括流程。

README 最后还强调：不要直接编辑生成出来的 PNG 或 ICO 文件。

这句简短的提醒，实际上也是一种边界声明——源头在 Icon Composer 项目，导出物不是手工改出来的成果，而是被追踪和再生成的结果。

从这些材料里，可以拼出一个相当清晰的项目轮廓

如果只依据 README 和仓库 description 来看，T3 Code 的轮廓是非常明确的。

它是一个面向编码代理的极简 Web GUI，目前支持 Codex、Claude、Cursor 和 OpenCode；它要求至少先安装并认证一个 provider；它既可以通过 npx t3@latest 快速运行，也提供 Windows、macOS 和 Arch Linux 的安装方式；它还处在很早期的阶段，README 明确提醒会有 bug，并且暂不接受贡献；它没有公开文档站点，但已经有结构化的 docs 目录；对于执意参与的人，它围绕 Vite+ 和 vp 准备了明确的开发入口；而从维护计划与品牌资产 README 来看，它在工程可维护性和资源规范上也已经投入了不少结构化思考。

它最耐人寻味的地方，是“极简”并不等于“草率”

很多项目一说 minimal，最后常常会变成“先别要求太多”。但从 T3 Code 这些 README 能读出来的，并不是草率，而是一种相当克制的聚焦。

它先把核心身份缩到很小：一个给编码代理用的极简 GUI。
然后把外围信息慢慢摆齐：安装方式、provider 依赖、开发入口、文档结构、维护计划、品牌导出规则。

这种感觉很像是在搭一间新工作室。门面不铺张，入口也不复杂，但墙上的工具、桌上的流程卡片、抽屉里的分类标签，都已经开始各就各位。它没有急着把一切讲成宏大叙事，而是先让人看到：这个项目知道自己在做什么，也知道以后复杂起来时，哪些地方最容易失控。

而这，往往正是一个早期工具最值得注意的地方。