← กลับหน้าภาพรวม
🔄 เวิร์กโฟลว์จริง · WORKFLOW

End-to-End: จากไอเดียสู่ของที่ส่งมอบจริง

หน้านี้เอาทุกอย่างที่สอนมาทั้งหลักสูตร มาร้อยเป็นขั้นตอนการทำงาน (workflow) เดียวที่เดินตามได้จริง มีให้เลือกสองเส้นทาง คือ เส้นทางของนักเขียนโปรแกรม (เร่งงานบนโค้ดของโปรเจกต์จริง) กับเส้นทางของคนที่เขียนโค้ดไม่เป็น (ปั้นตัวอย่างแอปให้เสร็จไว ๆ) แต่ไม่ว่าจะไปทางไหน สุดท้ายก็มาจบที่จุดเดียวกัน คือ ด่านตรวจความปลอดภัย (security gate) ก่อนเปิดให้คนใช้จริง เพราะจุดที่ AI ทำแอปให้จากคำสั่งพิมพ์ (prompt-to-app) และตัว AI ที่ทำงานเองได้ (agent) มักพลาดบ่อยที่สุดคือเรื่องความปลอดภัยนี่แหละ

🛠 ขั้นตอนการทำงานจริง ตั้งแต่ไอเดียจนได้แอปที่ปล่อยออกไปแล้ว

เส้นทางนักเขียนโปรแกรม: เร่งงานบนโค้ดจริง

1) เขียนและคอยดูแลไฟล์ AGENTS.md (หรือ CLAUDE.md) เองด้วยมือ ในนั้นบอกให้ชัดว่าใช้เครื่องมือ/เทคโนโลยีอะไรบ้าง (stack), กติกาการเขียนโค้ด, และอะไรทำได้อะไรห้ามทำ เขียนสั้น ๆ ไม่เกินราว 150 บรรทัด. 2) เริ่มงานด้วยการให้ AI อ่านเอกสารข้อกำหนดของตัวสินค้า (product spec คือเอกสารที่บอกว่าจะทำอะไร ต้องได้อะไรบ้าง) ให้จบก่อน. 3) ใช้โหมดวางแผน (Plan Mode) ให้ AI ร่างข้อกำหนดออกมาเป็นรายการงานย่อย ๆ (task) แล้วเราค่อยกดอนุมัติตรงจุดพักให้ตรวจ. 4) จากนั้นให้ AI ลงมือทำจริงทีละงาน (Agent mode) โดยให้รันการทดสอบ (test) ไปด้วยระหว่างทาง และบังคับให้มันโชว์ผลการทดสอบจริง ๆ มาเป็นหลักฐาน. 5) ให้ AI ช่วยตรวจโค้ด (AI reviewer เช่น CodeRabbit / Qodo / Bugbot) เป็นรอบแรก แล้วให้คนตรวจซ้ำอีกที ก่อนจะปิดท้ายด้วยระบบตรวจและปล่อยงานอัตโนมัติ (CI/CD) พร้อมทดสอบแบบผ่าน ๆ ให้แน่ใจว่ายังใช้งานได้ (smoke test) เป็นด่านสุดท้ายก่อนรวมโค้ดเข้าโปรเจกต์ (merge). 6) ส่วนฟีเจอร์ที่ AI เดาโค้ดต่อให้อัตโนมัติ (autocomplete) เก็บไว้ใช้ตอนเขียนโค้ดง่าย ๆ พื้น ๆ ที่กำลังลื่นมือ ส่วนงานจัดระเบียบโค้ดใหม่หรือไล่จับบั๊กเฉพาะจุด ให้คุยกับ AI ผ่านหน้าแชตแทน.

ตัวอย่าง PROMPT
เริ่ม session: อ่าน AGENTS.md และ docs/product-spec.md ก่อน แล้วสรุปให้ฉันเป็น 3 บรรทัดว่าเข้าใจ stack และข้อห้ามอะไรบ้าง ก่อนจะเริ่ม task แรก

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

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

ตัวอย่าง PROMPT
สร้างทีละฟีเจอร์: เริ่มจากหน้าจัดการสมาชิกก่อน ใช้ Supabase เก็บข้อมูลและ auth ในตัว ตั้งตาราง members พร้อม seed 5 แถว ยังไม่ต้องทำหน้าอื่น

จุดที่ทั้งสองเส้นทางมาเจอกัน: ด่านตรวจความปลอดภัยก่อนเปิดใช้จริง

ไม่ว่าจะมาทางไหน ก่อนส่งมอบของจริงต้องผ่านด่านเดียวกันนี้ทุกคน คือ ไล่หากุญแจลับ/รหัสสำคัญที่เผลอฝังไว้ในโค้ด (แล้วย้ายไปเก็บในที่ที่ปลอดภัยกว่าอย่างตัวแปรลับของระบบ หรือ env var), กรองข้อมูลที่ผู้ใช้กรอกเข้ามาให้สะอาดก่อนใช้ (เพื่อกันการแอบยัดสคริปต์หรือคำสั่งอันตราย เช่น XSS/injection), เช็กทุกชิ้นส่วนที่แอปไปเรียกใช้ (dependency) ว่ามีอยู่จริงและเป็นตัวที่เราตั้งใจใช้ (กันการหลอกให้โหลดของปลอมที่ตั้งชื่อคล้าย ๆ หรือ slopsquatting), และอย่างน้อยต้องรันเครื่องมือสแกนหาช่องโหว่จากตัวโค้ด (SAST) กับสแกนหาช่องโหว่จากชิ้นส่วนที่เอามาใช้ (SCA). ถ้าเป็นงานที่เสี่ยงสูง ให้เพิ่มการทดสอบตอนแอปทำงานจริง (DAST) และให้คนลองสวมบทเป็นแฮ็กเกอร์คอยหาช่องเจาะเข้าไปด้วย. หัวใจสำคัญคือ คำว่า 'ดูเหมือนใช้งานได้' ยังไม่เท่ากับ 'เสร็จแล้ว' — มันต้องมีหลักฐานและผ่านด่านตรวจจริง ๆ ถึงจะนับว่าเสร็จ.

ตัวอย่าง PROMPT
ทำ security audit ก่อน deploy: ตรวจตาม OWASP Top-10 เฉพาะ (1) hardcoded secret (2) unsanitized input/XSS (3) SQL injection (4) dependency ทุกตัวมีอยู่จริงบน registry ไหม — ชี้บรรทัดและเสนอแพตช์ อย่ารับรองว่าปลอดภัยถ้ายังตรวจไม่ครบ

สำหรับงานไทย: จะเอา ThaiLLM มาต่อตรงไหนดี

ถ้าแอปของเรามีฟีเจอร์ที่ต้องใช้ภาษาไทยตอนคนใช้งานจริง (เช่น แชตบอตตอบลูกค้า, สรุปข้อความยาว ๆ, หรือข้อความที่แสดงบนตัวสินค้า) แนะนำให้เอาโมเดลภาษาไทยอย่าง ThaiLLM มาต่อเข้ากับระบบเดิมผ่านชุดเครื่องมือของ OpenAI (OpenAI SDK) โดยตัวการเขียนโค้ดยังใช้โมเดล AI ตัวเก่ง ๆ ระดับหัวแถว (frontier model) อยู่เหมือนเดิม ข้อดีคือภาษาไทยที่ได้ออกมาลื่นและถูกต้องขึ้น ค่าใช้จ่ายถูกลงเยอะ (อย่างกรณีของ Typhoon ถูกลงราว 8 เท่า) แล้วข้อมูลก็ยังเก็บอยู่ในประเทศ ทำให้ทำตามกฎหมายได้ง่ายกว่า ส่วนพวกเอกสารข้อกำหนดและกฎกติกาที่เขียนให้ตัว AI ทำงาน (spec/rules ของ coding agent) ยังคงเขียนเป็นภาษาอังกฤษไว้เหมือนเดิม เพราะโมเดลจะทำงานได้แม่นยำที่สุด.

ตัวอย่าง PROMPT
ต่อ ThaiLLM (OpenAI-compatible) เป็น provider สำหรับ endpoint สรุปบทสนทนาภาษาไทยเท่านั้น ส่วน logic และโค้ดอื่นคงไว้ตามเดิม แล้วเขียน test ที่ตรวจว่า output เป็นภาษาไทยที่ถูกต้อง
← กลับหน้าภาพรวมหลักสูตร AI Coding