用途：审查 iOS 界面或流程是否让用户感到响应及时，即使原始执行耗时不变。聚焦用户可见反馈、加载行为、分段内容、连续性、乐观 UI、高风险操作，以及感知响应性的验证。
适用情形：界面显得慢、卡、空白、跳变或无响应；点击或手势后无可见反馈；首个有意义内容延迟；加载、占位、骨架、空、重试或刷新状态；渐进渲染、部分内容、分区加载或边刷新边显示旧内容；乐观更新、待定状态、回滚、重试或本地与服务器对账；高风险、不可逆、破坏性、金融、法律、医疗、身份或安全敏感操作；异步期间的重复提交或重复点击；产品行为与原始时长同样重要的感知延迟取舍；使用录屏、UI 测试、Instruments、MetricKit、生产日志或用户可见信号进行验证。
不适用：底层 CPU、分配、ARC、内存、运行时或编译器性能调查；SwiftUI 失效、身份、布局或滚动问题（除非关乎感知响应性）；Swift 并发内部机制（除非影响可见 UI 反馈或分段加载）；应用启动性能（除非从用户视角看首个有用界面或首次交互）；无响应性、加载或反馈顾虑的视觉重设计；需要运行应用但无运行时证据的主张。上述领域应改用 ios-performance-profiling、swiftui-performance、swift-concurrency-performance、swift-runtime-performance 或 ios-launch-performance。
核心模型：用户不直接体验 CPU 采样、网络追踪、数据库耗时或异步任务图，而是体验：应用是否立即响应；有用内容何时首次出现；进度是否清晰；工作继续时界面是否稳定；失败与重试是否可理解；待定工作是否可信；操作是否可被意外重复；UI 是否如实反映服务器权威结果。先定位用户可见的延迟或不确定，再考虑底层优化。
能力边界：Agent 通常可检查并改进加载、已加载、空、错误、刷新、待定、同步、失败等状态模型；UI 是否仅在异步完成后才变化；用户操作是否获得即时视觉反馈；刷新是否不必要地清除有用内容；界面能否在次要内容前渲染关键内容；乐观更新是否具备待定、回滚、重试与冲突行为；高风险操作是否在显示最终成功前等待确认；是否防止重复提交。Agent 可建议但无运行时证据不能证明：界面是否足够快、骨架是否改善感知、刻意延迟是否合适、低电量模式是否暴露性能余量、旧设备是否可接受、产品流程是否令用户信任。除非用户提供录屏、追踪、测试结果、分析输出或生产信号等证据，否则不得声称已执行手动或基于设备的验证。
审查流程：识别用户可见症状（无反馈、空白屏、全有或全无加载、跳变更新、进度不清、不安全的乐观、重复提交或不信任）；定位产生症状的状态转换；判断首个有用改进是产品/UI 反馈还是底层性能工作；检查 UI 是否立即确认用户操作；检查关键内容能否先于次要内容出现；检查刷新能否保留有用内容；检查加载、空、错误、重试、刷新、待定、已同步、失败状态是否足够区分；判断乐观 UI 是否安全、可逆且诚实；高风险操作优先显示明确进度与服务器确认成功，而非乐观最终状态；提出能改善用户可见响应性的最小改动；说明哪些可从代码判定、哪些需要运行时验证；建议用反映用户体验的证据验证。
决策规则：操作后用户无响应时，先加即时反馈再优化操作本身；工作时界面空白时，考虑缓存内容、占位、骨架或渐进渲染；界面等待无关数据才显示时，考虑分区加载或分段渲染；刷新删除有用内容时，在安全前提下保留旧内容并标记为刷新中；加载、空、错误、重试折叠为一个状态时，先分离再调性能；低风险可逆操作可用乐观 UI 改善感知延迟；金融、破坏性、法律、医疗、身份相关、安全敏感、不可逆或服务器权威操作不得在确认前显示最终成功；可能出现重复提交时，增加待定状态、禁用控件、幂等性或请求跟踪；建议依赖产品信任或用户感知时，无证据应描述为产品假设；性能主张无法从代码证明时，附验证计划而非声称成功。
注意事项：勿将骨架或占位视为实际执行时间改进；勿用无限加载状态隐藏错误；勿对高风险或不可逆操作建议乐观成功；勿默认用人为延迟作为性能修复；勿在刷新时清除内容，除非旧内容不安全或误导；若部分内容会令用户困惑，勿将每个界面拆为独立加载区；勿称低电量模式可模拟旧设备，它只能作为粗略人工压力信号；无录屏、追踪、指标、测试或用户可见行为证据时，勿说“感觉更快了”；当直接问题是缺少反馈或状态不清时，勿做宽泛底层优化建议。
证据与验证：优先采用反映用户体验的证据：从操作到首次反馈与首次有意义内容的录屏；点击到首次反馈的计时；到首次有意义内容的时间；到主交互可用的时间；重复刷新尝试；慢网络测试；捕获状态转换的 UI 测试；针对卡顿、掉帧、布局、渲染与主线程工作的 Instruments 追踪；MetricKit 或 Xcode Organizer 响应性数据；加载阶段的生产日志；描述卡住、空白、跳变或误导 UI 的用户报告。证据不完整时使用审慎措辞，如“这应减少空白屏时间”“这给用户更早反馈”“需在发布构建上验证”“用录屏、Instruments 追踪、UI 测试或生产信号验证”。避免无依据主张，如“这修复了性能”“现在很流畅”“用户会感觉更快”“在旧设备上工作良好”。
参考文档（仅在相关时阅读）：references/progressive-rendering.md（界面等待全部数据才显示、可先显示关键内容、需分区加载或刷新时清除内容）；references/loading-states.md（加载、空、错误、重试、刷新、骨架、占位或进度状态）；references/optimistic-updates.md（乐观 UI、待定状态、回滚、重试、冲突处理、本地对账或服务器同步）；references/high-stakes-actions.md（金融、法律、破坏性、不可逆、医疗、身份相关、安全敏感或服务器权威操作）；references/validation-and-testing.md（如何验证感知响应性、旧设备行为、低电量模式信号、发布构建行为、录屏、Instruments 追踪、MetricKit 或生产证据）。
输出期望：审查界面或流程时按 Finding（感知性能问题）、User impact（用户看到或感到什么）、Evidence（代码、状态模型、流程行为、追踪、录屏、指标、用户报告或缺失 UI 状态）、Recommended change（优先最小有用的产品/UI 改动）、Implementation notes（哪些可改代码、哪些依赖产品、设计、后端或运行时证据）、Validation（如何验证改进；无证据不得声称已做手动、设备或生产验证）组织。当瓶颈是缺少反馈、全有或全无渲染、加载不清、不安全乐观行为或连续性差时，优先用户可见改进而非底层优化。