เวลาทำงานกับ AI เรามักจะส่งไฟล์ทั้งก้อนให้ AI อ่าน ไม่ว่าจะเป็นล็อกไฟล์หลายพันบรรทัด โค้ดเบสขนาดใหญ่ หรือ documentation ยาว ๆ ยิ่ง context window ของ AI model ใหญ่ขึ้นเท่าไร เรายิ่งรู้สึกว่า "ส่งเข้าไปเลยก็ได้" แต่การทำแบบนั้นกิน token มหาศาลโดยไม่จำเป็น
บทความนี้จะมาลองพูดถึงเทคนิคที่กลับวิธีคิดกัน: แทนที่จะส่งไฟล์ทั้งก้อนให้ AI อ่าน ให้ AI เขียนโปรแกรมหรือสคริปต์ที่ดึงเฉพาะส่วนที่เกี่ยวข้องออกมาให้เราก่อน แล้วค่อยส่งเฉพาะส่วนนั้นกลับไปให้ AI ประมวลผลต่อ
แนวคิดนี้เลียนแบบวิธีที่มนุษย์เราทำเวลาอ่านโค้ดหรือล็อก เราไม่อ่านทุกบรรทัดตั้งแต่ต้นจนจบ แต่เราใช้ grep, awk, sed หรือ IDE features เพื่อค้นหาส่วนที่เกี่ยวข้องก่อน แล้วค่อยอ่านเฉพาะส่วนนั้น
AI ก็เหมือนกัน ถ้าเราส่งข้อมูลทั้งก้อนไป มันต้องเสียสมาธิไปกับข้อมูลที่ไม่เกี่ยวข้อง เสีย token ฟรี และได้คำตอบช้าลง
แนวทางเดิม: ส่งไฟล์ทั้งก้อน → AI อ่านทุกบรรทัด → ตอบ
→ ใช้ token เยอะ, เสียเวลากับข้อมูลไม่เกี่ยวข้อง
แนวทางที่ดีกว่า: ให้ AI เขียนสคริปต์ → ผู้ใช้รัน → ได้เฉพาะส่วนที่เกี่ยวข้อง → ส่งให้ AI วิเคราะห์ต่อ
→ ใช้ token น้อย, AI โฟกัสกับข้อมูลสำคัญ, ตอบเร็วขึ้น
สมมติว่าเรามีล็อกไฟล์ขนาด 50,000 บรรทัด อยากให้ AI ช่วยวิเคราะห์หาสาเหตุของ connection timeout
แนวทางเดิมคือส่งล็อก 50,000 บรรทัดไปให้ AI อ่านตรง ๆ
User: "ช่วยวิเคราะห์หาสาเหตุของ 'connection timeout' จากล็อกไฟล์นี้ให้หน่อย"
[แนบล็อก 50,000 บรรทัด]
→ ใช้ ~100,000 tokens, ค่าใช้จ่ายสูง, ตอบช้า
แนวทางที่ดีกว่าคือให้ AI เขียนสคริปต์ grep หา error ที่น่าสนใจก่อน
User: "ช่วยวิเคราะห์หาสาเหตุของ 'connection timeout' จากล็อกไฟล์นี้ให้หน่อย
แต่ก่อนอื่นช่วยเขียนสคริปต์ grep ดึงเฉพาะบรรทัดที่เกี่ยวข้องกับ error หรือ exception ก่อน"
AI: "ใช้คำสั่งนี้เพื่อดึงเฉพาะบรรทัดที่เกี่ยวข้อง"
grep -n -i "connection timeout\|error\|exception\|fail\|timeout" server.log | head -300
เมื่อรันสคริปต์แล้วจะเห็นว่าได้ผลลัพธ์ประมาณ 300 บรรทัด จากนั้นส่ง 300 บรรทัดนั้นให้ AI วิเคราะห์ต่อ ใช้ token แค่ ~3,000 tokens ประหยัดกว่า 30 เท่า
ถ้าล็อกมี timestamp เราอาจให้ AI เขียนสคริปต์ที่ซับซ้อนขึ้น เช่น ดึงเฉพาะช่วงเวลาที่เกิด error บ่อย
# ดึงเฉพาะบรรทัดระหว่าง 14:00-15:00 น. ที่มีคำว่า error
awk '/2026-08-12 14:/,/2026-08-12 15:/' server.log | grep -i "error" | head -200
อีกตัวอย่างคือการรีแฟกเตอร์โค้ด สมมติเราอยากให้ AI ช่วยรีแฟกเตอร์ฟังก์ชัน ProcessOrder ในไฟล์ order.go แต่ฟังก์ชันนี้ไปเรียกใช้บริการอื่น ๆ อีกหลายแห่ง
แนวทางเดิมคือส่งทั้งไฟล์ order.go (500 บรรทัด) พร้อมกับไฟล์ที่เกี่ยวข้องอีก 10 ไฟล์
User: "ช่วยรีแฟกเตอร์ฟังก์ชัน ProcessOrder ในไฟล์ order.go ให้หน่อย"
[แนบ order.go + services/*.go + models/*.go]
→ ใช้ ~5,000 tokens ต่อรอบ, หลายรอบ = หลายหมื่น tokens
แนวทางที่ดีกว่าคือให้ AI เขียนสคริปต์ดึงเฉพาะฟังก์ชันที่เกี่ยวข้อง
User: "ช่วยรีแฟกเตอร์ฟังก์ชัน ProcessOrder ในไฟล์ order.go ให้หน่อย
แต่ก่อนอื่นช่วยเขียนสคริปต์ดึงเฉพาะฟังก์ชัน ProcessOrder และ dependencies ที่มันเรียกใช้"
AI: "รันสคริปต์นี้เพื่อดูเฉพาะฟังก์ชัน ProcessOrder และ dependencies"
# ดึงเฉพาะฟังก์ชัน ProcessOrder
awk '/^func.*ProcessOrder/,/^}/' order.go
# หาว่า ProcessOrder ไปเรียกใช้ฟังก์ชันอะไรบ้าง
grep -oE '\b[A-Z][a-zA-Z]+\(' order.go | sort -u
# ดึงฟังก์ชัน dependencies
for fn in $(grep -oE '\b[A-Z][a-zA-Z]+\(' order.go | sort -u); do
grep -rn "^func.*$fn" ./services/ ./models/ 2>/dev/null
done
เมื่อรันสคริปต์แล้วจะพบว่าได้เฉพาะโค้ดที่เกี่ยวข้องประมาณ 80 บรรทัด ส่ง 80 บรรทัดนั้นให้ AI วิเคราะห์ต่อ ใช้ token แค่ ~800 tokens ประหยัดกว่า 6 เท่า
อีกสถานการณ์ที่เจอบ่อยคือการอ่าน documentation ยาว ๆ สมมติเรามีคู่มือ API ยาว 200 หน้า อยากรู้วิธีเรียกใช้ endpoint ใด endpoint หนึ่ง
แนวทางเดิมคือส่ง PDF หรือ Markdown ทั้งเล่มให้ AI อ่าน
User: "ช่วยดูวิธีเรียกใช้ /v3/checkout endpoint จากคู่มือนี้ให้หน่อย"
[แนบ documentation 200 หน้า]
→ ใช้ ~50,000 tokens, เสียเวลากับเนื้อหาที่ไม่เกี่ยวข้อง
แนวทางที่ดีกว่าคือให้ AI เขียนสคริปต์ดึงเฉพาะส่วนที่เกี่ยวข้อง
User: "ช่วยดูวิธีเรียกใช้ /v3/checkout endpoint จากคู่มือนี้ให้หน่อย
แต่ก่อนอื่นช่วยเขียนสคริปต์ดึงเฉพาะส่วนที่พูดถึง /v3/checkout หรือ checkout"
AI: "รันคำสั่งนี้เพื่อดึงเฉพาะส่วนที่เกี่ยวข้อง"
# ดึงเฉพาะบรรทัดที่มีคำว่า checkout
grep -n -i "checkout" api-docs.md | head -100
# หรือดึงทั้ง section ที่มีคำว่า checkout
awk '/^##.*[Cc]heckout/,/^## /' api-docs.md
เมื่อรันสคริปต์แล้วจะเห็นว่าได้เฉพาะส่วนที่เกี่ยวข้องประมาณ 50 บรรทัด ส่ง 50 บรรทัดนั้นให้ AI อ่านและอธิบาย ใช้ token แค่ ~500 tokens ประหยัดกว่า 100 เท่า
ข้อดีของแนวทางนี้คือประหยัด token อย่างมาก จากตัวอย่างจะเห็นว่าประหยัดได้ตั้งแต่ 6 เท่า ถึง 100 เท่า แถม AI ยังได้คำตอบที่แม่นยำขึ้นเพราะไม่ต้องเสียสมาธิไปกับข้อมูลที่ไม่เกี่ยวข้อง และตอบได้เร็วขึ้นเพราะส่ง token น้อย ยิ่งกับ model ที่คิดช้าเมื่อ context ยาว ยิ่งเห็นความแตกต่างชัดขึ้น
อีกข้อดีคือเราไม่จำเป็นต้องใช้ model ราคาแพงที่มี context window ใหญ่ แค่ model เล็ก ๆ ก็พอ แถมก่อนส่งให้ AI วิเคราะห์ เรายังได้เห็นข้อมูลที่ถูกดึงมาว่าครบถ้วนหรือไม่ ป้องกันการเข้าใจผิดกันไปก่อน
ข้อควรระวังคือถึงแม้สคริปต์ที่ AI เขียนจะช่วยได้มาก แต่ก็อาจไม่ครอบคลุมทุกกรณี หรืออาจพลาดข้อมูลสำคัญที่ซ่อนอยู่ในส่วนที่ถูกตัดทิ้งไป เช่น สาเหตุของ error อาจไม่ได้อยู่ที่บรรทัดที่มีคำว่า "error" แต่อยู่ที่ค่าตัวแปรผิดปกติที่เกิดขึ้นก่อนหน้านั้นหลายร้อยบรรทัด ดังนั้นลองตรวจสอบผลลัพธ์ของสคริปต์คร่าว ๆ ก่อนส่งให้ AI วิเคราะห์ต่อ และถ้าผลลัพธ์ที่ได้ดูไม่ครอบคลุม ก็ขอให้ AI ปรับปรุงสคริปต์ให้ดีขึ้นก่อนได้
จะเห็นว่าการให้ AI เขียนโปรแกรมดึง context แทนการส่งไฟล์ทั้งก้อนเป็นเทคนิคที่ช่วยประหยัด token ได้อย่างมาก พร้อมกับได้คำตอบที่แม่นยำและเร็วขึ้น แนวคิดคือเลียนแบบวิธีที่มนุษย์เราทำงานนั่นแหละ — ใช้เครื่องมือค้นหาส่วนที่เกี่ยวข้องก่อน แล้วค่อยอ่านเฉพาะส่วนนั้น
เทคนิคนี้ใช้ได้กับหลากหลายสถานการณ์ ตั้งแต่การวิเคราะห์ล็อก การรีแฟกเตอร์โค้ด ไปจนถึงการอ่าน documentation ยาว ๆ และที่สำคัญคือใช้ได้กับ AI ทุกรุ่น ไม่จำเป็นต้องพึ่ง model ราคาแพงที่มี context window ใหญ่