กำไร:
- ความสามารถในการแยกแยะว่า AI ให้ความเร็วที่แท้จริงในวงจรการพัฒนาซอฟต์แวร์ตรงไหน และการตัดสินใจและความรับผิดชอบยังคงอยู่ที่ใดของวิศวกร
- ความสามารถในการใช้ระเบียบวินัยทางวิศวกรรมสามชั้นที่ตรวจสอบทุกรหัสและการออกแบบที่สร้างขึ้นผ่านการรวบรวม การทดสอบ และการตรวจสอบ
- สร้างนิสัยในการล้างบริบทเพื่อใช้ประโยชน์จาก AI โดยไม่ต้องแชร์ซอร์สโค้ดที่เป็นความลับ ข้อมูลประจำตัว และข้อมูลลูกค้า
เมื่อคุณดูวันวิศวกรคอมพิวเตอร์ รูปภาพจะคล้ายกันในทีมส่วนใหญ่: การทำความเข้าใจคำขอทางธุรกิจ การออกแบบ การเขียนโค้ด การอ่านโค้ดของผู้อื่น การดีบัก (กระบวนการค้นหาสาเหตุที่โปรแกรมทำงานไม่ถูกต้องและการแก้ไข) การเขียนแบบทดสอบ การเตรียมเอกสาร การตรวจสอบโค้ด และการเข้าร่วมการประชุม กล่าวอีกนัยหนึ่ง เวลาที่ทุ่มเทให้กับ "วิจารณญาณทางวิศวกรรม" ที่แท้จริง กล่าวคือ ไม่ว่าวิธีแก้ปัญหาจะถูกต้อง ปลอดภัย และยั่งยืนหรือไม่ก็ตาม จะต้องถูกบดขยี้ภายใต้การทำงานซ้ำๆ นี่คือจุดที่ปัญญาประดิษฐ์ (AI หรือซอฟต์แวร์ที่ทำงานบนข้อความและโค้ดที่มีโมเดลภาษาขนาดใหญ่) เข้ามามีบทบาท AI ไม่ได้ตัดสินใจแทนคุณ โดยจะเตรียมคุณสำหรับการตัดสินใจ สร้างโครงร่างโค้ด ลดข้อผิดพลาดลง และวางร่างที่ใช้งานได้ไว้ตรงหน้าคุณ ตลอดโมดูลนี้ เราจะวางตำแหน่ง AI ไม่ใช่ "โปรแกรมเมอร์อัตโนมัติ" แต่เป็นพันธมิตรในการเขียนโปรแกรมคู่ที่มีระเบียบวินัย ซึ่งมีการรวบรวม ทดสอบ และตรวจสอบผลลัพธ์ทุกครั้ง
ในหน่วยแรกนี้ เราอธิบายสามสิ่ง: ในขั้นตอนใดของวงจรการพัฒนาซอฟต์แวร์ (ขั้นตอนที่ซอฟต์แวร์ต้องผ่านจากแนวคิดไปสู่การผลิต: การวิเคราะห์ การออกแบบ การเขียนโค้ด การทดสอบ การปรับใช้ การบำรุงรักษา) AI จะเพิ่มมูลค่าที่แท้จริงหรือไม่ การตัดสินใจใดควรอยู่กับวิศวกรอย่างเคร่งครัด และวินัยในการตรวจสอบและการรักษาความลับที่คุณต้องปฏิบัติตามคืออะไรเมื่อทำเช่นนี้ หากไม่มีการติดตั้งหลังคาอย่างถูกต้อง เทคนิคในยูนิตต่อๆ ไปอาจเป็นอันตรายได้ เนื่องจากข้อผิดพลาดในซอฟต์แวร์เข้าถึงผู้ใช้หลายล้านคนในเวลาเดียวกันและอาจกลายเป็นช่องโหว่ด้านความปลอดภัยได้
แนวคิด: ภาพหลอน: การสร้างวิธีการ ไลบรารี API หรือพฤติกรรมที่ไม่มีอยู่จริงอย่างน่าเชื่อของ AI บริบท: ข้อมูลที่คุณให้กับ AI (รหัส ข้อความแสดงข้อผิดพลาด ข้อกำหนด ข้อจำกัด) การตรวจสอบ: การตรวจสอบผลลัพธ์ด้วยวิธีอิสระ (การคอมไพล์ การทดสอบ และการจัดทำเอกสาร) แนวคิดทั้งสามนี้เป็นแกนหลักของโมดูลทั้งหมด
AI Accelerator ในธุรกิจใดบ้าง ธุรกิจใดบ้างที่มีความเสี่ยง?
งานด้านซอฟต์แวร์มีสองด้านในแง่ของผลลัพธ์ ที่ปลายด้านหนึ่งเป็นงานเตรียมแบบย้อนกลับได้และมีความเสี่ยงต่ำ ในอีกด้านหนึ่ง มีงานที่ส่งคืนยากซึ่งเข้าสู่สภาพแวดล้อมการใช้งานจริง และอาจทำให้ข้อมูลสูญหาย ช่องโหว่ด้านความปลอดภัย หรือการหยุดชะงัก คุณค่าของ AI จะแตกต่างกันไปขึ้นอยู่กับจุดยืนของคุณบนสเปกตรัมนี้
ประเภทธุรกิจ
การมีส่วนร่วมของ AI
บทบาทของวิศวกร
โครงกระดูกรหัส / แผ่นสำเร็จรูป
การสร้างโครงสร้างซ้ำอย่างรวดเร็ว
การควบคุมสถานะลอจิกและเอดจ์
การดีบัก
สมมติฐานและรายการสาเหตุที่เป็นไปได้
การสืบพันธุ์และการยืนยันสาเหตุที่แท้จริง
การทดสอบการเขียน
ทดสอบร่างและการสร้างสถานการณ์
การยืนยันและการตรวจสอบขอบเขตที่มีความหมาย
การปรับโครงสร้างใหม่
ข้อเสนอการปรับโครงสร้างใหม่
การรักษาพฤติกรรมผ่านการทดสอบ
เอกสารประกอบ
แบบร่างและโครงสร้างฉบับแรก
ตรวจสอบความถูกต้องกับรหัส
การตัดสินใจทางสถาปัตยกรรม/ความปลอดภัย
รายการตัวเลือกและข้อดีข้อเสีย
การตัดสินใจขั้นสุดท้ายและความรับผิดชอบ
กฎง่ายๆ ก็คือ ความเสี่ยงของเอาต์พุต AI เท่ากับความเสียหายที่จะเกิดขึ้นหากเอาต์พุตนั้นเกิดข้อผิดพลาด การแนะนำชื่อตัวแปรอย่างไม่ถูกต้องนั้นไม่เป็นอันตราย การรับรองความถูกต้องที่ไม่เหมาะสม (การตรวจสอบว่าผู้ใช้คือบุคคลที่ตนอ้างว่าเป็นจริงๆ) ทำให้ทั้งระบบมีช่องโหว่ ดังนั้นคำถามแรกที่ถามก่อนใช้เอาต์พุตคือ "จะเกิดอะไรขึ้นหากสิ่งนี้ผิด และใครสังเกตเห็น และเมื่อใด"
ข้อควรระวัง: AI สร้างโค้ดที่คล่องแคล่วและมั่นใจ ความคล่องแคล่วไม่รับประกันความถูกต้อง โมเดลภาษาสามารถสร้างชื่อฟังก์ชันที่ไม่มีอยู่จริง ลำดับพารามิเตอร์ที่ไม่ถูกต้อง หรือแม้แต่รูปแบบที่ไม่ปลอดภัยได้อย่างน่าเชื่อถือ ในซอฟต์แวร์ สิ่งนี้จะไม่อยู่บนกระดาษ มันรวบรวม รัน และระเบิดในการผลิต
การตัดสินใจที่ควรตกเป็นของวิศวกร
การตัดสินใจบางอย่างไม่ควรเป็นแบบอัตโนมัติทั้งหมด มีความเสี่ยงด้านเทคนิค กฎหมาย และจริยธรรม:
- การอนุมัติการผลิต: การเปิดตัวรหัสสู่การผลิตและความรับผิดชอบในเรื่องนี้
- ความปลอดภัยและสถาปัตยกรรม: การตัดสินใจที่มีราคาแพง เช่น การรับรองความถูกต้อง การอนุญาต การเข้ารหัส และแบบจำลองข้อมูล
- ใบอนุญาตและลิขสิทธิ์: การใช้งานรหัสที่ผลิตในผลิตภัณฑ์เชิงพาณิชย์และการปฏิบัติตามใบอนุญาต
- การทำงานกับข้อมูลที่เป็นความลับ: การทำธุรกรรมกับข้อมูลลูกค้า ความลับของซอร์สโค้ด และข้อมูลประจำตัว
คำเตือน: แม้ว่า AI จะบอกว่า "โค้ดนี้ปลอดภัยและพร้อมสำหรับการผลิต" แต่การยอมรับสิ่งนี้โดยไม่มีการทดสอบความปลอดภัย การตรวจสอบโค้ดและการตรวจสอบความถูกต้องภายใต้การโหลดจริงนั้นเป็นสิ่งที่ยอมรับไม่ได้ ในงานที่มีความสำคัญด้านความปลอดภัย เอาท์พุตของ AI จะไม่สามารถใช้ทดแทนการอนุมัติจากวิศวกรที่มีความสามารถได้ ผลลัพธ์ใดๆ ที่นำไปสู่การตัดสินใจจะต้องได้รับการตรวจสอบและอนุมัติอย่างอิสระโดยวิศวกรที่ได้รับอนุญาตก่อนนำไปใช้งาน
วินัยในการตรวจสอบ: การควบคุมสามชั้น
ใช้การควบคุมสามชั้นเพื่อใช้เอาต์พุต AI เหมือนผู้ตรวจสอบอาวุโสแทนที่จะสุ่มสี่สุ่มห้า นี่คือภาพสะท้อนพื้นฐานที่เราจะทำซ้ำตลอดทั้งโมดูล
- การคอมไพล์และการตรวจสอบแบบคงที่: โค้ดคอมไพล์/รันจริงหรือไม่ มีข้อผิดพลาดประเภท ตัวแปรที่ไม่ได้ใช้ API ที่ไม่มีอยู่จริงหรือไม่ เครื่องมือวิเคราะห์แบบคงที่ (เครื่องมือที่ตรวจสอบโค้ดโดยไม่ต้องรัน) พูดว่าอย่างไร
- การทำสำเนาโดยอิสระ (การทดสอบ): รันโค้ดด้วยอินพุตขนาดเล็กที่รู้จัก และดูว่าคุณได้รับเอาต์พุตที่คาดหวังหรือไม่ ลองใช้กรณีขอบ (null, ศูนย์, ลบ, ใหญ่)
- การตรวจสอบแหล่งที่มา: ทุกฟีเจอร์ API, เวอร์ชันไลบรารี และภาษาที่ AI ใช้ควรได้รับการตรวจสอบจากเอกสารอย่างเป็นทางการ
พร้อมท์การยืนยัน (ช่วยให้ตรวจสอบผลลัพธ์ได้ง่ายขึ้น): "แสดงรายการไลบรารีภายนอก วิธีการ และคุณลักษณะภาษาทั้งหมดที่คุณใช้ในโค้ดของคุณ สำหรับแต่ละรายการ ให้ระบุเวอร์ชันที่มีอยู่และติดป้ายกำกับว่า 'ต้องตรวจสอบจากเอกสารประกอบ' อย่าสร้าง API ใด ๆ ที่คุณไม่แน่ใจ หากคุณไม่แน่ใจ ให้เขียน 'ไม่แน่ใจ' อย่างชัดเจน นอกจากนี้ ให้ระบุกรณี Edge ใด ๆ ที่คุณไม่ได้ระบุเป็นรายการแยกต่างหากด้วย"
วิจารณ์โค้ดของคุณเอง: "จงมองโค้ดที่คุณเพิ่งเขียนอย่างมีวิจารณญาณ เหมือนวิศวกรอาวุโสที่จ้างคุณ ให้รายการที่เป็นรูปธรรมภายใต้หัวข้อทั้งสามนี้: (1) ข้อผิดพลาดของตัวพิมพ์ตรรกะ/ขอบ (2) ความเสี่ยงด้านความปลอดภัย (3) ปัญหาด้านประสิทธิภาพหรือความสามารถในการอ่าน เขียนสำหรับแต่ละรายการ ให้เขียนว่า 'เหตุใดจึงเกิดปัญหา' และ 'วิธีแก้ไขที่แนะนำ' หากไม่มีปัญหา ให้พูดว่า 'ฉันไม่พบปัญหา' อย่าพยายามตกแต่งมัน"
พรอมต์ที่อ่อนแอ / พรอมต์ที่แข็งแกร่ง
อ่อนแอ: "เขียนฟังก์ชันการตรวจสอบสิทธิ์ผู้ใช้ให้ฉัน" (ผลลัพธ์: ไม่ชัดเจนว่าภาษาใด กฎใด ลักษณะการทำงานผิดพลาด รหัสทั่วไป มักไม่ปลอดภัยหรือไม่อยู่ในบริบท) แข็งแกร่ง: "เขียนฟังก์ชันตรวจสอบอีเมลสำหรับ Python 3.11 อินพุต: สตริง เอาท์พุต: จริงหากถูกต้อง เท็จ มิฉะนั้น กฎ: สตริงว่าง เท็จ ไม่จำเป็นต้องปฏิบัติตาม RFC รูปแบบพื้นฐานเพียงพอ ห้ามใช้ไลบรารีภายนอก การทดสอบ 5 ตัวอย่างด้านล่างฟังก์ชันต่อท้ายบล็อก: ถูกต้อง ว่างเปล่า ไม่ '@', สองเท่า '@' มีช่องว่างเท่านั้น"
ความแตกต่างอยู่ในบริบท พรอมต์อันทรงพลัง; รวมถึงภาษา เวอร์ชัน สัญญาอินพุต-เอาท์พุต ข้อจำกัด และความคาดหวังในการทดสอบ ระเบียบวินัยเดียวนี้ช่วยลดความเสี่ยงของภาพหลอนและรหัสที่ไม่ปลอดภัยได้อย่างมาก
เคสมินิ
กรณีที่ 1 — วิธีการประดิษฐ์ นักพัฒนาได้ยินจาก AI ว่ามีวิธีที่เรียกว่า date.addBusinessDays(5) ในไลบรารีวันที่ และมีการอธิบายในลักษณะที่มั่นใจ เมื่อดูเอกสารประกอบก็พบว่าไม่มีวิธีดังกล่าว วิธีที่ถูกต้องคือ manual loop ภาพหลอนจะถูกบันทึกไว้ก่อนที่จะเข้าสู่การผลิตด้วยการตรวจสอบยืนยันเป็นเวลา 10 นาที
กรณีที่ 2 — การสูญเสียสถานะ Edge AI สร้างฟังก์ชัน "คำนวณค่าเฉลี่ย" ใช้งานได้เมื่อทดสอบกับข้อมูล 1,000 แถว อย่างไรก็ตาม เมื่อรายการว่างเปล่า จะทำให้เกิดข้อผิดพลาดในการหารด้วยศูนย์ เนื่องจากวิศวกรเพิ่มการทดสอบอินพุตว่าง เขาจึงมองเห็นและแก้ไขข้อผิดพลาดก่อนที่จะเผยแพร่ การทดสอบสภาพขอบเดียวจะช่วยป้องกันสัญญาณเตือนการผลิตในเวลาตี 3
กรณีที่ 3 — ความเสี่ยงด้านความเป็นส่วนตัว ผู้เชี่ยวชาญกำลังจะวางไฟล์ที่มีสตริงการเชื่อมต่อฐานข้อมูลจริงและคีย์ API ลงในเครื่องมือสาธารณะ จดจำนโยบายของสถาบัน โดยจะแทนที่ข้อมูลลับด้วย <REDACTED> ลดขนาดโค้ดให้เป็นตัวอย่างที่เป็นตัวแทน และถามหา ดังนั้นเขาได้รับความช่วยเหลือภายใน 5 นาที แต่ข้อมูลประจำตัวของเขากลับไม่ปรากฏออกมา
หลักการทำงานกับรหัสลับและข้อมูลประจำตัว
ส่วนที่ละเอียดอ่อนที่สุดของซอฟต์แวร์ ความลับของซอร์สโค้ด ข้อมูลประจำตัว (คีย์ API รหัสผ่าน โทเค็น) และข้อมูลลูกค้า/ข้อมูลส่วนบุคคล หลักการพื้นฐาน: ทำความสะอาดก่อนแบ่งปัน ถามเฉพาะแก่นแท้ของปัญหาพร้อมยกตัวอย่างหากเป็นไปได้
รูปแบบพรอมต์ที่ไม่ระบุชื่อ: "มีข้อผิดพลาดในฟังก์ชันต่อไปนี้ ฉันแทนที่ตรรกะทางธุรกิจจริงและค่าคงที่ที่ซ่อนอยู่ด้วยค่าตัวแทน (คีย์ API ชื่อตาราง ชื่อฟิลด์ทั่วไป) ปัญหา: ฉันได้รับข้อผิดพลาด Y ในอินพุต X เพียงค้นหาข้อผิดพลาดทางตรรกะในรหัสตัวแทนนี้และอธิบายเวอร์ชันที่ถูกต้อง [รหัสตัวแทน]"
เคล็ดลับ: หากมีข้อสงสัย ให้ทำการทดสอบนี้: "องค์กรของฉันจะประสบปัญหาหรือไม่หากฉันเขียนสิ่งนี้ต่อสาธารณะในฟอรัม" แม้ว่าคำตอบจะไม่ชัดเจนก็ให้เคลียร์ไว้ก่อน การรีเซ็ตมีราคาถูกกว่าการไล่ตามรอยรั่วในภายหลังเสมอ
ข้อผิดพลาดทั่วไป
- การใช้เอาต์พุตโดยไม่ต้องรวบรวม/ทดสอบ “AI เขียน” ไม่ใช่เหตุผล โค้ดแต่ละชิ้นได้รับการตรวจสอบโดยการรัน
- การร้องขอโดยไม่มีบริบท หากไม่ได้ระบุภาษา เวอร์ชัน อินพุต-เอาท์พุต และข้อจำกัด โค้ดจะกลายเป็นแบบทั่วไปและมักจะไม่ปลอดภัย
- แบ่งปันข้อมูลที่เป็นความลับโดยไม่ต้องคิด ไม่ควรปล่อยคีย์ API รหัสผ่าน และข้อมูลลูกค้าโดยไม่ล้างข้อมูล
- สับสนภาษาที่แม่นยำกับความถูกต้อง ยิ่ง AI พูดมีความมั่นใจมากเท่าไรก็ยิ่งระมัดระวังมากขึ้นเท่านั้น น้ำเสียงที่มั่นใจไม่ใช่หลักฐาน
- การมอบหมายการตัดสินใจให้กับ AI การตัดสินใจในการผลิต การรักษาความปลอดภัย และสถาปัตยกรรมยังคงเป็นหน้าที่ของวิศวกร AI ผลิตแต่วัสดุเท่านั้น
โดยสรุป
AI ช่วยเพิ่มความเร็วให้กับส่วนที่ซ้ำซากและใช้เวลานานของงานซอฟต์แวร์: โค้ดโครงร่าง การร่างการทดสอบ การลดจุดบกพร่อง และการจัดทำเอกสาร อย่างไรก็ตามการตัดสินใจและความรับผิดชอบยังคงอยู่กับวิศวกร ทุกเอาต์พุตจะต้องผ่านการควบคุมสามชั้น (คอมไพล์/สแตติก การทดสอบ แหล่งที่มา) การเขียนพร้อมท์พร้อมบริบทและการล้างข้อมูลที่ซ่อนอยู่เป็นนิสัยหลักสองประการที่เราจะทำซ้ำในแต่ละหน่วยของโมดูลนี้ เมื่อคุณใช้ AI อย่างมีระเบียบวินัย คุณจะได้รับความเร็ว เมื่อคุณใช้งานโดยไม่มีวินัย คุณจะนำข้อผิดพลาดและช่องโหว่ไปสู่การใช้งานจริง
งานสมัคร
เลือกงานเขียนโค้ดเล็กๆ จากงานของคุณเองหรือจากโครงการจินตภาพ (เช่น ฟังก์ชั่นการตรวจสอบความถูกต้อง) ขั้นแรกให้เขียนพรอมต์ที่อ่อนแอและรับเอาต์พุต จากนั้นใช้รูปแบบพรอมต์ที่มีประสิทธิภาพจากหน่วยนี้: เพิ่มภาษา/เวอร์ชัน สัญญาอินพุต-เอาท์พุต ข้อจำกัด และความคาดหวังในการทดสอบ วางงานพิมพ์ทั้งสองไว้เคียงข้างกันและเขียนความแตกต่าง จากนั้นรวบรวมผลลัพธ์ที่แข็งแกร่งและทดสอบด้วยกรณีขอบอย่างน้อยสามกรณี (รูปแบบ null, ศูนย์/ลบ, รูปแบบที่ไม่คาดคิด) และจดบันทึกสิ่งที่คุณพบในการทดสอบใด
รายการตรวจสอบ
- [ ] ฉันเพิ่มภาษา เวอร์ชัน และสัญญาอินพุต-เอาท์พุตลงในพรอมต์
- [ ] ฉันเขียนว่า "อย่าแต่งเติม บอกฉันถ้าคุณไม่แน่ใจ" และข้อจำกัดของขอบเขต
- [ ] ฉันรวบรวม/รันโค้ด ตรวจสอบคำเตือนแบบคงที่
- [ ] ฉันทดสอบกับ Edge Case อย่างน้อยสามกรณี
- [ ] ฉันตรวจสอบ API ที่ใช้จากเอกสารอย่างเป็นทางการ
- [ ] ฉันล้างรหัสลับ/ข้อมูลรับรองหรือเครื่องมือระดับองค์กรที่ใช้งานแล้ว
- [ ] ฉันยืนยันว่าการตัดสินใจในการผลิตและการรักษาความปลอดภัยยังคงเป็นของมนุษย์