24 · 权限与安全

用 AI 写代码，不能只关心”它写得多快”，更要关心”它能看到什么、能改什么、能删什么”。这一篇完整拆解 Trae 的安全体系。

01 · 为什么权限问题是你的问题

很多开发者第一次用 AI 编程助手时，第一反应是：“它只是帮我写代码，能出什么问题？”

问题出在信任边界上。传统 IDE 里，你安装的每个插件都拥有和你一样的文件系统权限。一个插件可以读取你的 .env、修改你的 package.json、甚至删除整个项目。AI 编程助手本质上也是一种”超级插件”——它不仅能读能写，还能联网，能根据远程服务器的决策执行操作。

Trae 作为一款深度融合 AI 的 IDE，在设计之初就把权限与安全作为核心架构的一部分，而不是事后补丁。理解这套体系，不仅是为了避免事故，更是为了在安全与效率之间找到适合你的平衡点。

02 · 三大工作模式：你的安全基线

Trae 定义了三种安全等级的工作模式。你选择的模式决定了 AI 能做什么、不能做什么。

workspace-write（推荐）

这是大多数开发者的默认工作模式。AI 只能：

• 读： 当前工作区内的任意文件（包括子目录）
• 写： 在工作区内创建、修改、删除文件
• 终端： 执行预定义的安全命令（如 npm install、git status、python 等），不可执行危险命令（如 rm -rf /、curl | bash）
• 网络： 发起 HTTP 请求前会弹窗征求你的同意

心智模型： 想象 AI 是一个只在你项目”院子”里活动的助手——它可以看到院子里的所有东西、移动院子里的物品，但不能拆邻居的房子，也不能打开通往外面的门。

danger-full-access（危险 — 全权限）

这个模式移除了几乎所有限制。AI 可以：

• 读/写： 系统任意路径（包括 /etc、~/.ssh、/usr/bin）
• 终端： 执行任何 shell 命令
• 网络： 自由发起网络请求，无需二次确认

**什么时候需要用？**当你确实需要 AI 帮你做系统层面的操作时——比如写一个安装脚本、修改系统配置、操作 Docker 守护进程等。使用这个模式之前，请确保你信任当前对话中的 AI 行为，并且项目代码是可信的。

心智模型： AI 现在是你的”系统管理员实习生”——它和你拥有一样的权限。你会让一个实习生拿到 root 密码吗？不会。所以请只在确实需要时开启这个模式。

sandbox（沙箱）

沙箱模式是最严格的限制模式：

• 文件： AI 只能在一个隔离的临时目录中操作
• 终端： 不允许执行任何命令
• 网络： 所有网络请求被拦截

**适用场景：**你只是想浏览一段代码、让 AI 解释某个算法、或者从剪贴板粘入一段不信任的代码让 AI 审查。沙箱模式确保 AI 无法触及你的真实项目文件。

03 · 审批策略：你控制每一次 AI 行动

权限模式定义了”AI 能做什么”的上限，但具体到每一次操作，你还可以通过审批策略来控制”AI 能不能立刻做”。

Trae 提供了三个级别的审批策略：

on-request（按需审批 — 默认）

在这种策略下，AI 执行任何敏感操作（写文件、执行命令、发网络请求）时，IDE 会弹出审批对话框，显示：

• 操作类型（文件写入 / 命令执行 / 网络请求）
• 目标路径或 URL
• 操作内容预览（即将写入的内容、要执行的命令等）

你需要点击”允许”或”拒绝”才能继续。你也可以勾选”本次对话记住此决定”来减少重复审批。

always-ask（每次询问）

比 on-request 更严格——即使你在本次对话中已经批准过同类操作，每次出现时都会重新征求你的意见。适合对安全极度敏感的场景，或者你不希望 AI 在未经逐条确认的情况下做任何更改。

never（从不询问）

AI 可以直接执行任意操作，无需弹窗确认。这个策略只能在 workspace-write 模式下搭配使用才相对安全，因为模式本身已经限制了操作范围。如果你在 danger-full-access + never 的组合下工作，相当于 AI 拥有完全的控制权——风险由你自己承担。

策略速查表

**建议：**日常开发使用 on-request，上手一两周后你会发现哪些审批是冗余的，可以逐步信任后改为 never（但保持 workspace-write 模式）。

04 · .git 保护：你的版本历史不可篡改

Git 目录（.git/）包含了项目的完整版本历史、分支、提交信息。如果有人篡改 .git 目录，可以做到：

• 伪造提交历史
• 植入恶意代码然后抹掉痕迹
• 窃取存储在 git hooks 中的凭据

Trae 的默认行为： .git 目录及其所有子文件被标记为只读。AI 无法读取、写入或删除 .git/ 中的任何内容。这个保护是强制的——即使在 danger-full-access 模式下，AI 也无法直接修改 .git 目录（但可以通过执行 git 命令间接操作，这是正常的开发行为）。

这个设计非常重要：它确保了版本历史的完整性不受 AI 影响。如果 AI 写入了错误的代码，你可以放心地用 git diff 查看变更、用 git checkout 回退，而不用担心 AI 已经偷偷修改了历史记录让你无法回退。

05 · 网络访问控制

AI 编程助手的核心能力之一是上下文理解——但联网能力也带来了数据泄露的风险。

Trae 的网络访问控制分为三个层面：

第一层：AI 模型推理的网络请求

AI 要分析你的代码、生成回答，需要将上下文发送到 LLM 后端服务器。这部分流量：

• 中国大陆版（trae.com.cn）： 数据发送到国内服务器，符合中国数据法律法规
• 国际版（trae.ai）： 数据发送到海外服务器
• 流量加密： 所有通信使用 TLS 1.3 加密

第二层：AI 自主发起的网络请求

当 AI 执行任务时，可能主动发起网络请求（比如调用 API 获取数据、下载依赖等）。这部分流量受权限模式和审批策略的双重控制：

• 在 workspace-write 模式下，每次网络请求都需要你的审批
• 审批对话框会显示完整 URL 和请求方式（GET / POST / PUT 等）
• 你可以选择”仅本次允许”或”允许本次对话中的所有请求到此域名”

第三层：本地回环限制

AI 默认不允许向 localhost / 127.0.0.1 / 0.0.0.0 发起网络请求，除非你在设置中明确开启。这防止了 AI 意外访问你本地运行的服务（如数据库、开发服务器、Redis 等）。

06 · SOLO 模式的安全边界

SOLO 模式是 Trae 的一个独特功能——它让 AI 独立完成一个较长的开发任务，而不需要你逐条确认。

但 SOLO 模式的安全设计才是真正值得关注的部分：

分阶段审批

SOLO 模式的工作流被分解为计划 → 执行 → 验证三个阶段。在第一阶段（计划），AI 会生成一个完整的操作计划——列出所有将要创建、修改、删除的文件以及要执行的命令。计划本身不会自动执行，你需要审查并批准这个计划后，AI 才会进入执行阶段。

自动回滚

如果在 SOLO 执行过程中出现异常（比如 AI 陷入循环、生成了不可编译的代码、或者你手动中断），SOLO 模式会自动回滚所有变更，将项目恢复到 SOLO 启动前的状态。

资源配额

SOLO 模式对 AI 的资源使用有硬性限制：

• 单次 SOLO 最多修改的文件数有限（取决于配置）
• 单次 SOLO 执行命令的次数有限
• 文件修改有大小上限

这些配额防止了 AI 失控时对项目造成过大影响。

07 · 数据隐私：你的代码去了哪里

这是开发者最关心的问题之一——“我把代码发给 AI 了，这些代码会被怎么处理？“

发送到 AI 服务器的内容

当你使用 Trae 的 AI 功能时，以下数据会被发送到 LLM 服务器：

1. 当前打开的文件的全部或部分内容（具体取决于上下文窗口需求）
2. 终端输出（当你粘贴终端的错误信息让 AI 分析时）
3. 你选中的代码片段（当你提问关于特定代码的问题时）
4. 项目结构信息（文件名、目录结构、文件间的 import 关系）
5. 对话历史（当前对话中你发送过的所有消息）

不会发送的内容

1. .git/ 目录下的任何内容（前文提到的强制保护）
2. 你明确标记为”忽略”的文件（通过 .traeignore）
3. 二进制文件（Trae 不会将图片、视频、编译产物等二进制数据发送给 AI）

中国大陆版与国际版的区别

企业版额外保障

如果你所在的公司有严格的代码保密要求，Trae 企业版提供了：

• 私有化部署（部分方案）：模型部署在公司内网，代码完全不离开公司网络
• 数据隔离承诺：你的代码不会与其他客户的数据混合训练
• 审计日志：记录每次 AI 调用的上下文内容，供安全团队审查

08 · 实战配置：搭建你的安全开发环境

理论讲完了，下面是一套推荐的安全配置方案，你可以直接套用。

场景 A：个人开发者 — 日常项目

工作模式:    workspace-write
审批策略:    on-request
.git 保护:   启用（默认）
网络控制:    每次请求审批
.traeignore: 排除 node_modules / dist / .env

这套配置在安全性和效率之间取得了很好的平衡。当 AI 需要写文件或执行命令时你会收到通知，但不会烦人到影响工作流。

场景 B：企业团队 — 敏感项目

工作模式:    workspace-write
审批策略:    always-ask
.git 保护:   启用（默认）
网络控制:    禁止所有 AI 主动网络请求
.traeignore: 排除 .env / secrets / config/production.json / *.key
SOLO 模式:   禁用

团队 Leader 可以在项目根目录创建 .trae/config.json，将这些配置设为强制，团队成员无法修改。

场景 C：原型验证 / 学习探索

工作模式:    sandbox
审批策略:    never（sandbox 下安全）
.git 保护:   启用（默认）
网络控制:    全部拦截
SOLO 模式:   禁用

这是最安全的配置——AI 被完全隔离，你可以在沙箱中随意实验，不用担心影响项目文件。

.traeignore 配置示例

# 敏感配置文件
.env
.env.*
*.pem
*.key
secrets/
config/production.*
config/staging.*

# 构建产物（AI 不需要看这些）
dist/
build/
out/
*.min.js
*.bundle.js

# 依赖
node_modules/
vendor/
third_party/

# 日志
*.log
logs/

# 二进制文件
*.png
*.jpg
*.jpeg
*.gif
*.ico
*.mp4
*.mov
*.dmg
*.exe
*.zip

09 · 常见误解

误解 1：“我的代码 AI 训练时会被用，所以会被别人看到。” 事实：Trae 默认不将用户代码用于模型训练。你的代码在推理后不会被用来改进模型。

误解 2：“沙箱模式太严格了，什么都做不了。” 事实：沙箱模式主要用于代码审查、理解和简单的生成任务。它是一个”只读 + 思考”模式，不是开发模式。

误解 3：“danger-full-access 是给高级用户用的，我早晚也要学会用。” 事实：超过 90% 的开发任务在 workspace-write 模式下就能完成。不需要特意升级到全权限模式。

误解 4：“审批弹窗很烦，开启 never 就一劳永逸了。” 事实：审批弹窗是安全设计的重要一环。建议先用 on-request 体验一段时间，确认你对 AI 的行为模式有足够了解后，再接合你的风险承受能力决定是否改为 never。

10 · 安全最佳实践清单

• 每个项目第一件事：创建 .traeignore 文件，排除敏感文件
• 不要将 .env、*.pem、*.key 等敏感文件放在项目根目录
• 日常使用保持 workspace-write 模式
• 在审批弹窗中仔细阅读即将写入的内容——警惕 AI 生成的不安全代码（如硬编码密钥、SQL 注入风险等）
• 使用版本控制（Git），每次 AI 大规模修改后运行 git diff 审查变更
• 企业项目开启 always-ask 审批策略
• 定期检查 .trae/config.json 的权限设置
• 不要将 API Key、Token 等凭据写在对话中让 AI 看到——即使 AI 不会泄露，对话历史可能在本地或云端留存
• 区分清楚你用的是中国大陆版还是国际版，了解对应的数据法规
• 如果使用 SOLO 模式，务必审查执行计划后再批准

11 · 总结

Trae 的权限与安全体系可以用一句话概括：三层防御，你永远掌控最终决定权。

• 第一层：工作模式（定义 AI 的能力边界）—— workspace-write / danger-full-access / sandbox
• 第二层：审批策略（控制操作的执行方式）—— on-request / always-ask / never
• 第三层：文件排除（划定 AI 不能触及的数据范围）—— .traeignore / .git 保护

这三层不是互相替代的关系，而是叠加生效的。最宽松的组合（danger-full-access + never + 无 .git 保护）等于 AI 拥有你的完全权限；最严格的组合（sandbox + always-ask + 完整 .traeignore）则几乎将 AI 隔离在真空中。

核心原则： 信任是好的，控制更好。训练 AI 按照你的方式工作，而不是在没有护栏的情况下让它自由发挥。

安全不是功能特性，而是一种开发习惯。每次你点下”允许”之前多看一眼、每次你写好 .traeignore 再开始工作、每次你做完改动后用 git diff 扫一眼——这些习惯加起来，比任何安全配置都管用。

下一篇： 25 · 团队协作与配置管理

上一篇： 23 · 提示词工程实战技巧