我花了三天学 CodeBuddy CLI，发现 90% 的人根本不会用
“他们用 AI 编程，AI 也用他们——因为 AI 知道这些人只会点按钮。”
前两篇说了 WorkBuddy 和 CodeBuddy 的区别，又说了 8 个上手技巧。有人问我：CLI 值得专门写一篇吗？
值得。
因为大抵只有 10% 的人真的会用 CLI。剩下的 90%，大概还在 IDE 里点来点去。
先说安装
一行命令：
npm install -g @tencent-ai/codebuddy-code
装完之后，终端里就有了两个命令：codebuddy 和 cbc。
验证：
cbc --version
能打印版本号，就说明装好了。
踩坑提示：如果你用 nvm 管理 Node 版本，记得切到 Node 18+。低于 18 会报错。我当初就踩了这个坑——装完了死活跑不起来，查了半天才发现是 Node 版本问题。气笑了。
两种用法
第一种：问完就走。
cbc "帮我优化这个正则表达式"
第二种：交互模式。
cbc
直接敲 cbc，进入一个 REPL 界面。你可以跟它来回对话，逐步细化。
两种用法没有优劣。看场景。
管道：CLI 的杀手锏
这才是 CLI 真正厉害的地方。
它支持 Unix 管道——把别的命令的输出，直接喂给它分析。
例子一：分析 Git 提交历史
git log --oneline -20 | cbc "分析这些提交，找出可能的问题"
例子二：分析错误日志
cat error.log | cbc "分析这些错误，找出根本原因"
例子三：代码审查
git diff main | cbc "审查这些改动，检查安全和性能问题"
为什么管道重要？
因为管道意味着可编程调用。
你可以把这条命令写进脚本：
#!/bin/bash
# 每日代码审查脚本
TODAY=$(git log --since="midnight" --oneline)
if [ -n "$TODAY" ]; then
echo "$TODAY" | cbc "审查今天的提交，列出潜在问题"
fi
把这个脚本加到 crontab，每天下班前自动跑一遍。
IDE 插件做不到这个。
我试过在 IDE 里搞自动化——基本上不可能。你得先打开 IDE，再打开对话窗口，再输入指令。CLI 呢？一条命令的事。
这大约就是”终端党”的优势罢——你不觉得麻烦，别人觉得麻烦。
四个常用场景
场景一：提交前审查
git diff --cached | cbc "审查这些改动，如果有明显问题就告诉我"
场景二：读陌生代码
cat some_module.py | cbc "解释这个模块的作用和关键函数"
场景三：跑测试分析结果
pytest tests/ 2>&1 | cbc "分析测试结果，定位失败的测试"
场景四：生成提交信息
git diff --cached | cbc "根据这些改动生成一段 commit message"
三个坑
坑一：上下文会爆。
CLI 的上下文窗口有限。聊了 50 轮之后，它开始”前说后忘”。
解法：定期开新会话。
坑二：大文件要小心。
把 1 万行的文件直接丢给它：
cat big_file.py | cbc "重构这个文件"
它会返回一堆东西，但大概率不是你想要的。
解法：只给它需要的部分。
head -100 big_file.py | cbc "重构这个函数"
坑三：有时候会卡住。
你输入问题，它半天不响应，报超时错误。
大约是网络问题。腾讯的服务器偶尔会抖。
解法：重试。或者换个时间用。
CLI vs IDE 插件
| 场景 | 选什么 |
|---|---|
| 写代码时需要补全 | IDE 插件 |
| 需要在脚本里调用 | CLI |
| 需要处理管道输入 | CLI |
| 需要 CI/CD 集成 | CLI |
| 需要交互式对话 | 都行 |
它们是互补的，不是互斥的。
小结
CLI 的核心优势就一句话：它是可以被编程调用的。
你可以把它塞进管道、写进脚本、加到 CI/CD。它不是”对话窗口”，它是”工具”——跟 grep、awk、jq 一样，只是它能理解你说的话。
真正会用 AI 编程的人，大约都不会只在 IDE 里跟它聊天。
他们会把它变成工作流的一部分。
这便是 CLI 的价值罢。
关于码孖AI
码孖AI，专注 AI 工程化落地。我们相信：AI 不是来替代程序员的，是来帮程序员省时间的——前提是，你得会用。
关注我，持续更新实战踩坑指南。
觉得有用？ 点个「在看」，分享给同样在 AI 落地路上挣扎的朋友。