เครื่องมือ AI ทุกตัวมักเจอปัญหาคล้ายกัน ถ้าเขียนได้ตรงโทนที่สั่ง ก็มักแต่งตัวเลขที่ไม่มีในเอกสารต้นทาง แต่ถ้าเกาะเอกสารต้นทางได้แม่น ก็มักส่งผลลัพธ์มาเป็นกำแพงตัวอักษรก้อนเดียวที่ต้องจัดรูปแบบใหม่ทั้งหมด ในคลิป "Gemini Gems + NotebookLM is INSANE (Try This Today)" Parker Prompts สาธิตวิธีต่อเครื่องมือฟรีของ Google สองตัวเข้าด้วยกัน เพื่อปิดช่องว่างนี้ด้วย 3 ระบบที่เขาใช้ทำงานเอกสารและบริการลูกค้าจริงทุกวัน
บทความนี้เรียบเรียงจากคลิปต้นทางของ Parker Prompts เป็นหลัก โดยถอดสูตรหลักที่เขาเรียกว่า PACT พร้อมขั้นตอนของระบบทั้งสามที่เขาสาธิตในคลิป เพื่อให้ผู้ที่ทำงานเอกสาร ทำคอนเทนต์ หรือดูแลลูกค้าในไทยนำไปประยุกต์ได้ทันที
ปัญหาที่ Parker Prompts ชี้: AI ตัวเดียวทำได้ไม่ครบ
Parker เปิดคลิปด้วยปัญหาที่เขาเจอเอง คือ AI ส่วนใหญ่เก่งได้อย่างใดอย่างหนึ่งระหว่าง "เขียนตรงโทน" กับ "อ้างอิงเอกสารแม่น" แต่ไม่เก่งทั้งสองด้านพร้อมกัน ตัวอย่างที่ Parker ยกในคลิปคือผู้ช่วยที่เขียนได้ในสำเนียงที่ตั้งไว้ แต่กลับใส่ตัวเลขสถิติที่ไม่ปรากฏในเอกสารต้นทาง หรือผู้ช่วยที่อ้างอิงเอกสารได้ครบ แต่กลับส่งคำตอบมาเป็นบล็อกข้อความก้อนใหญ่ที่ต้องจัดใหม่ทุกครั้ง
ปัญหานี้ยิ่งหนักขึ้นเมื่อบทสนทนากับ Gemini ยาวขึ้น เพราะ Parker อธิบายว่า Gemini จะเริ่ม "ลืม" คำสั่งที่กำหนดตั้งแต่ต้น และค่อยๆ ดริฟต์ออกจากแนวที่วางไว้ ผลลัพธ์ในแชตที่ 50 จึงต่างจากแชตแรกอย่างชัดเจน จุดอ่อนนี้ทำให้ใช้ AI เป็น "ระบบ" ระยะยาวไม่ได้ ใช้ได้เพียงเครื่องมือเฉพาะกิจ
วิธีที่ Parker Prompts เสนอจึงไม่ใช่การเปลี่ยนโมเดล แต่เป็นการประกอบเครื่องมือสองตัวของ Google เข้าด้วยกัน เพื่อเอาจุดแข็งของแต่ละตัวมาเติมจุดอ่อนของอีกตัวพอดี
NotebookLM กับ Gemini Gems: เครื่องมือฟรีที่ทำคนละหน้าที่
NotebookLM คือเครื่องมือของ Google ที่ออกแบบมาเพื่อ "ผูกคำตอบไว้กับเอกสารต้นทาง" โดยเฉพาะ Parker อธิบายว่าทุกคำตอบที่ NotebookLM ส่งกลับมาจะระบุที่มาให้ตรวจสอบได้ว่าข้อมูลแต่ละชิ้นมาจากไฟล์ไหน หน้าไหน จึงไม่เดาเองหรือดึงข้อมูลภายนอกมาปน จุดนี้คือสิ่งที่ Parker เรียกว่า "grounding" และเป็นเหตุผลที่ NotebookLM เหมาะกับงานที่แตะข้อมูลจริงขององค์กร เช่น นโยบาย ราคา หรือผลงานเก่า
ส่วน Gemini Gems คือ Gemini เวอร์ชันที่บันทึกคำสั่งไว้ถาวร Parker อธิบายว่า gem หนึ่งตัวประกอบด้วยช่องตั้งค่าหลัก ได้แก่ ชื่อ คำอธิบาย และช่องคำสั่ง พร้อมตัวเลือกเครื่องมือเริ่มต้น เช่น สร้างภาพ ทำ deep research สร้างวิดีโอ หรือสร้างเพลง และยังมีส่วนคลังความรู้ที่อัปโหลดไฟล์อ้างอิงเข้าไปได้ ข้อดีคือระบบล็อกคำสั่งทั้งหมดไว้ ทำให้ผลลัพธ์ในการใช้งานครั้งที่ 1 กับครั้งที่ 50 ออกมาเป็นแนวเดียวกัน
จุดที่ Parker เน้นในคลิปคือเครื่องมือทั้งสองตัวนี้เปิดให้ใช้งานฟรี และเชื่อมต่อกันได้ผ่านระบบนิเวศของ Google โดยใช้ Google Drive เป็นตัวกลางในการส่งต่อเอกสารระหว่างกัน ซึ่งทำให้การต่อสองเครื่องมือเป็นเรื่องที่ทำได้โดยไม่ต้องเขียนโค้ดหรือใช้ API
สูตร PACT: โครงคำสั่งที่ทำให้ gem ทำงานได้จริง
ในคลิป Parker ตั้งชื่อโครงคำสั่งที่ใช้กับทุก gem ว่า PACT ซึ่งย่อมาจาก Persona, Assignment, Context, Template โดยอธิบายว่าโครงนี้คือสิ่งที่ทำให้คำสั่งของ gem มีระเบียบและให้ผลลัพธ์ที่คาดเดาได้ทุกครั้ง
ตัวอย่างที่ Parker สาธิตในคลิปคือ gem ชื่อ Email Drafter โดยใส่ Persona ว่า "เป็นนักสื่อสารธุรกิจสไตล์ตรงไปตรงมาที่ให้คุณค่ากับความกระชับ" ใส่ Assignment ว่า "ร่างอีเมลถึงลูกค้าตามสถานการณ์ที่ระบุ" ใส่ Context ว่า "ให้อีเมลทุกฉบับไม่เกิน 150 คำ ไม่ใช้คำเสริมที่ไม่จำเป็น ปิดท้ายด้วยขั้นตอนถัดไปที่ชัดเจน และใช้โทนเป็นมิตรแต่ไม่กันเอง" และใส่ Template ว่า "หัวเรื่อง คำทักทาย เนื้อหาแบ่งเป็น 2 ย่อหน้าสั้น และปิดท้ายด้วยขั้นตอนถัดไปที่ระบุชัด"
หลังเซฟ gem และพิมพ์โจทย์เพียงสั้นๆ ว่า "ร่างอีเมลติดตามลูกค้าที่ยังไม่ตอบใบเสนอราคาใน 5 วัน" gem จะตอบกลับมาด้วยอีเมลที่ตรงโทนและตรงโครงสร้างทันที โดยไม่ต้องอธิบายซ้ำ Parker เน้นว่าจุดสำคัญคือถ้าสั่งให้ร่างอีเมลติดตามอีก 10 ครั้งในเดือนถัดมา ผลลัพธ์ทุกครั้งจะออกมาตามกรอบเดิม เพราะบันทึกคำสั่ง PACT ไว้แล้ว ไม่ได้ลอยอยู่ในบทสนทนาที่จะถูกลืม
โครงนี้ใช้ได้กับทุก gem ที่จะสร้างต่อไป โดยเปลี่ยน Persona ให้เข้ากับงาน เปลี่ยน Assignment ให้ตรงผลลัพธ์ที่ต้องการ ส่วน Context และ Template คือชั้นคุมคุณภาพที่กันไม่ให้ผลลัพธ์ดริฟต์
ทำไม Parker จึงต่อ NotebookLM เข้ากับ Gem
ถึงแม้ gem จะจำคำสั่งได้แม่นยำ แต่ Parker ชี้ว่ายังมีช่องโหว่หนึ่งคือ gem ยังคงดริฟต์ได้เมื่อต้องอ้างอิงเอกสารหนาๆ ที่มีตัวเลขหรือนโยบายเฉพาะ เพราะ gem มีแนวโน้มจะถอดความแบบหลวมๆ หรือเติมรายละเอียดที่ "ฟังดูใช่" แต่ไม่ปรากฏในเอกสารจริง ส่วน NotebookLM ออกแบบมาเพื่อแก้ปัญหานี้โดยตรง เพราะทุกคำตอบจะอิงเอกสารที่อัปโหลดเท่านั้น
การจับคู่จึงเป็นการแบ่งหน้าที่ที่ชัดเจน ตามที่ Parker สรุปในคลิปว่า NotebookLM ดูแลความรู้และทำให้ข้อมูลแม่นยำ ส่วน gem ดูแลพฤติกรรมและทำให้ผลลัพธ์คงเส้นคงวา เมื่อแชร์ gem ให้ทีมใช้ร่วมกันได้ผ่านปุ่มแชร์ในหน้า gem ระบบนี้จึงไม่ใช่แค่เครื่องมือส่วนตัว แต่กลายเป็นระบบของทั้งทีมที่ใช้ความรู้และกฎเดียวกัน
3 ระบบจริงที่ Parker สร้างจากคู่หูนี้
หลังจากวางสูตร Parker พาไปดู 3 ระบบที่เขาใช้งานจริงในแต่ละวัน ระบบแรกคือ Research-to-Content ที่ลดเวลาเขียนบทความ ระบบที่สองคือ Proposal Writer ที่ใช้ปิดดีลลูกค้า และระบบที่สามคือ Support Assistant ที่ใช้ตอบลูกค้า แต่ละระบบมีโครงคล้ายกัน: NotebookLM เก็บความรู้และส่งต่อไฟล์อ้างอิงไป Google Drive ส่วน gem ใน Gemini ดึงไฟล์มาใช้สร้างผลลัพธ์ในโทนที่กำหนด
ระบบที่ 1: Research-to-Content Writer
Parker เล่าว่าเดิมเขาแยกงานวิจัยกับงานเขียนเป็นคนละขั้นตอน ใช้เวลาหนึ่งชั่วโมงอ่านบทความ ดึงสถิติ จดโน้ต แล้วเปิดเอกสารเปล่าเพื่อเขียนใหม่ตั้งแต่ต้น ระบบใหม่ปิดช่องว่างนี้ด้วยขั้นตอนต่อไปนี้
เริ่มใน NotebookLM โดยสร้าง notebook ใหม่ อัปโหลดแหล่งข้อมูล เช่น บทความจากคู่แข่ง และรายงานเครื่องมือเพิ่มประสิทธิภาพปี 2026 จากนั้นสลับช่องคำสั่งเป็น Deep Research แล้วพิมพ์โจทย์ เช่น "ค้นหาแหล่งข้อมูลเพิ่มเติมเกี่ยวกับเครื่องมือเพิ่มประสิทธิภาพ AI และวิธีที่ธุรกิจนำมาใช้ในปี 2026" Deep Research จะออกไปขุดข้อมูลจากหลายสิบแหล่ง เมื่อเสร็จแล้วกดนำเข้าไปไว้ใน notebook ถ้ามีแหล่งใดโหลดไม่สำเร็จ ก็คลิกขวาลบทิ้งเพื่อให้ฐานข้อมูลสะอาด
ขั้นถัดไปคือเปิดแผง Studio ทางขวา เลือก Reports แล้วเลือก Create my own พร้อมอธิบายว่าต้องการบทสรุปแบบไหน NotebookLM จะสร้าง research brief ที่ผูกทุกข้อกับเอกสารต้นทาง ทำให้ตรวจสอบที่มาของทุกประโยคได้ จากนั้นส่งออกไป Google Docs ซึ่งจะเซฟลง Google Drive อัตโนมัติ
ต่อมาเปิด Gemini แล้วสร้าง gem ใหม่ชื่อ Content Writer จากนั้นใส่สูตร PACT เต็มรูปแบบ Parker เน้นว่าไม่ต้องอัปโหลดงานวิจัยใดเข้าไปในช่องคลังความรู้ของ gem เพราะ gem ตัวนี้จะเก็บเฉพาะสไตล์การเขียน โทน กฎการจัดรูปแบบ และโครงเนื้อหา เมื่อไม่ผูกกับหัวข้อใดหัวข้อหนึ่ง gem ตัวนี้จึงนำไปใช้ซ้ำกับเรื่องใดก็ได้
เมื่อจะใช้งาน Parker เปิด Google Docs แล้วคลิกไอคอน Gemini มุมขวาบนเพื่อเรียกแถบด้านข้าง กดเครื่องหมายบวกในช่องคำสั่งเพื่อเปิดสิทธิ์เข้าถึง Drive Search, Gmail Search, Chat Search และ Web Search จากนั้นเลือก gem ชื่อ Content Writer แล้วพิมพ์โจทย์ เช่น "มี research brief ใน Drive ชื่อ AI productivity trends 2026 ให้อ่านและเขียนบทความ 1,200 คำตามผลที่พบ และใช้โครงสร้างกับโทนตามคำสั่งของ gem" gem จะดึงรายงานจาก Drive อ่านข้อมูลที่ตรวจสอบแล้ว และเขียนบทความฉบับเต็มในเสียงของผู้ใช้งานทันที กระบวนการตั้งแต่อัปโหลดแหล่งข้อมูลจนได้ต้นฉบับใช้เวลาประมาณ 15 นาที
ระบบที่ 2: Proposal Writer
Parker เล่าว่าเขาเคยจับเวลาเขียนใบเสนอราคา พบว่าเฉลี่ยแล้วใช้เวลาประมาณ 50 นาทีต่อหนึ่งลูกค้า เพราะต้องไล่หาโครงเก่า คัดลอกส่วนที่เคยใช้ได้ ปรับขอบเขตงาน และเขียนราคาใหม่ จนสุดท้ายได้ใบเสนอราคาที่ราว 80% เป็นการเรียบเรียงใหม่จากของเก่าอยู่ดี ระบบใหม่ของ Parker ลดเวลาตรงนี้เหลือประมาณ 15 นาที
ขั้นตอนเริ่มใน NotebookLM โดยสร้าง notebook ชื่อ business knowledge base แล้วอัปโหลดทุกอย่างที่นิยามการทำงานของธุรกิจ ทั้ง case study พร้อมผลลัพธ์จริง รายละเอียดบริการ และตารางราคา จากนั้นเข้า Studio แล้วสั่ง Create my own เพื่อสร้างเอกสารอ้างอิงรวม ซึ่ง NotebookLM จะจัดราคาให้เป็นระเบียบ สรุป case study พร้อมประเภทลูกค้า ขอบเขต และผลลัพธ์ แล้วเซฟไปไว้ใน Drive
ต่อมาสร้าง gem ใน Gemini ชื่อ Proposal Writer พร้อมเขียนคำสั่งตามสูตร PACT เมื่อมีลูกค้าใหม่เข้ามา Parker เปิด Google Docs เปิด Drive Search เลือก gem แล้วอธิบายโจทย์สั้นๆ เช่น "มีเอกสารอ้างอิงหลักใน Drive ชื่อ business knowledge base ให้ใช้ในการเขียนใบเสนอราคาสำหรับงานปรับปรุงเว็บไซต์ของแบรนด์อีคอมเมิร์ซขนาดกลาง งบประมาณราว 15,000 ดอลลาร์ ระยะเวลา 8 สัปดาห์ ลูกค้าให้ความสำคัญกับอัตราการแปลงและประสบการณ์บนมือถือ"
gem จะดึงเอกสารอ้างอิงจาก Drive อ่านโครงสร้างราคา หา case study ที่เกี่ยวข้องสองชิ้น แล้วร่างใบเสนอราคาฉบับเต็มที่มีขอบเขตโครงการ ระยะเวลา การแบ่งราคา และอ้างอิง case study Parker ย้ำว่าถ้าไม่มีขั้น NotebookLM gem จะเดาราคาและแต่งรายละเอียด case study ขึ้นมา แต่ในระบบนี้ gem ดึงตัวเลขจริงจากตารางราคาและอ้างอิงโปรเจกต์ที่เคยทำจริง เมื่อแชร์ gem ตัวนี้ให้ทีมผ่านปุ่มแชร์ในหน้า gem ทุกคนในบริษัทก็สร้างใบเสนอราคาด้วยเอกสารอ้างอิงและกฎชุดเดียวกันได้โดยไม่ต้องผ่าน Parker
ระบบที่ 3: Support Assistant
ระบบสุดท้ายที่ Parker สาธิตคือผู้ช่วยตอบลูกค้า เขาออกแบบมาเพื่อแก้ปัญหาที่พบบ่อยในร้านอีคอมเมิร์ซและธุรกิจแบบ subscription: คำถามซ้ำๆ ที่เข้ามาทุกวัน และคำตอบทุกครั้งต้องตรงนโยบาย ตรงโทนแบรนด์ ไม่ว่าใครในทีมจะเป็นคนตอบ Parker ยกตัวอย่างปัญหาที่เกิดขึ้นจริงว่า ถ้าทีมหนึ่งคนบอกลูกค้าว่าคืนสินค้าได้ภายใน 30 วัน แต่อีกคนบอก 14 วันเพราะจำผิด ความน่าเชื่อถือก็เสียทันที
ขั้นตอนเริ่มที่ NotebookLM สร้าง notebook ชื่อ support knowledge base แล้วอัปโหลดเอกสารหลัก ได้แก่ หน้า FAQ นโยบายการคืนสินค้าและคืนเงิน นโยบายการจัดส่ง เงื่อนไข subscription และคู่มือเสียงแบรนด์ Parker ใช้ห้าไฟล์ในการสาธิต แต่ระบุว่าระบบรองรับเอกสารหลายสิบไฟล์ได้
ต่อมาเข้า Studio เพื่อสร้าง briefing doc จาก Reports โดย NotebookLM จะบีบเอกสารทั้งห้าให้เหลือเอกสารอ้างอิงโครงสร้างเดียวที่ครอบคลุมนโยบายหลัก กรณีพิเศษ และกฎเสียงแบรนด์ จากนั้นสั่งสร้าง customer report เพิ่มอีกหนึ่งฉบับ โดยอธิบายว่า "เรียบเรียงคู่มือการตอบลูกค้าจัดตามประเภทคำถาม พร้อมคำตอบเชิงนโยบายและที่มาเอกสารของแต่ละข้อ" Parker จะได้ไฟล์ที่จัดโครงสร้างสะอาดสองฉบับ คือคู่มือนโยบายและคู่มือการตอบ ทั้งสองฉบับผ่านการตรวจสอบกับเอกสารจริงโดย NotebookLM แล้วเซฟไว้ที่ Drive
จากนั้นสร้าง gem ชื่อ Support Assistant แล้วใช้งานโดยเปิด Google Docs คลิกไอคอน Gemini เปิด Drive Search เลือก gem แล้ววางข้อความลูกค้าลงในช่องคำสั่ง Parker ทดสอบด้วยข้อความที่ว่า "สั่งแจ็กเก็ตไป 3 สัปดาห์ ใส่ไม่พอดี ตัดป้ายออกแล้ว ยังคืนหรือเปลี่ยนไซส์ได้ไหม" gem จะดึงเอกสารนโยบายจาก Drive หานโยบายคืนสินค้ากรณีตัดป้าย ตรวจสอบว่าช่วงเวลา 3 สัปดาห์อยู่ในระยะคืนสินค้าหรือไม่ ปรับให้ตรงกับเสียงแบรนด์ แล้วร่างคำตอบสองเวอร์ชัน ทั้งอีเมลฉบับเต็มและข้อความสั้นสำหรับแชต
ในเคสที่ยากขึ้น Parker ลองด้วยข้อความ "ถูกเรียกเก็บเงินซ้ำสองครั้งในเดือนนี้ ขอเงินคืนสำหรับรายการซ้ำ และขอยกเลิก subscription ตั้งแต่นี้เป็นต้นไป" gem จะตรวจเงื่อนไข subscription จาก Drive ระบุว่าเป็นข้อผิดพลาดเรื่องการเรียกเก็บเงิน ร่างคำตอบที่ยอมรับปัญหา ยืนยันขั้นตอนคืนเงินตามเอกสารนโยบาย และจัดการคำขอยกเลิกตามเงื่อนไข subscription Parker สรุปว่าคำตอบที่มีโครงสร้างแบบนี้จะออกมาเหมือนกันทุกครั้ง ไม่ว่าใครในทีมจะเป็นผู้ตอบ เมื่อแชร์ gem ตัวนี้ให้ทีม ผู้ช่วยทุกคนจะเข้าถึงคลังความรู้และกฎตอบชุดเดียวกัน ระบบจึงกลายเป็นโครงสร้างสนับสนุนของทั้งบริษัท ไม่ใช่แค่ผู้ช่วยส่วนตัว
เริ่มต้นใช้คู่หูนี้ในงานจริง
สำหรับผู้ที่อยากนำระบบของ Parker Prompts ไปลองเอง สามารถสรุปขั้นเริ่มต้นได้ตามแนวที่คลิปสาธิตไว้
- เปิด NotebookLM และ Gemini ด้วยบัญชี Google เดียวกัน ทั้งสองตัวเปิดให้ใช้งานฟรี
- รวบรวมเอกสารหนึ่งหมวดที่อยากให้ AI อ้างอิงได้แม่น เช่น นโยบายภายในของบริษัท ตารางราคา หรือคลังบทความที่เคยเขียน
- สร้าง notebook ใน NotebookLM อัปโหลดเอกสารชุดนั้น แล้วใช้ Studio สร้างเอกสารอ้างอิงรวม ส่งออกไว้ที่ Google Drive
- สร้าง gem ใน Gemini ตามสูตร PACT โดยใส่ Persona ที่ตรงงาน Assignment ที่ระบุผลลัพธ์ Context ที่เป็นข้อจำกัด และ Template ที่ล็อกโครงสร้าง
- ทดสอบการใช้งานผ่าน Google Docs โดยเปิด Drive Search ให้ gem อ่านเอกสารอ้างอิงได้ และเริ่มจากโจทย์เล็กๆ ก่อนเพิ่มความซับซ้อน
Tip: Parker Prompts เน้นว่า gem ตัวที่ดีคือ gem ที่ไม่ผูกกับหัวข้อใดหัวข้อหนึ่ง ดังนั้นการแยกความรู้เฉพาะเรื่อง (เก็บใน NotebookLM แล้วส่งเข้า Drive) ออกจากกฎการเขียน (เก็บใน gem) คือหลักที่ทำให้นำกลับมาใช้ซ้ำได้นาน
ข้อสังเกตเพิ่มเติมที่ Parker ระบุในคลิปคือ เมื่อเริ่มแชร์ gem ที่ดีให้ทีมแล้ว ระบบหนึ่งตัวจะกลายเป็นโครงสร้างของทั้งองค์กร โดยเฉพาะงานที่มี SOP ชัดเจน เช่น การตอบลูกค้า การเขียนใบเสนอราคา หรือการผลิตคอนเทนต์ตามแบรนด์ เมื่อพนักงานใหม่เข้ามา ก็ onboard ได้ภายในวันเดียวแทนที่จะใช้สัปดาห์ เพราะระบบรู้จักทุกนโยบายแล้ว
สรุป
Parker Prompts สรุปท้ายคลิปว่า เหตุผลที่ Support Assistant ทำงานได้ดีคือ NotebookLM บีบเอกสารห้าฉบับให้เหลือเพียงสองไฟล์ที่ gem อ้างอิงได้แม่นยำ นี่คือหลักของระบบทั้งหมดในคลิปนี้: ใช้ NotebookLM เป็นชั้น grounding ที่ผูกข้อมูลกับแหล่งจริง ใช้ gem เป็นชั้น behavior ที่ล็อกโทนและโครงสร้าง และใช้ Google Drive เป็นทางส่งต่อระหว่างกัน
ผู้ที่สนใจดูคลิปต้นทางฉบับเต็ม สามารถดูได้ที่ Gemini Gems + NotebookLM is INSANE (Try This Today) บนช่อง Parker Prompts ซึ่งมีการสาธิตหน้าจอจริงและคำสั่งที่ Parker ใช้ในแต่ละ gem
ความคิดเห็น
ยังไม่มีความคิดเห็น เป็นคนแรกที่แสดงความเห็น!