我做开源工具盘点也有些日子了，每周会从社区里挑一批值得关注的项目，整理成一份开源雷达。这一期的主题是自动化，选了十个开源工具，核心标准只有一个——它们都能快速跑出可见结果，也就是我说的可试用流程。很多项目在收藏夹里吃灰，原因往往不是工具不够强，而是不知道怎么开始。
先说结论：我倾向于把自动化工具分成两类，一类是“看着牛”，一类是“拿起来就能跑”。这一期我挑了十个，逐个按“可试用流程”的路径重新走了一遍，今天把步骤和踩过的坑一起写出来。不管是Web自动化、移动端测试、运维批量操作，还是RPA脚本，你都能找到对应的工具和上手路线。适合谁看：正在搭自动化测试框架的测试开发，想用自动化解放双手的运维工程师，以及刚接触RPA但对开源方案感兴趣的产品运营。这十个工具覆盖的自动化场景足够宽，你大概率能从中找到两三个可以直接拿进项目里试水的。
1. 为什么“可试用流程”比工具本身更值得关注
1.1 自动化项目的落地难点其实不在工具选型
很多团队在选择自动化工具时，周期往往比实际开发还长。今天A说Playwright好，明天B说Cypress香，后天运维同事又推荐Ansible。工具确实多，但真正卡脖子的不是“哪个功能强”，而是“这个工具到我手里之后，多久能跑出第一个有效结果”。
我观察过不少自动化项目的推进过程，大部分在前两周就凉了。原因非常统一：安装配置折腾了两三天，环境依赖打架，文档读了一半发现版本对不上，最后连一个Demo都没跑通。所以我在挑选工具时会做一件事——把它当成一个产品来试用，而不是当成一个框架来学习。所谓“可试用流程”，就是从一个空环境出发，用最少的步骤获得一个可见的自动化产物。这个产物可以是一段测试报告、一个自动生成的脚本、一次批量任务的成功执行。
这个角度很重要，因为工具的能力边界往往要在“跑起来”之后才能被真正感知。看文档只能看到作者想让你看到的，跑起来才能看到工具在真实场景下的脾气。比如Playwright的自动等待机制，文档里一句话带过，真用起来才知道它能让你少写多少sleep；再比如Ansible的幂等性设计，你不亲手跑两遍同一个Playbook，很难理解它对生产环境的意义。所谓“纸上得来终觉浅”，放在工具选型上同样成立。
1.2 从“能跑”到“好用”之间有四个判断维度
我给自己定了一套快速评估工具的方法，不复杂，但挺实用。第一个维度是Init成本，也就是从零到第一个可运行脚本的时间，最好控制在15分钟以内。超过这个时间的工具，除非有不可替代的能力，否则我会启动第二套方案。第二个维度是调试友好度，自动化脚本百分之八九十的时间都花在调试上，一个工具如果报错信息清晰，提供录制回放或者实时日志，踩坑成本会低很多。
第三个维度是文档和社区活跃度，这个不多说，冷门工具再强也不敢直接用，出了坑连问的人都没有。第四个维度是团队上手曲线，工具再好，团队里的同事学不会也是白搭，关键字驱动、低代码可视化这类设计其实是很聪明的降门槛手段。这四个维度我会在下面逐个工具拆解时反复用到，你第一次接触某个工具时，也可以用同样的问题去问自己：它值不值得你花时间。
2. 十个开源自动化工具逐个拆解
2.1 Playwright：浏览器自动化里的“头号玩家”
Playwright是微软开源的一套浏览器自动化框架，支持Chromium、Firefox和WebKit三种内核。它的能力边界很宽：网页自动化测试、爬虫、截图、PDF生成、录制回放。相比Selenium，Playwright最大的优势是它内部的自动等待机制，基本告别了手工sleep，这让它对新手特别友好，你不用一开始就研究“元素没出来该等多久”这类问题。
试用路径非常顺。如果你的开发环境有Python，执行pip install playwright，再执行playwright install chromium，然后用下面这段代码就能打开一个真实的浏览器页面：
from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch(headless=False) page = browser.new_page() page.goto("https://example.com") page.screenshot(path="example.png") browser.close()这就是一个完整的可试用流程：装依赖、下内核、跑脚本、看到截图产物。整个过程五分钟以内。我实际用下来，Playwright在复杂交互方面的表现很可靠，特别是处理iframe和弹出框，比Selenium省心不少。它的录制功能也值得一提，执行playwright codegen就会打开一个带操作记录的浏览器窗口，你点哪里它自动生成代码，这几乎是零学习成本地体验自动化。
补充一个经验：初期试用不要一上来就写断言，先尽量多录几段用户操作回放，观察它生成的代码长什么样，慢慢就能建立对自动化的直觉。另外，浏览器内核下载如果遇到超时，先确认当前网络环境能正常访问CDN，再手动执行一次install命令，多数时候是网络抖动导致的不完整下载，重跑一次就好。
2.2 Appium：移动端自动化的跨平台答案
Appium是移动端自动化绕不开的名字，它把iOS和Android的自动化接口做了统一，底层调用系统自带的自动化框架，所以不需要修改App代码就能测。它的适用人群很明确：要跑移动端回归测试的QA，或者想在多台真机设备上批量执行任务的团队。核心概念就三个：Desired Capabilities、WebDriver协议、Element定位，理解这三块基本就能上手。
可试用流程也不复杂：安装Appium Server（新版直接npm install -g appium），配好Android SDK环境，在一台真机或模拟器上装一个示例App，然后启动会话。我给的参考配置：
from appium import webdriver desired_caps = { "platformName": "Android", "platformVersion": "14", "deviceName": "emulator-5554", "appPackage": "com.example.app", "appActivity": ".MainActivity", "noReset": True } driver = webdriver.Remote("http://127.0.0.1:4723/wd/hub", desired_caps)跑起来后就能看到驱动在设备上进行操作。这里要提醒一句：移动自动化比Web自动化更依赖环境，模拟器和真机的兼容性差异明显，首次试用最好选定一个环境组合，别今天模拟器明天真机，容易心态崩。另外，如果设备连接报错，先用adb devices确认设备列表，再检查platformVersion是否和真机系统版本完全一致，这个字段填错是最常见的坑。
2.3 Pytest：Python自动化测试的“万金油”
Pytest在社区的热度一直很高，它确实是我见过最顺手的Python测试框架。它能跑单元测试、接口测试、数据驱动测试，还能通过插件拓展到UI自动化场景。我最喜欢它的原因是fixture机制，可以非常优雅地处理用例之间的前置条件和清理逻辑，比如登录态复用、临时数据清理，都是几行代码的事。
可试用流程一句话：pip install pytest，然后写一个test_sample.py：
def test_answer(): assert 3 * 3 == 9然后执行pytest -v，它就会自动收集测试文件并输出报告。别小看这三行，它是理解pytest收集机制的最小模型。再往深了走，pytest可以配合requests做接口自动化，配合allure-pytest生成测试报告，配合pytest-xdist做分布式执行。很多团队的接口自动化框架都是从这一套长出来的。
实操经验：接口自动化里，fixture的scope设定很重要。session级适合登录token，function级适合变量隔离，搞反了会出现环境串扰的坑。比如你定义了session级的数据库连接，却在测试函数里修改连接状态，后续用例会发现数据对不上。另外，pytest的插件生态非常丰富，装插件前优先看发布时间和维护状态，太久没更新的插件尽量别碰。
2.4 Ansible：免装Agent的运维自动化标杆
Ansible是自动化运维领域一个不得不提的存在。它和Puppet、SaltStack最大的区别是无需在目标机器上安装agent，只要控制端能通过SSH连上目标机，就能批量执行任务。这个特性让Ansible成了临时批量操作的利器，也排除了很多agent兼容性问题，你甚至可以直接管到网络设备、云服务器这些不方便装agent的对象。
试用流程非常符合“可试用”的标准。控制端只需要Python环境，pip install ansible就行。目标端甚至什么都不用装。最小示例：写一个hosts.ini文件：
[web_servers] 192.168.1.10 ansible_user=root然后执行：
ansible web_servers -m ping会看到它返回绿色的pong，一次成功的远程连接确认。再往上就可以用Playbook把多个任务串起来，比如批量更新系统包、分发配置文件、重启服务。官方文档里Playbook的语法看着简单，但yaml缩进问题会折磨新手，我建议在编辑器里开启空格显示，或者在本地用ansible-lint做语法检查，能省很多无谓的报错时间。
2.5 n8n：把自动化做成可视化工作流
n8n是一个开源的工作流自动化平台，它的定位类似于Zapier，但是可自托管、源代码开放。你可以通过拖拽节点把不同的应用串起来：收到邮件触发一个Webhook，然后把数据推到数据库，再发一条企业微信通知。对非技术背景的人来说，这几乎是“自动化”三个字最直观的形态。
试用流程是我见过最友好的：一行Docker命令就能起服务：
docker run -it --rm --name n8n -p 5678:5678 n8nio/n8n然后打开浏览器localhost:5678，注册一个本地账号，界面里有一个现成的Workflow模板库，挑一个模板点进去看，就是完整的自动化流程。对没有编程基础的人来说，n8n是把自动化概念变成实体的最好路径；对有编程基础的人来说，它的Code节点又能直接写JS/Python，做到了低代码和可编程的平衡。
经验提醒：n8n很强大，但别一上来就搭复杂流程，先从“Webhook触发→发送测试消息”这类简单链路开始，把触发、动作、输出的逻辑理顺，再加分支。我见过很多新人一上来就想搭一个跨十个应用的完整链路，结果一个节点配置错了，整个流程卡住半天排查不出来。从小处着手，反而能更快理解它的执行原理。
2.6 Maestro：移动UI自动化的新势力
Maestro是这两年冒头比较快的移动端UI自动化工具，主打极简配置和低门槛。它不像Appium需要写一堆capabilities，而是通过一个flow.yaml文件来描述用户操作流程。它的底层其实也借用了系统UIAutomator的能力，但包装得很优雅，上手体验比老牌工具轻松太多。
可试用流程尤其清爽。装好CLI之后，连上Android设备，写一个flow.yaml：
appId: com.example.app --- - launchApp - tapOn: "登录" - assertVisible: "请输入密码"然后执行maestro test flow.yaml。整个过程就是“描述操作流→自动执行→输出测试结果”。我把它和Appium做了个对比，适合不同人群：如果你的测试团队有很强的编码能力，需要高度定制的原生能力调用，Appium依然是首选；如果团队偏业务侧，想快速做冒烟回归，Maestro的体验明显更好。但要注意Maestro目前对复杂手势和深度控件树的支持还不够，太复杂的场景还是得上Appium。
2.7 Robot Framework：关键字驱动测试的常青树
Robot Framework是测试自动化里很经典的存在，它用关键字封装动作，测试用例可以由非技术人员编写。社区里积累了大量的关键字库，比如SeleniumLibrary、RequestsLibrary，生态非常齐全。它的设计哲学很明确：把“怎么做”收敛到关键字库里，把“做什么”留给用例层，让业务人员也能参与测试用例维护。
试用流程：pip install robotframework，再写一个纯文本用例test.robot：
*** Settings *** Library Collections *** Test Cases *** 登录场景 ${name} Set Variable 张三 Should Be Equal ${name} 张三执行robot test.robot，就能看到HTML格式的测试报告。这个框架最大的价值是“业务人员也能看测试用例”，在团队协作上有天然优势。不过说实话，新时代项目如果团队全是技术背景，Robot Framework的吸引力会下降，它更适合需要业务和测试共同维护用例的团队。不要因为它是老牌就神话它，选型还是要围绕团队真实构成来。
2.8 Jenkins：自动化流程的调度中枢
严格说Jenkins不是“单项自动化工具”，而是一个自动化流水线的调度平台。前面提到的Pytest、Ansible、Robot Framework都可以被Jenkins串起来，按时间或事件自动触发。它在自动化体系里的角色更像是一个总控台，负责“什么时候跑、跑哪些任务、结果怎么通知”这些事情。
可试用流程也简单，官方有Docker镜像：
docker run -d --name jenkins -p 8080:8080 jenkins/jenkins:lts启动后按界面提示装插件、建Job。你不需要第一天就完全掌握Pipeline语法，先在Job里配置“构建触发器”为定时任务，再添加一个“执行Shell/Python脚本”的构建步骤，一个定时自动化任务就成了。
我的体会是，Jenkins的Pipeline as Code（即Jenkinsfile）才是它真正好用的地方，把流程配置入库，后面所有环境都能复用同一套流水线。建议从最简单的单job起步，再逐步把复杂流程拆到不同stage里。另外，Jenkins容器本身会积累很多历史数据，日常使用要留意磁盘占用，尽量把工作目录挂载到宿主机上方便管理。
2.9 Robocorp：新一代开源RPA的代表
RPA这两年热度很高，开源RPA里Robocorp做得比较务实。它不是靠录制鼠标点击来糊弄，而是用Python代码构建整个自动化任务，同时具备浏览器控制、Excel处理、PDF读取这些企业级场景能力。它的前身和Robot Framework同源，所以你在它的项目里能看到robot任务文件的影子，但对开发者更友好。
试用路径：先安装rcc命令行工具（Robocorp的控制器），然后用rcc create创建一个示例项目，里面会有一个AutoHooks的资源脚本，一个task在task.py里。改一下，让它打开浏览器操作：
from robocorp.tasks import task from robocorp.browser import browser @task def open_website(): page = browser.goto("https://example.com") page.screenshot(path="rpa_output/screenshot.png")执行rcc run就能看到任务运行和日志输出。它的任务库结构、凭证管理和云端的调度对做企业自动化交付来说特别顺手。有一说一，开源RPA和商业RPA在“操作简单度”上还有差距，但Robocorp胜在你能看到每一行代码在干什么，调试和定制空间大。适合团队里有一定开发能力，又想用RPA解决重复流程的人。
2.10 AutoHotkey：桌面级自动化的隐藏神器
最后一个工具可能和工作流无关，但它在Windows桌面自动化上几乎不可替代。AutoHotkey是一个开源的脚本语言，能模拟键盘输入、鼠标点击、窗口操作。日常办公里“自动填表、批量重命名、窗口管理”这类操作，用它最快。它不依赖额外运行环境，Windows机器装了就能跑，虽然看起来“野”，但解决重复操作是立竿见影的。
可试用法：安装AutoHotkey之后，新建一个.ahk文件，写一行：
^j::Send 自动填充的文本保存并双击运行，然后按Ctrl+J，光标所在位置就会自动输入“自动填充的文本”。这就是一个零成本的桌面自动化Demo。再深入一点，可以写鼠标连点器、窗口位置记忆工具、Excel自动录入脚本。
很多人觉得这类脚本工具很“野”，但它其实是解放重复操作最直接的方法。我个人的建议是：当你每天在Windows上做同一个操作超过三次，就可以考虑写一个AutoHotkey脚本。它能帮你省下的时间，绝对值得那几分钟的编写成本。
3. 如何快速把工具跑起来：可试用流程实操
3.1 环境准备：给初学者的快速配置路线
十个工具的试用环境可以分成三类。Python环境类包括Pytest、Playwright、Robot Framework、Appium的Python客户端，推荐用pyenv或者venv隔离环境，避免全局Python包混乱——我见过太多人因为全局环境里装了个旧版本依赖，导致Playwright或者Appium出现诡异报错，一半以上都是包冲突。Docker环境类包括n8n、Jenkins，这两个强烈推荐用Docker，因为涉及的服务端组件较多，Docker可以一条命令装完，也便于随时清理和切换版本。系统脚本环境类包括Ansible（控制端只需要Python环境）、AutoHotkey（Windows原生）、Robocorp（自带rcc工具），这类工具基本不存在复杂的环境依赖。
具体到一个全新的机器上，我的习惯是：先装Git、Python 3.11和pip，再装Docker Desktop或Linux下的docker-engine。Docker装好后，先确认能正常拉取公共镜像，再开始跑工具，这一步可以提前暴露网络或配置问题。Windows用户在第一次跑终端工具时，很可能会遇到PATH不对的情况，建议用管理员权限打开PowerShell执行安装命令。如果你常用Anaconda，则要注意conda和pip混用可能导致的库冲突，建议为每个项目建独立虚拟环境，并且在项目目录下维护一份requirements.txt，方便回滚。
3.2 五个零成本试用场景
这里给出五个我实际跑通的组合场景，你直接照着复制粘贴就能看到效果。
场景一是接口自动化冒烟。用Pytest加requests写一个测试，断言接口返回200。
import requests import pytest def test_api_status(): resp = requests.get("https://api.example.com/health", timeout=5) assert resp.status_code == 200执行pytest test_api_status.py -v，输出绿色通过。这个场景适合所有想验证“接口自动化是什么”的人，五分钟足够建立起最基本的认知。
场景二是Web端登录自动化。用Playwright的codegen录制一个登录流程并回放。或者直接跑上面那段截图脚本，确保浏览器驱动正常。这个场景的产物是一段录制的脚本和一张截图，你能直观看到自动化工具到底在操作什么。
场景三是Ansible的批量Ping检查。在hosts文件里定义一组测试机器，用ansible all -m ping验证远程连接。如果你没有现成的目标机器，可以先用ansible localhost -m ping在本地跑一遍，同样能看到正确的返回结构。
场景四是移动端UI自动化的最小验证。用Maestro的flow.yaml跑一个App的基础交互流程，前提是本地有Android模拟器。如果你不想装模拟器，这个场景可以先跳过，等有真机环境再回来。
场景五是桌面重复输入自动化。用AutoHotkey脚本向记事本窗口自动输入一串固定文本，验证模拟输入是否生效。这个场景几乎零成本，任何一个Windows用户都可以在十分钟内跑通。
这五个场景跑通后，自动化工具在你手里就不再是“收藏夹里吃灰的星标项目”，而是能直接改造成自己工作的起点。重点是体验“从零到可见结果”的过程，而不是看完了事。
3.3 把多个工具串成一个自动化流程
可试用流程走到最后，往往不止是“跑通单个工具”，而是把不同工具串起来。举一个我实际搭过的例子：用n8n作为前端流程引擎，接收一个Webhook事件，然后把任务参数通过HTTP请求传给Jenkins；Jenkins触发Ansible Playbook执行服务器批量操作；操作完成后，Ansible回调Webhook让n8n继续后续流程，把结果推送到企业微信或者邮件。
这个链路里，每个工具都只负责自己最擅长的一段：n8n做可视化编排，Jenkins做任务调度，Ansible做具体执行。这也是我坚持推荐多种工具组合的原因——它们不是彼此的替代品，更像是一条流水线上的不同工位。串联多个工具的价值在于，你可以把一个完整业务动作变成无人值守流程，比如每晚自动备份并生成报表再发到群里，全程不需要人干预。
当然，串工具也有成本，每多一个环节就多一个故障点。我的建议是，先在两个工具之间打通一条最简链路，确认消息格式和回调逻辑没问题，再逐步往中间加环节。别图快，把链路一次搭到位，调试时你会被各种联合报错折磨到怀疑人生。
4. 自动化工具选型与落地避坑指南
4.1 我踩过的自动化工具选型大坑
第一个坑是迷信“全能工具”。市面上确实有一些宣称包罗万象的自动化平台，但实际用下来，什么都沾一点，什么都不精。我的原则是：特定领域用特定选手，比如Web自动化就用Playwright，移动端就用Appium或Maestro，运维就用Ansible。别指望一个工具解决所有问题，组合使用才是常态。
第二个坑是忽略团队技术栈。选型时只顾着自己喜欢，不照顾队友的技术背景。一个运维团队全员都是Python背景，你硬推Node.js写的工具，学习成本很高，落地阻力自然会大。反过来，一个前端团队选Playwright就比选Selenium顺手得多，因为它符合现代Web开发的心智模型。
第三个坑是拿“试用Demo”代替“真实场景压力测试”。一个工具Demo跑通了，不代表在复杂业务里也稳。决策之前，至少要拿两个真实场景去压一压它。比如Playwright在小页面上很顺畅，但面对几十个iframe嵌套的后台系统，性能表现未必理想。
第四个坑是不敢换工具。很多人担心迁移成本，看到更好的工具也懒得动。但工具是手段，不是信仰。当新工具能在同样的时间内提升两倍以上的效率，果断换。迁移固然有成本，但留在旧工具上持续付的心智税和维修费，往往比一次迁移更高。
4.2 团队落地自动化流程的协作经验
自动化不只是个人能力的比拼，更多是流程和协作的比拼。我的经验是分四步走。第一步，先画清楚要自动化的场景，不用画得很复杂，纸笔就行，关键是把“人做什么、系统做什么、工具做什么”三个角色分清楚。第二步，从高频低风险操作切入，比如每周的报表生成、每天的登录巡检，这些操作失败了也不会造成大事故，非常适合作为自动化项目的试点。
第三步，把自动化脚本当成产品管理。这个很少人提到。脚本也有生命周期，也需要版本控制、可读性维护和文档说明。我见过太多团队的自动化脚本只有写的人自己看得懂，人一离职整个自动化体系就瘫痪了。写脚本的时候，至少要在文件头部留下一段注释说明输入输出和依赖，这是最基本的职业素养。第四步，逐步建立自动化监控。自动化跑起来了，还得知道它跑得好不好。Jenkins、n8n这类平台都支持日志和告警，别把自动化当成“跑完就不管的任务”，要让失败自动暴露在群通知里。
4.3 常见问题与排查速查表
这部分我整理了一张表，把十个工具可能遇到的典型问题和解决思路放进去，适合放在团队Wiki里当参考。
| 工具 | 常见问题 | 排查思路 |
|---|---|---|
| Playwright | 下载浏览器内核超时 | 确认当前网络能正常访问CDN，手动重新执行install命令 |
| Appium | 无法连接设备或会话超时 | 用adb devices确认设备列表，核对platformVersion是否与真机一致 |
| Pytest | 测试用例收集不到 | 检查文件名是否以test_开头，确认conftest.py放在正确层级 |
| Ansible | ping模块报错 | 先手工用ssh连接目标机器，确认端口和用户权限 |
| n8n | 节点执行异常 | 查看该节点运行日志，多数是字段映射填错 |
| Maestro | 元素定位失败 | 打开控件树视图确认实际id，别凭肉眼猜控件名 |
| Robot Framework | 报告打不开 | 确认robot命令的输出目录，报告默认生成在运行命令的当前目录 |
| Jenkins | Job构建失败 | 重点看控制台输出的前20行，大部分报错线索在Stderr里 |
| Robocorp | rcc运行缺依赖 | 更新project.yaml的依赖列表，重新执行rcc pull |
| AutoHotkey | 脚本无反应 | 确认脚本进程在运行，检查是否被安全软件拦截 |
这个表没法覆盖所有情况，但可以作为第一次上手时的排查参考。真实开发中，把工具日志打开，跟着日志走，往往比盲目搜索问题答案更快。另外建议团队统一日志规范，凡是自动化任务都在关键节点打日志，排查问题时能省很多时间。
5. 延伸思考：把自动化能力沉淀为团队资产
5.1 从试用流程到组织级自动化资产
前面说的都是“个人能不能跑通”，但自动化真正产生价值，是在“组织能不能持续用”这个层面。一个工具被试用成功后，接下来要做三件事：标准化、文档化、平台化。标准化指统一脚本目录结构、命名规范、参数传递方式，让不同成员写的脚本能被互相接手；文档化指把关键流程、依赖关系、部署方式写清楚，这不是为别人写的，更多是给三个月后的自己看的；平台化指通过Jenkins或n8n这类调度平台把脚本编排成可复用的服务，而不是散落在各自电脑的某个文件夹里。
这三步做完，自动化就不再是某个人的技能，而是团队的资产。新同事入职后，照着Wiki里的流程就能把一套现成的自动化体系跑起来，而不是从零开始摸索。这个过程的投入看起来多，但收益是长期的。
5.2 下一步：AI与自动化的结合
最后聊聊方向。最近一段时间，AI辅助自动化是社区讨论最多的方向。比如用开源大模型辅助生成测试用例、自动分析报错日志、把自然语言描述转换成自动化脚本，这些都不是科幻片，在开源社区已经有项目在做了。在数据合规要求高的场景，完全可以考虑本地部署开源模型，把自动化平台产生的日志、报错喂给模型做初步诊断，再把结论推给人工复核。
我的看法是，AI不会立刻替代自动化工具，但会显著降低自动化的使用门槛。十年后回头看，我们可能很难理解“为什么写自动化脚本还要手写XPath”这种问题。不过现阶段，老老实实把手头工具的试用流程跑通，仍然是基本功。先把基础打牢，再谈智能化的加成，这条路不会错。
6. 写在最后：一点私人心得
做这份开源雷达也有一些日子了，陆陆续续试用过上百个自动化项目。如果让我用一个词概括这几年的感受，我会选“复利”。一个自动化脚本今天帮你省十分钟，明天帮你省十分钟，一年下来就是几十个小时。而把工具选对、试用跑通、团队沉淀下来，省下的时间会成倍放大，这就是复利。
最后再分享一个小技巧：每周抽半天，只做“试用一个新工具”这一件事，不追求精通，只追求跑通一个最小Demo。这个习惯看起来不起眼，但它会让你的技术视野一直保持锐利。下期开源雷达，我会继续挑一批值得试的项目，到时候再写出来。
