命令行与 Git
Coding Agent 的主战场：终端、仓库、分支、diff 与提交。
一句话理解：命令行是 Coding Agent 的“双手”，Git 是它的“后悔药”；看懂一条命令和一份 diff，你就能监督 Agent 在你的代码仓库里做了什么。
Coding Agent 是目前最成熟的 Agent 形态之一，而它几乎所有的动作都发生在两个地方：终端（执行命令）和 Git 仓库（管理代码变更）。当 Agent 请求你批准“运行 npm test”或“执行 git push”时，如果你看不懂这些命令意味着什么，所谓的“人工审批”就只是机械地点确认。
即使你不写代码，这一课也值得认真学：它能让你看懂 Agent 的操作记录，也能帮你理解为什么 Coding 领域的 Agent 特别容易做强——因为终端提供了客观反馈，Git 提供了安全网。
命令行：用文字操作电脑
图形界面里你点按钮，命令行（CLI）里你输入命令。一条命令的结构：
git log --oneline -n 5
#命令 子命令 选项 选项参数Coding Agent 最常用的一组命令：
| 命令 | 作用 | Agent 用它做什么 | 风险 |
|---|---|---|---|
pwd |
显示当前所在目录 | 确认工作位置 | 无 |
ls |
列出文件 | 了解项目结构 | 无 |
cd src |
进入目录 | 切换工作位置 | 无 |
cat README.md |
查看文件内容 | 阅读代码与文档 | 无 |
grep -rn "redirect" src |
在文件中搜索文本 | 定位相关代码 | 无 |
npm test / pytest |
运行测试 | 验证修改是否正确 | 低，但测试可能访问外部资源 |
npm install 包名 |
安装依赖 | 引入新库 | 中，可能引入恶意或不必要的包 |
curl https://... |
发起网络请求 | 调试接口 | 中，可能把数据发到外部 |
rm 文件 |
删除文件 | 清理 | 高，命令行删除通常不进回收站 |
rm -rf 目录 |
强制递归删除 | 极少需要 | 极高 |
看懂命令的执行结果
每条命令执行后会产生三样东西，Agent 正是靠它们判断下一步：
| 输出 | 含义 | 例子 |
|---|---|---|
| 标准输出 stdout | 正常的输出内容 | 测试报告、文件内容 |
| 标准错误 stderr | 错误与警告信息 | Error: Cannot find module 'axios' |
| 退出码 exit code | 数字，0 表示成功，非 0 表示失败 |
测试失败时通常返回 1 |
$ npm test
FAIL src/auth/redirect.test.ts
✕ 登录后应跳转到带语言前缀的首页 (12 ms)
Expected: "/zh/dashboard"
Received: "/dashboard"
Tests: 1 failed, 23 passed, 24 total
$ echo $?
1对 Agent 来说，这段输出信息量很大：哪个测试失败、期望值与实际值分别是什么、退出码为 1。它会据此去修改跳转逻辑，然后再跑一次测试——这就是初识 Agent Loop 中的 Verify 环节在 Coding 场景里的具体样子。
Agent 就是这样把终端当成反馈回路的：
退出码是最便宜、最客观的验证信号。 办公类 Agent 很难有这样的信号，这也是 Coding Agent 更容易做好的原因之一。
Git：代码的版本管理与安全网
Git 记录代码的每一次变更，让你可以查看、比较、撤销。核心概念用“写文档”来类比：
| 概念 | 类比 | 说明 |
|---|---|---|
| 仓库 Repository | 整个文档项目及其所有历史版本 | 一个代码项目 |
| 工作区 Working Tree | 你正在编辑的草稿 | 当前磁盘上的文件 |
| 暂存区 Staging Area | 挑出准备存档的修改 | 用 git add 放入 |
| 提交 Commit | 一次带说明的存档快照 | 用 git commit 创建，可随时回到这个版本 |
| 分支 Branch | 另开一份副本试验新改动，不影响正式版 | Agent 通常在独立分支上工作 |
| 差异 Diff | 修订模式下的“红删绿增” | 展示具体改了哪几行 |
| 远程 Remote | 团队共享的云端仓库 | 例如 GitHub、GitLab 上的仓库 |
| 拉取请求 PR / MR | 请求把分支合并进主线，供他人审查 | Agent 提交 PR，人来 Review |
一个 Coding Agent 修 Bug 的典型 Git 流程：
对应的命令：
git switch -c fix/login-redirect # 从当前分支创建并切换到新分支
# ……Agent 修改文件、运行测试……
git status # 查看哪些文件被修改
git diff # 查看具体改动
git add src/auth/redirect.ts # 暂存修改
git commit -m "修复登录后跳转缺少语言前缀的问题"
git push -u origin fix/login-redirect # 推送到远程仓库读懂一份 diff
审查 Agent 的修改，最重要的技能就是读 diff：
--- a/src/auth/redirect.ts
+++ b/src/auth/redirect.ts
@@ -8,7 +8,8 @@ export function getRedirectPath(user: User, locale: string) {
if (!user.isVerified) {
return '/verify';
}
- return '/dashboard';
+ const prefix = locale === 'en' ? '' : `/${locale}`;
+ return `${prefix}/dashboard`;
}---和+++标明修改前后的文件。@@ -8,7 +8,8 @@表示从第 8 行开始，原来 7 行变成了 8 行。-开头是删除的行，+开头是新增的行，没有符号的是上下文。
作为审查者，你要问的问题不是“语法对不对”，而是：改动范围是否和任务匹配？有没有改到不相关的文件？有没有删除测试或跳过检查来让测试“通过”？
危险命令：审批的重点
| 命令 | 后果 | 为什么危险 |
|---|---|---|
rm -rf 路径 |
强制删除目录及其全部内容 | 不进回收站，路径写错可能删掉整个项目 |
git reset --hard |
丢弃所有未提交的修改 | 未提交的工作无法用 Git 找回 |
git push --force |
用本地历史覆盖远程分支 | 可能抹掉他人已推送的提交 |
git clean -fd |
删除未被 Git 跟踪的文件 | 新建但未提交的文件会被删除 |
curl ... | sh |
下载脚本并立即执行 | 执行了未经审查的外部代码 |
| 修改 CI 配置、跳过测试 | 让检查“通过” | 表面成功，实际掩盖问题 |
读取 .env 等密钥文件 |
可能把密钥带进上下文或日志 | 凭据泄露 |
成熟的 Coding Agent 产品通常会把这些操作纳入权限规则：有的默认需要确认，有的可以配置为禁止，并在沙箱中限制文件与网络访问范围。Claude Code 等产品的具体做法见Claude Code 拆解。
Git 为什么是 Agent 的安全网
对比有没有 Git 时，Agent 改坏文件后的结局：
这给做其他领域 Agent 的产品经理一个重要启发：如果你的业务 Agent 也要修改数据，能不能设计出类似“分支、diff、回滚”的机制？ 例如，先生成“拟修改清单”（diff），审批后再执行，保留修改前快照以便回滚。见不可逆操作。
常见误区
- “看不懂代码就没法审查 Coding Agent。” 你可以审查改动范围、涉及的文件、是否修改了测试或配置、测试是否真的通过。这些不需要读懂每一行代码。
- “有 Git 就不怕 Agent 乱来。” Git 只管理被跟踪的文件。数据库修改、外部 API 调用、已发送的消息、已推送到远程的强制覆盖，Git 都救不回来。
- “测试通过就说明改对了。” Agent 可能通过修改测试、跳过测试或写只针对测试用例的代码让测试“通过”。审查 diff 时要特别留意测试文件的变动。
产品经理检查清单
评估一个 Coding Agent 或类似的执行型 Agent 时：
- Agent 在哪个目录下工作？能否访问该目录之外的文件？
- 哪些命令自动执行，哪些需要确认，哪些禁止？
- Agent 是否在独立分支工作？谁有权合并到主线？
- 用户能否方便地查看完整 diff 与命令执行记录？
- 测试、Lint 等验证手段是否被纳入 Agent 的工作流程？
- 如何防止 Agent 通过修改测试或跳过检查来“完成”任务？
- 出问题时，如何快速回滚？
练习
用 45–60 分钟在自己电脑上完成（需要先安装 Git）：
mkdir agent-git-lab && cd agent-git-lab
git init
echo "# 订单售后处理规则" > rules.md
git add rules.md
git commit -m "初始化规则文档"
git switch -c update-rules
echo "- 支付成功后订单状态超过 72 小时未更新，标记为异常" >> rules.md
git diff
git commit -am "新增支付状态异常规则"
git log --oneline
git switch -
cat rules.md如果第一次提交时报错提示需要设置身份，先执行 git config --global user.name "你的名字" 和 git config --global user.email "你的邮箱"。
然后回答：
- 执行
git diff时，看到的+行是什么？ - 最后切回原分支后，
rules.md的内容里有没有新规则？为什么？ - 如果这是 Agent 做的修改，你会如何决定是否合并？
延伸阅读
- Pro Git 中文版：Git 官方网站提供的免费图书，前三章足以覆盖本课内容。
下一步
命令在哪里执行、代码在哪里运行，决定了 Agent 的能力与风险边界。下一课「程序在哪里运行」讲清本地、服务器、Serverless、容器与沙箱的区别。