ถ้าบทความก่อนเล่าว่า ใคร สร้างบล็อกนี้ (Muse Code) บทความนี้จะเล่าว่า วิธีคิด ที่คุมมันชื่ออะไร คำตอบคือปลั๊กอินชื่อ 8-habit-ai-dev สโลแกนของมันคือ "Stop vibe coding" คือหยุดพฤติกรรมสั่ง AI เขียนโค้ดเลยโดยไม่คิด ด้วย 24 skills 7 ขั้นตอน และ 8 habits จากหลักการของ Covey ดูโปรเจกต์ได้ที่ pitimon/8-habit-ai-dev
ปัญหาที่มันแก้
Vibe coding คือการกระโดดเข้าโค้ดทันทีโดยไม่นิยามว่าเสร็จคืออะไร ไม่ค้นคว้าก่อน ไม่รีวิวก่อน commit ไม่วางแผน deploy แล้วไปจ่ายต้นทุนทีหลังตอนแก้บั๊กกับ rollback ปลั๊กอินนี้แก้ด้วยการผูกแต่ละขั้นตอนเป็น skill โดยแต่ละ skill จะบอกว่าต้องการอะไรจากขั้นก่อน และส่งอะไรให้ขั้นต่อไป
7 ขั้นตอนมีอะไรบ้าง
| ขั้น | Skill | ใจความ |
|---|---|---|
| 0 | research | ศึกษาก่อนกำหนด ห้ามนิยาม requirement ลอยๆ |
| 1 | requirements | นิยามว่า done คืออะไรก่อนแตะโค้ด |
| 2 | design | ตัดสินใจสถาปัตยกรรม (คนตัดสิน AI เสนอ) |
| 3 | breakdown | แตกงานเป็นชิ้นเล็กพร้อม dependency |
| 4 | build-brief | เตรียมบริบทก่อนเขียนโค้ดแต่ละชิ้น |
| 5 | review-ai | ตรวจโค้ดที่ AI เขียนก่อน commit (ห้ามข้าม) |
| 6 | deploy-guide | วางแผน deploy แบบ staging-first พร้อม rollback |
| 7 | monitor-setup | ตรวจสุขภาพ alerting และ error tracking |
กฎที่ชอบที่สุดคือ honest skip rule ถ้าอธิบายออกเสียงได้ว่าทำไมถึงข้ามขั้นนั้น ก็ข้ามได้ แต่ถ้าอธิบายไม่ได้ก็ต้องรัน งานแก้บั๊กบรรทัดเดียวไม่ต้องลากทั้ง 7 ขั้น แต่ห้ามข้าม review-ai เด็ดขาด
8 habits คืออะไร
ตัวเลข 8 มาจาก habits ของ Covey แต่ละข้อถูกตีความใหม่เพื่องาน AI:
- H1 Be Proactive โฟกัสสิ่งที่คุมได้ แก้บั๊กแล้วไล่ทุก caller ไม่ใช่แค่จุดที่แจ้ง
- H2 Begin with the End นิยามว่าเสร็จคืออะไรก่อนเริ่ม
- H3 First Things First จัดลำดับก่อนลงมือ
- H4 Think Win-Win ทุกอย่างที่ผลิตคือฝากหรือถอนกับคนถัดไป ปิด issue พร้อมเหตุผลคือฝาก ปิดว่า fixed เฉยๆ คือถอน
- H5 Seek First to Understand อ่านโค้ดเดิมก่อนเขียนใหม่ เพราะบั๊กของ AI ส่วนใหญ่ไม่ใช่โค้ดผิด แต่ถูกโดดเดี่ยวผิดบริบท
- H6 Synergize ผสานความเห็นต่างให้ได้ของที่ดีกว่าเดิม
- H7 Sharpen the Saw ลงทุนในความสามารถในการผลิต (CI test deploy monitoring) ไม่ใช่แค่ผลผลิต
- H8 Find Your Voice จากมีประสิทธิภาพสู่มีความหมาย เอาความรู้ไปแบ่งปัน — ซึ่งก็คือสิ่งที่บล็อกนี้กำลังทำ
รายละเอียดเต็มอยู่ใน Habits-Reference ของ wiki
vibe coding กับแบบมีโครงต่างกันอย่างไร
wiki ของปลั๊กอินมีตารางเทียบไว้ชัด พร้อมประโยคเด็ดว่า "ทำเสร็จ ≠ ทำดี":
| ด้าน | vibe coding | แบบมีโครง |
|---|---|---|
| นิยามปัญหา | prompt ก่อน | requirements ก่อน |
| เจอเรื่องใหม่ | เดา | research |
| สถาปัตยกรรม | โมเดลเลือกเองเงียบๆ | design โดยคนตัดสิน |
| รีวิว | "ดูดีแล้ว" | review-ai พร้อมเช็กลิสต์ |
| deploy | push แล้วลุ้น | deploy-guide พร้อม rollback |
| บทเรียน | จบงานก็หาย | reflect กับ post-mortem |
wiki ยังซื่อสัตย์ว่างานเบาๆ อย่าง script ใช้แล้วทิ้งหรืองานจัด format ไม่ต้องขนชุดใหญ่ (Vibe-Coding-vs-Structured) ซึ่งตรงกับ honest skip rule ข้างบนพอดี
เราเอามาใช้ตรงไหนบ้าง
บล็อกนี้คือหลักฐานการใช้งานจริง งาน jevgrep เริ่มด้วย research จนได้ research brief พร้อมแหล่งอ้างอิงก่อนเขียนบทความ งาน deploy ทุกครั้งเดินตาม deploy-guide คือ preview ก่อน verify แล้วค่อย prod พร้อมแผน rollback ทุกครั้ง
ส่วนบันทึก retrospective หลังงาน Vercel ก็คือหัวใจของ reflect และธรรมเนียม CHANGES.log ใน repo ก็คือวินัยเดียวกับ ai-dev-log ที่ปลั๊กอินสอน
ผลที่รู้สึกได้คือ AI ถามกลับเมื่อ requirement ไม่ชัด เสนอแผนก่อนลงมือ และตรวจงานตัวเองด้วยหลักฐานแทนความมั่นใจ
ชวนมาลอง
ถ้าคุณสั่ง AI เขียนโค้ดแล้วได้ของที่ต้องแก้ซ้ำ หรือกลัวว่ายิ่งสั่งยิ่งเละ ให้เริ่มจาก skill เดียวก็พอ งานใหม่เริ่มที่ research ส่วนงานที่เขียนเสร็จแล้วเริ่มที่ review-ai
ไม่ต้องใช้ทั้ง 24 ตัว (เจ้าของปลั๊กอินเองบอกว่าใช้หมดทุกงานคือ theater) แค่ขั้นเดียวก็เห็นความต่างแล้ว ที่เหลือค่อยเพิ่มตามขนาดงาน