Impeccable 这个项目到底解决了哪些前端设计问题，它的解决路径是什么？

核心分析\n\n项目定位：Impeccable 的核心目标是把前端设计专业知识（排版、色彩、间距、动效、交互、响应式、文案）以机器可消费的知识层封装成一个可分发的 skill 套件，供不同 LLM harness 通过命令调用，从而减少由通用模板带来的重复视觉模式与可访问性问题。\n\n### 技术特点\n\n- 结构化知识库：7 个领域参考文件把设计原则拆成可引用的子域，便于针对项目定制替换。\n- 命令化接口：17 个明确的命令（如 /audit、/polish、/distill）支持聚焦子区域的参数化调用，便于把设计检查/修复纳入 CI 或 PR 流程。\n- 反模式集合：显式列出“不要做”的示例（例如避免 Inter、灰色文字在有色背景），作为负面提示以抑制 LLM 的常见偏差。\n\n### 使用建议\n\n1. 一键采集上下文：首先运行 \/teach-impeccable` 将项目上下文保存到配置，避免命令泛化。\n2. 将 /audit 纳入 PR：在代码评审阶段自动运行审计，把可执行问题转成任务（accessibility/fix CSS）。\n3. 按需定制参考文件：把默认参考文件作为模板，针对自家设计系统重写 typography 与 color-and-contrast。\n\n### 注意事项\n\n- 不是组件库：Impeccable 输出建议或草稿组件，不是开箱即用的生产组件代码。\n- 依赖 LLM 能力与配置：在弱模型或缺少上下文时，建议需要人工验证，特别是可访问性与实际交互测试。\n\n> 重要提示：在引入到自动化流程前，先在样例页面做闭环验证（视觉比对、键盘导航、色彩对比）。\n\n总结：Impeccable 提供了一个可移植的“设计知识层”与命令驱动工作流，能显著降低 LLM 在 UI 产出中的常见错误，但需项目级定制与人工验证以确保可用性与一致性。¶

87.0%

为什么采用“skill + command + domain references + anti-patterns”的架构比仅靠设计文档或组件库更有优势？

核心分析\n\n项目定位对比：与传统的设计文档和组件库不同，Impeccable 的架构是把设计知识转换为机器可执行的形式：领域参考作为知识存储、命令作为行为接口、反模式作为负面提示。这一层面是设计文档与组件库之间的桥梁，专注于把“规则”传递给 LLM 而非直接产出运行时组件。\n\n### 技术分析\n\n- 可执行性高：命令（如 /audit、/polish）为 LLM 提供明确任务边界，降低理解歧义。\n- 正/负提示并存：正向参考文件给出应做的方向，反向反模式明确指出要避免的事项，二者结合比单纯说明更能约束 LLM 行为。\n- 跨 agent 可复用：知识层与 agent 解耦，提供 dist 包可在 Cursor、Claude、Gemini、Codex 等多种 harness 重用。\n\n### 实用建议\n\n1. 把 Impeccable 当作规则引擎：在自动化审计、生成草稿、提取组件片段时调用命令，而不是把其作为最终组件来源。\n2. 与组件库配合：把 Impeccable 的输出映射到你现有的组件库实现（例如将建议样式转换为 design tokens）。\n\n### 注意事项\n\n- 并非运行时系统：不提供生产级组件，仍需工程化实现与测试。\n- 注意 agent 差异：不同 LLM/harness 在命令语法与能力上有差异，需针对性调优。\n\n> 重要提示：将反模式作为负面约束引入时，要在项目级别校准（某些反模式可能与已有设计系统冲突）。\n\n总结：该架构的关键优势是把人类设计知识转成可由 LLM 程序化调用的规则集合，显著提升在自动化/半自动化场景中规则的可执行性与可控性，但仍需与组件实现和人工验证结合以落地生产。¶

86.0%

如何在项目中把 Impeccable 的参考文件与本地设计系统对齐？有什么具体步骤和注意点？

核心分析\n\n问题核心：直接使用默认参考文件会导致风格冲突（例如字体、色彩不一致）或建议泛化。要把 Impeccable 真正融入工程流程，需要把默认域参考转成与你的 design tokens/组件库一致的机器可读配置。\n\n### 具体步骤（实践化流程）\n\n1. 采集上下文：运行 \/teach-impeccable`并提供项目的 design tokens、主要 breakpoints、常用组件列表与 brand 色彩。\n2. **重写参考文件**：以项目的 token 为基础修改typography、color-and-contrast、spatial-design等参考文件，明确字体族、字体尺度、色差阈值（contrast ratios）、间距模数。\n3. **版本控制**：把修改后的参考文件纳入版本库（例如/.impeccable/），并在 PR 模板中要求变更说明。\n4. **集成 CI/PR**：在 CI 中运行`/audit`对变更页面做审计，失败则阻断或生成修复任务。\n4. **映射到组件实现**：把 Impeccable 的建议自动或半自动地映射为 design token 变更或组件样式修复。\n\n### 注意事项\n\n- *细粒度校准*：某些反模式可能与既有品牌决策冲突（例如品牌需要某种特定字体），需在参考文件中明确豁免规则。\n- *保持与 LLM 版本一致*：不同 agent/版本在解析指令上差异较大，记录并固定使用的 harness 版本。\n- *人工验证必需*：即使参考文件已对齐，仍需进行键盘可访问性和真实设备测试。\n\n> **重要提示**：把/teach-impeccable` 的输出作为项目配置的一部分并纳入版本控制，可以显著降低后续命令输出的漂移风险。\n\n总结：对齐流程的核心是把人类可见的 design tokens 转换为 Impeccable 的领域参考（machine-readable），并通过版本控制与 CI/审计环节保证一致性与可追溯性。¶

86.0%

如何有效利用 Impeccable 的反模式（anti-patterns）来抑制 LLM 的常见偏差？有哪些实操建议？

核心分析\n\n问题核心：LLM 易回到通用模板与流行视觉（如 Inter 字体、紫色渐变、卡片嵌套），反模式作为负面提示能显著减少这类偏差。但滥用或未校准的反模式可能与品牌需求冲突或导致过度约束。\n\n### 实操建议\n\n- 把反模式参数化并版本化：将 README 中的反模式转成项目级配置文件（例如 /.impeccable/anti-patterns.json），并纳入版本控制，便于团队讨论与回滚。\n- 在采集上下文时持久化豁免：运行 \/teach-impeccable`时把需要豁免的设计决策记录下来（例如“公司品牌必须用 X 字体”），防止后续命令误改。\n- **针对性命令调用**：使用命令的聚焦参数（例如`/audit header`或`/polish checkout-form``）把反模式限制在有问题的区域，避免全局过度替换。\n- 把反模式作为负面提示嵌入模板：在给 LLM 下发任务时同时传入正向参考和反向禁令，确保二者共同约束输出。\n\n### 注意事项\n\n- 避免盲目全局禁止：某些反模式在特定上下文下是可接受或必要的——必须在配置中列出豁免与理由。\n- 记录变更理由：任何当场豁免或重写反模式的决定都应写入 PR/变更日志，以便审计。\n\n> 重要提示：把反模式配置当作团队协商的产物，而非单向强制，确保设计/品牌/无障碍团队共同参与。\n\n总结：通过把反模式结构化、参数化并与命令联用，以及把豁免纳入持久化配置，可以有效抑制 LLM 的通用模板偏差，同时保持对品牌与可访问性需求的可追溯控制。¶

86.0%

Impeccable 在实际使用中有哪些主要限制和失败模式？如何评估是否适合我的项目？

核心分析\n\n问题核心：Impeccable 并非万能，它的局限来自于对 LLM 能力的依赖、不是生产组件库、工具兼容性与仓库元数据（license/release）不够明确等。评估适配性需要把这些限制纳入决策矩阵。\n\n### 主要限制与失败模式\n\n- 模型能力不足：在低能力模型或错误配置下，审计/建议可能出现遗漏或误导。\n- 上下文缺失：如果未运行 \/teach-impeccable`或未定制参考文件，输出会过度泛化并可能与设计系统冲突。\n- **不是组件运行时**：输出为建议或草稿组件，需要工程化工作来变为生产代码。\n- **工具/版本兼容性**：不同 agent 要求不同安装与语法（例如 Codex CLI 的/prompts:` 前缀）。\n- 合规/许可风险：仓库元数据显示 license 未明，README 提到 Apache-2.0，但需在实际使用前核实 LICENSE/NOTICE。\n\n### 评估适配性的实用方法\n\n1. 能力审查：确认团队对 LLM agent 的熟练度与能否固定 harness 版本。\n2. 试点项目：选择核心页面或常修改组件进行 2–4 周试点，度量发现数量与修复率。\n3. 工程配套：确保有把建议映射到 tokens/组件的工程流程与测试覆盖（包括 A11Y）。\n4. 合规核查：在采用前核实 LICENSE/NOTICE 与内部法律团队确认再发布/商用约束。\n\n### 注意事项\n\n- 小团队/无 LLM 经验者：先采用人工化审计清单或现有 linters，再考虑引入 Impeccable。\n- 追踪与回滚：把所有 Impeccable 配置和参考文件纳入版本控制，便于回滚与审计。\n\n> 重要提示：不要把 Impeccable 当作最终可接受性的判定者；将其输出纳入一个带有人类复核的交付链。\n\n总结：Impeccable 适合有 LLM 经验、能把规则工程化并管理合规性的团队；对于不满足这些条件的项目，应把它作为辅助工具并先做小范围试点。¶

85.0%

什么时候应该选用 Impeccable 而不是传统的设计系统、UI 组件库或现有 linters？

核心分析\n\n决策要点：Impeccable 并不是为了替代设计系统或 UI 库，而是为了补强在 LLM 驱动 的生成与审查环节的规则传递与一致性控制。选择应基于你的主要目标：自动化与 LLM 集成，还是运行时一致性与工程约束。\n\n### 什么时候优先选 Impeccable\n\n- 需要把设计知识注入多种 LLM agent：如果团队在用 Cursor、Claude、Gemini、Codex 等做 UI 生成/审查，希望统一规则与提示，Impeccable 提供的可分发 skill 十分适合。\n- 希望在生成/审查阶段提升一致性：用于自动审计（\/audit`）和润色（`/polish`）以减少人工初筛工作量。\n- **需要可移植的规则层**：跨项目或平台分发相同设计规则而不复制组件实现时。\n\n### 什么时候优先选设计系统/组件库或 linters\n\n- **运行时保证与性能/兼容性要求**：要保证实际交付的样式、可访问性与性能，组件库与工程化 linters（A11Y linters、stylelint）更直接有效。\n- **需要生产级组件与单元测试**：Impeccable 产出建议或草稿，真正的组件仍需由组件库提供。\n\n### 实用组合策略\n\n1. **并行使用**：把 Impeccable 用在生成与审查阶段，将其建议映射为 design token 改动或组件修复，再通过组件库/linters 做最终验证。\n2. **流程化**：在 PR 流程中先运行`/audit``（Impeccable），然后触发 linters 与视觉回归测试作为必过项。\n\n> 重要提示：视为互补工具而非对立选择——Impeccable 改善设计决策的生成与审查层面，组件库与 linters 提供运行时与代码级保障。\n\n总结：如果你的痛点是 LLM 生成的一致性与可控性，优先采用 Impeccable；如果痛点在运行时的可测试性、性能与交付质量，优先强化设计系统与组件库，并辅以 Impeccable 做上游规则治理。¶

85.0%

从工程与 UX 使用角度看，引入 Impeccable 的学习成本与常见使用陷阱有哪些？如何规避？

核心分析\n\n问题核心：引入 Impeccable 的门槛体现在两方面：技术集成（安装 dist 包、为不同 agent 做配置）和语义对齐（理解并定制参考文件）。常见陷阱包括对 LLM 产出的盲目信任、版本/工具兼容问题与上下文不足导致的泛化。\n\n### 深度分析\n\n- 学习曲线（中等）：对熟悉 LLM agent 的开发者而言，下载 dist 并启用技能相对直接；但要得到稳定输出，需要理解参考文件与反模式的语义并进行调优。\n- 工具兼容性风险：不同 harness（Cursor Nightly、Claude/ Gemini preview、Codex CLI）有不同的语法与功能，安装步骤与行为会有差异。\n- 输出信任问题：Impeccable 提供建议，但可访问性、性能及交互正确性仍需人工或自动化测试验证。\n\n### 实用规避策略\n\n1. 培训与文档：为团队准备简明的上手文档（包含常用命令、示例流程和常见豁免）。\n2. 固定环境：锁定 agent 版本与配置，记录在项目文档（避免 Nightly/preview 导致的不可重复行为）。\n3. 流程化校验：在 PR/CI 中运行 \/audit``，并把结果转成 issue 或自动标注以供人工复审。\n4. 半自动化落地：对重要更改采用人工复核（A11Y tests、device QA）再合并。\n\n### 注意事项\n\n- 永远不要完全信任 LLM 输出：把 Impeccable 当作早期筛查和建议来源，而非最终批准者。\n- 记录反模式变更：若项目需要豁免某些反模式，应在版本库中记录该决策理由。\n\n> 重要提示：在引入初期，把 Impeccable 限定在一两个页面/组件上试点，观察命令输出在实际 PR 工作流中的表现，再推广到全仓库。\n\n总结：通过固定 harness 版本、培训、CI 审计与人为验证的组合，可以把中等的学习曲线与常见陷阱管控到可接受水平，从而安全地将 Impeccable 纳入工程化流程。¶

84.0%