ทำไมพรอมต์แรกมักจะไม่พอ\n\nพรอมต์แรกอาจฟังดูชัดเจนสำหรับผู้เขียน แต่ก็ยังพลาดเป้าหมายได้ ปัญหามักไม่ใช่การเลือกคำ แต่เป็นข้อเท็จจริงที่ขาดหายไปเบื้องหลังคำขอ\n\nคนมักพยายามแก้พรอมต์ที่อ่อนด้วยการเขียนให้ฉลาดขึ้น ยาวขึ้น หรือดูดีขึ้น แต่การปรับวลีไม่สามารถแทนข้อมูลที่ไม่เคยมีได้ เมื่อโมเดลไม่มีบริบทเพียงพอ มันยังต้องตอบ ดังนั้นมันจะเติมช่องว่างด้วยการเดาที่เป็นไปได้\n\nการเดาเหล่านั้นอาจดูมีประโยชน์ในตอนแรก แต่ความแตกต่างจะปรากฏ ผลลัพธ์ไม่ตรงกับผู้ใช้ ข้อมูล หรือสถานการณ์ที่ซับซ้อนที่ผลิตภัณฑ์ของคุณต้องจัดการ\n\nคำขออย่าง "สร้าง CRM สำหรับทีมเล็ก ๆ" ฟังดูเฉพาะพอสมควร แต่ก็ทิ้งคำถามพื้นฐานไว้:\n\n- บันทึกลูกค้ามีรูปแบบอย่างไร?\n- ใครใช้ระบบทุกวัน?\n- ควรเกิดอะไรขึ้นเมื่อข้อมูลไม่ครบหรือแปลกประหลาด?\n- การกระทำใดควรถูกจำกัดตามบทบาท?\n\nหากไม่มีรายละเอียดเหล่านี้ โมเดลไม่ได้แก้ปัญหาของคุณ มันกำลังแก้เวอร์ชันทั่วไปของปัญหานั้น\n\nคุณจะเห็นเรื่องนี้ในเครื่องมือสร้างแอปแบบแชทด้วยเช่นกัน ถ้ามีคนขอให้ Koder.ai สร้างเครื่องมือภายใน แพลตฟอร์มอาจทำงานได้เร็ว แต่ผลลัพธ์แรกยังขึ้นกับบริบทที่ได้รับ หากพรอมต์ไม่ระบุตัวอย่างเรคอร์ด บทบาททีม หรือกรณีพิเศษ แอปอาจดูเรียบร้อยแต่พลาดส่วนสำคัญ\n\nผลลัพธ์แรกที่อ่อนไม่ได้หมายความว่า AI ทำงานไม่ดีในงานนั้น ส่วนใหญ่เป็นเพราะงานถูกอธิบายน้อยเกินไป โมเดลได้แค่หัวข้อใหญ่ ไม่ใช่รายละเอียดที่ใช้งานได้\n\nการเปลี่ยนแปลงที่แท้จริงเกิดขึ้นเมื่อคุณหยุดถามว่า "จะเขียนยังไงให้ดีขึ้น?" และเริ่มถามว่า "ฉันสมมติอะไรไว้แล้วที่โมเดลน่าจะรู้?" คำถามหลังมักช่วยให้ผลลัพธ์ดีขึ้นเร็วกว่าการเขียนประโยคเดิมซ้ำไปมา\n\n## สามส่วนของบริบทที่คนมักข้ามไป\n\nพรอมต์ส่วนใหญ่ล้มเหลวเพราะขาดบริบท ไม่ใช่เพราะใช้คำผิดคน\n\nคนมักเขียนประโยคใหม่ เปลี่ยนคำให้เป็นทางการขึ้น และเพิ่มคำสั่งมากขึ้น แต่ปัญหาใหญ่คือโมเดลยังมีทางเลือกมากเกินไป สามประเภทของบริบทจะช่วยลดตัวเลือกเหล่านั้นได้เร็ว: ตัวอย่างข้อมูลจริง บทบาทผู้ใช้ และข้อยกเว้น\n\nตัวอย่างข้อมูลทำให้งานเป็นรูปธรรม หากคุณขอแดชบอร์ดลูกค้า นั่นอาจหมายถึงสิบสิ่งที่ต่างกัน ตัวอย่างเรคอร์ดสักสองสามรายการจะแสดงว่ามีฟิลด์อะไรบ้าง ฟิลด์ไหนรก และอะไรสำคัญที่สุด\n\nบทบาทผู้ใช้ก็สำคัญไม่แพ้กัน ผู้ก่อตั้ง นักขาย ผู้จัดการ และเจ้าหน้าที่ซัพพอร์ต ไม่ต้องการหน้าจอ โทน หรือสิทธิ์แบบเดียวกัน หากคุณละบทบาท โมเดลจะผสมทุกคนเข้าด้วยกันและให้คำตอบกลาง ๆ ที่ไม่เหมาะกับใครเลย\n\nข้อยกเว้นเป็นส่วนที่คนมักสังเกตช้า สิ่งจะเกิดขึ้นอย่างไรถ้าการชำระเงินล้มเหลว ฟิลด์หายไป ผู้ใช้มีสิทธิ์อ่านอย่างเดียว หรือมีเรคอร์ดขัดแย้งกัน? หากไม่มีข้อกำหนดเหล่านี้ โมเดลจะเติมช่องว่างด้วยการเดา\n\nลองนึกถึงคนที่สร้าง CRM ง่าย ๆ ใน Koder.ai ผ่านแชท "สร้าง CRM สำหรับทีมของฉัน" กว้างเกินไป แต่ถ้าเพิ่มผู้ติดต่อตัวอย่างสามรายการ อธิบายว่านักขายแก้ไขดีลได้ขณะที่ผู้จัดการสามารถส่งออกรายงาน และบอกว่าจะทำอย่างไรเมื่อนำเข้าลีดที่ไม่มีอีเมล ผลลัพธ์จะมีประโยชน์ขึ้นมากเพราะโมเดลกำลังแก้ปัญหาที่กำหนดไว้แทนที่จะคิดขึ้นมาเอง\n\nรายละเอียดเหล่านี้ไม่ได้ทำให้พรอมต์ยาวขึ้นโดยไร้เหตุผล แต่มันทำให้งานเล็กลง ชัดเจนขึ้น และยากที่จะเข้าใจผิด\n\n## ตัวอย่างข้อมูลทำให้คำขอคลุมเครือน้อยลง\n\nพรอมต์จะดีขึ้นมากเมื่อโมเดลเห็นว่าข้อมูลของคุณหน้าตาเป็นอย่างไร คนจำนวนมากบรรยายงานแต่ไม่เคยแสดงวัตถุดิบดิบ\n\nถ้าคุณต้องการสรุป ตาราง ฟอร์ม หรือกฎทำความสะอาดข้อมูล ให้เพิ่มตัวอย่างเล็ก ๆ จำนวน 3–5 รายการที่คล้ายของจริง พวกมันไม่จำเป็นต้องเป็นของจริงหรือสมบูรณ์ แค่แสดงรูปแบบของอินพุต\n\nตัวอย่างเช่น ผู้ก่อตั้งที่ใช้ Koder.ai เพื่อสร้าง CRM อาจขอกฎการให้คะแนนลีด "ให้คะแนนลีดใหม่ตามความเร่งด่วนและงบประมาณ" ฟังดูชัด แต่ยังเปิดช่องให้เดาได้ดีขึ้นหากใส่ตัวอย่างลีดพร้อมฟิลด์เช่นขนาดบริษัท ช่วงงบประมาณ ฟีเจอร์ที่ร้องขอ และไทม์ไลน์\n\nตัวอย่างข้อมูลที่ดีมักทำสี่สิ่ง:\n\n- แสดงกรณีปกติที่โมเดลจะเห็นบ่อยที่สุด\n- รวมหนึ่งกรณีแปลก เช่น ฟิลด์หายหรือโน้ตรก\n- ใช้ชื่อและตัวเลขปลอมแบบง่าย ๆ\n- ตรงกับรูปแบบที่คุณต้องการให้คืนกลับ\n\nข้อสุดท้ายสำคัญกว่าที่คิด หากอินพุตของคุณเป็นรายการตั๋วซัพพอร์ตและผลลัพธ์ที่ต้องการคือโต๊ะที่มีคอลัมน์ความสำคัญ เจ้าของ และขั้นตอนถัดไป ให้โชว์ตัวอย่างหนึ่งรายการในโครงสร้างนั้น โมเดลมักจะตามรูปแบบไป\n\nพรอมต์อ่อน ๆ จะบอกว่า "จัดการคำสั่งเหล่านี้" แต่ที่แข็งขึ้นจะระบุว่า "ใช้ตัวอย่างด้านล่าง แปลงคำสั่งแต่ละรายการเป็น JSON ที่มี customer_name, item_count, rush, และ notes" ตอนนี้งานเป็นรูปธรรมแล้ว\n\nตัวอย่างข้อมูลยังช่วยให้เห็นปัญหาแอบแฝงตั้งแต่ต้น คุณอาจสังเกตว่าบางรายการใช้วันที่ บางรายการใส่ว่า "ASAP" และมีลูกค้ารายหนึ่งเว้นช่องราคาไว้ เมื่อกรณีเหล่านี้ถูกเห็น โมเดลจะจัดการได้แน่นอนขึ้นแทนที่จะเดาสุ่ม\n\n## บทบาทผู้ใช้เปลี่ยนคำตอบที่ถูกต้อง\n\nโมเดลไม่สามารถให้คำตอบที่ถูกต้องได้หากไม่รู้ว่าคำตอบนั้นสำหรับใคร ผู้ก่อตั้ง ผู้จัดการ และลูกค้า สามารถขอแดชบอร์ดเดียวกันแต่ต้องการสิ่งต่างกันมาก\n\nถ้าคุณแค่บอกว่า "สร้างแดชบอร์ดโครงการ" AI ต้องเดาว่าแต่ละคนควรเห็นและทำอะไร การเดานั้นมักนำไปสู่หน้าจอที่ยุ่ง ขาดการควบคุม หรือสิทธิ์ที่รู้สึกผิด\n\nเมื่อเขียนพรอมต์ ให้ระบุชื่อแต่ละบทบาทและขอบเขตชัดเจน กล่าวว่าใครสร้างเรคอร์ดได้ ใครแก้ไขได้ ใครอนุมัติ ใครเห็นได้อย่างเดียว และอะไรที่แต่ละบทบาทไม่ควรเข้าถึง\n\nจุดสุดท้ายสำคัญมาก ลูกค้าอาจต้องติดตามคำสั่งของตัวเอง แต่ไม่ควรเห็นข้อมูลลูกค้ารายอื่น ผู้จัดการอาจอนุมัติคำขอแต่ไม่ควรเปลี่ยนการตั้งค่าบิล Admin อาจต้องเห็นทุกอย่างรวมถึงการควบคุมบัญชีและผลงานทีม\n\nการทับซ้อนกันเป็นเรื่องปกติ แต่ต้องชัดเจน บางครั้งผู้จัดการก็เป็นผู้อนุมัติ บางครั้งหัวหน้าซัพพอร์ตแก้ไขเรคอร์ดลูกค้าแต่ส่งออกข้อมูลไม่ได้ หากสองบทบาทแชร์สิทธิ์ ให้บอกไว้ หากแตกต่างในจุดสำคัญ ให้เน้น\n\nพรอมต์ที่ดีไม่ได้แค่บรรยายฟีเจอร์ แต่บรรยายความรับผิดชอบ เมื่อโมเดลรู้ว่าแต่ละคนเป็นใคร คำตอบที่ถูกต้องก็ง่ายขึ้นมาก\n\n## ข้อยกเว้นหยุดพฤติกรรมขอบที่อึดอัดได้\n\nพรอมต์อาจฟังดูชัดเจนแต่พังเมื่อข้อมูลจริงรก นั่นเกิดขึ้นเมื่อคำสั่งครอบคลุมเส้นทางปกติแต่ไม่พูดถึงกรณีแปลก ๆ ที่เกิดขึ้นจริง\n\nถ้าคุณต้องการผลลัพธ์ที่ดีกว่า อย่าบรรยายแค่ข้อมูลอินพุตในอุดมคติ จงบอกว่าจะทำอย่างไรเมื่อบางอย่างหาย ซ้ำ ไม่ถูกต้อง หรือว่าง กฎเล็ก ๆ เหล่านี้มักสำคัญกว่าการใช้คำหรู\n\nลองคิดเกี่ยวกับฟอร์มลูกค้าสำหรับ CRM กรณีทดสอบที่สะอาดมีชื่อเต็ม อีเมล บริษัท และเบอร์โทร แต่การส่งจริงมักไม่เรียบร้อย คนหนึ่งเว้นเบอร์ คนหนึ่งใส่อีเมลซ้ำ และอีกคนพิมพ์ข้อมูลมั่วในฟิลด์วันที่\n\nกฎง่าย ๆ บางข้อป้องกันพฤติกรรมอึดอัดได้มาก:\n\n- ถ้าฟิลด์ที่จำเป็นหาย ให้ทำเครื่องหมายเรคอร์ดว่าไม่สมบูรณ์และขอค่านั้นกลับมา\n- ถ้าฟิลด์ไม่จำเป็นว่าง ให้ดำเนินการต่อโดยไม่ขัดขวาง\n- ถ้าพบรายการซ้ำ ให้ปรับปรุงหรือทำเครื่องหมายเรคอร์ดเดิมแทนการสร้างใหม่\n- ถ้าข้อมูลไม่ตรงรูปแบบ ให้คืนข้อความผิดพลาดสั้น ๆ ที่ระบุฟิลด์นั้น\n- ถ้าไม่พบผลลัพธ์ ให้แสดงสถานะว่างแทนการเดา\n\nข้อสุดท้ายมักถูกมองข้าม พรอมต์หลายฉบับบอกระบบให้ "ช่วย" ผู้ใช้ ดังนั้นมันจึงเติมช่องว่างด้วยสมมติฐานแย่ ๆ พรอมต์ที่ดีกว่าจะบอกว่าเมื่อไรต้องหยุด เมื่อไรต้องถามคำถามเพิ่มเติม และเมื่อไรต้องปฏิเสธการกระทำ\n\nนอกจากนี้ช่วยได้ถ้ากำหนดว่าจะทำอย่างไรเมื่อคำขอขัดกับกฎธุรกิจ เช่น ถ้าคำขอคืนเงินเกิน 30 วัน อย่าดำเนินการอัตโนมัติ ให้ส่งตรวจสอบด้วยมือ ถ้าผู้ใช้พยายามมอบหมายงานให้ใครนอกทีม ให้ปฏิเสธและแจ้งเหตุผล\n\nคุณไม่จำเป็นต้องคาดการณ์ทุกอย่าง แค่ครอบคลุมข้อยกเว้นที่อาจก่อให้เกิดความเสียหาย ความสับสน หรือเสียเวลาจริง ๆ นั่นมักเป็นความแตกต่างระหว่างเดโมที่ดูฉลาดกับเวิร์กโฟลว์ที่คนเชื่อถือได้\n\n## วิธีเขียนพรอมต์ให้แข็งแรงขึ้นทีละขั้น\n\nเริ่มจากเรียบง่าย พรอมต์ที่ดีที่สุดมักเริ่มด้วยประโยคชัดเจนหนึ่งประโยคเกี่ยวกับผลลัพธ์ที่ต้องการ ไม่ใช่การปูพื้นยาวหรือเทคนิคฉลาด ๆ แค่บอกงาน: เขียนฟลอว์สมัครสมาชิก สรุปตั๋วซัพพอร์ต หรือวางแผน CRM สำหรับทีมขาย\n\nแล้วเพิ่มบริบทการทำงานที่ขาดหายไปตามลำดับที่มีประโยชน์:\n\n1. ระบุผลลัพธ์ด้วยภาษาธรรมดา บอกว่าสิ่งที่คุณต้องการให้ AI ผลิตคืออะไรและสำหรับใคร\n2. เพิ่มตัวอย่างอินพุตเล็ก ๆ ก่อนเพิ่มกฎจำนวนมาก\n3. ระบุบุคคลที่เกี่ยวข้องและสิ่งที่แต่ละคนเห็นหรือแก้ไขได้\n4. เน้นข้อยกเว้นตั้งแต่ต้น รวมถึงข้อมูลหาย การกระทำที่ถูกบล็อก และกรณีไม่แน่นอน\n5. ขอร่างแรก แล้วปรับปรุงทีละส่วน\n\nตัวอย่างสั้น ๆ แสดงว่าทำไมวิธีนี้ได้ผล แทนที่จะพูดว่า "สร้างแอปงาน" ให้บอกว่า "สร้างแอปงานสำหรับทีมการตลาดห้าคน ผู้จัดการมอบหมายงานได้ สมาชิกทีมปรับปรุงได้เฉพาะงานของตนเท่านั้น ถ้าวันครบหาย ให้ทำเครื่องหมายว่ายังไม่มีกำหนด แทนการเดา ใช้ตัวอย่างนี้..."\n\nเวอร์ชันนี้ให้โมเดลสิ่งที่จับต้องได้ ตัวอย่างข้อมูลแสดงรูปแบบ บทบาทกำหนดขอบเขต และข้อยกเว้นป้องกันพฤติกรรมอึดอัด\n\nถ้าคุณใช้ผู้สร้างแบบแชทอย่าง Koder.ai ลำดับนี้ยังช่วยให้แพลตฟอร์มวางแผนแอปได้แม่นยำก่อนจะสร้างหน้าจอ ตรรกะ หรือโครงสร้างฐานข้อมูล โดยสรุป พรอมต์ที่ดีกว่ามักเกี่ยวกับการให้ข้อเท็จจริง ไม่ใช่การเลือกคำหลายแบบ\n\n## ตัวอย่างที่สมจริง\n\nผู้ก่อตั้งที่ใช้ผู้สร้างแบบแชทอาจเริ่มด้วยคำขอสั้น ๆ ว่า: "สร้างแอปรับข้อมูลลูกค้าแบบง่าย"\n\nนั่นฟังดูชัด แต่ผลลัพธ์มักจะเป็นแบบทั่วไป แอปอาจมีฟิลด์พื้นฐาน เช่น ชื่อ อีเมล เบอร์โทร และโน้ต และอาจสร้างเวิร์กโฟลว์มาตรฐานเดียวสำหรับทุกคนโดยไม่มีความแตกต่างระหว่างพนักงานหน้าฟรอนต์ ผู้จัดการ และพนักงานบริการ\n\nผลลัพธ์แรกนั้นไม่ใช่เรื่องไร้ค่า แต่เป็นเงาตามขอบเขตของพรอมต์ ระบบไม่มีตัวอย่างลูกค้า ไม่มีบทบาทพนักงาน และไม่มีกฎสำหรับกรณีจริงที่ซับซ้อน\n\nพรอมต์ที่แข็งแรงกว่าจะเพิ่มบริบท เช่น:\n\n- เอกสารตัวอย่างสำหรับลูกค้าสามหรือสี่รายทั่วไป\n- บทบาทของคนที่ใช้แอปทุกวัน\n- กฎสำหรับรายการซ้ำ ฟิลด์หาย และการบันทึกแบบร่าง\n\nตัวอย่างเช่น พรอมต์อาจระบุว่าพนักงานหน้าฟรอนต์สร้างและแก้ไขแบบฟอร์มรับลูกค้าได้ ผู้จัดการอนุมัติหรือรวมเรคอร์ดได้ และพนักงานบริการเห็นเฉพาะลูกค้าที่มอบหมายมา อาจรวมลูกค้าใหม่หนึ่งรายที่มีรายละเอียดครบ ลูกค้ากลับมาอีกคนที่เปลี่ยนเบอร์ และการแนะนำที่มีข้อมูลไม่ครบ\n\nจากนั้นข้อยกเว้นจะทำให้ต่างกันจริง ๆ ถ้าอีเมลหรือเบอร์ซ้ำ แอปควรเตือนพนักงานก่อนสร้างเรคอร์ดใหม่ ถ้าแบบฟอร์มหายรายละเอียดสำคัญ ให้บันทึกเป็นร่างแทนที่จะขึ้นเป็นรายการที่เสร็จแล้ว\n\nเมื่อรวมรายละเอียดเหล่านั้น ผลลัพธ์ถัดไปมักใกล้เคียงกับสิ่งที่ธุรกิจต้องการ ฟิลด์จะไม่ดูสุ่ม หน้าจอเข้ากับงานจริง และเวิร์กโฟลว์จัดการความผิดพลาดทั่วไปโดยไม่ต้องให้พนักงานหาทางแก้เอง\n\nการเลือกคำไม่ได้ฉลาดขึ้นมาก แต่บริบทสมบูรณ์ขึ้น\n\n## ความผิดพลาดทั่วไปที่เสียเวลา\n\nคนเสียเวลาเยอะด้วยการพยายามทำให้คำพูดดูฉลาดกว่าแทนที่จะทำให้ชัดเจน ผู้คนเขียนคำสั่งที่ปรุงแต่งเหมือนบรีฟในห้องประชุม แต่โมเดลยังต้องเดาว่าหมายความว่าอย่างไร\n\nพรอมต์เรียบง่ายที่มีรายละเอียดจริงมักชนะพรอมต์หรูที่คลุมเครือ "เขียนอัปเดตลูกค้าสำหรับผู้จัดการร้านที่ยุ่ง" ดีกว่า "สร้างสื่อสื่อสารที่น่าสนใจในโทนมืออาชีพ"\n\nความผิดพลาดทั่วไปคือเพิ่มกฎมากมายโดยไม่ยอมให้ตัวอย่างเดียว หากคุณต้องการรูปแบบ โทน หรือระดับรายละเอียด ให้โชว์ตัวอย่างสั้น ๆ ตัวอย่างหนึ่งมักลดการเดาได้เร็วกว่าการเพิ่มคำสั่งอีกห้าบรรทัด\n\nข้อผิดพลาดอีกอย่างคือลืมว่าใครจะใช้ผลลัพธ์จริง ๆ คำตอบสำหรับผู้ก่อตั้ง เจ้าหน้าที่ซัพพอร์ต และลูกค้ามือใหม่ไม่ควรเหมือนกัน หากคุณข้ามบทบาท ผลลัพธ์อาจถูกต้องเชิงเทคนิคแต่ผิดสำหรับกลุ่มเป้าหมาย\n\nเรื่องนี้ปรากฏในการสร้างแอปด้วยเช่นกัน ถ้าพรอมต์บอกว่า "ทำแดชบอร์ดให้ทีม" แต่ไม่บอกว่าใครในทีม ผลลัพธ์จะเบี้ยว ผู้จัดการฝ่ายขาย หัวหน้าคลัง และนักบัญชีต้องการหน้าจอ คำพูด และการกระทำที่แตกต่างกัน\n\nกรณีขอบเป็นอีกแหล่งซ่อนเวลา ทีมมักละเลยจนกระทั่งร่างแรกเสร็จ แล้วค่อยมาแพตช์ทีละจุด นำไปสู่พฤติกรรมอึดอัด เช่น ฟอร์มที่ใช้ได้กับผู้ใช้ใหม่แต่ล้มเหลวกับผู้ใช้เก่า admin หรือคนที่มีข้อมูลไม่ครบ\n\nข้อผิดพลาดซ้ำ ๆ มีดังนี้:\n\n- เปลี่ยนคำพูดเมื่อปัญหาจริงคือบริบทขาด\n- เพิ่มข้อจำกัดแต่ไม่มีตัวอย่างข้อมูล\n- แก้โทน รูปแบบ และกลุ่มเป้าหมายพร้อมกันทั้งหมด\n- ทดสอบแค่เส้นทางที่เป็นสุข (happy path)\n- แก้ผลลัพธ์ก่อนกำหนดข้อยกเว้น\n\nข้อสุดท้ายคือการเปลี่ยนมากเกินไประหว่างการแก้ไข หากคุณเขียนเป้าหมาย กลุ่มเป้าหมาย ตัวอย่าง และข้อจำกัดใหม่ทั้งหมดในการแก้ครั้งเดียว คุณจะไม่รู้ว่าปัจจัยไหนช่วยให้ดีขึ้น ให้เปลี่ยนทีละตัวแปรใหญ่ ๆ แล้วพรอมต์จะพัฒนารวดเร็วกว่า\n\n## การตรวจสอบด่วนก่อนส่งพรอมต์\n\nพรอมต์มักล้มเหลวด้วยเหตุผลง่าย ๆ ไม่ใช่เพราะคำพูดไม่ฉลาดพอ ก่อนกดส่ง อ่านมันเหมือนคนที่ไม่เคยรู้เรื่องนี้มาก่อน ถ้าคนคนนั้นไม่สามารถบอกได้ว่างานคืออะไร ความสำเร็จหน้าตาเป็นอย่างไร และอะไรต้องหลีกเลี่ยง โมเดลจะเดา\n\nประเด็นนี้สำคัญยิ่งเมื่อคุณขอเครื่องมืออย่าง Koder.ai ให้สร้างส่วนของแอป หน้า หรือเวิร์กโฟลว์จากแชท เพราะช่องว่างเล็ก ๆ ในพรอมต์อาจกลายเป็นช่องว่างใหญ่ในผลลัพธ์\n\n### เช็คลิสต์ก่อนส่งแบบง่าย\n\n- ระบุงานด้วยประโยคธรรมดาหนึ่งประโยค\n- เพิ่มหนึ่งหรือสองตัวอย่างอินพุตและผลลัพธ์ที่คาดหวัง\n- ระบุทุกบทบาทผู้ใช้ที่เกี่ยวข้อง\n- รวมข้อยกเว้นบางข้อ\n- ระบุว่าควรให้โมเดลถามคำถามก่อนทำถ้าสิ่งใดไม่ชัดเจนหรือไม่\n\nข้อสุดท้ายนี่มักพลาด ผลลัพธ์แย่หลายครั้งเกิดจากโมเดลพยายามช่วยและเติมรายละเอียดที่หายไปเอง หากคุณต้องการให้หยุดแล้วถาม ให้บอกตรง ๆ\n\nการทดสอบง่าย ๆ ช่วยได้: หลังอ่านพรอมต์ครั้งเดียว คุณตอบคำถามเหล่านี้ได้โดยไม่ต้องเดาหรือไม่?\n\n- นี่สำหรับใคร?\n- พวกเขาจะให้ข้อมูลอะไรเข้ามา?\n- ควรได้ผลลัพธ์แบบไหนกลับมา?\n- อะไรที่ห้ามเกิดขึ้น?\n- โมเดลควรทำอย่างไรเมื่อข้อมูลหาย?\n\nถ้าคำตอบข้อใดยังคลุมเครือ พรอมต์ยังไม่ชัด เจ็บบริบทเพิ่มอีกไม่กี่บรรทัด โดยเฉพาะตัวอย่างข้อมูล บทบาทผู้ใช้ และข้อยกเว้น มักช่วยได้มากกว่าการแต่งประโยคให้สวยขึ้นอีกครั้ง\n\n## ขั้นตอนปฏิบัติที่ทำได้จริง\n\nถ้าคุณอยากได้ผลลัพธ์ที่ดีขึ้นภายในวันพรุ่งนี้ อย่าเริ่มจากการหาคำพูดฉลาด ๆ ให้เริ่มเก็บพรอมต์แบบใช้ซ้ำได้สำหรับงานที่ทำบ่อย โครงสร้างง่าย ๆ ใช้ได้ดี: เป้าหมาย บทบาทผู้ใช้ ตัวอย่างอินพุต ผลลัพธ์ที่คาดหวัง และข้อยกเว้น\n\nจากนั้นสร้างคลังบริบทเล็ก ๆ เก็บตัวอย่างข้อมูลจริง กรณีขอบที่พบบ่อย และข้อผิดพลาดที่เคยเห็น สำหรับการตอบซัพพอร์ต อาจหมายถึงตั๋วปกติหนึ่งใบ ข้อความลูกค้าโกรธหนึ่งฉบับ และคำขอที่ควรยกระดับแทนตอบ\n\nรูทีนที่มีประโยชน์ไม่ซับซ้อน:\n\n- ใช้เทมเพลตเดิมสำหรับงานคล้ายกัน\n- เพิ่มตัวอย่างสมจริงหนึ่งหรือสองตัว\n- ระบุบทบาทผู้ใช้ที่เกี่ยวข้อง\n- รวมข้อยกเว้นก่อนส่ง\n- ตรวจผลลัพธ์แรกและจดว่าขาดบริบทอะไรไป\n\nข้อสุดท้ายสำคัญที่สุด เมื่อผลลัพธ์อ่อน หลายคนจะเขียนคำสั่งเดิมซ้ำสามครั้ง การแก้บริบทที่ขาดหายมักเร็วกว่าและได้ผลมากกว่าแต่งคำอีก\n\nถ้าคำตอบดูทั่วไป ให้เพิ่มตัวอย่างข้อมูล ถ้าใช้โทนหรือระดับรายละเอียดผิด ให้กำหนดบทบาทผู้ใช้ให้ชัดเจนขึ้น ถ้ามันล้มเหลวกับกรณีอึดอัด ให้ระบุข้อยกเว้นเป็นภาษาง่าย ๆ\n\nจดสั้น ๆ เอกสารเล็ก ๆ ต่อแต่ละงานที่ทำซ้ำก็พอ เมื่อเวลาผ่านไป คุณจะมีชุดพรอมต์ที่เชื่อถือได้และใช้เร็วขึ้น\n\nแนวคิดเดียวกันใช้ได้เมื่อคุณสร้างซอฟต์แวร์ผ่านแชท ไม่ใช่แค่เขียนข้อความ Koder.ai ให้คนสร้างเว็บ เซิร์ฟเวอร์ และแอปมือถือผ่านแชท ดังนั้นคุณภาพของการสร้างครั้งแรกยังขึ้นกับบริบทที่ให้มาอย่างมาก ถ้าผู้ก่อตั้งขอ CRM และรวมตัวอย่างลูกค้าจริง กฎบทบาทสำหรับนักขายและผู้จัดการ และข้อยกเว้นเช่นลูกค้าซ้ำหรือขั้นตอนการอนุมัติ ผลลัพธ์มักใกล้เคียงกับสิ่งที่ธุรกิจต้องการมากขึ้น\n\nคุณไม่ต้องมีไลบรารีพรอมต์ที่สมบูรณ์ในวันแรก เก็บพรอมต์ที่ได้ผล รวบรวมตัวอย่างแข็ง ๆ สั้น ๆ และมองผลลัพธ์แรกเป็นการทดสอบเร็ว ๆ เมื่อคุณแก้บริบทที่ขาดหายแทนไล่ตามคำพูดฉลาด ๆ ผลลัพธ์ถัดไปมักดีขึ้นเร็วขึ้น
