Grok สำหรับนักพัฒนา

Grok เป็นเหมือนเป็ดเหลืองคู่ใจ (rubber duck) ที่โต้ตอบกับคุณได้จริง บน grok.online ใช้งานได้ฟรีโดยไม่ต้องสมัครบัญชี: Grok 4.20 ทำงานรวดเร็วสำหรับคำถามสั้นๆ ทั่วไป, Grok 4.3 Thinking จะคิดวิเคราะห์อย่างละเอียดก่อนตอบ จึงเหมาะมากสำหรับการหาบั๊ก และ Grok 4.7 ซึ่งเป็นโมเดลใหม่ล่าสุด พร้อมช่วยคุณแก้ปัญหาที่ยากที่สุด โดยให้โควตา 10 ข้อความจากทั้งหมด 30 ข้อความต่อวันของคุณ ทั้งสามโมเดลสามารถอ่านภาพหน้าจอได้ นี่คือ 7 รูปแบบการใช้งาน พร้อมพรอมต์ที่คุณสามารถเปิดในแชตและนำไปปรับใช้ได้ทันที

ค้นหาและแก้ไขปัญหา

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

ถอดรหัส stack trace

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

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

เปิดพรอมต์นี้ในแชต หรือใช้ Code Assistant เพื่อทำงานในลักษณะเดียวกันได้ในหน้าต่างเดียว

ทำแผนผังโค้ดที่คุณไม่ได้เขียนเอง

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

ฉันเพิ่งได้รับช่วงต่อไฟล์ [ภาษา] นี้มา และจำเป็นต้องแก้ไข [ฟีเจอร์] ช่วยอธิบายภาพรวมสั้นๆ: ไฟล์นี้ทำหน้าที่อะไร, ฟังก์ชันหลักๆ มีอะไรบ้างโดยเรียงตามลำดับการทำงาน, มี global state หรือ side effects จุดไหนที่ต้องระวังเป็นพิเศษ และจุดที่ปลอดภัยที่สุดในการเริ่มแก้โค้ดคือตรงไหน: [วางโค้ด]

ดูภาพรวมโค้ด จากนั้นค่อยถามเจาะลึกในฟังก์ชันที่ยังดูเข้าใจยาก

ตามล่าหาบั๊กด้านตรรกะด้วยโมเดลสายคิดวิเคราะห์

เมื่อโค้ดไม่แครชแต่ผลลัพธ์กลับผิด คุณจำเป็นต้องไล่โค้ดทีละบรรทัดอย่างละเอียด Grok 4.3 Thinking จะไล่ตรวจสอบโค้ดอย่างเป็นขั้นตอนก่อนตอบ เหมาะเป็นพิเศษสำหรับบั๊กประเภท off-by-one หรือเงื่อนไขที่ทำงานผิดพลาด

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

ไล่ตรวจสอบโค้ดด้วย Grok 4.3 Thinking

แก้ปัญหาเลย์เอาต์พังจากภาพหน้าจอ

แนบภาพหน้าจอของหน้าเว็บที่มีปัญหา วางโค้ด HTML และ CSS ที่เกี่ยวข้อง แล้วอธิบายผลลัพธ์ที่ต้องการ

ฉันได้แนบภาพหน้าจอของหน้าที่เกิดปัญหา: [อธิบายปัญหา เช่น แถบด้านข้างซ้อนทับเนื้อหาเมื่อเปิดบนหน้าจอแคบ] นี่คือโค้ด HTML และ CSS ของส่วนดังกล่าว: [วางโค้ด] ช่วยอธิบายว่าเกิดจากอะไร และเสนอโค้ด CSS ที่แก้ไขแล้ว โดยปรับเปลี่ยนโค้ดเดิมให้น้อยที่สุด

เปิดพรอมต์นี้ แล้วแนบภาพหน้าจอของคุณ

วางแผนรีแฟกเตอร์โค้ดที่มีความเสี่ยงสูง

การจัดโครงสร้างโมดูลขนาดใหญ่ที่ซับซ้อนขึ้นใหม่ คือจังหวะที่คุ้มค่าแก่การใช้โควตารายวันของโมเดลรุ่นใหม่ล่าสุด แนะนำให้ขอเป็นแผนงานทีละขั้นตอนแทนการสั่งให้เขียนโค้ดใหม่ทั้งหมดทันที

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

วางแผนงานด้วย Grok 4.7 จากนั้นค่อยส่งแต่ละขั้นตอนไปให้ Grok 4.20 ช่วยจัดการต่อ

เขียนโค้ดและองค์ประกอบรอบตัวงานหลัก

ชุดทดสอบ, คิวรี, การตรวจทานโค้ด และเอกสารกำกับ มักเป็นสิ่งที่ถูกมองข้ามเมื่อกำหนดส่งงานใกล้เข้ามา

เขียนเทสต์สำหรับ edge cases ที่คุณอาจมองข้าม

ขอรายการกรณีทดสอบ (edge cases) ก่อน แล้วค่อยขอโค้ดสำหรับรันเทสต์ เพราะคุณค่าที่แท้จริงอยู่ที่ตัวรายการเหล่านั้น

นี่คือฟังก์ชัน [ภาษา]: [วางฟังก์ชัน] ขั้นแรก ช่วยระบุ edge cases ที่คุ้มค่าแก่การทดสอบ เช่น ข้อมูลว่าง (empty input), ค่าขอบเขตต่างๆ (boundaries) และประเภทข้อมูลที่ไม่ถูกต้อง พร้อมเหตุผลสั้นๆ หนึ่งบรรทัดสำหรับแต่ละกรณี จากนั้นเขียนชุดทดสอบโดยใช้ [test framework] แยกหนึ่งเทสต์ต่อหนึ่งกรณี และตั้งชื่อให้อ่านเข้าใจง่าย

สร้างชุดทดสอบ นำไปรัน และเลือกเก็บชุดทดสอบที่เฟลด้วยเหตุผลที่ถูกต้องไว้

ขอ code review สไตล์ซีเนียร์สุดเฮี้ยบ

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

ช่วยรีวิว diff นี้แบบซีเนียร์เอนจิเนียร์ที่เข้มงวดแต่ยุติธรรม ชี้จุดที่เป็นบั๊ก, ชื่อตัวแปรที่ไม่ชัดเจน, จุดที่ขาด error handling และสิ่งที่จะสร้างปัญหาในอีก 6 เดือนข้างหน้า โดยระบุเลขบรรทัดและวิธีแก้ไขที่แนะนำ เรียงลำดับปัญหาตามความร้ายแรง และไม่ต้องพูดถึงเรื่องสไตล์โค้ดเล็กๆ น้อยๆ: [วาง diff]

ขอรับการรีวิว ก่อนที่จะส่งให้เพื่อนร่วมทีมของคุณตรวจ

แปลง schema ให้เป็น SQL และ README

ระบุโครงสร้างตารางและสิ่งที่ต้องการค้นหาด้วยภาษาทั่วไป พร้อมขอคำอธิบายสั้นๆ ควบคู่ไปกับคำสั่งคิวรี

นี่คือโครงสร้างตารางสำหรับ [ฐานข้อมูล เช่น PostgreSQL]: [วาง schema] ช่วยเขียนคิวรีเพื่อ [อธิบายสิ่งที่คุณต้องการด้วยภาษาทั่วไป] อธิบายการ join และเงื่อนไข filter แต่ละจุดสั้นๆ ในหนึ่งบรรทัด และบอกด้วยว่าควรสร้าง index ตรงไหนเพื่อรองรับข้อมูลระดับหลายล้านแถว

เขียนคำสั่งคิวรี จากนั้นสามารถขอให้เขียนเอกสารสรุปรายละเอียดตารางสำหรับ README ต่อได้ทันที

ข้อควรระวัง

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

หน้าที่เกี่ยวข้อง

• พบกับ 20 แนวทางเริ่มต้นเพิ่มเติมได้ที่ พรอมต์สำหรับการเขียนโค้ด
• คู่มือแนะนำ การเขียนโค้ดด้วย Grok และบทความอธิบาย โมเดลสายคิดวิเคราะห์ (reasoning models)
• กำลังพัฒนาแอปพลิเคชันของคุณเองอยู่ใช่ไหม? ศึกษาข้อมูลเกี่ยวกับ Grok API ได้ที่นี่