[AI 回顧] AI如電氣化的歷史映照

 [AI 回顧] AI如電氣化的歷史映照

摘要 : AI像百年前的電氣化，前期重資本、低效率，後期才迎來生產力與應用大爆發。

內容:

AI的發展路徑，與一百年前的電氣化極為相似。電本身並不神奇，真正決定一個國家、一家企業能否受益的，不是技術是否出現，而是它是否足夠便宜、便利，以及人們是否真正懂得如何拿它來創造成果。AI也是如此，不需要過度恐懼，也不必過度神化。

近一年市場對AI充滿爭論，核心問題始終圍繞「AI是不是泡沫」。悲觀者認為，下游應用不足、模型公司難以盈利、上游硬體景氣不可持續，巨額資本支出未必能回本。但隨著企業端與Coding場景的突破，AI Agent的能力與商業化開始明顯提升，進一步擴散到金融、法律、客服、網安與營運等領域，讓市場逐漸意識到，限制AI收入的關鍵可能不是需求，而是算力供給不足。

若把今天的AI放進歷史座標來看，它很像1914年前後的美國電氣化。當時美國已經進行了約20年的電力建設，發電廠、工廠電機與城市電網都逐步普及，但整體生產力成長卻依然平平。也就是說，技術滲透率上升，不代表生產力會立刻反映。這與今天大量企業導入AI工具，卻尚未全面改變組織結構與工作流程的情況極為相似。

電氣化歷史大致可分成幾個階段。最初是技術摸索期，交流電與直流電爭奪主導權，商業模式不清，標準也未定型，市場估值波動劇烈。這對應到AI從Transformer、GPT到各種模型路線競爭的早期階段，大家都在問技術能做什麼、誰能賺錢、標準會落在哪裡。

第二階段是基建期。當年大量資本投入發電廠、電網與工廠設備更新，美國工廠電氣化率和家庭通電率大幅提高，但生產力幾乎沒有同步上升。原因在於，工廠雖然改用了電機，卻沒有重設流程、組織與產線配置，只是把蒸汽機換成了電力驅動。本質上只是更換動力來源，沒有真正重構生產方式。今天許多企業導入AI，也仍停留在將其嵌入既有流程的輔助工具階段，因此效果有限。

真正的轉折點，來自基建完成後的應用重構期。當工廠不再受蒸汽主軸與皮帶系統限制，開始重新設計空間配置、作業流程與管理模式，生產力才真正大幅躍升。這也說明，AI若想迎來真正的爆發，不只是模型更強、算力更大，更關鍵的是企業是否願意重組工作流、改寫軟體架構，甚至重塑整體組織運作方式。

從資本市場角度來看，技術革命不等於所有相關資產都會穩賺。電氣化時代裡，設備製造商雖然身處產業核心，卻在很長一段時間內回報平庸，因為需求成長慢、技術迭代快、競爭激烈、客戶集中，導致利潤被壓縮。反而到了應用爆發期，相關公司股價才出現大幅上漲。這意味著，即使看對大方向，也不代表每一個產業鏈環節都會成為最佳投資標的。

另一類贏家則是應用層企業。像當年汽車、家電、收音機等新產品，藉由電氣化基礎設施快速普及，才真正創造出大規模需求與高成長回報。放到今天，AI最值得關注的，或許不只是模型公司與晶片公司，更是那些能把AI能力商品化、流程化、場景化的應用企業。

歷史同時也提醒我們，技術革命中確實會出現真正的泡沫。電氣化時代裡，不少看似搭上趨勢的產業，最終因需求錯判、商業模式不成立或政策限制而破裂。也就是說，「技術是真的」與「標的是對的」是兩回事。AI不是假的，但某些資產價格、槓桿產品與過度包裝的概念股，依然可能成為泡沫。

最重要的結論是，技術革命的物理進程，往往不會因為股價崩跌而停止。就像1929年股市崩盤後，電氣化仍在持續推進，發電量與家電滲透率仍不斷成長。崩的是估值、情緒與槓桿，不是技術本身。這對今天的AI也同樣適用：即使未來市場波動劇烈，AI落地與產業重構仍可能持續發生。

總結來說，AI更像是一場長週期的基礎設施革命，而不是短期的題材炒作。它現在可能仍處於重資本投入、應用剛起步的中段位置，真正的大規模生產力釋放，往往發生在基建逐漸完成、流程與組織開始全面重構之後。理解這段歷史，不只是為了判斷AI有沒有泡沫，更是為了看清未來十年的真正方向。

[AI 教學] 六分鐘搞懂AI八大術語

 [AI 教學] 六分鐘搞懂AI八大術語

摘要 : 從大語言模型到Skill，快速理解AI八大核心術語與彼此關係。

內容:

這篇內容用簡單易懂的方式，整理出 AI 領域最常被提到的八個重要術語，幫助大家建立完整概念，而不是只停留在表面理解。

首先是「大語言模型」。它並不是從資料庫中直接查找答案的搜尋引擎，而是根據前文去預測下一個最可能出現的詞，逐步生成整段內容。因此，它的本質是機率生成器，不是知識庫。這也解釋了為什麼 AI 有時會出現「幻覺」，說出聽起來合理但實際不正確的內容。不過也正因為如此，它同時具備創造力，能寫作、編故事，甚至產生新的程式碼結構。

第二個概念是「Token」。Token 是 AI 處理文字時的最小單位，不完全等同於一個字或一個詞。不同語言拆分方式不同，中文通常比英文消耗更多 Token。由於大多數 AI 服務都是按 Token 計費，因此在大量使用時，理解 Token 的概念不只影響技術認知，也直接關係到成本控制。

第三個概念是「Context」，也就是上下文或上下文視窗。這代表 AI 在一次互動中能同時看到多少資訊，包括歷史對話、系統指令與當前輸入內容。可以把它想像成 AI 面前的一張桌子，桌面越大，能攤開的資訊越多。Context 的品質與安排方式，會直接影響 AI 的理解能力與最終表現。

接著是「Prompt」，也就是提示詞。很多人以為 Prompt 只是對 AI 提問，其實更像是在用自然語言替 AI 下達結構化指令。提示越清楚，角色越明確，需求越完整，AI 的輸出通常就越穩定、越接近預期。所謂 Prompt Engineering，本質上就是把腦中的模糊需求，轉換成 AI 能精準執行的指令格式。

第五個概念是「Tool」。即使 AI 很會分析與回答，如果沒有工具，它仍然只能停留在「建議」層面，無法真正執行任務。Tool 的作用，就是讓 AI 具備操作能力，例如讀取檔案、修改程式碼、執行指令，甚至操作瀏覽器。當 AI 擁有工具之後，就不再只是參謀，而開始成為真正能動手做事的執行者。

第六個概念是「Agent」。很多人誤以為只要 AI 能調用工具，就是 Agent，但真正的關鍵在於「自主決策能力」。一般 AI 需要人一步一步下指令，而 Agent 則能根據目標，自行拆解任務、選擇工具、安排流程，甚至在遇到問題時調整策略。也就是說，你給它的是目標，它自己決定怎麼完成。

第七個概念是「MCP」，也就是模型上下文協議。它的價值在於標準化工具的接入方式。過去不同工具需要不同的整合方式，開發與適配成本很高；而 MCP 就像 AI 世界的 Type-C，讓支援同一標準的模型與工具能更容易互通。MCP 不是工具本身，而是一種基礎設施，目的是讓 AI 能更有效率地連接外部能力。

最後一個概念是「Skill」。即使 Agent 已經具備自主行動能力，仍然可能出現「什麼都能做，但都做得普通」的問題。Skill 的作用，就是把特定任務所需的提示詞、工作流程、工具組合與品質標準，封裝成可重複使用的技能包。這能讓 AI 在某些專業領域表現得更穩定、更深入，也讓它從通才進一步變成專才。

整體來看，這八個概念其實是一層一層往上建立的。大語言模型提供生成能力，Token 是文字處理單位，Context 決定可用資訊範圍，Prompt 決定輸出方向，Tool 讓 AI 能動手執行，Agent 讓它具備自主規劃能力，MCP 負責工具生態的標準化，而 Skill 則讓 AI 在特定任務中走向專業化。理解這套脈絡，就能更清楚看懂 AI 為什麼強大，也知道它的限制與進化方向。

[AI 觀點] AI時代產品經理不會消失，真正稀缺的是品位與判斷力

 [AI 觀點] AI時代產品經理不會消失，真正稀缺的是品位與判斷力

摘要 : AI讓寫程式與做原型更便宜，但產品經理與設計師的價值反而更凸顯，關鍵在於策展、判斷與系統整合能力。

內容:

近期在業界很常見的觀點：隨著AI讓寫程式越來越便宜，人人都能快速做出原型，因此產品經理（PM）似乎變得可有可無，甚至有些公司開始喊出要砍掉PM、全員轉型成Builder。這種說法聽起來很符合AI時代強調效率與快速落地的氛圍，但OpenAI Codex主管安德魯·阿姆布羅西努卻公開反對，直言「人人都能做產品」其實更像是一種毒雞湯，背後甚至帶著對非工程職能的傲慢。

安德魯在矽谷累積了十多年經驗，做過設計、寫過程式、也創過業。他坦言自己過去的創業並不成功，直到接手OpenAI的Codex產品後才真正迎來突破。從今年1月以來，Codex的週活躍使用者暴增6倍，超過500萬；在OpenAI內部，幾乎所有員工每週都在使用，甚至包含不懂程式碼的財務與法務人員。也正因為Codex的成功，團隊對「產品工作該怎麼做」的理解也發生了明顯轉變。

過去產品開發的核心前提是：寫程式很貴，所以要先做研究、寫需求文件、做低保真原型，盡量在正式開發前消除風險。但AI出現後，寫程式與做原型的成本大幅下降，OpenAI內部甚至可能同時有90多個不同團隊，各自做出功能相似的原型。在這種情況下，真正昂貴的已經不是「做出來」，而是如何從大量嘗試中辨認出哪些方向有價值、哪些方案與整體系統相容、哪些真正符合使用者需求。這部分所依賴的，就是產品經理與設計師的品位與判斷力。

安德魯指出，AI時代最大的變化，是整個產品流程被反轉了。以前的稀缺資源是實作能力，現在則是策展能力，也就是在眾多原型與想法中，判斷哪些值得進一步整合進正式產品。這不只是挑出「好不好看」的功能，而是涉及它應該歸屬於哪個模組、是否與整體產品主題一致、甚至連一個開關要設計成幾段都可能是關鍵決策。

對於「PRD已死，原型當立」這類說法，安德魯並不認同。他認為，因為各種表達形式的成本都變低了，所以更重要的反而是選對載體。如果要討論模糊的產品方向、底層邏輯，文件仍然是最適合的形式；如果要驗證互動模式是否可行，原型則更有效。問題不在於哪一種形式取代另一種，而在於你要清楚自己想表達的是什麼，以及應該用什麼方式表達。

他也特別提醒一個容易被忽略的風險：高保真原型帶來的錨定效應。現在一個點子半天就可以做成看似成熟的產品原型，這很容易讓團隊過早被表象帶著走，直接沿著原型修修改改，而忽略了更大的方向探索。原型雖然看起來像成品，但在流程裡可能仍然只是早期假設，不能因為它逼真，就誤以為方向已經確定。

至於大家常說的「品位」，安德魯認為它絕不只是審美。表層上，品位的確包含動效節奏、視覺呈現、介面是否協調；但更深一層，它是系統思維，關乎某個功能放進整體產品後是否適配、是否會與其他模組衝突；再往上，它甚至涉及方向判斷——當什麼都能做的時候，你究竟該做什麼。換句話說，品位不是單純選好看的東西，而是在無限可能裡選出最值得投入的那條路。

談到AI為何寫程式進步很快，但設計能力總是差一點，安德魯認為原因很現實。首先，程式碼好不好比較容易評估，能不能編譯、能不能運行、是否有bug，都有清楚標準；但設計缺乏統一可量化的評分機制，因此很難形成訓練閉環。其次，AI研究本來就優先投入能幫助模型自身進步的能力，程式碼生成能直接幫研究員加速工作，因此發展特別快；設計則沒有這麼明確的正向飛輪。

另外，設計還有更深層的困難，因為它牽涉文化與風格。什麼樣的設計算好，本身就受時代與文化影響。若AI只會反覆生成流行風格，例如一味模仿某些知名產品的美學，那其實並沒有真正解決設計的核心問題。程式碼講求穩定與成熟模式，但設計往往要求差異化與語境貼合，這是更難被標準化的。

在團隊協作上，安德魯描述Codex團隊採取的是一種深度嵌入式合作模式。現在的職能邊界不再用「你從哪做到哪」來定義，而是用「你平均把時間花在哪裡」來區分。設計師可能也會寫程式、做產品判斷；工程師也需要有產品意識。因為大家共同參與建造過程，匯報關係的重要性反而沒那麼高，重點是能不能在同一個場域裡快速協作。

但即便如此，安德魯仍然非常反對「取消產品經理」這種跟風做法。他認為，產品經理是一個有完整方法論、經過長期試錯沉澱的專業，不可能因為AI降低了工具門檻就被視為不重要。就像會用Excel算帳，不代表你具備專業財務能力；會用AI寫幾行程式，也不代表你懂得做產品。工具門檻降低是好事，能幫助不同職能更容易跨界，但這不等於可以否定專業本身。

他也提到，現在的產品團隊更像是在做「區域聯防」。在一個充滿想法與原型、變化極快的環境裡，自上而下規劃一整年的做法已經不太可行。每個產品人更像是守住自己的一塊區域，哪裡有空缺就補哪裡，工作重點從寫需求、排時程，轉成策展、對齊、引導，把公司內部四散的好點子梳理成一致的產品方向。因此，他們招人看重的不只是單一技能，而是主動性與品位，希望每個人都帶著判斷力工作。

在路線圖規劃方面，安德魯認為，越短期的事情越應該做細，越長期的事情則只看方向。任何九個月以後還規劃得鉅細靡遺的計畫，很多時候都只是「虛假的精確」。他們的做法是，把未來一兩年可能想做的功能都先做出原型，再根據當前模型能力判斷哪些已經成熟可以上線，哪些還需要等待。等到底層模型有重大升級，再把舊原型拿出來重新測試。因為決定一個AI產品是否好用的，往往不是介面，而是模型本身夠不夠聰明。

他舉例說，Codex之所以在今年2月推出後大獲成功，如果把同樣的產品提早到去年11月發布，結果很可能完全不同。中間真正改變體驗的，不是產品外殼，而是模型能力的代際提升。因此，產品人不能因為一個功能當下效果不好，就直接判定它是壞點子；它有可能只是出現得太早，還在等待模型能力補上。

當然，超前也不一定是好事。安德魯坦言，他們早期也做過過於激進的產品形態，試圖讓AI高度自主地完成任務，使用者只需下命令即可，但因為當時模型能力不足，結果效果很差。反而一些競品不強調AGI敘事，而是老老實實做輔助型體驗，在不確定時主動詢問使用者，最後更成功。這說明產品節奏感非常重要：要提前布局未來，但不能超前於當下模型能力太多。

最後，安德魯也分享了自己實際如何使用Codex。現在他的角色不再只是寫程式，而更多是做產品與管理，所以他的用法也轉向個人工作流優化。像是每天早上，他會先查看一份由AI自動生成的日報，濃縮他所在幾千個Slack頻道中需要關注的重點；版本發布時，他也會在Notion列出任務，讓Codex自動抓取程式碼提交與Slack更新，完成進度追蹤與協調。OpenAI內部很多人也都用Codex搭建自己的私人工作系統，例如整理資料、過濾郵件、管理記憶等，而產品團隊要做的，就是從這些零散的個人用法中找出共通需求，沉澱成正式功能。

此外，他也提到AI操作瀏覽器與電腦介面的能力，認為這會打開很大的想像空間。未來AI不一定只能透過API整合，還可能直接進入介面替你點擊、設定與完成任務。這意味著AI產品的邊界會變得更寬，從單純的聊天工具逐漸走向真正能幫你做事的代理系統。

整體來看，安德魯的核心觀點很明確：AI確實改變了產品工作的方式，也模糊了許多職能邊界，但這不代表產品經理或設計師會被淘汰。相反地，當實作越來越便宜，真正稀缺的就會變成品位、策展能力、方向判斷與系統整合能力。AI時代不是不需要產品人，而是更需要真正懂產品的人。

[AI 分享] 主流AI熱詞一次搞懂

 [AI 分享] 主流AI熱詞一次搞懂

摘要：從Token、Prompt到RAG、Agent與工作流，系統拆解AI熱詞的由來與用途。

內容:

此貼文的核心目標，把目前主流的 AI 熱詞講清楚，幫助使用者之後再遇到各種新名詞時，不再感到焦慮。整體拆解方式很清楚：每一個概念都回答兩件事，第一，這個詞為什麼會出現；第二，它實際解決了什麼問題。

一開始先講的是 Token 和 Context Window。AI 並不是像人一樣直接閱讀整段文字，而是會先把輸入內容拆成更小的資訊單位，這些單位就叫 token。模型一次最多能處理多少 token，就叫 context window，也就是上下文視窗。像常見的 128k 上下文，本質上就是 AI 一次能看多少資訊。不過，視窗大不代表一定更聰明，因為資訊太少答不出來，資訊太多也可能被干擾。真正影響效果的，不只是模型能看多少，而是使用者怎麼把任務說清楚。

接著出現的是 Prompt。大家很快發現，同樣一件事，不同問法，AI 回答的品質差很多。隨便問一句，可能得到一堆空泛內容；但如果明確交代角色、任務、背景、輸出格式與要求，結果就會明顯更具體、更有結構。所謂 prompt engineering，本質上不是什麼神秘咒語，而是替 AI 寫一份工作說明書，讓它更準確理解任務。

但 Prompt 再強，也解決不了一個根本問題：AI 不知道的事情就是不知道。像公司內部文件、專案程式碼，或昨天才發生的新資訊，如果模型沒見過，就只能猜，於是容易出現一本正經胡說八道的情況。這時就引出了 RAG。

RAG（檢索增強生成） 的邏輯很簡單，就是不要讓 AI 只憑記憶回答，而是先查資料，再根據資料生成答案。做法通常是先把文件、手冊、程式碼等內容放進知識庫，當使用者提問時，系統先檢索相關資料，再交給 AI 回答。這樣產生的答案就不再只是猜測，而是有來源依據。

RAG 也帶出了幾個常見概念，包括 Embedding、向量資料庫、知識庫。Embedding 可以理解成把文字轉成一串數字，方便電腦比較語意距離。這樣即使兩句話字面不同，只要意思接近，系統也能找出相關內容。向量資料庫就是專門存放這些向量，幫助快速找到語意相似的資訊。RAG 的重要性在於，它讓 AI 第一次具備了接入外部知識的能力。

不過，傳統 RAG 更像一次性的搜尋：問一次，查一次。面對複雜問題時，這通常不夠，所以又出現了 Agentic RAG。它不像單純搜尋引擎，而更像研究助理，能判斷資料夠不夠、不夠就換關鍵字繼續查、必要時拆成多個子問題，甚至交叉比對不同來源。到了這一步，AI 已經不只是被動回答，而開始有一點主動研究的能力。

接下來的熱詞是 Tool Calling。RAG 讓 AI 會查資料，但還不代表它能真的做事。Tool Calling 的意義在於，讓 AI 從「提供建議」變成「執行動作」。例如查詢訂單狀態、執行程式碼、讀取日曆，這些都可以透過呼叫外部工具完成。這代表 AI 不只是告訴你怎麼做，而是真的幫你做。

但問題又來了：現實中很多系統沒有 API，或即使有 API，也很難整合。大量工作其實發生在網頁、後台、管理系統中，例如點按鈕、填表單、上傳檔案、切換頁面，這些並不是單純呼叫 API 就能完成的，因此又發展出了 Computer Use。

Computer Use 的概念，是讓 AI 像人一樣操作電腦。它不只是呼叫工具，而是能看懂畫面、理解介面，接著用滑鼠和鍵盤去執行操作，例如打開網頁、點擊按鈕、輸入內容、提交表單、下載或上傳檔案。這對於老舊系統、沒有 API 的內部平台特別重要，因為它讓 AI 有機會進入那些原本只能人工處理的工作流程。不過這個方向也有不少難點，例如介面變動、按鈕識別錯誤、驗證碼、安全與權限等問題，所以想真正穩定落地，還需要很多工程能力支撐。

當 AI 既能查資料、又能呼叫工具、還能操作電腦時，下一個問題就是：它能不能自己完成一個複雜任務？ 這就是 Agent。

很多人把 Agent 理解成更聰明的聊天機器人，但其實不準確。Agent 的關鍵，不是聊天，而是它能圍繞一個目標，自己拆解步驟、選擇工具、執行動作、觀察結果，再依結果調整下一步。普通聊天機器人是你問一句它答一句；Tool Calling 是你叫它做一件事，它去呼叫一次工具；Agent 則更像你給它一個目標，它自己想辦法往前推進。

這也是為什麼 Agent 最早在程式設計領域爆發得特別快。因為程式碼有清楚的檔案結構、具體的錯誤訊息、可執行的測試、可追蹤的版本控制，很適合 Agent 這種「計劃—行動—觀察—調整」的循環模式。像現在的 AI IDE、AI Coding Agent，以及延伸出的 Vibe Coding，本質上都在往這個方向走：由人描述目標，AI 生成實作，人再負責驗收、調整與把關。

但 Agent 越強，風險也越大。它可能會誤改檔案、刪除內容、生成不安全的程式碼、消耗大量 token，甚至做出表面能跑、實際不敢上線的結果。因此，真正要把 Agent 用到生產環境，光靠模型能力不夠，還需要一整套外部約束，這就引出了 Harness Engineering。

Harness Engineering 可以理解成給 Agent 套上的安全帶、方向盤、儀表板與煞車系統。如果模型是發動機，Harness 就是整輛車的控制系統。它通常包含許可權控制、工具白名單、執行沙箱、操作追蹤、錯誤重試、輸出驗證、人工審批、成本控制、安全邊界、回滾機制與評測系統等。核心目標不是讓 Agent 看起來更聰明，而是讓它變得安全、可控、可追蹤、可驗證。這也代表 AI 落地的難點，正從「模型夠不夠聰明」轉向「系統夠不夠可靠」。

最後，內容進一步帶到 Workflow（工作流）。因為企業裡的真實工作，通常不是單一 Agent 就能完成，而是一整條流程。例如客戶提交表單後，系統要先讀表單內容、判斷客戶類型、生成跟進建議、分配給合適人員、寄送通知，再同步到其他系統。這時 AI 不再只是單點能力，而是要嵌進整個業務流程中，成為流程的一部分。

整體來看，這支影片是在幫大家建立一條清晰的 AI 演進脈絡：從最早理解輸入資訊的 token 與 context window，到讓任務描述更清楚的 prompt；再到讓 AI 具備查資料能力的 RAG，延伸到能主動研究的 Agentic RAG；接著從 Tool Calling 到 Computer Use，讓 AI 從回答問題走向實際操作；再往上發展成能自主拆解與執行複雜任務的 Agent；最後再用 Harness Engineering 與 Workflow，把 AI 真正帶進可控且可落地的企業場景。

簡單說，這些熱詞不是彼此割裂的新名詞，而是一條很清楚的能力升級路線：AI 先學會理解，再學會查資料，再學會用工具，接著學會操作系統，最後進入真實工作流程。

[AI 觀點] 企業AI落地兩大障礙

 [AI 觀點] 企業AI落地兩大障礙

摘要 : 企業AI落地最大卡點在於缺資料與缺推動力，核心不只在技術，更在人員觀念與數位化基礎。

內容:

最近接觸了許多企業後，整理出企業AI落地目前最常見、也最核心的兩大障礙：一個是「沒資料」，另一個是「沒人幹」。

首先是資料問題。AI要真正運作，前提一定是有資料。這些資料包含企業內部的資料庫、ERP、知識庫，以及各種業務流程中累積的資訊。如果企業本身沒有足夠、可用、可流轉的資料，就很難支撐AI應用落地，因為沒有資料，就沒有辦法讓AI跑起來。

目前很多企業仍停留在手工時代，特別是一些製造業，依然使用傳統Excel表格去記錄生產製造流程、登記與彙報。這樣的方式不僅人工成本高，效率也非常低，資料也難以形成可持續運作的數位資產。換句話說，企業一方面缺乏完整資料，另一方面也尚未完成數位化，這就成為AI落地的第一大障礙。

對於這個問題，我認為有兩個解法。第一，企業若想推動AI，必須先補上數位化這一課，順勢完成公司的數位轉型。第二，可以從AI需求出發，反向推動數位化，先盤點現有業務邏輯、挖掘需求、理清流程，再倒推企業該如何建立數位基礎。無論從哪個方向切入，資料都是重中之重。

第二大障礙是人的問題，也就是「沒人幹」。很多企業在推動AI數位化轉型時，最大的阻力不是技術，而是員工的心理與行為。第一個常見問題，是員工擔心AI會取代自己。尤其是一些基礎、重複性高的工作，例如資料統計、資料分析，甚至部分設計工作，確實已經被AI大幅改變，這讓員工自然產生不安。

第二個問題，是員工不想學新技術。對很多人來說，原本在崗位上做得好好的，為什麼還要額外增加自己的學習成本與工作量？更何況，學了之後還可能加速自己被取代，這種心態其實非常普遍。

針對人的障礙，我提出三個解決方案。第一，AI必須是一把手工程。因為AI轉型不是單一部門、單一崗位可以獨立完成的事，它需要從全局出發，由企業最高決策者親自推動，才有機會打通部門、資源與流程。

第二，要做全員培訓。企業應該提供學習平台與培訓機會，讓員工知道AI不是單純來淘汰人，而是提供升級與轉型的可能。如果願意跟上，就有機會成長；如果完全拒絕改變，未來自然可能被優化。

第三，是要積極擁抱AI。現在的大環境變化非常快，不跟上AI步伐的人，未來很可能不只是個人落後，也會影響整個組織的效率與競爭力。從這個角度來看，擁抱AI其實不是選擇題，而是生存題。

總結來說，企業AI落地的障礙表面上看是資料與執行問題，但本質上最重要的還是「人」。很多人不願意改變現狀，不願意離開舒適圈，不想增加新的工作事項，也擔心被AI取代。這些心理因素，往往比技術與資金更難解決。

最後，用一句話作為總結：沒有充分的數位化，就沒有全面的AI智慧化。AI真正能否轉動起來，核心仍然在資料，而資料的背後，則是企業是否真正願意完成數位化轉型。

[AI 觀點] Agent Skills 與低程式碼平台之爭

 [AI 觀點] Agent Skills 與低程式碼平台之爭

摘要 : Agent Skills不會立即取代低程式碼平台，企業真正的關鍵在於能否把業務know-how沉澱成可執行、可治理的AI系統。

內容:

近期AI應用開發領域最受關注的問題之一，是Agent Skills是否會取代以workflow編排為核心的低程式碼平台，例如現今常見的各類自動化與流程設計工具。這個問題表面上是在比較兩種開發方式，但背後其實反映出AI應用架構正在發生更深層的變化。

為了說明這件事，分享者以「HR簡歷篩選」作為真實業務案例來對比兩種做法。這個場景雖然常見，但流程其實完整且具代表性，包含候選人上傳簡歷、系統解析文件、提取結構化資訊、模型依標準評分，最後再將結果寫入多維表格。整個過程涉及文件解析、資訊抽取、模型判斷、資料落庫以及多人協作，因此很適合用來觀察兩種模式的差異。

若使用傳統低程式碼平台，通常會將整個流程拆解為多個清楚的節點，例如上傳簡歷、判斷檔案類型、解析內容、欄位映射、評分、資料寫入與結果回傳等，形成一條明確的workflow。這種方式的核心特點，是每個節點的輸入與輸出都非常確定，整體流程透明、可追蹤、可維護。

低程式碼workflow平台的價值，在於它具備企業需要的多項能力：流程可視化、節點可控、異常可排查、結果可入庫、權限可管理、團隊可協作，以及後續可持續維護。對企業而言，這些能力非常重要，因為實際生產環境最怕的是黑盒系統。一旦出現資料遺漏或結果異常，企業需要能夠快速定位問題究竟出在解析、映射、規則，還是權限設定。

相較之下，使用Agent Skills的方式則更接近自然語言驅動。只要事先定義好一個「HR簡歷篩選」的skill，清楚描述使用場景、必要輸入、執行流程、欄位對映、評分原則、異常處理與輸出格式，使用者之後便可以直接對agent下達任務，例如要求其篩選一批Java後端簡歷、依標準打分並寫入表格。剩下的工作則交由agent自動完成。

從本質上看，skills並不是沒有workflow，而是把workflow隱藏在自然語言與任務描述之中。也就是說，skills其實是把一整套業務方法封裝成agent可理解、可調用、可重複使用的能力包。這也是許多人容易忽略的一點：skills不是反流程，而是把流程從顯性編排轉成隱性描述。

若從使用體驗來看，skills確實比傳統workflow更靈活。當HR臨時調整需求，例如改為優先考慮有B端SaaS經驗的候選人，並推薦80分以上的人選時，workflow可能需要重新修改參數或規則；但skills有機會直接理解新指令並調整執行方式。對個人使用者或小團隊來說，這種靈活性極具吸引力，因為它更快、更輕、更自然，也更適合快速驗證業務想法。

然而，這種靈活性同時也帶來企業級落地的難題。當skills進入正式生產環境時，會面臨評分標準如何統一、執行路徑如何穩定、權限如何控制、結果如何治理等問題。這些都是目前skills模式相對薄弱的地方，也正是企業在選型時不得不重視的風險。

因此，在工具選擇上，分享者認為應依場景判斷。若是個人或小團隊做快速驗證、原型開發，skills通常是更合適的選擇，因為它能讓業務先跑起來，降低啟動成本。但若進入企業真實生產環境，尤其涉及候選人隱私、資料安全、權限管理、規則版本控制等要求時，顯性的workflow平台依然更可靠，也更符合企業對穩定、可控與可治理的需求。

第一個核心洞察是：Skills不會讓workflow平台消失，但會迫使它們升級。未來的workflow平台將越來越agent化，不再只是靠人工拖拉拽來搭建流程，而會引入更多AI生成與理解能力；反過來，skills系統也會逐漸平台化、治理化，補足企業落地所需的控制能力。兩者未來很可能不是彼此取代，而是向中間靠攏，最終融合成新的產品形態。

第二個核心洞察，也是整場分享最重要的結論：真正決定AI應用效果的，從來不是工具本身，而是業務know-how。以Java後端職位篩選為例，真正有價值的不是用哪個平台，而是企業是否清楚知道該如何評分，例如Java基礎能力佔多少、微服務經驗佔多少、專案複雜度該怎麼判斷。這些業務標準，才是AI能否真正承載企業能力的關鍵。

進一步來看，AI應用的競爭表面上像是workflow、skills與agent之間的競爭，但本質上其實是「業務know-how如何被承載」的競爭。誰能把企業內部的經驗、規則與判斷標準沉澱下來，讓它們能在流程中執行、在結果中驗證、在反饋中持續更新，誰才真正具備長期價值。

最後總結來說，workflow、skills與agent，本質上都只是AI應用的承載層。它們主要解決的是流程步驟、模型調用、工具使用、資料寫入與異常處理等問題。這些固然重要，但真正最難的從來不是工具，而是企業是否已經具備一套可被AI調用的知識體系與SOP系統。

所以，今天討論workflow還是skills，表面上是在做工具選型，實際上是在回答一個更大的問題：企業是否有能力把業務know-how轉化為可執行、可觀測、可迭代的AI系統。若沒有這個能力，換任何平台都可能只停留在demo；若具備這種能力，那麼不同平台都只是不同階段的承載方式。真正值錢的，不是平台本身，而是企業持續沉澱流程、知識、資料與評價體系的能力。

[AI 分享] Agentic RAG為何成為企業級AI關鍵

 [AI 分享] Agentic RAG為何成為企業級AI關鍵

摘要 : 傳統RAG常因檢索不準、無法理解意圖與處理複雜任務而失效，企業場景更需要具規劃、工具調用與反思能力的Agentic RAG。

內容:

許多公司表面上看似很聰明的AI客服或智慧系統，實際上只是關鍵詞匹配器。當使用者提出稍微複雜一點的問題，系統就容易開始編造答案。這不一定是模型能力不足，而是很多系統仍停留在傳統RAG的做法上，只能查資料，卻無法真正理解問題與思考解法。

在實際生產環境中，傳統RAG幾乎已經無法滿足多數企業需求。內容指出，約有80%到90%的企業級場景，都需要依賴Agentic RAG，才能應付真實業務中的複雜需求。這也是本篇重點：從工業需求出發，說明為什麼Agentic RAG正在成為主流方案。

文章先回顧傳統RAG的基本概念。大模型如GPT-4、DeepSeek等，知識主要來自訓練時使用的公開資料，因此對企業內部的私有文件、產品手冊、合約與流程內容通常不了解。RAG的作用，就是讓模型在回答前先去查資料，以外部知識補足模型原本不知道的內容。

標準的RAG流程通常包含幾個步驟：先把PDF、Word等文件切分成小段，再透過Embedding模型轉成向量，存進向量資料庫；當使用者提問時，也把問題向量化，從資料庫中找出最相似的片段，最後再把問題與檢索到的內容一起交給模型生成答案。整體上，它像是一個會先查文獻再作答的AI助手。

問題在於，這套流程在工業應用中常常效果不佳。第一個致命痛點是檢索相關性差。系統可能因為只抓關鍵詞而找到表面相似、實際無關的內容，導致模型基於錯誤資料生成一本正經卻完全錯誤的回答，也就是常見的幻覺問題。這在企業場景中特別危險，因為錯誤建議可能直接影響客戶或業務決策。

第二個問題是缺乏意圖理解。使用者的提問往往不完整，例如只問「那個報錯怎麼修」，卻沒有提供是哪個系統、哪個模組、什麼情境。傳統RAG只會照原句去檢索，不會主動追問，也無法補全上下文，因此很容易答非所問。文中用看病做比喻：如果病人只說「我難受」，醫生卻不能進一步問診，只能根據這兩個字開藥，效果當然不會好。

第三個問題是無法處理複雜任務。很多企業問題不是單一步驟就能完成，例如分析最近三個月A產品退貨率上升多少、原因是什麼、有哪些改善方案。這種需求往往需要先查資料、再做分析、最後提出建議，但傳統RAG只會執行一次檢索與一次生成，缺乏拆解問題與逐步推理的能力。

因此，Agentic RAG被提出作為新一代解法。它不是單純換名稱，而是一種理念上的升級：把大模型從被動查資料的閱讀器，變成能主動解題的問題解決者。文中將它概括為「RAG + Agent」，核心差異在於，它不再只是拿到問題後直接查與答，而是能夠自己判斷接下來該怎麼做。

相較於傳統RAG像是一位照本宣科的實習生，Agentic RAG更像是一位專案經理。它具備三個關鍵能力。第一是規劃能力，能把問題拆成步驟，思考是否需要分階段處理。第二是工具調用能力，可以根據任務需要決定該查資料庫、呼叫API，還是進行其他搜尋。第三是反思能力，會回頭檢查答案是否可靠、是否需要進一步修正與最佳化。

在工作流程上，Agentic RAG通常會先重寫查詢，把模糊問題轉成更清楚、可執行的形式。例如將「報錯怎麼修」改寫為更具體的查詢內容，甚至主動要求補充像是最近一次502錯誤的日誌資訊。接著，系統會判斷目前資訊是否足夠回答；如果上下文不足，就不急著生成答案，而是先向使用者追問必要細節。

若資訊足夠，系統才會進一步進入檢索、分析與決策流程。這代表Agentic RAG不再是一次性的固定流水線，而是可以根據問題狀態做動態判斷。也正因如此，它更適合真實企業環境中那些模糊、多步驟、需要驗證的工作任務。

整體來看，傳統RAG雖然解決了大模型知識過時與無法存取私有資料的問題，但在檢索準確度、意圖理解與複雜任務處理上仍有明顯限制。Agentic RAG則透過規劃、工具調用與反思機制，讓AI從單純查資料進化成能主動處理問題的系統，這也是它成為企業級AI應用關鍵技術的主要原因。

[AI 分享] 大模型 Skill 載入機制

 [AI 分享] 大模型 Skill 載入機制

摘要 : 大模型技能不該一次全塞進提示詞，而應以三層按需載入機制，兼顧上下文、成本與效果。

內容:

在大模型系統中，很多新手一開始會直覺地認為，既然要讓模型具備多種能力，那就把所有技能說明、程式碼檔案與參考資料一次性全部放進提示詞裡。這種做法看似直接，實際上風險很高。

首先，大模型的上下文視窗非常寶貴。如果同時塞入大量技能內容，不只容易讓上下文迅速膨脹，導致模型無法抓住重點，也會明顯提高推理成本，進而帶來高昂的使用費用。

較好的做法是採用「漸進式披露」的思路，也就是一種三層式的技能載入機制。它的核心精神是：只在真正需要時，才載入對應的資訊，避免無效佔用上下文空間。

第一層是「原資料」。可以把它理解為一張簡潔的工具清單，放在模型隨時可見的位置。這份清單只包含每個工具的名稱，以及一句簡短介紹，讓模型知道自己有哪些能力可用。因為內容非常精簡，所以可以長期保留在上下文中，而不造成太大負擔。

第二層是「技能正文」。當模型根據第一層的清單，判斷當前任務需要某個特定技能時，系統才會進一步載入該技能的詳細說明。這部分通常包含具體步驟、操作規則與注意事項。也就是說，只有在技能真正被觸發時，這些較長的核心內容才會被臨時加入上下文。

第三層是「捆綁資源」。有些任務除了技能說明外，還需要更大型的參考資料、字典，甚至可直接執行的程式碼腳本。這時系統不會一次把所有內容完整展開，而是依照任務進度，精準調用當下需要的那一小部分資源。像是腳本可以直接執行，不必把全文讀進上下文；查資料時，也只取出必要片段即可。

整體來看，這種三層載入機制的本質就是按需載入。用不到的資訊不提前加入，需要時再精準調用。這樣不僅能有效保護上下文空間、降低成本，也能讓大模型把注意力集中在眼前任務上，提升整體執行效率與品質。

[AI 評估維護] AI模型技能評估與回歸測試方法

 [AI 評估維護] AI模型技能評估與回歸測試方法

摘要 : 建立AI Skill評估與維護系統，提升生產環境中的穩定性、可靠性與可維護性。

內容:

如何建立一套系統化的方法，來評估與維護 AI 模型的 Skill，並進一步提升它在實際應用中的可靠性與可維護性。這件事之所以重要，是因為很多 Skill 一旦部署到生產環境後，表面上看起來可以正常運作，但每次修改之後，團隊往往缺乏客觀標準去判斷這次調整究竟是優化，還是造成退步。短期內或許還能靠經驗判斷，但隨著系統越來越複雜，風險也會快速累積。

尤其當 Skill 已經接入真實工作流後，它可能會呼叫工具、生成檔案、改變系統狀態，因此每一次修改都不只是改一段提示詞，而是可能牽動整個系統行為。真正的挑戰，不只是讓 Skill 能運作，而是要確保它在持續變動的過程中，依然保持穩定、可預期的表現。

在評估 Skill 之前，首先要先釐清到底要評估什麼。根據內容提到的方法，成功標準可以分成四大類。第一是結果目標，也就是任務有沒有完成、應用有沒有成功跑起來。這是最直觀、也最容易被單獨關注的一項。第二是過程目標，重點在於 Skill 是否依照預期設計的步驟與工具鏈執行。第三是風格目標，也就是輸出是否符合既定規範，例如檔案結構、命名方式、程式碼風格等是否一致。第四則是效率目標，檢查是否存在多餘的工具呼叫、資源浪費，或不必要的 Token 消耗。只有把這四類目標綜合起來，才能比較全面地衡量一個 Skill 的真實表現。

另外，Skill 的維護不應只聚焦在執行內容本身，而是要分成「執行體」與「觸發邊界」兩個獨立面向來看。執行體指的是 Skill 的具體指令、步驟與工具鏈；觸發邊界則是 Skill 的名稱與描述，也就是它在什麼情況下會被選中或被呼叫。這兩者雖然彼此獨立，但都會直接影響最終效果。實務上，團隊通常比較容易關注執行體的修改，卻忽略了描述文字與觸發條件的變動也可能讓 Skill 在不該啟動的時候被啟動，因此兩部分都必須分開維護與檢查。

接著，內容也提到三類容易被忽略的隱藏假設，這些往往是 Skill 失控的來源。第一類是觸發假設，意思是 Skill 是否能在該被呼叫時被呼叫，不該被呼叫時不會誤觸發。如果邊界不清楚，就可能出現原本只是要調整樣式，卻意外啟動新應用的情況。第二類是環境假設，也就是 Skill 是否偷偷假設了某些執行環境條件，例如預設目錄是空的、系統已安裝某些工具，這些在開發環境中可能不明顯，但一旦換環境就容易出錯。第三類是執行假設，指的是 Skill 內部步驟之間的依賴是否被妥善處理，例如還沒安裝依賴就嘗試啟動服務，這種問題可能不是每次都發生，但本質上是潛在風險。

為了降低這些風險，就需要建立回歸樣本集。最重要的原則，是把歷史上曾經導致 Skill 出錯或失控的真實案例收集起來，整理成回歸測試樣本。這個樣本集不一定要很大，每個 Skill 大約十幾到二十個 Prompt 就可能足夠，關鍵在於能否覆蓋重要的失敗場景與風險邊界。

這些樣本可以分成幾種類型。第一種是顯示呼叫，也就是直接指定要測試某個 Skill。第二種是隱示呼叫，只描述要解決的問題，觀察系統會不會自動正確選中這個 Skill。第三種是帶上下文的呼叫，也就是加入真實業務中的雜訊與背景資訊，測試 Skill 在複雜情境下是否仍能被正確識別。第四種則是復控樣本，也就是刻意設計那些本來不應該觸發該 Skill 的輸入，檢查是否出現誤觸發。這類樣本特別重要，但在實務中經常被忽略。

在自動化評估方面，核心前提是先把 Skill 的執行軌跡完整記錄下來。像是執行了哪些命令、建立了哪些檔案、操作順序如何，都應該以結構化日誌的方式保存。只有當這些過程資料被穩定記錄後，後續的自動評分器才有依據可以判斷 Skill 的表現是否合格。

自動評分器大致可以透過兩種方式來運作。第一種是確定性檢查，也就是預先定義明確規則，檢查某個命令是否有執行、某個檔案是否有建立、步驟順序是否正確。這種方式優點是規則明確、容易除錯，也適合驗證基礎功能是否正確。不過它的限制是，很難判斷最終產物「好不好」。

因此，第二種方式是評分細則檢查，也就是引入大模型進行整體評估。像是程式碼結構是否合理、命名規範是否一致、輸出品質是否達到要求，都可以透過多維度打分的方式進行判斷。把確定性檢查與評分細則檢查結合起來，就能同時兼顧底層功能正確性與整體結果品質，讓 Skill 的評估更完整，也更接近實際生產需求。

[AI 分享] RAG是否已死

 [AI 分享] RAG是否已死

摘要 : RAG並未過時；雖然大模型上下文變長，但在成本、效率與私有知識接入上，RAG仍具重要價值。

內容:

RAG（Retrieval Augmented Generation，檢索增強生成）是近年大模型領域中相當成熟的一項技術。不過，最近有不少自媒體開始宣稱「RAG已死」，因此本文希望從原理、價值與爭議三個角度，重新梳理RAG的前世今生，看看這個說法是否站得住腳。

從名稱來看，RAG本質上是一種「用檢索來增強生成效果」的方法。傳統做法是把問題直接交給大模型作答；而在RAG架構中，會在問題與大模型之間加入一個檢索模組，先從外部知識庫中找出相關內容，再將問題與檢索結果一併交給模型。這樣做的根本原因在於：原始問題所需的資訊，往往不完整存在於大模型本身，因此需要透過外部知識庫來補足，尤其是企業私有資料、內部文件或特定領域知識。

那麼，為什麼不直接把整個外部知識庫全部丟給大模型？原因很簡單，因為大模型有上下文長度限制。即使上下文已經比以前大很多，把所有知識一次性輸入，不但可能超出限制，也會讓模型分析與計算的成本大幅上升，因此仍需要一套有效率的篩選與檢索機制。

RAG的基本流程大致如下。首先，外部知識庫會先被切分成多個較小的文本分片。這樣做的目的是讓系統在每次檢索時，更容易找到和問題最相關的局部內容，而不是從龐大原文中無差別處理。這些分片，就是之後會提供給大模型參考的文本材料。

接著，這些文本分片需要經過向量化（embedding）處理。由於電腦本質上處理的是數值而不是文字，因此必須將文本轉換為向量，映射到向量空間中。在這個空間裡，語意相近的文本應該彼此靠近，語意差異大的文本則距離較遠。也就是說，若兩段內容意思相近，經過向量化之後，它們在向量空間中的位置也應該相近。

當使用者提出問題時，問題本身也會先被向量化。接著，系統會拿這個問題向量去比對知識庫中各個文本分片的向量，找出最接近、也就是語意上最相關的幾個分片。最後，再把問題與這些相關分片一起送進大模型，讓模型在有額外上下文支援的情況下生成答案。這也是RAG能提升回答準確度的核心原因。

這裡有一個很重要的前提：知識分片與使用者問題在向量化時，應採用一致的向量化模型或演算法。只有在同一套語意映射規則下，系統才能保證語意相近的內容在向量空間中也足夠接近，進而讓檢索結果具有可靠性。

雖然RAG的整體流程看起來不複雜，但真正進入工程實作時，仍有許多細節需要最佳化。首先是分片策略。分片如果切得不好，就可能破壞語意完整性，例如把同一句話、同一條法規或同一段關鍵說明拆散，導致檢索時拿到的是殘缺資訊。以法律文件為例，理想情況是以完整法條作為切分單位，而不是把一條法規拆到不同分片裡。因此，不同場景下需要不同的分片邏輯。

第二個關鍵點是向量化演算法的選擇。RAG是否能準確找回相關內容，很大程度取決於向量模型是否能正確表達語意相似性。實務上常常需要針對不同資料集，測試多種向量化方案，挑選效果與效能兼顧的方法。

第三個重點是檢索策略本身。系統可以只取最相近的兩個分片，也可以擴大到三個、五個甚至更多。檢索條件設得太嚴，可能漏掉重要資訊；設得太寬，則可能帶入太多雜訊。因此，檢索數量與門檻也需要依應用場景做客製化調整。

那麼，為什麼會有人說「RAG已死」？其中一個主要理由，是因為現在大模型發展很快，上下文長度越來越大。像 DeepSeek、Gemini 等模型都已支援非常長的上下文，於是有人認為，既然模型可以一次讀進大量內容，就不再需要額外的檢索流程，只要把所有相關資料直接給模型即可。

但這樣的推論其實並不充分。即便上下文夠大，把所有資料一股腦交給模型，仍然會面臨兩個現實問題：第一是效率，因為大模型推理本來就慢，輸入內容越多，整體處理時間越長；第二是成本，更多的上下文代表更高的計算資源消耗。因此，僅因上下文變長就斷言RAG失去價值，並不合理。

另一種批評則來自效果面。有人認為，RAG依賴分片檢索，容易造成語意遺失，因此最終效果不如預期。這個問題確實存在，但它更像是「RAG做得不夠好」，而不是「RAG沒有用」。因為RAG本質上是一個框架，真正的效果高度依賴分片方式、向量化品質與檢索策略。只要這些環節有足夠細緻的最佳化，RAG仍然可以產生相當不錯的結果。

總結來說，RAG並沒有死。相反地，它仍然是在私有知識接入、大模型回答增強、控制成本與提升效率等場景中非常重要的方法。大模型上下文變長，確實會改變RAG的使用方式，但不代表它會被完全取代。更準確地說，RAG正在演進，而不是消失。