当 Mitchell Hashimoto 在 2025 年 8 月 19 日合并 PR #8289 时，Ghostty 项目正式确立了一套完整的 AI 工具披露机制。这份增加 34 行文档的改动不仅仅是简单的政策声明，更是一套可执行的工程规范。从 PR 模板的披露复选框到贡献指南中的阈值定义，从文档要求的具体示例到社区讨论中涌现的 CI 自动化方案，Ghostty 的实践为开源项目提供了一个可参照的工程模板。
披露阈值的界定：何种 AI 使用需要申报
政策制定的核心难点在于划定清晰的边界。Ghostty 的贡献指南明确规定，任何超出简单 tab 自动补全的 AI 辅助都必须披露。这里的「简单 tab 自动补全」被定义为关键词或短语的补全 —— 换言之，当开发者使用 AI 进行代码生成、重构建议、测试编写或文档创作时，都需要在 PR 中主动说明。
这一阈值设定的考量非常实际。Mitchell Hashimoto 在 PR 描述中坦言，他并不反对 AI 工具本身，甚至自己也在「严格监督」下成功使用过 AI。他的核心担忧是缺乏经验的 AI 驱动者无法充分审查 AI 生成的代码，从而向项目提交质量低劣的修改。用他的话说，这是在阻止「AI slop」—— 大量由不熟悉代码库的人通过 AI 快速生成、但实际上难以维护的代码。披露机制的本质不是禁止 AI 使用，而是让维护者能够根据披露信息调整审查策略：对人类新手贡献者投入更多指导精力，对 AI 驱动的贡献则采用更严格的验收标准。
PR 模板中的披露机制配置
PR 模板是披露政策落地的第一道关卡。Ghostty 在其 Pull Request 模板中添加了明确的披露选项，要求贡献者在提交修改时回答两个核心问题：是否使用了任何形式的 AI 辅助，以及如果使用了，具体涉及哪些类型的协助。
一个典型的 PR 披露区块应包含以下结构。首先是声明确认，贡献者需要明确阅读并理解了项目的 AI 政策；其次是使用声明，在「使用了 AI 辅助」和「未使用 AI 辅助」之间做出选择；最后是详细说明区域，用于描述 AI 工具的具体用途，例如是用于代码生成、文档撰写、测试创建还是仅用于语法检查。这种结构化的披露方式既降低了贡献者的填报门槛，又确保了信息的完整性和可追溯性。
社区成员 yawaramin 在 PR 评论中建议进一步扩展模板，将 Developer Certificate of Origin（DCO）等其他合规要求也纳入同一份清单。这个建议反映了一个重要的工程实践：披露机制不应孤立存在，而应与其他贡献者合规流程整合，形成完整的质量门禁。
贡献指南的文档规范
CONTRIBUTING.md 是开源项目与贡献者之间的契约文档。Ghostty 的 AI 披露政策在此文件中占据独立章节，详细说明了政策制定的背景、适用范围和执行方式。
文档的核心内容包括四个维度。第一是政策说明，解释为何项目要求披露 AI 使用 —— 不是为了排斥 AI，而是为了维护代码质量和社区协作的健康度。第二是适用范围，列举需要披露的具体场景，如使用 GitHub Copilot、Claude CodeCursor 等工具进行代码编写，或使用 ChatGPT、Claude 等对话式 AI 进行设计讨论或文档创作。第三是豁免条件，明确排除简单关键词补全、IDE 内置的静态分析建议等场景。第四是执行方式，说明披露信息将用于 PR 审查优先级评估，但不构成代码被拒绝的绝对理由。
文档还提供了具体的披露示例，帮助贡献者理解如何准确描述自己的 AI 使用情况。例如，一个规范化的披露声明可能这样写：「本 PR 中的配置文件修改使用了 GitHub Copilot 进行语法补全和关键字建议，核心逻辑由本人撰写并审查。」这种示例驱动的文档设计显著降低了贡献者的理解成本。
CI 层面的自动化检查方案
虽然 Ghostty 当前的政策主要依赖荣誉制度，但社区已经提出了多种 CI 自动化检查方案。这些方案虽然尚未在 Ghostty 项目中实施，但对于其他希望强化披露政策执行力的开源团队具有直接参考价值。
Pre-commit 钩子是第一道自动化防线。通过配置 pre-commit 框架，项目可以在代码提交前自动检查 PR 描述中是否包含 AI 披露声明。GitGuardian 的 ggshield 工具已经支持通过 pre-commit 集成进行 secret 扫描，其模式可以扩展到 AI 披露检查。典型的 pre-commit 配置如下：在 .pre-commit-config.yaml 中添加自定义钩子，该钩子读取 PR 描述并使用正则表达式或关键词匹配检测是否包含「AI」「Copilot」「Claude」等披露标识符。如果检测失败，钩子可以输出提示信息并阻止提交，或仅输出警告但不阻断流程。
GitHub Actions 是云端 CI 检查的天然载体。一个典型的 AI 披露检查 Action 可以在 PR 创建或更新时触发，读取 PR 主体内容并与预设的披露模板进行比对。如果发现 PR 缺少必需的披露声明，Action 可以输出检查失败结果，甚至通过 GitHub API 自动添加「needs-disclosure」标签。更进一步，Action 还可以读取已更改文件的内容，通过静态分析检测是否存在 AI 生成代码的典型特征 —— 虽然这种检测的准确率存疑，但可以作为辅助手段。
社区成员 tobi 在 PR 评论中提出了一个更具野心的建议：GitHub 应该发布一个 AI byline 标准。这个标准将要求所有 AI 工具在提交时自动向一个特殊的 git 暂存文件写入自己的标识信息，类似于 Co-authored-by 的机制。这样，维护者可以在 commit message 中看到所有参与代码生成的 AI 工具列表，而 AI 工具也能获得标准化的曝光方式，避免当前各自为政地在 co-authors 中「蹭流量」的现象。
社区影响与采纳情况
Ghostty 的 AI 披露政策已经在开源社区引发了连锁反应。antiwork/.github 项目在 PR 提交次日即采纳了类似的披露要求，增加了 comprehensive AI Assistance Notice 章节，直接引用 Ghostty PR #8289 作为政策依据。Buildkite/agent 项目也在同期添加了类似的披露需求（见 PR #3433）。这些跟进表明，Ghostty 的实践正在成为开源社区的一种参考范式。
值得注意的是，政策制定者本身也在严格遵守自己建立的规则。Mitchell Hashimoto 在 PR 描述末尾特别声明：「本着这份 PR 的精神…… 本 PR 的内容没有任何是 AI 生成的。lol。」这种「以身作则」的态度对于政策的长期执行至关重要 —— 如果政策制定者都不遵守，贡献者更难以形成合规习惯。
对于希望在项目中实施类似机制的开源维护者，Ghostty 的经验提供了几条可操作的建议。首先，披露阈值应该足够明确，避免「灰色地带」带来的执行困难；将简单的语法补全与实质性的代码生成区分开来是合理的。其次，披露机制应该嵌入现有的贡献流程，而不是增加独立步骤；PR 模板整合是最自然的方式。再次，政策应该伴随充分的文档解释，说明「为什么」需要披露，而非仅仅声明「必须披露」。最后，虽然自动化检查可以增强执行力，但当前阶段以荣誉制度为主、自动化为辅是更务实的选择；过度依赖技术手段可能引发规避行为和社区反感。
AI 辅助开发已经成为不可逆转的趋势。Ghostty 的 AI 披露政策既不排斥这一趋势，也不放任其带来的质量风险。这种平衡立场 —— 承认 AI 的生产力价值，同时要求透明和责任 —— 或许代表了开源社区在 AI 时代最理性的应对方式。
资料来源：Ghostty GitHub 仓库 PR #8289（2025 年 8 月 19 日合并），CONTRIBUTING.md 文档。