ใช้ GitHub Copilot ให้คุ้ม: 6 เทคนิคเขียน Prompt และรีวิวโค้ด AI ก่อน Merge

GitHub Copilot ช่วยให้การเขียนโค้ดเร็วขึ้นอย่างมาก แต่ปัญหาที่หลายคนเจอคือได้โค้ดที่ "พอใช้งานได้" โดยไม่แน่ใจว่าเหตุผลเบื้องหลังคืออะไร หรือโค้ดนั้นปลอดภัยและเหมาะกับระบบจริงหรือไม่

ถ้าต้องการใช้ Copilot ให้เป็นผู้ช่วยที่มีประสิทธิภาพจริง สิ่งสำคัญคือการ "คุมทิศทาง" ด้วย prompt ที่ชัดเจน และตามด้วยการรีวิวโค้ดอย่างมีหลักการก่อนนำขึ้นระบบ

ทำไมการเขียน Prompt จึงสำคัญ

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

ดังนั้น การเขียน prompt ที่ดีจึงไม่ได้มีหน้าที่แค่สั่งงาน แต่ต้องช่วยกำหนดกรอบ วิธีคิด และข้อจำกัดให้ชัดเจน

6 เทคนิคเขียน Prompt ให้ Copilot ทำงานได้ตรงเป้า

1) บอกบริบทให้ครบก่อนสั่งงาน

Copilot จะทำงานได้ดีขึ้นมากเมื่อรู้ว่าโค้ดชิ้นนั้นอยู่ในบริบทแบบไหน เช่น เป็นไฟล์ประเภทใด ใช้ framework อะไร และมีข้อจำกัดใดบ้าง

ตัวอย่างข้อมูลที่ควรระบุ:

• เป็น Next.js API route
• ใช้ TypeScript
• ต้องมีการตรวจสอบ input
• ห้ามเพิ่ม dependency ใหม่

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

2) สั่งรูปแบบผลลัพธ์ให้ชัด

แทนที่จะบอกเพียงว่า "ช่วยสร้างฟังก์ชันนี้" ควรระบุด้วยว่าต้องการผลลัพธ์ในรูปแบบใด เช่น

• ชนิดข้อมูลที่คืนกลับ
• แนวทางจัดการ error
• รูปแบบการตั้งชื่อ
• pattern ที่ทีมใช้อยู่

ตัวอย่างเช่น:

• return Result<T, E>
• throw HttpError พร้อม status code
• ใช้ชื่อฟังก์ชันและตัวแปรตาม convention ของทีม

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

3) ใส่ตัวอย่าง input/output เพื่อป้องกันการตีความผิด

Copilot มักตีความ requirement จากชื่อฟังก์ชันหรือคำสั่งแบบกว้างๆ ซึ่งอาจคลาดเคลื่อนได้ง่าย การใส่ตัวอย่าง input/output 2-3 เคสจะช่วยล็อกทิศทางได้ดีมาก

ตัวอย่าง:

• input: " Foo-Bar "
• output: "foo_bar"
• และต้องลบอักขระพิเศษออก

วิธีนี้ช่วยลดความคลุมเครือ และทำให้ Copilot เข้าใจทั้งพฤติกรรมหลักและ edge case ได้ดีขึ้น

4) ระบุข้อห้ามด้านความปลอดภัยใน Prompt

โค้ดจาก AI อาจเผลอสร้างแนวทางที่เสี่ยงโดยไม่ได้ตั้งใจ เช่น

• log token หรือข้อมูลสำคัญ
• ใช้ crypto ที่ไม่ปลอดภัย
• สร้าง SQL ด้วย string concatenation
• ใช้ eval

จึงควรระบุกติกาให้ชัดใน prompt เช่น:

• ห้ามใช้ eval
• ห้ามสร้าง SQL ด้วย string concat
• ห้าม log ข้อมูล PII
• ต้องใช้ parameterized query

การบอกข้อห้ามไว้ตั้งแต่ต้น ช่วยลดความเสี่ยงได้มากกว่าการมานั่งแก้ทีหลัง

5) แตกงานให้เล็กและให้ช่วยทีละชั้น

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

• ออกแบบ type และ interface
• สร้าง schema validation
• เขียน core logic
• เขียน tests

แนวทางนี้ช่วยให้แต่ละส่วนมีขอบเขตชัดเจน ลดโอกาสที่โค้ดจะมั่ว และทำให้การรีวิวมีประสิทธิภาพมากขึ้น

6) ให้สร้าง Tests ก่อนเขียน Implementation

อีกเทคนิคที่มีประโยชน์มากคือให้ Copilot ช่วยเขียน test cases จาก requirement ก่อน แล้วค่อยให้เขียน implementation ตาม test เหล่านั้น

ข้อดีของวิธีนี้คือ:

• ช่วยกัน requirement หลุด
• ลด bug เงียบๆ
• บังคับให้คิดถึง edge cases ตั้งแต่ต้น
• ทำให้เห็นความคาดหวังของระบบอย่างชัดเจน

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

ตัวอย่าง Prompt ที่นำไปใช้ได้ทันที

ตัวอย่าง prompt:

Write a TypeScript function normalizeSlug(input) with these rules:
- trim, lowercase
- replace spaces and hyphens with underscore
- keep only a-z0-9_
- if empty after normalize, return "untitled"
Also generate Jest tests for at least 8 cases including unicode and empty string.

จุดเด่นของ prompt นี้คือระบุครบทั้ง:

• ภาษาและบริบท
• กติกาการทำงาน
• เงื่อนไขกรณีพิเศษ
• จำนวนและประเภทของ test cases

จึงมีโอกาสสูงที่จะได้ผลลัพธ์ที่นำไปใช้จริงได้ทันที

เช็กลิสต์รีวิวโค้ดจาก Copilot ก่อน Merge

แม้ prompt จะดีเพียงใด โค้ดจาก AI ก็ยังต้องผ่านการตรวจสอบโดยคนเสมอ โดยเฉพาะก่อน merge เข้าสาขาหลักหรือก่อน deploy

1) อ่าน logic ให้ครบ ไม่ดูแค่ diff สวยๆ

อย่าตัดสินจากความเรียบร้อยของโค้ดหรือความสั้นกระชับเพียงอย่างเดียว ต้องอ่านให้เข้าใจว่า logic ที่เขียนมาทำงานตรงตาม requirement จริงหรือไม่

2) ตรวจสอบ input validation

ดูว่าโค้ดรองรับกรณีเหล่านี้ครบหรือยัง:

• null
• undefined
• ค่าขอบเขต
• unicode
• รูปแบบข้อมูลผิดประเภท

หลาย bug มักเกิดจาก input ที่ไม่อยู่ใน happy path

3) ตรวจสอบ error handling

ควรดูว่าโค้ดมีการ fail fast หรือไม่ และข้อความ error มีข้อมูลที่ไม่ควรเปิดเผยหลุดออกมาหรือเปล่า เช่น stack trace ภายใน หรือรายละเอียดระบบที่มากเกินจำเป็น

4) ตรวจสอบด้านความปลอดภัย

ประเด็นที่ควรเฝ้าระวัง เช่น:

• injection
• path traversal
• SSRF
• deserialization ที่ไม่ปลอดภัย

โค้ดที่ดูเหมือนทำงานได้ดี อาจซ่อนช่องโหว่สำคัญไว้ในรายละเอียดเล็กๆ

5) ตรวจสอบประสิทธิภาพ

Copilot อาจเขียนโค้ดที่ถูกต้องแต่ไม่เหมาะกับงานจริง เช่น:

• loop ซ้อนโดยไม่จำเป็น
• regex ที่หนักเกินไป
• query แบบ N+1

จึงควรดูทั้งความถูกต้องและความคุ้มค่าในการรันจริง

6) ตรวจสอบ dependencies และ API ที่เพิ่มเข้ามา

บางครั้ง AI อาจแนะนำ library ใหม่โดยไม่จำเป็น หรือเลือกใช้ API แปลกๆ ที่ทีมไม่ได้มาตรฐานไว้ก่อน ควรประเมินทุก dependency ที่ถูกเพิ่มเข้ามาว่าจำเป็นจริงหรือไม่

7) ตรวจสอบ concurrency และ async flow

หากเกี่ยวข้องกับงาน async หรือระบบที่มีการทำงานพร้อมกัน ควรระวังประเด็นต่อไปนี้:

• race condition
• การลืม await
• retry ที่ไม่มี backoff
• การจัดการ timeout ไม่เหมาะสม

ข้อผิดพลาดลักษณะนี้มักตรวจพบยากหากดูแค่ผลลัพธ์ในกรณีปกติ

8) ตรวจสอบ Tests ให้ครอบคลุม

ดูว่า tests ครอบคลุมทั้ง:

• happy path
• invalid input
• edge cases
• พฤติกรรมเมื่อเกิด error

ถ้า test ดี โอกาสที่โค้ดผิดแล้วหลุดเข้า production จะลดลงอย่างชัดเจน

ทริคเสริม: ให้ Copilot อธิบายข้อสมมติฐานและความเสี่ยง

อีกวิธีที่ช่วยได้มากคือสั่งให้ Copilot วิเคราะห์โค้ดของตัวเอง เช่น:

List assumptions and potential risks in this implementation.

คำสั่งลักษณะนี้มักช่วยเปิดเผยจุดเสี่ยงที่เราอาจมองข้าม เช่น:

• ปัญหา timezone
• encoding
• รูปแบบข้อมูลที่ไม่คงที่
• สมมติฐานเรื่องลำดับข้อมูล

แม้คำตอบจะยังต้องผ่านการกลั่นกรอง แต่ก็เป็นวิธีที่ดีในการใช้ AI ช่วยหา blind spot เพิ่มเติม

วิธีคิดที่ควรมีเมื่อใช้ Copilot

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

เปรียบเทียบง่ายๆ มันเหมือนนักศึกษาฝึกงานที่มีความสามารถสูง แต่ยังต้องมีคนคุมงาน คอยตั้งโจทย์ และคอยตรวจคุณภาพก่อนส่งมอบจริง

เมื่อใช้ด้วยวิธีคิดแบบนี้ เราจะไม่คาดหวังเกินจริง และสามารถดึงประโยชน์จาก AI ได้มากที่สุดโดยไม่ลดมาตรฐานงาน

สรุป

GitHub Copilot จะมีประโยชน์มากขึ้นทันทีเมื่อเราเขียน prompt อย่างมีโครงสร้าง ระบุบริบท รูปแบบผลลัพธ์ ตัวอย่าง input/output และข้อห้ามด้านความปลอดภัยให้ชัดเจน รวมถึงแบ่งงานเป็นส่วนเล็กๆ และใช้ tests เป็นตัวกำกับคุณภาพ

อย่างไรก็ตาม โค้ดจาก AI ไม่ควรถูก merge โดยไม่ผ่านการรีวิว การตรวจสอบด้าน logic, validation, security, performance, dependencies, concurrency และความครอบคลุมของ tests คือขั้นตอนที่จำเป็นเสมอ

หากเริ่มต้นจากฟังก์ชันเล็กๆ เพียงหนึ่งจุด แล้วทดลองใช้ 6 เทคนิคนี้ คุณจะเห็นได้ชัดว่าคุณภาพของโค้ดและความมั่นใจในการใช้งาน Copilot ดีขึ้นอย่างเป็นรูปธรรม