การเขียนสคริปต์และการเติมข้อความอัตโนมัติ

กำไร:

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

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

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

โหมดการใช้งานสองโหมด: เสร็จสิ้นอินไลน์และการแชท

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

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

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

ขั้นตอนในการแปลความตั้งใจให้เป็นโค้ด

1. กำหนดสัญญา. พฤติกรรมอินพุต เอาท์พุต และข้อผิดพลาดของฟังก์ชันคืออะไร เช่น "รับอีเมล ทำให้เป็นมาตรฐานหากถูกต้อง ส่งข้อผิดพลาดหากไม่ถูกต้อง"
2. ระบุข้อจำกัด อย่าใช้การพึ่งพาภายนอกใช่ไหม คู่มือสไตล์ที่เฉพาะเจาะจง? มีการจำกัดประสิทธิภาพหรือไม่?
3. ยกตัวอย่าง. คู่อินพุต-เอาต์พุต (“ali@x.com → valid, ali@ → error”) ย้ายความเข้าใจของโมเดลเกี่ยวกับเจตนาจากการทำนายไปสู่ความแม่นยำ
4. ขอชิ้นเล็กๆ. หนึ่งหน้าที่ หนึ่งความรับผิดชอบ จากนั้นไปยังอันถัดไป
5. อ่านและรันโค้ดที่สร้างขึ้น การคอมไพล์ + การลองด้วยตนเองอย่างรวดเร็วเป็นขั้นตอนการรับประกันที่ถูกที่สุด

มินิเคสสามอัน

กรณีที่ 1 — การผลิตที่ขับเคลื่อนด้วยความคิดเห็นช่วยเพิ่มความแม่นยำ ขั้นแรกนักพัฒนาขอฟังก์ชันแยกวิเคราะห์วันที่ด้วยเนื้อหาว่างและได้ผลลัพธ์ที่ถูกต้องใน 3 รอบ ในความพยายามครั้งที่สอง เมื่อฉันกำหนดฟังก์ชันด้วยความคิดเห็น 4 บรรทัด (รูปแบบที่ยอมรับ กฎเขตเวลา เงื่อนไขข้อผิดพลาด) และร้องขอ รหัสที่ทำงานในรอบแรกก็มาถึง รุ่นเดียวกันในวันเดียวกัน ความแตกต่างเป็นเพียงความชัดเจนของเจตนาเท่านั้น

กรณีที่ 2 — การไม่ระบุเวอร์ชันมีราคาแพง ทีมหนึ่งประสบปัญหากับ API ที่ใช้การเรียกกลับแบบเดิมแทนที่ fs.promises ในโค้ดที่สร้างขึ้นสำหรับ Node.js เมื่อมีการเพิ่มบรรทัด "ใช้โหนด 20, ESM, async/await" ลงในพรอมต์ การผลิตจะติดตามโปรเจ็กต์ในครั้งแรก รีเซ็ตเวลาเฉลี่ย 12 นาทีที่ใช้ในการแก้ไขแล้ว

กรณีที่ 3 — กำไรจริงจากโค้ดสำเร็จรูป ไมโครเซอร์วิสจำเป็นต้องมี DTO ใหม่ 6 ตัว (Data Transfer Object — คลาสข้อมูลอย่างง่ายที่นำข้อมูลระหว่างเลเยอร์) และกฎการตรวจสอบ สิ่งที่เคยเป็นงานแบบแมนนวลประมาณ 90 นาทีก็ลดลงเหลือ 35 นาทีเมื่อ AI ผลิตและตรวจสอบ เนื่องจากการทำซ้ำโค้ดสูงและรูปแบบมีความชัดเจน AI จึงทำงานในพื้นที่ที่มีประสิทธิภาพสูงสุดที่นี่

เทมเพลตที่คัดลอกได้สี่แบบ

การสร้างฟังก์ชันตามสัญญา:

บทบาท: คุณเป็นนักพัฒนา {{ภาษา}} ที่ขยันขันแข็ง สัญญาด้านฟังก์ชัน:- ชื่อ: {{name}}- อินพุต: {{ประเภทและความหมาย}}- เอาต์พุต: {{ประเภทและความหมาย}}- สถานะข้อผิดพลาด: {{สิ่งที่ถูกโยน/ส่งคืนเมื่อ}}ข้อจำกัด: {{ไม่มีการพึ่งพาภายนอก / สไตล์ / ประสิทธิภาพ}}ตัวอย่าง:- {{input_1}} -> {{output_1}}- {{entry_2}} -> {{error_2}}ให้ลายเซ็น + แผนสั้นๆ ก่อน จากนั้นจึงเขียนโค้ด ข้อสอบการเขียน แค่ฟังค์ชั่น

เพื่อให้เข้ากับสไตล์ที่มีอยู่ (ปรับให้เข้ากับฐานโค้ด):

ด้านล่างนี้เป็นตัวอย่างฟังก์ชันจากโครงการของเรา เรียนรู้การตั้งชื่อ การจัดการข้อผิดพลาด และรูปแบบการแสดงความคิดเห็นที่นี่ เขียนฟังก์ชันสำหรับ {{new_task}} ด้วยสไตล์ SAME ตัวอย่าง: {{current_code}}

จากโครงกระดูกสู่การเติม (stub → การใช้งาน):

กรอกโครงกระดูกฟังก์ชันด้านล่างตามสิ่งที่ต้องทำในความคิดเห็น เปลี่ยนลายเซ็นและประเภทการส่งคืน อย่าสร้างฟังก์ชันตัวช่วยที่ไม่มีอยู่ หากจำเป็น โปรดแจ้งให้เราทราบว่า "จำเป็นต้องมีตัวช่วยนี้" {{โครงกระดูก_kod}}

การเปรียบเทียบแอปทางเลือก:

มอบการใช้งานที่แตกต่างกัน 2 แบบสำหรับ {{task}}: (a) จัดลำดับความสำคัญของความสามารถในการอ่าน (b) จัดลำดับความสำคัญประสิทธิภาพ เขียน 1 ประโยค "เมื่อใดดีกว่า" ไว้ข้างใต้แต่ละประโยค

พรอมต์อ่อน / พรอมต์แข็งแกร่ง

อ่อนแอ: "เขียนฟังก์ชันยืนยันอีเมลให้ฉัน"

แข็งแกร่ง: "TypeScript 5, ไลบรารีมาตรฐานเท่านั้น เขียน isValidEmail(input: string): boolean ตัดแต่งช่องว่าง ทำให้ไม่คำนึงถึงขนาดตัวพิมพ์ a@b.co ถูกต้อง a@, @b.co สตริงว่างไม่ถูกต้อง หากคุณกำลังจะใช้ regex อย่าซับซ้อนจนเกินไป เพิ่มความคิดเห็น 2 บรรทัด"

รุ่นทรงพลัง; ส่งคืนภาษา เวอร์ชัน ลายเซ็น Edge case และข้อจำกัดของสไตล์ ดังนั้นโค้ดที่สร้างขึ้นจึงใช้งานได้และเหมาะสมกับโปรเจ็กต์ของคุณ

แนวทาง

เมื่อจะใช้

ความสนใจ

เสร็จสิ้นแบบอินไลน์

เม็ดมีดขนาดเล็กไหล

อย่ายอมรับข้อเสนอแนะโดยไม่ได้อ่าน

การผลิตตามสัญญาในการแชท

ฟังก์ชั่น/คลาสใหม่

ยกตัวอย่างและกรณีขอบ

ผลิตตามตัวอย่างสไตล์

การเพิ่มรหัสที่มีอยู่

เลือกโค้ดตัวอย่างปัจจุบัน

การบรรจุโครงกระดูก

ลายเซ็นคงที่ เนื้อหาว่างเปล่า

การเปลี่ยนลายเซ็น

การทำสำเนาโค้ดและกับดักการพึ่งพา

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

ข้อควรระวัง: ตรวจสอบบรรทัดการนำเข้าที่แนะนำโดย AI ชื่อแพ็คเกจที่ไม่มีอยู่จริง (ซึ่งอาจคล้ายกับแพ็คเกจปลอมที่เรียกว่า "typo-squatting") จะทำให้การคอมไพล์หยุดชะงักและก่อให้เกิดความเสี่ยงด้านความปลอดภัย

ข้อผิดพลาดทั่วไป

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

โดยสรุป

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

งานสมัคร

เลือกฟังก์ชันขนาดเล็กจริงจากโปรเจ็กต์ของคุณที่คุณต้องการเขียน ขั้นแรก ให้พิมพ์ไปที่ AI ​​ด้วยเทมเพลต “การสร้างฟังก์ชันตามสัญญา” โดยระบุประเภทอินพุต/เอาท์พุต เคส Edge สองกรณี และข้อจำกัดด้านสไตล์ รวบรวมโค้ดที่สร้างขึ้นและลองใช้กับอินพุตที่แตกต่างกันสองแบบ จากนั้นถามฟังก์ชันเดิมอีกครั้ง คราวนี้ "เขียนสิ่งนี้ให้ฉัน" โดยไม่มีบริบทใดๆ และเปรียบเทียบเอาต์พุตทั้งสองทีละบรรทัด: Edge case ใดที่พลาดไป ต้องมีการแก้ไขกี่ครั้ง

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

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