从 DevEco Code 到 Claude Code：一次工具链切换的完整决策
第一篇交代过：MarkPin 起步用的是 DevEco Code（鸿蒙官方 AI 编程工具，内置免费模型），中途切换到了 Claude Code 自接入大模型。当时只说了"个人工作流偏好"，这篇把这次切换完整拆开 ：怎么判断该不该换、怎么把鸿蒙开发能力在新工具链里补齐、怎么验证换完没断档。先说立场：两种工具各有所长，这篇讲的是决策方法，不是优劣对比。
一、问题描述：错位信号长什么样
换工具的念头不是拍脑袋，是几个具体症状攒出来的：
- 复杂改动的理解错位。小改动（改个样式、加个按钮）都很顺；但牵扯多文件的架构级改动（比如渲染层重构），反复沟通后产出的方案仍然偏浅，返工率高；
- 上下文断层。项目规范、架构约束、历史坑这些"项目记忆"没有稳定的注入通道，每次会话都要重新讲一遍；
- 修复闭环依赖人工拼接。改码、编译、跑模拟器、看日志、查文档，每一步都要人工搬运，流水线搭不起来。
症状清单出来后，问题就变成了：这是模型能力问题、工具集成问题，还是我的使用方式问题？ 复盘的结论是三者都有份------但"项目记忆注入"和"修复闭环自动化"这两项，恰好是另一条工具链的强项。这就有了切换的假设。
二、决策方法：不搬家，做"能力对等接入"
定下方向后，第一个关键决策是：不迁移 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 的项目级接入：
bash
# 在 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 是这次切换的枢纽------语法检查不用编译就能拦截错误，实际项目里长这样：
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 完成注册。所以共享的标准做法是"真身 + 链接"：
bash
# ① 下载到两个工具都认的标准目录
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，把鸿蒙工具约定、工程不变式、文档维护规则全部固化。现在项目里实际生效的规则节选：
markdown
## 工具约定（鸿蒙开发，一律用 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 有平台坑 |
| 项目记忆（规则文件） | 效果显著 | 规则文件是最便宜的生产力，没有之一 |
| 复杂架构改动的沟通 | 有缓解，未根治 | 工具切换不解决"需求拆分"，那是使用方法问题 |
| 成本控制 | 可行 | 多通道错峰是个人开发者的现实选择（细节不展开） |
六、三条心得
- 换工具的正确姿势是"能力对等接入"而不是"整体搬家"。先画能力矩阵、标出缺口、再逐项接，缺什么补什么，永远知道自己的工具链短板在哪；
- 配置即资产。MCP 配置、Skill 目录、规则文件这三样东西固化下来，换任何一台机器、任何一个协作者都能复现同一套环境；
- 切换决策要基于症状清单，不是基于口碑。别人说哪个工具好不重要，你的项目里具体哪类任务反复卡壳，才是决策依据。
如果你也在折腾 AI 开发工具链，或者想看 MarkPin 后续，关注专栏。