[AI 啟發] AI時代工程師晉升的乘數思維

 [AI 啟發] AI時代工程師晉升的乘數思維

摘要：技術深度不是晉升資深工程師的唯一關鍵，真正差異在於能否放大團隊影響力並建立可複利的系統。

內容:

很多工程師以為，只要程式碼寫得更快、架構設計更複雜、技術鑽研更深入，就能自然從高級工程師晉升到資深工程師。但實際上，許多技術能力很強的人，反而會長期卡在這個階段。問題不在於技術不夠，而在於資深工程師與高級工程師的價值維度，本質上並不相同。

Pinterest 的 Staff 工程師 Jordan Cutler 提出一個很重要的觀點：高級工程師偏向「加法」，重點是自己能完成多少工作；而資深或 Staff 工程師更偏向「乘法」，重點是能否放大周圍人的能力，讓整個團隊的產出持續複利成長。這也是《The Multiplier Mindset》所強調的核心概念。

Jordan 自己也曾走過典型工程師的路線，長時間專注在大量輸出程式碼上。但後來他意識到，自己最大的影響力，往往來自那些表面上看起來不像「寫程式」的事情，例如建立分享機制、推動跨團隊合作、打造可擴充的度量系統。

第一個關鍵維度，是擴大自己的表面積。當時公司並沒有要求 Jordan 負責 AI 相關工作，但他敏銳察覺 AI 正在改變開發模式，而且這與他提升開發者效能的職責高度相關。於是他開始積極研究各種 AI 編碼工具與工作流。

如果是一般高級工程師，可能只會把這些工具用來提升自己的寫碼效率；但 Jordan 的做法不同。他主動找來同樣對 AI 有興趣的同事，一起建立了名為「How AI」的 Slack 頻道，鼓勵大家分享 AI 使用經驗與提效方法。結果這個頻道一天內就吸引了 200 多人加入，幾個月後更成長到 1200 多人。

在這個基礎上，他又進一步推出多個提升效率的 AI 工具，例如排程工具、文件生成器、簡報生成器，甚至探索 MCP 整合。這些成果也逐漸被公司高層注意，Jordan 開始受邀在工程、產品與設計組織的月度 demo 上分享，之後更加入公司級的 AI 編碼探索小組，並參與標準制定。

這整件事並不是被指派的任務，而是他主動建立了一個能讓價值自然擴散的空間。這種做法的重點，不只是自己會用新工具，而是讓更多人一起學、一起用，進而形成組織級影響力。

第二個關鍵維度，是跨團隊影響力。Pinterest 當時有一個公司級目標：提升網頁載入速度。Jordan 最初負責審計搜尋頁面，分析變慢原因。他深入研究使用者操作流程與底層渲染過程，找出瓶頸，也估算了優化空間。

一開始他用很典型的技術語言溝通，例如直接指出「你們的 JSON payload 有 500KB，太大了，需要改」。但這樣的說法並沒有引起對方重視，因為這只是在指出問題，卻沒有降低對方理解與執行的門檻。

後來他調整了方式，改成用更具體、更貼近業務價值的語言來描述。例如，他不再只說資料量太大，而是說：「這個搜尋回應有 500KB，遠超過實際需要。如果修正，使用者看到結果的速度可以快 100 毫秒。」同時，他也補上清楚且不複雜的修復建議，例如減少查詢參數欄位，以及對回應資料做規範化處理。

這樣的溝通方式有三個特點：指出問題、量化影響、提供方案。也因為如此，相關團隊才願意把這項優化排進優先順序。

之後，Jordan 更進一步主動接觸其他高流量頁面的團隊，例如 home feed 與 pin page，提出免費幫忙做效能審查。他也從跨頁面使用者流程中找出優化機會，例如當使用者從首頁點進圖片詳情頁時，在高解析圖片尚未載入完成前，可以先沿用首頁上已顯示的中解析圖片，而不是讓使用者看到空白背景。這些建議最終讓核心頁面的效能提升超過 30%。

值得注意的是，做這些事情時，Jordan 當時還只是 senior 工程師。他並不是靠管理權限推動事情，而是透過跨團隊影響、用資料說服與降低協作門檻，實際創造了超出自身職責範圍的影響力。

第三個關鍵維度，是建立可擴充、可持續運作的系統。Jordan 與他的經理曾面臨一個問題：大家無法清楚回答「團隊的開發者體驗到底好不好」。雖然手上有各種零散指標，例如 CI 建置時間、GitHub PR 數據、Jira 開發速度，但缺乏統一且全局的判斷框架，導致團隊常常只能被動救火，誰抱怨什麼就先修什麼。

為了改善這個情況，Jordan 設計了一套框架，把三種層次的資訊整合起來：第一是團隊可直接控制的技術指標，例如建置時間；第二是開發者每天實際感受到的工具摩擦；第三是管理層可追蹤的大盤指標，例如整體開發者體驗指數。

更重要的是，他沒有只是蒐集資料，而是為每個指標建立明確的紅黃綠基準。例如 CI 流水線低於 12 分鐘是綠色，12 到 18 分鐘是黃色，超過 18 分鐘就是紅色。這讓原本模糊的抱怨，轉化成清楚可行動的訊號。像是「CI 太慢了」這種主觀感受，就能變成「CI 目前紅燈，平均耗時 19 分鐘」的客觀資訊。

有了這套系統後，跨部門協調與 OKR 對齊變得更容易。團隊每季規劃時，不再靠感覺決定優先順序，而是先看哪些指標已經飄紅，再往回推導應該投入哪些改善項目。

更進一步的是，Jordan 將這個系統自動化。團隊只需要透過簡單設定檔定義指標名稱與門檻值，後端流程就會每週自動抓取資料、計算變化，並在每週一透過 Slack 發出格式化報告。這使得問題與退步可以被持續追蹤，而且不依賴 Jordan 本人每天手動維護。

由於接入方式很簡單，其他團隊也能快速採用，像 API Platform 團隊只花一天就完成導入。這正是可擴充系統的價值：你不是只解決一次問題，而是打造一個基礎設施，讓其他人也能自行運作並持續受益。

Jordan 的案例說明了一件很重要的事：晉升並不是單純靠技術能力的線性堆疊。資深工程師真正的核心價值，不是自己能做多少，而是自己建立的機制、工具與系統，能讓其他人做得更多、更快、更好。

一個能自動運轉的 AI 分享社群、一份讓其他團隊願意採用的效能優化建議、一套在你休假時仍能自動監控與回報的度量框架，這些才是具備複利效果的工作，也是 AI 時代工程師更值得追求的晉升能力。

[AI 分享] Agent七大架構選型指南

 [AI 分享] Agent七大架構選型指南

摘要 : 梳理七種主流Agent架構，說明優缺點與適用場景，幫助依需求選擇最合適方案。

內容:

目前主流的七種 Agent 架構，從最簡單的單 Agent，到企業級常見的圖形化工作流，目的在於幫助大家理解：Agent 並沒有唯一標準答案，真正重要的是依照場景複雜度、控制需求與系統目標來選型。

一開始先提出三個核心結論。第一，Agent 架構沒有統一標準，該怎麼選，取決於任務有多複雜，以及你希望保留多少控制力。第二，整體發展路徑通常是從單 Agent，走向多 Agent 協作，再進一步進入圖形化工作流。第三，如果是做 AI Coding 或技能型系統，Router 加 Skill 架構目前是相對成熟且實用的最佳實踐。

第一種是單 Agent 架構。這種方式是由一個大模型處理所有事情，包含接收使用者輸入、進行思考、呼叫工具，再輸出結果。它的優點是架構簡單、成本低，也容易快速上手，像 ChatGPT 這類模式就屬於這一型。缺點則是當任務一旦變得複雜，模型容易出現思考負擔過重、上下文汙染嚴重的問題，同時處理多件事時也容易失準。

第二種是 ReAct 架構，也就是 Reason 加 Act，先推理再行動。它的運作方式是一個持續迴圈：先思考、再行動、觀察結果後繼續思考，直到任務完成。這種架構相較單 Agent，更適合多步驟任務，也具備較好的鏈式推理與可解釋性。不過它的缺點是 Token 消耗較大，穩定性也不算高，容易在過程中跑偏，因此不太適合大規模工程化系統。

第三種是 Plan and Execute 架構。這種方式更偏向工程化思維，先由系統生成完整計畫，再交由執行器依照步驟逐一完成。它的優勢在於穩定性較高，適合用在程式碼生成、專案自動化與長流程任務。缺點則是如果一開始規劃錯誤，後續整體執行就可能全面失效，靈活性也不如 ReAct。

第四種是 Dual Agent 或多 Agent 分工架構。這類做法會讓多個 Agent 各司其職，通常還會有一個任務協調與分配系統，底下再由不同角色如規劃者、審查者、執行者共同協作。它的優點是任務拆解更清楚，也能減少上下文污染，整體擴展性較強。缺點則是成本較高，系統也更複雜，因此比較適合團隊協作、複雜專案或企業級應用。

第五種是 Router 加 Skill 架構，也是內容中較推薦的一種方式。核心概念是先透過 Intent Router 做意圖識別，再將請求直接路由到對應的 Skill 執行。每個 Skill 都是明確定義好的能力模組，並附帶對應知識與說明。這種架構的優勢是穩定性高、可控性強，也容易做快取與效能優化，命中率也較好評估。目前不少 AI Coding 與技能系統，基本上都採用這個思路。缺點則是 Skill 的設計成本高，且可能出現技能命中衝突的問題。

第六種是 Blackboard 架構，也就是黑板系統。這種做法允許多個 Agent 同時讀寫共享狀態，並透過狀態變化來驅動整個執行流程。它很適合複雜協作情境，但狀態管理非常困難，一旦出錯也不容易追蹤問題。像一些工作流引擎與分散式系統，就常見這類設計思路。

第七種是 Graph 與 Graph Workflow 架構。這是企業級生產環境中非常主流的一種模式，透過有向無環圖來編排工作流，能支援條件分支、並行執行、可回溯與可重試。常見代表工具包括 LangGraph、Temporal、Airflow 等。它的優勢在於穩定、可除錯、適合長流程，特別適合企業級流程自動化與正式生產部署。

最後，做了整體總結：單 Agent 適合做簡單驗證，ReAct 適合多步探索，Plan and Execute 適合工程化流程，多 Agent 適合協作場景，Router 加 Skill 適合精準技能系統，Blackboard 適合共享狀態協作，而 Graph Workflow 則適合企業級生產環境。

整體重點很清楚：不需要一開始就追求最複雜、最高級的架構，而是應該依照自己的場景複雜度與實際需求做選擇。沒有最好的架構，只有最適合的架構。

[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真正能否轉動起來，核心仍然在資料，而資料的背後，則是企業是否真正願意完成數位化轉型。