开发工具版本控制【免费下载链接】vscode-gitlensSupercharge Git inside VS Code and unlock untapped knowledge within each repository — Visualize code authorship at a glance via Git blame annotations and CodeLens, seamlessly navigate and explore Git repositories, gain valuable insights via rich visualizations and powerful comparison commands, and so much more项目地址https://gitcode.com/gh_mirrors/vs/vscode-gitlens点击查看免费下载导读本文深入解析 GitLensvscode-gitlens仓库中内置的 Claude Code 技能/ux-review用户流程体验审查。与只追踪代码路径的/deep-review不同/ux-review以开发目标文档goals.md中的User Experience与Success Criteria为审查基准端到端走查用户流程专门发现死胡同dead ends、反馈缺失、可发现性缺口与体验断层。读完本文你将掌握该技能的调用方式、四步走查流程、七透镜评估框架、标准输出格式以及它如何嵌入 GitLens 从 issue 到合入triage → dev → review → commit的完整开发流水线。技能定义文件位于 .claude/skills/ux-review/SKILL.md与其配套的同类技能位于 .claude/skills/ 目录下deep-review、dev-scope、review、a11y-audit等。一、定位/ux-review 与 /deep-review 是两副不同的透镜原文档开篇即明确了二者的分工Use/deep-reviewfor the code-level merge gate. Use/ux-reviewfor user flow validation. Different lenses.两者都承担实现后审查但审视对象完全不同SkillTraces追踪对象Finds发现的问题/deep-review代码路径code paths合入门禁目标对齐、完整性、验证通过内置/code-review做 bug 排查/ux-review用户流程user flows死胡同、反馈缺失、可发现性缺口、UX 断层/deep-review的回答是代码对不对、合不合规、目标达成没有/ux-review回答的是用户能不能顺畅地得到他想要的结果、体验对不对。对于任何面向用户user-facing的改动两者应一起使用/deep-review抓代码层问题/ux-review抓体验层问题。相关定义可对照 .claude/skills/deep-review/SKILL.mdmerge-gate 审查与 .claude/skills/review/SKILL.mdGitLens 标准的轻量静态代码检查。二、调用方式与适用边界用法/ux-review [target] --scope .work/dev/{id}/--scope path必填指向包含goals.md的 dev 文件夹。goals.md对 UX 审查来说不可省略——没有它就没有审查所依据的预期用户体验的权威描述。如果该目录不存在goals.md应当停下来告知用户先运行/dev-scope或让用户直接内联提供 UX 意图。无参数审查暂存区改动git diff --cachedall所有未提交改动branch相对基线分支的改动git diff main...HEADpr当前 PR 改动gh pr diffcommit:SHA指定提交其中goals.md由 .claude/skills/dev-scope/SKILL.md 产出其标准结构中的User ExperienceTrigger / Expected flow / Edge cases / Workflow context与Success Criteria正是/ux-review的审查基准。/dev-scope与/deep-planning、/challenge-plan共同构成实现前的规划流水线。何时可以跳过并非每个改动都需要 UX 审查。原文档明确列出三种跳过场景纯内部改动重构、性能优化、测试基础设施无用户可见表面一行式的 bug 修复UX 影响显而易见且可控没有goals.md且用户确认该改动没有 UX 维度。原文档的忠告是拿不准就跑——一次快速的无 UX 发现很便宜一个随版本发布的 UX bug 才昂贵。三、四步走查流程Step 1收集上下文Gather Context读取{scope}/goals.md重点看User Experience与Success Criteria两个章节——这就是审查所依据的规格按 target 参数获取 diff与/deep-review一致无参git diff --cached、all→git diff HEAD、branch→git diff main...HEAD、pr→gh pr diff、commit:SHA→git show SHA完整阅读所有被修改的文件而不是只看 diff hunks——理解用户可见行为的周边上下文。Step 2识别用户可见改动Identify User-Facing Changes对 diff 中的每处改动逐一回答三个问题出现在哪个表面surface编辑器、树视图、webview、quick pick、状态栏、通知、命令面板、上下文菜单还是终端由什么触发用户动作点击、命令、快捷键自动触发打开文件、仓库变更还是事件驱动定时器、外部事件用户看到什么改动生效前、生效中、生效后分别是什么。过滤掉没有用户可见表面的改动标注无 UX 影响no UX impact后继续。Step 3走查用户流程Trace User Flows与/deep-review从 diff 追踪代码路径不同这里追踪的是用户路径从 goals.md 的 UX 章节出发——这是规格审查就是拿 diff 去对照它端到端走完每个流程——从 goals.md 描述的触发器开始直到流程完成记下每一处实现与描述体验不一致的地方检查 diff 里没有的东西——缺失的实现就是 UX bug。如果 goals.md 描述了某个错误状态而 diff 没有处理它这就是一条 finding。Step 4用七透镜评估Evaluate Against Seven Lenses并非每个透镜都适用于每次改动——不适用就跳过并说明。七个透镜详见下一节。四、七透镜评估框架详解1. Flow Delivery流程交付实现是否真正交付了goals.md描述的用户流程Happy path主路径逐步走查预期流程goals.md 的每一步是否都有对应实现是否存在用户会撞上的死胡同Error paths错误路径出错时用户看到什么错误信息是否可操作找不到远程仓库——请检查你的网络连接还是含糊不清操作失败出错后用户是否处于可恢复状态Edge cases边界情况空状态、首次使用、数据缺失、并发操作、超大输入分别会发生什么goals.md 里列的边界情况是否都被处理了Entry/exit进出点流程是否从正确的地方开始命令面板、上下文菜单、按钮、自动触发结束时用户是否落在合理的位置2. Feedback Responsiveness反馈与响应UI 在每个阶段是否都在传达正在发生什么加载状态耗时操作git 命令、API 调用、文件解析期间用户能否看到进度条、spinner 或至少有事情在发生静默超过约 200ms 就需要反馈成功确认动作完成时用户是否知道成功了并非每个动作都要 toast——有时 UI 自动更新就是足够的确认但破坏性或不可逆操作必须显式确认失败沟通失败是否出现在用户正在看的位置一条用户永远看不到的日志错误不算反馈状态切换UI 在状态间切换loading→loaded、editing→saved、collapsed→expanded时是平滑还是突兀3. Discoverability可发现性用户能否找到并理解这个功能位置功能是否出现在正确的表面命令面板、上下文菜单、视图操作、编辑器 gutter、状态栏——用户自然会去找的地方命名命令名、菜单标签、tooltip 是否使用用户思考时的语言避免内部黑话。用户用自然语言搜索命令面板时应该能找到它首次接触如果是新功能用户如何知道它存在是否有 walkthrough 步骤、whats new 条目或上下文提示可感知性Affordances可交互元素看起来可交互吗禁用元素是否通过 tooltip 或上下文消息解释了禁用原因4. Consistency一致性它看起来像 GitLens 吗交互模式是否与现有类似功能的模式一致GitLens 已有同类做法时应保持一致除非有明确理由不这样做术语是否使用了 GitLens 其他位置对同一概念的相同措辞例如 repository vs repo、stash vs shelf视觉语言图标、树条目结构、webview 布局、quick pick 格式是否符合 GitLens 既有约定行为预期用户学会了某个 GitLens 功能后这套知识能否迁移到这个新功能上5. Workflow Integration工作流集成它是否契合人们在 VS Code 中的真实工作方式流程保持功能让用户留在当前流程里还是把用户拽出上下文本可以用通知的地方弹了模态框、本可以用行内指示器的地方却切换了整个视图——这些都是流程断裂可逆性用户能否撤销或退出破坏性动作需要确认多步流程需要能回退或取消可组合性能否与 VS Code 其他功能及 GitLens 其他功能协同是否与常见快捷键冲突、独占面板、破坏预期的多仓库行为打断成本如果用户正在做别的事编辑、审查、rebase这个功能会打断他吗会抢焦点吗6. Information Design信息设计是否在正确的时间呈现了正确的信息渐进披露UI 是否先展示必要信息、允许用户按需深入还是一股脑全部倒出信息层级最重要的信息是否在视觉上最突出树视图、hover 详情、webview 面板中用户的目光是否落在关键处密度信息密度是否适配场景树视图应可快速扫读详情面板可以更丰富quick pick 应简洁空状态没有数据时用户看到的是有帮助的引导消息还是一片空白空状态是引导用户的绝佳机会还没有 stash——用git stash保存进行中的工作。7. Accessibility无障碍所有用户都能有效使用这个功能吗键盘每个交互都能用键盘完成吗Tab 顺序合理吗自定义交互元素有键盘处理器吗屏幕阅读器元素是否有合适的 ARIA 标签、角色和状态动态更新是否使用 live regions焦点管理改变 UI 的动作开关面板、导航列表之后焦点是否落在合理位置模态框是否困住焦点对比度与主题功能是否尊重 VS Code 主题没有硬编码颜色在高对比度主题下可用吗GitLens 仓库对无障碍还有一整套配套技能可对照 .claude/skills/a11y-audit/SKILL.mdWCAG 2.1 AA 静态审计与其 references 目录下的aria-patterns.md、wcag-criteria.md、safety-rules.md等参考文档。五、Review Rules审查的边界纪律原文档为/ux-review划定了严格的边界防止越界审查goals.md 的 UX 章节是规格——对照它审查而不是对照自己的 UX 偏好如果 goals.md 的 UX 章节不完整把不完整本身作为 finding 提出而不要自行发明需求已描述用户流程的缺失实现是 UX bug不是未来工作一个技术上正确但不可发现的功能依然是失败不评估代码质量、性能内部实现或测试覆盖——那是/deep-review和/review的职责不评估webview CSS 的视觉设计布局、间距、颜色超出主题合规之外的都不评估——这需要运行中的扩展进行视觉检查不运行扩展、不与之交互——这是对用户可见行为的代码级审查不是手工 QA 巡检。这些边界与 .claude/skills/deep-review/SKILL.md 的边界评估 goals 对齐、完整性、验证互为补充形成代码门禁 体验门禁的双重审查结构。六、输出格式与审查报告Findings按严重度排序每条 finding 必须包含以下字段字段取值lensflow delivery / feedback / discoverability / consistency / workflow / information design / accessibilityseveritycritical阻塞合入/ high应修复/ medium尽快修复/ low备注confidenceconfirmed / likely / low-confidencelocationfile:line 或用户可见表面例如 Commit Graph context menu然后依次说明用户实际体验到的、用户应当体验到的、建议的修复方案。示例 finding原文档原文lens: feedback |severity: high |confidence: confirmedlocation:src/commands/git/push.ts:142- push command error pathIssue: When push fails due to no upstream branch, the error is caught and logged but the user sees nothing -- no notification, no status bar update, no output channel message. The operation silently fails.Expected: The user should see an actionable notification: No upstream branch set for {branch}. Set upstream? with a button to rungit push --set-upstream.Fix: Add awindow.showWarningMessagein thePushError.is(ex, noUpstream)branch with an action button that runs the set-upstream command.这个示例的写法本身就是一份迷你检查清单先给出透镜 严重度 置信度 位置四元组再用 Issue用户实际遇到什么→ Expected应该遇到什么→ Fix怎么修三段式描述。仓库中的真实推送命令位于 src/commands/git/push.ts其中已存在--set-upstream标志的 quick pick 处理逻辑见该文件createFlagsQuickPickItemFlags(flags, [--set-upstream, ...])与Flags --force | --set-upstream | string的类型定义示例所指的无上游分支静默失败正是这类流程中典型的高严重度反馈缺口。报告必需章节Findings—— 按严重度排序使用上述格式Flow walkthrough—— 实现中的端到端用户流程标注何处与 goals.md 一致、何处背离Workflow impact summary—— 该改动触及了哪些既有用户工作流、如何影响。改动不是孤立存在的——识别穿过被修改表面的更广泛工作流例如 push 行为改动会影响 commit→push→PR、stash→branch→push 等。对每个受影响工作流命名它、从用户视角描述变化、标记变化是中性的neutral、改进的improved还是退化的degradedWhat works well—— 值得肯定的 UX 亮点Open questions—— 需要人工测试验证的事项仅凭代码无法完全评估的交互Verdict—— 三选一UX approved—— 体验符合意图UX approved with follow-ups—— 存在不阻塞合入的次要问题UX needs work before merge—— 体验在重要方面背离了 goals.md。如果没有发现问题要明确说出来然后列出残余风险residual risks与需要人工测试的开放问题open questions for manual testing。七、在 GitLens 开发流水线中的位置与目标文档流水线的衔接/ux-review是 docs/triage-dev-skills.md 所描述的Dev Pipeline的正式一环。该文档完整定义了从 issue 到合入的流程/dev-scope产出 goals.md → /deep-planning产出 plan.md → /challenge-plan产出 challenge.md → /worktree隔离分支 ── 实现阶段 ──UI 改动可配合 /live-exercise → /deep-review产出 review.md → /ux-review产出 ux-review.md → /commit → /audit-commits/ux-review消费goals.md由/dev-scope产出并产出ux-review.md供人类审查。典型调用组合是/deep-review branch --scope .work/dev/5096/ /ux-review branch --scope .work/dev/5096/产物与存放位置所有 dev 产物统一写在主工作树的.work/根下该目录被 gitignore不随 worktree 共享。/ux-review的产物约定为.work/dev/{identifier}/ux-review.mdrubber-duck第二意见模式下还会生成ux-review.rd.md保存搭档模型的批评意见。完整布局见 docs/triage-dev-skills.md。脚本化编排与第二意见/ux-review可独立使用也可通过pnpm workflow脚本纳入流水线# 完整 dev 流水线scope → plan → challenge停在实现前 pnpm workflow dev 5096 # 实现完成后跳过前置阶段直接做实现后审查 pnpm workflow dev 5096 --skip-to review其中--skip-to的 dev 阶段包括scope、plan、challenge、review、ux-review、commit。/ux-review阶段支持--rubber-duck第二意见模式主 agent 产出报告后由不同模型家族的搭档 agent 给出 35 条高价值关切主 agent 据此修订并追加 Second-Opinion Review 章节搭档失败不阻塞非阻塞式。注意 dev 流水线有明确的安全模型分析类技能只读永不修改 GitHub issue 或已提交代码pnpm workflow脚本从不自动实现代码会在 challenge 阶段后停下等待人工--skip-to review。上述安全与编排细节同样记录于 docs/triage-dev-skills.md。在仓库工作流中的参考位置仓库 AGENTS.md 的 Git 与仓库指南一节也引用了这套技能体系For code reviewing, use/reviewor/deep-review... Additional workflow skills live in.claude/skills/并规定所有 skill 产物写入主工作树的 gitignored.work/根目录。八、实战要点小结先有 goals再谈 UX 审查--scope指向的目录必须包含goals.md否则停下让用户先跑/dev-scope或提供内联 UX 意图——没有规格的 UX 审查无从谈起拿 diff 与 goals 对照而不是凭感觉七透镜里的每个问题都要落到goals.md 怎么说 / diff 怎么做的对照上重点盯diff 里没有的东西缺失的错误处理、缺失的空状态、缺失的加载反馈都是 UX bug不是未来工作输出要可执行每条 finding 必须带 lens、severity、confidence、location 四元组并给出用户实际体验 → 应该体验 → 修复建议三段式描述守住边界不评代码质量那是/deep-review、不评视觉设计细节、不运行扩展——只做用户可见行为的代码级审查善用组合面向用户的改动同时跑/deep-review与/ux-review代码门禁与体验门禁缺一不可配合pnpm workflow dev id --skip-to review可脚本化串联。遵循这套流程一个技术上正确但用户用不起来的功能就能在合入之前被系统性地拦下来。赞分享开发工具版本控制【免费下载链接】vscode-gitlensSupercharge Git inside VS Code and unlock untapped knowledge within each repository — Visualize code authorship at a glance via Git blame annotations and CodeLens, seamlessly navigate and explore Git repositories, gain valuable insights via rich visualizations and powerful comparison commands, and so much more项目地址https://gitcode.com/gh_mirrors/vs/vscode-gitlens点击查看免费下载相关推荐Newton 代码审查实战指南基于 code-review-newton 技能的三轴审查方法论Newton 代码审查实战指南基于 code review newton 技能的三轴审查方法论 导读 code review newton 是 Newton物理引擎机器人艾尔登法环存档编辑器终极指南5步打造完美褪色者Build艾尔登法环存档编辑器终极指南5步打造完美褪色者Build 想要重新分配属性点却不想重新开档错过了传说级武器又不想再跑一遍地图ER Save Editor这开发工具版本控制Presto PR 代码审查指南基于 review-presto-pr 技能的完整审查流程与规范Presto PR 代码审查指南基于 review presto pr 技能的完整审查流程与规范 导读 本文基于 Presto 官方仓库 prestodb/大数据数据库后端上一篇如何使用clockwork快速构建可测试的Go应用从入门到精通下一篇如何5分钟部署web-vmstats快速搭建实时Linux系统监控仪表板创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考