Impeccable 原生端技术审计指南用 audit.native 对 iOS / Android 应用做五维代码级质量检查【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccableImpeccable 是面向 AI 编码助手的界面设计技能体系其中audit命令负责对现有界面做系统化的技术质量审计。当目标应用不是网页而是原生应用iOS / Android / 自适应多平台时审计会自动切到本技能的原生变体 audit.native.md。本篇指南带你完整理解这套原生审计协议它从哪些维度打分、每一项检查点与 0-4 评分刻度、报告应如何组织、P0-P3 严重级别如何标记以及如何把结论映射到后续的修复命令让/impeccable audit真正成为原生应用上线的质量门禁。读完本篇你将掌握在 SwiftUI/UIKit/Compose/React Native/Flutter 等原生代码上独立执行技术审计的完整流程、直接可套用的报告模板以及如何依据审计结论排定修复命令优先级并以/impeccable polish收尾。什么是原生审计代码级质量检查而非设计批评audit.native.md的第一句话就划定了边界Run systematictechnicalquality checks on a native app (ios/android/adaptive) and generate a comprehensive report. Dont fix issues; document them for other commands to address.即只审计、不修复。审计的输出是一份完整报告修复动作留给其他命令adapt、animate、optimize、polish等按报告去执行。这保证了审计结果的客观性和可复核性也让问题可以被逐条跟踪到修复命令上。几点关键定位这是代码级审计不是设计批评。审计对象是源码SwiftUI / UIKit / Compose / React Native / Flutter不依赖浏览器工具也无需运行detect.mjs检测器——它只服务于 Web 端的实现完整性检查。评分基准是平台参考文档。对ios平台对照 ios.md对android平台对照 android.md而adaptive一套代码同时发布到多平台则两个文档都要对照。如果 Setup 阶段没有提前加载应在评分前先读它们。报告骨架与 Web 版保持一致。audit.md 是 Web 界面的审计参考原生版报告的章节结构与它对齐修改其中一份时必须保持两份同步。审计入口由命令路由保证。SKILL.md 的 Commands 表把audit [target]描述为 Technical quality checks (a11y, perf, responsive)并明确标注 native 平台应使用 reference/audit.native.mdaudit.md 同样声明 Web only.Native platforms (ios/android/adaptive) route toaudit.native.mdinstead。从触发方式看该命令在 command-metadata.json 中被描述为 Run technical quality checks across accessibility, performance, theming, responsive design, and anti-patterns. Generates a scored report with P0-P3 severity ratings and actionable plan——这解释了审计报告需要产出的两大交付物维度分数与按严重级别组织的可执行问题清单。平台参考基线HIG 与 Material 3 是打分的尺子原生审计的两把评分尺子分别来自 ios.md 与 android.md。理解它们才能理解 audit.native 中每个维度在查什么。iOS 基线ios.md要点HIG 一致性主导结构、导航与交互在任何模式下都要符合 HIG品牌只表达在平台留出的层次tint、字体、动效、内容里。slop test一个熟练的 iPhone 用户会不会因为这是从网站移植来的而迟疑——例如重造导航栏、自定义返回手势、网页形状的按钮、依赖 hover 的交互。应默认使用平台组件偏离必须有用户会感谢你的理由。结构与导航内容不得压到刘海、灵动岛、home indicator 之下safe-area insets2-5 个顶级分区用 Tab bar左缘 edge-swipe back 手势绝不能禁用或覆盖。触控目标 ≥ 44×44 pt正文 17 pt字号底线 11 pt使用 Dynamic Type 系统文本样式而非硬编码字号。语义化系统色label、secondaryLabel、systemBackground、separator、tint随深色模式与高对比度自动适配深色模式是一等公民系统材质承担毛玻璃效果不用手搓的 glassmorphism。SF Symbols图标不得混入 Web 图标集Sheet 用于可专注的子任务明确的 Cancel/DoneReduce Motion时用 crossfade 替代 parallax 与大滑动。验证截图必须来自 Simulatorxcrun simctl io booted screenshot path深色与大字体内置于检查环节xcrun simctl ui booted appearance dark模拟器给广度、真机给手势/性能证据。Android 基线android.md要点Material Design 3 是规则书品牌通过 Material 的 theming颜色角色、type scale、形状、动效表达。交叉平台应用即使同时发布到 iPhone在该硬件上仍要满足 iOS 的 OS 保证safe-area、Reduce Motion、edge-swipe back。slop test最常见的信号是穿着 Android 皮囊的 iOS 应用——照搬 iPhone 的底部导航、忽略系统 Back 手势的返回箭头、Cupertino 形状的开关与对话框。结构与导航compact 宽度用 Navigation bar3-5 个目的地expanded 宽度用 navigation rail 或 drawer系统 Back 永远可用尊重 predictive Back 手势edge-to-edge 应用 status bar、navigation bar、display cutout、IME insets。触控目标 ≥ 48×48 dp目标之间至少 8 dp字号用sp 而非固定 px跟随系统字体设置语义化 Material 颜色角色primary、on-primary、surface、surface-variant、secondary-container、outline、error。Dynamic ColorMaterial YouAndroid 12 从壁纸派生配色方案但要提供静态 fallback暗色主题是一等方案绝不是快速反相用表面色调层tonal elevation表达层级而非任意投影。组件与动效Material 组件filled/tonal/outlined/text 按钮、FAB、chips、snackbar、bottom sheet、dialog、navigation bar/rail/drawer绝不移植 iOS 控件每屏一个 FAB 一个主操作container transform、shared-axis、fade-through 等 Material 动效尊重系统Remove animations设置。验证截图来自模拟器或真机adb exec-out screencap -p path暗色adb shell cmd uimode night yes与字体缩放adb shell settings put system font_scale 1.3都属于验收范围多设备用-s serial指定。诊断扫描五个维度与检查清单audit.native在五个维度上做全面检查每维度按统一标准打分0-4。下面逐维列出检查点与评分刻度原文可直接当作现场检查单。1. AccessibilityVoiceOver / TalkBack检查项缺失标签交互元素没有无障碍标签、traits/roles 或状态播报阅读与焦点顺序遍历顺序不合逻辑、控件不可达、导航后焦点丢失文本缩放固定字号打败了 iOS Dynamic Type或 Android 用了 px 而非 sp大字下布局被裁剪或互相重叠触控目标低于 44 ptiOS/ 48 dpAndroid或挤在一起没有间距忽略 Reduce Motionparallax 与大滑动没有 crossfade 替代方案对比度浅色或深色外观下文本对比度不达标。评分0Screen reader unusable, 1Major gaps (unlabeled controls, no scaling), 2Partial (labels exist, order or scaling breaks), 3Good (minor gaps), 4Excellent (labeled, ordered, scales cleanly, Reduce Motion honored)。2. Performance检查项启动缓慢首帧前在 launch 阶段做了重活未虚拟化的列表长内容没有 FlatList / LazyColumn / List 回收复用主线程卡顿滚动或手势路径里的同步工作60/120 Hz 掉帧浪费的渲染React Native 不必要的 re-render、Compose 不必要的 recomposition缺少 memoization/keys图片处理为缩略图解码全尺寸图片、没有缓存应用体积臃肿的 JS bundle 或二进制、未使用的依赖。评分0Janky everywhere, 1Major problems (unvirtualized lists, slow launch), 2Partial, 3Good (minor improvements possible), 4Excellent (fast launch, smooth scroll, lean)。3. Appearance Theming检查项硬编码颜色raw hex 而非 iOS 语义系统色 / Android Material 颜色角色 / 设计令牌深色外观破损缺少暗色变体、暗色下对比度差、快速反相式的伪深色Dynamic ColorAndroid 12没有静态 fallback 方案或在适用处被忽略偏离平台的材质系统材质或 tonal elevation 该出现的地方手搓视觉材质。评分0Hard-coded everything, 1Minimal tokens, 2Partial (tokens exist, inconsistently used), 3Good (minor hard-coded values), 4Excellent (semantic throughout, both appearances first-class)。4. Platform Conformance关键维度 CRITICAL对照已加载的平台参考文档含其中的 slop tests打分。检查项系统手势破损iOS 禁用了 edge-swipe back、Android 劫持了 predictive Backinsets 违规内容压到刘海、Dynamic Island、home indicator、状态栏或键盘下面偏离平台的导航自定义全局导航、超载的 tab bar、把 iOS 模式搬到 Android 或反之网页形状的控件HTML 风格按钮、自定义 toggle、依赖 hover 的可用性暗示图标漂移混用图标集而非统一的 SF Symbols / Material Symbols系统漂移与产品、平台或既有设计系统冲突的重复快捷键或装饰模式。评分0Web port (nothing native), 1Heavy violations (3-4 kinds), 2Some (1-2 noticeable), 3Mostly conformant (subtle issues), 4Fully native (a fluent user trusts every screen)。5. Adaptivity检查项手机布局被拉伸平板/iPad 渲染放大后的手机 UI而非使用 size classes / window size classes方向破坏横屏被裁剪、被忽略或无理由锁定方向键盘/IME 处理输入框被键盘遮挡、没有 insets 调整多任务iPad Split View / Android 多窗口破坏布局折叠屏Android 折叠设备姿态变化时布局未感知铰链。评分0One screen size only, 1Major breakage (landscape or tablet broken), 2Partial, 3Good (minor edge cases), 4Excellent (adapts across sizes, orientations, and windowing)。生成报告健康分、Verdict 与执行摘要诊断完成后报告按固定骨架组织。它承接 Web 版 audit.md 的章节结构五维总分同样为20 分制换算为评级区间区间评级含义18-20Excellent只剩细微打磨14-17Good补强薄弱维度10-13Acceptable需要显著工作量6-9Poor需要大改0-5Critical存在根本性问题Audit Health Score 表格报告以表格呈现五维得分、关键发现与总分#DimensionScoreKey Finding1Accessibility?[most critical issue or --]2Performance?3Appearance Theming?4Platform Conformance?5Adaptivity?Total??/20[Rating band]Platform Conformance Verdict从这里开始写报告的第一个实质章节是通过/失败裁决这读起来是原生应用还是被移植的网站要列出具体违规并be brutally honest绝对诚实。这是全报告最关键的定性判断直接决定了后续维度分数的解读方向。Executive SummaryAudit Health Score??/20评级区间问题总数按 P0/P1/P2/P3 计数Top 3-5 关键问题建议的下一步动作Detailed Findings by SeverityP0-P3每个问题标记P0-P3 严重级别P0 Blocking阻碍任务完成。立即修复P1 Major造成显著困难或违反平台指南。发布前修复P2 Minor恼人但存在变通方案。下一轮修复P3 Polish值得修但无实际用户影响。有时间再修。对每个问题记录 7 个字段[P?] 问题名LocationScreen、file、lineCategoryAccessibility / Performance / Theming / Conformance / AdaptivityImpact对用户的影响Guideline违反的 HIG / Material 规则如适用Recommendation修复方法Suggested command建议执行的命令值得注意Web 版 audit.md 中 P0 的定义是 Prevents task completion、P1 是 WCAG AA violation而原生版把 P1 细化为 Significant difficultyor platform-guideline violation——平台指南HIG / Material违规被显式提升为 P1呼应了原生审计代码级检查平台符合度的核心立场。Patterns Systemic Issues 与 Positive Findings模式与系统性问题识别反复出现的、暗示系统性缺口而非偶发错误的规律例如 Hard-coded colors appear in 15 screens, should use semantic colors、 Touch targets consistently below 44 pt throughout the tab bar and list rows。正面发现记录做得好、应当保持并复制的实践——报告不能只报问题。收尾引导语报告结尾必须向用户展示两句话说明修复与复验方式You can ask me to run these one at a time, all at once, or in any order you prefer.Re-run/impeccable auditafter fixes to see your score improve.可逐条执行、可一次性执行、也可按任意顺序执行修复完成后重跑/impeccable audit观察分数提升。推荐行动把问题映射到修复命令报告的最后一部分是按优先级排序P0 → P1 → P2的命令推荐清单[P?]/command-name简短描述结合审计发现的具体上下文[P?]/command-name简短描述结合具体上下文命令白名单规则只能从以下集合中推荐——/impeccable adapt、animate、audit、bolder、clarify、colorize、critique、delight、distill、document、harden、layout、onboard、optimize、overdrive、polish、quieter、shape、typeset。把发现映射到最合适的命令若推荐了任何修复动作最后一步必须是/impeccable polish——这与 SKILL.md 中polish作为 Final quality pass before shipping 的定位一致也与原生参考 adapt.native.md 等修复类命令形成审计-修复-收尾的闭环。常见映射参考触控目标过小、布局在平板/横屏破损 →/impeccable adapt处理不同设备与屏幕尺寸硬编码颜色、缺少语义令牌 →/impeccable colorize或/impeccable extract从代码中抽取设计令牌深色外观破损、系统材质缺失 → 属 theming 修复可经由/impeccable colorize后复验启动缓慢、列表未虚拟化、掉帧 →/impeccable optimize诊断并修复 UI 性能动效喧宾夺主、忽略 Reduce Motion →/impeccable animate补充有目的性的动效并做降级转场不自然、动效层级乱 →/impeccable quieter或/impeccable animate交互文案不清、状态播报缺失的配套说明 →/impeccable clarify收尾打磨 →/impeccable polish执行纪律与注意事项原文档最后给出四条纪律它们决定了报告质量Be thorough but actionable太少的 P3 噪音反而更好聚焦真正重要的问题NEVER只报问题不解释影响Why does this matter?给出泛泛的通用建议要具体、可执行跳过正面发现做得好的要庆祝并保持忘记优先级不可能所有问题都是 P0未经验证就报假阳性。这与 Impeccable 技能层的总体原则验证采用有界轮次而非无限循环、用一次批量检查找出所有问题并集中修复一脉相承审计要一次找全、明确分级、给出可执行的下一步而不是无限自我问答。在仓库中的定位与进一步阅读本审计参考的原生镜像同时存在于各编辑器 skill 目录与插件/发布目录内容一致如 skill/reference/audit.native.md、plugin/skills/impeccable/reference/audit.native.md。修改报告骨架时需与 audit.md 保持同步。命令的注册、描述与参数提示见 command-metadata.json其中audit的 argumentHint 为[area (feature, page, component...)]说明审计可以限定到某个 feature、页面或组件而非只能全量扫描。若想进一步了解与审计配套的修复与迭代流程可继续阅读同目录的 adapt.native.md跨设备/平台适配、optimize.md性能修复与 polish.md上架前收尾以及总览 SKILL.md 的命令表与路由规则。把audit应用到原生仓库的推荐节奏是先读平台参考ios / android / adaptive按五维清单扫描源码并打分用 P0-P3 组织可执行的发现最后以平台符合度裁决和命令优先级清单收尾——让这是原生应用还是网页移植这个问题在代码层面得到可量化、可复核、可跟踪修复的答案。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考