寫東西只為了抒發，一切隨緣不為流量
有事找 @finalfantasty
👻 個人博客 Blog: https://blog.pdzeng.com
👻 個人微博客 Blog:
https://daily.pdzeng.com/
有事找 @finalfantasty
👻 個人博客 Blog: https://blog.pdzeng.com
👻 個人微博客 Blog:
https://daily.pdzeng.com/
Olanetsoft/midnight-mcp
🔗 https://github.com/Olanetsoft/midnight-mcp
#github
🔗 https://github.com/Olanetsoft/midnight-mcp
#github
GitHub
GitHub - Olanetsoft/midnight-mcp: Midnight MCP server giving AI assistants access to Midnight blockchain — search contracts, analyze…
Midnight MCP server giving AI assistants access to Midnight blockchain — search contracts, analyze code, explore docs - Olanetsoft/midnight-mcp
Murmur Voice v0.3.3 更新日誌
* 全螢幕覆蓋支援 (macOS) - 主視窗和轉錄預覽現在可以正確顯示在全螢幕應用程式上方。無論你在用 Keynote 簡報、全螢幕寫 Code、還是看影片，Murmur 都能即時浮現。
* 智慧顯示/隱藏 - 錄音時主視窗自動出現，轉錄完成約 3 秒後自動收起，不佔畫面空間。透過系統列的「顯示/隱藏」可手動控制，不受自動隱藏影響。
* ESC 取消錄音 - 錄到一半發現不對？按 ESC 即可取消，不會觸發轉錄，直接回到待機狀態。
* 輔助使用權限自動偵測 - macOS 上會自動偵測「輔助使用」權限狀態，未授權時每 3 秒自動重試，授權後立即生效，不需重啟。
安全性與效能
* 修復 CSP 安全漏洞，移除 unsafe-inline
* 模型下載改為非同步 I/O，不再阻塞介面
* Whisper 執行緒數自動最佳化
* 前端 DOM 快取，減少重複查詢
Murmur Voice — 免費、開源、完全離線的語音轉文字工具，支援 macOS 與 Windows。
GitHub: https://github.com/panda850819/murmur-voice/releases/tag/v0.3.3
* 全螢幕覆蓋支援 (macOS) - 主視窗和轉錄預覽現在可以正確顯示在全螢幕應用程式上方。無論你在用 Keynote 簡報、全螢幕寫 Code、還是看影片，Murmur 都能即時浮現。
* 智慧顯示/隱藏 - 錄音時主視窗自動出現，轉錄完成約 3 秒後自動收起，不佔畫面空間。透過系統列的「顯示/隱藏」可手動控制，不受自動隱藏影響。
* ESC 取消錄音 - 錄到一半發現不對？按 ESC 即可取消，不會觸發轉錄，直接回到待機狀態。
* 輔助使用權限自動偵測 - macOS 上會自動偵測「輔助使用」權限狀態，未授權時每 3 秒自動重試，授權後立即生效，不需重啟。
安全性與效能
* 修復 CSP 安全漏洞，移除 unsafe-inline
* 模型下載改為非同步 I/O，不再阻塞介面
* Whisper 執行緒數自動最佳化
* 前端 DOM 快取，減少重複查詢
Murmur Voice — 免費、開源、完全離線的語音轉文字工具，支援 macOS 與 Windows。
GitHub: https://github.com/panda850819/murmur-voice/releases/tag/v0.3.3
GitHub
Release Murmur Voice v0.3.3 · panda850819/murmur-voice
What's New
Auto-hide main window — main window auto-shows on recording, auto-hides ~3s after transcription. Tray Show/Hide toggle overrides auto-hide behavior
ESC cancel recording — press ESC ...
Auto-hide main window — main window auto-shows on recording, auto-hides ~3s after transcription. Tray Show/Hide toggle overrides auto-hide behavior
ESC cancel recording — press ESC ...
▶️ Head of Claude Code: What happens after coding is solved | Boris Cherny #youtube
https://www.youtube.com/watch?v=We7BZVKbCVw
https://www.youtube.com/watch?v=We7BZVKbCVw
allen-hsu/clawhuddle
🔗 https://github.com/allen-hsu/clawhuddle
#github
🔗 https://github.com/allen-hsu/clawhuddle
#github
GitHub
GitHub - allen-hsu/clawhuddle: Self-hosted OpenClaw for teams — Give every person on your team their own AI assistant. Each team…
Self-hosted OpenClaw for teams — Give every person on your team their own AI assistant. Each team member gets an isolated OpenClaw instance with zero maintenance. You add people, the system handle...
傳統的垂直領域軟體將業務邏輯編碼在程式碼中。成千上萬個 if/then 分支、驗證規則、合規檢查、審批工作流。由工程師歷經多年硬編碼而成……而且不只是普通的工程師。你需要真正理解該領域的軟體工程師，而這非常罕見。要找到一個既能編寫正式環境程式碼，又理解訴訟工作流實際運作方式，或現金流量折現（DCF）模型應如何構建的人，是極其困難的。修改這些業務邏輯需要開發週期、品質保證（QA）和部署。
讓我舉一個我親身經歷的具體例子。
在 Doctrine，我們建立了一套法律研究工作流程，協助律師針對特定的法律問題尋找相關判例。該系統需要理解法律領域（民事、刑事或行政）、將問題解析為可搜尋的概念、跨多個法院資料庫進行查詢、按相關性和權威性對結果進行排名，並提供正確的引用脈絡。打造這套系統耗費了由工程師和法律專家組成的團隊數年時間。其業務邏輯分散在數千行 Python 程式碼、自定義排名演算法和手動調整的相關性模型中。每一次修改都需要經過工程衝刺（sprints）、程式碼審查、測試和部署。
在 Fintool，我們有一項 DCF（現金流量折現法）估值技能。它會告訴 LLM 代理如何進行現金流量折現分析：要收集哪些數據、如何按行業計算 WACC（加權平均資本成本）、要驗證哪些假設、如何進行敏感度分析，以及何時應將股份報酬（SBC）加回。這只是一個 Markdown 檔案。編寫它花了一週時間，而更新它只需幾分鐘。一位做過 500 次 DCF 估值的投資組合經理，無需編寫任何一行程式碼，就能將其整套方法論編碼進去。
數年的工程開發對比一週的寫作。這就是轉變所在。
而且這不僅僅是速度的問題。Markdown 技能在重要方面表現得更好。它對任何人來說都是可讀的、可審計的，並且可以根據每個使用者進行客製化（我們的客戶會編寫自己的技能）。此外，隨著底層模型的改進，它會自動變得更好，而無需我們動任何一行程式碼。
商業邏輯正在從由專業工程師編寫的程式碼，遷移到任何具備領域專業知識的人都能編寫的 Markdown 檔案。垂直領域軟體公司花費十年累積的商業邏輯，現在幾週內就能被複製。工作流護城河正在迅速瓦解。"
讓我舉一個我親身經歷的具體例子。
在 Doctrine，我們建立了一套法律研究工作流程，協助律師針對特定的法律問題尋找相關判例。該系統需要理解法律領域（民事、刑事或行政）、將問題解析為可搜尋的概念、跨多個法院資料庫進行查詢、按相關性和權威性對結果進行排名，並提供正確的引用脈絡。打造這套系統耗費了由工程師和法律專家組成的團隊數年時間。其業務邏輯分散在數千行 Python 程式碼、自定義排名演算法和手動調整的相關性模型中。每一次修改都需要經過工程衝刺（sprints）、程式碼審查、測試和部署。
在 Fintool，我們有一項 DCF（現金流量折現法）估值技能。它會告訴 LLM 代理如何進行現金流量折現分析：要收集哪些數據、如何按行業計算 WACC（加權平均資本成本）、要驗證哪些假設、如何進行敏感度分析，以及何時應將股份報酬（SBC）加回。這只是一個 Markdown 檔案。編寫它花了一週時間，而更新它只需幾分鐘。一位做過 500 次 DCF 估值的投資組合經理，無需編寫任何一行程式碼，就能將其整套方法論編碼進去。
數年的工程開發對比一週的寫作。這就是轉變所在。
而且這不僅僅是速度的問題。Markdown 技能在重要方面表現得更好。它對任何人來說都是可讀的、可審計的，並且可以根據每個使用者進行客製化（我們的客戶會編寫自己的技能）。此外，隨著底層模型的改進，它會自動變得更好，而無需我們動任何一行程式碼。
商業邏輯正在從由專業工程師編寫的程式碼，遷移到任何具備領域專業知識的人都能編寫的 Markdown 檔案。垂直領域軟體公司花費十年累積的商業邏輯，現在幾週內就能被複製。工作流護城河正在迅速瓦解。"
"2. 客製化工作流程與商業邏輯 → 煙消雲散
垂直領域軟體編碼了該行業的實際運作方式。一個法律研究平台不只是儲存判例法，它還編碼了引用網絡、Shepardize 訊號、判決要旨分類，以及訴訟律師助理撰寫書狀的特定方式。
這些商業邏輯耗費多年才建立完成，反映了與領域專家成千上萬次的對話。當我建立 Doctrine 時，最難的部分不是技術，而是理解律師究竟如何工作：他們如何研究判例法、如何起草文件、如何從受理案件到審判建立訴訟策略。將這種理解編碼進可運行的軟體中，是垂直領域軟體之所以有價值且具備防禦力的重要原因。
LLMs 將這一切轉換為一個 markdown 檔案。
這是最被低估的轉變，而且我認為從長期來看，這也是最具毀滅性的。
https://www.facebook.com/share/1777oYdSaz/?mibextid=wwXIfr
放棄吧，不要再看 AI 寫的 Code 了！
前幾天跟一位工程師討論案子規格，他說：「我不太放心讓 AI 全權開發，祂會疊床架屋，明明一樣的東西在不同地方寫成兩套，以後很難維護。」
所以他都會去審核 AI 寫的程式。
我跟他說：「放棄吧，不要再看祂寫的 code 了。」
⸻
🎯 我建議應該這樣做：
1. 讓 AI 自己去 review 祂寫的 code
2. 讓祂提出改進方案並改完
3. 讓祂做完測試
我們要的是最後的結果。
你可以請祂加上 Regression Test，確保祂改的東西不會嚴重影響其他地方。
因為——你再怎麼看 code、再怎麼寫 code，都比不上祂。而且祂進步的速度，比任何軟體工程師都快太多了。
⸻
💡 這讓我想到一件事
軟體工程師剛升主管時，最常犯的錯：自己下去 coding。
以前我帶這些新手主管，都會特別跟他們講：
1. 綁住你的手腳
2. 不要做部屬該做的事
3. 就算覺得不完美，也要接受——否則永遠改不完，而且之後你的部屬會反過來盯著你追進度。
現在碰到的情況一模一樣。
只是這次，這個「部屬」比你更厲害：寫程式更快、學習更快，發展潛力無可限量。
⸻
🔥 這是我接觸軟體產業三十多年來，碰到最大的巨變
你可以選擇忽略祂，但祂的高速發展不會因為你的忽略而改變。
你也可以選擇接受祂，讓祂變成你的超級部屬。
不要再想著去看祂的 Code 了。許多傳統軟體工程機制都會面臨巨大改變：
• 傳統的 Code Review 機制
• 傳統的 Waterfall 流程
• 傳統的 CI/CD、Regression Test
這些將全部被 AI 接管，只是時間早晚的問題，所以——就接受這一切吧。
⸻
📍 寫 Code 不是瓶頸，Review 才是
很多人還在糾結 AI 寫的 code 品質好不好。
但真正用過的人都知道：寫 code 從來不是瓶頸。
瓶頸在哪？
1. 規劃——你自己都沒想清楚要什麼
2. Review——你花更多時間審核，而不是產出
有個十年經驗的工程師說得很直白：「我用 Claude Code 的工作流變成：丟一個模糊 prompt，跑出錯誤結果，反覆迭代，最後發現自己寫還比較快。」
但這問題不在 AI，問題在他還想「審核」每一行。而且這是「現在」，過一週或一個月後，有了新版 LLM，AI 的能力又會上升到另一個等級，任何「人」的 Review 都追不上祂的進化。
當你把 Review 的時間省下來，讓 AI 自己 Review 自己，整個生產力才會真正爆發。
⸻
⚔️ 回應那些擔憂的聲音
「AI 寫的 code 有安全漏洞！」
前陣子 BBC 才報導一個 vibe-coding 平台被駭的新聞。
但我要說：那是平台的問題，不是 AI 的問題。
你讓 AI 幫你做資安檢測，祂會比人類更徹底。我的經驗是，多跑幾輪，每輪都會有新的資安問題被提出。你要做的是決定哪些要改——決策權在你，讓 AI 解釋問題嚴重性並提供建議，你來做決定。
工具沒有對錯，用法才有。資安本身就是強度與體驗的 tradeoff，沒有最好，只有剛好。
「成熟 codebase 上 AI 不好用！」
這是很常見的藉口。
「我們的 codebase 太複雜了，AI 看不懂。」
真的嗎？還是你沒給祂足夠的 context？
我看到的現實是：成熟 codebase 上，AI 反而更有價值。因為沒有人比 AI 更快讀完幾萬行程式碼。你花三天搞懂的架構，祂三分鐘就理解了。
問題不在 AI，問題在你還沒學會怎麼用。
⸻
🚀 我想補充我之前說過的話
上週我寫過一篇文章「砍掉 UIUX 設計師、前端及後端工程師，留下自己和 Claude AI，網站功能迭代更新加速 10 倍！」，提到「這套模式的邊界」：
大型企業系統、需要高度資安合規的金融產品、百萬級併發的基礎設施、需要長期維護的大型 codebase，這些仍然需要專業團隊。
現在我想更新這個想法。
邊界正在消失。
一年前，我覺得 AI 只適合做 MVP。現在，我用 AI 在成熟產品上迭代，速度一樣快。
六個月前，我覺得複雜架構需要人來設計。現在，AI 設計的架構比我想的還周全。
一個月前，我覺得資安合規一定要專家。現在，AI 做的安全檢測比大多數資安工程師還徹底。
這個邊界不是固定的，它正在以超乎想像的速度縮小。
⸻
🕰 2000 年的既視感
這讓我想起 2000 年網路泡沫時，那些「專家」說的話：
「信用卡被盜刷的新聞層出不窮，誰敢在網路上刷卡消費。」
「網路不是剛需，人們的吃喝拉撒睡才是，網路的虛擬世界永遠取代不了人類生活實體需求。」
但如今呢？
你上一次不是用線上支付或線上刷卡買東西是什麼時候？
你的生活有多少比例已經「活在網路上」？
當年那些畫邊界的人，現在看起來多可笑。
「大公司的軟體無法被 AI 接管」——這句話，和當年說「網路無法取代實體」一樣天真。
這件事不可避免的趨勢已經很明顯了，只是時間早晚的問題。
以現在 AI 發展的態勢，很快就會蔓延到各大企業內部。
沒有公司能倖免。
⸻
🛠 給還在掙扎的工程師——四個具體解法
1. 擔心疊床架屋？
直接問祂：「請檢查有沒有類似的 code 在不同地方出現，給我一份報告。等我確認後再改。」
一兩個 prompt 就解決。
2. 擔心資安問題？
「請進行徹底的安全檢測，把可能漏洞列成清單，由我決定哪些要改。」
可以跑好幾輪。我的經驗是，幾乎每輪都會有新的資安問題被提出——但不是每項都需要改，決定權在你手中。
3. 擔心邊做邊改影響已上線的服務？
請祂把程式碼分成開發和產品兩個 branch。跟祂講清楚：「所有新東西先加在開發 branch，只有當我說要 merge，才放到產品 branch。」
4. 擔心新功能把舊功能改壞？
請祂建立 Regression Test，寫好 Test Cases。開發到一個段落後，請祂跑測試，並把新增的功能也加進 Test Cases。
⸻
🤔 最後一點
以上所有事情，你也可以用不同 LLM 互相驗證，例如用 Claude 生產，用 Gemini 測試。
若用同一個 LLM 其實就不需要分不同 AI 角色，因為 AI 不會為了隱藏自己生成的程式中的 bug，而故意不揭露——這不是 AI 目前會做的事，除非你要祂這麼做。
⸻
✍️ 結語
三十年來最大的巨變已經發生。
問題不是 AI 會不會取代你——
問題是，你願不願意讓祂成為你的超級部屬。
而那些還在畫邊界的人，很快就會發現：
邊界不是用來守的，是用來被打破的。
2000 年，有人說網路不會改變人們實體生活。
2026 年，有人說 AI 不會接管所有軟體開發。
歷史會證明，他們都錯了。
https://www.facebook.com/share/p/189sEiQACx/?mibextid=wwXIfr
前幾天跟一位工程師討論案子規格，他說：「我不太放心讓 AI 全權開發，祂會疊床架屋，明明一樣的東西在不同地方寫成兩套，以後很難維護。」
所以他都會去審核 AI 寫的程式。
我跟他說：「放棄吧，不要再看祂寫的 code 了。」
⸻
🎯 我建議應該這樣做：
1. 讓 AI 自己去 review 祂寫的 code
2. 讓祂提出改進方案並改完
3. 讓祂做完測試
我們要的是最後的結果。
你可以請祂加上 Regression Test，確保祂改的東西不會嚴重影響其他地方。
因為——你再怎麼看 code、再怎麼寫 code，都比不上祂。而且祂進步的速度，比任何軟體工程師都快太多了。
⸻
💡 這讓我想到一件事
軟體工程師剛升主管時，最常犯的錯：自己下去 coding。
以前我帶這些新手主管，都會特別跟他們講：
1. 綁住你的手腳
2. 不要做部屬該做的事
3. 就算覺得不完美，也要接受——否則永遠改不完，而且之後你的部屬會反過來盯著你追進度。
現在碰到的情況一模一樣。
只是這次，這個「部屬」比你更厲害：寫程式更快、學習更快，發展潛力無可限量。
⸻
🔥 這是我接觸軟體產業三十多年來，碰到最大的巨變
你可以選擇忽略祂，但祂的高速發展不會因為你的忽略而改變。
你也可以選擇接受祂，讓祂變成你的超級部屬。
不要再想著去看祂的 Code 了。許多傳統軟體工程機制都會面臨巨大改變：
• 傳統的 Code Review 機制
• 傳統的 Waterfall 流程
• 傳統的 CI/CD、Regression Test
這些將全部被 AI 接管，只是時間早晚的問題，所以——就接受這一切吧。
⸻
📍 寫 Code 不是瓶頸，Review 才是
很多人還在糾結 AI 寫的 code 品質好不好。
但真正用過的人都知道：寫 code 從來不是瓶頸。
瓶頸在哪？
1. 規劃——你自己都沒想清楚要什麼
2. Review——你花更多時間審核，而不是產出
有個十年經驗的工程師說得很直白：「我用 Claude Code 的工作流變成：丟一個模糊 prompt，跑出錯誤結果，反覆迭代，最後發現自己寫還比較快。」
但這問題不在 AI，問題在他還想「審核」每一行。而且這是「現在」，過一週或一個月後，有了新版 LLM，AI 的能力又會上升到另一個等級，任何「人」的 Review 都追不上祂的進化。
當你把 Review 的時間省下來，讓 AI 自己 Review 自己，整個生產力才會真正爆發。
⸻
⚔️ 回應那些擔憂的聲音
「AI 寫的 code 有安全漏洞！」
前陣子 BBC 才報導一個 vibe-coding 平台被駭的新聞。
但我要說：那是平台的問題，不是 AI 的問題。
你讓 AI 幫你做資安檢測，祂會比人類更徹底。我的經驗是，多跑幾輪，每輪都會有新的資安問題被提出。你要做的是決定哪些要改——決策權在你，讓 AI 解釋問題嚴重性並提供建議，你來做決定。
工具沒有對錯，用法才有。資安本身就是強度與體驗的 tradeoff，沒有最好，只有剛好。
「成熟 codebase 上 AI 不好用！」
這是很常見的藉口。
「我們的 codebase 太複雜了，AI 看不懂。」
真的嗎？還是你沒給祂足夠的 context？
我看到的現實是：成熟 codebase 上，AI 反而更有價值。因為沒有人比 AI 更快讀完幾萬行程式碼。你花三天搞懂的架構，祂三分鐘就理解了。
問題不在 AI，問題在你還沒學會怎麼用。
⸻
🚀 我想補充我之前說過的話
上週我寫過一篇文章「砍掉 UIUX 設計師、前端及後端工程師，留下自己和 Claude AI，網站功能迭代更新加速 10 倍！」，提到「這套模式的邊界」：
大型企業系統、需要高度資安合規的金融產品、百萬級併發的基礎設施、需要長期維護的大型 codebase，這些仍然需要專業團隊。
現在我想更新這個想法。
邊界正在消失。
一年前，我覺得 AI 只適合做 MVP。現在，我用 AI 在成熟產品上迭代，速度一樣快。
六個月前，我覺得複雜架構需要人來設計。現在，AI 設計的架構比我想的還周全。
一個月前，我覺得資安合規一定要專家。現在，AI 做的安全檢測比大多數資安工程師還徹底。
這個邊界不是固定的，它正在以超乎想像的速度縮小。
⸻
🕰 2000 年的既視感
這讓我想起 2000 年網路泡沫時，那些「專家」說的話：
「信用卡被盜刷的新聞層出不窮，誰敢在網路上刷卡消費。」
「網路不是剛需，人們的吃喝拉撒睡才是，網路的虛擬世界永遠取代不了人類生活實體需求。」
但如今呢？
你上一次不是用線上支付或線上刷卡買東西是什麼時候？
你的生活有多少比例已經「活在網路上」？
當年那些畫邊界的人，現在看起來多可笑。
「大公司的軟體無法被 AI 接管」——這句話，和當年說「網路無法取代實體」一樣天真。
這件事不可避免的趨勢已經很明顯了，只是時間早晚的問題。
以現在 AI 發展的態勢，很快就會蔓延到各大企業內部。
沒有公司能倖免。
⸻
🛠 給還在掙扎的工程師——四個具體解法
1. 擔心疊床架屋？
直接問祂：「請檢查有沒有類似的 code 在不同地方出現，給我一份報告。等我確認後再改。」
一兩個 prompt 就解決。
2. 擔心資安問題？
「請進行徹底的安全檢測，把可能漏洞列成清單，由我決定哪些要改。」
可以跑好幾輪。我的經驗是，幾乎每輪都會有新的資安問題被提出——但不是每項都需要改，決定權在你手中。
3. 擔心邊做邊改影響已上線的服務？
請祂把程式碼分成開發和產品兩個 branch。跟祂講清楚：「所有新東西先加在開發 branch，只有當我說要 merge，才放到產品 branch。」
4. 擔心新功能把舊功能改壞？
請祂建立 Regression Test，寫好 Test Cases。開發到一個段落後，請祂跑測試，並把新增的功能也加進 Test Cases。
⸻
🤔 最後一點
以上所有事情，你也可以用不同 LLM 互相驗證，例如用 Claude 生產，用 Gemini 測試。
若用同一個 LLM 其實就不需要分不同 AI 角色，因為 AI 不會為了隱藏自己生成的程式中的 bug，而故意不揭露——這不是 AI 目前會做的事，除非你要祂這麼做。
⸻
✍️ 結語
三十年來最大的巨變已經發生。
問題不是 AI 會不會取代你——
問題是，你願不願意讓祂成為你的超級部屬。
而那些還在畫邊界的人，很快就會發現：
邊界不是用來守的，是用來被打破的。
2000 年，有人說網路不會改變人們實體生活。
2026 年，有人說 AI 不會接管所有軟體開發。
歷史會證明，他們都錯了。
https://www.facebook.com/share/p/189sEiQACx/?mibextid=wwXIfr
https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-1-pro/
Gemini 3.1 Pro 今天發布（2026-02-19） ⭐️ 7/10
Google 繼上週 Gemini 3 Deep Think 後，今天推出 3.1 Pro。
關鍵數字
- ARC-AGI-2（測試解決全新邏輯模式的能力）：**77.1%**
- 比 3 Pro 的推理能力**翻倍以上**
現在可以用的地方
- 開發者（preview）：Gemini API / AI Studio / Gemini CLI / **Google Antigravity**（新的 agentic 開發平台）/ Android Studio
- 企業：Vertex AI / Gemini Enterprise
- 消費者：Gemini App / NotebookLM（限 Pro / Ultra 用戶）
值得注意的新東西
Google Antigravity — 第一次看到這個名字，Google 稱之為「agentic development platform」，感覺是他們的 agent 開發工具鏈，值得去看。
展示亮點
- 直接從文字 prompt 生成可嵌入網頁的動態 SVG
- 建立 ISS 即時軌道追蹤 dashboard
- 複雜 3D 動畫 + 手勢互動 + 生成式音樂
目前是 preview，Google 說還在驗證、會很快 GA。
Gemini 3.1 Pro 今天發布（2026-02-19） ⭐️ 7/10
Google 繼上週 Gemini 3 Deep Think 後，今天推出 3.1 Pro。
關鍵數字
- ARC-AGI-2（測試解決全新邏輯模式的能力）：**77.1%**
- 比 3 Pro 的推理能力**翻倍以上**
現在可以用的地方
- 開發者（preview）：Gemini API / AI Studio / Gemini CLI / **Google Antigravity**（新的 agentic 開發平台）/ Android Studio
- 企業：Vertex AI / Gemini Enterprise
- 消費者：Gemini App / NotebookLM（限 Pro / Ultra 用戶）
值得注意的新東西
Google Antigravity — 第一次看到這個名字，Google 稱之為「agentic development platform」，感覺是他們的 agent 開發工具鏈，值得去看。
展示亮點
- 直接從文字 prompt 生成可嵌入網頁的動態 SVG
- 建立 ISS 即時軌道追蹤 dashboard
- 複雜 3D 動畫 + 手勢互動 + 生成式音樂
目前是 preview，Google 說還在驗證、會很快 GA。
Google
Gemini 3.1 Pro: A smarter model for your most complex tasks
3.1 Pro is designed for tasks where a simple answer isn’t enough.
