十月补记：本文于 2026 年 10 月 25 日整理并首次发布，页面日期用于归档对应时期的实践；后续修整一并写入。产品开放范围以文中链接的公开说明为准。
同时做 iPhone 和安卓，最容易出现一种感觉：这边刚追上，那边又往前走了。
咫尺的公开介绍也把这点写得很直接：功能以 iPhone 版为准，安卓版正在逐项补齐，个别功能会晚一些到。真正困难的地方，是怎样让“逐项补齐”变成可以完成、可以验证的一批工作。
我现在会先把两件事分开：这一批参考哪些功能，以及实现这些功能时，代码基于哪一版继续做。
本批功能先确定，别让终点每天移动#
假设这一批要追齐的是照片消息和消息列表。做到一半，手机端又增加了另一项能力，如果立即把它塞进来，这一批可能永远没有明确终点。
我会先写清本批纳入什么、暂时排除什么，以及每项完成后要看到什么结果。新增需求可以进下一批，真正影响当前功能的修复则要单独判断。
这不是让安卓停在一份过期产品上，而是给当前交付留一个可检查的范围。用户看到“补齐中”时，也应该知道哪些已经可用，哪些仍然需要等。
功能范围固定，代码却不能一直停在旧版#
“参考的功能不再扩张”和“开发一直使用旧代码”不同。共用接口、安全修复或数据兼容发生变化时，当前分支仍然需要同步和验证。
因此我会分别记功能参考和集成代码。前者回答本批要做哪些事，后者回答这些改动现在要与什么一起工作。只写“跟手机端一致”，会把这两个问题混在一起。
一项功能，至少从三层看#
第一层是交互意图。例如发照片时，用户想完成选择、发送、查看，而不是单纯看见一个长得相同的按钮。
第二层是平台能力。相册权限、后台运行、通知和系统返回行为都可能不同；照搬界面，不一定能得到同样的结果。
第三层是数据和协作。两端互发的内容能不能正确展示，旧版收到新内容怎样处理，弱网重试会不会重复，往往比单端截图更接近实际体验。
| 批次记录项 | 一个可以检查的答案 |
|---|---|
| 范围 | 这批只处理已列明的功能 |
| 平台差异 | 权限、系统交互和不可用状态分别说明 |
| 双端路径 | 手机端发出，另一端实际接收并继续操作 |
| 完成条件 | 构建、设备使用和分发分别有结果 |
表格中的功能只是方法示例，不表示某个批次已经验收完成。
做完功能，也别忘了它怎样到用户手里#
咫尺的 iPhone 和 Mac 使用 TestFlight，安卓通过自己的下载页安装，鸿蒙还要区分具体运行方式。代码里的同一项改动，不会自动在所有渠道同时出现。
我会分别记“代码已合入”“包已经形成”“对应渠道可取得”“目标设备已使用”。如果还没完成，就在公开说明里保留范围，而不是用一张功能清单把差异藏起来。
这套分批做法没有消灭多端成本，但让我更容易回答：这一轮怎样才算做完，以及下一轮从哪里继续。比一直追着移动的终点跑，这样更容易把东西真正交出去。