เลือกงานแรกที่มีประโยชน์สำหรับ AI

เลือกงานที่ตรวจสอบได้

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

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

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

เปรียบเทียบงานที่อาจเลือก

พิจารณาคำขอสมมติสามแบบในแอปพลิเคชันรายงาน

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

สำหรับแบบฝึกหัดแรก ให้เลือก regression test ใช้วันที่ที่แต่งขึ้นและ branch ภายในเครื่อง ระบุว่าการเข้าถึง production การอัปเกรด dependency และ refactoring ที่ไม่เกี่ยวข้องอยู่นอกขอบเขต

เขียนเงื่อนไขงานเสร็จ

“ปรับปรุงการจัดการวันที่” เปิดให้ตีความมากเกินไป ใช้เงื่อนไขที่เจาะจงว่า “เมื่อ input มีวันที่ตามปฏิทินที่ไม่ถูกต้อง ให้ส่งกลับ validation error รักษา output ตามเอกสารสำหรับวันที่ที่ถูกต้อง”

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

แยกผลลัพธ์ของงานออกจากกิจกรรม “Agent เขียน test” อธิบายกิจกรรม “Test ไม่ผ่านเมื่อมีข้อบกพร่องที่ทราบ” อธิบายหลักฐาน Test ที่ผ่านทั้งโค้ดถูกและโค้ดผิดไม่ได้พิสูจน์ว่ามีการป้องกันตามที่ตั้งใจ

สังเกตกระบวนการทำงาน

ระหว่างฝึก ให้บันทึกจุดที่ agent ต้องการบริบทเพิ่ม ตรวจสอบว่าอ่านคำสั่ง repository ที่เกี่ยวข้องหรือไม่ สังเกตว่าเปลี่ยนไฟล์นอกขอบเขต หรือทำวิธีที่ไม่สำเร็จซ้ำโดยไม่มีหลักฐานใหม่หรือไม่

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

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

ขยายขอบเขตทีละด้าน

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

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

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