首页 文章 精选 留言 我的

精选列表

搜索[WorkBuddy],共4351篇文章
优秀的个人博客,低调大师

#WorkBuddy# 我让 AI 校了 50 份财务表格,它漏掉了一个会毁掉集团评审的数字

> 我用大模型校稿,发现个要命的事:**它对表格的"理解"停留在文本层面,根本看不到数字层面的硬错**。等领导把表格甩回来的时候,我才发现——一份"看似完美"的增资报告里,藏着多个数字硬错,每个都足以让集团评审毙掉。 这篇文章写给所有**用 AI 校表格、改表格、写表格的人**。我会告诉你:现在的 AI 表格工具在老财务面前就是小儿科,遇到复杂数字问题直接抓瞎;以及我用什么思路、什么工具把它解决了。 --- ## 一、工作中的痛点:AI 看表格,到底"看"到了什么? ### 1.1 我经历的真实事故 去年我帮一家公司做增资请示报告校稿。流程是这样的: 1. 把 Word 主文 + Excel 附件丢给 AI 1. AI 读 → 输出校稿意见 1. 我审 → 改 → 出稿 AI 校完说"问题不大"。领导接手后,**第一句话**: > "今年研发费用怎么只有 1 万元?" 我翻回去看表格——**断崖 + 反弹**。AI 一字没提。 更糟的是后面审计发现的: |#|问题|AI 是否抓到| | --- | --- | --- | |1|某年研发费用 1 万元(暴跌 5000 倍)|❌ 漏| |2|收入小计 vs 子项差 2000 多万|❌ 漏| |3|IRR 8.5% 未含本次增资(口径错误)|❌ 漏| |4|项目成本两年口径不一(付现/权责混用)|❌ 漏| |5|备注"年均增长 30%" 实际年化 20.6%|❌ 漏| **5 个硬错,AI 一个都没抓到。** ### 1.2 为什么 AI 抓不到? 我事后复盘,发现根本原因是**AI 看表格的方式错了**: **错误做法**(主流 AI 校表格的标准流程): ``` xlsx → 转成 Markdown 文本 → LLM 读文本 → 输出"看起来不对"的地方 ``` **问题在哪**: ``` 2024 收入:0.5 亿 2025 收入:0.0001 亿 2026 收入:0.565 亿 ``` LLM 看到的是 3 行文本。**它不知道 0.5 → 0.0001 是 5000 倍断崖**,因为它没有"数字直觉"——它看到 0.0001 就是一个"小数字",不是"异常值"。 再比如 IRR 测算: ``` 2026 年(T0)净现金流:-1.42 亿 ... 2030 年:+0.01 亿 2031 年起转正 IRR:8.5%,回收期 8.3 年 ``` AI 看到"IRR 8.5%,回收期 8.3 年"觉得"挺合理"。但**它根本不知道**——本次增资 2.2 亿压根没进现金流表。这 8.5% 是"经营 IRR",不是"增资项目 IRR"。**口径错误**。 ### 1.3 老财务怎么看表格? 我跟一个做了 20 年审计的老前辈聊,他说: > "你看 Excel 表,最重要的不是算,是**找关系**。先看几个 sheet 页,摸清楚结构;再扫公式,看哪些是死的、哪些是活的、表和表之间怎么勾;最后**逐行比对**,差 1 分钱都不放过。" 他顿了下: > "说白了,Excel 就是格式化数据。**按数据库处理就行了**——sheet 是表,列是字段,公式是 JOIN 和 GROUP BY。" 我突然被点醒。过去 2 年我用 AI 校表格,都让 LLM "读"——读不到的就跳过。但其实我应该让它"查"——查公式、查引用、查量级。 这就是我开始做这套工具的起点。 ### 1.4 现有 AI 表格工具的 3 大流派(看完你就懂为什么抓瞎) 为了搞清楚"市面上有什么",我花了 2 周调研 4 套主流方案: |流派|代表|强项|短板| | --- | --- | --- | --- | |官方派|Anthropic xlsx skill(simonw/claude-skills 镜像)|金融模型规范(蓝/黑/绿/红/黄五色)、公式重算|不查公式、不做量级校验、只验算| |实战派|WPS 灵犀(本地 App)|内置 Python sandbox 跑 pandas 行级算术校验,逐行比对 v(N) vs v(N-1) 数字量级合理性|闭源,没法借鉴代码| |工作流派|davila7 spreadsheet skill|5 步标准工作流 + 视觉检查|流程完整但不做数字层面的智能校验| |方法流派|vasilyu1983 document-xlsx(74⭐)|Do/Avoid 清单 + I/C/O(输入/计算/输出)分离 + Model Review Checklist|方法论强,工具代码弱| **没有任何一家把"看 → 查 → 比 → 改"四阶段 + 11 项数字规则做到一起**。 更扎心的是——**老财务的"逐行比对 + 差 1 分钱都不放过"**,主流 AI 工具**一个都做不到**。这就是"小儿科"的本质。 --- ## 二、怎么解:把表格当数据库,让 AI 走 4 阶段 ### 2.1 核心思路:表格 = 数据库 如果你接受"Excel 就是格式化数据",那所有 AI 校表格的难题都能套数据库思维解: ``` sheet → 表(table) 行/列 → 字段(field/column) 公式 → 视图(view)/ JOIN / GROUP BY 小计行 → SUM(子项) 跨表引用 → foreign key + JOIN 同比/环比 → window function ``` 数据库怎么查数据,AI 就应该怎么查表格。 ### 2.2 四阶段强顺序流程 ``` ┌─────────────────────────────────────────────────────────────┐ │ Phase 1 · 看 读懂结构 │ │ ↓ 多 sheet 摘要 + 单 sheet schema(行/列/标签/数据型) │ ├─────────────────────────────────────────────────────────────┤ │ Phase 2 · 查 找关系 │ │ ↓ 找公式 → 追溯引用 → 画跨表引用图 → 分类求和 │ ├─────────────────────────────────────────────────────────────┤ │ Phase 3 · 比 找差异 │ │ ↓ 11 项数字合理性自动校验 + 多版本 diff │ ├─────────────────────────────────────────────────────────────┤ │ Phase 4 · 改 改内容 │ │ ↓ 批量改 + 增删 + recalc + 改完自动审计 │ └─────────────────────────────────────────────────────────────┘ ``` **强顺序**——不看完结构不能查关系,不查清关系没法比差异。**这就是老财务的"先看结构、再扫公式、最后逐行比对"**,只是把它流程化、可执行化。 ### 2.3 11 项数字合理性自动校验规则 Phase 3 的核心是**11 项确定性规则**——不靠 LLM 推理,纯逻辑判断,**两次跑结果必须一致**: |规则|含义|抓的是| | --- | --- | --- | |R1|小计 = 子项之和|漏列/重复/并入| |R2|同比/环比骤变 > 10× 或跌至近 0|漏填/公式失效(如 0.5 → 0.0001)| |R3|备注 CAGR 与实际年化一致|备注增长率 vs 实际数| |R5|IRR 闭环(含初始投资)|增资 IRR vs 经营 IRR 口径| |R8|累计行单调性|累计逻辑错| |R9|公式-缓存值一致|LibreOffice 未跑| |R10|关键字段缺失|必备字段缺| 每条规则的输出都是 JSON: ``` { "rule": "R2", "severity": "🔴", "location": "1.效益测算表!D27 (6.研发费用)", "evidence": "C=0.5000 → D=0.000100 (暴跌至近0)", "suggestion": "强烈怀疑漏填或公式失效,优先核实" } ``` **关键设计**:LLM 只负责"理解发现",不参与"判断对错"。**这是工具和 LLM 协作的核心边界**。 ### 2.4 为什么不用 LibreOffice? 主流方案用 LibreOffice 重算公式。但这玩意 macOS 上不一定有、启动慢、还偶发卡死。我的方案:**直接读 Excel 缓存值,不重算**。代价:未跑过 LibreOffice 的文件会触发 R9 提示。**99% 场景够用,且启动 相关阅读: - [Anthropic 官方 xlsx skill 镜像](https://github.com/simonw/claude-skills) - [vasilyu1983 document-xlsx(74⭐)](https://github.com/vasilyu1983/ai-agents-public) - [davila7 spreadsheet skill](https://github.com/davila7/claude-code-templates) - [AI Agent 自动化处理 Excel 表格实战教程](https://www.youres.cn/post/1274.html)(主流写法参考) ---

优秀的个人博客,低调大师

让 WorkBuddy 自己领积分:# 用 Python + OCR 驯服 Electron 桌面客户端:一次「每日签到」自动化实战

# 用 Python + OCR 驯服 Electron 桌面客户端:一次「每日签到」自动化实战 > 一、背景:为什么一个简单的"签到"这么难 很多桌面软件(尤其是基于 Electron / Chromium 的跨平台客户端)都内置了"每日签到领积分"这样的运营功能。点一下按钮,积分到账——动作本身很简单,但当你想把它**自动化**时,会发现它处处是坑: - 窗口是 GPU 渲染的,常规截图一片黑; - 系统开了 150% 缩放,坐标忽而对忽而错; - 用 `pyautogui` / `mouse_event` 模拟点击,光标明明移到了按钮上,却**毫无反应**; - 双显示器下窗口跨屏,截图函数直接卡死; - 配置成定时任务后,第二天发现它"偷偷"跑了不止一次。 本文记录我用 Python 把一个 Electron 客户端的"每日签到"做成**稳定、幂等、可定时触发**的自动化任务的完整过程。其中 90% 的工作量都不在"点按钮"本身,而在和 Windows 图形子系统"斗智斗勇"。 --- ## 二、整体思路 目标很明确:让脚本在每天固定时间,**无需人工干预**地完成: 技术选型: |环节|方案| | --- | --- | |窗口定位|EnumWindows + 进程路径匹配| |截图|PrintWindow 失败回退 mss| |按钮识别|RapidOCR 多尺度文本检测| |鼠标点击|PostMessage(WM_LBUTTONDOWN/UP) + 客户区坐标| |健壮性|空闲检测、锁屏检测、幂等判断| |定时触发|平台自动化任务(每天 02:00 单次)| --- ## 三、第一关:截图——`PrintWindow` 为什么一片黑? 最直觉的截图方式是用 `PrintWindow` 把窗口内容"画"到一张内存位图上: 对普通 Win32 窗口这招很好用,但对 **Electron / Chromium 渲染的窗口**,GPU 合成层不走 GDI,于是你拿到的是一张**纯黑(或纯白)位图**(均值 `arr.mean() **坑点**:`mss.grab` 传入的坐标必须是**物理像素**且落在某个显示器范围内,否则它会**无限阻塞**(不报错、不返回)。下一节讲怎么处理。 --- ## 四、第二关:坐标体系与 DPI 陷阱 这是最容易让人"算错坐标"的地方。我的环境是系统缩放 150%(DPI=144)。 **结论先行**:`GetWindowRect`、`mss.grab` 返回的坐标,**全程都是物理像素**,和窗口在屏幕上的真实位置一致;而 `SetCursorPos` / `PostMessage` 客户端坐标也接受物理像素,**不需要再乘 1.5**。 我曾一度"自作聪明"地加了一层缩放: 验证方法很简单:用 OCR 在截图上找窗口标题栏文字,得到它的真实像素位置,再和 `GetWindowRect` 对比——两者一致,证明**根本不存在逻辑→物理的换算**,那层 `×1.5` 是画蛇添足。 **多显示器裁剪(关键)**:我的窗口矩形是 `(474,129)-(3600,1965)`,而主屏只有 `2560×1440` 宽。窗口横跨到右侧副屏之外,`mss.grab` 因为区域超出可见范围而**永久卡死**。必须先把抓取区域裁到所有显示器的并集内: 再加一层**线程超时**,防止任何意外阻塞拖垮整个任务: 实测加上这两步后,跨屏抓取从"卡死 2 分钟"变成"约 30ms 返回"。 --- ## 五、第三关(核心突破):`SetCursorPos` 点了等于没点 这是整个过程**最关键的发现**,也是本文最想分享给读者的经验。 前面所有准备就绪后,我用最"标准"的方式点击头像: 结果:光标确实挪到了头像上方,**但菜单从不弹出**。我扫了 20 多个坐标点(头像左缘、中心、右缘、上 5px/下 5px……)全部无效。 原因:`mouse_event` / `SendInput` 这类 **"合成输入"** 走的是系统的"低级输入队列",而 Electron 的渲染进程对来自输入法/辅助功能的合成事件有**过滤或不响应**的情况(尤其在窗口未处于"前台输入焦点"或被 accessibility 层拦截时)。 **解法:绕过输入队列,直接把鼠标消息投递到目标窗口过程**: **第一次尝试就弹出了头像菜单**——这就是整条链路打通的瞬间。 > 划重点:`PostMessage` 用的是**客户区坐标**(相对窗口客户区左上角),而 `SetCursorPos` 用屏幕坐标。务必用 `ScreenToClient` 转换,否则坐标会整体偏移一个窗口边框/标题栏的尺寸。 ### 实测有效坐标(供参考,实际以你自己的 OCR 为准) |操作|屏幕坐标|客户区坐标| | --- | --- | --- | |左下角用户头像|(574, 1912)|(100, 1783)| |菜单项「签到领积分>」|(886, 1272)|(412, 1143)| |面板「立即领取」|(587, 1826)|(113, 1697)| --- ## 六、按钮识别:让 OCR 只认"对的"按钮 截图有了,点在哪?用 **RapidOCR** 做文本检测,但要注意**防误命中**: - 侧边栏常驻的"每日领取 Buddy 加油..."对话标题里也含"签到/领取",会干扰; - 聊天记录里用户发的图片标注「立即领取 (红框)」不是按钮。 所以识别时要**限定搜索区域 + 精确关键词 + 优先精确匹配**: 经验:把"头像→菜单"的搜索区限制在小窗格内、用连续词「加油站」而非「签到」(后者会误中同名对话),命中率显著提升。 --- ## 七、健壮性:别在错误的时间瞎点 定时任务最大的不确定性是——**触发时电脑可能在锁屏、屏保,或你正用着鼠标**。 1. **空闲检测**:用户 2 分钟内动过键鼠就跳过(避免抢走操作): 1. **锁屏/屏保判定**:通过当前输入桌面名判断(`Winlogon`=密码锁,`Screen-saver`=带密码屏保,`Default`=正常): 1. **幂等**:点击前先 OCR 判断是否已「已领取」,是则直接结束;点击后再复检,避免重复领取。 --- ## 八、落地:配置定时自动化任务 脚本稳定后,用平台自带的**自动化任务**能力挂上调度即可。核心配置要点: - **工作目录**指向脚本所在目录(`buddy-points`); - **触发命令**直接调用解释器跑脚本: - **执行频率**:每天 **02:00 单次**(凌晨窗口,机器多半空闲、锁屏自愈逻辑也能兜住); - **模型**:交给轻量模型执行,无需人工值守。 (小插曲:我一度在系统里看到了**两个同名签到任务**——旧的残留注册没清干净,导致同一脚本被调度了两次、白天还弹窗打扰。最终删掉陈旧任务、保留唯一的 02:00 任务才干净。**教训:重建自动化任务后,务必确认旧的注册被彻底移除,否则会出现"重复触发 + 记忆分裂"。**) --- ## 九、踩坑清单(直接抄) 1. **Electron 窗口 `PrintWindow` 黑屏** → 用 `mss` 屏幕抓取。 1. **`mss.grab` 跨屏卡死** → 先把区域裁到显示器并集,再加线程超时。 1. **DPI 缩放坐标错乱** → `GetWindowRect`/`mss`/`PostMessage` 都是物理像素,别乱乘缩放。 1. **`SetCursorPos`+`mouse_event` 点了没反应** → 换 `PostMessage(WM_LBUTTONDOWN/UP)` + **客户区坐标**。 1. **OCR 误命中聊天/标题文字** → 限定搜索区域 + 精确关键词 + 短文本优先。 1. **定时任务重复触发** → 删除陈旧任务注册;脚本内做幂等与空闲/锁屏保护。 --- ## 十、结语 "每日签到"看似是个体力活,真正难的从来不是"点一下",而是**在 Windows 图形子系统、DPI、多显示器、Electron 渲染架构、输入安全模型之间找到那条能稳定走通的路**。 本文最核心的一条经验是:**对 Electron/Chromium 客户端,别迷信 `pyautogui`/`mouse_event`,`PostMessage` + 客户区坐标才是可靠之选。** 配合 `mss` 截图与 OCR 定位,你就能把任意桌面客户端的"点点点"流程,改造成一个安静、幂等、凌晨自己跑的自动化任务。 祝你的积分,天天到账。🪙

资源下载

更多资源
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册