接手一個已經運作中的 WordPress 網站，最容易被需求推著往前走：這裡修一下、那裡補一段，先讓畫面恢復正常再說。可是我曾經在準備動手前回頭確認，才發現手上的本機檔案未必就是線上正在使用的樣子。那一刻讓我明白，修改前最重要的工作不是寫程式，而是先替現況留下一個可信的基準。
看起來最新，不一定就是正在使用
網站維護裡，最危險的誤會之一，是把本機資料夾當成唯一真相。它可能曾經是最新版本，也可能只是某次工作的快照；時間一久，名稱再熟悉都不代表它仍和線上一致。若直接從這份印象出發修改，改對了也難以確認，改錯了更不知道差異從哪裡開始。
後來我會先把「現在實際在運作的是什麼」和「我準備修改的是什麼」分開看。這個動作看似多花一點時間，卻能讓後續討論回到具體證據，而不是依賴誰記得上次做了什麼。需求再急，也不會因此失去判斷的座標。
不知道現在站在哪裡，就很難判斷下一步是不是往對的方向走。
基準不是拖慢進度，而是讓速度有方向
建立基準並不表示每一次調整都要變得很重。它只是先把眼前的版本看清楚：哪些內容本來就存在、哪些是這次要處理、完成後應該出現什麼不同。當這三件事清楚，修改反而能更集中，驗證也不必靠猜。
尤其在 WordPress 與 WooCommerce 長期累積的環境裡，一個畫面背後常有許多歷史決定。先確認基準，是尊重既有流程，也是在替新需求留出一條能被理解的加入方式。
能比較，才談得上回復與交接
我最在意的不是把每一次變更留下多複雜的紀錄，而是未來有人回來看時，能分辨哪些是原本狀態、哪些是本次調整。只要這條界線還在，遇到意外就有依據可回頭，交接時也不必重新拼湊故事。這也讓團隊敢在有證據的前提下討論取捨，而不是害怕任何改動。
這個習慣讓我看待網站客製的方式慢慢改變：好的修改不是留下很多新功能，而是讓系統在改完之後仍然說得清楚。先確認線上基準，正是讓這份清楚得以延續的第一步，也讓每次維護都更有把握。