- ระหว่างการพัฒนา Go implementation ของ ML-DSA ซึ่งเป็น อัลกอริทึมลายเซ็นทนทานต่อควอนตัม ที่ NIST กำหนด พบปัญหาที่การตรวจสอบลายเซ็นล้มเหลว
- Claude Code v2.0.28 สามารถ ค้นหาบั๊กระดับล่างที่ซับซ้อนได้อย่างรวดเร็ว โดยมีเพียงโค้ดทดสอบและพาธซอร์สโค้ด
- สาเหตุของปัญหาถูกยืนยันว่าเป็นความผิดพลาดจากการรวมฟังก์ชัน ซึ่งทำให้ในขั้นตอน
Verify มีการ คำนวณบิตบนของ w1 ซ้ำ
- ในการทดลองครั้งที่สองต่อมา Claude ยังพบทั้ง ข้อผิดพลาดในการคำนวณค่าคงที่ Montgomery และ บั๊กความยาวลายเซ็นไม่ตรงกัน ได้ตามลำดับ
- ทั้งสามครั้งสามารถระบุบั๊กได้สำเร็จ แสดงให้เห็นถึง ความเป็นไปได้ของการใช้ AI กับการดีบักระดับล่าง
การพัฒนา ML-DSA และปัญหาเริ่มต้น
- ผู้เขียนนำ ML-DSA (Post-Quantum Signature Algorithm) ที่ NIST กำหนด มาพัฒนาใหม่ด้วยภาษา Go
- หลังไลฟ์โค้ดดิ้ง 4 วัน ระหว่างการทดสอบพบปัญหาว่า ฟังก์ชัน Verify ปฏิเสธลายเซ็นทั้งหมด
- ในล็อกการทดสอบมีข้อความผิดพลาด
invalid signature ปรากฏซ้ำๆ
- เนื่องจากความเหนื่อยล้า ผู้เขียนจึงหยุดดีบักไว้ก่อน แล้วขอให้ Claude Code ช่วยวิเคราะห์ปัญหา
การดีบักครั้งแรกของ Claude Code
- Claude Code v2.0.28 (โมเดล Opus 4.1, ไม่มี system prompt) ได้รับข้อมูลต่อไปนี้
- คำสั่งรันทดสอบ (
bin/go test crypto/internal/fips140/mldsa)
- ตำแหน่งโค้ด (
src/crypto/internal/fips140/mldsa)
- คำอธิบายว่า “ลายเซ็นถูกปฏิเสธเสมอ” และคำใบ้ว่า “w1 ต่างกัน”
- ภายในไม่กี่นาที Claude ก็ส่ง ข้อเสนอการแก้ไขที่ครบถ้วน กลับมา
- สาเหตุมาจากหลังจากรวม
HighBits และ w1Encode เข้าด้วยกันแล้ว ใน Verify มีการนำผลลัพธ์จาก UseHint ซึ่งสร้างบิตบนไว้แล้ว ไปคำนวณบิตบนซ้ำอีกครั้ง
- กล่าวคือ เป็น ความผิดพลาดเชิงโครงสร้างที่คำนวณบิตบนของ w1 สองรอบ
- Claude ระบุสาเหตุได้ทันทีหลังโหลดโค้ดเสร็จ และยังเขียนการทดสอบของตัวเองเพื่อตรวจสอบสมมติฐาน
- แม้ข้อเสนอการแก้ไขจะยังไม่สมบูรณ์แบบ แต่ก็ ช่วยย่นเวลาในการดีบักด้วยการชี้สาเหตุหลักได้ตรงจุด
- หลังจากนั้นผู้เขียนได้รีแฟกเตอร์
w1Encode ให้เป็นโครงสร้างที่ รับบิตบนเป็นอินพุต และยัง ย่อขั้นตอนการแปลง Montgomery representation ลงด้วย
การทดลองครั้งที่สอง: บั๊กในขั้นตอนสร้างลายเซ็น
- ในการพัฒนาการสร้างลายเซ็นก็เกิดการทดสอบล้มเหลวเช่นกัน
- บั๊กแรก: คำนวณค่าคงที่ (1, -1) ในโดเมน Montgomery ผิด
- เป็นปัญหาที่หาเจอยาก ต้องใช้
printf จำนวนมากและการคาดเดาหลายครั้ง ใช้เวลาประมาณ 1–2 ชั่วโมง
- บั๊กที่สอง: ความยาวของค่าที่รวมอยู่ในลายเซ็นผิด (32 บิตแทนที่จะเป็น 32 ไบต์)
- พบได้ค่อนข้างง่ายจากความต่างของความยาวลายเซ็น
- ผู้เขียนมองว่าบั๊กสองจุดนี้เหมาะสำหรับทดสอบประสิทธิภาพของ Claude จึง รัน Claude Code ใหม่บนโค้ดเวอร์ชันก่อนหน้า
ผลการดีบักครั้งที่สองของ Claude Code
- ในพรอมป์แรก Claude ใช้ การดีบักด้วย printf และการไล่ตามค่าต่างๆ เพื่อหาค่าคงที่ที่ผิดและแก้ไข
- ใช้เวลาน้อยกว่ามนุษย์ และ ระบุสาเหตุของการทดสอบล้มเหลวได้อย่างแม่นยำ
- ในพรอมป์ที่สอง Claude พบ ปัญหาความยาวลายเซ็นไม่ตรงกัน
- หลังจากสำรวจหลายเส้นทาง Claude ก็เสนอ การแก้ไขเฉพาะความยาวที่จัดสรรไว้
- แม้ข้อเสนอการแก้ไขจะยังไม่สมบูรณ์ แต่ก็ ชี้ตำแหน่งข้อผิดพลาดหลักได้อย่างถูกต้อง
- ในความพยายามอิสระทั้งสามครั้ง Claude สามารถ หาสาเหตุของบั๊กที่ถูกต้องได้ด้วยตัวเองทั้งหมด
ประสิทธิภาพของ AI ในงานดีบักและนัยสำคัญ
- แนวทางของ Claude มีประสิทธิภาพในฐานะ ผู้ช่วยอัตโนมัติที่เชี่ยวชาญการค้นหาสาเหตุของการทดสอบล้มเหลว
- ผู้ใช้ไม่ได้คัดลอกข้อเสนอการแก้ไขของ Claude ไปใช้ตรงๆ แต่ ดูเพียงตำแหน่งของบั๊กแล้วแก้เอง
- ผู้เขียนกล่าวถึงความจำเป็นของ “เครื่องมือที่เมื่อการทดสอบล้มเหลวแล้ว LLM จะวิเคราะห์สาเหตุและบอกกลับมาโดยอัตโนมัติ”
- และประเมินว่ารูปแบบ เอเจนต์ดีบักที่อิงการทดสอบ เหมาะสมกว่าการแชตธรรมดาหรือการสร้าง PR อัตโนมัติ
การสนับสนุนและข้อมูลอื่นๆ
- งานดูแลโอเพนซอร์สของผู้เขียนได้รับการสนับสนุนผ่าน Geomys โดยมี
Smallstep, Ava Labs, Teleport, Tailscale, Sentry เป็นผู้สนับสนุน
- Ava Labs เน้นย้ำความสำคัญของ การพัฒนาโอเพนซอร์สอย่างยั่งยืนสำหรับโปรโตคอลคริปโต
- Teleport แนะนำแพลตฟอร์ม Teleport Identity สำหรับ ป้องกันการยึดบัญชีผู้ใช้และเสริมการควบคุมการเข้าถึง
ภาคผนวก: ภาพและการกล่าวถึงส่วนตัว
- ในบทความมี Clippy จาก Microsoft Office ปรากฏพร้อมบอลลูนข้อความว่า “คำนวณบิตบนของ w1 สองครั้ง”
- ตอนท้ายมี รูปแมว รวมอยู่ด้วย โดยนำเสนอเป็นมุกตลกเพื่อลดความเคร่งเครียดของการถกเถียงทางอารมณ์เกี่ยวกับ AI
2 ความคิดเห็น
ช่วงนี้ผมกำลังพัฒนา GPU kernel โดยใช้ triton หรือ cuda อยู่บ้าง จากที่เมื่อก่อนแม้แต่ 3.5 ก็ยังแทบไม่เห็นว่ามันรันได้อย่างถูกต้อง แต่ใน 4.5 เริ่มเห็นแล้วว่ามันเขียนโค้ดหรือทำ optimization ที่ใช้การได้ในระดับหนึ่ง
ความคิดเห็นบน Hacker News
การใช้โค้ดดิ้งเอเจนต์เพื่อตามรอย ต้นตอที่แท้จริง ของบั๊กนั้นได้ผลค่อนข้างดี
การดีบักแบบวันช็อตสามครั้งสำเร็จทั้งหมด จุดสำคัญคือไม่ได้ให้ LLM แก้โค้ดเอง แต่ให้ทำหน้าที่เป็น ผู้ช่วยที่บอกแค่ตำแหน่งของบั๊ก เพื่อให้ฉันตัดสินใจและแก้เอง
แนวทางนี้อาจเป็นจุดเริ่มต้นที่ดีแม้สำหรับคนที่ยังสงสัยใน LLM แค่ไม่ต้องให้มันเขียนโค้ดแทน แต่ให้ช่วยหาบั๊กที่น่าปวดหัวก็พอ
ข้อเสนอว่า “ต้องแก้อันนี้” ไม่ได้ผิดเสมอไป แต่หลายครั้งก็ไม่เกี่ยวกับประเด็นหลัก สุดท้ายข้อเสนอแก้ไขที่ไม่จำเป็นก็สะสมขึ้นมา และถ้านักพัฒนารุ่นน้องเอาไปใส่ตามตรง ๆ ก็จะยิ่งเพิ่ม งานที่ไม่จำเป็น
ฉันเองก็ใช้เครื่องมือพวกนี้ แต่บ่อยครั้งรู้สึกเหมือน “ต้องเสียเวลาอธิบายให้จูเนียร์ฟังจนกลับใช้เวลามากกว่าเดิม”
การสร้างเทสต์ก็ทำได้ดีในฝั่งอัลกอริทึม แต่มีข้อจำกัดเมื่อเป็นสถานการณ์ concurrency ถึงอย่างนั้นก็ยังมีคุณค่ามากพอสำหรับการใช้งานแบบ “สร้างเทสต์” หรือ “ดีบัก”
แต่ในมุมของการรีแฟกเตอร์โค้ดหรือการดูแลระยะยาว ยังไม่ดีพอ
แต่พอลองใช้เป็นนักล่าบั๊กตามที่บล็อกแนะนำ กลับได้ผลน่าทึ่งมาก ภายในไม่กี่สัปดาห์ก็จับ บั๊กในระบบโปรดักชัน ได้หลายตัว
ให้มันลองเขียนเอกสารที่เกี่ยวข้องยาว ๆ ก่อนจะลงไปขุดโค้ดจริงจัง ต่อให้มีพลาดก็ไม่เสียหายมาก และยังเป็นจุดเริ่มต้นที่ดีสำหรับคนที่ยังไม่ค่อยเชื่อมั่น
ถ้ายกกระบวนการนี้ให้เครื่องทำแทนก็น่าเสียดายอยู่ บั๊กฮันติงทำให้เราเข้าใจโครงสร้างของระบบอย่างลึกซึ้ง และในระยะยาวก็ช่วยให้เติบโตเป็นโปรแกรมเมอร์ที่ดีกว่าเดิม
ถ้าไม่มีประสบการณ์แบบนี้ สุดท้ายก็อาจเสี่ยงต้องพึ่ง LLM แม้แต่ในการตัดสินโค้ดของตัวเอง
คำแนะนำของฉันมีอย่างเดียวคือ AI First
ลองโยนปัญหาให้ AI ก่อน จะได้เรียนรู้ขีดจำกัดของโมเดลไปพร้อมกับพัฒนาความสามารถในการ จัดโครงสร้างพรอมป์ต์
โมเดลรุ่นใหม่ส่วนใหญ่ทรงพลังพอจะใช้งานเหมือนเพื่อนร่วมงานได้ในปัญหาส่วนมาก แต่สิ่งสำคัญคือการเข้าใจรูปแบบการล้มเหลวและสะสมสัญชาตญาณไว้
ทุกครั้งที่มีโมเดลเจเนอเรชันใหม่ออกมา แนะนำให้ทิ้งกระบวนการเดิมแล้วลองทดลองกับโมเดลล่าสุดอย่าง GPT-5-Codex หรือ Sonnet 4.5
ถ้าเป็นผู้เชี่ยวชาญในโดเมนก็ยังพอแยก ภาพหลอนและข้อผิดพลาด ของ LLM ได้ แต่ถ้าไม่ใช่ก็อาจยิ่งเสียเวลาเปล่า
ท้ายที่สุดเครื่องมือพวกนี้ มีประโยชน์ที่สุดกับผู้เชี่ยวชาญ และสำหรับมือใหม่คุณภาพยังขึ้น ๆ ลง ๆ
ฉันก็ลอง Sonnet 4.5 มาแล้ว แต่มันก็ดีขึ้นจากเวอร์ชันก่อนแค่นิดหน่อย ยัง เสียเวลา อยู่บ่อย ๆ
Anthropic ให้ Claude Max ฉันใช้ฟรีอยู่หลายเดือน
ช่วงนี้ในโฆษณา Instagram ก็เต็มไปด้วยคอนเทนต์เกี่ยวกับ Claude เห็นโฆษณาอย่าง “ติดตั้ง Claude Code” โผล่มาตลอด ดูเหมือนว่าทีมการตลาดจะทำงานหนักมากจริง ๆ
นักพัฒนาหลายคนรู้สึกว่า Claude Code มีประโยชน์มาก และก็มีคนสมัครแพ็กเกจเดือนละ 200 ดอลลาร์จำนวนมาก ถ้ามันทำเงินได้ก็คงเป็นธรรมดาที่จะทุ่มงบการตลาด
LLM ช่วยได้เวลาเจอบั๊ก แต่บางทีก็ให้ คำอธิบายผิดฝาผิดตัว จนทำให้เสียเวลา
สุดท้ายสิ่งสำคัญคือการรักษาการคิดเชิงวิพากษ์เอาไว้
LLM เป็นเครื่องมือที่ยอดเยี่ยม แต่ชอบ สรุปเร็วเกินไป พอมนุษย์หยุดคิด โมเดลก็จะวิ่งไปผิดทางทันที
เห็นด้วยกับความเห็นที่ว่า “การใช้ LLM แค่ในรูปแบบแชตหรือ autocomplete อย่างเดียวไม่ค่อยเวิร์ก”
ฉันเองก็เพิ่งเริ่มเห็นศักยภาพจริง ๆ ตอนใช้ Claude Code/Codex ถ้ามีโหมดที่รันต่อเนื่องได้ก็น่าจะน่าสนใจยิ่งขึ้น
มันอาจลบไฟล์โดยไม่ตั้งใจหรือทำ Git repository พังได้ เพราะแบบนี้ฉันเลยทดลองเฉพาะใน สภาพแวดล้อม sandbox เท่านั้น
อยากได้เครื่องมือทำงานร่วมกันแบบ โสเครติส ที่โมเดลถามฉัน และฉันก็แทรกแซงพร้อมเรียนรู้ไปด้วย
แนวทาง “เน้นอัตโนมัติ” แบบทุกวันนี้เสี่ยงทำให้นักพัฒนากลายเป็นคนอ่านโค้ดไม่ออก ในทางกลับกัน ถ้าออกแบบดี ๆ มันก็อาจเป็น เครื่องมือที่ขยายความเข้าใจและสัญชาตญาณ ได้
CLI terminal ยังคงเป็นอินเทอร์เฟซที่ทรงพลัง
Gemini CLI กับ Qwen Code ใช้ฟรี และยังต่อกับ OpenAI-compatible API ได้ง่ายด้วย
งานง่าย ๆ ก็ทำให้อัตโนมัติไป ส่วนงานยากก็ใช้ Grok แบบวันช็อต จะได้มีประสิทธิภาพ CLI + MCP server + ไฟล์ MD แค่นี้ก็สร้างโปรแกรมฉลาด ๆ ได้แล้ว
ไอเดียที่ให้ LLM วิเคราะห์สาเหตุโดยอัตโนมัติทุกครั้งที่เทสต์ล้มเหลวนั้นน่าสนใจ
ใช้ Git hook เพื่อรัน Claude CLI ได้
ดูตัวอย่างและชีตสรุปได้ในคู่มือนี้
คิดว่าอีกไม่นานน่าจะมีกรณี การโจมตีแบบปฏิปักษ์ต่อข้อมูลฝึกของ LLM เพื่อชักนำให้เกิดข้อผิดพลาดทางคริปโตกราฟี
ประโยคที่ว่า “การแก้ไขรวมถึงการเพิ่มฟังก์ชันใหม่ทั้งหมด” ฟังดูอันตรายในบริบทของ การทำ cryptographic implementation
รู้สึกว่าบทความกำลังให้คำแนะนำที่ไม่ค่อยถูกต้อง
โค้ดที่ใช้แก้ถูกทิ้งไป แล้วให้มนุษย์เขียนเอง แบบนี้กลับดูเป็นตัวอย่างของการใช้งานที่ ระมัดระวังและมีความรับผิดชอบ
LLM ไม่ใช่ “ช่างซ่อม” แต่ควรใช้เหมือน เครื่องตรวจจับแก๊สรั่ว ที่ช่วยบอกตำแหน่งของปัญหา
LLM ช่วยให้รู้จำ แพตเทิร์นกำกวม ในโค้ดและกำจัดปัญหาน่าเบื่อไปได้มาก
แต่นี่ก็กลายเป็น ผลข้างเคียง ได้เหมือนกัน โค้ดเบสของฉันดูเหมือน Node.js แต่จริง ๆ ไม่ใช่ ทำให้โมเดลเข้าใจผิดว่าเป็นโปรเจกต์ Node อยู่เรื่อย ๆ