Name: เข้าใจ AI Coding และสร้างแอปแรกด้วย Prompt-to-App · หลักสูตร AI Coding อย่างมืออาชีพ
Author: จักริน นพรุจนธาดา

1.1

โมดูล 1.1

ภาพรวม AI Coding ปี 2025-2026

รู้จักผู้เล่นหลักและแบ่งประเภทเครื่องมือให้ถูก

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนก่อนจะเลือกซื้อรถ เราต้องรู้ก่อนว่าตลาดมีค่ายไหนบ้าง รถกระบะ รถเก๋ง รถ SUV ต่างกันยังไง จะได้ไม่ซื้อผิดคัน โมดูลนี้คือการพาเดินดูโชว์รูมเครื่องมือ AI Coding ทั้งตลาด

🎯

ทำไมต้องรู้: ถ้าเรารู้จักผู้เล่นและแยกประเภทเครื่องมือเป็นตั้งแต่ต้น เวลาเจองานจริงเราจะหยิบเครื่องมือถูกตัว ไม่เสียเวลาเสียเงินไปลองผิดลองถูกทีละอัน

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

แยกออกว่าเครื่องมือมี 3 กลุ่ม คือ ตัวช่วยเขียนโค้ดสำหรับนักพัฒนา (IDE agent), ตัวสร้างแอปจากคำพิมพ์สำหรับคนไม่เขียนโค้ด (prompt-to-app) และสมอง AI ที่อยู่เบื้องหลัง (model)
รู้จักชื่อจริงและตำแหน่งของ Cursor, GitHub Copilot, Claude Code, Devin Desktop (เดิม Windsurf)
เข้าใจว่าทำไมวงการนี้เปลี่ยนเร็วมาก และทำไมต้องระวังพวกเลขรุ่น (version) กับราคาที่มักจะเก่าไปแล้ว

เนื้อหา

เราจะเปิดหลักสูตรด้วยการพาเดินดูตลาดตอนนี้ให้เห็นภาพรวมทั้งหมด เครื่องมือแบ่งได้เป็น 3 กลุ่ม กลุ่มแรกคือตัวช่วยเขียนโค้ดสำหรับนักพัฒนา (IDE agent) ได้แก่ Cursor (เอา VS Code มาดัดแปลงต่อ ตอนนี้เป็นผู้นำของกลุ่ม), GitHub Copilot (เจ้าตลาดเดิม มีของต่อเชื่อมเยอะที่สุด), Claude Code (สั่งงานผ่านหน้าจอดำ ๆ ที่พิมพ์คำสั่ง) และ Devin Desktop ซึ่งเดิมชื่อ Windsurf/Codeium ก่อนจะถูก Cognition AI ซื้อไปเมื่อ ก.ค. 2025 — ตัวนี้เปลี่ยนชื่อมาแล้วถึงสองรอบ กลุ่มที่สองคือตัวสร้างแอปจากคำพิมพ์สำหรับคนไม่เขียนโค้ด (prompt-to-app) ได้แก่ v0, Bolt.new, Lovable, Replit ส่วนกลุ่มที่สามคือสมอง AI ที่อยู่เบื้องหลัง (model) เช่น Claude Opus 4.8, GPT-5.5, Gemini 3.x Pro สิ่งที่อยากให้จำที่สุดในโมดูลนี้คือ ทุกอย่างเปลี่ยนเร็วมาก ราคากับเลขรุ่นขยับกันแทบทุกเดือน เพราะฉะนั้นให้ติดนิสัยเข้าไปเช็กข้อมูลล่าสุดจากหน้าราคาจริงเสมอ อย่าไปเชื่อตัวเลขในสไลด์แบบตายตัว

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

IDEโปรแกรมที่นักเขียนโค้ดใช้ทำงาน เหมือนโต๊ะทำงานครบชุดของช่าง มีทั้งที่พิมพ์โค้ด ที่ทดสอบ และเครื่องมือช่วยเหลือรวมอยู่ในที่เดียว

IDE agentโต๊ะทำงานเขียนโค้ดที่มีผู้ช่วย AI ฝังอยู่ในตัว คอยเขียนและแก้โค้ดให้เราแบบเป็นเพื่อนคู่คิด

forkการเอาโปรแกรมของคนอื่นมาก๊อปปี้แล้วดัดแปลงต่อเป็นเวอร์ชันของตัวเอง เหมือนเอาสูตรอาหารต้นตำรับมาปรับใส่เครื่องเพิ่มให้เป็นสูตรใหม่

terminal-firstเครื่องมือที่เน้นสั่งงานผ่านหน้าจอดำ ๆ ที่พิมพ์คำสั่ง (terminal) แทนการคลิกปุ่มบนหน้าจอสวย ๆ

ecosystemระบบแวดล้อมของเครื่องมือ ทั้งส่วนเสริม ชุมชนผู้ใช้ และของที่ต่อเชื่อมได้ ยิ่งใหญ่ยิ่งหาตัวช่วยได้ง่าย เหมือนห้างที่มีร้านครบทุกอย่าง

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

จัดกลุ่มเครื่องมือจากโจทย์งาน

โจทย์: 'ฉันเป็น PM อยากทำต้นแบบแอปจองคิวร้านอาหารให้ทีมดูภายในสัปดาห์นี้ ฉันเขียนโค้ดไม่เป็น' — เครื่องมือกลุ่มไหนเหมาะ และเพราะอะไร

✅ ผลลัพธ์ที่ได้

คำตอบ: เลือกกลุ่ม prompt-to-app ไม่ใช่ IDE agent เพราะไม่ต้องเขียนโค้ดเอง หากต้องมีฐานข้อมูลจองคิว + auth เลือก Lovable หรือ Replit หากเน้นหน้าตา UI สวยเลือก v0 — ยังไม่ต้องแตะ Cursor/Copilot/Claude Code ซึ่งออกแบบมาสำหรับคนที่อ่านโค้ดออก

💡 จุดสอน

การเลือกเครื่องมือเริ่มจากโจทย์และทักษะผู้ใช้ ไม่ใช่จากความดังของชื่อ heuristic แรกคือ 'คุณอ่านโค้ดออกไหม' ถ้าไม่ ให้เริ่มที่ prompt-to-app

แบบฝึกหัดท้ายโมดูล

ทำตารางเปรียบเทียบเครื่องมือ 8 ตัวจากในโมดูล ระบุว่าแต่ละตัวอยู่กลุ่มไหนและเหมาะกับใคร แล้วเข้าเว็บ pricing จริงของ 2 ตัวเพื่อตรวจว่าราคายังตรงกับที่เรียนหรือไม่
เขียนอธิบาย 3 บรรทัดว่าทำไม 'Windsurf' ที่เห็นในบทความเก่าจึงถือว่าเป็นชื่อเก่าที่เลิกใช้แล้ว และตอนนี้เรียกว่าอะไรอยู่ใต้บริษัทไหน

1.2

โมดูล 1.2

สามโหมดการทำงาน: Inline, Chat, Agent

เข้าใจลำดับชั้นของโหมดและเลือกใช้ให้ตรงงาน

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนการขอความช่วยเหลือจากคนอื่น 3 ระดับ: บอกใบ้เติมประโยคให้ (inline), นั่งคุยปรึกษาทีละเรื่อง (chat), หรือมอบงานทั้งก้อนให้ไปทำเองแล้วค่อยมาส่ง (agent) เลือกระดับให้เหมาะกับความยากของงาน

🎯

ทำไมต้องรู้: ถ้าเข้าใจว่าแต่ละโหมดเหมาะกับงานแบบไหน เราจะทำงานเร็วขึ้นมาก ไม่เอาปืนใหญ่ไปยิงนก หรือเอามือเปล่าไปสู้งานใหญ่

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

อธิบายได้ว่าโหมดเติมโค้ดให้อัตโนมัติ (inline completions), โหมดแชตคุย (chat) และโหมดปล่อยให้ทำงานเอง (agent mode) ต่างกันยังไง
รู้ว่าแต่ละโหมดเหมาะกับงานแบบไหนและมีข้อจำกัดอะไร
เข้าใจว่าการปล่อยให้ AI ทำเองมากขึ้น (autonomy) ไม่ได้แปลว่าดีกว่าเสมอ มันคือการแลกกันได้อย่างเสียอย่าง (trade-off)

เนื้อหา

ถึงมือใหม่จะเริ่มต้นที่ตัวสร้างแอปจากคำพิมพ์ (prompt-to-app) แต่ก็ควรเข้าใจภาพในหัว (mental model) ของทั้ง 3 โหมดตั้งแต่แรก เพราะมันเป็นแกนของทั้งหลักสูตร โหมดแรกคือการเติมโค้ดให้อัตโนมัติ (inline completions) พิมพ์ไปมันก็เดาโค้ดที่เหลือให้ กด Tab รับได้เลย โหมดนี้เร็วที่สุด ทำงานลื่นไม่สะดุด เหมาะกับโค้ดพื้น ๆ ที่ต้องพิมพ์ซ้ำ ๆ แต่มันไม่เข้าใจเป้าหมายภาพใหญ่ โหมดสองคือแชตคุย (chat) ที่มีช่องแชตอยู่ข้างจอให้เราคุยทีละเรื่อง เราคุมได้ทีละขั้น เหมาะกับการสั่งให้อธิบายโค้ด จัดโค้ดใหม่ให้อ่านง่าย เขียนตัวทดสอบ (test) ตอบคำถาม และช่วยไล่จับบั๊ก โหมดสามคือปล่อยให้ทำงานเอง (agent mode) แค่บอกเป้าหมาย มันจะไปอ่านไฟล์เอง แก้ทีเดียวหลายไฟล์ รันคำสั่งกับตัวทดสอบ แล้ววนแก้ไปเรื่อย ๆ จนเสร็จ เหมาะเวลาที่เราบอกได้ชัด ๆ ในหนึ่งถึงสองประโยคว่าแบบไหนถึงเรียกว่า "เสร็จ" และไว้ใจให้ระบบตรวจอัตโนมัติกับการรีวิวช่วยจับที่พลาด หลักคิดสำคัญคือ ปล่อยให้ AI ทำเองมากขึ้นไม่ได้แปลว่าดีขึ้นเสมอ ยิ่งให้ผู้ช่วย (agent) อิสระมาก ก็เท่ากับแลกความเร็วมาด้วยการควบคุมที่น้อยลง (บริษัท Swarmia อธิบายเรื่องนี้ไว้เป็น "ห้าระดับของการปล่อยให้ทำเอง")

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

inline completionsAI เติมโค้ดให้อัตโนมัติขณะเราพิมพ์ เหมือนมือถือที่เดาคำถัดไปให้เราตอนพิมพ์ข้อความ

ghost textตัวอักษรจาง ๆ ที่ AI แสดงให้ดูล่วงหน้าว่าจะเติมอะไร ถ้าถูกใจก็กดรับ ถ้าไม่ก็พิมพ์ของเราต่อ

boilerplateโค้ดพื้น ๆ ที่ต้องเขียนซ้ำ ๆ เหมือนกันทุกงาน น่าเบื่อแต่จำเป็น เหมาะให้ AI ช่วยพิมพ์แทน

chat (side panel)ช่องแชตข้าง ๆ จอที่เราคุยกับ AI ถาม-ตอบทีละขั้น เหมือนไลน์คุยกับที่ปรึกษา

mental modelภาพความเข้าใจในหัวว่าสิ่งหนึ่งทำงานยังไง เหมือนแผนที่ในใจที่ช่วยให้เราตัดสินใจได้ถูก

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

จับคู่งานกับโหมด

งานสามชิ้น: (1) เติมโค้ดวน loop ที่เหลือครึ่งบรรทัด (2) 'ช่วยอธิบายว่าฟังก์ชันนี้ทำอะไรและ refactor ให้อ่านง่ายขึ้น' (3) 'แก้บั๊กที่กดปุ่มลบแล้วรายการไม่หาย มี repro ชัดเจน' — แต่ละงานควรใช้โหมดไหน

✅ ผลลัพธ์ที่ได้

(1) inline completion — งาน boilerplate อยู่ใน flow, (2) chat — งานผ่าตัดเฉพาะจุดที่เราอยากคุมทีละขั้น, (3) agent mode — โจทย์ชัด อธิบาย 'เสร็จ' ได้ในประโยคเดียว และมี repro ให้ agent วน test เองได้

💡 จุดสอน

โหมดไม่ใช่เรื่องของความเจ๋ง แต่เป็นเรื่องของความชัดของโจทย์และความไว้ใจในด่านตรวจ ยิ่งโจทย์ชัดและมี test/CI รองรับ ยิ่งเลื่อนไปทาง agent ได้

แบบฝึกหัดท้ายโมดูล

เขียนรายการงานจริงในชีวิตประจำวัน 6 งาน แล้วจัดว่าแต่ละงานควรใช้ inline/chat/agent พร้อมเหตุผลหนึ่งประโยค
อธิบายด้วยตัวอย่างของตัวเองว่า 'autonomy สูงกว่าไม่ได้ดีกว่าเสมอ' หมายความว่าอย่างไรในงานที่คุณเคยทำ

1.3

โมดูล 1.3

Vibe Coding vs Agentic Engineering

เข้าใจคำที่เปลี่ยนความหมายและกับดักของมัน

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: Vibe coding เหมือนทำอาหารมั่ว ๆ ตามใจ อร่อยก็กินไม่อร่อยก็ทิ้ง เหมาะกับลองเล่น ส่วน agentic engineering เหมือนเป็นหัวหน้าเชฟที่คุมลูกมือหลายคน คอยสั่งและตรวจงานให้ออกมาใช้ได้จริง

🎯

ทำไมต้องรู้: รู้ทันสองคำนี้จะช่วยให้เราไม่หลงเอาของเล่นไปใช้งานจริง เพราะปล่อยใจตาม vibe อย่างเดียวมักได้งานที่พังตอนใช้จริง

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

รู้ที่มาของคำว่า vibe coding ที่ Karpathy เป็นคนพูดขึ้น (ก.พ. 2025) และมันค่อย ๆ กลายมาเป็น agentic engineering ได้ยังไง
แยกออกว่า vibe coding ต่างจากการเขียนโปรแกรมแบบอัตโนมัติ (automatic programming) ยังไง ตามที่ antirez นิยามไว้
เข้าใจว่าความเชี่ยวชาญของมนุษย์คือส่วนผสมชี้ขาด

เนื้อหา

Andrej Karpathy เป็นคนตั้งคำว่า vibe coding ขึ้นมาเมื่อเดือนกุมภาพันธ์ 2025 เขานิยามว่ามันคือการ "ปล่อยใจไปกับ vibe ลืมไปเลยว่ามีโค้ดอยู่" เหมาะกับต้นแบบ (prototype) ที่ทำเล่น ๆ ทิ้ง ๆ ขว้าง ๆ แต่พอถึงปี 2026 เจ้าตัวเองกลับบอกว่า vibe coding เริ่มเชยแล้ว และหันมาใช้คำว่า agentic engineering แทน คือเราเปลี่ยนบทบาทมาเป็นคนกำกับวงให้ผู้ช่วย AI (agent) ทำงานประสานกัน และคอยตรวจดูแล (oversight) แทนที่จะลงมือเขียนโค้ดเอง คำว่า engineering สื่อว่ามันต้องมีวินัยและความเชี่ยวชาญจริง ๆ อยู่เบื้องหลัง เขาบอกว่าตอนนี้โค้ดของเขาราว 80% เป็นฝีมือ AI ทำ ส่วน antirez คนที่สร้าง Redis แยกให้คมขึ้นว่า vibe coding คือการส่งงานทั้งที่ยังไม่เข้าใจ ต่างจากการเขียนโปรแกรมแบบอัตโนมัติ (automatic programming) ที่ได้งานคุณภาพสูง เพราะยังยึดตามภาพที่ผู้เขียนตั้งใจไว้ (vision) อย่างเคร่งครัด เพียงแต่ใช้ AI เป็นมือช่วยลงมือเท่านั้น เขาย้ำว่า "ความเชี่ยวชาญเชิงลึกในเรื่องที่เขาทำ คือส่วนผสมที่ขาดไม่ได้" บทเรียนสำหรับมือใหม่คือ vibe coding มันสนุกและเหมาะกับการทำต้นแบบ แต่ห้ามเอาไปใช้ตัดสินใจส่งของจริงทั้งที่ยังไม่เข้าใจเด็ดขาด

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

vibe codingการปล่อยให้ AI เขียนโค้ดตามอารมณ์โดยเราแทบไม่อ่านโค้ดเลย เน้นความไว เหมาะกับงานลองเล่นทิ้ง ๆ ขว้าง ๆ

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

prototypeต้นแบบที่ทำเร็ว ๆ ไว้ลองไอเดีย ยังไม่ใช่ของจริงที่พร้อมใช้ เหมือนโมเดลบ้านจำลองที่ยังไม่ใช่บ้านจริง

orchestrateการกำกับวงให้ทุกส่วนทำงานประสานกัน เหมือนวาทยกรคุมวงดนตรีให้เล่นพร้อมกันสวยงาม

oversightการกำกับดูแลตรวจสอบงานที่ AI ทำ ให้แน่ใจว่าถูกต้องและปลอดภัยก่อนเอาไปใช้จริง

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

แยก vibe coding กับ automatic programming

สถานการณ์: คุณให้ Lovable สร้างแอปทั้งแอปจาก prompt เดียว กด deploy ทันทีโดยไม่เปิดดูโค้ด แล้วประกาศว่าพร้อมใช้จริงกับลูกค้า — นี่คืออะไร และเสี่ยงอย่างไร

✅ ผลลัพธ์ที่ได้

นี่คือ vibe coding แบบเต็มขั้น (ส่งของโดยไม่เข้าใจ) เหมาะกับ demo แต่ไม่เหมาะกับ production เพราะคุณไม่รู้ว่ามี hardcoded secret, input ที่ไม่ถูก sanitize หรือ package ปลอมซ่อนอยู่ไหม — automatic programming จะยังคุม vision และตรวจผลลัพธ์ก่อนส่ง

💡 จุดสอน

เส้นแบ่งไม่ได้อยู่ที่ 'ใช้ AI หรือไม่' แต่อยู่ที่ 'คุณยังเข้าใจและควบคุมผลลัพธ์อยู่หรือไม่' ผู้เริ่มต้นควรใช้ vibe coding เพื่อเรียนรู้ ไม่ใช่เพื่อส่งมอบ

แบบฝึกหัดท้ายโมดูล

อ่านนิยาม vibe coding ของ Karpathy ปี 2025 เทียบกับจุดยืนปี 2026 แล้วสรุปด้วยคำพูดตัวเองว่าอะไรเปลี่ยนไปและทำไม
ยกงานของคุณเองมาหนึ่งชิ้น ระบุว่าถ้าทำแบบ vibe coding จะเป็นอย่างไร และถ้าทำแบบ automatic programming จะต่างกันตรงไหน

1.4

โมดูล 1.4

สร้างแอปแรกด้วย Prompt-to-App

เลือกเครื่องมือให้ตรงเป้าและสร้างทีละฟีเจอร์

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนสั่งทำเสื้อผ้า แค่บอกช่างว่าอยากได้แบบไหน (prompt) เดี๋ยวได้เสื้อออกมา (app) แต่ต้องเลือกช่างให้ตรงงาน อยากได้ชุดสวยไปงานก็ร้านหนึ่ง อยากได้ชุดทำงานครบเซตก็อีกร้าน

🎯

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

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

ใช้สูตรลัดในหัว (heuristic) เลือกได้ว่างานนี้ควรใช้ v0, Bolt, Lovable หรือ Replit ตัวไหน
สร้างแอปด้วยการอธิบายเป็นภาษาธรรมดา ทีละฟีเจอร์ ไม่ใช่ก้อนเดียว
ใช้ตัวต่อเชื่อมสำเร็จรูป (integration) ของฐานข้อมูลและระบบล็อกอิน (auth) ที่เครื่องมือมีให้ แทนที่จะไปทำเองทั้งหมด

เนื้อหา

นี่คือโมดูลแรกที่ได้ลงมือทำจริง เริ่มจากสูตรลัดในการเลือกเครื่องมือ: อยากได้หน้าตาสวย ๆ → เลือก v0 (ของ Vercel เก่งสุดเรื่อง React/Next.js/Tailwind/shadcn); อยากได้แอปครบทั้งหน้าบ้านหลังบ้าน หรือทำแอปมือถือ → เลือก Bolt.new (ของ StackBlitz ทำงานในเบราว์เซอร์ มี Git และต่อ Supabase ได้); ไม่ใช่สายเทคนิคแต่ต้องมีฐานข้อมูล → เลือก Lovable (ต่อ Supabase ได้ มีระบบล็อกอินมาให้ ขึ้นออนไลน์ง่าย คิดเงินแบบเครดิต); อยากได้ที่ที่สร้าง เก็บ และขึ้นออนไลน์ได้ครบจบในที่เดียว → เลือก Replit ที่มีตัว Agent 3 คอยสร้างแอปให้ครบทั้งระบบจากคำสั่งภาษาคน แถมยังลองกดใช้ผ่านเบราว์เซอร์เพื่อทดสอบตัวเองได้ด้วย (คือทำรายงานเสร็จแล้วแก้ให้เองเลย) หลักปฏิบัติที่สำคัญที่สุดคือ "ค่อย ๆ สร้างทีละฟีเจอร์ อย่าสั่งทั้งแอปในคำสั่งเดียว" เพราะพอสั่งเป็นก้อนใหญ่ทีเดียว ผลลัพธ์มักเพี้ยนและตามหาบั๊กยาก และให้ใช้ตัวต่อเชื่อมสำเร็จรูป (Supabase หรือระบบล็อกอิน) แทนการทำเองทั้งหมด เพื่อลดช่องโหว่ อีกเรื่องที่ต้องเตือนคือราคาที่เปลี่ยนบ่อย เช่น Bolt Pro ราว $20/เดือน (~10M tokens), Lovable Pro ราว $25/เดือน ที่เครดิตหมดเร็วมากจนอาจทำได้แค่หน้าแรก (landing page), และ Replit Core $20/เดือน ที่คิดเงินตามปริมาณงานที่ใช้จริง

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Prompt-to-Appการพิมพ์บอกความต้องการเป็นภาษาคน แล้ว AI สร้างแอปให้เลย ไม่ต้องเขียนโค้ดเอง

heuristicหลักคิดหรือกฎง่าย ๆ ไว้ช่วยตัดสินใจเร็ว ๆ เหมือนสูตรลัดในหัวว่างานแบบนี้ควรใช้อันไหน

full-stackแอปที่ครบทั้งหน้าบ้าน (ส่วนที่ผู้ใช้เห็น) และหลังบ้าน (ระบบและฐานข้อมูลเบื้องหลัง) จบในตัวเดียว

database (ฐานข้อมูล)ที่เก็บข้อมูลของแอปอย่างเป็นระเบียบ เช่น รายชื่อผู้ใช้ รายการสินค้า เหมือนตู้เก็บเอกสารที่ค้นหาได้ไว

deployการนำแอปที่ทำเสร็จขึ้นออนไลน์ให้คนอื่นเข้าใช้งานได้จริง เหมือนเปิดร้านให้ลูกค้าเข้ามาได้

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

prompt สร้างแอปทีละฟีเจอร์ใน Lovable

สร้างแอปจัดการรายการสั่งซื้อ เริ่มจากฟีเจอร์แรกก่อน: หน้าแสดงรายการสินค้าเป็นตาราง มีคอลัมน์ ชื่อสินค้า ราคา จำนวนคงเหลือ ใช้ Supabase เป็นฐานข้อมูล ยังไม่ต้องทำหน้าอื่น ให้ตั้งตาราง products ใน Supabase พร้อม seed ข้อมูลตัวอย่าง 5 แถว

✅ ผลลัพธ์ที่ได้

Lovable สร้างตาราง products บน Supabase, หน้า UI แสดงข้อมูลจริง 5 แถว และ auth ตั้งต้นให้ — จากนั้นค่อยสั่งฟีเจอร์ถัดไป (เพิ่มสินค้า/แก้ไข) เป็นรอบใหม่

💡 จุดสอน

การแตกงานเป็นฟีเจอร์ย่อยทำให้ตรวจสอบได้ทีละก้อนและแก้ทางได้เร็ว การใช้ Supabase สำเร็จรูปแทนการเขียน backend เองช่วยลดโอกาสสร้างช่องโหว่ที่ prompt-to-app มักพลาด

แบบฝึกหัดท้ายโมดูล

เลือกโจทย์แอปของตัวเองหนึ่งเรื่อง ใช้ heuristic ตัดสินว่าจะใช้ v0/Bolt/Lovable/Replit ตัวไหน เขียนเหตุผลสามบรรทัด แล้วลงมือสร้างฟีเจอร์แรกจริง
ลองสั่งสร้างทั้งแอปในคำสั่งเดียว เทียบกับสั่งทีละฟีเจอร์ แล้วบันทึกว่าแบบไหนได้ผลดีกว่าและเพราะอะไร

1.5

โมดูล 1.5

อ่านและตรวจผลลัพธ์ AI เบื้องต้น

ไม่ต้องเขียนโค้ดเป็น ก็ต้องตรวจของอันตรายให้เป็น

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนซื้อของกินสำเร็จรูป ถึงหน้าตาจะดูน่ากินแต่เราก็ต้องอ่านฉลากและดมดูก่อนว่าปลอดภัยไหม แค่ 'ดูใช้ได้' ไม่ได้แปลว่าปลอดภัยเสมอ

🎯

ทำไมต้องรู้: โค้ดที่ AI สร้างมีโอกาสมีช่องโหว่มากกว่าโค้ดคนเขียน ถ้าเราตรวจของอันตรายเป็น จะกันปัญหาใหญ่อย่างข้อมูลรั่วหรือถูกแฮ็กได้ตั้งแต่ต้น

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

เข้าใจว่า AI มัน "มั่นใจแม้ตอนที่ตอบผิด" และงานที่ดูดี ๆ ก็อาจซ่อนบั๊กไว้ได้
รู้จักช่องโหว่ยอดฮิตของโค้ดที่ AI สร้าง ในระดับที่คนไม่เขียนโค้ดก็ตรวจเองได้
รู้ว่าก่อนจะเปิดใช้จริง (go live) ต้องขอตรวจความปลอดภัย (security pass) หรือให้นักพัฒนา (dev) ช่วยดูอะไรบ้าง

เนื้อหา

มือใหม่มักคิดว่าถ้าแอป "ดูใช้งานได้" ก็แปลว่าเสร็จแล้ว ซึ่งความคิดนี้อันตรายมาก โมดูลนี้จะบอกความจริงจากงานวิจัยหลายชิ้นในปี 2026 ว่าโค้ดที่ AI สร้างเสี่ยงกว่าโค้ดที่คนเขียนแบบเห็นได้ชัด (CodeRabbit ประเมินไว้ว่าเสี่ยงกว่าราว 1.7 เท่าโดยรวม) ตัวเลขแต่ละที่จะต่างกันไปตามวิธีวิจัย (บางเจ้าว่าปลอดภัยแค่ราว 10.5% บางเจ้าว่ามีช่องโหว่ถึง 25.1%) แต่ทิศทางตรงกันหมดว่ามันเสี่ยงกว่าจริง ช่องโหว่ที่เจอบ่อยและอธิบายให้คนไม่เขียนโค้ดฟังเข้าใจได้มีอยู่สามอย่าง หนึ่งคือ กุญแจลับ (API key) ที่ถูกเขียนฝังตรง ๆ ไว้ในโค้ดฝั่งผู้ใช้ ใครเปิดดูก็เจอ สองคือ ข้อมูลที่ผู้ใช้กรอกเข้ามาแล้วแอปไม่ได้กรองก่อน และสามคือ ปัญหาที่ AI มั่วชื่อของเสริมที่ไม่มีอยู่จริงขึ้นมา (slopsquatting) ซึ่งพบราว 19.7% แล้วคนไม่หวังดีอาจแอบไปจดชื่อนั้นเอาไว้ ก่อนยัดโปรแกรมอันตราย (malware) เข้ามาแทน เพราะฉะนั้นก่อนเปิดใช้จริงทุกคนต้องขอตรวจความปลอดภัย (security pass) อย่างน้อยสามข้อนี้: กุญแจลับที่ฝังไว้ในโค้ด, ข้อมูลกรอกที่ยังไม่ถูกกรอง, และของเสริมที่ยังไม่ได้ยืนยันว่ามีอยู่จริง

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

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

โค้ด (code)ชุดคำสั่งที่บอกให้คอมพิวเตอร์ทำงาน เหมือนสูตรอาหารที่เขียนบอกทุกขั้นตอน

CodeRabbitเครื่องมือ AI ที่ช่วยตรวจทานโค้ดให้ คอยหาจุดผิดและจุดเสี่ยง เหมือนบรรณาธิการคอยตรวจต้นฉบับ

งานวิจัย (research)การศึกษาเก็บข้อมูลอย่างเป็นระบบเพื่อหาข้อสรุปที่เชื่อถือได้ ไม่ใช่แค่ความรู้สึกส่วนตัว

นัยสำคัญ (significant)ความต่างที่มากพอจนถือว่ามีความหมายจริง ไม่ใช่บังเอิญเล็กน้อย ควรใส่ใจ

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ตรวจ hardcoded secret ในโค้ดที่ Bolt สร้าง

ให้ Bolt/Lovable อธิบาย: 'ในโค้ดที่สร้างมา มี API key, รหัสผ่าน หรือ secret อะไรที่ถูกเขียนตรง ๆ ในไฟล์ฝั่ง client บ้าง ถ้ามีให้ย้ายไปเป็น environment variable และบอกฉันว่าต้องตั้งค่าตรงไหน'

✅ ผลลัพธ์ที่ได้

เครื่องมือชี้จุดที่มี key ฝังอยู่ (เช่นใน config หน้า frontend) และเสนอย้ายไปเป็น env var — ผู้ใช้เห็นชัดว่าเดิมใครเปิด dev tools ก็อ่าน key ได้

💡 จุดสอน

แม้เขียนโค้ดไม่เป็น ก็สั่งให้ AI ตรวจตัวเองในเรื่องที่ตรวจได้ชัด ๆ ได้ แต่ต้อง 'ถามให้เจาะจง' ไม่ใช่ถามลอย ๆ ว่า 'ปลอดภัยไหม' เพราะมันจะตอบว่าปลอดภัยทั้งที่ไม่

แบบฝึกหัดท้ายโมดูล

ใช้แอปที่คุณสร้างในโมดูล 1.4 สั่งเครื่องมือตรวจหา hardcoded secret และ input ที่ไม่ถูกกรอง แล้วบันทึกว่าเจออะไรบ้าง
ทำ checklist สามข้อ (secrets / unsanitized input / unverified package) เป็นภาษาของตัวเอง สำหรับใช้ก่อน go live ทุกครั้ง

1.6

โมดูล 1.6

บริบทไทย: เมื่อไรใช้ ThaiLLM

ทำแอปภาษาไทยให้ดีขึ้นและถูกลงด้วยโมเดลของไทยเอง

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนเลือกใช้วัตถุดิบท้องถิ่นที่เข้าใจลิ้นคนไทย ทำอาหารไทยได้อร่อยกว่าและถูกกว่าวัตถุดิบนำเข้า ThaiLLM คือโมเดล AI ที่เข้าใจภาษาไทยดีเป็นพิเศษ

🎯

ทำไมต้องรู้: ถ้าแอปเราต้องใช้ภาษาไทยเยอะ การเลือกโมเดลไทยช่วยให้ผลลัพธ์ดีขึ้น ประหยัดกว่า และข้อมูลอยู่ในประเทศ ปลอดภัยตามกฎหมายไทย

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

รู้จัก ThaiLLM และโมเดลย่อย (sub-model) ตัวหลัก ๆ (OpenThaiGPT, Pathumma, Typhoon, THaLLE)
เข้าใจว่าควรหยิบ ThaiLLM มาใช้กับฟีเจอร์ภาษาไทยตอนไหน ไม่ใช่เอาไปแทนโมเดลที่ใช้เขียนโค้ด
เข้าใจเรื่องการเก็บข้อมูลไว้ในประเทศ และการประหยัดค่าใช้จ่ายสำหรับงานภาษาไทย

เนื้อหา

สำหรับคนไทยที่จะสร้างแอป เรามีตัวเลือกเป็นโมเดลของไทยเองที่เรียกใช้ผ่าน API ได้ ThaiLLM เปิดตัวโดย NSTDA/NECTEC รันอยู่บนซูเปอร์คอมพิวเตอร์ ThaiSC ของไทย (ข้อมูลจึงอยู่ในประเทศ) มีให้เลือกทั้งขนาด 8B และ 30B และที่ดีคือใช้งานร่วมกับ OpenAI SDK ได้ เลยเอาเครื่องมือเดิมมาต่อได้เลยแทบไม่ต้องแก้อะไร โมเดลย่อยตั้งต้นได้แก่ OpenThaiGPT-ThaiLLM-8B (AIEAT), Pathumma-ThaiLLM (NECTEC), Typhoon-S-ThaiLLM-8B (SCB 10X), THaLLE (KBTG) จุดเด่นคือรับมือภาษาไทยได้ดีกว่าโมเดลต่างชาติ ทั้งภาษาทางการและคำสแลง แถมช่วยเรื่องเก็บข้อมูลไว้ในประเทศให้ถูกกฎหมาย และถูกกว่ากันเยอะสำหรับงานภาษาไทย (อย่างเคส Typhoon voice-AI ลดค่าใช้จ่ายลงราว 8 เท่า) หลักที่ต้องจำคือ ให้ใช้ ThaiLLM กับ "ฟีเจอร์ภาษาไทยตอนใช้งานจริง และงานประมวลผลภาษาที่ต้องคุมค่าใช้จ่าย" เช่น แชตบอต ข้อความโฆษณา เนื้อหาสินค้า — ไม่ใช่เอาไปแทนโมเดลตัวท็อป (frontier model) ในการเขียนตัวโค้ด

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

ThaiLLMโมเดล AI ภาษาไทยที่พัฒนาในไทย เข้าใจภาษาและบริบทไทยได้ดีกว่าโมเดลต่างชาติ

โมเดลอธิปไตย (sovereign model)โมเดล AI ที่ประเทศเราเป็นเจ้าของและควบคุมเอง ข้อมูลไม่ต้องส่งออกไปต่างประเทศ

APIช่องทางให้แอปเราเรียกใช้บริการ AI จากที่อื่น เหมือนช่องสั่งอาหารที่เราสั่งแล้วได้ของกลับมาโดยไม่ต้องเข้าครัวเอง

8B / 30Bขนาดของโมเดล (จำนวนพารามิเตอร์เป็นพันล้าน) ยิ่งตัวเลขมากยิ่งฉลาดแต่ก็กินทรัพยากรมากกว่า เหมือนเครื่องยนต์ที่แรงขึ้นแต่กินน้ำมันมากขึ้น

compatible กับ OpenAI SDKใช้งานร่วมกับเครื่องมือมาตรฐานที่คนใช้กับ AI เจ้าดังได้เลย ไม่ต้องรื้อของเดิม เหมือนอุปกรณ์ที่เสียบปลั๊กเดิมได้พอดี

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

วางแผนใช้โมเดลแบบ hybrid

โจทย์: แอปตอบแชทลูกค้าภาษาไทยของร้านค้า อยากได้ทั้งโค้ดที่ดีและตอบไทยเป็นธรรมชาติในราคาประหยัด — ควรใช้โมเดลอะไรทำอะไร

✅ ผลลัพธ์ที่ได้

ใช้โมเดลตัวท็อป (frontier model — Claude/GPT/Gemini) สร้างตัวโค้ดแอปและตรรกะการทำงาน; ใช้ ThaiLLM (เช่น Typhoon/OpenThaiGPT) เป็นตัวตอบแชทภาษาไทยตอนใช้งานจริง เพื่อให้ภาษาดีและประหยัด; เก็บข้อมูลลูกค้าไว้ในไทยเพื่อให้ถูกกฎหมาย

💡 จุดสอน

อย่ามองหาโมเดลเดียวทำทุกอย่าง แยกหน้าที่: โมเดลเก่งโค้ดทำโค้ด โมเดลไทยทำภาษาไทย เป็นการออกแบบที่ทั้งดีและประหยัด

แบบฝึกหัดท้ายโมดูล

ระบุในแอปของคุณว่าส่วนไหนเป็น 'ฟีเจอร์ภาษาไทย runtime' ที่ควรใช้ ThaiLLM และส่วนไหนเป็น 'การเขียนโค้ด' ที่ควรใช้ frontier model
อ่านว่า ThaiLLM compatible กับ OpenAI SDK แล้วสรุปว่าทำไมสิ่งนี้ทำให้ทีมไทยเปลี่ยนมาใช้ได้ง่าย

🎯 Mini-Project: แอปภาษาไทยที่ผ่าน Security Checklist

เลือกโจทย์แอปจริงมาหนึ่งเรื่อง (เช่น ระบบจองคิว, จัดการสต็อกร้านเล็ก, หรือแชตบอตตอบลูกค้าไทย)
เลือกเครื่องมือสร้างแอปจากคำพิมพ์ (prompt-to-app) โดยใช้สูตรลัด (heuristic) ที่เรียนมา (v0/Bolt/Lovable/Replit) พร้อมเขียนเหตุผลที่เลือก
ค่อย ๆ สร้างแอปทีละฟีเจอร์ อย่างน้อย 3 ฟีเจอร์ ใช้ตัวต่อเชื่อม Supabase หรือฐานข้อมูล และระบบล็อกอินที่เครื่องมือมีให้ ไม่ต้องทำเองทั้งหมด
ถ้ามีฟีเจอร์ภาษาไทยที่ทำงานตอนใช้จริง (runtime) ให้ออกแบบว่าจะต่อ ThaiLLM ตรงไหน (วาดเป็นแผนผังแบบผสม (hybrid) ก็ได้)
ก่อนส่ง ให้ตรวจความปลอดภัย (security pass): หากุญแจลับที่ฝังในโค้ด, ข้อมูลกรอกที่ยังไม่ถูกกรอง และเช็กว่าของเสริม (package) ทุกตัวมีอยู่จริง พร้อมจดสิ่งที่เจอและวิธีแก้
ส่งมอบ: ลิงก์แอปที่ขึ้นออนไลน์ (deploy) แล้ว พร้อมเอกสารสั้น ๆ อธิบายว่าเลือกเครื่องมืออะไร, แผนใช้โมเดลแบบผสม (hybrid) และผลการตรวจความปลอดภัย

ก้าวต่อไป

เร่งงานจริงด้วย IDE Agent อย่างมีวินัย

ไปต่อ →