No. 29: 我用油猴脚本给常用网页补了一层自己的体验
从 X 阅读增强到 2Libra 双栏布局，我把反复出现的网页体验摩擦写成了一个低权限、无构建的用户脚本仓库。
2026.08.10
我每天会反复打开几个固定网站。它们的功能没有坏，信息也都在那里，但页面总有一些细小的摩擦：主内容太窄，右栏占着视线，浮动按钮挡在角落，帖子和回复之间的节奏也不适合长时间阅读。
这些问题小到不值得等待平台重做，又稳定到每天都能遇见。最早我只是给 X 写了几段 CSS，后来又为 2Libra 调整双栏和内容密度。等脚本变成两个，安装、来源和验证方式也需要被认真管理，我干脆把它们整理成了一个 Tampermonkey 仓库。
我想保留网页原有的能力，只把每天重复承受的体验摩擦拿掉。
第一个脚本只解决 X 的阅读问题
X 阅读增强做的事情很克制。它隐藏右侧推荐栏和右下角浮动控件，加宽并居中信息流，调整正文行高、页面间距和媒体高度，同时保留左侧导航、发帖和互动等原有能力。
脚本同时匹配 x.com 与 twitter.com，只申请 GM_addStyle。它不拦截请求，不读取账号数据，也不试图接管网站业务。安装后如果不喜欢，关闭脚本就能回到原来的页面。
这种边界对个人工具很重要。网页样式可以大胆调整，数据和业务行为却不该因为一次阅读偏好被卷进来。
到了 2Libra，问题不再只是补几段 CSS
2Libra 的需求更具体。我希望宽屏下拥有接近 V2EX 的阅读节奏：主栏足够承载帖子，右侧保留个人信息与辅助内容，列表、详情、回复和编辑器之间有一致的密度。
最后的布局约为 805 px 主栏加 270 px 侧栏，中间留 25 px 间距。帖子列表、正文、回复卡片、个人区域和评论编辑器分别调整，但窄屏下必须回到单栏，不能为了桌面端好看破坏移动端。
这里遇到的麻烦是，目标页面会局部更新 DOM。只在首次加载时查一次元素并不可靠，所以脚本会先找到帖子列表、正文或回复作为锚点，再给页面真实结构标记自己的语义类名。MutationObserver 发现页面变化后不会立刻反复执行，而是通过 requestAnimationFrame 合并这一帧内的更新，再重新确认布局。
这仍然是一个很小的脚本，但它已经需要考虑输入、状态变化、失败退出和响应式恢复，不能只靠一张改完后的截图证明可用。
用户脚本的完成标准在真实页面里
这个仓库没有包管理器，也没有构建步骤。每个 .user.js 文件既是源码，也是可以安装的产物。少了一条构建命令，不代表少了验证。
X 阅读增强需要在 1280、1440 和 1920 像素宽度下检查首页、个人主页与帖子详情，确认主栏变宽以后，导航、站内跳转和核心交互仍然存在。2Libra 脚本除了 1440、1920 像素宽屏，还要检查 375、768 像素窄屏，避免双栏规则压坏移动端。
网页本身还会持续更新。今天稳定的类名和结构，之后可能失效。脚本必须能在找不到目标节点时安全退出，匹配范围也要尽量窄，不能为了省事把权限扩展到所有网站。
代码能执行只是起点，页面变化之后仍然可读、可操作、可关闭，才是这类工具的完成标准。
收录参考脚本时，来源要比数量清楚
仓库后来收录了一份 V2EX Polish 2.0.6 的上游脚本快照。它给 2Libra 的排版提供了参考，但它不是我的作品。
所以 README 把 3 个脚本条目分成两类：X 阅读增强和 2Libra 双栏是自有脚本，V2EX Polish 是第三方快照。后者保留上游作者与 MIT 许可证信息，也明确提示安装和更新优先前往上游项目。
这看起来只是文档里的几行字，却决定了仓库有没有把别人的工作包装成自己的成果。个人项目规模再小，来源、许可证和维护责任也应该说清楚。
一个仓库开始有了自己的边界
这次整理还补齐了中英文 README、原始脚本安装入口、Claude Cream 风格的 Logo 与仓库横幅。它们没有让脚本多出新功能，但让别人第一次打开仓库时，能看懂这里有什么、哪些可以直接安装、每个脚本申请了什么权限，以及出现问题后应该去哪里检查。
我没有把它做成脚本市场，也没有增加打包工具、自动发布和复杂抽象。当前最简单的工作流仍然是编辑脚本，在 Tampermonkey 或 Violentmonkey 里更新，打开匹配页面，硬刷新并检查真实行为。
以后是否继续增加脚本，只看我是否遇到新的高频问题。每个脚本仍然只服务一个站点或一件明确的事，权限保持最小，关闭后可以恢复原状。
个人工具的价值不在于做得多，而在于把一件每天重复发生的小事，改成自己愿意长期使用的样子。
Vibe Coding 项目页：Tampermonkey Scripts