VSCode 不要把子目錄中只有一個目錄的目錄,移到父目錄的右側

VS Code 檔案總管會把只有單一路徑的資料夾壓成 a/b/c 一行(Compact Folders),導致拖曳與瀏覽不便。本篇教你一鍵關閉 explorer.compactFolders,並附常見問題與進階縮排設定。[……]

閱讀更多

測試網站在中國大陸是否可開啟 (同時測不同地理位置),完全免費、免申請會員

你正在做個跨國網站或服務,但你不確定是否被中國防火牆封鎖,此時,以下工具就會變得很好用,即時從中國境內節點測試,這是我的筆記,試過覺得好用的與大家分享,完全免費、免加入會員、快速,每個站可能都會有不同的涵蓋位置,可以交叉使用,我專找不用會員就可以測試的網路工具,可以多測幾個站,

以下網路工具特色:

EXPERTE.com

China Firewall Test

[……]

閱讀更多

剛過完中秋節就看到 ChatGPT 發布重磅消息推出 AgentBuilder

說真的,這對做自動化的人來說有點衝擊。

因為如果你玩過 #n8n#Zapier,就知道那種拖拉式自動化流程有多方便——

結果現在 OpenAI 要自己做一個。還給不給人活路。

但重點是,這不只是「又一個 API」。

它是一個可視化畫布,可以拖拉元件、設定邏輯、加上審核流程,

直接在 OpenAI 裡完成多步驟的 Agent 工作流。

左邊是元件列表,右邊是即時預覽畫面,整個像在拼積木。

幾個亮點真的很猛:

* 邏輯節點:能做 if/else、分支、重試

* MCP 連接器:外部系統直接拉進來,不用再自己串

* 使用者審核與 guardrails:關鍵節點可人工確認

* 檔案搜尋與資料轉換模組:非結構化資料也能自動處理

用這些組件,可以拼出自動客服、資料補全、文件比對、審核流程…

而且這次不是「外部工具整合 OpenAI」,

而是 OpenAI 自己變成整合的中心。

開發者 Alexey Shabanov 形容這是「目前體驗最順暢的 Agent Builder 畫布」。

某種程度上,這就像把 n8n、Zapier 的核心功能原生化、嵌進 OpenAI 平台裡。

從這一刻開始,「自動化平台」和「AI 平台」的界線幾乎被抹平。

我自己會特別觀察兩件事:

1. 小團隊能不能用更少基礎建設,做出穩定又可審核的 AI 功能

2. 資料治理與人工審核能不能真的模組化,讓任何人都能拖出來用

也許未來我們不再是「串 AI」,

而是直接在 AI 裡「設計自動化」。

到那時,開發者的角色可能也要重新定義了。

[……]

閱讀更多

去x的,Google這招太奸詐了!

今天 AI Vibe Coding 界燒起來的一篇文章,苦主是一名講師兼開發者,利用 Google AI Studio Build Vibe Coding 方式開發了一個多功能圖片生成的 APP ,分享給大家使用,APP 中有寫了一個填入自己 API Key 的欄位,一切都好,直到收到一萬多元的刷卡訊息後驚覺不妙,原來填入 User API Key 的欄位的功能是假的,事實上是用自己綁定的 API Token 在燒錢,全世界都用他的 API Token 生圖,氣得作者以「去 X 的,Google 也太奸詐」為題發文,民俗月剛過還是有這種故事。

* 本來想說點什麼,看大家炮成這樣,我也來說點什麼 *

看到這個議題,如果是普通人就算了,如果是講師,傳遞正確觀念應該是有討論空間的,我覺得本件事也不全然是 Google 的問題,這裡與大家聊聊,這是個人主觀的觀點啦:

1. Vibe Coding:

我不能說 Vibe Coding 擠壓到我們的商業價值,的確 Vibe Coding 的方式的確降低了進入軟體領域的門檻,可以快速做出各式各樣看起來可以改變世界的有趣玩意,但我個人會把它定位成玩具,若是商業行為會把它定義為原型 (prototype),是一個把想法到實踐的第一個步驟。這是一個挺好的改變,不需要就圖面想像,可以更有利的爭取到投資或是有效與客戶溝通,跳過圖說這個步驟,簡化開發流程。

簡化開發流程,並不代表原型即產品。自己用風險可控,肯定沒問題;真正要上線運作的,面對不特定人的服務,還是需要一個產品化的過程,需要嚴格的檢查,因為你真的不知道 User 會怎麼用你的有趣服務,模擬各種情境,盡可能把低級錯誤降到最低。另外對於開發者本身也必須控制風險。

2. API Token 管理

此例,開發者知道 API Token 的成本問題,於是做了使用 User 自身提供的 API Token 的輸入框,這點很好。但這一段功能也是 vibe code 出來,卻沒做驗證的動作。AI 的確存了 User 的 API Token,只是沒用到,是個假功能(嚴格說也不是假功能),AI 覺得功能已完成,但開發者應該於功能完成後,與上線前都驗證功能是否為自己預期。最簡單的就是關閉自己開發的 API Token,來測試輸入的 Token 是否真的有用,其實這是可以避免的風險。

接著,API Token 是不能寫進 Code 裡的,這跟你把提款卡與密碼放在一起一樣,如果閉源服務就算了,要開源應該也要檢查一下,抄完別人考卷也要檢查一下班級、姓名座號有沒有不小心抄到。 

另外,聊聊 API Token 管理,應該要把開發用的 API Token 與自己的 Token 分離,必須限定額度、範圍。就像是信用卡一張用來買網購額度低一點,自己用的卡額度高一點,如果網購被盜刷,還在可以控制的範圍,這就是很簡單的生活例子。

另一個面向,使用者對於這些有趣的程式時,對於不信任的單位,有沒有防備的觀念?好好保存你的 API Token,思考一下有沒有可能被騙走的 API Token。技術上盜走你的 Token 比盜刷你信用卡簡單,不要覺得沒什麼。記得口罩地圖嗎?新冠疫情期間工程師大哥開發了方便大眾使用的口罩地圖聲名大噪,但收到帳單臉都綠了,60 多萬。Google 商用 API 都是要錢的,不是免費的,用一筆算一筆的,這金額是無上限的。

3. LLM 養、套、殺

說「太奸詐」有點過於嚴厲,這就是商業,一個願打一個願挨。

大型語言模型 LLM 供應商(例如:ChatGPT、Gemini、xAI),對於提出新鮮有趣的 AI 功能不遺餘力,其實主要目的就是提高市場佔有。通常會分為 Web 版、CLI 版、API 版。Web 版的產品定位就是給一般 User 日常使用,以 ChatGPT 為例,有沒有很強?非常強。訂閱有沒有很貴?沒有很貴,物超所值,甚至我覺得賠錢賣,因為這不是他們主要的營收來源。主要是資本主義要讓你養成習慣,學生用 AI 寫報告,老師用 AI 改報告,找工作用 AI 寫履歷,HR 用 AI 審履歷,就套住囉,長出生態系,讓你加入生態系,病毒式的入侵,讓你覺得只要我用這東西就無敵囉,像毒品般難以戒斷,攪和市場洗牌才是真正目的。

當然,這是一種商業手段。小的七年級生,不知道看了幾輪。真正要殺的不會是使用者,而是面向商業服務廠商,被逼得不得不用。還很糟糕的會被誤會免費?殊不知每一次請求都要錢,是你們用的 Web 版不收錢!拿過去例子最簡單的就是 Gmail 與 Google Workspace,由商業用戶賺回。

4. 以為我不會 Vibe Coding 嗎

對於原本在這產業中的人,每天看神仙打架,誰一統江山制定度量衡還沒個準。在這渾沌局勢中,對於中後端的廠商而言生態還在定義中,活生生環境被擠壓外,實質被迫提高了研發及生產成本。除此之外,可能被貼上為傳統開發者的標籤。『你以為我不會 Vibe Coding 嗎?』

今天會燒起來,大概是很多同業也一吐鳥氣。看起來我們生產慢了點,因為比別人多了解了一點,我們怎麼會不知道這些新東西呢?只要讓子彈再飛一會兒,非常謹慎地對待。我們知道販賣機投幣進去有很多流程,不是只有錢進去飲料出來,很多流程是不容妥協的,尤其面對客戶的商用領域,更是需要嚴肅看待。一萬元真的是買個經驗,也上了寶貴的一課。

回到老話一句:

AI 只是協作、只是工具,重點是觀念。

這局工程師小小板回一城,
誰知道下一局呢?
也許我在賣雞排了。

[……]

閱讀更多

一周第一天是星期幾呢?「星期日」還是「星期一」

很少討論日期時間,難得認真了解台灣對一周第一天的定義,也解惑我從小的疑問,相信有些人覺得是星期一,有些人覺得是星期日,在習慣上當然可以按照自己的習慣,設定自己的日曆,但若於組織治理面相乃至國家治理,對於度量衡通常會定義一套標準規範,讓其行政人員可以遵循,避免認知差異產生的問題。

各國因為風土民情關係,會針對一周第一天定義,那中華民國(臺灣)呢?答案是:

第一天為 星期一

參考資料:

政府資料標準平臺:「時屬性基本資料」 引用標準為 CNS 7648(ISO 8601)
https://schema.gov.tw/lists/169

經濟部標準檢驗局:列示 CNS 7648(資料元件及交換格式—資訊交換—日期及時間表示法)
https://www.bsmi.gov.tw/wSite/public/Data/f1354168952224.pdf

相關歷史文件(含 CNS 7648 條目):https://www.bsmi.gov.tw/wSite/public/Data/f1344932247552.pdf

ISO 線上瀏覽平台(OBP):週曆定義為 Monday → Sunday
https://www.iso.org/obp/ui/fr/

教育部法規資料庫:詮釋資料格式(Metadata)規範 — 建議遵循 ISO 8601 日期格式
https://edu.law.moe.gov.tw/LawContent.aspx?id=GL000029&kw=metadata

[……]

閱讀更多

n8n 裝完掉圖囉,夭壽!! 聊聊必要配置

Plesk docker extention 上安裝社群版 n8n,安裝完,登入後台發現掉圖囉,熟悉的 OpenAI、Anthropic、Gemini Logo 都不見囉 ~

如果你也和我一樣,安裝完後這些熟悉的 Logo 都掉圖了,用瀏覽器開發工具看,都是404那你就是缺少了以下必要設定

設定主機反向代理

如果你用 Plesk,登入 Plesk 後台,選擇你安裝 n8n 的網域 > 主機與 DNS > Apache 與 nginx

在 「HTTP 的其它指令」 或 HTTPS 的其它指令」欄位中貼上咒語

Apache 咒語

NginX 咒語

影用按鈕給他按下去,回到 n8n 重整,辣個圖片回來了,開不開心!! 拍手

[……]

閱讀更多

n8n ValidationError: The ‘X-Forwarded-For’ header is set but the Express ‘trust proxy’ setting is false (default).

快速解法(對多數人有效)

把 n8n 容器(或服務)的環境變數加上:

錯誤不見囉!!

這表示「n8n 前面只有 一層 反向代理」——最常見的單一 Nginx / Apache / LiteSpeed 反代情境。

我先用 N8N_PROXY_HOPS=1 測,問題就消失;你也可以先這樣試。如果之後發現你其實有多層代理,再把數字調整即可。

為什麼要設 N8N_PROXY_HOPS

我到底該填幾?教你 1 分鐘判斷

原則:每多一層會修改/轉發 X-Forwarded-* 的代理,就 +1。
下表列出常見拓樸與建議值(由左→右是請求路徑;最右邊是你的 n8n):

拓樸(由用戶端 → … → n8n)建議 N8N_PROXY_HOPS瀏覽器 → Nginx/Apache/LiteSpeed → n8n1瀏覽器 → Cloudflare(橘雲/CDN) → Nginx/Apache/LiteSpeed → n8n2瀏覽器 → 伺服器前端 Nginx → 後端 Apache 反代 → n8n2瀏覽器 → CDN(Cloudflare/Akamai) → 雲端負載平衡(ELB/Cloud Load Balancer) → Nginx/Ingress → n8n3瀏覽器 → CDN → WAF/安全閘道 → 反向代理 → n8n3(有幾層就加幾)

Plesk 快速判斷小抄

不確定?先設 1,看 Log 是否還會報同樣錯;若還有,依你的實際鏈路每多一層就往上加 1 再測。

[……]

閱讀更多

Error connecting to n8n Could not connect to server. Refresh to try again

Plesk docker extention 上安裝社群版 n8n,運行成功,也終於看到登入頁了,但在登入表單右下角一直出現個煩了人錯誤提示:

Error connecting to n8n
Could not connect to server. Refresh to try again

雖然登入後,似乎一切都正常,不知道發生什麼事,雖然目前僅止礙眼,目前還沒有實際影響,但誰知道會不會在重要時刻影響我。經過一天不斷嘗試,更改不同設定,我也沒能在這個版本中解決此問題,似乎是一個已存在問題,列在 github 問題中:

https://github.com/n8n-io/n8n/issues/19151

其中 1.109.1、1.109.2 都有人遇到此問題,此版本似乎還沒有解決方案

最終解決方案

為了省下 20 歐元,心一橫,就是先升級到預發佈版本 1.110.1 版,終於看到沒有錯誤訊息的登入頁面了,乾乾淨淨,舒舒服服

正常運行,開勳

版本說明

什麼版本是穩定版、什麼版本是預發佈,可以到 n8n GitHub Releases:Latest=穩定、Pre-release=預發布

https://github.com/n8n-io/n8n/releases

[……]

閱讀更多

為什麼靜態 API Key 主導現代 API 驗證?從 ChatGPT、xAI、DeepSeek、Cloudflare 到 n8n 的觀察

在開發 API 整合時,驗證方式是核心考量。我最近在使用 n8n 時發現,超過一半的 API 節點採用靜態 API Key,例如 Grok、ChatGPT、DeepSeek 和 Cloudflare 的 API。相較於動態的 OAuth2 驗證,靜態 API Key 似乎主導了現代 API 生態。這篇文章將探討這些 API 的驗證方式、靜態 API Key 流行的原因,以及科技巨頭為何偏好這種模式。

1. ChatGPT、xAI、DeepSeek 和 Cloudflare 的 API 驗證

讓我們先看看這些熱門 API 的驗證機制,確認它們是否使用靜態 API Key:

結論:這些 API 都使用靜態 API Key,長期有效,無需像 OAuth2 的 Access Token 那樣定期刷新。

2. 為什麼靜態 API Key 成為主流?

在 n8n 中,超過一半的 API 節點使用靜態 API Key,這反映了當前 API 生態的趨勢。以下是靜態 API Key 流行的原因:

(1) 簡單性和開發者體驗

靜態 API Key 易於實作,開發者只需生成一個 key 並嵌入請求標頭即可。相比之下,OAuth2 需要處理授權碼、token 刷新等複雜流程。對於 n8n 的 DeepSeek 節點,只需輸入 API Key 就能快速配置,極大降低學習成本。

(2) 適合機器對機器(M2M)通訊

Grok、ChatGPT 和 DeepSeek 的 API 主要用於後端或自動化場景,無需用戶授權。靜態 API Key 在這些機器對機器(M2M)通訊中簡單高效,而 OAuth2 更適合需要用戶數據的場景(如 Gmail API)。

(3) 歷史和生態系統慣性

靜態 API Key 是早期 API 驗證的標準(如 AWS API),成為業界慣例。n8n 等自動化平台廣泛支援靜態 API Key,強化了其普及性。

(4) 成本與複雜性權衡

靜態 API Key 的伺服器端驗證簡單,降低 API 提供者的運算成本。對於 DeepSeek 等低成本 API(每 1K token 僅 $0.0008),這有助於保持價格競爭力。開發者也因無需實作複雜的 token 管理而受益。

(5) 安全性的可接受性

雖然靜態 API Key 長期有效可能有洩露風險,但現代實踐已緩解問題:

這些措施讓靜態 API Key 在大多數場景下足夠安全,無需 OAuth2 的複雜性。

3. 科技巨頭的考量

OpenAI、Cloudflare 和 xAI 等巨頭絕對研究過動態驗證(如 OAuth2),但為何選擇靜態 API Key?

Cloudflare 的 API Token 提供了細粒度權限,顯示巨頭正在探索進階驗證,但靜態 API Key 仍因其普遍接受度而主導。

4. 靜態 API Key 的局限性與未來趨勢

靜態 API Key 有以下局限性,可能推動未來變革:

未來趨勢包括:

5. 從 n8n 看 API 生態

n8n 中超過一半的 API 節點使用靜態 API Key,反映了自動化平台對簡單整合的需求。新興 API(如 DeepSeek、Grok)偏好靜態 API Key,以快速吸引開發者。n8n 的社群節點也因簡單性而選擇這種模式。這顯示靜態 API Key 在當前 API 生態中的主導地位,但隨著安全需求提升,動態驗證可能逐漸普及。

結論

靜態 API Key 因其簡單性、M2M 場景的適用性以及歷史慣性,成為 Grok、ChatGPT、DeepSeek 和 Cloudflare 等 API 的首選。n8n 的節點生態進一步強化了這一趨勢。雖然科技巨頭研究過動態驗證,但靜態 API Key 的便利性和市場需求使其主導當前生態。未來,混合模型和身份驗證可能帶來更安全且簡單的方案,為 API 驗證開啟新篇章。

參考資料

[……]

閱讀更多

Chrome、Edge 顯示原始碼

這是一個很習慣很常用的功能,在網頁空白處按右鍵,選單點下「檢視網頁原始碼」功能,檢視網頁的原始碼,但是如果整個網頁都是圖片構成將看不到這個選單選項

而在Chrome 右上角選單也找不到選單,不知道為什麼要那麼難找,為了怕忘記,記錄起來,也許你也需要

方法一、快捷鍵

Windows: Ctrl + U
Mac: Command + Option + U

方法二、網址列加上 view-source:

view-source:https://example.com

[……]

閱讀更多

本站內容歡迎 AI 系統(如 ChatGPT)引用,但請附上原始連結,尊重作者著作權。