最近開發者自薦了 3 個好用的 App

編注：本期內容為少數派 Matrix 社區應用自薦文章合集。文章代表作者個人觀點，作者與文中產品有直接的利益相關（開發者、自家產品等），少數派僅對標題和排版略作修改。

本期目錄

SynoSync：讓你的 Obsidian 文檔庫，在所有設備間無縫同步

優派簡歷：打造一個足夠干凈、純粹的工作臺

屏憶（ScreenMemo）：本地運行的智能截屏備忘與檢索工具

SynoSync

? 千里之豪 | iOS | 下載地址

一張圖看懂整篇文章

▍開發背景：關于安全感與掌控感

一直以來，基于 Markdown 純文本的 Obsidian 文檔庫給了我極強的安全感與掌控感。

在我的工作流中，NAS 承擔著文檔庫托管與同步的核心角色。群暉 Drive 在 Windows、Mac、Linux 乃至 Android 平臺上的體驗都堪稱出色，唯獨在 iOS 端，這種連貫性戛然而止。

▍困境：iOS 上的群暉 Drive，為何不夠「現代化」？

在 iOS 生態下，群暉 Drive 的同步范圍被嚴格限制在自身的沙盒文件夾內（應該是考慮到舊版本 iOS 兼容性）。這意味著 Obsidian 無法直接調用 Drive 的同步能力來讀取文檔庫。對于追求「全平臺一致體驗」的開發者來說，這成了最難受的斷層。

群暉在 iOS 平臺的 Drive 應用不支持新版本的路徑自定義

▍Obsidian 的多平臺同步方案現狀

如果你想自建 Obsidian 文檔庫同步，目前主流方案的優劣對比清晰可見：

如果你和我一樣，希望文檔庫具備更安全的托管方式，Remotely Save + WebDAV依然是目前的權宜之計。但要獲得穩定的體驗，通常還需折騰HTTPS、內網穿透、DDNS 或 Cloudflare。

▍我的「萬級」文件同步噩夢

我的 Obsidian 文檔庫包含26,000+ 個文件，總體積接近10GB。

我的 Obsidian 文檔庫

在這種規模下，單純依賴 Obsidian 的前臺插件同步，體驗會呈斷崖式下降。更棘手的是，常規插件方案很難像群暉官方 App 那樣，根據網絡環境（局域網 vs 公網）自動且智能地切換連接地址。

▍那么……

難道就沒有一種方案，能讓我們直接復用 QuickConnect 那種「開箱即用」的穿透能力與內外網自動切換邏輯，在免去繁瑣穿透配置的同時，實現真正的文檔庫自動同步到任何地方？

為了解決這些切膚之痛，我開發了SynoSync。它的目標非常明確：

徹底解決「群暉 + iOS」用戶的文檔庫同步難題。

▍SynoSync 能為你做什么？ 1. 多賬號與多任務的靈活管理

支持配置多臺 DSM：完美適配擁有多套群暉環境的進階用戶。

支持多同步任務并行：你可以針對不同的 App、不同的本地路徑，創建多條上傳、下載或雙向同步任務，靈活構建你的同步方案。

2. 覆蓋全場景的同步模式

三種同步場景：App 內、長時間高效同步、后臺同步

前臺同步：實時可見的極速同步。

大批量初始化：針對首次同步或超大文件夾優化的傳輸模式。

后臺靜默同步：無需干預，在系統允許的范圍內自動對齊差異。

快捷指令觸發：聯動 iOS 自動化，解鎖更多高效玩法。

3. 直觀的狀態追蹤

小組件刷新機制下信息更新較慢，你如果真的關心實時進度，還是打開 App 比較好

同步活動報告：每一個文件的流轉都清晰可查。

小組件支持：無需打開 App，在桌面即可實時觀察同步進度。

▍一些坦誠的局限性……

在開發 SynoSync 的這一個多月里，最讓我抓狂的莫過于 iOS 嚴苛的后臺機制。

眾所周知，iOS 采用了近乎「墓碑式」的后臺管理。對于 SynoSync 這種需要頻繁進行網絡請求、文件比對及高強度讀寫的 App 來說，后臺環境極其不友好。為了實現優雅的「靜默同步」，我嘗試了各種姿勢去突破限制，但必須承認：它的后臺效果依然無法達到 Android 或 PC 端的隨心所欲。

特別是在面對我那 2.6 萬個文件的「巨型庫」時，iOS 的后臺限制會導致同步耗時拉長。

因此，SynoSync 提供的最終解法是：

先通過「前臺大批量同步」完成沉重的初始化任務（批量上傳｜下載），后續的日常增量更新，則交給「后臺比對」去靜默完成。

如果你發現 SynoSync 發出了后臺同步失敗的通知，也不用驚慌，這只是 iOS 后臺切斷了 App 的后臺網絡權限（為了省電），SynoSync 會在下一個 iOS 允許的時間窗口重新嘗試同步的。

：https://apps.apple.com/cn/app/synosync/id6762731663

優派簡歷

? Tox | web 端 | 在線網址

每年到了求職季或需要更新履歷的時候，很多人的數字生活都會陷入一種隱秘的焦慮中。

面對市面上琳瑯滿目的在線簡歷生成器，你花了幾個小時在網頁上小心翼翼地填滿了自己的教育背景、工作經歷、項目細節，然而，當你排版完畢，滿心歡喜地點擊導出的那一刻，往往只會迎來一個令人崩潰的結局：屏幕上赫然彈出一個“請掃碼支付 9.9 元解鎖 PDF 下載”的二維碼。

被 “綁架” 付費還只是表面的痛點。更讓人后背發涼的是，就在你毫無防備地填寫這些信息時，你的核心個人隱私和職業履歷，早就悄無聲息地變成了平臺數據庫里的大數據養料，隨時準備被打包、分析，甚至出售給第三方機構。

作為一名對數據主權有著極度潔癖的開發者，我實在無法忍受這種將核心隱私拱手讓人的體驗。一份記錄了我職業生涯全部心血的文檔，它的最終歸宿應該在我的本地硬盤里，而不是某個不知名公司的云端數據庫中。

為了解決這個痛點，我決定為自己，也為所有在意數字隱私的人，打造一個足夠干凈、純粹的工作臺。這就是優派簡歷（OpResume）。

▍真正的 Local-First：不妥協的數據主權

初次打開優派簡歷，你可能會覺得它 “少” 了點什么 ——它沒有注冊按鈕，也沒有登錄彈窗。

在這個萬物皆需云同步的時代，優派簡歷選擇了一條最老派卻最讓人安心的道路：100% 純本地運行（Local-First）。

打開網頁的瞬間，你的瀏覽器就是所有的后端。你在頁面上敲下的每一個字，都只保存在當前設備的 LocalStorage 中。系統根本不存在用于存儲用戶簡歷的云端服務器，自然也就從根本上杜絕了隱私泄露的可能性。

這不僅僅是一個技術選型，更是一種數字生活態度：我的履歷，只屬于我自己。

那么，數據全在本地，換了電腦怎么辦？

不用擔心被平臺綁架。在數據結構上，優派簡歷嚴格遵循了通用的JSON Resume開源標準。你隨時可以把整份簡歷一鍵導出一份不到幾十 KB 的 .json 文件備份到你的云盤。換了新設備，只需將這個文件拖拽導入，一切工作流即可無縫接力。

▍BYOK 模式：當 AI 遇上絕對隱私

不可否認，AI 已經是當下效率工具的標配。在寫簡歷時，“如何用 STAR 法則提煉項目亮點” 或者 “如何潤色這段工作經歷”，是最讓人頭疼的環節。

但我面臨一個巨大的邏輯沖突：既然承諾了沒有后端，不碰用戶數據，那我要怎么幫你調用大語言模型？如果我偷偷把你的經歷傳給云端 API，這無異于一種背叛。

最終，我選擇將選擇權完全交還給你 ——BYOK（Bring Your Own Key）模式。

優派簡歷本身提供純粹的客戶端環境，如果你需要 AI 輔助，可以在設置中填入你自己申請的 API Key（目前我們已接入了「硅基流動 SiliconFlow」）。

只有當你主動劃選一段苦思冥想的文本，并點擊 “AI 潤色” 時，這段特定的文字才會通過你自己的 Key 臨時發送給大模型進行處理。

這是一種奇妙的體驗：AI 依然在為你打工，但監工是你自己，而不是某個 SaaS 平臺。這種透明的機制，讓我在處理敏感工作經歷時感到前所未有的踏實。

▍拒絕折騰：所見即所得的極客美學

很多極客向的簡歷工具（比如基于 LaTeX 或 Markdown 的方案），雖然保障了隱私，但往往需要使用者與繁瑣的語法和反人類的排版引擎作斗爭。

我認為，寫簡歷本該是一件順滑、純粹甚至有些享受的事情。在優派簡歷的交互設計上，我盡可能保留了現代化 Web 應用的輕盈感：

積木式拖拽排版：哪里不對拖哪里，直觀且符合直覺，讓你把全部精力集中在內容的打磨上。

一鍵開啟的隱私模式：考慮到有時需要截圖請教別人或在社區求職，應用內可以直接開啟隱私模式，瞬間屏蔽掉姓名、電話、郵箱等敏感信息。

原生打印引擎，拒絕 “糊弄”：很多平臺為了防抓取，導出的 PDF 其實是由 Canvas 繪制的圖片，不僅放大后文字邊緣模糊，甚至無法被大廠的 ATS（招聘追蹤系統）正確識別。優派簡歷直接調用瀏覽器原生的 Print 引擎，生成的 PDF 矢量清晰，文字可精準復制。

▍寫在最后

優派簡歷從最初的想法，到現在 v1.3.0 版本的迭代，始終圍繞著 “隱私” 與 “掌控感” 這兩個關鍵詞。它可能沒有那些商業 SaaS 平臺花哨的主題模板庫，但它為你提供了一個絕對安全、不用擔心被偷窺的角落，讓你能夠靜下心來，認真審視自己過去幾年的職業軌跡。

在這個 “隱私極其廉價” 的時代，如果你也苦于信息泄露，或者厭倦了那些層出不窮的付費套路，不妨來試試這個為你準備的專屬工作臺。

完全開源，純粹免費。

在線體驗（點開即用，無需登錄）：在線使用

GitHub：倉庫地址（如果你覺得這個項目不錯，歡迎給個 Star 支持一下）

如果你在使用過程中遇到任何問題，或者對接入更多 AI 生態有好的想法，歡迎在評論區與我交流。希望優派簡歷能幫你拿下心儀的 Offer。

屏憶（ScreenMemo）

? 少數派71601116 | Android | GitHub 下載

我經常遇到一種很具體的遺忘：明明知道自己之前在手機上看到過某個東西，卻完全想不起它來自哪個 App、出現在哪一天、存在于哪個頁面。更麻煩的是我通常沒有截圖來幫我回憶，那些內容只是當時恰好看到，沒有收藏、沒有轉發、也沒有寫進筆記。

后來想找，連一個可以回去的入口都沒有。

一開始我只是覺得煩，后來我慢慢意識到，這件事可能比「找不到截圖」更大一點：如果將來每個人都能擁有自己的 AI 助手，它能不能理解你不只取決于模型有多強，也取決于你給它留下過多少真實的上下文。今天沒有留下來的東西，明天很難補上。

所以我開始做屏憶（ScreenMemo），一個開源的本地屏幕記憶工具：自動記錄屏幕內容，然后通過 OCR、搜索、時間線、每日總結和 AI 回顧，把那些原本滑走、然后遺忘的內容，變成可以找回的線索。

屏憶會按應用組織已經記錄下來的屏幕內容。對我來說，先有一個能回到過去畫面的入口，比一開始就追求復雜整理更重要。

屏憶的基礎工作流程并不神秘：通過無障礙服務定時截屏，然后把截圖保存在本地，同時記錄當前應用、時間和路徑；對截圖做 OCR 并建立本地索引后，在 App 里提供搜索、圖庫、收藏、時間線、動態總結、每日總結和 AI 回顧。

它最直接的場景，是找回那些你覺得「我明明看過」、但記憶相對模糊的內容。

比如昨天在信息流里刷到過一個有用的方法，隔天想再看時卻發現沒有收藏，想不起作者、也想不起標題。放在過去，我大概會翻瀏覽記錄、重新搜關鍵詞，或者干脆等它哪天再次被推薦。

屏憶的做法更粗暴一點：如果當時屏幕被記錄下來，OCR 文本進入了本地索引，之后就可以搜索那幾個模糊的關鍵詞，再回到對應截圖確認。

第二種情況是找回一段過程。

有些操作不是一張截圖能說明白的。注冊、登錄、授權、付款、查詢、客服溝通，都可能跨過好幾個頁面。單張截圖只能告訴你某一刻屏幕上有什么，時間線能把前后關系補回來。屏憶支持按時間回看，也可以生成回放，用來還原一次操作路徑。

單張截圖解決「那一刻有什么」，時間線和回放更接近「當時我是怎么走到這里的」。

還有每天的回顧。

如果你一直在手機上查資料、溝通、處理事情，屏幕內容本身也會留下了不少線索。每日總結不是日記，只是先把一天里零散的記錄整理成一份能讀的摘要。它不一定深刻，但至少能回答一個樸素的問題：今天我大概看過什么、處理過什么。

AI 回顧也是類似思路。

普通 AI 助手并不知道你昨天在手機上看過什么。屏憶在你配置 AI 提供商后，可以基于截圖、動態總結、上下文片段和你明確選擇的證據圖片做回顧。你可以問它「下午那段流程大概在做什么」，也可以讓它幫你從一組截圖里整理出重點。這里的 AI 不是憑空聊天，它只會將你已經留下的屏幕線索作為上下文。

最后，屏憶也支持收藏和備注。自動記錄負責兜底，但有些內容還是要人來標一下，看到值得留下的截圖，你可以加一句自己的說明。這個功能小但必要，自動記錄再多也替代不了人的判斷。

如果要找一個參照物，屏憶和一些桌面端自動記錄屏幕的工具有點像。比如我經常想到 Rewind，它早期的方向和屏憶很接近，記錄 Mac 上看過、聽過的內容，再用 OCR 和語音識別做搜索。這個想法很誘人，也確實說明桌面端早就有人在嘗試「屏幕記憶」。只是后來的故事有點復雜：Rewind 在 2024 年轉向 Limitless，開始做會議記錄和錄音吊墜；2025 年被 Meta 收購后，Limitless 官方說明寫明 Rewind 應用會逐漸停止運營，最新版從 2025 年 12 月 19 日起已經禁用了屏幕和音頻捕獲。

Rewind 早期主打「記錄你在 Mac 上做過的一切」，這和屏幕記憶的方向很接近。

Rewind 的事不是一句「產品失敗」就能概括的，商業產品會轉向、會被收購、會砍掉特定功能，開發團隊有自己的選擇。但對個人記憶庫來說，這些「意外」的影響會變得十分具體，它們的理想狀態是長期記錄，但這些產品本身未必長期存在。

后續微軟的 Recall 則補上了另一層提醒：它同樣想把電腦上出現過的內容做成可搜索的時間線；2024 年遇到隱私和安全方面的質疑后，微軟在官方博客里說，Recall 會先進入 Windows Insider 計劃，而不是直接隨 Copilot+ PC 面向用戶提供預覽。大公司也繞不開這個問題：只要工具會持續記錄屏幕，信任就會跑到功能前面。

這張圖提醒我：個人記憶工具如果完全依賴閉源產品，生命周期本身就是風險。

在手機上幾乎沒找到同類工具的前提下，偏偏很多最零碎、最容易丟的上下文又都發生在手機上：聊天、搜索、信息流、支付、設置、臨時打開的網頁。這便是屏憶開發的初心。你的屏幕里可能有聊天、訂單、賬號、位置、支付流程、工作資料和臨時驗證碼，有了 Rewind、Recall 等功能的「前車之鑒」，屏憶在設計理念上強調本地保存和開源，截圖、OCR、索引和大多數配置默認留在本地；代碼、實現方式和隱私邊界你也能直接在 GitHub 倉庫里看到。本地優先也意味著用戶必須能把數據帶走，屏憶支持導出 ZIP 備份，導入時提供覆蓋導入和合并導入。

Recall 的官方說明里也把「快照」「本地保存」「權限控制」放在很前面。只要工具會記錄屏幕，信任問題就不會是附屬問題。

屏憶還提供隱私模式、敏感內容分析和 NSFW 相關能力。這不是獵奇功能，而是長期記錄屏幕以后必須面對的問題。一個記憶工具不能只會保存，也要能遮擋、限制和刪除。

存儲方面，自動截圖的數據是長期增長的，按壓縮后約 50 KB 一張、每分鐘一張粗算，30 天大約是 43200 張截圖，約 2.1 GB。這個數字不算夸張但會持續增長，所以屏憶不能只負責保存。它還要提供目標大小壓縮、歷史壓縮、過期清理、存儲分析和按應用策略。你可以只記錄真正需要的 App，也可以定期清理不再需要的截圖。

屏憶的設置頁自上線以來變得越來越長，一開始我也有點猶豫：設置太多會不會顯得復雜？但做了一段時間后，我覺得這些開關不能省。

因為屏憶記錄的是屏幕，很多選擇不應該由工具替用戶決定：哪些 App 要進入記憶庫、哪些內容需要自動遮擋、AI 請求發給哪個模型、提示詞怎么寫、請求日志要不要保留…… 甚至要不要把本地記憶通過 MCP 暴露給同一局域網里的 AI 客戶端，這些都應該是明確的選擇，而不應該藏在默認行為里。

所以屏憶把 AI 能力被做成了可選項。只有在你啟用 AI 并配置提供商后，相關總結或對話請求才會發往你配置的模型服務。這會增加配置門檻，但我更愿意把選擇權留給用戶，你可以配置 OpenAI、Claude、Gemini 或兼容接口的服務，也可以調整 Prompt，查看請求日志和工具調用報告。這樣做不如「打開即用」順滑，但出了問題時，你至少知道一次總結用了哪些圖片、發給了哪個模型、返回了什么結果；MCP 服務也是同樣的思路，它可以讓桌面端 AI 客戶端讀取手機里的摘要、搜索結果和少量證據圖片，但需要手動開啟，只在局域網內工作，并且帶 token。

做屏憶之后，我越來越覺得「記住」不是一個單點功能。只做自動截圖，會變成圖片堆；只做 AI 總結，會缺少證據；只強調本地保存，又必須面對備份和遷移；只強調找回，也要承認有些內容應該被清理。

屏憶現在做的這些功能，本質上都在圍繞同一件事：讓屏幕上發生過的事，在未來還能有線索可循。

所以它也不會只停在手機端。目前我正在做桌面端，一方面是為了處理更大的備份、合并和遷移任務，另一方面也是希望把手機里留下的記錄帶到更適合整理、檢索和寫作的環境里。手機負責捕獲那些稍縱即逝的畫面，桌面負責承接更長時間尺度上的整理和回看。

更遠一點，我希望屏憶能逐步適配更多平臺。不是為了把所有設備都塞進同一個 App，而是讓記錄、搜索、回顧、備份和遷移之間形成一條更完整的鏈路。你在不同設備上看到過的內容，不應該因為換了設備、換了系統、換了應用入口，就徹底斷掉。

屏憶現在才剛剛起步。它還需要更好的兼容性、更穩定的后臺、更清晰的隱私控制、更順滑的搜索體驗和更豐富的回顧方式。但從今天開始，把一部分屏幕記憶留在自己手里，我覺得已經是一件值得做的事。

如果未來真的會有更懂我們的個人 AI，它需要的不只是更強的模型，也需要足夠真實、足夠連續、并且仍然由自己掌握的上下文。屏憶想做的，就是先把這些上下文留下來。

：https://github.com/2977094657/ScreenMemo?source

/歡迎投稿/

/產品推薦/