[AI 反思] AI降本神話破滅：企業開始重新計算人與機器的成本

摘要：AI使用成本暴增、管理失控，企業開始懷疑當初以AI取代人力的決策是否失算。

內容：

過去幾年，許多企業把AI視為降低人力成本、提升效率的終極工具，甚至因此大規模裁員。然而到了2026年，這套邏輯正遭遇強烈反噬。原本被認為能取代員工、替公司省錢的AI，實際運行起來卻開始比真人勞動更昂貴。

這個問題並不是個別現象。像Uber原本為2026年整年編列的AI程式碼生成預算，才到4月就已經用罄；微軟內部也直接限制多部門員工繼續使用Anthropic的程式碼工具，原因同樣很直接：成本太高。許多企業這才發現，維持AI運作的費用，可能早已超過過去支付給員工的薪資。

造成這場成本危機的根源之一，是企業過去被早期AI公司的低價策略誤導。2022年到2025年間，OpenAI、Anthropic等公司為了搶市場，大量用資本補貼價格，讓企業誤以為AI是一種便宜、可無限使用的生產力工具。但AI與傳統軟體不同，它不是固定成本，而是每一次生成、對話、分析都在消耗真實算力，而算力本身是按Token計價的。

到了2026年，AI供應商為了上市與獲利，開始把原本隱藏的成本轉嫁給企業。市場上大約85%的SaaS供應商，陸續從按人頭收費改成按用量收費。這讓企業第一次真正感受到，AI成本並不是平均的，而是可能極度失控。

例如，一般行政人員一天可能只消耗一萬個Token，但工程師若拿高階模型分析大型程式碼庫，一天就可能燒掉一千萬個Token。同樣是一名員工，因工作內容不同，成本差距可能達到上千倍。更誇張的是模型之間的價差，有些便宜模型每百萬Token只要幾美分，但最頂級的推理模型每百萬Token可能高達180美元，價差達數千倍。

當企業缺乏權限管控時，問題就更嚴重。很多員工即使只是處理簡單問題，也直接呼叫最昂貴的模型，導致帳單迅速失控。Meta就是典型案例，內部每月Token消耗量驚人，支付給外部AI供應商的年費高達數十億美元。甚至連AI公司自己內部，也出現員工單月就燒掉十幾萬美元API額度的情況。

除了價格結構本身，另一個讓成本惡化的因素，是一種荒謬的管理文化：把Token消耗量當成績效指標。部分管理層認為，員工用越多AI，就代表越積極、產出越高。結果在錯誤KPI引導下，員工開始刻意拉長提示詞、同時開多個AI代理，甚至讓AI空轉處理無意義任務，只為了交出漂亮的使用報表。

這種現象被稱為「Token Maximization」或「Token Maxxing」。表面上看起來是企業AI使用量高速成長，實際上卻可能只是員工為了迎合制度，在後台大量浪費算力。最終結果不是效率提升，而是公司被巨額AI帳單反噬。

表面上這是一場技術成本問題，但實質上，它是由錯誤定價模式、短視管理決策與畸形職場文化共同造成的後果。

在這種情況下，很多企業與外包團隊其實已經開始調整策略。對於不需要高階推理能力的任務，例如資料清洗、初步翻譯、客服自動回覆等，企業往往不再使用最昂貴的西方大模型，而是悄悄切換到中國大模型或低成本開源模型，以壓低支出。

這背後反映的是不同商業模式的競爭。部分西方AI公司希望靠單次呼叫直接獲利，把模型當高價產品販售；而一些中國廠商則更像在經營基礎設施，先用低價甚至近乎白送的方式綁定企業，再透過雲服務與客製化方案賺錢。這種策略對高成本AI市場形成了直接衝擊。

但即使有了更便宜的替代方案，很多大型金融、醫療、法律等高度敏感產業，仍不敢輕易切換。因為更深層的問題已經浮現：資料安全與供應商綁定。企業過去幾年為了接入AI，把大量財務資料、客戶資訊、內部流程與商業知識輸入外部模型。如今他們開始擔心，自己不只是在付費使用工具，還可能在無形中把核心資產交給供應商。

企業擔憂的是，當AI公司吸收了足夠多的行業知識後，未來完全可能直接推出垂直產品，反過來與原客戶競爭。再加上一旦企業的工作流程、系統架構與員工習慣都被某個模型綁住，未來供應商漲價、改規則或技術升級，企業幾乎沒有議價能力。

也因此，2026年開始出現另一股明顯趨勢：企業轉向開源模型與小參數模型。經歷高昂帳單之後，許多公司終於意識到，不是所有任務都需要最強、最貴的大模型。對很多日常場景而言，本地部署的小模型就已經夠用。

例如客服中心、報表整理、制式文件生成等固定型任務，若改用部署在內部伺服器的開源模型，雖然能力不如頂尖商業模型全面，但成本更固定、資料更安全，也更容易控管。與其長期支付昂貴的雲端API費，不如一次性投入設備，在本地穩定運行。

因此，市場上開始出現一種新的角色：「AI降本工程師」。這類人才的任務不是把更多業務丟給AI，而是精準拆解流程，判斷哪些地方該用本地模型、哪些能用規則系統處理、哪些根本不需要AI。他們存在的目的，就是幫企業擺脫對高價大模型的依賴。

事情發展到這一步，整個局面變得相當諷刺。AI原本是為了取代人類、降低成本而來，結果企業現在不僅要支付高昂的Token費、雲端費與伺服器費，還得再聘請一批專家專門控制AI成本，避免AI本身成為新的財務黑洞。

當市場熱潮退去，企業開始重新面對一個原本不願承認的問題：如果AI的成本已經高於真人，而且還伴隨資料風險、供應商綁定與管理失控，那麼當初那些為了追逐AI風口而被裁掉的員工，是否其實裁錯了？

近幾個月，部分公司已經開始悄悄把過去裁掉的基礎職位重新招回來。只是對外，他們通常不會承認原因是AI太貴，而會用其他更體面的說法包裝。這也意味著，這場AI取代人力的浪潮，或許正在進入一個意想不到的反轉期。

最終，這不只是技術效率的問題，而是一場企業經營現實對AI狂熱敘事的集體修正。當機器的使用成本開始超越人的成本，企業真正要面對的問題，也許已經不再是「該裁多少人」，而是「該把多少不合理的AI幻想裁掉」。

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

[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、機器人、腦機介面與新生產力革命，探索文明的下一站。這兩條路，也許都代表著人類在新時代中的不同選擇。

[分享] 賣的不只是產品，而是顧客的嚮往

 [AI 分享] 賣的不只是產品，而是顧客的嚮往

摘要 : 真正高價與高利潤的關鍵，往往不是解決問題，而是滿足顧客對身分、自由與美好生活的嚮往。

內容:

最會賺錢的人，往往不只是會解決問題，而是懂得滿足顧客內心深處的嚮往。當產品只是在解決功能性需求時，顧客可能只會購買一次；但當產品承載了某種理想生活、身分象徵或情感價值時，顧客就更容易持續買單。

以咖啡為例，速溶咖啡主要解決的是「提神」與「方便」的需求；但星巴克賣的並不只是咖啡，而是都市人嚮往的「第三空間」——一個介於家庭與工作之間，能夠放鬆、社交、短暫喘息的生活場景。因此，一杯原本只值幾塊錢的咖啡，能夠被賦予更高的價值。

再看包包市場，幾百元的包已足以解決日常收納需求，但愛馬仕販售的並不是單純的實用品，而是一種頂級階層的象徵與入場券。像鉑金包這樣的產品，價格可高達數十萬，甚至長年缺貨，背後反映的正是顧客對身分認同與稀缺價值的追求。

同樣的邏輯也出現在其他產業中。露營經濟賣的不只是帳篷與裝備，而是現代人對逃離內捲、回歸自由與自然的想像。迪士尼賣的也不只是樂園門票，而是一種能短暫逃離現實、進入夢幻烏托邦的沉浸式體驗。

這也說明了一個重要觀點：痛點只能促成一次交易，但嚮往更能建立長期吸引力與品牌忠誠。當顧客購買的不再只是功能，而是對某種生活方式、情感狀態或社會角色的投射時，產品的價值就會被大幅放大。

因此，真正值得思考的，不只是你的產品能幫顧客解決什麼問題，而是它能幫顧客實現什麼樣的嚮往。

[AI 分享] 設計師也能高效用 Codex

 [AI 分享] 設計師也能高效用 Codex

摘要 : Codex正快速成為設計師新工具，透過上下文、外掛與技能配置，可產出更精緻且可迭代的UI原型。

內容:

OpenAI正式推出更適合設計師使用的Codex，且設計師已成為成長最快的使用族群之一。隨著外掛、標註、可分享站點預覽等功能陸續上線，Codex不再只是工程師的工具，對設計師、行銷人員等非技術使用者也越來越友善。

Codex本質上是一個由OpenAI推出的編碼代理，可以在終端、IDE與桌面端運作，自主完成讀取專案、編寫程式、檢查成果，再交由使用者稽核的流程。背後模型也針對不同場景進行調校，有適合快速任務的低延遲版本，也有能處理複雜工作的高能力版本。

對設計師來說，使用Codex是否能做出真正有質感的成果，關鍵不在一句提示詞，而在於事前是否提供足夠完整的上下文。如果只輸入「幫我做一個儀表盤」，雖然它能生成畫面，但結果往往會流於常見、缺乏辨識度的AI風格，因此建立明確的上下文是最重要的一步。

第一個核心做法，是建立一份Agent MD檔案。這份檔案可以視為專案簡報，裡面可放入設計規範、元件樣式、設計變數、排版規則、色彩系統與注意事項。它的好處是Codex會自動讀取，不需要每次重新解釋需求。除了告訴AI要做什麼，也要明確寫出不要做什麼，例如避免過度花哨、玻璃擬態或亮眼漸層等風格，這能大幅降低產出偏離預期的機率。

第二個重要步驟，是安裝外掛。Codex的外掛可連接MCP伺服器與各種技能包，幫助AI與外部工具整合。對設計師來說，產品設計外掛相當實用，能協助探索產品方向、檢查使用流程、分析痛點，甚至把真實網址直接轉換成可在本機執行的互動原型。若本身有使用Figma，也非常推薦安裝Figma外掛，能加快從設計稿到可執行程式碼的流程。

另外，像Mobbing這類設計靈感平台的MCP伺服器也很值得導入。因為它能讓Codex分析大量來自Uber、Netflix、Apple等成熟產品的真實介面，協助生成更符合市場慣例與高品質設計模式的UI，避免AI只靠猜測做出空泛的畫面。

第三個步驟則是使用技能。技能可理解為一套可重複使用的指令規則，能讓Codex依照特定方法工作。設計師可依自己的流程建立專屬技能，例如生成圖片、優化介面、套用設計工程規範等。搭配Agent MD與外掛，技能能讓整個產出流程更穩定，也更符合團隊標準。

當這三項配置完成後，就可以開始第一次生成。文中示範的案例，是用最新模型生成一套桌面版深色模式投資儀表盤，包含儀表盤、交易、預算與目標分析、持倉與設定等頁面。提示詞除了描述頁面需求，也會要求參考Agent MD檔案與附帶的靈感圖片，讓Codex更清楚視覺方向。

在生成過程中，如果資訊不足，Codex還會主動追問，例如要做靜態精緻UI，還是完整可互動原型。這代表它不只是被動接收命令，而是能協助釐清任務目標。若是較簡單的專案，可以直接要求產出完整原型；若專案較複雜，則建議先確認風格與結構，再逐步擴充互動功能。

值得注意的是，使用產品設計外掛後，Codex在交付成果前還會進行視覺質檢。它會自動開啟瀏覽器檢查產出畫面，擷取狀態並修正與參考圖明顯不一致的地方。這種讓AI自行檢查與校正成果的能力，對提升最終UI品質非常重要，也能減少設計師後續手動微調的負擔。

整體來看，Codex對設計師的價值，不只是「幫你畫圖」而已，而是能在設計系統、靈感參考、互動原型與視覺校驗之間形成一套更完整的工作流。只要前期把上下文、外掛與技能配置好，Codex就有機會成為設計師身邊像全職助手一樣的存在，協助快速產出更成熟、可執行且更有質感的設計成果。

[AI 分享] 賣點要翻成需求

 [AI 分享] 賣點要翻成需求

摘要 : 顧客不是為產品參數買單，而是為自己的麻煩、爽感與期待買單。賣點若能對準需求，成交力才會提升。

內容:

很多老闆賣不動貨時，第一反應是拼命加碼講賣點：材質、工藝、價格優勢、品牌實力一直重複說。但賣點講得越多，顧客反而越無感，因為問題往往不是顧客聽不懂產品，而是他感受不到這東西和自己有什麼關係。

核心觀念是：賣點是你想說的，需求才是顧客想買的。你一直講產品多厲害，使用者未必會付錢；但只要講中他的麻煩、慾望與期待，他就會立刻產生感覺。真正驅動下單的，從來不是產品參數，而是需求被點燃。

王老吉就是典型例子。如果它一直講草本配方、傳統工藝、口感清爽，大家未必記得住；但一句「怕上火喝王老吉」，立刻讓人知道什麼場景該買：吃火鍋、吃燒烤、熬夜、喉嚨不舒服時。它不是在背賣點，而是直接站穩了需求場景。

顧客下單，常被三個按鈕推動：第一是痛點，想少一點麻煩；第二是爽點，想立刻變爽；第三是癢點，想成為更好的自己。像賣枕頭，不要只講記憶棉、人體工學，而要講「醒來脖子不僵不痛」；賣口紅，不只講色號和持久，而要講「一擦上氣色變好，出門就被誇」；賣眼霜，不只講成分科技，而要講「看起來沒那麼累、沒那麼顯老」。

所以不是賣點不能講，而是不能只站在產品角度往外倒。你要把產品語言翻譯成使用者語言：把「人體工學分區承托」翻成「明天醒來脖子不疼」，把「持久不脫妝」翻成「一出門就被誇氣色好」，把「緊緻科技」翻成「看起來更年輕更有精神」。

最後要記住，顧客不是為你的產品買單，而是為自己的問題、情緒和期待買單。別再只問產品有多少賣點，而要問顧客現在有什麼麻煩、想立刻得到什麼爽感、期待自己變成什麼樣。只有被需求接住的賣點，才真正有成交力。

[AI 分享] 用戶運營與關係建立

 [AI 分享] 用戶運營與關係建立

摘要：用追求與交往的過程，比喻用戶運營從陌生到信任再到支持的完整路徑。

內容:

把使用者運營放進真實的人際互動場景裡，就會更容易理解它的本質。就像你不會在毫無鋪墊、對方還不認識你的情況下，直接向一個女生表白；同樣地，你也不該一開始就急著向使用者推銷產品、強調自己有多好。因為在最初階段，對方對你是陌生的、無感的，也缺乏了解。

這個階段可以對應到使用者運營的A1。此時最重要的不是成交，而是先讓對方認識你、了解你，並看到你值得被關注的一面。就像在追求過程中，你會自然展現自己的生活態度、價值觀與優點，慢慢建立第一印象。

當對方開始對你產生一些好感時，就進入了A2階段。這時候不只是被看見，而是開始形成初步的認同。你透過持續互動，讓對方感受到你的真誠、穩定與吸引力，讓關係從陌生慢慢走向熟悉。

接著到了A3階段，雙方關係進一步升溫。你會開始描繪共同的願景，也會在困難出現時表現出立場與承擔，讓對方感受到安全感與信任感。這在使用者運營中，代表的不只是曝光與互動，而是更深層的信任建立。

當時機成熟，對方的情感與認同都到位之後，才會來到A4，也就是正式轉化的階段。就像表白成功、確認關係一樣，這不是一開始硬推就能得到的結果，而是前面每一步累積之後的自然發生。

而A5則是更長期的關係經營。當彼此建立穩定連結、持續互信，甚至在你需要的時候，對方也願意主動支持你，這就不只是一次交易，而是一段成熟且有黏性的關係。對應到使用者運營，就是從轉化走向忠誠、認同與主動擴散。

這段比喻提醒我們，自媒體與行銷的對象並不是冰冷的流量數字，而是螢幕另一端一個真實的人。當手機隔絕了很多情感交流時，我們更容易忽略對方的感受，誤以為只要一直說自己多好，對方就會買單。

因此，更好的做法是先預設對方是冷漠的、陌生的、無感的，再依照關係發展的節奏去溝通。不要在A1的時候說A5的話，也不要在還沒建立信任前，就急著要求對方做出承諾。真正有效的使用者運營，本質上就是尊重關係建立的順序。

[AI 分享] 用 Codex /goal 理解 Agent 核心

 [AI 分享] 用 Codex /goal 理解 Agent 核心

摘要：Codex 的 /goal 模式是理解 Agent 的好入口，涵蓋目標、狀態、工具、驗證、預算與停止條件。

內容:

很多人學 Agent 時，會先接觸規劃、多智慧體、工具呼叫、長期記憶、自動化與工作流等大概念。這些當然重要，但如果想真正理解 Agent 為什麼能持續做事，而不只是回答一句話，Codex 的 /goal 模式其實是一個非常適合的切入點。它不會複雜到難以理解，卻剛好包含了 Agent 系統中最關鍵的幾個元素：目標、狀態、工具、驗證、預算與停止條件。

從表層使用來看，平常給 Codex 一個 prompt，它通常只會處理一輪，可能讀檔、改程式、跑命令、看錯誤後回傳結果。若任務很短，這樣就足夠；但當任務拉長，例如專案遷移、修複雜 bug、效能優化或補齊測試時，就不可能靠一輪完成。這類任務常常要經過多個檢查點：先重現問題、再定位原因、接著修改、執行測試、修正新錯誤，最後再驗證結果。沒有 /goal mode 時，人往往得一直守在旁邊，反覆下「繼續」指令；而 /goal 的作用，就是把這個持續推進的意圖，變成一個可持久追蹤的任務目標。

/goal 模式最重要的概念，不只是「長任務」，而是「可驗證的停止條件」。這也是許多人學 Agent 時最容易忽略的一點。很多人以為 Agent 的核心在於會拆步驟，但真正困難的是：系統怎麼知道自己什麼時候做完。如果沒有清楚的完成定義，它就只會不停生成看似合理的下一步，卻無法真正結束。因此，/goal 的本質不是讓模型更努力，而是給模型一個能反覆檢查的完成標準。

例如，若目標是把專案從 JavaScript 遷移到 TypeScript，並要求 Strict Mode 編譯通過、不保留明顯 Any、關鍵路徑測試全數通過，這就是一個明確且可驗證的 /goal。相較之下，「幫我把專案優化一下」就過於模糊，沒有範圍、驗收方式與停止依據。當目標寫得夠清楚，Codex 每一輪都能檢查：編譯過了嗎、Any 清掉了嗎、測試跑了嗎。如果答案是否定，它就不應宣告完成。這也說明 Agent 的第一層核心，就是目標必須可驗證。

更深入來看，/goal 並不是只存在對話上下文中的一段文字。從原始碼可見，它會被寫入獨立的 SQLite 狀態資料庫中，並以執行緒 ID 對應任務資料，包含目標文本、狀態、Token 預算、已消耗 Token、已用時間、建立時間與更新時間等欄位。這代表 /goal 不是單純依賴模型記住你的需求，而是作為一個真正存在於系統外部的任務狀態。上下文可能被截斷、壓縮或摘要，但外部狀態表能明確保存任務目前進展、資源消耗與是否結束。這正是 Agent 的第二層重點：長任務不能只靠上下文，必須有外部狀態。

再往下看工具邊界設計，原始碼中可見幾個和 /goal 相關的工具，例如 Get/goalal、Create/goalal 與 Update/goalal。Get/goalal 用來查看當前目標與資源使用情況；Create/goalal 用來建立新目標，但不能隨意覆蓋尚未完成的任務；Update/goalal 則更關鍵，模型能更新的狀態很有限，主要只是在「完成」或「阻塞」之間做判定。至於暫停、恢復、清空、預算限制與用量限制，則由宿主系統控制，而不是交給模型自由決定。這反映出很典型的 Agent 設計原則：模型負責推進與判斷，系統負責保存狀態、控管邊界與限制資源。這也是 Agent 的第三層重點：工具要能行動，但權限必須收口。

/goal 最像 Agent 的地方，在於它的自動續跑機制。當執行緒進入 Idle 狀態時，系統會檢查是否存在 Active /goalal；若有，就會讀取該目標，生成一個 continuation 的執行項，並將它重新注入執行流程，啟動下一輪工作。所以，我們看到的「它自己繼續做」，並不是模型突然產生了自我驅動，而是執行時系統在空閒邊界做了一次排程決策。這一點非常重要，因為它把 Agent 從神祕化的想像，拉回工程實作的本質：它更像是一個有目標、有狀態、有觸發條件、能決定下一步的狀態機。這就是 Agent 的第四層：持續性來自執行時排程，而不是來自模型的主觀意志。

在資源管理與停止條件上，/goal 的設計也很值得借鏡。它不是單純讓模型一直跑，而是會記錄 Token 與時間消耗，甚至在 Token 計算上，還會扣除快取輸入，避免重複計算成本。這背後反映的是一個非常現實的系統設計問題：長任務必須有成本視角。若一個 Agent 能長時間自動執行，卻不知道自己花了多少資源，那最終只會讓自動化失控。

此外，/goal 的狀態不只包含 Active 與 Complete，還有 Paused、Blocked、Usage Limited、Budget Limited 等狀態。Paused 代表可以被人工暫停；Blocked 表示任務推進受阻；Usage Limited 與 Budget Limited 則代表達到用量或預算上限；Complete 才是真正完成。這些狀態共同說明，/goal 不是無限迴圈，而是一個有預算、有邊界、有失敗與停止條件的長任務機制。這也是 Agent 的第五層核心：不只要會開始，更要會停。很多自動化系統不好用，不是因為它不會做事，而是因為它不會停。

從實用角度來看，凡是「中間步驟多，但最後有清楚驗收標準」的任務，都很適合 /goal。像是程式碼遷移，可以定義成遷移到特定框架、頁面視覺一致、建構成功、關鍵測試通過；修 bug 可以定義為先重現問題、只修改相關模組、補回歸測試、本地測試通過並說明驗證結果；效能優化則可以要求首頁 TTI 降到指定秒數內，並以指定命令驗證，且不能犧牲核心功能；資料研究也可以要求閱讀指定資料、提取證據、給出結論與不確定點，且關鍵判斷都必須附來源。這些任務都有清楚邊界，因此很適合交給 /goal 持續推進。

相反地，有些任務就不適合 /goal。第一種是開放式、沒有完成定義的任務，例如「幫我把專案做得更好」，因為沒有 Done，系統就沒有停下來的依據。第二種是把一堆互不相關的事情塞在一起，例如一邊修登入、一邊改首頁、再重構支付、順便寫週報，這比較像待辦清單，而不是單一 /goalal。第三種則是需要頻繁人工主觀判斷的任務，例如設計風格要不要更高級、文案是否更像某個品牌、商業策略是否該轉向，這些更適合先讓系統做規劃或提出方案，再由人做決策。

整體來說，Codex 的 /goal 模式之所以是理解 Agent 的好入口，不是因為它只是多了一個更強的提示詞，而是因為它完整呈現了 Agent 系統運作的幾個核心原則：目標要可驗證、任務要有外部狀態、工具權限要受控、續跑來自系統排程、執行必須記帳且能停止。當你理解了這些，就更能明白，真正能長時間穩定運作的 Agent，不是無限循環的模型，而是一個有狀態、有邊界、有證據的系統。

[AI 分享] RAG知識庫更新機制

 [AI 分享] RAG知識庫更新機制

摘要 : 生產級RAG文件更新不應做Chunk局部替換，而應以文件為單位先刪後增，並結合雜湊、輪詢或事件驅動確保更新可靠。

內容:

在面試或實務場景中，若被問到RAG知識庫上線後文件更新怎麼處理，不能簡單回答「只更新變動的Chunk即可」。這種說法通常代表對生產級RAG的理解還不夠深入。因為文件進入知識庫之前，會先被切分成多個Chunk，再做Embedding後寫入向量庫；只要原文改動一小段，整體Chunk的邊界與數量都有可能改變，原本的第3個Chunk，更新後可能變成第3和第4個Chunk的一部分，因此很難穩定地只更新某一個Chunk。

在真實的生產環境中，更穩定可靠的做法是「先刪後增」。只要系統偵測到某篇文件被修改，就先刪除該文件在向量庫中對應的所有舊Chunk，再用新版本文件重新切分、重新Embedding，最後重新寫入向量庫。這樣雖然看起來較粗暴，但能有效避免舊內容殘留、新舊資訊混雜，導致檢索結果錯亂的問題。很多工程設計追求的不是最精細，而是最可控。

要實現這套更新機制，系統必須先能自動知道哪篇文件發生了變化。常見做法是為每篇文件計算內容雜湊值，首次入庫時記錄文件ID、內容Hash，以及對應的Chunk ID。之後系統再次掃描文件時，重新計算Hash，若Hash未變就直接跳過；若Hash改變，就表示內容有更新，觸發重新處理流程。實務上還可以先用最後修改時間做粗篩，只有修改時間變動的文件才進一步計算Hash，以降低大規模文件掃描成本。

此外，文件ID與Chunk ID之間的關聯設計一開始就要規劃好，否則之後很難準確刪除某篇文件對應的全部Chunk。常見做法有兩種：一種是直接在Chunk ID中包含文件ID，例如 product-manual-chunk-001；另一種則是在Chunk的metadata中保存 source-doc-id，方便向量庫依文件ID做批次刪除。這是知識庫可維護性的關鍵基礎設計。

文件更新的觸發方式通常分為兩類。第一類是定時輪詢，例如每小時或每天固定掃描一次資料來源，檢查哪些文件新增、修改或刪除。這種方式簡單易做，適合內部知識庫或對即時性要求不高的場景，但缺點是同步會有延遲。第二類是事件驅動，也就是當文件發生變更時，由資料來源透過 webhook、Kafka、RabbitMQ 等方式主動通知知識庫更新服務。這種模式的優勢是即時性高，適合政策更新、新聞發布、客服知識庫等需要快速同步的應用。

除了新增與修改，文件刪除也是非常重要的一環。若原始文件已下線，但向量庫內的舊Chunk沒有同步刪除，就會形成所謂的「殭屍Chunk」，導致系統仍可能檢索出過期甚至錯誤資訊。在金融、醫療、合規、法務等高風險場景，這類問題可能帶來嚴重後果。因此，RAG知識庫更新本質上就是穩定處理三件事：新增、修改、刪除，其中最需要注意的就是修改與刪除時的資料清理完整性。

至於是否需要定期全量重建知識庫，答案是可以，但不應作為日常方案。全量重建適合知識庫規模小，或遇到重大變更，例如更換Embedding模型、調整Chunk策略等，因為此時新舊向量本身已不相容，只能全面重建。若平時文件更新頻繁，仍以增量更新為主會更符合成本與效率。

如果知識庫應用在高風險、高價值場景，例如金融問答、醫療問答、企業合規系統，還可以進一步採用灰度更新策略。做法是同時保留舊版與新版知識庫，分別標記版本，例如 old 與 new。新版本完成入庫後，先用測試問題驗證品質，確認無誤後再切換線上檢索條件；若新版本異常，也能快速回退。這種方式類似軟體部署中的藍綠發布，能大幅提升更新的安全性與可控性。

總結來說，生產級RAG知識庫更新的核心，不是怎麼精細地更新某一個Chunk，而是如何可靠地感知文件變化、完整刪除舊資料，並穩定地將新資料重新寫入向量庫。這正是生產級RAG與Demo級RAG之間最本質的差別。

[AI 分享] 向量資料庫是什麼？

 [AI 分享] 向量資料庫是什麼？

摘要 : 向量資料庫能將文字、圖片與音訊轉成向量，支援語意相似搜尋，是 AI 搜尋、RAG 與推薦系統的重要基礎。

內容:

向量資料庫是一種專門用來儲存、檢索與管理向量的資料庫。這裡的向量，通常是由文字、圖片、音訊、影片等非結構化資料，經過 AI 模型轉換後所形成的數字表示。理解向量資料庫的重點，不只是它怎麼存資料，而是要先明白，為什麼 AI 需要把內容轉成數字，以及為什麼傳統資料庫不擅長處理「相似」這類問題。

傳統資料庫最擅長的是精確查詢，例如查找某個手機號碼、篩選價格大於 100 的訂單，或依時間排序最近的資料。它依賴的是明確欄位與固定條件，因此在處理「完全匹配」時非常有效率。但如果問題變成「哪篇文章和這段話意思最接近」，傳統資料庫就不容易做好。向量資料庫的價值，正是在於解決這種語意相近的搜尋需求。

所謂向量，可以理解成一組高維度的數字座標。AI 模型會把一句話、一張圖片甚至一段聲音，轉換成像 768 維或 1536 維的數值陣列。雖然人類無法直接看懂這些數字，但模型可以透過它們判斷內容彼此是否相似。例如「貓在沙發上睡覺」與「一隻小貓躺在長沙發上休息」雖然文字不同，但轉成向量後，在空間中的距離會很接近；反之，與股市大跌相關的內容距離就會很遠。

向量資料庫的核心能力，就是在大量向量中快速找出最相似的結果。這種做法稱為向量檢索或相似度搜尋，常見的計算方式包括餘弦相似度、歐式距離與點積。它不是判斷有沒有完全一樣，而是判斷「誰最像」。當資料量只有幾百筆時，逐一比對還可行；但若資料規模達到數十萬、數千萬甚至上億筆，全量比對的速度會非常慢，這時就需要向量資料庫的索引能力。

為了兼顧速度與準確度，向量資料庫通常會使用近似最近鄰搜尋，也就是 ANN。它透過特殊索引機制，快速縮小搜尋範圍，在龐大資料中找到足夠接近的候選結果。可以把它想像成在大城市裡找風格最像某間咖啡館的店家，不是每一家都實地走訪，而是先根據區域、風格、價格與客群先做初步分區，再到可能的範圍中精準比對，提升搜尋效率。

典型的向量資料庫流程大致分成四步。第一，準備原始資料，例如文件、商品描述、網頁內容、圖片素材或使用者問題。第二，使用嵌入模型將這些內容轉換成向量。第三，將向量連同原文、標題、標籤、來源等資料一起存入資料庫。第四，當使用者提出查詢時，也先把查詢轉成向量，再去資料庫中找出最相似的結果。

實際應用中，向量資料庫通常不只存向量本身，也會搭配許多原始欄位資訊，例如文章 ID、作者、分類、發布時間、商品價格與權限設定等。原因是企業場景不只是找相似內容，還會有條件篩選需求，例如只搜尋 2024 年後的文件，或僅限特定使用者有權限查看的資料。因此，向量搜尋往往需要與傳統條件過濾一起配合。

向量資料庫最常見的應用之一是語義搜尋。過去搜尋引擎高度依賴關鍵字匹配，但使用者輸入的字詞，未必與文件中的用字完全一致。比如搜尋「電腦發熱怎麼辦」，而文件標題卻寫成「筆記型電腦溫度過高處理方式」，傳統搜尋可能無法把最相關結果排在前面。透過向量資料庫，系統能理解這兩者語意接近，找出真正有幫助的內容。

第二個重要應用是 RAG，也就是檢索增強生成。大模型本身有知識截止時間，也不一定知道企業內部最新文件。RAG 的作法，是先利用向量資料庫從知識庫中找出與問題最相關的資料，再把這些內容提供給大模型生成回答。這樣模型回答時不是單純依靠記憶，而是根據檢索結果作答，因此能提高準確性與可追溯性。

第三個場景是推薦系統與個人化內容分發。使用者點擊過的商品、看過的影片、收藏過的文章，都能轉換成向量。系統再根據使用者興趣向量，找出內容特徵相近的商品或資訊。相較於只依分類推薦，向量方式能更細緻地捕捉偏好，例如辨識使用者偏好的是「極簡風黑色雙肩包」，而不只是廣泛的「包包類商品」。

第四類應用是多模態檢索，也就是圖片、音訊與影片等非文字資料的搜尋。例如上傳一張椅子的照片，找出外型相似的商品；輸入一句描述，找到符合風格的圖片素材；上傳一段旋律，搜尋相近的音樂片段。這些需求若只靠關鍵字很難完成，而向量資料庫正適合處理這類複雜特徵比對。

向量資料庫與一般資料庫並不是互相取代，而是互補關係。一般資料庫擅長管理結構化資料，例如訂單、帳戶、交易紀錄與庫存；向量資料庫則更適合處理非結構化內容的相似性搜尋。很多實際系統都會同時使用兩者，將業務資料放在關聯式資料庫中，將語意檢索資料存進向量資料庫，再透過 ID 進行關聯。

在選擇向量資料庫時，通常會評估幾個關鍵面向，包括檢索速度、找回效果、擴充能力，以及過濾與更新能力。因為真實業務中的資料不是一次匯入後就不再變動，而是會持續新增、刪除、調整權限與更新內容，所以資料庫是否能穩定支援這些操作也很重要。

常見的向量資料庫或相關方案包括 Milvus、Chroma，以及 Elasticsearch、PostgreSQL 搭配 PGVector 等擴充方式。不同產品的定位不同，有些偏向雲端服務、部署快速，有些適合開源自建、方便掌控，有些更適合原型驗證，有些則較適合大規模正式環境。選型時不應只看知名度，而要依據資料規模、查詢延遲需求、團隊維運能力與成本來判斷。

不過，向量資料庫也不是萬能。它擅長的是找出「相似」內容，但相似不一定代表正確。如果嵌入模型品質不佳，向量表示就可能失準；如果文件切分不合理，檢索到的片段也可能缺乏足夠上下文。此外，若只依靠向量相似度，沒有搭配關鍵字檢索、規則篩選或重排序機制，結果可能表面相關，卻無法真正回答問題。

文件切分是實務中非常關鍵但容易被忽略的一環。如果把整本手冊只轉成一個向量，資訊會過於混雜；如果每一句都獨立轉向量，又可能失去上下文。較常見的做法，是依段落、標題層級或固定長度切成內容區塊，同時保留來源、章節與頁碼等資訊。這樣在檢索到結果時，既能精準命中重點，也能方便回溯原文脈絡。

總結來說，向量資料庫是 AI 時代的重要資料基礎設施。它讓機器不只能做精確匹配，還能理解內容之間的語意接近程度。從語義搜尋、智慧客服、RAG 知識庫到多模態推薦，向量資料庫正逐漸成為連結非結構化資料與 AI 應用的關鍵核心。