การตรวจคุณภาพ product content

กำหนด quality contract ก่อนสร้างเนื้อหา

เขียน acceptance rule สำหรับแต่ละ field ฟิลด์ identity และ revision ต้องตรงกับ source ข้อความที่แก้ได้ควรใช้ locale ที่ขอ มีข้อมูลจำเป็น และเคารพ format ของปลายทาง claim ต้องมีหลักฐานรองรับ ป้าย pass หรือ fail เดียวหยาบเกินกว่าจะอธิบายว่าเงื่อนไขใดทำให้สินค้าไม่ผ่าน

แยก defect ที่เครื่องตรวจได้ออกจากการตัดสินใจเชิงบรรณาธิการ ข้อความหายและ identifier drift ตรวจได้แบบ deterministic ส่วนการแปลกล่าวอ้างประโยชน์เกินจริงต้องใช้บริบทและผู้รีวิวที่มีคุณสมบัติ ส่งแต่ละ issue ไปยังบุคคลหรือระบบที่แก้ได้ และผูกผลลัพธ์ไว้กับ candidate revision

เปรียบเทียบ protected value หลังประกอบ record

สร้างเฉพาะ text field ที่อนุญาต แล้วประกอบ candidate record โดยคัดลอก protected value จาก source รันการเปรียบเทียบอีกครั้งบน record ที่ประกอบแล้ว วิธีนี้จับ mapper mistake และการแก้โดยไม่ตั้งใจระหว่าง review ได้

ตัวอย่าง JavaScript ใช้ object ที่ผ่าน schema validation และมี protected value แบบ scalar มันตรวจ protected key ที่หาย เกิน หรือเปลี่ยน รวมถึง source revision ที่ล้าสมัย และคืน issue code ที่เสถียร ให้ทำ schema และ value validation ก่อน helper นี้ แล้วส่ง candidate ที่ถูกต้องเชิงโครงสร้างไป editorial review

function checkProtected(source, candidate) {
  const issues = [];
  if (candidate.sourceRevision !== source.sourceRevision) {
    issues.push({ code: "STALE_SOURCE", field: "sourceRevision" });
  }
  const keys = new Set([
    ...Object.keys(source.protected),
    ...Object.keys(candidate.protected),
  ]);
  for (const field of keys) {
    const hasSource = Object.prototype.hasOwnProperty.call(source.protected, field);
    const hasCandidate = Object.prototype.hasOwnProperty.call(candidate.protected, field);
    if (!hasSource || !hasCandidate ||
        !Object.is(source.protected[field], candidate.protected[field])) {
      issues.push({ code: "PROTECTED_FIELD_CHANGED", field });
    }
  }
  return issues;
}

แยกการจัดรูปแบบตัวเลขออกจากค่าจริง

ตัวเลขที่แปลตาม locale อาจหน้าตาต่างกันแต่แทน quantity ที่เก็บไว้เดียวกัน MDN มีเอกสาร Intl.NumberFormat สำหรับการแสดงผลตาม locale ใช้ formatting หลังเลือก authoritative value แล้ว อย่าให้ language model สร้างราคาจาก currency string ที่แสดงผลใหม่

กำหนด unit ไว้คู่กับ numeric value รวมถึง unit ที่เป็นของแต่ละ dimension หากอนุญาตให้แปลง ให้ใช้ conversion rule แบบ deterministic และเก็บรูปแบบเดิมไว้ อย่าเทียบแค่ตัวเลขในประโยค ตัวเลขเดียวกันที่มี unit ต่างกันอาจอธิบายสินค้าคนละแบบ Unit ที่หายควรหยุดการอนุมัติจนกว่า source จะได้รับการแก้

ตรวจ placeholder multiplicity และ markup

ใช้ template parser ของ application รวบรวม placeholder token จาก source และ candidate เปรียบเทียบจำนวน ไม่ใช่แค่ set ของชื่อ token เพราะ token ที่ซ้ำอาจทำให้ประโยคหรือ application พัง แม้ token เดิมทุกตัวจะยังปรากฏ เก็บกฎการ escape ตาม format ไว้ที่ขอบเขตปลายทาง

check ขนาดเล็กต่อไปนี้รับ token ที่ดึงมาแล้ว ไม่พยายามสร้าง universal placeholder regular expression สำหรับ HTML ให้ parse document fragment แล้วเปรียบเทียบ structure และ link ที่อนุญาตแยกกัน คำแนะนำการ escape ของ WordPress มีประโยชน์สำหรับ custom rendering แต่การ escape อย่างเดียวพิสูจน์ไม่ได้ว่าเนื้อหายังมีความหมายตามตั้งใจ

function samePlaceholderCounts(sourceTokens, candidateTokens) {
  const counts = new Map();
  for (const token of sourceTokens) {
    counts.set(token, (counts.get(token) ?? 0) + 1);
  }
  for (const token of candidateTokens) {
    if (!counts.has(token)) return false;
    counts.set(token, counts.get(token) - 1);
  }
  return [...counts.values()].every((count) => count === 0);
}

เคส: field ถูกต้อง แต่ถ้อยคำยังต้องแก้

translation agent ที่ตั้งค่า gpt-5.6-luna พร้อม xhigh reasoning สร้าง patch ภาษาญี่ปุ่น 20 รายการและภาษาเยอรมัน 20 รายการจากสินค้า synthetic 20 รายการ การตรวจ schema, identity และ protected field แบบ deterministic ผ่านครบทั้ง 40 assembled rows ราคา currency material และ dimensions ถูกคัดลอกจาก source patch ที่สร้างขึ้นเปลี่ยนได้เฉพาะ title และ description ของ SKU กับ locale ที่ระบุ

Japanese patch ที่ยังไม่แตะต้องก็ผ่าน structural validator เช่นกัน แต่ AI review พบ issue เรื่องถ้อยคำ 2 จุดด้านล่างและแก้ description แล้ว นี่คือเหตุผลที่การตรวจ protected material field ไม่อาจยืนยันว่า prose อธิบาย material ได้ถูกต้อง เปรียบเทียบ assertion ที่มีผลทุกข้อกับ source แม้ schema check ทุกตัวจะเป็นสีเขียว

ทดสอบ review export เช่นเดียวกับ import

OWASP อธิบาย spreadsheet formula injection และระบุว่า safety transformation แตกต่างกันตาม consumer ปฏิบัติต่อ cell จาก supplier และ generator เป็น untrusted ใช้ serialization policy ที่ผ่านการรีวิวสำหรับ spreadsheet tool จริง และตรวจ artifact ที่บันทึก ไม่ใช่แค่ table ใน memory

แยก machine import ออกจาก review file prefix ที่เพิ่มเพื่อให้คนดูอย่างปลอดภัยต้องไม่เปลี่ยน identifier หรือ public description เงียบๆ ตอน import ตรวจ encoding, quote handling และ row identity ที่คาดไว้ด้วย parser เก็บ source ที่ไม่แตะต้องไว้ เพื่อระบุและแก้ความเปลี่ยนแปลงที่ spreadsheet editor นำเข้ามาได้

ผูกการอนุมัติกับ candidate ที่แน่นอน

เก็บ candidate revision หรือ hash ไว้กับ factual approval และ language approval การแก้ภายหลังควรทำให้ approval ที่เกี่ยวข้องใช้ไม่ได้จนกว่าจะรีวิวใหม่ publisher สุดท้ายต้องเทียบ source revision ปัจจุบันด้วย เพราะ translation ที่ไม่เปลี่ยนอาจล้าสมัยหลัง product specification เปลี่ยน

ใน case artifact Japanese patch ที่แก้แล้วและ German patch ประกอบเป็น row ที่มี review_status: unreviewed ทั้งสองรายงานเก็บ translation_semantic_review: pending ไว้ การแก้โดย AI เป็น revision step ไม่ใช่การรับรองจาก native speaker หรือ merchant เก็บ candidate เดิมและ candidate ที่แก้แล้ว จากนั้นให้ reviewer ที่เหมาะสมอนุมัติข้อความ exact ที่จะเข้า import package

ทำซ้ำ check และระบุขอบเขตให้ชัด

test ของ local case ตรวจ source-field preservation, duplicate SKU, missing SKU และ forbidden price override การประกอบ Japanese และ German patch ที่บันทึกไว้แบบ read-only ให้ผล validated output ทั้งสองชุดซ้ำได้ สำหรับ catalog ที่ใหญ่ขึ้น ให้เพิ่ม check ตาม placeholder grammar, markup และ revision policy ของคุณ helper ตัวอย่างด้านบนเป็นตัวอย่างแยก ไม่ใช่ validator ที่ใช้กับ 40 row นี้

นี่คือ local translation case ที่ตั้งค่าด้วย Luna ไม่มี Astra หรือ gateway call และไม่มี real store import เครื่องมือไม่เปิดเผย API usage, request ID หรือ billing output ทั้งสองยังเก็บ usage และ cost เป็น null ใช้ผล structural เพื่อไปต่อ semantic review แล้วทดสอบ store adapter ที่ได้รับอนุญาตแยกต่างหาก

node --test examples/commerce-localization-case/case.test.mjs

คำถามที่พบบ่อย