文章首先分析了 AI 编程工具形态的变化，指出 CLI 工具因能深度介入软件工程中占 70% 时间的流程环节（如拆任务、CI/CD、部署等），正逐渐取代传统 IDE 插件成为主流。随后，作者重点评测了腾讯推出的 Claude Code 平替产品——CodeBuddy Code。该工具支持国内外多种大模型，具备项目初始化分析（生成 CODEBUDDY.md）、复杂需求分阶段拆解、MCP 协议集成（如 Figma 联动）、SubAgent 自定义以及 Skills 扩展等核心功能。实测显示，CodeBuddy Code 能够理解 5 万行规模的跨语言项目逻辑，并能自动修复编译错误和生成测试代码。作者认为，此类工具体现了腾讯内部的工程方法论，是开发者提升端到端交付能力的利器。
最近半年，我身边的工程师朋友们经历了一次集体迁徙。他们从各种花哨的 IDE 插件，转向了以终端为主的 AI 编程工具。比如 Claude Code。
这件事其实多少有点让我困惑。
为什么 CLI 会成为主流？
你想啊，我们花了几十年时间，把计算机从黑底白字的命令行，进化到图形界面、可视化交互。现在 AI 时代来了，怎么又回去了？这不是开历史倒车吗？
最近我逐渐想明白了这事。
先问你一个问题：一个中大型团队，写代码这件事，大概占整个软件工程的多少时间？
你可能会说，怎么也得六七成吧，毕竟程序员嘛，不写代码写什么。
答案是 30%左右。
剩下 70%的时间花在哪儿了？花在流程上。
你想想一个需求从提出到上线要经历什么：
有人提需求，得拆任务吧；拆完任务，得开分支吧；代码写完了，得发起评审吧；评审意见来来回回改几轮。
改完了提交，CI 跑挂了，得排查修复吧；终于合并了，还得生成发布说明、部署到各个环境、观察线上有没有问题。
这一串下来，写代码那点时间，其实只是中间一小截。
如果 AI 只是 IDE，它只能改代码。 但如果 AI 是 CLI 工具，我们就可以在 pipeline 里直接调用它。
CLI 可以做的事情远远大于 IDE，这也是为什么 IDE 里总会集成 CLI 的原因。
Claude Code 的平替
除了 Claude Code 之外，国内几家公司也都做了同类产品。今天我想花时间测评下腾讯的 CodeBuddy Code。
安装的话，很简单。直接敲下面命令，如果权限不够，记得加 sudo。
npm install -g @tencent-ai/codebuddy-codeCodeBuddy Code 目前分国际版和国内版，国际版集成了 Codex、Gemini 3.0 等头部 Coding 模型，新用户前两周有免费的 Token 可以用。
国内版本集成了 DeepSeek、GLM、Kimi 等模型，目前国内版本完全免费。
在网上搜了下，看到有人说，CodeBuddy Code 的优势是它为复杂项目专门做了优化，并且腾讯内部也在用。
所以，我就拿我们公司现有的一个项目来试试。
我理解腾讯做这事有几个优势：
第一，他们本身就是一个软件研发大厂，可以把内部在复杂项目上的思考和方法论，融合到这款产品里。
第二，和腾讯云深度打通。开发工具和云资源处在同一体系之下，从写代码、调试、测试，到部署上线、扩容和运维，整条链路在一个闭环中完成。
开发、构建、发布形成连续流程，减少系统之间的割裂感。
接下来开干！
Reminder 是我们之前做的一个智能提醒类的产品，用来帮助用户管理生日、纪念日、倒计时等。
前端使用的是 Flutter，后端是 Go。整体加起来，有 5 万行代码。
可上下滑动查看
我们就围绕这个产品，实测腾讯的 CodeBuddy Code。
第一步，我们先初始化项目。在 CodeBuddy Code 中，输入 /init 命令。录了个屏，兄弟们看看。
CodeBuddy Code 分析完当前项目后，会创建一个叫 CODEBUDDY.md 的文件，里面包含项目概述、目录结构、核心数据流这些信息。
这一步很关键。
你可以把它理解成给 AI 看的 README，加上架构说明，再加上团队规范。
目录怎么组织的，模块之间怎么调用的，数据是怎么流转的，构建和运行依赖哪些脚本。
这些东西平时都散落在代码各处，或者只存在于老员工的脑子里。现在整理成一份文档，AI 对项目就有个整体概念了，不至于只盯着眼前这几行代码。
还有团队的规范也可以写到这个文件里去，诸如命名规则是什么，分支策略是什么，代码风格有什么要求，测试覆盖率要达到多少。
有了这些，AI 干活就有个准头，不会自己瞎发挥。
CODEBUDDY.md 文件，第一次生成可以靠 AI，但它的核心是迭代。比如你发现有什么关键信息文档里没有覆盖，那就补充进去，及时优化和修改。
这一步其实挺重要，因为有些东西 AI 扫代码是扫不出来的。
比如某个模块历史包袱重，轻易别动；比如某段代码看着丑，但暂时不能重构；比如某个接口和外部系统耦合很深，改了会出事。
这些只有团队自己清楚，得人写进去。
可上下滑动查看
初始化完成后，我们进入到正式的开发环节。
用户可能在 iPhone、iPad、Mac 等多个设备上使用这个应用。需要有一个可靠的数据同步逻辑，并且离在线的切换，需要用户无感同步。
大家看看执行的录屏过程，有点意思。拿到一个相对复杂的需求，它拆成了三个阶段。
第一阶段做那些风险低、马上能见效的；第二阶段做性能提升明显但需要点工作量的；第三阶段才是那些高级特性，属于长期收益。
其实就是 P0、P1、P2，这背后明显是腾讯内部的工程方法论。让我惊喜到的是，它从代码里找到了真正的瓶颈是什么。
因为我这个项目有个核心设计是离线优先，还有一套自动冲突解决的机制，这两个东西决定了很多架构选择。
所以，我看到它分析的时候把这些都考虑进去了，这说明它理解的是整个同步系统的逻辑，不只是表面的代码结构。
可上下滑动查看
整个过程确实像一个资深的技术同事在做事情：1）先理解业务目标 2）深入分析现有实现 3）设计可落地方案 4）分阶段实施 5）量化效果 6）考虑边界。
这里，CLI 形态的 AI Coding 工具的价值就比较清楚了。它就是一个可以端到端执行任务的 Agent，而且 Agent 的设计者会把自己的最佳实践揉到产品里。
像刚才的任务拆解思路，我推测大概率是腾讯内部的方法论。
下面是这个任务的执行过程，不到 20 分钟，我倍速了下，方便大家了解。
CodeBuddy Code 还支持 MCP，所以我可以在这里配置 pipeline 中各个产品的 MCP。比如，配置一个 Figma 的。
在用户根目录下 ～/codebudd 创建 mcp.json 就行。Figma 的配置如下。我从他们官网找到的，注意加 Type 类型。
{
"mcpServers": {
"Figma": {
"timeout": 60000,
"command": "npx",
"args": [
"-y",
"figma-developer-mcp",
"--figma-api-key=your-key",
"--stdio"
],
"type": "stdio",
"disabled": false
}
}
}配置好 MCP 后，CodeBuddy Code 可以根据提示词自动识别需要 MCP 的场景。
像下面这个真实的例子，我希望它基于 Figma 的新设计图，来重构关于我们页面。
改造前和改造后的效果如下：
再试试在 CodeBuddy Code 中创建和使用专门的 SubAgent。
我写了一个生成测试代码的 SubAgent。/agents 这个命令可以直接选择创建子代理，只需要输入提示词就可以自动生成 SubAgent。
codebuddy/agents/ 是它存放项目子代理的地方，如果觉得有问题可以自行去修改里面的提示词。
在输入生成测试这个提示词后，自动就触发了对应的 SubAgent。
有了编译错误它会自己去解决。
下面是帮我生成的测试单元，并且做了对应的目录结构区分。
CodeBuddy Code 同样支持最近大火的 Skills。哈哈哈，Skills 实在是太火了。我的感觉是，Skills 这玩意的传播速度，可真的是比当时 MCP 快，证明它命中了一些刚需的需求。
研究了下。.codebuddy/skills/ 是 Skills 在项目中的目录位置，你可以自己去写，也可以直接让 CodeBuddy Code 生成。
我写了一个创建新功能模块结构的 Skills，这个 skill 完全遵循项目现有的模式和约定，可以帮我快速开始新功能的开发。
可上下滑动查看
我们执行这个 Skills 看看：
写在最后
这么实测下来，我感觉腾讯这款产品确实还不错。而且国内版本免费，大家可以去玩玩。
最近 Skills 很火，很多人开始折腾 Claude Code，然后被各种网络问题搞得焦头烂额。其实完全可以拿 CodeBuddy Code 当平替，功能差不多，省去一堆折腾。
周六我写了篇文章，提到一个正在发生的小趋势：有些创业公司开始打破原来的技能分工，不再按前端后端运维这样划线，而是要求工程师能用 AI 工具一站式搞定需求。
我认识好几个创业公司已经在这么干了。文章发出来之后争议还挺大的。
评论区让我挺感慨。
有些人对 AI 的理解，好像跟我们生活在不同的时代。很多人连 Claude Code 这样的工具都没用过。
我知道现在要学的东西确实多，每天都有新工具冒出来，新工具又在不停更新新功能，应接不暇。
但我自己的感受是，时代变化快的时候，恰恰需要刻意的给自己留点时间，抬头看看外面在发生什么，不能总埋在手头的活儿里。
不会用 AI 的人，生产力会迅速落后。