[AI 風險提醒] Codex SSD異常寫入問題

 [AI 風險提醒] Codex SSD異常寫入問題

摘要 : Codex本地日誌疑似以Trace級別持續寫入SQLite，可能造成SSD壽命、效能與隱私風險。

內容:

近期有使用者回報，OpenAI Codex CLI 與桌面版可能出現 SSD 寫入放大問題，主因疑似來自本地診斷日誌持續以高頻率寫入 SQLite。若你最近有使用 Codex，建議先檢查本機的日誌檔案是否異常成長，避免 SSD 健康度持續受影響。

自查方式很簡單。Windows 使用者可到使用者個人目錄下的 Codex 資料夾查看 `Logs.r.sqlite`；macOS 與 Linux 使用者則到對應的 Codex 目錄檢查相同檔案。若旁邊同時看到 `WAL` 與 `SHM` 檔案屬正常情況，因為 Codex 採用 SQLite。但若發現 WAL 檔在短時間內快速變大，或只要開啟 Codex 磁碟寫入就長時間偏高，就要特別注意。

根據社群回報，這個問題已被多位使用者重現，有案例指出 21 天內寫入 37TB，也有人在 10 分鐘內寫入 7GB。對一般消費級 SSD 而言，這樣的寫入量相當可觀，可能對壽命造成實質影響。

問題核心不在於「寫日誌」本身，而是預設日誌級別疑似設為 Trace。Trace 屬於非常細緻的開發級日誌，適合除錯與深度排查，但不適合長期預設寫入本地資料庫。更麻煩的是，這部分 SQLite 日誌行為似乎不完全受 Rust Log 設定控制，因此即使用戶已將日誌等級調成 `warn`，本地 SQLite 仍可能持續寫入大量 Trace 級內容。

從已公開的資訊來看，寫入量較大的來源之一是 Responses WebSocket 的原始回應紀錄，另外還包含 OpenTelemetry 相關事件與部分底層依賴日誌。這些內容對一般使用者排查幫助有限，但若全部持久化進 SQLite，就容易形成高頻率、大體積的磁碟寫入。

除了 SSD 壽命外，這件事也牽涉效能、穩定性與隱私。首先，日誌資料庫持續膨脹後，Codex 桌面端可能會越來越慢，特別是在 WSL2 或本身磁碟壓力較高的環境中，可能出現磁碟活躍時間接近 100%。其次，若 `Logs.r.sqlite` 與 WAL 檔過大，可能導致啟動時 SQLite 連線超時，甚至讓 Codex 無法正常開啟。再者，若日誌中保存了 WebSocket 原始內容、對話資訊或任務上下文，也可能帶來本地隱私與資料治理風險。

截至 2026 年 6 月 23 日，GitHub 上已有兩個相關修正 PR 合併進主分支。其一是停止記錄每個成功的 Responses WebSocket 事件；其二是從持久化日誌中過濾高噪音目標，例如部分橋接日誌與 OpenTelemetry 映射事件。這些調整的方向都很明確，就是減少無效日誌寫入本地 SQLite。不過，PR 合併進主分支不代表你目前安裝的版本已經包含修復，因此仍需自行更新並觀察。

如果你是一般使用者，建議先做三件事。第一，立即更新 Codex 到最新版本。第二，完全退出 Codex 後，檢查 Codex 目錄中的 `Logs.r.sqlite`、`Logs.r.sqlite-wal` 與 `Logs.r.sqlite-shm` 是否異常肥大。第三，確認更新後磁碟寫入是否恢復正常。處理時建議只針對日誌檔案，不要直接刪除整個 Codex 目錄，以免誤刪設定或其他重要資料。

如果你是技術人員，或必須暫時使用尚未修復的舊版 Codex，可以考慮一些臨時措施。例如定期執行 SQLite 的 WAL checkpoint，以減少 WAL 檔長期膨脹；但這只能緩解檔案變大，無法真正解決持續寫入問題。更進一步的方式是對 Logs 表建立攔截插入的觸發器，直接阻止日誌寫入，但代價是未來若遇到問題，開發者可用的診斷資訊也會同步減少。另有人會把 Codex 放到 RAM Disk，以避免 SSD 持續被寫入，但這較偏向權宜之計，未必適合所有人。

對團隊與 IT 管理者而言，這次事件也是一個提醒。AI 程式工具不只要評估功能與產出品質，也應納入終端監控範圍，包括磁碟寫入量、日誌目錄大小與程序異常狀態。若工具涉及對話、程式碼片段或業務上下文，更應明確規範儲存位置、保留時間與清理機制，並建立簡單 SOP，讓團隊遇到卡頓或寫入異常時能快速排查與處理。

整體來看，這次 Codex SSD 寫入放大問題，本質上是預設日誌級別與持久化策略設計不當所引發。若你目前仍在使用 Codex，建議立即更新版本、檢查日誌檔案大小，並確認系統磁碟寫入是否存在異常增長。

[AI 分享] 熱門UI落地Skill實測盤點

 [AI 分享] 熱門UI落地Skill實測盤點

摘要 : 實測5款熱門UI設計Skill，涵蓋頁面生成、動效與大廠設計規範，整體表現差異明顯。

內容:

評測了市面上幾款近期很熱門的 UI 落地相關 Skill，主要從生成個人筆記管理頁面的效果、整體設計質感，以及動效與風格還原能力來做比較。

第一款是討論度很高的 Taste Design。作者直接要求它生成個人筆記管理頁面，在沒有提供參考圖的情況下，成品偏簡約清新，但整體缺乏明顯亮點，和預期相比略顯普通，因此評價偏保守，認為大致只有「NPC」水準。

第二款是 Web Design Skill，同樣在無參考圖的前提下生成頁面。它會先讓使用者選擇偏好與風格，而作者認為這類帶預設的 Skill 通常品質都不錯。實際生成結果也非常突出，整體風格高級、完成度高，和前者相比差距明顯，因此給出很高評價。

第三款是來自 X 上開發者製作的動效 Skill，主要用途是替靜態頁面補上微互動。作者先找好設計稿並透過 Figma 連結讓 ClockCode 呼叫此 Skill，生成後可看到兩類效果：首次載入時的入場動畫，以及頁面內元素的互動效果，例如圖表與數字的生長動畫、各元素的 Hover 效果。作者認為這些動效明顯提升了頁面的完整度。

第四款是由中國團隊開發的 Magic Slide。它的互動方式偏向 Keynote 式的轉場，因此整體生成效果很像 PPT。作者認為這類風格不一定最適合一般 UI 頁面，但若拿來做簡報或演示，效果應該會相當不錯，因此仍給予正面評價。

最後一款 Skill 的特色是內建全球 72 家頂級大廠的設計規範，可直接調用特定品牌風格來完成頁面設計。作者先用 Notion 風格生成個人筆記頁面，發現配色與 Emoji 語言都高度貼近原本設計，且細節處理穩定；接著再生成蘋果風格版本，結果同樣很出色，整體辨識度很高。綜合來看，作者認為這款表現最佳，屬於頂級水準，並表示之後會整理這些 Skill 的安裝地址提供給有需要的人。

[AI 分享] Claude Code 前端技能組合

 [AI 分享] Claude Code 前端技能組合

摘要 : 用 Claude Code 做前端時，先補齊設計、系統、元件與檢查五項技能，成品更完整也更不易有 AI 味。

內容:

如果你用 Claude Code 做前端，不要只讓它直接硬寫頁面。先補上幾個關鍵前端 skill，能讓整體成果更成熟、可用，也更有設計感。

第一個是 Frontend Design，主要負責視覺方向。它會先幫你定好版式、字型、配色和動效，讓做出來的頁面不再像制式模板。

第二個是 Design Taste Frontend，重點在提升設計品味。若你要做官網、落地頁或作品集，又不想成品一看就很有 AI 痕跡，這個 skill 能先把整體風格拉開。

第三個是 Tailwind Design System，適合 Tailwind 專案使用。它能把顏色、間距、元件變體與 Dark Mode 整合進同一套設計系統，讓後續開發更一致。

第四個是 ShadGUI，適合 React 加 Tailwind 的後台或 SaaS 工具站。它能讓 Claude 依照 ShadCN 的方式搭建元件，後續維護與調整也更方便。

第五個是 Frontend Design Review，頁面完成後不要急著上線，先用它檢查響應式、可訪問性、設計 Token 與元件一致性。整體順序就是先定設計、再搭系統、再做元件、最後質檢。

[AI 影響] 一人協同18個AI員工的團隊實驗

 [AI 影響] 一人協同18個AI員工的團隊實驗

摘要 : 一名工程師協同18個AI員工，完成模型訓練框架初版，效率被認為可接近傳統30人團隊。

內容:

有團隊分享，現在公司內部已經在實際探索「人類員工＋AI員工」的協作模式。其中一位負責基礎設施的人員，背後同時協同18個AI員工，甚至在吃飯時也能透過手機發出文字指令，讓AI持續梳理框架、補強特性與推進任務。

這種以 agent 形式運作的協作方式，被認為效率不是單純的「1加18」，而是遠高於這個數字。公司內部評估後認為，這名員工加上18個AI員工，整體產出能力可能接近過去大廠中約30人團隊的水準。

這組「1加18」的成果，主要是完成了公司第一版的模型訓練框架。18個AI員工並非沒有分工，而是有明確角色配置：其中15個負責實作，3個擔任專案經理。15個實作型AI員工又進一步分成三組：5個做底層框架設計、5個負責模組之間的協同、5個專門撰寫程式碼。3個AI專案經理則各自管理5個AI員工，而這位人類員工主要與這3個專案經理互動，提出需求與調整方向。

在這樣的工作模式下，團隊也形成了新的能力評估標準。分享者認為，如今評估一個人的能力，已不只是看程式寫得多厲害，而是看他每天能否有效提出需求、調動多少API token，以及能否提出多樣化且具體的任務。換句話說，能同時提出框架、coding、特定技術需求的人，反而更有價值。

公司在資源配置上，對API key與code agent的使用給了相當充足的預算，甚至提到相關API成本可能已經遠高於某些單一員工的成本。這也顯示，他們是把AI視為真正的生產力單位，而不只是輔助工具。

在團隊管理上，他們也減少傳統的日會、週會機制，因為認為會議相當耗時。取而代之的是使用AI來整理所有資訊，並透過郵件自動同步每個人正在做的事情，讓團隊成員快速掌握整體進度。

此外，團隊內部還建立了共享 memory 與共享 skill 的機制。每個人每天完成的工作都會進入共享報告，如果同事之間任務重疊，還會有更高層的 agent mentor 主動提醒，指出技術路線的差異、重疊部分，並建議雙方安排會議或私下交流。也就是說，許多原本屬於中台、協調、同步的管理工作，都逐漸交由AI處理。

分享者自己也有5個專屬 agent 協助工作。其中一個用來協助閱讀論文、追蹤新架構與新的訓練方法；另外3個偏向公司技術討論；還有1個財務 agent，協助管理公司預算與財務安排。

整體而言，這段分享想表達的是：即使是學生創業、第一次創業的團隊，在大量引入AI後，也能在某種程度上補足經驗不足的問題。對他們來說，AI不只是工具，更像是一群可以被管理、分工與協同運作的「數位員工」。

[AI 影響] 納德拉重寫程式設計師工作定義

 [AI 影響] 納德拉重寫程式設計師工作定義

摘要 : AI不一定取代工程師，但會重寫其工作內容，重點將轉向管理agent、維持認知覆蓋率與承擔治理型工作。

內容:

最近微軟 CEO 納德拉在《紐約時報》Hard Fork 播客上的一場訪談，提出了幾個非常值得技術工作者重視的觀點。重點不在於他宣布了什麼驚人的新消息，而是他用幾個非常具體的概念，說清楚了許多人隱約感受到、卻一直沒有被講透的變化。

這場訪談裡，有幾句話特別關鍵。像是他提到，未來的軟體開發者可能要管理 100 個、甚至 1000 個 agent；他也提出了「認知覆蓋率」這個概念，用來對照大家熟悉的「測試覆蓋率」；另外，他還說人類在 AI 時代的新價值，是去做「膠水工作」。這些詞單看有點抽象，但串在一起之後，其實指向同一件事：我們過去一直在討論「AI 會不會取代程式設計師」，這個問題本身可能就問偏了。真正正在發生的，不是這個職業消失，而是它的工作內容正在被徹底改寫。

先說訪談背景。這場節目是在 6 月 12 日於舊金山錄製，主持人是《紐約時報》的兩位科技記者 Kevin Roose 和 Casey Newton。納德拉作為微軟 CEO，本來就是全球 AI 產業最核心的人物之一。無論是微軟與 OpenAI 的深度合作、Azure 的雲端算力地位，還是微軟自家剛推出的 MAI 系列模型，都讓微軟在這場 AI 競賽中握有相當厚實的籌碼。

但這場訪談真正有意思的地方，不是他再講一次微軟戰略，而是他回應了很多非常具體、非常落地的問題。其中一個最尖銳的提問是：兩年之後，軟體工程師會變多還是變少？

這個問題之所以敏感，是因為現在外界的爭論非常激烈。一派認為 AI 寫程式越來越強，公司未來不再需要這麼多工程師；另一派則認為 AI 反而會創造更多需求，工程師依然會供不應求。納德拉沒有簡單站隊，而是給出了一個更複雜、也更值得注意的答案：未來軟體開發者需要的技能可能和今天差不多，但工作內容會完全不同。

他用了一個很形象的類比。假如很早以前有人說，未來全世界會有 35 億人變成打字員，你一定會覺得荒謬，因為世界不需要那麼多專職打字員。但今天幾乎每個人都在打字，原因不是打字員變多了，而是打字已經不再是一種職業，而是所有知識工作與資訊工作的基礎能力。納德拉認為，軟體開發也可能走上類似的路。

換句話說，未來的開發者管理的未必是傳統意義上的程式碼庫，而是一整組 agent，可能是 100 個，也可能是 1000 個。這些 agent 可以自己執行任務、自己撰寫程式碼、自己提交修改。而人類開發者的核心工作，將從親手寫出每一行程式碼，轉向理解這些 agent 做了什麼、為什麼這樣做、哪裡可能做錯，以及出問題時誰來負責與收尾。

這個判斷的重要性，在於它不只是回答「工程師會不會失業」，而是在重新定義工程師這個職業的本質。

接下來是整場訪談中最有價值的一個概念，也就是納德拉提出的「認知覆蓋率」。

對軟體開發者來說，「測試覆蓋率」是很熟悉的概念。它代表程式碼中有多少比例被測試案例覆蓋，覆蓋率越高，通常表示關鍵邏輯驗證得越完整，出錯風險相對較低。這是過去幾十年軟體工程中非常基礎的品質指標。

但納德拉認為，當程式碼庫裡越來越多的內容是由 agent 產生時，只有測試覆蓋率已經不夠了，還需要另一個新指標，也就是認知覆蓋率。

所謂認知覆蓋率，看的不是程式碼有沒有被執行過測試，而是人類有沒有真正看懂這次修改。更具體地說，就是 agent 改了哪些地方、為什麼這麼改、這些改動會如何影響整個系統流程、有沒有突破原本的架構約束、整個決策鏈條能不能被解釋。核心問題不是「能不能跑」，而是「人有沒有理解」。

這個概念非常關鍵，因為它點出了 AI 寫程式進入深水區之後最容易被忽略的風險。現在很多團隊使用 AI 輔助開發，關心的通常還是效率提升多少、寫得快不快。但納德拉提醒的是，當 agent 寫的程式碼越來越多，甚至占了大部分時，真正棘手的問題不再只是產出速度，而是可解釋性、可審計性與可控制性。

測試通過，只能說明程式碼在某些案例中可以運作；但認知覆蓋率關心的是，團隊是否理解 agent 的決策邏輯，是否知道它有沒有繞過原本的架構設計，是否能在事故發生時回放、追責、撤銷。這已經不只是技術問題，而是治理問題。而且 AI 越快，這個治理問題只會被放大。

以前一個工程師一週可能寫幾百行程式碼，每一行自己都清楚；現在 agent 一天就可能產出幾千行甚至更多。如果團隊沒有相應的工具與方法去理解這些變更，那麼整個程式碼庫很快就可能變成一個「雖然能跑，但沒人真正懂」的黑箱。

也因此，納德拉提到未來可能出現一種新的開發環境，不再只是 IDE，而是 ADE，也就是 Agent-Driven Development Environment。這種環境的核心功能，不是單純幫你寫程式，而是協助你管理一群 agent、理解他們做了什麼，並維持認知覆蓋率。這是一個很強的訊號，代表微軟內部已經開始認真思考：當 agent 成為主要程式碼生產者之後，開發工具本身應該如何被重新設計。

和認知覆蓋率相對應的，還有另一個很耐人尋味的概念，叫做「膠水工作」。

當主持人追問，如果工作型態變了，人是不是會因此賺得更多時，納德拉沒有直接談薪資，而是說了一段更值得深思的話。他的意思是，過去兩百多年來，很多價值都建立在某種專業知識或深度技能之上。當某些專業能力因技術而變得更容易取得時，人類就會再形成新的專業能力。即使我們擁有越來越多數位系統，人力資本依然重要，而人類仍然會去承擔那些「膠水工作」。而隨著自動化增加，新的膠水工作還會繼續出現。

什麼是膠水工作？可以把它理解成那些把系統、流程、組織和判斷連接起來的工作。AI 可以處理很多標準化的任務，但組織裡真正重要的許多細節，往往沒辦法完整寫進 prompt。

如果放回開發團隊的脈絡，這個概念就很具體了。例如：業務需求怎麼判斷、介面邊界怎麼切、權限怎麼設計、風險如何承擔、跨部門衝突怎麼協調、上線後誰來解釋結果與負責，這些都屬於膠水工作。

你會發現，這些事情有一個共同點：它們不是純技術問題，而是技術與業務、技術與組織、技術與人的交界問題。這些工作很難完全標準化，也很難被單一 agent 直接取代。納德拉的判斷甚至有點反直覺：agent 越多，膠水工作不但不會消失，反而會變得更難、更貴，也更需要人來治理。

很多人覺得 AI 越強，所需的人就會越少；但納德拉的邏輯剛好相反。AI 越強，系統越複雜，越需要有人去「膠水」，因為 agent 處理的是標準化、可定義的任務，但任務與任務之間、系統與系統之間、人與系統之間，反而會出現更多縫隙。而這些縫隙，往往才是最有價值、也最需要綜合判斷的地方。

因此，如果回到最初那個問題：「程式設計師會不會失業？」納德拉的真正答案其實很清楚。這個職業不會因為 agent 的出現而立刻消失，但職業重心一定會被改寫。下一階段最稀缺的開發者，未必是最會手寫程式碼的人，而是最能看懂、管住、排程與治理 agent 的人。

除了工作型態，納德拉在訪談中也談到另一個非常實際的問題，那就是 AI 的成本。他提出了一個詞，叫做「Token Economics」，也就是 Token 經濟學。

這個詞聽起來有點抽象，但本質上很簡單：你花出去的 token，必須換回對應的價值。納德拉的說法很直接，生產力提升的邊際價值，必須配得上 token 的邊際成本，這是一種管理紀律。

他的意思是，不能為了追求所謂的 token maxing，就什麼問題都用最強模型、什麼任務都塞進最大上下文，靠無腦堆砌算力來解決一切。尤其在非核心問題上，更不應持續消耗最昂貴的模型資源。AI 工具確實很容易讓人上癮，他自己也承認會高頻使用，但新鮮感退去之後，真正重要的是回頭問：這些消耗到底有沒有產生足夠價值。

整體來看，納德拉這場訪談最值得記住的，不是哪個產品、哪個模型，而是他對未來軟體開發結構性變化的判斷。他不是在說程式設計師會被簡單取代，而是在說，當 agent 成為主要生產力之後，開發工作的重心將從「寫」轉向「管」，從「產出」轉向「理解」，從「效率」轉向「治理」。

如果這個方向成立，那麼未來真正重要的能力，會變成幾件事：能不能有效管理大量 agent、能不能維持足夠的認知覆蓋率、能不能承擔那些看似瑣碎但其實最關鍵的膠水工作，以及能不能在 AI 成本與產出之間做出有紀律的取捨。

也就是說，AI 時代不是不要工程師了，而是更需要那種能跨技術、跨業務、跨組織理解整體系統的人。這可能才是這場訪談最值得所有技術人認真聽的地方。

[AI 分享] Codex Recall & Replay

 [AI 分享] Codex Recall & Replay

摘要 : Codex 推出 Recall & Replay，可直接錄製並學會使用者操作，將示範轉成可重播的 Skill，大幅降低教 AI 自動化流程的門檻。

內容:

Codex 昨天更新了新功能 Recall & Replay。開啟後，它會錄下你在電腦上的操作，理解每一步的意圖，並自動轉化為可重複呼叫的 Skill。之後遇到相同任務，就不必再手動操作，只要讓 Codex 執行該 Skill 即可。

這是今年最強、甚至可稱為「神級」的更新，原因在於 AI 的學習方式出現了重要變化：從過去依賴人用文字描述流程，進化成直接透過示範讓 AI 學會。這大幅降低了使用門檻，因為多數人其實很難把自己的工作流程清楚語言化、結構化。

這項功能的本質，是把原本難以表達的隱性知識顯性化。使用者不再需要先整理出 SOP 或寫提示詞，只要實際操作一次，AI 就能根據錄影理解流程、判斷邏輯，並封裝成後續可複用的技能。

示範了一個實際場景：經常需要把 Ulysses 裡寫好的文章複製到 Substack，建立新文章、貼上內容、整理標題並加入訂閱按鈕，這是一個高頻且重複的工作。於是他透過 Recall & Replay 錄下整個流程，讓 Codex 自動建立對應 Skill。

第一次測試時，Codex 已能自動找到指定文章、開啟 Substack 後台、建立草稿、貼上正文並整理標題，但漏掉了文末的訂閱按鈕。作者回報後，Codex 回看先前錄影，確認自己的判斷錯誤並補上該步驟；再次執行後，整個流程便完整重現，成果也與作者原本操作一致。

最後指出，Recall & Replay 建立在兩個核心能力上：多模態理解錄影，以及 Computer Use 重現操作。這些能力單獨看並不新，但結合之後，讓 AI 能透過「看你怎麼做」來學會技能，預示未來將有更多人類工作流程被 AI 快速吸收與自動化。

[AI 衝擊] AI暗黑工廠：當軟體工程進入極速開發時代

 [AI 衝擊] AI暗黑工廠：當軟體工程進入極速開發時代

摘要 : AI大量接管寫碼後，工程師角色正從工匠轉向工廠經理，生產力暴增同時也帶來失控、重構與基礎設施新挑戰。

內容:

你印象中的程式設計師，或許還停留在那種安靜敲鍵盤、反覆推敲邏輯、謹慎測試的工匠式畫面。但這份材料描繪的，已經不是人類親手逐行寫程式的世界了。取而代之的，是大量高活躍度的 AI 智慧體同時在程式碼庫中高速產出，讓軟體工程從「手工創作」轉變成「規模化生產」的現場。

OpenCloud 的維護者 Vincent Cox，正是這種新模式的縮影。白天，他在大型企業裡遵循嚴格、結構化、安全優先的工程規範；夜晚，他則投入開源世界，依靠對測試框架的強烈信任，驅動大批 AI 在程式碼庫中高速運轉。這種反差不只是工作風格的切換，更像是兩套完全不同的工程哲學並存於同一個人身上。

最令人震撼的是這種模式所帶來的吞吐量。OpenCloud 的核心維護者其實只有約 10 到 15 人，而且大多數人都有全職工作，但專案高峰期卻能做到單日約 800 次程式碼提交。更誇張的是，Vincent 曾在 3 月 15 日創下個人單日將近 3400 次提交的紀錄。這不是透過作弊腳本灌水，而是真實大量驅動 AI 所產生的結果，甚至因此頻繁觸發 GitHub 的 API 保護機制，被平台按小時熔斷，反而成了他少數被迫停下來休息的時間。

這也揭示出所謂「暗黑工廠」模式的核心：當程式碼的主要生產者不再是人類手指，而是大模型的生成能力時，軟體工程比拚的就不再是個人的手速，而是整體生產體系的調度能力。真正的變化，不是寫得更快，而是整個生產方式被重新定義了。

Vincent 用一段早年體驗 VR 的經歷，來形容開發者面對這種 AI 洪流時的感受。2013 年，他曾無視早期 VR 頭顯「每次使用不要超過五分鐘」的警告，連續玩了三小時遊戲，最後不但劇烈暈眩、抱著馬桶狂吐，連視覺都短暫扭曲。他認為，這種生理上的反胃與失衡，和今天開發者面對幾十個 AI 同時輸出、數萬行程式碼瀑布般湧出的認知衝擊非常相似。不是因為內容不能理解，而是因為量級太大，超出了人腦即時消化的極限。

因此，開發者的角色被迫改變。過去那種逐行雕琢程式碼的浪漫工匠形象，正在被「監控整條流水線的工廠經理」所取代。這種轉變甚至可類比英國工業革命：手工織布時代，最熟練的工匠也受限於雙手速度；而進入集中式工廠後，產能的上限來自系統規模與機械協作。AI 時代的軟體工程，也正在經歷類似的結構性躍遷。

在這套模式裡，系統被拆成多個不同風險等級的「湧道」。其中第三與第四號湧道屬於深水區，負責較複雜的功能開發，例如整合與底層訊息通道機制。這部分人類無法缺席，必須與 AI 持續高頻互動、審查架構、修正偏差。AI 更像是高速起草的工程師，人類則是負責把關安全性與方向的經理。

壓力最大的則是第五號湧道，也就是專門處理 P0、P1 級高危 Bug 的急診區。這裡的 AI 會長時間潛伏在社群平台與討論頻道中，持續監聽全球使用者回報。一旦察覺崩潰徵兆，便立即整理出過去幾小時內的重大錯誤、提煉重點並給出修復建議。從這套體系可以看出，真正稀缺的已經不是 Token 成本，而是算力，以及人類注意力、腦容量與多工處理能力。

這種脆弱性，在一次被稱為「凌晨兩點大重構」的事件中徹底暴露。一位位於地球另一端、毫不知情的開源維護者，只是移動了幾個底層檔案路徑，卻瞬間導致整個通訊架構混亂甚至癱瘓。按照傳統工程思維，這種事故應該先回滾、再補丁修復。但當時疲憊不堪的團隊卻做出極度反直覺的決定：不修了，乾脆趁機把整個程式碼庫徹底重構成外掛化架構。

這個決定背後其實有明確邏輯。在 AI 時代，新增功能的成本大幅下降，真正困難的不是答應需求，而是拒絕需求。如果架構沒有物理層面的解耦，專案很快就會因特性膨脹而變成無法維護的泥潭。於是他們放開限制，讓數十個 AI 全面接手重構工作。最終，短時間內產生了約 2700 次提交，修改近千萬行程式碼，觸及核心程式碼庫約 82% 的區域，幾乎等同於把整棟大樓炸掉後原地重建。

過程中當然一度瀕臨失控。測試系統滿屏飄紅，團隊陷入強烈自我懷疑，甚至懷疑自己是否像伊卡洛斯一樣飛得太高、終將墜落。但戲劇性的轉折是，最後救回整個專案的，竟然是那些平常被資深工程師嫌棄、由 AI 過度擬合產生的糟糕單元測試。

這些測試平常被視為技術債，因為太死板，稍微改動邏輯就會報錯；但在這場毀滅式重構中，它們反而成了最原始、最可靠的生命線。只要這些老派而僵硬的測試重新變綠，就代表最底層的核心邏輯仍然是通的。換句話說，即便新房子蓋得再奇怪，只要地基和主要承重結構還能通過驗證，就還有挽回空間。

然而，真正撐起這種極速並發開發模式的，不只是流程與測試，還有底層基礎設施。Vincent 也坦言自己曾犯下一個代價巨大的判斷錯誤：他原本使用適合傳統開發的工作樹機制來管理多執行緒工作區，因為這樣能共享同一套程式碼庫、節省硬碟空間。但在暗黑工廠模式下，數十個 AI 不斷拉取與提交，導致每天累積 70 到 80 個極度活躍的工作區，最終把高規格機器也拖進記憶體溢位與系統崩潰。

相較之下，他的同事 Peter 採取了極為粗暴但有效的方法：直接把整個龐大程式碼庫完整複製多份，透過物理隔離來徹底避免工作區之間互相爭搶資源。這種看似笨拙的做法，反而更適合高並發 AI 開發的現實需求。

經歷這些慘痛教訓後，Vincent 又進一步打造出一套保命機制：一個常駐守護程序。當系統因為 AI 的瘋狂輸出而卡死、接近崩潰時，他只要按下鍵盤上的 ESC 鍵，守護程序就能立刻介入，強制熔斷失控流程，並指揮 AI 進行環境清理與狀態恢復。這相當於替整座高速運轉的暗黑工廠，加裝最後一道人工緊急煞車。

整體來看，這份內容真正想揭示的，不只是「AI 能把寫程式速度提升多少」，而是軟體工程的本質正在改變。開發者不再只是程式碼作者，而更像是調度者、審查者、熔斷者與系統經理。AI 帶來的不是單純效率提升，而是一種足以讓工程方法論、團隊協作方式、架構設計原則與基礎設施策略全面重寫的衝擊。

[AI 回顧] Token Maxing三月熱潮退場

[AI 回顧] Token Maxing三月熱潮退場

摘要 : Token Maxing從矽谷狂熱蔓延至大廠，卻在三個月內快速降溫，主因是成本失控、ROI不明、能力與組織流程脫節。

內容:

三個月前，矽谷還在流行一場名為「Token Maxing」的熱潮。當時工程師們比拼誰消耗更多 token，彷彿用得越多，就越懂 AI、越代表未來。這股風潮最早出現在 OpenAI、Anthropic 等前沿模型公司內部，後來快速擴散到整個科技圈，甚至連迪士尼、Visa 與國內大廠都加入其中。

所謂 Token Maxing，本意是「最大化使用 token 資源」，但很快被扭曲成一種身份象徵。大家開始把高 token 消耗等同於更高的 AI 掌握度與生產力。當時的氛圍甚至到了「不用 AI 就落後、不多用 AI 就是態度有問題」的程度。

但這場熱潮退得也非常快。到了五月底、六月初，亞馬遜關閉了內部 AI 使用排行榜，因為員工開始為了衝排名而讓 AI 執行沒有價值的任務。Uber 也公開質疑 token 消耗與實際業務成果之間的關聯，微軟則開始削減大量內部 Cloud Code 授權。原本無上限投入的企業，幾乎都陸續踩下煞車。

在這波調整中，各家公司也開始尋找新的衡量標準。百度提出以日活智慧體數（DAA）取代 token；Devin主張用節省的人類工時衡量；Uber希望將 token 與功能交付、ROI 掛鉤；亞馬遜則回到客戶與業務問題解決數量。但問題是，token 消耗與這些最終指標之間並沒有簡單直接的換算關係，試錯成本與效益邊界也難以界定。

微軟 CEO 納德拉後來提出「Token 資本」的概念，認為 token 使用的目的不應只是消耗，而是要沉澱成企業自己的 AI 能力資產，例如工作流、私有評測、組織知識、反饋閉環與可遷移的企業經驗。這個觀點雖然補充了部分方向，但本質上也只是把正在被工具鏈自動化的流程，重新包裝成企業資產來理解。

那麼，Token Maxing 為什麼會這麼快失敗？最直接的原因就是太貴了，企業燒不起。更深層來看，至少有三個原因。

第一，前沿模型公司的成本結構本來就不好看，尤其在 IPO 壓力下，更難維持寬鬆的使用政策。模型本身研發成本極高，商業化後毛利也未必理想，因此企業開始提高價格，或透過調整 tokenizer、計費方式來變相漲價。

第二，訂閱制被重度使用者與 agent 工具打穿了。原本包月訂閱適用於一般聊天式使用，但自動化 agent 能長時間並行工作，token 消耗遠超舊有模型。這讓廠商不得不把高強度推理成本拆出來額外收費，例如 Anthropic 與 Google 都開始調整訂閱方案與計費邏輯。

第三，從技術層面看，agent 的 token 消耗極其驚人，而且效率很低。研究指出，agent 式程式設計任務的 token 消耗大約是普通程式碼問答的 1000 倍，最大開支還不是輸出，而是模型反覆讀取上下文的輸入成本。探索、修正、測試等階段尤其消耗巨大，說明現有工具鏈為了讓模型不跑偏，必須不斷餵入上下文，代價極高。

此外，agent 真正的能力也還遠未成熟。研究顯示，在大量真實專業任務中，即使是最好的系統，最難任務的完整通過率也只有 8.6%，平均甚至只有 2.6%。而且 75% 的失敗並不是執行層面的手腳問題，而是理解與策略問題，也就是說，agent 最大的短板是缺乏真正的行業知識與專業判斷。

這意味著，AI 並不是不能做事，而是越接近真實企業場景，越依賴隱性知識、本地規則、專業流程與可驗證輸出。一個通用 skill 到企業內部往往還要二次開發，法務、財務、研發、銷售各有自己的規範與系統，越貼近業務，越難通用。

組織層面也是一大瓶頸。即使 AI 在某個上游環節真的有效，比如寫程式碼，它也未必能轉化成最終成果。因為程式碼之後還有審查、測試、整合、發布與採用等一連串流程。上游加速了，但下游沒有同步加速，最後就只會堆出更多半成品。

MIT 的研究就指出，AI 工具確實讓程式碼提交大幅增加，但這種增幅傳導到專案數與實際發布版本時，效果會明顯縮水。也就是說，「寫出更多程式碼」和「交付更多產品」完全不是一回事。更麻煩的是，AI 產生的程式碼還可能讓人類後續審查負擔更重，理解難度更高，進一步卡住人的頻寬。

除了這些大問題，還有兩種常被忽略的浪費。第一是簡單任務上的虛耗。研究顯示，像簡單算數、拼寫檢查、同義詞查詢這類小任務，很多人明明自己做更快，卻還是習慣打開 AI。結果反而花更多時間在寫提示詞、等待答案、閱讀與確認上，形成一種「效率幻覺」。

第二是重複造輪子。隨著 agent 生成內容的成本越來越低，開發者與 AI 都更傾向直接重新生成一份，而不是搜尋、理解、複用既有成果。研究發現，大量 skill 高度相似，許多 agent 提交的程式碼修復請求最終未被合併，其中相當一部分原因就是同樣的問題早已被別人解決。這說明在缺乏全局協調時，AI 很容易放大重複建設與資源浪費。

總結來看，Token Maxing 的失敗，不只是一次短期泡沫破裂，更像是 AI 產業從狂熱走向現實的過程。它暴露了兩件事：第一，現階段 agent 的能力還不足以在所有任務上穩定提效；第二，企業也還沒有建立出一套成熟的 AI 使用方法，能真正避免浪費並轉化為業務成果。

更深一層說，這其實是經濟學中「生產率悖論」的再次上演。像電力、電腦、網際網路這些通用技術，在剛出現時都曾經歷過「技術進步很快，但整體產出沒有立刻提升」的階段。因為真正的瓶頸，往往不在單一技術本身，而在與之互補的流程、制度、組織與人類能力。

所以，Token Maxing 的退潮不一定代表 AI 沒有未來。相反地，它可能只是提醒大家：AI 要真正產生價值，不能只看 token 花了多少、程式碼寫了多少，而要看它是否穿透整條價值鏈，最終轉化成可交付、可使用、可驗證的成果。

[AI 分享] AI三巨頭分道競爭，產業進入下半場

 [AI 分享] AI三巨頭分道競爭，產業進入下半場

摘要：Google拚生態、Anthropic拚深度、OpenAI拚商業化，AI競爭重心正從模型能力轉向產品與服務。

內容:

AI產業正在進入一個新的競爭階段。5月19日，Google、Anthropic、OpenAI幾乎在同一時間做出重大動作，但三家公司選擇了完全不同的方向，也象徵AI競爭正式走入下半場。

Google在當天一口氣發布28項產品與功能，企圖全面擴張AI在日常生活中的滲透率。重點包括可長時間在背景運作的AI管家「Gemini Spark」，即使手機螢幕關閉，仍可協助處理郵件、追蹤任務與安排日曆；新一代旗艦模型「Gemini 3.5 Flash」，主打更快的速度；以及可24小時監控新聞、部落格與社群媒體動態，並主動推送資訊的AI資訊代理。除此之外，還涵蓋影片生成、程式設計平台升級與智慧眼鏡等。

Google的核心戰略很明確，不只是推出單一強產品，而是藉由Gmail、地圖、搜尋、YouTube等既有生態系，打造更難被取代的AI入口。它比的不是單點模型最強，而是誰能讓使用者更離不開自己的整體服務體系。

另一方面，Anthropic則走向更聚焦、更深度的路線。當天，知名深度學習專家加入Anthropic，引發AI圈高度關注。這類頂尖人物的轉換，不只是職涯選擇，更像是在替某種技術路線投票。

Anthropic從一開始就強調兩件事：打造最好的模型，以及確保模型對人類安全。這種堅持並非口號。此前美國國防部曾要求AI供應商移除部分安全限制，允許軍方將AI應用於所有合法用途，Google與OpenAI選擇接受，但Anthropic拒絕放寬自主武器與大規模監控相關紅線，甚至因此失去高額合作機會。

Anthropic的特別之處，不只是有原則，而是把這種高標準落實到產品上。其模型與工具在長推理、深度分析與程式設計領域被不少人視為頂尖選擇。它不追求產品數量，也不急著鋪滿生態，而是專注在做出夠強、夠硬的產品，並吸引最優秀的人才。

至於OpenAI，則走出第三條路：商業化與速度。Sam Altman在同一天宣布推出1到3年的算力承諾合約，提供折扣價格，並強調市場對算力確定性的需求正在上升，未來一段時間算力緊缺可能仍會持續。同時，OpenAI也對特定創業圈提供token資源支持。

這背後代表的是，OpenAI正在把算力當成一種可預售的資源，近似「算力期貨」。邏輯很直接：趁AI需求持續暴增、算力仍然稀缺時，用長約換取客戶承諾、穩定現金流與可預期收入。

OpenAI目前的處境相對微妙。它仍然是全球最具知名度的AI品牌之一，但在模型前沿能力上，未必始終全面領先；在產品生態鋪設上，也面臨Google這類巨頭的壓力。因此它選擇更務實地把品牌、用戶規模與商業模式轉化為護城河。與其只比誰模型更聰明，不如先比誰能更快鎖定客戶、把算力變現。

這三條路之所以在此刻明顯分叉，根本原因在於AI競賽的重心變了。從2023年到2025年上半，市場比的是誰先做出GPT-4等級的模型，模型能力幾乎代表一切。但到了下一階段，頂尖模型之間的差距逐漸縮小，多模態、長推理、程式設計、日常任務與工具整合能力，各家都開始形成自己的強項，已經很難再出現一家全面碾壓所有對手的情況。

於是，Google選擇了廣度，靠生態綁定使用者；Anthropic選擇了深度，專注做最強的細分產品；OpenAI則選擇了速度與商業化，搶先鎖定資源與現金流。

對一般AI使用者來說，這其實是好事。因為市場不再只有單一強者，而是三家各自擅長不同場景。未來關鍵不再是找「最強AI」，而是找「最適合自己需求的AI」。

如果偏向搜尋研究、多模態內容製作，可優先考慮Gemini；如果需要深度分析、長文撰寫、程式設計，Anthropic系統可能更合適；如果重視日常對話、快速原型與成熟工具體驗，OpenAI仍然具有明顯優勢。理解各家定位、依需求組合使用，往往才是最實際的策略。

總結來看，這一天三家公司同時亮牌，不只是新聞事件，更是一個訊號：AI模型本身的絕對差距正在縮小，未來競爭將更集中在產品、服務、商業模式與使用者體驗。對大公司而言，這是新一輪戰略分化的開始；對創業團隊而言，則意味著更需要找到差異化定位；而對普通使用者而言，真正重要的是建立屬於自己的AI工作流，讓工具為自己提升效率與產出。

AI下半場，才正要開始。

[AI 分享] 用對AI的方法

 [AI 分享] 用對AI的方法

摘要 : 多數人用不好AI，不是提示詞不夠長，而是把自己的有限理解硬套給AI。真正有效的方法，是提供優質樣本，讓AI自行拆解規律。

內容:

大部分人用不好AI的核心原因，在於他們常常把AI變成「另一個維度的自己」。換句話說，很多時候提示詞寫得越詳細，反而越容易把AI的表現限制在自己的理解範圍內，導致結果看起來很假、很僵硬，缺少真正的味道。

以AI寫爆款文案為例，很多人會先告訴AI「你是一位資深文案專家」，再補充一大堆風格、原則與技巧，甚至寫上數千字提示詞。但最後產出的內容，往往只是表面像，實際上沒有神韻。也有人研究某些博主的影片後，整理出短句、犀利語言、反問等特徵，再把這些規則餵給AI，結果依然只是「形似神不似」。

問題的本質在於，這些做法都是把自己腦中對某種風格的理解，翻譯成一套規則，然後要求AI照著執行。這在某些場景可以成立，但在更多創造性工作裡，往往註定失敗。

使用AI大致可以分成兩種類型。第一種是流程明確、步驟清楚的任務，例如翻譯、資料整理、格式轉換，或將A平台內容搬到B平台並做固定調整。這類工作輸入、輸出和中間流程都能清楚定義，使用詳細提示詞或智慧體處理，通常效果很好。

第二種則是創造性任務，例如希望AI模仿某位博主，寫出相似風格的爆款內容。這時候，單靠自己總結幾條特徵，再轉成提示詞讓AI模仿，通常不夠。因為你以為自己抓住的是對方成功的秘密，但實際上往往只抓到表層。

這就像學做菜。你去餐廳吃到一道很好吃的菜，或許能分辨出用了醬油、蠔油，火候比較大，於是把這些寫成菜譜讓別人照做。但成品通常還是差很遠。原因是廚師真正的能力，不只是材料和步驟，而是火力、翻鍋節奏、下料時機，甚至是一種說不清楚的手感與經驗。你從外部觀察後得到的，只是你理解中的那道菜，而不是廚師真正做出的那道菜。

因此，正確做法不是先替AI總結規則，而是直接把作品本身交給AI。讓AI看到真正的大量樣本，例如把某位高手的十篇、幾十篇，甚至上百篇作品直接提供給它，然後只問一句：「幫我分析這些內容有什麼共性？」

大語言模型最強的能力，本來就不是乖乖執行你主觀整理出的規則，而是進行大規模模式識別。它是從海量文本中訓練出來的系統，只要給它足夠多的樣本，它就能提取出連創作者自己都未必意識到的規律。

實際上，當把一個人表現最好的幾十條影片文案都交給AI分析，而且不先預設風格、不限定維度時，AI拆解出來的結果，往往比人自己反覆觀看後總結得更完整。它可能分析出平均句長、短句比例、反問句常出現的位置、正文結構偏遞進還是分點、開頭啟動了什麼樣的心理機制等。很多細節，往往是人看到AI分析後，才恍然大悟原來一直存在，只是自己過去根本不會想到去觀察。

這裡有一個很核心的差別。若你先研究高手，再把自己的研究成果寫成提示詞，那AI產出的上限，其實就是你的認知上限。你不知道的東西，就無法寫進提示詞裡。反過來，如果你把高手的作品直接交給AI，讓它自己拆解規律，那你用到的就是AI最強的模式識別能力，這才是真正發揮它價值的方式。

所以，與其在提示詞裡憑空塑造一個你想像中的高手，不如去現實中找到真正的高手與真實作品，然後大量提供給AI，讓它自己分析、自己總結。你的任務不是教AI怎麼做，而是選對樣本、問對問題。

說到底，AI時代真正重要的分水嶺，是你是否願意承認：在許多創造性領域裡，自己的理解其實不足以直接定義想要的結果。一旦承認這一點，你就不會再執著於把有限認知硬塞給AI，而會把自己的角色，從「教AI做事的人」，轉變成「為AI選素材、提問題的人」。這種策展式的能力，才是更值得修煉的方向。