先说一个很真实的场景你在终端里开着 Claude Code 让它干一个多步骤的活儿比如“把这个模块重构一下、补上测试、再检查有没有遗漏的调用点”。它往往不会老老实实一路跑完而是拆出好几个 Subagent 分头行动有的在翻目录、有的在改文件、有的在跑验证。这个时候屏幕上的日志就跟瀑布一样往下滚你根本分不清哪个 Subagent 正在忙、哪个已经结束、哪个其实是卡住了。我踩了几次这个坑之后实在受不了了就动手给 Claude Code 做了一个自定义状态栏工具。核心作用就是把 Subagent 的状态实时钉在终端底部现在有几个子任务在跑、各自是什么状态、有没有出错。用起来之后整个终端的“掌控感”完全不一样——你不用再一直翻日志瞄一眼底部就知道当前进度。这篇文章就把我自己的安装、配置和实现思路完整写一遍操作上以我常用的 Shell tmux 方案为主也给不用 tmux 的朋友留了替代做法。1. 项目需求与整体思路拆解1.1 终端里跑 AI 编程助手的真实痛点Claude Code 这类命令行 AI 编程助手跟你在网页对话框里问问题是完全不同的体验。它可以直接读你项目里的文件、运行命令、修改代码而且一次任务还可以拆成多个并行子任务去处理每个子任务都有一个独立的 Subagent 上下文。听起来很强大但在终端里用的时候有一个明显的短板输出只有一屏信息是流水式刷过去的。多个 Subagent 并发工作的时候它们的输出会交错在一起。比如 A 子任务读完了某文件、B 子任务正在跑测试、C 子任务刚报了权限错误这些信息在同一时间都混在终端滚动区里。你想确认 C 子任务是不是真的失败了得往上翻十几屏甚至更多。如果任务跑几十分钟这个过程会重复出现无数次效率非常低。另一个痛点是不确定感。终端里没有图形界面没有像网页端那样的任务列表你不知道当前到底有几个子任务在跑、每个跑到哪一步了。有些耗时长的任务你甚至没法判断它是在正常思考还是已经卡死了。这种状态其实很影响工作节奏你不敢离开终端太久也不敢同时开好几个会话来操作。当时我试过几种笨办法人工盯日志、把输出重定向到文件再另开终端用 tail 看、给每个子任务手动加标记。说实话都不好用因为它们都需要额外操作而且不能实时汇总。最终我意识到真正需要的不是“更多日志”而是一个常驻的、结构化的状态视图——这就是状态栏工具的出发点。1.2 自定义状态栏到底要展示什么动手之前我先列了需求清单避免自己做出一个花哨但没用的东西。当前运行的 Subagent 有哪些每个子任务给一个短编号或者短名称能对应上日志里的线索。每个 Subagent 的状态等待中、运行中、已完成、异常这四种状态基本能覆盖常见的子任务生命周期。整体进度比如当前有 5 个 Subagent其中 2 个完成、2 个运行中、1 个异常一眼就能看出整体对局面的掌控感。最近事件最近一条与 Subagent 相关的日志时间或动作方便回溯。辅助信息像 token 消耗、耗时统计我当时也考虑过但放到状态栏里意义不大而且会让渲染变得冗长。状态栏的核心价值应该是“快速扫一眼就能读懂”不是把所有日志都塞进去。所以我最终定下来的展示内容非常收敛分组统计 当前各子任务状态 最近事件。在这个基础上我进一步确定了几个设计原则不干扰原终端输出状态栏应该像 tmux 的状态栏一样是独立的区域。刷新要快状态变化后最好 2 秒内能在状态栏体现出来。低成本不要为了显示状态给 Claude Code 本身加太多负担最好只读日志、不改动它的运行逻辑。健壮日志偶尔缺失、格式变化、子任务数量突然增多都不能让脚本崩溃。带着这个需求列表我开始了选型。2. 技术选型与架构设计2.1 终端状态栏方案选型对比要实现“终端底部的状态栏”我试过几种方式这里直接给对比。方案优点缺点适用场景纯 Shell 脚本 tput 模拟底部固定行无额外依赖简单刷新逻辑难做输出容易跟终端内容打架临时调试、极简环境tmux 的 status-right / status-left稳定、自带刷新周期、不干扰主终端需要 tmux依赖其配置日常主力推荐独立常驻进程重绘终端区域控制力最强实现复杂处理终端尺寸变化很麻烦对交互要求极高的场景复用编辑器/IDE 的嵌入式终端图形界面展示友好本质上换了环境不一定适合命令行重度用户团队内部工具我选了tmux 方案原因很实在tmux 天然提供了状态栏容器而且它自带的 status-interval 刷新机制可以让我不用自己写事件循环。我需要做的只是写一个脚本输出一小段文本把它挂到 tmux 的 status-right 里。这样状态栏跟主终端输出完全隔离怎么看都不会乱。如果你没有用 tmux 的习惯我自己也验证过一条备选路线用极简的 Shell 脚本读取最后一次渲染结果通过tput sc、tput rc这类终端控制序列在底部固定一行但说实话比较折腾。建议优先选 tmux省下的时间够你干很多别的事了。2.2 状态数据从哪里来日志解析方案核心问题永远是状态栏的数据源是什么Claude Code 在运行过程中会把大量事件以 JSON Lines 的形式写入日志文件每条日志是一个独立的 JSON 对象包含时间戳、事件类型、关联的上下文信息。Subagent 的创建、启动、完成、出错都会产生对应的事件。所以不需要去改 Claude Code 本身只要读取并解析这些日志就能拿到状态。我采用的链路是这样的Claude Code 运行日志 (JSON Lines) ↓ tail jq 按事件类型过滤 ↓ 提取 Subagent 状态数据 ↓ 渲染为一行文本 ↓ 挂到 tmux status-right在整个链路里解析精度决定了状态栏的准确率而读取策略决定了性能。读取上我用了tail -F来跟踪日志文件末尾避免一次性把超大日志读完解析上我用 jq 做 JSON 字段提取因为 jq 的过滤表达式比 awk 去抠字符串靠谱得多。这里有一个非常关键的经验不同版本的 Claude Code 日志格式有细微差别所以脚本里对事件的匹配字段尽量用“宽松模式”宁可多匹配几种字段名也不要因为一个字段名变化就输出空白。后面我还会讲一个我踩过的具体坑。2.3 目录结构与模块划分我把整套工具拆成了三个模块避免一个文件里挤了太多逻辑后面改起来头大。status-fetch.sh核心的日志解析模块负责读取日志、提取 Subagent 状态。status-render.sh渲染模块把状态数据格式化成状态栏文本内含截断逻辑。config.env配置项比如日志路径、状态栏最大展示数量、刷新间隔。划分之后的好处是如果我想换数据源只改status-fetch.sh如果我想改展示样式只动status-render.sh不想动逻辑的时候调config.env就够了。做小工具也值得保持模块感不要嫌麻烦。3. 安装与配置全过程3.1 环境准备依赖与目录规划这个工具对系统要求不高只要满足下面这几项即可bash 4.0 以上macOS 自带的 bash 3.2 建议先换成新版本或者直接用 zsh 跑也没问题jq 命令tail、grep 等基础命令tmux如果走 tmux 方案Claude Code 命令行工具本身且已经在终端里正常使用在开始之前先确认环境用一行命令检查依赖command -v jq command -v tmux echo deps ok如果缺 jq在 Debian/Ubuntu 上用sudo apt install jqmacOS 上用brew install jq。tmux 同理缺什么装什么。然后我建立了一个独立目录专门放这套工具mkdir -p ~/.claude-status这里也顺手用.gitignore把这个目录排除掉避免以后不小心把它提交到项目仓库里去——虽然只是个小工具但提交错目录这种事我发生过好几次了。3.2 主脚本安装与核心配置我把核心脚本放到~/.claude-status/status-fetch.sh。脚本的职责很简单读取日志文件提取 Subagent 状态输出一行状态文本。下面是我简化后的核心脚本框架你可以直接抄走改#!/usr/bin/env bash # ~/.claude-status/status-fetch.sh # 依赖jq source ~/.claude-status/config.env LOG_FILE${CLAUDE_LOG_FILE:-$HOME/.claude/logs.jsonl} # 从日志尾部读取最近 500 行过滤 Subagent 事件 tail -n 500 $LOG_FILE 2/dev/null | jq -c select(.type subagent_event) | { time: .timestamp, agent: .subagent_id, event: .event_type, detail: .message } | tail -n ${MAX_DISPLAY:-20}这段脚本的逻辑是先定位到日志文件然后取尾部 500 行用 jq 过滤出 subagent 相关事件并提取字段。MAX_DISPLAY控制最多展示多少条避免子任务特别多时状态栏被刷爆。然后对应的渲染脚本status-render.sh核心逻辑是这样#!/usr/bin/env bash # ~/.claude-status/status-render.sh source ~/.claude-status/config.env cd $(dirname $0) # 调用 fetch 脚本获取原始事件 EVENTS$(./status-fetch.sh) # 统计各类状态数量 RUNNING$(echo $EVENTS | jq -s [.[] | select(.event started)] | length) DONE$(echo $EVENTS | jq -s [.[] | select(.event completed)] | length) ERROR$(echo $EVENTS | jq -s [.[] | select(.event error)] | length) TOTAL$(echo $EVENTS | jq -s length) # 渲染输出 printf Subagents: %s | running: %s | done: %s | error: %s \ $TOTAL $RUNNING $DONE $ERROR写完脚本后要给它加执行权限否则 tmux 调用时会报 permission deniedchmod x ~/.claude-status/status-fetch.sh ~/.claude-status/status-render.sh配置项集中在config.env里内容大概是# Claude Code 日志路径 CLAUDE_LOG_FILE$HOME/.claude/logs.jsonl # 状态栏最多展示的事件条数 MAX_DISPLAY20 # tmux 状态栏刷新间隔秒 STATUS_INTERVAL2这里的日志路径和刷新间隔是调整最频繁的参数我建议都拆成配置项不要硬编码在脚本里。我第一次写的时候把路径直接写在脚本里后来换了日志位置改脚本改到崩溃。3.3 挂到 tmux 状态栏上脚本准备好之后剩下的就是让 tmux 的 status-right 调用它。在~/.tmux.conf里加上这几行set -g status-right #(bash ~/.claude-status/status-render.sh) set -g status-interval 2然后重载 tmux 配置tmux source-file ~/.tmux.conf注意一个新手常犯的坑status-right里写#()时tmux 会调用里面的命令但不会自动帮你加载你的PATH。所以脚本路径最好用绝对路径而且脚本内部用到的命令比如 jq也建议写绝对路径或提前确认在 PATH 中。我当时第一次配好发现状态栏是空的折腾了半天最后发现是脚本里找不到 jq。如果你已经临时进入了 tmux 会话也可以用按键直接临时改tmux set -g status-right #(bash ~/.claude-status/status-render.sh)这一招在调试时特别好用因为不用反复 reload 整个配置改完马上能看到效果。3.4 不用 tmux 的替代接入方式我不建议但还是要给需要的朋友一个备选。如果你实在不想用 tmux还有两个可能的接入点利用 Claude Code 自带的 hook 机制在特定事件触发时执行脚本并把最新状态写入一个临时文件用终端的 PROMPT_COMMAND 机制在每次命令提示符出现前刷新底部状态行。第二个方案我用过一个非常轻量的版本在.bashrc里加status_line() { printf \\033[1;30m%s\\033[0m\\n $(~/.claude-status/status-render.sh) } PROMPT_COMMANDprintf \\033[?25l; status_line; printf \\033[?25h原理是每次回车执行命令后、出现新提示符前把渲染好的状态行打印出来。但这里有个体验问题状态行一旦跟命令输出混在一起位置就不固定看着很乱。所以我最终还是没有把它作为日常方案只在快速调试时用。你要长期用真的建议 tmux。4. Subagent 状态展示核心实现4.1 状态数据的解析细节状态栏能不能准确工作决定性因素是日志解析。Claude Code 的日志是 JSON Lines 格式每条事件类似下面这种结构我做过脱敏简化字段含义保持一致{timestamp:2025-01-18T10:23:41.001Z,type:subagent_event,source:main,subagent_id:agent_01,event_type:created,message:Subagent agent_01 created} {timestamp:2025-01-18T10:23:43.512Z,type:subagent_event,source:main,subagent_id:agent_01,event_type:started,message:Subagent agent_01 started} {timestamp:2025-01-18T10:25:55.088Z,type:subagent_event,source:main,subagent_id:agent_01,event_type:completed,message:Subagent agent_01 finished}可以看到关键字段有三个subagent_id、event_type、timestamp。我的解析思路不是模拟一个完整的状态机而是把最近一组事件按 subagent_id 分组取每个 subagent_id 最后一条事件作为它的当前状态。由于日志本身是按时间顺序追加的取“最后一个事件”的操作在实现上就非常自然。核心解析命令如下tail -n 200 $CLAUDE_LOG_FILE 2/dev/null | jq -s map(select(.type subagent_event)) | group_by(.subagent_id) | map({ agent: .[0].subagent_id, status: (map(.event_type) | last) }) 这里的group_by(.subagent_id)会把所有同一子代理的事件聚在一起然后取每个分组里最后一个event_type作为当前状态。这样即使日志里事件很多也能保持状态汇总的正确性。状态值的转换我写了一个映射原始 event_type状态栏展示含义createdwait已创建等待执行startedrun运行中completeddone已完成errorerr异常结束其他unknown未知状态这个映射是我在开发过程中反复调整过的。最初我直接展示原始英文词后来发现状态栏宽度有限created、started、completed这些单词太长了就统一改成短标签。短标签还有一个好处你瞄一眼就能通过颜色或前缀区分不用读完整单词。4.2 状态渲染与截断策略解析出状态列表后渲染模块要做两件事格式化文本、控制长度。格式化部分我最终采用了这种模板Subagents: 5 | a1:run | a2:done | a3:err | 2 more前面的Subagents: 5是总数后面依次是每个子代理的短 ID 和状态。短 ID 我取的是subagent_id最后两段字符既能区分彼此又不会把状态栏撑爆。截断逻辑也非常关键。有一次我跑了一个大任务一次性派发了二十多个 Subagent如果全部展示出来tmux 的 status-right 直接溢出把状态栏挤乱。我在渲染脚本里加了一个最大数量限制MAX_ITEMS${STATUS_MAX_ITEMS:-6} ALL_ITEMS$(... ) # 解析得到的所有条目 TOTAL$(echo $ALL_ITEMS | jq -s length) IFS$(printf \\n) read -r -a items $(echo $ALL_ITEMS | jq -r .[:STATUS_MAX_ITEMS] | group_by(.status) | map(\(.agent):\(.status)) | join(|))实际上一开始实现比这个还要简单粗暴直接用awk把前 N 条串起来超出的部分统计为N more。要控制的是两个变量——N 的大小和状态项的格式。N 设成 6 左右比较合适再多状态栏就挤了。另外一个细节是颜色区分。tmux 的 status-right 支持#[fgcolor]这种内联样式我给不同状态加不同颜色运行中绿色、已完成默认色、异常红色。效果非常直观远远扫一眼就能知道有没有出问题。这算是我这个工具里性价比最高的一个优化。4.3 刷新策略与实时性调优状态栏的实时性取决于两个环节日志写入的速度以及 tmux 状态栏的刷新频率。tmux 的status-interval最小可以设到 1 秒但设太短每次渲染都会重新读取日志日志大的时候会有无畏的 CPU 开销。我测试下来的平衡点是2 秒。还有一点要提如果刷得太快状态栏会频繁跳动反而不如固定节奏稳。把status-interval 2配上脚本里的tail -n 200实测下来既不会漏掉关键事件也不会让风扇转起来。如果你希望状态变化后立即刷新而不是傻等下一轮定时刷新我用过一个小技巧在 tmux 的status-right命令里加一个后台触发set -g status-right #(bash ~/.claude-status/status-render.sh | \ if [[ \$(cat ~/.claude-status/last_hash) ! \$(sha1sum \$(cat ~/.claude-status/data.json)) ]]; then \ tmux refresh-client -S -; fi)不过这个方案在实际使用中收益不大因为 2 秒的间隔已经足够感知状态变化。过度优化反而带来复杂性后面维护起来麻烦。我的建议就是先设 2 秒用几天如果觉得响应慢再往 1 秒调不要一开始就加复杂机制。4.4 日志变化时的自适应处理Claude Code 本身在更新日志格式也可能跟着变。我刚写完这个工具没几天就遇到了一个情况某次版本升级后event_type字段从started变成了started_at结果状态栏全是unknown等于整个工具失效了。为了解决这类问题我后来在解析脚本里加了一个字段兼容层对同一种语义的状态名做映射不再死板匹配一个值。normalize_status() { case $1 in created|pending|queued) echo wait ;; started|running|executing) echo run ;; completed|finished|succeeded) echo done ;; error|failed|exception) echo err ;; *) echo unknown ;; esac }有了这个兼容层即使日志字段小范围变化状态栏也不会立刻崩溃。把这种防御逻辑放在最底层解析里后面能省很多麻烦。5. 常见问题与排查实录5.1 状态栏显示为空或不刷新这是我遇到最多的一个问题而且每次出问题用户反馈都高度相似tmux 配置加载了、脚本也放好了status-right 就是空的。排查顺序我建议这样走先手动执行一次渲染脚本bash ~/.claude-status/status-render.sh看有没有输出。如果输出为空那就是解析层出问题再单独执行bash ~/.claude-status/status-fetch.sh看日志读取和 jq 解析是否正常。如果脚本单独跑有输出在 tmux 里却是空优先怀疑 tmux 的 PATH 环境。用绝对路径、在脚本里显式定义 jq 路径就能解决。我自己遇到的一个真实问题是漏了chmod xtmux 调用脚本时报 permission denied但在终端手动用bash调用却一切正常因为bash不依赖直接执行权限。后来我学乖了每次新增脚本后的第一件事就是chmod x。5.2 Subagent 数量太多导致状态栏错位当一次任务派生几十个子代理时状态栏会被长文本撑爆。表现就是 tmux 状态栏出现“挤行”、右侧内容被截掉或者状态栏换行。解决方法就是我前面提到的截断策略。我在渲染层加了两层保险最多只展示前STATUS_MAX_ITEMS个子代理其余用N more汇总单个状态项的短 ID 固定长度超长截断。具体到参数我通常设STATUS_MAX_ITEMS6。试过 10但那种密度下眼睛反而不容易聚焦。6 是一个自己用下来比较舒服的值。还有一个辅助技巧如果异常子代理特别多我会在状态栏里额外加一个“异常列表”字段把最近的异常子代理 ID 放进去方便快速定位。5.3 多个终端会话共享同一个状态栏这个问题的场景是我同时开了多个 tmux 窗口分别在不同项目里跑 Claude Code。默认配置下所有窗口共用一个全局 status-right导致 A 项目的状态显示到了 B 项目的窗口里相当混乱。解法是让 status-right 根据当前窗口或当前目录动态渲染。我改成了这样set -g status-right #(bash ~/.claude-status/status-render.sh #{pane_current_path})然后在渲染脚本里接收当前路径参数用它把日志读取范围限定为当前项目目录下的 Claude Code 日志。如果你的 Claude Code 本身就是项目级日志这一步会非常顺。值得说明的是这需要 Claude Code 支持项目级日志输出如果你的版本还是全量日志写到同一个文件那状态栏就不可能精确区分项目。此时退而求其次可以在状态栏展示“最近一条事件来自哪个项目”至少能帮你区分方向。5.4 性能开销控制状态栏脚本每 2 秒跑一次如果日志文件已经很大tail -n 200加上 jq 解析还是有开销的。在巨量日志场景下我发现瞬时 CPU 占用会跳到明显可见的程度。优化思路是分层用tail -n限制解析行数避免全量扫描解析结果缓存在临时文件里如果日志文件没有变化就直接复用降低刷新频率从 2 秒变成 3 秒感知差异不大但 CPU 占用明显下降。实测下来200 行日志 jq 解析单次执行时间在十几毫秒到几十毫秒之间加上缓存后几乎可以忽略。除非你的日志文件大得离谱否则不用太担心性能。5.5 日志文件被轮转导致的读取中断Claude Code 在长时间运行后日志文件可能按天或按大小轮转新的日志会写到新文件里。如果你一直用tail -F跟踪旧文件切换后状态栏就再也读不到新日志了。解决方式有两个一种是用tail -F跟踪当前实际路径它能自动跟随重命名另一种是在配置里使用通配路径比如~/.claude/logs/*.log但这样需要在脚本里处理“按修改时间选择最新文件”的逻辑。我最终选择了按天切换的方式每天第一次执行状态下拉时解析脚本会检查当天的日志文件名自动切换。这个改动不复杂却能避免早上开电脑之后状态栏持续停在昨天的状态上。6. 界面效果与使用体验调整6.1 状态栏文案与颜色调整技巧状态栏做出来后我花了不少时间在“文案优化”上。刚开始我用了很长的描述比如subagent-01 is running在窄终端里会显得很挤。后来统一改成紧凑格式Subagents: 5 | a1:run | a2:done | a3:errtmux 支持在 status-right 里用#[fgcolour]改颜色我做了这样一个映射case $STATUS in run) COLOR#[fggreen] ;; done) COLOR#[fgdefault] ;; err) COLOR#[fgred] ;; wait) COLOR#[fgyellow] ;; esac这个改动让我在远处看一眼就知道整体有没有问题。状态栏本来就是为了“扫一眼”存在的不要把所有都想靠文字表达。6.2 适配不同终端宽度tmux 的状态栏在终端窗口变窄的时候会自动处理一部分但 status-right 自身的内容过长时还是会截断。为了在不同窗口宽度下都保持可读我加了一个简单的策略根据终端宽度动态调整展示的 Subagent 数量。COLUMNS$(tput cols) if [ $COLUMNS -lt 100 ]; then MAX_ITEMS3 elif [ $COLUMNS -lt 180 ]; then MAX_ITEMS6 else MAX_ITEMS10 fi这样在外接屏幕和笔记本屏幕之间切换时状态栏都能保持在一个可接受的宽度内。极客朋友可能觉得这算过度设计但当你天天面对这个状态栏时这点细节真的能提升舒适度。6.3 我把上次状态也放进状态栏的小细节有一次我跑了一个很重的任务中途去喝了杯水回来之后想知道在我离开的几分钟里有没有 Subagent 已经完成任务或报错。但状态栏此时只显示当前的最新快照历史信息没有了。后来我加了一个字段last: completed agent_02 at 10:25展示最近一次状态变化的事件。实现上就是在渲染脚本里额外读取最近一条非 started 事件。效果很好因为你不需要翻日志就能感知“刚才发生了什么”。这个小字段后来成了我最常用的信息。7. 项目后续扩展与个人经验总结7.1 还能怎么扩展这个状态栏这个状态栏工具做到底之后我发现它的架构其实可以承载更多信息不只是 Subagent 状态。比如我想过把 token 消耗显示在状态栏里只要日志里能提取出 token 字段就能把每次调用的 token 数和累计数渲染出来。再比如把最近的错误消息摘要也加到状态栏里通过关键词过滤出 error 级别的事件给出前几条简短文本提示。还有一个扩展方向多项目状态看板。如果你同时维护多个项目、每个项目各跑了一个 Claude Code 会话可以在一个总览状态栏里把各自的项目名、运行状态、异常数量都列出来。这个想法我后来验证过技术上就是读取多个日志文件汇总渲染难度不大但对团队协作来说还挺有用的。7.2 个人踩坑与经验总结回头看看整个开发过程最深的体会有三点。第一解析层要做好兼容。Claude Code 迭代很快日志字段名说变就变。我在 4.4 里加了 normalize_status 之后工具稳定性高了很多。如果你只是自己用可以不加但如果想长期维护这层防御很值得。第二状态栏应该是一个“汇总层”而不是另一个“日志流”。最开始我差点直接往状态栏里塞原始事件后来发现根本没必要。状态栏越短信息密度越高用起来越顺手。把详细信息留在日志里状态栏只给出干脆利落的结论。第三接入 tmux 状态栏是最值得的决定。不用自己写循环调度、不用处理终端重绘、不用管刷新频率tmux 全给你管好了。如果一开始我选择自己写一个常驻进程估计要多花好几倍时间。利用现成的容器机制永远是最快出效果的路径。7.3 最后分享一个小技巧如果你用了这个工具之后发现状态栏偶尔还是跟不上任务节奏我建议你重点检查一下刷新链路里最弱的一环——通常不是 tmux而是日志文件写入频率。Claude Code 在跑子任务时日志写入是有批处理和延迟的。状态栏显示“等一下”其实不是它的错而是日志还没落盘。这个没法从脚本层面根治但可以通过一个折中方案缓解在渲染脚本里查一下日志文件的修改时间如果和当前时间差异超过 10 秒就显示一个刷新滞后提示。选这个方案比反复调大刷新频率靠谱得多。这个工具我自己用了很长时间最大的感受不是“多酷炫”而是终端里跑长任务的时候心里终于有一个明确的位置可以观察进度了。如果你也在用 Claude Code 处理多子任务、多步骤的重活照这套思路搭一个状态栏会让整个终端使用体验改善不少。
先说一个很真实的场景你在终端里开着 Claude Code 让它干一个多步骤的活儿比如“把这个模块重构一下、补上测试、再检查有没有遗漏的调用点”。它往往不会老老实实一路跑完而是拆出好几个 Subagent 分头行动有的在翻目录、有的在改文件、有的在跑验证。这个时候屏幕上的日志就跟瀑布一样往下滚你根本分不清哪个 Subagent 正在忙、哪个已经结束、哪个其实是卡住了。我踩了几次这个坑之后实在受不了了就动手给 Claude Code 做了一个自定义状态栏工具。核心作用就是把 Subagent 的状态实时钉在终端底部现在有几个子任务在跑、各自是什么状态、有没有出错。用起来之后整个终端的“掌控感”完全不一样——你不用再一直翻日志瞄一眼底部就知道当前进度。这篇文章就把我自己的安装、配置和实现思路完整写一遍操作上以我常用的 Shell tmux 方案为主也给不用 tmux 的朋友留了替代做法。1. 项目需求与整体思路拆解1.1 终端里跑 AI 编程助手的真实痛点Claude Code 这类命令行 AI 编程助手跟你在网页对话框里问问题是完全不同的体验。它可以直接读你项目里的文件、运行命令、修改代码而且一次任务还可以拆成多个并行子任务去处理每个子任务都有一个独立的 Subagent 上下文。听起来很强大但在终端里用的时候有一个明显的短板输出只有一屏信息是流水式刷过去的。多个 Subagent 并发工作的时候它们的输出会交错在一起。比如 A 子任务读完了某文件、B 子任务正在跑测试、C 子任务刚报了权限错误这些信息在同一时间都混在终端滚动区里。你想确认 C 子任务是不是真的失败了得往上翻十几屏甚至更多。如果任务跑几十分钟这个过程会重复出现无数次效率非常低。另一个痛点是不确定感。终端里没有图形界面没有像网页端那样的任务列表你不知道当前到底有几个子任务在跑、每个跑到哪一步了。有些耗时长的任务你甚至没法判断它是在正常思考还是已经卡死了。这种状态其实很影响工作节奏你不敢离开终端太久也不敢同时开好几个会话来操作。当时我试过几种笨办法人工盯日志、把输出重定向到文件再另开终端用 tail 看、给每个子任务手动加标记。说实话都不好用因为它们都需要额外操作而且不能实时汇总。最终我意识到真正需要的不是“更多日志”而是一个常驻的、结构化的状态视图——这就是状态栏工具的出发点。1.2 自定义状态栏到底要展示什么动手之前我先列了需求清单避免自己做出一个花哨但没用的东西。当前运行的 Subagent 有哪些每个子任务给一个短编号或者短名称能对应上日志里的线索。每个 Subagent 的状态等待中、运行中、已完成、异常这四种状态基本能覆盖常见的子任务生命周期。整体进度比如当前有 5 个 Subagent其中 2 个完成、2 个运行中、1 个异常一眼就能看出整体对局面的掌控感。最近事件最近一条与 Subagent 相关的日志时间或动作方便回溯。辅助信息像 token 消耗、耗时统计我当时也考虑过但放到状态栏里意义不大而且会让渲染变得冗长。状态栏的核心价值应该是“快速扫一眼就能读懂”不是把所有日志都塞进去。所以我最终定下来的展示内容非常收敛分组统计 当前各子任务状态 最近事件。在这个基础上我进一步确定了几个设计原则不干扰原终端输出状态栏应该像 tmux 的状态栏一样是独立的区域。刷新要快状态变化后最好 2 秒内能在状态栏体现出来。低成本不要为了显示状态给 Claude Code 本身加太多负担最好只读日志、不改动它的运行逻辑。健壮日志偶尔缺失、格式变化、子任务数量突然增多都不能让脚本崩溃。带着这个需求列表我开始了选型。2. 技术选型与架构设计2.1 终端状态栏方案选型对比要实现“终端底部的状态栏”我试过几种方式这里直接给对比。方案优点缺点适用场景纯 Shell 脚本 tput 模拟底部固定行无额外依赖简单刷新逻辑难做输出容易跟终端内容打架临时调试、极简环境tmux 的 status-right / status-left稳定、自带刷新周期、不干扰主终端需要 tmux依赖其配置日常主力推荐独立常驻进程重绘终端区域控制力最强实现复杂处理终端尺寸变化很麻烦对交互要求极高的场景复用编辑器/IDE 的嵌入式终端图形界面展示友好本质上换了环境不一定适合命令行重度用户团队内部工具我选了tmux 方案原因很实在tmux 天然提供了状态栏容器而且它自带的 status-interval 刷新机制可以让我不用自己写事件循环。我需要做的只是写一个脚本输出一小段文本把它挂到 tmux 的 status-right 里。这样状态栏跟主终端输出完全隔离怎么看都不会乱。如果你没有用 tmux 的习惯我自己也验证过一条备选路线用极简的 Shell 脚本读取最后一次渲染结果通过tput sc、tput rc这类终端控制序列在底部固定一行但说实话比较折腾。建议优先选 tmux省下的时间够你干很多别的事了。2.2 状态数据从哪里来日志解析方案核心问题永远是状态栏的数据源是什么Claude Code 在运行过程中会把大量事件以 JSON Lines 的形式写入日志文件每条日志是一个独立的 JSON 对象包含时间戳、事件类型、关联的上下文信息。Subagent 的创建、启动、完成、出错都会产生对应的事件。所以不需要去改 Claude Code 本身只要读取并解析这些日志就能拿到状态。我采用的链路是这样的Claude Code 运行日志 (JSON Lines) ↓ tail jq 按事件类型过滤 ↓ 提取 Subagent 状态数据 ↓ 渲染为一行文本 ↓ 挂到 tmux status-right在整个链路里解析精度决定了状态栏的准确率而读取策略决定了性能。读取上我用了tail -F来跟踪日志文件末尾避免一次性把超大日志读完解析上我用 jq 做 JSON 字段提取因为 jq 的过滤表达式比 awk 去抠字符串靠谱得多。这里有一个非常关键的经验不同版本的 Claude Code 日志格式有细微差别所以脚本里对事件的匹配字段尽量用“宽松模式”宁可多匹配几种字段名也不要因为一个字段名变化就输出空白。后面我还会讲一个我踩过的具体坑。2.3 目录结构与模块划分我把整套工具拆成了三个模块避免一个文件里挤了太多逻辑后面改起来头大。status-fetch.sh核心的日志解析模块负责读取日志、提取 Subagent 状态。status-render.sh渲染模块把状态数据格式化成状态栏文本内含截断逻辑。config.env配置项比如日志路径、状态栏最大展示数量、刷新间隔。划分之后的好处是如果我想换数据源只改status-fetch.sh如果我想改展示样式只动status-render.sh不想动逻辑的时候调config.env就够了。做小工具也值得保持模块感不要嫌麻烦。3. 安装与配置全过程3.1 环境准备依赖与目录规划这个工具对系统要求不高只要满足下面这几项即可bash 4.0 以上macOS 自带的 bash 3.2 建议先换成新版本或者直接用 zsh 跑也没问题jq 命令tail、grep 等基础命令tmux如果走 tmux 方案Claude Code 命令行工具本身且已经在终端里正常使用在开始之前先确认环境用一行命令检查依赖command -v jq command -v tmux echo deps ok如果缺 jq在 Debian/Ubuntu 上用sudo apt install jqmacOS 上用brew install jq。tmux 同理缺什么装什么。然后我建立了一个独立目录专门放这套工具mkdir -p ~/.claude-status这里也顺手用.gitignore把这个目录排除掉避免以后不小心把它提交到项目仓库里去——虽然只是个小工具但提交错目录这种事我发生过好几次了。3.2 主脚本安装与核心配置我把核心脚本放到~/.claude-status/status-fetch.sh。脚本的职责很简单读取日志文件提取 Subagent 状态输出一行状态文本。下面是我简化后的核心脚本框架你可以直接抄走改#!/usr/bin/env bash # ~/.claude-status/status-fetch.sh # 依赖jq source ~/.claude-status/config.env LOG_FILE${CLAUDE_LOG_FILE:-$HOME/.claude/logs.jsonl} # 从日志尾部读取最近 500 行过滤 Subagent 事件 tail -n 500 $LOG_FILE 2/dev/null | jq -c select(.type subagent_event) | { time: .timestamp, agent: .subagent_id, event: .event_type, detail: .message } | tail -n ${MAX_DISPLAY:-20}这段脚本的逻辑是先定位到日志文件然后取尾部 500 行用 jq 过滤出 subagent 相关事件并提取字段。MAX_DISPLAY控制最多展示多少条避免子任务特别多时状态栏被刷爆。然后对应的渲染脚本status-render.sh核心逻辑是这样#!/usr/bin/env bash # ~/.claude-status/status-render.sh source ~/.claude-status/config.env cd $(dirname $0) # 调用 fetch 脚本获取原始事件 EVENTS$(./status-fetch.sh) # 统计各类状态数量 RUNNING$(echo $EVENTS | jq -s [.[] | select(.event started)] | length) DONE$(echo $EVENTS | jq -s [.[] | select(.event completed)] | length) ERROR$(echo $EVENTS | jq -s [.[] | select(.event error)] | length) TOTAL$(echo $EVENTS | jq -s length) # 渲染输出 printf Subagents: %s | running: %s | done: %s | error: %s \ $TOTAL $RUNNING $DONE $ERROR写完脚本后要给它加执行权限否则 tmux 调用时会报 permission deniedchmod x ~/.claude-status/status-fetch.sh ~/.claude-status/status-render.sh配置项集中在config.env里内容大概是# Claude Code 日志路径 CLAUDE_LOG_FILE$HOME/.claude/logs.jsonl # 状态栏最多展示的事件条数 MAX_DISPLAY20 # tmux 状态栏刷新间隔秒 STATUS_INTERVAL2这里的日志路径和刷新间隔是调整最频繁的参数我建议都拆成配置项不要硬编码在脚本里。我第一次写的时候把路径直接写在脚本里后来换了日志位置改脚本改到崩溃。3.3 挂到 tmux 状态栏上脚本准备好之后剩下的就是让 tmux 的 status-right 调用它。在~/.tmux.conf里加上这几行set -g status-right #(bash ~/.claude-status/status-render.sh) set -g status-interval 2然后重载 tmux 配置tmux source-file ~/.tmux.conf注意一个新手常犯的坑status-right里写#()时tmux 会调用里面的命令但不会自动帮你加载你的PATH。所以脚本路径最好用绝对路径而且脚本内部用到的命令比如 jq也建议写绝对路径或提前确认在 PATH 中。我当时第一次配好发现状态栏是空的折腾了半天最后发现是脚本里找不到 jq。如果你已经临时进入了 tmux 会话也可以用按键直接临时改tmux set -g status-right #(bash ~/.claude-status/status-render.sh)这一招在调试时特别好用因为不用反复 reload 整个配置改完马上能看到效果。3.4 不用 tmux 的替代接入方式我不建议但还是要给需要的朋友一个备选。如果你实在不想用 tmux还有两个可能的接入点利用 Claude Code 自带的 hook 机制在特定事件触发时执行脚本并把最新状态写入一个临时文件用终端的 PROMPT_COMMAND 机制在每次命令提示符出现前刷新底部状态行。第二个方案我用过一个非常轻量的版本在.bashrc里加status_line() { printf \\033[1;30m%s\\033[0m\\n $(~/.claude-status/status-render.sh) } PROMPT_COMMANDprintf \\033[?25l; status_line; printf \\033[?25h原理是每次回车执行命令后、出现新提示符前把渲染好的状态行打印出来。但这里有个体验问题状态行一旦跟命令输出混在一起位置就不固定看着很乱。所以我最终还是没有把它作为日常方案只在快速调试时用。你要长期用真的建议 tmux。4. Subagent 状态展示核心实现4.1 状态数据的解析细节状态栏能不能准确工作决定性因素是日志解析。Claude Code 的日志是 JSON Lines 格式每条事件类似下面这种结构我做过脱敏简化字段含义保持一致{timestamp:2025-01-18T10:23:41.001Z,type:subagent_event,source:main,subagent_id:agent_01,event_type:created,message:Subagent agent_01 created} {timestamp:2025-01-18T10:23:43.512Z,type:subagent_event,source:main,subagent_id:agent_01,event_type:started,message:Subagent agent_01 started} {timestamp:2025-01-18T10:25:55.088Z,type:subagent_event,source:main,subagent_id:agent_01,event_type:completed,message:Subagent agent_01 finished}可以看到关键字段有三个subagent_id、event_type、timestamp。我的解析思路不是模拟一个完整的状态机而是把最近一组事件按 subagent_id 分组取每个 subagent_id 最后一条事件作为它的当前状态。由于日志本身是按时间顺序追加的取“最后一个事件”的操作在实现上就非常自然。核心解析命令如下tail -n 200 $CLAUDE_LOG_FILE 2/dev/null | jq -s map(select(.type subagent_event)) | group_by(.subagent_id) | map({ agent: .[0].subagent_id, status: (map(.event_type) | last) }) 这里的group_by(.subagent_id)会把所有同一子代理的事件聚在一起然后取每个分组里最后一个event_type作为当前状态。这样即使日志里事件很多也能保持状态汇总的正确性。状态值的转换我写了一个映射原始 event_type状态栏展示含义createdwait已创建等待执行startedrun运行中completeddone已完成errorerr异常结束其他unknown未知状态这个映射是我在开发过程中反复调整过的。最初我直接展示原始英文词后来发现状态栏宽度有限created、started、completed这些单词太长了就统一改成短标签。短标签还有一个好处你瞄一眼就能通过颜色或前缀区分不用读完整单词。4.2 状态渲染与截断策略解析出状态列表后渲染模块要做两件事格式化文本、控制长度。格式化部分我最终采用了这种模板Subagents: 5 | a1:run | a2:done | a3:err | 2 more前面的Subagents: 5是总数后面依次是每个子代理的短 ID 和状态。短 ID 我取的是subagent_id最后两段字符既能区分彼此又不会把状态栏撑爆。截断逻辑也非常关键。有一次我跑了一个大任务一次性派发了二十多个 Subagent如果全部展示出来tmux 的 status-right 直接溢出把状态栏挤乱。我在渲染脚本里加了一个最大数量限制MAX_ITEMS${STATUS_MAX_ITEMS:-6} ALL_ITEMS$(... ) # 解析得到的所有条目 TOTAL$(echo $ALL_ITEMS | jq -s length) IFS$(printf \\n) read -r -a items $(echo $ALL_ITEMS | jq -r .[:STATUS_MAX_ITEMS] | group_by(.status) | map(\(.agent):\(.status)) | join(|))实际上一开始实现比这个还要简单粗暴直接用awk把前 N 条串起来超出的部分统计为N more。要控制的是两个变量——N 的大小和状态项的格式。N 设成 6 左右比较合适再多状态栏就挤了。另外一个细节是颜色区分。tmux 的 status-right 支持#[fgcolor]这种内联样式我给不同状态加不同颜色运行中绿色、已完成默认色、异常红色。效果非常直观远远扫一眼就能知道有没有出问题。这算是我这个工具里性价比最高的一个优化。4.3 刷新策略与实时性调优状态栏的实时性取决于两个环节日志写入的速度以及 tmux 状态栏的刷新频率。tmux 的status-interval最小可以设到 1 秒但设太短每次渲染都会重新读取日志日志大的时候会有无畏的 CPU 开销。我测试下来的平衡点是2 秒。还有一点要提如果刷得太快状态栏会频繁跳动反而不如固定节奏稳。把status-interval 2配上脚本里的tail -n 200实测下来既不会漏掉关键事件也不会让风扇转起来。如果你希望状态变化后立即刷新而不是傻等下一轮定时刷新我用过一个小技巧在 tmux 的status-right命令里加一个后台触发set -g status-right #(bash ~/.claude-status/status-render.sh | \ if [[ \$(cat ~/.claude-status/last_hash) ! \$(sha1sum \$(cat ~/.claude-status/data.json)) ]]; then \ tmux refresh-client -S -; fi)不过这个方案在实际使用中收益不大因为 2 秒的间隔已经足够感知状态变化。过度优化反而带来复杂性后面维护起来麻烦。我的建议就是先设 2 秒用几天如果觉得响应慢再往 1 秒调不要一开始就加复杂机制。4.4 日志变化时的自适应处理Claude Code 本身在更新日志格式也可能跟着变。我刚写完这个工具没几天就遇到了一个情况某次版本升级后event_type字段从started变成了started_at结果状态栏全是unknown等于整个工具失效了。为了解决这类问题我后来在解析脚本里加了一个字段兼容层对同一种语义的状态名做映射不再死板匹配一个值。normalize_status() { case $1 in created|pending|queued) echo wait ;; started|running|executing) echo run ;; completed|finished|succeeded) echo done ;; error|failed|exception) echo err ;; *) echo unknown ;; esac }有了这个兼容层即使日志字段小范围变化状态栏也不会立刻崩溃。把这种防御逻辑放在最底层解析里后面能省很多麻烦。5. 常见问题与排查实录5.1 状态栏显示为空或不刷新这是我遇到最多的一个问题而且每次出问题用户反馈都高度相似tmux 配置加载了、脚本也放好了status-right 就是空的。排查顺序我建议这样走先手动执行一次渲染脚本bash ~/.claude-status/status-render.sh看有没有输出。如果输出为空那就是解析层出问题再单独执行bash ~/.claude-status/status-fetch.sh看日志读取和 jq 解析是否正常。如果脚本单独跑有输出在 tmux 里却是空优先怀疑 tmux 的 PATH 环境。用绝对路径、在脚本里显式定义 jq 路径就能解决。我自己遇到的一个真实问题是漏了chmod xtmux 调用脚本时报 permission denied但在终端手动用bash调用却一切正常因为bash不依赖直接执行权限。后来我学乖了每次新增脚本后的第一件事就是chmod x。5.2 Subagent 数量太多导致状态栏错位当一次任务派生几十个子代理时状态栏会被长文本撑爆。表现就是 tmux 状态栏出现“挤行”、右侧内容被截掉或者状态栏换行。解决方法就是我前面提到的截断策略。我在渲染层加了两层保险最多只展示前STATUS_MAX_ITEMS个子代理其余用N more汇总单个状态项的短 ID 固定长度超长截断。具体到参数我通常设STATUS_MAX_ITEMS6。试过 10但那种密度下眼睛反而不容易聚焦。6 是一个自己用下来比较舒服的值。还有一个辅助技巧如果异常子代理特别多我会在状态栏里额外加一个“异常列表”字段把最近的异常子代理 ID 放进去方便快速定位。5.3 多个终端会话共享同一个状态栏这个问题的场景是我同时开了多个 tmux 窗口分别在不同项目里跑 Claude Code。默认配置下所有窗口共用一个全局 status-right导致 A 项目的状态显示到了 B 项目的窗口里相当混乱。解法是让 status-right 根据当前窗口或当前目录动态渲染。我改成了这样set -g status-right #(bash ~/.claude-status/status-render.sh #{pane_current_path})然后在渲染脚本里接收当前路径参数用它把日志读取范围限定为当前项目目录下的 Claude Code 日志。如果你的 Claude Code 本身就是项目级日志这一步会非常顺。值得说明的是这需要 Claude Code 支持项目级日志输出如果你的版本还是全量日志写到同一个文件那状态栏就不可能精确区分项目。此时退而求其次可以在状态栏展示“最近一条事件来自哪个项目”至少能帮你区分方向。5.4 性能开销控制状态栏脚本每 2 秒跑一次如果日志文件已经很大tail -n 200加上 jq 解析还是有开销的。在巨量日志场景下我发现瞬时 CPU 占用会跳到明显可见的程度。优化思路是分层用tail -n限制解析行数避免全量扫描解析结果缓存在临时文件里如果日志文件没有变化就直接复用降低刷新频率从 2 秒变成 3 秒感知差异不大但 CPU 占用明显下降。实测下来200 行日志 jq 解析单次执行时间在十几毫秒到几十毫秒之间加上缓存后几乎可以忽略。除非你的日志文件大得离谱否则不用太担心性能。5.5 日志文件被轮转导致的读取中断Claude Code 在长时间运行后日志文件可能按天或按大小轮转新的日志会写到新文件里。如果你一直用tail -F跟踪旧文件切换后状态栏就再也读不到新日志了。解决方式有两个一种是用tail -F跟踪当前实际路径它能自动跟随重命名另一种是在配置里使用通配路径比如~/.claude/logs/*.log但这样需要在脚本里处理“按修改时间选择最新文件”的逻辑。我最终选择了按天切换的方式每天第一次执行状态下拉时解析脚本会检查当天的日志文件名自动切换。这个改动不复杂却能避免早上开电脑之后状态栏持续停在昨天的状态上。6. 界面效果与使用体验调整6.1 状态栏文案与颜色调整技巧状态栏做出来后我花了不少时间在“文案优化”上。刚开始我用了很长的描述比如subagent-01 is running在窄终端里会显得很挤。后来统一改成紧凑格式Subagents: 5 | a1:run | a2:done | a3:errtmux 支持在 status-right 里用#[fgcolour]改颜色我做了这样一个映射case $STATUS in run) COLOR#[fggreen] ;; done) COLOR#[fgdefault] ;; err) COLOR#[fgred] ;; wait) COLOR#[fgyellow] ;; esac这个改动让我在远处看一眼就知道整体有没有问题。状态栏本来就是为了“扫一眼”存在的不要把所有都想靠文字表达。6.2 适配不同终端宽度tmux 的状态栏在终端窗口变窄的时候会自动处理一部分但 status-right 自身的内容过长时还是会截断。为了在不同窗口宽度下都保持可读我加了一个简单的策略根据终端宽度动态调整展示的 Subagent 数量。COLUMNS$(tput cols) if [ $COLUMNS -lt 100 ]; then MAX_ITEMS3 elif [ $COLUMNS -lt 180 ]; then MAX_ITEMS6 else MAX_ITEMS10 fi这样在外接屏幕和笔记本屏幕之间切换时状态栏都能保持在一个可接受的宽度内。极客朋友可能觉得这算过度设计但当你天天面对这个状态栏时这点细节真的能提升舒适度。6.3 我把上次状态也放进状态栏的小细节有一次我跑了一个很重的任务中途去喝了杯水回来之后想知道在我离开的几分钟里有没有 Subagent 已经完成任务或报错。但状态栏此时只显示当前的最新快照历史信息没有了。后来我加了一个字段last: completed agent_02 at 10:25展示最近一次状态变化的事件。实现上就是在渲染脚本里额外读取最近一条非 started 事件。效果很好因为你不需要翻日志就能感知“刚才发生了什么”。这个小字段后来成了我最常用的信息。7. 项目后续扩展与个人经验总结7.1 还能怎么扩展这个状态栏这个状态栏工具做到底之后我发现它的架构其实可以承载更多信息不只是 Subagent 状态。比如我想过把 token 消耗显示在状态栏里只要日志里能提取出 token 字段就能把每次调用的 token 数和累计数渲染出来。再比如把最近的错误消息摘要也加到状态栏里通过关键词过滤出 error 级别的事件给出前几条简短文本提示。还有一个扩展方向多项目状态看板。如果你同时维护多个项目、每个项目各跑了一个 Claude Code 会话可以在一个总览状态栏里把各自的项目名、运行状态、异常数量都列出来。这个想法我后来验证过技术上就是读取多个日志文件汇总渲染难度不大但对团队协作来说还挺有用的。7.2 个人踩坑与经验总结回头看看整个开发过程最深的体会有三点。第一解析层要做好兼容。Claude Code 迭代很快日志字段名说变就变。我在 4.4 里加了 normalize_status 之后工具稳定性高了很多。如果你只是自己用可以不加但如果想长期维护这层防御很值得。第二状态栏应该是一个“汇总层”而不是另一个“日志流”。最开始我差点直接往状态栏里塞原始事件后来发现根本没必要。状态栏越短信息密度越高用起来越顺手。把详细信息留在日志里状态栏只给出干脆利落的结论。第三接入 tmux 状态栏是最值得的决定。不用自己写循环调度、不用处理终端重绘、不用管刷新频率tmux 全给你管好了。如果一开始我选择自己写一个常驻进程估计要多花好几倍时间。利用现成的容器机制永远是最快出效果的路径。7.3 最后分享一个小技巧如果你用了这个工具之后发现状态栏偶尔还是跟不上任务节奏我建议你重点检查一下刷新链路里最弱的一环——通常不是 tmux而是日志文件写入频率。Claude Code 在跑子任务时日志写入是有批处理和延迟的。状态栏显示“等一下”其实不是它的错而是日志还没落盘。这个没法从脚本层面根治但可以通过一个折中方案缓解在渲染脚本里查一下日志文件的修改时间如果和当前时间差异超过 10 秒就显示一个刷新滞后提示。选这个方案比反复调大刷新频率靠谱得多。这个工具我自己用了很长时间最大的感受不是“多酷炫”而是终端里跑长任务的时候心里终于有一个明确的位置可以观察进度了。如果你也在用 Claude Code 处理多子任务、多步骤的重活照这套思路搭一个状态栏会让整个终端使用体验改善不少。
