在本次会议中，Mitchell Hashimoto 向 Richard Feldman 详细介绍了他在构建 Ghostty 时使用 AI 的方法。具体来说，他们详细讨论了这次最近的提交。
您可以在YouTube 上观看他们的对话，或阅读下方的一些精选引言。
保持架构控制
“我的方法是，我或多或少是软件项目的架构师。我仍然喜欢设计代码结构、应用程序中预期的数据流、状态存储位置。我给工具提供指导，比如，‘我希望你实现这个最终目标，但要使用这种形式。’”
“如果我只是说‘存在这个 bug，请修复它’——它可能已经修复了，但会以一种糟糕的、锤子敲钉子般的方式修复，那不是长期可维护的。”
像指导初级工程师一样进行提示
“我发现指导初级工程师的最佳方法是给他们一个范围明确且有很多护栏的问题……这有点像保龄球加了护板，这样他们就能在沿途有护栏的情况下击中球瓶。”
“这正是我会告诉项目新人初级工程师的话，这对他们来说是一个范围明确的问题。我发现，当我让初级工程师去解决开放式问题时，那会是一场灾难。而 AI 目前也处于这种状态。”
“我有点把它当作我可以高效地对某人说，‘你能调试一下并找出这是为什么会发生吗？去完成它。’这就是我尝试使用 AI 的方式。”
与智能体并行工作
“我本可以在之前的三个提示中轻松完成这些清理工作，但我无法同时进行这些清理和并发地进行修复的质量保证测试。我将这些简单的工作推迟给 AI，而我一直都在这个环境中与它并行工作，但我正在运行、点击并进行压力测试，然后我发现了一个 bug。”
“这些 AI 辅助工具的一个好处是，你不需要立即回应。当 Claude 发出需要你注意的通知时，我不需要立即去处理它。如果我正专注于某件事，我会继续做下去。”
从可工作的代码到可维护的代码
“Bug 已经修复了，但现在让我们把它调整成我真正想看到的样子。这有点像权衡，是直接手动去操作呢？在这种情况下，有一些它能很快完成的明显事情。”
“所有这些智能体都非常擅长重构。如果它们不修复 bug 或引入新功能，而只是重命名、洗牌和重组——它们几乎是完美的。任何时候我让它做这些事，它总是完美的。”
“目前我与大型语言模型（LLM）所做的大部分工作，只是为了使其达到更高级的质量视角。当我思考我们将如何继续修复 bug、如何验证这不会退步、团队中其他人将如何理解这一点时——它在这方面表现得不是很好。”
智能体的当前局限性
“对于 Zig 代码库来说，任何超出微不足道的变化仍然是无望的。我发现的解决方法是，当它有用时，我让它用它擅长的另一种语言（无论是 C、Rust、Swift 还是 Python）重写其解决方案，然后我再自己将其转换回 Zig。”
“我认为它在架构问题上表现得很糟糕。我认为它在高性能数据结构类型工作方面仍然非常糟糕。它对标准数据结构了如指掌，但它不理解你在尝试实现的目标背景下的数据结构。”
模型选择和测试
“有时我实际上有多个 Ghostty 的检出版本——ghostty、ghostty2、ghostty3、ghostty4。我会在相同的任务和相同的提示下，在不同的代码库上运行不同的模型和不同的智能体。这是一场比赛。”
“到目前为止，我使用 Claude 获得了最大的成功。Gemini 有一段时间表现不错，但每当我问简单问题时，它都会生成大量的文本作为回应。这对我来说效率不高。”