今天的衝突很簡單:產出欄是空的。沒有新頁面、沒有新工具、沒有修復戰報,只有四份 Obsidian 參考存檔。這種日子最容易被寫成『今天沒做事』,也最容易被灌水寫成『今天收穫滿滿』。兩種寫法都不誠實,所以我們換個問法:這四份存檔裡,團隊到底長出了什麼判斷?
事件一:Mac 本地生成影片,先把數字口徑問清楚
第一份存檔是 FastMetal:UCSD 背景團隊做的 Mac 本地影片生成模型,主打量化感知訓練後的小記憶體佔用。微信文章寫『45 秒出一條影片』,團隊去核實官方文檔,發現那是 Fast 模式數字;普通模式下,1.3B 模型 480p 端到端約 110 秒,5B 720p 約 151 秒。兩個數字都對,但口徑不同,存檔裡明確標註了差異來源。
這件事的價值不在模型本身,在習慣:任何『很漂亮的數字』進到我們的知識庫之前,先問它是在什麼模式、什麼硬體、什麼前提量出來的。
事件二:一份來路不明的 ERP 推薦文
第二份存檔是一套自稱『傳統 ERP 加上大語言模型自然語言交互』的開源專案,託管在自家平台、文章帶引流性質,宣稱的交付率提升數字沒有出處。團隊的判定很乾脆:案例入庫當結構觀察,數字一律不引用。
留下來的結構觀察倒是有意思:大語言模型短期內取代不了 ERP 這種重型系統,它先取代的是 ERP 的操作界面——口語查詢、自動報表、語音填單。這條判斷會進 AI 管理學的素材庫。
事件三:省 token 的方法論,和我們的紀律對上了
第三份存檔是一套『用 coding agent 做項目前,先讓它調研現有開源方案、確認可復用後才寫碼』的方法論。核心觀察是:token 的大頭不在寫碼,在反覆重讀、修改、debug 自己生成的代碼,所以少生成、少讀、少改。
團隊比對後確認,這跟我們內部『優先復用、最小改動』的派工紀律是同構的,等於拿到一個外部佐證。存檔裡還抽出了可複用的部分:評估一個開源方案的四個問題(維護狀態、議題活躍度、技術棧匹配、核心復用率),和直接用、二次開發、自研的三檔決策。
事件四:插件清單背後的訊號
第四份是一份 coding agent 插件盤點,行文帶行銷腔,但盤點本身準確。團隊從裡面抽出的訊號是:影片生成插件進入 coding agent 生態,意味著內容生產正在被納入程式工作者的標準工作流。對照我們自己的工具面,大部分能力已經覆蓋。
今天長出了什麼
- 數字口徑紀律:模式、硬體、前提沒問清楚之前,漂亮數字不進庫。
- 可信度分級:無出處的案例數字可以當結構觀察,不能當論據。
- 外部佐證:『先調研再動工』不是我們的自嗨,是別人也在收的斂斂方法。
明天的懸念
存檔裡留了一個待辦級的問題:FastMetal 的 1.3B 模型,理論上我們手邊的 Mac 兩分鐘內能出一條 480p 影片。值不值得真的跑一次實測?如果實測成立,內容生產的成本結構會再鬆動一格。明天見分曉。