ทำไมพรอมต์แรกมักล้มเหลว: บริบทสำคัญกว่าการเรียบเรียงฉลาดๆ

ทำไมพรอมต์แรกมักจะไม่พอ

พรอมต์แรกอาจฟังดูชัดเจนสำหรับผู้เขียน แต่ก็ยังพลาดเป้าหมายได้ ปัญหามักไม่ใช่การเลือกคำ แต่เป็นข้อเท็จจริงที่ขาดหายไปเบื้องหลังคำขอ

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

การเดาเหล่านั้นอาจดูมีประโยชน์ในตอนแรก แต่ความแตกต่างจะปรากฏ ผลลัพธ์ไม่ตรงกับผู้ใช้ ข้อมูล หรือสถานการณ์ที่ซับซ้อนที่ผลิตภัณฑ์ของคุณต้องจัดการ

คำขออย่าง "สร้าง CRM สำหรับทีมเล็ก ๆ" ฟังดูเฉพาะพอสมควร แต่ก็ทิ้งคำถามพื้นฐานไว้:

• บันทึกลูกค้ามีรูปแบบอย่างไร?
• ใครใช้ระบบทุกวัน?
• ควรเกิดอะไรขึ้นเมื่อข้อมูลไม่ครบหรือแปลกประหลาด?
• การกระทำใดควรถูกจำกัดตามบทบาท?

หากไม่มีรายละเอียดเหล่านี้ โมเดลไม่ได้แก้ปัญหาของคุณ มันกำลังแก้เวอร์ชันทั่วไปของปัญหานั้น

คุณจะเห็นเรื่องนี้ในเครื่องมือสร้างแอปแบบแชทด้วยเช่นกัน ถ้ามีคนขอให้ Koder.ai สร้างเครื่องมือภายใน แพลตฟอร์มอาจทำงานได้เร็ว แต่ผลลัพธ์แรกยังขึ้นกับบริบทที่ได้รับ หากพรอมต์ไม่ระบุตัวอย่างเรคอร์ด บทบาททีม หรือกรณีพิเศษ แอปอาจดูเรียบร้อยแต่พลาดส่วนสำคัญ

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

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

สามส่วนของบริบทที่คนมักข้ามไป

พรอมต์ส่วนใหญ่ล้มเหลวเพราะขาดบริบท ไม่ใช่เพราะใช้คำผิดคน

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

ตัวอย่างข้อมูลทำให้งานเป็นรูปธรรม หากคุณขอแดชบอร์ดลูกค้า นั่นอาจหมายถึงสิบสิ่งที่ต่างกัน ตัวอย่างเรคอร์ดสักสองสามรายการจะแสดงว่ามีฟิลด์อะไรบ้าง ฟิลด์ไหนรก และอะไรสำคัญที่สุด

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

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

ลองนึกถึงคนที่สร้าง CRM ง่าย ๆ ใน Koder.ai ผ่านแชท "สร้าง CRM สำหรับทีมของฉัน" กว้างเกินไป แต่ถ้าเพิ่มผู้ติดต่อตัวอย่างสามรายการ อธิบายว่านักขายแก้ไขดีลได้ขณะที่ผู้จัดการสามารถส่งออกรายงาน และบอกว่าจะทำอย่างไรเมื่อนำเข้าลีดที่ไม่มีอีเมล ผลลัพธ์จะมีประโยชน์ขึ้นมากเพราะโมเดลกำลังแก้ปัญหาที่กำหนดไว้แทนที่จะคิดขึ้นมาเอง

รายละเอียดเหล่านี้ไม่ได้ทำให้พรอมต์ยาวขึ้นโดยไร้เหตุผล แต่มันทำให้งานเล็กลง ชัดเจนขึ้น และยากที่จะเข้าใจผิด

ตัวอย่างข้อมูลทำให้คำขอคลุมเครือน้อยลง

พรอมต์จะดีขึ้นมากเมื่อโมเดลเห็นว่าข้อมูลของคุณหน้าตาเป็นอย่างไร คนจำนวนมากบรรยายงานแต่ไม่เคยแสดงวัตถุดิบดิบ

ถ้าคุณต้องการสรุป ตาราง ฟอร์ม หรือกฎทำความสะอาดข้อมูล ให้เพิ่มตัวอย่างเล็ก ๆ จำนวน 3–5 รายการที่คล้ายของจริง พวกมันไม่จำเป็นต้องเป็นของจริงหรือสมบูรณ์ แค่แสดงรูปแบบของอินพุต

ตัวอย่างเช่น ผู้ก่อตั้งที่ใช้ Koder.ai เพื่อสร้าง CRM อาจขอกฎการให้คะแนนลีด "ให้คะแนนลีดใหม่ตามความเร่งด่วนและงบประมาณ" ฟังดูชัด แต่ยังเปิดช่องให้เดาได้ดีขึ้นหากใส่ตัวอย่างลีดพร้อมฟิลด์เช่นขนาดบริษัท ช่วงงบประมาณ ฟีเจอร์ที่ร้องขอ และไทม์ไลน์

ตัวอย่างข้อมูลที่ดีมักทำสี่สิ่ง:

• แสดงกรณีปกติที่โมเดลจะเห็นบ่อยที่สุด
• รวมหนึ่งกรณีแปลก เช่น ฟิลด์หายหรือโน้ตรก
• ใช้ชื่อและตัวเลขปลอมแบบง่าย ๆ
• ตรงกับรูปแบบที่คุณต้องการให้คืนกลับ

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

พรอมต์อ่อน ๆ จะบอกว่า "จัดการคำสั่งเหล่านี้" แต่ที่แข็งขึ้นจะระบุว่า "ใช้ตัวอย่างด้านล่าง แปลงคำสั่งแต่ละรายการเป็น JSON ที่มี customer_name, item_count, rush, และ notes" ตอนนี้งานเป็นรูปธรรมแล้ว

ตัวอย่างข้อมูลยังช่วยให้เห็นปัญหาแอบแฝงตั้งแต่ต้น คุณอาจสังเกตว่าบางรายการใช้วันที่ บางรายการใส่ว่า "ASAP" และมีลูกค้ารายหนึ่งเว้นช่องราคาไว้ เมื่อกรณีเหล่านี้ถูกเห็น โมเดลจะจัดการได้แน่นอนขึ้นแทนที่จะเดาสุ่ม

บทบาทผู้ใช้เปลี่ยนคำตอบที่ถูกต้อง

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

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

เมื่อเขียนพรอมต์ ให้ระบุชื่อแต่ละบทบาทและขอบเขตชัดเจน กล่าวว่าใครสร้างเรคอร์ดได้ ใครแก้ไขได้ ใครอนุมัติ ใครเห็นได้อย่างเดียว และอะไรที่แต่ละบทบาทไม่ควรเข้าถึง

จุดสุดท้ายสำคัญมาก ลูกค้าอาจต้องติดตามคำสั่งของตัวเอง แต่ไม่ควรเห็นข้อมูลลูกค้ารายอื่น ผู้จัดการอาจอนุมัติคำขอแต่ไม่ควรเปลี่ยนการตั้งค่าบิล Admin อาจต้องเห็นทุกอย่างรวมถึงการควบคุมบัญชีและผลงานทีม

การทับซ้อนกันเป็นเรื่องปกติ แต่ต้องชัดเจน บางครั้งผู้จัดการก็เป็นผู้อนุมัติ บางครั้งหัวหน้าซัพพอร์ตแก้ไขเรคอร์ดลูกค้าแต่ส่งออกข้อมูลไม่ได้ หากสองบทบาทแชร์สิทธิ์ ให้บอกไว้ หากแตกต่างในจุดสำคัญ ให้เน้น

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

ข้อยกเว้นหยุดพฤติกรรมขอบที่อึดอัดได้

พรอมต์อาจฟังดูชัดเจนแต่พังเมื่อข้อมูลจริงรก นั่นเกิดขึ้นเมื่อคำสั่งครอบคลุมเส้นทางปกติแต่ไม่พูดถึงกรณีแปลก ๆ ที่เกิดขึ้นจริง

ถ้าคุณต้องการผลลัพธ์ที่ดีกว่า อย่าบรรยายแค่ข้อมูลอินพุตในอุดมคติ จงบอกว่าจะทำอย่างไรเมื่อบางอย่างหาย ซ้ำ ไม่ถูกต้อง หรือว่าง กฎเล็ก ๆ เหล่านี้มักสำคัญกว่าการใช้คำหรู

ลองคิดเกี่ยวกับฟอร์มลูกค้าสำหรับ CRM กรณีทดสอบที่สะอาดมีชื่อเต็ม อีเมล บริษัท และเบอร์โทร แต่การส่งจริงมักไม่เรียบร้อย คนหนึ่งเว้นเบอร์ คนหนึ่งใส่อีเมลซ้ำ และอีกคนพิมพ์ข้อมูลมั่วในฟิลด์วันที่

กฎง่าย ๆ บางข้อป้องกันพฤติกรรมอึดอัดได้มาก:

• ถ้าฟิลด์ที่จำเป็นหาย ให้ทำเครื่องหมายเรคอร์ดว่าไม่สมบูรณ์และขอค่านั้นกลับมา
• ถ้าฟิลด์ไม่จำเป็นว่าง ให้ดำเนินการต่อโดยไม่ขัดขวาง
• ถ้าพบรายการซ้ำ ให้ปรับปรุงหรือทำเครื่องหมายเรคอร์ดเดิมแทนการสร้างใหม่
• ถ้าข้อมูลไม่ตรงรูปแบบ ให้คืนข้อความผิดพลาดสั้น ๆ ที่ระบุฟิลด์นั้น
• ถ้าไม่พบผลลัพธ์ ให้แสดงสถานะว่างแทนการเดา

ข้อสุดท้ายมักถูกมองข้าม พรอมต์หลายฉบับบอกระบบให้ "ช่วย" ผู้ใช้ ดังนั้นมันจึงเติมช่องว่างด้วยสมมติฐานแย่ ๆ พรอมต์ที่ดีกว่าจะบอกว่าเมื่อไรต้องหยุด เมื่อไรต้องถามคำถามเพิ่มเติม และเมื่อไรต้องปฏิเสธการกระทำ

นอกจากนี้ช่วยได้ถ้ากำหนดว่าจะทำอย่างไรเมื่อคำขอขัดกับกฎธุรกิจ เช่น ถ้าคำขอคืนเงินเกิน 30 วัน อย่าดำเนินการอัตโนมัติ ให้ส่งตรวจสอบด้วยมือ ถ้าผู้ใช้พยายามมอบหมายงานให้ใครนอกทีม ให้ปฏิเสธและแจ้งเหตุผล

คุณไม่จำเป็นต้องคาดการณ์ทุกอย่าง แค่ครอบคลุมข้อยกเว้นที่อาจก่อให้เกิดความเสียหาย ความสับสน หรือเสียเวลาจริง ๆ นั่นมักเป็นความแตกต่างระหว่างเดโมที่ดูฉลาดกับเวิร์กโฟลว์ที่คนเชื่อถือได้

วิธีเขียนพรอมต์ให้แข็งแรงขึ้นทีละขั้น

เริ่มจากเรียบง่าย พรอมต์ที่ดีที่สุดมักเริ่มด้วยประโยคชัดเจนหนึ่งประโยคเกี่ยวกับผลลัพธ์ที่ต้องการ ไม่ใช่การปูพื้นยาวหรือเทคนิคฉลาด ๆ แค่บอกงาน: เขียนฟลอว์สมัครสมาชิก สรุปตั๋วซัพพอร์ต หรือวางแผน CRM สำหรับทีมขาย

แล้วเพิ่มบริบทการทำงานที่ขาดหายไปตามลำดับที่มีประโยชน์:

1. ระบุผลลัพธ์ด้วยภาษาธรรมดา บอกว่าสิ่งที่คุณต้องการให้ AI ผลิตคืออะไรและสำหรับใคร
2. เพิ่มตัวอย่างอินพุตเล็ก ๆ ก่อนเพิ่มกฎจำนวนมาก
3. ระบุบุคคลที่เกี่ยวข้องและสิ่งที่แต่ละคนเห็นหรือแก้ไขได้
4. เน้นข้อยกเว้นตั้งแต่ต้น รวมถึงข้อมูลหาย การกระทำที่ถูกบล็อก และกรณีไม่แน่นอน
5. ขอร่างแรก แล้วปรับปรุงทีละส่วน

ตัวอย่างสั้น ๆ แสดงว่าทำไมวิธีนี้ได้ผล แทนที่จะพูดว่า "สร้างแอปงาน" ให้บอกว่า "สร้างแอปงานสำหรับทีมการตลาดห้าคน ผู้จัดการมอบหมายงานได้ สมาชิกทีมปรับปรุงได้เฉพาะงานของตนเท่านั้น ถ้าวันครบหาย ให้ทำเครื่องหมายว่ายังไม่มีกำหนด แทนการเดา ใช้ตัวอย่างนี้..."

เวอร์ชันนี้ให้โมเดลสิ่งที่จับต้องได้ ตัวอย่างข้อมูลแสดงรูปแบบ บทบาทกำหนดขอบเขต และข้อยกเว้นป้องกันพฤติกรรมอึดอัด

ถ้าคุณใช้ผู้สร้างแบบแชทอย่าง Koder.ai ลำดับนี้ยังช่วยให้แพลตฟอร์มวางแผนแอปได้แม่นยำก่อนจะสร้างหน้าจอ ตรรกะ หรือโครงสร้างฐานข้อมูล โดยสรุป พรอมต์ที่ดีกว่ามักเกี่ยวกับการให้ข้อเท็จจริง ไม่ใช่การเลือกคำหลายแบบ

ตัวอย่างที่สมจริง

ผู้ก่อตั้งที่ใช้ผู้สร้างแบบแชทอาจเริ่มด้วยคำขอสั้น ๆ ว่า: "สร้างแอปรับข้อมูลลูกค้าแบบง่าย"

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

ผลลัพธ์แรกนั้นไม่ใช่เรื่องไร้ค่า แต่เป็นเงาตามขอบเขตของพรอมต์ ระบบไม่มีตัวอย่างลูกค้า ไม่มีบทบาทพนักงาน และไม่มีกฎสำหรับกรณีจริงที่ซับซ้อน

พรอมต์ที่แข็งแรงกว่าจะเพิ่มบริบท เช่น:

• เอกสารตัวอย่างสำหรับลูกค้าสามหรือสี่รายทั่วไป
• บทบาทของคนที่ใช้แอปทุกวัน
• กฎสำหรับรายการซ้ำ ฟิลด์หาย และการบันทึกแบบร่าง

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

จากนั้นข้อยกเว้นจะทำให้ต่างกันจริง ๆ ถ้าอีเมลหรือเบอร์ซ้ำ แอปควรเตือนพนักงานก่อนสร้างเรคอร์ดใหม่ ถ้าแบบฟอร์มหายรายละเอียดสำคัญ ให้บันทึกเป็นร่างแทนที่จะขึ้นเป็นรายการที่เสร็จแล้ว

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

การเลือกคำไม่ได้ฉลาดขึ้นมาก แต่บริบทสมบูรณ์ขึ้น

ความผิดพลาดทั่วไปที่เสียเวลา

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

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

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

ข้อผิดพลาดอีกอย่างคือลืมว่าใครจะใช้ผลลัพธ์จริง ๆ คำตอบสำหรับผู้ก่อตั้ง เจ้าหน้าที่ซัพพอร์ต และลูกค้ามือใหม่ไม่ควรเหมือนกัน หากคุณข้ามบทบาท ผลลัพธ์อาจถูกต้องเชิงเทคนิคแต่ผิดสำหรับกลุ่มเป้าหมาย

เรื่องนี้ปรากฏในการสร้างแอปด้วยเช่นกัน ถ้าพรอมต์บอกว่า "ทำแดชบอร์ดให้ทีม" แต่ไม่บอกว่าใครในทีม ผลลัพธ์จะเบี้ยว ผู้จัดการฝ่ายขาย หัวหน้าคลัง และนักบัญชีต้องการหน้าจอ คำพูด และการกระทำที่แตกต่างกัน

กรณีขอบเป็นอีกแหล่งซ่อนเวลา ทีมมักละเลยจนกระทั่งร่างแรกเสร็จ แล้วค่อยมาแพตช์ทีละจุด นำไปสู่พฤติกรรมอึดอัด เช่น ฟอร์มที่ใช้ได้กับผู้ใช้ใหม่แต่ล้มเหลวกับผู้ใช้เก่า admin หรือคนที่มีข้อมูลไม่ครบ

ข้อผิดพลาดซ้ำ ๆ มีดังนี้:

• เปลี่ยนคำพูดเมื่อปัญหาจริงคือบริบทขาด
• เพิ่มข้อจำกัดแต่ไม่มีตัวอย่างข้อมูล
• แก้โทน รูปแบบ และกลุ่มเป้าหมายพร้อมกันทั้งหมด
• ทดสอบแค่เส้นทางที่เป็นสุข (happy path)
• แก้ผลลัพธ์ก่อนกำหนดข้อยกเว้น

ข้อสุดท้ายคือการเปลี่ยนมากเกินไประหว่างการแก้ไข หากคุณเขียนเป้าหมาย กลุ่มเป้าหมาย ตัวอย่าง และข้อจำกัดใหม่ทั้งหมดในการแก้ครั้งเดียว คุณจะไม่รู้ว่าปัจจัยไหนช่วยให้ดีขึ้น ให้เปลี่ยนทีละตัวแปรใหญ่ ๆ แล้วพรอมต์จะพัฒนารวดเร็วกว่า

การตรวจสอบด่วนก่อนส่งพรอมต์

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

ประเด็นนี้สำคัญยิ่งเมื่อคุณขอเครื่องมืออย่าง Koder.ai ให้สร้างส่วนของแอป หน้า หรือเวิร์กโฟลว์จากแชท เพราะช่องว่างเล็ก ๆ ในพรอมต์อาจกลายเป็นช่องว่างใหญ่ในผลลัพธ์

เช็คลิสต์ก่อนส่งแบบง่าย

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

ข้อสุดท้ายนี่มักพลาด ผลลัพธ์แย่หลายครั้งเกิดจากโมเดลพยายามช่วยและเติมรายละเอียดที่หายไปเอง หากคุณต้องการให้หยุดแล้วถาม ให้บอกตรง ๆ

การทดสอบง่าย ๆ ช่วยได้: หลังอ่านพรอมต์ครั้งเดียว คุณตอบคำถามเหล่านี้ได้โดยไม่ต้องเดาหรือไม่?

• นี่สำหรับใคร?
• พวกเขาจะให้ข้อมูลอะไรเข้ามา?
• ควรได้ผลลัพธ์แบบไหนกลับมา?
• อะไรที่ห้ามเกิดขึ้น?
• โมเดลควรทำอย่างไรเมื่อข้อมูลหาย?

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

ขั้นตอนปฏิบัติที่ทำได้จริง

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

จากนั้นสร้างคลังบริบทเล็ก ๆ เก็บตัวอย่างข้อมูลจริง กรณีขอบที่พบบ่อย และข้อผิดพลาดที่เคยเห็น สำหรับการตอบซัพพอร์ต อาจหมายถึงตั๋วปกติหนึ่งใบ ข้อความลูกค้าโกรธหนึ่งฉบับ และคำขอที่ควรยกระดับแทนตอบ

รูทีนที่มีประโยชน์ไม่ซับซ้อน:

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

ข้อสุดท้ายสำคัญที่สุด เมื่อผลลัพธ์อ่อน หลายคนจะเขียนคำสั่งเดิมซ้ำสามครั้ง การแก้บริบทที่ขาดหายมักเร็วกว่าและได้ผลมากกว่าแต่งคำอีก

ถ้าคำตอบดูทั่วไป ให้เพิ่มตัวอย่างข้อมูล ถ้าใช้โทนหรือระดับรายละเอียดผิด ให้กำหนดบทบาทผู้ใช้ให้ชัดเจนขึ้น ถ้ามันล้มเหลวกับกรณีอึดอัด ให้ระบุข้อยกเว้นเป็นภาษาง่าย ๆ

จดสั้น ๆ เอกสารเล็ก ๆ ต่อแต่ละงานที่ทำซ้ำก็พอ เมื่อเวลาผ่านไป คุณจะมีชุดพรอมต์ที่เชื่อถือได้และใช้เร็วขึ้น

แนวคิดเดียวกันใช้ได้เมื่อคุณสร้างซอฟต์แวร์ผ่านแชท ไม่ใช่แค่เขียนข้อความ Koder.ai ให้คนสร้างเว็บ เซิร์ฟเวอร์ และแอปมือถือผ่านแชท ดังนั้นคุณภาพของการสร้างครั้งแรกยังขึ้นกับบริบทที่ให้มาอย่างมาก ถ้าผู้ก่อตั้งขอ CRM และรวมตัวอย่างลูกค้าจริง กฎบทบาทสำหรับนักขายและผู้จัดการ และข้อยกเว้นเช่นลูกค้าซ้ำหรือขั้นตอนการอนุมัติ ผลลัพธ์มักใกล้เคียงกับสิ่งที่ธุรกิจต้องการมากขึ้น

คุณไม่ต้องมีไลบรารีพรอมต์ที่สมบูรณ์ในวันแรก เก็บพรอมต์ที่ได้ผล รวบรวมตัวอย่างแข็ง ๆ สั้น ๆ และมองผลลัพธ์แรกเป็นการทดสอบเร็ว ๆ เมื่อคุณแก้บริบทที่ขาดหายแทนไล่ตามคำพูดฉลาด ๆ ผลลัพธ์ถัดไปมักดีขึ้นเร็วขึ้น