Vibe Coding แบบคนไม่รู้อะไรเลย ฉบับไม่มีคู่มือ 101
สี่เดือนก่อน เราเริ่ม vibe coding ทั้งที่ไม่มีพื้นฐานทางด้าน code อะไรทั้งสิ้นเลยค่ะ
จนตอนนี้มีเว็บแอป FKE ที่คนใช้งานจริงออกมาแล้วหนึ่งตัว (พร้อมได้รับฟีดแบ็คน่ารัก ๆ) และกำลังปั้นอีกตัวอยู่แบบเข้มข้น
เผื่อใครที่อยากเริ่มแต่ยังลังเล
เราคิดว่านี่น่าจะเป็นแนวทางสำหรับคนที่ไม่มีความรู้เลยแต่อยากเริ่ม vibe coding ค่ะ

แนวคิดที่อยู่เบื้องหลังโพสต์นี้ — ความสนุกอยู่ที่การได้ลองสร้างของที่ "เราเอาไปใช้ได้จริง" — นั่นคือสิ่งที่เรากำลังสร้างเป็นอีกสองโปรเจกต์ที่กำลังปั้นอยู่ค่ะ สิ่งที่เราสนใจไม่ใช่การสร้างเครื่องมือเพื่อให้คนมีข้อมูลเพิ่มขึ้น แต่คือการออกแบบระบบที่ช่วยให้เราเห็นสิ่งสำคัญ และลงมือทำขั้นต่อไปได้ง่ายขึ้น ตอนนี้กำลังนำแนวคิดนี้ไปใช้กับ Wealth Tracker สำหรับการตัดสินใจเรื่องเงิน และ FKE สำหรับการฝึกภาษาฝรั่งเศสแบบ active learning ถ้าแนวคิดนี้ตรงกับสิ่งที่คุณกำลังหา ลองดูสิ่งที่กำลังสร้างต่อได้ที่นี่ →
เราว่าหลายคนไม่ได้ติดตรงที่ไม่มีไอเดียหรอก แต่ติดอยู่ที่ประโยคว่า "เราไม่ใช่สายนี้" พอไม่รู้ code ก็เลยคิดว่าต้องไปเรียนให้รู้ก่อนถึงจะเริ่มสร้างอะไรได้ แต่สิ่งที่เราเรียนรู้คือ
การ learning by doing เริ่มลงมือไปก่อน แล้วค่อยมาเรียนและแก้ปัญหาระหว่างทำไปค่ะ
ถ้าใครก็มีของที่อยากทำ แต่ยังยืนงงอยู่หน้าประตูเหมือนเราเมื่อสี่เดือนก่อน นี่คือวิธีที่เราเริ่มค่ะ
1. ลองของฟรีก่อน อย่าเพิ่งรีบจ่าย
เริ่มจาก AI ฝั่งแชทก่อนก็ได้ค่ะ ลองถามเรื่องที่เรารู้อยู่แล้ว เพื่อดูว่ามันเข้าใจเราแค่ไหน ลองเปลี่ยนคำสั่งแล้วสังเกตว่าคำตอบเปลี่ยนยังไง ลองให้แต่ละโมเดลสรุป แตกปัญหา หรือถามกลับก่อนตอบ
พอใช้ไปสักพัก เราจะเริ่มจับทางได้เองว่า
ต้องให้ context หรือเขียนละเอียดแค่ไหน (จริง ๆ ยิ่งละเอียดยิ่งดีนะ เพราะเค้าจะได้คิดแบบครอบคลุม)
งานสเกลใหญ่ ควรแบ่งเป็นกี่พาร์ท จะได้โฟกัสทีละจุด
เมื่อไหร่ควรหยุดแล้วขึ้น session ใหม่เพื่อถาม
prompt บอกข้อจำกัดยังไง เพื่อไม่ให้คำตอบฟุ้งไปเรื่อย ไม่เปลือง usage หรือ tokens
เราว่าจุดนี้สำคัญตั้งแต่เริ่มแรก มากกว่าการหา prompt สำเร็จรูปอีกค่ะ
เพราะ prompt ที่ดีที่สุด ไม่ใช่ prompt ที่ยาวที่สุด แต่คือ prompt ที่เราเข้าใจว่า AI กำลังทำอะไรให้เรา และทำให้ AI เข้าใจว่าเรากำลังพยายามทำอะไร มันคือ analytical thinking ล้วน ๆ
2. เริ่มอยากเสียเงินตะหงิด ๆ ก็จ่ายรายเดือนก่อน
อย่าเพิ่งใจใหญ่ไปรายปีค่ะ แม้ส่วนลดมันจะเย้ายวนใจมาก
โมเดลแต่ละเจ้าเปลี่ยนเร็วมาก ประหนึ่งค่ายมือถือแจกโปรโมชั่น !! 555+
อย่างเราตอนแรกก็เข้าวงจร Claude Cowork พอ ChatGPT ให้ตั๋วรีเซ็ตกับสิทธิ์ใช้ Plus ฟรีหนึ่งเดือน เราก็ย้ายมาลอง GPT ต่อ เพราะเรามันคนใจง่าย ไม่มีตัวไหนต้องเป็น "บ้านหลังสุดท้าย" ของเราก็ได้
สิ่งที่ควรทำให้พร้อมกว่า คือ ทำให้งานย้ายบ้านง่าย
เราเก็บ requirement, context, สิ่งที่ตัดสินใจไปแล้ว และ progress ของโปรเจกต์ไว้ในไฟล์ .md พอเปลี่ยนเครื่องมือก็ยื่นไฟล์ให้ตัวใหม่อ่านต่อ ไม่ต้องนั่งเล่าเรื่องเดิมตั้งแต่ชาติปางก่อน
Tool เปลี่ยนได้ค่ะ แต่งานของเราต้องไม่หายความจำตาม tool ไปด้วย
prompt ที่เราใช้สรุปงานเป็นไฟล์ .md คืออันนี้ค่ะ
Read our entire conversation above and turn it into a single handoff document
so a brand-new AI session can continue this project with zero context loss.
Write it as clean Markdown with these sections, in this order:
1. Goal & Definition of Done — what we're building and how we'll know it's finished
2. Current State — what's done, what's in progress, what's broken
3. Decisions Made (and WHY) — so the next session doesn't re-open settled choices
4. Constraints — tech, tools, budget, time, my skill level
5. Key Code / Artifacts / Links — only what's needed to keep going
6. Open Questions — what's still undecided or unverified
7. Next 3 Steps — the exact things to do next, most important first
Rules:
- Be specific. Prefer concrete names, values, and file references over summaries.
- If something important is missing or unclear, list it under Open Questions instead of guessing.
- Output everything inside ONE Markdown code block so I can copy it in one click.
- No preamble, no sign-off, no filler.เอาประมาณนี้ไปก่อนค่า พอเราเชี่ยวชาญขึ้น เราจะเริ่มรู้เองว่าต้องปรับอะไรยังไง
3. สิงอยู่ตามกลุ่มคอมมู
ไม่เข้าใจก็โพสต์ถามในกลุ่มเนี่ยแหละค่ะ ไม่ต้องกลัวว่าคนอื่นจะคิดว่าเราไม่มีความรู้ เพราะหลายครั้งคำถามที่เราคิดว่าพื้นฐานมาก ๆ คือเรื่องที่คนอื่นเคยติดมาแล้วเหมือนกัน
เราว่าคอมมูของ Claude กับ Codex ที่เราอยู่น่ารักที่สุดแล้ว คนตอบกันจริงจังมากนะคะ บางทีมีคนทัก DM มาอธิบายเพิ่มให้ด้วยซ้ำ ประทับใจมากกกกก
ข้อดีของการสิงในกลุ่มไม่ใช่แค่ได้คำตอบ แต่เราได้เห็นว่า "ความเป็นไปได้" ตอนนี้ไปอยู่ตรงไหนแล้ว คนอื่นกำลังทำอะไร ติดปัญหาแบบไหน ใช้ workflow ยังไง และมีอะไรที่เราไม่เคยนึกถึง จะได้เอามาปรับกับโปรเจกต์ตัวเองได้ค่ะ บางคนก็ใจดีแจก prompt กันด้วย อย่าง prompt สร้าง KOS คลังสมองกลาง กับ MiroFish ที่ปรึกษาส่วนตัว เราก็เอามาแจกต่อเหมือนกันค่ะ
4. อยากได้อะไร บอก AI ไปตรง ๆ
อยากทำเว็บ ก็เริ่มจากบอกว่าอยากทำเว็บอะไรค่ะ อยากทำแอพก็บอกไปว่าอยากทำแอพ ไม่จำเป็นต้องรู้ก่อนว่าต้องใช้ framework ไหน ฐานข้อมูลอะไร หรือ architecture หน้าตาแบบไหน แต่ต้องไปรู้ทีหลังนะ !! (แค่พิมพ์สามคำนี้ได้ตอนนี้ เราก็มาไกลแล้วนะ 555)
หน้าที่แรกของเราไม่ใช่เลือก technology แต่คืออธิบายให้ชัดว่า
ใครทำอะไรเพื่ออะไร — ใครจะใช้ เขามีปัญหาอะไร อยากให้ระบบช่วยทำอะไร อะไรคือข้อจำกัด และผลลัพธ์แบบไหนที่เราจะเรียกว่า "ใช้ได้จริง"
ถ้ายังไม่รู้จะเริ่มยังไง ลอง copy อันนี้ไปคุยกับ AI ก่อนได้ค่ะ
ฉันอยากสร้าง: [สิ่งที่อยากสร้าง]
คนที่จะใช้: [ใคร]
ปัญหาที่อยากแก้: [ปัญหา]
สิ่งที่อยากให้ทำได้หลัก ๆ: [3–5 อย่าง]
ข้อจำกัดของฉัน: [เวลา / งบ / ความรู้ / เครื่องมือที่มี]
สิ่งที่ฉันยังไม่รู้: [เช่น ยังไม่รู้ว่าต้องใช้ระบบอะไร]
ก่อนจะเสนอวิธีทำ ขอให้ทำตามนี้:
1. ถามคำถามที่จำเป็นจริง ๆ เพื่อเข้าใจโจทย์ก่อน (อย่าเพิ่งเขียนโค้ด)
2. เล่าโจทย์กลับมาด้วยคำของคุณเอง เพื่อยืนยันว่าเราเข้าใจตรงกัน
3. เสนอ "ชิ้นแรกที่เล็กที่สุดที่ใช้งานได้จริง" ว่าควรเริ่มตรงไหน
4. แตกงานเป็นขั้นเล็ก ๆ ที่ฉันตรวจสอบได้ทีละขั้น พร้อมบอกว่าแต่ละขั้น "เสร็จ" ดูจากอะไร
5. เตือนฉันทุกครั้งถ้ามีขั้นไหนแตะเรื่อง payment, ข้อมูลส่วนตัว หรือความปลอดภัย
ตอบเป็นภาษาไทย อธิบายเหมือนคุยกับคนที่ไม่มีพื้นฐาน codingยิ่งเราให้เป้าหมาย ข้อจำกัด และตัวอย่างชัดเท่าไหร่ มันก็ยิ่งพาเราไปใกล้ของที่อยู่ในหัวมากขึ้น แล้วเราค่อย ๆ แตกยอดจากตรงนั้นค่ะ
5. อ่าน อ่านจนตาแตก
อันนี้น่าจะเป็นข้อที่หลายคนไม่ชอบที่สุด 555
เวลา AI ตอบกลับมายาว ๆ อย่าเพิ่งกด accept รวดเดียวค่ะ ให้อ่านว่ามันกำลังทำอะไร ทำไปทำไม เปลี่ยนตรงไหน และสิ่งที่เปลี่ยนยังตรงกับที่เราอยากได้อยู่หรือเปล่า เราไม่จำเป็นต้องเข้าใจทุกบรรทัดแบบ developer แต่ต้องเข้าใจมากพอที่จะรู้ว่างานยังวิ่งไปหาเป้าหมายที่เราตั้งใจไว้อยู่มั้ย ไม่ใช่ใจเกเรพาเราออกนอกกรอบ
เพราะ vibe coding ไม่ได้แปลว่า "บอก AI แล้วปล่อยให้มันทำทั้งหมด"
แต่เราคือคนกุมบังเหียนม้า แล้วเอาเท้ากระทุ้ง หรือบางทีก็เอาแส้กระตุ้น ให้ไปถึงจุดหมายค่ะ
อีกอย่างหนึ่งคือ เรามองว่า
AI เหมือน multiplier ที่เป็นตัวคูณความเก่งของเรา
หลาย ๆ ที เรามักต้องใส่ความรู้เฉพาะทางไปสะกิดเพิ่มเวลาที่เค้าบอกว่าทำไม่ได้ ถ้าเป็นเรื่อง payment, privacy, security หรือข้อมูลสำคัญ ก็ให้ audit บ่อย ๆ และไปสิงถามในกลุ่มคอมมู จะทำให้เราเห็นว่าความเป็นไปได้ไปอยู่ที่จุดไหน
เราว่าการ vibe มันมีข้อดีของมัน
แค่เราใช้เวลากับมันบ่อย ๆ เราจะเริ่มรู้แนวทางว่าจะ vibe แบบไหน มันไม่ได้มีกฎเกณฑ์อะไรขนาดนั้น
developer ได้เปรียบเรื่อง architecture, debugging, security และการดูแลระบบระยะยาว
แต่คนที่ไม่ได้มาจากสาย tech ก็มีของดีคนละแบบ เพราะเราเป็นผู้ใช้มาก่อน เราเข้าใจ user รู้ pain point จากประสบการณ์ตรง เราก็แค่ต้องอดทน ถามเยอะ อ่านละเอียด แล้วทำ product testing ไล่แก้ไปเรื่อย ๆ (ขยัน vibe coding กับเน้นทนถึกเอาค่ะ)
ทำบ่อยเข้า เราจะเริ่มรู้เองว่า AI ทำอะไรได้ ไม่ได้ และ workflow แบบไหนเข้ากับสมองของเรา ซึ่งมันเป็นความสนุกอย่างนึงเหมือนกันนะคะ
เราไม่คิดว่า vibe coding จะมาแทน developer ทั้งหมด
แต่คิดว่ามันกำลังทำให้คนธรรมดาที่มีปัญหาอยู่ในมือ สามารถลองสร้างวิธีแก้ปัญหาของตัวเองได้เร็วขึ้น
ในโลกที่ใคร ๆ ก็ทำ app ได้ ความต่างอาจไม่ได้อยู่แค่ว่าใครเขียน code เก่งที่สุด แต่อยู่ที่
ใครเข้าใจคนใช้มากพอจะรู้ว่าควรสร้างอะไร และของที่สร้างออกมาดีพอสำหรับชีวิตจริงแล้วหรือยัง
ถ้ามีคนทำแอปดี ๆ มาแล้ว ก็ซื้อ ๆ ใช้ไปเถอะค่ะ เค้ากลั่นกรองมาให้เราตั้งเยอะแล้ว
แต่ถ้าของที่อยากได้ยังไม่มี หรือมีแล้วแต่รสไม่ถูกปาก อยากลองสานฝันวัยเด็ก ก็ลองทำเองได้เหมือนกัน เหมือนไปกินก๋วยเตี๋ยวร้านเดียวกัน บางคนยังปรุงคนละรสเลย 🍜
ก็หวังว่าทุกคนจะสนุกกับ vibe coding กันค่ะ
ถ้าบทความนี้ทำให้อยากลองสร้างระบบเล็ก ๆ ของตัวเองดูบ้าง นั่นแหละคือแนวคิดเดียวกับที่เรากำลังทำอยู่ Wealth Tracker สำหรับการตัดสินใจเรื่องเงิน FKE ช่วยเปลี่ยนการเรียนภาษาฝรั่งเศสให้เป็นการฝึกแบบ active learning (core tools ลองเล่นได้แล้ว) แนวคิดเดียวกัน แต่คนละการใช้งาน เลือกติดตามอันที่ใช่สำหรับคุณได้เลย




Comments