DeepSeek V4 和 Codex 组合做数据分析 Agent值不值得花几十轮提示词去调我的答案是值得但重点不是提示词轮数而是从模型接入、任务拆解、结果验证到报告迭代的一整条链路。这篇文章我不讲概念只讲我自己按项目交付标准跑完一轮的完整记录环境怎么搭、模型怎么接、提示词怎么分阶段组织、300 万行数据怎么处理、输出结果怎么保证可追溯以及最终怎么把这件事写进简历。先说结论这种项目的难点不在“让模型写出一段能跑的脚本”而在“让模型在 40 轮对话里始终知道自己要干什么并且每一步都留下可验证的中间结果”。如果你只是拿一段提示词让 Codex 生成一个数据分析脚本那不算交付只能叫 Demo。真正能写进简历的工程至少要满足三件事任务边界清楚、数据能追溯、报告能迭代。下面按实际落地顺序拆一遍。1. 先想清楚DeepSeek V4 加 Codex 到底能解决什么问题很多人在看到“DeepSeek V4 Codex”“40 轮提示词”“300 万行数据”这些词时第一反应是这又是一个让 AI 自动写代码的噱头。一开始我也这么想但真正跑完之后我会说这个组合最值钱的不是“自动写代码”而是把“从原始数据到最终报告”的整个分析过程变成了一段可以对话、可以修改、可以复现的 Agent 工作流。1.1 目标不是“写代码”而是交付一个可复用的数据分析链路我做的项目目标很具体用 Codex 作为命令行编程 Agent接入 DeepSeek V4 模型通过多轮提示词完成一个处理约 300 万行记录的数据分析任务。最终交付物不是单个脚本而是一个完整的小型工程包含数据读取、清洗、聚合、异常检测、结果导出和报告生成。如果只看表面Codex 确实是在“生成代码”。但真正有价值的是这几点任务拆解由人完成代码生成由模型完成中间每一轮都可以提出修改。每一轮生成的结果都落到项目目录不靠“模型记忆”靠文件记录。模型可以在后续轮次里读取之前生成的脚本和输出再决定下一步怎么改。整个分析链路是可见的不是模型直接在内存里跑完就结束。这就让项目从“一个临时脚本”变成了“一套可追溯的分析流水线”。对于数据量到百万级的数据分析任务这个区别非常关键。1.2 为什么选择 Codex 而不是直接复制提示词到网页我也试过把同一段提示词贴到网页对话里让模型直接给我返回一个完整脚本。结果是可以跑通小样例但一放到 300 万行数据上就出问题有的脚本内存占用过高有的输出列名和原始数据不一致有的根本没有把中间结果保存下来。Codex 这类 CLI 工具的优势在于它并不只是“聊天”它能读取当前项目目录、执行命令、查看运行结果、根据报错继续修改。也就是说它能进入真实的开发循环写脚本、运行、看日志、改脚本、再运行。这不只是提示词数量的问题而是 Agent 的工作方式更贴近工程交付。所以我在这个项目里的核心选择是模型用 DeepSeek V4执行环境用 Codex CLI提示词只负责定义目标和约束具体代码和调试过程交给 Agent 在项目目录里完成。1.3 300 万行数据的任务边界先确认数据长什么样很多人一听到“300 万行”就担心算力不够实际上要看数据本身的列数、格式和计算复杂度。我这次处理的数据是 CSV 格式大约 80 列单文件接近 1.5GB。按照常见个人电脑配置内存 16GB 到 32GB不一定跑不动但绝对不能直接read_csv然后一把梭。建议拿到数据后先做三件事用head -n 100或类似方式看前 100 行确认列名、分隔符、字符编码。统计文件大小和行数估算单行平均宽度。明确分析目标是统计聚合、趋势分析、异常检测还是要做特征工程。确认完之后再跟 Codex 进入第一轮提示词。否则模型不知道数据格式写出来的脚本每一步都要返工。2. 第一步落地安装 Codex CLI 并接入 DeepSeek V4标题里说“从模型接入到项目交付”第一步就是把 Codex 跑起来并且让 Codex 能真正调用 DeepSeek V4 模型。这一步报错非常多但大部分不是模型能力问题而是环境配置问题。2.1 环境准备系统、Node、Python 与目录规划我这次是在 macOS 环境下跑的但下面的思路在 Windows 和 Linux 上同样适用。需要准备的东西有项目建议说明操作系统Windows 10/11、macOS、主流 Linux 均可注意命令行工具路径差异Node.jsLTS 版本Codex CLI 常见安装方式依赖 NodePython3.10 或 3.11数据处理脚本主要用 Python磁盘空间至少 5GB数据文件、依赖环境、输出结果都会占空间模型服务DeepSeek V4 可调用的接口地址需要有效的 API Key目录规划这件事很多人会忽略。我建议每个项目单独建一个目录里面再分data/、scripts/、output/、logs/。比如project/ ├── data/ # 原始数据不手动修改 ├── scripts/ # Agent 生成的代码 ├── output/ # 结果文件、可视化、报告 └── logs/ # 运行日志、轮次记录这样的好处是Agent 在生成脚本时能明确知道往哪里读数据、往哪里写输出不会把中间文件散落得到处都是。2.2 Codex CLI 安装与路径问题排查Codex CLI 的安装方式以官方文档为准常见做法是通过 npm 全局安装。示例命令如下npm install -g openai/codex装完先确认版本codex --version如果你在 IDE 插件或图形界面里启动 Codex 时遇到下面这类报错先不要怀疑模型配置而是去检查 CLI 可执行文件路径unable to locate the codex cli binary. set codex cli path or ensure the executable is in PATH这类报错翻译过来就是“系统找不到 Codex 命令”。排查顺序很简单在终端里执行which codex确认 CLI 是否真的安装成功。如果没有输出重新安装或者找到 npm 全局安装目录。如果 CLI 存在但 IDE 插件找不到需要在插件设置里把 CLI 路径填进去。不要在系统 PATH 没有配置好的时候去改模型参数那是无效的。2.3 把 DeepSeek V4 配置成可用的模型Codex 默认情况下并不一定能直接连上 DeepSeek V4需要把模型服务的接口地址和模型名称配置进去。不同版本的 Codex 配置方式会有差异落地时先执行codex --help看看当前版本支持哪些参数。我采用的通用思路是设置服务地址环境变量再指定模型名称。示例export OPENAI_BASE_URLhttps://你的服务地址/v1 export DEEPSEEK_API_KEY你自己的密钥 codex --model deepseek-v4这里有几个需要注意的地方服务地址要以模型服务商提供的文档为准不要照搬我的示例。模型名称不是随便写的比如deepseek-v4、deepseek-v4-pro、deepseek-v4-flash可能对应不同能力和价格。如果报错信息类似there is an issue with the selected model deepseek v4 pro先确认你填的模型标识是否被当前服务地址支持。不要为了“看起来高级”把不存在的后缀拼进去比如有的模型支持flash但不支持vision-exp这种组合。命令行环境下最容易犯的错就是模型标识和服务地址不匹配。换模型之前先到服务商文档里查清楚当前 model 字段支持哪些取值。2.4 其他接入方式opencode、Qoder、VSCode、本地模型如果 Codex 在你的环境里始终装不上或者你的项目本身不在终端里跑可以换用别的客户端。像 opencode、Qoder、Claude Code 这类工具以及 VSCode 里的 AI 编程插件底层思路都是一样的配置一个兼容接口填入模型名称和密钥。我顺便测试过几个场景opencode 接入 DeepSeek V4 时同样要先确认它支持的自定义模型配置项。VSCode 插件接入 GLM、千问这类模型时重点是找到base URL设置项而不是只填模型名称。本地部署模型时要特别关注机器显存和内存。低配置能跑通 Demo不代表能跑百万行数据。另外如果你在麒麟桌面系统这类 Linux 环境里开发安装 openclaw 或类似工具时最常遇到的问题是 PATH 路径和权限。先用普通用户安装再把可执行文件目录加进 PATH运行报错就去检查日志不要直接怀疑模型有问题。3. 40 轮提示词不等于乱聊分阶段组织 Agent 的工作流标题里提到“40 轮提示词”很多人会误以为这是把同一个问题反复问 40 遍或者写一段超长提示词让模型一次生成。这两种理解都不对。我实际跑下来40 轮其实是分阶段完成的一个迭代过程每轮提示词只解决当前最紧迫的问题像带着一个实习生逐步完成项目而不是一口气塞给它全部需求。3.1 为什么我不用一段超长提示词超长提示词看起来能一次性讲清楚需求但模型很容易在长文本里丢失细节。尤其当项目涉及数据格式、字段口径、输出格式、异常处理时一段 3000 字的提示词反而会让模型抓不住优先级。分轮次提示词的核心好处是可定位、可回溯。模型的每一步操作都有明确上下文出问题时你能精准定位是哪一轮给的信息不对而不是重新从头开始。以下是团队协作里非常常用的“上下文卡片”思路放在这里也适用每一轮提示词都说明“现在在做什么”。明确“输入是什么输出要保存到哪里”。要求模型在代码里写日志而不是直接给一个黑盒结果。上一轮的输出就是下一轮的输入不靠模型记忆。3.2 阶段一把业务问题翻译成数据任务第一轮提示词不需要写代码需求而是先让 Agent 确认对任务的理解。我通常这样写你是一个数据分析工程师。项目目录为 project/原始数据在 data/raw.csv。 数据大概 300 万行、80 列。请先不要写具体代码先读取前 100 行数据 返回列名、数据类型、缺失值情况并给出你理解的数据分析步骤。这一轮的目的有两个让 Agent 建立项目上下文同时确认数据读取路径是否正确。如果数据编码有问题、路径写错这一轮就会暴露出来。3.3 阶段二固定输入输出与过程验证方式从第二轮开始要逐步把输入输出协议固定下来。Agent 默认情况下会自由发挥但工程项目不能靠自由发挥。我会在提示词里明确所有清洗后数据保存到output/cleaned.csv。所有聚合结果保存到output/summary/。运行日志写入logs/run_YYYYMMDD_HHMMSS.log。任何一步运行失败时直接把报错信息原样返回不要自己编一个成功结果。请生成第一个脚本读取 data/raw.csv完成基础清洗包括去除全空列、 统一日期格式、删除重复行。结果保存到 output/cleaned.csv。 清洗完成后打印行数和基础统计信息。 如果失败请把错误日志和我要求的路径一起反馈。这里的关键是“让 Agent 在文件系统里逐步留下痕迹”。模型对话可能有上下文丢失但文件系统不会丢。只要你把中间结果写盘后面任何一轮失败都能从磁盘上的文件继续排查。3.4 阶段三清洗、聚合、异常检测与性能调优数据量到 300 万行之后脚本能不能跑通是一回事跑得多快、占多少内存是另一回事。常见的问题是直接用 pandas 一次性读全量结果内存吃满电脑卡死。这种问题不是模型不会写代码而是它在没有约束时天然会选择最简单的写法。遇到这种情况我会加一轮提示词专门做性能优化当前脚本读取整个 CSV 时内存占用过高。请改为分块读取每次读取 50 万行 处理完就写入临时文件最后合并。同时打印每块处理耗时和内存占用。 不要引入过多依赖保持脚本可读。这样一轮一轮下去Agent 才会真正开始考虑工程约束。聚合、异常检测、口径校验这些步骤也要按类似方式拆开。每一步都独立验证不要指望一次性生成一个大而全的脚本。3.5 阶段四报告生成与迭代反馈分析结果出来之后还需要把结果转成可读报告。我在项目里让 Agent 生成 Markdown 报告并支持后续反复迭代更新。提示词示例读取 output/summary/ 下的所有结果文件生成一份 Markdown 报告。 报告必须包含数据量概览、关键指标表、异常数据说明、口径说明。 报告保存到 output/report.md。后续所有修改都在该文件上迭代不要另建新文件。这样做的价值是报告不是一次性产物而是每次数据更新后都能重新生成的迭代产物。当上游数据变化时只需要重新运行脚本再让 Agent 更新报告即可。4. 300 万行数据实战细节采样、批量、资源控制数据量一上来很多问题就不只是“模型生成代码”的问题了。你需要用自己的工程经验去约束 Agent否则它会写出一个逻辑正确但跑不动的脚本。4.1 先跑最小样例再放大数据量我在项目里强制规定的流程是先用 1 万行数据验证流程再逐步放大到 50 万行、100 万行、300 万行。无论 Agent 生成的代码看起来多合理第一次运行都要在小数据上验证列名、输出格式和运行日志。具体做法用脚本截取原始数据前 10000 行保存到data/sample_10k.csv。让 Agent 基于sample_10k.csv开发流程。确认小样结果符合预期后把输入路径改为完整数据。如果全量跑失败不要从头改先看日志再回退到小数据复现问题。这样能做到底层逻辑验证和性能问题分开处理。小数据跑不通大概率是逻辑问题小数据能跑通但大数跑不动大概率是性能和资源问题。4.2 分批处理而不是一次性读入内存300 万行数据如果只有几列一次性读入内存可能没问题但 80 列 1.5GB 的文件就容易吃满内存。我在实际项目里让 Agent 采用分块读取import pandas as pd chunk_size 500000 output_parts [] for chunk in pd.read_csv(data/raw.csv, chunksizechunk_size): # 对 chunk 做清洗和聚合 chunk chunk.dropna(axis1, howall) result chunk.groupby(category).agg( total_amount(amount, sum), order_count(order_id, count), ) output_parts.append(result) final_result pd.concat(output_parts).groupby(level0).sum() final_result.to_csv(output/summary_by_category.csv)这段代码只是示例不是通用写法。但思路是对的每一块数据独立处理最后再合并结果。这样可以控制内存峰值也能在某一整块失败时快速定位。4.3 单机执行的性能判断耗时、内存、磁盘判断项目能不能持续迭代不能只看“有没有跑完”。我会记录三类指标单次任务耗时每一阶段脚本执行用了多少秒。内存峰值处理过程中内存占用是否接近系统上限。磁盘占用output/目录写了多少中间文件。例如单次聚合任务如果耗时 8 分钟全量跑 3 个任务就是 24 分钟。这个时间可接受但要记录下来便于后面优化。内存如果超过物理内存的 70%就要考虑换更小的分块或者减少同时保留的中间变量。注意不要看任务开始在跑就以为没风险。同时观察内存和磁盘如果内存一直往上走赶紧停掉先改分块策略。4.4 批量任务与失败重试不要只做一个跑完就结束的脚本数据分析项目进入交付阶段后通常要处理多个文件或多次运行。这时不能靠人工盯着屏幕也不能让 Agent 每次都从头开始。我建议在项目里加入一个简单的任务清单例如tasks.json[ {input: data/raw_202401.csv, output: output/result_202401.csv}, {input: data/raw_202402.csv, output: output/result_202402.csv}, {input: data/raw_202403.csv, output: output/result_202403.csv} ]然后让 Agent 写一个按清单顺序执行的任务脚本。每个任务独立写日志失败后跳过并记录错误最后汇总哪些成功、哪些失败。这样 40 轮提示词迭代出来的工程才能真正交到别人手里用。5. 数据可追溯和报告迭代是怎么做到的“数据可追溯”和“报告能迭代”是简历里很有分量的关键词但它们不是靠口号实现的而是靠工程规范。以下是我在项目里实际落地的方式。5.1 每次运行都留下版本号和数据指纹数据分析最怕的事情是结果文件已经被覆盖但没人知道它是用哪份数据、哪个脚本、哪个参数跑出来的。为了避免这个问题我在输出目录里加入版本控制输出文件命名带时间戳如summary_20240101_100000.csv。脚本开头记录原始文件的 MD5 或 SHA256 值。每次运行把参数、输入路径、输出路径写入一个run_meta.json。这样哪怕过了很久你也能反查某份报告是基于什么数据生成的。这也是“可追溯”的真正含义。5.2 报告结构固定指标口径写进配置报告要能迭代结构就不能每次都不一样。我在项目里定义了一个固定模板包含数据概览、分渠道指标、异常样本、附注四部分。指标口径单独放到metrics_config.yaml里metrics: - name: total_amount description: 订单金额总和 column: amount agg: sum - name: order_count description: 订单总数 column: order_id agg: count当口径发生变化时不用重写报告生成代码只需要改配置再让 Agent 重新运行一次完整流程。这就是“报告能迭代”的底层逻辑。5.3 代码、日志、输出目录统一归档项目交付时把以下东西一起打包scripts/下所有代码脚本。logs/下所有运行日志。output/下的最终结果和报告。tasks.json、metrics_config.yaml等配置文件。一份README.md说明如何从原始数据复现最终结果。做到这一步才算是一个可以写进简历的完整工程。面试官问“数据可追溯怎么实现”时你可以直接打开目录结构给他看而不是只背概念。6. 常见报错和排查顺序我跑这个项目时遇到过不少报错集中在模型接入、Codex 环境、数据处理三类。下面按排查顺序整理出来。6.1 模型接入类报错常见现象there is an issue with the selected model deepseek v4 pro这说明 Codex 收到了你的模型选择指令但服务端不认这个模型标识。排查顺序查看模型服务商文档确认当前支持哪些模型名称。确认你填的是 model 标识不是模型展示名。如果是自定义模型检查 base URL 是否写错。在命令行直接调用接口测试避免经过 Codex 时多一层干扰。6.2 Codex CLI 路径和环境类报错常见现象unable to locate the codex cli binary这是环境问题不是模型问题。顺序如下终端执行which codex看有没有输出。没有输出检查 npm 全局 bin 目录是否在 PATH 里。有输出但 IDE 插件仍报错在插件设置里手动指定 CLI 路径。路径正确后再执行codex --version确认 CLI 能正常运行。如果是 Codex 请求接口时报连接错误优先检查服务地址是否写错以及当前网络是否能访问目标服务。不要去改模型参数改完也不会解决连接问题。6.3 数据处理任务卡住或输出异常任务卡住时先不要急着杀进程我一般这么做看日志确认卡在哪一步。看内存和磁盘占用排除资源耗尽。看输入文件是不是被其他程序占用。如果一直卡在读取阶段考虑是不是文件太大或格式异常。如果是输出为空先看输入数据过滤条件再看脚本有没有提前退出。6.4 排查链路现象到输入到环境到参数我把整个项目的排查链路固定成以下顺序现象是什么报错、卡住、无输出、输出结果不对。输入是什么文件路径、格式、编码、字段名。环境是什么依赖版本、Python 版本、磁盘空间、内存占用。参数是什么模型名称、服务地址、分块大小、任务清单。最后看工具本身Codex 版本、插件版本、功能边界。按照这个顺序排查90% 的问题都能快速定位。很多看起来像模型能力不行的报错最后都是环境或输入格式问题。7. 这类项目写进简历时怎么准备最后说简历。一个“用 DeepSeek V4 Codex 做了 300 万行数据分析 Agent”的项目面试官不会只看标题他一定会追问细节。准备的时候不要只背亮点要把整个项目的工程约束讲清楚。7.1 项目亮点不是“40 轮”而是工程约束写简历时不建议把“40 轮提示词”作为核心亮点。因为 40 轮只是过程面试官更关心的是你通过迭代最终交付了什么。建议这样描述项目经历使用 Codex 接入 DeepSeek V4通过多轮提示词迭代开发了一个数据分析 Agent。完成 300 万行、80 列数据处理、清洗、聚合和报告生成。通过分块读取、分批聚合控制内存占用保证单机环境可运行。通过运行元信息、日志、版本化输出实现数据可追溯。通过固定报告模板和指标配置实现报告可迭代。这些描述每一句都有真实工程支撑不会被问倒。7.2 面试时容易被问到的细节面试官如果懂行会盯着这些点问300 万行数据是怎么读的有没有考虑内存分块大小为什么是 50 万不是 10 万数据可追溯具体记录了什么报告迭代时指标口径变了怎么处理Codex 生成的代码你审查过吗哪些地方你手动改过中间某一步失败了如何定位这些问题没有标准答案但只要你真的跑过一轮就能讲出实际取舍。比如分块大小不是拍脑袋定的而是根据文件大小和内存情况测出来的。7.3 这套流程还能复用到哪里这套流程并不只适用于数据分析凡是“模型生成代码 工程交付”的场景都可以复用。比如批量文档处理、报表自动化、数据清洗管道、特征工程流水线甚至自动生成运维巡检报告逻辑都一样明确任务边界、分阶段提示词、中间结果落盘、日志和版本管理、固定输出模板。跑完这个项目后我的体会是AI 编程的真正门槛不在提示词文学而在你有没有能力把一次对话式的生成变成一套可维护、可复现、可追踪的工程流程。只要这个流程搭起来了换成任何模型、任何客户端都能快速再做一遍。