Seedance 2.5 走向超寫實 AI 影片生成，重點放在畫面真實感同創作效率。這類工具適合想快速做出貼近真人拍攝效果嘅內容製作者。
Seedance 2.5 透過影片生成能力，主打把 AI 片段做得更貼近真實拍攝感，適合內容創作者、短片製作同需要快速試片嘅工作流。片段描述雖然唔多，但方向好清楚：重點唔係花巧效果，而係提升畫面可信度同整體觀感。
對一般創作者嚟講，呢類模型最有用之處係可以縮短由構思到成片嘅時間，尤其係要做概念片、廣告草稿、社交平台短片，或者先行測試視覺風格嘅時候。它強調 ultra realistic，代表畫面一致性、材質細節同動態自然度會係主要賣點。
不過，原始資料只提到示範與推廣用途，未有交代訓練細節、評測指標、輸入限制或實際可否隨意下載使用，所以唔適合自行推斷佢嘅開放程度。現階段較合理嘅理解係：Seedance 2.5 係一個面向高寫實影片生成嘅模型/服務，重點在於實用視覺效果，而唔係提供完整技術規格。
同一個策略連續解幾類相關任務，邊做邊整理可轉移的技能文件，正是 SkillRise 想處理的學習斷層。它不是只追單次成功率，而是想讓經驗在下一題繼續生效。
做完一題就把經驗丟掉，往往是代理系統訓練最可惜的地方。SkillRise 屬於強化學習框架，焦點放在 cross-task skill learning：讓同一個 policy 按次序處理同一家族的任務，一邊解題，一邊把軌跡整理成會持續演化的 skill document，將前一題學到的做法帶去下一題。
它的取向不是把每個任務分開訓練到最好，而是刻意安排由淺入深的任務序列，讓 Solve 與 Curate 交替發生。這個設計針對的是跨任務遷移能力，而不是單一回合表現；代價是環境設定與資料組織較講究，ALFWorld、WebShop 要跟隨 verl-agent 的環境配置，ScienceWorld 則沿用 BEACON 的 setup，並且要先整理模型路徑、資料路徑與追蹤設定。
README 提供了可直接對照的執行方式：同一套 examples 結構下，既有 SkillRise，也有 GRPO baseline，方便把新方法與基線放在相近條件下比較。模型部分從腳本名稱可見已準備 Qwen3-4B 配置，底層也建立在 veRL、verl-agent、BEACON 等現成項目之上，所以它比較像研究與實驗工作流的延伸，而不是即裝即用的產品。
成果描述指向一個清楚結論：SkillRise 在 ALFWorld、WebShop、ScienceWorld 的整體結果最好，勝過 prompting-based methods 與 RL baselines。較適合研究 Agentic workflow、長程技能累積、跨任務學習的團隊；想觀察 skill document 如何影響後續決策的人，也會比只看最終分數得到更多訊息。
想交低指示後由 AI 繼續處理雜務，Gemini Spark 就是朝這個方向而來。它把電郵、文件、搜尋與排程串連起來，減少你反覆催促。
最易理解 Gemini Spark 的方式，是把它看成一個會在背景持續運作的 Agentic AI 助手：你先交代目標，它再慢慢把零散工序接起來，處理那些花時間、又不想不停重複提示的工作。Google 已在香港推出這項服務，定位很清楚，就是幫用家把日常行政與資料整理自動化。
它接上的重點，不是單次問答，而是整段工作流。Gemini Spark 運行於 Google 的雲端基礎設施，能原生連接 Workspace 工具，例如 Gmail 和 Docs，毋須另外設定，就可以整理混亂的電郵往來、彙整行業消息、從舊文件抽資料做後續安排，甚至進行網上資料搜集、比較選項與完成預訂。
Google 提到，系統以 tasks、custom skills 和 schedules 這類機制去安排工作，讓用家用自然語言交代規則、例行事項與時間觸發條件，毋須寫程式。另一個分別在於，它不會因為你闔上手提電腦或鎖上手機就停下來，背景流程仍可繼續運作，較適合需要長時間跟進的文書與研究工作。
控制權仍然留在用家手上。Google 表示，Gemini Spark 會按照用家指示運作，用家可決定何時啟用，以及容許它接觸哪些應用程式；遇到交易或發送電郵等高風險操作，系統亦會先徵求明確授權。現時香港由 Google AI Ultra 訂閱用家率先使用，Google AI Pro 用家的開放時間會在未來數星期逐步擴展。
一份放在 GitHub 的提示詞檔案，讓人更具體見到大型模型點樣被「定調」。它未必代表完整系統，但足以幫你理解模型回應背後的設計取向。
想知道大型語言模型點解會用某種語氣答你、點樣處理敏感內容，最直接的方法之一，就是看它背後的 system prompt。這個 GitHub 項目整理了疑似來自 Anthropic Opus 的提示詞內容，重點不在功能展示，而在於把模型行為規則攤開，讓人看到回應風格、安全邊界與工具使用指令可能如何被設定。
對開發者、提示詞研究者同內容工作者來說，這類資料最有價值的地方，在於它把平時只能靠輸出結果推測的設計思路，變成可以直接閱讀的文字線索。你可以更清楚理解模型點樣被要求保持語氣一致、避開高風險內容，或者在多步驟任務中遵守某些優先次序，但同時要留意這類「leaked prompts」未必完整，也未必反映最新版本。
它和一般產品介紹最大的分別，是你見到的不是功能清單，而是控制模型行為的內部文字結構。這種資料未必能直接提升效果，卻很適合用來拆解 AI 產品點樣把品牌語氣、風險控制同任務規則包進同一套提示詞框架。
從使用角度看，這份內容較適合拿來做觀察、比對同研究，不應視為官方文件或穩定接口。對關心 Anthropic、AI 安全同提示詞設計的人而言，它提供了一個少見的切入口，去理解模型輸出背後不只是能力，仲有大量預先寫好的約束。
想拍角色反應戲，但提示詞只寫到情緒名？這些 Skill 會把動機、微表情同鏡頭節拍補完整，令 AI 影片生成更似一場表演。
情緒寫得太粗，AI 影片角色往往只會交出一個「表情」，而唔係一段有起伏的反應。呢個 GitHub 項目定位好明確：它係一個為人物表演而設的提示詞 Skill，專門把模糊情緒拆成可拍、可生成、可放入文生視頻與圖生視頻模型的演出指令，處理的是角色點樣由看到事件、壓住反應，再慢慢洩露情緒。
最有用的地方不只是擴寫字數，而係先補足角色點解會有反應。它用五個問題建立因果鏈，再把眼神、眼瞼、眉間、嘴角、下顎、呼吸、姿態同聲音排成時間軸，連鏡頭、光線、時長同負面約束都一併整理。對 Seedance、Kling、Runway、Veo 呢類模型來講，呢種寫法比單一句「她很傷心」更容易生成連貫畫面。
同類做法常見是堆情緒形容詞，或者直接放大表情強度；呢個項目反而重視克制、遞進同角色自我控制，所以特別適合特寫、關係戲、對白反應同微表情場景。代價亦好清楚：它偏向劇情演出導向，唔係追求高速出稿的萬用提示詞模板，使用者最好本身知道角色處境，先能發揮得更準。
這個 Repo 可理解成一個可直接複用的 Agent Skill／提示詞模板項目，而唔係獨立模型或推理服務。它較適合內容創作者、短片導演、角色動畫設計者，或者要反覆修改人物反應戲的團隊；當目標係令 AI 生成的角色「有心事」而不只是「有表情」，呢個項目的取向相當實用。
想像你一邊改文字指令，一邊即時見到角色順住路徑、姿勢同目標動起來。ARDY把可控性同即時回應拉到同一個工作流入面。
一邊輸入文字、一邊指定角色要去邊、幾時抬手或者身體要擺成咩姿勢，系統仍然可以即時生成自然動作；ARDY瞄準的正正是呢種互動式 3D human motion generation 場景。呢類能力對動畫、模擬同 humanoid robotics 都重要，因為傳統離線方法雖然控制精準，但速度未必跟得上互動需求；純即時方法又常常在語意理解、長距離目標同約束服從度上打折扣。
ARDY 採用 autoregressive diffusion model，同時配合 hybrid representation，把角色移動軌跡相關的 root features 同 latent body embedding 結合。咁樣做的用意很直接：一方面保留對路徑與朝向的明確控制，另一方面維持生成模型學習複雜全身動作時的效率與彈性。配合 two-stage autoregressive transformer denoiser，同一套框架可以處理 online text prompting，亦能接住較長時間範圍的 kinematic constraints。
它支援的約束方式幾完整，包括 root paths、waypoints、full-body keyframes，以及 sparse joint positions/rotations，亦可混合使用。更重要的是，約束唔一定只限當前生成視窗，較遠將來的目標都可以先講定，令角色更容易朝長程目標連續行動，而唔係每幾步就失去方向。
資料提到，ARDY 以大型 motion capture dataset 訓練，並直接用文字標籤與來自真實姿勢抽樣的 kinematic constraints 作條件，令模型原生學會受控生成。研究團隊亦展示了互動式 demo，涵蓋動態文字控制、關鍵幀約束、路徑跟隨同即時 locomotion control；定位上，它較適合需要邊調邊看結果的內容製作與研究場景。
由快手 Kling Team(快手) 與學界合作推出，UnityShots 把單鏡頭擴散模型改造成可保持人物、場景與聲音一致的多鏡頭敘事系統，並釋出 200 段基準測試集。
UnityShots 是一個研究性質的多鏡頭影音生成框架，核心任務是解決現有方法在長序列多鏡頭影片中難以維持人物、場景與聲音一致性的問題。它基於已有的單鏡頭影音擴散模型 LTX-2.3（22B 參數）建構，從一段結構化提示詞直接生成 3 至 9 個鏡頭的連續 .mp4 影片，確保角色容貌、場景光影與配音語音在各鏡頭間保持連貫。
現有做法通常依賴三種路線：端到端訓練固定長度序列但難以擴展、以記憶庫逐鏡頭生成但容量隨鏡頭數線性膨脹，或用大型語言模型規劃器調度預訓練生成器而缺乏多鏡頭感知骨幹。UnityShots 的切入點是引入邊界感知門控（Boundary-Aware Gating）與雙槽記憶機制：影片流維持兩個固定大小記憶槽，長期記憶（LTM）錨定開場鏡頭，短期記憶（STM）保留前一鏡頭尾部，兩者在每次剪接時由門控網路更新；音訊流則在每個鏡頭注入參考說話者 token，避免滑動音訊庫的負擔。另一個辨識度高的設計是透過 AdaLN 學習離散剪接類型先驗（cut-type prior），讓使用者可在推論階段調整轉場強度。
以下為重點摘要：
現有評估涵蓋 I2V、T2V、R2V 三種條件模式，UnityShots 在跨鏡頭一致性與音畫品質上與開源及閉源基準相當。對從事多鏡頭敘事、短影音自動化或數位人內容生成的團隊而言，這套框架提供了較完整的記憶與控制設計思路。原始資料庫明確指出，檢查點、訓練程式碼與代理系統尚未釋出，因此目前無法從儲存庫直接取得安裝指令或模型權重；讀者若有興趣部署，需等待官方後續發布。資料集本身可從 Hugging Face 的 KlingTeam/UnityShotsBench 下載，供研究者評測自家模型。授權為 CC BY-NC 4.0，僅限非商業學術用途。
GitHub： https://github.com/JIA-Lab-research/UnityShots
CF-World 以三層反事實框架，測試 T2I 模型是否真正理解因果，而非僅靠記憶統計關聯。
CF-World 是一個專門針對文生圖（text-to-image, T2I）模型的基準測試與研究原型，用以判斷模型在面對違反常識的指令時，到底是在推理，還是僅僅複製訓練數據中的高頻模式。現有的 T2I 模型在日常語境下表現出色，但只要物理法則被刻意改寫，例如要求它們生成「重力反轉」或「光線反向折射」的畫面，便會出現明顯崩潰。CF-World 採用三層遞進設計來暴露這種落差：L1 為事實生成，要求模型按真實世界知識作畫；L2 為顯式反事實（Explicit Counterfactual），同時提供反事實前提與指定的視覺結果，測試模型能否依指令調整；L3 為隱式反事實（Implicit Counterfactual），只給出反事實條件，要求模型自行推導應有的視覺呈現，從而考驗真正的因果推演能力。
為了量化這種落差，項目引入兩項指標：PRR（Prior Resistance Rate，先驗抵抗率）衡量模型擺脫既定視覺慣性的能力，RRR（Reasoning Retention Rate，推理保留率）則檢驗模型在多步驟指令下能否維持邏輯連貫性。儲存庫還包含因果解耦（Causal Decoupling）、屬性解耦（Attribute Decoupling）與去範式化（De-nominalization, De-norm）三條專門評測線，協助研究者區分失敗究竟源自因果變量無法分離，還是源自語言先驗的「概念鎖定」。
在評估對象方面，CF-World 涵蓋 FLUX.2-dev、Qwen-image、Nano Banana 等近期模型，結果顯示 L1 表現良好的模型在 L3 場景中普遍出現一致性急劇下降，說明高維統計先驗正在壓制真正的因果推理。代碼庫結構清晰：eval_questions 收錄預先生成的評測題目，prompt 存放基礎提示詞與反事實規則，scripts 則涵蓋題目生成及基於 VLM 的自動評分（支援 Gemini 與 Qwen3-VL）。對從事多模態模型評測、視覺推理研究或關心模型安全邊界的團隊而言，這個基準提供了一個可重現且分層細緻的測試平台，有助於定位「模型究竟卡在哪個環節」。
The repository is organized into prompts, pre-generated evaluation questions, and execution scripts:
├── eval_questions/ # Pre-generated evaluation questions (categorized by discipline)
│ ├── physics/ # Physics sub-disciplines (Astronomy, Mechanics, etc.)
│ └── ...
├── prompt/ # Raw base prompts and counterfactual rules
│ ├── physics/
│ └── ...
└── scripts/ # Core execution scripts
├── generate_eval/ # Scripts to generate evaluation questions
│ ├── gemini.py # Generates standard CF-World questions via Gemini
│ └── rule_decouple.py # Generates questions for the Causal Decoupling experiment
└── score/ # Automated VLM-based scoring scripts
├── gemini.py # Standard multi-dimensional scoring using Gemini
├── qwen3vl-235b.py# Standard multi-dimensional scoring using Qwen3-VL
├── rule_decouple.py # Scoring for the Causal Decoupling experiment
├── attribute_decouple.py # Scoring for the Attribute Decoupling experiment
└── denorm.py # Scoring for the De-nominalization (De-norm) experiment
GitHub： https://github.com/jylei16/CF-World
PerceptionDLM 把多個區域描述改成並行生成，重點不是只追準確度，而是連速度一齊納入比較。
現時不少 Multimodal Large Language Models (MLLMs) 做區域描述時，仍然依賴 autoregressive (AR) 逐段生成：一張圖有幾多個 mask，就要逐個區域慢慢解讀。PerceptionDLM 提出的方向很明確，改用 Multimodal Diffusion Language Model，同一輪 denoising process 內同時輸出多個區域描述，目標是解決多區域感知在延遲上隨數量線性上升的問題。
這是一個偏向模型加基準測試的開源項目：核心是 PerceptionDLM 與 PerceptionDLM-Base，另加 ParaDLC-Bench、PerceptionDLM-Data 和 Bee / Honey 系列訓練資料配方。作者點名批評舊範式主要卡在 autoregressive region captioning，因此加入 efficient prompting 與 structured attention masking，讓平行生成不只停留在概念，而是落到 sequence level 同 token level。
從公開資料看，這個項目較適合以 Hugging Face 已釋出的模型、資料集與 evaluation suite 來理解和測試；想重現結果的人，亦可沿住訓練資料配方、Training 與 Evaluation 流程部署。對一般開發團隊而言，最有參考價值的不是安裝細節，而是它示範了 diffusion VLM 怎樣處理「多區域同時描述」這種以往較少由 DLM 承擔的任務。
它較適合做視覺理解、圖像標註、自動資料整理，或者需要一次看多個區域的研究團隊。限制也很清楚：目前公開資訊主力強調 benchmark 與吞吐提升，對一般產品場景的記憶體需求、延遲分佈與部署成本仍要再看實測；相關模型則包括 PerceptionDLM、PerceptionDLM-Base，以及其 backbone LLaDA-8B-Instruct，對比對象則有 LLaDA-V。
GitHub： https://github.com/MSALab-PKU/PerceptionDLM
項目主頁： https://msalab-pku.github.io/projects/PerceptionDLM/index.html
項目： https://huggingface.co/collections/MSALab/perceptiondlm-model-zoo
這項研究指出，不同檢索器需要不同改寫策略。把 retrieval 當成同一種工具呼叫，效果未必最好。
不少 Retrieval-augmented generation 都把 retrieval 視為通用步驟：先改寫問題，再交給任何檢索器處理。這項論文反對這種 fixed generic tool-call 範式，認為限制在於查詢寫法會受檢索環境影響，同一句問題交給 BM25、Contriever、all-MiniLM-L6-v2 或 Qwen3-Embedding，最佳表達方式可以完全不同，因此提出 Environment-aware Information Retrieval 這個設定，專門研究 LLM 如何因應 retriever 改寫查詢。
項目本質上是研究型框架與實驗資源，用來解決「RAG 查詢改寫是否應按檢索器調整」這個問題。作者用 reinforcement learning（RL）訓練 query rewriter，並以 nDCG@10 當 reward；重點不只是答對與否，而是觀察模型會否學到不同 retriever 對應的語言風格。
不同檢索器之間的策略難以轉移，主要不是 search intent 變了，而是查詢的 structural 或 stylistic 形式不對。例子很清楚，BM25 偏好精簡 keyword-style queries，Contriever 則更受 document-like、statement-style rewrites 幫助；作者亦加入 retriever-specific human guidance 改善 RL 探索，並用 branching rollout 穩定 multi-turn retrieval 訓練中的 credit assignment。
如果你想測試這個項目，做法是挑同一批問題，分別接到 BM25 與 embedding-based retriever，比較原始問題、改寫後查詢，以及 nDCG@10 變化。做 RAG pipeline、query rewriting、search quality tuning 的人會特別啱用；對一般應用團隊來說，這份研究也提醒了一點：不要假設一套 prompt 或 rewrite policy 可以通吃所有 retrieval backend。
整體來看，這不是靠更大模型硬推效果，而是重新檢視「查詢應怎樣配合檢索器」這個常被忽略的步驟。若後續公開更多 benchmark 細節與可重現結果，這個方向有機會成為 RAG 調校中的實用基線，而不只是論文中的觀察。
GitHub： https://github.com/LCO-Embedding/Envs-aware-Information-Retrieval