昨天，我們將使用者需求轉換成 User Story、驗收條件及 MVP。

假設團隊最後決定完成這條核心流程：

使用者輸入預算、距離及飲食限制
→ 系統篩選符合條件的餐點
→ AI 比較候選項目
→ 顯示推薦理由與資料來源

接著開始分工：

• A 同學負責蒐集餐廳資料
• B 同學負責製作網站
• C 同學負責串接 AI
• D 同學負責分析與簡報

一週後，大家準備整合，卻發現：

• 有人把價格寫成 80
• 有人寫成 80元
• 有人寫成 約80～100
• 距離有時是公尺，有時是公里
• 素食有 素食、vegetarian、V、是
• 營業時間有 18:00、晚上六點、6PM
• 有些資料沒有來源
• 有些空白代表不知道，有些空白代表不適用
• AI 回傳的欄位名稱和網站需要的欄位不同

每個人的資料看起來都「差不多」，但電腦不會自動理解這些差異。

今天要建立的不是單純一張試算表，而是團隊共同遵守的「資料契約」。

資料契約是什麼？

資料契約可以理解成：

團隊事先約定每個欄位的名稱、意義、格式、單位、允許值、來源及驗收規則。

它會回答：

• 一筆資料代表什麼？
• 哪些欄位一定要有？
• 價格使用數字還是文字？
• 日期採用什麼格式？
• 空白代表什麼？
• 哪些分類值可以使用？
• 資料來自哪裡？
• 誰在什麼時間驗證？
• 網站、AI 及圖表應讀取哪一個版本？

如果沒有共同規格，團隊很容易出現：

資料蒐集者認為：「看得懂就好。」

程式開發者認為：「格式固定就好。」

AI 使用者認為：「全部丟給模型整理就好。」

最後整合者發現：「每一筆都不一樣。」

資料契約的目的，就是讓人與工具對同一欄位有相同理解。

圖 1：AI 專題的資料契約流程。原始資料先保留，再依資料字典統一欄位名稱、型態、單位與允許值；清理後必須通過格式、範圍、邏輯及來源檢查，才能發布為供試算表檢查的 CSV 及供網站、AI 使用的 JSON。製作方式：參考 IETF CSV、JSON 規格及 W3C 表格資料指南，自行繪製 SVG，輸出為 1800×1100 PNG。