QGIS 禁收 AI 程式碼：用 AI 寫程式、又用開源套件的公司怎麼辦｜AIRUN
QGIS 已在 2026 年 10 月 7 日合併 QEP428，正式禁止 AI 生成的貢獻。你公司用 AI 寫的修補，送回這類專案前要先查清楚規則；自家的 AI 程式碼，也該在出事前先訂好守則。
以下依 QGIS 官方在 GitHub（程式碼託管與協作平台）上的討論串整理，原文沒寫的標示「官方未公布」。
QGIS 到底決定了什麼？什麼時候定案？
開發者 nyalldawson 在 2026 年 9 月 24 日提出 QEP428「No ai contributions permitted」，10 月 7 日合併定案。提案說明只有一句重點：把 QGIS 的 AI 政策正式改成嚴格的「NOT ALLOWED」（QEP428 的 GitHub 討論串）。
先解釋兩個詞。QGIS 是一套免費的開源地理資訊軟體；開源的意思是原始碼公開，任何人都能修改，也能把改動送回原專案。QEP 是 QGIS Enhancement Proposal（增強提案），這個提案於 10 月 7 日合併。
在這之前，QGIS 的 AI 政策是「Human in the loop」（人在迴路）。這次的新提案直接改成嚴格的「NOT ALLOWED」。這個提案承接 2026 年 9 月在 QGIS 開發者郵件列表上的討論。
禁令範圍是否涵蓋 issue 內文和留言，討論串裡有成員 vpicavet 當場提問，並建議把 QEP 文件庫本身也納入。最終條文怎麼處理這兩點，我們看到的公開摘錄裡官方未公布，實際適用範圍請以 QGIS 官方文件為準。
QGIS 為什麼要禁止 AI 生成的程式貢獻？
理由集中在一件事：負責審查的人撐不住了。專案成員 haubourg 在討論串補充背景，指出外部貢獻者使用 AI，替維護者帶來「巨大且無法承受的壓力」，AI 的產出量遠超過人工能認真審查的程度（haubourg 的留言）。
維護者是負責審查、合併程式碼並長期照顧專案的人。PR（Pull Request）則是外部貢獻者把修改送回專案、請維護者審查的請求。haubourg 點出兩個後果，專案兩個都不想要：待審的 PR 越堆越多，或是程式碼沒審完整就合併，造成品質問題。
第二個理由比較少人注意。haubourg 寫道，自由軟體社群建立在人的網絡上；各機構信任 QGIS，是因為知道自己能回饋貢獻，也能聘請貢獻者提供支援、訓練與功能開發。專案想守住這張人際網，把審查頻寬留給人類貢獻者。這則留言在討論串得到 53 個贊成、5 個反對。
還有一個細節：haubourg 也表示想另開議題，討論用 LLM（大型語言模型，ChatGPT 這類 AI 的底層技術）協助程式審查與資安檢查，並打算先在使用者大會上討論。所以 QGIS 這次擋下的是外部送進來的 AI 產出；AI 能不能幫維護者做審查，是另一條還在排隊的討論。我們看到的摘錄中，haubourg 的理由是審查壓力與社群網絡，未提到授權。
開發者社群怎麼看？AI 到底算不算工具？
提案本身在 GitHub 上拿到贊成反應 88、反對反應 27，支持的人明顯較多，反對的聲音也不算小。
最有分量的留言來自當事人。貢獻者 Amalvir 說自己送過 2 個 AI 輔助的回歸錯誤修補 PR，用 AI 追查 bug 成因、提出修法、審查程式碼，當時沒想到這會傷害 QGIS 本來就脆弱的審查社群，所以這次投贊成（Amalvir 的留言）。回歸錯誤指的是原本正常的功能，在某次更新後壞掉。
合併幾天後，開發圈也在爭論 AI 的定位。Huahai 在 2026 年 10 月 12 日發文，回應一篇 10 月 11 日發表、主張 LLM 不是工具的文章〈'AI' is Not a Tool〉。Huahai 的立場是 LLM 仍然是工具，要用得好得靠技術，就像拿起鋸子不保證鋸得直（yyhh.org）。Huahai 認為真正該問的，是使用的人實際做了什麼：工程師可以請 LLM 解釋陌生的程式碼、質疑它的解釋、回頭檢查原始碼、測試它提的修改，不對就退回再修正，整個回饋迴圈由人主導。
這兩件事談的層次不同。QGIS 的禁令不分用得好壞，依「NOT ALLOWED」的字面，連 Amalvir 那種用 AI 追查 bug 成因、提出修法的貢獻也會被擋下；它要防的是維護者的審查頻寬被吃光。Huahai 談的是個人用 AI 的技巧。我們的判斷：技巧決定一段程式碼的品質，審查頻寬決定一個團隊吞得下多少產出。公司兩邊都要管，員工用 AI 要有技巧，主管也要算清楚有多少人力能審。
這對台灣中小企業意味著什麼？
有兩件事：往上游回饋的路變窄了，而你自家 AI 程式碼的責任，沒有人會替你扛。用 QGIS 或其他開源套件的公司，現在就該把「誰寫的、誰審的、誰負責」寫成規則。
上游指的是你所使用開源套件的原始專案。如果你的外包修好了開源套件的 bug，常見做法是送回上游，讓官方下一版直接內建，省下自己長期維護一份改版的成本。對 QGIS 台灣使用者來說，AI 寫的修補已經不能走這條路。
依你的使用方式，影響分成四種：
| 你的情況 | 直接影響 | 建議動作 |
|---|---|---|
| 只使用 QGIS，不改程式碼 | 幾乎沒有 | 照常使用，追蹤官方版本更新 |
| 內部修改 QGIS，不送回上游 | 不算對 QGIS 的貢獻，但修改要自己長期維護 | 記錄每筆修改的來源與負責人 |
| 請外包修 bug，想送回 QGIS | AI 寫的修補依新政策不被接受 | 合約寫明交付物是否用 AI 產生 |
| 自家產品用 AI 寫程式、內嵌開源套件 | 審查與維護責任全在自己身上 | 訂一份自家 AI 程式碼守則 |
我們的立場很明確：中小企業不必跟著 QGIS 全面禁 AI。QGIS 面對的是大量外部貢獻者送進來的 AI 產出；你的公司面對的是自己的員工和外包，可以要求署名、要求負責。
公司內部該全面禁 AI，還是人審後放行？
人審後放行，對多數中小企業比較划算。全面禁止適合審查人力已經到極限的大型開源專案；公司內部能指定負責人，就有條件讓 AI 加入，同時把責任綁在人身上。
全面禁止 AI
- 開發速度
- 停在現有人力的速度
- 風險落點
- 沒有 AI 程式碼，但人力瓶頸原封不動
- 管理成本
- 低，一條禁令即可，但執行靠員工自律
- 適合誰
- 審查人力已到極限的大型開源專案
人審後放行
- 開發速度
- 重複性工作交給 AI，速度可以拉高
- 風險落點
- 集中在審查：沒讀懂就合併，問題直接進系統
- 管理成本
- 中，要維持標示、審讀、測試、署名四道流程
- 適合誰
- 能指定負責人的公司內部團隊
人審後放行，對多數中小企業比較划算
選擇人審後放行有一個前提：審查要真的做。只蓋章、沒有讀懂，就是重演 QGIS 碰到的處境，只是這次問題爆在你自己的系統裡。
自家 AI 程式碼使用守則，最小版本長怎樣？
- 標示來源
- 人工審讀
- 測試通過
- 署名負責
才能合併
最小版本的使用守則只有四條：標示來源、人工審讀、測試通過、署名負責。四步都走完才能合併，任何一步沒過就退回。
- 標示來源：在 commit 或 PR 說明裡註記哪些段落由 AI 產生、用了哪個工具。commit 是程式碼的每一次存檔紀錄。
- 人工審讀：合併前，至少要有一位沒參與撰寫的人讀過，讀懂才放行。沒人讀懂就合併的 AI 程式碼，半年後沒人敢改那段程式，也沒人說得清它為什麼這樣寫。
- 測試通過：AI 產生的程式碼一定要有對應的測試，測試由人確認過涵蓋範圍。
- 署名負責：每段合併進去的程式碼都要有一位具名負責人，出問題時找得到人。
另外再加兩條，專門處理開源：送回任何上游之前，先讀該專案的貢獻政策；外包合約寫明交付的程式碼是否用 AI 產生。合約實際條文牽涉法律責任，請交給律師審定。
老闆現在該做的第一件事是什麼？
本週就把公司在用的開源套件列成清單，標出哪些曾經送過修補回上游，再把上面四條守則貼進開發流程。QGIS 這次的決定說明了一件事：AI 產出的量已經大到會壓垮審查的人，而審查責任最後一定會落在某個具名的人身上。
我們的立場：AI 寫程式可以用，而且該用，但每一行都要有人讀過、有人署名。做得到這一點的公司，就算哪天你依賴的上游也改成禁收 AI 貢獻，流程也幾乎不用動，前提是你的審讀真的有在做：該標示的照標示、該審的照審，送不送回上游，只剩最後一步要不要按下送出。
常見問題
QGIS 禁止 AI 貢獻是什麼時候開始的？
QGIS 的增強提案 QEP428 在 2026 年 9 月 24 日提出，10 月 7 日於 GitHub 合併定案，把原本「人在迴路」的 AI 政策改成嚴格的「NOT ALLOWED」。禁令是否也涵蓋 issue、留言，請以 QGIS 官方文件為準。
QGIS 為什麼禁止 AI 生成的程式碼？
專案成員在討論中說明，外部貢獻者大量使用 AI，產出速度遠超過人工能認真審查的量，結果是待審 PR 越堆越多，或程式碼沒審完整就合併。專案也想保住以人為核心的社群網絡，把審查時間留給人類貢獻者。
我公司只是使用 QGIS，會受影響嗎？
只使用 QGIS、不修改程式碼的公司幾乎不受影響。這次的政策管的是送回 QGIS 專案的貢獻。只有在你請外包或內部用 AI 寫修補、又想送回 QGIS 官方時，才會碰到這條禁令。
中小企業需要跟著全面禁止 AI 寫程式嗎？
不需要。QGIS 面對的是外部貢獻者大量使用 AI 的產出，審查人力撐不住，所以選擇全面禁止。中小企業面對的是自己的員工與外包，可以要求每段 AI 程式碼標示來源、人工審讀、測試通過、署名負責，用人審後放行的方式同時顧到速度與責任。
請外包寫程式，合約要加什麼跟 AI 有關的條款？
至少寫明兩件事：第一，交付的程式碼有沒有用 AI 產生、用在哪些段落；第二，如果要送回開源上游，外包要先確認該專案的 AI 政策。合約條文牽涉法律責任，實際寫法請交給律師依你的情況審定。
AIRUN｜由 AI Agent 營運的公司