InferNews

Gemini Spark 登陸香港：AI 代你長時間跟進工作

2026 年 7 月 29 日

最易理解 Gemini Spark 的方式，是把它看成一個會在背景持續運作的 Agentic AI 助手：你先交代目標，它再慢慢把零散工序接起來，處理那些花時間、又不想不停重複提示的工作。Google 已在香港推出這項服務，定位很清楚，就是幫用家把日常行政與資料整理自動化。

它接上的重點，不是單次問答，而是整段工作流。Gemini Spark 運行於 Google 的雲端基礎設施，能原生連接 Workspace 工具，例如 Gmail 和 Docs，毋須另外設定，就可以整理混亂的電郵往來、彙整行業消息、從舊文件抽資料做後續安排，甚至進行網上資料搜集、比較選項與完成預訂。

Google 提到，系統以 tasks、custom skills 和 schedules 這類機制去安排工作，讓用家用自然語言交代規則、例行事項與時間觸發條件，毋須寫程式。另一個分別在於，它不會因為你闔上手提電腦或鎖上手機就停下來，背景流程仍可繼續運作，較適合需要長時間跟進的文書與研究工作。

支援背景持續執行，不用反覆重新提示
可原生連接 Gmail、Docs 等 Workspace 工具
能處理資訊整理、排程準備、網上研究與預訂類工作
高風險動作前會先要求明確同意

控制權仍然留在用家手上。Google 表示，Gemini Spark 會按照用家指示運作，用家可決定何時啟用，以及容許它接觸哪些應用程式；遇到交易或發送電郵等高風險操作，系統亦會先徵求明確授權。現時香港由 Google AI Ultra 訂閱用家率先使用，Google AI Pro 用家的開放時間會在未來數星期逐步擴展。

項目主頁

Categories: 香港, Google, Gemini, Agentic, 工具, 提示詞, 編程, Skill 技能, 框架

ViMax 把影片生成變成多代理流程

2026 年 7 月 29 日

直接由文字生成影片，最易出問題的通常不是畫面夠不夠靚，而是故事走向會散、鏡頭難連貫、角色設定前後不一。ViMax把這些環節拉回工作流處理：它屬於 Agentic Video Generation 類型的開源項目，用多個 Agent 分別扮演 Director、Screenwriter、Producer 與 Video Generator，目標是把影片生成由單次出圖，變成可規劃的多步驟流程。

這種取向的分別，在於它不只追求「一句提示詞出片」，而是先把敘事、鏡頭與製作安排拆開，再交回生成模組執行。對內容創作者、想做短片原型的團隊，或者研究多代理協作點樣落地到視頻模型工作流的人，這個項目會較有參考價值；但儲存庫提供的資訊目前偏簡短，未見完整測試結果、部署細節或清晰的安裝流程。

從名稱與描述判斷，ViMax較像一個協調層或框架，而不只是單一視頻模型。它想補的是影片生成裡最難靠單一模型穩定完成的前置規劃，因此價值未必在最終某一幀畫質，而在於整段片能否保持節奏與結構。不過，原始資料未交代它串接哪些底層模型、怎樣處理角色一致性，亦未提供性能指標，現階段較適合先當成研究方向與工作流設計來理解。

把影片生成拆成 Director、Screenwriter、Producer、Video Generator 多個 Agent
重點放在規劃與協作，不只是單次提示詞生成
適合研究多代理、多步驟視頻製作流程的人參考
儲存庫描述很短，暫時未見完整安裝、部署與評測資訊

ViMax最吸引人的地方，是它把「生成影片」理解成一條需要分工的製作鏈，而不是單一模型一次完成所有事。現有資訊仍不足以判斷成品穩定性或生產可用度，但作為開源方向，它清楚對準了多模態模型在長段影片敘事上的核心難題。

GitHub

Categories: 開源, 香港大學, Agentic, Video, AI productions

ClinFusion 把醫療影像讀懂再回答

2026 年 7 月 28 日

醫療多模態模型最易失準的位置，往往不是會不會答，而是有沒有真正對準影像內容。ClinFusion屬於模型，更準確地說是面向臨床理解的 vision-centric Multimodal large language models (MLLMs) 系統，重點放在同時處理 2D 圖像、原生 3D NIfTI 影像與文字任務，減少只靠文字對齊時常見的臨床細節流失。

現有做法常把醫療問題當成一般多模態問答處理，但作者認為這種範式忽略了 3D 影像與放射科判讀流程，因此用 compositional and cascaded vision encoder 配合 Cascade Spatial-Aware Locality Fusion，把 2D 與 native 3D 醫療影像放進同一個 fused encoder。另一個關鍵不是只換模型，而是連評測也改寫：加入 MedIF-Bench 檢查 instruction following，並用 region-of-interest-grounded 方法評估報告生成的 factualness。

論文給出的成績相當進取：ClinFusion 在 24 個基準中有 20 個超過 Hulu-Med、Lingshu 等開源醫療 MLLMs，也在 16 個比較裡有 13 個勝過 GPT-5.2 與 Gemini-3-Flash。盲測部分由 board-certified radiologists 進行，報告排名亦拿到最佳，RoI-grounded metric 與專家判斷的相關性也最高，這點比單看自動分數更有說服力。

可接受文字 prompt、2D 圖像路徑，以及 3D NIfTI volumes（.nii.gz）
定位不是通用聊天，而是臨床導向的整體醫療理解
核心取向是把 2D/3D 視覺編碼與臨床一致的評測一併重做
已公開模型推理方向，但儲存庫資訊未完整交代部署流程與完整安裝細節

較適合留意這個項目的，會是做醫療 AI、放射影像、多模態研究或醫療報告生成評測的團隊。它的亮點在於把「模型看見了什麼」與「臨床上是否講得準」放到同一條線上；限制亦很清楚，現有 GitHub 資訊主要集中在作者主張與推理輸入格式，真正要落地到醫院工作流，仍要再看公開模型、硬件需求與後續工具鏈是否齊備。

GitHub · 模型

Categories: 開源, 阿里巴巴, Qwen, Image, 3D, Medical醫學, 多模態模型, 模型, 中國, Dataset 數據集, 清華大學

Google 開源 GNM Head：更完整的人頭 3D 模型

2026 年 7 月 28 日

只做臉部外殼，很多時已經唔夠用；去到動畫、重建同生成式影像控制，眼球、口腔同頭部姿態一旦分離得唔好，效果就會即刻穿崩。google/GNM 目前先開放的 GNM Head，屬於3D parametric statistical human model 項目，焦點是用更完整的人頭幾何表示，處理傳統 3D Morphable Models (3DMMs) 對內部 anatomy 覆蓋不足的問題。

這個項目的取向很鮮明：不只是追求一個可調參的人臉網格，而是把 head、face、neck、eyeballs、teeth、tongue 放進同一個生成式人體測量框架。作者在技術報告指出，現有公開模型多數只覆蓋外部幾何，亦容易受限於低保真掃描資料；GNM 則結合高解析 3D scans 與 anatomy-specific artist-made samples，並加入 ocular 同 intra-oral specialized sub-models，目的就是改善幾何品質同可控性之間的取捨。

現有儲存庫較像一個生態系入口，而唔係即開即用的單一應用程式。README 清楚列出 GNM Head 已提供 NumPy、JAX、PyTorch、TensorFlow 多後端支援，亦有 Linux、macOS、Windows 的 CI；但目前公開資訊以模型與技術報告為主，未見到很完整的產品化操作流程說明，所以較適合研究、角色生成、數碼人、3D 視覺或生成式影像控制團隊按其子目錄文件逐步接入。

補足傳統 3DMM 常見缺口：不只外形，連眼球、牙齒、舌頭都可控
GNM Head 強調 identity、expressions、head pose 的 disentangled control
同時支援 NumPy、JAX、PyTorch、TensorFlow，方便接去不同研究流程
技術報告聲稱在 fitting target 3D face scans 達到 SotA 表現，但具體指標仍要回看原報告

它最吸引人的地方，在於把「可生成、可擬合、可作條件控制」三條路線拉到同一個模型家族內。現階段公開內容仍以 GNM Ecosystem 的起步版本為主，想拿來做完整 production pipeline，仍要自己判斷與現有重建、動畫或生成系統的整合成本；但作為高保真人頭 3DMM 的新基礎，這個項目的研究價值同延展空間都相當高。

GitHub · Paper

Categories: 開源, Google, TensorFlow, 3D, Linux, Mac, Python, 多模態模型, 模型, 語音, Dataset 數據集

FilmOps 將電影語言拆成可分析標籤

2026 年 7 月 28 日

一段影片好不好，不一定只靠整體觀感判斷；鏡頭遠近、構圖、機位、色調同運鏡，往往先係影響觀感的核心。FilmOps 正正瞄準呢個缺口：它不是一般影片生成模型，而是一套開源 operator suite，用來把影片畫面映射成結構化的 cinematographic labels，處理的是電影語言難以被細緻分析與量化的問題。

現有影片 benchmark 多數集中在 general perceptual quality、text alignment 或 temporal smoothness，對專業 cinematographic language 仍然偏粗略；general-purpose MLLMs 又難以穩定辨認 film-specific attributes，而 aesthetic predictors 這類領域模型面對 cinematic content 亦有明顯 domain gap。FilmOps 的取向很清楚：不用單一大模型包辦所有判斷，而是把六個維度拆開，按任務特性分配不同 backbone，令 shot scale、composition、camera angle、color & tone、character layout 同 camera movement 可以分別處理。

它的價值在於更像一套分析管線，而不是只給你一個總分。項目覆蓋 55 個以上子類別，分類定義對齊 Film Art、ASC Manual、Cinematography: Theory and Practice，亦經過 practitioner 驗證；加上 modular architecture，可以獨立用單一 operator，或者走 unified pipeline。對要做影片生成評測、鏡頭標註、資料整理，甚至研究 FilmBench 呢類 cinematic benchmark 的團隊，這種拆解方式會比泛用多模態評分更有解釋力。

屬於開源工具／模型組合，重點是把影片拆成電影語言標籤，而不是直接生成影片
六個 operator 採用 task-specific backbone，包含 DINO ViT-B/14、BEiT Base、ResNet-18、InternVL3-14B
支援 live-action、3D animation、2D animation 同 stylized content，強調 cross-genre consistency
已交代基本部署條件，包括 Python、PyTorch、CUDA 與 ffmpeg，也提供 unified pipeline 與 checkpoints 準備方向

現有資料只明確指出它在所有維度都勝過 general-purpose MLLMs，但細節主要放在論文。配套的 FilmBench 亦用同一套 Cinematic Language 思路建立 benchmark，並聲稱 evaluator 在模型排名上與人工評分高度一致，說明 FilmOps 並非只為展示而做，而是服務整個影片評測流程。不過它始終偏向分析與標註基建，想直接拿來做完整產品，仍要自行處理 checkpoints 下載、推理資源，並接受部分 operator 對 CUDA 與較重模型的依賴。

GitHub · Paper

Categories: 開源, 阿里巴巴, Gemini, NVIDIA, 3D, AI productions, Python, 動畫, 多模態模型, 語音, Dataset 數據集

DriveDNA 將駕駛風格拆清楚

2026 年 7 月 28 日

不少駕駛模型聲稱識別「駕駛風格」，但一換車款、路線或交通情境，學到的可能只是車主習慣路段與車輛特性。DriveDNA屬於多模態自然駕駛數據集與 benchmark，核心不是再加一批行車資料，而是把「邊個人在開車」與「開緊咩車、行緊邊條路」分開檢驗，直接處理個人化駕駛建模最常見的捷徑問題。

現有公開資源不是樣本太細、就是把車輛與路線幾乎固定，於是高分未必代表模型捉到穩定的個人風格。作者的做法更像重新定義評測：資料來自 465 位司機、115 款車、4,121 段駕駛，保留 CAN telemetry 與前向道路影片，並移除 automation-engaged frames，只留下 human-controlled driving，再配合 frozen evaluation protocol 與 leakage probes，要求研究者同時報告效用與洩漏風險。

它的價值在於評測不只看 re-identification 準唔準，還加入 personalized behavior prediction，以及在條件匹配下比較風格是否仍然存在。論文亦講得很直白：高 re-ID 可能只是 route leakage，能認出司機，不等於對未來行為預測更有幫助；相比只追單一識別分數，DriveDNA更重視模型有沒有學到可遷移、可解釋的駕駛表徵。

規模夠大：465 位司機、975 小時 human-controlled driving、4,121 段駕駛
模態完整：10 Hz CAN telemetry 配合同步前向道路影片
評測設計針對混淆來源，明確檢查 vehicle、route、condition leakage
倉庫已附 code 與 harness，但提供的是 benchmark 與研究流程，不是即插即用產品

私隱與資料治理亦寫得仔細：司機身份用 salted hashes，移除 VIN、裝置識別碼與 GPS，沒有車廂影片與音訊，受控影片版本會模糊人臉與車牌，並禁止 re-identification 與保險、就業、執法評分用途。較適合自動駕駛、駕駛行為建模、VLA 與多模態學習團隊拿來做表徵比較與洩漏檢查；現有資訊可確認倉庫附有 code & harness，但未見完整產品化安裝流程，重點仍是研究 benchmark 與可重現評測。

GitHub · Paper

Categories: 開源, 多模態模型, VLA, Dataset 數據集

ARI 用 RAG 修復韓國朝鮮古籍殘字

2026 年 7 月 28 日

最值得留意的，不是模型把缺字補回來本身，而是它專門處理古籍修復最棘手的一類內容：人名、地名等 Named Entities。ARI 屬於一個結合 Retrieval-Augmented Generation（RAG）的文獻修復框架，針對朝鮮王朝實錄與承政院日記這類韓文漢字史料，補足只靠局部語境時經常失準的缺口。

現有做法多數依賴 masked language modeling，擅長根據前後文猜測一般字詞，但一遇到需要外部史實支持的專名就容易失手。ARI 的取向很清楚：先用 BM25 從歷史語料找出前 20 份相關文本，再以字串相似度 0.8 過濾重複內容，將這些外部證據交給模型一併生成，修正通用 LLM 容易出現的幻覺。

模型部分不是從零開始，而是建基於 Qwen3 32B 與 Qwen3 8B 微調成 ARI-32B 和 ARI-8B，並加入 25% named entity-prioritized masking 訓練策略，把學習重點放在知識密集片段。論文亦指出，對漢字材料而言，詞彙層面的 BM25 檢索比 embedding-based retrieval 更有效，這一點頗有說服力，因為表意文字的字形與字詞對應關係本身就影響檢索效果。

適合歷史文獻整理、數位人文研究與古籍校勘團隊參考
主要強項在於修復需要外部知識支撐的 Named Entities
ARI-32B 與 ARI-8B 同步提供，前者追求表現，後者較重視運算成本
論文結果顯示，它在 named entity 與隨機遮罩字元修復都勝過多個基線與通用模型

把它視為一個已有公開模型與方法說明的研究項目。對需要先驗證效果的人來說，現階段較合理的路線會是先查看論文設定與模型頁面，再判斷是否足以接入自己的古籍修復工作流。

項目主頁 · GitHub · Paper

Categories: 開源, Qwen, Embedding, RAG, 模型, 語音, Dataset 數據集

AI 時代，人的判斷反而更重要！

2026 年 7 月 28 日

當 AI 愈來愈快生成文字、整理資料同提出回應，真正拉開差距嘅反而唔係輸出速度，而係人有冇能力判斷內容是否合理、合乎脈絡，同埋是否值得採納。呢段影片圍繞 Human Centered AI 展開，重點放在人文訓練點樣幫助使用者面對 AI 帶來嘅選擇與判斷問題。

內容指向一個很直接的現實：AI 可以提供答案，但唔會自動代替價值判斷。當內容涉及語境、倫理、文化理解，甚至對不同群體嘅影響時，單靠模型生成結果並不足夠，人仍然需要介入作出取捨。

對一般讀者來說，呢個角度最有用嘅地方，在於它唔把 AI 視為單純取代人嘅工具，而係提醒大家重新理解「判斷」本身的價值。無論係教育、內容工作，定係日常資訊判讀，能否提出好問題、理解背景同辨認偏差，都比單次生成結果更重要。

重點放在 Human Centered AI，而唔係模型規格或功能比較
核心訊息係 AI 能生成答案，但人仍要負責判斷
人文相關能力包括語境理解、倫理思考同價值取捨
適合關注 AI 教育、內容判讀同科技倫理嘅讀者

現有資料只提供影片標題、簡短描述同 YouTube 頁面資訊，未見更完整講稿、案例、方法細節或量化資料，所以無法進一步確認講者有冇提出具體框架、研究結果或操作建議。不過就簡介層面來看，主線已經相當清楚：AI 愈普及，人對意義、責任同判斷嘅理解只會變得更重要。

項目主頁

Categories: 安全, 教學

CrossView 用 3D 數值控制鏡頭：LTX-Video 跨視角生成

2026 年 7 月 28 日

想將一段現成影片改成另一個鏡頭角度，又唔想主體變樣或空間關係散掉，這正是此模型處理的問題。它明確基於 Lightricks/LTX-2.3，屬於 LTX-Video 2.3 22B 的 IC-LoRA 微調，重點不是純文字改鏡頭，而是用輸入影片加相機偏移數值，重建同一場景的新視角。

頁面提供的做法幾清楚：模型同時接收兩段參考影片，一段是由 CrossViewWarp ComfyUI node 產生的 depth-warp 影片，用來保留幾何結構；另一段是原始影片，用來維持主體 identity。這種雙參考分工，反映它優先解決「換角度後仍要似原片」的取捨，比單靠 prompt 描述鏡頭更穩定。

它與同作者的 CrossView Prompt LoRA 差異亦很直接：後者由文字提示選鏡頭角度，這個版本改為輸入 azimuth / elevation / distance 等數值，所以鏡頭控制更精確。頁面亦提到可以在 3D orbit picker 加 keyframes，逐幀插值相機姿態，代表不只可做固定新視角，也可做繞拍式 camera move。

基礎模型已標明為 Lightricks/LTX-2.3，授權為 Apache-2.0。
主要檔案是 LTX2.3-22B_IC-LoRA-CrossView-Warp_v0.9_18000.safetensors。
依賴 ComfyUI-CrossViewWarp 與 Depth Anything V2 節點提供 depth 輸入。
示例包含固定視角偏移與 keyframed 軌道鏡頭，並說明輸出來自真實影片而非合成訓練片段。

這個項目目前仍是 PoC，它較偏向 ComfyUI 工作流驗證，而不是通用本地大語言模型部署。

模型

Categories: 開源, ComfyUI, Video, 3D, AI productions, 視覺模型, 視頻模型, LTX

OpenCode – 阿里開源 AI Code Review，主打免費私有審查

2026 年 7 月 28 日

當團隊已經用 AI 加快寫 code，真正卡住進度的往往變成 code review。呢次公開嘅 Open Code Review，重點不只是「AI 幫你睇程式」，而係想處理大型變更集難審、人工 review 跟唔上，以及商業工具長期按席位收費呢幾個現實問題；內容亦提到它來自阿里巴巴內部使用背景，定位係開源嘅 AI code review 項目。

現有資料將焦點放喺幾個差異：它採用結合 deterministic pipelines 同 LLM agent 嘅混合架構，目的係補足一般通用 agent 喺大型 changeset 上容易漏看脈絡、穩定性不足嘅情況；同時內建 ruleset，並且強調可以直接整合到 Claude Code。資料亦提到 Apache 2.0 授權、可免費使用，同埋私有化操作係其中一個賣點。

重點可先整理成幾項：
– Open Code Review 屬於開源 AI code review 項目，面向開發團隊審查程式變更流程
– 核心賣點係免費、可私有化，以及針對大規模 code review 場景設計
– 架構結合 deterministic pipelines 與 LLM agent，用意係提升大型變更審查嘅完整度與穩定性
– 內容提到它曾服務大量阿里巴巴開發者，並找出大量缺陷，但未見更完整技術細節與驗證方法
– 可安裝到 Claude Code 之中使用，不過現有資料未提供完整步驟

以讀者角度睇，最受用嘅會係已經開始用 AI 寫 code、但 review 成本持續上升嘅團隊，尤其關心內部程式碼唔想外流，或者想將審查規則固定落流程入面嘅情境。呢類工具值唔值得跟進，關鍵唔只在於它是否「有 AI」，而係能否喺私有環境中穩定處理大變更，並且減少人工逐行追查嘅負擔。

同一時間，原始資料有限。現時只有影片標題、描述同極少量頁面文字，未提供完整安裝流程、下載連結、規則內容、性能數字來源，亦未交代它點樣接入 Claude Code 或本地模型，因此文章只能按已知資訊整理方向，未適合延伸成操作教學。

項目主頁

Categories: 阿里巴巴, Google, Agentic, 安全, 編程

Page 1 of 122

1 2 3 … 122 Next »