# 将 AI 使用策略编码为可执行规则：Ghostty 的实践与工程落地参数 > 解析 Ghostty 终端项目的 AI 使用披露策略，探讨如何将政策声明转化为可审计的代码规则，并给出 PR 模板、CI 检查与合规监控的工程化参数。 ## 元数据 - 路径: /posts/2026/01/24/ghostty-ai-usage-policy/ - 发布时间: 2026-01-24T02:02:15+08:00 - 分类: [security](/categories/security/) - 站点: https://blog.hotdry.top ## 正文 在开源协作中，AI 辅助编程已成为常态，但随之而来的质量隐患也日益凸显。Ghostty 终端项目维护者 Mitchell Hashimoto 在 2025 年 8 月发起的一项政策变更，将 AI 工具使用披露从道德倡议推向了可执行的工程规则。这一实践为如何将政策声明编码为机器可验证的规则提供了可参照的范本。 ## 问题背景：AI _slop_ 与维护者的注意力困境 Hashimoto 在 Pull Request #8289 中坦言：「在 AI 时代，披露 AI 工具使用是一种基本的礼貌。」他观察到，在理想世界中，AI 辅助应产生与人类相当或更高的代码质量，但现实是大多数情况下它生成的是缺乏维护价值的代码片段。他将这种现象称为「AI slop」——即由缺乏经验的开发者驱动 AI 工具生成、但他们自己无法充分审查和理解的代码。 这一问题的核心在于维护者的注意力分配。Hashimoto 指出：「我会尽力协助经验不足的贡献者，引导他们完成代码提交，因为让 PR 被接受是一种值得骄傲的成就。但如果对面只是 AI，我不需要付出这些精力，而欺骗我付出这些精力是不礼貌的。」因此，AI 使用披露的本质不是惩罚，而是为维护者提供评估审查深度的上下文信息。 ## 策略声明：从道德倡议到可执行规则 Ghostty 的 AI 使用政策声明包含以下核心要点：任何超越简单 tab 补全的 AI 辅助都必须披露；贡献者需明确说明 AI 使用的范围，例如仅用于文档还是包含代码生成；由 AI 生成的 PR 响应同样需要披露。值得注意的是，政策明确将「仅限于单个关键词或短语的简单 tab 补全」排除在披露要求之外，这一阈值划分避免了过度合规的负担。 政策的工程化实现依赖于三个层面的协同：贡献指南的文本声明、PR 模板的强制填写字段，以及社区对违规行为的监督机制。这种分层设计使政策既保持足够的可见性，又不引入过重的技术实施成本。 ## 工程落地参数：PR 模板与披露字段设计 在实际落地中，Ghostty 采用的策略是向 PR 模板添加显式的 AI 使用声明字段。根据 PR 讨论中的建议，一个有效的模板应包含以下元素：首先是强制性的单选或复选框组件，询问「本次提交中是否使用了 AI 工具辅助代码编写」；其次是条件性的文本输入区，仅在用户勾选「是」时显示，要求详细描述 AI 工具的使用方式、生成代码在整体变更中的占比，以及贡献者对 AI 生成内容的审查程度。 对于 CI 层面的自动化检查，可配置的基础参数包括：在 PR 主体检查中验证披露字段非空；通过正则匹配检测 PR 描述或正文中是否包含常见的 AI 工具关键字（如 Copilot、ChatGPT、Claude、DeepSeek 等）；对于使用 AI 生成代码比例超过 50% 的变更，触发高风险标记以提醒维护者进行更深入的审查。这些阈值可根据项目规模和维护资源动态调整，初期建议将高风险阈值设定为 30%，随着团队审查能力提升再逐步放宽至 50% 或更高。 ## 监控与审计：合规数据的长期追踪 AI 使用政策的长期有效性依赖于持续的数据监控。推荐维护团队建立以下追踪指标：每月的 AI 披露率，即声明使用 AI 的 PR 数量占总 PR 数量的比例，这一比例的健康区间应维持在 15% 至 35% 之间，过低可能意味着政策宣传不足或存在未披露的 AI 使用，过高则需要审视代码审查流程是否足够高效；AI 辅助代码的审查通过率，即声明使用 AI 的 PR 被接受合并的平均周期与非 AI PR 的对比，异常延长的审查周期可能表明现有的披露粒度不足以支撑审查决策；以及 AI 披露合规后的代码回滚频率，用于评估 AI 生成代码是否确实带来了更高的维护成本。 对于追求更高自动化程度的团队，可考虑在提交历史中嵌入结构化的 AI 元数据。PR 讨论中提出的「AI byline」方案建议在 commit message 中以标准格式列出所有参与的 AI 工具，类似于 Co-authored-by 的设计，这为后续的代码溯源和审计提供了更细粒度的数据基础。 ## 政策演进的边界条件 Ghostty 的实践表明，AI 使用政策的成功取决于对「适度使用」边界的清晰定义。当前政策将披露要求限定在「超越简单 tab 补全」的范畴内，这一定义在实际执行中需要维护团队持续校准。建议团队在政策引入初期建立 FAQ 文档，记录常见场景的判定案例，例如使用 IDE 内置的 AI 语法建议是否需要披露、让 AI 解释现有代码并手动实现是否属于披露范围等问题。 另一个值得关注的边界是政策的时间适用范围。Hashimoto 明确表示他本人也使用 AI 辅助编程，但强调「在严格监督下」使用。这意味着政策设计需要区分「使用 AI 的开发者」与「被 AI 使用的开发者」，前者是政策期望培养的协作模式，后者是政策试图防范的风险来源。 ## 资料来源 本文核心事实来源于 Ghostty 项目的 Pull Request #8289，该 PR 于 2025 年 8 月 19 日合并，引入了 AI 工具披露要求。Hashimoto 在 PR 描述中详细阐述了政策动机，强调披露是帮助维护者评估审查深度的信息，而非排斥 AI 辅助的门槛。这一实践已被多个开源项目借鉴，展示了将政策声明转化为可审计工程规则的可行性路径。 ## 同分类近期文章 ### [微软终止VeraCrypt账户：平台封禁下的供应链安全警示](/posts/2026/04/09/microsoft-terminates-veracrypt-account-platform-lock-risk/) - 日期: 2026-04-09T00:26:24+08:00 - 分类: [security](/categories/security/) - 摘要: 从VeraCrypt开发者账户被终止事件，分析Windows代码签名的技术依赖、平台封禁风险与开发者应对策略。 ### [GPU TEE 远程认证协议在机密 AI 推理中的工程实现与安全边界验证](/posts/2026/04/08/gpu-tee-remote-attestation-confidential-ai-inference/) - 日期: 2026-04-08T23:06:18+08:00 - 分类: [security](/categories/security/) - 摘要: 深入解析 GPU 可信执行环境的远程认证流程，提供机密 AI 推理场景下的工程参数配置与安全边界验证清单。 ### [VeraCrypt 1.26.x 加密算法演进与跨平台安全加固深度解析](/posts/2026/04/08/veracrypt-1-26-encryption-algorithm-improvements/) - 日期: 2026-04-08T22:02:47+08:00 - 分类: [security](/categories/security/) - 摘要: 深度解析 VeraCrypt 最新版本的核心加密算法改进、跨平台兼容性与安全加固工程实践，涵盖 Argon2id、BLAKE2s 及内存保护机制。 ### [AAA 游戏二进制混淆：自研加壳工具的工程现实与虚拟化保护参数](/posts/2026/04/08/binary-obfuscation-in-aaa-games/) - 日期: 2026-04-08T20:26:50+08:00 - 分类: [security](/categories/security/) - 摘要: 解析 AAA 级游戏二进制保护中的自研加壳工具、代码虚拟化性能开销与反调试实现的技术选型。 ### [将传统白帽黑客习惯引入氛围编程：构建 AI 生成代码的防御纵深](/posts/2026/04/08/old-hacker-habits-for-safer-vibecoding/) - 日期: 2026-04-08T20:03:42+08:00 - 分类: [security](/categories/security/) - 摘要: 将传统白帽黑客的安全实践应用于氛围编程，通过隔离环境、密钥管理与代码审计，为 AI 生成代码建立防御纵深，提供可落地的工程参数与清单。