#從「第二大腦」到 AI 工作系統：我如何把 Aino 建在 LifeOS 之上

#LifeOS 先走過了一段很長的路

我不是從這一輪 AI 熱潮才開始做 LifeOS 的。最初，我把自己基於 Obsidian 搭建的個人工作流公開到了 GitHub。到本文寫作時，開源版已經獲得 1,000+ GitHub Stars，累計下載量超過 50,000 次，付費版使用者也超過 1,000 人。2024 年，LifeOS for Obsidian 還獲得了 Obsidian 年度寶石獎「最佳模板」季軍。

對我而言，數字當然不是全部。我更看重的是，越來越多人真的把 LifeOS 用在每天的記錄、任務、專案、日曆和週期復盤裡。LifeOS 能走到今天，靠的正是大家長期的使用、反饋與喜愛。

我把這套方法概括成一句話：「從每天隨手記開始，把任務、專案、日曆和回顧串起來，不再靠腦子硬記。」 在 LifeOS 官網首頁，我先用六項核心特性說明社群版的底座：開箱即用、無壓記錄、快速取回、週期筆記、知識管理和專用外掛。我想解決的從來不是某一個孤立功能，而是怎樣把每天產生的資訊變成以後找得到、接得上、能繼續行動的個人系統。

在這層底座之上，我又用幾組真實介面展示 LifeOS Pro 和 DeepAsk 如何把這套方法變成日常工具：

#日程規劃：把任務真正放進時間裡

我在 LifeOS Pro 中加入了大日曆：可以把任務拖進日曆規劃截止時間，並在月、周、日程、四象限、看板和時間線等檢視之間切換；需要時，還可以把遠端日曆集中到同一處管理。

#高階列表：從散落的 Markdown 中找回行動

檔案、任務和子彈筆記不該因為分散在不同筆記裡就失去聯絡。因此，我為高階列表加入了搜尋、排序、過濾和分頁，讓人可以從主題與狀態出發，快速定位當前要處理的內容。

#主頁檢視：讓輸入、專案、任務和輸出形成閉環

我又把捕獲、專案、任務和表達放進同一個主頁檢視，並加入習慣統計和閃念漫遊。我希望 LifeOS 不只是一套檔案目錄，而是一張每天都能回到其中繼續工作的操作檯。

#DeepAsk AI：讓筆記開始參與思考

在做 Aino 之前，我已經通過 DeepAsk 探索 AI 與筆記上下文的結合：圍繞當前筆記、標籤、檔案和時間範圍對話，讓 AI 不只是回答通用問題，而是讀取與你正在處理的事情相關的材料。

這些特性構成了我做 LifeOS 的第一階段：記錄資訊、建立結構、安排任務、回看進展，並開始讓 AI 參與理解。它們也讓我逐漸看見下一個問題：如果 AI 不再只是一個外掛面板，而要深入整理、執行、復盤乃至生成專用工具，我應該怎樣從底層重新設計產品？

這條路也早於今天的 Aino。2023 年，我在少數派寫過一篇《如何「構建第二大腦」，這是我的 Obsidian 實踐配方》。那篇文章記錄的已經是 LifeOS 當時的實踐：把人的大腦比作 CPU，把第二大腦比作外接儲存，讓大腦專心處理當下，由筆記系統儲存暫時不必記住、以後又需要找回的上下文。

之後，我沿著這套方法持續迭代 LifeOS：用週期筆記管理時間，用主題筆記管理專案、領域和知識，再通過任務、標籤、連結和復盤把兩套系統連線起來。

#為什麼還要做一個獨立的 Aino

正因為我已經把 LifeOS 在 Obsidian 中做得足夠深入，我也逐漸看清了兩條不同的產品路線。我在《Obsidian vs Aino》中解釋過：我會繼續維護和迭代 Obsidian 外掛路線的 LifeOS Pro，同時用 Aino Desktop 探索獨立桌面應用路線。它們不是替代關係，而是兩種 Markdown Workspace 的開啟方式。

我決定獨立開發 Aino，並不是因為 Obsidian 做不到 AI，也不是要把 LifeOS Pro 停掉。當 AI 從「偶爾問一句」變成工作流的一等參與者時，我需要把上下文選擇、模型與 Skill、檔案許可權、diff 稽核、任務和日曆、長期工作現場以及小程式執行環境，組織在同一套可控的互動邊界裡。獨立桌面應用讓我可以從整體上設計這條鏈路，而不只是再增加一個外掛面板。

今天，「把東西存下來」已經不是終點。我還希望系統能理解這些積累，在需要的時候找到相關材料、梳理現狀、提出下一步，甚至在獲得授權後修改筆記、推進任務。

這就是我做 Aino 的出發點：不是在筆記軟體旁邊加一個 AI 聊天框，而是在 LifeOS 已經形成的上下文之上，讓 AI 進入記錄、整理、執行和復盤的完整迴圈。

#為什麼很多「AI 筆記」用久了還是聊天

第一次讓 AI 總結一篇筆記，效果通常很驚豔。但當你繼續問「我這個專案現在進行到哪了」「這週最值得關注的問題是什麼」，答案往往開始變得含糊。

問題不一定在模型，而在上下文。

一個通用聊天視窗不知道：

• 哪些檔案屬於正在推進的專案，哪些只是參考資料；
• 一條記錄發生在今天、上週，還是已經失效的去年；
• 哪些待辦是專案下一步，哪些只是順手記下的想法；
• 週記、專案索引和日記之間有什麼關係；
• 修改筆記時應該寫到哪個區塊、使用什麼模板、遵循什麼命名規則。

把整個知識庫一次性塞給模型，並不能真正解決問題。上下文越多，噪聲也越多；更重要的是，AI 仍然不知道這套系統如何運轉。

我越來越確信：AI 需要的不只是更多文本，而是一套有座標、有邊界、有規則的長期上下文。 這正是 LifeOS 已經在做的事。

#我用 LifeOS 為 AI 準備了什麼

我在 LifeOS 中始終圍繞兩套系統工作。

第一套是週期筆記。日記、週記、月記、季記和年記把生活與工作的變化放到時間軸上。AI 想知道「最近發生了什麼」，可以沿著明確的日期範圍讀取，而不必在所有檔案裡猜測。

第二套是主題筆記。專案、領域、資源和存檔給每件事一個主題座標。AI 想推進某個專案，可以從專案索引、相關任務和近期記錄開始，而不是把整個知識庫當作一團無差別的文本。

兩者之間再通過標籤、連結、任務和模板連線起來。於是，筆記不再只是文件，而是帶有時間、主題、狀態和操作約定的資料。

這層基礎非常重要。沒有 LifeOS，AI 得先花大量時間理解「你的筆記怎麼放」；有了 LifeOS，它才有機會進一步理解「你正在做什麼」。

#在 Aino 裡，AI 如何進入工作流

我在 Aino 中把這套能力組織為 AI 問答、AI 總結、AI 復盤、AI 整理、AI 小程式和 AI 智慧執行。它們看起來是六項功能，實際對應的是同一條工作鏈：先理解上下文，再壓縮資訊、整理材料、回看結果，最後生成專用工具或執行行動。

#1. 上下文不是自動全選，而是隨任務進入

我為 Aino 右側欄設計了幾種明確的上下文入口：用 # 選擇標籤、用 / 選擇檔案、用 @ 選擇時間範圍、用 $ 載入 Skill、用 ! 使用提示詞。當前筆記、當前網頁和手動附加的材料也可以成為本輪上下文。

這是一種有意的設計：AI 不需要永遠看見整個知識庫，而應該在完成某個任務時拿到恰當的材料。

例如：

• 「用 @ 選擇最近 7 天，幫我整理已經完成、延期和可能被阻塞的事項」；
• 「結合 /產品改版.md 和 #使用者反饋，給出下週最值得驗證的三個假設」；
• 「讀取當前網頁和專案筆記，把值得保留的觀點整理成一段帶來源的研究記錄」。

上下文從 LifeOS 的時間軸和主題網路中被選出來，問題才真正和你的工作發生關係。

#2. AI 總結不是終點，而是下一步的入口

總結是 AI 最常見的能力，但在 Aino 裡，它不只針對當前開啟的一篇文章。你可以讓 AI 總結一篇長文、一組專案資料、剛剪藏的網頁，或某個時間範圍內的週期記錄，再從結果中提取關鍵觀點、決定和下一步。

結果可以繼續追問、複製，或直接匯出為 Markdown。需要進入知識庫時，你可以再把它寫入主題筆記、專案索引，或交給編輯模式生成可稽核的任務與修改。

這也區分了「總結」和「復盤」：總結回答的是「這些材料說了什麼」，復盤還要結合目標、行動與結果，回答「發生了什麼、為什麼，以及下一輪怎麼調整」。

#3. 從問答到編輯，再到智慧體執行

我把 AI 分成三個逐步增加能力的模式：

• 問答只讀，用來總結、解釋、比較和分析；
• 編輯針對當前或相關筆記提出修改，應用前必須確認；
• 智慧體可以跨檔案搜尋、建立和更新內容，也能呼叫 MCP 工具或本機 Agent 完成多步驟任務。

這三個模式並不是為了堆功能，而是在表達不同的信任級別。你可以先讓 AI 看懂，再讓它提出修改，最後才把一整段工作委託出去。

#4. AI 工作臺把一次對話變成持續現場

聊天的天然問題是上下文會隨著會話結束而散掉。一個真實專案卻可能持續幾週甚至幾個月。

AI 工作臺會圍繞專案、任務、主題或輸出建立一個「工作現場」。專案索引、關鍵任務、長期參考和主要輸出可以作為現場材料跨會話保留；右側欄附加的檔案、日期和網頁則只服務當前一輪。

當你把「AI 整理」「生成下一步」「檢查阻塞」或「生成輸出」交給 AI 時，它會先讀現場，再按需探索其它材料。執行結束後，工作臺還會告訴你它實際讀取了什麼、更新了哪些檔案、是否發現了現場之外的新材料。

目前 AI 工作臺仍是實驗功能，但它代表了我對 AI 筆記更重要的判斷：AI 不應該只記住聊天記錄，它應該回到工作物件本身。

#5. Skill 讓 AI 學會 LifeOS，而不只是讀到 LifeOS

只有檔案訪問還不夠。一個 Agent 即使能看到整個 Vault，也未必知道週期筆記路徑、主題模板、任務語法和復盤區塊。

我把這些方法寫進 LifeOS Skill，變成 AI 可以執行的規則。Aino 會讀取當前 Vault 的真實設定，讓 AI 知道你的 PARA 資料夾叫什麼、日記放在哪裡、模板如何渲染、寫入前需要檢查什麼。

於是你可以直接說：

記到今天的日記：14:30 和產品開了需求評審。

建立一個“新版網站上線”專案，使用當前專案模板，
再把今天討論的三個下一步寫進專案索引。

先盤點這個舊資料資料夾，給出第一批分類建議，
不要移動檔案，等我確認。

Skill 的意義不是提供一組漂亮的提示詞，而是讓方法論成為穩定、可複用、可檢查的操作協議。同一套 LifeOS 規則也可以被 Aino 右側欄、Claude Code 或 Codex 使用。

#6. 整理與復盤不再是兩個孤立按鈕

我在 LifeOS 中一直強調「先捕獲，再整理」和週期復盤。到了 Aino，我把 AI 放進了這兩個原有節點。

AI 整理會先從捕獲區、主題筆記或週期記錄中篩出候選項，再把明確的範圍交給智慧體。AI 可以提出摘要、標籤、合併或移動建議；後續變更是進入編輯器 diff，還是由 Agent 按許可權執行，取決於當前的 Edit / Agent 模式和授權設定。

AI 復盤則從當前週期出發，先給出到期與實際完成任務、活躍筆記、週期筆記、推斷專案和習慣等有界證據，再由 Agent 分析進展與可能的阻塞。你可以繼續討論和更新報告；報告確認後，再要求 Agent 寫回復盤筆記或建立下一週期任務，所有寫入都先展示變更預覽。

這時 AI 不是額外製造一份總結，而是在 LifeOS 原本就存在的整理和復盤節奏中工作。今天的記錄進入專案，本週的變化進入週記，本月反覆出現的問題又成為下一輪計劃的依據。

#7. AI 小程式讓 Markdown 長出自己的介面

LifeOS 已經把很多內容變成了帶有標籤、Frontmatter、區塊和關係的 Markdown，但每個人最終想看的介面並不一樣：有人需要客戶跟進臺，有人需要專案駕駛艙，也有人只想看自己的閱讀、習慣或內容釋出進度。

我在 Aino 中加入了 AI 小程式：你可以直接描述需求，AI 會先確認用途、資料來源、記錄格式和讀寫方式，再生成 HTML、CSS、JavaScript 與 Markdown 資料契約。Aino 會展示示例筆記，等你確認後才儲存原始碼和示例資料；生成的原始碼還要經過宿主校驗，並在隔離沙箱中執行。

例如，你可以說：

為“個人品牌”專案做一個內容釋出臺：
讀取帶 #內容選題 標籤的 Markdown，按想法、寫作中、待發布和已釋出分組；
卡片裡顯示平臺、計劃日期和關聯文章，並允許更新狀態。

AI 負責生成介面，業務資料仍然是普通 Markdown。小程式只能通過 Aino 提供的 Host SDK 按已確認的資料契約讀寫，不能任意訪問網路。以後即使不用這個介面，原始筆記依然可以直接開啟、搜尋和遷移。

AI 小程式目前也是實驗功能。它把 AI 和 LifeOS 的結合再向前推了一步：不只是讓模型讀寫現有筆記，而是讓每套個人工作流都能按需獲得一個專用介面。

#8. 最後的控制權必須留在人手裡

當 AI 開始真正操作筆記，「它能不能改」不是唯一問題，「我能不能看懂它改了什麼」更重要。

在編輯模式，以及 AI 整理、AI 復盤等開啟預覽確認的工作流中，Aino 會把新增、刪除與改寫顯示成編輯器 diff。你可以按檔案或按片段接受、拒絕。普通智慧體或本機 CLI Agent 是否直接寫入，取決於當前模式和你授予的許可權；寫入、刪除與 MCP 工具也分別受許可權邊界約束，並保留稽核或撤銷入口。

我希望 AI 帶來的不是一種「交出去就別管了」的自動化，而是更低成本的人機協作：AI 負責搜尋、歸納和執行，人負責目標、判斷與最終確認。

#一個完整例子：讓 AI 推進「新版網站上線」

假設我正在推進一個持續四周的網站改版。

平時，會議結論、使用者反饋和零散想法先進入日記；明確的行動寫成任務，並用專案標籤和「新版網站上線」連線。網頁資料通過 Aino Web Clipper 進入本地 Markdown，重要參考再加入專案現場。

週中，我開啟這個專案的 AI 工作臺，讓 AI 做三件事：

1. 根據專案索引、最近日記和任務，說明當前進度；
2. 找出沒有負責人、沒有下一步或長期未更新的事項；
3. 給出接下來三天最值得推進的動作。

如果結論合理，我切到編輯模式，讓 AI 更新專案索引。Aino 展示 diff，我逐塊接受。需要查詢外部資料時，智慧體可以通過 MCP 呼叫我明確啟用的工具；需要複雜的跨檔案工作時，也可以交給本機 Claude Code 或 Codex。

週末進入 AI 復盤。Aino 沿著本週時間範圍整理到期與實際完成任務、活躍筆記、專案和習慣等證據，再由 Agent 分析延期、可能的阻塞和新發現。我補上只有自己知道的判斷：為什麼延期、什麼決定是錯的、下週真正要捨棄什麼。確認報告後，我再要求 Agent 把復盤寫回週記，並把新行動加入專案和任務系統；寫入前先稽核變更預覽。

於是形成一個閉環：

日常捕獲 → LifeOS 建立時間與主題關係 → AI 整理和分析
        → 人做判斷 → AI 執行或提交可審查修改 → 週期復盤 → 進入下一輪

這個流程裡，模型可以替換，工具可以增加，但專案、記錄、判斷和結果始終留在自己的 LifeOS 中。

#本地優先，是 AI 時代更重要的底座

我始終堅持本地優先：Aino 把筆記儲存為你選擇目錄裡的本地 Markdown，可以直接開啟 Obsidian Vault，也不要求把整個知識庫遷入某個專有云端格式。

桌面端 AI 由你配置自己的模型 API、相容端點、Ollama，或本機 Claude Code / Codex。我沒有讓 Aino 預設把整個 Vault 一次性上傳給模型；每次請求只會把介面中啟用或可見的當前筆記、網頁、手動選擇的材料和會話歷史，以及執行任務所需的系統指令與 Skills，按照所選服務的方式交給對應模型或工具。在 Agent 模式中，你授權的檔案工具、MCP 或本機 CLI Agent 還可能按任務需要讀取其它檔案，並把必要的工具結果傳送給所選模型或服務；工作現場是優先上下文，不是安全沙箱。Aino 預設不提供託管的桌面端 AI 推理。

本地優先並不意味著完全拒絕網路，而是讓資料位置、模型選擇和授權邊界保持清楚。即使未來更換模型、停止使用 Aino，Markdown 檔案、目錄結構和 LifeOS 工作流仍然屬於你。

#Aino 不是要替代 Obsidian

我最初在 Obsidian 上實現 LifeOS，也仍然喜歡它的外掛生態和高度可定製性。Aino 與 Obsidian 可以開啟同一個 Vault：

• 想使用豐富的社群外掛和自由組合，繼續在 Obsidian 中工作；
• 想讓 AI 帶著 LifeOS 規則理解和推進當前工作，就開啟 Aino；
• 檔案仍然是同一批 Markdown，不需要在兩個封閉系統之間匯入匯出。

在我看來，Aino 更像是 LifeOS 面向 AI 時代的一種新介面。它沒有丟掉原來的時間系統、主題系統和本地檔案，反而把這些積累變成 AI 真正可以使用的長期上下文。

#如何開始

如果你已經有 LifeOS 或 Obsidian Vault，可以直接用 Aino 開啟；如果沒有，也可以從 Memos、IPO、GTD、PARA 或 OPC 示例庫開始。

我的建議是循序漸進：

1. 先用日記和一個真實專案記錄一週，讓系統擁有真實上下文；
2. 在 設定 → AI 配置模型、相容端點或本機 CLI Agent；
3. 在右側欄安裝 LifeOS Skill，先用問答模式總結和查詢；
4. 確認 AI 理解你的結構後，再嘗試編輯模式和 diff；
5. 最後才把多步驟工作交給智慧體、AI 工作臺或 MCP 工具。

不要一開始就追求「讓 AI 自動管理一切」。先讓筆記系統真實反映你的工作，再逐步把重複、機械、可檢查的部分交給 AI。

#寫在最後

三年前，我把第二大腦理解成第一大腦和現實世界之間的一層快取。它替我儲存上下文，讓我可以專注當下。

現在，這層快取開始擁有理解和行動能力。但我並不希望它取代第一大腦。真正重要的變化是：當我需要回到一個專案、一次復盤或一段長期生活時，AI 不再面對一片空白，也不必靠我重新講述一切。

LifeOS 讓經歷成為有結構的長期上下文，Aino 讓 AI 在這份上下文中工作。

第二大腦負責不遺忘，AI 工作系統負責把記憶重新變成行動。