[AI 轉型] Java後端轉AI Agent，先搞懂系統本質差異

 [AI 轉型] Java後端轉AI Agent，先搞懂系統本質差異

摘要 : Agent不是聊天介面，而是半確定性的任務執行系統，後端轉型先理解邊界與架構。

內容:

如果你是 Java 後端工程師，最近想轉向 AI Agent，很可能會有一種感受：學了不少東西，像是 Spring AI、LangChain、向量檢索、LangGraph、RAG、Prompt Engineering，但回頭一看，距離真正做出一個可上線的 Agent 還是很遠。

問題往往不在於學得不夠多，而是起點選錯了。很多人一開始就急著學框架、寫 Prompt、搭工作流，但這些解決的其實只是「怎麼做」。真正更重要的，是先想清楚「你要做的東西，本質上和傳統後端系統有什麼不同」。

過去做後端，本質上是在構建一個確定性系統。請求進來之後，參數是什麼、進哪個 Controller、調哪個 Service、回什麼結果，大多數都已經預先定義好。輸入明確、流程明確、輸出明確，這就是傳統後端最熟悉、也最穩定的模式。

但 Agent 面對的通常不是標準化請求，而是一個模糊任務。使用者可能說：「幫我整理一下這批客戶反饋」、「幫我分析最近業績為什麼下滑」、「幫我找出報表中的異常」。這不是傳統 API 參數，而是把一個任務交給系統去完成。

因此，Agent 更像是一個任務執行系統。它要先理解目標，再判斷需要什麼資訊、是否要查資料、是否要呼叫工具、是否要拆步驟執行，最後再組織結果輸出。與傳統後端最大的差異在於：以前流程主要由程式碼寫死，現在流程中有一部分要由模型依據上下文動態判斷。

到了 Agent 場景，傳統後端的三個確定性都被打破了。第一，輸入不再確定，因為使用者講的是自然語言，常常不完整、也不精確。第二，流程不再完全確定，系統可能要檢索、呼叫工具、追問、重試，甚至依據中間結果改變執行路徑。第三，輸出也不再完全穩定，因為模型生成內容每次都可能有細微差異。

這也是 Agent 最核心的一個概念：半確定性系統。所謂半確定性，不是放任系統不受控，而是把一部分交給模型負責理解與生成，把另一部分交給工程系統負責約束與兜底。模型負責靈活，工程負責穩定；模型可以有變化，但系統不能失控。

所以，後端工程師在 AI 時代的價值，絕對不只是會呼叫模型 API，而是能把大模型這種天然不穩定的能力，接到穩定的業務系統中。像是權限控制、工具調用、失敗重試、日誌追蹤、結果評估，這些都不是模型自動幫你處理的，而是標準的工程問題。

很多人以為 AI 應用就是做一個聊天框，後端呼叫一次模型 API，再把答案回傳給前端。這頂多只能算是最小 Demo。真正要上線時，你會面對的是：使用者是誰、能看哪些資料、能用哪些工具、執行過程能不能審計、結果出錯能不能追溯、模型或版本升級後效果有沒有下降。當這些問題出現，Agent 其實就重新回到了後端工程師最熟悉的戰場。

如果把 Agent 抽象化來看，通常離不開四個核心要素。

第一是目標，也就是使用者到底想完成什麼任務。  

第二是上下文，也就是系統能拿到哪些業務資訊、歷史資料與知識。  

第三是工具，也就是系統可調用的 API、資料庫、搜尋與計算能力。  

第四是約束，包括權限、風控、成本、審計與評估，哪些事情絕對不能失控。

有了這個結構之後，再看各種 Agent 場景就會清楚很多。客服 Agent 是圍繞客戶問題調用知識庫和工單系統；辦公 Agent 是圍繞文件、日程、郵件做任務編排；研發 Agent 則是圍繞程式碼、測試、部署做工具調用。本質都一樣：理解目標、取得上下文、調用工具，並守住業務邊界。

如果是後端工程師想練習這套能力，一個很適合的真實場景是「智慧問數」，也可以理解為經營數據分析 Agent。因為老闆、營運、財務、銷售主管，幾乎每天都在問資料：收入為什麼漲了？利潤為什麼掉了？哪個區域異常？現金流壓力來自哪裡？

例如，當使用者問「上個月經營利潤為什麼下滑？」這句話背後絕對不是單純生成一條 SQL 就能解決的事。系統需要先理解利潤的計算口徑，再分析收入、成本、費用的變化，還要依照區域、產品、客戶類型去拆解，找出真正的異常來源。最後輸出的，也不應只是一張查詢表，而應該包含結果表、趨勢圖、關鍵原因，以及可追溯的分析過程。

這也說明了一件事：企業級智慧問數，不等於 Text-to-SQL。網路上很多 Demo 看起來很酷，像是使用者提問後，模型直接產出 SQL 並執行。但在企業裡這其實很危險，因為真實資料環境裡會有指標口徑、欄位歧義、權限邊界、查詢成本與結果解釋等問題。只會生成 SQL，根本不足以支撐企業級需求。

真正的企業級問數 Agent，要做的是把自然語言問題，轉化成一個受控的資料分析任務。模型可以負責理解問題、拆解思路、生成候選查詢；但指標口徑、權限校驗、SQL 安全、執行限制、審計日誌、結果評估，都必須由工程系統來兜底。這就是所謂的「上層靈活、下層穩定」。

為了更容易理解，可以把這個場景拆成三層。

第一層是模型判斷層，負責理解使用者問題、判斷意圖、拆解分析步驟，並生成候選查詢與說明。  

第二層是任務編排層，負責檢索指標口徑、選擇資料來源、判斷是否需要追問，並組織查詢、校驗、執行與彙總。  

第三層是業務治理層，負責指標定義、行列權限、SQL 安全、查詢超時、審計日誌，以及效果回歸與評估。

這個場景特別適合後端工程師入門 Agent，因為它不是單純聊天，也不是炫技 Demo。它同時包含模型理解、工具調用、業務口徑、權限安全、結果輸出、可追溯與可評估等完整問題，而且經營分析、財務分析、銷售分析，也確實是企業願意買單的真實需求。

所以這篇內容真正想強調的，不是哪個框架最好，而是先建立一個正確判斷：Agent 不是普通介面，而是半確定性的任務執行系統。後端工程師要學的，也不是放棄原本的工程能力，而是把資料庫、權限、任務、日誌、穩定性這些老本行，接到大模型時代的新系統裡。

在真正開始選框架、選技術棧之前，應該先把系統邊界與架構想清楚。只有先理解使用者是誰、輸入是什麼、輸出是什麼、邊界在哪裡，才不會一開始就把方向走偏。

[AI 分享] AI程式設計的盲區管理

摘要 : 模型愈強，AI寫程式的瓶頸愈不在模型，而在於人是否說清需求與管理未知。

內容:

這兩天 Claude Code 團隊工程師 Tarek 發了一篇長文，談怎麼用 Fable5 做更好的 AI 程式設計。表面上看，這是一份工具使用指南，裡面有 prompt、原型、實施計劃，以及程式碼合併前的檢查方法；但更值得注意的，是它點出了 AI 程式設計正在出現的關鍵變化。

過去大家用 AI 寫程式時，常常是在測試模型能力，例如它能不能理解需求、找對檔案、修掉 bug、跑通測試，或像工程師一樣掌握專案上下文。但到了 Fable5 這類等級後，瓶頸開始改變：很多時候，影響工作品質的已經不是模型會不會做，而是人有沒有把那些沒說清楚的地方講明白。

這個判斷很重要。因為 AI 程式設計進入 Agent 階段後，它不只是幫你補幾行程式碼，而是會讀倉庫、改檔案、跑命令、處理跨檔案任務，也會在長時間任務中替你做很多中間決策。這時，Prompt 更像是一張地圖，但真正要進入的是程式碼庫、業務邏輯、歷史包袱、現實限制，以及團隊裡那些沒寫進文件的習慣。地圖再細，也不可能覆蓋所有細節；凡是沒交代清楚的地方，模型就只能自己猜。

也因此，很多人都會遇到一個熟悉的現象：小任務很驚艷，大任務開始發散。像是改一個函式、補一個測試、寫一個腳本，通常效果很好，因為邊界清楚、目標明確，模型不需要替你做太多判斷。但如果讓它做完整功能、改複雜模組，或搭一個產品頁面，它就會開始補完你沒說清楚的部分。它可能替你決定狀態結構、錯誤處理方式、服務層拆法，甚至加入一些看起來很專業、但專案其實不需要的抽象。這些選擇未必錯，真正的問題是：模型不是違背要求，而是在填補你沒說出口的空白。

文中把這些空白分成四類。第一類，是你已經知道，也已經寫出來的內容，例如明確告訴模型要在哪裡加按鈕、按下去要做什麼。第二類，是你知道自己還沒想清楚的地方，例如要不要支援行動裝置、失敗時怎麼提示、權限不足時要顯示什麼。第三類，是你心裡有標準，但平常不會寫下來的東西，例如頁面是不是順眼、互動是不是自然、文案語氣對不對。這些很難事前說清楚，但結果一出來，你通常一眼就知道對不對。第四類最麻煩，是你根本沒想到的問題：你不知道這個領域有哪些坑、不知道程式碼庫有哪些歷史約定、不知道以前的人為什麼這樣寫，也不知道這件事其實可以做到什麼程度。很多 AI 程式設計失敗，就發生在這一類。

這也是為什麼，真正厲害的 Agentic coder，不只是會寫 prompt，而是熟悉程式碼庫、懂模型特性，也清楚自己真正要什麼。他們知道哪些地方必須先問清楚，哪些地方可以交給模型發揮，哪些地方一定要保留回頭修正的空間。換句話說，AI 程式設計的核心能力，正在從「寫一個好 Prompt」，轉向「管理整段協作中的未知」。

Tarek 在文章裡提出了幾個很實用的方法。

第一個方法是 Blind Spot Pass，也就是盲區掃描。假設你要在陌生模組中加入新功能，例如接一個新的認證方式，但你對現有 Auth 模組並不熟。很多人會直接說「幫我接入這個 Provider」，但更好的起點是先請模型做盲區掃描，找出你現在還沒意識到的風險與問題，讓後續提問更準確。這一步的價值在於先承認自己不知道，讓模型先去翻程式碼庫、找既有模式、整理潛在風險，例如哪些權限處理不能忽略、哪些相容性不能漏、哪些地方看似簡單其實會牽動架構。這時 AI 的角色，就不只是執行者，而更像能幫你擴大視野的搭檔。

第二個方法是先做原型。特別是介面、設計、互動這類問題，很多標準不是靠語言就能講清楚。你說「高級一點」、「清爽一點」、「像某個產品一點」，模型未必真的懂，你自己也未必真的想清楚。這種情況下，不要急著直接改真實專案，可以先請模型做一個獨立的 HTML 頁面，用假資料產出幾個方向。等你看到實際畫面後，判斷會快很多：哪個太重、哪個太花、哪個版面對、哪個資訊層級不行。這看起來像繞路，但其實能大幅降低後面返工成本。因為在原型階段發現問題很便宜，等到真實程式碼已經接好狀態、介面、測試，再發現方向錯了，撤回就沒那麼輕鬆。

第三個方法，是讓模型反過來問你。當你有大致方向，但還有很多地方模糊時，不要只是一味把 Prompt 寫得更長，而是可以要求模型一次只問一個問題，而且優先問那些會改變架構的問題。這點非常關鍵，不是所有問題都值得同等對待。像按鈕名稱、顏色細節，之後都還能調；但資料模型、型別介面、權限邊界、使用者流程，這些一旦選錯，後面代價就很高。好的需求澄清，不是問題越多越好，而是能儘快把真正影響方向的問題提到前面。這其實很像一位可靠工程師接到需求後，先確認誰會用、失敗時怎麼辦、哪些輸入合法、哪些行為不能發生、上線後誰維護、舊資料怎麼處理。AI 沒有消滅這些問題，只是讓它們更快浮上檯面。

第四個方法，是給參考。很多時候你說不清自己想要什麼，不是因為表達能力差，而是因為有些東西本來就很難只靠文字描述清楚。你想要某個函式庫的重試策略、某個網站元件的互動、某個工具列的佈局，與其堆砌一堆形容詞，不如直接給參考。Tarek 特別強調，最好的參考往往是原始碼。截圖只能讓模型知道外觀，原始碼則能讓它理解結構、狀態、邊界與處理方式。對 AI 程式設計來說，真正重要的常常不是表面長相，而是實作語義。像是 Rate Limiter 如何處理重試、API Client 如何處理錯誤、元件如何拆分狀態，這些自然語言很容易漏細節，但程式碼反而更精確。

第五個方法，是先寫實施計劃。這不是為了增加流程感，而是為了把關鍵決策提前攤出來給人審視。文中的建議是，讓模型把最可能需要人調整的部分放在前面，例如資料模型、新型別介面、使用者可見流程；至於格式調整、搬移檔案、樣板程式碼這類機械性工作，可以放後面。這背後反映的是一個很現實的事：人的審查精力有限，不可能逐行檢查所有模型生成內容，但一定要盯住那些一旦決定就很難回頭的部分。模型幫你做重構或樣板碼，風險相對低；模型替你決定系統邊界，則必須先看。

此外，Tarek 也建議在實作過程中，讓模型維護一份 Implementation Notes.md，記錄它中途做了哪些決定、何時偏離原計劃、為什麼選了更保守的方案。這個做法看似樸素，但對長任務非常有效。因為長任務最怕的不是模型某一步做錯，而是它默默做了很多你不知道的決策，最後你只看到一個 diff，卻無法還原過程。有了這份實施筆記，至少能幫助你回頭理解：原本計劃哪裡不適用、程式碼裡出現了什麼邊界情況、模型為什麼沒有照原方案走。這樣你拿到的就不只是一堆程式碼，而是一段可被理解、可被追溯的決策過程。

整體來看，這篇文章真正重要的地方，不只是教你怎麼用某個工具，而是提醒我們：當模型能力越來越強，人類工作的重點就越不是下更華麗的指令，而是更誠實地面對自己不知道什麼、沒想清楚什麼，以及哪些決策不能交給模型默默完成。AI 程式設計的難題，正在從模型能力問題，轉向協作與未知管理問題。這可能才是下一階段最值得重視的能力。

[AI 趨勢解析] 主流AI熱詞演化路線全整理

 [AI 趨勢解析] 主流AI熱詞演化路線全整理

摘要 : 一次看懂AI熱詞從Token、Prompt到Agent與Workflow的出現邏輯與實際用途。

內容:

用一條清楚的演化路線，整理目前主流AI熱詞的來龍去脈，核心重點不是背名詞，而是理解每個概念「為什麼會出現」以及「它解決了什麼問題」。只要掌握這套脈絡，之後再看到新的AI術語，也比較不容易焦慮或混亂。

一開始先從最底層的 Token 與 Context Window 講起。AI在處理文字時，並不是像人一樣直接讀完整句子或文章，而是會先拆成更小的資訊單位，也就是 Token。這個概念會直接影響模型一次能讀多少內容、使用成本如何計算，以及為什麼對話太長時，AI會忘記前面說過的內容。所謂 Context Window，就是模型一次最多能處理的上下文範圍。它越大，不代表AI一定越聰明，而是代表它一次能接收的資訊更多；真正影響效果的，還是任務是否描述清楚。

因此，Prompt 提示詞成為早期最重要的AI熱詞之一。大家很快發現，AI並不是不會做，而是常常因為任務描述不清，導致輸出空泛或偏題。提示詞工程的本質，不是寫神秘咒語，而是替AI寫一份明確的工作說明書，包括角色、任務、背景、輸出格式、限制條件與範例。Prompt解決的是「如何讓AI理解你要它做什麼」，但它無法解決模型本來就不知道的事情。

接著就出現了 RAG。因為如果AI沒看過公司文件、專案程式碼或最新資料，它只能靠機率猜答案，進而產生一本正經卻不正確的內容。RAG，也就是檢索增強生成，核心邏輯很簡單：先查資料，再回答。系統會先從知識庫中找出相關內容，再交給AI生成答案。這讓AI從只靠記憶回答，進化成可以基於外部資料作答。這一段也延伸出 Embedding、向量資料庫與知識庫等概念，本質上都是為了讓系統更準確地找到語意相近的內容，而不是只做表面的關鍵字比對。

當普通RAG無法應對複雜問題時，又進一步發展出 Agentic RAG。它不再只是查一次資料就結束，而是像研究助理一樣，會判斷資料夠不夠、是否需要換關鍵字重查、是否要把大問題拆成小問題，甚至交叉比對不同來源。這代表AI開始從被動回答，走向更主動的推理與研究。

但就算AI能查資料，仍然不等於它真的能做事。於是 Tool Calling 或 Function Calling 出現了。這讓AI不只是給建議，而是能呼叫外部工具或系統，例如查日曆、讀資料庫、執行程式碼、查詢訂單狀態等。RAG讓AI有資料室，Tool Calling則讓AI有手，可以真正去執行動作。

工具越來越多之後，新的問題又浮現：每個工具的介面、參數、權限與回傳格式都不同，整合成本非常高。這時 MCP 開始受到關注。MCP可以理解成AI連接外部工具與資料來源的統一協議，像是AI世界裡的 Type-C。它的價值不在於讓模型更聰明，而在於讓AI能以更標準化、可管理的方式接入真實世界中的工具與系統。

接下來，影片也提到 Scale 的概念。Prompt像一次性的指令，而 Scale 更像是長期可重複使用的標準作業流程。它代表的不只是叫AI做一次事，而是把某一類任務的方法沉澱成穩定、可複用的能力。這對個人、團隊與企業都很重要，因為它能把工作風格、標準流程與崗位經驗逐步轉化成AI能力。

再往前一步，就是 Computer Use。這是AI從呼叫API，進化到像人一樣直接操作電腦。當系統沒有API、只能靠人工在網頁或後台點擊操作時，Tool Calling就無能為力了。Computer Use 的價值在於，AI可以看螢幕、理解介面、點按按鈕、填表、上傳檔案、下載報表，甚至在多個頁面之間切換。這讓AI開始能進入很多老舊系統與只能人工操作的工作場景，但同時也帶來穩定性、安全性與權限管理上的挑戰。

當AI具備查資料、用工具、操作電腦等能力後，大家自然會問：它能不能自己完成複雜任務？這就是 Agent 的核心。Agent 不是比較會聊天的機器人，而是能圍繞一個目標，自行拆解步驟、選擇工具、觀察結果，再持續調整行動的系統。它的關鍵是循環：先規劃、再執行、再觀察、再修正。這也是為什麼AI Agent最先在程式設計領域爆發，因為程式碼有清楚的檔案結構、錯誤訊息、測試結果與驗證方式，非常適合AI自主迭代處理。

而像 Vibe Coding 這類詞會流行，也是因為程式開發模式正在改變。過去是人寫程式、AI輔助；現在逐漸變成你描述目標，AI幫你實作，人類主要負責驗收、調整、架構設計與品質控管。只是 Agent 越強，自由度越高，風險也越大，像是誤刪檔案、亂改程式碼、越權存取資料、消耗過多資源等問題，都會放大。

因此，Harness Engineering 變得非常重要。它可以理解成給Agent加上安全帶、方向盤、剎車與儀表板。模型像發動機，Harness 則是控制系統。這一層通常包含權限控制、工具白名單、沙箱執行、追蹤記錄、錯誤重試、輸出驗證、人工審批、成本控管、回滾機制與評測系統。企業真正需要的，不是看起來很厲害的Agent，而是安全、可控、可追蹤、可驗證的Agent。

當AI開始進入真實業務場景後，單一Agent往往還不夠，因為企業運作通常是一整條流程。這時 Workflow 就很關鍵。Workflow 解決的是「一整個業務流程如何串起來」，例如讀取表單、判斷客戶類型、查CRM、生成建議、發通知、寫資料庫、排入後續跟進等。Agent負責思考與判斷，Workflow則負責把步驟、系統、審批與自動化節點串接起來，讓AI真正進入穩定運轉的業務流程。

最後，談到 Workspace Agent。這比一般的Workflow更進一步，因為企業真正想要的，不只是跑完一條流程，而是擁有一個長期存在於工作空間中的數位助手。Workspace Agent 不只是執行一次任務，而是理解團隊長期積累的上下文，例如文件在哪、誰負責什麼、哪些資訊敏感、什麼時候要提醒、什麼時候需要審批、哪些任務卡住了。普通Agent比較像臨時工，Workspace Agent 則更像長期駐點的數位員工。

整體來看，這些AI熱詞其實不是彼此孤立的新名詞，而是一條非常清楚的能力演化路線：從AI一次能看多少內容開始，進入如何正確理解任務，接著學會查資料、呼叫工具、統一接入外部系統、操作電腦、自主拆解任務、安全執行、串接流程，最後走向真正融入團隊工作的數位助手。理解這條主線後，未來再看到新的AI概念，就更容易知道它是在補哪一層能力、解哪一類問題。

[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應用關鍵技術的主要原因。