docs: mintlify 文档撰写

docs/safety/permission-model.mdx

@@ -0,0 +1,64 @@
+---
+title: "权限模型"
+description: "三种行为 x 多级来源 = 灵活而严谨的权限体系"
+---
+
+{/* 本章目标：详解权限系统的设计 */}
+
+## 三种权限行为
+
+每一次工具调用，系统都会做出三种裁决之一：
+
+| 行为 | 含义 | 典型场景 |
+|------|------|---------|
+| **Allow** | 自动放行，用户无感知 | Read 工具读取项目内的文件 |
+| **Ask** | 弹出确认对话框，等待用户决定 | Bash 执行一条未知命令 |
+| **Deny** | 直接拒绝，AI 收到"权限被拒"的反馈 | 尝试执行被禁止的命令 |
+
+## 权限规则的层级
+
+规则可以来自多个来源，优先级从高到低：
+
+<Steps>
+  <Step title="用户会话内设置">
+    用户在当前对话中手动授权的（"对这个工具始终允许"）
+  </Step>
+  <Step title="项目配置">
+    项目目录中的 `.claude/settings.json`，团队共享
+  </Step>
+  <Step title="用户全局配置">
+    `~/.claude/settings.json`，跨项目生效
+  </Step>
+  <Step title="托管设置">
+    企业管理员下发的策略，用户不可覆盖
+  </Step>
+  <Step title="默认规则">
+    系统内置的基线规则
+  </Step>
+</Steps>
+
+## 规则的匹配方式
+
+权限规则不是简单的"允许/禁止某个工具"，它支持丰富的匹配条件：
+
+- **工具名匹配**：`"tool": "Bash"` → 针对所有 Bash 命令
+- **命令模式匹配**：`"command": "git *"` → 只针对 git 开头的命令
+- **路径匹配**：`"path": "src/**"` → 只允许操作 src 目录下的文件
+- **组合条件**：以上条件可以组合使用
+
+## 权限模式
+
+系统提供几种预设的权限模式，适应不同信任级别：
+
+| 模式 | 适用场景 |
+|------|---------|
+| **Default** | 日常使用，敏感操作逐一确认 |
+| **Plan Mode** | 探索阶段，AI 只能读不能写 |
+| **Bypass** | 完全信任 AI，所有操作自动放行（需显式开启） |
+
+## Denial Tracking
+
+系统不仅记录"允许了什么"，还追踪"拒绝了什么"：
+
+- 如果 AI 被连续拒绝多次同一类操作，系统会调整策略
+- 这防止 AI 陷入"反复请求同一个被拒操作"的死循环

docs/safety/plan-mode.mdx

@@ -0,0 +1,60 @@
+---
+title: "计划模式"
+description: "先看后做——给 AI 一个只读的探索阶段"
+---
+
+{/* 本章目标：解释 Plan Mode 的设计理念 */}
+
+## 问题场景
+
+你说"重构这个模块"，AI 立刻开始改代码——但你还没搞清楚它打算怎么改。等改了一半发现方向不对，已经来不及了。
+
+## Plan Mode 的解决方案
+
+计划模式给对话加了一个"只读阶段"：
+
+<Steps>
+  <Step title="进入计划模式">
+    AI 自主判断任务需要规划（或用户主动触发），进入计划模式
+  </Step>
+  <Step title="探索阶段">
+    在这个阶段，AI 只能使用读取和搜索类工具——不能编辑文件、不能执行命令
+  </Step>
+  <Step title="形成计划">
+    AI 把理解和方案写入计划文件，提交给用户审阅
+  </Step>
+  <Step title="用户审批">
+    用户阅读计划，提出修改意见或直接批准
+  </Step>
+  <Step title="退出计划模式">
+    计划被批准后，AI 恢复全部工具权限，按计划执行
+  </Step>
+</Steps>
+
+## 权限的自动收窄与恢复
+
+计划模式的精妙之处在于**自动改变权限上下文**：
+
+- 进入时：系统自动保存当前权限模式，切换为"只读"
+- 退出时：系统自动恢复之前的权限模式
+
+AI 和用户都不需要手动调整权限设置。
+
+## 什么时候该用计划模式
+
+| 场景 | 是否需要计划 |
+|------|-------------|
+| 修复一个明确的 typo | 不需要，直接修 |
+| 添加一个简单的函数 | 不需要 |
+| 重构一个大模块 | 需要——先搞清楚影响范围 |
+| 涉及多个文件的 feature | 需要——先统一方案 |
+| 不确定该怎么做 | 需要——让 AI 先调研 |
+
+## 计划模式 + 任务系统
+
+计划模式通常与任务系统配合使用：
+
+1. 在计划模式中，AI 把实施步骤创建为任务列表
+2. 用户审批计划（包含任务列表）
+3. 退出计划模式后，AI 按任务列表逐项执行
+4. 用户可以通过任务列表追踪进度

docs/safety/sandbox.mdx

@@ -0,0 +1,35 @@
+---
+title: "沙箱机制"
+description: "即使命令被允许执行，也不意味着它可以为所欲为"
+---
+
+{/* 本章目标：解释沙箱的作用和原理 */}
+
+## 权限之外的第二道防线
+
+权限系统决定"这条命令能不能执行"，沙箱决定"执行时能做到什么程度"。
+
+即使一条命令通过了权限审批，沙箱仍然可以限制它的行为：
+
+| 限制维度 | 说明 |
+|----------|------|
+| **文件系统** | 只能访问项目目录及其子目录 |
+| **网络** | 可以禁止或限制网络访问 |
+| **进程** | 限制可启动的子进程 |
+| **时间** | 超时自动终止 |
+
+## 何时启用沙箱
+
+沙箱不是默认对所有命令生效——它根据风险评估动态决定：
+
+- 用户显式请求禁用沙箱的命令（`dangerouslyDisableSandbox`）不走沙箱
+- 已通过安全规则白名单的命令可以跳过沙箱
+- 未知命令或高风险命令强制进入沙箱
+
+## 沙箱的实现思路
+
+不同平台使用不同的沙箱技术：
+
+- **macOS**：利用系统级沙箱机制限制文件和网络访问
+- **Linux**：基于命名空间和 cgroup 的进程隔离
+- 沙箱策略由系统自动选择，用户不需要手动配置

docs/safety/why-safety-matters.mdx

@@ -0,0 +1,40 @@
+---
+title: "为什么安全至关重要"
+description: "当 AI 能操作你的电脑，信任的边界在哪里"
+---
+
+{/* 本章目标：建立安全意识，解释为什么需要这么多安全机制 */}
+
+## AI 动手的代价
+
+Claude Code 不是在沙盒里回答问题——它在你的真实项目中修改文件、执行命令。一个失误可能意味着：
+
+- 覆盖了你还没提交的工作
+- 执行了危险的 `rm -rf` 命令
+- 推送了包含 bug 的代码到远程仓库
+- 泄露了 `.env` 文件中的密钥
+
+## 安全设计的核心理念
+
+<CardGroup cols={2}>
+  <Card title="最小权限原则" icon="lock">
+    AI 默认没有任何"动手"权限，每项能力都需要显式授予
+  </Card>
+  <Card title="可逆优先" icon="rotate-left">
+    优先执行可逆操作（读文件、搜索），对不可逆操作（删除、推送）严格审批
+  </Card>
+  <Card title="人在回路" icon="user">
+    关键操作必须经过人类确认，AI 不能绕过用户自行决定
+  </Card>
+  <Card title="纵深防御" icon="shield-halved">
+    多层安全机制叠加——权限规则、沙箱、计划模式、预算上限——任何一层都能阻止危险操作
+  </Card>
+</CardGroup>
+
+## 安全 vs 效率的平衡
+
+如果每个操作都要确认，AI 就变成了一个不停弹窗的烦人助手。Claude Code 的设计在安全和效率之间找到了平衡：
+
+- **低风险操作自动放行**：读取文件、搜索代码——这些不会改变任何东西
+- **中风险操作规则放行**：编辑指定目录的文件——用户可以预设"允许"规则
+- **高风险操作人工确认**：删除文件、执行未知命令——必须手动审批