โมเดลแชทกับเอเจนต์เขียนโค้ดเป็นเครื่องมือคนละแบบ
ควรแยกให้ชัดตั้งแต่แรก เพราะทั้งสองอย่างมักถูกเข้าใจปนกัน เครื่องมือเขียนโค้ดแบบเอเจนต์อยู่ในอีดิเตอร์หรือเทอร์มินัลของคุณ อ่านรีโพซิทอรี และเขียนไฟล์ให้ ส่วนพื้นที่แชทคือที่ที่คุณคิด คุณแปะ stack trace ถกเถียงเรื่องแนวทาง รีวิว diff ทำความเข้าใจไลบรารีที่ไม่เคยใช้มาก่อน และร่างเอกสารออกแบบ
นักพัฒนาส่วนใหญ่ใช้ทั้งสองแบบ และฝั่งแชทคือจุดที่การเลือกโมเดลสำคัญที่สุด เพราะคุณกำลังอ่านเหตุผลมากกว่า diff และนี่คือจุดที่การจ่ายค่าสมัครสมาชิกสามที่แยกกันเพื่อเทียบสามโมเดลเริ่มไม่สมเหตุสมผล
| สิ่งที่คุณกำลังทำ | แนวโน้มของโมเดล | หมายเหตุ |
|---|---|---|
| การให้เหตุผลที่ยาก: concurrency ปัญหา race ที่ซับซ้อน หรือการตัดสินใจเชิงสถาปัตยกรรม | Claude กับ GPT ต่างกันอย่างมีนัยสำคัญ | ถามทั้งคู่ นี่คือกรณีที่ความเห็นที่สองคุ้มค่ากับตัวมันเอง |
| ความเร็วในการเขียนโค้ดบนพื้นที่ที่คุ้นเคยดีแล้ว | GPT | เร็ว เขียนได้เป็นธรรมชาติ เก่งเรื่อง boilerplate และการแปลงรูปแบบ |
| อ่านโค้ดเบสขนาดใหญ่ที่ไม่คุ้นเคย หรือสเปกที่ยาว | Gemini | หน้าต่างบริบทใหญ่ที่สุด จึงใส่ระบบทั้งหมดเข้าไปได้มากกว่าในครั้งเดียว |
| อธิบายข้อผิดพลาดหรือแนวคิด | ขึ้นอยู่กับมุมมองที่เข้าใจง่ายกว่า | แต่ละโมเดลอธิบายต่างกัน และนั่นแหละคือประเด็น |
| เอาต์พุตที่มีโครงสร้างตายตัว: config, JSON, schema | GPT | เชื่อถือได้มากที่สุดในการทำตามรูปแบบเป๊ะๆ |
พรอมต์ดีบักที่ดีกว่าการแปะ stack trace ตรงๆ
การแปะข้อผิดพลาดแล้วถามว่าอะไรผิดจะได้แค่การเดา การเดามักจะถูก แต่เมื่อผิดคุณจะเสียเวลาไปยี่สิบนาทีไล่ตามวิธีแก้ที่ฟังดูสมเหตุสมผลสำหรับปัญหาที่คุณไม่ได้มี พรอมต์เหล่านี้เปลี่ยนรูปแบบของคำตอบ
พรอมต์: ตั้งสมมติฐานก่อนแก้ปัญหา
นี่คือข้อผิดพลาด โค้ด และสิ่งที่ฉันตัดออกไปแล้ว อย่าเพิ่งให้วิธีแก้ ให้ระบุสาเหตุที่เป็นไปได้มากที่สุดสี่ข้อเรียงตามความน่าจะเป็น และสำหรับแต่ละข้อ ให้บอกวิธีตรวจสอบที่ถูกที่สุดที่จะยืนยันหรือตัดทิ้งได้ ข้อผิดพลาด: [paste] โค้ด: [paste] สิ่งที่ตัดออกไปแล้ว: [list]
พรอมต์: บั๊กที่เกิดขึ้นบางครั้ง
สิ่งนี้ล้มเหลวเป็นระยะๆ ประมาณ [frequency] ภายใต้ [conditions] นี่คือโค้ดที่เกี่ยวข้องและสิ่งที่ฉันรู้เกี่ยวกับสภาพแวดล้อม ให้ระบุประเภทของความล้มเหลวเป็นระยะๆ ที่อาจก่อให้เกิดอาการนี้โดยเฉพาะ (จังหวะเวลา ลำดับ ทรัพยากรหมด การพึ่งพาภายนอก การรั่วไหลของสถานะระหว่างการรัน นาฬิกาหรือโซนเวลา แคช) สำหรับแต่ละข้อ บอกว่าหลักฐานในสิ่งที่ฉันให้ไปสนับสนุนหรือขัดแย้งอย่างไร และฉันควร log อะไรเพื่อแยกแยะระหว่างกัน
พรอมต์: อธิบายวิธีแก้ก่อนที่ฉันจะใช้
อธิบายว่าทำไมวิธีแก้นี้ถึงได้ผล มันไม่ได้แก้อะไร และมันอาจทำให้อะไรพังบ้าง ถ้าสาเหตุที่แท้จริงอยู่ที่อื่นและนี่เป็นแค่การปะอาการ ให้บอกตรงๆ
พรอมต์สุดท้ายนี้จับความช่วยเหลือจาก AI ประเภทที่แพงที่สุด นั่นคือการเปลี่ยนแปลงที่ทำให้อาการหายไปในขณะที่ข้อบกพร่องจริงยังอยู่ในโค้ดเบส
ใช้สองโมเดลกับปัญหาเดียวกัน ไม่ใช่แค่ลูกเล่น
เมื่อคำตอบชัดเจนอยู่แล้ว โมเดลเดียวก็เพียงพอ เทคนิคนี้คุ้มค่าตรงปัญหาที่คุณไม่แน่ใจ และมันได้ผลเพราะโมเดลต่างๆ ล้มเหลวไปคนละแบบ ไม่ใช่แบบเดียวกัน
รูปแบบที่มีประโยชน์ไม่ใช่การถามทั้งคู่แล้วเลือกคำตอบที่ชอบ แต่คือการถามโมเดลหนึ่งก่อน แล้วส่งคำตอบนั้นให้อีกโมเดลตรวจสอบ
พรอมต์: รีวิวคำตอบแบบจับผิด
วิศวกรอีกคนเสนอวิธีแก้นี้สำหรับปัญหานี้ ให้หาว่ามีอะไรผิดพลาด: ความถูกต้องภายใต้ edge case, concurrency, การจัดการข้อผิดพลาด, ประสิทธิภาพที่ [scale] หรือแนวทางที่ง่ายกว่าที่ถูกมองข้ามไป ถ้ามันสมเหตุสมผลจริงๆ ให้บอกตรงๆ แทนที่จะสร้างข้อโต้แย้งขึ้นมา ปัญหา: [paste] วิธีแก้ที่เสนอ: [paste]
มีสองผลลัพธ์ที่เป็นประโยชน์ทั้งคู่ ไม่ว่าโมเดลที่สองจะเจอช่องโหว่จริง ซึ่งคุณจะรู้ก่อน merge หรือมันเห็นด้วย ซึ่งเป็นหลักฐานที่แท้จริงเพราะมันมีแรงจูงใจทุกอย่างที่จะไม่เห็นด้วย เทียบกับการทำซ้ำกับโมเดลเดิม ซึ่งมักจะเห็นด้วยกับตัวเอง
รูปแบบเดียวกันนี้ใช้ได้กับการตัดสินใจเชิงออกแบบด้วย
พรอมต์: โต้แย้งฝั่งตรงข้าม
ฉันเลือก [approach A] แทน [approach B] สำหรับ [context and constraints] ให้สร้างข้อโต้แย้งที่หนักแน่นที่สุดสำหรับ B เงื่อนไขอะไรบ้างที่ต้องเป็นจริงเกี่ยวกับข้อจำกัดของเราเพื่อให้ B เป็นตัวเลือกที่ถูกต้อง และมีข้อไหนที่เป็นจริงในกรณีนี้บ้าง
ฟีเจอร์เปรียบเทียบแบบเคียงข้างกันของ Whizi มีไว้เพื่อสิ่งนี้โดยเฉพาะ และมีคู่มืออยู่ที่ compare models side by side
รีวิวโค้ดและอ่านโค้ดที่ไม่คุ้นเคย
พรอมต์: รีวิว diff แบบผู้รีวิวที่จู้จี้
รีวิว diff นี้ เรียงตามหมวดหมู่ดังนี้: บั๊กด้านความถูกต้อง ปัญหาด้านความปลอดภัย เคสความล้มเหลวที่ไม่ได้จัดการ race condition แล้วค่อยเรื่องสไตล์ สำหรับแต่ละข้อที่พบ ให้บอกความรุนแรง บรรทัดที่ชัดเจน และเหตุผลว่าทำไมมันสำคัญในบริบทนี้ ไม่ใช่ในเชิงทั่วไป อย่าคอมเมนต์เรื่องการจัดรูปแบบ ถ้า diff นี้ไม่มีปัญหา ให้บอกตรงๆ บริบท: โค้ดเบสนี้ใช้ [stack and conventions] Diff: [paste]
พรอมต์: ทำความเข้าใจโค้ดเบสที่เพิ่งรับช่วงต่อ
นี่คือไฟล์ซอร์สหลัก ให้สรุป: จุดเริ่มต้นของโปรแกรม การไหลของข้อมูลจาก request ไปยัง response สถานะที่ถูกใช้ร่วมกันและถูกเปลี่ยนแปลงที่ไหน dependency ภายนอกและจะเกิดอะไรขึ้นเมื่อแต่ละตัวใช้งานไม่ได้ และสามส่วนที่มีแนวโน้มจะมีบั๊กมากที่สุดตามความซับซ้อนและการเชื่อมโยง บอกให้ชัดเจนว่าอะไรที่คุณระบุไม่ได้จากสิ่งที่ฉันให้ไป
คำสั่งสุดท้ายนี้สำคัญกว่าที่เห็น โมเดลมักจะอธิบายพฤติกรรมของไฟล์ที่คุณไม่ได้แปะให้อย่างสบายใจ โดยเดาจากชื่อไฟล์เท่านั้น การบังคับให้ระบุรายการสิ่งที่ไม่รู้อย่างชัดเจนจะบอกคุณว่าควรไปอ่านอะไรต่อ
พรอมต์: เขียนเทสต์ที่คุณคาดไม่ถึง
เขียนเทสต์เคสสำหรับฟังก์ชันนี้ โดยเน้นอินพุตที่ฉันน่าจะยังไม่ได้พิจารณา: ค่าขอบเขต ค่าว่างและ null, unicode, ค่าที่ใหญ่มาก การเรียกพร้อมกัน และสมมติฐานแฝงใดๆ ในการทำงาน สำหรับแต่ละเทสต์ ให้ระบุสมมติฐานที่มันกำลังตรวจสอบ ฟังก์ชัน: [paste]
จุดพลาดที่ทำให้เสียเวลาจริง
API ที่ไม่มีอยู่จริง โมเดลมักสร้างชื่อเมธอด พารามิเตอร์ และ config key ที่ไม่มีอยู่จริงด้วยความมั่นใจ โดยเฉพาะไลบรารีที่เพิ่งเปลี่ยนแปลงหรือไม่ค่อยเป็นที่รู้จัก signature จะดูถูกต้องดี ตรวจสอบเอกสารจริงก่อนสร้างสิ่งใดต่อจากสิ่งที่ไม่คุ้นเคย
วิธีแก้ที่ผิดแบบมั่นใจ ไม่มีสัญญาณใดในน้ำเสียงเลย วิธีแก้ที่แก้ปัญหาได้จริงกับวิธีแก้ที่สร้างปัญหาใหม่ที่ซ่อนอยู่ ถูกส่งมาด้วยความมั่นใจเท่ากันเป๊ะ ควรถามเสมอว่าการเปลี่ยนแปลงนี้อาจทำให้อะไรพัง
รูปแบบที่ล้าสมัย ข้อมูลฝึกสอนมักเอนเอียงไปตามปริมาณโค้ดที่เขียนเกี่ยวกับเฟรมเวิร์กหนึ่งๆ ซึ่งมักเป็นเวอร์ชันหลักก่อนหน้า ถ้าคำตอบให้ความรู้สึกเหมือนมาจากหลายปีก่อน มันก็อาจจะเป็นแบบนั้นจริงๆ บอกเวอร์ชันที่คุณใช้อยู่ในพรอมต์ด้วย
scope creep แบบเงียบๆ ขอวิธีแก้แต่มักได้ refactor กลับมาแทน เพิ่ม change as little as possible, and list every line you changed and why เพื่อให้ diff ยังรีวิวได้
ละครความปลอดภัย โมเดลสามารถระบุประเภทของช่องโหว่ในโค้ดของคุณได้ ซึ่งมีประโยชน์จริงสำหรับการตรวจสอบรอบแรก แต่มันไม่ใช่การ audit มันไม่รู้ threat model การดีพลอย หรือความอ่อนไหวของข้อมูลของคุณ
ตำแหน่งของมันในชุดเครื่องมือที่คุณมีอยู่
มันไม่ได้มาแทนที่การเชื่อมต่อกับอีดิเตอร์หรือเครื่องมือเขียนโค้ดแบบเอเจนต์ของคุณ แต่มันมาแทนที่แท็บเบราว์เซอร์สามแท็บที่คุณเปิดเทียบคำตอบ บวกกับค่าสมัครสมาชิกสองที่ที่ต้องมีเพื่อเปิดแท็บเหล่านั้นพร้อมกัน
การตั้งค่าที่นักพัฒนาส่วนใหญ่ลงเอยด้วยจริงๆ คือ โมเดลหลักหนึ่งตัวสำหรับคำถามด่วน โมเดลที่สองที่สลับไปใช้เมื่อคำตอบแรกไม่น่าเชื่อถือ และ Gemini เมื่อต้องใส่โค้ดจำนวนมากหรือสเปกที่ยาวเข้าไปให้โมเดลดูพร้อมกันในครั้งเดียว ทั้งหมดอยู่ในเธรดเดียว บริบทที่คุณตั้งไว้แล้วจึงติดตามไปด้วยเมื่อสลับโมเดล แทนที่จะต้องแปะใหม่
อ่านเพิ่มเติมได้ที่ AI for coding, coding-focused alternatives comparison และ Claude coding prompt pack ส่วนวิธีตั้งค่านี้ภายใน Whizi อยู่ที่ write and debug code with multiple models
- ขอสมมติฐานเรียงลำดับและวิธีตรวจสอบที่ถูกก่อนขอวิธีแก้
- ส่งคำตอบของโมเดลแรกให้โมเดลที่สองตรวจหาช่องโหว่
- ถามเสมอว่าวิธีแก้ที่เสนอมาอาจทำให้อะไรพัง และมันเป็นแค่การปะอาการหรือเปล่า
- ระบุภาษา เฟรมเวิร์ก และเวอร์ชันในพรอมต์เพื่อหลีกเลี่ยงรูปแบบที่ล้าสมัย
- ตรวจสอบ API ที่ไม่คุ้นเคยกับเอกสารจริงก่อนสร้างต่อจากมัน
- เพิ่ม "change as little as possible and list every change" เพื่อให้ diff ยังรีวิวได้
- ใช้โมเดลที่มีบริบทขนาดใหญ่เมื่อคำถามครอบคลุมโค้ดมากกว่าที่จะใส่ในพรอมต์ปกติได้
คำถามที่พบบ่อย
ทำไมไม่ใช้แค่โมเดลเขียนโค้ดตัวเดียวไปเลย
สำหรับงานทั่วไป ตัวเดียวก็พอ คุณค่าจะเห็นชัดในปัญหาที่คุณไม่แน่ใจจริงๆ เพราะโมเดลต่างๆ ล้มเหลวไปคนละจุด ไม่ใช่จุดเดียวกัน การส่งวิธีแก้ที่โมเดล A เสนอให้โมเดล B ตรวจหาข้อบกพร่อง จะช่วยให้เจอปัญหาจริงก่อน merge หรือไม่ก็ให้การยืนยันที่มีความหมาย การทำซ้ำกับโมเดลเดียวส่วนใหญ่ให้ผลแค่การเห็นด้วยกับตัวเอง
นี่เป็นตัวแทนเครื่องมือเขียนโค้ดแบบเอเจนต์หรือไม่
ไม่ใช่ ทั้งสองแก้ปัญหาคนละแบบ เอเจนต์อยู่ในรีโพซิทอรีของคุณและแก้ไขไฟล์ ส่วนพื้นที่แชทคือที่ที่คุณใช้เหตุผล: stack trace ข้อโต้แย้งเชิงออกแบบ การรีวิว diff การทำความเข้าใจไลบรารีที่ไม่คุ้นเคย และการร่างเอกสารออกแบบ นักพัฒนาส่วนใหญ่ใช้ทั้งสองแบบ และการเลือกโมเดลสำคัญกว่าในฝั่งแชท เพราะคุณกำลังประเมินเหตุผล ไม่ใช่ diff ที่ได้
โมเดลไหนดีที่สุดสำหรับการเขียนโค้ด
ขึ้นอยู่กับงาน ซึ่งเป็นคำตอบที่ตรงไปตรงมาและเป็นเหตุผลที่หน้านี้มีอยู่ GPT มักจะเร็วกว่าและเขียนได้เป็นธรรมชาติกว่าในงานที่คุ้นเคยดีแล้ว Claude มักจะแข็งแกร่งกว่าในการให้เหตุผลที่ละเอียดอ่อน สถาปัตยกรรมที่ไม่คุ้นเคย และการอธิบายว่าทำไมสิ่งหนึ่งถึงทำงานแบบนั้น Gemini ชนะเมื่อคำถามต้องการใส่โค้ดหรือสเปกจำนวนมากพร้อมกัน การเทียบทั้งสามกับปัญหาจริงของคุณเองเป็นเวลาหนึ่งสัปดาห์ดีกว่า benchmark ใดๆ
ฉันสามารถแปะโค้ดที่เป็นกรรมสิทธิ์ได้ไหม
Whizi ไม่นำบทสนทนาของคุณไปฝึกโมเดล และนโยบายข้อมูลของแต่ละผู้ให้บริการก็เปิดให้ตรวจสอบได้ก่อนที่คุณจะเปิดใช้โมเดลนั้น นโยบายของนายจ้างคุณมักเป็นข้อจำกัดที่สำคัญที่สุดและแตกต่างกันไปมาก จึงควรตรวจสอบก่อน ในกรณีที่มีข้อจำกัด วิธีที่ใช้ได้จริงคือจำลองปัญหาขึ้นใหม่ในตัวอย่างขนาดเล็กที่มีโครงสร้างแต่ไม่มี business logic เลย ซึ่งมักให้คำตอบที่ดีกว่าด้วยซ้ำ
จะหยุดไม่ให้มันเขียนทุกอย่างใหม่ได้อย่างไร
สั่งให้ชัดเจน: change as little as possible, preserve the existing structure and naming, and list every line you changed with a one line reason การ refactor ที่ไม่ได้ขอเป็นสาเหตุหลักที่ทำให้คำแนะนำจาก AI รีวิวไม่ได้ และการจำกัด diff คือความต่างระหว่างการเปลี่ยนแปลงที่คุณให้เหตุผลตามได้ กับสิ่งที่คุณต้องอ่านใหม่ตั้งแต่ต้น