SKU裂变工坊 V3.0

Create all final visuals with an image-generation or image-editing model. Never synthesize final images with Python, PIL, OpenCV, SVG, Canvas, HTML, programmatic text overlays, product duplication, or compositing scripts.

Default SKU canvas and information design

Generate every final SKU image at a 1:1 square aspect ratio unless the user explicitly requests another ratio. When source material is not square, use the image-generation/editing model to adapt it to a square canvas before building the master; preserve the important product, avoid destructive cropping, and create usable information space. Do not use programmatic cropping, padding, or compositing for the final visual.

Make the SKU name and key quantity the largest, clearest text. Use high contrast, generous spacing, and mobile-thumbnail readability. Include:

• exact SKU name and quantity;
• exact label or gift;
• exact product dimensions when provided;
• one or two short, product-relevant selling points;
• simple, restrained ecommerce layout elements that improve hierarchy.

Before approval, inspect the image at thumbnail scale. The SKU name and the defining differences for that category—such as quantity, model, color, size/capacity, package form, included items, interface, or gift—must remain readable without zooming. Enlarge or simplify the layout when they do not.

Do not invent technical claims, certifications, performance numbers, medical claims, or gifts. Derive ordinary descriptive selling points from visible product properties and user-provided facts; keep them short. Keep typography, placement, palette, badges, and selling-point structure consistent across children of the same master.

Adapt copy by SKU while inheriting the layout

Treat the master as a stable visual system, not a requirement that every child repeat identical copy. For each SKU, allow these information fields to change together when supported by that SKU's data:

• SKU title, quantity, size type, and dimensions;
• gift or promotional badge;
• one or two short selling points;
• emphasis order among quantity, gift, size, and selling points.

Keep the information slots, overall hierarchy, typography family, palette, icon language, margins, and product presentation consistent. Resize text or make small within-slot adjustments only when needed to fit accurate copy.

Choose SKU-specific copy by priority:

1. Use the user's exact gift, label, size, and claims verbatim.
2. Emphasize the defining difference of that SKU, such as trial quantity, larger quantity, included gift, or larger physical specification.
3. Use visible, non-quantified product attributes as secondary selling points only when needed.
4. Never infer a gift from another SKU, copy a small-size dimension into a large-size SKU, or reuse a claim that conflicts with the current SKU.

Examples of safe differentiation include 试用装/少量体验, 加量装/囤货更省, 赠硝化细菌 when explicitly supplied, or 加大规格 when supported by dimensions. Treat these as patterns, not mandatory wording.

Use the four-level hierarchy

Always model:

project -> master_group -> base_visual -> master_template -> sku_variant

Distinguish:

• source_image: the user-uploaded original.
• base_visual: the approved underlying product scene, either preserved or transformed.
• master_template: the approved complete ecommerce layout built on one base visual.
• sku_variant: a child edit derived from exactly one approved master.

Never treat the base visual and master as the same object. Never create an SKU without master_group_id and master_id.

When any visible SKU fact differs, use master_per_sku or separate master groups. This includes product identity, model, count, color, visible size/capacity, form, package type, components, accessories, gifts, interfaces, or arrangement. Visual similarity alone never justifies sharing one base or master.

Classify copy changes versus structural changes

Classify every planned SKU difference before choosing a parent master. Apply this rule to every product category, not only electronics:

• copy_only: the current pixels already truthfully show every visible fact stated or implied by the new copy. Only non-visual information such as title phrasing, approved selling points, price/promotion, or a label changes. Edit it in sku_variant.
• structural: the new copy requires any product-region pixel to change. This includes identity/model, count, color/material/finish, visible size or capacity, shape, package/container type, pack form, included components, accessory/gift composition, interface, open/closed state, assembly state, or object arrangement. Create a new base_visual, then a new sibling master_template.

Do not decide from wording alone. Parse the SKU copy into a visual_fact_contract, compare it with the approved parent's visual_fact_contract, and use source evidence to determine whether each differing fact is visibly represented. If evidence is missing or contradictory, mark the SKU needs_user_confirmation; never assume that text-only editing is safe.

Examples of structural changes include 1件 -> 2件, 单瓶 -> 组合装, 500ml -> 1L when the container differs, 黑色 -> 白色, 短款 -> 长款, S码 -> XL码 when visible proportions differ, 裸机 -> 含配件, 袋装 -> 盒装, and 一拖一 -> 一拖二 -> 一拖三. Regenerate the product zone with the exact structure and a composition appropriate to the copy. Rebalance scale, spacing, negative space, and information placement.

Organize related structural masters as siblings in one visual style family. Inherit typography family, palette, badges, icon language, margins, module order, and brand direction across the family, but bind each sibling to its own base, visible count, arrangement, master lock, and child IDs.

Never duplicate products programmatically or change only text when the stated SKU requires different pixels. Never use any parent whose product scene contradicts the SKU copy, even if its layout and style are suitable.

Confirm three decisions before generation

Skip only decisions the user already specified.

1. Ask for base_strategy:
   - original_preserve: retain product, background, composition, lighting, quantity, placement, crop, and scene; add information only inside specified mask regions.
   - img2img_transform: redesign background, composition, layout, and scene while locking product identity, silhouette, material, color, structure, texture, proportions, brand, and packaging.
   - mixed: choose either mode per master group.
2. Ask for master_topology:
   - single_master: one approved master supplies all variants.
   - master_per_sku: approve and lock a separate master per SKU.
   - grouped_multi_master: create multiple groups, each with its own base, master, and children.
3. Ask for inheritance_mode:
   - strict: preserve the visual slots and layout while allowing specified title, quantity, dimensions, gift, badges, and SKU-specific selling points to change.
   - semi_strict: additionally allow local typography, badge colors, and small information-position changes.
   - style_inherit: preserve product and brand direction while allowing visible layout and color-ratio changes.

Use prompts/02-confirm-project-structure.md for the exact confirmation pattern. Then output a group plan with counts and expected outputs and wait for approval.

Treat explicit original-only wording as a complete decision

When the user says, in substance, “use the current/original image, only add the corresponding SKU name and label, and do not modify the base image” (当前原图，仅增加对应 SKU 名称和标签，不修改底稿内容), record all three decisions without asking again:

• base_strategy: original_preserve
• master_topology: single_master
• inheritance_mode: strict

Treat the supplied original as the approved base and the unchanged visual foundation for the single master. Generate one child per supplied SKU with an image-generation/editing model. Change only approved information fields; lock product, background, composition, lighting, quantity shown in the photograph, placement, texture, color, and every other original-image element. If the required output is 1:1 and the source is not square, allow only the minimum model-driven reframing or canvas extension needed to reach 1:1 while preserving the full product presentation. Follow the current user's supplied requirements for dimensions, selling points, and simple layout; do not invent unsupported claims or gifts. Keep text placement and styling consistent across the full set.

Execute in approval gates

1. Inventory every source and assign exactly one role per use: product identity, appearance, physical specification, package/component structure, accessory/gift, claim evidence, or layout/style only. Add category-specific roles only when needed.
2. Build the expected SKU matrix before generation. Derive category-relevant dimensions from the supplied SKU data, create a visual_fact_contract for each cell, and classify each difference as copy_only, structural, or needs_user_confirmation.
3. Analyze inputs and extract every SKU without inventing unsupported matrix cells.
4. Build a source-to-SKU binding card and claim-evidence registry for every expected SKU.
5. Confirm the three decisions and present expected counts per matrix cell.
6. Wait for plan approval unless the user explicitly authorizes direct full-SKU generation.
7. Split every unique visible structure into its own base/master sibling before generation. Multiple SKUs may share that sibling only when their visual fact contracts are equivalent. Process one master group at a time; direct generation waives preview pauses only, never binding, evidence, structural classification, self-check, or completeness checks.
8. Generate or preserve the base visual and run the base self-check against its binding card.
9. Generate the visual master, create the master lock, and generate only its bound variants.
10. Run the mandatory visual and thumbnail-readability checks on every result; repair or regenerate every failure.
11. Compare expected versus passing SKU matrix cells and generate every supported omission.
12. Audit the final directory; output only current passing files and the relationship/completeness report.

Never generate child variants before their base and master are approved. When multiple bases require approval, obtain approval for each, not only the first.

Require a source-to-SKU binding card

Before generating any base, master, or variant, record one binding card with:

• SKU ID and exact display name;
• allowed source image IDs and the role of each source;
• exact primary-product, secondary-object, component, accessory, and gift counts;
• appearance, visible physical specification, package/container form, configuration, and arrangement;
• any category-specific structure such as interfaces, case topology, garment pieces, closures, applicators, attachments, or flavor markers;
• product identity locks: silhouette, proportions, screen, buttons, grilles, ports, clips, seams, and materials;
• approved claims and the evidence source for each claim;
• forbidden objects, interfaces, gifts, claims, and cross-SKU sources.

Also record a category-neutral visual_fact_contract: product identity/model; primary and secondary object counts; color/material/finish; visible dimensions/capacity/form; package/container type; included components; accessories/gifts; state or configuration; arrangement constraints; and any category-specific visible attributes. Use not_applicable for irrelevant fields and unknown only when the SKU must pause for confirmation.

Assign an image role for each use. An accessory/gift source may supply that object's identity but not the primary product. A layout reference may supply composition but not products, copy, claims, specifications, or included items. A component or package source may supply structure only when it matches the exact SKU configuration.

Treat the binding card as a hard generation contract. Never infer any model, appearance, quantity, physical specification, package form, component, accessory/gift, configuration, or arrangement from a different SKU. When a required field is uncertain, stop that SKU and request confirmation instead of generating it.

Bind claims to evidence

Create a claim-evidence registry per SKU. Use a selling point only when the user supplied it or a source for the same product family directly supports it. Record conflicting values such as distance, duration, capacity, or signal-to-noise ratio as blocked claims and omit them until confirmed. Prefer visible hardware facts over performance claims. Never transfer a claim merely because another SKU looks similar.

Propagate user corrections

Treat any correction to a visual fact, source mapping, or claim as a binding-card revision. Identify every dependent base, master, variant, prompt, label, and report entry. Mark all affected outputs obsolete before regeneration. A correction that changes required pixels requires product regeneration from correct sources; changing only the text is forbidden.

Examples:

• moving C转苹果接口 from an Apple bundle to a Type-C bundle invalidates both affected product images;
• changing 挂绳 to 收纳袋 invalidates every SKU image and gift line containing the old gift;
• discovering that one-to-one uses a compact two-bay case invalidates any one-to-one image built from a one-to-two case.

Run mandatory visual self-checks

Inspect every generated image against its own source images, binding card, approved base, and master before saving it as final. Use visual inspection at sufficient detail; filenames and prompt intent are not evidence that the pixels are correct.

Apply hard-fail checks first:

• wrong source product or cross-SKU contamination;
• wrong product identity, model, appearance, visible specification, package form, configuration, or arrangement;
• wrong primary-product, secondary-object, component, accessory, or gift count;
• wrong category-specific structure such as interface, case, closure, applicator, attachment, garment piece, or bundle ownership;
• missing, substituted, duplicated, or invented gifts;
• changed product category, silhouette, screen, grille, button, port, clip, or major seam;
• obvious stretching, squashing, warped straight edges, fused objects, impossible overlaps, malformed connectors, or inconsistent perspective;
• text that conflicts with the visible product or binding card.

Any hard failure makes the image ineligible for delivery regardless of its numeric score. Move or label the failed file as obsolete/rejected, regenerate from the correct sources, and re-run the full check. Do not repair a wrong product mapping with text-only editing.

After hard-fail checks pass, score consistency and quality using references/visual-self-check.md and references/retry-strategy.md. Require at least 90/100. Record the check result, detected issues, repair action, and final status in the relationship report.

Audit matrix completeness and delivery

Before final delivery, compare the approved expected SKU matrix with passing output files. Report expected, passing, rejected, obsolete, unsupported, and missing cells. Generate every supported missing cell. Do not silently invent unsupported cells such as a dual-interface one-to-one SKU without evidence.

Keep final or sku_variants directories clean: only current passing outputs may remain there. Move wrong mappings, superseded versions, failed checks, and rejected generations to obsolete or rejected with a reason. Never count or link those files as deliverables.

Enforce base modes

For original_preserve, prefer masked/local editing. Do not claim pixel preservation from ordinary full-image img2img. If masked editing is unavailable, say: “纯模型编辑无法保证原稿完全不发生像素变化，建议使用支持蒙版编辑的图像模型。”

For img2img_transform, generate a text-free base with reserved information space first. Preserve product identity and obtain user approval before master generation.

For mixed, record base_mode independently in every group.

Lock approved masters

Record approved status, locked elements, editable elements, inheritance mode, and child IDs. Never borrow a base, product, or layout from another group.

Read these resources when applicable:

• references/master-hierarchy.md: hierarchy, topology, approvals, and relationship report.
• references/structural-variation.md: apply the universal copy-to-pixel decision and decide when any SKU fact requires a new base and sibling master.
• references/template-lock-rules.md: exact inheritance locks.
• references/product-consistency-rules.md: product identity rules.
• references/visual-self-check.md: mandatory binding, deformation, count, interface, gift, and text checks.
• references/batch-integrity.md: source roles, correction propagation, expected-versus-actual matrix audit, and clean delivery rules.
• references/model-only-workflow.md: model-only execution constraints.
• references/retry-strategy.md: scoring and repairs.

Use schemas in schemas/ as the canonical project and task contracts and prompts in prompts/ for each stage.