สรุปและแบบฝึกหัด
ประเด็นสำคัญ
- ให้บริบทก่อนให้โจทย์: ระบุสแตกเทคโนโลยี ธรรมเนียม และชิ้นส่วนที่มีอยู่แล้วที่ควรนำมาใช้ซ้ำ — หรือวาง signature จริงที่โค้ดต้องเข้ากันได้
- นิยามขอบเขต: อินพุต เอาต์พุต และกรณีขอบ พฤติกรรมที่น่าสนใจของซอฟต์แวร์อยู่ที่ขอบของมัน ดังนั้นจงใช้คำของคุณตรงนั้น
- ทำงานเป็นขั้นตอนเล็ก ๆ ที่ตรวจสอบได้ และขอแผนก่อนขอโค้ด เพราะการแก้แผนถูกกว่าการแก้ มาก
- แก้ทีละส่วน (diff) ที่ตรงจุด ไม่ใช่เขียนใหม่ทั้งหมด และใช้ตัวอย่างที่เป็นรูปธรรม (ในรูปแบบเทสต์ยิ่งดี) เพื่อตรึงสิ่งที่คำพูดยังคลุมเครือ
- จัดการหน้าต่างบริบทเหมือนทรัพยากรอย่างหนึ่ง และบอกว่าอะไรไม่ควรทำ — ข้อจำกัดเชิงลบที่ชัดเจนช่วยให้ผลลัพธ์กระชับ
ลองทำดู
หยิบคำขอสั้น ๆ คลุมเครือที่คุณอาจพิมพ์ตามปกติ ("เพิ่มการค้นหาให้ลิสต์หน่อย") แล้วเขียนมันใหม่เป็นพรอมต์แบบวิศวกรก่อนส่งอะไรออกไป เพิ่มบริบท (สแตก ไฟล์ที่เกี่ยวข้อง) อินพุต/เอาต์พุต กรณีขอบสองสามข้อ ตัวอย่างผลลัพธ์ที่ต้องการหนึ่งตัวอย่าง และข้อจำกัดเชิงลบหนึ่งข้อ (อะไรที่ไม่ควรแตะ) ส่งเวอร์ชันที่เขียนใหม่แล้วเปรียบเทียบกับสิ่งที่เวอร์ชันขี้เกียจจะให้ผลลัพธ์ออกมา ทำแบบนี้กับคำขอจริงสามครั้ง แล้วการอัปเกรดนี้จะกลายเป็นเรื่องอัตโนมัติ
พรอมต์ประจำบท
Context: <language + framework + version>, working in <file/module>.
We already <relevant existing pattern or library to reuse>.
Task: <one clear thing to build>.
Inputs / outputs: <types and shapes>.
Edge cases to handle: <list the ones that matter>.
Example: <one concrete input -> expected output>.
Constraints:
- No new dependencies — use <what we already have>.
- Touch only <this file>; don't refactor anything else.
- Keep existing names and signatures unchanged.
Before coding, give me a 3-4 line plan and wait for my "go".