上一篇測了 Cloudflare Workers AI 的 FLUX.1 Schnell
這次換另外一顆:
@cf/black-forest-labs/flux-2-klein-4b這顆我覺得比 Schnell 更適合真的拿來做 Blog 圖片
原因很簡單,它可以直接設定圖片的寬高,也支援 seed , width , height ,所以如果我要 16:9,不用自己再裁圖
直接指定 1280 x 720 就可以
上一篇測了 Cloudflare Workers AI 的 FLUX.1 Schnell
這次換另外一顆:
@cf/black-forest-labs/flux-2-klein-4b這顆我覺得比 Schnell 更適合真的拿來做 Blog 圖片
原因很簡單,它可以直接設定圖片的寬高,也支援 seed , width , height ,所以如果我要 16:9,不用自己再裁圖
直接指定 1280 x 720 就可以
最近我一直在找可以直接用 API 產圖,而且成本不要太誇張的服務
最後又回頭看了一下 Cloudflare Workers AI
Cloudflare 其實不只有文字模型,它也有提供圖片生成模型,其中一個就是
@cf/black-forest-labs/flux-1-schnell
實戰退休
在數位轉型快速演進的環境中,組織常常陷入傳統低效率與自動化承諾之間的困境。連接這兩種狀態的橋樑並非建立在猜測之上,而是依賴精確的可視化。業務流程模型和標記法 (BPMN) 已成為映射這些工作流的全球標準,提供了一種通用語言,彌合了業務利益相關者與技術實施者之間的差距。
OpenAI Dots、Grok Bot、Muse、Hermes 與 OpenClaw 都能執行多步驟任務,但定位各不相同。本文比較五者的特色、適用場景、共同點與差異,並提供選型建議。
在系統分析與設計的領域中,清晰度至關重要。開發人員和分析師面臨的最常見陷阱之一是僅依賴視覺圖表或僅依賴文字描述。真正的力量在於兩者的結合。
如果你曾負責過跨國資產配置或大中華區股票量化策略開發,一定碰過這種讓人抓狂的場景:回測時,你在本地硬碟讀取預先清洗好的分K歷史資料,各項指標與回報率漂亮得無可挑剔;然而一把策略部署到模擬盤或實盤,切換到實時串流時,整個程式卻彷彿人格分裂。
在現代軟體開發、產品管理與技術寫作中,單純的文字描述往往難以完整呈現複雜的系統架構、業務流程或數據關係。圖表能幫助讀者快速理解結構、序列、依賴關係與工作流,但傳統的文檔工作流程卻常面臨一個痛點:圖表與文字是分離的。使用者通常需要在獨立的繪圖工具中製作圖表,匯出為靜態圖片(如 PNG 或 SVG),再手動上傳至文檔系統。一旦需求變更,整個過程必須重複進行,不僅耗時,還容易導致圖表過時或版本混亂。
上一篇已經讓 .NET 10 ASP.NET Core 支援 MCP,OpenCode 也可以直接呼叫 UpdateHoroscope 去修改網站上的雙子座運勢
不過上一篇是直接連 http://localhost:5100/mcp
在现代敏捷软件开发中,保持“单一事实来源”(Single Source of Truth)至关重要。Visual Paradigm 一直是建模领域的强大工具,但其真正的魔力在于各个工具之间的无缝连接。Pipeline(管道) 正是这一生态系统的核心枢纽,它充当了图表创建、代码生成和动态文档之间的“结缔组织”。
如果你在專業交易圈或基金公司開發部門工作,你會發現 R-Breaker 的挑戰不只是指標公式。以一位大學金融系講師、同時也是創業踩坑總結者的角度來看,真正影響策略能否上線的,是即時行情資料、更新頻率、斷線處理與訊號觸發。
以下會用「研究痛點 → 資料需求 → 支援實作 → 學術價值」的順序,並以高可擴展性為核心,帶你用第二人稱視角,把 R-Breaker 接到外匯、股票、黃金與即時行情資料。
最近在測 MCP,一開始看很多範例都是 Echo、GetWeather,Code 可以跑,但是我自己還是覺得有點難看出實際可以拿來幹嘛
所以這次換一個簡單一點的案例,讓你直接體驗 MCP 對於製作網站可以幹嘛
公司把規則只能在內網登入的Azure AI Foundry鎖了, Azure CLI也鎖了, 只能用API打了
在物件導向分析與設計(OOA/D)的領域中,類-職責-協作者(Class-Responsibility-Collaborator,簡稱 CRC)卡片一直是一項經典且強大的技術。它幫助團隊在編寫任何程式碼之前,透過輕量級的方式對系統架構進行頭腦風暴和驗證。然而,傳統上創建這些卡片往往涉及手動索引、使用便利貼或基本的繪圖工具——隨著系統變得複雜,這一過程可能非常耗時且容易出現不一致。
最近在玩 Orca 這套工具,發現它不只是一個 terminal 管理器,還內建了一套多 Agent 協調機制,叫做 orchestration。想法很單純:手上有 copilot、antigravity、opencode 好幾種 agent,如果每次都要自己開視窗、自己盯著它有沒有做完,人力成本太高了。這篇就來記錄一下怎麼用 orchestration 同時派工給這幾個 agent,順便整理一下踩過的幾個坑。

最近在看 API Client 驗證這一塊
一般除了 Token 之外,可能還會再加 DeviceId、Fingerprint 之類的資訊,用來判斷是不是原本那台 Client
但這些東西本質上還是 Client 傳一個值給 Server
如果真的想確認 Client 還是不是原本那個,就可以再多一層 Key Proof
前一陣子我在整理自己的美股監控小工具時,重新檢視了手邊的資料源。原本用的是富途 API,後來因為維護上的不便,轉而嘗試了雲端直連的 AllTick 行情介面。這篇文章記錄我的實際使用經驗,提供給同樣在評估「美股資料 API」的開發者參考。
在前後端分離、Web API、App Backend 或系統對系統 API 中,JWT(JSON Web Token) 是非常常見的驗證方式。