วิธีเขียนพรอมต์สำหรับ AI App Builder (พร้อมตัวอย่างก่อน/หลังชัด ๆ)
ลองดูคนสองคนใช้ AI app builder ตัวเดียวกันเป็นเวลาหนึ่งชั่วโมง คนหนึ่งได้แอปที่ใช้งานได้ อีกคนได้กองความยุ่งเหยิงกับความเห็นว่า "AI coding มันโดนอวยเกินจริง" เครื่องมือเหมือนกันทุกอย่าง พรอมต์ต่างหากที่ไม่เหมือน
การพรอมต์ app builder เป็นทักษะคนละแบบกับการพรอมต์แชตบอต คุณไม่ได้กำลังถามคำถาม — คุณกำลังออกใบสั่งงานให้เอเจนต์ที่จะตัดสินใจหลายสิบเรื่องจากสิ่งที่คุณพูดและไม่ได้พูด นี่คือสิ่งที่ได้ผลจริง พร้อมตัวอย่างก่อน/หลังตลอดทั้งบทความ
พรอมต์แรก: ใส่การตัดสินใจให้ครบ ข้ามเรื่องการ implement
พรอมต์เปิดของคุณวางรากฐานของโปรเจกต์ เอเจนต์จะเติมทุกช่องว่างที่คุณทิ้งไว้ด้วยการเดา และแม้เอเจนต์เก่ง ๆ จะเดาอย่างมีเหตุผล ทุกการเดาคือการโยนเหรียญว่าจะตรงกับเจตนาคุณหรือไม่
ก่อน:
ทำแอปฟิตเนสให้หน่อย
หลัง:
สร้างแอปบันทึกการออกกำลังกายสำหรับสายยกเวท ข้อมูล: เวิร์กเอาต์มีวันที่ แต่ละเวิร์กเอาต์มีรายการบันทึกที่ระบุชื่อท่า เซ็ต ครั้ง และน้ำหนัก หน้าจอ: (1) บันทึกวันนี้พร้อมช่องกรอกด่วน (2) ประวัติจัดกลุ่มตามสัปดาห์ (3) กราฟพัฒนาการรายท่า ใช้คนเดียว ไม่ต้องมีล็อกอิน ดีไซน์โทนมืด มินิมอล
เวอร์ชัน "หลัง" ตัดสินใจเรื่องกลุ่มเป้าหมาย โครงสร้างข้อมูล หน้าจอ ขอบเขตการยืนยันตัวตน และทิศทางดีไซน์ — ห้าการตัดสินใจที่แก้ทีหลังแพงที่สุด สังเกตด้วยว่ามัน ไม่ ใส่อะไร: ไม่มี tech stack ไม่มีการเลือกฐานข้อมูล ไม่มี component library แพลตฟอร์มที่ดีตัดสินใจเรื่องพวกนั้นได้ดีกว่าพรอมต์ และการยัดศัพท์เทคนิคที่เข้าใจครึ่ง ๆ กลาง ๆ ลงในบรีฟมีแต่ผลเสีย ("ใช้ MongoDB" ทั้งที่แพลตฟอร์มสร้างมาบน Postgres มีแต่จะสร้างแรงเสียดทาน)
โครงสร้างที่ได้ผลสม่ำเสมอ:
- มันคืออะไร ในหนึ่งประโยค พร้อมกลุ่มเป้าหมาย
- ข้อมูล เป็นคำนามกับฟิลด์ธรรมดา ๆ
- หน้าจอ ใส่หมายเลขกำกับ
- ข้อยกเว้นที่ชัดเจน — "ไม่ต้องมีล็อกอิน" "ไม่ต้องมีระบบชำระเงิน" ข้อยกเว้นป้องกันขอบเขตงานที่เอเจนต์จะหวังดีคิดเผื่อให้เอง
พรอมต์ปรับแก้: หนึ่งการเปลี่ยนแปลง ผูกกับตำแหน่งเสมอ
หลังการสร้างครั้งแรก พรอมต์ของคุณเปลี่ยนบุคลิก: จากงานสถาปัตยกรรมเป็นงานผ่าตัด กฎสองข้อทำงานได้เกือบทั้งหมด
หนึ่งการเปลี่ยนแปลงต่อหนึ่งข้อความ คำขอแบบยัดรวมล้มเหลวเป็นก้อนเดียวกัน — เมื่อหนึ่งในห้าการเปลี่ยนแปลงออกมาผิด คุณต้องพรอมต์ใหม่โดยระวังไม่ให้กระทบอีกสี่อย่าง
ผูกทุกการเปลี่ยนแปลงกับตำแหน่ง
ก่อน:
วันที่ดูแปลก ๆ
หลัง:
ในหน้าประวัติ หัวข้อสัปดาห์แสดงว่า "Week 32" ให้แสดงเป็นช่วงวันที่แทน เช่น "4 ส.ค. – 10 ส.ค."
ระบุหน้าจอ ยกข้อความที่ผิดมาให้ดู บรรยายข้อความที่ถูก เอเจนต์จะหาจุดที่ต้องแก้เจอทันทีแทนที่จะงมหา — เดาผิดน้อยลง เครดิตหายน้อยลง
บรรยายผลลัพธ์ ไม่ใช่วิธี implement
คุณจะถูกล่อใจให้พูดเหมือนโปรแกรมเมอร์ อดทนไว้ ยกเว้นว่าคุณเป็นจริง ๆ
ก่อน:
เพิ่ม useEffect ที่ refetch ตอน mount แล้ว memoize การเรนเดอร์ลิสต์ด้วย
หลัง:
พอฉันกลับมาที่แดชบอร์ดหลังเพิ่มรายจ่าย ยอดรวมยังโชว์ตัวเลขเก่าจนกว่าจะรีเฟรช มันควรอัปเดตทันที
เวอร์ชันแรกผูกมัดเอเจนต์กับการวินิจฉัย ของคุณ ซึ่งอาจผิด เวอร์ชันที่สองให้ตัวปัญหาจริง — สิ่งที่คุณมั่นใจ — แล้วปล่อยให้มันหาสาเหตุเอง บรรยายอาการด้วยความมั่นใจแบบผู้ใช้ ปล่อยการวินิจฉัยให้สิ่งที่อ่านโค้ดได้
ใช้ตัวอย่างอ้างอิง — มันชนะคำคุณศัพท์ขาดลอย
"โมเดิร์นและคลีน" ไม่มีความหมายอะไรเลย ดีไซน์ทุกชิ้นตั้งแต่ปี 2010 ก็อ้างแบบนี้ทั้งนั้น ตัวอย่างอ้างอิงบรรจุข้อมูลได้มากกว่าหลายเท่าตัว:
ทำให้ส่วนราคาให้ความรู้สึกเหมือนหน้าราคาของ Linear: พื้นที่ว่างเยอะ ๆ เส้นขอบบาง สีเน้นสีเดียว
ดีกว่านั้นอีกคือแนบสกรีนช็อต — ของแอปที่คุณชอบ ของสเก็ตช์ที่วาดมือ ของเลย์เอาต์พังที่คุณกำลังบรรยายอยู่ แพลตฟอร์มที่รับไฟล์แนบรูปภาพได้ (Massvai รับ) คลี่คลายความกำกวมทางภาพจากรูปหนึ่งรูปได้เร็วกว่าจากคำบรรยายมาก สกรีนช็อตของบั๊กพร้อมแคปชันหนึ่งบรรทัดคือฟอร์แมตพรอมต์ที่คุ้มค่าที่สุดเท่าที่มี
เมื่อมันพัง: หยุดขุดหลุมต่อ
ความผิดพลาดด้านพรอมต์ที่แพงที่สุดไม่ใช่พรอมต์แย่ ๆ — แต่คือความพยายามครั้งที่สี่ติดต่อกันในการปะผุทิศทางที่ผิดตั้งแต่ราก
ถ้าลองแก้แบบเดิมสองครั้งแล้วยังไม่ได้ผล เปลี่ยนกลยุทธ์:
- ย้อนกลับ กู้คืนเช็กพอยต์ก่อนความยุ่งเหยิง (Massvai สแนปช็อตทุกการสร้าง) แล้วเข้าหาใหม่ด้วยคำอธิบายใหม่ การถอยหลังรู้สึกเหมือนขาดทุน แต่ส่วนใหญ่มันคือทางไปข้างหน้าที่เร็วที่สุด
- ถอยมามองภาพใหญ่ แทนที่จะอธิบายวิธีแก้ซ้ำ ๆ ให้อธิบายเป้าหมาย: "ลืมคำสั่งก่อนหน้าเรื่อง dropdown ตัวกรองไปก่อน สิ่งที่ฉันอยากให้ผู้ใช้ทำได้จริง ๆ คือ: …" เอเจนต์รับมือเป้าหมายใหม่สด ๆ ได้ดีกว่าคำสั่งปะผุที่สะสมมาเรื่อย ๆ
สรุปสูตรลัด
| สถานการณ์ | ทำ | อย่าทำ |
|---|---|---|
| เริ่มโปรเจกต์ | กลุ่มเป้าหมาย + ข้อมูล + หน้าจอ + ข้อยกเว้น | "ทำแอปเกี่ยวกับ X ให้หน่อย" |
| ขอแก้ไข | หนึ่งการเปลี่ยนแปลง ผูกกับหน้าจอ | ห้าการเปลี่ยนแปลงในข้อความเดียว |
| รายงานบั๊ก | อาการ ตำแหน่ง พฤติกรรมที่ควรเป็น | การเดาสาเหตุระดับโค้ดของคุณ |
| ทิศทางดีไซน์ | แอปอ้างอิงและสกรีนช็อต | ซุปคำคุณศัพท์ |
| ติดขัดหลังลอง 2 ครั้ง | ย้อนกลับ แล้วอธิบายเป้าหมายใหม่ | กด "ลองอีกครั้ง" เป็นครั้งที่ห้า |
ทั้งหมดนี้ไม่ใช่เรื่องลึกลับ มันคือความชัดเจนแบบเดียวกับที่คุณพึงมีให้ผู้รับเหมาที่เป็นมนุษย์ — เพียงแต่ผู้รับเหมารายนี้อ่านอย่างละเอียด ไม่เคยรำคาญรายละเอียด และเริ่มงานในไม่กี่วินาที มอบบรีฟที่คู่ควรกับมันเถอะ