原文核对：2026-10-13 · 中文正文 · 英文提示词与演示
场景定位
找到正确 scheme 和模拟器，启动应用，检查 UI 树，执行点击、输入和滑动，采集截图与日志，必要时附加 LLDB，完成可验证的小修复。
- 难度
- 高级
- 时间跨度
- 1 小时
适合用于
- 依赖特定点击、滚动或表单路径才出现的 UI 缺陷。
- 需要日志、截图、视图层级和回溯才能定位的崩溃、卡住或导航故障。
- 希望 Codex 负责复现—修复—验证循环的团队。
相关工具
通过 XcodeBuildMCP 构建、启动和操作模拟器，采集日志、截图与堆栈，缩小问题范围。
Build iOS Apps ↗起步提示词
英文原文 · 可复制后按实际材料修改
Use the Build iOS Apps plugin and XcodeBuildMCP to reproduce this bug directly in Simulator, diagnose the root cause, and implement a small fix.
Bug report:
[Describe the expected behavior, the actual bug, and any known screen or account setup.]
Constraints:
- First check whether a project, scheme, and simulator are already selected. If not, discover the right Xcode project or workspace, pick the app scheme, choose a simulator, and reuse that setup for the rest of the session.
- Build and launch the app in Simulator, then confirm the right screen is visible with a UI snapshot or screenshot before you start interacting with it.
- Drive the exact reproduction path yourself by tapping, typing, scrolling, and swiping in the simulator. Prefer accessibility labels or IDs over raw coordinates, and re-read the UI hierarchy before the next action when the layout changes.
- Capture evidence while you debug: screenshots for visual state, simulator logs around the failure, and LLDB stack frames or variables if the bug looks like a crash or hang.
- If the simulator is not already booted, boot one and tell me which device and OS you chose. If credentials or a special fixture are required, pause and ask only for that missing input.
- Make the smallest code change that addresses the bug, then rerun the simulator flow and tell me exactly how you verified the fix.
Deliver:
- the reproduction steps Codex executed
- the key screenshots, logs, or stack details that explained the bug
- the code fix and why it works
- the simulator and scheme used for final verification交给 Codex 完整模拟器循环
让 Codex 选择 target、启动模拟器、查看页面、复现、收集日志截图，必要时检查堆栈，再修改并重跑相同路径以证明修复。
Build iOS Apps 的 iOS debugger 流程基于 XcodeBuildMCP，可以操作已启动模拟器并自动采集通常由人工收集的证据。
配置模拟器、UI 自动化、调试和日志工作流后，可负责完整循环。尚未选择 project、scheme 和模拟器时先发现它们，并在本次会话中复用。
使用 XcodeBuildMCP 能力
可要求使用这些能力：
- 发现项目与模拟器：检查已有配置，发现 project/workspace、列出 scheme、查找或启动模拟器，后续保持一致。
- 构建与启动：构建 target、安装启动，按需带日志重启，解析 bundle id 以检查应用专属日志。
- UI 检查与操作：读取无障碍层级、截图、点击、输入、滚动及边缘滑动等手势。
- 日志与调试：流式日志、附加 LLDB、断点、堆栈帧和局部变量，以及深入检查崩溃或卡住的调试命令。
点击前先检查视图树，优先使用稳定标签或元素 ID，而非猜测屏幕坐标。
把模糊问题变成可复现流程
提供一个具体缺陷和预期结果，允许自主操作和采集证据。一次说明登录、深链或测试数据要求，仅缺失输入阻塞时再暂停。
实用建议
要求证据
提供实际使用的模拟器、scheme、截图、日志片段和堆栈细节，让修复便于审阅。
优先无障碍标签
无稳定标签或标识符、不得不用坐标点击时应明确指出，可能需要一并改善 UI 可测试性。
每轮聚焦一个缺陷
先完成一个复现—修复—验证循环，再扩展到邻近问题。
技术栈
| 需要 | 默认选项 | 用途 |
|---|---|---|
| 模拟器自动化 | XcodeBuildMCPXcodeBuildMCP ↗ | 配置、构建启动、UI 快照、点击输入手势、截图、日志和调试器附加。 |
| 代理流程 | Build iOS Apps 插件Build iOS Apps plugin ↗ | 以模拟器为中心复现、取证，并在每次修改后验证。 |
| 可观测性 | Logger、OSLog、LLDB 和模拟器截图 | 用日志与调试状态解释故障，截图证明修复前后的 UI。 |
展开英文原文对照
Use Codex to discover the right Xcode scheme and simulator, launch the app, inspect the UI tree, tap, type, swipe, capture screenshots and logs, attach LLDB when needed, and turn a vague bug report into a small verified fix.
Give Codex the whole simulator loop
This use case works best when Codex owns the full loop: choose the right app target, launch the app in Simulator, inspect the current screen, perform the reproduction steps, gather logs and screenshots, inspect a stack trace if needed, patch the code, and rerun the same path to prove the bug is gone.
Use the Build iOS Apps plugin when you want that loop to stay agentic. Its iOS debugger workflow is built around XcodeBuildMCP, which means Codex can interact with a booted simulator and gather the same evidence a human would normally collect by hand.
When XcodeBuildMCP is configured with simulator automation, UI automation, debugging, and logging workflows, Codex can own the full reproduce-debug-verify loop. If Codex has not picked a project, scheme, and simulator yet, ask it to discover those first and reuse that setup for the rest of the session.
Leverage what XcodeBuildMCP can do
These are the practical capability groups to prompt Codex to use:
- Project and simulator discovery: check whether Codex already knows which app target and simulator to use, discover the Xcode project or workspace, enumerate schemes, find or boot a simulator, and keep that setup stable for future build/run steps.
- Build and launch control: build the active app target, install and launch the simulator build, relaunch with log capture when needed, and resolve the app bundle id if Codex needs to inspect app-specific runtime logs.
- UI inspection and interaction: read the on-screen accessibility hierarchy, take screenshots, tap controls, type into fields, scroll through lists, and perform edge swipes or other simulator gestures.
- Logs and debugger state: stream simulator logs, attach LLDB to the running app, set breakpoints, inspect stack frames and local variables, and run debugger commands when a crash or hang needs deeper inspection.
The key habit is to ask Codex to inspect the view tree before it taps. XcodeBuildMCP exposes the accessibility hierarchy plus coordinates, so Codex can prefer stable labels or element IDs instead of guessing raw screen positions.
Turn a vague bug into a reproducible script
The iOS debugger skill is most effective when your prompt gives one concrete bug and one expected outcome, then lets Codex drive the app and collect evidence autonomously. If a login, deep link, or test fixture is required, say that once and ask Codex to pause only when that missing input blocks progress.
Practical tips
Ask for evidence, not just a fix
Request the exact simulator, scheme, screenshots, log snippets, and stack details that Codex used to explain the bug. That makes the final patch much easier to review than “I think this should fix it.”
Prefer accessibility labels over coordinates
If Codex has to tap by coordinates because a control has no stable label or accessibility identifier, ask it to call that out. That is often a signal that the bug fix should include a small UI testability improvement too.
Keep one bug per run
A simulator-driven debugging loop is powerful, but it is still easier to trust when one prompt targets one failure mode. Ask Codex to finish one reproduce-fix-verify cycle before expanding to adjacent issues.