[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正在演進，而不是消失。

痛點營銷的成交關鍵

 [AI 影響] 痛點營銷的成交關鍵

摘要 : 透過具體場景與嚴重後果，讓客戶看見問題風險，提升危機感與購買意願。

內容:

痛點營銷的核心，不是一直強調產品有多好，而是要真正站在客戶角度，理解他內心的擔憂與需求。很多銷售雖然很勤奮、很熱情，卻始終無法成交，原因往往在於只會介紹產品優點，卻沒有讓客戶感受到「不解決問題」的後果。

客戶真正買單的原因，通常不是因為產品參數多厲害，而是因為他意識到，如果現在不處理這個問題，未來可能會付出更大的代價。換句話說，客戶害怕的不是產品本身，而是忽略問題之後所帶來的風險。

因此，銷售在溝通時，不能只停留在表面介紹，而要把產品轉化成生活中的具體場景，並清楚描述問題若持續存在，可能造成哪些實際影響。當風險可以被想像、被看見，客戶就更容易產生危機感，也更願意採取行動。

例如賣淨水器時，如果只是說水裡有雜質、鐵鏽，客戶通常不會覺得嚴重。但若進一步說明，長期使用含有雜質與重金屬的水，可能影響皮膚狀態、堵塞毛孔，甚至讓保養效果變差，客戶就會更直接感受到這個問題與自己生活息息相關。

這套方法的關鍵公式，就是「具體場景＋嚴重後果」。它適用於大多數行業，因為本質上是在幫助客戶看見那些平常被忽略的小問題，並理解這些問題若不處理，將逐步影響生活品質、形象，甚至健康。

除了淨水器，像服裝銷售也能運用相同邏輯。若只是強調價格或款式，吸引力有限；但若讓客戶意識到，長期只圖便宜、忽略穿搭質感，可能會影響整體氣質與他人對自己的印象，客戶就更容易理解購買背後的價值。

所以，銷售真正賣的從來不只是產品，而是一種更安心、更省心、更有品質的生活方式。好的銷售，是透過專業幫助客戶發現風險、看見後果，並提供解決方案，進而促成成交。

[AI 影響] AI分詞到未來職場的關鍵變化

 [AI 影響] AI分詞到未來職場的關鍵變化

摘要 : AI其實靠分詞、機率預測與上下文運作，並非真正思考；理解其侷限與Knowhow價值，將是未來關鍵。

內容:

想了解AI，首先要先理解它最基礎的動作：分詞。分詞可以視為人類語言與AI語言之間的翻譯過程。當人類輸入一句話時，系統會先把文字拆成一個個token，再進一步轉成對應的數字，也就是token ID。這些token ID才是AI真正能理解與處理的語言，之後才會送入大語言模型進行計算。

很多人以為大語言模型像人類一樣，會先思考、分析，再給出答案，但其實並不是如此。大模型本質上是一個數學函式，它不會思考，只會計算。它每次只能產生一個token，也就是一次只輸出一個單位的答案，所以我們平常看到AI像是一個字、一個字慢慢生成回覆，其實正是它逐步計算與輸出的結果。

而AI之所以能持續產生內容，是因為它會根據接收到的所有資訊，去計算詞表中每個候選詞出現的機率，再選擇最有可能的結果作為下一個輸出。因此，AI看起來像是有智慧，實際上是因為它不斷在做高機率預測，而不是像人類那樣真正理解世界。

這也帶出一個重要問題：高機率不等於正確答案。AI之所以可能答對，是因為某個答案在資料中出現機率最高；但如果錯誤資訊被大量散播，錯誤答案的機率也可能上升，甚至超過正確答案。這代表AI不僅會出現幻覺，也可能被輿論、內容操作與商業手法所影響。

近年出現的GEO（生成式引擎最佳化），正是建立在這種邏輯之上的商業模式。透過最佳化網路上的產品資訊與內容格式，讓AI更容易將這些內容判定為高品質、高相關，進而提高推薦機率。這說明AI的回答不只可能出錯，也可能受到商業利益引導，尤其對老人與孩子這類較缺乏判斷能力的使用者來說，更需要建立正確認知：AI可以參考，但不能盲信。

除了輸出邏輯，AI還高度依賴Context，也就是上下文。上下文包含對話歷史、使用者提示詞、系統提示詞，以及AI正在生成中的內容。這些資訊會被一併送入模型，成為它預測下一個token的基礎。若把LLM比喻成AI的大腦，那麼Context就像它的短期記憶。

而這個記憶是有上限的，這個上限就叫Context Window。它指的是模型單次最多能處理多少token。目前主流模型的上下文容量已經相當驚人，基本都能超過100萬token，換算成中文約可達150萬字。對一般使用者而言，問題往往不是夠不夠用，而是如何有效利用這麼大的容量。

為了讓AI接觸更多外部資料與工具，於是出現了MCP，也就是模型上下文協議。它可以理解成AI世界裡的統一接孔，像電腦的USB一樣，讓模型能更方便地連接外部能力。在這個基礎上，又延伸出幾個重要概念，例如Workflow工作流、Agent智慧體、智慧體駕馭框架，以及Skill技能包。

如果把整個AI系統想像成一座工廠，那麼工作流就是高度自動化的生產線；智慧體則像是能規劃、執行任務的AI員工；而智慧體駕馭框架則像主管，負責協調、管理與約束這些智慧體，避免它們失控或出錯。至於Skill技能包，則像是每位AI角色所擁有的專業能力證照，不論是文案、設計、維修、表格，甚至各行各業的專業技能，都可以被封裝成工具供AI調用。

這也讓知識的形態出現巨大改變。對人類而言，知識往往需要長期學習、練習與內化；但對AI來說，知識更像是可直接使用的工具。一旦具備相關能力模組，它就能快速投入工作。這種效率差距，對許多職位都形成了壓力。

因此，未來人類真正的競爭力，可能不再只是會不會用AI，而是是否擁有Knowhow。Knowhow指的是一個行業長時間累積下來的隱性經驗，是那些沒有完整寫在書上、卻存在於專家判斷與實作細節中的能力。這種能力來自實戰、直覺、感受與判斷標準，也是AI最難直接取代的部分。

例如同樣是做出百萬播放影片，新手可能需要反覆嘗試很多次，但有經驗的創作者往往能更快掌握觀眾心理、節奏、選題與傳播方式，因此更有機會一次成功。這種差距，不只是技術工具的問題，而是Knowhow的差距。

相關就業資料也反映了這種趨勢。當高Knowhow的高級崗位仍維持成長時，低Knowhow的初級崗位卻開始下滑，尤其在生成式AI普及後，這個差距變得更加明顯。這代表AI正在重塑職場門檻，也讓年輕人在還沒真正累積工作經驗前，就面臨被替代的壓力。

這也引發兩個值得深思的問題。第一，年輕人若在進入職場前就被AI取代，未來該如何累積自己的Knowhow？第二，已經擁有Knowhow的專家，是否還願意繼續分享自己的經驗？因為在AI時代，知識分享不再只是幫助後進，也可能同時成為提升AI能力、加速取代更多人的來源。

最終，這些問題或許沒有簡單答案。但可以預見的是，未來世界的人可能會分成兩個方向：一群人選擇回歸家庭、自然、身體、信仰與真實關係，重新尋找文明的源頭；另一群人則全面奔向AI、機器人、腦機介面與新生產力革命，探索文明的下一站。這兩條路，也許都代表著人類在新時代中的不同選擇。