标题里那个 3 天是我给自己定的死线。因为再拖下去这个项目大概率会变成又一个“收藏了就当做完了”的坑。Ghostty 在终端圈子的热度不用我多说macOS 和 Linux 用户早就用上了 GPU 加速的渲染、低到离谱的延迟Windows 用户却只能对着官方路线图干等。我的日常工作机又恰好是 Windows每次在 Windows Terminal 里看着那个加载速度就忍不住想把 Ghostty 搬过来。时机也刚好AI 编程辅助已经成熟到可以让我这种没系统写过 Zig 的人也有胆量去啃一个跨平台终端模拟器的源码。这篇文章不聊什么宏大叙事就讲讲我这三天的实操过程怎么用 AI 把 Ghostty 的核心代码读懂怎么识别出它内部所有跟平台绑死的地方怎么一层层替换成 Windows 原生的实现以及最后踩了哪些坑、怎么排查出来的。写出来希望能给也想折腾“带着 AI 去移植开源项目”的人一点参考。1. 目标拆解先弄清楚 Ghostty 为什么难移植1.1 为什么 Ghostty 迟迟不出 Windows 版在动手之前得先明白 Ghostty 到底是什么技术底子。它最核心的一点是用 Zig 写的。Zig 是一门很年轻的语言强调显式内存管理、编译期计算、以及在 C ABI 层面的无缝互操作。对开发者来说它“心智负担小”但对一个刚接触 Zig 的人来说读这种代码的门槛并不低。更关键的是Ghostty 从设计之初就不是 Electron 套壳那种“一套代码到处跑”的路子。它的 UI 层大量使用平台原生能力macOS 上是 AppKit MetalLinux 上是 GTK OpenGL/WebGPU。字体渲染、剪贴板、窗口事件、光标形状、平滑滚动每一样都跟操作系统深度绑定。也就是说它没有一个“只写一次、到处运行”的抽象层而是针对每个平台单独实现了后端。Windows 之所以迟迟没有官方版本不是没人想做而是这活儿的复杂度被很多人低估了不是改几行编译配置就能跑起来的。1.2 为什么在已有大量终端的情况下还要做它有人可能会问Windows 上已经有 Windows Terminal、Alacritty、WezTerm为什么非要有 Ghostty这个问题我在动手前也问过自己。答案是这些终端各有各的取舍。Windows Terminal 功能全但启动速度和资源占用一直被人吐槽Alacritty 的渲染性能不错但很多日常功能得靠 TMUX 补WezTerm 配置灵活但默认设置下内存占用偏高。Ghostty 的价值在于它的设计目标本身就非常聚焦渲染要用 GPU启动要够快字体要按原生平台质量渲染延迟要低到“看起来像没有中间层”。在 Windows 上确实还没有一个完全对标这些点的原生终端。1.3 为什么决定用 AI 来完成主力开发这个项目靠我人工一行行读代码三天连门都摸不到。我选定的路线是用 AI 当主力工程师我当架构师和质检员。具体到工具我主要用了两类一个是对话式的大模型编程助手用来速读项目结构、解释跨平台逻辑、生成需要补的代码另一个是 IDE 里的 AI 插件用来做代码补全和局部重构。AI 做得最多的一件事就是在我给它一个“平台差异点”之后直接生成一整段可编译的 Windows 原生实现。这么做的前提是AI 生成代码的质量高度依赖上下文。你给它的不是一句“给我写一个窗口”而是“这是 Ghostty 在 Linux 上处理鼠标滚轮的代码请用 Win32 等价 API 实现同样的效果并要求能接入现有事件循环”。上下文越精确AI 生成的代码越可用。整个三天里我花在“把上下文梳理给 AI”上的时间比真正调试代码的时间还多。2. 关键决策不给 Ghostty 补全端而是替换平台后端2.1 先花小半天梳理源码里的平台相关模块决定动手之后我第一件事不是写代码而是把这三天当成一次“源码考古”。我把 Ghostty 的仓库克隆到本地然后用 AI 辅助扫描了一遍目录结构把每个明显带平台关键词的文件单独列出来。结果很快就发现它的核心仿真器部分实际上是平台无关的这一块代码占比很大包括终端状态机、ORM 分析、滚动缓冲区、解析 VT 序列等。这些代码在 Windows 上可以直接编译不需要任何修改。要改的只有外围那层窗口创建、事件循环、渲染后端、字体后端、剪贴板、伪终端、进程管理。我把这些整理成了一张表每一条后面都标注了“当前平台实现是什么、Windows 上对应什么、需要改动的代码位置在哪”。这张表就是我三天里所有工作的核心清单。整个过程有 AI 帮忙大概两三个小时就过完了。如果没做这一步就直接改代码后面大概率会陷入“这里也报错、那里也报错”的泥潭。2.2 关键决策保留 GTK 还是换纯 Win32在动手之前我面临一个非常关键的选择Ghostty 在 Linux 上用的是 GTK那在 Windows 上是不是可以把 GTK 编译进去看起来省事但实际不可行。第一GTK 在 Windows 上的渲染和字体显示效果跟原生略微软这跟 Ghostty 追求原生体验的理念相违背第二GTK 在 Windows 上依赖一堆 DLL分发成本高还会拖慢启动速度第三AI 在生成 GTK 兼容代码时绕来绕去最后还是回到 Win32 API 上。所以我很快拍板直接用 Win32 API 实现一套最小的窗口层渲染部分用 Direct3D/WebGPU 的 Windows 后端接上字体部分用 DirectWrite。这个决定的意义在于它让我在后续所有代码生成中都能明确告诉 AI “不要使用跨平台 UI 库直接用 Win32”。目标越清晰AI 生成的代码越少出现“看起来很合理但根本链接不过”的情况。2.3 编译目标怎么设置从 Linux target 改成 Windows targetGhostty 的构建系统用的是 Zig 自己的构建工具核心文件是build.zig。正常情况下它在 Linux 上会把 target 解析成x86_64-linux-gnu。要出 Windows 版我需要让构建系统生成一个目标为x86_64-windows-msvc的可执行文件。这个改动本身不难难的是在改完 target 之后有一堆平台判断代码会走不通。例如const std import(std); // 这段代码示意性展示了如何在 build.zig 里透传 target // 实际使用时需要把目标平台从宿主平台替换为 Windows const target b.standardTargetOptions(.{ .default_target .{ .cpu_arch .x86_64, .os_tag .windows, .abi .msvc, }, });改完构建配置接下来所有跟平台有关的编译报错就成了我三天里交替出现的“日常伴侣”。每次报错出现我都会把完整错误信息丢给 AI让它在源码里定位问题然后给出修复思路。很多修复并不是直接把某一行改成 Windows 写法而是需要在平台分派的地方增加一个 Windows 分支。这时候 AI 的价值就体现出来了它能很快帮我判断某个if (builtin.os.tag .macos)分支后面是不是应该加一个.windows分支并且自动补全分支内的代码。3. 三天实操记录从编译报错到可用的终端3.1 Day 1把原版代码在 Windows 上艰难编译起来第一天的目标只有一个让 Ghostty 源码在 Windows 上完成编译。哪怕编译出来的程序启动后瞬间崩溃也算成功——因为我需要先解决所有跟工具链、依赖库、平台 API 相关的硬性问题。第一步是装 Zig 编译器。这里就有一个小坑Ghostty 的build.zig可能依赖特定版本的 Zig 特性用太新的编译器反而会报语法不兼容。我最后锁定的版本是当时比较稳定的 0.13.0之后遇到编译报错会先怀疑版本问题。第二步是处理链接阶段的问题。Win32 API 的开发并不需要额外安装 SDK系统自带的 Windows SDK 就够用但 Zig 在链接时需要正确找到 libc 和 kernel32.lib。这里 AI 帮我做的一件特别有价值的事是生成了一个最小复现样例单独调用 Win32 API 创建一个空窗口测试当前 Zig 环境的链接是否正常。样例能编译通过就说明问题不在工具链而在 Ghostty 自身的源码。这一步排查思路后来帮我省了很多不必要的折腾。第三步才是真正编译 Ghostty 本体。那一长串报错出来了从“找不到coretext.zig”到“ioctl未定义”都有。所有错误信息我先原封不动丢给 AI然后它会告诉我这条报错是因为这部分代码只在 Linux 下编译需要用条件编译屏蔽掉。在 Zig 里常见的做法是在文件头部加上平台判断或者把平台相关代码放到os目录下由build.zig根据平台选择编译文件。就这样一个接一个修到第一天晚上Ghostty 总算在 Windows 上完成了编译。虽然双击运行直接黑屏退出但至少跨过了第一阶段。3.2 Day 2让 AI 逐个平台模块写 Windows 版第二天是最耗心智的一天。我的核心工作是把梳理出来的平台模块一个一个喂给 AI让它看懂现有实现后生成对应的 Windows 版本。先处理的是窗口系统。Ghostty 在 macOS 上用NSWindow在 Linux 上用 GTK 的GtkWindow在 Windows 上最直接的对应就是 Win32 的CreateWindowEx。AI 生成的窗口启动代码很快就跑通了但接下来一堆问题浮出水面消息循环怎么跟 Ghostty 的事件机制对接窗口缩放时内部的终端尺寸怎么同步DPI 变化怎么处理这些都是 GTK 帮你做了的事换成裸 Win32 后全部要自己处理。比较顺利的是渲染后端。Ghostty 已经抽象了一个渲染层底层是通过 WebGPU 实现跨平台加速的。Windows 上 WebGPU 可以走 DX12 后端我把后端初始化部分的代码交给 AI让它参考显卡和窗口句柄的获取逻辑生成 DX12 的初始化流程。这部分虽然耗时但属于“查 API、套代码”就能完成的活。字体系统是第二天里最让我头大的部分。Ghostty 在 Linux 上用 fontconfig 做字体匹配在 macOS 上用 CoreText。Windows 上对应的技术是 DirectWrite。但 DirectWrite 的字体枚举、回退链、字形指标系统跟 fontconfig 完全不一样不是简单换 API 就能等价替代的。尤其是“中日韩字体回退”这个环节在 Windows 上如果不设置好IDWriteFontFallback终端里一打中文就全是豆腐块。这个坑我单独花了几个小时最后是靠 AI 定位到字体回退链的配置入口再自己手动加的Microsoft YaHei UI回退才解决的。到第二天结束窗口能正常打开终端区域能渲染字符虽然还没法输入但已经能从界面上看到熟悉的 Ghostty 欢迎页。3.3 Day 3接入 ConPTY、输入事件跑通主流程第三天的工作主要围绕“能输入、能交互”展开。终端模拟器最核心的输入输出链路是用户敲键盘 → 字符被编码成标准输入 → 写入伪终端 → 被真正的外壳进程读取 → 外壳输出结果 → 终端模拟器读取到输出 → 分词后渲染到屏幕。这条链路在 Linux 上靠/dev/pts和ioctl实现在 Windows 上对应的技术是ConPTYPseudo Console它是 Windows 10 之后提供的官方伪终端机制。我给 AI 提供的指令很明确参照现有的 PTY 模块接口用CreatePseudoConsole、ResizePseudoConsole和ClosePseudoConsole实现一个 Windows 版本的伪终端。AI 很快生成了一段可用的代码核心部分长这样// 示意在 Zig 中调用 ConPTY API 创建一个伪终端 var pseudoConsole: HPCON undefined; const hr CreatePseudoConsole(size, inputPipeHandle, outputPipeHandle, 0, pseudoConsole); if (hr ! S_OK) { // 伪终端创建失败时的处理 }这之后又牵扯出一连串问题输入事件要怎么编码成按键序列终端尺寸变更时怎么通知 ConPTY 改变窗口大小前后台任务切换时怎么转发行程组信号。这些细节单靠 AI 一次性生成很难完全正确需要反复调。我印象最深的是按住方向键时终端不自动重复移动光标——这个问题的根源是事件循环没有处理WM_KEYDOWN的 repeat 标志属于平台细节差异。AI 在那个位置改了三版才完全符合预期。第三天下午我终于能在一个原生 Windows 窗口里流畅地运行 PowerShell、git log、vim还跑了一遍htop的 Windows 等价物。说实话那个瞬间还挺有成就感的。4. 实操中踩过的坑与排查办法4.1 编译分层不要指望一次修好所有报错如果你也想走这条路别想着“把错误列表一次性看完然后逐个修完就成功”。编译问题是有依赖性的修掉 A 错误B 错误可能就消失了反而冒出 C 错误。我第一天最蠢的操作就是一次性把 200 行报错都丢给 AI让它“全部修复”。AI 真的改了一堆无关的东西结果还得回滚。正确做法是一次只处理第一个报错解决完重新编译再处理下一个。这条经验反复送给我自己。4.2 事件循环Win32 的异步模型比 GTK “低”得多的多GTK 自带一个全局事件循环把鼠标、键盘、绘制、定时器都整合在一起。Win32 则是一套非常底层的消息泵所有东西都靠GetMessage循环分发。Ghostty 里原本的事件模型基于 GTK有一套自己的调度规则。在 Windows 上移植时我让 AI 做了一层适配器把 Win32 消息翻译成 Ghostty 内部的事件结构。这层适配器是最容易出 bug 的地方因为一个消息丢了终端就会出现“鼠标点击没反应、窗口拖一下才刷新”的奇怪问题。排查这类问题没有捷径只能在关键分支上打日志把收到的消息类型一一打出来对比 GTK 上对应的行为。4.3 渲染性能不要着急优化先保证正确性刚跑通渲染的时候我看到了一个更隐蔽的问题快速滚动时会有明显闪烁。这是因为终端模拟器在渲染每一帧时把整个窗口背景先清掉了再重新画字符。GTK 上的 Ghostty 默认做了双缓冲两层帧缓冲之间无缝切换。我在 Windows 版初期没有实例化双缓冲导致后台缓冲的内容没有被正确保留。AI 给出的方案是给 DirectWrite 的渲染目标设置D2D1_PRESENT_OPTIONS_RETAIN_CONTENTS让画面在帧与帧之间保留旧内容闪烁问题立刻缓解。这个优化很值得记录因为它不是说“性能差”而是“渲染策略不匹配”。4.4 伪终端兼容性同一段代码换 shell 就出问题ConPTY 的适配程度在不同程序上表现差异很大。我在 PowerShell 5 里测试一切正常换成 Windows Terminal 默认的 PowerShell 7 之后部分 VT 转义序列的解析开始混乱。最后定位到问题ConPTY 在启用了虚拟终端解析后对某些 CSI 序列的包装方式和 Linux PTY 不一样。解决办法是在开 ConPTY 之前设置合适的ConsoleVirtualTerminalLevel还要在子进程继承句柄时处理好bInheritHandles标志。这个细节非常隐蔽没有 AI 帮忙在源码里比对不同平台的序列处理逻辑靠人肉对照列表查的话估计得折腾一整天。4.5 字体回退终端最容易摔的跟头Windows 上有大量中英文混排场景中文字体回退必须专门配置。一开始终端里中文全是方框排查过程是先用 AI 定位到字体解析模块再把 Linux 上 fontconfig 的matchPattern逻辑跟 Windows 上 DirectWrite 的IDWriteFontFallback::MapCharacters做对比。AI 给到的修改思路是在字体管理器初始化时创建一个全局回退对象并把“微软雅黑”加入回退列表。改完之后中文显示正常但等宽字体里的中文仍然是对不齐的这个我暂时接受了毕竟连一些成熟的终端也做不到完美的中文对齐。5. AI 辅助移植的经验总结这套流程对其他项目也适用5.1 先把“让 AI 看代码”的姿势学会这次最大的体会是AI 不是万能的但你给它的信息足够结构化之后它的产出质量会高到超出预期。具体怎么结构化我推荐一个思路每次给 AI 布置任务都按“背景说明 原始代码 目标平台 验收标准”四段式来描述。背景说明是告诉它这段代码属于整个项目的哪一层原始代码是让它有足够的上下文可参考目标平台是明确告诉它改到哪里去验收标准是为了让它知道“做到什么程度才算完”。这一套组合下来AI 生成的代码几乎能用剩下的只是微调。5.2 移植类项目最忌“贪多”第三天下午我差点顺手做了一个 Windows 版的主题渲染重构被自己强行拦住了。移植项目的核心目标是先跑通性能优化、功能增强都属于事后慢慢做的东西。如果你在移植过程中不断加新功能bug 的来源就永远分不清是“平台适配的问题”还是“新功能本身的问题”。我后来把所有改动限制在保证 Ghostty 原有功能不丢、在 Windows 上能原生运行这个范围内所有花活一律记在 TODO 里排到项目第二期。5.3 把编译错误当成线索来源而不是麻烦我见过很多人一遇到编译错误就开始心烦其实编译错误是编译器在告诉你“它期望的结构和你提供的不匹配”。配合 AI 的时候编译错误甚至比代码阅读更有效。因为你可以直接把错误信息粘给 AI请它把出错位置相关的上下文解释一遍然后让它给出修复选项同时列出每种选项的副作用。这种方式远比直接问“怎么写一个窗口”效率高。很多 AI 生成的代码初看能用但真正暴露问题的地方就是在编译阶段善用它等于拿到了免费的持续集成反馈。6. 下一步计划与最后的建议这三天项目的产出目前只是尽到了一个“技术验证”的责任证明 Ghostty 的核心仿真器是可以在 Windows 上原生运行的也证明了 AI 可以极速缩短一个人接触陌生代码库的学习成本。接下来我打算继续做两件事一是把 Windows 版的分发包整理好补上图标、安装脚本和长期稳定性测试二是研究能不能把这次移植的代码向上游仓库提 PR哪怕只是把跨平台构建的部分合并进去也能让后来者少走很多弯路。最后再分享一个小小的实操习惯移植类项目里每完成一个平台模块的适配立刻把前后的差异点和修改原因记录到一个PORTING_NOTES.md文件里。这些笔记看起来不起眼一旦整个项目卡住、需要回退或者重试的时候它们就是最宝贵的线索。AI 会忘记上下文你也会忘记当时的思路但笔记会一直在。期待 Ghostty 官方真正出 Windows 版的那一天。如果到那时我这份粗糙的适配代码已经没人用了那我就觉得值了。