2026年6月30日 星期二

[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 的評估更完整,也更接近實際生產需求。

2026年6月29日 星期一

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

2026年6月28日 星期日

痛點營銷的成交關鍵

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

2026年6月27日 星期六

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

 [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之間最本質的差別。

2026年6月26日 星期五

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

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

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




內容:

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

2026年6月25日 星期四

[AI 分享] RAG準確率提升關鍵四步

 [AI 分享] RAG準確率提升關鍵四步

摘要 : 透過切分、Query改寫、混合檢索與指標拆解,將RAG準確率從60%提升到85%。




內容:

RAG系統若想把準確率從60%提升到85%,關鍵不在單點微調,而在整條鏈路的核心最佳化。最先要處理的是資料切分,這也是整體投入產出比最高的一步。


很多人會直接用固定token數切分文件,例如每500個token切一段。這種方式雖然簡單,但很容易把完整知識點、表格內容或因果邏輯硬生生切斷,導致檢索回來的內容零碎不完整,模型看不到足夠上下文,自然難以回答正確。


更適合落地的做法,是採用NLP語義感知的動態切分,搭配10%到20%的重疊視窗。透過分句模型與文件結構解析,確保句子、標題、段落的語義完整性,同時保留上下片段銜接區,避免語意斷層。光是這一步,就有機會比固定切分方式提升約15個百分點。


第二個常見問題出現在使用者Query處理。真實場景中,使用者常常只輸入極短的問題,例如「怎麼退費」或「開票規則」,這類問題語意模糊,直接檢索很難命中正確內容。


常見解法是用小模型做Query擴寫,補出更完整的問句再進行檢索。不過這裡風險很大,若擴寫模型產生幻覺,把原本「怎麼退費」改成「怎麼收費」,就會把整個檢索方向帶偏。因此必須加入語義相似度校驗機制,利用嵌入模型檢查改寫後問句與原問句的相似度,通常低於0.8就應直接捨棄,避免系統自己引入噪聲。


第三步是混合檢索與重排序。實務上不能只靠向量檢索,也不能只靠BM25關鍵詞檢索,兩者要一起使用。但問題在於兩種檢索方式的分數尺度不同,向量分數可能落在0到1之間,BM25卻可能是十幾甚至幾十,無法直接相加比較。


工業界較成熟的方式,是引入LambdaMART這類排序學習模型,將多路檢索特徵映射到同一套排序維度,不再憑經驗手動調權重,而是讓模型學習更合理的排序邏輯,提升混合檢索的穩定性與效果。


最後,最佳化不能只看整體準確率,還必須拆解指標,才能知道問題到底出在哪個環節。最核心的兩個指標是Context Recall與Faithfulness。


Context Recall用來判斷使用者問題的正確答案,是否真的出現在檢索回來的內容片段中。如果答案根本沒被召回,表示問題出在切分或檢索策略,應回頭調整檢索環節。


Faithfulness則是用來衡量生成內容是否忠於檢索資料,也就是常說的幻覺率。若檢索內容明明提供的是A,模型卻回答成B,就代表生成階段有問題,需要重新調整Prompt或生成策略。


整體來看,RAG系統要穩定升級成工業級產品,可以記住四個重點:切分不要一刀切,要做動態語義切分;Query改寫不能偏離原意,要加相似度校驗;混合檢索不要手動拍腦袋定權重,要靠排序學習模型統一最佳化;評估不要只看總準確率,必須拆成召回與忠實度來監控。把這四步做扎實,RAG才有機會從展示型Demo真正走向可承受線上流量的實戰系統。

[AI 產業衝擊] 企業AI從工具走向數字員工

[AI 產業衝擊] 企業AI從工具走向數字員工

摘要 : Anthropic讓AI直接進入企業工作流,從輔助工具升級為可執行任務的數字同事,重塑SaaS與組織效率邏輯。




內容:


Anthropic這波更新釋出了一個非常關鍵的商業訊號:企業AI正在從「回答問題的工具」,轉向「能直接工作的數字員工」。文中提到的 Claude Tag,不再要求員工另外開網頁、整理提示詞或重建上下文,而是直接進入團隊原本就在使用的溝通平台,例如 Slack,成為群組中的一個正式成員。


它最大的突破,在於具備環境感知能力。當團隊成員在群組中 @Claude 時,它能直接理解專案過去的對話、文件、決策脈絡與目前卡點,不需要人再額外花時間整理背景資料。這解決了過去企業導入AI時最痛的問題:互動成本太高、上下文缺失太嚴重。


在實際業務場景中,這種能力的影響很大。像是銷售反映客戶急需某個功能,過去往往要經過銷售、產品、研發多層傳遞與排程;現在 Claude 可以在群裡直接理解需求、掌握優先順序,甚至進一步連到程式碼庫進行修改與部署。依文中描述,Anthropic 內部已有高達 65% 的產品程式碼合併請求,是由 Claude 自動開啟並完成初步部署,顯示AI已不只是建議者,而是執行者。


更深層的變化在於權限系統。Claude Tag 不是外部顧問型AI,而是擁有自己帳號、自己權限配置的數字分身。它可以依不同群組、不同團隊獲得特定資料與操作能力,例如在法務群中查看合約條款,在研發群中讀寫程式碼庫,但彼此之間嚴格隔離、不可越權。這種設計一方面回應企業最在意的資料安全問題,另一方面也讓所有操作都有完整日誌可追蹤,強化信任基礎。


這代表企業級AI的價值正在被重新定義。過去SaaS賣的是流程數位化工具,例如表單、審批流、資料庫;現在賣的則更像是直接的勞動力產出。AI不只是協助員工使用軟體,而是開始反過來推動工作進度、承接跨部門任務。從這個角度看,AI已經不只是軟體功能升級,而是在重構企業組織的分工方式。


除了 Claude Tag,文中也提到 Claude Design 2.0 的升級,進一步將設計與開發整合起來。這次一個關鍵改變是,Claude Design 與 Claude Code 的額度與帳單打通,讓它從原本偏展示性質的功能,變成能計算投資報酬率的正式生產工具。對企業來說,這不只是功能整合,更是採購邏輯的改變:不需要為設計與開發分別採買不同AI系統,而是用同一套能力覆蓋更多場景。


在工作流層面,Claude Design 2.0 強調所見即所得與跨工具整合。透過 MCP 連結器,使用者可以把第三方工具接進設計流程中,例如在製作簡報時直接呼叫外部模型生成封面圖片,並無縫放進頁面。這打破了過去軟體之間的孤島,讓設計過程不再需要反覆切換工具與搬運素材。


另一個重要能力是設計規範同步。大型企業通常有嚴格的品牌視覺規範,因此不太敢直接採用AI生成前端介面。這次更新讓企業可以先在程式碼端設定好設計規範,再同步到設計介面,之後生成的按鈕、頁面與儀表板都會遵循既定品牌語言。這直接降低了AI設計產出與企業品牌不一致的風險。


更進一步,設計與開發之間的交接也被大幅壓縮。當設計師完成畫板上的視覺配置後,可以直接把前端資料傳回程式碼環境,讓系統接上真實資料庫、建立定時更新任務,形成從草圖、介面、程式碼到即時資料面板的完整閉環。傳統上設計師交稿給工程師、工程師再接資料的流程,在這裡被大幅簡化甚至消除。


把這些能力串起來看,Anthropic 顯然不是在做單點工具,而是在打造一個整合式超級工作台。無論是溝通、設計、程式開發還是文件與簡報,最終都被拉進同一個工作環境,由統一的邏輯、記憶與算力驅動。這意味著未來企業需要的可能不再是一堆分散的軟體,而是一個能理解業務、能執行任務、能跨部門協作的數位操作系統。


文中也強調,這場變化對企業組織架構的衝擊很可能比表面看到的更大。當AI可以處理大量基礎開發、跨部門溝通、需求轉譯與文件維護工作時,許多依附於資訊差、轉述、彙報與協調的中間角色,存在價值將被快速壓縮。這不只是工具替代人力,而是企業內部資訊流與權力分配方式的重組。


從商業競爭角度看,真正的核心不只是模型能力,而是誰能成為企業的數位化入口。當設計資產、程式碼、文件、溝通與決策都沉澱在同一個AI生態中,企業對這套系統的依賴度就會非常高,轉換成本也會變得極大。這種黏性與生態深度,才是比單一功能更可怕的護城河。


總結來說,這篇內容的核心觀點是:企業AI的競爭,已經從「誰比較會聊天、誰提示詞寫得好」,轉向「誰能真正進入工作現場,接手任務、理解業務、產出結果」。Anthropic 這次展示的不是單一功能升級,而是企業軟體邏輯、SaaS估值方式、組織分工模式與生產力定義的一次整體翻轉。

[AI 影響] 谷歌 Interactions API 改寫 AI 應用開發生態

 [AI 影響] 谷歌 Interactions API 改寫 AI 應用開發生態

摘要 : 谷歌將 Interactions API 全面可用化,透過原生記憶、長週期任務與工具整合,大幅降低 Agent 開發與商業落地門檻。




內容:


谷歌近日低調將 Interactions API 推向全面可用階段。這不只是一次 API 名稱或版本的更新,而是代表 AI 應用開發的核心路線,正從單純的大模型對話,轉向原生 Agent 驅動的應用架構。換句話說,開發者不再只是「和模型聊天」,而是能透過 API 直接驅動 Agent 執行更複雜、更接近實際業務的工作。


過去幾年,各家大模型公司持續競逐模型能力、推理表現與榜單成績,但開發者真正面臨的難題,往往不是模型夠不夠聰明,而是如何用低成本、穩定的方式把模型接進真實業務流程。為了讓模型具備記憶、讀取私有資料、呼叫內部系統與工具,開發者往往需要依賴大量外部框架與自行拼裝的程式碼,導致整體系統脆弱、維護成本高,稍微複雜的多輪互動或高併發場景就可能失效。


谷歌這次的核心動作,是把原本最繁雜、最不穩定的 Agent 基礎能力,直接下沉到基礎設施層。Interactions API 提供統一的底層呼叫方式,讓開發者不必在基礎模型與複雜 Agent 之間切換不同端點或學兩套開發模式。實作上,只要調整請求參數,就能從一般模型呼叫切換到具備長程推理能力的 Agent,甚至也能接入企業自定義、私有化部署的 Agent。這代表的不是單純少寫一些程式,而是整體底層架構被重新整理。


其中最關鍵的一點,是服務端狀態管理,也就是原生記憶能力。傳統無狀態 API 模式下,若要做多輪對話或長任務,客戶端每次請求都得重新附帶完整歷史紀錄。這不只浪費頻寬,也會大幅增加 Token 成本;一旦網路波動、斷線或頁面刷新,累積的上下文還可能直接消失。現在,Interactions API 直接在谷歌服務端保存互動狀態,將每次互動定義為可追蹤的物件。開發者後續只要提供歷史 ID,模型就能快速讀取先前上下文、工具呼叫紀錄與推理流程,讓客戶端明顯輕量化,也降低了大規模商業部署時的成本壓力。


這種做法實際上也反映出當前 AI 競爭已不只是模型能力之爭,更是算力、網路與基礎設施能力之爭。即使底層晶片效能持續提升,在高併發與長上下文場景下,成本依舊驚人。谷歌透過服務端原生優化上下文快取與狀態流轉,相當於在基礎設施層面替企業節流,這也是只有掌握大規模算力集群的公司才能做到的事情。


另一個極具商業價值的更新,是後台長週期執行能力。真正能創造價值的 Agent,不會只是幾秒鐘內回覆幾句文字,而可能需要花上數十分鐘甚至數小時,去撰寫深度報告、交叉比對大量資料、執行多步驟工具鏈任務。傳統長連線模式下,客戶端若長時間收不到回應,往往就會超時中斷,任務直接報廢。現在透過新的 API,開發者可在請求中指定後台執行模式,讓 Agent 在雲端脫離客戶端持續運作。即使本地程序關閉,任務仍能在伺服器端繼續完成,最後再回傳結構化結果。這讓真正重型的商業自動化場景首次具備大規模落地的基礎。


在外部工具與企業系統整合方面,Interactions API 也明顯往前推進了一步。它與模型上下文協議(MCP)深度整合,讓遠端協議伺服器能以標準工具形式直接提供給模型使用。這代表 Agent 可以在合規憑證保護下,以更低成本接入企業核心資料庫、本地私有程式環境與第三方應用系統,打通了 Agent 與真實商業數位世界的連結。對企業來說,這不只降低介接成本,也有助於統一資料安全與工具呼叫規範。


谷歌官方同時也已明確將舊版呼叫介面標示為過時。這不只是產品更新,而是一種非常強勢的戰略訊號:未來的生態核心將圍繞原生 Agent 展開。谷歌顯然希望透過 Interactions API 這套統一標準,把所有需要 Agent 能力的開發者與企業,逐步綁進自己的雲端生態系中。


對許多技術團隊而言,這正是一道現實選擇題。過去大量時間耗費在處理上下文遺失、網路抖動、狀態儲存與多工具編排上,尤其是在銀行、供應鏈、智慧客服等需要長輪次、高上下文一致性的場景,傳統無狀態 API 幾乎成了專案推進的瓶頸。現在谷歌把這些基礎問題做成原生能力,等於直接砍掉了許多原本依附在 AI 工具鏈周圍的中介層價值。


這也意味著,過去兩年大量建立在 Agent 開發框架、生態工具鏈與上下文管理方案上的公司,可能面臨巨大壓力。當原本需要靠外部框架實現的記憶管理、長週期執行、工具整合與狀態恢復,都被雲端基礎設施直接吸收後,這些工具的差異化空間將被快速壓縮。某種程度上,這像是一場針對中介軟體層的基礎設施級清場。


從更宏觀的角度看,谷歌這一步也反映出 AI 競爭正從模型參數與智商指標,轉向工程落地能力、成本控制、全球骨幹網路與分散式算力管理。若只看模型能力,谷歌未必能短期內完全壓制 OpenAI 等對手;但若把競爭拉到底層工程、雲端託管與大規模商業化運營,谷歌的優勢就會變得非常明顯。Interactions API 本質上,是把谷歌多年累積的網路工程與分散式計算能力,直接封裝成面向開發者的武器。


不少一線架構師甚至認為,未來軟體開發的邊界可能不再明確區分前端與後端,而會變成由大量透過 Interactions API 串聯起來的分散式 Agent 網路。每個 Agent 負責處理一個垂直任務節點,彼此之間的溝通、狀態流轉、工具協作與長任務調度,全部交給底層雲基建完成。在這種模式下,開發者的工作重心將更偏向權限設計、工具邊界規劃與商業流程拆解。


更深一層來看,當越來越多企業把核心業務邏輯託管到這套 API 上,谷歌未來可累積的將不只是用量,而是大量真實世界中的 Agent 協作資料,例如工具調用模式、任務失敗率、商業流程效率與長週期執行行為。這些資料將成為極高價值的隱性資產,並可能反過來強化下一代模型對商業任務與工具使用的理解能力,進一步形成生態閉環與資料飛輪。


因此,這次更新傳遞的訊號其實很清楚:AI 應用開發野蠻生長、靠套殼與淺層封裝快速融資的時代,可能正在結束。未來比拼的不只是誰有模型,而是誰能把 Agent 真正嵌入複雜商業流程,替企業節省成本、提升效率、創造實際利潤。谷歌的 Interactions API,正是在這個轉折點上,試圖成為新的底層標準。


對整個產業而言,這不只是一次產品升級,而是一場開發方式、成本結構與生態主導權的重新分配。若這套標準被廣泛接受,開發者未來要遷移平台的成本也會顯著提高,因為不只是換一把 API Key,而是整個記憶機制、工具編排、長任務管理與系統架構都可能深度綁定在谷歌雲端之上。這也正是谷歌此舉最具戰略意義的地方。

2026年6月24日 星期三

[AI 分享] MCP與Skill的區別

 [AI 分享] MCP與Skill的區別

摘要:MCP負責連接工具與外部系統,Skill負責提供知識與方法,兩者搭配可讓AI既能做事也能做好事。




內容:

MCP可以理解為AI連接外部世界的通用介面,相當於幫AI配上手和工具。當AI接上MCP之後,就能夠查詢資料庫、開啟瀏覽器操作按鈕、發送微信,或呼叫各種API。它主要擴充的是AI「能做到什麼」。


Skill則比較像是一份說明書,將一套做法、規範或專業知識整理打包,在需要時自動載入。它相當於給AI一本專業手冊,主要擴充的是AI「能把事情做得多專業」。


兩者的差別可以用一句話概括:MCP提供的是工具與連線,讓AI可以做新的事情;Skill提供的是知識與方法,讓AI可以把事情做得更正確、更完善。


從技術角度來看,MCP通常需要運行一個服務,並與外部系統連接;而Skill通常只是幾個檔案,可以按需載入,成本相對較低。


在選擇上,如果目的是讓AI連接外部資料、執行操作,就適合使用MCP;如果目的是讓AI掌握某套專業做法或工作流程,就適合使用Skill。最理想的方式是兩者結合,讓MCP提供工具,Skill負責教AI如何把工具用好。A

[AI 轉變] 程式設計師與 AI 協作的觀念翻轉

 [AI 轉變] 程式設計師與 AI 協作的觀念翻轉

摘要 : 從一開始不相信 AI 能寫程式,到實際使用後幾乎不再手寫程式碼,展現了開發工作模式的巨大轉變。




內容:


一開始,對於 AI 寫程式這件事,原本抱持非常強烈的懷疑態度。認為複雜的業務邏輯、整套系統架構,以及多年累積下來的實戰經驗,不可能輕易被 AI 取代。甚至覺得,自己十年踩坑換來的能力,不會被一個工具說替代就替代。


當時也曾簡單試用過 Copilot,但初步感受並不深刻,覺得它頂多只能補幾個變數名,像是個小玩具,離真正能參與核心開發工作還差得很遠。因此原本的判斷是,真正複雜且核心的邏輯,最後還是得靠工程師親手完成。


不過,後來實際持續接觸之後,想法開始出現變化。雖然核心邏輯的理解仍然重要,但在實際寫程式的過程中,工作方式已經逐漸轉成以「和 AI 對話,讓 AI 輸出程式碼」為主,而不是自己一行一行手寫。


回過頭來看,曾經還公開放話說完全不相信 AI,如今的態度卻變成:不是不信 AI,而是不信自己竟然還需要親手寫程式碼。這種轉變本身就帶著很強的反差與幽默感。


到了現在,如果問一天手寫多少行程式碼,答案幾乎是零行。日常工作的重心,也不再只是傳統印象中的敲程式,而更像是在工作中分享、討論,甚至到處講述程式設計師與 AI 之間的各種段子與新型態協作方式。


整體來說,這不只是對工具的重新評價,也是一種開發習慣與職能角色的變化:從質疑 AI,到依賴 AI,再到幾乎完全改變寫程式的方式。

2026年6月23日 星期二

[AI 風險提醒] Codex SSD異常寫入問題

 [AI 風險提醒] Codex SSD異常寫入問題

摘要 : Codex本地日誌疑似以Trace級別持續寫入SQLite,可能造成SSD壽命、效能與隱私風險。




內容:

近期有使用者回報,OpenAI Codex CLI 與桌面版可能出現 SSD 寫入放大問題,主因疑似來自本地診斷日誌持續以高頻率寫入 SQLite。若你最近有使用 Codex,建議先檢查本機的日誌檔案是否異常成長,避免 SSD 健康度持續受影響。


自查方式很簡單。Windows 使用者可到使用者個人目錄下的 Codex 資料夾查看 `Logs.r.sqlite`;macOS 與 Linux 使用者則到對應的 Codex 目錄檢查相同檔案。若旁邊同時看到 `WAL` 與 `SHM` 檔案屬正常情況,因為 Codex 採用 SQLite。但若發現 WAL 檔在短時間內快速變大,或只要開啟 Codex 磁碟寫入就長時間偏高,就要特別注意。


根據社群回報,這個問題已被多位使用者重現,有案例指出 21 天內寫入 37TB,也有人在 10 分鐘內寫入 7GB。對一般消費級 SSD 而言,這樣的寫入量相當可觀,可能對壽命造成實質影響。


問題核心不在於「寫日誌」本身,而是預設日誌級別疑似設為 Trace。Trace 屬於非常細緻的開發級日誌,適合除錯與深度排查,但不適合長期預設寫入本地資料庫。更麻煩的是,這部分 SQLite 日誌行為似乎不完全受 Rust Log 設定控制,因此即使用戶已將日誌等級調成 `warn`,本地 SQLite 仍可能持續寫入大量 Trace 級內容。


從已公開的資訊來看,寫入量較大的來源之一是 Responses WebSocket 的原始回應紀錄,另外還包含 OpenTelemetry 相關事件與部分底層依賴日誌。這些內容對一般使用者排查幫助有限,但若全部持久化進 SQLite,就容易形成高頻率、大體積的磁碟寫入。


除了 SSD 壽命外,這件事也牽涉效能、穩定性與隱私。首先,日誌資料庫持續膨脹後,Codex 桌面端可能會越來越慢,特別是在 WSL2 或本身磁碟壓力較高的環境中,可能出現磁碟活躍時間接近 100%。其次,若 `Logs.r.sqlite` 與 WAL 檔過大,可能導致啟動時 SQLite 連線超時,甚至讓 Codex 無法正常開啟。再者,若日誌中保存了 WebSocket 原始內容、對話資訊或任務上下文,也可能帶來本地隱私與資料治理風險。


截至 2026 年 6 月 23 日,GitHub 上已有兩個相關修正 PR 合併進主分支。其一是停止記錄每個成功的 Responses WebSocket 事件;其二是從持久化日誌中過濾高噪音目標,例如部分橋接日誌與 OpenTelemetry 映射事件。這些調整的方向都很明確,就是減少無效日誌寫入本地 SQLite。不過,PR 合併進主分支不代表你目前安裝的版本已經包含修復,因此仍需自行更新並觀察。


如果你是一般使用者,建議先做三件事。第一,立即更新 Codex 到最新版本。第二,完全退出 Codex 後,檢查 Codex 目錄中的 `Logs.r.sqlite`、`Logs.r.sqlite-wal` 與 `Logs.r.sqlite-shm` 是否異常肥大。第三,確認更新後磁碟寫入是否恢復正常。處理時建議只針對日誌檔案,不要直接刪除整個 Codex 目錄,以免誤刪設定或其他重要資料。


如果你是技術人員,或必須暫時使用尚未修復的舊版 Codex,可以考慮一些臨時措施。例如定期執行 SQLite 的 WAL checkpoint,以減少 WAL 檔長期膨脹;但這只能緩解檔案變大,無法真正解決持續寫入問題。更進一步的方式是對 Logs 表建立攔截插入的觸發器,直接阻止日誌寫入,但代價是未來若遇到問題,開發者可用的診斷資訊也會同步減少。另有人會把 Codex 放到 RAM Disk,以避免 SSD 持續被寫入,但這較偏向權宜之計,未必適合所有人。


對團隊與 IT 管理者而言,這次事件也是一個提醒。AI 程式工具不只要評估功能與產出品質,也應納入終端監控範圍,包括磁碟寫入量、日誌目錄大小與程序異常狀態。若工具涉及對話、程式碼片段或業務上下文,更應明確規範儲存位置、保留時間與清理機制,並建立簡單 SOP,讓團隊遇到卡頓或寫入異常時能快速排查與處理。


整體來看,這次 Codex SSD 寫入放大問題,本質上是預設日誌級別與持久化策略設計不當所引發。若你目前仍在使用 Codex,建議立即更新版本、檢查日誌檔案大小,並確認系統磁碟寫入是否存在異常增長。

[AI 分享] 熱門UI落地Skill實測盤點

 [AI 分享] 熱門UI落地Skill實測盤點

摘要 : 實測5款熱門UI設計Skill,涵蓋頁面生成、動效與大廠設計規範,整體表現差異明顯。




內容:

評測了市面上幾款近期很熱門的 UI 落地相關 Skill,主要從生成個人筆記管理頁面的效果、整體設計質感,以及動效與風格還原能力來做比較。


第一款是討論度很高的 Taste Design。作者直接要求它生成個人筆記管理頁面,在沒有提供參考圖的情況下,成品偏簡約清新,但整體缺乏明顯亮點,和預期相比略顯普通,因此評價偏保守,認為大致只有「NPC」水準。


第二款是 Web Design Skill,同樣在無參考圖的前提下生成頁面。它會先讓使用者選擇偏好與風格,而作者認為這類帶預設的 Skill 通常品質都不錯。實際生成結果也非常突出,整體風格高級、完成度高,和前者相比差距明顯,因此給出很高評價。


第三款是來自 X 上開發者製作的動效 Skill,主要用途是替靜態頁面補上微互動。作者先找好設計稿並透過 Figma 連結讓 ClockCode 呼叫此 Skill,生成後可看到兩類效果:首次載入時的入場動畫,以及頁面內元素的互動效果,例如圖表與數字的生長動畫、各元素的 Hover 效果。作者認為這些動效明顯提升了頁面的完整度。


第四款是由中國團隊開發的 Magic Slide。它的互動方式偏向 Keynote 式的轉場,因此整體生成效果很像 PPT。作者認為這類風格不一定最適合一般 UI 頁面,但若拿來做簡報或演示,效果應該會相當不錯,因此仍給予正面評價。


最後一款 Skill 的特色是內建全球 72 家頂級大廠的設計規範,可直接調用特定品牌風格來完成頁面設計。作者先用 Notion 風格生成個人筆記頁面,發現配色與 Emoji 語言都高度貼近原本設計,且細節處理穩定;接著再生成蘋果風格版本,結果同樣很出色,整體辨識度很高。綜合來看,作者認為這款表現最佳,屬於頂級水準,並表示之後會整理這些 Skill 的安裝地址提供給有需要的人。

[AI 分享] Claude Code 前端技能組合

 [AI 分享] Claude Code 前端技能組合

摘要 : 用 Claude Code 做前端時,先補齊設計、系統、元件與檢查五項技能,成品更完整也更不易有 AI 味。




內容:

如果你用 Claude Code 做前端,不要只讓它直接硬寫頁面。先補上幾個關鍵前端 skill,能讓整體成果更成熟、可用,也更有設計感。


第一個是 Frontend Design,主要負責視覺方向。它會先幫你定好版式、字型、配色和動效,讓做出來的頁面不再像制式模板。


第二個是 Design Taste Frontend,重點在提升設計品味。若你要做官網、落地頁或作品集,又不想成品一看就很有 AI 痕跡,這個 skill 能先把整體風格拉開。


第三個是 Tailwind Design System,適合 Tailwind 專案使用。它能把顏色、間距、元件變體與 Dark Mode 整合進同一套設計系統,讓後續開發更一致。


第四個是 ShadGUI,適合 React 加 Tailwind 的後台或 SaaS 工具站。它能讓 Claude 依照 ShadCN 的方式搭建元件,後續維護與調整也更方便。


第五個是 Frontend Design Review,頁面完成後不要急著上線,先用它檢查響應式、可訪問性、設計 Token 與元件一致性。整體順序就是先定設計、再搭系統、再做元件、最後質檢。

[AI 影響] 一人協同18個AI員工的團隊實驗

 [AI 影響] 一人協同18個AI員工的團隊實驗

摘要 : 一名工程師協同18個AI員工,完成模型訓練框架初版,效率被認為可接近傳統30人團隊。




內容:

有團隊分享,現在公司內部已經在實際探索「人類員工+AI員工」的協作模式。其中一位負責基礎設施的人員,背後同時協同18個AI員工,甚至在吃飯時也能透過手機發出文字指令,讓AI持續梳理框架、補強特性與推進任務。


這種以 agent 形式運作的協作方式,被認為效率不是單純的「1加18」,而是遠高於這個數字。公司內部評估後認為,這名員工加上18個AI員工,整體產出能力可能接近過去大廠中約30人團隊的水準。


這組「1加18」的成果,主要是完成了公司第一版的模型訓練框架。18個AI員工並非沒有分工,而是有明確角色配置:其中15個負責實作,3個擔任專案經理。15個實作型AI員工又進一步分成三組:5個做底層框架設計、5個負責模組之間的協同、5個專門撰寫程式碼。3個AI專案經理則各自管理5個AI員工,而這位人類員工主要與這3個專案經理互動,提出需求與調整方向。


在這樣的工作模式下,團隊也形成了新的能力評估標準。分享者認為,如今評估一個人的能力,已不只是看程式寫得多厲害,而是看他每天能否有效提出需求、調動多少API token,以及能否提出多樣化且具體的任務。換句話說,能同時提出框架、coding、特定技術需求的人,反而更有價值。


公司在資源配置上,對API key與code agent的使用給了相當充足的預算,甚至提到相關API成本可能已經遠高於某些單一員工的成本。這也顯示,他們是把AI視為真正的生產力單位,而不只是輔助工具。


在團隊管理上,他們也減少傳統的日會、週會機制,因為認為會議相當耗時。取而代之的是使用AI來整理所有資訊,並透過郵件自動同步每個人正在做的事情,讓團隊成員快速掌握整體進度。


此外,團隊內部還建立了共享 memory 與共享 skill 的機制。每個人每天完成的工作都會進入共享報告,如果同事之間任務重疊,還會有更高層的 agent mentor 主動提醒,指出技術路線的差異、重疊部分,並建議雙方安排會議或私下交流。也就是說,許多原本屬於中台、協調、同步的管理工作,都逐漸交由AI處理。


分享者自己也有5個專屬 agent 協助工作。其中一個用來協助閱讀論文、追蹤新架構與新的訓練方法;另外3個偏向公司技術討論;還有1個財務 agent,協助管理公司預算與財務安排。


整體而言,這段分享想表達的是:即使是學生創業、第一次創業的團隊,在大量引入AI後,也能在某種程度上補足經驗不足的問題。對他們來說,AI不只是工具,更像是一群可以被管理、分工與協同運作的「數位員工」。

[AI 影響] 納德拉重寫程式設計師工作定義

 [AI 影響] 納德拉重寫程式設計師工作定義

摘要 : AI不一定取代工程師,但會重寫其工作內容,重點將轉向管理agent、維持認知覆蓋率與承擔治理型工作。




內容:

最近微軟 CEO 納德拉在《紐約時報》Hard Fork 播客上的一場訪談,提出了幾個非常值得技術工作者重視的觀點。重點不在於他宣布了什麼驚人的新消息,而是他用幾個非常具體的概念,說清楚了許多人隱約感受到、卻一直沒有被講透的變化。


這場訪談裡,有幾句話特別關鍵。像是他提到,未來的軟體開發者可能要管理 100 個、甚至 1000 個 agent;他也提出了「認知覆蓋率」這個概念,用來對照大家熟悉的「測試覆蓋率」;另外,他還說人類在 AI 時代的新價值,是去做「膠水工作」。這些詞單看有點抽象,但串在一起之後,其實指向同一件事:我們過去一直在討論「AI 會不會取代程式設計師」,這個問題本身可能就問偏了。真正正在發生的,不是這個職業消失,而是它的工作內容正在被徹底改寫。


先說訪談背景。這場節目是在 6 月 12 日於舊金山錄製,主持人是《紐約時報》的兩位科技記者 Kevin Roose 和 Casey Newton。納德拉作為微軟 CEO,本來就是全球 AI 產業最核心的人物之一。無論是微軟與 OpenAI 的深度合作、Azure 的雲端算力地位,還是微軟自家剛推出的 MAI 系列模型,都讓微軟在這場 AI 競賽中握有相當厚實的籌碼。


但這場訪談真正有意思的地方,不是他再講一次微軟戰略,而是他回應了很多非常具體、非常落地的問題。其中一個最尖銳的提問是:兩年之後,軟體工程師會變多還是變少?


這個問題之所以敏感,是因為現在外界的爭論非常激烈。一派認為 AI 寫程式越來越強,公司未來不再需要這麼多工程師;另一派則認為 AI 反而會創造更多需求,工程師依然會供不應求。納德拉沒有簡單站隊,而是給出了一個更複雜、也更值得注意的答案:未來軟體開發者需要的技能可能和今天差不多,但工作內容會完全不同。


他用了一個很形象的類比。假如很早以前有人說,未來全世界會有 35 億人變成打字員,你一定會覺得荒謬,因為世界不需要那麼多專職打字員。但今天幾乎每個人都在打字,原因不是打字員變多了,而是打字已經不再是一種職業,而是所有知識工作與資訊工作的基礎能力。納德拉認為,軟體開發也可能走上類似的路。


換句話說,未來的開發者管理的未必是傳統意義上的程式碼庫,而是一整組 agent,可能是 100 個,也可能是 1000 個。這些 agent 可以自己執行任務、自己撰寫程式碼、自己提交修改。而人類開發者的核心工作,將從親手寫出每一行程式碼,轉向理解這些 agent 做了什麼、為什麼這樣做、哪裡可能做錯,以及出問題時誰來負責與收尾。


這個判斷的重要性,在於它不只是回答「工程師會不會失業」,而是在重新定義工程師這個職業的本質。


接下來是整場訪談中最有價值的一個概念,也就是納德拉提出的「認知覆蓋率」。


對軟體開發者來說,「測試覆蓋率」是很熟悉的概念。它代表程式碼中有多少比例被測試案例覆蓋,覆蓋率越高,通常表示關鍵邏輯驗證得越完整,出錯風險相對較低。這是過去幾十年軟體工程中非常基礎的品質指標。


但納德拉認為,當程式碼庫裡越來越多的內容是由 agent 產生時,只有測試覆蓋率已經不夠了,還需要另一個新指標,也就是認知覆蓋率。


所謂認知覆蓋率,看的不是程式碼有沒有被執行過測試,而是人類有沒有真正看懂這次修改。更具體地說,就是 agent 改了哪些地方、為什麼這麼改、這些改動會如何影響整個系統流程、有沒有突破原本的架構約束、整個決策鏈條能不能被解釋。核心問題不是「能不能跑」,而是「人有沒有理解」。


這個概念非常關鍵,因為它點出了 AI 寫程式進入深水區之後最容易被忽略的風險。現在很多團隊使用 AI 輔助開發,關心的通常還是效率提升多少、寫得快不快。但納德拉提醒的是,當 agent 寫的程式碼越來越多,甚至占了大部分時,真正棘手的問題不再只是產出速度,而是可解釋性、可審計性與可控制性。


測試通過,只能說明程式碼在某些案例中可以運作;但認知覆蓋率關心的是,團隊是否理解 agent 的決策邏輯,是否知道它有沒有繞過原本的架構設計,是否能在事故發生時回放、追責、撤銷。這已經不只是技術問題,而是治理問題。而且 AI 越快,這個治理問題只會被放大。


以前一個工程師一週可能寫幾百行程式碼,每一行自己都清楚;現在 agent 一天就可能產出幾千行甚至更多。如果團隊沒有相應的工具與方法去理解這些變更,那麼整個程式碼庫很快就可能變成一個「雖然能跑,但沒人真正懂」的黑箱。


也因此,納德拉提到未來可能出現一種新的開發環境,不再只是 IDE,而是 ADE,也就是 Agent-Driven Development Environment。這種環境的核心功能,不是單純幫你寫程式,而是協助你管理一群 agent、理解他們做了什麼,並維持認知覆蓋率。這是一個很強的訊號,代表微軟內部已經開始認真思考:當 agent 成為主要程式碼生產者之後,開發工具本身應該如何被重新設計。


和認知覆蓋率相對應的,還有另一個很耐人尋味的概念,叫做「膠水工作」。


當主持人追問,如果工作型態變了,人是不是會因此賺得更多時,納德拉沒有直接談薪資,而是說了一段更值得深思的話。他的意思是,過去兩百多年來,很多價值都建立在某種專業知識或深度技能之上。當某些專業能力因技術而變得更容易取得時,人類就會再形成新的專業能力。即使我們擁有越來越多數位系統,人力資本依然重要,而人類仍然會去承擔那些「膠水工作」。而隨著自動化增加,新的膠水工作還會繼續出現。


什麼是膠水工作?可以把它理解成那些把系統、流程、組織和判斷連接起來的工作。AI 可以處理很多標準化的任務,但組織裡真正重要的許多細節,往往沒辦法完整寫進 prompt。


如果放回開發團隊的脈絡,這個概念就很具體了。例如:業務需求怎麼判斷、介面邊界怎麼切、權限怎麼設計、風險如何承擔、跨部門衝突怎麼協調、上線後誰來解釋結果與負責,這些都屬於膠水工作。


你會發現,這些事情有一個共同點:它們不是純技術問題,而是技術與業務、技術與組織、技術與人的交界問題。這些工作很難完全標準化,也很難被單一 agent 直接取代。納德拉的判斷甚至有點反直覺:agent 越多,膠水工作不但不會消失,反而會變得更難、更貴,也更需要人來治理。


很多人覺得 AI 越強,所需的人就會越少;但納德拉的邏輯剛好相反。AI 越強,系統越複雜,越需要有人去「膠水」,因為 agent 處理的是標準化、可定義的任務,但任務與任務之間、系統與系統之間、人與系統之間,反而會出現更多縫隙。而這些縫隙,往往才是最有價值、也最需要綜合判斷的地方。


因此,如果回到最初那個問題:「程式設計師會不會失業?」納德拉的真正答案其實很清楚。這個職業不會因為 agent 的出現而立刻消失,但職業重心一定會被改寫。下一階段最稀缺的開發者,未必是最會手寫程式碼的人,而是最能看懂、管住、排程與治理 agent 的人。


除了工作型態,納德拉在訪談中也談到另一個非常實際的問題,那就是 AI 的成本。他提出了一個詞,叫做「Token Economics」,也就是 Token 經濟學。


這個詞聽起來有點抽象,但本質上很簡單:你花出去的 token,必須換回對應的價值。納德拉的說法很直接,生產力提升的邊際價值,必須配得上 token 的邊際成本,這是一種管理紀律。


他的意思是,不能為了追求所謂的 token maxing,就什麼問題都用最強模型、什麼任務都塞進最大上下文,靠無腦堆砌算力來解決一切。尤其在非核心問題上,更不應持續消耗最昂貴的模型資源。AI 工具確實很容易讓人上癮,他自己也承認會高頻使用,但新鮮感退去之後,真正重要的是回頭問:這些消耗到底有沒有產生足夠價值。


整體來看,納德拉這場訪談最值得記住的,不是哪個產品、哪個模型,而是他對未來軟體開發結構性變化的判斷。他不是在說程式設計師會被簡單取代,而是在說,當 agent 成為主要生產力之後,開發工作的重心將從「寫」轉向「管」,從「產出」轉向「理解」,從「效率」轉向「治理」。


如果這個方向成立,那麼未來真正重要的能力,會變成幾件事:能不能有效管理大量 agent、能不能維持足夠的認知覆蓋率、能不能承擔那些看似瑣碎但其實最關鍵的膠水工作,以及能不能在 AI 成本與產出之間做出有紀律的取捨。


也就是說,AI 時代不是不要工程師了,而是更需要那種能跨技術、跨業務、跨組織理解整體系統的人。這可能才是這場訪談最值得所有技術人認真聽的地方。

2026年6月22日 星期一

[AI 分享] Codex Recall & Replay

 [AI 分享] Codex Recall & Replay

摘要 : Codex 推出 Recall & Replay,可直接錄製並學會使用者操作,將示範轉成可重播的 Skill,大幅降低教 AI 自動化流程的門檻。




內容:

Codex 昨天更新了新功能 Recall & Replay。開啟後,它會錄下你在電腦上的操作,理解每一步的意圖,並自動轉化為可重複呼叫的 Skill。之後遇到相同任務,就不必再手動操作,只要讓 Codex 執行該 Skill 即可。


這是今年最強、甚至可稱為「神級」的更新,原因在於 AI 的學習方式出現了重要變化:從過去依賴人用文字描述流程,進化成直接透過示範讓 AI 學會。這大幅降低了使用門檻,因為多數人其實很難把自己的工作流程清楚語言化、結構化。


這項功能的本質,是把原本難以表達的隱性知識顯性化。使用者不再需要先整理出 SOP 或寫提示詞,只要實際操作一次,AI 就能根據錄影理解流程、判斷邏輯,並封裝成後續可複用的技能。


示範了一個實際場景:經常需要把 Ulysses 裡寫好的文章複製到 Substack,建立新文章、貼上內容、整理標題並加入訂閱按鈕,這是一個高頻且重複的工作。於是他透過 Recall & Replay 錄下整個流程,讓 Codex 自動建立對應 Skill。


第一次測試時,Codex 已能自動找到指定文章、開啟 Substack 後台、建立草稿、貼上正文並整理標題,但漏掉了文末的訂閱按鈕。作者回報後,Codex 回看先前錄影,確認自己的判斷錯誤並補上該步驟;再次執行後,整個流程便完整重現,成果也與作者原本操作一致。


最後指出,Recall & Replay 建立在兩個核心能力上:多模態理解錄影,以及 Computer Use 重現操作。這些能力單獨看並不新,但結合之後,讓 AI 能透過「看你怎麼做」來學會技能,預示未來將有更多人類工作流程被 AI 快速吸收與自動化。

[AI 衝擊] AI暗黑工廠:當軟體工程進入極速開發時代

 [AI 衝擊] AI暗黑工廠:當軟體工程進入極速開發時代

摘要 : AI大量接管寫碼後,工程師角色正從工匠轉向工廠經理,生產力暴增同時也帶來失控、重構與基礎設施新挑戰。




內容:

你印象中的程式設計師,或許還停留在那種安靜敲鍵盤、反覆推敲邏輯、謹慎測試的工匠式畫面。但這份材料描繪的,已經不是人類親手逐行寫程式的世界了。取而代之的,是大量高活躍度的 AI 智慧體同時在程式碼庫中高速產出,讓軟體工程從「手工創作」轉變成「規模化生產」的現場。


OpenCloud 的維護者 Vincent Cox,正是這種新模式的縮影。白天,他在大型企業裡遵循嚴格、結構化、安全優先的工程規範;夜晚,他則投入開源世界,依靠對測試框架的強烈信任,驅動大批 AI 在程式碼庫中高速運轉。這種反差不只是工作風格的切換,更像是兩套完全不同的工程哲學並存於同一個人身上。


最令人震撼的是這種模式所帶來的吞吐量。OpenCloud 的核心維護者其實只有約 10 到 15 人,而且大多數人都有全職工作,但專案高峰期卻能做到單日約 800 次程式碼提交。更誇張的是,Vincent 曾在 3 月 15 日創下個人單日將近 3400 次提交的紀錄。這不是透過作弊腳本灌水,而是真實大量驅動 AI 所產生的結果,甚至因此頻繁觸發 GitHub 的 API 保護機制,被平台按小時熔斷,反而成了他少數被迫停下來休息的時間。


這也揭示出所謂「暗黑工廠」模式的核心:當程式碼的主要生產者不再是人類手指,而是大模型的生成能力時,軟體工程比拚的就不再是個人的手速,而是整體生產體系的調度能力。真正的變化,不是寫得更快,而是整個生產方式被重新定義了。


Vincent 用一段早年體驗 VR 的經歷,來形容開發者面對這種 AI 洪流時的感受。2013 年,他曾無視早期 VR 頭顯「每次使用不要超過五分鐘」的警告,連續玩了三小時遊戲,最後不但劇烈暈眩、抱著馬桶狂吐,連視覺都短暫扭曲。他認為,這種生理上的反胃與失衡,和今天開發者面對幾十個 AI 同時輸出、數萬行程式碼瀑布般湧出的認知衝擊非常相似。不是因為內容不能理解,而是因為量級太大,超出了人腦即時消化的極限。


因此,開發者的角色被迫改變。過去那種逐行雕琢程式碼的浪漫工匠形象,正在被「監控整條流水線的工廠經理」所取代。這種轉變甚至可類比英國工業革命:手工織布時代,最熟練的工匠也受限於雙手速度;而進入集中式工廠後,產能的上限來自系統規模與機械協作。AI 時代的軟體工程,也正在經歷類似的結構性躍遷。


在這套模式裡,系統被拆成多個不同風險等級的「湧道」。其中第三與第四號湧道屬於深水區,負責較複雜的功能開發,例如整合與底層訊息通道機制。這部分人類無法缺席,必須與 AI 持續高頻互動、審查架構、修正偏差。AI 更像是高速起草的工程師,人類則是負責把關安全性與方向的經理。


壓力最大的則是第五號湧道,也就是專門處理 P0、P1 級高危 Bug 的急診區。這裡的 AI 會長時間潛伏在社群平台與討論頻道中,持續監聽全球使用者回報。一旦察覺崩潰徵兆,便立即整理出過去幾小時內的重大錯誤、提煉重點並給出修復建議。從這套體系可以看出,真正稀缺的已經不是 Token 成本,而是算力,以及人類注意力、腦容量與多工處理能力。


這種脆弱性,在一次被稱為「凌晨兩點大重構」的事件中徹底暴露。一位位於地球另一端、毫不知情的開源維護者,只是移動了幾個底層檔案路徑,卻瞬間導致整個通訊架構混亂甚至癱瘓。按照傳統工程思維,這種事故應該先回滾、再補丁修復。但當時疲憊不堪的團隊卻做出極度反直覺的決定:不修了,乾脆趁機把整個程式碼庫徹底重構成外掛化架構。


這個決定背後其實有明確邏輯。在 AI 時代,新增功能的成本大幅下降,真正困難的不是答應需求,而是拒絕需求。如果架構沒有物理層面的解耦,專案很快就會因特性膨脹而變成無法維護的泥潭。於是他們放開限制,讓數十個 AI 全面接手重構工作。最終,短時間內產生了約 2700 次提交,修改近千萬行程式碼,觸及核心程式碼庫約 82% 的區域,幾乎等同於把整棟大樓炸掉後原地重建。


過程中當然一度瀕臨失控。測試系統滿屏飄紅,團隊陷入強烈自我懷疑,甚至懷疑自己是否像伊卡洛斯一樣飛得太高、終將墜落。但戲劇性的轉折是,最後救回整個專案的,竟然是那些平常被資深工程師嫌棄、由 AI 過度擬合產生的糟糕單元測試。


這些測試平常被視為技術債,因為太死板,稍微改動邏輯就會報錯;但在這場毀滅式重構中,它們反而成了最原始、最可靠的生命線。只要這些老派而僵硬的測試重新變綠,就代表最底層的核心邏輯仍然是通的。換句話說,即便新房子蓋得再奇怪,只要地基和主要承重結構還能通過驗證,就還有挽回空間。


然而,真正撐起這種極速並發開發模式的,不只是流程與測試,還有底層基礎設施。Vincent 也坦言自己曾犯下一個代價巨大的判斷錯誤:他原本使用適合傳統開發的工作樹機制來管理多執行緒工作區,因為這樣能共享同一套程式碼庫、節省硬碟空間。但在暗黑工廠模式下,數十個 AI 不斷拉取與提交,導致每天累積 70 到 80 個極度活躍的工作區,最終把高規格機器也拖進記憶體溢位與系統崩潰。


相較之下,他的同事 Peter 採取了極為粗暴但有效的方法:直接把整個龐大程式碼庫完整複製多份,透過物理隔離來徹底避免工作區之間互相爭搶資源。這種看似笨拙的做法,反而更適合高並發 AI 開發的現實需求。


經歷這些慘痛教訓後,Vincent 又進一步打造出一套保命機制:一個常駐守護程序。當系統因為 AI 的瘋狂輸出而卡死、接近崩潰時,他只要按下鍵盤上的 ESC 鍵,守護程序就能立刻介入,強制熔斷失控流程,並指揮 AI 進行環境清理與狀態恢復。這相當於替整座高速運轉的暗黑工廠,加裝最後一道人工緊急煞車。


整體來看,這份內容真正想揭示的,不只是「AI 能把寫程式速度提升多少」,而是軟體工程的本質正在改變。開發者不再只是程式碼作者,而更像是調度者、審查者、熔斷者與系統經理。AI 帶來的不是單純效率提升,而是一種足以讓工程方法論、團隊協作方式、架構設計原則與基礎設施策略全面重寫的衝擊。

[AI 回顧] Token Maxing三月熱潮退場

[AI 回顧] Token Maxing三月熱潮退場

摘要 : Token Maxing從矽谷狂熱蔓延至大廠,卻在三個月內快速降溫,主因是成本失控、ROI不明、能力與組織流程脫節。




內容:

三個月前,矽谷還在流行一場名為「Token Maxing」的熱潮。當時工程師們比拼誰消耗更多 token,彷彿用得越多,就越懂 AI、越代表未來。這股風潮最早出現在 OpenAI、Anthropic 等前沿模型公司內部,後來快速擴散到整個科技圈,甚至連迪士尼、Visa 與國內大廠都加入其中。


所謂 Token Maxing,本意是「最大化使用 token 資源」,但很快被扭曲成一種身份象徵。大家開始把高 token 消耗等同於更高的 AI 掌握度與生產力。當時的氛圍甚至到了「不用 AI 就落後、不多用 AI 就是態度有問題」的程度。


但這場熱潮退得也非常快。到了五月底、六月初,亞馬遜關閉了內部 AI 使用排行榜,因為員工開始為了衝排名而讓 AI 執行沒有價值的任務。Uber 也公開質疑 token 消耗與實際業務成果之間的關聯,微軟則開始削減大量內部 Cloud Code 授權。原本無上限投入的企業,幾乎都陸續踩下煞車。


在這波調整中,各家公司也開始尋找新的衡量標準。百度提出以日活智慧體數(DAA)取代 token;Devin主張用節省的人類工時衡量;Uber希望將 token 與功能交付、ROI 掛鉤;亞馬遜則回到客戶與業務問題解決數量。但問題是,token 消耗與這些最終指標之間並沒有簡單直接的換算關係,試錯成本與效益邊界也難以界定。


微軟 CEO 納德拉後來提出「Token 資本」的概念,認為 token 使用的目的不應只是消耗,而是要沉澱成企業自己的 AI 能力資產,例如工作流、私有評測、組織知識、反饋閉環與可遷移的企業經驗。這個觀點雖然補充了部分方向,但本質上也只是把正在被工具鏈自動化的流程,重新包裝成企業資產來理解。


那麼,Token Maxing 為什麼會這麼快失敗?最直接的原因就是太貴了,企業燒不起。更深層來看,至少有三個原因。


第一,前沿模型公司的成本結構本來就不好看,尤其在 IPO 壓力下,更難維持寬鬆的使用政策。模型本身研發成本極高,商業化後毛利也未必理想,因此企業開始提高價格,或透過調整 tokenizer、計費方式來變相漲價。


第二,訂閱制被重度使用者與 agent 工具打穿了。原本包月訂閱適用於一般聊天式使用,但自動化 agent 能長時間並行工作,token 消耗遠超舊有模型。這讓廠商不得不把高強度推理成本拆出來額外收費,例如 Anthropic 與 Google 都開始調整訂閱方案與計費邏輯。


第三,從技術層面看,agent 的 token 消耗極其驚人,而且效率很低。研究指出,agent 式程式設計任務的 token 消耗大約是普通程式碼問答的 1000 倍,最大開支還不是輸出,而是模型反覆讀取上下文的輸入成本。探索、修正、測試等階段尤其消耗巨大,說明現有工具鏈為了讓模型不跑偏,必須不斷餵入上下文,代價極高。


此外,agent 真正的能力也還遠未成熟。研究顯示,在大量真實專業任務中,即使是最好的系統,最難任務的完整通過率也只有 8.6%,平均甚至只有 2.6%。而且 75% 的失敗並不是執行層面的手腳問題,而是理解與策略問題,也就是說,agent 最大的短板是缺乏真正的行業知識與專業判斷。


這意味著,AI 並不是不能做事,而是越接近真實企業場景,越依賴隱性知識、本地規則、專業流程與可驗證輸出。一個通用 skill 到企業內部往往還要二次開發,法務、財務、研發、銷售各有自己的規範與系統,越貼近業務,越難通用。


組織層面也是一大瓶頸。即使 AI 在某個上游環節真的有效,比如寫程式碼,它也未必能轉化成最終成果。因為程式碼之後還有審查、測試、整合、發布與採用等一連串流程。上游加速了,但下游沒有同步加速,最後就只會堆出更多半成品。


MIT 的研究就指出,AI 工具確實讓程式碼提交大幅增加,但這種增幅傳導到專案數與實際發布版本時,效果會明顯縮水。也就是說,「寫出更多程式碼」和「交付更多產品」完全不是一回事。更麻煩的是,AI 產生的程式碼還可能讓人類後續審查負擔更重,理解難度更高,進一步卡住人的頻寬。


除了這些大問題,還有兩種常被忽略的浪費。第一是簡單任務上的虛耗。研究顯示,像簡單算數、拼寫檢查、同義詞查詢這類小任務,很多人明明自己做更快,卻還是習慣打開 AI。結果反而花更多時間在寫提示詞、等待答案、閱讀與確認上,形成一種「效率幻覺」。


第二是重複造輪子。隨著 agent 生成內容的成本越來越低,開發者與 AI 都更傾向直接重新生成一份,而不是搜尋、理解、複用既有成果。研究發現,大量 skill 高度相似,許多 agent 提交的程式碼修復請求最終未被合併,其中相當一部分原因就是同樣的問題早已被別人解決。這說明在缺乏全局協調時,AI 很容易放大重複建設與資源浪費。


總結來看,Token Maxing 的失敗,不只是一次短期泡沫破裂,更像是 AI 產業從狂熱走向現實的過程。它暴露了兩件事:第一,現階段 agent 的能力還不足以在所有任務上穩定提效;第二,企業也還沒有建立出一套成熟的 AI 使用方法,能真正避免浪費並轉化為業務成果。


更深一層說,這其實是經濟學中「生產率悖論」的再次上演。像電力、電腦、網際網路這些通用技術,在剛出現時都曾經歷過「技術進步很快,但整體產出沒有立刻提升」的階段。因為真正的瓶頸,往往不在單一技術本身,而在與之互補的流程、制度、組織與人類能力。


所以,Token Maxing 的退潮不一定代表 AI 沒有未來。相反地,它可能只是提醒大家:AI 要真正產生價值,不能只看 token 花了多少、程式碼寫了多少,而要看它是否穿透整條價值鏈,最終轉化成可交付、可使用、可驗證的成果。

[AI 分享] AI三巨頭分道競爭,產業進入下半場

 [AI 分享] AI三巨頭分道競爭,產業進入下半場

摘要:Google拚生態、Anthropic拚深度、OpenAI拚商業化,AI競爭重心正從模型能力轉向產品與服務。




內容:


AI產業正在進入一個新的競爭階段。5月19日,Google、Anthropic、OpenAI幾乎在同一時間做出重大動作,但三家公司選擇了完全不同的方向,也象徵AI競爭正式走入下半場。


Google在當天一口氣發布28項產品與功能,企圖全面擴張AI在日常生活中的滲透率。重點包括可長時間在背景運作的AI管家「Gemini Spark」,即使手機螢幕關閉,仍可協助處理郵件、追蹤任務與安排日曆;新一代旗艦模型「Gemini 3.5 Flash」,主打更快的速度;以及可24小時監控新聞、部落格與社群媒體動態,並主動推送資訊的AI資訊代理。除此之外,還涵蓋影片生成、程式設計平台升級與智慧眼鏡等。


Google的核心戰略很明確,不只是推出單一強產品,而是藉由Gmail、地圖、搜尋、YouTube等既有生態系,打造更難被取代的AI入口。它比的不是單點模型最強,而是誰能讓使用者更離不開自己的整體服務體系。


另一方面,Anthropic則走向更聚焦、更深度的路線。當天,知名深度學習專家加入Anthropic,引發AI圈高度關注。這類頂尖人物的轉換,不只是職涯選擇,更像是在替某種技術路線投票。


Anthropic從一開始就強調兩件事:打造最好的模型,以及確保模型對人類安全。這種堅持並非口號。此前美國國防部曾要求AI供應商移除部分安全限制,允許軍方將AI應用於所有合法用途,Google與OpenAI選擇接受,但Anthropic拒絕放寬自主武器與大規模監控相關紅線,甚至因此失去高額合作機會。


Anthropic的特別之處,不只是有原則,而是把這種高標準落實到產品上。其模型與工具在長推理、深度分析與程式設計領域被不少人視為頂尖選擇。它不追求產品數量,也不急著鋪滿生態,而是專注在做出夠強、夠硬的產品,並吸引最優秀的人才。


至於OpenAI,則走出第三條路:商業化與速度。Sam Altman在同一天宣布推出1到3年的算力承諾合約,提供折扣價格,並強調市場對算力確定性的需求正在上升,未來一段時間算力緊缺可能仍會持續。同時,OpenAI也對特定創業圈提供token資源支持。


這背後代表的是,OpenAI正在把算力當成一種可預售的資源,近似「算力期貨」。邏輯很直接:趁AI需求持續暴增、算力仍然稀缺時,用長約換取客戶承諾、穩定現金流與可預期收入。


OpenAI目前的處境相對微妙。它仍然是全球最具知名度的AI品牌之一,但在模型前沿能力上,未必始終全面領先;在產品生態鋪設上,也面臨Google這類巨頭的壓力。因此它選擇更務實地把品牌、用戶規模與商業模式轉化為護城河。與其只比誰模型更聰明,不如先比誰能更快鎖定客戶、把算力變現。


這三條路之所以在此刻明顯分叉,根本原因在於AI競賽的重心變了。從2023年到2025年上半,市場比的是誰先做出GPT-4等級的模型,模型能力幾乎代表一切。但到了下一階段,頂尖模型之間的差距逐漸縮小,多模態、長推理、程式設計、日常任務與工具整合能力,各家都開始形成自己的強項,已經很難再出現一家全面碾壓所有對手的情況。


於是,Google選擇了廣度,靠生態綁定使用者;Anthropic選擇了深度,專注做最強的細分產品;OpenAI則選擇了速度與商業化,搶先鎖定資源與現金流。


對一般AI使用者來說,這其實是好事。因為市場不再只有單一強者,而是三家各自擅長不同場景。未來關鍵不再是找「最強AI」,而是找「最適合自己需求的AI」。


如果偏向搜尋研究、多模態內容製作,可優先考慮Gemini;如果需要深度分析、長文撰寫、程式設計,Anthropic系統可能更合適;如果重視日常對話、快速原型與成熟工具體驗,OpenAI仍然具有明顯優勢。理解各家定位、依需求組合使用,往往才是最實際的策略。


總結來看,這一天三家公司同時亮牌,不只是新聞事件,更是一個訊號:AI模型本身的絕對差距正在縮小,未來競爭將更集中在產品、服務、商業模式與使用者體驗。對大公司而言,這是新一輪戰略分化的開始;對創業團隊而言,則意味著更需要找到差異化定位;而對普通使用者而言,真正重要的是建立屬於自己的AI工作流,讓工具為自己提升效率與產出。


AI下半場,才正要開始。

[AI 分享] 用對AI的方法

 [AI 分享] 用對AI的方法

摘要 : 多數人用不好AI,不是提示詞不夠長,而是把自己的有限理解硬套給AI。真正有效的方法,是提供優質樣本,讓AI自行拆解規律。




內容:

大部分人用不好AI的核心原因,在於他們常常把AI變成「另一個維度的自己」。換句話說,很多時候提示詞寫得越詳細,反而越容易把AI的表現限制在自己的理解範圍內,導致結果看起來很假、很僵硬,缺少真正的味道。


以AI寫爆款文案為例,很多人會先告訴AI「你是一位資深文案專家」,再補充一大堆風格、原則與技巧,甚至寫上數千字提示詞。但最後產出的內容,往往只是表面像,實際上沒有神韻。也有人研究某些博主的影片後,整理出短句、犀利語言、反問等特徵,再把這些規則餵給AI,結果依然只是「形似神不似」。


問題的本質在於,這些做法都是把自己腦中對某種風格的理解,翻譯成一套規則,然後要求AI照著執行。這在某些場景可以成立,但在更多創造性工作裡,往往註定失敗。


使用AI大致可以分成兩種類型。第一種是流程明確、步驟清楚的任務,例如翻譯、資料整理、格式轉換,或將A平台內容搬到B平台並做固定調整。這類工作輸入、輸出和中間流程都能清楚定義,使用詳細提示詞或智慧體處理,通常效果很好。


第二種則是創造性任務,例如希望AI模仿某位博主,寫出相似風格的爆款內容。這時候,單靠自己總結幾條特徵,再轉成提示詞讓AI模仿,通常不夠。因為你以為自己抓住的是對方成功的秘密,但實際上往往只抓到表層。


這就像學做菜。你去餐廳吃到一道很好吃的菜,或許能分辨出用了醬油、蠔油,火候比較大,於是把這些寫成菜譜讓別人照做。但成品通常還是差很遠。原因是廚師真正的能力,不只是材料和步驟,而是火力、翻鍋節奏、下料時機,甚至是一種說不清楚的手感與經驗。你從外部觀察後得到的,只是你理解中的那道菜,而不是廚師真正做出的那道菜。


因此,正確做法不是先替AI總結規則,而是直接把作品本身交給AI。讓AI看到真正的大量樣本,例如把某位高手的十篇、幾十篇,甚至上百篇作品直接提供給它,然後只問一句:「幫我分析這些內容有什麼共性?」


大語言模型最強的能力,本來就不是乖乖執行你主觀整理出的規則,而是進行大規模模式識別。它是從海量文本中訓練出來的系統,只要給它足夠多的樣本,它就能提取出連創作者自己都未必意識到的規律。


實際上,當把一個人表現最好的幾十條影片文案都交給AI分析,而且不先預設風格、不限定維度時,AI拆解出來的結果,往往比人自己反覆觀看後總結得更完整。它可能分析出平均句長、短句比例、反問句常出現的位置、正文結構偏遞進還是分點、開頭啟動了什麼樣的心理機制等。很多細節,往往是人看到AI分析後,才恍然大悟原來一直存在,只是自己過去根本不會想到去觀察。


這裡有一個很核心的差別。若你先研究高手,再把自己的研究成果寫成提示詞,那AI產出的上限,其實就是你的認知上限。你不知道的東西,就無法寫進提示詞裡。反過來,如果你把高手的作品直接交給AI,讓它自己拆解規律,那你用到的就是AI最強的模式識別能力,這才是真正發揮它價值的方式。


所以,與其在提示詞裡憑空塑造一個你想像中的高手,不如去現實中找到真正的高手與真實作品,然後大量提供給AI,讓它自己分析、自己總結。你的任務不是教AI怎麼做,而是選對樣本、問對問題。


說到底,AI時代真正重要的分水嶺,是你是否願意承認:在許多創造性領域裡,自己的理解其實不足以直接定義想要的結果。一旦承認這一點,你就不會再執著於把有限認知硬塞給AI,而會把自己的角色,從「教AI做事的人」,轉變成「為AI選素材、提問題的人」。這種策展式的能力,才是更值得修煉的方向。