[GN] ผู้ที่ไม่ใช่นักพัฒนา + Claude กับการรันโปรดักชัน 238 วัน — อะไรได้ผล และอะไรไม่ได้ผล?

ผมเป็นผู้ดูแลที่สร้าง chajooin.com จบแค่มัธยมปลาย ขับรถบรรทุกมา 8 ปี (2017~) ทั้งที่เขียนโค้ดไม่เป็นแม้แต่บรรทัดเดียว ผมทำคอมมิตแรกกับ Claude เมื่อวันที่ 16 สิงหาคม 2025

ผ่านไป 238 วัน ตอนนี้บริการนี้เก็บข้อมูลและเผยแพร่รายงานทุกวันโดยอัตโนมัติ

บทความนี้ไม่ใช่บันทึกว่า "สร้างเสร็จแล้ว" แต่เป็นบันทึกของ "สร้างแล้วและกำลังรันอยู่" มีรีวิวการทำต้นแบบด้วย vibe coding เยอะแล้ว แต่ประสบการณ์ในการดูแลโปรดักชันต่อเนื่องยังพบได้น้อย เลยอยากเขียนไว้ นี่ไม่ใช่เรื่องราวความสำเร็จ แต่เป็น บันทึกอย่างตรงไปตรงมาว่าอะไรเวิร์กและอะไรไม่เวิร์ก

---

พื้นหลัง

• โดเมน: เปรียบเทียบราคารถบรรทุก (ตลาดมูลค่า 17 ล้านล้านวอน ไม่มีบันทึกราคาซื้อขายจริงอย่างเป็นทางการ)
• ความพยายามก่อนหน้า: ปี 2024 จ้างเอาต์ซอร์ซแบบ turnkey 30 ล้านวอน → อำนาจในการแก้ไขอยู่ฝั่งเอาต์ซอร์ซ จึงเลิก
• การเปลี่ยนมาใช้แนวทางนี้: เรียน AI อยู่ 2 เดือนในเดือนกรกฎาคม 2025 → คอมมิตแรกวันที่ 16 สิงหาคม

สแตก

Frontend    Vite + React + TypeScript + Tailwind  
Backend     Node.js + Express + Prisma  
DB          PostgreSQL (Railway managed)  
การเก็บข้อมูล        Playwright (headless) + parser แยกตามแหล่งข้อมูล 46 ตัว  
ML          LightGBM (Python, 75 features)  
การดีพลอย        Railway (Docker)  
ระบบอัตโนมัติ      Node scheduler + การแจ้งเตือนทาง Telegram  
การทำงานร่วมกับ AI     Claude (ผู้พัฒนาหลัก) + GPT-4o (สคริปต์ Shorts/พรอมป์ต์)  
การยืนยันตัวตน        Naver/Kakao OAuth  

ผมไม่ได้เป็นคน "เลือก" สแตกนี้เอง ผมแค่ถาม AI ว่า "ถ้าจะทำสิ่งนี้ต้องใช้อะไรบ้าง?" แล้วก็ใช้ตามที่มันแนะนำ พอมาดูทีหลัง มันก็เป็นชุดที่สมเหตุสมผล นี่คือคุณค่าเชิงปฏิบัติของ AI agent — มันช่วยแบกรับภาระทางความคิดในการตัดสินใจเลือกแทนเรา

ตัวเลข (2025-08-16 ~ 2026-04-12)

รายการ	ค่า
คอมมิตทั้งหมด	3,493
จำนวนวันที่มีคอมมิต	189 วัน
จำนวนไฟล์โค้ด	ประมาณ 1,500 (อิงตาม js/ts/py)
โรลแบ็ก	20+ ครั้ง
ดีพลอยล้มเหลว	39 ครั้ง (สองวันแรกของการตั้งค่า Railway)
บั๊กเดิมซ้ำมากที่สุด	7 ครั้ง (หน่วยราคา)
จำนวนประกาศขายที่ใช้งานอยู่	ประมาณ 48,000 คัน
จำนวน parser ของแหล่งข้อมูลภายนอก	46 ตัว
CLAUDE.md	187 บรรทัด, กฎห้ามฝ่าฝืนเด็ดขาด 24 ข้อ
ไฟล์ความจำ	129 ไฟล์

---

ส่วนที่ 1 การสร้าง — 3 สิ่งที่ทำให้มันใช้งานได้จริง

1.1 CLAUDE.md — ควบคุม AI ด้วยกฎ

ถ้าบั๊กเดิมเกิดซ้ำเป็นครั้งที่สอง การบอกว่า "ช่วยระวังหน่อย" ไม่มีความหมาย ต้องเขียนกฎที่ชัดเจนลงในไฟล์ และให้ AI อ่านทุกครั้งเมื่อเริ่มเซสชัน

"parser=วอน → normalization=÷10,000 → DB=หมื่นวอน ห้าม ×10,000 กับค่าจาก DB"  
"ถ้า parser ดึงปีรถไม่สำเร็จ ห้ามแทนค่าด้วย getFullYear()"  
"ห้ามเพิ่ม kakaotalk เข้าไปใน vercel.json UA rewrite"  
"ค่า setInterval ต้อง clamp ด้วย Math.min(value, 2^31-1) เสมอ"  

ตอนนี้มี 24 ข้อ ทุกข้อเกิดขึ้นหลังจากเกิดอุบัติเหตุจริงมาแล้ว

1.2 แยกบทบาท — มนุษย์ทำการวางแผน/ตัดสินใจ, AI ทำการลงมือเขียน

ถึงจะอ่านโค้ดไม่ออก แต่ตัดสินผลลัพธ์ได้ ถ้า Porter 2 ตันแสดงราคา 5 ล้านวอน ก็พูดได้ว่า "อันนี้ผิด" ถ้า wing body กับ cargo ออกราคาเท่ากัน ก็สั่งได้ว่า "แยกออกจากกัน" ความเข้าใจโดเมนทำหน้าที่เป็นการทดสอบ

1.3 ไฟล์ความจำ — รักษาคอนเท็กซ์ข้ามเซสชัน

สะสมการตัดสินใจ/ความล้มเหลว/นโยบายไว้ในไฟล์ความจำ 129 ไฟล์ เมื่อเปิดเซสชันใหม่ก็ให้อ่านความจำที่เกี่ยวข้องเพื่อคงการตัดสินใจในอดีตไว้ เป็นโครงสร้างที่ใช้ระบบไฟล์มาอุดข้อจำกัดของ context window ของ AI

---

ส่วนที่ 2 การปฏิบัติการ — ปัญหาคนละแบบกับตอนสร้าง

2.1 สิ่งที่กำลังรันอัตโนมัติอยู่

• การ ingest ประกาศขาย: scheduler เก็บข้อมูลจากแหล่งภายนอก → ผ่าน quality gate → อัปเดตลง DB
• รายงานราคา: สร้างอัตโนมัติทุกวัน → เผยแพร่อัตโนมัติไปยังบล็อก/คาเฟ่
• การสร้างสคริปต์ Shorts: GPT-4o สร้างสคริปต์/Sora prompt ตามระดับตัน (การประกอบวิดีโอเป็นอีกขั้นตอนหนึ่ง)
• การฝึก ML ใหม่: สัปดาห์ละครั้ง ฝึก price engine ใหม่จากข้อมูลล่าสุด
• มอนิเตอร์ริง: แจ้งเตือนทาง Telegram เมื่อ pipeline มีความผิดปกติ

มีนักพัฒนาอยู่คนเดียวคือผมเอง

2.2 ค่าใช้จ่าย

• อินฟรา: Railway (PostgreSQL + Node + Playwright)
• AI API: สมัคร Claude (ใช้เพื่อพัฒนา) + GPT-4o API (ใช้สร้าง Shorts, ประเมินจาก api_usage_log ว่า ประมาณเดือนละราว $1)
• โดเมน/OAuth: Naver/Kakao

2.3 บันทึกการรับมือเหตุขัดข้อง

• ข้อมูลปนเปื้อน 1,138 รายการ (3/2): พบบั๊ก fallback ของปีรถ → แพตช์ DB + pipeline reprocess + เพิ่มกฎ
• Slack แจ้งเตือนไม่ทำงานนาน 6 เดือน (พบเมื่อ 3/18): ปัญหาจาก environment variable/path → ปรับใหม่ให้รวมเป็นเส้นทางเดียวผ่าน Telegram
• setInterval 32-bit overflow (4/10): ล็อกอินใช้งานไม่ได้ → hotfix + เพิ่มกฎการ clamp
• หน้าจอว่างใน KakaoTalk (1/31): SEO UA rewrite ไปจับ in-app browser ของ KakaoTalk ด้วย → แก้รายการ UA

2.4 ตัวอย่างกฎการปฏิบัติการ

ใน CLAUDE.md ยังมีกฎจากมุมมองการปฏิบัติการรวมอยู่ด้วย

"หลังดีพลอยให้รายงานด้วยตัวเลข 3 อย่าง: สถานะเซิร์ฟเวอร์ (health 200),  
 จำนวนที่ crawl ได้วันนี้ (อยู่ในช่วงเมื่อวาน ±20%), จำนวนประกาศขายที่ active (ไม่มีการเปลี่ยนแปลงผิดปกติ)"  
  
"ถ้าแก้ไฟล์ตั้งแต่ 4 ไฟล์ขึ้นไป, แตะการเชื่อมต่อ scheduler, เปลี่ยน DB schema,  
 หรือกลับไปแก้พื้นที่ที่เคย revert มาก่อน → ต้องรายงานล่วงหน้า"  
  
"การเปลี่ยนชั่วคราว (fallback/TODO/hardcoding) ต้องบันทึกไว้ในทะเบียน:  
 ต้องคืนค่าอะไรภายในเมื่อไร และถ้าไม่คืนค่าจะพังอะไร"  

AI จะอ่านกฎเหล่านี้ทุกครั้ง และเมื่อเจอสถานการณ์นั้นก็จะรายงานก่อนเริ่มงานเสมอ

---

ส่วนที่ 3 สิ่งที่ไม่ทำงาน

3.1 บั๊กเดิมซ้ำ 7 ครั้ง — มองไม่เห็นเส้นทางข้อมูลทั้งระบบ

เหตุผลที่บั๊กหน่วยราคาเกิดซ้ำ 7 ครั้งคือ ถ้าใน 6 ขั้นของ เก็บข้อมูล → parser → normalization → DB → API → UI แก้แค่จุดเดียว มันก็จะไปโผล่อีกในเส้นทางอื่น ความสามารถในการ "มองทั้งระบบ" คือจุดที่การผสมกันระหว่างคนนอกสายพัฒนา + AI ขาดที่สุด AI จะแก้เฉพาะจุดที่สั่ง ส่วนคนก็ไม่รู้ว่ามีเส้นทางอื่นอยู่ด้วย

3.2 ข้อมูลปนเปื้อน 1,138 รายการ — ค่าเริ่มต้นแบบ "หวังดี" ของ AI

ตอน parser ดึงปีรถไม่สำเร็จ มีโค้ดที่ให้คืนค่า getFullYear() ถูกใส่เข้ามา จากมุมของ AI มันอาจคิดว่า "ปีปัจจุบันยังดีกว่า null" ผลคือ Porter ปี 2003 ถูกบันทึกใน DB เป็นรุ่นปี 2026 ถ้าไม่ได้เขียนให้ AI ชัด ๆ ว่า "ถ้าไม่รู้ให้เป็น null" มันจะเติมอะไรบางอย่างลงไปเอง

3.3 Slack แจ้งเตือนไม่ทำงาน 6 เดือน — ไม่ได้เฝ้าระวังระบบเฝ้าระวัง

การแจ้งเตือนจบลงด้วยความล้มเหลว และความล้มเหลวนั้นเองก็ไม่ถูกบันทึกใน log เลยเงียบอยู่ 6 เดือน ระหว่างนั้น pipeline มีความผิดปกติอยู่หลายครั้ง แต่ผมเข้าใจผิดว่า "ไม่มีปัญหา" สภาวะที่อันตรายที่สุดของระบบที่สร้างด้วย AI คือสภาวะที่ 'ดูเหมือนว่ามันกำลังทำงานได้ดี' ตอนนี้ผมลดความซับซ้อนให้เหลือเส้นทางเดียวผ่าน Telegram

3.4 setInterval 32-bit overflow — กับดักของภาษา

ถ้าไม่รู้ว่า setInterval รับได้แค่ int32 ก็จะไม่รู้ว่าพอใส่ 30 วันในหน่วยมิลลิวินาทีแล้วมันจะรันทันที ล็อกอินจึงใช้งานไม่ได้ AI ไม่ได้เตือน edge case แบบนี้เองโดยสมัครใจ กฎการ clamp เพิ่งเกิดขึ้นหลังจากมันพังไปแล้ว

3.5 ML overfitting — MAPE ตอนฝึก 8.56% vs ใช้งานจริง 42%

พอได้ MAPE 8.56% จาก LightGBM 75 features ก็คิดว่า "ใช้ได้แล้ว" แต่ตอนใช้งานจริงเป็น 42% สาเหตุคือข้อจำกัดเชิงโครงสร้างของข้อมูลราคาประกาศขาย (ไม่มีราคาซื้อขายจริง, สัญญาราคาต่ำกว่าจริง, มาร์จินดีลเลอร์) ถ้าเป็นผู้เชี่ยวชาญโดเมนก็น่าจะรู้ตั้งแต่แรก แต่ผมติดอยู่กับความคิดว่า "ถ้าผลเทรนดี ก็พอแล้ว"

---

ความคิดที่ยังเหลืออยู่

พอลองมองย้อนกลับไป 238 วัน ก็สรุปได้ว่า:

• AI ช่วยเร่งความเร็วในการลงมือทำได้มาก คนที่ไม่รู้โค้ดก็สร้างบริการที่ใช้งานได้จริงขึ้นมาได้
• แต่คุณภาพด้านการปฏิบัติการไม่ได้ตามมาเองโดยอัตโนมัติ ปัญหาจะเกิดขึ้นแน่นอน และ AI จะไม่คอยเตือนให้เองโดยสมัครใจ
• งานของคนที่ไม่ใช่นักพัฒนาไม่ได้อยู่ที่การเขียนโค้ด แต่อยู่ที่การออกแบบกฎ การเฝ้าระวัง และการตรวจสอบ การตัดสินผลลัพธ์และการป้องกันไม่ให้เกิดซ้ำกลายเป็นงานหลัก

นี่เป็นโปรดักชันที่ผมรันคนเดียว จึงเป็นเพียงตัวอย่าง n=1 ผมจะไม่เหมารวม อยากรู้ประสบการณ์ของคนอื่นในเงื่อนไขคล้ายกัน

---

ลิงก์

• บริการ: https://chajooin.com (เปรียบเทียบและวิเคราะห์ราคารถบรรทุก)

ยินดีรับฟีดแบ็ก โดยเฉพาะเรื่องว่า คุณเฝ้าระวังสภาวะที่ "ดูเหมือนว่ามันกำลังทำงานได้ดี" กันอย่างไรเมื่อดูแลอยู่คนเดียว

[savvykang]

ผมคิดว่าปัญหาเรื่องสถานะที่ดูเหมือนทำงานได้ดีนั้นอาจบรรเทาได้ในระดับหนึ่ง หากมีการฝึกซ้อมกู้คืนเหตุขัดข้องเป็นระยะ และกำหนดให้ชัดเจนว่าคุณลักษณะใดของข้อมูลที่ถือว่าเป็นสภาวะปกติ

[workdriver]

ครับ ขอบคุณสำหรับความเห็นดี ๆ นะครับ
เมื่อระบบใหญ่ขึ้น ก็เป็นความจริงที่การจัดการเริ่มหนักมือขึ้นครับ

[savvykang]

ถ้าคุณดูแลระบบอยู่คนเดียว คุณก็ต้องจัดการบริการมอนิเตอร์ด้วยตัวเองด้วย ดังนั้นในสถานการณ์ตอนนี้อาจจะไม่ง่ายนัก การใช้บริการมอนิเตอร์จากภายนอกก็เป็นอีกทางเลือกหนึ่ง

[jjw9512151]

ขอบคุณสำหรับข้อมูลจากภาคสนามจริงครับ

[workdriver]

ครับ ขอบคุณครับ