在前端开发中，Skeleton（骨架屏）是提升用户感知性能的重要手段。常见做法是单独写一套灰色占位组件，但这种方法存在一些明显的问题： 骨架屏和真实 UI 结构脱节，修改 UI 需要额外同步 Skeleton； 文字行高和布局难以精准还原，容易出现错位； 页面渲染过程中容易出现布局抖动（CLS）。 本文分享我在组件库中对骨架屏的思考，以及如何通过与组件耦合的方式实现精准还原。 --- 传统 Skeleton 的问题 常见的实现方式是页面层写一套假的 Skeleton，例如： 这种方式存在几个问题： 结构脱节 骨架屏和真实组件是两个平行的版本，修改组件必须同步改 skeleton。 布局不精确 文字、行高、padding、响应式高度等都可能不一致，导致骨架屏和实际内容错位。 维护成本高 组件库或页面升级时，需要额外维护 skeleton 组件。 --- 我的方法：Skeleton 与组件结构耦合 我的核心思路是： 骨架屏应该是组件的一种状态，而不是独立组件。 实现方式： 在组件内部提供 属性； Skeleton 结构与真实 DOM 一致，

这两天我在本机里注意到了一个目录：。 打开一看，里面是一个非常熟悉的结构： 第一反应很自然： 这是不是某种通用的 Agent 规范？如果我写一套 skills，是不是 Codex、Claude Code、Cursor 都能直接吃？ 答案是： 方向上越来越接近“通用”，但现实里还没有通用到可以完全无脑互换。 这篇文章就聊清楚三个问题： 到底是什么 为什么越来越像跨客户端的共同格式 Codex、Claude Code、Cursor 真正的兼容差异到底在哪 先说结论：它更像“开放约定”，不是“统一标准” 如果你去看本地的 skill 文件，大概率会发现两件事： 每个 skill 都是一个独立目录 核心入口是 有些 skill 里还会附带： 文档 示例代码 辅助脚本 模板文件 这说明它本质上不是一个“只写 prompt 的文本片段”，而是一个更接近“可复用能力包”的东西。 但这里要注意一个非常重要的区分： 是技能描述格式 是某些客户端约定会去扫描的目录 这两层不要混在一起。 很多人会误以为： 只要目录叫 ，所有 Agent 客户端就都会自动识别。

最近我在琢磨一件很具体、但又挺容易让人踩坑的事： 能不能给 、、 这些编程代理客户端，设计一套统一的 prompt 约束注入机制？ 更直白一点说，就是我们能不能只维护一份类似 的文件，然后让不同客户端在 session 初始化时都自动加载它？如果能，这件事会非常省心。团队可以有统一规范，个人也能有统一偏好，不用在每个客户端里重复维护一遍。 我先说结论： 没有一个被这三家共同官方约定的“统一文件标准”。 但它们的机制已经足够接近，完全可以通过一层很薄的适配，把这件事做成。 这篇文章就梳理一下三家的官方机制、它们的差异，以及我最终更推荐的一套落地方案。 先说结论 截至 ，如果问题是： 有没有一个像 这样的通用标准文件，可以被 Codex、Cursor、Claude Code CLI 一起原生自动加载？ 我的答案是： 没有跨客户端统一标准。 Codex 和 Cursor 都支持 ，但支持方式不完全一样。 Claude Code 的主机制不是 ，而是 。 如果想统一维护，最稳的办法不是赌一个文件名通吃，而是“单一真源 + 各端适配层”。 也就是说，

[](https://github.com/Hexi1997/agent-root-cli) 是一个很小的 CLI，用来解决一个很具体的问题： 如果同时在用 、、，全局指令应该维护在哪一份文件里？ 这类指令通常都比较稳定，比如： 默认用中文回答 改代码前先读上下文 commit 前先确认 搜索优先用 它们更像是长期工作流配置，而不是某次对话里的临时 prompt。 问题是，不同工具的接入方式并不一样： 使用 主要使用 主要使用 结果就是，同一套规则很容易被维护成几份，时间一长还会分叉。 这个项目做了什么？ 的做法很直接： 保留一份源文件，再把不同客户端接到这份源文件上。 默认约定如下： 源文件： Codex： Claude： Cursor：手动创建一条 User Rule，指向 这样一来，真正需要编辑的就只有 这一份。 怎么用？ 先安装： 初始化源文件： 建立链接： 如果只想先预览，不想直接写入文件，也可以用： 完成后，Codex 和 Claude 会共享同一份源文件内容；Cursor 只需要手动配一条 的 User Rule，也能接入这套规则。

今天刷 GitHub 的时候，发现一个老朋友终于被关掉了。 这个 Issue 是 2021 年 2 月创建的，讨论的是一个很离谱的问题： 这个 Hook，居然不是在 install 之前执行的。 按名字理解， 不应该是先执行吗？ 结果 npm 7 开始，它变成了依赖安装完成后才执行。 我第一次知道这个 Issue 是在 2022 年做项目的时候。 当时项目里刚好踩到了这个坑。 查了半天，最后一路顺藤摸瓜找到了这个 Issue。 点进去一看，好家伙，已经有人在 2021 年提出来了，而且还被打上了 Bug、Priority 1、High Priority 等标签。 看到这里，我心想： 既然都已经确认是 Bug 了，那应该快修了吧？ 于是顺手在评论区留了一句： Why not fix this bug instead? 然后继续干活去了。 后来几年里，我偶尔会想起这个问题，然后点进去看看。 结果每次看到的都是： Open. 还是 Open. 依然 Open. 时间久了甚至开始怀疑： 这不会要变成 npm 的历史遗留问题了吧？ 结果前几天再打开的时候，