วิธีเขียนพรอมต์สำหรับ AI App Builder (พร้อมตัวอย่างก่อนและหลัง)
พรอมต์ที่ดีสำหรับ AI app builder อธิบายผลิตภัณฑ์ ไม่ใช่โค้ด ว่าใครใช้ เขาทำอะไรทีละขั้น แอปเก็บข้อมูลอะไร และใครได้รับอนุญาตให้เห็นอะไร หลังจากมีเวอร์ชันแรกแล้ว ให้ขอการเปลี่ยนแปลงที่ระบุชัดเจนหนึ่งอย่างต่อข้อความ บอกว่าอะไรต้องคงเดิม และอธิบายปัญหาด้วยรูปแบบ “ฉันทำ X คาดหวัง Y ได้ Z” นิสัยสามข้อนี้แก้ผลลัพธ์ที่น่าผิดหวังได้ส่วนใหญ่
ส่วนที่เหลือของคู่มือนี้อธิบายรูปแบบเหล่านี้อย่างละเอียด พร้อมตัวอย่างก่อนและหลังที่คุณนำไปปรับใช้ได้
ทำไมการสั่ง app builder ต่างจากการคุยกับ AI
เมื่อคุณถามผู้ช่วยแชตคำถาม พรอมต์ที่คลุมเครือจะได้คำตอบที่คลุมเครือ แล้วคุณก็ไปต่อ แต่เมื่อคุณสั่ง AI app builder ผลลัพธ์คือโปรแกรมที่ทำงานได้จริง ทุกช่องว่างในคำอธิบายของคุณจะถูกเติมด้วยการเดา และการเดาเหล่านั้นกลายเป็นโค้ด ตารางฐานข้อมูล และหน้าจอ ซึ่งคุณต้องใช้ต่อไปหรือย้อนกลับเอง
ดังนั้นเป้าหมายของพรอมต์ไม่ใช่การฟังดูฉลาด แต่คือการทำให้การตัดสินใจสำคัญ ๆ น้อยลงที่ต้องปล่อยให้เป็นเรื่องบังเอิญ คุณไม่จำเป็นต้องใช้ศัพท์เทคนิค สิ่งที่ต้องทำคือระบุให้ชัดในเรื่องที่มีแต่คุณเท่านั้นที่รู้ ได้แก่ ผู้ใช้ ขั้นตอนการทำงาน และกฎของคุณ
สิ่งที่ควรใส่ในพรอมต์แรก
ก่อนเขียนอะไร ให้ตอบคำถามเหล่านี้ แต่ละข้อปิดช่องว่างที่ AI จะต้องเดาไม่เช่นนั้น
| ควรใส่ | เหตุผล | ตัวอย่าง |
|---|---|---|
| ผลิตภัณฑ์ในประโยคเดียว | กำหนดกรอบให้ทุกการตัดสินใจหลังจากนั้น | “เว็บจองคิวสำหรับร้านตัดผมที่มีเก้าอี้สองตัว” |
| ใครใช้ | กำหนดหน้าจอและโทนของงาน | “ลูกค้าที่เดินเข้ามาใช้มือถือ และเจ้าของร้านใช้แล็ปท็อป” |
| ขั้นตอนหลักทีละขั้น | สิ่งที่ต้องทำงานได้ก่อนเป็นอันดับแรก | “เลือกบริการ เลือกเวลา กรอกชื่อและเบอร์โทร แล้วได้รับการยืนยัน” |
| ข้อมูลที่เก็บ | กลายเป็นการออกแบบฐานข้อมูล | “บริการ การจอง ลูกค้า” |
| ใครเห็นหรือแก้ไขอะไรได้ | กำหนดการเข้าสู่ระบบและสิทธิ์ | “มีเพียงเจ้าของที่เห็นการจองทั้งหมด” |
| ลุคและฟีลสั้น ๆ | หลีกเลี่ยงสไตล์เริ่มต้นที่ดูทั่วไป | “มืด เรียบง่าย ปุ่มขนาดใหญ่” |
| สิ่งที่ตัดออกไปก่อน | ทำให้เวอร์ชันแรกเล็ก | “ยังไม่มีการชำระเงินหรือรีวิว” |
แถวสุดท้ายนี้มักถูกมองข้าม การบอกสิ่งที่คุณ ไม่ ต้องการจะหยุดไม่ให้ AI เพิ่มบล็อก หน้าราคา และฟอร์มสมัครรับข่าวสารที่คุณไม่ได้ขอ
ก่อนและหลัง: พรอมต์แรก
ก่อน:
ทำแอปสำหรับยิมของฉันให้หน่อย
Builder ต้องเดาทุกอย่าง: สมาชิกหรือพนักงาน? คลาสหรือเทรนส่วนตัว? มีการชำระเงินไหม? สิ่งที่ได้คือเว็บไซต์ยิมที่ดูดี แต่ไม่ทำในสิ่งที่คุณต้องการ
หลัง:
สร้างแอปจองคลาสสำหรับสตูดิโอโยคะขนาดเล็ก สมาชิกดูคลาสของสัปดาห์นี้ (ชื่อ ผู้สอน เวลา ที่นั่งที่เหลือ) จองที่นั่ง และยกเลิกได้ก่อนเริ่มสองชั่วโมง สมาชิกสมัครด้วยอีเมลและรหัสผ่าน เจ้าของสตูดิโอเข้าสู่ระบบเพื่อเพิ่มคลาส ดูว่าใครจองไว้ และทำเครื่องหมายการเข้าเรียน เก็บคลาส สมาชิก และการจองไว้ในฐานข้อมูล ดีไซน์โทนอ่อน เรียบ ใช้งานได้ดีบนมือถือ ยังไม่มีการชำระเงิน
เวอร์ชันหลังยังคงสั้น เพียงแต่ตอบคำถามในตารางด้านบน
อธิบายพฤติกรรม ไม่ใช่วิธีทำ
บ่อยครั้งผลลัพธ์จะดีกว่าหากคุณอธิบายว่าควร เกิดอะไรขึ้น แทนที่จะบอกวิธีสร้าง
ก่อน:
เพิ่ม useEffect ที่ดึงข้อมูลการจอง และคอมโพเนนต์ modal สำหรับแก้ไข
หลัง:
เมื่อเจ้าของคลิกการจอง ให้เปิดแผงที่เปลี่ยนเวลาหรือยกเลิกได้ การเปลี่ยนแปลงควรแสดงในรายการทันที
พรอมต์แรกจะล็อก AI ให้ใช้เทคนิคเฉพาะซึ่งอาจไม่เหมาะกับวิธีที่แอปถูกสร้างไว้ ส่วนพรอมต์หลังบอกผลลัพธ์และปล่อยให้ AI เลือกแนวทางที่ถูกต้องสำหรับโค้ดที่มีอยู่แล้ว ถ้าคุณเป็นนักพัฒนาและมีความต้องการที่แน่นอน ให้บอกไป แต่ควรบอกควบคู่กับผลลัพธ์ที่ต้องการ
ระบุกฎให้ชัดเจน
กฎทางธุรกิจคือจุดที่แอปที่สร้างด้วย AI มักผิดพลาดมากที่สุด เพราะมันชัดเจนสำหรับคุณแต่มองไม่เห็นสำหรับ AI เขียนออกมาให้ครบ
- ขีดจำกัด: “สมาชิกหนึ่งคนถือการจองในอนาคตได้มากที่สุดสามรายการ”
- เวลา: “การยกเลิกปิดรับก่อนคลาสเริ่มสองชั่วโมง”
- กรณีพิเศษ: “ถ้าคลาสเต็ม ให้แสดงปุ่มรายชื่อรอแทนปุ่มจอง”
- สิทธิ์: “ผู้สอนดูการเข้าเรียนของคลาสตัวเองได้ แต่ดูของผู้สอนคนอื่นไม่ได้”
แต่ละข้อคือประโยคเดียว หากขาดข้อใดไป แอปจะไม่บังคับใช้กฎนั้น หรือไม่ก็สร้างเวอร์ชันของตัวเองขึ้นมาแทน
หลังเวอร์ชันแรก: หนึ่งการเปลี่ยนแปลงต่อหนึ่งข้อความ
เมื่อมีบางอย่างทำงานอยู่ในพรีวิวแล้ว ให้เปลี่ยนจากการอธิบายทั้งผลิตภัณฑ์ไปเป็นการขอการเปลี่ยนแปลงเล็ก ๆ ที่ตรวจได้
ก่อน:
ดีไซน์ไม่ถูก การจองยังใช้ไม่ได้ดี และฉันอยากได้มุมมองปฏิทินกับอีเมลด้วย
หลัง (ส่งเป็นสี่ข้อความแยกกัน):
- เมื่อฉันจองที่นั่งสุดท้ายของคลาส คลาสยังแสดง “เหลือ 1 ที่นั่ง” ควรแสดง “เต็ม” และซ่อนปุ่มจอง
- เพิ่มปฏิทินมุมมองรายสัปดาห์ในหน้าตารางเวลา โดยแต่ละคอลัมน์คือหนึ่งวัน และคงมุมมองรายการปัจจุบันไว้เป็นตัวเลือก
- ทำการ์ดคลาสให้กระชับขึ้นบนมือถือ: ลด padding และให้ชื่อผู้สอนอยู่บรรทัดเดียวกับเวลา
- ส่งอีเมลยืนยันให้สมาชิกเมื่อเขาจอง
ทำไมวิธีนี้ได้ผล:
- การเปลี่ยนแปลงแต่ละอย่างเล็กพอที่ AI จะทำได้ถูกต้องในรอบเดียว
- คุณทดสอบได้ทีละอย่างก่อนไปต่อ
- หากอย่างหนึ่งผิดพลาด คุณย้อนกลับเฉพาะขั้นตอนนั้นได้โดยไม่เสียขั้นอื่น
บอกว่าต้องคงอะไรไว้
เมื่อขอให้เปลี่ยนสิ่งที่ทำงานอยู่แล้ว ให้บอก AI ว่าอะไรต้องไม่เปลี่ยน นี่คือวิธีที่ง่ายที่สุดในการหยุดการถดถอย (regression) คือสิ่งที่เคยทำงานได้แต่กลับพังหลังการแก้ไข
ออกแบบส่วนหัวของหน้าแรกใหม่ ให้หัวข้อใหญ่ขึ้นและมีรูปด้านขวา คงเมนู สี และทุกอย่างใต้ส่วนหัวไว้ให้เหมือนเดิมทุกประการ
หลักการเดียวกันใช้กับข้อมูลด้วย “เพิ่มช่องเบอร์โทรให้สมาชิก อย่าลบหรือเปลี่ยนชื่อฟิลด์ที่มีอยู่”
ใช้ภาพหน้าจอและข้อความที่แน่นอน
คำว่า “สิ่งที่อยู่ด้านบน” คลุมเครือ app builder ส่วนใหญ่รับรูปภาพได้ และภาพหน้าจอพร้อมโน้ตสั้น ๆ เร็วกว่าย่อหน้าคำอธิบาย
- แนบภาพหน้าจอและบอกว่า “ปุ่มที่วงสีแดงทับเมนูบนมือถือ”
- วางข้อความ error ทั้งหมดตามที่แสดง อย่าสรุปเอง
- อ้างป้ายชื่อบนหน้าจออย่างแม่นยำ: “ปุ่ม Save changes ในหน้า Settings”
สำหรับบั๊กโดยเฉพาะ ใช้รูปแบบนี้:
ที่หน้าการจอง ฉันกด Cancel ที่การจองของพรุ่งนี้ ฉันคาดหวังว่ามันจะหายไปจากรายการ แต่ไม่มีอะไรเกิดขึ้น และการจองยังอยู่หลังจากรีเฟรช แก้ให้ด้วย และตรวจว่าการยกเลิกใช้งานได้
คู่มือวิธีดีบักแอปที่สร้างด้วย AI อธิบายเรื่องนี้เพิ่มเติม
วางแผนก่อนสำหรับการเปลี่ยนแปลงใหญ่
สำหรับทุกอย่างที่กระทบหลายส่วนของแอป เช่น เพิ่มบัญชีผู้ใช้ให้แอปที่ไม่เคยมี เพิ่มการชำระเงิน หรือเปลี่ยนโครงสร้างข้อมูล ให้ขอแผนก่อนที่โค้ดจะเปลี่ยน
ก่อนเปลี่ยนอะไร ช่วยอธิบายว่าคุณจะเพิ่มบัญชีทีมอย่างไร: ตารางใหม่อะไรบ้าง หน้าไหนเปลี่ยน และผู้ใช้เดิมจะเป็นอย่างไร ยังไม่ต้องแก้โค้ด
อ่านแผนนั้น ถ้ามันเข้าใจอะไรผิด การแก้ย่อหน้าเดียวถูกกว่าการแก้ฟีเจอร์ที่เสร็จแล้วมาก builder หลายตัวมีโหมดเฉพาะสำหรับเรื่องนี้ ใน Mythex คือโหมด Plan ควบคู่กับ Build และ Ask
สิ่งที่ควรหลีกเลี่ยง
| หลีกเลี่ยง | เหตุผล | ควรทำแทน |
|---|---|---|
| “ทำให้ดีขึ้น” / “ทำให้เด่น” | ไม่มีเป้าหมาย AI จึงเปลี่ยนสิ่งต่าง ๆ แบบสุ่ม | ระบุการเปลี่ยนแปลง: “เว้นระยะระหว่างส่วนให้มากขึ้น หัวข้อใหญ่ขึ้น” |
| พรอมต์ยักษ์หนึ่งอันที่มีสิบฟีเจอร์ | ข้อผิดพลาดทบต้น ทดสอบยาก | หนึ่งฟีเจอร์ต่อหนึ่งข้อความ |
| วางคีย์ API ลงในแชต | คีย์จะติดอยู่ในประวัติแชต | ใช้ secrets หรือการตั้งค่า environment ของ builder |
| เถียงกับผลลัพธ์ที่เสียอยู่ | การแก้ทุกครั้งซ้อนทับบั๊ก | ย้อนกลับ แล้วเขียนใหม่ |
| ระบุโค้ดที่คุณไม่เข้าใจ | ล็อกการทำงานที่ไม่เหมาะ | อธิบายพฤติกรรมที่ต้องการ |
| ขอ “ความปลอดภัยระดับองค์กร” | ไม่มีความหมายที่เฉพาะเจาะจง | ไล่กฎจริง: ใครเห็นอะไรได้บ้าง |
เรื่องคีย์ API: ถ้าคุณต้องใช้บริการชำระเงินหรืออีเมล ให้ใส่คีย์ในส่วน secrets ของโปรเจกต์ ไม่ใช่ในพรอมต์ ดูตัวแปร environment และ secrets คืออะไร หากยังไม่คุ้นเคย
เทมเพลตพรอมต์ที่นำกลับมาใช้ได้
ปรับใช้โดยแทนที่ส่วนในวงเล็บ
แอปใหม่:
สร้าง[ประเภทแอป]สำหรับ[ใคร] พวกเขา[ขั้นตอนหลักทีละขั้น] [ผู้ใช้ประเภทที่สอง]เข้าสู่ระบบเพื่อ[สิ่งที่ทำ] เก็บ[ข้อมูล]ในฐานข้อมูล [ลุคและฟีล] ไม่ต้องใส่[สิ่งที่จะทำทีหลัง]
ฟีเจอร์ใหม่:
เพิ่ม[ฟีเจอร์]ในหน้า[หน้า] เมื่อ[ผู้ใช้]ทำ[การกระทำ] ให้[สิ่งที่ควรเกิดขึ้น] เฉพาะ[ใคร]ที่[ทำได้] คง[สิ่งที่มีอยู่]ไว้ตามเดิม
เปลี่ยนดีไซน์:
ในหน้า[หน้า] เปลี่ยน[องค์ประกอบเฉพาะ]เป็น[การเปลี่ยนแปลงเฉพาะ] คง[สิ่งที่ต้องคงไว้] และตรวจว่าดูถูกต้องบนหน้าจอความกว้างมือถือ
บั๊ก:
ที่หน้า[หน้า] ฉัน[ขั้นตอน] ฉันคาดหวัง[สิ่งที่คาดหวัง] แต่กลับ[สิ่งที่เกิดขึ้นจริง พร้อมข้อความ error ตามที่แสดง] แก้ให้ และตรวจว่าขั้นตอนทำงานได้
คำถามโดยไม่แก้ไข:
ไม่ต้องเปลี่ยนโค้ดใด ๆ ช่วยอธิบายว่า[ส่วนหนึ่งของแอป]ทำงานอย่างไร และ[ข้อมูล]ถูกเก็บไว้ที่ไหน
การเขียนสเปกที่ยาวขึ้น
สำหรับโปรเจกต์ใหญ่ การเขียนบรีฟหนึ่งหน้าก่อนและวางเป็นพรอมต์เปิดอาจช่วยได้ ได้แก่ ผู้ใช้ ขั้นตอนหลัก ข้อมูล กฎ และสิ่งที่อยู่นอกขอบเขต คุณอาจให้ AI ช่วยร่างก็ได้ คู่มือวิธีเขียนเอกสาร product requirements ด้วย AI อธิบายวิธีนั้น เพียงแต่ให้คำขอสร้างครั้งแรกมีแค่ขั้นตอนหลัก แล้วเพิ่มส่วนที่เหลือทีละขั้น
การเขียนพรอมต์ใน Mythex
ทุกอย่างข้างต้นใช้ได้กับ Mythex มีรายละเอียดบางอย่างที่ช่วยได้:
- โหมด Build, Plan และ Ask ใช้ Plan กับการเปลี่ยนแปลงที่ใหญ่หรือมีความเสี่ยง และใช้ Ask เมื่อต้องการคำอธิบายโดยไม่แก้ไข
- Checkpoints หลังการเปลี่ยนแปลงที่สำเร็จแต่ละครั้ง Mythex จะบันทึก checkpoint และ Revert to this point ที่ข้อความตอบกลับจะย้อนโปรเจกต์กลับไปได้ คุณยังแก้ข้อความก่อนหน้าและส่งใหม่เพื่อลองพรอมต์อื่นจากจุดนั้นได้
- การ์ด Secrets เมื่อเอเจนต์ต้องการคีย์ API มันจะถามผ่านการ์ดในแชต ค่าจึงถูกเก็บเป็น secret ของโปรเจกต์ แทนที่จะถูกเขียนลงในข้อความของคุณ
- รูปภาพ แนบภาพหน้าจอหรือแบบร่าง แล้วเอเจนต์จะดูภาพนั้น
เอกสารมีหน้าสั้น ๆ เกี่ยวกับพรอมต์ที่ได้ผล และอีกหน้าเกี่ยวกับการปรับแก้โดยไม่ต้องสร้างใหม่ หากคุณเริ่มจากศูนย์ วิธีสร้างแอปด้วย AI อธิบายโปรเจกต์เต็มรูปแบบ และวิธีออกแบบแอปให้ดูดีด้วย AI ครอบคลุมพรอมต์สำหรับการขัดเกลาภาพลักษณ์
คำถาม
พรอมต์สำหรับ AI app builder ควรยาวแค่ไหน?
สำหรับเวอร์ชันแรก ย่อหน้าสั้น ๆ สี่ถึงแปดประโยคมักเพียงพอ ได้แก่ ใครใช้แอป ขั้นตอนหลักคืออะไร ข้อมูลที่เก็บ และใครเห็นอะไรได้บ้าง หลังจากนั้น พรอมต์สั้น ๆ ที่ขอเปลี่ยนแปลงทีละอย่างจะได้ผลดีกว่าพรอมต์ยาว
ควรบอก AI ว่าจะใช้เฟรมเวิร์กหรือภาษาอะไรไหม?
บอกเฉพาะเมื่อมีเหตุผล เช่น มีนักพัฒนาที่จะดูแลโค้ดต่อ หรือมีบริการที่ทำงานได้กับสแต็กเดียวเท่านั้น นอกจากนั้นให้อธิบายผลิตภัณฑ์และให้ builder เลือกค่าเริ่มต้นที่เหมาะสมเอง
ทำไม AI ถึงเปลี่ยนสิ่งที่ฉันไม่ได้ขอให้เปลี่ยนอยู่เรื่อย?
มักเป็นเพราะพรอมต์กว้างเกินไป (เช่น “ทำให้ดีขึ้น”) หรือไม่ได้บอกว่าต้องคงอะไรไว้ ระบุสิ่งที่ต้องเปลี่ยนให้ชัดเจน บอกว่าอะไรต้องคงเดิม และขอให้เปลี่ยนหนึ่งอย่างต่อหนึ่งข้อความ
ควรแก้ผลลัพธ์ที่ไม่ดีด้วยพรอมต์เพิ่ม หรือเริ่มใหม่ดี?
ถ้าการเปลี่ยนแปลงครั้งล่าสุดทำให้แย่ลง ให้ย้อนกลับไปเวอร์ชันก่อนหน้าแล้วเขียนใหม่ อย่าซ้อนการแก้ทับลงไปเรื่อย ๆ เริ่มโปรเจกต์ใหม่เฉพาะเมื่อไอเดียเองเปลี่ยนไปแล้วเท่านั้น