最近 Claude Code 和 Skills 这两个词在 AI 编程社区里几乎快被说烂了。各种前端开发 skills、superpower skills 的教程满天飞我也跟着折腾了好一阵。但真正让我决定动手换工具的其实是一次很日常的崩溃我想在一个旧项目里用 Claude Code 跑一个文档生成 skill结果光是配置模型服务、处理环境变量和权限就花了一个多小时活还没开始干人先被劝退了。所以当 CodeBuddy Code 以“国内首款支持 Skills 的编程助手”的姿态开始推广时我第一时间装了一版花了两天时间做了比较系统的实测今天就把这份体验原原本本写出来。这篇测评主要面向两类人一类是正在用或想用 Skills但不太想折腾环境配置的开发者另一类是正在纠结要不要从 Claude Code 迁移工具链的朋友。文章里我会尽量把能复现的步骤、命令和目录结构都贴出来也会把官方文档里不会写的坑讲清楚。如果看完你决定自己试至少能少走一半弯路。1. Skills 到底解决什么问题一个被忽略的核心协议很多人第一次听到 Skills下意识会联想到 IDE 插件这其实是个误会。插件是绑定在编辑器里的而 Skills 是一套基于 Markdown 文件的交互协议属于 Agent 世界的“专业知识包”。要理解 CodeBuddy Code 为什么要兼容它得先把这个底层的机制搞明白。1.1 SKILL.md 是一份“给模型看的说明书”一个典型的 skill文件结构长这样my-skill/ ├── SKILL.md └── scripts/ └── fetch_data.pySKILL.md 的开头有一段 YAML 格式的 frontmatter--- name: my-skill description: 用稳定的参数读取外部数据并在本地生成摘要 ---后面跟着的是正文指令告诉模型应该分哪几步完成这类任务、调用哪些脚本、遵守什么输出规范。这套设计最巧妙的地方在于它不是写给人看的文档而是由 agent 在任务匹配时动态读取、注入到上下文里的“运行时知识”。举个例子当你在终端里说“帮我生成一个移动端登录页”代码助手会先去扫描已知 skill 的 description如果发现某个 skill 描述里包含“移动端布局规范”它就会把那个 SKILL.md 的内容加载进来然后按照里面的规范来写代码。整个过程对用户来说不可见但输出的质量会明显不一样——比光靠模型“自由发挥”要稳定得多。理解了这个机制你就会明白为什么大家都在抢着做 skills 生态。Skills 不是某个工具独有的能力而是一套近乎通用的“文件协议”。只要一个新工具能解析 SKILL.md 的结构、能在合适的时机把内容注入上下文理论上就可以复用社区里已有的海量 skill 资源。1.2 资产可迁移这件事才是兼容的真正价值为什么我会特别在意“支持 Skills”而不是“内置多少功能”因为 skills 社区已经积累了大量高质量的技能包。有专门做前端 UI 规范的设计 skill有整合了各种工作流的 superpower skills有竞赛建模用的分析 skill甚至有人专门写了 LaTeX 排版 skill。这些资源我用 Claude Code 的时候整理过一批如果换工具就要全部重写那迁移成本就太高了。所以我在测试 CodeBuddy Code 时第一优先级不是看它的模型有多强而是看它能不能直接把我本地~/skills/目录里的东西读进来。如果这一步能跑通说明工具的可迁移性是有保障的——它不是在另起炉灶而是接入了现有生态。事实上CodeBuddy Code 在目录结构上参考了 Claude Code 的约定这让我对后面的测试更有信心。2. 动手之前先弄清 CodeBuddy Code 和 Claude Code 的定位差在哪作为一个习惯“先看定位再动手”的人我在安装之前花了一点时间研究 CodeBuddy Code 的产品设定。结论是它虽然对标 Claude Code但切入角度不太一样。2.1 完全不同的开箱体验Claude Code 是一个很强大的命令行编程代理但它在使用上有明显的“DIY 属性”你需要自己准备模型服务的 API Key、自己配置各种环境变量、自己处理权限策略。对于熟悉这套玩法的开发者来说这些都不是问题但如果你只是想快速解决一个编码任务这些前置工作会非常劝退。CodeBuddy Code 的做法更“国内互联网产品”一些安装之后用手机扫码登录就能直接用内置的模型服务。我的理解是它想做的不是“一个更强的前沿实验工具”而是“一个普通人也能轻松上手的 Agent 编程助手”。从官方宣称“国内首款支持 Skills”这句话也能看出来它瞄准的是那些已经在用或想用 Skills但又受不了 Claude Code 配置成本的人。2.2 功能边界和使用场景的差异我在测试前整理了一张对比表可以比较直观地看出两者的差异维度CodeBuddy CodeClaude Code模型服务内置国内模型扫码即用需自带 API Key 或自建网关Skills 兼容支持目录结构兼容原生支持生态最成熟中文交互自然默认符合中文习惯良好但需自行调优终端命令执行支持有确认机制支持权限策略灵活插件/扩展早期生态在增长丰富社区脚本多上手成本低几分钟就能开始较高需配置模型深度定制有限强可玩 spin 定制这张表想表达的核心意思是如果你需要的是一个“能深度折腾的瑞士军刀”Claude Code 仍然有优势但如果你要的是一个“开箱即用、能继承既有 skills 资产”的生产力工具CodeBuddy Code 的定位明显更合适。3. 安装与第一个任务从命令行到跑通 Agent说再多都不如直接跑一遍。我分别在 Linux 和 Windows 环境下做了安装测试这里以 Linux 为例Windows 的流程基本一致。3.1 一条命令装完扫码登录官方文档提供了一条安装命令以终端执行为准curl -fsSL https://codebuddy.dev/install.sh | bash安装完成后在终端输入codebuddy会进入引导流程屏幕上会出现一个二维码用手机 App 扫码确认登录。这一步比我想象中顺滑。登录成功后它会提示选择一个默认模型我直接用了内置模型服务没有再配置任何额外 Key。第一印象是 TUI 界面和 Claude Code 处于同一个交互范式底部是输入框主区域是对话流支持/开头的一系列斜杠命令。整体风格偏简洁没有 IDE 那种花哨的侧边栏注意力基本都放在对话和工具调用上。3.2 第一个任务让它给项目写 README为了快速测试它的 Agent 能力我直接挑了一个有 30 个文件的中型项目输入不要只写模板。先扫描项目结构和核心模块的职责再决定 README 的大纲。这里有一个值得注意的细节它没有立刻回答而是先连续调用了read_file和list_dir工具扫描了项目里的关键文件包括package.json、入口文件和几个核心模块然后才开始生成 README。最终产物不是空话套话而是真的按照模块依赖关系组织的文档连安装命令和启动参数都从源码里核对过。这可能是我第一次觉得“Agent 在认真看我的代码而不是在猜”。相比之下之前用普通聊天式助手时经常需要我手动把文件内容粘进去。这种差异用一句话总结就是CodeBuddy Code 默认把“上下文获取”这件事主动承担了用户不需要自己喂上下文。3.3 权限确认机制的好处和代价测试过程中我注意到每当 agent 要执行 bash 命令、写文件或者改动代码时终端里都会出现确认提示需要按一下确认才会继续。这个机制在跑简单任务时会感觉多了一步但在跑复杂任务时非常安心——至少你知道它在干什么。如果你跟我一样喜欢批量跑任务它也可以设置自动允许规则让某些命令不经过确认直接执行。这个后面踩坑部分会细说先提醒一句别图省事把所有命令都放开了。4. CodeBuddy Code 加载 Claude Code skills 目录的实际验证这是全篇测评最核心的部分。我不关心官方怎么宣传只关心一件事我本地已有的 Claude Code skills 目录能不能被它直接读取并真正发挥作用。4.1 测试环境和目录结构我本地原本就有这样一个 skills 目录~/skills/ ├── frontend-design/ │ ├── SKILL.md │ ├── rules/ │ │ └── layout-rules.md │ └── templates/ │ └── mobile-page.html ├── superpowers/ │ ├── SKILL.md │ └── modules/ └── latex-layout/ ├── SKILL.md └── scripts/ └── to_latex.py其中frontend-design是我从社区找来的前端开发 skillsuperpowers是社区很火的一套工作流整合包latex-layout是自己写的小工具负责把 Markdown 转成 LaTeX 片段。这三个各有代表性一个是社区维护型一个是整合型一个是个人定制型。CodeBuddy Code 支持直接复用 Claude Code 的 skills 目录。最方便的做法是建一个软链接让新工具直接指向原有目录# 以当前版本官方文档为准这里展示的是通用做法 mkdir -p ~/.codebuddy ln -s ~/skills ~/.codebuddy/skills软链接的好处是以后在原来的目录里改 skill两边都生效不需要维护两份文件。4.2 实测一前端设计 skill 能否被正确触发我给出的测试 prompt 是使用 frontend-design 技能帮我生成一个移动端登录页的完整 HTML 文件。 要求符合该技能里的布局规范不引入外部框架。几秒钟后我打开了 verbose 日志能看到它确实主动检索了frontend-design的 SKILL.md 内容并注入到了上下文。这一步本身就是关键如果工具不支持 skills 解析它要么无视“技能”这个词要么只会把技能名当成普通文字理解。生成结果符合预期。它输出的 HTML 采用了技能里要求的移动端视口配置遵循了模板中“不使用外部框架”和“CSS 类名带前缀”的约定注释风格也和 SKILL.md 里的要求一致。实测说明社区里的前端开发 skill 能直接跑起来语义兼容这一块没有什么障碍。4.3 实测二个人定制 skill 是否会被正确执行第二个测试用了我的latex-layout技能。我给了它一个 Markdown 格式的技术文档片段要求“按照 latex-layout 技能的规则转换成 LaTeX”。一个容易被忽略的细节是这个 skill 不是光靠提示词完成的它里面有实际的脚本逻辑。真正让我满意的是CodeBuddy Code 确实调用了脚本而不是“假装遵守”指令。它在生成文件前先执行了scripts/to_latex.py把我输入的内容转成了带章节结构的.tex片段再在对话里展示出来。这说明它对 SKILL.md 中标注的脚本调用部分是有执行能力的不是只读文本而已。4.4 兼容性的边界并不是 100% 等价虽然基础资产能复用但我在测试中也发现了一些边界。比如 SKILL.md 的 frontmatter 里如果写了 Claude Code 特有的扩展字段CodeBuddy Code 会静默忽略不会报错但对应功能也就失效了。结论是常规的 skills 资产可以无缝迁移但如果你在 skill 里用了一些非常高级的定制钩子迁移后还是要检查和调整。好在社区里 90% 的 skill 都是用基础字段写的影响面不大。5. 三个日常场景下的实测表现工具好不好用不能只看广告要在真实的日常开发场景里过招。我设计了三个场景分别覆盖文档、调试和重构这些是日常开发中出现频率最高的环节。5.1 场景一给老项目补文档第一个场景是给一个半年没维护的项目写 README。我没有给它任何额外的上下文只告诉它“先看代码再动手”实际表现我已经在前面说过了——它会先扫描结构再生成文档。这里还有一个不错的细节它生成完 README 之后自己又跑了一遍git diff确认修改的文件列表和预期一致然后把变更摘要写进了对话里。这个行为让我觉得它有一点“做事闭环”的意识——不是执行完就结束而是会检查自己的产出。5.2 场景二修复一个编译错误第二个场景我准备了一个故意写错的 TypeScript 项目。我输入运行测试查看报错然后修复问题确保再跑一次能通过。整个过程中它在终端里执行了npm run test读到了报错信息定位到类型定义文件的错误修改了源码再重新运行测试。整个过程大约不到三分钟中间没有需要我插手的地方。测试结果说明它在“读报错→改代码→再验证”这个循环上是可用的。这对实际开发很重要——很多 AI 编程助手能改代码但不会主动运行验证导致输出看着对、一跑就崩。5.3 场景三跨文件重构第三个场景更有挑战性我让它把utils.ts里散落的几个工具函数抽取到一个新的src/helpers/模块并更新所有引用文件。这个任务的关键点在于它需要有全局视野不能只改一个文件就完事。实测结果是它通过全局搜索定位了所有import引用自动创建了新文件修改了引用的路径最后跑了一遍测试确认功能没被破坏。下表是我对三个场景的横向评价场景完成度需要人工干预的次数耗时备注补 README高02 分钟左右扫描结构后自行生成修编译错误高03 分钟内自动验证修复结果跨文件重构中高1需确认改动范围5 分钟左右引用定位准确但改动较多时希望人工确认第三个场景之所以不是“高”是因为跨文件重构涉及面广它在中途停下来问我是否确认修改某个依赖了公共函数入口的文件。我的评价是这个确认有一定打扰但属于合理谨慎总比闷头改了导致线上出问题强。6. 和 Claude Code 比真实体验上的强项与短板标题里写着“替代 Claude Code”作为测评者我必须冷静地看看它在哪些维度上真的能替代哪些维度只是宣传话术。6.1 真正的强项降低使用门槛不抢已有配置CodeBuddy Code 最让我认可的一点是它把 Agent 编程助手的核心能力保留了下来同时把门槛降到很低。扫码登录、内置模型、默认中文友好这三件事打包在一起的效果就是“一个普通开发者也能在十分钟内跑起来”。我不需要先搞懂模型配置的来龙去脉也不需要处理一堆 Key 和权限文件。同时它在 skills 兼容上确实花了心思我愿意把手上已有的 Claude Code skills 资产直接交给它跑。对于很多想用 Skills 但被配置劝退的人来说这种“继承现成资源”的方式比从零搭建友好太多。6.2 不能回避的短板深度定制还不够Claude Code 经过这么多轮迭代在系统提示词定制、工具调用策略、复杂工作流的可玩性上都形成了自己的生态。CodeBuddy Code 作为一个新进入者在这些方面还有差距。比如我在测试中发现它对全局系统提示词的控制精细度不如 Claude Code某些非常细致的行为偏好没法完全通过配置文件表达。如果你是一个喜欢把 agent 行为“调教”到极致的人你可能还是会把 Claude Code 留在工具箱里作为备选项。6.3 我的建议什么情况下换什么情况下别换根据实测我给出这样的建议适合换的场景你以中文项目为主希望开箱即用手里已经有 Claude Code 的 skills 资源不想重新折腾配置。谨慎换的场景你需要非常前沿的实验性模型特性或者深度依赖 Claude Code 的某些定制脚本和复杂 spin 配置。建议双开的场景日常主力用 CodeBuddy Code 跑任务把 Claude Code 留给需要深度实验的场景。这个结论不是和稀泥而是基于两天实测的真实感受。它确实不是无死角的“替代”但在一大块真实场景里已经可以独当一面了。7. 踩坑实录文档里没写但一定会遇到的细节这一节是真正有信息量的部分。官方文档能告诉你“支持 Skills”但不会告诉你这些在实际使用中会绊倒人的细节。7.1 坑一skills 目录的搜索优先级我一开始把 skills 放在了项目目录下的.codebuddy/skills里但发现子目录中的 skill 没有被加载直接调到上一个配置目录才生效。后来在 verbose 日志里看到它的搜索路径是有优先级顺序的。遇到 skill 没被加载时别急着怀疑兼容性。先在终端里执行/codebuddy skills list看当前实际可见的 skill 列表再对照你的目录结构大概率就能定位问题。不同版本的默认路径可能不一样以当前版本实际行为为准。7.2 坑二自动允许规则千万别一刀切我在批量跑任务时为了省事把bash命令的所有确认规则都关掉了。结果一次重构过程中它执行了一条我本意不想执行的文件删除命令。虽然最终没有造成损失但这个经历让我一身冷汗。后来我的做法是只对明确的测试命令放开自动执行比如npm run test、python -m pytest这类低风险命令。文件删除、批量移动这类可能破坏性的操作始终保持待确认状态。这个策略推荐给所有人。7.3 坑三中文环境下的注释语言“漂移”测试期间有一次生成前端代码逻辑完全正确但注释突然全变成了英文。排查之后发现是我的 skill 模板里存在英文示例代码模型在长上下文里受到了示例影响自动切换了注释语言。解决方式很简单在 SKILL.md 或系统提示词里明确写一句“所有新增注释统一使用中文”就不会再出现这个漂移问题了。这个坑比较隐蔽因为它不是功能层面的报错而是风格层面的一致性失控不仔细看不会发现。7.4 通用的排障思路最后分享一个排查套路遇到行为异常时先开 Verbose 日志模式然后重复一次操作重点看三个地方——模型有没有加载预期的 skill、模型调用了哪些工具、上下文里有没有被无关内容占满。绝大部分“agent 不听话”的问题在这三个环节里都能找到根因。如果你平时习惯直接用不怎么看日志那这几乎是我最想让你带走的一个经验modern agent 工具的问题80% 能靠看日志自诊断。我自己测完这两天之后的体会是像“替代 Claude Code”这种口号短期不用太当真真正有意义的是它把 Skills 这套机制带了进来并且用自己的方式降低了使用门槛。如果你手头已经有 Claude Code 的 skills 目录不妨也开一个测试项目实际跑一跑看看哪些 skill 能直接复用哪些需要微调。工具之间怎么选最后还是要回到你的真实场景里决定。
 实战指南)
