← กลับหน้าภาพรวม
ระดับ 1 · FOUNDATION

Foundation: พื้นฐาน AI Automation ที่ใช้ได้จริง

เข้าใจแนวคิดหลัก สร้าง workflow แรกที่มี LLM และเลือกแพลตฟอร์มให้ถูกกับงาน โดยยังไม่ต้องเขียนโค้ดหนัก

📦 6 โมดูล⏱ 18-24 ชั่วโมง

6 โมดูลในระดับนี้: 1.1 Workflow vs. AI Agent: · 1.2 Building Blocks: Trigg · 1.3 n8n เบื้องต้น: แพลตฟอร · 1.4 Zapier และ Make: ทางเล · 1.5 LLM Node แรกของคุณ: ให · 1.6 เลือกแพลตฟอร์มให้ถูกงา

1.1
โมดูล 1.1

Workflow vs. AI Agent: ความต่างที่ต้องเข้าใจก่อนทุกอย่าง

เส้นแบ่งที่สำคัญที่สุดของทั้งวงการ ระหว่างระบบอัตโนมัติที่เราสั่งทุกขั้นตอน กับ AI ที่ตัดสินใจเอง (AI Agent)

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน
💡
เปรียบง่าย ๆ: Workflow เหมือนสูตรทำอาหารที่เขียนไว้ตายตัว ทำตามข้อ 1-2-3 ทุกครั้งไม่มีผิด ส่วน AI Agent เหมือนเชฟที่คุณบอกแค่ว่า 'ทำอาหารเย็นให้หน่อย' แล้วเขาคิดเองว่าจะทำเมนูอะไร ใช้วัตถุดิบไหน
🎯
ทำไมต้องรู้: ถ้าเลือกผิดแบบ งานที่ต้องการความแน่นอนอาจกลายเป็นเดาสุ่มและเสียเงินฟรี พอรู้เส้นแบ่งนี้ คุณก็จะเลือกเครื่องมือที่คุมได้ ราคาถูก และย้อนกลับมาดูทีหลังได้ว่าเกิดอะไรขึ้นตั้งแต่ต้น

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

  • อธิบายได้ชัด ๆ ว่าลำดับงานอัตโนมัติแบบตายตัว (workflow แบบ deterministic) ต่างจาก AI ที่ตัดสินใจเอง (AI Agent) อย่างไร
  • บอกได้ว่าเมื่อไหร่ควรให้ AI (LLM) เป็นแค่ก้อนงานหนึ่ง (node) และเมื่อไหร่ควรให้มันมีอำนาจตัดสินใจเอง
  • เข้าใจว่าทำไมงานแบบวางขั้นตอนไว้ตายตัว (structured workflow) ถึงครองระบบใช้งานจริง (production) ในปี 2025 และทำไมแบบผสม (hybrid) ถึงเป็นทางที่ดีที่สุด

เนื้อหา

โมดูลนี้ปูพื้นความเข้าใจที่สำคัญที่สุดของทั้งหลักสูตร ลองนึกภาพแบบนี้: workflow แบบตายตัว (deterministic คือใส่เหมือนเดิมก็ได้ผลเหมือนเดิมทุกครั้ง) ก็คือลำดับงานที่เราเป็นคนวางเองทุกขั้น มีตัวจุดชนวน (trigger) ให้เริ่ม แล้วต่อด้วยการกระทำ (action) และเงื่อนไข ส่วน AI (LLM) ถ้ามี ก็เป็นแค่ก้อนงานเดียว (node) ที่ทำงานแคบ ๆ เช่น แยกประเภท สรุป หรือดึงข้อมูล ข้อดีคือคาดเดาได้ ราคาถูก ย้อนกลับมาดูได้ว่าเกิดอะไรขึ้น และเชื่อถือได้ นี่แหละคือเหตุผลที่วิธีนี้ครองระบบใช้งานจริง (production) แบบท่วมท้นในปี 2025 ส่วน AI Agent คือการปล่อยให้ตัว AI คิดเองว่าจะทำอะไรต่อ เลือกหยิบเครื่องมือ (tool) ตัวไหนมาใช้ และรู้เองว่าเสร็จเมื่อไหร่ ยืดหยุ่นก็จริง แต่แลกมากับความคาดเดายาก (non-deterministic) แพงกว่า และตรวจสอบยากกว่า ทางที่คนส่วนใหญ่ใช้กันตอนนี้เลยเป็นแบบผสม (hybrid) คือวางกรอบด้านนอกให้เป็น workflow ตายตัว (จุดชนวนชัด ผลลัพธ์ชัด มีรั้วกันพลาดที่ขอบ) แล้วค่อยแทรกส่วนที่เป็น agent ไว้ข้างในเฉพาะจุดที่ต้องคิดเองจริง ๆ กฎง่าย ๆ ที่ได้จากงานจริง: ถ้าคุณต้องทำงาน 10,000 รายการที่หน้าตาเหมือนกันทุกวันและรูปแบบไม่เปลี่ยน ให้ใช้ระบบอัตโนมัติ (automation) ธรรมดาไปเลย เพราะเอา agent มาใส่มีแต่จะเพิ่มต้นทุน ทำให้ช้าลง (latency) และเพิ่มจุดที่พังได้ โดยไม่ได้อะไรกลับมา

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)
Workflowลำดับขั้นตอนงานที่วางไว้ล่วงหน้า ให้ระบบทำตามเป็นสเต็ป ๆ โดยอัตโนมัติ
AI Agentผู้ช่วย AI ที่ตัดสินใจเองได้ว่าจะทำอะไรต่อ ไม่ต้องเขียนทุกขั้นตอนให้
Deterministicแบบตายตัว ใส่ข้อมูลเดิมได้ผลเดิมเสมอ คาดเดาได้ 100%
Triggerจุดเริ่มต้นที่จุดชนวนให้งานทำงาน เช่น มีอีเมลใหม่เข้ามา
LLMโมเดล AI ที่เข้าใจและสร้างภาษาได้ เช่นตัวที่อยู่เบื้องหลัง ChatGPT

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ตัดสินใจเลือกสถาปัตยกรรมจากโจทย์งานจริง
โจทย์: บริษัทรับใบสั่งซื้อทางอีเมลวันละ 8,000 ฉบับ รูปแบบเหมือนกันหมด ต้องดึงเลขที่ PO, ยอดเงิน, วันที่ แล้วบันทึกลง Google Sheet คำถาม: ควรใช้ workflow หรือ AI Agent?
✅ ผลลัพธ์ที่ได้

คำตอบ: ใช้ workflow แบบ deterministic โดยมี LLM เป็นเพียง 1 node สำหรับ extraction เพราะ format คงที่และปริมาณสูง ไม่ต้องการการตัดสินใจแบบ agentic โครง: Trigger (อีเมลใหม่) → LLM node (extract 3 fields เป็น JSON) → Set node (validate) → Google Sheets node (append row)

💡 จุดสอน

เมื่องานซ้ำ format คงที่ ปริมาณสูง agent มีแต่จะเพิ่มต้นทุนและความไม่แน่นอน การให้ LLM ทำงานขอบเขตแคบใน node เดียวคือคำตอบที่ถูกที่สุดและเสถียรที่สุด

กรณีที่ควรใช้ agentic layer
โจทย์: ลูกค้าส่งคำถาม support ที่หลากหลายมาก บางครั้งต้องเช็คสถานะออเดอร์ บางครั้งต้องค้นนโยบายคืนเงิน บางครั้งต้องส่งต่อฝ่ายเทคนิค ไม่รู้ล่วงหน้าว่าต้องใช้ข้อมูลจากที่ไหน คำถาม: ควรออกแบบอย่างไร?
✅ ผลลัพธ์ที่ได้

คำตอบ: hybrid — outer workflow (trigger = ticket ใหม่, output = ร่างคำตอบ) โดยมี agentic layer ข้างในที่ให้ model เลือกเองว่าจะเรียก tool ไหน (check_order / search_policy / escalate) แล้วปิดท้ายด้วย Human-in-the-Loop ก่อนส่งจริง

💡 จุดสอน

เมื่อ path การทำงานคาดเดาไม่ได้ล่วงหน้า agentic layer คุ้มค่า แต่ยังคงล้อมด้วย outer workflow ที่ deterministic และ guardrails ที่ขอบเขตเสมอ

แบบฝึกหัดท้ายโมดูล

  1. ลองจับคู่โจทย์งาน 6 ข้อ (เช่น ส่งใบแจ้งหนี้อัตโนมัติ ตอบแชทลูกค้าที่ซับซ้อน ย้ายข้อมูลระหว่างระบบ) ว่าอันไหนควรเป็น workflow อันไหนควรเป็น agent หรือแบบผสม (hybrid) พร้อมบอกเหตุผล
  2. ลองอธิบายด้วยคำพูดของตัวเองว่าทำไมงานแบบวางขั้นตอนตายตัวถึงครองระบบใช้งานจริง แล้วยกตัวอย่างจากงานในองค์กรของคุณสัก 1 กรณี ที่ถ้าเอา agent มาใช้จะเป็นการเพิ่มต้นทุนโดยไม่จำเป็น
1.2
โมดูล 1.2

Building Blocks: Trigger, Node, Webhook และ API

ชิ้นส่วนพื้นฐานที่เอามาประกอบเป็น workflow อัตโนมัติทุกตัว

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน
💡
เปรียบง่าย ๆ: เหมือนต่อเลโก้: trigger คือชิ้นฐานที่เริ่มต้น แล้วเอา node แต่ละก้อนมาต่อกันเป็นชิ้นงาน ส่วน webhook กับ API คือ 'ปุ่มกริ่ง' และ 'ล่ามแปลภาษา' ที่ให้ระบบต่าง ๆ คุยกันได้
🎯
ทำไมต้องรู้: พอรู้จักชิ้นส่วนพื้นฐานเหล่านี้ คุณจะมองทะลุว่าระบบอัตโนมัติทุกตัวสร้างจากอะไร และประกอบมันขึ้นเองได้โดยไม่ต้องกลัวศัพท์

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

  • แยกออกว่าตัวจุดชนวน (trigger) มีกี่แบบ เช่น ตั้งเวลา (schedule/cron) รับสัญญาณจากภายนอก (webhook) มีอีเมล/แถวใหม่/ข้อความใหม่ หรือมีคนกดส่งฟอร์ม (form submit)
  • อธิบายได้ว่าก้อนงาน (node/action) เงื่อนไขแตกกิ่ง (condition/branch) และก้อนงาน AI (LLM node) แต่ละอย่างทำหน้าที่อะไรใน workflow
  • เข้าใจว่า webhook กับ API คือ "กาว" ที่เชื่อมแอปต่าง ๆ (SaaS) เข้าหากัน

เนื้อหา

ทุก workflow เริ่มจากตัวจุดชนวน (trigger) ที่ปลุกให้งานเริ่มทำงาน ซึ่งมีหลายแบบ ได้แก่ ตั้งเวลา (schedule/cron ทำตามเวลาที่ตั้งไว้) รับสัญญาณจากภายนอก (webhook คือมีสัญญาณ HTTP ส่งเข้ามา) มีเหตุการณ์ใหม่ (อีเมลใหม่ แถวใหม่ในสเปรดชีต ข้อความใหม่) หรือมีคนกดส่งฟอร์ม (form submit) จากนั้นก็ต่อด้วยก้อนงาน (node) หรือการกระทำ (action) ซึ่งก็คือขั้นตอนต่าง ๆ เช่น เรียก API แปลงข้อมูล แตกกิ่งตามเงื่อนไข (branch) หรือเรียกใช้ AI ตัวเชื่อมสำคัญคือ webhook กับ API ที่เป็นเหมือนประตูเข้า-ออกแบบ HTTP ทำให้แอปต่าง ๆ (SaaS) คุยกันได้ โมดูลนี้อยากให้คุณมองภาพ workflow ออกเป็นชิ้น ๆ ที่เอามาต่อกันได้ เพราะไม่ว่าจะใช้แพลตฟอร์มไหน แนวคิดพวกนี้ก็เหมือนกันหมด พอย้ายไปใช้เครื่องมืออื่นก็ยังเข้าใจได้ทันที

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)
Triggerตัวจุดชนวนให้ workflow เริ่มทำงาน เช่น ถึงเวลา มีอีเมล หรือมีข้อมูลใหม่
Nodeก้อนงานหนึ่งขั้นตอนใน workflow เช่น ส่งอีเมล หรือแปลงข้อมูล
Webhookเหมือนกริ่งประตูดิจิทัล พอมีเหตุการณ์เกิดขึ้น ระบบอื่นจะส่งสัญญาณมาปลุกงานของเรา
APIช่องทางมาตรฐานให้โปรแกรมคุยและแลกข้อมูลกัน เหมือนเมนูสั่งอาหารที่ทุกคนสั่งได้เหมือนกัน
Cron / Scheduleการตั้งเวลาให้งานทำงานเองตามรอบ เช่น ทุกวัน 9 โมง เหมือนตั้งนาฬิกาปลุก

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ออกแบบ trigger และ node ของ workflow แจ้งเตือน
งาน: เมื่อมีลูกค้ากรอกฟอร์มลงทะเบียนบนเว็บ ให้ส่งข้อความต้อนรับและบันทึกลงฐานข้อมูล แตกเป็น building blocks ทีละชิ้น
✅ ผลลัพธ์ที่ได้

Trigger: Webhook (รับ POST จากฟอร์ม) หรือ Form Trigger node Node 1: Set (จัดรูปข้อมูล name, email, phone) Node 2: IF (ตรวจว่ามี email ครบไหม) → true/false branch Node 3 (true): Database node (insert row) Node 4 (true): Email/LINE node (ส่งข้อความต้อนรับ) Node (false): แจ้ง error / log

💡 จุดสอน

การฝึกแตก workflow เป็น trigger + nodes + condition ทำให้คุณออกแบบระบบใดก็ได้ โดยไม่ต้องจำหน้าจอของแพลตฟอร์มใดเป็นพิเศษ

เข้าใจ webhook ในทางปฏิบัติ
อธิบายว่าเกิดอะไรขึ้นเมื่อระบบ A ส่ง webhook ไปหา workflow ใน n8n
✅ ผลลัพธ์ที่ได้

1. ระบบ A ส่ง HTTP POST พร้อม payload (JSON) ไปยัง URL ของ Webhook node 2. Webhook node รับ request นั้นและ trigger ให้ workflow เริ่ม run 3. ข้อมูลใน payload กลายเป็น input ของ node ถัดไป 4. workflow ประมวลผลและ (ถ้าตั้งไว้) ตอบกลับด้วย HTTP response

💡 จุดสอน

webhook คือ push (ระบบอื่นส่งมาหาเรา) ต่างจาก polling ที่เราไปถามเป็นระยะ การเข้าใจจุดนี้ช่วยออกแบบระบบ real-time และประหยัด execution

แบบฝึกหัดท้ายโมดูล

  1. ลองเลือกตัวจุดชนวน (trigger) ที่เหมาะกับ 5 สถานการณ์ (เช่น สรุปยอดขายทุกเช้า ตอบเมื่อมีอีเมลใหม่ ประมวลผลเมื่อมีคนกดปุ่มบนเว็บ) พร้อมบอกว่าเป็นแบบตั้งเวลา (cron) แบบรับสัญญาณ (webhook) หรือแบบตามเหตุการณ์ (event)
  2. ลองวาดผังชิ้นส่วน (building blocks) ของ workflow ที่ย้ายข้อมูลลูกค้าใหม่จากฟอร์มไปเข้าระบบจัดการลูกค้า (CRM) โดยระบุตัวจุดชนวน ก้อนงานแต่ละตัว และเงื่อนไข (condition) อย่างน้อย 1 จุด
1.3
โมดูล 1.3

n8n เบื้องต้น: แพลตฟอร์มที่ AI-native และ self-host ได้

เครื่องมือแบบลากก้อนมาต่อกัน (node-based) ที่คุมได้มากสุดและถูกสุดเมื่อใช้เยอะ เหมาะกับบริบทไทย

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน
💡
เปรียบง่าย ๆ: n8n เหมือนครัวที่คุณเป็นเจ้าของเอง จะปรุงอะไร เก็บของไว้ที่ไหน ก็คุมได้หมด ต่างจากการสั่งเดลิเวอรีที่สะดวกแต่ต้องจ่ายทุกจาน
🎯
ทำไมต้องรู้: เพราะรันบนเซิร์ฟเวอร์ตัวเองและไม่จำกัดจำนวนงาน ยิ่งใช้เยอะยิ่งคุ้ม อีกทั้งเก็บข้อมูลไว้กับตัวเองได้ ตอบโจทย์เรื่องความเป็นส่วนตัวและ PDPA ในไทย

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

  • สร้างและรัน workflow ตัวแรกบน n8n เวอร์ชันฟรี (Community Edition) ได้
  • เข้าใจว่า n8n คิดเงินต่อการรัน workflow 1 ครั้ง (execution) ไม่ใช่นับต่อขั้นตอน และก้อนงาน AI Agent (AI Agent node) ก็ฟรีในตัวแพลตฟอร์ม
  • รู้ว่ามีอะไรเปลี่ยนไปบ้างใน n8n 2.0 (ธ.ค. 2025) ที่กระทบการใช้งาน

เนื้อหา

n8n เป็นแพลตฟอร์มทำ workflow อัตโนมัติแบบลากก้อนมาต่อกัน (node-based) ที่เปิดโค้ดให้ดูได้ (fair-code license) และเอาไปรันบนเครื่องตัวเองได้ (self-host) ถือเป็นตัวที่พร้อมทำงานกับ AI มากที่สุด มีทั้งก้อนงาน AI Agent (AI Agent node) ก้อนงาน AI (LLM node) และ (ตั้งแต่ปลายปี 2025) ก้อนงาน MCP (MCP node) โดยเวอร์ชันฟรี (Community Edition) รันบนเซิร์ฟเวอร์ตัวเอง รันได้ไม่จำกัดจำนวน จ่ายแค่ค่าเซิร์ฟเวอร์ (ราว 3-7 ดอลลาร์/เดือนบน VPS สำหรับงานเล็ก ๆ) จุดเด่นเรื่องราคาที่สำคัญคือ n8n คิดเงินต่อการรัน workflow 1 ครั้ง (execution) ไม่ใช่นับเป็นรายขั้นตอน และก้อนงาน AI Agent ก็ฟรีในตัวแพลตฟอร์ม คุณจ่ายแค่ค่าใช้ AI (LLM) ของเจ้าที่เลือกเองเท่านั้น ส่วน n8n 2.0 (เวอร์ชันทดสอบ 8 ธ.ค. 2025 ตัวเต็มกลางเดือน) เป็นการปรับให้ปลอดภัยขึ้น สิ่งที่ต้องรู้ไว้คือ ก้อนงานโค้ด (Code node) จะรันแยกในกล่องปิด (sandbox) โดยอัตโนมัติ (ก้อนไหนพังหรือวนไม่หยุดก็ไม่ทำให้ทั้งระบบล่ม) และก้อนงานโค้ดจะอ่านค่าตัวแปรระบบ (env var) ไม่ได้เองอีกต่อไป (โค้ดแบบ process.env.SECRET_KEY จะพังหลังอัปเกรด ตรงนี้ต้องเตือนคนที่กำลังจะย้ายเวอร์ชัน) นอกจากนี้ยังมีก้อนงาน MCP แบบแยกเดี่ยว (Standalone MCP Client node) ตั้งค่า MCP ให้ใช้ทั้งระบบได้ และมีก้อนงานรั้วกันพลาด (Guardrails node) ไว้กรองสิ่งที่ป้อนเข้าและสิ่งที่ AI ตอบออกมา

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)
n8nแพลตฟอร์มสร้าง workflow แบบลากวางก้อนต่อกัน ที่เอามารันบนเครื่องตัวเองได้ฟรี
Self-hostการเอาโปรแกรมไปติดตั้งรันบนเซิร์ฟเวอร์ของเราเอง ไม่ต้องพึ่งคลาวด์คนอื่น
Node-basedการสร้างงานด้วยการลากก้อนงานมาต่อ ๆ กัน เห็นภาพเป็นแผนผัง ไม่ต้องเขียนโค้ด
AI-nativeออกแบบมาให้ทำงานร่วมกับ AI ได้ตั้งแต่แรก มีเครื่องมือ AI พร้อมใช้ในตัว
Community Editionเวอร์ชันฟรีของ n8n ที่เปิดให้ใช้เองได้ ไม่มีค่าใช้จ่ายลิขสิทธิ์

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

โครง workflow แรกบน n8n: สรุปอีเมลด้วย LLM
Workflow บน n8n: 1. Trigger: Gmail Trigger (อีเมลใหม่เข้า inbox) 2. AI node: Basic LLM Chain Prompt: "สรุปอีเมลนี้เป็นภาษาไทย 2 ประโยค และระบุว่าเร่งด่วนหรือไม่:\n\n{{ $json.snippet }}" 3. Node: Slack/LINE (ส่งสรุปเข้าช่องทีม)
✅ ผลลัพธ์ที่ได้

เมื่อมีอีเมลใหม่ workflow จะ run: ดึงเนื้อหา ส่งให้ LLM สรุป แล้วโพสต์สรุปพร้อมระดับความเร่งด่วนเข้าทีม การรันแต่ละครั้งนับเป็น 1 execution ไม่ว่าจะมีกี่ node

💡 จุดสอน

n8n นับ 1 execution ต่อ 1 การรัน workflow ไม่ว่ามีกี่ step ต่างจาก Zapier ที่นับ task ทำให้ n8n ถูกกว่ามากเมื่องานมีหลาย step

เตือนเรื่อง migration ไป n8n 2.0
ก่อน upgrade เป็น n8n 2.0 ตรวจสอบ: Code node ใดใน workflow ที่อ่านค่าจาก process.env?
✅ ผลลัพธ์ที่ได้

ต้องแก้: Code node ที่ใช้ process.env.SECRET_KEY หรือ env var อื่นจะพัง เพราะ 2.0 ปิดการอ่าน env var โดย default ให้ย้าย secret ไปเก็บใน credentials ของ n8n หรือ external secret store แทน

💡 จุดสอน

การปรับให้ปลอดภัยขึ้นใน 2.0 (แยกกล่องปิด + ปิดการอ่าน env var) ดีต่อความปลอดภัย แต่ทำให้ของเดิมบางอย่างพัง จึงต้องไล่ตรวจ workflow เก่าก่อนอัปเกรดทุกครั้ง

แบบฝึกหัดท้ายโมดูล

  1. ลองติดตั้ง n8n เวอร์ชันฟรี (Community Edition ผ่าน Docker หรือ npx) แล้วสร้าง workflow ที่รับสัญญาณ (webhook) แล้วตอบกลับข้อความ พร้อมเช็กว่าการรัน 1 ครั้งนับเป็น 1 execution จริงไหม
  2. ลองทำรายการตรวจเช็ก (checklist) ก่อนอัปเกรดเป็น n8n 2.0 อย่างน้อย 3 ข้อ (เช่น ตัวแปรระบบในก้อนงานโค้ด การใช้ MCP) สำหรับ workflow สมมติของคุณ
1.4
โมดูล 1.4

Zapier และ Make: ทางเลือก cloud ที่ง่ายและคุ้มค่า

เข้าใจวิธีคิดเงินและจุดแข็งของสองแพลตฟอร์มบนคลาวด์ (cloud) ยอดนิยม เพื่อเลือกให้ถูกงาน

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน
💡
เปรียบง่าย ๆ: Zapier กับ Make เหมือนบริการรับทำแทนแบบสำเร็จรูป ไม่ต้องมีครัวของตัวเอง แค่กดสั่งก็ได้เลย สะดวกมาก แต่จ่ายตามจำนวนครั้งที่ใช้
🎯
ทำไมต้องรู้: เหมาะกับคนที่อยากเริ่มเร็ว ๆ โดยไม่ต้องแตะเรื่องเทคนิค แต่ถ้าไม่เข้าใจวิธีคิดเงิน (โดยเฉพาะ Zapier ที่คิดเป็นรายงาน) พอใช้ AI เยอะ ๆ บิลอาจบานปลายได้

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

  • สร้างงานอัตโนมัติพื้นฐานได้ทั้งบน Zapier (เรียก Zap) และ Make (เรียก scenario) พร้อมเข้าใจส่วน AI ของแต่ละตัว
  • อธิบายวิธีคิดเงินได้ว่า Zapier คิดต่องาน (task) ส่วน Make คิดต่อการทำงาน (operation) และแต่ละแบบกระทบค่าใช้จ่ายยังไงเมื่อใช้ AI
  • เลือกได้ว่างานแบบไหนเหมาะกับ Zapier (งานเส้นตรง เชื่อมแอปได้เยอะ) หรือ Make (งานที่ต้องแตกกิ่งหลายทาง และคุ้มค่ากว่า)

เนื้อหา

Zapier เป็นทางที่ง่ายที่สุดสำหรับคนที่ไม่มีพื้นฐานเทคนิค เชื่อมต่อกับแอปได้เยอะที่สุดกว่า 7,000 แอป ทำงานแบบเส้นตรง (linear คือทำต่อกันไปทีละขั้น) มีเครื่องมือ AI ให้ใช้ ได้แก่ Zapier Agents (ผู้ช่วยอัตโนมัติ) Zapier Copilot (สั่งสร้าง Zap ด้วยภาษาพูดธรรมดา) และ AI actions/steps จุดที่ต้องระวังคือ Zapier คิดเงินเป็นรายงาน (task) แพ็กเกจเสียเงินเริ่มราว 19.99 ดอลลาร์/เดือน (จ่ายรายปี) ได้ 750 task แต่ AI ถูกคิดหนักกว่าปกติ ขั้นตอนแบบ Advanced AI นับเป็น 3 task ส่วน Premium นับเป็น 5 task และ Zapier Agents ยังต้องซื้อเสริมแยกต่างหาก ไม่รวมในแพ็กเกจพื้นฐาน สรุปคือถ้าใช้ agent บน Zapier อาจแพงกว่า Make ถึง 6 เท่าขึ้นไป ส่วน Make เป็นเครื่องมือสร้างงานที่เห็นภาพเป็นผัง (visual) มีตัวช่วยแตกเส้นทาง (router) ตัววนซ้ำ (iterator) และตัวรวมข้อมูล (aggregator) รองรับการแตกกิ่งหลายเส้นทาง (branching) แบบที่ Zapier เส้นตรงทำไม่ได้ ที่ต่างจาก Zapier ชัด ๆ คือ Make AI Agents และ Make Grid รวมอยู่ในทุกแพ็กเกจเสียเงินโดยไม่คิดเพิ่ม และคิดเงินต่อการทำงาน (operation) แพ็กเกจ Core ราว 9-10.59 ดอลลาร์/เดือนได้ราว 5,000 operations

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)
Zapierบริการคลาวด์เชื่อมแอปเข้าด้วยกันแบบง่ายที่สุด รองรับแอปเยอะมากกว่า 7,000 ตัว
Makeแพลตฟอร์มคลาวด์คู่แข่ง Zapier ที่คุ้มค่ากว่าและทำ logic ซับซ้อนได้มากกว่า
Integrationการเชื่อมต่อกับแอปหรือบริการอื่น เพื่อให้ส่งข้อมูลถึงกันได้
Zapชื่อเรียกงานอัตโนมัติหนึ่งชุดใน Zapier ที่ทำงานเป็นลำดับเส้นตรง
Taskหน่วยงานที่ Zapier ใช้คิดเงิน แต่ละขั้นที่ทำสำเร็จนับเป็นหนึ่ง task

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

สร้าง Zap ด้วย Copilot ภาษาธรรมชาติ
คำสั่งใน Zapier Copilot: "เมื่อมีอีเมลใหม่ใน Gmail ที่มีคำว่า 'ใบเสนอราคา' ให้สร้างการ์ดใน Trello และแจ้งเตือนใน Slack"
✅ ผลลัพธ์ที่ได้

Copilot จะร่าง Zap ให้: Trigger = Gmail (New Email Matching Search) → Action = Trello (Create Card) → Action = Slack (Send Channel Message) ผู้ใช้ตรวจและกด publish การรันแต่ละครั้งใช้ task ตามจำนวน action

💡 จุดสอน

Zapier เหมาะเมื่อต้องการเริ่มเร็วและมี integration พร้อม แต่ต้องนับ task ให้ดี โดยเฉพาะเมื่อมี AI step ที่คูณ 3 หรือ 5

ใช้ router ของ Make สำหรับ branching
Make scenario: รับ lead ใหม่ → Router แตกเป็น 2 เส้นทาง - เส้นทาง A (ถ้า budget > 100,000): ส่งเข้า SDR fast-lane - เส้นทาง B (ถ้าน้อยกว่า): เข้า nurture email sequence
✅ ผลลัพธ์ที่ได้

Router node แตก flow ออกเป็นหลายเส้นทางพร้อมเงื่อนไข filter บนแต่ละเส้น ทำให้จัดการ logic ซับซ้อนได้ใน 1 scenario ซึ่ง Zapier แบบ linear ต้องแยกหลาย Zap

💡 จุดสอน

เมื่อ logic มีการแตกกิ่งหลายทาง Make ประหยัดและจัดการง่ายกว่า อีกทั้ง AI Agents รวมในราคาแล้ว จึงคุ้มค่ากว่าเมื่อใช้ AI จริงจัง

แบบฝึกหัดท้ายโมดูล

  1. ลองสร้างงานเดียวกันทั้งบน Zapier (1 Zap) และ Make (1 scenario) เช่น บันทึกฟอร์มใหม่ลงสเปรดชีตพร้อมแจ้งเตือน แล้วเทียบดูว่าแต่ละฝั่งใช้ task กับ operation ไปเท่าไหร่
  2. ลองคำนวณต้นทุนสมมติต่อเดือนของ workflow ที่มีขั้นตอน AI วันละ 100 ครั้ง โดยเทียบระหว่าง Zapier (อย่าลืมคูณตัวคูณ multiplier) กับ Make แล้วสรุปว่าตัวไหนคุ้มกว่า
1.5
โมดูล 1.5

LLM Node แรกของคุณ: ให้ AI ทำงานใน workflow

ใส่ความสามารถ AI เข้าไปใน workflow ผ่านก้อนงาน AI (LLM node) สำหรับงานแยกประเภท สรุป และดึงข้อมูล

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน
💡
เปรียบง่าย ๆ: การวาง LLM node เหมือนจ้างพนักงานเก่ง ๆ มานั่งทำงานเฉพาะจุดหนึ่งในสายพาน เช่น คนคัดแยกจดหมาย โดยคุณต้องสั่งงานให้ชัดว่าต้องการอะไรและให้ส่งงานกลับมาในรูปแบบไหน
🎯
ทำไมต้องรู้: มันเติมความฉลาดให้ระบบทำงานที่กฎตายตัวทำไม่ได้ เช่นอ่านอีเมลแล้วสรุปหรือแยกประเภท และถ้าขอผลเป็นรูปแบบชัดเจน ขั้นตอนถัดไปก็เอาไปใช้ต่อได้ทันทีไม่มีสะดุด

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

  • ตั้งค่าก้อนงาน AI (LLM node) และเขียนคำสั่ง (prompt) ที่ให้ผลลัพธ์เชื่อถือได้กับงานขอบเขตแคบ ๆ
  • สั่งให้ AI ตอบเป็นรูปแบบระเบียบ (structured แบบ JSON) เพื่อส่งต่อให้ก้อนงานถัดไปใช้ได้เลย
  • เลือกใช้โมเดลราคาถูกกับงานส่งต่อและแยกประเภท (routing/classification) เพื่อประหยัดต้นทุน

เนื้อหา

พอเอา AI (LLM) ไปวางไว้ใน workflow แบบตายตัว หน้าที่ของมันก็คือเป็นก้อนงานเดียว (node) ที่ทำงานแคบ ๆ เช่น แยกประเภท (classify) สรุป (summarize) หรือดึงข้อมูล (extract) หัวใจอยู่ที่การเขียนคำสั่ง (prompt) ให้ชัด แล้วสั่งให้มันตอบออกมาเป็นรูปแบบระเบียบ (structured) เพื่อให้ก้อนงานถัดไปเอาไปใช้ต่อได้ทันที การบอกให้ตอบเป็น JSON ตามโครงที่เรากำหนด จะช่วยให้ผลลัพธ์นิ่งขึ้นมาก สำหรับงานส่งต่อ (routing) และแยกประเภท แนะนำให้ใช้โมเดลราคาถูก เช่น Claude Haiku, GPT-4o mini หรือ Gemini Flash-Lite เพราะงานพวกนี้ไม่ต้องคิดหนัก แล้วค่อยเก็บโมเดลตัวท็อป (premium ตัวแพง) ไว้ใช้กับงานยากจริง ๆ นี่คือวิธีประหยัดต้นทุนสำคัญที่ทุกคนควรทำตั้งแต่เริ่ม

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)
LLM Nodeก้อนงานใน workflow ที่ให้ AI ช่วยคิดหรือประมวลผลภาษาในจุดนั้น
Promptคำสั่งหรือคำถามที่เราพิมพ์บอก AI ว่าต้องการให้ทำอะไร เหมือนสั่งงานลูกน้อง
Classifyการให้ AI จัดหมวดหมู่ เช่น แยกว่าอีเมลนี้เป็นคำถามหรือคำร้องเรียน
Extractการให้ AI ดึงข้อมูลที่ต้องการออกมา เช่น ดึงเบอร์โทรจากข้อความยาว ๆ
Structured / JSONผลลัพธ์ที่จัดรูปแบบเป็นระเบียบตายตัว ให้ระบบถัดไปอ่านต่อได้ง่ายไม่งง

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

LLM node จำแนกอารมณ์ของ feedback
System: คุณเป็นตัวจำแนกอารมณ์ ตอบเป็น JSON เท่านั้น User: จำแนก feedback นี้ feedback: "อาหารอร่อยมากแต่รอนานเกือบชั่วโมง พนักงานก็ยิ้มแย้มดี" ตอบในรูปแบบ: {"sentiment": "positive|neutral|negative", "topics": [], "urgent": true|false}
✅ ผลลัพธ์ที่ได้

{"sentiment": "neutral", "topics": ["รสชาติอาหาร", "เวลารอ", "บริการ"], "urgent": false} ผลลัพธ์ JSON นี้ส่งต่อให้ node ถัดไปใช้ route เช่น ถ้า urgent = true ให้แจ้งผู้จัดการทันที

💡 จุดสอน

การบังคับ output เป็น JSON schema ทำให้ผลลัพธ์ predictable และเชื่อมต่อ node ถัดไปได้ทันที งาน classify แบบนี้ใช้โมเดลถูก (Haiku/GPT-4o mini/Flash-Lite) ก็เพียงพอ

เลือกโมเดลตามลักษณะงาน
งานใน workflow เดียว: - Step A: จัดหมวดหมู่ ticket (งานง่าย, ปริมาณสูง) - Step B: ร่างคำตอบเชิงเทคนิคที่ซับซ้อนให้ลูกค้า (งานยาก) ควรใช้โมเดลใดในแต่ละ step?
✅ ผลลัพธ์ที่ได้

Step A: GPT-4o mini / Claude Haiku / Gemini Flash-Lite (ถูก เร็ว พอสำหรับ classify) Step B: Claude Sonnet / โมเดล premium (ต้องการการให้เหตุผลและคุณภาพภาษา)

💡 จุดสอน

การใช้โมเดลถูกสำหรับ routing/classification และเก็บโมเดลแพงไว้เฉพาะงานยาก คือ cost lever พื้นฐานที่ลดค่าใช้จ่ายได้มากโดยไม่กระทบคุณภาพ

แบบฝึกหัดท้ายโมดูล

  1. ลองสร้างก้อนงาน AI (LLM node) ที่ดึงชื่อ เบอร์โทร และความต้องการ ออกมาจากข้อความสอบถามของลูกค้าให้เป็น JSON แล้วส่งต่อไปบันทึกในสเปรดชีต
  2. ลองใช้คำสั่ง (prompt) เดียวกันทั้งบนโมเดลถูกและโมเดลแพง แล้วเทียบคุณภาพผลลัพธ์ดูว่างานนี้ควรใช้โมเดลตัวไหน
1.6
โมดูล 1.6

เลือกแพลตฟอร์มให้ถูกงาน และเริ่มจากเทมเพลต

แนวทางตัดสินใจเลือกระหว่าง n8n / Make / Zapier และการเริ่มจากเทมเพลตสำเร็จรูป

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน
💡
เปรียบง่าย ๆ: เหมือนเลือกยานพาหนะให้เหมาะกับการเดินทาง จะไปใกล้ ๆ เร็ว ๆ ก็เรียกแท็กซี่ (Zapier) จะคุ้มและยืดหยุ่นก็ขับรถเอง (Make) จะคุมทุกอย่างและประหยัดระยะยาวก็ต่อรถเอง (n8n) และเริ่มจากเทมเพลตก็เหมือนขับตามแผนที่ที่คนอื่นวางไว้แล้ว
🎯
ทำไมต้องรู้: การเลือกแพลตฟอร์มให้ตรงงานตั้งแต่แรกช่วยประหยัดทั้งเงินและเวลา และการเริ่มจากเทมเพลตสำเร็จรูปทำให้เห็นผลงานจริงได้เร็วโดยไม่ต้องสร้างจากศูนย์

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

  • ใช้เกณฑ์เลือกแบบเร็ว ๆ (quick chooser) มาเลือกแพลตฟอร์มตามที่ต้องการ ทั้งเรื่องความง่าย ราคา ระดับที่คุมได้เอง และการรันบนเครื่องตัวเอง (self-host)
  • ค้นหาและหยิบเทมเพลต workflow สำเร็จรูปมาปรับใช้เป็นจุดเริ่มต้น
  • ประเมินข้อจำกัดของแต่ละแพลตฟอร์มให้ดีก่อนตัดสินใจใช้กับงานจริง

เนื้อหา

วิธีเลือกแบบเร็ว ๆ: Zapier เริ่มได้เร็วที่สุด เชื่อมต่อแอปได้เยอะที่สุด แต่แพงที่สุดเมื่อใช้ AI ส่วน Make คุ้มค่าที่สุดและทำงานที่ตรรกะซับซ้อน (logic) ได้ แต่ต้องใช้เวลาเรียนรู้ปานกลาง ส่วน n8n คุมได้มากที่สุด พร้อมทำงานกับ AI เอาไปรันบนเครื่องตัวเองได้ และถูกที่สุดเมื่อใช้เยอะขึ้น แต่ก็ต้องใช้ทักษะเทคนิคมากที่สุดเช่นกัน สำหรับเมืองไทยที่ต้องคิดเรื่องกฎหมายคุ้มครองข้อมูลส่วนบุคคล (PDPA) และการเก็บข้อมูลไว้ในประเทศ (data residency) การเอา n8n ไปรันบนเซิร์ฟเวอร์ในประเทศเองถือเป็นข้อได้เปรียบจริงที่คนพูดถึงกันบ่อย ส่วนการเริ่มจากเทมเพลตนั้นช่วยประหยัดเวลาได้มาก อย่าง n8n มีเทมเพลตฟรีกว่า 280 รายการบน GitHub เช่นชุดที่ชื่อ awesome-n8n-templates ซึ่งเป็นจุดเริ่มที่ดีสำหรับคนที่ไม่เขียนโค้ด คุณจะได้ฝึกอ่านเทมเพลต ปรับให้เข้ากับงานของตัวเอง และเข้าใจว่าแต่ละก้อนงาน (node) ทำอะไรบ้าง

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)
Templateแบบสำเร็จรูปที่มีคนทำไว้ให้แล้ว หยิบมาปรับใช้ได้เลยไม่ต้องเริ่มจากศูนย์
Learning curveความยากง่ายในการเรียนรู้ใช้งาน ยิ่งชันแปลว่ายิ่งใช้เวลากว่าจะคล่อง
Scaleการขยายปริมาณงานให้รองรับการใช้มากขึ้น โดยดูว่าต้นทุนคุ้มไหมเมื่อโตขึ้น
PDPAกฎหมายคุ้มครองข้อมูลส่วนบุคคลของไทย ที่กำหนดว่าต้องดูแลข้อมูลลูกค้าอย่างไร
Controlระดับที่เราควบคุมระบบและข้อมูลได้เอง ยิ่งสูงยิ่งปรับแต่งและดูแลเองได้มาก

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ใช้ quick chooser กับโจทย์จริง
โจทย์: โรงพยาบาลในไทยต้องการ workflow ประมวลผลข้อมูลผู้ป่วย โดยข้อมูลห้ามออกนอกประเทศ และต้องมี audit log สำหรับ compliance ควรเลือกแพลตฟอร์มใด?
✅ ผลลัพธ์ที่ได้

เลือก n8n แบบ self-host ในไทย เพราะข้อมูลไม่ออกนอก infrastructure ของโรงพยาบาล ได้ audit log สำหรับ PDPA compliance และควบคุมได้เต็มที่ ต่างจาก Zapier/Make ที่เป็น cloud-only

💡 จุดสอน

สำหรับอุตสาหกรรมที่มีข้อกำหนด (สุขภาพ การเงิน ภาครัฐ) ในไทย ความสามารถ self-host ของ n8n เพื่อ data residency คือปัจจัยตัดสินที่เหนือกว่าความง่ายของ cloud

ปรับใช้เทมเพลตจาก awesome-n8n-templates
เลือกเทมเพลต RAG chatbot จาก collection awesome-n8n-templates มาปรับ: - เปลี่ยนแหล่งข้อมูลจากตัวอย่างเป็น Google Drive ของบริษัท - เปลี่ยน LLM node เป็นโมเดลที่ต้องการ - ปรับ prompt เป็นภาษาไทย
✅ ผลลัพธ์ที่ได้

ได้ RAG chatbot ที่ทำงานกับเอกสารบริษัทจริงในเวลาไม่กี่ชั่วโมง แทนที่จะสร้างจากศูนย์ โดยเข้าใจโครงสร้าง node ที่เทมเพลตวางไว้ให้แล้ว

💡 จุดสอน

การเริ่มจากเทมเพลตที่มีคนพิสูจน์แล้วเป็นวิธีเรียนรู้ที่เร็วที่สุด และลดโอกาสผิดพลาดในการออกแบบ workflow ครั้งแรก

แบบฝึกหัดท้ายโมดูล

  1. ลองทำตารางเทียบ n8n, Make และ Zapier ในแง่ความง่าย ราคาเมื่อใช้ AI ระดับที่คุมได้เอง และการรันบนเครื่องตัวเอง (self-host) แล้วเลือกแพลตฟอร์มให้กับ 3 โจทย์งานในองค์กรของคุณ
  2. ลองหาเทมเพลตจาก awesome-n8n-templates ที่ใกล้เคียงงานของคุณสัก 1 อัน นำเข้ามาใน n8n ปรับอย่างน้อย 2 จุด แล้วรันให้ทำงานได้จริง

🎯 โปรเจกต์ย่อย (Mini-Project): ระบบสรุปและแจ้งเตือนอีเมลอัตโนมัติแบบครบวงจร

  1. ออกแบบ workflow ที่เริ่มทำงานเมื่อมีอีเมลใหม่ ให้ดึงเนื้อหาออกมา แล้วใช้ก้อนงาน AI (LLM node) สรุปเป็นภาษาไทยและจำแนกว่าเร่งด่วนแค่ไหน โดยตอบออกมาเป็น JSON
  2. แตกกิ่งด้วยเงื่อนไข (condition): ถ้าเร่งด่วนให้แจ้งเตือนทันทีผ่าน LINE/Slack ถ้าไม่เร่งด่วนก็บันทึกลงสเปรดชีตสรุปรายวัน
  3. เลือกและให้เหตุผลว่าจะใช้แพลตฟอร์มไหน (n8n/Make/Zapier) และใช้โมเดล AI ตัวไหน พร้อมประมาณต้นทุนต่อเดือน
  4. ลองทดสอบด้วยอีเมลตัวอย่างอย่างน้อย 5 แบบ แล้วจดไว้ว่าระบบจำแนกถูกต้องไหม พร้อมเสนอวิธีปรับคำสั่ง (prompt) ให้ดีขึ้น
ก้าวต่อไป

Intermediate: สร้าง AI Agent จริง ต่อ RAG และเชื่อมด้วย MCP

ไปต่อ →