把 Android / iOS / 鸿蒙（HarmonyOS） 之间的工程迁移交给「大模型 + 工具」时，真正决定上限的往往不是单次对话写得多漂亮，而是：上下文从哪来、结果怎么验、每一轮提交怎么收口。本文从实践角度串一条链路：用 MCP 把仓库与外部能力接到 Agent 上，再用 Skill 把「怎么评转换质量、怎么总结变更、怎么对照需求、怎么看代码质量」固化成可重复执行的检查步骤。
说明：下文中的「转换」泛指在统一业务语义下，把一侧平台的实现（Kotlin/Swift/ArkTS 等）迁到另一侧或生成可对照骨架；不是宣称存在某种全自动、零成本的万能翻译器。MCP 与 Skill 解决的是流程与门禁，不是替代架构决策与人工验收。
1. 问题长什么样
典型诉求可以概括成四类：
| 方向 | 常见场景 |
|---|---|
| Android → iOS | 业务模块、网络层、存储、部分 UI 逻辑迁移到 Swift / SwiftUI |
| iOS → Android | 对照实现 Kotlin / Jetpack，对齐生命周期与线程模型 |
| 与鸿蒙互转 | ArkTS / ArkUI 与双端对齐能力差异（线程、权限、分布式、声明式 UI） |
| 多向迭代 | 同一需求在三端分支并行改，需要统一的「需求—实现—差异」视图 |
纯靠聊天窗口贴代码，很快会遇到：上下文截断、无法读全仓库、无法跑构建与静态检查、无法稳定对比两次提交的差异。这就是 MCP 要接进来的原因。
2. MCP 在这条链路里干什么
MCP（Model Context Protocol） 做的是：让模型通过标准协议调用「工具」和拉取「资源」，而不是把整台电脑或整库文件糊进提示词。
在跨端迁移/转换场景里，常见有价值的 MCP 能力包括（按优先级大致排序）：
- 代码与版本：读文件、搜索符号、
git diff/git log、关联 issue / 需求文档（若你们有对应 MCP 或 HTTP 封装）。 - 构建与检查：触发 Gradle /
xcodebuild/hvigor（鸿蒙）的非交互命令，采集编译错误与警告（需沙箱与安全策略）。 - 静态分析：对接 linter、格式化结果、甚至你们内部的二进制接口规范检查脚本。
- 知识库：设计文档、接口契约、历史 CR 结论——用 resource 或检索类工具喂给模型当约束，而不是当闲聊材料。
一张很粗的协作关系如下：
flowchart LR
subgraph agent["Agent（IDE / CLI）"]
A[对话与计划]
end
subgraph mcp["MCP 服务"]
G[Git / 文件]
B[构建与日志]
L[Lint / 测试]
D[需求与文档]
end
subgraph repo["工程仓库"]
R[Android / iOS / Harmony 模块]
end
A --> G
A --> B
A --> L
A --> D
G --> R
B --> R
L --> R
要点：MCP 负责「能持续拿到真实状态」；模型负责在约束下改代码。没有 MCP，跨端转换很容易变成「语法像、跑不通」的演示。
项目实践里 MCP 真正帮上忙的一块
在自己项目里跑下来，MCP 带来的提效很实在的一点，是支撑 大块功能在端之间的直接互转：网络、状态、一条完整业务链路里的多个类/模块，在接好仓库与构建/日志之后，Agent 能按「功能点」连续改，而不是只在聊天里贴片段。这和「整仓库一键翻译」不是一回事，但已经能覆盖不少成块迁移的工作。
转换落地之后，仍然需要人按需求自己多走几遍：主路径、边界条件、各端差异（权限、后台、埋点）往往要手动点一点才暴露。这里不必讳言——人工走查仍是验收的一环。差别在于：一旦发现问题，把报错、堆栈、复现步骤丢回给 AI，在 MCP 能读到工程上下文的前提下，修一轮的成本明显低于从零手改。整体仍是：大功能先转过去 → 人按需求验收 → 卡点再交给 AI 迭代，提效很多，但预期是「加速器」，不是「免验收」。
3. 转换工作流建议（可落地的一版）
下面是一条在团队里较容易推广的最小闭环，可按你们 CI 成熟度裁剪。
flowchart TB Q[对齐需求与范围] --> S[建立对照表：模块/接口/平台差异] S --> T[分支策略：按端或按业务垂直切] T --> C[大功能点互转 + 本地构建] C --> H[人按需求走查多遍] H -->|发现问题| F[把现象与日志交给 AI 修复] F --> C H -->|通过| V[门禁：Skill 清单跑一遍] V -->|不通过| C V -->|通过| P[PR：说明对照与风险]
- 对齐需求与范围：哪些类/模块要迁、哪些只做适配层、哪些必须行为一致（加密、存储、埋点）。
- 对照表：把「Android 类 / iOS 类型 / ArkTS 组件」映射到同一张表，避免三端各写各的命名与语义漂移。
- 分支：要么「一需求一分支三端子目录」，要么「按端拆分支但共享契约文档」——关键是 diff 可读、review 可追责。
- 大功能点转换 + 构建优先：先争取「能编过、主链路能跑」；报错与日志进 Agent 上下文（MCP），便于迭代大块改动而不是零散粘贴。
- 人工按需求走查：对照验收条目多点几遍；出问题再 提醒 AI 修（复现步骤 + 日志/截图），形成短闭环，而不是指望一次生成就结项。
- 门禁再走 PR：下文 Skill 部分把这一步拆成可执行检查项。
4. 用 Skill 做「质量门禁」：评什么、怎么评
Skill 在这里不是替你做代码审查的人，而是把「每次该怎么审」写成稳定流程，让 Agent 和人类用同一套清单。可以与 .cursor/rules 分工：规则偏常驻约束，Skill 偏「进入迁移任务时按需加载」。
下面四类，对应你提到的诉求。
4.1 评估「转换质量」（对照与语义）
建议在 Skill 里写清输入与输出：
- 输入：源端关键文件路径、目标端对应路径、需求编号或用户故事摘要。
- 输出：一张结构化表，至少包含：
- API / 行为对照：异步模型（Kotlin 协程 vs Swift async vs Promise）、主线程约束、错误类型是否可对应。
- 平台差异显式声明：例如 Keychain vs Keystore vs 鸿蒙安全存储、推送与后台任务差异。
- 已知妥协：哪些为赶进度采用临时方案，必须带
TODO(@owner, deadline)。
转换质量不是「看起来像」，而是「在约束下可维护且可验证」。
4.2 总结「每次提交的变更内容」
与其让模型自由发挥写 PR 描述，不如在 Skill 里规定：
- 固定调用
git diff/git show（通过 MCP）得到事实； - 再按模板归纳：文件级摘要 → 行为变化 → 风险点 → 测试建议；
- 禁止把「推测的业务意图」写进摘要当事实（除非文档里有依据）。
这样每一轮提交都有可比对、可审计的变更说明，也方便后面做需求完成度对照。
4.3 评估「需求完成度」
把需求拆成可勾选条目（验收标准），在 Skill 中要求：
- 每条对应 commit 或 PR 中的证据（实现位置、测试用例、或文档更新）；
- 未完成项必须标 阻塞原因（依赖、接口未就绪、平台能力缺失）。
没有结构化条目，「差不多做完了」无法复盘。
4.4 评估「提交代码的质量」
建议在 Skill 里分三层，由浅入深：
| 层级 | 内容示例 |
|---|---|
| 机械层 | 格式化、命名、明显死代码、错误处理分支是否完整 |
| 工程层 | 日志是否泄露敏感信息、并发与生命周期是否匹配平台习惯 |
| 语义层 | 是否与对照表一致、边界条件是否与源端测试意图对齐 |
静态检查能覆盖机械层与部分工程层；语义层需要测试或人工 spot check。Skill 里应写明：哪些必须跑命令、哪些允许仅人工。
5. 示例：Skill 里可以长什么样（片段）
下面是一段示意性的 Markdown 结构，便于你落到仓库里的 SKILL.md（真实项目请补全 name、description 与触发条件）。
1 | --- |
实际仓库里你会把路径、分支名、文档名换成自己的约定。
6. 局限与诚实边界
- MCP 不是魔法：没有构建环境、没有测试、没有清晰需求，再好的协议也只能产出「更像代码的文本」。
- 三端互转在工程上常卡在 能力不对等（系统服务、商店政策、声明式 UI 数据流），Skill 应要求把这些写进「已知妥协」，而不是一笔带过。
- 安全：能执行命令的 MCP 必须限权、审计；不要把生产密钥放进可被模型读取的资源。
7. 小结
- MCP 解决的是：让 Agent 稳定读仓库、跑检查、对齐事实，跨端转换才有可持续的闭环。
- Skill 解决的是：把 转换质量、变更摘要、需求完成度、代码质量 变成可重复执行的评审步骤，减少「同一类问题每次重新口头讲一遍」。
若你已经在用 Cursor / Claude Code 一类工具，优先落地的往往是：一个最小 MCP 集合（git + 终端或 CI 日志）+ 一个迁移审查 Skill；再逐步把需求条目与对照表接进来。和自己在项目里的做法一样：大功能点先互转、人按需求走查、问题再丢给 AI，比一上来追求「全自动三端零走查」更实在，也更容易稳定提效。
本文为工程流程向说明，具体工具链与 MCP Server 名称以各厂商文档为准；实施时请结合团队安全与合规要求。