企業級 SEO 代理商在解的是與小企業代理不同的一類問題，而差別不是算術意義上的規模。一個大站很少是因為沒人知道該修什麼而失敗。它失敗是因為知道的那個人推不上線。 這正是提案裡從不談的部分。稽核查出十二個問題，其中十一個需要改動某個版型、某個平台，或某支擁有自己路線圖的團隊所掌管的發布流程，十八個月後上線了四個。SEO 從來都不是瓶頸。 真正限制企業級 SEO 的： 是實作能力與組織歸屬，不是診斷。沒人能部署的建議，價值等同於沒有建議。合適的代理要按有多少條發現真的進了正式環境來評判，任何拒絕被這樣衡量的代理，都是在賣文件給你。 為什麼診斷是容易的那半在小站上，做 SEO 的人通常也有改動的權限。在大站上，一個標題標籤可能由平台團隊...
企業軟體
關於企業軟體的文章、指南和教程，為開發者和企業提供實用知識與技巧。並附真實專案中的具體案例。
企業 AI 代理人是一個熟悉故事的當下版本：一個十分鐘就展示得很漂亮的原型，接著是六個月的努力，只為把它做到夠可靠、可以無人看管。幾乎全部預算都消耗在這兩種狀態之間的距離裡，而幾乎沒有任何行銷資料描述這段距離。 代理人與聊天機器人有一處在商業上真正要緊的差別。聊天機器人產出文字，由人來決定拿它做什麼。代理人則會採取行動：呼叫系統、寫入紀錄、發送訊息。這一轉變把風險從尷尬變成了後果，也正因如此，所需的工程紀律更接近建置一套支付系統，而不是一件內容工具。 錢實際花在哪裡： 模型是最便宜的部分。成本在工具整合、評測框架、護欄，以及交回給人的路徑上。一個簡單的內部代理人是 £5,000 到 £12,000，帶檢索的是 £12,000...
在英國做醫療軟體開發，比其他任何產業的同等工作都更貴、更慢，原因並不是程式碼更難寫。原因是預算中相當大的一部分花在證據而不是功能上：臨床風險文件、資訊治理，以及買方在還沒試用產品之前就會索取的合規資料。 在別處做過軟體的團隊一直低估這一點。他們替應用報價、拿下專案，然後才發現合規這一層不是收尾階段，而是必須從第一天就開始的平行工作流，因為它會限制那些日後修改代價高昂的架構決策。 真正推高成本的東西： 一個英國醫療專案大約四分之一到三分之一的預算花在臨床安全、資訊治理與合規證據上，而不是功能。決定性的問題不是你的應用有多複雜，而是它是否接觸病患資料、是否影響臨床決策，以及買方是不是 NHS。每一項都會各自增加一條獨立且無法省略的工作...
微調 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 的資料始終對不齊兩套...