想像一下，你的 AI 助理剛剛產生了 200 行程式碼。從法律上說，你可能一行都不擁有；但從法律上說，任何它送出的 bug，責任仍然算在你頭上。這兩句話之間的落差，就是明天你要合併的程式碼真正面對的問題。

整個議題就是活在這個落差裡。產生程式碼的工具不能被起訴；模型不能被追究責任；供應商的合約早就用大多數開發者從沒讀過的語言寫得很清楚：責任會一路往下流，流到按下 Tab 的人身上。

有趣的地方不在於這個落差存在，而在於幾乎沒有工程團隊真的把它當一回事。過去兩年，我們一直在慶祝生產力提升；但花在思考當速度撞上著作權主張、合規稽核或正式環境事故時該怎麼辦的時間，卻少得多。讓我們拆開來看：法院實際說了什麼、你的工具合約實際寫了什麼、法律的懸崖在哪裡，以及一個理性的工程團隊要怎麼處理這整件事，既不封殺 AI，也不假裝問題不存在。

那個沒有人簽字的交接

軟體所有權以前是個已經定案的問題。你寫程式碼，你的雇主付錢請你寫，勞動契約把著作權轉給他們，公司再用自己想要的授權方式把產品發出去。三個角色（你、你的雇主、使用者）之間的界線很清楚。如果出了問題，使用者去找公司抱怨，公司回頭看 commit 紀錄，然後某個人會在 1 對 1 裡被低調地聊一聊。

AI 助理把第四方塞進了這個結構，而這個第四方的合約，和其他任何一方都不一樣。模型沒有簽你的勞動契約；供應商不是你發版流程的一部分；他們的 EULA 也不是長得像聘僱合約，而是長得像免責聲明。你拿到建議、你保留建議，然後你也一併保留它附帶的一切：bug、授權義務、安全漏洞，以及未來任何監管機關決定要來查這個建議是怎麼來的。

這個交接是無聲發生的。你的 IDE 裡沒有一個核取方塊寫著：「我接受這個補完所帶來的法律責任。」你只是按下 Tab。介面的設計讓它看起來像自動完成，而多數開發者也把這個心智模型延伸過去：編輯器只是幫我打字更快，程式碼還是我的，整個程式碼庫的所有權沒有改變。這個心智模型幾乎對，但也幾乎完全錯，取決於你問的是哪個問題。

法院實際做了什麼決定

在美國，現在有兩個法律核心點，聽到的人通常都會讓開發者感到意外。

第一個：在美國，著作權保護需要人類作者。這不是新規則。這跟 2018 年那起決定猴子不能為自拍照主張著作權的規則是一樣的；但它在 Thaler v. Perlmutter 這個案子裡又重新接受了壓力測試。那是一起關於由 AI 系統產生、且沒有實質人類介入的影像案件。2025 年 3 月，華盛頓特區聯邦上訴法院維持下級法院的判決：1976 年《著作權法》「要求所有合格作品在最初就必須由人類創作」。沒有人的作者，就沒有著作權。那個輸出會落入公眾領域。

第二個，也是開發者真正身處其中的地方：美國著作權局在 2024 年到 2025 年初，一直在試圖為「有人類參與」的 AI 輔助作品劃出界線。2025 年 1 月，該局公布指引，說 AI 輸出只有在有人類貢獻「足夠的表達性元素」時，才有資格取得著作權。單純下提示詞，即使是複雜、反覆迭代的提示詞，也不夠。該局報告中引用的一則意見，用了一個讓開發者感受特別深的比喻：重複下提示詞就像在轉輪盤。人類選了，但人類沒有以足夠精確的方式控制輸出的表達性元素，因此不算作者。

這個比喻比措辭本身更重要。在著作權的語境裡，「按 Tab 接受」就是在轉輪盤；而「按 Tab 接受，然後改四行、重構函式、加上保護子句，並把它整合進你原本就設計好的類別」則是另一回事。這時候，人類的貢獻才開始接近著作局要找的那種表達性控制。

實際影響是：你 AI 工具吐出來、而你幾乎沒動過的程式碼，未必像上週你資深工程師親手寫的程式碼那樣屬於公司資產。它不算「被偷走」，但也不一定能以通常能讓公司主張權利的方式成為公司可主張著作權的資產。公司不能去告別人抄它；也不能把它當成可以有力主張的資產。公司可以發布、出貨、修改它，但它周圍的法律護城河，比大家以為的要薄得多。

一旦跨過邊界，情況就變了。英國自 1988 年《著作權、設計與專利法》第 9(3) 條以來，就一直明確處理「電腦生成作品」，把作者歸給「為創作該作品而進行必要安排的人」。印度也採類似做法。歐盟則正在透過 AI 法案進行更大膽的重構，這部分我們後面會再提。重點是：現在並沒有單一的全球答案。同一週、同一模型、同一份程式碼，從倫敦辦公室寫出來，和從舊金山寫出來，所有權故事可能完全不同。

你的工具合約到底寫了什麼

GitHub 的 Copilot 產品特定條款裡，有一句話最能說明問題，也是 AI 導入會議上幾乎沒人引用的一句：

「您保留對您程式碼的全部責任，包括您納入程式碼中或用以開發程式碼的建議。」

這句話同時在做兩件事。一方面，它把一樣東西交給你：GitHub 表示它不主張這些建議的所有權，所以這些建議不會以競爭性主張的形式出現在你的程式碼庫裡。另一方面，它也把另一樣東西交給你：所有伴隨這些建議而來的法律風險，包括訓練資料裡的開源授權義務、和你程式碼長得很像的其他開發者的著作權主張、以及建議本身的缺陷。供應商條款明確寫著，你有責任判斷你對輸出的使用是否需要第三方授權，並遵守任何這類授權。

如果你像開 README 一樣讀 GitHub 的客戶協議，只掃描安裝說明，你就會錯過那一條。如果你像律師一樣讀，整份文件其實就是在講這一條。

這種結構不只出現在 Copilot。幾乎所有 AI 程式助理的條款都長得一樣：供應商否認對輸出的所有權，客戶承擔對輸出的責任。之所以每家都這樣，是因為這是供應商唯一能 عملی運作的結構。想像相反的情況：供應商保證每個建議都沒有授權負擔、沒有 bug、也不會有著作權爭議。他們無法對一個訓練自整個 GitHub 公共語料的模型做出這種保證。所以合約只能把風險推給唯一有可能評估它的人：合併程式碼的人類。

模型無法讀懂你程式碼庫的授權條款；供應商不知道你的產業會接受哪個主管機關的監管；IDE 也不知道你現在做的是個興趣網站，還是支付處理系統。能夠錨定責任的地方，只剩下按下合併按鈕的人所在之處。

入職訓練裡沒人提的賠償缺口

問題到了這裡就開始不舒服了，而多數工程組織架構在這裡會有個盲點。

GitHub 的確提供針對建議的智慧財產賠償保護，但前提是你使用的是 Business 或 Enterprise 方案。如果你因為 Copilot 重現了別人一段程式碼而被告侵權，Microsoft 會根據它的 Customer Copyright Commitment 出面抗辯並支付損害賠償。整個產業大致都是這樣：多數主流 AI 程式工具在企業方案層級都提供某種形式的賠償保護。

如果你用的是個人方案，這些都不適用。你拿到的是同一個模型、同一批建議、同樣的風險面，但沒有任何法律遮罩。如果將來法院認定 Copilot 給你的某段程式碼，實質上重現了別人 GPL 授權的程式碼，那出問題的人就是你，個人。

這件事之所以重要，不只是在律師辦公室裡重要；很多正式產品仍然是由這種團隊出貨：工程師用自己的個人 Copilot 訂閱，可能是因為公司還沒標準化，可能是因為有人在公司採用企業方案前六個月就先辦了，或只是因為個人帳號的設定比較順手。這些工程師產出的程式碼流進公司程式庫，而公司以為自己已經有的賠償保護，因為公司付了 Enterprise 費用，實際上卻不涵蓋那些透過個人訂閱產生的建議。

工程領導幾乎從不檢查這件事。採購團隊以為 Enterprise 合約涵蓋全部；開發者不知道合約其實是按「哪個訂閱產生了建議」來劃線；只有等到訴訟真的降臨，資安長才會發現問題。

一個乾淨的責任故事，要求每個 IDE、每台開發者機器、每個共用環境都跑在有賠償保護的方案上。「我們買了 Enterprise」 不等於 「所有碰到我們 repo 的建議都來自 Enterprise」。

65 個詞素的過濾器，以及它擋不住什麼

如果你讀過 GitHub 的安全文件，你會找到一個叫做重複偵測過濾器的功能。這個過濾器會把建議拿去和 GitHub 上的公開程式碼比對；如果某個建議包含大約 65 個詞素以上的程式碼片段（約 150 個字元，大概是一兩段密集程式碼的長度），而且又和公開程式碼足夠接近，那這個建議就會被抑制。管理員可以在企業層級啟用這個過濾器，而多數合理的導入指南都會建議你保持開啟。

當團隊談到 Copilot 的授權風險時，這個過濾器是最常被提到的緩解手段。它也很能說明「功能存在」和「功能解決問題」之間的落差。

65 個詞素這個門檻不是隨便定的。它是在召回率和可用性之間做平衡。若某個過濾器連任何三個詞的公開程式碼比對都要擋，那 Copilot 幾乎所有建議都會被擋掉，因為三詞序列幾乎出現在所有開源專案裡。所以門檻被設得高得多，落在一個區間裡：這種比對更可能是刻意相似，而不是偶然相似。設計合理，但代價是：低於這個門檻的內容會不經過濾直接流過去。

一段 30 個詞素、而且和某個 GPL 授權儲存庫片段完全相同的函式主體，可能會進到你的程式碼庫裡，而過濾器根本看不到。50 個詞素的慣用寫法、常見演算法實作、解析器片段、序列化輔助函式，可能會跟數十個儲存庫一模一樣，卻從來沒跨過那條線。這個過濾器沒有宣稱能抓到全部；它宣稱能抓到那些最可能支撐著作權主張的長篇近似重複。短篇內容則落在法律本身還沒決定「實質相似」到底是什麼的灰色地帶。

這時候，你做的是可 دفاع的判斷，而不是完美判斷。過濾器有幫助；把它當成完整解法就不對了。把它想成你信箱裡的垃圾郵件過濾器：有用、常常默默正確，但不能取代你不要打開陌生人的附件。

監管機關不在乎是誰寫的

美國的著作權討論聚焦在「所有權」；歐洲的監管討論聚焦在「對結果的責任」，而這個出發點真的不一樣。

歐盟有三部法規正在匯流成某些實務界稱作的「合規三位一體」：AI 法案、資安韌性法案（Cyber Resilience Act, CRA）與產品責任指令（Product Liability Directive, PLD）。它們各自從不同角度看待 AI：AI 法案依風險等級管制 AI 系統，CRA 對連網產品施加資安義務，PLD 則把包含軟體在內的缺陷產品責任加諸其上。它們都有一個共同假設：監管機關不在乎你的程式碼是人寫的、AI 工具寫的、外包商寫的，還是訓練有素的雪貂寫的；他們在乎的是進到市場的產品。

2026 年 8 月 2 日，是多數開發者最可能聽到的里程碑。那是 AI 法案許多實質義務開始生效的時間，包括 AI 生成內容的透明揭露要求，以及更積極的執法權限。一般的開發者輔助 AI 使用，通常不會單獨把系統拖進高風險類別；但如果 AI 被用在像勞工評估或關鍵元件生成這類用途，就絕對可能。分類看的是系統在現實世界做了什麼，而不是幫忙寫程式的是什麼工具。

更難的轉變，是這一切暗示的文化變化。AI 助理出現之前，「有沒有仔細寫」和「產品安不安全」這兩個問題，大致指向同一件事：寫程式的人，也正是對程式負責的人。AI 助理介入之後，這兩個問題可能開始分岔。即使每個看過 diff 的人都發誓自己有認真看，產品仍然可能不安全。監管機關不接受「是 AI 建議的」這種解釋，程度不會比他們接受「是承包商寫的」更高。你把它送出去了；責任就是你的。

一旦接受這點，這個框架其實很清楚。不舒服的是，大家半成形地以為 AI 工具帶來某種分散式責任，彷彿供應商因為訓練了模型就要一起背鍋。他們沒有；合約上明確說沒有。而監管機關也禮貌地拒絕替你發明這種共享責任。

沒人提醒你的文化問題

除了法律文字之外，還有一種更柔性的模式，正在工程團隊內部悄悄侵蝕責任感，而這跟合約一點關係都沒有。

研究 AI 輔助開發的人已經開始記錄一件多數資深工程師早就感覺得到的事：由 AI 助理產生的程式碼，通常會得到比人類手打程式碼更不仔細的審查。審查者花在它上面的時間更少；抓到的問題更少；也更可能把一個能編譯、看起來合理的函式直接放行。部分原因是疲勞，因為現在要審查的程式碼比以往都多，因為那個曾經限制輸出的打字成本消失了。部分原因是隱性信任：模型讀過的程式碼比任何活著的審查者都多，所以它的輸出會自帶一點不自覺的權威感。還有一部分，只是介面設計造成的：接受是預設動作，拒絕才是摩擦。

問題不在於這些反應單看都不合理；而在於它們會往 更少 的責任感方向疊加，而不是更多。diff 變成兩倍長，審查卻變得只有一半仔細；原本會對防禦性空值檢查提出尖銳問題的人，正忙著往下滑看接下來三個建議。每一行合併程式碼分到的人類注意力單位下降，抓到 bug、授權問題，或模型根本沒意識到自己做錯的細微授權錯誤的機率也跟著下降。

這不是反對 AI 工具。這只是大多數團隊還沒在儀表板上補上的那一條問題：如果我們產出更多程式碼，我們有沒有相對更仔細地審查，還是因為量變大而放鬆了審查？ 沒人會把這問題說出口，因為那會拖慢進度。而上面的監管框架，無論哪一個，都不會替你回答這個問題。

一個可運作的責任模型長什麼樣子

你不可能靠一篇 Slack 貼文解決這些問題；就算寫成政策文件也不行，除非那份政策真的改變了程式碼進到 repo 的方式。那些處理得好的團隊，都在做四件很平凡、也一點都不聰明的事。

他們把方案所有權做得很無聊。每位開發者、每個共用環境、每個使用 AI 助理的 CI runner，都在有賠償保護的方案上。沒有個人訂閱可以拿來做公司工作的逃生門。這是採購層級的無聊決策，但一次就能補上大部分漏洞。

他們預設開啟重複偵測過濾器，且可被驗證。這個過濾器在管理控制台裡是啟用的，而且像 SSO 強制一樣，是定期資安審查的一部分。這不是某個星期二有人可能順手打開的設定，而是一個受稽核的控制措施。

他們在 code review 裡，把 AI 生成的程式碼視同第三方依賴。模型產生的新程式碼，在心理上會被當成 2014 年某位資深工程師從 Stack Overflow 複製貼上的回答。你會問：我真的懂它在做什麼嗎？我知道它來自什麼授權形態嗎？如果模型不存在、無法替我指著它，我還會簽下這段程式碼嗎？ 這個問題把整套倫理和法律機制壓縮成一句審查者真正能內化的話。

他們明確指定擁有者。每個 PR 都要有一位對裡面程式碼負責的人。不是模型，不是供應商，不是「整個團隊」。是某個具名的人，程式壞掉時會接電話的人。如果你的工具鏈讓你很難記住 AI-heavy PR 的那個人是誰，那就是流程問題，值得修，因為上面其他框架要有效，前提都得是最後有一個名字。

註
這些都不需要法務團隊或合規長。前三步只是管理控制台設定和 code review 檢查清單上的一句話。第四步則是一種文化常態，而好團隊對人寫程式早就有這種文化。AI 唯一帶來的新東西，只是你不能因為量變多了就跳過其中任何一步。

能把整件事撐住的那一句話

如果你只記得這篇文章的一件事，就記這句：每一個 AI 建議，都是來自一個匿名第三方的貢獻；這個第三方讀過網際網路上所有開源專案，而你完全無法訪談他；而且你的合約已經明白把他排除在責任鏈之外。

這不是叫你停止使用 AI 助理的理由；甚至也不是叫你放慢速度的理由。這就是這段關係的真實形狀，而軟體工程中的摩擦之所以一直回到這裡，就是因為這個形狀不會自己消失。法院正在往這個方向收斂；供應商早就把合約建在這個前提上；監管機關也即將開始執行。

如果這也算好訊息，那好訊息是：答案從來不在模型裡。答案在原本就應該是最無聊、也最嚴謹的工作流程那一段，也就是人看著 diff，決定要不要合併的那一步。那一步從來沒有像現在這樣重要過；而你的團隊處理整個所有權問題，最便宜的方法，就是確保那一步依然會發生，而且要像建議開始每分鐘出現兩次之前一樣仔細。

你寫下了那個 merge commit。責任就是你的。

P.S. 感謝您花時間閱讀這篇文章！文中表達的想法與觀點皆屬於我本人。英文不是我的母語，所以我會使用 AI 協助校正文法，讓我的寫作更清楚、也更容易閱讀。如果有些地方仍然有點不自然，還請見諒！

原文發表於 nazarboyko.com。

原文出處：https://dev.to/nazar-boyko/ai-and-code-ownership-who-is-responsible-for-generated-code-1dnj