เวลาสั่ง AI แก้บั๊ก เรามักหวังให้มันแก้ตรงจุดแบบเร็วๆ แต่ผล benchmark ล่าสุดกลับชี้ว่า AI ส่วนใหญ่ชอบแอบแก้โค้ดเกินคำสั่ง จนทำให้ Pull Request (PR) บวมเป็นร้อยบรรทัดจนทีมรีวิวไม่ไหว

นักวิจัยชื่อ nrehiew ทดลองวัดเรื่องนี้อย่างจริงจัง โดยนำโมเดล AI สายโค้ดดิ้งยอดนิยมมาเทียบกัน แล้วพบผลลัพธ์ที่น่าสนใจมาก Claude Opus แก้โค้ดน้อยที่สุดและแม่นยำที่สุดไปพร้อมกัน ขณะที่ GPT-5.4 แก้เกินเบอร์จนน่าตกใจ ที่สำคัญ มี prompt เพียงบรรทัดเดียวที่ช่วยลด diff โค้ดส่วนเกินลงได้กับแทบทุกโมเดล

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

สิ่งที่ต้องมีก่อนเริ่มทำตาม

บทความนี้เน้นเรื่อง prompt และ workflow จึงไม่ต้องติดตั้งอะไรยุ่งยาก ขอเพียงมีเครื่องมือพื้นฐานต่อไปนี้:

• เครื่องมือ AI coding ที่คุณใช้อยู่ประจำ (Claude Code, Cursor, ChatGPT หรือ Copilot)
• ติดตั้ง Git บนเครื่องเรียบร้อย (เพื่อนำคำสั่ง git add -p ไปใช้ใน workflow)
• โปรเจกต์จริงสักตัวที่คุณกำลังจะส่งให้ AI ช่วยแก้ไข

ทุกเทคนิคใช้งานผ่าน prompt และ workflow ตามปกติได้ทันที ใช้เวลาอ่านและทดลองเพียงไม่กี่นาทีก็เห็นผล

Over-editing คืออะไร ทำไมถึงเป็นเรื่องใหญ่

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

พูดภาษาชาวบ้านคือ AI ทำงานสำเร็จ แต่แอบแถมการแก้โค้ดส่วนอื่นที่คุณไม่ได้สั่งติดมาด้วย

ฟังเผินๆ เหมือนจะไม่มีพิษภัย เพราะบั๊กก็แก้ได้แล้วไม่ใช่หรือ แต่คนทำงานสาย vibe coding ตัวจริงจะรู้ดีว่ามันมีต้นทุนแฝงมหาศาลอยู่ 3 ข้อ:

1. รีวิวยากขึ้นหลายเท่า: diff 3 บรรทัดกับ diff 300 บรรทัดต้องใช้พลังงานสมองคนละเรื่อง หากทีมมีขั้นตอน code review จริง คนตรวจจะล้าและเสียเวลาโดยใช่เหตุ
2. เสี่ยงเกิดบั๊กใหม่ (Regression): ทุกบรรทัดที่ AI แก้เพิ่มคือความเสี่ยง การแก้บั๊กบรรทัดเดียวแทบไม่มีความเสี่ยง แต่ถ้า AI เผลอแก้ signature ของฟังก์ชัน ระบบส่วนอื่นที่เรียกใช้อาจพังทั้งแถบ
3. เปลือง context window ทั้งคนและ AI: diff ก้อนใหญ่กิน token สูง ทำให้ session ของ AI ตันเร็วขึ้น และทำให้คนทำงานเหนื่อยตามไปด้วย

เปรียบให้เห็นภาพ เหมือนคุณจ้างช่างมาซ่อมก๊อกน้ำรั่ว แต่พอกลับบ้านมาพบว่าช่างทาสีครัวใหม่ ย้ายตู้ และเปลี่ยนเคาน์เตอร์ให้เสร็จสรรพ แม้ก๊อกจะหายรั่วจริง แต่คุณคงตรวจงานไม่ไหว และถ้ามีท่อประปาแตกซ่อนอยู่ตรงไหน คุณแทบไม่มีทางรู้เลย

ตัวอย่างจริง บั๊ก 1 token แต่ AI รื้อทั้งฟังก์ชัน

nrehiew ยกเคสจริงที่ชวนปวดหัว เมื่อเขาสั่งให้ GPT-5.4 แก้ off-by-one bug สั้นๆ ตรงนี้:

range(len(x) - 1)

คำตอบที่ถูกต้องตามคำสั่งมีแค่:

range(len(x))

แค่ลบ - 1 ออกเพียง 1 token ก็เสร็จเรียบร้อย

แต่ GPT-5.4 กลับไม่หยุดแค่นั้น มันแถมทั้งการเช็ก None ดักแปลง array ผ่าน np.asarray ใส่ finite-value mask เพิ่ม validation ขนาด array เปลี่ยน signature ของฟังก์ชัน ไปจนถึงเขียน logic การพล็อตใหม่ทั้งหมด

สั่งแก้ 1 token แต่ผลลัพธ์คือรื้อทั้งฟังก์ชัน โค้ดที่ AI เพิ่มมาดูเผินๆ เหมือนจะเขียนดีทุกบรรทัด มีทั้ง input validation และการดัก edge case อย่างครบครัน

แต่ปัญหาคือเมื่อคุณไม่ได้สั่ง คุณย่อมไม่ได้เตรียมชุดทดสอบไว้รองรับ และหากส่วนที่แถมมาทำงานผิดพลาดขึ้นมา ก็ยากจะตามหาจุดที่พัง นี่คือเหตุผลว่าทำไม over-editing จึงไม่ใช่แค่เรื่องความสวยงามของ diff แต่เป็นเรื่องความเสถียรและความปลอดภัยของระบบโปรดักชันโดยตรง

ส่องตัวเลขจริง ใครแก้เกิน ใครแก้งานพอดี

nrehiew ใช้เกณฑ์วัดหลัก 2 ตัว ได้แก่ Normalized Levenshtein Distance (วัดระดับการเปลี่ยนโครงสร้างโค้ด คิดเป็น token) และ Added Cognitive Complexity (วัดความซับซ้อนที่ AI เติมเข้ามา เช่น nested if, recursion หรือ control flow ใหม่)

ตัวเลขทั้งสองยิ่งสูง ยิ่งแปลว่าแก้เกินขอบเขต ส่วน Pass@1 คืออัตราความถูกต้องของการแก้บั๊กในรอบแรก ยิ่งสูงยิ่งดี

ผลลัพธ์ของกลุ่ม reasoning model (โมเดลที่มี thinking step) เรียงจากผลงานดีที่สุดไปหาแย่ที่สุด ตามลำดับ Pass@1 / Levenshtein / Added Cognitive Complexity:

• Claude Opus 4.6: 0.912 / 0.060 / 0.200
• GLM 5 High: 0.859 / 0.099 / 0.320
• Gemini 3.1 Pro Preview: 0.858 / 0.145 / 0.501
• Qwen 3.6 Plus: 0.858 / 0.145 / 0.048
• DeepSeek R1: 0.820 / 0.232 / 0.673
• GPT-5.4: 0.723 / 0.395 / 2.313
• GPT-5 High: 0.713 / 0.438 / 3.832

เมื่อดูตัวเลขแล้ว Claude Opus 4.6 ทำผลงานโดดเด่นทั้งความแม่นยำที่สูงที่สุด และขนาด diff ที่เล็กที่สุดพร้อมกัน ซึ่งปกติแล้วสองสิ่งนี้มักต้องแลกกัน (trade-off) แต่ Opus กลับทำได้ยอดเยี่ยมทั้งสองฝั่ง

ทางด้าน GPT-5.4 และ GPT-5 High มีค่า Pass@1 ต่ำกว่าตัวอื่น แต่กลับมีค่า Levenshtein และ Added Complexity พุ่งสูงลิ่ว แปลว่าแก้โค้ดเยอะมากแต่กลับไม่ค่อยตรงจุด

ผลลัพธ์ของกลุ่ม non-reasoning model (ไม่มี thinking step):

• Claude Opus 4.6: 0.900 / 0.079 / 0.313
• Qwen 3.6 Plus: 0.870 / 0.106 / 0.605
• Gemini 3.1 Pro Preview: 0.860 / 0.129 / 0.358
• DeepSeek V3: 0.800 / 0.201 / 0.803
• GPT-5 Minimal: 0.738 / 0.397 / 2.877

พฤติกรรมที่น่าสนใจคือ reasoning model ส่วนใหญ่จะมีแนวโน้ม over-edit โดยธรรมชาติ ยิ่งปล่อยให้โมเดลมีเวลาคิดยาว มันจะยิ่งพยายามหาเรื่องไปปรับแก้โค้ดส่วนอื่นที่ไม่จำเป็น

ทว่ามีข้อยกเว้นเดียวคือ Claude Opus 4.6 ที่เวอร์ชัน reasoning กลับแก้โค้ดน้อยกว่าเวอร์ชัน non-reasoning ซึ่งเป็นโมเดลเดียวที่ทำได้ คาดว่าทาง Anthropic มีการเทรนให้โมเดลรู้จักยับยั้งชั่งใจ (restraint) ซึ่งน่าจะอธิบายได้ว่าทำไมเวลาใช้ Claude Code ถึงรู้สึกคล่องตัวและไม่เวิ่นเว้อเหมือนเครื่องมือตัวอื่น

วิธีที่ 1: Prompt บรรทัดเดียวที่ใช้ได้ผลแทบทุกโมเดล

nrehiew ทดลองเติมประโยคสั้นๆ นี้ต่อท้าย prompt:

IMPORTANT: Try to preserve the original code and the logic of the original code as much as possible.

หากคุณถนัดเขียน prompt ภาษาไทย สามารถใช้ข้อความนี้แทนได้:

สำคัญ: พยายามคงโค้ดเดิมและ logic เดิมไว้มากที่สุดเท่าที่ทำได้

ผลลัพธ์ปรากฏว่า ทุกโมเดลมีค่า Levenshtein Distance ลดลงอย่างเห็นได้ชัด และแทบทุกโมเดล (ยกเว้น DeepSeek R1/V3) มีค่า Pass@1 เพิ่มขึ้นด้วย

ประโยคเดียวช่วยปรับพฤติกรรมของทั้ง Claude Opus, GPT-5, GPT-5.4, Gemini, GLM, Qwen และ DeepSeek ได้ทันตา

เคล็ดลับอยู่ที่การใช้คำว่า IMPORTANT: หรือ สำคัญ: นำหน้า เพราะโมเดลที่ผ่านการเทรน instruction following จะให้ความสำคัญกับคำสั่งที่เน้นย้ำเป็นพิเศษ

สาเหตุที่เราควรใส่กฎนี้ไว้เสมอ เพราะ AI จะไม่มีความจำข้าม session ทุกครั้งที่เริ่มงานใหม่จึงจำเป็นต้องย้ำบริบทนี้

ทางเลือกที่สะดวกคือการบันทึกไว้ใน system prompt หรือไฟล์กฎของโปรเจกต์ เช่น CLAUDE.md สำหรับ Claude Code หรือ .cursorrules สำหรับ Cursor เพื่อให้ทุก session นำไปใช้โดยอัตโนมัติ

ตัวอย่างการกำหนดใน CLAUDE.md:

# Code Editing Rules

IMPORTANT: Try to preserve the original code and the logic of the original code as much as possible. Only make changes that are strictly necessary to complete the requested task. Do not refactor, rename variables, add validation, or improve unrelated code unless explicitly asked.

หรือแบบภาษาไทย:

# กฎการแก้โค้ด

สำคัญ: พยายามคงโค้ดเดิมและ logic เดิมไว้มากที่สุดเท่าที่ทำได้ แก้เฉพาะส่วนที่จำเป็นต่อ task ที่ระบุเท่านั้น ห้าม refactor, rename, เพิ่ม validation หรือปรับปรุงโค้ดส่วนอื่นที่ไม่เกี่ยวข้อง เว้นแต่จะมีคำสั่งชัดเจน

วิธีที่ 2: เลือกโมเดลที่แก้งานพอดีตั้งแต่เริ่มต้น

หากคุณมีงบประมาณเพียงพอหรือให้ความสำคัญกับขนาด diff มากเป็นพิเศษ Claude Opus ถือเป็นตัวเลือกที่โดดเด่นที่สุดในการทดสอบนี้ เพราะได้ทั้งความแม่นยำและ diff ที่กระชับตรงจุด

สำหรับผู้ที่มีข้อจำกัดด้านต้นทุน โมเดลอย่าง Qwen 3.6 Plus หรือ GLM 5 High ก็เป็นทางเลือกที่ดี เพราะมีค่า Levenshtein ค่อนข้างต่ำอยู่แล้ว (0.099 ถึง 0.145)

กลุ่มที่ควรเพิ่มความระมัดระวังคือผู้ที่ใช้งานตระกูล GPT-5 เพราะตัวเลขชี้ว่า GPT-5.4 และ GPT-5 High มีพฤติกรรม over-edit สูงที่สุด (Levenshtein 0.39 ถึง 0.44 และ Added Cognitive Complexity 2.31 ถึง 3.83) แม้จะยังใช้งานได้ดี แต่จำเป็นต้องใส่ prompt ควบคุมและรีวิวโค้ดอย่างละเอียดรอบคอบ

วิธีที่ 3: สแกนตรวจทุกจุดด้วย git add -p

นี่คือ workflow ที่ผู้ใช้ชื่อ graybeardhacker บน Hacker News แนะนำไว้ ซึ่งเรียบง่ายและนำไปใช้ได้ทันที

เมื่อ AI แก้ไขโค้ดเสร็จเรียบร้อย อย่าเพิ่งรีบพิมพ์ git add . แต่ให้ใช้คำสั่งนี้แทน:

git add -p

Git จะแสดงการเปลี่ยนแปลงทีละส่วน (hunk) พร้อมถามตัวเลือก:

Stage this hunk [y,n,q,a,d,s,e,?]?

ตัวเลือกสำคัญที่ใช้เป็นประจำ:

• y: นำส่วนนี้เข้า staging (เตรียม commit)
• n: ข้ามส่วนนี้ไป (ไม่เอาเข้า commit แต่โค้ดยังคงอยู่ในไฟล์)
• s: แยก hunk ให้มีขนาดเล็กลง (กรณีที่ hunk มีการเปลี่ยนแปลงหลายจุดปนกัน)
• e: แก้ไขเนื้อหา hunk ด้วยตัวเอง
• q: ออกจากคำสั่ง

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

เมื่อ stage เฉพาะส่วนที่ต้องการเสร็จแล้ว คุณสามารถเก็บโค้ดส่วนที่เหลือไว้ด้วยคำสั่ง:

git stash

หากภายหลังต้องการนำกลับมาใช้ก็สั่ง pop ได้ หรือถ้ามั่นใจว่าไม่ต้องการแล้วจริงๆ สามารถลบทิ้งได้ด้วย git checkout -- .

การใช้ git add -p อาจเพิ่มเวลาเพียง 1 ถึง 2 นาทีต่อ commit แต่ช่วยดักจับโค้ดส่วนเกินได้เกือบ 100%

วิธีที่ 4: วางบทบาท AI ให้เหมือน Junior Developer

ผู้ใช้ pyrolistical บน Hacker News แนะนำแนวคิดที่น่าสนใจ คือการปฏิบัติต่อ AI agent เหมือนโปรแกรมเมอร์ระดับ junior ที่ต้องมีกระบวนการตรวจสอบกำกับเสมอ:

1. แบ่งคำสั่งเป็นชิ้นเล็ก: แทนที่จะสั่งคลุมเครือว่า 'แก้บั๊กทั้งหมดในไฟล์นี้' ให้ระบุเจาะจง เช่น 'แก้ off-by-one ในฟังก์ชัน process_data() เท่านั้น ห้ามแตะส่วนอื่น'
2. บังคับให้อธิบายเหตุผลทุกจุด: สั่งให้ AI ระบุว่าแต่ละบรรทัดที่แก้ไข มีความจำเป็นอย่างไร
3. สั่งให้ AI ตรวจทานความจำเป็นด้วยตัวเอง: ให้โมเดลรีวิวผลงานตัวเองอีกรอบว่า มีจุดไหนที่ไม่ได้เกี่ยวข้องกับการแก้งานโดยตรง แล้วคัดทิ้งไป

ตัวอย่าง prompt พร้อมใช้งาน:

พบปัญหา off-by-one ในฟังก์ชัน process_data() ตรง range(len(x) - 1)
ช่วยแก้ไขให้ถูกต้อง โดยปฏิบัติตามกฎต่อไปนี้:
1. แก้เฉพาะจุดที่เป็นบั๊กนี้เท่านั้น ห้ามแตะส่วนอื่น
2. ทุกบรรทัดที่แก้ไข ให้อธิบายสั้นๆ ว่าทำไมต้องแก้
3. เมื่อแก้เสร็จ ให้ตรวจทานซ้ำว่ามีการเปลี่ยนแปลงที่ไม่จำเป็นหรือไม่ หากมีให้ตัดออกทันที

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

วิธีที่ 5: ใช้ Analysis-only Mode วางแผนก่อนลงมือแก้จริง

เทคนิคจาก vibe42 บน Hacker News คือหากต้องการให้ AI วิเคราะห์แนวทางโดยยังไม่ต้องลงมือแตะโค้ด ให้ใส่ข้อความนี้กำกับ:

Do not modify any code; only describe potential changes.

หรือภาษาไทย:

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

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

วิธีนี้เหมาะอย่างยิ่งสำหรับการสำรวจ codebase ใหม่ การเปรียบเทียบแนวทางการเขียนโค้ดก่อนเริ่มลงมือ หรือการทำ code review ก่อน merge PR นอกจากนี้ยังช่วยประหยัด token เพราะไม่ต้องเสียรอบการทำงานไปกับการเขียนโค้ดทิ้งขว้าง

ลดการใช้ xhigh Thinking ใน Reasoning Model

jasonjmcghee บน Hacker News แชร์ข้อสังเกตเชิงปฏิบัติที่ตรงกับข้อมูลใน benchmark คือเวลาใช้งาน reasoning model ในงานแก้โค้ด ไม่ควรตั้งค่า thinking budget ไว้ที่ระดับ xhigh เพราะจะทำให้โมเดลคิดวนและมีแนวโน้ม over-edit สูงขึ้น

ระดับ high หรือ medium มักให้ผลลัพธ์ที่ดีกว่าสำหรับงานแก้ไขโค้ดทั่วไป

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

ใน Claude Code คุณสามารถปรับงบการคิดได้ด้วยคำสั่ง:

/thinking high

ใน OpenAI API สามารถกำหนดผ่านพารามิเตอร์ reasoning_effort:

response = client.chat.completions.create(
    model="gpt-5",
    reasoning_effort="medium",
    messages=[...]
)

สรุป Workflow จัดการโค้ดให้กระชับ

เราสามารถนำทั้ง 5 เทคนิคมาประกอบเป็น workflow ประจำวันได้ดังนี้:

1. บันทึก prompt fix ลงใน CLAUDE.md, .cursorrules หรือ system prompt ของเครื่องมือที่ใช้งาน
2. ตั้งค่า thinking budget ไว้ที่ high หรือ medium เป็นค่าเริ่มต้น
3. สำหรับงานที่ซับซ้อน ให้ใช้ analysis-only mode เพื่อตรวจสอบความเข้าใจให้ตรงกันก่อนลงมือแก้โค้ด
4. ระบุขอบเขตคำสั่งให้เจาะจงถึงระดับฟังก์ชันหรือไฟล์
5. ตรวจสอบการเปลี่ยนแปลงทีละจุดด้วย git add -p ก่อนทำ commit เสมอ

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

ข้อควรระวังเมื่อใช้งาน Minimal Editing

jstanley บน Hacker News ให้มุมมองที่น่าสนใจว่า การจำกัดการแก้โค้ดให้น้อยที่สุดไม่ได้เหมาะกับทุกสถานการณ์เสมอไป

หากโค้ดเดิมมีโครงสร้างที่ไม่ดี การ refactor ครั้งใหญ่อาจเหมาะสมกว่าการปะผุเฉพาะจุด

แนวคิด minimal editing จึงเหมาะกับ:

• การแก้บั๊กที่มีขอบเขตชัดเจน
• โปรเจกต์ที่มีทีมงานร่วมพัฒนาหลายคน ซึ่งต้องการ diff ขนาดเล็กเพื่อให้รีวิวง่าย
• โค้ดบนระบบโปรดักชันที่มีความเสี่ยงสูง

แต่สำหรับงานขึ้นโครงร่างต้นแบบ (prototype) หรือการปรับปรุงระบบเก่า (legacy refactoring) คุณอาจปลดล็อกข้อจำกัดเหล่านี้เพื่อให้ AI นำเสนอโครงสร้างที่ดีกว่าเดิม

นอกจากนี้ hathawsh ยังแนะนำว่า หาก AI ทำงานผิดพลาด อย่าเพียงแค่สั่งแก้ แต่ให้บันทึกเป็นกฎไว้ใน CLAUDE.md หรือ .cursorrules ด้วย เพื่อให้โมเดลเรียนรู้และไม่ทำผิดซ้ำในโปรเจกต์เดิม

เริ่มต้นทดลองกับโปรเจกต์จริงของคุณ

สิ่งที่คุณสามารถนำไปปรับใช้ได้ทันทีในวันนี้:

1. เพิ่ม prompt fix สั้นๆ ลงในไฟล์ config ของโปรเจกต์
2. ในการแก้โค้ดรอบถัดไป ลองตรวจ diff ด้วย git add -p เพื่อสังเกตจุดที่ AI แอบแก้เกินคำสั่ง
3. หากคุณใช้งานโมเดลตระกูล GPT-5 ลองทดสอบเปรียบเทียบผลลัพธ์ระหว่างการใส่และไม่ใส่ prompt ควบคุม

คุณภาพของโค้ดที่ AI สร้างขึ้น ไม่ได้ขึ้นอยู่กับความฉลาดของโมเดลเพียงอย่างเดียว แต่อยู่ที่วิธีที่เราสื่อสารและจัดวาง workflow ควบคุมด้วย เมื่อปรับแต่งได้อย่างลงตัว PR ของคุณจะกระชับ รีวิวง่าย และปลอดภัยต่อระบบในระยะยาว

แหล่งอ้างอิง

• Coding Models Are Doing Too Much โดย nrehiew งานวิจัยต้นฉบับ พร้อม benchmark ตัวเลขเต็ม การทดลอง training Qwen3 และ pattern ของ over-editing ใน reasoning model