1. 项目概述：当AI助手遇上发票抽奖

最近在折腾一个挺有意思的小项目，起因是我自己一个挺实际的痛点：每次收到一堆电子发票，都得手动打开图片或者PDF，把发票代码、号码、金额这些信息一个个敲到Excel里，再等着财务系统或者小程序抽奖。这个过程不仅枯燥，还容易出错，万一哪天手滑输错一个数字，可能就与一笔“意外之财”擦肩而过了。

正好，我一直在关注一个叫WorkBuddy的AI智能体开发平台。它不像传统的低代码平台那样需要你从零开始搭积木，而是更像一个“技能超市”。你可以直接调用它预置好的各种“技能”（Skill），比如文件处理、网页操作、数据分析，甚至是调用第三方API，然后通过一个可视化的流程图把这些技能串联起来，快速构建一个能自动完成特定任务的“数字员工”。这次，我就想试试用WorkBuddy，打造一个能自动识别发票信息并通知我中奖结果的“发票抽奖小助手”。

这个项目的核心逻辑很简单：我只需要把收到的发票图片或PDF文件丢给WorkBuddy，它就能自动完成“OCR文字识别 -> 提取关键字段 -> 模拟提交抽奖 -> 判断结果并通知我”这一整套流程。听起来是不是有点像给自己雇了个免费的、24小时在线的财务小秘书？最关键的是，这次它真的提前告诉我，我的一张发票中了150元！这种“自动化创造价值”的即时反馈，体验感直接拉满。

接下来，我就把自己从零开始搭建这个“发票抽奖先知”项目的完整过程、踩过的坑以及最终跑通的方案，毫无保留地分享出来。无论你是想了解WorkBuddy这个新工具，还是对OCR和自动化流程感兴趣，抑或是单纯想解放双手，这篇内容都会给你带来直接的参考价值。

2. 核心思路与技术选型解析

在动手之前，明确整个流程的骨架和每个环节的技术实现方式至关重要。我们不能为了用AI而用AI，每一个工具的选择都要有充分的理由。

2.1 整体业务流程设计

我的目标是一个端到端的自动化流程，尽量减少人工干预。梳理下来，核心步骤分为四步：

1. 发票文件输入 ：如何方便地把文件交给WorkBuddy处理。可以是本地文件上传，也可以是监控某个邮箱附件或网盘目录。
2. 发票信息识别 ：这是最核心的一步，需要从图片或PDF中准确提取出“发票代码”、“发票号码”、“开票日期”、“不含税金额”等关键字段。这里必须用到OCR技术。
3. 模拟抽奖查询 ：提取到信息后，需要模拟浏览器操作，将这些信息提交到官方的发票抽奖平台（如各地税务公众号或小程序的后台接口）。
4. 结果解析与通知 ：拿到查询结果后，解析返回的页面或数据，判断是否中奖及中奖金额，最后通过一个我能即时收到的方式通知我，比如钉钉、企业微信或者邮件。

整个流程的成败，很大程度上取决于第二步OCR的准确率和第三步模拟提交的稳定性。

2.2 为什么选择WorkBuddy作为实现平台？

市面上能实现自动化的工具很多，比如纯Python脚本、RPA软件（如UiPath、影刀），我选择WorkBuddy主要基于以下几点考量：

• 降低开发门槛 ：我不需要从零开始写所有的网络请求、图像处理、定时任务代码。WorkBuddy提供了大量封装好的“技能”，比如“读取文件”、“调用HTTP API”、“解析JSON”、“发送钉钉消息”等，我只需要像搭积木一样连接它们。这对于非专业程序员或者想快速验证想法的人来说非常友好。
• 可视化流程编排 ：所有逻辑都在一个画布上以流程图的形式呈现，每一步做了什么、数据如何流转一目了然。调试的时候可以清晰地看到每个节点的输入输出，快速定位问题，这比在几千行代码里 print 调试要直观得多。
• 易于集成与扩展 ：WorkBuddy本身支持调用外部HTTP API，这给了我极大的灵活性。当平台内置的OCR技能可能不满足需求时，我可以轻松地切换到更专业的第三方OCR服务，比如腾讯云、百度云的OCR API，只需添加一个“HTTP请求”技能节点即可。
• 内置调度与触发 ：WorkBuddy可以设置定时触发（如每天上午9点运行一次），或者由事件触发（如收到新邮件），这完美契合了“定期处理发票”这个场景，我不需要自己再写一个 crontab 或者守护进程。

当然，它也有局限，比如深度定制化能力可能不如直接写代码，但对于发票识别抽奖这类逻辑相对固定、对稳定性要求高于极致灵活性的场景，WorkBuddy的效率优势非常明显。

2.3 OCR引擎的选型与决策

OCR是项目的“眼睛”，它的准确率直接决定了后续流程是否有意义。WorkBuddy平台可能有内置的OCR技能，但为了追求更高的准确率（尤其是对印刷体发票），我决定评估并引入第三方OCR服务。

我主要对比了三种方案：

1. 本地OCR引擎（如Tesseract） ：

   • 优点 ：免费、离线可用、隐私性好。
   • 缺点 ：对中文和复杂版面（如发票表格）的识别准确率需要精细调教；部署和优化有一定技术门槛；性能依赖本地硬件。
   • 结论 ：适合对隐私极度敏感、有较强技术能力进行模型训练和调优的场景。对于求稳、求快的我来说，不是首选。

2. 开源OCR框架（如PaddleOCR） ：

   • 优点 ：免费、开源、识别精度高，特别是对中文场景优化得很好，社区活跃。
   • 缺点 ：需要一定的Python环境和深度学习框架部署知识（如安装PaddlePaddle）；虽然提供了预训练模型，但在不同服务器环境上部署仍可能遇到依赖问题。
   • 结论 ：精度和免费是巨大优势，如果项目是部署在自己的长期稳定服务器上，这是一个绝佳选择。但在初期快速验证阶段，部署复杂度稍高。

3. 云服务OCR API（如腾讯云、百度云） ：

   • 优点 ：开箱即用，识别精度高且稳定（大厂持续优化模型）；按量计费，成本极低（识别一张发票几分钱）；有完善的API文档和错误处理。
   • 缺点 ：需要网络调用，有极小的延迟；发票图片需要上传到云端（需注意发票内容的敏感性，最好选择信誉好的服务商）。
   • 结论 ： 最适合本项目 。它完美平衡了精度、开发速度和成本。我只需要关注如何调用API，而不用操心模型维护、性能优化等问题。我最终选择了腾讯云OCR，因为它针对“增值税发票”有专门的、高精度的识别接口，这正是我需要的。

注意 ：使用任何云服务API，请务必仔细阅读其服务条款和数据隐私政策，确保你处理的数据类型是允许的。对于发票等包含敏感信息的文件，建议评估风险。

3. 环境准备与WorkBuddy技能配置

工欲善其事，必先利其器。在开始画流程图之前，我们需要把“武器库”准备好。

3.1 WorkBuddy基础环境搭建

首先，你需要拥有一个WorkBuddy的账号。目前它可能提供试用或免费额度。登录后，主要熟悉两个核心界面：

1. 技能市场 ：在这里搜索和启用你需要的预置技能。例如，搜索“文件”、“HTTP”、“JSON”、“钉钉”等关键词，将用到的技能添加到你的技能库中。
2. 流程画布 ：这是你创作的主战场。你可以从左侧拖拽技能节点到画布上，并用连接线定义它们的执行顺序和数据流向。

对于本项目，我提前在技能市场中启用了以下关键技能：

• 文件读取 ：用于获取本地或指定位置的发票文件。
• HTTP请求 ：核心技能，用于调用腾讯云OCR API和模拟提交抽奖查询。
• JSON解析 ：用于处理OCR API返回的复杂JSON数据，提取我们需要的信息。
• 条件判断 ：用于根据抽奖结果决定不同的通知路径。
• 钉钉机器人通知 ：我选择钉钉作为通知渠道，你也可以用企业微信、邮件等。

3.2 腾讯云OCR API申请与配置

这是确保识别准确度的关键外部服务。

1. 注册与实名 ：访问腾讯云官网，完成注册和实名认证。这是使用任何云服务的第一步。
2. 开通OCR服务 ：在控制台搜索“文字识别”，找到“增值税发票识别”或“通用印刷体识别”服务，点击开通。通常新用户会有免费额度。
3. 获取密钥 ：在“访问管理”中，创建一个子账号或直接使用主账号，获取 SecretId 和 SecretKey 。 请妥善保管，它们相当于你API的账号密码。
4. 了解API接口 ：查阅“增值税发票识别”的API文档，重点关注请求方式（POST）、请求地址、必需的参数（如 ImageBase64 -图片的Base64编码内容）和返回的数据结构。返回的数据通常是一个嵌套很深的JSON，里面包含了识别出的所有字段和其置信度。

一个简单的思路是：在WorkBuddy中，先用“文件读取”节点拿到发票图片的二进制数据，然后通过一个“编码”节点（或直接在“HTTP请求”节点中配置）将其转换为Base64格式，最后作为参数调用腾讯云OCR API。

3.3 本地测试脚本编写（可选但推荐）

在将整个逻辑搬到WorkBuddy的可视化界面之前，我强烈建议先用Python写一个简单的本地测试脚本。目的有两个：一是验证腾讯云OCR API是否能正确返回你需要的数据；二是提前熟悉API的响应格式，方便后续在WorkBuddy中设计JSON解析逻辑。

import base64
import json
import requests
from tencentcloud.common import credential
from tencentcloud.common.profile.client_profile import ClientProfile
from tencentcloud.common.profile.http_profile import HttpProfile
from tencentcloud.ocr.v20181119 import ocr_client, models

# 1. 准备密钥和图片
SECRET_ID = "你的SecretId"
SECRET_KEY = "你的SecretKey"
IMAGE_PATH = "./你的发票图片.jpg"

with open(IMAGE_PATH, "rb") as f:
    image_base64 = base64.b64encode(f.read()).decode('utf-8')

# 2. 初始化客户端
cred = credential.Credential(SECRET_ID, SECRET_KEY)
httpProfile = HttpProfile()
httpProfile.endpoint = "ocr.tencentcloudapi.com"
clientProfile = ClientProfile()
clientProfile.httpProfile = httpProfile
client = ocr_client.OcrClient(cred, "ap-guangzhou", clientProfile)

# 3. 构造请求并调用
req = models.VatInvoiceOCRRequest()
params = {
    "ImageBase64": image_base64
}
req.from_json_string(json.dumps(params))
resp = client.VatInvoiceOCR(req)

# 4. 打印原始响应，分析结构
print(resp.to_json_string())
# 重点查看返回的 JSON，找到如 `VatInvoiceInfos` 下的 `Number`(发票号码)、`Code`(发票代码)、`Total`(价税合计)等字段。

运行这个脚本，如果成功，你会看到一大段JSON。你需要像侦探一样，从中找出发票代码、号码、金额等关键信息所在的路径。这个路径信息，就是后续在WorkBuddy“JSON解析”节点中需要配置的“JSONPath”。

4. WorkBuddy流程搭建实操详解

现在进入最核心的部分——在WorkBuddy画布上构建我们的自动化流程。我会按照执行顺序，分解每一个关键节点是如何配置的。

4.1 流程触发与文件输入节点

我的流程设计为由“手动触发”开始，用于测试。实际部署时，可以替换为“定时触发”或“邮箱监听”触发。

1. 开始节点 ：从左侧拖拽一个“开始”节点到画布。
2. 文件读取节点 ：
   • 拖拽一个“文件读取”技能节点，并将其连接到“开始”节点之后。
   • 配置该节点：选择“指定文件路径”模式，将你存放发票的文件夹路径填入。例如， C:\Invoices\*.jpg 或 /home/user/invoices/*.pdf 。你可以配置它读取最新文件或所有文件。
   • 关键配置 ：设置输出变量，比如 file_raw_data ，这个变量将保存文件的二进制内容，用于后续步骤。

4.2 调用腾讯云OCR API节点

这是流程中的第一个技术难点，我们需要将图片数据发送给腾讯云并拿回识别结果。

1. Base64编码节点 ：

   • 腾讯云OCR API要求图片以Base64格式传递。WorkBuddy可能没有直接的Base64编码技能，但我们可以用“代码”节点或“数据处理”节点中的相关功能实现。
   • 我使用的是“代码”节点（支持Python），在其中编写简单的转换代码，输入是上一个节点的 file_raw_data ，输出一个变量如 image_base64 。
   • 代码示例（在代码节点中） :

     import base64
     def main(file_data):
         # file_data 是上游文件读取节点传来的二进制数据
         image_base64 = base64.b64encode(file_data).decode('utf-8')
         return {'image_base64': image_base64}
     

2. HTTP请求节点（OCR调用） ：

   • 拖拽一个“HTTP请求”节点，连接在Base64编码节点之后。
   • 配置请求 ：
     • URL : https://ocr.tencentcloudapi.com/ (具体接口地址以腾讯云文档为准，增值税发票识别可能是独立接口)
     • 方法 : POST
     • Headers : 需要添加腾讯云API签名所需的头部，这通常比较复杂。 一个更简单的方法是使用腾讯云官方SDK封装好的“签名”功能，或者直接在“代码”节点中使用SDK完成调用，然后将结果传递给下游。 为了流程清晰，我采用了“代码节点调用SDK”的方案。
   • 替代方案：使用代码节点集成SDK ：
     • 在WorkBuddy的代码节点中，你可以安装必要的Python包（如果环境允许），或者直接使用其内置的腾讯云连接器（如果提供）。
     • 我选择在代码节点中复用之前本地测试的脚本逻辑，这样最可控。代码节点的输入是 image_base64 ，输出是完整的OCR响应JSON，比如 ocr_result_json 。

4.3 解析OCR结果与数据清洗

拿到 ocr_result_json 后，我们需要从中“挖”出有用的信息。

1. JSON解析节点 ：

   • 拖拽一个“JSON解析”节点。
   • 输入 ：绑定上游代码节点输出的 ocr_result_json 变量。
   • 配置解析规则 ：这是关键步骤。你需要根据API返回的实际JSON结构，配置“字段映射”。
   • 例如 ：
     • 目标变量 invoice_code ， JSONPath 可能是 $.VatInvoiceInfos[0].Code 。
     • 目标变量 invoice_number ， JSONPath 可能是 $.VatInvoiceInfos[0].Number 。
     • 目标变量 total_amount ， JSONPath 可能是 $.VatInvoiceInfos[0].Total 。
   • 实操心得 ：一定要先用一张发票测试，把完整的响应JSON打印出来（可以输出到日志或临时变量），仔细分析结构。不同发票类型（普票、专票）返回的结构可能有细微差别，需要做兼容处理。

2. 数据清洗与格式化节点 ：

   • OCR识别出的金额可能是字符串，如“¥1,500.00”，我们需要将其转换为纯数字 1500.00 ，方便后续处理。
   • 日期字段可能需要从“2023年01月15日”转换为“20230115”以适应抽奖平台的格式。
   • 这些清洗操作可以在另一个“代码”节点中完成，使用简单的字符串替换和正则表达式即可。

4.4 模拟抽奖查询与结果判断

这一步是模拟浏览器向税务抽奖平台提交数据。由于涉及具体的网站，其接口和参数可能经常变动，这里我讲通用方法和核心思路。

1. 分析网络请求 ：

   • 使用Chrome浏览器的“开发者工具”（F12），打开“网络”选项卡。
   • 在目标抽奖平台页面，手动输入一张发票信息并点击查询。
   • 在“网络”标签页中，你会看到浏览器发出的所有请求。找到那个在点击查询按钮后出现的、携带了发票代码、号码等参数的请求（通常是XHR/Fetch请求）。查看其“标头”和“负载”，记下请求URL、方法（POST/GET）以及参数的格式。

2. 配置HTTP请求节点（抽奖查询） ：

   • 拖拽第二个“HTTP请求”节点。
   • 按照上一步分析的结果进行配置：
     • URL : 填写抓取到的请求地址。
     • 方法 : 通常是POST。
     • Headers : 复制抓取到的请求头，特别是 Content-Type 、 User-Agent 和可能需要的 Cookie 或 Token 。 User-Agent 设置为一个常见的浏览器标识，可以避免被简单屏蔽。
     • Body : 选择 x-www-form-urlencoded 或 json ，根据抓包情况而定。将之前清洗好的 invoice_code , invoice_number 等变量填入对应的参数值中。
   • 输出 ：将响应体保存到一个变量，如 lottery_response 。

3. 解析抽奖结果 ：

   • lottery_response 可能是HTML页面，也可能是JSON。需要根据实际情况解析。
   • 如果是JSON ：再用一个“JSON解析”节点，提取出“是否中奖”和“中奖金额”字段。
   • 如果是HTML ：这是更常见但也更复杂的情况。你需要使用“文本处理”或“代码”节点，通过正则表达式或HTML解析库（如BeautifulSoup，如果代码节点支持）来提取页面中的关键文本。例如，在HTML中搜索“恭喜您”、“未中奖”、“￥150”等字样。

4. 条件判断节点 ：

   • 拖拽一个“条件判断”节点。
   • 设置判断条件。例如： {{中奖金额}} > 0 。
   • 根据判断结果（是/否），流程将走向不同的分支。

4.5 结果通知与流程优化

最后一步，把结果告诉我。

1. 通知节点（中奖分支） ：

   • 在条件判断的“是”分支后，连接“钉钉机器人通知”节点。
   • 配置机器人的Webhook地址（需要在钉钉群里添加自定义机器人获取）。
   • 编辑消息内容，可以做得醒目一些。例如：

     🎉【发票中奖提醒】🎉
     发票号码：{{invoice_number}}
     中奖金额：{{中奖金额}}元
     查询时间：{{当前时间}}
     链接：[点击查看详情](抽奖结果页面链接)
     

   • 实操心得 ：消息模板里可以加入一些变量，让每次通知的信息都具体化，体验更好。

2. 通知节点（未中奖分支） ：

   • 在“否”分支后，也可以连接一个通知节点，但消息可以简单些，或者只记录日志不通知，避免骚扰。我选择记录到WorkBuddy的执行日志中，便于后续统计。

3. 错误处理与重试机制 ：

   • 任何一个HTTP请求都可能失败（网络超时、API限流等）。
   • 在关键的“HTTP请求”节点上，配置重试策略（如失败后重试2次，间隔5秒）。
   • 在流程最后，添加一个“错误处理”汇聚节点，如果任何步骤出现未捕获的错误，可以发送一条预警通知，告诉你“发票处理流程异常，请检查”。

5. 调试、部署与避坑指南

流程图画好了，但让它稳定跑起来，还需要一番调试和优化。

5.1 调试技巧：用好日志与变量预览

WorkBuddy的优势在于可视化调试。在测试运行流程时：

• 逐步运行 ：不要一次性跑完整个流程。先运行到OCR节点，检查 ocr_result_json 是否正确获取。
• 查看节点输出 ：点击每个节点，查看其输入/输出变量的具体值。这是排查数据传递错误最直接的方法。
• 添加日志节点 ：在关键位置插入“日志输出”节点，将重要的中间变量（如清洗后的发票号码、解析出的中奖金额）打印出来。这些日志会在流程运行历史中看到。
• 模拟输入 ：在开发阶段，不要每次都去读真实文件夹。可以使用“变量设置”节点，手动模拟一个图片的Base64字符串或一个固定的JSON作为输入，提高调试效率。

5.2 常见问题与解决方案

在实际搭建中，我遇到了以下几个典型问题：

1. OCR识别字段错位或遗漏 ：

   • 现象 ：发票代码识别成了日期，或者金额字段没识别出来。
   • 排查 ：首先检查原始发票图片质量是否清晰、有无倾斜。然后核对腾讯云OCR返回的完整JSON，看目标字段是否存在于其他位置。
   • 解决 ：
     • 提升图片质量 ：在流程前端增加一个“图片预处理”节点（可用代码实现），进行灰度化、二值化、纠偏等操作，能显著提升OCR精度。
     • 调整识别接口 ：腾讯云有“通用印刷体识别”和“增值税发票识别”等多个接口。对于发票，务必使用专用的“增值税发票识别”接口，它的字段定位准确率远高于通用接口。
     • 备用方案 ：如果某个关键字段（如发票号码）置信度太低，可以触发重试或记录为“需人工复核”。

2. 抽奖平台请求失败（403/404） ：

   • 现象 ：模拟提交的HTTP请求返回403禁止访问或404未找到。
   • 排查 ：
     • 检查请求头 ：特别是 User-Agent 、 Referer 、 Cookie 。有些网站会验证这些信息。尝试从浏览器中复制一个完整的、最新的Cookie字符串填入。
     • 检查参数格式 ：确认参数名、参数值格式（如日期格式）与浏览器抓包看到的一模一样。有时候多一个空格、少一个引号都会导致失败。
     • 检查接口时效性 ：网站可能更新了接口。重新抓包确认。
   • 解决 ：模拟浏览器行为是一个“攻防”过程。如果网站有简单的反爬机制（如验证码），这个方案就可能失效。此时需要考虑其他合法途径，如关注官方是否提供查询API。

3. WorkBuddy流程执行超时 ：

   • 现象 ：流程运行到一半自动中断，日志显示超时。
   • 排查 ：WorkBuddy对单个流程的执行时间可能有限制（如5分钟）。
   • 解决 ：
     • 优化流程，将耗时的操作（如下载大文件、复杂计算）移到外部服务或异步处理。
     • 如果是因为处理大批量发票，可以修改流程，一次只处理一张发票，通过外部调度（如每分钟触发一次）来实现批量处理。

4. Base64编码或JSON解析错误 ：

   • 现象 ：代码节点报错，提示编码错误或JSON格式无效。
   • 排查 ：检查上游传递给代码节点的变量数据类型是否正确。文件读取节点输出的是二进制流，需要确保在编码前其格式正确。
   • 解决 ：在代码节点中加入异常捕获和更详细的日志打印，例如 try...except 块，将错误信息输出到日志，便于定位。

5.3 部署与安全建议

当流程调试通过后，就可以部署上线了。

1. 触发方式 ：将开始节点从“手动触发”改为“定时触发”。设置为每天固定时间（如早上9点）运行，处理前一天收到的所有发票。
2. 密钥管理 ：腾讯云的 SecretId 和 SecretKey 是最高机密。 绝对不要 硬编码在流程的代码节点或配置框中。
   • 正确做法 ：使用WorkBuddy提供的“密钥管理”或“环境变量”功能。将密钥保存在那里，在流程中通过变量引用的方式使用（如 {{secrets.TENCENT_SECRET_ID}} ）。这样即使流程配置被他人看到，密钥也不会泄露。
3. 文件管理 ：流程处理完的发票文件，最好能移动到“已处理”文件夹，或者重命名，避免下次被重复处理。可以在流程最后添加一个“文件移动”或“重命名”节点。
4. 监控与告警 ：除了成功通知，也要关注失败情况。确保错误处理分支的通知渠道是有效的，能让你第一时间知道流程出了问题。

6. 项目总结与扩展思考

这个“发票抽奖小助手”项目虽然不大，但完整地串联起了文件处理、AI识别、网络请求、流程判断和消息通知等多个环节，是一个非常好的WorkBuddy入门和实践案例。

回过头看，整个项目的核心价值在于 “将重复、琐碎的数字劳动自动化” 。它节省的不仅仅是每次手动输入的那几分钟，更是避免了因枯燥而产生的拖延和因粗心导致的错误。当自动化流程第一次准确无误地识别出发票并告诉我中奖时，那种成就感远超150元奖金本身。

几个可以继续深化的方向：

1. 多平台适配 ：目前只对接了一个抽奖平台。可以扩展流程，让它根据发票类型（如不同省份的发票）自动选择对应的官方平台进行查询，实现全覆盖。
2. 结果聚合与统计 ：不要只满足于通知。可以在流程最后，将每次查询的结果（发票号、金额、是否中奖、中奖金额）追加写入到一个在线表格（如腾讯文档、Google Sheets）或数据库中。年底就能生成一份清晰的“发票抽奖年度报告”。
3. 处理更复杂的文件 ：现在的流程主要处理图片和PDF。如果收到的是压缩包，或者发票信息在邮件正文里，可以增加“解压缩”、“邮件解析”等前置技能节点，让流程的入口更友好。
4. 精度与成本平衡 ：对于腾讯云OCR，可以评估其“标准版”和“高精度版”的识别效果与价格。对于绝大多数清晰的印刷体发票，标准版已完全够用，成本更低。

最后，分享一个最深的体会： 在自动化项目中，最耗时、最考验人的往往不是核心逻辑的开发，而是对各种边界情况的处理和异常流程的打磨。 比如发票图片不清晰怎么办？网络超时怎么办？平台改版了怎么办？一个健壮的自动化流程，必须把这些“怎么办”都考虑进去。WorkBuddy这样的可视化工具，恰恰能让这些复杂的逻辑判断和错误处理路径变得清晰可见，降低了构建稳定自动化系统的门槛。如果你也有类似的重复性工作，不妨从一个小点开始，尝试用自动化解放自己。