AI E-commerce automation พร้อม review gates
Updated 2026-09-05
เปลี่ยน product changes เป็น drafting jobs ที่ติดตามได้ แยก generation, validation, approval และ store updates เพื่อเข้าใจและทำงานต่อจาก run ที่ fail ได้
ทำให้ handoff อัตโนมัติ ไม่ใช่แค่ prompt
content workflow ที่ทำซ้ำได้ต้องตอบว่าสินค้าใดเปลี่ยน ใช้ source revision ใด งานอะไรเหลือ และใครมีสิทธิ์ publish prompt ที่ตั้งเวลาไว้พร้อม CSV attachment ตอบเองไม่ได้ ให้ถือ prompt เป็นขั้นตอนหนึ่งของ job ที่เก็บ state นอก conversation
เริ่มจาก content ที่ export ได้และ offline review queue ให้ job ทุกตัวมี durable record และ next action ที่ชัด ปิด live product updates จนกว่าจะทดสอบ destination adapter และ approval checks ใน store ที่ควบคุม วิธีนี้สร้าง generation และ review ก่อนเพิ่ม publication permissions

ให้ job แต่ละตัวมี identity ที่เสถียร
ใช้ source revision, product identifier, locale, glossary revision และ prompt revision ระบุงานที่ตั้งใจ retry job เดิมต้องไม่สร้าง candidate ที่ไม่เกี่ยวหรือ import เดิมซ้ำ การเปลี่ยน source หรือ rules ต้องสร้างงานใหม่ที่มีความสัมพันธ์กับ candidate เก่าให้เห็น
อย่าใช้ row number เป็น key เพราะการ sort export เปลี่ยนตำแหน่ง row เก็บ prices และ units ใน source snapshot แต่อนุญาต generated output เฉพาะ approved text fields record ต่อไปนี้เป็น application contract ตัวอย่างสำหรับปรับใช้กับ job store
{
"productId": "SYNTHETIC-CATALOG-A",
"locale": "de",
"sourceRevision": "source-revision-required",
"glossaryRevision": "glossary-revision-required",
"promptRevision": "prompt-revision-required",
"state": "queued",
"approval": null,
"importReceipt": null
}Persist observable state transitions ของ job
เก็บ candidate output ก่อนเลื่อนไป validation เก็บ validation issues ก่อน assign reviewer ผูก approval กับ candidate และ source revisions ที่ตรงตัว publisher ควรปฏิเสธ record ที่ content เปลี่ยนหลัง approval แม้ version ก่อนหน้าจะ accepted
ใช้ hold state กับผลลัพธ์กำกวม ตัวอย่างเช่น connection loss ระหว่าง import ไม่ได้พิสูจน์ว่า store ปฏิเสธ write กระทบยอด current stored fields ก่อน retry ใช้ states ที่เสนอต่อไปใน orchestration layer พร้อม transition checks ข้าง operation ที่ persist result แต่ละอย่าง
| Transition | หลักฐานที่ต้องมี | เมื่อใดต้อง hold |
|---|---|---|
| Queued ไป drafted | Saved candidate และ request identity | Output หายหรือไม่สมบูรณ์ |
| Drafted ไป reviewable | Structured field checks ของ output | Protected-field drift ที่ต้อง hold |
| Reviewable ไป approved | Reviewer และ candidate revision | Factual issue ที่ยังไม่แก้ |
| Approved ไป imported | Authorized patch และ store receipt | Source เก่าหรือ write ไม่แน่นอน |
| Imported ไป verified | Stored-field comparison หลัง import | Field difference ที่ไม่คาดคิด |
แยก model client จาก store adapter
ให้ drafting worker เฉพาะ approved source subset และ model credentials เก็บ store credentials ใน adapter แยกที่มี operation แคบ เช่นเตรียม description patch AI request ที่สำเร็จไม่ควร publish สินค้าเป็น side effect
translation path ของ Shopify ใช้ resource-specific content และ digests ส่วน WooCommerce มี product CSV importer ตามเอกสาร ให้ interface แต่ละแบบมี mapper และ verification step ของตัวเอง ตั้ง model credentials ใน drafting client และเก็บ source reads กับ authorized store writes ใน destination adapter ทดสอบ boundaries แยกก่อนรวม flow
จำกัด retry และแยก record ที่มีปัญหา
retry temporary transport failures ด้วย policy ที่สิ้นสุดและบันทึก attempts การทำ response ที่ structurally invalid ซ้ำโดยไม่เปลี่ยนสาเหตุอาจเสียทั้ง usage และเวลา reviewer แยกหมวด failure: authentication, unavailable model, incomplete generation, invalid fields และ rejected content ต้องใช้ interventions ต่างกัน
ปล่อย successful records ให้ใช้ได้ขณะ hold failed records เก็บ attempts ทั้งหมดของสินค้าที่ได้รับผล รวม candidate ที่ validation fail worker restart ควร resume จาก persisted state ไม่ใช่ regenerate catalog ทั้งหมด ทดสอบ cancellation ด้วย การหยุด generation ต้องไม่ทิ้ง import process ให้รันต่อแบบเงียบๆ
วัดงานที่ accepted และ cost ทั้งหมด
ผูก usage records กับ job และ attempt รวม failed requests เมื่อมี billing evidence ติดตาม drafting, review และ revision calls แยกกัน เก็บ missing usage เป็น unknown receipt ที่หายไม่ใช่ free request แยก editor time จาก API ledger แทนการผสมค่าที่วัดต่างกันเป็นตัวเลขเดียว
กำหนด accepted work ตาม release criteria เช่น approved product-locale revision แบ่ง recorded costs ด้วย accepted work เมื่อ denominator ไม่เป็นศูนย์และ sample มีขอบเขตชัด ใช้ provider หรือ gateway billing information ปัจจุบัน และเก็บวันที่กับ billing source ใน report
กระทบยอด import และเตรียม reversal
สร้าง import proposal ที่มีเฉพาะ approved changes และเก็บ previous values ของ fields เหล่านั้น เปรียบเทียบ source revision อีกครั้งทันทีก่อน authorized write หาก editor อื่นเปลี่ยนสินค้า ให้หยุดและขอ review ใหม่แทนการเขียนทับ
หลัง import ให้อ่าน fields ที่ตั้งใจกลับและจัดหมวด mismatches ตาม product กับ locale reversal ควรคืนเฉพาะ changes ของ batch นี้เมื่อ store ยังตรง imported revision มิฉะนั้นต้อง conflict review แยก import permissions จาก permission ในการสร้าง text
ตรวจ flow เล็กๆ ที่รวม failure
ใช้ synthetic products ทดสอบ candidate ที่ accepted หนึ่งรายการ protected-field violation หนึ่งรายการ และ changed-source conflict หนึ่งรายการ restart worker ระหว่าง drafting กับ approval ตรวจ approved work ว่าอยู่ต่อและ held work เข้า import proposal ไม่ได้ checks เหล่านี้ทดสอบ state contract โดยตรงกว่าการทดสอบถ้อยคำ prompt ซ้ำ
จากนั้นทดสอบ adapter ใน staging store ด้วย permission ที่ชัด เก็บ source snapshot, generated revision, approval, import receipt และ read-back comparison local job simulation ยืนยันได้เฉพาะ orchestration behavior ไม่ได้ยืนยัน model quality หรือ store integration ที่สำเร็จ
คำถามที่พบบ่อย
workflow นี้รันตาม schedule ได้หรือไม่?
ได้ในฐานะ design choice เมื่อ job รู้ revision และ persist แล้ว scheduling ควร enqueue งานที่มีสิทธิ์ ไม่ควรข้าม validation หรือให้ publishing permission อัตโนมัติ
ถ้า source เปลี่ยนระหว่าง review จะเกิดอะไร?
ทำเครื่องหมาย candidate ว่า stale และเปรียบเทียบ fields ที่เปลี่ยน ต้อง approval กับ source revision ใหม่ก่อนเตรียม import
failed rows ควรหยุด catalog ทั้งหมดหรือไม่?
ไม่จำเป็น Hold records ที่ได้รับผลแต่เก็บ successful drafts ไว้ และ block batch เมื่อ shared failure เช่น glossary ผิดอาจกระทบทุก record
ควร retry store writes ที่ไม่แน่นอนอย่างไร?
อ่าน targeted fields กลับก่อน กระทบยอดว่าเกิดอะไร แล้ว retry เฉพาะ approved patch ที่ยังค้าง อย่าคิดว่า timeout หมายถึงไม่มี write
ควร implement components ใดก่อน?
เริ่มด้วย source snapshots, persistent jobs และ review queue ต่อด้วย model client แล้ว implement และ test destination adapter ก่อนเปิด authorized imports