一顆「已服藥」按鈕被搬到了首頁：巧鵲藥歷 1.2.1，把確認這件事變短了

2026 年 9 月 12 日，開發者 itbunan 在 V2EX 分享創造板發布了用藥提醒工具「巧鵲藥歷」的 1.2.1 版本更新。這次更新沒有動用藥計畫的核心邏輯，改的是兩個每天都要經歷的環節：喫完藥之後怎麼更快留下紀錄，以及怎麼在微信裡持續收到下一次提醒。乍看是小版本號裡的小改動，但從介面設計的角度看，它處理的其實是工具類產品最核心的一組張力：入口要多短，錯誤要多可挽回，授權要多誠實。

從劑次詳情頁，到一顆首頁按鈕

舊版的確認流程是線性的：打開劑次詳情，提交「我已喫藥」，一次紀錄才算完成。對按時服藥、無需補充任何資訊的多數日子來說，這條路徑重複得有些囉嗦。工具的儀式感一旦超過它的必要性，使用者就會開始跳過紀錄，而跳過紀錄的提醒工具，等於失效。

新版把一顆「已服藥」按鈕直接放進首頁的待服藥卡片。點一下，本次紀錄完成，該劑次後續的升級提醒同步停止。想填剩餘藥量、照片或備註的人，仍然可以點整張卡片進入原本的詳細頁。這裡的取捨很清楚：快捷入口服務「正常服藥」這個高頻場景，完整入口保留給低頻但需要資訊的場景，兩者並存，而不是用一個取代另一個。

這種做法與蘋果「健康」App 的服藥提醒相比，方向是相反的起點但收斂到同一個問題。V2EX 用戶 Nasdaq 在回覆中提到，他用蘋果的服藥通知時，最大痛點是需要空腹服用的藥品忘記點確認，導致二次服藥或乾脆不服。這條回覆其實點出了確認介面的另一面：確認太麻煩會被跳過，確認被跳過之後，系統與使用者對「到底喫沒喫」的認知就分岔了。巧鵲藥歷這次把按鈕前移，正是在縮短這段認知分岔的窗口。

撤銷不是改文字，是重新核對一次計畫

操作變短的下一步，必然是給誤觸留退路。快捷確認成功後，首頁會短暫顯示「撤銷」與剩餘時間，倒數之內點擊即可收回剛才的確認。

值得留意的是開發者對撤銷的描述：撤銷並非簡單把頁面文字改回「待服藥」，系統會重新核對用藥計畫、當前劑次與提醒狀態，再決定是否恢復；已修改或暫停的計畫不會被錯誤地恢復舊提醒，藥品庫存也按本次實際扣減的數量返還。這段話透露的設計態度，比按鈕本身更有分量。很多產品把撤銷做成 UI 層的 Ctrl+Z，視覺上回去了，資料層卻留下一堆不一致。巧鵲藥歷選擇讓撤銷走一遍完整的狀態機，慢一點，但每一條相依的資料都對得上。

倒數撤銷這個模式，在郵件與檔案工具裡已經很常見， Gmail 的送出撤銷是經典範例。把它搬進用藥紀錄，情境是成立的：服藥確認的錯誤成本高於送錯一封信，而操作又簡單到容易誤觸。倒數時長的拿捏會是下一個考驗，太短等於沒有，太長則紀錄處於懸置狀態。

一次性訂閱：把微信的規則誠實地攤開

新版加入的第二件事，是微信小程式訂閱通知。完成訂閱後，到達提醒時間，系統可透過微信服務通知發送本次服藥資訊，內容圍繞這一次服藥展示藥品、時間、劑量與必要備註，點擊可回到小程式繼續處理。

微信小程式的一次性訂閱機制，用過的人都熟悉它的彆扭：使用者每同意一次，系統才獲得一次可用的通知次數。大多數小程式的做法是假裝這個機制不存在，授權一次之後默默失效，直到某天提醒不再出現，使用者一頭霧水。巧鵲藥歷這次選擇把規則攤開：首頁與通知方式頁會顯示當前剩餘次數，並提供兩個入口補充，首頁提醒橫幅的「去訂閶」與「我的 → 通知方式 → 小程式訂閱通知」。拒絕本次申請不會被當成同意，每一次授權都由使用者主動發起。

更細的一處是「恢復提醒」。微信會記住使用者對某類訂閱訊息的長期選擇，一旦曾經關閉，再點普通的訂閱按鈕可能不會彈出授權視窗。新版會識別這種狀態，把按鈕改為「恢復提醒」，點擊後先說明原因，再打開微信提供的小程式通知設定頁，讓使用者在當前流程內重新開啟，免去去歷史訊息裡翻找當初那條被拒絕的通知。

這個細節的價值在於，它承認了平臺的記憶會變成使用者的死路，並主動替使用者把死路接回活路。多數小程式在這裡的表現是沉默：按鈕沒反應，使用者歸因於「這 app 壞了」，然後流失。

通知策略的邊界感

更新說明裡還有一段容易被略過，但對老用戶重要的內容。預設通知策略已包含小程式訂閱通知，但曾自訂過通知策略的用戶，系統不會擅自把新渠道加進去，需要自行到「我的 → 通知策略」確認是否放入需要的提醒層級。只有「獲得可用通知次數」與「把該方式加入通知策略」同時成立，這條通道才會參與提醒。

這是一種有節制的更新倫理。產品迭代最常見的粗暴做法，是把新功能預設推給所有用戶，用「為了你好」包裝對既有設定的覆寫。巧鵲藥歷選擇尊重原有設定，代價是說明文字變長、部分用戶需要手動操作，換來的是信任不被更新消耗。

討論區裡的另一個觀察

這則貼文的回覆區還有一個與介面無關、卻與設計誠實度有關的插曲。用戶 wobuchiyu 一眼指出更新說明的 border-left 排版是 AI 產物，開發者坦然承認「感覺現在離不開 AI 了」。另一個由 FlashTiger 提出的問題則更尖銳：如果用戶是老年人，使用是否需要更友好。

這兩則回覆合起來，恰好框出了這類工具的真實處境。用藥提醒的核心用戶羣裡有大量長輩，而首頁快捷確認、倒數撤銷、剩餘次數、恢復提醒這一整套介面，對年輕開發者是常識，對長輩可能是障礙。1.2.1 把流程變短了，但「短」與「容易」在面對不同使用者時，並不永遠是同一件事。

收在原則上

更新說明最後重申了一條基本原則：收到通知不等於已經服藥，只有本人確認後，系統才把該劑次記為已服用；小程式訂閱通知是新通道，不取代站內訊息、簡訊、語音等既有方式；工具負責記錄與執行已確定的用藥計畫，不提供診斷，不決定漏服後是否補服。

提醒與紀錄各司其職，這句話把整個 1.2.1 的改動收攏得很好。入口變短是為了讓確認更容易發生，撤銷與狀態核對是為了讓錯誤可以修復，訂閱次數的透明呈現是為了讓提醒的兌現可以被預期。一個小版本能把這三件事都對齊在同一條原則下，已經比多數求快的迭代值得多看一眼。至於 Nasdaq 提出的空腹藥忘記確認難題，那需要的是更主動的追問式介面，或許會是 1.3 的課題。