聘請一家醫療 SEO 代理商與聘請一家一般代理不同，而這個差別不在能力，在於許可。診所營運在一套廣告規則之下，這套規則讓常規打法中的很大一部分變得不合法；同時又處在 Google 的品質框架之下，而該框架對健康內容的檢視比幾乎任何其他類別都更嚴格。一家兩者都不了解的代理，做出來的東西要麼被下架，要麼永遠排不上去。 商業賭注異常之高，因為一例植牙、一次植髮或一個醫美療程的價值，超過多數電商顧客一生的消費。這也是為什麼這個類別會吸引那些從未讀過規則的代理。 決定一切的兩條邊界： 在英國不能向大眾宣傳處方藥，這就排除了在任何病患看得到的位置寫出肉毒桿菌品牌名；而 Google 把健康頁面當作涉及金錢或生命的內容，因此沒有署名的匿名文章無論...
英國企業
關於英國企業的文章、指南和教程，為開發者和企業提供實用知識與技巧。並說明真實成本與取捨。
企業 AI 代理人是一個熟悉故事的當下版本：一個十分鐘就展示得很漂亮的原型，接著是六個月的努力，只為把它做到夠可靠、可以無人看管。幾乎全部預算都消耗在這兩種狀態之間的距離裡，而幾乎沒有任何行銷資料描述這段距離。 代理人與聊天機器人有一處在商業上真正要緊的差別。聊天機器人產出文字，由人來決定拿它做什麼。代理人則會採取行動：呼叫系統、寫入紀錄、發送訊息。這一轉變把風險從尷尬變成了後果，也正因如此，所需的工程紀律更接近建置一套支付系統，而不是一件內容工具。 錢實際花在哪裡： 模型是最便宜的部分。成本在工具整合、評測框架、護欄，以及交回給人的路徑上。一個簡單的內部代理人是 £5,000 到 £12,000，帶檢索的是 £12,000...
在英國做醫療軟體開發，比其他任何產業的同等工作都更貴、更慢，原因並不是程式碼更難寫。原因是預算中相當大的一部分花在證據而不是功能上：臨床風險文件、資訊治理，以及買方在還沒試用產品之前就會索取的合規資料。 在別處做過軟體的團隊一直低估這一點。他們替應用報價、拿下專案，然後才發現合規這一層不是收尾階段，而是必須從第一天就開始的平行工作流，因為它會限制那些日後修改代價高昂的架構決策。 真正推高成本的東西： 一個英國醫療專案大約四分之一到三分之一的預算花在臨床安全、資訊治理與合規證據上，而不是功能。決定性的問題不是你的應用有多複雜，而是它是否接觸病患資料、是否影響臨床決策，以及買方是不是 NHS。每一項都會各自增加一條獨立且無法省略的工作...
AI SEO 代理商這個說法涵蓋了兩門完全不同的生意，而在簽約之前把它們分辨開來，就是這件事的大半工作。一種用語言模型更快地生產更多內容，並把這稱作 AI 服務。另一種研究的是，當 AI 系統生成答案時，你的公司會不會出現在答案裡面，這是一門真正的新學科，其機制與把一個頁面排上去完全不同。 只有後者賣給你的是你原本沒有的東西。前者賣給你的是一座更便宜的文字工廠，而市場上這兩者都掛著同一塊招牌。 真正重要的區分： 用 AI 寫稿的代理是在自動化供給。做 AI 能見度的代理，改變的是當有人提出你產品能回答的問題時，ChatGPT、Google AI Overviews、AI 模式與 Perplexity 會不會引用你。請在頭十分鐘就問清...
挑選一家 SaaS SEO 代理商，比挑選一般代理更難，因為一般代理擅長的大部分工作，對軟體公司幾乎沒有意義。在地引用、Google 商家檔案維護、每月一篇產業趨勢部落格，都是正當的服務。它們只是幾乎不影響一個訂閱制產品能否取得留得下來的客戶。 這種錯位在提案現場很容易被忽略，因為交付項目聽起來合理，報表看起來也詳盡。它會在半年後浮現：流量漲了，註冊數卻原地踏步，而沒有人能解釋這個落差。 SaaS SEO 代理商與一般代理的分水嶺： 它以試用啟用與留存營收為最佳化目標，而不是工作階段數；它把技術文件與整合頁面當成排名資產，而不是客服內容；它明白買家在決策前會研究好幾週。如果一家代理說不清自己將如何影響你的啟用率，那它賣的是流量，不是...
微調 vs RAG 這個題目，多半不是以問句出現，而是直接以一句結論登場：我們要拿自己的資料去微調一個模型。這大概是企業 AI 裡最花錢的一句話，而且多數時候是錯的。不是每次都錯，但確實多數如此。這句話背後幾乎只有兩種真實情況：模型不清楚我們公司的事，或者模型回答的方式不合我們的要求。前者用微調來解很糟糕，後者用微調來解很貴。 在微調、RAG 與提示詞之間做取捨，並不是工程師的口味問題。這三者處理的是完全不同類別的毛病，一旦選錯，換來的會是好幾個月的工，而最初那句抱怨依舊原樣擺在那裡。 最能省下預算的一條原則： 如果毛病出在模型不知道某件事，就用檢索。如果毛病出在模型知道，但回答的風格、格式或篇幅不對，先把提示詞改好，真的無效時才輪...
網站遷移大概是唯一一種能在一個下午就抹掉多年搜尋能見度的例行專案。重做前端、更換平台、更換網域，甚至只是順手整理一下網址結構，都帶著同樣的風險，而損失很少在上線當天現形。它通常在兩週後才浮出來，表現為一條安靜而持續的下滑曲線，沒有人會把它和那次發布聯想在一起。 好消息是，成因早就被研究得很清楚，而且幾乎全部可以預防。在實際專案裡，遷移造成的流量損失幾乎都能追到同一件事上：一份不完整的重新導向對照表。這篇文章裡的其他所有內容，重要性都排在把這件事做對之後。 只有一條規則： 每一個目前存在且仍有價值的網址，都必須透過一次永久重新導向，落到新站上最接近的對應頁面。這裡說的價值，指的是它有流量、有外部連結，或者僅僅是已被索引。不是首頁。不是...
Drupal 遷移屬於那種能安穩待在下一季計畫裡的專案，直到某個日期讓它變得急迫。眼前正有兩個日期在做這件事，而其中只有一個還沒到來。 Drupal 7 已於 2025 年 1 月 5 日失去官方支援。任何還在跑它的網站，已經一年多沒有任何資安保障了。Drupal 10 將在 2026 年 12 月 9 日走到生命週期終點，正好是 Drupal 12 推出的同一週，此後它不會再收到任何形式的釋出版本。如果你正處在這兩個版本之一，問題已經不是要不要動，而是走哪一條路、要花多少錢。 你現在的位置： 從 Drupal 10 到 Drupal 11 是一次真正的升級，同一個網站原地更新，通常兩到六週。從 Drupal 7 到 Drupal...
需要招聘 Drupal 開發者的組織，通常在營運體量不小的東西：有四十個院系的大學網站、帶有無障礙義務的公部門入口網站、權限真正重要的會員平台。Drupal 很少被選來做型錄式的網站。它被選中，是因為內容模型複雜，而這意味著你招的人必須理解模型，而不只是佈景主題。 這個市場也比 WordPress 更小、更成熟。開發者更少，其中資深比例更高，招聘流程獎勵的是具體。本文說清這個職位在 2026 年要花多少錢、哪些能力把 Drupal 工程師和只裝過一次 Drupal 的 PHP 開發者區分開，以及現在就該左右你決策的那個期限。 有時間壓力： Drupal 10 將於 2026 年 12 月 9 日結束生命週期，同一週 Drupal...
CRM 與 ERP 整合幾乎總是被說成一個連線問題，而它幾乎從來都不是連線問題。兩套系統都有文件齊全的介面，也都有現成的連接器。真正的難處在於，業務和財務花了很多年，用兩套不同的詞彙去描述同一門生意，而整合正是這兩套詞彙被迫達成一致的地方。 當有人問起，一條被轉換過兩次的商機到底該產生一個客戶還是兩個，這個專案就不再是技術問題了。這樣的對話，在三十個欄位上重複一遍，才是真正的工作量。 先做這件事: 在挑選連接器或平台之前，先寫下每一個共用欄位由哪套系統擁有，以及兩邊同時被編輯時會發生什麼。跳過這一步的整合建得很快，然後用好幾年時間不斷產出重複紀錄、對不上的合計數，以及沒人敢信的報表。 為什麼 CRM 與 ERP 的資料始終對不齊兩套...