2. 第一次对话-跑通一个小任务

来源：CodeBuddy

装好了，先别急着拿它干正事。

这一章的目的很朴素：在一个随便怎么搞都不心疼的目录里，把它启动起来、跟它说上话、看它干成一件事。走完这一章，你对它的脾气就有手感了。

先弄一个 playground

我们需要一块沙地。它等会儿会真的在里面创建文件、跑命令，所以这块地必须是无所谓的——别直接在你的项目根目录或者桌面练手。

macOS / Linux

mkdir -p ~/playground/cbc-demo && cd ~/playground/cbc-demo
git init

Windows PowerShell

New-Item -ItemType Directory -Path "$HOME\playground\cbc-demo" -Force
Set-Location "$HOME\playground\cbc-demo"
git init

WSL2

# 注意：目录要建在 WSL 自己的文件系统里，别放 /mnt/c/
mkdir -p ~/playground/cbc-demo && cd ~/playground/cbc-demo
git init

git init 这一步不是走形式。往后每一章我都会强调同一件事：让它动手之前，先让 Git 能兜底。 现在这个仓库是空的，但等会儿它建的文件、改的内容，你随时能 git status 看到、随时能回退。这一条习惯，比学会任何一个命令都值钱。

顺便确认一下 git 认识你是谁（没设过的话提交会失败）：

git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

启动

在那个目录里敲：

codebuddy

（短命令 cbc 一样用。）

你会进入一个对话界面：底部是一个输入框，上面是它的输出区。第一次进去它可能提示你选登录方式（第 1 章讲过），登录完就能用了。

界面上会显示当前目录、当前权限模式这类信息。先别管，往下走。

第一件事：建项目记忆

进会话之后，第一个要敲的不是你的需求，是这条命令：

/init

它会扫描当前目录，然后生成一个 CODEBUDDY.md 文件。这就是这个项目的记忆文件——项目是干什么的、目录怎么组织的、用什么技术栈、有什么规矩，都记在这里。

以后每次在这个目录启动 CodeBuddy，它都会自动读这个文件。也就是说，你不用每次都重复介绍"这是个 Python 项目、用 pytest 跑测试、提交信息要用英文"。

为什么这件事要第一个做？

因为不建记忆的后果，是它会反复扫同一批文件、反复问你同样的问题、反复踩同样的坑。一个项目建一次记忆，后面几十次对话都省事。

现在目录是空的，它生成的 CODEBUDDY.md 会很简陋。没关系，等会儿目录里有东西了，我们再让它重写一次。

你可以看一眼它写了什么：

macOS / Linux / WSL2

cat CODEBUDDY.md

Windows PowerShell

Get-Content CODEBUDDY.md

第一个任务

好，跟它说第一句话。复制这段进去：

帮我写一个 Python 脚本 wordcount.py，读当前目录下任意一个或多个文本文件，
统计每个词出现的次数，按频次从高到低输出前 20 个，并打印总词数。
要求：
1. 用 argparse 做命令行参数，支持传多个文件路径
2. 忽略大小写，忽略标点符号
3. 包含 if __name__ == "__main__": 入口
4. 不要引入第三方依赖，只用标准库
写完直接运行一次，自己造两个测试用的文本文件验证结果对不对。

说完回车。然后你会看到它开始工作——它会说打算做什么、创建文件、可能问你"是否允许执行 python wordcount.py"。

注意那个询问。 这就是 CLI 和聊天框最大的区别：它要真的执行命令，所以默认每条有副作用的命令都会问你一次。你可以选 Yes，也可以选"Yes, and don't ask again for this command"。

如果你不想一条条确认，可以按 Shift+Tab 切换权限模式（后面细讲）。

跑完之后，看结果：

macOS / Linux / WSL2

git status

Windows PowerShell

git status

你会看到它新建了 wordcount.py 和两个测试文本文件。git status 这条命令，往后每次它干完活你都要敲一遍——看它到底动了哪些文件，别只听它说"我改好了"。

四个权限模式，你得知道自己在哪个

CLI 有四种权限模式，决定了"它能不能不问我直接干"。

模式	行为	什么时候用
default	读文件自动放行，改文件/跑命令要问你	默认。陌生项目、第一次操作、心里没底的时候
acceptEdits	改文件不问了，跑命令还是问	你已经信任它，且改动都在版本控制里
plan	只给方案，一个字都不动	想先看它打算怎么干，或者涉及危险操作
bypassPermissions	全部放行	只在容器、CI 这类隔离环境里用。日常开发慎用

切换方式是按 Shift+Tab（部分 Windows 终端上是 Alt+M），按一次切一个，界面上有提示。

我的建议：日常保持 default，涉及重构和删除先切 plan。 那几次"点一下 Yes"的成本，远低于它一次改错带给你的麻烦。

几个必须记住的键

不用背，用两次就熟了：

键	作用
Esc	中断它正在做的事。它跑偏了、开始胡说八道了，按这个
Ctrl+C	退出当前任务/退出程序
Ctrl+O	展开看它的思考过程（默认折叠）。想知道它"为什么这么做"时用
Shift+Enter	输入框里换行（直接回车是发送）。写多行提示词必备
↑	调出上一条输入
Tab	输入 @ 之后按 Tab 补全文件名

Esc 那个键特别值得记住。它开始跑一个莫名其妙的命令时，别等它跑完，直接打断。

结束与恢复

一次对话干完一件事，想换话题，敲：

/clear

它会清空上下文重新开始。这一条比你想象的重要——上下文里堆着上一件事的细节，会污染下一件事的判断。一件事一个会话，是最省 token 也最不容易出错的做法。

想找回上一次的会话：

/resume

会列出最近的会话让你挑。或者启动时指定：

codebuddy --resume

顺手做一次完整闭环

趁热打铁，把这套动作做一遍，往后每个案例都这么走：

# 1. 看它改了什么
git status

# 2. 看具体改了哪些行
git diff

# 3. 没问题就提交
git add -A
git commit -m "feat: add wordcount script with argparse and tests"

git diff 那一步别省。它的"改好了"和你的"改好了"可能不是一个意思——尤其当它自作主张删了点什么的时候，只有 diff 会告诉你。

本章你多了什么

• 一个 ~/playground/cbc-demo 目录，里面有一个能跑的 wordcount.py
• 一份 CODEBUDDY.md 项目记忆（现在还很简单）
• 一条肌肉记忆：动手前 git 兜底，干完看 status 和 diff
• 四个权限模式的概念和 Shift+Tab 切换
• Esc 打断、/clear 换话题、/resume 找回

常见坑

它一直在问"是否允许"，烦。 两种解法：一是按 Shift+Tab 切到 acceptEdits；二是针对某条命令选"不再询问"。但涉及 rm、git push、--force 这类，我建议你永远手动确认。

它改出来的脚本跑不起来。 把报错整段复制给它，说"这段报错，修一下"。不用自己分析，它会读得比你还仔细。这是 CLI 最省事的地方之一。

它跑了很久没动静。 可能是在扫描大量文件或者在等网络。按 Ctrl+O 看它在想什么。真的卡住了就 Esc。

换了个目录启动，它就不认识项目了。 记忆文件是按目录走的。换了目录要么重新 /init，要么用 @CODEBUDDY.md 把它引进来（第 3 章讲）。

---

下一章讲心法——喂什么样的上下文、三种用法怎么选、会话怎么管。这些内容不刺激，但决定了后面七个案例你做得顺不顺。