ReDesign 把平面圖轉為可編輯設計

ReDesign想做的,就是把一張匯出圖,文字、圖層轉成獨立像素圖層結構,重新變成可編輯設計。

Repository image for jintae-00/ReDesign

設計原檔遺失之後,最麻煩唔係畫面睇唔到,而係改唔到字、拆唔開圖層、調唔到前後次序。ReDesign屬於Agentic取向的研究型工具,目標係由單張 raster image 重建出可編輯設計結構,輸出成帶有文字、向量形狀、群組同 z-order 的 JSON hierarchy。

它的判斷方式唔係一次過猜完整個版面,而係將設計當成 layer tree,由大區域開始逐層拆細,再用 verifier 檢查每一步成唔成立。呢個取向比起只做 OCR、只做分割,或者直接做多圖層分解更完整,代價就係系統較重,亦要配合多個視覺工具同較高 GPU 記憶體,當中 Qwen 相關 worker 官方已寫明大約要對應 55 GB 級別資源先容易跑得順。

相關模組之間的分工幾清楚:VLM controller 負責揀動作,文字會交由 PaddleOCR、字體辨識、Hi-SAM 同 LaMa 處理;物件與圖層則會用到 Qwen-Image-Layered、GroundingDINO、SAM 2、connected-component analysis 同 VTracer。換句話講,呢個項目唔係單一模型,而係把多個模型與工具串成一條可驗證的還原流程,較適合研究設計還原、可編輯圖形生成,或者想將靜態素材重新帶回設計工作流的團隊。

  • 單張平面圖可還原成可編輯 JSON hierarchy
  • 支援文字、向量形狀、圖片、群組與 z-order
  • 採用 coarse-to-fine tree expansion,加上 verifier 修正分支
  • 效能展示基於 Figma-909,指標上普遍優於多個 baseline

評測方面,項目頁面列出 Figma-909 這個 Dataset 數據集,並顯示 ReDesign 在 L1、PSNR、LPIPS、PQ 同 F1 等指標整體領先 baseline,說明它唔只重建外觀,亦較重視元素級別的可編輯性。儲存庫已提供 agent、baseline 同工具後端結構,但它更似一個研究系統而唔係輕量腳本;較值得留意的是多 GPU 分片、平行 worker 同視覺工具的資源安排,較適合有運算環境的研究者或產品團隊深入測試。

項目主頁 · GitHub

Categories: 開源, Qwen, Agentic, Image, 多模態模型, 影像處理, 視覺模型, Dataset 數據集

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

想交低指示後由 AI 繼續處理雜務,Gemini Spark 就是朝這個方向而來。它把電郵、文件、搜尋與排程串連起來,減少你反覆催促。

Og image

最易理解 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 把影片生成變成多代理流程

想由一句想法走到完整影片,卡位往往唔係生成本身,而係分鏡、節奏同角色一致性。ViMax把呢條流程拆成多個 Agent 協作,重點放在先規劃、再生成。

Repository image for hkuds/vimax

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

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

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

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

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

GitHub

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

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

寫 code 愈來愈快,review 反而更易塞車。阿里巴巴公開 Open Code Review,焦點放在免費、私有化同大規模變更審查。

Og image

當團隊已經用 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, 安全, 編程

Ollama 3.25 把開源模型帶回你部機

想喺自己電腦跑開源大模型,又唔想先砌一大堆環境,Ollama 正正係針對呢個卡位。它將模型執行、管理同串接應用壓縮成一條較順手的路。

Repository image for ollama/ollama

想將開源模型放返本地處理,又要兼顧聊天、程式整合同 agent 工作流,Ollama 幾乎係目前最直接的一條路。它屬於模型執行與管理工具,核心作用係將本地大語言模型的下載、啟動、呼叫同整合收斂到同一套介面,令 Mac、Windows、Linux 甚至 Docker 部署都比較一致。

它吸引人的地方不只是可以對話,而係可以直接接去 Claude Code、OpenClaw、Codex、Copilot 等現有工具鏈。換句話說,Ollama 唔係只提供一個聊天殼,而係充當本地模型服務層;你可以用 CLI 跑模型、經 REST API 調用,亦可以配合 ollama-python、ollama-js,或者再接 Open WebUI、LibreChat、Lobe Chat、NextChat、Perplexica 呢類前端與應用。

同類做法入面,Ollama 的取向好清楚:它唔著重花巧介面,而係先處理「點樣穩定喺本地把模型跑起來,再供其他程式使用」呢件事。背後支援 llama.cpp,意味住它承接咗本地推理生態的成熟基礎;代價亦存在,本地效能仍然受你部機的記憶體、GPU 與模型大小限制,追求大型模型或高併發時,就未必有雲端服務咁輕鬆。

  • 安裝路徑完整,覆蓋 macOS、Windows、Linux 同 Docker,理解上可以當成一個本地 AI 服務。
  • 既可直接 run 模型聊天,亦可透過 REST API、Python、JavaScript 接入現有項目。
  • 跟 Claude Code、OpenClaw、Codex、Copilot 等整合,適合做本地 agent 與開發工作流。
  • 配合 Open WebUI、LibreChat、Lobe Chat、NextChat 等,可快速補上可視化操作層。

較受惠的一群,會係想保留資料喺本地的開發者、需要快速測試開源模型的團隊,以及想把 AI 能力嵌入內部工具的人。就產品定位而言,Ollama 最有價值的地方,係將「本地跑模型」由零散步驟變成可重用的基礎設施。

項目主頁 · GitHub

Categories: 開源, Agentic, API, Linux, Mac, Ollama, Python

Anthropic Opus 提示詞外流反映了什麼

一份放在 GitHub 的提示詞檔案,讓人更具體見到大型模型點樣被「定調」。它未必代表完整系統,但足以幫你理解模型回應背後的設計取向。

Og image

想知道大型語言模型點解會用某種語氣答你、點樣處理敏感內容,最直接的方法之一,就是看它背後的 system prompt。這個 GitHub 項目整理了疑似來自 Anthropic Opus 的提示詞內容,重點不在功能展示,而在於把模型行為規則攤開,讓人看到回應風格、安全邊界與工具使用指令可能如何被設定。

對開發者、提示詞研究者同內容工作者來說,這類資料最有價值的地方,在於它把平時只能靠輸出結果推測的設計思路,變成可以直接閱讀的文字線索。你可以更清楚理解模型點樣被要求保持語氣一致、避開高風險內容,或者在多步驟任務中遵守某些優先次序,但同時要留意這類「leaked prompts」未必完整,也未必反映最新版本。

  • 幫助觀察 Anthropic 對模型人格、語氣與安全規則的安排
  • 適合研究 system prompt、AI alignment 同提示詞工程的人參考
  • 能作為分析模型輸出風格的輔助材料,而唔係正式技術文件
  • 內容真確性、時效性與完整度都需要保留判斷

它和一般產品介紹最大的分別,是你見到的不是功能清單,而是控制模型行為的內部文字結構。這種資料未必能直接提升效果,卻很適合用來拆解 AI 產品點樣把品牌語氣、風險控制同任務規則包進同一套提示詞框架。

從使用角度看,這份內容較適合拿來做觀察、比對同研究,不應視為官方文件或穩定接口。對關心 Anthropic、AI 安全同提示詞設計的人而言,它提供了一個少見的切入口,去理解模型輸出背後不只是能力,仲有大量預先寫好的約束。

項目主頁

Categories: Agentic, 安全, 提示詞, Anthropic, Skill 技能

FinanceComplexQA 點評:金融長文件問答基準

想測試模型是否真係讀得懂財務文件,FinanceComplexQA比一般抽句式問答更貼近難題。它把中英雙語、推理、多步計算與文件依據綁在同一個基準內。

Finance-ComplexQA at a Glance

金融問答最容易失真的位置,不是模型識唔識術語,而是它會否真正在整份參考文件入面推理、比對同計數。FinanceComplexQA屬於數據集/Benchmark,焦點不是背答案,而是檢驗 LLMs 和 agents 能否根據完整 reference documents 回答複雜金融問題。

它修正了只靠 parametric knowledge 或抽取單一段落的評測範式。作者把重點放在 document-grounded complex financial QA,要求答案同問題及原始文件一致,並涵蓋 multi-hop reasoning、numerical calculation、comparison、implicit inference、planning、summarization 同 evidence-grounded verification,對 RAG、Agentic workflow 同長文本閱讀能力都有參考價值。

資料結構本身亦有取捨。FinComplexQA-Pro 收錄 2,026 組獨立 QA,按語言、金融場景與任務分類組織;同一題會以 scene_categories 與 task_categories 兩種視角出現,所以總記錄視圖有 4,052 筆。另有 overall 提供 agent_answer、agent_thinking 及 LLM-as-a-judge 分數,但這些分數只適合做診斷訊號,不能當 ground truth。

  • 支援中文與英文,但兩個子集覆蓋的文件領域不同,schema 亦不完全一致
  • 較適合逐個子目錄讀取 JSONL,而不是一開始合併全部資料
  • 可用 exact match、數值容差、F1、semantic similarity 等方法比對輸出
  • 附有 Reference_documents,方便追查 PDF 與 LaTeX 原文證據

部署和測試的理解方式相當直接:資料主要在 Hugging Face 發佈,研究團隊可先挑單一語言、單一 task category 載入,再把模型輸出對照 gold answer 或文件證據做評估。它較受惠於做金融 RAG、長文件 QA、Agent 評測或雙語研究的團隊;要留意的是金融事實具時效性,而且項目已明確標示僅供研究與評估,不應延伸成投資、會計、法律或財務建議。

項目主頁 · GitHub · Paper

Categories: 開源, 微軟, DeepSeek, Agentic, RAG, 多模態模型, 中國, Dataset 數據集

ProVisE 用像素答案重做空間評測

空間理解唔一定適合用文字作答,ProVisE改咗評測入口,令圖像生成模型可以用畫、點、標記去答題。你會更易睇清楚,模型到底係唔識空間,定只係答題格式唔對。

ProVisE logo

當一條空間題目本來應該用圈選、標記路徑或者遮罩去表達,硬要模型交出座標、選項字母或文字描述,結果往往唔係能力差,而係答題介面同模型表達方式錯位。ProVisE屬於評測框架,處理的正是呢個落差:它唔改原本 benchmark 任務本身,只改回應介面,讓圖像生成模型用像素空間交答案,再轉回 benchmark 可計分的結構化輸出。

現有 spatial benchmarks 多數沿用 text-only interface,假設所有模型都應該以 coordinates、option labels 或 textual descriptions 回答。作者認為這種固定範式會壓縮 regions、paths、affordances 呢類本身偏視覺的判斷,因此提出 Protocolized Visual Evaluation:先由 task-aware router 指派 visual protocol,再用固定 guidance prompt 同 parser 約束輸出,最後仍然交回 original benchmark metric 評分。Text-output VLMs 就維持原本答題空間,兩類模型可以在同一套任務語義下比較。

ZJU-OmniAI/ProVisE 在於把「模型唔識答」同「評測方法逼錯答案格式」分開處理。配套的 SpatialGen-Bench 收錄 470 個 curated samples,涵蓋 14 個 subtasks,同時分成 perception、understanding、reasoning、interaction 四個 capability levels;研究結論亦相當直接,image-generation models 在可把判斷外化成像素標記的任務上有競爭力,但 text-output VLMs 在另外一些題型仍然較穩定,兩者並非誰全面取代誰。

  • 保留原有 benchmark metric,只替換答案介面,方便同既有結果對照
  • 用 visual protocol 限制生成內容,減少任意畫圖帶來的解析歧義
  • SpatialGen-Bench 把空間能力拆成 14 個 subtasks,唔再只看單一總分
  • 適合研究 VLM、image-generation models、agent 空間理解能力的團隊採用

安裝門檻看來不高,程式環境以 Python 3.10+ 為主,並已公開 code、project page 與 Hugging Face 上的 SpatialGen-Bench。現階段它更像研究與評測項目,不是即插即用產品;重點也不在部署成服務,而是在你想驗證模型空間認知時,能否用更貼近模型輸出形式的方式做比較。對做多模態模型、視覺評測或 Agentic 系統的人來說,ProVisE提供了一個相當清晰的檢查角度。

項目主頁 · GitHub · Paper

Categories: 開源, Agentic, Image, Python, 多模態模型, 視覺模型, Dataset 數據集

TrajLoc 把路線描述對準衛星圖

單張街景未必足夠判斷位置,TrajLoc改為沿住整段路線做比對。影片、文字敘述,甚至兩者一齊用,都可以指向同一塊衛星瓦片。

A trajectory can be queried as dense video or as abstract language — both retrieve the same satellite tile.

只靠一張街景相去配對衛星圖,遇到轉彎、路口相似、視角受限時好容易失手;TrajLoc改為追蹤整段移動路線,將街景影片、自然語言路線描述,或者兩者結合後對應到帶地理標記的衛星瓦片。它屬於跨視角 geo-localization 模型連同 benchmark 項目,處理的是「把連續路徑準確放回地圖」這個問題。

現有 cross-view 資料多數停留在 single-image、video-only 或 text-only 範式,作者認為這樣會拆散同一條路線入面本來互相補強的時序線索與語意線索,因此一併推出 SeqGeo-VL。呢個 benchmark 收錄 38,863 組對齊的 video-text-satellite triplets,並有 91.8% human verification pass rate,重點不是再加大資料量,而是把 sequential 同 linguistic 兩種證據放入同一任務。

TrajLoc沒有另起一套龐大時序架構,而是由 pretrained CLIP ViT-L/14 延伸成 video、text 同 satellite encoders,再用 co-training curriculum 將三種查詢模式放入同一個表示空間。作者另外加入 TrajMod,將路線幾何資訊 tau={(Δx_i, Δy_i, θ_i)} 轉成 FiLM 的 scale/shift 參數,直接調節 query embedding;做法比單靠提示詞更明確,亦保留 frozen encoders 的可重用性。

  • 支援 video、plain language、video+text 三種查詢方式
  • SeqGeo-VL 是首個同時包含 sequential 與 linguistic cross-view benchmark
  • TrajMod 只用 waypoint offsets 與 headings,不靠 map 或 POI metadata
  • 項目提供 agent-ready tool interface、persistent Python API 同 JSON CLI

從示範與說明看,TrajLoc的定位很清楚:它不是通用多模態聊天模型,而是給 spatial reasoning、戶外機械人、導航研究同 multimodal agents 調用的專門工具。225 ms 的示例檢索速度對互動式流程有吸引力,但目前公開資訊主要集中在 benchmark 與檢索能力,部署前仍要留意資料覆蓋範圍、地區泛化,以及自己的工作流是否真有影片或路線文本可供查詢。

項目主頁 · GitHub · 模型

Categories: 開源, Qwen, Agentic, API, Video, Image, AI productions, Embedding, Python, 多模態模型, 模型訓練, Dataset 數據集

ActiveVision 點出視覺推理真空帶

望一眼答題的多模態模型,在 ActiveVision 幾乎集體失靈。這個 benchmark 把「要一路觀察先答到」的能力,拆成更貼近人類解題節奏的測試。

ActiveVision — An Exam for Active Observers. Vision is a loop, not a glance.

不少視覺題目唔係靠一眼辨認,而係要沿住線追、逐區域數、一步步核對先答得到;ActiveVision 正正針對呢種落差而來。作為一個 benchmark,它集中測試 iterative visual reasoning,處理的是模型看得到畫面,但未必能持續整理觀察過程的問題。

現有多模態模型常見做法是對單張圖作一次性判讀,再配合 chain-of-thought 直接作答;作者認為這種 single-glance 範式,對需要反覆掃描、追蹤順序與維持中間狀態的題型特別吃力。ActiveVision 因此設計了 17 個任務,並用 deterministic program 生成場景,再以 photorealistic 方式重繪,令畫面自然之餘仍保留可驗證結構。

數字相當直接:人類表現為 96.1%,前沿模型在官方無工具評測下最高約 10.6%,差距接近 9 倍。網站亦列出 agent 版本的 tool-use ablation,像 Claude Code 與 Codex 接入工具後,分數明顯高過純 chain-of-thought,表示問題未必只是「看不懂圖」,而是缺少可逐步外化與操作的解題流程。

  • 收錄 17 個任務,重點放在 distributed scanning 與 sequential traversal 一類逐步觀察題
  • 官方評測涵蓋 Claude、GPT、Gemini,亦提供 agent ablation 腳本
  • 數據集可經 Hugging Face 下載,評測程式以 Python 為主
  • 同一靜態圖片也能迫使模型做多步推理,唔靠影片輸入撐起難度

整個 GitHub 項目比較像研究與評測基建,而唔係即用型產品:你需要先下載數據集、配置對應供應商 API,然後用 repo 內的 eval 腳本跑結果。對做多模態模型評測、Agentic 工作流、或者想驗證 Computer-use agents、CUAs 式外部工具協作價值的團隊,它提供了一個很尖銳的檢查點:模型是否真的會「觀察」,還是只會對影像作高階猜測。

項目主頁 · GitHub · Paper

Categories: 開源, Gemini, OpenAI, Agentic, API, Python, 多模態模型, Anthropic, Dataset 數據集

Page 7 of 25
1 5 6 7 8 9 25