Lorvex

下載

AI 承擔規劃負擔。
你保留判斷力。

一款由 AI 助手處理難點——排程、分類和上下文管理——同時你保持掌控的個人規劃應用。

規劃很難。不是因為記錄任務難,而是因為在截止日期、會議、精力狀態和不斷增長的待辦之間找平衡,需要持續的維護。

AI 可以接管這些維護工作。你的助手可以擷取、重組、安排和修訂——而你保留方向和最終決策。

Lorvex 讓這一切成為可能。一個開放的 MCP 伺服器給你的助手真正的工具,一個原生應用給你一個平靜的地方來查看結果。

你可以完全不用 AI,把它當作獨立的規劃器。也可以接入助手,讓它幫你扛起這個擔子。兩種模式都是一等公民。

系統不該一忙就失靈。
韌性

產品應該在生活變複雜時繼續運作,而不是因為你三天沒維護就崩潰。

規劃才是難點。
問題

難的不是存任務。難的是在截止日期、會議、精力、相依性和積壓之間找到一個可行的安排。

應用依然重要。
介面

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 開放了 114 個 MCP 工具,讓你的 AI 助手能做真正的操作——不只是產生關於你任務的文字,而是真的去建立、更新、安排和組織它們。

這在你整個 AI 工作流中都很重要。你的助手可以在同一個對話中同時使用 Lorvex 和其他工具——讀完郵件後建任務、會議前安排準備時間、需要休息時一鍵推遲所有事。

Lorvex 使用 Model Context Protocol (MCP) 實現這種互通性。任何相容 MCP 的助手——Claude、OpenAI Codex、或自訂 Agent——都可以連接。

為什麼原生應用依然重要

AI 原生不意味著介面可以將就。人依然需要一個讀起來快、用起來舒服、改起來直接的地方。

對話是表達意圖最快的方式。應用是消化結果最快的方式。兩個介面都重要,都應該被認真對待。

查看功能

持久上下文

大多數助手在工作階段之間會重置。Lorvex 給它們提供持久的狀態——你的專案、行為模式、歷史、習慣和真實約束——讓系統記住什麼是重要的。

隨著時間推移,規劃狀態不再只是一個待辦清單。它變成一份紀錄:你做了什麼、迴避了什麼、什麼反覆拖延、什麼真正適合安排在一天裡。

正是這種連續性,讓 AI 規劃能不斷改善,而不是每次都從零開始。

原則

一個有沒有 AI 都能用的個人規劃器。

應用應該獨立可用。

Lorvex 本身就是一個完整的任務管理器。AI 整合強大但可選——絕不是必須的。

產品的核心是規劃。

Lorvex 存在的意義,是幫你在真實約束下規劃真實的一天,而不是再造一個存放和排列任務的地方。

AI 必須透明可控。

AI 發起的變更會記錄在活動日誌中,你可以在應用程式裡查看。保留多久由你決定,也可以關閉。

資料屬於你。

預設使用本地 SQLite。支援 iCloud 跨裝置同步。隨時匯出。沒有供應商鎖定。

專案

Lorvex 是開源的。Issue 也是貢獻。

本專案使用 Claude Code 與 OpenAI Codex 建構,由人來把控設計方向和回饋。

如果你有想法,提一個 GitHub Issue。定義清晰的 Issue 會被當作實作請求:Issue → PR → 程式碼上線,回饋到產出的距離極短。

別再整理了。去做事。