我在整理最近半年的自动化生产实践时发现一个特别明显的变化以前写自动化脚本最大的成本不是让脚本跑起来而是把业务逻辑翻译成代码。接口要写成 requests 调用页面要写成元素定位文件处理要拼一堆 os.path 操作一套流程下来人已经累得不想维护了。Codex 这类 AI 编程工具进场之后成本结构彻底变了它能把需求描述直接翻译成可执行代码。这篇文章记录的是我基于 Codex 做多场景自动化生产的完整复盘覆盖接口自动化测试、Web UI 自动化、移动端与办公自动化四类场景适合测试开发、运维工程师以及所有想把重复劳动交给工具的人参考。这个系列叫“闪学IT-Codex 多场景自动化生产实战”说白了一点都不玄就是把自然语言变成自动化脚本再把脚本变成生产线。所谓“生产”不是单条脚本跑一次而是能反复执行、能交给定时任务、能接进 CI/CD、能出报告的整套机制。我下面会按照场景拆解把 prompt 怎么写、生成代码长什么样、踩过哪些坑都摊开讲清楚。1. 多场景自动化生产为什么值得用 Codex 重新做一遍1.1 自动化生产的瓶颈从来不是“跑”而是“写”很多团队不是没有自动化测试。恰恰相反pytest 用例堆了一大堆CI 上定时任务也挂着好几个但真出问题时大家还是习惯手工点页面。为什么因为自动化脚本的维护成本太高了。业务改一个字段名测试脚本要跟着改页面重构一次元素定位全废接口加了签名老脚本全部报错。于是自动化资产变成了一个“越用越不敢用”的包袱。这里有个很多人忽略的点自动化脚本真正的生产成本不是在执行阶段而是在编写和维护阶段。你需要的不是“能跑”的脚本而是“在业务变化后能快速更新”的脚本。而 Codex 做的恰恰是把“编写”这个环节的边际成本打下来。原来改一个接口测试用例要半小时现在把新文档粘给 Codex描述清需求几十秒就能得到新版本。“多场景自动化生产”的核心就是把这种“低成本的版本迭代能力”用到不同领域。1.2 Codex 在自动化生产里的定位需求翻译器我习惯把 Codex 理解成一个“需求翻译器”输入是自然语言描述输出是可直接执行的代码。但跟普通的“代码补全”不同Codex 的目标更像“拿着需求文档干活的人”——你告诉它步骤和约束它一次性把完整脚本给你。举个例子。你说“用 Python 写一个脚本读取 data.xlsx把‘未支付’状态的订单筛选出来生成 summary.csv”。如果靠自己翻文档你得先搞清楚 openpyxl 的 API交给 Codex它知道要打开工作簿、遍历行、判断状态列、写成新表还会顺带处理表头不存在、单元格为空这类常见问题。生活里类比一下它就像一个经验丰富的实习生你不需要教它 Excel 的每个按钮只需要把目标和边界说清楚。但注意实习生也会犯错。所以这套实战里最重要的不是“让 Codex 一次写对”而是“怎么描述需求、怎么验收产出”。把这两件事做好Codex 在自动化生产里才能真正缩短工期。1.3 场景选型接口、Web、App、办公四条主线做多场景自动化第一步不是打开 Codex而是想清楚你有哪些重复劳动值得自动化。我个人把平时的场景分成四条主线整理成一张表场景典型的重复劳动常用技术栈Codex 产出物生产落点接口自动化接口回归、参数校验、签名测试pytest, requests, allure用例文件、fixture、工具函数定时任务 / CI 流水线Web 自动化页面流程回归、数据采集Playwright, Selenium页面脚本、选择器策略、采集程序每日任务 / 监控App 自动化移动端冒烟、跨版本回归Appium, pytestcapabilities 配置、测试用例发版前回归办公自动化Excel处理、邮件发送、批量文件整理openpyxl, pandas一次性/定时脚本部门日常任务建议新手先选“接口自动化”入口因为它对运行环境依赖最少Codex 的产出质量也最容易验证。我自己的实战顺序就是接口 - Web - App - 办公每走完一个场景再往上叠加下一个。2. 场景一接口自动化Codex 见效最快的战场2.1 从接口文档到 pytest 用例的全自动生成接口自动化是所有自动化里最“结构化”的因为它有明确的请求、参数、响应结构Codex 对这种输入特别擅长。我的做法是先把接口文档里的请求示例、参数表、返回 JSON 复制出来然后写一段带约束的 prompt。我经常用的 prompt 长这样你是测试开发工程师。请根据下面的接口信息使用 pytest requests 编写接口自动化测试用例。 接口POST /api/user/login 请求参数 username: string password: string 返回示例 {code: 0, data: {token: abc123}, msg: success} 要求 1. 用 fixture 管理 base_url默认 http://test-server 2. 覆盖三个用例正常登录、密码错误、缺少 username 3. 对返回的 code 和 msg 字段做断言 4. 不要使用外部依赖只用 requests 和 pytestCodex 生成的代码通常会包含 conftest.py 和 test_login.py 两个文件。它的 fixture 会自动带上 yieldrequests.Session 会被正确复用。你几乎不需要改就能跑。但拿到代码后我建议先做小范围验收跑一条主流程用例确认断言逻辑没写反再去跑全量。这里有个关键点让 Codex 先列测试点再生成代码。比如在 prompt 里加一句“先列出要覆盖的测试点确认后输出代码”。原因是如果直接让它生成它容易把正常路径写得很好边界路径随便带过先列测试点相当于让它先画测试金字塔再往下填实现。2.2 参数化与数据驱动让 Codex 帮你把用例铺开接口自动化里最高频的需求就是参数化。比如登录接口要测试十组账号密码用 pytest 的pytest.mark.parametrize就能把数据跟用例逻辑分开。Codex 最擅长做的就是这个给它一张“用例数据表”它能直接生成参数化版本的测试函数。我总结了一个比较“信得过”的参数化 prompt 模板请将下面的测试数据用 pytest.mark.parametrize 改写到 test_login 中 1. 正确用户名和密码期望 code0 2. 错误密码期望 code1001 3. 空用户名期望 code1002 4. 密码带空格期望 code1002 同时把断言写成 fixture 函数 validate_code方便统一维护。这里要让 Codex 注意“用例标题”的易读性例如 pytest.param(..., idwrong_password)。如果一次生成的 id 都是 test_data[0] 这种后面报告会让人看晕所以 prompt 里可以直接要求“id 使用语义化名称”。这个小细节能让 Allure 报告立刻显得专业很多。2.3 生产化要点把用例接进 CI让“自动化生产”真正生产脚本在本地跑通只能算“一个能跑的脚本”要成为“自动化生产线”还得接到持续集成上。我用 GitLab CI 比较多最简配置像下面这样test-api: stage: test image: python:3.11 script: - pip install -r requirements.txt - pytest tests/api -m smoke --junitxmlreport/api-smoke.xml --alluredirallure-results artifacts: paths: - allure-results/ - report/ when: always这段配置把接口用例做成流水线中的测试任务。Codex 在这里同样能帮忙如果你不清楚 GitLab CI 的 before_script 和 artifacts 怎么用直接把配置粘贴给 Codex问它“这个文件里每个字段的作用是什么我想加一个定时执行怎么改”它给出的修改结果基本能直接用。实战中我最推荐的三个“生产化动作”是用例按 smoke/full 分层、失败时自动抓取响应、测试数据与代码分离。Codex 能帮你完成前两个第三个更需要你有意识地建一个 data/cases.yaml 管理数据。把数据跟代码分离之后后续维护成本会下降一个数量级。3. 场景二Web UI 自动化用 Playwright 把“看得见的流程”变成流水线3.1 为什么选择 Playwright 而不是 Selenium到了 Web UI 自动化技术栈我建议优先选 Playwright。不是 Selenium 不行而是 Playwright 有三点对“AI 生成代码”特别友好第一它有自动等待机制很多显式等待代码不用反复生成第二它的选择器语法更统一支持 role、text、css 多种策略AI 写出来的代码误报率更低第三Python 端的 API 设计很直觉page.goto、page.fill 这种命名让 Codex 不容易“编错”。举一个很实际的例子。让 Codex 写“用 Selenium 点击页面上文本为‘提交’的按钮”它需要生成 WebDriverWait、expected_conditions至少 20 行代码。同样的需求用 PlaywrightCodex 往往一句page.get_by_role(button, name提交).click()就搞定。代码越短后续维护越省心这就是我选它的理由。3.2 实战 prompt登录-搜索-下单全流程生成我拿一个完整的 Web 自动化案例来说prompt 大概是这样使用 Playwright 的 Python 库编写一个 UI 自动化用例模拟以下流程 1. 打开 https://example.com/login 2. 在用户名框和密码框输入 admin / Admin123 3. 点击登录按钮 4. 进入首页后在搜索框输入关键词“codex” 5. 点击第一个商品链接验证商品详情页的标题包含“codex” 请用 pytest pytest-playwright 组织用例登录动作提取为 fixture用例结束后关闭页面。生成完以后Codex 会给一个 conftest.py 和一个 test_order.py。这里要注意它很可能把 URL 直接硬编码我一般会在 prompt 里追加一句“URL 从环境变量 BASE_URL 读取默认用测试环境地址”这样换环境就不用手改代码。生成完的脚本先跑一条观察浏览器动作是否符合预期。3.3 元素定位与稳定性保障AI 的 selector 不一定可靠这是 UI 自动化的最大坑。Codex 生成的 selector 很可能来自它从网上学到的“常见写法”但不一定匹配你的真实页面。比如它有时会用动态 ID 做定位页面一刷新就挂了。我的处理策略是拿到 AI 生成的代码后先不要直接跑自己打开浏览器开发者工具用选择器搜索验证一遍存在性。如果页面元素有稳定的>写一个 Python 脚本 1. 请求列表页UA 设置为浏览器 UA 2. 解析商品名称、价格、销量 3. 如果当前页没有数据sleep 2 秒后重试最多 3 次 4. 把结果写入 CSV按价格升序排序这里我不主张把绕反爬的内容写进去毕竟合规比效率重要。大家要关注的点是“Codex 能生成完整的数据流水线”抓取、清洗、落盘、告警。把这段脚本挂到 Linux 的 crontab 或者 GitHub Actions 上每天自动跑数据直接发到内部群就形成了“数据生产自动化”。4. 场景三App 自动化与办公脚本自动化4.1 Appium 冒烟测试让 Codex 处理设备配置和用例移动端自动化比 Web 麻烦因为多了一堆设备上下文。Appium 的 AppiumDriver、capabilities、等待元素加载这些配置对新手是门槛。Codex 的价值是帮你把这些“死代码”一次写好。我的一次 prompt用 Python Appium 为 Android 购物 App 写冒烟测试用例 1. capabilities 设置平台为 AndroidappPackage 为 com.example.shopappActivity 为 .MainActivity 2. 使用 UiSelector 定位进入“分类”页点击“电子商品” 3. 点击第一个商品验证“加入购物车”按钮存在 4. 用 pytest 组织使用 fixture 创建 driverteardown 中退出Appium 自动化最烦人的是“闪退和时序问题”。Codex 生成的 sleep 动不动就 5 秒我会在 prompt 里强调“优先使用显式等待不要用固定 sleep”。这样一来它能改成适合 Appium 的等待方式冒烟用例的稳定度提升明显。真实设备上跑的时候环境变量里的 devices 参数要单独管理别写死在代码里。4.2 办公自动化Excel、邮件、批量文件处理的日常脚本办公场景很多人小瞧但它是生产自动化里“看得见摸得着”价值的场景。我用 Codex 写过几十个办公脚本批量给文件重命名、合并多张 Excel、按模板生成周报、把 PDF 批量转图片。这类脚本的共同点是逻辑不复杂但用多了能省下大量时间。举个例子部门每天要汇总十几个 Excel 里的“销售额”以前手工复制粘贴要 20 分钟。我用 Codex 生成 openpyxl 脚本遍历指定目录下的 xlsx读取指定 Sheet 的指定单元格合并后写入汇总表再按日期命名。整个过程从想法到脚本跑通不到 10 分钟。这类需求跟“自动化测试”完全不同但同样属于“自动化生产”。给 Codex 描述办公需求时关键词要落到“表头在哪一行”“哪些列需要合并”“输出格式是什么”这些细节上。描述越具体生成的代码越接近可用。你也可以把目标文件的一小段数据贴进 promptCodex 会根据真实数据推断列名和格式这比用自然语言描述“数据表”高效得多。4.3 把 Codex 当脚本工厂一次描述长期复用的工具箱办公自动化最容易积累成“脚本工厂”。我的习惯是每让 Codex 生成一个可用的办公脚本都保存进一个 scripts/ 目录同时让 Codex 给脚本写 docstring 和参数说明。半年后你就有了一个自己的自动化脚手架遇到类似需求直接改参数就能用。这里有个小技巧把常用 prompt 沉淀成模板文件。例如 excel_summarize.md、email_send.md下次只需把新数据贴进去。Codex 对模板的响应质量通常显著高于随机描述因为模板里已经包含了历史项目里踩过的坑和约束条件。办公自动化的“多场景”很大程度上就是靠这种模板积累出来的。5. 完整实战复盘接口自动化生产框架从需求到上线5.1 用一段话交代清楚项目背景很多人用 Codex 效果不好不是因为模型不强而是需求描述太模糊。我的做法是先准备一段“项目背景描述”一次性交代清楚技术栈、目录结构、运行方式。比如这是一个 Python 接口自动化测试项目。 技术栈pytest requests allure。 目录tests/api/ 放用例utils/ 放请求封装和加密工具data/ 放接口数据。 运行方式python -m pytest tests/api -m full。 请在这个项目基础上新增订单查询接口的测试用例并复用现有的 HTTP 封装不要重复制造 requests 调用。把这段话作为 prompt 的第一段Codex 就能理解“这不是从零写一个项目而是在已有框架里扩展”输出的代码风格会贴近项目现状。很多人一开始就让它“帮我写一个完整的接口自动化框架”结果生成了一堆和现状不匹配的代码反而更尴尬。5.2 生成后先审查再运行AI 代码的三级验收收到 Codex 代码后我不会直接全量跑而是分三级验收第一级看逻辑用例是不是覆盖了需求里的关键场景第二级看依赖有没有引入不存在的包或者调用了项目里没有的函数第三级看运行跑单条用例看是否通过。三级都过了才让它继续生成下一部分。这套验收习惯来自我踩过的坑有一次 Codex 生成的 fixture 引用了 utils.db 模块但项目里根本没有这个模块运行直接 ModuleNotFoundError。如果一开始就全量跑会被这种低级错误带偏。先审查再运行能省很多调试时间让 Codex 根据报错信息修改通常也比自己翻代码更高效。5.3 联调与修复处理 AI 生成的常见“技术债”AI 生成的代码有一个典型问题它在单个功能上没问题但连起来就缺东西。比如测试登录成功后没保存 token下一个用例拿不到认证信息或者用例之间共享了全局变量跑批时互相污染。发现这类问题后我会把它们整理成一条条规则写回 prompt比如“token 保存在 fixture 中通过依赖注入传给用例”“每个用例独立初始化测试数据”。这个过程很像给实习生做 Code Review。你不需要全盘重写只需要把问题点指出来Codex 会基于反馈重新生成。多轮迭代后最终代码已经接近一个合格工程师的水平而且比你手写快得多。5.4 集成 CI流水线里的 Codex 不等于把代码直接扔进流水线最后是上线。我的 CI 流水线里Codex 只负责“生产代码”不负责“生产之后的稳定运行”。代码要进仓库先经过本地运行验证再走人工 review最后 CI 只跑 pytest。不要天真地把 AI 生成的代码当作完全可信自动化的意思是“运行自动化”不等于“信任自动化”。把生产框架上线后我一般会把 Allure 报告和失败列表发到工作群定时任务每天 9 点跑。当连续一周通过率都在 99% 以上这个框架才算真正“生产”起来。后续再有新增接口直接丢给 Codex 扩展用例再走同一套验收流程。6. 常见问题与避坑指南6.1 一次交付太乐观先小步验证使用 Codex 最常见的错误是想让它一次生成一个几十个文件的庞大项目结果出来的代码要么跑不动要么结构混乱。我的建议是一次只做一个模块验收一个再接下一个。让 Codex 在一次对话里聚焦到“一个场景的一小步”生成质量明显更高。6.2 上下文被“稀释”长会话后期会走样Codex 在长对话里容易遗忘早期提到的约束。比如你最开始说“不要用外部依赖”聊到后面再让它加功能它可能会引入一个第三方库。我的解决办法是项目约束写成一个 requirement.md每次发新的 prompt 时都把它贴进去或者干脆重新开一个会话只带必要的上下文。多场景自动化生产不是越聊越长而是把需求拆成一个个可验证的“原子任务”。6.3 密钥与权限自动化越深入越要守边界当自动化脚本开始连数据库、发邮件、调用业务接口时密钥和权限就成了最大的隐患。我绝不把密码写进脚本统一用环境变量读取。CI 环境里敏感字段放进 Secret 变量本地脚本用 .env 文件。Codex 生成的代码如果出现了硬编码的 api_key我会立刻让它改成从环境变量读取并且检查会话历史里是否泄露过完整密钥。6.4 版本兼容性AI 的知识库可能比你想象的旧Codex 的训练数据有截止时间当工具版本换代后它可能仍生成旧 API。最典型的就是 Playwright、Appium 这类工具版本更新很快。遇到报错先看版本让 Codex 参考当前环境的版本重新生成。有些时候问题只是把某个参数从字符串换成了字典自己翻文档会花很久让 Codex 按新版 API 重写反而更快。6.5 避坑速查表问题可能原因应对套路生成代码导入不存在的模块缺乏项目上下文把项目结构/依赖贴进 prompt元素定位不稳定selector 选择了动态 id用 role/text/data-testid 定位用例互相污染共享全局状态全部走 fixture 依赖注入CI 上跑不过但本地能过环境差异/依赖缺失用 requirements 固定版本接口文档变化导致断言失败返回字段调整让 Codex 根据新文档重写断言长会话后期不按约束生成上下文太长被稀释打开新会话重贴约束避坑的核心就一句话把 Codex 当成一个需要 Review 的协作者而不是全自动的答案机器。有了这层认知自动化生产能力才能稳定下来。最后分享一点个人体会。做多场景自动化生产最大的收获不是代码量而是养成了一套“用描述驱动生产”的工作方式不管接到的是接口回归、页面流程、还是办公琐事我都会先用几句话把场景、目标、边界写清楚再交给 Codex 生成第一版然后审查、小步验收、迭代。这套流程跑顺之后自动化在我这里不再是一堆脆弱的脚本而是一条条稳定的生产线。Codex 不会替你思考业务但它能帮你把“想到”快速变成“手上能跑的活”。如果你也想推自动化生产我的建议很简单挑一个重复了三遍以上的手工操作按我上面提到的 prompt 模板让 Codex 做一版先跑通再慢慢放大场景。你会发现那个让琐碎工作自动化的门槛已经低到超出预期。