คู่มือเริ่มต้น Vibe Coding สำหรับคนที่ไม่ใช่นักพัฒนาใน 5 ขั้นตอน

 (stdy.blog)
26 คะแนน โดย spilist2 2025-04-23 | 7 ความคิดเห็น | แชร์ทาง WhatsApp

ในช่วงหลายสัปดาห์ที่ผ่านมา ผู้เขียนได้ลองทำแอปง่ายๆ ราว 5–6 ตัวด้วย Vibe Coding ร่วมกับคนรู้จักที่ไม่ใช่นักพัฒนา (เช่น ทนาย นักการตลาด PM เป็นต้น)

จากกระบวนการนี้ ผู้เขียนจึงสรุปออกมาเป็น 'คู่มือเริ่มต้น Vibe Coding สำหรับคนที่ไม่ใช่นักพัฒนา' 5 ขั้นตอน

  1. ทำความเข้าใจคร่าวๆ ว่า AI สมัยนี้ทำอะไรได้ไกลแค่ไหน
  2. นิยามให้ชัดว่าปัญหาที่อยากแก้หรือผลิตภัณฑ์ที่อยากสร้างคืออะไร
  3. ตรวจดูการทำงานของผลลัพธ์ด้วยตาตัวเองให้เร็วและบ่อย
  4. โต้ตอบกับ AI ด้วยการพรอมป์ตอย่างเหมาะสมเพื่อให้เขียนโค้ดได้ดี
  5. สังเกตพฤติกรรมผิดปกติและจุดที่ควรปรับปรุง แล้วแก้ไขจนปิดงานได้

1) ทำความเข้าใจคร่าวๆ ว่า AI สมัยนี้ทำอะไรได้ไกลแค่ไหน

สำหรับคนที่ไม่ใช่นักพัฒนาซึ่งเพิ่งเริ่มรู้จัก Vibe Coding ผู้เขียนแนะนำให้เริ่มจากกิจกรรมประมาณนี้

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

2) นิยามให้ชัดว่าปัญหาที่อยากแก้หรือผลิตภัณฑ์ที่อยากสร้างคืออะไร

  • แม้จะพอเข้าใจความสามารถของ AI แล้ว แต่ถ้ายังนิยามปัญหาไม่ชัด ก็สร้างผลิตภัณฑ์ไม่ได้
  • เพราะงั้นก่อนอื่นเราต้องทำให้ตัวเองคิดชัดขึ้น ผ่านคำถามที่ช่วยยกระดับการตระหนักรู้ของตัวเอง
  • ใช้งาน แอป metacognition ที่สร้างด้วย Vibe Coding
    1. อยากสร้างอะไร?
    2. ทำไมถึงอยากสร้างสิ่งนั้น? กำลังพยายามแก้ปัญหาอะไร?
    3. ปัญหานั้นเป็นของใคร?
    4. คนเหล่านั้นเจอปัญหานี้ในสถานการณ์แบบไหน?
    5. ตอนนี้ในสถานการณ์นั้น พวกเขาใช้อะไรเป็นทางแก้ชั่วคราวหรือสิ่งทดแทนอยู่?
    6. จะยืนยันได้อย่างไรว่า 1 แก้ปัญหาได้ดีกว่า 5?
    7. จะทำอย่างไรให้คนเหล่านั้นยอมใช้ 1 แทน 5 อย่างเต็มใจ?
  • เมื่อจัดระเบียบสิ่งที่อยากสร้างได้แล้ว ผู้เขียนก็นำ 'พรอมป์ตสร้าง PRD' ที่แอปนี้สร้างให้ไปใส่ใน LLM เพื่อให้ช่วยเขียน PRD

3) ตรวจดูการทำงานของผลลัพธ์ด้วยตาตัวเองให้เร็วและบ่อย

  • จุดแข็งที่สุดของ Vibe Coding คือสามารถได้ 'แอปที่รันได้' ตั้งแต่ช่วงต้นมากๆ และนี่สำคัญมากต่อแรงจูงใจของคนที่ไม่ใช่นักพัฒนา
  • ในความหมายนี้ ผู้เขียนจึงไม่ค่อยแนะนำให้คนที่ไม่ใช่นักพัฒนาเริ่ม Vibe Coding ด้วย Cursor เพราะกว่าจะรันแอปได้ต้องข้ามอุปสรรคเล็กใหญ่หลายอย่าง
  • ถ้าอย่างนั้น บริการอย่าง Lovable ที่รับ PRD แล้วปล่อย prototype ที่ใช้งานได้ออกมาทันที น่าจะเป็นจุดเริ่มต้นที่ดีกว่า แถมยังสร้าง public link ได้เลย จึงเอาไปให้คนรู้จักดูและรับ feedback ได้ง่าย
  • แต่ถ้าแอปที่อยากสร้างไม่ใช่เว็บ ก็จะซับซ้อนขึ้นเล็กน้อย เพราะเครื่องมือ prototyping มักสร้างเป็นเว็บแอป
  • ในกรณีนี้จะต้องมีทั้งการตัดสินใจเชิงเทคนิคและการตั้งค่าสภาพแวดล้อมการรัน ซึ่งหมายความว่าทั้งเราและ AI ต้องฉลาดขึ้นไปพร้อมกัน

4) โต้ตอบกับ AI ด้วยการพรอมป์ตอย่างเหมาะสมเพื่อให้เขียนโค้ดได้ดี

  • เรากับ AI ฉลาดขึ้น <-> เขียนพรอมป์ตได้ดีขึ้น <-> ได้ผลลัพธ์เร็วขึ้นและดีขึ้น
  • ยิ่งเขียนพรอมป์ตได้ดี จำนวนรอบการโต้ตอบเพื่อไปให้ถึงเป้าหมาย (= เวลาและเงิน) ก็ยิ่งลดลง
  • หากดูคู่มือ prompt engineering ต่างๆ จะพบว่ามีสิ่งหนึ่งที่พูดเหมือนกันคือ ต้องกำหนด Role, Context และ Task ในพรอมป์ตให้ดี

บทบาท บริบท และงาน

  • ใน Vibe Coding คำว่า 'บทบาท' ไม่ได้สำคัญมากนัก
    • เพราะ coding agent มักมีบทบาทที่เหมาะสมถูกกำหนดไว้อยู่แล้ว และการกำหนดเพิ่มอาจทำให้สับสนได้
    • อีกทั้งการเขียนโค้ดเป็น benchmark สำคัญ ทำให้ LLM หลายตัวเขียนโค้ดได้ดีแม้ไม่กำหนดบทบาท
    • แน่นอนว่าถ้าแอปที่กำลังสร้างมีลักษณะเฉพาะ การให้บทบาทที่เหมาะสมก็ยังเป็นเรื่องดี
  • ส่วน 'บริบท' ถ้าทำ PRD มาดีแล้วก็เพียงพอ
  • สำหรับ 'งาน' คือการกำหนดเป้าหมายและเกณฑ์ความสำเร็จให้ชัด โดยเกณฑ์ความสำเร็จอาจ
    • ระบุอยู่ในพรอมป์ตโดยตรง (few-shot prompting)
    • นิยามไว้ในไฟล์หรือโค้ดภายนอก (TODOs.md หรือ test code)
    • หรือมีอยู่แค่ในหัวเราเองก็ได้ (ซึ่งไม่ใช่สไตล์ที่ดีนัก)
  • เป้าหมายสูงสุดของ Vibe Coding คือ สั่งให้ AI เขียนโค้ดได้ดีเพื่อสร้างแอปที่ทำงานตาม PRD อย่างรวดเร็ว และเพื่อสิ่งนั้น ควรตั้งเป้าหมายระหว่างทางไว้ 3 ข้อ
    • ฉันฉลาดขึ้น
    • AI ฉลาดขึ้น
    • ฟีเจอร์ทำงานตรงตามสเปก

ฉันฉลาดขึ้น?

  • ถ้าไม่ใช่นักพัฒนา หรือไม่คุ้นกับโดเมนหรือ tech stack นั้นๆ การสั่งงานด้วยคำศัพท์ที่แม่นยำจะทำได้ยาก
  • ในกรณีนี้ให้บอก LLM ไปตรงๆ ว่าเรายังขาดอะไร และใช้มันเป็นครูได้
    • "(ให้ภาพหน้าจอ) เกมแบบนี้ปกติสร้างด้วยอะไร?"
    • "ฉันจะสร้างอะไรแบบนี้ ถ้าเป็นคุณจะหาข้อมูลอย่างไร?"
    • "ถ้าอยากตรวจสอบการทำงานหลักของ native app ให้เร็วที่สุด ควรใช้เทคโนโลยีอะไร?"
  • ลองสังเกตว่าตัวเองกำลังเปลี่ยนไปแบบนี้หรือไม่ผ่านคำถามเหล่านี้
    • คีย์เวิร์ดทางเทคนิค: ฉันเริ่มใช้คำศัพท์ทางเทคนิค/คำศัพท์เฉพาะโดเมนได้อย่างถูกต้อง
    • การไหลของข้อมูล: ฉันอธิบายได้ว่าแอปของฉันจะเอาข้อมูลสำหรับฟีเจอร์หลักมาอย่างไร ประมวลผลอย่างไร และแสดงผลอย่างไร
    • สภาพแวดล้อมการรัน: ฉันได้เตรียมสภาพแวดล้อมที่สามารถรันโค้ดที่ AI เขียนให้ แล้วตรวจสอบการทำงานด้วยตาตัวเองได้แล้ว
  • ตามอุดมคติ ควรเคลียร์ unknown unknown ให้หมดก่อนเขียน PRD แล้วค่อยเริ่มเขียนโค้ด แต่ไม่จำเป็นต้องเป๊ะขนาดนั้นเสมอไป
  • เพราะหลายอย่างจะได้เรียนรู้ก็ตอนเริ่มเขียนโค้ด และถ้าจำเป็นก็เริ่มทำใหม่ตั้งแต่ต้นได้เลย (บางครั้งอาจเร็วกว่าการไปแก้ของเดิมด้วยซ้ำ)

AI ฉลาดขึ้น?

  • คือการนำคีย์เวิร์ดทางเทคนิคหรือการไหลของข้อมูลที่เราเข้าใจแล้ว ไปบอก AI ผ่าน system prompt (เช่น Cursor Rules)
  • หากอยากลดจำนวนครั้งที่เราต้องเข้าไปแทรกแซง และอยากให้โค้ดของ AI ออกมาตรงใจมากขึ้น จะมีสิ่งสำคัญ 2 อย่าง คือข้อจำกัดและแนวทางด้านเอกสาร
  • แนวทางเรื่องข้อจำกัด ช่วยให้ AI เขียนโค้ดได้สม่ำเสมอขึ้น ตัวอย่างเช่น:
    • tech stack: ให้ใช้ NextJS app router, จัดสไตล์ด้วย Tailwind และ ShadCN, ใช้เฉพาะไอคอน Lucid, ใช้ Stripe สำหรับการชำระเงิน เป็นต้น
    • โครงสร้างและแพตเทิร์น: จัดโฟลเดอร์แบบนี้, ตั้งชื่อไฟล์แบบนี้, ทำสไตล์ UI ให้คล้าย Material เป็นต้น
    • รูปแบบผลลัพธ์ (ตามสภาพแวดล้อมการรัน): จะใช้ Electron Fiddle ก็ให้ส่งไฟล์ 4 ไฟล์ตามนั้น, จะใช้ CodePen ก็ให้ HTML, CSS, JS อย่างละไฟล์ เป็นต้น
  • แนวทางด้านเอกสาร ช่วยเพิ่มสมาธิและความจำของ AI ได้ดี ผู้เขียนพบว่า 2 ไอเดียนี้มีประโยชน์มาก
    • Memory Bank ของ Cline: กำหนด workflow ให้ทำงานพร้อมจดบันทึกสิ่งที่ทำแล้วและสิ่งที่ต้องทำไว้ในไฟล์
    • Prompt Context ของคุณคังดงยุน: แทนที่จะเขียนคำสั่งยาวๆ ไว้ที่โฟลเดอร์บนสุดของทั้งโปรเจกต์ ให้แยกคำสั่งตามแต่ละโฟลเดอร์
  • โดยเฉพาะ Memory Bank นั้นเหมาะกับคนที่ไม่ใช่นักพัฒนา เพราะช่วยให้สังเกตและเรียนรู้ได้ง่ายขึ้นว่าตอนนี้กำลังเกิดอะไรขึ้น

ฟีเจอร์ทำงานตรงตามสเปก?

  • นี่คือกลยุทธ์การพรอมป์ตเวลาคุยในแชตกับ coding agent ไม่ใช่ในระดับทั้งโปรเจกต์
  • ผู้เขียนคิดว่ากลยุทธ์ที่ดีที่สุดในการทำให้ฟีเจอร์ทำงานตามสเปกคือ ถ้าเทสต์ผ่านค่อยคอมมิต
    • "ช่วยทำ X ให้หน่อย เขียนเทสต์ก่อน จากนั้นค่อยเขียนโค้ด แล้วรันเทสต์ ถ้ายังไม่ผ่านก็แก้โค้ดต่อไปจนกว่าจะผ่าน"
  • สิ่งนี้ทำได้เพราะ coding agent มีทั้งสิทธิ์และความสามารถในการเขียน test code รันในเทอร์มินัล และอ่านผลลัพธ์ได้
  • เมื่อเทสต์ผ่านแล้ว ก็ให้มันเสนอ commit message จากนั้นคอมมิตทั้ง test code และ feature code ไปพร้อมกันได้ ผู้เขียนเลือกคอมมิตเอง แต่ agent ก็สามารถคอมมิตอัตโนมัติได้เช่นกัน
  • ไม่ใช่แค่ unit test เท่านั้น แต่ AI ยังสามารถเขียน รัน และแก้ไข integration test หรือ E2E test ได้เองด้วย (ดูเพิ่มเติม: Cursor + Playwright automated testing)
  • ทั้งหมดนี้คือกลยุทธ์ที่ทำให้ทั้งฝั่ง Vibe coder และฝั่ง AI ตรวจสอบได้ง่ายขึ้นว่า 'ฟีเจอร์แต่ละส่วนถูกพัฒนาตามสเปกหรือไม่ และแอปทั้งหมดทำงานตาม PRD หรือไม่'

5) สังเกตพฤติกรรมผิดปกติและจุดที่ควรปรับปรุง แล้วแก้ไขจนปิดงานได้

  • ในมุมมองของผู้เขียน Vibe Coding ไม่ใช่เรื่อง "กดปุ๊บได้ปั๊บ" และยังมีเรื่องให้เรียนรู้อีกมาก
  • โดยเฉพาะถ้าจะก้าวข้ามจาก 'prototype เล็กๆ ของตัวเอง' ไปสู่การสร้างแอประดับผลิตภัณฑ์เชิงพาณิชย์ในฐานะ solo founder จะมีทักษะสำคัญ 3 อย่างที่ขาดไม่ได้ คือทักษะการรับรู้ ทักษะการเขียนโค้ด และทักษะ product engineering

ทักษะการรับรู้

  • คือความสามารถในการสังเกตอย่างไวว่าหน้าจอหรือฟีเจอร์ใดทำงานต่างจาก PRD (หรือเจตนาเดิมของเรา)
  • ถ้าขาดสิ่งนี้ จะยากมากที่จะหาว่า AI ทำผิดตรงไหนแล้วสั่งให้แก้
    • 'การเทสต์' ในขั้นตอนที่ 4 ไม่เพียงช่วยลดความผิดพลาดของ AI ตั้งแต่ต้น แต่ยังช่วยเพิ่มทักษะของเราเองด้วย
    • เพราะเมื่อเราอ่านกระบวนการที่ AI แปลงสเปกให้เป็น test code เราจะได้เรียนรู้ว่า การบอกเพียงว่า 'ต้องมีฟีเจอร์นี้' ไม่พอ แต่ต้องเข้าใจด้วยว่า 'ถ้าจะถือว่าฟีเจอร์นี้เสร็จสมบูรณ์ ต้องมีเงื่อนไขอะไรบ้าง'
  • แต่ 'แอปถูกสร้างตรงตามสเปก' กับ 'แอปนั้นดี' ไม่ใช่เรื่องเดียวกัน เพราะฉะนั้นการมี product sense ในการหาจุดปรับปรุงจึงสำคัญ (รายละเอียดเพิ่มเติมดูในจดหมายข่าวของ Lenny ที่ลิงก์ไว้)

ทักษะการเขียนโค้ด

  • อย่างน้อยในตอนนี้ ต่อให้แตกงานให้ AI ดีแค่ไหน ก็ยังมีประมาณ 5% ที่ต้องลงมือแก้โค้ดเองเพื่อปิดงานให้จบ
    • มีแอปมากมายบน SNS ที่ไปไม่ถึงการเปิดตัว เพราะติดอยู่แถว 80% เนื่องจากทำจุดนี้ไม่ได้
  • แน่นอนว่าสัดส่วนนี้อาจต่างกันไปตามประเภทแอปที่อยากสร้าง และไม่ใช่ว่าจะเป็นไปไม่ได้เลยที่จะทำทุกอย่างด้วย AI จนจบ แต่ก็ไม่มีประสิทธิภาพนัก
  • แทนที่จะปล่อยตัวไปกับ Vibe อย่างเดียว ผู้เขียนแนะนำให้ใช้เอกสารที่ AI สร้างขึ้น (เช่น Memory Bank, test code เป็นต้น) เป็นสื่อช่วยเรียนรู้เรื่องโค้ดไปด้วย และถ้าเป็นไปได้ก็ลองขอคำแนะนำจากนักพัฒนา
  • โดยเฉพาะเรื่อง backend ที่มองเห็นได้น้อยกว่า (เช่น การยืนยันตัวตนผู้ใช้ การเชื่อมต่อ external API การรับส่งข้อมูล การชำระเงิน เป็นต้น) และกลยุทธ์การ deploy (เช่น main branch / feature branch, การจัดการ environment variables เป็นต้น) เป็นหัวข้อที่เรียนแล้วจะคุ้มมาก

ทักษะ product engineering

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

ปิดท้าย

  • การทำให้แอปด้วย Vibe Coding ไปถึงระดับผลิตภัณฑ์เชิงพาณิชย์นั้นไม่ใช่เรื่องง่ายเลย แต่คงไม่มีใครปฏิเสธได้ว่า 'การเริ่มต้น' ง่ายกว่าที่เคยมาก
  • เมื่อเห็นคนรู้จักได้เห็นไอเดียเล็กๆ ของตัวเองมีชีวิตขึ้นมาจริงๆ แล้วอุทานด้วยความตื่นเต้นว่า ("ว้าว ฉันกำลังเขียนโค้ดอยู่จริงๆ!") และมีความสุขมาก ผู้เขียนเองก็มีความสุขมากเช่นกัน
  • ผู้เขียนจึงอยากชวนคนที่ไม่ใช่นักพัฒนาคนอื่นๆ ที่ได้อ่านบทความนี้ ลองใช้โอกาสนี้มาเป็น 'maker' อย่างสนุกสนานดู
  • หากใช้ความเชี่ยวชาญเฉพาะทางของตัวเอง สร้าง เครื่องมือขนาดเล็กที่เร็ว มีประโยชน์ และแก้ปัญหาเฉพาะได้อย่างยอดเยี่ยม ด้วย Vibe Coding ก็เชื่อว่าในยุค AI ก็ยังมีศักยภาพในการแข่งขันได้มากพอ

บทความที่เกี่ยวข้อง

7 ความคิดเห็น

 
jk34011 2025-04-25

ว้าว~ ผมเคยคิดว่า vibe coding เป็นแค่ภาพลวงตา
ไม่ได้เห็นบทความที่เขียนอย่างมีความเป็นมืออาชีพขนาดนี้มานานแล้ว
อ่านได้อย่างเพลิดเพลินมากครับ
 
spilist2 2025-04-25

ขอบคุณครับ! ผมมองเห็นศักยภาพอย่างมากเลย 555
 
jk34011 2025-04-25

อ่า;; ตอนนี้พอกลับมาดูแล้วรู้สึกว่าคอมเมนต์ของผมมันแปลก ๆ ไปหน่อยนะครับ
ถ้าจะให้พูด แทนที่จะใช้คำว่าภาพลวง ก็น่าจะเป็นความรู้สึกประมาณว่ายังอีกไกล? มากกว่าครับ
สุดท้ายแล้วผมรู้สึกว่า vibe coding ก็มีข้อจำกัดอยู่ และถ้าไม่มีความรู้ด้านการพัฒนาก็คงยากครับ
แน่นอนว่าพอ AI พัฒนาขึ้น ต่อไปก็น่าจะดีขึ้นกว่านี้มากครับ

ผมกลัวว่าคอมเมนต์ของผมจะทำให้รู้สึกเหมือนกำลังบอกว่า vibe coding ไม่มีความหมาย ก็เลยมาพิมพ์ตอบอีกรอบยาว ๆ แบบนี้ครับ
ผมเองก็ใช้ vibe coding บ่อยมากเหมือนกัน ฮ่าๆ
 
spilist2 2025-04-26

อ้อ ไม่ใช่ครับ ฮ่าๆ ผมก็เข้าใจนัยที่คุณพูดถึงเหมือนกัน

เพราะงั้นอย่างที่ผมเขียนไว้ในบทความ การเขียนโค้ดแบบ vibe coding ที่ผมพูดถึงนั้นห่างไกลจากการแค่ 'คลิกเดียว' มาก และถ้าจะยกระดับให้ดีขึ้น ผมคิดว่าวิศวกรต้องทุ่มเทความพยายามอย่างมากครับ
 
bbulbum 2025-04-23

ติดตามอ่านอยู่เสมอครับ
 
spilist2 2025-04-23

ขอบคุณครับ!
 
spilist2 2025-04-23

ผมทำวิดีโอ YouTube ไว้ด้วยครับ ฮ่าๆ https://www.youtube.com/watch?v=ecY5VBpruOA