Ghostty 是个终端工具，Mitchell Hashimoto 写的，就是做 Vagrant 和 Terraform 那位。 核心用 Zig，Mac 上套一层 Swift，Linux 上用 GTK。没有 Windows 版。

我 fork 了一份，三天后 Windows 版能跑了。第一个提交是 9 月 1 号凌晨两点半， 9 月 4 号发了第一个版本。Windows 那部分 45 个文件，4.8 万行 Rust，代码我一行没写，246 个提交，每个 Co-Authored-By 都是 Claude。

这篇主要讲讲这三天我在干什么。

得先说清楚这个 fork 是干嘛的，不然后面的事讲不通。

我 fork Ghostty 本来不是为了 Windows，是为了做AI CLI编排，就是基于Claude code、codex、opencode这类CLI工具来编排和做自动化开发。

功能很简单，选一个AI作为总管，它能看到别的AI终端里多久没动了，能读屏，能往里打字，能开新终端，能把所有人拉进群聊，配了一块任务面板用于协同。

Windows 版就是拿这套东西做出来的，就是用工具借助AI来迭代工具自身。

一个总管，三四个工人，每个都是独立的 Claude Code 会话。总管建群，把活拆成任务丢进面板，一个个派下去。我定方向、拍板、盯着。

 都不行，全走总管。起因是有一次总管跟我说"这两个人改的文件不冲突"，它是从其中一个工人的汇报里读来的，但另一个却说有冲突。后来改成：谁动了什么只能由动手的人自己说，谁跟谁不冲突必须总管自己跑一次 

 Zig 的构建会先把某个中间产物删掉再重建，这期间另一个人的构建必然死在一个跟他毫无关系的地方，前两次我都以为是代码坏了。

 听着像废话，但 AI 在"清理环境"的时候是真会顺手把你正在用的窗口关掉。

这层壳用什么写，我没让 AI 定，因为它决定后面所有的事。

Linux 那份 Zig 是第一个被排除的。两万三千行听着能复用，翻开全是 GTK，窗口是 GTK 的窗口，标签页是 GTK 的标签页，输入法也走 GTK。换到 Windows 一行不剩。

Windows 的输入法框架叫 TSF，用 COM 写的。C++ 和 C# 调它很顺，因为语言本身就认识 这套东西。Zig 不认识，得手工弄那张函数表，一个字段错位全崩。而输入法是 Windows 终端最难的一块，也是中文用户开机十秒就会碰到的一块。

Mac 的输入法接口 Swift 天生就有，Linux 的是 D-Bus 加 C 接口，Zig 接起来很顺。就 Windows 这个是 COM。

Rust 有微软自己出的绑定，COM 支持完整。选它，输入法整个待在 Rust 这边，Zig 一行 COM 都不用碰。

Zig 那边最后只改了二十行左右——系统相关的信息压成了一个很小的结构，原来两行， 加第三行给 Windows 就完事。剩下的活全在 Rust，而且 Mac 那层壳已经把同一份接口 实现过一遍，等于有份参考答案。

按常理该先把窗口开出来，看见界面，有成就感，但我让AI先去啃输入法。

这是整条路上唯一一件光看代码猜不出难度的事。要是比我想的难十倍，我得在写两万行 后续代码之前知道。

结果特别顺。输入法那部分四百多行，头一回交叉编译出来的程序拷到 Windows 上一次 就通了：敲 

，候选词框浮出来，按 1，"你好"。

把第 0 到第 2 格替换成"你"。这个字在内存里算一个字符，在终端里占两格。 那个 2 要是算成 1，候选框就偏，而且只在中日韩文字上偏，英文完全正常。 这种 bug 最难查。

关键是那个 2 不是自己写死的，是问终端核心要的，跟核心排版用的是同一张宽度表。 它没图省事自己造一张，看到这儿我才觉得这套干活方式靠谱。

窗口能开了，输入法通了。接上核心跑起来，全黑。

不是崩溃，是安安静静地黑。该成功的全成功了，窗口也在正常收到"重绘制"的通知，就是一个像素都没有。

后来摸出个规律：先建个小窗口再放大就是黑的，建的时候直接给最终尺寸画面就出来。

画出来的区域 = 1000x670      ← 一直是建窗口那一刻的大小

慢慢拉大六次，这个数一次都没变过。

但终端自己是清醒的。在全屏的终端里敲命令查行列数，回答 143 列 41 行，正好等于全屏宽高除以单个字符的大小，一分不差。这个读数是命令行那头的程序报回来的。

继续埋，把每一环都打出来。链条是通的，每一环的数都对。两个 agent 各自写了个测试方法，两个都失败，屏幕还是黑的。

后来换了个办法，让AI不看日志了，截张图用画图工具量黑白分界线在哪。

分界线落在横坐标 1000，尺寸全对，只是有"旧尺寸那么大的一块矩形"被画上了屏幕。 把日志改到最后一步，真正往屏幕上贴图的地方：

目标=1240x790  贴图区=1240x790  画布=1240x790
可绘区域=(0,0,1000,670)          ← 死在这儿

前三个都跟上了，最后那个卡在了旧尺寸。

翻代码找到一个函数专管设这个区域，搜谁在调它——全仓库零个调用者。

这个"可绘区域"这辈子只被设过一次，创建的那一瞬间按当时窗口大小设的，之后再没人 管过。

Linux 上为什么没这毛病？翻 GTK 源码一眼就看见了，它在每次窗口变大时替我们重设 了一遍。GTK 一直在帮忙擦屁股，Windows 这边是块光板。

更难受的是这事早就写在代码注释里，那个函数旁边有句英文，大意是"在裸窗口上没有人会做这件事"。读过那个函数的人没把它当缺陷读。

回头看最开始那个"建窗口时给全屏尺寸"，它之所以有效，是因为它让那个只设一次的 区域恰好等于窗口大小。病一直都在，只是被藏到了第一次之后的任何一次拉伸里。

AI 写代码的难点不在写不出来，在它会特别自信地跟你说工作完成了，或者测试都通过了。

新加了个文件，接进项目，编译报 0 错误 0 警告。看着挺好。

其实把它加进项目的那行语句，从来没执行。当时是一串命令连着跑，中间断了一条，后面的全没执行。而屏幕上那个退出码，来自断点之前最后一条跑过的命令，正好是 0，导致AI说执行成功。

后面是测试发现功能不对应，才发现的代码缺失。

AI写了 16 道检查脚本。其中 4 道扫了 0 个文件，然后打印"一切正常"，退出码 0。

"扫遍整棵树没发现问题"和"一个文件都没扫到"，输出长得一模一样。

发现的办法是测试检查器换件，有一步把它们指向一个空目录，看谁还敢说正常。

现在每道检查都得带一句自检，哪一行不出现就说明它本身没工作，而不是它工作正常。一道永远不会失败的检查，比没有检查更糟。

有些代码只在"不是 Mac"的时候才走。而在 Mac 上编译时，编译器看一眼就知道这段 走不到，干脆不分析了。

所以平时那句"在 Mac 上跑一遍，确认没写坏"，对这部分代码完全不成立。

解决方案是进行交叉编译 Windows 会红，但在 Mac 上编译不一定会报错。

上面这些坑有个共同点，出问题的时候没有一条会大声报错。而 AI 最擅长产生一个看起来对的东西。所以我逼着它们把每次踩坑都变成一道自动检查。

 下现在有 61 个 Python 脚本，提交之前全跑一遍。文件名本身就是 那条规矩：

a-position-is-not-an-identity.py       位置不能当身份
an-async-handle-is-not-copied.py       这种句柄不能按值复制
the-ui-thread-never-waits-forever.py   界面线程不许无限等待

第一条是这么来的：标签页和分屏格子的身份必须是永不重复的编号，不能用它在数组里 的位置。格子会被拖来拖去、会被关掉，用位置的话"第 2 个"会在某一刻悄悄变成另一个 格子，不报错，不留痕。

还有个习惯比代码本身有用。状态文档里有两个词绝不混用：已落地是代码写完了、编译得过、检查都绿了；已验证是有一条在真机上跑出来的实际读数支持它。没有读数就不许写已验证，哪怕这事明摆着是对的。

还有一条：文档里没标"实测"的默认就是没验过。方向是这么定的，不是反过来。要是反过来，用"未验"去标例外，沉默就变成了一种承诺——读者看到会以为其余的都验过了。

Windows 版没法在 Mac 上验，旁边放了台 Windows 当测试机，接了远程控制。 AI 自己上去装包、起程序、截图、读日志，我基本不插手，但这里的坑也不少。

远程工具打字是绕过输入法的，它直接合成字符送进去，所以拿它测中文输入你会得出"输入法没接通"的结论，换成真的发按键候选框立刻就出来。

最麻烦的是发按键之前得先证明窗口在前台。Windows 某些情况下会静默拒绝把窗口提到前台，函数不报错，脚本一路跑完，键落到别人窗口上。这时候"键没发出去"、"键被别人吃了"、"这个功能坏了"三种情况在日志上完全一样。

后来写成硬规矩：凡是要发按键的验证，第一步写成"点一下被测窗口"，不要写成"把窗口置前"。

群聊这个功能本身是用群聊测的。在测试机上拿个本地跑的 27B 小模型当总管，带三个工人，在空目录里做个小项目。建文件、开终端、建群、派活、各自交件、汇总提交，五步全通。最想看到的信号也出来了：那模型被权限挡住之后，自己去查自己是谁，自己找到提权的办法，自己重试成功。

添加图片注释，不超过 140 字（可选）

9 月 4 号发的第一个版本，之后又花了一周多打磨，9 月 8 号打包给测试者， 9 月 9 号冻结。真正在写功能的就是头三天，后面都是真机验收和收尾。

核心一共 72 个动作，Windows 这边实现了 63 个，明确拒绝 7 个，还欠 2 个，欠的两个是背景透明度切换和退出计时器。

终端显示那一半根本不是移植的，它就是同一份 Zig 核心，Windows 这边只是给了它一个窗口，我做的是外面那层壳。

三天做出来，不是因为哪个模型写得特别快。而是那三天里一直有四个AI在协同工作——一个啃输入法，一个做标签和分屏，一个查黑屏，一个补菜单，139 个提交是这么堆出来的。

并行不难，难的是一个人如果监管多个AI。哪个在等你授权、哪个二十分钟前就干完了在那闲着、哪个只是在等你确认设计。我原先的是每隔一会儿就得一个个看一遍，都是碎片时间，自己想做什么事情很容易被打断。

所以我想法就是，这活我得交给了另一个 AI 来做。总管盯着每个AI的终端屏幕，哪个多久没动了、谁停下来了需要授权、谁干完了需要接着派下一个活儿，而我只需要和总管一开始确认好设计和内容，之后就不用再管了。

群聊和任务面板也不是摆设——上下文清空、终端重开、第二天接着干，面板上的活还都在。

3 天，我用 AI 给 Ghostty 做出了 Windows 版

Ghostty 是个终端工具，但官方只有Mac和Linux版本，我 fork 了一份，借助AI开发，三天后 Windows 版能跑了。

人工智能

开发工具

客户端

Windows版Ghostty移植：fork自MitchellHashimoto的终端工具，三天完成Windows支持。核心用Zig，Windows层用4.8万行Rust，246个提交全由Claude协作完成。文章详述了输入法TSF适配、黑屏故障排查、AI协作开发流程，以及61道自动化检查闸门。现支持63个核心动作，MIT开源，欢迎测试反馈。

Terraform

编译器

Windows

Python

Linux

Swift

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Windows版Ghostty移植：fork自MitchellHashimoto的终端工具，三天完成Windows支持。核心用Zig，Windows层用4.8万行Rust，246个提交全由Claude协作完成。文章详述了输入法TSF适配、黑屏故障排查、AI协作开发流程，以及61道自动化检查闸门。现支持63个核心动作，M...

3 天，我用 AI 给 Ghostty 做出了 Windows 版

3 天，我用 AI 给 Ghostty 做出了 Windows 版

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐