一次建檔的三個檔案位置
名片第 1 面主要圖片，原則上必填
名片第 2 面僅限同一張雙面名片
人物相片選填，第一版先保存來源
固定規則：一筆建檔只代表一張實體名片。不同公司、品牌或角色的另一張名片，必須另外建立並取得新的名片 Key。
課堂與未來分開看：本堂先用純前端 HTML Mock POC 證明 OCR 到 KM 的主線，不串接正式 API 或資料庫。未來 MVP 可評估 Google Apps Script＋Google Sheets＋Gemini API，也可依資料量、權限及維護需求改採其他雲端或地端架構。
完整地想，分階段做，再交給 AI Coding
01 發想展開完整需求
02 收斂處理矛盾與取捨
03 Master SPEC定義完整系統
04 分階段安排相依與驗收
05 AI Coding逐階段實作
06 演進依整體路線擴充
分階段不是做到哪裡才想到哪裡。Master SPEC 先描述完整系統、資料生命週期與最終模組；每次 AI Coding 只實作指定 Phase，並且不能破壞後續階段已確認的資料與介面。
01 上傳一張實體名片
02 辨識多模態模型對應欄位
03 修正人工確認內容
04 匹配提出人物候選
05 寫入保存來源明細
06 歸納更新人物 Context
ID 與可閱讀索引
名片 ID 使用建檔日期與當日流水號：
C-20260803-001
人物正式主鍵使用建立後不再改變的 Person ID：
P-20260803-001
姓名與第一張名片可另組成人看得懂的索引：鄭福強#C-20260803-001。改名時更新姓名欄位與別名，不改 Person ID。
資料分層
- 名片明細保存來源事實
- 人物索引負責精確比對
- 人物 Context 提供 LLM 使用
- AI 歸納可重建，原始名片不可被改寫
Drive 素材入口
每位人物可以手動提供一個 Google Drive 資料夾網址或 ID。同一人物的多張名片共用此資料夾。
第一版不自動建資料夾、搬移素材或修改權限。
人工確認介面
欄位修正
修改、移動、清空或補充 Gemini 對應的欄位。
人物匹配
查看姓名、Email、電話、公司、角色及 AI 理由。
最後決定
選擇既有人物、建立新人物，或暫時標記待確認。
未來 MVP 待確認
- 圖片保存與壓縮流程
- 正式資料庫或工作表結構
- 模型 Structured Output Schema
- 人物候選分數規則
- Context 版本歷程
- 後端存取、權限與防濫用
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
- 空值及錯誤狀態可處理
- 人工確認點沒有被跳過
- 真實案例可以重現
- 未擅自加入範圍外功能