Dayflow：把螢幕活動變成工作日誌的本機優先 Mac 工具
The automatic work journal/time tracker. Privately turns your screen into a timeline of what you actually accomplished. Open-source and local-first.
秒懂
- 它是什麼？
- Dayflow 以螢幕擷取加上可自選的 AI 供應商，把一天的活動整理成時間軸、站立會議摘要與週回顧。它的賣點是資料預設留在本機，代價是你必須交出 macOS 的螢幕錄製權限。
- 適合誰用？
- Dayflow 適合已經在用 Mac、不想手動按計時器、且願意自行決定 AI 後端的人；如果你連螢幕錄製權限都不想給，或需要跨 Windows、Linux 的團隊報表，它就不是合適的工具。採用前先確認三件事：你的 macOS 版本是否達 14 以上、你要用 Ollama 或 LM Studio 這類本機模型還是雲端供應商、以及 ~/Library/Application Support/Dayflow/ 這個資料目錄要保留多久，並在設定裡對應的自動清理選項中把上限調到你磁碟能接受的數字。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 5 天前。
- 用什麼語言寫的？
- 主要是 Swift（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是「哪個視窗開著」與「我到底做了什麼」之間的落差
多數時間追蹤工具記錄的是前景視窗標題。這個資訊在回顧時幾乎沒用：Cursor 開著兩小時，可能是在出貨一個功能，也可能是在查驗證問題、審 PR，或卡在環境設定。Dayflow 的定位就在這個落差上，README 的說法是它試圖理解你在做什麼，而不只是哪個應用程式是作用中的。
目標使用者是每天在 Mac 上工作、需要事後重建當天脈絡的人：要寫站立會議更新、要對客戶交代工時、或只是想知道時間花到哪裡去。它不要求你按開始計時，也不要求你寫筆記，這是它與手動計時器最根本的分歧。
螢幕區塊、AI 分析、活動卡：資料怎麼流動
根據 README 的功能表，Dayflow 的流程是：擷取輕量的螢幕區塊，交給你自己選的 AI 供應商分析，再轉成當天的活動卡。這三步決定了它的性格。第一步是持續的背景擷取，第二步是外部依賴，第三步才是你看到的時間軸。
分析結果往上堆疊成幾個視圖。每日站立會議視圖會從時間軸抽出昨日重點、今日任務與阻礙；週回顧把時間軸聚合成專注模式、分類、應用程式使用與互動圖表；聊天功能讓你用自然語言問關於這份日誌的問題，README 強調回答是根據你的時間軸，而不是翻筆記或截圖。另外有干擾追蹤，會標出分心的時段並與專注工作並列。
這裡有一個容易被忽略的設計後果：摘要品質直接綁在你選的模型上。選本機模型換到隱私，選 Gemini、ChatGPT 或 Claude 換到摘要品質，README 把這件事寫成隱私、成本、速度與摘要品質之間的取捨，而不是宣稱某一種配置全面勝出。這個誠實值得肯定，但也意味著「Dayflow 的摘要有多好」這個問題沒有單一答案。
安裝路徑與那個你必須給的權限
最短路徑是 Homebrew：
brew install --cask dayflow
或者從 GitHub Releases 下載 Dayflow.dmg，開啟後拖進 Applications，然後在系統提示時授予 macOS 的 Screen & System Audio Recording 權限。系統需求是 macOS 14 以上。
想從原始碼建置的話，README 給的是：
git clone https://github.com/JerryZLiu/Dayflow.git cd Dayflow open Dayflow/Dayflow.xcodeproj
接著在 Xcode 選 Dayflow scheme 執行。注意這一步只給出開啟專案的方式，建置與簽章相關的細節在提供的材料裡沒有著墨，實際會遇到什麼取決於你的 Xcode 環境。
AI 供應商是選配但實質必要的一環：本機走 Ollama 或 LM Studio，雲端走 Gemini 自帶 API key，或透過本機 CLI 工具接 ChatGPT 與 Claude。README 直白說明，選雲端供應商時，分析所需的活動資料會送到該供應商；選本機模型則分析留在你的機器上。這句話應該被當成採用決策的核心，而不是附註。
本機優先的邊界在哪裡，以及它不適合誰
Dayflow 宣稱 local-first，錄影、時間軸資料與應用程式資料庫預設都存在 ~/Library/Application Support/Dayflow/。但 local-first 不等於「資料永不離開機器」。一旦你把供應商設成 Gemini、ChatGPT 或 Claude，為了產生摘要而需要的活動資料就會外送。這是整個工具最大的取捨點，也是它與純本機方案的分界線。
第二個限制是平台。這是一個 Swift 寫的 Mac 應用，需求明列 macOS 14 以上，沒有提到其他作業系統的版本。如果你的團隊混用 Windows 與 Linux，Dayflow 只能覆蓋其中一部分人，無法產出一致口徑的團隊報表。
第三個是持續螢幕擷取本身的性質。README 提供自動清理，讓你可以設定儲存上限並自動清除舊錄影，這說明開發者意識到磁碟會被吃滿。但清理是事後補救，擷取期間那些畫面仍然存在本機，任何能讀取你使用者目錄的程序或人都可能接觸到。這不是漏洞，是這類工具的固有代價。
最後，如果你的需求只是「這個月我在哪些專案上花了幾小時」這種可計費工時，Dayflow 的活動卡與 AI 摘要其實是過度設計，而且會引入模型判斷的不確定性。
與手動計時器的差異：自動化換來的是推論，不是精確
最直接的替代方案是 Toggl Track 這類手動計時器。差別不在功能多寡，在資料的來源與性質。手動計時器記錄的是你主動宣告的區間，數字精確、可稽核、可歸因到專案代碼，缺點是你必須記得按下去，而且事後補登的準確度會下滑。
Dayflow 走的是相反的路：不要求你宣告任何事，改由擷取與模型推論來生成活動卡。好處是零摩擦與事後可重建，代價是每一張卡片都是模型的判斷，可能把一段除錯歸成「開發」，也可能把閱讀文件歸成別的類別。對於需要向客戶逐項舉證的計費場景，這種推論性質是弱點；對於「我今天到底忙了什麼」這種自我回顧，它反而比精確的計時器更貼近實情。
選擇的關鍵因此不是哪個工具更強，而是你的產出要被誰檢視、需要多高的可稽核性。
MIT 授權與維護成本：你能拿到什麼、要自己承擔什麼
Dayflow 以 MIT License 釋出，這意味著你可以閱讀、修改、再散布原始碼，包括商業用途，條件是保留著作權與授權聲明。這對想要自行審視資料流向、或想改掉某段擷取行為的人是有意義的，因為應用程式的行為可以攤開來看，不必只憑官網的隱私頁面。
需要留意的是授權涵蓋的是程式碼，不涵蓋你選擇的 AI 供應商。若走 Gemini 或 Claude，你與該供應商之間的條款、計費與資料處理政策與 MIT 無關，Dayflow 的授權不會替你解決那一層。
維護成本方面，材料顯示近期版本節奏密集：v2.2.0 在 2026-09-03，v2.4.0 在 2026-09-07，v2.4.2 在 2026-09-09。這種頻率對使用者是雙面的：功能在動，但你若自行從原始碼建置，就必須跟著 Xcode 專案走，每次升級都要重新確認建置能過。走 Homebrew cask 或 DMG 的人負擔小得多。另外 README 提到較大改動建議先開 issue 對齊範圍，這暗示專案對外部貢獻的節奏仍由維護者掌握。
採用前的檢查順序
先確認你的 Mac 是否為 macOS 14 以上，這是最硬的一道門檻。接著決定 AI 後端，這個選擇同時決定了隱私邊界與摘要品質，不該留到安裝後才想。若選本機，先讓 Ollama 或 LM Studio 跑起來；若選雲端，先把 API key 或 CLI 工具準備好。
安裝後第一件事是去設定裡的自動清理選項，把儲存上限設成你磁碟能長期承受的數字，因為擷取是持續發生的，預設值不見得符合你的機器狀況。再來是確認 ~/Library/Application Support/Dayflow/ 這個目錄你能接受它存在，並且知道怎麼刪。
最後，如果團隊要共用這份日誌，先確認所有人都在 Mac 上。只要有一個人不是，你就需要另一套方法來補齊，Dayflow 本身不處理這個問題。
編輯結論
Dayflow 適合已經在用 Mac、不想手動按計時器、且願意自行決定 AI 後端的人；如果你連螢幕錄製權限都不想給，或需要跨 Windows、Linux 的團隊報表，它就不是合適的工具。採用前先確認三件事：你的 macOS 版本是否達 14 以上、你要用 Ollama 或 LM Studio 這類本機模型還是雲端供應商、以及 ~/Library/Application Support/Dayflow/ 這個資料目錄要保留多久，並在設定裡對應的自動清理選項中把上限調到你磁碟能接受的數字。
社群筆記