Photos in a folder, product live in WooCommerce: a Make.com + n8n pipeline for a refurbished-tools shop

一家销售翻新专业电动工具的商店面临着新货商店所没有的问题：没有制造商提供的照片。每一台设备都各不相同，因此必须逐一进行拍摄、清理和手动上架。每件产品需要几分钟时间。面对数百件产品，这相当于数天的工作量，而且如果交给他人处理，照片质量往往会下降。我为 Luko Tools 构建了一个自动化流程，这是一家位于斯洛伐克的商店，专门销售翻新的 Milwaukee、DeWalt 和 Makita 工具。如今，店主处理每件产品的全部工作就是将照片上传到 Google Drive 文件夹中。本文将介绍该系统的构建方式，以及更重要的一点——我刻意在哪些环节停止了自动化。

What the shop did before For every product the same chain of steps:

• Photograph the product.
• Move the photos to the computer and sort them.
• Fix the quality (refurbished goods are shot in a workshop, not a studio).
• Remove the background so it looks like a product shot.
• Upload to WooCommerce and create the product.
• Fill in the name and attributes and assign a category.

该商店以前的做法是，每件产品都要经历同样的步骤：拍摄产品；将照片移至电脑并分类；修复质量（翻新商品是在车间而非摄影棚拍摄的）；去除背景使其看起来像产品照；上传至 WooCommerce 并创建产品；填写名称、属性并分配类别。

How it works now

• Input: photos land in a Google Drive folder. Nothing else is required from a person.
• Trigger: a Make.com scenario watches the folder and starts by itself, no click.
• Upscale: the photos are enlarged and sharpened to sales quality by an image-processing service over an API.
• Background removal: a workshop shot becomes a clean product photo, again over an API.
• Product creation: the WooCommerce REST API creates the product together with a gallery of the processed images, and it goes live.
• Social post: once the product is live, an n8n workflow builds an Instagram and Facebook post from its photo and name.

现在的运作方式：输入：照片存入 Google Drive 文件夹，无需人工干预。触发：Make.com 场景会自动监控文件夹并启动，无需点击。放大：通过 API 调用图像处理服务，将照片放大并锐化至销售级质量。背景移除：同样通过 API，将车间拍摄的照片转换为干净的产品照。产品创建：WooCommerce REST API 会创建产品并附带处理后的图片库，随后产品上线。社交媒体发布：产品上线后，n8n 工作流会根据其照片和名称自动生成 Instagram 和 Facebook 帖子。

Make.com orchestrates the product chain; n8n handles the social posts. They are separate on purpose: the second workflow only reacts to “a product is now live”, so it can fail, be paused or be changed without touching the part that fills the catalogue.

Make.com 负责协调产品链，n8n 处理社交媒体发布。它们被刻意分开：第二个工作流仅对“产品已上线”这一状态做出反应，因此即使它出现故障、被暂停或修改，也不会影响负责填充目录的部分。

One constraint I’d repeat: don’t touch the shop The whole solution runs outside WooCommerce and talks to it, and to the social networks, only through official APIs. No plugin, no edits to the theme or the shop’s code. That way it can’t break the shop and the shop’s updates can’t break it in a way that is hard to trace. The price of this approach is a precondition: it only works if the platform has an API. WooCommerce has one. With another platform I would check that first.

我必须重申的一个限制是：不要触碰商店本身。整个解决方案在 WooCommerce 外部运行，仅通过官方 API 与商店及社交网络通信。无需插件，无需修改主题或商店代码。这样它就不会破坏商店，商店的更新也不会导致难以追踪的故障。这种方法的代价是一个前提条件：只有平台拥有 API 才能实现。WooCommerce 有 API，如果是其他平台，我会先检查这一点。

What I left with a person This is the part case studies usually skip, and it decides whether the thing is usable:

• Photography. The system processes a photo; it does not take one. A blurred or badly lit photo stays bad. Input quality sets output quality.
• Price and description. For refurbished goods they depend on the condition of that particular unit. That is a commercial decision, so it stays manual.
• Unusual items. Anything that doesn’t fit the pattern is faster to create by hand, and that is fine. Not everything needs to go through the pipeline.

我留给人工处理的部分。这是案例研究通常会忽略的部分，但它决定了系统是否好用：摄影。系统处理照片，但不负责拍摄。模糊或光线不佳的照片处理后依然糟糕，输入质量决定输出质量。价格和描述。对于翻新商品，这些取决于特定设备的状况。这是商业决策，因此保持手动。特殊商品。任何不符合模式的商品手动创建更快，这没问题。并非所有东西都需要通过自动化流程。

The trade-off I want to be upfront about Unlike a workflow where a human approves the result, publishing here is automatic. The product goes live in the shop and the social post goes out without a further approval step. That was the right call for this shop and this kind of work — but it has a direct consequence: because nothing sits between the pipeline and the customer, the quality of the input photos is the only quality gate. If you build something similar for goods where a bad listing is costly, put an approval step before publishing.

我想坦诚说明的权衡：与需要人工审核结果的工作流不同，这里的发布是自动的。产品上线和社交媒体发布都没有额外的审批步骤。对于这家商店和这类工作来说，这是正确的选择，但它有一个直接后果：由于流程与客户之间没有中间环节，输入照片的质量是唯一的质量把关点。如果你为那些糟糕的商品列表会带来高昂成本的业务构建类似系统，请在发布前增加一个审批步骤。

Limits Image-service running costs depend on how many photos you process. It doesn’t write prices or descriptions. It needs an API on the shop side.

限制：图像服务的运行成本取决于处理的照片数量。它不负责编写价格或描述。它需要商店端提供 API。

What I did not measure I don’t quote hours saved as a measured number, because I didn’t measure it, and a figure you can’t verify doesn’t help you decide. What I can say is what changed: instead of a chain of steps per product, one thing remains — upload the photos. The batch of hundreds of products runs unattended, and listing stopped being postponed, so products now reach the shop continuously instead of in occasional pushes.

我没有测量的内容：我没有引用节省了多少小时作为衡量指标，因为我没有测量过，且无法验证的数字对决策没有帮助。我能说的是发生了什么变化：不再是每件产品都要经历一连串步骤，现在只剩下一件事——上传照片。数百件产品的批处理在无人值守的情况下运行，上架工作不再被推迟，因此产品现在是持续进入商店，而不是偶尔集中上架。

The client’s review is published on an independent portal (Jaspravim.sk), not written on my site. The full case page, with the diagram and limits, is here: nexflow.sk/en/case-ecommerce-products. I’m Maksym, an independent automation developer in Banská Bystrica, Slovakia. I build Make.com and n8n workflows and AI agents, and I work in writing only: nexflow.sk. Disclosure: this post was written by an AI assistant (Claude) from my project’s published case notes. The facts come from my own project; the wording is the AI’s.

客户的评价发布在独立门户网站 (Jaspravim.sk) 上，而非我的网站。包含图表和限制的完整案例页面位于：nexflow.sk/en/case-ecommerce-products。我是 Maksym，一名位于斯洛伐克班斯卡-比斯特里察的独立自动化开发者。我构建 Make.com 和 n8n 工作流及 AI 代理，仅通过书面形式工作：nexflow.sk。披露：本文由 AI 助手 (Claude) 根据我项目已发布的案例笔记撰写。事实来自我自己的项目，措辞由 AI 完成。