Requirements
- Target platform
- OpenClaw
- Install method
- Manual import
- Extraction
- Extract archive
- Prerequisites
- OpenClaw
- Primary doc
- SKILL.md
UI/前端问题调试方法论。当遇到 CSS、布局、组件行为等 UI 问题时,强制执行"先观察后动手"的调试流程,避免盲目尝试。
UI/前端问题调试方法论。当遇到 CSS、布局、组件行为等 UI 问题时,强制执行"先观察后动手"的调试流程,避免盲目尝试。
Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.
I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete.
I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run.
核心原则:先理解机制,后动手修改。 当 UI 行为不符合预期时,禁止立即修改代码。必须先完成以下调试流程。
当遇到以下情况时,必须激活本 skill 的调试流程: UI 行为不符合预期 CSS/样式不生效 组件交互有问题(拖拽、点击、hover 等) 布局错乱 第一次尝试修复失败后
┌─────────────────────────────────────────────────────────────┐ │ UI 问题调试流程 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 1. 观察现象 用 DevTools 检查实际 DOM 和样式 │ │ │ │ │ ▼ │ │ 2. 理解机制 搞清楚组件/CSS 的工作原理 │ │ │ │ │ ▼ │ │ 3. 定位根因 找到真正控制行为的代码/配置 │ │ │ │ │ ▼ │ │ 4. 最小修复 只改必要的部分 │ │ │ │ │ ▼ │ │ 5. 验证 测试所有场景 │ │ │ │ │ └──── 失败 ────▶ 回到步骤 1,不要继续打补丁 │ │ │ └─────────────────────────────────────────────────────────────┘
必须使用 DevTools 或 Playwright,而不是猜测。
检查项方法实际的 DOM 结构Elements 面板Computed styles查看 width/height/min-width/max-width 等样式来源看是哪个 CSS 规则在生效是否有覆盖查看被划掉的样式布局模式table-layout / display / flex / grid事件是否触发Console 加 log 或 breakpoint
当作为 AI Agent 调试时,使用 Playwright 获取运行时信息: // 获取元素的 computed style const style = await page.$eval('selector', el => { const computed = window.getComputedStyle(el); return { width: computed.width, minWidth: computed.minWidth, maxWidth: computed.maxWidth, display: computed.display, position: computed.position, tableLayout: computed.tableLayout }; }); // 获取实际 DOM 结构 const html = await page.$eval('selector', el => el.outerHTML); // 检查元素是否可见 const isVisible = await page.isVisible('selector'); // 截图对比 await page.screenshot({ path: 'debug-before.png' }); 关键:先拿到实际数据,再做判断。不要基于代码猜测运行时状态。
在动手前,必须能回答以下问题: 这个组件/CSS 属性的工作原理是什么? 哪些因素会影响它的行为? 我要修改的代码,在整个流程中扮演什么角色?
场景陷阱真相Ant Design Table 列宽以为 <th> 的 width 控制列宽实际由 <colgroup> + scroll.x 控制scroll.x: 'max-content'以为只是让表格可横向滚动实际让浏览器忽略 width,根据内容计算Flexbox 子元素宽度设置了 width 但不生效需要同时设置 flex-shrink: 0CSS position: absolute以为相对于父元素实际相对于最近的 position: relative 祖先transform只是视觉变换会影响 position: fixed 子元素的定位z-index 不生效以为值越大越靠前需要在同一个 stacking context 中比较overflow: hidden只影响自身会创建新的 BFC,影响子元素布局
先查官方文档(MDN、组件库文档) 搜索 "X not working" / "X width ignored" 等关键词 检查组件库源码 创建最小复现 demo
问自己:是我的代码问题,还是框架/机制问题?
移除可疑代码,看问题是否消失 创建最小复现,逐步添加代码直到问题出现 检查是否有其他 CSS/JS 在干扰
类型示例修复方向配置问题scroll.x: 'max-content' 导致列宽失效修改配置CSS 优先级全局样式覆盖了组件样式提高优先级或改选择器组件 API 误用用错了 prop 或 callback 签名查文档,改用法机制不匹配想用 CSS 控制,但实际由 JS 控制改用正确的控制方式第三方库限制库不支持这种用法换方案或 fork
只改必要的部分,不引入新复杂度。
能用原生实现就不引入库 能改配置就不改代码 能改一处就不改多处 改完能解释清楚为什么这样改
反模式问题引入新库解决小问题增加依赖,可能带来新问题到处加 !important掩盖问题,后续更难维护在多个地方加补丁说明没找到根因改了生效但不知道为什么下次还会踩坑用 as any / @ts-ignore 绕过类型错误隐藏真实问题
测试所有场景,不只是出问题的那个。
原问题场景修复 相关场景没有回归 边界情况(空数据、超长内容、极小/极大值) 不同浏览器(如果需要) 响应式布局(如果需要)
如果验证失败,回到 Step 1 重新观察。 禁止: 继续在当前方向打补丁 猜测 "可能是这个原因" 没观察就尝试下一个修复
问题:拖拽列宽时,某些列往左拖不动 尝试 1:用 react-resizable 库 → 失败 尝试 2:设置 minWidth/maxWidth → 失败 尝试 3:改 CSS table-layout → 失败 尝试 4:改 transform → 失败 ...(反复折腾 N 次) 最终:改 scroll.x → 成功
1. 观察:DevTools 检查 <th> 的 computed width → 发现 width 确实在变,但视觉没变 2. 理解:搜索 "ant design table column width not working" → 发现 scroll.x: 'max-content' 会让浏览器忽略 width 3. 定位:scroll.x 是根因 4. 修复:scroll.x 改成列宽总和 5. 验证:所有列都能正常拖拽 总耗时:10 分钟(而不是 N 小时)
禁止不观察就动手改代码 禁止不理解机制就引入新库 禁止修复失败后继续猜测打补丁 禁止改了生效但说不清为什么 禁止跳过验证步骤直接提交
UI 问题 → DevTools 观察 → 理解机制 → 定位根因 → 最小修复 → 验证 ↑ | └────────── 失败则回到这里 ──────────────┘
Code helpers, APIs, CLIs, browser automation, testing, and developer operations.
Largest current source with strong distribution and engagement signals.