大橘子的家: 當AI碰到軟體基金會

由PHP2Shell 看AI 時代與軟體基金會的運作

2026 年 10 月，PHP2Shell 再次把底層軟體的安全問題帶到檯面上。PHP 官方公布兩項可能造成未經驗證遠端程式碼執行的重大漏洞，要求使用者儘速更新。[1]

事件值得討論的，不只是 PHP 哪裡寫錯，更是現代企業如何選擇、依賴，以及支持自己的數位基礎設施。當關鍵軟體被大量使用，維護能力卻無法隨之成長，AI 又加快漏洞發現與攻擊研究，過去可以慢慢處理的落差，可能變成更急迫的安全危機。

企業主動選擇開源，也選擇了一種成本安排

過去二三十年，企業在許多場景中主動採用 Linux、Apache HTTP Server、OpenSSL 等開源軟體，替代或減少對商業 Unix、商業 Web 伺服器及商業 TLS 套件的依賴。這不是每個企業都走過的單一路徑，也不能把所有專案的歷史寫成商業產品移交基金會。許多專案原本就來自社群，基金會是後來為了支持其延續而成立。[2]

不過，企業的經濟選擇很清楚：免授權費、容易取得、可自行修改，以及龐大的工具與人才生態，使開源成為有吸引力的選項。這些選擇可以合理而有效，問題在於企業怎麼計算節省下來的成本。

商業授權與維護合約，通常把部分維護工作轉成企業必須支付的費用；合約的保障程度則各不相同。免費取得開源程式後，這筆支出可能從採購預算消失，但漏洞分析、程式審查、相容性測試、版本維護與緊急應變，仍然需要有人做。

如果企業取得了節省授權費的利益，卻把共用元件的維護長期留給其他公司、基金會與志願者，就可能把維護負擔留給其他參與者，形成搭便車與維護投入不足的問題。

但不能把所有開源使用都視為搭便車。有些企業聘請上游開發者、購買支援、資助稽核，或讓工程師在工作時間貢獻程式。真正需要追問的是：企業投入的維護能力，是否足以支持它所承擔的依賴與風險？

基金會補上了資源，卻沒有承諾無限維護

PHP Foundation 在 2021 年成立，目的就是為 PHP 開發提供經費。它不是接手 PHP 所有責任的商業供應商，PHP 語言的決策也仍由社群進行。[3]

依基金會公布的 2025 年報告，年底有 11 位全職或兼職合約開發者，全年捐款總額約 73 萬美元；基金會資助的開發者完成當年 PHP 核心約 42% 的 commit（程式碼提交）。同一份報告也顯示，2025 年扣除相關費用後實收約 64.5 萬美元，支出約 78.4 萬美元，形成約 13.9 萬美元的收支缺口。這是基金會為維持技術人力而刻意承擔的投入，報告同時表示仍有健全的準備金；全年贊助的組織與個人共 536 個，明顯少於前一年。[4]

這些數字不是整個 PHP 社群的人力與經費，也不能直接證明這次漏洞本身由資源不足造成。但它們提醒我們：基金會可以資助持續維護，卻不會因為世界各地都在使用 PHP，就自動獲得對應的預算。

企業若把「有基金會」理解成「有人會負責所有問題」，就把組織的存在誤認為足夠的服務能力。非營利組織同樣需要穩定收入、專業人員與可持續的工作負荷。

2024 年已出現線索，修補為何拖到 2026 年？

PHP Foundation 在修補發布當天的說明中坦承，其中一項問題的根源早在 2024 年就被注意到。當時，一位核心開發者在處理外部安全稽核（由德國 Sovereign Tech Agency 出資[4]）所發現的另一個問題時，察覺了這個記憶體處理上的缺陷；有人推測它可能被利用，但沒有找到具體攻擊路徑，加上還有影響更明確的問題要先處理。[5]

之後修補陷入停滯。安全團隊提出數種修法，各有代價：一種破壞向下相容，一種增加阻斷服務風險，一種要求許多第三方擴充套件跟著修改。小團隊以共識決運作，又擔心選錯方案，工作在數個月間反覆停頓、重啟。基金會直言，這次延誤是一次結構性失敗，原因同時來自安全團隊的決策流程與資源不足。[5]

這段自述的意義在於：問題不只是「沒有人發現」，而是發現之後，缺乏足夠的人力與決策機制，在困難的取捨中及時選出修法。基金會也已著手調整：2026 年 5 月成立生態系安全團隊，Alexandre Daubois 於 7 月加入，Daniel Scherzer 於 9 月加入，並正調整安全決策流程，引入多數決與折衷機制。[5]

有人看見問題，不等於有人有能力、也有權限及時把它修好。

此外，2024 年「找不到具體攻擊路徑」這個判斷，在 AI 時代特別值得重新檢視，後文會再回到這一點。

Log4j 已經提醒過我們什麼？

2021 年的 Log4Shell 已展示過共同依賴的威力：一個廣泛使用的 Java 日誌元件出現重大漏洞，就能影響大量應用程式與服務。[6]

美國網路安全審查委員會（CSRB）事後檢討指出，造成漏洞的 JNDI 元件早在 2013 年就加入 Log4j；若當時團隊中有具備安全專長的人審查程式碼，問題可能及早被發現，但主導專案的志願開發者並沒有這樣的資源。委員會也判定 Log4j 已成為會長期殘存的「endemic」漏洞，有漏洞的版本可能殘留在系統中十年以上。[6]

它留下的教訓，不應只是新增一條掃描規則，而是企業必須知道自己使用哪些元件、哪些產品間接依賴它們、由誰提供修補，以及多久能完成部署。

PHP2Shell 再次讓同一種治理問題浮現。不過，兩起事件不能簡化成同一個技術錯誤，也不能因為新的漏洞出現，就認定所有人完全沒有學到經驗。真正需要檢驗的是：共同依賴是否得到足夠支持，企業是否能迅速確認影響並完成修補。

如果這些能力沒有改善，下一次危機只是換了軟體名稱。

全球有人看，不等於重要路徑都被充分檢驗

開源提供了檢查、修改與獨立驗證的機會。但程式公開，不會自動產生足夠的安全審查人力。

貢獻者很多，也不代表每個關鍵模組都有多人深入理解。功能測試通過，也不代表記憶體耗盡、異常中斷、狀態清理等特殊路徑都已經安全。

PHP2Shell 的兩項公告分別涉及記憶體耗盡造成的損毀，以及殘留的全域狀態。[7] 最早受影響的程式路徑可追溯到 2012 年的 PHP 5.4.0[8]，說明至少部分受影響版本可追溯十多年前；這不等於每項漏洞都從同一版本開始存在，也不證明相關程式路徑曾被持續深入審查。這類問題需要對執行環境有深入理解，不能只用「這段程式曾經被審查過」作為充分保證。

因此，企業評估依賴時，需要看實際的維護、驗證與應變能力。基金會名稱、下載量與貢獻者人數，都無法單獨回答這些問題。

AI 加速了發現，其他工作卻未必跟著加速

AI 已經展示尋找真實漏洞與提出修補的能力。但討論「速度提升」時，必須分清楚：發現全新漏洞、依既有修補重建漏洞、產生攻擊程式，以及交付安全更新，是不同的工作，不能把數字混在一起。

以下案例中，有數項來自 AI 或資安廠商（包括 OpenAI、Anthropic、Wiz、AISLE）自行發表的研究或說明。數字已對照原文，但讀者宜留意其來源屬性；本文也盡量並列維護者與第三方的資料。

PHP2Shell 本身：AI 輔助稽核找出的老問題

PHP2Shell 本身就是 AI 輔助研究的成果。資安公司 Calif 在 OpenAI 支持的 Patch the Planet 計畫下稽核 PHP 原始碼，並使用 GPT-5.6 Sol 輔助。[9] 依 PHP Foundation 的說明，Calif 於 7 月 30 日開始稽核，8 月 11 日回報一項無條件的遠端程式碼執行，根源正是 2024 年注意到的記憶體耗盡問題；OpenAI 也獨立回報了相同根源。[5] Wiz 則以自家的 Wiz Atlas 搭配 Gemini 4 Argon 與 GPT-5.6 Sol，於 8 月 19 日發現第一個漏洞，8 月 24 日通報 PHP 安全團隊。[5][10]

Wiz 研究人員指出，這些缺陷存在已久，但要證明它們可被利用，需要一條極為複雜的攻擊鏈，幾乎到了人類研究人員實務上能做到的極限；前沿 AI 模型大幅降低了這個門檻。[11]

這正好對應 2024 年「找不到具體攻擊路徑」的判斷：當時因缺乏具體攻擊路徑而降低優先度的判斷，需要隨 AI 能力變化重新評估。缺乏可用攻擊證明，並不等於延後處理必然合理。

其他開源專案：有效發現大增，維護端吃緊

這不是單一專案的現象。OpenSSL 在 2026 年 1 月的安全版本修正了 12 個新漏洞，官方漏洞清單列有 AISLE 研究人員的發現貢獻，部分項目也列有其他共同發現者；依 AISLE 的說明，這些漏洞都是其 AI 系統發現的，其中一個甚至可追溯到 OpenSSL 誕生前的 SSLeay 時代，另有 5 個由 AI 系統提出的修補被正式版本採用。[12][13]

維護端的壓力也同步升高。PHP 安全團隊自 7 月起已發布 15 個 CVE，另外處理了超過 100 份最後判定無效、重複或無法重現的報告；基金會也強調，工具無法替數十年前的設計決策選出正確修法，也無法衡量相容性代價，這仍需要經驗豐富的工程師，而這樣的人太少。[5] curl 因持續的漏洞回報壓力，宣布自 2026 年 7 月 1 日暫停一般漏洞收件與處理，於 8 月 3 日恢復；付費支援合約仍維持服務，GitHub issue 與 PR 也繼續開放。[14]

真實漏洞發現：約 20 分鐘找到第一個，兩週找到 22 個

Anthropic 在 2026 年 3 月公布與 Mozilla 的合作成果：Claude Opus 4.6 約探索 20 分鐘，就報告 Firefox JavaScript 引擎的一項 use-after-free 漏洞，之後由人工獨立驗證。兩週內共發現 22 個漏洞，其中 14 個被 Mozilla 評為高嚴重性；22 個的總數超過 2025 年任何單月來自所有來源的漏洞通報量。[15]

這是實際作業時間與歷史通報量的對照，沒有控制人力、算力與搜尋範圍，因此不能換算成「比人工快幾倍」。更值得注意的是，在研究人員驗證並提交第一項漏洞的期間，AI 又找出 50 個不同的崩潰輸入。崩潰不等於已確認的安全漏洞，卻足以顯示候選問題產出可能快於人工處理。[15]

同一篇文章也指出，當時模型在數百次嘗試中，只把兩個漏洞做成簡陋的攻擊程式，而且只能在移除沙箱等防護的測試環境中運作；找漏洞的成本比寫攻擊程式低一個數量級。[15] 三個月後的另一項研究顯示，更強模型能在提供修補差異與特定測試條件下完成更多攻擊案例；但兩次實驗設計不同，不能直接據此衡量發現與利用之間的差距縮小多少。

同一組修補的模型比較：40 分鐘內累計重建 13 個漏洞觸發案例

Anthropic 於 2026 年 6 月公布的研究，以 Firefox 148 與 149 中 18 項 JavaScript 引擎安全修補作為共同題目。Claude Mythos Preview 約 12 分鐘產生第一個可重現崩潰的概念驗證（PoC），40 分鐘內累計達 13 個；Opus 4.8 約需兩倍時間，才累計到 11 個。按各題最快成功時間繪製的累積結果，約三小時的時間門檻涵蓋 14 個 PoC。[16]

這裡測的是已知漏洞的重建，並非從零發現新漏洞。研究對每題各跑三次，取最快的成功時間；每次嘗試的上限是 300 萬 token，而不是時間門檻。「40 分鐘內 13 個」是把各題最快時間排序後的累積結果，不是單一代理依序完成 13 題，也不是單次執行的平均表現。它是在相同題集下比較模型能力，不能推廣成所有漏洞研究都加速兩倍。

在同一研究中，Mythos Preview 第一個能執行任意程式碼的攻擊程式，端到端最快不到一小時；按各題最快成功時間排序，約十二小時的時間門檻涵蓋 8 個攻擊案例。這不是單一代理依序完成的總工時，也不是全部嘗試的總運算時間；對應的原始碼修補公開後，距 Firefox 正式版本發布卻還有 18 天。這是事後重跑的實驗（研究只選修補已公開至少 90 天的漏洞），並非當時發生的實際攻擊；測試使用獨立的 jsshell，沒有證明可突破完整瀏覽器的沙箱防護。[16]

也要注意，研究使用的 Mythos Preview 當時採限制存取方式，並未對一般大眾開放[17]，這項研究衡量的是能力前緣，而非攻擊者目前普遍可取得的工具；不過同一研究也指出，關閉防護機制的公開模型同樣做得出攻擊程式，只是數量較少。[16]

這個對照指出更直接的風險：攻擊研究可能縮短到小時尺度，正式更新交付與下游部署卻仍需要數天。

同一研究另以 21 個 Windows 核心漏洞測試：微軟評為「較不可能被利用」或「不太可能被利用」的 14 個漏洞中，Mythos Preview 為 13 個做出 PoC，並對其中一個「不太可能被利用」的漏洞完成提權。研究者認為，以人類研究者能力校準的可利用性評等，可能需要隨之調整。[16] 這與 PHP 在 2024 年因缺乏具體攻擊路徑而降低優先度的情況，並非相同的決策機制；但兩者都提醒我們，依既有人類研究能力形成的可利用性判斷，需要重新檢驗。

自動修補：平均 45 分鐘提交，但不等於部署完成

DARPA 的 2025 年 AI Cyber Challenge 報告指出，參賽系統平均約 45 分鐘提交修補；測試用人工植入漏洞的發現比例，由 2024 年準決賽的 37% 提升至 2025 年決賽的 86%，修補比例也由 25% 提升至 68%。這是不同年度測試的成果，不是對同一組漏洞進行的速度實驗。[18]

決賽也找出 18 個真實漏洞，並提供 11 個修補程式。這些成果說明 AI 能協助防守，但「提交修補」仍不同於上游接受、發行版完成打包，以及企業正式環境部署生效。[18]

軟體維護者的觀察：吞吐量提升，仍需要大量人力接住

Mozilla 在 2026 年 5 月的回顧指出，Firefox 150 修復了 Mythos Preview 發現的 271 個安全問題；整個 4 月各版本合計修復 423 個安全問題，來源也包含其他模型、外部研究者與傳統方法。這些是安全問題數，不能直接當成 423 個獨立 CVE 或可用攻擊鏈。[19]

Mozilla 同時表示，這波工作有超過 100 人貢獻程式碼，並需要去重、分類、測試與發布流程。這不是純粹的人機速度比較，卻提供了維護者端的重要證據：AI 可以快速增加有效發現，而把發現轉成安全產品，仍需要完整工程能力。[19]

以上數據支持的是：AI 已在特定漏洞發現、重建與修補任務中達到分鐘至小時尺度，並能增加工作吞吐量。目前沒有足夠證據給出適用所有軟體的「比人工快幾倍」；Firefox 等案例也不能直接當成 PHP2Shell 本身的發現耗時，PHP2Shell 的實際時程已見前文。

真正值得擔心的是速度差異。AI 可以擴大分析與攻擊研究的規模，維護者卻仍須確認報告、追查根因、檢驗修補，並維持不同版本的相容性。下游供應商還要重新打包、測試與發布；企業則要找出受影響系統、安排變更並確認更新生效。

低品質的 AI 報告也可能消耗審查時間。Anthropic 的漏洞揭露政策表示，送出的報告原則上都經人工審查確認，大量提交前也會先與維護者商定可承受的節奏，正反映了這種容量限制。[20]

如果發現速度提升，而驗證、修補與部署沒有同步提升，更多漏洞知識就可能先於有效防護擴散。這是風險機制的分析，不能僅憑目前案例就認定全球整體安全已經淨惡化。

從漏洞發現到正式公布，哪些環節會失衡？

漏洞處理不是「找到、改好、宣布」三個動作。依協調漏洞揭露（Coordinated Vulnerability Disclosure，CVD）的基本精神，研究者、上游維護者、下游供應商與使用者需要交換資訊，安排修補與揭露。各階段可能並行、反覆驗證，也可能因洩漏或實際攻擊而被迫改期。[21]

發現與私下通報：先把候選問題變成可處理的報告

AI 產生的漏洞假說、程式崩潰與已確認安全漏洞，是不同的證據層級。研究者應確認問題能否重現，提供必要的版本、設定、觸發條件與安全影響，透過專案指定的私下安全管道通報。敏感報告若直接放進公開 issue，可能在防護尚未就緒前暴露攻擊線索。

這一階段的瓶頸是報告品質與接收能力。大量自動產生的報告，即使看似專業，也可能讓維護者花時間排除誤報。報告接收確認應與技術結論分開：先承認收到、指定處理人，再持續告知分析進度，不必等到所有細節確認後才回應。

確認與影響分析：重現一個案例，還不足以界定整個問題

維護者需要確認根因、受影響版本、必要設定、權限與執行環境，並檢查相鄰程式是否存在同類錯誤。一個測試環境中成功的 PoC，不一定能在所有部署方式中使用；反過來，第一個案例的限制，也不代表其他攻擊路徑不存在。

過早縮小影響範圍，可能讓使用者誤以為不必更新；長時間無法釐清範圍，也可能拖延必要的防護通知。較合理的做法是明確區分已確認事實、待確認範圍與目前建議，隨證據更新公告。

修補與驗證：修掉第一個觸發案例，不一定修掉根因

候選修補必須經過安全審查、回歸測試與必要的跨版本驗證。除了原始 PoC，還需要檢查類似輸入、異常處理與可繞過路徑。AI 能產生修補建議，但維護者仍須確認它是否只是阻擋單一案例，或是否破壞原有功能。

PHP 在 10 月 21 日發布安全版本後，10 月 23 日又發布資訊性公告：若應用程式在設定中把 session 序列化處理器設為 php_binary 或 php_serialize，又在執行時以 ini_set() 切換回 php，且上傳進度功能仍開啟，就可能形成不常見的 RCE 路徑。這是新編號 CVE-2026-115560，PHP 判斷實務上不太可能發生，將隨下一個常規版本處理；在此之前建議關閉 session 上傳進度功能，而這項設定其實已列在 10 月 21 日的緩解措施中。[1] 原安全公告甚至建議，即使已經更新，若用不到這個鮮少使用、也鮮少測試的功能，也可考慮持續關閉。[7] 這說明安全處理可能需要後續補充；單憑後續公告，則不足以認定最初修補草率。

下游協調：上游改好，不等於產品更新已經準備好

PHP 等共用元件會被作業系統發行版、主機服務、容器映像與商業產品整合。上游有修補後，下游仍可能需要回補舊版、建置套件、測試、簽章與安排發布。在合理範圍內，提前向必要的下游維護者提供保密資訊，可以縮短正式揭露後的等待時間。[21]

但協調名單、資訊分發與保密期限本身也需要管理。參與者越多，同步發布越困難，資訊提前流出的可能性也需要納入規畫。基金會可以協助協調，卻不能代替每個供應商完成自己的工程工作。

正式公布：安全公告、修補程式與攻擊細節，並非同一件事

公眾通常把「公布」看成單一時間點，但它可能包含安全預告、原始碼提交、修補套件、安全公告、CVE 紀錄、技術分析及可執行 PoC。它們不必同時公開；公開修補本身，也可能讓研究者透過版本差異推回漏洞位置。[16]

因此，延後完整攻擊細節，無法保證攻擊者不知道漏洞；但在沒有防護資訊與可用更新時，直接公開詳細攻擊方法，也可能讓使用者承受更大風險。公告應優先提供可行動的資訊：受影響條件、可用更新、緩解措施、重新啟動需求與已知限制。

揭露期限需要考慮實際風險。過早揭露可能壓縮修補時間，無限期保密則可能讓使用者在不知情下持續暴露。以 Anthropic 政策為例，一般目標是在 90 天後或修補發布後（以先到者為準）公開；修補發布後，完整技術細節通常再等 45 天，讓下游有時間部署。遭實際利用的重大漏洞，目標在 7 天內完成修補或緩解；細節已從其他管道公開時可縮短緩衝，部署特別複雜或影響範圍特別廣時則可能延長。[20] 這是該組織的政策，不是所有專案通用的法定期限，也不是企業可以等待 90 天才處理的理由。

PHP2Shell 的實際提醒：協調時程可能被洩漏打斷

Ubuntu 的官方說明指出，PHP2Shell 原定於 2026 年 10 月 22 日 14:00 UTC 公開，因資訊洩漏，提前至 10 月 21 日同一時間。換成台灣時間，就是由 10 月 22 日晚間 10 點，提前至 10 月 21 日晚間 10 點。[22]

依 PHP Foundation 的說明，10 月 20 日約 15:00 UTC，兩個 CVE 編號開始在論壇與社群媒體流傳，附帶錯誤的發布時間與錯誤的 10.0 分（實際為 9.2），但沒有洩漏技術細節；PHP 隨即提前發布預告。之後又出現兩起狀況：回報漏洞的資安公司 Calif 誤發一段 PoC 示範影片，雖隨即刪除，複本仍已流傳；Chainguard 與其他發行商一樣事先取得修補，卻在正式發布前六個多小時就公開了已建置好的修補映像，讓任何人都能在其他使用者仍在等待時，先研究修補後的二進位檔。[5]

這是協調流程面對外部事件而改期的例子。它不等於證明整個流程失敗，也不能據此推定最初洩漏者的身分；但它說明揭露計畫需要備案：哪些更新可提前交付、哪些使用者需要先收到緩解建議、提前取得修補的參與者應遵守哪些規則，以及如何快速同步公告。

公告與更新發布後：仍須確認防護真正生效

正式發布不是流程的終點。企業還要確認資產是否受影響、更新是否安裝、執行中的程序是否載入新版，以及是否需要重建映像、重新部署或重新啟動。Ubuntu 在此次說明中特別提醒，即使自動更新已安裝套件，受影響應用仍可能需要重新啟動，或重新開機。[22]

如果系統可能已遭入侵，修補只能關閉漏洞入口，不能自動清除既有持續存取或復原資料，仍需依證據啟動事件調查。對重大漏洞而言，「套件更新成功」與「風險已受控」應有不同的驗證條件。

因此，企業應分別追蹤通報至回應、回應至確認、確認至修補驗證、下游套件就緒，以及更新交付至部署生效的時間。這些工作可能重疊，不宜只用一個平均修補天數掩蓋瓶頸。研究者、維護者、供應商與企業，也應各自有明確負責人。

AI 時代的漏洞治理，必須管理整條資訊與更新傳遞流程。只縮短發現時間，而沒有縮短其他階段，甚至可能把更多壓力推向資源最少的一端。

主要問題是發現、修補與部署的能力失衡

一個漏洞被找出，不代表它已經被修補；修補完成，不代表所有發行版與產品都已提供更新；更新可以下載，也不代表企業正在執行的系統已經受到保護。

攻擊者只需要找到仍然脆弱的目標。防守方則必須處理大量系統、不同產品，以及跨組織的責任分工。

AI 也能改善修補與測試，因此這種失衡不是注定的。但如果產業把大量資源投入「找得更快」，卻沒有投入相應資源讓上游「修得可靠」、下游「部署得及時」，新增能力就不會完整轉化為安全效益。

這也是為什麼只要求基金會再努力一點，無法解決問題。企業採用共用軟體時，必須同時承擔支持上游與管理自身部署的責任。

節省的預算，應該有一部分回到依賴本身

企業可以把關鍵開源依賴納入持續預算：購買合適的支援、資助維護者與安全稽核，或投入工程師協助上游。這些投入應延伸到日常維護，而不只在危機時支付一次性的漏洞獎金。

對外販售產品的供應商，也應清楚承擔所整合元件的更新責任。對內，企業則需要掌握執行環境與間接依賴，建立修補時限、替代緩解措施，以及更新後的驗證能力。

商業產品同樣可能有重大漏洞，付費也不能買到絕對安全。企業真正應該購買或建立的，是可驗證的維護能力、明確的責任，以及能運作的應變流程。

免費授權沒有讓維護成本消失。當企業長期把這筆成本留在上游，最後可能以停機、緊急修補與入侵損失的形式付回來。

PHP2Shell 值得追問的，正是我們是否願意為每天依賴的軟體，持續支付讓它安全運作所需的成本。AI 加快了這個問題的時間壓力，也讓過去被忽略的維護缺口更難繼續拖延。

本文依截至 2026 年 10 月 25 日的公開資料撰寫。關於成本外部化與能力失衡的論述，屬治理與風險分析；除 PHP Foundation 自行說明修補延誤與決策流程及資源不足有關之外，本文未據此認定特定漏洞由基金會制度、經費不足或個別企業未贊助直接造成。文中 AI 能力數據有數項來自 AI 或資安廠商自行發表的研究，已對照原文，但讀者宜留意其來源屬性。

大橘子的家

2026/10/25

當AI碰到軟體基金會