系統不該一忙就失靈。
韌性
產品應該在生活變複雜時繼續運作，而不是因為你三天沒維護就崩潰。
AI 承擔規劃負擔。
你保留判斷力。
一款由 AI 助手處理難點——排程、分類和上下文管理——同時你保持掌控的個人規劃應用。
規劃很難。不是因為記錄任務難，而是因為在截止日期、會議、精力狀態和不斷增長的待辦之間找平衡，需要持續的維護。
AI 可以接管這些維護工作。你的助手可以擷取、重組、安排和修訂——而你保留方向和最終決策。
Lorvex 讓這一切成為可能。一個開放的 MCP 伺服器給你的助手真正的工具，一個原生應用給你一個平靜的地方來查看結果。
你可以完全不用 AI，把它當作獨立的規劃器。也可以接入助手，讓它幫你扛起這個擔子。兩種模式都是一等公民。
規劃才是難點。
問題
難的不是存任務。難的是在截止日期、會議、精力、相依性和積壓之間找到一個可行的安排。
應用依然重要。
介面
AI 可以管理系統，但人依然需要一個原生的、清晰的、好看的地方來瀏覽、編輯和保持方向感。
當 AI 來幫你規劃，什麼會改變
大多數效率應用都假設你是排程器、分類引擎和維護工人。這就是為什麼一忙起來，系統就開始失效。
在 Lorvex 中，你的 AI 助手可以替你擷取、重組、安排和修訂任務。你保持在決策者的位置上：設定方向、協商約束、決定取捨。
對話成為操作入口。助手把你的意圖轉化為真實操作——建立任務、調整行程、推遲過載的日子——讓系統始終保持連貫。
結果是：你打開應用是為了看計畫，而不是從頭建計畫。
你："安排今天的計畫。10-11 和 15-16 有會。週五截止。"
助手：
行程
09:00-09:45 起草主題演講開場（45 分鐘）
11:15-11:25 回覆場地方（10 分鐘）
13:30-15:00 受保護的專注時段（90 分鐘）
16:15-16:45 將設計審查移至明天
你："今天狀態不好。只保留兩項。"
助手：
已更新：保留了和截止日期相關的關鍵工作，其餘已推遲。
規劃才是難點
規劃不是從清單裡挑幾項。而是在跨專案的截止日期、行事曆衝突、精力狀態、相依性和你一直默默迴避的工作之間找平衡。
這正是 AI 改變體驗的地方。Lorvex 不再要求你持續維護系統，而是讓你的助手承擔更多的規劃工作。
有了完整的上下文——你的任務、行事曆、習慣和歷史——助手可以解釋為什麼把工作提前了，為什麼某天安排過滿，或者為什麼一個任務反覆被推遲。
範例
1) "週三安排過滿。我把兩個任務移到了週一，你下午還有空閒。"
2) "你明天只有大約 90 分鐘可用。要把主題演講工作安排在那裡嗎？"
3) "你已經推遲這項任務六次了。歸檔它，還是搞清楚卡在哪了？"
開放工作流，真實操作
Lorvex 開放了 100+ 個 MCP 工具，讓你的 AI 助手能做真正的操作——不只是產生關於你任務的文字，而是真的去建立、更新、安排和組織它們。
這在你整個 AI 工作流中都很重要。你的助手可以在同一個對話中同時使用 Lorvex 和其他工具——讀完郵件後建任務、會議前安排準備時間、需要休息時一鍵推遲所有事。
Lorvex 使用 Model Context Protocol (MCP) 實現這種互通性。任何相容 MCP 的助手——Claude、帶外掛的 OpenAI Codex、或自訂 Agent——都可以連接。
為什麼原生應用依然重要
AI 原生不意味著介面可以將就。人依然需要一個讀起來快、用起來舒服、改起來直接的地方。
對話是表達意圖最快的方式。應用是消化結果最快的方式。兩個介面都重要，都應該被認真對待。
Lorvex 是用 Tauri + React 建構的原生桌面應用，因為這是每天都要用的軟體。它應該秒啟、離線可用、像是屬於你電腦的一部分。
持久上下文
大多數助手在工作階段之間會重置。Lorvex 給它們提供持久的狀態——你的專案、行為模式、歷史、習慣和真實約束——讓系統記住什麼是重要的。
隨著時間推移，規劃狀態不再只是一個待辦清單。它變成一份紀錄：你做了什麼、迴避了什麼、什麼反覆拖延、什麼真正適合安排在一天裡。
正是這種連續性，讓 AI 規劃能不斷改善，而不是每次都從零開始。
原則
一個有沒有 AI 都能用的個人規劃器。
應用應該獨立可用。
Lorvex 本身就是一個完整的任務管理器。AI 整合強大但可選——絕不是必須的。
產品的核心是規劃。
Lorvex 存在的意義，是幫你在真實約束下規劃真實的一天，而不是再造一個存放和排列任務的地方。
AI 必須透明可控。
每一個 AI 操作都有紀錄，每一個變更都可以復原，系統永遠不該讓你感覺像個黑箱。
資料屬於你。
預設使用本地 SQLite。支援 iCloud 跨裝置同步。隨時匯出。沒有供應商鎖定。
專案
Lorvex 是開源的。Issue 也是貢獻。
本專案使用 Claude Code 建構，由人來把控設計方向和回饋。
如果你有想法，提一個 GitHub Issue。定義清晰的 Issue 會被當作實作請求：Issue → PR → 程式碼上線，回饋到產出的距離極短。
別再整理了。去做事。
免費且開源。支援 macOS、Windows 和 Linux。