我写了一个小工具，专门帮我在“逛仓库”时不打断心流
我平时有个高频动作：
- 在各种文章、社区、Issue、Showcase 里看到有意思的仓库
- 先把链接存下来，免得丢
- 再手动
git clone到本地，准备后面读代码
听起来很简单，但一天重复几十次以后，就会变成典型的“微打断”：
- 复制链接
- 切窗口
- 粘贴到某个清单
- 回终端
- 执行 clone
- 再切回浏览器
每次都要在“看内容”和“做记录”之间来回切，心流很容易断掉。
于是我给自己写了一个 macOS 菜单栏小工具：MdM（Clipboard Repo Monitor）。
这个工具解决什么问题
核心目标就一句话：
当我在浏览仓库时，只管继续浏览。记录和 clone 这件事自动发生。
具体来说，当你复制了一个 Markdown 链接，比如：
[Some Repo](https://github.com/owner/repo)
MdM 会自动：
- 识别是不是 GitHub 仓库链接
- 把它追加到当天文件
links_yyyyMMdd.md - 执行
git c1 https://github.com/owner/repo.git（我自己的 clone 工作流）
并且做了“当天去重”：同一天同一个仓库不会重复记录、不会重复 clone。
为什么我觉得它有效
它不是“省掉一个大步骤”，而是省掉了大量“很小但高频”的动作切换。
这些切换在单次看起来不重，但非常影响连续思考：
- 从阅读上下文跳到管理上下文
- 再从管理上下文跳回阅读上下文
MdM 把这些机械动作后台化之后，我的体验是：
- 浏览阶段更连贯
- 收藏更完整
- 后续回看更方便（按天文件 + 日志）
我现在的使用方式
- 菜单栏常驻，按需开启监控
- 默认只处理“单链接复制”，避免误触
- 最近 7 天文件直接在菜单里点开
- 预览窗口左侧可浏览历史文件，右侧渲染 Markdown
- 需要时一键复制 Markdown 原文
如果当天做了很多探索，最后只要看 links_yyyyMMdd.md，就能快速回顾“我今天到底看了什么”。
一个小结
这类工具的价值不在于“技术炫酷”，而在于它是否真正嵌入你的日常节奏。
对我来说，MdM 做到的是：
- 减少操作噪音
- 保护浏览心流
- 让“发现 -> 收集 -> 落地”这条链路更顺滑
如果你也有类似习惯（经常边浏览边收集仓库），这种自动化值得试一试。它不会改变你怎么思考，但会减少你被迫中断思考的次数。
实现细节：剪贴板监听与 Markdown 解析
MdM 的监听模型是“轻量轮询 + 变更触发”：
- 通过
NSPasteboard.general.changeCount判断剪贴板是否变化 - 只有变化时才读取文本，避免无意义解析
- 默认只处理“文本里恰好一个 Markdown 链接”的场景
Markdown 解析采用正则提取 [label](link)，并支持开关控制：
- 关闭多链接模式：文本里出现多个链接直接忽略
- 开启多链接模式：逐个解析后进入后续校验
这么做的好处是：默认行为保守，误触少；需要批量处理时再显式打开。
实现细节：URL 规范化与去重策略
识别到链接后，不会直接用原始 URL，而是先做规范化：
- 仅接受
https://github.com/owner/repo - 去掉 query / hash
- 兼容末尾
/和.git - 统一得到 canonical URL：
https://github.com/owner/repo
去重键使用 owner/repo，并且是“当天去重”：
- 同一天同仓库：不重复写入，不重复 clone
- 跨天：允许再次记录（符合“按天回顾”习惯）
我当时有考虑“全局去重”，但最后选择“按天去重”，因为我更关心“今天看了什么”，而不是永久只收录一次。
实现细节：菜单栏交互、日志与预览窗口
菜单栏交互上，我踩过一个典型坑：点击时有 beep 但不弹窗。
最终方案是把动作放到菜单关闭后异步执行，并统一走窗口管理器。
当前设计要点：
- 菜单直接展示最近 7 天文件（不用再点二级菜单）
- 关于窗口和预览窗口都走
NSWindow管理 - 反复点击时已存在窗口会被拉到前台，而不是“有提示没窗口”
日志设计上，我故意做得“可排障优先”：
- 每天一份
logs_yyyyMMdd.log - 记录剪贴板变化、解析数量、跳过原因、clone 结果
- 成功写入时明确写
已写入 markdown: ...
这样在“看起来没反应”的时候，不靠猜，直接看日志就能知道卡在哪一段。
实现细节：为什么选 MarkdownUI 做渲染
一开始我用的是 AttributedString(markdown:)，但在复杂 Markdown 下（列表、换行、表格等）展示不够稳定，阅读体验一般。
后来换成 MarkdownUI，核心原因是：
- 渲染效果更接近常见 Markdown 阅读体验
- 和 SwiftUI 集成自然，维护成本低
- 后续想做主题化/样式调优也更方便
预览窗口现在也不仅是“看一篇内容”，而是“左侧历史文件列表 + 右侧预览 + 一键复制原文”，更贴近我实际回顾和再利用的流程。
这次开发里，我最意外的一点
坦白说，我以前几乎没有做过 Swift 桌面应用开发。
但这次从需求到上线可用版本，我用 Codex 把整个流程跑了下来：需求拆解、PRD、待办流转、代码实现、调试修复、测试回归、文档补齐，全部一条线推进。
最夸张的是：从我们开始协作到现在，我甚至还没有打开过 Xcode。
我基本只做两件事：
- 说清楚我要什么（比如“保持心流”“默认中文”“更新失败静默”）
- 在真实使用里给出反馈（比如“这里没弹窗”“这里会 beep”“日志不够可观测”）
剩下的实现细节，Codex 很快就能落到代码里，再通过回归测试把质量兜住。
对我来说，这不是“AI 帮我写了几个函数”，而是把一个完整的小产品从 0 到 1 推出来了。
我希望它继续进化的方向
现在这个版本已经能稳定支持我的主流程，但后面我还想做几件事：
- 支持跨天/全局去重策略切换
- 历史文件全文检索
- 更灵活的 clone 命令模板
- 预览窗口里增加更多信息密度（标签、统计、快速过滤）
如果你也有类似工作流，欢迎拿这个思路改成你自己的版本。
工具不需要“大而全”，只要能精准减少你每天最烦的重复动作，它就有价值。
结语
MdM 对我最大的意义，不是自动化本身，而是把“动作成本”降到几乎感觉不到。
当记录和 clone 变成无感动作，注意力就能更长时间停留在真正重要的事情上：理解代码、判断价值、建立自己的技术地图。
如果你最近也在被各种“微打断”消耗，不妨给自己做一个这种小工具。
一次投入，长期复利。