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

แล้วคุณภาพตกลงไหม คำตอบคือไม่ ซีรีส์นี้คือการค่อย ๆ สร้างรูปแบบที่ไม่ต้องอ่าน ด้วยกลไกทีละอย่าง

ช่วงท้ายของแต่ละตอนจะมีหัวข้อที่ชื่อว่า "วิธีการตรวจสอบ" ไม่จำเป็นต้องอ่านก่อน กลับมาอ่านเมื่ออยากเห็นกับตาตัวเองว่าทำไมกลไกที่วางไว้ถึงจำเป็น

เรียนรู้วิธีแก้จากอาการ

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

ไม่จำเป็นต้องจำก่อนว่าทำไมวิธีแก้นั้นถึงเหมาะ วางกลไกไว้หนึ่งอย่างก็รับมือได้แล้ว

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

เริ่มจากการตรวจสอบสิ่งที่นึกออก

เริ่มจากการนึกย้อนเพียงอย่างเดียว

AI coding agent ได้รับไฟล์ที่ชื่อว่า CLAUDE.md หรือ AGENTS.md ไว้เก็บกฎ ตอนนี้ไฟล์นั้นมีกี่บรรทัด และจำได้ไหมว่าบรรทัดไหนคือบรรทัดที่เพิ่มเข้าไปเมื่อสัปดาห์ก่อน แล้วบรรทัดนั้น AI ทำตามหรือเปล่าใน session ของวันนี้ ซึ่งก็คือการโต้ตอบกับ AI หนึ่งช่วงที่ต่อเนื่องกัน

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

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

wc -l CLAUDE.md   # เปลี่ยนเป็นชื่อไฟล์ที่ใช้อยู่จริง เช่น AGENTS.md

หยุดทำงานภายใน 3 สัปดาห์

เส้นทางที่พบบ่อยเป็นแบบนี้ สัปดาห์ที่ 1 ไฟล์คำสั่ง 10 บรรทัด AI ทำงานได้ดี สัปดาห์ที่ 2 เพิ่ม "ห้ามทำสิ่งนี้" 1 บรรทัดทุกครั้งที่ล้มเหลว จนกลายเป็น 30 บรรทัด ยังทำงานได้อยู่ แต่เริ่มมีวันที่ AI ทำผิดกฎที่เพิ่มไว้ก่อนหน้า สัปดาห์ที่ 3 พอมาถึง 60 บรรทัด สิ่งที่ AI เคยทำได้ในสัปดาห์ที่ 1 ก็ทำไม่ได้แล้ว

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

ที่ยุ่งยากที่สุดคือ ความพยายามปรับปรุงเองนั่นแหละที่กลับไปอยู่ฝั่งที่ทำให้สถานการณ์แย่ลง

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

กฎยิ่งเพิ่มก็ยิ่งเจือจาง การเพิ่มหนึ่งข้อคือการทำให้ข้ออื่นทั้งหมดอ่อนลงเล็กน้อย ดังนั้น "เพิ่มกฎเพื่อให้ทำตาม" จึงเป็นทางที่แพ้ตั้งแต่ในโครงสร้าง

Anthropic เขียนถึงเรื่องนี้ว่าเป็นทรัพยากรที่มีจำกัดและลดลงเรื่อย ๆ โดยเขียนไว้ว่า LLM มี attention budget และยิ่งจำนวน token เพิ่มขึ้น ความสามารถในการระลึกได้อย่างแม่นยำจากข้างในนั้นก็ยิ่งลดลง

เอกสารของ Claude Code ตรงกว่านั้น เขียนไว้ว่าไฟล์คำสั่งควรตั้งเป้าให้น้อยกว่า 200 บรรทัดต่อไฟล์ เพราะไฟล์ที่ยาวกิน context window มากกว่า และทำให้ทำตามน้อยลง

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

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

flowchart TB
  subgraph K["สิ่งที่โหลดเข้ามาทุก session ทุกครั้งที่ตอบ"]
    direction TB
    k1["ไฟล์คำสั่ง"]
    k2["รายการของ memory"]
    k3["บทสนทนาของ task ที่ทำอยู่"]
    k4["ผลลัพธ์ของ tool (ผลการทดสอบ diff …)"]
  end
  K --> B["attention budget ไม่เพิ่มขึ้น"]
  B --> R["การเพิ่มหนึ่งบรรทัดคือ<br/>การทำให้ทั้งหมดที่เหลืออ่อนลงเล็กน้อย"]

production project ที่อยู่ในมือของผมเองก็ผ่านจุดนี้มาแล้วเหมือนกัน คือ typingtube web service ที่ฝึกพิมพ์ดีดไปกับมิวสิกวิดีโอบน YouTube ได้ ซึ่งดูแลเองอยู่คนเดียว

ไฟล์คำสั่งโตขึ้นจนถึง 101 บรรทัด และ memory ที่สะสมไว้โตจนถึง 89 ไฟล์ ราว 1.1MB แค่ฉีดรายการกฎเข้าไปทุกครั้งด้วย hook ซึ่งเป็นกลไกที่แทรกเข้าไปตอน AI รัน command ก็ไปถึงสภาพที่มีราว 26KB เข้าไปอยู่ใน context window แล้ว

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

เทคนิคการไม่อ่าน

สิ่งที่อยู่ปลายทางของการเดินย้อนกลับ คือสิ่งที่ตรงข้ามกับ "ให้อ่านมากขึ้น"

ผลการทดสอบจะส่งมาถึงทั้งผมและ AI เฉพาะอันที่ล้มเหลว memory ไม่โตขึ้นเอง subagent หยุดตรงจุดที่ควรหยุดโดยไม่ต้องเฝ้า สิ่งที่เคยต้องอ่านหายไปทีละอย่าง แล้วก็เบาลงตามนั้น

ทำไมต้องเป็นกลไก ไม่ใช่กฎ กฎได้ผลเฉพาะเมื่อมีการอ่านเท่านั้น จะอ่านหรือไม่ ขึ้นอยู่กับความยาวของ context window ในตอนนั้น กลไกได้ผลแม้ไม่มีการอ่าน ตราบใดที่ยังไม่ผ่านเงื่อนไข AI ก็ไปต่อข้างหน้าไม่ได้ ดังนั้นไม่ว่า context window จะยาวแค่ไหน ผลก็ไม่เปลี่ยน

เอกสารของ Claude Code ก็ขีดเส้นเดียวกัน เรื่องไฟล์คำสั่งเขียนไว้ว่าไม่มีการรับประกันว่าจะทำตามอย่างเคร่งครัด แล้วเขียนต่อว่า ถ้าอยากให้รันที่จุดใดจุดหนึ่งให้ได้แน่ ๆ ก็เขียนลงใน hook

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

หลายตอนใช้ hook แต่ถ้าเป็น Claude Code ก็ตั้งค่าที่ hooks และถ้า tool ที่ใช้อยู่ไม่มี ก็สร้างขึ้นเองก็พอ สิ่งที่ต้องมีคือ "โครงสร้างที่ไปต่อไม่ได้ถ้ายังไม่ได้อ่าน" hook เป็นแค่หนึ่งในวิธีทำให้เกิดขึ้นจริงเท่านั้น

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

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

กลไกที่วางหลังจากล้มเหลวแล้วจะเข้าที่เข้าทางดี เพราะเพิ่งเห็นกับตาว่าทำไมถึงจำเป็น

ภาพรวมของซีรีส์

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

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

ตอนสุดท้าย จะสรุปว่าชิ้นส่วนทั้งหมดจนถึงตรงนี้ต่อกันอย่างไร จนหมุนไปได้โดยที่ผมไม่ต้องอ่าน

จะรัน test เมื่อไร กี่ตัว ด้วยวิธีไหน ซีรีส์นี้ไม่ได้พูดถึง

ตอนหน้าเริ่มจากเรื่องที่อยู่ใกล้มือที่สุด 26,147 บรรทัดที่ไหลออกมาตอน AI รัน test นั้น ผมไม่ได้อ่าน และยังไม่เคยมองข้ามอะไรไปเพราะแบบนั้นสักครั้ง

ซีรีส์ "เทคนิคการไม่อ่าน"