---------------|-----------|
| 需求分析 | 拆解为前端上传、后端 API、PDF 处理模块 |
| 代码生成 | 生成 Flask API 服务器、前端 HTML/CSS/JS |
| 技术选型 | 选择 pypdf+PIL 替代 pdf2image，解决 Windows 兼容性 |
| 调试排错 | 解决跨平台依赖问题 |
| 文档撰写 | 生成 README、API 文档、技术解读 |

举个例子：你要处理 1000 份扫描件 PDF，把它们转成可搜索的文本存入数据库。传统做法是手动 OCR 或者买商业 API 服务。用 OpenCode + PaddleOCR，你可以：

1. 让 OpenCode 写一个批量处理脚本
2. 脚本遍历目录 → 调用 PaddleOCR → 结果存入数据库
3. 后续同类需求，直接改参数就行

整个过程你不需要理解 PaddleOCR 的 API细节，OpenCode 会帮你生成、调试、优化。OpenCode 接到需求后的处理方式：

1. 理解需求 → 确定技术栈（Flask + PaddleOCR）
2. 设计架构 → 前端上传 → 后端 API → OCR 引擎 → 返回结果
3. 编写代码 → 生成 paddleocr_api.py、index.html
4. 解决难点 → PDF 跨平台处理方案（pypdf + PIL 而非 pdf2image）
5. 整理文档 → README、技术解读

你不需要写一行代码，只需要描述需求和确认方向。

图片 OCR 流程（OpenCode 生成代码示例）

用户上传图片（PNG/JPG）
       ↓
Flask 接收文件（multipart/form-data）
       ↓
保存到临时目录
       ↓
PaddleOCR 识别（ocr.ocr）
       ↓
构建 Markdown 返回
       ↓
JSON 响应 {success, text, stats}

这个流程跑通后，你可以上传任意图片，拿到结构化的文字提取结果。

PDF OCR 流程（跨平台方案）

PDF 处理比图片复杂一点，因为 PDF 里的内容可能是文本层（直接可提取），也可能是嵌入图片（需要先 OCR）。

OpenCode 生成的方案用了 pypdf + PIL，而不是 pdf2image——原因是 pdf2image 需要安装 poppler 依赖，在 Windows 上需要手动配置环境变量，对普通用户不够友好。pypdf + PIL 是纯 Python 方案，跨平台兼容更好。

用户上传 PDF
       ↓
pypdf 读取 PDF
       ↓
尝试 page.extract_text() 提取文本层
       ↓
有文本？→ 是 → 直接用
         否 → 提取 XObject 中的嵌入图片
              ↓
         PIL 转换为 PNG
              ↓
         PaddleOCR 识别临时图片
              ↓
         返回 Markdown 结果

这套方案的关键决策点是 OpenCode 帮你做的——它权衡了跨平台兼容性和实现复杂度，最终选了 pypdf + PIL。这个决策本身就有价值，省去了你自己踩坑的时间。

PaddleOCR vs Tesseract：选哪个

这是两个最主流的开源 OCR 方案放在一起对比：

简单结论：
- 纯文字提取 + 快速上手 → Tesseract（装完就能用）
- 复杂文档（表格、印章、多语言混合、中文为主）→ PaddleOCR
- 想让 OpenCode 帮你写代码 → 两者都行，PaddleOCR 中文场景更强

安装配置速查

# 安装 PaddlePaddle（CPU 版）
pip install paddlepaddle

# 安装 PaddleOCR
pip install paddleocr

# 快速试用（中文识别）
python
>>> from paddleocr import PaddleOCR
>>> ocr = PaddleOCR(lang="ch")
>>> result = ocr.ocr("path/to/image.png")
>>> print(result)

⚠️ Windows 踩坑记录：PaddleOCR 在 Windows 上首次运行会自动下载模型文件（约 100MB），如果网络不稳可能导致下载失败。国内建议配置国内镜像源，或者手动从 PaddlePaddle 官网下载模型后再放到本地目录。

# 指定本地模型路径（避免每次下载）
ocr = PaddleOCR(
    lang="ch",
    det_model_dir="./inference/ch_det_mv3_db/",
    rec_model_dir="./inference/ch_rec_mv3_crnn/",
    rec_char_dict_path="./ppocr/utils/ppocr_keys_v1.txt"
)

长期 OCR 需求？自己搭个网页更划算

如果你有长期图片、PDF转文字需求，完全可以自己动手开发个简单网页，部署后随时用，体验非常快。不再为付费OCR发愁，也不依赖那些价格飘忽的商业API。而且并不是所有AI模型都有图片理解能力——有这个需求的话，自己封装小工具是挺划算的选择。还可以结合 OpenCode 的 Skill 流水线，把项目中常用的文档处理流程固化下来，反复跑。

写在最后

OpenCode + PaddleOCR 这个组合的价值不在于"OCR"，而在于把文档识别能力变成可编程的日常工作流。你可以让它帮你写批量处理脚本、搭 Web OCR 服务、做多语言混合文档识别——这些以前需要专门写代码实现，现在用自然语言描述需求就能做到。

PaddleOCR 的生态已经相当成熟（Dify/RAGFlow/Cherry Studio 都在用），OpenCode 的代码生成能力也能稳定跑通 PaddleOCR 的 API。两者结合的本质是：让 AI 帮你写调用 AI 能力的代码。

你在用 OpenCode + PaddleOCR 做什么？或者有什么文档识别的需求？评论区说说。