当你使用 Codex 生成排序、遍历或数据聚合脚本时，可能发现它处理 10 万行日志耗时 8 秒、内存飙升到 1.2GB，而同类手写代码仅需 0.3 秒——这并非模型“能力不足”，而是自然语言指令没能准确触发它的算法级优化能力。

Codex 生成代码性能低下的根本原因，在于自然语言描述未能激活其算法级优化能力。必须重点检查循环内高开销函数调用、嵌套列表推导式、字符串拼接滥用这三类隐患，并通过添加复杂度约束注释和指定库函数等结构化指令来驱动优化。

快速识别Codex生成代码的性能瓶颈

打开 Codex 输出的 Python 脚本，逐行排查以下三类典型低效模式：

① 循环内重复调用高开销函数。例如 for line in lines: json.loads(line) 中没有缓存 json 模块引用，或反复使用 os.path.join()。这种模式会导致每次迭代都重新加载库函数，资源浪费十分明显。

② 列表推导式嵌套过深。像 [x for x in data for y in x if condition(y)] 这类写法，实际构建的是中间全量列表而非生成器。一旦数据量增大，内存压力会急剧上升。

③ 字符串拼接滥用。很多人习惯写成 result = "" → result += item，在循环内会触发 O(n²) 级别的复制操作。正确做法应改用 "".join(list) 或 io.StringIO。

只要存在上述任意一种模式，代码就已埋下性能地雷，必须立即重构。

通过结构化指令激活Codex的算法级优化

方法一：在注释中锁定时间/空间复杂度约束。在待优化函数上方添加注释，明确写出硬性指标，例如：# 时间复杂度必须为 O(n)，禁止嵌套循环；空间复杂度 ≤ O(1)，不得新建列表存储中间结果。这样 Codex 会自动过滤掉所有不符合复杂度要求的候选方案。

方法二：强制指定底层机制。直接给出技术路径，例如：# 用 itertools.chain.from_iterable 替代双层 for 循环展开嵌套列表，避免内存暴涨。这比笼统地说“优化性能”高效十倍——Codex 对库函数名称有强记忆力，能精准匹配实现方案。

【关键前提】必须粘贴原始代码全文，不能只给伪代码或描述。Codex 的优化依赖于上下文，一旦缺失变量定义或类型信息，生成逻辑就会断裂。

手动验证优化效果的三步闭环

第一步：用 timeit 测试原始版本。在 Python 中执行 python -m timeit -s "import your_module" "your_module.your_func(large_test_data)"，记录基准耗时与内存峰值（可借助 memory_profiler 辅助监控）。

第二步：运行 Codex 优化后的代码，使用完全相同的测试数据和命令重新执行 timeit。

第三步：对比两份报告中的 loops per second 数值。若提升不足 3 倍，说明优化未生效——此时需返回第二阶段，追加指令：// 补充使用 @lru_cache(maxsize=128) 缓存高频计算结果，并验证缓存命中率。