บทเรียน $1,000+ ในเดือนเดียว เมื่อ Prompt แย่ๆ ทำ AI หลอน จนผมต้องรื้อ Workflow การเขียนโค้ดใหม่ทั้งหมด

---

จาก Post ก่อนหน้า ที่ผมเล่าว่าผมคุม AI แบบสายการผลิตในโรงงาน มี Quality Gate มี TDD แล้วก็หั่น ticket ใบละเรื่อง ผมจะมาเล่าว่าตอนแรกผมก็ไม่ได้ทำแบบนี้มาตั้งแต่ตอนแรก ก่อนจะมาเป็น N-Flow Agentic Inception ที่ tune มาจน run งานยาวๆได้ ผมเสียทั้งเวลาเสียทั้งเงินและทำระบบพังจนต้องรื้อใหม่มาหลายรอบ

ไม่ทราบว่า มีใครได้ลองย้อนกลับไปดู Prompt เก่าๆ ของตัวเอง แล้วคิดในใจว่า "ทำไมเราสั่งงาน AI ได้แย่ขนาดนี้" บ้างไหมครับ ผมเคยครับ และบทเรียนรอบนั้นมาพร้อมกับ ticket ที่อ่านไม่รู้เรื่อง โค้ดที่ run ไม่ขึ้น และค่า API 18$+ (ประมาณ 600 กว่าบาท) ใน prompt เดียว รวมทั้งเดือนโดนไปกว่า $1,000

---

โยน Requirement กระจายๆ รวมกันเป็น 10,000 กว่าบรรทัด แล้วบอกให้ AI แตก Task เอง

ตอนนั้นผมคิดง่ายเกินไป ผมเขียน Requirement ก้อนใหญ่ๆ ยาวรวมกันเป็น 10,000 กว่าบรรทัด กระจายอยู่หลายไฟล์ แบบเขียนไปเรื่อยๆ ให้ AI มาช่วยเขียนบ้าง ทั้ง script ทั้งตารางอะไรไม่รู้ นึกอะไรออกก็ใส่ เนื้อหาข้ามไปข้ามมา ไม่ได้เรียงหรือแยกหัวข้อให้ดี แล้วก็สั่ง AI ว่า "แตก Task ออกมาให้หน่อย"

AI ก็แตก task มาให้ได้จริงๆ ได้ ticket มาหลายใบเลย แต่ว่าแต่ละใบอ่านแทบไม่รู้เรื่อง มีเลข reference โยงกันไปโยงกันมาเยอะมาก จนผมอ่านแล้วงงเอง

ตอนนั้นผมก็คิดไปเองว่า "ticket ที่คนอ่านไม่รู้เรื่องเนี่ยแหละ คงเป็นภาษาที่ AI มันคุยกันเอง ต้องเวิร์กแน่ๆ 555" เพราะผมเห็นว่ามันอ้างอิงไฟล์ อ้างอิงบรรทัด มีเลข commit แถมยังอ้างไปถึงจุดที่ผมเคยอนุมัติไว้ด้วย แต่ด้วยความที่มันพันกันไปหมด สุดท้ายผมก็เลยไม่ได้อ่านจริงจังเลย

เนื้อหาใน ticket เท่าที่ผมจำได้คร่าวๆ จะประมาณนี้ครับ

Ticket: T-D-0001 สร้างข้อมูล A0144 ด้วย B1345 แต่ต้องยอมให้ 4456 จาก git diff ที่ 0d12g41 จากนั้นการ Save ต้อง validate V-123 ด้วย V455 ไม่สนใจสิทธิใดๆ ยกเว้น (P-001, P-004, P-005) อ้างอิง file services/dataService.go ที่ Line (123, 125, 264)

---

Gemini Flash บอกว่า "เป็น Ticket ที่ดีมากครับ"

เพื่อความชัวร์ ผมเอา ticket ใบนี้ไปให้ AI ตัวเล็กๆ อย่าง Gemini Flash 3.x ช่วยรีวิวว่าเป็น ticket ที่ดีไหม (ที่เลือกตัวเล็ก เพราะผมคิดว่า ถ้า AI ที่ไม่ได้เก่งที่สุดยังอ่านเข้าใจ แปลว่า ticket เขียนมาดีแล้ว) คำตอบที่ได้คือ

"เป็น Ticket ที่ดีมากครับ มีการอ้างอิงชัดเจน ระบุไฟล์ที่จะแก้ด้วย รวมถึงมีเลข Commit อ้างอิงกับ Codebase เดิม แถมยังมีจุดที่เจ้าของอนุมัติด้วย โดยรวมแล้ว Ticket นี้ดีมากครับ"

ได้เห็นแบบนี้ผมก็ชื่นใจ หวานเจี๊ยบเลยครับ (ตอนนี้ย้อนกลับไปคิดผมยังฮาตัวเองอยู่เลย ticket ก็เละ รีวิวก็ชมซ้อนเข้าไปอีก ถ้าเอาไปให้ Claude roast คงโดนด่าไปแล้ว) วาดฝันไปใหญ่เลยว่า ต่อไปแค่โยนงานให้มัน สั่งว่าไม่ต้องถาม ให้อนุมัติตามคำแนะนำไปจนจบงาน (เพราะอยาก run งานต่อเนื่องยาวๆ) แล้วรอดูผลทีเดียว

ตรงนี้แหล่ะครับที่ผมเรียกว่า AI หลอน ผมก็หลอน (หลอน หรือ hallucination คือการที่ AI ตอบหรือสร้างงานออกมาอย่างมั่นใจ ทั้งที่มันผิดหรือไม่มีความหมาย) AI ตัวแรกแตก ticket ออกมามั่ว AI ตัวที่สองชมว่าดี ส่วนผมก็เชื่อทั้งสองตัว

---

จับ Ticket ลงเครื่องบดหมู

พอมั่นใจเต็มที่ ผมก็เริ่มจับ ticket เข้าเครื่องบดเลยทีนี้ วิธีที่ผมทำตอนนั้นคือสั่งทำ ticket ทีละ 3-5 ใบพร้อมกัน เหมือนโยนเนื้อหมู 3-5 ก้อนเข้าเครื่องบดหมู กะว่าปล่อย run ข้ามคืน ตื่นมางานเสร็จเนียนๆ แน่นอน

และผลที่ได้คือ....

เละ!!!

ถูกต้องนะคร๊าบบบ... เละเป็นหมูบดสมชื่อเลยครับ AI ปิดงานโดยไม่รู้ด้วยซ้ำว่าตัวเองเขียนอะไรลงไป ผมเองเขียนโค้ดมาเป็นสิบๆ ปี ทั้ง frontend และ backend ยังอ่านไม่ออกเลยว่ามันเขียนอะไร งานนี้ทำอะไร และ run ไม่ขึ้นด้วยซ้ำ จนไม่รู้จะเริ่มแก้ตรงไหน

---

ทำไมหน่ะหรอครับ

พอเข้าไปไล่ดูว่าทำไมถึงเละ ผมสรุปได้ว่าต้นเหตุคือการสั่งงานแบบยำรวมไปหมด ใน ticket เดียวมีทั้งทำ A ทำ B ทำ C พอ AI ทำตาม logic ใน service ก็ปนกันไปหมด context ที่มันต้องจำก็ปนกันจนเลอะ

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

แต่ AI ของผมตอนนั้นเอาห้องผ่าตัดกับห้องอาหารมารวมกันเลยครับ หยิบมีดผ่าตัดมาหั่นผัก แล้วเอามีดเล่มเดิมไปผ่าคนไข้ต่อ ผลที่ตามมาก็เช่น

• Solution ออกทะเล: แก้ไม่ตรงจุด หรือทำอ้อมโลกกว่าจะถึง
• UI พัง: โครงที่ผมขึ้นไว้ก็พังไปด้วย
• Unit Test แบบ Always True: (การทดสอบที่ผ่านเสมอ ไม่ว่าโค้ดจะถูกหรือผิด) บางเคสถ้าไม่มีข้อมูลก็ถือว่าผ่าน test ผ่านหมดนะครับ แต่โปรแกรมใช้ไม่ได้ คงอารมณ์ว่า อยากให้เทสผ่านนักใช่ไหม เดี๋ยวจัดให้ แบบนี้มั้งครับ

และอื่นๆ อีกเยอะแยะเต็มไปหมด

---

18$+ ใน Prompt เดียว หลายๆรอบ จนคิดได้

ถ้าพูดถึงความล้มเหลว อีกเรื่องที่ข้ามไม่ได้เลยคือ cost ครับ

ตอนนั้นผมใช้ Cline เป็นหลัก (ยังไม่ได้ใช้ Claude Code) แล้วต่อ API Key แบบ BYOK (Bring Your Own Key คือเอา key ของเราเองมาใส่ แล้วจ่ายตามที่ใช้จริง) แบบ On-Demand และเลือก model ตัวอย่าง Claude Opus (ราคาอยู่ที่ประมาณ $4 / $20 per 1M Token)

ผมโยน Requirement ก้อนใหญ่ที่ไม่ได้แยกหัวข้อก้อนนั้นเข้าไป สรุปว่าแค่ prompt เดียว กินเงินผมไป 18$+ เป็นเงินไทยก็ประมาณ 600 กว่าบาท แถมผลที่ได้ก็เอาไปใช้อะไรไม่ได้มาก ปรับไปปรับมาแบบไม่มีทิศทาง และไม่ได้โดนแค่ครั้งเดียวด้วยครับ ผมทำแบบนี้ซ้ำๆอยู่หลายรอบกว่าจะรู้ตัว

พอมาดูยอดรวมทั้งเดือนแล้วยิ่งเจ็บครับ เดือนกันยายน 2026 ค่า AI แบบ On-Demand ของผมรวมแล้ว 1,190$ กว่าๆ (ประมาณ 4 หมื่นบาท) และไม่ได้มีแค่ Claude นะครับ ตอนนั้นผมลองใช้หลายค่ายหลาย model ส่วนเดือนกรกฎาคมกับสิงหาคมก็โดนไป 244$ และ 206$ แต่กันยายนคือหนักสุด

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

เรื่องนี้ทำให้ผมเห็นอีกอย่างคือ ถ้าใช้ AI แบบ Subscription รายเดือน ผู้ใช้อย่างเราได้กำไรเยอะมาก เพราะค่าย AI ยอมแบกต้นทุนการประมวลผลไว้ให้ ส่วนแบบ API On-Demand นั่นแหล่ะครับคือราคาจริงของ AI ซึ่งแพงกว่ากันเยอะมากๆ หลังจากรอบนั้นผมไม่เสียดายค่า Subscription รายเดือนเลย

---

ผมรื้อใหม่ทั้งหมด

จากบทเรียนราคาแพง ทำให้ผมรื้อ workflow ใหม่ทั้งหมด จนกลายเป็นแกนหลักของ N-Flow Agentic Inception ที่ผมใช้อยู่ทุกวันนี้

• การรื้อ Requirement ใหม่: ต้องละเอียด แยกหัวข้อชัด และมีข้อบังคับที่รัดกุม ไม่ใช่นึกอะไรออกก็เขียน
• การหั่น ticket ให้เล็ก (Micro-batching): ticket ละเรื่องเดียว สั่งงานชัดเจน ตรวจสอบได้ และผลลัพธ์ต้องมีหลักฐาน
• การบังคับทำ TDD (Test-Driven Development): ให้ AI เขียน test จาก testcase ที่กำหนดใน task ก่อน และบังคับให้ test นั้น fail ก่อนเสมอ เพื่อพิสูจน์ว่า test จับผิดได้จริง แล้วค่อยให้ AI เขียนโค้ดจนผ่านทั้งหมด (ตัวนี้แหล่ะที่ปิดปัญหา Always True)
• การเลือก model ให้เหมาะกับงาน: ปรับ workflow ให้ AI Agent เลือก model ที่แปรผันตามความยากของงาน ไม่ใช่ใช้ตัวท็อปกับทุกอย่าง

ถ้าเพื่อนๆ อ่านตอนที่แล้ว จะเห็นว่าสายการผลิต ticket ละเรื่อง TDD ที่มี evidence และ Quality Gate ที่ผมเล่า ทั้งหมดมาจากแผลรอบนี้นั่นเองครับ

แน่นอนว่าการรื้อรอบนั้นไม่ได้ทำให้ AI หายหลอนไปเลย มันยังหลอนได้เสมอ สิ่งที่เปลี่ยนคือผมจับได้เร็วขึ้น ticket เล็กพอที่คนอ่านรู้เรื่อง test ต้องมีหลักฐานทั้งตอน fail และตอน pass และงานบางงานที่ยังไม่เคลียร์ก็ยังต้องมีคนตรวจอยู่ดี

---

ค่าใช้จ่ายหลังรื้อ workflow

หลังจากรื้อ workflow ยอดเดือนตุลาคมกับพฤศจิกายนลดลงเหลือนิดเดียว แต่ผมต้องแยกให้ชัดเจนว่าลดเพราะอะไรครับ

• ตัวหลักคือย้ายไปใช้แบบ Subscription: ผมย้ายมาใช้ Claude Code แบบรายเดือนเป็นหลัก แล้วลดการใช้ On-Demand ลง จุดเปลี่ยนคือตรงนี้
• workflow ใหม่ลดค่า token ต่องาน: จากเดิมที่ตกประมาณ 1-2$ ต่อ task ตอนนี้เหลือประมาณ 0.07-0.22$ ต่อ ticket แล้วแต่ model ที่เลือก

ตัวอย่างจากตารางเทียบล่าสุด ผม run ticket เดียวกันในงานระบบ Auth (ระบบยืนยันตัวตนและสิทธิ์ผู้ใช้) กับ 3 model ได้ผลแบบนี้ครับ

Model	ราคา/ticket	เวลา	ทั้งงาน Auth (181 slot)
Opus 5.5	$0.217	86s	~$39
Sonnet 5.5	$0.089	38s	~$16
Sol 6.1	$0.068	86s	~$12

(ราคาต่อ ticket คิดจากค่า token ตามราคา API แม้ตอนนี้ผมจะใช้แบบ Subscription ส่วนตัวเลขทั้งงาน Auth คือราคาต่อ ticket คูณ 181 slot เป็นการประเมิน ไม่ใช่ยอดที่จ่ายจริง)

ราคาต่อ ticket ต่างกันกว่า 3 เท่า และตัวที่แพงที่สุดก็ไม่ได้เร็วที่สุดด้วย นี่คือเหตุผลที่ workflow ต้องเลือก model ตามความยากของงาน ticket ไหนง่ายก็ไม่จำเป็นต้องใช้ตัวท็อป

---

สิ่งที่ผมเรียนรู้

การทำ AI Agentic Workflow ของผม ไม่ได้อยู่ที่การโยน prompt ยาวๆ ให้ AI เขียนโค้ด เขียน test ธรรมดา แล้วรอผลลัพธ์ แต่อยู่ที่การออกแบบระบบ ที่คุม AI ให้ทำงานตามที่วางไว้

และถ้ามองย้อนกลับไป มันก็คือเรื่องเดียวกับการทำงานกับคน ถ้า requirement ที่เราส่งให้ทีมยังยำรวมอ่านไม่รู้เรื่อง ทีมก็ส่งงานออกมาเละได้เหมือนๆกับ AI นั่นเองครับ