用一张规则表连接代码、评审与用户路径
虚构的社区图书交换站正在改造预约页面：读者选择取书时段，填写联系方式，在确认弹窗提交。团队同时维护 React 组件、TypeScript 类型和旧样式文件，规范散落在文档与口头约定中。一次 PR 即使通过格式检查，也可能允许重复预约，或者让键盘用户无法关闭弹窗。解决这类问题需要三层证据：可执行的团队规则、基于变更的走查、实际页面的无障碍路径。 先记录本次提交、比较基线、页面入口、启动方法、测试数据和适用的规范版本。本文给出可重复的操作方案，没有实际运行读者项目，也不承诺装上 Skill 后提交钩子就会自动生效。所有自动检查都需要明确接入点、执行环境和失败处理，不能把推荐文字当作已经部署的质量门禁。
场景一：把团队规范变成有边界的检查
从五类规则起步：导入边界、导出约定、类型要求、文件放置、组件状态归属。每条规则记下编号、理由、适用目录、正反例、检测方式和例外负责人。例如预约领域的内部模块只能通过公共入口导入；对应反例应指出具体路径，而不是写“架构不合理”。旧目录可以先记录基线，新改动按约定逐步收敛，避免把历史所有问题一次性压给当前作者。 优先复用项目已有 ESLint、TypeScript 与格式配置。先查看 package 脚本、锁文件和工作区结构，确认命令是否真的覆盖目标文件。ESLint 可通过规则和插件做多类静态检查，其能力取决于配置，不能一概说它完全不能发现无障碍或结构问题。格式工具、类型检查与人工规则各有边界，不应重复输出同一条建议制造噪声。 第一次只做检查，保留命令、版本、退出码、文件位置和原始诊断。需要自动修复时先解释会改哪些文件，确认当前改动已经有可恢复基线；修复后看 diff，再运行相关检查，不能因自动工具返回成功就跳过语义确认。生成目录、第三方代码和测试夹具应按实际情况配置，不能用大范围忽略让报告看起来整洁。 React 或 Next 项目可以在组件实现与性能模式复核这一步使用 React Best Practices。公开详情和 Vercel 固定来源已核验，MIT 许可。先确认框架与代码上下文，团队明确的业务约束优先。该技能不自动等于团队规范全集，也不验证预约名额规则、代码安全或完整无障碍；性能建议需要测量，不能凭模式名称宣称速度提升。 交付规则映射表与检查记录：哪些规则由工具覆盖，哪些由走查覆盖，哪些尚未实现。给每条例外设范围、理由和复查日期。团队之后修改规范时同步更新测试样例，避免文档与实际检查朝相反方向演进。
场景二：从差异追到行为，而不是只看新增行
先确认 PR 的真实基线，列出变更文件和受影响调用方。检查删除、重命名、公共类型、配置与依赖变化；只看新增行会漏掉被删掉的校验和受影响消费者。预约例子中，确认按钮虽然只改了几行，但如果请求状态从组件局部迁移到共享模块，就要追踪重复点击、取消请求及页面切换后的状态。 逐项走查正确性、类型与错误处理、结构与依赖、样式与响应式、测试及无障碍。正确性要回到产品约定：剩余名额由服务端确认，客户端禁用按钮只是交互措施。网络超时后应区分未知结果与明确失败，不能立即提示重新提交而忽略重复写入风险。类型检查能发现部分不一致，但不能证明接口数据和业务规则完全正确。 报告每项包含文件行号、可复现条件、预期与实际行为、影响、证据及最小修复建议。将确定缺陷、待验证风险和风格建议分开，严重度以用户影响和可达路径解释，不靠形容词。缺少服务端契约时标出缺口，不能伪造一个测试结果填满清单。人工评审仍需审查关键业务、不确定项及代表性低严重度问题，而不是只看工具标记的最高两档。 对于弹窗修复，补充回归样例：连续点击一次只形成一笔有效预约；错误反馈保留已填字段；取消后不会出现迟到的成功提示；刷新页面后呈现与服务端一致的状态。哪些是组件测试、哪些依赖接口测试、哪些需要浏览器操作，要在报告中注明。产物是可复查发现表、建议补丁及回归记录，不能把一份 Markdown 报告叫作“已经完成评审”。
场景三：在可操作状态中检查无障碍
先约定目标标准、页面范围、设备与辅助技术组合。这里参考 WCAG 2.2 快速参考组织测试，不作法律合规结论。开源 axe-core 是自动化网页检查候选，其公开规则与 MPL-2.0 许可证便于评估；选择依据是可读文档、适用规则和团队集成成本，不是星数。安装或运行前确认版本、依赖及页面数据范围。 不要只扫描首屏。分别打开空表单、时段已选、错误提示、确认弹窗、提交中和成功状态。记录扫描引擎、规则配置、浏览器、URL、状态准备步骤及结果；需要人工判断的项目单列，不把未完成项当通过。DOM 正则只能发现某些模式，不能确认元素在真实页面中的可操作性；自动扫描也不能证明完整 WCAG 符合性。 然后沿键盘路径从页首进入表单，确认每个控件可达、焦点可见、顺序合理。打开弹窗后检查焦点进入、交互范围、关闭动作和返回触发控件。遇到错误时，读者应能找到错误摘要与对应字段，不能只有颜色变化；提交失败后保留输入，说明可采取的下一步。对有时限的预约确认，依据实际标准条款及业务例外评估能否调整、延长或取消时限，不能把某一群体的所有需求简化成一条“容错”规则。 本地页面路径回归可选用 Webapp Testing。Anthropic 固定来源与 Apache-2.0 许可已核验，它适合用 Python Playwright 观察本地页面、操作控件、记录截图和日志。前提是明确启动命令、端口、可用测试账户与无敏感数据夹具。它可以协助重复键盘路径，但不提供完整屏幕阅读器评估，不证明后端持久化或法律合规。不要假定其包内已经配置了 axe-core；需要额外集成时单独记录。 交付状态清单、自动结果、人工路径记录和修复复测。涉及真实用户的测试应由团队按适合的方式组织，避免用机器人结果取代使用体验。修复标签后还要核对名称是否准确，添加 ARIA 也不能修好本来就错误的交互模型。
一次实操与门禁接入
可以这样给任务：“按当前规范版本审查图书预约 PR，先列基线和规则映射；只读检查后再提出最小修改。分别报告静态诊断、业务风险与键盘路径，写明每条发现的证据和未验证部分。不得擅自更新依赖、改变提交钩子或修改远端合并保护。”这能避免 Agent 把建议和实际执行混在一起。 接入提交检查时，先在团队认可的环境中测量耗时和误报，再决定哪些规则阻断。用正常样例、已知违规样例、工具启动失败样例测试三个结果；依赖缺失不是“零违规”。本地钩子可能被跳过，CI 是否必需检查要核对实际仓库规则。增量检查适合快速反馈，但共享配置、删除代码和跨模块变更可能需要更大范围检查。夜间全量检查要有负责人，不能只生成没人阅读的报告。
FAQ 与故障排查
已有规范文档还要技能吗？只有存在重复任务并且技能适用时才需要；先让规则可测试，技能用来辅助组织执行，不会自动注册钩子。已有 ESLint 还要走查吗？配置中的静态规则只覆盖部分问题，业务契约、真实交互与不确定路径仍需证据。不会写规则怎么办？先选少量明确规则与反例，再使用现有配置验证，避免宣称所有技能开箱即用。 检查突然变少怎么办？核对文件匹配、工作目录、缓存、忽略项与比较基线；保存环境变化再定位。报告很多却无法复现怎么办？要求最小路径和对应规则，不能用数量衡量审查质量。无障碍是否只服务出海或合规团队？键盘操作、清晰反馈和可恢复输入本身就影响日常使用，具体法律义务则要按实际地区与项目单独确认。 多久更新技能关联？随着目录变化定期复核当前公开详情、固定来源、许可证与用途边界，记录日期及移除原因；同名、热度或新增数量都不能代替匹配。需要发现技能时先核验 SkillPI Skill Finder 官方来源和安装前提，再找针对当前步骤的能力，不自动安装整组不明包。
来源与验收边界
原文中英文的规范自动检查、合并前走查、无障碍及 FAQ 场景在本稿分别保留。参考 ESLint 官方文档、axe-core 上游仓库、W3C WCAG 快速参考及两项技能的固定源码。未沿用匿名引语、使用人数和未经验证的速度承诺。验收以规则可追溯、发现可复现、页面路径可重复及未执行项明确为准，不以“Agent 已审阅”作为质量证明。