企业官网建设流程全解析

1. 从一次C盘爆红说起：为什么“删文件”是最差的第一反应

那天下午，我正在赶一个项目的收尾，编辑器突然卡住，接着系统弹窗提示“C盘空间不足”。切到资源管理器一看，C盘那条进度条红得发紫，剩余空间不到2GB。第一反应和大多数人一样：打开C盘，找几个大文件夹删掉。但鼠标悬停在Windows、Program Files这些目录上时，我停住了——这些地方删错一个文件，系统可能直接起不来。

真正让我冷静下来的，是一个更基础的问题：我根本不知道空间到底被谁吃了。凭感觉删，删掉的可能是重要缓存，留下的才是真正的空间黑洞。这种“盲删”思路，是C盘清理里最大的坑。

后来我用Codex配合PowerShell做了一次完整的磁盘占用分析，结果出来的时候确实有点意外：AppData目录占了87.81GB。这个数字意味着什么？一台256GB固态的笔记本，光用户配置目录就吃掉了超过三分之一。更关键的是，AppData里大部分内容是不能直接右键删除的，它藏着大量应用运行时的缓存、配置、临时文件，删错了轻则软件重装，重则用户配置丢失。

这篇内容适合两类人看：一类是C盘已经飘红、正在到处找“C盘清理大师”这类工具的人；另一类是平时用Codex写代码、想把它用到系统运维场景里的开发者。我会把整个排查链路、Codex在其中的角色、AppData里哪些能动哪些不能动，以及最后实际释放了多少空间，完整讲一遍。全程不推荐任何来路不明的清理软件，只用系统自带能力和Codex辅助分析。

提示：C盘爆红时，第一件事不是删文件，而是搞清楚空间分布。盲目删除系统目录或用户配置目录，风险远大于收益。

2. 为什么我选择Codex而不是现成的清理工具

2.1 现成清理工具的“黑箱”问题

市面上叫“C盘瘦身专家”“C盘清理大师”的工具不少，有些甚至是捆绑安装进来的。这类工具的通病是：扫描完给你一个“可清理XX GB”的数字，点一下“一键清理”，然后你也不知道它到底删了什么。更麻烦的是，部分工具会把应用缓存当成垃圾清掉，导致某些软件下次启动时重新下载资源，或者配置丢失。

我不是说这些工具完全不能用，而是当C盘占用达到87GB这种量级时，你需要的是可解释、可追溯的分析，而不是一个黑箱按钮。Codex在这里的价值，是它能根据你的自然语言描述，生成针对性的PowerShell分析脚本，并且你可以逐条审查脚本逻辑，确认它只做“统计”不做“删除”。

2.2 Codex在系统分析场景里的实际定位

Codex本质上是一个代码生成与辅助工具，它不直接操作你的文件系统。你描述需求，它给出脚本或命令，执行权始终在你手里。这个特性在磁盘清理场景里特别重要——因为清理本身是高危操作，任何自动化删除都应该经过人工确认。

我实际用下来的流程是这样的：先用Codex生成一个递归统计目录大小的PowerShell脚本，跑出结果后，把占用最大的几个子目录路径再丢给Codex，让它分析这些目录分别属于什么应用、是否可安全清理。整个过程是“分析—确认—再分析”的循环，而不是“一键删除”。

2.3 环境准备：PowerShell执行策略与编码问题

在跑脚本之前，有两个坑必须先填掉。第一个是PowerShell的执行策略。默认情况下，Windows不允许运行未签名的脚本，你会看到“无法加载文件，因为在此系统上禁止运行脚本”的报错。解决办法是以管理员身份打开PowerShell，执行：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

RemoteSigned的含义是：本地写的脚本可以直接跑，从网络下载的脚本需要签名。这比直接设成Unrestricted安全得多。

第二个坑是中文乱码。PowerShell默认编码在某些系统上是GBK，而脚本文件如果是UTF-8，中文路径就会显示成乱码。解决方法是在脚本开头加上编码声明，或者在PowerShell里先执行：

[Console]::OutputEncoding = [System.Text.Encoding]::UTF8 $OutputEncoding = [System.Text.Encoding]::UTF8

这两行加上之后，中文目录名就能正常显示了。别小看这个细节，AppData下面很多目录名包含应用名称，乱码会让你根本判断不出这是哪个软件的数据。

注意：执行策略的修改只影响当前用户，不会改动系统级设置。如果公司电脑有组策略限制，可能需要联系IT，不要强行绕过。

3. 用Codex生成磁盘占用分析脚本的完整过程

3.1 第一版脚本：递归统计目录大小

我给Codex的描述很直接：“写一个PowerShell脚本，统计指定目录下每个子目录的总大小，按从大到小排序，输出前20个。”它给出的核心逻辑是这样的：

param( [string]$TargetPath = "C:\Users\Administrator\AppData" ) Get-ChildItem -Path $TargetPath -Directory -Force | ForEach-Object { $size = (Get-ChildItem -Path $_.FullName -Recurse -File -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum [PSCustomObject]@{ Folder = $_.FullName SizeGB = [math]::Round($size / 1GB, 2) } } | Sort-Object SizeGB -Descending | Select-Object -First 20 | Format-Table -AutoSize

这段脚本有几个关键点值得说。-Force参数让Get-ChildItem能读取隐藏目录和系统目录，AppData里很多缓存目录是隐藏的，不加这个参数会漏统计。-ErrorAction SilentlyContinue用来跳过没有权限访问的目录，否则脚本会频繁报错中断。Measure-Object -Property Length -Sum是统计文件大小的标准做法，比手动累加可靠。

3.2 实测结果：87.81GB是怎么分布的

脚本跑完，输出让我有点意外。AppData下排名靠前的目录大致是这样的分布：

加起来正好在87GB上下。这里要说明的是，Temp目录22GB这个数字本身就不正常，正常情况下一两GB顶天了。后来排查发现是某个应用反复写入临时文件但从不清理导致的。

3.3 脚本的局限与第二版改进

第一版脚本有个明显问题：它只统计了顶层子目录，如果某个目录下面还有深层的大文件，会被合并成一个总数，看不出具体是哪个子目录在膨胀。比如AppData\Local\Packages下面有几十个UWP应用各自的目录，18GB具体是哪个应用占的，第一版看不出来。

于是我让Codex改了第二版，增加递归深度控制，并且对超过1GB的子目录单独展开：

function Get-FolderSize { param([string]$Path) $sum = (Get-ChildItem -Path $Path -Recurse -File -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum if ($null -eq $sum) { return 0 } return [math]::Round($sum / 1GB, 2) } Get-ChildItem -Path $TargetPath -Directory -Force | ForEach-Object { $topSize = Get-FolderSize $_.FullName if ($topSize -gt 1) { Write-Output "=== $($_.Name) : $topSize GB ===" Get-ChildItem -Path $_.FullName -Directory -Force -ErrorAction SilentlyContinue | ForEach-Object { $subSize = Get-FolderSize $_.FullName if ($subSize -gt 0.5) { Write-Output " $($_.Name) : $subSize GB" } } } }

第二版跑出来的信息量就大很多了。比如Packages下面，某个视频类应用的数据目录单独占了6GB，Google下面Chrome的Cache和Code Cache加起来占了8GB。这些细节才是决定“删什么”的依据。

4. AppData里哪些能清、哪些碰不得：逐目录拆解

4.1 Temp目录：可以清，但要注意占用中的文件

AppData\Local\Temp是临时文件目录，理论上里面的文件都可以删。但实际操作时，如果有程序正在运行，它占用的临时文件是删不掉的，强行删会报“文件正在使用”。正确做法是：先关闭所有非必要应用，然后用系统自带的磁盘清理工具，或者手动删除时跳过报错的文件。

我自己的做法是保留最近7天的临时文件，只删更早的。因为有些应用会把临时文件当缓存用，删太干净反而导致下次启动变慢。用PowerShell可以这样筛选：

$cutoff = (Get-Date).AddDays(-7) Get-ChildItem -Path "$env:LOCALAPPDATA\Temp" -Recurse -Force -ErrorAction SilentlyContinue | Where-Object { $_.LastWriteTime -lt $cutoff } | Remove-Item -Recurse -Force -ErrorAction SilentlyContinue

-ErrorAction SilentlyContinue在这里是必须的，因为总有一些文件被占用，脚本不应该因为个别文件失败就中断。

4.2 Packages目录：UWP应用数据，不能直接删

AppData\Local\Packages存放的是UWP（通用Windows平台）应用的数据。这个目录绝对不能直接删除，因为每个子目录对应一个已安装应用，删了会导致应用无法启动或数据丢失。正确的清理方式是通过应用自身的设置来清理缓存，或者用系统“设置—应用—已安装的应用”里的“高级选项—重置”功能。

如果某个UWP应用占用特别大，比如视频缓存类应用，优先在应用内部找“清除缓存”选项。实在找不到，可以考虑卸载重装，但要注意备份应用内的个人数据。

4.3 浏览器缓存：清理收益高，但会牺牲加载速度

AppData\Local\Google\Chrome\User Data\Default\Cache这类目录，清理收益通常很可观，几个GB很常见。代价是清理后首次访问常用网站会变慢，因为缓存要重新建立。我的建议是保留，除非你真的缺空间。如果一定要清，在浏览器设置里用“清除浏览数据”功能，勾选“缓存的图片和文件”，比手动删目录安全。

4.4 NVIDIA缓存与uv缓存：开发者常忽略的空间大户

AppData\Local\NVIDIA\DXCache和AppData\Local\uv这两个目录，普通用户可能不关注，但对开发者和游戏玩家来说很常见。DXCache是显卡着色器缓存，删了之后游戏或图形应用首次运行会重新编译着色器，可能卡顿几分钟，但之后会恢复。uv是Python包管理工具的缓存，删了不影响已安装的包，只是下次安装时需要重新下载。

这两个目录的清理策略是：如果你空间紧张，可以清；如果空间还够，留着能提升日常使用体验。

提示：任何位于AppData下的目录，删除前先确认它不属于正在使用的应用。最稳妥的方式是关闭相关应用后再操作。

5. 实际清理操作与效果验证

5.1 分阶段清理策略

我没有一次性全清，而是分了三步。第一步清Temp目录里7天以上的文件，释放了大约15GB。第二步清浏览器缓存和NVIDIA缓存，释放了约12GB。第三步处理uv缓存和编辑器缓存，释放了约8GB。三步加起来释放了35GB左右，C盘从爆红恢复到有充足余量。

分阶段的好处是，每清完一步都能观察系统是否正常。如果某个应用出问题，能快速定位是哪一步导致的。

5.2 清理后的验证方法

清理完不能只看剩余空间数字，还要验证关键应用是否正常。我的检查清单是：浏览器能否正常打开常用网站、编辑器能否正常启动并加载之前的项目、Python环境能否正常安装包、游戏能否正常启动。这几项都过了，才说明清理没有误伤。

另外建议清理后用之前的分析脚本再跑一遍，确认目标目录确实变小了，而不是被其他目录的增长抵消了。

5.3 一个反直觉的发现：清理后空间又快速回升

清理完一周后，我发现C盘空间又少了几个GB。重新分析发现，Temp目录又涨回来了。这说明有个应用在持续产生临时文件且不自动清理。这种情况下，单纯清理是治标不治本，需要找到那个应用并调整它的配置，或者设置一个定期清理任务。

我用PowerShell建了一个每周执行一次的清理任务，只清Temp目录里超过14天的文件。这样既不会误删近期需要的临时文件，又能防止空间被慢慢吃光。

6. 把Codex用成系统运维助手的几点心得

6.1 描述需求时要具体到“可执行”

Codex生成脚本的质量，很大程度上取决于你的描述。说“帮我清理C盘”这种模糊需求，它只能给通用建议。说“统计AppData下每个子目录大小，按GB排序，输出前20个，跳过无权限目录”，它就能给出可直接跑的脚本。描述里包含路径、排序方式、输出格式、异常处理，生成结果就靠谱得多。

6.2 永远先审查再执行

Codex生成的脚本，尤其是涉及删除操作的，一定要逐行看一遍。重点看Remove-Item的路径参数是不是你预期的目录，有没有-Recurse和-Force这种危险组合作用在错误的路径上。我自己的习惯是，任何删除脚本先在测试目录跑一遍，确认行为符合预期再应用到真实目录。

6.3 编码和权限是Windows脚本的两大拦路虎

前面提到的执行策略和中文乱码，几乎每次在新机器上跑PowerShell脚本都会遇到。把这两项准备工作做成一个初始化脚本，每次新环境先跑一遍，能省很多排查时间。另外，涉及系统目录的操作，记得用管理员身份运行PowerShell，否则很多目录连读取权限都没有。

6.4 定期分析比临时救火更有效

C盘爆红往往是长期积累的结果。与其等爆红了再手忙脚乱，不如每个月跑一次分析脚本，看看哪个目录在持续增长。发现异常增长就及时处理，比一次性清几十GB轻松得多。我现在把分析脚本设成了每月初自动运行，输出结果存到日志文件里，翻看历史记录就能看出趋势。

这套方法用下来，最大的感受是：C盘清理的核心不是“删得快”，而是“看得清”。Codex在这里扮演的角色，是帮你把模糊的“空间不够”变成具体的“哪个目录、哪个应用、占了多少”。有了这个清晰度，删什么、留什么、怎么删，都是水到渠成的事。