警報聲一響，才知道計畫書少了哪一頁

海邊小鎮的活動中心警報聲刺耳，志工照著演練流程小跑。跑到一半卡住了，鑰匙掛錯勾，對講機沒電，低窪那條街的人一下子不知道跟誰走。讀流程像看得懂字，真的跑一遍才看見哪裡會壞。

很多寫程式的工具也差不多，只看得見「寫在紙上的流程」。它們很會把字寫得像樣，也懂常見套路。結果一遇到邊邊角角，就不一定猜得到程式跑起來會做什麼，還可能拖很慢、很吃資源。

大家當然想多做幾次演練，問題馬上來了。有些流程根本跑不起來，像缺物資或步驟寫漏。紀錄又常亂，有的抄來抄去，有的只寫結果不寫過程，記太細還會拖慢整場演練。

有人提出一種「按步驟記錄表」的設計，想把演練的每一步都寫成一來一回。這一步做了什麼，用了什麼，現場回應是什麼，需要時也補一筆中途狀態，像門到底有沒有鎖上。它想補的是，光看文字看不出的真實反應。

接著又有人畫出更大的藍圖，把很多張記錄表整理成同一套可對照的集合。它打算讓不同隊伍、不同版本的流程都能放進來，順手記下花多久、費多少力、哪些步驟真的跑到。再把不同天氣、不同場地、不同器材的情況也分層放好，方便問「哪個版本在哪種狀況會倒」。

如果這套共享紀錄真的能長期累積，寫程式的工具就不只學「流程怎麼寫」，也能對照「跑起來真的怎麼動」。它的建議可以拿演練現場的回應來驗一下，少一點看起來很有把握卻帶錯路的狀況。警報再響時，大家靠的就不只是漂亮的紙本。