核心观点：Coding Agent 不是问答助手——它能读你的代码、改你的文件、跑你的命令。信任它之前，先确认它做了哪些安全措施。下面的七个维度不是打分表，而是你在选择或使用任何 Coding Agent 时应该追问的问题。
是什么 / 不是什么
先定清楚「Coding Agent」这个品类的边界，再讨论怎么评估。
是什么
- 能在代码仓库里执行多步操作的 AI：不只是回答「这段代码什么意思」，而是能打开项目、搜索文件、修改代码、执行命令、运行测试。
- 有执行后果的工具：修改真实文件意味着可能引入 bug，执行命令意味着可能影响系统状态。
- 需要信任机制的系统：因为它能造成不可逆的操作，所以必须有授权、审查和回滚机制。
不是什么
- 不是代码补全。补全只在你打字时提供建议，你需要逐个接受。Coding Agent 能自主规划并执行一系列操作。
- 不是万能程序员。Coding Agent 依赖你提供的上下文、授权范围和模型能力。它会犯错，尤其是在大型复杂项目中。
- 不是可以「设置好就忘」的。至少在当前阶段，Coding Agent 需要人类审查其输出——特别是在涉及生产环境代码时。
七个检查维度
下面按重要性排序，每一项都是你在选择 Coding Agent 时应该追问的。
1. 目录授权：它能碰哪些文件？
这是第一道门。好的 Coding Agent 应该让你显式指定它可以读写的目录范围，而不是默认拥有整个文件系统的权限。关键问题：
- 授权是目录级别的，还是整个项目/整个磁盘？
- 有没有路径逃逸防护？（符号链接、
..、UNC 路径） - 批准一个操作（如 git commit）是否会自动扩大目录权限？
理想状态：授权粒度细、逃逸被检测、权限不会意外扩大。批准 git commit 不应该等于放开对 ~/.ssh 的写权限。
2. 文件检查点：改坏了能撤吗？
Agent 修改了你的文件后，你能不能一键恢复？关键细节：
- 检查点是自动创建的，还是需要手动触发？
- 恢复时是全部回滚，还是只回滚 Agent 改过的文件？
- 如果你或 IDE 在 Agent 改过后又手动改了同一个文件，恢复会不会盲目覆盖你的手动修改？
好的实现能区分「Agent 改的」和「人后来改的」，只恢复前者。粗暴的全量回滚在真实工作流中会造成更多问题。
3. 变更审查：改了什么，透明吗？
Agent 完成工作后，你能不能完整核对它做了什么？理想交付物包括：
- 改了哪些文件的列表
- 每个文件的完整 diff（不是摘要，是逐行差异）
- 执行了哪些命令的完整记录
- 测试的完整输出（通过/失败/跳过，含错误信息）
这四个要素缺一不可。只告诉你「改了 3 个文件，测试通过」但不给你看 diff 的 Coding Agent，你没有理由信任它。
4. 测试证据：通过了什么测试？
「测试通过」四个字远远不够。你需要知道：
- 跑了哪些测试？是项目全量测试还是只跑了和改动相关的子集？
- 测试框架是什么？是真实运行还是模拟输出？
- 有没有新增测试？如果有，新测试本身的逻辑合理吗？
- 失败的测试有没有被悄悄跳过或修改？
最危险的情况是 Agent 修改了测试本身来让它「通过」。变更审查中的完整 diff 能帮你发现这类问题——前提是 diff 确实是完整的。
5. 代码理解：它真的「读」懂了吗？
Coding Agent 在修改代码前，应该先理解项目的结构。关键能力：
- 能不能构建代码图谱（调用关系、引用链、模块结构）？
- 修改一个函数时，能不能追踪到受影响的上下游？
- 面对陌生仓库，是全量扫描还是只读几个文件就开始改？
没有代码理解能力的 Agent 容易做出「局部正确、全局有 bug」的修改。代码图谱的质量直接影响修改的准确度——但它不容易一眼看出，需要你在审查时多留意 diff 里有没有不相关的文件变更。
6. Git 策略：它怎么和版本管理协作？
很多 Coding Agent 会操作 Git。关键问题：
- Git 操作（commit、push、force-push）是否需要审批？
- 不用 Git 的项目能不能正常工作？
- 批准 Git 操作是否会自动扩大文件系统权限？
理想状态：Git 是可选的源码管理，不是必要条件。git commit 这类写操作应该走统一审批，且批准 Git 命令不应该顺带放开目录权限。
7. 数据落点：代码和会话去了哪？
你和 Coding Agent 的会话可能包含大量代码片段、架构信息和业务逻辑。这些数据存在哪？
- 会话记录和上下文是存在本地还是云端？
- API 密钥存在哪？是系统凭据库还是明文文件？
- 代码片段有没有被用于模型训练？
对于开源项目可能不在意，但对于私有代码仓库，数据落点是一个严肃问题。
快速对照：不同工具的侧重
每款工具在这七个维度上各有侧重。下面对照不是排名，而是帮你理解各自的设计选择。
| 维度 | Cursor | Claude Code | GitHub Copilot | Semibot |
|---|---|---|---|---|
| 目录授权 | 编辑器 / 项目 | 终端目录 | 编辑器内 | 显式目录授权 + 逃逸检测 |
| 文件检查点 | 编辑器撤销 | Git-based | 编辑器撤销 | 自动检查点，区分人/Agent |
| 变更审查 | diff 视图 | 终端 diff | 内联预览 | ChangeSet（diff + 命令 + 测试） |
| 测试证据 | 终端输出 | 终端输出 | 有限 | 集成进 ChangeSet |
| 代码理解 | 项目模型（强） | 搜索 + 上下文 | 编辑器索引 | 原生代码图谱（TypeScript） |
| Git 策略 | 可选 | 终端内操作 | 深度集成 | 可选，写操作走审批 |
| 数据落点 | 混合 | 云端 | 云端 | 本地 SQLite |
Cursor 的项目模型和编辑器集成在代码理解上很强；Claude Code 在终端直接执行的灵活性上出色；GitHub Copilot 在编辑器内无缝嵌入的体验上领先。Semibot 侧重本地存储和显式授权流程。每款工具的强项不同，没有在这七个维度上全部领先的产品。
Semibot 的实现说明（含局限）
Semibot 对这七个维度的实现方式：
- 目录授权：用系统选择器授权工作目录；路径逃逸（
..、symlink、UNC）被检测并拒绝；批准 git 操作不自动扩大目录权限。 - 文件检查点：Agent 改过的文件自动存快照。恢复时区分 Agent 修改与后续人工修改，不盲目覆盖。
- 变更审查：ChangeSet 包含文件列表、完整 diff、命令记录和测试结果，接受前可完整核对。
- 代码理解：原生代码图谱（TypeScript 实现，无 Python sidecar），串起调用、引用与结构关系。
- Git 策略：Git 是可选的源码管理；
git commit等写操作走统一审批。 - 数据落点：会话、记忆、运行记录写在本机 SQLite，密钥进系统钥匙串。
需要如实说明的局限
- Semibot 是较新的产品。相比 Cursor、GitHub Copilot 等，用户群更小、第三方独立评测更少。上述能力描述来自我们自己的实现，不是独立第三方验证。
- Windows 构建暂未签名，安装时可能触发系统提示。
- Linux 桌面包尚未发布，目前在路线图上。
- 云端模型需要网络。本地优先描述数据存储，不描述推理链路。
- 模型质量取决于你接入的服务商。客户端是免费的，模型调用可能使用你的服务商账号或试用额度。
适合谁 / 不适合谁
这个检查清单适合
- 正在选型的团队：在多款 Coding Agent 之间做决策，需要一套结构化的评估维度。
- 已经在用但没认真审视过安全流程的人：用了一段时间但从未确认过目录授权、检查点和变更审查的具体行为。
- 有私有代码仓库的团队：代码安全和数据落点是刚需，不能只看功能演示。
不太需要这个检查清单
- 只用 AI 做代码补全和问答：不涉及自动修改文件，风险面小得多。
- 只处理个人开源项目：代码本身是公开的，数据落点的敏感度较低。
FAQ
什么是 Coding Agent？
能在授权范围内读代码、改文件、执行命令和测试的 AI 工具。它不只是问答助手，能真实地修改代码仓库。
为什么不能直接信任 Coding Agent？
因为它能修改真实文件和执行真实命令，操作有实际后果。信任应该来自验证——你确认过它的授权机制、审查流程和测试证据，再决定信任程度。
目录授权和文件权限有什么区别？
文件权限是操作系统的访问控制（如 chmod）。目录授权是应用层面的范围限制——指定 Agent 能碰哪些目录，通常比操作系统权限更细粒度且更易管理。
ChangeSet 和 Git 有什么关系？
ChangeSet 在 Git commit 之前发生，是 Agent 交付的变更预览。它让你在提交前核对 diff、命令和测试结果。两者是不同层次的概念：ChangeSet 是审查机制，Git 是源码管理。
代码图谱是什么？
代码图谱是代码库结构的索引：函数调用关系、模块引用链、类与接口的层级。它帮助 Agent 理解修改的影响范围，减少「改了 A 不知道 B 也受影响」的情况。
不用 Git 能用 Coding Agent 吗？
取决于具体工具。有些工具强依赖 Git。Semibot 把 Git 设计为可选——没有 Git 仓库的项目也能正常使用文件检查点和 ChangeSet。
这个检查清单适用于所有 Coding Agent 吗？
七个维度适用于所有能修改代码的 AI 工具。不同工具的实现方式不同（比如有的靠编辑器撤销代替文件检查点），但问题本身是通用的。