你想用 Codex 构建 iOS 或 macOS 应用吗？
我有一套新的 Agent Skill，能帮你快速开发应用。没有这个技能，你会浪费大量时间。听我解释。
我在用 Codex 构建一个“危险蜘蛛”应用时，发现 Agent 总是忽略自己的构建和测试失败。它盯着错误的状态码，根本找不到错误，还自以为一切正常（其实并没有）。
Xcode 编译器构建输出极其冗长。 真正的错误被淹没在成千上万行文本里。在 Xcode 构建输出中找错误，就像大海捞针。
Xcode 构建输出文本量巨大。
当你叠加 Agent 时，让它们去找错误只会浪费时间和上下文。
Agent 需要知道什么成功了、什么失败了。它需要的是“通过/失败”的明确信号，所以我专门设计了一个面向 Agent 的工作流来实现这一点。
这是我每天使用的 7 步工作流：
1. 用 AppCreator 让 Xcode 项目对 Agent 友好
我构建了一个 名为 AppCreator 的 Agent Skill。运行一次，它就能搭建一个新的 Xcode 项目，或者改造一个现有项目。现在你的项目已经为 Agent 准备好了。
App Creator Skill: https://super-easy-apps.kit.com/app-creator
核心在于：一个 Makefile 使用 xcbeautify 封装了 CLI 的 xcodebuild 命令。Xcode 应用构建和测试的输出变得干净、可读。Agent 能看到哪里失败了，修复它，然后继续。不再需要搜索冗长的输出。它适用于 iPhone 和 Mac 应用。
下载并安装 AppCreator Skill，让你的应用项目对 Agent 更友好。
2. make 是我唯一使用的构建命令
这个技能的设计使得一个命令就能构建并运行你的应用：
*make*
"make" 构建并运行我的 iOS 和 macOS 应用。
你的 Agent 知道如何使用 Makefiles，所以这只是一个起点。你可以按需扩展它。
我让 Agent 将默认操作设置为 "build-and-run"，并使用特殊的构建脚本，这样新构建的应用总能自动重新启动，就像 Xcode 一样。
- 在 Codex CLI 中，输入 "make" 来检查 Agent 的工作。
- 在 Codex 应用中，设置一个自定义运行操作：点击播放按钮，将其设置为：make。
自定义 Codex 应用操作
之后要找到这个设置需要多几步：前往 Environments → Project → View → Edit Local Actions → Actions → 将 Action Script 设置为 make。
创建额外的环境操作
有了 Makefile，你就拥有了一种快速、可重复的方式来构建和运行你的应用（通过 CLI 的上箭头键或 Codex 应用中的运行按钮）。
3. 直接跟它说
如果你想获得好结果，就需要主动引导你的 Agent。
Agent 很强大，但它们会做一些你不希望做的事，唯一避免的方法就是在它们工作时掌好舵。
我经常反复检查工作，并在发现 Agent 做错事时及时纠正。
我使用 Wispr Flow 大声说出来——描述我想要什么、它应该如何表现、需要改变什么。当 Agent 交回工作后，我在手动测试新改动时启动 Wispr Flow。这让我有机会说出哪些有效、哪些无效，然后，完成后，我可以直接把转录内容粘贴到 Codex 应用中。
计划模式 有助于激发关于功能和边缘情况的思考。不过，我发现计划模式还不够好。
相反，我会用计划模式来帮助你思考功能，把它作为一个起点。用它来激发讨论，这样你就能精炼出最终要构建哪些功能。
软件是微妙的，如果你一个功能一个功能地推进，最终你会得到更好的软件。
4. 测试让 Agent 保持负责
没有测试，Agent 会变得马虎。测试让 Agent 能够捕捉自己的错误。
让 Codex 在构建时编写单元测试。你的目标是快速测试。UI 测试有助于验证，但它们可能很烦人且运行缓慢。我喜欢让 Agent 使用 UI 测试来捕捉那些仅靠单元测试无法测试的错误。
"make test" 用于快速单元测试
我的建议是，将你的测试至少分成两个目标：
- make test
- make ui-test
当 Agent 运行 UI 测试时，它会占用你的机器，如果你需要做其他事情，这可能会造成干扰（这时有第二台 Mac 就很有用）。
UI 测试会拖慢一切，所以最好只在交接点测试它们。当你的 Agent 完成了一个或多个任务时。不要对增量工作进行完整的回归测试；相反，让 Agent 只测试最小的子集来验证它们的工作，并保持快速。
让你的 Agent 阅读 Peter Steinberger @steipete 的这篇文章：以极速在 iOS 上运行 UI 测试。利用这一点，你可以帮助你的测试套件避免成为瓶颈。
5. 记录运行时结果
另一个不可或缺的工具是使用日志和应用产物。让你的 Agent 为你的应用添加日志记录。这为它提供了另一个实时查看哪里出错的工具。
Agent 可以将开发日志流式传输到文件，或实时读取它们来修复那些不立即明显的问题。
日志能帮助 Agent 实时发现哪里出错了。
当我的 Agent 反复无法正确完成任务时，我就知道该引入更详细的日志了。
直接对你的 Agent 说：
请在 XYZ 周围添加详细日志，以便你能看到发生了什么并修复问题。
现在你的 Agent 有了测试逻辑和运行时验证结果的工具。
6. 你应该添加的 AGENTS.md 规则
以下是一些对我有用的规则。你可能需要根据自己的工作流进行调整。
我在 AppCreator skill 里包含了两个脚本，用于防止危险的 git 命令和文件删除。
* 未经我明确书面批准，不得添加任何回退或变通方案。如有疑问，请询问。
* 不得将“继续”或沉默视为对任何回退行为的批准。
* 每个操作只使用一个代码路径。按钮、菜单、弹出按钮、键盘快捷键和手势必须调用同一个实现。
* 不要为新代码添加向后兼容性。仅当已有发布行为时才保留向后兼容性。不清楚就问。
* 为用户操作、模式切换、监控目标定位和输入添加详细日志。在运行时利用这些日志排查问题。
* 未经我明确书面批准，不得运行破坏性 git 命令。
* 禁止的 git 命令：`git reset --hard`、`git checkout --`、`git restore`、`git revert`、`git clean`、强制推送和 `git amend`。
* 始终做原子提交。每次提交一个任务或修复。使用 `scripts/atomic_commit.sh Agent <NAME>: <intent>" <file1> <file2> ...`
* 永远不要使用 `rm` 删除文件。
* 始终使用回收站脚本 `scripts/move_to_trash.sh <paths...>`，以便删除可以撤销。
* 在实现过程中运行快速、有针对性的测试，将完整的回归测试留到最后交接。
* 仅在被要求时才运行 UI 测试。
* 如果工具或环境问题阻塞了验证，不要声称验证通过。7. 你的 Agent 需要文档
想要获得更高阶的效果？通过 DocSetQuery 给 Codex 提供真实的 Apple 文档。
我用 DocSet 捆绑包构建本地 Apple 文档集，并让 Agent 创建指南。
Agent 对代码的理解是模糊的。你需要给它们具体的代码，让它们使用实际 API 而不是猜测。
另一个选择是 https://sosumi.ai
这是我用的——直接拿去用：
- AppCreator skill：搭建新项目或改造已有项目。
- 直接和它对话：保持焦点小且易于理解。
- DocSetQuery：让 Agent 利用快速的本地 Apple 文档。
你的 Codex 工作流是什么样的？在下面回复。
关注 @PaulSolt 获取我正在用来构建和发布 iOS 和 macOS 应用的实际 Codex 工作流。
P.S. Super Easy Slides 已上架 Mac App Store（就是用这个工作流构建的）。你也可以在这里预览我的 Dangerous Spider 应用。