Gemini 開始接上越來越多：
Connected Apps。
方便歸方便，
但很快會遇到一個新問題：
同一件事情，到底要去哪個 App 找？
例如你問：
「這星期還有哪些工作沒完成？」
答案可能存在：
monday.com。
Google Calendar。
Google Drive。
甚至：
Email。
如果全部都已經連上 Gemini，
不要第一句就只問：
「幫我整理這星期沒完成的工作。」
今天只多做一個動作：
先指定來源。
第一步：先打 @
Google 官方支援在 Gemini Prompt 裡輸入：
@
再選擇要使用的 Connected App。
例如：
@monday.com
接著再問：
「整理本週到期和已逾期的工作。」
這個動作的目的很簡單：
先告訴 Gemini，這一題到底去哪裡找。
為什麼要自己指定？
因為 Connected Apps 越多，
「有更多 Context」
不一定永遠比較好。
假設：
Calendar 裡有一場：
「網站改版確認」。
Drive 裡有：
舊版改版清單。
monday.com 裡則有：
真正目前正在執行的 Tasks。
如果你真正想知道：
目前哪些工作沒完成，
monday.com
可能才是：
Source of Truth。
這時候：
資料越多
反而越可能把不同時間、
不同用途的資訊
混在一起。
所以今天第一句可以直接這樣想
不是：
「幫我找專案進度。」
而是：
「@monday.com，只用這個專案資料整理目前未完成工作。」
注意：
這不是 Google 官方固定 Prompt。
只是：
SasaDaily 建議的一種寫法。
真正關鍵是兩件事：
指定 App。
指定這次的資料範圍。
接著再補第二句：「只讀、不修改」
例如第一次測試時，
可以要求：
「只讀取與整理，不要新增、修改、刪除或送出任何內容。」
這句話的目的不是：
創造一套新的 Security System。
而是：
先把這一次工作的：
Action Boundary
講清楚。
因為 Connected Apps
未來最重要的差別，
就是：
有些只讓 Gemini：
找資料。
有些則可以：
Create。
Update。
Send。
Archive。
Manage。
一旦 Connector 可以寫，
風險就和單純 Search：
完全不同。
但一定要知道：「只讀」不是技術權限
這裡很重要。
Prompt 寫：
「不要修改。」
並不代表：
Gemini 的 Connector
從此真的失去：
Write Permission。
它只是：
這一次的行為指令。
如果該 App 本來就允許 Gemini：
Create。
Update。
Send。
那能力本身：
仍然存在。
所以不要把：
Prompt Boundary
當成：
Permission Boundary。
真正的 Permission 還是在 Connected Apps 設定與原服務裡
Google 官方讓你：
在 Connected Apps Settings
查看：
目前有哪些 App 可以連。
不同 App 支援哪些 Action。
也可以：
Disconnect。
而企業或工作帳號，
還可能再受到：
Workspace Administrator
與原服務本身權限控制。
所以如果公司規定：
這個帳號：
絕對不能修改某類資料，
真正要處理的不是：
每次 Prompt 都寫：
「拜託不要改。」
而是：
從權限設計本身限制。
今天這招只是第一層
它解決的是：
第一次使用 Connected App 時，
不要立刻讓 AI：
讀很多來源。
又同時採取 Action。
你先把問題縮成：
一個來源。
一個任務。
只讀。
這樣最容易驗證：
Gemini 到底有沒有找對東西。
實際例子：專案管理
假設你的團隊：
monday.com
管理工作。
Google Calendar
管理會議。
Drive
放文件。
你今天只想知道：
哪些 Tasks 快到期。
不要問：
「幫我整理這星期所有重要事情。」
先改成：
「@monday.com，只讀取目前專案。列出本週到期、逾期與 Blocked 的工作，不要修改任何項目。」
這樣有三個好處。
第一：你知道答案應該從哪裡來
如果 Gemini 說：
「星期五要交 Proposal。」
你可以直接：
回 monday.com
核對。
不是猜：
它到底從：
Calendar。
Email。
Drive
哪裡看到的。
第二：答案錯了比較容易找原因
如果資料不對，
先檢查：
monday.com 裡：
原始資料是不是就錯？
Gemini：
有沒有漏掉？
還是：
Connector 沒拿到正確 Board？
如果一次把五個 App 全開，
錯誤發生時：
很難知道是哪一層出了問題。
第三：不會第一輪就改資料
第一次 Connected App Test
最重要的不是：
證明 AI 能自動工作。
而是先確認：
AI 到底看到了什麼。
先讓它：
List。
Summarize。
Compare。
真正的：
Update。
Create。
Send
可以等：
答案穩定後
再開。
第二輪才加入「準備修改」
假設第一輪：
Gemini 正確找出：
3 件逾期工作。
下一步不要直接說：
「全部延期到星期五。」
可以先說：
「先列出如果延到星期五，將修改哪三個項目；不要執行。」
這時 AI 從：
Read
進入：
Draft Action。
仍然沒有：
真的改。
第三輪才是真的 Action
確認：
項目對。
日期對。
Owner 對。
沒有動到：
其他工作。
最後才說：
執行修改。
這其實是一個很簡單的三層：
Read。
↓
Preview。
↓
Write。
真正導入 Connected Apps，
這個順序比：
第一天就全自動
安全很多。
@App 的另一個好處：多個同類工具不容易搞混
Google 官方甚至特別提醒：
如果連了多個：
Tasks／Reminders Apps，
Gemini 可能預設使用：
最近一次存取的那個。
這時就可以透過：
@
明確指定：
這次到底要用哪一個。
所以 @App
不是只是：
方便叫出工具。
它也是：
資料來源控制。
同一個問題，Source 不同，答案可能完全不同
例如：
「今天有哪些事要做？」
如果指定：
Calendar，
答案可能是：
會議。
如果指定：
monday.com，
答案可能是：
Project Tasks。
如果指定：
Gmail，
答案可能變成：
尚未回覆的要求。
三個答案：
都可能沒有錯。
只是回答：
不同問題。
所以 Connected Apps 時代，
Prompt 裡會多出一個以前不太需要想的問題：
「我希望 AI 把哪一個系統當成真相？」
公司最好替不同問題定 Source of Truth
例如：
Project Status：
monday.com。
正式文件：
Drive。
會議時間：
Calendar。
客戶付款：
Accounting System。
CRM 狀態：
CRM。
這樣未來問 AI：
大家比較容易知道：
哪裡是：
正式來源。
哪裡只是：
參考 Context。
不要讓 Gemini 替公司猜「哪份資料才是真的」
如果：
Drive 有舊版 Excel。
monday.com 有新版 Task。
Email 又有客戶臨時修改。
AI 不一定知道：
公司內部到底規定：
哪個算正式。
這不是：
模型能力問題。
而是：
Workflow Governance。
人要先定義。
AI 才有辦法：
照規則工作。
如果答案重要，再看來源
Google 對工作／學校帳號的 Connected Apps
也明確提醒：
Gemini 仍然可能：
Hallucinate。
也可能拿到：
Outdated Information。
例如：
找到比較舊的 Email，
忽略：
比較新的版本。
所以：
連上真實資料
不代表：
答案自動變成 100% 正確。
遇到：
客戶承諾。
付款。
截止日期。
正式報價。
合約。
仍然應該：
點回原始資料確認。
Connected Apps 最危險的誤解就是：「既然是我的資料，AI 就一定不會搞錯」
不是。
以前 Chatbot
可能：
憑模型記憶回答錯。
現在 Connected App
可能：
找到真的資料，
但：
找到錯版本。
選錯 Record。
理解錯欄位。
混淆兩個 Project。
所以：
Grounded in your data
和：
Guaranteed correct
不是同一件事。
今天不用學十種 Connector
只學這個：
下次 Gemini 要碰工作資料時，
不要直接問：
「幫我處理。」
先變成：
@App
＋
要找什麼
＋
只讀、不修改。
例如：
「@monday.com，只讀目前 Project，列出本週逾期與 Blocked 工作，不要修改任何項目。」
就好。
如果你連的是其他 App，也是一樣
例如：
Airtable：
先指定：
只查某個 Workspace／Table。
PandaDoc：
先只列出待處理 Documents。
Drive：
先只找某個 Project Folder。
Calendar：
先只整理這週 Events。
不要一開始就：
跨所有 Connector
找資料＋改資料＋寄出去。
一分鐘做完的真正目的
不是：
讓 Prompt 看起來更專業。
而是：
讓 AI 工作：
比較容易驗證。
知道：
去哪裡找。
找了什麼。
有沒有改東西。
結果錯了：
從哪裡查。
這比：
一次下很厲害的長 Prompt
更適合真正工作。
最後記住三行
使用 Gemini Connected Apps 前：
第一行：@App 鎖定來源。
第二行：說清楚要讀哪一段資料。
第三行：第一次先寫「只讀、不修改」。
等你確認：
資料找對。
答案可靠。
範圍正確。
下一次再決定：
要不要讓 AI：
真的採取 Action。
因為 Connected Apps
真正改變的，
不是 AI：
知道更多。
而是 AI：
開始碰到你的：
真實工作。
越接近真實工作，
越需要先把：
資料來源
和：
行動邊界
講清楚。
如果你也想知道自己的工作裡，哪一步最適合先交給 AI，留言「流程」。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
推薦閱讀
今日 AI 工具｜2026/08/13：Glean，把 Drive、Slack、Microsoft 365、Salesforce 的公司資料變成一個 AI 搜尋入口
AI 一分鐘教學｜2026/09/16：Claude for Small Business 排程前，先跑 1 次「影子測試」：只讀、只草擬、不送出
AI 快問快答｜2026/09/16：Claude 會沿用 QuickBooks／Drive 權限，就代表一定看不到「不該看的」公司資料嗎？
