ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

Impeccable Critique 实战指南:用双评估(设计评审 + 检测器证据)量化你的 UI 设计质量

Impeccable Critique 实战指南:用双评估(设计评审 + 检测器证据)量化你的 UI 设计质量 Impeccable Critique 实战指南用双评估设计评审 检测器证据量化你的 UI 设计质量【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable导读/impeccable critique是 Impeccable 设计语言工具链中的设计评审命令。它把一个目标界面页面、组件或文件交给两个相互隔离的评估LLM 设计评审 确定性检测器扫描再综合成一份带 10 条 Nielsen 启发式评分、认知负荷检查、Persona 测试和 P0–P3 问题分级的结构化评审报告并持久化为快照、输出趋势线、以针对性问题收尾。读完本文你将掌握 critique 的完整执行协议、退化degraded判定规则、评分与再归一化方法、快照与趋势的底层机制以及如何把评审结果衔接到后续修复命令。1. critique 在整个 Impeccable 工作流中的定位在 Impeccable 的命令体系中critique 是评价与诊断环节处于塑造shape→ 构建craft→ 打磨polish的中间位置。它不直接改代码而是产出可被后续命令消费的结构化证据它把用户的语言化请求这个首页感觉不对帮我看看这个设置弹窗翻译成一次可重复、可追溯的设计体检它持久化的快照是/impeccable polish的输入之一polish 可以无复制粘贴地拾取优先问题见下文 Persist the Snapshot 一节命令元数据中是这样描述它的crates/context/src/command-metadata.jsonEvaluate design from a UX perspective, assessing visual hierarchy, information architecture, emotional resonance, cognitive load, and overall quality with quantitative scoring, persona-based testing, automated anti-pattern detection, and actionable feedback. Use when the user asks to review, critique, evaluate, or give feedback on a design or component.也就是说当用户说review / critique / evaluate / give feedback时就应触发本命令参数提示为[area (feature, page, component...)]。critique 一次完整运行的交付物有两件聊天响应中的完整报告主交付物.impeccable/critique/下的快照归档运行存档。命令明确定义如果报告只存在于.impeccable/critique/那么这次运行什么都没产出。2. 两条硬性不变量Hard Invariants任何一次 critique 运行都必须满足以下规则违反即视为失败运行双评估强制Assessment A设计评审与 Assessment B检测器/浏览器证据都不可少。隔离子代理只要会话暴露了 sub-agent/Task 工具A 和 B必须作为两个隔离的子代理并行运行互不可见对方输出内联运行被明令禁止Running them inline in this context is possible but is NOT permitted。仅在没有任何子代理工具可用或在会询问的平台上用户明确拒绝时才允许退化为内联顺序执行。退化必须声明任何原因导致退化报告第一行必须是横幅⚠️ DEGRADED: single-context (reason)。静默退化的 critique 就是失败的 critique。A 先于 B 的结论进入综合上下文检测器输出虽然是确定性的但它会锚定判断所以设计评审必须在看到检测结果之前完成。跳过检测器即失败除非impeccable detect缺失或真实尝试后崩溃否则跳过检测器 失败运行。可见目标需要浏览器检查当浏览器自动化可用时可视目标必须走浏览器可视化路径。本地服务器生命周期仅为可视化而启动的本地服务器必须后台运行、记录停止方式并在最终报告前停止除非用户要求保留。不要虚构 overlay除非脚本注入成功且检测器真的在页面里运行过否则不得声称存在用户可见的 overlay。问题必须是响应的最后内容先写完整个报告再提问问题之后不能再有散文结构化问题之后的散文会被挂起直到用户回答导致报告读起来像从未运行过。以收尾为结束如果一次运行既没有目标问题也没有字面的Questions skipped: reason行就是不完整的运行。报告不是结束收尾才是。这些不变量在源码层也有呼应——例如 crates/context/src/critique_storage.rs 中latest子命令对关闭closed快照返回退出码 2、close子命令对所有权不匹配的关闭请求返回退出码 2都是为了让过期/不匹配的运行状态显式可见而不是静默吞掉。3. Setup解析目标、确认 slug、读取 ignore 列表3.1 解析目标Resolve the target把用户的模糊指代解析成具体的文件路径或 URL。规则是当同一表面既可以用源路径又可以用 dev-server URL 表示时优先源路径——ports drift, paths do not端口会漂移路径不会。用户说法解析结果the homepagesite/pages/index.astro或index.htmlthe settings modal主要的组件文件this page当前 URL 或源文件3.2 确认 slug 干净slug 校验.kiro/skills/impeccable/scripts/impeccable critique-storage slug resolved-path-or-url后续所有命令也接受直接传入解析后的目标内部推导相同 slug永远不要手写 slug。如果该命令非零退出无稳定 slug则跳过本次的持久化与趋势但 critique 主体照常继续。slug 的生成机制在 crates/context/src/target_slug.rs 中实现对应 JS 的lib/target-slug.mjsURL 目标取host pathname转为 kebab-case本地路径相对 cwd 解析后转 kebab。超过SLUG_MAX长度时采用截尾 SHA-256 哈希后缀既保持可读性又保证区分度——这正是文档中永远不要手写 slug的原因slug 是确定性推导的手写必然漂移。3.3 读取 ignore 列表如果.impeccable/critique/ignore.md存在读取它并静默丢弃匹配的发现。这是 critique 消费的唯一先前运行输入prior-run input。4. 评估编排双子代理的隔离与门控┌─────────────────────────────┐ │ Assessment A: Design Review │ Assessment B: Detector Browser │ │ (设计总监视角先于B完成) │ (impeccable detect --json 浏览器) │ └──────────────┬──────────────┘ └────────────────┬─────────────────┘ │ 相互隔离看不到对方输出 │ └──────────────┬─────────────────────┘ ▼ Generate Combined Critique Report综合报告 ▼ Deliver the Report → Persist Snapshot → Trend → Ask the User子代理门控适用于所有 harness默认且强制只要暴露了 sub-agent/Task 工具就 spawn A、B 两个隔离的并行子代理。不要因为内联更快就在本上下文里跑。Unavailable只有一种含义本会话没有暴露任何子代理/Task 工具或在会询问的平台上用户拒绝了。它不是不方便的意思。仅当子代理不可用时才顺序退化先完成并记录 A再跑 B然后综合并输出退化横幅。无论走哪条路径都必须在报告头声明见 Report header provenance。不声明横幅就跳过子代理是这个命令最常见的失败方式。浏览器自动化可用时每个评估各自开一个新 tab绝不复用现有 tab即使它已经在正确的 URL 上。5. Assessment A设计评审5.1 评估维度阅读相关源文件浏览器自动化可用时目检实时页面。以设计总监design director的思维方式评估设计特异性Design specificity构图、交互、视觉语言是否扎根于本产品换一个无关产品能否原样使用必须在看到检测器输出之前做出这个判断。整体设计层级hierarchy、信息架构IA、情感契合、可发现性、构图、排版、色彩、可访问性、状态、文案、边缘情况。认知负荷对照文档附录的 Cognitive Load Assessment8 项检查清单 工作记忆规则报告清单失败项与决策点出现 4 个可见选项的情况。情感旅程峰终定律peak-end rule、情感低谷、高风险时刻的安抚。Nielsen 启发式对照 Heuristics Scoring Guide对全部 10 条 0–4 打分被模式适用性规则允许的启发式可标n/a而非强行给分。返回设计特异性结论、启发式分数、认知负荷、情感旅程、2–3 个优点、3–5 个优先问题、persona 红旗、次要观察、挑衅性问题。6. Assessment B检测器 浏览器证据6.1 CLI 扫描.kiro/skills/impeccable/scripts/impeccable detect --json [target]规则传入 markup 文件/目录作为[target]不要传纯 CSS 文件URL 目标跳过 CLI 扫描直接用浏览器可视化超大目录树500 可扫描文件要缩小范围或询问用户退出码0 干净2 有发现crates/detect/src/cli.rs退出码 2 表示存在 primary findings若有操作级失败则退出码 1 优先因为部分扫描的发现不能把不完整扫描变成完整扫描若检测器入口缺失或加载失败报告确定性扫描不可用并继续浏览器/人工评审。6.2 浏览器可视化overlay 流程可视目标且浏览器自动化可用时浏览器可视化是必做的。本地文件用 localhost dev/static URL除非浏览器明确支持file://工作流否则避免使用file://。流程新建 tab 并导航。优先使用 harness 自带的浏览器截图路径不要手写 Playwright/Puppeteer 脚本仅当没有暴露任何原生浏览器工具时才回退到自定义脚本。预检可变注入mutable injection通过设置document.title并追加script标签验证注入能力。只读的 evaluate API 不算数。若可变性不可用跳过 live server、浏览器呈现与注入报告 fallback 信号。若可变性可用执行.kiro/skills/impeccable/scripts/impeccable live-server --background然后呈现浏览器若支持、标记为[Human]、滚到顶部、注入http://localhost:PORT/detect.js、等待 2–3 秒、读取impeccableconsole 消息、最后停止 live server。多视图目标在 3–5 个代表性页面上注入。源码佐证/detect.js正是 live server 暴露的检测 overlay 路由crates/live/src/live_server.rs 中声明/detect.js Detection overlay (backwards compatible)并在--background模式下start detached, print connection JSON to stdout, then exit。浏览器端扫描完成后会向控制台输出带样式的消息例如[impeccable] No anti-patterns found.或按类型输出发现项browser-bundle/50-scan.js这正是文档要求读取 impeccable console 消息的原因。注入脚本由 crates/live/src/browser_assets.rs 托管确保引擎二进制与其安装的技能永远一致。6.3 返回内容CLI 发现 JSON/计数、浏览器 console 发现如适用、误报、以及跳过/失败的浏览器步骤及具体原因。复用规则当 Assessment B 返回可用的 CLI 发现后直接复用它们——不要在父上下文中重跑impeccable detect除非 B 失败、被截断或遗漏了计数/规则名/文件位置。7. 生成综合批评报告Generate Combined Critique Report把两个评估织合成一份报告而不是简单拼接Do NOT simply concatenate指出 LLM 评审与检测器在哪些点上一致、检测器抓到了哪些 LLM 漏掉的问题、哪些检测器发现是误报。聊天响应是主交付物必须在聊天中完整呈现结构化报告不能用摘要 链接替代。快照只是那次运行的归档。7.1 报告头来源声明Report header provenance报告第一行必须声明评估方式让退化运行永不沉默双代理Method: dual-agent (A: agent-id · B: agent-id)退化⚠️ DEGRADED: single-context (reason, e.g. no sub-agent tool exposed)7.2 设计健康分数Design Health Score以表格呈现 10 条 Nielsen 启发式得分#HeuristicScoreKey Issue1Visibility of System Status?[具体发现或n/a若该项扎实]2Match System / Real World?3User Control and Freedom?4Consistency and Standards?5Error Prevention?6Recognition Rather Than Recall?7Flexibility and Efficiency?8Aesthetic and Minimalist Design?9Error Recovery?10Help and Documentation?Total??/[applicable max][Rating band]要点可应用最大值 4 × 实际打分的启发式条数全部适用是/40两条n/a是/32。永远不要在部分集合上打印/40。诚实打分4 分意味着真正卓越。多数真实界面在 20–32/40 之间。模式适用性Mode applicability在 Persuade 与 Experience 类界面落地页、campaign、作品集、bodies of work上启发式 7Flexibility and Efficiency与 10Help and Documentation可以标n/a任何确实不适用于被评审表面的启发式都可标n/a。在 Score 单元格写n/a并附一行理由然后将总分按可应用最大值重归一化例如两条 n/a 时写24/32保持评级带成比例。持久化快照必须记录可应用最大值与哪些启发式被标了 n/a。评分等级表Score Summary与逐条启发式的 0–4 判据含 Check for 清单与评分标准表完整收录在文档附录中是打分的直接依据当有 n/a 时按百分比读带90% Excellent70% Good50% Acceptable30% Poor以下 Critical。7.3 设计特异性结论Design Specificity Verdict从这里开始。这个结果是为本产品撰写的还是品类可互换category-interchangeable的LLM 评估你未锚定的设计特异性评估。覆盖整体一致性、结构雷同、品类可互换的选择、以及错失的产品性格机会。确定性扫描概括自动化检测器发现给出计数与文件位置。指出检测器抓到你漏掉的问题并标记误报。可视化 overlay若注入成功告知用户 overlay 已显示在浏览器[Human]tab 中高亮检测到的问题概括 console 输出内容。若尝试了浏览器可视化但注入失败明确说明没有可靠的用户可见 overlay并报告 fallback 信号。7.4 其余报告章节Overall Impression简短直觉反应——什么有效、什么无效、最大的单一机会。Whats Working2–3 件做得好并具体说明为什么好。Priority Issues按重要性排序的 3–5 个最具影响的设计问题每条按下面模板标注P0–P3严重度定义见附录 Issue Severity- [P?] What清晰命名问题 - Why it matters如何伤害用户或破坏目标 - Fix具体怎么做要可操作 - Suggested command用哪个命令解决Persona Red Flags按附录 Persona-Based Design Testing 从 5 个预定义 archetypeAlex / Jordan / Sam / Riley / Casey中自动挑选与该界面类型最相关的 2–3 个用附录的选择表若.kiro/settings.json含impeccable init生成的## Design Context段再按模板生成 1–2 个项目专属 persona。逐个 persona 走一遍主用户操作列出具体红旗——Dont write generic persona descriptions; write what broke for them.示例见文档Alex 无快捷键、主操作需 8 次点击、强制弹窗 onboardingJordan 侧边栏纯图标导航、错误消息技术黑话、无可见帮助。Minor Observations值得处理的较小问题速记。Questions to Consider可能解锁更好方案的挑衅性问题如 What if the primary action were more prominent?。报告写作纪律文档原话直接、具体说 The submit button 而非 some elements、说清哪里错 为什么对用户重要、给出具体建议删掉 consider exploring...、无情排序如果一切都重要那就什么都不重要、不要软化批评。8. 交付报告Deliver the Report与持久化Persist the Snapshot8.1 先交付后归档在聊天响应中先写出完整报告——这是交付物其下全是簿记。原因最常见的失败方式是报告被直接写进持久化 heredoc运行结束归档完美但没人读过。报告只存在于.impeccable/critique/意味着这次运行什么都没产出。持久化不是运行终点之后还要输出趋势行与收尾。8.2 写快照报告定稿后写入.impeccable/critique/供用户回看也让/impeccable polish无需复制粘贴即可拾取优先问题。若 Setup 阶段的 slug 为 null模糊或根级目标跳过本步。把正文写入临时文件再管道给 helper。内容用完整报告启发式表格、设计特异性结论、优先问题、persona 红旗、次要观察、问题但截到后面的 Ask the User / Recommended Actions 之前。这只是已交付报告的副本供后续命令读取不是交付。通过IMPECCABLE_CRITIQUE_METAJSON传入结构化元数据然后运行写命令IMPECCABLE_CRITIQUE_META{target:user phrasing,total_score:n,max_score:n,na_heuristics:comma-separated numbers, or empty,p0_count:n,p1_count:n} \ .kiro/skills/impeccable/scripts/impeccable critique-storage write resolved target body-filemax_score是启发式表格的可应用最大值全适用时为 40这样后续运行能区分重归一化的总分与满额总分。对本地文件目标helper 还会记录精确内容指纹使 polish 无需依赖 Git 状态或时间戳即可区分被评估的字节与后来的编辑。helper 打印写入的绝对路径该文件保留在磁盘上——polish 会关闭它本次运行不会。删除临时正文文件无论写入成功失败。若删除失败在最终输出中简短提及temp-file cleanup failed: reason但不阻塞 critique。读取趋势.kiro/skills/impeccable/scripts/impeccable critique-storage trend resolved target 5返回最近 5 条 frontmatter 条目的 JSON 数组含刚写入的这条。在用户可见输出中追加一行报告之后、问题之前Trend forslug(last 5 runs): 24 → 28 → 32 → 29 → 32 (out of 40)Wrote.impeccable/critique/filename.读取每条趋势项的max_score所有条目共享同一最大值时如上写一次不同时逐个带分母打印24/32 → 30/40并注明各次打分集合不同、不能直接对比。旧条目缺max_score视为 40。首次运行时趋势只有一个分数写First run for this target, no trend yet.关闭运行去 Ask the User 发出问题或计数允许时发出Questions skipped: reason行。不做这一步就不算完整——持久化是簿记清理不是结尾停在这里会让用户拿到报告却没有前进方向让/impeccable polish没有可继承的优先级。这是 fire-and-forget不要向用户展示 helper 的 JSON 输出只展示人类可读的趋势行与写入路径。这里的失败不应阻塞其余流程打印错误并继续。8.3 快照的底层机制源码佐证快照持久化由 crates/context/src/critique_storage.rs 实现对应 JS 的critique-storage.mjs经 crates/context/src/lib.rs 导出、crates/cli/src/main.rs 路由到impeccable critique-storage目录get_critique_dir将.impeccable/critique拼在项目根resolve_project_root下文件名now_filename_stamp把 ISO 时间戳中的:与.替换为-形如2026-05-12T18-30-00Zwrite用create_new独占创建并支持~0001四位碰撞后缀确保同一 UTC 秒内的第二次 critique 不会覆盖历史目标身份target identityresolve_target_identity对文件目标生成file:resolved path对 URL 目标生成url:originpathnameURL 还要去掉尾部斜杠归一化这是快照归属与close权限校验的依据内容指纹fingerprint_target对本地文件目标计算sha256:前缀的字节摘要frontmatter 序列化serialize_frontmatter/parse_frontmatter支持字符串、布尔如closed: true、整数、数组/对象字符串含:或#时自动加 JSON 引号close 语义close_snapshot在第一个 frontmatter 块结尾注入closed: truelatest对已关闭或指纹不匹配的快照返回退出码 2stale语义polish 借此知道当前磁盘内容已不同于被评审版本trendtrend子命令按 slug 列出快照、排序、取末尾 N 条并解析 frontmatter 输出 JSON。测试在文件末尾的mod tests_660中覆盖了碰撞后缀命名、URL 尾部斜杠归一化、close 的拥有权校验错误目标拒绝关闭、正确目标标记 closed、二次 close 静默 no-op、latest --json输出结构、以及pre-hash 长目标回退到旧 slug 需匹配 target_identity等场景。9. Ask the User针对性收尾问题呈现发现之后基于实际发现提出针对性问题直接询问无法推断的部分。答案将塑造行动计划。问题必须与报告同一条消息发出——先完整报告、问题放最后。不要把两者拆到两个回合以报告结尾的回合就是结束的回合问题永远不会到达。消息内顺序是关键结构化问题之后的散文会被挂起直到用户回答。按这些方向提问按具体发现适配不要问通用问题优先级方向基于发现的问题问哪类现在对用户最重要给出 2–3 个问题类别作为选项。例如我发现了视觉层级、色彩使用和信息过载的问题。我们应该先处理哪个设计意图若发现语气不匹配问是否有意为之。给出 2–3 个能修复问题的语气方向作为选项。例如这个界面感觉偏临床、企业化。这是预期的语气还是应该更温暖/大胆/有趣范围问用户想承担多少。例如我发现了 N 个问题。全部处理还是聚焦前 3给出 Top 3 only / All issues / Critical issues only 等选项。约束可选仅当相关若发现触及多个区域问是否有禁区。例如是否有任何部分要保持原样问题规则每个问题必须引用报告中的具体发现绝不要问通用的你的受众是谁控制在 2–4 个问题尊重用户时间提供具体选项不要开放式提示仅当报告列出的Priority Issues 少于 3 条时才允许跳过数一数不要凭感觉判断发现很直接。达到 3 条及以上时问题为强制。最终问题门控Final-question gate用户可见响应必须包含针对性问题或携带字面行Questions skipped: reason写明允许跳过的计数。每个问题必须附带 2–3 个与实际发现挂钩的具体答案选项。不要只以开放式问题结束也不要两者皆无——报告之后什么也不问也不打印跳过行是这个命令最常见的失败方式。10. Recommended Actions把评审衔接到修复收到用户回答后按用户的优先级与范围呈现一份有序的行动总结。10.1 行动总结Action Summary按优先级列出推荐命令基于用户回答/command-name要修复什么的简短描述带 critique 发现的具体上下文/command-name简短描述具体上下文 ...推荐规则只推荐白名单命令/impeccable adapt、animate、audit、bolder、clarify、colorize、critique、delight、distill、document、harden、layout、onboard、optimize、overdrive、polish、quieter、shape、typeset排序先按用户声明的优先级再按影响每条描述携带足够上下文让命令知道聚焦什么把每条 Priority Issue 映射到合适命令跳过零问题的命令用户选了有限范围就只列范围内条目用户标记禁区就排除会触碰那些区域的命令若推荐了任何修复以/impeccable polish作为最后一步收尾。呈现总结后告诉用户You can ask me to run these one at a time, all at once, or in any order you prefer.Re-run/impeccable critiqueafter fixes to see your score improve.这正是快照 指纹机制的价值闭环修复后重跑 critique新快照入档、趋势线更新分数变化成为可见证据。11. 附录内联参考材料以下部分原来是独立参考文件cognitive-load.md、heuristics-scoring.md、personas.md现已内联让 critique 流程的所有深度上下文集中在一处。11.1 Cognitive Load Assessment认知负荷是使用界面的总心智努力。超载用户会犯错、受挫、离开。认知负荷分三种内在负荷Intrinsic Load——任务本身任务固有的复杂度无法消除但可以结构化。管理手段拆解为离散步骤、提供脚手架模板/默认值/示例、渐进披露现在只显示所需隐藏其余、把相关决策分组。无关负荷Extraneous Load——糟糕的设计设计不佳造成的心智浪费要无情消除。常见来源需要心智映射的混乱导航、让人猜含义的模糊标签、争夺注意力的视觉杂乱、阻碍学习的模式不一致、意图到结果之间多余的步骤。相关负荷Germane Load——学习努力建立理解的心智投入是好的认知负荷。支持手段渐进披露、回报学习的一致模式、确认正确理解的反馈、用行动而非文本墙教学的新手引导。认知负荷检查清单逐项评估单一焦点用户能否不受竞争元素干扰完成主任务分块Chunking信息是否以可消化组呈现每组 ≤4 项分组Grouping相关项是否视觉上归组邻近、边框、共享背景视觉层级屏幕上什么最重要是否一目了然一次一件事用户能否在进入下一决策前专注单个决策最少选择任何决策点是否简化到 ≤4 个可见选项工作记忆用户是否必须记住前一屏的信息才能在当前屏操作渐进披露复杂度是否只在需要时揭示计分数失败项。0–1 失败 低负荷好2–3 中等尽快处理4 高负荷必须修复。工作记忆规则人类一次能同时持有≤4 项工作记忆Millers Law 经 Cowan 2001 修订。决策点数一数用户必须同时考虑的不同选项/动作/信息≤4 项可控5–7 项接近边界考虑分组或渐进披露8 项超载用户会跳过、误点或放弃。实操操作按钮 1 主 1–2 次、其余收进菜单导航菜单 ≤5 个顶层项长文单一阅读路径、相关链接收进文末一个区块文档侧边栏每级 ≤4 个兄弟选项作品集/图库索引每屏一个决策打开哪件不要同时给筛选、排序、标签控件。常见违规 8 例问题 修复选项墙The Wall of Options10 个无层级选择 → 分组、高亮推荐、渐进披露。记忆桥The Memory Bridge必须记住步骤 1 的信息才能完成步骤 3 → 保持相关上下文可见或在需要处重复。隐藏导航The Hidden Navigation用户必须构建位置心智地图 → 始终显示当前位置面包屑、激活态、进度指示。术语壁垒The Jargon Barrier技术/领域语言迫使翻译努力 → 用平实语言无法避免则就地定义。视觉噪音地板The Visual Noise Floor所有元素视觉权重相同 → 建立清晰层级1 个主元素、2–3 个次级、其余弱化。不一致模式The Inconsistent Pattern相似动作在不同位置行为不同 → 标准化交互模式同类动作 同类 UI。多任务需求The Multi-Task Demand界面要求同时处理多路输入读 决策 导航→ 排序步骤一次一件事。上下文切换The Context Switch为单个决策不得不在屏/tab/弹窗间跳转 → 把决策所需信息放一起减少来回。11.2 Heuristics Scoring Guide0–4 打分诚实为上4 意味着真正卓越不是够用。每条启发式的完整 Check for 清单与 0–4 判据表见文档原文含 Visibility of System Status、Match Between System and Real World、User Control and Freedom、Consistency and Standards、Error Prevention、Recognition Rather Than Recall、Flexibility and Efficiency of Use、Aesthetic and Minimalist Design、Help Users Recognize/Diagnose/Recover from Errors、Help and Documentation 共 10 条每条均有 4 分档位说明例如 0No feedback; user is guessing what happened、4Excellent; every action confirms, progress is always visible。分数汇总Score Summary满分 4010 × 4。Score RangeRatingWhat It Means36–40Excellent仅需微抛光可以发布28–35Good处理薄弱点基础扎实20–27Acceptable用户满意前需要显著改进12–19Poor需要重大 UX 重构核心体验损坏0–11Critical需要重设计当前状态不可用存在 n/a 时最大值低于 40按百分比读带90% Excellent、70% Good、50% Acceptable、30% Poor、以下 Critical24/32 75%即 Good。问题严重度Issue Severity P0–P3PriorityNameDescriptionActionP0Blocking完全阻止任务完成立即修复showstopperP1Major造成显著困难或困惑发布前修复P2Minor烦人但有变通办法下一轮修复P3Polish锦上添花无真实用户影响有时间就修Tip拿不准两级之间时问用户会为这个联系客服吗会则至少 P1。11.3 Persona-Based Design Testing用 5 个不同用户原型archetype的眼睛测试界面每个 persona 暴露单一设计总监视角会漏掉的不同失败模式。用法选与所评审界面最相关的 2–3 个以每个 persona 身份走主用户操作报告具体红旗而非泛泛担忧。不耐烦的专家用户 Alex同类产品专家期待效率、讨厌手把手找不到快捷键就走人。红旗强制教程/不可跳过的 onboarding、主操作无键盘导航、无法跳过的慢动画、本该批量却一次一个的工作流、低风险动作的冗余确认。测试问题60 秒内能否完成核心任务常用操作有快捷键吗onboarding 能整体跳过吗弹窗能 Esc 关闭吗困惑的新手 Jordan从没用过这类产品每一步都需要指引宁肯放弃也不自己搞懂。红旗无标签的纯图标导航、无解释的技术黑话、无可见帮助选项、操作完成后下一步含糊、无动作成功确认。测试问题5 秒内首个动作是否显然所有图标都带文字标签吗决策点有情境帮助吗依赖无障碍的用户 Sam使用屏幕阅读器VoiceOver/NVDA、纯键盘导航可能低视力、运动障碍或认知差异。红旗无键盘替代的纯点击交互、缺失或不可见的焦点指示、仅靠颜色传达含义红错绿对、无标签表单字段/按钮、无延长选项的限时动作、破坏屏幕阅读器流程的自定义组件。测试问题能否纯键盘完成整个主流程对比度满足 WCAG AA正文 4.5:1吗屏幕阅读器会播报状态变化吗刻意的压力测试者 Riley有条不紊地把界面推过快乐路径专门测试边缘情况。红旗看起来能用但静默失败或产出错误结果的功能、暴露技术细节或让 UI 进入损坏状态的错误处理、无指导的空状态No results无下文、刷新/导航丢失用户数据的工作流、界面不同部分对相似交互行为不一致。测试问题0 项/1000 项/超长文本时发生什么流程中刷新状态保留吗emoji/特殊字符/Excel 粘贴等意外输入怎么处理分心的移动用户 Casey单手手机、经常被打断、可能慢网速。红旗主操作放在拇指够不到的屏幕顶部、无状态持久化切 tab 或被打断即丢进度、本可用选择却要求大段文本输入、每页重载重资产无懒加载、过小或过近的点击目标。测试问题主操作在拇指区屏下半吗离开再回来状态保留吗触达目标 ≥44×44pt 吗选择 Personas按界面类型Interface TypePrimary PersonasWhyLanding page / marketingJordan, Riley, Casey第一印象、信任、移动端Dashboard / adminAlex, Sam专家用户、无障碍E-commerce / checkoutCasey, Riley, Jordan移动端、边缘情况、清晰度Onboarding flowJordan, Casey困惑、打断Data-heavy / analyticsAlex, Sam效率、键盘导航Form-heavy / wizardJordan, Sam, Casey清晰度、无障碍、移动端项目专属 Personas若.kiro/settings.json含impeccable init生成的## Design Context段从中再推导 1–2 个 persona读受众描述 → 找出 5 个预定义 persona 未覆盖的主用户原型 → 按模板##### [Role]: [Name] Profile/Behaviors/Red Flags创建。只有存在真实 Design Context 数据时才生成项目专属 persona不要发明受众细节无上下文时用 5 个预定义 persona。12. 快速参考一次 critique 的关键命令清单步骤命令说明校验 slugimpeccable critique-storage slug target非零退出则跳过持久化/趋势CLI 检测impeccable detect --json [target]仅 markup 文件/目录退出码 0 干净 / 2 有发现浏览器可视化impeccable live-server --background 注入http://localhost:PORT/detect.js目标 URL 或可视化场景必做结束后停止服务器写入快照IMPECCABLE_CRITIQUE_META{...} impeccable critique-storage write target body-file自动记录 target_identity、内容指纹、时间戳、slug读取趋势impeccable critique-storage trend target 5最近 5 次 frontmatter JSON注意 max_score 是否一致所有命令均可直接传入解析后的目标路径/URL内部推导相同 slug无需手写 slug。完整协议、打分表与 persona 模板见.kiro/skills/impeccable/reference/critique.md底层实现可继续阅读 crates/context/src/critique_storage.rs、crates/context/src/target_slug.rs 与 crates/detect/src/cli.rs。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表