• 菜雞行為：把本機或 Demo 能跑當成已經交付
• STAR 階段：A+R (Action + Result)
• 本篇定位：交代如何逐項關閉 Demo、資料與正式環境的差距。

這個系列會用 STAR 架構整理每一段職場故事。STAR 分別代表情境（Situation）、任務（Task）、行動（Action）與結果（Result）。每個故事會拆成三天：第一天談 S，還原當時的情境與我原本的理解；第二天談 T，釐清真正的任務、限制與完成條件；第三天則合併 A 與 R，整理我採取的行動、造成的結果，以及後來學到的事。

這篇在三日故事中的位置

Day 08｜Demo 之外，我其實還欠資料、環境和交付條件，留下分成四層的任務定義。本篇交代我做了什麼、留下什麼證據、哪些仍是限制。

把差距寫成一張可以排序的表

虛構的粉鳥工單服務走到收尾這一段。我把展示與正式環境的差距拆成資料、權限、設定、部署、錯誤處理與維運六類，逐項填進《Demo差距表》，替每項決定三種結局之一：本次處理、延後並記錄，或列為交付限制。

順序只有一個原則：先驗會推翻設計的。資料與權限錯了要重做結構，監控晚補只是晚補。

最花時間的資料差距，用一紙契約關閉

最花時間的是資料。我取得真實樣本，把每個欄位的型別、單位、缺值處理與來源寫成《資料契約表》，逐欄與來源系統核對。它把「資料應該沒問題」換成逐欄可檢查的條款：時區、單位與唯一性都在對表時被迫講清楚，不是上線後用錯誤慢慢學。

展示成果與正式限制，可以分開驗收了

結果不是一次到位的上線，而是驗收邊界變清楚。我交付的不再只是會動的畫面，而是畫面加差距表與資料契約：哪些在正式環境驗證過、證據是什麼；哪些延後、記在哪裡；哪些列為限制。別人可以逐項檢查，不必再相信我的「差不多了」。限制也要說清楚：差距表只涵蓋我想得到的類別，沒列進的一樣會漏；部署驗證過一次，不保證每次都順；尖峰量與監控仍是待辦。小功能不必整套流程，樣本核對加一句限制就夠。

粉鳥工程筆記：差距不會自己消失

差距先分類再排序，先驗會推翻設計的；每項差距只有處理、延後或列為限制三種結局，不留「應該沒問題」；證據跟著交付走，驗收對表不對人。

今天可以帶走的練習

替一項要交付的功能，排半小時完成《Demo差距表》，圈出三項最高風險差距，各設計一個能證明補齊的證據；資料類差距另補《資料契約表》。產出是差距表加驗證計畫，驗收方式是另一位讀者能看懂每項差距的結局。口頭可確認的小改動不必填表。

對應工具：《資料契約表》。

# 資料契約表

用途：明確定義欄位的型別、單位、缺值與來源。
使用時機：資料要從展示樣本換成正式來源時。
不必使用：欄位極少且口頭確認已足夠時。

| 欄位 | 型別 | 單位 | 必填 | 缺值處理 | 來源 |
| --- | --- | --- | --- | --- | --- |
| 建立時間 | 日期時間 | UTC | 是 | 拒收並記錄 | 來源系統 |
| 工單金額 | 整數 | 新台幣元 | 否 | 以零計並標記 | 來源系統 |

提醒：逐欄與來源核對；不放機密、個資與可辨識人物。

下一篇

交付邊界清楚了，但程式裡還住著另一種樂觀。Day 10｜我只畫了 Happy Path，然後讓現實負責例外。