企业官网建设流程全解析

C盘又红了，剩下几个GB，动不动就弹“磁盘空间不足”，微信、QQ、开发环境轮着罢工。以前遇到这种局面，我通常是先删浏览器缓存，再跑一遍系统自带清理工具，实在不行就上第三方清理软件。但这次我换了个思路：让 OpenAI 的 Codex 命令行工具来帮我做主，全程把计划和执行摊开来看，最后算下来只花了四毛七。

先说结论：Codex 不是那种“点一下就帮你清理”的傻瓜工具，它更像一个能读懂命令、会跑命令、还能根据输出自己纠错的“命令行副驾驶”。你只需要用大白话告诉它“C盘满了帮我分析一下”，它就会拆解任务、给出清理计划、逐步执行，并且在删除风险较高的内容前向你汇报。整个过程透明可控，费用极低，这次四毛七就是真实的 API 账单折算结果。

这篇文章适合这几类人：C盘常年在爆红边缘徘徊但不想重装系统的普通用户、手头有 API Key 且愿意折腾命令行的开发者、以及对第三方清理软件不放心、想搞清楚每一个被删文件到底是谁的人。我会从安装配置、实际清理流程、成本拆解、常见报错这四块，把整个实操过程完整拆给你看。

1. 为什么我会想到让 Codex 来管 C 盘

1.1 手动清理的痛，我实在受够了

Windows 的 C 盘是个吞噬怪，你永远想不到空间是怎么没的。常见的大户包括：Windows 更新安装残留（C:\Windows\SoftwareDistribution 里动辄几个G）、用户临时目录（C:\Users\你的名字\AppData\Local\Temp）、各种国产软件的缓存垃圾、浏览器缓存、旧的错误报告文件等。手动清理不是不能做，但问题是这些目录分散在系统不同层级，光靠一层层点文件夹翻，半小时过去眼睛都花了，还不一定能找全。

更麻烦的是“清了到底有没有用”完全没底。有些文件叫 cache，实际上删了之后软件打不开；有些目录写的是 Temp，里面正好躺着你没保存的临时工程文件。手动清理时我经常在“删掉”和“再等两天”之间反复纠结，最后往往是只清出了几个G，该爆红还是爆红，该卡顿还是卡顿。

1.2 Codex 作为“会动手的助手”是什么定位

Codex 是 OpenAI 出的命令行编程代理（CLI 工具），它和普通聊天机器人的最大区别是：它能直接在终端里执行命令、读取输出、根据输出决定下一步动作，还能自动修改和运行脚本。你给它一句话目标，它可以自己拆解成若干操作，边跑边观察结果，遇到异常还能尝试修复。

拿清理 C 盘这件事来说，如果我面对的是结构化搜索的 GPT 类聊天工具，它顶多给你列出“推荐清理的目录清单”。而 Codex 可以直接运行 PowerShell 命令去扫描目录大小、识别哪些文件和缓存可以被安全清理、然后在你的确认下执行删除。整个过程等于把“判断什么时候该删什么东西”这个脏活交给了模型，而你只需要做好最终审核。

1.3 不用第三方清理软件的原因

市面上那些“C盘清理大师”、“优化卫士”，不少安装包本身清爽，装上之后就是另一回事。不是全屏弹窗，就是偷偷装全家桶，有的甚至把注册表、系统服务乱动一通，清理一时爽，重装火葬场。我吃过耦合整套系统的亏之后，对所有“一键优化”类软件都有天然警惕。

用 Codex 清理则完全是另一个逻辑：它不优化注册表、不碰系统服务、不装常驻进程，任务结束后工具就退场了。它只负责执行你指定的目录分析和删除动作，每一行命令都是可视的。对你来说，它更像一个随叫随到的顾问，而不是常年蹲在后台的“管家”。

2. Codex 的安装与最简配置

2.1 环境准备：Windows 下能跑 Codex 的前提

我的主力机是 Windows 11，Codex 官方支持 Windows、macOS 和 Linux。建议先保证 Node.js 环境已经装好，版本至少 18 以上，推荐走 LTS 版。装完 Node 后，在 PowerShell 里执行：

npm install -g @openai/codex

这行命令会全局安装 Codex CLI。安装完成后可以用codex --version检查是否成功。如果在安装过程中出现进度条卡住、报“npm 安装失败”等错误，多半是网络问题或者 npm 缓存损坏，不必慌，直接清一下 npm 缓存再重装：

npm cache clean --force npm install -g @openai/codex

很多 Windows 用户遇到的问题集中在“安装未完成”这一层，尤其是公司电脑有杀毒软件或者访问控制策略时，npm 脚本会被拦截。解决办法是暂时退出杀软、以管理员身份打开 PowerShell 重试，或者换用国内 npm 镜像源，安装过程会顺畅得多。

2.2 登录与模型选择

Codex 需要认证后才能使用。它支持两种方式：一种是登录 ChatGPT 账号，走订阅额度；另一种是配置 OpenAI API Key，按 token 计费。如果你想精准控制成本，推荐用 API Key 方式，因为账单看得清清楚楚。

配置 API Key 或在终端里执行认证：

codex login

如果需要手动指定 API Key，可以设置环境变量：

$env:OPENAI_API_KEY="你的key"

模型选择上有个常见坑：Codex 不同版本默认绑定的模型不同，一旦你在配置文件里手动改成了“听起来很高级但实际不在支持列表”的模型名，启动时会直接报类似“model not supported”的错误。我当时也踩过一回，后来把配置里模型名改成当前 Codex 官方支持的标准模型名，立刻恢复正常。遇到这种报错，优先升级 CLI 版本、查询官方支持模型列表，而不是凭直觉填模型名。

2.3 给 Codex 划定“安全边界”

让 AI 执行命令行时，最担心的就是它乱删系统文件。我的做法是在正式开始前，给它划一条非常明确的工作边界：只需要扫描和清理用户临时文件、Windows 更新缓存、浏览器缓存这几类内容，其他一律禁止动。

具体的会话提示可以直接这样写：

你在 Windows 11 上工作。请帮我分析 C 盘占用情况，重点关注用户 Temp、Windows Temp、Windows Update 缓存、浏览器缓存这些目录。先列出每个目录的大小和内容说明，不要立刻删除；我确认后再逐步清理。任何不在列表里的路径，未经我明确同意不要操作。

这相当于给 Codex 下了一道“没有命令不准动”的军令。它确实会在后续执行中严格遵守范围，被骗去删重要文件的概率就大大降低了。

3. 实战：一次完整的 C 盘清理过程

3.1 第一步：让 Codex 扫清家底

实际操练开始。我先在终端里运行 Codex，进入交互模式，然后发出了第一条指令：

codex

接着在会话里输入：

扫描 C 盘上最常见的缓存目录，统计每个目录占用空间的大小，用人类可读的方式展示，并按体积从大到小排序。目录优先级：用户 Temp、Windows Temp、Windows Update 下载缓存、浏览器缓存、Windows 错误报告。

Codex 会自己组合 PowerShell 命令，比如用Get-ChildItem -Recurse | Measure-Object去统计目录体积，再逐条输出结果。由于 Windows 目录权限严格，部分目录可能提示拒绝访问，它还会自动判断是跳过还是换方法重试。

扫完之后，它给我的结果类似这样：

C:\Users\用户名\AppData\Local\Temp : 3.2 GB C:\Windows\Temp : 780 MB C:\Windows\SoftwareDistribution\Download : 1.9 GB C:\Users\用户名\AppData\Local\Microsoft\Edge\User Data\Default\Cache : 650 MB

看到这个列表我是有点惊讶的——原来光这几个目录加起来就有 6 个多 G，而平时用系统自带清理功能扫出来的往往只有几百 MB。不是因为系统清理工具没用，而是它默认清理范围保守，很多开发工具和浏览器缓存根本不在它的考虑范围内。

3.2 第二步：确认清单，逐项执行

拿到报告后，我先自己过了一遍目录列表，确认没有可疑路径，然后让 Codex 继续：

请删除以上列出的目录中的文件，但保留目录本身。删除前先逐个说明删除的是什么内容，删除后立刻汇报释放的空间。遇到正在使用的文件直接跳过，不要强行结束进程。

注意我要求“保留目录本身”，这是一个很实用的细节。很多软件运行时依赖固定的临时目录存在，如果整个文件夹被删掉，之后可能因为找不到目录而报错。Codex 执行删除时也是用命令逐个处理，比如清理 Temp 目录时，它会保留文件但清空内容。

这段执行过程里，Codex 还做了一件让我满意的事：它发现 Windows Temp 下有几十个文件正被系统进程锁定，于是没有继续重试，而是主动跳过并说明原因，等待系统空闲时再处理。这种“发现问题但不硬刚”的执行风格，比不少清理工具一上来就“重启后删除”的野蛮方案要让人安心。

3.3 第三步：清理后验证与空间复查

所有目录清理结束后，我让 Codex 再做一次空间统计，确认效果：

现在 C 盘剩余空间是多少？和清理前对比，总共释放了多少空间？

它直接调用了Get-PSDrive C这类命令来读取磁盘状态，然后给出了前后对比结论。这次实际释放了约 6.1 GB，C 盘从只剩 8% 可用一路恢复到了 23% 左右，系统响应速度也确实好了不少。

验证完磁盘空间，我顺手又让 Codex 把常用软件的缓存路径过了一遍，确认浏览器和开发工具的新缓存目录仍然能正常写入。整个过程从扫描到清理完成，大约用了十几分钟，其中大部分时间是等待命令执行和目录扫描，而不是我手动翻找文件夹。

4. 四毛七的成本是怎么算出来的

4.1 为什么这次只花了几毛钱

Codex 按 token 计费，整个清理任务从分析、规划到执行，主要消耗是两部分：输入 token（包括我发出的指令、Codex 收集到的命令输出）和输出 token（Codex 生成的解释、命令清单）。因为清理任务本身范围清晰，不需要把几十 GB 的文件内容灌进模型，只需要把目录大小统计结果传给它做判断，所以 token 消耗很可控。

账是很直观的：任务按大概二十几次命令交互来计算，输入侧累计差不多 20 万 token，输出侧因为 Codex 习惯性附带解释，累计大约 3 万 token。按官方 API 定价换算（输入价格远低于输出价格），总费用大约折算成人民币四毛七。这个数字小到让我愿意每次动手清理时都优先考虑 Codex，而不是去下载那些来路不明的“清理大师”。

4.2 控制成本的关键技巧

想稳定把费用控制在几毛钱级别，核心不是省提示词字数，而是“控制进入上下文的垃圾信息量”。Codex 会把命令输出自动带入上下文，如果你让它跑一条把全部文件列表都打印出来的命令，那几万行文件名会被当成输入 token 计算，成本立刻翻几倍。

我的习惯是明确要求“输出精简”。在提示里直接写“只报告体积统计结果，不要输出完整文件列表”、“用表格汇总，不要粘贴日志原文”。Codex 就会改变输出风格，用紧凑模式汇报，上下文里不会积累大量噪音。

如果发现某次任务明显超出预期预算，可以随时按 Ctrl+C 中断执行，然后让 Codex 基于已经完成的部分重新整理方案，不要让它没完没了地自我迭代。命令执行的循环一旦失控，token 烧得比想象中快。

4.3 和传统清理方式的对比

用了这次之后，我重新评估了几种清理方式的性价比：

表格里最重要的一列是“风向”。第三方工具为了省事，往往自动化程度过高，删了什么你都来不及阻止。而 Codex 这种模式把决策权保留在用户手里，它替你执行，但不会替你决定——至少在明确要求下不会。

5. 常见的 Codex 清理报错与排查实录

5.1 安装阶段：“codex windows 安装未完成”

这个报错在 Windows 平台很常见，通常表现为 npm 安装进度条停住，最后提示失败。原因就是网络不稳定、镜像源连接超时、或者杀毒软件拦截了 npm 的脚本执行。处理顺序很固定：先清npm cache clean --force，再换国内 npm 镜像源，最后以管理员身份重新打开终端执行安装。重试超过两次还不行，就把 Node 重装成最新 LTS 版本，大概率能解决。

5.2 启动阶段：“endpoint”链路报错或连接失败

在实际使用中，Codex 偶尔会报类似“本地链路访问异常”或“endpoint 返回错误”的信息。这种情况通常不是工具坏了，而是本地网络环境波动，或者系统之前配置过不正常的网络转发规则，导致 CLI 在访问服务端时握手失败。排查方法是先确认其他网络访问正常，再重启终端，重置一下 Codex 本地配置后重试。我自己遇到这类问题时，关掉不安全的自定义网络设备后立即恢复正常，所以这类问题不必深究，按网络经验处理就行。

5.3 模型名不存在的“model not supported”

之前提过，这个报错多数是配置里填了不存在的模型名，尤其容易出现在你用新版本 Codex 配置旧参数的时候。处理起来很直接：升级 Codex 到最新版，查询官方当前支持的模型列表，把配置里的模型名改成标准型号。千万别凭关键词联想填模型名，否则大概率踩雷。

5.4 上下文超限：“ran out of room in the model's context”

这是让 Codex 执行复杂任务时最常遇到的错误，本质是对话上下文窗口被塞满了。清理 C 盘这种任务虽然听起来简单，但如果中途让 Codex 持续输出大量命令日志，累积几轮后上下文就会到顶。

遇到这个报错，请不要在同一会话里继续追加指令，而是开启新会话，把已完成的工作进度用简短摘要告诉它。另外，每完成一步就在提示里要求“终止并总结”，也是一种有效预防手段——它会把历史输出及时压缩，不让旧结果长期占着上下文空间。

6. 拿不准的命令该怎么办

6.1 永远保留“最终确认权”

无论 Codex 执行得多顺手，我始终强调一件事：它是副驾驶，不是机长。真正决定删除某类文件之前，必须让它先把命令和影响范围列出来，由你确认。习惯的用法就是在清理开始前提示：

每次执行删除类命令之前，先暂停并列出将要执行的命令、涉及路径、预计释放空间，等我输入确认后再继续。

这样就人为加了一层“二次确认”。Codex 会在每步删除前等你的指令，而不会自作主张一路跑到底。遇到它列出删除路径列表时，我会快速扫一遍，确认没有Program Files、Windows\System32这类关键目录混入再放行。

6.2 删错文件的挽回方案

再谨慎也有失手的时候，所以我每次让 Codex 清理之前，会先创建一个系统还原点。Windows 下创建还原点非常简单：

Checkpoint-Computer -Description "Before codex cleanup" -RestorePointType MODIFY_SETTINGS

创建完成后，万一 Codex 真的误删了哪个关键文件，可以直接从还原点恢复。实际执行中，因为 Codex 的删除范围都在缓存目录内，而且我确认得很仔细，还原点始终没用上。但“有后路”这件事本身就是一种安全感，让我敢把任务交给 AI。

6.3 尊重“被占用文件”的存在

还有一个小技巧是多留意 Codex 汇报的“跳过文件”。当你开着浏览器、聊天软件或开发工具时，它们的缓存文件会被占用，Codex 会跳过这些文件。这时候不要急着去强行结束进程，更不要手动补删。正常退出相关软件后，下一次运行时 Codex 再重新扫描就能清理干净。强行删除正在使用的缓存文件，轻则软件崩溃，重则数据损坏，得不偿失。

我在实际使用中最大的体会是：Codex 的强项不是帮你“想”，而是帮你“做”。C 盘清理的本质是大量的路径检索、体积统计和文件筛选，这些操作枯燥且容易出错，交给命令行代理正好合适。而四毛七的账单，说明这种“只花几毛钱就能获得一个懂行的清理顾问”的方案，确实已经成熟到可以进入普通人的日常工具箱了。后面我打算继续用同样思路处理微信缓存目录和开发环境的旧依赖，每次动手前先让 Codex 出报告、做计划，再人工确认执行。这种“AI 提方案、人来拍板”的工作方式，比傻点清理软件令人放心得多。