摘要：本文记录一次 AI 开发工具链切换的完整决策过程——从 DevEco Code 切换到 Claude Code 自接入大模型。核心思路是"能力对等接入"而非"整体搬家"：通过 DevEco CLI 工具链 + 技能市场 + MCP 三段配置，把语法检查、编译修复、崩溃定位、文档检索等鸿蒙开发能力逐一补齐，并用 CLAUDE.md 规则文件固化项目记忆。切换后经十项验证清单全过、两个月实战检验，修复闭环自动化与项目记忆均成立，复杂架构改动的沟通成本虽有缓解但未根治。文末附能力边界表与三条心得，供同样在折腾 AI 工具链的开发者参考。

从 DevEco Code 到 Claude Code：一次工具链切换的完整决策

第一篇交代过：MarkPin 起步用的是 DevEco Code（鸿蒙官方 AI 编程工具，内置免费模型），中途切换到了 Claude Code 自接入大模型。当时只说了"个人工作流偏好"，这篇把这次切换完整拆开：怎么判断该不该换、怎么把鸿蒙开发能力在新工具链里补齐、怎么验证换完没断档。先说立场：两种工具各有所长，这篇讲的是决策方法，不是优劣对比。

一、问题描述：错位信号长什么样

换工具的念头不是拍脑袋，是几个具体症状攒出来的：

1. 复杂改动的理解错位。小改动（改个样式、加个按钮）都很顺；但牵扯多文件的架构级改动（比如渲染层重构），反复沟通后产出的方案仍然偏浅，返工率高；
2. 上下文断层。项目规范、架构约束、历史坑这些"项目记忆"没有稳定的注入通道，每次会话都要重新讲一遍；
3. 修复闭环依赖人工拼接。改码、编译、跑模拟器、看日志、查文档，每一步都要人工搬运，流水线搭不起来。

症状清单出来后，问题就变成了：这是模型能力问题、工具集成问题，还是我的使用方式问题？ 复盘的结论是三者都有份——但"项目记忆注入"和"修复闭环自动化"这两项，恰好是另一条工具链的强项。这就有了切换的假设。

二、决策方法：不搬家，做"能力对等接入"

定下方向后，第一个关键决策是：不迁移 DevEco Code 的内置工具，用 DevEco CLI 工具链 + 技能市场 + MCP 做能力对等替代。实测发现内置 Skill 编译在官方工具的二进制里没有独立目录，拷贝路线走不通；替代路线反而更干净。

第一步是做能力替代矩阵——把旧工具链的每项能力列出来，给新工具链找到等价物，找不到就明说"暂缓"：

旧工具链能力	新工具链等价物	说明
ArkTS 语法规范检查	MCP 语法检查（实时拦截）+ devecocli docs 检索	写错即报，不用等编译
编译错误修复	MCP 检查 + devecocli docs search 错误方案	报错→查文档→修复
崩溃定位	devecocli log --crash + 崩溃/内存分析类 Skill	日志进，根因出
ArkUI 组件知识	devecocli docs search/read（本地官方文档库）	写 UI 前先查 API
构建运行	devecocli build / run	命令行全链路
UI 视觉验证	暂缓（依赖多模态）	明确缺口，不假装能行

这张表的价值在最后一行：接入不是越多越好，把"暂时没有"诚实列出来，比假装全覆盖更能避免中途翻车。

三、解决代码：三段配置把能力真正接上

3.1 CLI 集成与项目级 MCP

第一段配置，十分钟完成 CLI 集成和语法检查 MCP 的项目级接入：

# 在 MarkPin 工程根目录
cd /Users/mac/HarmonyOS_APP/MarkPin

# ① 把 deveco-cli Skill 同时装给两个工具
devecocli init --agent opencode,claude-code

# ② 配置项目级 MCP（ArkTS/C++ 实时语法检查）
devecocli init --mcp --agent claude-code --project ./

第二条命令生成的项目级 .mcp.json 是这次切换的枢纽——语法检查不用编译就能拦截错误，实际项目里长这样：

{
  "mcpServers": {
    "deveco-mcp": {
      "type": "stdio",
      "command": "devecocli",
      "args": ["serve", "mcp"],
      "env": { "PROJECT_PATH": "/Users/mac/HarmonyOS_APP/MarkPin" },
      "enabled": true
    }
  }
}

项目级文件随 Git 提交，团队成员拉下来就是一致的环境——这解决的是"每个开发者自己配一遍、配出来都不一样"的老问题。

3.2 Skill 共享：一句话原理 + 两条命令

Skill 怎么在两个工具间共享？先说原理，一句话：Skill 不是"安装进工具"，而是"放进工具会扫描的目录"——每个工具在会话启动时扫描自己认的目录，读取每个 Skill 的 SKILL.md 完成注册。所以共享的标准做法是"真身 + 链接"：

# ① 下载到两个工具都认的标准目录
mkdir -p ~/.agents/skills
devecocli skills add --skill hmos-arkts-syntax-checker --path ~/.agents/skills

# ② 给 Claude Code 建符号链接（两个工具各重启一次会话生效）
mkdir -p ~/.claude/skills
ln -s ~/.agents/skills/<名> ~/.claude/skills/<名>

装完不是结束，还有一张迁移验证清单逐项过：双工具 /skills 可见、MCP 生效、devecocli build 产出 HAP、MCP check 对故意写错的 .ets 实时报错、devecocli run 拉起模拟器、崩溃日志可取、文档检索命中……十个验证项全部打勾，这次切换才算闭环。

3.3 把"项目记忆"固化成规则文件

最后一刀切中"上下文断层"：在项目根目录写 CLAUDE.md，把鸿蒙工具约定、工程不变式、文档维护规则全部固化。现在项目里实际生效的规则节选：

## 工具约定（鸿蒙开发，一律用 DevEco CLI）
- 构建：devecocli build（release 加 --build-mode release）
- 日志：devecocli log --level E --follow；崩溃定位 devecocli log --crash
- 语法检查：优先用 deveco-mcp 的 check（无需编译即可拦截错误）
- 文档检索：先 devecocli docs search "<关键词>" 再 read 命中项
- 组件知识：写 ArkUI 前 devecocli docs search "<组件名>" 确认 API 用法

## 质量要求
- 改动代码后必须跑 devecocli build 验证通过，再报告完成
- 崩溃/异常定位用 hmos-jscrash-analysis 等已装 Skill

这份文件的效果是规则从"每次口述"变成"每次自动在场"——AI 每次会话都带着同一套约束干活，构建验证、文档检索这些动作不再依赖我记着提醒。

四、验证与效果

切换后跑了完整验证清单（十项全过才收工），再之后是两个月的项目实战。体感层面的结论：

• 修复闭环自动化成立了：语法检查实时拦截 + 崩溃分析 Skill + 规则文件里的"构建通过才算完成"，让"改码→编译→回归→记录"真正连成了流水线（下一篇的 39 个 BUG 修复就是这条流水线的产物）；
• 项目记忆成立了：CLAUDE.md + 文档体系（PROGRESS/PROBLEM-LOG 等）让每次会话都有上下文，不用从零讲起；
• 当初的错位症状大幅缓解，但不是消失——复杂架构改动的沟通成本依然存在，这是要把需求拆碎喂的原因（第一篇讲过），工具只放大方法，不替代方法。

五、能力边界表

事项	AI/工具链表现	我的结论
CLI 集成与 MCP 接入	顺利，十分钟级	官方 CLI 的开放程度决定了这条路能走通
Skill 双工具共享	可行，但目录规范要手动对齐	"真身+链接"是通用解，符号链接进 Git 有平台坑
项目记忆（规则文件）	效果显著	规则文件是最便宜的生产力，没有之一
复杂架构改动的沟通	有缓解，未根治	工具切换不解决"需求拆分"，那是使用方法问题
成本控制	可行	多通道错峰是个人开发者的现实选择（细节不展开）

六、三条心得

1. 换工具的正确姿势是"能力对等接入"而不是"整体搬家"。先画能力矩阵、标出缺口、再逐项接，缺什么补什么，永远知道自己的工具链短板在哪；
2. 配置即资产。MCP 配置、Skill 目录、规则文件这三样东西固化下来，换任何一台机器、任何一个协作者都能复现同一套环境；
3. 切换决策要基于症状清单，不是基于口碑。别人说哪个工具好不重要，你的项目里具体哪类任务反复卡壳，才是决策依据。

---

如果你也在折腾 AI 开发工具链，或者想看 MarkPin 后续，关注专栏。