企业官网建设流程全解析

做包装质检和仓储入库的兄弟一定深有体会：每天经手几百上千个盒子，要挨个确认外包装上的警示图标（小心轻放、防潮、堆码层数）和认证标志（CE、FSC、可回收）是否齐全合规，盯久了眼睛真能看花。我之前做过一个盒装图标自动识别的工具，把整条识别链路拆成了一组功能函数，从图片读取到预处理、轮廓定位、模板匹配、结果输出，每步一个函数，互相独立又能串联调用。这篇文章就把这组函数拿出来逐个拆解，聊清楚每个函数解决什么问题、关键参数怎么定、实际跑起来有哪些坑。适合正在用 OpenCV 做物体识别、想把识别流程工程化的朋友参考。

1. 整体设计与函数架构拆解

1.1 为什么用“函数拆分”的方式来组织代码

这个项目最早是给一个包装产线做辅助质检用的，需求很简单：拍一张外包装盒的照片，程序自动找出盒子表面印刷的各类图标准确归类，最后输出一份结构化结果。一开始我没想那么多，写了一个两百多行的脚本从头串到尾，结果真正跑起来才发现问题——识别准确率不行的时候，你根本不知道是图像预处理环节出了问题，还是模板匹配的阈值设得不对，又或者是轮廓过滤把目标区域给滤掉了。

所以后来我决定把整个识别链路拆成独立的函数，每个函数只做一件事，输入输出尽量单纯。这样做有个直接的好处：可以单独调试每一个环节。比如识别结果偏了，我可以先拿原始图片跑一下find_icon_regions，看看检测出来的候选框到底对不对；如果候选框是对的，再单独测match_template，定位到具体是哪一步丢了精度。项目后期要加新图标，也只需要往模板库里丢几张标准图，完全不用动主流程代码。

拆完之后的函数清单大概是这样的：

1.2 技术选型背后的权衡

可能有人会问：都什么年代了，识别图标为什么不用 YOLO 或者深度学习分类模型，反而用传统的 OpenCV 加模板匹配？这里我确实做过权衡。

盒装图标有一个天然特点：它们是标准化印刷的。同一类图标在材质、颜色、比例上高度一致，不像自然场景里的猫猫狗狗那样有千变万化的姿态。对高度标准化的物体来说，模板匹配是一种性价比极高的方案——不需要收集几千张标注样本，不需要 GPU 训练，测试环境只要有 OpenCV 就能跑。当时项目要求识别 CE 认证、可回收、防潮、易碎、堆码层数这类常规包装图标，我建一个模板库每类只要两三张标准图就够用了。

深度学习当然有它的优势，尤其在图标存在变形、遮挡、光照剧烈变化的情况下，模板匹配容易翻车。但代价也很明显：样本收集和标注成本高，模型训练和调参周期长，产线环境不一定有 GPU 推理。对这个项目来说，先用传统方案把流程跑通，识别率能满足验收标准，比盲目追求“先进”要务实得多。后面如果遇到模板匹配搞不定的场景，也可以用 ORB 特征匹配或者小模型分类作为兜底，这部分我在第四章单独展开聊。

2. 图像预处理：识别成败的第一道关口

2.1 图片加载函数：中文路径的经典坑

load_image这个函数看起来平淡无奇，但它解决了一个非常实际的问题：cv2.imread在 Windows 下遇到中文路径时经常返回None。产线上的图片文件名通常长这样——“2024年度_春季_批次A_包装盒外观.jpg”，如果直接把这种路径丢给cv2.imread，大概率会读到空值，程序报错你都找不到原因。

解决方案是用 NumPy 先把图片文件读成字节流，再交给cv2.imdecode解码：

import os import numpy as np import cv2 import logging logger = logging.getLogger(__name__) def load_image(image_path): """ 加载图像，解决中文路径问题。 cv2.imread 对中文路径支持不友好，需要用 np.fromfile 读入字节流再解码。 """ if not os.path.exists(image_path): raise FileNotFoundError(f"图片文件不存在: {image_path}") img_bytes = np.fromfile(image_path, dtype=np.uint8) image = cv2.imdecode(img_bytes, cv2.IMREAD_COLOR) if image is None: raise ValueError(f"图片解码失败，请确认文件格式: {image_path}") logger.info(f"图片加载成功: {image_path}, 尺寸: {image.shape[1]}x{image.shape[0]}") return image

这里有个细节值得注意：np.fromfile读出来的是一个一维数组，必须指定 dtype 为np.uint8，否则读出来的数据会被当成其他类型导致解码异常。这个函数我在项目里反复用了很多次，凡是遇到“图片读不出来”的诡异问题，十有八九都能归到路径上，用这套读写方案后基本就没再犯过。

2.2 灰度化、降噪与边缘提取

加载完图片之后，下一步是预处理。盒装图标的识别目标和自然场景不同：我们不需要颜色信息来做判断（当然也有例外，比如某个认证标志只有特定颜色，那种情况可以额外提颜色特征），所以第一步就是把彩色图转成灰度图，降低数据量，提高后续处理的稳定性。光照变化对彩色图的影响比对灰度图更明显，因为颜色值会随色温漂移，而灰度图相对更能扛。

预处理我封装在preprocess_image函数里，一次返回灰度图、高斯滤波图和边缘图，方便后面调试：

def preprocess_image(image, blur_kernel=(5, 5), canny_low=50, canny_high=150): """ 预处理流水线：灰度化 -> 高斯模糊 -> Canny边缘检测 blur_kernel: 高斯滤波核大小，越大降噪越强，但边缘也会被抹掉 canny_low/canny_high: Canny双阈值，经验值区间 [50, 150] """ gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY) blurred = cv2.GaussianBlur(gray, blur_kernel, 0) edges = cv2.Canny(blurred, canny_low, canny_high) return gray, blurred, edges

高斯滤波核的选择是有讲究的。核太小（比如 3x3），降噪效果有限，图片上的印刷网点、颗粒噪点会残留很多，Canny 会把这些误检成边缘；核太大（比如 9x9 以上），图标本身的边界线条也会被模糊掉，容易出现断边。我实测下来，5x5 是一个比较均衡的值，既能压掉大部分噪点，又不至于让图标边缘断裂。

2.3 透视校正：把歪着的盒子“摆正”

如果说预处理里哪个函数最容易被忽略但又最关键，我首推透视校正。产线拍照和实验室不同，相机不可能每次都正对着盒面垂直拍，稍微有点角度，盒面上的正方形图标就变成了梯形，直接拿去和模板匹配，相似度会低得离谱。

透视校正的原理类似“正畸”：你已经知道目标盒面大概的形状，或者通过盒子的边缘计算出了四个角点，再把这四个角点映射到一个正方形或矩形的标准坐标系里。这个操作在 OpenCV 里就是一个函数调两个步骤：

def correct_perspective(image, quad_corners, output_size=(300, 300)): """ 透视校正：将倾斜拍摄的四边形区域映射为正视角矩形。 quad_corners: 源四边形的四个点，顺序为左上、右上、右下、左下 output_size: 校正输出的宽度和高度 """ src = np.array(quad_corners, dtype=np.float32) dst = np.array( [ [0, 0], [output_size[0] - 1, 0], [output_size[0] - 1, output_size[1] - 1], [0, output_size[1] - 1], ], dtype=np.float32, ) matrix = cv2.getPerspectiveTransform(src, dst) corrected = cv2.warpPerspective(image, matrix, output_size) return corrected

这四个角点的顺序非常容易搞错，必须是左上、右上、右下、左下按顺时针排。如果顺序乱了，校正出来的图会直接旋转 180 度或者发生镜像，识别就全乱了。项目里我是通过检测盒面的最大外接四边形来动态获取角点的，但产线工位固定时也可以直接硬编码四个顶点坐标，反正相机位置不变、盒子摆放位置固定，这种场景没必要每次做角点检测。

生产环境下我强烈建议提前做好透视校正。模板匹配对角度变化非常敏感，差个几度相似度就能从 0.85 掉到 0.6，直接越过阈值线导致漏判。校正之后的图像统一缩放到 300x300，等于把所有输入图片都放到一个标准尺度上，后续模板匹配的时候就不需要再处理尺度不一致的问题了。

3. 图标定位与提取：锁定候选区域

3.1 轮廓查找与参数过滤

预处理只负责把图片“处理干净”，真正要把图标从盒面上找出来，靠的是轮廓检测。cv2.findContours能在边缘图上搜索出所有封闭区域的轮廓，但盒面上除了图标，还有文字、装饰线条、生产日期喷码等大量干扰元素，直接拿所有轮廓去做模板匹配，计算量巨大而且误判率极高。

因此find_icon_regions里我做了两层过滤：面积过滤和尺寸比例过滤。

def find_icon_regions(edges, min_area=500, max_ratio=0.3, draw_on=None): """ 在边缘图上查找候选图标区域。 min_area: 轮廓最小面积，小于该值的直接忽略（过滤噪点和喷码） max_ratio: 单个区域面积占全图面积的最大比例，防止把整个盒面当图标 """ contours, _ = cv2.findContours(edges, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE) regions = [] for cnt in contours: area = cv2.contourArea(cnt) if area < min_area: continue x, y, w, h = cv2.boundingRect(cnt) if w * h > edges.shape[0] * edges.shape[1] * max_ratio: continue regions.append((x, y, w, h)) regions.sort(key=lambda r: r[2] * r[3], reverse=True) return regions

面积阈值min_area不是拍脑袋定的。我试过把包装盒上的所有元素都放大标出来，观察每个目标图标的像素面积，发现小的认证图标大概占 500 像素左右，大的运输图标能到几千像素，而喷码字符单个轮廓一般只有几十像素。把阈值设在 500，既能滤掉喷码和细纹路，又不会漏掉真正的图标。

max_ratio=0.3这个限制也很关键。盒面上可能有一个满版印刷的品牌 Logo，面积占到全图 30% 以上。如果把它也当成候选图标送进模板匹配，不仅计算慢，还容易干扰结果排序。加了这层过滤之后，那些过大的装饰元素就被排除掉了。

3.2 候选区域排序与提取

筛选完轮廓之后，find_icon_regions返回的是一个区域坐标列表。我在返回之前按宽高乘积从大到小排序，这样做的好处是后续处理的时候可以优先处理大图标——通常大图标就是关键警示标志，识别优先级更高，而且大图标的匹配结果更可信。

拿到坐标列表后，extract_icon负责把每个候选区域从原图上裁剪出来。裁剪的时候我加了一个 padding 参数，默认往里塞 5 个像素的边距。这个 padding 是为了避免轮廓检测把图标的边缘线框正好卡在边界上，导致裁剪出来的图片边缘被切掉一像素，影响模板匹配的相似度。不要小看这一两像素的差异，模板匹配是按像素级别计算相关的，边缘缺一块，得分能掉 0.05 以上。

def extract_icon(image, region, padding=5): """ 从原图中裁剪候选图标区域，带边界保护。 """ x, y, w, h = region h_img, w_img = image.shape[:2] x1 = max(0, x - padding) y1 = max(0, y - padding) x2 = min(w_img, x + w + padding) y2 = min(h_img, y + h + padding) return image[y1:y2, x1:x2]

裁剪时的边界保护是为了防止区域靠近图像边缘时索引越界。Python 的切片语法对越界索引不会直接报错，但结果会给出一个比预期小的图，这种静默异常比报错更难排查，所以我习惯在裁剪前先用max和min把坐标钳制到合法范围内。

4. 识别与分类：核心函数登场

4.1 模板匹配函数

定位到图标区域之后，就进入真正的“识别”环节了。模板匹配的原理说起来很直白：拿待识别的图标和模板库里的每一张标准图逐像素比对，算出相似度得分，分数最高的那个类别就是识别结果。

我用的方法是cv2.matchTemplate加上TM_CCOEFF_NORMED相似度度量，这是 OpenCV 里对光照变化最鲁棒的一种匹配方式，因为它会先对图像做均值归一化，再去计算相关性。换成TM_SQDIFF那种基于差值的算法，对光照会更敏感，实测效果差不少。

def match_template(icon, template_dir, threshold=0.72): """ 模板匹配识别图标。 icon: 待识别的图标裁剪图 template_dir: 模板库目录，文件名就是标签名，如 "CE认证.jpg" threshold: 置信度阈值，低于该值判定为 unknown """ icon_gray = cv2.cvtColor(icon, cv2.COLOR_BGR2GRAY) icon_gray = cv2.resize(icon_gray, (64, 64)) results = [] for template_path in Path(template_dir).glob("*.jpg"): template = cv2.imread(str(template_path), cv2.IMREAD_GRAYSCALE) if template is None: continue template = cv2.resize(template, (64, 64)) score = cv2.matchTemplate(icon_gray, template, cv2.TM_CCOEFF_NORMED).max() label = template_path.stem results.append((label, float(score))) results.sort(key=lambda x: x[1], reverse=True) if not results or results[0][1] < threshold: return "unknown", 0.0 return results[0]

这里把匹配模板之前的图标图像统一 resize 到 64x64 是有讲究的。包装盒上不同图标的原始尺寸差异很大，有的 80x80 像素，有的 200x200 像素，直接用原始尺寸去匹配，模板比例对不上。统一缩放到固定尺寸，等于把尺度归一化，让匹配算法只看“形状和纹理”，不看“尺寸大小”。用 64x64 是速度和质量的一个折中，再大识别率提升有限但计算量翻倍，再小会丢失细节导致误判。

threshold这个阈值我放在参数里而不是硬编码，因为不同生产环境的图片质量差异很大。光照均匀、印刷清晰的场景，阈值可以设到 0.8；环境复杂的场景，设到 0.65 可能才能保证召回率。我在项目里的初始值是 0.72，再根据实际标注结果持续微调。

4.2 识别率不够怎么办：混合识别方案

模板匹配的优势是快和简单，但遇到图标印刷变体、部分遮挡、或者模板库里没有的新图标时就力不从心了。如果你在实际项目中碰到识别率上不去的瓶颈，我建议先别急着上深度学习，试试加上 ORB 特征匹配作为兜底。

ORB 特征匹配不比较整张图的像素，而是先提取图像中的关键点（角点、纹理丰富的小区域），再计算这些关键点的描述子，最后把待识别图和模板库里的图做特征点匹配，通过匹配点数量来判定相似度。它对缩放、旋转、光照变化都比模板匹配更鲁棒，而且不需要训练。

import cv2 def match_template_orb(icon, template_path, min_match_count=10): """ ORB特征匹配兜底函数，适用于模板匹配得分不稳定的场景。 """ orb = cv2.ORB_create(nfeatures=500) icon_gray = cv2.cvtColor(icon, cv2.COLOR_BGR2GRAY) template = cv2.imread(template_path, cv2.IMREAD_GRAYSCALE) kp1, des1 = orb.detectAndCompute(icon_gray, None) kp2, des2 = orb.detectAndCompute(template, None) if des1 is None or des2 is None: return 0.0 bf = cv2.BFMatcher(cv2.NORM_HAMMING, crossCheck=True) matches = bf.match(des1, des2) matches = sorted(matches, key=lambda x: x.distance) good_matches = [m for m in matches if m.distance < 50] return len(good_matches)

这里min_match_count和距离阈值50都要根据实际图标复杂度调整。我在项目中是先用模板匹配快速过滤一遍，得分高于 0.85 的直接判定；低于 0.85 但高于 0.5 的，再调用 ORB 做二次确认；低于 0.5 的基本可以认定不是已知图标，直接归为 unknown。这种分层策略能把召回率提升好几个百分点，而且没增加多少耗时。

另外，如果你的图标里包含大量文字信息（比如“小心轻放”这四个汉字），模板匹配是不擅长处理文字变体的，因为字体、字号、排版一变，像素差异就很大。这种情况可以考虑叠加上 OCR 能力，比如用 PaddleOCR 把图标区域里的文字识别出来，作为模板匹配的辅助信息。这个方向的扩展我在后面展开说。

4.3 主控函数组装全流程

前面这些函数都是单点能力，真正把它们串成一条流水线的是主控函数recognize_box_icons。这个函数的设计原则是：外部调用方只负责传图片路径和模板目录，剩下的流程细节全部内部消化。

def recognize_box_icons(image_path, template_dir="templates", save_dir="output"): """ 主控函数：加载图片 -> 预处理 -> 定位候选区域 -> 逐区域识别 -> 保存结果 """ image = load_image(image_path) gray, blurred, edges = preprocess_image(image) regions = find_icon_regions(edges) results = [] for region in regions: icon = extract_icon(image, region) label, score = match_template(icon, template_dir) results.append( { "region": region, "label": label, "confidence": score, } ) save_results(results, save_dir, image_path) return results

主控函数看起来简单，但有一个关键点：它把整条链路封装成了“对调用方友好”的接口。调用方的业务代码不需要关心预处理细节、不需要手动调每个函数，只需要拿到结构化的结果列表。这样后续即使我在预处理里增加新的增强步骤，或者把模板匹配换成深度学习模型，调用方的代码都不用改动。

主控函数的返回值是一个字典列表，每个字典包含候选区域坐标、识别标签和置信度。这个结构化结果的好处是可以直接被上层业务逻辑消费——比如判断有没有“防潮”图标、有没有“CE认证”图标，直接遍历列表查标签就行。

5. 辅助函数与工程化落地

5.1 结果结构化输出

识别流程跑通了，下一步是把结果落盘。项目里我写了save_results把识别结果转成 JSON 报告，这样下游质检系统可以直接解析，也方便人工复核时查看。

import json import os from datetime import datetime from pathlib import Path def save_results(results, save_dir, image_path): """ 将识别结果保存为结构化的 JSON 文件，文件名带时间戳避免覆盖。 """ os.makedirs(save_dir, exist_ok=True) base_name = Path(image_path).stem timestamp = datetime.now().strftime("%Y%m%d_%H%M%S") report = { "source_image": image_path, "recognized_at": timestamp, "icons": results, } output_path = os.path.join(save_dir, f"{base_name}_{timestamp}.json") with open(output_path, "w", encoding="utf-8") as f: json.dump(report, f, ensure_ascii=False, indent=2) return output_path

JSON 文件名加时间戳是必须的，因为产线上同一张盒子的图片可能在一天内被识别多次，不加时间戳就会互相覆盖。ensure_ascii=False这个参数不能漏，否则 JSON 文件里的中文标签会变成\uXXXX转义序列，人工查看报告时完全没法读。这个坑我踩过一次，后来所有 JSON 输出都固定加上这个参数。

如果团队用的是非结构化存储，也可以把结果直接写进 CSV 或者数据库，核心逻辑都一样——输出结构化数据而不是只在控制台打印。控制台输出只能用来自己调试定位问题，不能作为项目的正式交付物。

5.2 日志与异常处理

工程化项目里，日志跟代码功能同等重要。识别任务跑在产线上，出了问题你不可能每次都盯在终端前看。所以我在项目里给关键函数都加上了日志输出，并且用logging模块而不是print，这样可以通过日志级别灵活控制输出量。

这里分享一个实操经验：日志输出不要只记“成功”，更要记录“失败”和“异常”。我在load_image里遇到文件不存在时会raise FileNotFoundError，在match_template里模板目录为空时会返回("unknown", 0.0)而不是直接抛异常。为什么这样设计？因为产线场景里单张图片识别失败不应该中断整个批次，更合理的做法是标记为 unknown 或 error，记录日志后继续处理下一张，让异常在最终报告里集中暴露出来。这个“fail-open”的思路对于质检辅助工具尤其重要——机器识别不出来不等于这个产品不合格，人工复核兜底才是正确的流程。

异常处理方面，我会在批量调用主控函数外加一层 try-except，把单张图片的异常捕获后写入错误日志，避免一个坏文件拖垮整批任务。

5.3 批量识别与回调搭配

单张图片的识别流程跑通后，你自然会发现下一个需求：批处理。产线上一来就是几十上百张图，逐张调用recognize_box_icons虽然能跑，但效率很低，尤其是模板匹配本身是计算密集型任务，串行处理耗时直线上升。

我给项目加了一个批量识别函数，用线程池来并发处理多张图片。因为模板匹配是纯 CPU 计算，不涉及 GPU，Python 的多线程在 I/O 密集场景下优势不大，但这里瓶颈是 CPU 的matchTemplate，所以用多进程效果更明显。不过为了部署方便，第一版我用的是concurrent.futures.ThreadPoolExecutor，简单直接：

from concurrent.futures import ThreadPoolExecutor, as_completed def recognize_batch(image_paths, template_dir="templates", max_workers=4): """ 批量识别入口：并发处理多张图片，返回每张图的结果。 """ all_results = {} with ThreadPoolExecutor(max_workers=max_workers) as executor: future_to_path = { executor.submit(recognize_box_icons, path, template_dir): path for path in image_paths } for future in as_completed(future_to_path): path = future_to_path[future] try: all_results[path] = future.result() except Exception as e: logger.error(f"图片识别失败: {path}, 错误: {e}") all_results[path] = {"error": str(e)} return all_results

批量处理这里还有一个设计点：如果生产环境是异步任务队列（比如接收一条入库指令，后台处理图片，再回传结果），recognize_box_icons这种同步函数正好可以作为回调函数的内部实现。调起任务的时候把图片路径传进去，任务完成后回调函数拿到结果做后续处理。项目里我就在 Web 端的展示页用了“前端回调函数”的写法，把识别结果异步渲染到页面上，批量任务排队处理，不阻塞用户操作。附带说一句，前端写回调逻辑的时候强烈建议用箭头函数，(res) => { renderResult(res) }比旧式function(res) { ... }可读性好很多，还能避免this指向的坑。

6. 常见问题与排查实录

6.1 环境命令不识别问题

这个项目本身不复杂，但真正落地时拦路最多的往往是环境问题，尤其在新同事的电脑上。最常见的现象是：明明装好了 Python 和 OpenCV，在 CMD 或者 PowerShell 里执行pip install opencv-python，系统却提示“pip 无法识别为 cmdlet、函数、脚本文件或可运行程序的名称”。和这个一模一样的还有git、npm、python都提示无法识别。

这个问题的根源几乎都是PATH 环境变量没有配置。系统在命令行里执行命令时，会去 PATH 指定的目录列表里逐个查找对应的可执行文件，找不到就报这个错。解决步骤很简单：

1. 找到可执行文件的安装目录（比如C:\Users\你的用户名\AppData\Local\Programs\Python\Python311\Scripts\pip.exe所在的目录）；
2. 右键“此电脑” -> 属性 -> 高级系统设置 -> 环境变量；
3. 在“系统变量”里找到 Path，新增一行，把目录填进去；
4. 重新打开命令行窗口，执行pip --version验证。

注意改完环境变量后，已经打开的命令行窗口不会自动生效，必须重新开一个新的窗口。这个细节经常被忽略，导致操作者以为改完没用。

6.2 识别不准的排查路线

如果你遇到的是识别准确率问题，而不是环境问题，我总结了下面的排查清单。建议按顺序查，不要跳步：

这里重点说下第一个原因。模板匹配的上限取决于模板库的质量，模板图必须能和产线拍摄图保持同一种“风格”。项目早期我在网上找了一堆设计原图当模板，结果像素级比对时相似度一直上不去，因为设计原图是矢量的，线条锐利干净；产线照片带噪点、有光照不均。后来我改成直接从产线拍到的清晰盒面图上裁剪图标做模板，识别率一下就上来了。模板匹配就是个“傻瓜式”的相似度比对，你别指望它做抽象推理，模板长得像才是硬道理。

6.3 性能与资源占用优化

项目后期我还做了一轮性能优化。一开始测试跑一张 1200 万像素的产线照片，预处理加模板匹配大约要 3 秒，批量跑下来时间消耗挺大。优化思路有三条：

先降采样。图标识别的输入不需要原图那么高的分辨率，我把图片先缩放到宽 1000 像素左右，处理时间直接降到 1 秒以内。这里要注意降采样不能太狠，否则小图标会丢失太多细节，识别率跟着下降，1000 像素宽度是一个比较稳的经验值。

再压缩模板匹配范围。如果产线工位固定、盒子摆放位置固定，候选区域大概率集中在某个 ROI（感兴趣区域）内，完全可以只用 ROI 范围和模板库比对，跳过整图搜索。这个优化最狠，能直接把计算量砍掉 70%。

最后是并行化。用recognize_batch里的线程池把多张图并行处理，四核机器实测能跑到接近 3.5 倍的加速比。不过要注意线程数不要贪多，Python 的线程切换本身有开销，超过2 倍 CPU 核心数之后加速比反而会下降。

还有一个容易忽略的优化点：统一所有中间图像的尺寸。cv2.matchTemplate处理不同尺寸的图时计算量差异极大，我在上一步就把待识别图和模板统一 resize 到 64x64，不仅让分数有可比性，也大幅减少了计算量。代码注释里记一句“这是为了性能和质量的双重考虑”，下次回来看代码就知道当时不是随便定的尺寸。

这组函数我从最初两百行脚本一路拆到了现在的模块化结构，中间踩过不少坑，也积累了一些心得。对我来说最大的体会是：图像识别项目里，任何一环都不能想当然。中文路径必须处理，透视必须校正，模板必须贴近真实场景，阈值必须实测调整——这些都是“经验税”。现在再让我重写一遍这个项目，我依然会坚持把这些基础环节逐个做扎实，因为识别算法本身只是整个系统的一半，另一半恰恰藏在那些不起眼的辅助函数里。最后分享一个小技巧：每个函数在写完之后，单独写一个测试用例，用一两张真实图片验证输入输出的正确性。别看这个动作不起眼，项目迭代到后期，它能帮你省下一大把回头查 bug 的时间。