แพ็กพรอมต์เขียนโค้ดด้วย Claude สำหรับดีบัก รีแฟกเตอร์ และรีวิวสถาปัตยกรรม

เงื่อนไขสี่ข้อที่ทำให้พรอมต์ทุกแบบด้านล่างนี้ได้ผล

ก่อนเข้าเรื่องพรอมต์ นี่คือกฎที่ทุกพรอมต์มีร่วมกัน การเพิ่มกฎเหล่านี้เข้าไปในพรอมต์เขียนโค้ดใดก็ตามช่วยปรับปรุงผลลัพธ์ได้มากกว่าการเปลี่ยนโมเดล

ระบุเวอร์ชันที่ใช้. ข้อมูลฝึกโมเดลมักเอนเอียงไปทางเวอร์ชันหลักที่มีการเขียนถึงมากที่สุด ซึ่งมักไม่ใช่เวอร์ชันที่คุณใช้อยู่ การเขียน We are on [framework] [version], [language] [version] ช่วยป้องกันคำตอบที่ล้าสมัยได้ส่วนใหญ่

จำกัดขอบเขตของดิฟ. ขอแค่ทางแก้ แต่บ่อยครั้งกลับได้การรีแฟกเตอร์มาแทน ประโยค Change as little as possible, preserve existing structure and naming, and list every line you changed with a one line reason คือประโยคที่มีประโยชน์ที่สุดเพียงประโยคเดียวในเอกสารนี้

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

เรียกร้องผลกระทบที่อาจเกิดขึ้น. คำถาม What could this break, and is this fixing the cause or the symptom? ช่วยจับความช่วยเหลือของ AI ที่มีต้นทุนแพงที่สุด คือการแก้ไขที่ทำให้อาการหายไปแต่ข้อบกพร่องยังอยู่

การดีบัก

1. สมมติฐานที่จัดอันดับ

นี่คือข้อผิดพลาด โค้ดที่เกี่ยวข้อง และสิ่งที่ฉันตัดออกไปแล้ว อย่าเพิ่งให้ทางแก้กับฉัน ให้ระบุสาเหตุที่เป็นไปได้มากที่สุดสี่ข้อ จัดอันดับตามความน่าจะเป็น และสำหรับแต่ละข้อให้บอกวิธีตรวจสอบที่ง่ายและถูกที่สุดเพียงวิธีเดียวที่จะยืนยันหรือตัดสาเหตุนั้นออก ข้อผิดพลาด: [paste]. โค้ด: [paste]. สิ่งที่ตัดออกไปแล้ว: [list]. สแตก: [language, framework, versions].

2. บั๊กที่เกิดเป็นบางครั้ง

สิ่งนี้ล้มเหลวเป็นบางครั้ง ประมาณ [frequency] ภายใต้เงื่อนไข [conditions] ให้ระบุหมวดหมู่ของความล้มเหลวแบบไม่สม่ำเสมอที่อาจทำให้เกิดอาการนี้โดยเฉพาะ ได้แก่ จังหวะเวลา ลำดับการทำงาน การใช้ทรัพยากรจนหมด การพึ่งพาระบบภายนอก สถานะที่รั่วไหลระหว่างการรัน นาฬิกาหรือเขตเวลา และแคช สำหรับแต่ละหมวดให้บอกว่าอะไรในโค้ดสนับสนุนหรือขัดแย้งกับหมวดนั้น และบอกให้ชัดเจนว่าฉันควร log อะไรเพื่อแยกแยะสาเหตุเหล่านี้ โค้ด: [paste].

3. รันได้บนเครื่อง local

สิ่งนี้ทำงานได้บนเครื่อง local แต่ล้มเหลวใน [environment] ให้ระบุทุกหมวดหมู่ของความแตกต่างของสภาพแวดล้อมที่อาจทำให้เกิดอาการนี้โดยเฉพาะ ได้แก่ การตั้งค่า ตัวแปรสภาพแวดล้อม เวอร์ชัน ระบบไฟล์และการแยกตัวพิมพ์เล็กใหญ่ เขตเวลาและภาษาท้องถิ่น เครือข่ายและ DNS สิทธิ์การเข้าถึง ขีดจำกัดทรัพยากร และความแตกต่างของการ build หรือ bundling จัดอันดับตามความน่าจะเป็นโดยพิจารณาจากอาการ และให้คำสั่งวินิจฉัยสำหรับแต่ละข้อ

4. อธิบายทางแก้ก่อนที่ฉันจะนำไปใช้

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

การรีวิวโค้ด

5. รีวิวดิฟ

รีวิวดิฟนี้ในฐานะผู้รีวิวที่เข้มงวด เรียงหมวดหมู่ตามลำดับความสำคัญ คือ บั๊กด้านความถูกต้อง ปัญหาความปลอดภัย กรณีความล้มเหลวที่ไม่ได้จัดการ เงื่อนไขการแข่งขัน (race condition) แล้วจึงเป็นเรื่องสไตล์ สำหรับแต่ละข้อที่พบให้บอกระดับความรุนแรง บรรทัดที่เกี่ยวข้อง และเหตุผลว่าทำไมมันสำคัญในโค้ดเบสนี้ ไม่ใช่แค่ในทั่วไป อย่าแสดงความเห็นเรื่องการจัดรูปแบบ ถ้าดิฟนี้ไม่มีปัญหา ให้บอกตรงๆ แทนที่จะสร้างข้อค้นพบขึ้นมา แบบแผน: [describe]. ดิฟ: [paste].

6. การตรวจสอบด้านความปลอดภัย

รีวิวโค้ดนี้เฉพาะประเด็นความปลอดภัย ได้แก่ การฉีดคำสั่ง (injection) ช่องโหว่ด้านการยืนยันตัวตนและสิทธิ์การเข้าถึง การ deserialize ที่ไม่ปลอดภัย ข้อมูลลับในโค้ดหรือ log อินพุตที่ไม่ผ่านการตรวจสอบแล้วไปถึงจุดที่สำคัญ และความเสี่ยงจาก dependency สำหรับแต่ละข้อให้บอกเส้นทางการโจมตีที่ชัดเจน ไม่ใช่แค่เอ่ยชื่อหมวดหมู่ ระบุให้ชัดว่าอะไรที่คุณประเมินไม่ได้หากไม่เห็น [deployment, auth layer, data sensitivity]

7. การตรวจสอบผลกระทบที่อาจเกิดขึ้น

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

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

การรีแฟกเตอร์และสถาปัตยกรรม

8. แผนการรีแฟกเตอร์

เสนอแผนตามลำดับขั้นตอนสำหรับรีแฟกเตอร์ [description] เงื่อนไข: public API ของ [x] ห้ามเปลี่ยนแปลง เราดีพลอยแบบต่อเนื่องดังนั้นทุกขั้นตอนต้องพร้อมส่งได้อย่างอิสระ และเทสต์ต้องผ่านหลังจากทุกขั้นตอน สำหรับแต่ละขั้นตอนให้บอกการเปลี่ยนแปลง ความเสี่ยง วิธีตรวจสอบ และวิธีย้อนกลับ เรียงตามความเสี่ยงจากน้อยไปมาก อย่าเพิ่งเขียนโค้ด

9. โต้แย้งอีกฝั่ง

ฉันกำลังเลือก [approach A] แทน [approach B] สำหรับ [context and constraints] ให้เสนอเหตุผลที่หนักแน่นที่สุดสำหรับ B เงื่อนไขของเราต้องเป็นจริงแบบไหน B ถึงจะถูกต้อง และมีข้อไหนที่เป็นจริงในกรณีนี้บ้าง อย่าสรุปว่าทั้งสองแบบใช้ได้ทั้งคู่

10. ทำความเข้าใจสิ่งที่รับช่วงต่อมา

นี่คือไฟล์ซอร์สหลัก ให้สร้าง: จุดเริ่มต้นของโปรแกรม การไหลของข้อมูลจาก request ไปยัง response สถานะที่ใช้ร่วมกันและถูกเปลี่ยนแปลงที่ไหน dependency ภายนอกและจะเกิดอะไรขึ้นเมื่อแต่ละตัวใช้งานไม่ได้ และสามจุดที่มีแนวโน้มมีบั๊กมากที่สุดตามความซับซ้อนและการเชื่อมโยง ระบุให้ชัดเจนว่าอะไรที่คุณระบุไม่ได้จากสิ่งที่ฉันให้มา

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

การเขียนเทสต์

11. เทสต์ที่คุณคงไม่ได้เขียนเอง

เขียน test case สำหรับฟังก์ชันนี้ โดยเน้นอินพุตที่ฉันน่าจะยังไม่ได้พิจารณา ได้แก่ ค่าขอบเขต ค่าว่างและ null ยูนิโค้ด ค่าที่ใหญ่มาก การเรียกพร้อมกัน และสมมติฐานแฝงใดๆ ในการ implement สำหรับแต่ละเทสต์ให้ระบุสมมติฐานที่กำลังตรวจสอบ ฟังก์ชัน: [paste].

12. เทสต์ชุดเทสต์

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

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

รูปแบบการขอความเห็นที่สอง

นิสัยที่ให้ผลคุ้มค่าที่สุดในแพ็กนี้ทั้งหมด และเป็นข้อเดียวที่ต้องใช้โมเดลมากกว่าหนึ่งตัว

รับคำตอบจากโมเดลตัวหนึ่งก่อน จากนั้นสลับไปอีกตัวแล้วส่งต่อ:

วิศวกรอีกคนเสนอทางแก้นี้สำหรับปัญหานี้ ให้หาว่ามันมีจุดผิดพลาดตรงไหนบ้าง คือความถูกต้องในกรณีขอบเขต การทำงานพร้อมกัน การจัดการข้อผิดพลาด ประสิทธิภาพที่ [scale] หรือแนวทางที่ง่ายกว่าที่ถูกมองข้ามไป ถ้ามันดีจริงๆ ให้บอกตรงๆ แทนที่จะสร้างข้อโต้แย้งขึ้นมา ปัญหา: [paste]. ทางแก้ที่เสนอ: [paste].

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

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

สิ่งที่ต้องระวัง

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

ไม่มีสัญญาณบอกความมั่นใจ. ทางแก้ที่ถูกต้องกับทางแก้ที่ผิดแบบแนบเนียนมาพร้อมความมั่นใจเท่ากัน น้ำเสียงไม่ได้บอกอะไรคุณเลย

การขยายขอบเขตแบบเงียบๆ. นี่คือเหตุผลที่เงื่อนไขข้อสองมีอยู่

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

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