绕开 API/MCP，让电脑自己给知识库打标签：一个被"没有接口"逼停的项目，如何用"模拟人"重启

折腾了pi_computer_use后，就想着看能不能让我的“知识库自动打标”项目继续了，以下是今天的尝试（先说结果：今天还没能实现自动打标）

如果你读过我的「尝试用 WorkBuddy 搭建 IMA 知识库标签系统」系列（写到第 3 篇），那你一定记得那个结局—— 整套打标引擎全跑通了（8 种文档格式提取、受控词表、731 篇自动判标、10/10 测试全过），却卡在最后一步：平台没有打标接口，只能一篇篇手动点。项目因此暂停。 这篇文章，就是那个暂停项目的重启记录。我换了一条完全不同的路——不调 API、不走 MCP、不申请 KEY，而是用 Computer Use（模拟人操作电脑） 让脚本像人一样看屏幕、右键、点"编辑标签"、输入标签。全程绕开所有缺失的接口。我会把整个过程、踩过的坑、最后的解决方案、以及还没解决的问题，一股脑讲清楚——包括我上一篇文章里一个被现实打脸的判断。

一、前情回顾：那个"脑好手残"的项目

先快速回顾一下这个系列之前做了什么（没读过的也能跟上）：

我在公众号上写过「尝试用 WorkBuddy 搭建 IMA 知识库标签系统」系列文章，核心目标是给一个有 10660 篇文档的行业知识库（线束知识库）设计一套自动标签体系。

到第 3 篇时，我已经完成了这些：

从"读文档"到"该打什么标签"，整套智力活都完工了。

然后撞上了一堵墙——

把标签写回知识库。

IMA 平台没有提供打标的 API（OpenAPI 一调是 404），MCP 工具是只读的（ima-mcp 已连接，但只能查不能写）。想批量把 700 多篇标签结果写回去？没有通道，只能人工在界面上右键 → 编辑标签 → 输入 → 确定，一篇一篇来。

项目因此暂停。

这不是什么罕见困境。很多企业内部系统、行业 SaaS、老桌面软件，都是"功能很强、接口为零"。你明明算好了结果，却只能雇人照着点鼠标。

二、转机：没有 API，就"模拟人"

暂停了一段时间后，我摸清了另一套能力：Computer Use——直接让 AI（或者说脚本）像人一样看屏幕、点鼠标、敲键盘。

它的核心思想特别朴素：

它不调用软件的接口，也不走任何 API。它只是"看屏幕 → 找按钮 → 点鼠标 → 敲键盘"，和你我操作一模一样。

这正是它的价值所在——当一款软件没有 API、你又拿不到 KEY 时，Computer Use 用"模拟人"的方式，替掉了那个本该由数据接口完成的事。

我用到的底层栈是 pi-computer-use（一个开源的 Windows 桌面操作扩展），它靠一个叫 windows-bridge.exe 的小程序驱动，封装了 Windows 的 UI 自动化。而我真正把它用活的，是让我的本地 AI 助手（WorkBuddy）绕开那个自主智能体，直接 spawn 这个 bridge，按 JSON 行协议发命令——这样脚本一旦写定，运行时根本不需要 AI、不需要 KEY、不需要联网。

（这套"人 + 翻译编排 + 机器人脚本"的三方联动，我在《让电脑自己干活》那篇里详细写过，这里不重复。本文只聚焦一件事：用这套能力，复活那个被"没有接口"逼停的打标项目。）

三、第一次撞墙：我原以为它是网页，能走 CDP 后台

刚看到 IMA 知识库的网页版（ima.qq.com）时，我挺乐观。

它是网页应用，DOM 驱动，控件有真实引用。按 Computer Use 的能力清单，操作网页系统的首选路径是 CDP 浏览器自动化——后台运行、不抢鼠标、抗弹窗、零 KEY。我甚至准备好了一套"进文件夹 → 开文档 → 输标签 → 确认"的 CDP 模板。

在《让电脑自己干活》那篇文章里我也这么写了：

*"IMA 是网页应用（ima.qq.com），DOM 驱动，可用 CDP 浏览器自动化（后台、抗弹窗、零 KEY、零管理员）。"* ——当时觉得这是最稳的路线。

这句话，今天被现实打脸了。

四、第二次撞墙：网页版根本不能打标，PC 客户端又是"黑盒"

实测结论（真机确认 + bridge 实时探测），分两层：

1. 网页版不能打标。 IMA 网页版连文件内容都看不了，更别提打标签。要打标，必须用 IMA PC 桌面客户端（ima.copilot.exe，一个 Electron/Chromium 应用）。这是用户实操确认的铁律——打开文档详情后也不能打标，只能在文件列表层对文件右键操作。

2. PC 客户端是个"黑盒"。 我用 windows-bridge.exe 的 UIA 能力去读它的界面结构，结果：

• 进程 ima.copilot.exe，窗口类 Chrome_WidgetWin_1——确实是 Chromium 内核；
• 但主内容区是一个 document / RootWebArea 黑盒节点，文档列表里的每一行，UIA 树根本不暴露（整个树只有 ~21 个节点，全是 pane/button/edit，没有"文档行"这个可点对象）；
• 更要命的是：打标入口在右键菜单里。正确路径是——在文件列表里右键某个文档 → 点"编辑标签"（上下文菜单第一项）。

而那个右键菜单，是操作系统原生弹出的模态菜单，不挂在 IMA 的 UIA 树里。也就是说：

我想点的"编辑标签"，既不在 DOM 里，也不在 UIA 树里——它飘在系统层，没有任何 ref 给我程序化定位。

更讽刺的是，《让电脑自己干活》里判断"CDP 完全可行"的假设，在这一仗里直接失效：CDP 能进网页、能读 DOM，但打标这个动作偏偏藏在系统原生右键菜单里，CDP 够不着。

结论：所谓"干净的后台 CDP 路线"走不通。我被迫回到最朴素的方式——看屏幕、按坐标点。

五、两条"看屏幕 + 按坐标点"的路线

既然黑盒 + 原生菜单，自动化只能退化为"人怎么点，机器就怎么点"。我手里其实有两套可复用的实现，殊途同归：

路线 A：真实截图 + OCR 认字定位（来自 ima_poc.py）

思路最直接：

1. 用 pyautogui 真实截下 IMA 窗口区域（BitBlt，不受 GPU 合成影响）； 2. 用 RapidOCR 把截图里的文字连坐标一起识别出来，得到一堆带 (cx, cy) 的文本框； 3. 要点哪行，就按文字匹配到对应框，算出屏幕坐标 pyautogui.click(x, y)。

它的坐标模型很清爽：

屏幕坐标 = (窗口起点 x0 + OCR 框的 x, 窗口起点 y0 + OCR 框的 y)

windows-bridge.exe 在这条路线里只干一件事：focusWindow 把 IMA 提到前台，方便截图。其余全靠"真实眼睛 + 真实手"。

路线 B：bridge 驱动（来自 win-desktop-automation 技能）

思路更"官方"一点，全走 bridge 协议：

listRoots（找到 IMA 窗口）   → focusWindow（提前台）   → look(includeImage:true)（截一张带坐标空间的图）   → act(click, 坐标, policy:foreground)（点中文档行）   → act(keypress "Shift+F10", foreground)（弹右键菜单）   → act(keypress "Return", foreground)（选菜单第一项"编辑标签"）

两条路线本质一样：都是"看屏幕 → 按坐标点"。区别只是"眼睛"用 OCR 还是用 bridge 截图，"手"用 pyautogui 还是用 bridge 的 HID 输入。

而这两条路线要操作的"目标"，正是系列文章前几篇里已经产出的成果——标签清单_线束知识库.md（受控词表）和 ima_manifest_connector_folder_api.csv（705 篇已判标的文档清单）。"脑"早就准备好了，现在只是给它接上一双"手"。

六、关键突破：Shift+F10 = 右键菜单

路线 B 里有个真正的巧思，值得单拎出来说。

windows-bridge.exe 的 act 命令不支持 rightClick 动作——你直接发"右键点击"，它报 Unsupported。

但 Windows 有个键盘快捷键：Shift + F10 等效于右键菜单。我改用 act(keypress, keys:["Shift","F10"])，bridge 的响应里立刻出现：

rootDelta: [{ "kind": "popover", "change": "appeared" }]

右键菜单真的弹出来了。 接着补一个 Return（回车），就选中了菜单第一项"编辑标签"。

这一步是整条链路里最关键的破局点——它绕开了"bridge 不支持右键"的限制，用键盘快捷键复刻了人的右键操作，而且 bridge 的 rootDelta 能可信地告诉我"菜单出现了"（不像截图，Electron 窗口截出来是白屏，根本看不清）。

七、踩坑全记录（都是真金白银换来的）

把这几天撞过的墙列成表，省你时间：

八、诚实的边界：还差什么、哪些没解决

文章写到这里，必须说实话——端到端的自动打标，还没 100% 跑通。以下几点是当前真实的遗留问题：

1. 标签输入框的交互方式未验证。 我们验证了"右键 → 编辑标签"能弹出对话框（靠 Shift+F10 的 popover + 回车）。但对话框打开后，标签到底怎么输——是 typeText 逐字敲？setText 直接设值？还是粘贴？标签是自由输入还是下拉多选？这一步还没在真机上闭环验证。

2. 文档行坐标的稳定性存疑。 目前用的是估算坐标（如 (620, 500)）。IMA 的列表会随分组切换、滚动而改变，坐标是否稳定命中文档行，需要真实标定。路线 A 的 OCR 认字定位反而更稳——它是"按文字找"，不依赖固定坐标。

3. 前台抢焦点，无法真后台。 由于 IMA 的 UI 操作必须 foreground，自动化跑起来会动你的真实鼠标键盘。这跟"不干扰真人"相悖。现实做法：写成可双击运行的独立脚本，人离开电脑时（或午休/下班）再跑，配合"空闲检测"守卫。

4. 批量写回的工程纪律。 731 篇不是一次能跑完的。按我一贯的批量对外写入纪律，必须：

• 分多日（平台必有配额/限流，必然中断）；
• 续传状态文件（记录每篇是否已成功，断了能从这续）；
• 幂等跳过（已打的不再打）；
• 按配额反推 ETA（比如每天 13 篇 → 约 56 天，开工就给预期，别等"一键跑完"落空）。

5. UI 一改，坐标全废。 这是坐标路线的天性脆弱。一旦 IMA 更新界面布局，硬编码坐标会错位。缓解靠 OCR 文字定位（路线 A）而非纯像素坐标（路线 B）。

6. 受控词表是唯一的"刹车"。 正因为是模拟人、容易点错，自动化绝不许自由发挥标签。它只能从 标签清单_线束知识库.md 这个受控词表里选（封闭词表）。判标引擎算出来该打什么，脚本就只点那个；清单外的词，一律不当候选直接建。这样即便"手"有点笨，"脑"是规范的。

九、价值总结：把"接接口"换成"一台通用桥"

回到开头那个憋屈：

我算好了 731 篇该打什么标签，却因为平台没接口，只能雇人照着点。

Computer Use 给出的答案是——不接它的接口，直接模拟人去点。

它把难题从"每个软件单独申请 API/KEY"换成"一台通用桥 + 一次登录"：

• 对十个没有 API 的桌面/网页软件，是净赚；
• 对一个已经上好 API 的系统，反而退步（API 更快更准）。

而在"打标签"这个具体场景里，闭环是这样的：

【系列前3篇已完成】   文档提取（8 格式 ✓）     → 受控词表（单一事实源 ✓）     → 判标引擎（731 篇标签结果 ✓）       【本篇：接上"手"】         → Computer Use 写回（看屏幕 + 坐标点 + Shift+F10，进行中...）

前两步是"脑"，最后一步是"手"。脑早在系列文章里就好了，手现在被 Computer Use 接上了——虽然这只手还笨笨的、必须前台、还得防它点错。

写在最后

如果你也跟过这个「IMA 知识库标签系统」系列，这篇文章就是那个被"没有接口"逼停的故事的续集。

绕开 API/MCP 自动打标，不是什么优雅的架构胜利。它有点"野"：看屏幕、按坐标、模拟右键。但它解决的是 API 解决不了的现实——那些没接口、没权限、却天天要人手动点的重复活。

这趟踩坑给我最大的教训，恰好是打了我自己上一篇文章的脸：

别在没真机验证前，就把"应该能走 CDP 后台"写死成结论。网页、客户端、原生菜单，是三堵不同的墙。

如果你也在维护一个知识库、或者被"算好了结果、却写不回去"折磨，不妨想想：这台电脑能不能"自己动手"？

让电脑自己打标签，从绕开那道没有的接口开始。

*（本文是「尝试用 WorkBuddy 搭建 IMA 知识库标签系统」系列的续篇。前 3 篇覆盖了标签体系设计、文档提取引擎、自动判标引擎（覆盖率 96.4%）；本篇聚焦"无 API/MCP 时如何用 Computer Use 模拟人操作完成写回"。所有结论均来自真实环境实测：Windows + IMA PC 客户端 ima.copilot.exe + windows-bridge.exe + RapidOCR + WorkBuddy 本地驱动。）*

本文由AI生成