[AI 影響] 谷歌 Interactions API 改寫 AI 應用開發生態

 [AI 影響] 谷歌 Interactions API 改寫 AI 應用開發生態

摘要 : 谷歌將 Interactions API 全面可用化，透過原生記憶、長週期任務與工具整合，大幅降低 Agent 開發與商業落地門檻。

內容:

谷歌近日低調將 Interactions API 推向全面可用階段。這不只是一次 API 名稱或版本的更新，而是代表 AI 應用開發的核心路線，正從單純的大模型對話，轉向原生 Agent 驅動的應用架構。換句話說，開發者不再只是「和模型聊天」，而是能透過 API 直接驅動 Agent 執行更複雜、更接近實際業務的工作。

過去幾年，各家大模型公司持續競逐模型能力、推理表現與榜單成績，但開發者真正面臨的難題，往往不是模型夠不夠聰明，而是如何用低成本、穩定的方式把模型接進真實業務流程。為了讓模型具備記憶、讀取私有資料、呼叫內部系統與工具，開發者往往需要依賴大量外部框架與自行拼裝的程式碼，導致整體系統脆弱、維護成本高，稍微複雜的多輪互動或高併發場景就可能失效。

谷歌這次的核心動作，是把原本最繁雜、最不穩定的 Agent 基礎能力，直接下沉到基礎設施層。Interactions API 提供統一的底層呼叫方式，讓開發者不必在基礎模型與複雜 Agent 之間切換不同端點或學兩套開發模式。實作上，只要調整請求參數，就能從一般模型呼叫切換到具備長程推理能力的 Agent，甚至也能接入企業自定義、私有化部署的 Agent。這代表的不是單純少寫一些程式，而是整體底層架構被重新整理。

其中最關鍵的一點，是服務端狀態管理，也就是原生記憶能力。傳統無狀態 API 模式下，若要做多輪對話或長任務，客戶端每次請求都得重新附帶完整歷史紀錄。這不只浪費頻寬，也會大幅增加 Token 成本；一旦網路波動、斷線或頁面刷新，累積的上下文還可能直接消失。現在，Interactions API 直接在谷歌服務端保存互動狀態，將每次互動定義為可追蹤的物件。開發者後續只要提供歷史 ID，模型就能快速讀取先前上下文、工具呼叫紀錄與推理流程，讓客戶端明顯輕量化，也降低了大規模商業部署時的成本壓力。

這種做法實際上也反映出當前 AI 競爭已不只是模型能力之爭，更是算力、網路與基礎設施能力之爭。即使底層晶片效能持續提升，在高併發與長上下文場景下，成本依舊驚人。谷歌透過服務端原生優化上下文快取與狀態流轉，相當於在基礎設施層面替企業節流，這也是只有掌握大規模算力集群的公司才能做到的事情。

另一個極具商業價值的更新，是後台長週期執行能力。真正能創造價值的 Agent，不會只是幾秒鐘內回覆幾句文字，而可能需要花上數十分鐘甚至數小時，去撰寫深度報告、交叉比對大量資料、執行多步驟工具鏈任務。傳統長連線模式下，客戶端若長時間收不到回應，往往就會超時中斷，任務直接報廢。現在透過新的 API，開發者可在請求中指定後台執行模式，讓 Agent 在雲端脫離客戶端持續運作。即使本地程序關閉，任務仍能在伺服器端繼續完成，最後再回傳結構化結果。這讓真正重型的商業自動化場景首次具備大規模落地的基礎。

在外部工具與企業系統整合方面，Interactions API 也明顯往前推進了一步。它與模型上下文協議（MCP）深度整合，讓遠端協議伺服器能以標準工具形式直接提供給模型使用。這代表 Agent 可以在合規憑證保護下，以更低成本接入企業核心資料庫、本地私有程式環境與第三方應用系統，打通了 Agent 與真實商業數位世界的連結。對企業來說，這不只降低介接成本，也有助於統一資料安全與工具呼叫規範。

谷歌官方同時也已明確將舊版呼叫介面標示為過時。這不只是產品更新，而是一種非常強勢的戰略訊號：未來的生態核心將圍繞原生 Agent 展開。谷歌顯然希望透過 Interactions API 這套統一標準，把所有需要 Agent 能力的開發者與企業，逐步綁進自己的雲端生態系中。

對許多技術團隊而言，這正是一道現實選擇題。過去大量時間耗費在處理上下文遺失、網路抖動、狀態儲存與多工具編排上，尤其是在銀行、供應鏈、智慧客服等需要長輪次、高上下文一致性的場景，傳統無狀態 API 幾乎成了專案推進的瓶頸。現在谷歌把這些基礎問題做成原生能力，等於直接砍掉了許多原本依附在 AI 工具鏈周圍的中介層價值。

這也意味著，過去兩年大量建立在 Agent 開發框架、生態工具鏈與上下文管理方案上的公司，可能面臨巨大壓力。當原本需要靠外部框架實現的記憶管理、長週期執行、工具整合與狀態恢復，都被雲端基礎設施直接吸收後，這些工具的差異化空間將被快速壓縮。某種程度上，這像是一場針對中介軟體層的基礎設施級清場。

從更宏觀的角度看，谷歌這一步也反映出 AI 競爭正從模型參數與智商指標，轉向工程落地能力、成本控制、全球骨幹網路與分散式算力管理。若只看模型能力，谷歌未必能短期內完全壓制 OpenAI 等對手；但若把競爭拉到底層工程、雲端託管與大規模商業化運營，谷歌的優勢就會變得非常明顯。Interactions API 本質上，是把谷歌多年累積的網路工程與分散式計算能力，直接封裝成面向開發者的武器。

不少一線架構師甚至認為，未來軟體開發的邊界可能不再明確區分前端與後端，而會變成由大量透過 Interactions API 串聯起來的分散式 Agent 網路。每個 Agent 負責處理一個垂直任務節點，彼此之間的溝通、狀態流轉、工具協作與長任務調度，全部交給底層雲基建完成。在這種模式下，開發者的工作重心將更偏向權限設計、工具邊界規劃與商業流程拆解。

更深一層來看，當越來越多企業把核心業務邏輯託管到這套 API 上，谷歌未來可累積的將不只是用量，而是大量真實世界中的 Agent 協作資料，例如工具調用模式、任務失敗率、商業流程效率與長週期執行行為。這些資料將成為極高價值的隱性資產，並可能反過來強化下一代模型對商業任務與工具使用的理解能力，進一步形成生態閉環與資料飛輪。

因此，這次更新傳遞的訊號其實很清楚：AI 應用開發野蠻生長、靠套殼與淺層封裝快速融資的時代，可能正在結束。未來比拼的不只是誰有模型，而是誰能把 Agent 真正嵌入複雜商業流程，替企業節省成本、提升效率、創造實際利潤。谷歌的 Interactions API，正是在這個轉折點上，試圖成為新的底層標準。

對整個產業而言，這不只是一次產品升級，而是一場開發方式、成本結構與生態主導權的重新分配。若這套標準被廣泛接受，開發者未來要遷移平台的成本也會顯著提高，因為不只是換一把 API Key，而是整個記憶機制、工具編排、長任務管理與系統架構都可能深度綁定在谷歌雲端之上。這也正是谷歌此舉最具戰略意義的地方。

[AI 分享] MCP與Skill的區別

 [AI 分享] MCP與Skill的區別

摘要：MCP負責連接工具與外部系統，Skill負責提供知識與方法，兩者搭配可讓AI既能做事也能做好事。

內容:

MCP可以理解為AI連接外部世界的通用介面，相當於幫AI配上手和工具。當AI接上MCP之後，就能夠查詢資料庫、開啟瀏覽器操作按鈕、發送微信，或呼叫各種API。它主要擴充的是AI「能做到什麼」。

Skill則比較像是一份說明書，將一套做法、規範或專業知識整理打包，在需要時自動載入。它相當於給AI一本專業手冊，主要擴充的是AI「能把事情做得多專業」。

兩者的差別可以用一句話概括：MCP提供的是工具與連線，讓AI可以做新的事情；Skill提供的是知識與方法，讓AI可以把事情做得更正確、更完善。

從技術角度來看，MCP通常需要運行一個服務，並與外部系統連接；而Skill通常只是幾個檔案，可以按需載入，成本相對較低。

在選擇上，如果目的是讓AI連接外部資料、執行操作，就適合使用MCP；如果目的是讓AI掌握某套專業做法或工作流程，就適合使用Skill。最理想的方式是兩者結合，讓MCP提供工具，Skill負責教AI如何把工具用好。A

[AI 轉變] 程式設計師與 AI 協作的觀念翻轉

 [AI 轉變] 程式設計師與 AI 協作的觀念翻轉

摘要 : 從一開始不相信 AI 能寫程式，到實際使用後幾乎不再手寫程式碼，展現了開發工作模式的巨大轉變。

內容:

一開始，對於 AI 寫程式這件事，原本抱持非常強烈的懷疑態度。認為複雜的業務邏輯、整套系統架構，以及多年累積下來的實戰經驗，不可能輕易被 AI 取代。甚至覺得，自己十年踩坑換來的能力，不會被一個工具說替代就替代。

當時也曾簡單試用過 Copilot，但初步感受並不深刻，覺得它頂多只能補幾個變數名，像是個小玩具，離真正能參與核心開發工作還差得很遠。因此原本的判斷是，真正複雜且核心的邏輯，最後還是得靠工程師親手完成。

不過，後來實際持續接觸之後，想法開始出現變化。雖然核心邏輯的理解仍然重要，但在實際寫程式的過程中，工作方式已經逐漸轉成以「和 AI 對話，讓 AI 輸出程式碼」為主，而不是自己一行一行手寫。

回過頭來看，曾經還公開放話說完全不相信 AI，如今的態度卻變成：不是不信 AI，而是不信自己竟然還需要親手寫程式碼。這種轉變本身就帶著很強的反差與幽默感。

到了現在，如果問一天手寫多少行程式碼，答案幾乎是零行。日常工作的重心，也不再只是傳統印象中的敲程式，而更像是在工作中分享、討論，甚至到處講述程式設計師與 AI 之間的各種段子與新型態協作方式。

整體來說，這不只是對工具的重新評價，也是一種開發習慣與職能角色的變化：從質疑 AI，到依賴 AI，再到幾乎完全改變寫程式的方式。

[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選素材、提問題的人」。這種策展式的能力，才是更值得修煉的方向。

[AI 分享] 大腦啟動規則

 [AI 分享] 大腦啟動規則

摘要 : 靈感常在放空時出現，關鍵不在意志力，而在降低啟動摩擦、設定貼邊難度，並用簡單流程快速進入深度工作。

內容:

你可能常有這種經驗：洗澡、走路、搭地鐵，甚至上廁所時，突然想通卡了一整天的問題；但真正坐到桌前準備工作時，反而發呆、分心、遲遲進不了狀態。這種差距背後，其實藏著一套大腦啟動工作的規則。只要理解它，不一定要有安靜房間或整段空檔，在零碎時間裡也能更快進入深度工作。

很多人以為自己做不下去，是因為不夠自律，但研究指出，真正的問題常是「注意力殘留」。當你從一件事切到另一件事，前一件事留下的思緒碎片還會佔據工作記憶，讓你雖然人坐在書桌前，大腦卻還停留在剛剛的訊息、影片或聊天內容上。於是你一天下來覺得很累，但真正專注工作的時間可能很少，最耗能的往往不是工作本身，而是開始前的反覆空轉。

除了注意力殘留，還有一個更隱蔽的因素是「啟動摩擦」。同樣的人、同樣的工作，若檔案早已開好、資料就放在手邊、手機也被收起來，往往幾分鐘就能開始；反過來，如果還要找檔案、開軟體、想怎麼起頭，大腦就會判定這件事太麻煩。BJ福格的模型指出，行為要發生，需要動機、能力與提示同時具備；很多時候不是你不想做，而是環境把開始的門檻抬高了。若能提前用「什麼時間、在哪裡、做什麼」的執行意圖鎖定行動，啟動就會容易得多。

但能開始，不代表能持續。想進入像玩遊戲那樣的投入狀態，還需要符合「心流」條件：目標清楚、反饋即時、挑戰與能力匹配。其中最重要也最容易忽略的是任務難度要剛剛好，也就是所謂的「貼邊難度」——不能太簡單讓人無聊，也不能太難讓人想逃。只有當任務比你當前能力高一點點，剛好需要專注、又不至於崩潰時，大腦才最容易咬住不放。

因此，實作上的關鍵是把任務切小，切到15分鐘內能看到一個結果。像寫文章先寫300字開頭，做方案先列出第一頁框架，練琴先單獨練最難的幾個小節。這種可見的小交付物，既能降低壓力，也能快速提供回饋，幫助大腦逐步進入更深的專注狀態。對創造性工作來說，過高壓力反而有害，適中的喚醒程度通常表現更好。

如果環境不理想，也可以靠一套隨時可用的啟動流程：第一，只要求自己先做15分鐘，不追求一次做完；第二，把入口縮小到30秒內能完成的第一步，直接開始；第三，為每個小進展設計可見回饋，例如打勾或劃線；第四，減少干擾，把手機翻面、關掉無關頁面、移開雜物。走神、拖延、遲遲無法開始，很多時候並不是你意志力差，而是你還沒用對大腦啟動的方式。

[AI 觀點] 程式設計師在AI時代真正值錢的能力，是「寫得慢」

 [AI 觀點] 程式設計師在AI時代真正值錢的能力，是「寫得慢」

摘要 : AI讓寫程式碼速度不再稀缺，程式設計師真正值錢的，是能慢下來做架構、決策與品質把關。

內容:

在AI時代，程式設計師最稀缺、最值錢的能力，可能不是寫程式碼快，反而是「寫得慢」。這裡的慢，不是摸魚或拖延，而是先思考、先設計、先判斷，再動手實作的能力。

過去初級與高級工程師的重要差距，常常來自熟練度與輸出速度。老手熟框架、熟API、熟業務，寫起來自然比新手快很多。但現在AI已經能在極短時間內生成大量看似合格的程式碼，單純比拚敲鍵盤速度，人的優勢幾乎被抹平。當所有人都能快速產出程式碼時，「快」就不再是核心競爭力，而成了廉價能力。

AI普及後，程式設計師的分層會更明顯。初級工程師容易沉迷於速度，拿到需求就直接交給AI生成，快速接受建議、快速拼出頁面與介面，誤以為是自己效率提高了，實際上只是模型在幫忙加速。中級工程師開始處理較複雜的功能，能利用AI做模組整合，讓系統跑起來。但真正高級的工程師，核心能力不在產碼，而在決策。

高級工程師拿到需求時，第一步不是立刻生成程式碼，而是先分析需求、拆解系統、釐清業務邊界、設計資料表與架構，甚至思考未來幾年的擴展性。他們關注的不只是「這個功能能不能做出來」，而是「這樣設計未來會不會崩」、「下次需求變更時需不需要整個重構」。這種看起來比較慢的過程，才是真正有價值的地方。

所謂真正的慢，是一種「謀定而後動」的能力。AI可以當油門，但方向盤一定要握在人手上。你必須給AI清楚的上下文、明確的業務邊界與技術限制，才能讓它產出真正有用的結果。如果自己都沒想清楚，就只是丟一堆模糊需求給AI，那它雖然能很快生成程式碼，卻很可能產出一堆難維護、易出錯、與需求偏離的內容。

因此，比起快速生成程式碼，更重要的是仔細審視AI的輸出。包括review程式碼品質、檢查邏輯漏洞、確認併發安全、記憶體問題，以及判斷設計是否合理。這些工作看起來慢，但這正是工程師不可替代的價值。真正要負責上線品質與系統安全的人，不能只追求速度，否則程式碼寫得越快，翻車也可能越快。

AI讓寫程式碼的成本不斷下降，但讓系統做出正確決策的能力，價值卻變得越來越高。真正厲害的技術人，不一定天天親手敲很多程式碼，但他們知道系統該往哪裡走，也能判斷AI提出的方案到底是好解法還是陷阱。

所以，與其和AI比誰寫得快，不如把節奏放慢，把腦力放回需求理解、架構設計、邏輯判斷與品質控制上。在AI時代，能穩定思考、清楚決策、正確駕馭AI的人，才是最不容易被取代的那一群。

[AI 分享] 長專案中如何讓AI回到受控狀態

 [AI 分享] 長專案中如何讓AI回到受控狀態

摘要 : 長視窗易讓AI飄移，關鍵是分階段拆解、適時換視窗，並在每次開工前重新校準任務邊界。

內容:

很多人在用AI處理稍微長一點的專案時，都會遇到同樣的問題。前面對話看起來很正常，但隨著聊天視窗越來越長，AI開始偏離原本任務。你讓它修一個小問題，它卻順手改了其他地方；你讓它做驗收，它一邊檢查一邊直接修改，最後驗收又變成開發。即使你事先寫了規則或文件，AI口頭上說會遵守，實際執行時還是很容易被上下文帶偏。

這篇內容的核心重點，是當視窗變長後，如何把AI重新拉回可控狀態。第一個方法是「勤換視窗」，但換視窗真正困難的地方，不是開新聊天，而是如何把舊視窗的重要工作狀態正確交接到新視窗。很多人會重新講背景，卻漏掉最重要的執行資訊，例如目前處於哪個階段、已完成哪些工作、下一步只做什麼、依據哪些文件、驗收標準是什麼。只有把這些內容整理清楚放到新視窗最前面，AI才有機會從舊的混亂上下文中被拉回來。

至於什麼時候該換新視窗，可以看兩個訊號。第一是階段切換，例如需求整理完成後要進入開發，或一輪修復完成後準備驗收，只要工作階段改變，就很適合開新視窗。第二是AI已經出現明顯飄移，例如回覆變慢、答非所問、重複內容，或你叫它做A，它總是順手去碰B。這時候不要硬聊，應該先做交接，再換到新視窗繼續。

換視窗也分兩種情況。如果目前視窗還能正常工作，就在舊視窗直接要求AI整理一份「新視窗工作交接提示詞」，內容要包含專案目標、已完成階段、當前進度、正在處理的檔案或模組、下一步任務、必須遵守的文件、驗收標準與已知風險，而且要明確要求它「不要繼續開發，只做交接」。這句話很重要，因為此時你的目標不是讓它往前做，而是把真正有用的資訊整理出來。

如果目前視窗已經無法正常工作，例如內容混亂、一直轉圈、總結品質也變差，那就不要再依賴它原地整理，而是讓新視窗回頭讀取舊對話，再先做交接整理。重點依然是不要直接開發，而是先確認已完成與未完成內容、目前階段、關鍵限制、風險點與下一步計畫，同時再次確認規則文件是否真的被遵守。

第二個方法，是每次開工前都先補一次「階段邊界」。除了換視窗以外，還要養成一個習慣：每次開始工作前，先明確告訴AI現在是什麼階段，例如需求、開發、測試或驗收，並要求它先複述自己理解的階段目標、當前任務、禁止事項與驗收標準，等確認無誤後再開始。這樣做的目的，是讓AI在每次開工前重新校準邊界，不要帶著上一階段殘留的脈絡一路衝下去。

不過這種方法也有前提，那就是目前視窗還不能太長。如果上下文已經嚴重失控，只靠補一句提示詞效果有限，這時還是應該先換視窗、完成交接，再在新視窗重新建立規則與範圍。

最穩定的做法，其實是從一開始就不要把所有事情混在一起。需求、前端、後端、修Bug、測試、驗收如果全部塞進同一個長視窗，專案本身就容易變糊，AI自然更容易飄。比較好的方式，是把工作拆細，分成一個個階段文件來推進。每個階段只處理一件主要事情，並清楚定義目標、依據文件與驗收標準。這樣即使AI偏了，你也有文件可以把它拉回來；即使要換視窗，也有明確的交接依據，不會因為上下文丟失而重來。

總結來說，AI在長視窗中飄移是很正常的現象，不能只靠一句「請嚴格遵守規則」來硬壓。真正有效的方法有三個：第一，先把工作拆成清楚的階段，建立文件化底座；第二，當階段結束或AI明顯飄移時，就及時換視窗並做好交接；第三，每次開工前都重新確認階段目標、任務邊界與驗收標準。只要這三件事做好，即使AI有飄移傾向，也比較容易重新回到可控狀態。

[AI 分享] 打造好用的 Skill 方法

 [AI 分享] 打造好用的 Skill 方法

摘要 : 重點不在規則多，而是寫清觸發場景、任務邊界、輸出格式與示例，才能做出真正好用的 Skill。

內容:

cloud 官方文件指出很多人寫 Skill 效果不好，不是因為不夠努力，而是沒有抓到設計重點。真正好用的 Skill，不是靠堆疊大量規則，而是要讓系統清楚知道「什麼時候該被呼叫」、「被呼叫後要完成什麼」、「最後要如何輸出」。

先介紹 Skill 的基本結構。標準的 skill.md 分成兩部分：上方是 YAML 配置區，包含名稱、觸發時機與是否需要額外權限；下方是 Markdown 內容區，負責描述 Skill 被調用後的具體執行方式。示範案例是一個名為「meeting to action」的 Skill，功能是把會議記錄轉換成結構化的行動項清單。

其中，配置區最重要的欄位是 description。這一段文字會被系統拿來做語意匹配，判斷目前對話是否需要自動載入這個 Skill。若 description 只寫「會議記錄整理工具」這種模糊描述，系統無法理解具體用途與觸發時機；但若寫成「把會議記錄或會議內容整理成結構化的行動項清單，當使用者提供會議逐字稿、錄音轉文字，或要求整理會議與提取行動項時觸發」，就能明確提供場景、關鍵詞與觸發條件。作者也提醒，description 有字數顯示限制，因此最重要的觸發詞要盡量放在前面。

接著內容區的寫法。第一步不是急著列規則，而是先定義任務本身，也就是一句話講清楚這個 Skill 的核心工作。這樣系統才知道執行的終點與邊界，例如這個案例的重點不是做全面摘要，而是只聚焦在行動項、決策與待澄清問題。

第二步是定義輸出格式，而且越具體越好。作者示範的輸出包含三部分：第一是行動項清單，每一條都要有負責人、任務、截止時間與優先順序；第二是本次會議的核心決策，列出兩到四條；第三是待澄清問題，用來標記責任不清或尚未解決的事項，若沒有則可省略。明確的格式設計，能讓每次輸出維持穩定一致，不會忽長忽短、忽散忽亂。

在規則設計上，作者特別強調「少而有力」。很多人習慣寫出一長串像是「保持客觀」、「語言簡潔」、「注意格式」這類看似專業、實際卻缺乏約束力的規則。真正有效的規則，應該要能落地執行，例如：只提取明確任務、負責人不清楚就標示待定、截止時間未說明就寫未定、不要自行猜測內容、行動項要用動詞開頭等。這些規則能直接限制模型最容易出錯的地方。

示例是最常被忽略、卻極其重要的一部分。相較單純描述，完整的輸入輸出示例更能讓系統理解你想要的格式、資訊密度與判斷方式。像是如何區分行動項與決策、如何標記待定、如何處理未解決問題，透過一個涵蓋多種情況的示例，往往比十條抽象規則更有效。

最後，整理出三條 Skill 寫作原則。第一，先寫 description，再寫內容，因為先釐清觸發場景，後續設計才有方向。第二，一個 Skill 只解決一件事，不要同時想讓它整理會議、寫週報又寄信，否則容易失焦。第三，Skill 與 cloud.md 不能混用，cloud.md 適合放每次對話都要載入的固定規則與背景，而 Skill 則適合做按需載入的場景化指引。

整體來說，核心觀點很明確：Skill 不是越長越好，也不是提示詞的堆砌，而是一份精準的操作手冊。只要把觸發條件、任務邊界與示範方式設計清楚，就能寫出真正實用、穩定又高效的 Skill。

[AI 觀點] AI工具下的程式設計師內耗危機

 [AI 觀點] AI工具下的程式設計師內耗危機

摘要 : AI雖提升寫碼速度，卻可能壓縮思考、削弱除錯與架構能力，讓工程師陷入表面高效、實則退化的困境。

內容:

最近不少程式設計師都強烈感受到，真正變捲的不是找工作，而是日常開發工作本身。自從團隊導入 AI 工具後，管理者對開發效率的期待明顯提高，原本需要三天完成的任務，現在可能被認為一天就該做完。因為在許多人眼中，既然程式碼可以由 AI 產出，那工程師只要「按幾個鍵」就能交付成果。

這樣的變化不只來自上層壓力，團隊內部也開始出現一種比拼速度的氛圍。大家互相比誰更會用 AI、誰產出更快，再加上網路上大量渲染「幾秒生成系統」、「一天完成複雜專案」的內容，讓整個開發現場變得越來越焦躁，也越來越失真。

表面上看，AI 的確讓寫程式變快了，但真正令人擔心的是，工程師主動思考的空間正在被嚴重壓縮。過去接到需求後，會先理解問題、設計系統、規劃資料表，再一步一步親手完成程式碼，過程中不斷除錯與重構。雖然慢，但每一段程式碼都經過自己的思考，系統脈絡也更清楚。

現在在時程壓力下，許多人逐漸變成把需求丟給 AI、等 AI 生出程式碼、再把錯誤訊息丟回去修正的工作模式。人腦不再主導開發，而是淪為 AI 與需求之間的傳話工具。這種流程看似高效，實際上卻讓思考能力慢慢退化，長期下來會讓工程師失去最核心的價值。

其中最明顯被削弱的能力之一，就是除錯能力。以前自己寫的程式出錯時，必須看日誌、打斷點、追原始碼、理解底層機制，雖然痛苦，卻能一步步累積真正的技術內功。現在很多人一遇到錯誤，第一反應就是交給 AI 處理。AI 若修好了，自己未必真的知道原因；AI 若修不好，就只能反覆貼錯誤訊息碰運氣。一旦遇到複雜問題，例如分散式鎖、高併發異常或記憶體溢位，若基礎功不夠，往往連問題方向都抓不到。

另一個正在被侵蝕的，是架構與系統拆解能力。AI 擅長提供片段式答案，但企業級專案需要的是全局思維，包括模組拆分、邊界定義、解耦設計與整體架構判斷。當工程師長期習慣讓 AI 幫忙「切碎」問題、提供局部解法，就可能逐漸失去獨立拆解大型系統的能力。一旦系統規模變大、服務開始拆分、邏輯變複雜，AI 很容易因上下文不足而產出錯誤建議，這時若工程師自己也缺乏判斷能力，就很難有效修正。

這種現象帶來的，不只是效率提升，而是技術圈潛在的全面平庸化。問題不在於 AI 會不會寫程式，而在於工程師是否把最有價值的思考與決策也一併外包了。軟體開發中最不值錢的從來不是敲鍵盤，而是鍵盤背後的理解、判斷與取捨。

因此，真正值得警惕的不是 AI 讓人寫更少程式，而是它讓人少想程式。如果工作環境只追求速度，把 AI 當成思考替代品，那麼工程師的核心競爭力就會被一點一滴掏空。面對這個趨勢，最重要的不是拒絕 AI，而是重新思考：在 AI 時代，真正稀缺的能力，依然是獨立思考、深度理解與做出正確技術決策的能力。

[AI 分享] Codex AGENTS.md 實戰寫法

 [AI 分享] Codex AGENTS.md 實戰寫法

摘要 : 善用精簡的 AGENTS.md，可大幅提升 Codex 輸出品質與專案協作效率。

內容:

AGENTS.md 是一份提供給 Codex 的專案使用說明。每次 Codex 啟動時，都會自動讀取這個檔案，因此不需要手動貼上內容，也不需要每次重新說明專案規則。只要在終端輸入指定初始化指令，就能依照當前專案自動生成模板，再依需求進行修改即可。

可以把 AGENTS.md 理解成 Codex 的專案入門指南。若沒有這份檔案，Codex 每次都像剛加入專案的新手，無法快速掌握規則；有了它，Codex 一開始就知道專案怎麼執行、有哪些限制，以及提交前應遵守哪些流程，整體使用體驗會明顯提升。

撰寫 AGENTS.md 時，不建議把整份專案文件全部貼進去。因為它有 32KB 的長度限制，內容太多不但可能被截斷，還可能讓重要規則被忽略。最理想的做法，是把內容控制在十幾行內，只保留最關鍵、最具操作性的資訊。

建議優先寫五類內容。第一是專案執行方式，例如怎麼安裝依賴、怎麼跑測試、使用什麼包管理器與工具。第二是提交前必須完成的動作，例如 lint 與 test 必須全部通過。第三是禁止變更的內容，例如不要修改 ENV 檔案或既有 migration。第四是專案特殊約定，例如 commit message 格式、變數命名規則。第五是新增依賴的規矩，例如加入新的正式環境依賴前需要先確認。

撰寫時也要避開幾個常見問題。第一，不要只寫空泛態度，例如「請重視程式碼品質」，這類描述對 Codex 幾乎沒有實際幫助，應改成具體可執行的命令與步驟。第二，不要把它本來就能從專案中直接判斷的資訊重複寫進去，否則只會製造噪音。第三，不要寫完後就放著不管，因為專案規則會隨時間變動，應定期回頭檢查並刪除已經不必要的內容。

進階用法是分層管理。若專案屬於單一倉庫但包含多個服務，例如前端與後端採用不同技術棧，建議在根目錄放通用規則，再於各服務子目錄內建立各自的 AGENTS.md，分別定義專屬的測試命令與開發規範。Codex 會依所在目錄自動套用對應規則，而且越接近當前目錄的設定優先度越高。

另外，如果只是想暫時調整規則，又不想修改原本的 AGENTS.md，可以在同目錄新增 Agents Override MD。這樣就能臨時覆蓋原設定，刪除後即可恢復，使用上相當彈性方便。

總結來說，AGENTS.md 的重點不是寫得多，而是寫得準。只要內容精簡、明確、可執行，就能讓 Codex 更理解你的專案脈絡，進一步提升輸出品質與工作效率。

[AI 分享] Skill讓AI更專業

 [AI 分享] Skill讓AI更專業

摘要 : Skill將複雜流程從Agent憲法中拆出，讓AI按需載入，減少漂移並複製高手工程經驗。

內容:

前文提到，Agent憲法主要是規範AI在專案中應遵守的原則與邊界，例如哪些事能做、哪些不能做、衝突時該聽誰，以及什麼條件下才算完成任務。但如果把需求整理、開發計畫、除錯流程、驗收方式、程式碼審查與交接規則全部寫進去，內容就會變得過於龐大，不僅佔用上下文，也會增加Token消耗，反而讓AI更難抓住重點。

因此，Skill的角色就非常重要。Skill不是再補一份更長的規範，而是把特定工作流程整理成AI可以在需要時調用的能力模組。它通常在命中相關語意後才載入，所以適合承載那些具體、複雜、但不必每次都常駐的流程。這樣可以讓Agent憲法保持精簡，也讓AI在執行任務時更穩定。

對許多剛開始使用AI開發的人來說，最常見的做法就是直接丟一句話給AI，例如幫我加登入、幫我修錯、幫我優化UI。這樣雖然快速，但AI往往只是根據當下指令自由發揮，沒有穩定流程可依循。它可能這次先拆需求，下次卻直接改程式；這次先驗證Bug，下次卻直接猜測原因，久而久之程式碼就容易變亂，結果也難以保證。

而Skill的價值，就是把有經驗工程師面對不同任務時的標準流程交給AI。若說Agent憲法像專案的員工手冊，那麼Skill就更像各職位的SOP。前者規定原則，後者指導實作。這種分工不但更有效率，也避免所有內容都長期塞在上下文裡，造成額外負擔。

Skill之所以重要，第一個原因是它能減少AI漂移。所謂漂移，就是AI一開始明明在做A，後面卻慢慢偏成做B；原本要求先驗收再交付，最後卻變成寫完就說完成。Skill能將某一類任務的標準方法固定下來，讓AI不是每次都臨時組織做法，而是回到穩定流程中執行。

第二個重要性，在於它能複製高手經驗。很多新手缺少的並不是打程式碼的能力，而是完整的工程思維，例如需求怎麼拆、Bug怎麼查、審查風險怎麼看、上線前該驗證什麼。許多Skill本身就是資深工程師或團隊將自己長期累積的方法論沉澱下來的成果。使用Skill，等於是讓AI把這些成熟經驗帶進當前任務裡。

在實際使用上，Skill不一定需要使用者手動逐一指定。很多AI IDE會根據你的語句，自動判斷要觸發哪一類Skill。例如你提到排查問題，可能會載入除錯Skill；提到開發計畫，可能會載入規劃Skill；提到頁面檢查，可能會觸發前端驗收或瀏覽器相關Skill。當然，使用者也能主動點名，要求AI依指定Skill執行。

此外，Skill也不只是普通提示詞。它通常還會附帶說明文件，包含用途、適用時機、處理流程、輸出要求，甚至可能搭配模板、參考資料、腳本或命令。這代表在某些任務中，Skill不只是提供思路，還可能直接支援安裝、驗證、檢查與執行操作。因此，使用者若不清楚某個Skill怎麼用，最好的方式就是直接詢問IDE，了解它的用途、觸發方式與注意事項。

對一般使用者來說，安裝與理解Skill其實不一定困難。很多時候，只要把Skill連結交給AI IDE，請它協助安裝並確認是否能被工具辨識即可。如果不確定這個Skill適不適合目前專案，也可以直接詢問AI，請它依據專案技術棧、目錄結構、部署方式與既有Agent憲法，幫忙判斷是否適配，甚至進一步調整用法。

總結來說，普通人不必一開始就研究透整套Skill機制。只需要知道三件事：第一，遇到合適的Skill可以交給IDE協助安裝；第二，不懂怎麼用時可以讓IDE解釋；第三，不確定是否適合專案時，可以請IDE結合實際情況幫忙判斷與適配。這正是AI IDE的重要價值，也是Skill能真正幫助新手提升開發品質的原因。

 [AI 分享] 成交關鍵不在產品，在資訊

摘要 : 產品決定復購，資訊決定首次成交；客戶買前無法驗證品質，只能透過你釋放出的資訊做判斷。

內容:

做了15年品牌營銷後，可以總結出一個核心真相：賣東西，並不只是賣產品、賣服務、賣價格，真正影響成交的，是客戶在下單前接收到的資訊。

很多人以為，產品夠好、服務夠強、品質夠穩，客戶自然會買單。但現實是，客戶一開口就問價格、問能不能便宜、問和別家差在哪裡，其實你就已經被拉進價格比較裡了。這時候你再去解釋材料、工藝、服務和品質，客戶往往仍然只盯著價格，因為他還沒有真正感受到你的價值。

原因很簡單：在第一次購買之前，客戶根本無法驗證你的產品到底好不好。他沒用過你的服務，也沒體驗過你的交付與售後，因此他只能透過你對外傳遞的資訊來做判斷。這些資訊包括文案、封面、圖片、詳情頁、短影片、直播間、評論區、客戶案例、銷售話術，甚至是你朋友圈裡說的每一句話。

所以可以記住一句話：產品負責交付，資訊負責成交。產品的好壞，決定客戶會不會再次購買；資訊的好壞，決定客戶願不願意給你第一次機會。

許多老闆賣得很累，不是因為產品不好，而是太相信產品本身。他們以為只要東西夠好，客戶遲早會懂。但客戶不是質檢員，也不是產品經理，他不會花時間研究你的材料、工藝、技術流程。他只會在極短的時間裡問自己四個問題：這和我有什麼關係？我為什麼要停下來？我憑什麼相信你？我為什麼現在要買？

如果你的資訊無法回答這四個問題，那產品再好，客戶也感受不到。當你不主動翻譯價值，客戶就只能用價格來比較你。這也是很多生意陷入價格戰的真正原因，不是市場太卷，而是你傳遞出去的資訊，剛好只適合被拿去比價。

舉例來說，同樣是一支手機，如果你只講晶片升級、螢幕更亮、相機畫素更高、電池更大，客戶聽完通常只會問多少錢、值不值得換、別家是不是更便宜。因為這些都是引數，而引數天生就容易被比較。真正會賣的品牌，會把晶片翻譯成打遊戲不卡，把相機翻譯成晚上拍孩子也清楚，把續航翻譯成出門一天不用帶充電寶，把螢幕翻譯成太陽底下也看得清楚。產品沒有變，但資訊變了。普通資訊講的是「我有什麼」，高級資訊講的是「你會得到什麼」。

再比如外送平台上的一碗牛肉飯，一家店只寫「招牌牛肉飯28元」，另一家店寫「現炒牛肉、熱飯熱菜、30分鐘送到，適合加班晚餐，吃完不將就」。後者不一定更好吃，但更容易讓人下單。因為它賣的不只是一碗飯，而是加班後的一口熱飯，是不用糾結晚餐吃什麼，是不用下樓排隊，是不用將就冷掉的食物。客戶雖然無法先驗證味道，但會先被資訊打動。

真正有效的成交資訊，可以分成四個層次：看見、認可、信任、依賴。

第一層是看見。看見不只是客戶刷到你，而是願意為你停下來。你的標題、封面、短影片前三秒、詳情頁首屏、直播間第一眼，能不能讓客戶繼續看，這才是關鍵。看見的核心不是讓客戶看到你，而是讓客戶在你的內容裡看到自己。比如賣減脂餐，與其一開始講低卡、高蛋白、營養均衡，不如先說「下班已經很累了，別再靠意志力決定晚飯吃什麼」，這樣客戶更容易有感。

第二層是認可。客戶停下來之後，不會立刻購買，他會先判斷你有沒有用。這時候如果你只是不斷講自己的原料好、團隊專業、設備先進、服務周到，效果通常有限。客戶真正關心的是：我能得到什麼？我能少什麼麻煩？我能降低什麼風險？我能獲得什麼結果？所以認可的關鍵，就是把你的優勢翻譯成客戶的利益。發貨快，對客戶來說叫不用等；服務好，叫出問題有人管；品質穩定，叫不用反覆試錯；流程成熟，叫交給你更省心。

第三層是信任。認可不代表成交，因為信任解決的是「我會不會踩坑」。客戶會懷疑你說的是真的嗎？有人買過嗎？交付怎麼樣？售後可靠嗎？這時候，信任不能靠口頭保證，而要靠證據建立。真實案例、客戶評價、前後對比、交付流程、產品細節、常見問題、售後承諾、復購紀錄，這些才是讓客戶放心的關鍵。

像山姆、Costco這類會員店，厲害的不只是商品多或價格便宜，而是它們替客戶做了篩選。客戶相信這裡的商品大機率不容易踩坑，所以買的不只是商品，而是一種被篩選過的安心感，也是一種信任你的判斷力。

第四層是依賴。一次成交不難，真正有價值的是讓客戶下一次還找你，甚至一想到某個需求，第一個就想到你。這種依賴不是靠一次交易建立的，而是靠持續輸出資訊、持續解決問題、持續降低選擇成本、持續提供方法與判斷。最高級的成交，不是客戶被你說服，而是客戶覺得找你最省心，懶得再去比較別人。

所以，別再只是反覆問「我的產品哪裡還不夠好」，你更該問的是：客戶第一眼看見我時，接收到的是什麼資訊？客戶看完內容後，知不知道我解決什麼問題？客戶猶豫時，我有沒有提供足夠證據讓他放心？客戶買完之後，有沒有理由再回來找我？

最後要記住，產品當然重要，因為沒有好產品，再好的資訊也只能換來一次成交，後面終究會被口碑反噬。但如果只有好產品、沒有好資訊，客戶甚至不會給你第一次體驗的機會。

總結一句話：產品好，決定客戶會不會復購；資訊好，決定客戶會不會成交。

[AI 分享] Vibe Coding立項先行

 [AI 分享] Vibe Coding立項先行

摘要：Vibe Coding做專案時，先和AI完成立項討論與文件沉澱，比急著寫程式碼更重要。

內容:

前面已經談過 AI IDE、Agent、憲法、Skill，以及前端、後端、資料庫等基本開發認知。到了真正進入專案實作階段，最重要的第一步不是馬上寫程式碼，而是先完成立項。

很多新手在使用 AI 做專案時，常常一有想法就直接要求 AI 幫忙生成整個專案。看起來速度很快，但其實風險很高。因為專案開發就像蓋房子，必須先打好地基；如果產品方向、資料結構、頁面流程或功能邊界一開始就沒有想清楚，後面發現錯誤時，往往不是改幾行程式碼就能解決，而是整體都要重來。

更麻煩的是，AI 在重構時不一定會完全乾淨地重做，常常會留下死程式碼、過度相容舊邏輯，甚至不斷打補丁，最後把整個專案結構弄亂。因此，Vibe Coding 的核心不是一句話讓 AI 變出完整專案，而是在規則、流程與基本技術認知下，讓 AI 協助你一步步把專案做出來。

正式開始前，建議先建立一個空的專案資料夾，並用 AI IDE 開啟。這個資料夾一開始可以沒有任何程式碼，它的用途是作為專案的獨立空間，方便後續存放立項文件、開發規劃、Agent 憲法與專案說明等內容。資料夾名稱最好使用英文，搭配中劃線或底線，例如 task-manager 或 resume-assistant，避免使用中文、空格、特殊符號，或像 demo1、測試專案這類隨意命名。清楚的專案命名，對後續開發、部署、版本管理以及 AI 理解專案都更有幫助。

之所以要先討論，是因為 AI 雖然能寫程式碼，但不能替你決定產品真正要做什麼。像是產品面向誰、解決什麼問題、核心功能是什麼、使用者為什麼要用、第一版應該做到什麼程度、哪些功能之後再做、哪些現在不該碰，這些都必須先釐清。

立項階段和 AI 討論，主要有三個目的。第一，是讓 AI 對專案建立基本認知，不只是知道你要做個後台或小程式，而是理解產品類型、目標使用者、核心問題與主要流程。第二，是幫助你完善想法，因為很多初步構想其實還很粗糙，透過 AI 追問與分析，能更早發現自己沒想清楚的地方。第三，是讓 AI 幫你查漏補缺，例如你可能只想到功能，卻忽略了權限、資料設計、後續擴充性等問題。

和 AI 討論時，不需要一開始就說得很複雜。你可以先簡單描述自己想做的產品類型與大概功能，請 AI 協助分析核心設計、判斷想法是否可行，甚至主動追問你。這個階段的重點不是讓 AI 開寫，而是讓它扮演產品合夥人與架構顧問，協助你拆解需求、界定 MVP、分析使用者場景、整理核心功能、梳理資料流與推演使用流程。

如果腦中只有一個模糊方向，也可以直接告訴 AI，請它陪你一起梳理專案應該怎麼做。等專案輪廓初步清楚之後，還可以進一步讓 AI 幫你搜尋與分析競品、參考開源方案、找出差異點與切入機會。有時候你以為是新想法，其實市場上已經有類似產品；也有可能只是換個使用場景，就能找到新的價值定位。

到了更後面，AI 還可以幫你規劃長期路線，例如第一版先做什麼、第二版擴充什麼、哪些功能後面再處理、哪些模組現在就要先保留邊界。這些討論越清楚，後續開發就越不容易失控。

特別要注意的是，在立項階段不要讓 AI 直接開始寫程式碼。很多 AI 一看到你說要做專案，就會立刻建立檔案、安裝依賴、生成頁面和 API。這時候你必須明確阻止它，告訴它目前只做產品討論與立項設計，暫時不要寫程式碼。因為此時產品定位、功能邊界、技術路線與驗收標準都還沒沉澱下來，太早進入開發，只會讓專案提早陷入混亂。

當討論差不多之後，下一步就是讓 AI 在專案資料夾中整理並生成立項文件。這份文件非常重要，因為它會成為後續開發的依據。之後無論是寫程式碼、拆任務、設計資料庫、規劃前後端介面，都可以回到這份文件確認方向。如果沒有文件，專案在多輪對話與反覆修改中很容易飄移，今天設定給個人用，明天 AI 可能寫成企業後台；今天說第一版只做核心流程，明天又可能被塞進一堆不必要的複雜功能。

如果專案很小，一份立項文件就足夠；如果專案稍微複雜，可以拆成幾份，例如專案立項說明、詳細規劃、商業計畫或長期路線等。格式不必過度糾結，重點是這些文件要能讓你和 AI 都看得懂，並在後續開發中持續拿來對照，避免專案偏離原本目標。

此外，立項也不是追求一次到位的完美。尤其對新手來說，最重要的不是產出一份無懈可擊的文件，而是先把目前能確定的內容寫下來。像是專案是什麼、給誰用、解決什麼問題、第一版做什麼、暫時不做什麼、未來可能如何擴充，這些只要先整理清楚，就已經比一句「幫我做個專案」成熟許多。之後隨著討論、開發與驗證的進行，文件本來就可以持續更新。

總結來說，Vibe Coding 做專案的第一步不是寫程式碼，而是立項。你需要先學會和 AI 討論產品，讓它理解你的想法，也利用它幫你完善想法。等方向清楚後，再把討論結果沉澱成專案文件。這樣 AI 後續才知道專案是什麼、第一版要做什麼、哪些功能暫時不碰，以及未來大致往哪裡發展。真正穩妥的做法，是先建立空專案資料夾，用 AI IDE 開啟，從討論開始，把專案聊清楚，再讓 AI 正式動手。

[AI 開發] AI寫程式不跑偏的分階段管理法

 [AI 開發控] AI寫程式不跑偏的分階段管理法

摘要 : 用實施文件拆解任務，搭配分階段驗收，能有效避免AI寫程式時自由發揮、功能跑偏與架構失控。

內容:

很多人讓AI寫程式時，前面其實已經想了很多功能細節，也和AI討論得很清楚，原本以為方向既然定了，AI就能照著思路一步步完成專案。但實際情況常常不是這樣，AI不是加了一堆沒意義的功能，就是該做的功能沒做好。對不懂程式碼的人來說，更難自行核對，只能一輪一輪叫AI修改，結果越改越亂，最後不是重構就是直接放棄。

這篇內容的核心，在講真正開始寫程式之後，怎麼讓AI一個階段一個階段穩定往前推，避免中途跑偏。尤其對沒有技術背景的人來說，AI雖然像一把利器，但同時也很難駕馭。如果只是隨手丟一句需求給AI，往往就像在開盲盒，結果充滿不確定性。

要讓AI穩定做專案，重點其實只有兩件事。第一，是把目前要做的大階段拆成足夠細的實施文件；第二，是讓AI嚴格按照這份文件，一個子階段一個子階段執行，而且每完成一段就先驗收，再進入下一步。這樣才能降低AI自由發揮的空間。

所謂把大階段拆細，是因為大階段的描述通常太粗。像是「先做一個買家可以下單付款的最小可用版本」，這種話對人來說好像很清楚，但對AI來說卻會變成自行腦補流程、順序和完成程度。最後做出來的內容，常常不是你真正想要的。所以在寫程式之前，應該先把當前大階段拆成幾個子階段，再把每個子階段拆成更小的步驟。

拆解的目標不是越細越好，而是要細到讓AI清楚知道三件事：這一步要做什麼、做到什麼程度才算完成、哪些事情現在先不要碰。同時，每一步也要附上驗收標準與驗證方式，確保任務不只是能執行，還能驗收，而且邊界明確。

這份文件不只是拿來參考，而是每次開工前都要要求AI對照執行。這樣AI才知道這一輪只該做哪些內容，不容易自己延伸。這份文件可以視為該階段的「單一可信來源」，也就是這一階段的開發與驗收，都要以它為準。聊天過程中臨時冒出的想法，不是不能加，但必須先更新回這份文件，才算正式變更。

另外，也不需要一開始就把所有大階段都拆成這種細部實施文件。比較好的方式是，只拆目前馬上要做的那一個大階段，後面的階段先保留方向即可。因為專案進行中需求很可能會調整，如果太早把後面所有內容都寫得很細，之後一改動，前面整理的大量細節很可能就白做了。

不過，需求雖然可以微調，有一條底線不能隨便破壞，就是不要在已經開始寫程式之後，動不動就去改底層架構。像是技術棧、目錄結構、資料庫表設計、核心欄位存法、登入權限、支付流程等，這些都屬於地基。業務細節可以修，但如果一個改動會動到地基，就不能直接讓AI順手改下去，而是要先請AI做影響評估，說明影響範圍，再提出穩妥的調整方案。

如果沒有先評估，就直接丟一句「先滿足需求再說」，AI很可能為了配合需求，把原本的架構破壞掉。那樣一來，前面做的立項、技術選型與架構規劃，就可能全部白費。因此，在真正實作前，仍然要維持架構層面的紀律。

當你要AI幫忙拆解階段時，可以直接要求它根據功能清單與階段計畫，整理出一份詳細的實施文件。內容要包括：先拆成幾個子階段、每個子階段再拆成哪些步驟、每一步要做什麼、做到什麼程度、涉及哪些功能、驗收標準是什麼、用什麼方式驗證，以及暫時不做哪些事。這個階段先不要寫程式，只專心把文件定清楚。

文件拆好之後，你一定要先看過。這不只是給AI執行時看的，也是你在動手寫程式前，最後一次跟AI對齊需求的機會。如果你發現文件和原本想法有偏差，就先討論清楚並修正。如果看不懂，就直接請AI用白話一條條解釋。甚至你可以把最初的需求重新貼給AI，請它反過來檢查這份文件有沒有和需求衝突，或有沒有需要先釐清的地方。

等文件定好後，才進入真正的執行階段。這裡最大的風險叫做「飄移」，也就是AI寫著寫著偏離了原本的計畫。它可能會自己擴充你沒要求的功能，也可能漏掉該做的內容。為了防止這種情況，每次開始一個子階段前，都要先給AI一段明確指令，例如要求它嚴格遵守既定規則與實施文件，只實作當前子階段，不要超出範圍，做完後停下來回報，不要自動進入下一個子階段。

這種做法等於同時畫了兩條邊界，一條是AI做事的方法邊界，一條是這次任務的內容邊界。只要這兩條邊界清楚，AI亂跑的機率就會大幅降低。如果你使用的Agent工具有自動執行模式，更要注意不要讓它一路做到自己認為完成為止，而是每完成一段就停下來，先驗收再繼續。

在每個子階段完成後，你不一定要自己看程式碼，也可以直接要求AI回報三件事。第一，對照實施文件，哪些內容已經做完，哪些還沒完成；第二，它具體修改了哪些地方，有沒有漏做或多做；第三，它是怎麼驗證的，驗證結果是什麼，下一步應該做哪個子階段，理由是什麼。透過這三組問題，就能快速判斷AI是不是還在按照文件前進，還是已經開始憑感覺行動。

如果AI提出的下一步和文件內容對不上，就表示它的理解已經偏掉了，這時應該先把它拉回來，而不是放任它繼續做下去。如果它的說明你看不懂，也不要硬撐，直接要求它對照文件，用白話重新講一次做了什麼、還差什麼，以及驗證結果代表什麼。每個子階段都這樣確認沒問題後，再進入下一階段。

整體來看，這套方法的核心，就是不要讓AI憑感覺寫程式，而是讓它始終有文件可以對照、有邊界需要遵守、有驗收標準可以回報。即使你不懂程式碼，也能透過文件、範圍控制與驗收證據，把專案方向穩穩抓在自己手上。

[AI 分享] PDF型RAG處理思路

 [AI 分享] PDF型RAG處理思路

摘要 : PDF做RAG不能只轉文字切片，重點在辨識類型、保留結構、語意切分、可追溯引用與多工具協作。

內容:

當 agent 做 RAG 時，知識庫裡是一堆 PDF 該怎麼處理，不能只回答「先轉文字、再切片、再丟向量庫」。這種答案太表面，因為真實專案裡的 PDF 往往不是乾淨的純文字，而是充滿各種複雜結構與格式問題。

實務上，PDF 可能是合約、財報、掃描件、技術文件，裡面會包含條款、表格、圖表、圖片、雙欄排版、流程圖、程式碼區塊、註腳、頁首頁尾等內容。若直接把它當成一般文本抽取，後續很容易出現切片斷裂、表格結構混亂、頁首頁尾重複召回、圖片資訊遺失等問題。最終模型雖然能回答，但常常無法正確引用原文，來源也難以對應。

這題真正考的，不是會不會把 PDF 存進向量庫，而是有沒有理解 PDF 型 RAG 的難點在於：能不能正確讀懂、正確切分、正確引用。

第一步是先判斷 PDF 類型，而不是急著抽文字。若是原生文字型 PDF，例如說明書、產品文件、論文，可以直接做文字解析；若是掃描型 PDF，例如紙本合約、發票或拍照轉成的檔案，就必須先透過 OCR 做文字辨識；若是圖文混排、表格密集或含大量流程圖與截圖的 PDF，就不能只靠文字抽取，而要搭配版面分析、視覺理解，甚至多模態模型一起處理。因為一開始類型判斷錯了，後面的切片、檢索與回答都會跟著失真。

第二步是盡量還原文件結構。PDF 處理很常見的錯誤，就是把整份文件抽成一大段純文字，這樣雖然快，但會犧牲掉很多關鍵上下文。例如合約中的章節、條款、附件編號，或財報中的表格名稱、年份、指標欄位，這些資訊如果遺失，模型即使抽到一句內容，也不知道它屬於哪一頁、哪一章、哪一個條文，自然難以驗證與追溯。

因此在生產環境中，應盡量保留頁碼、標題層級、章節關係、段落邊界、表格位置、圖片說明、註腳與頁首頁尾等結構資訊。更重要的是，每一段內容都要知道自己在原文中的位置，這樣後續才能支援引用、校驗與來源追蹤。

第三步是按語意切片，而不是機械式固定字數切分。很多人習慣每 500 字或 800 字切一段，但 PDF 的內容通常不適合這樣做。標題和正文不能隨便拆開，合約條款最好保持完整，表格也不能當一般段落切開，圖表內容更不能直接忽略。

更好的方式是根據語意與結構切分，例如同一標題下的數個段落可以組成一個 chunk，合約中的單一條款盡量完整保留，表格可以單獨轉為結構化文本，圖表則可先生成摘要，再連同頁碼與標題一起保存。每個 chunk 都應附上 metadata，例如文件 ID、頁碼、章節標題、條款編號、表格編號、圖片描述與版本時間等，讓檢索結果不只是孤立句子，而是帶著上下文與來源資訊的內容單元。

若要做得更精細，還可以為每個 chunk 補充一段上下文說明，例如註記這段內容來自某份合約的付款條款，主要說明尾款支付條件。這樣模型在檢索回來後，不只看到片段，還能更快理解它在整份文件中的語意角色。

第四步才是 agent 層的工具設計。到了 agent 使用階段，不建議把整份 PDF 一次塞進上下文，這樣既浪費 token，也容易讓模型抓不到重點。更合理的方法，是把 PDF 處理能力拆成多個工具，讓 agent 根據問題類型按需呼叫。

例如可以設計 Search PDF 來做片段檢索，Read Page 用來讀取指定頁內容，Extract Table 專門抽取表格，Chart Analysis 或視覺分析工具用來理解圖表，Citation Source 則負責返回頁碼與原文引用。這樣當使用者問簡單問題時，agent 可以先檢索相關段落；當使用者問跨年度比較、數據變化趨勢等複雜問題時，agent 就能進一步定位章節、抽取表格、做整理與歸納；如果問的是流程圖或圖片內容，就要交給視覺分析工具，而不是只靠文字搜尋。

回答這題，最後最好補充生產級細節：PDF 型 RAG 一定要做到可追溯引用，也一定要建立評測機制。回答內容最好附上頁碼、章節、原文片段，甚至表格編號，否則模型說得再自然，也很難確認它是不是憑空編造。

而評測也不能只看最後答案對不對，還要往下拆成更細的品質指標，例如檢索片段是否正確、頁碼是否準確、表格有沒有被解析錯亂、OCR 是否漏字、圖表資訊是否被正確理解、原文引用是否真的能支撐最終回答。這些細節，才是真實業務裡最容易出問題的地方。

總結來說，這題的成熟回答不是「PDF 轉文字後向量化」而已，而是先辨識 PDF 類型，再選擇合適的解析方式；接著保留文件結構，依語意進行切片；對表格、圖片與圖表做專門處理；最後讓 agent 透過工具鏈按需檢索、讀頁、抽表、看圖，並全程保留引用與評測閉環。這樣的回答，才能讓面試官知道你不是只做過簡單 demo，而是真的理解 PDF RAG 在生產環境中的核心難點。

[AI 分享] 吳恩達AI Agent課程重點整理

 [AI 分享] 吳恩達AI Agent課程重點整理

摘要 : 濃縮吳恩達8小時AI Agent課程，快速理解什麼是Agent、如何搭建，以及最常被忽略的評估關鍵。

內容:

這次內容主要是把吳恩達釋出的 AI Agent 完整課程重點濃縮整理，幫大家省下八小時的學習時間。即使你不會寫程式、沒有技術背景，只要平常有在使用 ChatGPT、Gemini 這類 AI 工具，也能透過這份整理快速掌握核心觀念。

首先，AI Agent 其實沒有很多人想像中那麼複雜。最簡單的理解方式，就是替 AI 加上「自己做決定」和「使用工具」的能力。過去的大語言模型通常是你問一句、它答一句，任務到此結束；但 Agent 不一樣，它可以自己拆解任務、決定步驟、選擇工具，逐步完成整件事。

整個概念可以分成三個層次來理解。第一層是大語言模型，也就是我們熟悉的 ChatGPT、Claude、Gemini。這類模型的特點是輸入問題、輸出答案，但它有兩個限制：第一，它不知道你的個人資料或外部即時資訊；第二，它是被動的，你不下指令，它就不會主動行動。

第二層是 AI Workflow，也就是 AI 工作流。這一層是在大語言模型上增加固定步驟，讓 AI 在回答問題前，先去查日曆、待辦事項或其他資料來源。這樣它能回答得更準確，但本質上仍然只是照著你事先設定好的流程走。只要真正做決策的人還是你，那它就還不算 Agent。像常聽到的 RAG，本質上也是一種先查資料再生成答案的工作流。

第三層才是真正的 AI Agent。從 Workflow 升級到 Agent 的核心差異，在於「做決定的人從你變成 AI」。你不需要替它規劃每一個步驟，只要告訴它最終目標，例如幫你完成一份週報，它就會自己決定去哪裡蒐集資料、怎麼整理內容、是否需要檢查品質，甚至反覆修改直到結果夠好為止。

這裡有一個重要概念叫做 ReAct，也就是 Reasoning 加上 Action，代表推理與行動。真正的 AI Agent 必須同時具備這兩種能力：先想清楚怎麼做，再實際去做。它不只是會回答問題，更能採取行動、使用工具、持續迭代。

如果要搭建一個 AI Agent，核心可以拆成三塊積木。第一塊是模型 Model，也就是 AI 的大腦，負責理解、推理、產生內容。第二塊是工具 Tool，也就是讓 AI 能與外部世界互動的能力，例如查詢資料庫、讀取日曆、存取訂單系統、發送訊息等。第三塊則是評估 Evaluation，負責檢查結果品質、替輸出打分，判斷任務是否真的完成得夠好。

其中，工具的作用特別容易從實際場景看出來。以電商客服為例，當客戶反映尺寸寄錯，AI 模型本身可以先理解訊息內容，抓出關鍵資訊；接著需要透過工具連接後台系統，查詢訂單、物流與庫存；最後再利用模型撰寫回覆，並透過另一個工具把訊息真正發送出去。這就是模型與工具互相配合的完整過程。

而整份內容最重要的一個提醒，就是大多數人最容易忽略的「評估」。很多人在談 AI Agent 時，只關注模型夠不夠強、工具接得多不多，卻忽略了最後怎麼判斷結果是好還是不好。其實評估才是讓 Agent 能真正穩定運作的關鍵，因為沒有評估，AI 就無法知道自己是否做對、是否需要修正，也無法持續提升表現。

總結來說，AI Agent 的本質不是神秘的新技術，而是讓 AI 從單純回答問題，升級成能自主思考、使用工具並完成任務的系統。理解它的最好方式，就是先分清楚大語言模型、工作流與 Agent 的差異，再掌握模型、工具、評估這三大核心結構。只要把這些概念搞懂，你就已經具備進一步實作 AI Agent 的基礎了。

[AI 分享] Codex三種電腦操控方式解析

 [AI 分享] Codex三種電腦操控方式解析

摘要 : 一文看懂Codex的Computer Use、Chrome擴充套件與內建瀏覽器差異，快速選出最適合自己的使用方式。

內容:

OpenAI開發者體驗工程師、前Meta資料科學家 Jason Liu 近期分享，Codex 目前有三種主要方式可以操控電腦執行任務，分別適合不同場景。理解它們的能力邊界，才能真正發揮 AI Agent 的效率。

第一種是 Computer Use，這是目前 Codex 在操控電腦方面能力最強、應用範圍最廣的方式。它可以模擬使用者在電腦上的大部分操作，只要是滑鼠能點、鍵盤能輸入的地方，理論上都能處理。不論是微信、飛書，還是 Excel 等桌面軟體，甚至跨多個應用切換，它都能執行。

Jason Liu 分享了一個實際案例：有次他的包裹被偷，但亞馬遜客服排隊等待時間長達 25 分鐘，於是他讓 Codex 每 5 分鐘檢查一次客服視窗，等客服即將接通後再改成每分鐘檢查，並嘗試完成退款申請。等他回來時，退款流程已經處理完成。這顯示出 Computer Use 很適合接手那些繁瑣、耗時、必須盯著流程的任務。

不過，Computer Use 也有明顯限制。由於它每一步都需要先理解畫面，再判斷位置、進行操作，因此速度相對較慢。這種方式不適合追求極致效率的情境，但很適合那些沒有 API、沒有外掛、只能依靠圖形介面完成的工作。

第二種是 Codex Chrome 擴充套件，這類方式更適合發生在瀏覽器中的任務，尤其是需要登入狀態的網站，例如飛書文件、淘寶商家後台、B站創作中心等。這些平台依賴使用者當前的帳號登入資訊，而 Chrome 擴充套件可以直接基於你已登入的瀏覽器環境進行操作。

它和 Computer Use 最大的不同在於，Computer Use 是透過「看螢幕、點按鈕」來完成任務，而 Chrome 擴充套件則是直接進入瀏覽器工作流。它能讀取網頁內容，也能在多個分頁之間切換，例如先查資料、再交叉比對、最後整理輸出結果。因此，在純瀏覽器場景下，Chrome 擴充套件通常會比 Computer Use 更快、更準確。

Jason Liu 表示，他自己經常使用 Chrome 擴充套件來檢查私訊、瀏覽新聞、蒐集回饋，並將有價值的內容整理儲存到本地檔案，方便後續反覆查看。不過，這種方式的權限也更敏感，因為它使用的是你的真實登入狀態，所以網站會將所有點擊、輸入與提交視為你本人操作。因此，資訊蒐集、內容整理可以交給它，但像傳送訊息、確認付款這類高風險動作，仍建議由使用者自行確認。

第三種是內建瀏覽器，這種方式更偏向開發者使用，特別適合做網頁開發、前端頁面預覽與本地工具除錯。例如當你正在開發一個前端頁面時，可以讓 Codex 開啟本地預覽網址，檢查版面配置是否正常、按鈕是否錯位、手機端是否有溢位問題。檢查完成後，它還可以直接修改程式碼，再重新打開頁面驗證結果。

內建瀏覽器最有價值的地方，在於它把「寫程式碼」與「看結果」串接成一個完整流程。因此，它不是拿來登入網站或處理帳號任務的工具，而更像是 Codex 在開發與介面除錯時的專屬工作台。

如果要快速選擇使用方式，可以這樣理解：需要登入狀態的網站任務，優先使用 Chrome 擴充套件；需要操作桌面軟體，或在多個應用之間切換時，選擇 Computer Use；需要開發網頁、預覽頁面、除錯介面時，則使用內建瀏覽器。

Jason Liu 也特別提醒，如果任務本身可以透過外掛、MCP 或 API 等結構化工具完成，應優先選擇這些方式。像是讀取飛書文件、整理線上表格，如果能直接呼叫介面，通常會比讓 Codex 透過畫面模擬點擊來得更準確、更高效。

這也說明了一個重要觀點：Codex 操控電腦不是越像人越厲害，而是越能根據任務選對入口越強。真正高效的 Agent，不是接到任務就盲目點滑鼠，而是知道什麼時候該用 API，什麼時候該進瀏覽器，什麼時候該接管桌面。

從這個角度來看，Codex 早已不只是寫程式碼的工具，而是逐漸成為一套圍繞電腦、瀏覽器與本地專案運轉的任務執行系統。對想提升效率的人來說，重點不只是會不會用 AI，而是能不能根據任務場景，挑對最合適的工具入口。

[AI 影響] AI程式碼審查失效危機

 [AI 影響] AI程式碼審查失效危機

摘要 : AI大幅提升產碼速度，卻讓人類審查跟不上，傳統Code Review正失效，團隊需改用分層與證據驅動審查。

內容:

這裡主要在談一個越來越明顯的現象：團隊裡使用 AI 寫程式的人愈來愈多，產出速度暴增，但人類審查程式碼的能力並沒有同步提升。結果就是，面對動輒幾百上千行的 diff，很多人其實已經無法真正看完，只能草草 approve。這不是工程師變懶，而是既有的審查機制正在被 AI 的產出速度壓垮。

過去 50 年，程式碼審查之所以能有效運作，關鍵原因其實很簡單：人類寫程式很慢。因為寫得慢，審查者才有時間在合理成本下讀完程式碼，順便找 bug、討論架構、傳承知識，形成健康的協作閉環。但現在不同了，只要對 AI 工具下個指令，幾秒鐘就能生成上千行程式碼。機器產出的速度翻了好幾十倍甚至上百倍，但人類閱讀與理解程式碼的速度並沒有改變，傳統 PR 流程因此開始失靈。

幾組工業界數據來說明問題的嚴重性。Ferros AI 追蹤 4000 個團隊、22000 多名開發者後發現，深度採用 AI 之後，程式碼變動率暴增 861%，而審查時間也增加了 441.5%。更驚人的是，有 31.3% 的 PR 幾乎沒有經過任何人類審查，就直接合進主分支。結果缺陷率從 9% 升到 54%，正式環境事故率提高了 2.4 倍。GitClear 的分析也指出，雖然 AI 讓程式碼量增加到原本的四倍，但實際業務價值只增加 12%。也就是說，團隊付出了大量閱讀與維護成本，換來的卻不一定是對等的價值提升。

為什麼 AI 生成的程式碼常常比人類初學者的程式碼還難審。第一個原因是「意圖與推理過程的消失」。人類寫程式時，背後通常有設計理由與取捨脈絡，審查時還能口頭補充；但 AI 在產出最終程式碼後，這些思考過程往往不會完整保留下來，審查者只能從結果反推它的意圖。第二個原因是 AI 擅長局部最佳化，卻缺乏完整的業務上下文與組織默契。它可能在技術上可行，但未必符合系統長期演進方向。第三個原因是 AI 很會寫「看似合理但實際空洞」的程式碼，包含過度包裝、冗長防禦性設計與華麗但低價值的實作，讓審查者需要花更多力氣辨識真正重要的邏輯。

面對這種情況，認為不能再用單一標準看待所有團隊，而要根據系統的「爆炸半徑」來決定審查策略。也就是說，這段程式碼一旦出錯，影響有多大？這套系統要維護多久？是否涉及高風險業務？這些因素才是決定審查方式的核心。

針對不同團隊型態，內容整理出三種策略。第一種是單人開發者或原型驗證專案。這類場景下，程式碼審查的知識共享價值不高，應把重心放在自動化測試上，不要把時間浪費在形式化審查或風格細節上。但前提是測試要足夠扎實，否則等於只是延後爆雷。

第二種是多數人所在的成長型團隊。這類團隊已有真實使用者，也需要多人共同維護程式碼，因此要採取「分層審查」。機器負責重複性高的髒活，例如靜態分析、安全掃描、CI/CD 自動檢查；人類則聚焦在真正高價值的部分，包括核心業務邏輯是否正確、架構是否被帶偏、知識是否有同步傳遞。高級工程師不應該把時間花在逐行檢查 AI 生成的小細節，而應該去判斷那些程式碼是否真的有存在必要。

第三種是企業級重型系統，例如核心交易鏈路、金融支付或高風險基礎設施。這類系統不能只收程式碼，必須要求「證據驅動審查」。也就是說，若使用 AI 產生 PR，就應附上決策日誌，例如 decision log.md，把推理脈絡、備選方案、取捨原因一起交出來。若只有程式碼、沒有說明，就不應該直接 merge。因為在高風險系統中，光看結果遠遠不夠，審查者還必須理解背後決策。

除了調整審查策略，內容還提出一個很關鍵的實作方向：用 AI 來審查 AI，也就是所謂的 loop engineering。既然機器生成程式碼的速度太快，那就應該在 CI 流程中加入專門的 review agent，讓它先根據團隊的架構規範、設計原則與常見風險，自動檢查 PR 是否違規、是否引入壞味道、是否偏離既定架構。這樣一來，人類工程師在正式看到 PR 之前，已經有一層機器初審幫忙過濾，能有效減少那些表面工整、實際價值不高的 AI 垃圾程式碼。

最後，內容點出一個值得反思的結論。很多人擔心 AI 把寫程式的門檻拉低，會讓程式設計師失業；但真正有價值的能力，從來不是「把程式碼敲進電腦」本身，而是如何判斷一段程式碼能不能被信任、是否符合業務需求、會不會傷害系統長期穩定性。當 AI 讓產碼變得廉價，人類工程師真正重要的角色，反而會更集中在判斷、取捨、審查與系統思維上。