TemuCanvas 是面向 POD 帆布画 / 框画场景的图像自动可用性系统。这篇整理它的定位、核心流程，以及为什么它不是单纯的图片处理脚本，而是围绕真实业务图像建立的找图与可用性判断项目。

项目定位

TemuCanvas 是面向 POD 帆布画 / 框画场景的图像自动可用性系统。

它不是单纯的图片处理脚本，也不是一次性批处理工具。它关注的是商品图输入之后，如何自动识别可用候选，如何判断图像是否适合进入后续流程，如何保留人工复核和错误放行控制，并把失败样本纳入持续改进。

更准确地说，TemuCanvas 是一个围绕真实业务图像建立的找图与可用性判断项目。

为什么做这个项目

POD 商品图处理不是简单的“把图片裁一下”。

真实输入里会出现多目标、规格图、低置信度样本、边缘残留、画框边界、背景干扰、裁切偏松或主体识别失败等问题。如果只依赖单个脚本自动输出，很容易把错误结果放进生产链路。

TemuCanvas 的核心目标不是追求完全自动化，而是建立一套“尽快可用、保留人工兜底”的图像处理流程：自动生成候选，自动分流风险，人工复核不确定样本，失败样本进入下一轮改进。

不是单纯图片处理脚本

脚本只解决局部动作，系统要解决流程问题。

TemuCanvas 关注的不是单张图怎么处理得更漂亮，而是一个批次进入后，如何让结果可追踪、可复核、可回滚、可继续改进。因此它会关注输入目录、模型版本、候选输出、分流结果、人工复核、失败样本、批次记录和冻结基线，而不仅是图像处理算法本身。

核心流程

当前公开层面可以概括为几个阶段：

  1. 输入整理：确认本批次图片来源一致，避免历史输出和新输入混在一起。
  2. 候选生成：对商品图进行识别、矫正或生成候选输出。
  3. 自动分流：把结果分成可直接候选、需要后处理、需要人工 review、明显失败或 hard case。
  4. 人工复核：对不确定样本进行人工判断，避免错误结果直接放行。
  5. 失败诊断：把连续出现的问题和有价值的失败样本整理出来。
  6. 版本冻结：保留模型、脚本、参数、输出和关键记录，形成可回退的生产基线。

这个流程的重点是可控，而不是盲目追求“全自动”。

可用性判断

TemuCanvas 的判断重点不是“有没有生成图”，而是“这张图能不能进入真实工作流”。

一个结果可能主体正确但边缘有轻微问题，也可能模型不确定但仍然有参考价值，还可能看似成功但裁错主体。不同情况需要不同处理方式。因此项目会把结果拆成不同层级：可作为交付候选的结果，需要逐张确认的结果，需要人工判断的 review 样本，以及应隔离保存的 hard cases。这种分流机制比单纯的成功 / 失败更适合真实项目。

人工复核与错误放行控制

TemuCanvas 不假设自动输出永远可信。

人工复核不是低效补丁，而是当前阶段必要的质量阀门。对于多目标图、规格图、低置信度样本、明显裁错或主体缺失样本，系统应该停止自动放行，交给人工判断或进入失败样本池。错误放行控制的目标是：宁可把不确定样本拦下来，也不要让错误结果无声进入后续生产链路。

和 ACE 的关系

TemuCanvas 是 ACE 在图像处理场景里的实践样本：

  • 任务分层：简单批次走轻量流程，高风险改动先做方案和验收标准。
  • 数据管理：输入、候选、review、hard cases 和冻结包需要有清楚边界。
  • 失败诊断：失败不是只报错，而是要判断问题来自数据、模型、脚本、环境还是人工流程。
  • 版本冻结：模型、脚本、输出和关键记录需要形成可回退的事实层。
  • 最少充分验收：每次改动只验证直接影响的关键链路，避免完全不验收，也避免过度回归。

当前状态与后续

TemuCanvas 已有较多历史探索和生产流程积累，但在 Anchor AI Lab 里仍以 Building / Draft 状态呈现–公开站点沉淀的是项目方法和可复用经验，而不是直接公开完整生产系统或内部路径。

后续三个方向：公开版项目说明（边界与不做什么）、流程复盘（候选生成 / 复核 / 放行 / 诊断 / 冻结的可复用方法）、Skill 沉淀（把反复有效的图像 review、批次验收和 hard case 处理沉淀为 ACE Skill）。