三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

CLI-Anything：为任意软件封装命令行接口，让AI代理无缝操作GUI应用

发布时间：2026/8/11 4:53:29 三亩地 编程学习日记
CLI-Anything：为任意软件封装命令行接口，让AI代理无缝操作GUI应用

1. 项目概述：当AI代理遇上命令行

最近在折腾AI应用开发，特别是AI Agent（智能代理）这块，发现一个挺有意思的瓶颈：很多想法很美好，比如让AI帮我自动整理文件、分析日志、甚至操作专业软件，但真到动手实现时，却发现AI和这些软件之间隔着一道厚厚的墙。AI模型再聪明，它也没法直接“点击”一个图形界面按钮，或者“理解”一个没有开放API的桌面应用在干嘛。这感觉就像你有一个超级能干的助手，但他只会说一种语言，而你的工具们说的却是另一种。

这就是我遇到CLI-Anything这个开源项目时的背景。它的核心目标非常直接，甚至有点“暴力美学”的味道：把任何你能想到的软件，都给它套上一个命令行接口（CLI）的壳，让AI代理能够通过标准的文本指令来调用和操作它。简单来说，它致力于成为AI世界和人类软件世界之间的“万能翻译官”和“标准操作员”。

你可能会想，这不就是给软件写个脚本吗？但CLI-Anything的野心和设计思路远不止于此。它瞄准的是“任意软件”，尤其是那些原本没有CLI、或者CLI功能极其有限的图形界面（GUI）软件。它的工作方式，不是去破解或修改原软件，而是通过一种“外部观察与控制”的机制，模拟用户操作，并将操作过程和结果标准化。这对于AI Agent生态来说，是一个关键的基础设施。因为只有当下层工具的操作接口变得统一、可预测、可编程时，上层的AI才能稳定、可靠地串联起复杂的任务流。

举个例子，你想让AI Agent帮你完成“从某设计软件导出一张图，用图片处理软件调整尺寸并添加水印，最后上传到网盘”这一系列操作。如果每个软件都有稳定、规范的CLI，AI只需要按顺序发送几条文本命令即可。但现实是，这些桌面软件往往没有这样的接口。CLI-Anything试图填补的就是这个空白，它让AI代理调用Photoshop、Premiere、甚至一个古老的单机游戏，都变得像调用ls或grep命令一样简单。接下来，我就结合自己的研究和实验，拆解一下这个项目的核心思路、实现原理以及在实际应用中可能遇到的“坑”。

2. 核心设计思路与架构拆解

CLI-Anything的设计哲学可以概括为“桥接”与“抽象”。它不关心目标软件内部是如何实现的，只关心如何从外部与之交互，并将这种交互模式化。

2.1 核心问题定义：AI代理需要什么样的接口？

要理解CLI-Anything，首先要明白AI Agent在调用外部工具时面临的需求：

  1. 标准化输入/输出（I/O）：AI模型处理的是文本（或结构化的文本，如JSON）。因此，工具最好能以纯文本形式接受指令并返回结果。命令行天生就是文本驱动的，这是最佳匹配。
  2. 确定性行为：相同的命令输入，应该产生相同或可预期的输出。图形界面的操作往往涉及像素坐标、焦点状态等不确定因素，需要被消除或标准化。
  3. 状态可查询：AI需要知道命令执行后软件的状态（例如，“文件是否保存成功？”、“处理进度到哪了？”）。一个良好的CLI应该能提供状态查询命令。
  4. 错误可捕获：执行失败时，必须提供明确的、机器可读的错误信息，而不是弹出一个只有人类能处理的对话框。

传统的软件，尤其是GUI软件，很少为这些需求而设计。CLI-Anything的架构就是围绕解决这些问题而构建的。

2.2 整体架构：三层抽象模型

通过对项目代码和文档的分析，我发现其架构大致可以分为三层，这很好地体现了它的设计思路：

第一层：驱动适配层（Driver Adapter）这是最底层，直接与目标软件交互。因为不同软件的技术栈和交互方式天差地别，所以这一层需要多种“驱动”。

  • 系统自动化驱动：对于macOS，可能是AppleScript；对于Windows，可能是AutoHotkey或UI Automation；对于Linux，可能是DBus或xdotool。这些工具可以模拟键盘鼠标操作、读取窗口信息。
  • 网络协议驱动：如果软件提供WebSocket、HTTP API等接口，则可以直接通过协议驱动进行更精准的调用。
  • 命令行包装驱动：对于已有基础CLI但功能不全的软件，此驱动对其进行增强和封装。 这一层的目标是：无论用什么方法，只要能驱动目标软件执行一个“动作”（如打开文件、点击菜单、输入文本），并将其包装成一个统一的内部调用接口。

第二层：命令抽象与映射层（Command Abstraction）这是核心的“翻译”层。它定义了一套标准的、软件无关的“原子操作”元命令。例如：

  • open(file_path)
  • click(ui_element_identifier)
  • input(text, field_identifier)
  • read(area_identifier)
  • execute(internal_command)
  • get_status()驱动层传来的具体操作（如“在坐标(100,200)点击”），会被映射成这些元命令。同时，这一层还负责将多个原子操作组合成有意义的“复合命令”，比如一个export_image(format=‘png’, resolution=‘300dpi’)命令，可能由click(‘文件菜单’)、click(‘导出’)、input(‘300’, ‘分辨率输入框’)、click(‘确定按钮’)等一系列原子操作组成。

第三层：CLI生成与暴露层（CLI Generator）这是面向AI Agent（或用户）的最终接口层。它将第二层的复合命令，生成为一个真正的、可独立执行的命令行程序。这个生成的CLI程序具有：

  • 标准的帮助文档（--help）：AI可以通过阅读帮助来了解该工具有哪些功能。
  • 结构化的参数解析：支持位置参数、可选参数、标志等。
  • 标准化的输出流：结果输出到stdout，错误和日志输出到stderr，退出码（Exit Code）表示成功或失败类型。
  • 配置与上下文管理：能够记住一些会话状态，比如当前打开的文件路径。

这种三层架构的好处是清晰解耦。想要支持一个新软件，主要工作集中在第一层（写驱动适配器）；一旦适配完成，第二层和第三层可以自动或半自动地为其生成一套完整的CLI工具集。AI Agent只需要调用最终生成的这个CLI程序，就像调用系统自带的curl或ffmpeg一样简单。

3. 关键技术实现与难点剖析

理解了架构，我们来看看它是如何实现“控制任意软件”这个魔法般的承诺的。这里面的技术挑战不小，CLI-Anything采用了一些巧妙但实际的方法。

3.1 GUI自动化与控制：不是简单的“录屏回放”

很多人第一反应是使用“按键精灵”类的宏录制工具。但那种方式脆弱且不智能。CLI-Anything追求的是一种更健壮、可编程的自动化。

1. UI元素识别与定位这是GUI自动化的基石。项目需要能稳定地找到目标按钮、输入框或菜单。

  • 首选方案：可访问性树（Accessibility Tree）：现代操作系统的UI框架（如Windows的UIA， macOS的AXAPI， Linux的AT-SPI）都提供了可访问性接口，原本是为辅助功能设计的。这些接口能以结构化的方式暴露UI元素的层级、类型、名称、状态等信息。CLI-Anything的驱动层会优先尝试通过这个渠道定位元素，因为它稳定、不依赖视觉外观、且与屏幕分辨率无关。例如，它可以通过name=“保存”和role=“button”来精准定位保存按钮，而不是通过容易变化的屏幕坐标(100, 200)。
  • 备选方案：图像识别与OCR：对于老旧或自定义绘制的控件，可访问性接口可能失效。此时会退而求其次，使用计算机视觉库（如OpenCV）进行模板匹配来定位按钮图标，或使用OCR（如Tesseract）识别界面上的文字，再结合相对坐标进行点击。但这种方案速度慢、受主题和字体影响大，是保底策略。
  • 混合策略与锚点：在实际实现中，常采用混合策略。例如，先通过可访问性接口定位主窗口，再在窗口区域内使用相对坐标或图像识别定位其内部的特定区域。同时，会建立“锚点”概念，即使界面局部变化，只要锚点元素还在，就能重新校准坐标。

2. 操作执行与同步点击、输入等操作本身不难，难在确保操作发生在正确的时机。

  • 等待与超时机制：在执行click(“下一步按钮”)前，必须确保“下一步按钮”已经处于可点击状态（enabled且visible）。驱动层需要实现智能等待，轮询检查元素状态，并设置合理的超时时间，避免脚本卡死。
  • 操作后状态验证：点击后，如何知道操作成功了？是等待某个新窗口弹出，还是等待当前窗口的某个元素消失或文本改变？CLI-Anything需要为每个复合命令定义“成功条件”。例如，save()命令的成功条件可能是“文件菜单下的‘保存’按钮变为灰色（不可用）”，或者“状态栏出现‘已保存’文字”。
  • 异常对话框处理：这是自动化脚本最大的敌人。一个意外的错误弹窗会阻断整个流程。健壮的驱动需要包含“异常处理子流程”。例如，在执行主要任务前，先启动一个监控线程，监听是否有标题包含“错误”、“警告”的窗口弹出，一旦发现，则根据预设策略进行点击“确定”或“取消”，并向上层返回明确的错误信息。

3.2 CLI的生成与封装：打造AI友好的工具

生成了一个.exe或可执行脚本，并不等于就有了一个好用的CLI。CLI-Anything在这一层做了大量工作来提升工具的可用性，尤其是对AI调用方。

1. 自描述与发现生成的CLI必须能清晰地告诉调用者“我能干什么”。这通过以下方式实现：

  • 丰富的--help输出：不仅列出命令和参数，还会描述每个命令的用途、示例，甚至可能产生的副作用。
  • list-commands子命令：提供一个专门的命令来枚举所有可用的复合命令，AI Agent可以先调用这个命令来探索工具能力。
  • 输出Schema定义：对于返回复杂数据的命令（如get_document_stats），其输出的JSON结构应该是明确定义且稳定的，AI可以据此解析。

2. 状态管理与会话有些操作是有状态的。比如，你先用open(“project.aep”)打开了一个After Effects项目，后续的add_layer()命令应该作用于这个已打开的项目，而不是重新开一个。

  • 进程句柄保持：驱动层在打开软件后，需要持有该进程的句柄或连接，以便后续命令发送到同一个实例。
  • 上下文标识符：对于支持多实例或多文档的软件，CLI命令可能需要一个--context或--session-id参数来指定操作对象。这个上下文信息可能需要通过临时文件、环境变量或轻量级服务来维护。

3. 输出格式化与流式处理为了便于AI处理，输出格式至关重要。

  • 默认结构化输出（JSON）：这是最AI友好的方式。几乎所有命令的结果都以JSON格式输出到stdout，包含status,data,message等标准字段。
  • 可选纯文本模式：为了方便人类调试，提供--format text选项，将关键信息以易读的文本形式输出。
  • 进度反馈：对于耗时长的操作（如视频渲染），CLI应支持流式输出进度信息（如每10%输出一行JSON日志），让调用方知道任务仍在进行中，而不是卡死。

注意：GUI自动化天生具有“脆弱性”。软件更新一个版本，UI布局或控件ID可能就变了。因此，基于CLI-Anything构建的自动化流程，其维护成本是必须要考虑的因素。它最适合用于那些UI相对稳定，或者你能控制其版本的环境。

4. 实战：将一个图像查看器包装成AI可用的CLI

理论说再多，不如动手试一下。我们假设一个简单的目标：将系统自带的图片查看器（例如Windows的照片查看器或macOS的预览）包装成一个CLI，让AI能通过命令来查看图片、获取图片信息、进行简单的旋转操作。

4.1 目标分析与驱动选择目标软件：Preview.app(macOS) /照片.exe(Windows 10/11)。 核心诉求：

  1. open_image <path>：打开指定图片。
  2. get_image_info：获取当前打开图片的尺寸、格式、色彩模式。
  3. rotate_image <degrees>：顺时针旋转图片。
  4. save_image <path>：保存图片到新路径。

对于macOS的Preview，我们可以使用AppleScript作为驱动，因为它对原生应用的支持非常完善。对于Windows的照片应用，可能需要使用Microsoft UI Automation (UIA) 或pyautogui这类库。这里我们以macOS + AppleScript为例进行概念性实现。

4.2 编写驱动适配器（AppleScript驱动）CLI-Anything需要一个驱动模块来与Preview对话。我们会创建一个Python类，内部调用osascript命令执行AppleScript。

# preview_driver.py import subprocess import json import time import os class PreviewDriver: def __init__(self): self.app_name = "Preview" # 用于跟踪当前打开的窗口/文档 self.current_doc = None def _run_apple_script(self, script): """执行AppleScript并返回结果""" try: result = subprocess.run(['osascript', '-e', script], capture_output=True, text=True, timeout=10) if result.returncode == 0: return result.stdout.strip() else: raise RuntimeError(f"AppleScript Error: {result.stderr}") except subprocess.TimeoutExpired: raise RuntimeError("操作超时，Preview可能未响应") def open(self, image_path): """打开图片文件""" if not os.path.exists(image_path): raise FileNotFoundError(f"文件不存在: {image_path}") abs_path = os.path.abspath(image_path) script = f''' tell application "Preview" open POSIX file "{abs_path}" activate end tell ''' self._run_apple_script(script) time.sleep(1) # 等待应用和文件加载 # 尝试获取当前文档名作为标识 script = ''' tell application "Preview" if (count of documents) > 0 then set docName to name of document 1 return docName else return "" end if end tell ''' self.current_doc = self._run_apple_script(script) or "unknown" return {"status": "success", "document": self.current_doc} def get_info(self): """获取当前图片信息（模拟）""" # 注意：Preview的AppleScript接口不直接提供像素尺寸，这里需要变通。 # 一种方法是使用`sips`命令行工具分析当前文件。 if not self.current_doc: return {"error": "没有打开的文档"} # 假设我们通过其他方式知道了文件路径，这里简化处理 script = f''' tell application "Preview" tell document 1 return {{ "name": name, "modified": modified }} end tell end tell ''' info_str = self._run_apple_script(script) # 实际项目中，这里需要解析返回的字符串，并可能结合`file`或`sips`命令获取真实尺寸 # 为演示，我们返回模拟数据 return { "status": "success", "info": { "name": self.current_doc, "format": "JPEG", # 应实际解析 "dimensions": "1920x1080", # 应实际获取 "color_profile": "sRGB" } } def rotate(self, degrees): """旋转图片。Preview通常只支持90度旋转。""" valid_degrees = {90, 180, 270} if degrees not in valid_degrees: return {"error": f"Preview只支持 {valid_degrees} 度旋转"} # 旋转操作通常通过菜单或快捷键实现 # 这里模拟发送快捷键 Command+L (顺时针旋转90度，可能需要多次) script = ''' tell application "System Events" tell process "Preview" keystroke "l" using {{command down}} end tell end tell ''' rotations_needed = int(degrees / 90) for _ in range(rotations_needed): self._run_apple_script(script) time.sleep(0.2) # 短暂间隔 return {"status": "success", "action": f"rotated {degrees} degrees"} def save(self, new_path=None): """保存图片。如果提供新路径，则另存为。""" script = ''' tell application "Preview" tell document 1 save end tell end tell ''' if new_path: abs_new_path = os.path.abspath(new_path) script = f''' tell application "Preview" tell document 1 save in POSIX file "{abs_new_path}" end tell end tell ''' self._run_apple_script(script) return {"status": "success", "saved_to": new_path or "original location"}

4.3 定义命令映射与生成CLI接下来，我们需要利用CLI-Anything框架（或模仿其思路），将上述驱动方法映射成标准的CLI命令。假设框架提供了一个装饰器或注册机制。

# preview_cli.py (基于CLI-Anything框架概念) import click from preview_driver import PreviewDriver driver = PreviewDriver() @click.group() def cli(): """一个由CLI-Anything生成的，用于控制Preview.app的命令行工具。""" pass @cli.command() @click.argument('image_path') def open_image(image_path): """打开一张图片。""" result = driver.open(image_path) click.echo(json.dumps(result, indent=2)) @cli.command() def get_info(): """获取当前打开图片的信息。""" result = driver.get_info() click.echo(json.dumps(result, indent=2)) @cli.command() @click.argument('degrees', type=int) def rotate(degrees): """顺时针旋转图片（支持90, 180, 270度）。""" result = driver.rotate(degrees) click.echo(json.dumps(result, indent=2)) @cli.command() @click.argument('new_path', required=False) def save(new_path): """保存图片。如果提供NEW_PATH，则另存为该路径。""" result = driver.save(new_path) click.echo(json.dumps(result, indent=2)) if __name__ == '__main__': cli()

现在，我们就得到了一个名为preview_cli.py的工具。安装依赖后，AI Agent就可以像这样调用它：

# AI Agent 可以执行的命令 python preview_cli.py open_image /Users/me/photo.jpg # 输出: {"status": "success", "document": "photo.jpg"} python preview_cli.py get_info # 输出: {"status": "success", "info": {"name": "photo.jpg", "format": "JPEG", ...}} python preview_cli.py rotate 90 # 输出: {"status": "success", "action": "rotated 90 degrees"} python preview_cli.py save /Users/me/photo_rotated.jpg # 输出: {"status": "success", "saved_to": "/Users/me/photo_rotated.jpg"}

这个简单的例子揭示了CLI-Anything的工作流程：分析目标软件 -> 编写/选择驱动 -> 映射原子操作 -> 组合成业务命令 -> 暴露为标准化CLI。对于更复杂的软件（如IDE、视频编辑器），驱动层会复杂得多，可能需要混合使用可访问性接口、图像识别、甚至逆向工程其内部协议，但核心思路是一致的。

5. 典型应用场景与AI Agent集成模式

CLI-Anything的价值在具体的应用场景中才能充分体现。它本质上扩展了AI Agent的“手”和“眼”，使其能力不再局限于文本和代码。

5.1 场景一：自动化数字内容创作流水线这是最直观的应用。一个AI Agent可以协调多个被“CLI化”的专业软件，完成端到端的创作。

  • 流程示例：
    1. Agent接收指令：“为我的博客文章‘AI趋势’生成一张头图”。
    2. Agent调用dalle_cli generate --prompt “futuristic AI brain circuit, tech background” --output /tmp/ai_image.png（假设DALL-E有CLI）。
    3. 生成图片后，Agent调用我们的preview_cli get_info检查图片尺寸。
    4. 尺寸不合适，Agent调用photoshop_cli resize --width 1200 --height 630 /tmp/ai_image.png（假设Photoshop被CLI化）。
    5. 接着调用photoshop_cli add_text --text “AI Trends 2024” --font “Arial Bold” --size 60 --color “#FFFFFF” --position “center”。
    6. 最后调用upload_cli --service s3 --file /tmp/ai_image_final.png --bucket my-blog。 整个流程完全自动化，无需人工干预。Agent在这里扮演了项目经理和调度员的角色。

5.2 场景二：软件测试与质量保障（QA）GUI自动化测试工具（如Selenium）是针对Web的，而CLI-Anything可以将思路扩展到任何桌面应用。

  • 应用方式：QA工程师为被测软件（如一个图形化的数据可视化工具）生成一套CLI命令（load_dataset,apply_filter,generate_chart,export_report）。然后，可以编写简单的测试脚本，或者让AI Agent根据测试用例自动生成并执行这些CLI命令序列，验证软件功能是否正常，并自动对比输出结果（如图表文件、报告内容）与预期是否一致。这比基于坐标的录制回放测试要稳定和可维护得多。

5.3 场景三：个人工作流自动化与RPA很多重复性的桌面操作都可以被简化。

  • 示例：财务人员每月需要从某个老旧的企业ERP软件（只有GUI）中导出报表数据，该软件没有导出功能，只能手动截图或抄录。使用CLI-Anything，可以为该ERP软件生成login,navigate_to_report_page,set_date_range,capture_table_data等CLI命令。然后编写一个脚本，每月1号自动执行这些命令，将捕获的数据结构化后保存为CSV或直接导入数据库。AI Agent甚至可以负责监控邮件，收到特定格式的报表请求邮件后，自动触发这个流程。

5.4 与AI Agent框架的集成模式CLI-Anything生成的工具，如何被主流的AI Agent框架（如LangChain, AutoGPT, CrewAI）调用呢？主要有两种模式：

模式A：作为普通工具（Tool）集成这是最直接的方式。在LangChain中，你可以将一个CLI命令封装成一个Tool对象。

from langchain.tools import Tool import subprocess import json def preview_open_image(image_path: str) -> str: """打开一张图片到Preview.app。参数：image_path (str): 图片文件路径。""" result = subprocess.run( ['python', '/path/to/preview_cli.py', 'open_image', image_path], capture_output=True, text=True ) # 解析JSON输出，返回给Agent try: output = json.loads(result.stdout) return f"状态: {output.get('status')}, 文档: {output.get('document')}" except: return result.stdout preview_tool = Tool( name="Preview_Open_Image", func=preview_open_image, description="用于在macOS的Preview应用中打开图片文件。" ) # 然后将这个tool加入到Agent的工具列表中

Agent在思考过程中，如果觉得需要打开一张图片，就会调用这个preview_tool。

模式B：动态工具发现与调用更高级的集成是让Agent能够动态发现一个CLI工具提供了哪些命令。这需要CLI工具支持list-commands和--help这类自描述功能。Agent可以先调用list-commands，获取所有可用命令列表，然后根据任务需求，动态构造并调用相应的命令和参数。这实现了更高程度的自动化，Agent不再需要为每个CLI工具预先硬编码集成代码。

6. 局限、挑战与未来展望

尽管CLI-Anything的理念非常吸引人，但在实际落地中，我们必须清醒地认识到它的局限性和挑战。

6.1 当前面临的主要挑战

  1. 稳定性的“阿喀琉斯之踵”：基于GUI自动化的驱动，其稳定性严重依赖于目标软件的UI结构。软件更新、主题更换、屏幕分辨率变化、甚至弹出一个意外的通知，都可能导致元素定位失败，脚本崩溃。维护成本可能很高。
  2. 性能开销：图像识别、OCR、甚至轮询等待UI状态，都是计算密集型或耗时操作。不适合对实时性要求极高的场景。
  3. 安全与权限问题：自动化工具通常需要较高的系统权限（如控制鼠标键盘、访问其他应用窗口）。在企业环境或安全要求高的场景下，部署可能受阻。此外，让AI拥有操作关键软件（如财务系统）的能力，需要极其严格的权限控制和操作审计。
  4. 复杂交互的抽象难度：对于涉及自由绘制、拖拽、复杂状态机（如视频编辑时间轴）的软件，将其操作抽象成有限的几个CLI命令非常困难，可能丢失大量灵活性和细节。
  5. “黑盒”交互的局限性：这种方式是在“模拟用户”，而不是“集成软件”。它无法直接访问软件的内部数据模型或API。例如，你很难通过这种方式从图形化图表软件中直接提取出底层的数据序列，除非软件本身提供了复制数据的接口。

6.2 适用边界与选型建议基于以上挑战，CLI-Anything并非万能钥匙。它更适合以下场景：

  • UI相对稳定的软件（如一些企业级内部工具，版本迭代慢）。
  • 操作流程标准化、重复性高的任务。
  • 作为临时解决方案或原型验证，在软件官方API推出前使用。
  • 对失败有一定容忍度，或有完善的重试和人工接管机制的场景。

在选择是否使用CLI-Anything方案时，务必遵循以下优先级：

  1. 首选官方API/SDK：如果软件本身提供了编程接口，永远优先使用。
  2. 次选脚本/宏功能：如果软件支持内置脚本（如Photoshop的JSX， Excel的VBA），利用它们更稳定。
  3. 考虑逆向工程协议：对于客户端-服务器架构的软件，分析其网络通信协议有时比搞GUI自动化更可靠。
  4. 最后考虑GUI自动化：当以上所有路径都走不通时，CLI-Anything代表的GUI自动化才是值得考虑的“最后一招”。

6.3 未来的演进方向这个项目的未来，我个人认为会向两个方向发展： 一是“驱动生态”的丰富。社区会为各种流行软件贡献高质量、经过充分测试的驱动适配器，形成类似“驱动程序库”的东西，降低使用门槛。 二是与AI更深的结合。未来的驱动可能不再是完全预编程的，而是由AI实时生成。例如，给AI一个软件截图和“帮我点击登录按钮”的指令，AI能实时分析UI，生成点击坐标或可访问性指令。CLI-Anything可能演变成一个“实时UI理解与操作引擎”，而不仅仅是预置命令的生成器。这将极大增强其应对UI变化的能力和泛化性。

在我自己的实验中，将CLI-Anything用于操作一些系统级工具（如访达、文本编辑器）和少数几个支持良好的开源软件时，体验非常流畅。但挑战一个大型商业软件（如Adobe套件）的完整自动化，立刻就会遇到各种边界情况。我的建议是，从小处着手，先自动化一个你每天都要重复三五次的、简单的、UI稳定的操作，感受其威力和痛点，再逐步扩大范围。它是一把非常锋利的“瑞士军刀”，但用之前，最好先看清楚你要切的到底是什么材料。

编程学习 学习日记 实战经验
← 返回列表