ใส่กฎแล้ว AI จะเขียนดีขึ้นไหม? — เปลี่ยน “บรรณาธิการมืออาชีพ” ให้เป็นเวิร์กโฟลว์ TypeScript

เวลา AI เขียนออกมาไม่ดีพอ วิธีที่คนมักคิดก่อนคือเปลี่ยนไปใช้โมเดลที่ฉลาดกว่า

แต่อีกวิธีคือวาง กองบรรณาธิการที่จู้จี้สุด ๆ และไม่เคยนอน ไว้ข้างโมเดล

มันตรวจชื่อเรื่อง เทียบคำสัญญาในชื่อเรื่องกับเนื้อหา หาศัพท์ที่ไม่อธิบาย จับคำสงวนที่พูดซ้ำ ตรวจให้ครบ 12 ภาษา แล้วส่งกลับไปแก้เฉพาะจุดที่พัง

TypeScript ไม่ได้มีพรสวรรค์ด้านการเขียน แต่สร้าง สายการผลิตที่ไม่ยอมปล่อยต้นฉบับอ่อนออกจากโรงงาน ได้

1. สรุปใน 5 วินาที: อย่าเขียน “พรสวรรค์” ลงโค้ด ให้เขียน “กระบวนการบรรณาธิการ” ลงโค้ด

กฎร่วมช่วยให้บทความ AI ดีขึ้นได้ แต่ผลที่ใหญ่กว่าคือทำให้กฎกลายเป็นวงจร สร้าง → ตรวจ → ประเมินความหมาย → แก้จุดเสีย → ตรวจซ้ำ

OpenAI อธิบาย eval ว่าเป็นการกำหนดก่อนว่าอะไรคือผลลัพธ์ที่ดี จากนั้นวัด และปรับปรุง โดยนำรูปแบบความผิดพลาดใหม่จากผลลัพธ์จริงกลับมาเพิ่มในระบบประเมิน[1]

ถ้าเป็นโรงงานบทความ ความผิดพลาดหนึ่งครั้งไม่ควรแก้แค่บทความเดียว แต่ควรกลายเป็นด่านตรวจของอีกหนึ่งร้อยบทความถัดไป

2. TypeScript ไม่ใช่นักเขียน แต่เป็นสายการผลิต

โค้ดเก่งเรื่องที่ตัดสินได้แน่นอน เช่น

• มี H1 มากกว่าหนึ่งหรือไม่
• title กับ og:title ขัดกันหรือไม่
• ขาดภาษาใดใน 12 ภาษาหรือไม่
• มีหัวข้อซ้ำหรือไม่
• วันที่หรือ URL ผิดรูปแบบหรือไม่
• ถ้าไม่ผ่านเกณฑ์ต้องส่งกลับแก้หรือไม่

แต่คำถามอย่าง “เปิดเรื่องสนุกไหม” “ควรเก็บอุปมานี้ไหม” “ชื่อเรื่องตรงกับคำถามจริงของผู้อ่านหรือไม่” และ “งานวิจัยกลบข้อสังเกตเดิมหรือเปล่า” ต้องเข้าใจความหมาย

ดังนั้นแบ่งงานเป็น TypeScript ตรวจเชิงกล และ AI บรรณาธิการตรวจเชิงความหมาย จะเหมาะกว่า

3. “บรรณาธิการมืออาชีพ” ใช้งานจริงง่ายขึ้นเมื่อแยกเป็นบทบาท

บรรณาธิการโครงสร้าง

ดูว่าผู้อ่านอยากรู้อะไร คำตอบมาช้าไปไหม และลำดับบทเป็นธรรมชาติหรือไม่

บรรณาธิการสำนวน

ปรับชื่อเรื่อง บทนำ การซ้ำ คำ และจังหวะ

บรรณาธิการข้อเท็จจริง

ตรวจตัวเลข วันที่ คำอ้าง ระดับความมั่นใจ และแหล่งที่มา

บรรณาธิการทางเข้าจากการค้นหา

ดูว่าช่วงแรกของชื่อเรื่องบอกได้หรือยังว่าหน้านี้เกี่ยวกับอะไร

Google Search Central ระบุว่าชื่อผลการค้นหาช่วยให้ผู้ใช้เข้าใจเนื้อหาและความเกี่ยวข้องได้อย่างรวดเร็ว และแนะนำชื่อที่ชัด กระชับ แตกต่างกัน พร้อมหลีกเลี่ยงการยัดคีย์เวิร์ด[2]

งานวิจัยด้านการใช้งานของ NN/g ก็ชี้ว่าผู้ใช้เว็บมักสแกนมากกว่าอ่านทุกคำ ดังนั้นคำต้น ๆ ของลิงก์และชื่อเรื่องจึงมีน้ำหนักมาก[4][5]

นี่ไม่ใช่การยัด “คีย์เวิร์ด SEO วิเศษ” ไว้ซ้ายสุด แต่คือทำให้ผู้อ่านรู้เรื่องเร็ว

4. Before / After: ย้ายมุก ไม่ต้องฆ่ามุก

ก่อนแก้

นามสกุลไม่ผิด พจนานุกรมต่างหากที่พัง — Manko, Wang, Chin กับ “ชื่อที่อันตรายในภาษาอื่น”

มุกแรง แต่หัวข้อจริงมาช้า

หลังแก้

ชื่อที่ฟังน่าอายในอีกภาษา — Manko, Wang, Chin และการชนกันข้ามภาษา

แล้วเปิดบทความด้วย

นามสกุลไม่ผิด พจนานุกรมต่างหากที่พัง

มุกยังอยู่ และทำงานดีขึ้นเพราะผู้อ่านรู้บริบทแล้ว

แนวทาง people-first ของ Google ก็เสนอให้ชื่อเรื่องสรุปเนื้อหาอย่างมีประโยชน์และตรงไปตรงมา แทนการทำให้หวือหวาเพื่อดึงทราฟฟิกจากการค้นหา[3]

5. กฎร่วมที่ดีป้องกันอุบัติเหตุซ้ำ ไม่ได้ทำให้ทุกบทความหน้าตาเหมือนกัน

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

กฎที่ดีกว่าคือกำหนดสิ่งที่ห้ามพัง เช่น

• อย่าฝังคําถามหลักไว้หลังสโลแกน
• อย่าสัญญาในชื่อเรื่องสิ่งที่เนื้อหาไม่ตอบ
• อย่าพูดข้อสงวนเดิมซ้ำ
• อย่าโยนศัพท์เฉพาะโดยไม่อธิบาย
• หัวข้อย่อยควรเข้าใจได้เมื่ออ่านเดี่ยว ๆ
• งานวิจัยควรหนุนข้อสังเกตเดิม ไม่แย่งบทนำ
• อย่าแปลโครงสร้างภาษาญี่ปุ่นตรง ๆ ไปอีก 11 ภาษา

6. แบ่ง P0 / P1 / P2 เพื่อไม่ให้ระบบกลายเป็นคุกของกฎ

P0: ห้ามพลาด

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

P1: สำคัญมาก

ตอบเร็ว หนึ่งย่อหน้าหนึ่งประเด็น อธิบายง่ายก่อนศัพท์เฉพาะ หัวข้อชัด ลดการซ้ำ

P2: รสชาติของบทความ

มุก อุปมา น้ำเสียงสนทนา จังหวะ และฮุกที่จำง่าย

รักษา P0 ไม่ได้แปลว่าต้องฆ่า P2 ไม่เช่นนั้นงานคุณภาพทั้งหมดจะออกมาเหมือนประกาศราชการ

7. ทรัพย์สินจริงคือวงจรประเมินที่โตจากความผิดพลาด

1. สร้างร่าง
2. ตรวจเชิงกล
3. ให้ AI บรรณาธิการอ่านความหมาย
4. ส่งเหตุผลที่ไม่ผ่านแบบมีโครงสร้าง
5. แก้เฉพาะส่วนที่ผิด
6. ตรวจซ้ำ
7. ถ้าเป็นความผิดพลาดชนิดใหม่ที่ใช้ทั่วไปได้ ให้เพิ่มเป็นกฎถาวรที่ควรพิจารณา

แนวคิด eval ของ OpenAI ก็เน้นวงจรปรับปรุงต่อเนื่องจากความผิดพลาดจริงเช่นกัน[1]

ถ้าพังแค่ชื่อเรื่อง ก็ไม่ควรสร้างเนื้อหาดี ๆ สองพันคำใหม่ทั้งหมด

8. TypeScript ทำได้ง่ายกว่าที่คิด

const draft = await writeArticle(input);
const hardCheck = runDeterministicChecks(draft);
const editorial = await semanticEditor.review(draft, rubric);

if (!hardCheck.ok || editorial.hasCriticalIssue) {
  const revised = await reviseOnlyFailures(draft, { hardCheck, editorial });
  return verifyAgain(revised);
}
return draft;

สิ่งที่ตัดสินได้แน่นอนให้โค้ดทำ สิ่งที่ต้องเข้าใจความหมายให้ AI บรรณาธิการทำ แล้วเปลี่ยนเหตุผลที่ไม่ผ่านเป็นคำสั่งแก้เฉพาะจุด

9. ระบบอัตโนมัติก็ยังพลาด: AI บรรณาธิการไม่ใช่พระเจ้า

มันอาจลบมุกดีเพราะมองว่าเยิ่นเย้อ ทำสไตล์ชนกลุ่มน้อยให้เรียบเกินไป ทำมุกวัฒนธรรมจืดตอนแปล หรือให้คะแนนงานตัวเองสูงเกินจริง

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

10. เมื่อมี 100 หรือ 1000 บทความ สิ่งที่แรงที่สุดคือ “ดอกเบี้ยทบต้นของการปรับปรุง”

เจอบทความหนึ่งที่สโลแกนดันคำถามหลักไปข้างหลัง ก็เพิ่มด่านตรวจให้ทุกบทความได้

เจออีกบทความที่คำว่า “แต่” ซ้ำจนสรุปละลาย ก็เพิ่มเกณฑ์ใหม่ได้

เจอเยอรมันที่ไวยากรณ์ถูกแต่กลิ่นแปลชัด ก็เพิ่มเกณฑ์เฉพาะภาษาได้

ความผิดพลาดจึงเปลี่ยนจากงานแก้ครั้งเดียวเป็นโครงสร้างพื้นฐานของกองบรรณาธิการ

11. สรุป: สร้างกองบรรณาธิการที่ไม่หลับ ไม่ใช่ภูเขากฎ

เป้าหมายไม่ใช่ย้ายพรสวรรค์ด้านภาษาเข้า TypeScript

แต่คือทำให้คำตัดสินของบรรณาธิการเก่ง ๆ ทำซ้ำได้ เช่น “คนอ่านไม่รู้ว่านี่เรื่องอะไร” “ชื่อเรื่องสัญญาแต่เนื้อหาไม่ตอบ” “มุกนี้อย่าลบ แค่ย้าย” “ข้อเท็จจริงนี้ต้องมีแหล่ง”

เมื่อคำตัดสินเหล่านี้กลายเป็นการตรวจเชิงกล การอ่านเชิงความหมาย การแก้เฉพาะจุด และการตรวจซ้ำ โมเดลเดิมก็สร้างผลลัพธ์สุดท้ายที่ดีขึ้นได้

เพราะสิ่งที่พัฒนาคือ ระบบบรรณาธิการรอบโมเดล

---