换成 Voyager 这类桌面端一体化流程，省下来的主要不是单个工具里的点击速度，而是衔接处：一天里在工具之间来回切换的次数、同一份素材在目录之间被复制的次数，以及「流程走到哪一步」这个状态记在什么地方。这三项都能在半天到一天内数出来，数完再决定装不装，比先装再适应更可控。下面给记录方式和判断依据，结论由读者自己的数字决定。

判断方向：先做一天基线，把工具切换、文件复制、状态记录各记一遍，再看桌面端能否在同一个界面里覆盖其中重复最多的触发点。适用场景是每天跑多次、素材需要多步转换的小流程；如果任务一周只有一两次，或者已有脚本把步骤串起来，迁移到桌面端的收益通常抵不过学习与改写成本。记录只用来对比自己的流程，不用来给工具排名；桌面端是否合适，仍要以实际跑一遍任务的落盘位置和界面行为为准。

先数清当前流程一天发生多少次工具切换

把「麻烦」变成可数的东西，只需要一张表和一支笔。每发生一次切换就记一行，重点是触发原因，而不是时间精确到秒。触发原因写得越具体越好，「格式转换」「看图对齐」「跑脚本」「查报错」「改文件名」比「处理素材」有用得多。

不想手写也可以用一行命令追加日志，收工后按触发原因聚合：

# 每发生一次切换追加一行
printf '%s,%s,%s,%s\n' "$(date +%H:%M)" "编辑器" "终端" "跑转码脚本" >> ~/flow-switch.log

# 收工后看哪类触发原因重复最多
cut -d, -f4 ~/flow-switch.log | sort | uniq -c | sort -rn

手工记录通常会有遗漏，记一天足够看出模式。判断标准不是切换次数多少，而是某个触发原因是否反复出现、且每次的输入输出格式一致；一致的那部分，才是一体化流程可能接手的部分。

统计同一份素材在几个目录之间被复制了几次

搬运是容易被忽略的成本，因为复制粘贴本身只要一秒，但每次复制都制造一个未来要判断「哪份是准的」的问题。梳理方式是从最终产物反推：写下产物路径，再往回找它的输入路径，一直找到原始素材，中间每跳一次记一条「源路径 → 目标路径 → 谁读谁写」。

# 1. 先看哪些文件名在工作目录里出现了不止一次
find ~/work -type f -printf '%f\n' | sort | uniq -d

# 2. 针对重复的基名，列出各自路径和修改时间
find ~/work -type f -name 'transcript.md' -printf '%TY-%Tm-%Td %TH:%TM\t%p\n' | sort

macOS 自带的 find 通常不支持 -printf，可以换成 find ~/work -type f -exec stat -f '%Sm %N' {} + 来对比修改时间。版本混乱的典型表现不复杂：文件名靠 final、final2、日期后缀区分；同一份素材在三个位置有三种尺寸；修改只发生在其中一份，其余副本变成陈旧输入；下游已引用了某一份，却无法判断引用的是哪一版，于是清理时谁也不敢删。出现其中两条以上，说明流程缺一个权威路径，而不是缺一个更快的复制动作。

看流程状态记录在哪：脑子里、聊天记录还是项目文件里

状态外置程度决定返工成本。同样一个任务被打断两小时，状态记在不同位置，恢复代价差别很大。

• 记在脑子里：会议、第二天、换机器都会导致上下文重建；并行两个任务时容易串线；无法移交给别人。
• 记在聊天记录里：顺序是时间序不是流程序，检索只能靠关键词；消息里的文件路径随目录调整失效；清理会话后状态直接消失；协作者看不到你的上下文。
• 记在项目文件里：需要维护纪律，好处是可 diff、可复现、可移交。最小做法是在工作目录里留一个状态文件，只写「当前在哪一步」和「下一步的输入是什么」。

# job.yaml 示例，放在工作目录里，任何工具都能读写
task: 素材转写与配图
input: work/raw/clip.mp4
steps:
  - name: 提取音频
    status: done
  - name: 转写
    status: doing
    output: work/out/transcript.md
  - name: 配图
    status: todo
    depends_on: work/out/transcript.md

判断桌面端是否值得换，先看同一份状态信息能否写在项目目录里、并且被界面读出，而不是只存在界面的内存中。

把这三项对应到桌面端可验证的界面行为

不要凭界面观感下结论，按维度找到具体入口，再用一个真实小任务跑一遍。

是否值得迁移的判断清单：

• 可以先试：某个触发原因一天重复多次且输入输出格式一致；同一素材在三个以上路径出现；状态主要靠记忆和聊天记录维持。
• 暂缓：任务一周只有一两次、每次一个文件；已有脚本把步骤串起来；核心步骤依赖桌面端没有的专业功能。
• 小范围对比：拿一个真实任务在新旧两种方式各跑一次，记录切换次数、产物落盘目录数、中断后恢复所需动作，再决定是否把常用流程整体搬过去。

列出不值得迁移的场景

划清边界比论证收益更重要，避免为了统一而统一。

• 单文件轻量任务：一周几次、每次一个文件、步骤固定，打开桌面端本身要等加载，还得先把文件导进工作目录，点击次数反而增加。
• 已有稳定脚本流水线：脚本已经把提取、转换、输出串起来，工具切换接近零。迁移意味着把脚本逻辑搬进界面或重新接线，回退成本高，收益不明显。
• 强依赖特定专业功能：精细图像处理、特定格式校验、特定调试器，桌面端通常只覆盖通用步骤，剩下的仍要回到原工具，等于多一层跳转。
• 协作方各自工具链不同：统一桌面端只在你自己的机器上成立，交付格式和目录约定依然要单独维护，一体化流程解决不了跨人的约定问题。
• 有环境或审计约束：必须在指定环境内执行、需要保留原始命令记录时，界面化步骤如果无法导出等价命令，复核反而变难。

把这五项与上面的自查记录对上，如果多数命中，保留现有单点工具组合、只在衔接处补一个状态文件，通常是更稳的选择；如果三项维度都指向同一类重复动作，再考虑把那条流程整体搬进桌面端，并在迁移后重跑一次同样的记录，用新数字对照旧数字。