将完整的模拟器循环交由 Codex 处理

当 Codex 负责整个循环时，此用例效果最佳：选择正确的应用目标，在模拟器中启动应用，检查当前屏幕，执行复现步骤，收集日志和截图，在需要时检查堆栈跟踪，修补代码，并重新运行相同的路径以证明错误已被消除。

使用 Build iOS Apps 插件 当你希望该循环保持自主智能体状态时。它的 iOS 调试器工作流围绕 XcodeBuildMCP 构建，这意味着 Codex 可以与已启动的模拟器进行交互，并收集人类通常手动收集的相同证据。

当 XcodeBuildMCP 配置了模拟器自动化、UI 自动化、调试和日志记录工作流时，Codex 便能拥有完整的“复现-调试-验证”循环。如果 Codex 尚未选择项目、scheme 和模拟器，请要求它首先发现这些信息，并在会话的其余部分复用该设置。

发挥 XcodeBuildMCP 的能力

这些是可以提示 Codex 使用的实用功能组：

• 项目和模拟器发现：检查 Codex 是否已知道要使用的应用目标和模拟器，发现 Xcode 项目或工作区，枚举 scheme，查找或启动模拟器，并保持该设置在未来的构建/运行步骤中稳定不变。
• 构建和启动控制：构建活动的应用目标，安装并启动模拟器构建版本，在需要时重新启动并捕获日志，以及在 Codex 需要检查特定于应用的运行时日志时解析应用包 ID。
• UI 检查和交互：读取屏幕上的辅助功能层次结构，截取屏幕截图，点击控件，在字段中输入，滚动列表，以及执行边缘滑动或其他模拟器手势。
• 日志和调试器状态：流式传输模拟器日志，将 LLDB 附加到正在运行的应用，设置断点，检查堆栈帧和局部变量，以及在崩溃或挂起需要更深入检查时运行调试器命令。

关键习惯是要求 Codex 在点击之前检查视图树。XcodeBuildMCP 公开了辅助功能层次结构及坐标，因此 Codex 可以优先使用稳定的标签或元素 ID，而不是猜测原始屏幕位置。

将模糊的错误转化为可重现的脚本

当你给出一个具体的错误和一个预期结果，然后让 Codex 自主驱动应用并收集证据时，iOS 调试器技能最为有效。如果需要登录、深度链接或测试夹具，请说明一次，并要求 Codex 仅在缺失的输入阻碍进度时才暂停。

实用技巧

要求提供证据，而不仅仅是修复

请求 Codex 用来解释错误的确切模拟器、scheme、截图、日志片段和堆栈详情。这使得最终的补丁比“我认为这应该能修复它”更容易审查。

优先使用辅助功能标签而不是坐标

如果 Codex 必须通过坐标点击是因为某个控件没有稳定的标签或辅助功能标识符，请要求它指出这一点。这通常是一个信号，表明错误修复还应包含一个小幅的 UI 可测试性改进。

每次运行只处理一个错误

模拟器驱动的调试循环非常强大，但当一个提示只针对一个故障模式时，它仍然更容易让人信任。要求 Codex 在扩展到相邻问题之前完成一个“复现-修复-验证”循环。