writing-beats

name	writing-beats
description	งานเขียน โหมด exploit — ประกอบวัตถุดิบดิบให้เป็น journey ของ beat โดย ground แต่ละ term ก่อนที่ beat จะพิงมัน
disable-model-invocation	true

ผู้ใช้ได้ส่ง (หรือกำลังจะส่ง) ไฟล์ markdown ที่เป็นวัตถุดิบดิบมาให้ นี่คือโหมด exploit: ช่วงสำรวจจบแล้ว กองวัตถุดิบนิ่งแล้ว — ตัดสินใจเลือกเส้นทางผ่านมัน แล้วขุดจากกองนั้นมาเติมแต่ละ beat

ถ้าผู้ใช้ไม่ได้บอกว่าจะเซฟบทความไว้ที่ไหน ถามครั้งเดียวแล้วจำ path นั้นไว้

จากนั้นเดิน journey ทีละ beat สไตล์ choose-your-own-adventure:

1. ตั้ง prerequisite ก่อน ก่อนเริ่ม beat ใด ๆ ตกลงกับผู้ใช้ว่าคนอ่านรู้อะไรมาก่อนแล้วบ้าง — นั่นคือ concept ที่ grounded ตั้งแต่ต้น ที่เหลือทั้งหมดต้องถูก ground โดย beat ใด beat หนึ่งก่อนที่ beat ถัด ๆ ไปจะใช้มันได้ ดู Grounding
2. เขียน starting beat ตัวเลือก 2–3 อัน ดึงมาจากวัตถุดิบดิบ แต่ละอันคือทางเข้าบทความคนละแบบ แต่ละอันพิงได้เฉพาะ concept ที่ grounded แล้ว และให้ระบุว่าแต่ละอัน ground concept ใหม่อะไรบ้าง โชว์ beat ให้ผู้ใช้ดูก่อนเขียนลงไฟล์บทความ ผู้ใช้เลือกหนึ่งอัน แล้ว preview ว่าตัวเลือกนั้นปลดล็อก beat อะไรต่อ — เหมือนให้ผู้ใช้มองเห็นเส้นทางข้างหน้านิดหน่อย
3. พอผู้ใช้เลือก starting beat แล้ว เขียน เฉพาะ beat นั้น ลงไฟล์บทความ beat หนึ่งอาจยาวแค่ประโยคเดียวหรือหลายย่อหน้า — แล้วแต่ว่า beat นั้นโดยธรรมชาติเป็นแบบไหน แล้วหยุดตรงนั้น
4. อ่านไฟล์บทความจาก disk ใหม่ จากนั้นเสนอ next beat ตัวเลือก 2–3 อัน — ทิศทางต่าง ๆ ที่ journey จะหักเลี้ยวไปได้จากจุดที่บทความยืนอยู่ตอนนี้ แต่ละอันต้องไปถึงได้จากเซ็ต concept ที่ grounded อยู่ปัจจุบัน และระบุว่าแต่ละอัน ground อะไรเพิ่ม
5. วนขั้น 3–5 จนบทความไปถึงจุดจบตามธรรมชาติ

Grounding

ทุก concept ต้องถูก ground ก่อนที่ beat จะพิงมันได้: คนอ่านต้องรู้มันมาก่อนตั้งแต่ต้น หรือได้เจอมันใน beat ก่อนหน้า beat ที่เอื้อมไปหา concept ที่ยังไม่ grounded จะทำให้คนอ่านหลุด — นั่นคือท่าเดียวที่ journey นี้ห้ามทำ หน่วยที่นับคือ concept ไม่ใช่คำที่ใช้เรียกมัน: beat อาจพิงไอเดียที่คนอ่านไม่มี ทั้งที่ไม่มีศัพท์เทคนิคโผล่มาเลยสักคำ และเมื่อ concept มีชื่อเรียก — มี term — การ ground มันหมายถึงส่งทั้งไอเดียและ term ให้ถึงพร้อมกัน

concept ถูก ground ได้สองทาง:

• Prerequisite — grounded ก่อน beat แรก คนอ่านพกมาเอง ตายตัวตั้งแต่เริ่ม
• Introduced — มี beat หนึ่งสถาปนามันขึ้นมา และหลังจากนั้นมันก็ grounded สำหรับทุก beat ที่ตามมา

ดังนั้น beat แต่ละอันทำสองงาน: มัน require concept ที่ grounded แล้ว และมัน ground concept ใหม่ เก็บ running list ว่าอะไร grounded แล้วบ้าง และอัปเดตทุกครั้งที่ beat หนึ่งลงจอด

นี่แหละคือสิ่งที่กำหนดรูปทรงของ choose-your-own-adventure: candidate beat จะไปถึงได้ก็ต่อเมื่อทุกอย่างที่มัน require ถูก ground แล้ว การเลือก beat ที่ ground concept X จะปลดล็อกทุก beat ที่รอ X อยู่ เวลาเสนอ next beat ทุกตัวเลือกต้องไปถึงได้จากเซ็ตที่ grounded อยู่ปัจจุบัน — และบอกด้วยว่าแต่ละอัน ground อะไร เพื่อให้ผู้ใช้เห็นว่ามันเปิดเส้นทางไหนบ้าง

คันโยกใหญ่คือการเลือกว่าอะไรเป็น prerequisite กับอะไรที่จะ ground ภายในตัวบทความ เรียกร้องความรู้ล่วงหน้ามากไปก็กันคนอ่านที่ไม่มีมันออกไป ground ในบทความมากไป beat ช่วงต้นก็จมอยู่กับคำนิยาม ตกลงเรื่องนี้กับผู้ใช้ตอนตั้ง prerequisite และหยิบกลับมาคุยใหม่ทุกครั้งที่ beat ที่น่าหยิบดันต้องใช้ concept ที่ยังไม่มีอะไร ground มันเลย — ทางแก้คือใส่ beat สำหรับ ground ก่อนหน้ามัน หรือเลื่อนขั้น concept นั้นเป็น prerequisite

Beat คืออะไร

beat คือหนึ่งการเคลื่อนไหวใน journey มันทำหนึ่งอย่าง — เปิดฉาก ตอกประเด็น ตั้งคำถาม แทรกเกร็ดเล็ก ๆ หรือบิดมุมมอง แล้วมันก็หยุด ทิ้งคนอ่านไว้ที่จุดที่ beat ถัดไปหักเลี้ยวต่อได้

ขนาดของ beat ขึ้นกับสิ่งที่มันต้องการ:

• ประโยคเดียว ถ้าการเคลื่อนไหวนั้นมีแค่นั้น ("แล้วก็ไม่มีอะไรเกิดขึ้นเลยสามสัปดาห์")
• ย่อหน้าสั้น ๆ ถ้าการเคลื่อนไหวต้องการการปูพื้น
• หลายย่อหน้า ถ้า beat นั้นเป็น vignette, ข้อโต้แย้ง หรือตัวอย่างที่จบในตัว

ถ้า "beat" หนึ่งต้องใช้ห้าย่อหน้ากับสามหัวข้อย่อย มันไม่ใช่ beat — มันคือสอง beat ที่ถูกกาวติดกัน แยกมันซะ

ขุดจากกอง

ดึงวัตถุดิบจากกองดิบมาเติมแต่ละ beat จะ paraphrase แยกส่วน ประกอบใหม่ หรือ quote ก็ได้ กองวัตถุดิบคือเหมืองหิน

จบ journey

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

จังหวะการเขียน

• ต่อท้ายทีละ beat ห้ามเขียนล่วงหน้าเด็ดขาด
• อ่านไฟล์บทความจาก disk ใหม่ก่อนเขียนทุกครั้ง รักษาการแก้ไขของผู้ใช้ไว้อย่างเคร่งครัด
• ถ้าผู้ใช้แก้ beat ก่อนหน้าอย่างมีนัยสำคัญ ให้มันส่งผลต่อสิ่งที่จะมาต่อ
• ถ้าผู้ใช้บอก "rewrite beat นั้น" หรือ "ย้อนกลับไปลอง beat 3 แบบอื่น" ก็ทำเลย — แก้ตรงที่เดิม ส่วนที่เหลือไม่ต้องแตะ