| name | writing-beats |
| description | งานเขียน โหมด exploit — ประกอบวัตถุดิบดิบให้เป็น journey ของ beat โดย ground แต่ละ term ก่อนที่ beat จะพิงมัน |
| disable-model-invocation | true |
ผู้ใช้ได้ส่ง (หรือกำลังจะส่ง) ไฟล์ markdown ที่เป็นวัตถุดิบดิบมาให้ นี่คือโหมด exploit: ช่วงสำรวจจบแล้ว กองวัตถุดิบนิ่งแล้ว — ตัดสินใจเลือกเส้นทางผ่านมัน แล้วขุดจากกองนั้นมาเติมแต่ละ beat
ถ้าผู้ใช้ไม่ได้บอกว่าจะเซฟบทความไว้ที่ไหน ถามครั้งเดียวแล้วจำ path นั้นไว้
จากนั้นเดิน journey ทีละ beat สไตล์ choose-your-own-adventure:
- ตั้ง prerequisite ก่อน ก่อนเริ่ม beat ใด ๆ ตกลงกับผู้ใช้ว่าคนอ่านรู้อะไรมาก่อนแล้วบ้าง — นั่นคือ concept ที่ grounded ตั้งแต่ต้น ที่เหลือทั้งหมดต้องถูก ground โดย beat ใด beat หนึ่งก่อนที่ beat ถัด ๆ ไปจะใช้มันได้ ดู Grounding
- เขียน starting beat ตัวเลือก 2–3 อัน ดึงมาจากวัตถุดิบดิบ แต่ละอันคือทางเข้าบทความคนละแบบ แต่ละอันพิงได้เฉพาะ concept ที่ grounded แล้ว และให้ระบุว่าแต่ละอัน ground concept ใหม่อะไรบ้าง โชว์ beat ให้ผู้ใช้ดูก่อนเขียนลงไฟล์บทความ ผู้ใช้เลือกหนึ่งอัน แล้ว preview ว่าตัวเลือกนั้นปลดล็อก beat อะไรต่อ — เหมือนให้ผู้ใช้มองเห็นเส้นทางข้างหน้านิดหน่อย
- พอผู้ใช้เลือก starting beat แล้ว เขียน เฉพาะ beat นั้น ลงไฟล์บทความ beat หนึ่งอาจยาวแค่ประโยคเดียวหรือหลายย่อหน้า — แล้วแต่ว่า beat นั้นโดยธรรมชาติเป็นแบบไหน แล้วหยุดตรงนั้น
- อ่านไฟล์บทความจาก disk ใหม่ จากนั้นเสนอ next beat ตัวเลือก 2–3 อัน — ทิศทางต่าง ๆ ที่ journey จะหักเลี้ยวไปได้จากจุดที่บทความยืนอยู่ตอนนี้ แต่ละอันต้องไปถึงได้จากเซ็ต concept ที่ grounded อยู่ปัจจุบัน และระบุว่าแต่ละอัน ground อะไรเพิ่ม
- วนขั้น 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 แบบอื่น" ก็ทำเลย — แก้ตรงที่เดิม ส่วนที่เหลือไม่ต้องแตะ
