Grok Bot 進化史:由早期 Beta 到而家功能表(附香港實例)

Grok 係腦,Grok Bot 係會動手嘅同事。講吓點 set rules、同香港實際用法——寫通告、追包裹、監測網站,進化史幾句帶過就得。

最近周圍人都問:Grok 同 Grok Bot 係咪同一樣嘢?簡單講——唔係。Grok 係腦,識傾偈、識寫;Grok Bot 係會動手嘅同事,有自己一部雲端電腦,可以幫你開網、睇電郵、寫稿、甚至盯住你個 server 有冇掛。

2026 年 8 月公開 early beta,之後加 Android、接 The X Subscription,十月再有 Pages、Vault、1Password。細節官方 Help 有,呢篇唔整長時間線表——重點係:而家已經可以當「幾隻手」一齊打工。

用得順唔順,關鍵唔係模型有幾醒,而係你有冇講清楚規則。

先 set 好 rules,唔係亂叫

開一個 bot,唔好淨係寫「你係助手」。好似請人返工,要講清楚職責、邊啲唔准做、用咩語氣。

角色可以咁分(示例,名稱你自己定):

  • 寫手:只負責 blog 初稿,書面語/教學說明風,唔自動發佈,敏感通道唔開。
  • 監測:只做探測同告警,唔准自行重啟伺服器、改防火牆。
  • 彙總/秘書:定時(例如每日某個鐘,香港時間)整告警同待你批核事項清單。

你可以喺 bot 第一則訊息、profile/instructions,或者每次開新任務時重複提醒。敏感嘢(密碼、卡、學生個資)唔貼 chat;用 Vault 或 1Password,外寄/落單要停低等你確認。

一句:rules 寫得鬆,bot 就當自己係萬能;rules 寫得實,先似請咗幾個專責同事。

實際可以點用(多啲例子)

以下全部係「你可以點同佢講」嘅場景。香港網站若擋 cloud IP,可以試經你部電腦路由,或者敏感步自己 Take over。

學校/教學

  • 「用書面語寫明日雨天通告,對象小一至小六家長;另外俾一則 WhatsApp 口語版。」你再按學校格式改。
  • 「根據呢張錯誤畫面同外掛版本,列三個最可能原因、檢查步驟,同『唔好亂 Reset』清單;結果整成一頁畀同事跟。」
  • 「睇我日曆,星期三邊啲會;為科組會議寫五點議程,會前一小時用 routine 提醒我(Asia/Hong_Kong)。」
  • 「整一頁比較三個 AI 方案畀家長會用:表、風險、問答;先只分享俾我。」

日常生活

  • 「Foodpanda 觀塘附近兩餸飯,預算 $120 內,落籃後停低等我確認先付款。」
  • 「Uber 由九龍塘去觀塘大概幾耐幾錢,唔好直接叫車,先報價。」
  • 「呢個順豐運單,開官方追蹤頁,用幾句寫狀態、預計、下一站,連結留低。」

寫 blog/估成本

  • 「用 zh-HK 教學說明風,為自己 blog 出大綱+正文;分類標籤建議;唔好捏造數據。」——常見流程:bot 出稿,你審完先上。
  • 「用公開 API 價同訂閱額度兩套邏輯,估一日教師研討會大概用量。」(可對照本站《大會花多少 bot token》)

管理員/系統監測(幫你打工嗰種)

  • 「每 15 分鐘 check 我個公開網站;唔係 200 或者超時就用一句告警我,並列最近三次結果。唔好自動重啟。」
  • 「我貼咗 df -h、uptime、free -h 同 error log。幫我判斷係碟滿、OOM 定服務掛;用表列現象/可能原因/建議指令/風險。唔好自己跑會改系統嘅指令。」
  • 「根據外掛清單同 PHP/OS 版本,對照公開公告,列高危項目同建議;每週更新一頁。唔好亂裝未知外掛。」——之前好多站因 XML-RPC/舊外掛出事,呢類巡檢好有用。
  • 分工示例:一個 bot 專探測,一個專寫稿,一個定時彙總。監測嗰個發現異常只通知人,唔准自己改機。

再加兩個常見場面:

  • 「每晚 11 點 routine:摘要今日未覆 Gmail,草稿三封最急,唔好直接寄。」
  • 「家用 NAS/備份完成未?只讀狀態頁,失敗就 chat 知我一聲。」(視你有冇俾權限開嗰個介面)

幾樣我自己會守

  • 唔撈亂「Grok App 聊天」同「Grok Bot 助手」——同人介紹時講清楚。
  • Free/Plus 唔一定有 Grok Bot;多數要 The X Subscription Premium 起,或者舊付費 Cursor/連結計劃。用量睇 Settings → Usage & Billing。
  • 學生姓名、密碼、OTP 唔上 chat、唔丟公開 Page。
  • Bot 可以好似千手觀音咁多手,但每一隻手都要有職分——rules 先係真正嘅遙控。

想追系列可以訂 RSS:https://www.rockfu.net/blog/feed/
相關:《大會花多少 bot token?》

(功能同計劃會變;以你帳號畫面同官方頁為準。呢篇只係分享用法,唔係訂閱/資安建議。)

學校 AI:本地部署,還是外購?

巫筆、Sayo、豆包已落地;難的不是再開一個 App,而是敏感走本地、無個資走外購;還要算同時在線、多媒體上限與維護人手。

週五下午,語文科組剛散會。有人把作文批次丟進 「巫筆」 做寫作批改;隔壁同事打開 Sayo,用 AI 輔助出題與評改草稿;會議剛結束,另一位老師用 豆包 的錄音紀要,把剛才的討論轉成待辦。同一棟樓裡,還有人用免費 Gemini 想課件插圖,或把教材丟進 NotebookLM 問「這份指引怎麼說」。

AI 已嵌進批改、備課、會議。港產寫作批改工具服務逾四百間本地中小學、累計批改達數十萬篇量級;面向教師的評改與課室工具也有二百校以上採用規模。問題不是「會不會開 AI」——老師已經在用。 真正卡著的是:資料可不可以貼、平台愈開愈散、敏感工作要不要留校內、錢能不能續、買了本地之後誰來養。選項一多,人很容易把「核心抉擇」誤寫成「再買一個全校入口」。這篇故意把重點放前面:不是答案特別簡單,而是若不先講清,後面的表格與價錢只會變成另一份報價說明。

先講人話:其實就五件事

  1. 核心抉擇是「本地部署 vs 外購服務」——不是再多買/再開一個 App 當「全校入口」。
  2. 按場景分流:有個資/敏感 → 本地;無個資、要速度與創意 → 外購。巫筆、Sayo、豆包、Gemini 同一條私隱底線(含學生真容/可識別影片)。
  3. 同時在線決定成本帳:雲端多人=多付錢;本地多人=排隊或加機。不要用全校帳號數估本地併發——單機文字聊天與圖片/影片生成還會互相搶資源。
  4. 政府/教育城模型會加入,但不是唯一答案——可選備課軌道,不取代校本分流。
  5. 老師已在用;難的是規範、私隱、可持續——可持續包含維護人手:本地不是「買完就忘」。

下面用場景與數字把這五點撐開;採購細節放到分流清楚之後再談。讀下去時不妨對照這五點——對不上的段落,大概就是可以刪的。

老師已經在用:難的是規範,不是入口

說白了:學界現在缺的不是「有沒有 AI」,而是用得散、規範跟不上、私隱與可持續說不清。

散開的樣子很具體。巫筆管作文流、Sayo 管評改與備課、豆包管會議錄音、Gemini/NotebookLM 管靈感與資料庫——效率真實提升,但「學生作文、會議真名、成績表」可不可以貼進去,往往靠個人判斷,而不是校本原則。疑惑也很具體:資料會不會被拿去訓練?評語、試題、會議摘要準不準,老師還要不要逐句覆核?平台愈開愈多,今天教一個入口、明天又多一個 App,壓力同時來自政策節奏與同儕潮流。這些疑惑不會因為「再上一個平台」自動消失;它們只會在沒有校本原則時,一層層疊到下一間課室。

難度則多落在 IT 與校政:外洩風險、服務能否續、敏感要不要本地、一般備課可否繼續外購、若走本地誰負責更新與救火。本地部署、教育訂閱、政府推動的教學專屬模型,選項愈多,愈需要一條說得清楚的分流——而不是再多開一個「全校入口」。 這也是開頭場景要先講「正在用什麼」,而不是先講「該買什麼」的原因。用得愈多,愈要分清:哪些是「已經在跑的專科工具」,哪些是「還缺一條合規出口」——兩者不是同一筆採購。

一張表看清:哪些本地、哪些外購

分流其實只看兩件事——資料出不出校、要不要速度與多人同時。

場景常見做法敏感度較合適方向
寫作批改巫筆;或 Sayo/通用助理中高外購專科工具(條款清楚、盡量去識別);含明文個資則審合約
出試卷/評改Sayo;免費/教育版 Gemini中高公開題型可外購;含姓名答卷宜本地
學科遊戲生字卡、選擇題小遊戲、課室腳本低外購
圖片生成課件/遊戲/通告配圖(如 Gemini 圖像);或本地 Flux/SD 類中無肖像、要快 → 外購;敏感內用可本地(較慢、常一次一張);學生真容勿上公有雲
短片/動畫課件示意短片、活動宣傳片草稿中高無個資創意 → 外購為主;單機本地短片可行但慢,難當全校併發管線;可識別學生影片勿隨便上公有雲
成績分析班/級平均、弱項、跟進建議高本地
通告家長信、活動通知中先刪姓名後可外購
會議記錄豆包錄音紀要;或 NotebookLM中高本地為佳;至少脫敏再上雲
備課資料庫教材、舊卷、校規 → NotebookLM/校本庫視內容公開教材可外購;含學生樣本則分流

私隱底線可以寫一行:可識別的學生/家長資料,原則上不出校;無個資、要速度與創意的,優先外購。 給 AI 的提示盡量只見內部編號;產出當建議,老師確認後才回寫原系統。本地≠自動安全——帳號共用、無審計一樣會出事;安全靠分流與流程,不是口號。

圖片與短片特別容易越界:課件、遊戲、通告配圖,雲端圖像通常又快又方便;但不要把學生相片上傳公有雲「AI 美化」,也不要把可識別學生活動片丟上公有雲「一鍵生成宣傳片」。敏感內用可考慮本地圖像模型(較慢、工具鏈較散、品質與便利度通常不及雲端),或圖庫/人手。表裡每一格,都應能套回上面第 2 點——同一條私隱底線,不是每個 App 各講一套。 讀表時可以自問一句:這一格若貼進雲端,外洩時學校能不能向家長說得清?說不清的,優先本地或不用。

外購軌道與本地軌道:同一條底線,不是互搶入口

工具可以有四條軌道,但判斷標準其實只有一條——敏感度。核心抉擇是本地還是外購,不是再選一個品牌當全校門面。

  • 專科/免費層(巫筆、Sayo、豆包、免費 Gemini):上手快、對應場景效率高;要注意資料去向,入口不要愈開愈散。
  • Gemini Enterprise for Education(含 NotebookLM):按席位、可集中管理,適合教師團隊備課與指定教材庫;年費會累積,中小學多經代理、常有人數門檻。
  • 本地 Mac Studio/開源(如 MLX+Qwen;圖像可試 Flux/SD 類):適合成績、輔導、含名會議/答卷;併發有限,要 IT 維護;多媒體別指望與文字聊天「同時全開」。
  • 教育城「教學專屬大語言模型」:政府推動、按科目逐步開放的教學助理;不是全港強制唯一平台。

同一套「有個資→本地/無個資→外購」套到以上每一條。寫作批改可以繼續用巫筆,會議可以繼續用豆包——但一旦出現明文姓名、成績、輔導內容,就要問:這條工作流該不該出校?這才是「本地 vs 外購」的意思,而不是把所有老師趕到同一個新入口。實務上,外購解決「快、多人、專科工作流」;本地解決「敏感資料不出校」。兩者可以並存,但並存的前提是分流寫進指引,否則只會變成帳號愈開愈多、責任愈分愈糊。

政府模型會加入——但不是唯一答案

教育城專屬模型是可選軌道,不是全港統一答案,也不取代校本私隱分流。

根據 2026 年 7 月立法會答覆:香港教育城正建立「香港中小學教學專屬大語言模型」;科學科 AI 助理已試行(輔助教案、備課、設計評估或課業),並由 2026/27 起逐步擴至更多科目。同一答覆裡,教育局表明:不會統一採購單一 AI 大模型供全港學校,也不會建立強制「唯一平台」——強調校本選擇,避免技術迭代下被鎖死。

含義很直白:備課/學科助理可以多一條官方可選路;它不取代巫筆、Sayo,也不等於學校可以停想私隱分流。成績、輔導、含名會議,仍要校本自己定界——政府加入 ≠ 學校可以停想分流。 把它放進「四條軌道」裡當一條即可,不要把它神話成「以後全校只走這條」。對校政來說,更有用的問法是:教育城助理開放後,我們用它處理哪一類「無個資備課」?敏感流是否仍走本地或既有合規路徑?——答案應能對上上面第 4 點。

若走本地:單機能扛什麼、扛不住什麼

一句話:Mac Studio 是敏感工作流的私有節點,不是全校雲端助理的替代品。併發天花板,往往比「模型酷不酷」更重要。

本地推理近年常提到 Mac Studio:統一記憶體大、功耗與噪音適合放 IT 室,再配 MLX 跑開源模型。跑大模型應對準 M5 Ultra(統一記憶體 256GB 或 512GB);M5 Max 最高只有 128GB,Max ≠ Ultra。

社群約數(MLX、batch=1):約 7B–9B 短對話可到約 ~140 tok/s,數人至約十人輪流/輕量併發較現實;約 32B 短上下文約 ~30 tok/s(長文更慢),認真對話多為 1–3 路。五十人同一分鐘搶 32B,單機扛不住。誠實一句:本地開源模型在廣度與「最新常識」上多數仍落後免費/教育版雲端助理;本地贏的是邊界與校本語境。

校本知識庫(或 Enterprise 裡指定來源的 Notebook)負責「說本校的話」。沒有庫,本地 32B 只是較慢的通用聊天;有庫,外購也能問校規——但敏感文件放哪裡,要另訂規則。建本地之前,更該問:有沒有三個每週都做、又含敏感度的任務,是校內工具能明顯勝過老師已經打開的那些 App 的?答不出這三個任務,就不該先買「全校本地入口」。本地值得買的,是那條「老師每週都做、又不能安心貼上雲」的工作流;買的是邊界,不是把消費級助理整間學校搬進機房。

單機圖片、影片:能跑,但不該當全校創意管線

一台 M5 Ultra 級機器「可以」做本地圖像,短片也「試得過」——但遠不是雲端那種多人同時、即開即用的創意工廠。無個資創意優先外購;可識別學生影像原則上不出校。

先把期望講死三句:

  1. 圖像:高統一記憶體的 Mac Studio,用 MLX/mflux 一類路徑跑 Flux/SD 系模型,單張課件圖大致可行;社群實測常見是「數秒至十數秒級/張」量級(視模型與解析度),往往一次一張重活,工具鏈與提示詞生態通常仍不及 Gemini 圖像那類雲端服務好上手。品質與便利度參差,適合「敏感、不能上雲」的內用圖,不適合「全校美術科同一節課搶算力」。
  2. 影片:本地短片生成比圖像重一個數量級——數秒短 clip 往往要數十秒至數分鐘級(視長度、解析度與模型),記憶體與算力吃得兇。社群已有 Apple Silicon/MLX 路徑能跑短片,但把它當「全校宣傳片/課室動畫併發管線」並不現實。無個資、要速度與迭代的創意短片,實務上多半仍應外購;可識別學生活動片,則不應隨便丟上公有雲。
  3. 跟文字聊天搶機:圖像/影片任務容易把同一台 Studio 的統一記憶體與 GPU 時間吃光,聊天併發立刻變慢或排隊——這又回到第 3 點:一台機不是「全校所有 AI」。若敏感文字助理已在跑,創意圖像最好另排時段、另開佇列,或乾脆把無個資創意交給雲端。

一句對照就夠:課件插圖要快、又無肖像 → Gemini 圖像等外購;學生真容要處理 → 本地或不用 AI、改圖庫/人手。影片同理:無個資示意片走雲端;帶臉、帶聲音的學生影像,先問私隱底線,再問算力。

維護人手:本地不是「買完就忘」

沒有具名負責人與固定工時,本地 AI 節點會慢慢壞掉。外購把「機房運維」交給供應商,但校本政策、合約與私隱底線仍要學校自己扛。

學校 IT/TSS 本來就忙:帳號、Wi‑Fi、機房、考試系統、教師支援。本地 AI 節點不是插電即用的印表機,它至少還有這幾類持續工作:

  • 系統與安全:macOS/運行時修補、權限與防火牆、誰能連進來。
  • 模型與磁碟:下載、量化選擇、換模型、舊權重清掉;大模型檔很佔位,磁碟規劃要先做。
  • 存取與審計:教師帳號、科組權限、基本日誌——出事時才有跡可查。
  • 備份與還原:知識庫、設定、權限名單;機器壞了能不能一週內回來。
  • 救火與溝通:老師問「為什麼今天很慢」「圖像佇列卡了」「模型換了提示詞怎麼寫」——要有人回。

外購對照也很清楚:雲端服務的機房、升級、可用性多半由供應商運維;學校仍要管的是私隱條款、數據留存、誰准用、出事通報、續約預算。本地省的是「敏感資料出校」的焦慮,換來的是校本運維負債;外購省的是半夜修機,換來的是合約與政策功課。兩邊都不是零人手——只是人手花在不同地方。

務實問法比口號管用:這台 Studio 每週預留幾小時給誰?暑假換模型誰測?老師投訴慢,第一個電話打給誰?答不出「具名+工時」,就不該把本地吹成「一勞永逸的全校方案」。這直接撐起上面第 5 點:可持續=規範+私隱+付錢續得起+有人養得起。

成本帳:先看同時在線,再看價錢

五十人同時用,外購通常是「付錢」;本地通常是「排隊」。帳要按併發算,不是按全校帳號數;若還要跑圖像/影片,併發帳要再打折。

硬對照先講三句,數字只是佐證——若只記得價錢、忘了併發,帳一定會算歪:

  1. 約 50 席 Gemini Enterprise(約 US$60/席/年)≈ US$3,000/年(約港幣 2.3 萬)——多人同時,雲端靠付錢/額度撐。
  2. 一台 M5 Ultra(256GB 級) 約 US$8,000–12,000 一次過(三年攤約 US$220–330/月)——敏感、低併發划算;五十人同一分鐘當唯一入口則不划算;若同一機還要扛圖像/短片,文字聊天的「夠用人數」還要再往下修。
  3. 5 人認真用本地 32B 多數夠;20 人要限流或改 9B;50 人不應指望單機當唯一入口。

換句話說:外購的邊際成本主要是「多一個席位、多一截用量」;本地的邊際成本主要是「多一個人排隊、或多買一台機」,外加維護工時(見上一節)。討論「划不划算」之前,先問科組尖峰時有幾人同時等回覆——這個數字一出來,本地與外購哪邊該扛「一般備課」、哪邊該扛「敏感流」,通常就清楚了。

再補細節:院校/JUCC 聯合招標,Gemini Enterprise for Education 約 US$4.7/用戶/月(約 15 席起),折合約 US$56/年,訂閱含 Gemini Notebook(前稱 NotebookLM);中小學經代理,業界口述「一戶口約 US$60/年」與上述同量級。15 席門檻附近約 US$840–900/年。外購贏在老師已熟、要多人同時、要集中或專科工作流(含無個資圖像/短片);本地贏在敏感資料穩定、不想把成績/輔導/含名會議貼上雲。不要用「全校帳號數」估本地併發——要用「同一分鐘有幾人在等回覆」。免費層適合個人試用,很難當全校正式工作流。

到要動預算時才須面對:項目撥款(例如「『智』啟學教」一筆過約五十萬)看起來闊,但三年要攤硬件、訂閱與活動;撥款用完後,續期與維護是常額——維護不只是電費,還包括具名 IT/TSS 工時。《中小學數字教育發展藍圖》(2026 年 6 月)方向是 AI for all,沒有規定必須自建本地大模型,也沒有規定必須買某一家教育訂閱——政策留白,正是校內要填敏感/一般/教育城助理怎麼接、第四年錢從哪來、本地節點誰養。分流清楚之後,這筆帳才算得準;分流沒寫清就下單,最容易買成兩套「全校入口」。把「同時在線」與「誰養機」寫進討論,比把「機型名稱」寫進討論更重要——前者決定錢與人怎麼花,後者只是手段。

最後再對一下:還是那五件事

怕讀完又變回「再買一個入口」,把五點換句話說一遍:

  1. 要決定的是 本地還是外購,不是再開一個 App。
  2. 有個資/敏感 → 本地;無個資要速度 → 外購——巫筆、Sayo、豆包、Gemini 同一條私隱底線(含學生真容/可識別影片)。
  3. 同時在線才是成本主角:雲端多人付錢,本地多人排隊;單機還要分心跑圖片/影片時,聊天併發再打折。
  4. 教育城模型會加入,但不是唯一——可選備課,不取代分流。
  5. 老師已在用;要補的是規範、私隱與可持續——可持續包含維護人手:本地不是買完就忘。

五點對齊了,後面的「怎麼做」才不會變成長長待辦卻忘了為什麼做。務實路徑很短,而且都服務上面五點:把場景表寫進校本指引;知識庫先行;敏感低併發才考慮 M5 Ultra,並先寫明負責人與每週工時;一般任務與無個資創意(圖/短片)用教育訂閱或既有專科工具;教育城助理做備課試點、不假設它能處理個資;一兩個科組試一學期再扩;項目錢優先買脫敏與知識庫——硬件與席位不要買成兩套全校入口。

若只能帶走一句:先寫清「哪些資料不可出校」,再決定巫筆/Sayo/豆包/Gemini/本地/教育城各管哪一段——入口可以多,私隱底線只能有一條。入口可以多、模型可以換,分流標準不應每個學期重寫一次——工具會換,底線應長期留下去;機可以買,人要養得起。

本地不是信仰,外購也不是投降——是在私隱、併發、多媒體上限、既有平台習慣、撥款、維護人手與政府可選軌道之間,收一個每週真會打開的結。


約數說明:硬件以 Apple 2026 年公開規格為準。tokens/秒參考 MLX 社群約數。本地圖像/短片速度為社群實測量級(視模型與解析度差異大),只作定性與謹慎範圍,不作採購基準。Gemini Enterprise 院校價見 JUCC/院校公開資料(約 US$4.7/用戶/月起,含 Gemini Notebook);中小學實際港元以代理合約為準。政府模型與「不統一採購」見立法會答覆(2026-07-15)。巫筆/Sayo 採用規模為公開報道約數,非採購背書。《藍圖》與「『智』啟學教」依據教育局/政府新聞處材料。本文僅供思考參考,並非採購建議。

校園裏那個「永遠在忙」的人——談談香港學校技術支援的困局與出路

從晨早課室故障說起:香港學校不缺 IT 撥款與 AI 項目,卻長期欠缺像實驗室技術員、政府電腦操作員那樣清晰的 TSS 職級。文章回顧 2017 年教聯會「納入常額編制」訴求,並回應「有了 AI 還要請 TSS 嗎」——結論是技能會變,校本穩定人手仍不可少。

早上八點一刻,鈴聲還沒響,電腦室的投影機突然黑屏;家長 App 的密碼重設訊息同時湧進來;老師拿着平板問:「點解上唔到 Wi‑Fi?」——校園裏總有人一邊聽電話、一邊蹲在機櫃前、一邊在群組回覆「收到,即刻睇」。課上完了,學生以為一切理所當然;真正撐着整件事的,往往是那一兩個技術支援人員(TSS)。

這篇文章想說的,不是埋怨,而是一個愈來愈難迴避的問題:香港學校的資訊科技發展很快,但支撐服務運作的人力結構,似乎一直沒有跟上。

資源其實有,職級卻常常沒有

先說公道話:教育局並非沒有投放資訊科技資源。學校常用的經常性撥款,包括「資訊科技綜合津貼」(CITG),可用於消耗品、軟件、網絡保安、保養,以至聘請技術支援人員或購買技術支援服務;另有自 2017/18 學年起發放的「資訊科技人員支援津貼」(ITSSG),2026/27 學年每校約 35 萬元,主要用來加強駐校技術人手——可以自行聘請,也可以委託公司派駐。

再往上數,還有「第四個資訊科技教育策略」下覆蓋全校課室的無線網絡建設(業界常稱 WiFi900 相關安排),以及優質教育基金(QEF)對 STEAM、數字教育的支持;近年更有「『智』啟學教」一筆過撥款,推動人工智能輔助教學。硬件、平台、課程項目,一個接一個。

問題在於:錢與項目可以到位,職位本身卻往往仍停留在「津貼聘用/服務合約」的層次。CITG 與 ITSSG 的官方表述,都強調學校可靈活訂定入職要求與薪酬福利——靈活固然好,卻也意味着:TSS 多數不在資助學校核准編制裏,沒有像其他工種那樣清晰的職級階梯。ITSSG 的出現,確實加強了人手資源;但它本質上仍是現金津貼,並不等于把 TSS 納入常額編制。

其實,這個缺口並不新鮮。2017 年 6 月,香港教育工作者聯會(教聯會)與候任特首辦主任會面,就善用新增經常教育經費提出補充要求,其中特別提到:應將「資訊科技技術支援人員(TSS)」納入常額編制。理由很直白——TSS 不屬常額、欠缺晉升前景、流失率偏高,而電子學習已成大勢。教聯會當時建議增設專門經常撥款聘請 TSS(涵蓋薪酬、強積金及《僱傭條例》福利),並按中小學學位教師薪金中位數估算,預計新增開支約四至五億元。近十年過去,校園科技只會更多、不會更少;當年那句「納入常額」的訴求,讀起來仍然刺耳——因為問題的核心,還沒有真正被結構性解決。

同一個校園,兩種待遇感——甚至三種對照

最容易拿來對照的,是實驗室技術員。資助中學的實驗室技術員有編制計算方法,亦有一級、二級、三級等職級與薪級安排,職責隨 STEM/科學活動需要更新,官方文件寫得清楚。他們服務的對象,主要是科學相關課堂與活動——當然重要。

再拉開一點看公務員體系:政府本身就有「電腦操作員」職系(由數字政策辦公室相關職系管理),職責涵蓋操作與監察電腦設備、網絡及數據中心/伺服器室、用戶支援/求助台、相關採購與資產管理等——跟學校 TSS 日常做的事,其實頗相近。更關鍵的是,這條路有透明的總薪級表階梯:例如二級電腦操作員約第 6 至 15 點、一級約第 16 至 20 點、高級約第 21 至 28 點,再上至助理電腦操作經理、電腦操作經理。薪點對應的金額隨公務員事務局公布的總薪級表調整(以 2026 年 4 月 1 日起計,約由二萬出頭遞增至近十萬元級別,視職級而定)。換言之,政府承認「操作層 IT 支援」值得一套正式職級;資助學校的 TSS,卻多數仍靠校本靈活聘用,欠缺可對照的核准編制階梯。

TSS 呢?日常面對的是全校:學生帶裝置上課、老師用電子學習平台、家長查電子通告、行政要跑網上校管系統、訪客要上網、典禮要影音。服務面更闊,責任鏈更長,但在不少學校,職稱仍停留在「技術支援」「IT 助理」,晉升路徑模糊。這裏不臆測個別學校的具體薪金數字——重點是:校內往往看不到像實驗室技術員、或政府電腦操作員那樣公開可循的職級階梯,薪酬與前景也較難與業界同級技術工作競爭。業界裏常見的感受是:招人難、留人更難;升職空間窄,雜務卻從不缺——搬機、佈線、跟進供應商、放學後趕維修,都可能落在同一個人身上。

老師有較清晰的專業階梯,亦要持續進修數字教育相關培訓;TSS 同樣要不斷學——雲端、保安、裝置管理、AI 工具進校後的新問題——卻未必換來對等的專業認可。很多人自資報讀課程、晚上翻文件、週末趕緊測新系統,為的是學校下一波挑戰到來時不至於手足無措。可是,學習若只被看成「個人興趣」,而不是崗位應有的專業投資,士氣自然難持久。

坊間有種心態:「老師流動性低,TSS 走了再請過。」這句話聽起來務實,其實很傷人:把穩定當成理所當然,把流失當成可接受成本。事實上,換人的隱性代價往往更高——新同事要重新認識校情、裝置帳號、供應商習慣,中間掉落的細節,最後還是老師與學生來承擔。

發展很快,結構卻像在趕工

回看這十來年:無線網絡普及、電子學習成為日常,接着是 STEM/STEAM,再來是人工智能進校園。節奏快得像趕工建樓——先把招牌亮起來,骨架是否穩妥,有時反而少人問。

有資源時,話題容易集中在「買什麼設備、推什麼計劃」;人手結構、職銜、晉升、培訓預算,卻常被輕輕帶過。資源緊絀時,又會想:不如外判吧。外判不是原罪,但若校內沒有懂技術、懂採購、懂跟進的人,老師真的要自己追供應商、拆合約條款、判斷維修是否合理嗎?最後往往還是那幾個「懂一點 IT」的同工默默頂上。

一個「資訊科技統籌」職銜,不足以概括整條服務鏈。統籌可以定方向;真正半夜重啟伺服器、白天撐課堂裝置、傍晚對家長系統的,需要被看見、被命名、被納入長遠人力規劃——教聯會當年說的「常額編制」,講的正是這種結構性位置,而不只是多一個臨時工時。

那 AI 來了,還要請幾個 TSS 嗎?

有人會認真反問——而且問得很合理:AI 能減輕老師行政負擔,AI agent 又能處理日常 IT 疑難,學校是否還要請幾名 TSS?難道不該「減人手、加智能」?

先承認能省的部分。重設密碼、常見 FAQ、簡單故障分流、按劇本做的狀態檢查,確實可由聊天機械人或自動化接手;善用的話,重複性壓力會下降。這是好事,不必為了護航人手而否定 AI。

但校園 IT 從來不只是「答問題」。Wi‑Fi、投影機、佈線仍是實體工作;供應商合約與驗收要人把關;學生與家長資料涉及私隱,不宜全盤交給黑箱;開學、派成績、惡劣天氣停課那幾天,家長系統一擠,要的是懂校情、知道該找誰升級的人;雲端或 AI 本身掛掉時,還得有人現場止血。更諷刺的是:學校愈積極導入 AI,就愈需要人評估工具、設定權限、訂政策、做培訓,以及收拾「影子 IT」。AI 減的是部分票務;加的是整合、治理與事故應變。

誠實的答案不是「還要請那麼多同樣的人」,而是「仍需要穩定的校本技術力量,只是技能組合會變」——少一點純重複操作,多一點自動化、保安、數據判斷與 AI 落地。若把 AI 當砍崗位的理由,最後往往只剩外判熱線與老師自己追供應商。政府有電腦操作員職級、教聯會談常額編制,正是因為操作層支援是長遠能力。AI 愈是戰略項目,校內愈需要留得住、跟得上的人。

可以怎樣走下去?

與其只抱怨,不如問:學校與業界可以做些什麼?

一、把「人」寫進發展計劃。 談 AI、談電子學習時,同步寫明技術支援編制、培訓時數、替假與應急安排,以及人手技能如何從「修機應急」轉向「自動化+治理+AI 落地」,而不是只寫設備清單。

二、校內先給尊嚴與階梯。 即使短期未能等到全港統一職級,學校仍可訂立清晰職稱(例如技術支援主任/高級技術員)、年度調薪與進修支援,避免「什麼雜務都丟給 IT」。

三、對照已有的正式職級經驗。 實驗室技術員說明學校體系可以為技術崗位訂編制;政府電腦操作員職系則說明「操作層 IT 支援」本來就可以有透明晉升階梯。不是要把工種對立,而是承認:當某類技術崗位服務全校運作,就值得認真討論核准編制、職責指引與合理晉升——至少讓「默默貢獻者」有正式位置。

四、外判與自聘要有校內「懂行人」。 供應商可以幫手,但不能代替校本知識。家長、老師、學生三邊都依賴的系統,需要有人長期守着;否則一出問題,前線同事只能在群組裏乾着急,然後把電話打給「那個懂 IT 的人」。

這些建議不一定要一次到位。哪怕先從職稱、工作範圍、培訓預算三樣小事做起,已經是在告訴同事:你的專業被看見了。而政策層面,2017 年那次「納入常額」的討論,也值得被重新拿出來——不是為了翻舊帳,而是因為 AI 時代的校園,比當年更需要穩定的技術隊伍。

設備會折舊,平台會換代;真正難買回來的,是願意留在學校、既懂技術又懂教育節奏的人。香港校園已經走到 AI 門口,是時候認真問一句:我們會否給這些沉默的支撐者,一個配得上他們工作的名分與出路?

—

參考連結

– 教育局「資訊科技綜合津貼」
– 教育局「資訊科技人員支援津貼」(ITSSG)
– 教聯會(2017):要求將 TSS 納入常額編制 — https://hkfew.org.hk/教育政策/item/8296-教聯會要求將「資訊科技技術支援人員-tss-」納入常額編制
– 公務員事務局:總薪級表
– 數字政策辦公室:電腦操作員職系說明

https 經常誤導

搬遷了網站,數據庫,一切正常,但DNS一切換發現開不了網站,奇怪,看log 也正常

vhost正常,搞了一下突然想起https….唉

到後台/usr/local/apache/bin/httpd -S

果然port 443 沒了

autoSSL 開啟來,一切又正常了,https瀏覽器真是多了不少誤導…被誤導了30分鐘

本地部署大模型平台

LangChain‌AI 產品及服務越來越多,每天總有幾個產品推薦,好用的教學又多的但又不見多,假如你也正在找比較有方向的AL平台,不妨試試。

Dify,名字好記DO IT FOR YOU,Web 界面的LLM平台,可以RAG,AI工作流。

RAGFLOW,RAG 的可視平台,也是web 界面,提供RAG 界面,可以自己選擇embedding 模型,rerank 模型,可以直接上傳文件,可以選擇和本地ollama 一起跑。也有chat 和knowledge base

haystack 是一個LLM 框架,提供模塊化,可以自己開發搭建,我還沒有這能力。

cognita 是一個LLM 框架,有在線演示https://cognita.truefoundry.com/

GPUStack 是一個本地運行AI的管理器,這個名氣沒有cherry studio llm studio 之類那麼出名,也是網頁界面。
MaxKB,有點類似RAGFLOW,國內開發的平台,有RAG,chat,AI 流程。
LangChain‌,這個是十分出名AI框架,書籍也有不少。

MCP介紹

AI 的信息每天都在更新,最近比較受歡迎的叫MCP(Model Context Protocol,模型上下文協議)是一種由Anthropic於2024年11月推出的開源標準化協議,旨在簡化大型語言模型(LLM)與外部數據源和工具的互動。MCP伺服器作為該協議的核心組成部分,是一個獨立的程式,負責向LLM提供特定的功能或數據,例如存取檔案系統、資料庫(如PostgreSQL)、外部API(如GitHub、Slack)或執行特定任務(如搜尋、操作日曆)。它的設計理念類似於HTTP協議之於網頁應用,提供了一個統一的「連接器」,讓LLM能夠輕鬆與外部世界互動。

MCP伺服器如何與LLM互動?

MCP採用客戶端-伺服器架構,具體互動流程如下:

  1. 初始化與發現:當MCP客戶端(如Claude Desktop或支援MCP的應用程式)啟動時,它會連接到本機或遠端的MCP伺服器,並詢問伺服器提供的功能(即工具清單)。
  2. 工具註冊:伺服器回應可用工具(如「查詢資料庫」、「獲取當前時間」),客戶端將這些工具註冊到LLM的上下文中。
  3. 需求觸發:當用戶向LLM提出問題或任務(例如「幫我檢查GitHub上的最新提交」),LLM識別出需要外部數據,隨即透過MCP客戶端向對應的MCP伺服器發送請求。
  4. 執行與回饋:MCP伺服器執行任務(例如調用GitHub API),將結果返回給客戶端,LLM再根據結果生成回應。
  5. 雙向通信:與傳統API不同,MCP支援雙向互動,伺服器甚至可以反向利用客戶端的AI能力(例如生成內容),無需額外的API金鑰。

這種標準化互動讓LLM突破訓練數據的限制,實現即時、動態的功能擴展。

用戶的優勢

MCP伺服器為用戶帶來了多方面的便利:

  • 統一整合:無需為每個外部工具開發獨立的整合程式,MCP提供了一個通用的介面,減少開發時間與成本。
  • 靈活性:用戶可以根據需求啟動不同的MCP伺服器,例如連接到個人Google Drive或企業級資料庫,隨時切換LLM提供者(如從Claude換到其他模型)而無需重寫程式碼。
  • 即時性:透過MCP,LLM能存取最新數據(例如天氣、股票價格),解決傳統模型知識過時的問題。
  • 可擴展性:隨著MCP生態系統成長,用戶可從開源社區獲取現成的伺服器(例如Cloudflare、Discord整合),直接應用於自己的工作流。
  • 個人化體驗:MCP伺服器能根據用戶的特定數據(如個人日曆、聊天記錄)提供量身定制的回應。

性能與安全的區別

MCP伺服器在性能與安全方面的設計與傳統方法有明顯差異:

  • 性能:
    • 優勢:MCP伺服器通常運行於本機或私有雲端,減少了遠端API調用的延遲,提升回應速度。雙向通信也讓互動更高效,避免單向請求的多次往返。
    • 挑戰:由於目前多數MCP實現以本機為主,對於需要高吞吐量的企業應用,擴展性可能受限。遠端部署尚在發展中,可能需要額外的基礎設施支持。
  • 安全:
    • 優勢:MCP內建權限控制,每次工具使用需用戶明確授權,確保LLM不會未經許可存取敏感數據。此外,數據傳輸支援TLS加密,符合企業級安全標準。
    • 挑戰:與傳統API相比,MCP的雙向通信增加了伺服器端的安全管理複雜性,例如防止惡意伺服器利用客戶端AI能力。開發者需自行配置防火牆、身份驗證等額外措施。

個人資料如何保護?

MCP在設計上非常重視個人資料的隱私與安全,提供多層保障:

  • 本地優先:大多數MCP伺服器預設運行於用戶設備上,數據無需上傳至雲端,降低了洩露風險。
  • 明確授權:每次LLM調用MCP伺服器工具時,系統會提示用戶確認,確保敏感操作(如讀取檔案、發送郵件)在掌控之中。
  • 模組化控制:伺服器功能被限制在明確定義的工具範圍內,LLM無法隨意存取未授權的數據。例如,一個GitHub MCP伺服器只能存取指定的儲存庫,而非整個帳戶。
  • 加密與日誌:數據傳輸使用TLS加密,同時支援集中式日誌記錄,讓企業用戶能追蹤所有AI存取行為,符合合規性需求(如GDPR、HIPAA)。
  • 開源透明:作為開源協議,用戶和開發者可審查MCP伺服器的程式碼,確保無隱藏的後門或數據收集行為。

那究竟如何用呢,我剛剛在網上看到了一個使用Cherry Studio + MCP的 教學,這還是公測版,目前LLM studio 和ollama 還是未能支持MCP的

https://mp.weixin.qq.com/s/a8XlAw4wrdJpKGVUWneaqg

https://github.com/punkpeye/awesome-mcp-servers?tab=readme-ov-file

這是一個例子,可以根據用戶指令去幹事,這裡可以看到你可以拼接不同的服務到大模型或者不同的大模型API 上去,那就不用擔心處理的不夠好。找個時間測試一下。