Click Path Audit Skill 是 Everything Claude Code 插件体系中的高级调试工具，专门用来追踪每个用户交互触点（如按钮、表单等）在实际操作下的完整状态变化序列。它能发现那些单独函数测试都没问题，但组合后却导致 UI 状态错乱或“按钮无效”的复杂 Bug。通过系统性梳理状态流、识别副作用和顺序冲突，Click Path Audit Skill 极大提升了 AI 辅助编程下前端交互的可靠性和可维护性，尤其适用于大型重构、共享状态变更后或用户反馈“按钮没反应”时的精准排查。

Everything Claude Code Click Path Audit Skill：追踪每个触点完整状态变化序列，发现组合使用才出现的 Bug

在现代前端开发中，随着 Zustand、Redux、React Context 等状态管理方案的普及，UI 交互的复杂性大幅提升。许多时候，单步调试、静态代码检查和常规测试都无法发现“按钮无响应”“状态莫名被重置”这类只有在多个操作组合下才暴露的问题。Click Path Audit Skill 正是为此而生：它以“行为流审计”为核心，系统性梳理每一个用户可见触点的状态变化全链路，精准捕捉那些只有在特定顺序、特定副作用下才会出现的隐藏 Bug。

1. Click Path Audit Skill 解决了什么问题？

传统调试方式（如断点、单元测试、类型检查）只能验证函数本身是否存在、是否崩溃、返回类型是否正确，却无法回答：

• 最终 UI 状态是否和按钮/操作的承诺一致？
• 函数 B 是否悄悄撤销了函数 A 的操作？
• 共享状态（如 Zustand store）是否有副作用导致状态被重置？

比如，某个“新建邮件”按钮的 onClick 先调用 setComposeMode(true)，再调用 selectThread(null)。两者单独测试都没问题，但 selectThread 内部有副作用会把 composeMode 重置为 false，导致按钮表面上什么都没做。系统性调试能发现 54 种常规 Bug，但这种“组合副作用”只有 Click Path Audit Skill 能精准定位。

2. 触发条件：什么时候需要用 Click Path Audit Skill？

• 用户反馈“按钮无效”但常规调试未发现问题时（典型场景）
• 重构后涉及共享状态（如 Zustand/Redux/Context）变更时
• 发布前对关键用户流程做全链路状态流审计
• 新增/修改状态管理函数后，需排查所有调用方是否受影响

在 Everything Claude Code 体系中，通常在 /superpowers:systematic-debugging 之后、/superpowers:verification-before-completion 之前运行 Click Path Audit Skill，确保所有隐藏的交互 Bug 被提前暴露（可参考 Claude Code 快速上手指南 了解整体流程）。

3. 使用流程 Step by Step

Step 1：梳理所有状态存储及副作用（State Store Mapping）

首先，对当前页面或模块涉及的所有 Zustand store、React context 进行“副作用映射”：

// 伪代码示例
STORE: emailStore
  setComposeMode(bool) → sets: {composeMode}
  selectThread(thread|null) → sets: {selectedThread, ...} RESETS: {composeMode: false, ...}

• 明确每个 action/setter 会修改哪些字段，是否会“顺带”重置其他状态
• 标记出“危险副作用”（如 selectThread 会重置 composeMode，虽然 composeMode 的 owner 是 setComposeMode）

Tip: 这一步输出的副作用表是后续所有触点审计的基础，建议用专门 Agent 先独立完成。

Step 2：逐个审计每个用户交互触点（Touchpoint Audit）

对每个按钮、切换、表单提交等交互点，逐步追踪其 handler 内的所有函数调用顺序：

TOUCHPOINT: "新建邮件" 按钮 in ThreadList.tsx:123
  HANDLER: onClick → {
    call 1: setComposeMode(true)   // sets composeMode = true
    call 2: selectThread(null)     // resets composeMode = false
  }
  EXPECTED: 用户应看到新建邮件界面
  ACTUAL: composeMode 被重置为 false，界面无变化
  VERDICT: Sequential Undo — 组合副作用导致按钮无效

常见 Bug 模式包括：

• 顺序撤销（Sequential Undo）：后续函数把前面设置的状态又重置了
• 异步竞态（Async Race）：多个异步操作导致最终状态不确定
• 闭包陈旧（Stale Closure）：多次 setState 捕获了旧值，导致状态未正确累加
• 状态转移缺失（Missing State Transition）：按钮承诺的操作未真正执行（如只校验未保存）
• 条件死路径（Conditional Dead Path）：条件恒为 false，实际操作永远不发生
• useEffect 干扰：按钮设置状态后，被 useEffect 监听又重置

Step 3：生成结构化审计报告

对每一个发现的 Bug，输出标准化报告，便于后续修复和测试：

CLICK-PATH-001: [severity: CRITICAL]
  Touchpoint: "新建邮件" 按钮 in ThreadList.tsx:123
  Pattern: Sequential Undo
  Handler: inline
  Trace:
    1. setComposeMode(true) → sets {composeMode: true}
    2. selectThread(null) → resets {composeMode: false}
  Expected: 用户进入新建邮件模式
  Actual: 状态被重置，UI 无变化
  Fix: 调整调用顺序或拆分副作用

Step 4：合理控制审计范围（Scope Control）

Click Path Audit Skill 属于高强度审计，建议按需分层：

• 全应用审计：适合大版本上线或全局重构后，建议每个页面/模块分配独立 Agent 并行执行
• 单页面审计：新建页面、用户反馈异常时优先使用
• 状态函数变更审计：Zustand/Redux action 变更后，重点审计所有调用方

推荐 Agent 分工示例：

Agent 1: 先梳理所有状态存储（全局副作用表）
Agent 2~N: 各自负责不同页面/模块的触点审计

Agent 1 的输出作为其他 Agent 的输入，确保副作用信息一致。

4. 输出示例

真实案例：ThreadList.tsx “新建邮件”按钮 Bug

onClick={() => {
  useEmailStore.getState().setComposeMode(true)   // ✓ sets composeMode = true
  useEmailStore.getState().selectThread(null)      // ✗ RESETS composeMode = false
}}

Store 定义：

selectThread: (thread) => set({
  ...,
  composeMode: false,     // ← THIS silent reset killed the button
  ...
})

报告输出：

CLICK-PATH-007: [CRITICAL]
  Touchpoint: "新建邮件" 按钮 in ThreadList.tsx:87
  Pattern: Sequential Undo
  Handler: inline
  Trace:
    1. setComposeMode(true) → sets {composeMode: true}
    2. selectThread(null) → resets {composeMode: false}
  Expected: 进入新建邮件界面
  Actual: composeMode 被重置，UI 无变化
  Fix: 拆分 selectThread 的副作用或调整调用顺序

5. 常见配套 Agent 与 Skill 协作关系

• 配套 Agent：通常与“状态存储映射 Agent”“页面审计 Agent”并行使用，适合全局大规模审计
• 与其他 Skill 协作：
  • 先于 /superpowers:verification-before-completion 运行，确保所有隐藏 Bug 被提前发现
  • 后于 /superpowers:systematic-debugging，补充常规调试遗漏的“组合副作用”类问题
  • 与 /superpowers:test-driven-development 联动，将发现的 Bug 转化为自动化测试用例

更多关于多 Agent、Skill、Hook 协作的高阶用法，可参考 Everything Claude Code 完全指南 和 Hooks 实战。

---

FAQ

Q: Click Path Audit Skill 和常规单元测试、系统调试有何区别？
A: 它专注于“多函数组合副作用”导致的 UI 状态流 Bug，能发现单独测试都没问题但组合后出错的场景，是常规测试/调试的有力补充。

Q: 这项审计会不会很耗时？适合多大范围使用？
A: 是的，Click Path Audit Skill 属于高强度全链路分析，建议在关键流程、全局重构后或用户反馈异常时使用，可通过多 Agent 并行缩短耗时。

Q: 审计后发现 Bug，如何快速修复和防止回归？
A: 建议将报告输出的 Bug 立即转化为自动化测试用例，并结合 TDD/Verification Loop 等 Skill，确保修复后不会回归。

---