一次建檔的三個檔案位置
名片第 1 面主要圖片，原則上必填
名片第 2 面僅限同一張雙面名片
人物相片選填，第一版先保存來源
固定規則：一筆建檔只代表一張實體名片。不同公司、品牌或角色的另一張名片，必須另外建立並取得新的名片 Key。
目前技術方向：標準 HTML＋Google Apps Script＋Google Sheets＋Gemini API。第一版先證明 OCR 到 KM 的主線，不急著加入相機、人臉、向量資料庫或 Agent。
完整地想，分階段做，再交給 AI Coding
01 發想展開完整需求
02 收斂處理矛盾與取捨
03 Master SPEC定義完整系統
04 分階段安排相依與驗收
05 AI Coding逐階段實作
06 演進依整體路線擴充
分階段不是做到哪裡才想到哪裡。Master SPEC 先描述完整系統、資料生命週期與最終模組；每次 AI Coding 只實作指定 Phase，並且不能破壞後續階段已確認的資料與介面。
01 上傳一張實體名片
02 辨識Gemini 對應欄位
03 修正人工確認內容
04 匹配提出人物候選
05 寫入保存來源明細
06 歸納更新人物 Context
Key
名片 Key 使用建檔日期與當日流水號：
C-20260803-001
人物 Key 使用建立時姓名與第一張名片：
鄭福強#C-20260803-001
資料分層
- 名片明細保存來源事實
- 人物索引負責精確比對
- 人物 Context 提供 LLM 使用
- AI 歸納可重建，原始名片不可被改寫
Drive 素材入口
每位人物可以手動提供一個 Google Drive 資料夾網址或 ID。同一人物的多張名片共用此資料夾。
第一版不自動建資料夾、搬移素材或修改權限。
人工確認介面
欄位修正
修改、移動、清空或補充 Gemini 對應的欄位。
人物匹配
查看姓名、Email、電話、公司、角色及 AI 理由。
最後決定
選擇既有人物、建立新人物，或暫時標記待確認。
待討論
- 圖片保存與壓縮流程
- Sheets 正式工作表結構
- Gemini JSON Schema
- 人物候選分數規則
- Context 版本歷程
- GAS 存取與防濫用
Phase 1 暫不實作
以下仍屬於 Master SPEC，安排在後續階段：
- 手機相機直接拍攝
- 人物影像匹配
- 物件、品牌與對話
- 情報排程與 BI
- 向量搜尋、RAG 與 Agent
- Drive 自動化與治理
整體階段路線
Phase 1
名片 OCR、人物匹配、Sheets KM、Context 與基礎運用。
Phase 2
人物影像、物件品牌、對話與多來源人物知識。
Phase 3
情報排程、全文與向量搜尋、RAG、BI 與 AI Insight。
Phase 4
Workflow、Agent、治理、成本與架構升級。
進入 AI Coding 前檢查
開發途中出現新想法
先寫變更單，不直接插入程式修改：
CR-001
提出原因：
影響畫面／資料／API：
是否阻擋 v1.0：
決定：v1.0／v1.1／不採用
完成不是「可以動」
- 輸入與輸出符合 SPEC
- 空值及錯誤狀態可處理
- 人工確認點沒有被跳過
- 真實案例可以重現
- 未擅自加入範圍外功能