ก่อนให้ AI เริ่มงาน ต้องให้รู้อะไรบ้าง

“ช่วยแก้ขั้นตอนอนุมัติให้หน่อย” ฟังดูชัดเจน จน AI ต้องเลือกระหว่างเอกสารสองฉบับ ฉบับหนึ่งระบุว่าผู้จัดการอนุมัติยอดไม่เกิน 50,000 บาทได้ แต่อีกตัวอย่างที่เก่ากว่าใช้วงเงินต่างกัน ควรเชื่อฉบับไหน และจะรู้ได้อย่างไรว่าไฟล์ตัวอย่างไม่ใช่นโยบาย?

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

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

เริ่มจากเจ้าของกติกา

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

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

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

แยกกติกาประจำออกจากชุดข้อมูลเฉพาะงาน

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

ภาพต้นฉบับภาษาอังกฤษ — กดพับหรือเปิดภาพ

เปิดภาพต้นฉบับขนาดเต็ม (ภาษาอังกฤษ)

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

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

เรียกข้อมูลตามงาน แล้วตรวจว่าได้อะไรมา

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

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

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

ทิ้งบันทึกที่งานรอบถัดไปใช้ต่อได้

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

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

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

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

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

ที่มาและขอบเขต

การแบ่งประเภทข้อมูลและแยกกติกาประจำออกจากข้อมูลที่เรียกตามงานต่อยอดจาก The New SDLC With Vibe Coding ของ Addy Osmani, Shubham Saboo และ Sokratis Kartakis ฉบับเดือนพฤษภาคม 2569 ส่วน Effective context engineering for AI agents ของ Anthropic อธิบายการเลือกข้อมูลที่เกี่ยวข้องและเรียกใช้ตามความจำเป็นจากมุมเทคนิค ชุดข้อมูล นโยบาย P1 จำนวนเงิน และการแบ่งเจ้าของงานในบทความนี้เป็นตัวอย่างสมมติ ไม่ใช่ผลวัดการประหยัดต้นทุนหรือข้อกำหนดให้ใช้เครื่องมือใด