本地 LLM 接駁 Google Calendar：識排時間之前，先鎖實改行程權限

日曆識記時間，唔代表識安排你

Google Calendar 好擅長提醒你幾點開會，不過遇到兩場會之間得四十分鐘、午飯前仲有幾份工作未做，佢唔會主動幫你判斷先做邊樣。XDA 作者 Samarveer Singh 就寫咗個 Python 程式，將每日任務、優先次序同預計需時交畀本地 LLM，再按日曆已有嘅空檔排成時間表。完成後，程式會將結果寫返入 Google Calendar，手機 widget 同電腦畫面都睇到。

呢個做法吸引嘅位幾實際：工作、煮飯、覆客同打機本身冇固定開始時間，最花精神往往係每日重新決定先後次序。模型可以一次過睇晒空檔同限制，減少朝早對住長長嘅工作清單發呆。不過原文只係一位作者嘅個人用法，佢覺得做嘢順咗，唔代表換個工作模式、任務估時或者模型都會有同一效果。

圖片：Wikimedia Commons — The original uploader was 718 Bot at English Wikipedia.（Public domain）

要準備三層工具，Calendar 設定最煩

原文嗰套組合分成三層：llama.cpp 負責喺電腦運行模型，Python 程式讀取工作清單、計算空檔同檢查結果，Google Calendar API 就讀寫行程。實際設定要先開 Google Cloud project、啟用 Calendar API、整 OAuth consent screen，再建立桌面 app 憑證。Google 官方 Python quickstart亦要求下載 credentials.json，首次登入授權後會喺本機保存 token，之後先可以自動讀日曆。

2026 年 4 月，Google 已經推出官方 Calendar MCP server 開發者預覽，畀兼容嘅 AI app 用統一接口列出、建立、更新或者刪除活動。方向上會易接過自己逐個 API endpoint 寫，不過仍然要 Google Cloud project、OAuth 同支援 MCP 嘅 host，亦未去到撳一下就用。想照原文砌一套，現階段 Python 加 Calendar API 仍然清楚直接，亦較易加入自己嘅安全限制。

RTX 4070 Ti 係測試機，唔係最低門檻

作者用 RTX 4070 Ti 12GB、Ryzen 5 7600X 同 32GB RAM，測試 Qwen3-8B、Qwen3.5-9B 同 GPT-OSS-20B 嘅量化版本，context size 設成 4096。據佢嘅數據，三次排程大約用 3.3 至 26.6 秒；最後佢偏好 GPT-OSS-20B，因為安排出嚟嘅工作轉換較順，而 Qwen3.5-9B 就快一截兼冇漏任務。呢啲只係嗰部電腦同嗰份工作清單嘅結果，唔應當成通用跑分。

如果目標只係整理一日十幾項工作，8B 至 9B 量化模型已經證明做到基本排程，12GB VRAM 亦唔係經核實嘅最低要求。較舊顯示卡、Apple Silicon，甚至純 CPU 都可能運行細模型，只係速度同工具調用穩定性要另計。實際最考功夫嘅係模型可唔可以穩定交出程式啱用嘅格式，仲有 OAuth 憑證、出錯重試同日曆更新點處理。

Prompt 寫「唔准郁」仍然會郁

原文最值得記低嘅失敗，係三款模型都試過移動作者指定為固定嘅晨早運動或每日 stand-up。作者最初只喺指示寫明嗰啲行程唔可以改，結果模型照樣為咗塞入其他工作而重新編排。佢最後改 Python 程式，先計好固定活動之間嘅空檔，只准模型喺空檔內放任務；程式再驗證開始、結束時間，超出邊界就拒絕結果。

所以穩陣做法係將模型當排程建議器：先輸出一份草稿，程式鎖死固定活動、睡眠時間、交通緩衝同每日上限，再顯示「新增咩、改咩、刪咩」畀人確認。第一版最好只准新增活動，停用刪除、改動已有會議、加入賓客同寄通知；確認後先寫入一個專用次要日曆。就算模型突然理解錯，清走嗰層測試日曆都容易過逐項救返主日曆。

本地模型只保住模型運算嗰一段

模型喺自己部機跑，工作清單可以唔經第三方 AI server，但 Calendar 資料原本仍然放喺 Google，程式亦要用網上連接 API。若果排程結果包含客戶名、會議內容或私人活動，呢啲資料寫入 Calendar 後一樣受 Google 帳戶同分享設定影響。更直接嘅風險係 credentials.json、access token 同 refresh token；Google 官方要求安全保存，唔好寫死喺程式、放入公開程式庫或者用純文字傳送。

OAuth scope 同樣要收窄。只分析空檔可用 calendar.freebusy，要睇活動內容先用 calendar.events.readonly；真係要改活動，先考慮 calendar.events 或只處理自己日曆嘅 calendar.events.owned。完整 calendar scope 可以睇、改、分享，甚至永久刪除所有可存取日曆，個人排程工具通常冇理由攞到咁闊。唔再用時亦要撤銷授權，再刪走本機 token。

日曆內容本身都可能呃到模型

Google 喺官方 Calendar MCP 文件特別提醒 indirect prompt injection：外來邀請嘅標題或描述可能藏住指令，誘使有工具權限嘅模型讀取、修改甚至刪除帳戶資料。普通 Python 排程器若果將活動描述原封不動塞入 prompt，同樣有呢類風險。程式應只抽取排程必需嘅開始時間、結束時間、busy 狀態同可信標籤，外來文字當資料處理，唔好當指令。

本地 LLM 配 Calendar 確實可以慳返每日執時間表嗰輪心力，不過原文亦示範咗模型幾有自信都會踩界。想長用，先由唯讀模式試幾個星期，記錄漏排同撞期，再逐步開放新增活動；改動同刪除繼續保留人手確認。試穩之後再逐步加權限，先至適合每日使用。

參考來源

• XDA Developers — I connected my local LLM to Google Calendar, and it schedules my day better than I ever could — original report
• Google Calendar API Python quickstart — 核對 Google Cloud project、桌面 app 憑證、credentials.json 同本機 token 設定
• Choose Google Calendar API scopes — 核對 free/busy、唯讀、活動編輯同完整 Calendar 權限差異
• Configure the Calendar MCP server — 核對官方 Calendar MCP 預覽、設定要求、可用工具同 prompt injection 警告
• OAuth 2.0 Best Practices — 核對 OAuth client credentials、access token 同 refresh token 嘅保存及撤銷建議
• Google Calendar API usage limits — 核對 API 配額、rate limit、重試同避免密集輪詢嘅官方建議

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。