企业官网建设流程全解析

分析

问题核心：

为什么微软默认把整个 Windows 系统盘挂载到/mnt/c，而不是只挂载用户目录？

因为实际上：

/mnt/c/ ├── Windows/ ├── Program Files/ ├── Program Files(x86)/ ├── Users/ ├── ProgramData/ └──...

WSL 看到的是整个 C 盘，而不是：

/mnt/c/Users/xxx

所以理论上你完全可以：

sudorm-rf/mnt/c/Windows

或者：

sudorm-rf"/mnt/c/Program Files"

这确实比仅共享用户目录危险得多。

原因主要有三个。

1. WSL 被设计成 Windows 的一部分，而不是沙箱

微软的设计理念是：

Windows + Linux = 一个开发环境

而不是：

Windows ↓ 虚拟机 ↓ Linux

他们希望 Linux 程序能够像 Windows 程序一样访问整个文件系统。

例如：

cd/mnt/c/Windows/System32

grepsomething *.log

find/mnt/c-name"*.dll"

对于系统管理员、运维、开发者来说，这种能力是有价值的。

如果只开放：

C:\Users

很多运维场景就做不了了。

2. Windows 权限模型本来就在保护系统文件

微软可能认为：

Linux 进程最终也是以 Windows 用户身份访问文件。

例如：

rm/mnt/c/Windows/explorer.exe

实际上会经过 Windows 的 NTFS 权限检查。

很多关键文件属于：

TrustedInstaller SYSTEM Administrators

普通用户并没有删除权限。

所以很多危险操作会失败。

但是——

这只能保护一部分文件。

用户有权限的内容：

C:\Users C:\Downloads C:\Documents

仍然可以被删掉。

因此风险依然存在。

3. WSL 最初的目标用户不是 AI Agent

这一点很关键。

WSL 最早发布于 2016 年。

当时微软假设的用户是：

• Linux 开发者
• DevOps
• 运维工程师
• 程序员

而不是：

Claude Code OpenAI Codex Cursor Agent Gemini CLI

这种能够自动执行命令的 Agent。

在 2016 年的设计视角里：

rm-rf/mnt/c/Windows

属于“用户自己作死”。

因为默认认为：

执行命令的人理解自己在做什么。

而今天情况变了。

很多人已经开始：

Agent ↓ Shell ↓ WSL ↓ /mnt/c

这时候风险确实明显上升。

从今天（2026）的角度看

如果让我重新设计 WSL，我可能会这样做：

默认： /mnt/c/Users 高级模式： /mnt/c

或者：

Agent Safe Mode 不挂载系统目录 Developer Mode 挂载整个磁盘

这样更符合现在 AI Agent 大量执行 Shell 命令的现实。

但 WSL 的设计比 Claude Code、Cursor、Codex 这些产品早了接近十年，当时几乎没人考虑过“自动化 Agent 误删主机系统”这个问题。

所以你的直觉其实没错：

对于 AI Agent 时代来说，默认暴露整个/mnt/c确实是一种偏危险的设计。

很多使用 Claude Code 的开发者现在会刻意：

~/projects

工作在 WSL 自己的 ext4 文件系统里，甚至直接禁用自动挂载，原因正是为了降低 Agent 或脚本误操作影响到 Windows 主机的风险。

规避手段或解决方法

不要把项目放在 Windows 文件系统（/mnt/c/...）里，而是放在 WSL 自己的 Linux 文件系统里。

很多人刚开始这样用：

/mnt/c/Users/yourname/projects/my-app

实际上对应：

C:\Users\yourname\projects\my-app

Claude Code、Cursor、Agent、脚本操作的是真实的 Windows 文件。

如果 Agent 失控：

rm-rf../*

删掉的可能是：

C:\Users\yourname\Documents C:\Users\yourname\Downloads C:\Users\yourname\Pictures

甚至更糟。

推荐方式

项目放到：

/home/<username>/projects

例如：

mkdir-p~/projectscd~/projectsgitclone https://github.com/xxx/my-app.git

目录变成：

Ubuntu └── /home/xiang/projects/my-app

而不是：

Windows └── C:\Users\xiang\projects\my-app

此时：

pwd

显示：

/home/xiang/projects/my-app

而不是：

/mnt/c/Users/xiang/projects/my-app

WSL 文件到底存在哪里？

实际上存储在一个虚拟磁盘文件里：

ext4.vhdx

位置通常类似：

C:\Users\<user>\AppData\Local\Packages\ CanonicalGroupLimited... \LocalState\ ext4.vhdx

你在 Linux 看到的是：

/home /etc /var /usr

这些都在这个虚拟磁盘里面。

因此：

rm-rf~/projects/test

只会影响 Linux 环境。

不会直接删除：

C:\Users C:\Windows C:\Program Files

VS Code 能正常工作吗？

完全没问题。

推荐这样启动：

cd~/projects/my-app code.

VS Code 会自动连接 WSL。

左下角会显示：

WSL: Ubuntu

此时：

• Python 在 WSL 运行
• Node.js 在 WSL 运行
• Git 在 WSL 运行
• Claude Code 在 WSL 运行

全部都在 Linux 环境。

这是目前最推荐的开发方式。

Docker Desktop 也是这样工作的

你前面提到：

Windows └── WSL2 Ubuntu ├── Claude Code ├── Python ├── Node.js ├── Git └── Docker CLI

其实 Docker Desktop 官方推荐也是：

~/projects

而不是：

/mnt/c/projects

因为：

• 文件 IO 更快
• inode 支持完整
• 文件权限正常
• watch 机制稳定
• Git 性能更好

如何彻底禁止访问/mnt/c

如果你非常担心 Agent 误删 Windows 文件，可以关闭自动挂载。

编辑：

sudonano/etc/wsl.conf

写入：

[automount] enabled = false

保存后退出。

然后在 Windows PowerShell：

wsl--shutdown

重新打开 Ubuntu。

此时：

ls/mnt

结果大概是：

空目录

或者：

c 不存在

这时候：

cd/mnt/c

会直接报错。

Claude Code 也无法访问 Windows 系统盘。

我个人更推荐哪种？

对于使用 Claude Code 的开发者，我更推荐：

✓ 项目放在 ~/projects ✓ Git 仓库放在 ~/projects ✓ Docker Engine 运行在 Docker Desktop，Docker CLI 运行在 WSL ✓ VS Code Remote WSL ✗ 不关闭 /mnt/c（可能有副作用）

原因是：

• 日常仍可访问下载目录
• 复制文件方便
• 不影响 Docker Desktop 集成
• 不影响 VS Code

只要养成一个习惯：

cd~/projects

而不是：

cd/mnt/c/Users/xxx/project

那么 Claude Code、Agent、脚本绝大部分操作都会被限制在 Linux 的 ext4 虚拟磁盘里，误伤 Windows 的概率会大幅降低。

真正会关闭/mnt/c自动挂载的人其实不多，通常是安全要求较高的开发环境或者经常运行高权限自动化 Agent 的用户。