AWS Re:cap 02: 裝置端多模態 AI 與智慧城市實踐

裝置端多模態 AI：從三日原型到城市級公共能力

核心主張

能辨識一盤食物並估算營養的手機應用，看起來像小產品。實務上它同時觸及影像理解、知識檢索、裝置端推論、隱私保護、公共衛生與長期營運。政府與大型企業真正該學的，不是三日能做完多少功能，而是如何在第一天就把範圍、風險、資料與問責邊界寫清楚。

決策視角

本簡報以公共價值為主線，串連香港智慧城市、數位政府、資料治理、北部都會區、健康與醫療創新及區域協作。技術選擇不以單一品牌為中心，而是依監管、資料駐留、延遲、成本、供應鏈韌性、人才能力與退出條件組裝。

帶走重點

聽眾將帶走可重用方法：把展示型 AI 拆成可接受範圍的工作包；建立裝置端與雲端的分工；以拒答、不確定性與人工覆核控制健康風險；再用證據鏈、階段閘門與服務指標，把原型升級為可審計、可營運、可擴展的正式能力。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

為何熱量辨識能對智慧政府說話

小場景的放大效應

一盤食物的照片，含有光線、遮擋、混搭菜式、份量、地域飲食與個人偏好帶來的不確定性。這與政府影像辨識必須處理的模糊身份證件、現場巡查、災害照片、農作物病蟲害影像非常相似。小型健康應用因此是理想的工程沙盒：能以低成本暴露 AI 系統最難處理的邊界。

公共服務有何不同

互聯網產品可以用快速更新修補問題。政府服務必須同時承擔可用性、可解釋性、公平性、投訴處理與供應商延續。若模型分錯類、雲端離線或資料外洩，影響不只是單一使用者體驗，而可能成為公共信任與治理風險。

轉換方法

把熱量應用當成縮小版的數位政府系統。逐項練習身份、授權、資料最小化、知識來源、模型版本、人工否決與降級服務。基礎到位後，同一架構可安全重用於學校膳食、基層健康教育、長者服務及偏遠地區離線外展。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

從政策到產品：五年規劃如何變成工程待辦

策略轉譯

香港首份經濟社會發展五年規劃，把創新科技、民生、北部都會區、區域合作、綠色轉型與安全治理放在同一發展框架。工程團隊必須把這些宏觀方向轉成具體需求：減少民眾重複提交、提升弱網可用性、縮短辦理時間，並讓跨部門協作具備清楚授權與可追溯性。

需求層次

第一層是公共成果，例如健康教育覆蓋、服務可及性與前線負擔。第二層是業務能力，例如影像預篩、可信資料檢索與人工轉介。第三層是技術組件，例如裝置端模型、API、向量索引、身份平台與日誌。這樣可避免先買平台再找用途。

落地紀律

每個政策目標都必須對應問責擁有者、服務對象、可量測指標、資料依據、預算上限與退出條件。若功能無法說明如何改善公共成果，或只能用模型準確率證明價值，就不應進入正式採購與大規模部署。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

三日衝刺第一原則：凍結問題，不凍結學習

範圍邊界

三日只驗證一條完整旅程：拍攝餐盤、品質檢查、食物候選、份量線索、營養檢索、風險標示與結果呈現。明確排除疾病診斷、個人治療建議、全菜系覆蓋與臨床級精度，避免團隊被不可能的承諾拖垮。

假設清單

衝刺開始前寫下可被推翻的假設：單張照片是否足夠；裝置端模型能否在目標手機記憶體內運行；使用者是否理解區間估算；弱網下哪些功能仍可用。每個假設都需要測試方法與停止條件。

學習產出

三日成功不是功能數量最多，而是能回答值不值得繼續、最大風險在哪、下一輪需要什麼資料與專家。結束時交付範圍聲明、測試紀錄、失敗樣本、模型與知識版本、成本估算、風險登記冊與下一階段決策建議。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

第一日：一次寫清需求、資料與安全底線

上午工作

用半天完成使用者旅程、關鍵角色與錯誤後果分析。營養教育使用者、校園管理者、健康專業人員與系統管理員看到的資訊與權限不同。任何高風險提示都必須預先定義誰可檢視、誰可變更、誰負責回覆投訴。

資料準備

只使用公開、合成、匿名化或正式授權的影像與營養資料。建立最小資料字典，記錄菜名、地域別名、估算單位、來源日期、適用範圍與限制。原型階段不收集無關人臉、位置、裝置識別碼或完整健康紀錄。

安全閘門

完成威脅建模與濫用情境，包括惡意影像、提示注入、知識庫投毒、模型檔替換與日誌外洩。若無法做到敏感資訊遮罩、傳輸加密、版本鎖定與基本稽核，原型只能在隔離環境示範，不得接觸真實市民資料。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

第二日：讓裝置端推論跑起來，也讓失敗看得見

推論管線

先檢查影像清晰度、亮度、構圖與敏感內容，再把影像交給裝置端多模態模型，產出有限數量的食物候選。輸出應包含候選名稱、可見證據、信賴區間與需要重拍的角度，而不是一個看起來確定的單一答案。

裝置預算

按不同手機記憶體、處理器、作業系統與電池狀況建立裝置矩陣。逐項量測模型載入時間、首次推論、持續推論、峰值記憶體、耗電與表面溫度。若高階手機能跑、前線常用裝置不能跑，必須重新評估公共服務價值。

失敗可視化

分類並保留遮擋、反光、混搭菜式、醬汁、餐具比例失真與本地菜名差異等案例。團隊每天檢視錯誤類型分布與新出現的邊界，而不是只挑選成功照片展示。可重複的失敗分類，比單一精修結果更有工程價值。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

第三日：產品化、評測與可交付證據

體驗收斂

最後一天把功能收斂成可理解操作：拍攝指引、處理狀態、結果區間、資料來源、風險提示、重拍與人工協助。介面不得把模型信心偽裝成醫療可信度，也不得用精確小數製造虛假確定感。

最小評測

建立包含正常、困難、超出範圍與惡意輸入的測試集。除食物候選命中率外，還要測拒答是否正確、營養引用是否對應、敏感資訊是否外洩、離線模式是否完整、延遲是否可接受，以及出錯後系統能否安全恢復。

交付包

示範版本應連同模型卡、資料卡、版本清單、架構決策紀錄、測試結果、已知限制、成本假設與後續工作一併交付。決策者看到的不只是畫面，而是判斷風險、預算與可持續性的完整證據。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

裝置端、雲端與混合推論：按問責邊界選擇

何時適合裝置端

需要離線運作、低延遲、資料最小化或現場即時回應時，裝置端推論優勢明確。它可先做影像品質檢查、敏感資訊遮罩、初步分類與簡單規則，減少原始資料外送。但裝置碎片化、模型更新與算力限制，會提高測試與支援成本。

何時適合雲端

需要大模型能力、集中知識更新、複雜檢索或跨部門服務共享時，雲端較易統一治理與擴展。資料駐留、網路依賴、每次推論成本、供應商故障與跨境資料流仍須明確處理。雲端不應成為所有資料的預設去處。

混合原則

最務實的設計通常是裝置端先過濾與摘要，僅在同意且必要時上傳最少資料；雲端處理需要更強能力的任務；斷線時回退到離線知識與保守提示。每一段都需要清楚的 SLO、逾時、重試、降級與回滾規則。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

模型量化不是壓縮作業，而是服務設計

工程取捨

量化可降低模型大小、記憶體與推論時間，但也可能影響細粒度辨識與語言生成穩定性。不要只比檔案大小。要對照真實任務，檢查菜式候選、拒答、地域別名與混搭菜式描述是否退化。

分群策略

按裝置能力建立高、中、低配置，選擇不同模型大小、影像解析度、上下文長度與並行度。低階裝置可用兩段流程：先用輕量模型篩選，需要時才啟用更強能力，讓不是每台裝置都承擔相同資源成本。

發布經驗

量化版本必須有自己的識別碼、自己的評測與回滾路徑。灰度發布先從內部測試裝置開始，再擴大到真實環境的一小部分；觀察當機、耗電、升溫、延遲與任務成功。只看準確率，往往錯過使用者最先感受到的效能問題。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

影像品質閘門：先判斷能不能看，再判斷看到什麼

預先檢查

好的辨識管線不應把每張照片直接送進模型。先判斷是否模糊、過暗、反光、裁切不全、距離太遠或含有多盤食物，再給出具體拍攝指引。這一步減少後續錯誤，也節省裝置端電池與雲端成本。

敏感遮罩

餐盤照片也可能拍到人臉、員工證、病歷、地址或螢幕內容。系統應先在裝置端偵測並遮罩不必要資訊；使用者預覽後再決定是否繼續。遮罩結果也必須進入測試，避免過度遮罩破壞食物判斷。

可行動回饋

不要只顯示「影像不合格」。指出原因與下一步，例如靠近餐盤、補光、去掉包裝、由上方重拍，或放置已知尺寸的參照物。具體回饋把模型限制轉成使用者跟得上的流程設計。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

食物候選辨識：從單一答案到證據集

候選輸出

對相似菜式、地方名稱與混搭餐盤，模型應輸出少量排序後的候選，並說明可見食材、烹調方式與不確定部分。使用者可修正候選，但修正不得直接進入正式知識庫，必須經過品質流程。

分類體系

建立菜式、食材、烹調方式、份量單位與飲食文化的分層詞彙。把「叉燒飯」拆成主食、蛋白質、醬汁與配菜，有助營養估算與跨地域對應，也讓新菜出現時可重用既有組件。

偏差控制

評測集必須覆蓋粵菜、少數族裔飲食、素食、學校膳食、長者軟食與不同餐具。若資料只來自網紅照片或標準擺盤，模型會低估真實場景的遮擋與多樣性，並對特定社群落出系統性錯誤。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

份量估算：熱量誤差的最大來源

為何困難

食物辨識正確不等於熱量正確。單張二維照片缺少深度、密度與容器尺寸資訊。同一碗飯因拍攝角度看起來可以差很多；醬汁、油脂與隱藏食材更難從表面判斷。

降低誤差

要求由上方與側面各拍一張，使用標準餐具或參照卡，詢問碗盤尺寸，並讓使用者選擇小、中、大或克數區間。系統應保存估算方法，而不只是最終數字。

結果表達

輸出宜優先採用區間、主要假設與敏感因子，例如「若包含兩湯匙醬汁，上限估算會上升」。對無法合理估算的混搭菜式，拒答精確熱量數字，改提供食物組成與一般健康教育資訊。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

知識庫與模型分離：讓每個答案可追溯

為何分離

模型擅長理解影像與語言，但不應憑記憶編造營養數字。營養主資料、過敏原、單位換算與政策提示應放在可版本化的知識庫。模型只負責提出查詢、整理結果與說明限制。

來源治理

每筆紀錄必須記載發布機構、更新日期、適用地區、食物狀態、份量單位與授權條件。來源衝突時保留差異，不要把多個數值平均成看似權威的答案。過期或無來源的資料不得用於高風險提示。

更新機制

知識更新與模型更新採不同節奏與審批流程。小幅資料修正可快速發布，但影響過敏原、健康警示或法律用詞的變更需要雙人覆核、測試與回滾。這種解耦降低每次更新的風險與成本。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

不確定性、拒答與人工覆核

安全設計

政府 AI 的成熟度不是答得更多，而是知道何時不答。當影像品質低、候選差距小、知識來源缺失，或使用者詢問疾病治療時，系統應停止給出精確結論，清楚說明限制，並引導重拍或專業協助。

人工否決

人工覆核不是裝飾。流程必須定義哪些輸出需要覆核、覆核者需要看到什麼證據、必須多快回覆，以及已發布結果能否撤回或更正。高風險節點的人員必須有明確否決權，不得被績效指標逼著快速放行。

評測方法

拒答也必須量測。錯誤拒答降低可用性；該拒不拒增加風險。測試集需要正常、模糊、超出範圍、對抗及健康關鍵情境，並分開計算適當作答、適當拒答與錯誤自信的比率。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

健康安全邊界：教育工具不得冒充醫療系統

使用限制

應用定位為健康教育、研究示範與一般飲食認知。不診斷疾病、不給治療建議、不調整用藥、不做個人醫療決策。介面、宣傳、資料保存與人員培訓必須一致。免責聲明不能一面宣稱低風險，實際流程卻鼓勵醫療依賴。

高風險處理

若使用者提到嚴重過敏、低血糖、吞嚥困難、妊娠、腎病或類似狀況，系統不得憑照片判斷安全。應提供清楚、非診斷性的風險提醒，並建立轉介至合資格專業人員或緊急服務的路徑。

問責證據

每次輸出保留模型版本、知識來源、規則版本、信賴度、拒答原因與使用者修正。若出現投訴或疑似傷害，機構能重建當時系統看到什麼、依據什麼、誰做最終決定。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

離線優先：弱網地區仍需要基本服務

基本包

離線模式至少保留拍攝指引、影像品質檢查、敏感遮罩、常見食物候選、基本營養教育與緊急風險提示。需要即時資料或專業覆核的功能應清楚標示暫時無法使用。舊資料不得呈現為最新結果。

同步策略

恢復連線後，只上傳必要摘要、錯誤碼與經同意的樣本。使用佇列、重試、去重與衝突處理，避免同一事件提交兩次。同步失敗不得阻擋使用者查看已完成的離線結果。

演練要求

測試不只是關掉 Wi-Fi。還要模擬高延遲、頻繁斷線、低電量、儲存不足與時鐘偏差。對偏遠健康外展、災害現場或大型活動，離線能力是服務韌性，不是附加項。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

電池、熱管理與可持續使用

量測情境

在連續拍攝、背景下載、模型更新與長時間推論下量測耗電與升溫。一次性順暢示範不代表日常可用，因為過熱會觸發降頻，低電量模式也可能限制背景工作與相機能力。

控制措施

使用較低解析度預檢、動態批次、按需載入模型、快取常用知識，以及閒置時更新。高耗能任務應告訴使用者為何需要，並允許延後到充電或較佳網路時再做。

公共採購視角

驗收應在指定裝置矩陣上量測每任務能耗、峰值溫度、平均延遲與當機率。若供應商只提交旗艦裝置的實驗室結果，不能證明服務能覆蓋前線常用設備。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

證據鏈：把每次 AI 動作變成可審計事件

事件內容

完整事件包含去識別化輸入摘要、影像品質結果、模型與提示版本、知識檢索來源、工具調用、規則命中、人工覆核、最終輸出、延遲與成本。不是所有原始內容都需長期保存。重點是能重建決策。

保存策略

按資料分類設定不同保存期，並把安全事件、模型品質、業務交易與除錯日誌分開。高敏感原始影像可在裝置端處理後刪除，只保留雜湊、特徵摘要或經核准的匿名樣本。

稽核價值

證據鏈支援投訴調查、版本回滾、偏差分析、供應商驗收與成本核對。沒有證據的 AI 系統，即使平均準確率很高，也無法在政府場景承擔問責。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

從 PoC 到正式上線：六道階段閘門

閘門設計

依序通過六道閘門：問題價值、資料合法性、技術可行性、安全與隱私、營運就緒、公共問責。每道閘門有必要文件、量化門檻、批准角色與退回條件，避免原型因高層關注而跳到全面上線。

停止條件

若沒有合法資料來源、無法建立人工覆核、離線時沒有安全降級、供應商不提供必要版本資訊，或三年成本超出可負擔範圍，專案應暫停或縮小用途。停止不是失敗，而是治理成熟。

擴展方法

先在低風險輔助場景與受控人群試行，觀察錯誤後果與營運負擔，再擴展到更多地區與裝置。每次擴展都重新評估資料、容量、公平與支援能力。不要假設先前結論仍然成立。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

服務指標：從模型分數到公共價值

公共成果

核心指標包括服務辦理時間、一次辦結率、重複提交減少、前線工作量、弱網可及性與民眾滿意度。這些指標回答技術是否真正改善服務，而不只是多了一個新介面。

模型與工程

模型層追蹤任務成功、引用命中、錯誤自信、適當拒答與敏感資料外洩。工程層追蹤 p95 延遲、可用性、變更失敗率、平均修復時間、裝置當機與災備結果。

治理與成本

治理層追蹤高風險人工覆核、可追溯率、政策攔截與投訴結案。成本層追蹤每次推論成本、單位吞吐、閒置資源與三年 TCO。每個指標都需要擁有者與觸發行動，避免儀表板只供展示。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

成功案例：一百多項數位政府與智慧城市措施

成果背景

香港完成全政府電子服務審視，並在二〇二五年底前推進一百多項數位政府與智慧城市措施，運用大數據、人工智能、區塊鏈及地理空間分析改善公共服務。此案例的成功不是單一技術，而是共用平台、跨部門協調與便民目標的組合。

可重用底座

政府雲、大數據分析平台、數位身分、共享區塊鏈、聊天機器人服務與統一服務入口，讓部門不必每次從零建設。共用能力減少重複投資，也為安全、身份、日誌與服務可用性設定一致基線。

對 AI 原型的啟示

若熱量應用要進入公共衛生場景，應接上既有身份、同意、雲端與資料交換能力，而不是再建一座孤島。成功案例說明，先建立可治理的共用底座，再容納多供應商方案，比追逐單一超級平台更可持續。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

成功案例：數位身分從登入工具升級為服務入口

採用規模

香港一站式 iAM Smart 數位身分平台已累積超過四百萬登記使用者，支援超過一千三百項服務與電子表格，並取得資訊安全與私隱資訊管理相關國際標準認證。規模化的關鍵是身份、簽署、填表與文件能力可被多項服務重用。

設計啟示

公共 AI 不應自行管理密碼、身份證件複本與完整個人資料。透過可信身份平台取得最少必要屬性，並對高風險操作使用加強認證，可減少重複收集與冒充。匿名健康教育功能不應強制登入。

下一步銜接

企業數位身分平台預計於二〇二六年底推出，政府對企業及企業對企業服務可進一步使用企業驗證、數碼簽署、預填與文件錢包。若 AI 代理代表機構行事，授權範圍與簽署證據會比自然語言能力更重要。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

成功案例：CDEG 改善一次辦事

運作方式

CDEG 讓部門或獲授權機構在市民同意下交換已核實資料，每月約處理二百萬次資料交換。它把「不要再交一次」從口號變成受控流程，並保留資料來源、目的與授權關係。

對健康應用的教訓

若校園或社區健康服務需要年齡組別、服務資格或既有預約狀態，應透過同意交換取得必要欄位，而不是要求上傳整份證明。營養照片與健康資料仍應分開處理，避免便利擴大資料連動。

治理重點

同意必須具體、可理解、可撤回且有時限。資料接收方不得把一次性授權延伸到模型訓練或商業用途。每次交換都需要目的、最少欄位、保存期與例外通報，才能維持市民信任。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

成功案例：開放數據從供給走向使用

規模進展

截至二〇二五年十二月，公開數據下載量由二〇一九年約五十億次增至超過八百億次。平台提供五千七百多個數據集、約一百一十個 API，並有二千五百多個資料提供者參與。這說明穩定供給、機器可讀與持續更新能形成使用生態。

品質重於數量

AI 應用需要資料字典、更新頻率、授權、血緣、品質規則與聯絡人。上傳檔案不等於可用。對營養、交通、環境等資料，版本與時間戳尤其重要，因為使用過期資料可能造成真實風險。

實施建議

指定資料產品擁有者，追蹤 API 可用性、欄位變更、錯誤回報與下游影響。對外開放時提供樣本、限制、變更通知與歷史版本，讓多品牌雲端、學術與企業團隊能安全重用。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

成功案例：AI+ 公共服務從工具目錄開始

務實入口

香港以 AI 工具與方案目錄覆蓋七類常見工作：數碼人客服、會議摘要、文件處理、寫作、流程自動化、創意推廣與數據分析。論壇、研討與配對活動協助部門了解可用選項。這比要求每個部門自己研究每個模型更有效率。

多供應商治理

目錄不應只列功能與價格，還應標示資料去向、部署模式、模型來源、日誌能力、可攜性、支援等級與禁用場景。同一用途至少保留一個替代方案，並用共同測試集比較，避免品牌認知取代證據。

落地次序

先從草稿、摘要、分類等低風險內部工作開始，要求人員確認後才外發；再逐步處理跨部門流程與市民互動。每個工具都需要退出路徑、資料匯出與提示版本管理。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

北部都會區：把 AI、教育與健康創新放進空間規劃

發展定位

北部都會區把創新科技、專上教育、健康與醫療創新視為重要功能，並強調規劃先行、基建帶動、產業驅動與以人為本。未來五年規劃提出超過七萬個住房單位及一百萬平方米經濟樓面，為產業與社區共同成長創造容量。

技術機會

大型新區可把資料管線、數位身分、物聯網、邊緣運算、綠色建築與公共衛生服務納入基礎設計，而不是事後拼接。連接大學城、科研設施、產業園與社區，也有助閉合真實場景測試與人才培養的循環。

治理提醒

living lab 不能成為無限制收集資料的藉口。每個試點都需要清楚範圍、居民溝通、退出安排與獨立評估。新區技術應支援開放接口與多供應商營運，避免城市基礎設施長期鎖定單一方案。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

河套與跨境創新：規則互通比網路互通更難

協作價值

河套深港科技創新合作區以一區兩園推動研發、測試、轉化與產業化，並與新田科技城共同構成北部創科引擎。健康科技可結合香港研究、法治與國際連通，以及深圳工程、製造與市場能力。

資料邊界

跨境合作先劃資料類別與流向，區分公開資料、一般業務資料、個人資料、重要資料與研究樣本。對每一類把法律依據、儲存位置、存取角色、加密、審批與刪除寫清楚。合作協議不能取代具體控制。

標準合同經驗

GBA 個人資訊跨境流動標準合同於二〇二三年開始先行，並自二〇二四年十一月起擴展至大灣區各行業。工程團隊仍須把合同要求落到 API 欄位、日誌、權限與事故通報。法律文件本身不會自動變成安全系統。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

智慧健康：從醫院數位化到社區預防

政策方向

五年規劃把基層醫療、慢性病防治與早診早治、智慧醫療、健康資訊基建及中西醫協作列為優先。智慧健康因此不能只集中在大型醫院，也必須支援社區、長者、照顧者與弱網地區的持續服務。

應用層次

低風險層可提供健康教育、預約、提醒與一般飲食資訊。中風險層可協助專業人員整理資料與發現異常。高風險診治必須留給合資格人員。不同層次使用不同資料、模型、覆核與驗收標準。

熱量案例的位置

裝置端餐盤辨識最適合放在健康教育與行為紀錄層，協助使用者理解食物組成與份量，而不是做疾病判斷。任何連接電子健康紀錄的做法，都必須另行完成臨床、安全、隱私與專業責任評估。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

智慧鄉村與遠端服務：小模型也能產生高公共價值

場景需求

智慧鄉村試點包括公共 Wi-Fi、遙距醫療、電子支付、非法傾倒與水浸偵測，以及由機械人與人工智能輔助的山火早期發現。這些場景共通點是網路不穩、維運資源有限，以及現場回應時間重要。

架構選擇

把初步偵測放在邊緣裝置，保留本地規則與離線運作。中央雲端處理模型管理、跨區分析與專家協作。裝置必須支援遠端盤點、更新、回滾與停用，並在通訊中斷時保存事件序列。

營運經驗

遠端部署最常被忽略的是電力、防水、防塵、備件、現場培訓與告警疲勞。採購評分應包含五年可維護性與更換週期，而不只是模型準確率與一次性報價。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

多雲與混合雲：不綁品牌，要綁標準

選型哲學

不同品牌雲端服務在模型生態、資料分析、邊緣管理、安全與區域覆蓋上各有長處。政府不必平均拆分工作負載，而應按資料駐留、服務等級、成本、能力成熟度與既有人才選擇最適合的位置。

可攜設計

使用容器、標準 API、基礎設施即程式碼、開放資料格式與外部化設定，把身份、日誌、模型接口與業務規則分離。可攜不是隨時零成本搬遷，而是關鍵依賴能在合理時間與預算內被替換。

避免假多雲

若兩朵雲只同時出現在簡報上，但資料、監測、人才與演練都集中在單一供應商，仍是單點依賴。真正的多雲需要明確故障轉移、資料一致性、共同安全基線與定期退出演練。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

企業能力堆疊：每一層都有清楚問責

端到端層次

裝置層處理相機、遮罩、離線推論與裝置狀態。API 層處理身份、限流與協定。資料層處理主資料、向量索引、版本與品質。模型層處理登錄、評測、發布與回滾。營運層處理監測、事故與成本。

共用平台

Kubernetes 適合需要一致部署與長生命週期服務的工作負載。Serverless 適合事件驅動與突發流量。物件儲存適合版本化資產。內容傳遞適合模型與靜態知識分發。選擇應由問責與負載特性決定，而不是技術潮流。

最低文件

每個組件都需要擁有者、SLO、容量假設、RTO、RPO、成本上限、資料分類、外部依賴、更新方法與退出計畫。沒有這些材料的組件不應進入正式架構。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

MLOps：裝置分群、灰度發布與漂移管理

發布單元

裝置端模型不能只靠應用版本管理。必須按裝置類型、模型格式、量化方法、知識版本與規則版本形成可追溯的發布單元。任何一項變更都可能改變最終行為。

灰度策略

先發布給內部與低風險人群，設定健康指標與自動停止條件，再逐步擴大。若當機率、延遲、錯誤自信或耗電超過門檻，系統應停止擴大並回滾，不必等到大量使用者投訴。

漂移監測

監測季節菜式、新包裝、相機硬體與使用習慣造成的輸入漂移，也監測知識更新後的輸出變化。漂移不是數字一變就重訓。先判斷是否影響公共成果與特定群體。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

安全設計：保護模型、裝置與供應鏈

裝置端防護

必要時使用安全儲存、憑證綁定、程式完整性檢查與遠端證明，降低模型檔、規則或 API 金鑰被竄改。裝置遺失時可撤銷憑證並清除敏感快取，不依賴使用者自行處理。

服務防護

API 實施最小權限、限流、輸入驗證、惡意檔掃描與異常偵測。模型與知識更新必須簽署、驗證並分批發布，避免供應鏈污染一次影響所有裝置。

事故準備

建立模型替換、資料外洩、提示注入、供應商中斷與不良更新的處置手冊。演練必須包含技術修復、業務降級、管理通報、市民溝通與證據保存。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

隱私工程：資料最小化是架構能力

收集最少

若辨識只需餐盤一部分，在相機介面引導裁切。若統計只需年齡組別，不收集出生日期。若錯誤分析只需特徵摘要，不保留原始影像。每少一項資料，也降低外洩、合規與營運成本。

目的限制

健康教育、服務分析、模型改善與研究是不同目的，不能用一份含糊同意涵蓋。使用者應能使用基本服務而不參與模型訓練，撤回同意後必須有可執行的刪除流程。

可驗證控制

隱私要求必須變成測試：遮罩準確度、日誌不含原始影像、按期刪除、權限變更立即生效、匯出內容完整。沒有技術驗證的政策文件，不能證明資料最小化真的落地。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

採購與驗收：買能力，不是買展示

標書要求

規格應描述業務成果、風險邊界、接口、資料權利、可觀測性與退出要求，避免鎖定特定模型名稱或專有服務。供應商可提出不同技術組合，但必須通過共同測試集與現場情境。

驗收組合

把準確度、拒答、安全、公平、延遲、耗電、可用性、成本、災備、日誌與投訴流程一併驗收。單一平均分會掩蓋高風險失敗。設定不可妥協的硬門檻。

合約保障

明確資料與衍生權利、模型更新通知、分包商、漏洞修補、服務終止、資料匯出、刪除證明與移交期。若退出成本不透明，低價可能變成昂貴的長期依賴。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

組織模式：政產學研投協同

角色分工

政府定義公共問題、規則與採用場景。企業負責工程與持續營運。大學與研究機構提供方法、評測與人才。投資者支持可擴展的成果轉化。任何一方都不應單獨決定高風險系統的成功標準。

共同語言

以用例、資料契約、服務指標、風險登記冊與架構決策紀錄作為跨界溝通工具。研究準確率、商業營收與公共價值是不同目標，專案開始時需要明確排序。

知識移轉

合約要求文件、培訓、聯合值班以及程式與設定交付，讓公共服務團隊具備基本判斷與接管能力。外包可補充能力，但不能外包最終問責。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

人才與數位素養：教使用者質疑 AI

能力層次

領導者需要理解風險與投資組合。產品擁有者需要定義公共成果。工程師需要資料、模型、安全與營運。前線人員需要辨識不確定性、更正錯誤並啟動人工流程。培訓不能只教提示。

實務訓練

用真實但已匿名的失敗案例做桌面演練，包括模型自信但答錯、資料來源衝突、供應商中斷、不良更新與市民投訴。參與者決定停止、回滾、通報與回覆，而不只是操作介面。

持續機制

建立實務社群、工具目錄、共用測試集、技術配對活動與季度案例回顧。這與智慧城市中公務員技術培訓與跨部門協調的經驗一致，把個人專家知識轉成組織能力。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

綠色 AI：把算力成本納入公共問責

連結城市目標

香港方向是二〇五〇年前碳中和，並推進建築能效、低碳運輸、循環經濟、可持續航空燃料與氫能。AI 專案也應量測運算、儲存、網路與裝置更新的資源成本，而不是假設數位化天生綠色。

工程選擇

優先採用適合任務的小模型、裝置端預篩、快取、批次處理、模型量化，以及自動關閉閒置資源。高耗能訓練需要清楚改善目標與停止條件，避免為微小分數提升花費不成比例的算力。

採購指標

要求供應商報告資源使用、硬體壽命、能源地區、裝置更換與電子廢棄物安排。綠色指標不必取代服務品質，但應與成本、延遲與公共價值一併評估。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

城市韌性：把故障當成必然，而不是例外

威脅範圍

極端天氣、網路中斷、電力問題、供應商故障、網路攻擊與不良發布都可能讓數位服務失效。五年規劃強調城市安全、跨部門預警、應急預案與災後快速復原。AI 系統必須進入同一韌性體系。

降級層級

設定四種模式：完整服務、受限服務、離線基本服務與人工替代。每一級把可用功能、資料新鮮度、問責擁有者與市民提示寫清楚，避免故障當下臨時決定。

演練與事後檢討

定期演練區域雲故障、身份平台不可用、不良模型更新與請求暴增。事後檢討不只問復原時間，也問關鍵民生服務是否保留、是否產出錯誤輸出、跨部門通報是否清楚。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。

結語：以克制、證據與公共問責推進 AI

重新定義成功

三日完成裝置端熱量應用，可證明團隊能快速整合。不能證明醫療有效性、監管適配或大規模可靠性。真正成功是清楚知道什麼能用、什麼不能用、出錯時如何保護市民，以及繼續投資是否合理。

城市級啟示

香港在數位身分、CDEG、開放數據、政府共用平台、一百多項智慧城市措施與 AI 生態建設上的成功經驗說明，長期能力來自共用底座、跨部門治理與持續營運，而不是單一模型。

行動原則

從低風險輔助場景起步。以裝置端資料最小化、模型與知識分離、不確定性、人工否決、證據鏈、多供應商標準與退出演練建立信任。讓 AI 成為穩定、可信、克制且可持續的公共能力，而不是短暫展示。

現場提問： 把本頁變成架構審查問題。要求團隊用證據作答，未答項目記入下一份工作清單。