AI และ Claude Code สำหรับงานออกแบบเกมในทางปฏิบัติ

ไม่มีตัวเลขที่กุขึ้นแม้แต่ตัวเดียว — เวิร์กโฟลว์ AI ที่รันมา 6 เดือน เปิดเผยทั้งหมดตั้งแต่พรอมต์ โค้ด ไปจนถึงการตรวจสอบ

Design Director ประสบการณ์ 24 ปี นำกฎ 304 ข้อ เครื่องมือ 48 ตัว และระบบอัตโนมัติที่ใช้งานจริงในทีมขนาดกลาง (10–50 คน) มาเสนออย่างที่เป็นจริง

ผู้เขียน อี มินซู (Minsoo Lee) · 2026

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

การเผยแพร่และลิขสิทธิ์ของหนังสือเล่มนี้

หนังสือเล่มนี้เปิดเผยให้อ่านฟรีด้วยความหวังว่าจะมีผู้อ่านอย่างกว้างขวาง อย่างไรก็ตาม ไม่ว่าจะเป็นต้นฉบับภาษาเกาหลี หรือฉบับแปลภาษาอังกฤษ ภาษาญี่ปุ่น ข้อเท็จจริงที่ว่าผู้เขียนต้นฉบับของหนังสือเล่มนี้คือ อี มินซู (Minsoo Lee) จะต้องคงอยู่ไม่ว่าจะอยู่ที่ใดก็ตาม

• สัญญาอนุญาต: ครีเอทีฟคอมมอนส์ แสดงที่มา-ไม่ใช้เพื่อการค้า-อนุญาตแบบเดียวกัน 4.0 (CC BY-NC-SA 4.0)
• ผู้เขียนต้นฉบับ: อี มินซู (Minsoo Lee), 2026
• ฉบับตั้งต้น (canonical): https://eremes81.github.io/game-design-ai-practice (GitHub Pages ของผู้เขียน — ฉบับตั้งต้นที่สิทธิ์ในการแก้ไขอยู่ที่ผู้เขียน)

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

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

ความรู้ที่บรรจุอยู่ในหนังสือเล่มนี้สมบูรณ์ในตัวเองภายในเล่มเดียว และฟรีในตัวมันเอง หากหนังสือเล่มนี้เป็นประโยชน์และคุณอยากให้กำลังใจผู้เขียน การสมทบด้วยการซื้ออีบุ๊กฉบับเป็นทางการหรือชุดเครื่องมือแบบเสียค่าใช้จ่ายจะเป็นที่ขอบคุณยิ่ง

คำนำ — หนังสือที่เขียนสามครั้ง

หนังสือเล่มนี้ถูกเขียนขึ้นสามครั้ง

ครั้งแรกไม่ใช่หนังสือ แต่เป็น คู่มือภายในบริษัท ตลอด 6 เดือนที่รันเวิร์กโฟลว์ AI ในบริษัท ผมตรึงการตัดสินใจ เครื่องมือ และขั้นตอนต่าง ๆ ไว้เป็นเอกสาร เพื่อให้ทีมไม่ต้องถามกฎเดียวกันซ้ำสองครั้ง มันไม่ได้สร้างขึ้นเพื่อตีพิมพ์ แต่เป็นเอกสารปฏิบัติงานที่สั่งสมขึ้นเพื่อลดงานซ้ำ ๆ ในแต่ละวัน ความเป็นรูปธรรมของหนังสือเล่มนี้มาจากตรงนั้น — หมายความว่ามันไม่ใช่ตัวอย่างที่แต่งขึ้นเพื่อหนังสือ แต่มีคู่มือที่ทำงานอยู่จริงเป็นรากฐาน

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

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

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

ข้อสอง ตัวเลขเป็นหนึ่งในสามอย่างนี้ มาตรฐานสาธารณะที่ใครก็ตรวจสอบได้ (ค่าโทเค็นของโมเดล แนวทางด้านการเข้าถึง) ค่าคงที่ที่ป้อนอยู่จริงในโค้ดของระบบผม หรือค่าที่ระบุไว้ชัดว่า "นี่คือการประมาณของผู้เขียน" ไม่มีตารางตัวเลขเงินที่ประหยัดได้ที่กุขึ้นแม้แต่ตารางเดียว ผมยกความซื่อตรงเป็นจุดที่ทำให้หนังสือเล่มนี้แตกต่าง

ข้อสาม ผมอ้างอิงระบบจริงที่รันมา 6 เดือนในงานจริงอย่างที่เป็น ตั้งแต่การ์ดการตัดสินใจ (atom) 304 การ์ด เครื่องมือ (skill) 48 ตัว hook ที่ดึงความทรงจำที่เกี่ยวข้องมาให้อัตโนมัติในทุกการป้อนข้อมูล ไปจนถึงโครงสร้างหน่วยความจำที่คนคนเดียวบริหารบริบทการทำงานร่วมกันได้เท่ากับสี่คน ผมไม่ได้เขียนว่า "เครื่องมือบางอย่าง" แบบนามธรรม แต่เขียนชื่อไฟล์ โค้ด และคะแนนไว้อย่างที่เป็น ในตัวอย่างของเนื้อหา ผมเพียงปิดบังชื่อบริษัท ชื่อโปรเจกต์ และชื่อสมาชิกทีมเท่านั้น แต่ไม่ได้ลบความเป็นรูปธรรมของเวิร์กโฟลว์ออก (บริษัทที่อนุญาตให้ตีพิมพ์หนังสือเล่มนี้ ผมได้ระบุชื่อจริงไว้ในกิตติกรรมประกาศ — เพราะได้รับความยินยอมแล้ว)

ผมเป็นนักออกแบบเกม (Game Designer) ประสบการณ์ 24 ปี ผมก้าวเข้าสู่วงการนี้ด้วยงาน QA และการตรวจสอบเกมแบบเล่นคนเดียว หลังจากนั้นก็ใช้เวลาไปกับการสร้าง RPG และ MMORPG รวมถึงสายพันธุ์ย่อยของมัน — ตั้งแต่ตำแหน่งผู้กำกับ MMORPG ที่ให้บริการในหลายสิบประเทศ การพัฒนาช่วงแรกของ AAA MMORPG ขนาด 200 คน ไปจนถึงการให้บริการเกม (Live Ops) ของ MMORPG บนมือถือระดับโลก ผมเข้าร่วมโปรเจกต์อย่าง Ragnarok Online (แร็กนาร็อก), Bless Online และซีรีส์ Mir ในหลากหลายบทบาท ทั้งผู้กำกับ หัวหน้าทีมออกแบบ นักออกแบบระบบ (System Designer) และบางครั้งก็เป็น PM และเคยก่อตั้งบริษัทเกมมือถือเล็ก ๆ ของตัวเองด้วย

พูดตามตรง ผมได้ตำแหน่งผู้กำกับเร็วเกินไป หลังจากนั้นมีช่วงเวลายาวนานที่ผมเป็นสมาชิกทีม — ในฐานะนักออกแบบระบบที่จับชีตข้อมูลและตัวเลขการต่อสู้ด้วยมือตัวเอง ในฐานะนักออกแบบเนื้อหา (Content Designer) ที่ผลิตเควสต์และ NPC ทีละบรรทัด ออกแบบอีเวนต์ และผลิตเนื้อหาใหม่ ๆ เวิร์กโฟลว์จำนวนมากในหนังสือเล่มนี้ถูกสร้างขึ้นที่ตำแหน่งนั้น — ตำแหน่งที่ไม่ใช่คนบริหาร แต่เป็นคนที่ลงมือจนมือเปื้อนเอง — ด้วยความรู้สึกว่า "อยากลดงานซ้ำ ๆ นี้ให้ได้ไม่ทางใดก็ทางหนึ่ง" ตอนนี้ในงานปัจจุบัน ผมเป็น Design Director นำทีมขนาดกลาง (10–50 คน) ของ MMORPG หนึ่งเกม แต่เครื่องมือในหนังสือเล่มนี้ไม่ใช่เครื่องมือบริหารของผู้กำกับ มันออกมาจากมือของผู้ปฏิบัติงาน ดังนั้นระบบในหนังสือเล่มนี้จึงไม่ใช่ทฤษฎี แต่เป็นสภาพแวดล้อมการทำงานที่หมุนอยู่ทุกวัน ผมยังจัดการตัวอย่างของเกมพัซเซิลเล็ก ๆ เกมหนึ่งที่ทำคนเดียวที่บ้านด้วยวิธีเดียวกัน — โดยอ้างอิง git commit และโค้ดจริงของเกมนั้นอย่างที่เป็น

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

วิธีอ่านหนังสือเล่มนี้

หนังสือเล่มนี้ไม่จำเป็นต้องอ่านเรียงตั้งแต่ต้นจนจบ คุณเลือกเส้นทางที่เหมาะกับสถานการณ์ของตัวเองได้เลย หากคุณยังใหม่กับเทอร์มินัลและการติดตั้ง ก่อนอื่นใดให้เปิดที่ 1.0 「ก่อนเริ่มต้น」 — เป็นบทที่ช่วยคลายความกลัวหน้าจอสีดำให้ก่อน

ท้ายแต่ละบทมี 「ลองทำดู」 เป้าหมายไม่ใช่บทที่อ่านแล้วปิดทิ้ง แต่คือการทำให้คุณขยับมือลงมือทำในสภาพแวดล้อมของตัวเองได้แม้เพียงขั้นเดียวในวันนี้

ขอเพิ่มอีกคำสำหรับผู้ที่ทำงานนอกวงการเกม เวิร์กโฟลว์จำนวนมากในหนังสือเล่มนี้ — การเปลี่ยนบันทึกการประชุมให้เป็นการตัดสินใจ การติดตามผลกระทบของการตัดสินใจ ด่านตรวจสอบ (verification gate) การจัดการต้นทุน ลิขสิทธิ์·จริยธรรม — ทำงานได้อย่างที่เป็นโดยไม่เกี่ยวกับเกม คุณจะอ่านโดยแทนที่ "การออกแบบเกม" ด้วยงานของตัวเองก็ได้ กล่อง 「การประยุกต์นอกเกม」 ในแต่ละบทคือสะพานเชื่อมนั้น และหากไม่มีเวลา แม้จะตามเฉพาะคอร์สเร่งรัด 90 นาที (17.1 → 16.2 → 22.1 → 21.1) คุณก็สัมผัสโครงสร้างหลักด้วยมือตัวเองได้

ขอแยกความหมายไว้สักหนึ่งจุด ในหนังสือเล่มนี้ "หนึ่งคน" ใช้ในสองความหมาย หนึ่งคือ ผู้กำกับคนเดียว — หัวหน้าทีมที่แบกบริบทการทำงานร่วมกันของหลายคนไว้คนเดียว — อีกหนึ่งคือ นักพัฒนาคนเดียว·งานอดิเรกที่ทำเกมด้วยตัวคนเดียว 「ฉบับย่อสำหรับคนเดียว」 ท้ายแต่ละบทมีไว้สำหรับความหมายหลัง โดยเขียนเส้นทางที่นำเฉพาะแก่นของบทนั้นไปใช้ได้โดยไม่มีทั้งทีมและโฟลเดอร์บริษัท

หนังสือเล่มนี้จะอ่านรวดเดียวจบทั้งเล่มก็ได้ หรือจะแบ่งเป็นสองสาย — ส่วนที่ 1–15 'รากฐาน·สาขา' และส่วนที่ 16–24 'กระบวนการ·การดำเนินงาน' — แล้วอ่านจากฝั่งที่ต้องการก่อนก็ได้ และโค้ดในเนื้อหาส่วนใหญ่รันได้ทันทีอย่างที่เป็นด้วยไลบรารีมาตรฐานของ Python โดยไม่ต้องพึ่งสิ่งภายนอก มีเพียงเครื่องมือบางตัว เช่น กราฟความสัมพันธ์ ที่ต้องใช้แพ็กเกจนอกมาตรฐาน (networkx, PyYAML) และในจุดเหล่านั้นผมเขียนคำสั่งติดตั้งหนึ่งบรรทัด (pip install …) ไว้ข้างโค้ดด้วย ยกเว้นกรณีนั้น คุณคัดลอกบล็อกโค้ดไปรันตรวจสอบได้ทันทีโดยไม่ต้องดาวน์โหลดอะไรเพิ่ม

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

วิธีใช้ที่ง่ายที่สุด

สุดท้ายนี้ ขอกระซิบวิธีใช้หนังสือเล่มนี้ที่เร็วที่สุดให้สักหนึ่งวิธี นั่นคือการให้เครื่องมือ AI อย่าง Claude Code อ่านหนังสือเล่มนี้ทั้งเล่ม

หนังสือเล่มนี้ไม่ได้เขียนไว้ให้คนอ่านอย่างเดียว พรอมต์เต็ม โค้ด และขั้นตอนการตรวจสอบในแต่ละบท เขียนไว้ในรูปแบบที่ AI เข้าใจและทำซ้ำได้อย่างที่เป็น ดังนั้นในโฟลเดอร์โปรเจกต์ของคุณ คุณส่งหนังสือเล่มนี้ให้ AI — จะเป็น PDF หรือข้อความก็ได้ — แล้วขอแบบนี้ได้ "อ่านรูปแบบการตรวจสอบความสอดคล้องในหนังสือเล่มนี้ แล้วสร้างเครื่องมือตรวจสอบที่เหมาะกับชีตข้อมูลของเราให้หน่อย" จากนั้น AI จะติดตั้งเวิร์กโฟลว์ของบทนั้นให้เข้ากับสภาพแวดล้อมของคุณ ทั้งเส้นทางที่คนค่อย ๆ ทำตามทีละบทด้วยมือ และเส้นทางที่ให้หนังสือทั้งเล่มแก่ AI แล้วสร้างไปด้วยกัน — ทั้งสองเส้นทางเปิดอยู่

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

คำสัญญาหนึ่งข้อ

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

คำสัญญาของคำว่า 'การเรียบเรียงใหม่'

ในเนื้อหาของหนังสือเล่มนี้ ผลลัพธ์ของบันทึกเซสชันจริง (worked transcript) มักมีคำว่า 'การเรียบเรียงใหม่ (reconstruction)' กำกับอยู่ — เช่น 「ขั้นที่ 3 — ผลลัพธ์ของ Claude (การเรียบเรียงใหม่)」 ผมขอให้คำสัญญาให้ชัดเจนสักครั้งเดียวว่า คำนี้หมายถึงการรักษาสิ่งใดไว้และแตะต้องสิ่งใด เพราะนี่คือจุดที่หนังสือซึ่งชูความซื่อตรงเป็นหัวเรื่องไม่ควรปล่อยให้คลุมเครือที่สุด

'การเรียบเรียงใหม่' ไม่ได้หมายความว่ากุขึ้น แต่หมายความว่าได้แก้ไขเรียบเรียงเซสชันจริง เส้นแบ่งเป็นดังนี้

พูดอีกอย่าง ในผลลัพธ์ที่เรียบเรียงใหม่ ผมไม่ได้เติมตัวเลขที่พองผลลัพธ์หรือเติมความสำเร็จที่ไม่เคยมี ผมเพียงทำให้เป็นนามแฝง ตัดข้อความ และเกลาให้เข้ากับหน้ากระดาษเท่านั้น ไม่มีที่ใดที่ผมแก้ผลลัพธ์ที่ล้มเหลวให้กลายเป็นความสำเร็จ — ตรงกันข้าม ผมจงใจคงความล้มเหลวไว้บางส่วน เพราะนั่นคือจุดที่แสดงให้เห็นว่าคนปฏิเสธสิ่งใด (ในทางตรงข้าม จุดที่ระบุว่าเป็นผลการรันโค้ดหรือล็อกของระบบว่า 'วัดจริง'·'อ้างอิงอย่างที่เป็น' คือสิ่งที่ย้ายมาโดยไม่มีการแก้ไข)

หมายเหตุของผู้แปล: ฉบับภาษาไทยนี้แปลด้วยปัญญาประดิษฐ์ (AI) เป็นร่างแรก แล้วผ่านการตรวจสอบและเรียบเรียงโดยมนุษย์ บทสนทนาจริง (worked transcript) ทั้งหมดในฉบับนี้เป็นการแปลจากเซสชันภาษาเกาหลีต้นฉบับ ไม่ใช่การรันใหม่เป็นภาษาไทย พรอมต์และผลลัพธ์ภายในบล็อกโค้ดก็ได้รับการแปลเพื่อให้อ่านง่ายเช่นกัน ต้นฉบับภาษาเกาหลี — สิ่งที่หนังสือเล่มนี้สัญญาว่าจะไม่แก้ไข — ได้รับการเก็บรักษาไว้ตามเดิมในฉบับภาษาเกาหลี (ที่ repository ต้นฉบับบน GitHub) ส่วนไวยากรณ์ของโค้ด ตัวระบุ ตัวเลข และค่าตรวจสอบ (verification values) ไม่ได้ถูกแก้ไขใด ๆ การแปลงสกุลเงินเป็นค่าโดยประมาณ โดยอิงอัตราราว 1,500 วอนต่อ 1 ดอลลาร์สหรัฐ ณ กลางปี 2026

ส่วนที่ 1 · เริ่มต้น

1.0 ก่อนเริ่มต้น — การติดตั้ง บัญชี ค่าบริการ และชุดเอาตัวรอดบนเทอร์มินัล

หัวข้อ 1.1 คือ "การพบกันครั้งแรก" เป็นช่วงที่คุณนั่งอยู่หน้าเคอร์เซอร์ที่กะพริบและลองพิมพ์อะไรบางอย่าง แต่ก่อนจะนั่งลงตรงนั้นได้ มีสิ่งที่ต้องเตรียมพร้อมก่อน เครื่องมือต้องติดตั้งไว้แล้ว ต้องล็อกอินไว้แล้ว ต้องพอเข้าใจคร่าว ๆ ว่าค่าบริการคิดอย่างไร และต้องพิมพ์ตัวอักษรสักสองสามตัวบนหน้าจอดำได้ บทนี้จึงอยู่ก่อนหน้า 1.1 หนึ่งขั้น

หนังสือสำหรับผู้เริ่มต้นจำนวนมากข้ามขั้นตอนนี้ไป เขียนแค่บรรทัดเดียวว่า "เปิดเทอร์มินัล" แล้วผ่านเลยไป แต่ผู้เริ่มต้นกลับติดอยู่ที่บรรทัดนั้นเอง เทอร์มินัลอยู่ตรงไหน ต้องติดตั้งอะไร ถ้าติดตั้งแล้วเจอตัวอักษรสีแดงต้องทำอย่างไร — คนที่หยุดอยู่ที่บรรทัดแรกไปไม่ถึง 1.1 เป้าหมายของบทนี้มีเพียงข้อเดียว คือทำให้คุณไม่ติดอยู่ที่บรรทัดแรก

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

flowchart LR
    A["1.0 ขั้นเตรียมการ
(บทนี้)"] --> B["1.1 การพบกันครั้งแรก
(นั่งลงหน้าเคอร์เซอร์)"]
    A1["① การติดตั้ง"] --> A2["② บัญชี·ล็อกอิน"]
    A2 --> A3["③ แนวคิดแพ็กเกจค่าบริการ"]
    A3 --> A4["④ ชุดเอาตัวรอดบนเทอร์มินัล"]
    A4 --> A5["⑤ รันครั้งแรกใน 5 นาที"]
    A5 --> B
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class A1,A2,A3,A4,A5 human
    class B pass

1.0.1 การติดตั้ง — หนึ่งบรรทัดต่อหนึ่ง OS

หลักการของการติดตั้งคือทำตามคำแนะนำอย่างเป็นทางการ เครื่องมือเปลี่ยนแปลงบ่อย และไฟล์ติดตั้งที่ได้มาจากแหล่งที่ไม่เป็นทางการนั้นอันตราย ด้วยเหตุนี้หนังสือเล่มนี้จึงไม่ได้ใส่ลิงก์ดาวน์โหลดไว้ แต่จะแนะนำวิธีค้นหาเส้นทางอย่างเป็นทางการแทน หากพิมพ์ "Claude Code เอกสารทางการ" หรือ "Claude Code install" ในช่องค้นหา หน้าเอกสารทางการของบริษัท Anthropic จะปรากฏขึ้นมาเป็นอันดับแรก การใช้คำสั่งติดตั้งจากหน้านั้นตามที่ระบุไว้คือวิธีที่ปลอดภัยที่สุด

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

ทั้งสาม OS มีขั้นตอนเหมือนกัน คือ "เปิดเทอร์มินัล → วางคำสั่งหนึ่งบรรทัดจากเอกสารทางการ → กด Enter" ไม่จำเป็นต้องท่องจำคำสั่ง การคัดลอกจากเอกสารทางการแล้ววางคือวิธีมาตรฐาน

แม้ระหว่างติดตั้งจะมีตัวอักษรสีแดง (ข้อผิดพลาด) ปรากฏขึ้นก็ไม่ต้องตกใจ ข้อผิดพลาดในการติดตั้งที่ผู้เริ่มต้นพบมักเป็นหนึ่งในสองอย่าง คือปัญหาเรื่องสิทธิ์ หรือกรณีที่ไม่มีเครื่องมือพื้นฐาน (เช่น รันไทม์อย่าง Node.js) หากมีตัวอักษรสีแดงปรากฏขึ้น ให้คัดลอกทั้งประโยคนั้นตามเดิมเพื่อไปค้นหา หรือถาม AI ก็มักจะแก้ได้เกือบทุกครั้ง ข้อความข้อผิดพลาดไม่ใช่ศัตรู แต่เป็นเบาะแส

วิธีตรวจสอบว่าติดตั้งสำเร็จหรือไม่: พิมพ์ claude --version ในเทอร์มินัลแล้วกด Enter ถ้าหมายเลขเวอร์ชันปรากฏขึ้นมาหนึ่งบรรทัด แสดงว่าติดตั้งสำเร็จ หากมีข้อความทำนองว่า "ไม่พบคำสั่ง" ปรากฏขึ้น แสดงว่ายังติดตั้งไม่เสร็จ หรือเป็นกรณีที่ต้องเปิดเทอร์มินัลใหม่ ลองปิดเทอร์มินัลให้สนิทแล้วเปิดขึ้นมาใหม่ จากนั้นตรวจสอบอีกครั้ง

1.0.2 บัญชีและการล็อกอิน

ติดตั้งเสร็จแล้วไม่ได้แปลว่าใช้งานได้ทันที Claude Code เป็นเครื่องมือที่ยืมโมเดล AI ของ Anthropic มาใช้ จึงต้องมีขั้นตอนล็อกอินเพื่อยืนยันว่าใครเป็นผู้ใช้

ขั้นตอนนั้นเรียบง่าย เมื่อรัน claude ในเทอร์มินัลเป็นครั้งแรก คำแนะนำการล็อกอินจะปรากฏขึ้น โดยทั่วไปเว็บเบราว์เซอร์จะเปิดขึ้นมาเองโดยอัตโนมัติ จากนั้นล็อกอินด้วยบัญชี Anthropic ตรงนั้น (หากไม่มี ก็สามารถสร้างใหม่ได้จากหน้าจอนั้น) เมื่อล็อกอินเสร็จ เบราว์เซอร์จะแสดงคำแนะนำทำนองว่า "ตอนนี้กลับไปที่เทอร์มินัลได้แล้ว" และฝั่งเทอร์มินัลเองก็จะแสดงเครื่องหมายว่าเสร็จสมบูรณ์

ตรงนี้มีอยู่สองจุดที่ผู้เริ่มต้นมักจะติด

จุดแรก คือกรณีที่เบราว์เซอร์ไม่เปิดขึ้นมาเองโดยอัตโนมัติ ในกรณีนี้จะมีที่อยู่ยาว ๆ (URL) ปรากฏขึ้นหนึ่งบรรทัดในเทอร์มินัล ให้คัดลอกที่อยู่นั้นไปวางในช่องที่อยู่ของเบราว์เซอร์แล้วเข้าไป ไม่ได้ตันแต่อย่างใด เพียงแค่ต้องทำด้วยตัวเองเพิ่มอีกขั้นเดียวเท่านั้น

จุดที่สอง คือกรณีที่สับสนเรื่องประเภทบัญชี การเชื่อมโยงระหว่างบัญชีที่เคยใช้กับเว็บแชต (Claude.ai) กับบัญชีและค่าบริการของ Claude Code นั้นอาจมีนโยบายต่างกันไปในแต่ละช่วงเวลา การทำตามคำแนะนำบนหน้าจอล็อกอินและเอกสารทางการคือวิธีที่ถูกต้องที่สุด หากทำตามที่หน้าจอการรันครั้งแรกบอก ส่วนใหญ่ก็จะล็อกอินได้โดยไม่มีปัญหา

ล็อกอินครั้งเดียวแล้วจะคงอยู่บนเครื่องนั้น ไม่จำเป็นต้องทำใหม่ทุกครั้ง

1.0.3 แนวคิดเรื่องแพ็กเกจค่าบริการ — สมาชิกรายเดือนแบบเหมาจ่าย vs API แบบจ่ายตามการใช้

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

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

API แบบจ่ายตามการใช้ คือรูปแบบที่คิดเงินตามสัดส่วนของปริมาณที่ใช้จริง (โทเค็น) เหมือนมิเตอร์ไฟฟ้าที่เรียกเก็บตามที่ใช้ไป เหมาะกับการประมวลผลปริมาณมาก ระบบอัตโนมัติ (pipeline) หรือกรณีที่เชื่อมต่อกับโปรแกรมอื่น หากใช้อย่างพิถีพิถันก็มีประสิทธิภาพ แต่ในขั้นเริ่มต้น การคาดการณ์ค่าใช้จ่ายอาจทำได้ยากจนกว่าจะจับทางปริมาณการใช้ได้

โทเค็นคืออะไรและทำไมจึงคิดเงินด้วยมัน จะกล่าวถึงอย่างละเอียดในหัวข้อ 1.2 (โมเดล AI·โทเค็น·ฮาร์เนส) ตรงนี้ขอให้จำไว้เพียงข้อเดียว ผู้เริ่มต้นมักจะเริ่มต้นด้วยสมาชิกรายเดือนแบบเหมาจ่าย เพราะจำนวนเงินคงที่ทุกเดือน จึงฝึกฝนได้โดยไม่ต้องกลัวว่า "ใช้ไปแล้วจะโดนบิลก้อนโต" ชื่อแพ็กเกจ ราคา และเพดานเปลี่ยนแปลงบ่อย หนังสือเล่มนี้จึงไม่ได้ใส่ตัวเลขเฉพาะเจาะจงไว้ เนื้อหาของหนังสือเล่มนี้เขียนขึ้นโดยอ้างอิงช่วงกลางปี 2026 และแพ็กเกจค่าบริการ โมเดล รวมถึงฟีเจอร์ต่าง ๆ ก็ยังคงเปลี่ยนแปลงต่อไปหลังจากนั้น การตรวจสอบค่าปัจจุบันที่หน้าค่าบริการอย่างเป็นทางการคือวิธีที่ถูกต้องที่สุด

สรุปหนึ่งบรรทัด: ความกลัวว่าทุกครั้งที่ใช้จะเสียเงินหรือเปล่า → ถ้าเป็นสมาชิกรายเดือนแบบเหมาจ่ายก็คงที่ทุกเดือน ผู้เริ่มต้นเริ่มด้วยแบบเหมาจ่ายจะสบายใจกว่า

1.0.4 ชุดเอาตัวรอดบนเทอร์มินัล — ลดความกลัวหน้าจอดำ

ทีนี้มาถึงกำแพงที่ใหญ่ที่สุด นั่นคือหน้าจอดำ เหตุผลที่หัวข้อ 1.1 เริ่มต้นด้วย "ลังเลอยู่หน้าเคอร์เซอร์ที่กะพริบ" ก็อยู่ตรงนี้ สำหรับมือที่ทำงานกับ GUI มา 24 ปี เทอร์มินัลเป็นสิ่งแปลกหน้า แต่คำสั่งที่จำเป็นเพื่อไม่ให้ติดอยู่ที่บรรทัดแรกนั้นมีไม่มากนัก หกคำสั่งด้านล่างนี้ก็เพียงพอแล้ว

(บน Windows PowerShell ก็ใช้ ls·cd·pwd ได้ตามนี้ macOS·Linux ก็เหมือนกัน ดังนั้นหกคำสั่งนี้จึงใช้ได้ไม่ว่าจะ OS ใด)

หากดูสิ่งที่หกคำสั่งนี้ทำเป็นภาพ ก็จะเป็นแบบนี้ การเคลื่อนที่บนเทอร์มินัลสุดท้ายแล้วก็คือการเข้า ๆ ออก ๆ ในและนอกโฟลเดอร์ ซึ่งเป็นการกระทำแบบเดียวกับการดับเบิลคลิกโฟลเดอร์หรือการย้อนกลับใน GUI

flowchart TD
    Q["pwd
ตรงนี้คือที่ไหน?"] --> L["ls
ตรงนี้มีอะไรบ้าง?"]
    L --> D{"มีโฟลเดอร์
ที่จะเข้าไปไหม?"}
    D -- "ใช่" --> IN["cd ชื่อโฟลเดอร์
เข้าไป"]
    D -- "ไม่ ขึ้นข้างบน" --> UP["cd ..
ออกมา"]
    IN --> L
    UP --> L
    RUN["หลังจากพิมพ์คำสั่งแล้ว"] --> ENT["Enter
รัน"]
    STUCK["เมื่อรู้สึกว่ามีอะไรค้างอยู่"] --> STOP["Ctrl + C
หยุดแล้วดึงเคอร์เซอร์กลับมา"]
    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    class Q,L,IN,UP,ENT,STOP code
    class D human

เหตุผลที่แท้จริงที่หน้าจอดำน่ากลัวคือความรู้สึกว่า "ถ้าพิมพ์ผิดแล้วมันจะพังเสียหาย" แต่ในหกคำสั่งข้างต้นไม่มีคำสั่งใดที่ทำให้อะไรพังเสียหายได้ pwd·ls·cd แค่ดูหรือย้ายที่เท่านั้น ไม่ได้ลบหรือเปลี่ยนแปลงไฟล์ Enter คือการรัน Ctrl + C ก็เป็นเพียงการหยุด ดังนั้นหกคำสั่งนี้พิมพ์ได้อย่างสบายใจเมื่อไหร่ก็ได้

มีบางครั้งที่หน้าจอดูเหมือนค้างอยู่ คือเมื่อพิมพ์คำสั่งไปแล้วไม่มีอะไรตอบสนองอยู่นาน หรือเคอร์เซอร์กะพริบอยู่ที่อีกบรรทัดหนึ่งราวกับกำลังรออะไรเพิ่มเติม ในกรณีเช่นนั้น หากกด Ctrl + C หนึ่งครั้ง ส่วนใหญ่ก็จะกลับมาที่เคอร์เซอร์เดิม เพียงแค่รู้ว่ามี "ปุ่มหยุด" นี้อยู่ หน้าจอดำก็ดูน่ากลัวน้อยลงมาก ถ้าติดก็ใช้ Ctrl + C ออกมาแล้วเริ่มใหม่ก็ได้

สุดท้าย เมื่อตัวอักษรที่พิมพ์ไปกองพะเนินจนตาลาย ก็สามารถล้างหน้าจอได้ ทั้ง Windows PowerShell·macOS·Linux ล้างด้วยคำสั่ง clear ทั้งหมด แม้จะล้างไปแล้ว สิ่งที่ทำไปก็ไม่ได้หายไป เพียงแต่ตัวอักษรที่มองเห็นถูกจัดให้เรียบร้อยเท่านั้น

1.0.5 เช็กลิสต์ "รันครั้งแรกใน 5 นาที"

หากมาถึงตรงนี้ การเตรียมการก็เสร็จสิ้นแล้ว หากผ่านห้าช่องด้านล่างนี้ได้ภายใน 5 นาที ก็แสดงว่าคุณมีคุณสมบัติพอจะนั่งลงตรงที่หัวข้อ 1.1 หากติดแม้แต่ช่องเดียว ก็ย้อนกลับไปยังหัวข้อนั้น (1.0.1\~1.0.4) ได้

flowchart LR
    C1["① เทอร์มินัล
เปิดขึ้นมา"] --> C2["② claude --version
เวอร์ชันปรากฏ"]
    C2 --> C3["③ รัน claude →
ล็อกอินเสร็จ"]
    C3 --> C4["④ pwd·ls
เห็นโฟลเดอร์ของฉัน"]
    C4 --> C5["⑤ Ctrl+C
ออกมาได้"]
    C5 --> OK["✅ ไปสู่ 1.1"]
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class C1,C2,C3,C4,C5 human
    class OK pass

• [ ] ① เปิดเทอร์มินัลได้ (Windows: PowerShell / macOS: เทอร์มินัล)
• [ ] ② พิมพ์ claude --version แล้วหมายเลขเวอร์ชันปรากฏขึ้นมาหนึ่งบรรทัด (ยืนยันการติดตั้ง)
• [ ] ③ รัน claude แล้วล็อกอินไว้แล้ว (หรือล็อกอินเสร็จตามคำแนะนำ)
• [ ] ④ ดูตำแหน่งปัจจุบันด้วย pwd และดูเนื้อหาในโฟลเดอร์ด้วย ls ได้
• [ ] ⑤ เมื่อมีอะไรค้าง ออกมาได้ด้วย Ctrl + C

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

1.0.6 Python·pip — หากต้องรันเครื่องมือ (เฉพาะเมื่อจำเป็น)

ส่วนต้นของหนังสือเล่มนี้ (ส่วนที่ 1·2) สามารถทำตามได้ด้วยพรอมต์ภาษาธรรมชาติเพียงอย่างเดียว เพียงแต่บางบทตั้งแต่ส่วนที่ 4 เป็นต้นไปจะรันสคริปต์ Python เล็ก ๆ ด้วยตัวเอง (เช่น pip install pyyaml, pip install pyvis) ถึงจะเพิ่งเริ่มใช้ Python ก็ไม่เป็นไร มีอยู่สองเส้นทาง

เส้นทางแรก เส้นทางติดตั้งเอง ดาวน์โหลด Python จาก python.org มาติดตั้ง (อย่าลืมเลือก "Add to PATH" ในหน้าจอติดตั้ง) แล้วตรวจสอบด้วย python --version ในเทอร์มินัล pip เป็นเครื่องมือติดตั้งแพ็กเกจที่ติดตั้งมาพร้อมกับ Python ดังนั้นจึงรับแพ็กเกจที่ต้องการได้ในบรรทัดเดียวอย่าง pip install pyyaml

เส้นทางที่สอง เส้นทางมอบหมายให้ AI (แนะนำ) เส้นทางที่ง่ายกว่าคือสั่งให้ AI สร้างสภาพแวดล้อมให้เอง เพียงร้องขอในเทอร์มินัลแบบนี้

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

AI จะตรวจสภาพแวดล้อมของคุณและสร้างคำสั่งติดตั้งให้ หากติด ก็วางข้อความข้อผิดพลาดตรงนั้นตามที่เป็นแล้วถามว่า "ข้อผิดพลาดนี้แก้อย่างไร" ได้เลย ในทุกบทที่ต้องรันเครื่องมือ แพตเทิร์นนี้เพียงอย่างเดียวก็เพียงพอ ในขั้นที่ Python·pip เป็นภาระ "ฉบับย่อสำหรับคนเดียว" ของบทนั้นจะแนะนำเส้นทางที่เบากว่าซึ่งไปได้โดยไม่ต้องใช้โค้ด

ตัวอย่างบทถัดไป

• 1.1 การพบกันครั้งแรกของนักออกแบบเกมกับ Claude Code — นั่งลงหน้าเคอร์เซอร์แล้วประคองตัวให้ผ่าน 30 นาทีแรก

ลองทำดู

setup 1. เปิดเทอร์มินัลของ OS ที่คุณใช้อยู่ (Windows: PowerShell, macOS: เทอร์มินัล) 2. ค้นหา "Claude Code เอกสารทางการ" แล้วเปิดหน้าคำแนะนำการติดตั้งอย่างเป็นทางการค้างไว้ 3. ตั้งเวลา 5 นาที — เป้าหมายคือการผ่านทั้งห้าช่องของเช็กลิสต์ 1.0.5

prompt (ลองพิมพ์ทีละบรรทัดตามลำดับ นี่เป็นคำสั่ง ไม่ใช่คำถามภาษาธรรมชาติ)

① claude --version      # ถ้าเวอร์ชันปรากฏ แสดงว่าติดตั้งสำเร็จ
② pwd                   # ตอนนี้ฉันอยู่ในโฟลเดอร์ไหน
③ ls                    # ในโฟลเดอร์นี้มีอะไรบ้าง
④ cd ..                 # ออกขึ้นไปข้างบนหนึ่งขั้น (แล้ว ls อีกครั้ง)
⑤ claude                # รัน Claude Code (ถ้าคำแนะนำการล็อกอินปรากฏ ก็ทำตาม)

verify - หากในข้อ ① หมายเลขเวอร์ชันปรากฏขึ้นมาหนึ่งบรรทัด แสดงว่าการติดตั้งเสร็จสิ้นแล้ว หากปรากฏข้อความ "ไม่พบคำสั่ง" ให้ปิดเทอร์มินัลแล้วเปิดใหม่ จากนั้นลองอีกครั้ง - ระหว่างที่ดูและย้ายโฟลเดอร์ด้วยข้อ ②·③·④ ให้ลองยืนยันด้วยตัวเองว่าไม่มีอะไรพังเสียหาย ทั้งสามนี้เป็นคำสั่งที่ปลอดภัยซึ่งแค่ดูและย้ายที่เท่านั้น - หากระหว่างรันข้อ ⑤ ดูเหมือนค้าง ให้ออกมาด้วย Ctrl + C หากออกมาได้ ก็แสดงว่าคุณได้ยืนยันด้วยตัวเองแล้วว่า "มีปุ่มหยุดอยู่"

ฉบับย่อสำหรับคนเดียว

หากคุณเป็นบุคคลที่ไม่มีทั้งทีมและไม่มีโฟลเดอร์บริษัท ขอให้ฝึกแค่การติดตั้ง (①) และการออกมาด้วย Ctrl + C ก่อน หากยืนยัน "เครื่องมือติดตั้งแล้ว" ด้วย claude --version และยืนยัน "ติดแล้วก็ออกมาได้" ด้วย Ctrl + C ความกลัวหน้าจอดำครึ่งหนึ่งก็จัดการได้ภายใน 5 นาทีแม้อยู่คนเดียว ส่วนค่าบริการ หากเริ่มต้นด้วยสมาชิกรายเดือนแบบเหมาจ่ายไปก่อน ก็จะฝึกฝนได้อย่างเต็มที่โดยไม่ต้องกังวลเรื่องค่าใช้จ่าย

1.1 การพบกันครั้งแรกระหว่างนักออกแบบเกมกับ Claude Code

หน้าจอสีดำปรากฏขึ้น เคอร์เซอร์กะพริบอยู่ ตรงหน้าจอนั้นมีนักออกแบบเกมประสบการณ์ 24 ปีนั่งอยู่ มือที่ทำงานมา 24 ปีด้วย PPT และ Excel ด้วยวิกิและ Figma หยุดนิ่งอยู่ครู่หนึ่งเหนือแป้นพิมพ์ มันชวนให้นึกถึง DOS ในยุคที่ยังมีโรงเรียนสอนคอมพิวเตอร์อยู่ หลังจากนั้นสิ่งที่เรียกว่าเทอร์มินัลก็เป็นของที่เห็นได้แต่บนโต๊ะของโปรแกรมเมอร์เท่านั้น ไม่รู้ว่าต้องพิมพ์อะไร และรู้สึกว่าถ้าพิมพ์ผิดแล้วอะไรบางอย่างจะพังไป ความลังเลตรงจุดนี้คือจุดเริ่มต้นของหนังสือเล่มนี้

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

เมื่อนักออกแบบเกมนั่งลงต่อหน้าเครื่องมือเขียนโค้ดด้วย AI อย่าง Claude Code เป็นครั้งแรก ความรู้สึกแปลกใหม่และความรู้สึกอึดอัดเกิดขึ้นพร้อมกัน ณ ที่เดียวกัน ข้อเท็จจริงที่ว่าอารมณ์สองอย่างนี้ปะทะกันเองนั้นคือเบาะแสแรกของการนำเข้ามาใช้

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

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

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

1.1.1 ทำไมต้องเป็นตอนนี้ ทำไมนักออกแบบเกมจึงต้องใช้ AI

การออกแบบเกมเข้าร่วมกระแส AI ช้ากว่าอาชีพอื่น คนที่ทำงานกับโค้ดเข้าก่อน ตามด้วยนักออกแบบและศิลปิน นักออกแบบเกมมักมีรูปแบบที่ผัดผ่อนไปเรื่อย ๆ พร้อมพูดซ้ำว่า "พวกเราก็น่าจะต้องลองทำอะไรสักอย่างนะ"

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

แต่ระหว่างปี 2024 ถึง 2026 มีสามสิ่งที่เปลี่ยนไป

ประการแรก ความสามารถในการให้เหตุผลของโมเดล AI ก้าวข้ามจุดวิกฤต มันก้าวข้ามการสร้างประโยคง่าย ๆ ไปจัดการกับการออกแบบระบบที่ซับซ้อน การตรวจสอบความสอดคล้อง และการวิเคราะห์ผลกระทบ Claude รุ่นล่าสุดช่วยสนับสนุนเวิร์กโฟลว์การออกแบบเกมได้ส่วนหนึ่งที่มีนัยสำคัญ เพียงแต่ไม่ได้หมายความว่ามอบหมายทั้งหมดให้ได้ การตรวจสอบและความรับผิดชอบยังคงเป็นหน้าที่ของมนุษย์ (ขอบเขตที่ช่วยได้แตกต่างกันมากตามชนิดของงานและความสมบูรณ์ของทีม — การประมาณของผู้เขียน ยังไม่ได้ตรวจสอบ)

ประการที่สอง ฮาร์เนส (harness) สมบูรณ์ขึ้น เครื่องมืออย่าง Claude Code ไม่ใช่แค่แชตธรรมดา มันอ่านและเขียนไฟล์ได้โดยตรง รันคำสั่งได้ และรับผลลัพธ์กลับมาเป็นอินพุตอีกครั้ง คล้ายกับวิธีที่มนุษย์ทำงาน

ประการที่สาม เทคนิคการใช้งานอย่างเมโมรี atom และ skill ลงตัวแล้ว ไม่ใช่การใช้ AI ครั้งเดียวแล้วจบ แต่เป็นการสะสมความรู้ของทีมเพื่อทำให้ฉลาดขึ้นเรื่อย ๆ เมื่อเวลาผ่านไป ซึ่งระเบียบวิธีนี้ได้ลงหลักปักฐานแล้ว แก่นที่ส่วนหลังของหนังสือเล่มนี้กล่าวถึงก็คือการสะสมนี้เอง

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

1.1.2 Claude Code คืออะไร — ความแตกต่างจากเครื่องมืออื่น

เครื่องมือ AI ที่นักออกแบบเกมมักพบเจอมีอยู่สองชนิด ได้แก่ ชนิดแชตบอตที่โยนคำถามลงในช่องแชต (ChatGPT, เว็บแอป Claude) และชนิดผนวกกับเอดิเตอร์ที่ทำการเติมข้อความอัตโนมัติภายในโค้ดเอดิเตอร์ (Cursor, Copilot)

Claude Code เป็นชนิดที่สาม มันทำงานบน CLI (เทอร์มินัล) และเข้าถึงสภาพแวดล้อมการทำงานทั้งหมดของมนุษย์ หากมองเป็นภาพเดียวว่าทั้งสามชนิดแยกกันตรงไหน จะได้ดังนี้

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

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

1.1.3 30 นาทีแรก — จะมองอะไรและจะลองทำอะไร

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

flowchart LR
    A["มอง (5 นาที)
ช่วยสรุปโฟลเดอร์นี้ที
→ 'มันเข้าใจภาษาธรรมชาติ'"]
    B["ค้นหา (5 นาที)
หาคีย์เวิร์ด·ไฟล์ล่าสุด
→ 'มันทำงานจุกจิกที่ทำทุกวันแทน'"]
    C["แปลง (10 นาที)
บันทึกประชุม→ตาราง, Excel→Markdown
→ 'มันสร้างเวลาให้'"]
    D["ตรวจสอบ (10 นาที)
สงสัยผลลัพธ์ที่เพิ่งได้มา
→ 'เครื่องมือนี้สมควรถูกตั้งข้อสงสัย'"]
    A --> B --> C --> D
    D --> E["ความรู้สึกห่างเหินคลายไป 80%"]
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class A,B,C ai
    class D human
    class E pass

5 นาทีแรก — มอง

เมื่อเปิดเทอร์มินัลและรัน Claude Code หน้าจอสีดำจะปรากฏขึ้นและเคอร์เซอร์กะพริบ หลายคนหยุดอยู่ตรงนี้ แต่ถ้าหยุดก็จะพลาดโอกาสแรกที่ความรู้สึกห่างเหินจะคลายลง ลองพิมพ์ประโยคภาษาธรรมชาติหนึ่งประโยคลงไป

ช่วยสรุปให้หน่อยว่าในโฟลเดอร์นี้มีอะไรบ้าง

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

ช่วยสรุปให้หน่อยว่าในโฟลเดอร์นี้มีอะไรบ้าง


สแกนโฟลเดอร์นี้แล้ว ดูเหมือนเป็นโฟลเดอร์ทำงานข้อมูลเกมและเอกสารออกแบบ

  ชนิดไฟล์         จำนวน   ประมาณเนื้อหา
  ─────────────   ────    ───────────────────────────
  .xlsm            12     ชีตข้อมูล (ไอเทม·เควสต์·NPC ฯลฯ)
  .md              34     ร่างเอกสารออกแบบ·บันทึกประชุม
  .png             88     ม็อกอัป UI·ภาพอ้างอิง
  โฟลเดอร์ย่อย      6     /data /docs /ref /meeting /export /tmp

ข้อสังเกต:
  - ในโฟลเดอร์ /meeting มีบันทึกประชุมของสัปดาห์ที่ผ่านมา 5 รายการสะสมอยู่
  - item_table.xlsm กับ quest_table.xlsm ดูเหมือนใช้คอลัมน์ ID
    เดียวกันร่วมกัน (เป็นผู้ต้องสงสัย FK)
  - ในโฟลเดอร์ /tmp มีไฟล์ export ชั่วคราวจำนวนมาก — อาจเป็นเป้าหมายที่ควรจัดระเบียบ

จะให้ดูส่วนไหนก่อนดี

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

5 นาทีต่อมา — ค้นหา

ลองสั่งค้นหาเล็ก ๆ เช่น "บอกไฟล์ Markdown 5 ไฟล์ที่แก้ไขในสัปดาห์ที่ผ่านมาหน่อย" หรือ "ไฟล์ที่มีคำว่า 'รีวอร์ด' อยู่ที่ไหน" งานที่นักออกแบบเกมเคยเปิด Find in Files พิมพ์คีย์เวิร์ดและเลื่อนดูผลลัพธ์ทุกวัน Claude Code รับด้วยภาษาธรรมชาติแล้วเรียบเรียงคืนมาให้ ความรู้สึกที่ว่าเครื่องมือนี้ทำงานจุกจิกที่ทำทุกวันแทนนั้นจะลงตัวในช่วง 5 นาทีที่สอง

10 นาทีต่อมา — แปลง

ลองสั่งการแปลงเล็ก ๆ เช่น "ดึงเฉพาะสิ่งที่ตัดสินใจจากบันทึกประชุมนี้แล้วทำเป็นตารางหน่อย" หรือ "เปลี่ยนแถวที่ 1 ถึง 10 ของชีต Excel นี้เป็นตาราง Markdown หน่อย" ประสบการณ์ที่การแปลงซึ่งใช้มือทำ 5 ถึง 10 นาทีถูกจัดการในเวลาสั้น ๆ จะนำไปสู่ความรู้สึกที่ว่าเครื่องมือนี้ไม่ได้แค่ทำการค้นหาแทน แต่สร้างเวลาให้ด้วย

10 นาทีสุดท้าย — ตรวจสอบ

เหตุผลที่การหยุดเพียงเท่านี้เป็นอันตรายก็เพราะ AI โกหกอย่างฟังดูสมเหตุสมผล จึงต้องทำให้มันตั้งข้อสงสัยผลลัพธ์ที่เพิ่งสร้างขึ้นเอง

ช่วยตรวจอีกครั้งว่าตารางที่เพิ่งทำให้ตรงกับต้นฉบับไหม มีรายการที่ตกหล่นไหม

จากนั้น Claude Code จะอ่านต้นฉบับอีกครั้ง เทียบกับผลลัพธ์ของตัวเองทีละบรรทัด แล้วรายงานจุดที่ไม่ตรงกัน ในช่วงนี้มักปรากฏหน้าจอแบบนี้บ่อยครั้ง

ช่วยตรวจอีกครั้งว่าตารางที่เพิ่งทำให้ตรงกับต้นฉบับไหม มีรายการที่ตกหล่นไหม


เทียบต้นฉบับ (meeting_0603.md) กับตารางที่เพิ่งทำอีกครั้งแล้ว
พบจุดที่ไม่ตรงกัน 3 รายการ

  ⚠ ตกหล่น   "ปรับลดรางวัลทูทอเรียลลง 50%" — มีในแถวที่ 12 ของต้นฉบับแต่ตกหล่นในตาราง
  ⚠ เขียนผิด  ผู้รับผิดชอบ "คิม OO" → ในตารางกรอกผิดเป็น "อี OO"
  ⚠ คลุมเครือ "พิจารณารีวอร์ดใหม่" — ต้นฉบับไม่ชัดเจนว่าตัดสินใจแล้วหรือพักไว้
           ได้ใส่ไว้ใน 'ตัดสินใจแล้ว' ตามดุลยพินิจเอง แต่จำเป็นต้องยืนยัน

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

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

เมื่อผ่านไป 30 นาที ความรู้สึกห่างเหิน 80% หายไปแล้ว ส่วนอีก 20% ที่เหลือจะค่อย ๆ ลดลงในบทถัด ๆ ไป

1.1.4 ภาพที่เห็นในบริษัท — 6 เดือนของทีมขนาดกลาง

โปรเจกต์ MMORPG แห่งหนึ่งที่ผู้เขียนดูแลในฐานะ Design Director (ต่อไปเรียกว่า "โปรเจกต์ A") ได้ดำเนินเวิร์กโฟลว์ที่มี Claude Code เป็นศูนย์กลางร่วมกับทีมออกแบบ (4 ถึง 5 คน) มาประมาณ 6 เดือน (ทีมพัฒนาทั้งหมดของโปรเจกต์ A เป็นขนาดกลาง 10 ถึง 50 คน) ขอยกภาพมาบางส่วน

ขอแยกออกมาเพียงกรณีเดียวที่จับต้องได้ที่สุดด้วยการวัดจริง นั่นคือการตรวจสอบความสอดคล้องของ FK (foreign key, คีย์นอก) ที่พาดผ่านชีตข้อมูลกว่า 30 ชีต เป็นงานที่ใช้สายตามนุษย์ไล่ตามว่า ID ของชีตหนึ่งถูกอ้างอิงอย่างถูกต้องในอีกชีตหรือไม่ ยิ่งชีตเพิ่มขึ้น การจับคู่ก็ยิ่งเพิ่มแบบทวีคูณ

• Before: นักออกแบบหนึ่งคนเปิดชีตสลับไปมาเพื่อเทียบ ID ไล่ครบกว่า 30 ชีตหนึ่งรอบใช้เวลาครึ่งวัน (ประมาณ 4 ชั่วโมง) หากสมาธิขาดกลางคันก็จะมีแถวที่หลุดไป
• After: เครื่องมือตรวจจับความสัมพันธ์เทียบ FK ระหว่างชีตโดยอัตโนมัติ แล้วแสดงเฉพาะการอ้างอิงที่ขาดออกมาเป็นรายการ ไล่หนึ่งรอบประมาณ 5 นาที

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

• การดึงสิ่งที่ตัดสินใจจากบันทึกประชุม (สะสม 5 ถึง 10 รายการต่อสัปดาห์): งานที่มนุษย์เคยติดตามด้วยการค้นหาและเลื่อนดู → ตารางดึงข้อมูลอัตโนมัติ ภาระการติดตามเกือบหายไป
• ร่าง GDD (Game Design Document): เวลาเขียนลดลงเหลือไม่ถึงครึ่ง แต่แทนที่ด้วยเวลาตรวจทานและขัดเกลาที่เพิ่มขึ้น ปริมาณรวมลดลงแต่จุดศูนย์ถ่วงของงานย้ายจาก 'การเขียน' ไปสู่ 'การตัดสินใจ'
• แผนผังความสัมพันธ์ของชีตข้อมูล: โครงสร้างการพึ่งพาที่เคยอธิบายซ้ำด้วยวาจาในที่ประชุม → สร้างเป็น HTML แบบอินเทอแร็กทีฟครั้งเดียวแล้วแชร์

เวลาที่ประหยัดสะสมตลอด 6 เดือนหลังจากเครื่องมือแต่ละตัวถูกสร้างขึ้นครั้งเดียวนั้น สำหรับความรู้สึกของผู้เขียนคิดเป็นหน่วยคน-เดือน (person-month) ไม่ใช่คน-สัปดาห์ (person-week) (การรวมยอดที่แม่นยำยังไม่ได้วัด เป็นค่าประมาณ) ด้วยเวลานั้นจึงสามารถทุ่มเทกับการออกแบบที่ลึกขึ้นได้

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

1.1.5 ความกลัวและความคาดหวัง — จัดการอย่างตรงไปตรงมา

ขอชี้ความกลัวที่นักออกแบบเกมมักมีต่อหน้าเครื่องมือ AI อย่างตรงไปตรงมา การจัดการโดยไม่หลีกหนีคือขั้นตอนแรกของการนำเข้ามาใช้

ความกลัวที่ว่า "AI จะมาแทนที่งานของฉัน" นั้นถูกครึ่งหนึ่งและผิดครึ่งหนึ่ง งานจุกจิกง่าย ๆ (ตรวจสอบความสอดคล้อง·แปลงเอกสาร·ค้นหา) AI แทนที่ได้ แต่การตัดสินใจ การจัดลำดับความสำคัญ และการออกแบบอารมณ์ของผู้เล่นนั้นแทนที่ไม่ได้ ตรงกันข้าม นักออกแบบเกมที่ใช้ AI ได้ดีจะหลุดพ้นจากงานจุกจิกแล้วทุ่มเทกับแก่นแท้ ลองถามตัวเองดูว่า "สัดส่วนของงานจุกจิกกับแก่นแท้ในงานของฉันเป็นเท่าไร" หากงานจุกจิกเป็น 70% แก่นแท้อีก 30% ก็ยังคงเป็นหน้าที่ของตัวเองอยู่ดี และประเด็นสำคัญคือ 30% นั้นจะยิ่งสำคัญมากขึ้น

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

ความกลัวที่ว่า "ไม่ค่อยรู้เรื่องโค้ดเลยใช้ไม่ได้" จะคลายลงในไม่ช้า Claude Code ทำงานด้วยภาษาธรรมชาติ ดังนั้นไม่รู้เรื่องโค้ดก็เริ่มได้ตามที่ไม่รู้นั้น เพราะได้อ่านสคริปต์ที่ AI สร้างไปด้วยกัน พอผ่านไปสักสองสามเดือนก็จะอ่านและแก้ไขสคริปต์ง่าย ๆ ได้ การเรียนรู้จะตามมาเองโดยอัตโนมัติ

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

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

1.1.6 วิธีใช้หนังสือเล่มนี้

หนังสือเล่มนี้ประกอบด้วย 24 ส่วน ไม่จำเป็นต้องอ่านเรียงลำดับตั้งแต่ต้นจนจบ เลือกหนึ่งในสามรูปแบบต่อไปนี้ที่เหมาะกับสถานการณ์ของตัวเองได้

หากยังนึกไม่ออกว่าจะเลือกเส้นทางไหน แบ่งตามว่าตัวเองใกล้เคียงกับอะไรก็ได้ หากคุณเป็นนักออกแบบนอกวงการเกม·PM·พนักงานบริษัททั่วไป แทนที่จะใช้สามรูปแบบข้างต้น ขอแนะนำ 「เส้นทางของงานทั่วไป」 (ส่วนที่ 1·2 → ส่วนที่ 17 บันทึกประชุม → ส่วนที่ 16 การทำงานร่วมกัน → ส่วนที่ 18 การตัดสินใจ → ส่วนที่ 21·22 การพัฒนาตนเอง·ธรรมาภิบาล) — แม้ข้ามบทที่เป็นโดเมนเกมไป โครงกระดูกหลักก็ยังตั้งอยู่ได้ตามเดิม และกล่อง 「การประยุกต์นอกเกม」 ในแต่ละบทเป็นสะพานให้ย้ายไปอ่านในแง่งานของตัวเอง (ดัชนีอยู่ในภาคผนวก F.5) หากไม่มีเวลา ตามไปเพียงสี่บท 17.1 → 16.2 → 22.1 → 21.1 ก็ได้ หากคุณเป็นผู้อ่านที่ไม่ได้เรียนมาทางนี้และเพิ่งเริ่มใช้เครื่องมือ AI ให้ใช้ 'รูปแบบเริ่มต้นนำเข้า' ยึดสาขาของตัวเอง (หรือสาขาที่ใกล้เคียงที่สุด) เพียงสาขาเดียวจนจบ ส่วนสาขาที่ลงลึก (4·8·11 ฯลฯ) ให้เก็บเฉพาะ 'บรรทัดเดียวสำหรับผู้ที่ไม่ได้เรียนมาทางนี้' ในส่วนนำของบทไว้ก่อน แล้วค่อยลงไปยังเนื้อหาเมื่อจำเป็น

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

1.1.7 เชื่อมต่อไปยังบทถัดไป

หัวข้อ 1.1 เป็นบทที่ลดความรู้สึกห่างเหิน ส่วนหัวข้อ 1.2 จะก้าวเข้าไปอีกขั้น แล้วอธิบายกลไกพื้นฐานของเครื่องมือนี้ด้วยภาษาที่เป็นมิตรต่อนักออกแบบเกม เป้าหมายของหัวข้อ 1.2 คือทำให้ไม่กลัวคำอย่างโมเดล·โทเค็น·คอนเท็กซ์·ฮาร์เนส ส่วนการตั้งค่าอย่างจริงจัง (เมโมรี·สิทธิ์·settings.json) จะกล่าวถึงในหัวข้อ 1.3

สรุปประเด็นสำคัญของบท

• ความรู้สึกห่างเหินในการพบกันครั้งแรกไม่ใช่ข้อบกพร่องของเครื่องมือ แต่เป็นต้นทุนการปรับตัวของคนที่คุ้นเคยกับ GUI
• Claude Code ไม่ใช่แชตบอต แต่ใกล้เคียงกับเพื่อนร่วมงานข้างโต๊ะที่จัดการทั้งโฟลเดอร์
• เมื่อผ่านการมอง·ค้นหา·แปลง·ตรวจสอบใน 30 นาทีแรกอย่างละครั้ง ความรู้สึกห่างเหิน 80% จะหายไป

ตัวอย่างบทถัดไป

• บทที่ 2. โมเดล AI·โทเค็น·ฮาร์เนส — กลไกพื้นฐานสำหรับนักออกแบบเกม

ลองทำดู

setup 1. เปิดเทอร์มินัล (Windows ใช้ PowerShell, macOS ใช้เทอร์มินัล) 2. ย้ายไปยังโฟลเดอร์ที่รวมเอกสารออกแบบไว้ แล้วรัน Claude Code (การติดตั้งอยู่ในหัวข้อ 1.0) 3. ตั้งเวลา 30 นาที — 5 นาที (มอง)·5 นาที (ค้นหา)·10 นาที (แปลง)·10 นาที (ตรวจสอบ)

prompt (หนึ่งบรรทัดต่อหนึ่งช่วง ลองพิมพ์ตามลำดับ)

① ช่วยสรุปให้หน่อยว่าในโฟลเดอร์นี้มีอะไรบ้าง
② ไฟล์ที่มีคำว่า 'รีวอร์ด' อยู่ที่ไหน
③ ดึงเฉพาะสิ่งที่ตัดสินใจจากบันทึกประชุมนี้มาทำเป็นตารางหน่อย
④ ช่วยตรวจอีกครั้งว่าตารางที่เพิ่งทำตรงกับต้นฉบับไหม มีรายการที่ตกหล่นไหม

verify - ในข้อ ① ให้เทียบด้วยสายตาว่าการสรุปโครงสร้างโฟลเดอร์ตรงกับโฟลเดอร์จริงหรือไม่ - ในข้อ ④ หากรายงานจุดที่ไม่ตรงกันออกมาแม้เพียงรายการเดียวก็ถือว่าสำเร็จ หมายความว่าคุณได้เห็นฉากที่ AI ตั้งข้อสงสัยผลลัพธ์ของตัวเองกับตา - แม้คำตอบจะเพี้ยนออกมาก็ไม่ใช่ความล้มเหลว การร้องขอใหม่อย่าง "คำตอบเมื่อกี้ผิด ช่วยดูเฉพาะไฟล์นี้อีกครั้ง" ก็นับเป็นส่วนหนึ่งของการฝึก 30 นาทีแรกด้วย

ฉบับย่อสำหรับคนเดียว

หากคุณเป็นบุคคลที่ไม่มีทั้งทีมและโฟลเดอร์บริษัท ให้ลองพิมพ์เฉพาะ prompt ข้อ ① และ ④ ข้างต้นในโฟลเดอร์ทำงานใด ๆ บน PC ของตัวเอง (เช่น โฟลเดอร์ดาวน์โหลด โฟลเดอร์บันทึกย่อ) เมื่อยืนยัน "มันเข้าใจภาษาธรรมชาติ" ด้วยข้อ ① และ "สามารถตั้งข้อสงสัยผลลัพธ์ได้" ด้วยข้อ ④ แก่นสำคัญสองอย่างของบทนี้ก็สัมผัสได้ภายใน 5 นาทีแม้อยู่คนเดียว

1.2 โมเดล·โทเค็น·ฮาร์เนส — เส้นทางที่โทเค็นของงานหนึ่งไหลผ่าน

เรื่องนี้เกิดขึ้นตอนที่ผมทำงานชิ้นหนึ่งเสร็จแล้วมองดูปริมาณการใช้งาน บันทึกการประชุมห้าฉบับของสัปดาห์นี้กองอยู่ในโฟลเดอร์ และก่อนการประชุมสแตนด์อัปเช้าวันจันทร์ ผมต้องสรุป "เฉพาะสิ่งที่ตัดสินใจกันแล้ว" ลงในหน้าเดียว ผมพิมพ์ข้อความบรรทัดหนึ่งลงในหน้าต่าง Claude Code "ช่วยดึงเฉพาะข้อตัดสินใจจากบันทึกการประชุมในโฟลเดอร์นี้มาทำเป็นตาราง" หลังจากกด Enter ไปราว 0.4 วินาที ก็มีตัวอักษรสีเทาเล็ก ๆ กะพริบขึ้นที่ด้านล่างของหน้าจอ

Reading meeting-2026-05-25.md ... (1,840 tokens)
Reading meeting-2026-05-27.md ... (2,310 tokens)

ตัวอักษรสีเทานี้คือหัวข้อของบทนี้ เมื่อเราโยนประโยคภาษาเกาหลีหนึ่งประโยคเข้าไป เครื่องมือจะหั่นมันเป็นโทเค็น อ่านไฟล์เป็นโทเค็นแล้วป้อนให้โมเดล รับคำตอบของโมเดลมาเขียนลงไฟล์ ทุกครั้งที่การไป-กลับนี้หมุนรอบหนึ่ง ก็จะมีการคิดค่าใช้จ่าย และมีข้อมูลสะสมอยู่ใน "มุมมอง" ของโมเดล บทนี้จะแยกสิ่งที่เกิดขึ้นเบื้องหลังตัวอักษรสีเทานั้นออกมาด้วยภาษาของนักออกแบบเกม สี่คำก็พอ — โมเดล·โทเค็น·context window·ฮาร์เนส

บันทึกศัพท์ - โมเดล (model): สมองที่สร้างคำตอบ มีหลายชนิดที่ขนาดและนิสัยต่างกัน เช่น Opus·Sonnet·Haiku - โทเค็น (token): ชิ้นส่วนที่หั่นตัวหนังสือออกเป็นชิ้นเล็ก ๆ ค่าใช้จ่าย·ความเร็ว·มุมมอง ล้วนนับด้วยหน่วยนี้ทั้งสิ้น - context window: จำนวนโทเค็นสูงสุดที่โมเดลบรรจุไว้ในหัวได้ในคราวเดียว - ฮาร์เนส (harness): ตัวถังที่ทำให้โมเดลทำงานได้ Claude Code คือตัวอย่างหนึ่งของมัน

1.2.1 ลูปของฮาร์เนส — ตัวตนของตัวอักษรสีเทา

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

flowchart TD
    Start([คน: สั่งงานหนึ่งบรรทัด]) --> Read[ฮาร์เนส: อ่านไฟล์·ข้อมูล
แปลงเป็นโทเค็น]
    Read --> Inject[ฮาร์เนส: ฉีดเข้า context
+ รวมโทเค็นสะสม]
    Inject --> Model{โมเดล: ตัดสินใจการกระทำถัดไป}
    Model -->|ต้องรันคำสั่ง| Exec[ฮาร์เนส: รันคำสั่งเชลล์·สคริปต์]
    Exec --> Result[ป้อนผลลัพธ์การรัน
กลับเข้าเป็นโทเค็น]
    Result --> Inject
    Model -->|คำตอบพร้อมแล้ว| Write[ฮาร์เนส: เขียนไฟล์·แสดงผล]
    Write --> Verify{ผ่านการตรวจสอบ?}
    Verify -->|ไม่ผ่าน| Inject
    Verify -->|ผ่าน| Done([บันทึกผลลัพธ์])
    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class Start,Verify human
    class Read,Inject,Exec,Write code
    class Model ai
    class Result data
    class Done pass

ในภาพนี้ ช่องที่คนลงมือมีเพียงสองช่องคือบนสุด (สั่งงาน) และล่างสุด (ตรวจยืนยันผลการตรวจสอบ) ส่วนวงตรงกลางฮาร์เนสหมุนเองโดยอัตโนมัติ ที่ตัวอักษรสีเทากะพริบห้าครั้งระหว่างอ่านบันทึกการประชุมห้าฉบับ ก็คือการหมุนช่อง Read → Inject ไปห้ารอบ ถ้าเป็นแชตบนเว็บ เราต้องเปิดไฟล์ทั้งห้ามาคัดลอก·วางเองทีละไฟล์ การที่ฮาร์เนสทำงานนั้นแทนเราได้ นี่คือความต่างชี้ขาดที่ทำให้แชตบอตกับฮาร์เนสแบบ CLI กลายเป็นเครื่องมือคนละชนิด

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

1.2.2 โทเค็น — เงินตราจริงที่งานหนึ่งใช้จ่าย

โทเค็นไม่ใช่ตัวอักษร แต่เป็นชิ้นส่วนที่โมเดลหั่นตัวหนังสือออกมา ตามหลักประสบการณ์ ภาษาอังกฤษราว 4 ตัวอักษรเท่ากับ 1 โทเค็น ภาษาเกาหลีราว 2 ตัวอักษรใกล้เคียง 1 โทเค็น (ไม่ใช่อัตราแปลงทางการ แต่เป็นค่าประมาณสำหรับใช้งานจริง — ค่าจริงนั้นตัวตัดโทเค็น (tokenizer) ของโมเดลเป็นผู้กำหนด และต่างกันไปในแต่ละประโยค) ภาษาเกาหลีรวมเว้นวรรค 20 ตัวอักษรก็ราว 10 โทเค็น

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

มีสองสิ่งที่สะดุดตา หนึ่ง คำสั่งที่ผมพิมพ์มีแค่ 25 โทเค็น แต่ทั้งงานมีเฉพาะอินพุตเกินหนึ่งหมื่นหนึ่งพันโทเค็น ค่าใช้จ่ายเกือบทั้งหมดไม่ได้มาจากประโยคของผม แต่มาจากข้อมูลที่เครื่องมืออ่านเข้าไป สอง เอาต์พุต (1,810) เป็นราวหนึ่งในหกของอินพุต (11,225) งานอัตโนมัติด้านการออกแบบเกมส่วนใหญ่อ่านมากเขียนน้อยแบบนี้ ดังนั้นหากต้องการลดค่าใช้จ่าย การจัดการปริมาณข้อมูลอินพุตได้ผลกว่าการขัดเกลาเอาต์พุตมากนัก

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

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

1. การฉีดแบบ JIT — ไม่บรรทุกข้อมูลทั้งหมดไว้ล่วงหน้า แต่ดึงมาด้วยการจับคู่คีย์เวิร์ดเฉพาะเมื่อจำเป็น "การฉีดกฎการจัดหมวด 480 โทเค็น" ในตารางข้างบนคือตัวอย่างนั้น ไม่ใช่เอกสารกฎการจัดหมวดการประชุมทั้งฉบับ (หลายพันโทเค็น) แต่เข้ามาเพียง atom ที่จับคู่ได้หนึ่งรายการ
2. แคชบทสรุป — เอกสารยาวให้แยกฉบับสรุปสำหรับ AI ออกจากต้นฉบับสำหรับคน AI จะอ่านฉบับสรุป
3. การแบ่ง atom — ถ้าบรรจุข้อตัดสินใจเดียวต่อหนึ่งไฟล์ (รายละเอียดในข้อ 2.2) ก็ดึงเฉพาะชิ้นที่ต้องการได้อย่างแม่นยำ ประหยัดโทเค็น
4. การจัดระเบียบ context — เมื่อเซสชันยาวขึ้นก็บีบอัด Claude Code รองรับการบีบอัดอัตโนมัติ
5. การเลือกโมเดล — ถ้าใช้โมเดลใหญ่กับงานแปลงข้อมูลง่าย ๆ โทเค็นเท่ากันก็ค่าใช้จ่ายแพงขึ้น นี่คือหัวข้อของหัวข้อถัดไป

ในจำนวนนี้ ข้อ 1 การฉีดแบบ JIT คือกลไกที่หมุนอยู่จริงในสภาพแวดล้อมการทำงานของหนังสือเล่มนี้ เมื่ออินพุตหนึ่งบรรทัดเข้ามา ฮุก inject_memory.py จะจับคู่ atom ในหน่วยความจำตามลำดับคะแนน คัดเฉพาะไม่กี่อันดับแรกมาฉีด และแม้ล้มเหลวก็ไม่ขวางการไหลของงาน (รายละเอียดการอิมพลีเมนต์อยู่ใน 1.3) หลักการประหยัดโทเค็นที่ว่า "เฉพาะข้อมูลที่จำเป็น เฉพาะไม่กี่อันดับแรก ล้มเหลวก็เงียบ ๆ" บรรจุอยู่ในไฟล์โค้ดไฟล์เดียวอย่างนั้นเลย

1.2.3 โมเดล — ตัวถังเดียวกัน เครื่องยนต์ต่างกัน

โมเดลเปรียบเหมือนเครื่องยนต์รถยนต์ บนตัวถังเดียวกันที่ชื่อ Claude Code เราสามารถใส่เครื่องยนต์ต่างกันอย่าง Opus·Sonnet·Haiku ได้ เปลี่ยนเครื่องยนต์แล้วลักษณะของงานก็เปลี่ยน

เมื่อเทียบกับงานออกแบบเกมก็แบ่งได้อย่างนี้ งานที่ต้องการการให้เหตุผลลึกและความสอดคล้อง เช่น การตรวจการออกแบบระบบหรือการสังเคราะห์ร่าง GDD (Game Design Document, เอกสารออกแบบเกม — เอกสารสเปกละเอียด) ที่รวมข้อมูลหลายแหล่ง ใช้ Opus งานประจำส่วนใหญ่ เช่น การดึงข้อตัดสินใจจากบันทึกการประชุมหรือบทสรุปรายวัน ใช้ Sonnet งานที่แทบไม่มีการตัดสิน เช่น การแปลงรูปแบบของชีตข้อมูลง่าย ๆ ก็ส่งไปที่ Haiku ที่งานบันทึกการประชุมในหัวข้อก่อนหน้ารันด้วย Sonnet ก็ด้วยเกณฑ์นี้ — งานคัดข้อตัดสินใจมาย้ายลงตารางนั้น ความสมดุลและความเร็วเหมาะกว่าการให้เหตุผลลึก

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

• การเขียนการทบทวนรายวัน → ใช้ Sonnet อัตโนมัติ
• การรีวิวการออกแบบระบบ → ใช้ Opus อัตโนมัติ
• การตรวจความสอดคล้องของชีตข้อมูล → ใช้ Haiku อัตโนมัติ

การตรึงเช่นนี้ทำได้โดยระบุโมเดลไว้ใน settings.json หรือในคำสั่งสแลช (รายละเอียดใน 1.3) ตรึงไว้ครั้งเดียว ความยุ่งยากในการเลือกทุกครั้งก็หายไป

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

1.2.4 context window — ขีดจำกัดที่ลูปเติมจนเต็ม

ผมบอกไปแล้วว่าทุกครั้งที่ลูปหมุนหนึ่งรอบ โทเค็นจะสะสมที่ช่อง Inject เพดานที่การสะสมนั้นชนคือ context window กล่าวคือจำนวนโทเค็นสูงสุดที่โมเดลประมวลผลได้ในคราวเดียว ถ้าเทียบกับคนก็คือความจำใช้งาน (working memory)

• ตระกูล Claude 4: มาตรฐาน 200K โทเค็น มีตัวเลือกขยาย 1M โทเค็น
• 200K โทเค็น ≈ ปริมาณราว 400 หน้า A4 โดยอิงภาษาเกาหลี

งานบันทึกการประชุมข้างต้นมีอินพุตสะสมในระดับหนึ่งหมื่นหนึ่งพันโทเค็น เทียบกับเพดาน 200K แล้วราว 6% เศษ จึงยังเหลือเฟือ แต่ถ้าไม่เปลี่ยนงานแล้วลากเซสชันยาวอยู่ในหน้าต่างเดิม ก็จะเข้าใกล้เพดาน เมื่อเต็มแล้ว เนื้อหาเก่าจะถูกตัด โมเดลเริ่มลืม "ความทรงจำ" ส่วนต้น และการบีบอัดอัตโนมัติจะทำงานแทนที่บทสนทนาก่อนหน้าด้วยฉบับสรุป

นิสัยที่ใช้จัดการเพดานนี้มีสี่อย่าง

กรณีหนักที่นักออกแบบเกมเจอบ่อยคืองานที่ต้องใช้ทั้งเอกสารการประชุม·เอกสารออกแบบ·ชีตข้อมูลพร้อมกัน ตอนนั้นตัวเลือก 1M มีประโยชน์ เพียงแต่ 1M มาพร้อมภาระค่าใช้จ่ายและความเร็ว ปกติ 200K ก็เพียงพอ และจะหยิบ 1M ออกมาเฉพาะเมื่อกองข้อมูลใหญ่จริง ๆ เท่านั้น

1.2.5 เมื่อฮาร์เนสกรองความเท็จได้จริง — ช่องตรวจสอบ

กลับมาที่ช่อง ผ่านการตรวจสอบ? ล่างสุดของภาพลูป หากไม่มีช่องนี้ คำโกหกที่ดูน่าเชื่อของโมเดลก็จะถูกบันทึกลงไฟล์ตรง ๆ บางครั้งโมเดลก็เสนอคำตอบที่ผิดอย่างมั่นใจราวกับเป็นคำตอบที่ถูก (อาการหลอน, hallucination) ความถี่นั้นลดลงเมื่อรุ่นสูงขึ้น แต่ไม่ถึงศูนย์ จึงต้องตั้งการตรวจสอบไว้เป็นช่องประจำ

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

การตรวจสอบมีอยู่ห้ารูปแบบ

1. การเทียบกับต้นฉบับ — นำเอาต์พุตของ AI มาเทียบกับข้อมูลต้นฉบับอีกครั้ง ("ช่วยตรวจว่าสิ่งนี้มีอยู่ในข้อมูลนั้นจริงหรือไม่")
2. การแปลงสองทาง — เปลี่ยน A→B แล้วแปลงกลับ B→A เพื่อดูว่าตรงกันหรือไม่
3. การตรวจตัวอย่าง — ให้คนตรวจเอาต์พุตแบบสุ่ม 3\~5 รายการด้วยตนเอง
4. ระบบอัตโนมัติด้วย Linter — ตรวจอัตโนมัติว่าเอาต์พุตละเมิดรูปแบบ·ช่วง·กฎที่กำหนดไว้หรือไม่
5. การตรวจไขว้สองโมเดล — ให้ Opus ตรวจเอาต์พุตของ Sonnet

ไม่ได้ทำทั้งห้าทุกครั้ง แต่เลือก 1\~3 อย่างตามระดับความเสี่ยงของงาน ในงานบันทึกการประชุม ผมรวมข้อ 4 Linter ("ในข้อตัดสินใจมีผู้รับผิดชอบ·เนื้อหา·กำหนดเวลาครบหรือไม่") เข้ากับข้อ 3 การตรวจตัวอย่างหนึ่งครั้ง บรรทัดสุดท้ายของตารางโทเค็นก่อนหน้า "ป้อนซ้ำเพื่อตรวจสอบ 320 โทเค็น" ก็คือการไป-กลับที่ Linter จับรายการตกหล่นได้แล้วถามกลับไปยังโมเดลนั้นเอง ถ้าเทียบกับภาพลูปก็คือการหมุนเพิ่มอีกหนึ่งรอบจาก ไม่ผ่านการตรวจสอบ → Inject

ถ้าให้คนตรวจสอบทั้งหมดทุกครั้ง ผลของการนำมาใช้ก็ลดครึ่ง การตรวจสอบจึงเป็นเป้าหมายของการทำให้อัตโนมัติด้วย การดึงข้อตัดสินใจจากบันทึกการประชุมให้ Linter ตรวจรายการที่ตกหล่นในรูปแบบ การแปลงชีตข้อมูลให้ตรวจความสอดคล้องของจำนวนแถว·ผลรวม·foreign key การสร้าง GDD อัตโนมัติให้ตรวจหัวข้อสำคัญที่ตกหล่น ทั้งหมดตรวจอัตโนมัติ ผ่านแล้วคนไม่ต้องดูก็ได้ ดูเฉพาะที่ไม่ผ่าน เป็นภาพของการหยิบเฉพาะโฟลเดอร์ที่ติดธงแดงขึ้นมาจากกองเอกสารที่เต็มตู้ การออกแบบให้สายตาของคนตกลงเฉพาะที่อันตรายเท่านั้น คือจุดประสงค์ของการทำการตรวจสอบให้อัตโนมัติ

1.2.6 จุดที่สี่คำถูกร้อยเข้าด้วยกันเป็นงานหนึ่ง

ทีนี้มาสรุปงานบันทึกการประชุมนั้นตั้งแต่ต้นจนจบ ว่าสี่คำถูกร้อยเข้าในบรรทัดเดียวอย่างไร

ถ้าทำด้วยมือ การเปิดอ่านบันทึกการประชุมห้าฉบับ คัดเฉพาะข้อตัดสินใจมาคัดลอก แล้วจัดรูปแบบ จะใช้เวลา 30 นาที พอทำเป็นอัตโนมัติก็ลดเหลือ 5 นาที และในห้านาทีนั้น มือของคนทำเพียงงานเดียวคือกวาดดูตัวอย่างการตรวจสอบหนึ่งครั้ง เวลาของคนจะตกลงเฉพาะที่ต้องการมันจริง ๆ เท่านั้น (ว่าเรื่องที่พักไว้ไม่ได้ถูกยกขึ้นเป็นข้อตัดสินใจผิด ๆ หรือไม่) แก่นไม่ได้อยู่ที่ 25 นาทีที่ประหยัดได้ แต่อยู่ที่ตำแหน่งที่สายตาตกลงไปนั้นเปลี่ยนไป

1.2.7 ความเข้าใจผิดที่พบบ่อย

"Opus ดีกว่าเสมอ" คือสิ่งที่พบบ่อยที่สุด ถ้าไม่สนใจค่าใช้จ่าย·ความเร็วก็จริงอยู่ แต่กับงานง่าย ๆ Opus คือความสิ้นเปลือง การจับคู่ตามงานคือคำตอบ

"context 1M จำเป็นเสมอ" ก็โผล่มาบ่อย ส่วนใหญ่ 200K ก็เพียงพอ และ 1M มาพร้อมภาระ จึงใช้เฉพาะกับกองข้อมูลที่ใหญ่จริง ๆ

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

"ไม่ต้องใส่ใจโทเค็นก็ได้" ในงานส่วนตัวก็พอใช้ได้ระดับหนึ่ง แต่พอหลายคนใช้ร่วมกัน ค่าใช้จ่ายสะสมจะโตขึ้นเร็ว การปลูกฝังรูปแบบการทำให้มองเห็น·การประหยัดตั้งแต่แรกจะปลอดภัยกว่า

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

1.2.8 ลองทำดู

ลองหมุนสี่คำของบทนี้ด้วยตนเองผ่านงานเล็ก ๆ ชิ้นหนึ่ง

setup

• ในสภาพที่ติดตั้ง Claude Code แล้ว ให้เตรียมโฟลเดอร์หนึ่งที่มีโน้ตข้อความ (บันทึกการประชุม·บันทึกย่อ) 2\~3 ไฟล์
• เปิด Claude Code ในโฟลเดอร์นั้น

prompt

ช่วยคัดเฉพาะ "สิ่งที่ตัดสินใจกันแล้ว" จากโน้ตในโฟลเดอร์นี้
มาทำเป็นตาราง 3 คอลัมน์ ผู้รับผิดชอบ·เนื้อหา·กำหนดเวลา
เรื่องที่พักไว้·ยังหารือกันอยู่ให้ตัดออก และในแต่ละบรรทัดที่ใส่ในตาราง
ให้ระบุชื่อไฟล์ด้วยว่ามาจากไฟล์ใด

verify

• เมื่องานเสร็จ ให้พิมพ์ /context เพื่อดูโทเค็นที่เซสชันนี้ใช้ (คุณจะได้เห็นว่าอินพุตใหญ่กว่าที่คิด)
• เลือกสักหนึ่งหรือสองบรรทัดในตาราง เปิดไฟล์ตามชื่อที่ระบุไว้ แล้วเทียบกับต้นฉบับว่าเขียนไว้ว่าเป็น "ข้อตัดสินใจ" จริงหรือไม่ (การตรวจสอบแบบเทียบกับต้นฉบับ)
• กวาดดูสักครั้งว่าเรื่องที่พักไว้ไม่ได้ถูกยกขึ้นในตารางผิด ๆ หรือไม่ (การตรวจตัวอย่าง)

ฉบับย่อสำหรับคนเดียว

ถ้าเพิ่งเริ่มใช้เครื่องมือ ให้เก็บแค่สองอย่างจากข้างบนนี้ก็พอ หนึ่ง มอบโน้ตทั้งโฟลเดอร์ไปและอย่าคัดลอก·วางเอง (มอบให้ลูปของฮาร์เนสทำ) สอง ตารางเอาต์พุตให้รับชื่อไฟล์มาพร้อมกันเสมอ แล้วเปิดต้นฉบับดูเฉพาะบรรทัดที่น่าสงสัย การเลือกโมเดลหรือการทำให้โทเค็นมองเห็นได้ ค่อยเพิ่มหลังจากคุ้นแล้วก็ไม่สาย แค่สองนิสัยนี้ — ไม่ขนข้อมูลด้วยมือ และเทียบเอาต์พุตกับต้นฉบับ — ครึ่งหนึ่งของการนำมาใช้ก็เข้าที่แล้ว

สรุปประเด็นสำคัญของบท

• ฮาร์เนสหมุนลูป อ่าน→รัน→ป้อนซ้ำ โดยอัตโนมัติ คนลงมือแค่สองช่องคือสั่งงานและตรวจสอบ
• ค่าใช้จ่ายของงานหนึ่งเกือบทั้งหมดมาจากข้อมูลที่เครื่องมืออ่านเข้าไป ไม่ใช่คำสั่งที่ผมพิมพ์
• โมเดลให้เปลี่ยนสลับตามงาน ส่วนเพดาน context และการตรวจสอบให้จัดการด้วยระบบอัตโนมัติ

ตัวอย่างบทถัดไป

• บทที่ 3 หน่วยความจำ·สิทธิ์·โครงสร้างพื้นฐานการตั้งค่า — ตั้งค่าครั้งเดียวก็เป็นฐานที่ทำงานถาวร

1.3 โครงสร้างพื้นฐาน: หน่วยความจำ สิทธิ์ และการตั้งค่า

ผมเปิดเซสชันใหม่แล้วพิมพ์ว่า "มาดูการปรับสมดุลคูลดาวน์ของสกิลกันหน่อย" ก่อนจะกดเอนเทอร์ มีตัวอักษรสีเทาเล็ก ๆ บรรทัดหนึ่งวาบผ่านที่ส่วนล่างของหน้าจอ [memory injected: 2 atoms, 1,842 chars] แม้ผมจะยังไม่ได้เปิดไฟล์ใด ๆ เลย แต่เอกสารกฎคูลดาวน์ที่ผมตรึงเป็นกฎไว้เมื่อสัปดาห์ก่อนได้ถูกแนบเข้าไปไว้หน้าอินพุตของโมเดลเรียบร้อยแล้ว นี่คือสัญญาณแรกของสภาพแวดล้อมการทำงานที่มีโครงสร้างพื้นฐานวางอยู่ ทันทีที่เปิดเครื่องมือ เครื่องมือก็จดจำผมได้

เพื่อให้ฉากนี้เป็นไปได้ สามสิ่งต้องเข้าที่เข้าทางไว้ก่อน ได้แก่ สิ่งที่ AI จะจดจำ (หน่วยความจำ) สิ่งที่ AI ทำได้โดยไม่ต้องให้คนอนุมัติ (สิทธิ์) และสวิตช์กลางที่เปิด-ปิดทั้งสองอย่างนั้น (settings.json) เวลาที่ใช้ติดตั้งครั้งแรกอย่างมากก็แค่ราวหนึ่งชั่วโมง และหนึ่งชั่วโมงนั้นจะกลับคืนมาเป็นเวลาที่ประหยัดได้ทุกวันตลอด 6 เดือนหลังจากนั้น แทบจะเป็นการลงทุนที่ถอนคืนได้เต็มจำนวน

บทนี้คือการเดินตามทีละขั้น (walkthrough) ของ settings.json หนึ่งบรรทัดที่ผมรันจริงบนพีซีส่วนตัว บรรทัดนั้นเรียก inject_memory.py และไฟล์นั้นอ่าน _jit_manifest.json ตามลำดับ เมื่ออ่านจบ คุณจะสามารถชี้ด้วยมือได้ว่าคำว่า "หน่วยความจำถูกฉีดเข้าไปอัตโนมัติ" นั้นเกิดขึ้นที่บรรทัดไหนของไฟล์ไหน

1.3.1 settings.json — บรรทัดเดียวที่ทุกอย่างเริ่มต้น

ขอดูข้อสรุปก่อน สิ่งที่เปิดการฉีดหน่วยความจำอัตโนมัติบนพีซีส่วนตัวของผมคือบล็อกเพียงบล็อกเดียวภายใน settings.json

{
  "hooks": {
    "UserPromptSubmit": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "python ~/.claude/hooks/inject_memory.py"
          }
        ]
      }
    ]
  }
}

ถ้าจะแปลความหมายของบล็อกนี้ออกมาเป็นภาษาคน ก็คือ "ทุกครั้งที่เกิดเหตุการณ์ที่ผู้ใช้ส่งพรอมต์ (UserPromptSubmit) ให้รันสคริปต์ Python ชื่อ inject_memory.py หนึ่งครั้ง" แค่นั้น ไม่ใช่ว่า AI ฉลาดจนจดจำได้เอง แต่เป็นโครงสร้างที่ทุกครั้งที่มีอินพุตเข้ามา สคริปต์ที่คนลงทะเบียนไว้จะแทรกตัวเข้ามาทำงานหนึ่งครั้ง

settings.json คือไฟล์กลางที่ควบคุมการทำงานทั้งหมดของ Claude Code และแบ่งออกเป็นสองชั้น

• ~/.claude/settings.json — ระดับโกลบอล ใช้กับทุกเซสชัน เป็นการตั้งค่าที่แชร์กับทีมได้
• ~/.claude/settings.local.json — ระดับโลคัล ใช้กับพีซีเครื่องนี้เท่านั้น เป็นการตั้งค่าเฉพาะของพีซีส่วนตัว

ทั้งสองจะถูกผสาน (merge) เข้าด้วยกันแล้วนำไปใช้ ด้วยเหตุนี้ผมจึงแยก hook และสิทธิ์ที่ต้องแชร์กับทีมไว้ใน settings.json ส่วนพาธสัมบูรณ์หรือพาธเครื่องมือส่วนตัวที่ใช้บนพีซีบ้านเครื่องนี้เท่านั้นก็แยกไว้ใน settings.local.json เป็นการแบ่งแยกเพื่อหลีกเลี่ยงการชน (conflict) ของ git ตอนทำงานร่วมกัน และป้องกันอุบัติเหตุที่การตั้งค่าส่วนตัวรั่วไหลเข้าไปใน repository ของทีม

นอกจาก hook แล้ว ยังมีรายการอื่นที่เข้าไปตั้งบ่อยอีกหลายอย่าง

• effortLevel — ความลึกในการให้เหตุผลของโมเดล มี low / medium / high งานที่ต้องใช้การตัดสินใจเชิงลึกอย่างการออกแบบเอกสารออกแบบเกม ก็ตั้งเป็น high
• permissions — ขอบเขตของคำสั่งที่ AI สามารถรันได้โดยไม่ต้องขออนุมัติ (รายละเอียดใน 1.3.4)
• enabledPlugins — รายการปลั๊กอินที่เปิดใช้งาน

ตรงนี้มีนิสัยในการปฏิบัติงานที่สำคัญที่สุดเพียงข้อเดียว settings.json พิมพ์ผิดแค่ตัวเดียวก็อาจทำให้เครื่องมือเปิดไม่ขึ้นได้เลย แค่ลืมใส่จุลภาคของ JSON ตัวเดียว การแจงไวยากรณ์ (parsing) ก็พังแล้ว ฉะนั้นการสำรองข้อมูลก่อนแก้ไขจึงเป็นสิ่งจำเป็น บนพีซีของผมก็มีไฟล์สำรองแบบนี้เก็บไว้จริง

settings.json.bak_2026-05
settings.local.json.bak_2026-05

ถ้าทำสำเนาไว้หนึ่งชุดพร้อมต่อท้ายด้วยวันที่ การย้อนกลับ (rollback) ก็ใช้เวลาแค่ 1 วินาที ถ้าจัดการด้วย git ได้ก็ยิ่งดี เหมือนกุญแจเก่าหนึ่งชุดในลิ้นชัก ปกติไม่ได้ใช้ แต่จะมีสักจังหวะที่จำเป็นต้องใช้แน่ ๆ เมื่อยืนอยู่หน้าประตูที่ถูกล็อก

1.3.2 inject_memory.py — สิ่งที่เกิดขึ้นจริงภายใน hook

ทีนี้เราเข้าไปในสคริปต์ที่ settings.json เรียกใช้ นี่คือกระดูกสันหลังของ walkthrough โค้ดมีประมาณ 100 บรรทัด แต่แก่นอยู่ที่ห้าการกระทำ

flowchart TD
    A["เซสชัน: ผู้ใช้ส่งพรอมต์\nเช่น 'มาดูการปรับสมดุลคูลดาวน์ของสกิลกัน'"] --> B["UserPromptSubmit hook ทำงาน\nsettings.json รัน inject_memory.py"]
    B --> C["โหลด _jit_manifest.json\nเมตาดาตาของ atom 17 ตัว"]
    C --> D["เรียงลำดับจากมากไปน้อยตาม score\n→ ลองจับคู่ regex ทีละ atom"]
    D --> E{"มี atom ที่\nจับคู่ได้หรือไม่?"}
    E -->|ไม่มี| Z["ไม่ฉีดอะไรเลย\nexit 0"]
    E -->|มี| F["เลือกเฉพาะ max_matches(3) ตัวบนสุด"]
    F --> G["ถ้ารวมกันเกิน 6,000 ตัวอักษร\nก็ truncate"]
    G --> H["แนบเนื้อหา atom\nไว้หน้าอินพุตของผู้ใช้"]
    H --> I["โมเดลรับ atom + พรอมต์\nพร้อมกัน → ตอบกลับ"]
    D -.->|ข้อยกเว้นใด ๆ ก็ตาม| Z2["กลืนข้อยกเว้นทุกกรณี\nexit 0 (ไม่ขวางการทำงาน)"]
    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    class A human
    class B,C,D,E,F,G,H code
    class I ai

ถ้าจะอธิบายห้าการกระทำให้กระจ่าง ก็เป็นดังนี้

1) อ่าน manifest ก่อนอื่นสคริปต์จะเปิด ~/.claude/projects/C--Users-user/memory/_jit_manifest.json ไฟล์นี้รวบรวมเมตาดาตาของ atom (ชื่อ พาธ regex สำหรับจับคู่ และคะแนน) ไว้ บนพีซีส่วนตัวของผมในตอนนี้มี atom ลงทะเบียนไว้ 17 ตัว

2) เรียงลำดับจากมากไปน้อยตาม score ทุก atom มีค่า score กำกับ atom ที่คะแนนสูงกว่าจะถูกลองจับคู่ก่อน เวลามีหลาย atom เข้าเงื่อนไขด้วยคีย์เวิร์ดเดียวกัน คะแนนนี้เป็นตัวตัดสินว่าใครได้สิทธิ์ก่อน

3) จับคู่ด้วย regex เปรียบเทียบสตริงอินพุตของผู้ใช้กับแพตเทิร์น regex ของแต่ละ atom ถ้ามีคำว่า "คูลดาวน์" อยู่ในอินพุต atom ที่มีแพตเทิร์น 쿨다운|cooldown|GCD ก็จะเข้าเงื่อนไข การเปรียบเทียบไม่แยกตัวพิมพ์ใหญ่-เล็ก

4) ตัดให้เหลือไม่เกิน 3 ตัว ต่อให้จับคู่ได้มากแค่ไหน ถ้าเกิน max_matches (สภาพแวดล้อมของผมตั้งไว้ที่ 3) ก็จะเก็บไว้แค่ 3 ตัวบนสุด และถ้าความยาวรวมของเนื้อหา atom ที่ถูกเลือกเกิน 6,000 ตัวอักษร ก็จะ truncate เป็นกลไกความปลอดภัยสองชั้นที่ป้องกันไม่ให้อินพุตบวมเกินไป

5) จบด้วย exit 0 ไม่ว่าจะเกิดข้อยกเว้นใด นี่คือแก่นของการออกแบบ ไม่ว่า manifest จะพัง ไฟล์จะหาย หรือ regex จะผิด สคริปต์ก็จะกลืนข้อยกเว้นไว้เงียบ ๆ แล้วจบด้วยโค้ดสถานะ 0 เพราะถ้า hook ตายด้วยโค้ดที่ไม่ใช่ 0 พรอมต์ของผู้ใช้เองก็อาจถูกขวางได้ หลักการที่ว่า "ต่อให้การฉีดหน่วยความจำล้มเหลว ก็จะไม่ขวางการทำงานของผู้ใช้เด็ดขาด" ถูกบันทึกไว้ที่ try/except ชั้นนอกสุดของโค้ด

จุดศูนย์ถ่วงอยู่ที่ข้อ 4 และข้อ 5 ข้อ 4 (เพดานบน) ป้องกันไม่ให้หน่วยความจำทำให้โทเค็นระเบิด ส่วนข้อ 5 (กลืนข้อยกเว้น) ป้องกันไม่ให้โครงสร้างพื้นฐานมาขัดขวางการทำงาน ทั้งสองเป็นสองด้านของปรัชญาเดียวกันที่ว่า "ระบบอัตโนมัติต้องไม่ทำให้คนรู้สึกรุงรัง"

1.3.3 _jit_manifest.json — พจนานุกรมคีย์เวิร์ดที่ปลุก atom ให้ตื่น

ใน 1.2 ผมได้สัญญาถึงหลักการประหยัดโทเค็นที่ว่า "เอาเฉพาะข้อมูลที่จำเป็น เฉพาะไม่กี่ตัวบนสุด และถ้าล้มเหลวก็เงียบ ๆ" แล้วเลื่อนรายละเอียดการนำไปปฏิบัติมาไว้ในบทนี้ รายละเอียดนั้นอยู่ใน manifest ที่ inject_memory.py อ่าน นี่คือหัวใจของ JIT (Just-In-Time วิธีดึงข้อมูลมาเฉพาะตอนที่จำเป็น) และเอนทรีของ atom หนึ่งตัวมีหน้าตาดังนี้

{
  "atoms": [
    {
      "name": "combat_cooldown_rule_v2",
      "path": "atoms/combat/combat_cooldown_rule_v2.md",
      "regex": "쿨다운|cooldown|GCD",
      "score": 80
    },
    {
      "name": "user_health",
      "path": "memory/user_health.md",
      "regex": "건강|복약|컨디션|약물",
      "score": 95
    }
  ],
  "config": {
    "max_matches": 3,
    "case_insensitive": true
  }
}

สี่ฟิลด์ที่นิยาม atom หนึ่งตัว

• name — ชื่อเฉพาะของ atom
• path — พาธของไฟล์ที่จะอ่านเนื้อหามาเมื่อจับคู่ได้
• regex — แพตเทิร์นที่นิยามว่าถ้าคีย์เวิร์ดใดเข้ามาในอินพุตจะปลุก atom นี้
• score — ลำดับความสำคัญในการเรียง ยิ่งสูงยิ่งถูกจับคู่ก่อนและได้ที่นั่งก่อน

max_matches: 3 ในบล็อก config คือที่มาของเพดาน "ไม่เกิน 3 ตัว" ที่เห็นใน 1.3.2 ถ้าแก้ manifest ด้วยมือ การทำงานก็เปลี่ยนทันที

ขอชี้ให้เห็นความรู้สึกเรื่องสเกลสักเรื่อง พีซีส่วนตัว ของผมดำเนินงานอย่างเบาบางด้วย atom 17 ตัวและ manifest เพียงหนึ่งชุด ในทางกลับกัน สภาพแวดล้อมการทำงานจริงในบริษัท (โปรเจกต์ A) นั้น เมื่ออ้างอิงข้อมูลสำรอง ณ เดือนพฤษภาคม 2026 มี atom ของทีมลงทะเบียนไว้ 304 ตัว และ skill 48 ตัว มี Hot atom ตัวหนึ่งที่ score ไต่ขึ้นไปถึง 356.53 (อยู่ในตระกูล view_html_filename_convention ที่ว่าด้วยกฎการตั้งชื่อไฟล์) ซึ่งไม่ได้สูงมาตั้งแต่ต้น แต่เป็นร่องรอยที่สะสมขึ้นจากการถูกเรียกซ้ำและถูกตรวจสอบ

สิ่งที่ความต่างระหว่าง 17 ตัวบนพีซีส่วนตัวกับ 304 ตัวในบริษัทบอกเราก็คือ ต่อให้เป็นกลไก JIT เดียวกัน ความเร็วและขนาดที่ข้อมูลสะสมขึ้นก็แปรผันตามความหนาแน่นของโปรเจกต์ ไม่จำเป็นต้องสร้าง 304 ตัวตั้งแต่ต้น เริ่มจาก atom หลักห้าตัว แล้วตรึงเป็นกฎเพิ่มสัปดาห์ละหนึ่งถึงสองตัว ไม่ทันไร manifest ก็จะหนาขึ้นเอง

การประมาณของผู้เขียน (ยังไม่ได้ตรวจสอบ): คำอธิบายที่ว่า score สะสมขึ้นตามจำนวนครั้งที่จับคู่และถูกตรวจสอบ เป็นการตีความที่อิงจากแพตเทิร์นการดำเนินงาน สูตรการคิดคะแนนเองนั้นแปรเปลี่ยนไปตามการออกแบบ manifest ของแต่ละสภาพแวดล้อม ฉะนั้นค่าสัมบูรณ์อย่าง 356.53 ข้างต้นจึงเป็นเพียงภาพถ่าย ณ ขณะนั้นที่วัดได้จริงในสภาพแวดล้อมของผู้เขียน ไม่ใช่มาตรฐานทั่วไป

ตรงนี้ขอย้ำหลักการที่ว่าหน่วยความจำแบ่งเก็บเป็นสองชั้นอีกครั้ง

การเก็บโกลบอลให้เบาไว้ปลอดภัยกว่า เพราะถ้าโกลบอลหนักขึ้น น้ำหนักนั้นจะสะสมเป็นต้นทุนโทเค็นในทุกเซสชัน ถ้าเปรียบกับสำนักงาน โกลบอลก็คือสมุดนามบัตรบนโต๊ะ (ยิ่งเบายิ่งหยิบใช้สะดวกทุกวัน) ส่วนหน่วยความจำของโปรเจกต์คือแฟ้มในตู้ข้าง ๆ (ต่อให้หนาขึ้นต่อโปรเจกต์ก็ไม่เป็นภาระในยามปกติ) ด้วยเหตุนี้ในโกลบอลที่ถูกโหลดอัตโนมัติจึงควรเก็บแค่แก่น ส่วนข้อมูลที่อุดมสมบูรณ์ให้สะสมไว้ในหน่วยความจำของโปรเจกต์ แล้วค่อยปลุกด้วย JIT เฉพาะตอนที่จำเป็น

1.3.4 สิทธิ์ — ไวต์ลิสต์ที่ร่องรอยการสะสมงานทับถมกัน

ทีนี้มาถึงแกนที่สามของโครงสร้างพื้นฐาน คือสิทธิ์ Claude Code สามารถลบไฟล์ รันคำสั่ง และเรียก API ภายนอกได้ ความทรงพลังมาพร้อมความเสี่ยง ระบบสิทธิ์คือสิ่งที่บริหารจัดการความเสี่ยงนั้น

สิทธิ์แบ่งออกเป็นสองชนิด คือชนิดที่รันอัตโนมัติโดยไม่ต้องให้คนอนุมัติ กับชนิดที่ต้องขออนุมัติทุกครั้ง จะเอาอะไรไว้ฝั่งไหนนิยามได้ในบล็อก permissions ของ settings.json

{
  "permissions": {
    "allow": [
      "Bash(ls:*)",
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Read(*)",
      "Grep(*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)"
    ]
  }
}

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

สภาพแวดล้อมการทำงานในบริษัทของผม (โปรเจกต์ A) มีแพตเทิร์นอนุญาตอัตโนมัติอยู่ราว 80 รายการ เริ่มจาก 20 รายการ แล้วเพิ่มขึ้นมาอีก 60 รายการตลอด 6 เดือน ซึ่งถ้าอ่าน 60 รายการนั้นย้อนกลับ ก็จะเผยว่าผมทำงานอะไรซ้ำ ๆ มาตลอดครึ่งปีที่ผ่านมา การดึงข้อมูลจากชีต การสร้างผังความสัมพันธ์ การจัดทำเอกสารสคีมา — เครื่องมือที่ใช้บ่อยก็คือสิทธิ์ที่อนุญาตบ่อยนั่นเอง

การดำเนินงานเรื่องสิทธิ์มีสี่แพตเทิร์นที่เข้าที่เข้าทาง

• เริ่มจากไวต์ลิสต์ — การอนุญาตอัตโนมัติให้ออกตัวจากน้อยที่สุด แล้วค่อยเพิ่มเฉพาะตอนจำเป็น ไม่ใช่เปิดกว้างไว้แล้วค่อยหรี่ลง แต่เป็นทิศทางปิดแคบ ๆ ไว้แล้วค่อยเปิด
• คำสั่งอันตรายให้บล็อกอย่างชัดเจน — คำสั่งที่อุบัติเหตุครั้งเดียวถึงตายอย่าง rm -rf หรือ git push --force ให้ใส่ไว้ใน deny ต่อให้ขยายการอนุญาตอัตโนมัติแค่ไหน สองตัวนี้ก็อย่าไปแตะ
• จัดระเบียบเป็นระยะ — ทุกไตรมาสให้ทบทวน allow ใหม่ แล้วถอดสิทธิ์ที่เลิกใช้แล้วออก ร่องรอยถ้าเอาแต่สะสมก็จะกลายเป็นสัญญาณรบกวน (noise)
• แยกตามโดเมน — แยกสิทธิ์โกลบอลกับสิทธิ์โปรเจกต์ออกจากกัน เหมือนพีซีบ้านกับพีซีบริษัทมีนโยบายต่างกัน แต่ละสภาพแวดล้อมก็มีขอบเขตการอนุญาตต่างกัน

ถ้ามีป็อปอัปขออนุมัติเด้งขึ้นมาทุกครั้ง คนก็เหนื่อย จึงมีกลไกลดความเหนื่อยล้าด้วย เช่น ใช้คำสั่งสแลชอย่าง fewer-permission-prompts เพื่อลงทะเบียนแพตเทิร์นที่ปรากฏบ่อยทีเดียวทั้งชุด หรือให้สิทธิ์ชั่วคราวเฉพาะภายในเซสชันเดียว หรือใช้โหมดอนุญาตอัตโนมัติเต็มสิทธิ์เฉพาะกับงานส่วนตัวเท่านั้น อย่างไรก็ตาม ตัวเลือกสุดท้ายไม่แนะนำในสภาพแวดล้อมแบบทีม

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

1.3.5 เมื่อเซสชันเริ่มต้น — ภาพที่หน่วยความจำและสิทธิ์ถูกโหลดมาพร้อมกัน

ที่ผ่านมาเราดูสามแกน (settings · หน่วยความจำ · สิทธิ์) มาแล้ว ทีนี้มาคลี่ดูว่าทั้งสามทำงานพร้อมกันอย่างไรในเซสชันเดียว โดยยึดอินพุตหนึ่งบรรทัดเป็นเกณฑ์ ต่อไปนี้คือภาพตัดขวางของสิ่งที่เกิดขึ้นจริงเมื่อพิมพ์ว่า "มาดูการปรับสมดุลคูลดาวน์ของสกิลกัน"

สามเลนมาบรรจบกันที่อินพุตเดียว settings.json ปลุก hook ขึ้นมา hook คัดเลือกหน่วยความจำมาแนบไว้กับอินพุต และเมื่อคำตอบที่สร้างขึ้นเช่นนั้นไปเรียกใช้เครื่องมือ สิทธิ์ก็ทำงานเป็นด่านตรวจสอบสุดท้าย ผู้ใช้แค่พิมพ์ว่า "มาดูคูลดาวน์กัน" บรรทัดเดียว แต่โครงสร้างพื้นฐานทั้งสามกลับทำงานตามลำดับอยู่ในที่ที่มองไม่เห็น นี่คือโครงสร้างภายในของช่วงเวลาที่เครื่องมือรู้สึกเหมือนเป็น "เครื่องมือของผม"

1.3.6 คู่มือการตั้งค่าครั้งแรก — สู่สภาวะพร้อมใช้งานภายใน 1 ชั่วโมง

เมื่อดูทฤษฎีแล้ว ก็ถึงเวลาขยับมือ หลังติดตั้ง Claude Code ครั้งแรก ใช้เวลาหนึ่งชั่วโมงก็วางภาพทั้งหมดข้างต้นลงบนพีซีของตัวเองได้ แบ่งเป็นห้าช่วง

0\~10 นาที ยืนยันการติดตั้งและการรัน หลังติดตั้งแล้วให้รัน Claude Code จากเทอร์มินัล ลองถามในโฟลเดอร์หนึ่งว่า "ในโฟลเดอร์นี้มีอะไรบ้าง?" แล้วดูคำตอบ เริ่มจากดูว่าเครื่องมือยังมีชีวิตอยู่หรือไม่ก่อน

10\~25 นาที เขียนหน่วยความจำโกลบอลสามไฟล์ โกลบอลที่ถูกโหลดอัตโนมัตินั้นมีสามไฟล์ก็เพียงพอ

• MEMORY.md (5 บรรทัด) — ตัวตนของตนเองหนึ่งบรรทัด + ตัวชี้ไปยังไฟล์อื่น
• user-profile.md (20\~30 บรรทัด) — ชื่อ บทบาท สาขาความเชี่ยวชาญ ช่องทางติดต่อ
• feedback-collaboration-style.md (20\~30 บรรทัด) — กฎการทำงานร่วมกัน เช่น ภาษา น้ำเสียง การให้ความสำคัญกับการลงมือทำก่อน และคำอธิบายที่กระชับ

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

25\~40 นาที ตั้งค่า settings.json เบื้องต้น ตั้ง effortLevel เป็น high ใส่ชุดสิทธิ์เริ่มต้น (อ่านและค้นหาให้อัตโนมัติ เขียนและลบต้องอนุมัติ) และทำสำเนาสำรองไว้หนึ่งชุด (settings.json.bak_<วันที่>) การสำรองข้อมูลคือบรรทัดที่สำคัญที่สุดในช่วงนี้

40\~55 นาที atom ห้าตัวแรกของโปรเจกต์ เอาการตัดสินใจที่ตัวเองลืมอยู่ทุกที และข้อมูลที่ถามบ่อยห้าอย่างมาทำเป็น atom โฟลเดอร์คือ ~/.claude/projects/<โปรเจกต์>/memory/ ส่วนรูปแบบให้ดูบทที่ 5 ห้าตัวนี้แม้ยังไม่ทำ JIT manifest ในทันที แค่การโหลดอัตโนมัติของโกลบอลก็ให้ผลแล้ว

55\~60 นาที ทดสอบหนึ่งครั้ง เปิดเซสชันใหม่แล้วโยนคำถามในสาขาของตัวเองสักหนึ่งข้อ ดูว่าหน่วยความจำโกลบอลถูกโหลดอัตโนมัติหรือไม่ และน้ำเสียงของคำตอบเป็นไปตามกฎการทำงานร่วมกันของตัวเองหรือไม่

ถึงตรงนี้ก็หนึ่งชั่วโมง JIT manifest และ hook จะติดตั้งตอนที่ atom เริ่มเกิน 50 ตัว นั่นคือตอนที่การโหลดอัตโนมัติเริ่มหนัก ก็ยังไม่สาย ณ จุดนั้นค่อยติดตั้ง inject_memory.py ของ 1.3.2 ก็ได้

1.3.7 ความผิดพลาดที่พบบ่อยและวิธีเลี่ยง

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

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

1.3.8 ปิดท้ายส่วนที่ 1

1.1 เป็นที่ที่ลดระยะห่างที่มีต่อเครื่องมือ 1.2 เป็นที่ที่จับกลไกการทำงานขั้นต่ำของเครื่องมือนั้น และ 1.3 เป็นที่ที่วางโครงสร้างพื้นฐานชุดแรกด้วยหน่วยความจำ สิทธิ์ และ settings สามบทนี้ถือเป็นบทนำของหนังสือ เมื่อทำถึงตรงนี้จบ โครงกระดูกพื้นฐานสำหรับดำเนินงานเครื่องมือโดยไม่สะดุดก็เข้าที่เข้าทาง

แก่นคือ โครงกระดูกนี้ไม่ใช่การตั้งค่าที่อยู่นิ่ง atom ใน manifest เพิ่มขึ้นทุกสัปดาห์ รายการ allow ยาวขึ้นตามร่องรอยการทำงาน และ score สะสมขึ้นผ่านการตรวจสอบ โครงสร้างพื้นฐานไม่ได้เสร็จสมบูรณ์ในวินาทีที่วางลง แต่เติบโตไปพร้อมกับผู้ใช้บนสิ่งที่วางไว้ ความต่างที่ 17 ตัวบนพีซีส่วนตัวขยายไปสู่ 304 ตัวในบริษัท คือระยะทางของการเติบโตนั้น

ตั้งแต่ส่วนที่ 2 เป็นต้นไป เราจะเข้าสู่สถาปัตยกรรมข้อมูลอย่างจริงจัง บทที่ 4 YAML frontmatter บทที่ 5 Atom บทที่ 6 Layer และบทที่ 7 ออนโทโลยี จะตามมาตามลำดับ atom ที่ใน 1.3 เห็นเพียงในฐานะเอนทรีหนึ่งของ manifest จะกลายเป็นตัวเอกของทั้งบทใน 2.2 ต่อเมื่อจับกระดูกสันหลังได้แล้ว บทแยกตามสาขาแต่ละบทจึงจะหาที่ทางของตัวเองได้บนพิกัดเดียวกัน

สรุปประเด็นสำคัญของบท

• การฉีดหน่วยความจำอัตโนมัติคือโครงสร้างที่ hook หนึ่งบรรทัดใน settings.json ปลุก inject_memory.py ให้ตื่น
• รายการ allow ของสิทธิ์ไม่ใช่การตั้งค่า แต่เป็นร่องรอยของการสะสมงาน และให้ทำความสะอาดทุกไตรมาส
• โครงสร้างพื้นฐานไม่ได้จบเมื่อวางลง แต่เป็นโครงกระดูกที่มีชีวิตซึ่ง atom สิทธิ์ และ score เติบโตไปด้วยกัน

ตัวอย่างบทถัดไป

• เริ่มต้นส่วนที่ 2: บทที่ 4 YAML frontmatter — เปลี่ยนทุกเอกสารให้เป็นข้อมูล

ลองทำดู

setup 1. เปิด ~/.claude/settings.json แล้วทำสำเนาสำรองเป็น settings.json.bak_<วันที่วันนี้> ก่อนแก้ไข 2. ใส่ Read(*), Grep(*), Bash(ls:*), Bash(git status:*) ลงใน permissions.allow และใส่ Bash(rm -rf:*), Bash(git push --force:*) ลงใน permissions.deny 3. (เมื่อมี atom ตั้งแต่ 50 ตัวขึ้นไป) ลงทะเบียน python ~/.claude/hooks/inject_memory.py ไว้ใน hooks.UserPromptSubmit แล้วเขียนเอนทรีของ atom (name · path · regex · score) และ config.max_matches: 3 ลงใน _jit_manifest.json

prompt - ในเซสชันใหม่ ให้โยนคำถามที่จงใจใส่คีย์เวิร์ดของ atom ตัวใดตัวหนึ่งใน manifest เช่น "มาดูการปรับสมดุลของสกิลโดยอิงตามกฎคูลดาวน์กัน"

verify - ทันทีหลังป้อนอินพุต ให้ดูว่ามีสัญญาณอย่าง [memory injected: N atoms] ขึ้นมาหรือไม่ - ดูว่า atom ที่ตั้งใจไว้สะท้อนอยู่ในคำตอบหรือไม่ - ลองจงใจใส่ JSON ที่พังลงใน manifest แล้วตรวจว่าพรอมต์ยังไม่ถูกขวางและทำงานได้อยู่ (รับประกัน exit 0) หลังจากนั้นค่อยย้อนกลับคืน

ฉบับย่อสำหรับคนเดียว - เริ่มต้นโดยไม่มีทั้ง hook และ manifest เขียนแค่ตัวตน 3 บรรทัด + กฎการทำงานร่วมกัน 3 บรรทัดลงในไฟล์โกลบอล MEMORY.md เพียงไฟล์เดียว และตั้งสิทธิ์ให้อนุญาตอัตโนมัติแค่ Read(*) · Grep(*) เท่านั้น เมื่อ atom เริ่มเข้ามือและใกล้แตะ 50 ตัว ตอนนั้นค่อยวาง hook ของ 1.3.2 ลงไป โครงสร้างพื้นฐานคือสิ่งที่เริ่มจากเล็ก ๆ แล้วเลี้ยงให้โตตามร่องรอย ไม่ใช่การมี 304 ตัวพร้อมตั้งแต่ต้น

ส่วนที่ 2 · สถาปัตยกรรมข้อมูล

2.1 YAML Frontmatter — เปลี่ยนทุกเอกสารให้เป็นข้อมูล

คืนก่อนวันสร้างบิลด์มาตรฐานสำคัญ (milestone build) เพียงหนึ่งวัน เพื่อนร่วมทีม A ซึ่งเป็น System Designer ถามผมผ่านแชตภายในทีมว่า "สัปดาห์นี้มีเอกสารที่แตะเส้นโค้งรางวัล (reward curve) กี่ฉบับ แล้วที่ตรวจเสร็จแล้วไปถึงไหนแล้ว" ผมไม่รู้คำตอบ เอกสารอยู่ที่ใดที่หนึ่งในโฟลเดอร์ ส่วนข้อมูลว่าใครเป็นคนแก้ครั้งสุดท้าย เป็นของมาตรฐานสำคัญรอบไหน กระจัดกระจายอยู่ในความทรงจำของแต่ละคนและในข้อตกลงเรื่องการตั้งชื่อไฟล์ สิ่งที่เราทำในคืนนั้นคือสร้างข้อตกลงให้ใส่หกบรรทัดไว้ที่ต้นเอกสาร และหกบรรทัดนั้นเองที่ทำให้ตั้งแต่มาตรฐานสำคัญรอบถัดไป คำถามของเพื่อนร่วมทีม A สามารถตอบได้โดยที่คนไม่ต้องเปิดโฟลเดอร์เลย

YAML ไม่กี่บรรทัดที่เขียนไว้ระหว่าง --- ด้านบนสุดของเอกสาร เราเรียกสิ่งนี้ว่า frontmatter ข้อตกลงนี้บอกทั้งคนและเครื่องพร้อมกันว่า "เอกสารนี้คืออะไร" โดยไม่ต้องอ่านเนื้อหาแม้แต่ตัวอักษรเดียว บทนี้จะตามรอยผ่านสคริปต์ที่ทำงานได้จริงว่า บรรทัดเดียวนั้นกลายเป็นพิกัดทางเข้าของสถาปัตยกรรมข้อมูล (information architecture) ทั้งระบบได้อย่างไร

ขอปูพื้นคำศัพท์ไว้เพียงคำเดียวก่อน หนังสือเล่มนี้แบ่งเอกสารออกแบบออกเป็นห้า Layer (จะกล่าวถึงอย่างจริงจังในบทที่ 6) L0 = โลกของเกม·คอนเซปต์, L1 = กฎของระบบ, L2 = เนื้อหา, L3 = ข้อมูล, L4 = พิกัดการ implement ทิศทางปกติคือพึ่งพาจากบนลงล่าง บรรทัด layer: 2 ที่ปรากฏในหัวข้อถัดไปคือการประกาศพิกัดว่า "เอกสารนี้คือ Layer เนื้อหา"

2.1.1 ทำไมไม่ใช่ "เอกสาร" แต่เป็น "เอกสารในฐานะข้อมูล"

เอกสารออกแบบเกมแบบดั้งเดิมอยู่บน Word, PPT และ Google Docs มาโดยตลอด เนื้อหาถูกปรับให้เหมาะกับการอ่านของคน แต่ข้อมูลเชิงเมตา (meta information) อย่างประเภท·ความรับผิดชอบ·สถานะ·ตำแหน่งของเอกสาร กลับฝังอยู่ในเนื้อหา หรือไม่ก็ขึ้นอยู่กับโครงสร้างโฟลเดอร์และข้อตกลงเรื่องชื่อไฟล์ ดังนั้นถ้าจะรู้ว่า "เอกสารนี้เป็นของมาตรฐานสำคัญรอบไหน ใครเป็นผู้รับผิดชอบ และตรวจครั้งสุดท้ายเมื่อไหร่" ก็ต้องเปิดเนื้อหาขึ้นมาดู

ตรงนี้มีข้อจำกัดสองอย่างซ้อนกันอยู่ ข้อแรก เอกสารไม่บอกตัวตนของตัวเอง ตัวตนอยู่ในความทรงจำของคนและในข้อตกลงเรื่องโฟลเดอร์ ซึ่งข้อตกลงเหล่านั้นจะผุกร่อนเมื่อเวลาผ่านไป ข้อสอง AI ไม่มีเบาะแสที่จะอนุมานบริบทได้ ถ้าสั่ง Claude Code ว่า "ช่วยตรวจเอกสารนี้ให้หน่อย" มันก็จะอ่านเนื้อหาตั้งแต่ต้นจนจบ สิ้นเปลืองโทเค็น และยังไม่รู้ด้วยว่าขอบเขตความรับผิดชอบไปถึงไหน

YAML frontmatter แก้ทั้งสองข้อนี้พร้อมกัน ถ้าใส่เมตาดาตาไว้อย่างชัดเจนที่ต้นเอกสาร ทั้งคนและเครื่องก็ระบุเอกสารได้โดยไม่ต้องเปิดเนื้อหา เหมือนกับที่เมื่อมีป้ายติดอยู่หน้าลิ้นชักตู้เก็บเอกสาร เราก็รู้ว่าข้างในมีอะไรโดยไม่ต้องเปิดลิ้นชัก และป้ายนี้ไม่ได้เป็นเพียงเครื่องมือจัดหมวดหมู่เท่านั้น อย่างที่จะได้เห็นต่อไป ฟิลด์ layer เพียงฟิลด์เดียวกลายเป็นพิกัดทางเข้าของการสร้างแบบโพรซีเดอรัล (procedural generation) และการตรวจสอบอัตโนมัติ

2.1.2 Frontmatter จริง — 14 บรรทัดแรกของเอกสารหนึ่งฉบับ

แทนที่จะยกตัวอย่างนามธรรม เราจะดู frontmatter ที่เอกสารเส้นโค้งรางวัลของโปรเจกต์ A แบกไว้บนหัวจริง ๆ ตามที่เป็น (เปลี่ยนเฉพาะ ID·ชื่อจริงให้เป็นนามแฝง ส่วนโครงสร้างเป็นไปตามที่ใช้งานจริง)

---
title: "เส้นโค้งรางวัล เควสต์หลัก บทที่ 12"
layer: 2
status: review
owner: teammate_a
created: 2026-04-15
updated: 2026-05-20
related:
  - quest_main_chapter12
  - reward_curve_milestone_2
affects:
  - L3_BalanceSheet_v2
ip_check: passed
---

# เส้นโค้งรางวัล เควสต์หลัก บทที่ 12

(เริ่มเนื้อหา)

หัวใจอยู่ที่การแยกส่วนเหนือและใต้ --- ด้านบนคือข้อมูลที่ parser อ่าน ด้านล่างคือเนื้อหาที่คนอ่าน โดยปกติตัว render มาร์กดาวน์จะซ่อน frontmatter ไว้ จึงไม่รบกวนเวลาอ่าน ไฟล์เดียวบรรจุทั้งข้อมูล (frontmatter) และเนื้อหา (body) ไว้ด้วยกัน จึงกลายเป็นแหล่งข้อมูลจริงเพียงแหล่งเดียว (single source of truth)

ต้องสังเกตสองบรรทัดนี้ให้ดี คือ layer: 2 และ affects: [L3_BalanceSheet_v2] นี่คือการประกาศว่า "เอกสารเนื้อหา (L2) ฉบับนี้ส่งผลต่อชีตปรับสมดุล (balance sheet) ใน Layer ข้อมูล (L3)" เพียงเท่านี้เครื่องมือก็วาดความสัมพันธ์การพึ่งพา L2→L3 เป็นกราฟได้โดยไม่ต้องดูเนื้อหา ในทางกลับกัน ถ้าเอกสารข้อมูล L3 อ้างถึงกฎของระบบ L1 ด้วย depends_on (เป็นการพึ่งพาย้อนทิศจากล่างขึ้นบน) นั่นคือกลิ่นของปัญหาในการออกแบบ และเครื่องมือจะตรวจจับการอ้างย้อนนั้นโดยอัตโนมัติ

เหตุผลที่ YAML เขียนด้วยมือง่ายกว่า JSON นั้นเรียบง่าย มันแสดงโครงสร้างด้วยการเยื้องบรรทัด (indentation) แทบไม่ต้องใช้เครื่องหมายคำพูด และใช้คอมเมนต์ # ได้ จึงเหมาะกับการให้นักออกแบบเกมกรอกเองโดยตรง

2.1.3 มาตรฐานอยู่ที่ไหน — _NAMING_FRONTMATTER_STANDARD

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

ฟิลด์หลักขั้นต่ำที่ใช้ร่วมกันมีหกฟิลด์

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

ฟิลด์ขยายเฉพาะสาขาต่างกันไปในแต่ละโดเมน System Designer ชอบใช้ depends_on·affects, ฝ่ายออกแบบการต่อสู้ใช้ combat_phase·anim_target, ฝ่ายเนื้อเรื่องใช้ world_region·chapter, ฝ่ายปรับสมดุลใช้ data_sheet·formula_id ฟิลด์ขยายเหล่านี้ห้ามกระจัดกระจายโดยอิสระ จึงต้องมีเอกสารมาตรฐานเพียงฉบับเดียวที่ตรึงชื่อทางการ·ค่าที่อนุญาต·ตัวอย่างไว้ตายตัว เอกสารฉบับนั้นคือ _NAMING_FRONTMATTER_STANDARD.md หากต้องการเพิ่มฟิลด์ใหม่ก็ต้องผ่านเอกสารนี้ และเอกสารมาตรฐานฉบับนี้เองก็ลงทะเบียนเป็น atom จึงได้รับการจัดการในสายเดียวกับกฎที่บังคับให้ใส่หมายเลข Layer ไว้หน้าชื่อเอกสาร (atom ชื่อ docs_layer_numeric_prefix_naming)

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

2.1.4 บันทึกเซสชันจริง (worked transcript) — บังคับมาตรฐานด้วยโค้ด และบทเรียนจากบั๊ก datetime

คราวนี้ผมให้ Claude Code สร้าง "Linter ที่ตรวจว่าเอกสารมาร์กดาวน์ทุกฉบับของโปรเจกต์ A ปฏิบัติตามมาตรฐาน frontmatter หรือไม่" ความต้องการหลักมีสองข้อ คือ ให้จับรายการตรวจสอบให้ได้ (ฟิลด์บังคับขาดหาย, ค่า status ที่ไม่เป็นมาตรฐาน, layer ละเมิดช่วง 0\~4, เอกสารที่เป็น review แต่ไม่ถูกแก้นานเกิน 90 วัน) และ อย่าฮาร์ดโค้ดค่าที่อนุญาตลงในโค้ด แต่ให้อ่านมาจากเอกสารมาตรฐาน การแยกส่วนนี้คือหัวใจ แก้มาตรฐานแล้วเกณฑ์การตรวจก็เปลี่ยนโดยไม่ต้องแก้โค้ด (สคริปต์ฉบับเต็มและขั้นตอนรันโดยตรง อยู่ใน «ลองทำดู» ท้ายบทนี้)

ตรงนี้เกิดเหตุการณ์หนึ่งขึ้น โค้ดที่ Claude เสนอมาในตอนแรกคำนวณผลต่างของวันที่ในการตรวจ STALE ด้วย today - fm["updated"] และเขียนคอมเมนต์ไว้ว่า "ถ้าเขียนแบบ updated: 2026-05-20 PyYAML จะ parse เป็น datetime.date ให้อัตโนมัติ" คำพูดนี้ถูกแค่ครึ่งเดียว เมื่อรันกับเอกสารจริง บางไฟล์ก็เกิด traceback ขึ้น

TypeError: unsupported operand type(s) for -: 'datetime.date' and 'str'

ต้นตออยู่ที่มือคน ผู้เขียนบางคนเขียน updated: 2026-05-20 (parse เป็น date) บางคนเขียน updated: "2026-05-20" โดยใส่เครื่องหมายคำพูด (parse เป็นสตริง) ตรงที่มาตรฐานไม่ได้ตรึงรูปแบบวันที่ไว้ มือคนก็แตกออกเป็นสองทาง และ Claude สมมติไว้เพียงทางเดียว ผมปฏิเสธโค้ดนั้นและขอใหม่ว่า "ให้ normalize ทั้งสองแบบเป็น date อย่างปลอดภัย และให้กรองกรณีที่ไม่มี updated ด้วย" Claude จึงเสริมฟังก์ชันช่วย (helper) ที่ตรวจชนิดของอินพุตแล้ว normalize ทั้งคู่ให้เป็น datetime.date (บล็อกที่แก้แล้วก็ดูได้ใน «ลองทำดู»)

บทเรียนที่แท้จริงไม่ใช่บั๊กของโค้ด แต่คือเรื่องที่ว่า ตรงที่มาตรฐานไม่ได้ตรึงรูปแบบการเขียนวันที่ไว้ มือคนก็แตกออกเป็นสองทาง ผมจึงเพิ่มบรรทัด updated: YYYY-MM-DD (ไม่ใส่เครื่องหมายคำพูด) ลงใน _NAMING_FRONTMATTER_STANDARD.md กลายเป็นว่า Linter กำลังตรวจโค้ดอยู่ แต่กลับเผยให้เห็นรูโหว่ของมาตรฐานซึ่งเป็นสิ่งที่มันใช้ตรวจเสียเอง

ผลลัพธ์แรกของสคริปต์ที่แก้แล้วก็ยังไม่สะอาด ผมขอคงผลลัพธ์ที่รกออกมาจริง ๆ ไว้ตามนั้น

[NO-FM]   manuscript/legacy/old_combat_notes.md
[MISSING] manuscript/system/quest_flag_table.md: layer
[STATUS]  manuscript/content/town_intro.md: WIP
[LAYER]   manuscript/balance/dps_v2.md: None
[STALE]   manuscript/system/inventory_rules.md: 134d

ห้าบรรทัดนี้คือสถานะจริงของทีมในช่วงเริ่มนำมาใช้ เอกสารเก่าไม่มี frontmatter เลย (NO-FM), บางเอกสารตกหล่น layer, บางคนใช้ค่าที่ไม่เป็นมาตรฐานอย่าง status: WIP, เอกสารปรับสมดุลฉบับหนึ่งปล่อย layer เป็น None, และเอกสารกฎของระบบฉบับหนึ่งหลับอยู่ในสถานะ review มา 134 วันแล้ว มาตรฐานไม่เคยถูกปฏิบัติตามตั้งแต่แรก Linter เพียงแค่เผยข้อเท็จจริงนั้นออกมาให้เห็นทุกเช้าเท่านั้นเอง

2.1.5 จาก frontmatter ถึงสคริปต์ — กระแสการไหล

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

flowchart TD
    A["ผู้เขียน: สร้างเอกสารใหม่
เทมเพลตแทรก frontmatter 6 ฟิลด์อัตโนมัติ"] --> B["เติมเฉพาะค่าที่ว่าง
title / layer / status / owner ..."]
    B --> C["ไฟล์ .md ที่บันทึก
--- frontmatter --- + เนื้อหา"]
    C --> D["รันสคริปต์ Linter
rglob('*.md')"]
    D --> E["_NAMING_FRONTMATTER_STANDARD.md
อ่านค่าที่อนุญาตมา"]
    E --> F{"ตรวจสอบ
ฟิลด์บังคับ / status / layer / stale"}
    F -->|"ผ่าน"| G["ป้อนเข้ากราฟความสัมพันธ์
related·affects → ระดับการพึ่งพาพิกัด L"]
    F -->|"ละเมิด"| H["รายงานรายวัน
แจ้งผู้รับผิดชอบ owner อัตโนมัติ"]
    H --> B
    G --> I["สอบถาม AI ได้
'รวบรวมเอกสาร Layer2 review ให้หน่อย' → ตอบทันที"]
    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef fail fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    class A,B human
    class D,F code
    class C,E,G data
    class H fail
    class I ai

หัวใจมีสองอย่าง ข้อแรก มาตรฐาน (E) ถูกแยกจากสคริปต์ (D) แก้มาตรฐานแล้วเกณฑ์การตรวจก็เปลี่ยนโดยไม่ต้องแก้โค้ด ข้อสอง การละเมิด (H) ไม่ใช่ทางตัน แต่เป็นลูปที่วนกลับไปยังขั้นการเขียน (B) ไม่ใช่การโทษคน แต่ส่งกลับไปให้เจ้าของเอกสารแก้เอกสารของตัวเอง

2.1.6 กรณีใช้งานจริง — หกเดือนของทีมขนาดกลางทีมหนึ่ง

โปรเจกต์ A ที่ผู้เขียนดูแลในฐานะ Director ได้นำ frontmatter มาใช้กับทีมออกแบบทั้งหมด (4\~5 คน) เมื่อราวหกเดือนก่อน การนำมาใช้ไม่ได้สำเร็จในครั้งเดียว แต่ผ่านสี่ระยะ

แรงต้านที่ใหญ่ที่สุดในสัปดาห์แรกของการนำมาใช้คือ "ให้เขียนด้วยมือทุกครั้งเลยเหรอ" การจำหกบรรทัดมาเขียนทุกครั้งที่สร้างเอกสารใหม่นั้นน่ารำคาญ ทางแก้คือการแทรกเทมเพลตอัตโนมัติ snippet ของ VSCode, เทมเพลตของ Obsidian, ปุ่ม "เอกสารใหม่" ในพอร์ทัลออกแบบ ต่างก็แทรกบล็อก YAML เปล่าให้อัตโนมัติ ผู้เขียนเอกสารเพียงเติมค่าที่ว่าง แรงต้านก็หายไปภายในหนึ่งสัปดาห์

เดือนแรกเกิดความขัดแย้งเรื่องมาตรฐาน เมื่อหลายคนเพิ่มฟิลด์ได้อย่างอิสระ owner·responsible·author ก็ปรากฏขึ้นพร้อมกัน เป็นแนวคิดเดียวกันแต่เขียนได้สามแบบ การค้นหาและการทำงานอัตโนมัติจึงพังลง ทางแก้คือรวบรวมชื่อทางการ·ค่าที่อนุญาต·ตัวอย่างของทุกฟิลด์ไว้ในเอกสารเดียวคือ _NAMING_FRONTMATTER_STANDARD.md แล้วตั้งกฎให้การเพิ่มฟิลด์ใหม่ต้องผ่านเอกสารนี้ ภายในหนึ่งเดือนมาตรฐานก็มั่นคง

เดือนที่สาม Linter ที่เห็นในหัวข้อ 2.1.4 ก็เข้ามา ต่อให้มีมาตรฐานคนก็ยังฝ่าฝืน ดังนั้นจึงให้สร้างรายงานความสอดคล้องอัตโนมัติทุกเช้าแล้วส่งลงในช่องสาธารณะของแชตภายในทีม ผู้รับผิดชอบดูแค่เอกสารของตัวเองก็พอ หลังจากทำอัตโนมัติแล้ว การละเมิดมาตรฐานก็ลดลงอย่างเห็นได้ชัด (เป็นการประมาณของผู้เขียน ไม่ใช่ค่าที่วัดอย่างแม่นยำ — รู้สึกได้ราว ๆ ครึ่งหนึ่งลงไป)

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

• "รวบรวมเอกสาร Layer 2 ที่อัปเดตในช่วงสองสัปดาห์ที่ผ่านมาและมี status เป็น review ให้หมด"
• "วาดไทม์ไลน์การเปลี่ยนสถานะของเอกสารทุกฉบับที่ผมเป็น owner ให้หน่อย"
• "ดึงรายการเอกสารอื่นที่คำขอแก้ไขนี้ส่งผลกระทบมาให้หน่อย" — โดยตามกราฟ related·affects อัตโนมัติ

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

2.1.7 ข้อผิดพลาดที่พบบ่อยและวิธีเลี่ยง

ข้อผิดพลาดที่เกิดซ้ำในช่วงเริ่มนำมาใช้รวบรวมได้เป็นห้าอย่าง ทุกข้อตั้งอยู่บนรากเดียวกัน — "ตรงที่ปล่อยมาตรฐานไว้กับเจตจำนงของคนเพียงอย่างเดียว"

ไม่จำเป็นต้องกันข้อผิดพลาดทั้งห้าให้ครบตั้งแต่วันแรก ข้อ 1·3 ให้จับรูปแบบการเลี่ยงไว้ตั้งแต่สัปดาห์แรกของการนำมาใช้ ส่วนข้อ 2·4·5 ค่อย ๆ ใส่เข้าไปทีละข้อโดยเริ่มจากจุดที่ทีมของตัวเองชนบ่อยที่สุดในระหว่างการใช้งาน จะเป็นไปอย่างเป็นธรรมชาติกว่า

2.1.8 เริ่มจากเล็ก — ทำให้ลงตัวภายในสามสัปดาห์

การนำ frontmatter มาใช้เป็นงานที่เบากว่าที่คิด สามสัปดาห์ก็ลงตัวได้ในทีมหนึ่ง

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

ไม่ต้อง migrate เอกสารทั้งหมดในครั้งเดียว ใช้กับเอกสารที่ดูบ่อยก่อน กับเอกสารใหม่ก่อน พอผ่านไปราวหกเดือน เอกสารแทบทุกฉบับก็จะมี frontmatter ติด แต่ก็ไม่ได้หมายความว่าเป้าหมายคือ 100% การเสียเวลา migrate ไปจนถึงเอกสารเก่าที่ไม่เคยเปิดเลยแม้แต่ครั้งเดียวนั้นเป็นการสิ้นเปลือง

ลองทำดู

เราจะลองรันหนึ่งรอบด้วยตัวเองในหน่วยที่เล็กที่สุด

setup - วางเอกสาร .md ที่จะตรวจไว้ 2\~3 ฉบับในโฟลเดอร์งาน บางฉบับให้ตั้งใจลบ layer ออก หรือใส่ค่าที่ไม่เป็นมาตรฐานอย่าง status: WIP ไว้ - วางเอกสารมาตรฐานหนึ่งบรรทัดไว้ในโฟลเดอร์เดียวกัน status: allowed = ["draft", "review", "approved", "archived"] updated: YYYY-MM-DD (ไม่ใส่เครื่องหมายคำพูด)

prompt (ป้อนใน Claude Code)

ช่วยเขียนสคริปต์ Python ที่ตรวจ YAML frontmatter ของไฟล์ .md ทุกไฟล์ใต้โฟลเดอร์นี้ให้หน่อย ให้จับ ฟิลด์บังคับ title·layer·status·owner ที่ขาดหาย, status ละเมิดค่าที่อนุญาต (อ่านมาจากเอกสารมาตรฐาน), layer ละเมิดจำนวนเต็มช่วง 0\~4, และที่เป็น review แต่ updated เกิน 90 วัน ให้จัดการได้อย่างปลอดภัยทั้งกรณีที่ updated มาเป็นสตริงและมาเป็น date แล้วแสดงการละเมิดแยกตามไฟล์

verify - รันสคริปต์แล้วตรวจดูว่าการละเมิดที่ตั้งใจฝังไว้ถูกจับได้ทั้งหมดหรือไม่ - เพิ่ม WIP ลงในรายการ allowed ของเอกสารมาตรฐาน แล้วรันใหม่ ตรวจดูว่าทั้งที่ไม่ได้แก้โค้ดแม้แต่บรรทัดเดียว status: WIP กลับเปลี่ยนเป็นผ่านหรือไม่ นั่นคือหลักฐานว่ามาตรฐานกับโค้ดถูกแยกจากกัน - ใส่ทั้งเอกสารที่ใส่เครื่องหมายคำพูดให้ updated และที่ไม่ใส่ ลงไปทั้งคู่ แล้วตรวจดูว่า TypeError ที่เห็นในหัวข้อ 2.1.4 ไม่เกิดขึ้น

อ้างอิง: สคริปต์ Linter ฉบับเต็ม

นี่คือโค้ดที่ Claude เสนอมาในตอนแรกในหัวข้อ 2.1.4 บรรทัดตรวจ STALE (age = (today - fm["updated"]).days) มีบั๊ก datetime ค้างอยู่ตามนั้น

import sys, datetime, pathlib, re
import yaml  # PyYAML

ROOT = pathlib.Path("manuscript")
STANDARD = pathlib.Path("_NAMING_FRONTMATTER_STANDARD.md")
REQUIRED = ["title", "layer", "status", "owner"]

def load_allowed_status(standard_path):
    # ดึงค่าที่อนุญาตของ `status` มาจากเอกสารมาตรฐาน
    text = standard_path.read_text(encoding="utf-8")
    m = re.search(r"status:\s*allowed\s*=\s*\[(.*?)\]", text)
    if not m:
        return ["draft", "review", "approved", "archived"]
    return [s.strip().strip('"').strip("'") for s in m.group(1).split(",")]

def parse_frontmatter(md_path):
    text = md_path.read_text(encoding="utf-8")
    if not text.startswith("---"):
        return None
    end = text.find("---", 3)
    block = text[3:end]
    return yaml.safe_load(block)

def main():
    allowed = load_allowed_status(STANDARD)
    today = datetime.date.today()
    violations = 0
    for md in ROOT.rglob("*.md"):
        fm = parse_frontmatter(md)
        if fm is None:
            print(f"[NO-FM]   {md}")
            violations += 1
            continue
        for field in REQUIRED:
            if field not in fm:
                print(f"[MISSING] {md}: {field}")
                violations += 1
        if fm.get("status") not in allowed:
            print(f"[STATUS]  {md}: {fm.get('status')}")
            violations += 1
        if not isinstance(fm.get("layer"), int) or not (0 <= fm.get("layer") <= 4):
            print(f"[LAYER]   {md}: {fm.get('layer')}")
            violations += 1
        if fm.get("status") == "review":
            age = (today - fm["updated"]).days   # ← ตรงนี้พัง
            if age > 90:
                print(f"[STALE]   {md}: {age}d")
                violations += 1
    sys.exit(violations)

บล็อกหลักที่แก้กลับมาหลังการขอใหม่ normalize updated ให้เป็น date อย่างปลอดภัยทั้งกรณีที่มาเป็นสตริงและมาเป็น date

def as_date(v):
    if isinstance(v, datetime.date):
        return v
    if isinstance(v, str):
        return datetime.date.fromisoformat(v.strip())
    return None

# ส่วนที่แทนการตรวจ STALE ภายใน main()
if fm.get("status") == "review":
    upd = as_date(fm.get("updated"))
    if upd is None:
        print(f"[MISSING] {md}: updated")
        violations += 1
    elif (today - upd).days > 90:
        print(f"[STALE]   {md}: {(today - upd).days}d")
        violations += 1

ฉบับย่อสำหรับคนเดียว

ไม่มีทีมก็ได้ ในโฟลเดอร์โน้ตที่ใช้คนเดียว ให้ลดฟิลด์หลักเหลือสามคือ title·status·updated แล้วตั้ง Linter ให้จับเฉพาะ "เอกสารที่ status เป็น review แต่ updated เกิน 30 วัน" เพียงเท่านี้ "เอกสารที่ผมตรวจค้างไว้แล้วลืม" ก็จะลอยขึ้นมาเหนือผิวน้ำสัปดาห์ละครั้ง สามเหลี่ยมมาตรฐาน-เทมเพลต-การตรวจสอบทำงานได้เหมือนเดิมแม้ในขนาดคนเดียว

สรุปประเด็นสำคัญของบท

• frontmatter หนึ่งบรรทัดคืออิฐข้อมูลก้อนเล็กที่สุดที่ใช้ระบุเอกสารได้โดยไม่ต้องอ่านเนื้อหา
• แยกมาตรฐานออกจากโค้ดแล้ววางไว้เป็นเอกสาร จะเปลี่ยนเกณฑ์การตรวจได้โดยไม่ต้องแก้โค้ด
• ฟิลด์ layer เพียงฟิลด์เดียวกลายเป็นพิกัดทางเข้าของการสร้างแบบโพรซีเดอรัลและการตรวจสอบอัตโนมัติ

2.2 Atom รายหน้า — กายวิภาคของ 1 เอกสาร 1 การตัดสินใจ

สัปดาห์แรกที่พนักงานใหม่เข้ามา เขาถามผมผ่านแชตว่า "Cooldown ของการต่อสู้คือ 0.6 วินาทีใช่ไหมครับ มันเขียนอยู่ในเอกสารไหน" ผมตอบว่า "อยู่ใน GDD ของระบบสกิล (Game Design Document หรือเอกสารสเปกแบบละเอียด)" เขาถามต่อว่า "GDD นั้นอยู่ในหัวข้อไหน เพราะหลังจากการออกแบบคลาสก็เป็น Damage Curve ต่อด้วยวิธีแสดงผล UI รวมแล้ว 220 บรรทัด" ผมจึงเปิดไฟล์แล้วหาให้เขาเอง มันอยู่บรรทัดที่ 137 สุดท้ายเขาถามว่า "แต่ทำไมต้อง 0.6 วินาที 0.5 ไม่ได้เหรอครับ" คำตอบนั้นไม่มีอยู่ในเอกสารใดเลย ผมจำได้ว่าตัดสินใจกันในการประชุมเมื่อ 6 เดือนก่อน แต่เหตุผลถูกฝังอยู่ที่ไหนสักแห่งในบันทึกการประชุม

ในบทสนทนา 5 นาทีนี้บรรจุความล้มเหลวทั้งสามของเอกสารรวม 220 บรรทัดไว้ครบ — หาตำแหน่งไม่เจอ (การค้นหาล้มเหลว) ไม่มีเหตุผล (บริบทสูญหาย) และต้องให้คนเป็นตัวกลางทุกครั้ง (อัตโนมัติไม่ได้) ถ้าถามคำถามเดียวกันนี้กับ AI สถานการณ์จะยิ่งแย่ลง AI จะอ่านครบทั้ง 220 บรรทัด แล้วตอบโดยปนเรื่อง Damage Curve ที่ไม่เกี่ยวกับ cooldown เข้ามาด้วย

ยาที่บทนี้สั่งจ่ายนั้นเรียบง่าย เอกสารหนึ่งฉบับบรรจุการตัดสินใจเพียงหนึ่งเดียว เอกสารหน่วยการตัดสินใจที่ถูกซอยย่อยด้วยหลักการนี้ เราเรียกว่า atom เมื่อแยก GDD 220 บรรทัดออกเป็นชิ้น ๆ "cooldown คือ 0.6 วินาที" ก็จะกลายเป็น atom หนึ่ง และภายใน atom นั้นจะรวมตำแหน่ง เนื้อหา เหตุผล ข้อยกเว้น และความสัมพันธ์ไว้ในที่เดียวกัน บทนี้จะไม่พูดทฤษฎีลอย ๆ แต่จะผ่ากายวิภาค atom จริงหนึ่งตัวจนจบ — ตั้งชื่ออย่างไร ใส่ frontmatter แบบใด ระบุความสัมพันธ์อย่างไร และผลลัพธ์คือ AI หยิบเฉพาะ atom ตัวนั้นออกมาได้แม่นยำอย่างไร

2.2.1 เลือกตัวอย่างมาหนึ่งชิ้น — combat_cooldown_rule_v2

ตัวอย่างที่จะผ่าคือ atom หนึ่งตัวที่ใช้งานจริงอยู่ในโปรเจกต์ A ชื่อ combat_cooldown_rule_v2 เนื้อไฟล์ทั้งหมดเป็นดังนี้ ไม่ยาว เพราะบรรจุการตัดสินใจเพียงหนึ่งเดียว

---
name: combat_cooldown_rule_v2
title: "กฎ Cooldown การต่อสู้ — v2"
type: rule
layer: 1
status: approved
owner: อี มินซู
created: 2026-03-10
updated: 2026-05-12
applies_to: [skill_system, item_system]
---

# กฎ Cooldown การต่อสู้ v2

Why (ทำไม): เพื่อจำกัดจำนวนสกิลที่ใช้พร้อมกันได้ ลดภาระการ
ตัดสินใจชั่วขณะ และรักษาความหมายของการกดคอมโบไว้

Rule (กฎ): สกิลแอ็กทีฟทุกตัวมี Global Cooldown 0.6 วินาที +
Cooldown รายตัว (กำหนดตามแต่ละสกิล) ระหว่างที่ Global Cooldown
กำลังทำงาน จะร่ายสกิลแอ็กทีฟใดก็ไม่ได้

How to apply (การนำไปใช้):
- เมื่อนิยามสกิลใหม่ ต้องระบุ cooldown รายตัวเสมอ
- ถ้าคอลัมน์ cooldown ใน L3_SkillSheet เป็น 0 ถือว่าละเมิดกฎนี้
- การตรวจสอบความสอดคล้องในขั้น build จะตรวจจับการละเมิดอัตโนมัติ

Exceptions (ข้อยกเว้น):
- สกิลพาสซีฟไม่อยู่ภายใต้กฎนี้
- ท่าไม้ตายใช้ระบบเกจแยกต่างหาก (See: [[ultimate_gauge_system]])

Relations (ความสัมพันธ์):
- affects: [[combat_dps_calculation_v3]], [[balance_curve_v3]]
- derives_from: [[principle_decision_load_reduction]]
- conflicts_with: [[skill_cancel_rule_legacy_v1]]
- requires: [[combat_input_buffer_system]], [[skill_system_v2]]
- is_a: rule
- part_of: combat_system_master

ผมจะแยกไฟล์แผ่นนี้ออกเป็นห้าส่วนเพื่อพิจารณา — การตั้งชื่อ frontmatter การตัดสินใจเดี่ยว ความสัมพันธ์ และความสามารถในการสืบย้อน ทั้งห้าส่วนต้องครบ AI จึงจะอ่าน atom นี้เป็น "หน่วยที่มีความหมายในตัวเองได้แม้อยู่ลำพัง"

2.2.2 ส่วนที่ ① การตั้งชื่อ — ตัวชื่อเองคือพิกัด

ชื่อไฟล์คือ combat_cooldown_rule_v2 ไม่ใช่ชื่อที่ตั้งขึ้นลอย ๆ แต่มีโครงสร้างสามท่อน

combat_         cooldown_rule          _v2
└ prefix        └ ตัวการตัดสินใจ       └ เวอร์ชัน
  (โดเมนใด)       (การตัดสินใจเรื่องอะไร) (ปรับครั้งที่เท่าไร)

prefix combat_ คือพิกัดที่บอกว่า "นี่คือการตัดสินใจของโดเมนการต่อสู้" atom ประเภทกฎของโปรเจกต์ A แยกโดเมนกันด้วย prefix ได้แก่ quest_ (เควสต์), data_ (การจัดการข้อมูล), docs_ (การจัดการเอกสาร), meeting_ (บันทึกการประชุม), portal_ (วิวเวอร์เอกสารออกแบบ) แค่ดู prefix ก็จับได้ว่าการตัดสินใจนี้อยู่ในขอบเขตความรับผิดชอบของใคร และได้รับผลกระทบจากที่ไหน

ถ้าการตั้งชื่อสั่นคลอน ทุกอย่างก็สั่นคลอนตาม ถ้าการตัดสินใจเดียวกันมีอยู่สองครั้งในชื่อ skill-cooldown.md กับ cooldown_skill_v2.md ทั้งการค้นหาก็พัง และการจับคู่ JIT ที่จะกล่าวถึงต่อไปก็พังด้วย ด้วยเหตุนี้โปรเจกต์ A จึงตรึงกฎการตั้งชื่อไว้เป็น atom หนึ่งตัวเสียก่อน นั่นคือ atom_naming_convention_v1 ซึ่งบังคับ snake_case · บังคับมี prefix · บังคับมี suffix เวอร์ชัน และกฎนี้ไม่ได้อาศัยเจตจำนงของคน แต่ Linter เป็นผู้รักษา ถ้าชื่อไฟล์ที่ไม่มี prefix ถูก commit เข้ามา มันจะถูกดักไว้ในขั้น build

ในการตั้งชื่อยังมีการออกแบบที่ใหญ่กว่าซึ่งร้อยทะลุทั้งเล่มฝังอยู่ layer: 1 ใน frontmatter คือพิกัดที่สอง ถ้า prefix บอก "โดเมนใด" Layer ก็บอก "ชั้นนามธรรมใด" พิกัดสองตัวต้องประกอบกัน ตำแหน่งของ atom จึงถูกตรึงเป็นจุดเดียวบนระนาบ ตรงนี้ Layer เป็นเพียงพิกัดเท่านั้น (รายละเอียดนิยามชั้น 0\~4 อยู่ใน 2.3) กฎ cooldown เป็น "กฎอินพุตที่ควบคุมการสร้าง" จึงนั่งอยู่ที่ Layer 1 ยังมีกฎที่บังคับให้ใส่พิกัด Layer นี้เป็นเลข prefix หน้าชื่อเอกสารแยกต่างหากด้วย — docs_layer_numeric_prefix_naming พูดอีกอย่างคือในชื่อเดียวมีแกนพิกัดสองแกนระบุไว้ครบ

แก่นแท้ของการออกแบบนี้ไม่ใช่นิสัยรักความเป็นระเบียบ มีคำหนึ่งที่ผมพูดกับทีมซ้ำ ๆ "Layer ที่แบ่งไว้นั้น แบ่งไว้เพื่อการสร้างแบบโพรซีเดอรัล (procedural generation) นั่นเอง" เมื่อแต่ละ atom ระบุพิกัดโดเมน (prefix) และพิกัดชั้น (Layer) ไว้ ต่อไปก็เป็นไปได้ที่ AI จะ "รับกฎ combat ของ Layer 1 ทั้งหมดเป็นอินพุต แล้วสร้างเนื้อหา (content) ของ Layer 2 โดยอัตโนมัติ" ชื่อคือระบบที่อยู่ (address) ของการทำงานอัตโนมัตินั้น

2.2.3 ส่วนที่ ② frontmatter — ป้ายกำกับที่เครื่องอ่าน

บล็อก YAML ระหว่าง --- เหนือเนื้อความคือ frontmatter เป็นการนำมาตรฐานที่กล่าวใน 2.1 มาใช้กับ atom ตรง ๆ และเป็นป้ายกำกับที่ไม่ใช่คนอ่าน แต่เครื่อง (build script · JIT hook · ตัวสร้างแผนผังความสัมพันธ์) เป็นผู้อ่าน

เมื่อป้ายเหล่านี้ถูกใส่ไว้ การตรวจสอบอัตโนมัติก็ทำได้ ตัวอย่างเช่น ถ้ากฎระบบที่ประกาศเป็น layer: 1 ไปอ้างถึง data atom (Layer 3) อย่าง [[L3_SkillSheet_row_0042]] โดยตรงในเนื้อความ นั่นคือ การอ้างย้อน (L3→L1) ที่ชั้นบนถูกผูกติดกับค่ารูปธรรมของชั้นล่าง โปรเจกต์ A ตรวจจับรูปแบบนี้อัตโนมัติในขั้น build เพราะกฎต้องอ้างถึงรูปแบบของข้อมูล ไม่ใช่ข้อมูลทีละแถว ถ้าไม่มีบรรทัด layer ใน frontmatter การตรวจสอบนี้ก็ไม่เกิดขึ้นเลย

การจัดการ status: archived ก็เป็นงานของ frontmatter เช่นกัน เมื่อการตัดสินใจเปลี่ยนไป atom จะไม่ถูกลบ แต่จะได้ status: archived + วันที่ archived_at ทั้ง build และ JIT จะคัด atom ที่ archived ออก คือเก็บบันทึกไว้แต่ถอนออกจากตัวที่ใช้งานจริง ตลอด 6 เดือนของการใช้งานในโปรเจกต์ A อัตราการเลิกใช้อยู่ที่ราว 15% (ผู้เขียนวัดจริง) ถ้าอัตรานี้เข้าใกล้ 0% ผมตีความว่าเป็นสัญญาณว่าเวิร์กโฟลว์การเลิกใช้ไม่ทำงาน

2.2.4 ส่วนที่ ③ การตัดสินใจเดี่ยว — สรุปได้เป็นประโยคเดียวหรือไม่

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

"สกิลแอ็กทีฟทุกตัวมี Global Cooldown 0.6 วินาที"

จบในประโยคเดียว ผ่าน ถ้าสรุปออกมาเป็นสองประโยคเช่น "cooldown คือ 0.6 วินาที และระหว่างคอมโบลดลง 50%" นั่นคือสองการตัดสินใจ ต้องแยกเป็น combat_cooldown_rule_v2 (cooldown พื้นฐาน) และ combat_combo_cooldown_reduction_v1 (การลดในคอมโบ)

มีการตรวจสอบเสริมที่ดูความเป็นหนึ่งเดียวอีกสองข้อ

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

การตรวจการอ้างอิงเดี่ยว ถ้าที่อื่นวาง link เพียง [[combat_cooldown_rule_v2]] ตัวเดียว ความหมายยังเดินได้หรือไม่ ถ้าเดินได้ แสดงว่าหน่วยถูกต้อง ถ้าจะอ้างบรรทัดนี้แล้วต้องอ่านเนื้อความหลายที่ให้ครบ แสดงว่ายังแยกย่อยไม่พอ

เนื้อความที่ผ่านการตรวจเหล่านี้จะจัดเรียงเป็นห้าหัวข้อโดยธรรมชาติ — Why, Rule, How, Exceptions, Relations โดยเฉพาะ อย่าลบ Why คำตอบของคำถามสุดท้ายที่พนักงานใหม่ถามในบทนำว่า "ทำไมต้อง 0.6 วินาที" อยู่ตรงนี้ — "เพื่อลดภาระการตัดสินใจชั่วขณะและรักษาความหมายของการกดคอมโบ" เมื่อ 6 เดือนต่อมามีใครเสนอว่า "ลดเหลือ 0.5 วินาทีกันเถอะ" บรรทัดเดียวนี้จะกลายเป็นจุดตั้งต้นของการถกเถียง atom ที่ Why หายไปจะกลายเป็นฟอสซิลที่ไม่มีใครกล้าแตะ

2.2.5 ส่วนที่ ④ ความสัมพันธ์ — ลูกศรสร้างการวิเคราะห์ผลกระทบ

หัวข้อ Relations ที่ก้นสุดของ atom ทำให้ตัวอย่างนี้ไม่ใช่บันทึกโดดเดี่ยว แต่เป็นโหนดหนึ่งในกราฟ แก่นคือมันไม่ได้เป็นเพียง "เอกสารที่เกี่ยวข้อง" แต่ ระบุชนิดของความสัมพันธ์

flowchart TD
    P["หลักการ: ลดภาระการตัดสินใจ"] -->|derives_from| C["combat_cooldown_rule_v2"]
    C -->|affects| A1["combat_dps_calculation_v3"]
    C -->|affects| A2["balance_curve_v3"]
    C -->|requires| R1["combat_input_buffer"]
    C -->|requires| R2["skill_system_v2"]
    C -.->|conflicts_with| X["skill_cancel_legacy_v1
(ขัดแย้ง รอเลิกใช้)"]
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef fail fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    class P,C,A1,A2,R1,R2 data
    class X fail

ความสัมพันธ์หกชนิดต่างทำหน้าที่ต่างกัน

• derives_from: การตัดสินใจนี้แตกหน่อมาจากหลักการชั้นบนใด cooldown 0.6 วินาทีคือการทำให้หลักการ "ลดภาระการตัดสินใจ" เป็นรูปธรรม
• affects: ถ้า atom นี้เปลี่ยน อะไรจะได้รับผลกระทบ ถ้าเปลี่ยน 0.6 วินาทีเป็น 0.5 วินาที การคำนวณ DPS และ Balance Curve จะสั่นคลอน ดึงขอบเขตผลกระทบออกมาได้อัตโนมัติก่อนเปลี่ยน
• requires: การตัดสินใจนี้จะตั้งอยู่ได้ต้องมีอะไรอยู่ก่อน ถ้าไม่มีระบบ input buffer Global Cooldown จะกลืนอินพุตหายไป
• conflicts_with: ขัดแย้งกับอะไร มันขัดแย้งกับกฎ skill cancel เวอร์ชันเก่า และ link นี้คือสัญญาณว่า "หนึ่งในสองตัวต้องถูกเลิกใช้"
• is_a / part_of: การจัดประเภท (rule) และการสังกัด (combat_system_master) คือโครงกระดูกของกราฟ

ถ้าเป็นเพียง link แบบ "Related: [เอกสาร A], [เอกสาร B]" คนก็ต้องไล่พิจารณาเองทีละตัว แต่เมื่อชนิดของความสัมพันธ์ถูกใส่เป็น enum เครื่องจะพิจารณาให้ "เปลี่ยน atom นี้แล้วอะไรได้รับผลกระทบบ้าง แสดงมาให้หมด" กลายเป็นคิวรีอัตโนมัติที่ไล่ตาม affects และ "ตอนนี้กฎที่ขัดแย้งกันมีอะไรบ้าง หามาให้หมด" กลายเป็นการตรวจอัตโนมัติที่สแกน conflicts_with การออกแบบออนโทโลยีเต็มรูปแบบของ enum ทั้งหกนี้จะกล่าวใน 2.4 ส่วน 2.2 เพียงชี้ว่ามาตรฐาน atom ได้นำ enum นั้นมาใช้ล่วงหน้าในรูปแบบหนึ่ง

ลูกศรความสัมพันธ์ยังเป็นอินพุตของเครื่องมือสร้างแผนผังความสัมพันธ์ด้วย gen_relation_map.py ของโปรเจกต์ A อ่าน layer ใน frontmatter และหัวข้อ Relations ของ atom ทุกตัว แล้ววาดแผนผังความสัมพันธ์ HTML แบบอินเทอร์แอ็กทีฟที่ลงสีตาม Layer ให้อัตโนมัติ เป็นไปได้เพราะ atom แต่ละตัวมีพิกัด (Layer) และลูกศร (Relations)

2.2.6 ส่วนที่ ⑤ ความสามารถในการสืบย้อน — atom หนึ่งตัวที่กัน 30 นาทีไว้ได้

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

atom meeting_image_caption_standard ของโปรเจกต์ A คือกฎที่กำหนดให้รูปภาพแนบในบันทึกการประชุมต้องระบุคำบรรยายว่า "เป็นหน้าจออะไร · ทำไมจึงแนบ · เป็นการตัดสินใจอะไร" เสมอ สมัยที่ยังไม่มี atom นี้ มีบันทึกการประชุมหนึ่งที่แนบสกรีนช็อตโดยไม่มีคำบรรยาย หนึ่งสัปดาห์ต่อมาเพื่อนร่วมทีมที่เห็นมัน ต้องใช้เวลา 30 นาทีไปยืนยันกับผู้เขียนว่า "นี่คือหน้าจออะไร" หลังจากมี atom นี้แล้ว เมื่อเกิดการตกหล่นแบบเดียวกันซ้ำ Linter ในขั้น build จับรูปภาพที่ไม่มีคำบรรยายได้อัตโนมัติ แก้ไขเสร็จใน 5 นาที จาก 30 นาทีเหลือ 5 นาที

ตัวอย่างอีกชิ้น skill_listing_budget_wrapper_only_policy คือกฎที่จำกัดสล็อตคำสั่งสแลช (slash command) ระดับ global ไว้ที่ 12 ตัว ให้เก็บสกิลตัวจริงไว้ในไดเรกทอรีแยก แต่เปิดเผยใน global เพียง wrapper 12 ตัว ก่อนถูกตรึงเป็นกฎ คำสั่งสแลชระดับ global พองตัวจนเกือบ 40 ตัว กัดกินงบโทเค็น (token) ทุกครั้งที่เริ่มเซสชัน หลังจากนิยาม atom แล้ว เครื่องมือจัดระเบียบอัตโนมัติจะเก็บกวาดส่วนเกินทุกครั้งที่เริ่มเซสชัน กฎถูกบังคับใช้ด้วยเครื่องมือ ไม่ใช่ความทรงจำของคน

atom แบบนี้สะสมอยู่ในโปรเจกต์ A ราว 304 ตัว (ผู้เขียนวัดจริง ณ จุด 6 เดือนของการใช้งาน) ถ้าดูเฉพาะกิ่งใหญ่ของการกระจาย กฎป้องกันการเกิดซ้ำ (rule) มีสัดส่วนใหญ่ที่สุด ถัดมาคือการตรึงการตัดสินใจครั้งเดียวจบ (decision) · แนวคิดของโดเมน (concept) · การปรับการทำงานร่วมกัน (feedback) ตามลำดับ เวลาที่ atom หนึ่งตัวกันไว้ได้นับเป็นนาที แต่เมื่อสะสมครบ 304 ตัว เวลาที่ประหยัดสะสมก็ข้ามไปเป็นหน่วยวัน นี่คือเหตุผลที่ผมเรียก atom ว่า "สินทรัพย์" ไม่ใช่ "การจัดระเบียบ"

2.2.7 จากการผ่ากายวิภาคสู่การฉีดอัตโนมัติ — การทำงานจริงของ JIT

จนถึงตอนนี้ผมผ่ากายวิภาค atom หนึ่งตัวแบบนิ่ง ตอนนี้มาดูช่วงเวลาที่มันมีชีวิตขยับ JIT (Just-In-Time) hook ที่กล่าวใน 1.3 คัดเฉพาะ atom ที่ตรงกับคำสำคัญของอินพุต แล้วฉีดเข้าสู่บริบท ณ ตรงนั้น JIT manifest คือ JSON ที่จับคู่คำสำคัญที่ใช้แมตช์และคะแนนให้กับ atom แต่ละตัว

{
  "name": "combat_cooldown_rule_v2",
  "path": "atoms/combat/combat_cooldown_rule_v2.md",
  "regex": "쿨다운|cooldown|글로벌 쿨다운|GCD",
  "score": 75
}

การฉีดจริงไหลดังนี้

flowchart TD
    A["อินพุตผู้ใช้:
ถ้าลด cooldown สกิลเหลือ 0.5 วินาทีล่ะ?"] --> B["JIT hook:
สแกน regex ใน manifest"]
    B --> C{"แมตช์ cooldown?"}
    C -->|"ใช่ score=75"| D["combat_cooldown_rule_v2
ฉีดเนื้อความเต็ม"]
    C -->|"ไม่"| E["ไม่ฉีด"]
    D --> F["AI อ่านจนถึง Why·Rule·Exception
แล้วตอบ"]
    F --> G["คำตอบ: 0.6 วินาทีมีฐานจากการลด
ภาระการตัดสินใจ ถ้าลดเหลือ 0.5 วินาที
ต้องทบทวนการคำนวณ DPS และ Balance
Curve ที่เป็นเป้าหมายของ affects ใหม่"]
    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    class A human
    class B,C code
    class D data
    class F,G ai

แก่นอยู่ที่ช่องสุดท้าย AI ไม่ได้ตอบเพียงว่า "มันคือ 0.6 วินาที" เพราะอ่าน Why ของ atom จึงยกเหตุผลมาประกอบ และเพราะอ่าน affects ใน Relations จึงชี้ล่วงหน้าถึงเป้าหมายที่จะสั่นคลอนเมื่อเปลี่ยน (การคำนวณ DPS · Balance Curve) ห้าส่วนที่ซอยย่อย เขียนเหตุผล และระบุความสัมพันธ์ไว้ ฟื้นคืนมีชีวิตในคำตอบครบทุกส่วน

ตรงนี้เผยให้เห็นว่าหลักการตัดสินใจเดี่ยวคือเงื่อนไขตั้งต้นของการทำงานอัตโนมัติ ถ้า atom นี้เป็น GDD รวม 220 บรรทัด ในวินาทีที่คำว่า "cooldown" เพียงคำเดียวแมตช์ การออกแบบคลาส · Damage Curve · UI จะถูกฉีดเข้ามาทั้งก้อน งบโทเค็นถูกหั่น และ AI จะหลงโฟกัสว่าควรตอบการตัดสินใจตัวไหนในห้าตัว ยิ่ง atom เล็กและชัด ความแม่นยำของ JIT ยิ่งสูงขึ้น สภาพที่ซอยย่อยไว้ไม่ใช่คุณธรรมของการจัดระเบียบ แต่เป็นเงื่อนไขตั้งต้นของการฉีดอัตโนมัติ

score คือกลไกที่รักษางบบริบท ถ้าอินพุตหนึ่งแมตช์หลาย atom จะฉีดเฉพาะ N ตัวบนสุดตาม score (ค่าเริ่มต้น 3 ตัว) เกณฑ์การให้คะแนนกำหนดไประหว่างใช้งานจริง

• atom เกี่ยวกับความปลอดภัย · ความมั่นคง · สุขภาพ = 95\~99 (ห้ามตกหล่นเด็ดขาด)
• atom ที่เป็นสารหลัก · ปรัชญา = 90\~94
• กฎหลักของโดเมน = 75\~89 (กฎ cooldown อยู่ตรงนี้ คือ 75)
• atom สำหรับอ้างอิง · ประวัติ = 30\~50

2.2.8 atom ส่วนตัวกับ atom ที่ทีมใช้ร่วม — การแยกสองชั้น

ตัวอย่างที่ผ่าไป combat_cooldown_rule_v2 คือ atom ที่ทีมใช้ร่วมซึ่งได้รับ status: approved ไม่ใช่ทุก atom จะมาถึงตำแหน่งนี้ตั้งแต่แรก โปรเจกต์ A แบ่ง atom ออกเป็นสองชั้น

• atom ส่วนตัว — สมมติฐานที่ยังไม่ยืนยัน · บันทึกส่วนตัว · การตรึงไว้ตามช่วงเวลา มีเพียงเจ้าตัวเห็น มาตรฐานหลวม
• atom ที่ทีมใช้ร่วม — กฎที่ผ่านการยืนยันแล้ว ทุกคนในทีมเห็น ต้องผ่านขั้นตอนการตั้งชื่อ · โครงสร้าง · การอนุมัติ

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

combat_cooldown_rule_v2 เองตอนแรกก็คงเป็นบันทึกสั้น ๆ บรรทัดเดียวใน atom ส่วนตัวว่า "ลองทดสอบ cooldown 0.6 วินาทีกัน" หลังถูกยืนยันในอัลฟาบิลด์ มันถูกเลื่อนขั้นสู่ atom ที่ทีมใช้ร่วมในรูปคำขอเปลี่ยนแปลง และผ่านการรีวิวของนักออกแบบเกมคนอื่นจึงกลายเป็น approved กระแสการเลื่อนขั้นจากส่วนตัวสู่ทีมนี้เองคือแกนหนึ่งของลูป self-improving ที่ทำให้ระบบ atom ฉลาดขึ้นตามกาลเวลา

2.2.9 ความผิดพลาดที่พบบ่อยห้าประการ

ความผิดพลาดที่เกิดซ้ำในช่วงต้นของการใช้งาน atom สรุปได้เป็นห้าข้อ ทั้งหมดออกมาจากรากเดียวกันคือ "ปฏิบัติต่อ atom เป็นบันทึกครั้งเดียวจบ ไม่ใช่สินทรัพย์"

ไม่จำเป็นต้องหลีกเลี่ยงทั้งห้าข้ออย่างสมบูรณ์ตั้งแต่เดือนแรก ข้อ 1 และ 4 คลายไปด้วยกันด้วย atom กฎการตั้งชื่อตัวเดียว ส่วนข้อ 2 · 3 · 5 พอรันการตรวจรายไตรมาสหนึ่งครั้ง ณ จุด 3 เดือนของการใช้งาน ก็จะจัดเรียงเข้าที่โดยธรรมชาติ

2.2.10 สู่บทถัดไป

บทนี้ผมแยก atom หนึ่งตัวออกเป็นห้าส่วนเพื่อพิจารณา — ชื่อ (พิกัด), frontmatter (ป้ายสำหรับเครื่อง), การตัดสินใจเดี่ยว (การตรวจหนึ่งประโยค), ความสัมพันธ์ (การวิเคราะห์ผลกระทบ), ความสามารถในการสืบย้อน (30 นาทีที่กันไว้ได้) และยืนยันแล้วว่าห้าส่วนนั้นฟื้นคืนมีชีวิตทั้งก้อนอย่างไรในการฉีดอัตโนมัติของ JIT

หนึ่งในสองพิกัดที่ระบุไว้ในชื่อ คือ layer: 1 นั้น 2.2 เพียงแตะผ่านไปเบา ๆ 2.3 จะจัดการ Layer นั้นแบบเต็มหน้า เมื่อให้พิกัด Layer แก่ atom แต่ละตัว แม้คนละสาขาก็เริ่มมองเห็นว่าผลงานของกันและกันนั่งอยู่ตรงไหน และ 2.4 จะทำให้ความสัมพันธ์หกชนิด (affects · derives_from · conflicts_with · requires · is_a · part_of) ที่บทนี้หยิบยืมมาแค่ชื่อ enum กลายเป็นออนโทโลยีอย่างเป็นทางการ ในโครงกระดูกของสถาปัตยกรรมข้อมูลที่ไล่จาก YAML (2.1) → Atom (2.2) → Layer (2.3) → Ontology (2.4) บทนี้คือข้อต่อที่สอง

สรุปประเด็นสำคัญของบท

• atom หนึ่งตัวคือผลรวมของห้าส่วน — ชื่อ · frontmatter · การตัดสินใจเดี่ยว · ความสัมพันธ์ · ความสามารถในการสืบย้อน
• หลักการตัดสินใจเดี่ยวไม่ใช่นิสัยรักความเป็นระเบียบ แต่เป็นเงื่อนไขตั้งต้นของการฉีดอัตโนมัติของ JIT
• พิกัดสองตัวคือโดเมนและ Layer ที่ระบุในชื่อ กลายเป็นระบบที่อยู่ของการสร้างแบบโพรซีเดอรัล

ลองทำดู — สร้าง atom หนึ่งตัวแล้วฉีดด้วย JIT

setup สร้างไดเรกทอรี atoms/ ในโฟลเดอร์งาน แล้วเขียน atom กฎการตั้งชื่อ (atom_naming_convention_v1) เป็นอันดับแรกสุด แค่จดสามบรรทัดคือ snake_case · บังคับ prefix · suffix เวอร์ชัน ก็พอ ถ้าใช้ JIT ก็วาง _jit_manifest.json ที่เป็นอาร์เรย์ว่างไว้หนึ่งไฟล์

prompt เลือกการตัดสินใจหนึ่งอย่างที่คุณลืมทุกครั้ง แล้วขอร่าง atom ด้วยพรอมต์ด้านล่าง

"ช่วยทำการตัดสินใจต่อไปนี้ให้อยู่ในรูปแบบมาตรฐาน atom การตัดสินใจ: 'สกิลแอ็กทีฟมี Global Cooldown 0.6 วินาที' หัวข้อมีห้าหัวข้อคือ Why · Rule · How to apply · Exceptions · Relations ใส่ name (snake_case+prefix), type, layer, status: draft, owner, created ใน frontmatter และช่วยตรวจตอนท้ายด้วยว่าการตัดสินใจสรุปได้เป็นประโยคเดียวหรือไม่"

verify ตรวจ atom ที่ได้ด้วยสามข้อ ① การตัดสินใจสรุปได้เป็นประโยคเดียวหรือไม่ (ถ้าไม่ได้ ให้แยกย่อย) ② Why ไม่ว่างเปล่าใช่ไหม ③ เพิ่มบรรทัด {"name", "path", "regex", "score"} ใน manifest แล้วเมื่อโยนคำสำคัญของ regex นั้นเป็นอินพุตจริง atom ถูกฉีดหรือไม่ ถ้าผ่านทั้งสามข้อ atom แรกก็เสร็จสมบูรณ์

ฉบับย่อสำหรับคนเดียว

ถ้าคุณเป็นนักพัฒนาคนเดียวที่ไม่มีทั้งทีม ไม่มี Linter ไม่มี build pipeline คุณสามารถย่อทั้งบทนี้ลงเหลือแค่โฟลเดอร์หนึ่งในแอปจดโน้ตได้

• การตั้งชื่อ รวมชื่อไฟล์ให้เป็นกฎเดียว domain_decision_v1 แทน Linter ก็ใช้ตาตัวเองรักษา
• การตัดสินใจเดี่ยว โน้ตหนึ่งแผ่นต่อหนึ่งการตัดสินใจ ถ้าเขียนหัวข้อเป็นประโยคเดียวไม่ได้ ให้แยกเป็นสองแผ่น
• Why บังคับ จดบรรทัดบนสุดของโน้ตว่า "ทำไมจึงตัดสินใจเช่นนี้" บรรทัดเดียวนี้จะช่วยตัวคุณเองในอีก 6 เดือนข้างหน้า
• ความสัมพันธ์ แทน enum ทางการ แค่ใช้สามเครื่องหมาย → ผลกระทบ:, ↑ ฐานเหตุผล:, ✕ ขัดแย้ง: ก็คงการสืบย้อนผลกระทบไว้ได้ราว 90%
• ใช้แทน JIT แทน manifest ก่อนเริ่มงาน ให้เปิดโน้ต 1.2\~1.3 ที่เกี่ยวข้องเองแล้ววางให้ AI นี่คือ JIT แบบมือ

แก่นไม่ใช่เครื่องมือ แต่เป็นนิสัยห้าส่วน 10 โน้ตแรกยากที่สุด เมื่อข้ามด่านนั้นไปได้ อีก 100 โน้ตถัดไปมือจะสร้างเองโดยอัตโนมัติ

2.3 การออกแบบ Layer — การทำให้ระบบเกมเป็นนามธรรม

นั่นคือช่วงที่สาขางานขยายจากสามเป็นแปด นักออกแบบเกมฝ่ายต่อสู้กำหนดระยะของสกิลไว้ที่ 8 เมตร ในสัปดาห์เดียวกัน นักออกแบบเลเวลก็ล็อกความกว้างของทางเดินดันเจี้ยนไว้ที่ 6 เมตร ทั้งสองการตัดสินใจสมเหตุสมผลอย่างสมบูรณ์เมื่อมองในขอบเขตสาขาของตัวเอง ปัญหาเผยตัวออกมาในบิลด์อีกสามสัปดาห์ถัดมา สกิลโจมตีเป็นวงทะลุกำแพงทางเดินออกไปและศัตรูตายในที่ที่มองไม่เห็นด้วยซ้ำ ไม่ใช่ความผิดของใครเลย เพียงแต่ทั้งสองคนไม่มีหน้าต่างที่จะมองเห็นการตัดสินใจของอีกฝ่าย

บทนี้คือเรื่องราวของการสร้างหน้าต่างนั้น การทำให้แต่ละสาขายังคงมีห้องของตัวเองไว้ครบ แต่รู้ได้ด้วยพิกัดเพียงตัวเดียวว่ากำลังเกิดอะไรขึ้นในห้องข้างๆ ระบบพิกัดนั้นเราเรียกว่า Layer

2.3.1 การเกิดไซโล — ศัตรูที่ต้องเผชิญซ้ำทุกครั้ง

การออกแบบเกมแตกแขนงเป็นสาขางานย่อยๆ จำนวนมาก ทั้งระบบ ต่อสู้ เนื้อเรื่อง เนื้อหา เลเวล บาลานซ์ UX และ QA แต่ละสาขามีเครื่องมือ ผลงาน และการประชุมของตัวเอง ยิ่งโครงการใหญ่ขึ้นเท่าไร แต่ละคนก็ยิ่งดำดิ่งลึกเข้าไปในขอบเขตของตัวเอง จนกลายเป็นสภาพที่ไม่รู้ว่าสาขาอื่นกำลังทำอะไรอยู่ สภาพนี้เรียกว่าการเกิดไซโล (silo)

ต้นทุนของการเกิดไซโลจะปรากฏให้เห็นก็ต่อเมื่อเวลาผ่านไปแล้ว

• ระยะของสกิลที่ฝ่ายต่อสู้ตัดสินใจไว้ไม่เข้ากับความกว้างของทางเดินที่ฝ่ายออกแบบเลเวลกำหนด
• แรงจูงใจของ NPC ที่ฝ่ายเนื้อเรื่องออกแบบไว้ขัดแย้งกับโครงสร้างรางวัลเควสต์ที่ฝ่ายเนื้อหากำหนด
• วงจรเศรษฐกิจที่ฝ่ายบาลานซ์วางไว้ไม่ตรงกับกำหนดการรางวัลเช็กชื่อของ Live Ops

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

ทางออกคือการทำให้รับรู้กระแสงานของกันและกันได้ (การมองเห็นแบบรวม) โดยไม่ต้องลดทอนขอบเขตของแต่ละสาขา (คงการแตกแขนงของสาขาไว้) ข้อเรียกร้องสองข้อที่ดูเหมือนขัดแย้งกันนี้จะบรรลุได้พร้อมกันเมื่อจัดวางลงบนระบบพิกัดเดียวกัน ระบบพิกัดนั้นคือ Layer หากเปรียบกับสำนักงานก็เหมือนกับการที่แต่ละคนมีโต๊ะของตัวเอง แต่ดูนาฬิกาแขวนผนังและปฏิทินอันเดียวกัน

2.3.2 นิยามของ Layer — การทำให้เป็นนามธรรม 5 ชั้น

Layer ที่ใช้ในหนังสือเล่มนี้คือการทำให้เป็นนามธรรม 5 ชั้น ตั้งแต่ 0 ถึง 4 ยิ่งสูงขึ้นยิ่งเป็นนามธรรมและเปลี่ยนแปลงน้อย ยิ่งต่ำลงยิ่งเป็นรูปธรรมและเปลี่ยนแปลงบ่อย

บทบาทที่แต่ละชั้นทั้งห้ารับผิดชอบในไปป์ไลน์การสร้างแบบโพรซีเดอรัลและการทำงานอัตโนมัติ อยู่ในป้ายกำกับด้านขวาของแผนภาพข้างต้น การแมปนี้คือกระดูกสันหลังของบทนี้ หากมอง Layer เป็นเพียง "โฟลเดอร์ที่จัดเรียงไว้อย่างเป็นระเบียบ" ก็เท่ากับเห็นเพียงครึ่งเดียว แต่ละชั้นสอดคล้องอย่างแม่นยำกับหนึ่งขั้นในไปป์ไลน์การสร้าง (จุดยึด → กฎ → เนื้อหา → ค่า → ด่าน)

5 ชั้นนี้ไม่ใช่แนวคิดเฉพาะเกม กระดูกสันหลังเดียวกันนี้สามารถย้ายไปใช้กับการพัฒนาผลิตภัณฑ์ IT ทั่วไปได้โดยตรง ผู้อ่านที่ไม่เคยทำเกมมาก่อน ขอให้ใช้ตารางแปลงสายงานด้านล่างเพื่อจับคู่แต่ละชั้นกับผลงานของตัวเอง (ด้านซ้ายคือ Layer ของการออกแบบเกม ด้านขวาคือผลงานที่อยู่ในตำแหน่งเดียวกันใน SaaS แอป หรือระบบภายในองค์กร เป็นต้น)

วิธีอ่านเหมือนกับเกมทุกประการ ยิ่งสูงขึ้นยิ่งเปลี่ยนแปลงน้อย (วิสัยทัศน์ผลิตภัณฑ์เปลี่ยนปีละครั้งต่อไตรมาส) ยิ่งต่ำลงยิ่งเปลี่ยนบ่อย (ค่าตั้งค่าเปลี่ยนทุกวัน) อุบัติเหตุไซโลที่เห็นก่อนหน้านี้ — ฉากที่ระยะของสกิลกับความกว้างของทางเดินขัดแย้งกัน — มีโครงสร้างเหมือนกันเป๊ะกับเรื่องที่เกิดใน IT ทั่วไปอย่าง "นิยามฟิลด์ฝั่ง backend (L3) กับกฎหน้าจอฝั่ง front (L1) ไม่ตรงกันจนระเบิดก่อนปล่อยไม่นาน" ต่างกันแค่ชื่อสาขา แต่กระดูกสันหลังมีเพียงหนึ่งเดียว

5 ชั้นนี้ไม่ใช่สิ่งสัมบูรณ์ ขึ้นอยู่กับขนาดและโดเมน 4 ชั้นอาจเหมาะสม หรืออาจต้องการ 6 ชั้น หัวใจสำคัญไม่ใช่ว่าตัวเลขเป็น 5 แต่เป็นตัวการกระทำของการนิยามชั้นอย่างชัดแจ้งเอง

ผลงานหนึ่งชิ้นอาจคร่อมสอง Layer ได้ "GDD ระบบสกิล (Game Design Document หรือเอกสารสเปกละเอียด)" บรรจุทั้งการออกแบบระบบ (Layer 1) และข้อมูลรูปธรรม (Layer 3) ไว้พร้อมกัน ในกรณีนี้ให้แบ่งเอกสารออกหรือกำหนด Layer หลักเป็น 1 แล้วแยกส่วนข้อมูลออกไปเป็นชีตต่างหาก ไม่ว่าจะวิธีใดก็ต้องระบุชัดเจนว่าแต่ละส่วนอยู่ใน Layer ใด

2.3.3 หลักการเมตา — แตกแขนงและรวมเข้าด้วยกันไปพร้อมกัน

สาขางานแผ่ออกในแนวนอน และ Layer ซ้อนกันในแนวตั้ง งานของสาขาหนึ่งคร่อมหลาย Layer เมทริกซ์ด้านล่างแสดงจุดศูนย์ถ่วงของการกระจายของ 11 สาขา (แนวนอน) × Layer 0\~4 (แนวตั้ง) ด้วยความเข้มสีของช่อง ช่องที่เข้มคือ Layer ที่เป็นจุดศูนย์ถ่วงของสาขานั้น

อ่านในแนวตั้งจะเห็นว่าสาขาหนึ่งคร่อมอยู่ใน Layer ใดบ้าง อ่านในแนวนอนจะเห็นว่ามีสาขาใดบ้างที่มารวมอยู่ใน Layer หนึ่ง แถว L0 (วิสัยทัศน์) มีเนื้อเรื่องและอาร์ตไดเรกชันเข้มที่สุด — สองสาขาที่ใกล้วิสัยทัศน์มากที่สุด แถว L3 (ข้อมูล) มีระบบ ต่อสู้ เลเวล บาลานซ์ และตัวละครมารวมกันอย่างเข้มข้น — เป็นสัญญาณว่าสาขาเหล่านี้ปะทะกันที่ชีตข้อมูล

หากมีการกระจายนี้อยู่อย่างชัดแจ้ง สาขาอื่นจะรู้ตำแหน่งได้ทันทีว่า "ต้องไปดู Layer 2 ของฝ่ายต่อสู้" ไม่ใช่กำแพงของไซโลพังลง แต่เป็นการเจาะหน้าต่างบนกำแพงต่างหาก

หากย่อเมทริกซ์ทั้งหมดเป็นประโยคเดียวก็คือเช่นนี้ แกนตั้ง Layer แบ่งไว้เพื่อทำให้การสร้างเป็นอัตโนมัติ แกนนอนสาขาแบ่งไว้เพื่อรักษาความเชี่ยวชาญ ทั้งสองมาพบกันที่ช่องหนึ่งของตาราง

2.3.4 กรณีปฏิบัติงาน — การวัดจริงของโครงการ MMORPG หนึ่ง

โปรเจกต์ MMORPG A ที่ผู้เขียนดูแลในฐานะ Design Director ได้ใช้ระบบ Layer ร่วมกับทีมออกแบบ (4\~5 คน) มาประมาณ 6 เดือน (ทีมพัฒนาทั้งหมดเป็นขนาดกลาง 10\~50 คน) ลองดูกรณีตัวอย่างที่เป็นรูปธรรม

ก่อนอื่น เนื้อเรื่อง 5 ชั้น ตัวโฟลเดอร์ของฝ่ายออกแบบเนื้อเรื่องเองถูกแบ่งออกเป็น Layer

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

เครื่องมือสร้างแผนผังความสัมพันธ์อัตโนมัติ gen_relation_map.py ก็ทำงานควบคู่กันด้วย มันวิเคราะห์ความสัมพันธ์ foreign key (FK) ระหว่างชีตข้อมูล สร้างแผนผังความสัมพันธ์ HTML แบบโต้ตอบได้ และแสดง Layer ด้วยสีของโหนด (แดง=L1 ระบบ, เหลือง=L2 เนื้อหา, เขียว=L3 ข้อมูล) มองเห็นได้ในพริบตาว่าการพึ่งพิงไหลจาก Layer ใดไปยัง Layer ใด หากการพึ่งพิงไหลย้อนทาง — หาก L3 ยิงลูกศรไปหา L1 — เกือบจะเป็นข้อบกพร่องในการออกแบบเสมอ

เอกสารมาสเตอร์การสร้างเลเวลแบบโพรซีเดอรัลระบุพิกัด Layer ไว้ใน frontmatter

---
title: มาสเตอร์การออกแบบเลเวลแบบโพรซีเดอรัล v0.1
layer_inputs: [L1.World, L2.StoryLine]
layer_outputs: [L3.LevelData, L4.PlayCapture]
---

สองบรรทัดนี้ประกาศว่า "ไปป์ไลน์นี้รับ Layer 1·2 เป็นอินพุตและสร้าง Layer 3·4 ออกมา" และการคำนวณขอบเขตผลกระทบเมื่อมีการเปลี่ยนแปลงก็เป็นอัตโนมัติ วิสัยทัศน์ L0 แม้ไม่ระบุก็เป็นอินพุตเสมอ — เพราะไม่ว่าจะเป็นการสร้างใด จุดยึดวิสัยทัศน์ก็พ่วงตามมาทุกครั้ง

ยังมี atom ที่บังคับให้มี Layer prefix ในชื่อเอกสารด้วย หนึ่งใน atom ที่แชร์กันในทีมเป็นเช่นนี้

docs_layer_numeric_prefix_naming: ชื่อไฟล์ชีตข้อมูลต้องมี Layer prefix ของหมายเลข (L1_, L2_, L3_) เสมอ ชีตที่ไม่มี prefix จะถูกเตือนในการตรวจสอบความสอดคล้อง

กฎยิ่งเรียบง่ายยิ่งทรงพลัง เพียงเรียงตามชื่อก็จัดกลุ่มตาม Layer ได้แล้ว และเครื่องมือ AI ก็รู้ Layer ได้จากชื่อไฟล์เพียงอย่างเดียว แม้คนจะลืม การตรวจสอบความสอดคล้องก็จับได้

2.3.5 การตรวจจับการอ้างอิงย้อนทาง — บันทึกเซสชันจริง

ในหัวข้อก่อนหน้า (2.3.4) กล่าวไว้ว่า "หาก L3 ยิงลูกศรไปหา L1 ก็เกือบจะเป็นข้อบกพร่องในการออกแบบเสมอ" หากมอบการตรวจจับนี้ให้ AI แทนสายตามนุษย์ จะเป็นอย่างไร ผู้เขียนจะถ่ายทอดหนึ่งช่วงที่รันจริงตามนั้นโดยไม่ขัดเกลา (ปกปิดเฉพาะข้อมูลที่ระบุตัวบริษัทเท่านั้น)

[พรอมต์ฉบับเต็ม]

ดู frontmatter สองอันที่แนบมาแล้วช่วยตรวจว่าทิศทางการพึ่งพิงของ Layer ปกติหรือไม่
การอ้างอิงต้องไหลจากหมายเลขสูง→หมายเลขต่ำเท่านั้นจึงจะปกติ ถ้าย้อนทางให้เตือน

--- เอกสาร A (L1_combat_system.md) ---
title: โครงสร้างระบบต่อสู้
layer: L1
refs: [L3_skill_damage_sheet, L2_combat_flow]

--- เอกสาร B (L3_skill_damage_sheet.md) ---
title: ชีตดาเมจสกิล
layer: L3
refs: [L1_combat_system]

[ผลลัพธ์ดิบจาก Claude — ตามจริงโดยไม่มีการสรุปย่อ]

ได้ตรวจสอบเอกสารทั้งสองแล้ว

เอกสาร B (L3_skill_damage_sheet, L3):
  refs → [L1_combat_system]
  ทิศทาง: L3 → L1 (รูปธรรม → นามธรรม)
  ผลวินิจฉัย: ปกติ การที่ชีตข้อมูลอ้างอิงโครงสร้างระบบ
        ที่ตัวเองยึดถือเป็นทิศทางที่เป็นธรรมชาติ

เอกสาร A (L1_combat_system, L1):
  refs → [L3_skill_damage_sheet, L2_combat_flow]
  - L1 → L2 : ปกติ (การออกแบบชี้ไปยังโฟลว์ระดับล่าง)
  - L1 → L3 : ⚠ เตือนทิศทางย้อนกลับ
        โครงสร้างระบบ L1 อ้างอิงชีตข้อมูล L3 โดยตรง
        นี่หมายความว่า "เอกสารออกแบบขึ้นต่อค่าข้อมูล
        เฉพาะค่าหนึ่ง" ก่อให้เกิดการยึดเกาะที่ทำให้ต้อง
        แก้เอกสารออกแบบทุกครั้งที่ข้อมูลเปลี่ยน

ข้อแนะนำ: ลบ L3_skill_damage_sheet ออกจาก refs ของเอกสาร A
      หากโครงสร้างระบบจำเป็นต้องรู้ค่าตัวเลขที่เป็นรูปธรรม
      ให้ย้ายค่านั้นขึ้นเป็นกฎนามธรรมใน L1 (เช่น "ดาเมจพื้นฐาน
      คือ สัมประสิทธิ์คลาส × เลเวล") หรือผ่านเอกสารโฟลว์ L2

สรุป: ตรวจพบการอ้างอิงย้อนทาง 1 รายการ (A: L1 → L3)

[การตรวจสอบโดยมนุษย์ / การปฏิเสธ]

ผลวินิจฉัยของ AI ถูกต้อง แต่ข้อแนะนำว่า "ให้ผ่านเอกสารโฟลว์ L2" นั้นเกินไปในเคสนี้ สิ่งที่ L1 จำเป็นต้องรู้คือ รูปแบบ ของสูตรดาเมจ ไม่ใช่เซลล์เฉพาะใดของชีต ผู้เขียนจึงรับเฉพาะข้อแนะนำที่สอง (การยกขึ้นเป็นกฎนามธรรม) และปฏิเสธข้อเสนอให้ผ่านโฟลว์

[การร้องขอใหม่]

ตัดข้อเสนอให้ผ่านโฟลว์ออก แล้วแสดงเฉพาะ diff การแก้ไข
ของ L1_combat_system.md ในทิศทาง "ยกเฉพาะรูปแบบของสูตร
ดาเมจขึ้นเป็นกฎนามธรรมใน L1" เท่านั้น
จัดระเบียบ refs ด้วย

หนึ่งวงรอบนี้คือฐานที่มั่นของการตรวจจับการอ้างอิงย้อนทาง AI จับการละเมิดทิศทาง (อัตโนมัติ) คนเล็มความเหมาะสมของข้อแนะนำ (การตรวจสอบ) และสั่งทำใหม่เฉพาะงานที่แคบลงแล้ว (การร้องขอใหม่) ในโปรเจกต์ A นั้น gen_relation_map.py ทำงานในระดับกราฟ และ atom portal_layer_change_impact_check จะถูกกระตุ้น ณ จุดตรวจจับการเปลี่ยนแปลง เพื่อบังคับให้ตรวจสอบขอบเขตผลกระทบ

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

2.3.6 การแยกย่อย Layer = เงื่อนไขเบื้องต้นของการสร้างแบบโพรซีเดอรัลและการทำงานอัตโนมัติ

จุดประสงค์ที่ผิวเผินของการรวม Layer คือการคลายไซโลและการทำให้ภาษาในการทำงานร่วมกันเป็นหนึ่งเดียว (2.3.1\~2.3.5) แต่จุดประสงค์ที่แท้จริงลึกลงไปอีกขั้นหนึ่ง เมื่อการแยกย่อย Layer ลงตัวแล้ว เงื่อนไขเบื้องต้นของการสร้างแบบโพรซีเดอรัลและการทำงานอัตโนมัติก็พร้อม

กรณีปฏิบัติงานในสองหัวข้อก่อนหน้าเป็นขั้นที่คนตัดสินใจและ AI ช่วยตรวจสอบและฉีดข้อมูล ขั้นถัดไปจะเข้าสู่ขั้นที่ AI สร้างผลผลิตของตัวสาขาเองเป็นตัวเลือกและคนเป็นผู้รับเลือก เหตุผลที่การแยกย่อย Layer เป็นเงื่อนไขเบื้องต้นของการเคลื่อนนี้มีสามประการ ① การสร้างตัวเลือกของ AI ต้องระบุได้ว่า "จะสร้างอะไรของ Layer ใด" ② การตรวจสอบความสอดคล้องอัตโนมัติทำงานได้ต่อเมื่อทิศทางการพึ่งพิงระหว่าง Layer ถูกทำให้เป็นมาตรฐาน (การตรวจจับการอ้างอิงย้อนทางใน 2.3.5) ③ การคำนวณผลกระทบจากการเปลี่ยนแปลงอัตโนมัติทำได้ก็ต่อเมื่อมีพิกัดว่าการเปลี่ยนแปลงเกิดขึ้นที่ Layer ใด ทั้งสามมารวมกันที่ "หากไม่มีการแยกย่อย Layer การทำงานอัตโนมัติเองก็ถูกปิดกั้น" ปลายทางของมือที่แบ่งพิกัดมีการสร้างแบบโพรซีเดอรัลรออยู่ตั้งแต่แรก

ในขั้นที่ยังไม่ได้ดูส่วนของแต่ละสาขา จึงไม่จำเป็นต้องลงลึก เราจะจับโครงไว้เพียงสองขั้นของการประยุกต์ การประยุกต์เชิงอนุรักษ์ คือคนตัดสินใจ และ AI ช่วยตรวจสอบความสอดคล้อง คำนวณผลกระทบจากการเปลี่ยนแปลง และฉีดข้อมูลแบบ JIT โดยอัตโนมัติ — กรณีปฏิบัติงานใน 2.3.4·2.3.5 อยู่ตรงนี้ ต้นทุนของเครื่องมือต่ำและผลสะสมจะเผยตัวราวเดือนที่ 6 ของการใช้งาน ทีมขนาดกลาง (10\~50 คน) ส่วนใหญ่จึงเข้าถึงได้ การประยุกต์เชิงก้าวหน้า ก้าวไปอีกขั้นโดยให้ AI สร้างผลผลิตของตัวสาขาเองเป็นตัวเลือก (เนื้อเรื่อง Persona, rulebook PCG, เลเวลแบบโพรซีเดอรัล, ตัวเลือกการเปลี่ยนบาลานซ์, แอสเซตอาร์ต เป็นต้น) และคนตัดสินใจเพียง "จะรับตัวเลือกใด" เท่านั้น รูปแบบของแต่ละสาขาและความสุกงอมของเครื่องมือจะกล่าวถึงในส่วนของสาขานั้นๆ

3 องค์ประกอบที่การประยุกต์เชิงก้าวหน้าต้องการร่วมกันในทุกสาขาคือ ① โครงสร้างพื้นฐานของการแยกและติดป้าย Layer (frontmatter · atom · prefix ชื่อไฟล์) ② วงรอบการสร้างและประเมินตัวเลือก (ตัวเลือกจาก AI จำนวน N → ประเมินอัตโนมัติ → รายงานอันดับและเหตุผล) ③ ด่านตรวจสอบโดยมนุษย์ (เฉพาะผลที่ถูกรับเลือกเท่านั้นที่ไปสู่ Layer ถัดไป) ทั้งนี้ ไม่ว่าจุดใดก็ตาม แกนกลางเชิงกำหนด (การจำลอง · ฟิสิกส์ · ข้อจำกัดทางกฎหมาย) ยังคงเป็นความรับผิดชอบของคนและโค้ดเชิงกำหนด และการตรวจสอบทั้งหมดต้องจบลงในขั้นที่ย้อนกลับได้ก่อนเข้าสู่ขั้นที่ย้อนกลับไม่ได้ (การอัดเสียง · การแคสต์ · การเปิดเผยในไลฟ์ เป็นต้น) — เส้นแบ่งย้อนกลับได้/ย้อนกลับไม่ได้นี้เป็นหลักการร่วมของทุกสาขา

สุดท้าย จุดเรื่องเวลาหนึ่ง การประยุกต์เชิงอนุรักษ์เป็นไปได้บางส่วนแม้ในทศวรรษ 2010 แต่การประยุกต์เชิงก้าวหน้าติดอยู่ที่สามขีดจำกัด คือ พลังการแสดงออกของการสร้างตัวเลือกด้วย AI การตีความภาษาธรรมชาติของการประเมินอัตโนมัติ และภาระการตรวจสอบโดยมนุษย์ หลังจาก LLM พัฒนาขึ้น ทั้งสามก็เข้าสู่ขอบเขตที่ใช้งานได้จริง และการประยุกต์เชิงก้าวหน้าก็ลงจากวิสัยทัศน์บนกระดาษสู่ขั้นปฏิบัติงาน สารเมตาที่ร้อยทะลุทั้งเล่มนี้ — ว่าการพัฒนาของ AI ได้ยกระดับความเป็นไปได้ของการสร้างแบบโพรซีเดอรัลและการทำงานอัตโนมัติ — อยู่ตรงนี้

2.3.7 พิกัดของสาขา — ที่ที่ส่วนของแต่ละสาขาในหนังสือเล่มนี้อาศัยอยู่

ส่วนของแต่ละสาขาในหนังสือเล่มนี้จะระบุในบทนำว่าแต่ละสาขากระจายอยู่ใน Layer ใดเป็นหลัก และใช้พิกัด Layer บ่อยภายในบทด้วย ขอจัดระเบียบไว้ล่วงหน้า (เป็นการย้ายจุดศูนย์ถ่วงของเมทริกซ์ 2.3.3 มาเป็นตาราง)

แต่ละสาขาแตะ Layer อื่นด้วย แต่หากรู้จุดศูนย์ถ่วงก็จะเห็นช่องทางการทำงานร่วมกัน บาลานซ์ (L3) กับไลฟ์ (L2\~L4) มาพบกันที่ L3 จึงต้องทำงานร่วมกันใกล้ชิดเสมอ และสองสาขาที่ใกล้วิสัยทัศน์ (L0) มากที่สุดคือเนื้อเรื่องและอาร์ตไดเรกชัน ความสัมพันธ์ที่ติดกันเช่นนี้เผยตัวอย่างเป็นธรรมชาติบนระบบพิกัด

2.3.8 เริ่มเล็ก ขยายใหญ่

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

flowchart LR
    S1["ขั้นที่ 1
นำมาใช้ในสาขาเดียว
(แนะนำ: เนื้อเรื่อง)"] --> S2["ขั้นที่ 2
ขยายไปสาขาที่ติดกัน
(เนื้อเรื่อง+เนื้อหา)"]
    S2 --> S3["ขั้นที่ 3
ทำให้เป็นมาตรฐานทุกสาขา
(prefix ชื่อไฟล์·ตรวจสอบความสอดคล้อง)"]
    S3 --> S4["ขั้นที่ 4
ผสานเครื่องมือ AI
(JIT·ผลกระทบจากการเปลี่ยนแปลง·จำแนกการทบทวน)"]
    S1 -.->|"ทีมขนาดเล็ก (~10 คน)"| E1["แค่นี้ก็พอ"]
    S3 -.->|"ทีมขนาดกลาง (10~50 คน)"| E2["แนะนำถึงตรงนี้"]
    S4 -.->|"ทีมขนาดใหญ่ (100+ คน)"| E3["ต้องไปถึงตรงนี้จึงจะเห็นผล"]
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class S1,S2,S3,S4 human
    class E1,E2,E3 pass

• ขั้นที่ 1 (สาขาเดียว): เลือกสาขาเดียว (แนะนำ: เนื้อเรื่อง) แล้วแบ่งโฟลเดอร์ออกเป็น Layer ทิ้งสาขาอื่นไว้ก่อน ใช้งานสักหนึ่งถึงสองเดือนพร้อมขัดเกลานิยาม Layer
• ขั้นที่ 2 (ขยายไปสาขาที่ติดกัน): ประยุกต์พร้อมกันกับสองสาขาที่เส้นโค้งการแตกแขนงใกล้กัน (เช่น เนื้อเรื่อง+เนื้อหา) สังเกตรูปแบบที่ Layer ประสานกัน และสร้างกฎความสอดคล้อง 1\~2 ข้อด้วย atom
• ขั้นที่ 3 (ทำให้เป็นมาตรฐานทุกสาขา): ให้พิกัด Layer แก่ทุกสาขา นำกฎชื่อไฟล์ (L1_·L2_·L3_ prefix) มาใช้ และทำให้แผนผังความสัมพันธ์·การตรวจสอบความสอดคล้องเป็นอัตโนมัติ
• ขั้นที่ 4 (ผสานเครื่องมือ AI): ใช้ประโยชน์จากเมทาดาทา Layer ใน JIT hook คำนวณขอบเขตผลกระทบจากการเปลี่ยนแปลงอัตโนมัติ และเพิ่มการจำแนก Layer เข้าไปในระบบการทบทวน

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

ขนาดเล็ก (\~10 คน) ทำขั้นที่ 1\~2 ขนาดกลาง (10\~50 คน) ทำขั้นที่ 3 ขนาดใหญ่ (100+ คน) ต้องไปถึงขั้นที่ 4 จึงจะเห็นผล ไม่ได้หมายความว่าทีมเล็กใช้ไม่ได้ ต่างกันแค่ความลึก แต่คุณค่าหลักเริ่มต้นแล้วตั้งแต่ขั้นที่ 1

2.3.9 บทสรุป — กระดูกสันหลังของทั้งเล่ม

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

• คงการแตกแขนงไว้ — ความเชี่ยวชาญและเครื่องมือของแต่ละสาขาคงไว้ตามเดิม
• เพิ่มการรวมเข้าด้วยกัน — ผลงานทุกชิ้นถูกจัดวางบนระบบพิกัดเดียวกัน
• AI เข้าใจระบบพิกัดนี้และดำเนินการฉีดข้อมูลอัตโนมัติ · ตรวจสอบความสอดคล้อง · การแพร่กระจายการเปลี่ยนแปลง (การประยุกต์เชิงอนุรักษ์)
• บนระบบพิกัดเดียวกันนี้ การประยุกต์เชิงก้าวหน้าของแต่ละสาขาเติบโตขึ้นทีละขั้น

ส่วนที่เหลือทั้งหมดของหนังสือเล่มนี้ตั้งอยู่บนสมมติฐานของบทนี้ ส่วนของแต่ละสาขาจะระบุพิกัดที่สาขานั้นครองอยู่ใน Layer ไว้ในบทนำ ส่วนกระบวนการจะกล่าวถึงระบบการใช้งานที่ตัดข้าม Layer และส่วนการให้บริการจะกล่าวถึงวงจร self-improving ของตัวระบบ Layer เอง

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

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

สรุปประเด็นสำคัญของบท

• Layer คือระบบพิกัดที่เพิ่มการมองเห็นแบบรวมเข้าไปในขณะที่คงการแตกแขนงของสาขาไว้ และเป็นกระดูกสันหลังของทั้งเล่ม
• แต่ละชั้นทั้งห้าสอดคล้องกับบทบาทหนึ่งของการสร้างแบบโพรซีเดอรัล (จุดยึด · กฎ · เนื้อหา · ค่า · ด่าน)
• รูปแบบที่เป็นคำตอบของการทำงานอัตโนมัติคือ AI จับและคนเล็ม เหมือนการตรวจจับการอ้างอิงย้อนทาง (L3→L1)

atom หลักของบทนี้ (อ้างอิง)

• layer_unified_design_philosophy — atom แม่แบบของบทนี้
• docs_layer_numeric_prefix_naming — กฎบังคับ prefix ชื่อไฟล์
• dead_table_5layer_cleanup — กฎจัดระเบียบชีตนอก 5 ชั้น
• portal_layer_change_impact_check — ตรวจสอบผลกระทบจากการเปลี่ยนแปลงอัตโนมัติ

ตัวอย่างบทถัดไป

• บทที่ 7 ภววิทยาเกมและกราฟความรู้ — เพิ่มลูกศรเชิงความหมายลงบนพิกัด Layer
• บทที่ 8 ระบบ Wikilink — รูปแบบการอ้างอิงที่สกัดจากองค์ความรู้ในการใช้งานจริง

ลองทำดู

setup — เลือกโฟลเดอร์ของสาขาหนึ่ง (แนะนำ: เนื้อเรื่อง) แล้วแบ่งโฟลเดอร์ย่อยออกเป็น 5 อันตั้งแต่ Layer0_Vision/ จนถึง Layer4_BuildVO/ ย้ายไฟล์เดิมไปยัง Layer ที่เหมาะสม ไฟล์ที่ชื่อกำกวมให้จัดวางโดยใช้เกณฑ์ "ความถี่ที่เอกสารนี้เปลี่ยนแปลง" (ยิ่งเปลี่ยนบ่อยยิ่งอยู่ Layer ล่าง)

prompt — เลือก frontmatter ของชีตข้อมูลสองอัน แล้ววางพรอมต์ฉบับเต็มของ 2.3.5 ลงไปตามนั้น ให้วินิจฉัยทิศทางการพึ่งพิงของ Layer เพียงให้กฎหลักหนึ่งบรรทัดอย่างแม่นยำก็พอ "การอ้างอิงต้องไหลจากรูปธรรม→นามธรรม (หมายเลขสูง→หมายเลขต่ำ) เท่านั้นจึงจะปกติ"

verify — เมื่อ AI จับการอ้างอิงย้อนทางได้ อย่ารับข้อแนะนำนั้นมาตามนั้น แต่ให้เล็มความเหมาะสมด้วยตัวเอง (ดู "การตรวจสอบโดยมนุษย์/การปฏิเสธ" ของ 2.3.5) ร้องขอใหม่เป็น diff เฉพาะทิศทางที่รับเลือก หากเรียงตามชื่อแล้วเห็น Layer มัดรวมจากบนลงล่าง แสดงว่ากฎ prefix ลงตัวแล้ว

ฉบับย่อสำหรับคนเดียว

แม้ทำงานคนเดียว Layer ก็ทำงานได้ เพราะไม่มีทีมจึงไม่มี "ไซโลระหว่างสาขา" แต่มี "ไซโลระหว่างช่วงเวลา" ตัวเราเมื่อ 3 สัปดาห์ก่อนกับตัวเราวันนี้ลืมการตัดสินใจของกันและกัน เพียงแบ่งโฟลเดอร์ออกเป็น Layer 0\~4 — วิสัยทัศน์หนึ่งแผ่น โครงสร้างระบบไม่กี่แผ่น โฟลว์ความคืบหน้า ชีตข้อมูล บันทึกบิลด์ — ก็หาได้ทันทีว่าตัวเราในอดีตวางอะไรไว้ในช่องไหน เพียงพ่วงหนึ่งบรรทัดให้ AI ว่า "ตอนนี้กำลังทำงาน L2 อยู่" มันก็จะไม่ดึงข้อมูล Layer ที่ไม่เกี่ยวข้องเข้ามา จะลดเหลือ 4 ชั้น · 3 ชั้นก็ได้ หัวใจสำคัญไม่ใช่ตัวเลข แต่เป็นตัวการกระทำของการ "ระบุชั้นอย่างชัดแจ้ง"

2.4 ออนโทโลยีและกราฟ wikilink — ตรวจสอบลูกศรเชิงความหมาย

เช้าวันจันทร์ มีคำขอเปลี่ยนแปลงหนึ่งรายการถูกส่งเข้ามา สมาชิกทีมต่อสู้ A เขียนข้อความหนึ่งบรรทัดลงในแชตภายในทีม "ผมจะเปลี่ยน global cooldown จาก 0.5 วินาทีเป็น 0.3 วินาทีนะ มีที่ไหนได้รับผลกระทบไหม" หากเป็นปกติแล้ว จากตรงนี้จะเริ่มต้นการประชุมยาว 30 นาที คนดูแลสูตรคำนวณดาเมจยกมือขึ้น คนดูแลกฎ combo cancel ก็แทรกเข้ามา และมีใครบางคนถามว่า "แพตเทิร์นบอสไม่ได้รับผลกระทบด้วยหรือ" เมื่อไม่มีใครเก็บภาพรวมทั้งหมดไว้ในหัว การประชุมจึงเต็มไปด้วยการพยายามรื้อความทรงจำ

แต่คราวนี้ต่างออกไป หนึ่งวินาทีหลังจากส่งคำขอ บอตได้แสดงคอมเมนต์อัตโนมัติขึ้นมา "หากเปลี่ยน atom นี้ จะมี atom 4 รายการที่ได้รับผลกระทบ ได้แก่ skill_dps_calculation, combat_combo_cancel_v3, refgame_boss_pattern_phase2, balance_curve_v3 ผู้รับผิดชอบ: สมาชิกทีม B, สมาชิกทีม A, สมาชิกทีม C" การประชุมไม่ถูกเปิดขึ้น ทั้ง 4 คนต่างตรวจสอบเฉพาะ atom ของตัวเองแล้วก็จบ (บอตตัวนี้เราจะสร้างขึ้นเองในภายหลัง — 2.4.3)

คอมเมนต์นี้ไม่ใช่เวทมนตร์ ในหัวข้อ 2.3 เราได้กำหนดพิกัด Layer ให้กับ atom ทุกตัวไปแล้ว และบนพิกัดนั้น ในบทนี้เราได้เพิ่ม ลูกศรเชิงความหมาย — การตัดสินใจใดส่งผลต่อการตัดสินใจใด — เข้าไป พิกัดบอกได้เพียงแค่ "ตรงนี้มีอะไรอยู่" เท่านั้น ส่วนความสัมพันธ์อย่าง "สิ่งนี้ส่งผลต่อสิ่งนั้น" "สิ่งนั้นต้องมีอยู่ก่อนจึงจะตั้งอยู่ได้" "สองสิ่งนี้เปิดพร้อมกันไม่ได้" คือลูกศรที่ถูกวาดลงบนพิกัด บทนี้จะกล่าวถึงว่าจะเขียนกำกับลูกศรเหล่านั้นอย่างไร และจะตรวจจับลูกศรที่ขาดโดยอัตโนมัติได้อย่างไร

บันทึกศัพท์ - ออนโทโลยี (ontology): ระบบที่นิยามแนวคิดและความสัมพันธ์ระหว่างแนวคิดเหล่านั้นอย่างชัดเจน ในหนังสือเล่มนี้เราใช้เวอร์ชันเบาที่ลดรูปให้เหลือความสัมพันธ์ 6\~12 แบบ - wikilink: ลิงก์ระหว่างเอกสารในรูปแบบ [[atom_name]] ยืมการเขียนกำกับมาจากเครื่องมืออย่าง Obsidian และ Roam - การอ้างกลับ (backlink): รายการของ "atom ทั้งหลายที่ชี้มายัง atom นี้" ทิศทางตรงข้ามกับการอ้างไปข้างหน้า - โหนดกำพร้า (orphan): atom ที่ไม่ถูกอ้างถึงจากที่ใดเลย เป็นสัญญาณว่าเป็นผู้สมัครสำหรับการเลิกใช้ - ลิงก์ที่ขาด (broken link): wikilink ที่ชี้ไปยัง atom ซึ่งไม่มีอยู่จริง ร่องรอยของการพิมพ์ผิดหรือการเปลี่ยนชื่อ

2.4.1 ความสัมพันธ์คือลูกศร — เหตุใด wikilink เพียงอย่างเดียวจึงไม่พอ

ในหัวข้อ 2.1 เราได้แนบเมตาดาตาด้วย YAML frontmatter และโปรย wikilink ไว้ในเนื้อหาของ atom เพียงเท่านั้นเอกสารก็เชื่อมโยงกันเป็นตาข่ายอยู่แล้ว ปัญหาคือการเชื่อมโยงเหล่านั้น ไม่ได้เขียนกำกับไว้ว่าหมายความว่าอะไร

การตัดสินใจนี้ตั้งอยู่บน [[skill_cooldown_rule_v2]]

บรรทัดเดียวนี้บอกได้เพียงแค่ "กล่าวถึง skill_cooldown_rule_v2" เท่านั้น เหตุใดจึงกล่าวถึง การตัดสินใจนี้ ต้องการ (requires) กฎข้อนั้นหรือ แตกแขนงมาจาก (derives_from) กฎข้อนั้นหรือ หรือว่า ขัดแย้งกับ (conflicts_with) กฎข้อนั้น มนุษย์อ่านประโยคแล้วก็เข้าใจ แต่เครื่องไม่รู้ ต่อให้ถาม AI ว่า "ถ้าเปิดการตัดสินใจนี้ มีอะไรพังบ้าง" ลิงก์ที่ไร้ความหมายเพียงอย่างเดียวก็ตอบไม่ได้

ดังนั้นเราจึงสวม ประเภทความสัมพันธ์ ลงบน wikilink ความสัมพันธ์ที่ใช้กันจริงในการออกแบบเกมนั้นน้อยอย่างคาดไม่ถึง หกแบบต่อไปนี้ครอบคลุมได้มากกว่า 90%

atom ที่ตรึงหกแบบนี้ไว้เป็น enum คือ ontology_relation_enum_v1 หากต้องการเพิ่มประเภทความสัมพันธ์ใหม่ จะต้องผ่านการรีวิวคำขอเปลี่ยนแปลง แม้จะเพิ่มขึ้นเส้นที่เหมาะสมก็อยู่ที่ 10\~12 แบบ และในตอนเริ่มต้นจะเริ่มด้วยสามแบบคือ affects·derives_from·requires ก็เพียงพอแล้ว ที่ที่จะเขียนความสัมพันธ์ลงไปคือ YAML frontmatter ของ atom

---
name: combat_combo_cancel_v3
layer: 1
affects: [skill_dps_calculation, refgame_boss_pattern_phase2]
derives_from: [vision_taste_focused_combat]
requires: [combat_input_buffer_system, skill_cooldown_rule_v2]
conflicts_with: [skill_cancel_rule_legacy_v1]
---

มนุษย์เขียนแค่ทิศทางไปข้างหน้าเพียงบรรทัดเดียว ส่วนทิศทางย้อนกลับ ("ใครที่ affects ฉัน") เครื่องมือจะสแกนทั้งหมดแล้วคำนวณให้เอง หากเขียน affects ไว้ทั้งสองฝั่ง ภาระในการซิงค์จะเพิ่มเป็นสองเท่า และวินาทีที่แก้ฝั่งหนึ่งแล้วลืมอีกฝั่ง กราฟก็จะเริ่มโกหก ทิศทางเดียวด้วยมือ ทิศทางตรงข้ามด้วยเครื่องมือ คือหลักการที่ร้อยเรียงทั้งบทนี้เข้าด้วยกัน

2.4.2 บันทึกเซสชันจริง (worked transcript) — ตรวจสอบการอ้างกลับของ wikilink และความสมบูรณ์ของกราฟในคราวเดียว

จากตรงนี้ไปจะถ่ายทอดเซสชันหนึ่งที่เกิดขึ้นจริงทั้งยวง สถานการณ์เป็นดังนี้ ในขณะที่รื้อกฎ combo cancel จาก v2 ไปเป็น v3 เราตัดสินใจจะเลิกใช้ skill_cancel_rule_legacy_v1 แต่ก่อนจะเลิกใช้นั้น ต้องตรวจสอบก่อนว่า มี atom อื่นที่ชี้มายัง atom นี้หรือไม่ (การอ้างกลับ) และ หลังจากเลิกใช้แล้วจะไม่มีลิงก์ที่ขาดหรือความขัดแย้งหลงเหลืออยู่หรือไม่ (ความสมบูรณ์ของกราฟ) หากใช้มือ grep ก็จะตกหล่น เราจึงให้ Claude ทำ

พรอมต์ (ฉบับเต็ม)

ในโฟลเดอร์ atom (decisions/) ที่แนบมา มี atom อยู่ และใน frontmatter
น่าจะมีความสัมพันธ์ (affects/derives_from/requires/conflicts_with/is_a/part_of)
เขียนไว้ ในเนื้อหาก็มี wikilink ด้วย ตอนนี้ฉันจะเลิกใช้
skill_cancel_rule_legacy_v1 ก่อนเลิกใช้ช่วยตรวจ 3 อย่างให้หน่อย:
1) การอ้างกลับ 2) ลิงก์ที่ขาด 3) ความขัดแย้ง อย่าเดา ให้อ่านไฟล์จริง ๆ
แล้วตอบ ถ้าหาไม่เจอก็บอกว่าหาไม่เจอ
// การอ้างกลับ=ทั้งความสัมพันธ์ใน YAML และ wikilink ในเนื้อหา / ลิงก์ที่ขาด=ลิงก์ที่กลายเป็น stale·ไม่มีอยู่เพราะการเลิกใช้
// ความขัดแย้ง=ในบรรดาคู่ conflicts_with มี status: approved ที่ยังมีชีวิตอยู่หรือไม่

ผลลัพธ์จาก Claude (ดิบ — ไม่ได้สรุปหรือเรียบเรียง)

ได้อ่านไฟล์ 47 ไฟล์ในโฟลเดอร์ decisions/ แล้ว นี่คือผลการตรวจสอบ 3 อย่างเกี่ยวกับ skill_cancel_rule_legacy_v1

1. การอ้างกลับ (atom ที่ชี้มายัง atom นี้)

atom ที่ชี้มาด้วยความสัมพันธ์ใน YAML: - combat_combo_cancel_v3 — conflicts_with: [skill_cancel_rule_legacy_v1] - skill_cancel_rule_v2 — derives_from: [skill_cancel_rule_legacy_v1]

atom ที่ชี้มาด้วย wikilink ในเนื้อหา: - เนื้อหาของ combat_combo_cancel_v3: "แก้ปัญหา input buffer ของเวอร์ชันเก่า [[skill_cancel_rule_legacy_v1]]" - เนื้อหาของ qa_combat_regression_checklist: "รายการ regression ข้อ 3 เขียนขึ้นโดยอ้างอิง [[skill_cancel_rule_legacy_v1]]"

กล่าวคือ มี atom 4 รายการที่อ้างถึง atom นี้ (YAML 2 + wikilink ในเนื้อหา 2 แต่ combat_combo_cancel_v3 ปรากฏทั้งสองฝั่ง ดังนั้นจำนวน atom จริงคือ 3 รายการ)

2. ลิงก์ที่ขาด (จุดที่จะขาดเมื่อเลิกใช้)

การเลิกใช้ในตัวมันเองไม่ได้ทำให้ wikilink "ขาด" — เพราะไฟล์ยังอยู่ มีแค่ status ที่กลายเป็น deprecated เท่านั้น อย่างไรก็ตาม: - qa_combat_regression_checklist นิยามรายการ regression โดยอ้างอิง atom ที่ถูกเลิกใช้ จึง ไร้ผลในเชิงเนื้อหา นี่ไม่ใช่ลิงก์ที่ขาดแต่เป็น stale link จำเป็นต้องตรวจทาน - หากท่าน ลบ ไฟล์ออกไปด้วย การอ้างอิงทั้ง 4 รายการข้างต้นจะกลายเป็นลิงก์ที่ขาดทั้งหมด

⚠️ มีจุดหนึ่งที่คลุมเครือ: ในเนื้อหาของ balance_curve_v3 มีลิงก์ [[skill_cancel_rule_legacy]] (ไม่มี _v1 ต่อท้าย) อยู่ ไม่อาจมั่นใจได้จากตัวไฟล์เพียงอย่างเดียวว่านี่เป็นการพิมพ์ผิดที่ตั้งใจจะชี้ไปยัง _v1 หรือว่าตั้งใจให้เป็น atom แยกอีกตัว ไฟล์ชื่อ skill_cancel_rule_legacy นั้น ไม่มีอยู่ ในโฟลเดอร์ กล่าวคือนี่มีความเป็นไปได้สูงว่าเป็นลิงก์ที่ขาดอยู่แล้ว จำเป็นต้องตรวจสอบ

3. ความขัดแย้งที่หลงเหลือ (คู่ conflicts_with ยังมีชีวิตอยู่หรือไม่)

atom ที่ผูกกับ skill_cancel_rule_legacy_v1 ด้วย conflicts_with มีเพียง combat_combo_cancel_v3 ตัวเดียว - status ของ combat_combo_cancel_v3: approved (ยังมีชีวิตอยู่)

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

---

สรุป: การเลิกใช้ปลอดภัย แต่ให้จัดการสองอย่างก่อน (a) stale link ของ qa_combat_regression_checklist — อัปเดตรายการ regression ข้อ 3 (b) [[skill_cancel_rule_legacy]] ของ balance_curve_v3 — สงสัยว่าพิมพ์ผิด อาจเป็นลิงก์ที่ขาดอยู่แล้ว

การตรวจสอบและการยับยั้งของมนุษย์

ตรงนี้ผมไม่ได้รับผลลัพธ์มาตามนั้นทั้งดุ้น (a) นั้นถูกต้อง — เช็กลิสต์ regression เป็นสิ่งที่ผมต้องอัปเดตเอง แต่ผมหยุดที่ (b) Claude บอกว่า [[skill_cancel_rule_legacy]] ของ balance_curve_v3 "สงสัยว่าพิมพ์ผิด" แต่ผมต้องเปิดโฟลเดอร์ดูเองว่ามันเป็นลิงก์ที่ขาดจริงหรือไม่ คำว่า "ไม่อาจมั่นใจได้" ของ AI เป็นสัญญาณที่ซื่อสัตย์ ไม่ใช่ข้อสรุป

เมื่อเปิดโฟลเดอร์ดูก็พบว่าไฟล์ชื่อ skill_cancel_rule_legacy ไม่มีอยู่จริง แต่เมื่อดู git log ก็พบว่าเมื่อ 6 เดือนก่อนมีคอมมิตที่ เปลี่ยนเพียงชื่อ จาก skill_cancel_rule_legacy → skill_cancel_rule_legacy_v1 ตอนนั้นเองที่ลิงก์ในเนื้อหาของ balance_curve_v3 ไม่ได้รับการอัปเดตและถูกปล่อยผ่านไป กล่าวคือนี่ไม่ใช่การพิมพ์ผิดแต่เป็น ลิงก์ที่ขาดซึ่งกลายเป็นกำพร้าหลังการเปลี่ยนชื่อ การคาดเดาว่า "สงสัยว่าพิมพ์ผิด" ของ Claude ถูกเพียงครึ่งเดียว สาเหตุไม่ใช่การพิมพ์ผิดแต่เป็นการตกหล่นในการ rename หากผมไม่จับความต่างนี้ ก็คงแก้แค่เช็กลิสต์ regression แล้วฝังลิงก์ที่ขาดเอาไว้ตามเดิม

การร้องขอใหม่ (สะท้อนข้อเท็จจริงที่ตรวจยืนยันแล้ว)

ตรวจสอบแล้ว [[skill_cancel_rule_legacy]] ไม่ใช่การพิมพ์ผิด แต่เป็นลิงก์ที่ขาด
ซึ่งตอน rename เมื่อ 6 เดือนก่อน (_legacy → _legacy_v1) ลืมแก้ลิงก์ในเนื้อหา

งั้นถือโอกาสนี้ ช่วยค้นหา "wikilink ที่ชี้ไปยัง atom ที่ไม่มีอยู่จริง"
ทั้งหมดในโฟลเดอร์ให้ที โดยยึดจาก wikilink ในเนื้อหา ที่ไฟล์เป้าหมายไม่มีในโฟลเดอร์ ทั้งหมด
แสดงชื่อไฟล์และลิงก์ที่ขาดในนั้นเป็นตาราง

ได้รวบรวม wikilink ในเนื้อหาทุก [[...]] ของไฟล์ทั้ง 47 ไฟล์ แล้วเทียบกับรายชื่อไฟล์ในโฟลเดอร์ ลิงก์ที่ขาดซึ่งไฟล์เป้าหมายไม่มีอยู่จริงมี 3 รายการ

ไฟล์ที่มีลิงก์	wikilink ที่ขาด	สาเหตุที่คาดว่า
balance_curve_v3	[[skill_cancel_rule_legacy]]	ตกหล่นในการ rename (→ _v1)
quest_reward_table_v2	[[concept_reward_currency]]	atom เป้าหมายยังไม่ได้เขียน (มีแต่แผน ไม่มีไฟล์)
refgame_boss_pattern_phase2	[[skill_global_cooldown]]	ตกหล่นในการ rename (→ skill_global_cooldown_rule)

ใน 3 รายการ 2 รายการ (ตกหล่นในการ rename) แก้ได้โดยเปลี่ยนชื่อ atom เป้าหมายเป็น _v1 / _rule ส่วน 1 รายการ (concept_reward_currency) ตัว atom ที่ชี้ไปนั้นไม่มีอยู่ จึงต้องเขียนขึ้นหรือไม่ก็ลบลิงก์ออก ผมไม่ได้แก้ให้โดยอัตโนมัติ — โปรดตรวจสอบว่าท่านตั้งใจแบบใดก่อนดำเนินการ

ทั้งสามรายการเป็นความจริง หากใช้มือ grep ก็เกือบจะแน่นอนว่าจะพลาดลิงก์ที่ขาดของ quest_reward_table_v2 ลิงก์นั้นเป็น "การอ้างอิงอนาคตที่ตั้งใจ" ซึ่งชี้ล่วงหน้าไปยัง atom ที่ยังไม่ได้สร้าง แต่ตลอด 6 เดือนไม่มีใครสร้าง atom นั้นขึ้นมา มันจึงกลายเป็นคำสัญญาที่ตายไปแล้วในทางพฤตินัย

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

2.4.3 สิ่งที่มองเห็นเมื่อวาดเป็นกราฟ — ย้ายการตรวจสอบไปสู่ภาพ

การตรวจสอบในหัวข้อก่อนหน้าจะรันด้วยพรอมต์ทุกครั้งก็ได้ แต่หากตรึงการตรวจสอบเดียวกันนั้นไว้ในโค้ด ก็จะมองเห็นได้ในแวบเดียวบนกราฟ ในโปรเจกต์ A มีเครื่องมือกราฟที่ขยายจาก gen_relation_map.py ที่แนะนำในหัวข้อ 2.3 เดินงานในฐานะ R&D หัวใจคือการอ่าน atom ในโฟลเดอร์มาสร้างเป็นกราฟทิศทางด้วย networkx แล้ววางฟังก์ชันตรวจสอบสี่อย่างทับลงไป

import networkx as nx

# build_graph(folder): อ่านโฟลเดอร์ atom แล้วสร้าง DiGraph
#   จากโหนด (=atom) และเอดจ์ความสัมพันธ์ใน YAML (ฉบับเต็มอยู่ใน「ลองทำดู」)

def find_cycles(G):                      # การพึ่งพาแบบวนรอบ
    return list(nx.simple_cycles(G))

def find_orphans(G):                     # inbound 0 = ผู้สมัครเป็นกำพร้า
    return [n for n in G.nodes if G.in_degree(n) == 0]

หัวใจอยู่ที่สองบรรทัด simple_cycles จับการพึ่งพาแบบวนรอบ (A requires B requires C requires A) และ in_degree(n) == 0 จับโหนดกำพร้า — ไม่จำเป็นต้องเขียน DFS เอง ฟังก์ชันอีกสองตัวที่เหลือก็เป็นแบบหนึ่งบรรทัดในระนาบเดียวกัน find_broken_wikilinks รวบรวม [[...]] ในเนื้อหาด้วย regular expression (regex) แล้วคัดเลือกตัวที่ไม่มีอยู่ในรายชื่อโหนด ส่วนการอ้างกลับนั้นได้มาจากการไล่กราฟย้อนทาง (ฉบับเต็มอยู่ใน「ลองทำดู」) การทำให้เป็นภาพจะลงสีโหนดตาม Layer ลงสีเอดจ์ตามประเภทความสัมพันธ์ และวาดโหนดที่ถูกอ้างถึงมาก (โหนดที่มีเอดจ์ inbound เยอะ) ให้ใหญ่ขึ้นเพื่อให้ฮับปรากฏชัด เปรียบเหมือนโฟลเดอร์ที่จัดเรียงโดยติดป้ายสีไว้บนตู้ แพตเทิร์นจะลอยขึ้นมาก่อนภายในขอบเขตสายตา

ด้านล่างคือกราฟที่ถ่ายทอดความสัมพันธ์จริงของ atom ทั้งหลายที่กล่าวถึงในเซสชัน 2.4.2 ทิศทางลูกศรหมายถึง "atom ต้นทางสร้างความสัมพันธ์มุ่งไปยัง atom ปลายทาง"

graph LR
    combo[combat_combo_cancel_v3
L1·approved]
    legacy[skill_cancel_rule_legacy_v1
L1·deprecated]
    v2[skill_cancel_rule_v2
L1]
    dps[skill_dps_calculation
L3]
    vision[vision_taste_focused_combat
L0]
    buffer[combat_input_buffer_system
L1]
    boss[refgame_boss_pattern_phase2
L2]
    qa[qa_combat_regression_checklist
L4]
    broken[skill_cancel_rule_legacy
ไม่มีอยู่จริง]

    combo -->|affects| dps
    combo -->|affects| boss
    combo -->|derives_from| vision
    combo -->|requires| buffer
    combo -->|conflicts_with| legacy
    v2 -->|derives_from| legacy
    qa -.stale.-> legacy
    balance[balance_curve_v3] -.broken.-> broken

    classDef dep fill:#eee,stroke:#999,stroke-dasharray:4
    classDef miss fill:#fff,stroke:#cc2222,stroke-dasharray:4
    class legacy dep
    class broken miss

สองเอดจ์ที่วาดด้วยเส้นประคือปัญหาที่จับได้ด้วยการตรวจสอบของมนุษย์ในหัวข้อ 2.4.2 qa → legacy คือ stale link ที่อ้างอิง atom ที่ถูกเลิกใช้ ส่วน balance_curve_v3 → skill_cancel_rule_legacy คือลิงก์ที่ขาดซึ่งชี้ไปยังโหนดที่ไม่มีอยู่จริง เมื่อวาดเป็นกราฟ เส้นประสองเส้นนี้จะโดดเด่นขึ้นมาท่ามกลางเส้นทึบ หากดำเนินการด้วยข้อความเพียงอย่างเดียว มันคงถูกฝังอยู่ที่ใดที่หนึ่งในไฟล์ 47 ไฟล์และมองไม่เห็นไปตลอดกาล

กฎที่รันโดยอัตโนมัติที่ verification gate (Layer 4) มีสี่อย่าง

• การพึ่งพาแบบวนรอบ: หากสายโซ่ requires วนกลับมายังตัวเอง ให้เตือน ตรวจจับด้วย simple_cycles
• การเปิดใช้ความขัดแย้ง: หาก atom สองตัวที่ผูกด้วย conflicts_with ทั้งคู่เป็น status: approved ให้เตือน (กรณีในหัวข้อ 2.4.2 ผ่านได้เพราะฝั่งหนึ่งเป็น deprecated)
• โหนดกำพร้า: atom ที่ inbound เป็น 0 และไม่มีพ่อแม่ด้วยจะเป็นผู้สมัครสำหรับการเลิกใช้ ตรวจตามรายไตรมาส atom ชื่อ graph_orphan_detection_quarterly ระบุรอบนี้ไว้
• การไหลย้อนของ Layer: L1 → L3 affects เป็นปกติ (การตัดสินใจระดับบนส่งผลต่อข้อมูลระดับล่าง) แต่ L3 → L1 affects น่าสงสัย เป็นหลักการเดียวกับการตรวจจับการอ้างถอยหลังในหัวข้อ 2.3 เพราะ atom ชื่อ docs_layer_numeric_prefix_naming บังคับให้ใส่ prefix หมายเลข Layer ในชื่อเอกสาร การไหลย้อนจึงถูกคัดกรองชั้นแรกได้แค่ดูชื่อไฟล์

เมื่อกฎสี่ข้อนี้ถูกตรึงไว้ในโค้ดแล้ว ก็ไม่จำเป็นต้องเขียนพรอมต์ทุกครั้งอย่างในหัวข้อ 2.4.2 ในวินาทีที่คำขอเปลี่ยนแปลงถูกส่งเข้ามา บอตจะ build กราฟใหม่ แล้วแสดงรายการ atom ที่ได้รับผลกระทบ พร้อมลิงก์ที่ขาด·การวนรอบ·ความขัดแย้งเป็นคอมเมนต์อัตโนมัติ คอมเมนต์ "atom 4 รายการได้รับผลกระทบ" ที่ต้นบทนี่เองคือสิ่งนี้ — บอตตัวนี้คือบอตที่ได้บอกล่วงหน้าไว้ก่อนหน้า

2.4.4 ทำไมจึงเป็น Layer — พิกัดที่แบ่งไว้เพื่อการสร้างแบบโพรซีเดอรัล

ตรงนี้ต้องชี้ให้ชัดว่าเหตุใด 2.3 และ 2.4 จึงเป็นชุดเดียวกัน พิกัด Layer และลูกศรความสัมพันธ์ไม่ได้นำมาใช้แยกกัน แต่เป็นสองด้านของจุดประสงค์เดียวกัน

ในเชิงผิวเผิน Layer ทำให้ภาษาในการทำงานร่วมกันเป็นหนึ่งเดียว — เมื่อเรียกว่า "อันนี้คือการตัดสินใจระบบ L1" "อันนั้นคือข้อมูล L3" ต่อให้สาขาต่างกันก็ใช้พิกัดเดียวกันร่วมกันได้ แต่จุดประสงค์ในเชิงแก่นแท้นั้นอยู่ที่อื่น Layer คือพิกัดที่แบ่งไว้เพื่อการสร้างแบบโพรซีเดอรัล (procedural generation)

วิสัยทัศน์ L0 คือ context anchor — ไม่เปลี่ยนแปลง และถูกฉีดเข้า AI ทุกครั้ง ระบบ L1 คือกฎอินพุตของการสร้าง — rulebook·ความสัมพันธ์·แท็กอาศัยอยู่ที่นี่ เนื้อหา L2 คือที่ที่เนื้อหาที่ถูกสร้างขึ้นสะสมตัว ข้อมูล L3 เป็นอินพุตของการจำลองด้วยตัวเลข·ID·ความสัมพันธ์ ส่วน build·QA ใน L4 คือ verification gate ลูกศรความสัมพันธ์ทำงานเป็น เงื่อนไขจำกัดของการสร้าง บนพิกัดนี้ เมื่อ AI สร้างเนื้อหาใหม่ ลูกศร requires กลายเป็นข้อสมมติฐานว่า "สิ่งนี้ต้องมีก่อน" และลูกศร conflicts_with กลายเป็นข้อห้ามว่า "สิ่งนี้เปิดร่วมกันไม่ได้"

สาขาแตกแขนงออกไป (ต่อสู้·เควสต์·เศรษฐกิจต่างมีความเชี่ยวชาญของตน) แต่เพราะผลผลิตทั้งหมดมีพิกัด Layer จึงรับรู้ซึ่งกันและกัน การแตกแขนงและการบูรณาการตั้งอยู่พร้อมกันบนระบบพิกัดเดียว เมื่อกราฟนี้เติบโตพอ AI จะอ่านลูกศรความสัมพันธ์เป็นข้อจำกัดอัตโนมัติขณะสร้างผู้สมัคร และมนุษย์เพียงตรวจสอบว่ามีการละเมิดหรือไม่ที่ด่านตรวจ บันทึกเซสชันจริงในหัวข้อ 2.4.2 คือฉบับย่อของสิ่งนั้น — AI อ่านกราฟเพื่อค้นหาการละเมิดข้อจำกัด (ลิงก์ที่ขาด·ความขัดแย้ง) และมนุษย์ตัดสินที่ด่าน

2.4.5 แนวคิดโดเมนก็เป็นโหนด — พจนานุกรมศัพท์เล็ก ๆ

โหนดที่เป็นจุดต้นทาง·จุดปลายทางของลูกศรความสัมพันธ์ไม่ได้มีแต่ atom การตัดสินใจเท่านั้น atom ที่นิยามแนวคิดโดเมนอย่าง "สกิล" "เควสต์" "รางวัล" ก็เป็นพลเมืองชั้นหนึ่งของกราฟ concept_skill_definition_v1 มีหน้าตาแบบนี้

# สกิล (Skill)
Definition: หน่วยแอ็กชันที่ตัวละครปลดปล่อยระหว่างการต่อสู้ ครอบคลุมอินพุต·คูลดาวน์·ทรัพยากร·เอฟเฟกต์
Required Properties: input / cooldown / cost / effects
Subtypes: active_skill (is_a) / passive_skill (is_a) / ultimate_skill (is_a)
Not a skill: การโจมตีอัตโนมัติ [[concept_auto_attack]] / การแปลงร่าง [[concept_transformation]]

หากเขียนว่า boss_skill is_a skill กฎของแนวคิดระดับบนจะถูกสืบทอดมาโดยอัตโนมัติ ในโปรเจกต์ A มี atom นิยามแนวคิดเช่นนี้ราว 19 ตัว และ atom การตัดสินใจทุกตัวอ้างถึงพวกมัน เมื่อศัพท์ถูกทำให้เป็นหนึ่งเดียวด้วยพจนานุกรมเล่มเดียว ภาระในการแปลระหว่างการประชุม·เอกสาร·โค้ดก็หายไป เปรียบเหมือนการที่ไม่ได้วางพจนานุกรมคนละเล่มไว้ตามโต๊ะแต่ละตัว แต่ใช้พจนานุกรมเล่มเดียวกันร่วมกัน concept_reward_currency ที่ถูกจับได้ว่าเป็นลิงก์ที่ขาดในบันทึกเซสชันจริงก่อนหน้านี้ ก็คือ "รายการว่างที่ตกลงกันว่าจะขึ้นทะเบียนในพจนานุกรมแต่ยังไม่ได้สร้าง" นั่นเอง

2.4.6 จงรักษาให้เบาไว้ — กับดักของออนโทโลยีเชิงวิชาการ

อ่านมาถึงตรงนี้ก็จะมีคำถามว่า "นี่มันออนโทโลยีอย่างเป็นทางการแบบ OWL/RDF ไม่ใช่หรือ" ไม่ใช่ และตั้งใจทำให้ไม่ใช่

ออนโทโลยีเชิงวิชาการ (OWL·RDF·SKOS) นั้นทรงพลัง แต่มีประเภทความสัมพันธ์หลายสิบถึงหลายร้อยแบบ ต้องใช้เอนจินอนุมานเฉพาะทาง และหากจะดำเนินการก็ต้องมีผู้เชี่ยวชาญด้านออนโทโลยีประจำอยู่ ในด้านที่การอนุมานแม่นยำตัดสินความเป็นความตายอย่างเสิร์ชเอนจิน·การแพทย์·กฎหมาย สิ่งนี้จำเป็น แต่การอนุมานที่จำเป็นจริงในการออกแบบเกมมีเพียง "ขอบเขตผลกระทบของการเปลี่ยนแปลง" "การพึ่งพาที่ต้องมาก่อน" "การตรวจจับความขัดแย้ง" เท่านั้น และทั้งหมดจบลงที่ระดับการค้นแบบเรียบง่าย (BFS·DFS) ที่ไล่ตามกราฟทีละช่อง หัวข้อก่อนหน้าที่จับการวนรอบได้ด้วย networkx บรรทัดเดียวคือหลักฐานของสิ่งนั้น เอนจินอนุมานอย่างเป็นทางการนั้นเกินจำเป็น

เกณฑ์มีเพียงข้อเดียว นักออกแบบเกมดำเนินการด้วยมือได้หรือไม่ YAML enum 6 ตัว, การประมวลผลด้วย networkx, การทำเป็นภาพด้วย pyvis หรือ D3.js วินาทีที่ก้าวข้ามเส้นนี้ เครื่องมือก็เลิกเป็นเครื่องมือและกลายเป็นภาระอีกอย่างหนึ่ง ความเบาไม่ใช่การประนีประนอม แต่เป็นเจตนาในการออกแบบ

ในการหลีกเลี่ยงกับดักนี้มีความผิดพลาดที่เกิดซ้ำอยู่ห้าอย่าง ทั้งหมดงอกออกมาจากรากเดียวกันคือ "ที่ที่จัดการออนโทโลยีในฐานะมาตรฐานบังคับ"

ข้อ 1·2·3 จะจับแพตเทิร์นได้ภายในเดือนแรกของการนำมาใช้ ส่วนข้อ 4·5 หากตรวจในการทบทวนเดือนที่สามก็จะเข้าที่เข้าทางไปเองโดยธรรมชาติ

2.4.7 การเริ่มต้นเล็ก ๆ และบทถัดไป

เดือนแรกขาดทุน มีแต่ภาระในการเขียนความสัมพันธ์สะสมขึ้น ส่วนผลที่มองเห็นนั้นไม่มี ดังนั้นจึงเริ่มต้นแบบเล็ก ๆ สัปดาห์แรกมีแค่สามความสัมพันธ์ affects·derives_from·requires สัปดาห์ที่ 2\~4 นำไปใช้กับ atom หลัก 20 ตัวพลางเฝ้าดูกราฟค่อย ๆ เติบโต หากในเดือนแรกสร้าง HTML graph view ระดับหัวข้อก่อนหน้าขึ้นมาสักหนึ่งอัน นับจากเดือนที่สองการทำเป็นภาพก็จะเริ่มแสดงคุณค่าให้เห็น และในเดือนที่สามการตรวจสอบอัตโนมัติ (การวนรอบ·ความขัดแย้ง·กำพร้า·ลิงก์ที่ขาด) จะลดเวลาการประชุมได้โดยตรง การทนเดือนแรกที่ขาดทุนให้ผ่านไปคือจุดแยกของความสำเร็จหรือล้มเหลวในการนำมาใช้

บทที่ 8 Wikilink บทถัดไปจะเจาะลึกการเขียนกำกับ [[...]] ที่บทนี้กล่าวถึงในรูปลูกศรไปสู่ระดับการดำเนินการ — ใช้แผงการอ้างกลับในแต่ละวันอย่างไร อัปเดตลิงก์ทั้งหมดพร้อมกันอย่างไรเมื่อเปลี่ยนชื่อ (วิธีป้องกันการตกหล่นในการ rename อย่างในหัวข้อ 2.4.2 ตั้งแต่ต้น) นำ graph view ของเครื่องมืออย่าง Obsidian มาหลอมรวมเข้ากับงานจริงอย่างไร YAML (บทที่ 4) → Atom (บทที่ 5) → Layer (บทที่ 6) → Ontology (บทที่ 7) → Wikilink (บทที่ 8) คือรูปห้าเหลี่ยมที่สมบูรณ์ของสถาปัตยกรรมสารสนเทศ

ลองทำดู

setup. กำหนดโฟลเดอร์ที่รวบรวม atom ไว้ (เช่น decisions/) แล้วเตรียมเขียนคีย์ความสัมพันธ์ลงใน YAML ของแต่ละ atom ตอนแรกมีแค่สามตัว affects·derives_from·requires ลิงก์ในเนื้อหาให้รวมเป็นรูปแบบ [[atom_name]] ให้เป็นแบบเดียวกัน

prompt. ก่อนเลิกใช้·เปลี่ยนชื่อ ให้โยนคำสั่งด้านล่างนี้

อ่าน atom แบบ markdown ในโฟลเดอร์นี้ ฉันจะเลิกใช้/เปลี่ยน [atom_เป้าหมาย]
ช่วยตรวจสอบ
(1) การอ้างกลับ: atom ทั้งหมดที่ชี้มายัง atom นี้ด้วยความสัมพันธ์ใน YAML และ wikilink ในเนื้อหา
(2) ลิงก์ที่ขาด: ลิงก์ที่จะขาดหรือกลายเป็น stale เมื่อเปลี่ยน/ลบ
(3) ความขัดแย้งที่หลงเหลือ: ในบรรดาคู่ conflicts_with ตัวที่เป็น status: approved
อย่าเดา ให้อ่านไฟล์จริง ๆ ถ้าหาไม่เจอก็บอกว่าหาไม่เจอ

verify. จุดที่ AI กำกับว่า "สงสัยว่าพิมพ์ผิด" "ไม่อาจมั่นใจได้" ให้มนุษย์เปิดดูเอง สาเหตุ ของลิงก์ที่ขาด (พิมพ์ผิด หรือตกหล่นในการ rename หรือยังไม่ได้เขียน) มนุษย์ตัดสินด้วย git log และตัวจริงในโฟลเดอร์ อย่าสั่งให้แก้อัตโนมัติ แต่ให้แก้เองหลังยืนยันเจตนาแล้ว

ฉบับเต็มของเครื่องมือกราฟ (ตัดตอนจาก 2.4.3)

ในเนื้อหา (2.4.3) ได้แสดงเพียงสองฟังก์ชันหลัก ฉบับเต็มที่ build ทั้งโฟลเดอร์เป็นกราฟและวางการตรวจสอบสี่อย่างมีดังนี้

import networkx as nx
import re, yaml, glob, os

REL_TYPES = ["affects", "derives_from", "requires",
             "conflicts_with", "is_a", "part_of"]
WIKILINK = re.compile(r"\[\[([a-zA-Z0-9_]+)\]\]")

def build_graph(folder):
    G = nx.DiGraph()
    files = {}
    for path in glob.glob(os.path.join(folder, "*.md")):
        name = os.path.splitext(os.path.basename(path))[0]
        text = open(path, encoding="utf-8").read()
        fm = yaml.safe_load(text.split("---")[1]) or {}
        files[name] = fm
        G.add_node(name, layer=fm.get("layer"), status=fm.get("status"))
    # เอดจ์ความสัมพันธ์ใน YAML
    for name, fm in files.items():
        for rel in REL_TYPES:
            for tgt in (fm.get(rel) or []):
                G.add_edge(name, tgt, type=rel)
    return G, files

def find_broken_wikilinks(folder, known_nodes):
    broken = []
    for path in glob.glob(os.path.join(folder, "*.md")):
        text = open(path, encoding="utf-8").read()
        for m in WIKILINK.findall(text):
            if m not in known_nodes:
                broken.append((os.path.basename(path), m))
    return broken

def find_orphans(G):
    # โหนดที่ inbound เป็น 0 และไม่มีพ่อแม่ part_of/is_a ด้วย
    return [n for n in G.nodes if G.in_degree(n) == 0]

def find_cycles(G):
    return list(nx.simple_cycles(G))

ฉบับย่อสำหรับคนเดียว

ไม่มีเครื่องมือก็ได้ โฟลเดอร์ atom หนึ่งโฟลเดอร์ Claude หนึ่งตัวก็เพียงพอ ตอนเขียนการตัดสินใจใหม่ ให้เพิ่มเพียงสองบรรทัด requires·affects ลงใน YAML และทุกครั้งที่เกิดการเลิกใช้·เปลี่ยนชื่อ ให้รัน prompt ข้างต้นสักหนึ่งครั้ง การทำกราฟเป็นภาพเป็นเรื่องของทีหลัง — นิสัยการไล่ดูลิงก์ที่ขาดและความขัดแย้งสักครั้งก่อนเปลี่ยนแปลง หนึ่งครั้งนั้นคือสิ่งที่ป้องกันการขาดทุนก้อนใหญ่ที่สุดในการดำเนินงานคนเดียว

สรุปประเด็นสำคัญของบท

• ต้องสวมลูกศรเชิงความหมายลงบนพิกัด "อะไรส่งผลต่ออะไร" จึงจะถูกอนุมานโดยอัตโนมัติ
• การตรวจจับการอ้างกลับ·ลิงก์ที่ขาดเป็นงานของ AI ส่วนการตัดสินสาเหตุและการยืนยันเจตนาเป็นงานของมนุษย์
• ความเบาไม่ใช่การประนีประนอมแต่เป็นเจตนาในการออกแบบ — หากดำเนินการด้วยมือไม่ได้ เครื่องมือก็กลายเป็นภาระ

ส่วนที่ 3 · System Design

3.1 งานของ System Designer และพิกัด Layer

วันพฤหัสบดี เวลา 16:50 น. ชีตสกิลที่ผู้รับผิดชอบด้านบาลานซ์กรอกเสร็จเพิ่งถูกอัปโหลดขึ้นมา สกิลทั้งหมด 312 รายการ แต่ละสกิลต้องกรอกหมายเลขเอฟเฟกต์ลงในช่องชื่อ effect_id และหมายเลขนั้นชี้ไปยังแถวที่อยู่ในชีตเอฟเฟกต์อีกชีตหนึ่ง ทั้งสองต้องตรงกันเกมจึงจะทำงานได้ ถ้าไม่ตรงกัน ไคลเอนต์จะเรียกเอฟเฟกต์ที่ว่างเปล่าหรือไม่ก็ตายเงียบ ๆ

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

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

3.1.1 System Designer สร้างสี่สิ่ง

System Designer คือคนที่เดินทางไปมาระหว่างระดับนามธรรมกับระดับรูปธรรมได้กว้างที่สุด เขารับเอาหมอกที่ชื่อว่าวิสัยทัศน์มา แล้วลากมันลงมาจนถึงตัวเลขแข็ง ๆ อย่างเซลล์สุดท้ายของชีตข้อมูล สิ่งที่ถูกสร้างขึ้นในการเดินทางนั้นมีสี่ประเภท

(1) แปลวิสัยทัศน์ให้เป็นโครงสร้าง เมื่อ Design Director พูดว่า "การต่อสู้แบบแอ็กชันที่มีสัมผัสการกระแทกมีชีวิตชีวา" System Designer จะเปลี่ยนคำพูดนั้นให้เป็นโครงร่างอย่างสกิล คอมโบ แคนเซิล และ hit-stop ส่วน "สิทธิ์ในการกำหนดการเติบโตด้วยตัวเอง" ก็จะกลายเป็นระบบคลาส สกิลทรี และอุปกรณ์ นี่คือช่วงเวลาแรกที่หมอกกลายเป็นสิ่งก่อสร้าง

(2) ระบุข้อกำหนดของอินเทอร์เฟซระหว่างระบบ การต่อสู้ การเคลื่อนที่ อินเวนทอรี ร้านค้า เควสต์ และกิลด์ ทำงานพร้อมกัน ถ้าเปิดอินเวนทอรีระหว่างต่อสู้จะได้รับสถานะอมตะหรือไม่? ถ้ามีคำขอ PvP เข้ามากลางคันขณะตีบวกอุปกรณ์ล่ะ? คำตอบของเคสเหล่านี้มารวมกันแล้วสร้างสัมผัสที่เรียกว่า "ทำมาดีจริง ๆ" ทุกตำแหน่งที่คำตอบขาดหายไป ผู้ใช้จะรู้สึกหงุดหงิด

(3) รับผิดชอบชีตข้อมูลและสคีมาของมัน ค่าสัมประสิทธิ์ของสกิล 312 รายการ เอฟเฟกต์ของไอเทมหลายร้อยชิ้น พฤติกรรมของมอนสเตอร์หลายสิบชนิด ค่าต่าง ๆ จะกรอกเองหรือส่งต่อให้สายงานบาลานซ์กับเนื้อหาก็ได้ แต่อย่างน้อย นิยามคอลัมน์ (schema) ของชีตนั้น System Designer ต้องถือไว้เอง มันคืองานสร้างลิ้นชักที่ติดป้ายกำกับไว้ให้ ถ้าลิ้นชักหลวมเลื่อน แต่ละคนก็จะกรอกต่างกันจนความสอดคล้องพังลง

(4) ออกแบบลอจิกของพฤติกรรม AI ของตัวละครและมอนสเตอร์ออกมาในรูปแบบอย่างสเตตแมชชีน (FSM, Finite State Machine, เครื่องสถานะจำกัด) ทรีพฤติกรรม (Behavior Tree, ต่อไปเรียกว่า BT) ตารางการตัดสินใจ และกฎแบบโพรซีเดอรัล เอกสารเหล่านี้จะถูกส่งต่อไปยังโปรแกรมเมอร์แล้วกลายเป็นโค้ด

ประเด็นสำคัญคือทั้งสี่สิ่งนี้มาบรรจบกันบนโต๊ะทำงานของคนคนเดียว ดังนั้น "วันนี้จะใช้เวลาไปกับอะไร" จึงกลายเป็นการตัดสินใจด้านการบริหารงานที่ใหญ่ที่สุดของ System Designer

3.1.2 ผลงานของระบบมีพิกัด Layer

ในหัวข้อ 2.3 เราได้วางผลงานการผลิตเกมทั้งหมดลงบนแกนพิกัดตั้งแต่ L0 (วิสัยทัศน์) ถึง L4 (บิลด์) ตอนนี้เราจะปักผลงานทั้งสี่อย่างของ 3.1.1 ลงบนแกนนั้นโดยตรง กรณีที่ผลงานของสายงานเดียวกระจายกว้างหลาย Layer อย่างงาน System Designer นั้นหาได้ยาก

ต่อไปนี้คือแผนที่ที่เขียนลงในภาพเดียวว่าผลงานอาศัยอยู่ตรงไหนบน Layer และพบกับใครในแต่ละพิกัด

แผนที่นี้บอกอยู่สองอย่าง อย่างแรก System Designer รับผิดชอบระยะทางยาวที่ รับ L0 มาแล้ว พา ให้ไปถึง L4 อย่างที่สอง ช่วงที่ลงมือสร้างเองคือ L1 ถึง L3 และคู่ทำงานในแต่ละช่องสามช่องนั้นเปลี่ยนไป ทุกครั้งที่เปลี่ยนช่อง ภาษาที่ใช้ทำงานร่วมกันก็เปลี่ยน ดังนั้นหากไม่รู้ตัวว่าตอนนี้อยู่พิกัดไหน การประชุมก็จะวนเปล่าอยู่บ่อย ๆ

แต่ทั้งนี้ไม่ได้หมายความว่าคนคนเดียวจะแตะ L1 ถึง L3 ทั้งหมด ถ้าทีมใหญ่ ผู้รับผิดชอบ L1 ถึง L2 กับผู้รับผิดชอบ L3 จะแยกกัน ถ้าทีมเล็ก คนคนเดียวก็ดูทั้งหมด พิกัดคือแผนที่แบ่งบทบาท ไม่ใช่คำสั่งให้โยนทุกอย่างไปให้คนคนเดียว

3.1.3 เมื่อพิกัดถูกกำหนด ตำแหน่งที่จะเสียบ AI ก็จะปรากฏ

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

flowchart TD
    L1["L1 โครงร่างระบบ
(จำนวนคลาส, โมเดลการต่อสู้)"]
    L2["L2 อินเทอร์เฟซ
(กฎการโต้ตอบ)"]
    L3["L3 สคีมา + ข้อมูล
(ชีต 312 แถว)"]

    L1 -->|"เชื่อมตรงกับเอกลักษณ์เกม
คนเป็นผู้ตัดสิน"| H1["AI = ช่วยแปรรูป/ตรวจสอบการตัดสินใจของคน"]
    L2 -->|"เคสระเบิด
ขอบเขตผลกระทบกว้าง"| H2["AI = ดึงขอบเขตผลกระทบของการเปลี่ยนแปลงอัตโนมัติ"]
    L3 -->|"เป็นรูปแบบตายตัว·ซ้ำ ๆ
ตรวจความสอดคล้อง"| H3["AI = รับผิดชอบทั้งการสร้าง·ตรวจสอบ·แปลง"]

    H1 --> R["คนรับผิดชอบการตัดสินใจหลัก,
AI รับผิดชอบรายละเอียด·ความสอดคล้อง·งานซ้ำ"]
    H2 --> R
    H3 --> R

    style L3 fill:#fff8e1,stroke:#f9a825
    style H3 fill:#e8f5e9,stroke:#2e7d32
    style R fill:#e3f2fd,stroke:#1565c0

ประเด็นสำคัญคือ ยิ่งพิกัดเลื่อนลงล่างมากเท่าไร สัดส่วนที่ AI รับผิดชอบทั้งหมดก็ยิ่งมากขึ้น "จะตั้งคลาสไว้กี่คลาส" ของ L1 เป็นเรื่องเอกลักษณ์เกม คนจึงต้องถือไว้ ในทางกลับกัน "foreign key (FK) ทั้ง 312 แถวตรงกันหมดไหม" ของ L3 เป็นรูปแบบตายตัวและซ้ำ ๆ AI จึงควรรับไปทั้งก้อน ส่วน L2 อยู่ตรงกลาง — การตัดสินใจเป็นของคน แต่ AI ช่วยหนุนด้วยการดึงขอบเขตผลกระทบว่า "ถ้าเปลี่ยนกฎนี้แล้วจะกระเทือนไปถึงไหน"

ภาพนี้อธิบายว่าทำไมการฝึกปฏิบัติทั้งหมดตั้งแต่ 3.1.4 เป็นต้นไปจึงเริ่มจากบริเวณ L3 เพราะเป็นตำแหน่งที่ได้ผลมากที่สุดและเสี่ยงน้อยที่สุด ต่อให้เครื่องมือสคีมาทำงานผิดพลาดก็ไม่เกิดอุบัติเหตุ แผนผังความสัมพันธ์ก็แค่วาดรูปเท่านั้น และการตรวจสอบความสอดคล้องก็เป็นสิ่งที่คนปฏิเสธได้

3.1.4 บันทึกเซสชันจริง (worked transcript): มอบหมายให้ AI ตรวจสอบความสอดคล้องที่พิกัด L3

ทฤษฎีมีแค่นี้ ตอนนี้เรากลับไปยังวันพฤหัสบดีที่ต้นบท 3.1 กัน เราจะลองสั่งให้ AI ตรวจว่า effect_id ของสกิลทั้ง 312 รายการในชีตสกิลตรงกับชีตเอฟเฟกต์หรือไม่ ผมจะคัดลอกบทสนทนาตามที่โต้ตอบกันจริงโดยไม่สรุปย่อ

การป้อนข้อมูลเป็นไปตามหลัก schema-first กล่าวคือคนเป็นผู้นิยาม ชีตข้อมูลจำเพาะ (specification sheet) ก่อน จากนั้น Enum และ .proto จึงออกมา (VBA (ภาษามาโครของ Excel) Export) แล้วสุดท้ายข้อมูล csv จึงถูกกรอกเข้าไป ดังนั้นพรอมต์ตรวจสอบจึงเริ่มด้วย "อ่านสคีมาก่อน" และตอกย้ำว่าฉบับจริงไม่ใช่เอกสารสคีมา แต่เป็น JSON ที่ export ออกมาจริง (json_over_schema_doc_as_source_of_truth) เพราะเอกสารโกหกได้ แต่ JSON ที่ export ออกมาโกหกไม่ได้

พรอมต์ (ฉบับเต็ม)

คุณคือตัวตรวจสอบความสอดคล้องของข้อมูลในโปรเจกต์ของเรา อินพุตคือ export JSON สองไฟล์ 1) skill.json — แต่ละอ็อบเจกต์สกิลมีฟิลด์ skill_id, name, effect_id 2) effect.json — แต่ละอ็อบเจกต์เอฟเฟกต์มีฟิลด์ effect_id, effect_type

จงตรวจสอบสิ่งต่อไปนี้ (A) effect_id ทุกตัวใน skill.json มีอยู่ใน effect.json หรือไม่ (ความสอดคล้องของ foreign key) (B) เอฟเฟกต์กำพร้า (orphan) ที่อยู่ใน effect.json แต่ไม่มีสกิลใดอ้างถึง (C) แถวที่ effect_id ว่างเปล่าหรือเป็น 0 ใน skill.json

กฎ: ห้ามเดา ฟิลด์ที่ไม่มีใน JSON ให้รายงานว่า "ไม่มีฟิลด์" เอาต์พุตให้แบ่งเป็นสามส่วนคือ (A)(B)(C) และแต่ละกรณีที่ละเมิดให้ระบุ skill_id (หรือ effect_id) กับเหตุผลในบรรทัดเดียว ถ้าไม่มีการละเมิด ให้เขียนในส่วนนั้นแค่ "ไม่มีการละเมิด"

ผลลัพธ์ดิบของ Claude (ไม่ผ่านการตกแต่ง·เสริมแต่ง)

ยังไม่ได้รับ input JSON สองไฟล์ ในข้อความปัจจุบันไม่มีเนื้อหาไฟล์แนบมาด้วย กรุณาส่งมาใหม่ด้วยวิธีใดวิธีหนึ่งต่อไปนี้ - เนื้อหาจริงของ skill.json และ effect.json (วางข้อความหรือแนบไฟล์) - หรือพาธของไฟล์ทั้งสอง

เมื่อได้รับเนื้อหาแล้ว ผมจะตรวจสอบตามลำดับ (A)(B)(C) ผมจะไม่กุผลลัพธ์ขึ้นมาเองโดยไม่มีไฟล์

การที่มันหยุดตรงนี้กลับเป็นสัญญาณของความน่าเชื่อถือ ถ้าอินพุตว่างเปล่าแต่กลับมีรายงานดูดีตอบกลับมา ความเรียบร้อยนั้นแหละคือสัญญาณอันตราย ฝ่ายที่ไม่สร้างผลการตรวจสอบขึ้นมาจากมือเปล่าแต่ย้อนถามว่า "ขอไฟล์ก่อน" ต่างหากที่น่าเชื่อถือ ผมจึงวาง JSON ทั้งสองไฟล์เข้าไปจริง ๆ แล้วร้องขอใหม่ (ในเนื้อหาหลักคัดมาแสดงเพียงบางส่วนเนื่องด้วยความยาว)

// skill.json (คัดมาบางส่วน)
[
  {"skill_id": 1001, "name": "강타",     "effect_id": 5001},
  {"skill_id": 1002, "name": "회전베기", "effect_id": 5002},
  {"skill_id": 1003, "name": "방패올리기","effect_id": 0},
  {"skill_id": 1004, "name": "독바르기", "effect_id": 5099}
]

// effect.json (คัดมาบางส่วน)
[
  {"effect_id": 5001, "effect_type": "DAMAGE"},
  {"effect_id": 5002, "effect_type": "DAMAGE"},
  {"effect_id": 5003, "effect_type": "BUFF"}
]

ผลลัพธ์ครั้งที่สองของ Claude (อิงข้อมูลจริง)

(A) ความสอดคล้องของ foreign key — ละเมิด 1 รายการ - skill_id: 1004 → effect_id: 5099 ไม่มีอยู่ใน effect.json (dangling reference)

(B) เอฟเฟกต์กำพร้า — ละเมิด 1 รายการ - effect_id: 5003 (BUFF) → ไม่มีสกิลใดอ้างถึง

(C) effect_id ว่าง/0 — ละเมิด 1 รายการ - skill_id: 1003 → effect_id: 0 อาจเป็น "ไม่มีเอฟเฟกต์" ที่ตั้งใจไว้ก็ได้ จึงควรตรวจกับสคีมาว่า 0 เป็นค่าที่ใช้ได้หรือไม่

การตรวจสอบและการปฏิเสธโดยคน

สองในสามรายการเป็นบั๊กชัดเจน 5099 เกิดจากการที่ผู้รับผิดชอบบาลานซ์เขียนไว้ในสกิลก่อนที่จะเพิ่มแถวลงในชีตเอฟเฟกต์ — เป็นเคสคลาสสิกของลำดับงานที่สลับกัน จับได้

แต่ (C) ผมกลับ ปฏิเสธ ในโปรเจกต์ของเรา effect_id: 0 เป็นค่าที่ตกลงกันไว้และใช้ได้ ซึ่งหมายถึง "ช่อง passive, ไม่มีเอฟเฟกต์" AI ไม่รู้เรื่องนั้นจึงรายงานว่า "ควรตรวจสอบ" การตัดสินนั้นถูกต้อง แต่ไม่ใช่เรื่องที่ควรนับเป็นการละเมิด ผมจึงเดินหน้าต่อไป — นั่นคือการตรึงข้อตกลงนี้ไว้เป็น atom เพื่อให้ตั้งแต่การตรวจครั้งหน้าเป็นต้นไป AI รู้ว่า 0 เป็นค่าที่ใช้ได้

ร้องขอใหม่ (ฉีดความรู้เชิงโดเมนเข้าไป)

กฎเพิ่มเติม: effect_id == 0 หมายถึง "passive, ไม่มีเอฟเฟกต์" ซึ่งเป็นค่าที่ตกลงกันไว้และใช้ได้ในโปรเจกต์ของเรา ดังนั้นใน (C) effect_id == 0 ไม่ถือเป็นการละเมิด ให้รายงานเฉพาะสตริงว่าง·null·จำนวนลบเป็นการละเมิดของ (C) เท่านั้น

(C) effect_id ว่าง/0 — ไม่มีการละเมิด (effect_id: 0 ถือเป็นค่าที่ตกลงกันไว้และใช้ได้ ไม่มีค่าว่าง/null/จำนวนลบ)

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

ในบันทึกเซสชันนี้ สิ่งที่คนทำมี เพียงสามอย่าง เท่านั้น — (1) กำหนดลำดับอินพุตว่าให้อ่านจากสคีมาก่อน (2) ยืนยันว่า 5099 เป็นบั๊กจริง (3) รู้ว่า 0 เป็นค่าที่ใช้ได้แล้วปฏิเสธ·แก้ไขการตัดสินของ AI สองชั่วโมงที่เคยนั่งดูทีละช่องโดยกระโดดไปมาตลอด 312 แถวที่เหลือนั้นหายไป สิ่งที่ถูกทำเป็นอัตโนมัติคือแรงงานอย่างการกระโดดและการเทียบ ส่วนการตัดสินสามบรรทัดที่เหลือต่างหากคือแก่นแท้

3.1.5 สินทรัพย์ที่สะสมขึ้น: ตรึงพิกัดให้แข็งเป็นโค้ด

การตรวจในบันทึกเซสชันข้างต้นจะสั่งด้วยมือทุกครั้งก็ได้ แต่งานที่ซ้ำ ๆ ที่ L3 การตรึงให้แข็งเป็นเครื่องมือคือหลักปฏิบัติของงานออกแบบระบบ ผมขอยกตัวอย่างสองอย่างที่ผู้เขียนใช้งานอยู่ — ไม่ใช่ "เครื่องมือของโปรเจกต์ A" ที่เป็นนามธรรม แต่เป็นของที่หมุนอยู่บนโต๊ะทำงานจริง ๆ

gen_relation_map.py วิเคราะห์ชื่อคอลัมน์·ค่าของชีตเพื่อตรวจจับความสัมพันธ์ของ foreign key โดยอัตโนมัติ แล้วดึงออกมาเป็นแผนผังความสัมพันธ์ HTML แบบอินเทอร์แอ็กทีฟ ถ้าใน 3.1.4 คนเป็นผู้วาดลูกศร skill.effect_id → effect.effect_id ไว้ในหัว สคริปต์นี้ก็จะวาดลูกศรนั้นออกมาเป็นภาพสำหรับชีตทั้งหมด ตำแหน่งที่การพึ่งพิงไหลย้อนทาง (ความเสี่ยงที่ข้อมูล L3 ไปอ้างถึงโครงร่าง L1 แบบย้อนกลับ) จะกระโดดเด่นออกมาจากภาพในทันที

สกิล schema-doc ทำการพาร์ส ชีต $สคีมา ของ xlsm แล้วสร้างเอกสารสคีมาแบบ Markdown โดยอัตโนมัติ สคีมาที่ว่านี่เองคือสคีมาที่คำถามใน 3.1.4 (C) ที่ว่า "ควรตรวจกับสคีมาว่า 0 เป็นค่าที่ใช้ได้หรือไม่" โผล่ขึ้นมา — มันทำให้คนอ่านสคีมาล่าสุดได้ทันทีโดยไม่ต้องไปรื้อค้นไฟล์อื่น เมื่อชีตเปลี่ยน เอกสารก็เปลี่ยนตาม โรคเรื้อรังที่เอกสารกับข้อมูลจริงไม่ตรงกันจึงลดลง

หากพูดถึงตำแหน่งของเครื่องมือทั้งสองด้วยภาษาพิกัดอีกครั้งก็เป็นเช่นนี้ schema-doc ปกป้อง นิยามคอลัมน์ ของ L3 ส่วน gen_relation_map.py ปกป้อง ความสัมพันธ์ ระหว่าง L2 ถึง L3 ส่วนพรอมต์ผู้ช่วย AI (การตรวจสอบอย่างใน 3.1.4) หมุนอยู่ข้างบนทั้งสองอย่างนั้น ทั้งสามไม่ได้ต่างคนต่างเล่น แต่ต่างก็รับผิดชอบระดับความสูงที่ต่างกันบนแกนพิกัดเดียวกัน

วิธีใช้งานจริงของเครื่องมือเหล่านี้จะลองทำด้วยมือใน 3.2·3.3·3.4 หัวข้อ 3.1 คือแผนที่ที่กำหนดว่าจะเสียบเข้าตรงไหน และสามบทถัดไปคืองานเสียบ

3.1.6 การนำเข้ามาทีละขั้น: เริ่มจากพิกัดที่เสี่ยงน้อย

ถ้าเปิดเครื่องมือทั้งสามพร้อมกันในคราวเดียว ภาระการบริหารงานจะมาถึงก่อนผลลัพธ์ จากประสบการณ์ของผู้เขียน ลำดับที่ปลอดภัยคือเริ่มจากพิกัดที่เสี่ยงน้อย (ด้านล่าง) ก่อน

ระยะเวลาไม่ใช่เกณฑ์ตายตัว ขึ้นอยู่กับขนาดทีม·โครงสร้างพื้นฐานเดิม อาจใช้เวลาเป็นสองเท่า หรือจบในครึ่งเดียวก็ได้ (การประมาณของผู้เขียน ยังไม่ได้ตรวจสอบ) สิ่งที่ไม่เปลี่ยนคือ ลำดับ เมื่อวางตัวช่วยตัดสินใจที่เสี่ยงสูงไว้ท้ายสุด ทีมจะได้สร้างนิสัยการตรวจสอบจากเครื่องมือสองอย่างแรกไปแล้วก่อนที่จะไปแตะตำแหน่งที่อ่อนไหวที่สุด

3.1.7 การวัดผล — อย่างซื่อตรง

ผมจะบันทึกตัวเลขโดยไม่ตกแต่งให้ดูดี ต่อไปนี้คือสิ่งที่สังเกตได้จากทีมออกแบบ (กำลังคน 4\~5 คน ทั้งทีมพัฒนาขนาดกลาง 10\~50 คน เปิดให้บริการราว 6 เดือน) ของโปรเจกต์ MMORPG ที่ผู้เขียนบริหารในฐานะ Director (ต่อไปเรียกว่า "โปรเจกต์ A") ไม่ใช่การวัดอัตโนมัติที่แม่นยำ แต่เป็น การสังเกตของผู้เขียน ที่อิงบันทึกการทำงานและบันทึกการทบทวน ขอแนะนำให้อ่านเป็นเพียงทิศทางและอัตราส่วนคร่าว ๆ เท่านั้น

• การตรวจสอบความสอดคล้อง: การเทียบ foreign key ระหว่างสกิลกับเอฟเฟกต์ 312 แถวด้วยมือ เร็วที่สุดก็สองชั่วโมง (วันพฤหัสบดีที่ต้นบทนั้นแหละ) ส่วนการตรวจสอบด้วย AI นั้น ถ้าหักเวลาเตรียมอินพุตออก รายการที่ละเมิดก็ออกมาภายในไม่กี่นาที สิ่งที่ลดลงคือแรงงานในการกระโดด·เทียบ ไม่ใช่การตัดสิน
• การออนบอร์ดนักออกแบบหน้าใหม่: เมื่อมีแผนผังความสัมพันธ์ HTML หนึ่งภาพ ก็ช่วยลดการประชุมที่ต้องอธิบายโครงสร้างการพึ่งพิงระหว่างระบบด้วยปากเปล่าลงได้หลายครั้ง จำนวนครั้งที่แน่ชัดต่างกันไปในแต่ละคน ผมจึงไม่ฟันธง (การสังเกตของผู้เขียน)
• การถกผลกระทบของการเปลี่ยนแปลง: จากเดิมที่ต้องคลำหาในการประชุมว่า "ถ้าเปลี่ยนกฎนี้แล้วจะกระเทือนตรงไหน" ผมเปลี่ยนเป็นให้ AI ร่างขอบเขตผลกระทบมาก่อนแล้วคนค่อยตรวจสอบ การประชุมไม่ได้หายไป แต่การประชุมกลายเป็น การตรวจสอบ แทน

ประเด็นสำคัญคือเวลาที่ประหยัดได้ไม่ใช่เวลาที่ไม่ได้สร้างเกม เวลานั้นจะหมุนกลับไปสู่การตัดสินใจที่ลึกซึ้งซึ่งมอบให้ AI ไม่ได้ อย่างเช่นโครงร่าง L1 ลดแรงงานลงเพื่อนำไปใช้กับการตัดสิน — นั่นคือหนึ่งบรรทัดที่บทนี้แนะนำ

ลองทำดู: ตรวจสอบความสอดคล้องที่พิกัด L3 หนึ่งครั้ง

setup. export ชีตสองชีต (เช่น สกิล, เอฟเฟกต์) เป็น csv ถ้าทำได้ก็แปลงเก็บไว้เป็น JSON (หลักการที่ว่าผลลัพธ์ที่ export ออกมาคือฉบับจริง ไม่ใช่เอกสาร) เลือก foreign key หนึ่งคู่ระหว่างสองชีต (เช่น skill.effect_id → effect.effect_id)

prompt. ใช้พรอมต์ฉบับเต็มของ 3.1.4 ตามนั้นเลย อย่าลืมสามบรรทัดสำคัญ — (1) "อ่านสคีมา/โครงสร้างก่อน" (2) "อย่าเดา สิ่งที่ไม่มีให้รายงานว่าไม่มี" (3) "ถ้าไม่มีการละเมิด ให้เขียนแค่ว่าไม่มีการละเมิด"

verify. คนตรวจรายการที่ละเมิดซึ่ง AI ส่งขึ้นมาทีละบรรทัด บั๊กจริงก็แก้ ส่วนผลตรวจผิดพลาด (false positive) ที่เกิดจากค่าที่ตกลงกันไว้ในโดเมน (เช่น 0 = ไม่มีเอฟเฟกต์) ก็ ปฏิเสธ แล้วเพิ่มข้อตกลงนั้นเข้าไปในพรอมต์ (หรือ atom) เมื่อผลตรวจผิดพลาดแบบเดียวกันหายไปจากการตรวจครั้งถัดไป ก็แสดงว่าสินทรัพย์ถูกวางสะสมไปแล้วหนึ่งใบ

ฉบับย่อสำหรับคนเดียว

ถ้าเป็นนักพัฒนาคนเดียวที่ไม่มีทั้งทีมและชีต แค่แท็บสองแท็บใน Google Sheets ก็พอ แท็บหนึ่งเป็น "สกิล" อีกแท็บเป็น "เอฟเฟกต์" เชื่อมทั้งสองด้วยคอลัมน์ effect_id เพียงคอลัมน์เดียว ดาวน์โหลดแท็บเป็น csv แล้ววางลงในพรอมต์ของ 3.1.4 ต่อให้เป็นชีต 30 แถวแทนที่จะเป็น 312 แถว ก็จับ dangling reference และเอฟเฟกต์กำพร้าได้เหมือนกัน ต่างกันแค่ขนาด แต่พิกัดเหมือนกัน เริ่มจาก L3 แล้วเมื่อมือเริ่มชิน ก็ค่อยไต่ขึ้นไปทีละช่องสู่แผนผังความสัมพันธ์และขอบเขตผลกระทบ

สรุปประเด็นสำคัญของบท

• ผลงานของระบบทั้งสี่อย่างมีพิกัดตั้งแต่โครงร่าง L1 ถึงชีต L3 และพิกัดก็คือคู่ทำงานในการร่วมงาน
• ยิ่งพิกัดเลื่อนลง (L3) สัดส่วนที่ AI รับผิดชอบทั้งหมดก็ยิ่งมากขึ้นและความเสี่ยงก็ยิ่งน้อยลง
• สิ่งที่ถูกทำเป็นอัตโนมัติคือแรงงานในการกระโดด·เทียบ ส่วนการตัดสินอย่างการยืนยันบั๊กและการปฏิเสธผลตรวจผิดพลาดเป็นหน้าที่ของคน

3.2 สคีมามาก่อน — $สคีมาต้องมาก่อนข้อมูล

เช้าวันจันทร์ ผู้เขียนได้บิลด์ชีตสกิลที่นักออกแบบเกมคนใหม่กรอกไว้ 120 แถวให้เป็น csv แล้วในล็อกฝั่งไคลเอนต์ก็ขึ้นบรรทัดสีแดงมา 28 บรรทัด class_id อ้างอิงไปที่หมายเลข 47 แต่ในชีตคลาสกลับไม่มีหมายเลข 47 ในช่อง element มีคนหนึ่งเขียนว่า Fire อีกคนเขียนว่า fire และมีอยู่แถวหนึ่งเขียนว่า 화염 เป็นภาษาเกาหลี การไล่บรรทัดสีแดงทั้ง 28 บรรทัดทีละบรรทัดด้วยมือ ทำให้ครึ่งหนึ่งของช่วงบ่ายหายไป

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

บันทึกศัพท์ - สคีมา (schema): การนิยามคอลัมน์ของชีตข้อมูล ทั้งชื่อ·ชนิด·ช่วงค่า·foreign key·คำอธิบาย - $สคีมา: ชีตเฉพาะสำหรับนิยามคอลัมน์ที่วางไว้ในชีตข้อมูล Excel (xlsm) ไม่บรรจุแถวข้อมูล แต่บรรจุเฉพาะกฎของคอลัมน์ - FK (foreign key): คอลัมน์ที่อ้างอิงไปยัง PK (primary key) ของอีกชีตหนึ่ง เช่น class_id ชี้ไปยังแถวของชีต Class - proto: นิยาม Protocol Buffers (.proto) สัญญาว่าด้วยโครงสร้างข้อมูล·Enum ที่ไคลเอนต์และเซิร์ฟเวอร์ใช้ร่วมกัน - แหล่งความจริงเดียว (single source of truth): หลักการบริหารที่จัดการข้อมูลเดียวกันไว้ที่เดียว เพื่อให้ทุกฝ่ายดูที่แหล่งนั้น

3.2.1 ลำดับการป้อนข้อมูลก็คือสคีมา

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

ลำดับการป้อนข้อมูลที่หนังสือเล่มนี้แนะนำ คือไปป์ไลน์สี่ช่อง

flowchart LR
    A["ชีต $สคีมา
(นิยามกฎของคอลัมน์)"] --> B["Enum / *.proto
(สร้างสัญญาโค้ดด้วย VBA Export)"]
    B --> C["ข้อมูล csv
(กรอกแถวภายใต้กฎ)"]
    A -.->|schema-doc| D["เอกสารสคีมา
(.md สร้างอัตโนมัติ)"]
    C -.->|gen_relation_map.py| E["แผนผังความสัมพันธ์ FK
(HTML สร้างอัตโนมัติ)"]
    D -.-> F(("AI / คน
อ่านนิยามเดียวกัน"))
    E -.-> F
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    class A,B,C,D,E data

เส้นทึบที่ไหลจากซ้ายไปขวาคือ ลำดับการป้อนที่ถูกบังคับ นิยาม $สคีมา ก่อน จากนั้นดึง Enum และ proto ออกมาด้วย VBA (ภาษามาโครของ Excel) Export แล้วจึงกรอกข้อมูล csv ภายในขอบเขตของสัญญานั้นเท่านั้น เส้นประคือสิ่งที่ถูกสร้างขึ้นโดยอัตโนมัติจากการป้อนนั้น—เอกสารสคีมา (schema-doc) และแผนผังความสัมพันธ์ FK (gen_relation_map.py)—ซึ่งคนและ AI มองเห็นนิยามเดียวกันผ่านอนุพันธ์เหล่านี้

ตราบใดที่ลำดับนี้ถูกบังคับ บรรทัดสีแดง 28 บรรทัดที่เห็นในช่วงเปิดบทนี้ส่วนใหญ่จะถูกปิดลง ก่อนจะกรอกข้อมูล ถ้าข้อเท็จจริงที่ว่า element ต้องเป็นหนึ่งในสี่ค่า fire/ice/lightning/none ถูกตรึงไว้เป็น Enum ของ proto ทั้ง Fire และ 화염 ก็จะถูกดักไว้ตั้งแต่ขั้นตอนป้อนข้อมูล ถ้าข้อเท็จจริงที่ว่า class_id อ้างอิงไปยัง PK ของชีต Class ถูกระบุไว้ใน $สคีมา การขาดหายของหมายเลข 47 ก็จะถูกจับได้ที่ขั้นตรวจสอบก่อน ไม่ใช่ที่บิลด์

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

3.2.2 บันทึกเซสชันจริง (worked transcript) — จาก $สคีมา ถึง csv ในครั้งเดียว

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

ขั้นที่ 1 — คนเขียน $สคีมา ด้วยมือก่อน

ยังไม่เรียกทั้งเครื่องมือและ AI คนนิยามกฎของคอลัมน์ด้วยตัวเอง เฉพาะขั้นตอนนี้จะไม่มอบหมายให้ใคร

# ชีต Skill $สคีมา (เขียนโดยคน)
คอลัมน์          ชนิด       ช่วงค่า/ข้อจำกัด        FK                  คำอธิบาย
skill_id       int        1000~9999            (PK)                ID เฉพาะของสกิล
name           string     1~30 ตัวอักษร          -                  ชื่อที่แสดง
class_id       int(FK)    -                    Class.class_id      คลาสที่ใช้ได้
cooldown       float      0.0~120.0            -                   เวลารอใช้ซ้ำ (วินาที)
damage_coef    float      0.0~10.0             -                   สัมประสิทธิ์คูณพลังโจมตี
element        enum       fire/ice/lightning/none  -              ธาตุ
is_passive     bool       true/false           -                  เป็นพาสซีฟหรือไม่

ขั้นที่ 2 — สั่งให้ AI ร่าง proto Enum (พรอมต์ฉบับเต็ม)

งานคือนำ enum element และโครงสร้าง FK ของ $สคีมา ไปแปลงเป็นสัญญา proto เป็นการแปลงรูปแบบ จึงเป็นงานที่มอบหมายให้ AI ได้

พรอมต์ (ฉบับเต็ม): ด้านล่างคือข้อกำหนดคอลัมน์ของชีตข้อมูลเกม จงแปลงข้อกำหนดนี้เป็นข้อความ (message) และ Enum ของ Protocol Buffers (proto3) กฎ: (1) คอลัมน์ชนิด enum ให้นิยามเป็น enum แยกต่างหาก และค่าแรกต้องเริ่มด้วย _UNSPECIFIED = 0 เสมอ (2) คอลัมน์ FK ให้คงเป้าหมายอ้างอิงไว้เป็นคอมเมนต์ (3) ข้อจำกัดช่วงค่าไม่สามารถแสดงด้วย proto ได้ จึงให้คงไว้เป็นคอมเมนต์เท่านั้น อย่าเพิ่มคอลัมน์ที่ไม่มีในข้อกำหนด

skill_id int PK / name string / class_id int FK→Class.class_id /
cooldown float 0~120 / damage_coef float 0~10 /
element enum{fire,ice,lightning,none} / is_passive bool

ขั้นที่ 3 — ผลลัพธ์ดิบของ Claude (ตามเดิม ไม่แตะต้อง)

syntax = "proto3";

// สัญญาข้อมูลของชีต Skill
// หมายเหตุ: ข้อจำกัดช่วงค่า (cooldown 0~120, damage_coef 0~10)
//          ไม่สามารถบังคับด้วย proto ได้ ให้ตรวจสอบใน Linter
enum SkillElement {
  SKILL_ELEMENT_UNSPECIFIED = 0;
  SKILL_ELEMENT_FIRE = 1;
  SKILL_ELEMENT_ICE = 2;
  SKILL_ELEMENT_LIGHTNING = 3;
  SKILL_ELEMENT_NONE = 4;   // ← เครื่องหมายสำหรับให้คนตรวจสอบ
}

message Skill {
  int32 skill_id = 1;       // PK
  string name = 2;
  int32 class_id = 3;       // FK → Class.class_id
  float cooldown = 4;
  float damage_coef = 5;
  SkillElement element = 6;
  bool is_passive = 7;
}

ขั้นที่ 4 — การตรวจสอบและการปฏิเสธของคน

ตรงนี้คนจะปฏิเสธอยู่จุดหนึ่ง AI วาง none ไว้เป็น SKILL_ELEMENT_NONE = 4 ที่ตำแหน่ง ท้ายสุด ของ enum แต่ใน $สคีมา นั้น none คือสถานะตั้งต้นที่หมายความว่า "ไม่มีธาตุ" ประเด็นอยู่ที่ค่าหมายเลข 0 ของ proto ใน proto3 ค่าหมายเลข 0 ของ enum คือ "ตำแหน่งที่ถูกใส่เข้ามาอัตโนมัติเมื่อค่ายังไม่ถูกกรอก" จึงต้องเลือกว่าจะเว้นหมายเลข 0 ไว้เป็น _UNSPECIFIED (ไม่ได้ป้อนค่า) หรือจะเติมด้วยค่าที่มีความหมายอย่าง none (ไม่มีธาตุโดยตั้งใจ) ถ้ารวมทั้งสองไว้ที่ตำแหน่งเดียว แถวที่เว้นช่องว่างไว้ (ความผิดพลาด) กับ แถวที่เลือกไม่มีธาตุโดยจงใจ (ความตั้งใจ) จะเข้ามาเป็น 0 เหมือนกัน และแยกกันไม่ออกตลอดไป AI แยก _UNSPECIFIED = 0 กับ none ออกจากกันก็จริง แต่ดัน none ไปอยู่ตำแหน่งหมายเลข 4 ท้ายสุด ทำให้สถานะตั้งต้นที่พบบ่อยที่สุดถูกผลักออกห่างจากการค้นหาและการดีบัก

การตัดสินใจที่คนลงไป: - คง _UNSPECIFIED = 0 ไว้ (สำหรับตรวจจับการขาดหาย) - คง none ไว้ตามเดิม แต่เพิ่มในกฎการเขียน csv ว่า "ไม่มีธาตุต้องระบุ none เสมอ ห้ามเว้นว่าง" ช่องว่าง=0=UNSPECIFIED ให้ถือเป็นความผิดพลาดในการป้อนข้อมูล - เพิ่มการตัดสินใจนี้ลงในคำอธิบายของแถว element ใน $สคีมา หนึ่งบรรทัด: "ไม่มีธาตุก็ต้องระบุ (none) ช่องว่างคือความผิดพลาด"

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

ขั้นที่ 5 — ดึง Enum/proto จากชีตด้วยปุ่ม VBA Export

นิยาม proto ที่ผ่านการตรวจสอบแล้วจะถูกแมโคร Export ของ Excel (ปุ่มในชีต $สคีมา) ส่งออกอย่างสม่ำเสมอ คนจะไม่พิมพ์ซ้ำอีกครั้งใน IDE เพราะชีตคือแหล่งความจริง proto จึงออกมาจากชีต ลำดับนี้เป็นการต่อยอดของหลักการ "ผลลัพธ์คือฉบับจริง" (json_over_schema_doc_as_source_of_truth) ที่จะกล่าวถึงใน 3.3—ไม่ใช่เอกสารอธิบายโค้ด แต่ชีตเป็นตัวให้กำเนิดโค้ด

ขั้นที่ 6 — ถึงตอนนั้นจึงกรอกข้อมูล csv (มี AI ช่วย รวมการขอใหม่)

พรอมต์ (ฉบับเต็ม): จงสร้างแถว csv 5 แถวที่เป็นไปตาม Skill proto และ $สคีมาข้างต้น ข้อจำกัด: class_id เป็นหนึ่งใน [1,2,3] (PK ที่มีอยู่ในชีต Class ปัจจุบัน), damage_coef ถ้าเป็นพาสซีฟ (is_passive=true) ให้เป็น 0.0, element ให้เป็นสตริง fire/ice/lightning/none ตามเดิม, ห้ามเว้นว่าง

ในผลลัพธ์ครั้งแรกของ Claude มีอยู่แถวหนึ่งที่ผิดพลาด

skill_id,name,class_id,cooldown,damage_coef,element,is_passive
1001,เฉือนเปลวเพลิง,1,3.5,2.4,fire,false
1002,มือเยือกแข็ง,2,8.0,3.1,ice,false
1003,ฟื้นฟูพลังชีวิต,1,0.0,1.2,none,true     ← ปฏิเสธ: เป็นพาสซีฟแต่ damage_coef≠0
1004,หอกสายฟ้า,3,5.0,2.8,lightning,false
1005,ท่าตั้งรับ,2,0.0,0.0,none,true

แถว 1003 ละเมิดกฎ (ถ้า is_passive=true ก็ต้องเป็น damage_coef=0.0) คนจึงปฏิเสธและขอใหม่

การขอใหม่ (ฉบับเต็ม): แถว 1003 ละเมิดกฎ is_passive=true แต่ damage_coef=1.2 พาสซีฟต้องเป็น 0.0 จงแก้เฉพาะ 1003 แล้วส่งกลับมาใหม่

ผลลัพธ์ใหม่ของ Claude: 1003,ฟื้นฟูพลังชีวิต,1,0.0,0.0,none,true

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

บทเรียนของบันทึกทั้งหมดนี้เรียบง่าย ถ้าลำดับการป้อนข้อมูลถูกตรึงไว้เป็น $สคีมา → proto → csv AI จะกรอกรูปแบบได้รวดเร็ว และคนจะตรวจสอบเฉพาะความหมายและการละเมิด ถ้าลำดับพังทลาย คนจะต้องแบกรับทั้งหมดตั้งแต่รูปแบบไปจนถึงความหมาย

3.2.3 schema-doc — เพื่อไม่ให้คนต้องคัดลอกสคีมาด้วยมือ

การวาง $สคีมา ไว้ใน Excel นั้นสะดวกสำหรับนักออกแบบเกม แต่เป็นที่ปิดสำหรับ AI กับ git และเครื่องมือภายนอก ดังนั้นจึงมีการใช้เครื่องมือที่แปลง $สคีมา เป็น Markdown โดยอัตโนมัติ คำสั่งสแลช (slash command) schema-doc ทำหน้าที่นี้

การทำงานมีสี่ขั้นตอน

1. parse ชีต $สคีมา ของ Excel (xlsm) (python-calamine, เร่งความเร็วด้วย Rust)
2. ดึงนิยามคอลัมน์ 5 องค์ประกอบออกมา
3. แปลงเป็นตาราง Markdown
4. สร้าง <ชื่อชีต>_schema.md ในโฟลเดอร์เดียวกัน

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

ผลลัพธ์ที่ schema-doc สร้างขึ้น (อ้างอิงชีต Skill จากบันทึกก่อนหน้า):

# สคีมาชีต Skill  (สร้างอัตโนมัติ — ห้ามแก้ไขโดยตรง)

| คอลัมน์ | ชนิด | ช่วงค่า/ข้อจำกัด | FK | คำอธิบาย |
|---|---|---|---|---|
| skill_id | int | 1000~9999 | (PK) | ID เฉพาะของสกิล |
| name | string | 1~30 ตัวอักษร | - | ชื่อที่แสดง |
| class_id | int(FK) | - | Class.class_id | คลาสที่ใช้ได้ |
| cooldown | float | 0.0~120.0 | - | เวลารอใช้ซ้ำ (วินาที) |
| damage_coef | float | 0.0~10.0 | - | สัมประสิทธิ์คูณพลังโจมตี |
| element | enum | fire/ice/lightning/none | - | ธาตุ ไม่มีธาตุก็ต้องระบุ (none) ช่องว่างคือความผิดพลาด |
| is_passive | bool | true/false | - | เป็นพาสซีฟหรือไม่ ถ้า true แล้ว damage_coef=0 |

_source: Skill.xlsm / generated by schema-doc_

โปรดสังเกตว่าขอบเขตที่คนขีดไว้ในขั้นที่ 4 และ 6 ของ 3.2.2 ตามเข้ามาในช่องคำอธิบายของ element และ is_passive ตามเดิม คนเขียนเพิ่มลงใน $สคีมา หนึ่งบรรทัด แล้วเอกสาร·proto·การตรวจสอบก็มาใช้กฎเดียวกันร่วมกันหมด นี่คือภาพที่แหล่งความจริงเดียวทำงานจริง

สคีมาที่ออกมาเป็น Markdown ถูกนำไปใช้ทันทีในสามที่

• การสร้างข้อมูลด้วย AI: ก่อนจะสร้างแถว AI อ่านตารางนี้แล้วสร้างเฉพาะแถวที่ปฏิบัติตามคอลัมน์ทั้ง 7·ข้อจำกัดแต่ละข้อ·FK ที่นิยามไว้
• การปฐมนิเทศนักออกแบบเกมคนใหม่: ตารางหนึ่งหน้านี้เร็วกว่าการประชุมสามครั้ง
• Linter: ตรวจสอบโดยอัตโนมัติว่าแต่ละแถวของ csv ละเมิดตารางนี้หรือไม่

3.2.4 gen_relation_map.py — ดูด้วยกราฟว่า FK ยังมีชีวิตอยู่หรือไม่

ถ้าสคีมาเป็นกฎ ภายใน ชีต FK ก็เป็นกฎ ระหว่าง ชีต นิยามที่ว่า class_id อ้างอิงไปยังชีต Class นั้นเขียนไว้ใน $สคีมา แต่การจะรู้ว่าการอ้างอิงนั้นยังมีชีวิตอยู่จริงในวินาทีนี้หรือไม่ ต้องมีการตรวจสอบแยกต่างหาก

gen_relation_map.py ตรวจจับความสัมพันธ์ FK ของชีตข้อมูลโดยอัตโนมัติ แล้ววาดเป็นแผนผังความสัมพันธ์ HTML แบบโต้ตอบได้ เมื่อลูกศรอย่าง class_id→Class ของ Skill, set_id→ItemSet ของ Item มารวมอยู่ในหน้าจอเดียว "FK ที่เป้าหมายอ้างอิงหายไป" ก็จะปรากฏให้เห็นเป็นลูกศรที่ขาด อุบัติเหตุอย่างการขาดหายของหมายเลข 47 ในช่วงเปิดบทนี้ จะปรากฏ ระหว่างที่กำลังกรอกข้อมูล เป็นเส้นที่ขาดในแผนผังความสัมพันธ์ ไม่ใช่เป็นบรรทัดสีแดงในล็อกบิลด์

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

3.2.5 เวิร์กโฟลว์สคีมามาก่อน 5 ขั้น

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

ไม่จำเป็นต้องมีครบทั้งห้าขั้นในเดือนแรก แค่หมุน 1·2 ขั้น (ออกแบบสคีมา + ทำเอกสารอัตโนมัติ) ก็ได้คุณค่าไปครึ่งหนึ่งแล้ว ขั้นที่ 3\~5 ค่อยต่อเติมทีละน้อยหลังจากคุ้นเคยกับการดำเนินงาน ถ้าบังคับครบห้าขั้นตั้งแต่ต้น ภาระของผู้เขียนข้อมูลจะทำให้การดำเนินงานหยุดก่อนจะตั้งหลักได้

3.2.6 สิ่งที่วัดได้จากโปรเจกต์ A

ในโปรเจกต์ MMORPG หนึ่งที่ผู้เขียนบริหารในฐานะ Director (ต่อไปนี้เรียก "โปรเจกต์ A") ผู้เขียนได้หมุนเวิร์กโฟลว์นี้ประมาณ 6 เดือน ในบรรดาตัวเลขด้านล่าง ความสม่ำเสมอของคอลัมน์ชีตข้อมูลและเวลาที่ใช้ร่างชีตใหม่ เป็นค่าที่วัดจริงซึ่งรวบรวมจากล็อกเครื่องมือและบันทึกการทำงาน ส่วนความถี่ของ FK ที่ขาด เป็น การประมาณของผู้เขียน (ยังไม่ได้ตรวจสอบ) ที่คำนวณย้อนจากปัญหาบิลด์ล้มเหลว

ต้นทุนการนำมาใช้คือการพัฒนาเครื่องมือเริ่มต้นประมาณ 3 วัน + การตั้งหลักดำเนินงานประมาณ 1 เดือน บทสรุปจากการดำเนินงานคือ ต้นทุนการนำมาใช้นั้นน้อยเมื่อเทียบกับผลสะสม 6 เดือน อย่างไรก็ตาม อัตราส่วนข้างต้นเป็นกรณีเดี่ยวของทีมเดียว·โปรเจกต์เดียว จึงไม่มีหลักประกันว่าจะนำไปใช้กับทีมอื่นได้ตามเดิม

3.2.7 การเสริมพลังกันระหว่าง AI กับสคีมา และขอบเขตของมัน

เมื่อมีสคีมาปูรองอยู่ ความน่าเชื่อถือของการสร้างข้อมูลด้วย AI จะพุ่งสูงขึ้นอย่างก้าวกระโดด เหตุผลคือสคีมาปิดช่วงการป้อนข้อมูลที่คลุมเครือซึ่งเป็นชนวนของอาการหลอน (hallucination) ไว้ล่วงหน้า เมื่อมีคำขอว่า "ช่วยสร้างสกิล 20 อัน" หากไม่มีสคีมา AI จะประดิษฐ์คอลัมน์ที่ดูเข้าท่าขึ้นมาแล้วเติมค่าที่ไม่เข้ากับชีตของเราเอง ถ้ามีสคีมา คำขอเดียวกันจะกลับมาเป็นแถวที่ปฏิบัติตามคอลัมน์ทั้ง 7·ข้อจำกัดแต่ละข้อ·FK ที่นิยามไว้ ต่อให้มีการละเมิดอย่างกรณีแถว 1003 ของ 3.2.2 ก็แค่ชี้บรรทัดเดียวแล้วขอใหม่ก็จบ

แต่ขอบเขตชัดเจน ค่าบาลานซ์ (balance) ไม่สั่งให้ AI ทำ ถ้าให้ AI กำหนด damage_coef "ตามที่เหมาะสม" มันจะขัดกับเจตนาของเกม สิ่งที่เป็นหน้าที่ของ AI คือการปูตัวเลือกที่รูปแบบถูกต้องให้เร็วเท่านั้น ส่วน "สัมประสิทธิ์ของสกิลนี้ที่เป็น 2.4 ถูกต้องหรือไม่" เป็นสิ่งที่คนตอบ แต่นั่นไม่ได้หมายความว่า AI ไร้ประโยชน์ต่อการบาลานซ์—ความเรียบลื่นของเส้นโค้ง·ค่าผิดปกติ·สถิติช่วงค่า AI จับได้รวดเร็ว มอบหมายการวัดตัวเลขให้เครื่องมือ ส่วนตัวเลขนั้นถูกต้องหรือไม่ คนเป็นผู้คัดแยก

3.2.8 ความผิดพลาดที่พบบ่อยและการหลีกเลี่ยง

ลองทำดู

setup 1. เลือกชีตที่เป็นแกนหลักที่สุดหนึ่งชีตในสายงานของคุณ (เลือกหนึ่งในสกิล·ไอเทม·มอนสเตอร์) 2. เพิ่มชีตชื่อ $สคีมา ลงในไฟล์ Excel นั้น แล้วเขียน 5 องค์ประกอบ (ชื่อ·ชนิด·ช่วงค่า·FK·คำอธิบาย) ของแต่ละคอลัมน์ทีละบรรทัด ขั้นตอนนี้คนทำเอง

prompt (ใช้ AI เฉพาะกับการร่าง proto/csv เท่านั้น)

จงแปลง $สคีมาด้านล่างเป็นข้อความ (message) และ Enum ของ proto3 ค่าแรกของ enum คือ _UNSPECIFIED = 0 FK ให้คงเป้าหมายอ้างอิงไว้เป็นคอมเมนต์ ข้อจำกัดช่วงค่าให้คงไว้เป็นคอมเมนต์เท่านั้น ห้ามเพิ่มคอลัมน์ที่ไม่มีในข้อกำหนด (วาง $สคีมาของคุณตรงนี้)

ต่อด้วย:

แถว csv 5 แถวที่เป็นไปตาม proto และ $สคีมาข้างต้น อย่าสร้างแถวที่ละเมิดข้อจำกัด ถ้า is_passive=true ให้ damage_coef=0

verify 1. เทียบ 5 แถวที่ AI ให้มากับสคีมาทีละบรรทัด ถ้ามีแถวที่ละเมิด ให้ขอใหม่ว่า "แถว N ละเมิด แก้เฉพาะแถวนั้นให้หน่อย" (การปฏิเสธและการขอใหม่เป็นกระบวนการปกติ) 2. ดึง $สคีมา ออกมาเป็น .md ด้วย schema-doc (หรือสคริปต์ Python อย่างง่ายที่เทียบเท่า) แล้วตรวจว่านิยามใน Excel กับเอกสารตรงกันหรือไม่ 3. ถ้ามี FK ให้เทียบสักครั้งว่า PK ของเป้าหมายอ้างอิงมีอยู่จริงหรือไม่

ฉบับย่อสำหรับคนเดียว

ถ้าเริ่มต้นคนเดียวโดยไม่มีทั้งเครื่องมือและทีม ไฟล์ Excel หนึ่งไฟล์·เท็กซ์เอดิเตอร์หนึ่งตัวก็เพียงพอ

1. สร้าง $สคีมา ไว้ที่แท็บแรกของชีต แล้วเขียนกฎของคอลัมน์เป็น 5 องค์ประกอบ (15 นาที)
2. คัดลอกข้อกำหนดนั้นตามเดิม แล้วขอ "proto Enum + csv 5 แถว" จาก AI (10 นาที)
3. เทียบ csv ที่ได้รับกับสคีมาด้วยตา แล้วแก้บรรทัดที่ละเมิดหนึ่งบรรทัดด้วยการขอใหม่ (10 นาที)
4. บันทึกข้อความ $สคีมา ลง Notepad เป็น skill_schema.md ไว้ นี่คือแหล่งความจริงเดียวแหล่งแรกของคุณ

เมื่อขยับไปยังชีตถัดไป ให้ทำซ้ำ 4 ขั้นเดิม เมื่อชีตแกนหลัก 5\~10 ชีตในไตรมาสถูกจัดเรียงด้วยลำดับเดียวกัน ตอนนั้นแหละจึงจะเกิดคุณค่าที่จะต่อระบบอัตโนมัติอย่าง schema-doc เข้ามา

สรุปประเด็นสำคัญของบท

• ถ้าบังคับลำดับการป้อนข้อมูลเป็น $สคีมา→Enum/proto→csv การละเมิดจะถูกปิดก่อนกรอกข้อมูล
• Excel เป็นฉบับจริง·เอกสารเป็นอนุพันธ์ schema-doc ผูกทั้งสองไว้ที่แหล่งเดียว เพื่อให้คน·AI มองเห็นนิยามเดียวกัน
• ค่าบาลานซ์ให้คนตัดสินใจ ส่วน AI รับเฉพาะการปูตัวเลือกรูปแบบและการวัดค่าผิดปกติ

ตัวอย่างบทถัดไป

• 3.3 การแสดงผลแผนผังความสัมพันธ์ — ดู FK dependency ด้วยตาด้วย gen_relation_map.py

3.3 การแสดงผลแผนผังความสัมพันธ์ — มองเห็นการพึ่งพากันด้วยตา

นักออกแบบเกมที่เพิ่งเข้ามาใหม่เดินมาที่โต๊ะของผมในสัปดาห์แรกของการเริ่มงาน "ผมอยากแก้ตารางรางวัลของเควสต์ครับ ถ้าแตะตรงนี้แล้วมันจะพังตรงไหนบ้าง" ผมกำลังจะชี้ไปที่จอแล้วตอบ แต่ก็หยุดไว้ ในหัวของผมมีภาพอยู่ RewardTable ยึดอยู่กับ ItemTable ItemTable ยึดอยู่กับ ItemEffectTable และเหนือขึ้นไปก็มี QuestTable ที่อ้างอิงรางวัล… แต่พอผมพยายามแปลงภาพนั้นออกมาเป็นคำพูด รูปร่างมันก็พังทลายลงในหัวของคนฟัง ผมวาดกล่องเจ็ดกล่องลงบนไวต์บอร์ด ลูกศรเริ่มพันกันยุ่ง สามสิบนาทีต่อมา เขาพยักหน้าแล้วกลับไปที่โต๊ะ และวันรุ่งขึ้นก็กลับมาพร้อมคำถามเดิมอีกครั้ง

ฉากนี้แหละที่ทำให้ผมเขียนบทนี้ขึ้นมา ในหัวของนักออกแบบระบบมีกราฟการพึ่งพากันอยู่ ปัญหาคือมันอยู่แค่ในหัวเท่านั้น พอคนเปลี่ยน ภาพก็หายไปด้วย ผมต้องการเครื่องมือที่ดึงภาพนั้นออกมาไว้ภายนอก และสิ่งที่ผมสร้างขึ้นมาก็คือ gen_relation_map.py

เมื่อชีตข้อมูลมีอยู่ 5\~10 ชีต การใช้หัวคิดก็เพียงพอ แต่พอเกิน 30 ชีต ความจำขณะทำงานของคนก็รับไม่ไหว โฟลเดอร์ชีตของโปรเจกต์หนึ่งมักจะข้ามเส้นนั้นไปตั้งแต่เนิ่น ๆ ตารางที่เขียนเป็นข้อความว่าอะไรพึ่งพาอะไร อ่านแล้วก็วาดเป็นภาพไม่ออก บทนี้จะติดตามกระบวนการบันทึกเซสชันจริง (worked transcript) ในการสร้างแผนผังความสัมพันธ์แบบ HTML เชิงโต้ตอบจากความสัมพันธ์ foreign key โดยอัตโนมัติ ตั้งแต่ต้นจนจบ

3.3.1 ปัญหาสี่ข้อที่แผนผังความสัมพันธ์ช่วยแก้

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

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

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

การตรวจจับการพึ่งพาแบบย้อนทิศ การที่ชีตข้อมูล L3 อ้างอิงเอกสารระบบ L1 เป็นเรื่องปกติ แต่ทิศทางตรงข้าม (Layer ที่อยู่ระดับสูงกว่าอ้างอิงชีตข้อมูลระดับล่างโดยตรง) เกือบจะเป็นข้อบกพร่องในการออกแบบเสมอ ในรายการ FK ที่เขียนเรียงเป็นข้อความ คนจับการย้อนทิศนี้ไม่ได้ แต่ในภาพ มันจะปรากฏให้เห็นทันทีด้วยลูกศรเส้นเดียวที่สีของ Layer ไม่เข้ากัน

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

จุดร่วมของปัญหาทั้งสี่ข้อคือ ทั้งหมด "ต้องมองโครงสร้างด้วยตาถึงจะแก้ได้" ด้วยข้อความและตารางมันตัน

3.3.2 บันทึกเซสชันจริง: จากชีตข้อมูลไปจนถึงแผนผังความสัมพันธ์

ทีนี้มาติดตามกันจริง ๆ อินพุตคือโฟลเดอร์หนึ่งที่บรรจุชีตข้อมูล เอาต์พุตคือ HTML เชิงโต้ตอบหนึ่งแผ่นที่เปิดในเบราว์เซอร์ ผมจะบันทึกสิ่งที่ AI ทำและจุดที่คนตรวจสอบ/ปฏิเสธไว้ในระหว่างนั้นโดยไม่ตกหล่น

3.3.2.1 ภาพรวมของกระบวนการทั้งหมด

flowchart TD
    A[โฟลเดอร์ชีตข้อมูล
xlsm/xlsx จำนวนมาก] --> B[1. สแกน: เก็บส่วนหัวของชีตและคอลัมน์]
    B --> C[2. ดึงตัวเลือก FK
*_id / *Id / FK ที่ระบุในเอกสารกำหนด]
    C --> D[3. จับคู่เป้าหมายการอ้างอิง
ชื่อคอลัมน์ → ชีตเป้าหมาย]
    D --> E{การตรวจสอบโดยมนุษย์}
    E -->|ปฏิเสธผลบวกลวง| C
    E -->|ผ่าน| F[4. สร้างกราฟ
โหนด=ชีต, เอดจ์=FK]
    F --> G[5. ใส่เมตา Layer
อ้างอิงผลลัพธ์ schema-doc]
    G --> H[6. เรนเดอร์ HTML ด้วย pyvis]
    H --> I[relation_map.html
โต้ตอบในเบราว์เซอร์]
    I --> J{การวินิจฉัยโดยมนุษย์}
    J -->|พบการย้อนทิศ·โดดเดี่ยว·วนรอบ| K[ขอแก้ไขการออกแบบ]
    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    class A,I data
    class B,C,D,F,G,H code
    class E,J,K human

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

3.3.2.2 FK มาจากไหน — ลำดับของอินพุต

ความแม่นยำของเครื่องมือนี้ถูกกำหนดด้วยว่าดึงอินพุตมาจากไหน หลักการ schema-first ที่กำหนดไว้ใน 3.2 ถูกนำมาใช้ตรง ๆ ลำดับฉบับที่ยึดเป็นหลักของข้อมูล FK เป็นดังนี้

1. ชีต $스키마 — ฉบับที่ยึดเป็นหลักอันดับแรกของแต่ละชีตข้อมูล มีการระบุประเภท·Enum·เป้าหมาย FK แยกตามคอลัมน์ ถ้ามี FK เขียนอยู่ตรงนี้ นั่นคืออันดับ 1
2. นิยาม *.proto / Enum — สคีมาที่ส่งออกมาด้วย Export ของ VBA (ภาษามาโครของ Excel) เสริมประเภทเมื่อเอกสารกำหนดว่างเปล่า
3. เอาต์พุต csv จริง — ข้อมูลจริงที่ชีตส่งออกมา ความสัมพันธ์ที่ไม่มีในเอกสารกำหนดก็ปรากฏเป็นแพตเทิร์นในข้อมูลได้ (เช่น ถ้าค่าของคอลัมน์ npc_id อยู่ในช่วงคีย์ของ NPCTable ทั้งหมด ก็ถือว่าเป็น FK โดยพฤตินัย)

ตรงนี้ผมขอกำหนดหลักการหนึ่งให้ชัดเจน ฉบับที่ยึดเป็นหลักไม่ใช่เอกสารสคีมา แต่เป็นเอาต์พุต JSON/csv จริง แม้ในเอกสารกำหนดจะเขียนว่า reward_id เป็น FK แต่ถ้าในข้อมูลจริงคอลัมน์นั้นว่างเปล่าหรือชี้ไปยังค่าที่ไม่เกี่ยวข้อง ก็แปลว่าเอกสารกำหนดผิด เครื่องมือจะเชื่อฝั่งข้อมูลเมื่อทั้งสองไม่ตรงกัน และจะบันทึกความไม่ตรงกันนั้นไว้ในรายงาน นี่คือเหตุผลที่ไม่ตั้งให้ schema-doc เป็นฉบับที่ยึดเป็นหลัก

3.3.2.3 ขั้นที่ 1 — สแกนโฟลเดอร์และดึงตัวเลือก FK

การกระทำแรกของเครื่องมือคือ เปิด xlsm/xlsx ทุกไฟล์ในโฟลเดอร์เพื่อเก็บส่วนหัวของชีตและคอลัมน์ ขั้นนี้เป็นเชิงกลไกล้วน ๆ จึงไม่น่าสนใจ ที่น่าสนใจคือกฎในการดึงตัวเลือก FK ตอนแรกมันเรียบง่าย ถ้าชื่อคอลัมน์ลงท้ายด้วย *_id หรือ *Id ก็ถือเป็นตัวเลือก FK แต่กฎข้อเดียวนี้ทำให้เกิดทั้งผลบวกลวงและการตกหล่น

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

พรอมต์: ต่อไปนี้คือชื่อชีตและรายการส่วนหัวของคอลัมน์ของชีตข้อมูลเกม จงอนุมานว่าแต่ละคอลัมน์เป็น foreign key (FK) หรือไม่ และถ้าเป็น FK มันอ้างอิงคอลัมน์ใดของชีตใด กฎของชื่อคอลัมน์โดยทั่วไปคือ <รูปเอกพจน์ของชีตเป้าหมาย>_id แต่ถ้าไม่มั่นใจ จงทำเครื่องหมายว่า "ไม่แน่ใจ" แล้วเขียนเหตุผล อย่าเติมด้วยการเดา

QuestTable: quest_id, title, npc_id, reward_id, prev_quest_id, region_id
NPCTable: npc_id, name, region_id, faction_id
RewardTable: reward_id, item_id, count, currency_id
ItemTable: item_id, name, item_effect_id, grade
ItemEffectTable: item_effect_id, effect_type, value
RegionTable: region_id, name, parent_region_id

ผลลัพธ์ดิบของ Claude (ละแถว PK ไว้ คัดเฉพาะการตัดสิน FK):

QuestTable - npc_id → NPCTable.npc_id (คาดว่าเป็น NPC ที่ให้เควสต์) - reward_id → RewardTable.reward_id - prev_quest_id → QuestTable.quest_id (เควสต์ก่อนหน้า, การอ้างอิงตัวเอง) - region_id → RegionTable.region_id

NPCTable - region_id → RegionTable.region_id - faction_id → ไม่แน่ใจ: ไม่มี FactionTable อยู่ในรายการอินพุต ตามกฎของชื่อคอลัมน์ดูเหมือนจะอ้างอิง FactionTable.faction_id แต่เนื่องจากไม่ได้ให้ชีตนั้นมา จึงไม่สามารถยืนยันเป้าหมายได้

RewardTable - item_id → ItemTable.item_id - currency_id → ไม่แน่ใจ: ไม่มี CurrencyTable อยู่ในรายการ ประเภทของสกุลเงินอาจถูกจัดการเป็น Enum ก็ได้ ดังนั้นอาจไม่ใช่ FK จำเป็นต้องตรวจสอบเอกสารกำหนด

ItemTable - item_effect_id → ItemEffectTable.item_effect_id - grade → ไม่ใช่ FK (คาดว่าเป็น Enum: ค่าระดับ)

ItemEffectTable - effect_type → ไม่ใช่ FK (คาดว่าเป็น Enum)

RegionTable - parent_region_id → RegionTable.region_id (การอ้างอิงตัวเอง, โครงสร้างลำดับชั้นของภูมิภาค)

หมายเหตุ: การอนุมานข้างต้นอ้างอิงจากกฎของชื่อคอลัมน์ และไม่ได้ตรวจสอบค่าข้อมูลจริง โดยเฉพาะคอลัมน์ที่ไม่ได้ลงท้ายด้วย _id อย่าง count และ value ผมตัดออกจากเป้าหมายการตรวจ FK แต่ถ้ามีการอ้างอิงที่ซ่อนอยู่ ก็จะตกหล่นไป

ในผลลัพธ์นี้ สิ่งที่คนทำมีสามอย่าง

• ปฏิเสธ 1: faction_id → AI จัดให้เป็นไม่แน่ใจเพราะไม่มี FactionTable ถูกต้องแล้ว แต่จริง ๆ faction_id เป็น Enum เนื่องจากแฟกชันถูกตรึงไว้ที่ 6 ชนิด จึงจัดการด้วย Enum โดยไม่ต้องมีชีตแยก เพราะ AI ไม่ได้กุชีตที่ไม่มีขึ้นมาและหยุดการตัดสินไว้ คนจึงดูเอกสารกำหนดแล้วยืนยันเป็น Enum ได้ ตัดออกจาก FK
• ปฏิเสธ 2: currency_id → AI เปิดความเป็นไปได้ไว้ทั้งสองทาง พอดูข้อมูลจริงก็พบว่า CurrencyTable มีอยู่ (ผมเองที่ตกหล่นในรายการอินพุต) ยืนยันเป็น FK นี่เป็นการตกหล่นในอินพุตของคน ไม่อาจโทษ AI ได้
• ยอมรับ: การตรวจจับการอ้างอิงตัวเองของ prev_quest_id และ parent_region_id ถ้าเป็นแค่กฎ regex ธรรมดาก็คงพลาดไป การที่ AI ใส่ความหมายอย่าง "เควสต์ก่อนหน้า" "ลำดับชั้นของภูมิภาค" มาให้ด้วย ช่วยให้การตรวจสอบเร็วขึ้น

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

3.3.2.4 ขั้นที่ 2 — สร้างกราฟและใส่ Layer

เมื่อได้รายการ FK ที่ผ่านการตรวจสอบแล้ว gen_relation_map.py ก็จะสร้างกราฟ ชีตเป็นโหนด FK เป็นเอดจ์แบบมีทิศทาง มันนับจำนวน inbound edge (ชีตอื่นอ้างอิงฉันมากแค่ไหน) เพื่อกำหนดขนาดของโหนด ยิ่งถูกอ้างอิงมากก็ยิ่งเป็นโหนดใหญ่ นั่นคือฮับของระบบ

เมตาดาตาของ Layer ดึงมาจากเอกสารสคีมา markdown ที่สกิล schema-doc สร้างขึ้น พิกัด Layer (L0\~L4) ที่นิยามไว้ใน 3.1 ถูกติดเป็นป้ายให้แต่ละชีต และเครื่องมือก็อ่านมันแล้วลงสีโหนด การเชื่อมนี้สำคัญ ถ้าแผนผังความสัมพันธ์ไม่รู้จัก Layer มันก็เป็นแค่กล่องกับลูกศร ต้องรู้จัก Layer ถึงจะวินิจฉัย "การย้อนทิศ" ด้วยสีได้

ถ้าแสดงโครงสร้างภายในของเครื่องมือออกมาเป็นโครงโค้ดก็เป็นดังนี้ (คัดเฉพาะกระแสหลัก)

# gen_relation_map.py (คัดเฉพาะกระแสหลัก)
from pyvis.network import Network

LAYER_COLORS = {          # จานสี Layer — ทำให้เป็นมาตรฐานด้วย atom 1 ตัว
    "L0": "#2c3e50",      # เมตา/ใช้ร่วม
    "L1": "#2980b9",      # ระบบ
    "L2": "#27ae60",      # เนื้อหา
    "L3": "#f39c12",      # อินสแตนซ์ข้อมูล
    "L4": "#c0392b",      # อนุพันธ์/แคช
}

def build_graph(fk_list, layer_map):
    net = Network(directed=True, height="900px")
    inbound = count_inbound(fk_list)          # รวมจำนวน inbound edge
    for sheet in all_sheets(fk_list):
        layer = layer_map.get(sheet, "L0")
        size = 10 + inbound[sheet] * 3        # ยิ่งเป็นฮับยิ่งโหนดใหญ่
        net.add_node(sheet, color=LAYER_COLORS[layer],
                     size=size, title=sheet_tooltip(sheet))
    for src, dst, col in fk_list:
        # ตรวจจับการย้อนทิศของ Layer: ถ้า Layer ระดับสูงอ้างอิงระดับล่าง ให้ใช้สีเตือน
        edge_color = "#e74c3c" if is_reverse(src, dst, layer_map) else "#888"
        net.add_edge(src, dst, title=col, color=edge_color)
    return net

is_reverse คือหัวใจเล็ก ๆ ของเครื่องมือนี้ ถ้าชีตต้นทางของเอดจ์อยู่ Layer ระดับสูงกว่าชีตปลายทาง (เช่น L1 → L3) ก็ถือว่าเป็นการย้อนทิศและลงสีเอดจ์เป็นสีแดง พอคนเปิดภาพขึ้นมาแล้วเห็นลูกศรสีแดง นั่นเกือบจะเป็นจุดที่ต้องแก้เสมอ

3.3.2.5 ขั้นที่ 3 — เรนเดอร์ HTML และโครงสร้างผลลัพธ์

ขั้นสุดท้ายคือขั้นที่ pyvis พ่น HTML เชิงโต้ตอบออกมา เมื่อคลิกที่โหนด คอลัมน์·Layer·จำนวน inbound ของชีตนั้นจะแสดงเป็นทูลทิป และสามารถกรองด้วยชื่อชีตในช่องค้นหาได้ เหตุผลที่ต้องเป็น HTML ไม่ใช่ PNG แบบสแตติกอยู่ตรงนี้ — เมื่อจำนวนโหนดเกินหลายสิบ ในภาพแบบสแตติกลูกศรจะพันกันจนมองอะไรไม่เห็น ต้องลากด้วยเมาส์เพื่อคลี่ออก แล้วคลิกเจาะเฉพาะพื้นที่ที่สนใจ ถึงจะจับแพตเทิร์นได้

ถ้าแปลงโครงสร้างของแผนผังความสัมพันธ์ที่สร้างจากข้อมูลตัวอย่างข้างบนออกมาเป็น SVG ก็เป็นดังนี้ สีคือ Layer ลูกศรสีแดงหมายถึงตำแหน่งการย้อนทิศ (แม้ในตัวอย่างนี้จะไม่มีก็ตาม)

ดูจากขนาดของโหนดจะเห็นว่า RegionTable ถูกอ้างอิงมากที่สุด (ทั้ง Quest·NPC ชี้มาหมด) นี่คือฮับ ส่วน ItemEffectTable เป็นโหนดใบไม้จึงเล็ก คำตอบของคำถามที่นักออกแบบใหม่ถามว่า "ถ้าจะเข้าใจระบบนี้ ควรเริ่มดูจากตรงไหน" อยู่ในภาพอยู่แล้วตามลำดับขนาดของโหนด

3.3.3 การวินิจฉัยที่ภาพสร้างขึ้น — ผสานกับ Layer

ใน 3.1 ผมนิยามพิกัด Layer ไว้ พอแผนผังความสัมพันธ์ของบทนี้ยกพิกัดนั้นขึ้นมาสู่สายตา การวินิจฉัยสี่อย่างที่ข้อความหรือตารางทำไม่ได้ก็เป็นไปได้ในหน้าจอเดียว

• การย้อนทิศของ Layer — ลูกศร (สีแดง) ที่สีของ Layer ไหลย้อนทิศ เป็นโครงสร้างที่ไม่เป็นธรรมชาติ ที่ชีตข้อมูลส่งผลกระทบย้อนกลับไปยังการออกแบบระบบ
• โหนดที่โดดเดี่ยว — เกาะร้างที่ไม่เชื่อมต่อกับเอดจ์ใดเลย เป็นตัวเลือกที่จะถูกเลิกใช้
• ฮับรับภาระเกิน — โหนดยักษ์ที่มี inbound edge มากผิดปกติ เป็นสัญญาณว่าชีตหนึ่งแบกความรับผิดชอบมากเกินไป ควรพิจารณาการแบ่ง
• การพึ่งพาแบบวนรอบ — ตำแหน่งที่ลูกศรวาดเป็นวงกลม เกือบจะเป็นข้อบกพร่องในการออกแบบเสมอ และนำไปสู่ปัญหาเรื่องลำดับการโหลดข้อมูล

แต่ก็ไม่ได้หมายความว่าภาพจะจับทุกปัญหา ภาพจับข้อบกพร่องเชิงโครงสร้าง ส่วนที่ว่า FK นี้เป็นความสัมพันธ์ที่ถูกต้องตามความหมายจริงไหม (เช่น npc_id เป็น "NPC ที่ให้เควสต์" จริง หรือเป็น "NPC ที่ปรากฏในเควสต์" กันแน่) นั้นภาพแก้ไม่ได้ นั่นเป็นหน้าที่การตัดสินเชิงโดเมนของคน เครื่องมือเพียงแค่ปูเวทีให้การตัดสินของคนได้ทำงานเท่านั้น

3.3.4 ถ้าไม่มีการอัปเดตอัตโนมัติ มันจะผุ

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

ดังนั้นผมจึงผูกการอัปเดตไว้กับทริกเกอร์อัตโนมัติ

• Git pre-push hook — สร้างแผนผังความสัมพันธ์ขึ้นใหม่ก่อนพุชชีตข้อมูล รับประกันว่าเป็นสถานะล่าสุดเสมอ
• ณ จุดที่มีคำขอเปลี่ยนแปลง — เมื่อมีคำขอเปลี่ยนแปลงชีตข้อมูลเข้ามา ก็เทียบแผนผังความสัมพันธ์ก่อนและหลังการเปลี่ยนแปลงด้วย diff แล้วแนบไว้ในคอมเมนต์ เอดจ์ที่เพิ่มมาเป็นสีเขียว เอดจ์ที่หายไปเป็นสีแดง ผู้รีวิวจะได้เห็นขอบเขตผลกระทบเป็นภาพ
• แบตช์กลางคืน — ทุกคืนสร้างแผนผังความสัมพันธ์ใหม่แล้วเก็บ diff เทียบกับวันก่อนหน้าไว้
• คำสั่งด้วยมือ — สร้างทันทีด้วยสแลช /relation-map ใช้ตอนอยากเปิดขึ้นมาแบบสด ๆ ระหว่างประชุม

HTML ที่สร้างขึ้นจะถูกดีพลอยไปยังโฮสติงสแตติกภายในองค์กร (พอร์ทัลการออกแบบ) โดยอัตโนมัติ ทุกคนเห็นแผนที่เดียวกันได้เพียงแค่มีเบราว์เซอร์ โดยไม่ต้องติดตั้งเครื่องมือเพิ่ม เหมือนแผนที่ที่กางคลี่ไว้ข้างโต๊ะตลอดเวลา ไม่ว่าใครจะถาม ก็ตอบโดยชี้ไปยังภาพเดียวกันด้วยกัน

3.3.5 ความผิดพลาดที่พบบ่อยและวิธีหลีกเลี่ยง

ในการดำเนินงาน gen_relation_map.py สิ่งที่ผมเจ็บตัวบ่อยที่สุดคือบรรทัดที่สาม ถ้าเชื่อแค่กฎ *_id ก็จะพลาดการอ้างอิงที่ซ่อนอยู่อย่าง count หรือ value (AI ใน 3.3.2.3 ก็เตือนข้อจำกัดนี้ด้วยตัวเอง) และตรวจ Enum อย่าง grade ผิดเป็น FK ลูปการตรวจสอบที่ดูทั้งเอกสารกำหนดและข้อมูลจริงคือคำตอบของบรรทัดนี้

3.3.6 ลองทำฉบับย่อสำหรับคนเดียวก่อน

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

ลองทำดู

setup. 1. เลือกโฟลเดอร์หนึ่งที่บรรจุชีตข้อมูล 5\~10 ชีตที่คุณรับผิดชอบ 2. ติดตั้ง dependency ด้วย pip install pyvis openpyxl (การอ่าน Excel ใช้สกิล excel-reader หรือ openpyxl) 3. ตรวจดูก่อนว่าในชีต $스키마 ของแต่ละชีตมีการระบุ FK ไว้หรือไม่ ถ้าไม่มี ก็เก็บแค่ส่วนหัวของคอลัมน์

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

verify. 1. ดูตัวเลือก FK ที่ AI ส่งมาทีละบรรทัด ยืนยันบรรทัดที่ทำเครื่องหมาย "ไม่แน่ใจ" ด้วยเอกสารกำหนด/ข้อมูลจริง 2. คอลัมน์ที่สงสัยว่าเป็น Enum (อย่าง grade, effect_type ที่ไม่มี _id แต่ดูเหมือน FK) ให้ตัดออกจาก FK 3. ตรวจว่าการอ้างอิงตัวเอง (prev_*_id, parent_*_id) ถูกจับมาถูกต้องไหม 4. วาดกราฟด้วยรายการที่ผ่านการตรวจสอบ แล้วเปิดในเบราว์เซอร์เพื่อค้นหาลูกศรสีแดง (การย้อนทิศ) และเกาะร้าง (การโดดเดี่ยว) ด้วยตา

ฉบับย่อสำหรับคนเดียว

ถ้าไม่มีเวลาสร้างเครื่องมือ ในสัปดาห์แรกจะเริ่มจาก mermaid ที่วาดด้วยมือสักหนึ่งแผ่นก็ได้ เขียน FK ของ 5 ชีตลงใน mermaid โดยตรงด้วยรูปแบบของ 3.3.2.3 พอเอาแผ่นนี้ไปประชุมแล้วแสดงให้ดูว่า "นี่คือการพึ่งพากันของระบบเรา" คุณค่าก็พิสูจน์ได้ตรงนั้นเลย พอเห็นคุณค่าแล้ว เครื่องมืออัตโนมัติก็จะตามมาเองในลำดับถัดไป คุณวางภาระที่ว่าต้องมีเครื่องมือที่ทำงานได้ออกมาตั้งแต่แรกลงได้

การขยายจะไหลไปตามลำดับนี้อย่างเป็นธรรมชาติ — สัปดาห์ที่ 1 ภาพวาดมือ mermaid ของชีตตัวเอง → สัปดาห์ที่ 2 เพิ่มสี Layer และการคลิก → 1 เดือน อัปเดตอัตโนมัติ (git hook หรือแบตช์กลางคืน) → 3 เดือน ดีพลอยขึ้นพอร์ทัลภายในองค์กร → 6 เดือน แผนผังความสัมพันธ์รวมของชีตทั้งหมด

3.3.7 เชื่อมต่อสู่บทถัดไป

ใน 3.2 ผมจัดการกับด้านในของชีต (สคีมา) ใน 3.3 ก็จัดการด้านนอกของชีต (ความสัมพันธ์) ส่วน 3.4 จะวางแพตเทิร์นพรอมต์ที่ AI ช่วยเสริมไว้เหนือสิ่งเหล่านี้ บนระบบที่สคีมาและความสัมพันธ์ลงตัวแล้ว มันจะต่อด้วยแพตเทิร์นเชิงปฏิบัติว่า AI ช่วยเสริมการตรวจความสอดคล้องและการดึงขอบเขตผลกระทบได้อย่างไร

สรุปประเด็นสำคัญของบท

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

ตัวอย่างบทถัดไป

• 3.4. แพตเทิร์นพรอมต์การออกแบบระบบที่ AI ช่วยเสริม

3.4 รูปแบบพรอมต์สำหรับการออกแบบระบบโดยมี AI ช่วย

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

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

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

3.4.1 พรอมต์แบบด้นสดรั่วสองจุด

เมื่อเริ่มใช้ AI ครั้งแรก เรามักพิมพ์เป็นภาษาธรรมชาติด้นสดทุกครั้ง ในทำนองนี้

ช่วยดูชีตสกิลให้หน่อย ตรวจดูว่ามี foreign key พังไหม
ถ้ามีอะไรแปลก ๆ ก็บอกด้วย อ้อ แล้วก็ที่ cooldown ติดลบด้วยนะ

พรอมต์นี้รั่วอยู่สองจุด

จุดแรก รายการที่ตรวจเปลี่ยนไปทุกครั้ง วันนี้นึกถึง "cooldown ติดลบ" ได้ แต่พรุ่งนี้ลืม "PK ซ้ำ (Primary Key, คีย์หลัก)" ที่เคยกรองออกไปเมื่อวานหายไปจากพรอมต์ของวันนี้ การตรวจที่พึ่งพาความจำของคนย่อมตกหล่นตามสภาพร่างกายของคนในวันนั้น

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

ทางแก้คือปล่อยพรอมต์ออกจากมือแล้วเก็บเข้าลิ้นชัก เปลี่ยนบันทึกที่เคยจดด้วยมือทุกครั้งให้เป็นการ์ดที่ติดป้ายกำกับ แล้วหยิบออกจากลิ้นชักเดียวกัน การ์ดใบนั้นคือคำสั่งสแลช (slash command หรือ skill) และ atom ที่หนังสือเล่มนี้พูดถึง

3.4.2 สามรูปแบบของการตรึงเป็นกฎและเกณฑ์การเลือก

การตรึงเป็นกฎมีภาชนะอยู่สามแบบ การจะเก็บอะไรไว้ที่ไหนนั้นแบ่งกันด้วยความถี่ในการเรียกใช้และความเสถียร

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

3.4.3 รูปแบบที่ ① การตรวจความสอดคล้อง — บันทึกเซสชันจริง (worked transcript)

แทนที่จะอธิบายด้วยคำพูด ผมจะพาไล่ตามรูปแบบหนึ่งตั้งแต่ต้นจนจบ มันคือรูปแบบที่ถามให้อัตโนมัติว่า "ลบอันนี้ได้ไหม" ก่อนจะลบแถวว่างสักแถว ชื่อของมันคือ /check-sheet ภายในมีรายการที่ตรวจและรูปแบบผลลัพธ์ตรึงเอาไว้

สินทรัพย์ที่ใช้เป็นฐานอยู่ในบันทึกการทำงานจากการวัดจริงที่ฝังไว้ทั่วทั้งเล่ม การป้อนข้อมูลเป็นไปตามหลัก schema-first (atom data_entry_schema_first) ลำดับการป้อนคือ ชีต $스키마 → Enum/*.proto (Export ด้วย VBA (ภาษามาโครของ Excel)) → csv และสิ่งที่เป็นต้นฉบับจริงไม่ใช่เอกสาร schema แต่เป็นผลลัพธ์ JSON ที่ออกมาจริง (atom json_over_schema_doc_as_source_of_truth) การตรวจความสอดคล้องก็คือการยกหลักสองข้อนี้มาเป็นกฎการตรวจตรง ๆ นั่นเอง

setup — ส่วนในของคำสั่งที่ตรึงไว้

เมื่อกาง /check-sheet ออก ภายในมีเนื้อพรอมต์แบบนี้อยู่ นี่คือส่วนที่ไม่ต้องพิมพ์ด้วยมือทุกครั้ง

บทบาท: คุณคือตัวตรวจสอบความสอดคล้องของชีตข้อมูลเกม

ชีตที่จะตรวจ: {{sheet_name}}
schema ที่อ้างอิงได้: ชีต $스키마 (ชนิด·ช่วงค่า·เป้าหมาย FK ของแต่ละคอลัมน์)
ต้นฉบับจริงที่อ้างอิงได้: export JSON ของชีตเดียวกัน (สำคัญกว่าเอกสาร schema)

รายการที่ตรวจ (ตามลำดับนี้):
1. ความถูกต้องของ foreign key — ค่าในคอลัมน์ FK มีอยู่จริงในชีตเป้าหมายที่อ้างอิงหรือไม่
2. การละเมิดช่วงค่า — ค่าที่หลุดออกนอก min/max ที่นิยามไว้ใน $스키마
3. คอลัมน์ที่จำเป็นแต่ขาดหาย — แถวที่คอลัมน์ required=true ว่างเปล่า
4. PK ซ้ำ — PK เดียวกันมีตั้งแต่สองรายการขึ้นไป

รูปแบบผลลัพธ์ (ต้องเป็นตารางนี้เท่านั้น):
| # | แถว | คอลัมน์ | ชนิดการละเมิด | ค่าปัจจุบัน | ตัวเลือกการแก้ไข | ความมั่นใจ |

กฎ:
- ตัวเลือกการแก้ไขเป็นแค่ข้อเสนอ ห้ามแก้ชีตโดยตรงเด็ดขาด
- ความมั่นใจให้เลือกหนึ่งในสาม สูง/กลาง/ต่ำ ถ้าเป็นการเดาให้ระบุต่ำ
- ถ้าไม่มีการละเมิด ให้แสดงผลแค่ "ละเมิด 0 รายการ" แล้วจบ

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

prompt — บรรทัดเดียวที่คนพิมพ์จริง

/check-sheet skill_table

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

ผลลัพธ์ดิบของ Claude

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

นี่คือผลการตรวจความสอดคล้องของ skill_table พบการละเมิดทั้งหมด 4 รายการ

| # | แถว | คอลัมน์      | ชนิดการละเมิด | ค่าปัจจุบัน | ตัวเลือกการแก้ไข            | ความมั่นใจ |
|---|-----|------------|------------|--------|----------------------|------|
| 1 | 142 | buff_id    | ละเมิด FK   | 9007   | 9070 (น่าจะพิมพ์ผิด 1 ตัว) | กลาง   |
| 2 | 142 | buff_id    | ละเมิด FK   | 9007   | 9012 (ชื่อ "맹독" คล้ายกัน) | ต่ำ   |
| 3 | 88  | cooldown   | ละเมิดช่วงค่า | -1     | 0 (ติดลบไม่ได้)         | สูง   |
| 4 | 215 | combo_next | จำเป็นแต่ขาด | (ว่าง)  | ขอพักการตัดสิน          | ต่ำ   |

ขอเสริมข้อสังเกตบางประการ

- รายการ 1 และ 2 เป็นตัวเลือกที่ต่างกันสำหรับคอลัมน์เดียวกันของแถวเดียวกัน (142)
  ID ที่ชื่อ 9007 ไม่มีอยู่ในชีต buff ส่วน 9070 ต่างกันแค่ตัวเลขหลักเดียว
  จึงมีความเป็นไปได้ว่าพิมพ์ผิด และ 9012 มีชื่อ "맹독" คล้ายกัน จึงนำมาเป็น
  ตัวเลือก ทั้งคู่มีความมั่นใจต่ำ คนต้องเป็นผู้เลือกเอง

- รายการ 4 (แถว 215 คอลัมน์ combo_next ว่าง) นั้นกำกวม ใน $스키마 ตั้งไว้เป็น
  required=true แต่เมื่อดู export JSON พบว่าคอลัมน์นี้มีแถวที่ว่างอีก 12 แถว
  อาจเป็นไปได้ว่าเอกสารกำหนดสเปกไม่ใช่ฉบับล่าสุด หรือมีกฎว่า "สกิลปิดท้าย
  คอมโบจะเว้น combo_next ว่างไว้" แต่ยังไม่ได้สะท้อนลงในเอกสารกำหนดสเปก
  ผมไม่สามารถฟันธงได้ จึงพักไว้เป็น "ขอพักการตัดสิน"

- ถ้าต้องการรันการตรวจช่วงค่าเพิ่มนอกจาก cooldown ต้องตรวจ min/max ของ
  คอลัมน์อื่นใน $스키마 แต่ในข้อมูลที่ผมได้รับ บางส่วนของคอลัมน์ range_check
  ว่างเปล่าอยู่ ผมจึงไม่สามารถตรวจคอลัมน์ cast_time ได้

ที่ผลลัพธ์นี้เป็นผลลัพธ์ที่ดี ไม่ใช่เพราะมันเรียบร้อย แต่เพราะมันตรงไปตรงมา มันไม่ได้ฟันธงรายการ 4 ว่า "จำเป็นก็ต้องเติม" แต่แสดงความสงสัยตัวเองว่า "เอกสารกำหนดสเปกอาจไม่ใช่ฉบับล่าสุด" และยังสารภาพข้อจำกัดว่ามองคอลัมน์ cast_time ไม่ได้ ถ้า AI มั่นอกมั่นใจบอกว่ารายการ 4 ให้ "เติม 0" นั่นอาจเป็นคำตอบผิดที่ทำให้สกิลปิดท้ายคอมโบพังได้

verify — การตรวจสอบและการยับยั้งของมนุษย์

ตอนนี้คนตัดสินทีละบรรทัด การที่การตรวจสอบมาพร้อมกันโดยอัตโนมัติ หมายความว่าตารางนี้ออกมาเองโดยอัตโนมัติ ไม่ได้หมายความว่าคนไม่ดู

• รายการ 3 (cooldown -1 → 0): รับ ความมั่นใจสูง cooldown ติดลบเป็นความผิดพลาดในการป้อนข้อมูลที่ชัดเจน แก้ทันที
• รายการ 1·2 (buff_id 9007): พัก ทั้งคู่ความมั่นใจต่ำ จะเปิดชีต buff โดยตรงเพื่อตรวจสอบ ID จริงของบัฟตระกูล "맹독" ไม่รับตัวเลือกของ AI ทั้งสอง
• รายการ 4 (combo_next ว่าง): ยับยั้ง สิ่งที่ AI สงสัยนั้นถูกต้อง สกิลนี้เป็นตัวปิดท้ายคอมโบ การที่ combo_next ว่างจึงเป็นเรื่องปกติ ไม่ใช่การละเมิด ยับยั้งไป และนี่เป็นปัญหาฝั่งเอกสารกำหนดสเปก

รายการ 4 ตัวสุดท้ายคือหัวใจ ในจุดที่ถ้าเชื่อผลลัพธ์ของ AI ไปดื้อ ๆ ก็จะทำให้ข้อมูลที่ดี ๆ พังเสียหาย การยับยั้งของมนุษย์ได้ทำงาน ในขณะเดียวกันรายการ 4 ก็เผยให้เห็นความบกพร่องของกฎการตรวจเองด้วย นั่นคือ required=true ในเอกสารกำหนดสเปกนั้นผิด

การร้องขอใหม่ — การยับยั้งแก้ไขกฎ

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

รายการ 4 ไม่ใช่การละเมิด เพราะสกิลที่ combo_finisher=true จะเว้น combo_next
ว่างไว้เป็นเรื่องปกติ ช่วยเพิ่มกฎข้อยกเว้นนี้ลงในรายการที่ตรวจด้วย ต่อจากนี้
อย่าจับว่าแถว finisher ที่ combo_next ว่างเป็นการละเมิด และรายการที่ดูเหมือน
นิยาม required ในเอกสารกำหนดสเปกผิด ให้แยกออกมาเป็นหัวข้อ "สงสัยเอกสารสเปก" แล้วแจ้งต่างหาก

เข้าใจแล้ว ผมจะสะท้อนข้อยกเว้นนี้ลงในกฎการตรวจของ /check-sheet

กฎที่เพิ่ม:
- ตอนตรวจ combo_next ว่าจำเป็นหรือไม่ ให้ตรวจค่า combo_finisher ของแถวเดียวกันก่อน
  ถ้า combo_finisher=true ให้ถือว่า combo_next ว่างเป็นเรื่องปกติ (ยกเว้นจากการละเมิด)

หัวข้อที่ตั้งใหม่:
- "สงสัยเอกสารสเปก" — เมื่อการกระจายตัวจริงใน export JSON ขัดกับนิยามใน $스키마
  ให้แยกออกมาเป็นตัวเลือกที่ต้องแก้เอกสารกำหนดสเปก ไม่ใช่แก้ข้อมูล แล้วรายงาน
  (ตามหลักที่ว่าต้นฉบับจริงคือ JSON หากข้อมูลส่วนใหญ่ขัดกับเอกสารกำหนดสเปก
   ก็ให้สงสัยฝั่งเอกสารกำหนดสเปก)

ต้องการให้บันทึกการเปลี่ยนแปลงนี้ลงใน atom นิยามคำสั่ง /check-sheet หรือไม่

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

3.4.4 รูปแบบที่ ② การดึงขอบเขตผลกระทบจากการเปลี่ยนแปลง — บันทึกเซสชันจริง (worked transcript)

รูปแบบที่สองคือการกำจัดสองชั่วโมงในฉากเปิดเรื่องนั้น ก่อนจะเปลี่ยนแถวหนึ่ง หรือการตัดสินใจหนึ่ง ให้ถามก่อนว่า "มันจะลามไปถึงไหน" ชื่อของมันคือ /impact แผนภาพความสัมพันธ์ที่สร้างไว้ในหัวข้อ 3.3 (HTML ความสัมพันธ์ FK ที่ gen_relation_map.py ดึงออกมา) คือเชื้อเพลิงของรูปแบบนี้

setup — เส้นทางการค้นหาที่ตรึงไว้

ภายใน /impact มีการตรึง "ต้องไปค้นที่ไหนถึงจะหาผลกระทบได้ครบไม่ตกหล่น" ไว้สี่ทาง

บทบาท: คุณคือตัวดึงขอบเขตผลกระทบจากการเปลี่ยนแปลง

เป้าหมายที่เปลี่ยน: {{target}}  (อย่างใดอย่างหนึ่งจาก ชื่อชีต·คอลัมน์·atom_id·การตัดสินใจเชิงระบบ)

เส้นทางการค้นหา (ต้องเดินครบทั้งสี่):
1. inbound ของแผนภาพความสัมพันธ์ — ในผลลัพธ์ของ gen_relation_map.py ชีตที่อ้างอิง
   {{target}} เป็น FK (ลูกศรที่ชี้มายังชีตนี้)
2. การกล่าวถึงในเนื้อหา — เอกสารใน sources/manuscript ที่ ID·ชื่อของ {{target}}
   ปรากฏโดยตรง
3. ความสัมพันธ์ affects ของ atom — atom ที่เชื่อมกับ {{target}} ด้วย affects
4. การอ้างอิงย้อนกลับ — โน้ตที่ชี้ไปยัง {{target}} ด้วย [[wikilink]]

รูปแบบผลลัพธ์:
| ชนิด | ชื่อ | หลักฐานการเชื่อมโยง | ความแรงของผลกระทบ | ผู้รับผิดชอบ |

กฎ:
- ความแรงของผลกระทบมีสามระดับ ทางตรง/ทางอ้อม/อ่อน FK ตรงคือ 'ทางตรง' การกล่าวถึงในเนื้อหาคือ 'ทางอ้อม' การคาดเดาคือ 'อ่อน'
- ถ้ากลัวตกหล่น ให้ใส่ไว้เป็นอ่อนก็ยังดี ดีกว่าทำหล่น
- ไม่จัดลำดับความสำคัญและไม่สั่งงาน ทำแค่รายการเท่านั้น

prompt

/impact buff_id=9012

ถามด้วยบรรทัดเดียวว่า "กำลังจะเปลี่ยนบัฟ 맹독 (9012) เป็นเอฟเฟกต์อื่น ตรงไหนจะกระเทือนบ้าง"

ผลลัพธ์ดิบของ Claude

นี่คือขอบเขตผลกระทบจากการเปลี่ยน buff_id=9012 (맹독) ผมค้นหาครบทั้ง 4 เส้นทางแล้ว

| ชนิด    | ชื่อ                | หลักฐานการเชื่อมโยง        | ความแรง | ผู้รับผิดชอบ |
|--------|--------------------|----------------------|---------|----------|
| ชีต    | skill_table         | อ้างอิง buff_id FK ตรง  | ทางตรง   | teammate_a |
| ชีต    | monster_drop        | อ้างอิง reward_buff FK   | ทางตรง   | teammate_b |
| ชีต    | set_item_effect     | อ้างอิง proc_buff FK     | ทางตรง   | teammate_a |
| เอกสาร  | 독계열_밸런스_노트.md  | กล่าวถึง "9012" ในเนื้อหาโดยตรง | ทางอ้อม | (ผู้เขียน) |
| atom    | poison_stack_rule   | affects: 9012          | ทางอ้อม | (ผู้เขียน) |
| โน้ต    | 상태이상_설계.md       | อ้างอิงย้อน [[맹독]]      | อ่อน    | (ผู้เขียน) |

ขอเสริมบางประการ

- แถวใน skill_table ที่อ้างอิง 9012 มี 3 แถว (สกิลคลาสนักลอบสังหาร)
  ถ้าเปลี่ยน เอฟเฟกต์จริงของสกิล 3 ตัวนี้จะเปลี่ยนไป เป็นผลกระทบที่แรงที่สุด

- reward_buff ของ monster_drop ผมมั่นใจค่อนข้างอ่อน เพราะชื่อคอลัมน์คือ
  reward_buff แต่บางแถวดูเหมือนมีค่าที่ชี้ไปยัง item ไม่ใช่ buff ปนอยู่
  ผมแนะนำให้เปิดชีตนี้ตรวจสอบด้วยตัวเองสักครั้ง

- "독계열_밸런스_노트.md" แค่กล่าวถึง 9012 เป็นข้อความ ไม่ใช่ FK ผมจึงจัดไว้
  เป็นทางอ้อม แต่เนื่องจากเป็นเอกสารที่เขียนเจตนาด้านบาลานซ์ไว้ ผลกระทบจริง
  อาจแรงก็ได้ โปรดระวังว่าความแรง (ทางอ้อม) กับความสำคัญอาจไม่ตรงกัน

- set_item_effect ใช้ 9012 เป็น proc_buff ในไอเทมเซต 4 ชนิด ถ้าเอา 맹독 ออก
  คอนเซปต์ของเซตเหล่านี้จะเปลี่ยนไป

verify — การตรวจสอบและการยับยั้งของมนุษย์

• skill_table (ทางตรง, ทีมเมต A): ยืนยัน สกิลนักลอบสังหาร 3 ตัวได้รับผลกระทบโดยตรง ต้องแจ้งทีมเมต A รับ
• monster_drop (ทางตรง): รายการที่ AI สงสัยตัวเอง เปิดชีตตรวจสอบโดยตรง ผล: คอลัมน์ reward_buff มี item ID ปนอยู่จริง และแถวที่อ้างอิง 9012 จริง ๆ มีแค่ 1 แถว การสารภาพว่า "มั่นใจอ่อน" ของ AI นั้นแม่นยำ ปรับลด ความแรงจากทางตรง→ทางอ้อม
• set_item_effect (ทางตรง, ทีมเมต A): ยืนยัน เซต 4 ชนิดได้รับผลกระทบ รับ
• 상태이상_설계.md (อ่อน): เป็นแค่การอ้างอิงย้อน ไม่มีผลต่อเนื้อหา คงไว้ในรายการแต่ตัดออกจากเป้าหมายงาน

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

การร้องขอใหม่ — จากการดึงข้อมูลสู่การแบ่งปัน

เมื่อรายการผ่านการตรวจสอบแล้ว มือถัดไปคือการส่งต่อสิ่งนี้ให้คน

ช่วยจัดกลุ่มตามผู้รับผิดชอบที่ได้รับผลกระทบโดยตรง แล้วร่างเมโมแบ่งปันสั้น ๆ
สำหรับส่งให้ teammate_a / teammate_b ในรูปแบบ "กำลังพิจารณาเปลี่ยน 9012 맹독
เป็น X ชีตของคุณได้รับผลกระทบ N แถว" การตัดสินใจยังไม่เคาะ ดังนั้นให้เป็นโทน
ขอความเห็น ไม่ใช่การแจ้งให้ทราบ

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

[ถึง teammate_a]
กำลังพิจารณาแนวทางเปลี่ยนบัฟ 맹독 (9012) เป็นเอฟเฟกต์อื่น ยังไม่เคาะ
อยากฟังความเห็นก่อน ขอบเขตผลกระทบ:
- skill_table: แถวสกิลนักลอบสังหาร 3 แถวอ้างอิง 9012 (ผลกระทบทางตรง)
- set_item_effect: ไอเทมเซต 4 ชนิดใช้ 9012 เป็น proc_buff
ถ้าเปลี่ยน คอนเซปต์ของสกิล·เซตเหล่านี้จะเปลี่ยนไป ถ้ามีความเห็นค้านหรือเสริม
ช่วยแจ้งภายในสัปดาห์นี้

[ถึง teammate_b]
ขอรบกวนตรวจสอบเรื่อง reward_buff ของ monster_drop กำลังพิจารณาเปลี่ยนบัฟ
맹독 (9012) อยู่ และดูเหมือนแถวที่ได้รับผลกระทบมี 1 แถว (เนื่องจากในคอลัมน์
reward_buff มี item ID ปนอยู่ ตอนแรกจึงดูเหมือนมีมากกว่านั้น) ช่วยตรวจสอบให้
หน่อยได้ไหมว่าตรง 1 แถวนี้ถูกต้องจริงหรือไม่

เมโมทั้งสองผมจัดเป็น "กำลังพิจารณา·ขอความเห็น" และไม่ได้ใส่ถ้อยคำแจ้งแบบฟันธง ก่อนส่งคุณต้องเติมเอฟเฟกต์ตัวเลือกที่จะเปลี่ยน (ตำแหน่ง X) ด้วย

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

3.4.5 โครงกระดูกที่สองรูปแบบใช้ร่วมกัน

ทรานสคริปต์สองชุดข้างต้นเดินตามโครงกระดูกเดียวกัน รูปแบบอื่นทั้งหมดก็วางอยู่บนโครงกระดูกนี้

flowchart LR
    A[คำสั่งที่ตรึงไว้
รายการตรวจ·รูปแบบผลลัพธ์·ข้อห้าม] --> B[คน: เรียกหนึ่งบรรทัด
ส่งแค่เป้าหมาย]
    B --> C[Claude: ผลลัพธ์ดิบ
ตัวเลือก+ความมั่นใจ+สงสัยตัวเอง]
    C --> D{คนตรวจสอบ}
    D -->|รับ| E[นำไปใช้]
    D -->|แก้ไข| F[ปรับความแรง·ค่า]
    D -->|ยับยั้ง| G[พบความบกพร่องของกฎ]
    G --> H[อัปเดต atom นิยามคำสั่ง]
    H -.สะท้อนในการเรียกครั้งถัดไป.-> A
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    classDef fail fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    class A,H data
    class B,D,F human
    class C ai
    class E pass
    class G fail

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

มือของคนเหลืออยู่สามจุด การเรียก (เลือกเป้าหมาย) การตรวจสอบ (รับ·แก้ไข·ยับยั้ง) และการปรับปรุงกฎ (การป้อนกลับของการยับยั้ง) AI ทำแค่งานเสนอตัวเลือกอยู่ระหว่างนั้นเท่านั้น

3.4.6 รูปแบบที่เหลือ — การแปรผันของโครงกระดูกเดียวกัน

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

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

3.4.7 ห้าหลักของการดำเนินงานและจุดบรรจบ

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

สุดท้าย จุดบรรจบหนึ่ง ในโปรเจกต์ MMORPG หนึ่งที่ผู้เขียนเคยดำเนินงาน คำสั่งสแลชที่อยู่อย่างเสถียรในการออกแบบระบบบรรจบลงที่ราว 12 ตัวเมื่อเวลาผ่านไป นี่ไม่ใช่มาตรฐานสาธารณะ แต่เป็นค่าจากการสังเกตของโปรเจกต์หนึ่ง (ประสบการณ์ของผู้เขียน ยังไม่ได้ตรวจสอบ) แต่ทิศทางนั้นชัดเจน คำสั่งไม่ใช่สิ่งที่จะเพิ่มไปเรื่อย ๆ ไม่มีที่สิ้นสุด แต่จะหยุดที่จำนวนที่จดจำในหัวไหว โดยเพิ่มและลดเดือนละ 1–2 ตัว ลิ้นชักที่ติดป้าย 100 ใบก็เหมือนกับลิ้นชักที่ไม่มีป้าย

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

3.4.8 ปิดท้าย Part 3

ในหัวข้อ 3.1 เราวางพิกัด Layer ของการออกแบบระบบ ในหัวข้อ 3.2 วาง schema ในหัวข้อ 3.3 วางแผนภาพความสัมพันธ์ และในหัวข้อ 3.4 วางพรอมต์ที่ให้ AI ช่วยไว้บนนั้น หนึ่งสัปดาห์ของนักออกแบบระบบที่ผ่านสี่บทนี้จะเปลี่ยนไปแบบนี้

flowchart LR
    M[จันทร์: สังเคราะห์ร่าง GDD
4h → 1h] --> T[อังคาร: ตรวจความสอดคล้อง
ครึ่งวัน → 5 นาที]
    T --> W[พุธ: ออนบอร์ดดิ้ง, แผนภาพความสัมพันธ์หนึ่งใบ
ประชุม 5 ครั้ง → 1 ใบ]
    W --> Th[พฤหัส: ดึงขอบเขตผลกระทบ
ประชุม 1h → 10 นาที]
    Th --> F[ศุกร์: จัดประเภทการทบทวนอัตโนมัติ
ทำมือ → อิงข้อมูล]
    F --> R[นำเวลาที่ลดลง
กลับไปลงทุนในการออกแบบ·ตรวจทาน·ประสบการณ์ผู้เล่น]
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class M,T,W,Th,F ai
    class R pass

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

Part 4 ถัดไปคือการออกแบบการต่อสู้ ในฐานะพี่น้องที่ใกล้ชิดที่สุดของการออกแบบระบบ เครื่องมือและรูปแบบของ 3.1\~3.4 จะข้ามไปใช้ได้ตรง ๆ

สรุปประเด็นสำคัญของบท

• วงจรการตรึงพรอมต์ด้นสดให้เป็นคำสั่งสแลช·atom·เทมเพลต คือจุดที่เก็บเกี่ยวคุณค่าได้มากที่สุดของการมี AI ช่วย
• ทุกรูปแบบเดินตามโครงกระดูกเดียวกัน เรียกหนึ่งบรรทัด → ผลลัพธ์ดิบ → คนตรวจสอบ·ยับยั้ง → ป้อนกลับสู่กฎ
• AI เสนอตัวเลือก ส่วนมือสุดท้ายของการรับ·แก้ไข·ยับยั้งยังคงอยู่ฝั่งมนุษย์จนถึงที่สุด

ลองทำดู

setup. เลือกงานตรวจหนึ่งอย่างที่คุณทำซ้ำทุกสัปดาห์ (เช่น ตรวจความสอดคล้องของชีต) เขียนรายการที่ตรวจ 4 ข้อและรูปแบบตารางผลลัพธ์ของงานนั้น แล้วตรึงเป็นคำสั่งสแลชหนึ่งตัว อย่าลืมใส่กฎสามบรรทัด ("ห้ามแก้โดยตรง / ให้คะแนนความมั่นใจ / การเดาให้สารภาพ") ลงในเนื้อคำสั่งให้ครบ

prompt. เรียกโดยส่งแค่เป้าหมายหนึ่งบรรทัด

/check-sheet skill_table

verify. ตัดสินตารางที่ย้อนกลับมาทีละแถวว่ารับ·แก้ไข·ยับยั้ง ถ้ามีการยับยั้งออกมา นั่นไม่ใช่เรื่องโชค แต่เป็นความบกพร่องของกฎ ส่งบรรทัดที่เพิ่มข้อยกเว้นนั้นลงในนิยามคำสั่งกลับไปอีกครั้ง เพื่อให้การเรียกครั้งถัดไปไม่ต้องกรองความผิดพลาดเดียวกันซ้ำสองครั้ง

ฉบับย่อสำหรับคนเดียว

ถ้าไม่มีทั้งทีมและระบบ atom แทนที่จะใช้คำสั่งสแลช ให้วางบล็อกข้อความหนึ่งบล็อกไว้ในแอปจดบันทึก ตั้งชื่อว่า "พรอมต์ตรวจชีต" เนื้อหาคือรายการที่ตรวจ 4 ข้อ + กฎ 3 บรรทัดจาก setup ข้างต้น ทุกครั้งที่จะตรวจ ก็คัดลอกบล็อกนี้แล้วเปลี่ยนแค่ชื่อชีตก่อนวางลงให้ AI เมื่อมีเรื่องที่ต้องยับยั้ง ก็เพิ่มข้อยกเว้นหนึ่งบรรทัดลงในบล็อกบันทึกนั้นด้วยตัวเอง ไม่ว่าเครื่องมือจะเป็นคำสั่งสแลชหรือบันทึกหนึ่งหน้า วงจร (ตรึงเป็นกฎ → เรียก → ตรวจสอบ·ยับยั้ง → อัปเดตกฎ) ก็หมุนเหมือนกัน

ส่วนที่ 4 · Combat Design

4.1 นักออกแบบการต่อสู้กับ Layer — สัมผัสของการตีอยู่ในช่องไหน

เป้าหมายการเรียนรู้ของบทนี้ (ระดับความยาก 🟡 ภาคปฏิบัติ · ความรู้พื้นฐานที่ต้องมี: การบวกลบคูณหาร·การคำนวณในตาราง): สามารถแยกย่อยคำคุณศัพท์เชิงนามธรรมอย่าง "สัมผัสของการตี" ออกมาเป็นสัญญาณที่วัดได้ และระบุเป็นพิกัดได้ว่าผลงานทั้งห้าอย่างของนักออกแบบการต่อสู้นั่งอยู่ในช่องไหนของ Layer

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

"อืม… ทำไมสัมผัสของการตีมันอ่อนไปนิดนะ"

คนข้าง ๆ พยักหน้า "ใช่ครับ จืด ๆ ไปหน่อย"

โปรแกรมเมอร์ถาม "ต้องแก้ตรงไหนอย่างไรครับ"

ความเงียบ ในห้าคนที่อยู่ในห้องประชุมนี้ ไม่มีใครตอบคำถามนั้นเป็นตัวเลขได้ "สัมผัสของการตีมันอ่อน" เป็นสิ่งที่ทั้งห้าคนรู้สึกได้ แต่คนที่พูดได้ว่า "ปรับ hit stop จาก 3 เฟรมเป็น 5 เฟรม" กลับไม่มีสักคน การประชุมดำเนินไป 40 นาที โดยโยนคำคุณศัพท์อย่าง "ให้หนักแน่นกว่านี้อีกหน่อย" "อิมแพกต์ยังไม่พอ" ไปมา แล้วก็จบลงด้วย "เอาเป็นว่าไว้ดูกันใหม่ในบิลด์หน้านะ"

ฉากนี้บีบอัดปัญหาทั้งหมดของงานออกแบบการต่อสู้ไว้ มันเป็นแขนงที่ผู้เล่นสัมผัสได้โดยตรงที่สุด แต่พอจะถ่ายทอดสัมผัสนั้นออกมาเป็นคำพูด ก็เหลือแค่คำคุณศัพท์ คำคุณศัพท์วัดไม่ได้ และเมื่อวัดไม่ได้ ก็ปรับไม่ได้ งานแรกของนักออกแบบการต่อสู้คือการดึงคำคุณศัพท์เหล่านี้ลงมาเป็นตัวเลข

บทนี้กำหนดว่าตัวเลขนั้นเข้าไปอยู่ในช่องไหน ผลงานทั้งห้าอย่างที่นักออกแบบการต่อสู้สร้างขึ้น แต่ละอย่างนั่งอยู่ที่ตรงไหนของ Layer และทำไมพิกัดนั้นจึงกลายเป็นเงื่อนไขเบื้องต้นของการทำงานอัตโนมัติ เครื่องมือภาคปฏิบัติของ 4.2·4.3·4.4 ล้วนขับเคลื่อนอยู่บนพิกัดนี้

สรุปหนึ่งบรรทัดสำหรับผู้ที่ไม่ได้อยู่ในสายงานนี้ ในส่วนนี้คุณไม่จำเป็นต้องท่องค่าตัวเลขการต่อสู้หรือหน่วยเฟรม สิ่งเดียวที่คุณควรนำติดตัวไปคือสิ่งนี้ — "คำขอที่โยนกันไปมาด้วยคำคุณศัพท์ ทั้งวัดและปรับไม่ได้" แนวคิดที่ว่าทันทีที่ดึง "ให้หนักแน่นกว่านี้อีกหน่อย" ลงมาเป็น "ปรับอะไรให้เป็นเท่าไร" การทำงานร่วมกันก็เดินหน้าไปได้ ใช้ได้เหมือนกันกับฟีดแบ็กคลุมเครือของงานสายไหนก็ตามนอกวงการเกม ผลงานทั้งห้าอย่างใน 4.1.1 คุณอ่านผ่าน ๆ ได้ แล้วกุมเอาเพียงสิ่งเดียวนี้ไว้ในมือก็เพียงพอ

4.1.1 ห้าสิ่งที่อยู่บนโต๊ะทำงานของนักออกแบบการต่อสู้

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

ก้อนที่หนึ่ง สเปก Look & Feel ของการต่อสู้ เป็นเอกสารที่แปลความเชิงนามธรรมอย่างสัมผัสของการตี·การตอบสนอง·น้ำหนัก ให้เป็นค่าตัวเลขที่วัดได้ นี่เป็นผลงานที่ยากที่สุดของแขนงนี้ และเป็นเกณฑ์ในการประเมินอีกสี่อย่างที่เหลือ

Look & Feel ยังแยกย่อยออกได้อีกเป็นสี่สัญญาณ

• Hit Timing — นับจากจังหวะที่กดปุ่มอินพุต ไปจนถึงตอนที่ปฏิกิริยาทางสายตา·เสียงปรากฏบนหน้าจอ ใช้เวลากี่ ms
• Hit Stop — ในเสี้ยววินาทีที่การตีเข้าเป้า หน้าจอหยุดนิ่งกี่เฟรม (โดยทั่วไป 1\~6 เฟรม)
• Camera Shake — แอมพลิจูด·ระยะเวลา·เส้นโค้งการลดทอน
• การซิงก์เอฟเฟกต์ — VFX·SFX·ปฏิกิริยา UI ถูกทริกเกอร์ในเฟรมเดียวกันหรือไม่

ถ้าไม่มีสเปกนี้ ฉากในห้องประชุมก็จะวนซ้ำ ถ้ามีสเปก ก็จะมีคำสั่งปรับออกมาว่า "Hit Stop 3→5 เฟรม แอมพลิจูด Camera Shake +20%"

ก้อนที่สอง ระบบสกิล·Combo·Cancel เป็นกฎที่อินพุตถูกแปลงเป็นแอ็กชัน

• ลำดับการใช้สกิล: อินพุต → ร่าย (cast) → เริ่มทำงาน → ดีเลย์ตอนจบ (recovery)
• กฎ Combo: หลังจากสกิลไหนต่อด้วยสกิลไหน และโบนัสคืออะไร
• กฎ Cancel: ระหว่างแอ็กชันใดสามารถ Cancel ไปเป็นแอ็กชันใดได้บ้าง
• Input Queue: หน้าต่างเวลา (ms) ที่รับอินพุตถัดไประหว่างแอ็กชันมีค่าเท่าไร

ก้อนที่สาม AI ของตัวละคร·มอนสเตอร์ ลอจิกพฤติกรรมของ NPC — Behavior Tree (ต่อไปเรียก BT) สเตตแมชชีน (FSM (Finite State Machine, เครื่องสถานะจำกัด)/HFSM) ตารางการตัดสินใจ (decision table) แพตเทิร์นพฤติกรรมมอนสเตอร์ การเปลี่ยนเฟสบอส การทำงานร่วมกันของ NPC เพื่อน การจำลองฝูง (flocking) ล้วนอยู่ในก้อนนี้

ก้อนที่สี่ สูตรดาเมจ·ทรัพยากร·Cooldown เป็นคณิตศาสตร์ที่ตัวเลือกของผู้เล่นถูกแปลงเป็นผลลัพธ์ ค่าสัมประสิทธิ์ดาเมจ·การลดทอนจากการป้องกัน·คริติคอล·การปรับตามธาตุ การบริโภค·เส้นโค้งการฟื้นคืนของทรัพยากร (MP/พลังภายใน/สแตมินา) การกระจาย Cooldown

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

จุดสำคัญตรงนี้คือ ห้าสิ่งนี้มาเจอกันบนโต๊ะเดียวกัน ถ้ากฎ Combo (ก้อนที่สอง) เปลี่ยน DPS ของสูตรดาเมจ (ก้อนที่สี่) ก็เปลี่ยน และนั่นก็ไปเปลี่ยนน้ำหนักที่รู้สึกได้ของ Look & Feel (ก้อนที่หนึ่ง) อีกที ถ้าไม่ระบุไว้ชัดว่าผลงานไหนเป็นอินพุตของผลงานไหน การเปลี่ยนเพียงครั้งเดียวก็สั่นสะเทือนถึงห้าจุด ด้วยเหตุนี้จึงต้องมีพิกัด

4.1.2 ผลงานทั้งห้าอย่างนั่งอยู่ในช่องไหนของ Layer

เราจะวางผลงานการต่อสู้ทั้งห้าลงบนพิกัด L0\~L4 ที่จับไว้ใน 2.3 การแมปนี้คือกระดูกสันหลังของบทนี้

flowchart TD
    L0["L0 · วิสัยทัศน์
'การต่อสู้แบบแอ็กชันที่สัมผัสของการตียังมีชีวิต'"]
    L1["L1 · โครงสร้างระบบ
โครงสร้าง Combo·Cancel / สเปก Look&Feel / โครงคลาส"]
    L2["L2 · การไหลของเนื้อหา
เส้นโค้งกลุ่มศัตรูแต่ละบท / ลำดับการปลดล็อกสกิล"]
    L3["L3 · ชีตข้อมูล
ค่าสัมประสิทธิ์ดาเมจ·ค่า Cooldown·การบริโภคทรัพยากร"]
    L4["L4 · การวัดในบิลด์
DPS ที่วัดจริง / เส้นทาง Combo จริง / ฟีดแบ็กผู้เล่น"]

    L0 -->|"รับมา"| L1
    L1 -->|"โครงกำหนดการไหล"| L2
    L1 -->|"สเปกเป็นเกณฑ์ของค่าตัวเลข"| L3
    L2 --> L3
    L3 -->|"สะท้อนลงบิลด์"| L4
    L4 -.->|"วัด → ฟีดแบ็กแก้สเปก"| L1
    L4 -.->|"ค่าผิดปกติ → ปรับชีต"| L3

    classDef vision fill:#2d3748,stroke:#1a202c,color:#fff
    classDef build fill:#c05621,stroke:#7b341e,color:#fff
    class L0 vision
    class L4 build

หากเรียบเรียงใหม่เป็นตารางจะได้ดังนี้

ลักษณะเด่นของงานออกแบบการต่อสู้คือ สัดส่วน L4 ใหญ่กว่าแขนงอื่น ๆ สำหรับงานออกแบบเนื้อเรื่อง สเปก L1 แทบจะเท่ากับฉบับสุดท้ายในตัว แต่การต่อสู้ต่างออกไป "สัมผัสของการตีดี" เป็นพื้นที่ที่ต้องลงมือตีในบิลด์จริงและดูหน้าจอเองเท่านั้นจึงจะรู้ได้ แม้จะเขียนในสเปกว่า "Hit Stop 5 เฟรม" แต่ว่ามันรู้สึกหนักแน่นจริงหรือไม่ จะยืนยันได้แค่ที่ L4 เท่านั้น ด้วยเหตุนี้เครื่องมือจำลอง (simulation) และการวัดอัตโนมัติจึงสร้างคุณค่าได้มากที่สุดในแขนงนี้ (4.4)

อย่างไรก็ตาม การที่ L4 ใหญ่ไม่ได้แปลว่า L1 สำคัญน้อยลง ดูลูกศรเส้นประให้ดี ค่าที่วัดได้ของ L4 จะป้อนกลับเข้าสู่สเปก L1 ถ้าไม่มีสเปก ค่าที่วัดได้ก็จะสูญเสีย "เกณฑ์ในการเปรียบเทียบ" ต้องมีสเปก 5 เฟรมก่อน จึงจะมีคำวินิจฉัยออกมาว่า "วัดจริงได้ 4 เฟรม ขาดไป 1 เฟรม" วัฏจักร สเปก → บิลด์ → วัด → แก้สเปก เดินผ่านทั้งห้า Layer ครบ นักออกแบบการต่อสู้เป็นตำแหน่งที่วางมือไว้บนวัฏจักรนี้ทั้งกระบวนการ เป็นที่นั่งซึ่งมี Layer หมุนพร้อมกันมากที่สุดบนโต๊ะเดียว

4.1.3 เปลี่ยนคำคุณศัพท์ให้เป็นตัวเลข — กระดูกสันหลังหนึ่งของงานจริง

ทฤษฎีเชิงนามธรรมจบลงตรงนี้ ทีนี้จะกลับไปที่ฉากในห้องประชุม แล้วดูกระบวนการดึง "สัมผัสของการตีอ่อน" ลงมาเป็นตัวเลขจริง ๆ ผ่านบันทึกเซสชันจริง (worked transcript — บันทึกการทำงานจริงกับ AI ทั้งพรอมต์และผลลัพธ์) เครื่องมือคือ LLM เพียงตัวเดียว ผลลัพธ์ไม่ได้ขัดเกลา และส่วนที่คนปฏิเสธก็เก็บไว้ตามเดิม

ผู้เขียนจะเรียบเรียงใหม่จากการไหลจริงของการกำหนดสเปก Look & Feel ของสกิลระยะประชิดใหม่หนึ่งตัว ใน TF การต่อสู้ของโปรเจกต์ MMORPG หนึ่ง (ต่อไปเรียก "โปรเจกต์ A") ที่ผู้เขียนบริหารในฐานะ Director

พรอมต์ (เต็ม)

ช่วยเปลี่ยน Look & Feel ของสกิลนี้จากคำคุณศัพท์ให้เป็นค่าตัวเลขหน่วย ms·เฟรมหน่อย
ห้าหัวข้อ ได้แก่ hit timing, hit stop, camera shake, การซิงก์เอฟเฟกต์, ดีเลย์ตอนจบ
อันไหนไม่มั่นใจ ให้เขียนกำกับว่า "ต้องตรวจสอบในเกมนี้"

สกิล: ฟันลงตรงด้วยดาบใหญ่ (heavy_overhead_slash)
เจตนา: "ฟันลงอย่างหนักแน่น ให้รู้สึกว่าศัตรูเสียหลัก"
เฟรมเรต: 60fps

ผลลัพธ์ดิบจาก Claude (ไม่สรุป·ไม่เรียบเรียง)

"ความหนักแน่น" ของการฟันลงตรงด้วยดาบใหญ่ ถูกสร้างขึ้นจาก ความยาวของ hit stop และดีเลย์ตอนจบ เป็นหลัก และจาก การลดทอนของ camera shake ขอเสนอแยกเป็นรายหัวข้อ

1) Hit Timing ยิ่งเป็นอาวุธหนัก ดีเลย์ตอนเริ่ม (startup) จากอินพุต→เริ่มทำงานยิ่งต้องยาว น้ำหนักจึงจะมีชีวิต แนะนำ 50\~80ms (3\~5 เฟรม) จากอินพุตไปจนถึงปฏิกิริยาทางสายตาแรก (ตัวละครเริ่มยกดาบขึ้น) แต่ปฏิกิริยา ทางสายตา แรก กับปฏิกิริยา การตีโดน แรก เป็นคนละอย่างกัน เวลาจนถึงตอนตีเข้าเป้าขึ้นอยู่กับความยาวของโมชัน จึงฟันธงตรงนี้ไม่ได้ — ต้องตรวจสอบด้วยความยาวโมชันของเกมนี้

2) Hit Stop เป็นตัวแปรหลักของการโจมตีหนักแน่น ถ้าการโจมตีเบาอยู่ที่ 1\~2 เฟรม การฟันลงตรงด้วยดาบใหญ่แนะนำ 4\~6 เฟรม (ราว 67\~100ms) ถ้าเกิน 6 เฟรม "ความหนักแน่น" จะข้ามไปเป็น "การกระตุก" ทำให้การตอบสนองแย่ลง

3) Camera Shake แอมพลิจูดราว 1\~2% ของความสูงหน้าจอ ระยะเวลา 0.2\~0.3 วินาที การลดทอนใช้ ease-out (อ่อนลงอย่างรวดเร็ว) มากกว่าแบบเชิงเส้น การโจมตีหนักจะเป็นธรรมชาติเมื่อเป็นเส้นโค้งที่การสั่นครั้งแรกแรงและจางหายไปอย่างรวดเร็ว

4) การซิงก์เอฟเฟกต์ VFX (เอฟเฟกต์การตี)·SFX (เสียงการตี)·hit stop ต้องถูกทริกเกอร์เหมือนกันในเฟรมที่ตีเข้าเป้าเสมอ แค่คลาดเคลื่อนไป 1\~2 เฟรมก็จะรู้สึกได้เป็น "ความจืด" ปฏิกิริยา UI (ตัวเลขดาเมจ) ช้าไป 1\~2 เฟรมไม่เป็นไร

5) ดีเลย์ตอนจบ ค่าที่ต้องจ่ายเพื่อความหนักแน่นคือดีเลย์ตอนจบที่ยาว แนะนำ 20\~30 เฟรม (333\~500ms) นับจากตีเข้าเป้าจนกลับมารับการโจมตีได้ แต่ค่านี้เปลี่ยนแปลงไปมากตามจังหวะการต่อสู้โดยรวมของเกม (แอ็กชันเร็ว vs แนวโซลที่หนักแน่นจริงจัง) — ต้องตรวจสอบที่จังหวะมาตรฐานของเกมนี้

สรุปแล้ว "ความหนักแน่น = ดีเลย์ตอนเริ่มยาว + hit stop 4\~6 เฟรม + camera shake แบบ ease-out + VFX/SFX/stop ในเฟรมเดียวกัน + ดีเลย์ตอนจบยาว" อย่างไรก็ตาม ตัวเลขข้างต้นเป็นช่วงคำแนะนำทั่วไป ส่วน น้ำหนักจริงต้องลงมือตีในบิลด์และปรับจึงจะสรุปได้

การตรวจสอบ·ปฏิเสธ·ขอใหม่ของคน

ตรงนี้นักออกแบบเกมไม่รับผลลัพธ์ทั้งก้อน เขาหยุดที่สองจุด

ปฏิเสธ 1 — แอมพลิจูด camera shake "1\~2% ของความสูงหน้าจอ" เกมนี้ให้มือถือมาก่อน บนหน้าจอเล็ก 1\~2% แทบมองไม่เห็น ทั้งยังมีปัญหาอาการเมาบนมือถืออีก นักออกแบบเกมปฏิเสธค่าแนะนำนี้ และนำหลักการของตัวเองมาใช้ว่า "บนมือถือจะเน้น hit stop แทน shake เพื่อสื่อถึงน้ำหนัก" LLM ให้แค่ทฤษฎีทั่วไป มันไม่รู้ข้อจำกัดของแพลตฟอร์มในเกมนี้

ระงับ 2 — hit stop "4\~6 เฟรม" อันนี้ไม่ใช่การปฏิเสธ แต่เป็นการพักไว้ ในแง่ช่วงค่าถือว่าถูก แต่ค่าที่แม่นยำจะกำหนดในบิลด์ด้วยสัมผัสมือ ในสเปกจะเขียนว่า "ใส่ 4 เฟรมเป็นค่าตั้งต้นลงในบิลด์ แล้วทำตัวแปร 5·6 เฟรมขึ้นมา เปรียบเทียบทั้งสามด้วยมือ"

การขอใหม่ออกไปแบบนี้

นี่เป็นโปรเจกต์ที่ให้มือถือมาก่อน ให้ลด camera shake ให้น้อยที่สุด
แล้วเขียนสเปกใหม่ในทิศทางที่ใช้ hit stop·ดีเลย์ตอนจบ·SFX สื่อถึงน้ำหนัก
ทำ hit stop เป็นสามตัวแปร 4/5/6 เฟรม เป็นตารางสำหรับเปรียบเทียบในบิลด์

ในผลลัพธ์ครั้งที่สองนี้ LLM สร้างตารางสเปกที่สะท้อนข้อจำกัดของมือถือ ตารางนั้นเข้าสู่บิลด์ และในการประชุมบิลด์ครั้งถัดมา นักออกแบบเกมพูดแทนคำคุณศัพท์ว่า "ตัวแปร 4 เฟรมเบาเกินไป เลือก 5 เฟรม" การประชุม 40 นาทีหดเหลือเป็นการตัดสินใจ 5 นาที

สิ่งที่บันทึกเซสชันนี้แสดงให้เห็น

มีสามอย่าง หนึ่ง LLM สร้างร่างแรกที่ดึงคำคุณศัพท์ลงมาเป็นช่วงตัวเลข ได้ดี — นี่ทลายความเงียบในห้องประชุม สอง LLM ไม่รู้ข้อจำกัดของเกมนี้ (มือถือ·จังหวะ·ความยาวโมชัน) — มันจึงให้แค่ค่าแนะนำทั่วไป ส่วนการปฏิเสธ·ปรับเป็นหน้าที่ของคน สาม LLM ตอกย้ำด้วยตัวเองถึงสองครั้งว่า "ต้องลงมือตีในบิลด์จึงจะสรุปได้" — แม้แต่เครื่องมือก็รู้ว่าการตัดสินขั้นสุดท้ายของน้ำหนักคือมือคนที่ L4

4.1.4 สี่ตำแหน่งที่ AI คืนค่าของการนำมาใช้

บันทึกเซสชันข้างต้นแสดงเพียงตำแหน่งเดียว (การกำหนดสเปก) ในงานออกแบบการต่อสู้ทั้งหมด ตำแหน่งที่ AI สร้างคุณค่ามีอยู่สี่แห่ง

1) การจำลอง — คุณค่าใหญ่ที่สุด คำนวณเส้นโค้ง DPS (Damage Per Second, ดาเมจต่อวินาที)·เส้นทาง Combo·การบริโภคทรัพยากรไว้ล่วงหน้าโดยไม่ต้องมีบิลด์ เร็วกว่าการสร้างบิลด์แล้ววัดด้วยมืออย่างเทียบกันไม่ได้ ใน 4.4 จะลงมือทำกับตัวจำลอง simulate_dps โดยตรง

2) การสร้างสเตตแมชชีน·BT อัตโนมัติ แปลงคำอธิบายเป็นภาษาธรรมชาติอย่าง "บอสตัวนี้จะคลั่งเมื่อพลังชีวิตต่ำกว่า 50% และระหว่างคลั่งจะใช้แพตเทิร์น 3 ทีติด" ให้เป็นไดอะแกรม BT/FSM ความแม่นยำสูง — โครงสร้างกฎเป็นพื้นที่ที่ LLM จัดการได้ดี ประหยัดเวลาในการย้ายลอจิกในหัวออกมาเป็นภาพ

3) การวิเคราะห์บันทึกจากบิลด์โดยอัตโนมัติ สกัด hit timing·อัตราความสำเร็จของ Combo·การกระจายความเสียหายออกมาจากคลิปการเล่นโดยอัตโนมัติ แต่ว่านี่เป็น ตำแหน่งที่ความยากในการ implement สูงที่สุด (จะพิจารณาอย่างตรงไปตรงมาด้านล่าง)

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

ในสี่ตำแหน่งนี้ การวิเคราะห์บันทึกจากบิลด์โดยอัตโนมัติ (3) มีระยะห่างระหว่าง "ทำได้" กับ "ทำได้ง่าย" ไกลที่สุด ในหนังสือมักเขียนกันว่า "AI ดึงทุกอย่างออกมาจากคลิปวิดีโอให้โดยอัตโนมัติ" แต่ในความเป็นจริงไม่ได้ง่ายขนาดนั้น คอมพิวเตอร์วิทัศน์ที่อิงพิกเซลในวิดีโอ, vision API สำเร็จรูป, บันทึก telemetry ในเกม — การเปรียบเทียบความแม่นยำ·ภาระในการ implement ของสามวิธีจับข้อมูลนี้ 4.4 เป็นฉบับหลัก จึงให้ไปอ้างอิงที่นั่น ตรงนี้จะชี้แค่ข้อสรุป

เส้นทางที่สมจริงที่สุดคือ บันทึก telemetry ในเกม ทำให้เอนจินบันทึกอีเวนต์อย่าง "ที่เฟรม 1204 skill_overhead ตีเข้าเป้า, ดาเมจ 340, นับ Combo 3" ออกมาเองโดยตรง นี่เป็นข้อมูลต้นทางจึงแม่นยำ และจบในการแทรกโค้ดการบันทึกเพียงครั้งเดียว LLM ใช้ในการอ่านบันทึกนั้นแล้วสรุปเป็นรายงานภาษาธรรมชาติ ("จนถึง 3 Combo ประสิทธิภาพทรัพยากรดี แต่ตั้งแต่ 4 Combo ลดลงฮวบ") ส่วนวิดีโอเก็บไว้เป็นตัวเสริมให้คนตรวจด้วยตาเฉพาะเคสที่น่าสงสัยเท่านั้น

กล่าวคือ รูปแบบที่สมจริงของวิสัยทัศน์ "AI วิเคราะห์วิดีโออัตโนมัติ" คือ บันทึก telemetry + การสรุปด้วย LLM ไม่ใช่ pixel vision การแยกแยะอย่างตรงไปตรงมานี้เป็นจุดตั้งต้นของการเลือกเครื่องมือใน 4.4

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

4.1.5 เหตุผลที่แท้จริงในการแบ่งพิกัด — เงื่อนไขเบื้องต้นของการทำงานอัตโนมัติ

ที่ผ่านมานี้เป็นเหตุผลผิวเผินว่า "ถ้าแบ่งผลงานออกเป็น Layer เวลาทำงานร่วมกันจะคุยกันรู้เรื่อง" ที่อธิบายไว้ว่าวางกฎ Combo ไว้ที่ L1 และชีตดาเมจไว้ที่ L3 เพราะความถี่ในการเปลี่ยนต่างกัน เป็นคำที่ถูกต้อง แต่นั่นไม่ใช่ทั้งหมด

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

ก้อนที่หนึ่ง การจำลองจะทำงานได้ก็ต่อเมื่อแยก "อะไรที่ป้อนเข้าไปได้ และอะไรที่เปลี่ยนได้" ออกจากกัน ถ้าคอร์เชิงกำหนด (ฟิสิกส์·Hitbox — โครง L1) กับสเปกที่เปลี่ยนได้ (ค่าดาเมจ·Cooldown — ชีต L3) ปนกัน ตัวจำลองก็จะนิยาม "พื้นที่ของตัวเลือกที่จะเปลี่ยน" ไม่ได้ คอร์คงที่ ชีตเป็นตัวแปร — ต้องมีการแยกนี้ก่อน simulate_dps จึงจะทำการค้นหาอย่าง "ค่อย ๆ ดันค่าสัมประสิทธิ์ดาเมจจาก 280 ไปจนถึง 340 ทีละ 20 แล้ววาดเส้นโค้ง DPS"

ก้อนที่สอง การวิเคราะห์บันทึกจากบิลด์โดยอัตโนมัติจะมีความหมายก็ต่อเมื่อ atom ของแอ็กชันถูกติดป้าย (labeling) ต้องมี atom ที่ติดป้ายไว้ในระดับสเปกว่า "ช่วงเฟรมนี้คือสเตจ hit ของ skill_overhead" เสียก่อน จึงจะสามารถนำสัญญาณที่สกัดจากบันทึก telemetry มาเทียบกับสเปกโดยอัตโนมัติได้ ถ้าไม่มีป้าย บันทึกก็เป็นแค่การเรียงต่อกันของจุดที่ไร้ความหมายว่า "ที่เฟรม 1204 มีบางอย่างตีเข้าเป้า"

ก้อนที่สาม การสร้างลำดับ Combo ด้วย LLM จะทำงานได้ก็ต่อเมื่อกฎ Cancel·Input Queue ถูกแยกออกมาเป็นเอกสารภายนอก คำขอแบบจำกัดอย่าง "เสนอลำดับ 5 Combo มา 10 ชุด จากคู่ที่ Cancel ได้ 7 คู่ของตัวละครนี้ ภายใน Input Queue 200ms" จะเป็นไปได้ก็ต่อเมื่อกฎ Cancel ไม่ได้ฝังตายอยู่ในโค้ด แต่ถูกแยกออกมาเป็นเอกสารเท่านั้น

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

จากการประยุกต์แบบอนุรักษ์นิยมสู่การประยุกต์แบบก้าวหน้า

เมื่อปูเงื่อนไขเบื้องต้นนี้แล้ว การดำเนินงานการต่อสู้จะวิวัฒน์เป็นสองขั้น

การประยุกต์แบบอนุรักษ์นิยม — คนออกแบบ ระบบอัตโนมัติตรวจสอบ ตอนนี้การดำเนินงานการต่อสู้ของเกมแอ็กชัน·MMORPG ส่วนใหญ่อยู่ตรงนี้ เมื่อคนเขียนสเปก Combo·Cancel ด้วยตัวเอง ระบบอัตโนมัติก็จำลอง DPS·ทรัพยากร และจับด้วย telemetry แล้วออกรายงานเปรียบเทียบ "สเปก vs ค่าที่วัด" คนตีความความต่างนั้นแล้วตัดสินใจแก้สเปก แล้วก็กลับไปที่การเขียนสเปก วัฏจักรหมุนอีกครั้ง การออกแบบเป็นของคน ส่วนการจำลอง·การจับ·การเปรียบเทียบเป็นของระบบอัตโนมัติ

การประยุกต์แบบก้าวหน้า — AI เสนอตัวเลือก คนแค่เลือกใช้ เป็นขั้นถัดไป AI แจกแจงลำดับออกมา 10\~30 ชุดโดยอัตโนมัติภายในคู่ Cancel และ Input Queue ระบบอัตโนมัติจำลอง DPS·ทรัพยากรของแต่ละลำดับแบบขนาน และ LLM ติดอันดับ·การตีความให้ในรูปแบบ "ประสิทธิภาพทรัพยากรอันดับ 1, ความยากในการอินพุตปานกลาง" การตัดสินใจที่เหลืออยู่ในมือคนมีแค่ "จะเลือกลำดับไหนในบรรดาตัวเลือกมาเป็นซิกเนเจอร์" หนึ่งเดียว กับการตัดสินใจสะท้อนลงบิลด์·การจับโมชันของ Director เท่านั้น การสร้างลำดับจากศูนย์ กับการเลือกจาก 30 ชุด มีมิติของภาระงานต่างกัน

การที่การประยุกต์แบบก้าวหน้าจะตั้งหลักได้ ต้องมีพร้อมสามอย่าง (1) โครงสร้างพื้นฐานการจำลองเชิงกำหนดที่คำนวณ DPS·ทรัพยากร·เวลารอดได้ภายใน 1 วินาทีโดยไม่ต้องมีบิลด์ (2) atom ของแอ็กชันที่ Combo·Cancel·Input Queue ถูกแยก·ติดป้ายเป็นเอกสารภายนอก (3) การวิเคราะห์ข้อมูลที่จับมาอัตโนมัติบนฐาน telemetry ทั้งสามอย่างล้วนเป็นผลลัพธ์โดยตรงของการแยกย่อย Layer ที่กล่าวมาข้างต้น

การจับโมชันเป็นขั้นที่ย้อนกลับไม่ได้ — ด่านการตัดสินใจ

สุดท้ายคือเรื่องความย้อนกลับได้ ในวัฏจักรการตรวจสอบของนักออกแบบการต่อสู้ มีทั้งขั้นที่ย้อนกลับได้และย้อนกลับไม่ได้ปนกันอยู่ และการรู้เส้นแบ่งนั้นเป็นเรื่องสำคัญ

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

4.1.6 ภาพในบริษัท — อะไรที่ลดลง

นี่เป็นความเปลี่ยนแปลงที่ TF การต่อสู้ของโปรเจกต์ A วัดได้จากการใช้พิกัดและเครื่องมือข้างต้นมา 6 เดือน ตัวเลขด้านล่างเป็นค่าเฉลี่ยคร่าว ๆ ที่ดึงจากบันทึกการดำเนินงานของ TF ไม่ใช่ค่าที่วัดอย่างละเอียด จึงอ่านเป็น ทิศทางของความเปลี่ยนแปลงที่รู้สึกได้ จึงจะถูกต้อง

ทิศทางสำคัญกว่าตัวเลขเอง ทั้งสี่หัวข้อล้วนเคลื่อนจาก "ถกอัตวิสัย·วัดด้วยมือ·บิลด์ซ้ำ" ไปสู่ "ค่าที่วัดได้·จำลอง·ทำไดอะแกรมอัตโนมัติ" ในห้องประชุมคำคุณศัพท์ลดลง ตัวเลขเพิ่มขึ้น นั่นคือประโยคเดียวที่บททั้งบทต้องการจะพูด — งานของนักออกแบบการต่อสู้คือการสร้างสะพานที่เคลื่อนจากอัตวิสัย (สัมผัสของการตี·ความสนุก) ไปสู่ภววิสัย (ค่าตัวเลข·การจำลอง) และ AI คือเครื่องมือที่ปูสะพานนั้นได้อย่างรวดเร็ว ส่วนมือที่ตัดสินว่า "หนักแน่น" ที่ปลายสะพานยังคงเป็นของคนอยู่ดี

สรุปประเด็นสำคัญของบท

• งานออกแบบการต่อสู้เป็นที่นั่งซึ่งมี Layer หมุนพร้อมกันมากที่สุดบนโต๊ะเดียว ตั้งแต่สเปก L1, ชีต L3, ไปจนถึงการวัดจริงในบิลด์ L4
• การแยกย่อย Layer มีการทำให้ภาษาการทำงานร่วมกันเป็นหนึ่งเดียวเป็นเปลือกนอก ส่วนสาระคือเงื่อนไขเบื้องต้นของการทำงานอัตโนมัติที่ได้แก่ การจำลอง·การจับข้อมูล·การค้นหาด้วย LLM
• การตัดสินขั้นสุดท้ายว่า "สัมผัสของการตีดี" เป็นหน้าที่ของคน ส่วน AI สร้างข้อมูลที่เป็นหลักฐานของการตัดสินนั้นได้อย่างรวดเร็ว

ลองทำดู — ดึงคำคุณศัพท์ลงมาเป็นตัวเลข

setup มี LLM ตัวเดียวก็พอ เลือกสกิลหนึ่งที่อยู่ในมือคุณ (จะใหม่หรือเก่าก็ได้) เขียนเจตนาของสกิลนั้นเป็นคำคุณศัพท์หนึ่งบรรทัด — อย่าง "หนักแน่น" "ฉับไว" "ทื่อหนัก"

prompt เติมข้อมูลสกิลลงในโครงด้านล่าง

คุณคือผู้ช่วยงานออกแบบการต่อสู้ ให้แปลง Look & Feel ของสกิลด้านล่าง
ให้เป็น "สเปกค่าตัวเลขที่วัดได้" ไม่ใช่คำคุณศัพท์ แต่เป็นหน่วย ms·เฟรม·%
หัวข้อที่ไม่มั่นใจ ให้ระบุว่า "ต้องตรวจสอบในเกมนี้"

สกิล: [ชื่อ]
เจตนา: "[คำคุณศัพท์หนึ่งบรรทัด]"
เฟรมเรต: [60fps เป็นต้น]
หัวข้อ: 1)hit timing 2)hit stop 3)camera shake 4)การซิงก์เอฟเฟกต์ 5)ดีเลย์ตอนจบ

verify โยนคำถามสองข้อให้กับทุกตัวเลขในผลลัพธ์ (1) ภายใต้ข้อจำกัดของเกมนี้ (แพลตฟอร์ม·จังหวะ·ความยาวโมชัน) ค่านี้ถูกต้องไหม → ถ้าไม่ถูก ให้บอกข้อจำกัดแล้วขอใหม่ (2) ค่านี้ต้องกำหนดด้วยมือในบิลด์หรือไม่ → ถ้าใช่ ให้เขียนตัวแปร 2\~3 ตัวลงในสเปกแทนค่าเดียว แล้วเปรียบเทียบในบิลด์ หัวข้อที่ LLM ตอกย้ำว่า "ต้องตรวจสอบ" อย่ารับมาใช้ตามนั้นเด็ดขาด

4.1.7 ฉบับย่อสำหรับคนเดียว

ถ้าเป็นเกมที่ทำคนเดียว ไม่จำเป็นต้องมีผลงานทั้งห้า·Layer ทั้งห้าครบ ทำแค่สองอย่างขั้นต่ำพอ หนึ่ง สเปก Look & Feel หนึ่งหน้า — สำหรับแอ็กชันหลัก 3\~5 อย่าง ให้เขียนแค่ hit stop·ดีเลย์ตอนจบ·การซิงก์เป็นตัวเลข บันทึกที่เขียนด้วยคำคุณศัพท์ ตัวคุณเองในอีก 6 เดือนข้างหน้าก็จะอ่านไม่ออก สอง แยก Combo·Cancel ออกจากโค้ดมาไว้เป็นไฟล์เดียว — ถ้าดึงคู่ Cancel ออกมาเป็นข้อมูล ภายหลังก็สามารถให้ LLM "เสนอ 5 Combo ที่สร้างได้จากคู่นี้" ได้ สองอย่างนี้คือพิกัดขั้นต่ำที่เปิดประตูสู่การทำงานอัตโนมัติไว้แม้ในการพัฒนาคนเดียว

4.2 Look & Feel ของการต่อสู้ — จุดที่ใช้ข้อมูลจับ 'สัมผัสมือ'

หน้าจอมอนิเตอร์ในห้องประชุมมีคนยืนล้อมอยู่ห้าคน บิลด์เดียวกัน สกิลเดียวกัน วิดีโอความยาว 30 วินาทีคลิปเดิมกำลังเล่นวนซ้ำเป็นรอบที่สามบนจอ โปรแกรมเมอร์ฝั่งไคลเอนต์เอ่ยปากก่อน "ผมว่าโอเคนะ" คนดูแลฝั่งอาร์ตกอดอก "มันอ่อนไป รู้สึกเหมือนขาดอะไรไป" นักออกแบบเกมที่อยู่ข้าง ๆ แทรกขึ้นมา "เอฟเฟกต์ดีนะ แต่มันไม่ติดมือ" ผู้กำกับมองอยู่นานแล้วตัดสินใจ "อืม… เอาให้หนักแน่นขึ้นอีกนิดละกัน"

แล้วการประชุมก็จบลง 'หนักแน่นขึ้นอีกนิด' นั้นแม่นยำคือกี่ ms กี่เฟรม ไม่มีใครจดเอาไว้ ในบิลด์ถัดไปโปรแกรมเมอร์ก็สร้าง 'ความหนักแน่น' ตามที่ตัวเองเข้าใจ ส่วนฝั่งอาร์ตก็เติม 'ความหนักแน่น' ตามที่ตัวเองเข้าใจ แล้วสัปดาห์ถัดมาในห้องประชุมเดียวกันก็ดูวิดีโอเดียวกัน บทสนทนาเดิมก็วนซ้ำอีกครั้ง

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

4.2.1 การต่อสู้ = Look & Feel, ระบบ = การทำงาน

ก่อนอื่นขอลากเส้นแบ่งเอาไว้ งานออกแบบการต่อสู้แบ่งใหญ่ ๆ ได้สองสาย

• ระบบการต่อสู้ (combat system): ทำงานอย่างไร สูตรดาเมจ คูลดาวน์ การสะสมสแต็ก กฎของสถานะผิดปกติ เป็นพื้นที่ของบทถัดไป (4.3 คอมโบ·แคนเซิล, 4.4 การจำลองด้วย AI)
• Look & Feel ของการต่อสู้: ให้ความรู้สึกอย่างไร หลังกดปุ่มแล้วหน้าจอตอบสนองเมื่อไร ในจังหวะที่โจมตีโดน หน้าจอหยุดนานแค่ไหน เอฟเฟกต์ เสียง และแรงสั่นพุ่งขึ้นในจังหวะเดียวกันหรือไม่

บทนี้ว่าด้วยอย่างหลังเท่านั้น ดาเมจจะเป็น 100 หรือ 120 ก็ไม่เกี่ยวข้องโดยตรงกับสัมผัสมือ สิ่งที่เป็นสัมผัสมือคือผู้เล่นรู้สึกอย่างไรกับ 'จังหวะที่ดาเมจ 100 นั้นเข้าไป' แม้จะเป็นสูตรดาเมจเดียวกัน หากจังหวะการเข้าโจมตี (hit timing) และฮิตสต็อป (hitstop) ต่างกัน ก็จะรู้สึกเหมือนเป็นคนละเกมกันเลย

ก่อนอื่นมีเรื่องที่ต้องพูดกันตรง ๆ ความรู้สึกของแรงปะทะไม่ได้สมบูรณ์ด้วยตัวเลขเพียงสามตัว ต้องมีทั้งเส้นโค้งความเร่ง·ความหน่วงของโมชันโจมตี (แอนิเมชัน) ปฏิกิริยาของฝั่งที่โดน (hit reaction·อาการชะงัก) ไปจนถึงเดฟอร์เม (deformation — การยืดและบีบอัดตัวละครให้เกินจริงในจังหวะปะทะ เป็นการแสดงภาพ ภาพซ้อน·การเบลอ ที่นิยมใช้ในเกมแอ็กชันญี่ปุ่นยุค 80–90) ทั้งหมดจึงจะประกอบกันเป็นความรู้สึก "โดนแล้ว" ก้อนเดียว สิ่งที่บทนี้มุ่งดึงลงมาเป็นตัวเลขที่วัดได้ คือสามแกนในจำนวนนั้น ส่วนโมชัน·ปฏิกิริยา·เดฟอร์เมเป็นพื้นที่ที่มือของแอนิเมเตอร์·อาร์ติสต์สัมผัสมากกว่า จึงยกไปพูดในบทถัด ๆ ไปและในส่วนของอาร์ต ในที่นี้เราจะเน้นน้ำหนักไปที่สามแกนที่นักออกแบบเกมสามารถตรึงไว้เป็นข้อกำหนด (spec) และตรวจสอบในบิลด์ได้ สามแกนนั้นแยกย่อยได้ดังนี้

เมื่อมีใครในห้องประชุมพูดว่า "มันอ่อน" ความอ่อนนั้นมาจากหนึ่งในสามแกน ตอบสนองช้าไป (จังหวะ) ไม่มีความรู้สึกของการปะทะ (ฮิตสต็อป) หรือต่างคนต่างเล่น (การซิงค์)? เมื่อแยกออกเป็นสามแกนแล้วถาม คำว่า 'อ่อน' จึงกลายเป็นประโยคที่แก้ไขได้เสียที

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

สี่ตัวด้านบนถูกมัดรวมเป็นสามแกนของบทนี้และกลายเป็นเป้าหมายของการวัด·ทำข้อกำหนด ส่วนสามตัวตรงกลาง (โมชัน·ปฏิกิริยา·เดฟอร์เม) เป็นสิ่งที่ขาดไม่ได้ แต่เป็นพื้นที่อาร์ต·แอนิเมชันที่นักออกแบบเกมคนเดียวปิดด้วยตัวเลขได้ยาก จึงทำเพียงระบุให้ชัดว่า 'มันมีอยู่' เท่านั้น หากโมชันแข็งทื่อหรือฝั่งที่โดนยังยืนเฉยอยู่ดี ๆ ต่อให้สามแกนตรงครบก็ไม่เกิดความรู้สึกของแรงปะทะ

4.2.2 จังหวะการเข้าโจมตี — จากอินพุตถึงการตอบสนอง

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

แกนแรกของสัมผัสมือคือเวลา ตั้งแต่ขณะที่กดปุ่ม (0ms) จนถึงขณะที่หน้าจอตอบสนองเป็นครั้งแรก ใช้เวลากี่ ms มนุษย์ไวต่อความหน่วงนี้อย่างน่าประหลาดใจ ความต่างระหว่าง 60ms กับ 120ms นั้น 'อธิบายเป็นคำพูดไม่ได้ แต่มือรู้'

การโจมตีหนึ่งครั้งไม่ใช่จุดเดียวเรียบ ๆ แต่เป็นหลายเหตุการณ์ที่กางออกบนแกนเวลา เมื่อนำการโจมตีปกติหนึ่งจังหวะมาวางบนแกนเวลา หน้าตาจะเป็นแบบนี้

ในภาพนี้ ตัวเลขที่สำคัญที่สุดคือ '100ms ที่ hitbox เปิดเป็นครั้งแรก' หมายความว่าหลังกดปุ่ม 100ms การตัดสินการโจมตีจึงเริ่มขึ้น ค่านี้กำหนดความเร็วที่สัมผัสได้ของสัมผัสมือ

ช่วงที่แนะนำต่างกันไปตามแนวเกม·ตัวละคร แต่ก็มีเส้นมาตรฐานคร่าว ๆ อยู่

ช่วงนี้ไม่ใช่มาตรฐานตายตัว เป็นการประมาณของผู้เขียน (ยังไม่ได้ตรวจสอบ) ว่าเกมมือถือแคชวลมักแกว่งไปทางผ่อนปรนอินพุต ±50ms ส่วนเกมต่อสู้บนคอนโซลมักรัดให้เข้มงวดกว่า สิ่งสำคัญยิ่งกว่าตัวเลขเองคือการที่ทีมมีเส้นมาตรฐานร่วมกันว่า 'การโจมตีเบาของเกมเราตกลงกันที่ 90ms' เมื่อมีเส้นมาตรฐานแล้วจึงจะพูดได้ว่า 'ถูก/ผิด' เมื่อดูบิลด์

แต่ตรงนี้มีกับดักอยู่หนึ่งอย่าง สายตามนุษย์แยกระหว่าง 90ms กับ 110ms ไม่ออก ที่ 60fps หนึ่งเฟรมประมาณ 16.67ms และความต่าง 20ms นี้ก็แค่หนึ่งเฟรมนิด ๆ ในห้องประชุม ประโยค "รู้สึกช้าไปหน่อยมั้ย?" จะถูกหรือผิด สุดท้ายก็ตัดสินด้วยสายตาไม่ได้ ด้วยเหตุนี้จึงต้องวัด

4.2.3 จะดึงจังหวะออกมาจากบิลด์อย่างไร — การเปรียบเทียบอย่างซื่อตรง

ในข้อกำหนดเขียนว่า 'hitbox 100ms' จะตรวจในบิลด์ได้อย่างไรว่าจริง ๆ มันเปิดที่ 100ms เส้นทางของการทำงานอัตโนมัติแยกออกเป็นสาม (วิเคราะห์วิดีโอ·เครื่องมือ vision สำเร็จรูป·telemetry ในเกม) ซึ่งการเปรียบเทียบความแม่นยำ·ความยากของสามวิธีนี้จะกล่าวเป็นฉบับหลักใน 4.4 ในที่นี้ขอเก็บเฉพาะข้อสรุป สิ่งที่ต้องวางในงานจริงเป็นอันดับแรกคือ telemetry ในเกม เหตุผลเรียบง่าย การที่โค้ดยิง [HITLOG] หนึ่งบรรทัดลงตรงเฟรมที่เหตุการณ์ OnHit เกิดขึ้นโดยตรงนั้น แม่นยำและถูกกว่าการอนุมานจากวิดีโอว่า VFX 'ปรากฏที่เฟรมไหน' บนหน้าจอแบบเทียบกันไม่ติด การวิเคราะห์วิดีโอใช้กับวิดีโอภายนอกที่ไม่มีโอเวอร์เลย์อินพุต (เช่น การวิเคราะห์เกมคู่แข่ง) ส่วนบิลด์ของเราให้เริ่มวางจาก telemetry ก่อน

ล็อก telemetry มีหน้าตาแบบนี้

[HITLOG] frame=6  t_ms=100  evt=hitbox_on    skill=1001 char=warrior
[HITLOG] frame=6  t_ms=100  evt=vfx_trigger  skill=1001
[HITLOG] frame=6  t_ms=100  evt=sfx_trigger  skill=1001
[HITLOG] frame=7  t_ms=117  evt=damage_apply skill=1001 dmg=124
[HITLOG] frame=7  t_ms=117  evt=ui_dmgnum    skill=1001
[HITLOG] frame=6  t_ms=100  evt=cam_shake    skill=1001 amp=0.4

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

4.2.4 บันทึกเซสชันจริง (worked transcript) — ให้เทียบล็อก telemetry กับข้อกำหนด

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

พรอมต์ครั้งที่ 1

ต่อไปนี้คือ 'ข้อกำหนดจังหวะการเข้าโจมตี' ของสกิลต่อสู้หนึ่งตัว และล็อก
telemetry ที่ดึงจากบิลด์จริง ช่วยจัดรายการที่บิลด์คลาดเคลื่อนจากข้อกำหนดเป็นตารางให้หน่อย

[ข้อกำหนด]
character: warrior
skill_id: 1001
fps: 60
events:
  hitbox_on:    {expect_ms: 100, tol_frame: 0}
  vfx_trigger:  {expect_ms: 100, tol_frame: 0}
  sfx_trigger:  {expect_ms: 100, tol_frame: 1}
  damage_apply: {expect_ms: 110, tol_frame: 1}
  ui_dmgnum:    {expect_ms: 100, tol_frame: 2}
  cam_shake:    {expect_ms: 100, tol_frame: 1}

[ล็อก telemetry]
[HITLOG] frame=6  t_ms=100  evt=hitbox_on    skill=1001
[HITLOG] frame=6  t_ms=100  evt=vfx_trigger  skill=1001
[HITLOG] frame=8  t_ms=133  evt=sfx_trigger  skill=1001
[HITLOG] frame=7  t_ms=117  evt=damage_apply skill=1001
[HITLOG] frame=9  t_ms=150  evt=ui_dmgnum    skill=1001
[HITLOG] frame=6  t_ms=100  evt=cam_shake    skill=1001

60fps (1 เฟรม=16.67ms) ช่วยแปลง expect_ms เป็นเฟรมแล้วเทียบกับ frame ของล็อก
ถ้าส่วนต่างเกิน tol_frame ให้แสดงเป็น FAIL

ผลลัพธ์ดิบของ Claude (ตามเดิม)

ก่อนอื่นผมจะแปลง expect_ms ของข้อกำหนดเป็นเฟรม ที่ 60fps frame = round(ms / 16.67)

• hitbox_on: 100 / 16.67 ≈ 6.0 → frame 6
• vfx_trigger: 100 → frame 6
• sfx_trigger: 100 → frame 6
• damage_apply: 110 / 16.67 ≈ 6.6 → frame 7 (ปัดขึ้น)
• ui_dmgnum: 100 → frame 6
• cam_shake: 100 → frame 6

ผลการเทียบกับ frame จริงในล็อกเป็นดังนี้

เหตุการณ์	frame ที่คาด	frame จริง	ส่วนต่าง(frame)	ค่าที่ยอม	ผลตัดสิน
hitbox_on	6	6	0	0	PASS
vfx_trigger	6	6	0	0	PASS
sfx_trigger	6	8	+2	1	FAIL
damage_apply	7	7	0	1	PASS
ui_dmgnum	6	9	+3	2	FAIL
cam_shake	6	6	0	1	PASS

มีสองรายการที่เกินค่าความคลาดเคลื่อนที่ยอมรับได้ - sfx_trigger: เสียงช้ากว่าการปะทะทางภาพ 2 เฟรม (ประมาณ 33ms) เกินค่าที่ยอม 1 เฟรม มีความเป็นไปได้สูงที่ผู้เล่นจะรู้สึกว่า "เสียงมันหลุดออกไปนิด ๆ" - ui_dmgnum: ตัวเลขดาเมจขึ้นช้าไป 3 เฟรม (ประมาณ 50ms) เกินค่าที่ยอม 2 เฟรม อาจนำไปสู่ความรู้สึกขัด ๆ ว่า "ตีโดนแล้วแต่ตัวเลขขึ้นช้า"

การที่ damage_apply เป็น frame 7 ตรงกับ frame 7 ตามข้อกำหนด (แปลงจาก 110ms) จึงถือว่าปกติ อย่างไรก็ตาม การที่ damage_apply ช้ากว่า hitbox_on (frame 6) อยู่ 1 เฟรม เป็นจุดที่ต้องยืนยันว่าเป็นการออกแบบที่ตั้งใจหรือไม่

การตรวจสอบของมนุษย์ — ปฏิเสธไปหนึ่งช่อง

พอได้ผลลัพธ์มาก็ไม่เชื่อทั้งหมดในทันที มีจุดที่ต้องตรวจสอบอยู่สองจุด

ตรวจสอบ 1 (เส้นแบ่งการปัดเศษ — ผ่าน) การแปลง 110ms ของ damage_apply ดูน่าสงสัย 110 / 16.67 = 6.598… เมื่อปัดเศษได้ 7 ถูกต้อง แต่ถ้าเจตนาของข้อกำหนดคือ '6 เฟรม = เฟรมเดียวกับ 100ms' ล่ะ? พอเช็กเองโดยตรงก็พบว่าในข้อกำหนดระบุ damage_apply: expect_ms 110 ตั้งใจให้ต่างจาก vfx (100) อยู่ 10ms จริง ดังนั้นการแปลงเป็น frame 7 จึงแม่นยำ AI ผ่าน

ตรวจสอบ 2 (ประโยคสุดท้าย — ปฏิเสธ) ประโยคที่ AI เติมท้ายว่า "การที่ damage_apply ช้ากว่า hitbox_on อยู่ 1 เฟรม เป็นจุดที่ต้องยืนยันว่าเป็นการออกแบบที่ตั้งใจหรือไม่" นั้นเป็นสัญญาณรบกวน ทั้งที่ในข้อกำหนดระบุเจตนาไว้แล้วด้วย expect_ms 110 แต่ AI กลับย้อนถามว่า 'ต้องยืนยัน' เมื่อให้ข้อกำหนดไปแล้วก็ควรปิดคำตอบภายในข้อกำหนด แต่กลับสร้างคำถามที่ไม่จำเป็นขึ้นมา ประโยคนี้จึงไม่นำมาใช้

ผมจึงร้องขอใหม่โดยใส่เหตุผลของการปฏิเสธลงไป

พรอมต์ครั้งที่ 2 (ร้องขอใหม่)

damage_apply มีเจตนาตรึงไว้ในข้อกำหนดที่ 110 อยู่แล้ว ตัดคอมเมนต์ 'ต้องยืนยัน' ออก
// หมายถึงอย่าย้อนถามรายการที่ปิดคำตอบไว้ในข้อกำหนดแล้ว
เหลือไว้แค่ FAIL สองรายการ (sfx, ui_dmgnum) และแทนที่จะฟันธงสาเหตุ
ให้เป็นเช็กลิสต์ 'ตำแหน่งโค้ด/รีซอร์สที่ต้องตรวจ'

ผลลัพธ์ครั้งที่ 2 ของ Claude (ตามเดิม)

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

sfx_trigger (ดีเลย์ +2 เฟรม) - [ ] ทริกเกอร์เสียงผูกไว้กับเหตุการณ์เดียวกับ hitbox_on หรือผูกไว้กับ animation notify แยกต่างหาก - [ ] ตัวแอสเซ็ตเสียงเองมีช่วงเงียบนำหน้า (leading silence) หรือไม่ — ช่วงว่างหัวไฟล์อาจดูเหมือนเป็นดีเลย์ได้ - [ ] การเรียกเล่นเสียงเข้าในเฟรมเดียวกันแล้ว แต่ถูกเลื่อนด้วยเลเทนซีเอาต์พุตหรือไม่ (บัฟเฟอร์เสียงของแพลตฟอร์ม)

ui_dmgnum (ดีเลย์ +3 เฟรม) - [ ] UI ตัวเลขดาเมจมีโครงสร้างที่อัปเดตในติกแยกหลังจาก damage_apply (frame 7) หรือไม่ - [ ] การอัปเดต UI ถูกประมวลผลรวบยอดที่ท้ายเฟรมถัดไปหรือไม่ (คิวเรนเดอร์แบบหน่วง) - [ ] เฟรมเริ่มต้นของแอนิเมชันป็อปอัปตัวเลขมีค่าดีเลย์เพิ่มแทรกอยู่หรือไม่

สิ่งที่ฟันธงได้: ทั้งสองรายการเกินค่าความคลาดเคลื่อนที่ยอมในข้อกำหนด และช้ากว่าการปะทะทางภาพ (frame 6) สิ่งที่ฟันธงไม่ได้: ในบรรดาสาเหตุข้างต้นว่าเป็นอันไหน ไม่อาจทราบได้จนกว่าจะตรวจโค้ด/แอสเซ็ต

ผลลัพธ์ครั้งที่สองนี้นำมาใช้ตามเดิม การที่ไม่กุสาเหตุขึ้นมาแต่เปลี่ยนเป็น 'จุดที่ต้องตรวจ' เป็นรูปแบบที่ต้องการพอดี ผมส่งเช็กลิสต์นี้ให้ผู้รับผิดชอบฝั่งเสียงและฝั่ง UI ตามเดิม ฝั่งเสียงพบว่าตัวการคือช่วงเงียบนำหน้าของแอสเซ็ตเสียง 33ms (เช็กลิสต์ข้อ 2) ส่วน UI เป็นโครงสร้างอัปเดตในเฟรมถัดไป (ข้อ 1)

ตรงนี้เส้นแบ่งของการแบ่งงานก็ชัดเจน AI เทียบข้อกำหนดกับล็อกเชิงกลไกเพื่อจับ FAIL ส่วนมนุษย์ (a) ปฏิเสธคำย้อนถามที่ไม่จำเป็นซึ่ง AI สร้างขึ้น และ (b) ยืนยันสาเหตุที่แท้จริงของ FAIL ในโค้ด หากให้ AI ฟันธงสาเหตุ มันจะกุคำโกหกที่ฟังดูน่าเชื่อขึ้นมา การสั่งให้ทำแค่ถึง 'จุดที่ต้องตรวจ' จึงปลอดภัย

4.2.5 ฮิตสต็อป — น้ำหนักของการปะทะ

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

ช่วงที่แนะนำ (อิงที่ 60fps) เป็นดังนี้ ตัวเลขนี้เป็นแนวปฏิบัติคร่าว ๆ ที่ใช้กันในเกมแอ็กชัน ส่วนค่าตายตัวให้ปรับตามแต่ละเกม

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

'ใครหยุด' ก็เป็นทางเลือกในการออกแบบเช่นกัน

ข้อกำหนดป้อนเข้าแบบนี้

character: warrior
skill_id: 1001
hit_stop:
  attacker: 2          # frames
  victim: 4
  critical_multiplier: 1.5   # ตอนคริติคัลคูณ 1.5 เท่า (ปัดเศษ)

ฮิตสต็อปเป็นแกนที่ตรวจสอบสัมผัสมือยากที่สุด เพราะไม่อาจปิด 'ถูก/ผิด' ด้วยตัวเลขข้อกำหนดเพียงอย่างเดียว telemetry จับได้ว่า 'หยุดไป 4 เฟรมจริงหรือไม่' แต่ '4 เฟรมเหมาะสมหรือไม่' มนุษย์ต้องลงมือลองในบิลด์เองแล้วตัดสิน AI รับประกันความตรงตามข้อกำหนด ส่วนมนุษย์ดูความเหมาะสมของค่าข้อกำหนดนั้นเอง

4.2.6 การซิงค์เอฟเฟกต์ — ทุกอย่างพุ่งขึ้นในเฟรมเดียวกันหรือไม่

แกนที่สามคือความพร้อมเพรียง เมื่อ VFX (เอฟเฟกต์ภาพ)·SFX (เสียง)·UI (ตัวเลขดาเมจ)·กล้อง (การสั่น)·แรงสั่น (คอนโทรลเลอร์) เริ่มในเฟรมเดียวกัน สมองผู้เล่นจะมัดมันเข้าด้วยกันเป็น 'เหตุการณ์เดียว' คลาดเคลื่อนแค่ 1\~2 เฟรมก็จะได้ปฏิกิริยา "ขัด ๆ" คลาดไป 3\~5 เฟรมก็จะได้ปฏิกิริยา "เหมือนบั๊ก" เรื่องที่ sfx ช้า 2 เฟรมและ ui ช้า 3 เฟรมจน FAIL ในบันทึกเซสชันจริงก่อนหน้านี้ก็คือปัญหาของแกนนี้พอดี

เป้าหมายการซิงค์ 5 อย่างและค่าความคลาดเคลื่อนที่ยอมรับได้

หัวใจคือ 5 อย่างนี้ต้องเข้าไปอยู่ในข้อกำหนด ทั้งหมด ความผิดพลาดที่พบบ่อยคือเขียนเฉพาะ VFX ลงข้อกำหนด แล้วปล่อยอีกสี่อย่างไว้แบบ 'เดี๋ยวมันคงเข้าจังหวะกันเอง' ถ้าไม่มีในข้อกำหนด เกณฑ์ของการตรวจสอบบิลด์ก็ไม่มี และต่อให้จับด้วย telemetry ได้ ก็ไม่มีสิ่งที่จะเอามาเทียบ 5 อย่างต้องอยู่ในข้อกำหนดครบ การเทียบอัตโนมัติจึงจะปิดได้

การเทียบอัตโนมัติใช้บันทึกเซสชันจริงในหัวข้อก่อนหน้าได้ตามเดิม หากเฟรมทริกเกอร์ของทั้ง 5 อย่างถูกบันทึกครบในล็อก telemetry AI จะเทียบกับข้อกำหนดและรายงานเฉพาะรายการที่เกินค่าความคลาดเคลื่อน คนไม่จำเป็นต้องเอาตา 100 สกิลมาตรวจทุกบิลด์ อย่างไรก็ตาม การที่ AI จับความคลาดเคลื่อนจากข้อกำหนด กับการที่มนุษย์จับพื้นที่ "ข้อกำหนดตรงครบแต่ก็ยังไม่ได้ความรู้สึก" ยังคงเป็นคนละเรื่องที่แยกกันอยู่

4.2.7 จากข้อกำหนดถึงบิลด์ถัดไป — ลูปทั้งหมด

เราจะร้อยชิ้นส่วนทั้งหมดที่ผ่านมาเป็นกระแสเดียว เมื่อลูปนี้เริ่มหมุน 'หนักแน่นขึ้นอีกนิด' ในห้องประชุมก็จะถูกแปลเป็น 'ฮิตสต็อป victim 4→6 เฟรม'

flowchart TD
    A["เขียนข้อกำหนด
(นักออกแบบเกม: yaml)"] --> B["ทำในบิลด์
(โปรแกรมเมอร์·อาร์ติสต์)"]
    B --> C["รันบิลด์ + ล็อก telemetry
[HITLOG] ออกอัตโนมัติ"]
    C --> D["AI เทียบอัตโนมัติ
yaml ข้อกำหนด vs telemetry"]
    D --> E{"มี FAIL
ที่เกินค่าคลาดเคลื่อนไหม?"}
    E -->|มี| F["รายการ FAIL + เช็กลิสต์ตรวจสอบ
(AI, ห้ามฟันธงสาเหตุ)"]
    F --> G["ผู้รับผิดชอบยืนยันสาเหตุที่แท้จริง
ในโค้ด·แอสเซ็ต (มนุษย์)"]
    G --> B
    E -->|ไม่มี| H["นักออกแบบเกม: ตรวจ 'ความรู้สึก'
ข้อกำหนดตรงแต่ได้สัมผัสมือไหม (มนุษย์)"]
    H -->|ต้องปรับ| A
    H -->|OK| I["เก็บเป็นอินพุตของการทบทวนไมล์สโตนถัดไป"]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class C code;
    class D,F ai;
    class A,G,H human;
    class I pass;

ในลูปนี้ ช่องที่ AI รับ (D, F) กับช่องที่มนุษย์รับ (A, G, H) แยกออกจากกันชัดเจน AI เก่งการเทียบเชิงกลไกและการสร้างเช็กลิสต์ ส่วนมนุษย์เก่งการตั้งเส้นมาตรฐาน·ยืนยันสาเหตุ·ตัดสินความรู้สึกขั้นสุดท้าย การทำงานอัตโนมัติไม่ได้ถอดคนออก แต่ปลดคนออกจาก 'การนับเฟรมด้วยสายตา' ที่เคยใช้ครึ่งวันทุกครั้ง ให้ไปจดจ่อกับ 'ความรู้สึก' เพียงอย่างเดียว

ช่องสุดท้ายของลูป (I) สำคัญ ข้อมูลการวัดนี้ไม่ใช่ใช้แล้วทิ้ง แต่จะกลับเข้าไปเป็นอินพุตของการทบทวนไมล์สโตนถัดไปอีกครั้ง เมื่อแพตเทิร์นอย่าง 'FAIL ของสัมผัสมือไตรมาสที่แล้วกระจุกอยู่ที่การซิงค์ sfx' เหลือไว้เป็นข้อมูล ไตรมาสถัดไปก็จะลงมือแก้ไปป์ไลน์เสียงก่อน

4.2.8 จุดที่การวัดลดการถกเถียง — การสังเกตจากการปฏิบัติงาน

ในโปรเจกต์เกมมือถือ MMORPG หนึ่ง (ต่อไปเรียก 'โปรเจกต์ A') ที่ผู้เขียนเข้าร่วมในฐานะผู้กำกับ นี่คือความเปลี่ยนแปลงที่สังเกตได้จากการหมุนลูปข้างต้นราว 6 เดือน ตัวเลขด้านล่างไม่ใช่การวัดอย่างละเอียด แต่เป็น การสังเกตจากการปฏิบัติงานของผู้เขียน (รวมการประมาณ) ที่อิงจากไทม์สแตมป์ในบันทึกการประชุมและบันทึกการตรวจสอบบิลด์ ขออ่านในแง่ทิศทางและสัดส่วน อย่านำค่าตายตัวไปใช้เป็นเบนช์มาร์กที่อ้างอิงได้

สิ่งที่เป็นแก่นคือความเปลี่ยนแปลงเชิงคุณภาพยิ่งกว่าตัวเลขเอง พอมีคนพูดในห้องประชุมว่า "มันอ่อนนะ" ก็จะย้อนถามได้ทันทีว่า "แกนไหนล่ะ? จังหวะ? ฮิตสต็อป? การซิงค์?" และเมื่อยังไม่ได้คำตอบก็เปิด telemetry ขึ้นมาดูด้วยกัน การที่ความเป็นปรวิสัยซึ่งวัดได้สร้างจุดสิ้นสุดให้การถกเถียง คือความเปลี่ยนแปลงที่ใหญ่ที่สุดในรอบ 6 เดือน เรื่องที่ 'หนักแน่นขึ้นอีกนิด' หลุดออกไปนอกห้องประชุมก็ลดลง

4.2.9 ความผิดพลาดที่พบบ่อยและการหลีกเลี่ยง

ลองทำดู

นี่คือขั้นตอนการลองวางลูปนี้ลงในโปรเจกต์ของคุณด้วยขนาดที่เล็กที่สุด

setup 1. เลือกสกิลที่จะตรวจสอบ 1 ตัว (แนะนำการโจมตีปกติ) 2. ฝังล็อกบรรทัดละหนึ่งลงในจุดทริกเกอร์ 6 จุดของโค้ด (hitbox_on, vfx, sfx, damage_apply, ui_dmgnum, cam_shake): [HITLOG] frame=X t_ms=Y evt=... skill=... 3. เขียน yaml ข้อกำหนด (ในบล็อก events ใส่ expect_ms + tol_frame) ใช้ตัวอย่างพรอมต์ครั้งที่ 1 ของบทนี้เป็นเทมเพลต

prompt 4. รันบิลด์หนึ่งครั้งเพื่อรวบรวมล็อก telemetry 5. วาง yaml ข้อกำหนด + ล็อก telemetry เข้าไปใน AI พร้อมกัน แล้วสั่งแบบนี้: "ช่วยเทียบรายการที่บิลด์คลาดเคลื่อนจากข้อกำหนดด้วยการแปลงเป็นเฟรมที่ 60fps แล้วให้เฉพาะ FAIL เป็นตาราง อย่าฟันธงสาเหตุ ให้เป็นเช็กลิสต์ 'จุดที่ต้องตรวจ'" (รูปแบบพรอมต์ครั้งที่ 2 ของบทนี้)

verify 6. คำนวณตรวจสอบการแปลงเฟรมในผลลัพธ์ AI ด้วยตัวเองสักหนึ่งช่อง (ms / 16.67 ปัดเศษ) ถ้าผิดแม้แต่ช่องเดียวให้สงสัยทั้งหมด 7. ถ้า AI ย้อนถามรายการที่ปิดในข้อกำหนดแล้วหรือฟันธงสาเหตุ ให้ปฏิเสธและร้องขอใหม่ 8. ส่งเช็กลิสต์ FAIL ให้ผู้รับผิดชอบเพื่อยืนยันสาเหตุที่แท้จริงในโค้ด·แอสเซ็ต

ฉบับย่อสำหรับคนเดียว

ถ้าเป็นนักพัฒนาคนเดียวที่ไม่มีทั้งทีมและโครงสร้างพื้นฐาน telemetry ให้ลดทอนแบบนี้ บันทึกหน้าจอบิลด์ที่ 60fps แล้วเปิดโอเวอร์เลย์อินพุตปุ่มให้เห็นจังหวะที่กด หลังจากบันทึกสกิลที่จะตรวจสอบหนึ่งครั้ง ในโปรแกรมตัดต่อวิดีโอให้นับ 'เฟรมที่กดปุ่ม' และ 'เฟรมที่หน้าจอเปลี่ยนเป็นครั้งแรก' ด้วยตัวเอง ป้อนเลขเฟรมสองค่าและค่าที่คาดในข้อกำหนดให้ AI แล้วสั่งว่า "ช่วยแปลงเป็น ms ที่ 60fps แล้วเทียบกับข้อกำหนดให้หน่อย" ก็จะตรวจสอบแกนหลักหนึ่งแกน (จังหวะการเข้าโจมตี) ได้แม้ไม่มี telemetry การซิงค์ครบ 5 อย่างทำได้ยาก แต่เพียงจับแกน 'อินพุต→ตอบสนอง' แกนเดียวได้ ครึ่งหนึ่งของการถกเรื่องสัมผัสมือก็ย้ายมาอยู่บนความเป็นปรวิสัยแล้ว

บทถัดไปจะข้ามจากการปะทะหนึ่งครั้งไปสู่การปะทะที่ต่อเนื่องกัน คอมโบ·แคนเซิล·คิวอินพุต — ว่าด้วยกฎที่ทำให้การปะทะหนึ่งเชื่อมไปสู่การปะทะถัดไปอย่างเป็นธรรมชาติ

สรุปประเด็นสำคัญของบท

• สัมผัสมือคือผลรวมของสามแกน จังหวะการเข้าโจมตี·ฮิตสต็อป·การซิงค์เอฟเฟกต์ การแก้เพียงแกนเดียวจะทำให้อีกสองแกนสั่นคลอน
• ล็อก telemetry ในเกมแม่นยำและถูกกว่าการวิเคราะห์วิดีโอ — บิลด์ของเราเริ่มวางจาก telemetry ก่อน
• AI จับ FAIL ด้วยการเทียบข้อกำหนด ส่วนมนุษย์ปฏิเสธคำย้อนถามและยืนยันสาเหตุในโค้ด

ตัวอย่างบทถัดไป

• 4.3. คอมโบ·แคนเซิล·คิวอินพุต

4.3 คอมโบ คานเซิล และคิวอินพุต — แจกแจงทุกเส้นทางแล้วตรวจสอบ

สมาชิกทีม B ซึ่งเป็นดีไซเนอร์ฝ่ายการต่อสู้ ยืนอยู่หน้าไวต์บอร์ดในห้องประชุมและกำลังวาดกล่องด้วยปากกามาร์กเกอร์ เบสิก1 เบสิก2 เบสิก3 และกิ่งที่แตกออกข้างไปเป็นการโจมตีหนัก เมื่อมีลูกศรเพิ่มขึ้นราวเจ็ดเส้น มีคนหนึ่งถามขึ้นว่า "งั้นถ้าหลังจากใช้ท่าดีดศัตรูขึ้นจากการโจมตีหนัก แล้วคานเซิลด้วยการหลบ จะกลับมาเริ่มที่เบสิก1 ได้อีกไหม" สมาชิกทีม B หยุดปากกาไว้ บนกราฟที่อยู่บนไวต์บอร์ดไม่มีเส้นทางนั้นวาดเอาไว้ จะวาดได้แต่ไม่ได้วาด หรือกฎไม่อนุญาตให้ทำกันแน่ แม้แต่เจ้าตัวเองก็ตอบทันทีไม่ได้

นี่คือปัญหาที่แท้จริงของการออกแบบคอมโบ คอมโบเมื่อคิดในหัวจะดูเหมือนเส้นเดียวเรียบง่ายแบบ "1-2-3 ต่อกัน แล้วแตกกิ่งไปการโจมตีหนัก" แต่เมื่อมีคานเซิลและคิวอินพุตเข้ามาเกี่ยว เส้นนั้นก็กลายเป็นกราฟ แค่เพิ่มเอดจ์คานเซิลไม่กี่เส้นบนโหนดหกตัว เส้นทางที่เหยียบได้จริงก็เพิ่มขึ้นเป็นหลายสิบสาย คนเราไม่สามารถกางทั้งหลายสิบสายนั้นออกในหัวได้หมด ความคิดเรื่องบาลานซ์อย่าง "เส้นทางนี้แรงเกินไป" จึงมักถูกค้นพบก็ต่อเมื่อมันเข้าไปอยู่ในบิลด์แล้วเท่านั้น

เป้าหมายของบทนี้มีหนึ่งเดียว คือการสร้าง เวิร์กโฟลว์ที่แจกแจงเส้นทางคอมโบทั้งหมดโดยอัตโนมัติแทนที่จะวาดด้วยมือ แล้วตรวจสอบแต่ละเส้นทาง เราจะเปลี่ยนกฎที่เขียนเป็นภาษาธรรมชาติให้เป็นสเปก แจกแจงเส้นทางจากสเปก แล้วเอาเส้นทางที่แจกแจงได้ไปป้อนเข้าการจำลอง ในระหว่างนั้นผู้เขียนจะแสดงให้เห็นแบบดิบ ๆ ว่า AI ช่วยได้ถึงไหน และมันโกหกตรงไหน

4.3.1 คอมโบไม่ใช่ตาราง แต่เป็นกราฟ

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

ดังนั้นรูปร่างที่แท้จริงของคอมโบจึงเป็น กราฟแบบมีทิศทาง (directed graph) แอ็กชันคือโหนด การเชื่อมต่อคือเอดจ์ แต่ละเอดจ์มีหน้าต่างอินพุต (input window — รับอินพุตเมื่อไหร่) และคีย์อินพุตติดอยู่ โหนดมีเฟรมที่กินเวลาติดอยู่ และบางโหนดมีเงื่อนไขโบนัส (ต้องผ่านโหนดเฉพาะจึงจะได้ตัวคูณดาเมจ) ติดอยู่

ถ้าวาดคอมโบพื้นฐานหนึ่งชุดของตัวละครนักรบเป็นกราฟก็จะได้ดังนี้ หกโหนด รวมกิ่งคานเซิล

จุดที่ต่างจากไวต์บอร์ดอย่างชัดเจนมีสองอย่าง อย่างแรก แต่ละเอดจ์มีช่วงเฟรมของหน้าต่างอินพุตระบุไว้ "โจมตีหนัก 6\~24f" หมายความว่ารับอินพุตการโจมตีหนักได้ตั้งแต่เฟรมที่ 6 จนถึงเฟรมที่ 24 หลังจากเบสิก2 เริ่มขึ้น อย่างที่สอง มีเอดจ์เข้าเบสิก1 ใหม่จากการหลบ (หลบ→เบสิก1) ที่วาดด้วยเส้นประ นี่คือเส้นทางที่สมาชิกทีม B ตอบทันทีในห้องประชุมไม่ได้ เมื่อระบุลงในกราฟแล้ว "มี/ไม่มี" ก็ชัดเจน

ถ้าคนวาดกราฟนี้ด้วยมือ ก็จะได้หกโหนดและเอดจ์เจ็ดแปดเส้น ถ้ามีตัวละครยี่สิบตัว และแต่ละตัวมีชุดคอมโบสามสี่ชุด กราฟก็จะกลายเป็นหลายร้อยแผ่น มือตามไม่ทัน ดังนั้นเราจึงเขียนกราฟไว้เป็น สเปกข้อความ (text spec) แล้วสร้างรูปภาพและการตรวจสอบขึ้นจากตรงนั้นโดยอัตโนมัติ

4.3.2 สเปกที่คนอ่านได้แต่เครื่องพาร์สได้

เราย้ายกราฟข้างต้นไปเป็นสเปก YAML แก่นกลางคือสามบล็อก ได้แก่ โหนด (nodes) เอดจ์ (edges) และโบนัส (bonuses) กฎคานเซิลก็มองเป็นเอดจ์ชนิดหนึ่งด้วย เพราะการตัดแล้วไปยังโหนดอื่นก็คือเอดจ์เช่นกัน

# warrior_basic_chain.yaml
character: warrior
combo_id: basic_chain

nodes:
  - { id: basic_1,  name: เบสิก1,   duration_frames: 21 }
  - { id: basic_2,  name: เบสิก2,   duration_frames: 24 }
  - { id: basic_3,  name: เบสิก3,   duration_frames: 30 }
  - { id: heavy,    name: โจมตีหนัก,  duration_frames: 33 }
  - { id: launch,   name: ดีดขึ้น,  duration_frames: 28 }
  - { id: dodge,    name: หลบ,    duration_frames: 18, cancels_recovery: true }

edges:
  - { from: basic_1, to: basic_2, input: light, window: [10, 21] }
  - { from: basic_2, to: basic_3, input: light, window: [12, 24] }
  - { from: basic_2, to: heavy,   input: heavy, window: [6, 24] }
  - { from: heavy,   to: launch,  input: heavy, window: [10, 33] }
  - { from: heavy,   to: dodge,   input: dodge, window: [0, 33], type: cancel }
  - { from: basic_3, to: dodge,   input: dodge, window: [0, 30], type: cancel }
  - { from: dodge,   to: basic_1, input: light, window: [8, 18] }   # เข้าใหม่

bonuses:
  - { on: basic_3, requires_path: [basic_1, basic_2], damage_multiplier: 1.5 }

สเปกนี้ตอบสนองผู้อ่านสองฝ่ายพร้อมกัน คนอ่าน window: [6, 24] แล้วเข้าใจว่า "การโจมตีหนักเริ่มรับได้ตั้งแต่ช่วงกลางของเบสิก2" ส่วนเครื่องพาร์สบรรทัดเดียวกันเพื่อใช้วาดกราฟและแจกแจงเส้นทาง ความเข้าใจของคนและการตรวจสอบของเครื่องออกมาพร้อมกันจากแหล่งเดียว

ค่าเฟรมข้างต้น (21, 24, [6, 24]) ไม่ใช่ค่าที่วัดจริง แต่เป็นค่าตัวอย่างที่ผู้เขียนกำหนดขึ้นเพื่ออธิบายในบทนี้ (ยังไม่ได้ตรวจสอบ) ในโปรเจกต์จริง ค่าเหล่านี้มาจากความยาวมอนทาจที่แอนิเมเตอร์สร้างและไทมิงของโนทิฟายในบิลด์ ตอนเขียนสเปกครั้งแรกให้ใส่ค่าตามเจตนาของดีไซเนอร์ไปก่อน แล้วเมื่อบิลด์ออกมาก็แคปเจอร์มาแก้ให้เป็นค่าที่วัดจริง ลูปการแก้ค่านี้จะกล่าวถึงใน 4.4

4.3.3 บันทึกเซสชันจริง (worked transcript) — จากภาษาธรรมชาติถึงสเปก

เราเอากฎที่สมาชิกทีม B วาดไว้บนไวต์บอร์ดมาให้เป็นภาษาธรรมชาติ แล้วให้แปลงเป็นสเปก YAML ผู้เขียนจะคัดลอกพรอมต์ฉบับเต็ม ผลลัพธ์ดิบของ Claude และการตรวจสอบ/ปฏิเสธของคนมาตามจริงโดยไม่สรุปย่อ

พรอมต์ (ฉบับเต็ม)

ต่อไปนี้คือกฎคอมโบของตัวละครนักรบ จงแปลงสิ่งนี้เป็นสเปกคอมโบ YAML

กฎ:
- การโจมตีพื้นฐานต่อกันเป็นจังหวะที่ 1, 2, 3 ด้วยคีย์โจมตีเบา
- ถ้ากดคีย์โจมตีหนักระหว่างเบสิก2 จะแยกออกไปเป็นการโจมตีหนักได้
- ถ้ากดโจมตีหนักอีกครั้งหลังการโจมตีหนัก จะดีดศัตรูขึ้น (ดีดขึ้น)
- การโจมตีหนักคานเซิลด้วยการหลบได้ตลอดเวลา
- เบสิก3 ก็คานเซิลด้วยการหลบได้
- ทันทีหลังหลบ สามารถเริ่มเบสิก1 ใหม่ด้วยการโจมตีเบาได้
- เบสิก3 จะมีดาเมจ 1.5 เท่าก็ต่อเมื่อผ่านทั้งเบสิก1 และเบสิก2 แล้วเท่านั้น

รูปแบบสเปก:
- nodes(id, name, duration_frames), edges(from, to, input, window, type),
  bonuses(on, requires_path, damage_multiplier)
- เอดจ์คานเซิลให้ระบุด้วย type: cancel
- ค่าเฟรมที่ฉันไม่ได้ให้ ห้ามนายกำหนดเอง ให้เว้นไว้เป็น TODO

บรรทัดสุดท้ายคือแก่น ระบุชัดว่าถ้าไม่ได้ให้ค่าเฟรมมา ก็ห้ามกุขึ้น นี่คือการบังคับมาตรฐาน v3 ข้อ 3 (ความซื่อตรงของตัวเลข) ในระดับพรอมต์

ผลลัพธ์ดิบของ Claude (ไม่ได้แก้ไข)

แปลงเป็นสเปกแล้ว ค่าเฟรมไม่ได้ถูกให้มา จึงเว้นไว้เป็น TODO

```yaml
character: warrior
combo_id: basic_chain
nodes:
  - { id: basic_1, name: เบสิก1, duration_frames: TODO }
  - { id: basic_2, name: เบสิก2, duration_frames: TODO }
  - { id: basic_3, name: เบสิก3, duration_frames: TODO }
  - { id: heavy,   name: โจมตีหนัก, duration_frames: TODO }
  - { id: launch,  name: ดีดขึ้น, duration_frames: TODO }
  - { id: dodge,   name: หลบ,   duration_frames: TODO }
edges:
  - { from: basic_1, to: basic_2, input: light, window: TODO }
  - { from: basic_2, to: basic_3, input: light, window: TODO }
  - { from: basic_2, to: heavy,   input: heavy, window: TODO }
  - { from: heavy,   to: launch,  input: heavy, window: TODO }
  - { from: heavy,   to: dodge,   input: dodge, window: TODO, type: cancel }
  - { from: basic_3, to: dodge,   input: dodge, window: TODO, type: cancel }
  - { from: dodge,   to: basic_1, input: light, window: TODO }
bonuses:
  - { on: basic_3, requires_path: [basic_1, basic_2], damage_multiplier: 1.5 }
```

ส่วนที่ต้องยืนยัน:
1. "เริ่มเบสิก1 ใหม่ทันทีหลังหลบ" ใส่ไว้เป็นเอดจ์ dodge -> basic_1 แต่ยังไม่ชัด
   ว่าเป็นการรับอินพุตระหว่างช่วงดีเลย์ท้ายท่าของการหลบ หรือหลังจากการหลบจบไปแล้วโดยสมบูรณ์
2. กฎไม่ได้ระบุว่ามีคอมโบกลางอากาศต่อจากการดีดขึ้น (launch) หรือไม่
   ต้องยืนยันว่าการดีดขึ้นเป็นจุดจบของคอมโบหรือไม่
3. ยังไม่ชัดว่าจะวางการหลบเป็นโหนด หรือเป็นเพียงเอดจ์ (แอ็กชันคานเซิล) ตอนนี้วางไว้
   เป็นโหนดก่อน โดยมองว่าตัวการหลบเองเป็นแอ็กชันที่มีระยะเวลากินเฟรม

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

จุดที่ยังก้ำกึ่ง คือข้อ 3 ที่วางการหลบเป็นโหนดนั้นเป็นเรื่องที่ความเห็นแยกกันได้ การหลบเป็นทั้ง "แอ็กชันคานเซิล" และในขณะเดียวกันก็เป็น "แอ็กชันที่มีระยะเวลากินเฟรม" จึงถูกทั้งสองด้าน การที่ AI เลือกด้านหนึ่งไว้แล้วรายงานว่ามันคลุมเครือนั้นซื่อตรง แต่นี่เป็นการตัดสินใจด้านการออกแบบ คนจึงต้องเป็นผู้กำหนด

การตรวจสอบ/ปฏิเสธของคน

ตอบคำถามสามข้อและปฏิเสธบางส่วน

• ข้อ 1 (ไทมิงการเข้าใหม่): รับอินพุตในช่วงดีเลย์ท้ายท่าของการหลบ (8\~18f) ไม่ใช่หลังจากดูการหลบจนจบ แต่เป็นการคานเซิลดีเลย์ท้ายท่าเพื่อเข้าเบสิก1 ใหม่ → รับมา window: [8, 18]
• ข้อ 2 (หลังการดีดขึ้น): ในขอบเขตของบทนี้ ให้การดีดขึ้นเป็นจุดจบของคอมโบ คอมโบกลางอากาศแยกเป็นชุดต่างหาก → รับการตัดสินของ AI มา
• ข้อ 3 (หลบ=โหนด): วางเป็นโหนด แต่เพิ่มแอตทริบิวต์ cancels_recovery: true เพื่อระบุว่าเป็น "แอ็กชันที่ตัดดีเลย์ท้ายท่า" → รับมาบางส่วน + เพิ่มแอตทริบิวต์

และมีอีกหนึ่งอย่างที่ ปฏิเสธ AI ไม่ได้ติด type: cancel ให้เอดจ์ dodge → basic_1 ซึ่งจริง ๆ นี่เป็นการตัดดีเลย์ท้ายท่าของการหลบแล้วเข้า จึงมีลักษณะเป็นคานเซิลตรงตามนั้น แต่ตรงนี้เรามองว่าเป็น "การเข้าตามปกติหลังหลบ" และวางไว้เป็นเอดจ์ทั่วไป เพราะการแยกระหว่างการคานเซิลดีเลย์ท้ายท่ากับการเชื่อมต่อตามปกติไม่ทำให้ฟีลของเกมต่างกันในตัวละครนี้ นี่เป็นตัวอย่างที่คนใช้การตัดสินเชิงโดเมนมาเขียนทับการจัดประเภทของ AI

คำขอใหม่

ดี ต่อไปจงนำสิ่งเหล่านี้มาปรับแล้วออกสเปกฉบับสุดท้ายอีกครั้ง:
- เพิ่ม cancels_recovery: true ให้ dodge
- window ของเอดจ์ dodge -> basic_1 ให้เป็น [8, 18]
- ค่าเฟรมที่เหลือฉันยังไม่ได้ให้ จึงคง TODO ไว้ แต่ค่าตัวอย่างในกราฟข้างบน
  (basic_1=21, basic_2=24, basic_3=30, heavy=33, launch=28, dodge=18)
  ฉันจะใช้ ดังนั้นให้เติมด้วยค่าเหล่านั้น และให้ตรึงไว้ในคอมเมนต์ว่านี่เป็นค่าตัวอย่างที่ยังไม่ได้ตรวจสอบ

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

4.3.4 แจกแจงเส้นทางโดยอัตโนมัติ

เนื่องจากสเปกเป็นกราฟ การแจกแจงเส้นทางคอมโบจึงกลายเป็นปัญหาของ การค้นหาบนกราฟ เป็นการค้นหาแบบลึกก่อน (depth-first search, DFS) ทุกเส้นทางที่ออกจากโหนดเริ่มต้นไปจนถึงโหนดปลาย (หรือฟินิชเชอร์) คนทำสิ่งนี้ในหัวไม่ได้ แต่โค้ดทำได้ในชั่วพริบตา

ใน 95_BattleTF ซึ่งเป็นพื้นที่ทำงานแบบแยกของทีมผู้เขียน มีสคริปต์เล็ก ๆ ที่รับผิดชอบการแจกแจงนี้ มันอ่านสเปก YAML ดึงทุกเส้นทางออกมา แล้วตรวจสอบว่าแต่ละเส้นทางเป็นไปได้ตามกฎหรือไม่ (เอดจ์มีอยู่จริงไหม) ถ้าแสดงเฉพาะลอจิกแก่นกลางก็จะเป็นดังนี้

# 95_BattleTF/enumerate_paths.py (ตัดตอน)
import yaml

def load_graph(path):
    spec = yaml.safe_load(open(path, encoding="utf-8"))
    adj = {}
    for e in spec["edges"]:
        adj.setdefault(e["from"], []).append(e)
    return spec, adj

def enumerate_paths(adj, start, max_depth=8):
    results = []
    def dfs(node, path, edges):
        # ถ้าเป็นโหนดปลาย (ไม่มีเอดจ์ออก) หรือถึงขีดจำกัดความลึก ให้ปิดเส้นทาง
        outs = adj.get(node, [])
        if not outs or len(path) >= max_depth:
            results.append((list(path), list(edges)))
            return
        for e in outs:
            if e["to"] in path:        # กันการวนซ้ำ: หนึ่งเส้นทางผ่านโหนดเดิมได้ครั้งเดียว
                results.append((list(path), list(edges)))
                continue
            dfs(e["to"], path + [e["to"]], edges + [e])
    dfs(start, [start], [])
    return results

เมื่อรันโดยเริ่มจาก basic_1 เส้นทางที่มือไม่มีทางกางออกได้หมดก็หลั่งไหลออกมา ถ้าดูเพียงบางส่วนก็จะเป็นดังนี้

ข้อ 3 และ 4 สำคัญ เพราะเอดจ์เข้าใหม่จากการหลบทำให้คอมโบ วนซ้ำ เส้นทางวนซ้ำแบบนี้แหละคือสิ่งที่คนมองไม่เห็นบนไวต์บอร์ด ถ้าไม่ใส่การ์ดกันการวนซ้ำ (ผ่านโหนดเดิมในเส้นทางเดียวได้ครั้งเดียว) ลงใน DFS การแจกแจงก็จะตกลงในลูปไม่รู้จบ นี่เป็นกับดักที่ผู้เขียนรู้จริงตอนรันโค้ดครั้งแรกแล้วมันหยุดค้างไปจริง ๆ ครั้งหนึ่ง ถ้ากราฟมีการวนซ้ำ ตัวแจกแจงต้องมีการ์ดเสมอ

ผลผลิตของขั้นแจกแจงมีสองอย่าง อย่างแรก รายการทุกเส้นทางที่เป็นไปได้ตามกฎ อย่างที่สอง การตรวจจับความขัดแย้งของกฎ ถ้าในสเปกมีเอดจ์ dodge → basic_1 แต่กลับไม่มีนิยามของโหนด dodge ตัวแจกแจงจะจับได้ว่าเป็น "เอดจ์ที่ชี้ไปยังโหนดที่ไม่ได้นิยามไว้" ความผิดพลาดที่พบบ่อยที่สุดเวลาเขียนสเปกด้วยมือคือการอ้างอิงลอย (dangling reference) นี้

4.3.5 ป้อนเส้นทางที่แจกแจงได้เข้าการจำลอง

ลำพังรายการเส้นทางอย่างเดียวเราไม่รู้ว่า "เส้นทางไหนแรงเกินไป" ต้องเอาแต่ละเส้นทางใส่เข้าตัวจำลอง DPS (DPS = ดาเมจต่อวินาที) simulate_dps ของทีมผู้เขียนทำหน้าที่นี้ มันรับเส้นทาง (ลำดับโหนด) พร้อมดาเมจ·เฟรมของแต่ละโหนดและกฎโบนัส แล้วคำนวณดาเมจรวมและเฟรมรวมที่ใช้ จากนั้นออกเป็นดาเมจต่อวินาที (DPS)

# 95_BattleTF/simulate_dps.py (ตัดตอน, สมมติ 60fps)
def simulate(path_nodes, node_dmg, node_frames, bonuses):
    total_dmg = 0
    total_frames = 0
    visited = []
    for nid in path_nodes:
        dmg = node_dmg.get(nid, 0)
        # โบนัส: ถ้าผ่าน requires_path ครบทั้งหมด ให้ใช้ตัวคูณ
        for b in bonuses:
            if b["on"] == nid and all(r in visited for r in b["requires_path"]):
                dmg *= b["damage_multiplier"]
        total_dmg += dmg
        total_frames += node_frames[nid]
        visited.append(nid)
    seconds = total_frames / 60.0
    return {"dmg": total_dmg, "frames": total_frames,
            "dps": round(total_dmg / seconds, 1) if seconds else 0}

ถ้าไหลผลการแจกแจงจาก 4.3.4 เข้ามาทั้งก้อนตรงนี้ DPS ของแต่ละเส้นทางก็จะหล่นออกมาเป็นตาราง ด้านล่างคือผลที่ได้จากการใส่ดาเมจของโหนดเป็นค่าตัวอย่าง (ตีพื้นฐาน 100, โจมตีหนัก 180, ดีดขึ้น 140 — ทั้งหมดเป็นค่ากำกับที่ยังไม่ได้ตรวจสอบ) แล้วรัน

ตารางนี้เปลี่ยนบทสนทนา สัญชาตญาณที่ว่า "กิ่งโจมตีหนักดูแรงกว่าสามจังหวะมาตรฐานนะ" เปลี่ยนเป็นตัวเลข "DPS เส้นทางโจมตีหนัก 294 vs มาตรฐาน 280 เหนือกว่า 5%" ถ้า 5% ที่เหนือกว่าเป็นไปตามเจตนาก็ผ่าน ถ้าไม่ใช่ก็เพิ่มเฟรมของการโจมตีหนักเพื่อลด DPS ลง เราตัดสินใจเรื่องนี้ในขั้นสเปก ก่อน ที่บิลด์จะออกมา

ถ้ามองเวิร์กโฟลว์ทั้งหมดในแผ่นเดียวก็จะเป็นดังนี้

flowchart LR
    A["กฎภาษาธรรมชาติ
(teammate_b ไวต์บอร์ด)"] --> B["พรอมต์ → AI"]
    B --> C{"สเปกดิบ
มี TODO·คำถาม"}
    C -->|คนตรวจสอบ/ปฏิเสธ| D["สเปก YAML ฉบับยืนยัน
warrior_basic_chain.yaml"]
    D --> E["enumerate_paths.py
แจกแจงทุกเส้นทางด้วย DFS"]
    E --> F["ตรวจจับความขัดแย้งของกฎ
เอดจ์ลอย·วนซ้ำไม่รู้จบ"]
    E --> G["simulate_dps.py
คำนวณ DPS รายเส้นทาง"]
    G --> H["ตัดสินบาลานซ์
ส่วนต่าง DPS ระหว่างเส้นทาง"]
    F --> D
    H -->|ปรับเฟรม| D

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    class E,F,G code;
    class B,C ai;
    class H human;
    class A,D data;

สเปก (D) อยู่ตรงกลาง และการแจกแจง (E) การตรวจสอบ (F) การจำลอง (G) ก็แตกกิ่งออกไปจากตรงนั้น ถ้าจับความขัดแย้งได้หรือบาลานซ์ผิดเพี้ยน ก็ย้อนกลับมาที่สเปกเพื่อแก้ ไวต์บอร์ดไม่มีลูปนี้ คอมโบบนไวต์บอร์ดจึงรู้ว่าผิดก็ต่อเมื่อมันเข้าไปอยู่ในบิลด์แล้วเท่านั้น

4.3.6 คานเซิลและคิวอินพุต — สองมือจับที่เพิ่มและบีบเส้นทาง

ที่ผ่านมาเราได้ดูกราฟคอมโบและการแจกแจงเส้นทาง คานเซิลและคิวอินพุตคือมือจับสองอันที่ปรับกราฟนี้ ทิศทางของทั้งสองตรงข้ามกัน

คานเซิลเพิ่มเอดจ์ ทุกครั้งที่เพิ่มกฎคานเซิลหนึ่งข้อ จะมีเอดจ์มาติดที่กราฟ และจำนวนเส้นทางที่แจกแจงได้ก็พองตัวขึ้นแบบทวีคูณ ดังนั้นคานเซิลจึงไม่ใช่ "ยิ่งใจกว้างยิ่งดี" ยิ่งปลดคานเซิลออกมากเท่าไหร่ เส้นทางก็ยิ่งระเบิด และโอกาสที่เส้นทางแรงเกินคาด (อย่างเส้นทางวนซ้ำในหัวข้อก่อนหน้า) จะปนเข้ามาก็ยิ่งสูงขึ้น นี่คือเหตุผลที่ประเพณีเกมต่อสู้วางคานเซิลไว้อย่างเข้มงวด และที่เกมแอ็กชัน RPG วางไว้อย่างใจกว้าง แนวเกมเป็นตัวกำหนด "จำนวนเส้นทางที่จะอนุญาต" ไม่มีค่าหน้าต่างที่ถูกต้องแบบสัมบูรณ์

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

คิวอินพุตไม่ได้บีบเส้นทาง แต่ทำให้เหยียบได้จริง ถ้าไม่มีคิว ผู้เล่นต้องกะหน้าต่างอินพุตของแต่ละเอดจ์ (เช่น [12, 24]) ให้ตรงระดับเฟรม ซึ่งแทบเป็นไปไม่ได้ด้วยปฏิกิริยาของคน คิวจะเก็บอินพุตที่กดก่อนหน้าต่างไว้ในบัฟเฟอร์ แล้วลั่นออกโดยอัตโนมัติในวินาทีที่หน้าต่างเปิด นั่นคือคิวไม่ได้เปลี่ยนเส้นทางของกราฟ แต่ใส่รองเท้าให้คนเดินบนกราฟได้

input_queue:
  window_start_ratio: 0.5   # เริ่มบัฟเฟอร์อินพุตถัดไปจากความคืบหน้าแอ็กชัน 50%
  expire_frames: 10         # อายุที่ใช้ได้ของอินพุตที่ถูกบัฟเฟอร์
  priority: latest          # เมื่อมีอินพุตหลายตัวพร้อมกัน ให้ตัวสุดท้ายมาก่อน

ความสมดุลของสามพารามิเตอร์คือแก่น ถ้า window_start_ratio เล็กเกินไป อินพุตช่วงต้นแอ็กชันก็จะถูกบัฟเฟอร์ด้วย ทำให้แอ็กชันถัดไปที่ไม่ได้ตั้งใจเด้งออกมา ถ้า expire_frames สั้นเกินไป คิวก็หมดความหมาย กลับไปเรียกร้องความแม่นยำอีก แต่ถ้ายาวเกินไป อินพุตที่กดไปนานแล้วก็ลั่นออกมาช้า ๆ เกิดเหตุ "ทำไมจู่ ๆ ถึงขยับ" ค่าตั้งต้นที่แนะนำคือ expire_frames 5\~15 และ window_start_ratio ราว 0.5 แต่นี่เป็นเส้นเริ่มต้นที่ต้องปรับตามแนวเกมและความหนักหน่วงของตัวละคร ไม่ใช่คำตอบสำเร็จรูป

เรื่องเชิงปฏิบัติการอีกหนึ่งข้อ อย่าตั้งค่าพารามิเตอร์คิวอินพุตให้ต่างกันหมดในแต่ละตัวละคร ให้มีค่าเริ่มต้นแบบโกลบอลหนึ่งชุด แล้ว override เฉพาะตัวละครที่ความหนักหน่วงต่างเป็นพิเศษ (แบบบอสตัวยักษ์เป็นต้น) ถ้าจัดการค่าคิวของตัวละครยี่สิบตัวแยกกัน ก็จะแยกไม่ออกว่าค่าไหนเป็นความต่างที่ตั้งใจ และค่าไหนเป็นความผิดพลาด

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

• Cancel Notify: จะเริ่มตัดแอนิเมชันปัจจุบันแล้วรับอินพุตถัดไปตั้งแต่จุดไหน หน้าต่างเอดจ์ข้างต้น (window: [10, 21]) ก็คือการแสดงออกของโนทิฟายนี้นั่นเอง ถ้าเลื่อนโนทิฟายมาเร็วขึ้น คอมโบก็จะเร็วขึ้น (ไปยังท่าถัดไปก่อนที่การตีจะจบ) ถ้าเลื่อนช้าลง แต่ละจังหวะก็จะหนักแน่นขึ้น นั่นคือค่าเริ่มต้นของหน้าต่างไม่ใช่แค่ตัวเลขธรรมดา แต่เป็นการตัดสินด้านสัมผัสว่า "จะโชว์การตีนี้จนจบ หรือจะรีบข้ามไปท่าถัดไป"
• Anim Blending: ผสมระหว่างสองโหนดให้เนียนแล้วข้ามไป จากท่าจบของการโจมตีหนักไปยังท่าเริ่มของการดีดขึ้น โดยอินเตอร์โพเลตข้ามกันไปกี่เฟรม การเชื่อมต่อจะลื่นไหลเป็นธรรมชาติ แต่ในช่วงเบลนดิงมักเกิดช่องว่างของการตรวจจับการตี และ "รสชาติของการตัดขาด" ก็จะหายไป
• Frame Skip: ข้ามเฟรมที่เหลือของแอนิเมชันปัจจุบันโดยไม่เบลนดิง แล้วเริ่มโหนดถัดไปทันที การเชื่อมต่อจะฉับไวและตอบสนองเร็ว แต่ท่าทางอาจดูสะดุดเป็นช่วง ๆ "ฟีลคานเซิล" ของเกมต่อสู้·แอ็กชันส่วนใหญ่เป็นแบบนี้

ทั้งสามนี้ทำให้สัมผัสมือของเกมตรงข้ามกันโดยสิ้นเชิงแม้จะเป็นเอดจ์เดียวกัน ในขั้นสเปกให้กำหนดเพียงการมีอยู่ของเอดจ์และหน้าต่าง ส่วนวิธีเชื่อมต่อ (เบลนดิง vs เฟรมสกิป) มักจะกำหนดร่วมกับแอนิเมเตอร์ในขั้นบิลด์ อย่างไรก็ตามถ้าเว้นฟิลด์หนึ่งบรรทัดแบบ transition: blend / transition: skip ไว้ในสเปกล่วงหน้า ในขั้นบิลด์ก็ไม่ต้องมาถามซ้ำว่า "เอดจ์นี้ตกลงให้ข้ามแบบไหนนะ" วิธีเชื่อมต่อคือแกนที่สามที่ซ่อนอยู่ของกราฟคอมโบ

4.3.7 การตรวจสอบบิลด์เป็นงานต่างหาก (เกริ่น 4.4)

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

การดึง 5 สัญญาณ (เฟรมที่การตีเกิดขึ้น, ดีเลย์ท้ายท่า, หน้าต่างคานเซิล, คิวอินพุต, ฮิตสต็อป) จากวิดีโอบิลด์โดยอัตโนมัติมีความยากในการอิมพลิเมนต์สูง สิ่งที่น่าเชื่อถือที่สุดในทางปฏิบัติคือเทเลเมทรีภายในเกม ให้ในบิลด์บันทึกล็อกว่า "แอ็กชันนี้รับอินพุตนี้ที่เฟรมนี้" แล้วเอาล็อกนั้นมาเทียบกับสเปก (การเปรียบเทียบวิธีแคปเจอร์ดูใน 4.4) ลูปการเทียบนี้คือหัวข้อของ 4.4 ถ้าหน้าต่างที่สเปกระบุว่า [12, 24] วัดได้ในบิลด์เป็น [14, 26] ก็แก้สเปกให้ตรงกับค่าที่วัดจริงในบิลด์

4.3.8 ความผิดพลาดที่พบบ่อยและวิธีหลีกเลี่ยง

สรุปประเด็นสำคัญของบท

• คอมโบไม่ใช่เส้นตรงแต่เป็นกราฟ ดังนั้นเส้นทางจึงแจกแจงด้วยโค้ดไม่ใช่ด้วยคน
• คานเซิลคือมือจับที่เพิ่มเส้นทาง คิวอินพุตคือรองเท้าที่ทำให้เดินบนเส้นทางได้
• แม้เป็นเอดจ์เดียวกัน วิธีเชื่อมต่อ (Cancel Notify·Anim Blending·Frame Skip) ก็ทำให้สัมผัสมือตรงข้ามกันโดยสิ้นเชิง
• การตรวจสอบบนสเปกกับการตรวจสอบบนบิลด์เป็นคนละงาน และอย่างหลังเทเลเมทรีคือทางที่เป็นไปได้จริง

ลองทำดู — มินิไปป์ไลน์แจกแจงเส้นทางคอมโบ

นี่คือขั้นตอนขั้นต่ำที่คุณลองรันตามด้วยมือได้ ขอเพียงมีไพทอนและ pyyaml ก็พอ

setup. สร้างโฟลเดอร์ทำงานหนึ่งโฟลเดอร์ แล้ววางไฟล์สเปกและสคริปต์สองตัวไว้ในนั้น

combo-mini/
  warrior_basic_chain.yaml   # สเปกจาก 4.3.2
  enumerate_paths.py         # ตัวแจกแจง DFS จาก 4.3.4
  simulate_dps.py            # ตัวจำลองจาก 4.3.5

หลัง pip install pyyaml ให้แปะ YAML จาก 4.3.2 ลงในไฟล์สเปกตามนั้นเลย

prompt. ขั้นเปลี่ยนกฎภาษาธรรมชาติเป็นสเปกให้ฝากไว้กับ AI ใช้พรอมต์จาก 4.3.3 ตามนั้น แต่ต้องใส่ข้อจำกัดท้ายสุดเข้าไปด้วยเสมอ

ค่าเฟรมที่ฉันไม่ได้ให้ ห้ามนายกำหนดเอง ให้เว้นไว้เป็น TODO
เอดจ์คานเซิลให้ระบุด้วย type: cancel และส่วนที่คลุมเครือให้แยกออกมาเป็นคำถามต่างหาก

สองบรรทัดนี้กันการกุตัวเลขและการตัดสินตามอำเภอใจของ AI จากสเปกที่ออกมาให้คนเป็นผู้เติม TODO และรายการคำถาม

verify. เมื่อสเปกเสร็จแล้วให้ตรวจสอบสองครั้ง

python enumerate_paths.py warrior_basic_chain.yaml   # ทุกเส้นทาง + ความขัดแย้ง
python simulate_dps.py    warrior_basic_chain.yaml   # ตาราง DPS รายเส้นทาง

จากผลการแจกแจง ให้ตรวจว่า (1) เส้นทางวนซ้ำไม่เพิ่มขึ้นแบบไม่รู้จบหรือไม่ (2) ไม่มีเอดจ์ลอยที่ชี้ไปยังโหนดที่ไม่ได้นิยามไว้หรือไม่ จากผลของ DPS ให้ดูว่าส่วนต่างระหว่างเส้นทางอยู่ในช่วงที่ตั้งใจหรือไม่ ถ้าส่วนต่างมาก ให้แก้ค่าเฟรม/ดาเมจของสเปกแล้วรันใหม่

ฉบับย่อสำหรับคนเดียว

ถ้าไม่มีเวลาสร้างเครื่องมือต่างหาก ก็จบการเขียนสเปกและการแจกแจงเส้นทางด้วยบทสนทนา AI ครั้งเดียวเลย ให้กฎภาษาธรรมชาติไปแล้วใส่ลงในพรอมต์เดียวว่า "เปลี่ยนเป็นสเปกคอมโบ YAML แล้วไล่เรียงทุกเส้นทางที่เป็นไปได้จากโหนดเริ่มต้นแบบลึกก่อนให้หมด การวนซ้ำให้ตัดให้วนแค่ครั้งเดียว ถ้ามีเอดจ์ที่ชี้ไปยังโหนดที่ไม่ได้นิยามไว้ให้ทำเครื่องหมายไว้" AI จะทำการแปลงเป็นสเปก·การแจกแจง·การตรวจจับความขัดแย้งให้ในครั้งเดียว ส่วนการจำลอง DPS ถ้าให้ดาเมจของโหนดมาเป็นตารางด้วย ก็รับได้ด้วยคำขอตามมาว่า "คำนวณดาเมจรวมและเฟรมของแต่ละเส้นทางแล้วทำเป็นตารางให้" ความแม่นยำจะลดลง แต่ก็มองได้ไกลกว่าไวต์บอร์ดมาก แก่นไม่เปลี่ยน — อย่ากางคอมโบในหัว แต่ให้แจกแจงออกมาแล้วดู

4.4 การจำลองและตรวจสอบการต่อสู้ด้วยความช่วยเหลือของ AI

บิลด์ #234 ของทีม TF การต่อสู้เพิ่งขึ้นมาหมาด ๆ เป็นบิลด์แรกที่ได้สัมผัสสกิลใหม่ skill_thunder ในเอกสารระบุว่า hit timing อยู่ที่ 150ms ผมลองกดอินพุตดู ความรู้สึกที่ปลายนิ้วบอกว่า ช้า ช้าแน่ ๆ ผมเรียกเพื่อนร่วมทีม A ที่นั่งข้าง ๆ ว่า "อันนี้มันดูลอย ๆ หน่อยไหม" เพื่อนร่วมทีม A ลองกดสองสามที "อืม… ก็เหมือนจะใช่อยู่" ทั้งคู่ไม่มั่นใจ เอกสารบอกว่า 150 แต่มือยืนยันว่าราว ๆ 200 ใครกันแน่ที่ถูก ศึกระหว่างปลายนิ้วกับกระดาษ ในบิลด์ถัดไปก็จะมีใครสักคนพูดอีกว่า "รู้สึกว่าก็โอเคนะ" และเพียงคำพูดประโยคเดียวนั้น บิลด์อีกหนึ่งบิลด์ก็ไหลผ่านไป

เป้าหมายของบทนี้คือการยุติศึกนั้น ถ้าปลายนิ้วบอกว่า 200 ก็แสดงให้เห็นด้วยตัวเลขว่ามันเป็น 200 จริงหรือไม่ และก่อนที่บิลด์จะขึ้นมา ให้รู้ล่วงหน้าเพียงแค่ดูจากเอกสารว่า "สกิลนี้มี DPS สูงกว่าเป้าหมาย 30%" แม้แต่ในสมัยที่ผมจัดการการต่อสู้ของเกม AAA MMORPG ที่มีคนทำงานร่วมกัน 200 คนตั้งแต่ช่วงต้น ความอึดอัดเมื่อความรู้สึกกับตัวเลขไม่ตรงกันก็เหมือนเดิม สิ่งที่เปลี่ยนไปคือ ตอนนี้เรามีเครื่องมือที่จะปิดความไม่ตรงกันนั้นด้วยตัวเลขอยู่ในมือแล้วเท่านั้นเอง

ถ้า 4.2 และ 4.3 พูดถึงว่าจะ เขียน เอกสารการต่อสู้อย่างไร 4.4 ก็พูดถึงว่าเอกสารนั้น ทำงาน ตามที่ตั้งใจไว้หรือไม่ การตรวจสอบมีสองแกน แกนหนึ่งคือการจำลอง (simulation) ที่ตรวจสอบด้วยการคำนวณล้วน ๆ โดยไม่ต้องมีบิลด์ อีกแกนหนึ่งคือการวิเคราะห์การจับภาพ (capture analysis) ที่ดึงค่าที่วัดได้ออกมาจากวิดีโอบิลด์จริง เมื่อสองแกนถูกผูกเข้าเป็นรอบเดียวกัน จำนวนรอบของการออกแบบการต่อสู้ก็ลดจากหน่วยวันลงมาเหลือหน่วยชั่วโมง

ขอบอกข้อสรุปก่อน หัวใจของบทนี้คือ การวางตัวเลขที่ระบุในเอกสาร (150ms) กับตัวเลขที่วัดได้จากบิลด์ (220ms) ไว้เคียงกันแล้วอ่านความต่างนั้น (4.4.5) ส่วนหัวข้อก่อนหน้า (ตัวจำลอง·การแจกแจงคอมโบ) ให้อ่านเป็นขั้นเตรียมการที่ทำให้การเปรียบเทียบนั้นเป็นไปได้

4.4.1 ต้นทุนของการรอบิลด์

เมื่อนักออกแบบการต่อสู้ต้องการตรวจสอบสกิลใหม่หนึ่งสกิล จะเกิดอะไรขึ้นบ้าง

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

การจำลองคือเครื่องมือที่ให้คำตอบใน ขั้นแรกสุด ของรอบนี้ คำนวณดูจากเอกสารเพียงอย่างเดียว ถ้าคำตอบไม่ดีก็แก้เอกสารแล้วคำนวณใหม่ ก่อนเข้าสู่ขั้นบิลด์ซึ่งมีต้นทุนสูง ตัวเอกสารเองจะถูกกรองหนึ่งครั้ง เหมือนการเอารถจำลองเข้าอุโมงค์ลม (wind tunnel) ก่อน ก่อนที่จะนำรถจริงขึ้นถนน การออกแบบที่น่าสงสัยจะถูกคัดทิ้งบนโต๊ะทำงาน

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

4.4.2 simulate_dps — ตัวจำลองที่รันได้จริง

ซูโดโค้ดที่เป็นนามธรรมไม่สามารถตรวจสอบอะไรได้เลย ด้วยเหตุนี้จึงสร้างโค้ดที่ รันได้ ขึ้นมาตั้งแต่ต้น ด้านล่างคือโครงสร้างหลักของ simulate_dps.py ที่ผมใช้ในทีม TF การต่อสู้ ซึ่งเรียบเรียงใหม่เพื่อนำมาลงในหนังสือโดยตัดข้อมูลของบริษัทออก มันรันด้วยไลบรารีมาตรฐานของ Python เพียงอย่างเดียวโดยไม่มี dependency (ไฟล์ทั้งหมดดูได้ใน「ลองทำดู」)

อินพุตนั้นเรียบง่าย สกิลหนึ่งสกิลคือ dataclass ที่มี damage·cast_sec (เวลาครองการร่าย)·cooldown_sec·resource_cost ส่วนตัวละครมีปริมาณทรัพยากรรวม·ปริมาณฟื้นฟูต่อวินาที·รายการสกิล·ลำดับการหมุนเวียนตามความสำคัญ ตัวหลักที่รันอยู่บนนั้นมีเพียงกฎละโมบ (greedy) ที่เรียบง่ายว่า "ในทุกขณะ ให้ใช้สกิลที่มีลำดับความสำคัญสูงสุดในบรรดาสกิลที่ใช้ได้" เป้าหมายคือการหา ขีดสูงสุดในอุดมคติ ที่ไม่ฉลาดและไม่โง่ไปกว่าผู้เล่นจริง เมื่อตัดเฉพาะส่วนที่เป็นกระดูกสันหลังออกมาก็ได้ดังนี้

# สร้างไทม์ไลน์ด้วยติ๊ก 0.05 วินาที ถ้าไม่ได้อยู่ระหว่างร่าย ให้ใช้สกิลที่ใช้ได้ตัวแรกตามลำดับความสำคัญ
while t < duration_sec:
    resource = min(char.max_resource, resource + char.resource_regen * tick)
    for name in cooldowns:
        cooldowns[name] = max(0.0, cooldowns[name] - tick)
    if t >= busy_until:                     # ถ้าโมชันร่ายยังไม่จบ ให้รอ
        for name in char.rotation:          # ตามลำดับความสำคัญ
            s = skill_by_name[name]
            if cooldowns[name] <= 0 and resource >= s.resource_cost:
                total_damage += s.damage
                resource -= s.resource_cost
                cooldowns[name] = s.cooldown_sec
                busy_until = t + s.cast_sec  # ใช้สกิลถัดไปไม่ได้จนถึงเวลานี้
                break
    t += tick
# …(นิยาม dataclass·อินพุต warrior·ลูปเอาต์พุต ดูโค้ดทั้งหมดใน「ลองทำดู」)

เมื่อตั้ง skill_thunder (ดาเมจ 420·ร่าย 0.9s·คูลดาวน์ 6s) ไว้เป็นลำดับที่ 1 ให้ warrior แล้ววาง skill_dash·basic_1 ไว้ข้างหลัง รัน 20 วินาที ได้ผลลัพธ์ดังนี้ (python simulate_dps.py):

평균 DPS: 261.0
  t=  0.0s  skill_thunder  자원=60
  t=  0.9s  skill_dash     자원=47
  t=  1.3s  basic_1        자원=50
  t=  1.6s  basic_1        자원=53
  t=  1.9s  basic_1        자원=55
  ...

ค่านี้มีความหมายอย่างไร มันหมายความว่าเรารู้ว่าขีดสูงสุด DPS ในอุดมคติของ warrior อยู่ที่ราว 261 ได้ โดยไม่ต้องมีบิลด์ ภายใน 1 วินาที หากเป้าหมาย DPS คือ 180 เอกสารนี้ก็สูงเกินไป +45% ไม่ต้องรอบิลด์ แค่ปรับ damage หรือ cooldown_sec ตอนนี้ได้เลย

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

โน้ตการใช้ AI โครงสร้างข้างต้นผมเป็นคนเขียนเอง แต่เมื่อจะเพิ่มโมเดลทรัพยากรใหม่ (เช่น โครงสร้างที่เกจความโกรธจะเพิ่มขึ้นเมื่อได้รับดาเมจ) ให้ร้องขอกับ Claude โดย อ้างอิงโค้ดที่มีอยู่ เช่น "ช่วยเพิ่มกฎเมื่อโดนโจมตี ความโกรธ +5 ใน simulate_dps นี้ ภายในลูป tick โดยใช้ตัวแปรแยกต่างหากจากการฟื้นฟูทรัพยากรเดิม" หากสั่งให้สร้างตัวจำลองทั้งก้อนขึ้นมาจากกระดาษเปล่า จะได้โค้ดที่ตรวจสอบไม่ได้ออกมา กระดูกสันหลังให้คนจับ ส่วน AI ก็แตกกิ่งก้านออกไป

4.4.3 การแจกแจงเส้นทางคอมโบโดยอัตโนมัติ

ตัวเลข DPS เพียงตัวเดียวยังไม่พอ หากจะตรวจสอบว่า "คอมโบใดคือคอมโบหลักที่ตั้งใจไว้" ก็ต้องกาง เส้นทางที่เป็นไปได้ทั้งหมด ออกมาดู หากวาดทรีด้วยมือ แค่ 7\~8 โหนดหัวก็ระเบิดแล้ว การกางเส้นทางให้ครบถ้วนไม่ตกหล่นนั้น เครื่องทำได้ดีกว่าคนอย่างถล่มทลาย — แต่ต้องสั่งให้ดึงออกมาในรูปแบบที่คนสามารถย้อนทวนผลลัพธ์ได้

ต่อไปนี้คือโค้ดที่รับกราฟคอมโบ แจกแจงทุกเส้นทาง แล้วเรียงตาม DPS combo_graph คือการเขียน "หลังจากแอ็กชันใดสามารถ cancel ไปยังแอ็กชันใดได้" เป็น adjacency list ซึ่งถูกดึงออกมาจากเอกสาร state machine ของ 4.3 โดยตรง หัวใจคือเจเนอเรเตอร์ all_paths ที่กางด้วยการเรียกซ้ำ (recursion) จนถึงปลายทางตัน

# enumerate_combos.py — กางทุกเส้นทางของกราฟคอมโบแล้วเรียงตาม DPS
combo_graph = {"start": ["A"], "A": ["B", "D"], "B": ["C", "E"], "D": ["C"], "C": [], "E": []}
action_stats = {  # (ดาเมจ, เวลาที่ใช้ หน่วยวินาที)
    "A": (300, 0.8), "B": (450, 1.0), "C": (450, 1.2), "D": (600, 1.4), "E": (200, 0.6),
}

def all_paths(node="start", path=None):
    path = (path or [])
    nexts = combo_graph.get(node, [])
    if not nexts:                       # ปลายทางตัน = คอมโบที่สมบูรณ์
        yield [n for n in path if n in action_stats]
        return
    for nxt in nexts:
        yield from all_paths(nxt, path + [nxt])

results = []
for p in all_paths():
    dmg = sum(action_stats[a][0] for a in p)
    dur = sum(action_stats[a][1] for a in p)
    results.append((p, dmg, round(dur, 1), round(dmg / dur, 1)))

for p, dmg, dur, dps in sorted(results, key=lambda r: -r[3]):
    print(f"{' → '.join(p):<18} {dmg:>5} dmg  {dur:>4}s  DPS {dps}")

ผลการรัน:

A → D → C            1350    3.4s  DPS 397.1
A → B → C            1200    3.0s  DPS 400.0
A → B → E             950    2.4s  DPS 395.8

สัญญาณที่นักออกแบบควรอ่านจากตรงนี้ไม่ใช่แค่อันดับหนึ่งเรียบ ๆ แต่คือการที่ DPS ของสามเส้นทางอยู่ที่ 396\~400 แทบจะติดกัน — นี่คือสัญญาณว่า "ใช้คอมโบไหนประสิทธิภาพก็พอ ๆ กัน จึง ไม่มีอัตลักษณ์ของคอมโบหลัก" หากเจตนาคือ "A→D→C ควรเป็นคอมโบหลักแบบเสี่ยงสูงผลตอบแทนสูง" ก็ต้องเพิ่มดาเมจของ D หรือลดเวลาลงเพื่อดัน DPS ให้สูงขึ้นอีกขั้น ถึงเวลากลับไปที่เอกสารแล้ว

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

4.4.4 การวิเคราะห์การจับภาพบิลด์ — วิธีที่สมจริงคือ telemetry

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

แนวทาง A (วิเคราะห์พิกเซลวิดีโอ) ฟังดูน่าดึงดูด เป็นภาพที่ดึงห้าสัญญาณ — การแสดงอินพุต·การเปลี่ยนโมชันตัวละคร·เฟรมแรกของเอฟเฟกต์·รูปคลื่นเสียง·UI ตัวเลขดาเมจ — ออกมาจากหน้าจออัตโนมัติ แต่เมื่อลองสร้างจริง ความคลาดเคลื่อน ±1\~2 เฟรมจะมาเป็นพื้นฐานเพราะ noise จากการบีบอัดเฟรม·UI บัง·motion blur ที่ 60fps หนึ่งเฟรมคือราว 16.7ms ในการตรวจสอบที่นับ hit timing เป็นหน่วย ms นั้น noise ±33ms ถือเป็นเรื่องร้ายแรง ความยากในการสร้างสูงมาก แต่ความแม่นยำไม่คุ้มกับความพยายามนั้น

ด้วยเหตุนี้คำตอบในความเป็นจริงคือแนวทาง C คือ log telemetry ในเกม เอนจิน รู้เวลาที่แม่นยำอยู่แล้วภายใน ทั้งเวลาที่รับอินพุต·เวลาที่ animation notify เกิด·เวลาที่ VFX สปอว์น·เวลาที่ดาเมจถูกใช้ แทนที่จะอนุมานเวลานั้นจากพิกเซล ก็แค่ทำให้มันถูกบันทึกเป็น log หนึ่งบรรทัด แทนที่จะ กู้คืน 100ms จากพิกเซล ก็ รับเอา 100ms ที่เอนจินรู้มาจดไว้ตรง ๆ

// เพิ่มหนึ่งบรรทัดในโค้ดประมวลผลแอ็กชันการต่อสู้ (ตัวอย่างซูโด UE C++)
// เรียก logger ตัวเดียวกัน ณ จุดที่รับอินพุต / จุดที่ใช้ดาเมจ
CombatTelemetry::Log("input",  SkillName, GetWorld()->GetTimeSeconds());
CombatTelemetry::Log("hit",    SkillName, GetWorld()->GetTimeSeconds());

logger จะปล่อยออกมาทีละบรรทัดเป็น JSON Lines

{"event":"input","skill":"skill_thunder","t":12.340}
{"event":"hit",  "skill":"skill_thunder","t":12.560}
{"event":"input","skill":"basic_3","t":14.100}
{"event":"hit",  "skill":"basic_3","t":14.166}

ความต่างของเวลาระหว่าง input กับ hit ก็คือ hit timing ที่วัดได้นั่นเอง 12.560 − 12.340 = 0.220 วินาที = 220ms ไม่ใช่ ±33ms ของการวิเคราะห์พิกเซล แต่เป็นค่าเวลาของเอนจินตรง ๆ การดึง log นี้มาแล้วเทียบกับเอกสารคือเนื้อหาของหัวข้อถัดไป

4.4.5 บันทึกเซสชันจริง (worked transcript): เอกสาร 150ms vs ค่าวัด 220ms

ตอนนี้นำสองแกนมารวมไว้ที่เดียวกัน เอกสารสัญญา 150ms ส่วน telemetry วัดได้ 220ms +70ms ปลายนิ้วถูก เราจะติดตามกระบวนการบีบ สาเหตุ ของช่องว่างนี้ไปกับ AI จนจบ โดยไม่สรุปย่อ แต่ลงไว้ทั้งหมดแม้กระทั่งฉากที่ AI เดาผิดทางในตอนแรก

พรอมต์

เอกสารระบุ hit timing 150ms แต่ค่าวัดคือ 220ms แนบ log ด้านล่างแล้วถามด้วยความยาวเท่าที่คนพิมพ์จริง คำขอสั้น ๆ ที่เจตนาชัดเจนดีกว่าความเป็นทางการที่เยิ่นเย้อ — หนึ่งบรรทัดที่ให้เขียนถึงวิธีตรวจสอบด้วย กับอีกหนึ่งบรรทัดที่ห้ามฟันธง คือกระดูกสันหลังของพรอมต์นี้

hit timing ของ skill_thunder ระบุในเอกสาร 150ms แต่ค่าวัด 220ms เกิน +70ms จาก telemetry ด้านล่าง ช่วยแยกสาเหตุที่เป็นไปได้ และเขียนด้วยว่า แต่ละสาเหตุยืนยัน/ตัดออกได้ด้วย log ใด อย่าฟันธง ถ้าไม่แน่ใจให้เขียนว่า 'ยังไม่ยืนยัน' // "วิธีตรวจสอบด้วย"·"ห้ามฟันธง" สองอย่างนี้คือเจตนาหลัก ความเป็นทางการที่เหลือจะละไว้ผลลัพธ์ก็เหมือนเดิม

{"event":"input","skill":"skill_thunder","t":12.340}
{"event":"anim_start","skill":"skill_thunder","clip":"cast_thunder","t":12.340}
{"event":"anim_notify","skill":"skill_thunder","notify":"HitWindow","t":12.560}
{"event":"hit","skill":"skill_thunder","t":12.560}

ตามเอกสาร notify HitWindow ของ cast_thunder อยู่ที่จุด 0.150s

ผลลัพธ์ดิบของ Claude (ครั้งที่ 1 — ก่อนตรวจสอบ มีการเดาผิดทางรวมอยู่)

ผมประมาณสาเหตุของการเกิน +70ms เป็นสี่ข้อดังนี้

1. เลเทนซีเครือข่าย (network latency) อินพุตอาจวิ่งไป-กลับเซิร์ฟเวอร์แล้วเพิ่มมา 70ms หากเป็นบิลด์ multiplayer ให้ตรวจ RTT
2. เฟรมเรตตก หากบิลด์รันที่ 30fps หนึ่งเฟรมคือ 33ms ทำให้ timing ของ notify ถูกปัดเข้าขอบเฟรมและเกิดความล่าช้าสะสม
3. ความยาวโมชันร่ายเปลี่ยน คลิป cast_thunder อาจยาวกว่าในเอกสาร ทำให้ notify HitWindow ถูกเลื่อนไปข้างหลัง
4. บัฟเฟอร์อินพุตล่าช้า คิวอินพุตอาจถูกประมวลผลช้าไปหนึ่งติ๊ก

สาเหตุที่น่าจะเป็นไปได้มากที่สุดคือ ข้อ 1 เลเทนซีเครือข่าย 70ms เป็นช่วง RTT ที่พบได้ทั่วไป

การตรวจสอบ·ปฏิเสธโดยคน

หยุดตรงนี้แล้วกลับไปดู log อีกครั้ง การประมาณอันดับ 1 ของ AI (เครือข่าย) นั้น ถูกตัดออกด้วย log นี้อยู่แล้ว input กับ anim_start ถูกบันทึกที่เวลา 12.340 ตรงกันเป๊ะ หมายความว่าโมชันเริ่มทันทีในวินาทีที่อินพุตเข้ามา ไม่มีช่องว่างให้การวิ่งไป-กลับเครือข่ายแทรกได้เลย ข้อ 1 ผิด

ข้อ 2 (เฟรมเรต) ก็อ่อน หากเป็น 30fps ควรจะเห็นความกระท่อนกระแท่นเป็นหน่วย 33ms แต่ input→hit อยู่ที่ 0.220 อย่างเรียบสะอาด นี่ไม่ใช่การปัดเข้าขอบเฟรม แต่กลิ่นของ ตำแหน่งคงที่ภายในคลิป

เบาะแสชี้ขาดอยู่ที่อื่น เวลาของ anim_notify อยู่ที่ +0.220 จากฐาน anim_start เอกสารบอกว่า HitWindow ควรอยู่ที่ 0.150 หลังคลิปเริ่ม แต่ในคลิปจริงถูกตรึงอยู่ที่จุด 0.220 นั่นคือ คลิปเองถูกสร้างต่างจากเอกสาร หรือตำแหน่ง notify ถูกย้ายจาก 0.150 ไป 0.220 สาเหตุไม่ใช่เครือข่ายและไม่ใช่เฟรมเรต แต่เป็น ข้อ 3 ข้อมูลโมชัน/notify AI ใส่ตัวเลือกที่เป็นคำตอบไว้ในสี่ข้อ แต่จัดอันดับกลับหัวกลับหาง

พรอมต์ขอใหม่

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

ตัดเครือข่าย·เฟรมเรตออก (เหตุผล: input=anim_start เวลาตรงกัน จึงไม่มีดีเลย์อินพุต→โมชัน / input→hit อยู่ที่ 0.220 คงที่ไม่มี noise จากเฟรม) ข้อเท็จจริงที่เหลือ: anim_notify อยู่ที่ anim_start +0.220 เอกสารคือ +0.150 ใช้แค่ข้อเท็จจริงนี้บีบสาเหตุ และบอกว่าจะร้องขออะไรกับโปรแกรมเมอร์·อนิเมเตอร์ ใน หน่วยการกระทำ // หัวใจคือ "ในหน่วยการกระทำ" — ให้จบที่ว่าจะร้องขอใครให้ทำอะไร ไม่ใช่การคาดเดา

ผลลัพธ์ดิบของ Claude (ครั้งที่ 2)

จากเหตุผลที่ให้มา สาเหตุถูกบีบลงเหลือ การที่ notify HitWindow ของคลิป animation cast_thunder ถูกวางไว้ที่ 0.220s ไม่ใช่ 0.150s เหลือสองแขนง

• (ก) notify อยู่ที่ 0.150 ถูกต้อง แต่ทั้งคลิปช้าลง — หากความเร็วเล่น (play rate) ต่ำกว่าในเอกสาร หรือความยาวคลิปยืดขึ้น จุด 0.150 จะถูกยืดออกเป็น 0.220 ในเวลาจริง
• (ข) ตำแหน่ง notify เองถูกย้ายไป 0.220 — ความยาวคลิปเท่าเดิม แต่ marker ถูกย้ายเท่านั้น

การตรวจที่แยกสองแขนงนี้: 1. ขอจากอนิเมเตอร์: ขอหมายเลขเฟรมของ notify HitWindow ของ cast_thunder และจำนวนเฟรมรวมของคลิป พร้อมประวัติการเปลี่ยนแปลงเทียบกับค่าตอนเขียนเอกสาร หาก marker ถูกย้ายก็เป็น (ข) 2. ขอจากโปรแกรมเมอร์: ตรวจว่า montage play rate ของ skill_thunder เป็น 1.0 หรือไม่ และสแตตความเร็วโจมตีของตัวละครถูกคูณเข้ากับคลิปนี้หรือไม่ หาก play rate เป็น 0.68 (=0.150/0.220) ก็เป็น (ก) 3. วัดช่วง anim_start→anim_notify อีกครั้งที่ความเร็วโจมตีของตัวละครค่าอื่น หากช่วงเปลี่ยนตามความเร็วโจมตีก็เป็น (ก) หากไม่เปลี่ยนก็เป็น (ข)

มาตรการที่แนะนำ: หากยืนยันเป็น (ข) ให้ย้าย notify กลับไปที่ 0.150 หรืออัปเดตเอกสารเป็น 0.220 (เลือกฝั่งที่ตั้งใจไว้) หากยืนยันเป็น (ก) ให้ตรวจ logic การใช้ play rate

เอาต์พุตครั้งนี้น่ารับมาใช้ ไม่ได้ฟันธงการคาดเดา แต่แยกออกเป็นสองแขนง (ก)/(ข) และเขียน วิธีแยกแต่ละแขนงด้วยข้อมูล กับ จะร้องขอใครให้ทำอะไร ไว้ในหน่วยการกระทำ โดยเฉพาะการตรวจข้อ 3 (เปลี่ยนความเร็วโจมตีแล้ววัดใหม่) คือจุดแยกชี้ขาดที่คนมักพลาด หากนำรายงานนี้ไปเข้าประชุมตรง ๆ การประชุมก็จะไม่ใช่เวทีถกว่า "สาเหตุคืออะไร" แต่กลายเป็นเวที "ยืนยัน (ก) หรือ (ข) ภายใน 30 นาทีแล้วเลือกมาตรการ"

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

4.4.6 ผูกสองแกนเป็นรอบเดียว — ลูปการตรวจสอบ

หากการจำลอง (4.4.2\~4.4.3) กับการวิเคราะห์การจับภาพ (4.4.4\~4.4.5) แยกกันรัน ก็ได้ค่าเพียงครึ่งเดียว เมื่อผูกรวมเป็นหนึ่ง ลูปต่อไปนี้ก็ถูกสร้างขึ้น

flowchart TD
    A["เขียนเอกสาร
(นักออกแบบ, แบบฟอร์ม 4.2·4.3)"] --> B["การจำลอง
simulate_dps · แจกแจงคอมโบ
(อัตโนมัติ, 1 วินาที)"]
    B -->|"DPS·คอมโบผิดปกติ"| A
    B -->|"เอกสารผ่าน"| C["บิลด์
(โปรแกรมเมอร์·อาร์ทิสต์, หลายวัน)"]
    C --> D["รวบรวม log telemetry
(input·hit·anim_notify)"]
    D --> E["เทียบเอกสาร vs ค่าวัดอัตโนมัติ
(ตรวจความต่างแบบ 150ms vs 220ms)"]
    E -->|"รายการเกินค่าเกณฑ์"| F["รายงานประมาณสาเหตุโดย AI
(กางตัวเลือก → คนบีบให้แคบ)"]
    F --> G["นักออกแบบตรวจ → ตัดสินมาตรการ
(อัปเดตเอกสาร vs แก้บิลด์)"]
    G --> A
    E -->|"ตรงกันทุกรายการ"| H["ไปยังสกิลถัดไป"]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class B,E code;
    class F ai;
    class A,G human;
    class D data;
    class H pass;

เนื่องจากการจำลองให้คำตอบ ก่อน บิลด์ เอกสารที่เข้าสู่บิลด์จึงเป็นเอกสารที่ถูกกรองมาแล้วหนึ่งครั้ง ด้วยเหตุนี้ ปัญหาที่ค้นพบหลังบิลด์จึงถูกบีบลักษณะให้แคบลงจาก "เอกสารผิด" เหลือ "เอกสารกับการ implement ไม่ตรงกัน" +70ms ของ 4.4.5 ก็คือกรณีหลังนั้นพอดี — เอกสาร 150 สมเหตุสมผล เพียงแต่การ implement ออกมาเป็น 220 ไม่ตรงกันเท่านั้น การแยกแยะนี้ขจัดการโต้เถียงเรื่องผู้รับผิดชอบในการประชุม

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

4.4.7 สิ่งที่เห็นจากการให้บริการ 6 เดือน

นี่คือการวัด 6 เดือนของทีม TF การต่อสู้ใน MMORPG เกมหนึ่งที่ผมเคยให้บริการ (โปรเจกต์ A ที่ตั้งเป้าฟีลการบังคับแบบเกมตระกูล refgame) ตัวเลขด้านล่างคือ ค่าวัดจริง ที่คัดจากบันทึกภายในของทีม TF และขอแจ้งว่าจำนวนบิลด์·เวลาเป็นค่าที่ปัดเป็นหน่วยรอบ (เป็นการวัดเป็นหน่วยรอบ·ครึ่งวัน ไม่ใช่หน่วยนาทีที่แม่นยำ)

การเปลี่ยนแปลงที่สำคัญกว่าตัวเลขคือ ลักษณะ ของการประชุม ครึ่งหนึ่งของการประชุมก่อนนำมาใช้คือ "สกิลนี้แรงเกินไป" กับ "ไม่หรอก พอดีแล้ว" ศึกปลายนิ้วกับปลายนิ้ว หลังนำมาใช้ ที่นั่งตรงนั้นเปลี่ยนไปเป็น "DPS ที่วัดได้คือเป้าหมาย +12% และ hit timing ที่วัดได้คือเอกสาร +70ms จะย่นโมชันดี หรือจะลดดาเมจ 10% ดี" เวลาที่เคยถกเถียง ว่าอะไรคือปัญหา เปลี่ยนไปเป็นเวลากำหนด ว่าจะแก้อย่างไร

ขอเขียนต้นทุนของการเปลี่ยนผ่านนี้ไว้อย่างตรงไปตรงมาด้วย งานช่วงต้นในการฝัง logger telemetry ไว้ทั่วโค้ดการต่อสู้ใช้เวลาราว 1\~2 สัปดาห์ และการทำให้ schema ของเอกสารเป็นมาตรฐานเดียวกันในทุกตัวละคร·ทุกสกิลใช้เวลาเพิ่มอีกหนึ่งไตรมาส ในไตรมาสแรกผมมองว่ามีการจำลองกับ telemetry รันแค่อย่างใดอย่างหนึ่งก็เพียงพอแล้ว ทั้งสองมาประสานเป็นลูปเดียวกันก็ตั้งแต่ไตรมาสที่สองเป็นต้นมา

4.4.8 ความผิดพลาดที่พบบ่อยและการหลีกเลี่ยง

มีห้าอย่างที่เกิดซ้ำ ๆ

หนึ่ง เชื่อค่าจำลองอย่างเด็ดขาด 261 ของ simulate_dps คือ ขีดสูงสุด ไม่ใช่ค่าวัดจริง หากไม่เทียบกับ telemetry ก็จะประเมินสูงเกินไปเสมอ

สอง ไม่วัด หากจำลองเฉพาะเอกสารแล้วไม่ดูบิลด์ด้วย telemetry +70ms แบบใน 4.4.5 ก็จะสะสมเงียบ ๆ การ logging telemetry ไม่ใช่ตัวเลือกเสริม แต่เป็นโครงสร้างพื้นฐานของโค้ดการต่อสู้

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

สี่ รับการประมาณของ AI มาใช้โดยไม่ตรวจสอบ ดังที่เห็นใน 4.4.5 การประมาณครั้งที่ 1 ของ AI เป็นการเดาผิดทาง AI เป็นเครื่องมือกางตัวเลือกให้กว้าง ไม่ใช่เครื่องมือสรุปข้อสรุป อย่าข้ามขั้นตอนของคนที่ตัดตัวเลือกออกด้วย log โดยเด็ดขาด

ห้า โครงสร้างเอกสารต่างกันในแต่ละสกิล หากบางสกิลเขียน cast_sec เป็น cast_time บางสกิลเขียนเป็น castMs ทั้งตัวจำลองและสคริปต์เทียบก็จะพังทุกครั้ง ให้บังคับใช้ schema เอกสารร่วมหนึ่งเดียวกับทุกสกิล — นี่คือเงื่อนไขที่ทำให้เครื่องมือทั้งหมดของ 4.4 รันได้

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

4.4.9 ปิดท้าย Part 4

ใน 4.1\~4.4 เราได้พูดถึงพิกัด·Look & Feel·คอมโบ·การจำลองของการออกแบบการต่อสู้ตามลำดับ 4.1 พูดถึงว่านักออกแบบการต่อสู้มองอะไรเป็นเป้าหมายที่วัดได้ 4.2 พูดถึงว่าจะวัดและปรับ hit timing·hitstop·การ sync เอฟเฟกต์อย่างไร 4.3 พูดถึงว่าจะเขียนคอมโบ·cancel·input queue เป็น state machine อย่างไร และ 4.4 พูดถึงว่าจะตรวจสอบทั้งหมดนั้นว่าทำงานตามที่ตั้งใจไว้หรือไม่ ทั้งแบบไม่มีบิลด์/แบบในบิลด์อย่างไร

หนึ่งสัปดาห์ของนักออกแบบการต่อสู้ที่จบ Part 4 จะเปลี่ยนไปเช่นนี้ วันจันทร์ การตรวจสอบอัตโนมัติด้วย simulate_dps ถูกแนบไปกับเอกสารสกิลใหม่ วันอังคาร ตรวจอัตลักษณ์ของคอมโบหลักด้วยการแจกแจงเส้นทางคอมโบอัตโนมัติ วันพุธ พอบิลด์ขึ้น ตารางเทียบ telemetry ก็ขึ้นมาอัตโนมัติ วันพฤหัส ถกเถียงอิงข้อมูล 30 นาที วันศุกร์ แก้เอกสารสำหรับรอบถัดไป รอบบิลด์ลดจาก 3\~4 ครั้งเหลือ 1\~2 ครั้ง และการประชุมสั้นลงเหลือไม่ถึงครึ่ง ความเป็นนามธรรมที่เรียกว่าฟีลการกระแทกเปลี่ยนไปเป็น 220ms ที่วัดได้

และฉากนั้นในบิลด์ #234 — กับคำถาม "อันนี้มันดูลอย ๆ หน่อยไหม" ตอนนี้ log telemetry ตอบแทนแล้วว่า 220ms ศึกระหว่างปลายนิ้วกับกระดาษจบลงแล้ว

Part 5 ถัดไปคือการออกแบบเนื้อเรื่อง เราจะข้ามไปยังกรณีการประยุกต์ใช้จริงของโครงสร้าง NarrativeDocs Layer 0\~4 ที่แนะนำไว้ใน 2.3

ลองทำดู

setup 1. สร้าง simulate_dps.py ทั้งหมดด้านล่างตามนี้ตรง ๆ ไม่มี dependency รันได้ทันทีด้วย python simulate_dps.py และ "평균 DPS: 261.0" ของ 4.4.2 จะถูกสร้างซ้ำได้

# simulate_dps.py — คำนวณ DPS จากเอกสารเพียงอย่างเดียวโดยไม่ต้องมีบิลด์
from dataclasses import dataclass

@dataclass
class Skill:
    name: str
    damage: float          # ดาเมจต่อการตีหนึ่งครั้ง
    cast_sec: float        # เวลาร่าย (ครองโมชัน) (วินาที)
    cooldown_sec: float    # เวลารอใช้ซ้ำ (วินาที)
    resource_cost: float   # ทรัพยากรที่ใช้ (MP/พลัง)

@dataclass
class Character:
    name: str
    max_resource: float
    resource_regen: float  # ฟื้นฟูทรัพยากรต่อวินาที
    skills: list           # list[Skill]
    rotation: list         # ลำดับตามความสำคัญ (ชื่อสกิล)

def simulate_dps(char: Character, duration_sec: float, tick=0.05):
    cooldowns = {s.name: 0.0 for s in char.skills}   # คูลดาวน์ที่เหลือ
    skill_by_name = {s.name: s for s in char.skills}
    resource = char.max_resource
    total_damage = 0.0
    busy_until = 0.0          # เวลาที่โมชันร่ายจบ
    log = []
    t = 0.0
    while t < duration_sec:
        resource = min(char.max_resource, resource + char.resource_regen * tick)
        for name in cooldowns:
            cooldowns[name] = max(0.0, cooldowns[name] - tick)
        if t >= busy_until:   # ถ้าไม่ได้อยู่ระหว่างร่าย ให้เลือกสกิลถัดไป
            for name in char.rotation:          # ตามลำดับความสำคัญ
                s = skill_by_name[name]
                if cooldowns[name] <= 0 and resource >= s.resource_cost:
                    total_damage += s.damage
                    resource -= s.resource_cost
                    cooldowns[name] = s.cooldown_sec
                    busy_until = t + s.cast_sec
                    log.append((round(t, 2), name, resource))
                    break
        t += tick
    return total_damage / duration_sec, log

if __name__ == "__main__":
    warrior = Character(
        name="warrior", max_resource=100, resource_regen=8,
        skills=[
            Skill("skill_thunder", damage=420, cast_sec=0.9, cooldown_sec=6, resource_cost=40),
            Skill("skill_dash",    damage=180, cast_sec=0.4, cooldown_sec=3, resource_cost=20),
            Skill("basic_1",       damage=60,  cast_sec=0.3, cooldown_sec=0, resource_cost=0),
        ],
        rotation=["skill_thunder", "skill_dash", "basic_1"],
    )
    dps, log = simulate_dps(warrior, duration_sec=20)
    print(f"평균 DPS: {dps:.1f}")
    for t, name, res in log[:8]:
        print(f"  t={t:>5}s  {name:<14} 자원={res:.0f}")

1. เพิ่ม log telemetry ทีละบรรทัด ณ จุดที่รับอินพุต·จุดที่ใช้ดาเมจในโค้ดเอนจินการต่อสู้ (4.4.4) หัวใจคือการจดเวลาของเอนจิน (GetTimeSeconds ฯลฯ) ลงไปตรง ๆ

prompt เลือกรายการหนึ่งที่ไม่ตรงกับเอกสารจาก telemetry ของบิลด์ แล้วถาม AI ด้วยแบบฟอร์มของ 4.4.5 — แนบ log ที่ตัดมา และต้องใส่ "อย่าฟันธงการคาดเดา ให้เขียนถึงวิธีตรวจสอบของแต่ละสาเหตุด้วย ถ้าไม่แน่ใจให้เขียนกำกับว่ายังไม่ยืนยัน" ไว้เสมอ

verify อย่ารับเอาต์พุตครั้งที่ 1 ของ AI มาใช้ตรง ๆ อ่าน log ด้วยตัวเองแล้วลบตัวเลือกที่ตัดออกได้ด้วยมือ (เหมือนการตัดเครือข่าย·เฟรมเรตใน 4.4.5) จากนั้นแนบเหตุผลแล้วขอใหม่ หากรายงานสุดท้ายจบที่หน่วยการกระทำ "ประมาณสาเหตุ + ร้องขอใครให้ทำอะไร" ก็นำเข้าประชุมได้

ฉบับย่อสำหรับคนเดียว หากการติดตั้ง logger telemetry ทั่วทั้งระบบเป็นภาระ ให้จด input·hit สองบรรทัดเฉพาะ สกิลหนึ่งตัว ที่ต้องการตรวจสอบ และให้ simulate_dps ดูเฉพาะ DPS ของสกิลตัวนั้นตัวเดียว อย่าติดตั้งเครื่องมือทั้งหมด แต่หมุนลูปหนึ่งรอบด้วยสกิลที่น่าสงสัยที่สุดตัวเดียวก่อนแล้วค่อยขยาย

สรุปประเด็นสำคัญของบท

• การจำลองคำนวณขีดสูงสุดในอุดมคติของเอกสารก่อนบิลด์ ลดการตรวจสอบจากหน่วยวันลงเหลือหน่วยชั่วโมง
• การวัดในบิลด์ที่สมจริงคือ log telemetry ไม่ใช่วิดีโอ และจดเวลาของเอนจินมาตรง ๆ
• AI เป็นเครื่องมือกางตัวเลือกสาเหตุให้กว้าง ส่วนการตรวจสอบที่บีบตัวเลือกให้แคบด้วย log เป็นหน้าที่ของคน

ส่วนที่ 5 · Narrative Design

5.1 โครงสร้าง NarrativeDocs Layer 0\~4

เมื่อเดินเข้าห้องประชุม บนไวต์บอร์ดมีชื่อตัวละครหนึ่งถูกวงด้วยปากกาแดง เป็น NPC ที่ชื่อว่าคิม ในเควสต์เสริมของนักออกแบบเกมคนหนึ่ง เขาคือ "พ่อบุญธรรมที่เก็บตัวเอกมาเลี้ยงดูตั้งแต่เด็ก" แต่ในเควสต์หลักบทที่ 3 ของนักออกแบบเกมอีกคน เขากลับเป็น "อดีตสหายที่ทรยศตัวเอกแล้วจากไป" เอกสารทั้งสองได้รับการอนุมัติเมื่อหนึ่งเดือนก่อน และทั้งคู่ก็เข้าไปอยู่ในบิลด์แล้ว แม้แต่ใบเสนอราคาสำหรับการอัดเสียงพากย์ก็ได้รับมาแล้วด้วยซ้ำ

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

เมื่อการประชุมวันนั้นจบลง สิ่งที่เราตัดสินใจกันก็คือการแบ่ง NarrativeDocs ออกเป็นห้าชั้น บทนี้คือเรื่องราวของห้าชั้นนั้น

5.1.1 เหตุผลที่เริ่มจากสาขาที่เป็นนามธรรมที่สุด

การเปิดเรื่องการแยก Layer ตามสาขาด้วยเนื้อเรื่อง (narrative) ก่อนนั้นมีเหตุผล

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

อีกประการ เนื้อเรื่องมีอินเทอร์เฟซมากที่สุด ตัวละครเชื่อมกับงานอาร์ต เควสต์เชื่อมกับเนื้อหาและเลเวล บทพูดเชื่อมกับ UX และการแปลภาษา (localization) ส่วนรางวัลเชื่อมกับระบบ เพราะเป็นตำแหน่งที่ตัดข้ามระหว่างสาขามากที่สุด คุณค่าของการรวม Layer จึงปรากฏชัดในทันที

สุดท้าย ผลงานที่เป็นภาษาธรรมชาติมีสัดส่วนสูงที่สุด จึงเป็นสาขาที่ AI ช่วยได้มากที่สุดด้วยเช่นกัน อย่างไรก็ตาม ไม่ใช่ทุกเกมที่ยึดเนื้อเรื่องเป็นศูนย์กลาง หากเป็นแนวแคชวลหรืออาร์เคด ความลึกของบทนี้อาจมากเกินไป แต่ถึงอย่างนั้น โครงหลักที่ว่า "แยกเอกสารก้อนเดียวออกเป็น Layer และทำให้อินเทอร์เฟซแคบลง" ก็ย้ายไปใช้กับสาขาใดก็ได้ตามเดิม

5.1.2 ลิ้นชักห้าช่อง

รูปร่างของ NarrativeDocs ที่ถูกแยกออกเป็นห้าชั้นมีดังนี้ วิสัยทัศน์ (L0) อยู่ด้านบน บิลด์และ QA (L4) อยู่ด้านล่าง และทางเชื่อมระหว่างชั้นถูกออกแบบให้แคบโดยตั้งใจ

เมื่อย้ายไปเป็นโฟลเดอร์ จะได้รูปร่างดังต่อไปนี้ ชื่อไฟล์แต่ละชื่อไม่ใช่ชื่อที่ทำให้เป็นนามธรรมในหนังสือ แต่เป็นชื่อไฟล์ที่มีอยู่จริงในโฟลเดอร์นั้น

NarrativeDocs/
├── Layer0_Vision/
│   ├── world_premise.md          (สมมติฐานโลกของเกม — ไม่เปลี่ยนแปลง)
│   ├── narrative_pillar.md       (เสาอารมณ์ 3 ต้น)
│   └── tone_manifesto.md         (รายการโทน·คำต้องห้าม)
├── Layer1_System/
│   ├── faction_system.md
│   ├── reputation_model.md
│   ├── dialogue_branching_rule.md
│   └── lore_consistency_rule.md
├── Layer2_Content/
│   ├── main_quest/               (ระดับบท)
│   ├── side_quest/
│   ├── character_bible/
│   └── lore_codex/
├── Layer3_Data/
│   ├── quest_table.xlsx
│   ├── npc_table.xlsx
│   ├── dialogue_id_table.xlsx
│   └── reward_table.xlsx
└── Layer4_Build_QA/
    ├── narrative_qa_checklist.md
    ├── voice_review_log.md
    └── localization_status.md

จุดสำคัญคือ ห้าชั้นนี้ไม่ได้ให้คนคนเดียวรับผิดชอบทั้งหมด แต่ละชั้นมีผู้ดูแลหลักต่างกัน และมาตรฐานเฉพาะทางเชื่อมระหว่างชั้นที่อยู่ติดกันเท่านั้น ลูกศรสีแดงในภาพข้างต้นคือทางเชื่อมเหล่านั้น โดยเฉพาะทางเชื่อมระหว่าง L2 กับ L3 ถูกวาดให้แคบที่สุดโดยตั้งใจ (ลูกศรสีแดงหนา) ส่วนเหตุผลนั้นจะได้เห็นในตอนหลัง

ถ้ามองด้วยอุปมาลิ้นชัก ก็คือลิ้นชักห้าช่อง ช่องแรกมีโลกของเกมหนึ่งบรรทัดที่ห้ามย้ายเด็ดขาด ช่องที่สองมี rulebook ช่องที่สามมีเนื้อหาหลัก ช่องที่สี่มีชีต ช่องที่ห้ามีบันทึกการตรวจสอบ ทางเชื่อมระหว่างช่องนั้นแคบ และเหนือทางเชื่อมมีกระดิ่งแจ้งเตือนการเปลี่ยนแปลงติดอยู่

5.1.3 L0 — เขียนให้สั้นเพื่อให้ไม่เปลี่ยนแปลง

L0 ไม่เปลี่ยนแปลง หากเปลี่ยนก็เท่ากับอัตลักษณ์ของเกมเปลี่ยน ดังนั้นปริมาณจึงต้องน้อย น้อยจึงจะไม่เปลี่ยน

รวมกันราว 4.5 หน้า นี่คือน้ำหนักของ L0 ถ้าหนักขึ้น การเปลี่ยนแปลงก็จะกลายเป็นเรื่องน่ากลัว และเมื่อกลัว ชั้นอื่นก็จะเริ่มเลี่ยง L0 เมื่อการเลี่ยงเริ่มขึ้น L0 ก็กลายเป็นเอกสารที่ตายแล้ว

โครงสร้างจริงของ narrative_pillar.md มีรูปร่างดังนี้ (เนื้อหาทำให้เป็นนามธรรม)

---
title: เสาอารมณ์ของเนื้อเรื่อง
layer: L0
status: locked
last_updated: 2026-05-18
---

## 1. ความโหยหาสิ่งที่สูญเสียไป
- ผู้เล่นสูญเสียสิ่งหนึ่งในตอนจบของทุกบท
- สิ่งที่สูญเสียไปจะไม่หวนกลับมาอีก (มีเพียงในความทรงจำ)

## 2. ความขัดแย้งระหว่างหน้าที่กับอิสรภาพ
- NPC หลักทุกตัวแบกหน้าที่สองอย่าง
- ทางเลือกของผู้เล่นรักษาหน้าที่ได้เพียงด้านเดียว

## 3. น้ำหนักของการสัมผัสเล็ก ๆ
- ความเมตตาเล็กน้อยให้ผลลัพธ์ที่ใหญ่กว่าวีรกรรมอันยิ่งใหญ่

เสาสามบรรทัดนี้กำหนดทิศทางของอีกหลายร้อยหน้าที่อยู่ใต้มัน status: locked ไม่ใช่เพียงป้ายธรรมดา หนึ่งในการตรวจสอบอัตโนมัติของ L4 จะอ่านป้ายนี้ และตั้งไว้ว่าเมื่อเอกสารที่เป็น locked ถูกแก้ไขใน PR การ merge จะถูกระงับไว้จนกว่าจะได้รับการอนุมัติจากลีดเนื้อเรื่อง

5.1.4 L1 — เนื้อเรื่องที่ใกล้โค้ดที่สุด

L1 เปลี่ยนได้ แต่ต้นทุนสูง เพราะมันคือ rulebook เมื่อ rulebook เปลี่ยนไปหนึ่งบรรทัด เนื้อหาทั้งหมดที่ทำตามกฎนั้นก็ได้รับผลกระทบ

โครงสร้างของ faction_system.md มีดังนี้

---
title: ระบบฝ่าย
layer: L1
atoms:
  - faction_relation_matrix
  - faction_membership_rule
  - faction_quest_eligibility
---

## 1. แนวคิดฝ่าย
N ฝ่าย แต่ละฝ่ายนิยามด้วย (อุดมการณ์, ทรัพยากร, ดินแดน)

## 2. ความสัมพันธ์ระหว่างฝ่าย
- relation_matrix.json (-3 เป็นศัตรู ~ +3 เป็นพันธมิตร)
- ทริกเกอร์การเปลี่ยนความสัมพันธ์: การตัดสินใจในเควสต์หลัก, เกณฑ์ค่าชื่อเสียง

## 3. กฎการสังกัดของผู้เล่น
- สังกัดพร้อมกันได้สูงสุด 2 ฝ่าย (สังกัดฝ่ายที่เป็นศัตรูกันพร้อมกันไม่ได้)
- บทลงโทษการถอนตัว: ค่าชื่อเสียง -2, ฝ่ายพันธมิตร -1

ลองสังเกตรายการ atoms: ใน frontmatter ให้ดี ชื่อ atom ทั้งสามนี้ไม่ใช่เพียงบันทึกย่อ แต่เป็นตัวระบุ (identifier) ที่ออนโทโลยีในส่วนที่ 7 และแผนผังความสัมพันธ์ในส่วนที่ 11 ติดตามอยู่ เมื่อเควสต์ใดอ้างอิง faction_quest_eligibility ไว้ เควสต์นั้นจะถูกยกขึ้นมาในรายการที่ได้รับผลกระทบโดยอัตโนมัติเมื่อกฎนี้เปลี่ยน L1 เป็นผลงานเนื้อเรื่องที่ใกล้กับโค้ดของเกมที่สุด จึงทำงานจับคู่กับ System Designer (ออกแบบระบบ)

5.1.5 L2 — ชั้นที่หนาที่สุด ที่ซึ่งเนื้อหาหลักอาศัยอยู่

L2 หนาที่สุด เควสต์หลัก เควสต์เสริม character bible และพจนานุกรม lore อาศัยอยู่ที่นี่ทั้งหมด แม้แต่การตั้งค่าจริงของคิม "พ่อบุญธรรม vs สหายผู้ทรยศ" ที่ปะทะกันในห้องประชุมก่อนหน้านี้ ตอนนี้ก็ดำรงอยู่ในรูปไฟล์เดียวภายใน character_bible/ เท่านั้น ไฟล์นั้นคือแหล่งความจริงเดียว (single source of truth) ส่วนเควสต์เป็นเพียงผู้อ้างอิงไปยังที่นั่น

โฟลเดอร์เควสต์หลักมีรูปร่างดังนี้

main_quest/
├── chapter_01_awakening/
│   ├── 00_chapter_overview.md
│   ├── 01_quest_a_call_to_arms.md
│   ├── 02_quest_b_first_choice.md
│   └── ...
├── chapter_02_road/
│   └── ...
└── _TEMPLATES/
    └── quest_template.md

ไฟล์เควสต์แต่ละไฟล์ทำตามรูปแบบมาตรฐานของ atom

---
title: เมื่อต้องจับอาวุธ
layer: L2
type: main_quest
atoms:
  - quest_chapter_01_awakening_a
related:
  affects: [reputation_model, faction_relation_matrix]
  derives_from: [narrative_pillar, world_premise]
  requires: [character_kim, faction_alpha]
  part_of: chapter_01_awakening
---

## ขั้นตอนดำเนินการ
1. ...

## การแตกแขนง
- เมื่อเลือกตัวเลือก A: ...
- เมื่อเลือกตัวเลือก B: ...

## รางวัล (อ้างอิง L3)
- reward_table.xlsx → แถว quest_001

หัวใจอยู่ที่บล็อก related: ทันทีที่เขียนว่า requires: [character_kim] ก็เท่ากับเควสต์นี้ประกาศว่าจะดึงการตั้งค่าของคิมมาจาก character_bible และจะไม่นิยามคิมขึ้นใหม่ในไฟล์ของตัวเองอีกต่อไป เนื้อหาหลักของเนื้อเรื่องวางไว้ที่ L2 ส่วนรางวัลที่เป็นตัวเลขวางไว้ในชีต L3 ถ้าทั้งสองอยู่ในไฟล์เดียวกัน ทุกครั้งที่แก้ชีตหนึ่งบรรทัดก็ต้องไปแตะเนื้อหาหลัก และเมื่อนั้น คีย์การแปลก็จะคลาดเคลื่อน

5.1.6 L3 — ชั้นที่ไม่มีภาษาธรรมชาติแม้แต่บรรทัดเดียว

L3 คือชีตและ ID ประโยคภาษาธรรมชาติเข้าไปแม้แต่บรรทัดเดียวก็ไม่ได้

quest_table.xlsx
| quest_id | chapter | type | unlock_level | reward_xp | reward_gold | dialogue_set_id |
|----------|---------|------|--------------|-----------|-------------|-----------------|
| q_001    | ch01    | main | 1            | 500       | 100         | ds_001          |
| q_002    | ch01    | main | 2            | 800       | 150         | ds_002          |

แม้แต่บทพูดก็อ้างอิงด้วย ID เท่านั้น ตัวเนื้อหาหลักอยู่แยกต่างหากใน dialogue_id_table.xlsx และจับคู่กับคีย์การแปลแบบ 1:1 ทางเชื่อมระหว่าง L2 กับ L3 เพียงแค่คอลัมน์ quest_id คอลัมน์เดียวก็เพียงพอ นี่คือเหตุผลที่ในภาพก่อนหน้า ทางเชื่อมนี้เป็นเพียงทางเดียวที่เป็นลูกศรสีแดงหนา การทำให้อินเทอร์เฟซแคบลงเหลือคอลัมน์เดียวคือหัวใจของการแยก Layer หากทางเชื่อมกว้าง ทั้งสองด้านก็จะรู้จักกันมากเกินไป และเมื่อแก้ด้านหนึ่ง อีกด้านก็จะพังตามไปด้วย

5.1.7 L4 — เกตวางจำหน่าย

L4 คือการตรวจสอบและการวางจำหน่าย ทุกครั้งที่เนื้อหาใหม่เข้ามา การตรวจสอบทั้งอัตโนมัติและด้วยมือจะทำงาน การตรวจสอบอัตโนมัตินั้นรันด้วยสคริปต์ สี่รายการด้านล่างคือ lint ที่ตั้งอยู่ใน CI จริง

ลองสังเกตว่า tone_lint.py อ่าน tone_manifesto.md ของ L0 โดยตรง ชั้นบนสุด (วิสัยทัศน์ที่ไม่เปลี่ยนแปลง) กับชั้นล่างสุด (เกตวางจำหน่าย) เชื่อมต่อกันโดยตรงด้วยระบบอัตโนมัติ หากคำต้องห้ามที่เขียนไว้ในวิสัยทัศน์ถูกตรวจพบในเนื้อหาหลักก่อนวางจำหน่าย บิลด์ก็จะถูกระงับ

สิ่งที่ตรวจจับอัตโนมัติไม่ได้ ให้คนเป็นผู้ดู

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

5.1.8 ลองให้ AI ทำ Layer ดู — บันทึกเซสชันจริง (worked transcript)

ที่ผ่านมาคือโครงสร้าง แต่ที่ซึ่งโครงสร้างนี้ทำงานจริง คือตอนสร้างเนื้อหาใหม่ ผู้เขียนจะถอดเซสชันจริงที่สั่งให้ Claude รับไอเดียเควสต์เสริมหนึ่งบรรทัดแล้วโปรยกระจายลงใน Layer บนโปรเจกต์ที่วางห้าชั้นไว้แล้วมาให้ตามนั้น โดยไม่สรุปย่อ และรวมส่วนที่เบี่ยงเบนกับส่วนที่ถูกปฏิเสธไว้ด้วย

พรอมต์ที่ส่งไป (ฉบับเต็ม):

อย่าฝ่าฝืนบริบท L0/L1 ที่แนบมาเด็ดขาด แล้วแยกย่อยตามโครงสร้าง Layer ของเรา

[narrative_pillar.md ฉบับเต็ม — เสาอารมณ์ 3 ต้น]
[tone_manifesto.md บางส่วน — คำต้องห้าม: "โชคชะตา", "คำพยากรณ์", "ผู้ถูกเลือก"]
[character_bible/character_kim.md บางส่วน — คิม: พ่อบุญธรรมที่เก็บตัวเอกมาเลี้ยง,
 พูดน้อย, พูดทิ้งท้ายไม่จบ, ไม่พูดความรู้สึกออกมาตรง ๆ]

ไอเดีย: "เควสต์เสริมสั้น ๆ ที่คิมส่งของที่ระลึกของภรรยาผู้ล่วงลับให้ผู้เล่น"

เขียนไฟล์เควสต์ L2 (รวมบล็อก related, เนื้อหาหลักราว 200 ตัวอักษร), แถว
quest_table ของ L3 กับ dialogue_id, และการตรวจสอบตนเองเรื่องการละเมิด tone ด้วย
เอาแค่ L2 ก่อนแล้วหยุดไว้

ผลลัพธ์ดิบของ Claude (L2):

---
title: ผ้าเช็ดหน้าซีดจาง
layer: L2
type: side_quest
atoms:
  - quest_side_kim_keepsake
related:
  affects: [reputation_model]
  derives_from: [narrative_pillar]
  requires: [character_kim]
  part_of: chapter_02_road
---

## ขั้นตอนดำเนินการ
1. คิมเรียกผู้เล่นอย่างเงียบ ๆ ไม่ได้บอกธุระทันทีเหมือนเช่นเคย
2. ยื่นผ้าเช็ดหน้าเก่า ๆ ออกมา "อันนี้… ข้าว่าเจ้าเก็บไว้น่าจะดีกว่า"
3. หากผู้เล่นถามว่าคืออะไร คิมไม่ตอบ แต่มองออกไปนอกหน้าต่างแทน
4. (ตัวเลือก) รับไว้ / ปฏิเสธ

## การแตกแขนง
- รับไว้: ค่าชื่อเสียงของคิม +1 ปลดล็อกฉากความทรงจำเกี่ยวกับผ้าเช็ดหน้า 1 ครั้งในบทถัดไป
- ปฏิเสธ: คิมพยักหน้าแล้วเก็บผ้าเช็ดหน้ากลับเข้าไป ค่าชื่อเสียงไม่เปลี่ยนแปลง
  ผ้าเช็ดหน้าจะไม่ปรากฏขึ้นอีกตลอดกาล

## รางวัล (อ้างอิง L3)
- reward_table.xlsx → แถว quest_side_kim_keepsake

ตรงนี้ Claude หยุด และเติมมาหนึ่งบรรทัด

"ผมสะท้อนเสาที่ 1 ของ L0 (สิ่งที่สูญเสียไปจะไม่หวนกลับมา) ด้วยการทำให้ถ้าเลือก 'ปฏิเสธ' ผ้าเช็ดหน้าจะหายไปตลอดกาล แต่มีจุดหนึ่งที่ต้องยืนยัน การตั้งค่าเรื่องภรรยาผู้ล่วงลับไม่มีอยู่ในส่วนที่ตัดมาของ character_kim.md ผมใส่เข้าไปเองตามอำเภอใจ จึงอาจขัดแย้งกับ character bible ได้"

การตรวจสอบและการปฏิเสธของมนุษย์:

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

จึงปฏิเสธ แล้วส่งคำขอใหม่ไป

คำขอใหม่:

โทนดี แต่ "ภรรยาผู้ล่วงลับ" เป็นการตั้งค่าใหม่ที่ไม่มีใน bible ใช้ไม่ได้
อดีตของคิมยืนยันแค่ "ตอนจากบ้านเกิดมาได้ทิ้งบางอย่างไว้" เท่านั้น
อย่าระบุว่าของที่ระลึกคืออะไร เขียนใหม่ให้คลุมเครือแค่ระดับ "สิ่งที่ทิ้งไว้นานมาแล้ว"
ผ้าเช็ดหน้าก็ไม่มีใน bible ลดลงเป็นแค่ "เศษผ้า" ก็พอ

ผลลัพธ์หลังคำขอใหม่ (บางส่วน):

2. ยื่นเศษผ้าเก่า ๆ ออกมา "มีของอยู่ชิ้นหนึ่ง… ที่ข้าทิ้งไว้นานมาแล้ว
   ขอบอกแค่ว่านี่คือปลายของมันก็พอ"
3. หากผู้เล่นถามว่าคืออะไร คิมไม่ตอบ แต่มองออกไปนอกหน้าต่างแทน

คราวนี้รับไว้ มันแตะเสาอารมณ์ที่ 1 (การสูญเสีย) ได้โดยไม่ตอกตรึงอดีตของคิมขึ้นใหม่ ส่วนสิ่งที่สูญเสียไปคืออะไรนั้น ยังคงคลุมเครือไว้จนจบ

สิ่งที่เซสชันเดียวนี้แสดงให้เห็นมีสองอย่าง หนึ่ง เมื่อฉีดบริบท Layer (เสา L0 + โทน L1 + bible L2) เข้าไปอย่างแม่นยำ AI จับโทนได้ดีอย่างน่าทึ่ง สอง เมื่อ AI พบช่องว่าง มันจะเติมให้ดูสมเหตุสมผล และเมื่อสิ่งที่เติมนั้นเป็นข้อเท็จจริงใหม่ที่ไม่มีใน bible ผู้ที่จับมันได้ก็ยังคงเป็นมนุษย์ เพราะ requires: [character_kim] ของโครงสร้าง Layer บอกว่า "ต้องไปดูที่ไหน" ผู้ตรวจสอบจึงรู้ทันทีว่าต้องเทียบกับไฟล์ใด หากไม่มีโครงสร้าง คงต้องไปไล่รื้อทั้ง 70 หน้าอีกครั้ง

5.1.9 กระดิ่งแจ้งเตือนเหนือทางเชื่อมแคบ ๆ

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

ตัวอย่างเช่น หากยื่น PR ที่เปลี่ยน "สังกัดพร้อมกันได้สูงสุด 2 ฝ่าย" ใน faction_system.md ของ L1 เป็น "สูงสุด 1 ฝ่าย" แผนผังความสัมพันธ์จะกวาดเควสต์ L2 ที่อ้างอิง faction_quest_eligibility แล้วจัดทำรายการที่ได้รับผลกระทบ และรายการนั้นจะถูกแนบเข้ากับคอมเมนต์ของ PR โดยอัตโนมัติ คนที่เปลี่ยนกฎ แทนที่จะ "นัดประชุมสองสามครั้งเพื่อหาว่าใครได้รับผลกระทบบ้าง" ก็แค่ดูรายการที่แนบในคอมเมนต์ แล้วจบด้วยการประชุม 30 นาที

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

5.1.10 หกเดือนของการใช้งานจริง อะไรเปลี่ยนไปบ้าง

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

สิ่งที่ลดลงอย่างชัดเจนที่สุดคือการแปลภาษาตกหล่น เมื่อ dialogue_id ถูกผูกกับคีย์การแปลแบบ 1:1 ที่ L3 และ dialogue_lint.py ป้องกันการ mapping ตกหล่น อุบัติเหตุที่ว่า "บทพูดที่ยังไม่ได้แปลหลุดเข้าไปในบิลด์" ก็แทบหายไป การที่การออนบอร์ดสั้นลงก็เป็นเรื่องใหญ่ แทนที่จะบอกนักออกแบบเกมใหม่ว่า "อ่านไฟล์เวิร์ด 70 หน้าให้หมด" ก็พูดได้ว่า "จำ L0 แค่ 4.5 หน้า แล้วเควสต์ของคุณก็เติมเทมเพลต L2 เอา"

ขอเสริมอย่างตรงไปตรงมาว่า ผลนี้ไม่ได้ออกมาในครั้งเดียว ในไตรมาสแรกติดคอมเมนต์อัตโนมัติไว้เพียงอย่างเดียว ที่เหลือยังเป็นงานมือ ระบบอัตโนมัติของอินเทอร์เฟซเพิ่มทีละอย่างในแต่ละไตรมาส การติดตั้งระบบอัตโนมัติใช้เวลานานกว่าการแบ่ง Layer เสียอีก

5.1.11 เหตุผลที่ลึกกว่านั้น — เส้นทางสู่การสร้างแบบโพรซีเดอรัล

ที่ผ่านมาคือเหตุผลผิวเผิน "ทำให้ภาษาในการทำงานร่วมกันระหว่างสาขาเป็นหนึ่งเดียว" แต่มีเหตุผลที่เป็นแก่นแท้กว่านั้นอีกหนึ่งอย่าง การแยก Layer คือเงื่อนไขที่ทำให้การสร้างแบบโพรซีเดอรัล (procedural generation) เป็นไปได้ ห้าชั้นแต่ละชั้นล้วนสอดคล้องกับบทบาทหนึ่งของการสร้างแบบโพรซีเดอรัล (L0 แองเคอร์ → L1 rulebook → L2 เนื้อหาหลัก → L3 ตัวเลข → L4 เกต) และหากปนกันเป็นก้อนเดียว ตัวสร้างก็จะกำหนดไม่ได้ว่าจะอ่านจากที่ไหนและเขียนที่ไหน แล้วพังลง ประเด็นทั่วไปนี้ได้กล่าวถึงทั้งหมดแล้วใน §6.6 ตรงนี้จะดูเพียงว่าเงื่อนไขนั้นทำงานจริงอย่างไรบนห้าชั้นเนื้อเรื่อง

บนเอกสารก้อนเดียว 70 หน้า อัลกอริทึมการสร้างกำหนดไม่ได้ว่าจะอ่านจากที่ไหนและเขียนที่ไหน ห้าชั้นเนื้อเรื่องกลายเป็นห้าขั้นตอนของไปป์ไลน์การสร้างได้ทันที — L0 แองเคอร์, L1 กฎอินพุต, L2 ที่ที่เนื้อหาหลักสะสม, L3 อินพุตการจำลอง, L4 เกตตรวจสอบ

บันทึกเซสชันจริงก่อนหน้านี้ก็เป็นฉบับย่อของห้าขั้นตอนนี้อยู่แล้ว มันฉีดเสา L0 และโทน L1 เข้าเป็นบริบท (แองเคอร์) เนื้อหาหลักถูกสร้างที่ L2 แถว L3 ตามออกมา และการตรวจสอบตนเองเรื่องการละเมิด tone ก็เลียนแบบเกตตรวจสอบ สิ่งที่คนสั่งทำทีละเควสต์ หากย้ายให้ generator ผลิตเควสต์เสริมจำนวนมากบนโครงสร้างเดียวกัน ก็กลายเป็นการสร้างแบบโพรซีเดอรัล

ถ้าไปไกลกว่านั้น จะไหลแบบนี้ — การกระทำของผู้เล่นสะสม → การเปลี่ยนสถานะของโหนด BT ระดับโลก (Squad ระดับบน) → การเปลี่ยนค่าตัวเลขของ NPC (ค่าชื่อเสียง·ความสนใจ·ลำดับความสำคัญ) → แท็ก+ตัวเลขของ NPC คือเงื่อนไขการปรากฏ → เควสต์ที่จับคู่ได้ปรากฏจากกลุ่มก้อนเควสต์ (quest cloud) แทนที่จะเขียนเควสต์ไว้ล่วงหน้าทั้งหมด ก็ปล่อยให้มัน "ลอยอยู่ในอากาศเหมือนเมฆ" พร้อมแท็กติดอยู่ และเมื่อการกระทำของผู้เล่นเปลี่ยนค่าตัวเลขของ NPC เควสต์ที่ค่านั้นตรงกับเงื่อนไขการปรากฏก็จะร่วงลงมาปรากฏ โมเดลก้าวหน้านี้จะกล่าวถึงอย่างละเอียดอีกครั้งใน 5.3 (รวมแผนภาพการไหล) จุดที่ต้องเน้นตรงนี้คือ การไหลทั้งหมดนี้ทำงานได้บนการแยกห้าชั้นเท่านั้น

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

อย่างไรก็ตาม ไม่ได้หมายความว่าต้องมีลิ้นชักห้าช่องครบสมบูรณ์ตั้งแต่แรก ในไตรมาสแรก แยกแค่ L0 หนึ่งบรรทัดกับ rulebook L1 หนึ่งเล่มก็เพียงพอ แยกแบบค่อยเป็นค่อยไป อินเทอร์เฟซแคบเข้าไว้

สุดท้าย เรื่องของมุมมองทางเวลาสักหนึ่งข้อ ตัวการแยก Layer เองนั้นเป็นการแยกที่มีมาตั้งแต่ยุค PCG (Procedural Content Generation, การสร้างเนื้อหาแบบโพรซีเดอรัล) เชิงกำหนด สิ่งที่ใหม่คือ LLM (โมเดลภาษาขนาดใหญ่) สามารถจัดการเนื้อหาหลักที่เป็นภาษาธรรมชาติ เพอร์โซนา และการแตกแขนงของเรื่องเล่าบนการแยกนั้นได้แล้ว — การที่ AI เขียนบทพูดให้เข้ากับโทนของคิมในบันทึกข้างต้น เป็นสิ่งที่เมื่อ 5 ปีก่อนทำไม่ได้ด้วยตารางกฎ มุมมองทางเวลานี้จะกล่าวถึงเพิ่มเติมใน 5.3

ในบทถัดไป (5.2) จะได้เห็นว่าบนห้าชั้นนี้ lore_consistency_rule ตรวจสอบความสอดคล้องตั้งแต่โลกของเกม→ตัวละคร→เควสต์โดยอัตโนมัติอย่างไร นั่นคือตัวตรวจสอบ (checker) ที่ป้องกันอุบัติเหตุคิมในเชิงโครงสร้าง

ลองทำดู — การแยก Layer ครั้งแรก

สมมติว่าเริ่มจากสถานะที่มีเอกสารโลกของเกมก้อนเดียวอยู่แล้ว

setup. สร้างโฟลเดอร์เปล่าห้าโฟลเดอร์ใต้โฟลเดอร์ NarrativeDocs ตั้งแต่ Layer0_Vision ไปจนถึง Layer4_Build_QA คงเอกสารก้อนเดียวเดิมไว้ตามเดิม แล้วเลือกเฉพาะ "บรรทัดเดียวที่ห้ามเปลี่ยนเด็ดขาด" จากตรงนี้ ย้ายไปไว้ที่ Layer0_Vision/narrative_pillar.md ใส่ status: locked ใน frontmatter อย่าให้ไฟล์นี้เกิน 4.5 หน้า

prompt. เมื่อสร้างเนื้อหาใหม่ ให้บริบทแก่ AI ตามลำดับนี้

[narrative_pillar.md ฉบับเต็ม]
[คำต้องห้ามของ tone_manifesto.md]
[ส่วนที่ตัดมาจากไฟล์ character_bible ที่เกี่ยวข้อง]

ไอเดีย: "<ไอเดียหนึ่งบรรทัด>"

อย่าฝ่าฝืนบริบทนี้ แล้วเริ่มเขียนจากไฟล์เควสต์ L2 ก่อน เติมบล็อก related
(requires/derives_from/affects) ให้ครบ อย่าใส่การตั้งค่าใหม่ที่ไม่มีใน bible
ถ้าจำเป็นก็หยุดแล้วถามมา

verify. ดูสองอย่างจากผลลัพธ์ (1) เปิดไฟล์ที่ระบุใน requires: จริง ๆ แล้วเทียบว่า AI ไม่ได้สร้างข้อเท็จจริงที่ไม่มีอยู่ที่นั่นขึ้นใหม่ (2) ค้นหาคำต้องห้ามในเนื้อหาหลัก (ถ้ามี tone_lint.py ก็อัตโนมัติ ถ้าไม่มีก็ใช้สายตา) หากติดอย่างใดอย่างหนึ่ง ให้ปฏิเสธ แล้วระบุให้ชัดว่าอะไรผิดเพื่อขอใหม่ การปฏิเสธ "ภรรยาผู้ล่วงลับ" ในบันทึกข้างต้นก็คือข้อ (1) นี่เอง

5.1.12 ฉบับย่อสำหรับคนเดียว

หากคุณเป็นนักพัฒนาอินดี้ที่ทำคนเดียวโดยไม่มีทีม ห้าชั้นอาจดูมากเกินไป สองช่องก็พอ

วาง vision.md หนึ่งหน้า (รวม L0+L1), โฟลเดอร์ content/ หนึ่งโฟลเดอร์ (L2) และสเปรดชีตหนึ่งหน้า (L3) ส่วน QA แทนที่จะมีเป็นชั้นแยกต่างหาก ให้ใช้นิสัยเขียน requires: เพียงบรรทัดเดียวใน frontmatter ของไฟล์ content แทน ทุกครั้งที่เขียนเควสต์ใหม่ ก็เปิดเฉพาะไฟล์ที่ระบุใน requires ขึ้นมาเทียบใหม่ ก็จะป้องกันอุบัติเหตุคิมได้โดยไม่ต้องไล่รื้อทั้ง 70 หน้า หัวใจไม่ได้อยู่ที่จำนวนชั้น แต่อยู่ที่นิสัยที่ว่า "แยกบรรทัดเดียวที่ห้ามเปลี่ยนเด็ดขาดออกมา แล้วแสดงให้ AI ดูก่อนทุกครั้ง" บรรทัดเดียวนั้นคือแองเคอร์ของบริบท และไม่ว่าจะเป็นคนเดียวหรือทีมขนาดกลาง ก็เริ่มต้นจากตรงนั้น

สรุปประเด็นสำคัญของบท

• เมื่อเนื้อเรื่องที่เป็นนามธรรมที่สุดคลี่ออกเป็น Layer ได้ สาขาอื่นก็จะตามมาด้วยรูปแบบเดียวกัน
• L0 ต้องเล็กจึงจะไม่เปลี่ยน และต้องไม่เปลี่ยนจึงจะเป็นแองเคอร์ของบริบทในการสร้างและการตรวจสอบ
• ยิ่งกว่าตัวการแบ่ง Layer การติดระบบอัตโนมัติเข้ากับอินเทอร์เฟซแคบ ๆ ต่างหากคือแก่นแท้

5.2 การตรวจสอบความสอดคล้อง โลก → ตัวละคร → เควสต์

ก่อนเข้าสู่ช่วงเบตาไม่นาน มีบั๊กรีพอร์ตหนึ่งใบถูกส่งขึ้นมาจากฝ่าย QA หัวข้อคือ "พระราชาพูดจาไม่มีหางเสียง" เนื้อความสั้นมาก "ในคัตซีนเปิดของฉาก 3.4 K_001 (กษัตริย์) พูดกับผู้เล่นว่า 'เฮ้ เดี๋ยวก่อน' ตัวละครนี้ตั้งแต่ฉาก 1.1 จนถึง 3.3 ใช้คำว่า 'ท่าน' มาตลอด"

เมื่อถามนักเขียนบท คำตอบกลับน่าประหลาดใจ "บทพูดนั้นผมไม่ได้เขียนนะครับ" พอตามรอยดูจึงพบว่าเป็นนักเขียนภายนอก (outsource) ที่รีบเติมบรรทัดแยกสาขาของคัตซีนเข้าไปอย่างรวดเร็ว ในไบเบิลตัวละครของเรามี voice_profile อยู่ก็จริง แต่นักเขียนภายนอกคนนั้นไม่เคยเห็นเอกสารฉบับนั้นเลย กฎอยู่ในเอกสาร แต่บทพูดเข้ามาจากนอกเอกสาร

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

บทนี้ว่าด้วยเวิร์กโฟลว์ที่ดักอุบัติเหตุนั้นด้วย rulebook และตัวตรวจสอบ (checker) แทนสายตามนุษย์ เราจะดูจากตัวผลงานจริง ว่า rulebook ของ lore_consistency_rule กลายเป็นอินพุตของตัวตรวจสอบได้อย่างไร voice_lint คัดความสั่นไหวของโทนออกมาเป็นรายชื่อต้องสงสัยได้อย่างไร และเหตุใดการตัดสินขั้นสุดท้ายจึงต้องคงไว้ที่มนุษย์จนถึงที่สุด

5.2.1 อุบัติเหตุด้านความสอดคล้องรั่วออกจากตรงไหน

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

• ความขัดแย้งของโลก: ฉาก 1.1 บอกว่า "เวทมนตร์ถูกห้าม" → ฉาก 1.3 NPC กลับใช้เวทมนตร์อย่างไม่มีอะไรเกิดขึ้น
• ความสั่นไหวของน้ำเสียง (voice): NPC คนเดียวกันเปลี่ยนน้ำเสียงและคำลงท้ายยกย่องไปตามแต่ละฉาก (อุบัติเหตุ "พระราชาพูดไม่มีหางเสียง" ข้างต้น)
• ความขัดแย้งของเส้นเวลา: NPC ที่ตายไปแล้วกลับมาปรากฏตัวอย่างไม่เป็นอะไรในช่วงท้าย (ตกหล่นการซิงค์แฟล็กการตาย)
• รางวัลกับเรื่องเล่าไม่สอดคล้อง: เรื่องเล่าบอกว่าเป็น "ดาบที่พระราชาประทานให้" แต่ในข้อมูลกลับเป็นไอเทมเกลื่อนกลาดธรรมดา
• ความขัดแย้งของความสัมพันธ์ระหว่างฝ่าย: ทันทีหลังประกาศเป็นศัตรูกับฝ่าย A NPC ของฝ่าย A กลับทักทายอย่างเป็นมิตร

ทั้งห้าอย่างดูเหมือนเป็นอุบัติเหตุที่ต่างกัน แต่เมื่อตามรอยดูแล้วล้วนรั่วจากจุดเดียวกัน คือ Layer 0 (สมมติฐานของโลก) หรือ Layer 1 (กฎ) เปลี่ยนไป แต่การเปลี่ยนแปลงนั้นไม่ได้แพร่กระจายไปถึง Layer 2 (เนื้อหา) และ Layer 3 (ชีตข้อมูล) กฎถูกอัปเดตแล้ว แต่เนื้อหายังหยุดอยู่บนกฎเก่า

การจะกันเรื่องนี้ด้วยการตรวจสอบด้วยมือนั้นเกินกำลัง ในหนึ่งฉากมี NPC 50 ตัว บทพูด 2,000 บรรทัด และเควสต์ 30 อันพันกันอยู่ การที่มนุษย์จะตามรอยได้ 100% ว่าเมื่อแก้กฎไปหนึ่งบรรทัดแล้วผลกระทบจะลามไปถึงไหนนั้นเป็นไปไม่ได้ บรรทัดที่ตกหล่นไปจะไม่ถูกจับในขั้นตรวจสอบ แต่จะไปถูกจับในช่องรีวิวหลังวางจำหน่าย

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

5.2.2 lore_consistency_rule — rulebook ที่ป้อนให้ตัวตรวจสอบ

เอกสาร L1 ฉบับหนึ่งของโปรเจกต์ A คือ lore_consistency_rule.md เอกสารนี้เป็นทั้งไกด์ที่มนุษย์อ่าน และในขณะเดียวกันก็เป็นอินพุตที่ตัวตรวจสอบนำไปพาร์ส atoms และ affects ในฟรอนต์แมตเตอร์มัดสองบทบาทนี้ไว้ในกายเดียวกัน

---
title: กฎความสอดคล้องของโลก (lore)
layer: L1
atoms:
  - lore_check_world_rule
  - lore_check_character_voice
  - lore_check_timeline
  - lore_check_faction_relation
related:
  derives_from: [world_premise, narrative_pillar]
  affects: [main_quest/*, character_bible/*, dialogue_id_table]
---

## 1. กฎของโลก (World Rule)
- เริ่มต้นในสภาวะที่เวทมนตร์ถูกห้าม → เมื่อใช้เวทมนตร์ต้องระบุ (ช่วงเวลา ผู้ใช้ การอ้างความชอบธรรม) ให้ชัดเจน
- เทพเจ้าอยู่ในสภาวะนิ่งเงียบ → ห้ามบรรยายการตอบสนองโดยตรง (อนุญาตในความฝัน·ภาพนิมิต)

## 2. กฎน้ำเสียงตัวละคร
- บังคับให้อ้างอิง voice_profile ของแต่ละตัวละคร
- เมื่อเขียนบทพูดใหม่ ต้องปฏิบัติตาม voice_profile 5 หัวข้อ (คำศัพท์ ความยาวประโยค คำยกย่อง การแสดงอารมณ์ คำต้องห้าม)

## 3. กฎเส้นเวลา
- กำหนด status_timeline ให้ NPC ทุกตัว (มีชีวิต / บาดเจ็บ / เสียชีวิต / สูญหาย / เปลี่ยนตำแหน่ง)
- ตรวจ status_timeline อัตโนมัติ ณ ช่วงเวลาของบทพูดและการปรากฏตัว

## 4. กฎความสัมพันธ์ระหว่างฝ่าย
- บันทึกช่วงเวลาที่ faction_relation_matrix เปลี่ยน
- บทพูดหลังการเปลี่ยนต้องสะท้อนความสัมพันธ์ใหม่

บรรทัด affects เพียงบรรทัดเดียวกำหนดขอบเขตการสแกนของตัวตรวจสอบ เมื่อ world_premise เปลี่ยน ตัวตรวจสอบจะกวาดดู main_quest/*, character_bible/*, dialogue_id_table ทั้งหมดอีกครั้ง งานที่มนุษย์เคยตามรอยในหัวว่า "ผลกระทบจะไปถึงไหน?" กราฟความขึ้นต่อกัน (dependency graph) ที่เขียนไว้ใน rulebook ทำหน้าที่แทน

voice_profile เป็นทรัพยากร L2 แยกต่างหากที่ rulebook นี้อ้างอิงถึง โปรไฟล์ของตัวละครหนึ่งตัวถูกป้อนเป็นค่าตัวเลขและแบบแจกแจง (enumeration) เพื่อให้ตัวตรวจสอบใช้เป็นเกณฑ์เปรียบเทียบได้

# character_bible/K_001_voice_profile.yaml
character_id: K_001
display_name: กษัตริย์
voice_profile:
  vocabulary_register: โบราณ_เป็นทางการ      # ระดับคำศัพท์
  avg_sentence_len: 18                   # ความยาวประโยคเฉลี่ย (อักขระ)
  honorific: "ท่าน"                      # คำยกย่องบุรุษที่ 2 (ตายตัว)
  emotion_expression: สำรวม               # ระดับการเปิดเผยอารมณ์
  forbidden_terms: ["เฮ้", "เดี๋ยวก่อน", "5555"] # คำต้องห้าม

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

5.2.3 ลำดับการตรวจสอบความสอดคล้อง

ตัวตรวจสอบจะทำงานในวินาทีที่เกิดการเปลี่ยนแปลง ลำดับเป็นดังนี้

flowchart TD
    A[เกิดการเปลี่ยนแปลง: สมมติฐาน L0 / กฎ L1 / เนื้อหา L2] --> B{ตัวจำแนกการเปลี่ยนแปลง}
    B -->|เข้าข่าย affects ของกฎใด| C[เรียกตัวตรวจสอบที่เกี่ยวข้อง]
    C --> D[สแกนเนื้อหา L2 + ชีต L3 ในขอบเขต affects]
    D --> E[รายชื่อต้องสงสัย/ละเมิดกฎ]
    E --> F[แนบคอมเมนต์เข้ากับคำขอเปลี่ยนแปลงอัตโนมัติ]
    F --> G{การตัดสินโดยมนุษย์}
    G -->|ละเมิดจริง| H[แก้เนื้อหา → ตรวจซ้ำ]
    G -->|การเปลี่ยนที่ตั้งใจ| I[อัปเดต voice_profile / rulebook]
    G -->|กฎไวเกินไป| J[ปรับตัวกฎเอง]
    H --> K{เป็นขั้นข้อความหรือไม่}
    I --> K
    J --> K
    K -->|ใช่: ย้อนกลับได้| L[ปิดการตรวจสอบได้]
    K -->|ไม่: หลังอัดเสียง| M[ย้อนกลับไม่ได้ — ต้นทุนอัดเสียงใหม่]
    L -.เส้นกั้น.-> M

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    classDef fail fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    class B,C,D,F code;
    class G human;
    class A,E data;
    class L pass;
    class M fail;

สาขาสุดท้ายคือกระดูกสันหลังที่ซ่อนอยู่ของบทนี้ การตัดสินความสอดคล้องทั้งหมดต้อง จบในขั้นข้อความ นั่นคือขั้นที่ย้อนกลับได้ หากการตรวจสอบเลยไปสู่หลังการอัดเสียงและคัดเลือกนักพากย์ การแก้ไขก็จะกลายเป็นเรื่องที่ย้อนกลับไม่ได้ ด้วยเหตุนี้ ตัวตรวจสอบอย่าง voice_lint และ timeline_lint จึงไม่ได้สำคัญที่ทำงาน "เร็ว" แต่สำคัญที่ทำงาน แต่เนิ่น ๆ บทพูดของคัตซีนต้องผ่านการตรวจอย่างน้อยหนึ่งครั้งก่อนเข้าคิวอัดเสียง

ตัวตรวจสอบมีสี่ชนิด แต่ละชนิดสอดคล้องแบบหนึ่งต่อหนึ่งกับหนึ่งหัวข้อใน rulebook

• world_rule_lint.py — กฎโลก L1 + เนื้อหา L2 ทั้งหมด → รายการต้องสงสัยว่าละเมิด เช่น การใช้เวทมนตร์·การตอบสนองของเทพเจ้า
• voice_lint.py — voice_profile + dialogue_id_table → บทพูดต้องสงสัยว่าน้ำเสียงสั่นไหว
• timeline_lint.py — npc status_timeline + ช่วงเวลาของบทพูดและการปรากฏตัวทั้งหมด → ความขัดแย้ง เช่น NPC ที่ตายแล้วกลับมาปรากฏ
• faction_lint.py — faction_relation_matrix + dialogue tone → บทพูดที่ขัดแย้งกับความสัมพันธ์

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

5.2.4 บันทึกเซสชันจริง (worked transcript): รัน voice_lint หนึ่งรอบ

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

setup — ดึงบทพูดสองบรรทัดที่จะตรวจสอบมาจาก dialogue_id_table

dialogue_id_204  speaker=K_001  text="เฮ้ เดี๋ยวก่อนสิ ฝั่งนั้นพูดมาก่อนเลย"
dialogue_id_217  speaker=K_007  text="...เวรเอ๊ย ล้มเหลวอีกแล้ว เริ่มใหม่ตั้งแต่ต้น"

prompt — ตัวตรวจสอบเองทำงานบนพื้นฐานของกฎ (regex·การเทียบความยาว·การจับคู่คำต้องห้าม) AI จะถูกใส่ไว้เฉพาะตำแหน่งที่อธิบาย "ทำไมจึงต้องสงสัย" ด้วยภาษาธรรมชาติที่นักเขียนบทอ่านได้ พรอมต์ LLM ของขั้นตรวจสอบมีเนื้อความเต็มดังนี้

นี่คือรายการต้องสงสัยที่ voice_lint คัดออกมา อย่าตัดสิน แต่ให้อธิบาย
เฉพาะว่าแต่ละรายการน่าจะละเมิดหัวข้อใดของ voice_profile พร้อมเหตุผล 1~2 ประโยค
อย่าฟันธงว่า "ละเมิด/ไม่ละเมิด" ให้พูดแค่ "ต้องสงสัยว่า~" เท่านั้น

[voice_profile]
K_001: honorific="ท่าน", avg_sentence_len=18, forbidden=["เฮ้","เดี๋ยวก่อน"]
K_007: forbidden=["เวรเอ๊ย"]

[รายการต้องสงสัย]
- dialogue_id_204 (K_001): "เฮ้ เดี๋ยวก่อนสิ ฝั่งนั้นพูดมาก่อนเลย"
- dialogue_id_217 (K_007): "...เวรเอ๊ย ล้มเหลวอีกแล้ว เริ่มใหม่ตั้งแต่ต้น"

ผลลัพธ์ดิบจาก Claude (ถอดมาตามเดิม ไม่ได้สรุปหรือเรียบเรียง)

[dialogue_id_204 / K_001]
บทพูดนี้ต้องสงสัยว่าขัดแย้งกับหัวข้อ honorific voice_profile กำหนดคำยกย่อง
บุรุษที่ 2 ไว้ตายตัวเป็น "ท่าน" แต่บทพูดนี้ใช้ "ฝั่งนั้น" และไม่ปรากฏคำยกย่อง
ตัวมันเองเลย อีกทั้ง "เฮ้" และ "เดี๋ยวก่อน" ใน forbidden_terms ปรากฏทั้งคู่
จึงต้องสงสัยว่าหลุดออกจากระดับคำศัพท์ (โบราณ_เป็นทางการ) แม้จะดูไม่ขัดกับ
เกณฑ์ความยาวประโยคเฉลี่ย 18 อักขระโดยตรง แต่การที่น้ำเสียงเองกลายเป็นกันเอง
ก็ต้องสงสัยว่าเป็นสัญญาณการละเมิด

[dialogue_id_217 / K_007]
"เวรเอ๊ย" ใน forbidden_terms ถูกใช้ตรง ๆ จึงต้องสงสัยว่าละเมิดหัวข้อคำต้องห้าม
อย่างไรก็ตาม เนื่องจากไม่ได้ระบุหัวข้อ emotion_expression ของ K_007 (นักวิชาการ)
มาให้ จึงยากที่จะตัดสินด้วยข้อมูลเพียงเท่านี้ว่าการแสดงออกนี้เป็นการขับเน้นอารมณ์
ที่ตั้งใจ หรือเป็นเพียงการหลุดออกนอกกรอบ ต้องให้นักเขียนบทพิจารณาตัดสิน

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

verify — นักเขียนบทรับคอมเมนต์นี้มาตามเดิมจากคำขอเปลี่ยนแปลง การตัดสินเป็นหน้าที่ของนักเขียนบท

• 204: ละเมิดจริง เป็นบทพูดที่นักเขียนภายนอกใส่เข้าไปโดยไม่ได้ดู voice_profile → แก้เนื้อหา ตรวจซ้ำ
• 217: การละเมิดที่ตั้งใจ เป็นบทพูดขับเน้นอารมณ์ตอน K_007 พังทลายในฉาก 3.4 → เพิ่มแฟล็ก emotion_peak_exception ใน voice_profile แล้วลงทะเบียน 217 เป็นข้อยกเว้น

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

5.2.5 ทำไมการตัดสินจึงเป็นที่ของมนุษย์

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

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

ประการที่สอง ตัวกฎเองวิวัฒน์ หากข้อสงสัยชนิดเดียวกันถูกตัดสินเป็น "การเปลี่ยนที่ตั้งใจ" อยู่เรื่อย ๆ นั่นคือสัญญาณว่ากฎตามความเป็นจริงไม่ทัน ผลการตรวจไม่ได้ทำให้แก้แค่เนื้อหา แต่ทำให้แก้ rulebook ด้วย

ประการที่สาม ตัวละครและฝ่ายใหม่ต้องการช่วงเรียนรู้ NPC ใหม่ที่ voice_profile ยังถูกเติมแค่สองสามหัวข้อนั้น เป็นเรื่องปกติที่จะมีข้อสงสัยขึ้นมาเยอะ หากในช่วงนี้ตั้งให้ปฏิเสธอัตโนมัติ นักเขียนบทก็จะมองตัวตรวจสอบเป็นศัตรู

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

ขอเสริมข้อสังเกตหนึ่งข้อ หลักการที่ว่าการตรวจสอบต้องจบในขั้นข้อความ (เส้นกั้นในผังลำดับข้างต้น) ใช้กับการตัดสินของมนุษย์ด้วยเช่นกัน การตัดสิน "การละเมิดที่ตั้งใจ" ของนักเขียนบทก็ต้องจบก่อนการอัดเสียง การกลับคำหลังอัดเสียงไปแล้วจะเปลี่ยนจากปัญหาของตัวตรวจสอบกลายเป็นปัญหาต้นทุนกระบวนการผลิต (รายละเอียดทั้งหมดของเส้นแบ่งย้อนกลับได้/ย้อนกลับไม่ได้อยู่ที่ 5.4.5)

5.2.6 การวัดผล — ก่อนและหลัง 6 เดือน

ในโปรเจกต์ A เราทยอยนำตัวตรวจสอบทั้ง 4 ชนิดมาใช้เป็นขั้น ๆ และวัดผลตลอด 6 เดือน ด้านล่างอ้างอิงจากบันทึกการวัดจริง แต่ถอดมาเป็นทิศทาง·อัตราส่วนแทนค่าสัมบูรณ์ (วัดภายในบริษัท ไม่ใช่การประมาณของผู้เขียน)

• เวลาตรวจสอบหนึ่งบท: ก่อนนำมาใช้ราว 5 วัน → หลังนำมาใช้ราว 2 วัน (ไม่ถึงครึ่ง)
• อุบัติเหตุด้านความสอดคล้องที่พบหลังวางจำหน่าย: 3\~5 ครั้งต่อบท → 0\~1 ครั้ง
• ความเร็วในการผลิตหนึ่งบทต่อนักเขียน 1 คน: 4 สัปดาห์ → 2.5 สัปดาห์
• ความถี่ในการอัปเดต rulebook (L1): ไตรมาสละ 1\~2 ครั้ง → เดือนละ 1\~2 ครั้ง

ข้อสุดท้ายน่าสนใจที่สุด เมื่อมีตัวตรวจสอบ การเปลี่ยนกฎบ่อยก็ปลอดภัย เพราะพอแก้กฎไปหนึ่งบรรทัด ผลกระทบจะปรากฏให้เห็นโดยอัตโนมัติ ความกลัวการเปลี่ยนแปลงจึงลดลง และกฎก็วิวัฒน์เร็วขึ้น ผลที่แท้จริงของเครื่องมือด้านความสอดคล้องจึงไม่ใช่ "ลดอุบัติเหตุได้" แต่ค่อนไปทาง "ทำให้กล้าเปลี่ยนกฎโดยไม่กลัว" เสียมากกว่า

อนึ่ง ตัวเลขข้างต้นเป็นตัวเลข ณ ช่วงที่ตัวตรวจสอบทั้ง 4 ชนิดทำงานครบ สิ่งที่สำคัญกว่าคือในช่วงเริ่มต้น แค่ voice_lint อันเดียวก็ให้ผลที่เห็นได้ชัดแล้ว ไม่จำเป็นต้องเปิดครบทั้ง 4 ชนิดตั้งแต่แรก

5.2.7 จะวาง AI ไว้ที่ไหน

ตัวตรวจสอบอัตโนมัติส่วนหลักนั้นใช้แบบอิงกฎจะมีประสิทธิภาพกว่า เพราะอินพุตเดียวกันต้องให้ผลเดียวกัน ความเชื่อมั่นจึงจะสะสม ในขณะที่ LLM เป็นแบบไม่กำหนดผลแน่นอน (non-deterministic) จึงไม่เหมาะกับตำแหน่งนั้น AI เข้าไปอยู่ในอีกสี่ตำแหน่ง

• การตรวจจับรายการต้องสงสัยว่าละเมิดกฎ → กฎ (regex·คีย์เวิร์ด·ความยาว·การตรวจโครงสร้าง) ไม่ใช่ LLM
• การอธิบายเหตุผลของรายการต้องสงสัย → LLM คำอธิบายภาษาธรรมชาติว่า "ทำไมจึงต้องสงสัย" ที่เห็นใน worked transcript ข้างต้น
• การร่างบทพูดทางเลือก → LLM ร่างเพื่อให้นักเขียนบทพิจารณา ผู้ตัดสินใจขั้นสุดท้ายคือนักเขียนบท
• การเสนอรายการอัปเดต voice_profile อัตโนมัติ → LLM ดึงรูปแบบจากเนื้อหาหลายสิบฉากเพื่อเสนอแนวทางเสริมหัวข้อ

กฎนั้นเร็วและกำหนดผลแน่นอน ส่วน LLM เก่งเรื่องการอธิบายและการสร้าง หากเอาบทบาทของสองสิ่งนี้มาปนกันจะพังทั้งคู่ ถ้าฝากการตรวจไว้กับ LLM จะเกิดเรื่องที่บทพูดเดียวกันเมื่อวานผ่านแต่วันนี้ติด และถ้าฝากการอธิบายไว้กับ regex ก็จะได้แค่ภาษาเครื่องว่า "ละเมิดหัวข้อ honorific" ออกมาเท่านั้น

5.2.8 ลำดับการนำมาใช้และความล้มเหลวที่พบบ่อย

ถ้าทำตัวตรวจสอบครบทั้ง 4 ชนิดตั้งแต่แรก ภาระจะมาก่อนผล ลำดับที่แนะนำคือเริ่มจากอันที่ถูกที่สุดและให้ผลมากที่สุด

1. มาตรฐาน 5 หัวข้อของ voice_profile (ราว 1 เดือน) — ตั้งฟอร์แมตของ character_bible ให้อยู่ตัวก่อน อันนี้มาก่อนตัวตรวจสอบ
2. voice_lint เวอร์ชันขั้นต่ำ (ราว 1 สัปดาห์) — แค่จับคู่คำต้องห้าม การกันแค่หนึ่งคำก็ลดอุบัติเหตุบน SNS หลังวางจำหน่ายได้ไตรมาสละ 1\~2 ครั้ง
3. timeline_lint (1\~2 สัปดาห์) — ตรวจแฟล็กการตาย แค่จับ NPC ที่ตายแล้วกลับมาปรากฏก็ให้ความรู้สึกต่างมาก
4. world_rule_lint + faction_lint (1\~2 เดือน) — อีกสองชนิดที่เหลือ
5. AI ช่วยเสริม (เพิ่มอีก 1\~2 เดือน) — รวมการอธิบายและการสร้างร่างเข้าด้วยกัน

ขอย้ำว่าแค่ขั้นที่ 2 (voice_lint) อันเดียวก็ให้ผลมากแล้ว อุบัติเหตุ "พระราชาพูดไม่มีหางเสียง" ข้างต้นคือชนิดที่ดักได้ด้วยขั้นนี้เพียงขั้นเดียวพอดี

ความล้มเหลวที่เกิดซ้ำในกระบวนการนำมาใช้ก็แทบจะกำหนดไว้ตายตัวแล้วเช่นกัน

• ทำเป็นแบบปฏิเสธอัตโนมัติ → คืนกลับสู่โครงสร้างรายการต้องสงสัย + การตัดสินโดยมนุษย์
• rulebook ถูกดำเนินการแยกขาดจากนักเขียนบท → กำหนดให้การเปลี่ยน rulebook ต้องมีฉันทามติของนักเขียนบท และให้นักเขียนบทขอเปลี่ยน rulebook ได้
• voice_profile เป็นแค่พิธีการ → เติม 5 หัวข้อให้ครบสมบูรณ์ด้วยตัวละคร 1 ตัวก่อนแล้วจึงขยาย
• ไม่รู้ว่าผลการตรวจอยู่ที่ไหน → บังคับให้แนบเข้ากับคอมเมนต์คำขอเปลี่ยนแปลงโดยอัตโนมัติ
• ให้ LLM ทำการตรวจเอง → การตรวจคือกฎ ส่วนการอธิบายเท่านั้นที่เป็น LLM
• ตรวจสอบหลังอัดเสียง → การตรวจสอบจบในขั้นข้อความ ไม่ปล่อยให้ข้ามช่วงที่ย้อนกลับได้ไป

ข้อสุดท้ายแพงกว่าข้ออื่นทั้งหมดข้างต้น ความล้มเหลวอื่นทำให้เสียเวลา แต่ความล้มเหลวนี้ทำให้เสียตารางงานของนักพากย์

ในบทถัดไป (5.3) จะว่าด้วยลำดับการเขียนเนื้อหาเนื้อเรื่องด้วย AI ช่วยเสริมแทนตัวตรวจสอบ เราจะดูวิธีฉีดโทน L0 และกฎ L1 เข้าไปเป็นคอนเทกซ์ เพื่อให้ AI ออกคำตอบของโลกของเราแทนที่จะเป็นคำตอบทั่วไป

สรุปประเด็นสำคัญของบท

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

ตัวอย่างบทถัดไป

• 5.3 การเขียนเนื้อเรื่องด้วย AI ช่วยเสริม — การฉีดคอนเทกซ์โทน L0·กฎ L1

ลองทำดู

setup — เลือกตัวละคร 1 ตัวจาก character_bible แล้วเติม voice_profile 5 หัวข้อ (ระดับคำศัพท์·ความยาวประโยคเฉลี่ย·คำยกย่อง·การแสดงอารมณ์·คำต้องห้าม) ให้ครบสมบูรณ์เป็น yaml จากนั้นดึงบทพูดเดิม 10 บรรทัดของตัวละครเดียวกันมาจาก dialogue_id_table รวมไว้ในไฟล์เดียว

prompt — ใช้พรอมต์ช่วยตรวจจาก worked transcript ข้างต้นตามเดิม หัวใจคือข้อจำกัดสองข้อ "อย่าตัดสิน" และ "พูดแค่ \~ต้องสงสัยว่า เท่านั้น" แนบ voice_profile yaml และบทพูด 10 บรรทัดเข้าไปในอินพุต

verify — ตัดสินรายการต้องสงสัยที่ออกมาทีละบรรทัดด้วยตัวคุณเอง ถ้าละเมิดจริงก็แก้เนื้อหา ถ้าเป็นการเปลี่ยนที่ตั้งใจก็เพิ่มแฟล็กข้อยกเว้นใน voice_profile ตรวจไปพร้อมกันด้วยว่า AI ดันทุรังว่า "หัวข้อที่ไม่ได้ละเมิด" เป็นการละเมิดหรือไม่ และยอมรับ "ข้อมูลไม่พอ" หรือไม่ หาก AI ฟันธงว่าทุกหัวข้อเป็นการละเมิด ให้เสริมข้อจำกัด "อย่าตัดสิน" ในพรอมต์ให้แข็งแรงขึ้น

ฉบับย่อสำหรับคนเดียว

หากเป็นการพัฒนาคนเดียวที่ไม่มีทั้งตัวตรวจสอบ 4 ชนิดและ rulebook คุณก็ยังสร้างผลแบบเดียวกันได้ด้วยพรอมต์เพียงอันเดียวโดยไม่ต้องมีตัวตรวจสอบส่วนหลัก แค่ดูแล voice_profile yaml ของแต่ละตัวละครด้วยมือ และทุกครั้งที่เขียนบทพูดใหม่ ก็แนบ yaml ของตัวละครนั้น + บทพูดใหม่เข้ากับพรอมต์ช่วยตรวจข้างต้นเพื่อรับ "รายการต้องสงสัย" ไม่มีระบบอัตโนมัติก็จริง แต่โครงสร้างหัวใจที่ว่า มนุษย์เป็นผู้ตัดสิน AI เป็นผู้อธิบาย ยังคงอยู่เหมือนเดิม แค่รักษาบรรทัดเดียวให้ได้ก็พอ — ผ่านการตรวจนี้สักหนึ่งครั้งก่อนส่งต่อให้การอัดเสียงและการสังเคราะห์เสียง หลักการที่ว่าไม่ปล่อยให้ข้ามช่วงที่ย้อนกลับได้ไปนั้น ไม่ขึ้นกับขนาดของทีม

5.3 การเขียนเนื้อเรื่องโดยมี AI ช่วย

วันนั้นเป็นวันที่ผมกำลังร่างบทพูดแรกของ NPC ข้างเคียงตัวใหม่ ผมพิมพ์ลงในช่องแชตที่ว่างเปล่าว่า "ช่วยสร้างบทพูดให้ NPC ช่างตีเหล็กในหมู่บ้าน 5 บรรทัด" 5 วินาทีต่อมา หน้าจอก็แสดง "ผู้กล้าเอ๋ย จงมอบอาวุธของเจ้าไว้กับข้า" มันไม่ใช่แค่ประโยคที่รู้สึกเหมือนเคยเห็นที่ไหนสักแห่ง แต่เป็นประโยคที่ผมแทบจะบอกได้ว่าเห็นมาจากที่ไหนแน่ ๆ ต่อให้เอาพรอมต์เดียวกันไปใส่ในเกมอื่นของทีมอื่น ก็จะได้คำตอบแบบเดียวกันกลับมา สิ่งที่ผมตระหนักได้ในชั่วขณะนั้นไม่ใช่ว่าโมเดลอ่อนแอ แต่เป็นว่าผมไม่ได้บอกอะไรเกี่ยวกับเกมของเราให้โมเดลรู้เลยสักอย่าง

AI เขียนประโยคแฟนตาซีทั่ว ๆ ไปได้ดี แต่เขียนประโยคของโลกในเกมเราไม่ได้ ความต่างมีเพียงสิ่งเดียว นั่นคือการป้อนบริบท (context) ถ้าส่งโทน L0 และกฎ L1 ไปพร้อมกันในทุก ๆ คำขอ บรรทัดที่ AI พ่นออกมาจะเปลี่ยนจาก "ประโยคที่รู้สึกเหมือนเคยเห็นที่ไหนสักแห่ง" ไปเป็น "ประโยคของเกมนี้" บทนี้ว่าด้วยการปฏิบัติจริงในการบริหารการป้อนนั้นเป็น 4 ชั้น และในตอนท้ายจะชี้ให้เห็นถึงการประยุกต์ใช้แบบก้าวหน้า (world BT (BehaviorTree, ต้นไม้พฤติกรรม) + คลาวด์เควสต์) ที่ยกหลักการเดียวกันขึ้นไปสู่ระดับการจำลองโลกทั้งใบ ในฐานะแนวหน้าของงาน RnD

5.3.1 สิ่งที่เกิดขึ้นเมื่อบริบทว่างเปล่า

ในสายงานเนื้อเรื่อง การมี AI ช่วยเป็นพื้นที่ที่ถูกนำมาใช้เร็วที่สุด และสูญเสียความเชื่อมั่นเร็วที่สุดเช่นกัน เพราะรูปแบบความล้มเหลวแทบจะเหมือนกันทุกครั้ง

ถ้าโยนคำสั่ง "บทพูดเริ่มเควสต์ 5 บรรทัด" ไป ก็จะได้แฟนตาซีทั่วไป 5 แบบที่ขึ้นต้นด้วย "ผู้กล้าเอ๋ย หมู่บ้านของเรา..." กลับมา ถ้าบอก "ช่วยแก้บทพูดของตัวละครนี้หน่อย" เสียง (voice) ก็จะถูกปรับให้กลายเป็นมาตรฐานเดียวกัน จน NPC ทุกตัวลู่เข้าหาน้ำเสียงที่คล้าย ๆ กัน ถ้าบอก "ช่วยเขียนเรื่องย่อบทที่ 1" ก็จะได้ค่าเฉลี่ยของเรื่องย่อ RPG ที่เคยเห็น ๆ มาออกมา

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

ในโปรเจกต์ MMORPG ที่ผู้เขียนดูแล (ต่อไปนี้เรียกว่าโปรเจกต์ A) การมี AI ช่วยงานเนื้อเรื่องจะวางบริบท 4 ชั้นเรียงตามลำดับ โครงสร้างที่แยก NarrativeDocs ออกเป็น Layer 0\~4 ใน 5.1 ถูกนำกลับมาใช้เป็นหน่วยของการป้อนตรงนี้นั่นเอง

ไม่ได้ใส่ครบทั้ง 4 ชั้นทุกครั้ง ดึงออกมาเฉพาะชั้นที่จำเป็นตามประเภทของงาน ถ้าเป็นร่างบทพูดถัดไปของตัวละครหนึ่ง A + B (เฉพาะโทน) + D (บทพูดล่าสุด 10 บรรทัดของตัวละครนั้น) ก็เพียงพอ ถ้าเป็นเรื่องย่อของเควสต์ข้างเคียงตัวใหม่ ก็เพิ่ม C (กฎโครงสร้าง quest) เข้าไป ถ้าเป็นทางแยก 4 แบบของผลลัพธ์ ก็จะหนักขึ้นด้วย C (กฎทางแยก) + D (เนื้อหาทั้งหมดก่อนหน้าทางแยก) เปรียบเสมือนหยิบชีตเพอร์โซนา ภาพรวมโลกหนึ่งบรรทัด หน้ารูลบุ๊ก และชุดเนื้อหาใกล้เคียงจากแฟ้มเอกสารบนโต๊ะ มาเลือกส่งให้พอดีกับขนาดของงาน

5.3.2 บันทึกเซสชันจริง (worked transcript) หนึ่งชุด — บทพูดที่เผยอารมณ์ครั้งแรกของ K_007

แทนที่จะอธิบายแบบนามธรรม จะตามคำขอจริงหนึ่งคำขอไปจนจบ เป็นงานร่างบทพูด 3 แบบในฉากที่ตัวละครเดียวกัน (NPC แบบนักวิชาการ ID ภายในบริษัทคือ K_007) ต้องเผยอารมณ์ออกมาเป็นครั้งแรก เริ่มจากตัวพรอมต์เต็ม

พรอมต์ที่ส่งไป (Layer A + B (โทน) + D + คำสั่งงาน + รูปแบบผลลัพธ์):

[ระบบ]
นายคือนักเขียนเนื้อเรื่องของโปรเจกต์ A อย่าใช้คำซ้ำซากของ RPG อย่าง "ผู้กล้า"·"ผู้ถูกเลือก"
น้ำเสียงให้ตามโทนของบทพูดก่อนหน้าด้านล่างเป๊ะ ๆ เซตติงที่ไม่รู้อย่ากุขึ้นเอง
ให้ตอบว่า "จากบริบทไม่สามารถตัดสินได้" นายเขียนแค่ร่าง การตัดสินใจเป็นของฉัน

[โทน L0 — ตัดตอนจาก tone_manifesto]
อารมณ์ของโลกใบนี้คือการเก็บงำ ตัวละครจะไม่พูดความรู้สึกออกมาง่าย ๆ
อารมณ์เผยออกมาไม่ใช่ในรูปการระเบิด แต่ในรูปรอยร้าว ประโยคขาดห้วนและสั้น

[อ้างอิง — บทพูด 5 บรรทัดล่าสุดของ K_007 (เรียงตามเวลา ต้นฉบับตามเดิม)]
1. "...อันนั้นผมเองก็เพิ่งเคยได้ยินเหมือนกันนะครับ"
2. "มีบันทึกไหม ถ้าไม่มีก็ต้องสงสัยไว้ก่อน"
3. "อย่าเพิ่งขยับจนกว่าจะแน่ใจ"
4. "ความเห็นของผมก็มีแค่นั้น"
5. "...ขอโทษครับ ผมเย็นชาเกินไปหรือเปล่า"

[สถานการณ์]
NPC เพื่อนร่วมทางกลับมาในสภาพบาดเจ็บ นักวิชาการต้องเผยอารมณ์ออกมาเป็นครั้งแรก

ขอแค่ 3 แบบเท่านั้น แต่ละแบบไม่เกิน 25 ตัวอักษร ต่อท้ายแต่ละแบบด้วยป้ายกำกับ (ประเภทปฏิกิริยา: โกรธ/เศร้า/ปฏิเสธ)
ตัดคำอธิบายและคำเกริ่นนำออก

ผลลัพธ์ดิบของ Claude (ตามเดิม ไม่สรุปย่อหรือดัดแปลง):

1. "...ทำไมต้องแบกมันไว้คนเดียว โง่จริง ๆ" (ประเภทปฏิกิริยา: เศร้า)
2. "ผมน่าจะดูบันทึก ผม ผมพลาดไปเอง" (ประเภทปฏิกิริยา: ปฏิเสธ)
3. "ไม่เป็นไร ทุกอย่างไม่เป็นไร เพราะงั้นหยุด—" (ประเภทปฏิกิริยา: ปฏิเสธ)

จุดสำคัญคือไม่หยุดอยู่ตรงนี้ นักเขียนอ่านทั้งสามแบบแล้วตรวจสอบ แบบที่ 1 โทนถูกต้อง รอยร้าวที่บทพูดล่าสุดบรรทัดที่ 5 "...ขอโทษครับ" แสดงออกมา แบบที่ 1 รับช่วงต่อด้วยคำเดียวว่า "โง่จริง ๆ" เป็นตัวเลือกที่จะรับไว้ แบบที่ 2 การพูดติด ๆ ขัด ๆ ของ "ผม ผมพลาดไปเอง" ขัดกับการเก็บงำของนักวิชาการอยู่นิดหน่อย พักไว้ก่อน แบบที่ 3 ป้ายกำกับผิด การพูดซ้ำ "ไม่เป็นไร" ไม่ใช่การปฏิเสธ แต่ใกล้เคียงการหลีกหนีมากกว่า ซึ่งใน voice_profile ของเราไม่มีรูปแบบที่นักวิชาการจัดการอารมณ์ด้วยการหลีกหนี ปฏิเสธ

คำขอใหม่ (ส่งไปอีกครั้งพร้อมระบุเหตุผลที่ปฏิเสธ):

แบบที่ 3 ปฏิเสธ การพูดซ้ำ "ไม่เป็นไร" ไม่ใช่รูปแบบของนักวิชาการคนนี้ หมอนี่จัดการอารมณ์
ไม่ใช่ด้วยการหลีกหนี แต่ด้วย 'การโทษตัวเองที่ตรวจสอบข้อเท็จจริงล้มเหลว' แบบที่ 1 ฉันจะรับไว้
ในตำแหน่งของแบบที่ 2·3 ขอสองแบบที่ผิวสัมผัสต่างจากแบบที่ 1 มาใหม่ ไม่ต้องพูดติดขัด ไม่เกิน 25 ตัวอักษร

ผลลัพธ์ครั้งที่สองของ Claude:

2. "บันทึกไม่โกหก ผมต่างหากที่ไม่ได้ดู" (ประเภทปฏิกิริยา: โทษตัวเอง)
3. "...นั่งลงก่อน รักษาแผลก่อน ค่อยพูดทีหลัง" (ประเภทปฏิกิริยา: เศร้า)

คราวนี้ผ่านทั้งสองแบบ แบบที่ 2 นำคำศัพท์หลักของนักวิชาการอย่าง "บันทึก" (บทพูดล่าสุดบรรทัดที่ 2 "มีบันทึกไหม") กลับมาเขียนใหม่ให้เป็นสื่อกลางของการโทษตัวเอง ส่วนแบบที่ 3 แสดงรูปแบบที่นักวิชาการกดอารมณ์ลงด้วยการกระทำ ผ่านประโยคสั่งแบบเก็บงำ การรับขั้นสุดท้ายคือแบบที่ 1 + แบบที่ 2 + แบบที่ 3 สามบรรทัดนี้ผ่านการตรวจสอบอัตโนมัติ voice_lint ใน 5.2 แล้วถูกนำไปสะท้อนในเนื้อหา L2 และได้รับ dialogue_id ออกมาที่ L3

ในบันทึกเซสชันชุดเดียวนี้มีทุกอย่างของบทนี้อยู่ครบ การป้อนโทน (L0) ช่วยกู้แบบที่ 1 ไว้ เนื้อหาใกล้เคียงที่เป็นต้นฉบับตามเดิม (L2) ทำให้คำศัพท์ "บันทึก" ของนักวิชาการถูกนำกลับมาใช้ในคำขอใหม่ การบังคับรูปแบบผลลัพธ์กันการพูดเรื่อยเปื่อย และด่านปฏิเสธของนักเขียนกรองป้ายกำกับที่ผิดของแบบที่ 3 ออกไป AI ไม่ได้ตัดสินใจขั้นสุดท้ายแม้แต่บรรทัดเดียว

5.3.3 Layer A — ระบบพรอมต์ บรรทัดเดียวกำหนดทุกสิ่ง

เป็นนิยามเพอร์โซนาที่ปูอยู่บนสุด กำหนดไว้ครั้งเดียวแล้วแทบไม่เปลี่ยน บล็อกระบบในบันทึกเซสชันข้างต้นคือตัวจริงของมัน ในห้าบรรทัด บรรทัดสุดท้าย ("เขียนร่าง การตัดสินใจเป็นของนักเขียน") สำคัญที่สุด ถ้าขาดบรรทัดนี้ไป AI จะเสนอประโยคที่ทำเป็น "ขั้นสุดท้าย" ออกมาอย่างมั่นใจ แล้วนักเขียนก็จะกลายเป็นคนให้คะแนนแทนที่จะตรวจสอบ และบรรทัดที่สาม ("เซตติงที่ไม่รู้อย่าสร้างขึ้น ให้ตอบว่าตัดสินไม่ได้") สำคัญเป็นอันดับสอง ถ้าไม่มีบรรทัดนี้ โมเดลจะเติมช่องว่างด้วยคำโกหกที่ดูเข้าท่า ในงานเนื้อเรื่อง คำโกหกที่ดูเข้าท่าจะย้อนกลับมาเป็นความขัดแย้งของ lore (เนื้อเรื่องโลก) ในอีกไม่กี่วันถัดมา

5.3.4 Layer B — วิสัยทัศน์ L0 และตำแหน่งของแคชชิง

L0 มีปริมาณน้อย (ตามเกณฑ์ 5.1 ประมาณ 4.5 บท) แทบจะป้อนทั้งหมดได้ทุกครั้ง โดยประมาณตามเกณฑ์ภาษาเกาหลี world_premise.md ประมาณ 2,500 โทเค็น narrative_pillar.md ประมาณ 1,500 โทเค็น tone_manifesto.md ประมาณ 3,000 โทเค็น รวมกันประมาณ 7,000 โทเค็น (ตัวเลขเหล่านี้เป็นการประมาณของผู้เขียน (ยังไม่ได้ตรวจสอบ) จะเปลี่ยนไปตาม tokenizer และการปรับปรุงเอกสาร)

ถ้าส่ง 7,000 โทเค็นใหม่ทุก ๆ คำขอ ค่าใช้จ่ายจะสะสมขึ้น ดังนั้นจึงเปิดใช้แคชชิงพรอมต์ (prompt caching) เป็นฟีเจอร์ที่ทั้ง Anthropic และ OpenAI รองรับ และเมื่อแคชเข้าเป้า (cache hit) ค่าใช้จ่ายโทเค็นอินพุตจะลดลงมาก หัวใจคือการแยกสิ่งที่เปลี่ยนกับสิ่งที่ไม่เปลี่ยนออกจากกันภายในข้อความ

messages = [
    {"role": "system", "content": SYSTEM_PROMPT},
    {"role": "user", "content": [
        {"type": "text", "text": L0_FULL,      "cache_control": {"type": "ephemeral"}},
        {"type": "text", "text": L1_SELECTED,  "cache_control": {"type": "ephemeral"}},
        {"type": "text", "text": L2_ADJACENT},   # เปลี่ยนทุกครั้ง — ไม่แคช
        {"type": "text", "text": TASK_INSTRUCTION},  # เปลี่ยนทุกครั้ง
    ]},
]

L0 และ L1 ที่ติด cache_control เป็นเป้าหมายของการแคช ส่วนเนื้อหาใกล้เคียง L2 และคำสั่งงานเปลี่ยนทุกครั้งจึงไม่แคช การรวมบล็อกแคชไว้ส่วนหน้าของข้อความเสมอเป็นตัวกำหนดอัตราเข้าเป้า ถ้าบล็อกที่เปลี่ยนแทรกเข้ามาด้านหน้า แคชที่ตามหลังจะถูกทำให้เป็นโมฆะทั้งหมด การวางลำดับนี้ผิดคือสาเหตุที่พบบ่อยที่สุดของการเปิดแคชชิงแล้วค่าใช้จ่ายไม่ลดลง

รายละเอียดของตัวเลขอัตราการเข้าเป้าแคชและการประหยัดค่าใช้จ่าย จะกล่าวในบทของ ส่วนที่ 22 (ค่าใช้จ่าย) ตรงนี้แค่จำหลักการ "ไล่สิ่งที่เปลี่ยนไปไว้ข้างหลัง" ก็พอ

5.3.5 Layer C — ไม่ใส่กฎ L1 ทั้งก้อน

รูลบุ๊ก L1 มีปริมาณมาก ถ้าใส่ทั้งหมดบริบทจะแตก และที่แย่กว่านั้นคือโมเดลจะพลาดประเด็นหลัก เลือกเฉพาะกฎที่เกี่ยวกับงาน แถมยังเลือกเฉพาะหัวข้อ _summary อีกด้วย

ตอนร่างผลลัพธ์ทางแยกของเควสต์หลัก จะเลือก dialogue_branching_rule และ faction_relation_matrix ถ้าเป็นบทพูด NPC ตัวใหม่ ก็เป็น voice_profile และ tone_manifesto ของ NPC ตัวนั้น ถ้าเป็นรายการใหม่ในพจนานุกรม lore ก็เป็น lore_consistency_rule และ world_premise ถ้าเป็นโครงเควสต์ข้างเคียง ก็เป็น quest_template และ reputation_model การเลือกทำโดยคนเองโดยตรง หรือสกัดอัตโนมัติตามกราฟ wikilink (ส่วนที่ 7) ซึ่งเมื่อสกัดอัตโนมัติจะให้ความสำคัญกับ recall มากกว่า precision เพราะความเสียหายจากการที่กฎหนึ่งข้อตกหล่นไป มากกว่าความเสียหายจากการที่กฎหนึ่งข้อเข้ามาเกินมาก

แทนที่จะใส่เนื้อหารูลบุ๊กทั้งหมด ให้วางหัวข้อ _summary ไว้ที่หัวไฟล์รูลบุ๊กแล้วป้อนแค่นั้น

---
title: กฎทางแยก
layer: L1
---

## _summary
- ทางแยกเกิดเฉพาะตอนจบบทเท่านั้น
- ทางแยกมี 2~3 แบบ ห้ามเกิน 4 แบบขึ้นไป
- การเลือกทางแยกส่งผลต่อชื่อเสียง +/-1 ทางแยกตอนจบ +/-3
- ผลลัพธ์ของทุกทางแยกต้องแสดงผลภายใน 24 ชั่วโมง
- ทางแยกย้อนกลับไม่ได้ (แนะนำแยกเซฟ แสดงผลบน UI)

## 1. กฎจุดเวลาที่ทางแยกเกิดขึ้น
(คำอธิบายละเอียด สำหรับผู้ดูแลอ้างอิง — ไม่ป้อนให้ LLM)
...

_summary 5 บรรทัดมีผลต่อคุณภาพผลลัพธ์ของ LLM มากกว่าเนื้อหา 50 บรรทัด โมเดลปฏิบัติตามกฎที่สั้นและฟันธงได้ดีกว่า คำอธิบายยาว ๆ ทำให้ความสนใจของโมเดลกระจาย และความสนใจที่กระจายก็ย้อนกลับมาเป็นการละเมิดกฎ

5.3.6 Layer D — ไม่สรุปย่อเนื้อหาใกล้เคียง

บทพูดล่าสุด เควสต์ใกล้เคียง เรื่องย่อบทเดียวกัน เป็นบริบทที่ผันผวนมากที่สุด สำหรับบทพูดใหม่ของตัวละครเดียวกัน ให้ใส่บทพูดล่าสุด 10 บรรทัดของตัวละครนั้นเรียงตามเวลา สำหรับเควสต์กลางบท ให้ใส่เรื่องย่อบทและสรุปเควสต์ในบทเดียวกันบรรทัดละเรื่อง สำหรับตอนจบที่เป็นผลของทางแยก ให้ใส่เนื้อหาทั้งหมดก่อนหน้าทางแยกและข้อความของตัวเลือก ถ้าใส่มากเกินไป LLM จะพ่นค่าเฉลี่ยออกมา ถ้าใส่น้อยเกินไปก็จะได้ผลลัพธ์แบบทั่วไป จุดที่เหมาะสมอยู่ระหว่างโทเค็น 1,500\~3,000 (ตามการสังเกตของผู้เขียน ยังไม่ได้ตรวจสอบ)

กฎหลักหนึ่งข้อ เนื้อหาใกล้เคียงให้ใส่เป็นต้นฉบับตามเดิม โดยไม่แปรรูปหรือสรุปย่อ ที่บันทึกเซสชันข้างต้นใส่บทพูด 5 บรรทัดล่าสุดของนักวิชาการลงไปตามเดิมโดยไม่แตะต้อง โมเดลจึงสามารถหยิบคำว่า "บันทึก" มาได้อย่างแม่นยำในขั้นคำขอใหม่ และนำมาใช้ซ้ำเป็นสื่อกลางของการโทษตัวเอง หากใส่ 5 บรรทัดนั้นไปในรูปสรุปย่อว่า "นักวิชาการเป็นคนรอบคอบและเย็นชา" การเลือกอันละเอียดอ่อนของนักเขียนทั้งหมดจะหายไป แล้วโมเดลก็จะกลับไปสู่ค่าเฉลี่ยอีกครั้ง การสรุปย่อไม่ได้แค่ลดข้อมูล แต่ลบการตัดสินใจที่นักเขียนได้ตัดสินไปแล้ว

5.3.7 เวิร์กโฟลว์การตรวจสอบของนักเขียน — ใช้อัตราการทิ้งเป็นตัวชี้วัด

ผลลัพธ์ของ AI เป็นร่างเสมอ การตรวจสอบจะต้องผ่านด่านที่กำหนดไว้

flowchart TD
    A[ผลลัพธ์ AI N รายการ] --> B[ขั้น 1: voice_lint อัตโนมัติ
5.2]
    B --> C[ขั้น 2: นักเขียน 1 คนเลือก·แก้ไข
ประมาณ 15 นาที]
    C --> D{มีแบบที่รับไหม?}
    D -->|มี| E[ขั้น 3: ตกลงกับลีดเนื้อเรื่อง
เมื่อจำเป็น]
    D -->|รับ 0 แบบ = ทิ้งทั้งหมด| F[ขอใหม่หรือเขียนเอง]
    E --> G[สะท้อนในเนื้อหา L2
+ ออก L3 dialogue_id]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    classDef fail fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    class B code;
    class A ai;
    class C,D,E human;
    class G pass;
    class F fail;

กรณีที่นักเขียนเลือก 0 จาก N รายการ (ทิ้งทั้งหมด) ก็เป็นเรื่องปกติ ดังที่แบบที่ 3 ถูกปฏิเสธในบันทึกเซสชันข้างต้น การปฏิเสธไม่ใช่ความล้มเหลว แต่เป็นหลักฐานว่าด่านทำงาน ดังนั้นจึงวัดอัตราการทิ้งแยกตามนักเขียนและตามตัวละคร เพื่อใช้เป็นตัวชี้วัดคุณภาพของการป้อนบริบท

ถ้าอัตราการทิ้ง 0\~20% แสดงว่าบริบทเพียงพอ เป็นการเดินงานที่เสถียร ปล่อยไว้ตามเดิม 20\~50% เป็นช่วงการเดินงานทั่วไป แค่มอนิเตอร์ ถ้าขึ้นไป 50\~80% ให้กลับไปตรวจว่าการเลือกกฎ L1 ตกหล่นไปหรือไม่ ถ้าเกิน 80% ไม่ใช่ปัญหาของกฎรายข้อ แต่เป็นที่ระบบพรอมต์·เพอร์โซนาเองที่ผิดไป จึงต้องเขียน Layer A ใหม่ อัตราการทิ้งจะรวบรวมสัปดาห์ละครั้งแยกตามนักเขียนแล้วแชร์กันในการทบทวน (รายสัปดาห์)

อย่างไรก็ตาม อัตราการทิ้งไม่ใช่ตัวชี้วัดสัมบูรณ์ ตัวละครที่เปลี่ยนเร็ว (เช่น จุดเปลี่ยนที่เผยอารมณ์ครั้งแรกอย่าง K_007 ในบันทึกเซสชันข้างต้น) แม้อัตราการทิ้งสูงก็เป็นเรื่องปกติ ตัวเลขคือจุดเริ่มต้นของการสนทนา ไม่ใช่คำพิพากษา

5.3.8 ความปลอดภัย — จะกันการรั่วไหลของบริบทอย่างไร

L0\~L1 คือ IP หลักของเกม ถ้ารู้สึกเป็นภาระที่จะส่งให้ LLM API ภายนอกตามเดิม ทางเลือกก็จะแตกออกไป วิธีใช้ API ภายนอกตามเดิมด้วยสัญญาห้ามนำไปเทรนเร็วที่สุด แต่ต้องผ่านการตรวจสอบของฝ่ายกฎหมาย วิธีแทนชื่อบริษัท·ชื่อเฉพาะด้วย placeholder ก่อนส่ง มีค่าใช้จ่ายในการประมวลผลเพิ่ม และความเป็นธรรมชาติเสียหาย การโฮสต์เอง (โอเพนโมเดล) ข้อมูลปลอดภัยแต่ภาระด้านคุณภาพ·การเดินงานสูง ส่วนไฮบริดที่เก็บ L0 ไว้ภายในแล้วส่งแค่ร่างออกไปข้างนอกนั้นเดินงานซับซ้อน

โปรเจกต์ A ของผู้เขียนใช้วิธีแรก (API ภายนอก + สัญญาห้ามนำไปเทรน) เคยลองวิธีที่สองแล้วเลิก เพราะการแทนด้วย placeholder ทำให้เนื้อหากลายเป็นมาตรฐานเดียวกันในรูป "นักวิชาการ ○○ แห่งราชอาณาจักร ○○ พูดเรื่อง ○○" จนทำลายคุณภาพผลลัพธ์ การที่การทำให้ไม่ระบุตัวตน (anonymization) ฆ่าคุณภาพ เป็นการแลกได้แลกเสีย (trade-off) ที่ปรากฏซ้ำตลอดทั้งเล่ม (ดูบทการทำให้ไม่ระบุตัวตนใน ส่วนที่ 1) ในงานเนื้อเรื่องความเสียหายนั้นใหญ่เป็นพิเศษ เพราะชื่อเฉพาะคือโทนนั่นเอง

5.3.9 ความล้มเหลวที่พบบ่อยและวิธีแก้

ถ้าโยนแค่คำสั่งงานโดยไม่มีระบบพรอมต์ ก็จะได้ค่าเฉลี่ย ปูเพอร์โซนาและข้อห้ามก่อน ถ้าป้อน L0 ทั้งหมดทุกครั้งแต่ไม่ใช้แคชชิง ค่าใช้จ่ายจะรั่ว รวมบล็อกแคชไว้ข้างหน้า ถ้าใส่รูลบุ๊ก L1 ทั้งก้อน โมเดลจะพลาดประเด็นหลัก ดึงเฉพาะหัวข้อ _summary ถ้าใส่เนื้อหาใกล้เคียงแบบสรุปย่อ การเลือกของนักเขียนจะถูกลบ อ้างต้นฉบับตามเดิม ถ้าไม่กำหนดรูปแบบผลลัพธ์ คำตอบจำนวนมากจะขึ้นต้นด้วย "นี่คือ 3 ตัวเลือก:" แล้วก็ตามมาด้วยเหตุที่นักเขียนเข้าใจผิดว่าคำเกริ่นนั้นเป็นเนื้อหา ระบุจำนวน·ความยาว·ป้ายกำกับให้ชัด ถ้าใช้ผลลัพธ์ AI เป็นขั้นสุดท้าย ด่านตรวจสอบจะพังลง ให้ผ่านด่านนักเขียนเสมอ ถ้าไม่วัดอัตราการทิ้ง สุขภาพของเครื่องมือจะขึ้นกับความรู้สึกของคน รวบรวมเป็นรายสัปดาห์แล้วแชร์ในการทบทวน

5.3.10 จากการประยุกต์ใช้แบบอนุรักษ์นิยมสู่การประยุกต์ใช้แบบก้าวหน้า

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

ตรงนี้ขอชี้สิ่งหนึ่งก่อน การสร้างแบบโพรซีเดอรัล (procedural generation)·การจำลองโลก·เควสต์ไดนามิก คือวิสัยทัศน์ที่นักออกแบบเกมวาดไว้บนกระดาษมาตั้งแต่ 20\~30 ปีก่อน PCG ที่อิงรูลบุ๊กแบบกำหนด (deterministic) จัดการกับพื้นที่ตัวเลขอย่างห้องดันเจี้ยน·ออปชันอาวุธ·การกระจายการสปอว์นได้ แต่เอื้อมไม่ถึงเนื้อหาภาษาธรรมชาติ·เพอร์โซนาตัวละคร·ทางแยกเรื่องราว·บทสนทนา NPC ส่วนสำคัญของงานออกแบบจึงยังคงค้างอยู่บนกระดาษ ความก้าวหน้าของ LLM และโมเดลภาพในช่วงปี 2024\~2026 ได้ดึงพื้นที่นั้นมาสู่ตำแหน่งที่ทำให้เป็นจริงได้ ความหมายหลักของความก้าวหน้าของ AI ไม่ใช่คะแนนของโมเดล แต่อยู่ที่ความเป็นไปได้ในการทำให้งานออกแบบที่อยู่บนกระดาษมานานกลายเป็นจริง อย่างไรก็ตาม การที่ความเป็นไปได้เปิดขึ้น กับการที่มันลงตัวเป็นระบบที่เดินงานได้จริง เป็นคนละเรื่องกัน

การแยก Layer เป็นเงื่อนไขตั้งต้นของการสร้างแบบโพรซีเดอรัล

การแยก Layer 0\~4 ใน 5.1 ไม่ใช่แค่การจัดระเบียบ แต่เป็นเงื่อนไขตั้งต้นของการสร้างแบบโพรซีเดอรัล ห้าชั้นแต่ละชั้นสอดคล้องกับขั้นตอนใดของไปป์ไลน์การสร้าง (L0 anchor → L1 รูลบุ๊ก → L2 เนื้อหา → L3 ตัวเลข → L4 ด่าน) ได้กล่าวไว้ใน §6.6 และ 5.1.11 ประเด็นมีเพียงหนึ่ง — บนเอกสารก้อนเดียว ตัวสร้างจะกำหนดไม่ได้ว่าจะเริ่มอ่านจากไหนและเขียนลงที่ไหน ไม่รู้ว่า L0 อยู่ตรงไหนทำให้บริบทพร่ามัว และ L1·L2 ชนกันในไฟล์เดียวจนสายการผลิตจำนวนมากพังลง การแยก Layer ต้องมาก่อน แล้วการสร้างแบบโพรซีเดอรัลจึงทำงานได้บนนั้น ตรงนี้นำเงื่อนไขนั้นมาประยุกต์ใช้กับขั้นการผลิตจำนวนมากของการมี AI ช่วยงานเนื้อเรื่อง

โครงของการประยุกต์ใช้แบบก้าวหน้า — คลาวด์เควสต์

สามองค์ประกอบผูกเข้าด้วยกัน หนึ่ง NPC Persona ถูกสร้างแบบโพรซีเดอรัล NPC หลักเป็นฝีมือนักเขียน แต่ NPC ข้างเคียงผลิตจำนวนมากด้วยไปป์ไลน์ generator·Squad ใน 6.2\~6.3 แต่ละ Persona จะติดแท็ก (อาชีพ·ฝ่าย·แนวโน้ม·บทบาท) มาพร้อมกับ voice_profile สอง world BT อยู่เหนือ Squad ขึ้นไป ถ้า Squad ผูกพฤติกรรมของกลุ่ม NPC ในจุดล่าหนึ่ง world BT ก็อยู่เหนือนั้นโดยรับค่าสะสมของพฤติกรรมผู้เล่นมาอัปเดตสถานะของโลกทั้งใบ ผู้เล่นช่วยฝ่ายไหน ไปพื้นที่ไหนบ่อย ตัดสินใจอย่างไร จะเขย่าสถานะโหนดของ world BT และโหนดที่ถูกเขย่าก็สะท้อนไปยังตัวเลข (ชื่อเสียง·ความสนใจ·ลำดับความสำคัญ) ของ NPC ในเขตอิทธิพล สาม เควสต์เป็นโมเดลคลาวด์ เควสต์ทั้งหมดยกเว้นเควสต์หลักถูกสร้างแบบโพรซีเดอรัล แต่ละเควสต์ลอยอยู่พร้อมแท็ก (ใคร·ที่ไหน·ทำไม·เมื่อไร) และเงื่อนไขการปรากฏ ไม่มีเควสต์ใดถูกตรึงไว้กับ NPC ตัวใดตัวหนึ่ง

การปรากฏผ่าน 5 ขั้นตอน

flowchart TD
    P[1. สะสมพฤติกรรมผู้เล่น
สนับสนุนฝ่าย·เยือนพื้นที่·ตัดสินใจ] --> W[2. สถานะโหนด world BT เปลี่ยน
อัปเดตสถานะโลกเหนือ Squad]
    W --> N[3. ตัวเลข NPC เปลี่ยน
ชื่อเสียง·ความสนใจ·ลำดับความสำคัญ]
    N --> M[4. แท็ก NPC + ตัวเลข == เงื่อนไขปรากฏ
สร้างคีย์จับคู่]
    M --> Q[5. เควสต์ที่จับคู่ปรากฏ
จากคลาวด์เควสต์]
    Q -.->|ปรากฏหลังผ่านด่านนักเขียน| PL[ปรากฏต่อผู้เล่น]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class M code;
    class P,W,N,Q data;
    class PL pass;

ถ้าเปรียบเทียบให้เห็นภาพ เควสต์ไม่ได้วางเรียงอยู่บนชั้นหนังสือในห้องสมุด แต่เป็นเมฆที่ลอยอยู่กลางอากาศ เมื่อ NPC ไปถึงสถานะใดสถานะหนึ่ง เมฆที่เข้ากับตัวเองก็จะลอยลงมาให้คว้าได้ ในโครงสร้างนี้ AI ไม่ใช่ผู้ช่วยที่เขียนทีละบรรทัด แต่จัดการสามสิ่งพร้อมกัน เนื้อหาภาษาธรรมชาติของ Persona·เควสต์ที่สร้างแบบโพรซีเดอรัล (คำอธิบาย·บทพูด) การแปรผันของคำศัพท์เมื่อสถานะ world BT สะท้อนลงใน NPC (คง voice_profile เดิมไว้แต่หัวข้อสนทนาแปรไปตามสถานะโลก) และตัวจำแนกความสงสัยในขั้นตรวจสอบ (เควสต์นี้ปรากฏกับ NPC ตัวนี้ได้หรือไม่)

เส้นแบ่งย้อนกลับไม่ได้ — การตรวจสอบต้องจบที่ขั้นข้อความ

ในการประยุกต์ใช้แบบก้าวหน้า เส้นแบ่งย้อนกลับได้/ย้อนกลับไม่ได้ (5.4.5) ก็ยังคงมีชีวิตอยู่ตามเดิม ถ้าบทพูดของเควสต์ที่ปรากฏจากคลาวด์ไหลเข้าสู่ไปป์ไลน์เสียง (voice) โดยยังไม่ผ่านการตรวจสอบ จะย้อนคืนด้วยการ rollback โค้ดไม่ได้ ดังนั้นการวางด่านตรวจสอบทั้งหมด (voice_lint, ตัวจำแนกความสงสัย, ด่านนักเขียน) ไว้หน้าเส้นแบ่งย้อนกลับไม่ได้ จึงเป็นกลไกความปลอดภัยของการประยุกต์ใช้แบบก้าวหน้า ยิ่งเพิ่มการผลิตจำนวนมากแบบอัตโนมัติเข้ามา ด่านเหล่านี้ยิ่งต้องแข็งแกร่งกว่าการประยุกต์ใช้แบบอนุรักษ์นิยม

หยุดที่ไหน และทำไมจึงไม่หยุด

หนังสือเล่มนี้ไม่ได้กล่าวถึงรูปแบบสมบูรณ์ของการประยุกต์ใช้แบบก้าวหน้า เพราะเป็นเนื้อหาขนาดหนังสืออีกเล่มหนึ่ง และเงื่อนไขโครงสร้างพื้นฐานต่างกันไปตามแต่ละบริษัท·โปรเจกต์ จำแค่สองอย่างก็พอ ก่อนอื่น ทีมที่ทำการประยุกต์ใช้แบบอนุรักษ์นิยมไม่ได้ ก็ทำการประยุกต์ใช้แบบก้าวหน้าไม่ได้เช่นกัน ถ้าด่านตรวจสอบไม่เดินในการประยุกต์ใช้แบบอนุรักษ์นิยม ในการประยุกต์ใช้แบบก้าวหน้าคลาวด์ก็จะพุ่งกระจาย การเดินงานจะอยู่รอดได้ ต้องมีโครงสร้างพื้นฐานการสร้างแบบโพรซีเดอรัล เครื่องมือนิยาม·ทดสอบโหนด world BT การจำแนกความสงสัยอัตโนมัติ + ด่านนักเขียนของเควสต์ที่ปรากฏ การติดตามอัตราการปรากฏ·อัตราการทิ้ง·ความพึงพอใจของผู้เล่นพร้อมกัน และการเก็บคืน·เปลี่ยนเควสต์ที่ปรากฏผิดโดยอัตโนมัติ ครบพร้อมกัน ถ้าขาดไปหนึ่งใน 5 อย่าง จะถูกล้มเลิกภายในหนึ่งไตรมาส เพราะอุบัติเหตุด้านความสอดคล้องจะพุ่งจนการตรวจสอบโดยมนุษย์ตามไม่ทัน

ต่อมา การประยุกต์ใช้แบบก้าวหน้าไม่ใช่เครื่องมือเพิ่มการผลิตจำนวนมาก แต่เป็นเครื่องมือเพิ่มการตอบสนองแบบไดนามิก ถ้ามุ่งแต่การผลิตจำนวนมาก ค่าเฉลี่ยของ RPG ทั่วไปจะเต็มอยู่ในคลาวด์ แล้วผู้เล่นก็จะเจอโลกที่ "ดูหลากหลายขึ้นแต่ว่างเปล่ายิ่งกว่า" แต่ก็ไม่ได้แปลว่าเส้นทางนี้มีแต่ความเสี่ยง พื้นที่นี้คือแนวหน้าของงาน RnD ในการออกแบบเกม ตรงจุดที่การสร้างแบบโพรซีเดอรัล·การจำลอง·LLM มาบรรจบกัน เป็นจุดที่มีความเป็นไปได้สูงที่สุดที่รูปแบบเกมใหม่จริง ๆ จะถือกำเนิด แม้จะมีโอกาสน้อยที่จะนำมาใช้ในบริษัทในตอนนี้ แต่ก็คุ้มค่าที่จะมองไว้เป็นหนึ่งในทิศทางของ 5\~10 ปีข้างหน้า

5.3.11 ลองทำดูตามจนจบทั้งบท

นี่คือขั้นตอนในการทำซ้ำการประยุกต์ใช้แบบอนุรักษ์นิยมของบทนี้ตามเดิม

setup. ให้รวมไฟล์ L0 สามไฟล์ (world_premise.md·narrative_pillar.md·tone_manifesto.md) เข้าเป็นข้อความเดียวแล้วเก็บไว้ในตัวแปร L0_FULL เขียนระบบพรอมต์ตามห้าบรรทัดในบันทึกเซสชันข้างต้นตามเดิม แต่อย่าตัดบรรทัดสุดท้าย ("เขียนร่าง การตัดสินใจเป็นของนักเขียน") ออก รวบรวมบทพูดล่าสุด 10 บรรทัดของตัวละครที่จะร่างบทพูดเป็นข้อความต้นฉบับตามเดิม

prompt. ประกอบข้อความตามลำดับ [ระบบ] → [โทน L0] → [อ้างอิง: บทพูดก่อนหน้าต้นฉบับ] → [สถานการณ์] → [รูปแบบผลลัพธ์] ในรูปแบบผลลัพธ์ ให้ระบุ "จำนวน N แบบเป๊ะ ๆ / จำนวนตัวอักษรสูงสุดต่อแบบ / ป้ายกำกับ / ห้ามใส่อย่างอื่นใดทั้งสิ้น" ให้แน่ชัด ติด cache_control เฉพาะ L0 และ L1 แล้วไล่บล็อกที่เปลี่ยนไปไว้หลังข้อความ

verify. ตรวจสอบ N แบบที่ได้รับมาทีละบรรทัด ดูว่าโทนต่อเนื่องกับบทพูดก่อนหน้าหรือไม่ ป้ายกำกับตรงกับปฏิกิริยาจริงหรือไม่ มีรูปแบบที่ตัวละครเราไม่ใช้ (หลีกหนี·พูดติดขัด ฯลฯ) แทรกเข้ามาหรือไม่ แบบที่จะปฏิเสธให้ระบุเหตุผลแล้วขอใหม่ การรับ 0 แบบก็เป็นเรื่องปกติ และให้บันทึกเป็นอัตราการทิ้ง เฉพาะแบบที่ผ่านให้ผ่าน voice_lint แล้วสะท้อนใน L2 และออก dialogue_id ที่ L3

ฉบับย่อสำหรับคนเดียว. แม้ไม่มี API·แคชชิง·voice_lint หัวใจก็ยังเหมือนเดิม มีช่องแชต ChatGPT/Claude หนึ่งช่องก็พอ ทุกครั้งให้คัดลอกวางบทพูดล่าสุด 5\~10 บรรทัดของตัวละครไว้ข้างหน้าสุด ต่อท้ายรูปแบบผลลัพธ์ 3 บรรทัดเสมอ และในคำตอบที่ได้รับ แบบที่จะปฏิเสธให้เขียนเหตุผลแล้วขอใหม่ แทนที่จะใช้แคชชิง ให้คงเธรดสนทนาเดียวกันไว้ บริบทก่อนหน้าก็จะคงอยู่ตามเดิม อัตราการทิ้งนั้น นับด้วยมือเขียนลงในกระดาษหนึ่งแผ่นว่า "สัปดาห์นี้รับ 12 / ทั้งหมด 30" ก็เพียงพอ ต่อให้เครื่องมือเล็ก โครงของการป้อน 4 ชั้นและด่านตรวจสอบก็ทำงานกับนักเขียนคนเดียวได้เหมือนกัน

สรุปประเด็นสำคัญของบท

• ในบริบท 4 ชั้น (ระบบ·L0·L1·เนื้อหาใกล้เคียง) แค่ขาดไปชั้นเดียว ผลลัพธ์ก็ลู่เข้าหาค่าเฉลี่ย
• แคชชิงมีชีวิตอยู่บนการแยก คือไล่ L0·L1 ที่ไม่เปลี่ยนไว้ข้างหน้า แล้วเลื่อนเนื้อหาที่เปลี่ยนไว้ข้างหลัง
• ด่านตรวจสอบและอัตราการทิ้งต้องทำงาน การประยุกต์ใช้แบบก้าวหน้า (คลาวด์เควสต์) จึงจะไม่พุ่งกระจาย

ตัวอย่างบทถัดไป

• 5.4 ความสอดคล้องของบทสนทนา·เสียง (voice) — สกัด·อัปเดต voice_profile ด้วย AI และตรวจสอบเสียง

5.4 ความสอดคล้องของบทพูดและเสียงตัวละคร

ห้องอัดเสียง ผู้กำกับสวมหูฟังและยกมือขึ้นเพื่อให้คิว นักพากย์อ่านบทของ NPC ที่เป็นนักวิชาการ "ว้าว นี่มันสุดยอดไปเลยครับ" มือของผู้กำกับหยุดนิ่ง ตัวละครคนนี้ตลอด 5 บทไม่เคยใช้คำอุทานว่า "ว้าว" แม้แต่ครั้งเดียว เขาเป็นนักวิชาการที่ไม่เอ่ยคำหยาบหรือคำอุทานสมัยใหม่ออกจากปาก และพูดทิ้งท้ายประโยคแบบค่อย ๆ จางหายไปจนจบ แต่ในบทกลับมีบรรทัดนั้นปรากฏอยู่ตรง ๆ

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

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

5.4.1 จุดที่เสียงตัวละครเริ่มแกว่ง

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

เมื่อเปลี่ยนนักเขียน NPC ตัวเดิมก็กลายเป็นคนอื่นไป ต่อให้ไม่เปลี่ยนนักเขียน พอผ่านไป 6 เดือน นักเขียนคนเดิมก็ลืมโทนของตัวเอง เวลาเขียนบทพูดใหม่โดยไม่เปิดดูบทพูดเก่าของตัวละครนั้น บริบทก็ขาดตอน หากกฎเสียงตัวละครอยู่แต่ในหัวของนักเขียนและไม่มีเป็นเอกสาร ก็ส่งต่อให้คนถัดไปไม่ได้ และสาเหตุที่ห้าที่เพิ่มขึ้นเร็วที่สุดในช่วงสองปีมานี้ — เมื่อโยนคำสั่งใส่ LLM ว่า "ช่วยสร้างบทพูดของ NPC ตัวนี้ให้หน่อย" โดยไม่ให้ข้อมูลตัวละคร AI จะคืนบทพูดที่เฉลี่ย ๆ กลาง ๆ จึงไม่ใช่เสียงของใครเลย

สาเหตุที่ห้านี้คือผลข้างเคียงของการนำ AI เข้ามาใช้ การฉีดบริบท (context injection) ในบทก่อนหน้า (5.3) คือใบสั่งยา แต่ถ้าตัวบริบทที่จะฉีดเองนั้นบกพร่อง ก็ไม่มีอะไรจะฉีด บริบทนั้นก็คือ voice_profile นี่เอง บทนี้จะดูหนึ่งรอบของการสร้างไฟล์นั้น ตรวจสอบโดยอัตโนมัติ และปิดจบที่หน้าห้องอัด

5.4.2 voice_profile — เสียงที่ตรึงไว้ด้วยห้าหัวข้อ

ในโปรเจกต์ A ทุก NPC จะมี voice_profile ประกอบด้วยห้าหัวข้อ ได้แก่ ขอบเขตคำศัพท์ (กลุ่มคำที่ใช้บ่อย / กลุ่มคำที่ไม่ใช้เด็ดขาด), ความยาวประโยค (จำนวนตัวอักษรเฉลี่ย·สูงสุด), ระบบคำสุภาพ (สรรพนามบุรุษที่ 1·2, สัดส่วนการใช้ jondaetmal (ระบบคำยกย่องในภาษาเกาหลี), คำเรียกขาน), การแสดงอารมณ์ (ใช้วิธีตรง·อ้อม·หรือเก็บกด), และสำนวนต้องห้าม (คำหรือวลีที่ไม่ใช้เด็ดขาด) ทั้งห้าหัวข้อต้องมีตัวอย่างที่เป็นรูปธรรมกำกับ หากมีแต่คำพรรณนาเชิงนามธรรมอย่าง "นักวิชาการที่เคร่งขรึม" แต่ละคนก็จะอ่านต่างกันออกไป นักเขียนคนถัดไปจะจินตนาการนักวิชาการคนนั้นในแบบของตัวเอง

รูปแบบโปรไฟล์จริงของ NPC นักวิชาการ K_007 เป็นดังนี้ ไฟล์นี้จะกลายเป็นอินพุตของ voice_lint ทันที

---
title: K_007 นักวิชาการ voice_profile
layer: L1
character_id: K_007
atoms:
  - voice_profile_k_007
related:
  derives_from: [character_bible/k_007.md]
  affects: [dialogue_id_table (บทพูดทั้งหมดของ K_007)]
---

## 1. ขอบเขตคำศัพท์
- ใช้บ่อย: "บันทึก", "หลักฐาน", "สถานการณ์", "การประมาณ", "ข้อมูล", "กรณีตัวอย่าง"
- ไม่ใช้เด็ดขาด: "ความรู้สึก", "ลางสังหรณ์", "โชคชะตา", "พระประสงค์ของพระเจ้า", "เสียงในใจ"

## 2. ความยาวประโยค
- เฉลี่ย: 18 ตัวอักษร
- สูงสุด: 35 ตัวอักษร (เกินกว่านั้นแยกเป็นสองประโยค)
- ตัดจบสั้น ๆ บ่อย: "...ไม่ใช่ครับ" "เริ่มจากบันทึกก่อน"

## 3. ระบบคำสุภาพ
- บุรุษที่ 1: "ผม/ดิฉัน"
- บุรุษที่ 2: เรียกตามตำแหน่งก่อน (ท่านหัวหน้า, ท่านผู้บัญชาการ) เรียกชื่อต่อเมื่อสนิทกันแล้วเท่านั้น
- ใช้คำสุภาพ 100% (ยกเว้นฉากย้อนอดีต)
- แทบไม่มีคำอุทาน เมื่อมีจะเป็น "...อ่ะ"

## 4. การแสดงอารมณ์
- แทบไม่แสดงออกตรง ๆ (ความโกรธ·ความยินดี)
- แสดงผ่านความเงียบ·การพูดทิ้งท้ายให้จางหาย ("...ถ้าเป็นแบบนั้นล่ะก็")
- ความเศร้า: เลี่ยงด้วยการเปลี่ยนเรื่อง ("...คุยเรื่องอื่นกันเถอะ")

## 5. สำนวนต้องห้าม
- คำหยาบทุกชนิด
- คำอุทานสมัยใหม่ "ว้าว", "เฮ้ย", "สุดยอด"
- คำศัพท์รากจีน 3 พยางค์ขึ้นไป สองคำขึ้นไปในประโยคเดียว
- คำศัพท์เชิงไสยศาสตร์ เช่น "โชคชะตา", "คำพยากรณ์"

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

เมื่อมองห้าหัวข้อนี้ด้วยสายตาของการแปลและการแปลภาษาท้องถิ่น (localization) จะแยกได้เป็นสองกลุ่ม คุณสมบัติที่ ขึ้นกับภาษา (รูปลักษณ์ผิวเผินของขอบเขตคำศัพท์·ความยาวประโยค·ระบบคำสุภาพ) ต้องกำหนดใหม่ในแต่ละภาษาที่แปล ส่วนคุณสมบัติที่ ไม่ขึ้นกับภาษา (ท่าทีอย่างเช่น จะเก็บกดอารมณ์หรือแสดงออกตรง ๆ จะไม่พูดอะไรจนถึงที่สุด) ต้องคงไว้เช่นเดิมไม่ว่าจะแปลเป็นภาษาใด หากส่งต่อการแยกแยะนี้ไปพร้อมกับงานแปลภาษาท้องถิ่น ก็จะป้องกันไม่ให้ผู้แปลเปลี่ยนแค่คำศัพท์ผิวเผินแล้วเผลอทำให้ท่าทีของตัวละครแกว่งไปด้วย

5.4.3 บันทึกเซสชันจริง (worked transcript): สกัด profile ขึ้นมาจากเนื้อเรื่อง

หากเขียน NPC 50 ตัว × 5 หัวข้อ = 250 รายการ จากกระดาษเปล่าตั้งแต่ต้น มันจะไหลไปสู่ความเป็นนามธรรม หากเขียนว่า "ตัวละครนี้เป็นนักวิชาการเลือดเย็น" โดยไม่มีบทในเนื้อเรื่องแม้แต่บรรทัดเดียว ก็ไม่มีใครรู้ว่าความเลือดเย็นนั้นคืออะไร ดังนั้นจึงสลับลำดับ เขียน NPC หลักเพียง 5\~7 ตัวให้เต็มตั้งแต่ต้น ส่วนที่เหลือจะสกัด profile ย้อนกลับจากบทพูดหลังจากที่บทพูดในเนื้อเรื่องสะสมได้ 20\~30 บรรทัดแล้ว

ด้านล่างคือบันทึกเซสชันจริงของการดึงร่าง profile ออกมาหลังจากบทพูดของ K_007 สะสมได้ 25 บรรทัด เราจะไม่สรุปย่อ และทิ้งจุดที่ AI ผิดไว้ตามเดิม

[พรอมต์เต็มที่นักเขียนโยนเข้าไป]

ต่อไปนี้คือบทพูดของตัวละคร K_007 จำนวน 25 บรรทัด

1. "เริ่มจากดูบันทึกกันก่อน"
2. "...สถานการณ์มันไม่สอดคล้องกัน"
3. "เป็นเพียงการประมาณเท่านั้น ไม่มีหลักฐาน"
4. "กรณีตัวอย่างนั้นผมก็ทราบอยู่"
5. "...ไม่ใช่ครับ ข้อมูลมันต่างกัน"
   (... อ้างอิงข้อ 6~23 เต็มโดยไม่ตัดทอน ...)
24. "...ถ้าเป็นแบบนั้นล่ะก็ ผมขอถอนตัว"
25. "คุยเรื่องอื่นกันเถอะ"

จากนี้ ช่วยดึงออกมาห้าอย่าง ได้แก่ คำศัพท์ที่ใช้บ่อย (เฉพาะที่ปรากฏจริง),
ความยาวประโยคเฉลี่ย, รูปแบบคำสุภาพ·คำเรียกขาน, วิธีแสดงอารมณ์,
และขอบเขตของสำนวนที่ไม่เคยใช้เลย
แต่ละหัวข้อให้อ้างอิงบทพูดที่เป็นหลักฐาน 2~3 บรรทัดด้วยหมายเลข และอย่าใช้
ความประทับใจเชิงอัตวิสัยอย่างคำว่า "เคร่งขรึม" หรือ "เลือดเย็น"

[ผลลัพธ์ดิบของ Claude — ไม่ได้ขัดเกลา]

1. คำศัพท์ที่ใช้บ่อย
   - "บันทึก" (ข้อ 1), "สถานการณ์" (ข้อ 2), "การประมาณ/หลักฐาน" (ข้อ 3),
     "กรณีตัวอย่าง" (ข้อ 4), "ข้อมูล" (ข้อ 5)
   → เน้นคำนามกลุ่มข้อเท็จจริง·หลักฐาน

2. ความยาวประโยคเฉลี่ย
   - เฉลี่ย 25 บรรทัด ราว 14.6 ตัวอักษร ยาวสุด 21 ตัวอักษร (ข้อ 24)
   → เน้นประโยคสั้นเดี่ยว

3. คำสุภาพ·คำเรียกขาน
   - บุรุษที่ 1 "ผม" (ข้อ 3·24) คำลงท้ายเป็นรูปสุภาพ "-ครับ/-ค่ะ"
   - คำเรียกขานบุรุษที่ 2 ไม่ปรากฏใน 25 บรรทัดนี้
     → ตัดสินรูปแบบคำเรียกขานจากตัวอย่างชุดนี้เพียงอย่างเดียวไม่ได้ (ต้องให้นักเขียนยืนยัน)

4. การแสดงอารมณ์
   - ไม่มีคำแสดงอารมณ์ตรง ๆ จัดการการปฏิเสธด้วย "ขอถอนตัว" (ข้อ 24)
     และความเศร้า/การหลีกเลี่ยงด้วยการเปลี่ยนเรื่อง "คุยเรื่องอื่นกันเถอะ" (ข้อ 25)
   → แบบเก็บกด·อ้อม

5. ขอบเขตที่ไม่เคยใช้เลย
   - คำอุทาน, คำหยาบ, คำศัพท์เชิงไสยศาสตร์ ล้วนไม่ปรากฏ
   ※ แต่ "ไม่ปรากฏ" ไม่ได้รับประกันว่าเป็น "ข้อห้าม"
      เนื่องจากตัวอย่างมีเพียง 25 บรรทัดซึ่งน้อย จึงอาจเป็นการไม่ปรากฏโดยบังเอิญ

ตรงนี้มีสองจุดที่ต้องชี้ให้เห็น อย่างแรก AI หยุดที่หัวข้อ 3 มันขีดเส้นจำกัดให้ตัวเองว่า "ตัดสินจากตัวอย่างชุดนี้เพียงอย่างเดียวไม่ได้" เนื่องจากคำเรียกขานไม่ปรากฏใน 25 บรรทัด มันจึงไม่คาดเดา — นี่คือผลลัพธ์ที่ซื่อตรง หาก AI เติมว่า "บุรุษที่ 2 ประมาณว่า 'ท่านหัวหน้า'" นั่นคืออาการหลอน (hallucination) และเมื่อเข้าไปอยู่ใน profile ก็คือการปนเปื้อน อย่างที่สอง ในหัวข้อ 5 AI แนบข้อจำกัดความรับผิดให้ตัวเอง "ไม่ปรากฏ ≠ ข้อห้าม" คือคำเตือนสำคัญ การที่คำอุทานไม่ปรากฏใน 25 บรรทัดอาจเป็นเรื่องบังเอิญก็ได้

[การตรวจสอบและปฏิเสธของนักเขียน]

นักเขียนรับหัวข้อ 1·2·4 ส่วนหัวข้อ 3 คำเรียกขานนั้น นักเขียนเปิด character_bible แล้วเติม "เรียกตามตำแหน่งก่อน เรียกชื่อหลังสนิท" ด้วยมือ — คนเติมเต็มตำแหน่งที่ AI เว้นว่างไว้ ส่วนหัวข้อ 5 นักเขียนไม่เลื่อนสถานะ "ไม่ปรากฏ" ขึ้นเป็น "ข้อห้าม" ทันทีตามคำเตือนของ AI แต่นักเขียนเทียบกับการตั้งค่าตัวละครแล้วยืนยันเป็นข้อห้ามเฉพาะ "คำอุทานสมัยใหม่·คำหยาบ·ไสยศาสตร์" เท่านั้น ส่วนคำศัพท์ที่ไม่ปรากฏที่เหลือก็พักไว้ก่อน

[การขอใหม่ของนักเขียน]

"โชคชะตา", "คำพยากรณ์" ผมจะยืนยันเป็นข้อห้าม ช่วยดึงคำศัพท์เชิงไสยศาสตร์
ที่ความหมายซ้อนทับกันมาเพิ่มอีก 10 คำ
แต่เนื่องจาก K_007 ในฐานะนักวิชาการอาจยกมาอ้างในบริบทของการหักล้าง·วิพากษ์ได้
ช่วยแสดงกรณียกเว้นเหล่านั้นกำกับมาด้วยบรรทัดเดียว

การขอใหม่ครั้งสุดท้ายนี้สำคัญ หากขยายข้อห้ามอย่างกลไก บทพูดที่ชอบธรรมอย่าง "นักวิชาการวิพากษ์ไสยศาสตร์ว่า 'โชคชะตาอะไรกัน'" ก็จะถูกบล็อกไปด้วย ดังนั้นจึงนิยามบริบทยกเว้นกำกับไว้กับข้อห้าม AI ขยายตัวเลือกให้กว้าง ส่วนนักเขียนขีดเส้นขอบเขต หลังจากหมุนครบหนึ่งรอบนี้แล้ว voice_profile_k_007 จึงจะถูกยืนยันและตรึงไว้ที่ L1

เมื่อบังคับให้อ้างอิงหลักฐาน ("อ้างด้วยหมายเลข") และห้ามใช้คำคุณศัพท์เชิงอัตวิสัย ("ห้ามใช้ 'เคร่งขรึม'") อาการหลอนของ AI ก็ลดลง และนักเขียนก็มีพื้นผิวให้ตรวจสอบ profile ไม่ใช่สิ่งที่ AI เขียน แต่เป็นสิ่งที่ AI วางร่างไว้แล้วนักเขียนตรึงให้คงที่

5.4.4 voice_lint — เทียบกับทุกบทพูดใหม่โดยอัตโนมัติ

เมื่อ voice_profile มีเป็นไฟล์แล้ว ทุกครั้งที่มีบทพูดใหม่ขึ้นมาก็เทียบอัตโนมัติได้ ในบรรดาการตรวจห้าอย่าง สิ่งที่ได้ผลมากในงานจริงคือสองอย่าง ได้แก่ การจับคู่คำศัพท์ต้องห้าม (คำศัพท์ติดอยู่ในรายการต้องห้ามหรือไม่) และการละเมิดขอบเขตคำศัพท์ (เข้าไปอยู่ในกลุ่มคำที่ไม่ใช้เด็ดขาดหรือไม่) ส่วนการหลุดจากความยาวประโยค·การขาดคำสุภาพ·สัดส่วนคำที่ใช้บ่อยนั้นมีผลบวกลวง (false positive) มาก จึงใช้เป็นตัวเสริมเท่านั้น หากจับไปถึงขั้นที่ฉากย้อนอดีตบรรทัดเดียวทำให้ความยาวเฉลี่ยแกว่ง นักเขียนก็จะชินชาต่อคำเตือน

voice_lint รับชุดบทพูดใหม่ของบทแล้วออกรายงานแบบนี้

ผล voice_lint (ch04 บทพูดใหม่ 32 บรรทัด, profile=voice_profile_k_007)
─────────────────────────────────────────────
[ละเมิด] dialogue_id_412 — K_007
  เนื้อหา: "ว้าว นี่มันสุดยอดไปเลย!"
  เหตุผล: คำศัพท์ต้องห้าม "ว้าว", "สุดยอด" (profile §5)
  → ต้องให้นักเขียนตรวจสอบ

[น่าสงสัย] dialogue_id_421 — K_007
  เนื้อหา: "โชคชะตานั้นยอมรับได้ยาก"
  เหตุผล: ขอบเขตคำศัพท์ต้องห้าม "โชคชะตา" (profile §5)
        แต่อาจเข้าข่ายยกเว้น 'บริบทหักล้าง·วิพากษ์' — ให้นักเขียนตัดสิน
  → ต้องให้นักเขียนตรวจสอบ

[ปกติ] บทพูด 30 รายการ
─────────────────────────────────────────────
สรุป: ละเมิด 1 / น่าสงสัย 1 / ปกติ 30

ละเมิดคือสีแดง น่าสงสัยคือสีเหลือง ทั้งคู่ต้องผ่านการตัดสินของนักเขียนจึงจะผ่านไปได้ ตรงนี้มีหลักการเด็ดขาดข้อหนึ่ง — voice_lint จะไม่ปฏิเสธโดยอัตโนมัติ (เป็นการต่อยอดจากหลักการ 5.2) ลองดู dialogue_id_421 ข้างบน "โชคชะตา" เป็นข้อห้าม แต่หากเป็นบริบทที่นักวิชาการกำลังโต้แย้งไสยศาสตร์ ก็อาจเป็นการอ้างอิงที่ชอบธรรมได้ การตัดสินนั้นเครื่องมือทำไม่ได้ lint แบบปฏิเสธอัตโนมัติจะปิดกั้นจุดละเอียดอ่อนนี้ทั้งหมด และพรากโอกาสที่นักเขียนจะได้ขัดเกลาโทนไปด้วย lint คือไฟฉายที่ส่องจุดน่าสงสัย ไม่ใช่กุญแจที่ล็อกประตู

5.4.5 ด่านตรวจสอบ — เส้นประระหว่างย้อนกลับได้กับย้อนกลับไม่ได้

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

flowchart TD
    A["นักเขียนเขียนเนื้อเรื่อง (L2)"] --> B["voice_lint อัตโนมัติ
รายงานละเมิด·น่าสงสัย"]
    B --> C["นักเขียนตรวจสอบตัวเอง (15 นาที)"]
    C --> D["ลีดเนื้อเรื่องตรวจสอบตัวอย่าง
สุ่ม 10% ต่อบท"]
    D --> E["ออก L3 dialogue_id
+ จับคู่ translation key"]
    E --> F["ตรวจสอบการแปล·แปลภาษาท้องถิ่น"]

    F -.->|"━━━ เส้นแบ่งย้อนกลับได้ / ย้อนกลับไม่ได้ ━━━
เหนือเส้นนี้เป็นข้อความ แก้ได้ไม่จำกัด
ใต้เส้นนี้เป็นไฟล์เสียง แก้ไม่ได้"| G

    G["คัดเลือกนักพากย์ (VA)"] --> H["บันทึกเสียงพากย์ (ขั้นสุดท้าย·ย้อนกลับไม่ได้)"]
    H --> I["นำไฟล์เสียงเข้าบิลด์"]

    classDef reversible fill:#e8f4ea,stroke:#3a7d44,stroke-width:1px,color:#1b3a22;
    classDef irreversible fill:#f7e3e3,stroke:#b23b3b,stroke-width:2px,color:#5a1414;
    class A,B,C,D,E,F reversible;
    class G,H,I irreversible;

สีเขียวคือขั้นย้อนกลับได้ สีแดงคือขั้นย้อนกลับไม่ได้ เหนือเส้นประ (สีเขียว) ทั้งหมดเป็นข้อความ หากไม่พอใจบทพูดบรรทัดหนึ่งก็แก้ด้วยคีย์บอร์ดได้ ต้นทุนคือเวลาไม่กี่นาทีของนักเขียน ใต้เส้นประ (สีแดง) เป็นไฟล์เสียง ในวินาทีที่นักพากย์อ่านบรรทัดนั้นในห้องอัดและไฟล์เสียงเข้าไปอยู่ในบิลด์ บทพูดนั้นก็ถูกตรึงเป็นแอสเซต หากจะแก้ก็ต้องจองนักพากย์คนเดิม สภาพเสียงแบบเดิม สตูดิโอเดิมขึ้นมาใหม่ และค่าตัว·สตูดิโอ·เวลาของผู้กำกับก็เสียซ้ำเท่ากับครั้งแรกอีกรอบ หากตารางงานคับแคบ บางทีก็จองเซสชันเพิ่มของนักพากย์คนเดิมไม่ได้เลย

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

กลางแผนภาพ การตรวจสอบตัวอย่างของลีดถูกกำหนดไว้ที่ "สุ่ม 10% ต่อบท" สัดส่วนนี้คือจุดสมดุลระหว่างเวลาตรวจสอบกับความแม่นยำ (ค่าที่ผู้เขียนใช้บริหารงานจริง, ยังไม่ได้ตรวจสอบ) หากลดต่ำกว่า 5% อุบัติเหตุจะรั่ว หากดันเกิน 20% ลีดคนเดียวก็จะกลายเป็นคอขวด เนื่องจาก lint กรองละเมิด·น่าสงสัยไว้ล่วงหน้า ตัวอย่างจึงสุ่มจากส่วนที่ผ่าน lint — สายตาของคนจะมุ่งไปที่ความผิดพลาดเชิงบริบทที่เครื่องมือจับไม่ได้ (เช่น การอ้างอิง "โชคชะตา" ที่ดูชอบธรรมแต่จริง ๆ คือการพังทลายของตัวละคร)

5.4.6 ตัวละครย่อมเปลี่ยนแปลง — การจัดการเวอร์ชันของ profile

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

---
character_id: K_007
voice_profile_versions:
  - v1: ch01~ch05 (ระยะแรก — เก็บกดอารมณ์, นักวิชาการประโยคสั้น)
  - v2: ch06~ch10 (หลังเพื่อนร่วมทางตาย — ความถี่การแสดงอารมณ์เพิ่มขึ้น)
  - v3: ch11~ (หลังตื่นรู้ — เริ่มมีการพูดตรง ๆ)
---

แต่ละเวอร์ชันมีไฟล์ profile แยกกัน และ voice_lint จะดูหมายเลขบทของบทพูดที่ตรวจสอบเพื่อเลือกว่าจะใช้เวอร์ชันไหน หากเอากฎ "เก็บกดอารมณ์" ของ v1 ไปจับบทพูดของ ch07 บทพูดที่เปลี่ยนแปลงไปอย่างปกติก็จะขึ้นเป็น "น่าสงสัย" กันหมด ความเปลี่ยนแปลงไม่ใช่บั๊ก แต่เป็นการออกแบบ

สัญญาณของการเลื่อนเวอร์ชันมีสามอย่าง เมื่อนักเขียนตั้งใจทำให้โทนแกว่ง ก็เสนอเวอร์ชันใหม่และตกลงกับลีด เมื่อจำนวน "น่าสงสัย" ของ voice_lint ในตัวละครหนึ่งเพิ่มขึ้นเรื่อย ๆ นั่นคือสัญญาณว่านักเขียนกำลังเลื่อนโทนไปโดยไม่รู้ตัว — ถึงเวลาอัปเดตเวอร์ชันแล้ว เมื่อมีเหตุการณ์เปลี่ยนแปลง (ความตาย·การตื่นรู้·การทรยศ) เพิ่มเข้าไปใน character_bible ก็จะมี alert เตือนให้อัปเดต profile ขึ้นมา อย่างไรก็ตาม หากตัวละครหนึ่งเปลี่ยนทุกบท ความสอดคล้องก็จะพังทลาย ดังนั้นจำนวนเวอร์ชันที่สมจริงคือ 2\~4 เวอร์ชันต่อตัวละคร

[ป้ายบอกทาง — หากมองระหว่างตัวละครผ่านปริภูมิเสียง (ยังเร็วเกินไปในตอนนี้)] หาก voice_lint รักษาความสอดคล้อง 'ภายในตัวละครหนึ่ง' ด้วยกฎ 'ปริภูมิเสียง' (voice space) ที่ฝัง (embed) ชุดบทพูดจริงของแต่ละตัวละคร (บทพูดทั้งหมดที่ตัวละครหนึ่งพูด) เป็นจุดหนึ่งจุด จะมองว่า 'ระหว่างตัวละคร' แยกห่างกันมากพอหรือไม่ — หากจุดต่าง ๆ ค่อย ๆ เกาะกลุ่มเข้าหากัน นั่นก็จะกลายเป็นค่าวัดโดยตรงของการปรับเสียงให้เป็นมาตรฐาน·การลู่เข้าหากันที่ §5.3.1·§5.4.1 ชี้ไว้ แต่อย่าตรึงเกณฑ์ระยะทางเป็นตัวเลขสัมบูรณ์ ให้อ่านเป็นเพียงป้ายบอกทางว่า 'กำลังเกาะกลุ่ม' และไม่ใช่ด่านตัดสินที่มาแทน voice_lint (แนวคิดนี้อยู่ตำแหน่งเดียวกับการบีบอัดเวกเตอร์เชิงมิติใน §8.2.7 และสัญชาตญาณเชิงแนวคิดได้คลี่ไว้เป็นแผนที่หนึ่งภาพในภาคผนวก M — ไม่ใช่ใบสั่งยา แต่เป็นป้ายบอกทาง)

5.4.7 หน่วยความสอดคล้องที่เพิ่มขึ้นตามภาษาและนักพากย์ (VA)

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

จุดที่รั่วบ่อยที่สุดในความสอดคล้องของการแปลคือ สำนวนเดียวกันถูกแปลต่างกันในแต่ละบท (จับด้วยการตรวจความสอดคล้องของหน่วยความจำการแปล หรือ translation memory) ตามมาด้วยการที่ voice_profile ของตัวละครไม่ถูกสะท้อนในการแปล (แนบไกด์การแปลแยกของแต่ละตัวละครต่างหาก) และคำศัพท์ใหม่ที่ยังไม่ลงทะเบียนในอภิธานศัพท์ (lint อภิธานศัพท์) ไกด์การแปลสร้างขึ้นโดยอัตโนมัติจาก voice_profile — นำ "ตัวละครนี้ใช้คำสุภาพ 100%, ไม่มีคำอุทาน, ห้ามใช้คำศัพท์เชิงไสยศาสตร์" ไปแปะหัวคำสั่งการแปลโดยอัตโนมัติ เมื่อผู้แปลย้ายนักวิชาการคนนั้นเป็นภาษาอังกฤษ ก็จะมองเห็นขอบเขตเดียวกัน

การตรวจสอบ VA (Voice Actor, นักพากย์) คือการตรวจสอบในขั้นข้อความที่ย้อนกลับได้ขั้นสุดท้าย ก่อนจะแตะถึงใต้เส้นประ ความสอดคล้องของโทน (ระดับความเข้มของการแสดงความโกรธ·ความเศร้า) ผู้กำกับและฝ่ายเนื้อเรื่องเป็นคนดู ความถูกต้องของการออกเสียง (คำเฉพาะ) ผู้รับผิดชอบอภิธานศัพท์เป็นคนดู ส่วนจังหวะหายใจ·การตัดจบ (คำสั่งอย่าง "ตัดจบสั้น ๆ บ่อย" ใน profile) ผู้กำกับเป็นคนดู ผลการตรวจสอบบันทึกเป็นผ่าน·ตีกลับใน voice_review_log.md (L4) และอ้างอิงตอนคัดเลือกนักพากย์ตัวละครถัดไป

การตีกลับให้จบก่อนการคัดเลือก·บันทึกเสียงให้ได้มากที่สุด ข้อผิดพลาดของบทที่ถูกพบในห้องอัดจะทำให้เซสชันของวันนั้นพังทั้งหมดและกระทบไปถึงตารางเซสชันถัดไป แต่การเลื่อนบันทึกเสียงออกไปแล้วปิดการตรวจสอบก็ไม่ใช่คำตอบ หากการตรวจสอบติดขัดบ่อยตรงหน้าห้องอัด นั่นคือเวิร์กโฟลว์ขั้นบน (นักเขียน·ลีด) ที่ล่าช้า ไม่ใช่ปัญหาของตารางบันทึกเสียง

5.4.8 การวัดผล 6 เดือนกับต้นทุน

ในโปรเจกต์ A เราติดตามก่อนและหลังการนำ voice_profile + voice_lint มาใช้เป็นเวลา 6 เดือน ตัวเลขจำนวนสัมบูรณ์เป็นการประมาณของผู้เขียน (ยังไม่ได้ตรวจสอบ) ให้เชื่อถือเฉพาะทิศทาง·สัดส่วนก็พอ

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

เมื่อดูโครงสร้างต้นทุน ต้นทุนการดำเนินงานเล็กกว่าต้นทุนการนำมาใช้มาก การเขียน voice_profile ใช้นักเขียน 2 สัปดาห์สำหรับตัวหลัก 7 ตัว เครื่องมือ voice_lint ใช้พัฒนา 1\~2 สัปดาห์และบำรุงรักษาเดือนละ 1 วัน ฝั่งดำเนินงาน ต่อบทใช้นักเขียนตรวจสอบตัวเอง 15 นาที ลีดตรวจสอบตัวอย่างราว 2 ชั่วโมง (สุ่ม 10%) ส่วนการอัปเดต profile ของบทที่มีการเปลี่ยนแปลงใช้ 1\~2 วันต่อตัวละคร ต้นทุนดำเนินงานต้องเล็กระบบจึงจะอยู่รอด เครื่องมือที่ดำเนินงานหนักจะถูกทิ้งอย่างเงียบ ๆ ภายในหนึ่งไตรมาส

5.4.9 ความล้มเหลวที่พบบ่อย

ลองทำดู — voice_lint หนึ่งรอบ

ขั้นตอนขั้นต่ำสำหรับหมุนหนึ่งรอบด้วย profile หนึ่งไฟล์ เมื่อมีบทพูดของบทใหม่ขึ้นมา

setup 1. เปิด voice_profile_<id>.md ของตัวละครเป้าหมาย หากไม่มี ให้รวบรวมบทพูดในเนื้อเรื่อง 20\~30 บรรทัด 2. เตรียมบทพูดใหม่เป็นชุดข้อความธรรมดาในรูปแบบ id / ตัวละคร / เนื้อหา

prompt

นี่คือ voice_profile §5 (สำนวนต้องห้าม) ของ K_007
[แปะรายการต้องห้าม]

ch04 บทพูดใหม่ 32 บรรทัด
[แปะในรูปแบบ id / เนื้อหา]

ช่วยจัดประเภทแต่ละบทพูดเป็น [ละเมิด] (มีคำศัพท์ต้องห้ามตรง ๆ) / [น่าสงสัย]
(แตะขอบเขตต้องห้ามแต่อาจเข้าข่ายบริบทยกเว้น) / [ปกติ]
[ละเมิด]·[น่าสงสัย] ให้แสดง id·เนื้อหา·เหตุผลเป็นตาราง การตัดสินผมเป็นคนทำเอง
ดังนั้นอย่าปฏิเสธโดยอัตโนมัติ

verify 1. ดู [ละเมิด] ก่อน หากชัดเจนก็แก้ข้อความ (อยู่เหนือเส้นประจึงฟรี) 2. [น่าสงสัย] ตัดสินด้วยบริบท หากเป็นการอ้างอิงที่ชอบธรรมก็ผ่าน หากไม่ใช่ก็แก้ 3. จากส่วนที่ผ่าน สุ่ม 10% ส่งให้ลีดเพื่อกรองความผิดพลาดเชิงบริบทอีกครั้ง 4. ออก dialogue_id และส่งเข้าคิวบันทึกเสียงได้ก็ต่อเมื่อตัดสินทุกรายการเสร็จแล้วเท่านั้น หน้าห้องอัดจะไม่ตรวจสอบอีกต่อไป

ฉบับย่อสำหรับคนเดียว — หากเป็นนักพัฒนาคนเดียวที่ทำเครื่องมือไม่ได้ ให้เขียน voice_profile เพียงหัวข้อเดียวคือ §5 (สำนวนต้องห้าม) ต่อตัวละคร ทุกครั้งที่เขียนบทพูดใหม่ ให้แปะรายการต้องห้ามนั้นไว้หัวพรอมต์แล้วสั่ง AI ว่า "ช่วยทำเครื่องหมายเฉพาะบรรทัดที่ติดรายการนี้" คุณจะได้ 80% ของ lint ด้วยพรอมต์บรรทัดเดียวโดยไม่ต้องมีเครื่องมือ ก่อนส่งเข้าบันทึกเสียง (หรือ TTS) แค่ผ่านขั้นนี้ครั้งเดียว เส้นประหน้าห้องอัดก็จะถูกรักษาไว้

สรุปประเด็นสำคัญของบท

• ในบรรดาห้าสาเหตุของเสียงตัวละครที่แกว่ง การปรับเป็นมาตรฐานโดย AI เพิ่มขึ้นเร็วที่สุด และใบสั่งยาไม่ใช่บริบทที่บกพร่อง แต่คือ voice_profile ที่มีตัวอย่างกำกับ
• voice_lint เพียงทำเครื่องหมายละเมิด·น่าสงสัยเท่านั้น การปฏิเสธเป็นหน้าที่ของคน และข้อห้ามต้องนิยามบริบทยกเว้นกำกับไปด้วย
• การตรวจสอบทุกอย่างจบลงเหนือเส้นประหน้าห้องอัด — ไฟล์เสียงใต้เส้นประย้อนกลับไม่ได้เหมือนข้อความ

ตัวอย่างบทถัดไป

• 6.1. การสร้างคอนเทนต์แบบโพรซีเดอรัลกับ AI — มาบรรจบกันที่ตรงไหน

ส่วนที่ 6 · Content Design

6.1 การสร้างเนื้อหาแบบโพรซีเดอรัลกับ AI — ช่องเดียวที่สองแกนตัดกัน

เช้าวันจันทร์ในห้องประชุมวางแผน บนไวต์บอร์ดมีข้อความบรรทัดเดียว "ก่อนเปิดตัว — เควสต์เสริม 1,000 ชุด" มีคนหยิบเครื่องคิดเลขมากด ถ้านักเขียนหนึ่งคนใช้เวลาหนึ่งวันต่อหนึ่งเควสต์ ก็เท่ากับ 4 ปี ต่อให้ห้าคนช่วยกันทำก็ยังเกือบหนึ่งปี อากาศในห้องเริ่มหนักอึ้ง ผู้เขียนนั่งอยู่ในห้องนี้มา 24 ปีแล้ว และรู้ว่าเมื่อเจอตัวเลขแบบนั้น ผู้คนมักแตกออกเป็นสองทางเดิมเสมอ ฝ่ายหนึ่งบอกว่า "ลดปริมาณลงเถอะ" อีกฝ่ายบอกว่า "ใช้เครื่องมือปั๊มออกมาเลย" และเกือบทุกครั้ง คำตอบสุดท้ายคือทั้งสองอย่าง

การสร้างเนื้อหาแบบโพรซีเดอรัล (Procedural Content Generation ต่อไปเรียกว่า PCG) คือคำตอบเก่าแก่ของฝ่าย "ใช้เครื่องมือปั๊มออกมา" การจัดวางห้องในดันเจี้ยน การผสมออปชันอาวุธ และพูลการสปอว์นศัตรู ถูกทำให้อัตโนมัติด้วย rulebook และตารางความน่าจะเป็นมาตั้งแต่ 20 ปีก่อน สิ่งที่ใหม่จึงไม่ใช่ตัว PCG เอง แต่คือการที่ LLM และโมเดลเจเนอเรทีฟเข้ามาอยู่ในตำแหน่งที่เป็นภาษาธรรมชาติ ภาพ และเนื้อเรื่อง

แต่สิ่งที่หนังสือเล่มนี้ต้องการจะบอกไม่ใช่ "เอา AI ไปต่อกับ PCG สิ" นั่นใคร ๆ ก็ทำ ปัญหาคือต่อมัน ตรงไหน ต่างหาก หากเราหยิบเนื้อหาก้อนหนึ่งขึ้นมาแล้วไม่ตอกหมุดให้ชัดว่ามันมาพบกัน ณ ความเข้มของการทำงานอัตโนมัติระดับใด และที่ชั้นใดของโครงสร้าง ก็จะกลายเป็นสภาพที่มีเครื่องมือแต่ไม่มีที่ทาง บทนี้จะดูวิธีวาดช่องนั้นเป็นพิกัด และดูว่าบนช่องนั้น เนื้อหาหนึ่งชิ้นวิ่งครบหนึ่งรอบในไปป์ไลน์จริงอย่างไร

6.1.1 ตำแหน่งที่ PCG หยุดนิ่งอยู่กับที่

PCG แบบดั้งเดิมแข็งแกร่งในเรื่องความเป็นเชิงกำหนด (deterministic) อินพุตเดียวกันให้เอาต์พุตเดียวกัน และตรวจสอบได้ กราฟห้องในดันเจี้ยน prefix·suffix ของออปชันอาวุธ และการกระจายการสปอว์นศัตรู จึงลงตัวได้ตั้งแต่เนิ่น ๆ "ดาบเปลวเพลิง +5" ออกมาแบบอัตโนมัติได้ตั้งแต่ 20 ปีก่อน

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

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

ตำแหน่งที่ LLM และโมเดลภาพเข้ามาคือตรงนั้นพอดี ขอบเขตที่ปั๊มออกมาได้ขยายไปครอบคลุมถึงพื้นที่ภาษาธรรมชาติ เนื้อเรื่อง และภาพที่ rulebook เคยจัดการไม่ได้ แต่ก็ไม่ได้หมายความว่าการยกตำแหน่งนั้นทั้งหมดให้ AI คือคำตอบ AI ให้คำตอบที่ต่างกันเล็กน้อยทุกครั้ง และเมื่อบริบทว่างเปล่า มันก็จะคายค่าเฉลี่ยของ RPG ทั่วไปออกมา เราจึงต้องออกแบบ จุดเชื่อมต่อ จุดเชื่อมต่อนิยามด้วยแกนพิกัดสองแกน

6.1.2 แกนแรก: ความเข้มของการทำงานอัตโนมัติ (L0\~L3)

แกนตั้งคือ การผสมคน rulebook และ AI ในสัดส่วนใด ในบริษัทพัฒนา MMORPG แห่งหนึ่งที่ผู้เขียนทำงานอยู่ (ต่อไปเรียกว่า 'โปรเจกต์ A') เราแบ่งใช้เป็นสี่ระดับ

L0 — งานมือทั้งหมด ทุกตัวอักษรและทุกการตัดสินใจออกมาจากมือคน เนื้อหาเควสต์หลัก บทพูดของตัวละครซิกเนเจอร์ ตอนจบของเส้นเรื่องที่แตกแขนง คือตำแหน่งที่ความสอดคล้องและความลึกของเนื้อเรื่องเชื่อมตรงกับอัตลักษณ์ของเกม

L1 — การทำงานอัตโนมัติด้วย rulebook คือตำแหน่งของ PCG ดั้งเดิม อัลกอริทึมเชิงกำหนดอย่าง rulebook ตารางความน่าจะเป็น และ BSP สร้างเอาต์พุต ส่วนคนทำหน้าที่ตรวจสอบเท่านั้น การจัดวางห้องในดันเจี้ยน การผสมออปชันอาวุธ และการสปอว์นศัตรู เป็นตัวแทน

L2 — rulebook + AI ช่วย rulebook วางโครง ส่วน AI เติมรายละเอียด ซินอปซิสของเควสต์เสริม ชื่อและภูมิหลังสั้น ๆ ของ NPC ทั่วไป ข้อความแนะนำพื้นที่ล่าสัตว์ คนรับผิดชอบเพียงเมทาดาทาที่ป้อนเข้าและด่านตรวจสอบสุดท้ายเท่านั้น

L3 — AI นำหน้า + คนตรวจสอบ AI สร้างเนื้อหา ส่วนคนเข้าไปแค่ในขั้นตรวจสอบ น่าดึงดูดก็จริง แต่ความเสี่ยงของความไม่เป็นเชิงกำหนด อาการหลอน (hallucination) และความสอดคล้องที่เสียหาย ล้วนมารวมกันอยู่ที่นี่

หัวใจอยู่ที่ L2 มันรวมความเสถียรของ L1 เข้ากับกำลังการปั๊มของ L3 แล้วใช้ด่านตรวจสอบ (verification gate) ปิดจุดอ่อนของทั้งสองฝั่ง L3 มีแรงล่อใจให้รีบนำเข้ามาใช้สูง แต่ผู้เขียนเคยเห็นหลายครั้งที่ภาระการตรวจสอบพุ่งทะลุจนต้องเลิกใช้ภายในหนึ่งถึงสองไตรมาส ถ้าใน 100 ชิ้นมี 70 ชิ้นถูกยกขึ้นมาเป็นรายการน่าสงสัย มันก็แพงกว่าให้คนเขียนเองทั้ง 100 ชิ้นตั้งแต่ต้น

6.1.3 แกนที่สอง: โครงสร้าง Layer (L0\~L4)

ลำพังแกนตั้งอย่างเดียว สายการผลิตยังขับเคลื่อนไม่ได้ ตัวเนื้อหา เอง ต้องถูกแยกออกเป็นชั้น ๆ เสียก่อน ที่ทางให้การทำงานอัตโนมัติเข้ามาจึงจะเกิดขึ้น นี่คือการแยก Layer ที่กล่าวถึงในส่วนที่ 5 และเป็นแกนนอนในแง่ของสายงานเนื้อหา คำอธิบายทั่วไปที่ว่าทั้งห้าชั้นต่างสอดคล้องกับบทบาทหนึ่งของการสร้างแบบโพรซีเดอรัล (จุดยึด·rulebook·เนื้อหา·ค่าตัวเลข·ด่านตรวจ) ได้กล่าวไว้แล้วใน §2.3.6 ในที่นี้จะนำมาวางลงในสายการผลิตเนื้อหาโดยตรง Layer 0 วิสัยทัศน์คือจุดยึดด้านโทนและโลกของเรื่อง (ฉีดเข้าทุกครั้งที่สร้าง) Layer 1 ระบบคือ rulebook ของการสร้าง (กฎ·ตารางความน่าจะเป็น·ระบบแท็ก) Layer 2 เนื้อหาคือตำแหน่งเนื้อความที่ผลลัพธ์ของการสร้างจะมาสะสมกัน (เควสต์เสริม·ภูมิหลัง NPC·ข้อความแนะนำเมือง) Layer 3 ข้อมูลคือค่าตัวเลข·ID·ความสัมพันธ์ (รางวัล·การสปอว์น·เส้นโค้ง) และ Layer 4 บิลด์·QA คือด่านตรวจสอบ (lint·การตรวจความสอดคล้อง·การตรวจสอบโดยนักเขียน)

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

6.1.4 รวมสองแกนไว้ในแผ่นเดียว — เมทริกซ์ การทำงานอัตโนมัติ × Layer

นำสองแกนที่บรรยายเป็นถ้อยคำมาจนถึงตอนนี้มาซ้อนกันเป็นตารางแผ่นเดียว แนวนอนคือ Layer ของเนื้อหา แนวตั้งคือความเข้มของการทำงานอัตโนมัติ ป้ายในแต่ละช่องคือเนื้อหาที่ครอบครองช่องนั้นจริงในโปรเจกต์ A ยิ่งช่องสีเข้มมากเท่าใด ก็ยิ่งใกล้จุดศูนย์ถ่วงของสายการผลิตมากเท่านั้น

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

เมื่ออ่านตารางนี้ไปเรื่อย ๆ จะมีสองอย่างที่เข้าตา หนึ่ง จุดศูนย์ถ่วง (ช่องสีเข้ม) อยู่ที่แถว L2 × คอลัมน์ Layer 2 โครงเควสต์เสริมและภูมิหลัง NPC คือตำแหน่งนั้น มันคือหัวใจของสายการผลิต สอง เนื้อหาหนึ่งชิ้นไม่ได้อยู่แค่ช่องเดียว เควสต์เสริมมีเนื้อความ (Layer 2) อยู่ในช่อง L2 ก็จริง แต่ค่ารางวัล (Layer 3) ของมันเลื่อนลงไปอยู่ในช่อง L1 ต่อให้เป็นเควสต์เดียวกัน แต่ละส่วนก็อาศัยอยู่คนละช่อง นี่คือเหตุผลที่เราแยกสองแกนออกจากกัน

6.1.5 ไปป์ไลน์ขนาดย่อที่วิ่งอยู่บนช่องเดียว

บนช่องจุดศูนย์ถ่วง — แถว L2 × คอลัมน์ Layer 2 โครงเควสต์เสริม — เรามาดูกันว่าเนื้อหาหนึ่งชิ้นวิ่งครบหนึ่งรอบจริงอย่างไร กระแสการไหลเป็นดังนี้

flowchart TD
    A["ฉีด Layer 0 วิสัยทัศน์
(จุดยึดโทน: หมู่บ้านชนบทแบบตะวันออก)"] --> B["Layer 1 rulebook
(สร้างโครงสล็อตเป้าหมาย·รางวัล)"]
    B --> C["L2 AI ช่วย
(เติมแรงจูงใจ·ภูมิหลังหนึ่งบรรทัดของ NPC)"]
    C --> D{"Layer 4 ด่านตรวจสอบ
(lint โทน·ความสอดคล้อง)"}
    D -->|ผ่าน| E["Layer 3 ยืนยันข้อมูล
(ค่ารางวัลให้ rulebook คำนวณ)"]
    D -->|ตีกลับ| B
    E --> F["นำเข้าบิลด์"]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class B,D code;
    class C ai;
    class E data;
    class F pass;

ลองไล่ตามกระแสนี้ผ่านบันทึกเซสชันจริง (worked transcript) สักครั้ง สมมติว่าเรากำลังสร้างเควสต์งานจิปาถะหนึ่งชุดของหมู่บ้านชนบท

ขั้นที่ 1 — Layer 1 rulebook ดึงโครงออกมา rulebook เป็นเชิงกำหนด มันเติมแค่สล็อตแล้วคายออกมา

[โครงเควสต์ — เอาต์พุตของ rulebook]
พื้นที่: หมู่บ้านชนบท_3
บทบาทผู้ว่าจ้าง: คนเก็บสมุนไพร
ประเภทเป้าหมาย: เก็บรวบรวม(ยาสมุนไพร x6)
อุปสรรค: หมาป่าสปอว์น(กลางคืน)
สล็อตรางวัล: { gold: ?, exp: ?, item: เคียวเก็บเกี่ยว }

ขั้นที่ 2 — ขอรายละเอียดจาก AI เนื้อความพรอมต์เต็มเป็นดังนี้ (ป้อน Layer 0 วิสัยทัศน์เป็นบริบทก่อน)

คุณคือนักเขียนเควสต์ของ MMORPG ที่มีฉากเป็นหมู่บ้านชนบทแฟนตาซีตะวันออก จุดยึดโทน: "เรียบง่ายแต่แฝงด้วยความเชื่อโชคลางและความหวาดกลัวแบบชนบท" จงรับโครงด้านล่างไป แล้วเขียนแรงจูงใจหนึ่งบรรทัดของผู้ว่าจ้าง ชื่อ NPC และข้อความว่าจ้างสองประโยคที่ผู้เล่นจะเห็น ห้ามสร้างค่ารางวัลเด็ดขาด (ระบบเป็นผู้กำหนด) เอาต์พุตเป็น JSON โครง: { พื้นที่: หมู่บ้านชนบท_3, ผู้ว่าจ้าง: คนเก็บสมุนไพร, เป้าหมาย: เก็บยาสมุนไพร 6 ชิ้น, อุปสรรค: หมาป่ายามค่ำคืน, ไอเทมรางวัล: เคียวเก็บเกี่ยว }

ขั้นที่ 3 — ผลลัพธ์ดิบของ Claude (ย้ายมาตามต้นฉบับโดยไม่สรุปย่อ)

{
  "npc_name": "ป้าซัมวอล",
  "motive": "ทุกคืนเสียงหอนของหมาป่าทำให้ไร่สมุนไพรพังเสียหาย จนไม่กล้าออกไปเก็บยาสมุนไพรชิ้นสุดท้าย",
  "quest_text": "พอตกค่ำพวกหมาป่าก็มาคุ้ยไร่สมุนไพรจนกระจุยกระจาย กลัวจนก้าวขาไม่ออก ช่วยไปเก็บรากยาสมุนไพรหกรากที่เชิงเขาแทนข้าหน่อยเถิด",
  "reward": { "gold": 120, "exp": 300 }
}

มีสิ่งที่ต้องหยุดดูตรงนี้ AI สร้างฟิลด์ reward ใส่เข้ามาเอง ทั้งที่ไม่ได้สั่ง นี่แสดงให้เห็นตรง ๆ ว่าทำไมแกนที่ 1 กับแกนที่ 2 จึงต้องแยกออกจากกัน ค่ารางวัล (Layer 3) เป็นตำแหน่งของ rulebook ใน L1 ไม่ใช่ตำแหน่งของ AI (L2) ถ้ายกมันให้ AI ตัวเลขจะแกว่งไปทุกครั้งที่เรียก จนเส้นโค้งรางวัลพังทลาย

ขั้นที่ 4 — การตรวจสอบและปฏิเสธโดยคน ผู้ตรวจสอบทำสองอย่าง (1) ลบ ฟิลด์ reward ออก — นี่คือช่องที่ rulebook จะมาเติม (2) ดูโทน "ป้าซัมวอล" แรงจูงใจหนึ่งบรรทัด และข้อความว่าจ้างสองประโยค เข้ากับโทนหมู่บ้านชนบท ผ่าน หาก AI ใส่คำที่อยู่นอกโลกของเรื่องอย่าง "คำว่าจ้างจากกิลด์นักเวท" ก็จะตีกลับตรงนี้แล้วย้อนกลับไปขั้นสร้างโครง

ขั้นที่ 5 — ยืนยันข้อมูล Layer 3 rulebook เติมสล็อตรางวัลที่ถูกลบกลับเข้ามาใหม่ มันคือสูตรเชิงกำหนดที่ผูกกับเลเวลของพื้นที่และความยากของเป้าหมาย gold: 85, exp: 240 ค่าที่เข้ากับเส้นโค้งจะถูกใส่เข้าไป ไม่ใช่ 120·300 ที่ AI คายออกมาตามใจ

หนึ่งรอบนี้คือไซเคิลมาตรฐานของช่องจุดศูนย์ถ่วง rulebook ทำโครง AI เติมเนื้อ คนเป็นด่าน rulebook ใส่ค่าตัวเลขอีกที เนื้อหา 1,000 ชิ้นวิ่งตามไซเคิลนี้ทั้งหมด เพราะช่องถูกกำหนดไว้แล้ว จึงไม่ต้องมาเถียงกันใหม่ทุกครั้งว่า "อันนี้ใครสร้าง"

6.1.6 ห้าคำถามที่ใช้ตอนกำหนดช่อง

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

หนึ่ง ภาระการปั๊มมากแค่ไหน ก่อนเปิดตัวต้องการ N ชุดหรือไม่ ถ้า N เกิน 100 แถว L0 แทบเป็นไปไม่ได้

สอง ความต้องการความสอดคล้องสูงแค่ไหน ถ้าความสอดคล้องระหว่างเนื้อหาคือหัวใจของประสบการณ์ ด่านตรวจสอบ (Layer 4) ต้องแข็งแกร่ง แต่ถ้าความหลากหลายคือหัวใจ ก็มีช่องว่างให้ขยับขึ้นไปแถวบนได้

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

สี่ ค่าใช้จ่ายในการตรวจสอบเท่าไร ต่อเนื้อหาหนึ่งชิ้น 5 นาทีหรือ 30 นาที กำหนดความยาวของรอบการดำเนินงาน

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

ลองโยนห้าข้อนี้ใส่เควสต์เสริม คำตอบจะรวมไปทางเดียว มากกว่า 1,000 ชุด (L0 เป็นไปไม่ได้) ความสอดคล้องต่ำกว่าเควสต์หลัก ยอมรับความไม่เป็นเชิงกำหนด ตรวจสอบ 5\~10 นาที ค่าใช้จ่ายอุบัติเหตุต่ำ (ทิ้งทีละชิ้นได้) เมื่อห้าคำตอบมารวมกัน ช่อง L2 × Layer 2 จึงเป็นธรรมชาติ ลองโยนห้าข้อเดียวกันใส่เควสต์หลัก คำตอบจะรวมไปตรงข้ามกัน 50 ชุด ความสอดคล้องและความลึกของเนื้อเรื่องสูงสุด ไม่ยอมรับความไม่เป็นเชิงกำหนด ค่าใช้จ่ายในการตรวจสอบสูง ค่าใช้จ่ายอุบัติเหตุสูงมาก — เป็นช่อง L0

6.1.7 กับดักที่พบบ่อยสี่ข้อ

ต่อให้วาดตารางไว้แล้ว กับดักที่ตกลงไปก็คล้ายเดิม มีสี่ข้อที่เกิดซ้ำ

หนึ่ง เริ่มจากแถว L3 ถ้าออกตัวด้วยความคาดหวังว่า "AI จัดการ 100 ชุดเอง" การตรวจสอบจะพุ่งทะลุ ให้ตั้งช่อง L1 ให้ลงตัวก่อน แล้วค่อยขยับขึ้น L2 ส่วน L3 ทำเฉพาะบางส่วนอย่างระมัดระวัง การกระทำที่คนลบฟิลด์รางวัลออกในไปป์ไลน์ขนาดย่อข้างต้น แสดงให้เห็นในขนาดเล็กว่าทำไมแถว L3 จึงอันตราย

สอง มอบหมายให้ AI ทั้งก้อนโดยไม่มี rulebook "ช่วยสร้างเควสต์เสริม 100 ชุด" จะเรียกค่าเฉลี่ยของ RPG ทั่วไปออกมา Layer 1 rulebook ต้องวางโครงก่อน แล้ว AI จึงเติมเนื้อบนนั้น เนื้อหาของเกมเราถึงจะออกมา การเขียน rulebook สักหนึ่งเล่มคืองานที่กินแรงที่สุดและน่าเบื่อที่สุดใน PCG แต่ถ้าข้ามมันไป การปั๊มทุกอย่างที่อยู่เหนือมันก็จะทรุดลงเป็นค่าเฉลี่ย

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

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

6.1.8 การวัดผล — หกเดือนที่ย้ายไปช่องจุดศูนย์ถ่วง

ในโปรเจกต์ A หลังจากย้ายเควสต์เสริมจากช่อง L0 ไปช่อง L2 ได้วัดผลเป็นเวลาหกเดือน ในบรรดาตัวเลขด้านล่าง ค่าสัมบูรณ์เป็นการประมาณของผู้เขียน (ยังไม่ได้ตรวจสอบ) ส่วนทิศทางและสัดส่วนของการเปลี่ยนแปลงคือสิ่งที่สังเกตได้จากการวัดจริง

อัตราการทิ้งขึ้นไปเป็น 20% แต่ความเร็วการปั๊มเร็วขึ้น 6\~8 เท่า ปริมาณงานสุทธิจึงเพิ่มขึ้น 4\~5 เท่า อุบัติเหตุความสอดคล้องเพิ่มขึ้นเล็กน้อยเป็น 5\~8 ครั้งต่อไตรมาส แต่ด้วยด่านตรวจสอบและการเสริม rulebook ก็กลับสู่ช่วงปกติภายในไตรมาส

การเปลี่ยนแปลงที่ใหญ่ที่สุดไม่ใช่ตัวเลข แต่คือคน ตอนแรกนักเขียนรู้สึกเหมือนกลายเป็น "ผู้ตรวจสอบงานปั๊ม" ความพึงพอใจจึงตกจาก 8 เหลือ 6 เพื่อกอบกู้สิ่งนี้ เราจึงสอดนโยบายที่รับประกันเวลาของนักเขียนอย่างชัดเจนให้กับเควสต์หลักและเควสต์เสริมซิกเนเจอร์ (เมืองละ 1\~2 ชุด) เป็นการตอกหมุดให้สายการผลิตไม่ได้ดูดเวลาของนักเขียนไป แต่กลายเป็นเครื่องมือที่ส่งเวลานั้นคืนกลับไปยังเควสต์หลัก หกเดือนต่อมา ความพึงพอใจกลับมาเป็น 7

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

6.1.9 แยก Layer ก่อน แล้ว PCG จึงมาทีหลังบนนั้น

ข้อเสนอทั่วไปที่ว่าการแยก Layer คือเงื่อนไขเบื้องต้นของการสร้างแบบโพรซีเดอรัล อยู่ใน §2.3.6 ในที่นี้จะดูเพียงว่ามันเผยตัวบนตาราง PCG อย่างไร ในทีมที่แกนนอน (Layer 0\~4) พร่าเลือน ไม่มีช่องใดขับเคลื่อนได้อย่างเสถียร ถ้าไม่รู้ว่า Layer 0 วิสัยทัศน์อยู่ที่ไหน จุดยึดโทนของแต่ละ generator ก็ว่างเปล่าจนคายค่าเฉลี่ยของ RPG ทั่วไปออกมา ถ้า Layer 1 rulebook กับ Layer 2 เนื้อความปนกันอยู่ในไฟล์เดียว เวลาแก้กฎสักหนึ่งบรรทัดก็ต้องไปแตะเนื้อความหลายสิบจุดพร้อมกัน และถ้า Layer 3 ข้อมูลถูกป้อนอยู่ในเนื้อความ การปรับเส้นโค้งรางวัลครั้งเดียวจะกินเวลานักเขียนไปหนึ่งสัปดาห์ — นี่คือเหตุผลที่เราแยกรางวัลออกไปไว้เป็นสล็อตต่างหากในไปป์ไลน์ขนาดย่อข้างต้น

ดังนั้นสิ่งที่ต้องตรวจก่อนนำ PCG เข้ามาจึงไม่ใช่การเลือกเครื่องมือ แต่คือ แกนนอนถูกแยกออกหรือยัง ในทีมที่มีครบห้าชั้น ค่าใช้จ่ายในการต่อ generator ของ L1 คือเวลานักเขียนหนึ่งคนหนึ่งไตรมาส ในทีมที่ห้าชั้นปนกัน การนำเข้ามาแบบเดียวกันจะถูกเลิกใช้ด้วยอุบัติเหตุความสอดคล้องภายในสองไตรมาส

ห้าช่องไม่จำเป็นต้องสมบูรณ์แบบตั้งแต่ต้น แยกอย่างค่อยเป็นค่อยไป อินเทอร์เฟซให้แคบ ในไตรมาสแรก แค่แยกโทนหนึ่งบรรทัดของ Layer 0 และ rulebook หนึ่งเล่มของ Layer 1 ออกมา ที่ทางให้ generator เข้ามาก็เปิดออกแล้ว แต่ก็ไม่ได้หมายความว่าผัดผ่อนได้ไม่มีที่สิ้นสุด ถ้า Layer 2 เนื้อความกับ Layer 3 ข้อมูลยังเป็นก้อนเดียวกันจนถึงที่สุด เครื่องมือที่เป็นรูปธรรมในบทถัดไปก็จะหาที่ทางลงไม่ได้

6.1.10 ตัวอย่างบทถัดไป

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

สรุปประเด็นสำคัญของบท

• ความเข้มของการทำงานอัตโนมัติ (แนวตั้ง L0\~L3) กับโครงสร้าง Layer (แนวนอน 0\~4) มีความหมายขึ้นมาได้ก็ต่อเมื่อคูณกันเท่านั้น
• จุดศูนย์ถ่วงของสายการผลิตคือช่อง L2 × Layer 2 โครงเควสต์เสริม
• การแยกแกนนอนต้องมาก่อน และ PCG จะขับเคลื่อนได้ก็เฉพาะบนช่องเดียวที่อยู่เหนือมันเท่านั้น

ลองทำดู — วางเนื้อหาหนึ่งชิ้นลงบนช่องเดียว

setup เลือกเนื้อหาที่จะปั๊ม 1 ประเภท (เช่น เควสต์เสริม) แยกโทนหนึ่งบรรทัดของ Layer 0 และโครง rulebook ของ Layer 1 (นิยามสล็อต) ออกมาเป็นไฟล์ต่างหาก ปล่อยสล็อตค่ารางวัลให้ว่างไว้ทางฝั่ง rulebook

prompt หลังป้อนวิสัยทัศน์เป็นบริบทแล้ว ให้โครงไป และระบุชัดว่า "ห้ามสร้างค่ารางวัล เอาต์พุตเป็น JSON" ดัดแปลงพรอมต์ขั้นที่ 2 ข้างต้นมาใช้ได้เลย

verify ดูสามอย่าง (1) ถ้า AI ใส่ฟิลด์รางวัลเข้ามาเองให้ลบออก (L3 เป็นตำแหน่งของ rulebook) (2) ถ้ามีคำที่อยู่นอกโลกของเรื่อง ให้ตีกลับไปขั้นสร้างโครง (3) เฉพาะส่วนที่ผ่านเท่านั้นที่ rulebook จะเติมค่ารางวัลแล้วใส่เข้าบิลด์

ฉบับย่อสำหรับคนเดียว ไม่มีทีมก็ได้ ให้คุณสร้าง rulebook หนึ่งเล่ม (สล็อต 5 ช่อง) กับโทนหนึ่งบรรทัดเป็นไฟล์ข้อความเอง ลองรันเควสต์ 10 ชุดผ่านไซเคิลข้างต้น แล้วนับว่าตอนตรวจสอบตีกลับไปกี่ชุด ถ้าอัตราการตีกลับเกิน 30% แปลว่าช่องผิด — ให้ทำโครง rulebook ให้ละเอียดขึ้น หรือเลื่อนลงหนึ่งแถว (L1) แล้วดูใหม่ เมื่ออัตราการตีกลับเสถียร นั่นคือสัญญาณว่าช่องนั้นทำงานได้ในขนาดของคุณ

6.2 city_hunting_generator — สร้างเมือง 30 แห่งภายใน 4 สัปดาห์

ผู้อ่านหลัก: นักออกแบบเกม MMORPG ที่รับผิดชอบการผลิตเนื้อหาจำนวนมาก (ทีมขนาดกลาง 10–50 คน) ฉบับย่อสำหรับผู้อ่านที่ทำคนเดียว/เป็นงานอดิเรก: §6.2.10 「ถ้าทำคนเดียวก็แค่เท่านี้」

ผมยังจำการคำนวณในวันแรกที่ได้รับตารางเวลาซึ่งบอกว่าต้องมีเมือง 30 แห่งก่อนเปิดตัว เมืองหนึ่งประกอบด้วยข้อความแนะนำ 5–10 บรรทัด พื้นที่ล่า 3–5 จุด NPC 5–10 คนกับเควสต์เสริม 2–3 อันต่อพื้นที่ล่าแต่ละจุด ไอเทมพิเศษประจำถิ่น 1–3 ชนิด และบอสประจำเมือง 1 ตัว ถ้าปั้นเมืองหนึ่งด้วยมือก็กินเวลา 1–2 สัปดาห์ ถ้า 30 แห่งก็เท่ากับให้นักเขียนหนึ่งคนทุ่มเวลา 6 เดือนเต็มไปกับเมืองเพียงอย่างเดียว

แต่ 6 เดือนนั้นไม่มี เวลาของนักเขียนถูกผูกไว้กับเควสต์หลักและตัวละครซิกเนเจอร์อยู่แล้ว และเมือง 30 แห่งต้องทำควบคู่ไปกับงานนั้น แรงกระตุ้นแรกที่ว่า "ก็ให้ AI สร้างเมือง 30 แห่งให้ก็ได้นี่" พังลงในไม่ช้า เพราะถ้าสั่งทั้งก้อน สิ่งที่ได้คือหมู่บ้านแฟนตาซีที่คล้ายกัน 30 แห่ง บทนี้จะดูว่าเครื่องมือ city_hunting_generator ที่ผมสร้างขึ้นแทนแรงกระตุ้นนั้นรวมสี่ขั้นตอน — อินพุต รูลบุ๊ก AI และการตรวจสอบ — เข้าเป็นหนึ่งรอบได้อย่างไร และเมื่อหมุนรอบนั้นจริงจนจบจริงสักครั้ง อะไรจะออกมาและอะไรจะถูกทิ้ง

บันทึกการใช้งานจริงของผู้เขียน city_hunting_generator ในบทนี้คือการนำเครื่องมือจริงที่ผู้เขียนใช้งานอยู่ในโฟลเดอร์ R&D ของบริษัทมาทำให้เป็นนิรนาม ชื่อไฟล์ โครงสร้างโค้ด และรายการตรวจสอบนั้นยกมาจากเครื่องมือจริงอย่างซื่อตรง ส่วนชื่อเมือง (เช่น silvermark) และชื่อเฉพาะของบริษัทถูกแทนที่ใหม่เพื่อใช้ในหนังสือ เนื้อหาผลลัพธ์เป็นการเรียบเรียงใหม่จากเซสชันจริง

6.2.1 คนทำแค่เมตาดาตาและการตรวจสอบขั้นสุดท้ายเท่านั้น

ลำดับการทำงานทั้งหมดของเครื่องมือมีสี่ขั้น หัวใจอยู่ที่ขั้น 1 และขั้น 3 เป็นเชิงกำหนด (deterministic — รูลบุ๊ก) มีแต่ขั้น 2 เท่านั้นที่เป็น AI เมื่อรูลบุ๊กยึดทั้งโครงสร้างและการตรวจสอบไว้จากสองฝั่ง AI ที่อยู่ตรงกลางต่อให้ตอบต่างกันเล็กน้อยทุกครั้ง ความสอดคล้องระหว่างเมืองก็จะไม่สั่นคลอน คนเข้าไปเกี่ยวข้องเฉพาะอินพุตแรก (เมตาดาตา) และด่านสุดท้าย (การตรวจสอบ) เท่านั้น

flowchart TB
    A["อินพุต: เมตาดาตาเมือง yaml
(คน 15~20 นาที/เมือง)
lore_seeds 3 ตัว · forbidden_names แนบอัตโนมัติ"]
    A --> B["ขั้น 1 เชิงกำหนด: rules.py
generate_skeleton()
จำนวนพื้นที่ล่า·การกระจายศัตรู·เส้นโค้งรางวัล·บอส"]
    B --> C["ขั้น 2 AI: พรอมต์ 3 แบบ
L0 แคชวิสัยทัศน์ + L1 ฉีดกฎ
+ L2 เนื้อหาเมืองข้างเคียง
→ ข้อความแนะนำ·NPC·เควสต์เสริม"]
    C --> D{"ขั้น 3 เชิงกำหนด: lint
ชื่อซ้ำ·คำต้องห้าม·โทนเสียง
·ปริมาณ·ช่วงรางวัล"}
    D -->|ละเมิด alert| E["ขั้น 4 ด่านตรวจสอบโดยนักเขียน
(5~10 นาที/เมือง)
ตัดสินใจทิ้ง·สร้างใหม่"]
    E -->|ขอใหม่| C
    E -->|ผ่าน| F["นำเข้าบิลด์"]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class B,D code;
    class C ai;
    class A,E human;
    class F pass;

ในภาพนี้ จุดที่มือคนแตะมีเพียงสองแห่ง ตำแหน่งบนสุดที่ใส่เมตาดาตาหนึ่งหน้าให้สะอาด และตำแหน่งล่างสุดที่ตัดสินเรื่องโทนเสียงและการเล่าเรื่องซึ่ง lint จับไม่ได้ ระหว่างนั้น การสร้างโครงที่น่าเบื่อและการผลิตเนื้อหาจำนวนมากให้รูลบุ๊กกับ AI หมุนไป การออกแบบที่ชี้ขาดคือ แม้ lint (ขั้น 3) จะพบการละเมิด ก็จะไม่ทิ้งโดยอัตโนมัติ แต่ส่ง alert ขึ้นไปยังด่านนักเขียน (ขั้น 4) เท่านั้น เหตุผลจะดูใน §6.2.5

6.2.2 อินพุต — เมตาดาตาเมืองหนึ่งหน้า

นักเขียนเขียนเมตาดาตาหนึ่งหน้าต่อหนึ่งเมือง เวลาที่ใช้คือ 15–20 นาที สั้นก็จริง แต่หนึ่งหน้านี้คืออินพุตทั้งหมดของสามขั้นถัดไป

# city_021_silvermark.meta.yaml
city_id: city_021_silvermark
region: west
climate: cold_arid
dominant_faction: scholar_guild
cultural_tone: scholarly_strict
level_range: [25, 30]
lore_seeds:
  - เคยเป็นศูนย์กลางของการผนึกเวทมนตร์เมื่อ 100 ปีก่อน
  - สัญญาณแรกของการเสื่อมพลังผนึกถูกพบในเมืองนี้
  - ที่ตั้งสำนักงานใหญ่ของกิลด์นักปราชญ์
neighbors: [city_018, city_023]
# forbidden_names: (สคริปต์แนบให้อัตโนมัติ — นักเขียนไม่ต้องกรอก)

สล็อตที่สำคัญที่สุดคือ lore_seeds เหตุการณ์สำคัญ 3–5 อันเป็นตัวยึดตัวตนของเมือง ถ้าน้อยเกินไป AI จะคายเมืองแฟนตาซีทั่ว ๆ ไปออกมา ถ้ามากเกินไป เหตุการณ์ก็จะขัดแย้งกันเอง จากประสบการณ์ของผู้เขียน 3 อันเสถียรที่สุด

forbidden_names นักเขียนไม่ต้องเติม สคริปต์จะอ่านรายชื่อเมืองและตัวละครที่มีอยู่เดิมมาแนบเข้ากับเมตาดาตาโดยอัตโนมัติ เพราะเมื่อสะสมเมือง 30 แห่ง × NPC เฉลี่ย 50 คน การตรวจสอบความซ้ำของชื่อ 1,500 ชื่อด้วยหัวคนนั้นเป็นไปไม่ได้ จึงไม่ต้องเขียน "ทำให้ไม่ซ้ำกับ NPC เมืองอื่น" ด้วยมือทุกครั้ง

6.2.3 ขั้น 1 รูลบุ๊ก — ยึดโครงด้วยเชิงกำหนด

รูลบุ๊กรับเมตาดาตามาสร้างโครงสร้างของเมือง โค้ดเรียบง่าย

# city_hunting_generator/rules.py (โครง)
def generate_skeleton(meta):
    region_rules = REGION_RULES[meta.region]
    hg_count = region_rules.hunting_grounds_range.sample()
    enemy_dist = ENEMY_RULES[meta.climate][meta.dominant_faction]

    skeleton = {
        "hunting_grounds": [
            {
                "id": f"{meta.city_id}_hg_{i}",
                "level": meta.level_range[0] + i,
                "enemy_types": enemy_dist.sample(k=3),
                "reward_curve": calc_reward(meta.level_range[0] + i),
                "npc_count": region_rules.npc_per_hg,
                "sidequest_count": region_rules.sidequest_per_hg,
            }
            for i in range(hg_count)
        ],
        "boss": {
            "id": f"{meta.city_id}_boss",
            "level": meta.level_range[1] + 2,
            "pattern": BOSS_PATTERNS[meta.region],
        },
    }
    return skeleton

ผลลัพธ์เป็นเชิงกำหนด ใส่เมตาดาตาเดียวกันก็ได้โครงเดียวกัน โค้ดรับประกันว่าเส้นโค้งรางวัลอยู่ในช่วงมาตรฐานตาม region·level หรือไม่ และการกระจายศัตรูตรงกับกฎ climate·faction หรือไม่ และการทดสอบถดถอย (regression test) ก็จับได้ ขั้นนี้ไม่มอบให้ AI เด็ดขาด เพราะถ้าให้ AI สุ่มเส้นโค้งรางวัลเป็นตัวเลขต่างกันทุกครั้งที่เรียก ความสมดุลระหว่างเมืองก็จะสั่นคลอนตรงนั้นทันที

เมื่อใส่เมตาดาตาของ silvermark rules.py จะคืนโครงเปล่ามาเป็นพื้นที่ล่า 4 จุด (city_021_silvermark_hg_0\~hg_3) แต่ละจุดมีสล็อต NPC 6 ช่อง·สล็อตเควสต์เสริม 3 ช่อง และบอสเลเวล 32 จำนวน 1 ตัว ยังไม่มีทั้งชื่อและเนื้อหา เป็นตารางของช่องที่ต้องเติม การเติมช่องเหล่านั้นคืองานของ AI ในขั้น 2

6.2.4 ขั้น 2 AI — สร้างเนื้อหาภาษาธรรมชาติ

หลังจากรูลบุ๊กสร้างโครงแล้ว AI ก็เติมเนื้อหาภาษาธรรมชาติลงไปบนนั้น ข้อความแนะนำเมือง ชื่อ·รูปลักษณ์·ภูมิหลังสั้น ๆ ของ NPC ซินอปซิสเควสต์เสริม และข้อความบรรยายรสชาติ (flavor text) ของไอเทมพิเศษประจำถิ่น ออกมาตรงนี้

รูปแบบการเรียกใช้คือโครงสร้าง 4 ชั้นของการฉีดบริบทตามเดิมเลย แคช L0 วิสัยทัศน์ (world_premise + tone_manifesto) ฉีด L1 กฎ (city_naming_rule + region_west_lore) แบบเลือกใส่ เพิ่ม L2 เนื้อหาข้างเคียง (รายชื่อ NPC ของเมืองอื่น) และต่อท้ายด้วยคำสั่งงานในตอนสุดท้าย พรอมต์ข้อความแนะนำเมืองอยู่ในรูปที่คัดลอกไปใช้ได้ทันที

[บริบท L0] world_premise + narrative_pillar + tone_manifesto  (แคช)
[บริบท L1] city_naming_rule, region_west_lore
[อินพุต] city_021_silvermark.meta.yaml + lore_seeds 3 ตัว

เขียนข้อความแนะนำเมืองนี้ให้ 6~8 บรรทัด สอด lore_seeds ทั้งสามอันเข้าไปอย่างเป็นธรรมชาติ
และตัดคำซ้ำซากแบบ RPG อย่าง "หมู่บ้านอันสงบสุข" ออก โทนต้องเป็นแบบนักปราชญ์และเข้มงวด ยับยั้งอารมณ์ความรู้สึก
เอาแต่เนื้อหา ไม่ต้องมีคำนำหรือคำอธิบายประกอบ

รูปแบบเดียวกันนี้ทำซ้ำในการเรียกผลิต NPC และเควสต์เสริมตามเดิม ต่างกันแค่บริบทและรูปแบบเอาต์พุตเท่านั้น การเรียก NPC จะมีสล็อต forbidden_names (ห้ามชื่อ NPC ซ้ำกับเมืองอื่น) ใส่เข้าไป และการเรียกเควสต์เสริมจะมีข้อจำกัด "ให้เลือก NPC ผู้มอบหมายงานจาก NPC ที่สร้างไว้ข้างบน" ใส่เข้าไป

แล้วจริง ๆ มันออกมาเป็นอะไร ลองหมุนจนจบสักหนึ่งครั้ง

6.2.5 หมุนหนึ่งรอบจนจบ — เอาต์พุต·การตรวจสอบ·การทิ้ง

ถ้าเขียนแบบนามธรรมว่า "AI เติมเนื้อหา" อย่างเดียว ก็ไม่อาจรู้ว่าเครื่องมือนี้คายอะไรออกมาจริง ๆ จึงขอตามรอบของเมือง silvermark หนึ่งเมืองตั้งแต่อินพุตจนถึงการทิ้งจนจบสักหนึ่งรอบ

[เอาต์พุตขั้น 2 AI — ข้อความแนะนำเมือง] (เรียบเรียงใหม่จากเซสชันจริง)

ซิลเวอร์มาร์กคือเมืองแห่งการผนึก เมื่อ 100 ปีก่อน นักปราชญ์เจ็ดคนได้สร้างวงผนึกไว้ใต้ดินที่นี่เพื่อสกัดการล้นทะลักของพลังเวทฝั่งตะวันตก และเมืองก็เติบโตขึ้นมาโดยวางหินทีละก้อนไว้บนวงผนึกนั้น หอระฆังของสำนักงานใหญ่กิลด์นักปราชญ์คือหอสังเกตการณ์ที่อ่านชีพจรของการผนึก ไม่ใช่ยอดหอที่มุ่งสู่เทพเจ้า ในช่วง 3 ปีหลัง มีข้อความหนึ่งบรรทัดถูกบันทึกซ้ำในรายงานการสังเกต "ชีพจรกำลังเย็นลง" สัญญาณแรกของการเสื่อมพลังผนึกสั่นไหวขึ้นเป็นครั้งแรกที่หน้าปัดของเมืองนี้ ไม่ใช่ที่อื่นใด นักปราชญ์ตามท้องถนนไม่พูดถึงมันด้วยเสียงดัง เพียงแต่วันที่ไฟบนหอระฆังไม่ดับตลอดทั้งคืนมีมากขึ้นเท่านั้นเอง

ตรงนี้ lore_seeds ทั้ง 3 อัน (ศูนย์กลางการผนึก·สัญญาณเสื่อมแรก·สำนักงานใหญ่กิลด์นักปราชญ์) ถูกใส่ลงในเนื้อหาครบ ไม่มีคำซ้ำซากแบบ "หมู่บ้านอันสงบสุขที่ต้อนรับนักผจญภัย" และโทน scholarly_strict (ยับยั้งอารมณ์ ใช้คำศัพท์เชิงสังเกต·บันทึก) ยังคงอยู่ นี่คือหน้าตาของเอาต์พุตที่ผ่านได้

ต่อจากนั้น รอบเดียวกันก็เติม 3 ช่องจาก 6 ช่องสล็อต NPC ของพื้นที่ล่า hg_0

[เอาต์พุตขั้น 2 AI — NPC 3 คน] (เรียบเรียงใหม่จากเซสชันจริง)

1) โดเรน เวล (Doren Vale) — ผู้ช่วยสังเกตการณ์หอระฆัง วัย 50 ปลาย ติดแว่นขยายทองเหลืองที่ตาข้างหนึ่งถาวร ทำงานบันทึกการสั่นสะเทือนละเอียดของชีพจรการผนึกมา 30 ปี พูดน้อย สื่อสารด้วยตัวเลขเท่านั้น "วันนี้ 12.4 เมื่อวานนี้ 12.1 มันกำลังขึ้น ไม่ใช่เรื่องดี"

2) มิรา คอสต์ (Mira Kost) — บรรณารักษ์คลังเอกสารกิลด์ วัย 30 รอยหมึกที่นิ้วลบไม่ออก คอยรักษาต้นฉบับการออกแบบวงผนึกไว้ แต่เชื่อว่านักปราชญ์ที่อ่านแบบแปลนนั้นออกได้ตายไปหมดแล้ว ระแวงคนนอกอย่างมาก

3) เกรม (Grem) — คนเฝ้าเตาไฟใต้หอระฆัง ไม่ทราบที่มา อายุไม่แน่ชัด งานเดียวคือไม่ปล่อยให้ไฟบนหอระฆังดับ และตอบคนที่ถามเรื่องการผนึกเพียงว่า "แค่ดูไฟก็พอ" (ทำเครื่องหมายคลุมเครือ — AI รายงานเอง)

ขอให้สังเกตว่า NPC คนที่สาม 'เกรม' ถูก AI ติด เครื่องหมายคลุมเครือ ให้เอง พรอมต์ที่ดีทำให้ AI สามารถพูดได้ว่า "อันนี้ผมยืนยันไม่ได้" ตอนนี้ lint ขั้น 3 จะตรวจเอาต์พุตชุดนี้

[เอาต์พุตขั้น 3 lint] (รูปแบบจริง)

[PASS] ตรวจปริมาณ: ข้อความแนะนำ 7 บรรทัด (เกณฑ์ 6~8)
[PASS] ช่วงรางวัล: reward_curve ของ hg_0~hg_3 อยู่ในช่วงมาตรฐาน
[WARN] ชื่อซ้ำ: "Mira Kost" — กับ "Mira Veldt" ของ city_014_riverhold
       นามสกุล (Kost/Veldt) ต่างกันแต่ชื่อ (Mira) เหมือนกัน ชนกับ forbidden_names ใกล้เคียง
[PASS] คำศัพท์ต้องห้าม: ละเมิด tone_manifesto 0 รายการ
[WARN] ความสอดคล้องโทนเสียง: บทพูดของ "เกรม" voice_lint เชื่อมั่น 0.62 (ต่ำกว่าเกณฑ์ 0.70)

lint จับการละเมิดได้ 2 รายการ แต่ไม่ได้ทิ้งรายการใดโดยอัตโนมัติ เพียงส่งขึ้นด่านนักเขียนด้วย WARN เท่านั้น นี่คือหัวใจของการออกแบบที่บอกล่วงหน้าไว้ใน §6.2.1 ถ้ามอบสิทธิ์ปฏิเสธอัตโนมัติให้ตัวตรวจสอบด้วย นักเขียนก็จะกดสวิตช์นั้นลงภายในไม่ถึงหนึ่งสองเดือน เพราะเครื่องจะฆ่าแม้กระทั่งความแปรผันที่ตั้งใจไว้รวมไปด้วย และนักเขียนยังถูกพรากโอกาสที่จะกะเส้นแบ่งนั้นด้วยตัวเองด้วย ฉะนั้นจึงมอบงานคัดกรองตัวเลือกที่น่าสงสัยให้เครื่อง แต่การตัดสินใจครั้งสุดท้ายว่าจะเก็บหรือทิ้งตัวเลือกนั้นยังคงทิ้งไว้ในมือคน

[การตรวจสอบโดยนักเขียนขั้น 4 — การตัดสินและการทิ้ง]

นักเขียนจัดการ alert 2 รายการดังนี้

• Mira Kost → เก็บไว้ ชื่อเหมือนกับ Mira Veldt ของ riverhold แต่คนละเมือง คนละนามสกุล ไม่มีโอกาสปรากฏพร้อมกัน ผ่านในฐานะความแปรผันที่ตั้งใจไว้ (แต่บันทึกแยกไว้ว่าจะให้กฎ forbidden_names เปลี่ยนจาก "ชื่อ+นามสกุลตรงกันทั้งหมด" เป็น "ชื่อชนกันเดี่ยว ๆ ก็ WARN" หรือไม่)
• เกรม → ทิ้ง การที่ voice_lint เชื่อมั่นต่ำคือสัญญาณ อ่านอีกครั้งก็พบว่าตัวละครคนเฝ้าเตาไฟที่พูดว่า "แค่ดูไฟก็พอ" ขัดกับโทน scholarly_strict ของเมือง ถ้า NPC ในเมืองที่กิลด์นักปราชญ์ปกครองหลุดไปทางโทนลึกลับ ตัวตนของเมืองก็จะพร่าเลือน ทิ้งแล้วขอใหม่

หลังจากนักเขียนตัดสินใจทิ้งแล้ว การขอใหม่ก็หมุนหนึ่งรอบ "ทิ้งสล็อตเกรม สร้าง NPC คนเฝ้าเตาไฟที่เข้ากับโทนกิลด์นักปราชญ์ (สังเกต·บันทึก·เข้มงวด) ของพื้นที่ล่าเดียวกันใหม่ ห้ามใช้คำศัพท์เชิงลึกลับ" AI ตอบกลับมาเป็นคนแก่ที่บันทึกอุณหภูมิของเตาไฟบนหอระฆัง มองแม้แต่ไฟเป็นข้อมูล และเอาต์พุตนั้นผ่านด้วย voice_lint 0.81 หนึ่งรอบของ อินพุต → โครง → เนื้อหา → ตรวจสอบ → ทิ้ง → สร้างใหม่ ปิดลงตรงนี้

หนึ่งรอบนี้คือเกณฑ์ Show ของทั้งเล่ม ถ้าไม่เคยดูจนจบสักครั้งว่าเครื่องมือคายอะไร อะไรถูกจับ และคนฆ่าอะไร ประโยคที่ว่า "ผลิตจำนวนมากด้วย AI" ก็กลวงเปล่า

6.2.6 อัตราการทิ้งไม่ใช่ความล้มเหลวของเครื่องมือ แต่เป็นสัญญาณของด่าน

ในรอบข้างต้น NPC ถูกทิ้งไป 1 คน เมื่อมองทั้งเมือง การทิ้งจะสะสมมากขึ้น เวลาตรวจสอบเฉลี่ย 5–10 นาทีต่อเมือง อัตราการทิ้งของ NPC ประมาณ 20% และของเควสต์เสริมประมาณ 33%

ผมขอบอกที่มาของอัตราส่วนนี้อย่างซื่อตรง อัตราการทิ้งเป็นค่าที่นับเองขณะตรวจสอบเมือง 5 แห่งที่รวม silvermark ในช่วงเริ่มนำมาใช้โดยตรง NPC ทิ้งไป 6 คนจากที่ตรวจ 30 คน (20%) เควสต์เสริมทิ้งไป 5 อันจากที่ตรวจ 15 อัน (33%) เนื่องจากตัวอย่างมีเพียง 5 เมืองซึ่งเล็ก จึงควรอ่านมันเป็นค่าบ่งทิศ "หนึ่งในห้า หนึ่งในสาม" มากกว่าจะเป็นสัดส่วนประชากรที่แม่นยำ อัตราสะสมหลังจากตรวจครบทั้ง 30 เมืองอาจต่ำลงกว่านี้ หรือสูงขึ้นตามลักษณะของพื้นที่ล่าก็ได้

สิ่งสำคัญคืออัตราการทิ้ง 0% ไม่ใช่เป้าหมาย การทิ้ง 0% ใกล้เคียงกับสัญญาณว่าการตรวจสอบไหลผ่านไปอย่างเป็นพิธีการ เมื่อ NPC หนึ่งในห้าถูกทิ้งเพราะโทนไม่เข้ากัน และเควสต์เสริมหนึ่งในสามถูกสร้างใหม่เพราะไม่เกาะกับ lore_seeds นั่นคือตอนที่ด่านตรวจสอบทำงานจริง

6.2.7 การวัดผล — เมือง 30 แห่งใน 4\~5 สัปดาห์

เปรียบเทียบก่อนและหลังนำเครื่องมือมาใช้ ค่าเวลาด้านล่างเป็นค่าเฉลี่ยที่วัดจริงของเมืองช่วงแรกที่รวม silvermark ส่วนคอลัมน์ "ก่อนนำมาใช้" เป็นค่าประมาณของนักเขียนในช่วงทำมือก่อนมีเครื่องมือ ไม่มีตัวเลขที่กุขึ้น

ดูแค่ตารางก็เหมือนตัวเลขเป็นทั้งหมด แต่ผลจริงออกมาจากช่องอื่น เมื่อเวลาของนักเขียนที่เกือบถูกผูกไว้กับการผลิตเมืองจำนวนมากถูกปลดปล่อย นักเขียนหนึ่งคนก็เพิ่มผลผลิตเควสต์หลักต่อไตรมาสได้มากขึ้นอย่างมาก (จำนวนเท่าที่แน่นอนต่างกันไปในแต่ละไตรมาส จึงไม่ฟันธง — ทิศทางคือ "ผลผลิตเควสต์หลักเพิ่มขึ้นอย่างชัดเจน") เครื่องมือผลิตจำนวนมากจึงทำงานเป็นเครื่องมือที่ปลดปล่อย ไม่ใช่ดูดกลืน เวลาของนักเขียน (คำเตือนใน §6.1.8 ที่ว่าถ้านักเขียนรู้สึกว่าตนกลายเป็น "ตัวตรวจสอบ" เครื่องมือก็จะถูกปฏิเสธ ใช้ได้ตรง ๆ)

6.2.8 เนื้อหาที่ไม่เข้า generator

แม้ขอบเขตการทำงานอัตโนมัติจะกว้างขึ้น แต่สิ่งต่อไปนี้วางไว้นอกเครื่องมือ

ข้อเท็จจริงที่ว่าผลิตจำนวนมากได้ ไม่ควรนำไปสู่การตัดสินใจที่ว่าต้องผลิตจำนวนมากโดยอัตโนมัติ อย่างที่เห็นในรอบ silvermark เครื่องมือผลิต NPC ได้ดีถึง 5 คนจาก 6 คน แต่ NPC ซิกเนเจอร์หนึ่งคนที่ต้องแบกความตึงเครียดหลักของเมืองนั้นที่ว่า 'การผนึกกำลังเย็นลง' นักเขียนปั้นด้วยมือเอง เมื่อขอบเขตของการทำงานอัตโนมัติชัดเจน เครื่องมือผลิตจำนวนมากก็กลับกลายเป็นเครื่องมือที่ปกป้องพื้นที่หัวใจนั้นแทน

6.2.9 ความล้มเหลวที่พบบ่อยห้าอย่าง

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

6.2.10 ลองทำดู — หนึ่งขั้นที่ทำได้วันนี้

ถ้าทำคนเดียวก็แค่เท่านี้: ไม่ต้องมีโค้ดรูลบุ๊กก็ได้ เลือกเมือง·พื้นที่ 1 แห่งจากเกมของคุณ (หรือเกมที่คุณชอบ) แล้วเขียนเมตาดาตาในรูปแบบ §6.2.2 ด้วยมือ (lore_seeds 3 อันคือหัวใจ) คัดลอกพรอมต์ข้อความแนะนำของ §6.2.4 ไปวางตามนั้นแล้วลองหมุนหนึ่งครั้ง จาก NPC ที่ออกมา ลองเลือกคนหนึ่งที่โทนไม่เข้าด้วยตัวเองแล้วโต้แย้งว่า "NPC คนนี้ขัดกับโทนของเมือง ทิ้งแล้วทำใหม่" คุณจะรู้สึกได้ด้วยตัวเองว่าด่านตรวจสอบคือกลุ่มของการตัดสินใจแบบไหน

ถ้าเป็นทีม ขอให้เริ่มด้วยหนึ่งขั้นต่อไปนี้ สร้างแบบฟอร์ม yaml เมตาดาตาหนึ่งหน้าและสคริปต์แนบ forbidden_names อัตโนมัติก่อน โครงรูลบุ๊ก (generate_skeleton) และ lint เป็นลำดับถัดไป แค่มีแบบฟอร์มอินพุตและการตรวจชื่อซ้ำสองอย่าง ก็ป้องกันความล้มเหลวที่พบบ่อยสองอย่างซึ่งทำให้การผลิตเนื้อหาด้วย AI พังลงเป็น "หมู่บ้านคล้ายกัน 30 แห่ง" ได้ก่อนแล้ว

6.2.11 ตัวอย่างบทถัดไป

ใน 6.3 จะกล่าวถึงไปป์ไลน์ NPC Persona/Squad ถ้า generator ของ 6.2 ผลิต NPC อย่างโดเรน·มิราเป็นรายตัว Persona/Squad จะมัด NPC เหล่านั้นเข้าเป็นกลุ่ม เป็นวิธีทำให้ NPC ห้าคนของพื้นที่ล่าหนึ่งจุดทำงานเป็นสังคมเล็ก ๆ ไม่ใช่กองตุ๊กตาที่ไม่เกี่ยวข้องกัน

สรุปประเด็นสำคัญของบท

• ขั้น 1·3 เป็นรูลบุ๊ก (เชิงกำหนด) มีแต่ขั้น 2 ที่เป็น AI — คนทำแค่อินพุตและด่านตรวจสอบเท่านั้น
• ต้องดูเอาต์พุต·การตรวจสอบ·การทิ้งจนจบสักหนึ่งครั้ง "การผลิตจำนวนมากด้วย AI" จึงจะไม่กลวงเปล่า
• อัตราการทิ้ง 20·33% ไม่ใช่ความล้มเหลวของเครื่องมือ แต่เป็นสัญญาณว่าด่านทำงาน

ตัวอย่างบทถัดไป

• 6.3 ไปป์ไลน์ NPC Persona/Squad

6.3 NPC Persona และ Squad — จากพิพิธภัณฑ์ตุ๊กตาสู่สังคมเล็ก ๆ

ผู้อ่านหลัก: นักออกแบบเกม MMORPG ที่รับผิดชอบเนื้อหา NPC และจุดล่ามอนสเตอร์ (ทีมขนาดกลาง 10–50 คน) เวอร์ชันย่อสำหรับผู้อ่านคนเดียว/งานอดิเรก: §6.3.10 「ถ้าทำคนเดียว แค่นี้พอ」

ผู้เขียนมีความทรงจำของวันที่ใช้ generator ในหัวข้อ 6.2 ปั๊ม NPC ห้าตัวลงในจุดล่ามอนสเตอร์แห่งหนึ่งแล้วลองเปิดเข้าไปในเกมจริง ชื่อ รูปร่างหน้าตา และภูมิหลังสั้น ๆ ถูกเติมครบหมดแล้ว เหลือแค่กดพิกัดวางตำแหน่ง แต่พอลองเดินไปในจุดล่ามอนสเตอร์นั้นจริง ๆ มันกลับให้ความรู้สึกตายแปลก ๆ ห้าคนอยู่ในพื้นที่เดียวกันแต่ไม่เคยเอ่ยถึงกันสักครั้ง สองคนยืนซ้อนกันอยู่บนหินก้อนเดียวกัน ตรงนั้นต้องการคนที่รับบทพ่อค้า แต่ทั้งห้าคนกลับเป็นนักวิชาการหมด ทั้งโดเรนและมิราต่างก็เป็น NPC ที่ดูปกติดีเมื่อแยกเป็นรายตัว แต่พอเอามามัดรวมกัน มันก็กลายเป็นแค่กองตุ๊กตา

นี่คือสภาพ "พิพิธภัณฑ์ตุ๊กตา" NPC แต่ละตัวสร้างเสร็จหมดแล้ว แต่ไม่ได้มีชีวิตในฐานะกลุ่ม บทนี้ว่าด้วยไปป์ไลน์ที่มัดห้าคนนั้นให้กลายเป็นสังคมเล็ก ๆ การแยกแกนหลักคือ Persona และ Squad ถ้าเปรียบเป็นออฟฟิศ Persona คือนามบัตรของพนักงานแต่ละคน ส่วน Squad คือผังองค์กรของทีมหนึ่ง ต่อให้กองนามบัตรไว้ 50 ใบ แต่ถ้าไม่มีผังองค์กร บริษัทก็เดินไม่ได้ และกระดูกสันหลังของบทนี้คือขั้นตอนสุดท้าย นั่นคือจุดที่เราตรวจสอบร่วมกับ AI จนจบหนึ่งรอบว่ากลุ่มที่มัดรวมกันแล้ว "พูดและขยับเหมือนคนที่รู้จักกัน" หรือไม่

บันทึกการใช้งานจริงของผู้เขียน ไปป์ไลน์ Squad ในบทนี้เป็นการนำเครื่องมือ NPC Persona/Squad ที่ผู้เขียนใช้งานอยู่ในโฟลเดอร์ R&D ของบริษัทมาทำให้ไม่ระบุตัวตน โครงสร้าง yaml รายการตรวจสอบ และค่าขีดแบ่ง voice_lint ถ่ายทอดมาจากเครื่องมือจริงอย่างซื่อตรง ส่วนชื่อเมืองและชื่อ NPC เปลี่ยนให้เป็นเวอร์ชันสำหรับหนังสือเหมือนกับในหัวข้อ 6.2 เนื้อหาผลลัพธ์เป็นการเรียบเรียงใหม่จากเซสชันจริง

6.3.1 Persona คือนามบัตร, Squad คือผังองค์กร

Persona คืออัตลักษณ์ของ NPC แต่ละตัว บรรจุชื่อ รูปร่างหน้าตา voice_profile และบทบาท สิ่งที่ generator ในหัวข้อ 6.2 สร้างขึ้นก็คือ Persona โดเรน เวล และมิรา คอสต์ ต่างเป็น Persona หนึ่งตัว

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

ถ้าไม่แยกสองสิ่งนี้ออกจากกัน จะมีสองอย่างที่ตันพร้อมกัน ถ้าปั๊มแต่ Persona ก็จะกลายเป็นพิพิธภัณฑ์ตุ๊กตา แต่ถ้าพยายามเริ่มจาก Squad ก็จะไม่มี Persona ให้เติม เมื่อแยกออกจากกันแล้ว การดำเนินงานของแต่ละหน่วยจะเรียบง่ายขึ้น แต่การแยกไม่ได้หมายถึงการตัดขาด หัวใจคือการวางเส้นทางสำหรับการนำกลับมาใช้ซ้ำและการตรวจสอบไว้ระหว่างสองหน่วย และนี่คือเนื้อหาหลักของบทนี้

การแยกแกน Persona→Squad นี้ไม่ใช่แค่การจัดระเบียบ แต่เปิดทางไปได้ไกลกว่านั้น กลุ่ม NPC ต้องถูกทำให้เป็นรูปแบบมาตรฐานด้วยบทบาท ความสัมพันธ์ และค่าตัวเลขเสียก่อน ภายหลังสถานะของโลก (การสะสมพฤติกรรมของผู้เล่น) จึงจะสามารถสั่นค่าตัวเลขของ NPC ได้ และค่าตัวเลขนั้นก็กลายเป็นเงื่อนไขการเกิดเควสต์ ไปจนถึงการตอบสนองแบบพลวัตได้ บทนี้แตะแค่ทางเข้าของการประยุกต์เชิงก้าวหน้านั้น และในแนวทางหลักจะกล่าวถึงเพียง "การปั๊มแบบอนุรักษ์นิยมที่มีคนตรวจสอบ" เท่านั้น

6.3.2 อินพุต — เมตาดาตา Squad หนึ่งหน้า

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

# city_021_hg_3.squad.yaml
squad_id: city_021_hg_3_squad
hunting_ground: city_021_silvermark_hg_3
type: hunting_ground_residents
size: 5
roles:
  - role: quest_giver
    count: 1
    voice_traits: [authoritative, scholarly]
  - role: lore_keeper
    count: 1
    voice_traits: [scholarly, withdrawn]
  - role: merchant
    count: 1
    voice_traits: [practical, dry]
  - role: bystander
    count: 2
    voice_traits: [varied]
relationships:
  - between: [quest_giver, lore_keeper]
    type: mentor_and_former_student
  - between: [merchant, bystander_1]
    type: regular_customer
movement_pattern: stationary_with_shifts

สล็อตที่สำคัญที่สุดคือ relationships ถ้าความสัมพันธ์เป็น 0 รายการ ห้าคนก็จะเป็นคนแปลกหน้าต่อกันจนจบ แต่ถ้าความสัมพันธ์มากเกินไป (ห้าคนมีตั้งแต่ห้ารายการขึ้นไป) ผู้ใช้จะต้องจำเยอะจนกลับกลายเป็นว่ามันจมหายไป จากประสบการณ์ของผู้เขียน Squad ห้าคนที่มีความสัมพันธ์หลัก 2–3 รายการเป็นช่วงที่เสถียรที่สุด ส่วน voice_traits คือกลไกที่จับให้ห้าคนมีน้ำเสียงต่างกัน ถ้าเติม scholarly ให้ทั้งห้าคน ก็จะติดที่ขั้นตอนตรวจสอบเพราะ voice ถูกปรับให้เท่ากันหมด

6.3.3 ขั้น 1·2 — โครงร่าง rulebook และการเติม Persona

rulebook จับมาตรฐานของโครงร่าง Squad ก่อนเป็นอันดับแรก ค่าเริ่มต้นของขนาด การกระจายบทบาท ความหนาแน่นของความสัมพันธ์ และรูปแบบเส้นทางเดิน ตามแต่ละ region·type ของจุดล่ามอนสเตอร์ถูกป้อนไว้ในโค้ดแล้ว

# npc_squad/templates.py (발췌)
SQUAD_TEMPLATES = {
    ("west", "hunting_ground_residents"): {
        "size_range": (4, 6),
        "role_distribution": {
            "quest_giver": 1,
            "merchant": 1,
            "lore_keeper": (0, 1),
            "bystander": (1, 3),
        },
        "relationship_density": 2,        # จำนวนความสัมพันธ์ที่แนะนำ
        "movement_pattern": "stationary_with_shifts",
    },
    ("east", "outpost_squad"): {
        "size_range": (3, 4),
        "role_distribution": {
            "commander": 1,
            "scout": 1,
            "support": (1, 2),
        },
        "relationship_density": 1,
        "movement_pattern": "patrol_loop",
    },
}

ขั้นตอนนี้เป็นเชิงกำหนด (deterministic) Squad ผู้อยู่อาศัยฝั่งตะวันตกที่มี quest_giver ครบทั้งห้าคนเป็นเรื่องที่เป็นไปไม่ได้ในระดับโค้ด ถ้าการกระจายบทบาทออกนอก rule ก็จะถูกหยุดทันทีตรงนั้น

ถัดมาคือการเติม Persona ลงในแต่ละสล็อต มีอยู่สามทาง ถ้ามี Persona ในพูลที่เข้ากับสล็อต ก็นำกลับมาใช้ซ้ำ (น้ำหนักการปรากฏตัว +1) ถ้าไม่มีก็สร้างใหม่ด้วย generator ในหัวข้อ 6.2 และถ้าเป็นตัวละครหลักของเควสต์หลัก นักเขียนก็เขียนเองโดยตรง Squad hg_3 ของ silvermark เติม quest_giver·lore_keeper ด้วยมิราและโดเรนที่ปั๊มไว้แล้วในหัวข้อ 6.2 แล้วดึง merchant กับ bystander อีกสองคนมาใหม่ ถึงตรงนี้เหมือนกับรอบ generator ของหัวข้อ 6.2 งานจริง ๆ ของบทนี้คือสิ่งที่ตามมา นั่นคือจุดที่ตรวจสอบว่ากลุ่มที่มัดรวมกันแล้วทำงานเหมือนกลุ่มจริง ๆ หรือไม่

6.3.4 ทำหนึ่งรอบให้จบ — เสริมความสัมพันธ์·เส้นทางเดิน·ตรวจสอบความสอดคล้อง

ถ้าเขียนเพียงนามธรรมว่า "AI เสริมความสัมพันธ์" ก็จะไม่รู้ว่าไปป์ไลน์นี้คายอะไรออกมา เราจะตามรอบครึ่งหลังของ Squad silvermark hg_3 หนึ่งหน่วยให้จบสักครั้ง ตั้งแต่การสร้างข้อความความสัมพันธ์ไปจนถึงการทิ้งและการขอใหม่

ขั้น 3 — AI เสริมความสัมพันธ์

แท็กความสัมพันธ์ที่ป้อนไว้ในโครงร่าง Squad (mentor_and_former_student) เป็นนามธรรม จึงมองไม่เห็นในเกม การเปลี่ยนสิ่งนี้ให้เป็นคำบรรยายหนึ่งบรรทัดแล้วฝังลงในบทพูดของ NPC และอีเวนต์คือขั้น 3 พรอมต์อยู่ในรูปที่สามารถคัดลอกไปใช้ได้ทันที

[L0 บริบท] world_premise + tone_manifesto  (แคชชิง)
[L1 บริบท] city_021_silvermark.lore (สมาคมนักวิชาการครอบครอง, scholarly_strict)
[Persona 1] quest_giver — มิรา คอสต์, บรรณารักษ์คลังเอกสารสมาคม, วัย 30 ปลาย ๆ, รอยหมึกเปื้อน
[Persona 2] lore_keeper — โดเรน เวล, ผู้ช่วยสังเกตการณ์หอระฆัง, วัย 50, สนทนาด้วยตัวเลขเท่านั้น
[แท็กความสัมพันธ์] mentor_and_former_student

ช่วยบรรยายความสัมพันธ์ของสองคนนี้ (อาจารย์–อดีตลูกศิษย์) เป็นภูมิหลังสำหรับใช้ในบทพูดในเกม แค่ 1–2 บรรทัด
โดเรนคือตัวเลข มิราคือเอกสาร — ให้สำนวนการพูดของทั้งสองไม่ปะทะกัน โทนเป็นแบบนักวิชาการเคร่งครัด
ตัดถ้อยคำซ้ำซากอย่างความลึกลับหรือ "เพื่อนเก่า" ออก เอาเฉพาะเนื้อความ

[ขั้น 3 ผลลัพธ์ AI — ความสัมพันธ์หนึ่งบรรทัด] (เรียบเรียงใหม่จากเซสชันจริง)

โดเรนสอนวิธีเขียนสัญลักษณ์ของบันทึกการสังเกตการณ์แท่นผนึกให้มิราเมื่อ 20 ปีก่อน ทุกวันนี้สถานะกลับด้าน โดเรนเป็นคนวัดค่าตัวเลข แล้วมิราเป็นคนคัดลงสมุดบัญชีของคลังเอกสาร ทั้งสองจะถกเถียงกันสั้น ๆ ทุกวันอังคารเรื่องช่องหนึ่งที่ค่าจากการสังเกตการณ์ไม่ตรงกับสมุดบัญชี

ผลลัพธ์นี้ดี mentor_and_former_student ถูกทำให้เป็นรูปธรรม "ตัวเลข" ของโดเรนกับ "เอกสาร" ของมิราถูกมัดเข้าด้วยกันในฉากเดียว (การคัดค่าตัวเลขลงสมุดบัญชี) โดยไม่ปะทะกัน และโทน scholarly_strict ก็ยังคงอยู่ พรอมต์เดียวกันนี้นำมาทำซ้ำกับความสัมพันธ์ regular_customer ของ merchant–bystander_1 ด้วย

ขั้น 4 — สังเคราะห์เส้นทางเดิน

ถ้า NPC ยืนอยู่ที่เดียวทั้งวัน มันก็กลายเป็นตุ๊กตาอีกครั้ง rulebook เป็นตัวเติมรูปแบบเส้นทางเดิน stationary คือยืนตรึงที่เดียว (ยาม·บอส) stationary_with_shifts คือเปลี่ยนตำแหน่งเล็กน้อยทุก 8 ชั่วโมง (ทั่วไป) routine_loop คืออิงตารางเวลา (ผู้อยู่อาศัย) event_driven คือเคลื่อนที่เฉพาะตอนถูกทริกเกอร์ (NPC เควสต์) ขั้นตอนนี้เป็นเชิงกำหนดจึงไม่เรียก AI

ขั้น 5 — lint ความสอดคล้องของ Squad (ด่านตรวจสอบของไปป์ไลน์นี้)

ตอนนี้เราตรวจว่าห้าคนที่มัดรวมกันแล้วทำงานเหมือนกลุ่มจริง ๆ หรือไม่ ถ้า lint ในหัวข้อ 6.2 ดู NPC รายตัว lint ตัวนี้ดูความสอดคล้องของกลุ่ม

[ขั้น 5 ผลลัพธ์ Squad lint] (รูปแบบจริง)

[PASS] การกระจายบทบาท: quest_giver 1 · lore_keeper 1 · merchant 1 · bystander 2 (ตรงตาม rule)
[PASS] ความหนาแน่นความสัมพันธ์: 2 รายการ (แนะนำ 2, ตรงตาม)
[WARN] ความหลากหลายของ voice: สาย scholarly 3/5 — quest_giver·lore_keeper·bystander_2
       มีค่าความคล้ายเชิงโคไซน์ของ voice_profile 0.83 (เกินขีด 0.80) เสี่ยงถูกปรับให้เท่ากัน
[WARN] เส้นทางเดินชนกัน: ช่วง 14:00~16:00 พิกัดของ merchant·bystander_1 ซ้อนทับในรัศมี 1.5m
[FAIL] การเปิดเผยความสัมพันธ์: นิยามความสัมพันธ์ไว้ 2 รายการ แต่ในบทพูดของทั้งห้าคนไม่มีการเอ่ยถึงสมาชิกคนอื่นเลยสักครั้ง
       ความสัมพันธ์มีอยู่แค่ในข้อมูล — การมองเห็นในเกมเป็น 0

lint จับได้สามรายการ ทั้งสามไม่ถูกทิ้งโดยอัตโนมัติ แต่ยกขึ้นด่านตรวจสอบ — เครื่องเป็นคนคัดผู้ต้องสงสัย แต่คนเป็นคนตัดสินว่าจะฆ่าหรือไว้ชีวิต ซึ่งเป็นการออกแบบแบบเดียวกับ §6.2.5

[ขั้น 6 การตรวจสอบโดยนักเขียน — การตัดสินและการทิ้ง]

นักเขียนจัดการ alert ทั้งสามรายการดังนี้

• voice ถูกปรับให้เท่ากัน (WARN) → ทิ้ง bystander_2 ต่อให้เป็นเมืองนักวิชาการ ถ้าทั้งห้าคนพูดสำนวนนักวิชาการหมด จุดล่ามอนสเตอร์ก็จะจืดชืด จึงขอสร้าง bystander_2 ใหม่เป็นคนงานเบ็ดเตล็ดโทน practical, dry (การที่ quest_giver·lore_keeper เป็นนักวิชาการทั้งคู่เป็นอัตลักษณ์ของเมือง จึงคงไว้)
• เส้นทางเดินชนกัน (WARN) → ปรับ rule เลื่อนออฟเซ็ตเริ่มต้น shift ของ merchant ออกไป +2 ชั่วโมง เพื่อแก้การซ้อนทับตอน 14:00 ปรับเฉพาะพารามิเตอร์เส้นทางเดินโดยไม่เรียก AI
• การเปิดเผยความสัมพันธ์เป็น 0 (FAIL) → รายการที่สำคัญที่สุด นิยามความสัมพันธ์ไว้ตั้งสองรายการ แต่ถ้าในเกมไม่ปรากฏให้เห็นสักครั้ง ข้อมูลนั้นก็เป็นข้อมูลที่ตายแล้ว นักเขียนตัดสินใจเลือกความสัมพันธ์หลัก 1 รายการ (โดเรน–มิรา) แล้วฝังลงในบทพูด

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

ช่วยแทรกบทพูดของโดเรนหนึ่งบรรทัดที่ความสัมพันธ์กับมิราปรากฏออกมาแบบหลุดลอย ๆ
อย่าเป็นเชิงอธิบาย ให้เป็นแบบกิ่งก้านข้าง ๆ โทนนักวิชาการ เอาบทพูดแค่บรรทัดเดียว

[ผลลัพธ์จากการขอใหม่]

"แบบแปลนนั่นอยู่ในคลังเอกสาร ไปถามมิราดู ...เมื่อ 20 ปีก่อนข้านี่แหละที่สอนวิธีอ่านให้คนนั้น เดี๋ยวนี้มันกลับตาลปัตรเสียแล้ว"

ขณะที่บรรทัดนี้เข้าไป ความสัมพันธ์ของ NPC สองตัวก็ย้ายจากชีตข้อมูลมาสู่หน้าจอเกม หนึ่งรอบของ อินพุต (เมตา Squad) → โครงร่าง → การเติม Persona → การเสริมความสัมพันธ์ → เส้นทางเดิน → การตรวจสอบความสอดคล้อง → การตัดสินใจทิ้ง·เปิดเผย ปิดลงที่ตรงนี้

หนึ่งรอบนี้คือเกณฑ์ Show ของบทนี้ ประโยคที่ว่า "มัด NPC ให้เป็นสังคมด้วย Squad" จะกลวงเปล่า หากไม่ได้เห็นฉากที่คนปิด FAIL การเปิดเผยความสัมพันธ์ที่เป็น 0 ด้วยบทพูดหนึ่งบรรทัดแม้สักครั้ง

6.3.5 ภาพรวมทั้งหมดของ Persona→Squad

ขอใส่รอบข้างต้นไว้เป็นภาพเดียว หัวใจคือ ขั้น 1·2·4·5 เป็นเชิงกำหนด (rulebook·lint) และมีเพียงขั้น 3 เท่านั้นที่เป็น AI อีกทั้งมือของคนแตะแค่ที่อินพุตบนสุดและด่านตรวจสอบล่างสุดเท่านั้น

flowchart TB
    P["พูล Persona
(ผลผลิตจาก generator 6.2)
โดเรน·มิรา·..."] --> FILL
    A["อินพุต: เมตาดาตา Squad
(คน 10~15 นาที/จุดล่ามอนสเตอร์)
การกระจายบทบาท · เจตนาความสัมพันธ์ 2~3 รายการ"]
    A --> B["ขั้น 1 เชิงกำหนด: templates.py
มาตรฐานการกระจายบทบาท·ความหนาแน่นความสัมพันธ์·เส้นทางเดิน"]
    B --> FILL["ขั้น 2: การเติม Persona
นำกลับมาใช้ซ้ำ / generator / นักเขียนเขียนเอง"]
    FILL --> C["ขั้น 3 AI: เสริมความสัมพันธ์หนึ่งบรรทัด
L0 แคชชิง + ตรวจการปะทะของ voice_traits"]
    C --> D["ขั้น 4 เชิงกำหนด: สังเคราะห์เส้นทางเดิน
shift·routine·event_driven"]
    D --> E{"ขั้น 5 เชิงกำหนด: Squad lint
การกระจายบทบาท·ความหลากหลาย voice
·เส้นทางเดินชน·การเปิดเผยความสัมพันธ์"}
    E -->|"alert"| F["ขั้น 6 ด่านตรวจสอบโดยนักเขียน
(5~10 นาที/จุดล่ามอนสเตอร์)
ตัดสินใจทิ้ง·ปรับ rule·เปิดเผยความสัมพันธ์"]
    F -->|"ขอใหม่"| C
    F -->|"ผ่าน"| G["นำเข้าบิลด์"]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class B,D,E code;
    class C ai;
    class A,F human;
    class P data;
    class G pass;

จุดที่มือคนแตะมีแค่สองแห่ง จุดที่จับเจตนาบทบาท·ความสัมพันธ์ที่บนสุด กับจุดที่ตัดสินโทน·การเล่าเรื่องที่ lint จับไม่ได้ที่ล่างสุด ส่วนระหว่างนั้น โครงร่าง·เส้นทางเดิน·การตรวจสอบเป็นงานของ rulebook ส่วนเนื้อความความสัมพันธ์ AI เป็นตัวรัน

6.3.6 สามกลไกที่ทำให้ความสัมพันธ์มองเห็นในเกม

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

หนึ่ง การอ้างอิงในบทพูด เหมือนบทพูดของโดเรนใน §6.3.4 ที่ NPC เอ่ยถึงสมาชิกคนอื่นหนึ่งบรรทัด ถูกที่สุดและได้ผลมากที่สุด

สอง การตัดกันของเส้นทางเดิน ฉากที่โดเรนกับมิราอยู่ในคลังเอกสารด้วยกันทุกวันอังคารถูกสังเกตเห็นในเกม ถ้าผู้ใช้บังเอิญเห็นก็จะรู้ทันว่า "สองคนนั้นเกี่ยวพันกันหรือเปล่า" ถ้าเส้นทางเดินขั้น 4 กับความสัมพันธ์สอดคล้องกัน มันก็ออกมาเองตามธรรมชาติ

สาม เงื่อนไขกิ่ง ถ้าปฏิเสธคำขอของ quest_giver ค่าความพอใจของ lore_keeper ก็จะลดลงไปด้วย กลไกที่สามนี้คือทางเข้าของการประยุกต์เชิงก้าวหน้าที่กล่าวไว้ใน §6.3.1 — จุดที่ความสัมพันธ์ก้าวข้ามการบรรยายแบบเรียบ ๆ ไปสู่การส่งผลต่อสถานะของเกม

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

6.3.7 การวัดผล — อย่างซื่อตรง

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

เนื่องจากตัวอย่างมีเพียงจุดล่ามอนสเตอร์ไม่กี่แห่งซึ่งน้อย จึงควรอ่านเป็นค่าทิศทางมากกว่าสัดส่วนประชากรที่แม่นยำ การเปลี่ยนแปลงที่ใหญ่ที่สุดไม่อยู่ในตาราง เพราะ FAIL การเปิดเผยความสัมพันธ์ ของ lint บังคับยื่นใส่หน้านักเขียนว่า "จุดล่ามอนสเตอร์นี้ ไม่เห็นความสัมพันธ์เลยสักอย่าง" การที่ผลผลิตปั๊มออกวางขายในสภาพพิพิธภัณฑ์ตุ๊กตาจึงลดลงในเชิงโครงสร้าง ประเด็นที่ว่าการทิ้ง 0%·การเปิดเผย 0 รายการไม่ใช่เป้าหมาย (§6.2.6) ก็เป็นเช่นเดียวกันที่นี่ Squad ดูดซับงานมัดส่วนใหญ่ไป แต่ต้องเหลือเวลาให้นักเขียนได้ปั้นหัวใจอย่างบทพูดบรรทัดสุดท้ายของโดเรนด้วยตัวเองด้วย

6.3.8 พูล Persona — เมื่อคนเดียวกันปรากฏในหลายเมือง

เมื่อ Squad เสถียรแล้ว สิ่งที่ตามมาเองตามธรรมชาติคือพูล Persona Persona เดียวกันสามารถปรากฏในหลายเมืองได้ การที่ NPC สังกัดสมาคมนักวิชาการถูกพบเจอในเมืองสามสี่แห่งกลับเป็นเรื่องธรรมชาติ ไม่ใช่ทำให้โลกดูแคบ แต่ทำให้ดูเชื่อมโยงกัน

persona_pool:
  - id: persona_doren_vale
    voice_traits: [terse, numeric]
    appearance_count: 3
    appearance_cities: [city_021, city_018, city_023]
    signature: false
  - id: persona_mira_kost
    voice_traits: [scholarly, withdrawn]
    appearance_count: 2
    signature: false

สัดส่วนการนำกลับมาใช้ซ้ำมีช่วงที่ดีต่อสุขภาพอยู่

แต่ถ้าให้ NPC ตัวหนึ่งปรากฏในเมืองมากเกินไป ก็จะกลายเป็น "คนนี้โผล่มาอีกแล้ว" เมืองที่ Persona หนึ่งตัวปรากฏได้มากที่สุดกำหนดเพดานไว้ที่ 5 แห่ง ห้องบอส·ตัวละครซิกเนเจอร์ห้ามนำกลับมาใช้ซ้ำ (signature: true) ตั้งแต่การปรากฏครั้งที่สองของ Persona เดียวกัน บังคับให้มีการแปรผันทางสายตา (แสง·พร็อพ) ช่วง 30\~50% นี้ไม่ใช่ค่าตัวเลขที่แม่นยำ แต่เป็นแนวทางการดำเนินงาน — ต้องปรับตามขนาดทีม·เกม

[ป้ายชี้ทิศ — ถ้ามองพูลเปอร์โซนาเป็นการกระจายตัว (ตอนนี้ยังเร็วเกินไป)] ถ้าเป็นทีมที่พูลใหญ่ขึ้นถึงหลายร้อย NPC ก็มีทิศทางที่ก้าวไปอีกก้าว — เป็นป้ายชี้ทิศที่อยู่ตำแหน่งเดียวกับหัวข้อ 'เวกเตอร์เชิงมิติ' ใน §8.2.7 (ไม่ใช่ใบสั่งยา — สัญชาตญาณเชิงแนวคิดอยู่ในภาคผนวก M) voice_lint ใน §6.3.4 ดู 'ความใกล้' ของ Persona สองตัวด้วยค่าความคล้ายเชิงโคไซน์ (ค่าอย่าง 0.83) อยู่แล้ว ถ้านำ embedding เดียวกันนี้ขึ้นทั้งพูล ก็จะวินิจฉัยความน่าเบื่อได้ด้วยความหนาแน่นของการกระจายแทนความรู้สึกของนักเขียน — สภาพที่ 'สำนวนนักวิชาการกระจุกอยู่มุมเดียวกันเป็นกอง' จะเห็นเป็นความหนาแน่นของจุดในบริเวณนั้น เมื่อนั้นแทนที่จะปั๊ม 'นักวิชาการคล้าย ๆ กันอีกตัว' ลงในบริเวณความหนาแน่นต่ำ ก็จะเปิดทางให้เติมการแปรผันที่ประมาณค่าระหว่าง Persona สองตัวที่ใกล้กันเข้ามาเพื่อเติมความหลากหลาย แต่มีจุดที่ต้องระวังสองข้อในลมหายใจเดียวกัน Persona ที่ได้จากการประมาณค่ามักกลายเป็น 'ค่ากลางที่ตายแล้ว' ซึ่งเอา NPC สองตัวมาผสมกันอย่างขัดเขิน สุดท้ายคนต้องมาชุบชีวิต voice ขึ้นใหม่อยู่ดี และสัดส่วนความน่าเบื่อข้างต้น (30\~50%) ไม่ใช่ค่าที่แม่นยำ แต่เป็นแนวทางการดำเนินงาน พอแปลงมันเป็นระยะ embedding เมื่อใด ความหลวมก็มีความเสี่ยงที่จะแอบแฝงตัวให้ดูเหมือนแม่นยำ — ค่าระยะทางเป็นสัญญาณที่ช่วยการตัดสินของนักเขียน ไม่ใช่ตัวการตัดสินเอง

6.3.9 ความล้มเหลวที่พบบ่อยหกแบบ

แบบที่สี่ถูกมองข้ามบ่อยที่สุด การนิยามความสัมพันธ์กับการทำให้ความสัมพันธ์มองเห็นในเกมเป็นคนละงาน และถ้าไม่ตรวจ อย่างหลังก็มักจะหายไปแทบทุกครั้ง ถ้า lint ไม่ได้ยื่นการเปิดเผยความสัมพันธ์ 0 รายการเป็น FAIL ใส่ใน silvermark hg_3 โดเรนกับมิราก็คงเป็นอาจารย์–ลูกศิษย์กันแค่ในชีตข้อมูลเท่านั้น

6.3.10 ลองทำดู — หนึ่งขั้นที่ทำได้วันนี้

ถ้าทำคนเดียว แค่นี้พอ: ไม่ต้องมี rulebook หรือ lint ก็ได้ ลองเลือก NPC 3–5 ตัวที่อยู่ในสถานที่หนึ่งของเกมตัวเอง (หรือเกมที่คุณชอบ) แล้วเขียนบทบาทและความสัมพันธ์ 2 รายการลงมือด้วยตัวเองตามรูปแบบใน §6.3.2 จากนั้นแปะพรอมต์เสริมความสัมพันธ์ใน §6.3.4 ลงไปตรง ๆ เพื่อรับคำบรรยายหนึ่งบรรทัด และสุดท้ายลองถามตัวเองดู — "ความสัมพันธ์นี้ตอนนี้เห็นได้ที่บทพูดตรงไหนของเกม" ถ้าไม่มีสักที่ นั่นแหละคือ FAIL การเปิดเผยความสัมพันธ์ 0 ของ lint ถ้าลองแทรกสมาชิกคนอื่นลงในบทพูดของ NPC ตัวหนึ่งหนึ่งบรรทัดเพื่อปิด FAIL นั้นด้วยมือ คุณจะเข้าใจถึงเนื้อตัวว่าการตรวจสอบ Squad เป็นงานที่จับอะไร

ถ้าเป็นทีม ให้เริ่มจากหนึ่งขั้นต่อไปนี้ สร้างฟอร์ม yaml เมตาดาตา Squad หนึ่งหน้า และเริ่มจาก การเปิดเผยความสัมพันธ์ ของ lint ขั้น 5 หนึ่งบรรทัด ก่อน (grep ว่าในข้อความบทพูดของ NPC แต่ละตัวมีชื่อ·บทบาทของสมาชิกคนอื่นปรากฏหรือไม่) การตรวจการกระจายบทบาท·การตรวจเส้นทางเดินชนเป็นเรื่องถัดไป แค่มีการตรวจการเปิดเผยความสัมพันธ์เพียงอย่างเดียว ก็กันความล้มเหลวที่พบบ่อยที่สุด คือการที่จุดล่ามอนสเตอร์ที่ปั๊มออกมาวางขายในสภาพพิพิธภัณฑ์ตุ๊กตาได้ก่อนแล้ว

ถ้าสรุปเป็น setup → prompt → verify — setup: นิยามบทบาท·ความสัมพันธ์ลงใน yaml เมตา Squad แล้วจับโครงร่างด้วย templates.py prompt: รับความสัมพันธ์หนึ่งบรรทัดตามรูปแบบ §6.3.4 โดยบังคับห้าม voice_traits ปะทะกันและห้ามถ้อยคำซ้ำซาก verify: รัน lint ขั้น 5 เพื่อยืนยัน FAIL การเปิดเผยความสัมพันธ์ แล้วฝังความสัมพันธ์หลัก 1 รายการลงในบทพูดเพื่อปิดด้วยตัวเอง

สรุปประเด็นสำคัญของบท

• Persona คือนามบัตร, Squad คือผังองค์กร — ต้องแยกออกจากกัน พิพิธภัณฑ์ตุ๊กตาจึงจะกลายเป็นสังคม
• ต้องดูการเสริมความสัมพันธ์·เส้นทางเดิน·การตรวจสอบความสอดคล้องให้จบสักครั้ง คำว่า "มัดให้เป็นสังคม" จึงจะไม่กลวงเปล่า
• การที่คนปิด FAIL การเปิดเผยความสัมพันธ์ 0 ด้วยบทพูดหนึ่งบรรทัด คือหัวใจของไปป์ไลน์นี้

ตัวอย่างบทถัดไป

• 6.4 เวิร์กโฟลว์การปั๊มเนื้อหา — มัดการสร้าง Persona·Squad·เมืองเข้าด้วยกันเป็นรอบ 1 สัปดาห์

6.4 เวิร์กโฟลว์การผลิตเนื้อหาจำนวนมาก — ร้อย generator หลายตัวเข้าเป็นไลน์เดียว

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

เมือง port_harman ถูกสร้างขึ้นเป็น "หมู่บ้านประมงที่ล่มสลาย" แต่เพอร์โซนาของ NPC ที่ถูกวางไว้ในเมืองนั้นกลับเป็น "พ่อค้าผู้มั่งคั่งแห่งเมืองท่าการค้าที่รุ่งเรือง" เป็นเพราะ generator เมืองกับ generator NPC มอง lore_seeds คนละชุดกัน ส่วน generator อาวุธก็เอาอาวุธในตำนานระดับเลเวล 40 ไปวางขายในร้านค้า ทั้งที่เลเวลแนะนำของเมืองนั้นคือ 12–18 เครื่องมือทั้งสามตัวต่างทำถูกในแบบของตัวเอง แต่กลับผิดเพราะไม่ได้ถูกร้อยเข้าด้วยกัน

บทนี้ไม่ใช่เรื่องของการสร้างเครื่องมือตัวเดียว แต่เป็นเรื่องของการ ร้อย generator เมืองในหัวข้อ 6.2, NPC Squad ในหัวข้อ 6.3 และ generator ไอเทม เข้าเป็นไลน์การผลิตเดียว เมื่อมีเครื่องมือสามตัว กับดักก็ไม่ได้มีแค่สาม แต่จะเกิดใหม่ขึ้นในรอยต่อระหว่างเครื่องมือด้วย

6.4.1 มุมมองแบบไลน์การผลิต

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

ทั้งไลน์ไหลไปเช่นนี้

flowchart TD
    SEED[จันทร์: ชีต lore_seeds
region·climate·faction·level_range]:::human
    SEED --> CITY[อังคาร: generator เมือง
โครง rulebook L1 + เนื้อหา L2 โดย AI]
    CITY -->|city_manifest.json| NPC[อังคาร: generator NPC
สืบทอด lore ของเมือง]
    CITY -->|level_range| ITEM[อังคาร: generator ไอเทม
สืบทอดช่วงเลเวล·ฝ่าย]
    NPC -->|persona_pool| SQUAD[อังคาร: การวาง Squad]
    ITEM --> SQUAD
    SQUAD --> LINT[พุธ: lint รวม
ความสอดคล้องข้าม generator]
    LINT -->|alert| REVIEW1[พุธ: ตรวจสอบรอบแรก
ตัวผู้เขียนเอง]
    REVIEW1 --> REVIEW2[พฤหัส: สุ่มตรวจรอบสอง
ลีดฝ่ายเนื้อเรื่อง]
    REVIEW2 --> BUILD[ศุกร์: นำเข้าบิลด์
+ เตรียม seed สำหรับสัปดาห์ถัดไป]
    BUILD -.ป้อนกลับ.-> SEED

    classDef human fill:#fde68a,stroke:#b45309,color:#000;

หัวใจอยู่ที่ลูกศรชื่อ city_manifest.json ขณะที่ generator เมืองสร้างเมือง มันจะหย่อนอัตลักษณ์ของเมืองนั้น (ว่าเป็นหมู่บ้านประมงที่ล่มสลายหรือเมืองท่าการค้าที่รุ่งเรือง) ออกมาเป็น manifest แล้ว generator NPC กับ generator ไอเทมก็ รับ manifest นั้นเป็นอินพุต กับดักที่ผมเหยียบตอนนั้นก็เพราะไม่มีลูกศรเส้นนี้ การร้อยเครื่องมือเข้าด้วยกันก็คือการสอดสัญญาหนึ่งบรรทัดนี้เข้าไประหว่างเครื่องมือ

6.4.2 สัญญาหนึ่งบรรทัดที่ร้อยเครื่องมือเข้าด้วยกัน — manifest

ทุกครั้งที่ generator เมืองสร้างเมืองขึ้นมาหนึ่งแห่ง มันจะคายไฟล์ city_manifest.json ออกมาด้วย รูปแบบจริงของไฟล์นี้เป็นเช่นนี้ และไฟล์นี้เองที่กลายเป็นอินพุตของ generator NPC และไอเทม

{
  "city_id": "port_harman",
  "display_name": "ท่าฮาร์มาน",
  "lore_seeds": ["หมู่บ้านประมงที่ล่มสลาย", "เสียงสะท้อนของการค้าครั้งเก่า", "ขาดแคลนเกลือ"],
  "region": "ชายฝั่งตอนใต้",
  "dominant_faction": "กิลด์ชาวประมง",
  "level_range": [12, 18],
  "tone": "เสื่อมถอย·ดื้อรั้น",
  "forbidden_names": ["ฮารัน", "ฮาร์เมน"],
  "neighbors": ["salt_marsh", "old_pier"]
}

generator NPC สืบทอด lore_seeds และ tone มาสร้าง "ผู้คนดื้อรั้นแห่งหมู่บ้านประมงที่ล่มสลาย" generator ไอเทมสืบทอด level_range มาแล้ววางขายเฉพาะอาวุธเลเวล 12–18 ส่วน forbidden_names คือชื่อที่เมืองข้างเคียงใช้ไปแล้ว ทั้งสองฝ่ายจึงหลีกเลี่ยง เครื่องมือทั้งสามตัวมองสัญญาฉบับเดียวกัน

พรอมต์ที่ผมป้อนให้ Claude ตอนสร้าง manifest นี้เป็นดังนี้ เนื่องจากเป็นการเรียกครั้งเดียวที่สำคัญที่สุดในการร้อยต้นน้ำของไลน์การผลิต ผมจึงคัดลอกมาเต็มทั้งฉบับ

เธอคือเครื่องเขียน manifest ของ generator เมือง MMORPG จงรับเมตาดาตาของผู้เขียนด้านล่างแล้วสร้าง city_manifest.json

อินพุตจากผู้เขียน: - city_id: port_harman - lore_seeds: หมู่บ้านประมงที่ล่มสลาย, เสียงสะท้อนของการค้าครั้งเก่า, ขาดแคลนเกลือ - region: ชายฝั่งตอนใต้ - level_range: 12-18

กฎ: 1. ให้อนุมาน dominant_faction จาก lore_seeds แต่ต้องไม่ซ้ำกับฝ่ายของเมืองข้างเคียง (salt_marsh, old_pier) ฝ่ายของเมืองข้างเคียงคือ [สหกรณ์นาเกลือ, กลุ่มลักลอบค้า] 2. ใน forbidden_names ให้ใส่ชื่อ NPC/สถานที่ที่ถูกใช้ไปแล้วในเมืองข้างเคียง รายการที่ให้มา: [ฮารัน, ฮาร์เมน] 3. tone ต้องไม่เกินสองคำ และต้องไม่ขัดแย้งกับ lore_seeds 4. จงแยกแสดงค่าที่อนุมานเองกับค่าที่ผู้เขียนระบุไว้อย่างชัดเจน

ผลลัพธ์ดิบจาก Claude เป็นเช่นนี้ ผมคัดลอกมาตามจริงโดยไม่สรุปย่อ มีอยู่จุดหนึ่งที่ฝ่าฝืนกฎ

{
  "city_id": "port_harman",
  "display_name": "ท่าฮาร์มาน",
  "lore_seeds": ["หมู่บ้านประมงที่ล่มสลาย", "เสียงสะท้อนของการค้าครั้งเก่า", "ขาดแคลนเกลือ"],
  "region": "ชายฝั่งตอนใต้",
  "dominant_faction": "กลุ่มลักลอบค้า",   // ← อนุมาน: ขาดแคลนเกลือ + การค้าครั้งเก่า = การลักลอบค้า
  "level_range": [12, 18],
  "tone": "เสื่อมถอย·โลภ",
  "forbidden_names": ["ฮารัน", "ฮาร์เมน"],
  "neighbors": ["salt_marsh", "old_pier"]
}

(ค่าที่อนุมาน: dominant_faction, tone, display_name / ค่าที่ผู้เขียนระบุ: ที่เหลือ) ข้อควรระวัง: ผมเลือก dominant_faction เป็น "กลุ่มลักลอบค้า" แต่ตามกฎข้อ 1 เมืองข้างเคียง old_pier เป็น "กลุ่มลักลอบค้า" อยู่แล้ว จึงเป็นการฝ่าฝืนกฎ ขอเสนอ "กิลด์ชาวประมง" เป็นตัวเลือกทดแทน

สิ่งสำคัญตรงนี้คือ AI รายงานการฝ่าฝืนกฎด้วยตัวเอง "กลุ่มลักลอบค้า" เป็นการอนุมานที่น่าสนใจเมื่อมองจาก lore_seeds (ขาดแคลนเกลือ·การค้าครั้งเก่า) แต่ ในระดับของไลน์การผลิตแล้วมันชนกัน เพราะเมืองข้างเคียงเป็นกลุ่มลักลอบค้าอยู่ก่อนแล้ว ผมจึงรับข้อเสนอของ AI แล้วแก้ dominant_faction เป็น "กิลด์ชาวประมง" และแก้ tone เป็น "เสื่อมถอย·ดื้อรั้น" คำว่า "โลภ" เป็นคำที่ออกมาจากสมมติฐานกลุ่มลักลอบค้า จึงไม่เข้ากับกิลด์ชาวประมง

การตรวจสอบ·ปฏิเสธ·กำหนดใหม่เพียงครั้งเดียวนี้คอยปกป้องต้นน้ำของไลน์ ถ้า manifest ผิด NPC ทั้ง 110 ตัวและอาวุธทั้ง 60 ชิ้นที่อยู่ใต้มันก็จะถูกสร้างขึ้นบนสมมติฐานที่ผิดทั้งหมด ใช้เวลา 5 นาทีที่ต้นน้ำ จะประหยัดเวลา 3 ชั่วโมงที่ปลายน้ำ

6.4.3 lint รวม — ตรวจรอยต่อระหว่างเครื่องมือ

lint ของ generator เดี่ยวมองเฉพาะผลลัพธ์ของตัวเอง lint ของเมืองดูว่าเมืองทำตาม rulebook หรือไม่ lint ของ NPC ดูว่าเพอร์โซนารักษาความสอดคล้องของ voice ไว้หรือไม่ แต่กับดักที่ผมเหยียบตอนแรกอยู่ใน รอยต่อระหว่างเครื่องมือ ไม่ใช่ภายในเครื่องมือแต่ละตัว ดังนั้นไลน์จึงต้องการอีกหนึ่งชั้นที่อยู่เหนือ lint เดี่ยว นั่นคือ lint รวมที่อ่านข้อมูลของเมือง·NPC·ไอเทมไปพร้อมกันแล้วตรวจสอบแบบไขว้

รายการที่ lint รวมจับได้จริงเป็นเช่นนี้

ส่วนหนึ่งของผลลัพธ์จริงตอนรัน lint รวมนี้เป็นดังนี้ มันไม่ได้ทิ้งผลลัพธ์อัตโนมัติ แต่เพียงแสดง alert ขึ้นมาเพื่อให้คนเป็นผู้ตัดสิน

[lint รวม] ตรวจสอบไลน์ port_harman — 3 alert

ALERT-1 (ความสอดคล้องของ lore) port_harman
  city.lore_seeds = ["หมู่บ้านประมงที่ล่มสลาย", ...]
  npc[merchant_04].persona = "พ่อค้าผู้มั่งคั่งแห่งเมืองท่าการค้าที่รุ่งเรือง"
  → อาจขัดแย้งกัน ต้องยืนยันว่าเป็นความเบี่ยงเบนที่ตั้งใจหรือไม่

ALERT-2 (ความสอดคล้องของช่วงเลเวล) port_harman
  city.level_range = [12,18]
  item[blade_legend_07].required_level = 40
  → เกินช่วงเลเวลแนะนำไป 28 ทบทวนการวางในร้านค้าใหม่

ALERT-3 (ชื่อซ้ำ) — ข้อมูล
  npc[fisher_02].name = "ฮารัน"
  city.forbidden_names = ["ฮารัน", ...]
  → ชนกับ forbidden_names แนะนำให้สร้างชื่อ NPC ใหม่

พอเห็น ALERT-1 ผมก็ลังเลอยู่ครู่หนึ่ง การที่ NPC เป็น "พ่อค้าผู้มั่งคั่งแห่งเมืองท่าการค้าที่รุ่งเรือง" ก็ไม่ได้ผิดเสมอไป ถ้าเป็นเมืองที่ เคยรุ่งเรืองแต่ตอนนี้ล่มสลายไปแล้ว "พ่อค้าที่เคยร่ำรวย แต่ตอนนี้ยากจน" ก็กลับเป็นเรื่องเล่าที่ดีเสียด้วยซ้ำ ดังนั้นผมจึงตัดสิน ALERT-1 ว่าเป็น "ความเบี่ยงเบนที่ตั้งใจ" แทนที่จะทิ้ง แล้วขอแก้เพอร์โซนาของ NPC หนึ่งบรรทัดเป็น "พ่อค้าชราที่ยังยึดเหนี่ยวร่องรอยของเมืองท่าการค้าที่เคยรุ่งเรือง" ส่วน ALERT-2 เป็นความผิดพลาดที่ชัดเจน ผมจึงเอาอาวุธออก และ ALERT-3 ก็แค่สร้างชื่อใหม่

ไม่ใช่ lint อัตโนมัติที่หยุดความผิดพลาดได้ แต่ lint อัตโนมัติ ดึงความผิดพลาดมาวางไว้ตรงหน้าคน ส่วนการตัดสินเป็นหน้าที่ของคน นี่คือหัวใจของ L2 (rulebook + AI ช่วย) ที่พูดถึงในหัวข้อ 6.1 AI สร้างโครงและ alert ส่วนคนเป็นผู้ตัดสินครั้งสุดท้าย การคัดแยกสิ่งที่ "ดูเหมือนผิดแต่เป็นเรื่องเล่าที่ดี" อย่าง ALERT-1 เป็นสิ่งที่ rulebook ทำไม่ได้

6.4.4 หมุนไลน์ด้วยรอบหนึ่งสัปดาห์

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

วันอังคารคือหัวใจของไลน์ พอ generator เมืองหย่อน manifest ออกมา generator NPC ก็คาบมันไป generator ไอเทมก็คาบไป แล้ว Squad ก็วางตำแหน่งจนจบ ห่วงโซ่นี้หมุนอยู่เบื้องหลังโดยไม่ต้องอาศัยการแทรกแซงของผู้เขียน ระหว่างนั้นผู้เขียนก็ไปเขียนเควสต์หลัก (L0 ทำมือล้วน) ผลตอบแทนที่แท้จริงของการร้อยเครื่องมืออยู่ตรงนี้ ถ้าเครื่องมือแยกกัน ผู้เขียนต้องลงมือถึงสามครั้งในวันอังคาร แต่ถ้าร้อยเข้าด้วยกันก็ไม่ต้องลงมือเลยสักครั้ง

ผู้เขียนคนเดียวผลิตเมือง 5–7 แห่งต่อสัปดาห์ พร้อม NPC·อาวุธที่ผูกติดมาด้วย 4 สัปดาห์ก็ได้เมือง 20–28 แห่ง เป้าหมาย 30 แห่งบรรลุได้ใน 6 สัปดาห์

6.4.5 ความสมบูรณ์ของไลน์ — สี่ตัวชี้วัดที่ดูทุกสัปดาห์

ความสมบูรณ์ของไลน์ดูจากตัวเลข ไม่ใช่ความรู้สึก นี่คือสี่ตัวชี้วัดที่ถูกรวบรวมโดยอัตโนมัติทุกสัปดาห์

ตัวชี้วัดที่เป็นแบบไลน์มากที่สุดคือตัวที่สอง จำนวนการชนกันข้าม generator เมื่อใช้เครื่องมือเดี่ยวตัวเดียว ตัวเลขนี้ไม่มีอยู่ หากตัวเลขนี้พุ่งเกิน 10 ครั้งขึ้นมาทันที ก็ไม่ใช่ว่าเครื่องมือตัวใดตัวหนึ่งพัง แต่คือ สัญญา (manifest) ระหว่างเครื่องมือแตก มักจะระเบิดตอนที่เปลี่ยน schema ของ manifest ใน generator เมือง แต่ generator NPC ยังอ่าน schema เก่าอยู่ ถ้าไม่มีตัวชี้วัดนี้ ก็จะมองไม่เห็นความผิดพลาดนั้นจนกระทั่งปล่อยเกม

สี่ตัวชี้วัดนี้ถูกป้อนเข้าสู่การทบทวนรายไตรมาสทุกสัปดาห์ ถ้าแนวโน้มแย่ลง ก็ลดจำนวนเมืองที่ผลิตในสัปดาห์ถัดไปจาก 5–7 แห่งลงเหลือ 3–5 แห่ง แล้วหาสาเหตุ

6.4.6 สามความผิดพลาดที่ทำให้ไลน์ล่ม

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

หนึ่ง ความผิดพลาดจากสัญญาไม่ตรงกัน เพิ่มฟิลด์ใหม่ลงใน manifest ของ generator เมือง แต่ generator NPC ไม่รู้จักฟิลด์นั้น ตัวชี้วัดการชนกันแบบไขว้พุ่งสูง เมื่อพัฒนาเครื่องมือแยกกัน ก็ง่ายที่จะอัปเดตเพียงฝ่ายเดียว ทางรับมือคือใส่ฟิลด์ version ลงใน schema ของ manifest แล้วให้ generator ปลายน้ำแสดง alert ทันทีเมื่อเวอร์ชันไม่ตรงกัน ไม่ใช่การไล่บี้คน แต่เป็นการบังคับใช้สัญญา

สอง ความผิดพลาดจากต้นน้ำปนเปื้อน ถ้า manifest ถูกสร้างขึ้นบนสมมติฐานที่ผิด (เช่น "กลุ่มลักลอบค้า" ในหัวข้อ §6.4.2) ทุกอย่างที่อยู่ใต้มันก็จะปนเปื้อนตามไปด้วย อัตราทิ้งจากการตรวจสอบโดยมนุษย์เกิน 30% แต่พอดูผลลัพธ์ที่ถูกทิ้ง คุณภาพของ NPC แต่ละตัวกลับดีปกติ แต่ละตัวดีปกติ แต่สมมติฐานผิด ทางรับมือคือใส่การตรวจสอบเพิ่มอีกหนึ่งขั้นในช่วงการสร้าง manifest ตรวจต้นน้ำ 1 ชิ้นย่อมดีกว่าตรวจปลายน้ำ 110 ชิ้น

สาม ความผิดพลาดจากโมเดลดริฟต์ LLM ถูกอัปเดตอัตโนมัติจนคุณลักษณะของผลลัพธ์เปลี่ยนไป generator ทั้งสามตัวคือเมือง·NPC·ไอเทม สั่นพร้อมกัน ให้ตรวจสอบการเปลี่ยนแปลงในช่วง 1 สัปดาห์ล่าสุด วิเคราะห์ตัวอย่างที่ถูกทิ้ง 5 ชิ้น แล้วปรับพรอมต์หรือ context หลังจากเฝ้าติดตาม 1 สัปดาห์จึงยืนยันการกลับสู่สภาพเดิม

ทางรับมือร่วมของทั้งสามความผิดพลาดเหมือนกัน ไม่กล่าวโทษคน แต่เสริมความแข็งแกร่งของสัญญา ถ้าสาเหตุคือผู้เขียนเขียน lore_seeds มาเพียงบรรทัดเดียว แทนที่จะพูดว่า "เขียนมาสามบรรทัดสิ" ก็เพิ่มการตรวจสอบแบบบังคับลงใน lint ของ manifest แต่นั่นไม่ได้แปลว่าความรับผิดชอบของคนเป็น 0 นอกเหนือจากการเสริมความแข็งแกร่งของระบบแล้ว รูปแบบของความผิดพลาดยังถูกแบ่งปันกันในการทบทวนด้วย

6.4.7 เวลาของผู้เขียนไปอยู่ที่ไหน

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

เวลาของผู้เขียน 80% มารวมกันที่งานหลักและงานซิกเนเจอร์ แต่การกระจายนี้ไม่ได้คงอยู่ได้เอง พอนำไลน์มาใช้ เวลาของผู้เขียนมักจะไหลไปที่งานตรวจสอบจนหมด ดังนั้นจึงวัดการกระจายเวลาทุกเดือน และถ้างานหลักตกลงต่ำกว่า 50% ก็ลดจำนวนเมืองที่ผลิตเพื่อฟื้นเวลาของงานหลักกลับมา การกระจายเวลาเป็นสิ่งที่ต้องรักษาด้วยนโยบาย

6.4.8 ขยายไลน์ไปสู่เนื้อหาแบบอื่น

เมื่อไลน์เมือง·NPC·ไอเทมเสถียรแล้ว ก็ขยายโครงเดียวกันนี้ไปสู่ดันเจี้ยน·สมุดภาพ·อีเวนต์ Live Ops หัวใจคือ การไม่สร้างรูปแบบใหม่ สิ่งล่อใจที่ว่า "ดันเจี้ยนต่างจากเมือง จึงต้องใช้โครงสร้างที่ต่างออกไป" มาเยือนอยู่เสมอ แต่โครงของไลน์ (manifest ที่ใช้ร่วมกัน → ห่วงโซ่ generator → lint รวม → การตรวจสอบโดยมนุษย์) เหมือนกันทุกประการ เพียงสลับเปลี่ยนรูปแบบเมตาดาตาอินพุตกับ rulebook ของโดเมนเท่านั้น

ถ้าเป็นดันเจี้ยน ก็จะมีฟิลด์อย่าง boss_pattern·encounter_flow เพิ่มเข้ามาใน dungeon_manifest.json และมีกฎโดเมนอย่างเส้นทางเดินของบอสติดเข้าไปใน lint รวมอีกหนึ่งบรรทัด โครงเหมือนเดิม เปลี่ยนแค่กฎ ถ้ารักษาโครงเดิมไว้ ผู้เขียนก็ไม่ต้องเรียนรู้เครื่องมือใหม่อีก และโครงสร้างพื้นฐานของ lint รวมก็ถูกนำกลับมาใช้ซ้ำได้ทันที แต่นี่ไม่ได้แปลว่าให้ละเลยความเฉพาะตัวของโดเมน ดันเจี้ยนจำเป็นต้องมีกฎเส้นทางเดินที่เมืองไม่มีอย่างแน่นอน

6.4.9 ผลการเดินเครื่อง 6 เดือน

นี่คือผลของการเดินไลน์รวมนี้ในโปรเจกต์ของผมเป็นเวลา 6 เดือน เทียบกับช่วงที่รัน generator เมือง·NPC·ไอเทม แยกกัน ตัวเลขสัมบูรณ์ด้านล่างเป็น การประมาณของผู้เขียน (ยังไม่ได้ตรวจสอบ) ไม่ใช่การรวบรวมที่แม่นยำ แต่ทิศทางและสัดส่วนเป็นไปตามแนวโน้มที่วัดได้จริง

การเปลี่ยนแปลงที่สำคัญที่สุดคือบรรทัดสุดท้าย ตอนที่เครื่องมือแยกกัน การตรวจสอบต้นน้ำเป็น 0 และการตรวจสอบปลายน้ำเป็น 3 ชั่วโมง พอร้อยไลน์เข้าด้วยกันแล้วตรวจสอบ manifest ที่ต้นน้ำ 5 นาทีที่ต้นน้ำก็ลบ 2 ชั่วโมงที่ปลายน้ำออกไป และเมื่อความผิดพลาดไม่รั่วออกมาตามรอยต่อระหว่างเครื่องมือ ความผิดพลาดด้านความสอดคล้องหลังปล่อยเกมก็ลดจาก 8–12 ครั้ง/ไตรมาส เหลือ 2–4 ครั้ง

และการแลกเปลี่ยน (trade-off) ก็ชัดเจนขึ้น แต่ก่อนมีการถกเถียงนามธรรมว่า "การผลิตจำนวนมากอันตราย" วนเวียนอยู่ทุกไตรมาส แต่ตอนนี้ตัดสินใจกันบนการเปรียบเทียบที่เป็นรูปธรรมว่า "การชนกัน -8 ครั้ง / เควสต์หลัก +5 อัน"

6.4.10 เจ็ดความล้มเหลวที่พบบ่อย

1) กรณีที่ไม่ร้อยเครื่องมือเข้าด้วยกัน แต่รันแยกกัน กับดักเกิดในรอยต่อระหว่างเครื่องมือ ไม่ใช่ภายในเครื่องมือ

2) กรณีที่เชื่อม generator เข้าด้วยกันโดยไม่มี manifest ถ้าไม่มีสัญญาที่ใช้ร่วมกัน ปลายน้ำก็จะไม่ตรงกับต้นน้ำ

3) กรณีที่แทนที่ lint รวมด้วย lint เดี่ยว lint เดี่ยวมองการชนกันแบบไขว้ไม่เห็น

4) กรณีที่บีบรอบจาก 5 วันเหลือ 3 วัน 5 วันคือมาร์จินความปลอดภัยของการตรวจสอบ

5) กรณีที่ไม่ตรวจสอบต้นน้ำ (manifest) แต่ไปตรวจสอบปลายน้ำ จงดูต้นน้ำ 1 ชิ้นแทนปลายน้ำ 110 ชิ้น

6) กรณีที่โยนความผิดพลาดให้เป็นความรับผิดชอบของคนเพียงอย่างเดียว คำตอบคือการเสริมความแข็งแกร่งของสัญญา·การทำให้กฎเป็นอัตโนมัติ

7) กรณีที่ "ไม่ใช้" หลังจากมีไลน์แล้ว การบังคับใช้รอบหนึ่งสัปดาห์สำคัญพอ ๆ กับตัวเครื่องมือ

ลองทำดู

setup จงเตรียม generator เมือง (6.2) และ generator NPC (6.3) ให้พร้อม แล้วกำหนด schema ของ city_manifest.json ที่ทั้งสองจะใช้ร่วมกันขึ้นมาหนึ่งชุด ฟิลด์อย่างน้อยควรมี lore_seeds·region·faction·level_range·forbidden_names·tone·version

prompt จงใช้พรอมต์เครื่องเขียน manifest จากในเนื้อหาด้านบนตามนั้นเลย หัวใจอยู่ที่สองกฎสุดท้าย "อย่าให้ซ้ำกับฝ่ายของเมืองข้างเคียง" (ป้องกันการชนกันแบบไขว้) และ "จงแยกแสดงค่าที่อนุมานกับค่าที่ระบุไว้" (ความเป็นไปได้ในการตรวจสอบ) เมื่อสร้างเมืองให้หย่อน manifest ออกมา แล้วเชื่อมให้ generator NPC·ไอเทมรับ manifest นั้นเป็นอินพุต

verify จงรัน lint รวมหนึ่งครั้ง มันจะตรวจสอบสี่อย่างแบบไขว้กัน ได้แก่ ความสอดคล้องของ lore·ความสอดคล้องของช่วงเลเวล·การชนกันของฝ่าย·ชื่อซ้ำ ถ้า alert ขึ้นมา อย่าทิ้งอัตโนมัติ แต่ให้คนเป็นผู้ตัดสิน การคัดแยกสิ่งที่ "ดูเหมือนผิดแต่เป็นเรื่องเล่าที่ดี" (พ่อค้าชราแห่งเมืองท่าการค้าที่ล่มสลาย) เป็นหน้าที่ของคน

ฉบับย่อสำหรับคนเดียว แม้จะมีเครื่องมือแค่สองตัวคือเมือง·NPC ไลน์ก็ยังตั้งขึ้นได้ เพียงเขียน lore_seeds·level_range·forbidden_names ของแต่ละเมืองลงในสเปรดชีตหนึ่งใบ แล้วก๊อปปี้ทั้งแถวนั้นไปแปะลงในพรอมต์ของ generator NPC ก็ทำหน้าที่เป็น manifest ได้แล้ว lint รวมแม้จะมีแค่บรรทัดเดียวสำหรับความสอดคล้องของ lore ระหว่างเมือง-NPC ก็ป้องกันกับดักนั้นได้ ไม่ต้องมีโครงสร้างพื้นฐานยิ่งใหญ่ เพียงมีหลักการเดียวว่า "สอดสัญญาหนึ่งบรรทัดเข้าไประหว่างเครื่องมือ" ไลน์ก็เริ่มต้นได้

สรุปประเด็นสำคัญของบท

• กับดักเกิดในรอยต่อระหว่างเครื่องมือ ไม่ใช่ภายในเครื่องมือ จงร้อยรอยต่อนั้นเข้าด้วยกันด้วย manifest
• lint รวมไม่ใช่เครื่องทิ้งผลลัพธ์ แต่เป็นกลไกที่ดึงความผิดพลาดมาวางไว้ตรงหน้าคน
• การตรวจสอบต้นน้ำ 5 นาที ลบการตรวจสอบปลายน้ำ 2 ชั่วโมง จงสกัดกั้นจากด้านบน

ส่วนที่ 7 · การออกแบบเลเวล

7.1 มาสเตอร์การออกแบบเลเวลแบบโพรซีเดอรัล

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

บทนี้คือเรื่องราวของการสร้างโครงสร้างที่ทำให้อุบัติเหตุแบบนั้นถูกสกัดกั้นโดยอัตโนมัติตั้งแต่ขั้นบิลด์ หัวใจไม่ได้อยู่ที่ฝีมือในการวาดพื้นที่ แต่อยู่ที่วิธีบริหารข้อมูลที่ผูกอยู่กับพื้นที่นั้นด้วยกฎ

ที่ทำงานของการออกแบบเลเวลใกล้เคียงกับห้องเขียนแบบ แบบแปลนแต่ละแผ่นออกมาจากมือคน แต่ความสอดคล้อง การนำกลับมาใช้ และการตรวจสอบระหว่างแบบแปลนนั้น ถูกกำหนดด้วยกฎการบริหารตู้เก็บแบบแปลน ดันเจี้ยนหนึ่งห้องที่วาดด้วยมือนั้นใครก็ทำได้ แต่การบริหารดันเจี้ยน 100 อันให้มีเส้นโค้งความยากที่สอดคล้องกันและเป็นกราฟที่ไม่มีทางตันนั้น ไม่ใช่ปัญหาของฝีมือ แต่เป็นปัญหาของระบบ

ในโปรเจกต์ A ที่ผู้เขียนทำงานในตำแหน่ง Design Director (MMORPG ที่เจาะตลาดในประเทศ + เอเชียตะวันออกเฉียงใต้, ทีมขนาดกลาง (10\~50 คน), เน้นมือถือเป็นหลัก) ระบบนี้มีชื่อว่าเอกสารหนึ่งฉบับชื่อ Procedural_Level_Design_Master บทนี้พูดถึงว่าเอกสารฉบับนั้นรวมอะไรไว้ด้วยกัน AI เข้ามาแตะถึงไหน และหยุดตรงไหน ประสบการณ์การนำทีมออกแบบเกม RPG roguelite บนมือถือที่สร้างดันเจี้ยนขึ้นใหม่ทุกรอบการเล่น และการบริหารพื้นที่แบบโพรซีเดอรัลด้วยกฎ คือพื้นฐานที่รองรับบทนี้อยู่

7.1.1 สองทางแยก — จะสร้างพื้นที่ หรือจะบริหารเมตาดาตาของพื้นที่

การทำเลเวลให้เป็นอัตโนมัติแยกออกเป็นสองทิศทาง ทางหนึ่งคือการสร้างตัวพื้นที่เองแบบโพรซีเดอรัล PCG (Procedural Content Generation) แบบดั้งเดิม เช่น BSP partitioning (Binary Space Partitioning, เทคนิคคลาสสิกที่แบ่งพื้นที่ออกเป็นสองส่วนเท่า ๆ กันแบบเรียกซ้ำเพื่อจัดวางห้อง), wave function collapse, drunken walk grid อยู่ในกลุ่มนี้ อีกทางหนึ่งคือการบริหารเมตาดาตาของพื้นที่ — แท็กห้อง, ความเชื่อมต่อ, ป้ายกำกับความยาก, ช่องสำหรับเหตุการณ์

PCG แบบดั้งเดิมแข็งแกร่งในแบบแรก ในแนวเกมที่ "แผนที่ใหม่ทุกรอบ" คือหัวใจของความเป็นเกม อย่าง roguelike หรือ sandbox แบบแรกคือคำตอบที่ถูกต้อง แต่ MMORPG ต่างออกไป ผู้เล่นเดินดันเจี้ยนเดิมหลายสิบรอบ เดินจนเส้นทางขึ้นใจ ดันเจี้ยนจึงต้องเป็นพื้นที่ตายตัวที่ขัดเกลาด้วยมือ และที่ที่การทำให้เป็นอัตโนมัติจะเข้ามาได้นั้นไม่ใช่ตัวพื้นที่เอง แต่เป็น เมตาดาตาที่ทำให้พื้นที่นั้นบริหารจัดการได้

ทำไมเมตาดาตาจึงเป็นกระดูกสันหลังของการบริหาร เห็นชัดเมื่อมองทีละผลผลิต

ดันเจี้ยนที่ไม่มีเมตาดาตานั้นบิลด์ได้ แต่บริหารไม่ได้ เหมือนห้องสมุดที่มีหนังสือเต็มแต่ไม่มีดัชนี นี่คือเหตุผลที่บทนี้มุ่งเน้นไปที่ "การบริหารเมตาดาตาของพื้นที่"

7.1.2 เอกสารมาสเตอร์รวมอะไรไว้ด้วยกัน

Procedural_Level_Design_Master มัดมาตรฐานสี่อย่างไว้ในเอกสารฉบับเดียว ได้แก่ แบบฟอร์มเมตาดาตาห้อง, พจนานุกรมแท็กห้อง, กฎความเชื่อมต่อ และเช็กลิสต์การตรวจสอบ ลองดูก่อนว่าเกิดอะไรขึ้นเมื่อทั้งสี่อย่างนี้กระจัดกระจาย ถ้านักออกแบบห้าคนต่างอ้างอิงแบบฟอร์มจากไฟล์คนละไฟล์ ฟิลด์ type คนหนึ่งจะเขียน combat คนหนึ่งเขียน Combat อีกคนเขียน battle_room การค้นหาพัง สถิติพัง และสุดท้ายการทำงานอัตโนมัติก็พัง

มาตรฐานสี่อย่างนี้เมื่อจัดเรียงตาม Layer แล้ว ตำแหน่งของแต่ละอย่างชัดเจน แบบฟอร์ม·พจนานุกรม·กฎอยู่ในรูลบุ๊ก (L1) ที่ควบคุมการสร้าง, เนื้อหาห้องที่สร้างขึ้นอยู่ในคอนเทนต์ (L2), ค่าในชีตอยู่ในข้อมูล (L3), และการตรวจสอบอยู่ในด่านบิลด์·QA (L4)

การที่เอกสารมาสเตอร์รวมมาตรฐานสี่อย่างไว้ด้วยกันนั้นไม่ได้หมายความว่า "ยัดเนื้อหาทั้งหมดไว้ในไฟล์เดียว" แต่หมายความว่า "รวมกฎไว้ในตำแหน่ง L1" ด้วยเหตุนี้ การทำงานอัตโนมัติที่จะกล่าวถึงข้างหน้าจึงสามารถวางทับอยู่บนขอบเขตของ Layer ได้ (จะเกิดอะไรขึ้นเมื่อการแบ่งแยกพังทลาย จะกล่าวถึงใน 7.1.11)

7.1.3 แบบฟอร์มเมตาดาตาห้อง — ตำแหน่งอินพุตที่การทำงานอัตโนมัติเข้ามาเกาะ

ห้องหนึ่งเป็นไปตามแบบฟอร์มต่อไปนี้ แบบฟอร์มนี้คืออินเทอร์เฟซอินพุตของการทำงานอัตโนมัติ

room_id: dungeon_021_room_07
dungeon: dungeon_021_silvermark_library
type: combat_room          # combat / puzzle / lore / safe / boss
size: medium               # small / medium / large
difficulty_label: hard_for_level_28
tags: [scholar_theme, vertical_layout, water_hazard]
connections:
  - target_room: dungeon_021_room_06
    type: door
    direction: south
  - target_room: dungeon_021_room_08
    type: passage
    direction: east
event_slots:
  - slot: enemy_spawn_1
    constraints: [scholar_enemy, level_28]
  - slot: lore_object_1
    constraints: [scholar_lore]
movement_complexity: 4     # 1~5
estimated_clear_time_sec: 90
art_pack: scholar_library_v2

แต่ละฟิลด์มีปลายทางการบริโภคอัตโนมัติอย่างน้อยหนึ่งแห่ง type ใช้ในสถิติพูลดันเจี้ยนและการคำนวณความยาก, tags ใช้ในการค้นหา·การนำกลับมาใช้·การแมปชุดอาร์ต, connections ใช้ในการตรวจสอบกราฟ (การตรวจหาทางตัน), event_slots ใช้ในการจัดวางเควสต์·บอสอัตโนมัติ ฟิลด์ที่ไม่มีปลายทางการบริโภคจะไม่ใส่ไว้ในแบบฟอร์ม เพราะเพิ่มแต่ต้นทุนการป้อนข้อมูลโดยไม่มีคุณค่า

7.1.4 พจนานุกรมแท็กห้อง — เล็กและเป็นอิสระต่อกัน (orthogonal)

แท็กคือคีย์การค้นหาของเมตาดาตา ถ้าแพร่ขยายไม่จำกัด การค้นหาจะพัง ถ้าติดป้าย 200 อันในลิ้นชัก จะหาไม่เจอว่าอะไรอยู่ตรงไหน ด้วยเหตุนี้จึงบริหารด้วย 5 หมวด × ประมาณ 6 enum ต่อหมวด รวมแล้วประมาณ 30 อัน

ห้องหนึ่งไม่ใส่แท็กเกิน 5 อัน ปกติคือ 3\~4 อัน การจะเพิ่มแท็กใหม่ต้องผ่านด่านสี่ขั้น คือ ต้องเป็นตัวเลือกที่จะใช้ตั้งแต่ 5 ห้องขึ้นไปต่ออัปเดต, ต้องไม่สามารถแสดงได้ด้วยการรวมแท็กเดิม, การนำไปใช้ค้นหา·แมปชุดอาร์ตต้องชัดเจน, และต้องยังคงใช้อยู่ 5 ห้องแม้ผ่านการใช้งานไปแล้ว 1 เดือน เงื่อนไขข้อสุดท้ายคือหัวใจ ถ้าแท็กที่สร้างขึ้นชั่วคราวถูกใช้ครั้งเดียวแล้วทิ้ง พจนานุกรมก็จะปนเปื้อน

7.1.5 ไปป์ไลน์เลเวลแบบโพรซีเดอรัล — จากรูลบุ๊กถึงการตรวจสอบ

มาตรฐานทั้งหมดที่ผ่านมาเชื่อมต่อกันเป็นกระแสเดียวอย่างไร เส้นเชื่อมต่อนั้นคือโครงกระดูกที่บทนี้รองรับอยู่ เป็นไปป์ไลน์ที่เริ่มจากรูลบุ๊ก ผ่านการแปรผันโดย AI ช่วย แล้วจบที่การตรวจสอบของ guardrail

flowchart TD
    A["L0 วิสัยทัศน์ — คอนเซปต์ดันเจี้ยน·เจตนาการกำหนดจังหวะ"] --> B["L1 รูลบุ๊ก\nพจนานุกรมแท็ก · กฎความเชื่อมต่อ · กฎช่อง"]
    B --> C["จัดวางโครงห้อง\nงานมือนักออกแบบ + เอดิเตอร์"]
    C --> D["ดึงเมตาดาตาอัตโนมัติ\nroom_id · connections · type · size"]
    D --> E["แปรผันโดย AI ช่วย\nดึง tags · เสนอการแมป art_pack"]
    E --> F{"ตรวจสอบบังคับตามพจนานุกรม\nแท็กนอกพจนานุกรม?"}
    F -->|นอกพจนานุกรม| E
    F -->|ผ่าน| G["นักออกแบบตรวจสอบ\nยืนยัน tags · difficulty_label"]
    G --> H["L4 ตรวจสอบกราฟ\nการเข้าถึง · ทางตัน · วงวน · การแตกแขนง"]
    H -->|ละเมิด| C
    H -->|ผ่าน| I["ตรวจสอบเส้นโค้งความยาก\nรวมป้ายกำกับความยากของห้อง"]
    I --> J["ด่านความสอดคล้องของชุดอาร์ต"]
    J -->|ผ่าน| K["บิลด์ — ลงทะเบียนพูลดันเจี้ยน"]
    J -->|ไม่สอดคล้อง| E

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class B,D,F,H,I,J code;
    class E ai;
    class C,G human;
    class K pass;

ขอชี้ลักษณะสามอย่างของไปป์ไลน์นี้ไว้ ประการแรก รูลบุ๊ก (L1) อยู่ต้นน้ำของการสร้างทั้งหมด ประการที่สอง AI แปรผันได้เฉพาะภายในพจนานุกรมที่รูลบุ๊กกำหนดไว้เท่านั้น — ด่าน F ส่งผลลัพธ์ที่อยู่นอกพจนานุกรมกลับคืน ประการที่สาม การตรวจสอบ (H·I·J) ถูกตรึงไว้เป็นด่านก่อนบิลด์ ดังนั้นการละเมิดจึงถูกสกัดด้วยโค้ด ไม่ขึ้นอยู่กับความใส่ใจของคน อุบัติเหตุห้องหมายเลข 47 เกิดขึ้นเพราะไม่มีด่าน H

7.1.6 กฎความเชื่อมต่อ — guardrail ที่ตรวจสอบด้วยกราฟ

ฟิลด์ connections ในเมตาห้องทำให้ทั้งดันเจี้ยนกลายเป็นกราฟแบบมีทิศทาง เมื่อกลายเป็นกราฟ การตรวจสอบก็เป็นอัตโนมัติ

สคริปต์การวัดมีรูปแบบดังต่อไปนี้ เป็น wrapper บาง ๆ ที่ห่อคำศัพท์ของดันเจี้ยนไว้บนอัลกอริทึมกราฟมาตรฐาน (เส้นทางยาวที่สุด·ดีกรีออกเฉลี่ย·การนับลูป·เส้นทางสั้นที่สุด)

# level_graph_metrics.py
def measure(dungeon):
    graph = build_graph(dungeon.rooms)
    return {
        "depth":            longest_path_length(graph),
        "branching_factor": avg_out_degree(graph),
        "loop_count":       count_loops(graph),
        "dead_ends":        count_dead_ends(graph),
        "boss_reachability": shortest_path(graph.start, graph.boss),
    }

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

7.1.7 บันทึกเซสชันจริง — มอบการดึง tags ให้ AI, ปฏิเสธ, แล้วขอใหม่

ส่วนหนึ่งของการทำงานอัตโนมัติที่คนอยากปล่อยมือมากที่สุดคือการป้อน tags การติดแท็กห้อง 100 ห้องนั้นน่าเบื่อ และเมื่อดูแค่ภาพหน้าจอห้อง คนก็สับสนได้เหมือนกัน งานที่ทำซ้ำและมีเกณฑ์การตัดสินชัดเจนแบบนี้แหละคือตำแหน่งที่ดีที่ AI จะรองรับการร่างเบื้องต้น หัวข้อนี้จะกางเวิร์กโฟลว์ที่เคยรันงานนั้นจริง — ทั้งพรอมต์, ผลลัพธ์ของ AI ที่ถูกปฏิเสธ, ไปจนถึงการขอใหม่ของคน — ออกมาโดยไม่มีการตกแต่ง

พรอมต์ครั้งที่ 1:

[อินพุต]
- ภาพหน้าจอห้อง: (แนบมา)
- พื้นที่ห้อง: 18m × 12m, ความสูงเพดาน 9m (โครงสร้างแนวตั้ง 2 ชั้น)
- ศัตรูที่จัดวาง: scholar_phantom × 3, water_elemental × 1
- type ห้องที่อยู่ติดกัน: lore_room (ด้านตะวันตก), combat_room (ด้านตะวันออก)
- ในห้องมีแอ่งน้ำตื้น

เลือกแท็ก 3~5 อันที่เหมาะกับห้องนี้จากพจนานุกรมด้านล่างเท่านั้น อย่าสร้างแท็กนอกพจนานุกรม
ตอบเฉพาะ enum ของแท็กคั่นด้วยคอมมา

[พจนานุกรมแท็ก 30 อัน]
theme: scholar_theme, ruins_theme, forest_theme, cave_theme,
       crypt_theme, swamp_theme, mechanical_theme, celestial_theme
layout: vertical_layout, horizontal_corridor, open_arena,
        maze_layout, bridge_layout
hazard: water_hazard, fire_hazard, falling_hazard,
        poison_hazard, crush_hazard, dark_hazard
interaction: puzzle_required, lever_activation, key_gate, hidden_passage
narrative: flashback_trigger, dialogue_zone, lore_object_zone,
           ambush_setup, ritual_site, vista_point, rest_anchor

ผลลัพธ์ครั้งที่ 1 ของ Claude (แบบดิบ):

scholar_theme, vertical_layout, water_hazard, ambush_setup, two_story_layout

ตรงนี้มีปัญหาสองอย่างปรากฏออกมาตามจริง อย่างแรกคือ two_story_layout เป็นแท็กที่ไม่มีในพจนานุกรม โมเดลถูกอินพุต "โครงสร้างแนวตั้ง 2 ชั้น" ดึงไป จึงสร้างคำที่อยู่นอกพจนานุกรมขึ้นมา อีกอย่างหนึ่งคือแท็กแตะเพดาน 5 อันแล้ว แต่ vertical_layout กับ two_story_layout มีความหมายซ้อนทับกัน เท่ากับใช้สองช่องในหมวด layout

การตัดสินปฏิเสธของคน two_story_layout เป็นการละเมิดการบังคับตามพจนานุกรม จึงเป็นเป้าหมายของการปฏิเสธอัตโนมัติ (ด่าน F ของไปป์ไลน์) ส่วน ambush_setup นั้นการตัดสินแยกเป็นสองทาง — มีศัตรูจัดวางอยู่ 3 ตัวก็จริง แต่จากภาพหน้าจอนั้นคลุมเครือว่าเป็นองค์ประกอบของการซุ่มโจมตี หรือเป็นเพียงห้องต่อสู้ธรรมดา มีความเป็นไปได้ว่าโมเดลตีความเกินจริง ห้องที่อยู่ติดกันทั้งสองเป็น lore/combat จึงมีพื้นฐานของทริกเกอร์การซุ่มโจมตีเชิงเนื้อเรื่องที่อ่อน ปฏิเสธ

ขอใหม่ครั้งที่ 2:

two_story_layout ไม่มีในพจนานุกรมและซ้อนกับ vertical_layout เอาออก
ambush_setup ก็เอาออก — มีศัตรูไม่ได้แปลว่าซุ่มโจมตี
// (เจตนา: แท็ก narrative ใช้เฉพาะเมื่อมีการระบุเจตนาเชิงเนื้อเรื่อง การต่อสู้ธรรมดาแสดงด้วย type อยู่แล้ว)
ไม่ต้องฝืนเติมช่องว่างก็ได้ 3~4 อันคือปกติ ติดแท็กให้ใหม่

ผลลัพธ์ครั้งที่ 2 ของ Claude:

scholar_theme, vertical_layout, water_hazard

คราวนี้ลดเหลือ 3 อัน, ทั้งหมดอยู่ในพจนานุกรม, และไม่มีการซ้ำหมวด คนยอมรับผลลัพธ์นี้ tags: [scholar_theme, vertical_layout, water_hazard] ของแบบฟอร์มห้องจึงถูกยืนยันเช่นนี้

บทเรียนของบันทึกเซสชันจริงนี้มีสองบรรทัด ประการแรก AI overfit กับรายละเอียดหนึ่งของอินพุต ("2 ชั้น") แล้วออกไปนอกพจนานุกรม — ด่านบังคับตามพจนานุกรมต้องจับสิ่งนี้ที่ระดับโค้ด ประการที่สอง AI มีแนวโน้มจะพยายามเติมช่องว่าง — ถ้าไม่ระบุชัดว่า "ไม่ต้องฝืนเติม" มันจะพยายามถมทั้ง 5 ช่องให้เต็ม ความล้มเหลวทั้งสองนี้พบบ่อย และวิธีรักษาทั้งสองจะมีเสถียรภาพได้ต่อเมื่อถูกบังคับจากรูลบุ๊ก (พจนานุกรม + เพดาน) ไม่ใช่จากพรอมต์

7.1.8 การผลิตเมตาดาตาจำนวนมาก — ใครเติมและใครตรวจสอบ

ถ้านักออกแบบเติมเมตาห้อง 1 ห้องด้วยมือ จะใช้เวลา 5\~10 นาที ดันเจี้ยน 1 อัน (20\~30 ห้อง) ก็ 2\~5 ชั่วโมง ดันเจี้ยน 100 อันก็ 200\~500 ชั่วโมง (การประมาณของผู้เขียน ยังไม่ได้ตรวจสอบ — ค่าสูงสุดที่คำนวณจากเวลาป้อนข้อมูลเฉลี่ยต่อห้อง × จำนวนห้อง) ถ้าเติมด้วยมือทั้งหมด นักออกแบบก็จะกลายเป็นทาสการป้อนเมตาดาตา

ด้วยเหตุนี้จึงแบ่งผู้รับผิดชอบการเติมตามแต่ละพื้นที่

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

7.1.9 การนำห้องกลับมาใช้และกับดักของมัน

ผลที่ใหญ่ที่สุดของมาตรฐานมาสเตอร์คือการนำห้องกลับมาใช้ ถ้ามีห้องที่ค้นหาได้ด้วยแท็ก 30 ห้อง ก็สร้างดันเจี้ยน 5\~10 อันได้จากการผสมผสาน แต่เมื่ออัตราการนำกลับมาใช้สูงขึ้น ดันเจี้ยนจะน่าเบื่อ ด้วยเหตุนี้จึงวาง guardrail ไว้คู่กับการนำกลับมาใช้

การนำกลับมาใช้เป็นวิธีลดต้นทุน ไม่ใช่จุดประสงค์ พอตั้งอัตราการนำกลับมาใช้เป็น KPI เมื่อใด ประสบการณ์ผู้เล่นก็จะจืดชืดลง ถ้า 0% (ทุกห้องใหม่หมด) ต้นทุนการผลิตจำนวนมากจะระเบิด และถ้าเกิน 70% ดันเจี้ยนจะแยกแยะจากกันไม่ออก จากประสบการณ์ ช่วง 30\~40% คือจุดสมดุลระหว่างต้นทุนกับความหลากหลาย (เป็นการสังเกตเชิงทิศทาง ค่าเกณฑ์ที่แม่นยำต่างกันไปตามแต่ละโปรเจกต์)

7.1.10 ความล้มเหลวที่พบบ่อยและวิธีรักษา

7.1.11 การแยก Layer คือเงื่อนไขเบื้องต้นของการสร้างเลเวลแบบโพรซีเดอรัล

โครงสร้างของ 7.1.2\~7.1.6 ที่คลี่ออกด้วยรูลบุ๊ก·การสร้าง·การตรวจสอบที่ผ่านมาทั้งหมดนั้นเอง คือผลผลิตของการแยก Layer ข้อเสนอทั่วไปที่ว่าการแยก Layer คือเงื่อนไขเบื้องต้นของการสร้างแบบโพรซีเดอรัล·การทำงานอัตโนมัติ (L0 จุดยึด → L1 รูลบุ๊ก → L2 เนื้อหา → L3 ค่าตัวเลข → L4 ด่าน, ถ้าเป็นก้อนเดียวการสร้างจะพังทลาย) ได้กล่าวถึงใน §6.6 แล้ว ตรงนี้นำสิ่งนั้นมาประยุกต์ใช้กับการบริหารเมตาดาตาเลเวล

ถ้าไม่มีการแบ่งแยกนี้ การจัดวางห้อง·BSP·การกำหนดจังหวะ·ทริกเกอร์เชิงเนื้อเรื่องจะปนกันในไฟล์เดียว และทุกครั้งที่ขยับห้องหนึ่งช่อง เจตนาการกำหนดจังหวะ·ช่องเหตุการณ์·กราฟความเชื่อมต่อก็จะพังพร้อมกัน เป็นสถานการณ์ที่ห้องเขียนแบบ·โกดังวัสดุ·ห้องตรวจสอบกองรวมกันบนโต๊ะตัวเดียว พอดึงแบบแปลนออกหนึ่งแผ่น ใบส่งของวัสดุและตารางตรวจสอบก็หลุดออกมาด้วย ด้วยเหตุนี้ การที่ AI ช่วยใน 7.1.7 ทำงานได้ก็เป็นเพราะ Layer เช่นกัน ห้อง ID·ความเชื่อมต่อถูกเติมจากเอดิเตอร์ (ดึงอัตโนมัติ L3), แท็กจาก AI (บังคับตามพจนานุกรม L1), difficulty_label จากการรวม (L3→L4) การทำงานอัตโนมัติวางทับอยู่บนขอบเขตของ Layer ถ้าวางทับอยู่บนก้อนเดียว อุบัติเหตุจะระเบิดขึ้นภายในอัปเดตแรก และตัวเครื่องมือเองก็จะถูกทิ้ง

แต่นี่ไม่ได้หมายความว่าต้องมีลิ้นชักห้าช่องครบสมบูรณ์ตั้งแต่แรก หลักการคือ แบ่งแยกแบบค่อยเป็นค่อยไป อินเทอร์เฟซให้แคบ ในอัปเดตแรก แค่แยกรูลบุ๊ก L1 (พจนานุกรมแท็ก + กฎความเชื่อมต่อ) กับชีต L3 (ชีตเมตาห้อง) ก็เกิดที่ให้การทำงานอัตโนมัติเข้ามาได้แล้ว เจตนาการกำหนดจังหวะ L0 และด่านตรวจสอบ L4 ค่อยเติมขณะผ่านแต่ละอัปเดต เมื่อมาตรฐานเป็นหนึ่งเดียวจึงเกิดที่ให้การทำงานอัตโนมัติเข้ามา และยิ่งการทำงานอัตโนมัติเข้ามามากเท่าใด นักออกแบบก็ยิ่งมุ่งไปที่การตัดสินเรื่องการกำหนดจังหวะ·ซิกเนเจอร์·การนำกลับมาใช้ แทนที่จะทำงานมือทีละห้อง

สรุปประเด็นสำคัญของบท

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

ลองทำดู

setup. เลือกดันเจี้ยนหนึ่งอัน แล้วสร้างชีต YAML ที่มีเพียงสี่ฟิลด์ room_id · type · connections · tags ต่อแต่ละห้อง ส่วนแท็ก ให้ตรึงพจนานุกรม 5 หมวดประมาณ 30 enum ลงบนกระดาษหนึ่งแผ่นก่อน

prompt. ใส่ภาพหน้าจอห้อง + พื้นที่ + ชนิดศัตรู + type ห้องที่อยู่ติดกัน แล้วขอด้วย "เลือกแท็ก 3\~5 อันจากพจนานุกรมนี้เท่านั้น ห้ามแท็กนอกพจนานุกรม ไม่ต้องเติมช่องว่าง" (พรอมต์ 7.1.7 ตามเดิม)

verify. (1) ถ้าผลลัพธ์ของ AI มีแท็กนอกพจนานุกรม ให้ปฏิเสธและขอใหม่ (2) สร้างกราฟจาก connections แล้วตรวจสอบการเข้าถึงจากเริ่มต้น→บอสและทางตัน — ถ้ามีการละเมิดแม้แต่อันเดียว ให้ทำเครื่องหมายว่าห้องนั้นบิลด์ไม่ได้

ฉบับย่อสำหรับคนเดียว

ถ้าคุณเป็นนักพัฒนาคนเดียวที่ไม่มีโครงสร้างพื้นฐานของเครื่องมือ ให้เริ่มเอกสารมาสเตอร์ด้วยมาร์กดาวน์หนึ่งแผ่น พจนานุกรมแท็ก 30 บรรทัด, กฎความเชื่อมต่อ 5 บรรทัด, เช็กลิสต์การตรวจสอบ 5 บรรทัด ก็เพียงพอ สำหรับการตรวจสอบกราฟ ถ้ามีห้องไม่เกิน 10 ห้อง แค่วาดลูกศรลงบนกระดาษแล้วตรวจดูทางตันด้วยตาเปล่า ก็ได้ผล 80% ของประสิทธิภาพ หัวใจไม่ได้อยู่ที่เครื่องมือ แต่อยู่ที่นิสัยของการ "ติดข้อมูลให้กับห้อง แล้วตรวจสอบข้อมูลนั้นด้วยกฎ" เอง เครื่องมือค่อยเพิ่มเข้ามาเมื่อห้องเกิน 50 ห้องจนตรวจด้วยมือเริ่มหนักเกินไป

ตัวอย่างบทถัดไป

• 7.2 เอดิเตอร์ BehaviorTree — บริหารทรีพฤติกรรม AI ซึ่งเป็นพื้นที่ข้างเคียงของเลเวล โดยอิงจากรูลบุ๊ก·เมตาดาตา

7.2 เอดิเตอร์ BehaviorTree — บันทึกเซสชันจริงที่คนกับ AI ร่วมกันแก้ไขและตรวจสอบ BT json

จอมเวทฝึกหัดตัวหนึ่งวิ่งเข้าประชิดผู้เล่นแล้วฟันดาบใส่ มันคือ NPC ที่ออกแบบให้เป็นผู้ร่ายเวทระยะไกล HP บางเหมือนกระดาษ ถ้าโดนระยะประชิดแค่ครั้งเดียวก็ตาย แต่มันกลับไม่คิดจะถอยห่าง บันทึกการบิลด์ไม่มีข้อผิดพลาดใด ๆ เปิด BehaviorTree ในเอดิเตอร์ขึ้นมาดูอีกครั้ง โหนดก็ยังเชื่อมต่อกันเรียบร้อยดี หลังจากเพ่งดูอยู่ชั่วโมงหนึ่งจึงพบสาเหตุ เงื่อนไขระยะของกิ่งถอยถูกใส่ค่าเป็น 0.5 ไม่ใช่ 5 ทั้งที่มันควรหนีเมื่อศัตรูเข้ามาในระยะ 5 เมตร แต่กลับเป็น 0.5 เมตร — นั่นคือกิ่งถอยจะไม่ทำงานเลยจนกว่าจะเกือบจ่อหน้ากัน

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

7.2.1 จุดที่ BT (BehaviorTree, ต้นไม้พฤติกรรม) หลุดมือไป

BehaviorTree คือโครงสร้างมาตรฐานโดยพฤตินัยที่ใช้นิยามการต่อสู้ การเคลื่อนที่ และการตอบสนองของ NPC ฝ่ายศัตรู ตัวเลือก (selector) จะลองกิ่งต่าง ๆ ตามลำดับความสำคัญ ส่วนลำดับ (sequence) จะร้อยเงื่อนไขกับแอ็กชันเข้าด้วยกันตามลำดับ ตัวโครงสร้างเองนั้นเรียบง่าย ปัญหาอยู่ที่ขนาด

ในโปรเจกต์ A ของผู้เขียน BT ของ NPC ศัตรูหนึ่งตัวประกอบด้วยโหนดราว 50\~200 โหนด และ NPC ที่เปิดให้บริการมีมากกว่า 100 ตัว เมื่อคูณกันแล้ว จำนวนโหนด BT ทั้งหมดจะอยู่ในหลักหมื่น ที่ขนาดเท่านี้ จะมาถึงจุดที่คนตอบคำถามอย่าง "ถ้าเปลี่ยนแพตเทิร์นถอยนี้ NPC ตัวไหนจะได้รับผลกระทบบ้าง" ไม่ได้อีกต่อไป มันก็เหมือนกับมีสมุดร้อยเล่มกางอยู่บนโต๊ะ พอแก้บรรทัดหนึ่งในเล่มแรก ก็ต้องคอยกวาดสายตาตามว่าผลจะลามไปที่ไหนในอีกเก้าสิบเก้าเล่มที่เหลือ

สิ่งที่ผู้เขียนเรียกร้องตอนย้ายจาก BT แบบกราฟิกมาเป็น json มีอยู่สี่อย่าง

เอดิเตอร์ BT ในตัวของเอนจินเกมเชิงพาณิชย์นั้นผสานรวมได้สะดวกและดีบักเชิงภาพได้แข็งแรง เพียงแต่มันมักถูกบันทึกเป็นแอสเซตแบบไบนารี (binary) จึงอ่อนเรื่อง diff ของข้อความและการตามรอยผลกระทบของการเปลี่ยนแปลง เนื่องจากโปรเจกต์ A ของผู้เขียนตั้งสมมติฐานว่าเป็นเกมไลฟ์ที่มี BT เปิดให้บริการเกิน 100 ตัว จึงเลือกทางพัฒนาฟอร์แมต BT แบบ json และเอดิเตอร์ขึ้นเองต่างหาก ขอชี้ให้ชัด นี่ไม่ใช่คำตอบที่ถูกของทุกทีม ถ้า BT ที่เปิดให้บริการมีไม่ถึง 50 ตัว การใช้เอดิเตอร์ในตัวของเอนจินไปเลยมักจะถูกกว่าเสมอ เหตุผลรองรับการพัฒนาเองจะกล่าวถึงอีกครั้งตอนท้ายบทนี้

7.2.2 BT json — แปลงพฤติกรรมของศัตรูหนึ่งตัวเป็นข้อความ

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

{
  "bt_id": "bt_scholar_archer_v3",
  "category": "ranged_combatant",
  "tags": ["scholar_faction", "ranged", "support"],
  "description": "แบบสนับสนุนระยะไกลแห่งกิลด์นักปราชญ์ รักษาระยะ + ถอยเป็นลำดับแรก",
  "root": {
    "type": "selector",
    "children": [
      {
        "type": "sequence",
        "name": "low_hp_retreat",
        "children": [
          {"type": "condition", "fn": "hp_below", "param": 0.3},
          {"type": "subtree_ref", "id": "subtree_retreat_to_ally"}
        ]
      },
      {
        "type": "sequence",
        "name": "kite_pattern",
        "children": [
          {"type": "condition", "fn": "enemy_in_close_range", "param": 5},
          {"type": "action", "fn": "move_away", "param": {"distance": 8}}
        ]
      },
      {"type": "subtree_ref", "id": "subtree_ranged_attack_pattern"}
    ]
  }
}

หากกางต้นไม้นี้ออกมาเป็นภาพ จะเป็นโครงสร้างที่ตัวเลือกลองกิ่งทั้งสามจากบนลงล่าง ขอให้สังเกตว่าบั๊กในตอนต้นบท — param ของ enemy_in_close_range เป็น 5 หรือ 0.5 — กลายเป็นบรรทัดเดียวที่มองเห็นได้ในพริบตาเมื่ออยู่ใน json

flowchart TD
    R["selector
(จากบนลงล่างตามลำดับความสำคัญ)"]
    R --> A["sequence: low_hp_retreat"]
    R --> B["sequence: kite_pattern"]
    R --> C["subtree_ref:
subtree_ranged_attack_pattern"]
    A --> A1["condition: hp_below 0.3"]
    A --> A2["subtree_ref:
subtree_retreat_to_ally"]
    B --> B1["condition: enemy_in_close_range 5"]
    B --> B2["action: move_away dist=8"]

    style C fill:#e8f0fe,stroke:#4285f4
    style A2 fill:#e8f0fe,stroke:#4285f4
    style B1 fill:#fce8e6,stroke:#ea4335

enemy_in_close_range 5 ที่ระบายสีแดงไว้คือโหนดที่กินเวลาคนไปหนึ่งชั่วโมงในตอนต้นบท เมื่ออยู่ใน json มันถูกจับได้ในการรีวิวโค้ดเพียงครั้งเดียว

7.2.3 ไลบรารี subtree — อ้างอิงแทนการก๊อบวาง

ในพฤติกรรมของศัตรูที่มีมากกว่า 100 ตัว มีก้อนที่เกิดซ้ำ ๆ อยู่ เช่น "ถอยไปหลังพันธมิตร" "ถอยไปหลังที่กำบัง" "แพตเทิร์นโจมตีระยะไกล" ถ้าก๊อบสิ่งเหล่านี้ใส่ลงในทุก BT พอจะแก้ลอจิกถอยเพียงตัวเดียว ก็ต้องไล่หาแก้ด้วยมือเป็นร้อยจุด ดังนั้นแพตเทิร์นร่วมจึงถูกแยกออกไปเป็นไฟล์ subtree ต่างหาก แล้วอ้างอิงด้วย subtree_ref เท่านั้น

subtree_library/
├── retreat_patterns/
│   ├── subtree_retreat_to_ally.json
│   ├── subtree_retreat_to_cover.json
│   └── subtree_retreat_random.json
├── attack_patterns/
│   ├── subtree_ranged_attack_pattern.json
│   ├── subtree_melee_combo.json
│   └── subtree_aoe_attack.json
└── reaction_patterns/
    ├── subtree_react_to_ally_death.json
    └── subtree_react_to_player_taunt.json

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

# bt_impact_tracker.py
import json, glob

def has_subtree_ref(node, target_id):
    if isinstance(node, dict):
        if node.get("type") == "subtree_ref" and node.get("id") == target_id:
            return True
        for child in node.get("children", []):
            if has_subtree_ref(child, target_id):
                return True
    return False

def find_affected_bts(subtree_id):
    affected = []
    for bt_file in glob.glob("bts/*.json"):
        bt = json.load(open(bt_file, encoding="utf-8"))
        if has_subtree_ref(bt["root"], subtree_id):
            affected.append(bt["bt_id"])
    return affected

# วิธีใช้
affected = find_affected_bts("subtree_ranged_attack_pattern")
# → ["bt_scholar_archer_v3", "bt_ranger_v2", "bt_sniper_v1", ...]

ในโปรเจกต์ A ของผู้เขียน ฟังก์ชันนี้ถูกผูกไว้กับขั้นตอนคำขอเปลี่ยนแปลง (Pull Request) เมื่อมีใครไปแตะไฟล์ subtree รายการ BT ที่ได้รับผลกระทบจะถูกแปะเป็นคอมเมนต์ใน PR โดยอัตโนมัติ ผู้รีวิวจะได้เห็นข้อเท็จจริงที่ว่า "แก้แพตเทิร์นถอยไปบรรทัดเดียว แต่ศัตรูระยะไกล 12 ตัวเปลี่ยนหมด" ก่อนที่จะ merge

7.2.4 บันทึกเซสชันจริง — หนึ่งรอบที่ AI เขียนร่าง BT ใหม่

จากตรงนี้ไปคือช่วงที่มีน้ำหนักมากที่สุดของบทนี้ ผู้เขียนมอบหมายให้ AI ร่าง BT ของ NPC ศัตรูตัวใหม่ "จอมเวทฝึกหัด" แล้วนำหนึ่งรอบของการที่คนตรวจสอบ·ปฏิเสธ·ขอใหม่ต่อผลลัพธ์นั้น มาวางไว้ตามจริงโดยไม่ขัดเกลา การไม่ย่อให้ลื่นไหลมีเหตุผลของมัน เพราะว่า AI ทำอะไรผิดอย่างไรในผลลัพธ์ครั้งแรก ลายเส้นของความล้มเหลวนั้นแหละคือทั้งหมดที่บทนี้ต้องการสื่อ

Step 1 — พรอมต์ที่คนโยนเข้าไป (ฉบับเต็ม)

[คอนเซปต์ NPC ศัตรู]
จอมเวทฝึกหัดแห่งกิลด์นักปราชญ์ HP ต่ำ ดาเมจเวทมนตร์สูง
หลบระยะประชิดเป็นลำดับแรก ถอยไปหลังพันธมิตรแล้วค่อยโจมตีด้วยเวทมนตร์

[category] ranged_combatant

[BT อ้างอิง] bt_scholar_archer_v3
(โครงสร้างคล้ายกัน เพียงแต่เปลี่ยนจากโจมตีด้วยธนูเป็นโจมตีด้วยเวทมนตร์)

[enum ฟังก์ชันที่นิยามไว้]
condition: hp_below, enemy_in_close_range, ally_nearby, mana_below
action: move_away, cast_spell, retreat, wait
subtree_ref id (รายการที่ใช้ได้):
- subtree_retreat_to_ally
- subtree_ranged_attack_pattern   # อิงธนู ไม่ใช่สำหรับเวทมนตร์
- subtree_magic_attack_pattern

ช่วยเขียนเฉพาะ json ของโหนด root ของ BT ตามคอนเซปต์นี้ ใช้ subtree_ref ให้มากที่สุดและโหนดตรง ๆ ให้น้อยที่สุด
ฟังก์ชันให้อยู่ภายใน enum ข้างบนเท่านั้น อย่าเพิ่มพฤติกรรมที่ไม่มีในคอนเซปต์ ไม่ต้องอธิบาย เอาแค่ json

Step 2 — ผลลัพธ์ครั้งที่ 1 ของ Claude (วางตามจริงโดยไม่ปรุงแต่ง)

{
  "bt_id": "bt_scholar_apprentice_v1",
  "category": "ranged_combatant",
  "tags": ["scholar_faction", "magic", "fragile"],
  "description": "จอมเวทฝึกหัดแห่งกิลด์นักปราชญ์ หลบระยะประชิด + ถอยไปหลังพันธมิตร + โจมตีด้วยเวทมนตร์",
  "root": {
    "type": "selector",
    "children": [
      {
        "type": "sequence",
        "name": "low_hp_retreat",
        "children": [
          {"type": "condition", "fn": "hp_below", "param": 0.4},
          {"type": "subtree_ref", "id": "subtree_retreat_to_ally"}
        ]
      },
      {
        "type": "sequence",
        "name": "avoid_melee",
        "children": [
          {"type": "condition", "fn": "enemy_in_close_range", "param": 6},
          {"type": "action", "fn": "move_away", "param": {"distance": 10}}
        ]
      },
      {
        "type": "sequence",
        "name": "mana_recover",
        "children": [
          {"type": "condition", "fn": "mana_below", "param": 0.2},
          {"type": "action", "fn": "wait", "param": {"frames": 120}}
        ]
      },
      {"type": "subtree_ref", "id": "subtree_ranged_attack_pattern"}
    ]
  }
}

Step 3 — การตรวจสอบ·ปฏิเสธของคน

รับผลลัพธ์มาแล้วเอาเข้า lint (จะกล่าวถึงในหัวข้อถัดไป) และอ่านด้วยตา มีสามจุดที่ติด

1. กิ่งสุดท้ายผิด subtree_ranged_attack_pattern คือแพตเทิร์นโจมตีที่อิงธนู ทั้งที่เขียนหมายเหตุไว้ใน enum ว่า "ไม่ใช่สำหรับเวทมนตร์" แล้ว AI ก็ยังหยิบแพตเทิร์นธนูที่ชื่อคล้ายกันมา จอมเวทฝึกหัดต้องใช้ subtree_magic_attack_pattern — ปฏิเสธ

2. เพิ่มพฤติกรรมที่ไม่มีในคอนเซปต์ กิ่ง mana_recover (mana_below → wait 120frame) เป็นพฤติกรรมที่ไม่มีในคอนเซปต์แม้แต่บรรทัดเดียว ทั้งที่ตอกย้ำไว้ในพรอมต์แล้วว่า "ห้ามเพิ่มพฤติกรรมที่ไม่ได้ระบุ" แต่ดูเหมือน AI จะตัดสินว่า "เป็นจอมเวทก็ต้องจัดการมานาเป็นเรื่องธรรมดา" แล้วยัดมันเข้าไป ดูสมเหตุสมผลก็จริงแต่เป็นการละเมิดสเปก — ปฏิเสธ

3. ค่าเกณฑ์การถอยน่าสงสัย hp_below 0.4 เริ่มถอยเร็วกว่า BT อ้างอิง (0.3) จอมเวทฝึกหัดอ่อนแอกว่าก็จริง จึงอาจเป็นความตั้งใจ เพียงแต่ AI ไม่เคยให้เหตุผล จึงเป็นเรื่องที่ดีไซเนอร์ต้องตัดสิน — พักไว้ ให้ดีไซเนอร์ยืนยัน

Step 4 — การขอใหม่ของคน

ช่วยแก้แค่สามจุด กิ่งสุดท้าย subtree_ranged_attack_pattern เป็นแพตเทิร์นธนู
ให้เปลี่ยนเป็น subtree_magic_attack_pattern และกิ่ง mana_recover ไม่มีในคอนเซปต์ ให้ลบทิ้งทั้งก้อน
hp_below 0.4 ให้ย้อนกลับไปเป็นค่าของ BT อ้างอิง (0.3) — ถ้ามีเหตุผลที่จะใช้ 0.4 ก็ใส่ไว้ใน description สักบรรทัด
ที่เหลือคงเดิม เอาแค่ json

Step 5 — ผลลัพธ์ครั้งที่ 2 ของ Claude (ฉบับแก้ไข)

{
  "bt_id": "bt_scholar_apprentice_v1",
  "category": "ranged_combatant",
  "tags": ["scholar_faction", "magic", "fragile"],
  "description": "จอมเวทฝึกหัดแห่งกิลด์นักปราชญ์ หลบระยะประชิด + ถอยไปหลังพันธมิตร + โจมตีด้วยเวทมนตร์ HP ต่ำจึงคงค่าเกณฑ์การถอย 0.3 ไว้ (เท่ากับ archer)",
  "root": {
    "type": "selector",
    "children": [
      {
        "type": "sequence",
        "name": "low_hp_retreat",
        "children": [
          {"type": "condition", "fn": "hp_below", "param": 0.3},
          {"type": "subtree_ref", "id": "subtree_retreat_to_ally"}
        ]
      },
      {
        "type": "sequence",
        "name": "avoid_melee",
        "children": [
          {"type": "condition", "fn": "enemy_in_close_range", "param": 6},
          {"type": "action", "fn": "move_away", "param": {"distance": 10}}
        ]
      },
      {"type": "subtree_ref", "id": "subtree_magic_attack_pattern"}
    ]
  }
}

ผลลัพธ์ครั้งที่ 2 ผ่าน lint และในการตรวจสอบของดีไซเนอร์ได้ปรับระยะ 6 ของ avoid_melee ให้ลงมาหนึ่งขั้นเป็น 5 ให้เท่ากับ archer ก่อนส่งต่อไปยังด่านจำลอง (simulation gate) สิ่งที่ได้เรียนรู้จากตรงนี้ชัดเจน AI เติมโครงร่างของ BT ได้เร็ว แต่เกือบทุกครั้งจะก่อสองความผิดพลาด คือ "ดึง subtree ที่ผิดซึ่งชื่อคล้ายกันเข้ามา" และ "ยัดพฤติกรรมเพิ่มที่ดูสมเหตุสมผลโดยไม่มีในสเปก" สองความผิดพลาดนี้จับได้ด้วยตาคนและด่าน lint เท่านั้น ฉะนั้นผลลัพธ์ของ AI จึงเป็นร่าง ไม่ใช่ฉบับสุดท้าย

7.2.5 lint อัตโนมัติ — เครื่องจับสิ่งที่คนมองข้ามได้ก่อน

BT เชื่อมโยงโดยตรงกับประสบการณ์ของผู้ใช้ ถ้าเหตุที่ศัตรูไม่ยอมหนีทั้งที่อยู่จ่อหน้าหลุดออกไปจนถึงตอนวางจำหน่าย มันจะย้อนกลับมาเป็นคะแนนรีวิว ดังนั้นก่อน merge เครื่องจะตรวจก่อน

ข้อสุดท้ายคือจุดพิเศษของ lint นี้ ถ้า BT ห้าตัวที่ถูกจัดเป็น ranged_combatant เดียวกัน มีเวลาตอบสนองเฉลี่ยในการจำลองห่างกันมาก นั่นคือสัญญาณว่ามีใครทำลายสมดุลของตัวหนึ่งโดยไม่รู้ตัว มันคือกลไกที่จับ "บรรยากาศ" ซึ่งการตรวจแบบสถิต (static) จับไม่ได้ ด้วยสถิติ

ถัดจาก lint แบบสถิตคือการตรวจสอบด้วยการจำลอง รัน BT ในตัวจำลอง 1,000 ครั้งโดยไม่ต้องบิลด์เกมจริงแล้วดึงสถิติออกมา

โดยไม่ต้องบิลด์ก็ดู "ว่า BT นี้ตายเร็วเกินไปหรือไม่" "วนทำพฤติกรรมเดียวซ้ำ ๆ หรือไม่" ได้ภายใน 5\~10 นาที ถ้ามีสัญญาณผิดปกติขึ้นมา ก็แก้ json แล้วรันจำลองอีกครั้ง การที่รอบนี้หดจากหน่วยวันลงมาเหลือหน่วยนาที คือกำไรที่แท้จริงของการทำให้เป็น json

flowchart LR
    P["คน/AI
แก้ไข BT json"] --> L{"lint แบบสถิต"}
    L -->|บล็อก| P
    L -->|ผ่าน| R["ดีไซเนอร์ตรวจสอบ"]
    R -->|ปฏิเสธ| P
    R -->|อนุมัติ| S{"จำลอง 1,000 ครั้ง"}
    S -->|สัญญาณผิดปกติ| P
    S -->|ปกติ| M["merge + สะท้อนผลในบิลด์"]
    style L fill:#fef7e0,stroke:#fbbc04
    style S fill:#fef7e0,stroke:#fbbc04
    style M fill:#e6f4ea,stroke:#34a853

7.2.6 การวัดผล — อะไรลดลงบ้าง

วางสภาพก่อน·หลังการนำมาใช้ในโปรเจกต์ A ของผู้เขียนเป็นตาราง ตัวเลขสัมบูรณ์จะต่างกันไปตามขนาดทีม·แนวเกม จึงเป็นการประมาณของผู้เขียน (ยังไม่ได้ตรวจสอบ) เพียงแต่ทิศทางและสัดส่วนเป็นไปตามที่สังเกตได้จริงจากการให้บริการ

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

7.2.7 พัฒนาเอง หรือหยิบยืมมาใช้

ถ้าอ่านบทนี้แล้วสรุปว่า "เราก็มาทำเอดิเตอร์ json BT กันเถอะ" จะเป็นเรื่องลำบาก ที่โปรเจกต์ A ของผู้เขียนเลือกพัฒนาเองเป็นเพราะเงื่อนไขเฉพาะหลายอย่างลงตัวพอดี

เหตุผลที่โปรเจกต์ A เลือกข้อ 3 มีสี่อย่าง

• การตามรอยด้วย diff·git เป็นสิ่งจำเป็น — BT ในตัวเป็นแอสเซตแบบไบนารี จึงตามรอยเหตุ "ตัวเลขเพียงตัวเดียว" ในตอนต้นบทไม่ได้
• การอ้างอิง subtree และการตามรอยผลกระทบอัตโนมัติเป็นแกนหลักของการให้บริการ — เป็นฟังก์ชันที่เครื่องมือ BT มาตรฐานอ่อนแอ
• ต้องรันการตรวจสอบด้วยการจำลองในรันไทม์ที่แยกออกจากบิลด์
• ตั้งสมมติฐานให้ AI ช่วยเขียน — ฐานข้อความ (json) เป็นมิตรกับโมเดลภาษาขนาดใหญ่ (LLM, Large Language Model) อย่างท่วมท้น

ต้นทุนพัฒนาคือ 1\~2 เดือน จะคุ้มทุนก็ต่อเมื่อ BT ที่เปิดให้บริการแตะ 100\~300 ตัว และมีระยะการให้บริการแบบไลฟ์ที่ยาวนาน ที่ขนาด 30\~50 ตัว คืนทุนไม่ได้ หมายความว่าผลตอบแทนการลงทุน (ROI, Return On Investment) ของการพัฒนาเอง จะออกมาก็ต่อเมื่อทั้งขนาดและระยะการให้บริการได้รับการรับประกันทั้งสองอย่างเท่านั้น ถ้าเป็นทีมเล็ก ควรหยิบเอาแค่หลักการจากบทนี้ไป คือ "บันทึกเป็น json" "อ้างอิงด้วย subtree" "ผลลัพธ์ AI ต้องผ่านด่าน lint + ตรวจสอบ" แล้วใช้เครื่องมือโดยวางทับบนเอดิเตอร์ในตัวหรือไลบรารีภายนอกจะถูกต้องกว่า

7.2.8 ความล้มเหลวที่พบบ่อย

สรุปประเด็นสำคัญของบท

• ต้องบันทึก BT เป็น json เหตุ "ตัวเลขเพียงตัวเดียว" จึงจะเหลืออยู่ใน git diff และถูกตามรอยได้
• การอ้างอิง subtree และการตามรอยผลกระทบอัตโนมัติช่วยกันนรกของการก๊อบวางในการให้บริการ 100 ตัว
• AI เติมโครงร่าง BT ได้เร็ว แต่การอ้างอิงที่ผิดและพฤติกรรมนอกสเปกนั้นคนเป็นผู้จับ

ลองทำดู

นี่คือรอบขั้นต่ำที่ทีมเล็กลองทำได้วันนี้

setup — ลองเขียน BT ของ NPC ศัตรูที่กำลังเปิดให้บริการอยู่หนึ่งตัวเป็น json ด้วยมือ (bt_id, category, tags, root) แยกก้อนแพตเทิร์นถอย·โจมตีร่วมหนึ่งก้อนออกมาเป็น subtree_library/ แล้วอ้างอิงด้วย subtree_ref

prompt — มอบหมายศัตรูตัวใหม่ที่คล้ายกันให้ AI ใช้โครงร่างพรอมต์ของบันทึกเซสชันจริงข้างต้น (คอนเซปต์ + category + BT อ้างอิง + enum ฟังก์ชันที่ใช้ได้ + "ห้ามเพิ่มพฤติกรรมที่ไม่ได้ระบุ" + "เอาแค่ json") ตามนั้นได้เลย

verify — ให้นำผลลัพธ์ของ AI ผ่านสามด่านนี้ก่อนเท่านั้นจึงค่อย merge คือ (1) lint ที่กรองฟังก์ชันนอก enum·subtree ที่ไม่มีอยู่จริง (2) ตาคน (3) การจำลองหรือการตรวจสอบสั้น ๆ ในเกม ต้องตรวจให้แน่ใจว่า AI ยัด "subtree ที่ผิดซึ่งชื่อคล้ายกัน" และ "พฤติกรรมนอกสเปกที่ดูสมเหตุสมผล" เข้ามาหรือไม่

ฉบับย่อสำหรับคนเดียว

ถ้าไม่มีกำลังจะสร้างเอดิเตอร์ เครื่องมือก็แค่โปรแกรมแก้ไขข้อความกับ git และ bt_impact_tracker.py ความยาว 30 บรรทัดหนึ่งไฟล์ก็เพียงพอ ส่งออก BT ที่เขียนด้วยเอดิเตอร์ในตัวเป็น json สักครั้งแล้วเอาขึ้น git แยกเฉพาะ subtree ออกเป็นไฟล์ต่างหากแล้วอ้างอิง ถ้าผูกสคริปต์ตามรอยผลกระทบไว้กับ commit hook แม้อยู่คนเดียวก็เห็น "ว่าถ้าแก้แพตเทิร์นถอยนี้แล้วศัตรูตัวไหนจะเปลี่ยน" เป็นผลลัพธ์ ไม่ใช่การประมาณ ลำพังนิสัยเพียงข้อเดียวนี้ ก็ทำให้ "ตัวเลขเพียงตัวเดียวกินเวลาหนึ่งชั่วโมง" ในตอนต้นบท ลดลงเหลือการรีวิวโค้ดเพียงบรรทัดเดียว

ตัวอย่างบทถัดไป

• 7.3 ไลบรารีแพตเทิร์นดันเจี้ยน·สนาม — ผสานเมทาดาตาของห้องกับแพตเทิร์น subtree เพื่อมัดรวมเลเวลเป็นหน่วยของการให้บริการ

7.3 ไลบรารีแพตเทิร์นของดันเจี้ยนและสนาม

ในที่ประชุมรีวิวดันเจี้ยน นักออกแบบเลเวล (Level Design) คนใหม่ได้นำดันเจี้ยนของตนเองหนึ่งอันขึ้นจอ ทางเดินแคบ ศัตรูที่เคลื่อนเร็วไล่ตามมาจากด้านหลัง การตัดสินใจหลบหลีกที่จุดแยกทาง มันเป็นดันเจี้ยนที่ทำมาดี ปัญหาคือมันแตกต่างเพียงเล็กน้อยจากที่เราเคยทำมาแล้วในดันเจี้ยนอีกสิบเอ็ดอัน ความเร็วในการไล่ตามของศัตรู จังหวะที่กับดักทำงาน ช่วงเวลาที่จุดแยกทางปรากฏ ไม่มีสิ่งใดเหมือนกันเลย คนใหม่เชื่อว่าตนได้สร้างประสบการณ์ที่ใช้ชื่อเดียวกันคือ "ดันเจี้ยนไล่ล่า" แต่ความรู้สึกที่ผู้ใช้ได้รับนั้นต่างกันไปในแต่ละดันเจี้ยน

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

หากห้อง (room) เป็นหน่วยของพื้นที่ และ BehaviorTree เป็นหน่วยของพฤติกรรม แพตเทิร์นก็คือหน่วยปฏิบัติการที่มัดพื้นที่ พฤติกรรม และเหตุการณ์เข้าด้วยกันเป็นหนึ่งเดียว เมื่อแพตเทิร์นหนึ่งถูกนำกลับมาใช้ซ้ำในดันเจี้ยนหลายอัน ภาระในการผลิตจำนวนมากก็ลดลง และที่สำคัญกว่านั้นคือ ประสบการณ์ที่ผู้ใช้ได้รับจะมีความสอดคล้องกันระหว่างดันเจี้ยนต่าง ๆ

7.3.1 แพตเทิร์นในฐานะหน่วยปฏิบัติการ

ลองนึกถึงสูตรอาหารในตำราทำอาหารก็จะเข้าใจได้แม่นยำ สูตรหนึ่งหน้าจะมีวัตถุดิบ ลำดับการปรุง ความแรงของไฟ และภาพอาหารที่ทำเสร็จอยู่ด้วยกัน แม้ร้านอาหารจะเปลี่ยนไป หากทำตามสูตรเดียวกันก็จะได้รสชาติเดียวกัน เพียงแต่อนุญาตให้มีการปรับแต่งเล็กน้อยในแต่ละร้านได้ แพตเทิร์นก็เช่นกัน พื้นที่ (ห้อง) พฤติกรรม (BT subtree) เหตุการณ์ (event) ผลลัพธ์ (รางวัล/ระดับความยาก) และคำอธิบายเจตนาของนักออกแบบ ทั้งหมดนี้รวมอยู่เป็นชุดเดียวกัน

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

7.3.2 กระแสการประกอบแพตเทิร์น

หัวใจของไลบรารีแพตเทิร์นคือการตรึงแพตเทิร์นเป็น rulebook (กฎ/คู่มือกฎ) ไว้ แล้วนำมาประกอบกันเพื่อสร้างดันเจี้ยน นักออกแบบไม่ได้ร่างดันเจี้ยนจากจอเปล่า แต่เลือกแพตเทิร์นที่ตรวจสอบแล้วมาวางและปรับแต่งเพียงบางส่วน

flowchart TD
    A[สังเกตช่วงเวลาประสบการณ์ที่ดีในเกม] --> B[แยกย่อยเป็นพื้นที่·NPC·เหตุการณ์]
    B --> C[จับคู่กับเทมเพลตห้อง·subtree]
    C --> D{ผ่านการจำลอง + การทดสอบกับผู้ใช้?}
    D -- ไม่ --> B
    D -- ใช่ --> E[ลงทะเบียนแพตเทิร์นในไลบรารี
usage_count = 0]
    E --> F[(ไลบรารีแพตเทิร์น
5 หมวด · 30~50 อัน)]
    F --> G[ออกแบบดันเจี้ยน: เรียกอินสแตนซ์แพตเทิร์น]
    G --> H[การวาง placement + การปรับแต่ง overrides]
    H --> I{สัดส่วนการปรับแต่ง 20% หรือน้อยกว่า?}
    I -- ใช่ --> J[ดันเจี้ยนเสร็จสมบูรณ์
แพตเทิร์น usage_count +1]
    I -- ไม่ --> K[พิจารณาแยกเป็นแพตเทิร์นต่างหาก]
    K --> B
    J --> L[ติดตามผลกระทบของแพตเทิร์น
แก้แพตเทิร์นหนึ่ง → รวมยอดดันเจี้ยนที่ใช้โดยอัตโนมัติ]
    L --> F

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class L code;
    class F data;
    class J pass;

ครึ่งซ้ายของกระแสนี้ (สังเกต→แยกย่อย→จับคู่→ตรวจสอบ→ลงทะเบียน) คือกระบวนการสร้างแพตเทิร์น ส่วนครึ่งขวา (เรียกใช้→วาง/ปรับแต่ง→ทำให้เสร็จ→ติดตาม) คือกระบวนการบริโภคแพตเทิร์น งานสร้างเกิดขึ้นไม่บ่อย ส่วนงานบริโภคเกิดขึ้นบ่อยครั้ง เมื่อไลบรารีถูกบริหารดี ความไม่สมมาตรนี้จะนำไปสู่ประสิทธิภาพในการผลิตจำนวนมาก

7.3.3 ห้าหมวดพื้นฐาน

โปรเจกต์ A ของผู้เขียนเป็นเกมแนวแอ็กชัน RPG จึงจัดหมวดแพตเทิร์นไว้ห้าหมวด การจัดหมวดนี้ขึ้นอยู่กับแนวเกม หากเป็นเกมสยองขวัญ สัดส่วนของการซุ่มโจมตีและจังหวะของเนื้อเรื่องก็จะต่างไป และหากเป็นเกมปริศนา การต่อสู้ที่ใช้สภาพแวดล้อมก็จะมาเป็นศูนย์กลาง อย่ายึดติดกับการจัดหมวดเองเป็นสรณะ ควรกำหนดก่อนว่าประสบการณ์หลักของเกมตนเองคืออะไร แล้วจึงจับหมวดหมู่

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

7.3.4 รูปแบบที่ใช้ตรึงแพตเทิร์น

แพตเทิร์นหนึ่งถูกตรึงไว้ด้วยไฟล์ YAML หนึ่งหน้า ด้านล่างนี้คือรูปแบบที่ใช้จริงในโปรเจกต์ A ที่นำมาทำให้ไม่ระบุตัวตน (anonymize) แม้จะปิดบังชื่อทรัพย์สินเฉพาะของบริษัทและหมายเลขดันเจี้ยนไว้ แต่โครงสร้างฟิลด์และวิธีบริหารยังคงเดิม

---
pattern_id: pattern_corridor_pursuit_v2
category: pursuit
description: ศัตรูเร็วไล่ตามจากด้านหลังในทางเดินแคบ ผู้เล่นตัดสินใจหลบหลีกที่จุดแยกทาง
tags: [horizontal_corridor, scholar_theme_compatible]
rooms:
  - room_template: corridor_long
    size: medium
    connections_required: 2
  - room_template: junction_3way
    size: small
    connections_required: 3
npc_behaviors:
  - subtree_ref: subtree_aggressive_chase
    count: 2
  - subtree_ref: subtree_ranged_support
    count: 1
events:
  - type: trap_activation
    trigger: room_1_midpoint
  - type: enemy_spawn
    trigger: room_1_entry
difficulty_modifier: 1.2   # ภาระ 1.2 เท่าเมื่อเทียบกับห้องทั่วไป
reward_modifier: 1.3
clear_time_estimate_sec: 60
art_pack_compatible: [scholar_library, generic_dungeon]
narrative_slots:
  - slot: dialogue_during_chase
    constraints: [short_dialogue, fear_emotion]
usage_count: 12            # ใช้ในดันเจี้ยน 12 แห่ง
last_modified: 2026-05-18
deprecated: false
---

ไฟล์นี้นิยามส่วนหนึ่งของดันเจี้ยนสิบสองห้องพร้อมกัน น้ำหนักของบรรทัดเดียวที่ว่า usage_count: 12 มาจากตรงนั้น หมายความว่าหากแก้แพตเทิร์นนี้ ดันเจี้ยนสิบสองห้องจะได้รับผลกระทบพร้อมกัน ดังนั้นการแตะต้องไฟล์แพตเทิร์นจึงมีน้ำหนักต่างจากการแก้ห้องเพียงห้องเดียว

การอ้างอิงอย่าง subtree_aggressive_chase หรือ subtree_ranged_support ชี้ตรงไปยัง subtree ที่นิยามไว้ในเอดิเตอร์ BehaviorTree ของหัวข้อ 7.2 หัวใจคือการที่แพตเทิร์นไม่ได้บรรจุ BT ไว้โดยตรง แต่อ้างอิงเท่านั้น เมื่อแก้ BT แพตเทิร์นทุกอันที่อ้างอิง BT นั้นจะตามมาโดยอัตโนมัติ พื้นที่ (เทมเพลตห้อง) และพฤติกรรม (subtree) ถูกบริหารในไลบรารีของแต่ละฝ่าย และแพตเทิร์นทำหน้าที่เป็นเพียงตารางประกอบที่ร้อยทั้งสองเข้าด้วยกัน ค่าตัวเลขอย่าง clear_time_estimate_sec หรือ difficulty_modifier เป็นเพียงค่าปฏิบัติการของสภาพแวดล้อมของผู้เขียน ไม่ใช่ค่าคงที่สากล ต้องวัดด้วยตนเองจากการจำลองและการทดสอบกับผู้ใช้ของเกมตนเองแล้วจึงเติมลงไป

7.3.5 การสร้างอินสแตนซ์แพตเทิร์นในดันเจี้ยน

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

---
dungeon_id: dungeon_021_silvermark_library
pattern_instances:
  - instance: corridor_pursuit_1
    pattern_id: pattern_corridor_pursuit_v2
    placement:
      - room_id: dungeon_021_room_03
        as: corridor_long
      - room_id: dungeon_021_room_04
        as: junction_3way
    overrides:
      - field: npc_behaviors.0.subtree_ref
        value: subtree_scholar_chase   # ตัวแปรธีมนักวิชาการ
      - field: events.0.trigger
        value: room_1_2nd_third         # ปรับตำแหน่งทริกเกอร์เล็กน้อย
---

ตรงนี้ ดันเจี้ยน 021 ใช้แพตเทิร์น "ไล่ล่าในทางเดิน" ตามเดิม เพียงแต่เปลี่ยนศัตรูที่ไล่ตามจากศัตรูทั่วไปเป็นตัวแปรธีมนักวิชาการ และเลื่อนตำแหน่งที่กับดักทำงานจากกลางทางเดินไปด้านหลังเล็กน้อย แพตเทิร์น 80% ยังคงเดิม ปรับแต่งเพียง 20%

สัดส่วนนี้มีหลักฐานที่มาจากประสบการณ์ปฏิบัติการ หากปรับแต่งน้อยเกินไป (ใกล้ 0%) ดันเจี้ยนต่าง ๆ จะดูจำเจราวกับลอกกันมา หากปรับแต่งมากเกินไป (เกิน 50%) มันก็ไม่ใช่แพตเทิร์นเดียวกันอีกต่อไป กลับไปสู่สถานการณ์เดียวกับดันเจี้ยนที่คนใหม่นำมา คือเชื่อว่าเรียกแพตเทิร์นเดียวกันมา แต่ประสบการณ์จริงต่างกันโดยสิ้นเชิง ดังนั้นเราจึงตั้งกฎปฏิบัติการไว้ หาก overrides ของอินสแตนซ์หนึ่งเกินครึ่งหนึ่งของฟิลด์แพตเทิร์น นั่นไม่ใช่การปรับแต่ง แต่เป็นสัญญาณของแพตเทิร์นใหม่ ถึงเวลาแยกเป็นแพตเทิร์นต่างหากแล้ว

7.3.6 แก้บรรทัดเดียวแล้วตรงไหนสั่นคลอน

หากแก้ pattern_corridor_pursuit_v2 ดันเจี้ยนสิบสองห้องจะได้รับผลกระทบ หากคนติดตามเรื่องนี้ด้วยมือ ก็จะพลาดไปหนึ่งหรือสองห้องอย่างแน่นอน ดังนั้นเราจึงตั้งเครื่องมือเล็ก ๆ ที่ไล่ดูความสัมพันธ์ระหว่างแพตเทิร์นกับดันเจี้ยนโดยอัตโนมัติไว้

# pattern_impact.py
import json
from glob import glob

def find_dungeons_using(pattern_id):
    affected = []
    for d in glob("dungeons/*.json"):
        dungeon = json.load(open(d, encoding="utf-8"))
        for inst in dungeon.get("pattern_instances", []):
            if inst["pattern_id"] == pattern_id:
                affected.append({
                    "dungeon": dungeon["dungeon_id"],
                    "instance": inst["instance"],
                    "has_overrides": bool(inst.get("overrides")),
                })
    return affected

หัวใจของรายการที่ฟังก์ชันนี้ส่งคืนมาคือแฟล็ก has_overrides ดันเจี้ยนที่ไม่มี overrides ใช้แพตเทิร์นตามเดิม จึงปลอดภัยที่จะอัปเดตโดยอัตโนมัติ ส่วนดันเจี้ยนที่มี overrides การปรับแต่งเฉพาะของดันเจี้ยนนั้นอาจขัดแย้งกับการแก้แพตเทิร์นได้ จึงต้องมีการตรวจสอบโดยมนุษย์เพิ่มเติม

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

7.3.7 แพตเทิร์นถือกำเนิดอย่างไร และตำแหน่งของ AI

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

คำตอบชัดเจน ไม่ได้ การเขียนแพตเทิร์นหนึ่งอันมีอินไซต์ของนักออกแบบเป็นกระดูกสันหลัง ประสบการณ์ไล่ล่าที่ดีคืออะไร ทำไมจุดแยกทางต้องอยู่ตรงนั้น ทำไมกับดักต้องทำงานที่จุด 2/3 ไม่ใช่กลางทางเดินความตึงเครียดจึงจะมีชีวิต — นี่คือวิจารณญาณของคนที่ได้สัมผัสเกมจริงและเห็นปฏิกิริยาของผู้ใช้ หากให้ AI ร่างแพตเทิร์นจากศูนย์ แพตเทิร์นทั้งหมดจะลู่เข้าสู่รูปแบบที่ราบเรียบและกลาง ๆ ไลบรารีจะเต็มไปด้วย "แพตเทิร์นที่ไม่ผิด" แต่ "แพตเทิร์นที่น่าจดจำ" จะหายไป

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

ขั้นที่ 3 คือหัวใจของการช่วยเหลือโดย AI เมื่อนักออกแบบเขียนฉบับร่างว่า "ศัตรูเร็วไล่ตามจากด้านหลังในทางเดินแคบ" การที่คนต้องไล่ค้นเองทั้งหมดว่าอะไรเหมาะกับเจตนานี้ จากเทมเพลตห้องและไลบรารี subtree ที่สะสมไว้นับสิบ ๆ อันแล้วนั้นไม่มีประสิทธิภาพ ตรงนี้เราให้ AI แนะนำผู้สมัครการจับคู่ ด้านล่างนี้คือพรอมต์ที่ใช้จริงที่นำมาทำให้ไม่ระบุตัวตน

[อินพุต]
- yaml ฉบับร่างแพตเทิร์นของนักออกแบบ (แนบด้านล่าง)
- ไลบรารีเทมเพลตห้อง (ชื่อ + แท็ก + รายการขนาด)
- ไลบรารี subtree (ชื่อ + รายการสรุปพฤติกรรม)

ช่วยเลือกและแนะนำเทมเพลตห้องกับ subtree ที่จะใช้สร้างแพตเทิร์นนี้จากไลบรารีให้หน่อย
อย่างละ 2~3 อัน พร้อมความเหมาะสม 1~5 คะแนน และเหตุผลหนึ่งบรรทัดอ้างอิงเกณฑ์แท็ก·ขนาด
สิ่งที่ไม่มีในไลบรารีอย่ากุขึ้นมา ให้แนะนำเท่านั้น ถ้าทั้งหมดต่ำกว่า 3 คะแนน ให้บอกว่าจำเป็นต้องเขียนใหม่

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

ผู้สมัครเทมเพลตห้อง:
1. corridor_long  (ความเหมาะสม 5)
   เหตุผล: แท็ก horizontal_corridor ตรงกัน, size medium สอดคล้องกับเจตนา "ทางเดินแคบ"
2. corridor_narrow_short  (ความเหมาะสม 3)
   เหตุผล: แคบก็จริงแต่ความยาวสั้น จึงยากที่จะมีระยะไล่ล่าเพียงพอ พื้นที่วางจุดแยกทางไม่พอ
3. hall_wide  (ความเหมาะสม 1)
   เหตุผล: ห้องโถงกว้างตรงข้ามกับเจตนา "ทางเดินแคบ" ความกดดันจากการไล่ล่าไม่มีชีวิต

ผู้สมัคร subtree:
1. subtree_aggressive_chase  (ความเหมาะสม 5)
   เหตุผล: นิยามพฤติกรรมไล่ตามจากด้านหลังไว้ มีน้ำหนักความเร็วในการเคลื่อนที่
2. subtree_ranged_support  (ความเหมาะสม 3)
   เหตุผล: ตัวมันเองไม่ใช่การไล่ล่า แต่วางได้ 1 ตัวเพื่อช่วยกดดัน
3. subtree_patrol_basic  (ความเหมาะสม 2)
   เหตุผล: พฤติกรรมลาดตระเวนไม่ตรงกับเจตนาไล่ล่า ไม่มีโหนดเปลี่ยนเป็นการไล่ล่าหลังทริกเกอร์

เทมเพลตห้องจุดแยกทาง (junction):
ไม่พบรายการในไลบรารีที่ตอบสนองเงื่อนไขจุดแยก 3way + ขนาด small พร้อมกัน
junction_3way ใกล้เคียงที่สุด แต่แท็ก size ว่างอยู่ จึงไม่สามารถ
ยืนยันความเหมาะสมได้ จำเป็นต้องให้นักออกแบบตรวจสอบ

ย่อหน้าสุดท้ายคือส่วนที่มีค่าที่สุดในผลลัพธ์นี้ AI บอกว่า "ไม่แน่ใจ" เกี่ยวกับเทมเพลตห้องจุดแยกทาง และไม่ได้กุคำตอบที่ไม่มีอยู่ขึ้นมา นักออกแบบได้รับรายงานนี้แล้วก็พบความจริงว่าแท็ก size ของ junction_3way ว่างอยู่จริง ๆ จึงเริ่มเติมเมตาดาตานั้นก่อน หาก AI เพิกเฉยต่อแท็กที่ว่างแล้วให้ความเหมาะสม 5 นักออกแบบก็คงเลือกใช้ตามเดิมด้วยความเชื่อมั่นที่ผิดพลาด

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

[ป้ายชี้ทิศ — หากลองบีบอัดแพตเทิร์นเป็น 'เวกเตอร์ประสบการณ์' (ยังเร็วเกินไป)] โปรดอ่านในฐานะแนวโน้มการวิจัย ไม่ใช่ใบสั่งยา §7.3.1 เรียกแพตเทิร์นว่า 'สูตรอาหาร' อยู่แล้ว แพตเทิร์นหนึ่งใกล้เคียงกับค่าพิกัดที่เมตาห้อง·subtree พฤติกรรม·event·difficulty/reward_modifier·clear_time เป็นชุดเดียวกัน หากบีบอัดชุดนี้เป็น 'เวกเตอร์ประสบการณ์' เมื่อความเหมาะสมต่ำทั้งหมด ก็จับพื้นที่ว่างของปริภูมิที่บีบอัดเป็นจุดที่จะเขียนใหม่ แทนที่จะไล่ค้นกระแสข้างต้นทีละอัน และการตัดสิน deprecated ของ §7.3.8 ก็สามารถเสริมด้วยระยะพิกัดของความซ้ำซ้อนที่อยู่ใกล้กันได้ แต่มีเงื่อนไขสามข้อกำกับ difficulty/reward_modifier เป็นค่าปฏิบัติการของผู้เขียนตามที่ §7.3.4 บอกไว้ สเกลของแกนจึงต่างกันไปในแต่ละเกม จึงไม่สามารถยกปริภูมิที่บีบอัดไปใช้ตามเดิมได้ การประมาณค่า (interpolation) เป็นเพียงการ 'ชี้ป้าย' ช่องว่าง ไม่ใช่การ 'สร้าง' แพตเทิร์น และการเขียนแพตเทิร์นจริงบนป้ายนั้นก็ยังไม่ข้ามหลักการของหัวข้อนี้ที่ว่าอินไซต์ของนักออกแบบคือกระดูกสันหลัง แนวคิดนี้อยู่ตำแหน่งเดียวกับการบีบอัดเวกเตอร์มิติของ §8.2.7 และสัญชาตญาณเชิงแนวคิดอยู่ในภาคผนวก M — ขอเก็บไว้เป็นพื้นที่ที่ทีมซึ่งสะสมรากฐานเพียงพอแล้วจะหันมามองในอีกไม่กี่ปีข้างหน้า

7.3.8 การเก็บกวาดแพตเทิร์นที่ไม่ได้ใช้

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

หัวใจคือการยกเลิกไม่ใช่การลบ ดันเจี้ยนที่ใช้แพตเทิร์นนั้นอยู่แล้วก็คงไว้ตามเดิม เพราะการแตะต้องดันเจี้ยนที่กำลังทำงานอยู่ในบริการที่เปิดให้บริการจริง (Live) นั้นอันตรายกว่าการห้ามแพตเทิร์นใหม่ deprecated: true เป็นเพียงป้ายว่า "นับจากนี้อย่าใช้ใหม่" ไม่ใช่คำสั่งให้ลบอดีต

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

7.3.9 การวัดผลอย่างซื่อตรง

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

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

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

7.3.10 การตัดสินใจที่จะไม่สร้างไลบรารี

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

ROI (Return on Investment ผลตอบแทนเทียบกับการลงทุน) ของไลบรารีจะคุ้มทุนเมื่อมีสามเงื่อนไขครบพร้อมกัน คือ มีการให้บริการต่อ (Live Ops) นักออกแบบตั้งแต่สามคนขึ้นไป และดันเจี้ยนเกินยี่สิบห้อง MMORPG ที่ให้บริการแบบ Live เป็นเป้าหมายการประยุกต์ใช้ทั่วไปก็ด้วยเหตุนี้ หากโปรเจกต์ของตนเองเข้ากับบรรทัดใดในตารางข้างต้น ก่อนจะสร้างไลบรารีต้องหยุดและคิดใหม่ เครื่องมือมีคุณค่าเฉพาะเมื่อมีปัญหา และสำหรับโปรเจกต์ที่มีดันเจี้ยนห้าห้อง ไลบรารีแพตเทิร์นมีต้นทุนมากกว่าปัญหา

7.3.11 ความล้มเหลวที่พบบ่อยและการแก้ไข

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

7.3.12 ปิดท้ายส่วนที่ 7

ส่วนที่ 7 ได้ก่อร่างสาขาเลเวลขึ้นเป็นสามชั้น ใน 7.1 ได้วางมาตรฐานของเมตาดาตาห้อง·แท็ก·และความเชื่อมโยง (พื้นที่) ใน 7.2 ได้กล่าวถึงเอดิเตอร์ BehaviorTree บนฐาน JSON·subtree·และการจำลอง (พฤติกรรม) และในบทนี้ได้มาถึงไลบรารีแพตเทิร์นที่มัดทั้งสองเข้ากับเหตุการณ์เพื่อนำกลับมาใช้ซ้ำ (หน่วยปฏิบัติการ) จากการบริหารที่ดูแลพื้นที่และพฤติกรรมแยกกัน ปัญหาที่การตัดสินใจในตำแหน่งเดียวกันสั่นคลอนเป็นรูปแบบต่าง ๆ ทุกสัปดาห์ การแก้ปัญหานั้นด้วยการตรึงเป็นกฎในชุดที่เรียกว่าแพตเทิร์น คือเส้นแกนหลักของส่วนที่ 7 ทั้งหมด

กระแสนี้สอดประสานพอดีกับการออกแบบ Layer แบบบูรณาการ วิสัยทัศน์ของโทนพื้นที่ทั้งเกมอยู่ด้านบน ใต้ลงมาคือระบบที่เป็นกฎการสร้างเลเวลและกฎ BT ห้อง·BT·และไลบรารีแพตเทิร์นก่อตัวเป็นชั้นเนื้อหา อินสแตนซ์ดันเจี้ยนและสถิติการใช้แพตเทิร์นสะสมเป็นข้อมูล และ lint·การจำลอง·เทเลเมตรีของผู้ใช้ตรวจสอบสิ่งเหล่านี้ในขั้นบิลด์·QA ไลบรารีแพตเทิร์นเป็นกระดูกสันหลังของชั้นเนื้อหาในห้าชั้นนี้ ขณะเดียวกันก็เป็นข้อต่อที่ด้านบนทำตามกฎของระบบ และด้านล่างสร้างสถิติข้อมูล

สรุปประเด็นสำคัญของบท

• แพตเทิร์นคือหน่วยปฏิบัติการที่มัดพื้นที่·พฤติกรรม·เหตุการณ์เข้าด้วยกัน หากดูแลทั้งสามแยกกัน ประสบการณ์เดียวกันจะสั่นคลอนต่างกันทุกสัปดาห์
• การใช้ซ้ำ 80% + ปรับแต่ง 20% คือสัดส่วนที่แนะนำ และหากปรับแต่งเกินครึ่ง นั่นคือสัญญาณของแพตเทิร์นใหม่
• การเขียนแพตเทิร์นเป็นตำแหน่งของอินไซต์นักออกแบบ AI ช่วยแค่การแนะนำผู้สมัครการจับคู่และช่วยจำลองเท่านั้น

ตัวอย่างบทถัดไป

• 8.1 การบริหาร CombatBalance · CombatFormula — การแยกเอกสารสองฉบับของการออกแบบบาลานซ์

ลองทำดู — ตรึงแพตเทิร์นไล่ล่าหนึ่งอัน

setup

1. สร้างไดเรกทอรีสองอันคือ patterns/ และ dungeons/ ในโฟลเดอร์งาน
2. เตรียมไฟล์ที่เขียนรายการชื่อเทมเพลตห้องและรายการชื่อ subtree อย่างละหนึ่งบรรทัดต่อข้อความ (หากไม่มีไลบรารี จะเริ่มด้วยชื่อสมมุติอย่างละ 5 อันก็ได้)
3. บันทึก pattern_impact.py จากเนื้อหาข้างต้นไว้ตามเดิม

prompt

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

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

verify

1. ตรวจทีละบรรทัดว่า AI ไม่ได้กุชื่อเทมเพลตที่ไม่มีในไลบรารีขึ้นมา
2. ดูว่าคะแนนความเหมาะสมมีเหตุผลอ้างอิงเกณฑ์แท็ก·ขนาดแนบมาด้วยหรือไม่ อย่าเชื่อคะแนนที่ไม่มีเหตุผล
3. หลังจากสร้างอินสแตนซ์แพตเทิร์นในดันเจี้ยน 2 แห่งขึ้นไปแล้ว รัน find_dungeons_using("pattern_...") เพื่อตรวจว่าจับดันเจี้ยนสองห้องนั้นได้ถูกต้อง

ฉบับย่อสำหรับคนเดียว

หากทำเกมเล็ก ๆ คนเดียว ระบบไลบรารีก็เกินความจำเป็น แทนที่จะทำอย่างนั้น เพียงเลือกช่วงดันเจี้ยนที่ชอบที่สุดสักช่วงหนึ่งแล้วเขียนประสบการณ์นั้นลง yaml หนึ่งหน้าไว้ก็เพียงพอ เมื่อจะสร้างดันเจี้ยนถัดไป ก็เปิดหน้านั้นมาคัดลอกและแก้เพียง 20% แก่นแท้ของไลบรารีแพตเทิร์น — การนำประสบการณ์ที่ตรวจสอบแล้วกลับมาใช้ซ้ำ — ทำงานได้แม้ในไฟล์เพียงหน้าเดียว เมื่อขนาดใหญ่ขึ้น เมื่อนั้นค่อยเพิ่มหมวดหมู่และเครื่องมือติดตามเข้าไป

ส่วนที่ 8 · Balance Design

8.1 สูตรปรับสมดุลการต่อสู้ — ที่ทางของรูลบุ๊กแบบเชิงกำหนด

เป้าหมายการเรียนรู้ของบทนี้ (ระดับความยาก 🟡 ภาคปฏิบัติ · ความรู้พื้นฐานที่ต้องมี: การบวกลบคูณหาร · การคำนวณตาราง): แยกการปรับสมดุลการต่อสู้ออกเป็นที่ทางของสูตรกับที่ทางของค่าตัวเลข แล้วใช้คุณสมบัติสองอย่างคือความเป็นเชิงกำหนด (determinism) และความสามารถในการสืบย้อน เป็นเกณฑ์แยกแยะว่าควรมอบหมายงานให้ AI ได้ถึงไหน และตรงไหนที่มนุษย์ต้องล็อกไว้ด้วยรูลบุ๊ก

ตีสองของเช้ามืด มีการแจ้งเตือนขึ้นมาว่าอัตราการรอดชีวิตของอาชีพแทงก์บนเซิร์ฟเวอร์ Live แตะ 89% ไม่มีแทงก์คนไหนที่ตีบอสไม่จบ แต่แทงก์ที่ไม่ตายเลยกลับมีมากเกินไป ผมเปิดชีตข้อมูลขึ้นมาเพื่อหาร่องรอยว่าใครเข้าไปแตะอะไร เห็นค่าสัมประสิทธิ์การป้องกันบรรทัดหนึ่ง DEF / (DEF + 1000) ตัวเลข 1000 นี้ ลดจาก 1200 มาเป็น 1000 เมื่อไหร่ ด้วยมือของใคร และอ้างอิงจากอะไร ไม่มีจุดไหนในชีตที่เขียนบันทึกไว้เลย การสืบย้อนจึงเริ่มต้นขึ้น — ต้องไล่ดูล็อกแชต ไล่ดูประวัติบิลด์ และสุดท้ายต้องไปถึงความทรงจำของนักปรับสมดุลที่ลาออกไปเมื่อสามปีก่อนจึงจะจบ

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

หนึ่งบรรทัดสำหรับผู้ที่ไม่ได้เรียนสายนี้ z-score · การจำลอง · เส้นโค้งในส่วนนี้จะดูแปลกตาก็ไม่เป็นไร สิ่งเดียวที่ขอให้นำกลับไปคือสิ่งนี้ — "กฎ (สูตร) ที่ต้องให้ผลลัพธ์เดิมเสมอเมื่อใส่อินพุตเดิม จะไม่นำ AI เข้ามา" การแยกแยะระหว่างที่ทางที่ต้องการความเป็นเชิงกำหนดกับที่ทางที่ต้องการการสำรวจนี้ ย้ายไปใช้ได้ตรง ๆ กับทุกสายงานที่จัดการ 'กฎที่ผิดไม่ได้' เช่น ระเบียบบัญชี · ตรรกะการชำระเงิน · ข้อสัญญา ส่วนตัวสูตรเอง ค่อย ๆ ดูจาก 8.1.2 เป็นต้นไปก็ได้

8.1.1 สูตรคือรูลบุ๊ก

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

ในโปรเจกต์ A ที่ผู้เขียนดูแลอยู่ การปรับสมดุลการต่อสู้ถูกแยกออกเป็นสองที่ทาง คือที่ทางของสูตร (ในที่นี้เรียกว่า CombatFormula) และที่ทางของค่าตัวเลข (CombatBalance) ขออ้างอิงบรรทัดหนึ่งที่อาศัยอยู่ในที่ทางของสูตรมาตรง ๆ

final_damage = base_damage × dmg_multiplier × (1 − defense_factor) × variation

  base_damage    = skill_base × ATK × skill_coeff
  defense_factor = DEF / (DEF + 1000)
  variation      = uniform(0.95, 1.05)

สูตรนี้คือรูลบุ๊ก ลองนึกถึงคู่มือกฎของบอร์ดเกม คู่มือกฎเขียนว่า "เคลื่อนที่ได้เท่ากับแต้มที่ทอยลูกเต๋าออกมา" ไม่ได้เขียนว่า "ตานี้ถ้าโชคดีจะเดินได้ไกลกว่านิดหน่อยก็ได้" อินพุตเดิมต้องให้เอาต์พุตเดิมเสมอ นี่คือความเป็นเชิงกำหนด (determinism) ใส่พลังโจมตี 180 พลังป้องกัน 80 สัมประสิทธิ์สกิล 2.1 ไม่ว่าจะคำนวณเมื่อไหร่ ที่ไหน กี่ครั้ง ก็ต้องได้ดาเมจเดียวกัน หากอินพุตเดิมแล้วได้เอาต์พุตต่างกัน นั่นไม่ใช่เครื่องมือปรับสมดุล แต่เป็นเครื่องพนัน

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

พื้นที่หลักของสูตรการต่อสู้ไม่ได้จบที่ดาเมจบรรทัดเดียว อย่างน้อยมีสามบรรทัดที่อาศัยอยู่รวมเป็นชุดเดียวกัน

# ดาเมจ
final_damage = base_damage × dmg_multiplier × (1 − defense_factor) × variation

# คริติคอล
crit_damage  = final_damage × crit_multiplier
crit_chance  = base_crit + (LUK × 0.1)            # เพดาน 50%

# การฟื้นฟู
heal         = base_heal × healing_power × (1 − sickness_factor)

การเขียนสามบรรทัดนี้เป็นบล็อกโค้ดแทนภาษาธรรมชาตินั้นมีเหตุผล ภาษาธรรมชาติทิ้งช่องว่างให้ตีความ ประโยค "ยิ่งพลังป้องกันสูง ดาเมจยิ่งลด" ไม่ได้บอกว่าลดแบบเชิงเส้น ลดแบบเส้นโค้ง หรือหยุดตรงไหน แต่ DEF / (DEF + 1000) อ่านได้แบบเดียวเท่านั้น หน้าที่ของรูลบุ๊กคือทำให้ช่องว่างของการตีความเป็น 0

8.1.2 เส้นโค้งเป็นตัวกำหนดความเป็นเชิงกำหนด

ในสัมประสิทธิ์การป้องกัน DEF / (DEF + 1000) บรรทัดเดียวนี้ มีปรัชญาการปรับสมดุลทั้งหมดของเกมนี้อยู่ ลองวาดบรรทัดนี้เป็นกราฟจะเห็นว่าทำไมจึงเป็นเช่นนั้น แกนนอนคือพลังป้องกัน แกนตั้งคือสัดส่วนที่ลดดาเมจที่ได้รับ

เส้นโค้งนี้ค่อย ๆ แนบเข้ากับเส้นกำกับ (asymptote) อย่างช้า ๆ ที่พลังป้องกัน 1000 จะลดดาเมจลงครึ่งหนึ่งพอดี และหลังจากนั้นไม่ว่าจะเพิ่มขึ้นเท่าไรก็ไม่มีวันแตะ 100% การที่ไร้เทียมทานเป็นไปไม่ได้ ก็อยู่ในบรรทัดเดียวนี้ ถ้าเป็นเชิงเส้นแบบเส้นประสีเทา ที่พลังป้องกัน 1000 จะกันดาเมจได้หมด และเหนือกว่านั้นจะข้ามไปสู่พื้นที่ที่เป็นไปไม่ได้ คือดาเมจติดลบ (ยิ่งโดนตียิ่งฟื้นพลังชีวิต) จึงไม่เลือกใช้เชิงเส้น

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

8.1.3 การเปลี่ยนแปลงสูตรต้องมีประวัติติดตามมา

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

## การตัดสินใจ D17 (2026-04-22)
- การเปลี่ยนแปลง: เปลี่ยน defense_factor จาก DEF/(DEF+1000) → DEF/(DEF+1500)
- เหตุผล: ในช่วงเลเวลสูง (LV40+) อัตราการรอดชีวิตของแทงก์อยู่ที่ 89% (วัดจาก Live) เป็นสาเหตุที่ทำให้การสู้บอสยืดเยื้อ
- ลองครั้งที่ 1: จำลองด้วย 800 → อัตราการตายของแทงก์พุ่งสูง เข้าบอสไม่ถึง 1 นาทีก็ถูกล้างหลายครั้ง → ย้อนกลับ
- ลองครั้งที่ 2: จำลองด้วย 1200 → อัตราการรอดชีวิต 75% → ดีแต่สูงกว่าเป้า (60~70%)
- ลองครั้งที่ 3: เลือกใช้ 1500 → อัตราการรอดชีวิตจากการจำลอง 65% (อยู่ในช่วงเป้าหมาย)
- atom ที่ได้รับผลกระทบ: combat_defense_formula, combat_tank_class_balance
- การวัดผลภายหลัง (1 สัปดาห์): อัตราการรอดชีวิตบน Live 67% (เทียบกับที่จำลองทำนายไว้ 65% คือ +2%, อยู่ในช่วง)

บันทึกหนึ่งครั้งนี้ตอบคำถาม "ทำไมถึงกลายเป็นแบบนี้" ของอีกหกเดือนข้างหน้าได้ ที่สำคัญกว่าคือการที่ลองครั้งที่ 1 และลองครั้งที่ 2 ยังคงอยู่ ถ้ามีการบันทึกว่าทำไม 800 ถึงไม่ได้ ทำไม 1200 ถึงไม่ถูกเลือก คนถัดไปก็จะไม่ทำผิดซ้ำแบบเดิม เมื่อนักปรับสมดุลคนใหม่เข้าทีม ชุดล็อกการตัดสินใจชุดนี้จะกลายเป็นเอกสารสำหรับการเรียนรู้งานเริ่มต้น (onboarding) ที่ดีที่สุด

ตรงนี้มีสิ่งหนึ่งที่ต้องพูดอย่างตรงไปตรงมา ค่าตัวเลขจากการจำลองในลองครั้งที่ 1·2·3 ข้างต้น (อัตราการตาย, อัตราการรอดชีวิต 75%, 65%) เป็น ค่าประมาณของผู้เขียน (ยังไม่ได้ตรวจสอบ) เพื่อแสดงให้เห็นกระแสการดำเนินงาน เกมแต่ละเกมจริง ๆ มีทั้งเส้นโค้งและช่วงเป้าหมายต่างกัน แต่ โครงสร้าง ที่ว่า "การเปลี่ยนแปลงมาพร้อมการลอง การลองมาพร้อมหลักฐานจากการจำลอง และหลังจากเลือกใช้แล้วก็มาพร้อมการวัดผลภายหลัง" นั้นเป็นไปตามการดำเนินงานจริงทุกประการ ในโครงสร้างนี้ ถ้ามีช่องไหนว่างแม้แต่ช่องเดียว ช่องที่ว่างนั้นจะกลายเป็นการสืบย้อนตีสองของเช้ามืดที่ย้อนกลับมา

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

8.1.4 กระแสจริงของการเปลี่ยนสูตรหนึ่งครั้ง

ทีนี้ลองไล่ดูตั้งแต่ต้นว่า D17 ถูกตัดสินใจขึ้นมาอย่างไร นี่คือวิธีที่รูลบุ๊กแบบเชิงกำหนดเคลื่อนไหวในงานจริง

flowchart TD
    A["วัดบน Live
ตรวจพบอัตรารอดชีวิตแทงก์ 89%"] --> B["สมมติฐานสาเหตุ
สัมประสิทธิ์ป้องกัน 1000 ปกป้องเกินในช่วงท้าย"]
    B --> C["นิยามตัวเลือกการเปลี่ยนแปลง
1500 / 1200 / 800"]
    C --> D["Damage Simulator
รันแบบเชิงกำหนด 1,000 ครั้งต่อตัวเลือก"]
    D --> E["รายงานผลลัพธ์
อัตรารอดชีวิต · เวลาต่อสู้เฉลี่ย · อัตราชนะ"]
    E --> F{"นักปรับสมดุลตัดสิน
อยู่ในช่วงเป้า 60~70% ไหม?"}
    F -->|"800: อัตราตายพุ่งสูง"| G["ปฏิเสธ → ล็อกลองครั้งที่ 1"]
    F -->|"1200: 75%, ค่อนข้างสูง"| H["พัก → ล็อกลองครั้งที่ 2"]
    F -->|"1500: 65%, อยู่ในช่วง"| I["เลือกใช้ → การตัดสินใจ D17"]
    I --> J["นำเข้าบิลด์ (ย้อนกลับไม่ได้)"]
    J --> K["วัดผลภายหลังบน Live หลัง 1 สัปดาห์
67%, +2% เทียบกับที่ทำนาย"]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    classDef fail fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    class D code;
    class B,C,F human;
    class A,E,K data;
    class I pass;
    class G fail;

ในกระแสนี้ต้องดูบทบาทของตัวจำลองให้แม่นยำ Damage Simulator รันตัวเลือกทั้งสามตัว ตัวละ 1,000 ครั้ง ในที่นี้ 1,000 ครั้งไม่ได้หมายถึงการทำซ้ำอินพุตเดิม 1,000 ครั้ง เพราะ variation = uniform(0.95, 1.05) ในสูตรซึ่งเป็นตัวเลขสุ่ม ±5% และความน่าจะเป็นคริติคอลซึ่งเป็นตัวเลขสุ่มอีกตัวหนึ่ง ทำให้ผลของแต่ละรอบแต่ละรอบต่างกัน รัน 1,000 รอบเพื่อดู การกระจาย (distribution) ดูอัตราการรอดชีวิตเฉลี่ย กรณีเลวร้ายที่สุด และการกระจัดกระจายของเวลาต่อสู้

ประเด็นสำคัญคือ ตัวจำลองตัวนี้เองก็ต้องเป็นเชิงกำหนด ถ้าให้ค่าตั้งต้นตัวเลขสุ่ม (seed) เดียวกัน 1,000 รอบต้องทำซ้ำได้โดยไม่ผิดแม้แต่ตัวอักษรเดียว เช่นนั้นแล้วบรรทัดหนึ่งของ D17 ที่ว่า "ใช้ 1500 ได้ 65%" จึงจะทำซ้ำได้เหมือนกันและตรวจสอบได้แม้ในอีกหกเดือนข้างหน้า ถ้าตัวจำลองให้ผลต่างกันทุกครั้ง ล็อกการตัดสินใจก็จะกลายเป็นคำโกหก

ผู้เขียนสร้างตัวจำลองดาเมจตัวนี้ครั้งแรกในปี 2008 ตอนนั้นเป็นแมโคร Excel และตอนนี้ในโปรเจกต์ A มันถูกหุ้มเป็นสกิล balance-sim ตลอด 18 ปีที่ผ่านมาเปลือกนอกของเครื่องมือเปลี่ยนไป แต่รูลบุ๊กที่อยู่ข้างในไม่เคยเป็นเชิงความน่าจะเป็นแม้แต่ครั้งเดียว นี่คือหัวใจสำคัญ

8.1.5 ทำไม AI จึงถูกห้ามเด็ดขาดในเส้นโค้งรางวัลและในสูตร

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

LLM (โมเดลภาษาขนาดใหญ่) นั้นเป็นเชิงความน่าจะเป็นโดยเนื้อแท้ ตอบคำถามเดิมต่างกันเล็กน้อยทุกครั้ง นั่นเป็นต้นกำเนิดของพลังในการสร้างข้อความและไอเดียที่ดี แต่เป็นภัยร้ายแรงต่อที่ทางของรูลบุ๊ก ถ้าให้ LLM ตอบ "ตัวละครที่มีพลังป้องกัน 80 จะรับดาเมจเท่าไหร่" วันนี้อาจตอบ 92 พรุ่งนี้อาจตอบ 94 เปรียบเสมือนคู่มือกฎของบอร์ดเกมที่เปลี่ยนความหมายของแต้มลูกเต๋าทุกครั้งที่เปิดหน้าใหม่

เส้นโค้งรางวัลยิ่งอันตรายกว่า "ค่าประสบการณ์ที่ต้องใช้ตอนเลื่อนจากเลเวล 30 ไป 31" เมื่อกำหนดครั้งเดียวก็กำกับความเร็วการเล่นของคนหลายแสนคนพร้อมกัน หากมีความสั่นไหวเพียง ±2% เข้ามา ผู้เล่นบางคนล่ามอนสเตอร์เดียวกันก็ยังเติบโตช้ากว่าคนข้าง ๆ ความเสมอภาคพังทลาย ความเป็นเชิงกำหนดเป็นคำเดียวกับความเป็นธรรม ดังนั้นเส้นโค้งรางวัลจึงให้คนกำหนดด้วยมือ ป้อนลงในชีต และไม่มอบให้ความน่าจะเป็นอีก

แต่ก็ไม่ได้หมายความว่าให้ไล่ AI ออกจากพื้นที่การปรับสมดุลทั้งหมด เส้นแบ่งคือหัวใจสำคัญ

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

เส้นแบ่งนี้เป็นโครงสร้างเดียวกับระบบเศรษฐกิจที่จะดูใน 8.2 ในเศรษฐกิจก็เช่นกัน สูตรการผลิตและการบริโภคทรัพยากรเป็นเชิงกำหนด ส่วนการตรวจจับรูปแบบเงินเฟ้อเป็นที่ทางของ AI พื้นที่การปรับสมดุลทั้งหมดเคลื่อนไหวด้วยโครงร่างเดียวกัน

8.1.6 ไปอีกหนึ่งก้าว — การประยุกต์เชิงรุกด้วยการเสนอตัวเลือกผ่าน z-score

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

จุดเริ่มต้นคือการตรวจจับรูปแบบผิดปกติ ดูการกระจายของอัตราชนะ · อัตรารอดชีวิตของแต่ละตัวละครจากผลการจำลอง 1,000 รอบ แล้ววัดด้วย z-score ว่าเบี่ยงเบนจากค่าเฉลี่ยไปกี่เท่าของส่วนเบี่ยงเบนมาตรฐาน ตัวละครที่ z เกิน 2 จะถูกทำเครื่องหมายอัตโนมัติว่า "อยู่นอกช่วงปกติ" แทงก์ของตีสองเช้ามืดก็คงติดการตรวจจับนี้

เพื่อให้การตรวจจับนำไปสู่การเสนอตัวเลือก ต้องมีอีกสองอย่าง อย่างแรกคือ การนิยามพื้นที่การเปลี่ยนแปลง วางช่องอย่าง tunable_range ในชีต CombatBalance เพื่อระบุว่า "ค่าตัวเลขนี้ปรับได้ในช่วงไหน" อย่างที่สองคือ การทำงานคู่ขนานของการจำลอง หากต้องการรันตัวเลือก 10 ตัว × 1,000 รอบ = 10,000 รอบ ภายในเวลาของด่านบิลด์ ต้องมีโครงสร้างพื้นฐานแบบคู่ขนาน

เมื่อสามอย่างนี้ (การตรวจจับด้วย z-score · การนิยามพื้นที่การเปลี่ยนแปลง · การทำงานคู่ขนานของการจำลอง) พร้อม การตัดสินใจที่เหลืออยู่ในมือนักปรับสมดุลก็แคบลงเหลือเพียงอย่างเดียว คือ "จะเลือกตัวเลือกไหน" งานสร้างตัวเลือกจาก 0 กับงานเลือกจากห้าตัวนั้น มีภาระต่างกัน ในที่นี้ก็เช่นกัน สิ่งที่ AI แตะได้มีแค่การเสนอตัวเลือกและการตีความรายงาน ส่วนการคำนวณฝั่งในตัวจำลองและการตัดสินใจเลือกใช้เป็นที่ทางของความเป็นเชิงกำหนดและของคน

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

ลองทำดู — จัดการการเปลี่ยนสูตรหนึ่งครั้งอย่างปลอดภัย

setup. แยกสูตรการต่อสู้ออกจากคำอธิบายภาษาธรรมชาติ แล้วสร้างเอกสาร CombatFormula ที่เขียนเป็นบล็อกโค้ดเท่านั้น พร้อมเอกสารล็อก CombatFormula_Decisions เปล่า ๆ ไว้ข้าง ๆ ส่วนค่าตัวเลขให้แยกออกเป็นชีตต่างหาก (CombatBalance)

prompt. ใช้ AI เฉพาะกับ การวิเคราะห์ · การร่าง เท่านั้น ไม่ใช่การเปลี่ยนสูตร ตัวอย่างเช่น ให้ CSV ผลการจำลองไป แล้วขอแบบนี้

จากผลการจำลอง 1,000 ครั้งที่แนบมา ช่วยคำนวณ z-score ของอัตราชนะแยกตามตัวละคร
แล้วจัดตัวละครที่ z>2 เป็นตาราง สำหรับแต่ละตัวละคร
ช่วยประมาณพร้อมเหตุผลว่าค่าตัวเลขใด (พลังโจมตี/พลังป้องกัน/สัมประสิทธิ์สกิล)
มีโอกาสสูงที่จะเป็นสาเหตุของความผิดปกติ อย่าแก้ตัวเลขเอง — เสนอแค่ตัวเลือกเท่านั้น

verify. อย่าเชื่อตัวเลือกที่ AI เสนอมาทั้งดุ้น ป้อนค่าตัวเลขของตัวเลือกลงในชีต CombatBalance โดยตรง แล้วใช้ Damage Simulator (หรือ balance-sim) ให้ seed เดียวกันแล้วรัน 1,000 ครั้งใหม่ ตรวจสอบสองอย่าง (1) ผลการจำลองอยู่ในช่วงเป้าหมายไหม (2) รันด้วย seed เดียวกันอีกครั้งแล้วทำซ้ำได้โดยไม่ผิดแม้แต่ตัวอักษรเดียวไหม ถ้าผ่านทั้งสองข้อจึงเลือกใช้ และทันทีที่เลือกใช้ ให้เขียนเหตุผล · การลอง (รวมตัวเลือกที่ถูกปฏิเสธ) · ค่าที่ทำนายไว้ลงใน _Decisions แล้วหลังนำเข้าบิลด์ 1 สัปดาห์ ให้เพิ่มค่าที่วัดจาก Live ลงในล็อกนั้น

ฉบับย่อสำหรับคนเดียว

แม้จะเป็นการพัฒนาคนเดียวที่ไม่มีทั้งทีมและตัวจำลอง โครงร่างก็ทำงานเหมือนกันทุกประการ ให้บันทึกสูตรเป็นบล็อกโค้ดไว้ในคอมเมนต์ของโค้ดหรือใน .md แยกหนึ่งหน้า แล้ววาง ## ประวัติการเปลี่ยนแปลง ไว้ล่างสุดของไฟล์นั้น ถ้าเปลี่ยนค่าคงที่ของสูตรแม้แต่ตัวเดียว ให้เขียนวันที่ · เหตุผล · ค่าก่อนเปลี่ยน ลงไปหนึ่งบรรทัด ตัวจำลองใช้ลูป Python 30 บรรทัดก็พอแล้ว ตรึง seed ตัวเลขสุ่มไว้ ใส่ค่าตัวเลขของตัวละครลงในสูตร รัน 1,000 ครั้ง แล้วต่อให้พิมพ์ออกมาแค่อัตราชนะเฉลี่ย ก็ก้าวข้ามจาก "เปลี่ยนด้วยความรู้สึก" ไปสู่ "เปลี่ยนด้วยหลักฐาน" ได้ ส่วน AI ให้ใช้แค่ในงานอ่าน CSV ผลลัพธ์นั้นแล้วสรุปว่า "ตัวละครไหนผิดปกติ" เท่านั้น มีเพียงเรื่องเดียวที่ไม่ว่าจะขนาดเท่าไรก็อย่าทำ คือการให้ LLM คำนวณสูตรหนึ่งบรรทัด

สรุปประเด็นสำคัญของบท

• สูตรการต่อสู้คือรูลบุ๊กที่ให้เอาต์พุตเดิมเมื่อใส่อินพุตเดิม และวินาทีที่ความเป็นเชิงกำหนดนั้นพังลง เครื่องมือปรับสมดุลก็จะกลายเป็นเครื่องพนัน
• การเปลี่ยนแปลงสูตรต้องมีประวัติการตัดสินใจที่บรรจุเหตุผล · การลอง · การวัดผลภายหลัง ติดตามมาด้วยเสมอ จึงจะตอบคำถาม "ทำไมถึงกลายเป็นแบบนี้" ของอีกหกเดือนข้างหน้าได้
• AI อาศัยอยู่ได้แค่ภายนอกแกนเชิงกำหนด (การตรวจจับความผิดปกติ · การเสนอตัวเลือก · รายงาน) เท่านั้น และจะไม่เข้ามาในการคำนวณสูตรและเส้นโค้งรางวัลเด็ดขาด

8.2 สร้างโมเดลเศรษฐกิจด้วย Machinations — จับเงินเฟ้อด้วยซิมูเลชันแทนการประชุม

ผู้อ่านกลุ่มหลัก: นักออกแบบบาลานซ์/ระบบของ MMORPG ที่รับผิดชอบเศรษฐกิจในเกมที่ให้บริการจริง (ทีมขนาดกลาง 10\~50 คน) ฉบับย่อสำหรับผู้อ่านคนเดียว/มือสมัครเล่น: §8.2.10 「ถ้าทำคนเดียวก็แค่นี้พอ」

ครั้งแรกที่ผมรู้ว่าเงินทอง (gold) เริ่มรั่วไม่ใช่จากใบเรียกเก็บเงิน แต่จากตลาดประมูล สองเดือนหลังเปิดให้บริการ ราคาหินตีบวก (강화석) ค่อย ๆ ขยับขึ้น แล้วอีกหนึ่งเดือนต่อมาก็พุ่งขึ้นเป็นสองเท่า ผมนัดประชุมเพื่อตามหาสาเหตุ แต่สิ่งที่ออกมาจากห้องประชุมล้วนเป็น "ความรู้สึก" ทั้งสิ้น บางคนบอกว่ารางวัลจากดันเจี้ยนใหม่มากเกินไป บางคนบอกว่าเป็นเพราะประสิทธิภาพของจุดล่ามอนสเตอร์สูงขึ้น บางคนก็บอกแค่ว่าผู้เล่นเลเวลสูงเพิ่มจำนวนขึ้น ทุกข้อฟังดูสมเหตุสมผล และด้วยเหตุนั้นเองจึงไม่มีอะไรถูกตัดสินใจสักอย่าง เผาเวลาไปหนึ่งชั่วโมงกับการคาดเดา แล้วจบลงที่ "เอาเป็นว่าสัปดาห์หน้ามาดูข้อมูลเพิ่มกัน"

ปัญหาอยู่ที่ทรัพยากรไม่ได้มีแค่ชนิดเดียว เงินทอง·หินตีบวก·ค่าชื่อเสียง·เกียรติยศ·หินวิญญาณ ต่างก็มี source (ทางที่ไหลเข้า) และ sink (ทางที่ไหลออก) ของตัวเอง และทางเหล่านั้นต่างป้อนซึ่งกันและกัน บอสที่ดรอปหินตีบวกก็ดรอปเงินทองด้วย อุปกรณ์ที่ซื้อด้วยเงินทองก็เผาหินตีบวกไป เมื่อทรัพยากร 5 ชนิดพันกันด้วยกระแสไหลหลายสิบเส้น เครื่องคิดเลขในหัวก็ไม่อาจคำนวณแม้แต่สมดุลรายสัปดาห์ของทรัพยากรเพียงชนิดเดียวออกมาได้อย่างซื่อตรง บทนี้ว่าด้วยการย้ายความพันกันนั้นไปเป็น โมเดลโหนดของ Machinations และวิธีทำให้การตัดสินใจเปลี่ยนแปลงเศรษฐกิจผ่าน ด่านซิมูเลชัน (simulation gate) แทนการคาดเดาในที่ประชุม ทฤษฎีทั่วไปของการออกแบบเศรษฐกิจมีในหนังสือเล่มอื่นอย่างเพียงพออยู่แล้ว บทนี้จึงโฟกัสเฉพาะ จุดที่นำทฤษฎีนั้นไปรันด้วยเวิร์กโฟลว์ AI เท่านั้น

บันทึกจากการให้บริการจริงของผู้เขียน กรณีศึกษาในบทนี้นำมาจากเอกสารโครงการนำร่องด้านเศรษฐกิจ (Economy_Machinations_Pilot) ที่ผู้เขียนกำลังดำเนินอยู่ในโฟลเดอร์ R&D ของบริษัท และพื้นที่ทำงานวิจัยด้านเศรษฐกิจ โดยทำให้เป็นนิรนาม (anonymized) แล้ว ชนิดของทรัพยากร·โครงสร้าง source/sink·4 ขั้นของ Pilot ถ่ายทอดมาจากการให้บริการจริงอย่างซื่อตรง ส่วนชื่อเฉพาะของบริษัท·ตัวเลขจริงนั้นถูกแทนที่ด้วยค่าสำหรับหนังสือ หรือเขียนไว้เพียงในรูปอัตราส่วน·ทิศทาง เนื้อหาผลลัพธ์ของ AI เป็นการเรียบเรียงใหม่จากเซสชันจริง

8.2.1 เศรษฐกิจไม่ใช่ 'ทรัพยากร 5 ชนิด' แต่เป็น 'กระแสไหลหลายสิบเส้น'

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

ทรัพยากรมี 5 ชนิด แต่ source·sink รวมกันแล้วยี่สิบกว่าเส้น ยิ่งไปกว่านั้นทรัพยากรยังแปลงข้ามกันเองได้ (ตลาดประมูลที่ซื้อหินตีบวกด้วยเงินทองนั้นเป็นทั้ง sink ของเงินทองและ source ของหินตีบวก) ทันทีที่กระแสไหลป้อนซึ่งกันและกัน คำถามอย่าง "ถ้าปล่อยเงินทองเพิ่มอีก 5% ราคาหินตีบวกจะเป็นยังไง" ก็ไม่อาจตอบได้ด้วยการมองทรัพยากรเพียงชนิดเดียว นี่คือจุดที่บาลานซ์ตัวละคร (8.1) กับบาลานซ์เศรษฐกิจต่างกันอย่างชี้ขาด บาลานซ์ตัวละครปิดจบได้ด้วยสมการบรรทัดเดียว แต่เศรษฐกิจเป็น ระบบพลวัตที่สะสมไปตามเวลา ดังนั้นต่อให้สมดุลรายสัปดาห์ใกล้ศูนย์ พอสะสมไป 26 สัปดาห์ ตลาดประมูลก็พังลงได้

ดังนั้นแก่นแท้ของงานเศรษฐกิจไม่ใช่ "การเลือกตัวเลขให้ดี" แต่เป็น "การมองด้วยซิมูเลชันว่ากระแสไหลจะสะสมไปตามเวลาอย่างไร" และงานสร้าง·แก้ไขโมเดลซิมูเลชันนั้นด้วยมือก็น่าเบื่อ และทุกครั้งที่ทำก็มักมีอะไรหล่นหาย งานร่างที่ทำซ้ำ ๆ และตกหล่นง่าย แต่การตรวจสอบต้องให้มนุษย์กุมไว้แน่น — งานลักษณะนี้คือจุดที่เส้นแบ่งงานระหว่าง AI กับมนุษย์ถูกขีดได้สะอาดที่สุด

ก่อนอื่น ขอวางโครงของวัฏจักรเศรษฐกิจที่บทนี้ครอบคลุมไว้เป็นภาพหนึ่งภาพ

%%{init: {"flowchart": {"defaultRenderer": "elk"}}}%%
flowchart LR
    subgraph SRC["source (ผลิตทรัพยากร)"]
        H["จุดล่ามอนสเตอร์"]
        Q["เควสต์"]
        B["บอสดันเจี้ยน"]
        PVP["PvP/สงครามกิลด์"]
    end
    subgraph POOL["pool (เก็บทรัพยากร)"]
        G(("เงินทอง"))
        S(("หินตีบวก"))
    end
    subgraph SINK["sink (บริโภคทรัพยากร)"]
        UP["ตีบวกอุปกรณ์"]
        RP["ซ่อม/ภาษี"]
        SH["ร้านค้ากลุ่มอิทธิพล/กิลด์"]
    end
    H --> G
    Q --> G
    B --> S
    PVP --> SH
    G -->|แปลงผ่านตลาดประมูล| S
    G --> UP
    S --> UP
    G --> RP
    UP -.->|อุปสงค์หินตีบวก ↑| S
    G -.->|"เมื่อไหลเข้าสุทธิ > ไหลออกสุทธิ
เงินเฟ้อสะสม"| POOL

    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    class G,S data;

เส้นประคือหัวใจของบทนี้ sink ของการตีบวกดึงอุปสงค์หินตีบวกขึ้น จึงดันราคาหินตีบวก (UP -.-> S) และเมื่อการไหลเข้าสุทธิของเงินทองเกินการไหลออกสุทธิ ส่วนเกินนั้นก็สะสมเข้าพูล (pool) ทุกสัปดาห์ กลายเป็นเงินเฟ้อที่พอกพูน เส้นประสองเส้นนี้ตามรอยด้วยการคำนวณมือไม่ได้ จึงต้องมีโมเดล

8.2.2 Machinations — เครื่องมือย้ายเศรษฐกิจไปเป็นกราฟโหนด

Machinations คือเครื่องมือที่วาดกระแสไหลของเศรษฐกิจเป็นกราฟโหนด แล้วรันซิมูเลชันบนกราฟนั้น เป็นจุดที่ย้าย mermaid ของ §8.2.1 ไปเป็นโมเดลที่รันได้จริง

เมื่อสร้างโมเดลเศรษฐกิจด้วยโหนดเหล่านี้แล้วรันซิมูเลชัน 1,000 ครั้ง สิ่งที่ได้ไม่ใช่ผลลัพธ์เดี่ยว ๆ แต่เป็นการแจกแจง (distribution) ลักษณะอย่าง "หลัง 26 สัปดาห์ ราคาเงินทองมัธยฐาน +X%, ผู้เล่นกลุ่มบน 10% อยู่ที่ +Y%" อย่างไรก็ตาม Machinations ไม่ได้ครอบจักรวาล และตัวการนำมาใช้เองก็มีต้นทุน

ดังนั้น Machinations ไม่ใช่เครื่องมือที่นำมาใช้แบบไม่มีเงื่อนไข มันคุ้มค่าเมื่อสามเงื่อนไข — ทรัพยากร 5 ชนิดขึ้นไป + กระแสแปลงทรัพยากร + การให้บริการเกม (Live Ops) — มาทับซ้อนกัน เศรษฐกิจอย่างง่ายที่มีทรัพยากร 2\~3 ชนิดใช้ Excel ก็เพียงพอ ในกรณีนั้นการนำ Machinations มาใช้จะทำให้ภาระการดูแลมาถึงก่อนผลที่ได้

8.2.3 [บันทึกเซสชันจริง (worked transcript)] ร่างโมเดลทรัพยากรเดี่ยว 'เงินทอง' ด้วย AI

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

ขั้นที่ 1 — อินพุต: ทำกระแสไหลของเงินทองให้เป็นตารางที่เครื่องอ่านได้

ก่อนอื่น ดึง source·sink ของเงินทองจากชีตข้อมูลออกมาทำเป็นตาราง ไม่ใช่การเขียนใหม่ แต่เป็นการสกัด (extract)

# gold_flows.yaml — กระแสไหลของทรัพยากรเดี่ยว 'เงินทอง' (คัดจากชีตข้อมูลปัจจุบัน)
resource: gold
sources:
  - id: hunting        # ดรอปจากจุดล่ามอนสเตอร์
    trigger: per_kill
    note: เส้นโค้งดรอปตามช่วงเลเวลใช้กฎ reward_curve
  - id: quest_reward   # รางวัลเควสต์
    trigger: per_complete
  - id: market_sell    # ขายในตลาดประมูล
    trigger: per_trade
sinks:
  - id: gear_buy       # ซื้ออุปกรณ์
  - id: enhance        # ค่าตีบวก
  - id: repair         # ซ่อม
  - id: tax            # ภาษีตลาดประมูล (เป็น sink และเป็นหัวใจของการดูดเงินทองกลับคืน)
# การแจกแจงพฤติกรรมผู้เล่น (จำนวนครั้งล่าต่อชั่วโมง·อัตราทำเควสต์สำเร็จ) ยังว่างอยู่ → ให้แสดงไว้ถ้า AI ตั้งสมมติฐาน

ขั้นที่ 2 — พรอมต์: ให้สร้างโมเดล แต่บังคับสมมติฐานและรูปแบบ

ไฟล์แนบ gold_flows.yaml คือทรัพยากรเดี่ยว 'เงินทอง' ที่มี source 3 ตัว·sink 4 ตัว
จงสร้างร่างข้อกำหนดโหนด (node spec) สำหรับย้ายสิ่งนี้ไปเป็นโมเดล Machinations

กฎ:
1) จำแนกแต่ละกระแสไหลตามชนิดโหนด (Source/Drain/Pool/Converter)
2) เสนอสูตรของ 'อัตราไหลที่คาดหวังต่อผู้เล่น 1 คน อิงรายสัปดาห์' ให้แต่ละโหนด
   โดยหากต้องใช้สมมติฐานพฤติกรรมผู้เล่น (จำนวนครั้งล่าต่อชั่วโมง·อัตราทำเควสต์สำเร็จ ฯลฯ)
   จงระบุสมมติฐานนั้นไว้เป็นบรรทัดแยกต่างหากว่า '★สมมติฐาน' อย่าซ่อนสมมติฐานไว้ในเนื้อหา
3) แยกการไหลเข้ารวมของ source กับการไหลออกรวมของ sink เพื่อคำนวณสมดุลสุทธิ (net) รายสัปดาห์
4) สะท้อนว่าภาษีตลาดประมูล (tax) เป็น sink เดียวที่กำจัดเงินทองออกจากเศรษฐกิจอย่างถาวร
   และแยกแยะว่า sink อื่น (ตีบวก·ซ่อม) เป็นเพียงการที่เงินทองเคลื่อนไปยัง NPC
   ไม่ใช่การดูดกลับคืน
5) สมมติฐานที่เจ้า 'ไม่มั่นใจ' จงทำเครื่องหมาย ★ แยกไว้ แล้วส่งต่อให้มนุษย์ตัดสินใจ

รูปแบบผลลัพธ์: ตาราง (โหนด | ชนิด | สูตรอัตราไหลรายสัปดาห์ | สมมติฐาน | ระดับความมั่นใจ) ห้ามมีคำอธิบายอื่น

ในพรอมต์นี้ สิ่งที่เขียนยาวจริง ๆ ไม่ใช่คำสั่งให้สร้างโมเดล แต่เป็นกฎว่าจะเขียนสมมติฐานไว้ที่ไหนและอย่างไร ในการสร้างโมเดลเศรษฐกิจ ถ้าปล่อยให้ AI อิสระ มันจะคายตัวเลขที่ดูสมเหตุสมผลออกมาโดยซ่อนสมมติฐานเอาไว้ แล้วต่อให้โมเดลผิด ก็ไม่อาจชี้ได้ว่า ผิดตรงไหน การให้มันดึงสมมติฐานพฤติกรรมผู้เล่นออกมานอกเนื้อหาแล้วตั้งไว้เป็นบรรทัดแยก — น้ำหนักทั้งหมดของคำขอนี้อยู่ตรงนั้น สมมติฐานต้องมองเห็นได้จึงจะตรวจสอบได้

ขั้นที่ 3 — ผลลัพธ์ของ Claude (เรียบเรียงใหม่, คัดบางส่วน)

| โหนด          | ชนิด      | สูตรอัตราไหลรายสัปดาห์                  | สมมติฐาน          | ความมั่นใจ |
|--------------|-----------|----------------------------------------|------------------|-------|
| hunting      | Source    | สังหารต่อชม. × ดรอปเฉลี่ย × ชม.เล่นรายสัปดาห์ | ★สัปดาห์ละ 15h, สังหาร 80/h| กลาง  |
| quest_reward | Source    | จำนวนเดลี่เควสต์ × รางวัล × 7 × อัตราสำเร็จ | ★อัตราสำเร็จ 0.7  | กลาง  |
| market_sell  | Source    | (โอนระหว่างผู้เล่น — ไม่ใช่เพิ่มสุทธิ)   | เพิ่มต่อเศรษฐกิจสุทธิ 0 | สูง   |
| gear_buy     | Drain     | ความถี่ซื้อ × ราคาเฉลี่ย                  | ★สัปดาห์ละ 1.2 ครั้ง | ต่ำ   |
| enhance      | Drain     | ครั้งที่ตีบวก × ค่าใช้จ่ายต่อครั้ง          | ★สัปดาห์ละ 8 ครั้ง | กลาง  |
| repair       | Drain     | เวลาล่า × อัตราค่าซ่อม                     |                  | สูง   |
| tax          | Drain     | ยอดซื้อขาย × อัตราภาษี (★sink ดูดถาวรเพียงตัวเดียว) | ★อัตราภาษี 5%   | สูง   |
| ── สมดุลสุทธิ | net       | Σsource − Σsink ≈ +(เป็นบวกที่เกณฑ์กิจกรรมกลาง) | เมื่อรวมสมมติฐานข้างบน | ★ต่ำ |

★คำเตือนสมมติฐาน: market_sell เป็นการเคลื่อนเงินทองระหว่างผู้เล่น↔ผู้เล่น จึงเพิ่มต่อปริมาณรวมของเศรษฐกิจ 0
ถ้าบวกมันเป็น source จะนับเงินเฟ้อซ้ำซ้อน ต้องจัดการแยกในโมเดล
★จุดที่ไม่มั่นใจ: ความถี่ของ gear_buy (สัปดาห์ละ 1.2 ครั้ง) เป็นการเดา หากไม่มี telemetry การซื้อจริง
sink อาจถูกประเมินต่ำ/สูงเกินไป → ต้องให้มนุษย์ตัดสินใจ

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

ขั้นที่ 4 — การตรวจสอบและการปฏิเสธ (ที่ของมนุษย์)

จะเอาผลลัพธ์นี้ใส่เข้าโมเดลตรง ๆ ไม่ได้ หนึ่งในสอง ★ ที่ AI รายงานเป็นข้อบกพร่องที่ทำลายโมเดลจริง ๆ

ทีแรก AI จำแนก market_sell (ขายในตลาดประมูล) เป็น Source แต่การขายในตลาดประมูลเป็น การโอนเงินทองของผู้เล่น A ไปยังผู้เล่น B ไม่ใช่การที่เงินทองเกิดขึ้นใหม่ในเศรษฐกิจ ถ้าบวกสิ่งนี้เข้าการไหลเข้าของ source ก็จะนับเงินเฟ้อซ้ำซ้อน AI ชี้ด้วย ★คำเตือนสมมติฐานเองอยู่ก็จริง แต่ในเนื้อตารางก็ยังทิ้ง market_sell ไว้ในช่อง Source อยู่ดี — รายงานแล้วแต่ไม่ถอดออกจากโมเดล เป็นผลลัพธ์ที่ถูกแค่ครึ่งเดียว นี่ยังเป็นข้อบกพร่องของข้อมูลฝั่งมนุษย์ด้วย ที่อินพุต yaml ไม่ได้ระบุลักษณะของ market_sell (โอนระหว่างผู้เล่น vs สร้างใหม่)

จึงร้องขอใหม่

market_sell เป็นการโอนเงินทองระหว่างผู้เล่น↔ผู้เล่น จึงไม่ใช่ source ต่อปริมาณรวมของเศรษฐกิจ (แก้ส่วนที่
อินพุตตกหล่น) จงเอาโหนดนี้ออกจากการรวม source และให้สะท้อนเข้าโมเดลเพียงในฐานะ 'sink ที่ภาษีตลาดประมูล (tax)
ดูดส่วนหนึ่งของยอดโอนกลับคืนอย่างถาวร' เท่านั้น คำนวณสมดุลสุทธิใหม่
แล้วแสดงผลกระทบของการตัด market_sell ออกที่มีต่อ net เป็นหนึ่งบรรทัด

AI ตอบกลับด้วยโมเดลที่เอา market_sell ออกจาก source แล้วเหลือไว้แต่ภาษีในฐานะ sink ผลคือสมดุลสุทธิ (net) ต่ำลงกว่าที่ประเมินไว้ครั้งแรก — เผยให้เห็นว่าตอนที่ใส่การขายในตลาดประมูลเป็น source ผิด ๆ นั้น เรากำลังประเมินเงินเฟ้อสูงเกินจริงอยู่ การไป-กลับเพียงครั้งเดียวนี้คือหัวใจ ถ้ามนุษย์สร้างเองด้วยมือตั้งแต่ต้นก็กินเวลาครึ่งวันและตัวเองก็จับความผิดพลาดในการจำแนกโหนดได้ยาก แต่ร่างจาก AI + บังคับ "ระบุสมมติฐาน" + ปฏิเสธ 1 ครั้ง ใช้เวลาไม่ถึงหนึ่งชั่วโมง และด้วยโครงสร้างที่มนุษย์เป็นผู้ตัดสิน ★ ที่ AI รายงาน ข้อบกพร่องอย่างการนับซ้ำซ้อนจึงถูกดักก่อนเข้าโมเดล (การประมาณของผู้เขียน ยังไม่ได้ตรวจสอบ — เวลาที่ประหยัดได้ขึ้นกับทีม·จำนวนทรัพยากร จึงควรอ่านเป็นความต่างเชิงโครงสร้างระหว่าง "ทำเองด้วยมือตั้งแต่ต้น" กับ "ร่าง+ตรวจสอบ" มากกว่าค่าสัมบูรณ์)

8.2.4 ทีละทรัพยากร — นำเข้าด้วย Pilot 4 ขั้น

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

การตรวจสอบด้วยการเปรียบเทียบในขั้นที่ 2 คือหัวใจของ 4 ขั้นนี้ ถ้าซิมกับจริงไม่ตรงกัน สิ่งที่ผิดไม่ใช่เกม แต่เป็นโมเดล ถ้าตัดสินใจด้วยโมเดลที่ผิด การตัดสินใจนั้นก็จะย้อนกลับมาเป็นอุบัติเหตุในระบบที่ให้บริการจริง ดังนั้นการขยาย (ขั้นที่ 4) จะทำได้ก็ต่อเมื่อผ่านการตรวจสอบของขั้นที่ 2·3 แล้วเสมอ ถ้าลำดับนี้พังลง คือข้ามการตรวจสอบทรัพยากรเดี่ยวแล้วยัด 5 ชนิดเข้าไปพร้อมกัน ก็จะไม่อาจแยกชี้ได้แม้แต่ว่าโมเดลของทรัพยากรชนิดไหนผิด

8.2.5 ด่านซิม — ตั้งแผงกั้นไว้หน้าการตัดสินใจเปลี่ยนแปลงเศรษฐกิจ

เมื่อโมเดลผ่านการตรวจสอบ คราวนี้ก็ตั้ง ด่านซิม (simulation gate) ไว้หน้าการตัดสินใจเปลี่ยนแปลงทุกอย่างที่ส่งผลต่อเศรษฐกิจ เป็นจุดที่เปลี่ยนการตัดสินใจที่เคยปล่อยผ่านด้วย "ความรู้สึก" ในที่ประชุม ให้กลายเป็นการผ่านด่านซิม

เราจะลองทำให้เห็นว่าด่านทำงานจริงอย่างไร โดยปล่อยการตัดสินใจหนึ่งให้ผ่านบนโมเดลเงินทองที่ตรวจสอบแล้วใน §8.2.3

[ด่านซิม — การตัดสินใจเรื่องรางวัลอีเวนต์] (เรียบเรียงใหม่จากรูปแบบจริง)

[ข้อเสนอเปลี่ยน] อีเวนต์สุดสัปดาห์: รางวัลล็อกอินรายวัน +500 เงินทอง
[ด่าน]          เพิ่ม source ใหม่ → ซิมบังคับ
[ผลซิม 1000 ครั้ง]
  - สมดุลสุทธิเงินทองรายสัปดาห์: +6,900 → +10,400 (+50%)
  - เมื่อสะสม 26 สัปดาห์ ราคาเงินทองมัธยฐาน ~+28% (เตือนเงินเฟ้อ: เกิน ±10%)
  - ผู้เล่นกิจกรรมสูงกลุ่มบน 10%: ~+41% (ความเหวี่ยงของ segment สูง)
[คำตัดสิน]      FAIL — เกินช่วงเสถียร (±10%/ระยะยาว)
[ข้อปรับแก้]    ติด sink พร้อมกันให้กับ source ของอีเวนต์: ร้านค้าเฉพาะอีเวนต์ (ดูดเงินทองกลับ)
               ซิมใหม่ → สะสม 26 สัปดาห์ +9% (PASS)

ค่าของด่านอยู่ที่สองบรรทัดสุดท้าย ถ้าการตัดสินใจ "ปล่อยรางวัล +500 กันเถอะ" เป็นการคาดเดาในที่ประชุม มันก็คงผ่านด้วย "น่าจะโอเค" ด่านซิมแปลงการตัดสินใจนั้นให้เห็นเป็นเงินเฟ้อ +28% ใน 26 สัปดาห์ และยังบังคับการปรับแก้ไปถึงขั้นว่า ถ้าจะเพิ่ม source ก็ติด sink ไปพร้อมกัน การตัดสินการเปลี่ยนแปลงเศรษฐกิจด้วยการผ่าน/ไม่ผ่านซิมแทนการคาดเดา — นี่คือทั้งหมดของด่าน

ตรงนี้ขอชี้กับดักหนึ่งที่ตกบ่อย คือความเหวี่ยงของ segment ต่อให้เกณฑ์ผู้เล่นกิจกรรมกลางอยู่ที่ +28% แต่กลุ่มบน 10% อยู่ที่ +41% เพราะกลุ่มผู้เล่นที่หาเงินทองได้มากที่สุดสะสมเงินเฟ้อเร็วที่สุด ดังนั้นซิมจึงต้องไม่ดูแค่ค่าเฉลี่ย แต่ต้องรันแยกตาม segment ถ้าดูแค่ค่าเฉลี่ยก็จะพลาดการพังของราคาที่มาจากผู้เล่นกิจกรรมสูง

8.2.6 โมเดลวิวัฒนาการทุกเดือนด้วย telemetry หลังเปิดให้บริการ

ด่านซิมจะได้รับความเชื่อถือก็ต่อเมื่อโมเดลไม่หลุดออกจากเกมจริง เกมเปลี่ยนทุกสัปดาห์ โมเดลจึงต้องปรับเทียบตามไปด้วย หลังเปิดให้บริการ เราจะตรวจสอบโมเดลด้วย telemetry จริงทุกเดือน (ในช่วงที่มีการเปลี่ยนแปลงน้อยก็รายไตรมาส)

วัฏจักรปรับเทียบโมเดล (รายเดือน)
─────────────────────────────────
1. ดึง telemetry ผู้เล่นจริง 1 เดือน (รวมยอดกระแสไหลตามทรัพยากร)
2. คำนวณอัตราไหลจริงของ source·sink ตาม segment (กิจกรรมต่ำ/กลาง/สูง)
3. เปรียบเทียบกับซิม Machinations เป็นรายรายการ
4. รายการที่ความคลาดเคลื่อน >15% = ปรับพารามิเตอร์โมเดล (★สมมติฐานของรายการนั้นผิด)
5. หลังปรับ ซิมใหม่ → ใช้เป็นโมเดลฐานของด่านในเดือนถัดไป

หัวใจคือข้อ 4 รายการที่ความคลาดเคลื่อนสูงก็คือสัญญาณว่า "สมมติฐานที่ไม่มั่นใจ" ที่ AI ทำเครื่องหมาย ★ ไว้ใน §8.2.3 นั้นไม่ตรงกับความจริง เช่น ถ้าความถี่ gear_buy ที่ AI เดาไว้ (สัปดาห์ละ 1.2 ครั้ง) วัดจริงได้สัปดาห์ละ 2 ครั้ง ก็เปลี่ยนสมมติฐานนั้นเป็นค่าจาก telemetry ถ้าหยุดการปรับเทียบนี้ โมเดลก็จะค่อย ๆ ห่างออกจากเกม แล้วซิมในด่านของไตรมาสใดไตรมาสหนึ่งก็จะก่ออุบัติเหตุ "ปล่อยผ่านไปแล้วแต่ที่จริงเงินเฟ้อมา" ขึ้น ในวินาทีนั้นความเชื่อถือของตัวซิมเองก็พังลงในภายหลัง การปรับเทียบไม่ใช่งานพ่วงของการให้บริการ แต่เป็นวัฏจักรประจำที่ทำให้ด่านมีชีวิตอยู่

8.2.7 การประยุกต์เชิงก้าวหน้า — ตรวจจับรูปแบบผิดปกติ·นิยามปริภูมิการเปลี่ยนแปลง·รันซิมขนาน

มาถึงตรงนี้คือ 'การประยุกต์เชิงอนุรักษ์' ของการสร้างโมเดลเศรษฐกิจ มนุษย์เป็นผู้เสนอการเปลี่ยนแปลง ตรวจสอบด้วยโมเดล แล้วตัดสินใจด้วยผลลัพธ์ ถ้าก้าวต่อไปอีกหนึ่งก้าว สามแกนของการประยุกต์เชิงก้าวหน้าที่เห็นใน 8.1.6 — ตรวจจับด้วย z-score · นิยามปริภูมิการเปลี่ยนแปลง · รันซิมขนาน — ก็เปิดออกแบบเดียวกันบนโครงสร้างพื้นฐานเศรษฐกิจนี้เช่นกัน

ข้อแรก ตรวจจับรูปแบบผิดปกติ แทนที่จะให้มนุษย์เปรียบเทียบความคลาดเคลื่อนในวัฏจักรปรับเทียบรายเดือน (§8.2.6) ด้วยตา ให้โค้ดเป็นฝ่ายคัดรายการที่ค่าเบี่ยงเบนระหว่างโมเดล-ค่าวัดจริงเกินเกณฑ์ขึ้นมาก่อน การรู้ว่าราคาหินตีบวกกลายเป็นสองเท่าไม่ใช่จากการมองตลาดประมูล แต่ alert ที่ว่า "อัตราไหลของ source หินตีบวกเบี่ยง +30% เทียบกับโมเดล" มาถึงก่อนการประชุม

ข้อสอง นิยามปริภูมิการเปลี่ยนแปลง ไม่ใช่ทวิภาคว่า "ปล่อยรางวัล +500 หรือไม่ปล่อย" แต่ถ้านิยามช่วงรางวัล (0\~+1000) และช่วง sink พร้อมกันให้เป็นปริภูมิการเปลี่ยนแปลงไว้ ก็จะสามารถค้นหาคู่ผสมที่ทำให้เงินเฟ้ออยู่ใน ±10% ภายในปริภูมินั้นได้ มนุษย์กำหนด "จากตรงไหนถึงตรงไหน" ส่วนการค้นหาคู่ผสมที่ดีที่สุดภายในนั้นก็ทำให้เป็นอัตโนมัติ

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

แนวคิดร่วมคือการย้ายจุดที่มนุษย์เคย เสนอ การเปลี่ยนแปลง ไปเป็นจุดที่โค้ด ค้นหา ปริภูมิการเปลี่ยนแปลง แต่ทั้งนี้เป็นเรื่องหลังจากที่การประยุกต์เชิงอนุรักษ์ (§8.2.3\~8.2.6) หมุนอย่างมั่นคงและโมเดลผ่านการตรวจสอบด้วย telemetry แล้ว ถ้าค้นหาปริภูมิการเปลี่ยนแปลงโดยอัตโนมัติด้วยโมเดลที่ยังไม่ผ่านการตรวจสอบ โมเดลที่ผิดก็จะนำเสนอค่าที่ดีที่สุดที่ผิด ๆ ออกมาอย่างมั่นใจ

[การประยุกต์เชิงก้าวกระโดด — บีบอัดเศรษฐกิจเป็น 'เวกเตอร์เชิงมิติ' แล้วค้นหา] (ยังเร็วเกินไปในตอนนี้)

เป็นพื้นที่ที่ก้าวต่อจากการประยุกต์เชิงก้าวหน้าไปอีกหนึ่งก้าว ขอให้อ่านเป็นแนวโน้มงานวิจัย ไม่ใช่การฟันธง (หากเพิ่งเจอเวกเตอร์เชิงมิติ·เอ็มเบดดิงเป็นครั้งแรก ลองดู 'แผนที่' หนึ่งภาพในภาคผนวก M ก่อน แล้วข้างล่างจะอ่านง่ายขึ้น — 'ป้ายบอกทาง' ทั้งห้าของหนังสือเล่มนี้ล้วนหมุนอยู่บนภาพนั้น) โมเดลเศรษฐกิจที่มาถึงตรงนี้เป็นระบบความซับซ้อนสูง ที่ทรัพยากร 5 ชนิดพันกันด้วยกระแสไหลหลายสิบเส้น และการค้นหาปริภูมิการเปลี่ยนแปลงใน §8.2.7 ก็คือวิธีที่สุดท้ายแล้วก็จับกระแสไหลหลายสิบเส้นนั้นมาเป็นพารามิเตอร์ทีละตัวแล้วหมุน ความคิดเชิงก้าวกระโดดคือ บีบอัดความซับซ้อนนี้เองให้เป็นเวกเตอร์เชิงมิติ แล้วค้นหาคำตอบบนปริภูมิที่บีบอัดนั้น

อุปมาหนึ่งที่ดูห่างไกลกลับเป็นเบาะแส สูตรอาหารปรุง ซึ่งมักถูกยกเป็นพื้นที่เชิงคุณภาพที่จับต้องไม่ได้ ในงานวิจัยหนึ่ง (Epicure — Radzikowski·Chen, 2026, arXiv:2605.22391 · เดโม epicure.kaikaku.ai) ได้คัดวัตถุดิบมาตรฐาน 1,790 ชนิด จากสูตรอาหาร 4.14 ล้านสูตรจาก 11 แหล่ง แล้วบีบอัดความสัมพันธ์ระหว่างวัตถุดิบเป็นเวกเตอร์หลายร้อยมิติ แก่นคือ ต่อให้ "รสชาติ" เป็นเป้าหมายเชิงคุณภาพ แต่ถ้าแปลงความสัมพันธ์ระหว่างวัตถุดิบให้เป็นพิกัด สูตรที่คล้ายกันก็จะมารวมตัวกันใกล้ ๆ ในปริภูมิเวกเตอร์ และสามารถ interpolate ระหว่างนั้นเพื่อค้นหาคู่ผสมใหม่ได้ — Epicure เองก็แสดงการค้นหาแบบ interpolate ที่หมุนวัตถุดิบหนึ่งไปในทิศของวงอาหารหนึ่งบนปริภูมิที่บีบอัดนี้ เพื่อหาวัตถุดิบที่สมนัยกัน

เศรษฐกิจก็หลักการเดียวกัน ถ้าแทนสถานะเศรษฐกิจด้วยเวกเตอร์ที่ตั้งให้ source·sink·กระแสแปลง แต่ละอย่างเป็นมิติ "เศรษฐกิจที่เสถียรภายในเงินเฟ้อ ±10%" ก็จะถูกจับเป็นพื้นที่หนึ่งของปริภูมินั้น แล้วแทนที่จะเอาข้อเสนอเปลี่ยนไปเข้าซิมทีละข้อ ก็เปิดทางให้ค้นหาคำตอบโดยตรงในหรือใกล้พื้นที่เสถียรนั้น เป็นความเป็นไปได้ที่ซิมขนานของ §8.2.7 ที่เคยรันผู้สมัครทีละตัวเพื่อเปรียบเทียบ จะถูกย่นเหลือการค้นหาบนปริภูมิที่บีบอัดเพียงครั้งเดียว

ทำไม "ยังเร็วเกินไปในตอนนี้" ข้อแรก การกำหนดว่าจะตั้งอะไรเป็นมิติ (กระแสไหนเป็นอิสระ กระแสไหนเป็นตาม) ก็เป็นโจทย์ยากเชิงโดเมนอยู่ในตัวเอง ข้อสอง การบีบอัดโดยเนื้อแท้คือการทิ้งสารสนเทศ จึงอาจเกิดอุบัติเหตุในระบบจริงในมิติที่ทิ้งไป ข้อสาม ทั้งหมดนี้มีความหมายก็ต่อเมื่อการตรวจสอบ telemetry ของการประยุกต์เชิงอนุรักษ์ (§8.2.6) แน่นหนา — ถ้าโมเดลก่อนบีบอัดหลุดออกจากเกมอยู่แล้ว การบีบอัดก็เพียงบีบความคลาดเคลื่อนนั้นเข้าไปอย่างเรียบร้อยด้วย ดังนั้นหัวข้อนี้จึงไม่ใช่ใบสั่งยา แต่เป็น ป้ายบอกทาง สิ่งที่ต้องทำตอนนี้คือหมุนการประยุกต์เชิงอนุรักษ์อย่างซื่อตรง ส่วนเวกเตอร์เชิงมิตินั้นปล่อยไว้เป็นพื้นที่วิจัยที่ทีมซึ่งสั่งสมรากฐานเพียงพอแล้วจะหันมามองในอีกไม่กี่ปีข้างหน้า

8.2.8 การวัดผล — จุดที่การประชุมกลายเป็นซิม

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

ความหมายของบรรทัดสุดท้ายใหญ่กว่าตัวเลขในตาราง ความถี่ประชุมที่ลดลงเป็นเพราะซิมูเลชันเข้ามาแทนที่การถกเถียง พอ "ผมว่าหินตีบวกน่าจะเงินเฟ้อนะ" กลายเป็น "ผลซิม 26 สัปดาห์ +28%" จุดที่เคยเถียงกันชั่วโมงหนึ่งเรื่องการคาดเดาก็จบลงด้วยการแชร์ผลลัพธ์ 5 นาที นี่ตรงกับแนวคิดที่ตรึงเป็นกฎไว้ในการทบทวนของระบบของผู้เขียน (atom automation_signal_value_over_time_savings — คุณค่าของการทำงานอัตโนมัติไม่ใช่การประหยัดเวลา แต่คือการเปิดเผยสัญญาณ) อย่างแม่นยำ ผลผลิตที่แท้จริงของด่านซิมไม่ใช่เวลาที่ประหยัดได้ แต่คือการทำให้ตัวเลขเข้ามาแทนที่จุดที่การคาดเดาเคยครองในที่ประชุม

แต่มีสิ่งหนึ่งที่ขอวางไว้อย่างซื่อตรง "1\~2 ครั้งต่อไตรมาส → 0\~1 ครั้ง" ในตารางไม่ใช่ค่าวัดที่แม่นยำ แต่เป็นทิศทางที่สัมผัสได้จากการให้บริการ อุบัติเหตุเงินเฟ้อมีจำนวนนับเปลี่ยนไปตามนิยาม (จะถือว่าราคาเหวี่ยง ±กี่ % เป็นอุบัติเหตุ) ดังนั้นจึงควรอ่านเป็นการเปลี่ยนเชิงโครงสร้างว่า "ย้ายจากการพบหลังเกิดเหตุไปเป็นการสกัดล่วงหน้า" มากกว่าจำนวนครั้งสัมบูรณ์

8.2.9 ความล้มเหลวที่พบบ่อย

ข้อที่สองคือสิ่งที่พลาดบ่อยที่สุด เหมือนการนับซ้ำซ้อนของตลาดประมูลที่เห็นใน §8.2.3 AI คายโมเดลที่ดูสมเหตุสมผลออกมาอย่างมั่นใจ แต่จุดอ่อนของสมมติฐานตัวเองนั้นเพียงรายงานด้วย ★ แล้วก็ทิ้งข้อบกพร่องไว้ในเนื้อหา ถ้ามนุษย์ไม่ตัดสิน ★ นั้น โมเดลที่ผิดก็จะถูกปล่อยผ่าน และการตัดสินใจซิมทั้งหมดที่อยู่บนนั้นก็จะผิดไปด้วยกัน

8.2.10 ลองทำดู — หนึ่งขั้นที่ทำได้วันนี้

ถ้าทำคนเดียวก็แค่นี้พอ: ไม่ต้องมีทั้ง Machinations และ telemetry ก็ได้ เลือกทรัพยากรหนึ่งของเกมตัวเอง (หรือเกมที่ชอบ) เขียน source·sink ลงกระดาษ แล้ววางพรอมต์ของ §8.2.3 ลงไปตรง ๆ เพื่อรับร่างโมเดลสมดุลสุทธิรายสัปดาห์ดู ลองเลือกสมมติฐานหนึ่งข้อที่ AI ระบุไว้ด้วย ★ แล้วโต้แย้งว่า "สมมติฐานนี้ผมไม่เชื่อ จงยกเหตุผลมาใหม่" คุณจะรู้สึกถึงเข้าไปในร่างกายว่าโมเดลเศรษฐกิจคือมัดของสมมติฐานชุดไหนกันแน่ — และถ้าสมมติฐานหนึ่งข้อนั้นผิด ข้อสรุปจะพลิกกลับไปอย่างไร

ถ้าทำเป็นทีม เริ่มด้วยขั้นถัดไปหนึ่งขั้นนี้ เลือก ทรัพยากรที่เป็นปัญหามากที่สุดเพียงตัวเดียว (มักเป็นเงินทองหรือหินตีบวก) ไม่ใช่ทรัพยากรทั้งหมด แล้วตั้งแค่โมเดลทรัพยากรเดี่ยวของ §8.2.3 ก่อน จากนั้นวางด่านซิมของ §8.2.5 ไว้กับการตัดสินใจเปลี่ยนเศรษฐกิจชนิดหนึ่ง (เช่น รางวัลอีเวนต์) แค่ทรัพยากร 1 ตัว + การตัดสินใจ 1 ชนิด ก็เปลี่ยนจุดที่เคยเถียงกันเรื่องการคาดเดาในที่ประชุมให้เป็นตัวเลขหนึ่งบรรทัดได้แล้ว

สรุปเป็น setup → prompt → verify คือ — setup: สกัด source·sink ของทรัพยากรที่เป็นปัญหาหนึ่งตัวออกมาเป็น yaml prompt: รับร่างโมเดลโหนดในรูปแบบ §8.2.3 โดยบังคับให้ระบุสมมติฐานพฤติกรรมผู้เล่นด้วย ★ verify: ให้มนุษย์ปฏิเสธ·ร้องขอใหม่ด้วยตัวเองต่อสมมติฐาน ★ ที่ AI รายงานและการจำแนกโหนด (โดยเฉพาะการโอนระหว่างผู้เล่น vs การสร้างใหม่)

สรุปประเด็นสำคัญของบท

• เศรษฐกิจไม่ใช่ทรัพยากร 5 ชนิด แต่เป็นกระแสไหลหลายสิบเส้นที่สะสมไปตามเวลา จึงต้องมีซิม
• ร่างโมเดลของ AI บังคับให้ระบุสมมติฐาน แล้วให้มนุษย์ปฏิเสธสมมติฐานนั้น
• การเปลี่ยนเศรษฐกิจตัดสินด้วยการผ่าน/ไม่ผ่านของด่านซิม ไม่ใช่การคาดเดาในที่ประชุม

ตัวอย่างบทถัดไป

• 8.3 Damage Simulator (2008\~) — เครื่องมือซิมที่มีอายุ 18 ปี ถูกนำกลับมาใช้ใหม่ในยุค AI อย่างไร

8.3 Damage Simulator — วันที่ DPS ในเอกสารกับผลลัพธ์จากการจำลองแยกทางกัน

เช้ามืดวันหนึ่งในปี 2008 ผมนั่งตรวจเลขชุดเดิมซ้ำสามรอบอยู่หน้าไฟล์ Excel แผ่นเดียว ในเอกสารออกแบบเขียนไว้ว่าตัวละครดาบตัวหนึ่งสร้างความเสียหายต่อวินาทีได้ 847 แต่ตัววันนั้นเองที่ผมรันซิมูเลเตอร์เป็นครั้งแรก โดยใส่ตัวละครตัวเดิมด้วยสเปกเดียวกันทุกอย่าง มันกลับให้ค่าออกมา 612 ห่างกัน 27% หนึ่งในสองค่านี้โกหก และตอนนั้นผมยังไม่รู้ว่าฝั่งไหนคือคำโกหก

DPS ในเอกสารคือคำสัญญาบนกระดาษ เป็นเลขคณิตของความเสียหายต่อสกิลหนึ่งครั้งคูณกับความถี่ในการปล่อยสกิล ส่วน DPS จากซิมูเลเตอร์คือผลที่ได้จากการเอาคำสัญญานั้นไปฟันจริง 1,000 ครั้ง คูลดาวน์ทับซ้อนกัน เวลาถูกท่าร่ายสกิลกินไป คริติคอลไม่ออกตามค่าคาดหวัง — แรงเสียดทานที่กระดาษไม่รู้จักเข้ามาแทรก ช่องว่าง 27% นี้แหละคือที่ทางที่ทำให้นักออกแบบสายปรับสมดุลมีกินมีใช้ ถ้าเชื่อกระดาษ พอเกมออกแล้วก็ได้ร้องไห้

บทนี้คือเรื่องราวของเครื่องมือชิ้นหนึ่ง Damage Simulator ที่ผมสร้างขึ้นในปี 2008 และไม่เคยวางมือจากมันมาจนถึงทุกวันนี้ ผมจะพาไล่ดูว่าผมตามรอยจุดที่เอกสารกับผลลัพธ์แยกทางกันอย่างแม่นยำได้อย่างไร และอีก 18 ปีต่อมาผมเอา AI มาช่วยในการตามรอยนั้นอย่างไร โดยติดตามผ่านบันทึกเซสชันจริง (worked transcript) จริงหนึ่งครั้ง

8.3.1 ทำไม DPS ในเอกสารถึงโกหกอยู่เสมอ

ก่อนอื่นมาแกะดูตัวตนของ 612 กับ 847 นั้นกัน นักออกแบบรุ่นน้องที่เขียนเอกสารฉบับนี้ (ต่อไปจะเรียกว่าทีมเมเบอร์ A) ไม่ได้ทำอะไรผิดเลย เขาคูณตามที่ตารางสกิลระบุไว้ทุกประการ

การคำนวณ DPS ตามเอกสารหน้าตาเป็นแบบนี้ สมมติว่าตัวละครหนึ่งมีสามสกิล

การคำนวณในเอกสารของทีมเมเบอร์ A ตั้งอยู่บนสมมติฐานในอุดมคติว่า "ใช้แต่ละสกิลทุกครั้งที่คูลดาวน์หมดโดยไม่พลาดเลย" ฟันขวางสร้าง 320 ทุก 3 วินาที แทงสร้าง 540 ทุก 6 วินาที และตีปกติเข้ามาเติมช่วงเวลาที่ว่าง พอคิดเป็นเลขคณิตก็ได้ออกมาสวยงามที่ 847 บนกระดาษนั้นตัวละครราวกับมีหลายมือ ท่าร่ายสกิลจึงไม่ขวางกันเอง

เหตุผลที่ซิมูเลเตอร์ให้ค่า 612 มีเพียงข้อเดียวคือมันมีมือเดียว ระหว่างที่กำลังร่ายสกิลแทงที่ใช้เวลา 0.9 วินาที ต่อให้คูลดาวน์ของฟันขวางหมดก็ใช้ไม่ได้ การที่ท่าร่ายสกิลกินกันเองแบบนี้คือ การชนกันของ global cooldown ซึ่งในเอกสารไม่มี กระดาษคือสุญญากาศที่ไม่มีแรงเสียดทาน ส่วนซิมคือสนามรบที่มีแรงเสียดทาน ความจริงข้อแรกที่ผมเรียนรู้จากการทำงานนี้มา 24 ปีคือสิ่งนี้ — DPS ในเอกสารคือเพดานสูงสุด ไม่ใช่ค่าที่วัดได้จริง และผู้เล่นเล่นเกมด้วยค่าที่วัดได้จริง ไม่ใช่ด้วยเพดานสูงสุด

8.3.2 บันทึกเซสชันจริง — สอบถามที่มาของ 612 จาก AI

ผมในปี 2008 อุดช่องว่าง 27% นี้ด้วยมือ ไล่อ่านล็อกของซิมทีละบรรทัดด้วยตา แล้วนับว่าสกิลถูกบล็อกที่เฟรมไหน ใช้เวลาครึ่งวัน ผ่านมา 18 ปี ตอนนี้ผมโยนล็อกชุดเดียวกันนั้นให้ Claude ข้างล่างนี้คือเนื้อหาเต็มของเซสชันหนึ่งที่ผมรันจริง ผมไม่สรุปย่อ และใส่ความพยายามครั้งแรกที่พลาดเป้าลงไปตามจริง — เพราะการพลาดเป้านั้นคือครึ่งหนึ่งของวิธีใช้เครื่องมือชิ้นนี้

พรอมต์ที่ผมโยนไปเป็นแบบนี้

ที่แนบมาคือบางส่วนของล็อกการต่อสู้ 1,000 ติกของตัวละครเดี่ยวจาก Damage Simulator (damage_sim/, Python) ของเรา ตามเอกสาร DPS ของตัวละครนี้คือ 847 แต่ผลจากซิมออกมาเป็น 612 จงหาสาเหตุของช่องว่าง 27% จากในล็อก รูปแบบของล็อกคือ [tick] event skill=SKILL state=STATE อย่าเดา ให้อ้างเฉพาะหลักฐานที่มีอยู่ในล็อกเท่านั้น ถ้าหลักฐานไม่พอ ให้บอกว่าไม่พอ

[0.0] cast skill=แทง state=START
[0.9] cast skill=แทง state=HIT dmg=540
[0.9] cast skill=ฟันขวาง state=BLOCKED reason=GCD
[1.5] cast skill=ตีปกติ state=HIT dmg=180
[1.9] cast skill=ตีปกติ state=BLOCKED reason=GCD
[3.0] cast skill=ฟันขวาง state=HIT dmg=320
[3.6] cast skill=ตีปกติ state=HIT dmg=180
... (994 lines omitted)
[997.2] cast skill=แทง state=HIT dmg=540

ผลลัพธ์ดิบของ Claude เป็นแบบนี้ (ไม่ได้ขัดเกลา)

ข้อเท็จจริงที่ยืนยันได้จากล็อก:

1. อีเวนต์ state=BLOCKED reason=GCD ปรากฏซ้ำ ๆ ที่ [0.9] ฟันขวางถูกบล็อก และที่ [1.9] ตีปกติถูกบล็อกด้วยเหตุ GCD (global cooldown)
2. ก่อนที่การร่ายสกิลแทง (0.0→0.9, 0.9 วินาที) จะจบลง สกิลอื่นไม่สามารถปล่อยได้ ดูเหมือนเป็นโครงสร้างที่เวลาร่ายเข้าครอบครอง GCD
3. ดังนั้นสมมติฐานในเอกสารที่ว่า "ปล่อยทุกสกิลทุกครั้งที่คูลดาวน์หมด" จึงพังลง ในความเป็นจริงท่าร่ายสกิลชนกันเอง ทำให้การปล่อยบางส่วนตกหล่นไป

อย่างไรก็ตาม ล็อกที่ให้มามีเพียง 7 บรรทัดจากทั้งหมด 1,000 บรรทัด ไม่สามารถสรุปได้จาก 7 บรรทัดนี้ว่าช่องว่าง 27% ที่แม่นยำนั้นอธิบายได้ด้วยการชนกันของ GCD เพียงอย่างเดียวหรือไม่ ต้องรวมยอดจำนวนครั้งที่เกิดอีเวนต์ BLOCKED ทั้งหมด และความเสียหายรวมที่ตกหล่นไปเพราะมัน จึงจะตรวจสอบ 27% ได้ ถ้าให้ยอดรวม BLOCKED ของล็อกทั้งหมดมา ผมจะยืนยันเชิงปริมาณให้

การที่หยุดตรงนี้คือเรื่องสำคัญ AI ชี้ สาเหตุได้ แต่ พิสูจน์ 27% ไม่ได้ และมันบอกข้อจำกัดของตัวเองออกมา ในจุดที่นักออกแบบสายกระดาษคงจบการประชุมด้วยประโยค "เป็นเพราะ GCD นี่เอง" เครื่องมือกลับยืนยันว่า "จาก 7 บรรทัดยังไม่รู้" ผมพิจารณาแล้วว่าข้อเรียกร้องนั้นชอบธรรม — นี่แหละคือการตรวจสอบโดยมนุษย์ ผมจึงดึงยอดรวม BLOCKED ของล็อกทั้งหมดออกมาแล้วโยนกลับไปอีกครั้ง

นี่คือยอดรวมของทั้ง 1,000 ติก BLOCKED รวม 412 ครั้ง ในจำนวนนั้นเป็นเหตุ GCD 388 ครั้ง เป็นเหตุคูลดาวน์ยังไม่พร้อม 24 ครั้ง ความเสียหายที่ประมาณว่าตกหล่นไปเพราะ BLOCKED เมื่อแปลงเป็นค่าฟันขวางอยู่ที่ราว 19,800 ตลอดการต่อสู้ 1,000 ติก (= วินาที) ความเสียหายที่เอกสารคาดหวังคือ 847,000 ส่วนความเสียหายสะสมที่ซิมวัดได้จริงคือ 612,300 จงทบทวนช่องว่าง 27% ใหม่ด้วยตัวเลขชุดนี้

ผลลัพธ์ครั้งที่สองของ Claude

ขอตรวจสอบด้วยยอดรวม

• สะสมที่เอกสารคาดหวัง: 847,000
• สะสมที่ซิมวัดได้จริง: 612,300
• ช่องว่าง: 234,700 (27.7%)

องค์ประกอบของช่องว่างนี้: - ตกหล่นโดยตรงจากการชนของ GCD (388 ครั้ง): ที่ประมาณว่าราว 19,800 นั้นเป็นค่าที่แปลงเป็นฟันขวาง แต่ต้องบวกค่าเสียโอกาส (opportunity cost) ที่ช่องตกหล่นนั้นเคยจะใส่สกิลที่ความเสียหายสูงกว่าได้เข้าไปด้วย หากแปลงช่องที่ตกหล่นเป็นค่าความเสียหายเฉลี่ย ส่วนที่ตกหล่นจะมากกว่า 19,800 - แต่ทั้ง 234,700 อธิบายได้ด้วย BLOCKED อย่างเดียวไม่ได้ การตีความช่องว่างที่เหลือจะต่างกันไปขึ้นกับว่าค่า 847 ในเอกสารเป็น "ค่าที่รวมค่าคาดหวังของคริติคอลเฉลี่ยไว้แล้ว" หรือเป็น "ค่าพื้นฐานที่ไม่รวมคริติคอล" หากบอกสมมติฐานเรื่องคริติคอลของ 847 ในเอกสารมา ผมจะแยกย่อยช่องว่างที่เหลือให้

หยุดอีกครั้ง และก็หยุดในจุดที่ถูกต้องอีกครั้ง ว่า 847 ในเอกสารคำนวณคริติคอลไว้อย่างไร — นี่คือข้อมูลที่ไม่มีในล็อก และอยู่แต่ในหัวของทีมเมเบอร์ A เท่านั้น AI รู้ขอบเขตของข้อมูลที่ตัวเองมี พอผมไปตรวจดูก็พบว่า 847 ในเอกสารเป็นค่าที่นำคริติคอลโอกาส 20% คูณ 1.5 เท่ามาทำให้เรียบเป็นค่าคาดหวังแล้วใส่ลงไป ส่วนซิมเป็นการรันหนึ่งรอบหลังตรึง seed ที่จำนวนครั้งคริติคอลจริงออกมาต่ำกว่าค่าคาดหวัง พูดอีกอย่างคือช่องว่าง 27% เป็นค่าที่ผสมระหว่าง การชนของ GCD (เชิงโครงสร้าง · เกิดซ้ำได้) กับ ความแปรปรวนของคริติคอล (เชิงสถิติ · ดวงของรอบนี้รอบเดียว)

การแยกย่อยนี้แหละคือบทสรุป ส่วนที่เป็นการชนของ GCD คือปัญหาจริงที่ต้องแก้ด้วยการออกแบบ ส่วนที่เป็นความแปรปรวนของคริติคอลคือสัญญาณรบกวนที่จะหายไปเองเมื่อเปลี่ยน seed แล้วเฉลี่ยจาก 1,000 รอบ ถ้าเอาทั้งสองส่วนมาปนกันแล้วบัฟด้วยเหตุผลว่า "ตัวละครอ่อน" ตัวละครที่ปกติดีในค่าเฉลี่ย 1,000 รอบจะกลายเป็นแกร่งเกินไป สิ่งที่สร้างการแยกแยะนี้ขึ้นมา — ที่กระดาษไม่รู้ ซิมรอบเดียวก็ไม่รู้ และ AI ลำพังก็ไม่รู้ — คือการตรวจสอบโดยมนุษย์ที่เอายอดรวมจากล็อกและสมมติฐานที่ซ่อนอยู่ในเอกสารมาประกบกัน

8.3.3 อินพุตหนึ่งชุดกลายเป็นเอาต์พุตหนึ่งชุด — การผ่าซิม

ลองคลี่ดูอินพุต-เอาต์พุตของเครื่องมือที่เซสชันเมื่อกี้ส่องดูออกมาเป็นชุดเดียวกัน สุดท้ายแล้วซิมูเลเตอร์ก็คือฟังก์ชันที่ซื่อตรง อินพุตเดียวกันให้เอาต์พุตเดียวกัน อินพุตมารวมกันจากสามสาย

flowchart LR
    A["ชีตข้อมูลเกม
(ตารางสกิล·สเตตัสตัวละคร)
read-only"] --> SIM
    B["ไฟล์ yaml สถานการณ์
(เงื่อนไขการต่อสู้·ระยะเวลา·
องค์ประกอบเป้าหมาย)"] --> SIM
    C["seed=42
(ตรึงค่าสุ่ม)"] --> SIM
    SIM["Damage Simulator
domain/formulas.py
run_combat() × 1000틱"]
    SIM --> R1["ความเสียหายสะสมที่วัดได้
612,300"]
    SIM --> R2["ล็อก BLOCKED
412 ครั้ง (GCD 388)"]
    SIM --> R3["คริติคอลที่เกิด
วัดได้ 17.2% vs คาดหวัง 20%"]
    R1 --> REP["รายงาน markdown
เอกสาร 847 vs ซิม 612
แยกย่อยช่องว่าง: โครงสร้าง 19% + ความแปรปรวน 8%"]
    R2 --> REP
    R3 --> REP

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    class SIM code;
    class A,B,C,R1,R2,R3,REP data;

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

อินพุตหนึ่งชุดที่เป็นรูปธรรม (ไฟล์ yaml สถานการณ์) หน้าตาเป็นแบบนี้

# scenarios/single_dps_check.yaml
scenario: single_target_dps
duration_ticks: 1000      # สมมติ 1 ติก = 0.1s, การต่อสู้ 100 วินาที
seed: 42                  # เชิงกำหนด — อินพุตเดียวกันเอาต์พุตเดียวกัน
actor:
  char_id: K_004          # อ่านจากชีตข้อมูลเกม
  skill_rotation: optimal # เมื่อ GCD ชน ให้ความเสียหายคาดหวังสูงสุดมาก่อน
target:
  defense: 1200
  hp: infinite            # ดัมมีเลือดไม่จำกัดสำหรับวัด DPS
report:
  compare_to_spec: 847    # ใส่ DPS เอกสารเพื่อแยกย่อยช่องว่างอัตโนมัติ

และเอาต์พุตหนึ่งชุด (ตัดมาบางส่วนจากรายงาน) เป็นแบบนี้

# Damage Simulator Report — K_004 single DPS
อินพุต: scenarios/single_dps_check.yaml | seed=42 | data rev. 2026-06-05

## เทียบกับเอกสาร
- DPS เอกสาร:       847   (รวมการทำให้เรียบของค่าคาดหวังคริติคอล 20%·1.5x)
- DPS ที่ซิมวัดได้:  612   (seed นี้ 1 รอบ)
- ช่องว่าง:            -27.7%

## แยกย่อยช่องว่าง
- เชิงโครงสร้าง (การชน GCD, เกิดซ้ำได้):   -19.2%  ← เป้าหมายการทบทวนการออกแบบ
- เชิงสถิติ (ความแปรปรวนคริติคอล, รอบนี้): -8.5%  ← คาดว่าหายไปเมื่อเฉลี่ย 1000 รอบ

## ตรวจสอบการเกิดซ้ำ
- รัน seed=42 ซ้ำ 3 ครั้ง → 612,300 / 612,300 / 612,300 (ตรงกัน)
- เฉลี่ย DPS 1000 รอบจาก seed 0~999 → 731 (หลังหักความแปรปรวนคริติคอล)

ลองดูบรรทัดสุดท้าย ค่าเฉลี่ยจากการรัน 1,000 รอบด้วย seed 0\~999 คือ 731 ช่องว่าง 116 (13.7%) ระหว่างเอกสาร 847 กับค่าเฉลี่ย 1,000 รอบ 731 นั่นแหละคือขนาดของ ปัญหาเชิงโครงสร้างที่แท้จริง ที่ชื่อว่าการชนของ GCD ค่าที่ควรเป็นอินพุตของการประชุมออกแบบคือ 731 นี้ ไม่ใช่ 612 ของรอบเดียว ไม่ใช่ 847 ของกระดาษ และไม่ใช่ 612 ของรอบที่ดวงไม่ดี แต่เป็น 731 ที่ 1,000 รอบเห็นพ้องกัน การได้ตัวเลขนี้มากำในมือนี่แหละคืองานของนักออกแบบสายปรับสมดุล

8.3.4 มือของปี 2008 และมือของปี 2026

เครื่องมือชิ้นนี้มีอายุ 18 ปี แต่ไม่ได้มีชีวิตอยู่ด้วยโค้ดชุดเดิม ไม้แขวนยังเป็นไม้เดิม เปลี่ยนแต่เสื้อมาห้าครั้ง ไม้แขวนคือตรรกะของรายงานข้างบน — ขั้นตอนการแยกดูเอกสารกับค่าที่วัดได้จริง แยกย่อยช่องว่างออกเป็นโครงสร้างกับความแปรปรวน แล้วตรวจสอบด้วยการเกิดซ้ำ ขั้นตอนนี้เหมือนกันทุกตัวอักษร ทั้งใน Excel VBA (ภาษามาโครของ Excel) ปี 2008 และใน Python ปี 2026

เคล็ดที่ทำให้ผ่านการเปลี่ยนเสื้อห้าครั้งมาได้ถูกสลักไว้ในโครงสร้างโฟลเดอร์

damage_sim/
├── domain/          # ไม้แขวน — เหมือนเดิมมา 18 ปี
│   ├── formulas.py      # สูตรความเสียหาย·ตัดสินการชน GCD
│   └── metrics.py       # ตรรกะแยกย่อยช่องว่าง
├── adapters/        # ข้อมูลเกมแบบ read-only
│   └── excel_reader.py
├── runners/         # เสื้อ — เปลี่ยนทุกครั้งที่เทคโนโลยีเปลี่ยน
│   └── cli_runner.py
└── reporters/       # เสื้อ — รูปแบบการออกรายงาน
    └── markdown_report.py

พอเทคโนโลยีเปลี่ยน ก็เขียนแค่ runners/ กับ reporters/ ขึ้นใหม่ ส่วนตรรกะแยกย่อยช่องว่างใน domain/ ยังคงรอดมาเป็นสินทรัพย์ 18 ปีตามเดิม สูตรตัดสินการชน GCD ที่ผมเขียนด้วยเซลล์ Excel ในปี 2008 ตอนนี้ยังรันอยู่ใน formulas.py โดยเปลี่ยนแค่ลายเซ็นของฟังก์ชัน ที่ว่าการตอกเครื่องมือไว้กับเทคโนโลยีเดียวเท่ากับให้มันแก่ตายไปพร้อมเทคโนโลยีนั้น ผมเรียนรู้มาจากการส่งเครื่องมือที่ตายไปแล้วหลายชิ้น

LLM ที่ผมเอามาต่อในปี 2025 ไม่ใช่ไม้แขวนอันใหม่ แต่เป็นมือใหม่ อย่างที่เห็นในเซสชันก่อนหน้า AI คือมือที่ อ่านล็อกและตั้งสมมติฐาน การตามรอยล็อกที่เคยใช้เวลาครึ่งวันลดเหลือไม่กี่นาที แต่ไม่แตะต้องไม้แขวน — สิ่งที่ ตัดสิน ว่าช่องว่างเป็น 27% หรือไม่ คริติคอลออกกี่เปอร์เซ็นต์ ยังคงเป็นคอร์เชิงกำหนดที่ตรึง seed ไว้ ทันทีที่ปล่อยให้ LLM เข้าไปอยู่ในที่ตรงนั้น การตรวจสอบแบบ regression จะทำไม่ได้ แล้วเครื่องมือก็ตาย

8.3.5 คอร์เชิงกำหนดกับสิ่งที่อยู่นอกมัน — จะขีดเส้นตรงไหน

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

ด้านใน (เชิงกำหนด — ห้าม AI): - สูตรความเสียหาย, การตัดสินการชน GCD, การเกิดคริติคอล, การรวมยอดสะสม - รันด้วย seed=42 สามครั้งต้องได้ 612,300 เหมือนกันทั้งสามครั้ง ถ้าข้อนี้พังก็เทียบรายงานของเมื่อวานกับรายงานของวันนี้ไม่ได้

ด้านนอก (สมมติฐาน·การตีความ — ยินดีต้อนรับ AI): - การสอบถามสาเหตุอย่าง "ทำไมอัตราชนะของการจับคู่ตัวละครชุดนี้ถึงผิดปกติ" - หาแพตเทิร์น BLOCKED ในล็อก, ร่างรายงานภาษาธรรมชาติ, ร่างไฟล์ yaml สถานการณ์

บันทึกเซสชันจริงก่อนหน้านี้เคลื่อนไหวอยู่บนเส้นนี้พอดี AI ตั้งสมมติฐานว่า "การชน GCD คือสาเหตุ" ขึ้นมาอย่างรวดเร็วจากด้านนอก แต่ตัวเลข 27% และตัวเลข 612 เป็นค่าที่คอร์เชิงกำหนดคำนวณไว้จนถึงที่สุด AI เพียงรับค่านั้นมาตีความเท่านั้น และมันหยุดถึงสองครั้งด้วยคำว่า "ข้อมูลเท่านี้สรุปไม่ได้" — โดยเรียกร้องข้อมูลที่คอร์เชิงกำหนดให้ไม่ได้ (สมมติฐานคริติคอลของเอกสาร) การหยุดนี้คือเครื่องหมายของเครื่องมือที่ดี คือการไม่เข้าใจผิดว่าสมมติฐานเท่ากับการวินิจฉัย

มีเรื่องหนึ่งที่ผมขอบอกตามตรงเกี่ยวกับตัวเลข ตัวเลขเฉพาะอย่าง 847·612·731·412 ครั้ง ในบทนี้เป็นค่าตัวอย่างที่ประกอบขึ้นเพื่อการอธิบาย แต่ ทิศทาง ที่ว่า DPS ในเอกสารออกมาสูงกว่าค่าที่ซิมวัดได้จริงเสมอ โครงสร้าง ที่ว่าช่องว่างนั้นแยกย่อยออกเป็นการชนเชิงโครงสร้างกับความแปรปรวนเชิงสถิติ และ หลักการ ที่ว่าการตรึง seed เป็นเงื่อนไขตั้งต้นของการตรวจสอบ regression ล้วนเป็นสิ่งที่ผมยืนยันซ้ำจากการใช้งานจริงตลอด 18 ปีตั้งแต่ปี 2008 ขนาดของอัตราส่วนต่างกันไปในแต่ละโปรเจกต์ แต่ทิศทางกับโครงสร้างไม่เคยเปลี่ยน

ลองทำดู — แยกย่อยช่องว่างเทียบเอกสาร 1 ครั้ง

setup. เลือกตัวละครหนึ่งตัวจากข้อมูลเกม แล้วหาตารางสกิล (ความเสียหาย·คูลดาวน์·เวลาร่าย) กับ DPS เอกสารมาให้พร้อม ถ้าไม่มีซิมูเลเตอร์ ให้เขียนสคริปต์ขั้นต่ำที่รันการต่อสู้กับเป้าหมายเดี่ยว 1,000 ติก หัวใจมีข้อเดียวคือต้องรับ seed เป็นอาร์กิวเมนต์เพื่อตรึงค่าได้

prompt. โยนล็อกของซิม (รวมอีเวนต์ BLOCKED) พร้อมกับ DPS เอกสารไปด้วยกัน

ที่แนบมาคือล็อกการต่อสู้ 1,000 ติกของตัวละคร 1 ตัว และยอดรวม BLOCKED DPS เอกสารคือ [N] แต่ผลจากซิมคือ [M] จงแยกย่อยสาเหตุของช่องว่างด้วยหลักฐานจากล็อกเท่านั้น แยกสาเหตุเชิงโครงสร้าง (การชนที่เกิดซ้ำ) ออกจากสาเหตุเชิงสถิติ (ความแปรปรวนของรอบนี้) ถ้าหลักฐานไม่พอ ให้บอกว่าไม่พอ และชี้ว่าต้องการอะไรเพิ่ม

verify. เอาสาเหตุเชิงโครงสร้างที่ AI ชี้ไปตรวจสอบด้วยค่าเฉลี่ย 1,000 รอบโดยเปลี่ยน seed ถ้าช่องว่างยังเหลืออยู่แม้ในค่าเฉลี่ยก็คือปัญหาเชิงโครงสร้างจริง ถ้าหายไปก็เป็นสัญญาณรบกวนจากความแปรปรวน ถ้า AI หยุดด้วยคำว่า "สรุปไม่ได้" นั่นไม่ใช่ความล้มเหลวแต่เป็นเรื่องปกติ — ในจุดที่มันหยุด มนุษย์เข้าไปเติมสมมติฐานที่ซ่อนอยู่ในเอกสาร

ฉบับย่อสำหรับคนเดียว

ถ้าคุณเป็นนักพัฒนาคนเดียวที่ไม่มีทั้งซิมูเลเตอร์และ ML ก็รันขั้นตอนเดียวกันได้ด้วย Excel แผ่นเดียวกับ AI เท่านั้น เขียนตารางสกิลลงในชีต แล้วสร้างซิม 1,000 แถวที่ใช้ RAND() ทอยคริติคอลในคอลัมน์หนึ่ง เนื่องจากตรึง seed ไม่ได้ ให้กด F9 คำนวณใหม่ 100 ครั้งแล้วหาค่าเฉลี่ยด้วยมือ จากนั้นโยนช่องว่างระหว่างค่าเฉลี่ยนั้นกับ DPS เอกสารให้ AI โดยบอกว่า "ช่วยแยกออกเป็นสาเหตุเชิงโครงสร้างกับสาเหตุความแปรปรวน" เครื่องมือจะเล็กก็จริง แต่ไม้แขวน — การแยกย่อยช่องว่างเทียบเอกสาร, การแยกโครงสร้างออกจากความแปรปรวน, การตรวจสอบการเกิดซ้ำ — ยังตั้งอยู่เหมือนเดิมทุกประการ

สรุปประเด็นสำคัญของบท

• DPS เอกสารคือเพดานสูงสุดที่ไม่มีแรงเสียดทาน ส่วนค่าที่วัดได้จริงซึ่งผู้เล่นเจอนั้นซิมจะหาเจอด้วยค่าเฉลี่ย 1,000 รอบ
• ช่องว่างระหว่างเอกสารกับซิมต้องแยกออกเป็นการชนเชิงโครงสร้างกับความแปรปรวนเชิงสถิติ จึงจะเห็นปัญหาการออกแบบที่แท้จริง
• ด้านในของคอร์เชิงกำหนดห้าม AI ส่วนด้านนอกที่เป็นสมมติฐาน·การตีความนั้นยินดีต้อนรับ AI ในฐานะมือใหม่

ตัวอย่างบทถัดไป

• 8.4 การจำลองปรับสมดุลโดยมี AI ช่วย — ตำแหน่งต่าง ๆ ที่อัตโนมัติงานรอบ ๆ ได้โดยยังรักษาคอร์เชิงกำหนดไว้

8.4 การจำลองสมดุลด้วยความช่วยเหลือของ AI

บ่ายวันศุกร์ เวลาสี่โมง การจำลอง PvP 5:5 อัตโนมัติของอัลฟาบิลด์จำนวน 1,200 แมตช์ก็จบลง ผลลัพธ์ JSON มีขนาด 4 เมกะไบต์ ที่ไหนสักแห่งในนั้นมีบรรทัดหนึ่งบันทึกไว้ว่า "อัตราชนะของทีม A 92%" ทั้งที่อัตราชนะเฉลี่ยอยู่ที่ 52% ผมใช้เวลา 40 นาทีในการตามหาบรรทัดนั้น และจนกระทั่งเลิกงานก็ยังหาสาเหตุไม่ได้ว่าทำไมถึงเป็นเช่นนั้น