最近在做一个数据分析类项目时把 DeepSeek V4 接入 Codex用 40 轮提示词从零推进需求、清洗、指标计算、报告生成的完整链路最后产出的数据分析 Agent 能处理 300 万行级数据并且每轮结果都能追溯、报告可以持续迭代。这篇文章直接把这条链路拆开讲Codex 怎么装、DeepSeek 模型怎么接、40 轮提示词怎么拆、数据处理和报告生成怎么做成可交付的工程以及踩过的坑和排查方法。如果你正在做 AI 编程辅助的数据分析项目或者想给简历里加一个有交付深度的 Agent 实战项目这篇文章可以直接收藏。1. 核心能力速览先看该项目涉及的完整能力面判断是否匹配你的使用场景。能力项说明项目类型数据分析 Agent 交付工程基于 AI 编程工具生成可运行的 Python 数据处理与报告系统核心模型DeepSeek V4通过模型 API 或本地推理服务接入编程工具Codex CLI用自然语言提示词驱动代码生成与迭代核心目标处理 300 万行级数据完成清洗、指标计算、可视化报告输出主要功能数据加载、字段清洗、指标计算、图表生成、Markdown 报告、数据追溯批量任务支持分片处理、失败重试、结果汇总报告迭代按轮次生成报告版本可回溯对比硬件门槛接入 API 时本地 CPU 即可运行若本地部署模型需要按模型实际推理资源评估启动方式命令行启动 CodexPython 工程按模块运行是否支持 API可扩展为 FastAPI 服务供外部调用适合场景数据分析、数据报表自动化、简历实战项目、AI 编程工作流实验说明DeepSeek V4 的具体模型名称、API 地址和参数以你实际可用的模型服务为准本文示例使用占位符部署时需要替换。2. 适用场景与使用边界这类项目的定位不是做一个简单的“丢给 AI 一个 CSV 出报告”的 Demo而是把数据分析流程工程化让 AI 通过提示词逐步完成数据理解、清洗规则定义、指标计算、报告输出和结果追溯。适合以下几类人数据分析师或运营需要将重复性日报、周报自动化。后端工程师想用 Codex DeepSeek 快速搭建数据分析服务。准备找数据分析或 AI 应用岗位的求职者需要把 300 万行级数据处理经验沉淀成简历项目。对 AI 编程工作流感兴趣的开发者想验证大模型编码工具在真实业务中的表现。不适合的场景也要说清楚对数据准确性要求极其严格的金融、医疗等场景不能完全依赖模型自动生成的规则必须有人工复核。数据包含个人隐私、商业机密时不能直接把原始数据发送到未获授权的模型服务。模型生成代码不能直接上生产至少要做代码审查和测试。这里必须强调合规边界数据清洗、指标计算、报告生成只能使用已获得授权的数据涉及个人信息的要脱敏涉及商业数据的要确认使用范围。AI 生成的结果只作为辅助最终交付前需要人工复核。3. 环境准备与前置条件先准备基础环境。整个链路的核心依赖是 Codex CLI以及可用的 DeepSeek 模型服务。建议环境如下依赖项要求说明操作系统Linux / macOS / WindowsWSL 或 Git BashCodex CLI 在 Linux 和 macOS 上运行最稳定Node.js16 及以上或 18 以上 LTS部分安装方式依赖 npm包管理工具npm 或 Homebrew根据系统选择Codex CLI最新稳定版提供命令行交互和 API 调用DeepSeek 模型服务API 地址、API Key、模型名称按实际服务提供方配置Python3.9 及以上运行数据分析工程数据文件CSV 或 Excel测试建议先用少量数据例如 1 万行级联到 300 万行磁盘空间10GB 以上存放数据、代码、报告和模型缓存先确认 Node 和包管理器是否可用node -v npm -v如果使用 Homebrewbrew --version接下来安装 Codex CLI。最通用的是 npm 方式npm install -g openai/codex或者使用 Homebrewbrew install codex安装完成后验证版本codex --version如果提示找不到codex命令通常是 Node 全局安装目录没有加入 PATH需要把 npm 全局 bin 目录添加到环境变量或者在 Windows 上改用 npx 调用。4. Codex 接入 DeepSeek V4 模型配置Codex 默认使用 OpenAI 的模型但通过配置文件可以接入其他兼容服务的模型。这里给出一个通用配置模板实际使用时需要把base_url、api_key和model值替换为你的模型服务实际提供的信息。Codex 的配置文件位置Linux / macOS~/.codex/config.tomlWindows视安装方式而定通常是用户目录下.codex/config.toml示例配置model deepseek-v4 model_provider deepseek_provider [model_providers.deepseek_provider] name DeepSeek V4 base_url https://your-model-endpoint.example.com/v1 env_key DEEPSEEK_API_KEY wire_api chat说明model填写模型服务方提供的模型标识例如deepseek-v4或deepseek-v4-flash取决于你的服务实际支持哪个名称。base_url模型服务地址必须替换为实际地址通常是兼容 OpenAI Chat Completions 格式的接口。env_key环境变量名称Codex 会读取这个环境变量作为 API Key。配置好之后设置环境变量export DEEPSEEK_API_KEY你的密钥然后启动 Codexcodex如果配置正确Codex 会进入对话界面可以直接输入提示词要求它写代码。可以在正式任务前先用一个简单测试写一个 Python 脚本读取当前目录下的 data.csv输出总行数和各列数据类型。这一步用于验证模型接入是否正常。如果 Codex 回复正常说明接入成功可以开始 40 轮提示词迭代。5. 提示词工程40 轮迭代怎么拆很多人在 AI 编程里失败不是因为模型不够强而是不会拆任务。40 轮提示词不是让 Codex 连续生成 40 个无关功能而是一条递进链路每一轮都基于上一轮的结果做增量开发和校验。我建议把整个 40 轮拆成 7 个阶段阶段轮次建议目标需求定义第 1 - 5 轮明确数据字段、业务口径、报告框架数据字典第 6 - 10 轮让模型理解每个字段含义和值域清洗规则第 11 - 16 轮缺失值、异常值、类型转换规则指标计算第 17 - 24 轮核心指标定义、去重逻辑、分组聚合报告生成第 25 - 32 轮图表、表格、Markdown 报告模板可追溯改造第 33 - 37 轮记录输入文件、代码版本、输出结果的对应关系交付复核第 38 - 40 轮边界检查、异常处理、README 编写这里核心原则是每轮只处理一个可验证的小目标生成代码后立刻运行验证再把结果反馈给 Codex进入下一轮。第一阶段提示词示例我现在有一个数据分析项目数据文件是 sales_data.csv约 300 万行。 请先阅读文件前 50 行列出所有字段名、数据类型、非空数量。 不要写任何业务逻辑只做数据探查输出一个 markdown 格式的字段清单。第二阶段提示词示例基于上一轮得到的字段清单为每个字段生成一份数据字典。 数据字典需要包含字段名、字段含义、值域、空值情况、是否业务主键。 请将结果输出为 data_dictionary.md。第三阶段提示词示例根据数据字典为 sales_data.csv 编写一份数据清洗脚本 clean.py。 清洗规则要求 1. 删除完全重复的订单记录。 2. 将 amount 字段转换为 float出现转换失败时记录到 error_log.csv。 3. 将 date 字段统一为 YYYY-MM-DD 格式。 4. 缺失值超过 50% 的列输出警告。 清洗完成后输出清洗前后的行数对比。每一轮结束时让 Codex 输出运行日志和结果摘要方便你判断进度。不要把多轮任务塞进一次提示词里否则模型容易丢失上下文出错后也难以定位。这里分享一个提高成功率的小技巧每轮结束后把该轮生成的代码和输出文件路径记录到一个iteration_log.md文件中。记录格式可以是轮次 1数据探查输出字段清单。 轮次 2生成数据字典。 轮次 3完成清洗脚本 clean.py。这样做的好处是当你需要回溯问题时能明确知道是哪一轮引入的规则而不是面对一坨不知道从哪里来的代码。6. 数据分析 Agent 的项目结构经过 40 轮提示词迭代后项目结构会趋向稳定。这里展示一个典型的目录结构实际项目可能略有差异。sales_agent/ ├── data/ │ ├── raw/ │ │ ├── sales_data.csv │ │ └── data_dictionary.md │ ├── processed/ │ │ └── sales_clean.csv │ └── output/ │ ├── reports/ │ └── charts/ ├── scripts/ │ ├── explore.py │ ├── clean.py │ ├── metrics.py │ └── report.py ├── logs/ │ ├── iteration_log.md │ └── error_log.csv ├── manifest/ │ └── run_manifest.json ├── README.md └── requirements.txt其中核心模块的作用explore.py数据探查输出字段清单、类型、空值率。clean.py数据清洗缺失值处理、异常值处理、类型转换。metrics.py核心指标计算支持按日期、地区、渠道的分组聚合。report.py根据指标结果生成 Markdown 报告和图表。requirements.txt示例pandas2.2.2 matplotlib3.9.1 seaborn0.13.2 jinja23.1.4安装依赖pip install -r requirements.txt7. 300 万行数据的批量任务设计处理 300 万行数据时不能像处理小型数据集那样一次性读入内存做全部操作要有分片和重试机制。这个部分建议重点强调因为它是项目从 Demo 走向工程的关键。分片处理思路将原始 CSV 按固定行数分片例如每片 50 万行。每个分片独立执行清洗和指标计算。计算完成后合并结果并保留每个分片的状态日志。clean.py的核心逻辑可以写成类似结构import pandas as pd from pathlib import Path CHUNK_SIZE 500_000 RAW_DIR Path(data/raw) CLEAN_DIR Path(data/processed) def process_chunk(chunk: pd.DataFrame, chunk_id: int): # 去重 chunk chunk.drop_duplicates(subsetorder_id) # 类型转换 chunk[amount] pd.to_numeric(chunk[amount], errorscoerce) # 日期标准化 chunk[date] pd.to_datetime(chunk[date], errorscoerce).dt.strftime(%Y-%m-%d) # 清洗后保存 chunk.to_csv(CLEAN_DIR / fclean_{chunk_id}.csv, indexFalse) return len(chunk) def main(): reader pd.read_csv(RAW_DIR / sales_data.csv, chunksizeCHUNK_SIZE) for chunk_id, chunk in enumerate(reader): try: rows process_chunk(chunk, chunk_id) print(fchunk {chunk_id}: {rows} rows cleaned) except Exception as e: print(fchunk {chunk_id} failed: {e}) if __name__ __main__: main()这个示例中使用分片读取避免一次性加载 300 万行数据导致内存溢出。实际运行前需要按你的数据字段调整order_id、amount、date等字段名。合并分片结果cat data/processed/clean_*.csv data/processed/sales_all_clean.csv如果你用 Python 合并推荐使用 pandas 读取多个分片后 concat或者直接用命令行合并再统一做一次全量校验。批量任务的失败处理也很重要。实际运行时某个分片可能因脏数据导致异常不能让整个任务中断。建议在每个分片处理前后记录日志处理失败时保存错误上下文并允许后续重跑指定分片。8. 数据可追溯与报告迭代数据可追溯是这个项目区别于普通数据分析脚本的关键设计。可追溯的含义包括输入数据从哪来是谁在什么时间传入。清洗脚本用的是哪个版本的代码。报告基于哪个分片或哪个时间点的数据生成。报告内容相比上一版改了什么。我建议把运行信息写入manifest/run_manifest.json{ run_id: 20250612_1430, model: deepseek-v4, input_file: data/raw/sales_data.csv, input_rows: 3000000, clean_script_version: v1.3, clean_rows: 2985000, report_version: report_v12.md, generate_time: 2025-06-12T14:35:00Z }生成报告时把版本号写进文件名report_v12.md report_v12_chart_01.png这样做的好处是当你用同一份数据跑多轮报告后如果发现某个指标异常可以直接打开 manifest 查看是哪版脚本、哪个时间点产生的。对简历而言“数据可追溯”是面试官非常看重的工程素养。报告迭代的逻辑也一样。每次生成报告前先读取上一版报告的版本号新报告自动升级版本号并在文档头部标注变更说明。示例# 销售数据分析报告 - 报告版本v12 - 生成时间2025-06-12 14:35 - 变更说明调整去重逻辑增加渠道维度对比9. 接口 API 与批量调度扩展项目做完之后如果只是手动跑脚本工程化能力还不完整。可以把报告生成能力包装成 API 服务这样就能支持外部系统调用和定时调度。使用 FastAPI 封装一个接口from fastapi import FastAPI, UploadFile, File import subprocess import shutil import uuid app FastAPI() app.post(/upload) async def upload_data(file: UploadFile File(...)): run_id str(uuid.uuid4())[:8] input_path fdata/raw/{run_id}.csv with open(input_path, wb) as buffer: shutil.copyfileobj(file.file, buffer) subprocess.run([python, scripts/clean.py, --input, input_path]) subprocess.run([python, scripts/metrics.py, --input, input_path]) subprocess.run([python, scripts/report.py, --input, input_path]) return {run_id: run_id, status: done}启动 APIuvicorn api_server:app --host 127.0.0.1 --port 8000使用 curl 上传文件并触发任务curl -X POST http://127.0.0.1:8000/upload \ -F filedata/raw/sales_data.csv说明以上 API 示例是通用模板实际字段和请求路径需要按你的工程结构调整。如果你不需要 API 服务也可以保留 Python 命令行方式运行。接口服务适合将 Agent 接入定时报表、数据看板或企业微信机器人等场景。批量调度可以使用 cron 或计划任务0 9 * * * cd /path/to/sales_agent python scripts/report.py --input data/processed/sales_all_clean.csv logs/cron.log 2110. 资源占用与性能观察如果把 DeepSeek V4 通过 API 方式接入本机资源压力主要来自数据处理和分析脚本而不在模型推理。也就是说普通 CPU 机器也能跑 300 万行数据任务瓶颈通常是内存和磁盘 I/O。运行脚本时重点观察内存占用读取大 CSV 时内存会上升建议使用分片读取。CPU 使用率pandas 聚合计算会消耗多核 CPU。磁盘占用分片文件、图表、报告会持续占用磁盘空间。API 调用延迟Codex 生成代码时每一轮提示词需要等待模型返回延迟取决于模型服务的响应速度。使用top或 Windows 任务管理器观察进程资源top -p $(pgrep -f clean.py)实际占用会根据数据量和代码质量浮动。300 万行数据如果一次性加载到内存通常需要 2GB 到 4GB 内存具体取决于列数和字段类型分片处理后单次内存峰值可以控制在几百 MB 以内。不过这个数字只是经验估算务必以你本机实际运行结果为准。如果需要降低内存占用可以采用以下措施使用dtype指定列类型减少数值型字段内存。分片处理控制每次读取的行数。及时释放不再使用的 DataFrame 对象。输出结果为 CSV 时使用压缩格式。如果你选择本地部署 DeepSeek V4 模型则需要单独评估模型推理的显存或内存需求建议参考模型官方文档给出的最低配置并用nvidia-smi观察显存占用nvidia-smi11. 常见问题与排查方法在实际开发过程中Codex 接入 DeepSeek 或项目运行时遇到的最常见问题整理如下。问题现象可能原因排查方式解决方案提示codex命令找不到Codex CLI 未安装或 PATH 未配置执行codex --version验证检查 Node 全局 bin 目录重新安装配置了模型地址但请求失败base_url 或 API Key 错误查看 Codex 日志用 curl 测试模型服务确认模型服务地址和密钥准确性提示 “unable to locate codex cli binary”编辑器或工具找不到 Codex 可执行文件检查环境变量 PATH在系统 PATH 中配置 Codex 可执行路径提示 “the agent execution provider did not respond in time”模型服务响应超时或网络不稳定检查模型服务日志和网络降低请求并发延长超时时间或重试提示 “there is an issue with the selected model”配置的模型名称不存在或模型服务不支持核对模型服务支持的模型列表修改 config.toml 中的 model 名称API Key 未识别环境变量未设置或名称不匹配检查echo $DEEPSEEK_API_KEY确保环境变量名称与配置一致pandas 读取 300 万行内存溢出一次性加载数据过大使用分片读取调整 chunksize分批处理指标计算结果不一致清洗规则或去重逻辑变化查看 manifest 和迭代日志对比不同版本脚本的差异报告图表中文乱码matplotlib 字体库缺少中文字体检查字体配置指定系统中文字体文件调试模型接入时可以使用 curl 直接验证模型服务是否可用curl -X POST https://your-model-endpoint.example.com/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $DEEPSEEK_API_KEY \ -d {model: deepseek-v4, messages: [{role: user, content: ping}]}如果 curl 能正常返回说明模型服务本身没问题问题在 Codex 配置或环境变量。12. 最佳实践与合规提醒这个项目如果你想写进简历或者在真实业务中使用以下几点非常重要。第一第一次跑的时候不要直接上 300 万行数据。先用 1 万行左右的小数据集完整跑一遍流程确认清洗、指标、报告、追溯链路都通再逐步扩展到全量数据。第二给整个项目准备一套最小可运行配置。包括精简版数据、固定版本的依赖、一键运行脚本。这样无论是换机器还是给面试官演示都能快速复现结果。第三模型、数据、代码、报告要分目录管理。不要把模型输出和人工检查结果混在一起。数据放到data/raw处理后文件放data/processed报告放data/output/reports代码放scripts。目录清晰排查问题会快很多。第四批量任务必须加日志和失败重试。300 万行数据处理不是一次就能成功的中间可能出现脏数据、网络超时、内存不足等问题。日志要记录每批次的处理行数、耗时和异常信息。第五涉及数据安全和隐私时必须确认授权。不要将未经脱敏的个人数据上传到外部模型接口。如果数据敏感应优先选择本地部署模型或者对数据进行字段级脱敏后再分析。AI 模型生成的结果不能直接作为最终交付物人工复核是底线。第六简历项目展示不需要吹嘘“我 40 轮做出了 300 万行 Agent”。更成熟的表达是基于 DeepSeek V4 和 Codex 构建数据分析 Agent通过 40 轮提示词迭代完成数据清洗、指标计算、报告生成与追溯机制支撑 300 万行数据级任务并封装为可调用的 API 服务。这种写法既展示工具能力也展示你的工程化思路。13. 总结这个项目最值得尝试的点不是“用 AI 写代码”本身而是把 AI 编程工具纳入完整的数据分析交付链路从模型接入、提示词迭代到数据清洗、指标计算、报告生成、追溯机制和 API 封装。Codex 接入 DeepSeek V4 后你相当于拥有了一个能持续对话、能写代码、能帮你推进多阶段任务的工程助手。如果你要从零开始复现建议先验证三件事Codex 能否正常接入 DeepSeek V4并用一条简单的代码生成指令跑通。用 1 万行小数据跑通清洗、指标、报告三个环节。加入 manifest 和迭代日志确认每一轮输出都能被追溯。最容易踩的坑有两个一是模型接入阶段没有核对 base_url 和 model 名称导致大量请求失败二是在数据处理阶段一次性加载 300 万行数据导致内存溢出。这两点都在上文给了对应的排查方法。后续值得继续扩展的方向包括把报告内容接入企业协作工具、给 Agent 增加自动异常检测能力、用向量数据库保存历史报告便于语义检索以及把 40 轮提示词的迭代经验沉淀为可复用的提示词模板库。建议先把这个项目跑通再往这些方向逐个加能力。