เริ่มทดลองให้ LINE กับ AI เดินด้วยกัน

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

ตั้งใจไม่เขียนโค้ดเอง — ขยับสู่บทบาทคนคุมโจทย์และทิศทาง

สิ่งที่ผมอยากพิสูจน์คือ AI ที่หลายคนพูดหรือโฆษณาว่าสามารถช่วยสร้าง Software และ Product ได้ จะทำได้จริงแค่ไหนเมื่อเจอกับโจทย์จริง ไม่ใช่แค่การสร้างตัวอย่างสั้น ๆ หรือเขียน Code บางส่วนให้ดูสำเร็จ

ผมตั้งใจว่าจะไม่เป็นคนเขียนโค้ดเองเป็นหลัก แต่จะเป็นคนกำหนดโจทย์ ตัดสินใจ ตรวจสอบ และเรียนรู้จากสิ่งที่สร้างขึ้นมา ถ้าวิธีนี้จะทำให้ Product เดินต่อได้จริง AI ต้องช่วยได้มากกว่าการตอบคำถามหรือสร้าง Code เป็นชิ้น ๆ มันต้องช่วยคิดทางเลือก ลงมือทำ จัดการเอกสาร และรับช่วงบริบทเดิมไปทำงานต่อได้

เลือกเทคโนโลยีด้วย TCO — และ Drive จริงที่ต้องออกแบบให้ "สลับ Model ได้โดยง่าย"

เหตุผลที่ผมเริ่มจาก Codex ก็เพราะตอนนั้นมีให้ทดลองใช้งานฟรีหนึ่งเดือน สำหรับผม ค่าใช้จ่ายที่คาดเดาได้เป็นต้นทุนที่พอรับได้ ทำให้วางขอบเขตการทดลองได้โดยไม่ต้องกังวลกับค่าใช้จ่ายใหม่ทุกครั้งที่ให้ AI ช่วยทำงาน... แต่ในความเป็นจริง การทดลองไม่ได้ราบรื่นขนาดนั้นครับ!

ตอนนั้นกำลังมือขึ้น สั่งงานเพลิน ๆ จู่ ๆ ก็โดนกำแพงข้อจำกัดฟาดเข้าอย่างจัง: Codex ติดทั้ง 5-hour limit และ Weekly limit จนระบบหยุดชะงักไปต่อไม่ได้! (5555)

คนกำลังไฟลุกอยู่ จะให้นั่งรอนิ่ง ๆ รอเวลาปลดล็อกได้ยังไงล่ะครับ? ทางออกเดียวตอนนั้นคือ “ต้องหาตัวสำรองทันที”

• ผมเริ่มจากการโยกไปหา Gemini... แต่ใช้ไปได้แค่นิดเดียว ก็ชน Limit อีก
• สุดท้ายเลยต้องขยับไปซบ Cline + DeepSeek

หลายคนพอได้ยินชื่อ DeepSeek หรือ AI ค่ายนี้ อาจจะตั้งคำถามด้วยความระแวงตามกระแสว่า: “กล้าใช้ AI จีนเหรอ? ไม่กลัวข้อมูลหลุดเหรอ?”

แต่มุมมองของผมในวันนั้นเรียบง่ายและเป็นเหตุเป็นผลมากครับ: “มันไม่มีอะไรให้ต้องเสี่ยงเลยสักนิด!”

ลองคิดดูตามความเป็นจริงสิครับ โค้ดที่เราเขียน การคิดแนวทาง หรือการขึ้นโครงสร้างระบบ ทุกอย่างมันก็เกิดขึ้นจาก AI ร่วมคิดร่วมทำอยู่แล้ว ถ้าจะกลัวข้อมูลหลุด... มันไม่เคยมีข้อมูลความลับของใครให้หลุดเลยครับ! สิ่งเดียวที่มีอยู่ในนั้นคือ Idea ส่วนตัวที่ผม Top-up เสริมลงไป ซึ่งเป็นทรัพย์สินทางปัญญาในการเรียนรู้ส่วนตัวของผมเอง และมันไม่ได้กระทบกับงานประจำหรือองค์กรใด ๆ ทั้งสิ้น

เมื่อไม่มีความเสี่ยง แนวคิดตั้งต้นของผมจึงพุ่งตรงไปที่เรื่องเดียวคือ: “จ่ายน้อย และคุม Cost ได้จริง”!

ในการทำโปรเจกต์ส่วนตัวนอกเวลางาน ทุกบาททุกสตางค์คือเงินที่ควักออกจากกระเป๋าตัวเองล้วน ๆ และอีกอย่าง... มันมีโมเดลให้เลือกทั้งรุ่น Pro และ Flash ในเมื่อราคาค่า Token มันจับต้องได้สบายกระเป๋า มันก็กลายเป็นโอกาสทองให้คนชอบทดลองอย่างผมได้ลองดูให้เห็นกับตากันไปเลยว่า: สองรุ่นนี้มันต่างกันอย่างไร? งานแบบไหนที่ตัวเล็กอย่าง Flash ก็เอาอยู่สบาย ๆ และงานระดับไหนที่ต้องใช้ความลึกของรุ่น Pro แล้วผมก็พบว่า DeepSeek ให้ความคุ้มค่าต่อราคา (Price-to-Performance) ที่น่าทึ่งมาก ค่า Token ถูกจนเรากล้าปล่อยให้มันช่วยคิด ช่วยไล่โค้ด และทดลองลุยงานยาว ๆ ได้โดยไม่ต้องมานั่งสะดุ้งผวาเวลากระเป๋าตังค์ขยับ

ผมให้ AI ช่วยเปรียบเทียบและช่วยเคาะ Stack โดยใช้ TCO หรือ Total Cost of Ownership เป็นเกณฑ์สำคัญ ซึ่งหมายถึงต้นทุนรวมตั้งแต่การเริ่มต้น ทดลอง ใช้งาน ดูแล ไปจนถึงการเปลี่ยนแปลงในระยะยาว ไม่ใช่ดูเพียงว่า Technology ใดทำได้บ้าง ผมตั้งใจไม่เป็นคนเขียน Code เองเป็นหลัก ระบบต้องพอมีชีวิตอยู่ได้นาน และต้องเดินต่อได้แม้ผมจะมีเวลาทำงานเฉพาะนอกเวลางาน

ประสบการณ์โดน Limit ชนเข้าอย่างจังจนต้องดิ้นรนหาตัวสำรองนี่เอง ที่กลายเป็น Drive จริง ในการทำงานของผม: มันทำให้เห็นสัจธรรมทันทีว่า ในโลกของ AI เราไม่มีทางฝากชีวิตไว้กับโมเดลหรือค่ายใดค่ายหนึ่งได้เลย

และบทเรียนนี้ก็ส่งผลโดยตรงต่อการออกแบบระบบ SabayJai Buddy: สัญชาตญาณวิศวกรรมสั่งผมทันทีว่า “ระบบข้างหลัง ต้องออกแบบให้ 'สลับ Model ได้โดยง่าย' ตั้งแต่วันแรก!”

ในโลกของ AI ความสามารถและราคาของแต่ละค่ายหมุนเร็วมาก ค่ายใหม่โมเดลใหม่เปิดตัวแข่งขันกันแทบทุกเดือน ถ้าเราเขียนโค้ดผูกติดกับ Model ใด Model หนึ่ง วันข้างหน้าถ้าค่ายนั้นขึ้นราคา เจ๊ง หรือมีค่ายอื่นที่เก่งกว่าและคุ้มกว่าโผล่มา เราจะกลายเป็นตัวประกันทันที การออกแบบสถาปัตยกรรมตั้งแต่ก้าวแรกจึงต้องวางให้ส่วนต่อประสานกับ AI เป็นอิสระ เพื่อให้ระบบสามารถ “ถอดเปลี่ยนหรือสลับ Model ได้ทันทีโดยไม่ต้องรื้อระบบทั้งยวง” เลือกตัวที่คุ้มที่สุดในแต่ละช่วง และพร้อมเปลี่ยนไปใช้ตัวอื่นได้เมื่อมีทางเลือกที่ดีกว่า

ลองปล่อย Agent คุยกัน — สู่การเลือก Fastify, Strapi และ LINE

ช่วงแรกผมลองปล่อยให้ AI เดินงานเต็มที่อยู่หลายรูปแบบ ตามแนวทางที่เห็นคนอื่นทดลองกันบน YouTube หนึ่งในแบบที่ผมลองคือการแบ่งงานให้ Agent หลายตัว หรือผู้ช่วย AI ที่รับงานย่อยคนละส่วน ให้ Agent ช่วยคุยตกลง Contract ซึ่งหมายถึงข้อตกลงเรื่องขอบเขตและรูปแบบข้อมูลระหว่างกัน แล้วปล่อยให้มันพางานเดินต่อไปจนถึงจุดที่มีระบบให้ทดลองจริง ตอนนั้นผมยังไม่ได้สรุปว่าวิธีนี้ดีหรือไม่ แต่อยากรู้ก่อนว่าถ้าให้ AI รับผิดชอบงานต่อเนื่องมากขึ้น มันจะพา Product ไปได้ไกลแค่ไหน

จากเงื่อนไขเหล่านี้ การเลือก Stack ช่วงแรกจึงค่อย ๆ มีรูปขึ้นมา ผมรวมงานหลายส่วนไว้ใน npm workspace เพื่อให้ทำงานอยู่ใน Project เดียวกัน เลือก Fastify + TypeScript เป็นฐานบาง ๆ สำหรับรับข้อความจาก LINE และใช้ Strapi + PostgreSQL ผ่าน Docker Compose เพื่อให้มี Backend กับฐานข้อมูลพร้อมใช้ โดยไม่ต้องสร้างทุกอย่างเองจากศูนย์ การเลือก LINE เป็นช่องทางแรกก็เป็นส่วนหนึ่งของการลดขอบเขตให้เล็กและทดลองกับรูปแบบการคุยที่คุ้นเคย

ทดสอบทีละขั้น — แยกความไม่แน่นอนออกจากกัน

หลักการทดลองจึงเป็นการแยกความไม่แน่นอนออกเป็นขั้น ๆ ดูเส้นทางภายในก่อน แล้วค่อยต่อกับ LINE จริง ใช้ Mock AI เพื่อดูว่า Flow พื้นฐานเดินได้หรือไม่ แล้วจึงค่อยพิจารณา Model จริง รายละเอียดของเส้นทางที่เกิดขึ้นจริงจะอยู่ในตอน Walking Skeleton

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

ตอนเริ่มลงมือ ผมไม่ได้ตั้งเป้าว่า Walking Skeleton จะเสร็จภายในกี่วัน และยังไม่รู้ด้วยซ้ำว่าจะพาแนวคิดนี้ไปได้ไกลแค่ไหน สิ่งที่ผมพยายามทำในตอนนั้นคือทดสอบให้เห็นก่อนว่า แนวคิดที่ผมออกแบบไว้—ให้ LINE รับข้อความ เรียกใช้ AI แล้วโต้ตอบกลับได้—สามารถทำงานจริงหรือไม่

จุดหมายของช่วงนี้จึงยังไม่ใช่การสร้าง Product ให้ครบ แต่เป็นการหาคำตอบของคำถามเล็ก ๆ ว่า LINE กับ AI จะเดินไปด้วยกันตาม Flow ที่ผมออกแบบเองได้หรือไม่ คำตอบของคำถามนี้จะพาไปสู่การทดลอง Walking Skeleton ในตอนถัดไป