วิธีใช้ AI เขียนโค้ด เวิร์กโฟลว์ที่ลดความเสี่ยง

กฎสำหรับให้ AI ช่วยเขียนโค้ดอย่างปลอดภัย

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

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

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

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

เวิร์กโฟลว์ไล่บั๊ก

เวิร์กโฟลว์ไล่บั๊กด้วย AI ที่เชื่อถือได้มีห้าขั้น คือทำซ้ำอาการ แยกจุด ตั้งสมมติฐาน แพตช์ และตรวจสอบ อย่าเริ่มด้วยคำว่า "แก้ให้ที" ให้เริ่มด้วยหลักฐาน ป้อนคำสั่งที่ล้มเหลว ข้อความ error ที่แน่นอน พฤติกรรมที่คาดหวัง พฤติกรรมที่เห็นจริง โค้ดที่เกี่ยวข้อง รายละเอียดสภาพแวดล้อม และการเปลี่ยนแปลงล่าสุดที่อาจเป็นต้นเหตุ ให้โมเดลไปด้วย

ขั้นที่ 1: เก็บวิธีทำซ้ำอาการ สำหรับโค้ดฝั่งหลังบ้าน ให้ใส่ request, response, status code, ล็อก และเทสต์ที่ล้มเหลว สำหรับโค้ดฝั่งหน้าบ้าน ให้ใส่เส้นทาง การกระทำของผู้ใช้ error ในคอนโซลเบราว์เซอร์ response จากเครือข่าย สถานะของคอมโพเนนต์ และคำบรรยายภาพหน้าจอถ้าเกี่ยวข้อง สำหรับปัญหาตอนบิลด์ ให้ใส่คำสั่ง แพ็กเกจแมเนเจอร์ เวอร์ชัน Node และ error เต็ม ๆ รอบจุดที่ล้มเหลวครั้งแรก

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

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

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

พรอมต์ไล่บั๊ก:

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

พรอมต์แก้บั๊ก:

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

เวิร์กโฟลว์รีวิวโค้ด

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

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

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

พรอมต์รีวิวโค้ด:

รีวิว diff นี้แบบผู้ดูแลโปรเจกต์ที่เข้มแต่ใช้ได้จริง เน้นความถูกต้อง ความเสี่ยงงานพัง ความปลอดภัย เคสขอบ และเทสต์ที่ขาดไป ข้ามเรื่องสไตล์เล็ก ๆ เว้นแต่มันสร้างความเสี่ยงในการดูแลรักษาจริง ส่งกลับมาเป็นตารางที่มีปัญหา ระดับความสำคัญ หลักฐานจาก diff วิธีแก้ที่เสนอ และเทสต์ที่ต้องมี พฤติกรรมที่ตั้งใจไว้: [วาง] diff: [วาง] เทสต์ที่มีอยู่: [วาง]

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

เวิร์กโฟลว์รีแฟกเตอร์และเทสต์

การรีแฟกเตอร์ด้วย AI มีความเสี่ยง เพราะการรีแฟกเตอร์จำนวนมากถูกตัดสินจากสิ่งที่ไม่ควรเปลี่ยน โมเดลอาจทำให้โค้ดสวยขึ้นแต่แอบเปลี่ยนพฤติกรรม การจัดการข้อผิดพลาด จังหวะเวลา หรือสัญญาที่เปิดเผยต่อภายนอก เวิร์กโฟลว์รีแฟกเตอร์ที่ปลอดภัยกว่าเริ่มจากการนิยาม invariant ก่อนจะแตะตัวการทำงาน

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

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

ขั้นที่ 3: เขียน characterization test ก่อนเปลี่ยนโค้ด ให้สั่ง AI ระบุพฤติกรรมปัจจุบันและร่างเทสต์ที่ล็อกเคสสำคัญไว้ เทสต์พวกนี้มีประโยชน์มากเป็นพิเศษกับโค้ดเก่าที่ไม่ชัดว่าตั้งใจให้ทำอะไร ควรครอบคลุมอินพุตปกติ อินพุตที่ขอบ เส้นทางที่ล้มเหลว และเคสถดถอยหนึ่งเคสที่ผูกกับเหตุผลของการรีแฟกเตอร์

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

พรอมต์วางแผนรีแฟกเตอร์:

สร้างแผนรีแฟกเตอร์แบบแบ่งเป็นระยะ เป้าหมาย: [เป้าหมาย] โค้ดปัจจุบัน: [วาง] ข้อจำกัด: รักษาพฤติกรรมที่เปิดเผยต่อภายนอก ลดการเปลี่ยนแปลงที่ไม่จำเป็น ตามแบบแผนเดิม ไม่เพิ่ม dependency ใหม่ และทุกระยะต้องเทสต์ได้ ส่งกลับมาเป็น: invariant แผนที่ dependency ระยะต่าง ๆ ไฟล์ที่แตะ เทสต์ของแต่ละระยะ ความเสี่ยงตอนย้อนกลับ และเช็กลิสต์สำหรับรีวิว

พรอมต์ยูนิตเทสต์:

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

เทมเพลตพรอมต์

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

พรอมต์อธิบายโค้ด:

อธิบายโค้ดนี้ให้นักพัฒนาที่เพิ่งเข้าร่วมโปรเจกต์ฟัง ครอบคลุมจุดประสงค์ อินพุต เอาต์พุต การไหลของข้อมูล dependency รูปแบบความล้มเหลว และเทสต์ที่จะช่วยเพิ่มความมั่นใจ แยกข้อเท็จจริงที่เห็นได้จากโค้ดออกจากสิ่งที่เป็นการสันนิษฐาน โค้ด: [วาง]

พรอมต์เขียนโค้ดอย่างปลอดภัย:

รีวิวโค้ดนี้หาความเสี่ยงด้านความปลอดภัย เน้นการยืนยันตัวตน สิทธิ์การเข้าถึง การฉีดโค้ด ความลับ การตรวจสอบข้อมูล การเปลี่ยนเส้นทางที่ไม่ปลอดภัย การจัดการไฟล์ ความเสี่ยงจาก dependency และการเปิดเผยข้อมูลอ่อนไหว ส่งกลับมาเฉพาะปัญหาที่มีหลักฐาน ผลกระทบ วิธีแก้ที่เสนอ และเทสต์หรือการตรวจด้วยมือ โค้ดหรือ diff: [วาง]

พรอมต์เทียบวิธีแก้จากหลายโมเดล:

ฉันกำลังเปรียบเทียบโมเดล AI สำหรับงานเขียนโค้ด ใช้เฉพาะบริบทที่ให้ไปเท่านั้น ส่งกลับมาเป็นสาเหตุที่แท้จริง วิธีแก้ที่เล็กและปลอดภัยที่สุด เทสต์ ความเสี่ยง ข้อสันนิษฐาน และคำถามที่ยังค้างอยู่ ให้คะแนนความมั่นใจ 1 ถึง 5 และระบุว่าหลักฐานแบบไหนจะทำให้คุณเปลี่ยนคำตอบ งาน: [วาง] บริบท: [วาง]

เช็กลิสต์ QA ก่อนคุณจะรับโค้ดที่ AI สร้าง:

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

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