เลิกสั่ง AI แบบเดิมๆ: เปลี่ยนมาใช้ Problem Engineering เพื่อเขียนโค้ดให้ใช้งานได้จริง

ทำไม Prompt Engineering แบบเดิมๆ ถึงเริ่มใช้งานไม่ได้แล้ว?

ในฐานะมือใหม่ หลายคนอาจคุ้นเคยกับการใช้ AI ช่วยเขียนโค้ดด้วยการสั่งว่า "ช่วยเขียนโค้ดฟังก์ชันล็อกอินให้หน่อย" หรือ "เป็นผู้เชี่ยวชาญภาษา Python ช่วยแก้บั๊กนี้ที" เทคนิคเหล่านี้ที่เราเรียกว่า Prompt Engineering (การออกแบบคำสั่งเพื่อคุยกับ AI) เคยได้ผลดีในช่วงแรก แต่เมื่อเราเริ่มทำโปรเจกต์ที่ซับซ้อนขึ้น เราจะพบว่ามันเริ่ม "พัง" ในการใช้งานจริง

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

ความจริงที่โปรแกรมเมอร์ต้องรู้ในปี 2026 คือ AI เป็นเครื่องมือที่ฉลาดแต่ไม่มีความเข้าใจบริบทของธุรกิจคุณ หากคุณไม่ระบุขอบเขตให้ชัดเจน AI จะเลือกทางเลือกที่ง่ายที่สุดและเป็นมาตรฐานทั่วไป (Naive Implementation) ซึ่งมักจะไม่รองรับการใช้งานจริงที่มีคนใช้พร้อมกันเยอะๆ หรือสถานการณ์ที่ข้อมูลผิดพลาดครับ

เปลี่ยนจาก Prompt Engineering เป็น Problem Engineering

Problem Engineering (การวิศวกรรมปัญหา) คือการเปลี่ยนวิธีคิดจากการ "สั่งให้ AI ทำ" มาเป็นการ "วางโครงสร้างของปัญหาให้ชัดเจน" ก่อนส่งต่อให้ AI เหมือนกับการที่คุณเขียนพิมพ์เขียวบ้านก่อนให้ช่างก่อสร้าง ถ้าพิมพ์เขียวละเอียด ช่างก็ทำงานได้แม่นยำ ถ้าพิมพ์เขียวคลุมเครือ บ้านก็อาจจะพังลงมาได้ง่ายๆ ครับ

หัวใจสำคัญคือการจำกัดขอบเขตของคำตอบให้ AI ไม่ต้องเดาอีกต่อไป เราต้องกำหนด System Invariants (กฎที่ห้ามละเมิดเด็ดขาด) และ Data Contracts (ข้อตกลงเรื่องรูปแบบข้อมูล) ให้ครบถ้วน การทำแบบนี้จะเปลี่ยนจากงานที่ AI ต้องสุ่มคำตอบ มาเป็นการทำงานตามกรอบที่คุณขีดไว้ ซึ่งผลลัพธ์ที่ได้จะเป็นโค้ดที่พร้อมนำไปใช้ในระบบจริง (Production-ready)

ตัวอย่างความแตกต่างระหว่างการสั่งงานแบบเดิมกับแบบวิศวกรรมปัญหา:

• แบบเดิม: "เขียนฟังก์ชันตัดบัตรเครดิตให้หน่อย" (AI จะสุ่มวิธีเขียนที่อาจไม่มีระบบตรวจสอบความซ้ำซ้อน)
• แบบวิศวกรรมปัญหา: "เขียนฟังก์ชันตัดบัตรเครดิต โดยต้องมี Idempotency Key (กุญแจป้องกันการทำรายการซ้ำ) ตรวจสอบยอดเงินคงเหลือ และบันทึก Log ทุกขั้นตอนลงในฐานข้อมูล"

5 ชั้นความลับของการกำหนดปัญหาให้ AI ทำงานได้จริง

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

1. System Invariants: กฎเหล็กของธุรกิจ เช่น "ยอดเงินในบัญชีต้องไม่ติดลบ"
2. Data Contracts: กำหนดโครงสร้างข้อมูลให้ชัดเจน เช่น "ข้อมูลที่รับเข้ามาต้องเป็น JSON ที่มีฟิลด์ userId และ amount เท่านั้น"
3. State Mutations: ระบุการเปลี่ยนแปลงข้อมูลให้ชัด เช่น "เมื่อตัดเงินสำเร็จ ต้องอัปเดตสถานะในตาราง orders ทันที"
4. Fault Topologies: เตรียมรับมือความผิดพลาด เช่น "ถ้า API ธนาคารล่ม ให้ลองใหม่ 3 ครั้งและส่งข้อความแจ้งเตือน"
5. Observability Hooks: ฝังจุดตรวจสอบ เช่น "ใส่ Log ทุกครั้งที่ฟังก์ชันเริ่มทำงานและจบการทำงาน"

นี่คือตัวอย่างการสั่งงาน AI โดยใช้หลักการกำหนด Data Contract และ System Invariants ครับ:

// คำสั่ง: เขียนฟังก์ชันรับค่าเงินโอน
// 1. ตรวจสอบว่า amount ต้องมากกว่า 0 (System Invariant)
// 2. ข้อมูลขาเข้าต้องมี userId และ amount (Data Contract)
function processTransfer(data) {
  const { userId, amount } = data;

  // ตรวจสอบข้อมูลก่อนประมวลผล
  if (typeof amount !== 'number' || amount <= 0) {
    throw new Error("Invalid amount");
  }

  // ดำเนินการโอนเงิน...
  console.log(`Transferring ${amount} to ${userId}`);
}

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

สรุป: ฝึกเป็นสถาปนิกก่อนเป็นคนเขียนโค้ด

การเป็นโปรแกรมเมอร์เก่งๆ ไม่ใช่การพิมพ์คำสั่งให้ AI ได้เร็วที่สุด แต่คือการเป็นคนที่มีทักษะในการ ย่อยปัญหา (Problem Decomposition) ให้ละเอียดที่สุดครับ เมื่อคุณฝึกกำหนดปัญหาตาม 5 ชั้นที่เราคุยกันไป คุณจะพบว่าโค้ดที่ AI สร้างขึ้นมีความผิดพลาดน้อยลงอย่างเห็นได้ชัด และคุณเองก็จะเริ่มเข้าใจโครงสร้างของระบบซอฟต์แวร์มากขึ้นด้วย

ตัวอย่างการนำไปใช้จริง: ครั้งต่อไปที่คุณจะทำโปรเจกต์ เช่น "ระบบจัดการรายการสิ่งที่ต้องทำ (To-Do List)" อย่าเพิ่งบอกให้ AI เขียนโค้ดทั้งหมด ให้ลองเขียนรายการก่อนว่า: 1. ข้อมูลต้องเก็บในฐานข้อมูลอะไร 2. เมื่อกดลบรายการต้องตรวจสอบสิทธิ์ผู้ใช้ก่อนหรือไม่ 3. ถ้าเน็ตหลุดตอนกดบันทึก ระบบต้องทำอย่างไร การทำแบบนี้จะทำให้คุณกลายเป็นคนควบคุม AI แทนที่จะปล่อยให้ AI ขับเคลื่อนการพัฒนาของคุณครับ

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

ที่มา: Problem Engineering: Why Defining the Problem Matters More Than Your Prompt — DEV Community