从 DevEco Code 到 Claude Code:一次工具链切换的完整决策
文章目录从 DevEco Code 到 Claude Code一次工具链切换的完整决策一、问题描述错位信号长什么样二、决策方法不搬家做能力对等接入三、解决代码三段配置把能力真正接上3.1 CLI 集成与项目级 MCP3.2 Skill 共享一句话原理 两条命令3.3 把项目记忆固化成规则文件四、验证与效果五、能力边界表六、三条心得摘要本文记录一次 AI 开发工具链切换的完整决策过程——从 DevEco Code 切换到 Claude Code 自接入大模型。核心思路是能力对等接入而非整体搬家通过 DevEco CLI 工具链 技能市场 MCP 三段配置把语法检查、编译修复、崩溃定位、文档检索等鸿蒙开发能力逐一补齐并用CLAUDE.md规则文件固化项目记忆。切换后经十项验证清单全过、两个月实战检验修复闭环自动化与项目记忆均成立复杂架构改动的沟通成本虽有缓解但未根治。文末附能力边界表与三条心得供同样在折腾 AI 工具链的开发者参考。从 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 的项目级接入# 在 MarkPin 工程根目录cd/Users/mac/HarmonyOS_APP/MarkPin# ① 把 deveco-cli Skill 同时装给两个工具devecocli init--agentopencode,claude-code# ② 配置项目级 MCPArkTS/C 实时语法检查devecocli init--mcp--agentclaude-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 skillsadd--skillhmos-arkts-syntax-checker--path~/.agents/skills# ② 给 Claude Code 建符号链接两个工具各重启一次会话生效mkdir-p~/.claude/skillsln-s~/.agents/skills/名~/.claude/skills/名装完不是结束还有一张迁移验证清单逐项过双工具/skills可见、MCP 生效、devecocli build产出 HAP、MCP check 对故意写错的.ets实时报错、devecocli run拉起模拟器、崩溃日志可取、文档检索命中……十个验证项全部打勾这次切换才算闭环。3.3 把项目记忆固化成规则文件最后一刀切中上下文断层在项目根目录写CLAUDE.md把鸿蒙工具约定、工程不变式、文档维护规则全部固化。现在项目里实际生效的规则节选## 工具约定鸿蒙开发一律用 DevEco CLI - 构建devecocli buildrelease 加 --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 后续关注专栏。

相关新闻

最新新闻

日新闻

周新闻

月新闻