วิธีตรวจสอบโค้ดที่สร้างโดย AI

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

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

ปรับการตรวจตามความเสี่ยง

ไม่ใช่ทุกการเปลี่ยนแปลงต้องการความใส่ใจเท่ากัน

ขั้นตอนที่ 1: ดูว่าอะไรเปลี่ยนไป

ก่อนตัดสินโค้ด ให้ดูรายการการเปลี่ยนแปลง:

• หากโปรเจกต์อยู่ใน Git ให้ดู diff คือไฟล์และบรรทัดที่เปลี่ยนตั้งแต่ commit ล่าสุด ดูวิธีใช้ Git กับแอปที่สร้างด้วย AI
• หรือถาม AI โดยตรง:

แสดงรายการไฟล์ทุกไฟล์ที่คุณเปลี่ยนในการเปลี่ยนแปลงล่าสุด และอธิบายแต่ละไฟล์ในหนึ่งประโยคว่าเปลี่ยนอะไรและเพราะเหตุใด

สัญญาณเตือนในขั้นนี้: ไฟล์ที่ไม่เกี่ยวข้องกับคำขอ ไฟล์ที่ถูกลบ การเปลี่ยนการตั้งค่าหรือดีเพนเดนซีที่คุณไม่ได้ขอ

ขั้นตอนที่ 2: ทดสอบพฤติกรรมก่อน

การอ่านโค้ดบอกว่ามันตั้งใจจะทำอะไร การทดสอบบอกว่ามันทำอะไรจริง ก่อนอ่าน:

• ลองการเปลี่ยนแปลงในฐานะผู้ใช้ทั่วไป ทั้งบนเดสก์ท็อปและหน้าจอขนาดโทรศัพท์
• ลองกับอินพุตผิด ๆ เช่น ช่องว่าง ข้อความยาวมาก ตัวเลขติดลบ หรือวันที่ที่ผ่านมาแล้ว
• ลองตอนยังไม่ได้ล็อกอิน และลองในฐานะผู้ใช้อีกคน
• ทดสอบขั้นตอนที่สำคัญที่สุดซ้ำ: สมัครสมาชิก ล็อกอิน การกระทำหลัก การชำระเงิน

หากการทดสอบล้มเหลว คุณประหยัดเวลาอ่านไปได้ ให้รายงานอย่างชัดเจนแล้วให้ AI แก้ ดูวิธีเขียนรายงานบั๊กที่ดี

ขั้นตอนที่ 3: ตรวจสิทธิ์ที่เซิร์ฟเวอร์

สิ่งที่สำคัญที่สุดที่ต้องตรวจ เครื่องมือ AI มักซ่อนปุ่มไว้ในหน้า แต่ปล่อยให้เซิร์ฟเวอร์ยอมทำการกระทำนั้นให้ใครก็ได้ที่ขอ

สำหรับทุกเส้นทางหรือฟังก์ชันที่อ่านหรือเปลี่ยนข้อมูล ให้ถามว่า:

• ตรวจแล้วหรือว่าผู้ใช้ล็อกอินอยู่?
• ตรวจแล้วหรือว่าผู้ใช้นี้มีสิทธิ์เข้าถึงรายการ นี้ ได้?
• การตรวจนั้นอยู่ที่เซิร์ฟเวอร์ ไม่ใช่แค่ในหน้าเว็บ?

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

จากนั้นทดสอบ: ล็อกอินเป็นผู้ใช้ A จดรหัสของรายการหนึ่ง แล้วล็อกอินเป็นผู้ใช้ B และขอรายการนั้น รายการตรวจสอบความปลอดภัยสำหรับแอปที่สร้างด้วย AI มีการทดสอบฉบับเต็ม

ขั้นตอนที่ 4: ตรวจหาความลับที่รั่วไหล

• ค้นหาในไฟล์ที่เปลี่ยนสิ่งที่ดูเหมือนคีย์หรือรหัสผ่าน
• ตรวจว่าคีย์ลับถูกอ่านจากตัวแปรสภาพแวดล้อม และใช้เฉพาะในโค้ดฝั่งเซิร์ฟเวอร์
• ระวัง prefix สาธารณะ เช่น VITE_ หรือ NEXT_PUBLIC_ บนตัวแปรลับ เพราะสิ่งเหล่านี้ถูกฝังไว้ในโค้ดของเบราว์เซอร์

ดูวิธีเก็บคีย์ API ให้ปลอดภัย

ขั้นตอนที่ 5: ตรวจอินพุตและข้อผิดพลาด

• การตรวจสอบบนเซิร์ฟเวอร์ การตรวจในเบราว์เซอร์ข้ามได้ ฟิลด์ที่จำเป็น ความยาว รูปแบบ และค่าที่อนุญาตควรถูกตรวจโดยเซิร์ฟเวอร์ด้วย
• คำสั่งฐานข้อมูลใช้พารามิเตอร์ ไม่ใช่ข้อความที่นำอินพุตของผู้ใช้มาต่อกันเป็นคำสั่ง
• ข้อผิดพลาดไม่ถูกกลืนหาย บล็อก try/catch ที่ไม่ทำอะไรเลยจะซ่อนความล้มเหลว ข้อผิดพลาดควรถูกบันทึก และผู้ใช้ควรเห็นข้อความที่เข้าใจง่าย
• ไม่แสดงรายละเอียดภายในให้ผู้ใช้ สแต็กเทรซและข้อผิดพลาดของฐานข้อมูลควรอยู่ในล็อก

ขั้นตอนที่ 6: ตรวจว่ามีอยู่จริง

โมเดล AI บางครั้งสร้างโค้ดที่ดูถูกต้องแต่อ้างถึงสิ่งที่ไม่มีอยู่จริง

• แพ็กเกจ: ดีเพนเดนซีใหม่ทุกตัวควรเป็นแพ็กเกจจริงที่ยังดูแลอยู่ด้วยชื่อตรงนั้น ระวังชื่อที่ดูคล้ายพิมพ์ผิดของแพ็กเกจยอดนิยม
• ฟังก์ชันและตัวเลือก API: หากโค้ดเรียกฟังก์ชันของไลบรารีหรือตัวเลือกของ API ภายนอกที่คุณไม่เคยเห็น ให้ตรวจเอกสารทางการ
• โค้ดตัวอย่างที่ยังไม่สมบูรณ์: ค้นหา TODO mock fake ข้อมูลตัวอย่างที่ฝังไว้ในโค้ด หรือฟังก์ชันที่คืนค่าคงที่

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

ขั้นตอนที่ 7: ตรวจว่าเข้ากับระบบ

โค้ดอาจทำงานได้และยังทำให้แอปเปลี่ยนแปลงยากขึ้นในภายหลัง:

• การซ้ำซ้อน ลอจิกเดียวกันที่คัดลอกไปหลายที่จะแยกออกจากกันไปเรื่อย ๆ
• ความสอดคล้อง ควรทำตามรูปแบบที่ส่วนอื่นของแอปใช้
• ขนาด คำขอ 20 บรรทัดที่ได้โค้ด 600 บรรทัดควรถูกตั้งคำถาม
• โค้ดที่ไม่ได้ใช้ เวอร์ชันเก่าที่หลงเหลืออยู่ข้างเวอร์ชันใหม่

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

ความผิดพลาดที่พบบ่อย

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

รายการตรวจสอบ

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

การรีวิวโค้ดบน Mythex

• โหมดถาม (Ask) ตอบคำถามเกี่ยวกับโค้ดโดยไม่แก้ไข เหมาะกับคำขอ “อธิบายทุกการเปลี่ยนแปลง” และ “เส้นทางใดขาดการตรวจสอบสิทธิ์” ดูแชท
• มุมมองโค้ด (Code view) แสดงแผนผังไฟล์ ตัวแก้ไข และเทอร์มินัลในทุกแพ็กเกจ (อ่านอย่างเดียวบน Free แก้ไขได้บน Pro) เพื่อให้คุณอ่านสิ่งที่เปลี่ยนไปด้วยตัวเอง ดูตัวแก้ไขโค้ด
• /test ให้เอเจนต์คลิกผ่านพรีวิวในฐานะผู้ใช้และรายงานขั้นตอนที่พัง
• เช็คพอยต์ (Checkpoints) ช่วยให้คุณย้อนการเปลี่ยนแปลงที่ไม่ผ่านการรีวิวได้

หากมีนักพัฒนาช่วยรีวิวให้ วิธีทำงานกับนักพัฒนาในแอปที่สร้างด้วย AI อธิบายการส่งต่องาน และหากการรีวิวพบบั๊ก ดูวิธีดีบักแอปที่สร้างด้วย AI

คำถาม