需求来自一次非常具体的现代化改造：把一个运行多年的古老 MVC 架构 PC 端配置工具，完整搬到 Android、iOS 和鸿蒙三端手机。原工具沉淀了设备控制、板卡配置、UID 云转发等大量隐性规则；我们要做的不是重新画三个界面，而是在一个假期、两天之内完成需求复刻、协议验证、自动回归和三端上架。本文复盘这条从遗留系统到三端产品的完整研发流水线。

〇、先报成果：研发跑通，发布状态分层

先说清楚"这文章不是理论总结，是刚发生的实战复盘"：

• Android：版本 2026.10.17.7 已完成构建、测试，并发布到 FIR 内测分发页；这里的“已发布”指内测分发，不等同于 Google Play 商店上架。

• iOS：版本 2026.10.17、构建号 26101708 已在 App Store Connect 可见，审核物料已补齐；当前不能表述为“已通过审核”。

• 鸿蒙：本文保留三端方法论，但当前 ComputerMonitor 仓库没有鸿蒙工程和 AppGallery 审核回执，因此本轮不对鸿蒙发布状态作已提交或已上线判断。

这轮实践的关键词仍然是快，但“快”必须建立在状态准确、证据可追溯的基础上。Android 已完成内测分发，iOS 已进入 App Store Connect 的版本准备阶段，鸿蒙则需要在对应工程与发布后台补齐证据后再更新状态。下面拆开讲支撑这套效率的工程方法。

一、背景：这不是"一套代码"，是业务与协议的跨端复刻

需求的源头并不是一个从零设计的新产品，而是一套已经运行多年的 Windows PC 端配置工具。它采用典型的 C++/MFC MVC 架构：界面、业务状态和 TCP 协议处理长期耦合在控制器中，代码古老但业务经验密集。设备控制、配置读写、地址发现、UID、局域网直连和云代理穿透等规则，很多没有独立规格文档，只存在于旧代码分支、按钮事件和现场使用经验里。我们的第一步因此不是写手机页面，而是从遗留实现中抽取稳定协议、业务约束和异常边界，再把它们翻译为三端共同的需求基线。

• Android：Java + XML Views，Android Gradle Plugin 8.7.3、Gradle 8.9、JDK 17、compileSdk / targetSdk 35；

• iOS：Swift + SwiftUI，使用 Xcode 构建与 Archive，目标 App Store Connect；

• 鸿蒙：文章中的 ArkTS / hvigor 内容来自三端方案参考；当前 ComputerMonitor 仓库未包含鸿蒙工程，相关实现与 AppGallery 状态需要在独立工程中验证。

很多人会以为这是"一码三吃"的跨端工程。但现实是：三端各自用着完全不同的技术栈和组件范式，我们做的是把同一套硬件协议和业务行为在三个平台上"各自正确地实现一遍"，而不是共享一套 UI。这也正是全文所有矛盾与反思的起点。

三端首页（左起：Android / iOS / 鸿蒙）

二、先聊底层：协议是为多端对齐"定海神针"的那一环

三端最不能漂移的，就是协议。我们把它当成比"约定"更硬的东西来治理——用一个 8 字节帧为例：

55 ADDR FUNC D1 D2 D3 D4 CHECKSUM

• 第 1 字节 55 是帧头；

• ADDR 是板卡地址；

• FUNC 是功能码；

• 后 4 个字节是参数（比如 32 路开关位的比特掩码）；

• CHECKSUM 是前 7 字节和的低 8 位。

暂时无法在飞书文档外展示此内容

协议实现落在各端自己的工程结构里：Android 主要是 RelayProtocol.java 与 mySocket.java，iOS 是 RelayProtocol.swift 与 DeviceClient.swift；鸿蒙如继续实现，应在独立工程的 protocol / service 层保持同样的帧定义与测试向量。新增“读取 UID”“读取板卡地址”等命令时，先更新协议规格，再分别进入各端实现。

我们的做法是：每一次协议补充，先沉淀成文档、再落到三端实现，并且每一端都必须有对应的"读协议-解析返回"的单元测试。这样当 Android 侧发现"云转发持续返回无关帧导致读取卡死"时，修的是 Socket 的超时策略（加总读取截止时间），而不是去改协议本身——协议层永远是稳定的，变的只是各端的网络与状态处理。

一句话：跨端对齐最该对齐的，不是像素，是协议。协议一致，其它分歧都是局部问题。

三、通用研发规范：让三端都能跑起来的"最小底座"

多端并行最容易出现的问题是：本地能编译、换台机器就崩。我们为此沉淀了几条通用规范：

1. 环境可复现，脚本化到一台新机器

Android 端我们写了一套环境脚本（macOS 的 setup-android.sh、Windows 的 setup-android-windows.ps1），把 SDK、JDK 17、模拟器、Gradle 缓存一次性装到约定目录：

# Windows
.\scripts\setup-android-windows.ps1
.\scripts\android-env-windows.ps1
.\gradlew.bat testDebugUnitTest assembleDebug

iOS 生成并提交 xcodebuild-*.log 便于排查 xcodebuild 版本/命名问题；鸿蒙则使用官方的 hvigor 与 build-profile.json5。

关键点：版本锁死。比如 Android 明确 Gradle 8.9 只兼容 JDK 1.8~22，若误选 JDK 25 会直接拒编。这种"版本兼容表"要写进 README，降低 AI 或新人踩坑的概率。

2. 版本号用日期——三端统一的心智模型

我们放弃了递增的 v1.2.3，改为当天日期即版本号：

Android versionName = "2026.10.17.7"
Android versionCode = 26101707
iOS MARKETING_VERSION = "2026.10.17"
iOS CURRENT_PROJECT_VERSION = 26101708

对外版本采用 YYYY.MM.DD，同一天多次发布可追加序号；构建号采用 YYMMDDNN。这样三端版本一眼能对上，同时满足 App Store Connect 对已上传构建号不可复用的要求。

3. 把发布脚本当成一等公民

发布到 fir/betaqr 我们写成脚本，并且强制版本号从构建配置自动读取，而不是脚本里写死：

DEFAULT_VERSION_NAME="$(sed -nE 's/.*versionName = "([^"]+)".*/\1/p' app/build.gradle.kts | head -n 1)"

这个改动的直接教训是：脚本里硬编码的上一个版本号，会在一周后安静地发布出一个"旧版本"。敏感信息（如 API Token）一律走环境变量，绝不进代码库。

四、从古老 MVC 到三端商店：完整自动研发流水线

两天完成三端的关键，不是让 Agent 无限制地产生代码，而是把研发拆成一条可复刻、可判定、可回滚、可发布的流水线。每一阶段都有明确输入、产物和放行条件，Agent 负责加速执行，测试和商店规则负责给出客观反馈。

0. 先看治理框架：研发到发布的四阶段门禁

完整流水线先被压缩为四个不可混淆的阶段：规划、开发、验收门禁、定稿发布。前两阶段追求速度，第三阶段负责给出客观的对错反馈，第四阶段才允许产生面向用户和商店的正式结果。

硬规则：第 3 阶段未通过时，默认不得执行 git push、fir 发布或商店提交。只有用户明确要求跳过，并且风险被记录，才允许带风险放行。

这道门禁解决了 AI 辅助开发中最危险的问题：Agent 不能因为“代码已经写完”就把任务判定为完成。完成的定义必须是实现存在、测试通过、产物可用、发布可追溯。下面的遗留系统取证、三端复刻和自动化测试，都在这四阶段框架内运行。

1. 先做遗留系统取证，而不是直接重写

古老 PC 工具没有完整 PRD，真实需求散落在 MVC 控制器、按钮事件、Socket 收发、配置文件和用户操作习惯中。我们先建立“遗留行为证据表”：输入是什么、发什么协议、期待什么响应、超时如何表现、配置如何保存。只有被代码、硬件响应或用户场景验证过的行为，才进入三端需求基线。

2. 把需求变成可复刻的三端规格

每个需求不再写成“安卓加一个按钮”，而是写成跨端行为合同：入口位置、字段含义、协议帧、成功结果、失败提示、持久化规则、兼容策略和验收用例。Android、iOS、鸿蒙分别用本端组件和架构实现，但输入输出与异常语义保持一致。

3. 一张图看完整流程

暂时无法在飞书文档外展示此内容

这不是单向“写完即结束”的瀑布。商店审核、真机网络、客户设备和线上日志都会形成新证据，再回流到遗留行为取证与规格层。只要规格和测试先更新，下一轮仍然是三端同步复刻，而不是三套代码各自打补丁。

4. 五道回归卡点决定能不能进入发布

5. 自动开发不是“自动写代码”，而是自动闭环

Agent 接收同一份需求复刻包，分别进入三端仓库，先读取本端架构与历史约束，再完成实现、补测试、运行回归、生成构建产物。任何测试失败都会成为下一轮修复的明确输入。只有全部卡点变绿，流程才进入版本更新、签名、上传和商店提交。

1. 需求入口：业务变化先形成跨端规格与验收用例；

2. 并行实现：三端按各自组件体系开发，不强行共享 UI 代码；

3. 自动判定：测试、截图和构建结果直接判断对错；

4. 统一版本：日期版本关联同一批三端需求；

5. 自动发布：脚本读取版本、注入密钥、构建签名并上传分发或商店；

6. 反馈回流：审核问题和设备问题沉淀为新用例，避免再次发生。

真正可持续的自动开发公式：稳定规格 × 三端复刻 × 自动回归卡点 × 可重复发布脚本。代码生成只是其中一环，能够稳定判错和自动上架，才构成完整生产力。

6. 上架自动化的边界

可以自动化的是版本号、构建、签名、产物校验、上传、发布记录和状态通知；仍需人工判断的是隐私合规、权限用途、商店文案、截图表达和审核申诉。我们的目标不是绕过审核，而是让机器承担重复劳动，把人的时间留给产品判断和合规责任。

五、自动测试：给 Agent 一双"看得见对错"的眼睛

这部分的收益是这次研发里最出乎意料的。我们给 Android 端配了足够厚的测试网：

• 单元测试：覆盖协议编解码、.cmd 持久化迁移、连接池路由、Socket 超时等核心逻辑；

• Paparazzi 截图测试：无硬件、纯 JVM 渲染出 UI 截图，跑一遍就知道布局有没有被改飞；

• 模拟器走查：Android 15 / API 35 模拟器逐页点一遍，产出多张截图；

• Mock TCP：直连、云转发两条链路都能在无真机时被测试；

• Lint：目标是 0 errors。

每次改动后，固定跑一遍这条红线：

./gradlew testDebugUnitTest assembleDebug

为什么这对 AI 辅助开发特别重要

我们大量使用 AI Agent 改代码（改协议字段、加"读取地址"按钮、修 UID 云转发逻辑）。Agent 最大的不确定性是"它以为对了"。测试反馈就是它的"对错裁判"：

• 改完协议解析，有单测告诉我"这个 UID 该被解析成 16 字节，你解析成了 8 字节"；

• 改完 UI，Paparazzi 截图能立刻看出按钮挤到哪去了；

• 改完 Socket，有专门用例验证"即使持续收到无关字节也必须按时超时退出"。

可验证、可评估的环境，决定了 Agent 修 bug 的效率不是一个数量级而是好几个数量级的提升。没有这套反馈，Agent 容易陷入"改一行、猜一下、再改"的盲打循环；有了它，Agent 说"我修好了"的时候，我们真的信。

反思一：投入在"让结果可被自动评判"上的时间，回报率远高于投入在"多写几行代码"上的时间。

六、三端并行：怎么"分"，怎么"对齐"

多端研发刻意不共享 UI、不强行一码三端。当前仓库中的 Android 与 iOS 各自独立演进，只共享协议、字段含义、异常语义和验收用例；鸿蒙若在独立工程继续实现，也应遵守同一份行为合同。

并行时最大的挑战不是并行本身，而是"对齐"。尤其在总共只有 2 天的时候，每一分钟的重复解释、来回返工都是奢侈品——下面这三条反思，实际上就是我们用 2 天时间压力逼出来的取舍。

反思二：多端之间"严格 UI 对齐"几乎不现实

• Android 使用 Java + XML Views，状态由 Activity、Adapter、Repository 和持久化配置协作；

• iOS 使用 SwiftUI + ObservableObject，状态变化直接驱动界面刷新；

• 鸿蒙方案可使用 ArkTS 的 store / service / protocol 分层，但必须在独立工程中以实际代码和测试验证。

三种范式里"一个按钮"的呈现方式、生命周期、状态管理完全不在一个维度。要求三端像素级一致，既不经济也无必要——我们改为对齐"信息结构 + 交互路径"，即关键字段、可读性、操作流程一致，具体视觉允许平台各自发挥。

反思三：组件设计思路有本质差别，"复用"要克制

• Android 继续沿用现有 View 与 Adapter 边界，避免为了形式统一引入不必要的架构重写；

• iOS 使用 AppStore、DeviceClient 和 SwiftUI View 分离状态、通信与展示；

• 鸿蒙只有在存在可运行工程后，才能决定 store、service 与组件的实际复用边界。

表面看起来都是“一个开关列表”，但组件边界、状态归属和复用粒度完全不同。我们的取舍仍然是：协议层统一、业务行为统一、UI 层各端自治。真正可以互相参考的是 RelayProtocol.java、RelayProtocol.swift 这类协议解析、校验和测试向量，而不是直接共享 UI 代码。

Android 设备设置页（板卡地址、UID 云转发、读取UID / 读取地址）

七、值得一看的落地细节（剪自真实迭代）

挑三个我们在三端迁移中都遇到的具体点：

这些点如果只在 Android 修、iOS 和鸿蒙不跟进，就会造成"同一份协议，三端行为不一致"的暗坑——所以每一项我们都要求三端同步落地，并各自补测试。

八、总结

本轮可确认的结果是：Android 已完成 FIR 内测分发，iOS 构建已进入 App Store Connect 并完成审核物料准备；鸿蒙状态需要在独立工程和 AppGallery 后台继续核验。比“几个端都上桌”更重要的，是下面这些可复用判断：

1. 协议是对齐的锚点：跨端先固定协议，别让 UI 分歧污染协议层。

2. 环境与版本可复现：脚本化、版本锁死，是新机器和 AI 都能顺利入手的底线。

3. 测试网就是 Agent 的"对错裁判"：可验证可评估的环境，是 AI 辅助开发效率跃升的前提。

4. UI 严格控制成本、组件不复用：三端 UI 只对齐信息与交互，不强求像素，不自造伪复用。

最后送一句我们踩坑踩出来的话：

你有多容易知道"自己错了"，你就有多快能修对。——这一个原则，同时适用于我们的测试基建，也适用于我们依赖的 AI Agent。

九、机会点：把"复刻"做深，效率上一个数量级

这 2 天不只是交付了三端，更重要的是验证出一条可复制、能被再放大的方法。机会点就藏在三个杠杆里：复刻同步、回归卡点、统一版本。

1. 从"三端各写各的"到"一个需求复刻进三端"

默认动作是：需求一到，三端各从零实现、各回一遍问题、各做一次回归，同一件事反复理解 N 遍。而这次我们做到的是：因为协议和行为先固定，一次需求 = 同一份规格的三端方言。把每一次交付都从"从零写"切换成"按规格复刻"，实现就具备规模化复制的可能，这是第一个数量级的来源。

2. 定好"测试回归卡点"，让每端都有可判对错的裁判

把测试网升级为"卡点闸门"，三端各自约定死这些过闸条件，不满足不合并：

• 核心协议单测：编解码、解析返回必须被用例覆盖；

• UI 回归截图：无硬件渲染出界面，改完立刻看到布局是否被改飞；

• Mock 直连 + 云转发链路：无真机也能验两条通道；

• Lint / 编译零错：进 CI 的前置硬门槛；

• 三端同步清单：一个需求必须三端都补齐才放行，杜绝"只有安卓修了"的暗坑。

卡点自动化后，回归从"发布会前的恐慌"变成"每次改动的日常动作"；AI / 新人每改一次都能立刻知道对错，返工轮次大幅下降，这是第二个数量级的来源。

3. 同步上线三端，消除"版本错位"

用日期版本号统一三端语义，需求按"三端同批"排期，功能评审以协议与行为为准、UI 各自自治。这样测一轮 == 覆盖三端、反馈一次 == 修三处、发一版 == 三端对齐，版本错位带来的沟通与返工成本被直接抹平。

"20 倍"从哪来

把同一个需求，在传统方式与这套方式下各拆一遍时间去向：

结果是一个需求从"3 份实现 + 3 份人肉回归"变成"1 套规格 + 1 套卡点 + 同步放行"。量级落在约 6~20 倍，自动化覆盖越深，越接近上限——这也是为什么 I/O 值得继续投入在"卡点质量"上。

落地路线：把它做成常态

1. 短期：三端各自把卡点脚本建好并跑绿；

2. 中期：把"一个需求"固化成清单模板：需求 → 三端分支 → 三端卡点 → 同步发布；

3. 长期：卡点进 CI，Agent 跑绿灯自动并入，形成"复刻即同步"的流水线。

机会的核心不是"写了几个端"，而是一套规格 + 一套卡点撑起三份输出。把这套固化下来，从 2 天一个版本，变成随时可复制的标准产能。

边界与代价要写清楚：UI 只对齐信息与交互，不强求像素；组件不共享代码、只共享规格与卡点；"20 倍"依赖测试覆盖的深度而非数量——先有可靠的对错裁判，才有放大的底气。

十、本轮研发与发布平台交互复盘

这一节记录 ComputerMonitor 本轮可以由仓库、构建产物和发布后台共同证明的结果。它补充了前文的方法论，也把“代码写完”“安装包可用”“构建已上传”“审核通过”“正式可售”这几个经常被混为一谈的状态彻底拆开。

截至本次更新：Android 2026.10.17.7 已发布到 FIR 内测页；iOS 2026.10.17（26101708）已在 App Store Connect 可见并完成审核物料准备；当前没有足够证据确认 iOS 已审核通过或正式可售，也没有当前鸿蒙工程与 AppGallery 回执可供核验。

1. 研发侧最终落地

本轮最关键的功能闭环包括：

• 每台设备独立保存连接方式、目标地址、板卡地址、云服务器和控制延迟；

• 16 位 UID 按奇偶路由到默认云转发节点，并允许设备级覆盖服务器配置；

• 32 路通道统一编辑名称与绑定 IP，首页显示继电器状态和主机在线状态；

• 开关机与强制关机延迟写入协议固定字节，范围统一为 1–255 秒；

• Android 和 iOS 统一产品名、Logo、日期版本规则和发布记录。

2. 测试与交付证据

• Android：debug / release 两个变体各 18 项单元测试通过，Lint 0 error，APK 可安装运行；

• 协议：对开关机与强制关机指令抓包，确认配置延迟写入正确字节；

• UI：在模拟器验证首页、设备设置、云转发和 32 路通道列表；

• iOS：Release Archive 成功，最终 Info.plist 包含 iPad 多任务要求的四个方向；

• 审核物料：已生成 iPhone 灵动岛中等显示屏、iPhone Duo 外屏/内屏、iPad 13 英寸截图，均为平台接受的精确尺寸且无 Alpha。

3. 与各发布平台的实际交互

4. App Store Connect 交互中真正踩到的坑

1. App 记录和 Bundle ID 必须先对齐。二进制使用 Pannet.RelayController.ComputerMonitor，后台记录也必须绑定同一标识；否则 Xcode 无法定位目标 App。

2. 登录 Xcode 不等于拥有可用的分发能力。曾出现 IDEDistribution.DistributionAppRecordProviderError，同时本机只有 Apple Development 身份。账号访问、协议接受、Apple Distribution 证书和钥匙串访问是不同检查项。

3. iPad 多任务会反向约束 iPhone App 的方向声明。只声明竖屏会收到 Invalid bundle；必须重新 Archive，并在最终产物中包含四个界面方向。旧 Archive 不会因为源代码已修复而自动变正确。

4. 上传成功后，构建也可能不出现在待提交版本里。后台最初是 1.0 准备提交，二进制却是 2026.10.17，版本不一致时构建不能被该版本选择。版本号与 CFBundleShortVersionString 对齐后才进入正确链路。

5. 构建号必须只增不减。方向修复后使用 26101708 重新 Archive，避免复用已经上传或处理过的构建号。

6. 截图尺寸以当前后台设备组为准。旧的 1284×2778 属于另一显示屏分组；当前补充的是 1206×2622、Duo 外屏 1398×2034、Duo 内屏 2007×2853 和 iPad 2064×2752。

5. 发布状态要用状态机管理

后续发布记录不再只写“成功/失败”，而是固定使用以下状态：

1. 源码已合并；

2. 测试与静态检查已通过；

3. 安装包或 Archive 已生成；

4. 产物已上传并被平台接收；

5. 构建处理完成并可选择；

6. 元数据、隐私、截图和审核备注已完成；

7. 已提交审核；

8. 审核通过；

9. 已发布且用户可下载。

这样可以避免“Xcode 显示上传完成”被误写成“App Store 已上线”，也可以避免 FIR 内测发布和正式商店发布使用同一个状态词。

6. 下一次可直接复用的发布清单

• 构建前锁定版本号、构建号、包标识和 Git 提交；

• 先跑协议测试、单测、Lint、Release 构建和模拟器截图；

• 发布前检查签名身份、账号权限、开发者协议和目标 App 记录；

• 上传后同时核对平台版本、构建处理状态和可选构建列表；

• 截图按后台实时显示的设备组准备，统一检查尺寸、格式和 Alpha；

• 硬件类 App 提前准备审核录屏或审核期可访问的测试设备；

• 任何平台反馈都回写为测试或发布门禁，禁止只在聊天记录里修一次。

最终结论：三端研发的难点不是写三份界面，而是同时管理协议一致性、构建环境、签名身份、平台状态和审核证据。真正可复制的能力，是让每次发布都能回答三个问题：现在处于哪个状态、证据在哪里、下一步由谁完成。