# Ghostty AI 披露政策的工程落地：从 PR 模板到 CI 自动化检查 > 解析 Ghostty 终端模拟器的 AI 代码披露策略实现，聚焦 PR 模板配置、贡献指南要求与 CI 强制执行的工程参数。 ## 元数据 - 路径: /posts/2026/01/23/ghostty-ai-disclosure-runtime-enforcement/ - 发布时间: 2026-01-23T21:19:15+08:00 - 分类: [systems](/categories/systems/) - 站点: https://blog.hotdry.top ## 正文 当 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 文档。 ## 同分类近期文章 ### [好奇号火星车遍历可视化引擎：Web 端地形渲染与坐标映射实战](/posts/2026/04/09/curiosity-rover-traverse-visualization/) - 日期: 2026-04-09T02:50:12+08:00 - 分类: [systems](/categories/systems/) - 摘要: 基于好奇号2012年至今的原始Telemetry数据，解析交互式火星地形遍历可视化引擎的坐标转换、地形加载与交互控制技术实现。 ### [卡尔曼滤波器雷达状态估计：预测与更新的数学详解](/posts/2026/04/09/kalman-filter-radar-state-estimation/) - 日期: 2026-04-09T02:25:29+08:00 - 分类: [systems](/categories/systems/) - 摘要: 通过一维雷达跟踪飞机的实例，详细剖析卡尔曼滤波器的状态预测与测量更新数学过程，掌握传感器融合中的最优估计方法。 ### [数字存算一体架构加速NFA评估：1.27 fJ_B_transition 的硬件设计解析](/posts/2026/04/09/digital-cim-architecture-nfa-evaluation/) - 日期: 2026-04-09T02:02:48+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析GLVLSI 2025论文中的数字存算一体架构如何以1.27 fJ/B/transition的超低能耗加速非确定有限状态机评估，并给出工程落地的关键参数与监控要点。 ### [Darwin内核移植Wii硬件：PowerPC架构适配与驱动开发实战](/posts/2026/04/09/darwin-wii-kernel-porting/) - 日期: 2026-04-09T00:50:44+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析将macOS Darwin内核移植到Nintendo Wii的技术挑战，涵盖PowerPC 750CL适配、自定义引导加载器编写及IOKit驱动兼容性实现。 ### [Go-Bt 极简行为树库设计解析：节点组合、状态机与游戏 AI 工程实践](/posts/2026/04/09/go-bt-behavior-trees-minimalist-design/) - 日期: 2026-04-09T00:03:02+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析 go-bt 库的四大核心设计原则，探讨行为树与状态机在游戏 AI 中的工程化选择。