01 认知带宽的泄露：为什么单屏是程序员的隐形负债
1.1 那个让我崩溃的下午
去年 Q3，我在家办公做一个企业级中后台项目，技术栈是 React + TypeScript + Ant Design。项目到了联调阶段，一个表单组件在提交时白屏，只在生产环境复现，本地完全正常。
白屏原因是什么？是某个字段校验导致的无限循环？还是异步请求后 setState 时组件已卸载？或者是 Webpack 打包后某个 polyfill 没生效？
我当时的屏幕布局是这样的：13 寸 MacBook Pro，IDE 占全屏。排查过程像一场噩梦：
- 切到 Chrome 看白屏报错 → 控制台只报了一个模糊的 TypeError
- 切回 VS Code 看组件源码 → 怀疑是 useEffect 依赖数组漏了某个状态
- 切到 Chrome DevTools 的 Network 面板 → 接口返回正常，不是后端问题
- 切到 Elements 面板检查 DOM 结构 → 发现某个条件渲染分支在特定数据下返回了 null
- 切回 VS Code 改代码 → 加了个兜底判断，重新打包
- 再切到 Chrome 刷新测试 → 还是白屏，刚才的判断没走对分支
每个窗口我都认得，但组合在一起就成了一团乱麻。最后发现问题其实很简单：某个表单项的 name 字段包含了点号（user.name），Ant Design 的 Form.Item 在特定版本下对这种嵌套字段的校验处理有 bug。但找到这个答案花了我 4 个小时------其中至少 2 小时在切窗口、等 Chrome 刷新、重新定位刚才看到的报错信息。
那天晚上我装了 ManicTime。统计结果：下午 2 点到 6 点，我按了 Alt+Tab 847 次。
1.2 认知负荷理论：我们的大脑不是多核 CPU
认知心理学里有个概念叫 Cognitive Load Theory（认知负荷理论），由 John Sweller 在 1988 年提出。核心观点是：人脑的工作记忆容量极其有限，同时处理多个信息源时，认知负荷会指数级上升。
前端开发者的日常工作恰恰是高认知负荷的典型场景：
- 写组件：需要同时维护 JSX 结构、CSS 样式、TypeScript 类型、组件状态逻辑
- UI 调试：需要在浏览器渲染结果、DevTools 元素树、Console 报错、Network 请求之间来回对照
- Code Review：需要理解设计稿意图、组件接口设计、样式隔离方案、与现有业务组件的兼容性
单屏工作的问题在于，所有这些信息源被迫共享同一个视觉空间。每次切换窗口，大脑都需要：
- 识别 --- 当前屏幕显示的是什么（代码？日志？文档？）
- 定位 --- 我上次在这个窗口看到了什么内容？
- 关联 --- 当前窗口的内容和其他窗口的信息有什么关系？
- 决策 --- 基于这些关联，下一步该做什么？
这四个步骤，每一次切换都在重复。按 800 次 Alt+Tab 算，就是 3200 次认知操作。我们的大脑不是多核 CPU，没有超线程，没有分支预测------它就是一块单核单线程的 CPU，还被强制插入了 3200 次上下文切换。
1.3 空间记忆：被忽视的编程超能力
人脑有一个被严重低估的能力：空间记忆（Spatial Memory）。
想想我们是怎么记住家里东西放在哪里的。我们不用想"遥控器在沙发左边第三个靠垫下面"------我们的身体直接知道去哪找。这就是空间记忆在起作用：大脑把物品和物理位置绑定，回忆时不需要检索，只需要"导航"。
多屏编程的核心原理正是利用空间记忆。当我们把不同功能固定在屏幕的物理位置时：
- Chrome DevTools 永远在左侧竖屏下方 → 调试 DOM 和 Network 时手不用想，眼睛直接落过去
- 设计稿固定在右侧横屏上方 → 对像素时肌肉记忆直接切过去
- VS Code 主窗口在右侧横屏中央 → 写代码的主战场，永远不会迷路
这种模式一旦建立，信息获取从"检索"变成"导航"，认知负荷大幅降低。Gloria Mark 博士在 UC Irvine 的研究发现，知识工作者每次被打断后，平均需要 23 分钟 才能恢复到之前的心流状态。多屏布局的意义不是让我们更快，而是让我们更不容易被打断------因为信息就在那，不需要"切换"去获取。
1.4 心流状态的守护
Mihaly Csikszentmihalyi 提出的心流理论（Flow State）描述了一种完全沉浸、高度专注的心理状态。在心流中，时间感消失，自我意识降低，创造力爆发------这是程序员写出最佳代码的状态。
心流有一个很脆弱的前提：持续的、不被打断的注意力。每次 Alt + Tab，都是一次潜在的打断。不是视觉上的打断（切窗口很快），而是认知上的打断------我们在提醒大脑"注意，环境变了"。
多屏工作流的价值，本质上是在守护心流。当我们把所有需要的视觉信息平铺在物理空间中，我们就不再需要"切换"------我们只需要"看"。从"切换"到"看"，是质变。
02 显示器进化论：从盲选到精准匹配的五年踩坑史
2.1 第一台显示器："有个大的就行"
2017 年，毕业工作的第二年，我第一次买外接显示器。当时的认知很朴素：笔记本屏幕太小，买个大点的就行了。
当时花了 899 在某东买了一台 24 寸 1080P，IPS 面板，品牌不说了。刚用上确实爽------窗口能展开了，不再像沙丁鱼罐头。但三个月之后，问题开始浮现：
- 竖屏？ 支架不支持旋转，我试了把它侧放，底座不稳差点摔了
- 看代码： 24 寸 1080P 的 PPI 只有 91，dark 主题下字体发虚，看久了眼睛酸
- 多窗口： 24 寸分两个窗口，每个只有 12 寸，比笔记本还小
- 接口： 只有 HDMI 和 VGA，MacBook 还要接扩展坞
这台显示器用了 8 个月，最后 200 块在闲鱼出了。我总结的第一个教训：买显示器不是买"更大"，是买"更匹配我们的使用场景"。
2.2 第二台显示器：4K 的陷阱
2020 年，我升级到了 27 寸 4K。当时想的是：4K 总够了吧，像素密度 163 PPI，字体肯定清晰。
清晰度确实好了。但新的问题出现了：
- Mac 下需要开 HiDPI（Retina 模式），不然 UI 元素太小。开了之后实际渲染分辨率是 1920×1080------那我买 4K 的意义是？
- 4K 面板在 dark 主题下发灰，黑色不够黑，对比度一般
- 价格贵了一倍，但编程体验提升不到 20%
- USB-C 没有反向供电，MacBook 还要额外接充电器
4K 对设计师来说是刚需，但对程序员来说，性价比曲线在 2K（2560×1440）处达到拐点。 27 寸 2K 的 PPI 是 109，在 60cm 的视距下字体清晰又不至于太小，刚好是甜点区。
这台 4K 屏用了 14 个月，最后送给做 UI 的同事了------对他来说，4K 才是刚需。
2.3 寻找"第三块屏"：需求清单的进化
经过两台显示器的折腾，我的需求清单变得具体而苛刻：
- 27 寸 2K，PPI 109 左右，字体清晰不发虚
- 支架支持旋转，竖屏编码是刚需
- 雾面屏/抗反射，书房窗户在侧面，下午阳光直射
- USB-C 一线通，反向供电至少 60W
- 护眼认证，干眼症是程序员的职业病
- 高刷新率，滚长日志时不头晕
带着这个清单，我看了 Dell U2722D、LG 27UP850、BenQ RD270Q。最后选 RD270Q 的原因很简单：它是唯一一个把"编程"当作核心场景来设计的显示器，而不是"通用显示器也能写代码"。
图 1：RD270Q 的 OSD 菜单可以直接切换编码模式，支持亮色/深色主题自适应。这是我在其他显示器上没见过的设计。
03 空间锚定：多屏工作流的认知架构设计
3.1 什么是空间锚定
空间锚定（Spatial Anchoring） 算是我自创的术语（在心理学上也有这个术语，但是不是这个意思，但是拿来这里用挺合适的），用来描述一种工作流设计方法：把不同类型的信息固定在屏幕的物理位置上，让大脑建立"位置-功能"的条件反射。
这个概念来自两个认知科学原理：
- 空间记忆（Spatial Memory）： 人脑对物理位置的记忆远比抽象标签牢固。我们把钥匙放在玄关，不需要想"钥匙在玄关"------我们的身体直接知道去哪找。
- 习惯性动作（Habitual Action）： 当一个动作重复足够多次，它会从"有意识控制"变成"自动化执行"。新手司机换挡要看档杆，老司机手自动到位------这就是习惯性动作。
空间锚定的目标，是让信息获取从"有意识检索"变成"自动化导航"。
3.2 我的双屏空间锚定方案
我的桌面配置是经过多次迭代后的"最终形态"：
图 2：左侧 RD270Q 竖屏（认知锚点区）+ 右侧横屏（执行区）。竖屏在左、横屏在右，是经过三次调整后的最优布局。
左侧竖屏（RD270Q）：认知锚点区
竖屏是我的"认知锚点"------它承载主要的编码工作，并作为稳定的信息底座。
- 上半屏： 项目目录树 + Git 状态，或者 Figma 设计稿对照
- 中间： 当前关注的组件源码（竖屏一屏能看 80-100 行）
- 下半屏： Chrome DevTools（Elements + Console），常驻调试面板
竖屏的价值在于"纵向视野"。一个典型的使用场景是读开源组件库源码：左侧竖屏展开目录树，找到目标组件后直接在中间打开，不需要来回切换。读 200 行的 hooks 实现，竖屏一屏看完，横屏可能需要滚 3 次。
右侧横屏：执行区
- 主 IDE 窗口（VS Code）：写组件的主战场
- 浏览器窗口（Chrome，用于实时预览和 DevTools detached 模式）
- 偶尔放文档、Notion 笔记或腾讯会议窗口
右侧横屏是"动态区"------内容根据当前任务变化。但有一个原则：同一时间最多两个窗口。 三个以上窗口并排，每个都太小，反而不如单屏。
3.3 四个典型工作流场景
场景一：组件开发与 UI 调试
这是前端收益最高的场景。开发一个复杂表单组件时，我的布局：
- 左侧竖屏上半：组件源码（看 props 定义和内部状态逻辑）
- 左侧竖屏下半：Storybook 或本地页面预览（实时看渲染效果）
- 右侧横屏左 2/3：VS Code 主窗口（写组件代码）
- 右侧横屏右 1/3：Chrome DevTools（调样式、看 Console 报错）
这个布局让我能在改完 CSS 后 0.5 秒内看到效果，不需要 Alt+Tab。开发一个包含 20 个字段的表单，效率提升大概 40%------不是因为写得更快，而是因为"改-看-调"的循环不需要切窗口。
场景二：还原设计稿
前端最痛苦的任务之一：设计师说"这里差 1px"。对像素时需要同时看：Figma 设计稿、浏览器渲染结果、DevTools Computed 面板、组件源码。
- 左侧竖屏上半：Figma 设计稿（放大到 100% 对照）
- 左侧竖屏下半：浏览器预览（同屏对比设计稿和实现）
- 右侧横屏：VS Code（调 CSS）+ DevTools（看 Computed 值）
这个时候我发现： 设计稿和浏览器必须同时在视野内。单屏下只能来回切，眼睛在"设计稿什么样"和"我实现了什么样"之间不断 refocus，非常累。
场景三：Code Review
Review 前端 PR 时信息密度很高：TS 类型定义、组件接口、样式变更、逻辑改动。
- 左侧竖屏：Git diff（竖屏看 50+ 行变更，一屏抓住重点）
- 右侧横屏左 2/3：被修改的源文件
- 右侧横屏右 1/3：把分支切出来跑 Storybook 预览实际效果
竖屏看 diff 的优势是：一个 styled-components 的改动可能很长（嵌套 CSS），竖屏一屏看完，不用来回滚。
场景四：Debug 马拉松
最考验多屏价值的场景。线上白屏 / 样式错乱 / 性能卡顿，需要同时看：Sentry 报错、用户录屏、本地复现、代码。
- 左侧竖屏：Sentry 报错详情 + 用户操作录屏
- 右侧横屏左半：VS Code（定位问题代码）
- 右侧横屏右半：Chrome DevTools Performance 面板（分析渲染瓶颈）
Debug 时每一秒都很宝贵。多屏不是让我们更快找到 bug------是让我们不会因为"找不到信息"而焦虑。
图 3：深夜双屏协作------左侧 RD270Q 竖屏跑 AI 对话和日志监控，右侧横屏 diff 代码。这是我最近居家远程办公最常见的工作状态。
图 4：白天双屏工作流------左侧 RD270Q 竖屏看代码结构，右侧横屏写代码。
04 RD270Q 深度体验：一台"懂"编程的显示器
这一章我想从技术细节和实际体验两个维度，聊聊 RD270Q 到底"好在哪"。我不想列参数------去京东详情页看就行了。我想聊的是：这些参数在实际编程场景中，到底转化成了什么体验。
4.1 编码模式：不只是"调亮度"
RD270Q 内置了几种专业模式，其中"编码模式"（Coding Mode）是最让我意外的。
我一开始以为这只是一个营销概念------把对比度拉高一点，然后说"专为编程优化"。但真正对比后，发现不一样。
普通模式看深色主题（比如 VS Code 的 One Dark Pro），时间长了会有种"糊"的感觉------关键字和变量名的对比度不够，注释和代码之间的层次不分明。编码模式打开后，变化很微妙但可感知：
- 关键字（if/for/return 等）的辨识度提升，扫代码时更容易抓住结构
- 字符串字面量的对比度更高，一眼区分开
- 注释暗下去但不至于看不清，不会和代码"抢注意力"
- 整体画面从"flat"变成"layered"，像给代码做了语法高清的二次渲染
我专门做了一个 A/B 测试：同一个文件，编码模式 vs 标准模式，连续看 2 小时。编码模式下眼睛疲劳感明显更轻------不是因为亮度变了，而是因为对比度设计减少了眼睛的"解析负担"。
图 5：RD270Q 深色主题下的编码模式。对比度分层让代码结构一目了然，长时间阅读不容易疲劳。
4.2 144Hz：程序员也需要高刷
144Hz 对游戏玩家来说是刚需，但对程序员呢？
我的答案是：不是刚需，但用了就回不去。
场景一：长列表滚动调试。 做虚拟列表优化时，需要在 Chrome DevTools 里快速滚动几百条 DOM 节点看渲染性能。60Hz 下快速滚动，节点有拖影，定位具体元素时眼睛容易晕。144Hz 下滚动是连贯的，文字不会"撕裂"，长时间调试的舒适度提升明显。
场景二：多窗口动画。 macOS 的 Mission Control 动画、窗口切换的过渡效果，在 144Hz 下更流畅。这些"小流畅"积累起来，整体操作的"跟手感"好很多------写代码时"顺不顺手"会直接反映在心情和效率上。
场景三：鼠标移动。 高刷让鼠标指针的移动更顺滑，精准定位时更跟手。做 UI 还原时经常要精确点击像素级边界，这个提升每天累积下来，手部的疲劳感会降低。
4.3 彩纸模式：把屏幕变成纸
除了阅读文档，RD270Q 的彩纸模式（ePaper Mode）在编码场景下同样有意想不到的价值。
很多程序员以为彩纸模式只是给文字阅读用的，但我在实际写代码时发现，它解决了一个被忽视的问题：深色主题下的"发光感"疲劳。普通模式下，VS Code 的深色背景虽然对比度高，但长时间注视后，屏幕像一块发光的黑板，代码文字仿佛悬浮在光层之上，眼睛需要不断对抗背光的刺激。 彩纸模式打开后，背景不再是纯黑的发光板，而是呈现出类似米黄色纸张的质感。代码文字从"发光"变成了"印刷"------像看一本技术书籍的内页，而不是盯着一块电子屏。
图 6：彩纸模式下的阅读效果。RD270Q 的颜色优化在彩纸模式下有明显的效果，字体和图片的层次分明。
4.4 护眼：干眼症患者的自救指南
我有轻度干眼症，这是程序员的职业病。之前每天下午 4 点准时眼睛干涩，眼药水是标配。
RD270Q 过了六大护眼认证（TÜV 无闪烁、防反射、低蓝光、Eye Comfort 2.0、Eyesafe 2.0），但说实话我买东西不看认证------我看实际体验。
最直观的改变是抗反射面板。 我的书房朝南，下午 3-5 点阳光直射桌面。之前的显示器（光面屏）变成镜子，代码几乎看不清，只能拉窗帘。RD270Q 的雾面抗反射面板，同样的光照条件下，屏幕内容依然可读------不是"完全没反光"，而是反光被散射了，不会形成刺眼的亮点。居家办公没有公司那种遮光帘，抗反射面板对我来说是刚需。
图 7：雾面抗反射面板将光源反光散射为柔和的光晕，屏幕内容始终清晰可读
图 8：普通光面屏则产生强烈的镜面反射，形成刺眼的亮斑，亮斑区域的代码几乎无法辨认
抗反射面板（上）与普通光面屏（下）的侧光直射对比。在相同的光照条件下，RD270Q 的雾面抗反射面板将光源反光散射为柔和的光晕，屏幕内容始终清晰可读；而普通光面屏则产生强烈的镜面反射，形成刺眼的亮斑，亮斑区域的代码几乎无法辨认。如果办公场地没有遮光帘，这种差异直接决定了在光照强时是否能正常编码。
夜间防护模式（Night Hours Protection） 是我每天必用的功能。普通显示器的最低亮度对深夜环境来说还是太亮，而这个模式可以把亮度压到极低，同时保持文字可读。家人睡下后我继续写代码，屏幕不会亮得"把房间照亮"，配合桌上的显示器挂灯，深夜编码的舒适度提升不止一个档次。
智慧调光（Brightness Intelligence Gen2） 是个"润物细无声"的功能。传感器在屏幕下方，实时检测环境光并自动调整亮度和色温。从下午到深夜，屏幕亮度自然过渡，不会出现"突然亮一下"的惊吓。居家办公的光线环境变化比办公室大得多（阴天、晴天、开灯、关灯），智慧调光在这种多变环境下反而比办公室更实用。
图 9：深夜编码场景。RD270Q 夜间防护模式 + 屏幕挂灯，凌晨修 bug 眼睛不会被亮醒。
4.5 人体工学：被低估的生产力因素
程序员的职业病列表很长：颈椎痛、肩周炎、干眼症、腱鞘炎......其中至少一半和显示器的人体工学设计有关。
RD270Q 的支架支持：
- 高度调节 150mm： 找到视线和屏幕中心平齐的位置，减少低头/仰头
- 旋转 ±90°： 竖屏编码的物理基础
- 俯仰调节： 适配不同坐姿
- VESA 壁挂： 如果桌面空间有限，可以上显示器支架臂
我花了两周时间调整显示器的高度和角度，最终找到最舒服的位置：屏幕顶端和眉毛平齐，视线自然落在屏幕上半部分。这个姿势下，颈椎处于中立位，连续工作 4 小时不会有明显的颈部疲劳。
4.6 USB-C 一线通：桌面洁癖的救赎
一根 Type-C 线连接 MacBook：65W 反向供电 + 视频传输（DP Alt Mode）+ USB Hub，三合一。
桌上少了：一个充电器、一根 HDMI/DP 线、一个 USB Hub。我数了一下，相比之前的桌面，少了 3 根线、1 个充电器、1 个扩展坞。桌面干净程度 +50%，心情清爽程度 +100%。
RD270Q 的接口配置：HDMI 2.0 ×1、DP 1.4 ×1、USB-C（PD 65W）×1、USB 3.2 Hub（下行）×4。对于程序员来说，USB-C 上行 + 4 个 USB 下行口意味着：键盘、鼠标、U 盘、外接硬盘全部接在显示器上，MacBook 只需要一根线。
需要带走笔记本时，拔一根线就行------这种"一键 disconnect"的体验，用过就回不去了。
图 10：OSD 菜单切换不同模式。编码模式写代码，标准模式看设计稿，游戏模式偶尔放松一把。
05 Display Pilot 2：被低估的软件生态
大多数显示器厂商对"软件"的理解是：给我们个驱动光盘（现在连光盘都没有了），安装完能在系统里调调亮度，完事。
明基的 Display Pilot 2 不一样。它是一个完整的显示器管理软件，支持 Windows、macOS、Linux 三大平台------这在显示器厂商里真的不多见。很多品牌只给 Windows 驱动，Mac 和 Linux 用户被直接放弃。
5.1 FLOW：自动化工作流的核心
FLOW 是我使用率最高的功能。它的逻辑很简单：根据当前激活的应用程序，自动切换显示模式。
我的配置： 
图 11：不同的 FLOW 模式可以切换不同的应用，在实际工作中还是比较实用的
- VS Code / WebStorm → 自动切换编码模式
- Chrome / Safari → 切换标准模式（网页色彩更准确）
- Terminal → 切换深色模式（终端通常黑底白字，深色模式对比度更合适）
- 视频播放器 → 切换 HDR 模式（如果有 HDR 内容）
这个自动化省了多少心？粗略估算：每天切换应用 100+ 次，每次手动调模式需要 3-5 秒（点托盘图标 → 选模式 → 确认），FLOW 全自动，零操作。一天省 5-8 分钟，一年就是 30+ 小时------相当于多出了 4 个工作日。
更关键的是：不需要记着调。以前经常出现的情况是------从 IDE 切到浏览器查文档，忘了调模式，看了 20 分钟才发现屏幕太亮/太暗，眼睛已经不舒服了。FLOW 消除了这种"人为失误"。
5.2 桌面分区：窗口管理的物理法则
桌面分区（Desktop Partition）把屏幕划分成预设的区域，拖窗口时自动吸附。
我的双屏分区方案：
图 12：不同的窗口进行分区，工作起来就更有条理，也不需要再切来切去，一目了然
- 右侧横屏：左 1/2（文档/设计稿/博客等）+ 右 1/2（Chrome 预览/DevTools）
- 左侧竖屏：上 1/2（VS Code 主窗口） + 下 1/2（Iterm）
这个功能和 macOS 的 Magnet 或 Windows 的 PowerToys FancyZones 类似，但有两个优势：一是和显示模式联动（分区布局可以和编码模式同时切换），二是对竖屏的分区支持更好（很多第三方工具对竖屏的分区比例处理得不好）。
06 多屏工作流构建指南：从 0 到 1 的实操手册
这一章是给想搭建多屏工作流但不知从何下手的人的实操指南。我不会推荐具体品牌，只给方法论------根据自己的预算和需求填空。
6.1 第一步：分析你的工作流
在买任何硬件之前，先花一周时间观察自己的工作习惯。记录：
- 每天最常用的 3-5 个应用程序是什么？
- 哪些应用经常需要同时看？（比如 IDE + 浏览器、终端 + 日志）
- 你在什么任务上花费时间最多？（编码、Debug、Code Review、学习）
- 你的主要痛点是什么？（窗口太小、切来切去、眼睛疲劳、脖子酸）
可以用 ManicTime、RescueTime 或简单的 Excel 记录。数据不需要精确，关键是建立对自己工作模式的认知。
6.2 第二步：确定显示器配置
根据工作流分析，选择显示器配置：
单屏升级（预算 1000-2000）
如果你现在的主要痛点是"屏幕太小"，先升级到 27 寸 2K。竖屏功能强烈建议上------即使你现在觉得不需要，用惯了之后就回不去了。
双屏配置（预算 2500-4500）
推荐一竖一横。竖屏放左侧（目录树、文档、终端），横屏放右侧（IDE、浏览器）。两块屏可以同型号，也可以不同------竖屏对色彩要求不高，可以选便宜点的；横屏是主战场，建议选好的。
三屏及以上（预算 5000+）
三屏的边际收益递减。除非你有特殊需求（比如同时看大盘、监控、代码），否则双屏已经覆盖了 90% 的场景。三屏更适合特定职业：量化交易、运维 NOC、视频剪辑。
6.3 第三步：规划屏幕布局
屏幕布局不是随意的，要遵循几个原则：
- 主屏在正前方 --- 你视线自然落到的位置。通常是横屏，放 IDE。
- 辅助屏在侧面 --- 视线需要轻微转动才能看到。通常是竖屏，放参考信息。
- 屏幕顶部和眉毛平齐 --- 颈椎处于中立位，减少低头。
- 两块屏的间距保持一致 --- 鼠标跨屏移动时不会"跳"。
- 留出台灯/挂灯的位置 --- 深夜编码需要环境光，不要屏幕正对光源。
6.4 第四步：配置软件工作流
硬件到位后，软件配置决定了效率天花板：
- 窗口管理： Mac 用 Magnet/Raycast，Windows 用 PowerToys FancyZones，Linux 用 i3/sway（tiling WM 本身就是为多屏设计的）
- 自动化： Keyboard Maestro（Mac）、AutoHotkey（Windows）、xdotool（Linux）------用快捷键一键排列窗口
- 显示器管理： Display Pilot 2（明基）、MonitorControl（Mac 开源）、ClickMonitorDDC（Windows）
- 护眼： f.lux 或 Windows Night Light，配合屏幕挂灯使用
一个我常用的自动化脚本：按一个快捷键，自动把 IDE 放到右侧横屏中央、终端放到左侧竖屏下方、浏览器放到右侧横屏右 1/3。整个布局 1 秒完成，不需要手动拖窗口。
6.5 第五步：养成习惯
硬件和软件都配置好了，最后一步是养成使用习惯。多屏工作流的核心不是"有更多屏幕"，而是"把信息放在固定的位置"。
前两周会有不适应------你可能会发现自己在找窗口时犹豫了（"刚才那个文档放在哪个屏来着？"）。这是正常的。坚持两周后，大脑会建立空间记忆，信息获取变成自动化过程。
一个月后，你会发现自己单屏工作时有种"局促感"------像从别墅搬回了单间。这时候你就知道，多屏工作流已经内化了。