需求
应用日志
默认选项
为何需要它
结构化的统一日志为 Codex 提供了一个狭窄、可过滤的反馈循环,而不会将代码库变成一堵 print statements.
Codex 用例
使用 Codex 通过 Logger 为一个 Mac 功能添加埋点,运行应用,并从统一日志中验证操作。
使用 Codex 和 Build macOS Apps 插件,在窗口、侧边栏、命令或同步流程周围添加一些高价值的 Logger 事件,然后运行应用,并通过 Console 或 log stream 验证正确的操作是否已触发。
使用 Codex 通过 Logger 为一个 Mac 功能添加埋点,运行应用,并从统一日志中验证操作。
使用 Codex 和 Build macOS Apps 插件,在窗口、侧边栏、命令或同步流程周围添加一些高价值的 Logger 事件,然后运行应用,并通过 Console 或 log stream 验证正确的操作是否已触发。
使用 Codex 和 Build macOS Apps 插件,在窗口、侧边栏、命令或同步流程周围添加一些高价值的 Logger 事件,然后运行应用,并通过 Console 或 log stream 验证正确的操作是否已触发。
相关链接
| 技能 | 为什么使用它 |
|---|---|
| 使用 macOS SwiftUI 模式、窗口管理、AppKit 互操作以及构建/运行技能,创建侧边栏-详情-检查器布局,连接菜单和设置,并在外壳优先的循环中验证应用。 | 使用 macOS 遥测和构建/运行技能添加结构化的 `OSLog` 埋点,启动应用,演练 UI 路径,并从 Console 或 `log stream` 验证发出的事件。 |
此用例适用于 Mac 应用流程中那种仅凭代码审查无法准确定位问题的模糊情况。要求 Codex 在某个行为周围添加几条高价值的统一日志,运行应用,触发该行为,并从 Console 或 log stream 验证预期的事件是否已触发。
使用 构建 macOS Apps 插件 用于该循环。它的 macOS 遥测技能被有意设计得很轻量:使用 Apple 的 Logger,请选择清晰的子系统/类别对,记录动作边界和状态转换,避免敏感的负载数据,并在本地构建/运行后验证事件,而不是假设插桩已被正确连接。
良好的日志为 Codex 在每次修补后提供了可重复的反馈循环。智能体无需要求你手动检查每个窗口、菜单操作或同步转换,而是可以运行应用、演练流程、检查过滤后的日志,并根据证据决定下一步的代码更改。
这对于三种智能体循环尤其有用:
每个功能区域只向 Codex 索要一个 Logger,而不是为每一次状态变更都添加永久日志行。诸如以下的功能类别 Windowing, Commands, MenuBar, Sidebar, Sync, or Import 使日志在下一次调试时更容易过滤。
import OSLog
private let logger = Logger(
subsystem: Bundle.main.bundleIdentifier ?? "SampleApp",
category: "Sidebar"
)
@MainActor
func selectItem(_ item: SidebarItem) {
logger.info("Selected sidebar item: \(item.id, privacy: .public)")
selection = item.id
}
使用 info 用于应随时间保持有用的简洁操作和生命周期事件,而 debug 用于在任务完成前可能被移除或降级的、较为嘈杂的局部状态细节。仅在测量时间跨度时添加 signposts,不要默认添加。
有用的部分不仅仅是添加 Logger 调用。要求 Codex 运行应用,触发已埋点的流程,并向你提供它使用的精确 Console 过滤器或 log stream predicate,以及一到两行有代表性的日志记录。
log stream --style compact --predicate 'subsystem == "com.example.app" && category == "Sidebar"'
如果预期的事件未出现,要求 Codex 将日志移至更接近可疑控制路径的位置,重新运行相同的流程,并不断迭代,直到日志解释了发生的情况。如果任务转变为崩溃或回溯分析,请切换到插件的构建/运行调试工作流,并保持遥测聚焦于操作边界。
对于耗时较长或间歇性出现的 bug,要求 Codex 将聚焦的 log stream 保存到一个小的本地追踪文件中,总结时间线,并将该产物留在工作区,以便后续的 Codex 运行可以检查相同的证据,而无需从内存中重放整个会话。当你希望一个智能体运行收集追踪,而另一个运行比较修补前后的行为时,这会使多轮调试变得更容易。
当需要人工驱动部分会话时,这也非常有效。要求 Codex 在对日志友好的调试循环中启动应用,开始一次过滤捕获,在你手动重现问题时等待,然后在你完成后再读取保存的追踪文件。
从单个侧边栏、窗口、命令或同步路径开始,这样日志序列会保持易于检查的状态。如果该路径变得可靠,Codex 可以将相同的模式扩展到相邻的流程。
要求 Codex 解释每个记录的标识符,并避免将秘密、个人数据或原始内容写入统一日志。微小的事件词汇通常足以进行本地调试。
有代表性的日志记录比“已添加遥测”更让人信赖。要求 Codex 包含过滤器 predicate 和简短的操作时间线,以便下一次智能体运行可以复用相同的验证循环。
需求
默认选项
为何需要它
需求
应用日志
默认选项
为何需要它
结构化的统一日志为 Codex 提供了一个狭窄、可过滤的反馈循环,而不会将代码库变成一堵 print statements.
需求
智能体工作流
默认选项
为何需要它
该插件的遥测和构建/运行技能被设计为协同工作:为一个流程添加埋点、启动应用、检查日志并收紧事件集。
需求
运行时验证
默认选项
Console.app 和 log stream --predicate ...
为何需要它
具体的日志过滤器加上示例输出为智能体提供了可重复的交接,并使新的埋点在多次运行中易于验证。
| 需求 | 默认选项 | 为何需要它 |
|---|---|---|
| 应用日志 | OSLog 日志记录器 | 结构化的统一日志为 Codex 提供了一个狭窄、可过滤的反馈循环,而不会将代码库变成一堵 print statements. |
| 智能体工作流 | 构建 macOS Apps 插件 | 该插件的遥测和构建/运行技能被设计为协同工作:为一个流程添加埋点、启动应用、检查日志并收紧事件集。 |
| 运行时验证 | Console.app 和 log stream --predicate ... | 具体的日志过滤器加上示例输出为智能体提供了可重复的交接,并使新的埋点在多次运行中易于验证。 |