---
source_url: "https://mp.weixin.qq.com/s/oMjsImv2x7sJAEPZBWpH5g"
source_title: "用 AI Skills 打通中间件迁移：定位服务从 Android 到鸿蒙的完整实践"
source_author: "开益（淘天集团-用户终端技术团队）"
source_publisher: "大淘宝技术"
source_date: "2026-06-15"
ingested: "2026-06-15"
sha256: "9d487ac0f52bf0e44e927c164e3a2969aef90fc0d68a43e74360fa1303392efb"
---

# 用 AI Skills 打通中间件迁移：定位服务从 Android 到鸿蒙的完整实践

> 本文以 Android 到鸿蒙的定位服务迁移为实战案例，深入剖析了 AI 辅助开发中通用智能与领域知识断层的根本矛盾，提出并验证了"AI + Skills"解决方案。该方案通过将 API 映射、枚举细节、回调差异及常见陷阱等隐性知识转化为结构化、AI 可读的 Skills 文档，明确了 AI 负责通用逻辑生成、Skills 提供精准领域知识的分工模型，实现了从"面向人"到"面向 AI"的知识传递转变。实践表明，相比纯 AI 翻译的低准确率和人工查源码的低效率，AI + Skills 模式不仅将单服务迁移时间缩短至 30 分钟且零编译错误，更在 154 个服务的规模化迁移中节省 25 小时，实现了知识的资产化、可复用与持续演进。

## 引言：AI 辅助开发的根本矛盾

又双叒叕经历从 0 到 1 翻译一个安卓应用到鸿蒙的需求，并且近期 Skill 的概念很火，想着能通过 Skill 真正的解决一些实际业务遇到的一些问题，所以开始着手维护一个鸿蒙依赖分析的 Skill，为了协助 Cursor 更好的理解端侧的二方包，最后得出了两个暴论：

1. 目前很多知识库是冗余的，随着模型能力越来越强，需要提供的业务知识库是需要减负的
2. 未来我们各种二方包的接入方式都会以 Skill 的形式提供，从面向人转到面向 AI

## 现状：AI 很强大，但不够"准确"

**场景还原**：向 AI 提问"帮我将 Android 定位服务迁移到鸿蒙"，AI 生成的代码看起来很专业，但存在枚举值不存在（`LocationExpires.ONE_MINUTE` 实际应为 `ONE_MIN`）、回调位置错误（回调不在 params 内而在 options 内）等低级错误，编译提示 13 个错误。

**开发者的困惑**：
- AI 不是能理解代码吗？为什么会犯这种低级错误？
- 文档明明存在，为什么 AI 不看文档？
- 第一次踩坑修好了，第二次还会踩，知识怎么沉淀？

## 本质：AI 的能力边界

**根本矛盾**：AI 拥有强大的通用智能（理解自然语言、生成代码、推理逻辑），但缺乏领域知识（特定平台的 API 细节、枚举值、回调约定）。通用智能与领域知识之间存在断层。

## 重新定义问题

### 这不只是"代码翻译"问题

**表面问题**：Android 代码如何迁移到鸿蒙？

**深层问题**：
1. **知识获取**：开发者如何快速掌握新平台的 API？
2. **知识传递**：团队如何避免重复踩坑？
3. **知识演进**：API 更新后如何快速同步？
4. **AI 协同**：如何让 AI 使用最新的领域知识？

### 这是一个"知识工程"问题

**软件工程的两大知识库**：
- 通用知识（编程语言、设计模式、算法）— AI 擅长
- 领域知识（平台 API、业务逻辑、历史坑点）— AI 不擅长

**知识的三个状态**：
1. **隐性知识**：在老员工脑子里（"这里要用 ONE_MIN，别用 ONE_MINUTE"）
2. **显性知识**：在文档里（但分散、滞后、难搜索）
3. **可执行知识**：在 Skills 里（结构化、可索引、AI 可读）

**AI + Skills 的价值**：将隐性知识转化为可执行知识，让 AI 在生成代码时自动引用准确的领域知识。

## AI + Skills 方法论

### 核心概念

**定义**：AI + Skills = AI 的通用能力 + 可执行的领域知识包

**类比理解**：AI 像是一个聪明但没经验的实习生，Skills 像是详细的操作手册。实习生有很强的学习能力，但没有操作手册就会犯错。Skills 就是让实习生快速上手的操作手册。

### 分工模型

- **AI 负责**：通用逻辑生成、代码结构、模式识别
- **Skills 提供**：精准的 API 映射、枚举值、回调约定、常见陷阱

### 工作流程（完整闭环）

1. **输入阶段**：AI 加载 Skills 获取领域知识
2. **生成阶段**：AI 使用 Skills 中的映射表生成准确代码
3. **验证阶段**：编译/测试验证准确性
4. **反馈阶段**：问题 → 提炼 → 更新 Skills
5. **沉淀阶段**：成功经验 → 记录到 Skills

## 实战案例：安卓定位服务 → 鸿蒙代码迁移

### 问题背景

**业务场景**：穿搭业务需要从 0 到 1 迁移到鸿蒙

**技术挑战**：
- 154 个 Android 服务需要迁移
- 每个服务涉及不同的 API 映射
- 团队中大部分人不熟悉鸿蒙 API

### 三种方式对比

#### 方式 1：纯 AI 翻译（❌ 快但不准）

操作：提问"帮我将 Android 的 LBSService 翻译到鸿蒙"

AI 生成的代码问题：
- `LocationExpires.ONE_MINUTE` ❌ 实际是 `ONE_MIN`
- `LocationExpires.FIVE_MINUTE` ❌ 实际是 `FIR_MIN`
- `LocationAccuracy.MID_MODE` ❌ 这个枚举不存在
- 回调位置错误（放在 params 内而非 options 内）

**结果**：编译错误 13 个，调试时间无法估计。根本原因：AI 没有准确的 API 文档。

#### 方式 2：查源码 + 人工修正（✅ 准但慢）

操作流程：打开 Mega Location 源码 → 查看实际枚举定义 → 逐个修正 AI 生成的错误 → 测试验证

实际枚举定义（非常反直觉）：
```
enum LocationExpires {
  ONE_MIN = "ONE_MIN",    // 不是 ONE_MINUTE
  SEC_MIN = "SEC_MIN",    // 不是 TWO_MINUTE (SEC = SECOND)
  THR_MIN = "THR_MIN",    // 不是 THREE_MINUTE (THR = THREE)
  FOR_MIN = "FOR_MIN",    // 不是 FOUR_MINUTE (FOR = FOUR)
  FIR_MIN = "FIR_MIN"     // 不是 FIVE_MINUTE (FIR = FIVE)
}
```

实际回调方式：回调在 `options` 对象内而非独立参数。

**结果**：编译错误 0 个，耗时 40 分钟。问题：知识留在开发者脑子里，下次还要重新查。

#### 方式 3：AI + Skills（✅ 又快又准）

**Step 1：构建 Skills** — 将 API 映射、枚举值、回调差异整理为结构化表格：

```
## 4. API 对比
### 4.1 LocationExpires 枚举值映射
| Android 常量 | 鸿蒙枚举 | 说明 |
|-------------|---------|------|
| "1m" | LocationExpires.ONE_MIN | ⚠️ 不是 ONE_MINUTE |
| "2m" | LocationExpires.SEC_MIN | SEC = SECOND，不是 TWO_MIN |
| "3m" | LocationExpires.THR_MIN | THR = THREE，不是 THREE_MIN |
| "4m" | LocationExpires.FOR_MIN | FOR = FOUR，不是 FOUR_MIN |
| "5m" | LocationExpires.FIR_MIN | FIR = FIVE，不是 FIVE_MIN |

⚠️ 不存在的枚举值（AI 经常错误生成）：
- ❌ ONE_MINUTE, TWO_MINUTE, FIVE_MINUTE
- ❌ TEN_MINUTE, MID_MODE

### 4.2 定位请求方法对比
| Android | 鸿蒙 | 差异说明 |
|---------|------|---------|
| LocationServiceBridge.requestLocation() | Location.requestLocation() | 回调方式不同 |

关键差异：Android 回调作为独立参数，鸿蒙回调在 options 对象内。
```

**Step 2：AI 使用 Skills** — 加载 Skills 后 AI 生成准确代码，编译零错误。

**结果**：编译错误 0 个，耗时 30 分钟。知识沉淀为可复用的 Skills。

### 规模化效果

**单个服务迁移效率**：
- 纯 AI 翻译：快（~5 分钟）但编译错误多（13 个），调试时间无法估计
- 查源码 + 人工修正：准但慢（~40 分钟）
- AI + Skills：又快又准（~30 分钟，零编译错误）

**154 个服务的总成本**：
- 纯 AI 翻译：约 102 小时（含调试）
- 查源码 + 人工修正：约 77 小时
- AI + Skills：约 52 小时

**节省时间**：102 - 77 = 25 小时（对比纯 AI 翻译）

**关键价值**：
- ⏰ 效率提升：节省 25 小时
- 📚 知识资产：154 个服务的迁移经验永久沉淀
- 🚀 团队加速：新人 0 学习成本
- 🔄 持续演进：API 更新后，只需更新 Skills

## 方法论推广

### 适用场景

AI + Skills 模式不只适用于代码迁移，而是适用于所有需要领域知识的 AI 辅助开发场景。

**通用模式**：有明确知识的场景 → 知识结构化为 Skills → AI 索引使用 → 提升质量和效率

### 构建 Skills 的原则

**原则 1：AI 友好的结构化**
- ❌ 不友好的文档：长篇文字描述，AI 难以索引
- ✅ AI 友好的文档：表格化、结构化、明确的映射关系

**原则 2：持续演进**
- Skills 更新流程：遇到问题 → 查看源码 → 提炼规律 → 更新 Skills → 发布版本 → 团队同步

**原则 3：分层组织**
- Skill 文档结构：从概述到 API 映射到常见陷阱到最佳实践

## 未来展望

### 从 Skills 到知识图谱
- 当前：文档化的 Skills
- 未来：知识图谱 — AI 可以理解模块间的依赖关系，自动推荐相关的 Skills，提供跨模块的最佳实践

### 从被动查询到主动建议
- 当前：开发者主动询问 AI
- 未来：AI 主动发现问题 — IDE 插件实时分析代码，匹配 Skills 中的常见陷阱，编译前预警

### 从静态文档到动态生成
- 当前：人工编写 Skills（工程师踩坑 → 查源码 → 编写文档 → 更新 Skills）
- 未来：AI 自动生成 Skills（Skills 永远最新，0 人工维护成本，覆盖所有场景）

### 从个人工具到组织能力
- 当前：个人/团队使用（开发者 → AI + Skills → 提升个人效率）
- 未来：组织级知识平台
- 终极愿景：新人入职第一天就能高效工作（AI 教学），老人离职后知识不流失（Skills 沉淀），组织智慧持续积累（每次踩坑都是资产）

## 结语：重新定义软件工程的知识传递

- **效率提升**：AI 的速度 + 领域专家的准确度
- **知识沉淀**：从"人脑记忆"到"组织资产"
- **持续演进**：每次踩坑都让 Skills 更完善
- **团队赋能**：新人 0 学习成本，老人不再重复劳动

---

**团队介绍**：本文作者开益，来自淘天集团-用户终端技术团队。团队服务于淘宝基础用户产品（首页、信息流推荐、消息聊天、搜索、我淘、用增、互动、内容等亿级用户规模产品），以先进的跨端框架和研发模式不断完善自己，探索端智能等创新机会，持续探索以 AI 为底座构建从需求到上线的端到端自动化与产品化能力。