ProductPromptGenerator(Simple)

The name is a lie in the best way: this node doesn't generate prompts from nothing, it doesn't call an API, and it needs no key and no model files. ProductPromptGenerator(Simple) is a small glue node that takes the JSON-ish output of a vision language model - the README's example is Qwen2.5-VL - and turns it into a structured, ready-to-use prompt for e-commerce display images. Product photo → VLM describes it → this node writes the "put this ring on a model in a jewelry store, don't change the proportions" instruction for you.

That last part is the whole point. The product-photography pipeline the community settled on is: extract the product (BiRefNet/rembg), build a scene, composite, relight. What's tedious about it is writing a prompt that both describes the product and pins down the constraints - relative size, position, face detail - that keep the result usable. This node automates the prompting half for the case where a model is wearing or holding the product. It slots between a VLM node and your text encoder, and it's one of the few places where the VLM's analysis isn't just a caption you read - it's parsed data that changes the generated instruction.

How it works

The mechanism is plain Python, and it's genuinely simple. Three string inputs come in, each expected to hold a JSON object like the ones in the README ({"商品类型": "Ring", "是否支持手持": "No", "推荐背景": "Jewelry Store"}). The node strips markdown code fences, grabs everything between the first { and last }, and parses it. If a parse fails it quietly returns {} - no crash, no error visible to you, just defaults.

Then the interesting bit: it reads a handful of fields and picks an action verb by hard priority. If 是否支持佩戴 (wearable) is "是", you get 佩戴 (wear). Else if 是否支持手持 (handheld) is "是", you get 手持 (hold). Otherwise 使用 (use). Wearable beats handheld, always, and the interaction field only fills in the last clause when it's non-empty.

The inputs and output that matter

All three inputs are STRING, and the source marks them forceInput, so they're meant to be wired in, not typed:

• qwen_output_1 - product type, handheld flag, recommended background.
• qwen_output_2 - the interaction (交互方式, e.g. "wearing on a finger").
• qwen_output_3 - the wearability flag.

That's it. No optional inputs. The single output is prompt (STRING) - wire it into a CLIP Text Encode / conditioning node and you're done. Nothing else comes out.

Installing it

ComfyUI Manager: search ComfyUI-ProductPromptGenerator and hit install. Or by hand:

cd ComfyUI/custom_nodes/
git clone https://github.com/Baldwinzc/ComfyUI-ProductPromptGenerator.git

Restart ComfyUI. That's the entire install - requirements.txt is empty, there are no model downloads, and nothing runs until you feed it. It's about as dependency-free as a custom node gets.

Where people get burned

Three traps, and they're all quiet ones.

The prompt is in Chinese, and it's aimed at a Chinese-capable stack. The output is a natural-language instruction for a model that understands Chinese - think Qwen-Image or the bilingual Z-Image line. Feed it into a Flux or SDXL pipeline with an English T5/CLIP encoder and you're asking the model to parse a language it barely knows. If your generator isn't Chinese-friendly, this node's output is dead on arrival. Check your model before you blame the node.

The field names are hardcoded Chinese keys. The VLM must emit exactly 商品类型, 是否支持手持, 推荐背景, 交互方式, 是否支持佩戴. If your Qwen answers in English or renames a key, parsing silently falls back to defaults (verb becomes "use", product becomes "product") and you get a generic, wrong-ish prompt with zero error. This is the one that'll cost you an hour.

This node never sees the image. It's a pure text transformer - the actual analysis happens in the VLM node upstream (people typically run Qwen2.5-VL through nodes like ComfyUI-QwenVL). Prompt the VLM carefully: whatever it decides about wearability is law, because this node just obeys the flags.

Worth a quick honesty note: whole-frame instruction editing (Qwen-Image-Edit and friends) has eaten a lot of the product-photography job by 2026, and a prompt-only approach like this is a mid-2025-flavored pattern. But if your product's logo, stitching, or geometry must not drift - the thing whole-frame editors can't promise - a hard constraint prompt through a VLM plus masked compositing is still the professional answer. This node is the cheap, no-frills way to automate the prompt half of that.