在开源项目的维护实践中，如何平衡 AI 辅助开发的效率优势与代码质量保障，始终是一个棘手的问题。Ghostty 终端仿真器项目在 2025 年 8 月通过 PR #8289 引入的 AI 工具披露策略，提供了一个值得参考的工程化解决方案。这项策略的核心并非禁止 AI 使用，而是通过透明的披露机制，让代码审查者能够根据上下文调整审查深度。
策略动因：从隐性规则到显性规范
Ghostty 创始人 Mitchell Hashimoto 在该 PR 的说明中明确阐述了决策背景。他坦言，在 AI 工具普及之前，代码仓库中大约每六个月才会出现一个需要大量返工的问题性 Pull Request。然而，随着 AI 辅助编程的普及，这一频率急剧上升 —— 他观察到「几乎每周都会遇到」质量不达标的提交。这种变化并非因为 AI 本身产生了更多问题，而是因为 AI 生成的代码往往在表面上看似合理，却在细节层面经不起推敲。
值得注意的是，Hashimoto 强调他本人是 AI 工具的使用者，而非反对者。他在项目维护中采用 AI 进行 Issue 的首轮分类和模式识别，只是这一过程需要在「严格监督」下进行。这种立场决定了 Ghostty 的策略定位：既不排斥 AI 的生产力增益，也不回避其带来的质量风险。
披露机制的设计要点
该策略的实施载体是 CONTRIBUTING.md 文档中的明确规定。所有使用任何形式 AI 辅助的贡献必须在 Pull Request 中进行披露。披露的目的并非惩罚或审查，而是为代码审查者提供必要的上下文信息。当审查者知道某段代码是由 AI 生成时，他们可以相应地调整审查策略 —— 对关键路径进行更细致的验证，对边界条件和错误处理进行更深入的检查。
从工程实现角度来看，这种软性约束相比硬性禁令具有显著的灵活优势。它不要求维护者建立复杂的检测机制或自动化审批流程，而是依赖于贡献者的诚信和社区共识。这种方式特别适合中小规模的独立项目，因为它们往往缺乏资源来构建和维护严格的 AI 代码检测系统。
实践参数与可操作性建议
对于希望借鉴这一策略的开源项目，以下参数值得关注。披露的粒度建议保持宽泛 —— 仅需声明是否使用了 AI 辅助，无需详细说明使用的具体工具或提示词。这一设计降低了贡献者的披露成本，同时保留了审查者所需的关键信息。审查者可以根据披露标记调整审查时间分配，对 AI 辅助的提交预留更充裕的检查窗口。
在社区文化层面，该策略的成功依赖于维护者与贡献者之间的信任基础。Hashimoto 将其定位为「为审查者提供上下文」而非「管控贡献者」，这种表述方式有助于避免对抗性氛围。实践中，建议维护者在评论中使用类似「感谢使用 AI 辅助，这部分逻辑我需要多花些时间验证」的沟通方式，而非「为什么没有披露 AI 使用」的质疑语气。
治理模型的迁移适用性
Ghostty 的做法提供了一种可迁移的治理框架。对于采用类似策略的项目，建议在 CONTRIBUTING.md 中明确以下要素：披露的触发条件（任何程度的 AI 辅助均需披露）、披露的形式（在 PR 描述或特定文件中声明）、以及披露的预期效果（帮助审查者调整审查策略，而非影响合并决策）。这套框架可以适配不同规模的项目，从个人维护的独立仓库到拥有数百贡献者的大型框架。
该策略的另一个重要启示在于，它将质量保障的责任从「检测机制」转移到「人」身上。AI 生成代码的质量问题，本质上需要人类审查者来识别和纠正。通过让审查者知悉代码来源，Ghostty 实际上是在优化人力资源的分配效率 —— 让有限的审查注意力集中在更需要的区域。
资料来源
本文核心信息参考自 Ghostty 项目的 Pull Request #8289 以及相关社区讨论。