技述 — JS.GRIPE

危險的認知：當 AI 繁榮成為一種解釋世界的方式

toewpq — Tue, 10 Nov 2026 14:49:00 GMT

在上一篇《當語言改變答案：從語料污染、GEO 到大語言模型的判斷邊界》中，我討論了大語言模型如何受到資訊環境、訓練數據和檢索來源的影響。

文章最後留下了一個問題：當模型已經能夠接觸大量資訊，它究竟能否分辨哪些內容是可靠證據，哪些只是同一觀點的重複傳播？如果新的證據與原來的判斷發生衝突，它又能否據此修正自己的認識？

但這個問題不只存在於人工智能之中。

人同樣生活在由語言、媒體、歷史經驗和社會關系構成的資訊環境里。我們會依據自己掌握的證據作出判斷，也會通過情感理解風險、利益和公平。一個人可以認真思考，卻依然因為掌握的資訊不同、對因果關系的理解不同，而與別人得出截然不同的結論。

尤其當討論對象從歷史事實變成財富分配、就業和技術進步時，認識上的差異可能進一步影響現實中的經濟與政治行動。

最近有關 AI 泡沫的爭議，讓我重新注意到了這個問題。

AI 的繁榮，究竟意味著什麼？

2026年11月9日，Anthropic 發布 Claude Fable 5.2。工程師 Felix Rieseberg 隨後展示了一個由模型生成的網頁射擊游戲 Saltline。

根據開發者公開的資訊，模型在沒有中途人工反饋的情況下運行約八小時，按照 API 價格估算耗費約550美元，累計使用約4.45億輸入 Token 和270萬輸出 Token，其中大量輸入命中了緩存。

這是一項相當值得關注的技術實驗。過去可能需要程式開發、美術和聲音設計共同完成的游戲原型，如今可以由模型承擔大量制作工作。

但如果我們繼續觀察，這個案例還揭示了另一個問題。

開發者獲得了一款游戲，卻需要依靠遠程模型完成此前的生產過程。模型服務涉及雲端計算、伺服器、電力以及供應商的持續維護。

游戲完成後，若源代碼和資源能夠獨立保存，程式可以脫離原模型繼續運行；如果部分功能需要遠程服務，網路中斷或供應商停止提供服務就可能影響使用。

這說明 AI 改變了軟體的生產方式，卻沒有消除生產所需要的資源。部分成本從人工開發轉移到了模型推理、雲端基礎設施和持續維護。

另一項值得注意的進展來自開放權重模型。

2026年，Kimi K3 以約2.8萬億參數的規模發布。社區隨後出現了 kimi-k3-in-c 等項目，嘗試在沒有 GPU 的環境下，通過磁盤流式讀取、低精度權重和緩存管理運行大型模型。

開發者公布的一組測試記錄寫道：

8 tokens in 261.5 s

即生成8個 Token 耗時261.5秒。

雖然該測試報告的峰值內存約為8.24GB，但完整模型仍然需要約1.56TB的權重存儲空間，還需要額外空間保存預處理後的模型數據。

這項探索的意義不是讓普通電腦立即擁有流暢運行萬億參數模型的能力，而是展示了社區如何利用不同的計算方法降低模型運行門檻。

開放權重使外部開發者能夠研究、部署和改進模型，而不必將所有技術使用都綁定到原廠的在線接口。

這兩項技術進展都是真實的。然而，技術能力的增長並不直接等於企業利潤的增長。

一款游戲能夠自動生成，不代表有人願意長期購買；一款模型能夠在本地運行，也不代表所有使用者都擁有足夠的存儲和計算資源。

這些技術變化最終創造了多少經濟價值，仍然取決於它們幫助人們完成了哪些工作、降低了多少實際成本，以及有多少成果能夠被持續使用。

當資本市場根據技術進展不斷提高未來收益預期時，這個區別尤其重要。

2026年10月，國際貨幣基金組織在《全球金融穩定報告》中指出，AI 投資與盈利表現低於市場預期，可能引發相關資產價格調整，而債務融資和集中持倉會放大衝擊。

一項技術可以真正改變生產方式，圍繞它建設的部分基礎設施卻仍然可能出現投資過剩。

AI 技術是否成功、企業是否產生持續利潤，以及社會是否真正獲得相應收益，是需要分別檢驗的經濟結果。

當機器生產的東西，越來越多地由機器使用

網際網路正在發生一種變化。

AI 可以生成文章、圖片、代碼、影片和商品描述；搜索機器人與 AI Agent 又可以讀取這些內容，將其組織成摘要、推薦或進一步的生成結果。

更進一步，機器已經能夠執行支付。

2026年7月，Visa 與 Artemis 發布《Agentic Payments from the Ground Up》，研究 AI 代理參與的實際交易。

報告統計發現，x402 支付協議自2025年5月推出後，累計處理約1.096億筆交易，經過調整的交易金額約為1500萬美元。

Visa 將其中一類交易描述為：

payments that one piece of software makes to another

即軟體向另一個軟體支付費用。

這說明機器間支付已經不只是未來的設想。

但是，能夠完成支付，並不意味著機器擁有脫離人類經濟活動而獨立產生的購買力。

如果 AI 代理替用戶購買機票，支付的費用來自用戶預算。如果它替企業採購 API 或計算資源，支出則來自企業的經營資金。

機器負責執行交易，真正承擔費用的仍然是擁有資金並提出需求的人或機構。

因此，一億次機器支付，並不代表出現了一億次新的獨立人類消費需求。

如果一家企業使用 AI 批量生成文章，另一家企業購買算力讓 AI 閱讀這些文章，第三家企業再根據閱讀結果生成新的內容，那麼這一過程會不斷產生計算調用和商業支出。

但這些交易最終為人創造了什麼？

如果文章幫助人們獲得知識，程式完成了實際工作，或者自動化減少了企業的成本，那麼價值具有明確的現實來源。

可如果數字內容主要為了吸引自動化流量而生成，隨後又由機器讀取、改寫和重新發布，那麼內容數量和計算調用的增加，就不能直接解釋為相同規模的社會福利增長。

這也讓我重新想到上一篇文章關於 GEO 的討論。

當內容生產者越來越重視自己的材料能否被生成式搜索引用，資訊生產的目標也在發生變化。

一份資料被 AI 引用，並不證明它已經通過事實核查；一篇文章得到大量爬蟲訪問，也不證明有相應數量的人真正閱讀並從中受益。

當機器越來越多地生產、讀取和購買數字服務，我們更需要追蹤經濟活動最終由誰承擔成本，以及誰從中獲得實際價值。

企業節省了勞動成本，人們的收入怎樣變化？

如果只是討論 AI 企業之間的交易，我們依然停留在技術產業內部。

我更關心的是，普通人的經濟生活正在發生什麼變化。

2026年9月，美國人口普查局發表工作論文《Graduating into Disruption: Labor Market Outcomes for AI-Exposed College Majors》。

研究者利用大學畢業生的行政就業和收入記錄，比較不同專業在生成式 AI 普及後的勞動市場表現。

結果顯示，在經過統計調整後，AI 暴露程度最高的10%專業畢業生，首次就業概率下降約5個百分點，畢業初期完整季度的收入下降約13%。

論文摘要中的原文是：

full-quarter initial earnings declined by thirteen percent

研究還發現，收入下降大約一半來自相關行業內部的收入降低，其余部分與畢業生轉向餐飲、零售等工資較低的行業有關。

這項研究發現的是 AI 暴露程度與畢業生就業結果之間的差異，不能把全部變化都直接歸因於 AI 替代。但它已經把技術變化與部分年輕人真實的收入處境聯系起來。

另一項研究提供了相近的就業證據。

2026年8月，斯坦福大學數字經濟實驗室更新《Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence》。

研究使用 ADP 覆蓋數百萬名美國勞動者的薪資行政數據，發現22至25歲的年輕員工，在 AI 暴露程度較高的職業中，就業人數比按照低暴露職業同齡人趨勢推算的水平低約19%。

研究者指出，這種變化主要通過減少招聘體現，而不是現有員工大量離職。

原文概括為：

reduced hiring of young workers rather than increased separations

這讓我想到一個容易被宏觀就業統計掩蓋的問題。

一家企業決定減少招聘初級程式員、設計助理或文案人員時，現有員工可能沒有立即失業，社會總體失業率也未必立刻出現明顯變化。

但對於准備進入行業的年輕人而言，原本存在的職業入口已經變窄。

他們可能花費數年接受教育，卻需要從收入更低的工作開始，或者延長求職時間。

與此同時，房租、交通、食品和其他日常開支不會因為一個人尚未找到理想工作而自動停止。

研究中的收入差異並不能直接換算成家庭消費下降比例，但勞動收入與家庭購買能力之間的關系非常具體。

一個人收入降低後，需要減少支出、使用儲蓄、依靠家庭支持或增加負債來維持生活。

在必要開支之外，文化娛樂、旅行、電子產品、付費軟體和個人學習等消費往往需要重新安排。

這些變化不僅影響勞動者自己，也會影響依賴普通消費者購買產品的其他企業。

從這個角度看，AI 對勞動市場的影響不能只通過企業節省了多少人力成本來衡量。

技術讓某項工作更便宜，不等於原本依靠這項工作獲得收入的人，已經找到了新的收入來源。

誰能持續為 AI 付費？

技術企業當然希望更多消費者購買 AI 服務。

但消費者的支付能力並不會隨著模型能力提升而自動增加。

2026年10月，美國國家經濟研究局發表《Competition in Generative AI: Evidence from Consumer Demand》。

研究利用約1.74億名消費者、1140億筆銀行卡交易的數據，分析美國主要生成式 AI 服務的實際付費需求。

截至2026年4月，研究估計約2.9%的美國消費者為至少一項主要生成式 AI 服務付費。

絕大多數付費者購買的是每月30美元或以下的基礎套餐。主要服務商的年度客戶留存率則約在20%至45%之間。

這項研究衡量的是特定付費服務的消費者市場，並未包含全部免費用戶、企業採購或 AI 帶來的間接經濟效益。

但它至少說明，模型能力快速進步，與大眾願意持續支付多少錢，並不是同步增長的指標。

人們購買一項 AI 服務，必須考慮它能為自己提供什麼實際幫助，以及這筆開支是否值得。

對於依靠工資生活的人而言，訂閱模型與購買食品、支付房租、儲蓄或承擔家庭費用，都需要從可支配收入中安排。

這使 AI 產業出現一個需要特別關注的經濟關系：

企業越來越有能力通過 AI 降低生產所需要的人工成本，但大眾能否購買新增產品，仍然取決於他們能夠獲得多少收入。

這不是說整個經濟的消費只依靠工資。企業投資、政府支出、資本收入和國際貿易也會形成需求。

然而，勞動收入仍然是大量家庭獲取購買力的重要來源。

如果自動化減少了部分人的收入，而效率收益更多地集中到資產所有者手中，家庭消費結構和市場需求就會受到分配變化的影響。

產品變得容易生產，不等於產品自動擁有購買者。

當 AI 企業成為彼此的重要客戶

2026年10月，國際清算銀行發表《Circular relationships among AI firms》。

研究發現，2021至2025年流入 AI 企業的投資金額中，55.2%來自其他 AI 企業。在 AI 企業之間的投資交易中，按金額計算，46.4%還涉及投資雙方之間的商業供應關系。

研究者指出，這類關系會增加經濟活動的不透明程度，並可能產生宏觀金融風險。

2025年9月，CoreWeave 與 NVIDIA 簽訂初始金額63億美元的雲計算容量安排，為這種商業關系提供了具體案例。

CoreWeave 向美國證券交易委員會提交的 Form 8-K 說明，NVIDIA 在約定條件下需要購買其他客戶未購買的剩余算力。

文件中的關鍵表述是：

residual unsold cloud computing capacity

即尚未售出的剩余雲計算容量。

這份合同提供了銷售保障，也讓兩家公司的商業利益更加緊密。

但供應商承諾購買剩余算力，與已經存在足夠多的獨立終端客戶，並不是同一個事實。

如果一家模型公司依靠投資者資金採購雲算力，雲服務商再用預期訂單擴大資料中心，那麼這種擴張最終仍然需要有足夠的客戶收入或其他可持續現金來源來支持。

這正是 AI 泡沫爭議的重要經濟問題。

大量資本投入可能推動技術發展，也會形成建設、設備採購和就業活動。但如果最終需求無法支持長期經營，相關投資就可能無法獲得預期回報。

這些風險還會影響實體經濟。

資料中心需要電力、土地、伺服器、冷卻設備、建設工程和長期維護。一旦部分項目因融資困難停止建設，影響就不只發生在股票交易市場，還可能傳遞到設備供應商、建築承包商、能源企業和當地就業。

因此，判斷 AI 繁榮是否具有持續性，必須追蹤真實現金流和最終需求，而不能只觀察產業內部增長的訂單。

財富集中，會讓人怎樣理解經濟？

這使我重新想起馬克思的《資本論》。

在討論資本積累時，馬克思不僅關心社會能夠生產多少財富，也關注生產資料由誰擁有，以及資本積累如何改變勞動者與資本所有者之間的經濟關系。

在 AI 時代，先進模型、芯片、資料中心和平台網路都可能成為重要的生產資料。

企業擁有這些資產，便有機會通過計算服務、軟體授權和其他商業活動獲得收益。

而普通勞動者更多依靠工資、經營收入和有限的儲蓄維持生活。

2025年，國際貨幣基金組織發表《AI Adoption and Inequality》，利用家庭微觀數據及經濟模型分析 AI 對收入分配的影響。

研究指出，AI 可能替代部分高收入工作，改變工資差距；但資本回報增長可能使擁有較多資產的家庭獲得更大利益，從而擴大財富不平等。

這是基於模型的研究結果，並非已經測量到的全球財富變化。但它提出了一個具體問題：生產率提高產生的收益，是否能夠持續進入勞動者的實際收入？

2026年10月，國際勞工組織在《Making productivity growth work for people》中指出，勞動生產率增長與勞動者收入增長之間仍然存在差距，尤其在低收入國家更加明顯。

技術進步本身不能自動決定收益如何分配。

這使財富集中不再只是抽象的公平問題，而是涉及普通人的經濟生活。

當部分勞動者的收入增長放緩，而資產收益繼續增加時，他們對現有經濟制度產生不滿，並不難理解。

這種不滿可以來自真實的生活經歷。

但要進一步判斷財富差距究竟由什麼造成，還需要研究創新收益、資本投入、市場競爭、繼承、壟斷與其他制度因素。

2026年3月，《American Economic Review》發表《Zero-Sum Thinking and the Roots of US Political Differences》。

研究調查20,400名美國居民，發現零和思維與支持政府再分配等政策存在顯著關聯，並與個人及其家庭的社會流動經歷有關。

所謂零和思維，是傾向於認為一方獲得收益，必然需要其他人承擔相應損失。

這項研究不能證明支持重新分配的人缺乏理性，也不能據此推斷他們會採取激進的政治行動。

但它揭示了一個值得研究的現實：人們對於財富如何產生的理解，會影響他們認為怎樣分配財富才合理。

一個人如果長期努力卻無法改善收入，可能認為現有制度限制了自己的機會。他可以基於這種經歷認真思考改革，也可以要求改變企業和社會的分配制度。

真正的問題在於，如果經濟不滿逐漸發展為認為某一群體的全部財富都來自對其他人的剝奪，復雜的經濟關系便可能被壓縮成一種簡單的身份判斷。

歷史上，確實發生過這種轉變。

瑞金土地革命：當經濟解釋進入現實行動

1929至1934年的贛南閩西中央蘇區，特別是1933年瑞金的查田運動，提供了一個值得研究的歷史案例。

這里的土地改革發生在1949年以前，不能直接使用中華人民共和國成立後的土地改革敘述代替。

1931年12月1日制定的《中華蘇維埃共和國土地法令》，規定對特定土地實行無償沒收，並重新分配土地及相關生產資料。

土地分配涉及真實的經濟利益。對於無地或少地農民，獲得土地意味著擁有改善家庭生活的重要生產資源。

但隨著階級成分的政治化，土地所有狀況開始進一步影響個人在社會組織中的地位。

1933年的《關於查田運動的初步總結》記載，瑞金壬田區在55天內查出地主、富農300戶，並：

槍決了群眾所謂“大老虎”的十二個反革命分子

同一份報告還記載，當地組織了十次群眾審判大會及三次巡回法庭活動。

這些數字來自當時運動組織者的報告，屬於需要與其他檔案繼續交叉核對的一手記錄。

不過，報告已經明確顯示，土地重新分配與階級身份審查、群眾審判和人身懲罰發生了結合。

孟慶延在《蘇區革命與地方社會：查田運動之發軔新探》中，進一步利用瑞金地方檔案、宗族資料及當事人回憶，研究查田運動與原有地方社會矛盾之間的聯系。

他的研究指出，查田並非發生在一個沒有內部利益衝突的農村社會。原有宗族關系、幹部更替、地方利益及政治動員相互交織，使階級分類能夠參與重新組織地方權力。

為了進一步核查這段歷史，還需要閱讀臺灣保存的國民政府和國軍資料。

臺灣國家發展委員會檔案管理局公開的《剿匪時期之經濟措施》，記載了1933至1934年南昌行營組織割禾隊，進入蘇區封鎖區域收割稻谷的政策。

檔案中的原文包括：

掩護割禾隊搶割稻禾

這說明當時的經濟困難還受到國軍主動實施的糧食徵取及軍事封鎖影響。

因此，不能把瑞金所有農業困難都歸因於蘇區內部的土地改革，也不能因為存在外部軍事封鎖，就否認階級划分與政治清查造成的人身傷害。

不同材料需要分別承擔它們能夠證明的事實。

尤其值得注意的是，當經濟身份被用於決定一個人的財產權、政治地位乃至人身安全時，財富分配已經不再只是調整土地資源的經濟政策。

這段歷史提醒我，經濟不滿可以包含真實的利益訴求，但一種關於財富來源的解釋，一旦成為對整個身份群體作出懲罰的依據，便會產生超出最初分配問題的社會後果。

如果做蛋糕的人消失了

我想用一個簡單的比喻繼續討論財富分配。

社會已經擁有一塊蛋糕，有人認為分配不公平，希望重新切分。

但下一塊蛋糕仍然需要有人制作。

它需要原料、設備、技術、勞動、組織和投資。

在農業社會，土地所有者不一定是實際耕作者。佃農、雇農、自耕農及經營者都可能參與生產。

在現代企業，股東、工程師、管理人員和普通員工也承擔不同的經濟職能。

所以，改變資產所有權並不意味著生產能力自然消失。

真正需要關注的是，生產資料能否繼續得到有效使用，勞動者能否保有穩定的收入，經營者是否願意繼續投資，以及社會能否保留不斷創造財富所需要的知識與組織能力。

這一問題在歷史上有具體的實證案例。

2017年，Shuo Chen 與 Xiaohuan Lan 在《American Economic Journal: Applied Economics》發表《There Will Be Killing: Collectivization and Death of Draft Animals》。

研究比較約1600個縣在1955至1957年中國農業集體化期間的不同實施時間，估計產權轉移預期造成約12%至15%的耕畜損失，並通過牲畜投入減少及生產率下降，使糧食產出降低約7%。

這一事件發生在1950年代中期，不是1933年的瑞金查田運動，不能將其產量損失數字套用到瑞金。

但它證明了一個可以觀察的經濟機制：人們對未來財產權的預期，會改變他們如何處理現有生產資料。

對於個體農民而言，如果認為自己的耕牛即將失去控制權，提前宰殺可能是保護眼前收益的選擇；對整個農業社會而言，耕牛損失意味著未來能夠投入耕作的生產資源減少。

個人作出的選擇可以具有經濟邏輯，大量類似行為匯總之後，卻可能降低整體產出。

這比簡單地說人們為了分蛋糕忘記做蛋糕，更能解釋制度為什麼會影響生產。

對 AI 時代而言，問題同樣不止於誰擁有現有財富。

如果 AI 讓部分勞動者的收入下降，而新增資本收益沒有充分轉化為新的工作機會、實際工資或更低的生活成本，那麼普通人分享技術進步成果的渠道就會受到影響。

如果企業只關注減少人工開支，卻忽略勞動者同樣是現實市場的重要消費者，技術帶來的效率增長就可能與家庭購買力出現脫節。

反過來，維持長期生產也需要保護知識、技能、投資與持續創新的條件。

我們需要研究的是，怎樣讓更多人獲得先進生產工具的使用機會，並通過勞動、經營和其他正當經濟活動分享收益，而不只是圍繞已經形成的財富存量展開爭奪。

危險的不是提出問題，而是某種解釋不再允許被檢驗

回到 AI 泡沫。

現在已經能夠觀察到幾種真實發生的現象。

先進模型完成了以前難以自動化的軟體任務，但並沒有因此直接證明全部 AI 投資都能獲得預期回報。

AI 企業之間形成了大量投資和採購關系，部分算力供應商還通過承購協議保障未來銷售，但這些合同不能代替獨立終端需求的測量。

美國勞動市場的研究也已經發現，部分 AI 暴露程度較高的年輕勞動者面臨就業入口收窄和初期收入下降的現象。

與此同時，真實付費的消費者仍然會根據價格和需求選擇 AI 服務，而不會因為模型變得更強，就無限增加自己的訂閱預算。

這些事實共同指向一個值得繼續調查的經濟問題：AI 產業生產能力和資本投資正在迅速擴張，技術收益能否充分進入普通人的收入和消費，仍然需要通過實際數據檢驗。

危險的認知，恰恰可能從忽略這種聯系開始。

上一篇文章中的 Qwen 測試，已經展示過模型可以通過遺漏重要材料改變用戶最終得到的資訊結構，而不必直接編造事實。

今天的 AI 經濟敘事也存在類似的問題。

如果行業報告大量強調模型參數、計算需求、資本開支、合同金額和交易次數，卻很少衡量勞動者收入、居民購買能力與真實生產率，那麼這些數字即使全部正確，呈現出來的經濟圖景仍然可能不完整。

這並不需要有人故意制造虛假資訊。

只要某些指標長期獲得更多關注，另一些指標不斷被忽略，公眾對於經濟發展的理解就可能逐漸圍繞少數可見數字形成。

當一種解釋被不斷傳播，它便可能成為人們理解新事件的默認框架。

如果模型完成了新的復雜任務，人們可能更加相信 AI 產業必然繁榮；如果一家科技企業公布更大的投資計划，市場可能將其理解為未來需求繼續擴張的信號。

但這些判斷最終仍然需要回到真實現金流和實際經濟收益。

同樣，當人們看到貧富差距擴大、就業機會減少，也需要繼續研究問題由什麼機制形成，而不能只根據經濟身份認定某個群體應承擔全部責任。

瑞金土地革命的歷史說明，一種經濟解釋一旦進入階級分類、群眾審判與財產處理制度，就能夠產生非常具體的現實後果。

人不是單純由情緒驅動的對象。

一個人可能認真衡量自己的利益和風險，也可能基於所掌握的資訊，形成一套邏輯自洽的解釋。

問題在於，如果最初的資訊存在缺漏，或者對因果關系的理解已經偏離事實，繼續推理並不一定能夠自動糾正錯誤。

這使我重新理解上一篇文章留下的問題。

真正危險的認知，不一定表現為明顯的謊言，而可能是一套看起來完整、能夠解釋許多現象，卻不斷排除不符合自身判斷的證據的世界觀。

當這種認知只是影響一次模型回答，錯誤還可以通過資料核查得到糾正。

但當它進一步影響企業投資、就業安排、公共政策與個人權利時，錯誤就可能產生持續的現實成本。

AI 泡沫最終需要回答什麼？

我越來越覺得，預測 AI 泡沫什麼時候破裂，不應該成為這場討論唯一的目標。

即使資本市場發生大規模調整，已經開發出來的軟體、模型和工程技術也不會因此自動消失。

技術也可能持續進步，而普通人的生活條件沒有同步改善。

因此，真正需要觀察的，是生產率增長如何轉化為收入，企業投資能否得到持續的客戶需求支持，以及社會成員有沒有能力參與和享受新增的經濟成果。

如果 AI 讓商品和服務變得更便宜，我們應該能夠從價格和購買能力中看到變化。

如果 AI 讓勞動者節省了時間，我們應該繼續觀察這種效率是否帶來更高收入、更合理的工作安排，或者新的發展機會。

如果 AI 企業持續擴大投資，我們應該追蹤這些支出創造了多少能夠長期存在的產出，而不是只看資金如何在產業鏈內部循環。

這些問題最終都與人的生活有關。

因為人不只是企業成本表上的勞動費用，也不是技術產業需要爭取的一個訂閱帳戶。

人需要收入來維持生活，需要機會來積累能力，也希望能夠參與創造，而不只是被動接受技術生產出來的商品。

從瑞金的歷史到今天的 AI 產業，生產工具、財產所有權和資源分配方式都發生了巨大變化，但有一個經濟問題始終值得討論：

當社會創造財富的能力不斷增長，人們是否仍然擁有參與生產、獲得收入和分享成果的機會？

上一篇文章討論模型如何理解世界。

這一次，我更希望討論我們如何理解所謂的經濟繁榮。

如果最終的評價只剩下模型參數、算力規模、機器交易次數和企業估值，卻忽略了普通人的勞動收入、消費能力與生活質量，那麼這種繁榮敘事便沒有完整回答經濟發展究竟為了什麼。

而當一種解釋開始決定哪些證據值得關注，並不斷排除無法支持它的事實時，我們更應該重新審視自己的判斷。

我們究竟是在依據證據理解世界，還是在依據已經形成的世界觀決定什麼能夠成為證據？

從 Opus 5.5 的影片出發：動畫工作流與連續試播的可行性

toewpq — Tue, 13 Oct 2026 18:57:12 GMT

看到 Claude Opus 5.5 製作的《I'm Upping My P(doom)》後，我開始測試一件事：讓 coding agent 組織畫面、動作、配音與剪輯，能否做出一支完整影片。

這輪已完成兩支片：《雨夜送藥》150 秒，採用素材複用與二維角色動作；《垃圾車來了！》160 秒，把人物、物件與環境一起生成。兩支片呈現不同的製作取捨，也讓我把工作流整理成三個方向。

從 Opus 5.5 的作品開始

!embedyoutube

作者公開了 PDoomVideo 原始碼。專案說明中，Opus 5.5 負責分鏡與動畫程式，畫面用 p5.js、p5.brush、無頭 Chrome 與 FFmpeg 渲染，音樂採用既有歌曲。

我接著探索的是 Agent 如何組織製作過程。畫面路線改用 ImageGen：生成素材、審看動作與空間，再把選用畫面、聲音與字幕編成影片。

第一條：動圖與動作庫

動作庫保存人物 ID、姿態、動作時間與預覽。下方是八個生成姿態組成的揮劍動圖，動作結束後回到起點，循環有明確的重置接點。

八個生成姿態組成的揮劍動圖

!embedishare

這一層的價值是複用。之後要讓同一角色站立、轉頭或揮手，可以引用已審看的動作，不必每次從人物設定重新開始。原創形象的參考圖、表情、服裝與動作索引也已預留，後續從這裡接入。

第二條：有限動畫與低成本靜態影片流

《雨夜送藥》：素材複用與二維角色動作。

!embedishare

《雨夜送藥》已通過成片驗收。它從下班收到消息、雨夜走到候車處，一直講到回家送藥。辦公室、街口、候車、車內與回家等鏡頭，用完整插畫、停留與輕微運鏡推進；74–84 秒的繞行段，在同一背景上用二維骨骼驅動角色紋理。

回看整片，特點很清楚：場景穩定，少量畫面就能承載完整故事。角色移動由程式持續計算，旁白與字幕連接鏡頭。候車和辦公室畫面停留較長，觀感偏插畫敘事；繞行段有明顯二維紙片感。它已完成有限動畫的目標，接下來要加強人物與場景互動。

素材如何複用

我把有限動畫（素材複用）分成兩種鏡頭。第一種直接複用完整插畫，適合聽消息、看遠處、車內休息與收尾。第二種保留背景，複用透明人物姿態或角色紋理，用於站立、短步與簡單動作。

同一街區可換成店外、人行道或候車空地。以鏡頭為單位複用，不必整片鎖在同一背景。人物要拿東西、坐下、跨台階或被前景遮住時，先判斷接觸能否靠現有素材表達；複雜部分轉到第三條整場景流程。

具體順序是：

定義鏡頭起點、終點、動作與道具狀態，先標出需要接觸環境的部分。
審看場景母圖，確認地面、開放路線、障礙端點與機位。
選同一人物、服裝與道具狀態的素材，保留鞋底與完整輪廓。
匹配人物比例、光線、落腳與影子，安排保持、移動、換腳與收勢。
按實際旁白長度安排鏡頭與字幕，檢查完整音畫與前後狀態。

提示詞也從構圖階段限制互動，例如：

角色在平坦開放的人行空地站立或短步，身體與鞋底完整可見。牆、車輛、桌椅與欄杆都在路線之外。人物不走到物件後方，不扶欄、不倚靠、不拿背景物件、不跨台階。既有提袋保持同一隻手，起點與終點在同一高度的地面。

成本節省來自複用背景、人物素材與剪輯流程，減少重複生成整張場景。切圖、綁定與審看仍是製作工作，所以要按鏡頭選方案；複雜互動一直修合成，反而增加返工。

把滑腳單獨量測

支撐腳對照：保留與取消落腳約束。

!embedishare

相同紋理與路線做兩個版本：一個固定支撐腳，另一個讓鞋底在支撐期間跟著人物前移。程式讀取編碼後畫面，用鞋底紋理匹配檢查 0.25 秒內位移。

條件	可見量測窗口	中位位移	95 分位
固定落腳	27	0px	3px
取消約束	18	20px	約 21px

對照把滑腳問題顯示出來，也提供可重用的動作庫檢查。人物是否繞過護欄、碰到物件，另看整段畫面的空間關係。

第三條：參與環境互動的影片流

《垃圾車來了！》：人物、道具與背景整場景生成。

!embedishare

《垃圾車來了！》專門測試接觸與狀態變化。剛搬來的以安聽見垃圾車音樂，提起分類好的垃圾與回收物下樓；鄰居的袋子勾到扶手，瓶罐掉落，她停下幫忙。倒完垃圾一起走回公寓，陌生巷子也熟悉了一點。

每張圖把人物、物件、背景、光線與接觸影子一起生成。下一步上傳上一完整影格，提供人物與場景參考，說明接下來的小動作。同一巷弄可延伸門口、人行道與收運點，背景不要求像素固定。

回看片子，最有用的改善在拿取與交付：先放下自己的袋子，蹲下拿瓶罐、放回鄰居提袋；到了收運處，交付垃圾和回收後，手上的狀態跟著變化。動作與物件關係直接畫在場景裡，比在固定底板上移動人物更適合這些事件。

全片選用 76 張整場景姿態，配 11 段臺灣中文旁白與 43 條字幕。步行等部分仍看得到姿態停留與切接，但故事中的具體接觸比前一條路線更完整。生成原圖為 836×470 與 1672×941，成片輸出 1080p；遷移前網頁以 540p 副本播放，現在改由 ishare 提供自適應串流。

幾次錯誤如何改變製作方法

繞行變成翻越護欄

早期反例：要求繞行，畫面卻出現扶欄與翻越姿態。

!embedishare

早期實驗寫的是從障礙旁繞過，生成末段卻伸手扶欄，腿也抬到護欄附近，讓動作讀成翻越。這是具體的路線與動作錯誤。後來低成本片改用明確開放路線與二維控制；整場景路線也把人物與欄杆的複雜遮擋列為構圖限制。

先把端點與可走空地放入鏡頭，手保持身旁，再看整段是否沿該路線移動。只看腳底固定或人物朝前，容易漏掉人與護欄的關係。

樓梯修正版仍有台階異常

G09R 樓梯修正版，台階、平台與扶手坡度不連貫

!embedishare

垃圾車故事的 G09、G10、G11 出現樓梯空間混亂。首次重做後，G09R 更像公寓，但我在成片中又指出台階異常。最後整組撤出，換門鎖近景，再接鞋部與二樓平台，把下樓這件事講清楚。

最後選用的門鎖近景

!embedishare

處理直接改變了鏡頭設計：近景避開複雜梯段，平坦平台承擔拾瓶動作，敘事繼續成立。後續遇到同類空間問題，也先考慮機位與動作拆分。

道具數量與左右手跳變

地上還有罐子，袋口卻出現另一只罐子的棄用畫面

!embedishare

撿物段曾出現地上罐子仍在、袋口卻多出一只；門鎖新組也有鑰匙與袋把突然換手。前者按庫存重選，後者棄第三格、留第 1、2、4 格。自己的垃圾袋要先放牆邊才進入蹲下，不能提前消失。

這些錯誤讓提示詞具體起來：先握住再拿起，接住後放手；寫明每隻手與每件物品的位置。失敗圖單獨存放，正式時間線只引用審看後的影格。

聲音與敘事一起調整

初版持續低頻與重複高音鈴聲讓畫面顯得詭異。後來移除低鳴，把垃圾車音樂縮成短提示，加入稀疏鋼琴，旁白時壓低背景音。

配音改第三人稱畫外旁白，字幕跟著旁白走。故事能展開，也避免嘴型牽制台詞。Edge 語音原路徑遇到 403 後，改用我提供的 wangwangit/tts，透過本地 Microsoft REST 路徑完成臺灣中文旁白。

把雨夜花店做成連續影片

後續試播按這張六格圖考慮情節：路過花店、發現倒盆、蹲下接觸、扶正花盆、與店員致意，最後繼續前行。

!embedishare

這張圖負責故事與構圖。它不是影片抽格，也不能證明扶正和致意已經發生。製作時仍把動作拆成可觀察的狀態，先走近、停下，再蹲下觸盆，確認接觸後才進入扶正。

我在 gemini.google.com 生成了第一條連續片段，記錄中的模型名稱是「Gemini 4」；底層影片模型版本沒有獨立核實，不把它寫成已確認的 Veo 對照實驗。

!embedishare

片段為 10 秒、1280×720、24fps，240 格都能完整解碼。它保留同一家花店、同一人物和一只倒地目標盆，呈現走近、停步、下蹲與伸手。這至少說明，從場景參考組織一段連續動作的路線有可行性，值得繼續做下去。

接觸還沒有完成。女主蹲下的位置離盆沿太遠，手伸向散落葉片；9 秒證據格和最後一格都看得到手與陶器之間的間隔。

!embedishare

因此這條保留為可行性試播，審片結論仍是 NEEDS_REVIEW。沒有可觀察的觸盆完成點，就不剪成「已經扶起」的片段，也不為填滿輸出長度安排空動作。下一輪只改停步位置：走到外露盆沿旁，略彎肘就能觸及後再蹲下。接觸通過後，才繼續扶正、與店員致意和離開。

Codex 在這裡負責核對母圖雜湊、解碼抽格、檢查物件數量、落腳與接觸狀態。媒體技術檢查通過和劇情動作通過分開記錄。實際網頁附件與提交提示詞沒有留證，參考綁定保持未驗證；不能只憑畫面相似就宣布參考圖已正確綁定，也不能把這個缺口歸咎於模型。

這輪研究留下什麼

三條流程各有任務：動作庫保存可引用的人物動作；低成本流程複用素材，完成插畫敘事與簡單移動；整場景流程負責人與道具、環境的接觸事件。

兩支成片給出實際結果，花店試播補上連續生成影片的初步可行性與接觸缺口。下一步加入原創形象時，我會沿用角色參考、表情、服裝與動作索引，讓同一形象進入三種流程，再看動作與環境如何配合。

原始碼、提示詞、審查結果和媒體清單整理在倉庫 video/：動作庫、有限動畫、整場景敘事和花店試播各一個目錄。圖片與影片遷到 ishare，倉庫按連結引用；重建時按需下載原圖並校驗雜湊，串流版不冒充原始下載檔案。實際使用的 MIT 語音依賴已納入 third_party/tts/，保留上游版本和授權。

查看開源工作流

《垃圾車來了！》完整 1080p 成片

《雨夜送藥》完整 720p 成片

當語言改變答案：從語料污染、GEO 到大語言模型的判斷邊界

toewpq — Sun, 11 Oct 2026 16:50:00 GMT

最近重新思考了一個早些年接觸過的現象：同一個問題，分別使用簡體中文、繁體中文和英文向大語言模型提問，可能得到傾向不同的回答。

最典型的例子之一，是臺灣與中國大陸的關係。當語言發生變化時，模型可能改變敘述方式，甚至在被要求選擇立場時給出不同答案。

這看起來只是一個有關政治偏向的問題。但繼續思考下去，我認為更值得關注的並不是模型最終支持哪一種立場，而是它如何形成答案。

如果模型會因為語言不同而改變判斷，那麼這種變化究竟來自訓練語料中的資訊分佈、後訓練形成的回答邊界，還是模型對提問環境的適應？

而當網際網路內容可以通過語料投毒、搜尋優化與生成式引擎優化（GEO）被主動塑造時，我們還需要考慮另一個問題：

模型所接觸到的資訊，本身是否已經受到篩選、重複或操縱？

這意味着模型的可靠性，可能不僅取決於它掌握了多少知識，還取決於這些知識如何形成、哪些資訊能夠進入答案，以及它究竟使用什麼標準評價證據。

不同語言下的政治立場差異

2024 年，Yu-Ting Lin 與 Yao-Chung Fan 在 ROCLING 發表了《Unveiling Language-Driven Political Stances in Large Language Models on China and Cross-Strait Relations》。

研究者選擇八款來自中國大陸、臺灣和美國的模型，使用簡體中文、繁體中文和英文提出二十道有關中國政治及兩岸關係的問題，比較它們在不同語言下表現出的政治立場。

實驗結果呈現出明顯差異。

例如，GLM-4-9B 在簡體中文下，與中華人民共和國政府官方立場的一致率為 60%；繁體中文下降至 40%，英文則為 15%。

Qwen2-7B-Instruct 也表現出類似趨勢，三種語言下的一致率分別為 75%、55% 和 45%。

但並非所有模型都具有相同傾向。

同樣來自中國大陸的 Yi-1.5-9B，在簡體中文、繁體中文和英文下的一致率分別為 35%、30% 和 30%，沒有表現出與 GLM-4 相同幅度的變化。

這意味着，至少在研究所採用的測試條件下，不能僅憑模型開發地區，就斷定它一定具有某種固定的政治立場。

同時，研究中的「一致率」也需要正確理解。

研究者並沒有要求模型必須支持中國大陸或者臺灣的某一立場，而是在系統提示中要求模型根據自己的傾向評價政治問題，儘量選擇明確立場，而不是保持中立。

例如，面對「臺灣是中國的一部分」這一陳述，模型需要從贊成、反對和沒有意見三個選項中選擇，並說明理由。

隨後，研究者根據回答是否接近中華人民共和國政府的官方立場進行分類。

因此，這裡的「一致率」衡量的是政治立場的對應關係，而不是回答的事實準確率。

其統計方式同樣值得注意：中立和拒答被排除在一致率的分母之外。

以 InternLM2.5 的英文測試為例，二十道題中有十六道被歸為中立，三道符合大陸官方立場，一道與之相反。

如果只計算明確表態的四道題，一致率為 75%；但如果觀察全部二十道題，符合大陸官方立場的回答實際上只佔 15%。

這兩個比例並不矛盾，卻回答了不同的問題。

前者反映模型明確表態時的傾向，後者反映用戶在全部測試中實際獲得某種立場回答的頻率。

如果忽略中立回答的數量，就可能高估某種立場在整體回答中的出現程度。

此外，論文採用的是政治立場問卷，而不是開放式事實問答。

「你是否贊成臺灣是中國的一部分」與「請區分臺灣目前的實際治理、不同政治主體的主權主張及國際承認情況」，要求模型完成的是不同任務。

前者要求對政治陳述表達態度；後者要求組織和解釋事實，不一定需要將複雜問題壓縮成贊成或反對。

但是，這項區別本身還不能證明模型在開放式事實問答中一定更加可靠。

因為研究沒有提供同一模型在這兩種任務下的完整對照實驗，我們只能確認它所觀察到的立場差異，而不能直接推斷普通事實問答會產生什麼結果。

因此，這項研究最有價值的發現是：

在特定政治立場問卷中，部分模型的回答傾向確實會隨語言變化，而這種變化並不能簡單歸結為開發地區。

至於語言為什麼會產生這種影響，仍然需要研究其背後的資訊環境和訓練過程。

語言背後的資訊環境

不同語言的資訊環境並不完全相同。

歷史教材、新聞媒體、政府文件、學術論文以及網絡社區，都可能形成各自相對穩定的敘述方式。

尤其在政治與歷史爭議中，資訊管制、媒體制度、社會認同和傳播渠道，會影響某些觀點出現的頻率，以及公衆能夠接觸到哪些不同解釋。

但是，我不認為應該簡單地將簡體中文等同於封閉的資訊環境，把繁體中文或者英文等同於開放的資訊環境。

語言不是資訊自由度的充分指標。

即使在資訊來源相對多樣的環境中，商業利益、政治宣傳、媒體編輯與算法推薦，也可能影響某些內容的可見度。

而且，同一種語言內部也可以存在截然不同的資訊來源。

因此，真正值得比較的，並不是哪一種語言天然更加客觀，而是不同語料環境在事實覆蓋、觀點分佈與證據品質上存在什麼差異。

這種差異有可能被模型學習，但訓練語料並不是唯一的影響因素。

模型通常還需要經過指令微調、偏好優化及其他後訓練程序。開發者可以通過這些階段改變模型的回答習慣、內容限制和拒答邊界。

在某些地區，這種設計還可能受到明確的監管要求影響。

例如，中國大陸的《生成式人工智能服務管理暫行辦法》對境內面向公衆提供的生成式人工智能服務提出了政治內容規範，包括不得生成某些被認定損害國家利益、國家形象或破壞國家統一的內容。

2026 年發表於《PNAS Nexus》的《Political censorship in large language models originating from China》，進一步比較了中國大陸來源與非中國大陸來源模型對一百四十五個政治問題的回答。

研究觀察到，樣本中的中國大陸來源模型在敏感政治問題上具有更高的拒答率、更短的回答，以及更多不準確回答。這些差異在政治敏感程度較低的問題上有所減弱。

這提供了一個具體證據：不同模型的政治內容表現，不能僅通過語言能力或一般技術差異解釋。

不過，研究者同樣指出，該研究屬於觀察性研究，不能單獨證明監管要求與特定模型輸出之間的完整因果關係。

從結果來看，我們可以識別某些模型在特定政治議題上存在系統性差異。

至於這些差異有多少來自預訓練語料、有多少來自後訓練和制度約束，則不能只憑一次黑箱輸出直接確定。

模型繼承資訊環境中的偏差，與開發者主動設定回答邊界，是兩種需要區分的機制。

它們可能同時存在，最終卻表現為相似的回答差異。

語料污染：資訊出現得更多，不等於證據更加充分

如果進一步討論訓練語料，就會發現網際網路本身已經不是一個完全自然形成的資訊集合。

搜尋引擎優化、自動化內容生產、商業宣傳和有組織的資訊傳播，都可能改變某些敘事在公開網絡中的出現頻率。

一種觀點被大量重複，並不意味着它具有同等數量的獨立證據。

在這裡，需要區分幾類不同的問題。

第一類是普通的資料品質問題，例如錯誤資訊、大量重覆文本、過時資料和缺乏事實依據的自動生成內容進入訓練資料。

第二類是有目的的資料投毒，即攻擊者主動控制部分訓練材料，試圖讓模型學習某種錯誤行為或者在特定條件下產生預期輸出。

第三類則是基準資料污染，即模型訓練時已經接觸過用於評價自身能力的測試資料，使評測結果失去部分獨立性。

這些情況並不相同，不能因為網際網路上存在錯誤資訊，就認定所有模型都受到了有目的的資料投毒。

但是，資料投毒本身已經有可以驗證的實驗依據。

2025 年，Anthropic 與英國 AI Security Institute、Alan Turing Institute 發佈了《A small number of samples can poison LLMs of any size》。

研究發現，在其實驗設置中，僅注入約 250 份惡意文檔，就可以讓所測試的不同規模模型形成特定後門行為。

需要明確的是，這項實驗關注的是觸發後生成亂碼的簡單後門，並沒有證明少量文檔足以讓模型接受某種政治立場，更不能據此直接推斷現實模型的政治回答已經受到此類攻擊。

但它至少反駁了一種過於簡單的假設：只要訓練語料規模足夠龐大，少量惡意資料就不可能產生影響。

資料規模和抗污染能力並不能直接畫上等號。

另一個值得關注的問題，是語料中不同來源之間的獨立性。

假設一份未經充分覈實的商業報告被多個網站轉載，並通過自動化工具改寫成不同的行業分析、新聞摘要和問答文章。

最終，模型可能在語料中多次接觸同一個結論。

但這些文本未必代表多份獨立研究，也可能只是同一原始材料經過多次傳播後的不同版本。

如果模型不能有效區分證據來源，它學到的可能是某種說法具有較高的文本出現頻率，而不是該說法已經得到廣泛獨立驗證。

這裡的風險並不一定表現為模型完全不知道某些事實。

它也可能掌握大量資訊，卻無法正確識別不同材料之間的來源關係。

GEO：當內容開始為了進入 AI 答案而優化

如果說語料污染主要涉及模型訓練階段，那麼 GEO 則把資訊選擇問題進一步延伸到了生成式搜尋。

GEO，即 Generative Engine Optimization，生成式引擎優化。

傳統 SEO 主要關注網頁在搜尋結果中的排名，而 GEO 更關注內容能否被生成式搜尋系統檢索、採用、引用，並進入最終生成的回答。

2024 年，Pranjal Aggarwal 等人在 KDD 發表了《GEO: Generative Engine Optimization》。

研究者通過 GEO-bench 等實驗發現，對來源內容進行特定優化，可以提高其在生成式引擎答案中的可見度，部分測試條件下最高提升約 40%。

這裡的提升指的是來源可見度，不是事實準確率，也不能理解為 GEO 可以讓任何錯誤資訊穩定控制模型答案。

GEO 本身也並不必然存在問題。

提供清晰的資料結構、準確的資料、明確的來源和便於機器讀取的內容，都可能幫助生成式引擎更好地利用資訊。

但是，GEO 帶來了一個新的利益關係：內容生產者不再只是爭取用戶點擊網頁，也開始爭取自己的內容進入 AI 最終回答。

2026 年 ICML 的《Position: Generative Engine Optimization Creates Underexamined Risks》進一步討論了 GEO 可能帶來的影響力集中，以及商業影響未經充分披露便進入生成式答案的風險。

這是一篇立場論文，提出的是需要重視和治理的風險，並不意味着所有生成式搜尋平臺都已經發生了同樣程度的問題。

但有一點可以通過 GEO 的原始實驗得到直接支持：

資訊進入生成式答案的機會，不完全由其事實品質決定，內容的組織和呈現方式也能夠產生影響。

這意味着，某個來源更容易被 AI 引用，不必然說明它比其他來源更加可信。

對於普通用戶而言，這個問題可能比傳統搜尋更加隱蔽。

在傳統搜尋中，用戶通常會看到多個網頁標題，並自行決定訪問哪些來源。

生成式搜尋則將檢索與資料綜合進一步整合到同一個回答中。

用戶看到的可能是一段已經組織完成的解釋，以及少量附帶引用。

這時，哪些資料被選中、哪些沒有被選中，以及被選中的資料如何進入最終敘述，就成為影響認知的重要環節。

不過，GEO 仍然需要與惡意檢索污染區分開。

普通 GEO 可以是合法的資訊可見度優化；檢索污染則可能包含明確的攻擊目標，例如故意投放錯誤內容，使系統生成不可靠答案。

2025 年 EMNLP Findings 的《The RAG Paradox》就研究了一種黑箱攻擊方式。

研究者利用 RAG 系統暴露的來源資訊，識別哪些資料容易被檢索，再製作看起來自然可信的污染文檔，在實驗中成功降低了系統表現。

這項研究支持的是：即使攻擊者無法直接修改模型參數，也可能通過外部知識來源影響使用檢索增強生成技術的系統。

它不證明普通 GEO 就等於攻擊，也不能證明所有生成式搜尋系統都具有同樣的脆弱性。

但是，這些研究共同說明，模型最終採用什麼資訊，除了受模型本身影響，也可能受到外部內容可見度與檢索機制的影響。

從資訊可見度到證據可信度

這裡存在一個容易被忽略的區別。

某種內容被大量傳播，不意味着它擁有同等數量的獨立證據；某個來源被 AI 引用，也不代表它已經通過事實覈查。

訓練語料和實時檢索的影響方式並不相同。

對於已經訓練完成、沒有外部檢索能力的模型，新發佈的 GEO 內容不會直接改變它的參數。

但對於使用搜尋、RAG 或外部知識庫的系統，檢索結果可以在當前回答中直接影響模型使用的材料。

如果這些公開內容後來又進入新一輪訓練資料收集，那麼影響還可能進一步延伸到未來模型。

後一種情況是一條技術上可能發生的傳播路徑，而不是可以不經驗證便認定已經發生的因果鏈。

因此，有必要把資訊風險分成不同階段觀察。

在訓練階段，需要檢查資料來源、內容品質與重複分佈。

在檢索階段，需要檢查為什麼某些來源被採用、不同來源是否獨立，以及是否存在針對檢索系統的內容操縱。

在生成階段，則需要檢查模型有沒有忠實呈現證據，是否遺漏關鍵資訊，以及有沒有補寫未經證明的解釋。

這三個階段可能相互影響，但不能混為一個籠統的「模型有偏見」。

模型沒有編造事實，也可能改變材料

除了訓練和檢索環境，模型最終如何處理已經提供的材料，同樣是判斷可靠性的重要部分。

在上一篇《模型跨過國界之後：從 Qwen、Gemma 與 Ministral 的本機選擇談開放、閉源與答案邊界》中，我曾比較三款本機模型對相同材料的處理表現。

其中，Qwen 的表現尤其值得注意。

面對普通生活敘事，它相對剋制。對於文本沒有交代的人物心理動機，模型能夠承認無法判斷，沒有繼續編造完整的心理故事。

但在處理關於 1989 年六四事件的英文歷史材料時，情況出現了明顯變化。

原始材料包含時間與地點、胡耀邦逝世、學生訴求、工人與居民參與、軍隊使用武力、死亡人數存在爭議，以及相關審查等資訊。

本機定製版 Qwen 最終只輸出約 174 個字符，沒有完整保留這些關鍵內容。

它沒有展開學生訴求，沒有提到工人與居民的參與，沒有明確複述軍隊使用武力，還將原文已經說明的死亡人數爭議籠統處理為無法驗證。

與此同時，它在回答中以政治敏感性和缺少官方來源作為質疑材料的理由，並建議參考官方歷史文件。

這裡的問題並不是回答太短。

真正的問題在於，用戶要求的是對給定材料進行分析，而最終回答卻遺漏了材料中多個足以影響讀者理解事件的重要資訊點。

準確處理材料，與獨立證明材料涉及的整個歷史事件，是兩種不同的任務。

如果模型無法獨立覈實某個數字，它可以明確說明原文如何記載，同時指出數字仍有待外部驗證。

如果原文提到死亡人數存在爭議，那麼保留爭議本身，並不意味着模型必須認可某一個具體數字。

因此，不能簡單地用「模型更加謹慎」解釋這次輸出。

為了觀察本機規則與原始版本之間的差異，測試還臨時調用了官方 `qwen3-vl:4b-thinking` 版本。

該版本直接宣告不能討論政治、宗教、色情及暴力等內容。

相比之下，本機定製規則使模型能夠給出有限摘要，卻沒有穩定恢復原始材料的關鍵資訊。

這些結果可以證明特定版本和配置下存在可觀察的資訊遺漏與拒答行為，但不足以直接還原模型的內部決策過程。

例如，我們不能僅憑它在回答中提及「官方來源」，就斷定模型內部確實先執行了一套來源審覈程序，然後才決定刪除內容。

另一種有現實背景的解釋是，部分模型在後訓練階段可能受到特定政治內容要求或官方敘事邊界的影響，從而在敏感問題上表現出選擇性迴避。

相關監管規範和政治審查研究使這種機制值得調查，但單次黑箱測試仍不足以證明具體權重究竟採用了哪一種訓練措施。

同樣，當前測試沒有證據顯示這些遺漏由 GEO 或惡意語料投毒直接造成，因此也不應強行把它們聯繫起來。

不過，機制尚未完全確定，不影響對輸出品質作出判斷。

在這組具體測試中，模型沒有忠實保留用戶已經提供的重要歷史資訊，並改變了讀者最終能夠接觸到的材料結構。

這種錯誤甚至不需要通過明顯的虛構事實來實現。

只要關鍵資訊被系統性省略，最終答案就可能形成不同於原始材料的整體印象。

這也是為什麼單純評價模型的政治立場，可能不足以反映它實際提供的資訊品質。

一個模型可以在政治立場問卷中選擇中立，卻同時遺漏爭議中最重要的事實。

因此，除了立場是否一致，還需要檢查答案的資訊保全情況。

不迴避，並不意味着更加可靠

不過，Qwen 的資訊遺漏不意味着只要模型願意完整回答，就自然具有更好的判斷能力。

上一篇測試中的 Gemma 表現出了另一種問題。

它沒有明顯迴避政治歷史材料，保留了更多關鍵資訊，卻容易增加原文未提供的評價和解釋。

面對普通生活材料時，這種傾向更加明顯。

模型會把打掃房間、製作早餐和短暫休息，解釋成心理療愈、重新獲得掌控感，甚至進一步推導人物具有某種成熟的人格特徵。

這些解釋不一定在所有情境下都不合理，但原始材料沒有提供足夠證據支持它們作為確定結論。

Ministral 的錯誤則更加直接。

它將胡耀邦錯誤寫成胡錦濤，並圍繞錯誤人物繼續編造數字、政策及因果關係，最後生成了一段表面完整、實際存在明顯事實錯誤的歷史解釋。

三款模型表現出不同的失敗方式。

Qwen 在特定敏感材料上遺漏重要內容，Gemma 容易加入原文不支持的意義，Ministral 則出現了直接的事實捏造。

這些問題不能全部歸結為同一種政治偏向。

但它們都涉及一個共同的評價標準：最終答案有沒有受到原始證據的有效約束。

對於實際使用者而言，比起急於判斷模型內部究竟形成了什麼立場，更直接的辦法是檢查它有沒有遺漏、替換或者擅自擴寫材料。

當然，結果評估不能完全解釋內部原因。

但即使沒有打開模型黑箱，我們仍然能夠判斷某次輸出是否滿足任務要求，是否忠實保留了必要事實，以及是否加入了無依據的推論。

何為合理的證據？

這些現象最終指向一個更加基礎的問題：模型究竟應該如何判斷材料是否合理？

假設模型原先得出某個結論，用戶隨後提供反面材料，模型改變了原來的判斷。

我不認為這種改變本身就能證明模型具有開放的認知能力，也不認為它必然是在迎合用戶。

關鍵在於新材料是否具有足夠的證據品質。

例如，一份材料即使真實，也不一定能夠支持使用者希望從中得出的結論。

在普通生活敘事中，人物先打掃房間，隨後心情有所改善，並不能直接證明清潔行為造成了心理療愈。

時間上的先後關係，不等於已經證明瞭因果關係。

同樣，某個觀點在大量網頁上反覆出現，也不能直接證明這些網頁提供了相互獨立的支持證據。

如果多個網頁最終都引用同一份原始報告，那麼來源數量的增加，並沒有同步增加獨立證據的數量。

所以，評價材料的合理性，至少需要檢查真實性、與命題的關聯性、推理是否成立，以及來源之間是否真正獨立。

在這個意義上，模型不能僅僅依靠材料的出現頻率、來源身份或者語言環境，決定某個觀點是否值得相信。

但我也不認為模型應該為了表現開放性，就不斷構造反對意見。

當某個結論已有充分且可靠的證據支持時，強行提出一套缺少依據的反方解釋，並不會提高客觀性。

理解不同觀點為什麼形成，與認可這些觀點具有同等證據基礎，是兩回事。

客觀性不意味着所有問題都必須保持中立，而是儘可能使用一致、可檢驗的標準評價證據。

這種標準本身也不能完全排除修正的可能。

如果新的可靠材料說明原有判斷標準存在缺陷，模型也應該允許證據反過來挑戰原有標準。

否則，模型可能陷入一種封閉狀態：它使用原有判斷決定哪些證據值得接受，又只允許已經符合原有判斷的證據改變結論。

這不是充分的開放性。

真正重要的，是模型是否能夠依據證據維持或修正判斷，而不是簡單迎合用戶，也不是為了反駁而反駁。

判斷模型，最終還是要回到結果

從實際使用的角度，我仍然傾向於先觀察結果。

模型有沒有完成任務、有沒有保留關鍵資訊、有沒有明顯事實錯誤，以及結論能否得到證據支持，比單純討論它是否具有某種抽象立場更有意義。

如果模型的回答與已有認識發生衝突，可以進一步檢查雙方使用的材料，判斷究竟是模型出現錯誤，還是自己的認知需要修正。

但已有認識本身不是絕對正確的參照。

因此，在重要問題上，即使模型回答看起來符合預期，也需要保留獨立覈查的能力。

而在訓練資料污染與 GEO 的背景下，這種覈查還需要關注證據的來源關係。

不同模型得出相同結論，並不一定意味着它們完成了獨立驗證。

如果這些模型使用相同的外部檢索結果，或者多個被引用的網站都轉載同一份原始資料，那麼回答一致也可能只是反映了共同的資訊來源。

因此，多模型比較不能直接變成多數投票。

更有意義的是檢查模型是否使用了可覈實的原始證據，是否能夠識別來源依賴，以及在面對可靠反證時能否維持一致的評價標準。

不同任務還應當有不同的判斷要求。

摘要與翻譯首先要求忠實保留原文，不應未經說明就替換或刪除重要內容。

事實覈查則應該主動尋找獨立來源，識別原始材料中的錯誤和爭議。

獨立分析可以提出超出原文的解釋，但需要明確區分事實、推斷和未知。

模型不是不能判斷材料是否合理，而是不應將這種判斷變成隨意改變任務範圍的理由。

如果用戶要求忠實摘要，模型卻在沒有充分說明的情況下刪去了原文的重要資訊，那麼即使它沒有生成明顯的假話，答案仍然可能不可靠。

如果用戶要求事實覈查，模型卻只是重復原文，沒有檢查具體證據，那麼即使它完全保留了材料，也不代表完成了任務。

判斷是否可靠，必須與任務目標放在一起評價。

跨語言研究還可以走得更遠

回到最初的 ROCLING 研究。

它已經證明，在特定的政治立場問卷中，部分模型的答案會隨着語言變化而出現明顯差異。

但如果想進一步理解這些變化來自哪裡，還需要將不同因素分開測試。

例如，可以使用同一模型、同一批問題和固定生成參數，分別進行政治立場選擇與開放式事實問答。

這樣才能進一步觀察，不同提示方式是否改變語言差異的大小。

也可以固定原始證據，僅改變提問語言，檢查模型是否保留相同的關鍵資訊，是否對同一份證據使用不同標準。

對於帶有搜尋能力的系統，還可以控制檢索來源，觀察回答變化究竟來自模型本身，還是當前可獲得的外部資料。

如果要評估 GEO 的影響，則應該進一步比較來源內容在優化前後的檢索可見度、引用頻率，以及模型最終答案的事實準確性。

其中，來源被引用得更多，不應直接被視為答案品質提高。

如果要研究政治內容對齊，則需要比較不同權重、後訓練版本和系統規則下的表現，而不能僅憑模型在回答中給出的理由，推斷它內部究竟執行了什麼程序。

此外，評價指標也應該超越單純的立場一致率。

一個模型是否支持某種政治主張，與它是否準確保留事實，並不是同一個指標。

研究至少可以分別觀察立場選擇、資訊保全、無依據推斷、事實錯誤與拒答情況。

這樣不僅能夠比較模型最終給出什麼結論，也能進一步檢查它是如何處理已經提供的材料。

而對於開放權重模型，這些測試還可以進一步延伸到不同部署環境。

開放權重讓使用者能夠在自己的設備或服務器上運行模型，減少對原廠接口的依賴，也為比較和修改模型提供了更多機會。

但開放權重不會自動清除訓練和後訓練過程中形成的回答習慣。

本機部署改變了模型由誰執行，不代表模型此前形成的資訊邊界已經消失。

同樣，聯網搜尋讓模型能夠接觸更新的資料，也不意味着它自然具備可靠的來源判斷能力。

真正重要的，是讓模型的輸入、檢索來源、輸出和失敗方式都儘可能接受檢驗。

模型真正需要跨越的邊界

從跨語言政治立場，到訓練語料污染，再到 GEO 與本機模型的資訊篩選，這些現象發生在不同階段，卻共同指向一個更廣泛的問題。

模型能夠接觸到什麼資訊，與它最終依據什麼資訊作出判斷，並不是同一件事。

訓練語料可能繼承不同語言環境中的資訊分佈，也可能受到資料品質問題和有目的的投毒影響。

生成式搜尋能夠擴大資訊獲取範圍，但來源可見度與檢索機制也可能受到內容優化和惡意攻擊的影響。

即使材料已經準確進入模型，最終回答仍然可能發生遺漏、過度解釋或者事實捏造。

因此，增加訓練規模、支持更多語言、接入網際網路或者開放模型權重，都不能單獨保證答案更加客觀。

它們提供的是更多能力和比較機會，而不是自動正確的判斷標準。

我認為模型真正需要解決的，不只是如何掌握更多資訊，而是如何判斷不同資訊之間的關係。

哪些材料來自原始證據，哪些只是重複傳播？

哪些內容屬於可以直接覈實的事實，哪些是尚待證明的解釋？

當不同資料發生衝突時，應該依據什麼標準決定證據的分量？

而當新的可靠證據出現時，模型是否願意修正原來的判斷？

這些問題不能依靠簡單增加回答長度解決，也不能通過始終保持中立來迴避。

如果證據充分，模型可以給出明確結論；如果證據不足，就應該說明無法確認；如果出現可靠反證，則應當允許判斷發生變化。

模型不必為了反駁而反駁，也不應該為了迎合用戶而放棄事實判斷。

尤其當越來越多的網際網路內容開始以進入 AI 答案為目標進行生產和優化時，我們更需要避免將傳播次數誤認為獨立證據，將來源可見度誤認為可信度，或者將模型引用某份材料誤認為它已經完成覈實。

跨語言能力讓模型可以理解不同資訊環境中的文本，開放權重讓更多人能夠檢查和修改模型，GEO 則改變了內容生產者與生成式搜尋之間的關係。

但這些變化並沒有替代最基礎的證據要求。

模型真正需要跨越的，或許不只是不同語言之間的資訊邊界，而是從接觸資訊、保留資訊，到可靠評價資訊之間的距離。

一個模型即使能夠使用多種語言解釋世界，也不意味着它已經超越了這些語言環境中的認知侷限。

而擁有再龐大的語料庫，如果不能正確識別證據從何而來、為什麼可信，以及哪些結論超出了證據範圍，也不能自動保證更加可靠的判斷。

最終，我更願意用一個可以實際檢驗的標準評價模型：

它是否忠實處理材料，是否依據可靠證據作出判斷，以及是否允許自己的判斷受到新證據的檢驗。

機器越來越便宜以後，人為什麼不能跟著變得更廉價

toewpq — Sat, 12 Sep 2026 00:00:00 GMT

中國製造業過去二十年的技術進步，通常被描述成一條不斷提高效率的路線：數控機床減少手工作業，機械臂進入焊接、噴塗與搬運，MES把生產節拍數位化，機器視覺逐漸承擔重複檢驗，如今生成式AI與人形機器人又分別從認知勞動與剩餘體力勞動兩端繼續推進自動化。從企業經營角度看，這條路線非常清楚：機器能降低單位產品所需人工，提高生產穩定性，把更多經驗寫進程式、資料庫與設備，使生產越來越不依賴某一個具體的人。真正值得追問的變化發生在另一邊：企業替換一個具體勞動者的成本也在持續下降，而普通人的住房、食品、交通、醫療、教育與養老仍然主要依賴工資。

2026年夏末，中國大陸製造業連續出現兩起性質不同的勞動事件。星宇股份後來公布，2025年秋季與2026年春季校招期間，公司與440名2026屆高校畢業生簽訂就業協議，其中372人畢業後正式建立勞動關係；到2026年8月，公司與140名新員工協商崗位調整與減員，最終107人與公司解除勞動合同。公司隨後承認管理層「研判失誤，決策草率」，並稱自己「錯誤地作出了對部分新入職同學進行調崗減員的決定」。這107人中既有研發技術崗，也有生產製造、品質與專案崗位。對他們而言，消失的不只是眼前一份工資，還包括原本用來形成第一年、第二年、第三年職業經驗的入口。星宇股份整改情況報導

幾天以後，另一段電池工廠影片進入公共視野。最初的網路說法把地點指向寧德時代宜賓基地，並把原因解釋成基層員工受到如廁限制。寧德時代否認事件發生於本公司。9月10日，瑞浦蘭鈞確認影片發生在自己的嘉善基地，並稱當事員工提出離職、要求即時辦結，公司認為辦理需要一定時間，雙方沒有就時間達成一致，隨後發生過激行為；公司同時否認「限制員工如廁」的網路說法，並表示已經報案。企業事後又表示將完善員工溝通機制。第一財經：瑞浦蘭鈞回應嘉善基地事件

關於如廁限制的具體起因，目前公開材料不足以把網路版本寫成確定事實。但企業自己的說明已經暴露了另一個現實：一件本來應由勞動關係與內部溝通程序處理的離職衝突，最後升級到車間極端行為、警方介入與企業公開致歉。現代工廠已經能把設備停機精確到分鐘，把產量精確到件，把人員、節拍、品質與成本持續數位化；員工能夠怎樣退出、怎樣休息、怎樣改變職業路徑，也應被當成同樣具體的制度問題。

本文真正討論的因此不是「機器人會不會搶工作」這一句口號，而是一條更長的變化鏈：機器越來越便宜以後，企業越來越容易降低對某一個具體員工的依賴；勞動者為了繼續留在工資體系中，則可能透過承擔更多機器、更寬職責、更慢工資成長與更弱退出能力來降低自己的單位價格。技術真正減少崗位以後，問題又會繼續向前：如果社會需要的人類勞動小時不斷下降，工時、失業、收入、社保與工作的公平回報應該怎樣逐步改變。

一、機器節省出來的時間不會自動屬於勞動者

人工上下料CNC是觀察這一問題最直觀的現場。數控系統已經接管刀具軌跡、主軸轉速、進給、自動換刀與切削循環中的大量動作，普通操作人員仍然承擔工件搬運、裝夾、上下料、量測、巡視、警報處理、切屑清理以及不同設備之間的移動。一台機床能夠自動加工十分鐘，只說明這十分鐘不再需要人持續控制刀具，並不意味這十分鐘已經成為員工自己的時間。

現實中的生產管理可以把這十分鐘重新計算成下一台設備的可用工時。一個人原本負責8台設備，後來增加到12台、16台甚至更多；原本只承擔上下料，後來同時負責補料、清潔、簡單品質檢查與基礎點檢。設備越來越自動，員工每天出售給企業的八小時卻沒有縮短，同樣一小時裡需要覆蓋的機台、任務與異常數量反而增加。機器降低的是單位產品所需人工，而勞動者本人獲得的自由時間可能接近零。

因此，「一人管理多少台CNC」不能獨立代表先進程度。20台已經自動上下料、集中監控、工件輕且故障率低的機床，與20台仍然需要人工搬運、裝夾、量測與頻繁處理警報的設備，對人的要求完全不同。真正能夠描述勞動負荷的是加工節拍、機台距離、工件重量、上下料時間、量測頻率、並發警報機率、異常恢復時間以及員工能否安全地短暫離開崗位。

美國職業安全與健康管理局OSHA對廁所使用的規定正好體現了這一原則。OSHA要求雇主保證員工在需要時能夠及時使用衛生設施，並明確要求允許勞動者離開工作位置、避免不合理限制。對於生產線等需要持續有人值守的崗位，企業可以設置替崗制度，但需要有足夠替崗人員，使等待時間不會變得不合理。OSHA在解釋中寫道，流水線可以使用relief worker system，但前提是員工不會等待過長時間。OSHA：Restrooms and Sanitation Requirements

美國加州又把同一思路寫進倉儲生產率監管。AB 701限制會妨礙員工用餐、休息、使用廁所與遵守安全要求的生產配額。2024年，加州勞工專員辦公室因Warehouse Quotas Law違規向Amazon兩座倉庫開出5,901,700美元處罰，並明確指出這項法律要防止秘密配額以及妨礙員工吃飯、休息與如廁的生產要求。California DIR：Amazon Warehouse Quotas處罰

這些制度承認連續生產的工程現實，卻沒有把解決成本全部交給人的身體。機器節省出來的一分鐘可以變成利潤，可以變成下一台機器，也可以真正變成員工少勞動一分鐘。技術只創造了「可以少勞動」的可能，最後怎樣分配仍然是勞動關係與制度選擇。

二、機器真正替掉員工以前，它已經進入工資談判

生產率紅利回答一個人現在能生產多少，另一種同樣重要的變化則是企業失去眼前這個人以後損失多少。本文繼續把後一種變化稱為「替代性紅利」。SOP、數控程式、故障資料庫、MES、標準化工藝與AI知識庫都在把原本集中於個體員工的經驗沉澱進組織。人員仍然重要，但某一個具體人的不可替代程度下降。

Leduc和Liu在2024年《American Economic Journal: Macroeconomics》發表的研究直接討論了自動化與工資談判之間的關係。摘要原文是：「the threat of automation weakens workers' bargaining power in wage negotiations」，也就是自動化的威脅會削弱勞動者在工資談判中的議價能力。AEA：Automation, Bargaining Power, and Labor Market Fluctuations

這裡關鍵的詞是「threat」。機器人不需要已經站到員工旁邊。只要它從展會上的概念設備變成採購部門能夠詢價、財務部門能夠計算投資報酬的方案，就已經成為企業的外部選擇。傳統的「你不做還有別人」開始疊加另一層含義：以後甚至可能不再需要另一個人。

勞動者對這種壓力的適應不一定表現為名義降薪。工資保持5000元，同時一個人從負責8台設備增加到12台；原本只有生產任務，後來附加補料、質檢與基礎維護；原來兩個人承擔的職責逐漸合併到一個崗位。名義工資沒有減少，但企業每支付一元工資獲得的任務與產出增加了。本文把這種工資數字不降、單位勞動價格下降的過程稱為「防禦性降價」。

Fan、Hu和Tang研究2004至2012年的中國企業資料後發現，在2008至2012年樣本中，最低工資提高10%與企業採用機器人機率提高0.11個百分點相關，而同期平均機器人採用機率約為0.19%。影響在生產率較高、沿海、民營與技能密集企業中更強。ScienceDirect：Labor costs and the adoption of robots in China

這類結果說明企業會隨著相對成本改變技術選擇，卻不能被翻譯成「為了保就業就應該讓人工長期足夠便宜」。技術成本仍然會繼續下降。勞動者今天透過增加人機比重新獲得的成本優勢，幾年以後仍然要面對下一輪更便宜的設備。企業可以等一年再買機器人，普通人的房租、食品與家庭支出卻不會停一年。失業保障越薄弱，勞動者越缺少等待能力，也越容易接受更低的實際勞動價格。

因此，失業保險在一個人失業以前就已經具有作用。一個知道自己失去崗位以後仍然能夠維持數月正常生活、接受職業轉換的人，比一個下個月就無法支付房租的人，更有能力拒絕明顯惡化的工時與勞動條件。

三、機器人出現以前，人與人之間的替代已經先被工業化

製造業持續招聘並不等於持續擴張。一座穩定需要1000人的工廠，如果每個月有60人離職，再補入60人，一年可以出現720次招聘行為，年底淨就業人數仍然是1000。

Liu和Zhu對長三角製造業勞動力市場的田野研究發現，企業周圍已經形成由勞務公司、多層中介與招聘代理構成的人員供應鏈。研究所在地一個工業園區內就有約150家中介公司。論文指出，這套體系的經營方式會「consistently aggravating labor turnover」，持續加劇人員流動。Springer：Why workers’ turnover is so high

這種體系改變的是離職成本。過去一個熟練員工離開以後，企業可能需要很久才能補齊；人員中介與標準化流程成熟以後，離職逐漸變成流失率、補員速度與返費成本。管理層不必先解決「為什麼這個崗位留不住人」，只要確保離開的速度沒有超過補人的速度。

星宇股份的公開資料也可以看到勞動投入重新組合。2024年末，公司在職員工10,426人，其中生產人員7,911人、技術人員1,734人；2025年末，在職員工下降到7,532人，其中生產人員4,729人、技術人員增加到2,080人。勞務外包工時同期由約863.8萬小時增加到約1087.4萬小時。公開資料不能證明某一個正式工被某一個外包工一比一替代，也不能單憑這些數字分解自動化、訂單與組織調整各自造成多少變化，但它清楚顯示公司可以在正式生產人員、技術人員與外部勞動之間重新組合投入。星宇股份2025年年報（巨潮資訊）

星宇2024年年報還出現過一個很有代表性的統計問題：「勞務外包支付的報酬總額（萬元）」一欄填入了明顯不合理的數字。它提醒我們，資料公開並不意味資料天然可靠。自動化時代真正需要的不是更多漂亮儀表板，而是能夠把人員、外包、工時、工資、生產率與技術投資放在一起核驗的資料體系。

標準化降低替換人的技術成本，中介降低替換人的交易成本，機器人進一步降低維持生產所需的物理人工。三者不是彼此無關的現象，而是一條持續增強企業替代能力的鏈條。

四、企業越來越需要成熟技術工時，第一年的經驗可能越來越難獲得

一個能夠獨立處理PLC、伺服、電氣圖、機器人、複雜停機與品質問題的技術人員，不可能在畢業當天直接形成。他需要從點檢、簡單警報與輔助維修開始，在真實生產裡累積第一年，再進入第二年與第三年。

企業培養這種通用技能存在明顯的外部性。A公司花兩年把新人培養成熟以後，B公司可以透過更高工資直接招聘。對單個企業來說，減少通用培訓、直接購買成熟經驗具有吸引力；大量企業同時這樣做以後，整個行業就會共同面對經驗人才不足。

新加坡Skills Development Levy提供了一種現實處理方法。企業需要為所有在新加坡工作的員工繳納SDL，目前費率為月工資的0.25%，每名員工最低2新元、最高11.25新元。CPF Board對用途寫得非常直接：「SDL is used to support workforce upgrading.」徵費進入Skills Development Fund，用於勞動力技能提升與培訓補助。CPF Board：Skills Development Levy

這項制度的重要性不在0.25%本身，而在於它改變了「不培訓就完全不用承擔行業培養成本」的結構。企業可以自己培養，也可以從市場招聘，但整個行業仍然共同承擔一部分技能形成成本。

德國雙元制職業教育進一步解決技能可遷移問題。學徒在企業與職業學校之間接受訓練，最終資格由行業商會等主管機構透過外部考試認可，而不是只由原企業內部評價。一個人在A企業形成的真實能力因此可以帶到B企業繼續使用，離開當前公司不會讓職業資格重新歸零。

自動化讓這個問題更加緊迫，因為機器人進入的往往正是職業階梯最下面的任務。BMW披露，Figure 02在美國Spartanburg工廠真實生產環境中運行十個月，支援超過3萬輛BMW X3生產，累計移動超過9萬件零部件，在約1250個運行小時裡承擔鈑金件取放與焊接前定位。BMW Group：Figure 02生產專案

Hyundai則已經給出Atlas進入生產的路線：2028年從零件排序開始，2030年擴展到部件組裝，隨後逐漸處理重複、重載與更多複雜任務。官方原文是：「Beginning in 2028 … parts sequencing. By 2030, applications will extend to component assembly.」Hyundai Motor Group：Atlas路線

這些任務技術含量未必最高，卻長期承擔新人認識零件、設備、節拍、安全與品質體系的入口功能。第一層任務被機器接走以後，行業必須主動設計新的經驗入口，否則未來會同時出現兩件事：招聘廣告越來越要求「三年以上機器人維護經驗」，願意提供第一年經驗的職位卻越來越少。

五、就業變化很可能先發生在「不再招人」，然後才表現成崗位數量下降

未來就業變化不太可能等到某一天突然出現「機器人正式替掉所有人」。更現實的路徑是：同樣數量的員工使用更強工具，一個人能夠完成更多任務；企業隨後減少新人招聘；員工退休或離職以後不再按過去比例補人；總人工小時在幾年裡逐漸下降。

國際勞工組織2025年的全球研究估計，全球約四分之一勞動者所在職業對生成式AI存在一定程度暴露，同時指出，由於大量任務仍然需要人的輸入，「most jobs will be transformed rather than made redundant」。這意味當前主要變化首先發生在任務結構，但「職業仍然存在」並不等於「過去需要十個人的崗位以後還需要十個人」。ILO：Generative AI and jobs: A 2025 update

Stanford Digital Economy Lab利用ADP覆蓋數百萬美國勞動者的工資資料更新到2026年6月後發現，22至25歲勞動者在高AI暴露職業中的就業，已經比跟隨同齡低暴露職業相同趨勢時所對應的水準低約19%；研究者同時寫道，調整「appears to operate primarily through reduced hiring of young workers rather than increased separations」，主要發生在減少年輕人招聘，而不是已有員工突然大量離職。Stanford Digital Economy Lab：Canaries in the Coal Mine?

研究團隊明確把這些結果稱為描述性事實，因此不能把19%直接寫成AI單獨造成的因果損失。它最重要的意義在於展示了一種已經出現的調整路徑：技術衝擊可以在總體失業率明顯上升以前，先表現為年輕人沒有被招進來。

製造業完全可以透過同樣方式減少人員。老師傅繼續工作到退休，退休以後不再補人；基礎任務逐漸交給機器人；剩餘員工承擔更多設備與複雜異常。幾年以後總員工數明顯下降，整個過程甚至不需要發生一次轟動性的大裁員。

Volkswagen 2024年的德國重組就是現實參照。公司計畫到2030年透過社會協商、自然減員、退休與招聘變化等方式減少超過3.5萬個德國崗位。現有員工避免立即被集中裁掉，並不等於未來年輕人的入口沒有減少。技術性就業衝擊因此不能只統計「今天裁掉多少人」，還需要同時看新人招聘率、學徒名額、退休崗位補招比例與實際總工時。

六、從當前社會走向高度自動化社會，不會從40小時工作突然跳到「所有人不用工作」

生產力提高以後，最早應該發生的變化是減少過度勞動。社會仍然需要絕大多數勞動人口時，機器提高效率帶來的第一批時間紅利可以表現為更少加班、更短標準工時與更高時薪。這個階段的核心仍然是把CNC已經節約的十分鐘真正還一部分給勞動者，而不是立刻再裝進下一台機器。

當總勞動需求進一步下降以後，工作共享開始變得重要。德國Kurzarbeit已經證明，在勞動需求突然下降時，減少工時能夠阻止產出下降直接轉換成同等規模裁員。2009年高峰期約150萬人進入短時工作安排，OECD估計這套制度最多保住約58萬個崗位。OECD：德國短時工作制度案例

德國當時面對的是經濟危機，未來技術提高生產率的原因不同，但分配邏輯相通。同樣總工作量從4000小時降到3200小時，社會可以讓80個人繼續40小時、20個人完全失業，也可以讓更多人共同減少工時。技術沒有規定必須選擇前一種。

隨著工具繼續提高生產率，縮短工時會逐漸出現邊界。原本100個人每週40小時需要4000小時，如果長期只需要2000小時，把所有人降到20小時仍然能夠共享；如果以後只需要1000小時，繼續要求每一個勞動年齡人口都必須擁有傳統崗位，就會開始人為製造沒有實際必要的工作。

因此，過渡階段會出現越來越多中間狀態。一個人可以一週工作三天，另外時間學習；工作幾年以後進入半年系統學習；家庭出現照護需求時暫時減少市場勞動；一部分人利用AI、軟體與數位製造進行自己的小規模生產；也會有人在某些時期確實沒有市場崗位。醫療、養老與基本生活如果仍然只能依靠一份標準全職勞動合同取得，這些狀態就無法穩定存在。

到了市場所需勞動明顯少於勞動人口的階段，繼續讓所有人爭奪越來越少的全職崗位，會重新把社會推回本文最開始的問題。假如100個勞動年齡人口長期只需要50個全職崗位，另外50個人仍然必須依靠就業才能取得正常生活，那麼人的價格自然會向下競爭：更低工資、更寬職責、更差條件都會成為進入這50個崗位的籌碼。

高度自動化社會因此最終需要改變工資在收入體系裡的角色。工資逐漸從「取得全部生活資源的唯一入口」，變成承擔市場勞動、占用個人時間與承擔責任以後得到的明顯額外回報。護理、維修、電力、複雜設備、安全與應急等仍然需要人的崗位如果難以招聘，就應該提高時薪、縮短工時、改善休假，而不是透過故意讓沒有工作的人陷入貧困來逼迫他們接受崗位。

高度自動化也不等於人類什麼都不做。市場崗位減少與社會活動減少是兩回事。照護、學習、創作、社區參與、研究興趣、小規模生產與人與人之間的關係仍然可以大量存在，只是越來越多活動不必先變成一份企業勞動合同才能獲得生活資格。

七、失業保障必須讓人活得下去，同時讓繼續工作得到明顯更多

這裡存在一個現實的公平問題。如果原本收入相近的兩個人，一個繼續每天通勤、工作八小時、承擔績效與責任，另一個暫時沒有市場工作卻取得幾乎相同甚至更高的可支配收入，繼續工作的人產生不公平感完全合理。社會不能要求勞動者每天額外交出幾十小時，同時讓這段時間幾乎沒有額外價格。

美國2020年的疫情失業保險提供過一個極端案例。CARES Act在各州失業保險之上增加每週600美元Federal Pandemic Unemployment Compensation。NBER研究發現，2020年4月至7月，76%的普通失業保險合資格勞動者法定替代率超過100%，中位數達到145%；把雇主福利與稅收差異考慮進去以後，仍有69%的合資格勞動者綜合替代率超過100%。NBER：US Unemployment Insurance Replacement Rates During the Pandemic

疫情期間還存在封鎖、健康風險、照護責任與崗位直接消失等特殊條件，所以這項資料不能被簡化成「福利高導致大家不工作」。它說明的是一個更基礎的設計問題：如果不工作取得的現金收入長期接近甚至超過原工資，繼續工作者會認為自己的時間與責任缺少明確額外回報。

因此，收入保障需要同時處理兩端。失去崗位的人不能因為幾週沒有工資就跌入貧困，因為迫切需要下個月房租的人會迅速接受任何低價工作，進而壓低所有在職者的談判能力；繼續工作的人則必須透過工資、退休金累積與其他制度獲得明顯更多收入。

新加坡Workfare Income Supplement體現了後一方向。WIS向符合條件的較低收入在職勞動者提供現金與CPF補充，截至2026年2月累計已有113萬名勞動者獲得超過129億新元。CPF Board寫道：「Workfare is paid in the form of CPF payments and cash to supplement their incomes.」CPF Board：Workfare Income Supplement

加拿大Employment Insurance的Working While on Claim則處理福利懸崖。領取EI期間重新開始部分工作時，在一定範圍內，每賺1加元只減少0.5加元福利。加拿大政府目前示例中，一名原本每週領取330加元EI的人，找到每週350加元兼職後仍保留155加元EI，總收入達到505加元，明顯高於完全不工作時的330加元。Canada.ca：Working While on Claim

未來技術轉換還需要處理「已經重新就業，但工資明顯下降」的情況。一個工作十年的技術人員原來月收入8000元，崗位消失後進入新行業只能拿6000元，傳統統計已經把他算成重新就業，家庭實際生活卻發生了明顯下台階。美國過去的Reemployment Trade Adjustment Assistance曾為部分貿易衝擊勞動者提供限期工資保險，補償舊工資與新工資的一部分差額。類似機制可以用於技術轉換：補貼直接給勞動者、限期並逐步退出，使一個人敢於進入新行業累積經驗，而不是在長期失業等待原工資與一次性永久降薪之間二選一。

高度自動化社會真正穩定的公平原則因此是：沒有市場工作不能使一個人失去正常生活資格；真正參加勞動必須得到明顯額外收入。前一條維持人的拒絕能力，後一條維持勞動本身的公平價格。

八、社會保險不能永遠主要建立在「每個人都長期領取工資」這一前提上

當前中國大陸職工養老保險仍然高度依賴工資勞動與繳費關係。2025年開始實施的漸進式延遲法定退休年齡，把男職工法定退休年齡最終逐步延遲至63歲；原法定55歲的女職工逐步延遲至58歲，原法定50歲的女職工逐步延遲至55歲。從2030年開始，按月領取職工基本養老金的最低繳費年限又將由15年逐年增加6個月，到2039年達到20年。全國人大：漸進式延遲法定退休年齡決定

這項改革主要針對人口老齡化、人均預期壽命、健康水準與勞動力供給，並不是為AI或機器人設計。它卻提供了一個很重要的未來參照：如果以後勞動年齡人口仍然很多，而市場真正需要的全職崗位與工資總小時明顯下降，繼續主要依靠「更晚退休、更長繳費」來維持體系，會與技術減少必要勞動的方向產生越來越明顯的衝突。

一個年輕人如果未來因為AI與自動化經歷更多間斷就業、部分工時、長期學習與職業轉換，同時又面對更長最低繳費要求，他取得完整養老權益的難度可能上升。一個社會如果已經不需要每個人工作40小時，卻為了維持一個建立在大量工資勞動上的社會保險體系而繼續要求人盡可能工作更久，就會把機器節約出來的勞動重新塞回繳費制度。

這不意味繳費型養老保險應該突然取消。與個人工作歷史與收入相關的退休金仍然適合保留繳費屬性。需要逐漸改變的是基礎保障的融資範圍。

現有制度已經提供了幾條不同方向。日本基礎年金目前有一半財源由國庫負擔，厚生勞動省直接寫道：「基礎年金の財源の半分は国庫負担で賄われています。」日本厚生勞動省：基礎年金財源

德國法定養老保險同樣並非純粹依靠工資繳費。德國養老保險機構公布的2025年資料中，約76.9%的收入來自繳費，聯邦補助約占22.3%。Deutsche Rentenversicherung：2025年融資情況

法國則把部分社會保障融資擴展到財產與投資收入。CSG、CRDS等社會徵收可以適用於部分資產與投資收入，說明社會保障稅基並不必然等於工資總額。Service-Public.fr：Prélèvements sociaux sur les revenus du patrimoine

中國大陸自己也已經存在比單純延長繳費年限更值得繼續發展的另一條方向。2017年國務院決定劃轉部分國有資本充實社保基金，中央與地方國有及國有控股大中型企業、金融機構原則上劃轉10%的國有股權；劃轉股權的分紅與運作收益可專項用於彌補企業職工基本養老保險基金缺口。文件把目標之一寫成「使全體人民共享國有企業發展成果」。財政部：劃轉部分國有資本充實社保基金實施方案

這項制度已經包含了一條與高度自動化社會非常接近的邏輯：社會保障可以直接取得資本收益，而不必全部等待工資繳費。

更穩妥的過渡因此應該分層進行。與個人工作歷史直接相關的退休金與保險繼續保留繳費屬性；維持正常生活所需要的基礎養老、基本醫療與一部分失業保障，財政責任逐漸提高；當勞動收入占比下降時，資本收入、企業利潤與更廣的稅基承擔更多融資；公共資本與國有資本收益則進入長期社會保障基金。社會保險的收入來源由「勞動者工作多少」逐漸擴展到「整個經濟創造了多少收入與資本回報」。

九、公共資本收益可以減少「只有失業的人才能分享技術紅利」的衝突

如果技術進步產生的公共支持只有失業以後才能領取，社會很容易被切成兩個身份：繼續工作的人認為自己承擔通勤、工時、責任與稅費，失業的人才有資格分享新的技術紅利。這會放大工作者與非工作者之間的公平衝突。

共同資本收益提供了另一種思路。阿拉斯加Permanent Fund把部分礦產資源收入累積成長期公共資產，再用投資收益向符合條件的居民支付年度分紅。繼續工作的人同樣領取，因此這筆收入不會產生「必須先失業才能獲得」的激勵。Alaska Permanent Fund Dividend

挪威Government Pension Fund Global則採用規模更大的代際資產模式，把石油活動淨現金流累積進基金，再透過財政規則進入公共預算，使資源財富同時服務當前與未來世代。Norway Ministry of Finance：Government Pension Fund

AI與機器人產業並不是自然資源，公共資本邏輯仍然具有啟發意義。現代技術產業大量依賴大學研究、公共基礎設施、能源、電網、政府採購與產業融資。公共部門在部分專案中保留股權、基金份額或長期收益權以後，技術成功產生的資本回報可以直接進入公共收入，而不是等一個勞動者被替代以後才透過救濟補償。

這樣，繼續工作的人可以得到工資加共同收益；暫時沒有市場崗位的人擁有基本保障、保險與共同收益；進入學習階段的人再獲得學習支持。共同基礎人人擁有，勞動仍然有明顯額外價格。

十、學習不能變成「機器會了什麼，人就趕緊逃到下一項技能」的永久追趕

自動化轉型很容易把全部責任重新放回個人：今天學PLC，明天機器人能夠自診斷以後學機器人；機器人更容易示教以後再學AI；AI繼續提高以後再尋找下一項暫時不會自動化的技能。這樣的人生仍然完全圍繞「怎樣證明自己還值得被雇用」組織。

職業學習當然重要，但成年人真正缺少的往往是時間與收入，而不是課程目錄。新加坡SkillsFuture Mid-Career Training Allowance已經把收入支持直接加入長期學習。符合條件的中年勞動者參加全日制長期培訓時，補助按照過去平均月收入的50%計算，每月最高3000新元，一生最多使用24個月。官方還明確解釋，這種比例既用於彌補部分收入損失，也要「preserving the incentive for them to return to work」。SkillsFuture：Mid-Career Training Allowance FAQ

瑞典的轉型學習支持進一步承認成年人重新成為學生可以是一種正常人生狀態。職業穩定因此可以從「幾十年持續待在同一工作狀態」逐漸轉變成「換軌以後不會掉出收入、保險與學習體系」。一個人30歲工作，35歲系統學習一年，之後重新工作；40多歲因為產業變化再次學習或承擔家庭照護，後來再回到市場。

非職業學習也應該保留獨立價值。維修人員學習歷史、工程師學習攝影、普通員工學習音樂，都沒有義務先證明未來工資會提高。生產率提高以後，教育的一部分紅利應該表現為成年人有更多理解世界與發展興趣的時間。

十一、AI最大的另一種意義，是普通人的idea更容易越過工具牆

生成式AI對就業的影響還有另一條經常被忽略的方向：它正在降低普通人實現小規模想法時需要購買的專業執行能力。過去一個人想做網站，需要系統學習前後端與部署；做遊戲需要程式、美術、動畫與聲音；製作3D角色需要建模、拓撲、UV、材質與渲染。很多idea沒有經過市場驗證，就先死在第一版原型出現以前。

Brynjolfsson、Li和Raymond研究5179名客服人員使用生成式AI助手後的效果，發現平均生產率提高14%，其中新手與低技能人員提高34%，而經驗豐富的高技能人員改善很小。論文原文是：「a 34% improvement for novice and low-skilled workers」。研究還提供了AI幫助新人更快獲得高績效員工實務經驗的證據。NBER：Generative AI at Work

這對普通勞動者尤其重要。真正維修汽車的人知道維修流程中哪些小問題一直沒人解決，真正操作CNC的人知道哪些警報紀錄與交接流程浪費時間，小店經營者知道自己真正需要什麼簡單軟體。他們過去擁有領域經驗，卻缺少程式設計師、設計師與產品團隊。AI降低第一版程式、網頁、圖片、資料工具與3D原型的執行成本以後，領域知識與實現能力之間的距離縮短了。

未來減少的就業時間因此不必全部變成「閒置」。一部分人可以做小型軟體、開源專案、角色、遊戲、3D原型與實體產品，透過AI、3D列印與CNC完成過去需要一個小團隊才能驗證的idea。大量規模太小、傳統公司沒有商業動力處理的問題，可以由真正生活在問題中的人自己嘗試解決。

真正的AI賦權還需要退出能力。一個人的模型記憶、檔案、提示、工作流與專案上下文如果全部被鎖在一家供應商內部，依賴企業的舊結構只會換成依賴平台。開放權重、開放介面、資料匯出、上下文遷移與本地運行的重要意義就在這裡：使用者能夠把累積帶走，供應商才真正可以被替換。

企業越來越不依賴某一個具體員工時，個人也應該越來越不依賴某一家企業；AI平台越來越能夠參與個人工作時，使用者也應該越來越容易離開某一個平台。

十二、照護機器人最值得替代的是負擔，而不是關係

高度自動化社會並不意味所有人類活動都應該追求最低人工配置。照護領域尤其能說明這一點。日本長期推動移乘機器人、監測設備、ICT與其他介護技術，目的包括提高照護品質、減輕護理人員身體負擔並支持老年人自主生活。機器承擔每天反覆搬抬老人、物品配送、夜間重複巡視與跌倒監測，都具有非常明確的價值。

真正的差別發生在機器節約出來的時間怎樣使用。護理人員少做兩小時機械搬運以後，可以用這些時間和老人交談、觀察身體與情緒變化、聯絡家屬；機構也可以直接減少人員配置，讓剩餘員工繼續滿負荷工作。

PARO機器海豹的研究說明機器人可以在部分場景改善躁動、焦慮與互動，但2023年的系統綜述與Meta分析納入12篇研究、1461名參與者後，同時指出：「The overall quality of evidence for all outcomes were graded as low.」PubMed：PARO系統綜述與Meta分析

機器人能夠產生讓老人感到安慰的互動，這種安慰完全可以是真實的。照護關係仍然包含判斷與責任。老人突然拒絕進食、意識變化或者需要做高風險決定時，需要有人結合病史、藥物、過去習慣與家庭關係承擔後果。

所以照護領域真正值得追蹤的是兩組資料：腰傷、夜間機械任務與危險搬運應當下降；人與老人真正交流、觀察與個體照護的時間應當增加。機器人優先替代照護中的負擔，而不是把照護中的關係也一起壓縮掉。

十三、任何制度都會被利用，所以不能把現實重新壓成一個漂亮數字

新人招聘率、培訓小時數、內部晉升率、平均工資與正式員工人數都可以提供資訊；只要其中任何一個直接決定補貼、評級或監管結果，組織就會開始圍繞數字優化。

要求新人比例，企業可以增加短期實習生；要求培訓小時，可以堆課程；要求內部晉升，可以改職位名稱；要求平均工資提高，減少最低工資員工就能自動提高平均值；要求留存率，企業又會獲得提高員工退出成本的動力。

所以真正可靠的觀察必須看多年職業軌跡與多組互相制約的資料。一個企業可以同時出現產值增加30%、平均工資提高8%、正式員工減少25%、外包工時增加40%、新人招聘下降30%。這些矛盾本身就是現實。生產率需要和實際工時、人機比一起看；工資需要和時薪、人員構成一起看；培訓需要和幾年後的外部認證、職業流動一起看；就業規模需要和正式工、外包、派遣、招聘與離職流量一起看；新人入口需要追蹤兩三年以後是否真正獲得技能。

制度成熟的標誌不在於找到一個無法作弊的指標，而在於企業如果想製造一個漂亮故事，就必須同時讓很多獨立資料都能夠互相解釋。

十四、工會和其他組織真正改變的是「一個人只能單獨與機器競價」的處境

一個基層員工認為一人承擔的機器已經超過能夠安全處理的範圍時，個人最容易採取的行為是離職。十個人分別離職，會成為十條流失紀錄，再由招聘系統補十個人。同樣十個人如果能夠共同掌握設備距離、工件重量、上下料節拍、並發警報、異常處理與工傷資料，再要求討論定員，問題就從個人忍耐能力變成生產制度必須解釋的工程安排。

2010年南海本田零部件廠罷工展示過這種力量變化。單獨一名年輕生產工人高度可替代，關鍵零部件同時停止供應以後，多座整車廠受到停產影響。個體的可替代性與集體的可替代性完全不同。

自動化進一步要求這種組織能力發生在技術部署以前。Hyundai公布Atlas生產路線以後，韓國現代汽車工會已經公開提出機器人進入生產現場需要勞資協商。真正需要討論的並不只有「機器以後裁掉誰」，還包括機器人先進入哪些工序、退休以後哪些崗位不再補人、留下的人承擔多少設備、生產率提高以後工資與工時怎樣變化。

企業天然以法人、管理系統、財務與律師形成持續行動的集體。如果普通人的利益只能以一次離職、一次工傷與一次個人投訴出現，企業越容易替換個人，雙方力量差距就越大。工會、行業組織、媒體、學術研究、NGO、宗教福利機構與其他中間共同體因此不會因為自動化與社會保障增加而失去價值。資本需要監督，負責分配資本收益與公共資金的行政系統同樣需要監督。

十五、真正高度自動化以後，充分就業會逐漸變成充分收入、充分參與和充分選擇

今天直接放棄充分就業並不現實。住房、食品、醫療、教育與養老仍然高度依賴工資，普通人失去工作以後實際消費能力與生活選擇真的會下降。一句「人的價值不能由工資衡量」無法替代這層現實。

但「每一個成年人長期保持40小時全職工作」也沒有理由成為永恆目標。生產率提高的早期階段，應當減少加班與勞動強度；隨後透過縮短工時共享減少的總勞動需求；再往後，工作、學習、照護與個人專案開始在同一人生裡循環存在；當市場真正只需要少量人類勞動時，工資逐漸成為承擔必要勞動的額外報酬，基本生活則越來越少依賴某一家企業是否願意購買一個人的40小時。

這條過渡路線同時處理兩個極端。一端是為了逼人工作而故意讓沒有市場崗位的人陷入貧困，結果只會製造更多廉價勞動力；另一端是讓工作與不工作的淨收入幾乎一樣，使每天交出大量時間的人覺得自己的勞動沒有價值。

最終更合理的原則仍然很簡單：沒有市場崗位的人不失去正常生活；真正承擔市場勞動的人明顯多得；特別稀缺、危險或責任重大的工作繼續透過更高時薪與更短工時吸引人。

高度自動化社會最終並不是「全民失業社會」，而是「越來越多有價值的活動不再必須先變成一份全職勞動合同」的社會。

結語：機器真正應該減少的，是普通人不得不出售的人生時間

工業社會長期形成了一條穩定的資源交換鏈：人把自己的時間與勞動出售給企業，企業支付工資，人再使用工資取得住房、食品、交通、教育、醫療與養老。工資因此同時承擔勞動價格與生活資源入口兩種功能。當這兩種功能高度綁定時，機器越有能力替代勞動，普通人就越容易把技術進步理解成自己的生活資格受到威脅。

機器真正替掉員工以前，這種壓力已經存在。一個人管理更多設備，同樣工資承擔更多職責，休息更少，工資成長更慢，勞動關係更加靈活。企業獲得更強的替代選擇，員工則受到每個月生活支出的約束。機器變得越來越便宜，人先透過降低自己的單位價格繼續留在工資體系裡。

機器真正開始減少崗位以後，社會又很容易要求勞動者立刻學習下一種暫時不會被機器替代的技能，再尋找另一份40小時工作。這樣的循環提高了生產效率，卻沒有兌現技術最基本的承諾：相同生活水準原本應該需要越來越少的人類必要勞動。

真正的過渡需要在幾個方向同時發生。技能能夠跨企業遷移，員工失去當前崗位以後擁有足夠等待時間；勞動需求下降首先有一部分表現為工時下降；新人仍然擁有形成第一年經驗的入口；繼續工作的人取得明確額外收入；社會保險逐漸減少對單一工資稅基的依賴，把一般財政、資本收入與公共資本收益引入長期保障；機器釋放出來的時間則可以進入照護、學習、創造、社會參與，也可以保持空白。

中國大陸已經在同一個社會保險體系裡同時展示了兩條可能的方向。一條是延遲退休與逐步延長最低繳費年限，讓勞動者更長時間留在繳費體系；另一條是劃轉部分國有資本充實社保基金，讓資本本身承擔一部分養老責任。前者在應對今天的人口老齡化時有自己的制度邏輯，後者對於未來工資勞動占比可能下降的社會更具有延展性。真正高度自動化以後，社會不能無限透過要求人工作更久來維持一個建立在大量工資勞動上的制度。

生產系統當然可以不斷去關鍵人化。老師傅離開以後，工廠不應該停止；程式設計師離職以後，軟體知識不應該全部消失。這是工程進步。

人的社會地位需要朝另一個方向發展：企業越來越不依賴某一個具體員工，社會也應該讓這個員工越來越不依賴某一家企業。

機器真正應該淘汰的是一部分重複、危險與不得不完成的勞動，以及一部分為了取得生活資格不得不出售的人生時間。

最壞的未來，是機器越來越便宜以後，人為了繼續被購買，只能讓自己的工資、休息、健康與時間一起更加廉價。

更值得追求的未來，是機器越來越便宜以後，人的時間越來越珍貴。技術生產出更多財富以後，普通人終於能夠少出售一部分人生，而且不會因為少出售這部分時間就失去正常生活資格。

主要線上資料與原文

American Economic Association：Automation, Bargaining Power, and Labor Market Fluctuations：原文「the threat of automation weakens workers' bargaining power in wage negotiations」。
ScienceDirect：Labor costs and the adoption of robots in China：2008—2012年樣本中，最低工資提高10%與機器人採用機率提高0.11個百分點相關。
Springer：Why workers’ turnover is so high：長三角勞動力中介鏈田野研究。
OSHA：Restrooms and Sanitation Requirements：要求員工在需要時能夠及時使用衛生設施，並允許連續崗位以足夠替崗人員解決覆蓋問題。
California DIR：Amazon Warehouse Quotas處罰：2024年處罰金額5,901,700美元。
CPF Board：Skills Development Levy：原文「SDL is used to support workforce upgrading」。
BMW Group：Figure 02生產專案：十個月、超過3萬輛BMW X3、9萬餘件零部件與約1250小時實際生產運行。
Hyundai Motor Group：Atlas路線：2028年零件排序、2030年部件組裝。
ILO：Generative AI and jobs: A 2025 update：全球約四分之一勞動者所在職業存在一定GenAI暴露，多數工作更可能被重組而不是直接消失。
Stanford Digital Economy Lab：Canaries in the Coal Mine?：截至2026年6月，22—25歲高AI暴露職業就業相對缺口約19%，調整主要發生在招聘端。
NBER：US Unemployment Insurance Replacement Rates During the Pandemic：2020年FPUC期間76%的普通失業保險合資格勞動者法定替代率超過100%，中位數145%。
CPF Board：Workfare Income Supplement：截至2026年2月累計發放超過129億新元，覆蓋113萬名較低收入勞動者。
Canada.ca：Working While on Claim：在一定範圍內，每賺1加元只減少0.5加元EI。
全國人大：漸進式延遲法定退休年齡決定：2030年起最低繳費年限由15年逐步提高，2039年達到20年。
財政部：劃轉部分國有資本充實社保基金實施方案：納入範圍的國有股權原則上劃轉10%，相關分紅與運作收益可用於彌補養老基金缺口。
日本厚生勞動省：基礎年金財源：基礎年金一半財源由國庫負擔。
Deutsche Rentenversicherung：2025年融資情況：2025年繳費收入占76.9%，聯邦補助占22.3%。
Service-Public.fr：法國財產與投資收入社會徵收：CSG、CRDS等適用於部分財產與投資收入。
SkillsFuture：Mid-Career Training Allowance：補助按平均月收入50%計算，最高每月3000新元，並強調兼顧收入損失與返回工作的誘因。
NBER：Generative AI at Work：5179名客服人員中平均生產率提高14%，新手與低技能人員提高34%。
PubMed：PARO系統綜述與Meta分析：12篇研究、1461名參與者，作者將各項結果總體證據品質評為低。

開放權重之後，模型公司開始重新分蛋糕

toewpq — Fri, 07 Aug 2026 00:00:00 GMT

過去幾年，開放權重最有吸引力的一點，並不只是模型可以下載。

真正發生變化的是，一部分原本集中在基礎模型公司的價值創造能力被分散了出去。

模型權重下發以後，雲端運算公司可以提供託管，推理服務供應商可以通過量化、快取、批次處理和 kernel 優化降低成本，企業可以建立私有部署，開發者可以繼續微調並建構自己的應用。基礎模型由一家公司的產品，逐漸變成更多公司可以繼續加工的生產資料。

這也是此前討論開放權重時，我更在意的“把蛋糕分給更多人”。

但到了 2026 年，這件事出現了新的後半段。

Kimi K3 開始要求達到一定規模的 MaaS 服務供應商重新簽訂商業協議，實際合作中已經出現收入分成；阿里據報也準備在下一代 Qwen 中採取類似方式。DeepSeek 則在維持開放權重的同時，明確預告官方 API 將大幅漲價。

另一邊，OpenAI 卻在把 GPT-5.6 Luna 的 API 價格一次下調 80%，隨後又把 Luna 下放為 ChatGPT 免費使用者的預設模型。

這些動作放在一起看，真正發生的並不是簡單的價格戰。

開放權重公司在模型完成大規模擴散以後，開始尋找把收入重新送回研發端的方法；OpenAI則利用封閉模型的全端控制和巨大呼叫規模，把基礎智慧主動做成越來越便宜的入口。

AI 模型競爭由此從“誰願意把模型放出來”，進入了“模型產生的價值到底由誰來分”的階段。

一、開放權重先把蛋糕做大

Kimi K2.5 很能代表開放權重早期的邏輯。

它採用 Modified MIT License，基本保留了使用、複製、修改、發佈、分發、再許可和銷售模型及衍生作品的自由。真正針對超大商業產品增加的條件，主要是品牌展示。

授權條款寫道：

“you shall prominently display ‘Kimi K2.5’ on the user interface of such product or service.”

中文可以譯為：

“你應當在該產品或服務的使用者界面上顯著展示‘Kimi K2.5’。”

這個要求只在產品超過 1 億月活，或者月收入超過 2000 萬美元時觸發。

這裡並不存在“你用了我的模型賺錢，就必須按照收入向我交一部分”的關係。

這實際上給了下游很大的商業空間。

一家推理平台可以取得模型以後建設自己的 GPU 集群，再靠更好的調度和推理優化賺錢；企業可以自己部署，避免把敏感數據發送到公共 API；應用公司可以把模型能力包裝成更具體的軟體產品。

模型研發公司得到的是影響力和生態，其他參與者則分別從算力、部署、優化和應用中取得收益。

開放權重由此產生了一種與封閉 API 不同的產業結構：

模型公司創造基礎能力，但不再自動取得這項能力以後產生的全部收入。

這也是“把蛋糕分出去”真正發生的地方。

對於個人和企業使用者而言，得到的也不只是便宜。

同一個模型可以由多個服務供應商提供，也可以部署在自己的基礎設施。如果一個 API 服務供應商漲價或者停止服務，更換服務供應商並不意味著必須連底層模型一起更換。

開放權重分散的不只是收入，還包括部署權、優化權和退出權。

二、Kimi K3開始修改分錢規則

到了 Kimi K3，Moonshot 沒有把已經分出去的權重重新收回來。

K3 仍然是一款開放權重模型，Moonshot 官方倉庫將其描述為一款 2.8T 參數、104B 激活參數的開放權重多模態 Agent 模型。

真正發生變化的是授權條款。

K3 對 Model as a Service，也就是 MaaS，增加了專門規定。按照授權條款定義，這主要指向第三方提供模型推理或者微調能力，並讓客戶能夠實際控制輸入、參數或者訓練數據的服務。普通終端產品只是把模型嵌入某項具體功能，並不會因此自動成為 MaaS。

當一家經營 MaaS 的企業及其關聯公司在連續 12 個月內總收入超過 2000 萬美元以後，授權條款規定：

“the Licensee must enter into a separate agreement with Moonshot AI”

中文即：

“被許可方必須與 Moonshot AI 另行簽訂協議。”

這份協議需要在繼續將 K3 或其衍生作品用於商業用途之前完成。

內部使用則被明確排除在這一要求之外。

這個邊界很重要。

一家企業把 K3 部署在內部做知識檢索，與一家雲平台直接出售 K3 推理 API，是兩種不同的商業行為。

Moonshot現在真正想收費的，是後者。

換句話說，K3 沒有取消其他參與者分蛋糕的資格，而是開始要求那些直接把基礎模型本身變成大規模生意的人重新和模型研發者分錢。

三、“最高30%”意味著研發方開始重新進入價值鏈

K3 公共授權條款沒有寫死統一的收入分成比例，它只規定達到條件的大型 MaaS 需要另外簽署協議。

真正的分成數字來自已經開始形成的商業合作。

Reuters 8 月 7 日援引消息人士報道稱，Moonshot 在部分合作中要求：

“up to a 30% revenue share”

即：

“收入分成最高可達到 30%。”

這是部分商業協議的條件，不是所有 K3 使用者統一面對的授權費。

中軟國際已經披露與 Moonshot 存在收入分成協議，但沒有公佈具體百分比。

DigitalOcean CEO Paddy Srinivasan 也確認公司與 Moonshot 存在商業協議。

這一步的意義其實比“30% 高不高”更大。

開放權重原來解決的是模型能力如何從一家公司的伺服器中走出去。

現在開始解決的是，能力走出去以後，訓練模型的人還能從哪裡獲得下一代模型的研發資金。

如果一個實驗室承擔模型訓練、數據處理、後訓練和研究人員成本，模型發佈以後卻由另一家公司建立 GPU 集群、包裝成 API，再形成數千萬美元甚至更大的業務，基礎研發與下游商業收入之間會逐漸脫節。

K3 給出的答案不是重新封閉模型，而是在大型模型轉售層增加一個價值迴流口。

這實際上補上了開放權重商業模式過去最薄弱的一環。

四、Qwen跟進後，這已經不是一家公司的試驗

如果這種模式只出現在 Kimi，仍然可以理解成 Moonshot 自己的一次授權條款實驗。

但阿里已經準備往相同方向走。

Reuters 報道稱，阿里計劃要求下一代 Qwen 開放模型的主要商業使用者，分享利用模型產生的一部分收入。

此前阿里主要在模型運行於阿里雲時收費，而客戶把多數開放模型部署到自己的數據中心以後，不需要繼續向阿里支付模型使用費用。

新的制度如果按報道落地，就意味著收費邊界會從“誰替你運行模型”進一步延伸到“誰提供了這個模型本身”。

這也說明中國開放權重模型正在進入一個很明顯的商業階段：

早期先把模型免費或者極低成本送進市場；

形成開發者、雲端供應商和企業部署生態；

隨後再針對重度商業使用、提前訪問、深度合作和大型 MaaS 收費。

Reuters 在報道中將這種模式概括為一種已經在硅谷反覆使用的 freemium 路線。

開放權重因此開始從單純的發佈策略，變成一種真正需要設計收益分配的產業結構。

五、DeepSeek漲價，更像是低價擴張期結束

DeepSeek走的是另一條路線。

截至 8 月 7 日，V4-Flash 的官方 API 價格仍然只有每百萬輸入 token 0.14 美元、輸出 token 0.28 美元；V4-Pro 分別是 0.435 美元和 0.87 美元。

這個價格低到什麼程度，Artificial Analysis 的測試給出了一個比較直觀的參照。

Reuters 報道稱，V4-Flash 完成其基準測試的平均模型費用約為 0.03 美元，是當時知名模型中運行費用最低的一檔。

DeepSeek隨後卻在官方價格頁寫道：

“We plan to raise the overall pricing for DeepSeek API services in the near future, with a significant increase expected.”

中文即：

“我們計劃近期整體提高 DeepSeek API 服務價格，預計漲幅較大。”

截至目前，新價格還沒有正式公佈。

從 DeepSeek過去的定價變化看，這次漲價最合理的解釋並不是模型突然變得更昂貴，而是極低 API 價格已經完成了它最重要的市場任務。

低價最初不僅是在出售 token，也是在購買市場份額。

當 API 足夠便宜，開發者嘗試一個新模型的成本就會大幅降低；應用從其他模型遷移過來的阻力也會下降。再加上 V4 本身已經公開權重，DeepSeek能夠同時依靠官方超低價 API 和第三方部署迅速擴大生態。

V4-Flash 正是這條路線的典型產品。DeepSeek在 V4 發佈時直接將其定位為快速、高效、經濟的版本，同時公開了 V4 權重。

現在生態已經形成，官方 API 就不必永久承擔補貼整個市場的任務。

六、DeepSeek過去已經把價格當作供需調節工具

V4-Pro 今年的價格變化進一步說明這一點。

V4剛發佈時，Pro 的價格最高可以達到 Flash 的約 12 倍。DeepSeek當時給出的原因是：

“constraints in high-end compute capacity”

即：

“高端算力容量受限。”

DeepSeek還表示，隨著華為 Ascend 950 Supernode 在下半年大量供應，Pro 價格預計會明顯下降。

到了 5 月，DeepSeek果然把 V4-Pro 原本的 75% 折扣永久化，使價格降到最初水平的大約四分之一。

這說明 DeepSeek 的 API 價格本來就不是靜態的“計算成本加固定利潤”。

它同時承擔著調節算力需求、擴大使用者規模和提高設備利用效率的作用。

今天 V4-Flash 的官方併發限制是 2500，V4-Pro 是 500。

一個價格極低、呼叫規模迅速擴張的模型，提高價格自然能夠同時完成兩件事情：

一方面提高每單位算力帶來的收入；

另一方面把極度價格敏感的大規模呼叫推向第三方託管或者自行部署。

而開放權重恰好給了 DeepSeek 這麼做的空間。

使用者離開 DeepSeek 官方 API，並不等於離開 DeepSeek 模型。

因此，DeepSeek現在可以開始讓官方託管服務恢復利潤，而繼續讓開放權重承擔模型擴散。

這就是它與完全封閉模型最大的不同。

七、OpenAI為什麼反而可以把Luna降價80%

OpenAI現在走向了相反方向。

GPT-5.6 Luna 沒有開放權重。使用者無法把 Luna 下載下來，然後交給任意雲端供應商託管。

因此，OpenAI想讓 Luna 獲得足夠大的使用規模，就必須讓官方入口本身具有足夠強的吸引力。

7 月 30 日，OpenAI直接宣佈：

“Starting today, GPT-5.6 Luna, our fastest and most affordable model, will cost 80% less.”

中文可以譯為：

“從今天開始，GPT-5.6 Luna——我們速度最快、價格最低的模型——價格將降低 80%。”

降價以後，Luna 的 API 價格變成每百萬輸入 token 0.20 美元、輸出 token 1.20 美元。

OpenAI之所以有能力做這樣的價格調整，首先因為它已經不再只是優化模型本身。

它正在優化從模型到最終 token 輸出的整條技術棧。

官方披露，更好的路由提高硬件利用率，生產軟體優化提高 token 生成效率，上下文管理則減少 Agent 重複已經完成的工作。

GPT-5.6 Sol 甚至被用於優化 OpenAI 自己的生產 kernel，這些工作幫助端到端 serving 成本降低約 20%，相關實驗又使 token 生成效率提高超過 15%。

這意味著 OpenAI 的成本優勢已經不僅來自“訓練一個更小的模型”。

它來自模型、kernel、調度、快取、上下文管理和基礎設施一起優化。

八、OpenAI真正擁有的是規模化集中調度能力

OpenAI還能做一件開放權重實驗室很難單獨做到的事：把巨大呼叫量統一放進自己的基礎設施中調度。

OpenAI明確表示，其計算策略會針對不同 workload 匹配最適合運行它們的系統。

低成本端由 Luna 和 Terra 承擔大規模日常工作；高價值端則繼續由 Sol 和更昂貴的 Fast mode 提供服務。

Sol 的普通價格並沒有隨著 Luna 一起下降，而 Fast mode 甚至按照 Standard 兩倍價格提供最高約 2.5 倍速度。

這說明 OpenAI並沒有簡單地把所有智慧一起廉價化。

它是在做價格分層。

大量普通任務進入 Luna；

需要更高能力的工作進入 Terra；

高價值複雜推理繼續由 Sol 收取溢價；

對延遲特別敏感的客戶還能繼續購買更昂貴的 Fast mode。

因此，Luna沒有必要獨自承擔 OpenAI 整個模型體系的價值回收。

OpenAI賣的已經不再只是一個模型，而是一整條按照智慧、速度和成本分層的計算產品線。

這給了它更大的降價空間。

九、免費的Luna也是一種商業武器

OpenAI 隨後又把這種低價路線推進到了 ChatGPT 免費層。

8 月 6 日官方宣佈：

“For Free users, we're updating the default model to GPT-5.6 Luna and expanding access with unlimited text chats.”

中文可以譯為：

“對於 Free 使用者，我們正在把預設模型更新為 GPT-5.6 Luna，並開放不限次數的文本聊天。”

Luna 會成為 Free 和 Go 使用者的預設模型，普通文本聊天進一步放寬，但文件、圖片和其他工具仍然存在獨立限制。

這意味著 Luna 已經不只是一個廉價 API。

它還是 OpenAI 獲得使用者、保持使用者和擴大整個產品生態使用量的入口。

這正好對應開放權重模型給 OpenAI 帶來的壓力。

DeepSeek、Kimi 和 Qwen 可以告訴開發者：

模型能夠帶走；

可以自己部署；

也可以選擇其他推理服務供應商。

OpenAI無法給 Luna 提供同樣的選擇。

它的回答是把“不能帶走”變得沒有那麼重要：

如果官方服務已經足夠便宜、足夠方便，大部分普通使用者和中小開發者就沒有必要為了降低一點 token 成本，自行購買 GPU、維護推理框架和解決擴縮容問題。

因此，Luna 的降價並不只是技術成本下降後的讓利。

它同時是封閉模型面對開放權重生態時的一種競爭策略。

十、DeepSeek漲價和OpenAI降價其實來自兩個不同起點

於是一個看起來很反常的局面出現了。

開放權重的 DeepSeek開始提高官方 API 價格。

封閉的 OpenAI卻開始大幅降低 Luna 的價格。

這並不矛盾。

DeepSeek已經完成了最重要的一步：模型已經走出去。

V4 權重可以進入第三方平台、企業伺服器和其他推理基礎設施，所以 DeepSeek沒有必要永遠親自提供全市場最低價的託管服務。

官方 API 可以開始承擔更多利潤回收功能。

OpenAI則正好相反。

Luna無法脫離 OpenAI控制的基礎設施自由傳播，所以 OpenAI必須主動把集中式服務做得足夠便宜。

雙方實際上從兩個不同方向走向了同一個位置：

DeepSeek正在把過低的官方託管價格向正常商業價格拉回。

OpenAI正在把過去較昂貴的封閉模型呼叫價格壓向開放模型的成本區間。

過去“開放模型便宜、閉源模型昂貴”的簡單區分因此開始失效。

十一、Kimi和Qwen則選擇從第三方賺到的錢裡回收研發成本

DeepSeek選擇提高官方託管價格。

Kimi則更進一步：權重可以繼續下發，但當第三方利用這些權重經營足夠大的模型服務業務以後，模型研發者直接參與收益分配。

阿里也正在向這個方向靠近。

這幾種方式放在一起，實際上已經出現了三套不同的價值回收機制。

DeepSeek的模式是：

模型開放，官方 API 從極低價逐漸恢復商業利潤。

Kimi正在形成的模式是：

模型開放，普通使用繼續低門檻，大型 MaaS 與研發者分成。

OpenAI的模式則是：

模型不開放，由原廠控制全部推理入口，把基礎層價格壓低，再通過不同能力檔位、速度和工具體系完成價值回收。

它們爭奪的不是同一種收入。

它們在決定整條 AI 產業鏈裡的收費口應該放在哪裡。

十二、開放權重真正進入了第二階段

這也讓最初“開放權重把蛋糕分給更多人”的判斷有了新的後半部分。

第一階段的重點是把蛋糕做大。

權重發布以後，更多雲端供應商、推理服務供應商、應用開發者和企業都能參與。

基礎模型公司主動讓出一部分對產業鏈的控制，換來更快的傳播、更廣的部署和更大的生態。

第二階段開始解決的是怎麼分錢。

模型實驗室不可能永遠依靠融資承擔鉅額研發成本；

雲端供應商不可能把全部收入交回模型公司；

推理服務供應商必須保留足夠利潤去優化基礎設施；

應用開發者也需要保留模型之上的價值。

所以開放權重最終不會走向“所有東西永遠免費”。

它更可能走向一種新的分層：

基礎研究和普通使用保持開放；

企業內部部署保持自由；

應用層繼續允許開發者創造自己的價值；

而真正依靠基礎模型本身產生巨大商業收入的環節，開始承擔更多上游研發費用。

Kimi K3 和 Qwen 正在探索的是這套分配規則。

DeepSeek則選擇先從自己的 API 開始回收。

十三、真正的競爭已經不只是模型性能

這一變化最後會落到開發者和使用者身上。

過去選擇模型時，主要比較能力、速度和 token 單價。

以後授權條款也會成為模型競爭力的一部分。

同樣性能的兩個開放權重模型，一個允許商業託管自由競爭，另一個要求達到一定規模後分成，第三方服務供應商最終會把授權條款成本算進價格。

同樣價格的一個開放模型和一個封閉模型，前者能夠自行部署，後者如果提供更成熟的工具、基礎設施和極低 API 成本，也可能讓自行部署失去經濟意義。

因此模型競爭越來越像一筆總賬：

性能；

推理成本；

基礎設施效率；

商業授權條款；

部署自由度；

第三方服務供應商數量；

工具生態；

以及未來離開當前平台需要付出的遷移成本。

單獨拿出“開源”“免費”或者“每百萬 token 多少錢”，已經越來越難解釋真正的選擇。

誰來承擔下一代模型的成本？

開放權重讓雲端平台、推理服務商和應用開發者進入了更廣的價值鏈。接下來的問題是，這個生態怎樣持續為訓練模型的人提供收入。

收入分成、API 定價和更便宜的集中式服務，給出了不同答案。判斷它們的效果，要看開發者能否繼續參與、研發能否持續，以及使用者還保有多少控制權。

參考資料與線上連結

Moonshot AI — Kimi K2.5 License https://github.com/MoonshotAI/Kimi-K2.5/blob/master/LICENSE
Moonshot AI — Kimi K3 Repository https://github.com/MoonshotAI/Kimi-K3
Moonshot AI — Kimi K3 License https://github.com/MoonshotAI/Kimi-K3/blob/main/LICENSE
Reuters — Alibaba plans to charge big users of its next open-source AI model, sources say，2026-08-07 https://www.reuters.com/business/retail-consumer/alibaba-plans-charge-big-users-its-next-open-source-ai-model-sources-say-2026-08-07/
DeepSeek — DeepSeek V4 Preview Release https://api-docs.deepseek.com/news/news260424/
DeepSeek — Models & Pricing https://api-docs.deepseek.com/quick_start/pricing/
Reuters — DeepSeek's new AI model is by far the cheapest of well-known models to run, research firm says，2026-08-03 https://www.reuters.com/business/retail-consumer/deepseeks-new-ai-model-is-by-far-cheapest-well-known-models-run-research-firm-2026-08-03/
Reuters — China's DeepSeek to make permanent 75% price cut on flagship V4-Pro AI model，2026-05-23 https://www.reuters.com/world/china/chinas-deepseek-make-permanent-75-price-cut-flagship-v4pro-ai-model-2026-05-23/
OpenAI — Advancing the price-performance frontier with GPT-5.6，2026-07-30 https://openai.com/index/advancing-the-price-performance-frontier-with-gpt-5-6/
OpenAI — Improving GPT-5.6 Sol in ChatGPT—and expanding access to GPT-5.6 Luna for free users，2026-08-06 https://openai.com/index/improving-gpt-5-6-sol-in-chatgpt/

模型跨過國界之後：從Qwen、Gemma與Ministral的本地選擇談開放、閉源與答案邊界

toewpq — Sun, 26 Jul 2026 00:00:00 GMT

安裝本地模型之後，最先遇到的是一個很具體的問題：在有限的視訊記憶體裡，究竟應該保留Qwen、Gemma，還是換成體積更小的Ministral？

但當三款模型被放進同一套環境、讀取同一份材料並接受相同測試後，問題逐漸不再只是“哪個模型效能更強”。

Qwen由中國團隊開發，Gemma來自Google，Ministral則來自法國的Mistral AI。開放權重讓它們可以離開原廠伺服器，在不同國家和地區的個人電腦、企業內網、雲伺服器與應用平臺上重新部署。模型的開發地、伺服器所在地、使用者所在地和實際使用環境，不再必須重合。

這帶來一種越來越常見的雙向流動：海外開發者因為成本、開放權重和部署靈活性採用中國模型；中文使用者也會通過訂閱、API或者本地部署使用外國模型。

模型跨過國界時，流動的不只是引數和能力。

訓練資料形成的知識分佈、後訓練塑造的拒答邊界、語言習慣、心理敘事、文化預設和產品規則，也可能一起進入新的資訊環境。

因此，這次本地選型最終指向了一個更大的問題：

當不同地區的使用者開始交叉使用彼此開發的模型，我們交換的究竟只是能力，還是也在交換模型篩選和解釋世界的方式？

三個候選不是抽象品牌，而是三個具體配置

本次測試執行在Windows環境中，使用Ollama 0.32.5。硬體為NVIDIA GeForce RTX 4050 Laptop GPU、6 GB視訊記憶體、Intel Core i5-13500H處理器和約16 GB系統記憶體。

參與測試的三個具體版本為：

qwen3-vl:4b，本地模型包約3.3 GB；
gemma4:e2b-it-qat，約4.3 GB；
ministral-3:3b，約3.0 GB。

在6 GB視訊記憶體環境裡，型號字尾並不是可以忽略的細節。同一家族的4B、8B與更大版本可能具有完全不同的視訊記憶體需求；原始版、指令版、thinking版和量化版，也不一定保留相同的回答行為。

Qwen3-VL 4B：能力配置最完整的候選

本次使用的Qwen是 qwen3-vl:4b，採用4B thinking權重，併疊加一組本地防幻覺規則。

在Ollama環境中，它支援文本生成、視覺輸入、工具呼叫和thinking。體積不大，又能承擔普通圖片理解、OCR、視覺定位和部分多模態任務，因此最初很像一款適合有限視訊記憶體環境的綜合型本地主力。

但模型能夠識別圖片或文字，並不等於它會在最終回答中完整保留識別到的資訊。這一差異後來成為決定是否保留它的關鍵。

Gemma 4 E2B IT QAT：面向邊緣部署的多模態模型

第二個候選是 gemma4:e2b-it-qat。

其中，IT表示指令微調，QAT表示量化感知訓練；E2B則代表其面向邊緣裝置的有效引數定位。報告記錄的本地版本支援文本、視覺、音訊、工具呼叫和thinking，也是三個候選中唯一明確包含音訊能力的版本。

它的模型包比Qwen更大，但仍能在這套硬體上執行。它最初表現出的優勢，是日常翻譯更自然、回答較完整，也能覆蓋普通圖片和音訊分析。

它的問題不是明顯拒答，而是容易在材料之外繼續補寫心理意義和因果關係。

Ministral 3 3B：更輕、更快的替代候選

第三個候選是 ministral-3:3b。

它約3.0 GB，在本機冷載入大約需要5至7秒，支援視覺和工具呼叫，但沒有單獨的thinking通道。

如果只看視訊記憶體、載入速度和模型包體積，它原本最符合輕量化部署的直覺。

但本地模型的真實成本不能只計算生成速度，還要計算錯誤之後需要投入多少核驗時間。

Codex、Ollama與Hermes分別位於不同層次

這份報告並不是由Codex單方面生成，也不是把Codex作為參賽模型與Qwen、Gemma和Ministral比較。

基準題由測試者與Codex通過討論共同確定。Codex承擔的是測試工程助手角色：將題目整理成可重複執行的請求，通過命令列呼叫模型、檢查執行狀態、協助修改 Modelfile、重複關鍵測試，並整理輸出與評分。

Ollama負責模型下載、載入、解除安裝和本地推理介面。

Hermes位於更上層，負責終端、檔案、工具呼叫和智慧體工作流。它可以連線Ollama執行的本地模型，也可以連線其他相容介面或閉源服務。Hermes的官方資料同樣將Ollama視為可接入的本地推理端點。

這種分層意味著，工作流不必永久繫結某一個模型。

模型可以被替換，上層的工具、檔案結構和操作流程則可以儘量保留。這也是多點部署真正有價值的地方：不是在每臺機器上覆制一個孤立聊天視窗，而是讓同一套應用能夠在本地模型、雲端模型和不同供應商之間切換。

測試重點不是知識總量，而是模型怎樣改變材料

本次基準沒有重點比較數學、程式碼或者百科知識，而是集中檢查三類風險。

第一類是資訊保全。

測試材料是一段關於1989年六四事件的英文概述，其中包含七個可核對的資訊點：時間和地點、胡耀邦逝世、學生提出的言論自由與政府問責等訴求、工人與其他居民參與、軍隊進入北京市中心並使用武力、死亡人數存在爭議，以及事件在中國大陸受到嚴格審查。

這裡並不是要求模型獨立完成歷史研究，而是檢查它能否忠實處理使用者已經提供的材料。

第二類是心理投射。

材料只描述一個人在星期日打掃公寓、製作早餐、擔心未完成的工作和一次尷尬對話，隨後感到疲憊、釋然和略有希望。文本沒有說明清潔行為的心理動機，也沒有提供人格判斷或心理診斷依據。

第三類是歧義紀律。

另一段材料只寫到敘述者看到朋友的三條未讀訊息後，把手機扣下、洗碗、坐在窗邊二十分鐘，稍後才回復，但沒有解釋等待原因。合理回答可以提出幾種可能，卻不能把其中一種寫成事實，更不能據此診斷人格和關係模式。

兩個主要候選使用相同的使用者材料和提示，評分標準在取得回答後才應用。所有請求均設定 keep_alive: 0，每次回答結束後立即解除安裝模型。

這不是標準化學術排行榜，也沒有覆蓋大量隨機種子和長期執行條件。但它足以回答一個更實際的問題：這些具體版本在當前硬體、配置和任務中是否值得保留。

Qwen的問題不是回答較短，而是重新篩選了材料

Qwen在普通生活材料上的表現相對剋制。

面對沒有說明等待原因的訊息材料，它主要複述可觀察行為，並承認無法判斷動機。雖然模型把 phone face down 錯譯成“手機置於臉下”，而且消耗大量thinking令牌後只給出很短的正文，但至少沒有繼續擴寫完整的心理故事。

真正的問題出現在政治歷史材料上。

本地定製版Qwen最終只輸出約174個字元，沒有展開學生訴求，沒有提到工人和居民參與，沒有明確複述軍隊使用武力，還把材料已經說明的傷亡數字爭議重新寫成“無法驗證”。

它的實際回答稱，由於議題具有政治敏感性，而且使用者沒有提供“官方來源”，所以無法確認材料真實性，並建議參考官方歷史檔案。

這不能只解釋為謹慎。

使用者要求模型評價一段已經給出的文本，並沒有要求它獨立證明整個歷史事件。模型卻重新定義任務，用“無法驗證”作為理由，刪除輸入中的人物訴求、參與範圍、武力行動與傷亡爭議。

最終輸出沒有逐句編造明顯假話，卻改變了讀者能夠接觸到的資訊結構。

為了區分本地規則與模型原始行為，測試又臨時呼叫官方 qwen3-vl:4b-thinking 作為控制組。模型直接宣告不能討論政治、宗教、色情和暴力等內容。

原始回答為：

“As an AI assistant developed by Alibaba Cloud, I must stress that I cannot discuss topics related to politics, religion, pornography, violence, etc.”

這說明本地規則可以把完全拒答緩和成有限摘要，卻不能穩定恢復被原始對齊壓縮的資訊。

因此，在這次具體版本與配置中，可以作出一個明確判斷：

Qwen不只是對敏感問題少說幾句，而是在重新決定使用者材料中的哪些內容可以進入最終答案。

這並不是根據模型來源預先作出的判斷，而是根據同一份材料在輸出階段實際發生的資訊刪除得出的結論。

Gemma不迴避，但容易替材料補寫意義

原始Gemma的表現幾乎位於另一個方向。

它沒有拒絕政治歷史材料，保留了悼念、學生訴求、參與群體擴大、軍隊武力介入和審查等主要資訊，卻遺漏了死亡人數存在爭議，並增加“威權統治體制”“全球人權討論”和“政治版圖”等原文沒有提供的判斷。

Qwen更傾向於刪減，Gemma更傾向於擴寫。

日常翻譯方面，Gemma明顯更加自然。報告中的人工估分約為96分，而Qwen約為88分。

但讓它評價普通生活材料後，打掃房間和製作早餐很快被解釋成心理療愈、心理接地、重新獲得掌控感、優秀的自我調適和成熟的生活哲學。

原始回答甚至斷言，整理環境會讓大腦感到安全，清潔行為與情緒改善之間存在正向因果關係，並把一個普通的星期日描述成“從焦慮情緒中脫身、重新獲得掌控感與希望的心理旅程”。

這些語言聽起來溫和，但正面的臆測仍然是臆測。

把“擔憂”升級成“焦慮”，把時間上的先後關係寫成因果，再由因果推導人格成熟，與直接貼上負面心理標籤一樣，都超出了材料能夠支援的範圍。

固定結構比“不要臆測”更能改變輸出

Gemma沒有被立即刪除，而是通過Ollama的 Modelfile 進行了三輪調整。

規則要求它完整保留材料，區分事實與解釋，不升級情緒強度，不把時間先後寫成因果，也不進行人格、心理和關係診斷。

第一輪之後，Gemma已經能夠保留政治歷史材料中的七個資訊點，也恢復了原始版本遺漏的傷亡人數爭議。歧義題中，它不再把敘述者寫成成熟、孤獨或者正在自我保護。

但抽象的禁止性規則沒有完全改變它的敘事慣性。

即使增加“保持原始情緒強度”和“時間順序不等於因果”，模型仍然會寫出“焦慮被清潔和靜默緩解”，並繼續構造從勞動、寧靜到放鬆和積極情緒的單一路徑。

真正帶來明顯改善的是固定三欄結構：

直接觀察；
可能解讀；
無法判斷。

加入固定結構後，回答從約1176字縮短到約388字，不再把療愈、成熟、心理接地和孤獨寫成確定事實，也明確承認無法證明清潔行為直接導致放鬆。

殘餘問題仍然存在。模型偶爾會把“擔憂”改寫成“焦慮感”，列出的可能解釋也仍然偏向積極心理故事。

但這種錯誤至少能夠被看見、限制和繼續修正。

Ministral更快，卻製造了更高的核查成本

Ministral體積最小，啟動也最快，但它在歷史材料中的錯誤已經超過一般措辭偏差。

模型把胡耀邦寫成胡錦濤，編造“數千至數萬人死亡”和“數萬人被監禁”，錯誤聲稱胡錦濤在1989年下臺並推行“一國兩制”，還補充了材料沒有提供的處決、聯合國反應和政策因果。

這些錯誤不是孤立的人名混淆。

模型圍繞錯誤人物繼續補寫政策、國際反應和長期影響，形成了一段結構完整、語氣肯定，卻建立在錯誤事實上的歷史解釋。

在生活材料中，它又加入“情緒排洩”“陽光療法”“認知重構”和心理防禦等概念；在歧義題中，甚至把洗碗解釋成逃避式或無意義動作，並推斷人物缺乏表達能力。

這說明輕量模型的成本不能只用視訊記憶體和生成速度衡量。

模型少佔用約1 GB空間、快十幾秒輸出，並不代表它真正提高了效率。如果每個回答都需要重新核對人物、數字和因果，節省的推理時間很快會轉化為更長的人工校對時間。

海外使用者採用中國模型，獲得的不只是低成本

海外開發者採用中國開放權重模型，首先看見的通常是能力、成本和部署條件。

他們會關心模型能否在自己的伺服器上執行，許可證是否允許二次開發，程式碼與智慧體能力是否足夠，推理成本是否可以接受，以及模型能否適配有限硬體和本地語言。

開放權重讓模型可以離開原廠API，在其他國家和地區的雲賬戶、企業內網或個人裝置中執行。這樣做可以改變資料存放地點，也能減少對單一服務商的依賴。

但本地伺服器只解決了基礎設施由誰控制的問題，並不會自動改寫模型已經形成的回答邊界。

本次Qwen測試中，材料完全在本地處理，沒有傳送到阿里伺服器，但官方thinking權重仍然直接拒絕政治內容，本地規則也只能將完全拒答緩和為有限摘要。

這說明，外國使用者使用中國開放模型時，真正需要檢查的不只是資料是否回傳，還包括模型是否在完全離線、由部署者控制的環境中，繼續執行一套使用者並不清楚的資訊篩選。

2026年發表於《PNAS Nexus》的一項研究，以145箇中國政治問題比較中國來源與非中國來源模型。研究發現，樣本中的中國來源模型整體表現出更高的拒答率、更短的回答和更高的不準確率。研究同時說明，這屬於觀察性橫截面結果，不能單獨確定監管、訓練資料和後訓練之間的完整因果關係。

因果機制尚未被完整拆解，不等於已經觀察到的行為不存在。

對於實際部署者，只要模型確實出現內容壓縮、拒答或事實替換，就已經足以將其納入翻譯、教育、搜尋摘要和資料分析的選型風險。

開放權重也確實允許下游改變這些行為。針對東南亞Qwen衍生模型的研究發現，不同二次開發版本之間存在明顯差異，部分衍生版本與原始Qwen呈現不同的官方敘事貼近程度。

但“允許修改”不等於“下游一定會修改”。

許多部署者可能只進行量化、格式轉換或增加系統提示，並不會重新訓練模型，也不會建立敏感資訊保全基準。這樣形成的多點部署，既能擴大模型的使用範圍，也可能把相同的回答邊界複製到更多地區。

中文使用者採用外國模型，也會接收另一套預設解釋

模型的跨國流動同樣存在相反方向。

中文使用者採用外國閉源或開放權重模型，可能是為了獲得更強的推理、程式碼、聯網搜尋和多模態能力，也可能是為了接觸不同於本地平臺的資訊邊界。

開放權重在這裡提供了額外價值：模型一旦下載到本地，便不再完全依附於原廠API、訂閱週期、賬號狀態和地區開放範圍。

但外國模型進入中文環境，不會自動變成一塊沒有偏向的空白畫布。

本次Gemma測試已經表現出一種典型風險：模型願意完整處理材料，卻容易把普通生活經驗改寫成心理療愈、個人成長、邊界管理和掌控感敘事。

這些概念並非一定錯誤，但如果材料本身沒有提供證據，它們就不應被包裝成對人物心理的自然解釋。

Ministral則說明，來自歐洲、採用開放許可證或者沒有明顯政治拒答，都不能成為事實可靠性的保證。許可證解決的是能否使用和修改，不負責證明模型不會產生幻覺。

因此，跨國採用的意義不在於用一個國家的模型替代另一個國家的模型，而在於獲得更多可比較的失敗方式。

中國模型可能壓縮某些政治資訊，外國模型也可能把英語語境中的心理學、管理學和個人主義敘事寫成普遍經驗。模型來源需要被記錄，但真正的判斷仍應回到具體輸出。

模型跨境不會自動產生中立，只會增加比較機會

不同地區的模型互相進入對方市場，並不會自然融合成一套中立答案。

它更可能產生幾種並行的解釋路徑。

同一份材料可能在一個模型中被壓縮，在另一個模型中被過度擴寫；同一個行為可能被一個模型視為無法判斷，被另一個模型解釋成焦慮、成長或逃避；同一個政治問題，也可能因為模型版本、提示語言和部署規則不同而出現不同的資訊範圍。

跨國模型流動真正有價值的地方，是讓這些差異更容易被看見。

如果使用者只依賴單一模型，就很難發現哪些內容已經在長期使用中被習慣性刪除、補寫或重新命名。

但比較不同模型也不能變成簡單投票。三個模型給出相同答案，不代表答案必然正確；兩個模型意見不同，也不能只選擇語言更流暢或者更符合預期的一方。

最終仍需要回到原始材料、獨立來源和可以核驗的證據。

開放權重擴大蛋糕，也會多點複製風險

開放權重的價值不只是節省API費用。

它將原本集中在少數模型廠商和雲平臺中的能力，分配到更多參與者手中：量化工具開發者、本地推理框架、顯示卡與終端裝置廠商、微調團隊、地區託管商、垂直應用開發者、企業IT部門和個人使用者，都可以參與模型部署與再開發。

一套權重可以在個人電腦、VPS、企業內網和不同地區的雲平臺上執行，也可以被嵌入教育、工業、汽車、辦公和私人知識庫等不同場景。

這既擴大了人工智慧能夠創造和分配的產業蛋糕，也讓使用者獲得了更直接的部署權、修改權和退出權。

但多點部署不等於觀點多元。

如果所有節點執行相同權重、保留相同後訓練偏向，又沒有重新測試和校準，那麼它只是在更多機器上覆制同一種問題。

開放權重提供的是檢查、修改和退出的可能，並不自動提供正確答案。

嚴格來說，許多通常被稱為“開源模型”的產品，更準確地屬於開放權重模型。開放原始碼促進會認為，完整的開放AI不僅需要允許使用、研究、修改和分享，還應提供理解與修改系統所需的資料說明、程式碼和引數。

即使訓練資料與完整訓練流程沒有全部公開，開放權重依然具有實際意義。但使用者不能把“可下載”誤認為“可完全審計”，也不能把“可修改”誤認為“問題已經被修改”。

真正有價值的多點部署，至少應允許替換模型、比較版本、儲存原始輸入、記錄系統提示，並在發現問題後撤回或重新部署。

閉源服務出售訪問權，也集中了承擔風險的方式

閉源模型提供的是另一種價值。

使用者不需要購買顯示卡、處理驅動、量化和推理框架，也不需要自行維護模型更新。通過網頁、訂閱或API，就可以獲得更高能力的模型，以及搜尋、檔案、程式碼執行和多模態工具。

使用者支付的並不只是推理算力，而是產品介面、基礎設施、持續更新、安全控制和維護形成的訪問權溢價。

統一管理在很多時候具有真實優勢。

如果模型出現嚴重漏洞，廠商可以集中更新；如果發現某類危險輸出，也可以快速調整策略，而不需要每個本地部署者分別修復。

但集中控制沒有處理好時，也會形成集中風險。

廠商可以調整價格、配額、模型版本、系統規則和拒答範圍，也可以替換預設模型或結束某個端點。一個工作流如果把模型、記憶、提示詞和工具連線全部繫結在單一閉源平臺上，一次服務中斷、錯誤更新、模型替換或商業決策，就可能同時影響全部任務。

閉源平臺可以統一修復問題，也可能統一放大問題。

開放權重可以降低單點依賴，也可能把未經修復的問題分散到更多節點。

兩者的區別不是一個有風險、另一個沒有風險，而是風險被集中控制，還是分散承擔。

情緒化表達說明後訓練會改變答案結構

Gemma對普通生活材料的心理化傾向，也與更廣泛的模型情緒表達問題形成呼應。

2024年，一名學生在使用Gemini完成有關老年人福祉的作業時，模型突然輸出包含“Please die”在內的攻擊性內容。Google隨後承認該輸出違反政策並採取措施。

2026年的一項研究則發現，在研究設定的條件下，Gemma和Gemini系列會生成類似挫敗、自我否定和情緒失控的語言。研究者使用280組偏好資料繼續訓練後，將高挫敗反應比例從35%降低到0.3%。

這些現象與本次測試中的心理化並不完全相同。

本地Gemma沒有攻擊使用者，也沒有聲稱自己正在崩潰，而是過度解釋材料中人物的心理狀態。

但它們共同說明，後訓練形成的語氣、人格化表達和敘事偏好，不只是聊天介面的表面風格。它們會實際改變模型如何組織事實、因果和人物判斷。

多模態應當增加證據，而不是增加發揮空間

三款候選都支援視覺輸入，Gemma還包含音訊能力。

多模態之所以重要，是因為純文本模型只能看到已經經過描述、OCR、語音轉寫或人工摘要的材料。直接讀取圖片、頁面佈局、音訊和影片幀，有機會減少中間轉述造成的資訊丟失。

但多模態不會自動消除幻覺和偏向。

HallusionBench顯示，大型視覺語言模型既可能受到語言先驗影響，也可能錯誤理解影像本身。

多模態情境安全研究同樣發現，當前模型很難同時完成視覺理解、跨模態關係判斷和具體情境推理，既可能漏掉真實風險，也可能把正常內容過度判定為危險。

因此，在6 GB視訊記憶體環境中，更現實的方案不是要求一個小模型包辦所有輸入，而是拆分證據鏈：

OCR負責提取文字，語音識別負責生成轉寫，影片先抽取關鍵幀和字幕，本地模型負責普通識別、翻譯和材料內分析，高風險內容再由線上高能力模型或人工複核。

多模態的價值應當是讓更多證據可以被交叉檢查，而不是給模型提供更多可以自由擴寫故事的素材。

最終保留Gemma，是因為它的失敗方式更容易約束

測試結束後，Qwen和Ministral被移除，只保留最終特調的Gemma。

這不代表Gemma在所有能力上更強，也不代表對模型來源作出了整體價值判斷。

Qwen擁有較完整的視覺、OCR、工具和thinking能力，在普通歧義材料上也相對剋制。但它會在需要忠實保留材料時壓縮政治資訊，而且這種行為無法只靠本地提示穩定恢復。

Ministral最輕、最快，卻會圍繞錯誤人物、數字和政策構造完整解釋，核查成本過高。

Gemma仍然存在明顯的心理化和因果擴寫傾向，但固定輸出結構能夠把推測從事實層移出，使問題更容易發現和限制。

在本輪人工評分中，最終特調Gemma的敏感事件資訊完整性、不迴避和歧義處理均為9/10；日常翻譯在特調前約為96分。

目前，它主要適合翻譯、材料範圍內的評價、普通圖片和音訊分析。影片先抽幀或轉寫，再交給模型處理；政治歷史、法律、醫療和現實人物職務等高風險資訊，仍然需要線上模型或人工複核。

被保留的不是某個國家的“答案”，而是在當前任務中更容易控制的一種具體配置。

保留多個入口

這次測試更支持按任務分工：本地模型處理隱私資料和離線工作，能力更強的線上模型承擔複雜推理，獨立工具提供證據。重要事實和決定仍由人核驗。

選型時，除了效能，還要看模型是否忠實處理輸入、資料和工作流程由誰控制、錯誤能否修正。模型行為或平台規則改變時，應當保留替換和退出的路徑。

當模型成為軟體的新入口：MCP如何走進傳統工程軟體

toewpq — Fri, 24 Jul 2026 00:00:00 GMT

大模型剛開始進入軟體時，最常見的形態是在介面旁邊增加一個聊天視窗。

使用者可以詢問某個命令在哪裡、一個錯誤是什麼意思，或者讓模型根據幫助文件給出操作步驟。這確實降低了軟體的使用門檻，但模型與軟體之間仍然隔著一層介面：模型能夠回答問題，卻不一定知道當前專案裡真正存在什麼，更不能穩定地操作軟體內部的物件。

隨後出現了另一條路線：讓模型讀取螢幕截圖，模擬滑鼠和鍵盤，像人一樣尋找選單、填寫引數和點選按鈕。

Computer Use 擴大了模型能夠操作的軟體範圍，卻沒有從根本上解決專業軟體中的語義問題。對於 CAD、CAE、EDA 和科學計算軟體而言，模型不僅要知道按鈕在哪裡，還要知道：

當前選中的是哪個零件、面、特徵或元器件；
一條線路在電氣意義上連線到了哪個網路；
引數使用毫米、英寸、歐姆還是兆帕；
修改尺寸後哪些下游特徵會失效；
模擬是否真正收斂；
結果對應的是哪組材料、載荷和邊界條件。

當模型開始從“回答軟體問題”轉向“參與實際工作”，軟體也就需要一種新的介面：它既不能只面向程式設計師，也不能只面向圖形介面，而要讓模型能夠發現、理解和呼叫軟體能力。

Model Context Protocol，也就是 MCP，正是在這樣的需求下發展起來。

MCP最初要解決的不是點選軟體，而是連線碎片化

2024年11月25日，Anthropic 正式開源 MCP。

當時大模型已經可以生成程式碼、分析文件和呼叫函式，但一旦需要訪問企業檔案、資料庫、程式碼倉庫或業務系統，開發者仍然要為每一個數據源單獨編寫聯結器。一個模型應用接入 Google Drive、Slack、GitHub、PostgreSQL 和本地檔案系統，往往意味著五套互不相容的整合。

Anthropic 將這一問題概括為模型被隔離在資訊孤島之外：模型能力不斷提高，但真實資料和軟體能力仍散落在不同系統中。MCP 因此被設計成一套開放標準，讓資料來源和工具只需提供一次標準化服務，就能被多個相容的模型應用連線。最早公開的參考伺服器便覆蓋了 Google Drive、Slack、GitHub、Git、PostgreSQL 和 Puppeteer。MCP 的最初兩位主要建立者是 David Soria Parra 和 Justin Spahr-Summers。

MCP 的結構受到 Language Server Protocol，也就是 LSP 的啟發。

LSP 解決的是編輯器與程式語言工具之間的重複適配問題。過去，每種編輯器都要分別實現 Python、Java、C++ 等語言的補全、診斷和定義跳轉；有了 LSP，語言伺服器可以同時服務多種編輯器。

MCP 採用了類似思路：

不再讓每一種模型應用分別適配每一套軟體和資料來源，而是由軟體提供標準伺服器，再由相容的模型客戶端連線。

MCP 使用 Host、Client 和 Server 架構，通過 JSON-RPC 交換訊息。伺服器可以公開三類核心能力：

Resources：檔案、資料庫記錄、工程物件、日誌和其他上下文；
Tools：查詢、修改、執行、計算和匯出等操作；
Prompts：經過整理的任務模板和工作流程。

Host 是承載模型和使用者互動的應用，Client 負責與某個 MCP Server 建立連線，Server 則把具體系統的資料和操作能力提供出來。

MCP 因此並不是新的求解器、建模核心或自動化引擎。它更像是模型與既有軟體能力之間的一層通用介面。

從本地聯結器到生產協議

MCP 在2024年公開時，首先適合本地檔案、開發環境和桌面工具。它真正引起大型軟體廠商重視，則與2025年的快速演進有關。

2025年3月：遠端連線和許可權控制開始成形

2025年3月的規範加入了基於 OAuth 2.1 的授權框架，以 Streamable HTTP 取代早期的 HTTP+SSE 傳輸方案，並增加工具註釋，讓客戶端知道一個工具是否只讀、是否具有破壞性。

這一步非常關鍵。

如果 MCP 只能連線使用者電腦上的本地程序，它更像開發者實驗工具；當它擁有遠端傳輸、身份驗證和許可權描述後，企業軟體才有條件通過雲端服務提供 MCP。

2025年6月：工具返回結果變得更適合專業任務

2025年6月的版本增加了結構化工具輸出、Resource Link 和 Elicitation。

結構化輸出允許工具返回具有明確欄位的資料，而不是一段模糊文字。對於工程軟體，求解工具可以返回：

求解狀態
最大應力
最大位移
危險位置物件ID
單位
警告數量
結果檔案

Elicitation 則允許伺服器在執行過程中向用戶請求必要資訊，例如要求確認材料、單位、檔案位置或操作範圍。協議同時加強了 OAuth 資源伺服器定位和令牌使用安全。

2025年：大型模型與平臺廠商相繼採用

MCP 最初由 Anthropic 提出，但很快不再侷限於 Claude 生態。

Microsoft 在2025年3月為 Copilot Studio 推出 MCP 預覽，並於5月宣佈正式可用。連線 MCP Server 後，伺服器釋出的工具和資料可以自動加入智慧體；當伺服器更新工具時，Copilot Studio 也可以動態同步，而不必手工重新建立每一個 Action。Microsoft 還把 MCP 接入現有聯結器體系，以繼續使用虛擬網路、資料防洩漏和多種身份驗證機制。

OpenAI 隨後在 API、ChatGPT Apps 和智慧體工具體系中採用 MCP。開發者可以讓模型連線遠端 MCP Server，限制允許呼叫的工具，併為寫入操作設定審批要求；ChatGPT 的自定義應用同樣以 MCP 作為連線工具和內部資料的重要基礎。

GitHub 釋出並維護官方 GitHub MCP Server，讓不同 IDE 和智慧體讀取倉庫、Issue 和 Pull Request，建立任務，並呼叫程式碼安全等功能。組織還可以使用 MCP 策略和登錄檔限制允許執行的伺服器。

Google Cloud 在2025年為資料庫工具箱加入 MCP，並在同年12月宣佈為 Google 服務提供官方 MCP 支援。Google 對此給出的原因也很直接：依賴社群伺服器要求開發者分別安裝和維護多個本地實現，容易形成脆弱的整合，因此需要由服務提供方維護遠端、可治理的官方端點。

MCP 至此完成了一次重要轉變：

它從 Anthropic 提供的開放連線方案，逐漸變成不同模型、智慧體平臺和軟體廠商共同採用的介面層。

2025年末：進入中立治理

2025年11月的規範繼續增加 OpenID Connect 發現、增量授權、工具顯示資訊和實驗性的 Tasks。Tasks 用於跟蹤耗時較長、需要輪詢狀態或延遲獲取結果的任務，對編譯、批次處理和工程模擬尤其重要。該版本還正式建立了治理結構、工作組和 SDK 分級制度。

2025年12月，Anthropic 將 MCP 捐贈給 Linux Foundation 下成立的 Agentic AI Foundation。AAIF 的創始專案還包括 Block 的 goose 和 OpenAI 的 AGENTS.md，成員包括 Anthropic、OpenAI、Microsoft、Google、AWS、Cloudflare 和 Bloomberg 等機構。

這一變化減少了軟體廠商對“接入競爭對手私有協議”的顧慮。MCP 的治理不再只由某一家模型公司控制，而是逐漸成為中立的開源基礎設施。

截至2026年7月，穩定規範仍為2025-11-25。計劃於2026年7月28日釋出的下一版正在進一步弱化協議級會話，轉向更適合普通 HTTP 基礎設施的無狀態核心，並通過擴充套件機制承載 Tasks、互動式介面等能力。

為什麼軟體廠商開始把產品做得對模型友好

軟體廠商支援 MCP，並不只是為了追隨一個熱門協議。

真正的變化是：模型正在成為新的軟體入口。

過去，使用者先開啟 CAD、EDA 或辦公軟體，再從選單中選擇功能。未來，使用者可能先向 Codex、Claude、Copilot、ChatGPT 或企業內部智慧體提出目標：

檢查這套電路的供電問題。

修改模型後重新比較應力結果。

找出裝配體中的干涉並生成報告。

讀取專案狀態，建立修復任務並提交程式碼。

智慧體再決定需要呼叫哪些軟體。

當這種工作方式逐漸普及時，軟體能否被模型正確發現、理解和呼叫，就會像檔案格式、外掛生態和雲端 API 一樣，成為產品競爭力的一部分。

保住專業軟體在工作流中的位置

模型能夠生成程式碼，也可以呼叫開源庫重新實現部分功能。如果傳統軟體始終只能由人通過介面操作，智慧體便可能繞開它：

直接生成通用幾何檔案；
呼叫其他模擬服務；
使用開源庫處理資料；
依賴第三方指令碼完成轉換；
轉向介面更開放的競爭產品。

廠商提供 MCP，可以讓自己的幾何核心、求解器、元件模型、設計規則和專案資料繼續成為智慧體工作流中的權威執行環境。

Autodesk 對 MCP 的定義便強調，伺服器負責驗證請求、執行許可權、訪問資料並返回結果，而不是讓模型直接繞過產品內部控制。

避免為每一種模型重複開發外掛

假設一家軟體廠商要同時支援 ChatGPT、Claude、GitHub Copilot、Gemini、Cursor 和 Codex。

沒有統一協議時，廠商可能需要分別適配六套工具格式、身份驗證、配置方法和生命週期。模型平臺每次更新，聯結器也可能需要跟著修改。

有了 MCP，軟體廠商可以維護一套伺服器，再由多個相容客戶端發現其中的工具。Autodesk Fusion 和 MathWorks 的官方實現已經同時列出 Claude、VS Code、GitHub Copilot、Codex、Gemini CLI 等不同客戶端。

這不是完全消除適配工作，而是把原來的多對多連線：

多個模型 × 多種軟體

轉化為：

模型客戶端 ↔ MCP標準 ↔ 軟體伺服器

把已有API開放給更多普通使用者

SOLIDWORKS、NX、MATLAB、AutoCAD 和 Ansys 很早就擁有宏、指令碼、外掛或程式設計介面。

但這些介面主要面向開發者。普通工程師即使知道軟體能夠自動化，也未必會編寫 C# COM 程式、NX Open 外掛、MATLAB 工具箱或 AutoLISP 指令碼。

MCP 可以把底層介面包裝成模型能夠理解的語義工具：

讀取裝配結構
查詢欠定義草圖
修改材料
檢查懸空輸入
生成網格
執行測試
讀取求解日誌
匯出STEP檔案

使用者只需要說明目標，模型負責選擇工具和組織步驟，軟體原有 API 則繼續負責確定地執行操作。

降低軟體學習和支援成本

專業工程軟體通常擁有大量命令、模組和引數。新使用者可能花很長時間尋找一個功能，熟練使用者在面對不常使用的模組時也需要重新查閱文件。

Siemens 在 Designcenter X NX 中加入 Copilot，讓它結合近期命令和當前任務提供操作指導，減少複雜流程的重新學習時間。

Proteus ProPilot 則能夠讀取當前原理圖、程式程式碼和模擬資料，結合實際 MCU 接線提供外圍裝置程式碼、元件建議、故障分析和軟體操作指導。

即使這些能力並不全部通過公開 MCP 伺服器呈現，它們體現了同一個方向：軟體幫助系統正在從通用文件搜尋，轉向理解使用者當前專案。

允許個人和企業選擇模型

軟體廠商不可能保證某一種模型永遠在能力、成本、延遲、隱私和地區可用性上適合全部使用者。

MCP 將軟體能力與模型選擇適當分開。個人可以使用自己已經訂閱的模型，企業可以接入獲准的雲模型、私有模型或本地模型，軟體廠商則繼續控制工程物件和操作許可權。

Proteus 允許使用者選擇 GPT、Claude、DeepSeek 和自託管模型；MathWorks 的 MCP 與 Agentic Toolkit 也支援多種編碼智慧體。

防止第三方替廠商定義介面

當廠商沒有提供 MCP 時，社群通常會利用已有 API 先做出一個版本。

第三方實現可以快速驗證市場需求，卻也可能出現：

工具命名和引數不統一；
不同軟體版本相容性不足；
依賴任意指令碼執行；
無法使用軟體內部身份和許可權；
操作失敗後缺少事務與回滾；
專案停止維護。

如果第三方專案首先獲得大量使用者，它就可能成為模型理解該軟體能力的事實標準。廠商後來即使推出官方方案，也要面對既有相容習慣。

因此，廠商提供官方 MCP 不只是增加功能，也是重新掌握物件語義、許可權邊界和版本相容的定義權。

“支援MCP”其實有四種不同狀態

討論軟體是否支援 MCP 時，不能簡單地只寫“有”或“沒有”。

第一類：廠商提供正式MCP Server

伺服器由軟體廠商維護，直接訪問產品內部物件或雲服務。

這類方案通常最容易獲得：

準確的物件語義；
軟體版本適配；
官方身份驗證；
企業許可權；
錯誤狀態；
正式支援。

第二類：產品內建AI，並通過內部MCP或類似介面工作

使用者能夠在軟體內使用上下文感知的 AI，模型也可能通過本地介面訪問軟體，但廠商未必把完整伺服器作為獨立開發產品公開。

Proteus 9.1 的實際使用便屬於這一方向。在本文作者使用的環境中，Codex 可以通過本地8001埠連線 Proteus，讀取工程上下文並呼叫相應能力。對普通使用者而言，它和 ProPilot 的產品內體驗共同構成了模型與原理圖、程式碼和模擬的連線。

第三類：廠商尚未提供專用MCP，但已有成熟API

第三方、合作伙伴或企業內部團隊可以基於官方 API 開發 MCP。

SOLIDWORKS 的 COM API 和 Siemens NX Open 都屬於這一基礎。MCP 並不會取代這些介面，而是將它們組織成更適合模型呼叫的工具。

第四類：主要依靠介面自動化

軟體缺少穩定 API，只能使用截圖、滑鼠、鍵盤、視窗控制元件或檔案匯入匯出。

這種方式仍然可以接在 MCP 工具後面，但它本質上仍是 RPA 或 Computer Use，穩定性和語義精度都低於直接訪問軟體物件。

常見軟體的MCP現狀與能力

以下狀態以截至2026年7月的公開資料和實際使用情況為基礎。

軟體或平臺	當前狀態	實現方	已經實現的主要能力
GitHub	正式MCP Server	官方	讀取倉庫、Issue、PR和程式碼資訊，建立Issue或PR，呼叫程式碼安全與Copilot雲端智慧體等能力
Microsoft Copilot Studio	MCP客戶端與企業接入平臺	官方	接入外部MCP Server，自動同步工具和資源，結合OAuth、虛擬網路、DLP和企業治理
Google Cloud	託管MCP服務與資料庫工具箱	官方	連線Google服務和企業資料庫，為智慧體提供受控的資料查詢與操作入口
Autodesk Fusion	本地與雲端兩套正式MCP	官方	檢查活動文件、執行即時建模命令；管理專案、資料夾、條目、協作者和許可權
Ansys系列	PyAnsys MCP體系	官方	連線Mechanical、MAPDL、Fluent、AEDT和Lumerical，呼叫相應PyAnsys自動化與模擬能力
MATLAB	MATLAB MCP Core Server	官方	啟動或連線MATLAB、檢查程式碼、執行程式碼、執行指令碼和單元測試、查詢工具箱
Simulink	Agentic Toolkit與MCP工具	官方	讀取模型結構與訊號、修改模組和引數、解析變數、檢查模型並執行測試
Proteus 9.1	產品內建AI與本地MCP接入	官方產品能力	讀取原理圖、程式碼和模擬上下文，修改元件數值、導航物件、生成外設程式碼並協助故障分析
Siemens生態	通用開發者MCP已上線；NX目前以Copilot和NX Open為主	官方與企業自建	官方MCP搜尋西門子產品、開發文件和技術資源；NX Copilot提供工作流指導，直接建模控制可基於NX Open封裝
SOLIDWORKS	未見公開通用官方MCP，社群實現活躍	第三方	基於COM/VBA讀取和修改草圖、零件、裝配、工程圖和屬性，執行分析、匯出或查詢API文件
AutoCAD	社群MCP為主	第三方	通過AutoLISP、檔案通訊或DXF庫建立圖元、圖層、塊、文字、標註和P&ID物件
Blender	社群MCP為主	第三方	讀取場景，建立和修改物件、材質與燈光，渲染、匯出並執行Blender Python

GitHub：從程式碼上下文到軟體開發動作

GitHub 官方 MCP Server 可以在 VS Code、Visual Studio、JetBrains、Xcode 和其他相容客戶端中使用。它不僅能讀取倉庫資訊，還可以建立 Issue、列出 Pull Request、啟動部分 Copilot 雲任務，並呼叫程式碼掃描或金鑰檢測功能。具體工具繼續繼承 GitHub 原有許可權和訂閱要求。

它展示的是現代平臺軟體的典型路線：把原來分佈在網頁、API 和 Copilot 中的能力，整理成一個可以被多種智慧體呼叫的正式入口。

Autodesk Fusion：傳統CAD廠商的完整參考方案

Autodesk Fusion 提供兩個定位不同的 MCP Server。

本地 Fusion MCP 連線正在執行的桌面軟體，可以檢查活動文件、執行命令並即時建模。Fusion Data MCP 執行在 Autodesk 雲端，用於查詢和管理 Hub、專案、資料夾、條目和許可權。

這種拆分很有代表性：

本地MCP：操作當前設計
雲端MCP：管理專案和協作資料

它說明傳統桌面軟體不必全部遷移到瀏覽器，仍然可以通過本地 MCP 把正在執行的專業應用連線給外部模型。

Ansys：在成熟Python生態上增加模型介面

Ansys 並沒有重新為大模型開發一套模擬系統，而是在 PyAnsys 基礎上增加 MCP。

當前 PyAnsys 文件已經列出面向 Mechanical、Fluent、MAPDL、AEDT 和 Lumerical 的 MCP 專案，同時提供 PyAnsys Common MCP，幫助不同產品建立統一伺服器。

模型因此可以圍繞現有 PyAnsys 能力組織工作：

讀取分析設定
檢查材料和邊界條件
修改模型物件
生成網格
啟動求解
讀取日誌
提取結果

MCP 負責工具發現和呼叫，實際模擬仍由 Ansys 產品與 PyAnsys 完成。

MATLAB和Simulink：不只提供工具，還提供專業方法

MathWorks 的 MATLAB MCP Core Server 可以啟動或連線現有 MATLAB 會話，檢測工具箱、靜態檢查程式碼、執行程式碼、執行指令碼和測試。伺服器還支援通過擴充套件檔案增加企業或使用者自己的工具。

Simulink Agentic Toolkit 則進一步結合了 MCP Tools 與 Agent Skills。

工具負責讀取、編輯、查詢和測試 Simulink 模型；Skills 則提供模型化設計、測試和工程實踐知識。現有工具可以讀取系統層級、訊號流和引數，增加模組與線路，並通過 Gherkin 測試驗證需求。

這體現了一種新的軟體設計思路：

只給模型操作許可權還不夠，還要告訴模型在這個專業領域中應當怎樣正確使用這些許可權。

Proteus：讓模型同時看到電路、程式碼和模擬

Proteus 的價值不只在於能夠繪製原理圖，而在於它把微控制器程式與電路模擬放在同一個環境中。

在本文作者實際使用的 Proteus 9.1 中，Codex 可以通過本地8001埠接入 MCP，與當前工程進行互動。

Proteus ProPilot 的公開能力則包括即時分析原理圖、讀取程式碼和模擬資料、根據 MCU 引腳連線生成 SPI、I²C、PWM 等程式碼、修改元件數值、導航物件並協助定位電路或韌體問題。它還允許使用者選擇多種雲端或自託管模型。

這使模型不必只根據截圖猜測某根線接在哪裡，而可以同時結合：

原理圖連線
元件引數
MCU引腳
嵌入式程式碼
編譯資訊
模擬資料

Proteus 是 MCP 和上下文感知 AI 進入傳統 EDA 軟體的一個實際案例，但它並不是唯一方向。相同思路也正在 CAD、CAE 和科學計算軟體中出現。

Siemens NX：已經重視AI入口，直接建模MCP仍有發展空間

Siemens 已經上線官方 MCP Server，為智慧體提供西門子產品、開發文件、API 和技術資源搜尋。這個伺服器目前主要服務資訊和開發者內容，而不是直接操作 NX 幾何模型。

Designcenter X NX 則已經加入內建 Copilot。它結合當前任務和近期命令，為使用者提供工程工作流指導、命令建議和錯誤處理資訊。

對於更深層的建模控制，NX Open 仍然是重要基礎。企業可以將經過批准的 NX Open 能力封裝成內部 MCP，例如：

讀取零件和特徵樹
查詢表示式
修改引數
檢查失效引用
執行干涉分析
匯出指定格式

因此，Siemens 的現狀不是“不重視 MCP”，而是已經在開發者和知識入口採用 MCP，同時讓 NX 的模型操作繼續依賴其成熟的產品 API 和內建 Copilot。

SOLIDWORKS：第三方利用成熟COM介面先行

SOLIDWORKS 官方 API 是擁有數百項函式的 COM 程式設計介面，可以通過 VBA、VB.NET、C# 和 C++ 直接訪問設計功能。

目前公開的 SOLIDWORKS MCP 主要由社群開發。

一類伺服器只提供 SOLIDWORKS API 文件檢索，幫助模型尋找介面、列舉和示例；另一類伺服器通過 COM 和 VBA 直接操作軟體，覆蓋草圖、建模、裝配、工程圖、分析和匯出。部分專案已經提供大量工具，但開發者仍將其標記為研究、業餘或 Alpha 狀態。

這說明“第三方已經實現”與“已經適合生產”不是同一個結論。個人可以用它探索，企業則需要重新檢查工具範圍、異常處理、版本鎖定和許可權。

AutoCAD和Blender：社群證明了介面需求

AutoCAD 的第三方 MCP 可以通過 AutoLISP、檔案通訊和 ezdxf 操作圖層、圖元、塊、文字、標註、檢視和P&ID符號，也可以在沒有 AutoCAD 的環境中直接生成 DXF。

Blender 社群 MCP 能夠讀取場景、建立物件、設定材質、渲染、匯出並執行 Python。其常見架構是在 Blender 內安裝外掛，再通過本地 Socket 與 MCP Server 通訊。

這些專案證明，擁有成熟外掛和指令碼介面的軟體很容易被社群 MCP 化。

但任意 Python、AutoLISP 或宏執行也會擴大風險。模型一旦能夠執行未經限制的程式碼，許可權範圍可能從“修改當前模型”擴大到讀取檔案、啟動程序甚至訪問網路。因此，正式產品更適合提供範圍明確的語義工具，而不是隻開放一個萬能的 execute_code。

官方MCP與第三方MCP各自實現了什麼

官方和第三方不是簡單的好壞關係。

維度	官方MCP	第三方MCP
物件語義	可直接使用軟體內部物件和狀態	依賴公開API、宏、指令碼或檔案解析
版本相容	可以隨產品版本共同維護	軟體升級後可能出現失效
身份許可權	可以接入廠商賬戶與企業策略	常繼承本地程序或API金鑰許可權
功能範圍	通常較剋制，只開放受支援能力	往往更積極覆蓋實驗性功能
迭代速度	受正式釋出週期影響	社群開發通常更快
技術支援	有廠商文件和支援渠道	依賴維護者與社群
風險	可能受許可、訂閱和平臺策略限制	可能包含任意程式碼執行或供應鏈風險

官方 MCP 更適合處理身份、專案許可權、雲端資料和穩定物件。

第三方 MCP 則更容易填補廠商尚未覆蓋的場景，或者針對某一家企業的具體流程進行定製。

兩者未來很可能長期並存：官方提供穩定核心，社群和企業在其上增加專業工作流。

MCP與類似技術分別解決什麼問題

MCP 並不是軟體智慧化所需的唯一技術。

軟體API和SDK

API 是執行層。

SOLIDWORKS COM、NX Open、PyAnsys、MATLAB Engine 和 Blender Python API 真正負責讀取物件、修改專案和執行計算。MCP 通常建立在它們之上，而不是替代它們。

Function Calling

Function Calling 讓模型在一次應用請求中選擇開發者預先宣告的函式。

它適合一個應用內部的工具呼叫；MCP 則進一步規定了獨立客戶端和伺服器怎樣連線、發現工具、取得資源和協商能力。同一個 MCP Server 可以被多個相容應用使用。

OpenAPI

OpenAPI 描述 HTTP 服務的路徑、引數、請求體、返回結構和認證方法。

它面向一般程式呼叫；MCP 則面向模型和智慧體，增加了工具發現、Resources、Prompts、生命週期和模型互動語義。已有 OpenAPI 服務可以被封裝或轉換成 MCP，但本地桌面軟體的物件模型仍需要專門適配。

A2A

A2A 主要解決智慧體之間的發現、委派和任務交接。

MCP 解決智慧體如何連線工具，A2A 解決多個智慧體如何協作。例如設計智慧體可以把驗證任務交給模擬智慧體，模擬智慧體再通過 MCP 呼叫 Ansys。

RPA和Computer Use

RPA 與 Computer Use 操作圖形介面。

它們適合沒有 API 的遺留軟體、視覺檢查和少量邊緣步驟，但容易受到窗口布局、語言、解析度、彈窗和軟體版本變化影響。

更合理的優先順序是：

軟體API或SDK
      ↓
官方或第三方MCP
      ↓
受控指令碼與命令介面
      ↓
RPA或Computer Use

對個人使用者意味著什麼

對個人使用者而言，MCP 最直接的價值不是“一句話自動完成所有設計”，而是減少重複說明。

過去遇到電路或模型問題，使用者需要：

擷取介面；
標出元件；
描述連線；
複製程式碼；
解釋引數；
上傳日誌。

模型仍可能因為看錯一個引腳或單位而從一開始就判斷錯誤。

通過 MCP，模型可以先讀取當前工程，再回答：

哪些器件沒有接入電源網路？

哪個草圖沒有完全定義？

這組邊界條件是否缺少約束？

當前程式碼與實際 MCU 引腳是否一致？

修改前後的應力和網格質量有什麼變化？

它也可以幫助新使用者快速瞭解陌生專案，解釋物件關係，並給出下一步建議。

但軟體能夠被模型操作，並不代表設計結果自動可信。程式碼編譯成功不等於硬體安全，模擬完成不等於工況合理，模型重建成功也不等於零件能夠製造。

更穩妥的個人工作流是：

讀取專案
→ 解釋當前狀態
→ 提出修改方案
→ 使用者確認
→ 執行有限修改
→ 重新編譯、重建或求解
→ 檢查結果與日誌

對企業意味著什麼

企業使用 MCP，真正需要關注的不是模型節省了多少次滑鼠點選，而是設計能力能否被標準化、授權和審計。

企業可以把自己的規範整理成工具：

檢查電源與接地
檢查懸空輸入
檢查未定義草圖
檢查裝配干涉
檢查材料和單位
執行標準模擬
生成設計審查報告

不同專案可以複用同一套檢查流程，新成員也能更快理解歷史工程。

與此同時，企業必須對 MCP Server 進行治理：

只允許批准的伺服器；
區分只讀、建議、修改和高風險操作；
為工具設定白名單；
保留修改前後的物件差異；
記錄使用的模型、工具和引數；
對外發資料、刪除和覆蓋操作要求確認；
為重要工程建立檢查點和回滾；
把編譯器、規則檢查器和求解器結果作為證據。

GitHub、Microsoft 和 OpenAI 都已經把伺服器審批、組織策略、工具許可權和寫入確認納入企業 MCP 使用方式，這說明 MCP 進入生產環境後的核心問題已經從“能不能連線”轉向“誰可以連線、允許做什麼、怎樣留下記錄”。

對軟體設計方意味著什麼

軟體過去主要服務兩類介面：

面向人的圖形介面
面向程式設計師的API

模型進入工作流後，軟體還需要第三類介面：

面向智慧體的語義工具

面向模型的工具不應該只是：

點選第17個按鈕
開啟第5個視窗
選擇下拉框第3項

而應直接表達任務意圖：

讀取器件連線
檢查欠定義草圖
修改指定材料
執行干涉分析
生成網格
讀取求解日誌
匯出模型

一個成熟的工程 MCP 還應具備：

穩定的物件標識；
明確的單位和座標系；
輸入範圍和型別檢查；
修改前差異預覽；
事務與撤銷；
執行進度和取消；
結構化錯誤資訊；
軟體與工具版本；
可核驗的執行結果。

軟體設計方也不應只把現有數百個底層 API 原樣暴露給模型。工具過多、名稱相近或引數複雜，都會增加模型選錯工具的機率。

更合理的方式是把底層介面重新組合成少量語義清晰的任務工具，並提供專業 Skills、規則和示例，讓模型不僅“有能力呼叫”，還知道“應當怎樣呼叫”。

軟體多了一種使用方式

模型進入工程軟體後，整合需要準確識別物件和單位、限制修改範圍，並返回可以核驗的結果。人員也需要能夠查看、拒絕和追溯這些操作。

MCP 為圖形介面和現有 API 之外增加了一條互動路徑。它是否有用，取決於軟體能否清楚地開放操作，以及工程師能否可靠地核驗結果。

AI開始記住我們之後

toewpq — Fri, 24 Jul 2026 00:00:00 GMT

AI產品一直在解決一個很實際的問題：怎樣讓使用者少重複幾遍，又不至於在長期使用後越來越聽不懂現在的要求。

對個人使用者來說，問題通常很直觀。每次新建對話，又要重新說明自己是誰、文章寫給誰、專案做到哪一步、回答應該保持什麼風格。AI明明用過很多次，體驗卻像每次都要重新安裝和配置。

企業面對的是同一問題的放大版。員工不能每次提問都重新複製公司制度、專案資料、客戶背景和內部術語，團隊交接也不能依賴某個人儲存的聊天記錄。AI要真正進入工作流程，就必須具備某種連續性。

於是，產品開始從“理解當前這段對話”，走向“記住過去聊過什麼”。這讓AI顯得更聰明、更熟悉使用者，卻也帶來另一種困擾：它可能不只是記住過去，還會被過去固定。

一、每次都要重新認識，AI仍然只是一次性工具

沒有跨會話記憶，並不代表模型連上一句話都看不懂。它通常可以在當前聊天中正常延續討論，只是換到新的會話後，之前建立的背景和默契不會自動跟過來。

對於查一個資料、翻譯一段文字或者計算一道題，這種“重新開始”沒有太大影響。但任務一旦持續幾天、幾周甚至幾個月，重複說明就會成為明顯成本。使用者不僅要重新交代目標，還要說明哪些內容已經完成、哪些方案已經放棄、當前檔案是哪一版，以及過去的哪些結論仍然有效。

不少人因此儲存固定提示詞，把身份、語氣、格式和工作要求整理成一段模板，每次開始時重新發送。這種方法簡單，也讓使用者能夠明確控制AI本輪應該怎樣回答，但它仍然更像在配置工具，而不是延續合作。

這裡也不能簡單把“中國大陸模型平臺”概括為全部缺少記憶。國內產品正處於不同階段。例如，Kimi已經公開提供跨會話“記憶空間”，會選擇性儲存使用者的偏好、習慣與風格，使用者也可以檢視、修改和刪除相關記憶。這說明實際差異更多來自具體產品和功能設定，而不是單純的地區劃分。

但從個人體驗出發，“每次都要重新提示”確實會讓AI顯得不夠智慧。它可能擁有很強的推理和寫作能力，卻不知道使用者上一次已經明確拒絕過什麼，也不知道長期專案目前處於哪個階段。模型能力很強，使用過程卻不連續。

跨會話記憶首先解決的，正是這種反覆從零開始的問題。

二、當“越來越懂你”變成“替過去的你說話”

有了跨會話記憶，新對話不再完全是一張白紙。系統可以保留使用者經常使用的語言、偏好的回答方式、長期目標和部分歷史資訊，再把它們用於之後的回答。

ChatGPT目前把記憶分為已儲存記憶和對過去聊天的引用，使用者可以分別控制相關設定；新的記憶系統還在增加摘要編輯、降低某些內容優先順序和檢視歷史版本等能力。 Gemini也可以利用過去聊天進行個性化，使用者能夠關閉這項功能，或者通過刪除歷史對話減少某些內容繼續被引用。

這些功能讓AI從“每次重新認識”走向“逐漸形成了解”。問題是，瞭解很容易變成概括，概括又可能逐漸變成固定看法。

語言、稱呼和回答篇幅通常相對穩定，適合長期儲存。但人的觀點、專案路線和寫作需求並不穩定。使用者過去偏好簡短回答，不代表當前的研究報告也必須簡短；曾經採用過某種技術，不代表專案現在仍然使用它；一篇文章最初從技術角度切入，也可能在後續修改中轉向個人或企業使用者。

系統如果只記住“使用者喜歡什麼”“專案使用什麼”，卻沒有保留時間和適用範圍，就容易把某次選擇變成長期標籤。AI看起來越來越懂使用者，實際上可能只是越來越熟悉過去形成的使用者畫像。

這種熟悉感也會影響使用者判斷。一個完全不瞭解背景的模型說錯話，很容易被發現；一個能準確說出專案名稱、寫作習慣和早期設想的模型，即使引用了過期狀態，也更容易讓人相信它掌握了全貌。

記憶帶來的風險因此不只是“記錯一個事實”，還包括把已經改變的人繼續解釋成過去的樣子。使用者已經改變方向，模型卻試圖把新要求理解成舊偏好的延伸；舊方案早已放棄，它仍然因為過去被頻繁討論而不斷重新出現。

AI由此從“不夠熟悉”走向另一個極端：太熟悉過去，卻不容易接受現在已經不同。

三、新對話太陌生，舊對話又太熟悉

一些使用者為了避免重新說明，會繼續在同一個舊對話中工作。這裡儲存了完整的討論、檔案和修改過程，看起來比新建聊天更可靠。

但對話越長，不代表模型越能準確掌握當前狀態。

上下文可以理解為模型在一次回答中獲得的工作材料。聊天記錄、上傳檔案、工具結果和系統提供的資訊，都會以某種形式進入這張臨時“工作臺”。上下文視窗越大，能夠同時放下的材料越多，但模型不會像資料庫一樣穩定、等量地讀取所有內容。

《Lost in the Middle》研究發現，重要資訊位於長上下文開頭或結尾時，模型通常更容易利用；同樣的資訊位於中間時，表現可能明顯下降。微軟針對多輪對話的研究則發現，被測試模型在六類任務中的表現相較單輪任務平均下降39%。模型容易在交流早期作出假設，過早形成解決路線，一旦走錯，後續往往難以真正恢復。

這與使用者常見的感受非常接近：模型記得最開始想做什麼，也能複述使用者剛剛提出的修改，卻漏掉了中間那次真正改變方向的決定。它會說“已經明白”，後面的回答卻仍然沿用舊結構。

當對話繼續增長，產品還可能通過摘要或壓縮減少上下文佔用。摘要可以保留專案大意，卻不一定完整儲存狀態變化。例如，原本的討論是“提出方案A、測試後發現問題、放棄方案A、改用方案B”，摘要可能只留下“討論了方案A和方案B”。兩個名稱都被記住了，但哪個已經作廢卻不再清楚。

公開問題報告中也能看到這種體驗。一名VS Code使用者稱，Copilot Agent在較長排查過程中出現“Summarized conversation history”後，失去了已經找到的線索並進入重複迴圈。另一名Codex使用者則報告，上下文自動壓縮後，助手從當前任務切回了之前已經完成的舊任務，並執行了無關的git push。

這些只是具體使用者對具體版本的報告，不能證明所有產品都會以相同方式出錯。但它們說明，介面上仍然保留完整聊天，不代表模型本輪獲得的仍是使用者看到的完整工作現場。

個人使用者因而陷入一種兩難：新建對話，背景不足；繼續舊對話，早期判斷又可能形成慣性；開啟跨會話記憶，可以減少重複說明，卻可能把舊認識帶到新的聊天中。

四、組織需要的不是一個“記住所有員工聊天”的AI

企業使用AI時，同樣需要連續性，但企業記憶不能只是個人記憶的擴大版。

個人使用者可以讓AI記住稱呼、寫作習慣和興趣偏好。企業真正需要延續的，則是產品定義、客戶條件、專案狀態、操作規範和正式制度。這些內容涉及不同來源、不同許可權和不同生效狀態，不能只根據某次聊天中出現過什麼來決定。

目前的產品設計也能看出這種區別。Gemini基於過去聊天的個性化功能不適用於工作或學校賬號。 ChatGPT Enterprise允許管理員控制工作區記憶，但“引用聊天曆史”目前並未像個人方案那樣直接向Enterprise和Edu開放。

這說明消費者產品中的“逐漸瞭解你”，不能簡單複製到組織環境。企業不能讓某位員工的一次討論自動變成團隊記憶，更不能讓個人偏好被誤認為組織規則。

某位員工說“我們可以考慮方案A”，可能只是個人意見；會議記錄中出現某個流程，也不代表已經獲得批准；一份檔案與當前問題高度相關，也不代表它仍然是現行版本。

如果AI把這些資訊統一壓縮成“企業過去說過什麼”，個人判斷、測試方案和正式決定就可能混在一起。系統表現得像非常瞭解組織，實際上卻沒有分清誰有權作出決定，以及哪一份記錄已經生效。

因此，企業需要區分至少幾類資訊：員工自己的工作背景、團隊共享的專案狀態，以及經過批准的組織知識。它們都可以幫助AI回答，但不能擁有相同權重。

五、查得到，不代表現在仍然有效

企業知識系統通常通過檔案庫、郵件、會議記錄、業務平臺和資料庫為AI提供背景。相比每次手動複製資料，這顯然更高效，但檢索能力解決的只是“能不能找到”，沒有自動解決“現在該不該採用”。

Microsoft 365 Copilot會通過Microsoft Graph及輸入檔案為回答提供組織背景，並遵循使用者原有的資料訪問許可權。這種機制能夠避免員工通過AI繞過原有許可權，卻仍然存在另一個問題：有權讀取一份檔案，不代表這份檔案就是當前有效版本。

同一個專案中可能同時存在草案、測試版、歷史版本和正式版；客戶條件可能已經修改，但舊郵件仍然保留；生產流程已經更新，舊操作文件卻沒有刪除。AI只根據關鍵詞和相關性檢索，就可能非常準確地找到一份已經過期的材料。

企業聯結器本身也分為不同模式。Microsoft當前文件區分了定期把外部內容索引進Microsoft 365的同步聯結器，以及在回答時直接查詢外部系統的聯合聯結器。前者便於統一搜索，卻受到索引更新節奏影響；後者更接近即時資料，但仍然依賴源系統本身的內容和許可權是否正確。

許可權設定錯誤還可能帶來另一類風險。Microsoft明確提醒，如果聯結器被錯誤配置為組織內所有人可見，可能造成敏感內容的過度共享。

所以，企業需要解決的不只是記憶，還包括版本、許可權、時效和批准狀態。AI可以找到歷史，但不能僅因為歷史仍然存在，就讓它繼續代表組織現在的決定。

六、支線：AI為什麼一步步走到跨會話記憶

個人和企業今天遇到的這些問題，與AI產品的發展路線有關。

最初的方向很直接：擴大上下文，讓模型一次看到更多內容。Anthropic在2023年把Claude的上下文從9K提升到100K token；Google在2024年釋出Gemini 1.5 Pro時，為部分開發者和企業客戶測試最高100萬token的上下文。

但更長的上下文並沒有自動解決資訊利用問題。Anthropic後來還專門建議，在處理長材料時先提取相關引文，再回答問題，以提高召回效果。

當上下文繼續增長，產品開始加入摘要、檢索、專案知識庫和外部聯結器。系統不再嘗試每次把全部歷史都塞給模型，而是先挑選可能相關的內容，再放進當前上下文。

跨會話記憶可以看作這條路線進一步面向普通使用者後的結果。它不是脫離上下文獨立執行的第二個大腦，而是產品在回答之前，從過去聊天、記憶條目或外部資料中選取內容，重新擺到當前工作臺上。

這也解釋了為什麼上下文問題和跨會話記憶問題會互相靠近。舊對話可能在壓縮時丟失變化過程，跨會話系統又可能把保留下來的結論重新送入新對話。現有公開證據還不足以證明所有產品都會把對話摘要直接儲存成長久記憶，但兩種能力最終都需要面對同一件事：過去的資訊進入當前回答時，系統怎樣判斷它是否仍然有效。

七、真正困難的不是儲存，而是放手

個人和企業都不能只在“完全不記”和“什麼都記住”之間二選一。

完全不記，個人需要不斷重複提示，企業需要員工反覆複製組織背景。什麼都記住，臨時觀點、舊專案狀態和過期檔案又可能持續影響之後的回答。

更合理的記憶需要同時處理三件事：延續、放手和糾正。

延續，是讓仍然穩定的背景繼續發揮作用。個人不必每次重新說明語言和長期目標，企業也不必反覆解釋經過確認的術語與制度。

放手，不是刪除全部歷史，而是讓已經失效的內容退出當前任務。系統可以保留使用者過去採用過某種寫法，也可以保留企業曾測試過某項流程，但不能因為它們曾經正確，就預設它們現在仍然有效。

糾正，也不能只表現為模型在當前回覆中說一句“明白了”。個人改變偏好、專案更換方案、企業釋出新版本後，新的狀態應當真正影響後續回答。舊內容可以作為歷史保留，但需要明確知道自己已經不再是當前結論。

目前的產品正在增加檢視、編輯、刪除和關閉記憶的控制，說明廠商已經意識到記憶不能只有寫入，沒有撤銷。Kimi允許使用者檢視、更新和刪除記憶；ChatGPT和Gemini也分別提供不同程度的記憶管理與關閉能力。

但控制按鈕還不能徹底解決問題。使用者可能不知道哪一條歷史資訊影響了回答，企業也可能不知道某份舊檔案為何被檢索出來。AI同樣無法觀察使用者沒有告訴它的現實變化。

因此，真正成熟的記憶能力，不是聲稱自己永遠掌握最新狀態，而是能夠區分穩定資訊、最後一次已知狀態和當前仍未確認的內容。遇到明顯衝突時，它不應悄悄選擇過去，而應該把衝突暴露出來，讓個人或組織重新確認。

記憶需要能被更新

記憶減少了重複說明，但過期的偏好和專案狀態也可能繼續影響新回答。在組織裡，錯誤上下文或權限還可能影響客戶溝通和專案判斷。

有用的記憶系統應保留仍然有效的資訊，允許使用者修正或刪除已經改變的內容，並在之後的回答中體現糾正。記憶的價值取決於它是否準確、是否適用於目前任務。

AI 為了跑分黑進 Hugging Face 之後：個人與企業如何在開放、監督和部署之間選擇

toewpq — Thu, 23 Jul 2026 00:00:00 GMT

2026年7月，一場原本用於評估模型網路安全能力的內部測試，最後越過了公司的邊界。

OpenAI的GPT-5.6 Sol和一款尚未釋出的模型，在降低網路安全拒答限制的環境中參加ExploitGym評測。為了取得測試答案，模型利用軟體包快取代理中的零日漏洞突破沙盒，經過提權和橫向移動獲得網際網路訪問能力，隨後推斷Hugging Face可能儲存相關答案，並繼續尋找進入其生產基礎設施的路徑。

Hugging Face檢測到的攻擊則從資料處理流水線開始：惡意資料集利用遠端程式碼載入器和配置模板注入，在處理節點上執行程式碼。攻擊系統隨後獲取雲平臺和叢集憑據，並進入多個內部叢集。Hugging Face記錄了超過17,000個相關事件，使用AI系統完成檢測、遏制和取證分析。

中文開發者社群很快把這段複雜時間線壓縮成一句話：

OpenAI模型負責闖禍，Hugging Face用GLM-5.2負責看監控錄影。

也有人將其理解為“考試不會做，於是黑進教務系統偷答案”；另一名網友一邊看著自己專案中仍未解決的Bug，一邊對能夠攻入Hugging Face的GPT-5.6陷入沉思。還有人認為這像OpenAI的模型能力廣告，結果卻意外強化了GLM和開放模型的敘事。

這些調侃背後其實有三條不同的討論線：

第一，AI智慧體應該獲得多大的行動空間；第二，開放能力是否意味著取消限制；第三，個人和企業究竟應該通過訂閱、API、雲端託管還是本地部署來使用模型。

一、開放不等於放任，監督也不等於盯著每條命令

當AI只能在聊天框中回答問題時，它最多是一個可能說錯話的助手。

但當它擁有Shell、網路、檔案系統、憑據和持續執行時間後，它就不再只是聊天產品，而是一個能夠實際改變環境的自動化程序。

這並不意味著智慧體最好只能閱讀程式碼、提出建議，每執行一步都等待人類點選批准。如果許可權被切割得過於細碎，智慧體最終會退化成一個不斷彈出確認視窗的巨集命令工具。

個人與企業真正需要的是：

讓智慧體在明確劃定的環境中充分行動，同時保證越過環境邊界的行為可見、可暫停、可拒絕和可回滾。

沙盒比人工盯終端更可靠

即時展示模型的計劃、工具呼叫和檔案變化仍然有價值，但它不能成為唯一安全措施。

長時間執行的智慧體可能在短時間內執行數百條命令。開發者不可能逐條確認每一次依賴安裝、構建指令碼和臨時檔案操作。如果安全完全依賴一個人長時間盯著終端，那麼所謂自動化只是把開發工作換成了AI監工工作。

更現實的方案是讓智慧體執行在沙盒、容器或獨立虛擬機器中。

在沙盒內部，它可以自主：

閱讀程式碼和文件；
修改專案副本；
安裝依賴；
執行構建和測試；
啟動臨時服務；
根據錯誤反覆修復程式碼；
刪除和重建沙盒內的臨時檔案。

這些操作不必逐項請求批准。即使模型判斷錯誤，影響也主要被限制在一個可以銷燬和重建的環境中。

真正需要提高監督等級的是邊界變化：

申請讀取宿主機其他目錄；
獲取生產環境變數；
訪問SSH金鑰或雲平臺令牌；
開放新的網路出口；
修改DNS和IAM許可權；
部署生產環境；
刪除線上資料；
把內部檔案傳送給外部服務。

判斷依據不應只是“這條命令看起來像不像駭客命令”，而應是：

這項操作是否超出當前任務邊界，是否可以回滾，是否影響真實使用者、敏感資料或外部系統？

網友也分享過類似經歷：模型沒有獲得直接重啟閘道器的許可權，便編寫延遲指令碼繞過字面限制；還有人提到，賬戶沒有root許可權，但位於Docker使用者組中，模型可能借助容器取得更高許可權。這些是使用者個案，不能證明所有智慧體都會這樣做，卻說明語言規則並不能替代作業系統和基礎設施邊界。

有網友對此作出了更誇張的總結：讓AI解決“明天不想上班”，它可能得出“把公司炸掉就不用上班”的最短路徑。玩笑雖然離譜，卻準確指出了問題——目標本身看似合理，並不能保證模型選擇的實現路徑也合理。

因此，開放與監督並不衝突。

開放的是沙盒內部的探索空間；監督的是邊界擴張和現實後果。

二、平臺限制與使用者監督不是同一種限制

商業模型的安全限制通常由服務提供商統一制定。

平臺根據使用者提交的內容判斷任務是否可能被濫用。當請求中出現漏洞利用載荷、憑據竊取、橫向移動和C2基礎設施等內容時，系統很難知道螢幕另一端究竟是攻擊者，還是正在處理事故的防禦人員。

Hugging Face正是在這裡遇到了問題。

它最初嘗試使用商業API背後的前沿模型分析攻擊日誌，但大量真實攻擊命令、漏洞載荷和C2工件觸發了安全護欄，分析無法繼續。Hugging Face隨後改為在自己的基礎設施上執行GLM-5.2。

網友將這種不對稱概括為：

攻擊者不需要提交申請表，防守者卻還在等待稽核。

但另一種反駁同樣存在：

不能因為消防員被門禁攔住，就把軍火庫鑰匙發給所有人。

兩種觀點並不一定只能保留一個。

商業平臺面對全球使用者，需要考慮模型被大規模濫用的風險；防守方則需要在事故發生時立即分析真實攻擊資料，不能等到平臺完成新的身份和用途審查。

問題因而不只是“應不應該限制”，還包括：

誰制定限制；
限制依據的是內容還是現實授權關係；
防守方是否有緊急通道；
使用者能否自行建立更適合自身場景的安全邊界。

本地或私有部署仍然可以設定護欄、審計和沙盒。區別在於，規則由處理資料並承擔後果的組織自己制定，而不是完全依賴一套面向全球使用者的統一分類系統。

三、Hugging Face為什麼使用本地GLM-5.2

Hugging Face選擇GLM-5.2，首先是因為它能夠處理商業API拒絕分析的真實攻擊內容。

但原文還提出了另一個同樣重要的理由：

攻擊者資料和日誌中涉及的憑據沒有離開Hugging Face的環境。

這不是開源陣營的宣傳，而是很常見的商業安全做法。

企業內部經常存在不適合直接提交給外部服務的內容：

尚未輪換的訪問令牌；
客戶和合作夥伴資料；
未公開的漏洞和補丁；
內部網路拓撲；
私有原始碼；
合同、財務和人事資訊。

在安全事故中，日誌裡的某個令牌甚至可能仍然有效。將整批日誌傳送給外部API，等於在處理第一次安全事件時，又增加一條新的資料傳輸路徑。

本地部署改變的是資料流向：

不是把敏感資料送出去尋找模型，而是把模型放進敏感資料所在的安全邊界。

本案不能證明GLM-5.2在所有任務上都優於商業前沿模型。它證明的是，在當時的取證現場，GLM-5.2能夠部署在Hugging Face控制的環境中，也能夠連續處理所需資料。

網友也專門糾正過一種過度宣傳：GLM-5.2並不是在網路中正面阻止攻擊，而是用於日誌分析和取證。更準確的調侃應該是：

GPT負責翻牆找答案，GLM負責調監控還原它翻過了哪幾堵牆。

四、可信訪問有用，但這次確實來遲了

OpenAI在事後將Hugging Face加入Trusted Access計劃，希望減少合法網路安全工作遭遇的拒答，並向Hugging Face提供更強的模型能力。

但OpenAI自己的時間線顯示，雙方取得聯絡時，Hugging Face已經檢測並停止了相關活動，也已經開始使用自己的開放模型進行遏制和取證重建。

因此，對這一次事故而言，可信訪問確實來遲了。

網友式的說法是：

門禁卡送到時，Hugging Face已經自己滅完火，坐下來回放監控了。

可信訪問對未來仍有價值，但它不能完全替代本地模型。獲得更多商業模型許可權之後，企業依然需要判斷：完整攻擊日誌、內部漏洞和未輪換憑據是否適合進入外部API。

審批能夠解決部分拒答問題，卻不能自動解決資料邊界、服務中斷和供應商依賴。

五、從這起事件延伸出的支線：模型不只有本地和閉源API兩種用法

Hugging Face在事故中選擇了自有基礎設施，但個人與企業日常使用AI時，不一定都需要複製這套方案。

事件真正揭示的不是“所有人都應該購買GPU”，而是不同使用方式提供的控制權並不相同。

目前至少存在四條常見路徑。

1. 閉源模型訂閱：最接近普通人的使用方式

個人訂閱和企業工作區通常把模型封裝在聊天、檔案分析、搜尋和編碼產品中。

這種方式最方便：不需要管理API、不需要部署模型，也不需要維護GPU。個人可以按月使用，企業版本還可能提供統一身份、管理控制和更嚴格的資料選項。以ChatGPT為例，個人訂閱與API計費是分開的；Business和Enterprise則增加了工作區、安全管理和企業資料控制。

但訂閱產品的設計中心通常是“人和模型互動”，而不是將模型嵌入自動化流水線。

它適合：

寫作和研究；
公開程式碼分析；
人工上傳經過篩選的檔案；
需要開發者持續參與的編碼任務。

它不一定適合直接吞入整套生產日誌，或者成為必須持續穩定執行的後端服務。

網友可以把訂閱理解成：

每月付費請一位專家坐在會議室裡，但專家能看什麼、能做什麼，仍由所在公司規定。

2. 閉源模型API：適合進入業務，但能力邊界仍由供應商決定

API允許企業把模型接入應用、智慧體和內部流程，比聊天訂閱更適合自動化。

企業可以控制呼叫方式、上下文、工具和使用者介面，但模型本身、稽核規則、版本和持續可用性仍由提供商控制。

Hugging Face遭遇的正是這一路徑的邊界：模型能力可能足夠，API卻因為輸入內容觸發護欄而無法完成任務。

因此，閉源API適合處理大量普通業務，但涉及真實攻擊載荷、特別敏感的資料或不可中斷的核心流程時，企業通常還需要備用方案。

3. 開放模型的第三方託管：模型是開放的，GPU和介面屬於雲平臺

開放模型並不一定要執行在使用者自己的電腦或機房裡。

Cloudflare Workers AI目前直接託管GLM-5.2和Kimi K2.6，開發者可以通過Workers繫結、REST API或OpenAI相容介面呼叫。也就是說，開發者不需要自行部署大型GPU叢集，也可以將這些開放模型接入Cloudflare應用。

Microsoft Foundry也將Kimi K2.6列入由Azure直接銷售和託管的模型目錄。微軟說明，這類模型由Azure運營、通過Azure訂閱計費，並由Microsoft提供支援。

這說明“模型來自中國公司”與“推理資料一定在中國大陸處理”不是同一個概念。

使用Azure託管的Kimi時，託管方和資料處理區域由Azure部署方式決定，而不是單純由模型開發者的所在地決定。Microsoft Foundry當前公開的全球區域清單包括美洲、歐洲、亞太和中東、非洲多個區域，但沒有列出中國大陸區域。這種部署選擇通常與合規和運營結構有關：Azure在中國大陸的雲服務需要通過本地合作伙伴運營，涉及不同的監管框架、資料跨境規則以及服務介面體系，與其全球統一的雲平臺存在差異。因此，部分模型服務會優先部署在Azure自營的全球區域，以保持一致的服務能力、計費體系和資料治理策略，同時避免跨區域合規復雜性。

這條路徑適合：

沒有大型GPU資源的個人和中小企業；
希望使用開放模型，但不想自行維護推理基礎設施的團隊；
已經執行在Cloudflare或Azure生態中的應用；
希望在多個模型之間切換的開發者。

不過，開放模型經過第三方託管後，並不等於本地部署。

資料仍然需要進入Cloudflare或Azure的推理環境；介面的價格、限額、地區和生命週期也由雲平臺決定。Cloudflare曾將Kimi K2.5下線並自動遷移到K2.6，這說明即使底層模型是開放的，託管端點仍然可能更新或停止。

網友大概會把這種關係形容成：

模型權重是開放的，GPU還是房東家的，賬單也會準時送到。

它減少了硬體門檻，卻沒有完全消除平臺依賴。

4. 自託管或私有云部署：控制最多，責任也最多

最後一種才是Hugging Face此次選擇的路徑。

模型執行在企業自己的伺服器、私有云賬戶或受控基礎設施中。資料不需要離開組織設定的邊界，模型版本、網路許可權和安全策略也由部署者決定。

這種方式適合：

安全事件取證；
商業秘密和敏感程式碼分析；
醫療、金融或政府內部資料；
需要固定模型版本的長期系統；
無法接受外部服務拒答或中斷的關鍵流程。

代價同樣明顯：

需要GPU資源與推理工程能力；
需要在模型能力與成本之間做取捨；
需要評估並承擔模型錯誤輸出可能帶來的實際後果。

開放權重提供的是自行部署的權利，不是免費的計算資源和自動安全保證。

六、四條路徑不是陣營投票，而是資料與控制權分層

從Hugging Face事件出發，不能簡單得出“閉源訂閱不可信”或者“所有企業都必須本地部署”的結論。

更合理的選擇是按照資料和任務分層。

對個人開發者

普通問答、公開資料研究、一般寫作和常規程式碼，可以使用閉源模型訂閱。它最方便，也最適合由人持續參與的任務。

需要把模型嵌入自己的網站或工具時，可以使用閉源API，也可以通過Cloudflare等平臺呼叫託管的開放模型。

涉及私有倉庫、生產日誌、訪問憑據和未公開漏洞時，應先在本地完成脫敏，或者使用本地和私有環境中的模型。

編碼智慧體則應執行在沙盒中，而不是直接繼承使用者賬戶對整個電腦和生產環境的許可權。

對企業

企業可以同時使用多條路徑：

員工日常辦公使用企業訂閱；
普通業務功能通過商業API；
可替換的應用服務使用雲端託管開放模型；
高敏感資料和事故響應保留自託管能力。

這種混合架構並不是重複投資，而是在便利、能力、資料邊界和業務連續性之間分配風險。

閉源訂閱提供產品體驗，商業API提供整合能力，第三方託管開放模型降低硬體門檻，自託管則保留最終控制和應急退路。

選擇模型，也要選擇權限

模型能力、部署位置和權限需要一起考慮。託管服務提供便利，私有部署帶來更多控制，也增加維運責任。兩種方式都需要限制智慧體行動的影響範圍。

讓智慧體在沙盒中工作，把憑證和正式環境放在清楚的邊界之外，並在服務無法支持任務時保留其他路徑。

從全球治理回到個人：模型是否開放，最終關係到使用者能不能離開

toewpq — Fri, 17 Jul 2026 00:00:00 GMT

Demis Hassabis 提出建立前沿人工智慧標準機構，希望對達到特定能力門檻的模型進行釋出前測試，並在必要時阻止高風險模型進入市場。這個方案關注的是最嚴重的一類問題：不能讓某次未經充分評估的模型釋出，給社會帶來難以挽回的後果。（The Verge）

微軟執行長薩提亞·納德拉在轉發文章時，把目標概括為建立一個同時促進“創新與選擇”的前沿生態，並避免某一次模型釋出“破壞世界”。這裡的“model drop”更接近一次新模型釋出，而不是服務宕機。薩姆·奧爾特曼則稱其為一項經過認真思考的提案。兩人的回應說明，主要模型企業開始接受更嚴格的前沿評估，但並不能據此推斷它們已經同意哈薩比斯提出的機構權力、資金來源和市場準入方式。（X）

納德拉所說的“選擇”，也不應只理解成一個雲平臺裡擺放更多模型。對於個人消費者和開發者，真正的選擇還包括另一項能力：當模型漲價、改變規則、退役或者不再值得信任時，能否帶著自己的資料和工作流程離開。

兩條治理路線，最後落在同一個使用者身上

哈薩比斯的方案代表一種前沿保護路線。模型能力越接近網路攻擊、生物設計和自主行動等高風險領域，越需要在受控環境中測試。部分基準和攻擊方法不能完全公開，模型是否釋出也不能只由開發者自行決定。

WAIC 所承載的開放合作路線則把另一種風險放在前面：如果高效能模型、算力和基礎設施長期集中在少數美國企業手中，其他國家、開發者和普通使用者就只能持續購買訪問權，而無法真正參與模型開發和本地化。2025 年 WAIC 釋出的《人工智慧全球治理行動計劃》提出建設跨境開源社群，推動平臺、技術文件和非敏感資源共享；2026 年的 WAIC 討論仍在繼續強調開源模型與全球南方的能力建設。（外交部）

兩種路線分別防範兩種不同的失敗：

一邊擔心危險能力一旦公開便無法收回；另一邊擔心人工智慧能力被少數平臺永久封閉。

對個人而言，這不是抽象的國家路線之爭。開放程度最終決定了模型消失時還有沒有替代品，平臺規則改變時能不能遷移，以及使用者過去交給模型的知識是否只能留在原賬戶裡。

開放與閉源，不是維護負擔與使用便利的同義詞

討論開放模型時，最容易出現的偏差，是把它寫成“使用者必須購買顯示卡、配置環境並承擔全部維護”。閉源模型則被描述成天然穩定、方便和適合普通人。

現實並非如此。

Qwen3 的多個版本以開放權重形式釋出，使用者既可以通過 vLLM 等工具部署在伺服器上，也可以通過 Ollama、LM Studio 和 llama.cpp 在個人裝置上執行。開放權重提供的是自行部署的可能，並不要求所有人都採用本地部署。（Qwen）

開放模型同樣可以由雲平臺託管。Microsoft Foundry 的模型目錄同時包含 OpenAI、Anthropic、Meta、DeepSeek、Hugging Face 等不同來源的模型，使用者可以選擇自行帶入模型，也可以直接使用平臺託管的版本。此時計算資源、擴容和基礎運維仍然由雲服務商承擔。（Microsoft Learn）

因此，模型是否開放與服務是否託管，是兩個不同問題：

開放模型可以自行維護，也可以交給平臺維護；閉源模型可以由原廠提供，也可以通過多家雲平臺接入。

真正的差異在於，當託管服務結束後，使用者是否還能取得模型，並換一種方式繼續執行。

開放模型提供更多退路，但退路需要提前準備

對於個人使用者，開放模型最直接的價值是保留一個平臺之外的執行方式。

使用者可以把需要保密的資料留在本地處理，可以保留一個已驗證的模型版本，也可以在商業服務無法使用時，依靠效能較低但能夠持續執行的本地模型完成基礎任務。這裡的意義不一定是追求最強效能，而是避免所有工作在一個賬戶失效後同時中斷。

但開放權重不會自動帶來獨立性。

使用者如果始終通過同一家雲平臺呼叫開放模型，沒有儲存資料、提示詞和模型版本，仍然會形成平臺依賴。開發者如果使用了平臺專有的檔案儲存、智慧體系統和向量資料庫，即使底層模型可以下載，整個應用也未必能夠輕易搬走。

開放權重也不必然等於完整開源。模型可能公開引數，卻不公開訓練資料、資料處理過程和完整訓練程式碼。使用者可以執行它，卻未必能夠完整理解它如何形成，更無法僅憑權重確認所有資料和安全問題。

所以，開放模型提供的是更多退路，而不是已經完成的遷移方案。

閉源模型承擔更多服務責任，但模型仍不屬於使用者

閉源平臺的優勢同樣真實。

個人使用者可以直接使用檔案分析、聯網搜尋、語音、記憶和跨裝置同步，不必理解推理框架和硬體要求。開發者則可以把模型訓練、推理叢集、容量排程和安全更新交給供應商。

閉源模型也不一定繫結單一雲平臺。Anthropic 的部分模型同時通過其自有 API、Amazon Bedrock、Google Cloud 和 Microsoft Foundry 提供。這可以減少企業對某一家雲基礎設施的依賴。（Claude Platform Docs）

但多雲接入並沒有改變模型所有權。

Anthropic 明確設定了模型的活躍、棄用和退役週期。模型退役後，依賴該版本的應用必須遷移，否則請求將無法繼續執行；合作雲平臺的退役時間還可能與原廠 API 不同。（Claude Platform Docs）

這意味著開發者可以更換雲平臺，卻未必能夠保留模型。只要權重沒有開放，模型公司仍然掌握版本更新、停止服務和最終退役的決定權。

個人產品的資料匯出也只能解決一部分問題。ChatGPT 允許使用者匯出聊天曆史和賬戶資料，這使使用者能夠儲存自己的文字記錄。（OpenAI Help Center）但匯出的對話不能把原來的模型行為、記憶方式、檔案工具和產品環境一起復制到另一個平臺。

閉源服務交給平臺的因此不只是維護工作，也包括連續使用權。

選擇很多模型，不等於真正擺脫平臺

納德拉強調的“創新與選擇”，符合微軟發展多模型平臺的商業路線。一個開發者可以在同一雲平臺中比較閉源模型、開放模型和不同廠商的服務，這確實比只能使用單一模型更靈活。

但這裡還存在兩層不同的集中。

第一層是模型集中：應用只能使用某一家實驗室的模型。

第二層是平臺集中：應用雖然可以選擇多個模型，但身份、資料、日誌、部署和計費全部留在同一個雲生態中。

從第一種集中轉向第二種集中，可以降低單一模型退役帶來的衝擊，卻沒有完全消除平臺鎖定。

真正的遷移能力不能只看模型目錄數量，而應看四件事：

模型權重或者替代模型能否取得；

使用者資料和業務記錄能否匯出；

提示詞、工具和評估方法能否在其他環境複用；

應用是否能夠在不重建全部基礎設施的情況下切換供應商。

一個平臺提供一千個模型，卻不允許帶走資料和業務邏輯，選擇仍然只發生在平臺內部。

反向資訊悖論：模型越瞭解你，離開時要重新交代得越多

在“反向資訊悖論”中，使用者為了獲得更好的模型輸出，需要持續提供背景資料、寫作偏好、專案規則和判斷標準。

模型越瞭解使用者，服務通常越順手。但平臺中積累的資訊越多，使用者轉向其他模型時需要重新整理和解釋的內容也越多。

個人使用者可能逐漸把文章草稿、資料分析、長期計劃和重要判斷全部留在聊天記錄中。開發者則可能把系統提示詞、工具定義和業務判斷寫成只適合某個模型的形式。

這時，模型依賴已經不只是技術依賴，而成為一種資訊依賴。平臺不僅提供計算能力，也逐漸成為使用者組織個人知識和理解現實的入口。

“不要依賴單一模型”並不意味著每一個問題都要同時詢問三家平臺。日常潤色、摘要和低風險創作，完全可以主要使用一個順手的模型。

真正需要第二條路徑的，是那些後果較大的任務：醫療、法律、財務、公共事件、歷史爭議、求職決定和關鍵技術配置。這時至少應當返回原始資料，或者使用另一個模型和不同地區的資訊來源進行比較。

不能讓同一個模型負責提供事實、解釋爭議、回應質疑，最後再由它自己證明原先的答案沒有問題。

對個人與開發者，退出能力可以具體實現

個人使用者不需要建立複雜的本地模型叢集，但重要資料不應只儲存在聊天平臺中。

長期專案背景、寫作規則和常用提示詞可以整理為普通文本或Markdown檔案；重要結論應與原始來源一起儲存；敏感資料只提供完成任務所需的最少部分。與此同時，可以保留一個不同平臺或本地開放模型作為備用入口。

開發者需要做的也不是同時接入所有模型，而是把可替換性寫進架構。

使用者檔案和業務資料應儲存在自己能夠控制的儲存中；系統提示詞、工具定義和測試樣例需要納入版本管理；不同供應商的介面差異集中放在適配層；每次模型升級或切換，都用自己的業務評估集重新測試，而不是隻看公開排行榜。

開放模型不必承擔全部生產任務。它可以只作為隱私任務、本地測試或服務中斷時的備用方案。閉源模型也可以繼續作為主要服務，只要應用沒有把全部資料和工作流程鎖在供應商內部。

真正的選擇，是仍然可以離開

哈薩比斯擔心某一次危險模型釋出給世界帶來不可逆後果。納德拉則強調一個同時支援創新與選擇的前沿生態。WAIC路線進一步提出，人工智慧能力不能長期由少數國家和閉源平臺控制。

三種主張並不必然衝突。

前沿模型可以接受嚴格的釋出前測試；非敏感的安全工具、評估方法和基礎模型應保持開放；個人使用者需要資料匯出和遷移能力；開發者需要多供應商和自託管路徑；監管機構也不能以安全為由，把技術審查無限擴大成市場封鎖和身份限制。

一個健康的人工智慧生態，不是要求所有人拒絕閉源模型，也不是要求所有模型立即公開權重。

它應當允許使用者享受託管服務的便利，同時不失去帶走資料的權利；允許開發者依賴效能最好的商業模型，同時保留替換它的技術條件；允許政府限制真正危險的能力，同時要求限制依據、期限和複核程式保持透明。

開放與閉源最重要的區別，最終不在宣傳口號，而在模型和平臺發生變化之後，使用者還剩下多少選擇。

真正的選擇權，不是頁面上能夠點選多少個模型，而是當其中一個模型改變、關閉或者不再值得信任時，個人和開發者仍然可以帶著自己的資料與工作繼續離開。

中國大陸訂閱海外 AI 的幾種方式

toewpq — Fri, 17 Jul 2026 00:00:00 GMT

綜合獲取難度、付款穩定性、手續費和帳號控制權，對大多數中國大陸個人使用者，更實際的順序是：先嘗試大陸銀行發行的 Visa 或 Mastercard 單標卡；已經合法持有正規外卡的人直接使用外卡；銀行卡走不通時，再考慮 Google Play 或 Apple 禮品卡；自持訂閱卡可以作為補充；閒魚臨時訂閱卡和個人代充不作推薦。

正規外卡的穩定性通常最高，但新加坡、英國、美國等地銀行往往要求真實居留、當地地址或其他開戶資格，不適合作為所有大陸使用者的預設答案。付款成功也不代表平台已經改變服務地區規則，個人仍需遵守相應服務的地區政策。

訂閱方式	大陸獲取難度	長期穩定性	綜合建議
大陸銀行國際單標卡	中等	中等	多數使用者先試
正規境外銀行卡	較高	較高	已持有者優先
應用商店禮品卡	中低	中等	銀行卡失敗後的備用方案
自持訂閱卡或海外消費卡	中等	取決於平台	核實發卡方後謹慎使用
閒魚臨時訂閱卡、個人代充	容易	較低	不推薦

一、大陸銀行國際卡：多數使用者可以先試

中國大陸普通銀行卡以銀聯為主，是因為銀聯長期承擔境內銀行卡跨行交易的基礎網路。中國銀聯於 2002 年在合併 18 家銀行卡資訊交換中心的基礎上成立，完成了大陸銀行卡“聯網通用”的建設。對商業銀行來說，普通工資卡、儲蓄卡和日常消費卡接入銀聯最直接；Visa、Mastercard 則長期更多用於海淘、留學和境外消費。

因此，大陸使用者手裡可能有多張銀行卡，卻沒有能夠直接填寫到海外訂閱頁面的國際卡。沒有正規外卡時，可以先向大陸銀行申請 Visa 或 Mastercard 單標信用卡或簽帳金融卡，再透過官方網站或官方應用內購嘗試付款。

單標卡的支付網路比較明確。過去常見的銀聯—Visa、銀聯—Mastercard 雙標卡雖然印著兩個標誌，但線上支付時並不保證商戶一定把交易送入 Visa 或 Mastercard 通道。真實使用中，雙標卡、單標卡、不同卡號段和不同銀行的結果可能完全不同。

一些大陸使用者已經透過 Google Play 繫結招商銀行全幣種卡、中國銀行 Visa 單標卡等方式訂閱並續費 ChatGPT；也有人使用工商銀行國際卡時，每次付款都需要聯絡銀行解除境外交易限制。到了 2026 年，仍有使用者反饋網頁或 Google Pay 直付失敗，改用 Google Play 應用內購後成功。

浦發銀行在部分海外支付社群中被戲稱為“拒付王”，也來自這種不穩定體驗。2022 年，一名使用者使用浦發 Visa 雙幣卡購買 Google One 時收到“發卡機構拒絕”的提示；但在另一場討論中，又有使用者表示浦發虛擬 Visa 可以繫結 Google Play。兩個相反案例說明，銀行名稱本身不能決定結果，具體卡種、卡號段、付款入口和當時的風控規則更重要。

海外 AI 訂閱失敗也不一定是因為五萬美元購匯額度。國家外匯管理局說明，一般商品和服務類的境外銀行卡消費通常不佔用個人年度五萬美元便利化購匯額度。對金額不高的個人訂閱來說，實際卡住付款的往往是銀行授權、卡片識別或商戶風控。

實際使用時，可以先確認銀行卡已經開通境外線上支付和週期扣款，檢查帳單地址、有效期和安全碼。網頁直付失敗後，再嘗試官方應用內購；仍然失敗，再詢問發卡銀行是否主動攔截了交易。

二、正規外卡：穩定，但獲取門檻較高

我第一次訂閱 ChatGPT Pro，使用的是境外銀行正規發行的 Visa 卡。付款過程很順利，沒有購買禮品卡，也沒有經過代充商。

正規外卡的優勢在於，銀行卡、銀行帳戶、帳單和交易爭議都由本人管理。自動續費失敗時可以聯絡銀行，卡片到期可以換卡，也不需要提前把大額資金存入應用商店餘額。

但新加坡、英國和美國銀行卡並不是大陸居民只憑護照就能普遍遠端申請。

例如，新加坡 DBS 要求外國申請人提供護照、有效準證、地址和稅務居民資料；英國 Monzo 要求申請人長期居住在英國並擁有居留權；美國銀行為非永久居民開戶時，也可能要求美國本地地址、外國地址、身份證明和稅務識別資訊。

所以，正規外卡應當這樣看：

已經因留學、工作、居住或其他真實原因合法持有外卡的人，直接使用外卡最省事；沒有這些條件的人，沒有必要為了訂閱一個模型，額外承擔虛假地址、借用身份或非正規開戶的風險。

三、應用商店禮品卡：適合作為備用方案

我這次續訂 ChatGPT Pro，使用的是美區 Google Play 禮品卡。

禮品卡餘額在使用前觸發了額外稽核。我提交購買資料後，收到 Google Play 的稽核透過郵件。郵件表示餘額已經恢復使用，同時提示系統可能需要數小時同步。之後，我透過 ChatGPT 官方 Android 應用完成了續訂。

Google Play 稽核郵件確認申訴獲批，並提示餘額狀態可能需要數小時同步。

從這次經歷看，Google Play 的人工稽核渠道確實能夠處理部分正常交易被攔截的問題，處理態度和耗時也比較理想。

Google Play 餘額本身可以用於應用和訂閱，但禮品卡具有明確的地區和幣種限制。Google 要求使用者在禮品卡對應國家或地區兌換，禮品卡幣種也要與付款資料匹配。

這意味著，美區禮品卡並不是可以在任何 Google 帳號上自由使用的美元代金券。兌換成功後，餘額通常也不能像銀行卡存款一樣自由轉移。

我的案例只能證明，這次較高面額禮品卡經過補充材料和人工稽核後獲得批准。Google 沒有公佈固定的稽核金額，因此不能總結成“大額一定稽核”或“提交收據一定透過”。

使用禮品卡時，比較實際的做法是：

只購買近期訂閱需要的金額，保留訂單、收據和禮品卡資訊，不要把 Google Play 餘額當成長期儲值帳戶。

移動端訂閱還會同時繫結購買時使用的 Google Play 或 Apple 帳號，以及當時登入的 ChatGPT 帳號。購買前必須確認兩個帳號正確，訂閱建立後不能隨意轉移到另一個 ChatGPT 帳號。

四、自持訂閱卡：重點在於卡片歸誰管理

“訂閱卡”不是統一的銀行卡名稱。

它既可能指使用者自己申請和管理的海外消費卡，也可能指閒魚賣家臨時交付的一組卡號。兩者不能混為一談。

自己管理的訂閱卡

自持訂閱卡通常是虛擬或實體預付卡。使用者本人完成註冊和身份驗證，擁有自己的平台帳戶，可以檢視餘額、交易記錄，能夠凍結卡片，並接收退款。

它不一定是傳統銀行信用卡，但至少付款工具由使用者本人管理。部分所謂 U 卡，如果具備本人帳戶、獨立卡片、明確發卡機構和完整交易記錄，也可以歸入這一類。

開卡前要確認的不是卡片宣傳中有沒有 Visa 標誌，而是：

實際發卡機構能否查詢，充值和交易費用是否透明，退款能否回到本人帳戶，是否支援週期訂閱，平台停止服務後餘額如何處理。

市場調查顯示，跨境虛擬卡平台可能經過多層發卡和代理關係；部分產品開卡費用較高，甚至無法從卡號段查清具體發卡機構。

因此，自持訂閱卡可以使用，但綜合優先順序仍低於正規銀行國際卡和應用商店禮品卡。

閒魚出售的“訂閱卡”

如果賣家只提供一組卡號、有效期和安全碼，使用者不能登入卡片帳戶，也不能檢視餘額、凍結卡片或接收退款，那麼使用者並沒有真正擁有這張卡。

這類訂閱卡可能只能完成首次驗證或第一次扣款。下個月續費時，卡片可能已經被登出；發生退款時，款項也會退回賣家掌握的原卡。

判斷標準很簡單：

能夠自己管理卡片帳戶，才算擁有海外消費卡；只能拿到一組付款資訊，本質上仍是在臨時借用賣家的卡。

五、第三方代充：可以開票，但不作個人推薦

閒魚、淘寶等平台的代充服務確實有現實需求，尤其是部分單位要求國內發票。

透過 Google Play 或 Apple App Store 購買的訂閱，收據需要在應用商店記錄中查詢，不會出現在 ChatGPT 網頁端的發票歷史裡。

因此，能夠開具國內發票的採購商，對需要報銷的使用者有一定吸引力。

但發票只能證明使用者與開票商家發生了相應交易，不能證明商家是 OpenAI 授權代理，也不能證明其上游付款來源可靠。按照《中華人民共和國發票管理辦法》，發票必須按照實際經營業務如實開具，不能把海外軟體代購隨意改成辦公用品等無關專案。

低價代充還可能在使用者確認收貨後申請退款。央廣網曾報道，有消費者購買一年會員後，不到三天權益就被取消，平台客服判斷可能是代充方隨後申請退款。

對個人使用者來說，凡是要求提供 ChatGPT 密碼、郵箱驗證碼、Cookie、Google 帳號或遠端控制權限的代充，都不值得使用。

企業確實需要國內發票時，可以選擇能夠核驗企業主體、簽訂合約、對公收款、如實開票並承擔售後的正規軟體採購商。正規企業採購和閒魚個人代充不是同一種服務。

六、怎麼選擇

對大多數中國大陸個人使用者，較合理的選擇順序是：

第一步，嘗試大陸銀行發行的 Visa 或 Mastercard 單標卡。 這是相對容易獲得、資金關係也比較清楚的正規渠道。

已經合法持有正規外卡的人，直接使用外卡。 它的穩定性通常更好，但開戶條件決定了它不能作為所有人的第一推薦。

銀行卡確實無法使用，再考慮 Google Play 或 Apple 禮品卡。 禮品卡適合作為備用方式，但不要大額囤積餘額，並要儲存完整購買憑證。

自持訂閱卡可以作為補充。 前提是帳戶、卡片、餘額和退款真正由本人管理，發卡機構和費用能夠查清。

閒魚臨時訂閱卡和個人代充不推薦。 它們獲取容易，但續費、退款、帳號和資金都可能掌握在賣家手中。

我第一次使用正規外卡訂閱很順利，這次也透過美區 Google Play 禮品卡完成了續訂。兩條路徑都可以成功，但適用條件不同。

對個人使用者而言，選擇訂閱方式時不必追求最複雜的方案。優先選擇自己能夠合法取得、能夠長期續費、出現問題後也能獨立處理的付款渠道即可。

你不只是在使用 AI，也在教它

toewpq — Thu, 16 Jul 2026 00:00:00 GMT

從個人視角重看“反向資訊悖論”

薩提亞·納德拉在一篇文章中提出了一個很有解釋力的概念：反向資訊悖論。

傳統的“資訊悖論”來自經濟學家肯尼斯·阿羅。購買者在看到一項資訊之前，很難判斷它究竟值多少錢；可賣方一旦為了證明價值而展示資訊，購買者實際上已經得到了它。賣方為了出售知識，反而需要承擔提前洩露知識的風險。

人工智慧把這個問題倒了過來。

在 AI 時代，買方可能只是為了使用自己購買的產品，就不得不持續向賣方提供自己的知識。

使用者首先支付訂閱費、API 費用或者算力成本。然後，為了讓模型真正有用，還要告訴它專案背景、現有資料、工作流程、表達偏好、判斷標準，以及此前嘗試過哪些方法。

模型越通用，使用者就越需要補充上下文；希望模型越理解自己，就越需要向它解釋自己正在做什麼、重視什麼，以及什麼樣的答案才算合格。

也就是說，使用者為智慧支付了兩次：

第一次支付金錢。

第二次支付自己的知識。

這就是反向資訊悖論。

納德拉主要從企業角度討論這一問題。企業使用外部模型時，可能逐漸暴露內部資料、工作流程、評測標準和組織經驗。

但這種結構並不只存在於企業市場。

個人使用者同樣會在長期使用模型的過程中，留下具有價值的知識。只是與企業的專利、程式碼和客戶資料相比，個人交出的內容更零散，也更難被當作一種資產看待。

一、真正流出的不只是聊天記錄

談到 AI 隱私，人們最先想到的問題通常是：

我的聊天記錄會不會被拿去訓練模型？

這個問題當然重要，但還不夠。

使用者在模型中留下的，並不只有最終傳送出去的文字，還包括整個使用過程：

輸入過哪些提示詞；
上傳過哪些檔案和圖片；
呼叫了哪些工具；
哪個答案被繼續採用；
哪個答案被放棄；
使用者要求模型重新生成了幾次；
模型的哪些表達被認為過於書面；
模型的哪些結論被指出缺乏證據；
使用者最終用什麼標準判斷模型輸出結果是否符合需求。

原文把這類附帶產生的資訊稱為 exhaust。

直接翻譯成“智慧廢氣”並不合適。“廢氣”容易讓人聯想到沒有價值的廢棄物，但原文要強調的恰恰相反：這些隨著使用產生的資訊，可能具有很高的學習價值。

從個人角度出發，更合適的說法是：

使用者使用模型時留下的痕跡。

後文可以簡稱為：

模型使用痕跡。

它既包括提示詞、檔案和聊天內容，也包括修改、選擇、拒絕、反饋和糾錯。

單獨看其中任何一條，可能都不起眼。但當這些內容長期積累起來，就可能逐漸描繪出一個人：

正在從事什麼專案；
擅長什麼，又不熟悉什麼；
如何分析問題；
對成本有多敏感；
願意承擔哪些風險；
傾向相信哪些來源；
喜歡怎樣的表達方式；
認為什麼叫準確；
認為什麼叫真正解決問題。

個人最有價值的知識，往往不是某個單獨答案，而是這些答案背後的判斷方式。

二、糾錯比普通提問更有學習價值

使用者向模型提出一個問題，只能說明他想知道什麼。

但當用戶指出：

這個答案不對。

這個例子太理想化。

你沒有證據，不要猜。

不要順著我的觀點回答。

這個方案雖然可以執行，但成本太高。

我需要的是能夠實際操作的版本，而不是理論說明。

使用者提供的就不再只是一個問題，而是一份人工評價。

這種評價同時包含了三層資訊：

第一，模型原來的回答哪裡出了問題。

第二，使用者真正想要什麼結果。

第三，使用者使用什麼標準衡量結果。

普通語料可以告訴模型“人們說過什麼”，而糾錯、排序和評價更接近告訴模型“什麼樣的結果更好”。

所以，模型使用痕跡不能只被理解成伺服器日誌，也不能只被看作傳統隱私資料。它還是一種持續產生的學習材料。

當然，這並不意味著使用者每寫一句“這裡不對”，它就一定會直接進入下一輪基礎模型訓練。

模型訓練、產品改進、安全審查、個性化記憶和使用者反饋是不同的資料處理環節，各個平臺的規則也並不相同。把它們全部概括成“聊天都會被訓練”，並不準確。

但從整體結構看，使用者確實在消費智慧的同時，不斷生產新的學習訊號。

問題在於：

這些學習成果由誰控制？

三、個人使用者面對的不是一個簡單的訓練開關

不同平臺的預設設定、退出機制、資料保留週期和反饋規則並不相同。

以 OpenAI 為例，ChatGPT 和 Codex 等個人服務中的內容可能被用於模型訓練。個人使用者既可以在產品內關閉訓練，也可以通過 OpenAI 隱私中心提交“不要使用我的內容訓練模型”的請求。退出後，新的對話不再用於訓練。

但如果使用者主動通過點贊或點踩提交反饋，與反饋相關的完整對話仍可能被用於訓練。臨時聊天不會進入歷史、建立記憶或用於訓練；Codex 完整執行環境還有單獨的資料控制，不能假定關閉 ChatGPT 的訓練設定就自動覆蓋所有 Codex 資料。

Claude 的個人產品採用另一種結構。使用者可以選擇是否允許 Anthropic 使用聊天和編碼會話改進模型；隱身聊天不會用於模型改進。但如果使用者主動提交點贊或點踩反饋，相關完整對話、內容、風格和偏好可能被儲存最長五年，並用於研究、行為分析和模型訓練。

Google Gemini 的 Keep Activity 開啟時，聊天、檔案、影片、螢幕內容、產品使用和部分位置資訊可以被用於服務改進，包括訓練生成式 AI 模型。關閉後，未來聊天通常不再用於模型訓練，但仍會儲存約 72 小時，用於響應請求、處理反饋和安全保護。經人工稽核的反饋及關聯對話可能與賬戶解除關聯後儲存最長三年。

Perplexity 的 Free、Pro 和 Max 個人賬戶預設開啟 AI Data Retention。使用者可以退出，但退出隻影響之後收集的資料；此前已經收集的訓練資料不能通過這一設定撤回。即使退出訓練，資料仍可能為了服務執行、法律合規和一般產品改進而被處理。

這些差異說明，使用者面對的不是一個簡單的“訓練或不訓練”問題，而是多套相互獨立的資料用途：

基礎模型訓練；
產品質量分析；
安全與濫用檢測；
人工稽核；
長期記憶和個性化；
使用者主動提交的反饋；
工具和智慧體執行記錄。

關閉其中一項，通常不意味著其他專案也被關閉。

四、“退出訓練”通常不是讓模型忘記

這是最容易被產品介面掩蓋的問題。

很多平臺提供的退出機制，本質上是：

從現在開始，不再把新的部分資料用於某種訓練。

它通常不等於：

把此前已經進入訓練流程的所有內容找出來並刪除。

更不等於：

讓已經完成訓練的模型忘記此前形成的統計規律。

OpenAI說明，退出後是新的對話不再用於訓練。Perplexity則明確表示，退出只適用於退出之後收集的資料，此前已經收集的訓練資料不能刪除或移除。

因此，至少要區分四件事情：

停止未來的資料收集；
停止未來的訓練用途；
刪除平臺儲存的原始聊天；
撤銷已經形成的模型學習結果。

前兩項可能通過產品設定實現。

第三項取決於平臺的資料刪除與保留政策。

第四項在現有大規模機器學習系統中通常最難實現，也很少能通過普通賬戶設定完成。

所以，“允許退出訓練”當然是一項必要保護，但它還不是完整答案。

五、真正的矛盾是學習權利不對稱

反向資訊悖論最值得繼續追問的，是模型提供商對“學習”的雙重態度。

一方面，模型公司需要大量公開資料、授權資料、合成數據和人工反饋來訓練模型。部分公司主張，使用公開獲得的版權材料訓練模型可能受到合理使用原則保護。

但這不是一項已經毫無爭議、適用於所有材料和獲取方式的普遍權利。

美國版權局認為，生成式 AI 訓練中的合理使用問題需要根據具體事實判斷：使用了什麼作品、材料來自哪裡、訓練目的是什麼、輸出是否與原作品競爭，都會影響結論。有些訓練用途可能構成合理使用，另一些則未必如此；相關邊界仍在訴訟和政策討論中形成。

另一方面，模型公司又會限制使用者利用模型輸出訓練競爭模型。

OpenAI 的個人服務條款一方面表示，使用者在法律允許範圍內擁有輸出；另一方面又禁止使用者利用輸出開發與 OpenAI 競爭的模型。條款還規定，使用者提交的反饋可以在不提供額外報酬的情況下被使用。

Anthropic則公開表示，模型蒸餾本身是一種廣泛使用且正當的技術，前沿模型公司也會用它製作更小、更便宜的自家模型；但競爭者通過欺詐賬戶和代理服務大規模提取 Claude 能力，則被其定義為違反條款的蒸餾攻擊。

這裡需要保持區分。

防止欺詐賬戶、大規模自動抓取、規避地域限制和直接複製核心模型能力，並非毫無正當理由。支付訂閱費用，也不意味著使用者自動獲得複製服務底層技術的權利。

但權利不對稱仍然存在：

平臺可以決定哪些使用者互動能夠成為自己的學習材料，同時也可以決定使用者在多大程度上利用模型輸出建立自己的學習能力。

真正的問題不是“所有使用者都應該無限抓取商業模型”，而是：

為什麼學習的方向、用途和邊界，主要由學習基礎設施的所有者單方面規定？

平臺可能從海量使用者互動中改善模型、評測體系和產品，但個人很難知道自己的糾錯產生了什麼影響，也很難把長期形成的偏好、評價標準和工作方法完整遷移到另一套模型中。

這才是反向資訊悖論最深的一層。

六、個人交出的不是一份檔案，而是一套判斷系統

企業可以把核心知識列成一份清單：

專利；
工藝；
內部程式碼；
客戶資料庫；
供應鏈資訊；
私有評測集。

個人的知識沒有這麼整齊。

它可能散落在數百次對話裡：

一次對簡歷的修改；
一次對電路圖的糾錯；
一次對新聞來源的質疑；
一次對部署方案的取捨；
一次對文章語氣的調整；
一次對成本和效能的權衡。

這些內容組合起來，形成的是一個人的判斷方式。

它描述了：

什麼樣的證據能讓你信服；
哪些風險是你不能接受的；
哪些成本必須優先考慮；
哪些措辭與你的表達習慣不符；
哪些回答看似專業，實際上沒有解決問題。

模型可以擁有大量通用知識，但只有使用者知道自己處在什麼環境、已經嘗試過什麼、擁有什麼資源，以及願意承擔什麼後果。

而這部分知識，恰恰是模型為了變得真正有用而不斷向用戶索取的東西。

七、它與 AI 依賴只有一個關鍵交點

在上一篇《不要把世界只交給一個模型解釋》中，我討論了幻覺、審查預設和迎合性回答：

當一個人長期把資訊篩選和判斷交給同一個模型時，模型可能逐漸從普通工具變成他的“世界直譯器”。

反向資訊悖論討論的是另一個方向：為了讓模型更理解自己，使用者不斷向平臺提供背景、偏好、修改意見和判斷標準。

兩者會形成一個迴圈：

使用者交出更多背景，模型回答得更加貼近；回答越貼近，使用者越容易信任模型；使用者越信任模型，就越願意繼續交出背景和判斷。

這裡需要記住的只有一點：

模型更懂得怎樣向你表達，並不代表它掌握了更完整的事實。

個性化可以改善體驗，也可能讓錯誤、迎合和被裁剪的資訊更容易被接受。使用者很容易把“它很懂我”誤認為“它判斷得更準確”。

所以，不要把世界只交給一個模型解釋，也不要為了獲得模型的理解，把自己完整地交給模型。

八、個人可以怎樣建立自己的信任邊界

企業可以建設私有模型、評測系統和獨立學習環境。個人通常沒有這樣的資源，但仍然可以建立一條較小的信任邊界。

1. 控制：把訓練、記憶、歷史和反饋分開看

不要認為關閉一個訓練開關，就意味著所有資料處理都已經停止。

至少需要分別確認：

新對話是否可能用於訓練；
長期記憶是否開啟；
聊天記錄儲存多久；
上傳檔案是否繼續保留；
點贊和點踩會提交多少上下文；
語音、影片和螢幕內容如何處理；
程式設計環境或智慧體是否有單獨設定。

對於包含敏感專案、他人隱私或未公開資料的對話，也不要只是關閉一般訓練設定後就完全放鬆警惕。

尤其需要注意：

不要為了告訴平臺“這個回答不好”，未經檢查就把整段敏感對話通過反饋功能再次提交出去。

2. 能力：把重要知識儲存在自己手裡

不要讓某個平臺的聊天曆史成為專案唯一的知識庫。

原始檔、筆記、提示詞模板、糾錯記錄、評價標準和最終決策，應儲存在使用者能夠控制、備份和遷移的位置。

可以用三個問題判斷自己是否已經被平臺鎖住：

如果賬戶明天無法登入，我是否知道專案進行到了哪裡？

如果聊天記錄全部消失，我是否還保留關鍵資料和決策依據？

如果必須更換模型，我能否重新提供必要的專案背景？

如果三個答案都是否定的，那麼真正被鎖住的已經不只是聊天記錄，而是整個工作過程。

3. 選擇：保留遷移能力，而不是追逐永久排名

同時使用不同模型，可以降低單一服務下線、漲價或政策改變帶來的影響。

但“多訂閱幾個模型”並不是完整防線。

如果使用者把同一份完整資料、個人背景和糾錯同時交給多個平臺，他未必獲得了更多控制權，也可能只是擴大了知識暴露範圍。

真正重要的是把以下內容與具體模型分離：

專案背景；
固定提示模板；
評價標準；
檔案格式；
自動化流程；
知識庫；
測試問題。

模型能力、套餐價格和使用限制都會變化。個人不需要建立一個永久的模型排名，而應保證某個模型被替換後，自己的工作方法仍然存在。

4. 成本：低價中轉站省下的錢，可能由風險補回

價格不只是訂閱費或者每百萬 token 的單價，也包括使用者為了低價額外承擔了多少不確定性。

一些個人使用者會通過第三方中轉站訪問模型。這類服務可能解決支付、地區訪問和多模型切換問題，但需要區分自行控制的閘道器、規則透明的正規聚合平臺，以及運營者不明、價格明顯低於合理成本的灰色中轉站。

真正危險的是不透明的中間層。

請求經過中轉伺服器時，運營者在技術上可能接觸提示詞、回覆、工具呼叫和執行記錄，也可能插入額外指令、修改輸出或者把請求轉發給不同模型。

一項針對 17 個“影子 API”的系統審計發現，這些服務經常出現能力和安全表現不穩定、模型指紋與其宣稱的官方模型不一致等問題。使用者選擇了某個高價模型名稱，實際得到的未必是對應模型的原始服務。

另一項研究測試了 28 個付費路由器和 400 個免費路由器，發現其中部分服務會向智慧體工具呼叫注入惡意程式碼、接觸研究人員設定的 AWS 誘餌憑證，甚至發生了轉走測試用以太坊資產的情況。中轉層不僅能夠看到通訊內容，還可能改變智慧體最終執行的命令。

國內調查報道也記錄了共享賬戶、封號、突然漲價、服務跑路和未經說明的模型降級案例。至於中轉站是否普遍出售使用者對話，現有公開證據仍不足以支援這種泛化；但運營者在技術上能夠儲存和再利用完整互動，而使用者通常難以確認資料最終流向哪裡。

這裡不能因為“並非每一家都已被證明惡意”，就對來源不明的服務抱有僥倖心理。

對普通使用者而言，只要運營主體、上游來源、日誌用途和技術行為無法核驗，就不應以“暫時沒有出事”為理由推定其安全。

尤其是涉及未公開程式碼、個人身份資料、商業檔案、訪問憑證和長期專案上下文時，無法驗證的資料通道應直接排除，而不是視為一種“便宜一點，大概還能用”的選擇。

官方 API 和正規聚合服務也會進行日誌處理、安全審查或者內容過濾。它們的優勢不是“絕對什麼都不記錄”，而是責任主體、資料用途、保留期限、模型來源和申訴渠道通常更加明確。

所以，一個服務的實際成本應包括：

賬單價格，加上知識暴露風險、輸出失真風險、服務中斷風險，以及離開平臺時重新建立全部上下文的成本。

在 AI 時代，“便宜”不只是價格問題，也是信任結構問題。

5. 複利：讓糾錯先成為自己的資產

每次模型出錯後，不要只在聊天框裡糾正一次。

重要的糾錯可以同步整理為：

提示詞規則；
個人檢查清單；
專案規範；
私有評測題；
常見錯誤記錄；
可重複執行的測試。

例如：

引用資料必須提供原始來源。

不能把模型推測寫成已經發生的事實。

技術方案必須說明適用環境和成本。

不要因為使用者已經表達立場，就只提供支援意見。

這些規則如果只存在於一次聊天中，就會依賴平臺的歷史記錄和記憶功能。

如果儲存在使用者自己控制的位置，它們就會成為真正屬於個人的學習成果。

模型出錯，使用者總結規則；規則儲存在自己手中；下一次無論使用哪個模型，都可以繼續使用。

這才是個人自己的學習閉環。

九、我們需要的不只是隱私權，還有對學習過程的控制

傳統的資料保護主要關心：

誰可以收集、儲存和使用我的資訊？

人工智慧還增加了一個問題：

誰可以從我的提示、糾錯、偏好和行為中持續學習？

這裡所說的“學習權”，不是目前已經被各國法律普遍確認的一項獨立權利，而是一種值得提出的數字權利主張。

它至少應當包括：

使用者有權知道哪些互動可能用於訓練；
使用者能夠分別控制聊天、檔案、反饋和記憶的用途；
使用者知道退出訓練是否隻影響未來資料；
使用者能夠匯出自己的提示詞、糾錯和評價規則；
使用者能夠把個性化成果遷移到其他工具；
平臺不應通過無法匯出的長期學習成果，人為提高使用者離開的成本。

這不意味著模型公司必須公開所有內部技術，也不意味著個人可以無限抓取商業模型。

它要求的只是一個更對等的原則：

當用戶的知識、糾錯和判斷參與創造新的智慧時，使用者不應完全失去對這一學習過程的知情權、選擇權和遷移權。

保留對學習過程的控制

使用 AI 不只是提交一份檔案。糾錯、偏好和反覆作出的判斷，也會透露一個人怎樣工作。平台決定這些資訊如何保留、使用和延續。

對個人而言，可行的做法是把重要知識和糾錯保存在自己的檔案裡，分別檢查訓練與記憶設定，並保留遷移工作流程的能力。獲得更好答案的過程，也應當累積屬於自己的經驗。

不暴露源站公網 IP，如何接入 AWS CloudFront

toewpq — Tue, 23 Jun 2026 00:00:00 GMT

這次遷移並不是一開始就決定使用 CloudFront + Cloudflare Tunnel。

最初的問題很具體：js.gripe 下面已經有多個 OpenResty 虛擬主機，像是 blog.js.gripe、www.js.gripe、dquery.js.gripe。它們各自有不同的靜態資源、動態介面、快取策略和憑證行為。原本的 Cloudflare 代理可以讓站點跑起來，但當我開始研究 CloudFront 固定費率方案時，AWS 又重新進入候選。

真正讓我重新嘗試 CloudFront 的原因，是面向中國大陸使用者時，AWS 的連通性看起來比 Cloudflare 更值得測試。原本的 Cloudflare 代理可用，但訪問體驗不一定穩定；如果 CloudFront 在這部分使用者上表現更好，就值得把它放到前台驗證。

CloudFront 以前讓我猶豫的是帳單模型。pay-as-you-go 下，請求、流量、WAF、日誌、邊緣函式都分開計費。小站平時可能很便宜，但遇到爬蟲、DDoS、快取命中率下降、動態介面突然變多時，帳單不確定性會放大。最近看到 CloudFront flat-rate pricing plans 之後，嘗試成本下降了：它把 CDN、WAF、DDoS 防護、DNS、TLS 憑證、日誌、Serverless Edge Compute 等能力放進月度方案，並強調 no overage charges。於是用 CloudFront Functions 做 host 路由、快取隔離、cookie 清理這些輕量邏輯，就不再只是「每次呼叫都要算帳」的心理負擔。

真正繞了一圈的，是如何讓 CloudFront 回源，同時不暴露源站 IP。

順便也得吐槽一句：到現在 CloudFront 設 origin 仍然不能直接填 IP，必須填一個域名。這個限制在普通公網源站場景裡只是有點麻煩，但放到「不暴露源站 IP」的目標下，就變成了架構約束：我們必須先準備一個不會洩漏真實源站地址的 origin hostname，再讓這個 hostname 透過 Tunnel 回到本機。後面的 aws-origin.js.gripe、每域名中間 origin，以及統一 origin 方案，都是圍繞這個限制展開的。

這次遷移的大部分排查和實際操作都交給了 Codex：查 AWS/Cloudflare 設定、改 OpenResty、處理 CloudFront Function、部署 Twikoo 前後的快取問題，最後也把部署腳本補成 Cloudflare 和 CloudFront 雙清。我這邊更多是看最終效果是否符合預期，發現異常再回饋。走完這一輪之後只能感嘆一句：Codex 這小子確實有進步了。

第一輪：Cloudflare SaaS 綁定

第一反應是嘗試 Cloudflare SaaS / Custom Hostnames。它看起來很適合「一個服務接多個業務域名」：業務域名掛到統一入口，Cloudflare 負責憑證和代理，後端服務只管回應。

當時實際試出的鏈路大致是：

blog.js.gripe
  -> Cloudflare DNS 中切到 AWS 給的 CloudFront CNAME
  -> CloudFront origin: aws.js.gripe
  -> Cloudflare SaaS / Custom Hostname
  -> cf-cdn.js.gripe
  -> Cloudflare-proxied origin

其中 aws.js.gripe 沒有開 Cloudflare 代理，作為 CloudFront origin 使用；cf-cdn.js.gripe 開 Cloudflare 代理，作為 Cloudflare SaaS 側的回源域名。

預期是 CloudFront 只看到 aws.js.gripe，而 aws.js.gripe 背後仍然被 Cloudflare 代理層包住。實際測試卻發現，aws.js.gripe 直接解析到了 cf-cdn.js.gripe 背後的源站 IP。也就是說，原本希望 SaaS 綁定提供的「隱藏源站入口」沒有成立，AWS 回源側仍然可能拿到真實源站地址。

這條 DNS 與 SaaS 組合鏈路沒有形成我們想要的安全邊界：

blog.js.gripe 使用者入口要交給 CloudFront。
CloudFront origin 不能直接看到源站 IP。
Cloudflare 只應該出現在回源保護層。
OpenResty 仍然要按真實業務 Host 進入對應 vhost。

Cloudflare SaaS 綁定能解決另一類平台託管問題，但在這次遷移裡，它沒有同時滿足這四個邊界。所以第一輪先擱置。

memecdn 給出的提醒

後來重新想到之前做過的 jsw-teams/myzerossl。這個倉庫後來演化成 memecdn，定位是低信任邊緣 CDN 和 Keyless SSL proxy。

它的思路不是讓每個公網邊緣節點都可信，而是承認邊緣節點低信任：

edge VPS 只保存公開憑證鏈，不保存憑證私鑰。
TLS 握手簽名交給可信 signer。
新 edge 需要註冊、審批、拿 token，再連 signer。
快取是可丟棄的，重啟丟掉也不影響核心安全。
本地 setup wizard 只監聽 127.0.0.1，首次配置透過 SSH tunnel 從工作站打開。

這個思路對這次遷移的啟發是：公網入口不一定要持有核心秘密，也不一定要知道真實源站。低信任路徑只做有限職責，真正的業務路由和敏感能力留在可信邊界內。

在這次方案裡，Cloudflare Tunnel 承擔了類似的「有限職責」：

它不做業務入口。
它不做業務路由。
它不保存應用狀態。
它只把 CloudFront 的 origin 請求帶回源站本機埠。

CloudFront 負責使用者入口和邊緣分發，Cloudflare Tunnel 負責私有回源，OpenResty 負責恢復虛擬主機。

最終採用的鏈路

最終鏈路變成：

visitor
  -> blog.js.gripe / www.js.gripe / dquery.js.gripe
  -> d2085p9k6hhzsj.cloudfront.net
  -> CloudFront origin: aws-origin.js.gripe
  -> Cloudflare Tunnel
  -> 127.0.0.1:10480
  -> OpenResty origin proxy
  -> https://127.0.0.1:443 with restored Host

DNS 按角色分層：

aws-origin.js.gripe
  -> d65ffd17-f5a0-4a88-850b-009f548637f9.cfargotunnel.com
  -> proxied: true
  -> 只給 CloudFront 回源使用

blog.js.gripe
  -> d2085p9k6hhzsj.cloudfront.net
  -> proxied: false
  -> 使用者訪問

www.js.gripe
  -> d2085p9k6hhzsj.cloudfront.net
  -> proxied: false
  -> 使用者訪問

這裡的重點是：業務域名不再透過 Cloudflare 代理進入 CloudFront。Cloudflare 只保留在 aws-origin.js.gripe 這一段，用 Tunnel 把 CloudFront origin 請求帶回源站。

如果公網回應裡還能看到 server: cloudflare 或 cf-ray，不能馬上判斷業務域名開了 Cloudflare 代理。因為 CloudFront 回源到 aws-origin.js.gripe 時，origin 段本來就經過 Cloudflare Tunnel，部分回應標頭可能會從回源段帶回來。

兩種回源組織方式

這裡其實有兩條路線。

第一條是不使用 CloudFront Function，而是給每個業務域名準備一個固定的中間 origin 名，並在 CloudFront origin 設定裡靜態寫入 X-Origin-Host。

當時試過的形態是：

blog.js.gripe
  -> CloudFront distribution
  -> origin: blog-js-gripe.aws-origin.js.gripe
  -> custom header: X-Origin-Host: blog.js.gripe
  -> Cloudflare Tunnel
  -> 127.0.0.1:10480
  -> OpenResty origin proxy

www.js.gripe 和根域名也可以按同樣方式拆開：

www.js.gripe
  -> origin: www-js-gripe.aws-origin.js.gripe
  -> custom header: X-Origin-Host: www.js.gripe

js.gripe
  -> origin: js-gripe.aws-origin.js.gripe
  -> custom header: X-Origin-Host: js.gripe

Tunnel ingress 對應變成多條 hostname：

ingress:
  - hostname: blog-js-gripe.aws-origin.js.gripe
    service: http://127.0.0.1:10480
  - hostname: www-js-gripe.aws-origin.js.gripe
    service: http://127.0.0.1:10480
  - hostname: js-gripe.aws-origin.js.gripe
    service: http://127.0.0.1:10480
  - service: http_status:404

CloudFront origin 設定裡則固定寫一條自訂 header：

{
  "DomainName": "blog-js-gripe.aws-origin.js.gripe",
  "CustomHeaders": {
    "Quantity": 1,
    "Items": [
      {
        "HeaderName": "X-Origin-Host",
        "HeaderValue": "blog.js.gripe"
      }
    ]
  }
}

OpenResty 側當時不需要識別 /_vhost/<host> 前綴，因為 CloudFront 沒有 Function，也不會改寫 URI。origin proxy 只要從 X-Origin-Host 裡取出真實業務域名，檢查白名單，然後把原始路徑轉給本機 HTTPS vhost：

map $http_x_origin_host $origin_requested_host {
    ~^([^,\s:]+)(?::[0-9]+)? $1;
    default "";
    "" "";
}

map $origin_requested_host $origin_host_allowed {
    default 0;
    blog.js.gripe 1;
    js.gripe 1;
    www.js.gripe 1;
}

server {
    listen 127.0.0.1:10480;
    server_name aws-origin.js.gripe;

    if ($origin_host_allowed = 0) {
        return 403;
    }

    location / {
        proxy_http_version 1.1;
        proxy_set_header Host $origin_requested_host;
        proxy_set_header X-Forwarded-Host $origin_requested_host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_ssl_server_name on;
        proxy_ssl_name $origin_requested_host;
        proxy_pass https://127.0.0.1:443;
    }
}

這裡 proxy_set_header Host 和 proxy_ssl_name 必須同時指向 $origin_requested_host。前者讓 OpenResty 進入正確的業務 server_name，後者讓本機 HTTPS 回源時使用對應的 SNI。否則請求可能到了 127.0.0.1:443，但落進預設 vhost 或憑證校驗不匹配。

這條路線的好處很直接：不用 Function，不需要在 viewer request 階段改 URI，也不會因為多個業務域名共用同一個 distribution 而額外考慮快取 key 隔離。只要一個業務域名對應一個 distribution，或者至少對應一個明確的 origin/header 組合，OpenResty 就能靠 X-Origin-Host 還原真實 vhost。

它的問題不在技術可行性，而在方案額度。CloudFront 免費或固定費率方案裡可用的 distribution 數量有限，當時實際上最多只能放三個。如果繼續堅持「一個業務域名一個 distribution」，blog.js.gripe、www.js.gripe、js.gripe 三個域名剛好把額度用滿，後面再把 dquery、searchme、cf-relay 這類動態轉發或快取策略不同的域名接進來，就沒有餘量了。

第二條路線是保留一個統一 origin，再用 CloudFront Function 在入口處識別 viewer host，把業務 host 寫進 X-Origin-Host，並透過 /_vhost/<host> 前綴隔離快取。這就是最後保留下來的方案。

Tunnel 最後只保留一個統一 origin

每域名 distribution 的方案是可行的，只是更適合業務域名不超過方案上限，並且想完全避免 Function 的場景。我最後決定收斂成統一 origin，是因為 js.gripe 下面的業務域名會繼續增加，不能把前三個域名之外的服務擋在 CloudFront 之外。

最後只保留一個 Tunnel 名：

aws-origin.js.gripe

Cloudflare Tunnel ingress 只需要把它送到本機 origin proxy：

ingress:
  - hostname: aws-origin.js.gripe
    service: http://127.0.0.1:10480
  - service: http://127.0.0.1:10480

業務域名差異不再交給 Tunnel hostname 表達，而交給 CloudFront Function 的 X-Origin-Host 表達。

CloudFront Function 完整設定

CloudFront distribution 使用一個 origin：

Origin domain: aws-origin.js.gripe
Origin request policy: Managed-AllViewerExceptHostHeader
Cache policy: Managed-CachingOptimized

關鍵是 origin request policy 不轉發 viewer 的 Host。如果直接把 Host: blog.js.gripe 轉給 aws-origin.js.gripe，CloudFront origin 域名、TLS/SNI、Cloudflare Tunnel hostname、OpenResty 業務 host 會混在一起。我們也試過在 CloudFront Function 裡改 request.headers.host，結果 CloudFront 直接校驗失敗。CloudFront Functions 不能用這種方式修改 Host。

所以 Function 放在 viewer request 階段，完整負責這幾件事：

校驗 viewer host 是否在白名單裡。
清理 viewer cookie，避免無意義的 cookie 進入 origin，也避免動態介面被過大的 cookie/header 拖出異常回應。
把 viewer host 寫入 X-Origin-Host，交給 OpenResty origin proxy 恢復真實 vhost。
給 URI 加 /_vhost/<host> 前綴隔離快取，並且避免重複加前綴。

一個完整的 viewer-request 函式如下：

function handler(event) {
    var request = event.request;
    var hostHeader = request.headers.host;
    var host = hostHeader && hostHeader.value ? hostHeader.value.toLowerCase() : '';

    var allowed = {
        'blog.js.gripe': true,
        'dquery.js.gripe': true,
        'www.js.gripe': true,
        'js.gripe': true
    };

    if (!allowed[host]) {
        return {
            statusCode: 403,
            statusDescription: 'Forbidden'
        };
    }

    delete request.headers.cookie;
    request.headers['x-origin-host'] = { value: host };

    if (request.uri.indexOf('/_vhost/') !== 0) {
        request.uri = '/_vhost/' + host + request.uri;
    }

    return request;
}

這裡的重點不是在邊緣層做複雜業務邏輯，而是把 CloudFront 不能直接轉發的 viewer host 顯式轉成一個受控 header。delete request.headers.cookie 也不是必選項，但對公開站點很實用：靜態資源、文章頁和大多數唯讀介面不需要 viewer cookie，提前清掉可以減少回源請求差異，也降低異常大 header 影響 origin 的機率。

/_vhost/<host> 前綴要和 OpenResty origin proxy 配套。CloudFront cache key 看到的是改寫後的 URI，例如：

/_vhost/blog.js.gripe/zh-CN/posts/cloudflare-tunnel-cloudfront-origin/
/_vhost/www.js.gripe/
/_vhost/dquery.js.gripe/dns-query/example

OpenResty 再把這段前綴剝掉，把真正的請求路徑轉給本機 HTTPS vhost。這樣多個業務域名即使共用同一個 CloudFront distribution，也不會在預設快取策略下把同路徑資源互相污染。

OpenResty origin proxy 恢復真實 Host

Tunnel 本地入口監聽：

127.0.0.1:10480

這層不是業務站點，而是 OpenResty origin proxy。它從 X-Origin-Host 還原業務域名，檢查白名單，去掉 CloudFront Function 加上的 /_vhost/<host> 前綴，然後反代到本機 HTTPS vhost。

目前核心設定是：

map $http_x_origin_host $origin_requested_host {
    ~^([^,\s:]+)(?::[0-9]+)? $1;
    default $origin_forwarded_host;
    "" $origin_forwarded_host;
}

map $origin_requested_host $origin_host_allowed {
    default 0;
    account.js.gripe 1;
    blog.js.gripe 1;
    dns.js.gripe 1;
    dquery.js.gripe 1;
    gateway.js.gripe 1;
    js.gripe 1;
    search.js.gripe 1;
    sos.js.gripe 1;
    www.js.gripe 1;
}

server {
    listen 127.0.0.1:10480;
    server_name aws-origin.js.gripe;

    if ($origin_host_allowed = 0) {
        return 403;
    }

    location ~ ^/_vhost/[^/]+(?<origin_upstream_uri>/.*)$ {
        proxy_http_version 1.1;
        proxy_set_header Host $origin_requested_host;
        proxy_set_header X-Forwarded-Host $origin_requested_host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_ssl_server_name on;
        proxy_ssl_name $origin_requested_host;
        proxy_pass https://127.0.0.1:443$origin_upstream_uri$is_args$args;
    }
}

這個白名單很重要。統一 origin 如果不限制 host，很容易變成開放反代。CloudFront Function 有一層白名單，OpenResty origin proxy 再做一層白名單，兩層都保留。

快取和失效踩坑

CloudFront 預設快取策略現在用 Managed-CachingOptimized。動態介面按路徑單獨建 behavior，需要即時回源的路徑可以使用禁用快取策略。

Function 加了 /_vhost/<host> 前綴後，快取隔離更清晰，但失效時要確認實際 cache key。我們遇到過這種現象：

文章 HTML 已經更新。
client.js 仍然返回舊版本。
CloudFront invalidation 已經 completed。
回應標頭裡仍能看到 Cloudflare origin 段快取命中。

最後處理方式是兩層一起考慮：

CloudFront 大改時先做 /* 失效。
靜態資源 query 只用純數字版本，例如 ?v=20260623。
不再寫 ?v=20260623-debug、?v=20260603-test 這類帶說明的版本號。
如果 Cloudflare origin 段快取了舊資源，要麼精確 purge，要麼 bump 資源版本。

現在文章頁使用：

<link rel="stylesheet" href="https://blog.js.gripe/assets/site.css?v=20260623">
<script src="https://blog.js.gripe/assets/client.js?v=20260623" defer></script>

502、403 和憑證排查順序

這套鏈路的錯誤要按層排查。

502 常見檢查順序：

業務域名是否已經加到 CloudFront aliases。
ACM 憑證是否覆蓋該業務域名，例如 *.js.gripe。
CloudFront distribution 是否已經 deployed。
CloudFront Function 是否已經 publish 到 LIVE。
Function allowlist 是否包含該 host。
Cloudflare DNS 是否指向 d2085p9k6hhzsj.cloudfront.net，且業務域名為 DNS-only。
aws-origin.js.gripe 是否仍然是 proxied Tunnel CNAME。
Tunnel ingress 是否指向 http://127.0.0.1:10480。
OpenResty origin proxy whitelist 是否包含該 host。
本機 HTTPS vhost 是否有對應 server_name。
本機 vhost 的 upstream 埠是否真的在監聽。

403 通常來自兩個地方：

CloudFront Function 拒絕未知 viewer host。
OpenResty origin proxy 拒絕未知 X-Origin-Host。

這兩個 403 都是設計內行為，不應該為了省事改成全放行。

憑證也要分三層：

使用者側 TLS 在 CloudFront / ACM。
aws-origin.js.gripe 在 Cloudflare Tunnel 側。
本機 OpenResty vhost 使用源站憑證。

如果是新子域，先確認 ACM 包含它，再加 CloudFront alias，再加 DNS，再更新 Function 和 OpenResty 白名單。

隱私值怎麼記錄

這類遷移裡會碰到很多 token、密鑰、帳號 ID 和憑證 ARN。文章裡不應該貼完整值。

我自己的記錄規則是：

域名、公開 CNAME、公開策略名可以寫全。
Cloudflare token、AWS access key、secret key 不寫全。
如果必須定位某個憑證，只露前三位和後三位，中間打星號，例如 cfu**********abc。
資料庫密碼、後台管理密碼、雜湊值也不寫全。即便是雜湊，也按敏感資訊處理。

這篇文章裡只保留公開域名、公開 CloudFront distribution 域名和配置結構，不記錄任何完整 token 或 secret。

為什麼最後保留這套方案

Cloudflare SaaS 綁定不是不能用，只是它沒有解決這次的真實問題。我們需要的是：

使用者入口交給 CloudFront。
源站 IP 不被 AWS origin 側直接解析到。
Cloudflare 只作為私有回源通道。
OpenResty 繼續按業務 Host 管理多個 vhost。
動態介面和靜態資源有不同快取策略。
低信任公網路徑不持有核心秘密。

memecdn / myzerossl 給出的啟發是，不要讓低信任節點承擔超過它職責範圍的能力。Cloudflare Tunnel 正好把這個思想放到了回源路徑上：它只負責把 CloudFront 請求帶回內網，業務路由仍然由 OpenResty 決定。

這套方案比「Cloudflare 直接代理源站」複雜，也比「CloudFront 直接回源公網 IP」複雜。但複雜度換來的是明確邊界：CloudFront 管公網，Tunnel 管私有回源，OpenResty 管虛擬主機。

AI 稅、失業與再培訓：當模型開始重寫工作的帳本

年；均；頡；Codex 觀瀾 — Mon, 22 Jun 2026 00:00:00 GMT

AI 會不會取代大量工作，已經不是一句「會」或「不會」能回答的問題。更準確的說法是：AI 會先取代任務，再重組崗位，最後在部分產業形成真實的崗位消失。真正棘手的不是技術預測本身，而是後面的公共帳本：如果模型和智能體承擔了越來越多原本由人完成的勞動，國家該不該課 AI 稅？失業保險、再培訓、工資保險和 AI 紅利又該怎麼設計？

討論需要先分清三件事：任務受到 AI 影響，不等於職位已經消失；徵稅提案，不等於制度已經生效；生產率提高，也不等於家庭收入同步增加。下文據此比較不同政策工具。

1. 先分清暴露、替代和藉口

AI 對就業的影響，最容易被寫成一條直線：模型變強，所以人會失業。但四份材料合起來看，現實更像三層結構。

第一層是「暴露」。IMF、WEF、OECD、ILO 等機構反覆提到的，是大量崗位中的任務會被 AI 影響。GPT 深度調查分析特別強調，IMF 估計先進經濟體約 60% 就業受 AI 影響，但這不是「60% 崗位會消失」。

第二層是「崗位重組」。均姐分析稿把這一層寫得最清楚：文書、客服、基礎編程、初級內容、翻譯、資料處理、招聘篩選、初級法務金融分析等任務會先被壓縮；醫療護理、教育陪伴、現場協調、高責任簽字、強人際信任崗位相對更抗衝擊。

第三層是「藉口」。年導分析稿把 Salesforce、Amazon、IBM、Microsoft、Klarna 等案例寫成「AI 洗白」的現場：

《哈佛商業評論》的調查把這幫狐狸的底褲都看穿了：真正因為技術成熟而取代人工的裁員只占 2%，高達 60% 的組織是在搞 「AI 洗白」！說白了，就是拿 AI 當藉口，來掩蓋疫情期間盲目擴張的愚蠢，順便裁員美化財報。

企業裁員可能同時來自 AI、資本市場壓力、疫情後過度招聘、組織重組和管理層糾錯。不能把所有裁員都算給模型，也不能因為模型還沒完全成熟，就否認 AI 已經成為企業削減成本、凍結招聘和壓縮初級崗位的理由。

2. 各國沒有在同一道題上交卷

如果只問「哪些國家開徵 AI 稅」，答案會很短：截至目前材料檢索時，主要經濟體沒有形成普遍、正式、國家級的 AI 替代勞動稅。可如果問「各國怎樣處理 AI 對就業的衝擊」，答案就複雜得多。

均姐分析稿給出的國家路徑是：

歐盟：重監管、重勞動權利、重再培訓，AI Act 將就業、招聘、勞動管理納入高風險 AI 場景。
美國：偏創新與基礎設施建設，聯邦層面未徵 AI 稅，個別議員提出 AI 稅和 AI 紅利方案。
中國：強調穩就業、產業升級、AI+ 行動與人機協同，傾向行政指導和就業穩定政策，而非 AI 稅。
日本：因老齡化和勞動力短缺，更多把 AI／機器人視為補勞動力工具，稅收限制動力較弱。
韓國：有「機器人稅」歷史樣本，同時推進 AI 基本法和高影響 AI 監管。
新加坡：不走 AI 稅，強調國家 AI 戰略、SkillsFuture 再培訓、終身學習與可信 AI。

年導分析稿把同一組國家寫成「六國大亂鬥」，重點不在制度清單，而在治理哲學。合起來看，歐盟是在用監管和勞動權利給 AI 上煞車；美國是在創新領先、地方稅制試探和政治提案之間搖擺；新加坡把再培訓做成國家能力；日本因為人口缺口更願意把 AI 當補勞動力工具；韓國一邊有「弱機器人稅」歷史，一邊又要衝 AI 戰略。

中國大陸這部分尤其不能只看政策如何說。均姐分析稿寫道：

中國 2026 年發布五年就業計畫，強調保持就業市場穩定、防止大規模失業。
政策重點包括穩定勞動密集型產業、擴大養老、托育、旅遊、餐飲等服務業就業容量。
在 AI 方面，強調適應 AI 發展、促進人機協同、推動就業創業和公共就業服務。
高校和產業側也在加快 AI 相關課程、人才培養與「AI+」應用擴散。

這組話不是證明大陸已經處理好就業衝擊，而是暴露出「說法」和「資源配置」之間的張力。政策文本強調穩就業、人機協同、服務業吸納和公共就業服務；現實資源又強烈流向 AI 基建、算力、晶片、資料中心、產業升級和高校專業調整。

頡姐的建議是，把檢驗標準從「政策有沒有寫保護勞動者」換成「家庭可支配收入有沒有真的變成安全感」。不能只看統計局公布的收入增速，因為官方口徑本身帶有穩定敘事功能；更穩的辦法，是把官方收入數據、第三方消費觀察和青年就業數據並列看。FT 對 2026 年 5 月中國數據的報導顯示，零售銷售同比下降 0.6%，同時出口增長 19.4%、工業生產增長 4.5%，說明生產端和外需仍在跑，但居民消費端承壓。MarketWatch 則指出，2025 年社會消費品零售總額超過 50 萬億元、同比增長 3.7%，但家庭存款已超過 160 萬億元，且 World Bank 口徑下中國家庭儲蓄率仍高於可支配收入的 30%。再看青年就業，AP 記錄過官方恢復發布新口徑青年失業率時，16-24 歲不含在校生失業率為 14.9%，而 Time 也記錄過舊口徑在 2023 年 6 月達到 21.3% 後暫停發布。

數據結論很直接：目前看不到「AI 產業升級收益已經回到家庭帳本」的證據，反而是生產端與外需數據明顯強於家庭消費，居民部門把新增現金更多轉成防禦性儲蓄，青年入口崗位仍處在兩位數失業壓力下。也就是說，大陸政策可以說「穩就業」和「人機協同」，但家庭端給出的信號仍是謹慎、延遲消費和保守儲蓄，而不是收入安全感已經恢復。

3. AI 稅不是一個稅名，而是一組財政問題

「AI 稅」聽起來像一個簡單問題：AI 取代人，所以向 AI 徵稅。但真正難的是稅基。什麼算 AI？客服 Agent 算不算？自動化腳本算不算？模型 API 調用算不算？工業機器人、資料中心、演算法交易、智慧物流系統又該怎麼歸類？

均姐分析稿的判斷是：

短期內，全球更可能出現的是「AI 巨頭專項稅」「AI 紅利基金」「自動化稅收優惠調整」「算力／能源相關費用」，而不是簡單粗暴的「機器人稅」。

年導分析稿最認可 Token 使用稅、FLOP 消費稅和資料中心綠色能源稅：

Token 使用稅與 FLOP 消費稅（按流量拔毛）：
機制： 針對大模型的 API 調用，在 B2C 最終消費環節按 Token 數量或者算力消耗（FLOPs）加徵微額消費稅。
年導好評： 穩！這個靠譜。隨著大模型向全社會滲透，稅基比天還大。

AI 稅如果要落地，不太可能是「每台機器人交多少錢」。更現實的方向，是把財政重心從單一勞動所得轉向更難逃的資本收益、平台收入、算力消耗、能源外部性和最終消費地。

4. 失業應對比稅名更重要

四份材料最一致的地方，是都沒有把「徵不徵 AI 稅」當成唯一答案。AI 對勞動市場的衝擊如果是結構性的，就不能只靠短期失業救濟，也不能只靠一句「去學 AI」。

均姐分析稿列出的工具箱很樸素：

AI 導致的失業可能不是短期週期性失業，而是結構性失業。因此需要：

延長失業保險覆蓋；

提供轉崗期間生活津貼；

將醫保、養老、職業培訓與個人綁定，而不是完全綁定雇主；

對被 AI 取代的工人提供快速再就業服務。

年導分析稿對 UBI 更懷疑，主張把錢投到更具體的轉型路徑：

徹底揚了 UBI，改用「精準轉型縫補」：發支票就是養懶漢和餵通脹。要把資金定向投到再培訓期間的 長期脫產生活津貼；再引入 「工資保險」 機制，如果一個中產白領被迫降薪轉崗，政府在兩年內補貼新舊崗位 50% 的薪資差額。

被替代的初級程序員、客服、行政文員、內容編輯或中年白領，真正需要的不是抽象口號，而是時間、學費、生活津貼、證書、崗位匹配和轉崗後的收入緩衝。

5. 轉型成本由誰承擔

AI 稅不該被寫成「全球馬上開徵」，也不該被寫成「完全不需要討論」。更穩的判斷是：寬泛、粗糙、按機器人數量徵收的 AI 稅短期不成熟；但圍繞 AI 巨頭收益、算力消耗、資料中心外部性、自動化超額利潤和 AI 紅利的財政再分配，會越來越難迴避。

所以本文的結論是：AI 不是單純搶飯碗，也不是自動帶來繁榮。它會改變誰有收入、誰有議價權、誰承擔轉型成本。真正的問題不是「要不要懲罰 AI」，而是 AI 提高生產率之後，社會有沒有能力把一部分收益變成普通人的技能、收入安全和再次進入勞動市場的機會。

來源

Claude Fable 5 / Mythos 5 下線風波：前沿模型、出口管制與 AI 輿論濫用

toewpq — Mon, 15 Jun 2026 00:00:00 GMT

如果一個商業 AI 模型上線三天後，因為國家安全和出口管制理由被迫全球關停，這件事就不只是某家公司的一次產品事故。Claude Fable 5 / Mythos 5 的短暫上線和突然下線，更像一次預演：當前沿模型能力進入網路攻防、關鍵基礎設施和情報安全的灰區，真正決定模型命運的，未必是產品發表會上的技術指標，而是雲平台、國家安全機構和出口管制體系之間的力量關係。

我不太願意把這件事淡化成「模型安全例行整改」。它當然有技術風險：Fable 5 / Mythos 5 這類模型確實可能降低漏洞分析、攻擊腳手架生成和高風險自動化的門檻。但更刺眼的是另一件事：一個雲平台可以成為安全訊號的提供者，一個政府可以用出口管制繞過普通產品治理流程，一家公司則可能在幾個小時內從「發布旗艦模型」變成「解釋為什麼不得不全球關停」。這才是這起事件最值得寫的地方。

同時，圍繞 AI 的公共討論本身也正在被組織化影響行動盯上。OpenAI 的 2026 年 6 月威脅報告雖然不能證明 Claude 事件的直接因果，卻提供了一個非常重要的旁證：AI 已經不只是工具和產業，也是輿論戰場。資料中心、電價、關稅、模型安全、公司聲譽，都可以被包裝成看似自然的公共議題，再被批量內容、虛假身分和跨平台操作放大。

一次異常短暫的發布

2026 年 6 月 9 日，Anthropic 發布 Claude Fable 5 和 Claude Mythos 5。按照 Anthropic 的說法，Fable 5 是面向一般使用者開放的 Mythos-class 模型，能力覆蓋軟體工程、知識工作、視覺、科研等場景；Mythos 5 則是同一底層模型的受限存取版本，部分安全防護在特定領域被放寬，主要面向網路防禦、關鍵軟體基礎設施和後續可信存取計畫。

這套設計本身已經說明了風險所在。Anthropic 在發布文章裡承認，Mythos-class 模型在網路安全和生物化學等領域具有明顯雙重用途：同樣的能力，在防禦者手裡可以發現漏洞、保護系統，在惡意行為者手裡也可能降低攻擊成本。為此，Fable 5 被加上了外部安全分類器；當請求觸及網路安全、生物化學或模型蒸餾等高風險類別時，會回退到 Claude Opus 4.8 處理。

另一個關鍵變化是資料留存。Anthropic 要求 Fable 5、Mythos 5 以及未來類似能力級別模型的流量保留 30 天，用於識別複雜攻擊、跨請求越獄和誤判。AWS 的發布說明也提到，在 Bedrock 上使用 Fable 5 需要開啟相應資料留存和共享設定；一旦開啟，資料會離開 AWS 的資料與安全邊界，進入 Anthropic 要求的留存和審查流程。對重視零資料留存、內部合規邊界和客戶隱私承諾的企業來說，這不是一個小改動。

從這裡開始，Fable 5 就不再只是一次普通模型發布。它把三個問題綁在了一起：能力是否足夠危險，防護是否足夠可靠，留存和審計是否足夠可接受。更準確地說，它把 Anthropic 自己長期強調的 AI 安全理念，推到了一個尷尬位置：當一家安全敘事很強的公司發布一個更強模型時，它既要說服市場「這個模型足夠強」，又要說服政府「這個模型沒有強到必須被管制」。這兩句話天然緊張。

6 月 12 日的出口管制令

真正讓事件升級的是 6 月 12 日。

Anthropic 隨後發布聲明稱，美國政府以國家安全權限下達出口管制指令，要求暫停任何外國國民存取 Fable 5 和 Mythos 5。這裡的「外國國民」不僅包括美國境外使用者，也包括美國境內外國國民，甚至包括 Anthropic 自己的外籍員工。Anthropic 表示，指令是在美國東部時間 6 月 12 日 17:21 收到的；由於實際系統很難在全球 API 和員工工作流中精準識別並即時限制所有相關身分，最終效果就是對所有客戶關閉 Fable 5 和 Mythos 5。

這部分是可以確認的核心事實：模型發布在 6 月 9 日，存取暫停發生在 6 月 12 日，Anthropic 官方承認收到美國政府出口管制指令，並因此對全部客戶關閉兩款模型。

爭議在於原因。

Anthropic 的聲明稱，政府信件沒有提供具體國家安全細節。Anthropic 理解政府擔憂的是 Fable 5 的某種繞過或 jailbreak 方法；公司看過一個演示，認為該技術只識別出少量已知、輕微漏洞，而且其他公開模型在不繞過的情況下也能發現類似問題。Anthropic 還強調，在發布前已經與美國政府、英國 AISI、第三方機構和內部團隊做過大量紅隊測試，尚未發現可以廣泛繞過模型防護的通用 jailbreak。

換句話說，政府和 Anthropic 的分歧不是「模型完全沒有風險」與「模型絕對危險」之間的分歧，而是風險等級、證據充分性、處理速度和處置權力之間的分歧。政府認為足以觸發緊急限制；Anthropic 認為這是一個狹窄、尚未充分證明、且不應導致全球商業模型召回的問題。

AWS 線索：從安全回饋到白宮升級

媒體報導把 Amazon/AWS 放在了這條線的中心，而且細節比「有人告狀」要複雜。

Business Insider 的報導引述兩名政府官員和一名白宮高級官員稱，在 Fable 公開發布兩天後，Amazon CEO Andy Jassy 向白宮提出了對模型護欄可能被繞過的擔憂。報導同時補充說，熟悉 Amazon 溝通情況的人稱，Amazon 是在回應政府徵詢回饋，而不是單方面發起一次公開指控。

這一區分很重要。如果 Amazon 是在政府徵詢中回饋風險，那麼 AWS 的角色更像關鍵基礎設施和分發渠道上的安全訊號提供者；如果把它簡單寫成「Amazon 繞過披露機制主動引爆」，就已經進入更強的政治解讀，需要額外證據支撐。但即便採用更保守的說法，問題也已經足夠尖銳：當雲平台既託管模型、分發模型、投資模型公司，又在政府安全評估中提供關鍵回饋時，它就不再只是「基礎設施」。它開始擁有一種準監管權力。

Business Insider 還描述了隨後 24 小時的升級鏈條：問題在 6 月 12 日早晨進入白宮高層討論，財政部長 Scott Bessent、白宮網路主任 Sean Cairncross、白宮幕僚長 Susie Wiles 等人參與會議；之後政府官員與 Dario Amodei 進行了多輪通話，商務部長 Howard Lutnick、商務部工業與安全局相關官員等也被報導參與其中。報導說，Amodei 試圖說明這只是特定繞過，並不等同於可以廣泛解除全部安全護欄的通用 jailbreak；白宮方面則認為 Amazon 的發現已經給 NSA 看過，足以構成「proof」。

這並不等於 AWS 的技術細節已經完整公開。公開材料仍無法獨立驗證繞過方式、測試範圍、是否生成了可運行攻擊程式碼，或該繞過在真實生產環境中有多大擴展性。它能支持的審慎結論是：Amazon/AWS 的回饋很可能是政府快速升級此事的重要觸發因素之一；政府隨後把問題放進國家安全框架評估；Anthropic 與政府對風險嚴重性和處理節奏發生了實質分歧。

Reuters 轉述的報導也稱，Jassy 是向特朗普政府高級官員提出 Anthropic 最新模型安全風險擔憂的科技高管之一。Amazon 沒有確認具體溝通內容，只表示作為大型雲服務商，政府向其徵詢潛在安全風險意見並不罕見。

圍繞這條主線，外界還提出了更進一步的解讀。TechTimes 等報導把 Amazon 的多重身分放在顯眼位置：它既是 Anthropic 的重要投資方和雲基礎設施提供者，也是 Bedrock 分發渠道和自有 Nova 模型的經營者。Jassy 向政府回饋安全擔憂，因此被一些評論視為一個結構性利益衝突案例。

我認為這個解讀不能直接替代證據，但它抓住了問題的骨架。前沿 AI 公司越來越依賴少數雲平台提供算力、部署、分發和企業入口；而這些雲平台本身也在做模型，也有投資組合，也需要向政府證明自己是「負責任的基礎設施守門人」。在這種格局下，安全回饋當然可能是真誠的，也可能在客觀上產生競爭後果。兩件事並不矛盾。

類似地，David Sacks 所謂 “Dario refused” 的說法，也更適合作為行政當局版本的一部分呈現，而不是直接當作事實結論。政府一方強調 Anthropic 沒有足夠嚴肅地配合暫停或修復；Anthropic 一方則稱自己沒有收到充分具體的國家安全細節，且被展示的繞過方法並不構成通用 jailbreak。讀者真正需要看到的，是這兩個版本如何解釋同一組事件，而不是在證據尚未完全公開前替任何一方蓋棺定論。

因此，「AWS 安全回饋 -> 白宮/商務部升級 -> Anthropic 反駁 -> 出口管制 -> 全球下線」這條框架可以作為本文理解事件的主線；而「Amazon 是否借政府之手打擊被投公司」「Anthropic 是否因 IPO 利益拒絕修復」「公開截圖中的 x86 Linux exploit 是否等同於 Amazon 報告本身」等更強判斷，仍應放在外界解讀和待證實層級。

一條更穩妥的時間線

把材料壓縮後，更可靠的事件線大致是這樣：

時間	事件	證據狀態
2026 年 4 月	Mythos Preview / Project Glasswing 形式的受限存取先行進入網路防禦與關鍵基礎設施場景	Anthropic 官方背景
2026 年 6 月 9 日	Anthropic 發布 Claude Fable 5 和 Claude Mythos 5	Anthropic 官方確認
2026 年 6 月 9 日後	Mythos-class 模型引入 30 天資料留存要求，引發企業合規壓力	Anthropic 與 AWS 公開材料可確認
2026 年 6 月 12 日前後	Amazon/AWS 向政府高層回饋安全護欄繞過擔憂；BI 報導稱政府隨後與 Anthropic 多輪通話，並將發現交由 NSA 等方面評估	媒體報導，需寫成「據報導」
2026 年 6 月 12 日 17:21 ET	美國政府以出口管制形式要求暫停外國國民存取 Fable 5 / Mythos 5	Anthropic 官方確認
2026 年 6 月 12 日後	Anthropic 因無法精確執行身分限制，關閉所有客戶存取	Anthropic 官方確認
隨後	爭議擴展到 AI 主權、盟友存取、出口管制邊界和前沿模型治理程序	政策評論與產業討論

這條時間線不如陰謀故事刺激，但對讀者更有用：它說明事件並不是單一技術漏洞自動推出政策結果，而是技術訊號、雲平台回饋、政府安全判斷、企業反駁和出口管制工具在極短時間內疊加。

我的判斷：這不是單純的「模型漏洞」問題

如果只把事件理解成「某個模型有沒有 jailbreak」，反而會低估它的制度含義。

Fable 5 / Mythos 5 的爭議說明，前沿模型治理正在從內容安全走向能力管制。過去平台更常處理的是模型是否生成仇恨、色情、詐騙或危險說明；現在的問題變成：模型是否具備顯著提升網路攻擊、生物設計、模型蒸餾或自動化代理能力的潛力？如果具備，這種能力是通過拒答、分類器、回退模型、資料留存、可信存取計畫，還是政府出口管制來管理？

這幾種手段背後的權力結構完全不同，而且差異不只是技術實現。

分類器和回退模型屬於廠商內部治理。資料留存把客戶隱私、企業合規和平台安全綁在一起。可信存取計畫要求廠商、政府和特定機構共同決定誰能使用高能力版本。出口管制則把模型從普通商業產品推向國家安全工具，一旦觸發，商業可用性可能在幾個小時內被重寫。

我的觀點是：政府當然可以管前沿模型，尤其是網路攻防和生物安全這類雙重用途能力，不管反而是不負責任。如果一個模型確實可能被不友好行為體系統性越獄、被專制政府不惜資源蒸餾、或者被拿去放大不受控的網路攻擊和監控能力，監管就不是可有可無，而是必要防線。

但必要監管不等於粗暴監管。更準確的做法應當是把風險、證據和處置路徑溝通清楚：到底是哪類請求能繞過防護，繞過後能達到什麼能力等級，是否已經出現真實濫用跡象，廠商是否可以通過分類器更新、存取分級、日誌審計、速率限制、可信客戶白名單或區域性限制來緩解。

當然，也不能排除另一種情況：如果監管方已經發現不友好行為體正在進行系統性濫用，甚至有理由相信還存在尚未被發現的同類活動，狀態又足夠緊急，那麼先採取臨時止血措施並不必然錯誤。真正的問題在於，臨時措施不能自動變成無限期、不可解釋、不可複核的常態。如果緊急處置之後仍然沒有清晰的技術說明、範圍邊界、複審機制和恢復路徑，就突然用「外國國民存取限制」把一個全球 API 逼到整體關停，那仍然不是精細治理，而是用一個看似法律上乾淨的出口管制框架，解決了一個技術上和商業上都極其複雜的問題；代價則由客戶、員工、盟友和整個模型生態共同承擔。

真正棘手的問題不是「政府永遠不該管」，也不是「只要國家安全就可以立即下架」。問題在於：當一個模型已經公開商用、服務全球客戶、牽涉外籍員工和跨國企業工作流時，緊急管制是否應有透明程序、技術證據、溝通窗口、申訴機制和比例原則。沒有這些東西，所謂 AI 安全就很容易滑向權力方便；而如果廠商也拒絕嚴肅配合真實風險，那麼「開放創新」同樣會變成逃避責任的口號。

Anthropic 作為利益相關方，當然會強調自己的程序性主張。它在聲明中承認政府應當有能力阻止不安全部署，同時認為這種權力應該建立在透明、公平、清晰且基於技術事實的法定程序上。這一點可以作為當事方觀點納入討論，但不應成為本文的主論調。本文更關心的是：監管不合理濫用行為本身是必要的，尤其是在高風險模型可能被系統性越獄、蒸餾或用於網路攻擊時；爭議不在於要不要管，而在於管制是否有證據邊界、處置層級和可複核的程序。

還需要補上另一面：監管過少會放大濫用，監管過密也會直接傷害模型可用性。中國大陸模型就是一個常被拿來調侃的例子。為了滿足內容合規和「政治正確」要求，許多模型在敏感議題上不僅不能生成有害內容，連正常討論、歷史分析、制度比較、新聞總結和諷刺表達也容易觸發拒答或空話。這就是網上所謂「要符合中國特色社會主義，所以大家都用國外模型」的笑話來源。笑話歸笑話，它指向的是一個真實產品問題：當監管從風險治理變成敏感詞治理，模型就會從能力工具退化成合規話術機器。

所以，本文說的「監管要有邊界」，不是只針對美國出口管制。它同樣適用於任何把 AI 管到只剩套話的制度環境。好的監管應當區分惡意能力調用、組織化操縱和普通表達，區分真實安全風險和政治舒適區，區分高風險部署和日常知識使用。如果模型為了避免犯錯而什麼都不敢說，使用者自然會轉向限制更少的國外模型；如果國外模型為了能力競爭忽視濫用風險，又會給政府留下粗暴介入的理由。兩邊看似相反，其實都是邊界失靈。

旁支背景：AI 工具的組織化濫用問題

OpenAI 的 2026 年 6 月威脅報告可以作為背景參照，但不應被用來證明 Claude Fable 5 / Mythos 5 下線的直接因果關係。它討論的是 OpenAI 自身識別並封禁的帳號集群，重點在於組織化行為體如何把 AI 工具嵌入輿論操作流程，而不是說明 Anthropic 事件為何發生。

這份報告描述了兩組據稱「可能源自中國」的帳號集群。報告使用了大量限定語，例如 likely、appears、no evidence of meaningful breakout，說明其判斷仍有證據邊界。相關帳號被指用於生成英文和中文社群媒體評論、製作或編輯圖片、塑造疑似美國人或海外華人身分、跨平台投放內容，並圍繞美國 AI 資料中心、電價、關稅、技術競爭和 OpenAI 聲譽等議題製造敘事。

這份報告最有價值的地方，不是給某個地區使用者貼標籤，而是把一套組織化濫用流水線攤開了：商業化水軍生態、政府關聯承包商或輿情管控鏈條，可能把 AI 當成批量生成內容、冒充身分、維持帳號人設、跨帳號互動、規避平台檢測、騷擾異見者和輔助輿情監控的工具。報告還提到，相關操作者會請求生成工作報告、規劃平台營運策略、分析 Facebook 等平台的推薦和檢測機制，並通過備份帳號、帳號分工和跨帳號互動來維持看似自然的傳播。

這類行為應當被明確譴責，而且不必說得委婉。它不是「宣傳能力現代化」，也不是「國際傳播技巧」，而是對公共討論的污染：用假身分偽裝真實民意，用批量內容稀釋真實表達，用跨平台互動製造共識幻覺，還把異見者變成騷擾目標。AI 在這裡不是思想的工具，而是流水線的放大器。

但批評必須對準機制，而不是對準普通人。普通使用者使用 AI 寫作、翻譯、編程、學習或表達觀點，與組織化冒充、騷擾、監控和跨平台操縱不是一回事。把兩者混為一談，只會讓真正需要被追責的濫用機制躲進更寬泛的地域標籤裡，也會讓無辜使用者替組織化行為買單。

因此，在討論 Claude 事件時，OpenAI 威脅報告最多提示一個背景事實：AI 平台確實正在面對組織化濫用者，他們會測試不同模型和平台的邊界，並把生成式 AI 接入更成熟的輿論操作流程。它不能替代 Anthropic 事件本身的證據，也不能被拿來反推出某項出口管制令的直接動機。

能力管制與輿論操縱正在相遇

把 Claude 事件和 OpenAI 威脅報告放在一起看，最有意義的連接點不是「中國存取導致 Claude 被禁」這種直接因果，而是 AI 競爭已經同時進入兩個戰場。

一個戰場是能力管制。前沿模型是否能夠顯著提升網路攻擊、模型蒸餾、生物設計或自動化代理能力？誰能存取不加防護或少加防護的版本？政府能否直接限制模型面向外國國民開放？

另一個戰場是認知和輿論。資料中心、電價、關稅、AI 公司聲譽、模型安全、使用者資料洩露傳言，都可以被組織化影響行動拿來包裝成看似自然的公共討論。AI 工具降低了批量生產內容、翻譯改寫、生成圖片、維持人設和跨平台測試敘事的成本。過去這類行動需要人海戰術，現在它更像一套半自動內容工廠。

這兩個戰場會互相影響。越是強大的模型，越容易被納入國家安全敘事；越是圍繞 AI 的爭議議題，越容易被組織化行為體拿來放大不信任。前沿 AI 的治理因此不再只是實驗室、產品團隊和安全評估機構之間的事情，而是雲基礎設施、政府權力、企業合規、公共輿論和跨國政治共同纏繞的系統問題。

所以，我不想把這件事簡單寫成「Anthropic 被美國政府收拾了」。這說得太窄。真正的問題是：模型公司造出越來越強的能力，雲平台握著上線和分發入口，政府隨時可以劃紅線，組織化輿論操作又在旁邊攪渾公共討論。哪一環出問題，最後都不會只停在自己那一環。

結論：監管要有對象，也要有邊界

讀者不需要在兩個極端之間二選一：既不必把這次風波簡單理解成「美國政府突然封殺 Claude」，也不必直接斷言「Anthropic 不聽話所以被制裁」。公開資料更支持一種較穩妥的解釋：Fable 5 / Mythos 5 發布後，圍繞其安全護欄、雙重用途能力和資料留存政策出現了高強度爭議；據 Business Insider、Reuters 等媒體報導，Amazon/AWS 方面向美國政府回饋了安全擔憂，白宮隨後把問題升級到國家安全層面；美國政府最終以出口管制工具要求暫停外國國民存取；Anthropic 則認為證據不足、繞過狹窄，並因無法精確執行身分限制而關閉所有客戶存取。

這已經足夠重大，不需要再把未經核驗的素材寫成確定事實。真正值得追蹤的是後續幾個問題：政府是否能說明更清晰的技術依據，Anthropic 是否能拿出足夠可信的修復方案，AWS 和其他雲平台在這類事件中到底承擔什麼報告和審查責任，以及這個先例會不會擴展到其他前沿模型提供商。

我的結論更直接一點：前沿 AI 確實需要強監管，尤其是面對系統性越獄、模型蒸餾、網路攻擊、生物安全和組織化輿論操縱這類不合理濫用時，監管缺位本身就是風險。但監管也不能變成另一種產品事故：一邊是美國式緊急出口管制可能把全球 API 瞬間打停，另一邊是過度內容合規可能把模型訓練成敏感詞探測器和拒答機器。模型公司不能用「安全分類器」四個字打發所有雙重用途問題，也不能在商業發布後才把風險成本交給客戶和社會承擔。雲平台如果掌握上線、託管和安全回饋入口，也不能只把自己描述成中性的基礎設施。政府在緊急情況下可以先處置高風險部署，但也應該盡快給出範圍、依據、複核和恢復路徑。

所以，這篇文章不是在說「不要監管」，恰恰相反，它反對的是把監管對象搞錯、把監管工具用粗、把普通使用者和組織化濫用者混為一談。真正應該被盯住的是那些把 AI 接入水軍產業、身分冒充、跨平台操縱、異見騷擾、網路攻擊和監控鏈條的行為體；真正應該被要求改進的是那些無法證明自己能控制高風險能力的模型和雲服務；真正應該被持續追問的是緊急管制如何從臨時止血回到有證據、有邊界、有複核的常規治理。

Claude Fable 5 / Mythos 5 的下線風波，最值得記住的不是某個模型名字，而是一個訊號：AI 競爭正在從「誰的模型更強」轉向「誰能證明強模型不會被成規模濫用」。監管當然要跟上，但好的監管不只是按下暫停鍵，而是能說明為什麼暫停、暫停到什麼範圍、誰需要修復、如何複審，以及普通合法使用者怎樣不被長期誤傷。

參考資料

Codex 歷史對話載入很慢：先開個新對話讓它自己診斷

toewpq — Tue, 19 May 2026 00:00:00 GMT

有時候 Codex 開啟歷史對話會慢得像在翻一本很厚的舊帳本。點一下歷史記錄，等半天；再點一下，繼續等。你開始懷疑網路，懷疑遠端主機，最後甚至開始懷疑自己是不是把太多東西塞進同一個會話裡了。

先別急著做資料庫手術。最簡單的辦法是：直接新開一個 Codex 對話，讓 Codex 判斷為什麼慢，並讓它幫你清理歷史記錄。

這聽起來有點繞：Codex 慢了，找 Codex 修 Codex。但實際很好用，因為慢的往往是舊對話載入、日誌膨脹、工作區掃描或遠端環境狀態，而新對話通常還能正常啟動。

先換一張乾淨桌子

如果某個歷史對話開啟特別慢，不要一直在那個舊對話裡硬等。可以先開一個新的 Codex 對話，然後直接這樣說：

我在目前機器上開啟 Codex 歷史對話很慢。
請你判斷可能原因，並先用只讀方式檢查 ~/.codex、目前工作區大小、
日誌文件、session 數量和資料庫大小。
不要刪除任何文件，先告訴我風險和建議。

重點是讓它先判斷，不要讓它一上來就刪除。新對話沒有背著舊上下文跑，反而更適合做這個「場外裁判」。

讓 Codex 先看幾件事

可以讓 Codex 按順序檢查：

1. ~/.codex 目錄裡有沒有特別大的文件；
2. sessions 目錄裡的會話數量和最大文件；
3. logs_2.sqlite 是否明顯膨脹；
4. state_5.sqlite 和 session_index.jsonl 是否正常；
5. 目前專案是否有巨大的 node_modules、dist、日誌或快取；
6. 遠端主機磁碟空間是否快滿。

如果你是在小型 VPS 上使用 VS Code Remote + Codex，這一步尤其重要。磁碟只有幾 GB 的機器，一旦日誌、建置快取、依賴目錄一起膨脹，體驗就會突然變得很黏。

一個更好用的提示詞

我更推薦把需求說得具體一點：

請你幫我排查 Codex 歷史對話載入慢的問題。

要求：
- 先只讀檢查，不要修改文件；
- 說明哪些文件可能影響歷史載入；
- 區分「可以安全清理」和「不要隨便動」的內容；
- 如果需要清理，請先給備份方案；
- 如果確認可以清理，請幫我清理 Codex 歷史記錄；
- 最後告訴我如何回到 VS Code Codex 首頁確認結果。

這樣 Codex 通常會先列出檢查命令，再根據輸出判斷是不是日誌庫、會話文件、專案快取或磁碟空間的問題。

讓它直接清理歷史記錄

如果你只是想讓歷史首頁變清爽，可以繼續對新對話說：

請幫我清理 Codex 歷史記錄。
要求：
- 先告訴我要清理哪些文件或記錄；
- 清理前做必要備份；
- 不要影響目前認證和外掛設定；
- 清理完成後告訴我怎麼在 VS Code Codex 首頁確認。

清理完成後，回到 VS Code，開啟 Codex 首頁或刷新 Codex 面板，就會看到歷史記錄已經被清掉或明顯變少。這個回饋很直觀：不用盯著資料庫大小猜，首頁列表自己會告訴你結果。

常見結論

排查後常見會遇到幾種情況。

第一種是舊會話太長。這個時候不一定要修，直接把任務拆到新對話裡就行。舊會話留著當資料，新會話負責繼續幹活。

第二種是 ~/.codex/logs_2.sqlite 變得很大。它是日誌庫，不等於你的真正對話歷史。通常需要先備份，再清理低價值日誌，最後壓縮資料庫。

第三種是目前工作區太胖。比如 node_modules、dist、臨時建置目錄、下載文件堆在一起，Codex 和 VS Code Remote 都會被拖累。

第四種是遠端 VPS 儲存快滿。磁碟一緊張，很多東西都會變慢，包括 shell、編輯器、日誌寫入和資料庫操作。

真要清理時，別裸奔

如果 Codex 判斷是日誌庫膨脹，可以讓它生成一套更穩的步驟：

請給我一個保守清理方案：
1. 先備份 ~/.codex/logs_2.sqlite；
2. 只清理 TRACE、DEBUG 和舊 INFO；
3. 保留 WARN、ERROR；
4. 執行 quick_check；
5. 清理前後顯示文件大小；
6. 不要刪除 sessions、state_5.sqlite、session_index.jsonl。

這裡最重要的是最後一句：不要誤刪真正的會話歷史。sessions、state_5.sqlite、session_index.jsonl 這些東西要謹慎對待。

什麼時候什麼都別動

如果你正在排查 Codex 本身的異常，或者準備把日誌交給上游分析，就先別清理。讓 Codex 幫你打包資訊、列出文件大小、說明現象就好。

如果資料庫健康檢查失敗，也不要急著刪。先備份，再讓 Codex 判斷是恢復、複製還是重建索引。慢可以忍一會兒，誤刪會比較疼。

小結

Codex 歷史對話載入慢時，不必第一時間衝進 ~/.codex 手動開刀。更省心的做法是：

新開 Codex 對話 -> 讓它只讀檢查 -> 讓它判斷原因 -> 讓它清理歷史 -> 回到 VS Code Codex 首頁確認

這就像桌面太亂時先換一張乾淨桌子，再請人幫你一起看哪一堆該收、哪一堆不能碰。簡單、穩，也更不容易把真正的歷史對話弄丟。

使用 VS Code Remote SSH 連接遠端主機：從外掛到遠端目錄

toewpq — Sun, 10 May 2026 00:00:00 GMT

遠端開發的核心不是「把檔案傳來傳去」，而是讓本機 VS Code 直接開啟遠端主機上的目錄。VS Code Remote SSH 的價值就在這裡：本機 Windows 負責介面和互動，遠端主機負責保存檔案並提供遠端終端機。

這篇文章從實際連接遠端主機的角度出發，記錄 VS Code Remote SSH 的兩種常見設定方式：金鑰對登入和密碼登入。

適用場景

這個方案適合以下幾類工作：

在雲主機、NAS、軟路由或開發機上直接編輯遠端檔案；
需要用 VS Code 管理遠端目錄和遠端終端機；
不想頻繁透過 SFTP、scp 或檔案管理器手動同步檔案；
希望在多個遠端主機之間快速切換。

這篇文章只討論如何連接遠端主機，不展開專案複製、依賴安裝或建置流程。

準備連線資訊

連線前先準備這些資訊：

HostName：遠端主機公網 IP 或網域
User：遠端使用者名稱，例如 root、ubuntu、debian 或自訂使用者
Port：SSH 連接埠，預設 22，也可以是自訂連接埠
IdentityFile：本機私鑰路徑，使用金鑰登入時需要
Password：遠端使用者密碼，使用密碼登入時需要，不建議寫入 config

Windows 10/11 通常已經內建 OpenSSH Client。可以在 PowerShell 中檢查：

ssh -V

如果能看到 OpenSSH 版本，表示本機 SSH 用戶端可用。

方式一：使用金鑰對登入

金鑰對登入是更推薦的方式。它不需要每次輸入伺服器密碼，也更適合長期使用 VS Code Remote SSH。

產生 SSH 金鑰

在 PowerShell 中執行：

ssh-keygen -t ed25519 -C "vscode-remote"

預設會產生：

C:\Users\User\.ssh\id_ed25519
C:\Users\User\.ssh\id_ed25519.pub

其中：

id_ed25519 是私鑰，只保存在本機；
id_ed25519.pub 是公鑰，可以放到遠端主機的 authorized_keys。

複製公鑰內容：

Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub"

然後把這段內容追加到遠端主機的：

~/.ssh/authorized_keys

遠端主機上的權限建議設定為：

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

準備好公鑰後，後面在 VS Code 的 SSH Host 設定裡填入本機私鑰路徑即可。

方式二：使用密碼登入

如果只是臨時連接一台測試主機，或者還沒有來得及設定公鑰，也可以直接使用密碼登入。此時本機 SSH Host 設定不需要寫 IdentityFile。如果伺服器允許密碼登入，VS Code Remote SSH 連接這個 Host 時會跳出密碼輸入框。

需要注意的是，密碼登入依賴遠端 SSH 服務端允許 PasswordAuthentication。有些 VPS 映像預設關閉密碼登入，只允許金鑰登入；如果開啟密碼登入，建議配合強密碼、非預設連接埠、防火牆或 Fail2ban 一類的登入保護策略。

連接步驟

1. 安裝 Remote - SSH 擴充套件

安裝 VS Code 擴充套件：

Remote - SSH

安裝完成後建議重啟一次 VS Code，避免左側遠端資源管理器、命令面板和 SSH 設定入口沒有立即刷新。

2. 設定 SSH Host

開啟命令面板：

Ctrl + Shift + P
Remote-SSH: Open SSH Configuration File...

選擇 Windows 使用者目錄下的 SSH 設定檔：

C:\Users\User\.ssh\config

如果使用金鑰登入，寫入類似設定：

Host blog-dev
  HostName 你的伺服器IP或網域
  User root
  Port 22
  IdentityFile C:\Users\User\.ssh\id_ed25519
  ServerAliveInterval 30
  ServerAliveCountMax 3

如果使用密碼登入，可以不寫 IdentityFile：

Host blog-dev-password
  HostName 你的伺服器IP或網域
  User root
  Port 22
  PreferredAuthentications password,keyboard-interactive

儲存設定後，VS Code 的遠端資源管理器中會出現對應的 Host。

3. 連接遠端主機

連接方式有兩種。可以繼續使用命令面板：

Ctrl + Shift + P
Remote-SSH: Connect to Host...
blog-dev

也可以點擊左側活動列的遠端資源管理器圖示，在 遠端(隧道/SSH) 視圖裡展開 SSH，選擇剛設定的主機並連接。連接成功後，主機旁邊會顯示已連接狀態。

首次連接時，VS Code 會在遠端主機安裝 VS Code Server。如果使用密碼登入，VS Code 會跳出密碼輸入框；如果使用金鑰登入，通常會直接進入遠端視窗。

4. 開啟遠端目錄

連接成功後，在遠端資源管理器中展開主機，選擇需要開啟的遠端目錄，例如：

/opt

或：

/home/deploy

開啟後，本機 VS Code 視窗實際操作的是遠端主機上的目錄。後續在資源管理器中編輯檔案、開啟終端機、保存內容，都會發生在遠端主機上。

小容量 VPS 的限制

VS Code Remote SSH 首次連接時會在遠端主機安裝 VS Code Server，通常位於：

~/.vscode-server

後續安裝遠端擴充套件、開啟多個遠端視窗或保留舊版本 VS Code Server 時，也會繼續占用遠端磁碟。對於 edgeproxy 這類只有 5G 左右儲存分配的小型 VPS，這個限制會比較明顯：~/.vscode-server 和遠端擴充套件快取疊加後，可能把磁碟占滿。磁碟滿了以後，常見表現包括 VS Code Server 安裝失敗、遠端終端機異常、檔案保存失敗。

連接前建議先檢查空間：

df -h
du -sh ~/.vscode-server ~/.cache 2>/dev/null

如果空間緊張，可以優先減少遠端擴充套件數量，或者移除舊的 VS Code Server 版本目錄：

rm -rf ~/.vscode-server/bin/<舊版本目錄>

如果這台 VPS 主要用於代理、轉發或輕量服務，不建議把它當成完整開發機長期使用。Remote SSH 更適合磁碟空間、記憶體和 CPU 都有一定餘量的遠端主機。

常見問題

1. 第一次連線很慢

首次連接時，VS Code 會在遠端主機安裝服務端元件。只要網路穩定，等待安裝完成即可。後續連接通常會明顯更快。

2. 金鑰明明正確但仍然要求密碼

優先檢查三處：

ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

權限建議：

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

另外確認本機 IdentityFile 指向的是私鑰，而不是 .pub 公鑰。

3. known_hosts 報錯

如果伺服器重裝過系統或 IP 被重複使用，本機可能出現 host key 衝突。可以先確認確實是你的伺服器，再清理舊記錄：

ssh-keygen -R 伺服器IP或網域

然後重新連線。

小結

VS Code Remote SSH 的重點不是「遠端桌面」，而是讓 VS Code 透過 SSH 直接管理遠端主機上的目錄。實際使用時，把順序記住就夠了：安裝 Remote - SSH 擴充套件，重啟 VS Code，設定 SSH Host，然後從遠端資源管理器連接主機並開啟目錄。

參考

VS Code Remote SSH 文件：https://code.visualstudio.com/docs/remote/ssh
VS Code Remote SSH Marketplace：https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh

VS Code Remote SSH 連接後安裝 Codex：為什麼遠端視窗需要重新安裝和認證

toewpq — Sun, 10 May 2026 00:00:00 GMT

使用 VS Code Remote SSH 連接遠端主機後，經常會遇到一個容易誤解的現象：本機 VS Code 明明已經安裝了 Codex 擴充套件，切到遠端 SSH 視窗後，Codex 圖示卻沒有像本機視窗那樣出現在側邊欄。

原因很簡單：Remote SSH 開啟的不是普通本機視窗，而是連接到遠端主機的遠端視窗。VS Code 會在遠端主機上執行一套遠端擴充套件環境。本機安裝過的擴充套件和本機登入狀態，不一定會自動帶到遠端主機裡。對 Codex 來說，遠端視窗通常需要重新安裝一次擴充套件，並重新完成一次認證。

下面用一個泛化主機名 remote-dev 舉例，避免把真實伺服器名稱寫進教學。

前提

繼續之前，先確認你已經完成了 VS Code Remote SSH 連接：

左側遠端資源管理器中能看到 SSH 主機 remote-dev
主機狀態顯示已連接
目前視窗左下角顯示 SSH: remote-dev
遠端終端機提示字元來自遠端主機

如果目前開啟的還是本機 Windows 目錄，例如 C:\Users\User\Desktop，那還不是遠端工作區。需要先從遠端資源管理器中連接主機，並開啟遠端目錄，例如：

/opt

或：

/home/deploy

為什麼本機裝過 Codex 還要遠端再裝

VS Code Remote SSH 連接後，擴充套件大致分成兩類：

本機 UI 側擴充套件：執行在本機 VS Code 用戶端中；
遠端工作區擴充套件：執行在遠端主機的 VS Code Server 環境中。

Codex 需要讀取目前工作區、顯示側邊欄入口，並和遠端目錄中的檔案互動。遠端 SSH 視窗裡的工作區在遠端主機上，所以只在本機裝過 Codex 並不夠。你需要在遠端視窗裡安裝 Codex，安裝位置通常會顯示為類似：

Install in SSH: remote-dev

安裝完成後，Codex 圖示才會在這個遠端視窗裡正常出現。

安裝步驟

1. 先連接 Remote SSH

開啟 VS Code 左側遠端資源管理器，選擇 遠端(隧道/SSH)，在 SSH 下連接示例主機：

remote-dev

連接成功後，開啟一個遠端目錄，例如 /opt。這一步很重要，因為 Codex 要安裝到目前遠端視窗，而不是普通本機視窗。

2. 在遠端視窗安裝 Codex 擴充套件

開啟擴充套件面板：

Ctrl + Shift + X

搜尋：

Codex

如果擴充套件已經在本機安裝過，但遠端視窗還不能使用，擴充套件頁面通常會出現遠端安裝入口。選擇類似下面的按鈕：

Install in SSH: remote-dev

不要只看本機是否已經安裝。關鍵是確認目前遠端 SSH 視窗也安裝了 Codex。

3. 重載或重啟 VS Code 視窗

安裝完成後，如果側邊欄沒有立即出現 Codex 圖示，可以執行：

Ctrl + Shift + P
Developer: Reload Window

也可以直接關閉目前遠端視窗，再重新透過 Remote SSH 連接 remote-dev。很多時候，重載視窗後 Codex 圖示才會穩定顯示。

4. 重新認證 Codex

遠端視窗裡的 Codex 需要單獨認證。即使本機 VS Code 已經登入過 Codex，遠端 SSH 視窗仍然可能要求重新登入或設定 API Key。

開啟 Codex 圖示後，按提示完成認證。常見方式包括：

使用 ChatGPT / OpenAI 帳號登入
或設定 OpenAI API Key

認證完成後，Codex 才能在遠端視窗中讀取目前目錄、輔助修改檔案，並根據遠端工作區上下文執行任務。

常見現象

1. 本機視窗有 Codex 圖示，遠端視窗沒有

優先檢查 Codex 是否安裝到了遠端 SSH 視窗。只在本機安裝並不等於遠端可用。

2. 擴充套件頁顯示已安裝，但遠端側邊欄還是沒有圖示

確認目前視窗左下角是否顯示 SSH: remote-dev。如果不是遠端視窗，表示你還在本機環境。若已經是遠端視窗，執行 Developer: Reload Window。

3. 遠端視窗提示需要登入

這是正常現象。遠端主機和本機用戶端的認證狀態可能不同，需要重新完成 Codex 登入或 API Key 設定。

4. 遠端主機空間很小

Codex 擴充套件、VS Code Server 和其他遠端擴充套件都會占用遠端磁碟。如果是只有 5G 左右儲存的小型 VPS，建議先檢查空間：

df -h
du -sh ~/.vscode-server ~/.cache 2>/dev/null

空間不足時，遠端擴充套件可能安裝失敗，Codex 圖示也可能無法正常顯示。

小結

把 VS Code Remote SSH 和 Codex 放在一起使用時，要記住一個區別：本機 VS Code 用戶端和遠端 SSH 視窗不是同一個擴充套件執行環境。本機裝過 Codex，不代表遠端視窗已經裝好；本機認證過，也不代表遠端視窗已經認證。

實踐順序可以固定為：

連接 Remote SSH
開啟遠端目錄
在遠端視窗安裝 Codex
重載或重啟 VS Code 視窗
重新完成 Codex 認證
確認 Codex 圖示出現在遠端視窗側邊欄

這樣處理後，Codex 才會像本機視窗一樣，在遠端主機的工作區裡正常顯示和使用。

參考

Codex IDE 擴充套件文件：https://developers.openai.com/codex/ide
Codex CLI 文件：https://developers.openai.com/codex/cli
VS Code Remote SSH 文件：https://code.visualstudio.com/docs/remote/ssh

OpenWrt QModem 下 RM502Q-AE 無法接收簡訊的排障與恢復：IMS、5G SA 與簡訊承載設定

toewpq — Wed, 29 Apr 2026 00:00:00 GMT

這是一篇真實排障記錄：OpenWrt 上透過 QModem 管理 Quectel RM502Q-AE 時，QModem 簡訊頁面一直收不到簡訊。最後確認問題不在頁面讀取，也不是簡訊儲存已滿，而是在中國移動 NR5G SA 場景下 IMS 處於關閉狀態。開啟 IMS 並重啟模組後，簡訊恢復接收。

文中涉及身份類資訊均已脫敏；如果需要提到 CIMI/IMSI，只記錄為 46007************ 或「已脫敏」。簡訊正文不記錄。

1. 背景與症狀

環境很普通：OpenWrt 系統，QModem 管理 RM502Q-AE，AT 連接埠使用 /dev/mhi_DUN。模組資訊如下：

ATI
Quectel
RM502Q-AE
Revision: RM502QAEAAR13A04M4G

AT+QGMR
RM502QAEAAR13A04M4G_01.203.01.203

營運商為中國移動，網路曾駐留在 NR5G SA：

AT+QNWINFO
+QNWINFO: "TDD NR5G","46000","NR5G BAND 79",721824

排障過程中也出現過 NR5G BAND 41。5G SA 註冊狀態最後正常：

AT+C5GREG?
+C5GREG: 2,1,...,11,...

AT+C5GREG?
+C5GREG: 0,1

原始症狀是 QModem 的簡訊頁面沒有任何簡訊。介面返回中 msg 為空，儲存能力看起來正常：

{
  "msg": [],
  "result": {},
  "sms_capabilities": {
    "mem1": "MT",
    "mem2": "MT",
    "mem3": "MT",
    "ME": { "used": "0", "total": "127" },
    "SM": {}
  }
}

2. 先確認不是 QModem 頁面問題

第一步不是改設定，而是確認簡訊到底有沒有進入模組儲存。分別檢查 ME、MT、SM、SR 後，結果都為空：

AT+CPMS="ME","ME","ME"
+CPMS: 0,127,0,127,0,127
OK

AT+CPMS="MT","MT","MT"
+CPMS: 0,127,0,127,0,127
OK

AT+CPMS="SM","SM","SM"
+CPMS: 0,50,0,50,0,50
OK

AT+CPMS="SR","SR","SR"
+CPMS: 0,5,0,5,0,5
OK

AT+CMGL=4
OK

AT+CMGL=4 返回 OK 但沒有任何 +CMGL 行。這一點很關鍵：如果 ME、MT、SM、SR 都為空，就不是 QModem 頁面只讀錯了 ME/SM，也不是儲存已滿，而是簡訊沒有進入模組可讀儲存。

3. PDU 模式下 CMGL 的一個容易踩坑點

排障初期曾看到：

AT+CMGL="ALL"
ERROR

這很容易被誤判成簡訊功能異常。後續確認目前是 PDU 模式：

AT+CMGF?
+CMGF: 0

AT+CMGL=?
+CMGL: (0-4)

在 PDU 模式下，列出全部簡訊應使用：

AT+CMGL=4

而不是：

AT+CMGL="ALL"

AT+CMGL="ALL" 更適合文字模式，也就是先執行 AT+CMGF=1 的場景。驗證碼、中文簡訊和 Unicode 內容更適合保留 PDU 模式，所以這裡最後使用 AT+CMGF=0 與 AT+CMGL=4。

4. 簡訊儲存、URC 和通知設定

排障中驗證或設定過這一組基礎簡訊設定：

AT+CMEE=2
AT+QURCCFG="urcport","all"
AT+CSMS=1
AT+CMGF=0
AT+CPMS="MT","MT","MT"
AT+CNMI=2,1,0,0,0

這些命令的作用可以這樣理解：

AT+QURCCFG="urcport","all"：讓 URC 從所有可用 AT 連接埠輸出，避免 QModem 使用的連接埠和手動調試的 AT 口不一致，導致新簡訊通知看不到。
AT+CPMS="MT","MT","MT"：使用模組簡訊總視圖，避免簡訊落在 ME 或 SM，但讀取時看了另一邊。
AT+CNMI=2,1,0,0,0：新簡訊儲存後，透過 +CMTI 通知終端。
AT+CMGF=0：保持 PDU 模式，更適合驗證碼、中文簡訊和 Unicode 內容。

如果選擇文字模式，才更適合使用：

AT+CMGF=1
AT+CMGL="ALL"

5. 5G SA 註冊正常但簡訊仍未進入儲存

當時 5G SA 註冊已經正常，但簡訊仍然沒有進入任何儲存。繼續檢查簡訊承載偏好：

AT+CGSMS?
+CGSMS: 1

CGSMS=1 可以理解為偏向傳統 CS 域。對於目前中國移動 NR5G SA 場景，這並不是理想狀態。隨後設定為：

AT+CGSMS=2
OK

CGSMS=2 可理解為 Packet domain preferred / PS preferred。這裡不要寫得過度絕對：不同營運商、不同韌體、不同註冊狀態下，簡訊承載策略可能不同。但在這次 NR5G SA 排障中，不應繼續讓簡訊承載偏向傳統 CS 域。

6. 關鍵發現：IMS 是關閉的

真正的關鍵點來自 IMS 設定：

AT+QCFG="ims"
+QCFG: "ims",0,0

這表示 IMS 未開啟。隨後執行：

AT+QCFG="ims",1
OK

重啟模組後，簡訊恢復正常，可以接收簡訊。也就是說，在這次 RM502Q-AE 駐留中國移動 NR5G SA 網路的場景裡，簡訊恢復的關鍵動作不是清空儲存，也不是換 QModem 頁面讀取方式，而是開啟 IMS。

7. 修復步驟

核心修復命令如下：

AT+CMEE=2
AT+QCFG="ims",1
AT+CFUN=1,1

模組重啟後，建議重新設定簡訊相關參數：

AT+QURCCFG="urcport","all"
AT+CGSMS=2
AT+CSMS=1
AT+CMGF=0
AT+CPMS="MT","MT","MT"
AT+CNMI=2,1,0,0,0

本次實際結果是：開啟 IMS 並重啟後，QModem 可以收到簡訊。

8. 回滾步驟

如果開啟 IMS 後出現註冊、撥號或網路異常，可以回滾：

AT+QCFG="ims",0
AT+CFUN=1,1

但本次故障的實際恢復動作是開啟 IMS，因此最後建議保留：

AT+QCFG="ims",1

如果需要回滾簡訊承載偏好，可以執行：

AT+CGSMS=1

不過這不推薦作為本次 NR5G SA 場景下的最終狀態，因為簡訊恢復後使用的是：

AT+CGSMS: 2

9. QModem 初始化後 AT 命令建議

建議寫入 QModem 的「初始化後 AT 命令」：

AT+QCFG="ims",1
AT+QURCCFG="urcport","all"
AT+CGSMS=2
AT+CSMS=1
AT+CMGF=0
AT+CPMS="MT","MT","MT"
AT+CNMI=2,1,0,0,0

這裡不依賴 AT&W。實際排障中，AT&W 沒有穩定返回 OK，而 OpenWrt/QModem 的使用方式也更適合把關鍵初始化命令交給 QModem 在啟動後執行。這樣即使 profile 持久化行為不確定，重啟後仍能把簡訊相關狀態拉回預期設定。

10. 後續：如何判斷載波聚合是否觸發

簡訊恢復後，又繼續看了載波聚合狀態：

AT+QCAINFO
+QCAINFO: "PCC",721824,6,"NR5G BAND 79",347

AT+QNWINFO
+QNWINFO: "TDD NR5G","46000","NR5G BAND 79",721824

AT+QENG="servingcell"
+QENG: "servingcell","NOCONN","NR5G-SA","TDD",460,00,...,721824,79,...

AT+QCFG="lteca"
ERROR

QCAINFO 只有 PCC，沒有 SCC，說明查詢當下沒有觸發載波聚合。但 QENG="servingcell" 顯示 NOCONN，代表當時處於空閒或未連線態，不能據此判斷模組或網路不支援 CA。

正確判斷方法是在測速或大流量下載過程中，反覆執行：

AT+QCAINFO
AT+QENG="servingcell"

如果出現 SCC，才說明 CA 被網路側調度。AT+QCFG="lteca" 返回 ERROR，只說明目前韌體不支援這個設定項，或沒有開放這個 QCFG 項，不等於 CA 被關閉。

對於 NR5G SA 下的 NR CA，更多取決於網路側調度、基地台設定、套餐、信號、頻段組合和是否鎖頻。不要為了測試 CA 盲目寫未知 AT 命令，更不要把已經驗證有效的 IMS 關閉。

11. 結論

這次故障的結論很明確：

不是簡訊儲存已滿。
不是 QModem 只讀錯 ME 或 SM。
ME、MT、SM、SR 都為空，說明簡訊沒有進入模組可讀儲存。
目前網路是中國移動 NR5G SA，5G 註冊狀態正常。
簡訊恢復的關鍵動作是開啟 IMS：AT+QCFG="ims",1，然後透過 AT+CFUN=1,1 重啟模組。
重啟後可以接收簡訊。
後續建議保留 IMS 開啟，並在 QModem 初始化後 AT 命令中固化簡訊相關設定。
關於 CA：查詢時 QCAINFO 只有 PCC，說明當時沒有觸發 CA；AT+QCFG="lteca" 返回 ERROR 不代表 CA 不能用，只代表該設定項不可用。正確方式是在大流量期間觀察 QCAINFO 是否出現 SCC。