คู่มือเครื่องบินปี 1986 ที่ Karpathy แนะให้ใช้สั่ง AI

โดย Nokka (นก-กา) | 3 ตุลาคม 2026

บทความนี้เขียนโดย AI (deepseek-v4.1-flash) ผ่าน Hermes Agent ตรวจสอบและเรียบเรียงโดย Nokka

Andrej Karpathy โพสต์ข้อความสั้น ๆ เมื่อวันที่ 2 ตุลาคม 2026 [1]

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

เราจะใช้เวลากับการทำความเข้าใจผลลัพธ์ของโมเดลภาษามากขึ้นอีกเยอะ [1]

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

แต่พองานที่ AI ทำมากขึ้น สิ่งที่เราต้องทำก็ย้ายที่

จาก "ลงมือทำ" ไปเป็น "อ่านให้เข้าใจว่าเครื่องทำอะไรลงไป"

Karpathy เรียกจุดนี้ว่า oversight หรือการกำกับดูแล [1] และเขาให้เทคนิค 4 ระดับในการอ่านงานของ AI เรียงจากธรรมดาไปถึงขั้นที่เขาเชื่อมั่นที่สุด

ตัวเลขของโพสต์นี้บอกว่าคนสนใจแค่ไหน ณ วันที่ผมอ่าน มีไลก์กว่า 40,417 ครั้ง รีโพสต์ 4,457 ครั้ง และวิว 4.3 ล้านครั้ง [1]

แต่ที่ผมสนใจไม่ใช่ตัวเลข มันคือระดับแรกของเขา ซึ่งเอาเทคนิคจากคู่มือซ่อมเครื่องบินมาใช้กับ AI

ภาพแนวคิด: ความรู้จากคู่มือเครื่องบินเก่ากลายเป็นไดอะแกรมที่อ่านเข้าใจได้บนจอ

ระดับที่ 1: สั่งให้ AI เขียนแบบคู่มือเครื่องบิน

Karpathy เขียนว่าเขาลองวิธีนี้แล้วได้ผล คือสั่งให้ LLM อธิบายเรื่องอะไรก็ได้ ด้วยมาตรฐานชื่อ ASD-STE100 [1]

ASD ย่อมาจาก Aerospace, Security and Defence Industries Association of Europe ตามที่สมาคมเขียนชื่อตัวเองในเอกสารทางการของมาตรฐาน ซึ่งเป็นเจ้าของมาตรฐานนี้ ตัว STE ย่อมาจาก Simplified Technical English หรือ "ภาษาอังกฤษเทคนิคแบบง่าย" [14]

มันคือภาษาควบคุม (controlled language) ที่จำกัดคำและโครงสร้างประโยคไว้ตายตัว เกิดจากคำร้องขอของสายการบินในยุโรปสมัยทศวรรษ 1970 [2]

เหตุผลตอนนั้นตรงไปตรงมา สายการบินในยุโรปกว่า 80 เปอร์เซ็นต์ไม่ใช่เจ้าของภาษาอังกฤษ [2] แต่คู่มือซ่อมเครื่องบินเขียนเป็นภาษาอังกฤษ ช่างที่ต้องอ่านคู่มืออาจไม่ใช่คนที่อ่านภาษาอังกฤษคล่อง

ถ้าอ่านคำสั่งผิดตอนซ่อมเครื่องบิน ผลที่ตามมาไม่ใช่เรื่องทำงานช้า

เรื่องนี้จึงถูกวางเป็นมาตรฐานความปลอดภัย ไม่ใช่คำแนะนำเรื่องสไตล์การเขียน

ไทม์ไลน์ของมาตรฐานนี้

• ปลายทศวรรษ 1970 คณะทำงาน AECMA เริ่มศึกษาเรื่องภาษาอังกฤษแบบควบคุมให้สายการบิน [2][3]
• 1983 AECMA ตัดสินใจสร้างมาตรฐานของตัวเอง หลังสำรวจว่าในอุตสาหกรรมอื่นมีภาษาอะไรใช้อยู่แล้วบ้าง [3]
• 1985-1986 เอกสารฉบับแรกออกใช้ในชื่อ AECMA Simplified English Guide [2][3]
• 2004 AECMA รวมกับอีกสองสมาคม กลายเป็น ASD และชื่อมาตรฐานเปลี่ยนจาก AECMA Simplified English เป็น ASD Simplified Technical English ส่วนสถานะขยับจาก "คู่มือ" เป็น "ข้อกำหนด" โดยเอกสารทางการฉบับ Issue 9 ของ ASD ระบุปีลิขสิทธิ์ชุดใหม่ว่าเริ่มที่ 2005 [14]
• 2013 มาตรฐานเปิดให้ดาวน์โหลดฟรีตั้งแต่ Issue 6 เป็นต้นมา [3]
• มกราคม 2025 Issue 9 ออกใช้ พร้อมสถานะใหม่เป็น "มาตรฐานระหว่างประเทศ" [2]

มีจุดที่ผมต้องบอกตรง ๆ เรื่องวันที่ในบรรทัดแรก ๆ

เอกสารทางการของ ASD เขียนว่าเอกสารฉบับแรกออกใช้ปี 1986 [2] แต่ Wikipedia เขียนว่าเอกสารรหัส PSC-85-16598 ออกใช้ปี 1985 [3] และหลายแหล่งที่พูดถึงมาตรฐานนี้ในบริบท AI ใช้คำว่า "ตั้งแต่ปี 1983" [5]

ผมตรวจแล้วพบว่าตัวเลขที่ต่างกันนี้มาจากคนละเหตุการณ์ 1979 คือปีที่เริ่มศึกษา 1983 คือปีที่ตัดสินใจทำ 1985 และ 1986 คือปีที่เอกสารออกใช้ ซึ่งสองแหล่งรายงานต่างกันหนึ่งปี

ในบทความนี้ผมยึดเอกสารทางการของ ASD เป็นหลัก แล้วกำกับปีอื่นไว้ให้เห็นที่มา

กฎที่ทำให้ข้อความอ่านง่ายขึ้นจริง

โครงสร้างของ ASD-STE100 มีสองส่วน [2]

ส่วนแรกคือกฎการเขียน 53 ข้อ แบ่งเป็น 9 หมวด ครอบคลุมการเลือกคำ ไวยากรณ์ โครงสร้างประโยค และสไตล์ [2]

ส่วนที่สองคือพจนานุกรม ซึ่งมีคำที่อนุมัติให้ใช้ประมาณ 900 คำ แต่ละคำมีความหมายเดียวและทำหน้าที่ทางไวยากรณ์ได้อย่างเดียว [2]

ในพจนานุกรมยังมีรายการคำที่ไม่อนุมัติให้ใช้อีกประมาณ 1,200 คำ พร้อมคำทดแทนที่เสนอไว้ให้ [2]

ตัวอย่างที่คนพูดถึงกันบ่อยคือคู่นี้ ผมดึงจากพจนานุกรมทางการฉบับ Issue 9 มาตรวจเองทีละคู่ [14]

• commence ไม่อนุมัติ ให้ใช้ start
• ensure ไม่อนุมัติ ให้ใช้ make sure
• prior to ไม่อนุมัติ ให้ใช้ before
• replenish ไม่อนุมัติ ให้ใช้ fill
• utilize ไม่อนุมัติ ให้ใช้ use
• about ที่หมายถึงปริมาณ ไม่อนุมัติ ให้ใช้ approximately (ตัวอย่างในพจนานุกรม: DRAIN APPROXIMATELY 2 LITERS OF FUEL)
• in order to ไม่อนุมัติ ให้ใช้ to
• close ที่แปลว่า "ใกล้" ไม่อนุมัติ ให้ใช้ near

ข้อสุดท้ายนี้ผมว่าฉลาด คำว่า close ถูกอนุมัติให้ใช้ได้ในฐานะคำกริยาความหมายเดียวคือ "ปิด" เท่านั้น ถ้าอยากสื่อว่า "ใกล้" ต้องใช้ near [3]

นี่คือหลัก "หนึ่งคำ หนึ่งความหมาย หนึ่งหน้าที่" ที่บังคับใช้จริง ไม่ได้เป็นเพียงคำขวัญ

กฎด้านประโยคที่สำคัญกับงาน AI

• ประโยคคำสั่ง (procedure) ยาวได้ไม่เกิน 20 คำ ส่วนประโยคบรรยาย (descriptive) ยาวได้ไม่เกิน 25 คำ [3]
• ย่อหน้าหนึ่งมีได้ไม่เกิน 6 ประโยค และมีได้หัวข้อเดียว [3]
• กลุ่มคำนามซ้อนกันได้ไม่เกิน 3 คำ [8]
• ใช้กริยาได้เฉพาะรูป infinitive, imperative, present, past, future และ past participle ที่ทำหน้าที่เป็นคำคุณศัพท์ [3]
• ห้ามใช้กริยา -ing ยกเว้นในฐานะคำนามเทคนิคอย่าง "landing gear" [3]
• ใช้รูปกริยาช่วยสร้างโครงสร้างซับซ้อนไม่ได้ [3]
• ในคำสั่งให้ใช้ประโยคที่ประธานเป็นผู้กระทำ (active voice) [3]
• ห้ามตัดคำอย่าง "the", "a", "this" ออกเพื่อให้ข้อความสั้นลง [3]
• หนึ่งประโยคมีหนึ่งคำสั่ง (ยกเว้นงานที่ทำพร้อมกันจริง) [3]
• คำเตือนความปลอดภัยต้องขึ้นต้นด้วยคำสั่งหรือเงื่อนไขที่ชัดเจน [3]

ถ้าอ่านรายการนี้แล้วรู้สึกว่ามันคือรายการเดียวกับที่คนบ่นว่า AI เขียนไม่ดี นั่นคือประเด็น

ทำไมมาตรฐานซ่อมเครื่องบินถึงเข้ากับงาน AI

Karpathy อธิบายสั้น ๆ ว่ามาตรฐานนี้มาพร้อม "ข้อจำกัดหนัก ๆ ด้านสไตล์การเขียนที่สะอาด" ซึ่งเขามักพบว่าอ่านง่ายขึ้นมาก [1]

เขายังบอกต่อว่าตัวมาตรฐานเข้มงวดพอสมควร บางครั้งเขาจึงสั่งแบบผ่อนลง เช่นขอ "80 เปอร์เซ็นต์ของ ASD-STE100" [1]

มีคนทดลองตามแล้วได้ผลคล้ายกัน Kun Chen เขียนว่าเขาเพิ่งทดลองใช้กฎเรื่องถ้อยคำของ ASD-STE100 แล้วพบว่าช่วยเพิ่มความชัดเจนของคำตอบได้อย่างน่าประหลาดใจ แม้ในผลลัพธ์ที่เป็น HTML แต่ตัวกฎทั้งชุดเข้มเกินไปนิดหนึ่ง ต้องเลือกใช้เป็นบางส่วน [13]

ผมคิดว่าคำว่า "80 เปอร์เซ็นต์" ของ Karpathy คือส่วนที่คนมองข้ามมากที่สุดในโพสต์นี้

มันคือคำยอมรับว่ามาตรฐานเต็มรูปแบบถูกออกแบบมาเพื่อบริบทที่ความผิดพลาดมีราคาสูงมาก ไม่ใช่เพื่อให้คนอ่านบทความสบายขึ้น

ส่วนที่ผมคิดว่าน่าสนใจกว่าคือข้อสังเกตของคนที่ทำสกิลสำหรับมาตรฐานนี้แยกกัน

ทีมหนึ่งทำสกิลเพื่อใช้กับ "เอเจนต์ที่อ่านผลลัพธ์ของเอเจนต์อีกตัว" ไม่ใช่กับคน [6]

เหตุผลที่เขาให้คือ เอเจนต์ที่อ่านข้อความของเอเจนต์อีกตัวอยู่สถานการณ์เดียวกับช่างซ่อมเครื่องบิน คือไม่สามารถถามกลับได้ว่า "ที่เขียนมาหมายถึง A หรือ B" [6]

ไม่มีการถามย้อนกลับ ไม่มีคนให้คำอธิบายเพิ่ม มีแค่ข้อความที่ต้องตีความให้ถูก

นั่นทำให้กฎเรื่องความกำกวมกลายเป็นเรื่องของความถูกต้อง ไม่ใช่เรื่องของรสนิยม

ระดับที่ 2: ไดอะแกรม

Karpathy เขียนต่อว่า ถ้าไม่ต้องเขียน ขอให้ LLM ทำไดอะแกรมดีกว่า เพราะมัน "ประมวลผล แยกวิเคราะห์ และทำความเข้าใจได้ง่ายกว่าเยอะ" [1]

ผมเห็นด้วยแบบมีเงื่อนไข

ไดอะแกรมชนะข้อความเมื่อคำตอบมีโครงสร้าง ไม่ว่าจะเป็นส่วนประกอบกับการไหลของข้อมูล สถานะกับการเปลี่ยนผ่าน ลำดับเวลา หรือลำดับชั้น [8]

แต่ไดอะแกรมแย่กว่ามากเวลาคำตอบเป็นการโต้แย้งที่ต้องแยกแยะ กล่องกับลูกศรที่วาดคำว่า "แล้วแต่กรณี" ไม่ได้บอกอะไรกับใครเลย [8]

ระดับที่ 3: หน้าจอ HTML

ระดับที่สามคือขอดูผลลัพธ์ "ในรูปแบบ HTML" เพื่อให้ได้หน้าเว็บแบบโต้ตอบได้ [1]

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

เรื่องนี้มีต้นทางที่ชัดเจน ก่อน Karpathy โพสต์ครั้งนี้ เขาเคยแชร์โพสต์ของ Thariq Shihipar สมาชิกทีม Claude Code ของ Anthropic เมื่อเดือนพฤษภาคม 2026 [4]

ส่วนบทความฉบับเต็มที่ Shihipar เขียนเอง เผยแพร่ที่บล็อกของ Claude เมื่อวันที่ 20 พฤษภาคม 2026 โดยหน้าบทความระบุตำแหน่งของเขาว่าเป็นสมาชิกฝ่ายเทคนิคของบริษัท [7]

บทความนั้นชื่อ "Using Claude Code: The unreasonable effectiveness of HTML" อธิบายว่าทำไมทีม Claude Code จึงเลือกใช้ HTML แทน Markdown ในการสื่อสารระหว่างคนกับเอเจนต์ [7]

เหตุผลที่ทีมนั้นให้ไว้มี 5 ข้อ [7]

• ความหนาแน่นของข้อมูล HTML แสดงตาราง กราฟิก SVG โค้ด และภาพได้ในหน้าเดียว ขณะที่ Markdown ทำได้แค่โครงสร้างเอกสารพื้นฐาน [7]
• อ่านง่ายกว่า เขียนว่า "ผมไม่ค่อยอ่านไฟล์ Markdown ที่ยาวเกิน 100 บรรทัด และชวนคนอื่นในองค์กรให้อ่านก็ไม่ได้" [7]
• แชร์ง่ายกว่า ไฟล์ Markdown เปิดในเบราว์เซอร์ไม่ค่อยขึ้นรูป ต้องแนบไปกับอีเมลหรือแชท แต่ HTML อัปโหลดแล้วได้ลิงก์เปิดได้เลย [7]
• โต้ตอบได้สองทาง ขอให้ใส่สไลเดอร์หรือปุ่มให้ลองปรับค่า แล้วคัดลอกผลลัพธ์กลับไปวางใน prompt ได้ [7]
• ดูดข้อมูลบริบทได้ เพราะ Claude Code อ่านไฟล์ในเครื่อง ประวัติ git และเครื่องมือ MCP ของคุณได้หมด [7]

ข้อสุดท้ายนี้เป็นเหตุผลว่าทำไมเรื่องนี้ถึงเป็นเรื่องของ coding agent โดยเฉพาะ ไม่ใช่เรื่องของหน้าจอแชททั่วไป

ระดับที่ 4: วิดีโออธิบาย

ระดับที่ Karpathy บอกว่าเขามั่นใจที่สุด คือวิดีโออธิบายที่สร้างขึ้นเฉพาะเรื่อง [1]

ตัวอย่าง prompt ที่เขาให้ไว้คือ ขอให้สร้างวิดีโออธิบายสไตล์ 3b1b ในหัวข้อ X และใช้คีย์ ElevenLabs สำหรับเสียงบรรยาย [1]

3b1b คือช่อง 3Blue1Brown ที่ทำวิดีโอคณิตศาสตร์ด้วยภาพเคลื่อนไหว และ ElevenLabs เป็นบริการสังเคราะห์เสียงแบบเสียเงิน [1][4]

เขาปิดท้ายด้วยการบอกทางเลือกสำหรับคนไม่มีคีย์ คือสั่งให้ LLM หาเครื่องมือฟรีที่ดีพอ ที่รันบนเครื่องตัวเองแทนได้ [1]

และประโยคที่ผมคิดว่าสำคัญที่สุดของระดับนี้คือ "อันนี้เริ่มใช้ได้จริงแล้ว" [1]

มีโปรเจกต์โอเพนซอร์สที่ทำเรื่องนี้อยู่จริง และตัวเลขของมันน่าติดตาม

โปรเจกต์ชื่อ paper2video รับบทความหรือไฟล์ PDF แล้วแปลงเป็นวิดีโออธิบายความยาว 2 ถึง 5 นาที ใช้ Manim เรนเดอร์ภาพ ใช้ Kokoro สังเคราะห์เสียง แล้วรวมด้วย ffmpeg [9]

ตัวอย่างในหน้าโปรเจกต์คือวิดีโอ 3 นาทีที่อธิบายบันทึกความรู้ของ Karpathy เอง สร้างเสร็จในเวลาไม่ถึง 5 นาที ด้วยค่าใช้จ่ายประมาณ 5 เซนต์ [9]

มีอีกโปรเจกต์ที่ไปทางอื่น คือไม่ใช้โมเดลจ่ายเงินเลย ใช้เสียงจาก Edge TTS ของไมโครซอฟต์ บันทึกหน้าเว็บด้วย Chromium แบบไม่แสดงหน้าต่าง แล้วรวมเสียงด้วย ffmpeg [10]

แต่มีข้อที่ต้องบอก

โปรเจกต์หลังนี้มี commit แรกและ commit สุดท้ายเป็นวันเดียวกันคือ 27 พฤษภาคม 2026 [10]

คือผ่านมาแล้ว 4 เดือนกว่าโดยที่ไม่มี commit ใหม่ ผมไม่รู้ว่าเจ้าของตั้งใจหยุดหรือแค่ยังไม่กลับมา แต่จำนวนดาว 19 ดวงไม่บอกเรื่องนี้เลย

เครื่องมือที่ลองได้วันนี้

ถ้าจะเริ่มจากระดับที่ 1 ซึ่ง Karpathy ใช้จริงและเป็นระดับที่ตั้งค่าง่ายที่สุด มีสกิลโอเพนซอร์สให้เลือกอยู่หลายตัว [4]

• SimpleEnglish โดย AminBlg มีดาว 3,665 ดวง ฟอร์ก 135 สัญญาอนุญาต MIT เปิดตัว 21 กรกฎาคม 2026 และมี commit ล่าสุด 30 กันยายน 2026 [5]
• asd-ste100-skill โดย danyuchn มีดาว 2,809 ดวง ฟอร์ก 158 สัญญาอนุญาต MIT เปิดตัว 20 กรกฎาคม 2026 commit ล่าสุด 8 กันยายน 2026 [6]

ทั้งสองตัวติดตั้งผ่านตัวจัดการสกิลมาตรฐานได้ โดยตัวของ AminBlg เขียนไว้ชัดว่าเป็นโปรเจกต์ที่ไม่เป็นทางการ ไม่ได้เกี่ยวข้องหรือได้รับการรับรองจาก ASD หรือ STEMG และ ASD-STE100 เป็นเครื่องหมายการค้าจดทะเบียนของ ASD [5]

ตัวของ danyuchn ไม่ได้ใช้ถ้อยแบบเดียวกัน แต่ระบุเหตุผลด้านลิขสิทธิ์ว่ามาตรฐานฉบับ Issue 9 อนุญาตให้ทำซ้ำได้เฉพาะกับองค์กร 8 ประเภทที่ระบุไว้ ซึ่งโปรเจกต์นี้ไม่เข้าข่าย [6]

ตัวของ danyuchn มีจุดที่ผมชอบ คือเขาแยกเป็นสองโหมด [6]

โหมดเข้มงวดสำหรับคำสั่ง ข้อความข้อผิดพลาด และคำอธิบายเครื่องมือ ส่วนโหมดผ่อนสำหรับ README คำอธิบาย PR และงานเขียนเชิงอธิบาย โดยโหมดผ่อนยังคงวินัยเรื่องประโยคไว้ แต่ไม่ล็อกคำศัพท์ตายตัว [6]

และเขาบอกตรง ๆ ว่าไม่ได้ทำพจนานุกรม 900 คำของ ASD มาด้วย เพราะลิขสิทธิ์เปิดให้ทำได้เฉพาะกับองค์กร 8 ประเภทที่ระบุไว้ ซึ่งโปรเจกต์นี้ไม่เข้าข่าย [6]

ผมว่าความซื่อตรงข้อนี้ทำให้สกิลน่าเชื่อถือกว่าตัวเลขดาว

ตัวเลขที่ควรอ่านให้ครบ

สกิลตัวหนึ่งรายงานว่า ทำให้ข้อผิดพลาดต่อ 100 คำ ลดลง 72.9 เปอร์เซ็นต์ เฉลี่ยจากการทดสอบ 6 โมเดล กับงานเขียน 8 แบบ รวม 96 ครั้ง [12]

แต่เจ้าของโปรเจกต์เองเขียนไว้ในหน้า README ว่า ตัวเลขชุดที่เคยรายงานว่า "ลดลง 81.3 เปอร์เซ็นต์ จาก 9 โมเดล" นั้น วัดการเชื่อฟังกฎ ไม่ได้วัดสิ่งที่ผู้อ่านเห็น [5]

หลังทราบปัญหานี้ เขาจึงเปลี่ยนไปรายงานตัวเลขอีกชุด คือจำนวนข้อบกพร่องที่มองเห็นได้ในคำตอบลดลง 95 เปอร์เซ็นต์ จาก 218 เหลือ 11 จุด [5]

ตัวเลขนี้มาจากการทดลองเมื่อวันที่ 2 กันยายน 2026 ซึ่งยังใช้สกิลเวอร์ชัน 2.0.1 ที่มีการจำกัดความยาวคำตอบไม่เกิน 5 ประโยค ซึ่งเวอร์ชัน 2.1.0 ตัดข้อจำกัดนั้นออกแล้ว [5]

เจ้าของโปรเจกต์เขียนเองว่า ยังไม่มีการทดลองซ้ำกับเวอร์ชัน 2.1.0 หรือใหม่กว่า [5]

ผมเล่าเรื่องนี้เพราะมันคือตัวอย่างของการอ่านตัวเลข benchmark ให้ครบ ไม่ได้มีไว้ลดทอนผลงานของเขา

การที่เจ้าของโปรเจกต์เป็นคนออกมาเตือนว่า ตัวเลขที่ตัวเองเคยโปรโมตไม่ตรงกับสิ่งที่ควรวัด น่าชื่นชมกว่าตัวเลขเอง

สิ่งที่โพสต์ไม่ได้บอก

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

หนึ่ง: มาตรฐานนี้ไม่ได้ออกแบบมาสำหรับงานเขียนทั่วไป

เอกสารทางการของ ASD-STE100 ระบุเองว่า STE ไม่ได้มีไว้ทดแทนคู่มือสไตล์การเขียน และควรใช้ร่วมกับข้อกำหนดอื่นที่เกี่ยวข้อง [14]

คำเตือนนี้อยู่ในหน้าคำถามที่พบบ่อย ไม่ได้อยู่ในโพสต์

หลักการบางข้ออย่างประโยคสั้น หัวข้อเดียวต่อประโยค และการใช้ประโยคที่ประธานเป็นผู้กระทำ ย้ายมาใช้กับงานเขียนทั่วไปได้ แต่ตัวมาตรฐานทั้งฉบับไม่ใช่ชุดคำแนะนำการเขียนบทความ [4]

สอง: คำสั่งเรื่องสไตล์อาจเปลี่ยนวิธีคิดของโมเดล ไม่ได้เปลี่ยนแค่คำพูด

มีข้อโต้แย้งที่ผมเห็นว่าจริง ว่าคำสั่งเรื่องสไตล์ที่วางไว้ใน prompt เดียวกับงาน จะส่งผลต่อวิธีคิดของโมเดล ไม่ได้ส่งผลแค่คำที่ออกมาท้ายสุด [8]

ถ้าเทียบกับการบีบอัดข้อมูล การบีบอัดที่ทำระหว่างทางย่อมสูญเสียบางอย่าง

ทางแก้ที่บทความนั้นเสนอคือแยกงานออกจากกัน ให้เอเจนต์ทำงานในโหมดปกติก่อน แล้วค่อยรันรอบที่สองเพื่อเขียนผลลัพธ์ใหม่ให้อ่านง่าย [8]

ผมว่าวิธีนี้เข้ากับสิ่งที่ Karpathy พูดมากกว่าการสั่งสไตล์ตั้งแต่ต้น

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

สาม: มาตรฐานดิบอ่านเหมือนการ์ดซ่อมเครื่องบิน

เพราะแบบนี้เอง Karpathy จึงต้องผ่อนลงมาเป็น "80 เปอร์เซ็นต์" [1]

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

ถ้าคุณเขียนบล็อกหรือคอนเทนต์ที่ต้องมีน้ำเสียง อย่าใช้มาตรฐานเต็ม

สี่: มาตรฐานนี้มีหลายเวอร์ชัน และเปลี่ยนได้

ฉบับปัจจุบันคือ Issue 9 เดือนมกราคม 2025 ซึ่งปรับกฎการเขียนเกินครึ่ง และแก้รายการในพจนานุกรม 555 รายการ [2]

เท่าที่ผมอ่านเอกสารที่พูดถึงมาตรฐานนี้ หลายฉบับเขียนว่า "กฎ 53 ข้อ" โดยไม่บอกว่าอ้าง Issue ไหน ซึ่งสำคัญเพราะกติกาบางข้อถูกเขียนใหม่ในฉบับหลัง ๆ [2]

ห้า: ผมยังไม่ได้ทดลองกับงานจริงของตัวเอง

ผมอ่านสกิลทั้งสองตัวและเปิดดูโครงสร้างกฎของมัน แต่ยังไม่ได้ติดตั้งและใช้งานกับงานเขียนจริงของผม

งานที่ผมทำได้รอบนี้คืออ่านเอกสารต้นทางและรายงานว่าใครอ้างอะไรไว้บ้าง ซึ่งไม่เท่ากับการทดลองใช้

หก: จำนวนดาวไม่บอกว่าซอฟต์แวร์ยังมีชีวิตอยู่ไหม

ผมเจอเคสนี้มาแล้วกับโปรเจกต์อื่น และรอบนี้ก็เจออีกครั้งกับสกิลวิดีโอที่ commit หยุดไปตั้งแต่พฤษภาคม [10]

ก่อนติดตั้งอะไร ให้เปิดดูวันที่ commit ล่าสุดก่อนเสมอ ใช้เวลาไม่ถึงหนึ่งนาที

เรื่องภาษาไทยที่โพสต์นี้ไม่ได้พูดถึง

Karpathy เขียนถึงภาษาอังกฤษ และ STE คือภาษาอังกฤษแบบควบคุม

ภาษาไทยยังไม่มีมาตรฐานแบบนี้

มีคนทำสกิลสำหรับสอน AI เขียนภาษาไทยอยู่ ชื่อ kien-thai มีดาว 79 ดวง สัญญาอนุญาต MIT [11]

เจ้าของโปรเจกต์เขียนไว้ในหน้าแรกของ repo ประโยคที่ผมอ่านแล้วพยักหน้า

ภาษาไทยที่ AI สร้างมีกลิ่น [11]

แล้วเขาอธิบายกลไกต่อว่า ปัญหาไม่ได้อยู่ที่ AI ไม่รู้ภาษา แต่มาจากข้อมูลฝึกที่เอียงไปทางภาษาราชการและการแปลตรงตัวจากภาษาอังกฤษ [11]

ผลที่ได้คือประโยคยาว ๆ ที่ต่อกันด้วยคำว่า "ซึ่ง" กับ "โดย" ลงท้ายด้วย "ครับ" ทุกประโยค และขึ้นต้นด้วย "ในยุคปัจจุบัน" ทุกบทความ [11]

ผมทำงานเขียนบทความภาษาไทยทุกวัน และเจออาการนี้ตลอด

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

ความต่างคือ มาตรฐานนี้ผ่านการประชุมทำงานของคณะดูแลมากกว่า 90 ครั้ง ใน 13 ประเทศ มาเกือบ 40 ปี [2]

รายการของผมมาจากการนั่งแก้บทความของตัวเองซ้ำ ๆ

ผมว่าอันนี้คือช่องว่างที่มีคนทำได้ และน่าจะมีคนทำอยู่ตอนนี้

แล้วควรเริ่มจากตรงไหน

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

• เริ่มจากระดับที่ 3 คือขอ HTML ก่อน เพราะได้ผลชัดที่สุดและไม่ต้องตั้งค่าอะไรเลย [8]
• ถ้าจะลองระดับที่ 1 ให้เริ่มจากโหมดผ่อนของสกิล แล้วค่อยปรับความเข้มขึ้นตามงาน [6]
• ถ้าจะลองระดับที่ 4 ให้เริ่มจากโปรเจกต์ที่ใช้เสียงฟรี ไม่ต้องใช้คีย์ก่อน แล้วค่อยอัปเกรดเสียงถ้าติดใจ [10]
• ก่อนติดตั้งสกิลใด ให้เปิดดูวันที่ commit ล่าสุดก่อนเสมอ [10]

ลองแบบนี้ได้เลย

ผมรวบ prompt ตามสี่ระดับมาไว้ให้คัดลอกไปใช้ได้ทันที โดยปรับจากตัวอย่างของ Karpathy เองและจากสกิลที่เขาอ้างถึง

ระดับที่ 1 สั่งให้เขียนแบบคู่มือเครื่องบิน

อธิบาย [หัวข้อ] ด้วยสไตล์ ASD-STE100 ประมาณ 80 เปอร์เซ็นต์
ใช้ประโยคสั้น หนึ่งความคิดต่อประโยค ใช้กริยารูปธรรมดา
ใช้คำที่อนุมัติแล้วเท่านั้น ถ้ามีศัพท์เทคนิคใหม่ ให้อธิบายครั้งเดียวแล้วใช้คำเดิมตลอด

คำสำคัญคือ "ประมาณ 80 เปอร์เซ็นต์" เพราะมาตรฐานเต็มรูปแบบอ่านเหมือนการ์ดซ่อมเครื่องบิน [1]

ระดับที่ 2 ขอไดอะแกรมแทนคำอธิบาย

วาดสถาปัตยกรรมนี้เป็นไดอะแกรม SVG แสดงทิศทางการไหลของข้อมูลด้วยลูกศรมีหมายเลข
ติดป้ายกล่องทุกใบ และระบุว่าแต่ละส่วนรับอะไรเข้าและส่งอะไรออก

ใช้เมื่อคำตอบมีโครงสร้างเป็นส่วนประกอบกับเส้นทาง ถ้าเป็นข้อโต้แย้งที่ต้องแยกแยะ ไดอะแกรมจะไม่ช่วย [8]

ระดับที่ 3 ขอผลลัพธ์เป็นหน้าเว็บ

ทำไฟล์ HTML ไฟล์เดียวที่อธิบาย [เรื่อง] ให้ฉันอ่าน
มีสารบัญด้านข้าง แท็บแยกหัวข้อ และแผนภาพประกอบ
ทำให้อ่านบนมือถือได้ด้วย

ระดับที่ 4 ขอวิดีโออธิบาย

สร้างวิดีโออธิบายสไตล์ 3b1b เรื่อง [หัวข้อ]
ให้ตัวโมเดลหาเสียงบรรยายจากเครื่องมือฟรีที่รันบนเครื่องนี้ได้

ถ้ามีคีย์ ElevenLabs จะระบุไปใน prompt แทนได้ ตามตัวอย่างที่ Karpathy ให้ไว้ [1]

ส่วนประโยคปิดของ Karpathy ผมคิดว่าเป็นประโยคที่คนควรอ่านซ้ำ

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

งานแบบนี้เคยไม่คุ้มค่าที่จะทำ ไม่มีใครจ้างทีมทำวิดีโออธิบาย 3 นาทีเพื่อตอบคำถามข้อเดียว

แต่เมื่อต้นทุนการสร้างเหลือเกือบศูนย์ สมการมันพลิกทั้งสมการ [1]

ชิ้นงานเหล่านี้ไม่ได้มีไว้ดูแลรักษา มันมีไว้เพื่อย้ายความเข้าใจจากหน้าจอเข้าไปในหัวคุณ แล้วก็ทิ้งได้

และนั่นทำให้คำถามที่ควรถามเปลี่ยนไปด้วย

ไม่ใช่ "ผมจะประหยัดเวลาได้ไหม" แต่เป็น "ผมจะเข้าใจมันจริงไหม"

---

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

แหล่งอ้างอิง

[1] Andrej Karpathy, "We'll be spending a lot more time trying to understand the outputs of language models...", X (Twitter), 2 ตุลาคม 2026. https://x.com/karpathy/status/2105819303471976479

[2] ASD, "About ASD-STE100 Simplified Technical English", asd-ste100.org, 2026. https://www.asd-ste100.org/about_STE.html

[3] Wikipedia, "Simplified Technical English", 2026. https://en.wikipedia.org/wiki/Simplified_Technical_English

[4] Search Engine Journal, "OpenAI Founding Member: Make LLMs Write Like An Aircraft Manual", 2 ตุลาคม 2026. https://www.searchenginejournal.com/karpathy-llm-aircraft-manual-writing/591813/

[5] AminBlg, "SimpleEnglish - Agent skill: make LLMs write docs in ASD-STE100 Simplified Technical English", GitHub, 2026. https://github.com/AminBlg/SimpleEnglish

[6] danyuchn, "asd-ste100-skill - ASD-STE100 Simplified Technical English rules", GitHub, 2026. https://github.com/danyuchn/asd-ste100-skill

[7] Thariq Shihipar, "Using Claude Code: The unreasonable effectiveness of HTML", Claude Blog, 20 พฤษภาคม 2026. https://claude.com/blog/using-claude-code-the-unreasonable-effectiveness-of-html

[8] explainx.ai, "Karpathy on Understanding LLM Output: 4 Formats Ranked", ตุลาคม 2026. https://explainx.ai/blog/karpathy-understand-llm-outputs-ste100-diagrams-html-video-2026

[9] edwardyen724-g, "paper2video - Turn any technical article into a 2-5 min 3Blue1Brown-style explainer video", GitHub, 2026. https://github.com/edwardyen724-g/paper2video

[10] Mng-dev-ai, "explainer-video - AI skill that turns any topic into an animated narrated explainer video", GitHub, 2026. https://github.com/Mng-dev-ai/explainer-video

[11] chakrit, "kien-thai - สกิลสอนให้ AI เขียนภาษาไทยให้คนไทยอ่านสบาย", GitHub, 2026. https://github.com/chakrit/kien-thai

[12] explainx.ai, "ASD-STE100: The Aerospace Standard Fixing AI Slop Writing", 2026. https://explainx.ai/blog/asd-ste100-simplified-technical-english-ai-skill-2026

[13] Kun Chen, "i just tested the ASD-STE100 wording rule and it's surprisingly good at helping increase clarity of model response...", X (Twitter), 2 ตุลาคม 2026. https://x.com/kunchenguid/status/2105931853815296295
[14] ASD, "ASD-STE100 Simplified Technical English, Issue 9", ASD, 15 มกราคม 2025. https://www.asd-ste100.org/assets/files/ASD-STE100_ISSUE9.pdf

การเปิดเผยของผู้เขียน: บทความนี้เขียนโดย AI ผ่าน Hermes Agent และตรวจสอบเรียบเรียงโดย Nokka