企業軟體

微調 vs RAG 這個題目，多半不是以問句出現，而是直接以一句結論登場：我們要拿自己的資料去微調一個模型。這大概是企業 AI 裡最花錢的一句話，而且多數時候是錯的。不是每次都錯，但確實多數如此。這句話背後幾乎只有兩種真實情況：模型不清楚我們公司的事，或者模型回答的方式不合我們的要求。前者用微調來解很糟糕，後者用微調來解很貴。 在微調、RAG 與提示詞之間做取捨，並不是工程師的口味問題。這三者處理的是完全不同類別的毛病，一旦選錯，換來的會是好幾個月的工，而最初那句抱怨依舊原樣擺在那裡。 最能省下預算的一條原則： 如果毛病出在模型不知道某件事，就用檢索。如果毛病出在模型知道，但回答的風格、格式或篇幅不對，先把提示詞改好，真的無效時才輪...

進入 2026 年後，認真考慮遷移離開 OpenAI 的團隊明顯變多了。開放權重模型在日常生產任務上的品質已經很難與頂尖模型區分開來，公開單價更低，而權重本身可以下載這一點，把與廠商的關係從依賴變成了選擇。 但這不代表切換是免費的。API 呼叫本身幾乎一模一樣，真正要做的工作在它周圍的一切。本文說明：哪些東西能原樣搬過去、哪些會悄悄出問題、怎樣設計一次有意義的比較，以及什麼時候留在原地才是正確答案。 先把預期對齊。 換廠商就是換一個基底 URL、一個模型名稱、一份憑證。但要拿回同樣的輸出品質，那是以天為單位計的提示詞工程。給一個範圍明確的功能預留一到三週。任何假設可以即時替換的估算，都是樂觀估算。 哪些東西能原樣搬過去比你想的多，這...

大多數團隊把 API 安全當成身分驗證問題：發放權杖，在每一條路由上檢查它，然後認為事情已經做完了。直到某天，一位測試人員把網址裡的一個數字改掉，就讀到了另一位客戶的發票。 「已通過身分驗證」和「已獲得授權」之間的這道縫隙，正是絕大多數真實 API 外洩事件棲身的地方，而且它並不是掃描器能夠穩定發現的那類問題。自動化工具看到一個有效的權杖和一個 200 回應，就回報成功。只有理解你業務規則的人，才會注意到那個回應裡裝的是別人的資料。 核心區別： 身分驗證證明的是誰在呼叫。授權決定的是這個特定呼叫方可以看到什麼、可以修改什麼，而且它必須落實到每一個物件、每一次請求，並在資料層強制執行。幾乎所有嚴重的 API 漏洞，都是第一件事運作完...

Drupal 遷移屬於那種能安穩待在下一季計畫裡的專案，直到某個日期讓它變得急迫。眼前正有兩個日期在做這件事，而其中只有一個還沒到來。 Drupal 7 已於 2025 年 1 月 5 日失去官方支援。任何還在跑它的網站，已經一年多沒有任何資安保障了。Drupal 10 將在 2026 年 12 月 9 日走到生命週期終點，正好是 Drupal 12 推出的同一週，此後它不會再收到任何形式的釋出版本。如果你正處在這兩個版本之一，問題已經不是要不要動，而是走哪一條路、要花多少錢。 你現在的位置： 從 Drupal 10 到 Drupal 11 是一次真正的升級，同一個網站原地更新，通常兩到六週。從 Drupal 7 到 Drupal...

自架 Kimi K3 在 2026 年 7 月 27 日成為技術上可行的選項，當天 Moonshot AI 連同生產級推理支援一起公開了這個 2.8 兆參數模型的權重。許多組織讀到這則消息後得出結論：現在可以在自家硬體上執行前沿級推理，不必再按 token 付費了。 這個結論通常是錯的，但原因並非人們預想的那樣。工程上是做得到的。真正擊垮多數專案的是那筆帳，而且它往往在預算核准好幾個月後才悄無聲息地發作。 簡短回答： 在 MXFP4 精度下，2.8 兆參數在計入鍵值快取之前就已占用約 1.4TB。一個八卡 H100 節點只有 640GB，因此根本無法服務這個模型。實際的部署要從約 1.7TB 顯示記憶體起步，也就是採用 288GB ...

凡是按端點數量來估算客製化 API 開發成本的人，幾乎都會算錯，而且通常差三倍。端點本身是整件事裡最便宜的部分：十來個端點，只是讀寫你手上已經有的資料，對一位稱職的後端開發者來說不過是兩週的活。 真正花錢的，是把這些端點變成另一家公司願意把生意押上去的東西所需要的一切：經得起安全稽核的驗證、讓你日後還能改主意的版本管理、好到沒人需要寫信問你的說明文件，以及能告訴你哪個客戶今天早上過得不順的維運裝置。有一個 API，和有一個別人靠著它做生意的 API，兩者之間的那道落差，才是預算真正的去處。 價格區間速覽: 只被你自己的應用程式呼叫的內部 API，通常花費 10,000 到 30,000 英鎊。...

CRM 與 ERP 整合幾乎總是被說成一個連線問題，而它幾乎從來都不是連線問題。兩套系統都有文件齊全的介面，也都有現成的連接器。真正的難處在於，業務和財務花了很多年，用兩套不同的詞彙去描述同一門生意，而整合正是這兩套詞彙被迫達成一致的地方。 當有人問起，一條被轉換過兩次的商機到底該產生一個客戶還是兩個，這個專案就不再是技術問題了。這樣的對話，在三十個欄位上重複一遍，才是真正的工作量。 先做這件事: 在挑選連接器或平台之前，先寫下每一個共用欄位由哪套系統擁有，以及兩邊同時被編輯時會發生什麼。跳過這一步的整合建得很快，然後用好幾年時間不斷產出重複紀錄、對不上的合計數，以及沒人敢信的報表。 為什麼 CRM 與 ERP 的資料始終對不齊兩套...

採購 COBOL 現代化服務，和買任何其他軟體工作都不一樣。要動的那套系統已經跑了三四十年，公司裡現在沒有一個人完全弄得懂它，而做壞了的代價不是錯過幾個迭代，是法遵申報出問題。與此同時，擺在你桌上的幾份提案承諾的結果一模一樣，報價卻差了好幾倍。 這篇文章講清楚一份認真的合作究竟包含什麼，幾類供應商之間的差別在哪裡，以及哪些問題能把建立在證據上的報價，和建立在樂觀上的報價分開。它假設你就是事後必須為這個決定提出說明的那個人。 該看什麼： 一份可信的 COBOL 現代化提案包含現況盤點、目標架構設計、資料遷移、程式碼轉換或重新託管、以比對為核心的測試計畫、平行運行、切換規劃以及知識移轉。只替程式碼轉換標了價的報價，不是一份專案計畫，它只...

第三方 API 整合是商用軟體裡被低估得最穩定的一類工作。文件讀起來清清楚楚，供應商提供了用戶端函式庫，於是有人說兩週。六週之後，團隊還在爭論：當一個 Webhook 為一筆已經退款的訂單第二次送達時，究竟應該發生什麼。 這道落差不是能力問題。真正的原因在於，一次整合裡有意思的部分從來不是請求和回應，而是當對方系統做出它的文件從未描述過的行為時，隨之而來的一切。它一定會這麼做，因為它是一個活著的產品，屬於一群有自己路線圖、對你的發布計畫不承擔任何義務的人。 經驗法則： 只從一個服務拉取資料的唯讀整合，通常需要一到三週。會寫入交易的整合需要三到六週。兩邊都允許編輯的系統之間的雙向同步需要六到十二週，而且永遠不會真正結束，因為衝突解決是...

每一次大型主機遷移，都從有人去搜尋大型主機遷移工具開始，而隨後那場廠商展示看起來總是格外可信。幾千行 COBOL 送進去，可讀的 Java 出來，測試套件全部通過，簡報承諾七成到八成的自動化。展示本身通常是誠實的，只是它跑的那份程式碼，行為跟你的程式碼毫無相似之處。 本文梳理真實存在的工具類別，說明每一類真正擅長什麼，以及在真實負載下各自最容易垮掉的具體位置。它寫給必須在立案報告上簽字的人，而不是寫給組織內部替廠商說話的人。 實話實說： 大型主機遷移工具確實做了大量有用的工作，尤其是在分析、資料搬運與機械轉換這三件事上。它們做不到的是理解你的業務規則。自動轉換可以穩定地產出能執行的程式碼，但產不出你的團隊願意維護的程式碼，而彌合這段...