在 Codex 100 个真实案例系列里有一类项目最容易让人产生“原来 AI 编程已经这么顺手了”的感触——那就是 AI 生成一个轻量级的服务器监控面板。它看起来不算复杂却能把 CPU、内存、磁盘这些服务器核心指标统一到同一个网页里展示不需要每次排查问题时都登录服务器敲top、free、df。这篇文章我会用一次完整的实战过程复盘如何通过 Codex 从零生成一个可运行的服务器监控面板。内容会覆盖背景概念、环境准备、后端接口设计、前端页面生成、Codex 提示词写法、启动验证、常见报错以及生产环境注意事项。无论你是刚接触 AI 编程的初学者还是想快速给手里几台服务器做一个可视化小工具的开发者都可以按照下面的步骤实际操作一遍。需要提前说明的是AI 生成代码带有一定随机性不同版本、不同入口的 Codex 产出的代码结构可能不完全一致但整体的任务拆解思路是通用的。下面我会以稳定的“用自然语言拆任务再让 Codex 读写本地项目”的方式展开代码部分也会给出可运行版本供你对比参考。1. 为什么选择用 Codex 做服务器监控面板1.1 先认清 Codex 的角色Codex 不是传统意义上的“代码自动补全工具”它更接近一个能理解项目上下文的 AI 编程智能体。我们可以在对话里描述目标比如“帮我创建一个监控服务器 CPU、内存、磁盘的网页项目”Codex 会自己规划步骤创建文件、安装依赖甚至运行命令来验证结果。这一点对做小工具非常关键。过去我们自建一个监控面板通常需要自己完成这些动作选择合适的后端语言和框架设计数据采集逻辑规划前端展示方式解决接口跨域或静态资源目录问题反复启动服务、调试报错。如果用 Codex你只需要把需求描述得足够清楚让它在当前项目目录中逐步完成这些步骤。你真正要做的是给出清晰的任务边界、审查生成代码、在关键位置把关安全和权限。1.2 这类监控面板适合什么场景监控面板并不是越重越好。如果你已经拥有几十台、上百台服务器需要告警、权限、历史数据图表等完整能力那更适合直接引入 Prometheus Grafana 或 Zabbix 这类成熟系统。但如果你只是希望快速查看几台测试服务器、内部小业务主机的 CPU 和内存状态或者希望用最少代码加一个透明可修改的运维入口那么自己写一个轻量面板会更高效。这次案例的价值在于它不只是教你抄一块代码而是展示一个从自然语言需求到最终可运行页面的完整链路。你以后还可以把同一个思路复用到其他内部小工具上比如 API 健康检查页、定时任务执行状态页、日志关键字监控页等。1.3 为什么不用现成的开源监控软件在用 Codex 写监控面板之前我确实也考虑过 Grafana。Grafana 很好但它有学习成本和部署成本为了看一台机器的 CPU 和内存而启动一堆组件对轻量场景来说并不划算。自己写监控面板的另一个好处是可控。采集什么字段、展示什么指标、多久刷新一次、是否需要在页面做告警都可以按自己的习惯改。如果后续哪天需要接入企业微信、钉钉或邮件告警扩一个函数就行。这个案例正好说明了 Codex 的定位它不会替代大型监控平台但非常适合做“临时看板”“内部自动化小工具”“可定制运维页面”这一类开发任务。2. 面板要采集哪些指标2.1 CPU不只是看一个百分比服务器监控面板里的 CPU 指标最基础的是“使用率百分比”。我们通常会用top或htop看到系统整体 CPU 使用率也会看到用户态us、系统态sy、空闲id、等待 I/Owa等细分项。对第一版面板来说先展示整体使用率和每核使用率就足够了。之所以要看每核使用率是因为某些应用是单线程密集型即使整机 CPU 只有 30%也可能有一个核心已经跑到 100%。如果只展示总使用率很容易漏掉这类性能瓶颈。在 Python 中psutil.cpu_percent(intervalNone)可以拿到从上次调用到当前时间之间的平均 CPU 使用率。需要注意这个函数第一次调用通常返回 0.0因此更合理的做法是让监控服务一直运行由前端每隔几秒请求一次接口让后端内部不断产生有效的采样结果。2.2 内存用 available 而不是 free内存指标看起来简单实际有一个很容易踩的坑Linux 的free命令会区分 total、used、free、buff/cache 等字段。很多新手会把 used 当成真实占用但在 Linux 中Page Cache 这类内存会被系统用来做磁盘缓存在内存紧张时可以被内核回收所以free显示的并不完全等于“不能再分配的内存”。psutil 提供给我们的virtual_memory()里有三个常用字段total物理内存总量available在不触发明显交换的情况下估算还有多少内存可用于新程序used已经被使用的内存percent内存使用百分比。监控面板优先展示总内存、已用内存、可用内存和使用率。这样比只盯“free 值”更合理。2.3 磁盘空间和 I/O 是两个问题很多人会把“磁盘使用率高”和“磁盘空间不足”混在一起。实际上监控磁盘要分两层看一是容量使用率二是读写繁忙程度。容量使用率解决的是“磁盘还能不能装下数据”问题常用命令是df -hI/O 主要看磁盘设备是否繁忙常用命令是iostat。如果磁盘空间明明还剩很多但系统响应很慢可能是磁盘 I/O 吞吐、排队时间或 I/O 等待过高这时需要排查是否有进程在大量读写数据。第一版监控面板里可以用psutil.disk_partitions()获取分区挂载点然后通过psutil.disk_usage()获取每个分区的总量、已用、可用和百分比。要特别注意服务器的虚拟文件系统如/proc、/sys不应纳入展示否则一堆无意义的挂载点会把面板堆满。2.4 还应该展示哪些基础信息除了 CPU、内存、磁盘外一个实用监控面板还需要展示主机名、操作系统、当前时间、开机运行时长。这样当你打开多个服务器的监控页时能快速确认自己看的是哪台机器。如果是在物理机上运行后续还可以考虑读取 CPU 温度、风扇转速等传感器数据但在云服务器或虚拟机上底层硬件传感器通常不直接暴露给操作系统这时监控面板显示“无温度数据”也是正常现象。3. 环境准备与项目分工3.1 运行环境这次示例以 Linux 服务器为主云服务器、虚拟机或本机 Linux 环境都可以。Windows 和 macOS 也能运行 Python 代码但后面验证用的压测命令需要换成对应的替代方案。运行监控项目需要的基础环境如下一台可以运行 Python 的服务器Python 3.9 及以上版本pip 包管理工具能访问 PyPI 并安装依赖的网络条件已经安装并配置好 Codex 命令行工具或 IDE 扩展。版本方面不建议写得过于死板因为 Python、Flask、psutil 都在持续发版。本文示例不锁版本号你安装时选择当前稳定版本即可。如果是在生产环境建议把依赖固化到 requirements.txt 中方便后续复现。3.2 Codex 的连接与登录Codex 属于在线 AI 编程服务使用前需要准备好官方账号并完成登录或 API 访问授权。不同入口的登录方式会略有差别比如 CLI、IDE 扩展、网页版之间的差异。这里给你一个通用做法不纠结于某个按钮的位置而是先在终端或 IDE 中确认 Codex 能正常发起对话。只要 Codex 能读取当前目录、创建文件和执行命令就可以开始下面的实战。特别提醒Codex 在执行任务时可能会在你的服务器上创建文件并安装依赖。建议先在一台测试服务器或临时目录中操作不要一上来就放在生产环境的核心目录里。3.3 项目结构与技术选型为了减少不必要的复杂度这次监控面板的技术选型如下后端使用 Python Flask提供 HTTP 接口采集数据使用 psutil前端使用一个原生 HTML 文件不引入 Vue、React 等框架页面样式使用 CSS 实现避免依赖外网 CDN前端通过 fetch 接口每 2 秒刷新一次数据。项目结构规划为server-monitor/ ├── app.py ├── requirements.txt └── templates/ └── index.htmlFlask 默认从 templates 目录渲染 HTML 模板所以 index.html 必须放在 templates 目录下。这样可以避免前端跨域问题因为打开页面和请求接口都在同一个服务地址下。3.4 第一步创建项目目录打开终端先创建一个空目录再进入这个目录mkdir ~/server-monitor cd ~/server-monitor后续 Codex 的所有操作都会限制在这个目录内。建议在任务开始前把目录清空避免 Codex 误读无关文件影响判断。4. 让 Codex 生成监控后端4.1 第一阶段让 Codex 创建依赖文件在正式写代码前可以先让 Codex 创建 requirements.txt。依赖很简单只需要 Flask 和 psutil 两个包。我们可以向 Codex 下达这样一个指令请在当前目录创建 requirements.txt内容包含 Flask 和 psutil 并按 Python 包依赖格式写清楚。先不要安装依赖等待下一步操作。这段指令的关键是让 Codex“先创建文件不要直接执行安装”因为安装依赖前我们还需要确认 Python 环境没有问题。Codex 可能自动生成类似下面的文件# 文件路径server-monitor/requirements.txt flask psutil如果你希望固定版本可以明确告诉 Codex 使用某个大版本例如“Flask 使用 3.xpsutil 使用 5.x”但建议不要直接写死一个未来可能失效的小版本号方便以后升级。4.2 第二阶段向 Codex 描述后端接口后端需求不能只写“帮我写一个监控接口”这样得到的代码很可能不符合你的预期。更好的方式是把接口路径、返回字段、使用库、运行方式都描述清楚。我使用的提示词大致如下你是一个 Python 后端开发。请在当前目录创建一个 Flask 应用文件名为 app.py。 应用需要提供两个路由 1. GET / 返回页面使用 render_template 渲染 templates/index.html。 2. GET /api/metrics 返回本机实时监控数据内容必须是 JSON。 /api/metrics 返回字段需要包含 - hostname主机名 - os操作系统名称 - uptime服务器已运行秒数 - cpu包含总使用率 percent、每核使用率 per_core、逻辑核数 core_count - memory包含 total、available、used、percent - disk遍历 psutil.disk_partitions 获取每个挂载点的 device、mountpoint、fstype、total、used、free、percent - timestamp当前时间字符串。 采集 CPU 和内存时使用 psutil 库。 磁盘遍历时要注意跳过 PermissionError并在 Windows/macOS/Linux 上都能运行。 不要使用 flask-cors因为前端页面和接口同源。 启动方式使用 app.run(host0.0.0.0, port5000, debugFalse)。把需求写得越具体Codex 出错的可能性就越小。如果直接说“给我一个服务器监控”它可能会自作主张引入你不需要的数据库或图表框架。4.3 后端代码参考下面是一份符合上述需求的 Python 代码。如果你的 Codex 生成结果略有不同可以对照这份代码进行审查和修改。# 文件路径server-monitor/app.py # -*- coding: utf-8 -*- 服务器监控面板后端 通过 /api/metrics 返回 CPU、内存、磁盘等实时指标 import platform import time import psutil from flask import Flask, jsonify, render_template app Flask(__name__) def get_cpu_info(): 获取 CPU 使用率、每核使用率、核心数量 return { percent: psutil.cpu_percent(intervalNone), per_core: psutil.cpu_percent(intervalNone, percpuTrue), core_count: psutil.cpu_count(logicalTrue), physical_count: psutil.cpu_count(logicalFalse), } def get_memory_info(): 获取内存总量、可用、已用、使用率 memory psutil.virtual_memory() return { total: memory.total, available: memory.available, used: memory.used, percent: memory.percent, } def get_swap_info(): 获取交换分区信息 swap psutil.swap_memory() return { total: swap.total, used: swap.used, free: swap.free, percent: swap.percent, } def get_disk_info(): 获取磁盘分区容量使用信息 disk_list [] partitions psutil.disk_partitions(allFalse) for partition in partitions: try: usage psutil.disk_usage(partition.mountpoint) disk_list.append({ device: partition.device, mountpoint: partition.mountpoint, fstype: partition.fstype, total: usage.total, used: usage.used, free: usage.free, percent: usage.percent, }) except PermissionError: # 某些挂载点当前用户没有访问权限跳过即可 continue return disk_list app.route(/) def index(): 渲染监控页面 return render_template(index.html) app.route(/api/metrics) def metrics(): 返回实时监控 JSON 数据 boot_time psutil.boot_time() data { hostname: platform.node(), os: platform.system(), uptime: int(time.time() - boot_time), cpu: get_cpu_info(), memory: get_memory_info(), swap: get_swap_info(), disk: get_disk_info(), timestamp: time.strftime(%Y-%m-%d %H:%M:%S), } return jsonify(data) if __name__ __