DockTouchBar · 13 · 1.9 到 1.10：居中变最大化，长按“关不掉”也要有反馈

1.8 之后的三个小版本，起因都是用户的一句话：这个按钮只能居中，是不是有点浪费；系统里的预览、访达长按之后怎么没反应。这一篇把它们放在一起写，重点是每次动手前要先看清楚现在是什么情况。

开发细节补充：这篇记录放在 DockTouchBar 的产品日记里，不是为了把一个功能包装成故事，而是把“13 · 1.9 到 1.10：居中变最大化，长按“关不掉”也要有反馈”放回真实项目推进中看。它要同时回答三件事：用户为什么需要这个点，开发时哪些边界必须先定住，以及这个选择会怎样影响上架、推广和后续课程复盘。平台口径是 macOS / Touch Bar / Swift / AppKit，当前公开状态是 已公证 DMG / 源码可见 / 本地优先，所以文案不能脱离真实发布进度。

对应的 docs 线索主要来自 项目开发记录、私有接口可行性验证、跨桌面切换与手势实验、签名、公证与发布检查记录。公开页面不会照搬内部工作记录，而是把可公开、可学习、不会泄露私密路径和账号信息的事实整理出来。DockTouchBar 的开发记录从一次不满出发：现成的 Touch Bar Dock 工具功能太杂、用久了不稳定，于是把范围收窄到只做 Dock，并把稳定放在第一位。 动手写产品之前先做了私有接口的可行性验证，发现旧方法名已被系统移除，也发现 isVisible 会说谎，这两条直接决定了后面的技术选型。 跨桌面切换、双击隐藏（原计划是最小化，被台前调度挡住）、长按退出，每一个都有实测表格和被否掉的方案，而不是一次写对。 发布链路记录了权限绑定签名、公证凭据、二进制里的本机路径这几个真实踩过的坑，以及为此重新编译并重新公证的过程。 连点失效的排查记录了“先复现、分层找根因、从固定等待改成看结果、再加上持续纠正”的全过程，也记录了测试本身踩的坑：键鼠空闲判断、Touch Bar 触摸看不见、台前调度窗口干扰判据。 1.5 记录了一次新机制的副作用：双击隐藏被“盯着结果并纠正”当成异常拉回来，修法是让隐藏也成为一次新点击并在隐藏后核对结果；这次没有拿到自动化数据，只有用户手动确认。 1.6 记录了亮度调到 0 时的死循环和右端齿轮兜底：暂停与自动恢复的几种情况、被否掉的“调到 0 自动让位”（需要轮询亮度，会破坏空闲唤醒 0 次），以及哪些只能由用户在真机上验证。 1.7 记录了齿轮改成小眼睛、临时隐藏时长可选，以及菜单的重新命名和分组（功能不变，只减少误解）。 1.9 到 1.10 记录了居中按钮变成居中 / 最大化切换（先判断窗口现在的样子）、提示结尾改成转场式风暴、长按按窗口状态决定关窗口还是退出、被确认框拦住时切过去，以及新增的权限菜单。 1.24 记录了 Vibe 并入 DockTouchBar：先查出 vibecoding 是 main 的超集，再还原身份、合入三个外部 PR，以及数据迁移放在监听之前才不会删掉 socket 的坑。 1.8 记录了长按提示从一条红色进度条到像素画四季的几次推翻重来，右侧按钮换成咖啡杯，以及哪些效果只能在真实窗口里验证、哪些只能由用户在真机上确认。

从产品功能看，DockTouchBar 关联的能力包括：Touch Bar 上常驻显示 Dock：访达、固定的 App、其他正在运行的 App，顺序和系统 Dock 一致、单击切换（窗口在别的桌面时自动切过去），双击隐藏，长按退出；长按时 Touch Bar 右边缘会显示“正在关闭…”和倒计时，手指不会挡住，背景是像素画的春夏秋冬四季小场景，一个小角色沿着进度条往前跑，跑到头就关闭并扫过一阵花瓣或雪；长按会先看窗口：在最前面且有多个窗口只关当前窗口，访达这种退不了的会隐藏，App 在等你回答（要保存吗之类的确认框）或没关掉时会自动切过去并提示，每次长按都有反馈、睡眠唤醒、锁屏解锁、控制条进程重启之后自动恢复、图标位置可选靠左、居中、靠右（图标放不下时仍从左边滑动）；按 Fn、截图录屏时 Dock 自动让位，万一没收到“让位结束”的信号，会每隔几秒自动核对并恢复（1.25 起，可在设置里调整或关闭）、右侧有两个白色 8 位像素风的小按钮：咖啡杯（杯口有蒸汽）点一下暂时隐藏 Dock、把 Touch Bar 还给系统（亮度、音量），10–60 秒后自动恢复，屏幕被调到全黑也不会把你锁在外面；最右边是窗口居中 / 最大化按钮：先居中，再点一下最大化，再点回到居中，你自己拖过或换了 App 就先居中，图标跟着窗口现在的样子变、连续快速点击以最后一下为准；切桌面被系统丢掉或焦点被抢走，会自动纠正回你最后点的那个。写这类日记时，不能只说“做了什么”，还要说明为什么先做这些、为什么暂时不做另一些。比如一个按钮、一个导入流程、一个本地模型开关或一段截图文案，放在代码里只是小改动，放在产品里却会影响用户理解、审核员复现和后续推广素材。

从工程推进看，这篇日记对应的检查点是：和 Claude Code 协作完成：先做私有接口的可行性验证，再写正式代码；Developer ID 签名并通过 Apple 公证，DMG 在 GitHub Releases 分发；发布前专门检查过二进制里有没有带出本机路径；空闲占用是实测数字：CPU 0.0%、空闲唤醒 0 次、内存约 32 MB。菜单里有“权限”一项，列出唯一需要的辅助功能权限、状态和用途。真实开发最容易失真的是中间过程，因为最后页面看起来只有一个结果，但实际会经历方案取舍、权限确认、素材准备、测试设备、审核备注和发布节奏。把这些过程写下来，后面做同类产品时才不会重新踩同一个坑。

从隐私和合规看，当前约束是：不联网，没有统计，没有账号。只把开关、语言、长按时长、提示风格和居中窗口大小这几项偏好设置保存在你的 Mac 上。这类信息必须前置到开发日记里，因为独立产品的可信度不是靠口号建立的，而是靠数据在哪里处理、用户能不能退出、功能是否离线可用、商店页怎么承诺、隐私政策是否与实现一致这些小事实积累出来的。

从课程和复用看，这篇内容可以沉淀到 Swift 原生 macOS、AppKit 与 NSTouchBar、私有 API 的风险控制、签名、公证与 DMG 发布。它的价值不只是给访问者看一个产品，而是展示一个独立开发者怎样把想法转成可验证的产品：先收窄场景，再选技术路径，再做体验最小闭环，最后把审核、推广、运营数据和失败教训都纳入下一次迭代。

小工具的价值来自克制和验证：先验证最大的不确定性，再写代码；发布前检查产物本身，而不只是源码。 这也是为什么每篇产品日记都要写到足够长：不是为了凑字数，而是为了把“证据、决策、实现、边界、复盘”都放在同一页，让读者看到一个判断是怎样被逐步验证出来的。最难的是让一个依赖私有接口的后台工具，在系统更新、睡眠唤醒和权限变化之后仍然稳定，并且在接口消失时安全地关闭功能。

所以这篇日记的结论不是“功能已经写完”，而是把一个阶段的判断公开化：哪些证据足够支撑继续推进，哪些资料还需要回到源码、商店材料、公开文案或运营观察里补齐。这样的记录会比单纯的发布公告更慢，但也更真实，能让产品页、发布记录和课程内容保持同一条事实线。

验收时我会把它拆成四个层次：第一层是用户路径能不能走通，第二层是异常状态有没有被诚实处理，第三层是页面上的按钮、状态、截图和文案是否对应真实发布渠道，第四层是公开证据能否支撑这个判断。只要其中一层对不上，产品看起来再完整，也不能算真正进入下一个阶段。

交接时也要保留边界：源码、构建、测试、商店元数据、公开文案、平台反馈和运营观察分别保存原始资料。产品日记只把这些事实翻译成读者能理解的过程，不替任何私有记录保存原始材料。

把这些内容公开出来，还有一个很现实的原因：AI 教程如果只展示成功结果，很容易让人误以为产品是一次生成出来的。真实情况恰好相反，真正可学习的是一次次收窄、验证、失败、补证据和重新提交。日记越具体，后续读者越能看到判断的脉络，而不是只看到一个漂亮的截图。