ARTICLE · 1011016
用AI从零造一个OCR工具:我的文本计算器信创版诞生记
用AI从零造一个OCR工具:我的文本计算器信创版诞生记前阵子在公众号上介绍了一款OCR工具，没想到有读者留言说： "我用文本计算器的图片识别取字功能来实现OCR功能，挺好用的！" 这条留言让我眼前一亮。说实话，我之前只把这个工具当作计算器来用，从没想过它还能当OCR工具。于是我也去找了一款文本计算器来研究，发现它确实很好用——拍一张含文字的图片，它就能识别出来，还能对里面的算式自动计算。 但很快我发现一个问题：这款工具在信创系统上用不了。 银河麒麟、统信OS 这些国产操作系统，生态还在建设中，很多Windows上的小工具都没有对应的版本。对于信创电脑用户来说，找一个好用的工具并不容易——要么需要联网，要么需要安装复杂的运行环境，要么干脆不支持国产芯片。 能不能自己做一款？ 这个工具理论上并不复杂，我打算用AI来完成这个工具的制作。 做技术项目，最怕的就是一上来就动手。方向错了，后面全是白干。所以我先让豆包帮我做方案设计。 我跟豆包说清楚了需求： 能从图片中识别文字和算式 识别后能自动计算 纯离线运行，不依赖网络 单文件，双击就能用，不装任何软件 Windows + 信创平台兼容 支持国产CPU（飞腾、龙芯等） 豆包给出了好几个技术方案，我逐一分析筛选： 最终选择了 PP-OCRv6 Tiny + ONNX Runtime WASM 的方案。这个方案的核心思路是：把完整的 OCR 引擎（包括AI模型）全部打包进一个 HTML 文件，利用浏览器的 WebAssembly 技术运行，不需要任何后端服务。 方案确定后，我把详细的技术方案交给豆包，让它生成全部代码。 豆包的代码生成能力确实强。我描述功能，它写代码： "做一个 Tab 切换界面，左边文本计算器，右边普通计算器"——它生成了完整的 UI "加入中文数字识别，'二十五'要能转成 25"——它写好了转换算法 "支持自然语言算式，'苹果5元一斤买了3斤'能自动算"——它实现了解析引擎 整个项目的代码量很大，最终的 HTML 文件有 26MB，里面包含了： OCR 引擎代码（525KB） AI 检测模型（2.5MB） AI 识别模型（6MB） WASM 运行时（13MB） UI + 计算逻辑 这些如果手写，一个专业程序员也得花不少时间。而豆包在方案设计确定后，很快就生出了可运行的初版代码。 代码生成完了，但距离"能用"还差得远。这一步是最花时间的，也是AI编程最真实的现状——AI能写出代码，但跑不通的地方还得人来解决。 问题一：引擎找不到 初版代码在浏览器里打开，OCR 引擎直接报错"PaddleOcrService not found"。原因是引擎代码被封装在一个函数内部，没有导出到全局。 解决办法：在引擎代码的末尾加了两行导出代码。这个豆包很快就修好了。 问题二：DOM 元素冲突 引擎代码初始化时会去查找页面上的 HTML 元素，但我们的界面结构跟它预期的不一样，导致一堆"element not found"的报错。 解决办法：加了一个 DOM 安全代理——找不到元素就返回一个"假对象"，让引擎代码能正常运行。用完之后还要记得恢复原始的 DOM 方法，否则界面交互就失效了。 这个问题来回修了三轮。 问题三：国产系统上的"噩梦" 在 Windows 上好不容易调通了，放到银河麒麟 V10 + 飞腾 D2000 上一跑，直接崩溃。 错误一个接一个： 每一个问题单独看都不难，但叠加在一起就很折磨。而且修了一个问题，可能又冒出两个新问题。 这就是AI编程的真相：AI生成的代码不是拿来就能用的，调试工作量可能比写代码还大。 问题四：最隐蔽的 Bug 最后一个卡了我很久的问题是：WASM 二进制数据明明已经内嵌到 HTML 里了，但运行时就是报"BufferSource argument is empty"（空数据）。 查来查去，原因简单到让人无语：**两个 块的执行顺序反了。** 数据定义在后面的脚本块里，但使用数据的代码在前面的脚本块里。前面的脚本运行时，数据还不存在，所以拿到的是空的。 调整了一下脚本顺序，问题瞬间解决。 这个 Bug 用AI很难自动发现，因为它不是代码逻辑错误，而是文件结构问题。这种问题只能靠人来排查。 经过多轮调试，工具终于在多个平台上都跑通了： 纯离线，file:// 协议直接打开 单文件 26MB，无需安装 PP-OCRv6 Tiny 引擎 + 语义计算 + 中文数字识别 做完了这个项目，我对"用AI编程"这件事有了比较真实的感受： 1. AI擅长方案设计和代码生成 让豆包做技术方案、生成代码，效率确实比手写高很多。尤其是代码量大、重复性工作多的场景，AI的优势很明显。 2. AI不擅长调试和排查 AI生成的代码能跑通的概率不是100%。尤其是在复杂环境下（比如信创系统、离线场景、特殊浏览器），各种兼容性问题AI很难提前预见。调试工作目前还是得靠人。 3. 人要做"导演"，不是"码农" 用AI做软件，人的角色更像是导演——提需求、选方案、验收成果、解决问题。不需要你手写每一行代码，但需要你对技术方向有判断力，对问题有排查能力。 4. 信创生态需要更多这样的工具 这次做工具的过程中，我深切感受到信创系统上实用工具的匮乏。很多在Windows上随手可得的小工具，在麒麟、统信上找不到替代品。希望这个文本计算器能帮到有需要的同学，也希望能有更多开发者关注信创生态。 文本计算器信创版已开源，MIT License，可自由使用、修改、分发、商用。 获取方式：关注本公众号「信创电脑技巧社」，回复"文本计算器"获取下载链接。 如果你觉得这篇文章有用，欢迎转发分享给更多信创电脑用户 ?? 信创技巧社 · XinChuang Skills Society 专注信创电脑实用技巧和工具分享