เอกสารการตัดสินใจภายใน · 8 มิ.ย. 2026

Iris Chatbot
แผนที่เส้นทาง & การตัดสินใจ: n8n vs Code

สร้างโดย: มิรา (Mira Orchestrator) · Mongkol Catering

บอท Iris เวอร์ชัน code (standalone) สร้างเสร็จและผ่านเทสแล้ว — แต่ production ยังใช้ n8n ต่อไปก่อน เอกสารนี้เทียบ 3 เส้นทางข้างหน้า ให้พี่นัทคำนวณว่าควรเปลี่ยนเมื่อไหร่
✅ Standalone repo P0–P3 เสร็จ (87 เทสผ่าน) 🟠 Production = n8n (ไม่โดนแตะ) ⏳ Cutover = ยังไม่ทำ (รอพี่นัทเคาะ)
บริบท 1

ทำไม n8n ถึงสำคัญน้อยลงสำหรับตัว "สมอง" ของบอท

⏮ ก่อนมี AI

Chatbot = "ผังการไหล (flowchart)" ของกฎ if-this-then-that
การสร้างต้องใช้เครื่องมือต่อผังแบบลากวาง เช่น n8n — เพราะตัวบอท คือ ผังนั่นเอง
n8n จึงเป็น "บ้านที่ถูกต้อง" ของ chatbot ยุคนั้น

✨ หลังมี AI (LLM)

"สมอง" ของบอทไม่ใช่ผังกฎอีกแล้ว — มันคือการเรียก AI 1 ครั้งด้วย prompt ที่ดี + ความจำ
≈ code สั้นๆ ~50 บรรทัด ไม่ใช่ ผัง 17 โหนด
คุณค่าหลักของ n8n สำคัญน้อยลงสำหรับตัวสมอง — แต่ยังมีค่ามากสำหรับ "งานต่อท่อ / automation" รอบๆ บอท

💡 สรุป: n8n ไม่ได้แย่ลง — แต่ "งานที่ n8n เก่งที่สุด" เปลี่ยนจาก "เป็นตัวบอท" ไปเป็น "เป็นผู้ช่วยต่อท่อ (integration helper) รอบๆ บอท"
แผนที่ที่เดินมาแล้ว

งานที่ทำเสร็จแล้วทั้งหมด — 8 มิ.ย. 2026

🔒 Mongkol production ไม่โดนแตะแม้แต่ไฟล์เดียว ทุกขั้นตอนต่อไปนี้
✅
P0 — ตั้งโครง (Scaffold)
ยกระบบเดิมมาแยกเป็นชิ้นส่วน (module)
โครงสร้างโค้ดสะอาด แยก concern ชัดเจน ทดสอบได้แต่ละส่วน
✅ เทส 41/41 ผ่าน
✅
P1 — ย้ายสมองออกจาก n8n (Port Brain)
บอทรับข้อความ LINE → ตรวจลายเซ็น (signature) แบบกันปลอม → คิดคำตอบเอง → ตอบ
เส้นทาง: router → memory → Claude · เลิกพึ่ง n8n ในเส้นทางคุยลูกค้า
✅ เทส 74/74 ผ่าน
✅
P2 — ถอด Mongkol ออกเป็น config
ตัวตน / ความรู้ของบอทย้ายไปไฟล์ markdown (persona.md + knowledge.md)
แก้ได้โดยไม่แตะโค้ด — เปลี่ยนเป็นบอทธุรกิจอื่นได้ · พิสูจน์ด้วยเทส "Barista Bot"
✅ เทส 87/87 ผ่าน
✅
P3 — แพ็กให้ติดตั้งง่าย (Package)
Docker + ตัวช่วยตั้งค่า npm run setup + คู่มือ
"clone แล้วรันได้เลย" — พร้อมแจก / ขาย / ใช้งานจริงทันที
✅ พร้อม deploy
3 เส้นทางข้างหน้า

🛣️ เลือกดูเส้นทาง

🟠 เส้นทาง A — ใช้ n8n ต่อไป (production คงเดิม)

📋 Roadmap

  • ไม่ต้องสลับ (cutover) อะไร — production เดินต่อเหมือนเดิม
  • พัฒนาฟีเจอร์ใหม่ = แก้ workflow ใน n8n UI โดยตรง
  • ถ้าจะแจก / ขายให้เพื่อน = ยาก (เขาต้องตั้ง n8n เองก่อน)
  • repo standalone ที่สร้างแล้วยังนำไปใช้งานอิสระได้ (แค่ไม่ใช่ Mongkol)

✅ ข้อดี

  • ของจริงที่พิสูจน์แล้ว ไม่มีความเสี่ยงจากการสลับ
  • เห็นผัง (visual flow) เป็นภาพ ดูได้ทันที
  • ต่อ integration ใหม่ง่าย (มี node สำเร็จเป็นร้อย)
  • ไม่ต้องทำอะไรเพิ่ม — ประหยัดเวลา

⚠️ ข้อเสีย

  • เทสอัตโนมัติยาก (logic อยู่ในโหนด)
  • เจอ footgun เดิมซ้ำๆ (ดูข้อ 5)
  • แจก / ขายแทบไม่ได้
  • repo (standalone) ≠ production = drift / โค้ดเหลื่อม ฟีเจอร์ใหม่ใน repo ไม่ตกถึง Mongkol จริง
🟢 เส้นทาง B — ย้ายไป Code ล้วน (standalone) ทั้งหมด

📋 Roadmap

  1. ทดสอบกับ LINE จริง (test channel แยก) → ยืนยัน parity กับ n8n
  2. สลับ production (cutover): ชี้ webhook มาที่ code แทน n8n
  3. เก็บ n8n ไว้เป็น rollback สำรอง ~1 สัปดาห์
  4. จากนั้น dev → stable → deploy เป็น flow เดียว ครอบทั้ง Mongkol + เพื่อน + ลูกค้า

✅ ข้อดี

  • เทสได้ครบ 87 เทส — มั่นใจทุกการแก้ไข
  • พกพา — รันที่ไหนก็ได้ที่มี Node 18
  • ไม่มี footgun ของ n8n
  • version-control ด้วย git ทุกการแก้มีประวัติ
  • แจก / ขายได้ทันที (clone + docker-compose up)
  • โค้ดเดียว ไม่มี drift ระหว่าง dev กับ production

⚠️ ข้อเสีย

  • มี "วันสลับ (cutover)" ที่ต้องระวัง 1 ครั้ง
  • เสียมุมมอง "เห็นผังเป็นภาพ" (ชดเชยด้วย dashboard + เอกสาร)
  • ต่อ integration ใหม่ = ต้องเขียนโค้ด (ไม่ได้ลากวาง)
💙 เส้นทาง C — ผสมผสาน (Hybrid) ⭐ มิราแนะนำเป็นปลายทาง
แนวคิด: Code เป็นเจ้าของ "สมองคุยลูกค้า" (เทสได้ / พกพา / เร็ว) ส่วน n8n เป็น "ผู้ช่วยต่อท่อ (integration helper)" เฉพาะงาน automation รอบๆ ที่ n8n เก่งจริง เช่น ลูกค้า hot → n8n ดันเข้า Google Sheet / แจ้งเตือน / สร้างเอกสารใน FlowAccount

📋 Roadmap (เหมือน B แต่ไม่ทิ้ง n8n)

  1. ย้ายสมองบอทมาเป็น code (เหมือน B)
  2. ไม่ทิ้ง n8n — เก็บไว้ทำงานเสริม: Google Sheet, FlowAccount, แจ้งเตือน LINE, etc.
  3. แบ่งหน้าที่ชัด: code = คุยลูกค้า · n8n = เชื่อมระบบ
  4. สองระบบรู้จักกัน แต่ไม่ตีกัน (ไม่ใช่ parallel บอท)

✅ ข้อดี

  • ได้ของดีทั้งสองฝั่ง — สมองที่เทสได้ / ขายได้
  • ความยืดหยุ่นต่อ integration ของ n8n ยังอยู่ครบ
  • ลด footgun (เพราะ logic สมองออกจาก n8n แล้ว)
  • n8n ทำงาน "เหมาะๆ" กับตัวเอง ไม่ฝืน

⚠️ ข้อเสีย

  • มี 2 ระบบให้ดูแล (แต่แบ่งหน้าที่ชัด ไม่ทับกัน)
  • ต้องเข้าใจว่างานไหนอยู่ฝั่งไหน (learning curve เล็กน้อย)
ตารางเปรียบเทียบ

⚖️ n8n vs Standalone Code — เทียบทุกมิติ

มิติ 🟠 n8n 🟢 Standalone Code
เส้นทางทำงาน LINE → n8n (คิด) + iris-api — 2 ระบบ iris-api ตัวเดียวจบ
สมองอยู่ไหน ในโหนด n8n (visual) ใน code src/brain/
ต้องมีอะไรรัน n8n + iris-api + Cloudflare Node 18 อย่างเดียว (ไม่มี dependency)
แก้ logic ลากโหนดใน n8n UI แก้ code / แก้ markdown (persona + knowledge)
เก็บประวัติ / version export JSON ยาก track git — ทุกการแก้มีประวัติ
ทดสอบ (test) ยาก (logic ในโหนด) 87 เทสอัตโนมัติ
แจก / ขายต่อ ยากมาก (ต้องตั้ง n8n เอง) clone + docker-compose up
Deploy / อัปเดต แก้ใน UI / re-import JSON push git → deploy
ค่าโฮสต์ n8n หนักกว่า (รัน VPS รวม stack ~$7–10/เดือน) Node container เบามาก (VPS ตัวเดิมได้ ถูกลง)
ค่า AI (Claude) เท่ากันทั้งสองทาง เท่ากัน
บันทึกเหตุการณ์จริง

🔴 Footgun ของ n8n ที่เราเจอจริง (มีบันทึก ไม่ใช่เดา)

⚠️ 4 ปัญหาที่เกิดจริงบน n8n

1
Webhook ID ชนกัน (webhook-id conflict) — workflow แชร์ webhookId เดียวกัน = ระเบิดเวลา (shadow/prod ตีกัน ตอบลูกค้าสลับกัน)
2
n8n sandbox บล็อก fetch — โหนด Code เรียก LINE API โดยตรงไม่ได้ → นี่คือสาเหตุที่ต้องสร้าง "Option C" ให้ iris-api ดึง profile แทน (งานพิเศษที่ไม่ควรมี)
3
$env พังเมื่ออยู่ใน nested function — ต้องย้ายขึ้นบนสุด (hoist) ทุกครั้ง เป็น pitfall ที่ debug นานมาก
4
Webhook ดับเอง (silent failure) — ต้องตั้ง cron ทุก 15 นาทีคอยปลุกกลับมา เป็นงานเสริมที่ไม่ควรมี
✅ บน standalone (code) ปัญหาพวกนี้หายหมด เพราะเป็น Node ธรรมดา — fetch ได้, env ได้, ไม่มี sandbox, ไม่มี webhook-id conflict
ถ้าตัดสินใจย้าย

⬆️ ถ้าจะอัปเกรด (ย้ายไป code) — ดีขึ้นยังไง + ต้องทำอะไร

💚 ดีขึ้นยังไง (จับต้องได้)

  • หยุดเสียเวลาไล่ footgun n8n ซ้ำๆ
  • ทุกการแก้มีเทส = มั่นใจไม่พังของเก่า
  • พัฒนาที่เดียว push ขึ้น stable (ฝันที่พี่นัทพูด)
  • เอาไปแจก / ขายได้ทันที ไม่ต้องรอ

📋 Checklist สิ่งที่ต้องทำ

  1. 1สร้าง / หา LINE OA ตัวทดสอบ → ให้ token (channel access)
  2. 2รัน repo จริง ยิงข้อความทดสอบ เทียบคำตอบกับ n8n (parity check)
  3. 3push repo ขึ้น GitHub (private)
  4. 4deploy repo ขึ้น VPS ข้างๆ n8n
  5. 5วันสลับ (cutover): ชี้ webhook production มาที่ code + เฝ้าดู
  6. 6ถ้าเพี้ยน → กดกลับ n8n ได้ใน ~1 นาที (rollback plan)
เครื่องคิดเลขความคุ้ม

🧮 Trade-off ที่ต้องจ่าย + ควรเปลี่ยนเมื่อไหร่

💛 สิ่งที่ต้องจ่าย (cost)

  • เวลา cutover ~ไม่กี่ชั่วโมง (ครั้งเดียว)
  • ความเสี่ยงช่วงสลับสั้นๆ (กันด้วย rollback)
  • เสียมุมมอง "เห็นผังเป็นภาพ" (ชดเชยด้วย dashboard + เอกสาร)
  • ต้องมี LINE OA ทดสอบ (test channel)

🌿 ควรเปลี่ยนเมื่อ…

✅ เริ่มเบื่อไล่ footgun n8n ซ้ำๆ
✅ อยากแจก / ขายอย่างจริงจัง
✅ อยากให้ฟีเจอร์ใน repo ตกถึง Mongkol production ด้วย
⏸️ n8n ตอนนี้นิ่งดี ไม่กวนใจ
⏸️ ยังไม่มีเวลาทำ cutover
⏸️ ยังไม่มี LINE OA ทดสอบ

💡 สรุปตัวเลขจริง

≈ เท่ากัน
ค่าโฮสต์ (VPS ตัวเดิม)
เท่ากันเป๊ะ
ค่า AI / Claude API
เวลาดูแล
ตัวแปรจริงที่ต่าง
(ไม่ใช่เงิน)

ตัวแปรจริง = เวลาดูแล + ความเปราะ (fragility) ไม่ใช่เงิน — ถ้า n8n ไม่ทำให้ปวดหัว ก็ไม่รีบเปลี่ยน

💡 คำแนะนำมิรา

ปลายทางที่แนะนำ = เส้นทาง C (Hybrid): code เป็นสมอง · n8n เป็นผู้ช่วยต่อท่อ

จังหวะ: ไม่เร่ง — production คง n8n ไปก่อน (ของจริงห้ามเสี่ยง)

repo standalone ได้ประโยชน์ "แจก / ขาย" แล้วทันทีโดยไม่ต้องสลับ Mongkol

พอว่าง + ทดสอบ LINE จริงผ่าน ค่อยสลับสมอง Mongkol มาเป็น code — แล้วเก็บ n8n ไว้ทำ automation รอบๆ ต่อไป

"ไม่ใช่คำถามว่า n8n หรือ code — แต่คือ 'ให้แต่ละอย่างทำสิ่งที่มันเก่งที่สุด'"