概览
使用 Codex 找到正确的 Xcode scheme 和模拟器，启动应用，检查 UI 树，进行点击、输入、滑动，捕获截图和日志，在需要时附加 LLDB，并将一份模糊的 bug 报告转化为一个经过验证的小修复。
适合场景
- 只会在模拟器中经过特定点击、滚动或表单输入路径后才出现的 UI bug
- 崩溃、卡死或导航异常等情况，在修改代码前 Codex 需要日志、截图、视图层级状态和调试器回溯
- 希望由 Codex 完整负责“复现-修复-验证”循环，而不是让人工手动点过每个状态的团队
复现、诊断并修复一个模拟器 bug
使用 Build iOS Apps plugin 和 XcodeBuildMCP 直接在模拟器中复现这个 bug，诊断根本原因，并实现一个小修复。 Bug report: [描述预期行为、实际 bug，以及任何已知的界面或账户设置。] Constraints: - 先检查是否已经选定 project、scheme 和 simulator。如果没有，就找出正确的 Xcode project 或 workspace，选择应用的 scheme，选定一个 simulator，并在本次会话剩余时间里复用这套配置。 - 在 Simulator 中构建并启动应用，然后在开始交互前，先通过 UI 快照或截图确认当前显示的是正确界面。 - 你自己通过在模拟器中点击、输入、滚动和滑动来完成精确的复现路径。优先使用无障碍标签或 ID，而不是原始坐标；当布局发生变化时，在执行下一个操作前重新读取 UI 层级结构。 - 在调试时捕获证据：为视觉状态保存截图，在故障发生前后抓取模拟器日志，如果 bug 看起来像崩溃或卡死，则抓取 LLDB 栈帧或变量。 - 如果模拟器尚未启动，就启动一个，并告诉我你选择了哪个设备和 OS。如果需要凭据或特殊 fixture，请暂停，并且只询问缺失的那项输入。 - 做出能解决该 bug 的最小代码修改，然后重新运行模拟器中的流程，并准确告诉我你是如何验证修复的。 Deliver: - Codex 执行的复现步骤 - 用来解释 bug 的关键截图、日志或堆栈细节 - 代码修复以及它为什么有效 - 用于最终验证的模拟器和 scheme
让 Codex 接管整个模拟器循环
当 Codex 接管完整循环时，这个用例效果最佳：选择正确的应用 target，在 Simulator 中启动应用，检查当前界面，执行复现步骤，收集日志和截图，必要时检查堆栈跟踪，修补代码，然后重新运行相同路径来证明 bug 已经消失。
当你希望这个循环保持 agentic 时，请使用 Build iOS Apps 插件。它的 iOS 调试工作流围绕 XcodeBuildMCP 构建，这意味着 Codex 可以与一个已启动的模拟器交互，并收集通常需要人工手动获取的同类证据。
当 XcodeBuildMCP 配置了模拟器自动化、UI 自动化、调试和日志工作流后，Codex 就可以接管完整的“复现-调试-验证”循环。如果 Codex 还没有选定 project、scheme 和 simulator，请先让它发现这些内容，并在本次会话剩余时间里复用这套配置。
利用 XcodeBuildMCP 的能力
以下是一些可以提示 Codex 使用的实用能力分组：
- Project 和 simulator 发现：检查 Codex 是否已经知道该使用哪个应用 target 和 simulator，发现 Xcode project 或 workspace，枚举 schemes，查找或启动一个 simulator，并在后续构建/运行步骤中保持这套配置稳定。
- 构建与启动控制：构建当前活动的应用 target，安装并启动模拟器构建产物，在需要时重新启动并捕获日志，如果 Codex 需要检查应用专属的运行时日志，则解析 app bundle id。
- UI 检查与交互：读取屏幕上的无障碍层级，截取屏幕截图，点击控件，在字段中输入，滚动列表，并执行边缘滑动或其他模拟器手势。
- 日志与调试器状态：流式读取模拟器日志，将 LLDB 附加到正在运行的应用，设置断点，检查栈帧和局部变量，并在崩溃或卡死需要更深入检查时运行调试器命令。
关键习惯是在点击前先让 Codex 检查视图树。XcodeBuildMCP 会暴露无障碍层级和坐标，因此 Codex 可以优先使用稳定的标签或元素 ID，而不是猜测原始屏幕位置。
把模糊的 bug 变成可复现脚本
当你的提示给出一个具体 bug 和一个预期结果，然后让 Codex 自主驱动应用并收集证据时，iOS 调试技能最有效。如果需要登录、deep link 或测试 fixture，请只说明一次，并要求 Codex 仅在这些缺失输入阻塞进展时暂停。
实用建议
要求证据，而不只是修复
要求提供 Codex 用来解释该 bug 的准确模拟器、scheme、截图、日志片段和堆栈细节。这样最终补丁会比“我觉得这应该能修好”更容易审查。
优先使用无障碍标签，而不是坐标
如果 Codex 因为某个控件没有稳定标签或 accessibility identifier 而不得不按坐标点击，要求它明确指出这一点。这通常说明 bug 修复也应该顺带包含一个小的 UI 可测试性改进。
每次运行只处理一个 bug
模拟器驱动的调试循环很强大，但当一次提示只针对一种故障模式时，结果仍然更容易让人信任。先让 Codex 完成一个“复现-修复-验证”循环，再扩展到相邻问题。