这次本来只是一个很简单的需求：把本机正在用的一批服务入口整理成 Chrome 书签，放到一个固定文件夹里，方便以后找。最后却折腾得明显过度，值得复盘一下。
核心问题不是“书签列表很难”，而是我一开始选错了执行层级。
普通直觉会以为 Chrome 书签就是一个 Bookmarks JSON 文件，改完重启浏览器就行。但这台机器上实际可见的账号书签主要落在 AccountBookmarks，并且 Chrome 正在运行、账号同步也在参与。于是出现了几个叠加因素：
- 文件入口判断错位：只改传统
Bookmarks，Chrome UI 不一定显示，因为同步账号书签在另一个文件里。 - 运行中回写：Chrome 运行时会把内存里的书签状态写回磁盘，外部直接编辑很容易被覆盖。
- 同步层参与：账号书签不是一个纯本地静态文件，Chrome Sync 可能把本地改动合并、覆盖或延后体现。
- 校验和/元数据问题：Chrome 书签文件不是只要 JSON 合法就一定被接受，直接拼数据容易触发不一致。
- 自动化路径越走越偏：AppleScript、临时扩展、重启浏览器这些方案每个都能解释得通，但对“加一批书签”这个目标来说，成本已经超过收益。
真正该做的判断应该更早发生：当发现 Chrome 同步书签和运行时状态让直接写文件不稳定时，就应该立即降级为两个低风险方案之一：
- 输出一份清楚的手动添加清单，让用户自己加；
- 生成一个标准 bookmarks HTML 文件，让用户通过 Chrome 书签管理器导入。
这两个方案虽然不如“我自动帮你加好”听起来完整，但更符合任务规模。尤其是当用户只需要“别忘了这些入口”时，清单本身就已经解决了大部分问题。
这次的工程教训是：
- 自动化不是越底层越好。浏览器同步数据这种有运行时、有账号状态、有校验的东西，不适合一上来就手改内部文件。
- 如果一个任务的目标是“帮人记住一组入口”，不要把它升级成“逆向并稳定改写 Chrome 同步书签数据库”。
- 一旦发现工具路径开始制造比原任务更多的状态风险，就应该主动停下来，把结果收敛成用户能直接用的清单或导入文件。
- 对 Codex 这类本机操作代理来说，完成任务不等于坚持自动化到底；合适的降级路径也是完成任务的一部分。
所以这次更合理的做法其实很朴素：先核对本机服务入口，按“开关控制台、本机地址、IPv6 地址、Cloudflare 备用地址、WebUI、API base、日志/配置目录”等功能命名，列成清单，然后让用户手动加或导入。继续尝试强写 Chrome 同步书签，反而是不必要的复杂化。