• 菜雞行為：把本機或 Demo 能跑當成已經交付
• STAR 階段：S (Situation)
• 本篇定位：呈現我如何將本機成功與 Demo 順暢誤認為接近交付。

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

這篇在三日故事中的位置

上一組故事收在 Day 06｜我把決策縮小後，重做的程式碼也跟著變少。這一組的學生味是：把本機或 Demo 能跑當成已經交付。本篇只還原情境，任務留給 Day 08。

匯入功能一次跑通，我的進度回報開始變樂觀

虛構的粉鳥工單服務再往前一段。匯入功能在本機跑通那天，我用固定測試帳號、十幾筆理想資料、手動下指令啟動，畫面一路綠燈；對內展示也很順，工單一筆筆進來、清單即時更新。我的進度回報，悄悄從「還在做」變成「差不多了」。把兩邊條件攤開，其實是兩個世界：

表格每一列，都是我準備展示時親手排掉的變數；出錯，就在畫面外重跑一次。展示愈順，愈只證明舞台布置得好。

Demo 證明的範圍，比我以為的小

這不是要嘲笑 Demo。它證明主要流程走得通、介面方向可以討論、技術上沒有明顯死路，在早期都是重要證據。問題在我把「證明可行」讀成「接近交付」：成功畫面具體可見，部署、權限與失敗處理還沒發生，抽象又安靜；具體的成功，自然壓過抽象的缺口。

成功畫面之外，站著部署、維運與失敗

本機成功、Demo 成功與正式可用，是三個大小不同的證明範圍。本機成功證明程式在我的環境會動；Demo 證明挑選過的條件下流程走得通；正式可用卻要求它在別人的環境與資料上、我不在場時持續會動，還要壞掉有人知道。前兩件我有證據，第三件連清單都沒有。

「可以了」要指明在哪裡可以

任務還沒定義，我先把三個問題釘在牆上：「可以了」有沒有指明在哪個環境、用什麼資料；展示用的帳號與資料，跟正式使用者拿到的差多少；若我下線一週，最先壞掉的是哪裡。

今天可以帶走的練習

挑一項只在本機可運作的功能，用《Demo差距表》列出正式環境可能不同的資料、帳號、網路、設定與啟動方式，各補一句風險。產出是一頁差距清單，另一位讀者能指出最危險的一列即通過。使用者只有自己的小工具不必填表。

對應工具：《Demo差距表》。

# Demo 差距表

用途：盤點展示條件與正式使用條件的差異。
使用時機：準備用本機或 Demo 成果回報「快完成」時。
不必使用：純個人工具，或口頭確認已足夠時。

| 項目 | Demo 條件 | 正式條件 | 差距 | 風險 |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |

提醒：只填會影響交付判斷的差距；不放機密、個資與可辨識人物。

下一篇

差距列出來，還不是能驗收的任務。Day 08｜Demo 之外，我其實還欠資料、環境和交付條件，會定義展示品到可交付之間欠的東西。