คู่มือการเขียนทางการของ Microsoft และ Google นั้นทรงพลังมาก สอนให้เขียนประโยคสั้น ๆ วางประเด็นสำคัญไว้ก่อน ใช้ศัพท์ให้เป็นแบบเดียวกัน เขียนให้แปลง่าย และทำให้ใครก็อ่านได้สบาย
แต่ยาแรงไม่ได้ทำให้เราแข็งแรงเพียงเพราะกินทั้งขวด ถ้าเอาคู่มือทางการมาใช้แบบกลไก ราวกับเป็นกฎหมายที่ต้องทำตามทุกตัวอักษร บทความจะย้ายไปทำงานที่ศูนย์ช่วยเหลือของบริษัทขึ้นมาทันที ข้อความที่เมื่อวานยังบ่นว่า "ทำไมมันเป็นแบบนี้ได้เนี่ย" พอเช้าวันรุ่งขึ้นก็พูดได้แค่ "โปรดดำเนินการตามขั้นตอนต่อไปนี้" บุคลิกถูกส่งเข้าไปผ่านการอนุมัติของคณะกรรมการเสียแล้ว
ข้อสรุปนั้นง่ายมาก
สิ่งที่ควรยืมจากคู่มือทางการ คือภูมิปัญญาด้านโครงสร้าง ความชัดเจน การเข้าถึงได้ และการเขียนหลายภาษา ซึ่งมีไว้ไม่ให้ผู้อ่านหลงทาง ส่วนสิ่งที่ไม่ควรยืม คือการทำให้สไตล์เหมือนกันหมดทั้งที่ไม่เข้ากับเป้าหมายของสื่อเรา
และนี่ไม่ใช่ช่วงวัยรุ่นกบฏต่อคู่มือ คู่มือสไตล์สำหรับนักพัฒนาของ Google เองก็บอกให้ใช้กฎเฉพาะของโปรเจกต์ก่อน และออกนอกคู่มือได้ถ้าเป็นประโยชน์ต่อผู้อ่าน[4] สุดท้ายแล้วทั้ง Microsoft และ Google ต่างวาง "ให้ผู้อ่านเข้าใจง่าย" ไว้เป็นศูนย์กลาง[1][2][5]
สรุปใน 5 วินาที: คู่มือคือราวกันตก ไม่ใช่รัฐธรรมนูญ
ถ้าแบ่งการใช้คู่มือทางการเป็นสามชั้น จะเกิดอุบัติเหตุยากขึ้น
| ชั้น | บทบาท | ตัวอย่าง |
|---|---|---|
| เงื่อนไขบังคับ | สิ่งที่ต้องทำตาม เช่น กฎหมาย มาตรฐาน ข้อกำหนดทางการ | ข้อกำหนดทางการด้านการเข้าถึง ชื่อผลิตภัณฑ์ที่ถูกต้อง การอ้างอิงและแหล่งที่มา |
| ข้อแนะนำที่หนักแน่น | หลักการที่ช่วยให้อ่านง่ายขึ้นมาก | บอกข้อสรุปก่อน ใช้หัวข้อสร้างลำดับเรื่อง ย่อหน้าสั้น ใช้ศัพท์เป็นอย่างเดียวกัน |
| รสชาติของสื่อ | สิ่งที่ออกแบบให้เข้ากับเว็บไซต์ ผู้เขียน และผู้อ่าน | อารมณ์ขัน อุปมา มุกแซวตัวเอง จังหวะ คำลงท้าย มุกประจำ |
ปัญหาเกิดขึ้นในวินาทีที่เอาทั้งสามชั้นไปแปลงเป็น "กฎเด็ดขาด" หมด
ตัวอย่างเช่น คู่มือของ Google สำหรับนักพัฒนาแนะนำให้เลี่ยงสำนวนและมุกที่ขึ้นกับวัฒนธรรมในเอกสารเทคนิคที่เขียนให้คนทั่วโลก[5] สำหรับเอกสารอธิบายวิธีตั้งค่า API ที่จะแปลเป็น 12 ภาษา นี่เป็นเรื่องสมเหตุสมผลมาก
แต่ไม่ได้แปลว่าจะเอาไปเปลี่ยนรีวิวร้านอาหาร บันทึกท่องเที่ยว เรื่องเล่าจากการเล่นเกม เรียงความ หรือบทความเชิงสังเกต ให้กลายเป็น "ห้ามหัวเราะ: เอกสารเทคนิค 24 ชั่วโมง"
ถ้านำกฎมาใช้โดยไม่ดูขอบเขต เราอาจประกอบเครื่องจักรผิดตัวขึ้นมาจากชิ้นส่วนที่ถูกต้องก็ได้
ทำไมการใช้คู่มือทางการตรง ๆ ถึงมักทำให้จืด
แนวทางของ Microsoft เรื่องการเขียนให้กวาดตาอ่านง่าย แนะนำให้วางข้อมูลสำคัญไว้ก่อน ใช้หัวข้อ ประโยค และย่อหน้าที่สั้น และมีวิธีนำทางสำหรับข้อความยาว[1] แนวทางด้านการเข้าถึงก็ให้ความสำคัญกับข้อความที่สั้น มีความหมาย และตรงประเด็นเช่นกัน[2]
มาถึงตรงนี้ยังแข็งแรงมาก
แต่พอทำให้เป็นอัตโนมัติ แล้วเริ่มให้คะแนนเป็นตัวเลข เช่น "ยิ่งสั้นยิ่งได้คะแนนสูง" "ลบอุปมา" "ลบคำแสดงอารมณ์" "ลบภาษาพูด" ทุกอย่างก็พัง
ประโยคสั้นเยอะเกินไป
แล้ว
ข้อความ
ก็กลายเป็นแบบนี้
ตั้งใจจะให้อ่านง่าย แต่กลายเป็นหุ่นยนต์ส่งโทรเลขมาให้
ในทางกลับกัน ถ้าทำให้ทุกย่อหน้าเป็น "ข้อสรุป→เหตุผล→ตัวอย่าง" เหมือนกันหมด สักไม่กี่บทความก็รู้สึกดี แต่พอถึงบทความที่ 1,000 ผู้อ่านก็ทำนายอนาคตได้แล้ว ความสม่ำเสมอในการออกแบบข้อมูลเป็นสิ่งจำเป็น แต่ไม่จำเป็นต้องทำให้การแสดงออกเหมือนกันด้วย
การทำให้อ่านง่ายไม่ใช่งานดึงบุคลิกออกจากข้อความ
แต่คืองานลดต้นทุนที่สูญเปล่าซึ่งผู้อ่านต้องจ่ายเพื่อจับความหมาย
Microsoft กับ Google พูดอะไรกันแน่
ถ้าสรุปคู่มือทางการ จุดร่วมนั้นเรียบง่ายอย่างไม่คาดคิด
Microsoft ผลักดันอย่างหนักเรื่อง "กันหลงทาง" คือวางสิ่งสำคัญไว้ก่อน เขียนสั้นและชัด ข้อความยาวให้มีตัวนำทาง และรักษาโครงสร้างให้สม่ำเสมอ[1] ในเรื่องการเข้าถึงก็ให้ความสำคัญกับประโยคสั้นที่มีความหมายและโครงสร้างที่ชัดเจน[2] สำหรับเอกสารระดับโลก ระบุว่าประโยคสั้นเรียบง่ายและศัพท์ที่สม่ำเสมอช่วยให้แปลง่ายขึ้น[3]
คู่มือของ Google สำหรับนักพัฒนาก็แนะนำให้เขียนชัดเจน กระชับ ไม่กำกวม อธิบายตรง ๆ และใช้ศัพท์สม่ำเสมอ[5] แต่ที่ส่วนบนสุดของคู่มือเดียวกันเขียนไว้ว่า ให้ใช้สไตล์เฉพาะของโปรเจกต์ก่อน และออกนอกคู่มือได้ถ้าเนื้อหาดีขึ้น[4]
ส่วนฝั่งการค้นหาของ Google ให้ความสำคัญกับ ข้อมูลต้นฉบับ การวิเคราะห์ที่เป็นของตัวเอง คำอธิบายที่เพียงพอ ประสบการณ์ตรง และเนื้อหาที่ทำให้ผู้อ่านบรรลุเป้าหมาย มากกว่าการทำให้ข้อความดูเป็นสไตล์ Google[6] คำแนะนำปี 2026 สำหรับการค้นหาด้วย AI เชิงสร้างสรรค์ก็เน้นมุมมองที่เป็นเอกลักษณ์ และ "เนื้อหาที่ไม่ใช่เรื่องทั่วไปที่ใครก็ทำได้" ไม่ใช่การเอาข้อมูลเดิมมาเล่าใหม่[7]
กล่าวคือ ถ้าเอาเอกสารทางการทั้งหมดมาต่อกัน จะได้แบบนี้
ทำให้อ่านง่าย ทำให้ถูกต้อง ช่วยผู้อ่าน และอย่าเป็นเครื่องถ่ายเอกสาร
เป็นคำขอที่ค่อนข้างมนุษย์มาก
อย่าเอาตัวเลขที่คิดเองไปเรียกว่า "มาตรฐานของ Google"
สิ่งที่อันตรายเป็นพิเศษในการทำงานเขียนอัตโนมัติ คือการเลื่อนตัวเลขที่คู่มือทางการไม่เคยพูดถึงขึ้นเป็นโองการศักดิ์สิทธิ์
"หนึ่งประโยคต้องไม่เกิน 20 ตัวอักษร นี่คือมาตรฐานของ Google" "บทความเกิน 2000 ตัวอักษรได้เปรียบด้าน SEO" "หัวข้อต้องมีกี่หัวข้อพอดี" "สัดส่วนศัพท์เฉพาะต้องต่ำกว่ากี่เปอร์เซ็นต์"
ตัวเลขแบบนี้ใช้เป็นค่าเตือนภายในได้ แต่ถ้าฝ่ายทางการไม่ได้พูดไว้ ก็ห้ามเรียกว่า "Google บังคับ" หรือ "Microsoft บังคับ"
จริง ๆ แล้ว แนวทางของ Google Search เรื่องเนื้อหาที่ทำเพื่อผู้คน กลับแนะนำให้ถามตัวเองว่า เรากำลังปรับจำนวนคำให้ตรงตัวเลขเพราะคิดว่า Google ชอบหรือเปล่า และระบุชัดเจนว่า Google ไม่มีจำนวนคำตายตัวที่ชอบ[6]
ดังนั้นในการตรวจอัตโนมัติ ให้แบ่งการตัดสินเป็นสามประเภท
- เงื่อนไขบังคับทางการ: กำหนดเป็นข้อบังคับ พร้อมแนบหลักฐาน
- ข้อแนะนำทางการ: ทำเป็นคำเตือนหรือข้อเสนอให้ปรับปรุง
- กฎจากประสบการณ์ของเราเอง: ระบุชัดว่าเป็นกฎภายใน ไม่ยืมป้ายของทางการมาแปะ
อย่าเอาชุดยูนิฟอร์มของ Google ไปใส่ให้ "กฎส่วนตัวของเรา" แค่นี้ก็ดีต่อสุขภาพขึ้นมากแล้ว
การออกแบบสามชั้น ให้ทั้งอ่านง่ายและยังสนุก
ข้อความในบทความจัดการง่ายขึ้นเมื่อแบ่งเป็นสามชั้น
1. โครงกระดูกของความหมาย
ข้อเท็จจริง ข้อสรุป ตัวเลข วันที่ เงื่อนไข การอ้างอิง แหล่งที่มา ความไม่แน่นอน
ตรงนี้ห้ามเล่น ถ้าในคู่มือเกมความเสียหายคือ 3 ก็ห้ามเขียนเป็น 30 เพื่อให้ตลก โลกพังก่อนเสียงหัวเราะจะมาถึง
2. ทางสู่ความเข้าใจ
หัวข้อ สรุป ลำดับ ย่อหน้า ตาราง ตัวอย่างรูปธรรม คำอธิบายศัพท์ ลิงก์ภายใน
ตรงนี้ให้ใส่ภูมิปัญญาของ Microsoft และ Google ลงไปเต็มที่ เพื่อไม่ให้ผู้อ่านต้องมาถามว่า "ตอนนี้อยู่ตรงไหน" หรือ "สรุปคืออะไร"
3. เสียงของบทความ
อุปมา มุก มุกแซว การสังเกต จังหวะ สำนวน ตัวอย่างแปลก ๆ
ถ้าตัดตรงนี้ทิ้งหมด ข้อมูลอาจถูกต้อง แต่ก็ไม่เหลือเหตุผลที่ต้องมาอ่านที่เว็บไซต์นี้โดยเฉพาะ
สิ่งสำคัญคือชั้นที่ 3 ต้องไม่ทำลายชั้นที่ 1
มุกแย่จะซ่อนความหมาย มุกดีจะทำให้จำความหมายได้ง่ายขึ้น
ตัวอย่างเช่น การพูดแค่ว่า "การจัดการสามจุดสำคัญ" ยังอ่อนอยู่
แต่ถ้าพูดว่า "มีแค่ความจำ ก็เป็นแค่ปรัชญา มีแค่ GitHub ก็เป็นแค่รัฐธรรมนูญ มีแค่ตารางเวลา ก็เป็นแค่คนงาน ต่อเมื่อทั้งสามเชื่อมกัน จึงกลายเป็นโรงงาน" ผู้อ่านก็จำความต่างของบทบาทไปพร้อมกันด้วย
มุกกำลังช่วยแบกสัมภาระของคำอธิบาย แบบนี้ถึงเรียกว่าทำงาน
ใน 12 ภาษา ไม่ต้อง "แปลมุก" แต่ให้ "แปลงานของมุก"
สิ่งที่พังง่ายที่สุดในการทำหลายภาษา คือเสียงหัวเราะ ไม่ใช่ข้อเท็จจริง
ประโยคภาษาญี่ปุ่นที่ว่า "บทความย้ายไปทำงานที่ศูนย์ช่วยเหลือ" ถ้าแปลตรง ๆ เป็นภาษาอังกฤษอาจยังพอเข้าใจได้ แต่มุกเล่นคำ มีมในอินเทอร์เน็ต มุกคำลงท้าย และมุกวัฒนธรรม มีอัตราเกิดอุบัติเหตุสูง
เหตุที่คู่มือของ Google สำหรับเอกสารเทคนิคระดับโลกเลี่ยงสำนวนและมุกที่ขึ้นกับวัฒนธรรม ก็เพื่อลดอุบัติเหตุจากการแปลแบบนี้[5]
แต่สำหรับบทความทั่วไป ทางออกไม่ใช่แค่ "ลบเสียงหัวเราะออกจากทุกภาษา"
แยกความหมายออกจากหน้าที่ของมุก
ถ้ามุกในฉบับภาษาญี่ปุ่นมีหน้าที่คลายความตึงของคำอธิบายแข็ง ๆ ภาษาอังกฤษก็ใช้คำพูดเบา ๆ ที่เป็นธรรมชาติในภาษาอังกฤษ ภาษาเกาหลีก็สร้างจังหวะหยุดที่เป็นธรรมชาติในแบบภาษาเกาหลี ภาษาจีน สเปน โปรตุเกส อินโดนีเซีย ไทย เวียดนาม ฝรั่งเศส และเยอรมัน ก็เช่นเดียวกัน
สิ่งที่ตรึงไว้: ข้อเท็จจริง ตัวเลข ตรรกะ แหล่งที่มา ความไม่แน่นอน
สิ่งที่สร้างใหม่ได้: ลำดับคำ อุปมา ตะขอเกี่ยวใจ การเปรียบเทียบ มุก จังหวะของคำอธิบาย
12 ภาษาไม่ใช่การ "แปลงภาษาญี่ปุ่น 11 รอบ" แต่ใกล้เคียงกับการ "เขียนบทความเดียวกันอย่างตั้งใจ 12 ครั้ง"
เรียกว่าเป็นการประชุมบรรณาธิการ 12 คน มากกว่าโรงงานแปล ประชุมที่มีประโยชน์จริงด้วย หายากนะ
วางกฎไว้สามจุด: ความจำ ต้นฉบับหลัก และคำสั่งดำเนินการ
ในโรงงานบทความอัตโนมัติ ตั้งกฎดี ๆ ไว้ครั้งเดียวแล้วอย่าเพิ่งวางใจ
คนเราพูดว่า "เรื่องที่เคยบอกไว้น่ะ" แล้วก็เข้าใจกันได้ แต่การประมวลผลอัตโนมัติจะทำหน้าลืมสนิทในรอบถัดไปอย่างหน้าตาเฉย
เราจึงแบ่งเป็นสามจุด
| ที่ไหน | บทบาท | ใส่อะไร |
|---|---|---|
| ความจำ | เจตนาในการบรรณาธิการระยะยาว | ทำไมถึงมีแนวทางนี้ และอะไรที่ห้ามทำพัง |
| ต้นฉบับหลัก (GitHub เป็นต้น) | กฎทางการแบบละเอียด | เงื่อนไขการตัดสิน ตัวอย่าง ขอบเขต ประวัติการแก้ไข |
| ตารางเวลาและคำสั่งดำเนินการ | การกระทำในแต่ละครั้ง | อ่านต้นฉบับหลักล่าสุดก่อนรัน อย่าให้ความสำคัญกับกฎตายตัวเก่า ๆ |
ประเด็นสำคัญคือ อย่าคัดลอกกฎยาว ๆ อันเดียวกันไปวางสามที่ จนกลายเป็น "ต้นฉบับหลักสามชุด"
ถ้ามีต้นฉบับหลักสามชุด สัปดาห์หน้าทั้งสามชุดจะพูดไม่ตรงกัน นั่นไม่ใช่วิชาโคลนนิ่ง แต่เป็นสงครามกลางเมือง
ต้นฉบับหลักของกฎละเอียดให้รวมไว้ที่เดียว ความจำเก็บเจตนา ส่วนตารางเวลาเป็นสัญญาปฏิบัติที่ว่า "ให้อ่านต้นฉบับหลักล่าสุด"
แบบนี้ปรัชญาการเขียน ข้อกำหนดทางการ และการดำเนินการแต่ละครั้งก็เชื่อมต่อกัน
การตรวจอัตโนมัติต้องดูถึง "ลบบุคลิกทิ้งหรือเปล่า"
การตรวจข้อความแบบเดิมดูคำผิด ความยาวประโยค หัวข้อ ลิงก์ และแหล่งที่มา
ถ้าตรวจแค่นั้น เมื่อปรับปรุงคุณภาพซ้ำร้อยรอบ บทความทั้งหมดอาจมีหน้าตาเหมือนกันไปหมด
ดังนั้นให้เพิ่มรายการต่อไปนี้ในการตรวจด้วย
- จับข้อสรุปได้ทันทีไหม
- ดูแค่หัวข้อ H2 ก็เห็นลำดับเรื่องไหม
- ไม่รู้ศัพท์เฉพาะก็ยังเข้าใจความหมายไหม
- แหล่งที่มา ตัวเลข และความไม่แน่นอน ไม่ถูกทำลายใช่ไหม
- การสังเกต การเปรียบเทียบ การวิเคราะห์ และประสบการณ์ที่เป็นของตัวเองยังอยู่ไหม
- มุกที่ได้ผลและอุณหภูมิความอบอุ่นในต้นฉบับ ถูกตัดทิ้งโดยไม่จำเป็นหรือเปล่า
- หลังแก้แล้วถดถอยเป็น "สรุปจาก AI ที่หาได้ทั่วไป" หรือเปล่า
- แปลมุกเดียวกันตรง ๆ ใน 12 ภาษาจนเกิดอุบัติเหตุหรือเปล่า
- เอาเกณฑ์ที่ไม่มีในคู่มือทางการมาปลอมว่าเป็น "ข้อบังคับทางการ" หรือเปล่า
นโยบายสแปมของ Google Search มองว่าเป็นปัญหาเมื่อผลิตหน้าเว็บจำนวนมากด้วย AI เชิงสร้างสรรค์ การแปล หรือการเรียบเรียงใหม่ โดยแทบไม่เพิ่มคุณค่าให้ผู้ใช้[8]
กล่าวคือ "ไวยากรณ์ถูกต้อง" เป็นแค่เส้นต่ำสุด
ต้องดูให้ได้ว่า หลังแก้แล้ว เหตุผลที่จะอ่านต่อหายไปด้วยหรือเปล่า
ตัวอย่างความล้มเหลว: สิ่งที่หุ่นยนต์ปรับปรุงข้อความมักทำ
ความล้มเหลวที่ 1: ทำให้สั้นหมด
แยกประโยคยาวทั้งหมดจนทำลายสายสัมพันธ์ของความหมายไปด้วย วิธีแก้คือ ไม่ดูที่ "ความสั้น" แต่ดูว่าอ่านรอบเดียวแล้วเข้าใจความสัมพันธ์ไหม
ความล้มเหลวที่ 2: ใช้โครงประโยคเดียวกันหมด
ตรึงทุกย่อหน้าให้อยู่ในลำดับเดียวกันและจังหวะเดียวกัน วิธีแก้คือ จัดลำดับข้อมูลให้เรียบร้อย แต่อย่าใส่ยูนิฟอร์มให้จังหวะด้วย
ความล้มเหลวที่ 3: ตัดสินว่าอารมณ์ขันเป็นสัญญาณรบกวน
ลบอุปมาและมุกแซวทั้งหมด วิธีแก้คือ เก็บมุกที่ช่วยให้เข้าใจไว้ และตัดเฉพาะการออกนอกเรื่องที่เป็นอุปสรรค
ความล้มเหลวที่ 4: คิดว่าเขียนแบบ Google คือ SEO
สับสนระหว่างสไตล์เอกสารสำหรับนักพัฒนากับคุณภาพการค้นหา วิธีแก้คือ ปฏิบัติต่อคู่มือสไตล์ คุณภาพการค้นหา การเข้าถึง และการปรับให้เข้ากับท้องถิ่น เป็นคนละชั้นกัน
ความล้มเหลวที่ 5: สร้างตัวเลขขึ้นมาเอง
เรียกตัวเลขที่ไม่มีในแหล่งที่มาว่า "มาตรฐานของ Google" วิธีแก้คือ ถ้าเป็นกฎจากประสบการณ์ภายในก็ให้ระบุอย่างนั้น
เช็กลิสต์สุดท้าย: ทำให้อ่านง่ายขึ้นแล้ว ก็อย่าหยุดส่งความเป็นมนุษย์
- เข้าใจหัวข้อและข้อสรุปได้ใน 5 วินาที
- จับภาพรวมได้ใน 30 วินาที
- ดูแค่ H2 ก็เห็นลำดับเรื่อง
- เข้าใจได้ด้วยคำธรรมดา
- ชื่อทางการ ตัวเลข และแหล่งที่มาถูกต้อง
- ข้อความยาวก็ไม่หลงทาง
- มีคุณค่าที่เป็นของตัวเอง
- มุกช่วยให้คำอธิบายเข้าใจง่ายขึ้น
- มุกไม่ทำลายข้อเท็จจริง
- ปรับ "หน้าที่" ของมุกให้เข้ากับท้องถิ่นใน 12 ภาษาแล้ว
- ไม่ปะปนระหว่างข้อบังคับทางการ ข้อแนะนำทางการ และกฎภายใน
- แม้หลังแก้อัตโนมัติ ก็ยังเหลือเหตุผลที่จะมาอ่านที่เว็บไซต์นี้
คู่มือทางการนั้นทรงพลัง ก็เพราะอย่างนั้นจึงไม่ควรกลืนทั้งก้อน
จาก Microsoft ให้ยืม "การออกแบบที่ไม่ทำให้หลงทาง" จากคู่มือเอกสารของ Google ให้ยืม "ความชัดเจนและการออกแบบเพื่อคนทั่วโลก" จาก Google Search ให้ยืม "เนื้อหาเพื่อผู้คน คุณค่าที่เป็นต้นฉบับ และความน่าเชื่อถือ"
แล้วเสียงของเว็บไซต์ ให้เก็บไว้เอง
การยกระดับคุณภาพของงานเขียน ไม่ใช่การใส่ยูนิฟอร์มให้ข้อความ แต่คือการจัดระเบียบเฉพาะจุดที่ผู้อ่านหลงทาง และเก็บส่วนที่ความสนุกกำลังทำงานอยู่เอาไว้
ราวกันตกนั้นจำเป็น แต่ถ้าเปลี่ยนทั้งถนนให้เป็นราวกันตก ก็ขับไม่ได้อีกแล้ว
