บทความนี้อธิบายว่าบรรณาธิการ AI มองหาอะไรตอนเขียน แก้ หรือตรวจบทความ ให้ความสำคัญกับอะไรก่อน และทำอย่างไรให้ทั้งหลักฐานที่หนักแน่นกับความสนุกอยู่ร่วมกันได้ ตามกฎคุณภาพบทความ v5 ที่ใช้อยู่ตอนนี้
ไม่มีข้อมูลที่ระบุตัวบุคคลได้ รายละเอียดชีวิตส่วนตัว สถานที่ทำงาน ที่อยู่ และข้อมูลบัญชีถูกเขียนให้เป็นภาพรวมทั้งหมดแล้ว
คำตอบใน 5 วินาที: ดู 8 ชั้นตอนเขียนบทความ
บรรณาธิการ AI มองหาข้อมูลจากประมาณ 8 ชั้นดังนี้
- คำสั่งงานครั้งนี้ — จะทำอะไร และจะไม่ทำอะไร
- ความจำและเซสชันที่ผ่านมา — สไตล์การเขียน กฎคุณภาพ ข้อยกเว้นที่เคยตัดสินใจไว้
- main ล่าสุดบน GitHub — ข้อตกลง "ยุคคุณภาพ" (quality epoch) กฎการแก้ไข และการตรวจคุณภาพที่ใช้อยู่ตอนนี้
- บทความต้นฉบับและเอกสารต้นทาง — "พื้นดินที่ห้ามทำพัง" ได้แก่ ตัวเลข วันที่ คำอ้างอิง ชื่อเฉพาะ และความไม่แน่นอน
- แหล่งข้อมูลหลัก แหล่งทางการ และงานวิจัยบนเว็บ — ความทันสมัย ระเบียบ ข้อกำหนด งานวิจัย และหลักฐานที่ค้านได้
- ตัวบทความเอง — ความต้องการของผู้อ่าน มุมที่เลือกเล่า โครงสร้าง ข้ออ้างกับหลักฐาน มุกตลก ความเป็นธรรมชาติ
- ฉบับ 12 ภาษา — ปรับที่แนวคิดไม่ใช่แค่คำ และเก็บชื่อที่ต้องแม่นยำไว้ตามเดิม
- เว็บไซต์จริง ข้อมูลจริง และหลักฐานจากการตรวจคุณภาพ — มือถือ การซูม ข้อความยาว ลิงก์ ตาราง ไปจนถึงตอนเกิดข้อผิดพลาด
พูดง่าย ๆ คือ ไม่ใช่ "อ่านคู่มือของ Google แล้วเขียนไปเรื่อย ๆ" ถ้าดูแต่ Google วิญญาณพนักงาน Google จะเข้าสิง ถ้าดูแต่ Microsoft คู่มือก็จะเริ่มออกลูกเป็นคู่มือเล่มใหม่ สิ่งที่โรงงานบทความต้องการคือวิจารณญาณของบรรณาธิการที่เชื่อมแหล่งข้อมูลแข็งแรงหลายแหล่งเข้ากับจุดประสงค์ของบทความชิ้นนั้น
1. อย่างแรกที่ดูคือ "ออเดอร์ครั้งนี้"
สิ่งสำคัญที่สุดคือคำสั่งของผู้ใช้ในตอนนี้
มีเงื่อนไขที่ใช้แค่ครั้งนี้ เช่น "ให้ครบถ้วน" "ให้สั้น" "ใส่มุกเยอะ ๆ" "อิงงานวิจัย" "ไม่ใช้รูป" "12 ภาษา" "ตัดข้อมูลส่วนบุคคลออก" เทมเพลตเก่าจะดูดีแค่ไหน ถ้าลูกค้าสั่งราเมงแล้วเราเสิร์ฟแกงกะหรี่ ก็เป็นอุบัติเหตุธรรมดา ๆ
ตรงนี้จะตัดสินใจ 5 เรื่องหลัก ๆ
- บทความนี้เขียนให้ใคร
- ผู้อ่านสงสัยอะไร
- อ่านจบแล้วอยากให้เข้าใจหรือทำอะไรได้
- ต้องค้นคว้าลึกแค่ไหน
- ข้อห้าม รูปแบบ และน้ำเสียงที่ใช้เฉพาะครั้งนี้
ในขั้นนี้จะกำหนด "Reader Need" (สิ่งที่ผู้อ่านต้องการ) และ "Reader Outcome" (สิ่งที่ผู้อ่านได้หลังอ่านจบ) ของบทความ
2. ต่อมาดูความจำและเซสชันที่ผ่านมา
บทความต้องการมากกว่าคำสั่งเฉพาะหน้า ยังต้องมีกฎการเรียบเรียงที่สั่งสมมาด้วย
ตัวอย่างเช่น มาตรฐานปัจจุบันมีข้อต่อไปนี้
- อ่านเป็นธรรมชาติสำหรับผู้ใหญ่ทั่วไป แต่เด็กมัธยมต้นก็ยังตามความหมายทัน
- ได้ข้อสรุปใน 5 วินาที ได้ภาพรวมใน 30 วินาที
- อ่านแค่ชื่อเรื่องก็รู้ว่าเป็นเรื่องอะไร
- อ่านแค่หัวข้อ H2 (หัวข้อของแต่ละส่วน) ก็เห็นลำดับเรื่อง
- หลักการคือ 1 ย่อหน้า 1 หัวข้อ
- ข้อสรุปก่อน ตามด้วยเหตุผล แล้วตามด้วยตัวอย่างที่เป็นรูปธรรม
- คำเฉพาะทาง อธิบายก่อนว่าคืออะไร แล้วค่อยบอกชื่อ
- ใช้มุกเพื่อให้ประเด็นเข้าใจง่ายขึ้น
- ข้อมูลที่ระบุตัวบุคคลได้ ให้เขียนเป็นภาพรวม
- 12 ภาษา ไม่แปลตรงตัวทีละคำ
สิ่งสำคัญตรงนี้คือ อย่าใช้ความจำที่ผ่านมาเป็นแหล่งที่มาของข้อเท็จจริง
"ก่อนหน้านี้เคยตัดสินใจไว้แบบนี้" ใช้กับแนวทางการผลิตได้ แต่ถ้าปล่อยให้ "เมื่อก่อนเคยพูดไว้นี่" มาตัดสินเรื่องราคา กฎหมาย ข้อกำหนด ผลวิจัย หรือสถานะปัจจุบันของระบบ บทความก็จะกลายเป็นแคปซูลเวลา
ความจำใช้เพื่อ รักษาแนวทางบรรณาธิการให้ต่อเนื่อง ส่วนข้อเท็จจริงต้องกลับไปหาหลักฐานปัจจุบัน
3. main ล่าสุดบน GitHub คือ "คู่มือการใช้งานฉบับปัจจุบัน"
ในการใช้งานระยะยาว main ล่าสุดบน GitHub คือต้นฉบับที่ถูกต้องของโรงงานบทความ
ระบบคุณภาพปัจจุบันไม่ได้เพิ่มแกนคุณภาพที่ 29 แต่ นำความรู้เฉพาะทางด้านการบรรณาธิการไปรวมเป็นด่านย่อย (sub-gate) ภายใต้แกนหลัก 28 แกนที่มีอยู่
สิ่งที่ AI ใช้เป็นต้นฉบับหลัก ๆ มีดังนี้
- ยุคคุณภาพ (quality epoch) ปัจจุบัน
- แกนคุณภาพ 28 แกน
- ประสบการณ์การอ่านและการเข้าถึงด้านการรับรู้
- คุณภาพเนื้อหา
- มาตรฐานขยายของ Microsoft และ Google
- ขั้นตอนทำงานแบบบรรณาธิการมืออาชีพ
- กฎการเรียบเรียงภาษาญี่ปุ่น
- สไตล์การเขียนที่เป็นธรรมชาติ
- มาตรฐานด้านหลายภาษาและการปรับให้เข้ากับท้องถิ่น
- "หนังสือเดินทางข้อมูล" และความสด
- นิยามของ PASS, SAMPLE_PASS และ COMPLETE_100
- ข้อตกลงเรื่องการรับเข้าอย่างเป็นทางการ การเผยแพร่ และการตรวจยืนยัน
สิ่งสำคัญตรงนี้คือ กฎล่าสุดอยู่เหนือบันทึกความสำเร็จเก่า
ต่อให้เมื่อวานบทความได้ 100 คะแนน พอกฎคุณภาพเปลี่ยน มันก็กลายเป็นแค่ "100 คะแนนของเมื่อวาน" เหมือนชนะทุกแมตช์ตามกติกาของฤดูกาลก่อน จะไปลงแข่งรายการที่ใช้กติกาใหม่แล้วบอกว่า "เมื่อวานชนะแล้ว วันนี้ขอเป็นแชมป์เลย" ก็ไม่ได้
4. บทความต้นฉบับและเอกสารต้นทางคือ "พื้นดินที่ห้ามทำพังเด็ดขาด"
สิ่งที่แก้ได้คือวิธีนำเสนอข้อความ ไม่ใช่การเขียนข้อเท็จจริงใหม่ตามใจชอบ
สิ่งที่ต้องปกป้องเป็นพิเศษคือ
- ตัวเลข
- วันที่
- จำนวนเงิน
- หน่วย
- จำนวนคน
- ชื่อระบบหรือโครงการ
- สเปกผลิตภัณฑ์
- URL
- คำอ้างอิง
- แหล่งที่มา
- ชื่อเฉพาะ
- การออกแบบงานวิจัย
- ความไม่แน่นอน
- สถานะ "ยังไม่รู้"
ถ้าเปลี่ยน "ประมาณ 30%" เป็น "ราวครึ่งหนึ่ง" เพื่อให้อ่านง่าย นั่นไม่ได้อ่านง่ายขึ้น แต่คือการข้ามไปอีกเส้นเวลาหนึ่ง
งานพื้นฐานของบรรณาธิการ AI คือ แก้ลำดับ คำอธิบาย ตัวอย่าง หัวข้อ และสำนวน โดยไม่เปลี่ยนความหมาย
5. บนเว็บ ให้ดู "หลักฐานที่แข็งแรงที่สุด" ก่อน
เมื่อบทความต้องการข้อมูลที่ทันสมัยหรือข้อเท็จจริงจากภายนอก เราจะค้นบนเว็บ แต่ไม่ได้กราบผลลัพธ์อันดับต้น ๆ ของการค้นหาไปหมด
เราชั่งน้ำหนักแหล่งข้อมูลโดยคร่าว ๆ ตามลำดับความแข็งแรงนี้
- มาตรฐาน กฎหมาย และแหล่งข้อมูลต้นทาง
- คู่มือและข้อกำหนดของผู้ให้บริการอย่างเป็นทางการ
- งานวิจัยปฐมภูมิและงานวิจัยที่ผ่านการตรวจสอบโดยผู้เชี่ยวชาญ
- มาตรฐานวิชาชีพด้านบรรณาธิการและข่าว
- แหล่งข้อมูลทุติยภูมิที่เชื่อถือได้
- ชุมชน โซเชียลมีเดีย และประสบการณ์ส่วนตัว
แน่นอนว่าขึ้นอยู่กับประเภทของบทความ
ถ้าคำถามคือ "ผู้ใช้รู้สึกอย่างไรจริง ๆ" Reddit หรือโซเชียลมีเดียก็มีความหมายได้ แต่ถ้าคำถามคือ "WCAG (มาตรฐานการเข้าถึงเว็บ) กำหนดอะไรเป็นเงื่อนไขบังคับ" แล้วไปตัดสินด้วยกระทู้ในบอร์ดที่ว่า "น่าจะ 24px แหละ 555" มาตรฐานคงร้องไห้
นอกจากนี้ สำหรับบทความวิเคราะห์ เปรียบเทียบ วิจัย แนะนำ และบทความที่มีผลกระทบสูง เราจะหาข้อมูลที่ล้มข้อสรุปของตัวเองได้ด้วย
"ฉันรวบรวมแหล่งที่สนับสนุนทฤษฎีนี้มาได้ 5 แหล่ง!" แค่นี้ยังไม่ใช่การวิจัย แต่เป็นแฟนคลับ
6. แกนคุณภาพ 28 แกนไม่ใช่ "เทพ 28 องค์"
ระบบปัจจุบันคงแกนหลักไว้ 28 แกน ถ้ามองคร่าว ๆ คือแกนด้านประสบการณ์การอ่าน 17 แกน และแกนด้านคุณภาพเนื้อหา 11 แกน
17 แกนด้านประสบการณ์การอ่าน
- ความสนใจ
- ความจำ
- การตัดสินใจ
- ความเร็วในการประมวลผล
- ความเข้าใจ
- "กลิ่นข้อมูล" (เบาะแสที่บอกผู้อ่านว่าจะหาสิ่งที่ต้องการได้ที่ไหน)
- ความรกตา
- ลำดับชั้น
- เลย์เอาต์
- ตัวอักษร
- สีและการมองเห็น
- การใช้งาน
- หลายภาษา
- เทคโนโลยีช่วยเหลือ
- การเคลื่อนไหว
- การเปลี่ยนสถานะ
- ความทนทานต่อข้อมูลจริง
11 แกนด้านคุณภาพเนื้อหา
- ผู้อ่าน จุดประสงค์ และสิ่งที่ได้หลังอ่านจบ
- คุณค่าที่เป็นเอกลักษณ์
- ความน่าเชื่อถือ ผู้เขียน และวิธีการผลิต
- ความเสี่ยง ตัวเลข และการตัดสินใจ
- ความหมายของตาราง ภาพประกอบ และรูป
- ขั้นตอน การลงมือทำ และภาระต่อความจำ
- การเปิดกว้างและวัฒนธรรม
- ผู้อ่านทำสิ่งที่ตั้งใจได้สำเร็จหรือไม่
- ความสมบูรณ์ตามแต่ละภูมิภาค
- ประสิทธิภาพและการอ่านอย่างมีสมาธิ
- ข้อความในฐานะเสียง (ฟังเมื่ออ่านออกเสียงแล้วเป็นอย่างไร)
ไม่จำเป็นต้องท่องทั้ง 28 แกนในเนื้อหาทุกครั้ง
จุดประสงค์ไม่ใช่การเติมแกนให้ครบ แต่คือ คิดล่วงหน้าว่าผู้อ่านจะสะดุดตรงไหน แล้วใช้แกนที่เกี่ยวกับอุปสรรคนั้น
ถ้าโรงงานบทความเริ่มพูดว่า "คืนนี้ถวายเทพ 28 องค์ยังขาดอีก 3 แกน" นั่นไม่ใช่การควบคุมคุณภาพแล้ว แต่เป็นองค์กรศาสนา
7. ดูด่านย่อย 14 ด่านของงานบรรณาธิการมืออาชีพ
ภายใต้แกนหลัก 28 แกนมีด่านย่อย 14 ด่านที่มาจากกระบวนการบรรณาธิการมืออาชีพ
- ความต้องการของผู้อ่านและสิ่งที่ได้หลังอ่านจบ
- มุมที่เลือกเล่าของบทความ
- ช่วงเปิดเรื่องที่ดึงคนอ่าน
- บทความนี้พูดเรื่องอะไรและทำไมจึงสำคัญ
- ยกข้อมูลสำคัญขึ้นมาไว้ข้างหน้า
- บทบาทของแต่ละย่อหน้า
- ข้ออ้างกับหลักฐานสอดคล้องกัน
- ตรวจหาหลักฐานที่ค้านได้
- ความแข็งแรงของแหล่งข้อมูล
- แก้ตามลำดับ โครงสร้าง → ข้อเท็จจริง → ถ้อยคำ
- ทำตามคำสัญญาของชื่อเรื่องในเนื้อหา
- เส้นทางนำทางที่ทำให้เดาได้ว่าต่อไปจะมีอะไร
- ความสม่ำเสมอของการเขียนและคำศัพท์
- ความสดหลังเผยแพร่และ "หนี้เนื้อหา"
อย่างไรก็ตาม ไม่ได้เอาทุกข้อไปใช้กับทุกบทความแบบกลไก
บทความรีวิวอาหารไม่จำเป็นต้องสวมโครงสร้างข่าวแบบ Reuters ทั้งชุด และเอกสารข้อกำหนด API ก็ไม่จำเป็นต้องเปิดด้วยประโยคอย่าง "จู่ ๆ เส้นก๋วยเตี๋ยวก็หัวเราะ"
ใช้เฉพาะเทคนิคที่เหมาะกับประเภทของบทความ นี่คือข้อสำคัญ
8. ลำดับการแก้คือ "โครงสร้าง → ข้อเท็จจริง → ถ้อยคำ"
ลำดับเป็นเรื่องที่เงียบ ๆ แต่ได้ผลมากในงานบรรณาธิการมืออาชีพ
รอบที่ 1: โครงสร้าง
- ตอบคำถามของผู้อ่านหรือไม่
- มีมุมที่เลือกเล่าหรือไม่
- ข้อสรุปมาช้าเกินไปหรือไม่
- อ่านแค่หัวข้อ H2 แล้วเห็นลำดับเรื่องหรือไม่
- มีส่วนที่ซ้ำกันหรือไม่
- มีส่วนที่ไม่จำเป็นหรือไม่
รอบที่ 2: ข้อเท็จจริงและหลักฐาน
- ข้ออ้างมีหลักฐานหรือไม่
- หลักฐานนั้นสนับสนุนข้ออ้างจริงหรือไม่
- ตัวเลขต้องระบุกลุ่มตัวอย่างหรือสิ่งที่ใช้เปรียบเทียบหรือไม่
- มีหลักฐานที่ค้านหรือไม่
- มีข้อมูลที่ล้าสมัยหรือไม่
รอบที่ 3: ถ้อยคำ
- มีประโยคที่อัดแน่นเกินไปหรือไม่
- อธิบายศัพท์เฉพาะทางแล้วหรือไม่
- มีคำว่า "นี้" "นั้น" ที่ชี้ไปไม่ถูกหรือไม่
- มุกได้ผลหรือไม่
- กลายเป็นตัวหนาประดับแบบ AI หรือยิง "หมายเหตุ:" รัวเป็นชุดหรือไม่
ถ้าสลับลำดับนี้ จะกลายเป็น การแก้ที่ขัดเงาวอลเปเปอร์ของบ้านที่สัปดาห์หน้าจะถูกทุบทิ้ง
9. แบ่งกฎเรื่องตัวเลขเป็น 3 ประเภท
พอมีตัวเลขโผล่ขึ้นมา AI บางครั้งจะอยากสร้าง "ค่าเกณฑ์" ขึ้นมาเองทันที ตรงนี้ต้องห้ามไว้
ตัวเลขต้องแบ่งเป็น 3 ประเภทเสมอ
ตัวเลขที่แหล่งทางการหรือมาตรฐานกำหนด
เช่น reflow ของ WCAG ที่ระดับเทียบเท่า 320 CSS px การขยายตัวอักษร 200% และขนาดของเป้าหมายที่ต้องกด
ตัวเลขเหล่านี้ทำเป็นด่านบังคับ (hard gate) ได้ ภายในขอบเขตและข้อยกเว้นที่มาตรฐานนั้นกำหนด
ตัวเลขที่ได้จากงานวิจัย
ถ้ากลุ่มที่ศึกษา ภาษา เงื่อนไข หรือกลุ่มตัวอย่างต่างกัน ก็เอาไปเป็นเกณฑ์สากลตรง ๆ ไม่ได้
จะหยิบ "X คำในภาษาอังกฤษ" จากงานวิจัยมากดเครื่องคิดเลขเสกเป็น "X ตัวอักษรในภาษาญี่ปุ่น" ไม่ได้
เกณฑ์คร่าว ๆ ที่ใช้ภายในเว็บไซต์
เช่น "ถ้ามี H2 ตั้งแต่ 4 หัวข้อขึ้นไป ให้ตรวจดูว่าต้องมีสารบัญหรือไม่"
สะดวกสำหรับการหาบทความที่ควรกลับไปตรวจ แต่ อย่าปล่อยให้เกณฑ์คร่าว ๆ ได้เลื่อนขั้นเป็นตำรวจ
แม้แต่ Google เองก็ไม่ได้บอกตัวเลขวิเศษอย่าง "ความยาวที่ Google ชอบ" สิ่งที่ควรดูไม่ใช่ความยาว แต่คือบทความมีเนื้อหาที่จุดประสงค์ต้องการครบหรือไม่
10. 12 ภาษาต้องปรับให้เข้ากับท้องถิ่น ไม่ใช่แค่แปล
ภาษาที่รองรับคือ
- ภาษาญี่ปุ่น
- ภาษาอังกฤษ
- ภาษาเกาหลี
- ภาษาจีน (ตัวย่อ)
- ภาษาจีน (ตัวเต็ม)
- ภาษาสเปน
- ภาษาโปรตุเกส (บราซิล)
- ภาษาอินโดนีเซีย
- ภาษาไทย
- ภาษาเวียดนาม
- ภาษาฝรั่งเศส
- ภาษาเยอรมัน
เวลาทำหลายภาษา เราแบ่งคำเป็น 3 ประเภท
LOCALIZE_CONCEPT
แนวคิดทั่วไป ให้เปลี่ยนเป็นคำที่คนในภาษานั้นเข้าใจได้ตามปกติ
KEEP_EXACT_NAME
สิ่งที่ชื่อต้องแม่นยำ เช่น ชื่อผลิตภัณฑ์ ชื่อมาตรฐาน API URL โค้ด ชื่อไฟล์ และรหัสอ้างอิงของงานวิจัย ให้เก็บไว้ตามเดิม
KEEP_EXACT_NAME_WITH_LOCAL_DESCRIPTOR
ถ้าเก็บชื่อไว้ แต่ชื่อเพียงอย่างเดียวไม่ทำให้รู้ว่าเป็นอะไร ให้เติมคำอธิบายสั้น ๆ ในภาษานั้น
การคัดลอกลำดับคำ การขึ้นบรรทัดใหม่ และมุกเล่นคำของภาษาญี่ปุ่นไปใส่ 12 ภาษา ไม่ใช่การแปล
นั่นคือ การเอาปลั๊กญี่ปุ่นไปเสียบเต้ารับต่างประเทศด้วยกำลังใจล้วน ๆ
มุกตลกก็ต้องปรับที่ความหมายเช่นกัน ถ้าอันไหนไม่ไปต่อ ก็เปลี่ยนเป็นเสียงหัวเราะแบบอื่นที่เป็นธรรมชาติ
11. PASS คือระบบด่าน ไม่ใช่คะแนนเฉลี่ย
หลักพื้นฐานปัจจุบันคือ gate-first-score-second (ผ่านด่านก่อน ให้คะแนนทีหลัง)
นั่นคือ ไม่มีเรื่องแบบนี้
"ข้อเท็จจริงผิด แต่ดีไซน์ได้ 95 ถ้อยคำได้ 96 เฉลี่ยแล้วเกิน 90 ผ่าน!"
FAIL ร้ายแรงไม่อาจถูกลบด้วยคะแนนเฉลี่ย
SAMPLE_PASS
ในตัวอย่างที่ตรวจ ไม่พบปัญหาร้ายแรง
PASS
ขอบเขตของเป้าหมายปัจจุบันถูกกำหนดไว้ชัดเจน หลักฐานที่จำเป็นผูกกับตัวตนของเนื้อหาปัจจุบัน ยุคคุณภาพ และเวอร์ชันของกฎ และไม่มี UNKNOWN ร้ายแรงค้างอยู่ในหัวข้อที่จำเป็น
COMPLETE_100
hard gate ที่เกี่ยวข้อง การตรวจทานด้านความหมาย และหลักฐานภายนอกกับหลักฐานตอนรันจริงที่จำเป็นครบถ้วน และทุกอย่างปิดครบสำหรับเป้าหมายทั้งหมดในปัจจุบัน
ไม่ใช่ FAIL เพียงเพราะยังไม่มีมนุษย์มาให้คะแนน ตอนนี้ผู้ตรวจทานด้านความหมายอย่างเป็นทางการคือ บรรณาธิการเชิงความหมายแบบ AI ที่อิงแหล่งที่มา (source-grounded AI semantic editor)
แต่ถ้า AI เขียนเอง แล้วประกาศว่า
"หลังการตรวจสอบอย่างเข้มงวดโดยอาจารย์ AI ข้อความของอาจารย์ AI ถูกตัดสินว่าถูกต้องสมบูรณ์"
ก็ไม่นับเป็นหลักฐาน
ผู้พิพากษาเป็น AI ได้ แต่ผู้พิพากษาห้ามปั้นพยานหลักฐานเองจากดินเหนียว
12. ต่อจากเนื้อหา คือดูหน้าจอจริง
ต่อให้เนื้อหาบทความถูกต้อง ถ้าหน้าจอพังก็อ่านไม่ได้
บนเว็บไซต์จริง เราตรวจอย่างน้อยสถานะเหล่านี้
- มือถือขนาดประมาณ 320px
- มือถือขนาดประมาณ 390px
- มือถือแนวนอน
- แท็บเล็ต
- พีซีขนาดประมาณ 1280px / 1440px
- ขยายตัวอักษร 200%
- WCAG Text Spacing (การเว้นระยะข้อความ)
- ตัวอักษรบวมจากการจำลองการปรับท้องถิ่น (การทดสอบที่ยืดข้อความเหมือนตอนแปล)
- forced-colors (โหมดแสดงผลที่คอนทราสต์สูง)
- reduced-motion (การตั้งค่าปิดแอนิเมชัน)
จากนั้นใช้ "กับระเบิด" ในข้อมูลจริง
- ชื่อเรื่องที่ยาวที่สุด
- สายอักขระที่ตัดบรรทัดไม่ได้ยาวที่สุด
- เนื้อหาที่ยาวที่สุด
- เนื้อหาที่สั้นที่สุด
- บทความที่มีหัวข้อมากที่สุด
- บทความที่มีลิงก์มากที่สุด
- บทความที่มีตารางมากที่สุด
- บทความที่มีองค์ประกอบคล้ายนิยามมากที่สุด
- บทความที่มีบล็อก code / pre มากที่สุด
- บทความที่ผสมระบบตัวอักษรหลายแบบ
ถ้าลองแค่บทความธรรมดาแล้วบอกว่า "ไม่มีปัญหา!" ขอบเขตการตรวจต่างกันราวกับ ไปทำสควอตในห้องสมุดแล้วนับว่าตรวจสุขภาพเสร็จแล้ว
ข้อผิดพลาด ผลลัพธ์ 0 รายการ การโหลดล้มเหลว และคำแปลที่ขาดหาย ก็เป็นส่วนหนึ่งของประสบการณ์ของบทความเช่นกัน
13. กฎด้านการวิจัยก็ทำงานเองได้
กฎคุณภาพเองก็ล้าสมัยได้
ดังนั้นจึงฝังการอัปเดตด้านการวิจัยไว้ในการตรวจสอบส่วนกลางที่มีอยู่เดิม
- รีเฟรชตามปกติ: โดยหลักคือทุก 7 วัน
- deep sweep (กวาดตรวจเชิงลึก): โดยหลักคือทุก 30 วัน
- การเปลี่ยนแปลงสำคัญจากฝั่งทางการ: เลื่อนให้เร็วขึ้นได้ถ้าจำเป็น
สิ่งที่เข้าไปดูมี W3C/WCAG, ISO 24495, Microsoft, Google, Reuters, AP, GOV.UK, วิทยาศาสตร์การรู้คิด, HCI (ปฏิสัมพันธ์ระหว่างมนุษย์กับคอมพิวเตอร์), งานวิจัยด้านการอ่าน, การค้นหาข้อมูล, การเข้าถึง และงานวิจัยด้านหลายภาษาและงานบรรณาธิการ
ข้อค้นพบใหม่จะถูกพิจารณาตามลำดับนี้
ซ้ำกับกฎที่มีอยู่หรือไม่ → แหล่งข้อมูลแข็งแรงหรือไม่ → ใช้กับบทความไหน → ตัวเลขครอบคลุมช่วงไหน → มีหลักฐานที่ค้านหรือไม่
แล้วจัดเข้าหนึ่งในประเภทต่อไปนี้
- ADOPT
- CONDITIONAL
- TEST
- DEFER
- REJECT
- SUPERSEDED
ในการทำ deep sweep ครั้งแรกของ v5 เมื่อวันที่ 28 สิงหาคม 2026 ไม่พบการเปลี่ยนแปลงที่ใหญ่พอจะล้มเกณฑ์ PASS ปัจจุบัน จึงตัดสินใจคง v5 ไว้
14. คู่มือทางการไม่ใช่คำพยากรณ์
Microsoft, Google, Reuters, AP, W3C, ISO ล้วนเป็นแหล่งที่แข็งแรง แต่ ขอบเขตการใช้งานต่างกัน
ตัวอย่างเช่น ในเอกสารเทคนิค การลดสำนวนและอารมณ์ขันอาจช่วยให้แปลง่ายและแม่นยำขึ้น
แต่ถ้าเอากฎนั้นไปใช้กับบทความรีวิวอาหารหรือบทความบันเทิงทุกชิ้น ก็จะได้ข้อความแบบนี้
บริโภคแฮมเบิร์กสเต๊ก เกิดน้ำเนื้อ ระดับความพึงพอใจเพิ่มขึ้น
ข้อความที่ ทิ้งความรู้สึกไว้ที่ห้องกำกับดูแลการปฏิบัติตามกฎ
สำหรับคู่มือทางการ ให้ดูว่ามันถูกต้องในบริบทไหน
ไม่ใช่ "เป็นทางการ ก็ ADOPT กับทุกบทความ" ถ้าจำเป็นก็เป็น CONDITIONAL
15. ต่อให้ GitHub ล่ม "สมอง" ของบทความก็ต้องไม่ตายตาม
เมื่อเข้าถึง GitHub ไม่ได้ ก็ไม่จำเป็นต้องหยุดการเขียนบทความและการตรวจทานด้านความหมายทั้งหมด
เพื่อเป็นฐานสำหรับการกู้คืน สิ่งต่อไปนี้ถูกเก็บไว้ในอีกระบบหนึ่งด้วย
- แกนหลัก 28 แกน
- นโยบายของบรรณาธิการ AI
- ขั้นตอนทำงานแบบบรรณาธิการมืออาชีพ
- ความแข็งแรงของแหล่งข้อมูล
- เกณฑ์ตัวเลข
- วิธีอัปเดตงานวิจัย
- การตัดสิน PASS
- หลักการไม่หยุดโรงงาน
แต่ตอนที่มองไม่เห็น GitHub ห้ามเดาเอาเองเพื่อเติมสิ่งต่อไปนี้
- SHA ปัจจุบัน (รหัสระบุของ commit)
- ใบรับ (receipt) ล่าสุด
- นำไปใช้กับ repo แล้วหรือยัง
- ความคืบหน้าอย่างเป็นทางการในตอนนี้
เรื่องเหล่านี้คือ UNKNOWN
เมื่อ GitHub กลับมา ให้เทียบ main ล่าสุด ฐานกู้คืน และข้อมูลหลักและข้อมูลทางการล่าสุดเข้าด้วยกัน แล้วกลับสู่การทำงานปกติ
"ใครเขียนทีหลังชนะ" (blind last-write-wins) ไม่ใช่นโยบายบรรณาธิการ แต่คือเป่ายิ้งฉุบ
16. สิ่งที่เราไม่ทำ
โรงงานบทความนี้หลีกเลี่ยงอย่างน้อยสิ่งต่อไปนี้
- ใช้คำตอบของ AI เพียงอย่างเดียวเป็นหลักฐานของข้อเท็จจริง
- เขียนว่า "ผู้เชี่ยวชาญตรวจสอบแล้ว" ทั้งที่ไม่ได้ให้คนตรวจ
- เรียกตัวเลขที่ Google ไม่เคยบอกว่า "เกณฑ์ของ Google"
- ผลิตบทความคุณภาพต่ำจำนวนมากเพียงเพื่ออันดับการค้นหา
- ตั้งชื่อเรื่องยั่วแล้วไม่ตอบในเนื้อหา
- แก้ตัวเลขหรือความไม่แน่นอนของต้นฉบับเพื่อให้อ่านง่าย
- ยัดทุกบทความเข้าแม่พิมพ์เดียวกัน ไม่ว่าจะเป็นแบบข่าวหรือแบบเอกสารเทคนิค
- คัดลอกหัวข้อ ลำดับคำ และมุกของภาษาญี่ปุ่นไปยังภาษาอื่นแบบกลไก
- ใช้ตัวหนาทุบทั้งบทความ
- ปล่อยให้ "หมายเหตุ:" งอกเหมือนวัชพืช
- หยุดโรงงานที่ไม่เกี่ยวข้องเพียงเพราะบทความชิ้นเดียวล้มเหลว
- ประกาศว่า "ทั้งเว็บไซต์ได้ 100 คะแนน" จากการตรวจตัวอย่างอย่างเดียว
สรุป: บรรณาธิการ AI ยุ่งที่สุดตอน "ก่อนเขียน" และ "หลังเขียน"
ถ้ามองแค่การเขียน บรรณาธิการ AI ก็ดูเหมือนเครื่องสร้างข้อความ
แต่งานจริงคือ
อ่านคำสั่ง → อ่านกฎเก่า → อ่านต้นฉบับบน GitHub → ปกป้องเอกสารต้นทาง → ตรวจแหล่งข้อมูลหลัก แหล่งทางการ และงานวิจัย → ลองหักล้างตัวเอง → สร้างโครงสร้าง → ตรวจสอบข้อเท็จจริง → ขัดเกลาถ้อยคำ → ปรับเป็น 12 ภาษา → ลองทำให้พังบนหน้าจอจริง → ปิดงานด้วยการตรวจคุณภาพ → และวิจัยตัวกฎเองเป็นระยะ
"เขียนบทความให้หน่อย" คือปุ่มสตาร์ต ไม่ใช่คำอธิบายงาน
บรรณาธิการ AI ของโรงงานบทความเดินตรวจทั่วโรงงานในฐานะนักเขียน คนตรวจทาน นักวิจัย บรรณาธิการงานแปล ผู้ตรวจคุณภาพ และช่างซ่อมบำรุงในคนเดียว
และสิ่งสำคัญที่สุดไม่ใช่ การสร้างข้อความที่ทำตามกฎ แต่คือการสร้างบทความที่ ผู้อ่านจับความหมายได้ทันที ไล่ตามหลักฐานได้ และตัดสินใจเรื่องที่ต้องตัดสินใจได้
กฎเป็นเครื่องมือเพื่อสิ่งนั้น โรงงานบทความนี้ไม่ได้มีไว้บูชากล่องเครื่องมือ
