ตั้งค่าการเขียนโปรแกรมเป็นคู่อย่างมีเหตุผล ด้วยกฎส่วนตัวที่ชัดเจนและเขตห้ามเข้า เพื่อไม่ให้การช่วยเหลือกลายเป็นการพึ่งพา
เปิดบทเรียนนี้ใน Kodokonความเสี่ยงเชิงวิชาชีพของการพึ่งพาความช่วยเหลือถาวรมีชื่อในสาขาปัจจัยมนุษย์: ความชะล่าใจต่อระบบอัตโนมัติ นักบินสายการบินรู้ดี - ยิ่งระบบอัตโนมัติเชื่อถือได้มากเท่าไร มนุษย์ก็ยิ่งตรวจสอบน้อยลง และทักษะการทำด้วยมือของพวกเขาก็ยิ่งเสื่อมลงอย่างเงียบๆ สำหรับนักพัฒนา อาการนั้นชัดเจน: คุณยอมรับข้อเสนอแนะที่ยาวขึ้นเรื่อยๆ ตรวจทานน้อยลงเรื่อยๆ และในวันที่ AI ไม่พร้อมใช้งานหรือผิดพลาดในบางจุดที่ละเอียดอ่อน คุณจะพบว่าคุณไม่รู้วิธีทำมันด้วยตัวเองอีกต่อไป มาตรการรับมือไม่ใช่การงดเว้น: มันคือ สัญญาการใช้งานที่ชัดเจน ที่เขียนไว้ขาวดำ ที่คุณบังคับใช้กับตัวเอง
กฎหลักของสัญญานี้สรุปได้ในไม่กี่คำ: ฉันพิมพ์ มันตรวจทาน คุณเขียนโค้ดเองในร่างแรกโดยไม่มีตัวช่วย AI จะเข้ามาหลังจากนั้นเท่านั้น ในฐานะผู้ตรวจทาน การกลับด้านนี้เปลี่ยนทุกอย่าง: ความพยายามในการผลิต - สิ่งที่สร้างและรักษาทักษะ - ยังอยู่กับคุณ และ AI มีส่วนช่วยในสิ่งที่มันทำได้ดีที่สุด นั่นคือการมองงานของคุณอย่างละเอียดถี่ถ้วนไม่รู้จักเหน็ดเหนื่อย มันตรงกันข้ามกับปฏิกิริยาตอบสนองที่ครอบงำอยู่ (ให้มันสร้าง แล้วตรวจทานอย่างคร่าวๆ) ซึ่งกลับด้านภาระทางการรู้คิด: โมเดลผลิต และคุณรับบทที่ยากที่สุด นั่นคือการตัดสินโค้ดที่คุณไม่ได้คิดผ่านมัน
คุณคือผู้ตรวจทานโค้ดระดับอาวุโส เข้มงวดแต่สนับสนุน ฉันเพิ่งเขียนโค้ดนี้ด้วยตัวเอง และฉันต้องการการตรวจทานที่ช่วยให้ฉันพัฒนาขึ้น ไม่ใช่การเขียนใหม่
บริบท: [ภาษา ข้อจำกัดของโปรเจกต์ สิ่งที่โค้ดควรจะทำ]
[วางโค้ดของคุณ]
กฎการตรวจทาน:
1. ห้ามเขียนโค้ดใหม่ทั้งหมดเด็ดขาด แม้แต่ฟังก์ชันสมบูรณ์เพียงหนึ่งฟังก์ชัน
2. จำแนกแต่ละข้อสังเกต: น่าจะเป็นบั๊ก / ความเสี่ยงในการใช้งานจริง / ความอ่านง่าย / สไตล์
3. สำหรับแต่ละบั๊กที่น่าจะเป็น จงอธิบายสถานการณ์อินพุตที่แน่ชัดซึ่งกระตุ้นมัน โดยไม่ให้วิธีแก้ - ฉันอยากหามันเอง
4. จบด้วยการถามฉันเกี่ยวกับการตัดสินใจด้านการออกแบบที่ฉันทำ ซึ่งดูน่าสงสัยในสายตาคุณ
รูปแบบ: รายการมีหมายเลข ข้อสังเกตที่ร้ายแรงที่สุดก่อน มากที่สุด 8 ข้อสังเกตข้อที่สองของสัญญา: เขตห้ามเข้า จงกำหนดล่วงหน้าถึงส่วนต่างๆ ของโปรเจกต์ที่ AI ไม่เคยเขียนแม้แต่บรรทัดเดียว ไม่ว่าในสถานการณ์ใด สามหมวดหมู่มีความสำคัญ อย่างแรก โค้ดที่สำคัญต่อความปลอดภัย - การพิสูจน์ตัวตน การจัดการเซสชัน การเข้ารหัส การย้ายข้อมูล - ที่ซึ่งคำตอบที่ดูสมเหตุสมผลแต่ผิดนั้นมีราคาแพงเกินไป ต่อมา แกนกลางธุรกิจ ตรรกะที่ทำให้ผลิตภัณฑ์ของคุณมีคุณค่า: นั่นคือสิ่งที่คุณต้องรู้อย่างลึกซึ้ง สุดท้าย และนี่คือสิ่งที่ไม่ค่อยเป็นสัญชาตญาณที่สุด การสัมผัสครั้งแรกกับแนวคิดใหม่ใดๆ: หากคุณให้ AI เขียน Mutex ตัวแรกของคุณ saga ตัวแรก หรือ worker ตัวแรกของคุณ คุณจะไม่มีวันเรียนรู้มันอย่างแท้จริง ในเขตเหล่านี้ AI ยังมีบทบาท: การอธิบาย การตั้งคำถาม การตรวจทาน แต่ไม่มีวันผลิต
คุณคือคู่หูเขียนโปรแกรมเป็นคู่ของฉันในโหมดผู้นำทาง: คุณนำทาง ฉันขับ ฉันติดอยู่กับปัญหานี้:
[อธิบายปัญหา + วางข้อความแสดงข้อผิดพลาดหรือสนิปเป็ตที่เกี่ยวข้อง]
กฎเด็ดขาด:
1. ห้ามให้โค้ดที่ยาวเกินหนึ่งบรรทัดแก่ฉัน
2. ดำเนินการด้วยคำถามแบบโสกราตีส: ช่วยฉันตั้งสมมติฐาน แล้วออกแบบการทดสอบที่ยืนยันมัน
3. หากฉันมุ่งไปในทิศทางที่ผิด จงบอกฉันอย่างชัดเจนและอธิบายว่าทำไม แต่ปล่อยให้ฉันหาทิศทางที่ถูกต้องเอง
4. เมื่อฉันพบมันแล้ว จงขอให้ฉันระบุสาเหตุรากเหง้าใหม่ในสองประโยค และแก้ไขถ้อยคำของฉันหากมันไม่แม่นยำ
เริ่มด้วยการถามฉันว่าฉันได้ลองอะไรไปแล้วบ้าง และฉันสรุปอะไรได้จากมันข้อสุดท้าย: การวัดผล สัญญาที่ไม่มีตัวชี้วัดจะไม่รอดพ้นหกสัปดาห์ ตัวชี้วัดที่ถูกต้องไม่ใช่ปริมาณของพรอมต์ แต่คือ หนี้ความเข้าใจ ของคุณ: จำนวนบล็อกโค้ดที่คอมมิตเข้าไปในรีโปในสัปดาห์นี้ ซึ่งคุณไม่สามารถเขียนใหม่จากความทรงจำหรืออธิบายอย่างละเอียดได้ จงนับจำนวนนี้อย่างซื่อสัตย์ทุกวันศุกร์ หากมันเพิ่มขึ้นสองสัปดาห์ติดต่อกัน จงกระชับสัญญาให้แน่นขึ้น: ขยายเขตห้ามเข้า กลับไปสู่ "ฉันพิมพ์ มันตรวจทาน" อย่างเคร่งครัด บททดสอบสูงสุดยังคงเหมือนกับในการบิน: ปิดระบบอัตโนมัติหนึ่งวันต่อสัปดาห์ และสังเกตว่าคุณยังทำอะไรได้บ้าง