企業知識庫．系列講座 - 他交接了十五頁文件卻帶走了三年的答案
企業知識庫．系列講座 - 當場答不出來的那一句就是丟單的那一句
企業知識庫．系列講座 - 當新人第一天就能答出資深工程師的答案
這裡是智庫引擎，專為企業設計的知識庫。本集要談一個幾乎每家公司都會遇到的問題：公司最值錢的經驗，其實沒有存在公司裡。畫面上這個漏斗，就是這一集的主題。上面倒進去的是散落的檔案、錄音、對話紀錄；中間經過一層一層的過濾；最下面出來的，是一顆一顆乾淨、而且查得到的知識。我們要做的不是把檔案盲目丟進 AI，而是把企業累積的實戰經驗，提煉成一座問得到、信得過、絕不外洩的知識引擎。接下來十分鐘，我們從一通凌晨三點的電話說起。
企業知識庫．系列講座 - 他交接了十五頁文件卻帶走了三年的答案
企業知識庫．系列講座 - 當場答不出來的那一句就是丟單的那一句
企業知識庫．系列講座 - 當新人第一天就能答出資深工程師的答案
這裡是智庫引擎，專為企業設計的知識庫。本集我們從一個很常見的場景說起。一位在公司待了十二年的資深主管，遞出了辭呈。他很負責。一個月預告期、三場交接會議、十五頁交接文件，專案清單、客戶窗口、系統帳號、待辦移交，全部做到位。人資核對簽名，同事在會議室切了蛋糕，流程完美結案。三個月後，公司才慢慢發現一件事：交接完成，跟知識真的留下來，其實是兩回事。那一天公司失去的，不是一個人力，而是一整座從來沒有被寫下來的知識庫。
[AI 分享] OpenAI模型調價背後的分層策略
摘要 : OpenAI大幅下調Luna與Terra價格，Sol不動，顯示其正以分層定價清洗低端市場、穩住中端競爭並鞏固高端利潤。
內容:
就在今天，OpenAI公布一份引發AI圈高度關注的調價方案。GPT5.6 Luna價格大砍80%，Terra下調20%，但旗艦款Sol則完全沒有調整。Luna的API價格降到每百萬輸入token 0.20美元、輸出token 1.20美元；Terra則維持在每百萬輸入2美元、輸出12美元的水準。同時，Terra與Luna的積分消耗也進一步降低，但ChatGPT與Codex的訂閱費用則沒有任何變化。
表面上看，這像是一場價格戰，但若深入觀察，真正關鍵並不是降價本身，而是「不對稱降價」的設計。若只是單純反擊競爭對手，理應所有模型一起降價；然而OpenAI卻選擇讓Luna大幅降價、Terra小幅調整、Sol完全不動。這種梯度式調整，反而更像是一套精心安排的市場分層策略。
Luna大降80%，幾乎已逼近推理成本極限，這不只是薄利多銷，更像是貼著成本線進行市場清場。最直接受到壓力的，會是那些原本靠低價策略搶市的開源模型與國產AI廠商。當OpenAI親自把「便宜」這張牌打到極致，其他低價競爭者的生存空間就會被快速壓縮。
Terra只下調20%，顯示OpenAI對中端市場採取的是防守型策略。Terra所面對的，是主打穩定與均衡能力的日常辦公與企業應用場景。這類客戶對價格雖有感，但未必會只因最低價而轉單，他們更重視穩定性、可用性與整體服務品質。因此，20%的降幅已足以維持競爭力，同時避免過度侵蝕自身利潤。
最值得注意的是Sol價格完全不動。這代表OpenAI在高端市場的策略非常明確：旗艦模型就是利潤核心，服務的是對能力高度敏感、對價格相對不敏感的頭部客戶。這些客戶追求的是最強性能，而不是最便宜方案，因此即使Luna再便宜，也不會自然取代Sol。Sol Max與Ultra等更高能力檔位未調整，也說明OpenAI仍在牢牢守住高階溢價空間。
從整體來看，這份調價單的本質不是單純讓利，而是透過三層價格結構打造護城河：低端用Luna清場，中端靠Terra防守，高端則由Sol持續收割利潤。這是一套非常典型但執行得極為鮮明的市場分層打法。
另一個更隱蔽的訊號是，API使用者享受到了降價，但ChatGPT與Codex訂閱用戶沒有得到價格紅利。這意味著OpenAI一方面透過低價API去吸引開發者、壓縮競爭對手生態，一方面又保住C端與SaaS訂閱業務的利潤水位。換句話說，就是同時進行「清場」與「收租」兩種操作。
後續可以觀察三個重要訊號。第一，國產大模型與其他API供應商是否跟進降價；若被迫下調，代表OpenAI的清場策略已開始產生效果。第二，開發者是否大規模從開源模型或其他低價模型轉向Luna；若Luna呼叫量明顯暴增，將是低端市場被吸走的直接證據。第三，OpenAI下一季的API收入結構變化；若Luna呼叫量增加但收入占比下降，代表其在走以量補價路線；若Sol收入占比持續提升，則表示高階利潤池正在被進一步鞏固。
綜合來看，這不只是價格戰的開始，更可能是AI模型市場分層定價走向成熟的明確訊號。未來六個月，能夠同時在低端打價格、高端拚能力的公司，才有機會真正站穩。那些卡在中間、既不夠便宜又不夠強的業者，可能會成為第一波被清洗的對象。
[AI 分享] 企業AI落地思考
摘要 : 企業AI落地仍在早期，關鍵不只技術，更在老闆親自使用、挑對客戶，以及用Agent、Skills、Data建立實用循環。
內容:
在做兩類企業AI服務：一是諮詢與培訓，協助企業學習AI工具、Agent，以及持續追蹤新工具與新趨勢；二是更接近前線部署工程師（FDE）的工作，讓企業能穩定用上頂尖模型，並把AI真正融入業務流程中，必要時也會承接Agent與工作流開發。
對目前市場有兩個明確判斷：第一，企業AI服務的缺口非常大，而且市場才剛開始；第二，市場雖大，但挑選客戶非常重要。實際接觸後，幾乎99%的公司都還沒真正落地AI，多半只停留在簡單問答階段。技術端已逐漸成熟，但企業端的認知與採納仍很初期，中間存在巨大落差，因此能同時理解技術、商業、產品與營運的人才特別稀缺。
在選擇服務對象時，主要看三點：第一，原本業務最好是數位化、知識型工作，否則落地過程會過於繁瑣；第二，行業從業者要願意接受新事物、學習與適應能力強，因為AI能力變化非常快；第三，也是最重要的，公司或行業要有預算，只有資源足夠，才更可能接受新技術並承擔相應服務成本。
在人的層面，有兩個很反直覺的觀察。第一，企業裡最常用AI的通常不是基層，而是一把手或部門負責人。因為老闆本來就有很多想法，以前受限於執行速度，現在有了Agent就像多了一個隨叫隨到的執行者，所以若老闆自己不上手，AI落地通常很難推動。第二，現階段AI更適合先擴充每個員工的能力，而不是一開始就想全面提升整個部門效率。與其追求部門整體優化，不如先打造一群能力被放大的「超級個體」。
原因在於，當前這代Agent本質上更偏向服務個人，而不是天然適合複雜的部門協作；另一方面，當AI與Agent越用越熟後，整個工作鏈條裡最慢的往往變成人與人之間的溝通。因此，更聰明的做法是盡量擴大每個人的能力邊界，減少低效、無意義的人際資訊傳遞，而不是急著改造整個組織結構。
目前總結出的落地公式是：Agent + Skills + Data。也就是讓智慧體去調用技能（認知與流程）處理資料（公司文件、記錄與資訊），再產出結果；好的結果會沉澱為未來的資料，好的過程也會沉澱成新的技能，形成持續迭代的循環。其中，Agent本身反而不是最值得企業自己投入研究的部分，直接使用市面上最成熟、最好用的工具即可；真正困難且有價值的，是後面的Skills與Data，也就是流程優化與上下文管理。
[AI 影響] Agent正改寫GPU生態護城河
摘要 : Anthropic用Claude在週末自動跑起AMD新機架，顯示AI Agent正加速跨平台部署與效能調優，鬆動CUDA生態優勢。
內容:
輝達花了20年建立的CUDA生態護城河，過去一直難以撼動，因為真正有價值的不只是編譯器或數學庫，而是多年累積下來的大量工程經驗。像是運算元如何調到最快、通訊怎麼提速、顯存怎麼分配避免爆掉，這些關鍵知識長期掌握在少數資深工程師手中，因此即使後來者硬體性能接近，也很難快速補上生態差距。
不過這個局面，可能正因AI Agent而改變。Anthropic近期分享了一個案例：AMD送來一台全新的MI355X機架後，團隊原本預期要投入大量人工進行跨平台調整，但實際上只讓一名工程師把Claude接上機器，並給出「把這台機器跑起來」這樣的目標。等到工程師週末結束回來，系統不但已經成功運作，效能曲線還持續上升。
根據Anthropic首席計算官Tom Brown在AMD大會上的說法，Claude在這個過程中幾乎是全自動完成任務，包括安裝環境、調整參數、修改程式碼與持續優化效能。連AMD原本準備提供協助的團隊，最後也確認不需要介入，因為Claude已經處理完成。
這背後的關鍵，不只是AI模型本身聰明，而是AMD正在把原本必須依賴人類工程師理解的GPU操作流程，轉換成AI Agent可以直接讀懂與呼叫的工具體系。AMD在大會上推出名為ROCmDI的平台，可以視為專門提供給AI Agent使用的GPU工具箱，並以「AMD Skills」的形式，讓Claude、Cursor、Codex等AI程式工具能直接執行裝環境、部署模型、讀取日誌與排查故障等工作。
在效能調優方面，AMD也展示了一個名為Hyperlume的系統。它會先建立基線數據，自動找出瓶頸，再嘗試不同配置、生成客製化核心程式碼、驗證結果並輸出報告。現場展示中，Hyperlume曾將MiniMax M3模型的輸出速度提升38%。AMD也表示，該系統曾跑過1.4萬個模型，且每次調優得到的結果都能沉澱為後續Agent可直接複用的經驗。
更重要的是，AMD連晶片文件的寫法都開始改變。其軟體主管表示，未來每一代AMD GPU都會公開指令集，並提供AI可以直接讀懂的ISA格式。這代表晶片說明書不再只是寫給人類工程師閱讀，而是開始變成讓AI Agent也能理解、呼叫與優化硬體的技術介面。
這件事之所以引發關注，是因為它可能改變整個GPU產業追趕生態差距的方式。過去培養一位能獨立做GPU調優的頂級工程師，往往需要數年時間；但現在若能啟動多個Agent，就能平行排錯、找瓶頸、做優化，而且其中一個Agent累積的經驗，幾乎可以立刻共享給其他Agent。原本需要按年累積的追趕過程，正被壓縮成按任務推進。
因此，Anthropic這次的週末實驗，某種程度上不只是一次成功案例，更像是一種新模式的開場。就在同一天，Anthropic也宣布將在AMD Helios系統中部署最高2GW的Instinct GPU，首批預計於明年上半年啟動。同時，AMD承諾對Anthropic投資最多50億美元，雙方還將進一步利用Claude來優化AMD的工作負載，加速ROCm軟體開發。
這形成了一個過去少見的新循環：晶片公司投資AI公司，AI公司再反過來協助晶片公司優化自己的軟體生態。從技術角度來看，最值得記住的一點是，未來晶片公司爭取的開發者，不再只有人類工程師，還包括AI Agent。
這已經不是遙遠的概念，而是正在發生的轉變。當越來越多底層工程經驗被整理成Agent可以調用的能力後，原本被視為難以跨越的生態護城河，可能會開始出現新的突破方式。下次再聽到有公司想挑戰輝達時，也許不能只用過去的標準來判斷，因為背後可能早已有一群Agent在持續加速追趕。
[AI 分享] Graph RAG讓知識庫更聰明
摘要 : 傳統RAG常把零散投訴直接拼貼成答案，難以做推理與總結；結合知識圖譜的Graph RAG可提升分析與結論品質。
內容:
當公司上線一套RAG知識庫後，大家通常會期待它能像聰明的分析助手一樣，從大量資料中整理出真正有價值的結論。但實際上，若直接拿所有客戶投訴去問「三個最根本的系統性問題是什麼」，傳統RAG很可能只會把客戶A、客戶B、客戶C各自說了什麼逐條列出，最後再補一句「總結完了」。這種結果本質上更像是複製貼上，停留在現象整理，還無法上升到系統性問題的歸納。
這也正是傳統RAG常見的短板：它擅長把相關片段找出來，卻不一定能真正理解片段之間的關聯，更不一定能完成深層推理與總結。因此，當問題從「某個人叫什麼名字」這類簡單查詢，升級成「產品與競品相比有何優劣」或「從投訴中總結根本原因」這類複雜分析時，效果往往就不理想。
傳統RAG的核心流程大致分成三個階段。第一是索引階段，也就是先把原始文件切成較小的文本塊，再透過embedding模型把文本轉成向量，最後存入向量資料庫。第二是檢索階段，當使用者提出問題時，系統會把問題也轉成向量，並在向量資料庫中尋找語義最相近的幾段內容，通常取Top K個文本塊作為參考資料。第三是生成階段，把問題與檢索出的片段一併交給大語言模型，讓模型根據這些上下文產生答案。
這種方法的優勢很明顯：它能有效補足大語言模型知識更新不即時的問題，也能降低模型憑空猜測、一本正經胡說八道的情況。不過，這個前提通常是問題本身相對直接、答案可以從少數片段中取得。若問題需要跨文件、跨段落整合資訊，甚至進一步推理與歸納，傳統RAG就會遭遇明顯限制。
其中第一個限制是多跳推理困難。很多複雜問題的答案並不直接存在於某一段文件裡，而是必須綜合多個片段後才能得出。例如某段歷史為何引發重大事件，或某產品為何持續收到某類抱怨，這些都需要模型跨多個資訊點建立邏輯鏈。傳統RAG通常只能抓到局部相似內容，卻難以把分散資訊串成完整推理脈絡。
第二個限制是關係資訊缺失。因為文本被切成獨立片段後，片段中的人物、事件、概念彼此之間的隱含關係，往往就被打散了。換句話說，系統知道某些內容出現過，卻不一定知道它們之間到底是什麼關係，因此難以形成更高層次的理解。
第三個限制是上下文冗長、重點被稀釋。檢索出來的文本塊通常不只包含關鍵資訊，也夾帶大量與問題無直接關聯的內容。這不僅浪費模型的Token資源，也可能讓模型在過長的上下文中忽略真正重要的訊息，出現所謂「大海撈針」效應，最終使答案不夠準確。
為了解決這些問題，引入知識圖譜就成了提升RAG智慧程度的重要方法。知識圖譜的價值，在於它能把原本非結構化的文本，轉化成結構化的知識表示，例如以「實體—關係—實體」這類三元組來描述知識之間的關聯。透過這種方式，原本只是散落在各段文字中的資訊，可以被整理成一張能清楚表達關係的知識網路。
也因此，結合知識圖譜的Graph RAG，不只是把資料找出來而已，而是更進一步幫助系統理解知識之間的連結，提升推理、歸納與總結能力。對於像「從所有客戶投訴中找出三個最根本的系統性問題」這類高階分析任務，這種方法比傳統RAG更有機會產出真正可用、可向老闆交代的結論，而不是只停留在表層現象的堆疊。
[AI 分享] Google AI課程重點整理
摘要 : 聚焦MCP、Skill與多Agent協作，說明AI進入真實工作場景時的串接、測試與安全重點。
內容:
Google AI 課程 Day 1 的核心：Agent = Model + Harness。也就是 AI Agent 的能力，不只取決於模型本身，還取決於你為它打造的工作環境。當 AI 要進入真實工作場景，通常會遇到三個瓶頸：碰不到私有資料、單一 Agent 能力有限，以及記不住公司的流程與 SOP。這次內容主要延伸 Day 2 與 Day 3，分別對應 MCP、A2A 與 Skill 落地的關鍵觀念。
Day 2 第一個重點是 MCP（Model Context Protocol）。它是由 Anthropic 提出的開源標準，目的不是取代像 Gmail API 這類底層服務，而是統一 AI 工具如何連接外部工具。你可以把它想成 AI 世界的通用插座，讓不同模型或平台都能用一致方式操作信箱、資料庫、設計工具等外部資源。以前每個 AI 工具都要各自接各自的程式，現在只要支援 MCP，就能共用同一套工具串接方式，讓 AI 真正碰得到工作資料與常用 App。
MCP 的價值很大，但也伴隨風險。文中特別提醒三點安全原則：第一，不要安裝來路不明的 MCP Server，否則等於把系統控制權交給陌生程式；第二，不要把 API Key、密碼直接貼給 AI，應改用本地環境變數或設定檔保存；第三，剛開始使用新 MCP 時，權限應先設為唯讀，避免 AI 因誤判操作而改動甚至刪除重要資料。若想開始使用，可以先盤點自己最常用的 App，再搜尋是否有官方或維護良好的 MCP 專案。
接著談到單一 AI Agent 的極限。當任務複雜度提高，如果把所有指令一次塞給 AI，很容易讓 context window 爆掉，導致判斷力下降。較好的做法是把工作指示拆成一份份 Skill markdown，在真正需要時才載入，這種方式稱為 progressive disclosure（漸進式介入）。但 Skill 一旦要進入正式環境，就不能再用「只是寫 prompt」的心態看待，而要當成軟體功能來設計、測試與維護。
文中整理了 Skill 上線常見的四大問題。第一是 Trigger Failure，description 寫得不清楚，導致該觸發時沒觸發，不該觸發時卻亂入；第二是 Token Budget Failure，把太多內容塞進單一 Skill，導致 AI 記憶空間被占滿；第三是 Execution Failure，雖然 Skill 被正確叫出，但執行過程或工具呼叫順序出錯；第四是 Regression，新 Skill 上線後與舊 Skill 邊界重疊，反而破壞既有系統穩定性。因此 Skill 不只要看最終結果對不對，也要檢查中間的工具使用軌跡是否正確。
為了降低這些風險，Google 提出評估驅動開發的概念，把評估案例當成單元測試來設計。也就是先定義不同情境下的輸入、應使用的工具，以及預期輸出，再開始寫 Skill。之後每次修改都必須重新跑這些案例，未通過就不能上線。當 Skill 越來越複雜，還要建立 Golden Dataset，蒐集大量經典情境與標準答案，讓整體系統能持續驗證穩定性。整體來看，這套方法的重點不是把 AI 當魔法，而是把它當成需要工程化、標準化與安全治理的基礎設施。
[AI 影響] Bun用AI在11天內完成Rust重寫的啟示
摘要 : Bun以AI協作流程在11天內將53萬行Zig重寫為Rust，效能提升且更安全。
內容:
最近開源社群出現一個很受矚目的案例：JavaScript工具 Bun，將原本53萬行的 Zig 程式碼，在11天內重寫成超過100萬行的 Rust 程式碼。Bun本身是很流行的 JavaScript 執行與開發工具，能處理執行、安裝依賴、打包與編譯，每月下載量超過2000萬次。這種規模的重寫，過去通常需要一個小團隊投入約一年的時間。
這件事特別值得注意，不只是因為速度快，更因為它證明了大型程式碼庫的重構，未來可以在AI協助下變得可行。過去多數人即使會用AI寫功能，也很少接觸幾十萬、幾百萬行程式碼的重構，因為時間與成本太高；而 Bun 這次提供了一個實際樣本。
在重寫策略上，作者沒有選擇增量替換，而是採取一次性全量重寫。原因是增量重寫雖然看似穩妥，但在中短期內會造成雙語言或雙系統並存，維護成本反而更高。此外，這次重寫並不是先大幅改造設計，而是先盡量保持原有邏輯不變，將 Zig 程式碼直接翻譯為 Rust，等到正式上線後再逐步調整成更符合 Rust 習慣的寫法。
真正關鍵的，是作者採用了 loop engineering 的方式：先明確任務邊界，再讓 AI 在邊界內反覆循環執行。整個流程分成寫程式碼、評審程式碼、修復問題三個環節，並以約50個並行工作流持續跑了11天。作者主要負責監控流程，若發現問題，就去修改整個 loop，而不是手動修某一段程式碼，因為調整流程才能避免後續任務重複犯同樣錯誤。
在品質控制上，作者用了對抗式評審：讓獨立上下文中的另一個 AI 專門審查剛產生的程式碼，且預設立場是「這段程式碼可能是錯的，請找出問題」。這種做法模仿人類工程中的程式碼評審機制，讓實作者與評審者角色分離，避免同一個模型在同一脈絡裡傾向為自己辯護。這也帶來實務啟發：AI寫完程式碼後，應另外開新上下文，只提供改動內容，要求它從反方角度找錯，往往比自我檢查更有效。
最終結果是，Rust版本不僅通過全部測試，還帶來記憶體安全，從根本上減少 use-after-free 這類問題。作者形容這次上線是「boring is good」—— Rust版安靜、穩定地上線，幾乎沒人察覺。這個案例也說明，當多個 AI agent 能持續並行工作時，人的角色並沒有消失，而是從親自寫程式轉向設計、監控與優化整個系統流程；這或許正是 loop engineering 真正的價值。
[AI 分享] 反向提問讓AI變身戰略顧問
摘要 : 與其直接向AI要答案，不如讓AI主動提問，幫助理清思路並制定可落地行動方案。
內容:
最近有一個相當顛覆的研究觀點指出，直接向AI提問，未必是最高效的使用方式。相比一味追著AI要答案，更有效的方法可能是反過來操作，讓AI主動向人提問。
這種方式的核心在於角色互換。當一個人腦中資訊混亂、暫時沒有方向，或還沒釐清真正問題時，可以先給AI一段明確指令，讓它不再只是被動回答的工具，而是切換成主動引導的「專屬戰略顧問」。
在這個模式下，AI不再等著使用者發問，而是主導對話節奏，透過連續、高質量且有穿透力的提問，逐步協助使用者摸清現狀、拆解問題、找出關鍵線索。這樣的過程能有效啟動思考，將原本零散混亂的資訊重新整理清楚。
最終，AI不只是提供片段答案，而是能陪著使用者一步一步梳理思路，並共同形成一份具體、詳細且能實際落地的行動規劃。
簡單來說，這段提示詞的價值在於，能讓AI從被動回答模式，快速切換成主動拆解問題的專業顧問模式，特別適合在思路卡住、需要釐清方向時使用。
[AI 分享] 差異化定位
摘要 : 同質化市場中，品牌可透過競品分析、需求挖掘與心智標籤建立清晰差異化定位。
內容:
在產品功能與價格都相差不大的市場裡，差異化定位的核心，是讓品牌在使用者心中佔據一個清晰且有辨識度的位置。這種差異不是品牌自認為的不同，而是使用者能明確感知、理解，並願意為之付費的價值主張，也就是給使用者一個選擇你的明確理由。
判斷差異化定位是否有效，可看三個標準：第一，使用者能一眼看懂，並在實際使用中感受到；第二，和競品有明顯區隔，且不容易被快速複製；第三，能吸引願意付費的目標使用者，支撐長期經營。若只是做些表面功能微調、但使用者無感，就是典型的「自嗨式差異化」。
真正有效的做法，通常是從使用者真實需求出發，聚焦特定人群或場景，透過持續迭代的價值主張建立認知。許多成功品牌，往往不是什麼都做，而是專注解決某一類人、某一個場景中的關鍵問題，因此更容易被記住，也更容易形成共鳴。
在實操上，做差異化之前要先分清競爭對手，包括直接競品、間接競品、替代品類與潛在進入者。可透過表格動態整理競品清單，並結合行業報告、公開資料、使用者訪談、論壇社群討論與流量工具觀察，逐步建立競品畫像、競爭力雷達圖與差異化機會矩陣，看清市場空白與痛點。
進一步對標競品時，可以從產品功能、使用者體驗、技術能力與真實使用場景等層面拆解，找出哪些需求是使用者在意、但市場還沒做好或沒人深挖的。很多突破口，往往就藏在那些未被滿足的小需求裡，最後再回到自身優勢，提煉出具創新性的定位方向。
差異化定位落地的關鍵，是搶佔使用者心智：先評估自身市場位置與優劣勢，再挖掘未被滿足的需求空白，最後用極簡清晰的標籤去佔位，並持續在產品、傳播與服務中反覆強化。若再搭配STP模型、價值曲線、使用者分層與痛點分析等工具，並依市場回饋持續調整，品牌才能真正建立長期且穩固的認知壁壘。
