这次不是纸上谈兵是刚赶完的一个落地项目。我给公司那套跑了很多年、后端基于 Java 的老订单系统装了一个叫 OpenClaw 的“数字员工”。简单说它是一个能本地部署、能听懂指令、能自动操作浏览器和命令行的 AI 智能体框架。我把 OpenClaw 部署在 Ubuntu 服务器上让它每天定时登录系统后台自动审核新订单同时爬取几个公开行业站点的数据最后把审核结果和统计数据汇成 Excel 报告自动发出去。这套组合不是为了追新。老系统的功能没有任何问题真正的问题是重复操作太磨人。以前每天要先人工打开后台按编号核对订单金额、备注、库存状态再切到行业网站翻页面抄几个数字最后打开 Excel 手动填表耗时、容易漏还极其无聊。OpenClaw 接管“看、读、点、判断”的过程Java 负责提供可靠的数据接口和报表生成两边各干自己擅长的事。项目从部署到跑通大约花了两周踩坑和调优的时间占了一大半。下面我把完整链路按模块写清楚包括接口怎么设计、规则怎么喂给 OpenClaw、爬数据怎么控边界、POI 生成图表有哪些坑可以直接当施工图纸用。想动手做类似事情的朋友建议先把整体思路读完再开干。很多问题不是搞不定而是顺序不对导致返工。1. 需求拆解老系统里的“人肉操作”到底该不该自动化1.1 老系统每天实际在重复什么我这边遇到的场景在传统企业里非常典型。系统本身是 Java 技术栈早年基于 Spring MVC 搭建后来陆续加了不少新接口但核心业务还是原来那套。每天大概有三百到五百个新订单进来表面上系统能自动接单审核环节却一直是半人工。审核人要打开后台订单列表逐个查看订单金额、客户备注、库存状态如果备注里出现“加急”“测试”“特殊折扣”这类关键词还要再打开客户资料二次确认。这个动作非常机械但因为涉及资金和客户体验历史原因让它长期由人完成。除了订单审核每天还要填一份内部报表。报表的数据源包括订单汇总、退货数量以及几个公开行业网站上某类商品的价格和物流状态。以前运营同事手动抄后来我们写临时脚本导数据但脚本只负责把数据拉下来剩下整理格式的活儿还是得靠人。整个过程占用的时间不算多可问题是每天都得有人记得做一旦哪天忘掉后面环节全受影响。真正推动我用 OpenClaw 的原因不是某一次操作多累而是这类“低技术含量但高频”的任务积少成多把团队精力一点点耗干了。1.2 为什么选择 OpenClaw 这类数字员工而不是硬写 Java 脚本第一反应当然是写自动化脚本。如果只是审单完全可以用 Java 加 Selenium 模拟点击但我很快打住了。真正的麻烦在于页面结构会改、弹窗会出现、偶尔还有加载等待或验证码。每调一次业务流程脚本就要跟着改一遍时间一长脚本比老系统还难维护。OpenClaw 这类智能体框架解决的是另一层问题它把“目标”交给大语言模型理解自己则通过浏览器、命令行、API 等工具去执行。比如我告诉它“打开订单后台筛选所有状态为待审核的订单逐条调用订单审核接口把返回结果是异常的单子记录下来”它会把这个指令拆成“打开页面、点击筛选、读取列表、调用接口、记录结果”的动作序列。页面改版了它还能基于视觉和页面结构重新定位目标。这比把每个元素选择器写死在脚本里要抗造得多。但 OpenClaw 不是银弹。它适合“目标明确但步骤多变”的场景不适合“步骤极其固定、量大到每秒几千次”的场景。后者老老实实写 Java 高性能流程就好。我的判断标准很简单如果同样的事情让一个实习生做他能听一句指令就灵活换方法那就适合 OpenClaw如果必须像复读机一样严格按固定套路做一万次那就适合传统脚本。1.3 Java 在整套方案里的不可替代性既然规则这么重要那为什么不把订单判断逻辑直接丢给 OpenClaw 的模型去完成因为业务规则需要确定性。比如判断订单是否异常规则是“订单金额大于 5000 且备注包含‘加急’或‘测试’则不自动通过”。这种规则如果让大模型口头判断它会因为措辞不同给出一会儿走样一会儿一致的结论。但做成 Java 接口后OpenClaw 只负责传参和取结果规则的唯一执行方是 Java 代码结果完全可控。给模型再聪明的能力也不如让它在关键业务规则上“闭嘴只调接口”。另外老系统所有的订单、客户、商品数据都在 MySQL 和原有的 Java 服务里。让 OpenClaw 直连数据库风险太高不仅容易产生脏数据还会绕开销货、日志、库存校验等原有逻辑。标准做法是让 Java 服务暴露接口OpenClaw 通过 HTTP 调接口。这样它不需要知道数据库密码也不需要理解业务表结构只需要知道“调哪个接口、传什么参数、看什么返回值”。这套分隔带来三个直接好处。第一规则可以回归测试改一个条件不会牵连全局第二权限可控OpenClaw 永远不会拥有超出需要的数据库权限第三操作有日志Java 服务每一次被调用都会留下完整记录。这三个好处在后面排查问题时帮了大忙。2. 环境与部署OpenClaw 本地一键部署的完整过程2.1 Ubuntu 服务器准备与 Docker 安装我用的是配置不算高的云服务器2 核 4GOpenClaw 本体跑在上面够用。选 2 核 4G 是因为它并非在本地跑大模型推理而是通过 API 方式接入已有的模型服务省下了大量显存内存。如果还要在本地跑 13B 以上的模型建议直接升到 4 核 16G 起步。服务器系统选了 Ubuntu 22.04 LTS。先把系统更新和基础工具装好sudo apt update sudo apt upgrade -y sudo apt install -y git curl docker.io docker-compose-v2 sudo systemctl enable --now docker安装完 Docker 后把当前用户加入 docker 组避免每次执行 docker 命令都要 sudosudo usermod -aG docker $USER newgrp docker到这里环境基础就绪。OpenClaw 提供一键部署脚本常见方式是仓库 clone 下来后执行./install.sh或docker compose up -d。我建议优先用容器化部署升级、回滚、备份都方便。裸机安装也能跑但依赖 Python 环境、Node 环境和浏览器驱动系统很快会被搞得乱七八糟。2.2 OpenClaw 的配置与启动部署目录我放在/opt/openclaw克隆仓库后先不急着启动把配置看一遍。这里最关键的配置有三项。第一项是模型服务地址。OpenClaw 需要大模型做“大脑”这个模型可以在本地用 Ollama 跑也可以接云端模型 API。我内网有一台私有化部署的服务地址填http://10.0.0.5:8000模型名按实际写。如果是云端模型记得配置里用环境变量引用 API Key不要直接明文写在.env文件里提交到 Git。第二项是浏览器自动化开关。OpenClaw 默认内置 Playwright需要保证容器有权限拉取 Chromium。Docker 容器里首次启动前需要执行playwright install chromium否则打开浏览器会直接报错。第三项是端口映射。OpenClaw 管理面板默认跑在 3000 端口建议只做内网端口映射不要直接暴露公网。启动命令docker compose up -d启动完成后访问http://服务器IP:3000能看到管理面板和任务日志说明部署成功。这里要补一个实操建议第一次启动后用docker compose logs -f盯十分钟日志重点看模型服务是否连接成功、Playwright 是否初始化完成。这两个是后续一切任务的基础早发现问题比事后再查快得多。2.3 用最简单的任务验证全链路部署成功之后不要急着接订单接口先用一个最简单的任务验证全链路。我在管理面板输入“打开百度首页把页面标题读出来并返回给我。”如果 OpenClaw 成功返回标题说明模型、浏览器、任务执行三层都通了。如果卡在这一步多半是模型 API 地址不对或网络不通先排这个。下一步测试更接近真实场景的动作“打开一个本地测试网页点击页面上的按钮检查页面是否弹出一个包含‘完成’文字的提示。”这个任务覆盖点击、等待、读取结果三类动作等于把后面要用到的基础能力预演了一遍。这时候如果发现等待时间不够、按钮定位不准都还来得及调而不是在真实订单上磕磕绊绊。2.4 接入 Microsoft Teams 之类的通知渠道OpenClaw 可以接入聊天工具比如 Microsoft Teams 或企业微信把审核摘要和异常订单实时推送到团队群比邮件更及时。很多人在热搜里找 OpenClaw 接入 Teams 的方法其实原理不复杂OpenClaw 作为 bot 注册到 Teams之后在群里发一句“开始今天的审核”它就会触发对应工作流。对管理者来说非常友好。配置方式是在管理面板找到渠道配置填入 Teams 应用的 Bot Token 和群聊 ID。这里要注意 Bot 权限范围只开放消息发送不要给它群成员管理之类的无关权限。顺带提一句Teams 群最多能容纳的成员数和历史消息保留策略各团队可能不太一样配置的时候结合实际使用场景确认一下。2.5 Java 老系统的对接准备等 OpenClaw 跑通测试的同时我在 Java 老系统里准备好了对接接口。项目是老的 Spring Boot没有现成的内部接口于是新增了一个InternalController专门给 OpenClaw 调用。两个注意事项接口路径不要暴露公网只允许内网访问接口全部走独立 Token 鉴权不能复用系统登录态。目录结构建议就三个文件order-server/ internal-api/ OrderReviewController.java CrawlDataController.java ReportController.java每个 Controller 只放一个外部自动化入口逻辑保持薄薄一层不塞复杂业务直接调用原有 Service。这样后续加任务、加权限、改逻辑都不会牵一发动全身。3. 自动审单 API 开发与 OpenClaw 提示词编排3.1 订单审核接口的字段设计与幂等处理我最初设计的接口很简单就是POST /internal/order/review传订单号和备注返回通过或异常。实际跑起来发现漏洞很多。OpenClaw 可能因为网络超时重试同一个订单如果接口不幂等同一个订单被审核两遍库存和状态就可能被改乱。改造后的接口长这样POST /internal/order/review Content-Type: application/json { orderNo: SO20250101001, source: openclaw, requestId: uuid-xxxx, fields: { amount: 5200, customerLevel: B, remark: 加急, stockStatus: 1 } }返回值{ code: 0, result: PASS, reason: 金额未超限备注无风险关键词, reviewId: RV20250101001 }字段设计上有个细节不能只传一个订单号让 Java 自己查那样 OpenClaw 需要先查询再调用多一步且容易读错。更稳的做法是 OpenClaw 页面读到什么关键字段就传什么Java 收到后自己再做一次核对。requestId是幂等键如果 Java 发现同一个requestId已处理过直接返回上次结果不重复执行审核逻辑。幂等实现用一张review_log表字段包括request_id、order_no、result、create_time对request_id建唯一索引。插入时捕获重复键异常回查历史结果返回。这套机制解决的不只是 OpenClaw 的重试以后其他自动化系统误调也不会造成重复处理。3.2 Java 接口的实现代码参考下面给一段简化版代码展示核心流程去掉了缓存和事务细节重点看逻辑RestController RequestMapping(/internal/order) public class OrderReviewController { Autowired private OrderReviewService reviewService; PostMapping(/review) public ResponseEntityReviewResult review(RequestBody ReviewRequest req) { // 幂等检查同一 requestId 直接返回旧结果 ReviewResult cached reviewService.findByRequestId(req.getRequestId()); if (cached ! null) { return ResponseEntity.ok(cached); } // 核心规则判断全部在 Java 侧完成 boolean risky req.getFields().getAmount() 5000 || req.getFields().getRemark().contains(加急) || req.getFields().getRemark().contains(测试); boolean stockOk req.getFields().getStockStatus() 1; ReviewResult result new ReviewResult(); if (!stockOk) { result.setResult(MANUAL); result.setReason(库存不足转人工确认); } else if (risky) { result.setResult(MANUAL); result.setReason(触发高风险规则转人工复核); } else { result.setResult(PASS); result.setReason(常规订单自动通过); } result.setReviewId(reviewService.saveReview(req, result)); return ResponseEntity.ok(result); } }这里有个踩坑点别把MANUAL当成REJECT。MANUAL的意思是“我不能拍板需要人再看一眼”REJECT是“直接拒绝”。OpenClaw 拿到MANUAL时必须把订单转到人工待审列表如果模型把MANUAL理解成“审核不通过”反馈给客户很容易引发投诉。所以 Java 接口的返回字段设计尽量用不会产生歧义的英文单词并且配合下方的提示词把每个状态解释清楚。3.3 给 OpenClaw 的规则说明怎么写OpenClaw 的行为很大程度上受系统提示词和工作流配置影响。审单任务的提示词我建议按这个风格写你是订单审核助理。你的职责是逐一处理“待审核”列表中的订单。 步骤 1. 使用订单后台页面定位状态为“待审核”的订单。 2. 逐一读取订单编号、金额、客户等级、备注、库存状态。 3. 把读取到的字段通过 POST 请求发送到订单审核接口。 4. 根据接口返回结果分类 - PASS在页面标记为“已通过”进入下一单。 - MANUAL记录到人工复核清单不要执行任何修改。 - REJECT在原订单上添加拒绝备注并记录原因。 5. 最终汇总数量并返回结果摘要。 注意 - 任何情况下都不要绕过接口自己判断。 - 遇到页面加载失败等待重试不要重复提交同一个 requestId。 - 接口超时超过30秒标记为待人工处理不自动重试。这份提示词把“判断权”牢牢锁在 Java 接口上模型只负责“搬运”和“执行”。我见过不少人让模型直接看备注然后自己决定结果某个订单备注写“加急但不测试”模型就认为不该转人工而真实规则是只要包含“加急”就要转人工。这种误判一旦发生就是线上事故必须靠接口强制约束。3.4 异常订单的人工兜底闭环再稳的自动化也要有兜底。整个流程分三段OpenClaw 自动触达、Java 规则判断、异常单进入人工队列。人工队列放在老系统原有的待办中心。OpenClaw 不需要处理这个队列人只需要打开老系统后台看到一条“自动审核转人工”的待办展开可以看到 OpenClaw 读取到的原始字段和转人工原因处理人员对自动化机制无感知界面还是熟悉的界面。联调阶段建议先放少量订单验证比如只用五个测试订单走全流程。OpenClaw 跑完后人工核对订单状态与预期是否一致确认无误再放开全量。不要一上来就跑几百单万一规则写错一天的单都会进错状态那场面光是回滚就够喝一壶。4. 定时爬取公开数据Java 解析与 OpenClaw 网页自动化4.1 数据源与采集边界“爬数据”这个概念热度一直很高但很多项目不是死在技术上而是死在采集边界上。我的数据来源有两个一个是公司内部系统的物流接口一个是几个公开行业网站展示的价格、行情和发货状态。对公开网站只采集列表页展示出来的内容不登录、不提交表单、不抓取用户个人信息访问频率控制在每 30 秒一次以内保证不对目标站点造成压力也符合“公开数据、合理访问”的基本原则。动手前我把数据源整理成了配置表在系统里用一张crawl_source_conf表维护字段包括数据源名称、URL、采集字段、更新频率、用途、状态。好处在于流程可观测而且某个数据源改版时只需要停用配置不需要改代码。采集的方向分两类一类是“增量实时采集”比如物流状态每隔一段时间自动刷新另一类是“存量趋势采集”比如价格走势每天固定抓快照。Java 定时任务负责存量同步OpenClaw 负责那些需要点击翻页才能拿到的动态页面。4.2 Java HttpClient Jsoup 的抓取实现对结构简单、不依赖 JavaScript 渲染的页面直接用 Java 抓取解析就够了。示例代码public class SimpleCrawler { public ListPriceItem fetchPriceList(String url) throws IOException { HttpClient client HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(10)) .build(); HttpRequest request HttpRequest.newBuilder(URI.create(url)) .header(User-Agent, Mozilla/5.0 (compatible; InternalCrawler/1.0)) .header(Accept, text/html,application/json) .timeout(Duration.ofSeconds(30)) .GET().build(); HttpResponseString response client.send(request, HttpResponse.BodyHandlers.ofString()); Document doc Jsoup.parse(response.body()); ListPriceItem items new ArrayList(); for (Element row : doc.select(table.price-list tr)) { // 解析每一行数据封装成 PriceItem } return items; } }设置User-Agent是关键一步很多站点对空 UA 请求会直接返回 403。同时抓取一定要设超时避免单个页面卡死整个定时任务。读出来的数据先转成统一的PriceItem再进下一步去重和入库。4.3 OpenClaw 接管“翻页、点击、等待”类动态操作有些页面数据是前端 JS 异步加载的或者需要一直点“下一页”按钮。Java 直接抓会碰到无限滚动、动态 token、异步接口签名等麻烦。这时候 OpenClaw 的价值就体现出来了。我给 OpenClaw 配了一条采集工作流提示词大致是打开目标数据页。 等待列表出现数据。 读取当前页第一列到第五列的数据。 点击“下一页”按钮等待内容刷新后继续读取。 重复直到没有下一页按钮。 将每次读取的数据按字段汇总后通过 POST 请求发送到数据接入接口。OpenClaw 执行时就像一个长了眼睛的浏览器能判断按钮和表格位置即使页面异步加载也能靠等待元素出现拿到正确数据。这比在 Java 里维护 XPath 选择器省心得多因为选择器变了 Java 代码要改OpenClaw 则能靠模型推断出新的定位方式。但这种动态采集不适合高频大流量。OpenClaw 跑一次采集比 Java 直接抓慢得多更适合每天固定跑几次的低频任务。如果每天几万条数据的增量老老实实用 Java 写定向爬虫就好OpenClaw 会被性能拖垮。4.4 数据的去重、入库与版本管理不管是用 Java 抓还是 OpenClaw 提交数据进入系统后都走同一个入库管道。在数据接入接口里做了三件事。第一件是去重。对每条数据计算指纹把“时间、来源、商品ID、当前价格”拼接后做 MD5指纹已存在就不再插入避免 OpenClaw 重复提交产生重复记录。第二件是状态变更检测。老系统需要知道“今天这个商品比昨天涨了还是跌了”每条价格记录除了保存当前值还会与该来源该商品最后一次记录对比生成change_flag字段后续报表直接读这个字段不用每次现算。第三件是审计。所有来自自动化任务的数据都带上sourceopenclaw或sourcejava-scheduler标记某天数据异常时能快速定位是哪条链路的责任。这里提醒一下入库接口也要做幂等。指纹去重只能针对“完全一样”的数据一旦 OpenClaw 页面没加载全提交字段缺失的数据指纹就不一样可能生成半条脏记录。接口层要用requestId做全局去重参考审单接口的设计别只依赖业务指纹。5. 自动生成报告用 Java POI 输出带图表的 Excel/Word5.1 为什么坚持用 Java 生成报表很多人问既然 OpenClaw 都能操作浏览器了为什么不直接让它用在线版办公软件生成报表答案很简单报表模板格式非常固定有公司标准样式、指定字体、列宽、合并单元格和图表。让模型直接操作在线表格格式随机性太大这次对齐下次不对齐老板看了要骂人。Java 用 Apache POI 生成报表是真正可控的字体、颜色、单元格合并全部代码写死每次生成结果一致。另外一个原因是有历史资产。老系统本身就在用 Java 处理报表逻辑把同类逻辑集中到 Java 侧后续改模板、加栏目、调整数据口径都方便不用再去学一套新的表格自动化工具。5.2 Excel 图表实现与 POI 常见坑“Java POI Word 能生成图表吗”这个问题我经常在热搜里看到。答案是能但不是直接往 Word 里塞一个图表对象就行需要结合 Drawing 和图片。先看 Excel 图表POI 支持用 XSSFChart 绘制柱状图、折线图、饼图。下面是最小可用的 Excel 图表代码思路try (XSSFWorkbook workbook new XSSFWorkbook()) { XSSFSheet sheet workbook.createSheet(价格趋势); // 准备数据行... XSSFDrawing drawing sheet.createDrawingPatriarch(); XSSFClientAnchor anchor drawing.createAnchor(0, 0, 0, 0, 3, 1, 15, 12); XSSFChart chart drawing.createChart(anchor); chart.setTitleText(近7日价格走势); chart.createLegend().setPosition(LegendPosition.BOTTOM); // 使用 XSSFChart 添加折线图数据源... }这里坑很多。老版本 POI 创建图表的 API 不兼容升级版本后代码经常要调整图表默认样式比较丑要单独设置系列颜色中文字体在 Linux 服务器上缺渲染字体时生成图片会出现方块。后面这个坑最严重因为文件本身没问题但服务端渲染图片缺字体打开一看全是口口口。解决方法是安装中文字体sudo apt install -y fonts-noto-cjk装完字体生成图片就正常了。这个坑不踩一次真想不到。5.3 把图表放进 Word 报告的方案如果最终交付物是 Word我建议不要花大力气尝试在 Word 里画原生图表而是把图表作为图片嵌入最省事、兼容性也最好。流程是用 POI 生成 Excel内含图表。用 Java 把 Excel 转成 PDF 或截图可以通过 LibreOffice headless也可以直接用 JFreeChart 渲染图表。用 XWPFParagraph 往 Word 文档里插入图片。把最终 docx 保存或推送。这个方案在任意版本 Office 里打开都不会图形错乱。直接尝试在 Word 里嵌原生图表生成的 XML 可能和不同版本 Office 不完全兼容打开后图形丢失或格式漂移处理成本远高于“图片嵌入”方案。5.4 报告分发与执行记录报告生成后发送方式是 Java 的邮件服务直接发给内部收件人列表同时把摘要内容通过 OpenClaw 推到 Teams 群。如果邮件发送失败原始 docx 文件会保留在服务器上方便重发。所有报告生成动作都在数据库里留档表结构大致是report_id、report_type、file_path、status、trigger_source、create_time。出现“今天怎么没收到报表”的问题时先在表里查执行记录能立刻定位是定时任务没触发、OpenClaw 没跑完还是邮件服务挂了。这个思路比漫无目的地翻日志高效得多。6. 上线后的排查清单与避坑实录6.1 最让我头大的几个问题速查表把实际遇到过的问题整理成一张速查表回头排查直接对表症状根因解法OpenClaw 卡在等待页面元素超时页面异步加载慢等待策略太短调大等待超时时间页面出现关键元素再继续Java 接口收到重复审核请求OpenClaw 重试导致接口增加 requestId 幂等处理生成 Excel 的图表是空白Linux 缺少字体渲染安装 fonts-noto-cjk或改用预生成图片OpenClaw 偶尔漏读一个订单字段页面表格列顺序变化提示词里增加“如果字段缺失停止操作并记录”定时任务凌晨跑批超时采集页面响应慢拆分任务数据采集和审核任务错峰执行这个表里最常复发的是第一条。OpenClaw 操作浏览器时它等待页面元素的能力取决于模型对页面状态的判断。页面加载慢的时候它会误以为页面已经完成直接去读内容自然读不到。我后来在提示词里强制要求“先确认元素存在再读取内容读取失败就 wait 三秒重试”这个问题才算基本缓解。6.2 权限与安全红线给数字员工开权限记住“最小权限”四个字就够了。我给 OpenClaw 单独建了一个服务账号只授予订单查询和标记权限没有删除、导出、修改客户资料的权限。数据库完全不透给它所有写操作都通过 Java 接口转发。Java 接口的 Token 定期轮换避免长期有效的高危凭证泄露。老系统积累了行级权限逻辑Java 服务对普通用户会限制“这个业务员只能看自己的订单”。给 OpenClaw 的接口不能走普通用户权限体系要走独立自动化权限体系但拿到数据后也不能越过行级权限把全量客户数据写进报表。我在报表接口里加了字段白名单只允许输出订单总额、商品数、异常数等统计值不允许输出客户姓名、联系电话这类明细。OpenClaw 的所有操作日志要全量保存。除了它自己的任务日志Java 接口侧也记录每次调用的来源 IP、requestId、参数、返回结果。日志是自动化系统的救命稻草没有半分钟前谁干了什么所谓排查就是猜。6.3 给你的落地顺序建议如果想让这套方案安全落地建议分四步走。第一步先做只读任务。让 OpenClaw 登录后台读取当天订单列表把订单详情存下来不做任何修改。跑一周统计它读数据的准确率。第二步接入只读审单接口让 Java 返回判定结果OpenClaw 只展示结果不自动改订单状态。这样可以验证接口判断和人工判断的一致性。第三步放开自动标记。前两步累计准确率超过预期了再允许 OpenClaw 调用写接口修改订单状态。第四步逐步加入爬取数据、报表生成、消息推送最终形成完整的夜间自动流程。很多人一上来就想全部自动化结果出了问题还得回滚反而打击了团队对自动化系统的信任。循序渐进才能让这套东西真正被接受。我个人实际跑下来最深的体会是OpenClaw 和 Java 的搭配并不是谁取代谁而是各管一摊模型负责理解不可控的世界Java 负责保证可控的业务。老系统之所以让人痛苦从来不是因为它跑得慢而是因为它每天把人的时间消耗在毫无创造性的点击和抄写上。给老系统配一个数字员工本质上是把重复还给机器把判断留给人。这个项目跑通之后团队里没人再提“晚上记得审单”这件事因为大家终于可以放心下班了。最后再分享一个小技巧接口的返回字段尽量用全称英文加状态码数字比如{code:0,result:PASS}少用中文枚举这样不管模型怎么理解程序侧都不会认错。