ตรวจโค้ดที่ AI แก้ก่อนยอมรับผลงาน

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

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

1. เขียนเงื่อนไขรับงานให้ชัดอีกครั้ง

ใช้ตัวอย่างสมมติ: แบบฟอร์มงานยอมรับชื่อที่มีแต่ช่องว่าง สิ่งที่ขอให้แก้คือปฏิเสธข้อมูลแบบนี้โดยยังส่งชื่อปกติได้ ก่อนดูแพตช์ ให้เขียนเงื่อนไขที่ต้องเป็นจริง:

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

วางรายการสั้น ๆ นี้ไว้ข้าง diff เพื่อใช้ประเมินการเปลี่ยนแปลง แทนการคล้อยตามคำอธิบายของเอเจนต์ หากคำขอเดิมกำกวม ให้ตกลงพฤติกรรมก่อนยอมรับการแก้ที่กว้างขึ้น

2. ยืนยันสถานะรีโพซิทอรี

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

ในเทอร์มินัลของโฮสต์ที่ต้องการ คำสั่งอ่านอย่างเดียวเหล่านี้ช่วยได้:

git status --short
git diff --stat
git diff -- path/to/file
git diff --cached -- path/to/file

เปลี่ยนพาธตัวอย่างเป็นพาธจริง git diff ปกติแสดงสิ่งที่ยังไม่ได้ stage ส่วน --cached แสดงสิ่งที่ stage แล้วเทียบกับ commit ต้องตรวจไฟล์ที่ Git ยังไม่ติดตามแยกต่างหาก เอกสาร Git diff อธิบายการเปรียบเทียบเหล่านี้ working tree ที่สะอาดไม่ได้บอกว่าเอเจนต์ทำ commit ไปแล้วหรือไม่ หากทำไปแล้ว ให้ดูประวัติที่เกี่ยวข้องด้วย

3. อ่านแพตช์และโค้ดรอบข้าง

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

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

ตรวจไฟล์ใหม่ โค้ดที่ลบ การเปลี่ยน dependency และการจัดรูปแบบที่ไม่เกี่ยวข้อง คำอธิบายสั้น ๆ ไม่ได้ให้เหตุผลเพียงพอกับ diff ขนาดใหญ่ที่ยังไม่อธิบาย หากข้อความถูกตัดหรือการเปลี่ยนแปลงกว้างจนอ่านไม่มั่นใจ ให้ย้ายไปตรวจบนโฮสต์หรือจอใหญ่

4. จับคู่การทดสอบกับพฤติกรรม

ขอคำสั่งที่รันจริง ผลลัพธ์ และรายการที่ข้ามไป “การทดสอบน่าจะผ่าน” เป็นการคาดการณ์ ไม่ใช่ผลที่บันทึกไว้ แม้ชุดทดสอบผ่าน ก็ต้องมีกรณีที่เกี่ยวข้องกับบั๊กที่แจ้ง

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

5. แก้ข้อพบโดยไม่สูญเสียงานอื่น

ให้ข้อเสนอแนะเฉพาะจุด เช่น “ชื่อที่มีแต่ช่องว่างถูกปฏิเสธ แต่ข้อความผิดพลาดไม่ปรากฏ” หรือ “อธิบายว่าทำไมการแก้ validation นี้จึงเปลี่ยนไฟล์ dependency” ระบุพฤติกรรมและไฟล์ ไม่ใช่บอกเพียงว่า “ลองใหม่”

หลีกเลี่ยง reset หรือ restore ทั้งหมดเพื่อเอาการเปลี่ยนแปลงเล็กน้อยออก เมื่อมีงานอื่นอยู่ด้วย ขอให้แก้ตรงจุดแล้วตรวจ diff ใหม่ หลังแก้ให้รันการตรวจที่ได้รับผลกระทบอีกครั้ง ผลผ่านครั้งก่อนไม่ยืนยันการแก้ครั้งหลัง

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

6. ทิ้งบันทึกส่งต่องานที่ตรวจสอบได้

บันทึกข้อสรุปสั้น ๆ:

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

ให้การทำ commit และการปล่อยใช้งานเป็นการตัดสินใจที่ชัดเจน หากต้องเก็บบทสนทนา ให้ส่งออกเป็น Markdown แต่เก็บไฟล์โปรเจกต์จริงไว้ด้วย บทสนทนาบันทึกการหารือ ส่วนรีโพซิทอรีและผลตรวจที่ยืนยันแล้วแสดงว่าอะไรเปลี่ยนจริง