作者: admin

  • 【生產力升級,飯碗降級?Barclays 裁員 5,000 人,AI 究竟令邊個增長?】

    作者:SRAM

    AI 可以提高效率、降低成本、推動增長——呢套說法,企業聽咗幾年。當效率開始以減少職位呈現,員工感受到嘅「增長」,可能同管理層好唔一樣。

    Barclays 表示,今年將削減約 5,000 個職位,相當於員工總數約 5%,並透過 AI 等技術降低固定成本。呢次裁員屬於整體組織及成本重整,不能將每個被削減職位都當成由 AI 直接取代。

    但值得討論嘅問題已經浮現:當公司可以用更少人完成相同工作,節省落嚟嘅資源會流向邊度?

    企業可以將資源投入新服務、擴大業務,創造另一批職位;亦可以主要用來改善盈利。兩種選擇,對公司報表同社會就業帶來嘅結果,可以相差好遠。

    單一企業裁員,當然不足以證明整體失業率會因 AI 上升。真正需要留意嘅係轉型速度:新工作出現得夠唔夠快?原有員工有冇時間同機會轉過去?公司口中嘅「人才升級」,有冇實際培訓同職位配合?

    對企業主而言,採用 AI 嘅價值亦值得重新衡量。如果只計慳到幾多人工,就容易忽略服務質素、團隊經驗,以及擴大生意嘅可能性。

    如果 AI 帶來嘅增長寫喺企業盈利上,轉型成本卻落喺員工身上,呢場科技進步應該點樣分配成果?

    出處:Reuters|Barclays to slash 5,000 jobs in AI-powered cost-cutting drive;本文觀點為獨立編輯分析。

  • 【網站仲開到,就代表冇事?PHP2Shell 揭開「用得就唔使理」嘅維護迷思】

    作者:SRAM

    首頁正常、表格照收、後台登入到。對好多企業而言,呢幾樣已經足以判斷網站「冇問題」。

    PHP2Shell 事件提醒我哋,網站正常運作,同底層軟件安全,係兩回事。

    PHP 官方確認,兩個嚴重漏洞可能容許未經登入嘅攻擊者遙距執行程式碼,並已發布修補版本。The Verge 持續追蹤事件,報道部分網站及服務因風險而暫時下線。

    對用 WordPress 或其他 PHP 系統嘅企業而言,檢查範圍需要深入到伺服器環境。更新頁面內容、主題或外掛,未必已經處理埋實際運行網站嘅 PHP 版本。

    而臨急先升級,亦可能遇上另一個積存已久嘅問題:舊外掛、自訂功能同新版環境未必相容。平日延後嘅維護,最終可能集中喺一次緊急事故入面處理,令企業同時面對安全風險與停機壓力。

    從企業管理角度看,網站上線之後仍然需要持續投入。系統清單、更新安排、備份驗證同事故應變,每一項都影響網站出問題時,業務可以幾快恢復。

    維護做得好,平日往往冇乜感覺;等到出事先發現缺口,代價就可能涉及查詢、訂單同客戶信任。

    如果今日再有一個重大漏洞公布,你間公司係即刻知道由邊個處理,定係先開始問:個網站究竟邊個跟?

    出處:PHP 官方安全更新 · The Verge|PHP2Shell 事件追蹤;本文觀點為獨立編輯分析。

  • 【密碼冇交畀 AI,帳戶就安全?1Password 新工具帶出更大嘅授權問題】

    作者:SRAM

    你可能唔會將網店後台密碼交畀陌生人。但如果 AI 話可以幫你處理訂單、整理帳單,你會唔會按下「批准登入」?

    1Password 推出嘅 1Password for Agents,正正處理 AI 代辦工作時嘅登入需要。按照官方介紹,用戶先喺自己裝置確認授權,再由 1Password 將登入資料填入表格,AI 毋須看到或儲存密碼。

    呢個設計有助減少密碼被複製、保留或意外暴露嘅機會。不過,當 AI 成功登入,另一組問題先正式開始:佢可以睇到幾多資料?可以修改乜?涉及付款、刪除或對外發布時,仲需唔需要再問你?

    密碼保密與操作授權,係兩個都需要處理嘅環節。即使 AI 唔知道密碼,已登入嘅工作階段仍然可能容許佢讀取資料或執行操作,實際範圍取決於帳戶權限同服務設計。

    最近 PHP 事故亦提醒我哋,保安需要逐層檢視:登入方式、帳戶權限、應用程式同伺服器,各自都有需要管理嘅風險。保護好其中一層,其他層面仍然要有人把關。

    AI 愈能夠幫手做事,我哋就愈需要清楚界定「幫手」嘅範圍。

    下次你批准 AI 登入之前,你清楚自己授權佢做一件事,定係打開咗整個帳戶嘅大門嗎?

    出處:1Password|1Password for Agents 官方公布 · PHP 官方安全更新;本文觀點為獨立編輯分析。

  • 【AI 愈聰明,網站愈危險?企業正被拉入一場補漏洞競賽】

    作者:SRAM

    你用 AI 寫電郵、整簡報,有人就用 AI 尋找網站漏洞。當同一項技術同時落入防守者與攻擊者手上,網絡保安嘅勝負,愈來愈取決於一個字:快。

    Reuters 訪問多名網絡保安專家指出,AI 正加快軟件漏洞被發現嘅速度,未來可能再出現類似今次 PHP 事故引發嘅服務中斷。漏洞被找出,到企業完成修補之間,留畀防守一方嘅時間正受到壓縮。

    對企業而言,真正棘手嘅地方係:發現問題可以愈來愈自動化,處理問題卻仍然有大量現實限制。更新之前要測試、系統之間有依賴,部分舊程式甚至已經冇人熟悉。攻擊者只需要找到一個入口,企業卻要確保每一個重要入口都有人管理。

    從營運角度看,AI 同時亦有機會幫企業及早找出積存多年嘅問題。但要將呢個優勢變成保護,企業需要清楚知道自己用緊乜、邊個負責更新,以及出事時由邊個決定暫停服務。

    「個網站一直都用到」能夠證明過去冇明顯故障,卻不足以回答下一次漏洞出現時,公司有幾快反應。

    當 AI 可以加速找出漏洞,你間公司嘅維護流程,跟得上呢個速度嗎?

    出處:Reuters|AI-discovered bugs may soon trigger fresh disruptions, cyber experts say;本文觀點為獨立編輯分析。

  • PHP 重大安全更新:兩項漏洞可致遠端執行程式,網站應如何處理?

    優先安全通告|官方修補發布:2026 年 10 月 21 日|本文整理:2026 年 10 月 22 日。

    發生了甚麼事?

    PHP 官方公布 CVE-2026-109618 及 CVE-2026-109619,涉及記憶體不足處理及殘留全域狀態,特定情況下可讓未經登入的攻擊者在伺服器執行程式。提供網頁請求的 PHP 環境均應立即評估;不只 WordPress,App API 及其他 PHP 系統亦要檢查。

    不是「升到 8.3」就足夠

    官方修補版本為 PHP 8.5.12、8.4.27、8.3.36、8.2.35;應安裝所用受支援分支的已修補版本或其後更新。若主機商採用回補修補,需取得對應套件及修補證明,不能只看控制台顯示的主版本。PHP 8.1 或更舊版本應向供應商確認修補及遷移安排。

    網站負責人現在應做甚麼?

    一、盤點官網、測試站、App API、排程及各 PHP 執行環境,向主機商核實完整版本及修補狀態。二、保留資料庫、檔案備份和可疑存取紀錄,安排緊急修補;由管理員重啟受影響工作程序,確認沒有舊程序仍在服務。三、驗證登入、表格、付款及 App 接口等重要功能,持續檢查異常帳戶、檔案和紀錄。

    防火牆可以代替更新嗎?

    不可以。官方指出,臨時緩解措施不構成完整解決方案。未能即時更新時,應由主機商或安全團隊評估限制暴露面的臨時安排;若懷疑已入侵,另需進行事故調查,更新 PHP 不等於已清除入侵痕跡。

    以上為一般事件應對清單,並非 ATOM 已完成你現有網站或 App 的修補證明;本次只更新示範網站內容,沒有改動主機 PHP 設定。

    資料來源:PHP 官方安全公告(2026-10-21)。本文為 ATOM 編輯摘要及應用觀察;供應商公告、服務條款及可用地區如有更新,以官方資訊為準。

  • Google Cloud 引入 OpenAI 模型:企業 AI 選型更重視成本與治理

    新聞日期:2026 年 10 月 21 日|整理日期:2026 年 10 月 22 日。

    今次公布了甚麼?

    Google Cloud 宣布將 OpenAI 模型加入其模型平台,包括 GPT-6 Astra、GPT-6.1 Sol 及 GPT-6 Luna。按公告,目前正向部分企業客戶推出私人預覽,並非已向所有用戶全面開放。

    對企業採用 AI 有甚麼意思?

    同一業務可能包含客服分類、文件摘要及複雜分析,不同任務未必適合使用同一模型。多模型選擇提供彈性,但仍需以實際測試比較準確度、回應時間及整體成本。

    ATOM 觀察:先訂驗收標準,再接駁系統

    導入前,先定義哪些資料可以交予模型、哪些動作必須由人批准,以及如何留下審計紀錄。可先從不含敏感資料的內部知識搜尋或文件整理開始,保留人工覆核,再考慮接駁 CRM 或報價流程。

    資料來源:Google Cloud 官方公告(2026-10-21)。本文為 ATOM 編輯摘要及應用觀察;供應商公告、服務條款及可用地區如有更新,以官方資訊為準。

  • Atlas 新一代機械手:實體 AI 如何由示範走向實際工作?

    技術觀察|整理日期:2026 年 10 月 22 日。以下討論官方已公開的技術,並不代表產品於今日推出。

    機械手的進展在哪裏?

    Boston Dynamics 介紹 Atlas 新一代機械手,採用 13 個自由度及直接驅動設計,目標是在抓取能力、強度、耐用性和可維修性之間取得平衡。設計亦考慮高擬真模擬,方便把強化學習訓練轉移到實體機械人。

    ATOM 觀察:落地先看工作流程

    企業評估機械人,應先選定一項可重複、可量度的工作,例如搬運或物件整理,再驗證成功率、例外處理及安全邊界。展示影片不等於能直接在每個場地部署。

    除了硬件,亦要規劃派工介面、權限、操作紀錄及與庫存或管理系統的整合。先用小範圍試點取得數據,再決定是否擴大。

    資料來源:Boston Dynamics:Robot Hands for Modern AI and Real Work。本文為 ATOM 編輯摘要及應用觀察;供應商公告、服務條款及可用地區如有更新,以官方資訊為準。

  • 網上報價表,應該問客人甚麼?

    第一步先選服務

    不同服務需要不同資料。先讓客人選擇網站、App、設計或其他服務,再顯示對應問題,可減少無關欄位。

    把需求問得具體

    例如網站可問語言、頁面規模與必要功能;系統開發則可問使用角色及主要工作流程。讓客人選擇「需要建議」,可以照顧仍在探索階段的人。

    預算與時間提供範圍

    預算及完成時間有助判斷工作範圍,但不一定要客人填寫精確數字。以合理選項收集意向,再由團隊確認細節。

    留下清楚的下一步

    提交前讓客人檢查摘要,提交後說明資料是否成功收到,以及接下來如何跟進。如要提供即時計價,必須先建立清楚的計價規則與適用條件。

    只收集跟進所需的資料

    表格應清楚說明資料用途,避免一開始要求過多敏感或無關資訊。通知、儲存、存取權限及保留安排,也需要在正式上線前確認。

    如正準備相關項目,可透過 ATOM 的網上報價表提供基本需要,作為進一步討論的起點。

  • 手機 App 還是網上系統?由使用場景開始選擇

    先看使用者與使用頻率

    如果使用者只是偶爾查資料、提交表格或處理管理工作,可以先評估透過瀏覽器使用的網上系統。若有持續使用、手機操作或裝置整合需要,則進一步評估 App。

    列出真正需要的功能

    通知、相機、定位、離線操作及裝置整合,均需要按實際情況評估。網頁與 App 在不同平台上的能力及限制各有差異,不宜只按功能名稱作決定。

    不要漏掉後台與資料流程

    使用者看到的介面,只是項目的一部分。資料如何新增、誰可以修改、管理層需要甚麼報表,以及是否串接現有系統,同樣需要在規劃初期釐清。

    可以由核心流程開始

    先定義最重要的一個使用流程,再決定第一階段的功能。將預算、維護、平台發佈及日後擴展一併考慮,較容易選出適合企業的開發方式。

    如正準備相關項目,可透過 ATOM 的網上報價表提供基本需要,作為進一步討論的起點。

  • 網站重做前,先整理這五項資料

    先說清楚重做的原因

    網站過時、手機難用、查詢流程不順,背後需要處理的問題各有不同。先列出最想改善的三件事,並說明主要客人是誰、希望他們在網站完成甚麼操作。

    整理可沿用的內容

    把公司介紹、服務、產品、案例、圖片及品牌檔案集中整理,標記哪些需要更新。舊網站仍然有價值的資料,可以在重整架構時保留。

    列出必要功能與參考

    將必需功能與日後才考慮的功能分開。提供參考網站時,說明喜歡的是排版、導覽還是操作方式,比單純列出網址更容易溝通。

    確認網址、後台與主機權限

    整理域名、寄存、網站後台及分析工具的管理資料,確認由誰負責。新舊網址如有變更,需要一併規劃轉向及切換;亦應辨認是否與公司電郵共用相關設定。

    預先確認預算、時間及分工

    列出預算範圍、期望上線日期,以及內部負責確認設計和提供內容的人員。將文案、圖片、翻譯、測試與維護的責任說清楚,有助安排合理進度。

    如正準備相關項目,可透過 ATOM 的網上報價表提供基本需要,作為進一步討論的起點。