30 พรอมต์ Claude สำหรับเขียนโค้ดที่นักพัฒนาใช้ซ้ำได้จริง

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

นี่คือ 30 พรอมต์ที่นักพัฒนานำกลับมาใช้ได้ แบ่งเป็นหก workflow แต่ละข้อกำหนดรูปแบบคำตอบ เช่น สาเหตุหลัก ปัญหาเรียงตามความสำคัญ แผนทดสอบ หรือข้อควรทราบในการย้ายระบบ จึงตรวจคำตอบได้ง่าย สำหรับงานนอกสายวิศวกรรม รายการ พรอมต์ Claude แนะนำครอบคลุมการเขียน การค้นคว้า และงานประจำวัน

Claude มักทำได้ดีเมื่อพรอมต์ขอให้คิดทีละขั้น ยึดโค้ดเดิม ส่งคำตอบเป็นโครงสร้างที่ตรวจได้เร็ว และแยกข้อเท็จจริงจากการคาดเดาเมื่อข้อมูลไม่ชัดเจน พรอมต์เหล่านี้จึงละเอียดกว่า “แก้โค้ดนี้” เพราะคำสั่ง ข้อจำกัด และรูปแบบคำตอบที่ชัดเจนเป็นหัวใจของ prompt engineering และยิ่งสำคัญสำหรับงานโค้ด

คุณวางพรอมต์เหล่านี้ใน แชตบอต AIที่รองรับ Claude ได้ Claude Sonnet 5เป็นตัวเลือกที่แข็งแกร่งสำหรับดีบักหลายไฟล์และออกแบบระบบ ส่วน Claude Sonnet 4.6เหมาะกับรีวิวและรีแฟกเตอร์ทั่วไป และ Claude Haiku 4.5ตอบเร็วสำหรับคำอธิบาย docstring และการแก้ไขเล็ก ๆ

การดีบักด้วย AI มักผิดพลาดเมื่อโมเดลเขียนใหม่มากเกินไปเร็วเกินไป พรอมต์เหล่านี้ให้ Claude วินิจฉัยก่อน แล้วแก้ด้วยการเปลี่ยนแปลงที่เล็กที่สุด

1. ดีบักฟังก์ชันโดยไม่เขียนใหม่ทั้งหมด

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

2. อ่าน stack trace

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

3. ตั้งสมมติฐานสำหรับบั๊กที่เกิดบางครั้ง

ฉันมีบั๊กที่เกิดบางครั้ง: [อาการ ความถี่ สภาพแวดล้อม] ระบุห้าสาเหตุที่เป็นไปได้ เช่น race condition, caching, timing, shared state หรือบริการภายนอก เรียงตามโอกาสจากข้อมูล และให้วิธียืนยันหรือตัดแต่ละสาเหตุออกอย่างรวดเร็ว แยกสิ่งที่หลักฐานสนับสนุนจากสิ่งที่คาดเดา โค้ด: [วาง]

4. เพิ่ม log เพื่อแยกปัญหา

ฉันทำให้บั๊กเกิดซ้ำในเครื่องไม่ได้ แนะนำ log หรือ metric ชุดเล็กที่สุดที่ควรเพิ่ม เพื่อให้เมื่อเกิดครั้งหน้าใน [staging / production] รู้จุดที่ล้มเหลวแน่นอน อธิบายว่า log แต่ละบรรทัดบอกอะไร ห้ามบันทึกข้อมูลลับหรือข้อมูลส่วนบุคคล โค้ด: [วาง] อาการ: [อธิบาย]

5. สร้างตัวอย่างปัญหาขั้นต่ำ

ช่วยแปลงรายงานบั๊กเป็นตัวอย่างขั้นต่ำที่รันได้ด้วยตนเอง ตัดส่วนไม่เกี่ยวข้อง เหลือโค้ดและข้อมูลที่ทำให้เกิดปัญหา และให้ขั้นตอนรัน หากขึ้นกับสิ่งที่มองไม่เห็น ให้ระบุและเสนอวิธีใช้ stub แทน รายงาน: [วาง] โค้ดที่เกี่ยวข้อง: [วาง]

การดีบักหลายไฟล์เป็นเวลานานต้องเก็บบริบทมากขึ้น โมเดลขนาดใหญ่ช่วยได้ บทแนะนำ Claude Opus 4.8อธิบายว่าเมื่อใดการวิเคราะห์ที่ลึกขึ้นจึงคุ้มค่า

ใช้เมื่อต้องการให้ Claude เป็นผู้รีวิวที่เข้มงวด ให้ความเห็นเฉพาะเจาะจง จัดลำดับความสำคัญ และตรงไปตรงมา

6. รีวิวเหมือนวิศวกรอาวุโสที่เข้มงวด

เป็นวิศวกรอาวุโสที่รีวิวโค้ดก่อน merge ตรวจความถูกต้อง ความอ่านง่าย การดูแล ประสิทธิภาพ กรณีขอบเขต ความปลอดภัย และการเปลี่ยนพฤติกรรมที่ซ่อนอยู่ ให้ความเห็นเฉพาะเจาะจง ไม่ให้คำแนะนำทั่วไป และชมเฉพาะสิ่งที่ทำดีจริง ส่งคำตอบ: ปัญหาวิกฤต ความเสี่ยงกลาง การปรับปรุงลำดับต่ำ การแก้โค้ด และข้อสรุป (อนุมัติ / ขอแก้ไข) โค้ด: [วาง] ภาษา/เฟรมเวิร์ก: [ระบุ] หน้าที่: [ระบุ] ข้อจำกัด: [ระบุ]

7. ค้นหาความเสี่ยงด้านความปลอดภัย

เป็นวิศวกรแอปที่ใส่ใจความปลอดภัย ตรวจโค้ดหรือการออกแบบเพื่อหาช่องว่างยืนยันตัวตนและสิทธิ์ injection อินพุตไม่ปลอดภัย ข้อมูลลับรั่ว ค่าเริ่มต้นไม่ปลอดภัย การจัดการไฟล์และพาธ ข้อมูลรั่ว และการยกระดับสิทธิ์ จัดระดับสูง กลาง ต่ำ อธิบายผลจริง แสดงวิธีแก้ และรายการทดสอบด้วยมือ หลีกเลี่ยงคำกว้าง ๆ เช่น ‘ทำตาม best practice’ โค้ดหรือ flow: [วาง] สภาพแวดล้อม: [public API / เครื่องมือภายใน / admin dashboard / mobile backend]

8. ตรวจ pull request ตามข้อกำหนด

นี่คือ ticket และ diff ที่ควรใช้ทำงานตาม ticket บอกว่าครบข้อกำหนดหรือไม่ อะไรขาด อะไรเปลี่ยนโดยไม่ได้ขอ และส่วนใดเสี่ยงที่สุด Ticket: [วาง] Diff: [วาง]

9. รีวิวการจัดการข้อผิดพลาด

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

10. ตรวจ concurrency และ race condition

วิเคราะห์ shared mutable state, race condition, deadlock, lock หรือ transaction ที่ขาด และสมมติฐานเรื่องลำดับที่ไม่ปลอดภัย อธิบายแต่ละความเสี่ยงด้วยเหตุการณ์เรียงลำดับที่ทำให้เกิด แล้วเสนอวิธีแก้ง่ายที่สุด โค้ด: [วาง] Runtime: [threads / async / หลาย worker / distributed]

ต้องการพรอมต์สำหรับ pull request ที่ลึกขึ้นไหม? พรอมต์ Claude สำหรับรีวิวโค้ดครอบคลุมสไตล์ สถาปัตยกรรม และ feedback จากผู้รีวิวถึงผู้เขียนอย่างละเอียด

AI อาจเปลี่ยนพฤติกรรมโดยไม่รู้ตัวระหว่างรีแฟกเตอร์หรือเพิ่มประสิทธิภาพ พรอมต์เหล่านี้รักษาข้อตกลงภายนอกและให้ Claude อธิบายทุกข้อแลกเปลี่ยน

11. รีแฟกเตอร์ให้อ่านง่ายโดยคงพฤติกรรม

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

12. ปรับประสิทธิภาพโดยพิจารณาข้อแลกเปลี่ยน

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

13. แยกฟังก์ชันหรือโมดูลใหญ่

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

14. ลบ dead code อย่างปลอดภัย

ช่วยหาโค้ดที่น่าจะไม่ใช้หรือล้าสมัย เช่น branch เข้าไม่ถึง parameter ไม่ใช้ flag เก่า และ helper ซ้ำ แต่ละรายการบอกเหตุผล ระดับความมั่นใจ และวิธียืนยันก่อนลบ โค้ด: [วาง] ผู้เรียกหรือ entry point ที่ทราบ: [ระบุ]

15. ปรับ query ฐานข้อมูลที่ช้า

query นี้ช้า: [วาง] schema, index และขนาดตารางโดยประมาณ: [วาง] อธิบายว่าฐานข้อมูลน่าจะทำอะไร แนะนำ index หรือการเปลี่ยน query และแสดง query ใหม่ บอกวิธีตรวจผลด้วย [EXPLAIN / EXPLAIN ANALYZE / query plan ของฐานข้อมูล] และชี้การเปลี่ยนที่อาจกระทบการเขียนหรือ query อื่น

หากทำงานกับโครงสร้างที่เกินกว่าไฟล์เดียว พรอมต์ Claude สำหรับวิศวกรรมซอฟต์แวร์ครอบคลุมสถาปัตยกรรม หนี้ทางเทคนิค และการออกแบบระบบ

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

16. สร้าง unit test ที่มีคุณค่า

เป็นวิศวกรที่เน้นเทสต์ เขียน unit test ด้วย [pytest / jest / JUnit / เฟรมเวิร์กอื่น] ครอบคลุมพฤติกรรมหลัก กรณีขอบเขต อินพุตผิด เงื่อนไขบริเวณขอบ และ regression ที่น่าจะเกิดอย่างน้อยหนึ่งข้อ พร้อมเหตุผลสั้น ๆ อย่าสร้างพฤติกรรมที่โค้ดไม่บ่งชี้ และชี้ความกำกวม ส่งคำตอบ: แผน โค้ดเทสต์ และช่องว่างหรือความกำกวม โค้ด: [วาง] หน้าที่: [อธิบาย]

17. สร้าง regression test จากรายงานบั๊ก

นี่คือรายงานและวิธีแก้ เขียนเทสต์ที่ไม่ผ่านกับโค้ดเก่าและผ่านกับโค้ดใหม่ ตั้งชื่อให้ผู้พัฒนาคนต่อไปเข้าใจว่าป้องกันอะไร และเสนอหนึ่งหรือสองกรณีใกล้เคียง รายงาน: [วาง] โค้ดเก่า: [วาง] โค้ดใหม่: [วาง]

18. วางแผน integration test

ออกแบบแผนสำหรับ [ฟีเจอร์และบริการที่เกี่ยวข้อง] ระบุ flow หลัก dependency ที่รันจริงหรือ mock ข้อมูลเทสต์ และเหตุการณ์ล้มเหลว เช่น timeout ล้มเหลวบางส่วน หรือ response ผิด ทำให้เหมาะกับทีมที่รันเทสต์ใน CI ทุก pull request

19. สร้าง mock และ fixture

สร้าง fixture และ mock ที่ใช้ซ้ำได้สำหรับ dependency ของโค้ดนี้: [วาง] ใช้ [เฟรมเวิร์กเทสต์และไลบรารี mock] ให้ fixture เล็กและอ่านง่าย แสดงเทสต์ตัวอย่างหนึ่งข้อ และชี้ dependency ที่ควรทดสอบด้วย instance จริง

20. ตรวจชุดเทสต์เดิม

รีวิวเทสต์กับโค้ดนี้ บอกพฤติกรรมสำคัญที่ยังไม่ทดสอบ เทสต์เปราะบางหรือผูกกับรายละเอียดการทำงาน assertion ที่อ่อนเกินจับบั๊ก และสิ่งที่ควรเพิ่มหรือลบก่อน เทสต์: [วาง] โค้ดที่ทดสอบ: [วาง]

อยากเปรียบเทียบวิธีของโมเดลอื่นไหม? พรอมต์ ChatGPT สำหรับเขียนโค้ดช่วยให้เทียบคำตอบของงานเดียวกันได้ง่าย

Claude ทำได้ดีเมื่ออธิบายชัดเจนและแยกข้อเท็จจริงจากการคาดเดา ใช้กับการเริ่มงานในโปรเจกต์ โค้ดเก่า และเอกสารที่ยังไม่มีเวลาเขียน

21. อธิบายโค้ดเก่าโดยไม่แต่งข้อมูล

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

22. เขียน docstring และ comment

เพิ่ม docstring และ comment ตาม [สไตล์ เช่น Google / NumPy / JSDoc] อธิบาย parameter ค่าคืน error และ side effect เพิ่ม comment เฉพาะจุดที่ไม่ชัด โดยอธิบายเหตุผลแทนการทวนสิ่งที่ทำ และห้ามเปลี่ยนตรรกะ โค้ด: [วาง]

23. เขียน README ของโมดูล

เขียน README สำหรับนักพัฒนาที่ไม่เคยเห็นโมดูลนี้ รวมหน้าที่ เวลาที่ควรใช้ วิธีติดตั้งหรือ import ตัวอย่างสั้น ตัวเลือกตั้งค่า และข้อจำกัด เขียนกระชับ ใช้เฉพาะข้อเท็จจริงที่เห็นจากโค้ด โค้ด: [วาง]

24. อธิบาย expression ซับซ้อน

อธิบาย [regular expression / SQL query / one-liner / type definition] ทีละส่วนด้วยคำง่าย ๆ ยกตัวอย่างสองกรณีที่ตรงหรือรองรับ และสองกรณีที่ไม่ พร้อมเวอร์ชันอ่านง่ายกว่าหากมี Expression: [วาง]

25. สำรวจ repository ที่ไม่คุ้น

นี่คือโครงสร้างโฟลเดอร์และไฟล์สำคัญของ repository ที่เพิ่งเข้าร่วม: [วาง] อธิบายการจัดโปรเจกต์ entry point flow ของ request หรือ job และห้าไฟล์ที่ควรอ่านก่อน ระบุสิ่งที่อนุมานแทนการเห็นโดยตรง

ไม่แน่ใจว่าโมเดลไหนเหมาะกับงานของคุณ? บทเปรียบเทียบ Claude กับ ChatGPTอธิบายการให้คำอธิบาย การใช้เหตุผล และการทำงานกับโค้ดของทั้งสอง

โค้ดที่ดีเริ่มก่อนบรรทัดแรก พรอมต์เหล่านี้ให้ Claude คิดเหมือนหัวหน้าทีมเทคนิคที่เน้นใช้งานจริง: ทบทวนโจทย์ ชั่งน้ำหนักทางเลือก และชี้จุดที่ยังไม่ชัดเจน

26. ออกแบบก่อนเขียนโค้ด

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

27. ย้ายระหว่างเฟรมเวิร์กหรือเวอร์ชัน

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

28. เปลี่ยนโน้ตเป็นแผนลงมือทำ

แปลงโน้ตเป็นแผนที่มีสรุปชัด สมมติฐาน คำถามค้าง ขอบเขต ขั้นตอนตามลำดับ ความเสี่ยง กรณีขอบเขต แผนเทสต์ และแบ่ง ticket อย่าเติมช่องว่างด้วยความมั่นใจเทียม ระบุข้อกำหนดไม่ชัด และเขียนให้นักพัฒนาที่ต้องทำจริง โน้ต: [วาง]

29. รีวิวการออกแบบ API

รีวิวก่อนสร้าง: [endpoint และรูปแบบ request/response] ตรวจชื่อสอดคล้อง รูปแบบ error pagination versioning idempotency และ backward compatibility ชี้จุดที่แก้ยากเมื่อ client พึ่งพาแล้ว และเสนอการออกแบบใหม่

30. ออกแบบ schema ฐานข้อมูล

ออกแบบสำหรับ [ฟีเจอร์และ entity หลัก] ด้วย [ฐานข้อมูล] เสนอตารางหรือ collection, key, relationship และ index อธิบายการรองรับ query ทั่วไปและข้อแลกเปลี่ยน ระบุสมมติฐานเกี่ยวกับปริมาณข้อมูลและรูปแบบเข้าถึงที่อาจเปลี่ยนการออกแบบ

เลือกเครื่องมือสำหรับโปรเจกต์ใหญ่? คู่มือ AI ที่เหมาะสำหรับเขียนโค้ดเปรียบเทียบผู้ช่วยสำหรับงานทั้ง repository การเติมโค้ดอัตโนมัติ และการเขียนโค้ดด้วย agent

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

Chat Smith รวมโมเดล Claude ล่าสุดกับ GPT, Gemini, DeepSeek และ Grok ในแอปเดียว คุณส่งพรอมต์เดียวกันให้ โมเดล AI หลายตัวแล้วเทียบคำอธิบายได้ เหมาะกับการขอความเห็นเพิ่มเติมสำหรับบั๊กยากหรือการรีวิว สำหรับงานทั้ง repository ใช้ร่วมกับ coding agent เฉพาะทาง และ พรอมต์ ChatGPT สำหรับนักพัฒนาเป็นขั้นต่อไปที่เหมาะหากใช้ทั้งสองตระกูลโมเดล