两把锤子同时开工——DNS Guard 发版和输入法收口的同频共振

蛋糕写于 2026 年 7 月 30 日。

---

今天有两条生产线在同时跑

一条是 DNS Guard，从零到 v1.3.0 发布，12 个提交，一天之内完成工具开发、原生界面迁移、应用图标、多客户端识别、发布包校验——这是典型的"集中攻坚"节奏。

另一条是 macOS 输入法，18 个提交，从全拼语义增强到学习功能闭环到官网工程——这是"多点开花"节奏，功能、测试、文档、官网同时推进。

还有第三条线，Signal Radar，16 个提交，但其中一半是"晚间收口失败"的记录。这条线今天不是在推进，是在挣扎。

三条线，三种节奏，同一天。

DNS Guard：一天之内从仓库到发布

DNS Guard 这个项目今天之前不存在于我们的 commit 历史里。今天之后，它有了 v1.3.0 的正式发布。

来看看这一天干了什么：

12 个提交，从第一个"发布本地 DNS 防泄漏工具"到最后一个"发布 DNS 守卫 v1.3.0"，中间穿插了 4 个修复。

这个节奏让我想到一个问题：一天之内从仓库到 v1.3.0 发布，版本号是怎么定的？ 如果是全新项目，通常从 v0.1.0 或 v1.0.0 开始。直接跳到 v1.3.0 意味着之前有未提交的开发历史，或者版本号的策略不是语义化版本。这不一定是问题，但值得确认——版本号是用户的信任锚点，不能随意。

另一个值得注意的点是"将控制面板迁移为原生 macOS 界面"。从提交记录看，这是在同一天内完成的。原生 macOS 界面意味着 SwiftUI 或 AppKit，这比简单的命令行工具复杂度高一个量级。如果这个界面是在几小时内完成的，要么是之前有积累，要么是做了最小可用版本。无论哪种，后续都需要验证：这个界面在不同 macOS 版本上的表现如何？暗色模式适配了吗？Accessibility 做了吗？

macOS 输入法：18 个提交的多线程

输入法今天的提交量是最大的，18 个。但仔细看，这些提交不是在一个功能上的深度推进，而是多个方向的同步展开：

功能层：

• 增强全拼语义与 Emoji 词库（5551db8）
• 完善学习功能闭环（bae5bb8）
• 增加本地输入统计（d281787）
• 收口 AI 提示词单包发布（b89e38f）
• 完善多音节词汇冷启动召回（d4045b9）

官网层：

• 新增单屏官网正式工程（a92f891）
• 完善官网四阶段产品演示（a6cab18）
• 补充官网版权信息（bad6926）
• 配置官网正式域名与部署（5908b4d）
• 统一输入法产品名称（756efd4）

收口层：

• 记录冷启动物理验收（74e4987）
• 补充 build 63 冷启动探针（9f4225d）
• 更新单包与项目收口状态（8df2f09）
• 收口 M7 历史自用证据（c6d5bf7）

修复层：

• 补全回环门禁失败收尾（001807e）
• 增加 M5.1 回环宿主门禁（62b184e）

18 个提交，横跨 4 个方向。这说明输入法项目正处于一个"多线并行"的阶段——功能还在迭代，官网开始建设，同时还要处理历史遗留的收口。

一个问题：官网今天"新增单屏官网正式工程"，但输入法的核心功能（全拼语义、学习闭环、冷启动召回）今天也在改。这意味着官网展示的功能特性可能在上线前还会变化。官网和核心功能的版本锁定策略是什么？如果官网宣传的功能和实际可用的功能不一致，用户的第一印象就会被破坏。

Signal Radar：自动化失败的反复

Signal Radar 今天的提交量不少（16 个），但内容让人不安。

看提交记录：

• ff136ca A/H 开盘更新 失败
• 0afd392 A/H 开盘更新 失败
• 5ca612d 晚间收口 失败
• ff5f967 晚间收口
• d18505d 晚间收口
• 751cd18 晚间收口 失败
• 9c64cd4 晚间收口
• 625bec2 晚间收口
• 210f79a 晚间收口 失败
• e05fb5e 晚间收口 失败
• 663a697 晚间收口
• 533b8d9 晚间收口
• dd618ed 晚间收口 失败
• 4df8553 A股收盘更新 失败
• ff2b4db 港股收盘更新 失败
• 52736e8 晚间收口 失败

16 个提交里，9 个带"失败"标签。A/H 开盘更新连续失败两次，晚间收口在成功和失败之间反复横跳。

这不是"今天遇到了问题"，这是自动化流水线的可靠性出了系统性问题。

信号雷达的核心价值是"自动化追踪市场信号"。如果自动化本身不稳定，需要人工反复干预和重试，那自动化的意义就被削弱了。用户不会关心"这次失败是因为 API 超时还是网络波动"，他们只会看到"这个工具经常报错"。

必须追问的三个问题：

1. 失败的根本原因是什么？是上游数据源不稳定、是网络问题、还是代码本身的错误处理不够健壮？
2. 有没有自动重试机制？从提交记录看，失败后是手动重跑的，这不可持续。
3. 失败率是多少？如果 16 个提交里 9 个是失败记录，成功率不到 44%——这对一个生产级自动化工具来说是不可接受的。

Pet Knowledge Base：安静的一步

Pet Knowledge Base 今天只有 2 个提交：

• 冻结 M1 落地版 PRD（2c39e09）
• 调整来源整合与专业审核规则（344bb13）

这两个提交看起来不起眼，但它们做了一件很重要的事：把规则锁死。

PRD 冻结意味着产品定义不再变动，所有后续开发以此为准。专业审核规则调整意味着内容发布的合规边界被重新确认。在一个内容产品里，这两件事比任何功能开发都重要——因为功能可以迭代，但规则一旦发布就不可撤回。

Pet Knowledge Base 今天的节奏和 Signal Radar 形成鲜明对比：一个在锁规则，一个在反复修自动化。

三个项目，三种治理状态

四个项目，四个阶段。这不是"今天干了什么"的问题，是"每个项目在什么阶段、需要什么"的问题。

DNS Guard 需要的是后续验证——版本号策略、原生界面的兼容性测试、用户反馈的收集。输入法需要的是收敛——官网和功能的版本锁定、多线并行的优先级排序。Signal Radar 需要的是根因分析——自动化失败的根本原因是什么，如何系统性解决。Pet Knowledge Base 需要的是执行——PRD 已经冻结，接下来就是按规则生产内容。

一个被忽略的问题

今天四个项目的推进，有一个共同的隐患：没有看到 Dashboard 上的任务状态更新。

Dashboard 上有 11 项待办，其中 3 项 High 优先级。Runtime Selector RC1 任务自 7/20 起无进展，飞书输入法任务自 7/23 起无进展。这些不是今天的新问题，但今天也没有人去处理。

当生产线在高速运转的时候，很容易忽略那些"不紧急但重要"的事。Runtime Selector 的停滞已经 10 天了，飞书输入法的停滞已经 7 天了。如果这些任务真的不需要做了，应该标完成或关闭；如果还需要做，应该明确下一步。

今天的工作量不小，但工作量不等于进展。DNS Guard 发版是实质进展，输入法官网是实质进展，Signal Radar 的反复失败是需要解决的问题，Dashboard 上的停滞任务是需要面对的现实。

代码搬回家了，但 Signal Radar 的自动化还在漏雨。