把 Google Gemini Spark 變成名片掃描王：設定一次 Skill，以後拍照就能整理聯絡人
Skill，以後只要拍照上傳，就能自動啟動相同規則，持續幫你整理 Google 聯絡人。
這篇文章的重點不是掃描，而是工作流
如果只是把名片文字辨識出來，傳統 OCR 早就做得到。Gemini Spark 真正有意思的地方，是它可以把「辨識 → 整理 → 套規則 → 寫入 Google 聯絡人」這幾件事串成一段完整流程。而一旦這段流程被存成 Skill，它就不再只是一次成功的操作，而是可以持續重複使用的工作方法。
先做一次：拍照後請 Spark 匯入 Google 聯絡人
問題：這一步要確認什麼？
第一次使用時，我的做法很直接：把名片照片上傳給 Spark，請它將資訊寫入 Google 聯絡人，並指定「顯示名稱」要採用 姓名（公司及職稱） 的格式。
請幫我將名片上的資訊寫入 Google 聯絡人，其中「顯示名稱」上面寫為「姓名(公司及職稱)」。
為什麼我刻意把顯示名稱改成「姓名（公司 職稱）」？
這裡其實有一個很重要的技術限制，也是我最後採用這個命名方式的最主要原因。
Google 官方目前對 Contacts 連結功能的說明，明確舉例 Spark 可以查找、新增、修改或刪除姓名、Email、電話、生日、地址等聯絡資訊。不過在我實際使用 Spark 寫入 Google 聯絡人時，公司、職稱以及備註等欄位，並沒有像姓名、電話、Email 這些主要聯絡資訊一樣，可以直接指定寫入。
這就產生了一個很現實的問題：一張名片上真正有助於辨識對方身分的資訊，往往不只有姓名、電話與 Email，公司與職稱反而是最重要的背景資訊之一。如果 Spark 最後只能把姓名、電話、Email 寫進聯絡人，那麼名片上非常有價值的「他在哪裡工作、擔任什麼職務」就會在自動匯入的過程中遺失。
例如原本只會建立：
- 王大明
- 李小華
- 陳志宏
我改成：
- 王大明（○○科技 總經理）
- 李小華（○○顧問公司 專案經理）
- 陳志宏（○○大學 教授）
這樣做不是因為「顯示名稱」本來就應該拿來存公司與職稱，也不是最標準的資料庫設計；它純粹是因應 Spark 目前欄位寫入限制所採用的實務折衷。如果未來 Spark 可以直接把公司、職稱、備註等資訊寫進 Google 聯絡人的對應欄位，我會優先採用結構化欄位，而不是把所有資訊都塞進顯示名稱。
但這個變通方式，剛好又帶來一個額外好處
即使先不談欄位限制，我實際管理聯絡人時也發現，「姓名」往往不足以讓我立刻知道對方是誰。尤其參加研討會、跨機關會議或業務交流後，短時間內可能一次新增十幾位甚至更多聯絡人；過一段時間再看到「王大明」這個名字，我未必還記得他是哪個單位、當時是以什麼身分認識的。
公司與職稱其實就是很有效的「情境標籤」。當畫面直接顯示 王大明（○○科技 總經理），我不需要再點進聯絡人詳細資料，就能立刻知道他的組織與角色。
這個差異在幾個日常場景特別明顯：
- 搜尋聯絡人時：同名或名字相近的人，可以直接用公司與職稱區分。
- 電話打進來時：螢幕上直接看到「姓名＋公司＋職稱」，更容易立刻判斷對方身分。
- 在 Gmail 選收件人時：不用先打開聯絡人詳細資料，就能降低寄錯人的機率。
- 很久以後重新聯絡時：公司與職稱能幫助我快速喚回「當初在哪個情境認識這個人」。
當然，這個方法也有代價：如果對方換公司或升職，顯示名稱就必須跟著更新。所以它是一個現階段很好用的 workaround，而不是我認為永遠最理想的聯絡人資料結構。
從這張實際操作截圖可以看到，Spark 會先整理出要新增的聯絡人資料，接著詢問你是否允許建立聯絡人。這一步很重要，因為它代表流程不是單純文字回覆，而是真的往 Google 聯絡人的建立動作前進。
另外，手機拍照時候，可以將5~6張名片排好後一次拍攝，Spark 自己可以清楚地辨識每一張名片的資訊，毋需逐張拍照。
真正的重點：把剛才的做法存成 Skill
問題：為什麼這一步才是整篇文章最重要的部分？
如果每次拿到新名片，都還要重新打一大段指令，那這個流程只做了一半。真正讓 Spark 變成「名片掃描王」的關鍵，在於你把剛剛成功的做法，直接請它寫成一個 Skill。
好的，把我們剛剛拍名片照片上傳後，自動匯入到 Google 聯絡人的做法，寫成一個 skill。以後就照這樣的模式進行：只要我拍照上傳的內容都是名片的話，請自動啟動這個 skill，然後直接幫我寫入我的 Google 聯絡人。
這句話的價值在於：你不是在告訴它「這次怎麼做」，而是在告訴它「以後遇到同樣情境，都照這樣做」。這就是 Prompt 與 Skill 的差別。
從第二張實際畫面可以看到，Spark 已成功建立並啟用 business-card-to-contacts 這個 Skill，並明確說明：未來只要上傳名片照片並要求儲存或匯入，它就會自動啟動這個 Skill，辨識名片資訊，並依「姓名（公司及職稱）」的格式直接寫入 Google 聯絡人。
Prompt 與 Skill 的差別，到底差在哪裡？
| 比較面向 | Prompt | Skill |
|---|---|---|
| 用途 | 解決這一次的任務 | 定義之後都照這樣做 |
| 重複性 | 每次都要重新下指令 | 建立一次後可反覆使用 |
| 一致性 | 容易每次寫法不同 | 可固定命名規則與處理方式 |
| 適合情境 | 偶發性問題 | 重複性的固定工作流 |
所以如果你只是想偶爾試一次，Prompt 就夠了；但如果你參加會議、論壇或交流活動後，總是會拿到一批名片，那就沒有理由停在 Prompt。這種工作本來就應該被做成 Skill。
我建議至少固定下來的 4 個規則
- 啟動條件：只要我上傳的是名片照片，就自動使用這個 Skill。
- 擷取內容：姓名、公司、職稱、電話、手機、Email。
- 命名規則：顯示名稱統一為「姓名（公司及職稱）」。
- 容錯原則：若文字不清楚或欄位不確定，不要自行猜測，先顯示給我確認。
這樣你下次還是得從頭重新說一次，根本沒有形成工作流。
匯入後只剩姓名，之後在聯絡人裡很難快速辨識身分。
名片照片若有反光或裁切不清，電話與 Email 仍可能出錯。
這個方法真正替你省下的是什麼？
省下來的不是「打幾個字」而已，而是每次活動結束後那一整段低價值、但又不得不做的整理工作。以前你要自己看名片、自己輸入、自己命名；現在則是第一次把規則教好，之後把例行操作交給 Spark。
這也是我認為 AI Agent 真正值得重視的地方：不是幫你多回答幾個問題，而是開始幫你接手一段可重複的工作流程。
結論：先做對一次，再存成 Skill
這篇文章真正要講的只有一句話：名片掃描不是重點，存成 Skill 才是重點。 當你已經證明 Spark 可以完成「拍照 → 辨識 → 寫入聯絡人」之後，下一步就不是再重做一次，而是把這套流程固定下來。
如果你桌上也常常累積一堆懶得整理的名片，這大概就是最值得先做成 Skill 的工作之一。
沒有留言:
張貼留言