automate-this

自动完成这件事

分析一段手动操作的屏幕录制，并为其构建可用的自动化方案。

用户录下自己反复做某件重复或繁琐的事，把视频文件交给你，然后你要弄清他们在做什么、为什么做，以及如何用脚本把它自动化掉。

前置条件检查

在分析任何录制之前，先确认所需的工具是否可用。静默运行这些检查，仅在出现问题时才提示：

command -v ffmpeg >/dev/null 2>&1 && ffmpeg -version 2>/dev/null | head -1 || echo "NO_FFMPEG"
command -v whisper >/dev/null 2>&1 || command -v whisper-cpp >/dev/null 2>&1 || echo "NO_WHISPER"

• 必须要有 ffmpeg。 如果缺失，告诉用户：brew install ffmpeg（macOS）或适用于其操作系统的等效命令。
• Whisper 是可选的。 仅当录制中有旁白时才需要。如果缺失且录制包含音轨，建议：pip install openai-whisper 或 brew install whisper-cpp。如果用户拒绝，则仅进行视觉分析。

阶段 1：从录制中提取内容

给定视频文件路径（通常在 ~/Desktop/ 上），同时提取视觉帧和音频：

帧提取

每 2 秒提取一帧。这样可以在覆盖范围和上下文窗口限制之间取得平衡。

WORK_DIR=$(mktemp -d "${TMPDIR:-/tmp}/automate-this-XXXXXX")
chmod 700 "$WORK_DIR"
mkdir -p "$WORK_DIR/frames"
ffmpeg -y -i "<VIDEO_PATH>" -vf "fps=0.5" -q:v 2 -loglevel warning "$WORK_DIR/frames/frame_%04d.jpg"
ls "$WORK_DIR/frames/" | wc -l

在本会话中，所有后续临时文件路径都使用 $WORK_DIR。每次运行使用权限模式 0700 的目录，可确保提取的帧仅能被当前用户读取。

如果录制时长超过 5 分钟（超过 150 帧），将间隔增大到每 4 秒一帧，以保持在上下文限制内。告诉用户，对于较长的录制，你将降低采样频率。

音频提取与转写

检查视频是否包含音轨：

ffprobe -i "<VIDEO_PATH>" -show_streams -select_streams a -loglevel error | head -5

如果存在音频：

ffmpeg -y -i "<VIDEO_PATH>" -ac 1 -ar 16000 -loglevel warning "$WORK_DIR/audio.wav"

# Use whichever whisper binary is available
if command -v whisper >/dev/null 2>&1; then
  whisper "$WORK_DIR/audio.wav" --model small --language en --output_format txt --output_dir "$WORK_DIR/"
  cat "$WORK_DIR/audio.txt"
elif command -v whisper-cpp >/dev/null 2>&1; then
  whisper-cpp -m "$(brew --prefix 2>/dev/null)/share/whisper-cpp/models/ggml-small.bin" -l en -f "$WORK_DIR/audio.wav" -otxt -of "$WORK_DIR/audio"
  cat "$WORK_DIR/audio.txt"
else
  echo "NO_WHISPER"
fi

如果两个 whisper 二进制文件都不可用，且录制包含音频，告知用户他们缺少旁白上下文，并询问他们是想要安装 Whisper（pip install openai-whisper 或 brew install whisper-cpp），还是仅进行纯视觉分析。

阶段 2：重建流程

分析提取的帧（以及转写文本，如果有的话），以构建对用户所做操作的结构化理解。按顺序逐帧查看，并识别：

1. 使用的应用程序 — 录制中出现了哪些应用？（浏览器、终端、Finder、邮件客户端、电子表格、IDE 等）
2. 操作顺序 — 用户按什么顺序做了什么？一步一步，点击接点击。
3. 数据流 — 信息在各步骤之间如何流转？（复制的文本、下载的文件、表单输入等）
4. 决策点 — 是否存在用户暂停、检查某些内容或做出选择的时刻？
5. 重复模式 — 用户是否用不同输入多次做同一件事？
6. 痛点 — 流程在哪里显得缓慢、容易出错或繁琐？旁白往往直接揭示了这一点（“我讨厌这部分”“这总是要花很久”“每一个我都得这么做”）。

将这一重建结果以编号步骤列表的形式呈现给用户，并在提出自动化方案之前请他们确认其准确无误。这一点至关重要 — 错误的理解会导致无用的自动化。

格式：

Here's what I see you doing in this recording:

1. Open Chrome and navigate to [specific URL]
2. Log in with credentials
3. Click through to the reporting dashboard
4. Download a CSV export
5. Open the CSV in Excel
6. Filter rows where column B is "pending"
7. Copy those rows into a new spreadsheet
8. Email the new spreadsheet to [recipient]

You repeated steps 3-8 three times for different report types.

[If narration was present]: You mentioned that the export step is the slowest
part and that you do this every Monday morning.

Does this match what you were doing? Anything I got wrong or missed?

在用户确认重建结果准确之前，不要进入阶段 3。

阶段 3：环境指纹

在提出自动化方案之前，先了解用户实际可用的条件。运行这些检查：

echo "=== OS ===" && uname -a
echo "=== Shell ===" && echo $SHELL
echo "=== Python ===" && { command -v python3 && python3 --version 2>&1; } || echo "not installed"
echo "=== Node ===" && { command -v node && node --version 2>&1; } || echo "not installed"
echo "=== Homebrew ===" && { command -v brew && echo "installed"; } || echo "not installed"
echo "=== Common Tools ===" && for cmd in curl jq playwright selenium osascript automator crontab; do command -v $cmd >/dev/null 2>&1 && echo "$cmd: yes" || echo "$cmd: no"; done

用这些信息将方案限制在用户已具备的工具范围内。除非更简单的路径确实行不通，否则绝不要提出需要安装五样新东西的自动化方案。

阶段 4：提出自动化方案

基于重建的流程和用户的环境，最多分三个层级提出自动化方案。并非每个流程都需要三个层级 — 请自行判断。

层级结构

第 1 层 — 快速见效（搭建时间不超过 5 分钟） 最小可用的自动化。一个 shell 别名、一行命令、一个键盘快捷键、一段 AppleScript 代码片段。只自动化最痛苦的那一步，而不是整个流程。

第 2 层 — 脚本（搭建时间不超过 30 分钟） 一个独立脚本（bash、Python 或 Node —— 用户手头有哪个就用哪个），端到端自动化整个流程。能处理常见错误。可在需要时手动运行。

第 3 层 — 完全自动化（搭建时间不超过 2 小时） 在第 2 层脚本的基础上，再加上：定时执行（cron、launchd 或 GitHub Actions）、日志记录、错误通知，以及任何必要的集成脚手架（API 密钥、认证令牌等）。

方案格式

针对每一层，提供：

## Tier [N]: [Name]

**What it automates:** [Which steps from the reconstruction]
**What stays manual:** [Which steps still need a human]
**Time savings:** [Estimated time saved per run, based on the recording length and repetition count]
**Prerequisites:** [Anything needed that isn't already installed — ideally nothing]

**How it works:**
[2-3 sentence plain-English explanation]

**The code:**
[Complete, working, commented code — not pseudocode]

**How to test it:**
[Exact steps to verify it works, starting with a dry run if possible]

**How to undo:**
[How to reverse any changes if something goes wrong]

特定应用的自动化策略

根据录屏中出现的应用，选用以下策略：

基于浏览器的工作流：

• 首选：检查该网站是否有公开 API。API 调用比浏览器自动化可靠 10 倍。搜索 API 文档。
• 次选：对于端点已知的简单 HTTP 请求，使用 curl 或 wget。
• 第三选择：对于需要点击 UI 的工作流，使用 Playwright 或 Selenium。优先选择 Playwright —— 它更快、更稳定。
• 寻找规律：如果用户反复从某个仪表盘下载同一份报告，那它几乎肯定可以通过 API 或带查询参数的直接 URL 获取。

电子表格和数据工作流：

• 使用 Python 配合 pandas 进行数据筛选、转换和聚合。
• 如果用户在 Excel 中做简单的列操作，一个 5 行的 Python 脚本就能替代整个手动流程。
• 使用 csvkit 无需写代码即可快速进行命令行 CSV 操作。
• 如果输出需要保持 Excel 格式，使用 openpyxl。

电子邮件工作流：

• macOS：osascript 可以控制 Mail.app 发送带附件的电子邮件。
• 跨平台：使用 Python 的 smtplib 发送，imaplib 读取。
• 如果邮件遵循某个模板，通过变量替换从模板文件生成正文。

文件管理工作流：

• 使用 shell 脚本处理移动/复制/重命名模式。
• 使用 find + xargs 进行批量操作。
• 使用 fswatch 或 watchman 实现变更触发的自动化。
• 如果用户按日期或类型将文件整理到文件夹中，那只是一个 3 行的 shell 脚本。

终端/命令行工作流：

• 为频繁输入的命令设置 shell 别名。
• 为多步骤序列编写 shell 函数。
• 为项目特定的任务集编写 Makefile。
• 如果用户用不同参数运行了同一条命令，那就是一个循环。

macOS 特定工作流：

• 使用 AppleScript/JXA 控制原生应用（Mail、Calendar、Finder、Preview 等）。
• 对于不需要代码的简单多应用工作流，使用 Shortcuts.app。
• 使用 automator 处理基于文件的工作流。
• 使用 launchd plist 文件执行定时任务（在 macOS 上优先于 cron）。

跨应用工作流（数据在应用之间流转）：

• 识别数据传输点。每一次传输都是一个自动化机会。
• 录屏中基于剪贴板的数据传输表明这些应用之间并不互通 —— 应转而寻找 API、基于文件的交接或直接集成。
• 如果用户从应用 A 复制并粘贴到应用 B，自动化应直接从 A 的数据源读取，并以 B 的输入格式写入。

让提案更有针对性

将以下原则应用于每个提案：

1. 优先自动化瓶颈环节。 录像中的旁白和时间信息能揭示哪一步才是真正痛苦的。对最糟糕的环节做 30 秒的自动化，胜过对整个流程做 2 小时的自动化。

2. 匹配用户的技能水平。 如果录像中的人对终端操作驾轻就熟，就提议用 shell 脚本。如果录像中的人在图形界面里操作，就提议用某种简单触发方式（双击脚本、运行快捷指令，或输入一条命令）。

3. 估算真实节省的时间。 统计录像时长，再乘以他们执行该操作的频率。“这段录像 4 分钟。你说你每天都做这件事。那就是每年 17 小时。第 1 档把它缩短到每次 30 秒——你就能拿回 16 小时。”

4. 覆盖 80% 的常见情况。 自动化的第一个版本应完美覆盖常见路径。边缘情况可以在第 3 档中处理，或标记为需要人工介入。

5. 保留人工检查点。 如果录像显示用户在流程中途审阅或批准了某些内容，就把它保留为手动步骤。不要自动化需要判断的决策。

6. 提议试运行。 每个脚本都应有一种模式，只展示它将会做什么而不实际执行。在破坏性操作前使用 --dry-run 标志、预览输出或确认提示。

7. 考虑认证和密钥。 如果流程涉及登录或使用凭据，绝不要硬编码它们。使用环境变量、钥匙串访问（macOS 的 security 命令），或在运行时提示输入。

8. 考虑失败模式。 如果网站宕机了会怎样？如果文件不存在呢？如果格式变了呢？好的提案会提到这些情况并加以处理。

第 5 阶段：构建与测试

当用户选定某一档后：

1. 将完整的自动化代码写入文件（建议一个合适的位置——如果用户有项目目录就用它，否则用 ~/Desktop/）。
2. 在用户旁观下走一遍试运行或测试。
3. 如果测试通过，演示如何正式运行。
4. 如果失败，诊断并修复——不要一次尝试后就放弃。

清理

分析完成后（无论结果如何），清理提取出的帧和音频：

rm -rf "$WORK_DIR"

告诉用户你正在清理临时文件，让他们知道没有留下任何残留物。