MCP 与 Skill 驱动下的跨端代码转换与质量门禁

把 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 能力包括（按优先级大致排序）：

1. 代码与版本：读文件、搜索符号、git diff / git log、关联 issue / 需求文档（若你们有对应 MCP 或 HTTP 封装）。
2. 构建与检查：触发 Gradle / xcodebuild / hvigor（鸿蒙）的非交互命令，采集编译错误与警告（需沙箱与安全策略）。
3. 静态分析：对接 linter、格式化结果、甚至你们内部的二进制接口规范检查脚本。
4. 知识库：设计文档、接口契约、历史 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：说明对照与风险]

1. 对齐需求与范围：哪些类/模块要迁、哪些只做适配层、哪些必须行为一致（加密、存储、埋点）。
2. 对照表：把「Android 类 / iOS 类型 / ArkTS 组件」映射到同一张表，避免三端各写各的命名与语义漂移。
3. 分支：要么「一需求一分支三端子目录」，要么「按端拆分支但共享契约文档」——关键是 diff 可读、review 可追责。
4. 大功能点转换 + 构建优先：先争取「能编过、主链路能跑」；报错与日志进 Agent 上下文（MCP），便于迭代大块改动而不是零散粘贴。
5. 人工按需求走查：对照验收条目多点几遍；出问题再 提醒 AI 修（复现步骤 + 日志/截图），形成短闭环，而不是指望一次生成就结项。
6. 门禁再走 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 与触发条件）。

---
name: cross-platform-migration-review
description: Android/iOS/鸿蒙互迁时的对照审查与提交摘要
---

## 何时使用
用户提到跨端迁移、对照实现、ArkTS/Kotlin/Swift 同步修改时加载本 Skill。

## 步骤
1. 用 MCP 读取当前分支相对 main 的 diff 与最近 N 次提交信息。
2. 对照 `docs/platform-mapping.md`（若存在）检查涉及模块是否登记。
3. 按「转换质量 / 变更摘要 / 需求条目 / 代码质量」四节输出，缺信息则列出待补充问题。
4. 若涉及鸿蒙，显式检查线程与权限相关 API 是否与文档一致。

## 输出模板（节选）
### 变更摘要（基于 diff）
- 范围：...
- 行为变化：...
- 风险：...

### 需求完成度
| 条目 | 状态 | 证据 |

实际仓库里你会把路径、分支名、文档名换成自己的约定。

---

6. 局限与诚实边界

• MCP 不是魔法：没有构建环境、没有测试、没有清晰需求，再好的协议也只能产出「更像代码的文本」。
• 三端互转在工程上常卡在 能力不对等（系统服务、商店政策、声明式 UI 数据流），Skill 应要求把这些写进「已知妥协」，而不是一笔带过。
• 安全：能执行命令的 MCP 必须限权、审计；不要把生产密钥放进可被模型读取的资源。

---

7. 小结

• MCP 解决的是：让 Agent 稳定读仓库、跑检查、对齐事实，跨端转换才有可持续的闭环。
• Skill 解决的是：把 转换质量、变更摘要、需求完成度、代码质量 变成可重复执行的评审步骤，减少「同一类问题每次重新口头讲一遍」。

若你已经在用 Cursor / Claude Code 一类工具，优先落地的往往是：一个最小 MCP 集合（git + 终端或 CI 日志）+ 一个迁移审查 Skill；再逐步把需求条目与对照表接进来。和自己在项目里的做法一样：大功能点先互转、人按需求走查、问题再丢给 AI，比一上来追求「全自动三端零走查」更实在，也更容易稳定提效。

---

本文为工程流程向说明，具体工具链与 MCP Server 名称以各厂商文档为准；实施时请结合团队安全与合规要求。