我和 AI 一起做了一個自己的密碼管理器
這一個星期, 我和 AI 一起做了一個 macOS 原生的密碼管理器。 這不是一個準備上架 App Store 的產品, 也不是什麼想要挑戰 1Password、Bitwarden、LastPass、KeePassXC 的大型計畫, 就只是一款開發給自己使用的好工具。
我和 AI 一起做了一個自己的密碼管理器

這一個星期, 我和 AI 一起做了一個 macOS 原生的密碼管理器。 這不是一個準備上架 App Store 的產品, 也不是什麼想要挑戰 1Password、Bitwarden、LastPass、KeePassXC 的大型計畫, 就只是一款開發給自己使用的好工具。

我原本使用密碼管理器的是 1Password 6。 這是一個很舊的 1Password 版本, 但因為它是一次買斷、本機資料庫, 加上整體操作習慣我已經用了很多年,
所以即使現在, 每次重灌電腦或換新 Mac, 我還是會把它裝回來。
但這次換新電腦時, 剛好遇到 macOS 跳出 Rosetta 2 未來將停止支援的警告。
Rosetta 2 是內建於 macOS 的轉譯機制, 專為搭載 Apple 晶片的 Mac 電腦所設計。 它能自動為 Intel處理器編寫的舊版應用程式「翻譯」成 ARM 架構可理解的代碼,讓使用者得以在 Apple 晶片的 Mac 電腦順暢執行舊軟體。
1Password 6 就是基於 Intel 處理器開發的軟體, 所以為了避免之後不能使用還要急尋替代方案的窘迫場景。

我決定先轉換到 KeePassXC 這個 app, 它使用 KeePass 的 .kdbx 格式來儲存密碼。
KeePass 的好處很明確: 資料是自己的、格式是開放的、可以長久保存, 也不會被綁在某個雲端服務裡。
但就在我轉換使用 KeePassXC 一段時間之後, 還是覺得有些小地方不夠順手。
某些互動還是 1Password 6 比較好用。
剛好在這個 AI agent 盛行的時代, 我決定和 AI 一起基於 KeePass 格式做一個自己使用的密碼管理器。

這個密碼管理器可以 常駐在 menu bar, 可以用快捷鍵叫出快速搜尋, 可以透過 Touch ID 解鎖,即使重開機也一樣。 另外,這個密碼管理器平常不佔 Dock, 但真的打開主視窗時, 又能像一般 Mac app 一樣切換。

這些需求每一個都不大, 但加在一起, 其實就會影響這個工具到底順不順手,好不好用。
這次主要使用的 AI agent 是 Codex。 但我同時也會搭配 Claude Code 做 code review。
開發密碼管理器的第一個大問題是: .kdbx 要怎麼讀寫?
這不是一個簡單的文字檔或資料庫。 KeePass 資料庫涉及加密、壓縮、KDBX 版本、欄位保護、歷史紀錄等細節。自己從零實作不太合理。
我和 AI 論了幾個選項, 包括 KeePassium 的 Swift 實作、JavaScript 的 kdbxweb,以及 Rust 的 keepass-rs。

最後採用一個折衷做法: Swift app 負責 UI 和 macOS 整合, Rust helper 負責 KDBX 讀寫。
這樣可以保留 macOS 原生體驗, 又不用重新發明一套 KDBX parser。
接下來就是反覆推進讓 AI 幫忙開發我想要的功能, 目前我還不能接受一步到位, 讓 AI 一次開發完所有的功能, 因為很多需求, 其實連我自己一開始都還沒想清楚。 很多東西, 都是實際用過之後, 才會再回頭修正。
另外, 如果一次丟太大的 scope 給 AI, 其實也不利於 review 跟後續調整。
有些 AI Skill 使用起來是有幫助的, 例如 Codex 官方的 build-macos-apps:liquid-glass , 它可以幫忙打磨介面變得 Modern 。
Code review 則是使用 Claude Code 的 review 功能, 值得一提的是, 我一開始是開兩個視窗把 Claude code 的 review comment , 拷貝後貼到 Codex 給它參考修正, 但即使只是 copy/paste, 做久了其實也有點煩。

後來我乾脆做了一個小 Skill, 讓 review 方跟修正方可以透過檔案系統共享 review comment, 省掉很多重複操作。
在功能大致開發完後, 有一個重要的問題出現了: 當我真的載入我的真實資料來使用時, 解鎖很慢。
一開始我以為是 KDBX parser 有誤, 後來追下去才發現, Swift app 呼叫 Rust helper 時, 如果 helper 輸出很大的 JSON, 而 Swift 端沒有在 process 執行期間持續讀 stdout, 可能會卡在 pipe buffer。
這種問題如果只是做小 demo, 可能永遠不會遇到。
但一旦進入真實使用場景, 馬上就浮出來了。 修掉之後, 速度明顯改善。
這也讓我更確定一件事: AI 協作很適合快速把東西做出來, 但真實測試仍然不可省。

做到後來, 這個密碼管理器已經不只是「能打開 KDBX」。 目前它已經有:
- menu bar 狀態 icon
- lock / unlock 狀態
- Touch ID 解鎖
- Keychain 記住 master password
- 自動鎖定
- 開機自動啟動
- 快速搜尋
- 群組管理
- 新增、編輯、刪除 entry
- custom fields
- protected custom fields
- notes 多行編輯
- URL 開啟瀏覽器
- 複製各欄位
- 儲存前自動備份

而且它現在, 真的已經開始每天跑在我的 Mac 上。
這次經驗讓我覺得: AI 對我開發軟體最大的改變, 不是「讓不會寫程式的人瞬間變工程師」。 而是它大幅降低了「把自己的想法變成工具」的門檻。 以前如果我想到一個小工具, 可能只會停在想法階段。 因為要查 API、建專案、處理 build、debug、寫文件、整理 git commit。 每一件事都不難。 但全部加起來就很累。
我可以用自然語言說:
「這個視窗關掉後不要退出 app。」 「這個快捷鍵好像跟系統打架。」 「這個 dialog 文案不符合一般設計習慣。」 「這裡應該要用 picker,不要讓我手打 group path。」 「幫我整理一下 code,commit。」
然後 AI 就可以接收這些需求, 再轉成實際程式修改。
當然我本身的軟體開發經驗, 也幫上不少忙。
AI 可以提出實作。 但你要知道自己要什麼, 跟它的設計合不合理。
AI 可以修 bug。 但有些 bug 還是要我們介入跟判斷。
AI 可以寫 UI, 但有時能用跟好用, 還是得以真正使用者的體驗為準。
總而言之, 目前這個密碼管理器真的每天運作在我的 Mac 上。 謹此將這個經驗, 和我的朋友分享。
메타데이터
- post_id
- 19be8427e4e0
- slug
- 我和-ai-一起做了一個自己的密碼管理器-19be8427e4e0
- url
- https://medium.com/ddsakura-blog/%E6%88%91%E5%92%8C-ai-%E4%B8%80%E8%B5%B7%E5%81%9A%E4%BA%86%E4%B8%80%E5%80%8B%E8%87%AA%E5%B7%B1%E7%9A%84%E5%AF%86%E7%A2%BC%E7%AE%A1%E7%90%86%E5%99%A8-19be8427e4e0
- canonical_url
- https://medium.com/ddsakura-blog/%E6%88%91%E5%92%8C-ai-%E4%B8%80%E8%B5%B7%E5%81%9A%E4%BA%86%E4%B8%80%E5%80%8B%E8%87%AA%E5%B7%B1%E7%9A%84%E5%AF%86%E7%A2%BC%E7%AE%A1%E7%90%86%E5%99%A8-19be8427e4e0
- author_url
- https://medium.com/@ddsakura
- status
- ok
- fetched_at
- 2026-06-12 07:40:50