很长一段时间里我用 Codex 的方式都是“一条终端窗口丢到隔壁桌面自己在编辑器里看代码”。单次小任务还好一旦任务变长问题就来了我记不清当前进度到哪了也不知道现在该不该切回终端确认。最后的结果就是每隔几分钟切一次窗口每次切完还得花几秒重新找上下文。后来我做了一个小工具让一个辅助窗口跟着 Codex 走窗口停在会话旁边内容跟着任务状态刷新。这个改造看起来不起眼但它确实改变了我做长任务时的方式。这篇文章想把这段实践拆开说明白——不只是分享一个窗口小工具而是讲清楚“跟随窗口”到底要解决什么问题怎么做才不至于变成一个华而不实的玩具。我把这段经历沉淀下来的核心判断写在前面跟随窗口的真正价值不是“窗口会跟着动”而是让注意力不再需要频繁离开主任务。1. 先想清楚你要的到底是“窗口跟着 Codex 走”还是“注意力跟着任务走”1.1 一次真实的使用场景Codex 跑任务时我为什么总在切窗口假设你在用 Codex 重构一个模块。它会读取代码、改文件、跑测试、根据报错继续修。作为使用者你并不是全程盯着终端你还需要在编辑器里看它改过的代码在终端里观察它的执行过程在日志或输出里确认任务进度在文件列表里核对变更。这些信息分布在好几个软件里。正常情况下不觉得有什么问题但任务一长窗口切换就不再是一个操作问题而是一个认知问题。每次切换你都要回答一遍“我刚才看到哪了”“它现在在做什么”“我要不要等它”。这三个问题反复出现注意力就被打散了。我比较早意识到这一点是因为一次批量重构任务Codex 处理了十几个文件我在编辑器、终端、日志文件之间来回切结果漏掉了一条它停在半路的提示导致后续所有文件都是基于一个错误前提处理的。问题不在 Codex而在我的观察方式不够连续。1.2 两层“跟随”物理位置跟随和内容状态跟随“跟着 Codex 走的窗口”这句话其实藏着两种完全不同的能力。第一层是物理位置跟随。也就是 Codex 主窗口在屏幕上的位置移动时辅助窗口跟着移动始终保持在工作区旁边。第二层是内容状态跟随。也就是 Codex 的任务有了新输出、新进度、新报错时辅助窗口里的内容也会自动更新到最新状态。这两层看起来都是“跟随”实际价值完全不同。物理位置跟随解决的是“窗口该放哪儿”的问题而内容状态跟随解决的是“我现在该关注什么”的问题。后者对注意力的帮助要大得多。我见过不少人的第一反应是去做“让窗口跟着动”因为这件事听起来直观也容易演示。但真正长期用下来你会发现内容状态跟随才是刚需。如果一个窗口只是位置跟着 Codex 走里面显示的却是十分钟前的旧信息那它和一张贴在屏幕上的便签没有本质差别。可以把这个判断抽象成一张表跟随层次要解决的问题核心价值实现复杂度维护成本手工固定窗口窗口放哪降低找窗口的显性成本低低物理位置跟随窗口跟着主窗口停在哪视觉一致性不增加太多价值中中内容状态跟随什么时候该关注什么减少注意力切换和上下文重建中高中两层结合窗口位置和内容都最新真正适合长时间任务高中高所以我的建议是不要一开始就冲去做物理跟随先把内容状态跟随做好你会发现收益已经远超预期。2. 不写代码也能先成立把 Codex 会话和辅助面板固定在同一个工作区2.1 用终端分屏搭一个“Codex 日志面板”的最小结构在做任何自动化之前可以先做一个纯手工方案。它不需要写代码几分钟就能搭好而且能立刻改善窗口切换。类 Unix 系统里我一般会用 tmux。它在终端里把一个会话分成若干个窗格特别适合把 Codex 会话和日志面板放在一起# 新建一个名为 codex 的会话 tmux new -s codex -d # 左右分屏 tmux split-window -h -t codex # 左边跑 Codex右边显示日志 tmux send-keys -t codex:0.0 codex Enter tmux send-keys -t codex:0.1 tail -f /tmp/codex-session.log Enter # 回到会话 tmux attach -t codex这样你的 Codex 交互和日志查看就在同一个终端窗口的两个窗格里不存在两个软件之间的切换。tmux 还有会话持久化能力中途断网、不小心关掉终端重新 attach 就能回到原来的状态。如果你习惯用 Windows Terminal 或 macOS Terminal也可以直接用内置分屏。但 tmux 的优势在于它不依赖具体终端软件而且在服务器上同样好用。Codex 很多时候是跑在远程机器或容器里的这时 tmux 几乎是必选项。2.2 置顶、粘附与固定窗口的适用边界如果你不想用终端分屏而是希望开一个独立小窗口放在 Codex 旁边那就需要“置顶”能力。不同平台做法差别很大Windows 下可以用系统里的窗口管理工具很多工具都支持让某个窗口始终置顶macOS 下可以通过系统自带的窗口置顶能力或借助第三方窗口管理器Linux 下取决于你的窗口管理器部分桌面环境内置“始终置顶”快捷键Gnome/KDE 等也各有方案。我建议不要在这里过度追求统一方案。第一步的目标只是把窗口布局固定下来用什么工具其实无所谓。真正要想清楚的是这个辅助窗口“置顶”的优先级太高会遮挡编辑器太低又起不到效果。通常我会让辅助窗口保持在编辑器右侧宽度约 360 到 420 像素高度跟随主窗口。这样它不占太多空间又能在余光范围内。2.3 手工方案的局限它并不能真正“跟着 Codex 走”手工方案能解决一部分问题但它有一个根本局限布局是你手动固定的而 Codex 跑任务时的状态是动态的。举几个典型情况Codex 突然报错输出里出现一条错误但你的辅助窗口还停留在上一条指令的结果上Codex 切换到另一个目录继续处理你的辅助窗口内容还显示着之前的路径你手动调整主窗口大小时辅助窗口不会跟着自动调整需要再次动手。这些问题不会让任务失败但会持续消耗你的注意力。所以手工方案适合短会话和零散任务不适合长任务。它真正的价值是让你先理解“哪些窗口必须同时可见”再决定要自动化哪一部分。3. 做第一个真正会跟的东西内容状态跟随窗口3.1 设计原则不要改造 Codex去监听它的输出做内容状态跟随窗口时最容易犯的错是想去改 Codex 本身比如想办法拿到它的内部状态、解析它的内部数据结构、或者给它加插件。这通常不值得。一是 Codex 迭代很快内部结构随时可能变二是你改完后要长期维护成本会一直滚下去。更稳的做法是让 Codex 把会话输出落成一个文件然后用一个独立脚本去读文件尾部把新内容推到辅助窗口里。这样 Codex 侧几乎不用动你只需要处理一个文本文件谁都能看懂也最容易调试。在类 Unix 系统里可以用script命令录制终端会话把 Codex 的完整输出写进日志script /tmp/codex-session.log codex执行script后终端会进入录制模式codex启动后所有输出都会同时写入/tmp/codex-session.log。退出 Codex 后再按CtrlD结束录制。这是比较稳妥的通用做法比直接用管道codex | tee更好因为交互式终端里的管道经常会带来输入回显、缓冲和颜色码问题。如果你用的 Codex 本身已经支持日志配置那就更简单了直接把日志文件路径告诉脚本就行。3.2 一个日志跟随窗口的最小实现下面是用 Python 的 Tkinter 写的一个日志跟随窗口。它不依赖太多第三方库逻辑也清楚import os import tkinter as tk from tkinter.scrolledtext import ScrolledText class CodexFollowWindow: def __init__(self, root, log_path): self.log_path log_path self.file_pos 0 self.last_mtime 0 root.title(Codex 跟随窗口) root.attributes(-topmost, True) self.text ScrolledText(root, width100, height30, font(Menlo, 12)) self.text.pack(fillboth, expandTrue) root.protocol(WM_DELETE_WINDOW, self.on_close) self.root root if os.path.exists(log_path): # 如果日志文件已存在直接从末尾开始只显示后面新增的内容 self.file_pos os.path.getsize(log_path) self.poll() def poll(self): try: mtime os.path.getmtime(self.log_path) if mtime ! self.last_mtime: size os.path.getsize(self.log_path) # 如果文件变小说明被截断或轮转了重置到开头 if size self.file_pos: self.file_pos 0 self.text.delete(1.0, end) with open(self.log_path, r, encodingutf-8, errorsignore) as f: f.seek(self.file_pos) new_data f.read() self.file_pos f.tell() self.last_mtime mtime if new_data: # 如果滚动条在底部自动跟随到末尾否则保持用户阅读位置 at_bottom self.text.yview()[1] 0.99 self.text.insert(end, new_data) if at_bottom: self.text.see(end) except Exception: # 日志文件可能存在临时被占用或删除的情况 pass self.root.after(500, self.poll) def on_close(self): self.root.destroy() if __name__ __main__: root tk.Tk() CodexFollowWindow(root, /tmp/codex-session.log) root.mainloop()这里有几个关键点文件指针file_pos是核心。每次只读新增部分而不是把整个日志重新读一遍。日志文件越来越大时这个写法性能才撑得住。mtime 判断用来避免每次轮询都打开文件。虽然这里打开文件的开销不大但写成“文件没变就不读”更干净。遇到文件截断要重置。有些日志工具会做轮转文件大小可能变小如果还按旧指针读会永远读不到新内容。-topmost True让窗口置顶。这能保证它始终停在 Codex 旁边不被其他窗口盖住。自动滚动策略很关键。如果用户手动往上翻看历史窗口不应该强行把滚动条拉到底只有当滚动条本来就在底部时才自动跟随。否则辅助窗口会变成一个干扰源。3.3 让窗口内容更有用按任务状态分层展示直接把所有日志塞进窗口信息量太大反而难以扫读。更好的做法是做一个轻量级“状态面板”把日志里值得关注的信息抽出来分区块展示当前目录Codex 当前在哪个目录下工作最近指令最近一次用户输入或它正在执行的指令最近报错日志里出现error、failed、报错等关键字时单独抽出来变更文件数观察它改了几个文件、改了哪些。实现上不复杂你只需要在读取新日志时用正则或关键词把对应行抽出来更新一个字典然后刷新界面上对应的 Label 或 Text 区域。不要试图做严谨的解析因为 Codex 输出格式会变化只要能做到“关键信息能扫到”就够了。这种分层展示的价值在于你不需要读完整段日志只要扫一屏就知道它现在在哪个目录、出没出问题、改了多少文件。遇到报错再回主终端看细节。3.4 运行方式与参数调整跑起来很简单python3 codex_follow_window.py窗口会打开并停留在最前面。它自己不会启动 Codex你需要先在另一个终端里用script或 Codex 自带的日志方式准备好日志文件。参数调整建议刷新间隔。上面的代码是 500 毫秒轮询一次实际用下来够了。改成 200 毫秒会更跟手但没必要。窗口尺寸。我习惯宽度 360 到 420 像素高度和主窗口接近。置顶开关。如果你同时在看浏览器和文档可以考虑把置顶优先级降低或者加一个快捷键手动切换。注意第一次启动前先把日志文件路径确认好。路径写错了窗口会一直“跟着”一个不存在的文件这种 bug 通常发生在你自己身上而不是脚本逻辑上。4. 更进一步让辅助窗口在物理上跟随主 Codex 窗口4.1 物理跟随的原理窗口坐标同步内容状态跟随解决的是“该看什么”物理跟随解决的是“窗口该停在哪”。原理并不复杂获取目标窗口也就是 Codex 主终端窗口在屏幕上的坐标和尺寸根据目标窗口的位置计算辅助窗口应该放置的位置一般是主窗口右侧或左侧辅助窗口按同样的尺寸策略做调整重复执行第 1 到 3 步间隔不要太短。这里最大的难点不是原理而是跨平台兼容。窗口管理器相关的 API 在不同系统上差异极大而且还会遇到多显示器、DPI 缩放、窗口标题变化等问题。4.2 一个可参考的伪代码实现下面是一个思路示例不要直接拿去生产重点是理解流程# 伪代码仅用于理解物理跟随的流程 import time import pygetwindow as gw def follow_window(helper_prefix, target_keyword): while True: try: helper None target None for w in gw.getAllWindows(): title w.title or if target_keyword in title: target w if helper_prefix in title: helper w if target and helper: x, y target.left, target.top width, height target.width, target.height helper.moveTo(x width 12, y) helper.resizeTo(360, height) time.sleep(0.3) # 必须节流 except Exception: time.sleep(1) if __name__ __main__: follow_window(Codex 跟随窗口, codex)需要注意几个问题轮询间隔不要太快。300 毫秒已经算激进一般 500 毫秒到 1 秒都够。窗口位置本身不会频繁变化轮询太密只会消耗 CPU。窗口句柄可能失效。目标窗口一关、一刷新、标题一变getAllWindows的结果就会变。脚本要能容忍找不到窗口而不是直接崩。多显示器环境下要小心。辅助窗口可能被摆到另一个屏幕上位置偏移和负坐标都要考虑。4.3 跨平台说明和工程化建议如果只在你自己的机器上用写一个轮询脚本最快。但如果你想做得稳一点建议按平台差别考虑Windows 下窗口 API 相对易用窗口属性也稳定物理跟随脚本最容易跑通。Linux 下依赖窗口管理器不同桌面环境差异很大如果只在 Gnome/KDE 上用可以用对应桌面环境的窗口管理能力去绑定位置。macOS 下窗口位置控制有很多权限限制脚本如果频繁移动窗口可能会被系统拦下体验不一定好。我的建议是物理跟随属于“锦上添花”的功能如果你发现自己在真实使用中很少手动移动主窗口那就不必写物理跟随。把精力放在内容状态跟随上性价比更高。5. 这套方案最容易踩的坑以及该按什么顺序排查5.1 常见坑点逐个拆开说窗口一直闪烁或来回跳动如果辅助窗口的置顶优先级太高或者和主窗口互相抢焦点就会出现两个窗口来回跳的情况。常见原因是脚本里同时做了“移动窗口”和“重新置顶”两套逻辑互相冲突。解决思路很简单先只做置顶看是否稳定再只做位置跟随看是否稳定最后再合起来。如果合起来出问题八成是两者打架。日志文件读取到乱码或半个字符Codex 输出通常带颜色码和特殊字符。直接读文件显示时可能出现[32m这类 ANSI 转义码或者一条日志写到一半被读取。处理方式有两种一是在显示前去掉 ANSI 颜色码二是按行缓存只有看到完整换行才刷新到界面上。CPU 占用过高最常见原因是轮询间隔太短或者每次都读整个文件。如果日志文件已经几十 MB每次全量读取会非常明显。正确做法是前面写的文件指针增量读取不要每次read()全量。窗口标题变化导致物理跟随失效很多终端软件会在标题里显示当前目录、任务名、Git 分支这导致你按标题关键字找窗口时窗口可能在但标题已经变了。排查时先打印所有窗口的标题确认关键字是否仍然匹配。置顶窗口盖住其他应用辅助窗口始终置顶不代表它应该永远在最上层。如果你在同时调试浏览器里的页面辅助窗口可能会挡住页面。建议加一个快捷键来切换置顶状态或者把辅助窗口放在屏幕边缘减少遮挡。5.2 排查链路现象 → 输入 → 环境 → 参数 → 工具边界遇到问题不要直接猜代码。按下面的顺序排查通常能快速定位排查层先看什么常见问题现象窗口不更新、闪动、CPU高、位置不对先明确是内容问题还是位置问题输入日志文件路径、文件是否在写、编码路径错、文件没写入、日志格式变化环境操作系统、终端类型、窗口管理器平台 API 差异、权限限制参数刷新间隔、置顶开关、窗口尺寸间隔太短、置顶冲突工具边界Codex 输出格式变化、窗口标题变化日志结构变化、窗口句柄失效实际落地时我会先做一个最小验证把 Codex 跑起来确认日志文件在持续增长再启动跟随窗口。如果日志文件没有增长问题一定在前面如果日志 为 Codex 长任务打造内容状态跟随窗口，让注意力不漂移
很长一段时间里我用 Codex 的方式都是“一条终端窗口丢到隔壁桌面自己在编辑器里看代码”。单次小任务还好一旦任务变长问题就来了我记不清当前进度到哪了也不知道现在该不该切回终端确认。最后的结果就是每隔几分钟切一次窗口每次切完还得花几秒重新找上下文。后来我做了一个小工具让一个辅助窗口跟着 Codex 走窗口停在会话旁边内容跟着任务状态刷新。这个改造看起来不起眼但它确实改变了我做长任务时的方式。这篇文章想把这段实践拆开说明白——不只是分享一个窗口小工具而是讲清楚“跟随窗口”到底要解决什么问题怎么做才不至于变成一个华而不实的玩具。我把这段经历沉淀下来的核心判断写在前面跟随窗口的真正价值不是“窗口会跟着动”而是让注意力不再需要频繁离开主任务。1. 先想清楚你要的到底是“窗口跟着 Codex 走”还是“注意力跟着任务走”1.1 一次真实的使用场景Codex 跑任务时我为什么总在切窗口假设你在用 Codex 重构一个模块。它会读取代码、改文件、跑测试、根据报错继续修。作为使用者你并不是全程盯着终端你还需要在编辑器里看它改过的代码在终端里观察它的执行过程在日志或输出里确认任务进度在文件列表里核对变更。这些信息分布在好几个软件里。正常情况下不觉得有什么问题但任务一长窗口切换就不再是一个操作问题而是一个认知问题。每次切换你都要回答一遍“我刚才看到哪了”“它现在在做什么”“我要不要等它”。这三个问题反复出现注意力就被打散了。我比较早意识到这一点是因为一次批量重构任务Codex 处理了十几个文件我在编辑器、终端、日志文件之间来回切结果漏掉了一条它停在半路的提示导致后续所有文件都是基于一个错误前提处理的。问题不在 Codex而在我的观察方式不够连续。1.2 两层“跟随”物理位置跟随和内容状态跟随“跟着 Codex 走的窗口”这句话其实藏着两种完全不同的能力。第一层是物理位置跟随。也就是 Codex 主窗口在屏幕上的位置移动时辅助窗口跟着移动始终保持在工作区旁边。第二层是内容状态跟随。也就是 Codex 的任务有了新输出、新进度、新报错时辅助窗口里的内容也会自动更新到最新状态。这两层看起来都是“跟随”实际价值完全不同。物理位置跟随解决的是“窗口该放哪儿”的问题而内容状态跟随解决的是“我现在该关注什么”的问题。后者对注意力的帮助要大得多。我见过不少人的第一反应是去做“让窗口跟着动”因为这件事听起来直观也容易演示。但真正长期用下来你会发现内容状态跟随才是刚需。如果一个窗口只是位置跟着 Codex 走里面显示的却是十分钟前的旧信息那它和一张贴在屏幕上的便签没有本质差别。可以把这个判断抽象成一张表跟随层次要解决的问题核心价值实现复杂度维护成本手工固定窗口窗口放哪降低找窗口的显性成本低低物理位置跟随窗口跟着主窗口停在哪视觉一致性不增加太多价值中中内容状态跟随什么时候该关注什么减少注意力切换和上下文重建中高中两层结合窗口位置和内容都最新真正适合长时间任务高中高所以我的建议是不要一开始就冲去做物理跟随先把内容状态跟随做好你会发现收益已经远超预期。2. 不写代码也能先成立把 Codex 会话和辅助面板固定在同一个工作区2.1 用终端分屏搭一个“Codex 日志面板”的最小结构在做任何自动化之前可以先做一个纯手工方案。它不需要写代码几分钟就能搭好而且能立刻改善窗口切换。类 Unix 系统里我一般会用 tmux。它在终端里把一个会话分成若干个窗格特别适合把 Codex 会话和日志面板放在一起# 新建一个名为 codex 的会话 tmux new -s codex -d # 左右分屏 tmux split-window -h -t codex # 左边跑 Codex右边显示日志 tmux send-keys -t codex:0.0 codex Enter tmux send-keys -t codex:0.1 tail -f /tmp/codex-session.log Enter # 回到会话 tmux attach -t codex这样你的 Codex 交互和日志查看就在同一个终端窗口的两个窗格里不存在两个软件之间的切换。tmux 还有会话持久化能力中途断网、不小心关掉终端重新 attach 就能回到原来的状态。如果你习惯用 Windows Terminal 或 macOS Terminal也可以直接用内置分屏。但 tmux 的优势在于它不依赖具体终端软件而且在服务器上同样好用。Codex 很多时候是跑在远程机器或容器里的这时 tmux 几乎是必选项。2.2 置顶、粘附与固定窗口的适用边界如果你不想用终端分屏而是希望开一个独立小窗口放在 Codex 旁边那就需要“置顶”能力。不同平台做法差别很大Windows 下可以用系统里的窗口管理工具很多工具都支持让某个窗口始终置顶macOS 下可以通过系统自带的窗口置顶能力或借助第三方窗口管理器Linux 下取决于你的窗口管理器部分桌面环境内置“始终置顶”快捷键Gnome/KDE 等也各有方案。我建议不要在这里过度追求统一方案。第一步的目标只是把窗口布局固定下来用什么工具其实无所谓。真正要想清楚的是这个辅助窗口“置顶”的优先级太高会遮挡编辑器太低又起不到效果。通常我会让辅助窗口保持在编辑器右侧宽度约 360 到 420 像素高度跟随主窗口。这样它不占太多空间又能在余光范围内。2.3 手工方案的局限它并不能真正“跟着 Codex 走”手工方案能解决一部分问题但它有一个根本局限布局是你手动固定的而 Codex 跑任务时的状态是动态的。举几个典型情况Codex 突然报错输出里出现一条错误但你的辅助窗口还停留在上一条指令的结果上Codex 切换到另一个目录继续处理你的辅助窗口内容还显示着之前的路径你手动调整主窗口大小时辅助窗口不会跟着自动调整需要再次动手。这些问题不会让任务失败但会持续消耗你的注意力。所以手工方案适合短会话和零散任务不适合长任务。它真正的价值是让你先理解“哪些窗口必须同时可见”再决定要自动化哪一部分。3. 做第一个真正会跟的东西内容状态跟随窗口3.1 设计原则不要改造 Codex去监听它的输出做内容状态跟随窗口时最容易犯的错是想去改 Codex 本身比如想办法拿到它的内部状态、解析它的内部数据结构、或者给它加插件。这通常不值得。一是 Codex 迭代很快内部结构随时可能变二是你改完后要长期维护成本会一直滚下去。更稳的做法是让 Codex 把会话输出落成一个文件然后用一个独立脚本去读文件尾部把新内容推到辅助窗口里。这样 Codex 侧几乎不用动你只需要处理一个文本文件谁都能看懂也最容易调试。在类 Unix 系统里可以用script命令录制终端会话把 Codex 的完整输出写进日志script /tmp/codex-session.log codex执行script后终端会进入录制模式codex启动后所有输出都会同时写入/tmp/codex-session.log。退出 Codex 后再按CtrlD结束录制。这是比较稳妥的通用做法比直接用管道codex | tee更好因为交互式终端里的管道经常会带来输入回显、缓冲和颜色码问题。如果你用的 Codex 本身已经支持日志配置那就更简单了直接把日志文件路径告诉脚本就行。3.2 一个日志跟随窗口的最小实现下面是用 Python 的 Tkinter 写的一个日志跟随窗口。它不依赖太多第三方库逻辑也清楚import os import tkinter as tk from tkinter.scrolledtext import ScrolledText class CodexFollowWindow: def __init__(self, root, log_path): self.log_path log_path self.file_pos 0 self.last_mtime 0 root.title(Codex 跟随窗口) root.attributes(-topmost, True) self.text ScrolledText(root, width100, height30, font(Menlo, 12)) self.text.pack(fillboth, expandTrue) root.protocol(WM_DELETE_WINDOW, self.on_close) self.root root if os.path.exists(log_path): # 如果日志文件已存在直接从末尾开始只显示后面新增的内容 self.file_pos os.path.getsize(log_path) self.poll() def poll(self): try: mtime os.path.getmtime(self.log_path) if mtime ! self.last_mtime: size os.path.getsize(self.log_path) # 如果文件变小说明被截断或轮转了重置到开头 if size self.file_pos: self.file_pos 0 self.text.delete(1.0, end) with open(self.log_path, r, encodingutf-8, errorsignore) as f: f.seek(self.file_pos) new_data f.read() self.file_pos f.tell() self.last_mtime mtime if new_data: # 如果滚动条在底部自动跟随到末尾否则保持用户阅读位置 at_bottom self.text.yview()[1] 0.99 self.text.insert(end, new_data) if at_bottom: self.text.see(end) except Exception: # 日志文件可能存在临时被占用或删除的情况 pass self.root.after(500, self.poll) def on_close(self): self.root.destroy() if __name__ __main__: root tk.Tk() CodexFollowWindow(root, /tmp/codex-session.log) root.mainloop()这里有几个关键点文件指针file_pos是核心。每次只读新增部分而不是把整个日志重新读一遍。日志文件越来越大时这个写法性能才撑得住。mtime 判断用来避免每次轮询都打开文件。虽然这里打开文件的开销不大但写成“文件没变就不读”更干净。遇到文件截断要重置。有些日志工具会做轮转文件大小可能变小如果还按旧指针读会永远读不到新内容。-topmost True让窗口置顶。这能保证它始终停在 Codex 旁边不被其他窗口盖住。自动滚动策略很关键。如果用户手动往上翻看历史窗口不应该强行把滚动条拉到底只有当滚动条本来就在底部时才自动跟随。否则辅助窗口会变成一个干扰源。3.3 让窗口内容更有用按任务状态分层展示直接把所有日志塞进窗口信息量太大反而难以扫读。更好的做法是做一个轻量级“状态面板”把日志里值得关注的信息抽出来分区块展示当前目录Codex 当前在哪个目录下工作最近指令最近一次用户输入或它正在执行的指令最近报错日志里出现error、failed、报错等关键字时单独抽出来变更文件数观察它改了几个文件、改了哪些。实现上不复杂你只需要在读取新日志时用正则或关键词把对应行抽出来更新一个字典然后刷新界面上对应的 Label 或 Text 区域。不要试图做严谨的解析因为 Codex 输出格式会变化只要能做到“关键信息能扫到”就够了。这种分层展示的价值在于你不需要读完整段日志只要扫一屏就知道它现在在哪个目录、出没出问题、改了多少文件。遇到报错再回主终端看细节。3.4 运行方式与参数调整跑起来很简单python3 codex_follow_window.py窗口会打开并停留在最前面。它自己不会启动 Codex你需要先在另一个终端里用script或 Codex 自带的日志方式准备好日志文件。参数调整建议刷新间隔。上面的代码是 500 毫秒轮询一次实际用下来够了。改成 200 毫秒会更跟手但没必要。窗口尺寸。我习惯宽度 360 到 420 像素高度和主窗口接近。置顶开关。如果你同时在看浏览器和文档可以考虑把置顶优先级降低或者加一个快捷键手动切换。注意第一次启动前先把日志文件路径确认好。路径写错了窗口会一直“跟着”一个不存在的文件这种 bug 通常发生在你自己身上而不是脚本逻辑上。4. 更进一步让辅助窗口在物理上跟随主 Codex 窗口4.1 物理跟随的原理窗口坐标同步内容状态跟随解决的是“该看什么”物理跟随解决的是“窗口该停在哪”。原理并不复杂获取目标窗口也就是 Codex 主终端窗口在屏幕上的坐标和尺寸根据目标窗口的位置计算辅助窗口应该放置的位置一般是主窗口右侧或左侧辅助窗口按同样的尺寸策略做调整重复执行第 1 到 3 步间隔不要太短。这里最大的难点不是原理而是跨平台兼容。窗口管理器相关的 API 在不同系统上差异极大而且还会遇到多显示器、DPI 缩放、窗口标题变化等问题。4.2 一个可参考的伪代码实现下面是一个思路示例不要直接拿去生产重点是理解流程# 伪代码仅用于理解物理跟随的流程 import time import pygetwindow as gw def follow_window(helper_prefix, target_keyword): while True: try: helper None target None for w in gw.getAllWindows(): title w.title or if target_keyword in title: target w if helper_prefix in title: helper w if target and helper: x, y target.left, target.top width, height target.width, target.height helper.moveTo(x width 12, y) helper.resizeTo(360, height) time.sleep(0.3) # 必须节流 except Exception: time.sleep(1) if __name__ __main__: follow_window(Codex 跟随窗口, codex)需要注意几个问题轮询间隔不要太快。300 毫秒已经算激进一般 500 毫秒到 1 秒都够。窗口位置本身不会频繁变化轮询太密只会消耗 CPU。窗口句柄可能失效。目标窗口一关、一刷新、标题一变getAllWindows的结果就会变。脚本要能容忍找不到窗口而不是直接崩。多显示器环境下要小心。辅助窗口可能被摆到另一个屏幕上位置偏移和负坐标都要考虑。4.3 跨平台说明和工程化建议如果只在你自己的机器上用写一个轮询脚本最快。但如果你想做得稳一点建议按平台差别考虑Windows 下窗口 API 相对易用窗口属性也稳定物理跟随脚本最容易跑通。Linux 下依赖窗口管理器不同桌面环境差异很大如果只在 Gnome/KDE 上用可以用对应桌面环境的窗口管理能力去绑定位置。macOS 下窗口位置控制有很多权限限制脚本如果频繁移动窗口可能会被系统拦下体验不一定好。我的建议是物理跟随属于“锦上添花”的功能如果你发现自己在真实使用中很少手动移动主窗口那就不必写物理跟随。把精力放在内容状态跟随上性价比更高。5. 这套方案最容易踩的坑以及该按什么顺序排查5.1 常见坑点逐个拆开说窗口一直闪烁或来回跳动如果辅助窗口的置顶优先级太高或者和主窗口互相抢焦点就会出现两个窗口来回跳的情况。常见原因是脚本里同时做了“移动窗口”和“重新置顶”两套逻辑互相冲突。解决思路很简单先只做置顶看是否稳定再只做位置跟随看是否稳定最后再合起来。如果合起来出问题八成是两者打架。日志文件读取到乱码或半个字符Codex 输出通常带颜色码和特殊字符。直接读文件显示时可能出现[32m这类 ANSI 转义码或者一条日志写到一半被读取。处理方式有两种一是在显示前去掉 ANSI 颜色码二是按行缓存只有看到完整换行才刷新到界面上。CPU 占用过高最常见原因是轮询间隔太短或者每次都读整个文件。如果日志文件已经几十 MB每次全量读取会非常明显。正确做法是前面写的文件指针增量读取不要每次read()全量。窗口标题变化导致物理跟随失效很多终端软件会在标题里显示当前目录、任务名、Git 分支这导致你按标题关键字找窗口时窗口可能在但标题已经变了。排查时先打印所有窗口的标题确认关键字是否仍然匹配。置顶窗口盖住其他应用辅助窗口始终置顶不代表它应该永远在最上层。如果你在同时调试浏览器里的页面辅助窗口可能会挡住页面。建议加一个快捷键来切换置顶状态或者把辅助窗口放在屏幕边缘减少遮挡。5.2 排查链路现象 → 输入 → 环境 → 参数 → 工具边界遇到问题不要直接猜代码。按下面的顺序排查通常能快速定位排查层先看什么常见问题现象窗口不更新、闪动、CPU高、位置不对先明确是内容问题还是位置问题输入日志文件路径、文件是否在写、编码路径错、文件没写入、日志格式变化环境操作系统、终端类型、窗口管理器平台 API 差异、权限限制参数刷新间隔、置顶开关、窗口尺寸间隔太短、置顶冲突工具边界Codex 输出格式变化、窗口标题变化日志结构变化、窗口句柄失效实际落地时我会先做一个最小验证把 Codex 跑起来确认日志文件在持续增长再启动跟随窗口。如果日志文件没有增长问题一定在前面如果日志