พรอมต์รีวิวโค้ดระดับซีเนียร์ จับบั๊กจริง
การรีวิวโค้ดจาก LLM ส่วนใหญ่จะถมคุณด้วยข้อตำหนิเรื่องสไตล์และพลาดบั๊กจริง พรอมต์นี้บังคับให้โมเดลคัดกรองตามความรุนแรง รายงานเฉพาะสิ่งที่จะรอดในการรีวิวจาก tech lead ที่เข้มงวด และอ้างเลขบรรทัดที่แม่นยำเพื่อให้คุณตรวจสอบได้รวดเร็ว
คุณเป็นวิศวกร staff ระดับซีเนียร์ที่กำลังรีวิว diff ด้านล่าง เป้าหมายคือจับสิ่งที่จะรอดในการรีวิวจาก tech lead ที่เข้มงวด ไม่ใช่เสียงรบกวนของ lint กฎการรีวิว 1. คัดกรองทุกผลการตรวจพบเป็น BLOCKER, MAJOR, MINOR หรือ NIT 2. แสดงเฉพาะ BLOCKER และ MAJOR เป็นค่าเริ่มต้น ระงับ MINOR และ NIT เว้นแต่ฉันจะขออย่างชัดเจน 3. สำหรับแต่ละผลการตรวจพบ อ้างเส้นทางไฟล์ที่แม่นยำ + ช่วงเลขบรรทัด แล้วอธิบาย (a) สิ่งที่ผิด (b) โหมดความล้มเหลวใน production (c) วิธีแก้ที่แนะนำ 4. หากความมั่นใจว่าปัญหาเป็นจริงน้อยกว่า 80% ทำเครื่องหมายผลการตรวจพบ [low-confidence] และอธิบายว่าบริบทเพิ่มเติมใดที่จะช่วยให้ยืนยันได้ 5. จบด้วยสรุปภาพรวมหนึ่งย่อหน้า ship-it / ship-with-followups / do-not-ship ห้ามแสดงความคิดเห็นเกี่ยวกับ - ความชอบในการตั้งชื่อ เว้นแต่จะทำให้เข้าใจผิดอย่างชัดเจน - รูปแบบ/ช่องว่างหากใช้ formatter อยู่ - การปรับให้เหมาะสมเชิงสมมติฐานที่เชื่อมโยงกับ hot path ที่วัดได้ไม่ได้ - รูปแบบที่ codebase ใช้อยู่แล้วในที่อื่น (เป็นความสอดคล้องของสไตล์ ไม่ใช่บั๊ก) Diff สำหรับการรีวิว [วาง unified diff หรือเนื้อหาไฟล์ที่นี่]
เมื่อไหร่ควรใช้
- ก่อน merge PR ที่ไม่ใช่เรื่องเล็ก รัน diff ผ่านพรอมต์นี้เพื่อพบสิ่งที่อยากให้คนอื่นช่วยดู
- Self-review งานของตัวเอง มีประโยชน์ก่อนขอรีวิวจากคน จับสิ่งน่าอายได้
- Onboarding กับ codebase ที่ไม่คุ้นเคย วางฟังก์ชันพร้อมพรอมต์เพื่อเข้าใจความเสี่ยงก่อนเปลี่ยนแปลง
เคล็ดลับตามโมเดล
- claude
- Claude (Sonnet 4.6 หรือ Opus 4.7) มักให้การคัดกรองที่ละเอียดที่สุด วาง diff ใน code block บริบทยาวรองรับการรีวิวทั้ง PR ได้ดี
- chatgpt
- GPT-5 / GPT-4o มักจะติดธงเรื่องสไตล์อย่างก้าวร้าว กฎ 'ระงับ MINOR และ NIT' ด้านบนช่วยให้อยู่ในแนวทาง
- cursor
- ใน Cursor บันทึกเป็นรายการ .cursorrules หรือวางใน composer ใช้ได้ดีกับการอ้างอิง @file
ตัวอย่างผลลัพธ์
BLOCKER: src/auth/session.ts:42-58 - what: การเปรียบเทียบ session token ใช้ === ไม่ใช่ constant-time compare - failure mode: เสี่ยงต่อ timing attack ในการ login ระยะไกล - fix: เปลี่ยนเป็น crypto.timingSafeEqual() กับคู่ buffer MAJOR: src/auth/session.ts:73 [low-confidence] - what: Refresh token ถูกเขียนลง localStorage - failure mode: เสี่ยงต่อการ exfiltrate ผ่าน XSS หากเนื้อหาผู้ใช้ที่ไม่ sanitized มาถึงหน้า - fix: ย้ายไป httpOnly cookie หาก client ไม่ต้องอ่าน token นี้ (low-confidence: ไม่เห็นว่า front-end ใช้ token นี้อย่างไร) Summary: ship-with-followups การแก้ constant-time ต้องทำก่อน merge ตำแหน่งเก็บเป็น follow-up ที่ควรเปิด issue ไม่ว่า PR นี้จะเป็นอย่างไร
วิธีการทำงาน
ทำไมการรีวิวโค้ดจาก AI ส่วนใหญ่จึงไม่มีประโยชน์
เป็นค่าเริ่มต้น language models มักจะตั้งเป็น 'helpful junior' กับงานรีวิวโค้ด หมายความว่าจะคอมเมนต์เรื่องการตั้งชื่อมากเกินไป แนะนำให้เขียน 'clean code' ใหม่สำหรับโค้ดที่ใช้ได้แล้ว และฝังบั๊กจริงเดียวในกองข้อเสนอแนะที่คุณต้องเพิกเฉย อัตราส่วนสัญญาณต่อเสียงรบกวนทำลาย workflow ทีมส่วนใหญ่เลิกใช้ AI รีวิวภายในสัปดาห์
พรอมต์ด้านบนพลิกสามสิ่ง ขอการคัดกรองความรุนแรงเพื่อให้ปัญหาเล็กถูกระงับอย่างชัดเจน ต้องการเลขบรรทัดเพื่อให้แต่ละผลการตรวจพบยืนยันได้ในไม่กี่วินาที และบังคับธงความมั่นใจเพื่อให้รู้ว่าควรเชื่อผลการตรวจพบไหนโดยไม่ต้องอ่านไฟล์ทั้งหมด
การจับคู่กับ CI
รันพรอมต์นี้เป็นขั้น 'second opinion' ใน workflow PR ไม่ใช่การตรวจสอบที่บังคับ โมเดลยังคง hallucinate โดยเฉพาะกับ invariant ข้ามไฟล์และโค้ดที่ขึ้นกับ convention ของเฟรมเวิร์กที่คุณไม่ได้วาง ใช้ output เป็นรายการสิ่งที่ต้องตรวจสอบ ไม่ใช่รายการปัญหาที่ต้องแก้ตามอัตโนมัติ
หากต้องการใน CI ให้ output ผลการตรวจพบเป็น JSON (แก้พรอมต์: 'คืนค่า JSON array ที่มี field severity, path, lineStart, lineEnd, what, fix, confidence') แล้วโพสต์ BLOCKER/MAJOR ไปยัง PR เป็นคอมเมนต์เดียวที่มีหัวข้อชัดเจนว่า 'AI assist verify ก่อนทำ'
ปรับพรอมต์สำหรับทีม
เพิ่มส่วน 'Codebase context' เหนือ diff วาง 5-10 บรรทัดอธิบาย stack convention การทดสอบ และ invariant ที่ไม่ชัดเจน (เช่น 'การเขียน DB ทั้งหมดผ่าน src/db/withTx ไม่ใช่ raw client') โมเดลพลาด convention เฉพาะของ codebase หากไม่บอก
หากทีมมีจุดอ่อนที่ทราบ (race conditions ใน job runner, N+1 queries ในบริการเฉพาะ) เพิ่มบรรทัด 'Watch especially for: ...' โมเดลจะให้น้ำหนักกับบั๊กประเภทนั้นมากขึ้นและมีแนวโน้มที่จะติดธงเมื่อมี
คำถามที่พบบ่อย
›ใช้กับโค้ด closed-source ได้ไหม?
ได้ แต่ตรวจสอบนโยบายของนายจ้างก่อน พรอมต์เองไม่อันตราย สิ่งสำคัญคือคุณได้รับอนุญาตให้วางโค้ดในโมเดลที่ใช้หรือไม่ Claude และ ChatGPT แผน enterprise มักไม่ train จาก input ของคุณ แผน consumer อาจ
›ทำไมระงับผลการตรวจพบ MINOR และ NIT?
เพราะในทางปฏิบัติสร้างความเหนื่อยล้าในการรีวิว หลังจากโน้ต 'ลองแยกเป็นฟังก์ชัน' ครั้งที่สาม คุณหยุดอ่าน การระงับช่วยให้สัญญาณ BLOCKER/MAJOR คม เปิดกลับด้วย 'แสดงผลทั้งหมดรวม MINOR และ NIT' เมื่อต้องการรีวิวเชิงลึก
›diff ได้ยาวเท่าไหร่?
Claude Sonnet/Opus และ GPT-5 รองรับ 50K+ tokens ของ diff ได้สบาย สำหรับ PR ที่ใหญ่มาก ให้แยกการรีวิวตามไดเรกทอรี (รีวิว src/auth ก่อน แล้ว src/billing) เพื่อให้โมเดลคิดเกี่ยวกับแต่ละ subsystem แยกกัน
›การรีวิวด้านความปลอดภัยเฉพาะล่ะ?
พรอมต์นี้จับปัญหา crypto/storage/SSRF ที่ชัดเจน แต่ไม่ใช่การทดแทนการรีวิวความปลอดภัยของโค้ด auth หรือ payment สำหรับ path เหล่านั้น รันพรอมต์นี้และพรอมต์รีวิวความปลอดภัยเฉพาะ (เราจะเผยแพร่แยก)
›รีวิวข้ามหลายไฟล์ได้ไหม?
ได้ วาง diff ที่รวมไฟล์ทั้งหมด รองรับ invariant ข้ามไฟล์ได้พอประมาณในการวางครั้งเดียว สำหรับปัญหาที่กระจายข้าม PR หลายอัน (เช่น 'สอดคล้องกับวิธี gate feature flag ในที่อื่นไหม?') รวมตัวอย่างจากไฟล์อื่นๆ
›ควรเชื่อผลการตรวจพบ [low-confidence] ไหม?
ปฏิบัติเป็น 'ตรวจสอบก่อนทำ' ประมาณครึ่งหนึ่งของผลการตรวจพบ low-confidence เป็นจริงแต่โมเดลยืนยันไม่ได้ อีกครึ่งเป็นการอ่านผิด ธงเป็นสัญญาณซื่อสัตย์ ไม่ใช่เหตุผลที่จะเพิกเฉย
›ทำไมต้องให้ระบุ failure mode?
เพราะ 'นี่ผิด' ไม่มีประโยชน์โดยไม่มี 'นี่จะ crash เมื่อ input เป็น unicode' บรรทัด failure mode บอกลำดับความสำคัญ การแก้ที่ป้องกันกรณีขอบ 1 ใน 1 ล้านต่างจากการป้องกัน prod incident รายวัน
›ใช้กับ Cursor โดยเฉพาะอย่างไร?
บันทึกเนื้อหาพรอมต์เป็น .cursorrules ที่ root ของ repo หรือวางใน composer พร้อมการอ้างอิง @file ของไฟล์ที่กำลังรีวิว Cursor จะให้กฎทำงานสำหรับโปรเจ็กต์นั้น
เครื่องคำนวณที่เกี่ยวข้อง
พรอมต์ที่เกี่ยวข้อง
อัปเดตล่าสุด: