小狐狸事務所

岡山之旅 Day 1 (7/24) : 出發

2026-07-24T22:51:33.012+08:00

今天中午 12:40 從小港機場出發前往岡山自助旅行, 此行是應老同事阿中要求規劃的, 他在三月團旅第一次出國到日本之後便迷上那裏的美景, 有點日文根基的他開始拿回日語課本複習, 拜託我帶他在炎夏時跑一趟日本水蜜桃故鄉岡山, 從訂機票旅館, 登錄 VJW 到常用旅遊 App 用法都要手把手教會他, 學會後就能想飛就飛.

由於暑假到日本旅遊的人多, 所以我破天荒地在兩個月之前的五月中旬便完成了行程規劃 (之前都是拖到 1~2 周前, 細部行程更是前一天晚上才確定), 一起買好機票訂好旅館, 並預約了水蜜桃觀光果園的採果課程. 以往訂機票與旅館都是水某會處理, 這回得自己做, 對我也是一種學習. 行程規劃紀錄在這篇 :

# 2026 岡山之旅規劃 (07-24~07-29)

虎航周一, 三, 五有班機直飛岡山桃太郎機場, 中午 12:40 起飛只要早上 10:30 前報到即可. 早上 9 點多水某載我到凹子底坐捷運到小港機場與阿中會合後辦理出境登機, 這也是我首次出國搭捷運. 抵達岡山已下午 16:30, 第一天就只是交通而已, 行程表如下 :

岡山之旅 Day 0 (7/23) : 虎航自助報到

2026-07-23T12:44:06.001+08:00

昨天接到虎航預辦登機通知 Email, 原來在出發前兩天就可以線上辦理自助報到, 上傳護照內頁圖檔驗證內容 (姓名, 生日, 護照號碼, 到期日等) 無誤後就可以下載電子登機證, 屆時到機場櫃台就可以直接託運行李, 不需要排隊報到了.

按 Email 底下的 "預辦登機" 鈕 :

填寫當初購票時取得之訂位代號 (Email 標題就有), 護照英文姓名 (不用輸入 -, 輸入也會被去除), 按 "開始報到" :

按去程航班右邊的 "可報到" 鈕 :

接下來是行李託運與安檢相關規定事項, 閱讀後勾選底下 "我已完整閱讀並同意以上事項" 後按 "下一步" :

接下來是要輸入護照資料, 如果可以用影印機掃描護照內頁最好, 辨識成功率較高 (但也要仔細檢查), 用手機拍照要橫拍, 光線也要注意才能順利辨識, 如果都失敗就用手動輸入 :

檢視辨識資料是否正確 (錯誤資料可能影響登機) :

資料驗證過關後顯示已加購項目, 此處還可再加購, 若不需要就按左邊 "不加購到下一步" 鈕完成自助報到, 並顯示電子登機證下載超連結 :

完成自助報到後, 虎航也會寄一封包含電子登機證 pdf 檔的 Email, 將此 pdf 存入手機, 有印表機最好也列印出來作為備份.

iPhone 手機加入 eSIM 的方法

2026-07-23T10:27:51.512+08:00

明天要跟老同事阿中前往日本岡山採水蜜桃, 主要是應其要求, 教他如何在日本自助旅行. 前天已購買中華電信行動漫遊方案 (暑假日本定量型 10 天 10GB 688 元), 今天上 KLOOK 為備用手機 iPhone SE2 買 eSIM 卡 (軟銀 6 天每日 1GB) :

付款完成後點右下角的 "帳戶" 點選 "我的訂單" 按此訂單進去就會出現 eSIM 卡的 QR 碼, 把它截圖印出來, 或傳送到同行家人手機 LINE 備用.

到達目的地機場後, 開啟 iPhone 的 WiFi 功能連到家人或機場的免費 WiFi :

進入 "行動服務", 按底下的 "加入 eSIM" :

按 "使用行動條碼" :

拿出列印的 QR 碼或家人手機中的 QR 碼, 按 "掃描行動條碼" 掃描即可 :

掃描完成後開啟行動行動數據選擇此 eSIM 即可上網.

iPhone 手機螢幕截圖方法

2026-07-23T09:42:40.384+08:00

我的備用手機 iPhone SE2 有時需要螢幕截圖 (例如紀錄如何啟用 eSIM), 因為它有 HOME 鍵, 所以傳統截圖是同時按電源 + HOME 鍵即可, 但要同時按兩個鍵不方便, 也不好控制, 我今天問 Gemini , 原來可以用輕點背面 2 或 3 下方式截圖, 設定方法如下 :

打開設定, 點選 "輔助使用" :

點選身體動作項目下的 "觸控" :

開啟 "背面輕點" :

按點兩下或點三下, 勾選 "截圖" 即可 :

設定好後, 手指在手機背板輕敲兩下就可截圖了.

Google Antigravity 學習筆記 : 重構 serverless 函式執行平台 (六)

2026-07-22T16:01:48.075+08:00

前一篇在 Mapleboard 上成功地佈署了新版 serverless 平台, 驗證 API Key 功能正常, 整個專案重構來作業已近尾聲, 本篇要將專案提交上傳更新 GitHub 上的 repo (儲存庫).

本系列全部文章索引參考 :

# Google Antigravity 學習筆記索引

8. 提交新版 serverless 與上傳 GitHub :

在提交之前, 我回顧了前面的測試過程, 發現剛開始時是從 https://github.com/tony1966/serverless.git 複製專案到 D:\antigravity_cli\projects 底下, 然後將其打上 tag 標記後建立一個新分支 api-token-auth, 再叫 agy 用 Claude 模型去重構此專案, 這就形成了 Nested Repository (巢狀儲存庫) : serverless 資料夾內自成一國 (裡面有自己的 .git), 而外層的 antigravity_cli 也有自己的 .git 現象.

站在 D:\antigravity_cli 的角度看 projects/serverless 時, Git 預設只會把 serverless 當成一個被忽略的子目錄或是一個未追蹤的 gitlink, 兩邊的 Commit 完全是分開互不干擾的. 在 serverless 下提交並 push 時會上傳到 https://github.com/tony1966/serverless 上, 而非 Antigravity CLI 的 repo 庫https://github.com/tony1966/antigravity_cli. 雖然這種國中有國的情況並不少見, 但我想讓專案資料夾與儲存庫的關係單純點, 所以將此 serverless 專案剪下來貼到 D:\ 下, 與 D:\antigravity_cli\projects 分家.

分家後的 serverless 也要有自己的 .gitignore, 所以我把 Antigravity CLI 大倉庫下的 .gitignore 複製一份來給它用 :

# ==========================================

# Python 相關快取與編譯檔案

# ==========================================

__pycache__/

*.py[cod]

*$py.class

.pytest_cache/

.poetry/

.venv/

venv/

ENV/

env/

# ==========================================

# 專案實務資料與測試產出

# ==========================================

*.json

*.db

*.log

# ==========================================

# 開發工具與編輯器暫存檔

# ==========================================

.vscode/

.idea/

*.swp

*.bak

.DS_Store

Thumbs.db

# ==========================================

# 敏感資料與環境變數 (絕對不能上傳)

# ==========================================

.env

.env.local

.env.*.local

*.env

分家後的 serverless 專案結構如下 :

PS D:\> tree serverless /f

列出磁碟區新增磁碟區的資料夾 PATH

磁碟區序號為 0000027B 1258:16B8

D:\SERVERLESS

│ .env

│ .gitignore

│ Procfile

│ requirements.txt

│ serverless.db

│ serverless.py

│ serverless_error.log

│

└─functions

│ add_function.py

│ add_table.py

│ clear_stats.py

│ delete_function.py

│ delete_record.py

│ drop_table.py

│ edit_function.py

│ execute_sql.py

│ export_table.py

│ hello.py

│ list_functions.py

│ list_tables.py

│ save_function.py

│ show_schema.py

│ show_stats.py

│ update_function.py

│ view_table.py

│ __init__.py

│

└─apps_backup

add.py

hello.py

linebot_gemini.py

linebot_gpt.py

send_books_messages.py

send_ksml_books_messages.py

update_ksml_books.py

這樣便可進行 Git 提交作業了, 首先切換到專案目錄下 :

S D:\> cd serverless

然後用 git add . 指令將所有變更加入暫存區, 把修改過的程式碼與新增的 .gitignore 檔加入追蹤 (.gitignore 內所舉的檔案除外) :

PS D:\serverless> git add .

warning: in the working copy of 'functions/save_function.py', LF will be replaced by CRLF the next time Git touches it

warning: in the working copy of 'functions/update_function.py', LF will be replaced by CRLF the next time Git touches it

PS D:\serverless>

報出的 warning 可以忽略.

然後建立 Commit 紀錄, 將變更封裝並附上明確的功能說明 :

PS D:\serverless> git commit -m "feat: implement serverless API core with API Key auth"

[feature/api-token-auth df845ce] feat: implement serverless API core with API Key auth

5 files changed, 172 insertions(+), 37 deletions(-)

create mode 100644 .gitignore

create mode 100644 functions/hello.py

接下來是推送到 GitHub 遠端倉庫的 feature/api-token-auth 分支 (-u 參數會自動建立本地與遠端分支的追蹤關係) :

PS D:\serverless> git push -u origin feature/api-token-auth

Enumerating objects: 23, done.

Counting objects: 100% (23/23), done.

Delta compression using up to 16 threads

Compressing objects: 100% (18/18), done.

Writing objects: 100% (18/18), 8.71 KiB | 1.24 MiB/s, done.

Total 18 (delta 7), reused 0 (delta 0), pack-reused 0 (from 0)

remote: Resolving deltas: 100% (7/7), completed with 4 local objects.

remote:

remote: Create a pull request for 'feature/api-token-auth' on GitHub by visiting:

remote: https://github.com/tony1966/serverless/pull/new/feature/api-token-auth

remote:

To https://github.com/tony1966/serverless.git

* [new branch] feature/api-token-auth -> feature/api-token-auth

branch 'feature/api-token-auth' set up to track 'origin/feature/api-token-auth'.

可見 18 個檔案物件已成功打包上傳 (其中包含新的 .gitignore 與 code), 且在 GitHub 成功建立獨立的 feature/api-token-auth 分支與追蹤關係. 這時到 GitHub 去察看此 repo :

可見 GitHub 遠端倉庫 tony1966/serverless 已經順利接收到了最新的變更, 而下方的是 main 分支 (正式生產環境) 的檔案列表, 顯示它依然維持 6 個月前的穩定版本, 只要此 feature/api-token-auth 分支尚未合併到 main 分支就不會影響目前依賴此 repo 的線上服務 (例如 render.com).

目前暫時先做到這裡, 後續若準備好要把 API Key 驗證功能部署到 Render.com 時, 只要按右上角的 "Compare & pull request" 鈕, 檢查變更內容沒問題後按 "Create pull request" 鈕, 再按 "Merge pull request" 與 "Confirm merge" 鈕即可合併的 main 分支, 完成升版的最後一塊拼圖.

如果要在終端機下指令合併, 順序如下 :

# 切換到 main 分支

git checkout main

# 拉取遠端最新 main（確保同步）

git pull origin main

# 將 feature 分支合併進 main

git merge feature/api-token-auth

# 推送回 GitHub main 分支（會觸發 Render 自動部署）

git push origin main

註冊第三個 render.com 帳戶

2026-07-22T11:04:25.005+08:00

上週完成 serverless 改版後本想先佈署到 Mapleboard 上, 做實際驗證後再提交上傳 GitHub, 但由於 Mapleboard 站台設定引發疑似光世代數據機的雞肋防火牆阻擋問題, 導致本地的圖書館爬蟲要更新 Mapleboard 的 serverless 資料庫時偶而被阻擋, 這讓我對自架網站可靠性動搖. 反觀我架在 render.com 上的 serverless 只要定時 trigger 卻很穩定在運行, 可見雲端還是比較可靠, 所以今天又註冊了一個 render.com 帳戶來做測試.

本系列全部測試文章索引參考 :

# render.com 學習筆記索引

首先到 render.com 官網按右上角的 Sign Up 鈕進入註冊頁面 :

# https://render.com/

這次使用 Google 帳戶註冊, 過程比用 email 簡單 :

選擇 Google 帳戶後按 "繼續" 即可 :

註冊成功直接進入 Dashboard 頁面 :

好站 : 萊斯特的岡山遊記

2026-07-20T18:07:21.077+08:00

上週水某在 YT 找到萊斯特的岡山旅遊影片, 裡面介紹許多好吃的岡山美食 :

# 【第一次去日本岡山玩透透✈️】岡山城後樂園吉備津神社｜岡山2天自由行攻略

# 【岡山倉敷二日遊怎麼安排？】不只有倉敷美觀地區！兒島牛仔褲街、鷲羽山瀨戶大橋也值得去

旅程前四天要來看一下別人的遊記, 隨時補充或修正行程規劃.

博客來買書一本 : Gemini 投資理財全攻略

2026-07-19T19:50:14.024+08:00

今天在博客來看到這本旗標的書 66 折, 這種好康當然不錯過 :

# Gemini 投資理財全攻略：小資族看過來！完全零門檻的 AI 智慧選股×財報分析×資金管理

OpenPoint 折 55 點, 實付 340 元 (約 56 折), 至興店取貨.

2026 年第 27 周記事

2026-07-19T19:39:13.156+08:00

過去一周主要在忙著把我之前寫的 serverless 專案用 agy 重構 (選用 Claude 模型), Claude 的 Coding 能力真的沒話說, 三兩下就搞定了. 周末這兩天我把新版程式佈署到 Mapleboard 時遇到站台設定衝突的干擾, 我已一年多未接觸 Mapleboard 網站設定, 印象有點模糊了, 好在透過 Gemini 協助全面修正設定後已解決, serverless 平台重構算是告一段落了. 這如果是像剛開始創建時手刻的話, 恐怕要花上個把月, 現在沒 AI 真是沒法過日子了.

週五下午請假載爸去署立醫院回診, 先去小太陽掛號拿降血壓藥, 半路上 QRV 居然熄火, 最近有兩三次怠速熄火紀錄, 只要重啟引擎即可, 但卻回卻出現引擎異常標誌, 所幸休息一下還能發動. 從署醫拿藥出來順路開到附近的 Nissan 保養廠, 初步檢修是曲軸位置與角度感知器異常造成, 因已四點多需留廠, 想說乾脆就順便做 15.5 萬公里保養, 原本也是預約周六要去大中廠保養的. 廠長先載我跟爸回家. 週六保養的技師來電, 表示檢查發現剎車分泵漏油須換, 四條輪胎胎紋已淺, 且雨刷不良建議更換, 這一次維修總共花了 22000, 真是大手筆. 廠長週六下午把車開回來, 說以後就近在他們廠保養就好, 不用去大中廠,我也覺得這樣較方便. 但若八月買 RAV4 的話, QRV 變成備用車, 保養週期會變長, 我可能會改到八百屋去做例行保養.

本周向福利會寄出諮詢單後, 國都的業務已打電話報價 124 萬, 似乎是可以接受的價格, 下周聯繫時再談. 週四去高都賞車時業務提到希望 8/15 前能決定, 因為目前有銷售競賽. 如果高都下周打電話來, 就用這價格跟她往下談, 可以的話在高都買交車較方便.

下周五要帶阿中去岡山了, 所以這幾天要複習一下行程並整理行李.

Google Antigravity 學習筆記 : 重構 serverless 函式執行平台 (五)

2026-07-19T00:40:53.031+08:00

經過前面的測試已驗證了重構後的程式碼基本上達成了讓平台具備 API Key 功能的目標, 在提交到 GitHub 之前, 想要先佈署到 Mapleboard 上更新 serverless 到具有 API Key 功能的最新版. 關於 Mapleboard 筆記參考 :

# Mapleboard MP510-50 測試筆記索引

本系列全部文章索引參考 :

# Google Antigravity 學習筆記索引

7. 在 Mapleboard 佈署新版 serverless :

先用 VNC Cloud 遠端連線到 Mapleboard 桌面, 開啟終端機, 切換到 serverless 專案目錄下, 用 zip 指令把整個專案除指定之敏感檔案外全部壓縮成 zip 檔 :

tony1966@LX2438:~/flask_apps/serverless$ zip -r serverless_v4.zip . -x "serverless.db" "serverless_error.log" "*.pyc" "__pycache__/*" ".env"

參數 -r 表示要遞迴壓縮, 即連同所有子資料夾 (如 functions/) 一起打包. serverless_backup.zip 是壓縮結果的檔檔名. 後面的 . . 代表壓縮當前目錄下的所有東西, -x 參數後面接的是排除 (不壓縮) 名單, 這裡排除了本地資料庫 (serverless.db), 日誌檔 (serverless_error.log), Python 快取檔, 以及含有敏感密碼的 .env 檔.

然後用 WinSCP 連線 Mapleboard, 注意, 之前安裝 fail2ban 時為了提升資安, 已修改 SSH 埠 (不再是預設的 22), 埠號可用下列指令查得 :

tony1966@LX2438:~/flask_apps/serverless$ sudo nano /etc/fail2ban/jail.local

設定 WinSCP 連線時除了要輸入固定 IP 外, 還要更改 SSH 埠號, 如果用 22 埠是無法連線的. 連線成功後, 先將上面備份的 zip 檔傳送至本地保存. 完成後將本地的 serverless.py 主程式與 functions 資料夾上傳到 Mapleboard 的 serverless 專案目錄下覆蓋舊版程式檔.

由於主程式 serverless.py 有更改, 所以須用下例指令重啟服務才會運行新版程式 :

tony1966@LX2438:~/flask_apps/serverless$ sudo systemctl restart serverless

用瀏覽器測試 hello.py 函式 :

在有登入情況下, 對函式的請求無需攜帶 API Key 即可順利執行; 如果沒有登入就會收到 401 錯誤, 例如 :

但修改前一篇的 deploy.py 的 URL 想要進行本地佈署 hello.py 卻出現連線異常與 404 等錯誤, 經查原來我的 Mapleboard 之前在架站時 Nginx 與站台 (主要是 hello 站台與 flask.tony1966.cc) 設定出現埠的衝突, 重啟 Nginx 出現 2~3 個 warning. 經過與 Gemini 討論後, 修改站台設定後終於解決此問題, Nginx 設定檔就徹底理順了, 摘要如下 :

reject_ip 盡職地守在大門口擋掉所有奇奇怪怪的 IP 掃描.
flask.tony1966.cc 安全地走 HTTPS 連線, 讓新版 Serverless 平台, 樹莓派爬蟲與電腦部署都能順暢通訊.
hello 站台也成功轉型, 乾乾淨淨地留在 443 埠當作你的 is_alive 測試通道 (Port 8080/8081).

站台清單檢視指令 : ls -l /etc/nginx/sites-enabled/

重啟 Nginx 伺服器指令 : sudo nginx -t

重新載入 Nginx 指令 : sudo systemctl reload nginx

佈署程式 deploy.py 的 URL 要改成 https://flask.tony1966.cc, 下面是佈署市圖爬蟲伺服端程式 update_ksml_books.py 的範例 (伺服端程式都不必為 serverless 升版做任何改變) :

SERVER_URL="https://flask.tony1966.cc"

API_TOKEN="your-api-key"

# 2. 定義要佈署的函式名稱與本地檔案路徑

TARGET_FUNCTION_NAME="update_ksml_books"

LOCAL_FILE_PATH="update_ksml_books.py"

再次執行 deploy.py 就順利將函式發佈到 serverless 平台上了 :

D:\python\test>python deploy.py

🚀 正在將 update_ksml_books.py 更新至 https://flask.tony1966.cc...

✅ 函式更新成功！

伺服器回應: {'func_name': 'update_ksml_books', 'message': '模組 update_ksml_books 已成功更新'}

deploy.py 的完整內容如下 :

# deploy.py

import os

import requests

# 1. 設定伺服器資訊與 API Token

# 地端測試可用 http://127.0.0.1:5000，上雲端後改成你的 Render 網址

SERVER_URL="https://flask.tony1966.cc"

API_TOKEN="your-api-key"

# 2. 定義要佈署的函式名稱與本地檔案路徑

TARGET_FUNCTION_NAME="update_ksml_books"

LOCAL_FILE_PATH="update_ksml_books.py"

def function_exists(func_name):

"""檢查遠端伺服器上的函式是否已存在（透過 GET 探測）"""

url=f"{SERVER_URL}/function/{func_name}"

headers={"X-API-Key": API_TOKEN}

try:

response=requests.get(url, headers=headers)

# 404 表示不存在，其他狀態（200/400/500）表示檔案存在

return response.status_code != 404

except requests.exceptions.RequestException:

return False # 連線失敗時保守假設不存在

def deploy_function():

# 檢查本地檔案是否存在

if not os.path.exists(LOCAL_FILE_PATH):

print(f"❌ 找不到本地檔案: {LOCAL_FILE_PATH}")

return

# 讀取本地最新的程式碼內容

with open(LOCAL_FILE_PATH, "r", encoding="utf-8") as f:

new_code=f.read()

headers={

"X-API-Key": API_TOKEN,

"Content-Type": "application/json"

}

payload={

"func_name": TARGET_FUNCTION_NAME,

"code": new_code

}

# 3. 自動判斷：函式已存在 → update，不存在 → save（新增）

if function_exists(TARGET_FUNCTION_NAME):

url=f"{SERVER_URL}/function/update_function"

action="更新"

else:

url=f"{SERVER_URL}/function/save_function"

action="新增"

print(f"🚀 正在將 {LOCAL_FILE_PATH} {action}至 {SERVER_URL}...")

try:

response=requests.post(url, json=payload, headers=headers)

# 新增成功是 201，更新成功是 200

if response.status_code in (200, 201):

print(f"✅ 函式{action}成功！")

print("伺服器回應:", response.json())

else:

print(f"❌ {action}失敗 (狀態碼: {response.status_code})")

try:

print("錯誤原因:", response.json())

except ValueError:

print("非 JSON 回應內容:", response.text)

except requests.exceptions.RequestException as e:

print(f"💥 連線發生異常: {e}")

if __name__ == "__main__":

deploy_function()

市圖爬蟲程式本機版則需要配合 serverless 添加 API Key 功能而升版, 否則請求都會被 401 拒絕, 這部分記在另一篇.

Google Antigravity 學習筆記 : 重構 serverless 函式執行平台 (四)

2026-07-18T18:00:14.839+08:00

前面的測試已驗證了重構後的程式碼基本上達成了讓平台具備 API Key 功能的目標, 本篇要來測試本地自動化佈署功能, 在此過程中發現了原系統的一些缺陷, 都利用 agy 請 Claude Sonnet 修正, 除了主程式 serverless.py 外, 還包括 functions 下的 update_function.py 與 save_function.py.

本系列全部文章索引參考 :

# Google Antigravity 學習筆記索引

6. 本地自動化佈署 :

第一版的 serverless 系統在新增或修改函式時都需登入平台, 透過手動操作網頁來完成, 在本次重構加上 API Key 機制後, 系統安全性增強, 可以在本地撰寫一個自動化佈署程式, 攜帶 API Key 經過驗證完成函式的佈署. 只要寫一個 Python 函式讀取要佈署的函式檔, 然後攜帶 API key 呼叫 update_function 或 save_function 即可完成函式的佈署.

(1). 與 Claude 討論 :

> 我執行下列佈署程式 :

# deploy.py

import os

import requests

# 1. 設定伺服器資訊與 API Token

# 地端測試可用 http://127.0.0.1:5000，上雲端後改成你的 Render 網址

SERVER_URL="http://127.0.0.1:5000"

API_TOKEN="new-test-token"

# 2. 定義要更新的函式名稱與本地檔案路徑

TARGET_FUNCTION_NAME="hello"

LOCAL_FILE_PATH="hello.py"

def deploy_function():

# 檢查本地檔案是否存在

if not os.path.exists(LOCAL_FILE_PATH):

print(f"❌ 找不到本地檔案: {LOCAL_FILE_PATH}")

return

# 讀取本地最新的程式碼內容

with open(LOCAL_FILE_PATH, "r", encoding="utf-8") as f:

new_code=f.read()

# 3. 準備發送給 update_function 的端點與資料

# 路由設計是動態載入的 /function/update_function

url=f"{SERVER_URL}/function/update_function"

headers={

"X-API-Key": API_TOKEN,

"Content-Type": "application/json"

}

payload={

"func_name": TARGET_FUNCTION_NAME,

"code": new_code

}

print(f"🚀 正在將 {LOCAL_FILE_PATH} 部署至 {SERVER_URL}...")

try:

# 發送 POST 請求更新遠端函式

response=requests.post(url, json=payload, headers=headers)

# 檢查伺服器回應狀態

if response.status_code == 200:

print("✅ 函式更新成功！")

print("伺服器回應:", response.json())

else:

print(f"❌ 更新失敗 (狀態碼: {response.status_code})")

try:

print("錯誤原因:", response.json())

except ValueError:

print("非 JSON 回應內容:", response.text)

except requests.exceptions.RequestException as e:

print(f"💥 連線發生異常: {e}")

deploy_function()

===

出現如下錯誤 :

D:\python\test>python deploy.py

🚀 正在將 hello.py 部署至 http://127.0.0.1:5000...

❌ 更新失敗 (狀態碼: 401)

錯誤原因: {'error': 'Authentication required', 'login_url': '/login'}

===

在提供有效 API Key 情況下應該要能通過不受 login 阻攔, 請修改

▸ Thought for 29s

The user is experiencing a 401 error with the message "Authentication required" ...

問題很清楚。看一下目前的驗證順序：

● Read(D:/antigravity_cli/projects/serverless/serverless.py) (ctrl+o to expand)

根本原因找到了：

步驟 1（L165）先攔截， update_function 在 PROTECTED_FUNCTIONS 裡，API Client 沒有 Session →

直接 401，根本輪不到步驟 2 的 Token 驗證。

解法：將兩層驗證合併，一次判斷 Session 或 Token 擇一通過，同時可以移除 TOKEN_PROTECTED_FUNCTIONS

（已不需要）：

● Read(D:/antigravity_cli/projects/serverless/serverless.py)

if __name__ == "__main__":

● Edit(D:/antigravity_cli/projects/serverless/serverless.py) (ctrl+o to expand)

完成。來驗證最終結果：

● Read(D:/antigravity_cli/projects/serverless/serverless.py) (ctrl+o to expand)

還有一個小問題：L184 的步驟編號 # 3. 與 L182 的 # 3. 重複了，順手修正：

● Edit(D:/antigravity_cli/projects/serverless/serverless.py) (ctrl+o to expand)

完成。以下是這次修改的完整說明：

──────

## 問題根源

原本流程（有 Bug）：

步驟 1：update_function 在 PROTECTED_FUNCTIONS？ → 是

check_auth() = False（API Client 無 Session）

→ 直接 401 ❌ （Token 驗證根本輪不到）

## 修正後的流程

新流程（handle_function 前三步）：

步驟 1：一次性完成雙重驗證

is_session_auth = check_auth()

if 無 Session → 嘗試讀 X-API-Key → 查資料庫 → is_token_auth

is_authorized = is_session_auth OR is_token_auth

步驟 2：管理模組 → 需要 is_authorized，否則 401

步驟 3：一般函式 → 需要 is_authorized，否則 401

## 各情境結果

呼叫者 | Session | API Key | 結果

-----------------------------|----------------------|----------------------|----------------------

瀏覽器管理者（update/save） | ✅ | ❌ | ✅ 放行

deploy.py API Client | ❌ | ✅ 有效 | ✅ 放行

未認證請求 | ❌ | ❌ | ❌ 401

無效 Token | ❌ | ❌ 無效 | ❌ 401

────────────────────────────────────────────────────────────

> 成功了, 但出現連線異常:

D:\python\test>python deploy.py

🚀 正在將 hello.py 部署至 http://127.0.0.1:5000...

✅ 函式更新成功！

💥 連線發生異常: Expecting value: line 1 column 1 (char 0)

這要修改 deploy.py 還是系統的 update_function.py 較好?

▸ Thought for 27s

The user is seeing a successful update (✅) but then a connection error. Let me...

先看清楚錯誤發生在哪一行：

deploy.py 收到 200 → 印出 ✅ → 再執行 response.json() 時爆炸，代表 update_function.py

回傳的是 HTML 而非 JSON。

讓我確認 update_function.py 的完整內容：

● Read(D:/antigravity_cli/projects/serverless/functions/update_function.py) (ctrl+o to expand)

問題找到了，而且有兩個 bug 同時存在：

# | 問題 | 說明

---|--------------|-------------------------------------------------------------------------------

1 | 欄位名稱不符 | deploy.py 送 func_name ，但 update_function.py 讀 module_name →

| | 讀到空字串

2 | 輸入格式不符 | deploy.py 送 JSON body，但 update_function.py 只讀 request.form →

| | 永遠讀不到資料

3 | 回應格式不符 | 成功時回傳 HTML， deploy.py 呼叫 response.json() 爆炸

──────

## 修哪個？

修 update_function.py ，理由：

• 這是 server 端的問題（不認識 JSON 輸入、不回傳 JSON）

• 瀏覽器用表單呼叫、API Client 用 JSON 呼叫，server 應該兩者都支援

• deploy.py 的設計是正確的，不需要改

● Edit(D:/antigravity_cli/projects/serverless/functions/update_function.py)

● Create(D:/antigravity_cli/projects/serverless/functions/update_function.py) (ctrl+o to expand)

完成。以下是修改摘要：

──────

## 修改的檔案

### update_function.py

修正了三個問題：

# | 問題 | 修正方式

---|--------------------------------------|-------------------------------------------------------

1 | 只讀 request.form ，不懂 JSON | 用 request.is_json 判斷，JSON 時改讀

| | request.get_json()

2 | 只認 module_name ，不認 func_name | JSON 輸入時同時嘗試讀取 func_name 與 module_name

3 | 成功時只回傳 HTML | JSON 請求時回傳 {"message": "...", "func_name":

| | "..."}

──────

## 預期執行結果

D:\python\test>python deploy.py

🚀 正在將 hello.py 部署至 http://127.0.0.1:5000...

✅ 函式更新成功！

伺服器回應: {'func_name': 'hello', 'message': '模組 hello 已成功更新'}

────────────────────────────────────────────────────────────

> update_function 是更新已有的函式, 如果要新增函式則是使用 add_function 與 save_function,

如果要佈署新函式, deploy.py 要怎麼改? 同時請分析 add_function.py 與 save_function.py 在執行 deploy.p

佈署方面是否有需要配合修改之處?

▸ Thought for 1s

The user wants to understand the deployment flow for new functions. Let me first...

先讀取三個相關檔案：

● Read(D:/antigravity_cli/projects/serverless/functions/add_function.py)

● Read(D:/antigravity_cli/projects/serverless/functions/save_function.py) (ctrl+o to expand)

分析完畢。以下是完整報告：

──────

## 架構釐清

add_function → 純 UI 頁面，回傳 HTML 表單，action 指向 save_function

save_function → 實際寫檔（新增），只接受 form POST

update_function → 實際寫檔（覆蓋），已修改支援 JSON

deploy.py 要新增函式，只需呼叫 save_function ，不需碰 add_function （那是給瀏覽器用的 UI）。

──────

## save_function.py 的問題（與 update_function 一樣）

# | 問題 | 影響

-----------------------------|--------------------------------------|-----------------------------

1 | 只讀 request.form ，不懂 JSON | API Client 送來的資料讀不到

2 | 只認 module_name ，不認 func_name | deploy.py 欄位名稱不符

3 | 成功/失敗都回傳 HTML | response.json() 會爆炸

──────

## 修改計劃

修改 save_function.py ：與 update_function.py 相同邏輯，支援 JSON/form 雙輸入。

修改 deploy.py ：加入「新增 or 更新」判斷邏輯，自動選擇呼叫 save_function 或 update_function

。

開始修改：

● Create(D:/antigravity_cli/projects/serverless/functions/save_function.py) (ctrl+o to expand)

現在修改 deploy.py ，加入自動判斷新增或更新：

● Create(D:/python/test/deploy.py) (ctrl+o to expand)

完成。以下是完整摘要：

──────

## 修改了哪些檔案

檔案 | 修改內容

--------------------------------|-----------------------------------------------------------------

save_function.py | 支援 JSON/form 雙輸入、相容 func_name / module_name 、回傳

| JSON（201）或 HTML

deploy.py | 新增 function_exists() 探測，自動選 save_function 或

| update_function

functions/update_function.py | 上一輪已修改，本次不動

add_function.py | 不需修改，它只是瀏覽器 UI 頁面

──────

## deploy.py 新流程

執行 deploy.py

↓

function_exists()：GET /function/{func_name}

├─ 404 → 函式不存在 → POST /function/save_function → 回 201 ✅

└─ 其他 → 函式已存在 → POST /function/update_function → 回 200 ✅

──────

## 預期執行結果

# 第一次佈署（函式不存在）

🚀 正在將 hello.py 新增至 http://127.0.0.1:5000...

✅ 函式新增成功！

伺服器回應: {'func_name': 'hello', 'message': '模組 hello 已成功建立'}

# 第二次佈署（函式已存在）

🚀 正在將 hello.py 更新至 http://127.0.0.1:5000...

✅ 函式更新成功！

伺服器回應: {'func_name': 'hello', 'message': '模組 hello 已成功更新'}

(2). 本地佈署測試 :

上面程序中 Claude 已經修改 serverless.py, update_function.py, 以及 save_function.py, 且修正了原先使用的佈署程式 deploy.py. 接下來要實測看看是否可在本機用佈署程式 deploy.py 將 hello.py 發布到後端平台上.

先複習一下 serverless 平台的函式檔基本架構 :

# func_module.py

def main(request, **kwargs):

config=kwargs.get('config', {}) # 預設為空 dict

result='do something'

return result

注意, main() 的參數一定要傳入 request 與關鍵字參數 **kwargs :

request :
用來接收 HTTP 請求的相關資訊 (例如前端傳進來的 Payload, Query Parameters, Headers等).
**kwargs 與 config :
這是一個極具擴充性的設計, 透過 kwargs.get('config', {}) 可以在伺服器端 (Flask 主程式) 執行該函式時動態注入系統級的配置或環境變數 (例如資料庫連線字串, 加密金鑰等), 而不需要把這些敏感資訊寫死在 hello.py 裡面.

為了展示此架構中 main() 的兩個參數用途, 先開啟 .env 檔, 添加一個環境變數 DB_TIMEOUT :

DB_TIMEOUT=30

然後按照上面的函式架構寫了一個新的 hello.py 函式檔 (其實只是加上讀取環境變數 DB_TIMEOUT 而已) :

# hello.py

def main(request, **kwargs):

# 讀取系統注入的設定（如果有的話）

config=kwargs.get('config', {})

# 這裡可以安全地取得環境變數

db_timeout=config.get('DB_TIMEOUT', 30)

# 先從請求字串擷取 name 參數 (?name=)

name=request.args.get('name')

if not name: # 請求字串沒有 name 參數

# 嘗試從 RESTful 子路徑 (例如 /function/hello/Tony) 中擷取 name 參數

subpath=request.view_args.get('subpath', '') # 取得 Flask 傳入的 subpath 參數

parts=subpath.strip('/').split('/') # 拆解成串列例如 ['Tony']

if parts:

name=parts[0] # 取第一段作為 name (例如 'Tony')

# 從 request 也沒有找到

if not name:

name='World'

result=f"Hello {name}! Database timeout is set to {db_timeout}s."

return result

然後用下列 Claude 修正過的 deploy.py 程式來佈署此新的 hello.py (注意 API_TOKEN 必須填入有效的 API Key) :

# deploy.py

import os

import requests

# 1. 設定伺服器資訊與 API Token

# 地端測試可用 http://127.0.0.1:5000，上雲端後改成你的 Render 網址

SERVER_URL="http://127.0.0.1:5000"

API_TOKEN="new-test-token"

# 2. 定義要佈署的函式名稱與本地檔案路徑

TARGET_FUNCTION_NAME="hello"

LOCAL_FILE_PATH="hello.py"

def function_exists(func_name):

"""檢查遠端伺服器上的函式是否已存在（透過 GET 探測）"""

url=f"{SERVER_URL}/function/{func_name}"

headers={"X-API-Key": API_TOKEN}

try:

response=requests.get(url, headers=headers)

# 404 表示不存在，其他狀態（200/400/500）表示檔案存在

return response.status_code != 404

except requests.exceptions.RequestException:

return False # 連線失敗時保守假設不存在

def deploy_function():

# 檢查本地檔案是否存在

if not os.path.exists(LOCAL_FILE_PATH):

print(f"❌ 找不到本地檔案: {LOCAL_FILE_PATH}")

return

# 讀取本地最新的程式碼內容

with open(LOCAL_FILE_PATH, "r", encoding="utf-8") as f:

new_code=f.read()

headers={

"X-API-Key": API_TOKEN,

"Content-Type": "application/json"

}

payload={

"func_name": TARGET_FUNCTION_NAME,

"code": new_code

}

# 3. 自動判斷：函式已存在 → update，不存在 → save（新增）

if function_exists(TARGET_FUNCTION_NAME):

url=f"{SERVER_URL}/function/update_function"

action="更新"

else:

url=f"{SERVER_URL}/function/save_function"

action="新增"

print(f"🚀 正在將 {LOCAL_FILE_PATH} {action}至 {SERVER_URL}...")

try:

response=requests.post(url, json=payload, headers=headers)

# 新增成功是 201，更新成功是 200

if response.status_code in (200, 201):

print(f"✅ 函式{action}成功！")

print("伺服器回應:", response.json())

else:

print(f"❌ {action}失敗 (狀態碼: {response.status_code})")

try:

print("錯誤原因:", response.json())

except ValueError:

print("非 JSON 回應內容:", response.text)

except requests.exceptions.RequestException as e:

print(f"💥 連線發生異常: {e}")

if __name__ == "__main__":

deploy_function()

可見 Claude 修改後的 deploy.py 是透過讀取 functions 資料夾下有無該函式來判斷是要新增 (無) 還是更新 (有), 目前 functions 下有 hello.py, 所以執行

執行結果 :

D:\python\test>python deploy.py

🚀 正在將 hello.py 部署至 http://127.0.0.1:5000...

✅ 函式更新成功！

伺服器回應: {'func_name': 'hello', 'message': '模組 hello 已成功更新'}

接下來驗證此新佈署的 hello.py 函式功能是否正確 :

可見不同的參數傳遞方式功能都正確, 且 .env 中的環境變數 DB_TIMEOUT 也正確讀到了. 接下來測試 save_function 是否能順利佈署新函式, 先把 functions 底下的 hello.py 刪除, 然後再執行一次 deploy.py :

D:\python\test>python deploy.py

🚀 正在將 hello.py 新增至 http://127.0.0.1:5000...

✅ 函式新增成功！

伺服器回應: {'func_name': 'hello', 'message': '模組 hello 已成功建立'}

檢視 functions 下果然 hello.py 已被建立, 再次執行網頁測試結果相同.

Google Antigravity 學習筆記 : 重構 serverless 函式執行平台 (三)

2026-07-18T07:00:14.245+08:00

在前一篇測試中利用 Antigravity CLI (agy) 完成 serverless 函式執行平台的重構, 為其加上 API Key 認證機制, 所有請求必須在標頭中攜帶有效的 X-API-Key 屬性值, 否則請求將被拒絕, 使用 curl.exe 驗證新版 serverless 功能確實符合要求, 本篇則要改用 requests 套件來測試, 這是在實際應用中最常見用法.

本系列全部文章索引參考 :

# Google Antigravity 學習筆記索引

5. 使用 requests 提出請求 :

使用 requests 套件發送請求時, 要將 API Key 放進 headers 參數中的 X-API-Key 欄位傳送給伺服器, 請求的 HTTP 方法可以使用 GET 或 POST, 分別呼叫 requests.get() 與 requests.post() 函式.

注意, 在前一篇測試中我們已將 API Key 更新如下 :

以下測試將使用 new-test-token 這個 API Key.

(1). 使用 GET 方法 :

GET 方法不帶 Body, 只需要單純將 API Key 放入 headers 中的 X-API-Key 欄位, 然後在呼叫 requests.get() 時傳入 headers 參數即可, 例如 :

# serverless_api_key_get_ok.py

import requests

url="http://localhost:5000/function/hello"

headers={"X-API-Key": "new-test-token"}

response=requests.get(url, headers=headers)

if response.status_code == 200:

print("回應:", response.text)

else:

print(f"錯誤 {response.status_code}:", response.text)

此處因為 hello.py 傳回值是純文字, 所以用 resposne.text 而非 response.json() 取得回應值, 執行結果如下, 因為傳送了有效的 API Key, 所以伺服器回應 200 OK :

>>> %Run serverless_api_key_get_ok.py

回應: Hello World!

如果沒有傳送有效的 API Key, 請求會被拒絕而得到 401 回應, 例如 :

# serverless_api_key_get_ng.py

import requests

url="http://localhost:5000/function/hello"

response=requests.get(url)

if response.status_code == 200:

print("回應:", response.text)

else:

print(f"錯誤 {response.status_code}:", response.text)

執行結果如下 :

>>> %Run serverless_api_key_get_ng.py

錯誤 401: {

"error": "Missing API token",

"hint": "Provide X-API-Key header"

}

(2). 使用 POST 方法 :

呼叫 requests.post() 時傳入有效的 API Key 就可順利取得 200 OK 回應, 例如 :

# serverless_api_key_post_ok.py

import requests

url="http://localhost:5000/function/hello"

headers={"X-API-Key": "new-test-token"}

response=requests.post(url, headers=headers)

if response.status_code == 200:

try:

# 先嘗試用 JSON 解析

print("回應 (JSON):", response.json())

except requests.exceptions.JSONDecodeError:

# 如果不是 JSON 就印出純文字

print("回應 (純文字):", response.text)

else:

print(f"錯誤 {response.status_code}:", response.text)

此例使用 try catch 來判斷回應物件型態是 JSON 格式字串還是純文字, 前者呼叫 response.json() 取得回應內容, 後者則用 response.text, 執行結果如下 :

>>> %Run serverless_api_key_post_ok.py

回應 (純文字): Hello World!

如果呼叫 requests.post() 時沒有傳入有效的 API Key 就會收到 401 錯誤, 例如 :

# serverless_api_key_post_ng.py

import requests

url="http://localhost:5000/function/hello"

response=requests.post(url)

if response.status_code == 200:

try:

# 先嘗試用 JSON 解析

print("回應 (JSON):", response.json())

except requests.exceptions.JSONDecodeError:

# 如果不是 JSON 就印出純文字

print("回應 (純文字):", response.text)

else:

print(f"錯誤 {response.status_code}:", response.text)

執行結果如下 :

>> %Run serverless_api_key_post_ng.py

錯誤 401: {

"error": "Missing API token",

"hint": "Provide X-API-Key header"

}

以上測試說明重構後的 serverless 平台確實已改為 API Key 版本, 任何請求必須攜帶 API Key 才可能取得 200 OK 回應, 否則請求都會被拒絕, 收到 401 錯誤.

6. 主程式原始碼異動摘要 :

經過上面測試, 我們確認了此重購專案已達成了預期目標, 以下做個 Code Review, 將主程式 serverless.py 的異動摘要如下 :

首先是在 init_db() 函式中添加了一個儲存 API Key 的認證資料表 api_tokens :

# API Token 認證表

cursor.execute("""

CREATE TABLE IF NOT EXISTS api_tokens (

id INTEGER PRIMARY KEY AUTOINCREMENT,

token TEXT NOT NULL UNIQUE,

owner TEXT NOT NULL,

is_active INTEGER NOT NULL DEFAULT 1,

created_at TEXT NOT NULL DEFAULT (datetime('now'))

)

""")

其次是添加了一個 TOKEN_PROTECTED_FUNCTIONS 清單 :

# 需要 API Token 驗證的函式列表（儲存/更新 function 及所有一般函式執行）

TOKEN_PROTECTED_FUNCTIONS=['save_function', 'update_function']

這兩個系統函式 save_function 與 update_function 用來將函式內容寫進檔案中, 屬於最高權限的敏感操作, 必須通過 API Key 驗證.

其三是新增了一個 require_api_token() 函式來檢查請求標頭中是否有攜帶有效之 API Key, 有就傳回所呼叫的函式, 否則傳回 401 錯誤 :

def require_api_token(f): # 裝飾器：驗證請求 Header 中的 X-API-Key

@wraps(f)

def decorated(*args, **kwargs):

token=request.headers.get('X-API-Key')

if not token: # Header 遺失

return jsonify({'error': 'Missing API token', 'hint': 'Provide X-API-Key header'}), 401

conn=sqlite3.connect(DB_PATH)

cursor=conn.cursor()

cursor.execute(

'SELECT id FROM api_tokens WHERE token=? AND is_active=1',

(token,)

)

row=cursor.fetchone()

conn.close()

if not row: # Token 不存在或已停用

return jsonify({'error': 'Invalid or inactive API token'}), 401

return f(*args, **kwargs)

return decorated

最後是在 handle_function() 函式中添加雙軌互補驗證 (Session 或 Token 擇一通過) 機制 :

# 2. API Token 驗證：已登入管理者直接放行；否則需提供有效 Token

# 觸發範圍：TOKEN_PROTECTED_FUNCTIONS（save/update）及所有一般函式

if func_name in TOKEN_PROTECTED_FUNCTIONS or func_name not in PROTECTED_FUNCTIONS:

if not check_auth(): # 管理者已登入 → 信任，跳過 Token 驗證

token=request.headers.get('X-API-Key')

if not token:

return jsonify({'error': 'Missing API token', 'hint': 'Provide X-API-Key header'}), 401

conn=sqlite3.connect(DB_PATH)

cursor=conn.cursor()

cursor.execute(

'SELECT id FROM api_tokens WHERE token=? AND is_active=1',

(token,)

)

row=cursor.fetchone()

conn.close()

if not row:

return jsonify({'error': 'Invalid or inactive API token'}), 401

這段程式碼採用了巢狀條件設計, 提供了兩道過濾網 :

第一層 (判定範圍) :只要呼叫的函式是敏感的系統功能 (save/update_function) 或任何使用者自訂函式 (不在白名單內) 就會觸發此區塊.
第二層 (身份切換) :

情境 A (管理員) :
瀏覽器帶著 Cookie 請求, check_auth() 回傳 True. 此時 if not check_auth() 判定不成立, 直接跳過整個 Token 檢查與資料庫查詢, 此安排讓管理員登入後線上操作函式更新與存檔不因為沒帶 API Key 而被 401 擋掉.
情境 B (外部 API 呼叫/排程腳本) :
本機 Python 腳本或 curl 請求沒有瀏覽器 Session, 呼叫 check_auth() 會回傳 False, 程式進入 if 內部強制執行後續的 X-API-Key 擷取與 SQLite 比對.

if not check_auth() 是檢查使用者是否有登入, 沒有登入就要接受 API Key 查驗, 檢查 HTTP 請求的 Header 有沒有帶 X-API-Key 欄位, 沒有帶就直接拒絕請求, 回傳 401 Unauthorized 狀態碼. 如果已登入, 則程式會直接跳過整個 if not check_auth(): 內部的所有程式碼, 直接放行去執行該函式.

注意此處使用了 SQLite 的參數化查詢 token=? 並把變數包在元組 (token,) 裡傳進去, 這樣可以徹底杜絕駭客在 Header 亂寫 SQL 語法, 利用 SQL Injection 來破解驗證. 如果資料庫回傳 None, 表示 API Key 不存在, 或存在但被停用 (is_active 不是 1), 那就回傳 401 錯誤拒絕請求; 反之就是通過了驗證, 准許呼叫此函式, 放行讓後續的業務邏輯繼續執行.

Google Antigravity 學習筆記 : 重構 serverless 函式執行平台 (二)

2026-07-18T00:00:35.791+08:00

在前一篇測試中, 我已將 serverless 第一版原始碼從 GitHub 上複製到本機 Antigravity CLI 的專案目錄下, 並做好前置處理, 包含將原專案打上標籤, 建立新分支, 建立隔離資料夾並移動應用 App, 最後提交 Git 紀錄. 本篇要用 agy 來進行重構, 為 serverless 平台加上 API Token 認證機制.

本系列全部文章索引參考 :

# Google Antigravity 學習筆記索引

2. 用 agy 重構專案 :

切換到專案目錄下後輸入 agy 啟動 Antigravity CLI 介面, 這次仍然使用 Claude Sonnet 模型來完成此重構計劃. 輸入下列提示詞 :

我們正在 feature/api-token-auth 分支上，要為這個 serverless 專案加上 API Token 認證機制。請協助修改 serverless.py，完成以下任務：

1. 初始化資料庫：

在系統啟動時（或初始化 DB 的地方），自動建立 `api_tokens` 資料表（欄位包含：id, token, owner, is_active, created_at）。

2. 實作驗證裝飾器（Decorator）：

撰寫一個 `@require_api_token` 裝飾器，從請求的 Header 中讀取 `X-API-Key`。

- 若 Header 遺失或 Token 不存在於資料庫中（且 is_active 必須為 1），回傳 401 Unauthorized。

3. 保護 API 路由：

將這個裝飾器套用到「儲存/更新 function」以及「執行 function」的 Flask Route 上。

請先分析原始專案的架構, 提出你的重構計劃, 讓我看過後再修改程式碼。

Claude 閱讀原專案後規劃結果如下 :

> 我們正在 feature/api-token-auth 分支上，要為這個 serverless 專案加上 API Token 認證機制。

請協助修改 serverless.py，完成以下任務：

1. 初始化資料庫：

在系統啟動時（或初始化 DB 的地方），自動建立 `api_tokens` 資料表（欄位包含：id, token, owner,

is_active, created_at）。

2. 實作驗證裝飾器（Decorator）：

撰寫一個 `@require_api_token` 裝飾器，從請求的 Header 中讀取 `X-API-Key`。

- 若 Header 遺失或 Token 不存在於資料庫中（且 is_active 必須為 1），回傳 401 Unauthorized。

3. 保護 API 路由：

將這個裝飾器套用到「儲存/更新 function」以及「執行 function」的 Flask Route 上。

請先分析原始專案的架構, 提出你的重構計劃, 讓我看過後再修改程式碼。

▸ Thought for 2s

Let me first explore the project structure to understand the codebase before mak...

● ListDir(D:/antigravity_cli/projects/serverless)

● Read(D:/antigravity_cli/projects/serverless/serverless.py)

● ListDir(D:/antigravity_cli/projects/serverless/functions)

● Read(D:/antigravity_cli/projects/serverless/requirements.txt)

● Read(D:/antigravity_cli/projects/serverless/functions/save_function.py)

● Read(D:/antigravity_cli/projects/serverless/functions/update_function.py) (ctrl+o to expand)

已完整閱讀專案架構，以下是我的分析與重構計劃。

──────

● Create(C:/Users/tony1/.gemini/antigravity-...-a43e-cfa6fbc204e5/refactor_plan.md) (ctrl+o to expand)

以下是重構計劃的摘要：

## 架構分析結論

現有系統有兩層認證：

1. Session Cookie — 管理者透過 /login 密碼登入，保護 PROTECTED_FUNCTIONS 清單

2. 一般函式執行 — 完全沒有保護，任何人只要知道 URL 就能呼叫

──────

## 三個關鍵設計決策

### 1. init_db() 修正

移除 if not os.path.exists(DB_PATH) 判斷，改用 CREATE TABLE IF NOT EXISTS

，確保每次啟動都檢查表是否存在，不會因 DB 已建立但缺表而漏掉建立 api_tokens 。

### 2. @require_api_token 裝飾器

讀取 X-API-Key Header → 查詢 api_tokens 表（ is_active=1 ）→ 不符合一律回 401 JSON。

### 3. 保護路由的方案

因為 save_function 、 update_function 與一般函式執行共用同一個 handle_function()

路由，無法直接套裝飾器。

採用方案 A：在路由內部邏輯中呼叫驗證輔助函式，改動最小且與現有 Session 機制並存。

──────

計劃文件已整理完畢，請確認後按「Proceed」或告訴我需要調整的地方，即可開始撰寫程式碼。

此計劃看來很周到, 輸入 Proceed 按 Enter 看它表演即可 :

> Proceed

▸ Thought for 1s

The user wants to proceed with the refactoring plan. Let me implement the change...

好的，開始實作！

● Read(D:/antigravity_cli/projects/serverless/serverless.py)

● Edit(D:/antigravity_cli/projects/serverless/serverless.py) (ctrl+o to expand)

修改成功，來驗證最終結果：

● Read(D:/antigravity_cli/projects/serverless/serverless.py) (ctrl+o to expand)

內容正確。最後修正一個步驟編號的小問題（step 2 重複出現）：

● Edit(D:/antigravity_cli/projects/serverless/serverless.py) (ctrl+o to expand)

所有修改完成，以下是完整摘要：

──────

## ✅ 修改完成摘要

檔案：serverless.py

### 變更一覽

# | 位置 | 修改內容

---------------|---------------|------------------------------------------------------------------

1 | L6 | 新增 from functools import wraps

2 | L16–37 | init_db() 改為冪等執行，新增 api_tokens 資料表

3 | L56–73 | 新增 require_api_token(f) 裝飾器（備用，可掛在未來獨立路由上）

4 | L105–106 | 新增 TOKEN_PROTECTED_FUNCTIONS 常數

5 | L167–181 | handle_function() 步驟 2 加入 API Token 驗證邏輯

6 | L207–208 | 移除 __main__ 區塊重複的 init_db() 呼叫

### 認證邏輯流程（修改後）

/function/<func_name>

│

├─ func_name 在 PROTECTED_FUNCTIONS？

│ └─ 未登入 Session → 401 (Authentication required)

│

├─ func_name 在 TOKEN_PROTECTED_FUNCTIONS（save/update）

│ OR func_name 不在 PROTECTED_FUNCTIONS（一般函式）？

│ ├─ 無 X-API-Key Header → 401 (Missing API token)

│ └─ Token 無效或 is_active=0 → 401 (Invalid or inactive API token)

│

└─ 驗證通過 → 動態載入並執行函式

### 快速測試方式

# 插入測試 Token

sqlite3 serverless.db "INSERT INTO api_tokens (token, owner) VALUES ('test-token-123',

'developer');"

# ✅ 正確呼叫

curl http://localhost:5000/function/hello -H "X-API-Key: test-token-123"

# ❌ 無 Token → 401

curl http://localhost:5000/function/hello

不到三分鐘就完成重構了, 這若是照以前人工來改程式碼, 恐怕得花上一周或更久. 我叫 Claude 說明它改了哪些地方 :

> 解釋你修改了哪些檔案? 哪個部分(函式)?

▸ Thought Process

The user wants a clear explanation of which files and which functions were modif...

這次只修改了 1 個檔案，共改動 4 個區塊：

──────

## 修改的檔案

### serverless.py

──────

### 1. Import 區塊（L1–8）

+ from functools import wraps

新增 wraps ，讓裝飾器能保留被包裝函式的原始名稱與文件字串。

──────

### 2. init_db() 函式（L16–37）

改動前：用 if not os.path.exists(DB_PATH) 判斷，只有 DB 不存在時才建表，且只建 call_stats

一張表。

改動後：

• 移除 os.path.exists 條件判斷，改為每次啟動都執行（ CREATE TABLE IF NOT EXISTS

本身就是冪等的，不會重複建表）

• 新增 api_tokens 資料表，欄位為 id, token, owner, is_active, created_at

──────

### 3. 新增 require_api_token() 裝飾器（L56–73）

全新函式，位於 record_call() 之後、 app = Flask(...) 之前。

功能：從 Request Header 讀取 X-API-Key ，查詢資料庫確認 Token 存在且 is_active=1 ，否則回傳 401

。

│ 此裝飾器目前定義為備用，供未來掛在獨立路由上使用。

──────

### 4. handle_function() 路由函式（L163–181）

在原有的 Session 驗證之後，插入第二層 API Token 驗證邏輯（步驟 2）：

觸發條件（滿足其一即驗證）：

A. func_name 在 TOKEN_PROTECTED_FUNCTIONS → save_function、update_function

B. func_name 不在 PROTECTED_FUNCTIONS → 所有一般使用者自訂函式

兩種情況都會檢查 X-API-Key Header，並查詢 api_tokens 表，不符合就回傳 401 。

──────

### 未修改的部分

未動到的檔案/函式 | 原因

-------------------------------------------------|------------------------------------------------

functions/ 目錄下所有模組 | 驗證邏輯集中在 serverless.py ，子模組不需變動

check_auth() | Session 登入機制保持原樣

record_call() | 呼叫統計邏輯不變

/login 、 /logout 路由 | 管理者登入流程不變

這個說明後續可以開啟主程式 serverless.py 來檢視.

3. 功能測試 :

上面 agy 已完成重構, 接下來實地測試 Claud 實作的 API Token 是否能正常運作. 在進行測試之前, 須在專案目錄下建立一個純文字檔 .env, 紀錄管理者的 token 與 key, 前者是自己容易記的密碼, 後者是用工具函式產生的一長串金鑰, 可以用 Python 內建的 secrets 模組來產生, 參考 :

# Mapleboard MP510-50 測試 (三十七) : HTTP API 函式執行平台 (3)

在專案目錄下用記事本編輯一個 .env 檔, 輸入如下內容 (範例) :

SECRET_TOKEN=admin123

SECRET_KEY=fKFQPound41lv8FrWzU-lmFywxAT47uMwfvmBbiuLTE

其中的 SECRET_KEY 可在 Thonny 的 Python 互動環境匯入 secrets 模組後呼叫 secrets.token_urlsafe(32) 函式產生, 例如 :

>>> import secrets

>>> secrets.token_urlsafe(32)

'fKFQPound41lv8FrWzU-lmFywxAT47uMwfvmBbiuLTE'

由於我主要的測試環境主要是使用 Thonny 自帶的 Python, 所有 requirements.txt 中的套件在此開發環境都有安裝 (此專案主要是用到 Flask), 所以按 Thonny 的 "工具/開啟系統終端機" 開啟命令提示字元視窗, 切換到專案目錄下, 用下列指令啟動 Flask 開發伺服器 :

D:\antigravity_cli\projects\serverless>python serverless.py

* Serving Flask app 'serverless'

* Debug mode: on

伺服器運行起來後, serverless.py 就會建立一個 SQlite 資料庫 serverless.db, 執行下列指令在此系統資料庫裡的 api_tokens 資料表填入測試用的權杖 test-token-123 :

PS D:\antigravity_cli\projects\serverless> python -c "import sqlite3; conn = sqlite3.connect('serverless.db'); conn.execute('INSERT INTO api_tokens (token, owner, is_active) VALUES (?, ?, ?)', ('test-token-123', 'developer', 1)); conn.commit(); conn.close(); print('🎉 測試 Token 寫入成功！')"

🎉 測試 Token 寫入成功！

然後在瀏覽器網址列輸入 Flask 開發伺服器預設網址 http://localhost:5000/ 會看到 serverless 平台網站已順利運行, 按 "登入系統" :

輸入 .env 檔案中設定的 SECRET_TOKEN 密碼, 按 "登入" 鈕 :

登入成功後按 "函式列表" 進入管理頁面首頁 :

按 "資料表" :

可見多了一個 api_tokens 的資料表, 這就是 Claude 重構此平台時所添加, 用來儲存 API Key (token) 的資料表, 按 "檢視" :

顯示前面用 Python 指令寫入 api_tokens 資料表的測試用權杖 :

接下來用 curl.exe 測試沒帶 token 的情況, 這樣的請求會被拒絕 :

PS D:\antigravity_cli\projects\serverless> curl.exe -i http://localhost:5000/function/hello

HTTP/1.1 401 UNAUTHORIZED

Server: Werkzeug/2.3.7 Python/3.10.11

Date: Fri, 17 Jul 2026 11:36:12 GMT

Content-Type: application/json

Content-Length: 73

Connection: close

{

"error": "Missing API token",

"hint": "Provide X-API-Key header"

}

可見未攜帶 token 的請求會回應 "401 UNAUTHORIZED". 主體 (body) 內容為 JSON 訊息, error 鍵之值表示沒有收到 API token; 而 hit 鍵之值則表示必須在標頭攜帶 X-API-Key, 可在 curl.exe 指令中用 -H 參數指定此 token, 例如 :

PS D:\antigravity_cli\projects\serverless> curl.exe -i http://localhost:5000/function/hello -H "X-API-Key: test-token-123"

HTTP/1.1 200 OK

Server: Werkzeug/2.3.7 Python/3.10.11

Date: Fri, 17 Jul 2026 15:41:03 GMT

Content-Type: text/html; charset=utf-8

Content-Length: 12

Connection: close

Hello World!

可見若有攜帶正確的 X-API-Key 就會執行該函式, 回應 200 OK.

4. 線上管理 API Key :

在第一版的 serverless 函式執行平台就已實作了線上管理 serverless.db 的功能, 除了提供超連結可刪除資料表與紀錄外, 還可以執行 SQL 指令以新增, 更新, 或刪除紀錄.

按資料表列表頁面下方的 "執行 SQL" :

輸入 SQL 指令後按 "執行" 即可, 例如要修改 owner=developer 使用中的 token 的 SQL 指令 :

UPDATE api_tokens

SET token = 'new-test-token' WHERE owner='developer' AND is_active=1;

執行結果為成功 :

返回資料表內容檢視頁面可知 API Key (token 欄位) 已經更新了 :

新增 API key 的 SQL 例如 :

INSERT INTO api_tokens (token, owner, is_active)

VALUES ('fKFQPound41lv8FrWzU-lmFywxAT47uMwfvmBbiuLTE', 'proj-a', 1);

只要以管理員身分登入, 就可以線上管理 API Key 了.

以上測試顯示 agy 的重構確實達成了預期的目標, 讓 serverless 平台升級為需要 API Key 才能使用的網路服務, 避免伺服器被濫用或遭到攻擊.

購買 Hahow 課程 : AI Coding 無痛上手

2026-07-17T23:59:36.341+08:00

昨天在 Hahow 購買了 Kai 老師的 "AI Coding 無痛上手" 課程募資 :

雖然我平常就在用 Vibe coding, 但看到課程介紹就很想去了解人家的作法, 不同的老師有不同的方法論, 值得花點學費去了解別人的 AI 工作術. 但我最近似乎買太多課程了, 月底從岡山回來後, 八月份起要來好好上課了.

購買 MasterTalk 課程 (補記)

2026-07-17T23:47:30.698+08:00

今天查看 LINE 紀錄才想起上周三 (7/8) 請假陪水某與菁菁去大甲鎮瀾宮拜拜, 在自強號上滑手機時看到 MasterTalk 平台的新課程通知 :

# 不會寫程式，也能用 AI 打造你的台股看盤＋盯盤系統

有點數折換打 9 折, 實付 3492 元.

蝦皮購買 iPhone SE2 磁吸式手機殼

2026-07-15T12:35:17.017+08:00

今天上蝦皮幫我的備用手機 iPhone SE 買磁吸殼, 方便出國時直接將行動電源吸附充電免拉線 :

# 高級透明蘋果1716/15/14/13/12/11/xs/xr手機殻磁吸充電iPhone7P防摔8代全包SE2軟邊SE3 $119

明華智取店取付 238 元.

參加嘖嘖 ORIVA 隨行烘乾機募資預購

2026-07-14T23:08:02.937+08:00

最近在 FB 看到嘖嘖的 ORIVA 隨行烘乾機募資廣告, 覺得對出國旅行衣物烘乾很方便, 就參加預購了, 但要八月才開始出貨, 趕不上月底跟阿中的岡山之旅 :

# https://www.zeczec.com/projects/oriva-tw

市圖還書 1 本 : 超有料!職場第一實用的AI工作術

2026-07-14T08:13:12.002+08:00

此書被預約須還 :

超有料!職場第一實用的AI工作術

旗標出版的書內容質感都不錯 (個人評價 No.1), 此書亦然. 此書對於剛要步入職場的社會新鮮人實用度非常高, 從 AI 製做簡報, 影片修圖, 處理郵件+合約, 到廣宣文案生成等等, 涵蓋面足敷剛踏入職場的新手應付工作所需.

申請中國信託和泰聯名卡

2026-07-13T23:47:22.800+08:00

由於最近打算買新車 (豐田 RAV4 旗艦版), 我詢問 Gemini 付款方式, 它說可以辦車貸, 若資金充足建議全款付清, 不用給銀行賺利息. 我算是個小田僑, 當然是全款付清啦! 他說那這樣可以先辦一張中國信託和泰聯名卡, 這樣尾款可以刷這張卡 (綁定和泰 Pay), 全額刷卡可以現賺 0.6% 的和泰 Points 點數 (無上限, 刷 120 萬可拿到 7200 點, 1 點等於 1 元), 可以直接拿來折抵 RAV4 年底前的原廠定期保養費用 (目前點數計算方式 1 點等於 1 元在 2026-12-31 前有效).

刷卡購車點數回饋辦法 :

# Lexus、TOYOTA購車全額享0.6%和泰Points回饋無上限

線上申辦網址 :

# 中國信託和泰聯名卡

填寫姓名與生日, 勾選卡片類型 (可綁悠遊卡), 馬上就辦好了, 實體卡約需五天寄達, 但現在就可以下載和泰 Pay app 綁定此張信用卡消費了 :

現在刷聯名卡有洗車優惠 :

如果前段的訂金與後段的規費+保險也可刷這張卡, 回饋是 1%; 中段的高額尾款 (約 120 萬) 回饋比率是 0.6%, 以 5 萬元訂金計算可得 500 點, 合計 7700 點. 在刷卡付尾款前一天先打電話給中國信託客服, 表示明天買新車要刷和泰 Pay 尾款 120 萬, 現在直接轉帳 120 萬進中信指定帳戶, 要求客服幫我溢繳調高臨額 (人話 : 預存現金然後叫銀行暫時放寬刷卡上限) 即可.

2026-07-14 補充 :

已下載 My Toyota app, 等收到信用卡再綁定. 很巧昨日剛好收到公司福利會寄來的 Toyota 購車優惠 DM, RAV4 Adventure 價格寫 12? 萬 (我猜是 127~129), 雖沒寫旗艦版價格, 估計可能 123~125, 已填寫諮詢單回傳, 等業務員電話來時再詳細詢問.

2026-07-22 補充 :

7/20 收到卡了, 已綁定和泰 Pay :

古風的辭九門回憶

2026-07-13T15:19:26.450+08:00

今天偶然在 fb 聽到這首歌, 搜尋發現是中國歌手鄧寓君唱的 "辭九門回憶" :

# https://www.youtube.com/watch?v=3TjRpJmbsgc

也有動感的 DJ 版 :

# https://www.youtube.com/watch?v=O5nZZLkfOcM

除了優美的古風旋律外, 它的詞也填得很美 :

作詞：蟲二顛作曲：妖狐公子編曲：唯子

一曲定重樓

一眼半生籌

看的全都是那詭譎雲湧

入得此門不回首

無需宣之於口

我對案再拜那風雨瓢潑的殘陋

再聚首

戲子多秋

可憐一處情深舊

滿座衣冠皆老朽

黃泉故事無止休

戲無骨難左右

換過一折又重頭

只道最是人間不能留

誤闖天家

勸餘放下手中砂

張口欲唱聲卻啞

粉面披衣叫個假

憐余來安座下

不敢沾染佛前茶

只作凡人赴雪月風花

繞過胭脂樓

打散結髮扣

唱的全都是那情深不壽

入得此門不回首

無需宣之於口

我對鏡遮掩那風雨瓢潑的殘陋

碑已舊

戲子多秋

可憐一處情深舊

滿座衣冠皆老朽

黃泉故事無止休

戲無骨難左右

換過一折又重頭

只道最是人間不能留

誤闖天家

勸餘放下手中砂

送那人御街打馬

才子佳人斷佳話

憐餘來苦咽下

求不得佛前茶

只留三寸土種二月花

------------------------------

歌詞大概是描寫戲子愛上了身份高貴的人, 但門戶的不匹配, 注定了這是一場悲劇. 情郎似乎科舉及第, 還能在宮門前騎馬, 從此飛黃騰達, 而身份低微的戲子只能對名份與愛情痛苦地絕望, 只希望死後墳上的三寸荒土能在二月開春時節開出美麗的花, 真是淒美啊. 這首歌讓我想起梅艷芳與張國榮主演的香港電影 "胭脂扣".

2026 年第 27 周記事

2026-07-12T21:04:00.627+08:00

週三請了一天假陪水某與菁菁去大甲鎮瀾宮參拜, 這是我第一次造訪大甲, 其實台中對我來說通常只是路過而已, 我家在台中只有姑姑一房親戚, 小時候祖母常帶我們兄弟去清泉崗眷村的姑姑家, 當兵休假與在台北工作時, 偶而也會去住一兩天, 直到表哥他們搬離那裏. 這次去大甲給我印象非常好, 鎮瀾宮外都是美食, 有火車經過交通很便利.

中颱巴威周六襲台, 周五台北放颱風假, 在台北開便當店的小阿姨打電話說沒甚麼風雨, 她還跑去泡溫泉哩. 新聞說股市休市一天市值蒸發 100 多億, 可能是被上回內湖淹水嚇到了, 畢竟年底選舉的腳步近了. 我覺得其實沒甚麼好擔心的, 恕我直言, 就算不放颱風假, 萬安還是會連任的啦.

經過一周努力, 周六終於把舊筆電 INHON Carbonbook 救活, 順利重灌 Win11 與開發環境後做了還原點與映像備份, 據 CrystalDiskInfo 分析資訊, SSD 使用度算是年輕級的, 應該還可以再用好幾年, 將做為備用筆電用. 兩個月來的舊筆電拯救活動終於在本周告一段落了, 下周要全力投入 agy 專案開發.

Nissan e-Power vs Toyota RAV4

2026-07-12T08:05:30.334+08:00

前陣子周遭朋友與同學陸續換車, 我的 QRV Serenna 也開了 20 年了, 雖然車況還不錯, 但老車總有一些小毛病, 有時感到很困擾 (目前是偶而怠速熄火, 後車箱門有時要按兩次才會解鎖等等). 峰大師去年換 Nissan X-Trail e-Power (二代五人座), 曾開來鄉下家讓我試乘, 我那時非常喜歡這台車, 覺得它的設計理念很獨特, 但 QRV 又開得好好的, 還不需要換車, 等退休前 2~3 年再說, QRV 至少還可以再開五年以上. 但最近想到, 退休前的這 5 年可能會較頻繁往返城市與鄉下, QRV 油耗太高了, 應該換一台較省油的車來開. 以下是我這兩天與 Gemini 討論後整理的心得.

X-Trail e-Power 是 100% 馬達驅動的油電車, 它給我的第一感覺是車內靜音做得非常好 (前擋與雙前座雙層隔音玻璃, 全車使用大量吸音棉), 有電車的平穩舒適 (e-4ORCE 馬達精準控制帶來的穩定性), 但沒有一般電車的里程焦慮. 它並不是一般需要外接充電的純電動車, 而是配備一具 1.5 公升 VC-Turbo 引擎作為發電機, 只負責為鋰電池充電. 目前台灣上市的是 2026 小改款的二代, 建議售價 151 萬, 平均油耗是 17.5km/L (同學說它開了一年實際約 14km/L). 聽說明年將推出第三代 e-power, 油耗提升至 21.0 km/L, 且提供第三排座椅選配成為 5+2 空間配置, 蠻符合我家偶而全家 6 人出遊的需求 (但 5+2 的第三排空間較窄, 通常較適合小孩或短途應急, 大人坐久會像坐板凳, 舒適度不足, 不適合長途旅行), 參考 :

# Nissan 新一代 X-Trail 換上全新造型明年問世！尺碼增大空間更寬敞

豐田 RAV4 則是油電混合車 (Hybrid), 搭載最新世代的 THS 油電科技, 引擎與馬達共同負責驅動車輪, 在低速時主要由馬達驅動, 高速巡航時引擎所占比例提高, 馬達仍會依需求輔助驅動或回收能量, 這是目前全世界最成熟, 市佔率最高的油電架構. 今年初大改款後價格非常誘人, 最受歡迎的旗艦版建議售價 130萬, 平均油耗高達每公升 24.0 km, 是我的 QRV 的 2~3 倍! 此款油電混合車配備 2.5L 排氣量與兩顆馬達 (發電馬達 MG1 與驅動馬達 MG2), 它沒有使用傳統變速箱來換檔, 而是透過一個叫 "行星齒輪" 的結構 (E-CVT, 電子控制無段變速器) 將引擎和馬達結合在一起互相截長補短, 創造出舒適與省油兼具的駕車體驗.

一般情況下, RAV4 在起步與市區低速行駛時, 若高壓電池電量足夠, 引擎通常會熄火, 由 MG2 驅動車輛, 高壓鋰電池 (以下簡稱大電池) 放電驅動馬達 (MG2) 推動前輪, 這時它的行駛感受非常接近純電動車, 安靜且平順; 當踩油門超車或爬坡時, 引擎和馬達同時使勁推動前輪, 提供最高約 229 匹的系統綜效動力; 在高速公路行駛時, 引擎在最省油的轉速下巡航, 它輸出的動力會分兩路, 一路直接推動輪子前進, 另一路拿去帶動發電機 (MG1) 發電, 把電充回大電池備用; 當鬆開油門滑行或煞車減速時引擎會熄火, 車子的前進慣性會反向帶動驅動馬達 (MG2) 旋轉, 馬達此時變身為發電機, 把減速的動能換成電能灌回大電池充電. 參考 :

# 台灣最熱賣進口休旅再進化 Toyota RAV4旗艦車型試駕

# 【RAV4 怎麼選才不後悔？】全車型配備差異一次看懂！

# 想買RAV4必看！Toyota RAV4旗艦版徹底剖析

# RAV4竟然從無聊的交通工具變成有趣的車？

# Toyota 第六代Rav4 分享影片，好壞都會講，你們會喜歡

RAV4 旗艦版主要配備 :

影音 : 搭載 12.9 吋日本原裝 Arene 軟體平台車機, 支援智能語音與 OTA.
主動安全 : 標配 TSS 4.0 (全速域 ACC 與車道維持 LTA), 旗艦版含電子後視鏡.
舒適性 : 雙前座通風/加熱椅, 足踢尾門

雖然 e-Power 在隔音方面極致安靜, 但著眼於省油考量 (還有雙前座通風椅在炎夏帶來的涼爽), 我應該會選 RAV4 旗艦版. RAV4 最大的優勢其實不是省油, 而是全球累積超過數千萬套的實際道路驗證. 豐田車安全, 省油, 好養業界知名, 其 Hybrid 系統耐用度與二手殘值傲視市場其他廠牌, 例行保養是全台公認最強的國產價, 零件 (如機油芯, 冷氣濾網) 由於與多款車型共用, 外頭民間廠也都會修, 原廠常規小保養通常在 2,500~3,500 元之間, 每 4 萬或 6 萬公里的大保養費用也能控制在 5,000~6,500 元左右, 保養成本較低. 大條維修方面, RAV4 的 2.5L 自然進氣引擎構造相對傳統簡單, 構造相對成熟, 長期維修風險相對較低; 豐田成熟的油電大電池, 原廠提供 8 年或 16 萬公里保固, 過保後如果需要自費更換, 目前行情大約在 5~6 萬元左右. 總之, 豐田模式的保養特點是 : 便宜, 據點多, 零件到處都有, 目前大電池更換成本已比早年大幅降低, 對長期持有者而言負擔已不像過去那麼高.

e-Power 常規保養並不會貴, 只比 RAV4 稍高一點, 小保養約 3,000~4,000 元, 4 萬公里的大保養原廠報價一般約 5,000~10,000元, 視保養項目而定. 大電池原廠提供 8 年或 16 萬公里保固, 然而因為是進口高規格組件, 過保後的自費更換價格預估會比 Toyota 貴 (過往經驗推估在 8~10 萬元以上). 其次, 那具負責發電的 1.5L 引擎是 VC-Turbo (可變壓縮比渦輪引擎), 這是一項能根據發電需求自動切換引擎壓縮比的精密黑科技, 雖然效率極高, 但構造較為複雜, 未來高里程過保後. 這具引擎的周邊傳感器或渦輪系統預期維修成本可能會比 RAV4 高. 另外, 它的車頭搭載了非常具有科技感的全新分離式/貫穿式 LED 燈組, 萬一發生碰撞, 車身鈑件加上進口零件的單價非常高, 乙式車體險絕對不能省.

不過在稅金方面 RAV4 的 2.5 L 引擎似乎較吃虧, 因為剛好跨過 2400cc 級距, 每年的稅費比 e-Power 多出 10490 元 :

不過車價價差 15~20 萬, 足以繳 15~20 年的 RAV4 稅金差額, 加上 RAV4 高油耗省下來的油錢其實從總持有成本 (車價 + 稅金 + 油錢) 來看也沒有那麼吃虧.

月底跟阿中從岡山回來後, 找個周六上午跟水某去 TOYOTA 北高雄賞車與試駕看看.

2026-07-12 補充 :

買 e-Power 還有一個車廠財務體質的顧慮, Nissan 近兩年出現巨額虧損, 2025 財年到 2026 年初全球累計虧損已突破 $1.2 兆日圓 (約數十億美元). 原廠被迫啟動名為 Re:Nissan 的激進重整計畫, 全球大裁員兩萬人, 甚至關閉了 7 座生產基地與設計工作室, 就連現任執行長在 2026年 3 月接受外媒訪問時都坦言不排除在未來將公司出售或尋求併購. 雖然台灣的 Nissan 是由實力雄厚的裕隆日產代理, 短期內在台灣的保養與據點不會受到影響, 但 X-Trail e-Power 是進口車, 車上搭載的是新技術的專利黑科技 "VC-Turbo 可變壓縮比引擎", 如果母廠為了省錢削減研發, 精簡海外零件供應鏈, 過保固後的有可能增加特殊零件等待時間或成本. 反觀豐田目前的財務狀況與全球市佔率依然是世界第一, 發生零件斷料的風險相對最低.

其次是電池方面, 上回曾聽同學峰大師說他自己的案例, 他開 e-Power 去露營時晚上爽爽吹冷氣, 但早上起來發現車子竟然發不動, 它不是有顆大電池嗎? 我將此案例貼給 AI 詢問可能原因, 以下是依據 AI 與公開資料整理出的可能原因, 實際情況仍須視車輛狀態與當時使用方式而定. AI 推測由於 e-Power 是 100% 靠馬達驅動, 它的行車電腦對大電池的電量安全感極低, 當車宿吹冷氣時, 只要電池電量稍有下降, 那具 1.5L 的渦輪發電機引擎就會馬上打火發電, 依氣溫與冷氣設定, 以及電池 SOC 不同, 一般可能每隔 5 到 10 分鐘就會啟動一次, 而且因為它是渦輪引擎, 為了快速拉高轉速發電, 啟動時的低頻噪音和震動在安靜的野外夜裡會非常明顯, 睡眠品質會大打折扣.

而 e-Power 在車宿長時間 READY 吹冷氣情境下可能存在相對不利的使用特性. 元兇不是那顆負責驅動車子的大電池沒電, 而是車上另一顆負責控制系統大腦的 12V 傳統小電瓶被吸乾了. 這是許多油電或電動車車宿新手最容易犯的錯誤, 很多人晚上要睡覺時為了省電, 按點火開關時沒有踩煞車, 只把車子切換到 ACC (通電) 或 ON 模式, 以為這樣就可以單純吹冷氣與聽音樂. 在這種類似紅火的狀態下, 車子誤以為你只是暫時停在路邊, 因此大電池的電力是不會輸出來幫 12V 小電瓶充電的, 此時車上的螢幕, 冷氣風扇, 車內燈, 甚至行車紀錄器全都是直接去吸那顆小電瓶的電, 不到幾個小時就會徹底被吸乾, 小電池一旦沒電, 車子的大腦無法開機, 就算大電池還有滿滿的電, 車子也會鎖死完全無法啟動 (無法進入 READY 狀態). 正確做法是跟平常開車一樣踩著煞車按啟動, 讓儀表板亮起 READY 燈號, 此時大電池的發電系統才會正式啟動, 一邊吹冷氣, 一邊隨時幫 12V 小電瓶補電.

但 e-Power 在車宿情境下仍有一項值得注意的使用特性, 即使車宿吹冷氣時有正確進入 READY 狀態, e-Power 為降低重量與成本, 搭載容量較小的高壓電池, 主要依靠引擎即時發電維持能源供應, 因此吹冷氣可能不到 10 分鐘引擎就必須啟動打火一次幫大電池補電, 每次打火發動的那一瞬間需要極大的瞬間電流, 這主要都是靠 12V 鉛酸小電池來提供, 問題就出在引擎頻繁打火可能會造成 12V 小電池來不及補滿電, 特別是冷氣開得很強耗電快, 引擎啟動發電的時間又太短, 大電池很快充飽了, 但負責回充給 12V 小電池的直流轉換器來不及把小電池充飽, 10 分鐘後就又被下一次的打火給消耗掉電力, 這樣反覆折騰到後半夜, 那顆 12V 小電池就會因為頻繁打火而徹底虛脫耗盡電力, 結果就是隔天早上小電池宣告陣亡, 整台車癱瘓.

RAV4 相對來說比較不會發生 12V 電池耗盡這種事, 因為在 READY 狀態下, 大電池的電力非常雄厚, 它不需要頻繁打火, 大電池供應冷氣 30~40 分鐘引擎才發動一次 (依外界氣溫, 空調設定及 SOC 而異), 一整個晚上頂多打火 10 幾次而已. 重點是, 豐田的 DC-DC (直流轉換器) 控電邏輯非常保守且安全, 它的行車電腦有一個相當保守的保護機制, 在 READY 狀態下, 當它偵測到 12V 小電池的電壓偏低, 其保守的 DC-DC 控電策略通常能持續維持 12V 系統正常供電. 萬一遇到大電池電量也過低, 且引擎因為特殊狀況 (例如油箱快沒油或系統保護) 無法發動時, RAV4 會在螢幕上跳出警告並自動切斷大燈, 音響與冷氣風扇等周邊耗電, 目的是要保留最後一口氣, 不讓 12V 小電池走到深度放電的死路, 所以豐田油電車在 READY 狀態下車宿吹冷氣機幾乎還沒聽說過隔天小電池會沒電的.

此外, 一般車 (包括 X-Trail e-Power) 的 12V 小電池通常放在引擎室裡面, 南部的夏天非常炎熱, 引擎運轉時的高溫動輒 70~80 度, 而高溫正是鉛酸電池短命的元兇之一. RAV4 為了平衡車身前後配重, 把 12V 小電池移到了後行李廂的右側內板裡 (也就是室內空間), 這正是讓 12V 電池變長壽的巧妙設計. 由於它位於車室後方, 工作環境通常比引擎室溫和, 有助於降低高溫對鉛酸電池壽命的影響, 許多車主開到 4~5 年才需要預防性更換. 注意, RAV4 的 12V 鉛酸電池唯一的任務就是提供微弱的電流, 幫車上的行車電腦 (ECU) 開機, 把儀表板點亮並將大電池的高壓繼電器接通, 只要能讓車子顯示出 READY, 小電池的任務就 100% 功成身退了, 它不必像一般油車的 12V 電池還要負責輸出大電流來啟動引擎, RAV4 負責發動引擎的是那顆高壓大馬達 MG1, 大電池會用它那超級大電量, 瞬間把引擎轉速直接拉到 1000 轉以上點火發動引擎, 完全用不到 12V 小電池的電力.

如果是要每天開車通勤, 重視駕車質感與靜肅性, e-Power 的駕馭體驗確實很吸引人; 但以我希望一台車再開十幾二十年, 退休後降低維修與使用成本的需求來看, RAV4 Hybrid 提供了更成熟的技術, 更完善的維修體系, 以及較低的長期持有風險. 因此這次我的選擇不是因為 e-Power 不夠好, 而是 RAV4 更符合我的用車需求.

舊筆電維修筆記索引

2026-07-12T00:14:49.784+08:00

最近兩個月把三台舊筆電陸續升版與修復到可用狀態, 最先是 ASUS X550C, 這台因為錯過 Win8 升版為 Win10 最後期限, 一些軟體卡在 Win8 而無法安裝, 最後利用 Win10 ISO 檔直接安裝升版.

其次是 DELL Vostro 2520 筆電, 此機為 Win7 專業版, 但卡在多年未用丟失管理員密碼, 連日期時間都無法修改, 最後用 Rufus 製作 Ubuntu Linux 開機 USB, 直接抹除管理員密碼而恢復掌控.

最後是這兩天修復的 INHON Carbonbook 筆電 (之前是因為系統毀損無法開機而換 ACER Swift 5), 拆機發現 SSD 是特規無法找到替代品, 原本準備放棄, 哪知清潔金手指接點後居然可以讀到 SSD 了, 這幾天用 Win10 安裝 USB 重灌後恢復正常使用.

為了以後查找方便, 將維修筆記整理索引如下 :

# ASUS X550C 筆電升版為 Win10

# DELL 老筆電 Vostro 2520 修復 (失敗)

# DELL 老筆電 Vostro 2520 修復 (成功)

# INHON 應宏 Carbonbook 筆電維修 (一)

# INHON 應宏 Carbonbook 筆電維修 (二)

# INHON 應宏 Carbonbook 筆電維修 (三)

# INHON 應宏 Carbonbook 筆電維修 (四)

# INHON 應宏 Carbonbook 筆電維修 (五)

# INHON 應宏 Carbonbook 筆電維修 (六)

# INHON 應宏 Carbonbook 筆電維修 (七)

比較可惜的是 ACER Swift 5, 兩年多前因為銀幕橫線退役後被我當作下載用的桌機, 原本用得好好的, 不料六月時遭到阿咪尿攻而無法開機, 前陣子拆機發現電源模組附近腐蝕嚴重, 修復機會渺茫, 只好讓它安息主懷.

INHON 應宏 Carbonbook 筆電維修 (七)

2026-07-11T15:44:43.541+08:00

今天終於完成 INHON Carbonbook 筆電的重灌, 讓老筆電重獲新生. 本篇要用 CrystalDiskInfo 來取得 SSD 硬碟的健檢資訊, 讓 Gemini 提出分析報告.

本系列之前的文章參考 :

# INHON 應宏 Carbonbook 筆電維修 (一)

# INHON 應宏 Carbonbook 筆電維修 (二)

# INHON 應宏 Carbonbook 筆電維修 (三)

# INHON 應宏 Carbonbook 筆電維修 (四)

# INHON 應宏 Carbonbook 筆電維修 (五)

# INHON 應宏 Carbonbook 筆電維修 (六)

CrystalDiskInfo 是一款小巧的 HDD/SSD 健康檢測軟體, 可從微軟商店免費下載安裝, 參考 :

# HDD/SSD 健康狀態檢測軟體 CrystalDiskInfo

INHON Carbonbook 的 SSD 健檢數據如下 :

Gemini 的分析結果如下 :

========================================

這顆硬碟根本沒有壞軌，它健康得很！這台筆電之前的死機，100% 只是純粹的軟體與磁區結構毀損！

從工程師與架構師的數據觀點來看，這顆掛著 Inhon_128GB 的 SSD 數據非常漂亮，可以說是以一種極其健康的姿態存活著。以下是關鍵數據的深度拆解：

📊 核心健康數據分析

磁碟健康狀態：藍色「良好」 這是最直觀的指標。如果 SSD 晶片有發生嚴重的區塊損壞、或是壽命將盡，這邊會直接顯示黃色的「警告」或紅色的「不良」。
01 底層資料讀取錯誤率：原始值為 000000000000 這行是判定硬碟有沒有「壞軌/讀取物理障礙」的最核心數據。它的原始值是全零，代表這顆 SSD 從底層硬體晶片來看，從來沒有發生過任何一次讀取失敗。
已用時間總計：4673 小時 這顆硬碟只使用了 4600 多個小時，換算下來大約只有 194 天 的連續運轉時間。對一顆一般的 SSD 來說（通常設計壽命在數萬小時以上），這顆硬碟目前正值青壯年時期，離老化還非常遙遠。
已用次數總計：6478 次 通電次數偏高（平均一小時通電 1.3 次），這非常符合「老筆電被拿來開開關關、或者頻繁進出睡眠/休眠模式」的使用軌跡，對硬碟本身的健康沒有太大負面影響。
F1 SSD 總寫入量：原始值為 000000001C9C 十六進位的 1C9C 換算成十進位大約是 7324。根據這個特規控制器的顆粒計量，它的總寫入量非常低，遠低於這顆 SSD 的寫入壽命極限（TBW）。

💡 最終診斷與 PM 效率驗證

既然硬碟硬體健康度是完美的 100% 良好，那為什麼前幾天會突然死機、修復開不起來？

結論： 當年 Windows 8 升級到 Win 10 的過程中，底層舊的 MBR 分割表與新系統的 EFI 導引產生了衝突（也就是我們一開始抓到的那個 BIOS 鎖定問題）。再加上老系統長年累積的「不安全關機次數（原始值 68 次，代表突然沒電或強制拔電源）」，最終導致微軟的系統檔案崩潰，讓硬碟「誤以為自己壞了」。

現在您透過 Rufus 強制改用 GPT/UEFI 格式，重新洗牌刪除了全部分割區，等於是用正確的鑰匙打開了這顆原本就沒病的硬碟。

您可以徹底放心了！這顆 128GB 的硬碟還能陪這台筆電再戰好幾年。現在把「還原點」跟「映像備份」做起來，這台機器在硬體與軟體層面上，都已經達到最完美的完全體狀態了！

========================================

原來本機 SSD 還頭好壯壯, 只是金手指接點髒污接觸不良而已, 擦一擦裝回去就能讀到且順利重灌, 還好沒去蝦皮買規格不太確定能否合用的二手 SSD 來重灌, 否則現在應該懊悔白花錢了.

INHON 應宏 Carbonbook 筆電維修 (六)

2026-07-11T15:23:56.435+08:00

今天巴威颱風來襲, 屋外風狂雨驟, 只能窩在書房裡繼續做 Carbonbook 復原的收尾工作 : 建立還原點與備份映像檔.

本系列之前的文章參考 :

# INHON 應宏 Carbonbook 筆電維修 (一)

# INHON 應宏 Carbonbook 筆電維修 (二)

# INHON 應宏 Carbonbook 筆電維修 (三)

# INHON 應宏 Carbonbook 筆電維修 (四)

# INHON 應宏 Carbonbook 筆電維修 (五)

1. 建立還原點 :

所謂還原點其實就是系統核心的快照, 若電腦不小心因為灌錯驅動程式, 中毒, 或是 Windows Update 更新後死機, 就可以從還原點復原, 一鍵讓電腦仿佛時光倒流般當時的健康狀態.

建立還原點作法如下 :

按 Win+S 輸入 "建立還原點" :

點選 "本機磁碟 C:" 按 "設定" 鈕 :

預設是停用系統保護 :

勾選 "開啟系統保護", 拉動下面滑桿將磁碟用於系統保護的容量設為 5~10% 後按 "確定" 鈕 :

回到系統保護頁面時, 原本灰色的 "建立" 鈕就可以按了, 按下後會彈出視窗, 在文字框輸入還原點名稱後按 "建立" 鈕就會開始建立還原點 :

完成後按關閉即可 :

未來若要回到還原點, 按 "系統還原" 鈕後按下一步 :

然後在還原點清單中點選要還原的時間, 按下一步即可 :

比較建立還原點前後 C 碟大小, 原先 C 碟為 33.6GB, 目前 C 碟為 35.8GB, 還原點大約用掉 2.2GB.

2. 備份系統映像 :

系統映像是 C 碟的完整備份, 當系統出現問題, 連還原點也受損時, 除了重灌之外, 最快復原系統的方法就是從系統映像還原. 由於此筆電只有一個 C 碟, 備份映像需儲存在另一顆硬碟,因此我找了一顆水某很久以前的紅色 My Passport 隨身硬碟 (512GB) 連接到 USB 槽.

開啟控制台 (可用 Win+S 搜尋), 將右上角的檢視方式改為大圖示或小圖示 :

點選 "備份與還原 (Windows 7)" :

按左上角的 "建立系統備份" :

這時系統會去尋可用來儲存映像的硬碟, 找到我插在 USB 槽的隨身硬碟, 其容量只要大於目前 C 碟系統所占大小即可 (加上還原點約 35.8GB), 按下一步即開始備份映像到此外接硬碟上 :

備份完成詢問是否要建立系統修復碟, 按否 :

這時外接硬碟上會多出一個 WindowsImageBackup 資料夾, 這就是所建立的備份映像, 注意, 絕對不要去修改這個資料夾的名稱, 也不要搬移它或修改裡面的檔案, 日後要從備份映像復原系統時, Windows 只認這個特定的資料夾名字.

為了辨別這是哪台主機的映像, 可以在資料夾名稱後面加註, 例如改為 WindowsImageBackup_INHON_WIN10, 萬一要復原時再去掉加註改回 WindowsImageBackup 即可. 總之, WindowsImageBackup 必須放在硬碟根目錄, 裡面的檔案目錄不要動.