Graphite 开源项目的 AI 贡献政策：边界、披露要求与合规实践指南-二趣网

Graphite 开源项目的 AI 贡献政策：边界、披露要求与合规实践指南

【免费下载链接】GraphiteCommunity-built comprehensive 2D content creation appplication for graphic design, digital art, and interactive real-time motion graphics powered by a node-based procedural graphics engine项目地址: https://gitcode.com/GitHub_Trending/gr/Graphite

本文解读 Graphite 项目《AI contribution policy》这一贡献者指南页面，围绕"什么程度的 AI 使用被允许、什么行为会被封禁、以及如何履行披露义务"展开。结合仓库中的 PR 模板、提交贡献指南与 CI 配置，帮助计划向 Graphite 提交代码的开发者理解政策边界，并在真实提交流程中合规落地。

政策背景：低质量 AI 提交对开源项目的实际伤害

Graphite 项目以 Rust 编写，是一个由社区志愿者构建的 2D 内容创作应用，代码库横跨 editor、node-graph、frontend 等多个大型子工作区，代码评审本身就是一项高成本活动。政策开篇明确指出，许多开源项目（包括 Graphite）正在遭受越来越多由 AI 部分或完全编写的低质量 PR 的"淹没"式冲击。这类 PR 的直接危害有两方面：

浪费维护者时间：审查低质量提交挤占了维护者审查真实贡献的时间；
挤压真实贡献者：垃圾 PR 使得真正贡献者的 PR 无法及时获得审查。

因此 Graphite 采取的态度是：对付出努力的贡献者保持合理与理解，但同时设立严格规则来对抗"低努力 PR"（low-effort PR）。从仓库证据看，这一立场并非停留在文档层面，而是被强制固化进了提交流程——PR 模板第一行即写着 "Graphite has ZERO-TOLERANCE for contributing undisclosed AI-generated content"，并要求提交者删除模板规则后填写"严格由人类撰写"的 PR 描述。

可接受的 AI 使用方式：两条明确边界

政策将"允许"的行为限制在非常窄的范围内，且按使用方式区分是否需要披露：

非 Agent 工具的辅助性使用（无需披露）

Non-agent AI tools mayassistwith debugging and tab-completion of single lines of code you would have otherwise written yourself. This does not require disclosure.

允许场景：非 Agent 形态的 AI 工具，用于调试（debugging）以及单行代码的 Tab 补全（tab-completion）；
前提：这些代码行"本来就是你打算自己写出来的"——AI 只是帮你少敲几下键盘；
披露义务：无。

这一条对应的是 IDE 中的补全与错误提示类工具，本质上属于"打字效率工具"而非"内容生成器"，因此被排除在披露要求之外。

AI 聊天工具生成小片段（需要披露）

AI chat tools (not agents) may help yougeneratesmall (sub-40 line) snippets of code that you manually copy and paste, provided that you carefully review every line to ensure it is consistent with how you would have written it yourself. This requires disclosure.

允许场景：AI 聊天工具（而非 Agent）帮助生成小于 40 行的代码片段；
操作方式：必须由你手动复制粘贴（manually copy and paste），并逐行仔细审查，确保与你自己会写出的风格一致；
披露义务：需要披露。

这里出现了一个量化的边界：40 行。小于 40 行的片段，人工逐行审查后仍可接受；超过这一规模的生成内容则不在"可接受"清单内。同时注意两个限定词："not agents"（不是 Agent）与"manually copy and paste"（手动复制粘贴），这两点共同划定了"AI 是工具、人负责全部判断"的边界。

不可接受的 AI 使用方式：红线与封禁后果

政策明确列出了严格禁止的行为，并将它们定性为"对项目的恶意垃圾邮件攻击"：

AI slop, "vibe-coded", or agent-written PRs are strictly forbidden and may be treated as malicious spam attacks against the project, resulting in a ban.

AI slop：指低质量的 AI 批量生成内容；
"vibe-coded"：指"凭感觉用 AI 堆代码"式的开发方式；
Agent 编写的 PR：由 Agent 自主完成并提交的 PR。

这三类行为严格禁止，可能被当作对项目的恶意垃圾邮件攻击处理，导致封禁（ban）。

另一条容易忽略的禁令涉及沟通文本：

PR description text and replies to reviewers must be written by you, not AI. If your English is imperfect, just try your best; it is better than AI babble.

PR 描述与给审查者的回复必须由你本人撰写，不能用 AI；
政策甚至给出了明确的态度：如果英文不完美，尽力去写即可，"这比 AI 的胡言乱语要好"（better than AI babble）。

这条规则的信号很明确：项目团队重视的是贡献者真实的理解与沟通，而非文笔。这也与提交贡献指南中的警告相呼应——该指南在"代码审查礼仪"一节写道：如果错误严重到一定程度，可能被判定为 AI 生成的垃圾信息，并根据 AI 贡献政策导致封禁。

强制披露要求：零容忍与自审注释

政策对披露提出了最严格的要求，这是全文的核心：

Graphite haszero-tolerancefor contributing undisclosed AI-generated content.
A detailed, human-written description must accompany every line of material that you did not personally write using your own brain. It should justify why each line is correct and appropriate. This should be prepared ahead of time and written as self-review comments on the GitHub PR's diff immediately after the PR is opened or new code is pushed.

拆解如下：

零容忍：未披露的 AI 生成内容，是绝对不被接受的（undisclosed = 无例外）；
逐行披露：对每一行"不是用你自己的大脑亲自写的"材料，都必须附上一段详细、由人类撰写的描述，说明该行为何正确、为何恰当；
前置准备：这段描述应提前准备好（prepared ahead of time），而不是事后补救；
落点与时机：在 PR 打开之后或推送新代码之后，立即以 GitHub PR diff 上的**自审注释（self-review comments）**形式发布。

注意"every line of material that you did not personally write using your own brain"的措辞——它覆盖的不只是代码，还包括任何非本人撰写的材料；而"immediately after the PR is opened or new code is pushed"则明确了披露的时间窗口，意味着你不能在维护者追问后才补上说明。

实操要点：如何撰写自审注释

结合政策要求与提交贡献指南中关于 self-review 的流程，一套合规的自审注释应包含：

位置：GitHub PR 的 "Files changed"（diff）标签页，逐行或逐块添加评论；
内容：声明该行/该块由 AI 工具生成（注明使用的工具类型），随后用你自己的语言解释该代码为何正确——包括它解决的问题、为何采用这种写法、以及你审查过哪些潜在错误；
语气：保持与项目沟通一致的技术化描述，而不是让 AI 代写这段说明（说明本身必须是 human-written）；
时机：PR 打开或每次推送新代码后立即完成。

政策在仓库中的落地：从文档到强制流程

AI 贡献政策并非孤立的文档，而是与仓库中的多个机制形成闭环。以下是从源码与配置中可以确认的配套事实：

1. PR 模板中的强制声明

.github/pull_request_template.md 将零容忍政策直接嵌入每个 PR 的创建流程：

顶部声明 "Graphite has ZERO-TOLERANCE for contributing undisclosed AI-generated content"，并链接到本政策页；
提醒提交者"对变更的成功实现与无回归负有全部测试责任"；
明确警告："Egregiously dysfunctional PRs may be assumed to be undisclosed AI slop"——即功能严重失常的 PR 可能被直接推定为未披露的 AI 垃圾内容；
建议包含变更前后的视频与 UI 截图；
要求提交者在描述中删除全部模板规则，填写严格人工撰写的 PR 描述。

2. 提交指南中的引用与流程衔接

submitting-a-contribution.md 在多个环节引用 AI 政策：

"AI usage"一节要求任何使用 AI 工具的贡献者，在提交 PR 前必须阅读并遵守本政策；
"Self-review"一节再次要求在 diff 上披露 AI 生成的代码行；
"Code review etiquette"一节警告明显错误可能被判定为 AI 垃圾并导致封禁。

这说明披露不是一次性动作，而是贯穿"创建 PR → 自审 → 评审"全流程的持续义务。

3. CI 质量门槛作为配套防线

从 .github/workflows/check.yml 可以看到，项目用 CI 建立了与 AI 政策互补的硬性质量门槛：

cargo test --all-features：在自托管原生 runner 上运行全部 Rust 测试；
cargo fmt --all -- --check：格式化检查；
cargo-deny：许可证与依赖合规检查；
提交指南要求本地运行cargo test --all-features、cargo fmt、cargo clippy通过后再推送。

这些门槛无法直接识别"AI 生成"，但它们让"未经验证、无法构建、行为反常"的提交难以通过，配合"功能严重失常即推定 AI slop"的政策，形成质量与归属的双重防线。此外，代码质量指南要求代码保持可读、有注释、通过 clippy 检查——从源码结构看，这些要求同样对"AI 批量堆代码"的产物构成约束。

给贡献者的合规行动清单

综合政策正文与仓库配套机制，向 Graphite 提交代码时建议按以下清单自检：

区分工具形态：确认你使用的是"辅助工具"（补全、调试）还是"生成工具"（聊天模型生成片段）。只有前者免于披露；
控制生成规模：任何由 AI 聊天工具生成的片段应控制在 40 行以内，并且是你手动复制粘贴的；
逐行审查：对每个片段逐行阅读，确认其符合你本人会写出的风格与质量；
如实披露：对每个非本人撰写的代码行，在 PR 的 diff 上以人工撰写的自审注释说明"由 AI 生成 + 为何正确"；
人工撰写沟通文本：PR 标题与描述、对审查者的回复全部自己写，英文不完美可以接受；
保证可构建性：推送前本地通过cargo test --all-features、cargo fmt、cargo clippy，避免被判定为未经验证的垃圾提交；
主动沟通：如果对任务理解或边界有疑问，可以在项目的 Discord 开发频道中确认后再提交，避免因"明显功能失常"而被误判为 AI slop。

结语

Graphite 的 AI 贡献政策在"包容合理使用"与"打击垃圾提交"之间划出了一条清晰、可执行的界线：40 行以内的片段可人工审查后使用，非 Agent 工具可免披露辅助，但任何 AI 生成内容都必须逐行披露，而 AI slop、vibe-coding 与 Agent PR 则面临封禁。政策的意义不在于抵制工具，而在于确保每一行进入仓库的代码都经过真实人类的判断与背书——这正是维护一个志愿者驱动的开源项目可持续运转的前提。对于贡献者而言，理解并遵守这一政策，不仅是对维护者时间的尊重，也是让自己的真实工作获得公平审查的基础。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析