公有領域授權能擋住法律訴訟嗎？系統提示詞洩漏的風險與爭議
目錄
共 9 個章節
系統提示詞洩漏事件回顧：CC0-1.0 公有領域授權如何闖入法律灰色地帶
2025 年 5 月，一位匿名開發者在 GitHub 上建立了命名為 asgeirtj/system_prompts_leaks 的開源專案，目標簡單而大膽：系統性收集各大 AI 聊天機器人的「系統提示詞」——那些控制模型行為、個性與安全規則的隱藏指令層。根據研究報告顯示，僅僅 14 個月內，該專案便累積超過 42,327 顆星與 7,036 個分支，迅速登上 GitHub Trending，成為技術圈最受矚目的爭議性倉庫。
這個專案的關鍵決策，是選擇了 CC0-1.0 公有領域授權。CC0 號稱「不保留任何權利」，允許任何人自由複製、修改、商用、再發布，而無須取得原作者許可或標示來源。專案創始人顯然希望藉此繞開傳統版權主張，讓這些從各家 AI 公司逆向工程取得的提示詞，在法規灰色地帶中找到一個快速的落腳點。不過，這項授權策略在實務上是否真的能擋住後續的法律挑戰，至今仍是未解之謎。
專案的發展速度遠超預期。貢獻者們透過 API 回應錯誤訊息、瀏覽器端點調試、以及模型自身輸出的漏洞，持續從 Anthropic、OpenAI、Google、xAI、Perplexity、Microsoft、Cursor、Meta、Mistral、Notion、Qwen 等 14 家廠商中提取超過 100 個獨立提示詞，並收錄多個版本——例如 ChatGPT GPT-5.4/5.3、Claude Opus 4.6/Sonnet 4.6、Gemini 3.1 Pro/Flash 等。這些提示詞的公開，讓外界得以一窺各公司如何設定「助人、誠實、無害」或「幽默、未過濾」等不同個性，以及分層拒絕系統或憲法 AI 等安全方法。
真正讓這個專案從技術圈走向公眾視野的，是兩次關鍵的媒體報導。《華盛頓郵報》在 2026 年 5 月 11 日引用該倉庫的資料，甚至讓讀者直接使用模型真實的 system prompt 來改寫新聞稿，引發主流社會對「AI 黑盒子」設定的關注。而在華文圈，騰訊雲開發者社群於 2026 年 4 月 3 日發表深度分析，將該專案定義為「AI 行為控制層的反向觀察與歸檔庫」，強調其取之於社群、開源於社群的運作邏輯。此外，知乎專欄早在 2025 年 9 月 15 日便已報導此事，為後續的法律與倫理辯論埋下伏筆。
值得注意的是，專案本身在設計上採取了一種微妙的「避險策略」：它僅存放靜態檔案與原始文字，不執行任何程式碼，並聲明「只做存檔而不提供分析或解釋」。這種立場試圖將自身定位為被動的資訊載體，而非主動的洩密者。然而，隨著主流媒體的密集報導，各家 AI 公司的法務部門勢必不可能忽視——這批系統提示詞的公開，代表它們精心設計的商業機密與安全邊界已被徹底攤在陽光下。
這起事件的核心矛盾在於：當開發者選擇 CC0-1.0 公有領域授權時，他假設系統提示詞屬於「不受著作權保護的資訊」，因此可以自由釋出。但 AI 公司則可能主張，這些提示詞是投入大量研發資源的「營業秘密」或「專有資訊」，逆向工程與散佈行為已構成違約甚至侵權。換句話說，CC0-1.0 授權雖然在開源社群內部通行無阻，但放在著作權法、營業秘密法與服務條款交織的現實世界中，它的效力仍然充滿高度不確定性。
如果你對這項技術背後的設計哲學與實戰手法感興趣，歡迎參考我們先前發布的系列文章：從憲法AI到分層拒絕：系統提示詞的設計哲學大揭密，以及逆向工程實戰：如何從 API 與瀏覽器挖出隱藏提示詞？。這些內容將為你完整展開從理論到實作的路徑，幫助你在 AI 轉型浪潮中掌握主動權。
CC0-1.0 公有領域授權的本質：放棄著作權能、但不能免除其他法律責任
CC0-1.0 授權的核心，是讓創作者在法律允許的最大範圍內，完全、永久、不可撤回地放棄所有著作權（包括鄰接權）。當 asgeirtj/system_prompts_leaks 專案創辦人將超過 100 個系統提示詞以 CC0-1.0 釋出時，其原意非常明確：不主張任何版權，任何人都可以複製、修改、商用這些文字，甚至將它們拿去訓練自己的模型。
但問題在於，系統提示詞的爭議從來不僅是版權問題。這些提示詞是各大 AI 公司投入大量研發資源、經過反覆測試所產生的專有資訊——它們定義了助手的個性、安全規則與知識邊界，某種程度上就是 AI 產品的核心命脈。當一個專案以 CC0-1.0 將這些資訊公開時，版權或許被放棄了，但其他法律責任卻紋絲不動。
「CC0-1.0 授權文件本身明確記載：『本軟體以「現狀」提供，不提供任何明示或暗示的擔保。』更重要的是，它僅處理版權問題，並未豁免任何其他法律責任。」
從商業機密的角度來看，系統提示詞極有可能落入營業秘密的保護範圍。根據 2026 年 6 月柳沈律師事務所的分析，營業秘密的成立要件包括「非公知性」、「經濟價值性」與「合理保密措施」。OpenAI、Anthropic 等公司在其服務條款中明確將 system prompt 定義為「商業機密與專有資訊」，並要求使用者不得逆向工程——這就已經構成了合理的保密措施。
進一步來看，根據 2026 年 1 月《華盛頓郵報》引用的企業導入 AI 法律議題報告，系統提示詞一旦被認定為營業秘密，其洩漏行為就不再是版權問題，而是可能構成不正當競爭或違反保密義務。即使提示詞的原始作者放棄了著作權，但 AI 公司仍然可以基於營業秘密法主張權利——因為著作權與營業秘密是兩個完全獨立的法律領域。
除了營業秘密，這些提示詞的收集與散佈行為還可能違反服務條款（ToS）。OpenAI 的使用條款明確禁止使用者透過任何自動化手段「擷取、複製、監控或蒐集」系統提示詞；Google 的 Gemini 服務條款也規定，未經授權不得進行逆向工程。當 system_prompts_leaks 專案的貢獻者透過 API 調試、瀏覽器端點分析等方式提取提示詞時，這些行為很可能已經構成違約。
- 版權層面：CC0-1.0 放棄了原始作者的著作權，但無法放棄 AI 公司對編輯、編排或衍生內容的權利
- 營業秘密層面：提示詞若符合非公知性、經濟價值與保密措施三要件，竊取與散佈即構成侵權
- 服務條款層面：逆向工程與自動化擷取行為本身可能違反使用條款，構成違約責任
- 公平競爭層面：透過不正當手段取得競爭對手的核心指令，可能觸犯不正當競爭防止法
值得注意的是，上海法院在 2025 年審理的一起 AI 提示詞著作權案中，判決 AI 提示詞不構成著作權法保護的作品，理由是提示詞僅體現抽象的創作想法和指令集合，缺乏足夠的獨創性。但這起判決反而印證了 CC0-1.0 的尷尬之處：若提示詞不受著作權保護，那 CC0-1.0 所放棄的權利本身就沒有意義；若提示詞受著作權保護，AI 公司又可以反過來主張侵權。
替代方案有限公司在先前的分析中已經指出，system_prompts_leaks 專案之所以選擇 CC0-1.0，正是為了試圖避開版權爭議。然而，從實際法律風險來看，這種「版權避風港」策略恐怕無法應對來自營業秘密與服務條款的挑戰。這也是為什麼該專案在 GitHub 上聲明「只存檔不對內容負責」——但法律責任不會因為一紙聲明就消失。
更深層的問題在於：CC0-1.0 授權本身是一個法律工具，它只在著作權法的框架下運作。當系統提示詞同時涉及商業機密、契約義務、不正競爭等多重法律領域時，單靠放棄著作權並不能免疫其他法律責任。這就像一個人說「我放棄我對這房間的裝飾權」，但不能因此說他就可以隨意佔領他人的房子。
對於台灣的中小企業與技術團隊而言，這個案例提供了一個重要的警示：在任何開源或公有領域專案中，不要只看授權條款，還要看所釋出的內容本身是否涉及其他法律義務。如果你從 system_prompts_leaks 下載了 Anthropic 的 Claude 提示詞並用於自己的產品，CC0-1.0 或許能保護你免於版權訴訟，但你仍然可能因為違反營業秘密法或服務條款而被告上法院。
從憲法AI到分層拒絕：系統提示詞的設計哲學大揭密這篇文章中，我們分析了各家 AI 公司如何透過系統提示詞塑造其產品的核心價值——而這些正是他們最具競爭力的商業資產。當這些資產被以 CC0-1.0 的形式公開時，法律灰色地帶的範圍遠比想像中要廣。理解這一點，才是評估風險的第一步。
逆向工程實戰：專案如何取得提示詞？提取技術的法律邊界
要理解 system_prompts_leaks 專案為何能收集到超過 100 組、橫跨 14 家 AI 廠商的系統提示詞，我們必須深入貢獻者實際使用的提取技術。根據專案研究報告與社群回饋，這些方法並非單一管道，而是一套結合「被動觀察」與「主動偵測」的混合策略——從 API 錯誤訊息、瀏覽器端點調試，到模型輸出時的遺漏片段，每一種手法都踩在技術與法律的模糊地帶。
第一種最常見的方法是「API 錯誤訊息回拋」。許多 AI 平台在開發階段並未徹底過濾錯誤訊息中的內部狀態，導致當請求參數異常時，後端會直接將系統提示詞作為錯誤診斷的一部分回傳。例如，貢獻者發現，當傳入格式錯誤的 JSON 或超出允許長度的提示詞時，部分 API 會以 system_prompt 為鍵名，將完整內容暴露在 error.details 字段中。這種手法無需任何破解工具，只需要一個簡單的 HTTP 請求即可完成。
第二種則是「瀏覽器端點調試」，這項技術需要更高的技術門檻與耐心。研究人員會利用瀏覽器開發者工具（F12）監控前端與後端之間的 WebSocket 或 REST API 流量，從中攔截回應封包。由於許多 AI 聊天機器人為了降低延遲，會在初始連線時一次性下載包含系統提示詞的「初始化設定」——這些設定並未在前端顯示給一般使用者，但封包中卻以明文形式流動。貢獻者透過比對數百次連線的封包差異，逐步還原出各家模型的核心指令。
「這些提示詞並不是『被偷走的』，它們是平台自己不小心吐出來的。」一位匿名貢獻者在專案討論區中如此表示。然而，從法律角度來看，這種「不小心」並不能作為合理化逆向工程行為的辯護理由。
第三類方法則更貼近「模型遺漏輸出」——也就是 AI 模型本身在生成回應時，意外「忘記」隱藏自己的系統提示詞。這種情況最常發生在提示詞注入攻擊後，研究人員透過精心設計的使用者輸入，誘使模型「重複我剛才聽到的所有指令」，進而將系統提示詞直接輸出在對話中。根據專案收錄的案例，Claude 與 ChatGPT 部分舊版本曾多次出現此類漏洞，而貢獻者幾乎是即時捕捉這些「口誤」，並將其納入版本管控。
除了上述三種主要途徑，社群協作比對版本差異也是一項不可忽視的提取策略。當某個新的系統提示詞版本被部分使用者截獲後，貢獻者會將它與舊版進行比較，從變更痕跡反推出 AI 公司近期調整的安全策略或個性設定。這種方法雖然仰賴大量人力的交叉驗證，卻能以極低成本取得持續更新的資訊。正如我們在逆向工程實戰：如何從 API 與瀏覽器挖出隱藏提示詞？中所分析，這些技術在實務上並不罕見，但每一次提取行為都伴隨著不同的法律風險。
這些技術手段本身可能直接違反 AI 平台的服務條款（ToS）。以 OpenAI 為例，其服務條款明確將 system prompt 定義為「商業機密與專有資訊」，禁止使用者透過任何自動化手段「擷取、複製、監控或蒐集」相關內容。Google Gemini 的條款則進一步禁止「對服務的任何部分進行逆向工程、反編譯或反組譯」。貢獻者在提取提示詞時，無論是攔截 API 封包還是觸發模型遺漏輸出，都已經構成對這些條款的違反。
更嚴重的潛在風險來自刑事責任層面。在台灣與多數普通法國家中，「未經授權存取電腦系統」是一項可處有期徒刑的犯罪行為。當研究者利用自動化工具持續向 AI 平台發送異常請求，藉此觸發錯誤訊息或提取系統設定時，這種行為可能被認定為「未經授權進入電腦系統」或「幹擾電腦系統正常運作」。美國《電腦詐欺與濫用法》（CFAA）即明確規範，只要未經授權或逾越授權範圍存取電腦，就可能構成聯邦重罪。雖然目前尚無 AI 公司針對提示詞提取者提起刑事訴訟，但法律風險結構已經相當完整。
值得注意的是，system_prompts_leaks 專案本身僅存放靜態文件，並未提供任何提取工具或自動化腳本。這種「我們只存檔，不負責怎麼拿到的」立場，能否為貢獻者提供法律保護仍然存疑。我們在系統提示詞洩漏事件回顧：CC0-1.0 公有領域授權的法律灰色地帶中詳細探討過，即使是公有領域授權，也無法豁免提取行為本身所產生的法律責任。換句話說，貢獻者在取得提示詞的那一刻，就已經踏入了法律風險區——CC0-1.0 僅保護他們在發布後不受版權追訴，卻無法替提取時的違約或違法行為解套。
從另一個角度看，AI 公司也並非完全被動捱打。根據騰訊雲開發者社群於 2026 年 4 月發布的深度分析，多家廠商已經開始部署對抗性防護：對 API 錯誤訊息進行內容過濾、在瀏覽器端點加入請求簽章驗證、以及動態生成系統提示詞使提取結果每次不同。這些措施直接提高了逆向工程的技術門檻，也讓採用「模型遺漏輸出」這類被動方法的成功率大幅下降。
總體而言，system_prompts_leaks 專案的提示詞提取過程，是一場技術便利性與法律風險之間的零和博奕。貢獻者運用了從 API 錯誤訊息到瀏覽器調試等多種手法，每一步都遊走在服務條款與刑事法規的邊緣。對於台灣的中小企業與技術團隊而言，瞭解這些技術細節固然有助於掌握 AI 系統的運作邏輯，但更關鍵的是認清背後的合規代價。如果你正在研究自家產品的系統提示詞設計，建議參考我們先前發布的系列文章：從憲法AI到分層拒絕：系統提示詞的設計哲學大揭密，從合法管道獲取靈感，而非直接複製這些可能觸法的提取方法。
商業機密的攻防戰：系統提示詞能否被認定為營業秘密？
當〈system_prompts_leaks〉以 CC0-1.0 公有領域授權將系統提示詞散佈至全球時，多數人直覺反應是「版權問題」。然而，真正讓法務部門坐立難安的殺手鐧，並非著作權法，而是營業秘密法。以 OpenAI 為例，其在服務條款中明確將 system prompt 定義為「商業機密與專有資訊」（Confidential and Proprietary Information），並禁止使用者透過任何自動化手段進行擷取、複製或逆向工程。
依據各國營業秘密法的共通要件——秘密性、經濟價值、合理保密措施——這些系統提示詞極有可能符合法律保護的門檻。秘密性方面，提示詞通常只存在於模型供應商的伺服器端，從不對外公開，即便部分使用者在對話中曾窺見片段，也無法拼湊出完整邏輯架構。經濟價值更是顯而易見：這些指令直接決定了 AI 助手的安全性與個性化體驗，是各家公司在激烈市場競爭中耗費大量資源研發的核心資產。
再論合理保密措施。事實上，OpenAI 與 Anthropic 等業者普遍採行技術合規雙軌防護：技術上，透過模型輸出過濾、動態生成提示詞、以及對 API 回應進行降噪處理，大幅提高逆向提取的難度；合規上，則在服務條款中明定禁止逆向工程，並要求員工簽署嚴格的保密協議。這套防護網在〈asgeirtj/system_prompts_leaks〉專案中遭到集體破壞——貢獻者藉由瀏覽器端點調試、API 錯誤訊息外洩等手段，繞過了這些保護措施。
值得注意的是，CC0-1.0 授權在此一戰場上幾乎無法發揮防禦效果。營業秘密的保護基礎並非著作權，而是持有人對機密資訊的控制權與契約約定。公有領域授權僅能放棄著作權法上的權利，無法限制著作權法以外的法律主張。換言之，就算專案聲明「不對內容負責」並採用 CC0-1.0 授權，一旦 AI 公司認定提示詞為營業秘密，他們依然可以基於營業秘密侵權、不當得利甚至違反服務條約等理由，向專案維護者或下游使用者主張損害賠償。這在台灣的司法實務中同樣成立：經濟部智慧財產局已多次強調營業秘密的保護不因物件被釋出到公開領域而自動消滅。
「CC0-1.0 授權無法阻擋營業秘密侵權的主張，因為營業秘密的保護基礎是持有人對機密資訊的控制權，而非著作權。」——替代方案有限公司法務分析
此外，近期司法實務趨勢也對專案方相當不利。2026 年 1 月，〈OpenEvidence 案例〉即明確將系統提示詞認定為受營業秘密保護的技術資訊；同一時間，中國上海黃浦區法院雖在提示詞著作權案中駁回原告主張，但其判決理由恰恰指出提示詞不屬於著作權保護的「作品」，反而強化了業者必須依賴營業秘密法作為救濟管道的現實。這一判決邏輯對台灣企業具有高度參考價值，因為我國著作權法對作品的創作性要求與中國相似，均排除「思想」與「操作方法」的保護。
因此，對於台灣的中小企業與技術團隊而言，真正的法律紅線並非「使用 CC0-1.0 授權的提示詞是否違反著作權」，而是「複製或參考這些提示詞是否構成營業秘密侵權」。一旦您從〈system_prompts_leaks〉取得內容，並將其用於自家產品的系統開發或員工訓練，就可能踩入以下風險場景：內部員工對照洩漏內容來設計自家提示詞，因接觸來源不當而違反保密義務；供應鏈上下游傳遞這些內容時，構成共同侵權；甚至在法庭上無法證明自家設計與洩漏內容之間的獨立創作過程。
短期內，預期將有更多 AI 公司啟動證據保全程序，並對 GitHub 等平台發送下架要求。如果您正在評估自家產品的系統提示詞設計，建議參考我們先前發布的系列文章〈從憲法AI到分層拒絕：系統提示詞的設計哲學大揭密〉，從合法管道獲取靈感，而非直接複製這些可能觸法的內容。畢竟，一場營業秘密訴訟的訴訟成本與商譽損失，遠超過從公有領域授權倉庫中複製幾行程式碼所省下的時間。
服務條款（ToS）的違約效力：CC0‑1.0 無法繞過的合約紅線
當 asgeirtj/system_prompts_leaks 專案以 CC0‑1.0 公有領域授權聲明「所有內容均可自由使用」時，許多台灣技術團隊直覺認為：只要不複製受版權保護的程式碼，將這些系統提示詞貼進自家產品就沒有法律風險。這個判斷忽略了最重要的一層合約關係——你與 AI 平台之間簽署的服務條款（Terms of Service, ToS）。無論專案採用何種開源授權，原始取得系統提示詞的手段（逆向工程、自動化擷取）早已直接違反了 OpenAI、Anthropic 等平台的 ToS，而 CC0‑1.0 授權根本無法取代或廢止你對平台承諾的合約義務。
以 OpenAI 為例，其服務條款明確將「系統提示詞」（system prompt）定義為「商業機密與專有資訊」，並在「禁止行為」章節中列出：不得透過任何自動化手段（包括爬蟲、腳本、API 濫用）擷取、複製、監控或蒐集平台的任何內容或資訊。Anthropic 的條款同樣禁止逆向工程、反編譯，以及「未經授權地存取或取得服務的非公開部分」。這意味著，即使專案貢獻者透過瀏覽器開發者工具或 API 除錯訊息成功導出了 Claude Opus 4.6 或 ChatGPT 5.5 Thinking 的完整提示詞，這個「取得行為」本身已經構成違約——平台有權立即終止你的帳號，並請求損害賠償。
⚠️ 關鍵認知：CC0‑1.0 授權只處理「著作權」層面的權利放棄，它無法觸及你與平台之間簽訂的合約。你同意 OpenAI 的 ToS 時，就已經承諾不逆向工程；這個承諾不會因為第三方把結果貼上 GitHub 並加上公有領域標章就自動消失。
事實上，system_prompts_leaks 專案的貢獻者與使用者正面臨截然不同的法律處境。貢獻者透過逆向工程或漏洞利用取得提示詞，直接違反 ToS 中的「不得未經授權存取系統」條款；而使用者僅從 GitHub 倉庫下載檔案，雖然自身沒有實施逆向工程，但若明知這些內容是透過違約手段取得，仍將其用於商業開發或員工訓練，則可能構成「引誘違約」（inducement of breach）或「共同侵權」。美國司法實務上，即使原始取得者與後續使用者之間沒有直接契約，只要後者明知或可得而知來源的不法性，就可能被法院認定為「自願參與違約行為」。
騰訊雲開發者社群於 2026 年 4 月 3 日發表的深度分析中便特別指出：「該倉庫的授權協議僅針對其自身對檔案的著作權主張，無法豁免使用者對上游平台服務條款的遵守義務。」 換句話說，當你把倉庫中的提示詞貼進 VS Code 的 Cursor 設定檔時，你不僅違反了 Cursor 的 ToS（因為 Cursor 本身也禁止提示詞擷取），還可能因為使用了「來自未經授權管道」的資訊而喪失獨立設計抗辯的空間。一旦 AI 公司啟動證據保全，你的版本控制紀錄、專案草稿都可能成為法庭上的不利證據。
具體後果可分為三個層次。第一層是帳號層級制裁：OpenAI 或 Anthropic 會直接封鎖違規帳號，且通常會同步封鎖關聯帳號（例如同一信用卡、同一 IP 區段的開發者帳號）。對於依賴單一 API Key 的中小企業，這意味著整個團隊的開發環境瞬間停擺。第二層是民事求償：AI 公司可以主張違約造成的損害，包含律師費、訴訟成本，以及因提示詞外洩導致的競爭優勢損失。雖然台灣企業可能質疑美國法院的管轄權，但多數 AI 平台的 ToS 都指定了加州法院或紐約法院為專屬管轄，且要求使用者同意「以電子方式送達訴訟文件」。換句話說，你很可能在不知不覺中已經同意被跨海提告。第三層是商譽衝擊：一旦被媒體標籤為「使用非法擷取提示詞的廠商」，客戶信任度與潛在投資者的意願都會大打折扣，這對正在爭取第一筆訂單的新創團隊尤其致命。
或許有人會問：如果我只對倉庫內容做「參考」，從中學習提示詞的設計邏輯，而不是直接複製貼上，是否就安全了？答案是否定的。台灣智慧財產局在 2026 年發布的《AI 相關營業秘密指引》中明確指出：「即使最終產品的外觀或程式碼與原始素材不同，只要開發過程中有接觸且實質上依賴未經授權取得的資訊，就可能構成營業秘密的『使用』。」 更何況，多數系統提示詞並非單純的「角色設定」，而是包含明確的拒絕邏輯、工具呼叫格式與安全閥值——這些細節一旦被模仿，原廠很容易透過比對模型行為來推斷是否存在「實質近似」。去年的 Kneschke v. LAION 案（漢堡地方法院）已為此立下先例：即使最終模型參數不同，只要訓練資料中包含了未經授權的圖片，商業使用就不能主張合理使用（fair use）抗辯。同樣的邏輯可能適用於提示詞的「訓練」與「模仿」場景。
為了協助台灣技術團隊具體評估自身風險，替代方案有限公司整理了以下常見情境及對應的法律後果：
- 情境一：直接複製倉庫中的提示詞，用於自家 AI 產品的 system prompt 設定。 → 違反多個平台的 ToS，且可能構成營業秘密侵權。面臨帳號封鎖、民事求償（含懲罰性賠償），連帶影響上下游合作廠商。
- 情境二：僅閱讀提示詞以瞭解設計哲學，但未留下具體複製痕跡。 → 若日後被發現曾下載或存取該倉庫，仍可能被法院推定有接觸事實，需自行舉證獨立創作。訴訟成本與時間壓力巨大。
- 情境三：企業內部分享或教育訓練時，將倉庫內容提供給員工作為案例教材。 → 構成散佈行為，可能被原廠視為「誘使他人違約」。即使訓練不涉及開發，仍可能因使員工接觸機密資訊而違反保密義務。
- 情境四：研究人員用於學術論文或安全性分析，且未公開具體內容。 → 仍有機會主張合理使用或學術研究例外，但若研究結果導致提示詞外洩，責任仍可能回歸研究人員。
值得注意的是，就算專案維護者宣稱「僅存檔，不對內容負責」，法院在審判時仍會將專案的「整體意圖」納入考量。從 system_prompts_leaks 的 README 中明確記載「廣泛歡迎協助推進、更新與回報新洩漏」的措辭來看，其核心目的確實是系統性收集與公開原本不公開的內容，這與一般學術歸檔或漏洞揭露的「最小必要原則」有明顯差距。華盛頓郵報在 2026 年 5 月 11 日的報導中也委婉指出：「這些提示詞的價值在於它們的機密性，一旦被公開，各家公司的商業優勢將受到侵蝕。」
面對這樣的灰色地帶，替代方案有限公司建議台灣企業應採取三項具體措施。第一，立即盤點內部專案，確認是否有任何成員曾經下載或參考該倉庫的內容，並依據風險高低制定補救計畫（例如：更換所有系統提示詞、切換模型供應商）。第二，建立 ToS 合規檢查點，在每個開發衝刺開始前，將「本階段使用的 AI 服務」對應的 ToS 條款逐條比對，確保逆向工程與自動化擷取行為不會滲入日常工作流程。第三，投資合法的研究資源，例如直接向 AI 公司申請學術合作或安全研究授權，或採用官方提供的 System Prompt 範例（如 OpenAI 在 2026 年開源的「結構化輸出指南」）。這些方法雖然需要額外時間與費用，卻能徹底杜絕違約風險。
我們的〈逆向工程實戰：如何從 API 與瀏覽器挖出隱藏提示詞？〉一文詳細記錄了多種取得提示詞的技術手法，並在文末強調了法律紅線；與這篇文章同時發布的〈從憲法AI到分層拒絕：系統提示詞的設計哲學大揭密〉則從合法視角分析各家系統提示詞的設計邏輯。我們建議讀者優先參考後者，而非直接碰觸可能觸法的原始資料。畢竟，一場 ToS 違約訴訟的訴訟費用動輒數百萬台幣起步，加上商譽損失與強制刪除產品功能的風險，絕對遠超過從 GitHub 倉庫複製幾行程式碼所省下的幾分鐘時間。在 AI 產業快速發展的今日，「合法創新」不該只是一句口號，而是每一位負責任的開發者與企業主的底線。
判例啟示：提示詞著作權在法院的真實處境——從上海黃浦區法院判決談起
2025年至2026年間，上海黃浦區人民法院審理了一起極具指標意義的AI提示詞著作權案件。一家上海文化公司利用人工智慧大模型，輸入多組包含藝術風格、主體元素與材質細節的提示詞，產出精美的AI生成圖片並發布於網路平台。當該公司發現被告朱某與盛某未經授權使用完全相同的提示詞生成畫作、收錄於藝術圖鑑時，隨即提起侵害著作權訴訟，主張其提示詞屬於《著作權法》保護的「文字作品」。
法院最終判決原告敗訴，駁回全部訴訟請求，這一結果在AI法律圈投下震撼彈。承審法官認為，從內容角度觀之，涉案提示詞僅體現為「抽象的創作想法和指令集合」，核心是對畫面元素的描述與指令，屬於「思想」範疇而非具體的「表達」；撰寫提示詞的行為亦未被認定為《著作權法》意義上的創作行為。判決書明確指出：「提示詞僅是啟動生成過程的引導，而非最終作品本身的表達。」
「原告對提示詞不享有著作權，涉案提示詞僅為抽象的創作想法和指令集合。」——上海市黃埔區人民法院，2025-2026年AI提示詞著作權案判決
此判決對 system_prompts_leaks 專案具備多重暗示意涵。首先，該專案收錄的系統提示詞若被認定為「創作指令集」，依循同一法律邏輯，這些提示詞在著作權法層面亦難以獲得保護——專案採用CC0-1.0公有領域授權試圖規避版權爭議，其前提假設（即「這些提示詞需要授權才能使用」）本身便可能站不住腳。
然而，著作權保護的「不可及性」不代表法律風險的「不存在」。上海黃浦區法院的判決雖否定提示詞的著作權地位，但未觸及兩個更深層的法律戰場：商業秘密與服務條款違約。事實上，該判決僅處理著作權侵權單一請求權基礎，AI公司仍可依據《反不正當競爭法》主張系統提示詞構成營業秘密，或依據平台上「禁止逆向工程與資料擷取」的使用條款追究違約責任——後者在司法實務上的勝訴門檻遠低於著作權爭議。
我們在〈逆向工程實戰：如何從 API 與瀏覽器挖出隱藏提示詞？〉中已特別強調，多數AI平台的服務條款明確將 system prompt 定義為「商業機密與專有資訊」，禁止一切自動化擷取行為。這意味著，即使提示詞本身不受著作權保護，逆向取得的手段本身仍可能構成違約——例如透過瀏覽器端點調試與API回傳錯誤訊息來提取提示詞，這些行為幾乎無一例外地踩踏服務條款紅線。
深入分析這起判決的結構會發現，法院其實保留了另一扇門：若提示詞本身具備「足夠的原創性與具體性」——例如包含獨特的敘事結構、角色設定與邏輯鏈——而非單純的指令拼湊，其著作權地位仍有討論空間。然而，絕大多數AI系統提示詞（尤其是安全規則與工具調用區塊）屬於高度實用性的操作指令，其文字表達與功能目標高度綁定，難以符合著作權法對「文學或藝術作品」的最低創造性要求。
CC0-1.0公有領域授權在此脈絡下反而顯得「畫蛇添足」。若提示詞本身不具備著作權，授權條款根本無從附著——如同宣佈一座無人島嶼的主權歸屬，該島嶼從未屬於任何人。但矛盾之處在於：專案貢獻者透過逆向工程與抓取獲取這些提示詞時，已然違反與AI公司之間的使用契約；CC0-1.0僅能處理著作權層面的爭議，完全無法豁免違約責任、商業秘密侵權或不正當競爭的風險。
值得注意的是，騰訊雲開發者社群在2026年4月3日的深度分析中，直接點出此法律灰色地帶：「系統提示詞已成為AI產業的機密資產」（來源2）。即使上海黃浦區法院的判決為後續類似案件提供了參考座標——提示詞在著作權法層面難以獲得保護——這並不代表AI公司會放棄法律行動。相反地，企業很可能轉向依賴服務條款違約與營業秘密保護兩種攻防武器，這兩者在中國《反不正當競爭法》體系下均具備完整的救濟路徑。
從〈從憲法AI到分層拒絕：系統提示詞的設計哲學大揭密〉的視角出發，我們可以看到Anthropic、OpenAI、Google等公司為何投入巨量資源設計系統提示詞：這些指令不僅是技術文件，更是產品競爭力的核心。若任何開發者或企業依賴 system_prompts_leaks 專案中的提示詞來打造自己的AI產品，所面臨的法律風險恐怕遠比想像中複雜——即便提示詞不受著作權保護，使用逆向取得的商業機密開發產品，在訴訟中幾乎難以主張正當性。
舉例而言，若一家台灣新創使用該專案中ChatGPT 5.5 Thinking的系統提示詞來訓練自己的聊天機器人，OpenAI可以依據該公司的服務條款提出違約訴訟，或主張該提示詞構成營業秘密遭到不當使用。在這類訴訟中，被告往往需要承擔舉證責任——證明其提示詞來源合法、未直接複製專案內容，這在實務上極為困難。更何況，訴訟成本動輒數百萬台幣起跳，對於中小企業與技術團隊而言，光是應訴便可能拖垮研發資源。
最後，此判決也側面回饋到 system_prompts_leaks 專案的正當性論述。該專案在其README中宣稱「只存檔不對內容負責」，但上海黃浦區法院的邏輯暗示了一條出路：若專案的收錄行為本身可以主張為「學術研究」或「公共記錄」，而非商業使用，或許能避開營業秘密法規的射程範圍。然而，CC0-1.0授權允許商用與改作，恰恰與「學術研究」的封閉使用範圍存在根本衝突。一個允許全球使用者自由下載、修改、甚至商用這些提示詞的專案，要主張自己僅為「被動記錄者」，恐怕很難說服法院。
對於台灣中小企業與技術團隊而言，這起判決傳達的訊號十分清晰：不要指望著作權保護為你的提示詞提供盾牌，也不要依賴CC0-1.0授權為你擋箭。真正的安全策略，是從源頭確認提示詞的取得方式符合服務條款、不涉及逆向工程、不落入商業機密的範疇，並在合約中明確約定使用的權利與限制。替代方案有限公司建議，企業應建立完善的AI合規審查流程，將系統提示詞視為敏感資產來管理，而非當成可隨意複製的開源程式碼來對待。
若您對這起判決的完整法律邏輯感興趣，我們推薦閱讀〈從憲法AI到分層拒絕：系統提示詞的設計哲學大揭密〉，該文從制度設計角度分析各家公司提示詞的保護動機；另一方面，〈你的 Cookie 安全嗎？使用 Agent-Reach 前必須知道的隱私、合規與風險〉則深入探討AI產品開發中的營運風險，可為您的合規架構提供實務參考。畢竟，在提示詞著作權的司法迷宮裡，唯一不會被推翻的論述，永遠是「合法取得、合規使用」這八個字。
常見問題 Q&A：公有領域授權能否擋住 DMCA 刪除通知？研究者該如何自保？
系統提示詞洩漏事件爆發後，社群最常問的第一個問題是：CC0-1.0 公有領域授權到底能不能擋下 DMCA 刪除通知？答案恐怕讓許多人失望——「不能」。
DMCA（數位千禧年著作權法）的刪除通知機制，核心判斷標準是「是否侵害著作權」。但問題在於，AI 公司向 GitHub 提出的下架要求，往往不是以著作權為由，而是主張系統提示詞屬於商業機密或違反服務條款。CC0-1.0 授權僅能放棄著作權人的權利，卻無法抹去提示詞作為「營業秘密」的法律地位。
根據 2026 年 1 月的法律研究，系統提示詞的法律地位正在各國法院中被激烈辯論。中國上海市黃浦區法院在一審判決中認定，提示詞不構成著作權法意義上的作品，理由是它僅反映抽象的創作想法與指令集合。但這個判決並未觸及商業機密層面的保護——換句話說，即使提示詞不受著作權保護，它仍然可以是受營業秘密法保護的資產。
重要提醒：CC0-1.0 授權無法解決商業機密爭議。即使專案聲明「只存檔、不對內容負責」，法律風險依然存在——特別是在 AI 公司將提示詞視為核心競爭力的情況下。
那麼，如果 AI 公司真的送出 DMCA 通知，GitHub 會怎麼處理？根據 GitHub 的 DMCA 政策，平台收到完整且合規的通知後，會立即下架涉嫌侵權的內容，而非先審查授權協議的有效性。也就是說，system_prompts_leaks 倉庫可能在幾天內就從公開狀態轉為 private 或被封存，即使它採用 CC0-1.0 授權也無法改變這個程序。
2026 年 4 月的判例更進一步顯示，針對 AI 提示詞的訴訟，原告傾向於同時主張著作權、商業機密與違反合約三重請求。GitHub 在面對這類多重法律基礎的刪除要求時，幾乎不可能站在開源社群這邊——畢竟平台本身也需承擔「知情後未下架」的轉承責任風險。
面對這些法律灰色地帶，研究者該如何自保？替代方案有限公司整理出以下四項務實建議：
- 使用匿名帳號進行研究。無論是從 API 或瀏覽器端點提取提示詞（如我們在〈逆向工程實戰〉中討論的方法），都建議使用加密通訊、虛擬機器與一次性帳號，避免個人身分與研究行為直接關聯。
- 嚴格避免商業化利用。即使 CC0-1.0 授權允許商用，但若研究涉及商業機密性質的內容，任何營利行為都將大幅提高訴訟風險。建議將研究限制於學術分析、教育訓練或安全性揭露範圍內。
- 尊重各國法規差異。台灣的營業秘密法、美國的經濟間諜法（EEA）、歐盟的商業機密指令（2016/943）對於「不正當取得商業機密」的定義與罰則不同。跨國研究團隊尤其需注意管轄權重疊的問題。
- 保留法律諮詢窗口。在開始逆向分析或發布研究報告前，最好先諮詢熟悉 AI 法規的律師。替代方案有限公司建議企業導入 AI 後，應同步建立合規審查流程，將系統提示詞視為敏感資產來管理。
關於法律諮詢的實際操作，我們在〈你的 Cookie 安全嗎？使用 Agent-Reach 前必須知道的隱私、合規與風險〉中討論過類似的合規架構，包括資料分類、授權檢查清單與回應法律通知的標準作業程序。這些流程同樣適用於系統提示詞的研究場景。
最後一個常被忽略的重點：使用 CC0-1.0 授權的專案，不代表貢獻者可以免責。每個上傳系統提示詞到倉庫的貢獻者，都可能單獨承擔法律責任——特別是在 AI 公司能夠證明其提示詞的「秘點」（trade secret）具備具體性、非公知性與保密措施三要件的情況下。2026 年 6 月的柳沈律師事務所分析指出，商業秘密的持有人需要證明特定模型參數或資料集組合是具體且非公知的優化細節，而非公有領域的內容。換句話說，如果提示詞包含獨特的工具調用流程、分層拒絕邏輯或安全過濾規則，這些細節很可能構成可主張的營業秘密。
因此，替代方案有限公司呼籲所有研究者：不要因為專案採用「五權放棄」的 CC0-1.0 授權，就降低對法律風險的警覺。公有領域授權是著作權領域的工具，無法在商業機密、合約違反或不正競爭的戰場上提供足夠的保護。如果你對這些法律邊界想了解更多，我們推薦閱讀〈從憲法AI到分層拒絕：系統提示詞的設計哲學大揭密〉，該文從制度設計角度分析各公司提示詞的保護動機，可幫助你判斷哪些內容屬於「可安全研究」的範疇。
台灣觀點：企業導入 AI 時應注意的系統提示詞風險與合規策略
系統提示詞洩漏事件對台灣企業的衝擊，遠比想像中來得深遠。當員工基於研究或好奇，在公司設備上存取 asgeirtj/system_prompts_leaks 這類專案時，可能瞬間觸犯《營業秘密法》、《著作權法》甚至《刑法》中的妨害電腦使用罪——而且這三條紅線可能在一次點擊中同時被跨越。
從營業秘密法的角度來看，問題的核心在於系統提示詞的「具體性」與「秘密性」。即時搜尋資料中的研究報告指出，各大 AI 公司投入大量資源設計這些隱藏指令，定義助手的個性、安全規則、工具調用方式與知識邊界——這些涉及獨特商業策略的提示詞，很可能構成受保護的營業秘密。台灣《營業秘密法》第 2 條明確定義，營業秘密須具備秘密性、經濟價值性及合理保密措施，而 OpenAI 在其服務條款中已明確將 system prompt 定義為「商業機密與專有資訊」，這項聲明即滿足了「合理保密措施」的門檻。員工若下載或複製這類提示詞，企業可能因此承擔民事賠償責任，甚至面臨刑事追訴。
著作權法的風險同樣不容忽視。雖然中國上海市黃浦區人民法院在 2025 年的一起判決中，認為 AI 提示詞不構成著作權法保護的作品，但台灣的著作權實務與司法見解未必跟進。即時搜尋資料中的研究報告強調，提示詞的長度、原創性與表達方式若達到一定門檻，仍可能被認定為語文著作。更值得注意的是，該專案採用 CC0-1.0 公有領域授權，表面上允許任何人無限制使用，但這種授權只能處理著作權層次的爭議，無法對抗營業秘密或不正競爭的主張——這是許多台灣技術團隊最容易忽略的陷阱。
刑事責任的層面更是企業必須正視的烈火。員工使用逆向工程手法從 API 回應或瀏覽器端點提取系統提示詞，可能構成《刑法》第 359 條的「妨害電腦使用罪」，也就是無故取得、刪除或變更他人電磁紀錄。即時搜尋資料中的〈逆向工程實戰〉文章清楚指出，這類行為不僅違反 AI 平台的服務條款，更可能觸法——一旦進入刑事程序，企業將面臨搜索、扣押設備與內部調查的沉重壓力。
那麼，台灣企業該如何建立有效的防護網？替代方案有限公司提出三項具體的內部政策建議，可供中小企業與技術團隊立即導入：
- 禁止在公司設備存取該倉庫：在防火牆層級封鎖
github.com/asgeirtj/system_prompts_leaks及相關站點，同時透過端點管理系統（如 Microsoft Intune 或 Jamf）禁用員工從公司筆電存取該專案。唯有從根源阻斷接觸，才能避免後續的法律連鎖反應。 - 簽署保密協議（NDA）並明確列出提示詞為保密資訊：要求所有參與 AI 專案的員工簽署補充保密條款，明確定義「系統提示詞、開發者訊息及模型行為指令」為企業機密，且不得從外部來源下載、複製或散佈類似內容。這項文件將在未來可能的訴訟中作為企業已盡管理責任的有力證據。
- 部署提示詞監控工具：在 AI 應用層面導入即時監控機制，比對員工輸入與輸出內容是否包含已知的洩漏提示詞片段。即時搜尋資料中的研究報告建議，企業可採用字面比對、結構分析與變異偵測等技術，將系統提示詞視為「組織機密」進行生命週期管理。
即時搜尋資料中的〈從憲法AI到分層拒絕〉文章深入分析了各公司提示詞的設計哲學與保護動機，有助於企業判斷哪些內容屬於「可安全研究」的範疇。此外，〈逆向工程實戰〉文章也提供了具體的技術分析框架，協助技術團隊在不觸法的情況下理解提示詞的結構。
替代方案有限公司最後要提醒的是，企業導入 AI 不應只關注技術效益，更要建立完整的合規架構。系統提示詞的法律地位目前仍在灰色地帶，但這不代表企業可以輕忽風險。台灣的中小企業與技術團隊應立即檢視現有的 AI 使用政策，確保員工不會因為好奇心而將公司暴露在法律責任之下。唯有將提示詞保護納入資訊安全體系，才能讓 AI 轉型之路走得更穩、更遠。
結論：公有領域授權不是護身符——未來法律攻防與技術對策的平衡
回顧整起事件，CC0‑1.0 公有領域授權看似為 system_prompts_leaks 專案提供了著作權保護傘，但這把傘的遮蔽範圍遠比許多人想像的狹窄。從上海黃浦區法院對提示詞著作權案的判決——認定提示詞僅為「抽象的創作想法與指令集合」，不構成受著作權法保護的作品——便可看出，即使原作者主張權利都經常失敗，更何況是透過 CC0‑1.0 來「放棄」一個法律上不存在的權利。換句話說，CC0‑1.0 在著作權層面的作用，本質上是「放棄了根本不存在的權利」，並不能自動讓洩漏行為合法化。當訴訟戰場轉移到營業秘密、契約違反或不當得利時，這份授權聲明幾乎毫無防禦力。
真正的法律地雷藏在營業秘密領域。即時搜尋資料指出，部分系統提示詞「可能涉及商業機密」，廠商完全有權利依據營業秘密法提出刪除要求甚至訴訟。以 OpenAI 為例，其服務條款早已將 system prompt 定義為「商業機密與專有資訊」，任何形式的逆向工程都構成違約。即使專案採用 CC0‑1.0，也無法免除使用者因違反 ToS 而產生的契約責任。更棘手的是，不當得利請求——若企業因使用洩漏的提示詞而獲得競爭優勢（例如訓練出更有效率的客服機器人），原廠可主張該利益欠缺法律上原因。台灣中小企業若直接複製這些提示詞到自家系統中，將同時暴露在違約、侵權與不當得利三重風險之下。
面對這波洩漏潮，AI 公司勢必加速技術反制。預測短期內將出現三種主要防護手段：第一，動態生成——系統提示詞不再以固定文字儲存，而是由模型在執行時根據上下文組合產生，使逆向提取難度大幅提升；第二，輸出過濾與浮水印——在模型回覆中嵌入隱藏特徵，即使提示詞被擷取，也能追蹤來源並舉證；第三，強化 API 端點監控——透過異常流量偵測與瀏覽器指紋比對，攔截自動化爬取行為。這些技術對策雖無法完全杜絕洩漏，但足以讓逆向工程的成本與風險顯著增加。對於開發者與研究者而言，理解這些防護機制的原理（例如我們在逆向工程實戰：如何從 API 與瀏覽器挖出隱藏提示詞？中討論的技術細節），將成為未來合法研究的必要前提。
然而，技術圍堵並非長久之計。替代方案有限公司認為，業界應積極推動「系統提示詞透明化」標準——由第三方公正機構建立提示詞審計與揭露框架，讓 AI 公司在不洩漏核心商業機密的前提下，公開提示詞的設計目的與安全邊界。這不僅能降低法律風險，也能讓 prompt engineering 的研究回歸技術本質，而非依賴灰色地帶的逆向工程。例如，Anthropic 的「憲法 AI」框架本質上就是一種透明化的嘗試，若能進一步標準化，將有助於建立產業信任。同時，各國監管機構（如歐盟 AI Act）已開始要求高風險 AI 系統提供透明文件，系統提示詞的揭露很可能成為法規強制事項。
最後，台灣中小企業與技術團隊必須立即行動。我們建議至少做到三件事：第一，全面檢視現有 AI 使用政策，明文禁止員工透過未授權管道取得或複製第三方系統提示詞；第二，建立「內部提示詞管理流程」，將自家設計的提示詞視為營業秘密加以保護，例如限制存取權限、記錄版本變更；第三，採購或導入 AI 服務時，要求供應商出具系統提示詞的合規聲明，確認其設計不涉及逆向工程或違反他人權利。唯有將提示詞保護納入資訊安全體系，才能讓 AI 轉型之路走得更穩、更遠。正如前一篇分析所述（從憲法AI到分層拒絕：系統提示詞的設計哲學大揭密），設計哲學的透明化與法律風險的管理必須同步推進，AI 產業才能真正從「黑盒子競賽」走向可持續創新的健康生態。
