延續昨天的使用者測試方法，今天假設我們蒐集到了幾個典型的回饋意見，並實際動手修正。

回饋一：「不知道信心水準滑桿在做什麼」

這是典型的「功能不解釋自己」問題。修正方式是加上簡短的說明文字，讓使用者不用猜：

<!-- index.html -->
<div class="preference">
  <label for="confidence-slider">
    信心水準：<span id="confidence-value">80%</span>
  </label>
  <p class="hint">數值越高，建議出發時間越早，但越不容易遲到。</p>
  <input type="range" id="confidence-slider" min="50" max="99" value="80" />
</div>

回饋二：「不確定資料是不是最新的」

Day 10 雖然加了「最後更新時間」，但字太小容易被忽略。調整樣式讓它更顯眼，並加上「更新中」的視覺回饋：

// src/main.js
async function loadArrivals() {
  const timeLabel = document.getElementById('last-updated');
  timeLabel.textContent = '更新中...';

  try {
    const raw = await fetchBusArrivals('Taipei', '0100000A00');
    const arrivals = normalizeArrivals(raw);
    renderArrivalList(arrivalContainer, arrivals);
    timeLabel.textContent = `最後更新：${new Date().toLocaleTimeString()}`;
  } catch (err) {
    timeLabel.textContent = '更新失敗，顯示上次資料';
  }
}

回饋三：「建議出發時間的緩衝分鐘數，感覺像個黑盒子」

使用者希望理解「為什麼是這個時間」，而不只是看到一個結果。我們在建議文字中加入更透明的說明：

// src/main.js
document.getElementById('suggestion').textContent =
  `建議出發時間：${suggestion.departureTime.toLocaleTimeString()}` +
  `（根據近期資料，多預留 ${suggestion.bufferMinutes} 分鐘緩衝，` +
  `讓你有 ${suggestion.confidenceLevel * 100}% 的把握準時抵達）`;

為什麼「透明化」比「更聰明的演算法」更重要？

這是這幾天實作下來很深的體會：使用者對推薦系統的信任感，很多時候不是來自演算法多先進，而是來自「我能不能理解它為什麼這樣建議」。

這也是為什麼我在設計 SyncETA 時，特別重視把機率概念轉譯成使用者聽得懂的語言，而不是只丟出一個數字。

第五階段完成

到這裡，我們完成了離線功能、推播通知、響應式設計、以及基於（模擬）使用者回饋的介面調整。

從明天開始的第六階段，我們要進入收尾：把專案正式部署上線，讓它從「本機能跑」變成「有網址、任何人都能用」。