SKU.md v0.9: การทำงานร่วมกัน ขอบเขตความสอดคล้อง และการใช้งานอย่างปลอดภัย

SKU.md v0.9 เป็นรุ่นที่เน้นการทำงานร่วมกันและความสม่ำเสมอ ไม่ได้เพิ่มฟิลด์เฉพาะ Shopify คะแนนจัดอันดับ หรือระบบ Checkout ชุดที่สอง แต่กำหนดว่าผู้เผยแพร่จะระบุสิ่งที่ตรวจแล้วอย่างไร ผู้บริโภคจะตีความหลักฐานนั้นอย่างไร และทั้งสองฝ่ายต้องกลับไปหาระบบการค้าแบบเรียลไทม์ที่จุดใด

รูปแบบข้อมูลไม่เปลี่ยนแปลง

Schema v0.9 ยังคงประเภทเอกสาร Profile ฟิลด์ คุณสมบัติที่บังคับ ค่าแจกแจง กฎส่วนขยาย และขอบเขตความปลอดภัยของ v0.8 ดังนั้นการโยกย้ายในชั้นข้อมูลจึงตั้งใจให้มีขนาดเล็ก

1. เปลี่ยน schema_version เป็น sku.md/0.9-draft
2. เปลี่ยน Schema URL เป็น https://sku.md/schema/sku-md/0.9/schema.json
3. รันการตรวจที่จำเป็นทั้งหมดสำหรับขอบเขตความสอดคล้องที่ต้องการประกาศ

ผู้บริโภคยังอ่านเอกสาร v0.8 เพื่อความเข้ากันได้ แต่ห้ามระบุว่าเอกสารนั้นสอดคล้องกับ v0.9 ตัวระบุเวอร์ชันและหลักฐานความสอดคล้องเป็นคนละคำกล่าวอ้าง

ข้อกำหนด v0.9 ภาษาอังกฤษฉบับเต็มเป็นข้อความเชิงบรรทัดฐานเพียงฉบับเดียว JSON Schema ของ v0.9 ที่เผยแพร่สู่สาธารณะใช้ตรวจโครงสร้าง แต่ไม่ใช่คำตัดสินความสอดคล้องที่สมบูรณ์ด้วยตัวเอง

ขอบเขตความสอดคล้องสามแบบ

v0.9 ระบุสิ่งที่ตัวตรวจสอบตรวจจริง

ขอบเขต	สิ่งที่ยืนยันได้	สิ่งที่ยืนยันไม่ได้
offline_document	ฟรอนต์แมตเทอร์และ YAML ที่ปลอดภัย, Schema, ความหมายของเอกสารเดียว และความตรงกันของ Markdown	การส่ง HTTP การเข้าถึงทรัพยากร หรือความสมบูรณ์ของกราฟเอกสารแม่
published_resource	URL จริงหนึ่งรายการ รวมสถานะ HTTP การเปลี่ยนเส้นทาง MIME, URL หลัก การตอบกลับทดแทนที่ดูเหมือนสำเร็จ และการเข้าถึง	ความสม่ำเสมอของเอกสารทั้งชุด
document_graph	สายเอกสารแม่ รูปแบบการนำเสนอ Profile ภายนอก ทรัพยากรที่อ้างถึง และความสม่ำเสมอข้ามเอกสาร	สิทธิ์ซื้อ ชำระเงิน หรือเปลี่ยนสถานะการค้า

รายงานบันทึกการตรวจไวยากรณ์ Schema ความหมาย และการตรวจออนไลน์เป็นคนละชั้น หากการตรวจบังคับล้มเหลว ผลรวมคือ failed หากยังไม่ได้รันการตรวจบังคับและไม่มีรายการใดล้มเหลว ผลคือ incomplete ไม่ใช่ passed

รายงานการตรวจสอบที่นำไปใช้ข้ามเครื่องมือได้

รายงานเป็นหลักฐานเกี่ยวกับเอกสาร ไม่ใช่ส่วนหนึ่งของฟรอนต์แมตเทอร์ SKU-MD สำหรับเอกสารรากที่สร้างสำเร็จ อาจมีรูปแบบดังนี้

{
  "spec_version": "sku.md/0.9-draft",
  "validator": { "name": "sku-md-generator", "version": "0.2.0" },
  "target": {
    "url": "https://example.com/sku.md",
    "document_type": "catalog_manifest"
  },
  "scope": "offline_document",
  "status": "passed",
  "checked_at": "2026-08-01T00:00:00Z",
  "layers": {
    "syntax": "passed",
    "schema": "passed",
    "semantics": "passed",
    "online": "not_applicable"
  },
  "issues": []
}

รหัสปัญหาที่เสถียรช่วยให้เครื่องมือต่าง ๆ ใช้ผลร่วมกันได้ เช่น YAML_DUPLICATE_KEY, SCHEMA_VALIDATION_FAILED, CANONICAL_MISMATCH, GTIN_CHECK_DIGIT_INVALID, KNOWLEDGE_DYNAMIC_STATE_FORBIDDEN และ BODY_PARITY_INVALID ห้ามแปลงการหมดเวลาของเครือข่ายให้เป็นผลสำเร็จ

ตัวสร้างของเว็บไซต์สร้างเฉพาะรายงาน offline_document หลังอัปโหลด ผู้เผยแพร่ยังต้องตรวจสถานะ HTTP, text/markdown, การตอบกลับทดแทนที่ดูเหมือนสำเร็จ, URL หลัก ลิงก์เอกสารแม่ รูปแบบการนำเสนอ และการอ้างอิง Profile ภายนอกทางออนไลน์

พฤติกรรมของ Reference Consumer

Reference Consumer เป็นสัญญาพฤติกรรมสำหรับผู้อ่าน ไม่ใช่รูปแบบข้อมูลใหม่ ลำดับที่ปลอดภัยคือ

1. ค้นหารากที่ผู้ขายโฮสต์และตรวจต้นทางกับรูปแบบการนำเสนอ
2. ตามจุดเข้า Catalog และพาร์ทิชันที่ประกาศไว้โดยไม่เดาสินค้าที่ซ่อนอยู่
3. เลือก Variant ที่ตรงด้วยตัวระบุที่เสถียร ตัวเลือก ตลาด ภาษา และ URL หลักของ Variant
4. แยกข้อเท็จจริง คำกล่าวอ้าง ข้อมูลเปิดเผย คำแนะนำ ข้อจำกัด ความเข้ากันได้ URL แหล่งที่มา และวันที่ตรวจสอบ
5. ถือ offer_snapshot เป็นสิ่งที่สังเกต และใช้ live_lookup หรือ live_verification สำหรับราคา ความพร้อมจำหน่าย ค่าขนส่ง ภาษี และยอดรวมปัจจุบัน
6. ส่ง Cart, Checkout การชำระเงิน และ Order กลับไปยังระบบเรียลไทม์ที่มีอำนาจตามที่ประกาศ พร้อมการยืนยันอย่างชัดเจนจากผู้ใช้

เมื่อการระบุตัวตน หลักฐาน ความเป็นปัจจุบัน หรืออำนาจไม่เพียงพอ ผู้บริโภคต้องหยุดอย่างปลอดภัยแทนการเติมช่องว่างด้วยการอนุมานของโมเดล

การกำกับแหล่งข้อมูลอยู่ในชั้นเครื่องมือ

ผู้เผยแพร่ต้องเก็บสถานะบางอย่างที่ไม่ควรส่งให้ผู้บริโภค Source Map ส่วนตัวบันทึกที่มาของแต่ละค่าและสถานะ Detected, Derived หรือ Verified ได้ ขั้นตอน Audit–Plan–Apply จึงเปรียบเทียบ HTML, Product JSON-LD, Merchant Feed, Catalog ของแพลตฟอร์ม และ SKU-MD เดิม เตรียมความแตกต่างให้ตรวจสอบ และเผยแพร่หลังมนุษย์ยืนยันเท่านั้น

Source Map บันทึกการทบทวน สถานะร่าง ความแตกต่างของรุ่น บันทึกปัญหา และตัวชี้วัดช่องทางไม่เข้าสู่ Schema สาธารณะ หากการสร้างใหม่แบบเพิ่มเฉพาะส่วนหรือการตรวจออนไลน์ล้มเหลว ระบบส่งมอบควรเก็บเวอร์ชันที่ถูกต้องล่าสุดแทนการแทนที่ด้วยผลลัพธ์ที่ไม่สมบูรณ์

ร่วมมือกับแพลตฟอร์ม ไม่ใช่ทำซ้ำ

SKU-MD ควรอธิบาย Knowledge ที่เสถียรและขอบเขตแหล่งข้อมูลอย่างชัดเจน Catalog ของแพลตฟอร์มยังคงมีอำนาจเหนือการกระจาย ราคา และสินค้าคงคลังปัจจุบัน API แบบเรียลไทม์หรือ UCP/MCP จัดการคำขอปัจจุบัน และ Checkout รับผิดชอบการยืนยันผู้ซื้อ ยอดรวม การชำระเงิน และการสร้าง Order

ณ 2026-08-01 Shopify มีเอกสาร Shopify Catalog และส่วนติดต่อ Catalog, Cart, Checkout, Order ที่เข้ากันได้กับ UCP แต่ไม่ได้ระบุว่าระบบเหล่านั้น ChatGPT หรือช่องทาง Shopify อื่นจะอ่านหรือเชื่อถือ SKU-MD คำแนะนำการเชื่อมต่อจึงใช้ตัวชี้และขอบเขตอำนาจ โดยไม่คัดลอกสถานะการชำระเงินหรือ Order

วัด SEO, GEO และ AEO โดยไม่รับประกันผล

คำถามที่มีประโยชน์ไม่ใช่ว่าไฟล์คงที่ “เพิ่มอันดับ AI” หรือไม่ แต่การทดลองแบบควบคุมวัดสิ่งต่อไปนี้ได้

• ความแม่นยำในการระบุ Variant ที่ตรง
• การอ้างข้อเท็จจริงที่มีแหล่งที่มาแทนข้อความส่งเสริมการขาย
• การนำข้อมูลเปิดเผยและข้อจำกัดกลับมาใช้
• การตรวจสอบแบบเรียลไทม์ก่อนตอบข้อมูลที่ไวต่อเวลา
• ความสอดคล้องระหว่าง HTML, Product JSON-LD, Merchant Feed, Catalog ของแพลตฟอร์ม และ SKU-MD

ตัวชี้วัดเหล่านี้แสดงได้ว่าสัญญาการเผยแพร่ลดความกำกวมและคำตอบล้าสมัยหรือไม่ แต่ไม่พิสูจน์ว่าตัวเก็บข้อมูลจะดึงเอกสาร หรือแพลตฟอร์มจะจัดอันดับ อ้างอิง แนะนำ หรือทำให้เกิดยอดซื้อสินค้า

ลำดับการโยกย้ายที่ใช้ได้จริง

เริ่มด้วยการปรับตัวระบุเวอร์ชันและสร้างรายงานออฟไลน์ เผยแพร่หลังมนุษย์ตรวจทานเท่านั้น จากนั้นตรวจทรัพยากรออนไลน์และกราฟเอกสาร เก็บสถานะการค้าที่เปลี่ยนแปลงไว้นอก Knowledge รักษาฉบับแก้ไขที่ถูกต้องล่าสุดเมื่อระบบอัตโนมัติล้มเหลว และเปรียบเทียบผลด้วยการทดสอบแบบควบคุมแทนคำกล่าวอ้างเรื่องการนำไปใช้ที่ไม่มีหลักฐาน

อ่านเพิ่มเติม

นำข้อกำหนดไปใช้จริงด้วยคู่มือ เผยแพร่ SKU.md ฉบับแรก