必须在真实环境运行验证Codex修改效果：先用git stash保存改动并启动服务确认基础功能正常，再git stash pop恢复修改并重复启动访问；输入必须严格一致（如固定HTTP请求或输入文件），输出通过重定向日志、自动化截图或埋点日志捕获，最后逐项比对状态码、响应体及关键日志差异。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你想确认Codex修改代码后，程序实际运行行为是否真的按预期变化，而不是只看文件diff就默认“改对了”——这一步必须在真实环境里跑起来，用输入触发、用输出验证、用状态对比，才能发现逻辑漂移、副作用或隐藏崩溃。
准备两套可比对的运行环境
先确保修复前后的代码能分别启动且不报错。打开终端，进入项目根目录，执行：git stash → npm start（或python main.py等对应命令），等服务完全就绪后访问一次基础路径（如http://localhost:3000），确认页面/接口能返回内容；再执行git stash pop恢复Codex改动，重复启动→访问流程。两次都成功，才具备可比性。
如果修复后根本启动失败，别急着看结果差异——先解决Module not found或TypeError: Cannot read property这类阻断性错误。这类问题会让后续所有运行对比失去意义。
设计同一组输入驱动两次运行
不能靠“随便点两下看看像不像”。必须固定输入源：如果是Web应用，用Postman或curl发相同HTTP请求；如果是CLI工具，保存一组参数到test-input.txt，两次都执行codex-process --input test-input.txt；如果是数据处理脚本，准备一个sample.csv作为唯一输入文件。
【输入文件必须完全一致，且不能含时间戳、随机ID、本地路径等动态字段】。否则输出差异会混入噪声，无法判断是逻辑变更还是环境扰动。
这一步操作起来很简单，直接把文件拖进去就行。但很多人跳过它，直接肉眼扫界面，结果把缓存导致的按钮变灰当成Codex改坏了状态管理。
捕获并结构化输出结果
方法一：终端命令直接重定向
执行修复前命令时加> before.json 2>&1，修复后加> after.json 2>&1。注意2>&1必须带上，否则报错信息会漏掉。
通过本地 Codex 或 OpenClaw OAuth 凭证直接调用 ChatGPT/Codex Responses 的 image_generation 工具来生成或编辑光栅图像，然后保存
方法二：浏览器自动化截图（仅限UI）
用Playwright录制同一操作流：打开首页→点击搜索框→输入“test”→截全屏。生成before.png和after.png。不要用系统自带截图，它无法保证视口尺寸、缩放比例、字体渲染一致性。
方法三：日志埋点比对（推荐用于后台逻辑）
在关键分支入口加console.log('auth check:', user.role)或logger.info(f"payment_status: {status}")，将日志输出到log-before.txt和log-after.txt。Codex若删了某条日志打印，你立刻就能从文件行数差里发现。
逐项比对输出差异
第一步：检查HTTP状态码与响应头
用curl -I http://localhost:3000/api/user分别对修复前后执行。如果之前是200 OK，现在变成500 Internal Server Error，不用看body内容，修复已失败。
第二步：比对JSON响应主体
执行：diff before.json after.json | grep -E "^[]"。只看新增和删除<code>>行，忽略空格和换行差异。若出现而你没要求加限流，说明Codex擅自引入了新逻辑。
第三步：验证业务含义是否一致
例如输出都含"status": "success"，但修复前"data"是用户对象，修复后变成空数组——表面状态码和字段名没变，实际语义已断裂。这时要回查Codex的diff，看它是否误删了return user而写了return []。
第四步：运行时副作用检查
打开浏览器开发者工具的Network面板，清空记录→执行同一操作→对比请求数、资源加载顺序、是否有意外的/analytics或/track请求发出。Codex有时会悄悄补上它认为“该有”的埋点。
