โดย Thanedpol Dechaduangsakul | เผยแพร่: 20 สิงหาคม 2569 | อ้างอิง: จากงาน BDI Seminar 2026

สรุปสาระสำคัญ

• สั่ง AI ด้วยประโยคเดียว ได้ระบบเต็มใน 5 นาที แต่มี 2 จุดที่ใช้งานจริงไม่ได้ทันที

• ใส่สเปกครบ 4 ส่วนตามกรอบ VIBE ผลลัพธ์ตรงความต้องการขึ้นทันที (User Type 3 บทบาท, SLA เว้นเสาร์-อาทิตย์)

• เขียน Test Case ก่อนให้ AI สร้างโค้ด คือ ขั้นตอนที่ทำให้ AI โกหกไม่ได้ว่างานเสร็จแล้ว

• แนะนำใช้ AI 2 ยี่ห้อแยกตัวสร้างกับตัวตรวจ เพราะ AI มักให้งานตัวเองผ่าน

สรุป Session: เสวนา Vibe Coding: กระแส ความจริง และความพร้อมขององค์กรจากงาน BDI Seminar 2026 โดยคุณพชร วงศ์สุทธิโกศล, วิศวกรปัญญาประดิษฐ์อาวุโส BDI

AI ไม่เถียงเรา นั่นคือ ทั้งข้อดีและกับดัก

วันนี้ AI เก่งขึ้นจากเมื่อ 3 ปีก่อนมาก จนต่างจากการสั่งงาน Developer อีกคนหนึ่งอย่างสิ้นเชิง — คนสั่งไม่ชัดเจน อีกฝ่ายจะยิงคำถามกลับมาแน่นอนว่าหมายถึงอย่างไร แต่ AI ไม่ทำแบบนั้น

“AI มันไม่เถียงเราครับ เราสั่งอะไรไปมันก็ทำ ปัญหาคือ AI ไม่รู้ว่าเราคิดอะไรอยู่ในหัวบ้าง รายละเอียดเราต้องการอย่างไร SLA เราหมายถึงอะไร”

— คุณพชร วงศ์สุทธิโกศล

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

Prompt ที่โยนเข้าไป คือ "สร้างระบบติดตามร้องเรียน มีสถานะ มีจังหวัด มี SLA" จะสาธิตให้เห็น 3 รอบ:

1. รอบแรก คือ ประโยคเดียวนี้

2. รอบที่ 2 จะใส่สเปกเต็ม 1 หน้า

3. รอบที่ 3 จะเริ่มใช้ Coding Agent พร้อมชุดทดสอบ

เพื่อให้เห็นว่า Spec-Driven, การทำ Test และ Loop Engineering ที่พูดถึงในวงเสวนาก่อนหน้า จริง ๆ แล้วทำอย่างไร

5 นาที ได้ระบบเต็ม แต่ซ่อนปัญหาไว้ 2 จุด

ใช้เวลาไปประมาณ 5 นาที (ด้วย Google AI Studio) ก็ได้หน้าจอ Dashboard ติดตามสถานะเรื่องร้องเรียนออกมาเต็มรูปแบบ ดูเผิน ๆ เหมือนใช้งานได้จริง

สิ่งที่ AI เติมมาให้เอง

• Mock Data ครบ ตั้งแต่สถานะเกินกำหนด ไปจนถึงเหลืออีก 4 ชั่วโมง พร้อมการ์ดสรุปว่าเกิน SLA ไปเท่าไหร่

• ปุ่มให้ผู้ใช้กำหนดเกณฑ์ SLA เอง — เพราะ AI ไม่รู้ว่า SLA จริงของหน่วยงานคือเท่าไหร่ จึงเติมช่องให้เรากรอกเองแทน

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

ทำเกินขอบเขต หรือ ไม่ตรงกับที่คิด

2 ปัญหาจากคำสั่งที่ไม่ชัดเจน

กรอบ 4 ข้อ ก่อนเริ่มสร้างอะไรก็ตาม

งานที่ Software Engineer ทำจริง ๆ แบ่งออกมาคร่าว ๆ ได้ 4 อย่าง — และการทำงานกับ AI ยิ่งต้องระวังมากกว่าทำงานกับคน เพราะคนปกติไม่ขยันเกินขอบเขตขนาดนั้น แต่ AI ขยันมาก ไม่สั่งอะไรมันก็มาเต็มไปหมด

1. เก็บข้อมูลให้ครบ: ถามตัวเอง ถามลูกค้า หรือถามในทีมก่อนเริ่ม ว่าจะสร้างอะไรกันแน่

2. กำหนดขอบเขต (Scope): จุดเริ่มต้นไม่ควรทำครอบคลุมทุกอย่าง ต้องมีเฟสแรกที่ขอบเขตชัดเจน

3. ทำงานกับ AI อย่างระมัดระวัง: สำคัญกว่าทำงานกับคน เพราะ AI ไม่ทัดทาน สั่งอะไรก็ทำอันนั้นแบบไม่จำกัด

4. นิยามคำว่า เสร็จ: ปรับความเข้าใจให้ตรงกับ AI ว่าปิดงาน ส่งได้ คืออะไร ให้ AI เช็กตัวเองได้

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

อย่าเพิ่งสร้าง ให้ถามก่อน

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

“บอกมันว่าอย่าเพิ่งสร้าง ให้ถาม”

— หลักคิดก่อนเริ่ม Vibe Code ทุกครั้ง

5 คำถามนี้ปรับเปลี่ยนได้ตามงาน — สกิล “Grill Me” ที่พูดถึงในวงเสวนา Session ก่อนหน้าจะถามลึกถึง 20 กว่าข้อ แต่วันนี้ย่อเหลือ 5 ข้อเพื่อให้จบไว ๆ ในการสาธิต และเลือกใช้ ChatGPT เป็นตัวสัมภาษณ์ ไม่ใช่ Google AI Studio เพราะ AI Studio มี Instruction ของตัวเองฝังอยู่แล้ว ทำให้ทำงานอย่างอื่นได้ไม่ค่อยยืดหยุ่น

ตัวอย่างจริงจากการสัมภาษณ์

AI ถาม: เรื่องร้องเรียนที่เข้ามา มาจากช่องทางไหนบ้าง

พชร ตอบ: เจ้าหน้าที่กรอกเอง (คำตอบข้ออื่น ๆ เตรียมไว้ล่วงหน้าแล้วเช่นกัน)

อีก 4 คำถามที่เหลือดำเนินไปในลักษณะเดียวกัน เพื่อดึงรายละเอียดที่ยังคลุมเครือออกมาให้ครบก่อนเริ่มสร้างจริง

ผลลัพธ์: เอกสารสรุป 1 หน้า

หลังตอบครบ 5 ข้อ พรอมต์จะสั่งให้ AI สรุปเป็นเอกสาร 1 หน้า ว่า จะสร้างอะไร ห้ามทำอะไร และ แบบไหนเรียกว่าเสร็จ

ขั้นตอนนี้ข้ามได้เช่นกัน ถ้าทีมปรึกษากันเองจนได้สเปกที่ชัดเจนแล้ว ก็เขียนสเปกตรงได้เลยโดยไม่ต้องให้ AI สัมภาษณ์

V-I-B-E: 4 ส่วนที่สเปกดี ๆ ต้องมี

เอกสาร 1 หน้าที่ให้ AI เจนมา สรุปสั้น ๆ ได้ 4 หัวข้อ ไม่จำเป็นต้องได้คำว่า VIBE เป๊ะ ๆ แต่ตั้งใจให้จำง่ายด้วยคำนี้

1. Value (ใครและคุณค่า): ใครเป็นคนเดือดร้อน เราสร้างมาตอบใคร และสิ่งที่สร้างมีคุณค่าอะไรกับเขา

2. Interaction (ลอจิก): Input คืออะไร ทำอะไรกับ Input นั้น แล้ว Output คืออะไร

3. Boundary (ขอบเขต): จะไม่ทำเกินไปกว่านี้ ไม่มีอะไรที่อยู่นอกขอบเขตที่กำหนด

4. Evidence (เกณฑ์): แบบไหนเรียกว่าเสร็จ เกณฑ์ที่บอกให้ AI รู้ว่าจุดจบอยู่ตรงไหน

ฝั่ง Developer เรียกเอกสารลักษณะนี้ว่า PRD (Product Requirement Document) ซึ่งปกติจะยาวกว่านี้มาก เพราะมีสเปก Tech Stack และรายละเอียดเชิงลึกกว่านี้อีกมาก แต่สำหรับคนที่เพิ่งเริ่ม Vibe Code ที่ยังไม่รู้เรื่อง Tech ลึกขนาดนั้น แค่ 4 ข้อของ VIBE ก็เพียงพอ และเป็นสิ่งที่สำคัญที่สุดแล้ว

ก่อนสั่งให้สร้างจริง ต้องอ่านเอกสารที่ AI เจนมาก่อนเสมอ ดูว่า Make Sense หรือเปล่า ถ้าข้อไหนขัดกันให้ถามก่อน ห้ามเดา จากนั้นจึงส่ง Prompt ต่อ พอสร้างใหม่

ผลลัพธ์ที่เปลี่ยนไป

• มี User Type ชัดเจน 3 บทบาท: เจ้าหน้าที่รับเรื่อง, หัวหน้ากลุ่มงาน, ผู้บริหาร

• เปลี่ยนเป็นผู้บริหารแล้ว ระบบแสดงข้อมูลของทุกจังหวัดตามที่ควรจะเป็น

• SLA ไม่นับวันเสาร์-อาทิตย์แล้ว ตามที่ระบุไว้ในสเปก

ทั้งที่ใส่สเปกละเอียดมากแล้ว แต่ทุกคนยังไม่เชื่อมั่น เพราะ Flow ที่ถูกต้องเราข้ามขั้นตอนหนึ่งไป ทบทวนดูจะพบว่ามาถึงขั้นสร้างระบบแล้ว แต่ขาดขั้นตอนก่อนหน้าไป: เขียน Test Case ก่อนที่จะไปสร้าง ไม่ใช่สร้างเสร็จแล้วค่อยเทสต์ทีหลัง

สมมติว่ามีโค้ดอยู่แล้วจากรอบที่ 2 — บอกให้ AI อ่านเอกสารสเปก สำรวจโค้ดจริง รายงานจุดที่ไม่ตรงกัน แล้วเขียน Test Case จาก Definition of Done โดยตรง คราวนี้ย้ายมาใช้ Cursor แทน เพราะเหมาะกับงาน Coding มากกว่า

6 สิ่งที่ AI สำรวจเจอในโค้ด

1. ใช้ Gemini: เลือกใช้ Gemini เป็น Backend AI เอง — ไม่ผิดอะไร แค่เป็นสิ่งที่ต้องรับรู้

2. Free Text: มีช่องค้นหาแบบพิมพ์คำค้นอิสระ

3. Sort วัน: เรียงลำดับข้อมูลตามวันที่ได้

4. Dashboard: มีหน้าภาพรวมสำหรับติดตามสถานะ

5. สลับ User: สลับมุมมองไปตามบทบาทผู้ใช้ได้

6. ปุ่ม Reset Demo: มีปุ่มนี้จริง แม้ก่อนหน้าจะไม่เคยสังเกตเห็น เข้าไปเช็กแล้วพบว่ามีอยู่จริง

คนที่อ่านโค้ดไม่ออก จะตอบไม่ได้ว่า Test Case นี้ทดสอบอะไรจริงหรือเปล่า — ตั้งแต่ขั้นตอนนี้เป็นต้นไป จึงเริ่มต้องมีทักษะอ่านโค้ดอย่างน้อยระดับหนึ่ง

4 ขั้นตอนของกระบวนการวันนี้

Non-Dev ทำได้เอง

• เขียนสเปกจากบทสนทนา (คุยกันเอง หรือให้ AI สัมภาษณ์)

• สั่ง AI ให้ Vibe / สร้างโค้ดจากสเปกนั้น

ต้องมีทักษะโค้ด

• เขียน Test Case จาก Definition of Done

• รัน Test เพื่อยืนยันผลจริง

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

2 วิธีตรวจ ที่ให้ผลต่างกัน

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

เขียน Test ก่อนมีโค้ด → Red (ไม่ผ่าน) → สร้างโค้ด แล้วรันเทสต์ → Green (ผ่าน) → ไม่ Green ก็ Refactor → วนซ้ำจนผ่าน

ฝั่ง Developer เรียกเทคนิคนี้ว่า Red-Green-Refactor — สร้างเทสต์ตอนที่ยังไม่มีโค้ด เทสต์นั้นควรไม่ผ่านก่อน (Red) พอสร้างโค้ดแล้วรัน ถ้าผ่านคือ Green ถ้ายังไม่ Green ก็ต้อง Refactor แก้โค้ดวนไปเรื่อย ๆ จนกว่าจะผ่าน นี่คือรูปธรรมของ Loop Engineering ที่พูดถึงกันในวงเสวนาก่อนหน้า

ทำไมไม่ Vibe ไปเรื่อย ๆ จนกว่าจะถูก

เจอผิดตรงไหนก็สั่งแก้ไปเรื่อย ๆ สุดท้ายผลลัพธ์อาจถูกทั้งหมดจริง แต่ Token มีราคา — ยิ่งสั่งแก้ไปเรื่อย ๆ ก็ยิ่งเบิร์นเงินตัวเองไปเรื่อย ๆ การได้สเปกมาทีเดียวแล้วสั่งครั้งเดียว Loop ไม่กี่ครั้งจนกว่าจะผ่าน ประหยัดกว่ามากนัก

4 ต้นทุนของการขึ้น Production

1. AI Usage: ส่วนที่วันนี้ช่วยประหยัดได้ ด้วยแนวทาง Spec-Driven + Loop Engineering

2. Infra: ต้นทุนโครงสร้างพื้นฐานที่ต้องมี ไม่ได้พูดถึงรายละเอียดในวันนี้

3. Maintenance: ต้นทุนดูแลรักษาระบบต่อเนื่อง ไม่ได้พูดถึงรายละเอียดในวันนี้

4. Security: ต้นทุนด้านความปลอดภัย ไม่ได้พูดถึงรายละเอียดในวันนี้

คำถามที่พบบ่อย (FAQ)

Q1: Vibe Coding คืออะไร

A1: การสั่งให้ AI เขียนโค้ดด้วยภาษาพูดทั่วไป แทนการเขียนโค้ดเอง

Q2: AI Engineer ต่างจาก Software Engineer ทั่วไปยังไง

A2: ตามนิยามของคุณพชร คือ Software Engineer ที่เอา AI มาอยู่ในระบบ ต่างกันแค่จุดนี้จุดเดียว

Q3: VIBE Framework คืออะไร

A3: สเปก 4 ส่วนสำหรับมือใหม่ ได้แก่ Value, Interaction, Boundary, Evidence ใช้แทนเอกสาร PRD ฉบับเต็มได้ในโปรเจกต์เริ่มต้น

Q4: Red-Green-Refactor คืออะไร

A4: เทคนิคเขียนเทสต์ก่อนมีโค้ด (Red) สร้างโค้ดแล้วรันเทสต์ (Green ถ้าผ่าน) ไม่ผ่านก็แก้วนไปเรื่อยๆ (Refactor) จนกว่าจะผ่าน

Q5: ทำไมควรใช้ AI มากกว่า 1 ยี่ห้อในการเขียนโค้ด

A5: เพราะ AI มีความลำเอียงเล็กน้อยต่องานของตัวเอง ตัวหนึ่งควรสร้าง อีกตัวควรตรวจ เพื่อลดโอกาสที่งานผ่านทั้งที่ยังไม่ถูกต้อง

ข้อสรุป:

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