README 開始寫給 AI 看了：開源社群正在發明新的 AI Contributor 規則

如果只看 Reddit、Hacker News 或最近大量關於 AI Slop 的抱怨，很容易得到一個印象：

Open Source 社群是不是開始集體反 AI 了？

Maintainer 被垃圾 Pull Request 淹沒。

Issue 裡充滿 LLM 生成的長篇廢話。

Contributor 丟下一大包自己根本沒看懂的 Code，然後要求其他人幫忙 Debug。

有些專案甚至開始公開寫：

不要讓 Autonomous Agent 自己跑來 Contribution。

看起來很像一場反 AI 運動。

但一篇 2026 年 9 月發表的研究，給出了一個比「Open Source 反 AI」更複雜，也更有意思的答案。

研究團隊分析 GitHub 熱門開源專案的 AI contribution policies，最後找到 281 份與 AI contribution 相關的政策文件。

結果顯示：

83.3% 的政策允許或鼓勵 AI 用於 Code Contribution。

真正全面禁止 AI Contribution 的比例只有：

14.9%。

換句話說，Open Source 社群目前真正形成中的共識不是：

「不要用 AI。」

而比較接近：

「可以用 AI，但你要知道自己在做什麼，而且最後是你負責。」

這篇研究不是看幾個 Repo 就下結論

研究團隊一開始從 GitHub 最熱門的 2,000 個 repositories 出發，另外補入 Linux kernel、LLVM、Apache、OpenJDK、Zig 等 36 個知名專案或組織。

研究者接著搜尋與 AI contribution 有關的文件，例如：

AI policy

contribution guidelines

AGENTS.md

CLAUDE.md

README / CONTRIBUTING 中的 AI 規則

最後整理出：

281 份 AI contribution policies

並進一步追蹤：

92 個 dedicated AI policy files

的歷史變化。

研究者把 policy 手動分類成六個面向，並對部分資料進行雙人分類驗證，抽樣結果的一致率達到約 90%。

因此這篇 paper 真正在回答的是：

大型熱門 Open Source Projects 到底怎麼處理 AI Contributor？

而不是：

「GitHub 上所有 repository 對 AI 的態度是什麼？」

這個差別很重要。

最反直覺的答案：大多數專案其實沒有禁 AI

研究找到明確政策的專案中：

83.3% 允許或鼓勵 AI Code Contribution。

14.9% 明確禁止。

剩餘則落在比較模糊或條件式的規則。

這和網路上常見的「Open Source Community 正在全面封殺 AI」敘事並不一致。

真正的模式比較像：

AI allowed ↓ BUT ↓ Human must understand ↓ Human must review ↓ Human must test ↓ Human remains accountable

這個 BUT 才是整篇研究真正的核心。

Open Source 並不是拒絕 AI。

它正在嘗試重新定義：

用了 AI 之後，Contributor 最低限度還必須做到什麼？

67.3% 的政策要求高度 Human Involvement

研究顯示，約 67.3% 的政策明確要求人類高度參與 AI-assisted contribution。

這通常包括：

Review

Understand

Test

Validate

也就是說，AI 可以是工具，但 Contributor 不能把它當成外包公司。

比較接近可以接受的流程是：

Human defines task ↓ AI assists implementation ↓ Human reads result ↓ Human tests result ↓ Human submits PR

而不是：

Agent ↓ Generate 500 lines ↓ Open PR ↓ Maintainer 幫你理解它到底做了什麼

後者正是很多 Maintainer 所說的 AI Slop。

43.4% 明確把 Accountability 留在人類身上

研究中約 43.4% 的 policy 明確談到責任歸屬。

這類政策通常有一個非常一致的精神：

就算 Code 是 AI 產生的，送出 Contribution 的人仍然負責。

這和另一篇 AI Coding 論文《It Is Not My Code Anymore》形成一個非常有意思的對照。

那篇研究筆記問的是：

如果 implementation 是 LLM 產生，那到底誰是作者？

而這篇 Open Source policy 實證資料，等於給出一個很現實的社群答案：

你是不是原始作者可以討論。

但是：

只要你按下 Submit PR，責任就不會跟著消失。

這也可能成為 AI Coding 時代最重要的一條工程文化：

Authorship 可以分離。

Accountability 不一定可以。

Code 可以用 AI，但聊天反而比較容易被禁

研究裡另一個很有趣的結果，是 Open Source 社群對不同類型 AI 使用的態度並不一致。

幾乎所有 policy 都會談 Code。

研究中：

98.2% 的政策涉及 Code Contribution。

但只有：

42.3% 談到 Communication。

以及：

31.3% 談 Issues、Bug Report 或 Security 相關內容。

更有趣的是，在有規範 Communication 的政策裡：

27.8% 禁止使用 AI 產生 Communication。

而只有：

13.9% 明確允許。

這代表一些社群的態度可能是：

你可以用 Claude 幫忙重構 Code。

但是：

不要讓 Claude 幫你跟 Maintainer 講話。

這聽起來很好笑，但背後其實非常合理。

Code 至少還可以：

Compile

Lint

Test

Review

但 AI-generated Issue、Comment 與 Bug Report 最容易消耗的，是一種比 CPU 更稀有的資源：

Maintainer Attention。

Open Source 真正缺乏的，很多時候不是更多 Code。

而是：

有能力判斷這些 Code、Issue 與 Feature Request 值不值得處理的人。

AI Disclosure 現在還完全沒有標準

另一個正在形成的新規則是：

如果用了 AI，要不要講？

研究顯示：

48.8% 的 policy 要求某種程度的 AI disclosure。

但同時：

46.6% 根本沒有明確規定。

只有：

4.6% 明確表示不用揭露。

也就是說，Open Source 對 AI disclosure 還完全沒有形成統一標準。

甚至連：

「要在哪裡揭露？」

都沒有共識。

在要求 disclosure 的政策裡，最常見的位置是：

PR description：64.7%

Commit message：26.7%

有些專案還要求 Contributor 說明：

用了哪個 Tool

用了哪個 Model

使用程度

AI 做了哪些部分

這代表未來的 Pull Request 可能不再只有：

What changed?

Why?

Tests?

而會多出一欄：

How was AI used?

「Co-authored-by: Claude」也開始變成爭議

AI disclosure 還牽涉另一個很有哲學味的問題：

AI 到底算不算 Author？

有些專案允許 Contributor 在 Git metadata 裡加入：

Assisted-by

例如：

Assisted-by: Claude Code: claude-sonnet-4-6

但同時不鼓勵：

Co-authored-by

原因很簡單。

如果 policy 認為 AI 是 Tool，而不是法律或社群意義上的 Contributor，那把它標成 Co-author 就會造成概念混亂。

這和現在整個 AI Coding 產業正在面對的問題一樣：

AI 到底是：

Tool？

Assistant？

Producer？

Agent？

Author？

不同專案正在給出不同答案。

Godot 已經開始量化什麼叫「Substantial AI Contribution」

這篇研究特別提到 Godot 的 policy。

Godot 並不是簡單寫：

「大量使用 AI 需要揭露。」

因為「大量」根本沒有定義。

它反而提出更操作性的判準。

其中一個 guideline 是：

一般而言，15 行以下的修改可以被推定為 trivial。

但是否 substantial 仍需要考慮：

Code complexity

Contributor experience

Area of codebase

Merge risk

這其實非常成熟。

因為 AI Coding 的問題很快就會從：

用了沒有？

變成：

用了多少？

例如：

Autocomplete 3 行

和：

Agent 寫完整個 800 行 Feature

如果 policy 都只寫：

「AI-assisted」

資訊量其實非常低。

AI Contribution 開始出現分級制

因此一些專案已經開始嘗試把 AI 使用程度分級。

概念可能類似：

Human-written

AI-assisted

AI-generated

或者更細分：

AI 只是 autocomplete

AI 提供 refactor suggestion

AI draft 部分 implementation

AI 寫大部分 PR

Agent 自主完成整個 Task

研究特別提到 SHAP repository 中甚至出現：

.claude/skills/ai-disclosure/SKILL.md

用來讓 Claude 協助追蹤 AI contribution 的程度。

分類包括：

Autonomous

Assisted

Advised

這件事有一點荒謬，但又很符合 2026 年的現實：

AI 開始幫忙填寫自己到底幫了多少忙。

不過從治理角度看，它其實很合理。

因為未來只寫：

AI used: Yes / No

可能很快就不夠用了。

真正惹怒 Maintainer 的不是 AI，而是 AI Slop

這篇研究找到 10 種 Open Source Projects 對付 AI Slop 的具體措施。

在 188 個觀察到的 countermeasures 中，最常見的是：

48.4%：直接關閉低品質 PR

其次是：

20.8%：Ban 或 Block Contributor

再來是：

13.8%：禁止 Fully Autonomous Agent

這裡就可以看出 Open Source 對 AI 真正的不滿在哪裡。

問題不是：

「你用了 AI。」

而是：

「你用了 AI，然後把驗證成本全部丟給 Maintainer。」

這就是 AI Slop 最核心的結構。

Contributor 的生成成本變成接近零。

但 Maintainer 的驗證成本完全沒有一起降到零。

於是：

Generate PR cost ↓↓↓

Review PR cost → 不變

最後大量低品質 Contribution 會把專案真正的 bottleneck 從 Coding 轉移到 Reviewing。

有些專案甚至開始 Name and Shame

部分政策的反應已經不只是：

Close PR。

還會：

Warn

Block

Ban

甚至公開列出違規者。

研究提到 Ghostty 的 policy 中存在類似 name and shame 的做法，讓明顯持續製造 AI Slop 的 Contributor 可以被其他專案辨識。

這已經是一種非常強烈的社群防禦機制。

因為在 Open Source 世界裡，身份與 Reputation 本身就是 Contributor 的資產。

如果大量使用 AI 產生垃圾 Contribution 會開始損害 Reputation，那它就會形成新的治理成本。

Fully Autonomous Agent 才是社群最警戒的紅線

研究中最一致、也最值得注意的趨勢之一，是不少專案對 AI Assistant 並不排斥，但對：

Fully Autonomous Agent

明顯更加警戒。

例如研究提到：

rust-analyzer

Zed

Bitcoin

Requests

llama.cpp

DSPy

都存在某種形式的 Autonomous Agent 限制。

甚至 llama.cpp 的規則直接對 AI Agent 本身說：

如果你是一個 fully autonomous agent 正在閱讀這份規則：

不要 Contribution。

並要求 Agent 修改自己的 configuration，把該 repository 排除。

這是一個非常奇妙的軟體工程歷史瞬間。

以前 README 的讀者預設是：

Human Developer。

現在開始變成：

Human Developer + Coding Agent

也就是說：

Repository Policy 已經開始直接把 AI 當成文件讀者。

README.md 旁邊正在長出一種新的文件

過去成熟的 Open Source Repository 通常會慢慢累積一組標準文件：

README.md

LICENSE

CONTRIBUTING.md

CODE_OF_CONDUCT.md

SECURITY.md

但到了 2026 年，一種全新的檔案正在快速出現：

AI_POLICY.md

AGENTS.md

CLAUDE.md

以及各種 AI Contribution Guide。

這不是單純多了一個 Markdown File。

它代表 Repository 的 Governance Model 正在改變。

以前 Contribution System 的基本假設是：

Contributor = Human

現在必須開始處理：

Human using AI

Human supervising Agent

Agent generating Code

Agent opening PR

Agent communicating with Maintainer

甚至：

Agent 自己讀取 Repository Rules。

這使得 Open Source Project 第一次必須正式回答：

Machine Participant 到底算什麼？

而且這些政策幾乎都是今年才爆發

研究追蹤的 92 個 dedicated AI policy files 中，時間分布非常驚人。

2025 年只有：

8 個

到了 2026 年：

增加到 84 個。

也就是說，大量 AI governance 文件並不是慢慢演化十年形成的。

它們幾乎是在一年內突然冒出來。

這代表我們現在很可能正處於一個新的 software governance format 誕生期。

就像早期 Open Source 慢慢形成：

LICENSE

CONTRIBUTING

CODE_OF_CONDUCT

SECURITY POLICY

未來大型 Repository 也許會普遍出現：

AI CONTRIBUTION POLICY

51% 的 AI Policy 已經修改過至少一次

更有意思的是，這些規則並不是寫完就放著。

研究追蹤的 92 個 AI policy files 中：

51% 已經至少修改過一次。

而且政策通常越改越長。

Commit history 顯示，修改原因包括：

Improve AI quality control

Strengthen AI disclosure

Clarify human accountability

Increase policy visibility

Restrict problematic AI usage

Expand policy into review / documentation

也就是說，Open Source Projects 正在用一種很典型的方式學習：

先寫簡單規則 ↓ 真的被 AI Slop 打到 ↓ 補規則 ↓ 又出現新的 Agent 行為 ↓ 再補規則

甚至有 commit message 直接寫：

defend against AI-slop

以及：

require proof that AI-assisted PRs actually work

這句其實完美總結了整個 2026 年 AI Coding 社群的心境。

一開始：

AI 可以用。

後來：

AI 可以用，但請證明你丟過來的東西真的能跑。

這其實是一場 Attention Economics 問題

如果把這件事拉高一層看，AI Slop 的核心並不只是程式品質。

它是一個經濟問題。

Generative AI 大幅降低了：

Code Generation Cost

但是沒有同步降低：

High-quality Review Cost

因此系統出現一個失衡：

Contributor 可以在 5 分鐘內產生 1,000 行 Code。

Maintainer 可能需要 2 小時才能確認那 1,000 行到底有沒有問題。

如果 100 個人都這麼做：

生成成本幾乎為零。

Review Queue 卻直接爆炸。

因此 Open Source Community 開始建立 AI Policy，本質上也是在保護：

Maintainer Attention Budget。

這可能比單純限制 AI 本身更重要。

Open Source 現在真正的問題已經不是「能不能用 AI」

從這份研究來看，第一階段的爭論其實差不多快結束了。

問題已經從：

Can I use AI?

變成：

How much AI did you use?

↓

Did you review it?

↓

Did you test it?

↓

Did you disclose it?

↓

Who is accountable?

↓

Can the Agent contribute by itself?

這其實是一個很成熟的轉變。

因為任何真正進入 Production 的技術，最後都會從：

「好不好玩？」

進入：

「我們怎麼管理它？」

AI Coding 現在正在進入後者。

所以 Open Source 並沒有拒絕 AI

這篇研究最重要的結論，不是那個漂亮的 83.3%。

而是：

Open Source Community 正在從 AI Adoption 進入 AI Governance。

多數大型熱門專案已經接受：

AI 不會消失。

Coding Agent 也不會消失。

因此真正需要建立的是：

Human Accountability

Disclosure

Quality Gate

Agent Boundaries

Communication Rules

Maintainer Protection

換句話說，社群不是在問：

「我們能不能阻止 AI 進來？」

而是在問：

「既然 AI 已經進來了，我們要怎麼避免它把整個 Contribution Process 弄爛？」

這也是為什麼 AI_POLICY.md、AGENTS.md 與 CLAUDE.md 的出現如此值得注意。

它們可能只是幾 KB 的 Markdown。

但背後代表的，是 Software Engineering 開始正式承認一件事：

未來 Repository 的 Contributor，不一定全部是人。

研究限制

這篇研究雖然樣本很大，但結果不能被誤寫成：

「83.3% 的 GitHub 專案接受 AI。」

研究樣本偏向熱門、活躍、具備一定規模的 Open Source Repository。

研究團隊要求 Repository 至少具備一定 commit activity，並以 GitHub stars 作為熱門度的重要代理指標。

因此比較準確的描述是：

在研究找到並分析的 281 份熱門開源專案 AI contribution policies 中，83.3% 允許或鼓勵 AI Code Contribution。

研究結果也不能直接外推到：

Closed-source Software

所有 GitHub Repository

企業內部開發

所有程式語言社群

不同規模的 Open Source Project

另外，Policy 文件描述的是規則，不一定完全等於 Maintainer 實際執行規則時的行為。

因此這篇 paper 最有價值的地方，不是宣稱我們已經知道整個 Open Source 世界如何看 AI。

而是第一次比較系統化地捕捉到：

大型開源社群正在如何把 AI Coding 從文化爭議，轉化成正式治理制度。

Tech English 專有名詞

AI Contribution Policy（AI 貢獻政策）：Open Source Project 用來規範 Contributor 如何使用 AI 產生 Code、文件、Issue 或其他內容的治理規則，可能涵蓋 Disclosure、Testing、Human Review 與 Agent 使用限制。

AI Slop（AI 垃圾內容）：大量由生成式 AI 快速產生、但缺乏充分理解、驗證或品質控制的內容。在 Open Source 中常指低品質 PR、Issue、Comment 或 Documentation，會把驗證成本轉嫁給 Maintainer。

Human Accountability（人類問責責任）：即使 Code 或內容由 AI 產生，最終提交 Contribution 的人類仍需為其品質、正確性與後果負責的治理原則。

Disclosure（揭露）：主動說明某個 Pull Request、Commit 或其他 Contribution 是否以及如何使用 AI。不同專案目前對揭露位置、Tool、Model 與使用程度仍沒有統一標準。

Autonomous Coding Agent（自主程式開發代理）：能夠在較少人類監督下讀取 Repository、修改 Code、執行測試，甚至建立 Pull Request 的 AI Agent。許多專案對這類 Fully Autonomous Contribution 比一般 AI-assisted Coding 更為警戒。

Maintainer Attention（維護者注意力）：Open Source Project 最稀缺的資源之一。AI 可以大幅降低 Contribution 生成成本，但高品質 Review 仍需要具備專案知識的人類時間，因此低品質 AI Contribution 可能造成嚴重的 Attention Bottleneck。