ติดตามหัวข้อและเหตุการณ์ตามเงื่อนไข | Gemini Spark ฉบับเข้าใจง่าย | Vibe Coding Thailand$ cat 14-topic-monitor.md บทที่ 14ติดตามหัวข้อและเหตุการณ์ตามเงื่อนไข
Topic Monitor ไม่ใช่การสั่งให้ AI วิ่งไปค้นหาบนเว็บซ้ำๆ ทุก 5 นาที และไม่ใช่ระบบแจ้งเตือนแบบเรียลไทม์ (Real-time Alert) ทันทีทันใด แต่คือ Schedule ประเภทหนึ่งที่คอย “เฝ้ารอเงื่อนไขหรือเหตุการณ์ที่กำหนด” เกิดขึ้นก่อน แล้วจึงเริ่มต้นรัน Task ซึ่ง Google เองได้ระบุไว้อย่างชัดเจนว่าระบบ Monitor ยังไม่เหมาะกับข้อมูลที่มีความผันผวนรวดเร็ว หรืองานที่ต้องการความแม่นยำระดับวินาที (เช่น การเฝ้าแจ้งเตือนตั๋วคอนเสิร์ตเปิดขายเพื่อรีบกดซื้อ)
ในบทนี้เราจะมาทดลองสร้าง Topic Monitor จริง โดยใช้วลีสมมุติที่ไม่มีทางปรากฏอยู่บน Gemini Blog และกำหนดให้รายงานผลเฉพาะภายใน Task Thread เท่านั้น จากนั้นเราจะสั่ง Pause ทันทีหลังจากเก็บภาพหลักฐาน เพื่อให้เห็นหน้าตาการทำงานจริงบน UI โดยไม่เปิดทิ้งไว้ให้เกิดการแจ้งเตือนรบกวนในภายหลัง
3 ประตูกลั่นกรองของ Monitor ที่รัดกุม
หากเงื่อนไขผ่านไม่ครบทุกประตู = ไม่ต้องทำอะไร · หากผ่านครบทุกประตู = สรุปรายงานเฉพาะขอบเขตที่อนุญาต · และยังต้องตรวจสอบแหล่งที่มากับเวลาจริงเสมอ
3 ประตูของระบบทดลองในบทนี้:
- โดเมน (Domain): ต้องเป็น
blog.google/products/gemini เท่านั้น
- วันที่ (Date): ต้องเป็นบทความที่เผยแพร่หลังวันที่ 20 สิงหาคม 2026
- วลีตรงตัว (Exact Match): ต้องมีข้อความตรงตัวว่า
spark-book-demo-trigger-never-2026-08-20
การใช้เงื่อนไขแบบ “และ (AND)” เชื่อมทั้ง 3 ประตูเข้าด้วยกัน จะช่วยลดปัญหา False Positive (การแจ้งเตือนพร่ำเพรื่อเมื่อไม่ใช่เหตุการณ์จริง) แต่ก็อาจเพิ่มความเสี่ยงเรื่อง False Negative (การพลาดข่าวสารหากบทความใช้คำไม่ตรงกับวลีที่ตั้งไว้) ซึ่งเป็นสิ่งที่เราต้องชั่งน้ำหนักตามลักษณะของงาน ไม่ใช่ตั้งเงื่อนไขให้กว้างเกินไปเสมอ
ขั้นตอนการสร้างผ่าน Create with Gemini
Topic Monitor และ Gmail Monitor ต้องสร้างด้วยการสั่งงาน Gemini ด้วยภาษาธรรมชาติ (ส่วนฟอร์ม Create manually จะใช้ได้เฉพาะกับ Schedule ที่ตั้งตามวันเวลาเท่านั้น):
- เปิดหน้า Schedules จากแถบด้านข้าง
- คลิกปุ่ม Create with Gemini
- พิมพ์ระบุชื่อ Monitor, เงื่อนไขที่ต้องการตรวจจับ และสิ่งที่ให้ทำเมื่อพบเหตุการณ์
- ระบุชัดเจนว่า “หากเงื่อนไขไม่ครบ ให้ไม่ต้องทำอะไร”
- จำกัดช่องทางการรายงานผลและการกระทำ
ตรวจสอบรายละเอียดสิ่งที่ระบบสร้างขึ้นมาจริง
ผลลัพธ์ที่ได้จะแสดงชื่อ Monitor, เป้าหมายการติดตาม, สิ่งที่ต้องทำเมื่อพบเงื่อนไข และระบุสถานะว่าเริ่มเฝ้าตรวจจับตามเงื่อนไขโดยไม่รันทันที ใน work panel จะแสดงหมวด Schedules และช่อง Files ว่างเปล่า:
ไม่มีการเรียกใช้ Google Search หรือ Connected Apps ในขั้นตอนการสร้างตัว Monitor · ยังไม่มีบทความที่ตรงตามเงื่อนไขเกิดขึ้น และไม่มีการส่งผลแจ้งเตือนใดๆจุดที่ต้องตรวจสอบจากผลลัพธ์:
- ชื่อ Monitor ถูกต้องตรงตามที่ตั้งใจ
- โดเมนต้นทาง (Source Domain) ระบุเฉพาะเจาะจง ไม่เปิดกว้างทั้งเว็บ
- วันที่ถูกนำไปใช้เป็นเงื่อนไขในการกรองจริง ไม่ใช่ข้อความบรรยายลอยๆ
- วลีแบบ Exact Match ถูกบันทึกไว้ครบถ้วน
- การกระทำ (Action) มีเพียงการสรุป 3 บรรทัดใน Task Thread
- ไม่มีการผูกคำสั่งส่งอีเมล สร้างนัดหมาย สร้างไฟล์ หรือสั่งซื้อใดๆ
กด Pause ทันทีหลังยืนยันความถูกต้องบน UI
เมื่อเปิดไปที่หน้า Schedules จะพบ Topic Monitor อยู่ในกลุ่ม Ongoing พร้อมสถานะ Waiting to run จากนั้นให้คลิกที่เมนู More (จุดสามจุด) → Pause เพื่อย้ายไปยังกลุ่ม Paused:
สถานะ Ongoing หมายถึงระบบพร้อมที่จะเฝ้าตรวจจับเหตุการณ์ ไม่ได้แปลว่าเงื่อนไขนั้นเคยเกิดขึ้นแล้ว
เราปรับสถานะของ Monitor ให้อยู่ในกลุ่ม Paused เพื่อหยุดการทำงานไว้หลังจากเสร็จสิ้นการทดลองการกด Pause แตกต่างจาก Delete เพราะโครงสร้างของเงื่อนไขยังคงอยู่ ทำให้เราสามารถกลับมาตรวจสอบ แก้ไข หรือกด Resume เพื่อเปิดใช้งานใหม่ได้เสมอ (โดยก่อนกด Resume เราต้องกลับมาทบทวนเงื่อนไขและปลายทางของคำสั่งใหม่อีกครั้งเสมอ)
แยกแยะสัญญาณ (Signal) ออกจากการกระทำ (Action) เสมอ
การออกแบบ Monitor ที่ปลอดภัยควรแบ่งโครงสร้างออกเป็น 2 ส่วนชัดเจน:
1. สัญญาณ (Signal)
หลักฐานที่ใช้พิสูจน์ว่าเหตุการณ์เกิดขึ้นจริง เช่น URL, วันที่เผยแพร่, วลีที่ตรงกัน, ระดับราคา หรือสถานะเฉพาะจากแหล่งที่ระบุ
2. การกระทำ (Action)
สิ่งที่จะให้ทำหลังจากตรวจพบสัญญาณ เช่น การสรุปประเด็น, การแจ้งเตือนใน Task Thread, การร่างข้อความ หรือการเสนอช่วงเวลา
หากการกระทำนั้นมีผลกระทบต่อระบบจริง ในขั้นแรกควรจำกัดขอบเขตไว้แค่ “การแจ้งเตือนหรือการร่างข้อความ” เท่านั้น ห้ามสั่งให้ส่งอีเมล, สั่งซื้อสินค้า, ทำการจอง หรือแก้ไขปฏิทินแบบอัตโนมัติใน Monitor เดียวกัน
แม่แบบ Monitor ที่ปลอดภัย:
แนวทางป้องกัน False Positive และ False Negative
| ปัญหาที่พบ | ตัวอย่างสถานการณ์ | แนวทางป้องกัน |
|---|
| False Positive (แจ้งเตือนผิดเรื่อง) | พบคำสำคัญเดียวกันแต่คนละบริบท | เพิ่มตัวกรองโดเมน, ระบุช่วงวันที่ และเพิ่มเงื่อนไขร่วม (AND) |
| False Negative (พลาดข่าวสำคัญ) | หน้าเว็บใช้คำพ้องความหมาย (Synonyms) | กำหนดรายการคำค้นหาที่ยอมรับได้ และทดสอบความครอบคลุม |
| แหล่งข่าวเปลี่ยน URL | โครงสร้างโฟลเดอร์ของเว็บไซต์เปลี่ยนไป | ตรวจเช็กเส้นทาง Domain/Path เป็นระยะ |
| เนื้อหาถูกแก้ไขย้อนหลัง | วันที่เผยแพร่เดิมแต่ข้อความข้างในเปลี่ยน | บันทึกเวลาที่ Monitor ตรวจพบควบคู่กับ URL ต้นทาง |
| การแจ้งเตือนซ้ำซ้อน | หน้าเว็บเดิมถูกตรวจพบหลายรอบ | ระบุให้บันทึกรหัสเหตุการณ์หรือ URL ที่เคยแจ้งเตือนไปแล้ว |
อย่าแก้ปัญหา False Negative ด้วยการตัดเงื่อนไขทิ้งจนเหลือเพียงหัวข้อกว้างๆ เพราะปริมาณการแจ้งเตือนที่ผิดพลาดจะสร้างภาระมากกว่าประโยชน์
งานที่ไม่ควรนำระบบ Monitor มาใช้งาน
- งานฉุกเฉินหรืองานด้านความปลอดภัยในชีวิตและทรัพย์สิน
- การติดตามราคาซื้อขายหุ้น, การชำระเงิน หรือธุรกรรมที่จะเสียหายหากล่าช้า
- การเฝ้าตั๋วคอนเสิร์ตหรือสินค้าลิมิเต็ดที่ต้องแย่งกันซื้อทันที
- การเฝ้าระวังระบบเซิร์ฟเวอร์หรือ Production ล่ม
- งานที่ต้องการการการันตีเวลาทำงานระดับวินาที
- การตัดสินใจด้านสุขภาพ กฎหมาย การเงิน หรือเรื่องส่วนบุคคล
ระบบ Monitor อาจมีความล่าช้าในการประมวลผล อาจไม่ทำงานเมื่อบัญชีติด Usage Limit หรือเมื่อมี Task ทำงานพร้อมกันเต็มขีดจำกัด จึงจำเป็นต้องใช้ระบบแจ้งเตือนเฉพาะทางสำหรับเหตุการณ์ที่มีความสำคัญระดับวิกฤต
จุดที่ต้องตรวจก่อนปล่อยต่อ
- สัญญาณ (Signal) มีการระบุแหล่งข้อมูล วันที่ และเงื่อนไขที่ตรวจสอบได้จริง
- แยกแยะคำสั่งส่วน Action ออกจากเงื่อนไข Signal อย่างชัดเจน
- มีคำสั่งกำชับชัดเจนว่า “หากไม่ครบทุกเงื่อนไข ให้ไม่ต้องทำอะไร”
- รายงานผลที่แจ้งเตือนต้องมี URL ต้นทางและเวลาที่ตรวจพบแนบมาด้วยเสมอ
- ไม่นำ Monitor ไปใช้กับงานที่มีความอ่อนไหวเรื่องเวลา (Time-critical)
- ในรอบแรก ห้ามผูก Action ที่มีการส่งข้อมูล สั่งซื้อ ทำการจอง หรือแก้ไขข้อมูลจริง
- หน้า Schedules แสดงชื่อและสถานะของ Monitor ตรงตามที่ตั้งใจ
- หลังจากการทดสอบเสร็จสิ้น ให้กด Pause Monitor ก่อนเสมอ
- ก่อนจะกด Resume ให้กลับมาทบทวนแหล่งข้อมูล, Action และโควตาการใช้งานใหม่อีกรอบ
ลองเลย
ทดลองสร้าง Topic Monitor โดยใช้วลีสมมุติที่ไม่มีทางเกิดขึ้นจริง กำหนดโดเมนและช่วงวันที่ให้แคบ และตั้งให้ Action รายงานผลเฉพาะใน Task Thread เท่านั้น เมื่อเห็นรายการปรากฏในกลุ่ม Ongoing ให้กด Pause ทันที จากนั้นตรวจดูว่าชื่อ เงื่อนไข และปลายทางบันทึกไว้ถูกต้องหรือไม่ (ห้ามใช้หัวข้อฉุกเฉิน ราคาหุ้น หรือการเฝ้าตั๋วในการทดลอง)
เมื่อเราเข้าใจวิธีติดตามเหตุการณ์บนโลกภายนอกแบบมีเงื่อนไขรัดกุมแล้ว ในสูตรถัดไปเราจะย้ายไปสู่การจัดการงานธุระบนเว็บ ซึ่งมีความเสี่ยงเพิ่มขึ้นจากการเข้าสู่ระบบ (Login), ข้อมูลที่อาจส่งออกไปภายนอก และการโจมตีผ่าน Prompt Injection จึงต้องเข้าใจจังหวะการรับช่วง (Take over) มาทำต่อด้วยตัวเองอย่างชัดเจน
อัปเดตล่าสุด: 21 ส.ค. 2569
ความคิดเห็น
ยังไม่มีความคิดเห็น
เป็นคนแรกได้เลย