พรอมต์ 20 ข้อสำหรับให้ AI เขียนโค้ด โดยไม่ต้องเดา

โค้ดจาก AI ที่แย่ส่วนใหญ่เกิดจากโมเดลเติมช่องว่างที่คุณทิ้งไว้เอง พรอมต์แต่ละข้อในหน้านี้ปิดช่องว่างหนึ่งจุด โมเดลจะอ่านก่อนเขียน ทดสอบก่อนแก้ และจัดอันดับข้อสันนิษฐานของตัวเองให้เห็นชัด

แทนที่ทุกอย่างใน [วงเล็บเหลี่ยม] ด้วย โค้ด ข้อผิดพลาด หรือเป้าหมายของคุณเอง

01. ประเมินขอบเขตผลกระทบก่อนแตะโค้ดใดๆ

ก่อนแก้โค้ดที่คุณไม่ได้เขียนเอง

อ่านโค้ดด้านล่าง ยังไม่ต้องเขียนหรือแก้โค้ดใดๆ

บอกฉันว่า:
1. โค้ดนี้ทำอะไร ไม่เกินสามประโยค
2. ข้อสมมติทุกข้อที่โค้ดตั้งไว้เกี่ยวกับอินพุต ตัวที่เรียกใช้ และสภาพแวดล้อม
3. ถ้าฉัน [อธิบายการเปลี่ยนแปลงที่ต้องการทำ] อะไรจะพัง และพังตรงไหน

ถ้าต้องดูไฟล์อื่นเพื่อตอบ ให้ระบุชื่อไฟล์นั้นแล้วหยุด

[วางโค้ด]

02. จัดอันดับสาเหตุก่อนเริ่มเขียนวิธีแก้

บั๊กที่ยังอธิบายไม่ได้

นี่คือข้อผิดพลาดและโค้ดรอบๆ จุดที่เกิด

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

อย่าเสนอวิธีแก้ ฉันจะรันการตรวจสอบเองแล้วบอกว่าเป็นสาเหตุไหน

ข้อผิดพลาดและสแตกเทรซ:
[วางข้อผิดพลาด]

โค้ด:
[วางโค้ดที่เกี่ยวข้อง]

03. เขียนเทสต์ที่ต้องล้มเหลวก่อน แล้วหยุด

ก่อนขอให้เขียนโค้ดใหม่หรือวิธีแก้

เขียนเทสต์สำหรับ [ฟังก์ชันหรือฟีเจอร์] โดยใช้ [เฟรมเวิร์กทดสอบ]

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

ทุกเทสต์ต้องล้มเหลวเมื่อรันกับโค้ดปัจจุบันหรือโค้ดที่ยังไม่มีส่วนที่เขียนจริง อย่าเขียนส่วนที่ทำงานจริง

ปลดล็อกอีก 17 พรอมต์ ฟรี เพียงสมัครรับจดหมายข่าว

สมัครรับจดหมายข่าวของ Whizi เพื่ออ่านพรอมต์ที่เหลือในชุดนี้

  1. รีวิวดิฟฟ์ในมุมของคนที่ต้องถูกโทรปลุก
  2. รีแฟกเตอร์โดยไม่เปลี่ยนพฤติกรรมแม้แต่อย่างเดียว
  3. เลือกห้าไฟล์ที่ควรอ่านก่อน
  4. เขียนคิวรีจากสกีมาจริงของคุณ
  5. ได้เรเกกซ์พร้อมกรณีทดสอบที่พิสูจน์ได้
  6. พอร์ตโค้ดให้อ่านเหมือนเจ้าของภาษาเขียน
  7. หาว่าเวลาหายไปไหนจากโปรไฟล์จริง
  8. ตามรอยอินพุตที่ไม่น่าไว้ใจจากต้นทางถึงปลายทาง
  9. เขียน README ที่คนแปลกหน้าใช้ได้
  10. เขียนข้อความคอมมิตจากดิฟฟ์
  11. เรียนรู้แนวคิดจากโค้ดของคุณเอง
  12. ออกแบบ API แล้วโจมตีดีไซน์นั้น
  13. วางแผนไมเกรชันที่ไม่ทำให้เว็บล่ม
  14. ให้โมเดลเป็นฝ่ายถามคำถาม
  15. ระบุอินพุตที่จะทำให้พัง
  16. หาว่าการอัปเกรดไลบรารีทำโค้ดของคุณพังตรงไหน
  17. ให้โมเดลตัวที่สองตรวจให้คะแนนตัวแรก