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