ผู้ช่วย Refactor โค้ดเก่า

ข้อมูลที่ต้องเตรียม

หัวข้อ “ข้อมูลที่ต้องขอ” ระบุไว้ว่าจะขออะไรจากคุณ ถ้ายังไม่มี AI จะถามกลับก่อน

ระดับความพร้อม: ต้องเตรียมข้อมูลก่อน

ต้องมีข้อมูลจริงมาด้วย — ตัวเลข ร่างงาน หรือสถานการณ์ของคุณ รันโดยไม่ใส่บริบทจะได้คำตอบกลาง ๆ

เครื่องมือและภาษา

ใช้ได้กับผู้ช่วย AI ทุกตัวที่รับข้อความยาว ไม่ต้องติดตั้งอะไรเพิ่ม ไฟล์เป็นภาษาอังกฤษอย่างเดียว คุยต่อเป็นไทยได้ แต่อย่าแปลตัวไฟล์

ใครควรใช้

นักพัฒนา QA Engineer นอกกลุ่มนี้ควรใช้ผลเป็นจุดตั้งต้น ไม่ใช่คำตอบสุดท้าย

กรอบงานที่วางไว้ให้ AI

ไม่ประกาศบทบาท แต่วางกรอบงานทันทีในบริบทของตรวจสอบและแก้บั๊ก เหมาะกับงานที่โจทย์ชัดอยู่แล้ว

โครงสร้างของคำสั่ง ทีละส่วน

เปิดไฟล์แล้วจะเจอหัวข้อเหล่านี้เรียงกันอยู่

• ข้อมูลที่ต้องขอ — เก็บข้อมูลที่ AI ไม่มีทางเดาเองได้
• วิธีการ (รักษาพฤติกรรมเดิม) — กำหนดลำดับการคิดให้เป็นขั้นเป็นตอน (แบ่งเป็น 4 ขั้น)
• กติกาความปลอดภัย / ห้ามกุข้อมูล — บังคับให้ AI ยอมรับเมื่อไม่รู้ แทนที่จะเดา (3 ข้อย่อย)
• รูปแบบผลลัพธ์ — ล็อกหน้าตาของผลลัพธ์ (แบ่งเป็น 4 ขั้น)

ทำไมถึงได้ผลนิ่งกว่าการพิมพ์ถามเอง

เทียบกับการพิมพ์ถามสั้น ๆ คำสั่งนี้ตัดโอกาสที่ AI จะเดาออกทีละจุด

• มีส่วน “ข้อมูลที่ต้องขอ” ระบุไว้ชัด AI จึงถามกลับแทนที่จะเดา
• ล็อกลำดับการทำงานไว้ 8 ขั้น ผลจึงเป็นระเบียบเดิมทุกครั้ง
• กำหนดรูปแบบผลลัพธ์ไว้ล่วงหน้า นำไปใช้ต่อได้เลย ไม่ต้องจัดรูปแบบใหม่
• มีกติกาห้ามกุข้อมูลเขียนไว้ตรง ๆ ลดการแต่งตัวเลขและแหล่งอ้างอิง
• ตัวแปร 5 จุด ปรับไปใช้กับงานของคุณได้โดยไม่ต้องเขียนใหม่

Guardrails มาตรฐานที่ติดมาด้วย

ท้ายไฟล์มีบล็อก Guardrails มาตรฐาน — กรอกตัวแปรให้ครบ บอกตรง ๆ เมื่อข้อมูลไม่พอ และคุมโทนให้อยู่ในกรอบ

ขั้นที่ 1 — เปิดไฟล์และเลือกเครื่องมือ

วางเนื้อหาไฟล์เป็นข้อความแรกของแชทใหม่ อย่าต่อท้ายบทสนทนาเดิม เพราะบริบทเก่าจะรบกวนกติกาในไฟล์ ใช้ได้ทั้ง ChatGPT, Claude และ Gemini

ขั้นที่ 2 — แทนค่าในวงเล็บทั้ง 5 จุด

มีช่องในวงเล็บ 5 จุด แต่ละจุดคือข้อมูลที่ AI เดาแทนคุณไม่ได้ ปล่อยไว้ตามเดิมจะได้คำตอบกลาง ๆ

ขั้นที่ 3 — รันและอ่านผล

AI จะรับบทเป็น Strict Code Reviewer แล้วเดินตามหัวข้อ “วิธีการ (รักษาพฤติกรรมเดิม)” ทีละขั้น ถ้าข้อมูลไม่ครบ AI จะถามกลับก่อน — นั่นคือคำสั่งทำงานถูกต้อง ไม่ใช่ข้อผิดพลาด

แก้ตรงไหนเมื่อผลลัพธ์ไม่ตรงใจ

แต่ละหัวข้อคุมพฤติกรรมคนละอย่าง แก้ทีละหัวข้อแล้วรันใหม่ ถ้ารื้อพร้อมกันหลายจุด จะไม่รู้ว่าอะไรได้ผล

ตัวแปรที่ต้องกรอกก่อนใช้งาน

แทนช่องในวงเล็บด้วยข้อมูลของคุณ ยิ่งเจาะจงยิ่งใช้ได้จริง

• [โค้ด]
• [ภาษา + เวอร์ชัน]
• [มันทำอะไร / สัญญาของมันคืออะไร]
• [มีเทสต์หรือไม่ ถ้าไม่มี นั่นคือเรื่องที่ต้องจัดการก่อน]
• [ข้อจำกัด: ห้ามเปลี่ยน public API, ข้อจำกัดด้านประสิทธิภาพ]

ปรับความเข้มของข้อกำหนด

ปรับข้อกำหนดต่อจากตัวแปร แก้ทีละอย่าง ไม่งั้นจะไม่รู้ว่าอันไหนได้ผล

• แก้หัวข้อ “รูปแบบผลลัพธ์” เพื่อเปลี่ยนหน้าตาผลลัพธ์ เช่น เปลี่ยนเป็นตาราง หรือกำหนดความยาว
• ระบุกลุ่มผู้อ่านให้แคบลง เช่น จาก “ลูกค้าทั่วไป” เป็น “เจ้าของร้านอายุ 30–45 ปีที่ไม่ถนัดศัพท์เทคนิค”
• เติมบรรทัดกำหนดโทนเอง เช่น “เขียนแบบเป็นกันเอง ไม่ใช้ศัพท์เทคนิค” — ไฟล์นี้ยังไม่ล็อกโทนไว้

คำสั่งนี้ต้องเตรียมข้อมูลก่อน

กรอกทุกวงเล็บให้ครบก่อนส่ง ส่งทั้งที่ยังว่างจะได้ผลกลาง ๆ ที่ต้องมาแก้อยู่ดี

ต่อเป็น Workflow หลายขั้น

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

หน้าตาของคำตอบ

หัวข้อ “รูปแบบผลลัพธ์” ล็อกรูปแบบไว้ ผลจึงมีโครงเดิมทุกครั้ง

• คืน characterization test โค้ดที่ refactor และบันทึกการเปลี่ยน

สิ่งที่คำสั่งนี้จะไม่ทำ

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

• “กติกาความปลอดภัย / ห้ามกุข้อมูล” บังคับให้ AI ยอมรับเมื่อข้อมูลไม่พอ แทนที่จะแต่งขึ้นเอง
• ท้ายไฟล์มีกติกามาตรฐาน — ไม่กุข้อมูล ไม่แทนผู้เชี่ยวชาญ และบอกขอบเขตของตัวเอง

วิธีดูว่ารอบนี้ได้ผลดีหรือยัง

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