為什麼不用系統提醒事項，而是自己實作一個

系統提醒事項很好。它穩定、輕巧、和系統通知結合得足夠自然。對於「下午三點取快遞」「週五交材料」這樣的事情，它已經足夠好。

但 Knoself 想解決的不是「到點響一下」這麼簡單的問題。提醒背後的意圖是什麼？後來有沒有真的發生？如果發生了，花了多少時間？它屬於哪個長期目標？一週、一個月之後，能不能成為復盤的一部分？

這就是為什麼我們沒有把系統提醒事項當作主系統，而是選擇自己實作一個提醒事項體系。

提醒不是一個鬧鐘，而是一個意圖

一個提醒事項，其實是你對未來的自己說的一句話。

「晚上復盤 10 分鐘」不是一個孤立的通知，它可能屬於「自我整理」這個長期目標；「週三健身」也不只是待辦，它和運動、睡眠、精力狀態都相關。

如果提醒只停留在系統 App 裡，它通常只會回答一個問題：你有沒有完成它？

但 Knoself 還想繼續往下問：

• 你什麼時候開始做的？
• 實際花了多久？
• 做的時候狀態如何？
• 它和哪些標籤、照片、記錄有關？
• 一個月後回看，它是不是仍然重要？

這些問題，才是時間記錄真正關心的部分。

系統提醒事項不適合作為長期的個人資料庫

系統提醒事項的設計目標，是提供通用、系統級的提醒能力。它不應該、也很難承載 Knoself 需要的完整上下文。

Knoself 的提醒事項需要自然連接：

• 標籤體系：把提醒放進工作、學習、健康、家庭等長期分類裡。
• 計時記錄：從提醒一鍵開始計時，知道計畫到底變成了多少真實時間。
• 照片和備註：保留當時的場景，而不是只留下標題。
• 循環完成記錄：每天背單字、每週運動，不應該因為完成一次就關閉整條提醒。
• 復盤圖表：在週報、月報裡看到計畫與行動之間的距離。

如果把系統提醒事項當作唯一來源，就很容易陷入一種尷尬：Knoself 想表達的內容，系統提醒事項沒有欄位；系統提醒事項發生了變化，Knoself 又必須猜測它背後的真實含義。

長期來看，這會讓提醒事項變成一套脆弱的同步邏輯，而不是可靠的自我管理工具。

不做雙向同步，是為了減少混亂

雙向同步聽起來很美：你在系統提醒事項裡改一下，Knoself 也跟著變；你在 Knoself 裡完成一次，系統裡也自動更新。

但真實使用裡，雙向同步往往意味著更多邊界問題：

• 在兩個 App 裡同時修改，哪個版本算數？
• 循環提醒完成「今天」時，系統裡的整條提醒要不要完成？
• 一個提醒被移動、刪除、重建後，舊的計時記錄還算不算同一個任務？
• 系統提醒事項裡的列表，是否應該自動變成 Knoself 的標籤？

與其把複雜性藏在後台，讓使用者在出錯時才發現，不如一開始就把邊界說清楚：

Apple 提醒事項可以作為匯入來源，但 Knoself 的提醒事項由 Knoself 自己管理。

匯入之後，兩套系統彼此獨立。這樣更樸素，也更可靠。

自研提醒事項能完成「計畫 - 執行 - 復盤」的閉環

Knoself 的核心不是待辦清單，而是時間覺察。

所以在 Knoself 裡，提醒事項不是終點，而是起點：

1. 你建立一個提醒，表達一個未來的意圖。
2. 到了合適的時候，你從提醒開始計時。
3. 計時結束後，這段行動進入時間線。
4. 之後在圖表、標籤、復盤裡看見它。

一條提醒，最終會變成一段真實發生過的時間。

很多計畫之所以讓人焦慮，不是因為計畫本身太多，而是因為它們永遠停留在「我應該做」的層面。Knoself 希望把計畫輕輕推向現實：不逼迫你完成所有事，只幫你看見哪些意圖真的走進了生活。

系統提醒事項仍然有它的位置

我們並不是否定系統提醒事項。相反，它是很多人已經長期使用的工具，裡面沉澱了不少重要待辦。

所以更合適的方式是：讓系統提醒事項成為遷移入口。你可以把已有的未完成事項匯入 Knoself，然後從這裡繼續管理它們。

匯入後，Knoself 不會偷偷寫回系統提醒事項，也不會在後台持續讀取你的提醒。這個邊界看似保守，但它能讓資料關係更清楚：

• 系統提醒事項負責原來的輕量提醒。
• Knoself 負責與時間記錄相關的提醒、計時和復盤。

兩個工具各自做好自己擅長的事。

不是為了做更多功能，而是為了少一點割裂

自研提醒事項並不是為了重複造一個待辦 App。

它真正的意義，是減少割裂：計畫不再躺在一個 App 裡，計時不再躺在另一個 App 裡，復盤也不再只是一張事後統計圖。

當提醒、標籤、照片、計時和圖表連在一起時，你看到的就不只是「還有哪些事情沒做」，而是：

我把時間交給了哪些承諾？哪些承諾真的值得繼續？

這才是 Knoself 想實作提醒事項的原因。