TaskNotes：以 Markdown 筆記和 Bases 查詢為基礎的 Obsidian 任務外掛

任務即筆記的外掛

TaskNotes 是 Obsidian 的任務管理外掛，其決定性的設計選擇是：每個任務都是一則獨立的 Markdown 筆記，帶有 YAML frontmatter，而不是外掛自有資料庫中的一筆記錄。README 把這描述為可攜性優勢：任務只是純 Markdown 檔案，可以用任何工具讀取、用腳本轉換，或遷移到別處。frontmatter 可擴充，像 energy-level 或 client 這樣的欄位無需額外設定就能在 Bases 中用於篩選和分組。專案以 TypeScript 撰寫，倉庫元資料記錄有 2,012 個星標和 202 個 fork，以及 410 個未關閉的問題。

每個檢視都是一則 Bases 查詢

TaskNotes 中的每個檢視都是一則 Bases 查詢。Bases 是 Obsidian 的核心外掛，用於把筆記變成資料庫；它讀取筆記中的屬性，讓使用者無需撰寫程式碼即可篩選、排序和分組。TaskNotes 把任務儲存為帶有結構化 frontmatter 的筆記，然後用 Bases 查詢和展示它們。任務清單、看板、日曆和議程檢視都是 .base 檔案。TaskNotes 註冊為 Bases 資料來源，並提供四種自訂檢視類型：tasknotesTaskList、tasknotesKanban、tasknotesCalendar 和 tasknotesMiniCalendar。預設的議程檔案是一個預先設定的 tasknotesCalendar 清單檢視，模式為 listWeek。由於 .base 檔案是純文字，使用者可以直接編輯篩選和排序，或複製它們來建立新檢視。

預設檢視中的計算欄位

預設的 .base 檔案包含用於計算值的公式屬性。README 展示了其中四個：daysUntilDue、isOverdue、urgencyScore 和 efficiencyRatio。daysUntilDue 是到期日與今天的天數差；isOverdue 標記到期日已過且狀態不是 done 的任務。urgencyScore 在優先權重之上加上距到期的天數，上限為十，efficiencyRatio 把已追蹤時間表示為時間估算的百分比。使用者可以依 urgencyScore 排序，篩選只顯示已過期的任務，或把這些公式新增為欄。README 連結的 docs/views/default-base-templates.md 記錄了包含的公式完整清單。

任務結構與重複任務

README 用一個 YAML 範例說明了任務結構。一個任務可以包含標題、狀態、到期日、優先權、上下文、專案、時間估算，以及帶有開始和結束時間戳記的時間條目清單。重複任務使用 RRULE 格式並追蹤每個實例的完成情況：一個每週會議任務可以把 complete_instances 列為一個日期陣列。當某個單獨的重複實例需要自己的筆記時，TaskNotes 可以把它具體化為一個普通任務，帶有 recurrence_parent 和 occurrence_date 欄位。根據 README，發生實例筆記會繼承重複父任務的計畫元資料，如計畫時間、到期偏移、標籤、上下文、專案、提醒、詳情和時間估算，但不會複製父任務的重複規則、完成歷史或時間條目。所有屬性名都可設定；如果使用 deadline 而不是 due，可以在設定中重新對應。

時間追蹤、日曆同步與其他功能

TaskNotes 支援透過 OAuth 與 Google 和 Microsoft 帳戶同步日曆，也支援任何 ICS 訂閱來源。時間追蹤支援每個任務的開始和停止、番茄鐘計時器和工作階段歷史。重複任務支援固定或彈性的排程。README 還列出了任務之間的相依性、用於建立任務的自然語言解析，以及自訂狀態、優先權和使用者定義欄位。README 沒有說明相依性在任務 frontmatter 中如何表示，因此這一細節無法從該來源核實。

整合、語言涵蓋與授權

TaskNotes 有一個選用的 HTTP API，以及分別託管在獨立 GitHub 倉庫中的瀏覽器擴充功能和 CLI。Webhook 可以在任務變更時通知外部服務；README 指向 docs/HTTP_API.md 和 docs/webhooks.md 了解詳情。外掛介面支援英語、德語、西班牙語、法語、日語、俄語、中文、葡萄牙語和韓語。自然語言解析涵蓋英語、德語、西班牙語、法語、義大利語、日語、荷蘭語、葡萄牙語、俄語、瑞典語、烏克蘭語和中文。README 感謝 FullCalendar.io 提供日曆元件。專案採用 MIT 授權；授權條款授予使用、複製、修改、合併、發布、散佈、再授權和銷售軟體的權利，並聲明軟體不提供任何擔保。它沒有說明安全狀況、支援承諾或生產就緒性。

針對 callumalpass-tasknotes，閱讀 README 時應把安裝入口和日常使用入口分開看。先確認文件點名的執行檔、套件管理器或容器命令，再對照專案要求的作業系統、執行時版本與外部服務。這些前置條件會直接決定首次啟動能否成功，不能用其他專案的慣例代替。

配置層面的重點在於找出 callumalpass-tasknotes 真正讀取的檔案與參數。若 README 提到環境變數、設定檔、資料目錄、插件或 provider，就應逐一記錄其名稱和預設值，並觀察啟動後產生的日誌與輸出。文檔沒有交代的默認行為，應視為未知，尤其不能自行推定安全性、持久化或相容性。

從維護角度看，callumalpass-tasknotes 的功能清單不等於完整的營運承諾。需要實際檢查 README 列出的版本、依賴、資料格式和錯誤處理，確認升級時哪些狀態會被保留，哪些整合需要額外憑證。若要放入團隊流程，還要先確認其授權文字對分發、修改和商業使用的具體限制。

最小驗證可以沿用 callumalpass-tasknotes 自己提供的命令與檔案：在乾淨目錄建立最小設定，執行文件中的初始化或啟動命令，再查看 README 指定的輸出、狀態頁、產物或日誌。測試至少涵蓋一次成功流程與一次缺少必要參數的失敗流程，這樣才能分辨功能存在與實際可操作之間的差距。

callumalpass-tasknotes 的實際價值還取決於它如何處理日常變更。可以先改動一個 README 明確列出的選項，觀察重載、重新建置、快取失效或資料更新是否符合說明，再恢復原設定確認狀態沒有留下難以察覺的副作用。對需要網路、資料庫、瀏覽器或模型服務的專案，這個步驟也能把程式本身的問題與外部依賴故障區分開。

若 callumalpass-tasknotes 要交給其他人使用，交接內容不能只包含安裝命令。還要記下入口命令的完整參數、需要提交的設定檔、敏感值的存放位置、失敗時應查看的日誌，以及 README 明確列出的不支援情況。這些資訊會影響排障時間，也能避免使用者把社群版、實驗性功能或本地限定能力誤當成穩定服務。

在 callumalpass-tasknotes 的評估中，輸入與輸出的可追蹤性比功能數量更值得核對。保留一次命令執行的參數、產生的檔案名稱和關鍵日誌，才能在重跑時知道差異來自設定、依賴還是資料。若 README 沒有給出某項能力的介面或結果格式，文章只把它列為未說明，不替專案補上承諾。

部署 callumalpass-tasknotes 前也要核對資源與權限邊界。把 README 寫明的資料庫、網路、檔案系統和第三方帳號需求列成清單，逐項確認最小權限是否足夠，並把失敗時的返回值與日誌保存下來。這樣才能判斷它適合個人試用、團隊內部流程，還是需要更完整的運維審查。

採用前可在 callumalpass-tasknotes 的工作目錄執行 README 所列入口，逐項核對輸入、產物與錯誤訊息；文檔沒有承諾的行為不應當作既定能力。

編輯結論

TaskNotes 的設計讓任務保持為帶有 YAML frontmatter 的純 Markdown，並把查詢與展示交給 Obsidian Bases。MIT 授權條款授予廣泛的使用與再散佈權利，同時明確聲明不提供擔保。README 沒有記錄效能基準、安全狀況或支援承諾，這些仍屬待核實的開放問題。 對這個專案的判斷應以 README 中的實際入口為準：先按文件執行專案命令，再檢查產生的設定、服務狀態或輸出是否符合預期；若核心依賴、平台條件或文件未涵蓋的部署細節不合適，就不應只因功能清單完整而採用。

官方來源

1. Official documentation
2. Official README
3. Project repository
4. Release notes