AI สร้างหน้าจออนุมัติใบสั่งซื้อเสร็จแล้ว ปุ่มกดได้ ผู้จัดการอนุมัติได้ สถานะเปลี่ยนจากรออนุมัติเป็นอนุมัติแล้ว ก่อนให้ฝ่ายจัดซื้อเริ่มใช้ ผมอยากถามเรื่องที่ดูไม่น่าตื่นเต้นเท่าเดโมก่อนว่า ถ้ามีคนแก้ยอดหลังอนุมัติ ระบบจะทำอย่างไร?
คำถามนี้ช่วยให้เห็นว่าเดโมยังขาดอะไร ก่อนจะให้คนอื่นใช้ทำงานจริง หน้าจออาจดูเสร็จทั้งที่ยังไม่มีคำตอบเรื่องสำคัญ ใครมีสิทธิ์อนุมัติ ใช้ยอดใดเลือกสายอนุมัติ และถ้าส่งคำขอซ้ำจะเกิดอะไรขึ้น เดโมที่ยังตอบไม่ได้ก็ช่วยให้เราเรียนรู้ได้ หากจำกัดขอบเขตของมันชัดเจน
บทความชุดนี้ใช้ โครงการสมมติเรื่องการอนุมัติใบสั่งซื้อ เป็นตัวอย่างต่อเนื่อง เป็นตัวอย่างที่เขียนขึ้นเพื่ออธิบายแนวคิด ไม่ใช่งานลูกค้าหรือระบบที่ผมติดตั้งแล้ว เราจะค่อย ๆ เดินจากต้นแบบไปสู่การทดลองใช้ในขอบเขตจำกัด โดยดูเรื่องข้อมูล สิทธิ์ การตรวจสอบ การแบ่งงาน การดูแล และต้นทุน
ให้เดโมทำหน้าที่ที่มันทำได้จริง
สมมติว่าทีมจัดซื้ออยากรู้ว่าผู้อนุมัติเข้าใจหน้าจอใหม่หรือไม่ เราใช้ใบสั่งซื้อที่แต่งขึ้น ผู้ใช้จำลอง และปุ่มที่เปลี่ยนเพียงข้อมูลทดสอบได้ สิ่งที่ต้องการคือข้อสังเกต เช่น ขาดช่องข้อมูล สถานะอ่านแล้วสับสน หรือทีมลืมขั้นตอนหนึ่งไป การเรียนรู้เรื่องเหล่านี้ยังไม่ต้องเชื่อมระบบจัดซื้อจริง
ความเสี่ยงเปลี่ยนไปเมื่อปุ่มเดิมเริ่มแก้ใบสั่งซื้อจริงหรือส่งรายการต่อ ความผิดพลาดของหน้าจออาจกลายเป็นการกระทำทางธุรกิจ แม้หน้าจอที่อ่านอย่างเดียวก็อาจเผยข้อมูลให้คนที่ไม่มีสิทธิ์เห็น ขอบเขตจึงขึ้นอยู่กับสิ่งที่ระบบส่งผลกระทบได้ ไม่ได้ขึ้นอยู่กับชื่อที่เราเรียกว่าต้นแบบ
แนวคิดประกอบจาก The New SDLC With Vibe Coding, Addy Osmani, Shubham Saboo และ Sokratis Kartakis (พฤษภาคม 2569). บทความของผู้เขียน · เอกสารฉบับเต็ม
ผมจะเขียนข้อจำกัดของการทดลองตรง ๆ ว่า “รุ่นนี้ใช้ข้อมูลสมมติ บันทึกการอนุมัติจำลอง และส่งใบสั่งซื้อออกไปไม่ได้” ข้อความนี้ควรอยู่ในพื้นที่ทดสอบและเอกสารส่งต่องาน แต่ป้ายเตือนอย่างเดียวไม่พอ สภาพแวดล้อมนั้นควรไม่มีการเชื่อมต่อและข้อมูลรับรองสิทธิ์ที่ใช้ส่งใบสั่งซื้อจริงด้วย
Vibe coding บอกวิธีทำงาน ไม่ใช่ตรารับรองเครื่องมือ
คนใช้คำว่า vibe coding ในหลายความหมาย ในบทความนี้หมายถึงการทดลองด้วยการบอก AI ว่าต้องการอะไร รับการแก้ไขอย่างรวดเร็ว และส่งข้อผิดพลาดกลับไปให้ลองใหม่ โดยตรวจงานเบื้องหลังไม่มาก วิธีนี้อาจช่วยได้เมื่อเป็นงานที่ทดลองแล้วลบทิ้งได้และจำกัดผลกระทบไว้แล้ว
ภาพต้นฉบับเปรียบเทียบวิธีทำงานตั้งแต่ทดลองเร็วไปจนถึงการตรวจงานอย่างมีแบบแผน จุดต่างคือวิธีตรวจผล ไม่ใช่ชื่อเครื่องมือ ความเข้มของการตรวจยังต้องเลือกตามผลกระทบของงาน ลูกศรเรื่องโครงสร้าง ความเร็ว และความน่าเชื่อถือเป็นกรอบแนวคิด ไม่ใช่ผลวัดหรือคำรับรองว่าจะเร็วและเชื่อถือได้เสมอ
ภาพต้นฉบับจาก The New SDLC With Vibe Coding, Addy Osmani, Shubham Saboo และ Sokratis Kartakis (พฤษภาคม 2569) ออกแบบเอกสารโดย Michael Lanning เผยแพร่ภาพให้ใช้ซ้ำโดย Addy Osmani ที่มาและสิทธิ์ใช้ภาพ · เอกสารฉบับเต็ม
Agentic engineering เพิ่มระบบที่ตั้งใจออกแบบไว้รอบการทำงาน คนกำหนดผลที่ต้องการและขอบเขต AI ใช้เครื่องมือแก้งาน แล้วใช้หลักฐาน การตรวจ และการทบทวนตัดสินว่างานไปต่อได้หรือยัง ความรับผิดชอบเหล่านี้ยังอยู่ แม้ไม่ต้องพิมพ์โค้ดเอง
เอกสาร The New SDLC With Vibe Coding อธิบายวิธีเหล่านี้เป็นช่วงต่อเนื่อง แนวคิดนี้มีประโยชน์เพราะเครื่องมือเขียนโค้ดตัวเดียวกันอาจใช้ทดลองเร็ว ๆ หรือใช้แก้งานที่มีกติกาชัดเจนก็ได้ ต่อให้ใช้โมเดลที่เก่งขึ้น เราก็ยังต้องตัดสินใจว่าใครเป็นเจ้าของกติกาอนุมัติ จะบังคับสิทธิ์อย่างไร และหลักฐานแบบใดจึงเพียงพอ
ผมเลือกความเข้มของวิธีทำงานจากผลเสียหากผิด การลองจัดหน้าจอที่ทิ้งได้กับการอนุมัติรายการจริงควรมีวิธีตรวจต่างกัน การเพิ่มขั้นตอนไม่ใช่เป้าหมายในตัวเอง การตรวจแต่ละอย่างควรอธิบายได้ว่าช่วยจับความผิดพลาดอะไร
เขียนกติกาก่อนให้ AI ลงมือ
ในตัวอย่างนี้ สมมติว่าใบสั่งซื้อยอดไม่เกิน 50,000 บาทให้ผู้จัดการฝ่ายอนุมัติได้ ส่วนยอดเกิน 50,000 บาทต้องให้ผู้อำนวยการฝ่ายจัดซื้ออนุมัติ จำนวนเงินและบทบาทนี้เป็นเรื่องสมมติ ก่อนสร้างโค้ดเรายังต้องตกลงว่าใช้ยอดก่อนหรือหลังภาษี ก่อนหรือหลังส่วนลด และใช้สกุลเงินใด
เราจะเลือกยอดสุทธิเป็นบาทหลังส่วนลดและภาษี ภายใต้กติกาสมมตินี้ ยอด 50,000 บาทพอดีเข้าสายผู้จัดการ ส่วน 50,000.01 บาทเข้าสายผู้อำนวยการ ถ้ายอดเปลี่ยนหลังอนุมัติ การอนุมัติเดิมหมดผลและต้องกลับไปตรวจใหม่ ทั้งหมดนี้คือการตัดสินใจทางธุรกิจ ไม่ใช่รายละเอียดที่ควรปล่อยให้ AI เดาเงียบ ๆ
ตรงขอบเขตที่รวมไว้
50,000 บาท
ผู้จัดการฝ่ายอนุมัติ
สูงกว่าขอบเขต
50,000.01 บาท
ผู้อำนวยการฝ่ายจัดซื้ออนุมัติ
| คำถาม | หลักฐานก่อนทดลองใช้ |
|---|---|
| เข้าสายอนุมัติถูกหรือไม่ | กติกาที่ผู้รับผิดชอบตรวจแล้ว และผลทดสอบรอบขอบเขต 50,000 บาท |
| คนที่ไม่มีสิทธิ์อนุมัติได้หรือไม่ | การตรวจสิทธิ์ฝั่งเซิร์ฟเวอร์และผลปฏิเสธคำขอที่ไม่มีสิทธิ์ |
| รายการเดิมถูกอนุมัติซ้ำได้หรือไม่ | วิธีตอบคำขอซ้ำที่ตกลงไว้และทดสอบกับสถานะที่บันทึกจริง |
| แก้ข้อมูลหลังอนุมัติแล้วเกิดอะไรขึ้น | การเปลี่ยนสถานะที่ยกเลิกผลอนุมัติเมื่อข้อมูลที่เกี่ยวข้องเปลี่ยน |
| ใครรับเรื่องเมื่อระบบผิดพลาด | เจ้าของการทดลองและวิธีหยุดใช้ขั้นตอนใหม่ที่ซ้อมแล้ว |
ส่งต่องานด้วยหลักฐาน
เมื่อ AI บอกว่า “เสร็จแล้ว” เราได้รายงานที่ต้องตรวจต่อ ขอไฟล์ที่เปลี่ยน กติกาที่นำไปใช้ รายการตรวจที่รัน ผลตรวจ และเรื่องที่ยังตอบไม่ได้ ผู้ตรวจควรเชื่อมความต้องการทางธุรกิจกับงานที่สร้างได้ โดยไม่ต้องย้อนอ่านบทสนทนายาวทั้งหมด
สำหรับโครงการนี้ ผมจะจำกัดการทดลองกับงานจริงไว้ก่อน เช่น กลุ่มผู้ใช้และใบสั่งซื้อที่ตกลงกัน มีคนรับผิดชอบตรวจ และมีวิธีกลับไปใช้กระบวนการเดิม ขอบเขตที่เหมาะสมขึ้นอยู่กับองค์กร การทดลองเล็กลงช่วยจำกัดความไม่แน่นอน แต่ยังต้องปกป้องข้อมูลและบังคับสิทธิ์
ต้องนิยามการหยุดทดลองด้วย การปิดหน้าจอใหม่อาจหยุดรายการถัดไป แต่ไม่ได้ย้อนใบสั่งซื้อที่ส่งไปแล้ว การแก้ผลกระทบอาจต้องค้นรายการที่เกี่ยวข้องและให้เจ้าของงานผู้มีอำนาจตัดสินใจว่าจะแก้อะไร การย้อนรุ่นโค้ดจึงเป็นคำตอบเพียงส่วนหนึ่ง
ก่อนให้เดโมนี้ไปต่อ ผมต้องการกติกาที่ตกลงแล้ว หลักฐานของกรณีเสี่ยง ข้อจำกัดสิทธิ์ที่บังคับได้ และเจ้าของงานที่สั่งหยุดการทดลองได้ สิ่งที่ขาดควรกลายเป็นประเด็นเปิดที่เห็นชัด แทนการซ่อนอยู่ในข้อสมมติของโค้ด
ลองเลือกหน้าจอหนึ่งหน้าที่ทีมมีอยู่ แล้วระบุว่าการกระทำแรกที่กระทบข้อมูลจริงคืออะไร ใครมีอำนาจอนุญาต และต้องมีหลักฐานใดก่อนเปิดให้ทำ บทความถัดไปจะนำคำตอบนี้ไปจัดข้อมูลที่ควรให้ AI ก่อนเริ่มงาน
ที่มาและขอบเขต
บทความนี้นำแนวคิดจาก The New SDLC With Vibe Coding ของ Addy Osmani, Shubham Saboo และ Sokratis Kartakis ฉบับเดือนพฤษภาคม 2569 มาอธิบายใหม่ด้วยตัวอย่างธุรกิจที่แต่งขึ้น อ่านเรื่องการพัฒนาด้วย AI อย่างมีแบบแผนเพิ่มเติมได้จาก บทความ Agentic Engineering ของ Osmani ข้อเสนอการตรวจในที่นี้เป็นจุดเริ่มต้นสำหรับหารือ ไม่ใช่หลักฐานว่าระบบใดปลอดภัย ผ่านข้อกำหนด หรือพร้อมใช้ในทุกสภาพแวดล้อม
