ส่งโค้ดวันละกว่ายี่สิบ Pull Request แล้วมีวิธีให้ Lint กับ Test รันเองก่อนไหม
สรุปสั้น ๆ
Claude Code Hooks คือจุดเชื่อมที่ให้ทีมกำหนดคำสั่งอัตโนมัติที่ต้องรันก่อนหรือหลังเหตุการณ์บางอย่าง เช่นก่อนแก้ไฟล์หรือหลังเขียนโค้ดเสร็จ ใช้บังคับให้ lint, test หรือ format รันจริงทุกครั้งโดยไม่ต้องพึ่งความจำของคนหรือ Agent ว่าต้องทำขั้นตอนนี้เอง
ทีมที่ส่งโค้ดถี่ วันหนึ่งอาจมี Pull Request เปิด-ปิดกันมากกว่ายี่สิบครั้ง แต่ละครั้งควรผ่านขั้นตอนตรวจสอบพื้นฐานเหมือนกันหมด คือรัน lint ตรวจ style, รัน test ยืนยันว่าไม่ทำของเดิมพัง และบางทีมีขั้นตอน format โค้ดให้เป็นมาตรฐานเดียวกันก่อน commit แต่ในความเป็นจริง ขั้นตอนพวกนี้มักถูกข้ามไปเวลารีบส่งงาน
ปัญหาที่ตามมาคือ pipeline บน CI แดงบ่อยเพราะเรื่องเล็ก ๆ น้อย ๆ ที่ควรจับได้ตั้งแต่ก่อน push เช่น import ที่ไม่ได้ใช้ ฟังก์ชันที่ไม่มี test ครอบ หรือ format โค้ดไม่ตรงมาตรฐานทีม ทีมที่ใช้ Claude Code ช่วยเขียนโค้ดก็ยังเจอปัญหาแบบนี้ได้เหมือนกัน ถ้า Agent ไม่ถูกบังคับให้รันขั้นตอนตรวจสอบก่อนถือว่างานเสร็จ
Hooks คือคำตอบของปัญหานี้ มันคือกลไกที่ให้ทีมกำหนดคำสั่งที่ต้องรันอัตโนมัติในจังหวะที่กำหนดไว้ล่วงหน้า ไม่ต้องพึ่งว่า Agent หรือคนจะจำได้ไหมว่าต้องรัน lint ก่อน commit ทุกครั้ง บทความนี้จะอธิบายว่า Hooks ทำงานตรงไหนในกระบวนการ ตั้งค่ายังไง และควรใช้กับขั้นตอนแบบไหนถึงจะคุ้มค่าที่สุด
Hooks คืออะไร ทำงานตรงจุดไหนของ Workflow
Hooks คือจุดเชื่อมที่ให้ทีมกำหนดคำสั่งที่ต้องรันโดยอัตโนมัติเมื่อเกิดเหตุการณ์บางอย่างระหว่าง Claude Code ทำงาน เช่นก่อนที่ Agent จะแก้ไฟล์ หลังจากแก้ไฟล์เสร็จ หรือก่อนจะยืนยันว่างานเสร็จสมบูรณ์ คำสั่งเหล่านี้รันโดยไม่ต้องรอให้คนหรือ Agent นึกขึ้นได้เองว่าต้องทำ
หลักการทำงานคล้ายกับ Git Hooks ที่นักพัฒนาหลายคนคุ้นเคยอยู่แล้ว เช่น pre-commit hook ที่รัน lint ก่อนบันทึก commit แต่ Claude Code Hooks ขยายแนวคิดนี้ให้ครอบคลุมเหตุการณ์ในการทำงานของ Agent เองด้วย เช่นก่อน Agent จะรันคำสั่งที่มีความเสี่ยง หรือหลังจากแก้ไฟล์ในโฟลเดอร์ที่กำหนดไว้เฉพาะ
ทำไมพึ่งความจำอย่างเดียวไม่พอ ต้องมีระบบบังคับ
ปัญหาของการพึ่งให้ Agent 'จำ' ว่าต้องรัน test ทุกครั้งคือความไม่แน่นอน แม้ Agent จะทำตามคำสั่งในบทสนทนาได้ดี แต่ถ้าคำสั่งเริ่มต้นไม่ได้เน้นย้ำเรื่องนี้ชัดเจน หรือบทสนทนายาวจนบริบทเปลี่ยนไป โอกาสที่ขั้นตอนสำคัญจะถูกข้ามไปก็มีอยู่จริง
Hooks แก้ปัญหานี้ด้วยการทำให้ขั้นตอนสำคัญไม่ขึ้นกับความจำของใครเลย ไม่ว่า Agent จะได้รับคำสั่งแบบไหน หรือบทสนทนายาวแค่ไหน คำสั่งที่ผูกไว้กับ Hook จะรันเสมอเมื่อถึงจังหวะที่กำหนด เหมือนมีระบบตรวจสอบอัตโนมัติคอยดักอยู่เบื้องหลังตลอดเวลา ไม่ต้องพึ่งดุลยพินิจของ Agent ในแต่ละครั้ง
ประเภทของ Hook ที่ใช้บ่อยและใช้ทำอะไร
Hooks แบ่งตามจังหวะที่ทำงานได้หลายแบบ ทีมส่วนใหญ่เริ่มจากกลุ่มพื้นฐานเหล่านี้ก่อนขยายไปกรณีซับซ้อนขึ้น:
| จังหวะที่ทำงาน | ใช้ทำอะไร | ตัวอย่างคำสั่ง |
|---|---|---|
| ก่อน Agent แก้ไฟล์ | ตรวจสอบเงื่อนไขก่อนอนุญาตให้แก้ เช่นห้ามแตะไฟล์ config บางไฟล์ | ตรวจ path ของไฟล์ที่จะแก้ |
| หลัง Agent แก้ไฟล์เสร็จ | รัน format และ lint ให้โค้ดเป็นมาตรฐานทันที | prettier, eslint --fix |
| ก่อนยืนยันว่างานเสร็จ | รัน test ทั้งหมดเพื่อยืนยันว่าไม่ทำของเดิมพัง | npm test, pytest |
| ก่อนรันคำสั่งที่มีความเสี่ยง | ขอการยืนยันเพิ่มเติมก่อนรันจริง | ตรวจคำสั่งที่มีคำว่า rm หรือ DROP |
ตั้งค่า Hooks แรกของทีมทำยังไง
การเริ่มต้นไม่จำเป็นต้องตั้งค่า Hook ทุกจังหวะพร้อมกันตั้งแต่วันแรก ควรเริ่มจากจุดที่ทีมเจอปัญหาบ่อยที่สุดก่อน:
- สำรวจว่าขั้นตอนไหนที่ทีมลืมทำบ่อยที่สุดตอนนี้ เช่นลืมรัน lint ก่อน commit หรือลืมรัน test ก่อนส่งงาน
- เลือก Hook ที่ตรงกับปัญหานั้นก่อนเป็นอันดับแรก แทนที่จะตั้งค่าทุกจังหวะพร้อมกัน
- เขียนคำสั่งที่ต้องการให้รันอัตโนมัติ เช่นคำสั่ง lint หรือ test ที่ทีมใช้อยู่แล้วในโปรเจกต์
- ทดสอบกับงานจริงสักสองสามรอบ ดูว่า Hook รันถูกจังหวะและไม่รบกวนขั้นตอนทำงานปกติมากเกินไป
- ค่อยขยายไปตั้งค่า Hook เพิ่มเติมสำหรับจังหวะอื่นเมื่อมั่นใจว่าชุดแรกทำงานได้ดีแล้ว
ตัวอย่างสมมติ ทีมใช้ Hook ลดจำนวนครั้งที่ CI แดง
สมมติทีมพัฒนาระบบจัดการสต็อกสินค้ามี Pull Request เฉลี่ยวันละยี่สิบกว่าฉบับ ก่อนตั้งค่า Hook พบว่าประมาณหนึ่งในสี่ของ Pull Request ทำให้ pipeline บน CI แดงเพราะเรื่องเล็กน้อย เช่น lint error หรือ test ที่ลืมรันก่อน push
หลังตั้งค่า Hook ให้รัน lint และ test อัตโนมัติทุกครั้งก่อนที่ Agent จะยืนยันว่างานเสร็จ จำนวนครั้งที่ pipeline แดงเพราะเรื่องพื้นฐานเหล่านี้ลดลงอย่างเห็นได้ชัด เพราะปัญหาถูกจับตั้งแต่ก่อน push ไม่ใช่มาเจอทีหลังบน CI ซึ่งเสียเวลากว่ามาก
ตัวเลขและสถานการณ์นี้เป็นตัวอย่างสมมติเพื่อให้เห็นกรอบการทำงาน ไม่ใช่สถิติจากผลสำรวจอย่างเป็นทางการ แต่สะท้อนรูปแบบที่ทีมพัฒนาหลายทีมมักพบเมื่อเริ่มบังคับขั้นตอนตรวจสอบให้รันอัตโนมัติแทนพึ่งความจำคน
ใช้ Hook เป็นด่านความปลอดภัยก่อนคำสั่งเสี่ยง
นอกจากเรื่อง lint และ test แล้ว Hooks ยังใช้เป็นด่านตรวจสอบก่อนที่ Agent จะรันคำสั่งที่มีความเสี่ยงสูง เช่นคำสั่งที่ลบไฟล์จำนวนมาก หรือคำสั่งที่แก้ไขฐานข้อมูลโดยตรง ทีมสามารถตั้ง Hook ให้หยุดรอการยืนยันจากคนก่อนดำเนินการต่อ แทนที่จะให้ Agent รันไปเลยโดยไม่มีใครตรวจสอบ
แนวทางนี้สำคัญมากเวลา Agent ได้รับสิทธิ์เข้าถึงระบบภายนอกผ่าน MCP เพราะยิ่งเชื่อมกับระบบจริงมากเท่าไหร่ ความเสี่ยงจากคำสั่งที่ตีความผิดก็ยิ่งสูงตาม การมี Hook เป็นด่านตรวจสอบก่อนรันคำสั่งเสี่ยงจึงเป็นชั้นความปลอดภัยที่เสริมกับการจำกัดสิทธิ์ที่ระดับ MCP Server เอง
ข้อผิดพลาดที่ทำให้ Hooks กลายเป็นตัวถ่วงแทนตัวช่วย
ทีมที่เพิ่งเริ่มใช้ Hooks มักเจอปัญหาคล้ายกันคือตั้งค่ามากเกินไปตั้งแต่แรก จนขั้นตอนทำงานปกติช้าลงเพราะต้องรอ Hook หลายตัวรันทุกครั้ง ทั้งที่บาง Hook ไม่ได้จำเป็นสำหรับทุกงาน
- ตั้ง Hook ให้รันคำสั่งที่ใช้เวลานานเกินไปในทุกจังหวะ ทำให้ขั้นตอนทำงานช้าลงจนทีมเริ่มมองว่าเป็นตัวถ่วง
- ไม่แจ้งให้ทั้งทีมรู้ว่ามี Hook ทำงานอยู่เบื้องหลัง ทำให้บางคนสงสัยว่าทำไมงานถึงช้าลงโดยไม่รู้สาเหตุ
- ตั้ง Hook ที่ตรวจสอบเข้มงวดเกินไปจนบล็อกงานปกติที่ไม่มีความเสี่ยงจริง ทำให้ทีมหาทางเลี่ยง Hook แทนที่จะทำตาม
- ไม่เคยทบทวนว่า Hook ที่ตั้งไว้ยังจำเป็นอยู่ไหมเมื่อโปรเจกต์เปลี่ยนแปลงไปตามเวลา
แนะนำ Hooks ให้ทีมยอมรับโดยไม่รู้สึกว่าถูกจับผิด
การเริ่มใช้ Hooks ในทีมที่ยังไม่เคยมีกลไกบังคับแบบนี้มาก่อน อาจถูกมองว่าเป็นการเพิ่มขั้นตอนที่ยุ่งยากหรือรู้สึกเหมือนถูกจับผิด ถ้าไม่มีการสื่อสารที่ดีก่อนเริ่มใช้ วิธีที่ช่วยลดแรงต้านคือให้ทีมมีส่วนร่วมตั้งแต่ขั้นตอนออกแบบว่าควรบังคับตรงจุดไหนบ้าง แทนที่จะเป็นการประกาศกฎจากบนลงล่างโดยไม่ปรึกษาใคร
อีกวิธีที่ได้ผลคือเริ่มจาก Hook ที่ทีมเห็นประโยชน์ชัดเจนที่สุดก่อน เช่นตัวที่ช่วยจับ error ก่อน push แทนที่ต้องไปเจอทีหลังบน CI ซึ่งเสียเวลามากกว่า เมื่อทีมเห็นผลลัพธ์จริงว่าช่วยลดงานที่ต้องแก้ทีหลัง ความรู้สึกต่อต้านก็มักจะลดลงเอง เพราะมองว่าเป็นเครื่องมือช่วยงานมากกว่าเป็นกฎที่มาจำกัดการทำงาน
ขยายการใช้งาน Hooks ไปมากกว่าแค่ Lint และ Test
เมื่อทีมคุ้นเคยกับการใช้ Hook สำหรับงานพื้นฐานแล้ว หลายทีมเริ่มขยายไปใช้กับงานที่ซับซ้อนขึ้น เช่นตรวจสอบว่าโค้ดที่แก้ไม่มีการเปิดเผยข้อมูลลับอย่าง API Key หรือรหัสผ่านที่ติดไปในไฟล์โดยไม่ตั้งใจ ก่อนที่ Agent จะยืนยันว่างานเสร็จ ซึ่งเป็นด่านความปลอดภัยเพิ่มเติมที่ช่วยลดความเสี่ยงข้อมูลรั่วไหลได้ตั้งแต่ต้นทาง
อีกแนวทางที่ทีมขนาดใหญ่บางทีมใช้คือตั้ง Hook ให้ตรวจสอบว่าไฟล์ที่แก้ไขอยู่ในขอบเขตที่ Agent ควรแตะต้องหรือไม่ เช่นห้ามแก้ไฟล์ config ของระบบ deploy โดยไม่มีการยืนยันเพิ่มเติมจากคน แม้ Agent จะเข้าใจคำสั่งถูกต้อง แต่การมีด่านตรวจสอบเพิ่มช่วยป้องกันความผิดพลาดที่อาจเกิดจากการตีความคำสั่งกำกวมได้อีกชั้นหนึ่ง
สรุป
ทีมที่ส่งโค้ดถี่ทุกวันไม่ควรพึ่งความจำของคนหรือ Agent ในการทำขั้นตอนตรวจสอบพื้นฐานอย่าง lint และ test เพราะยิ่งจำนวน Pull Request มากเท่าไหร่ โอกาสที่จะมีขั้นตอนตกหล่นก็ยิ่งสูงตาม Hooks คือกลไกที่ทำให้ขั้นตอนเหล่านี้รันได้แน่นอนทุกครั้งโดยไม่ต้องพึ่งดุลยพินิจของใครคนใดคนหนึ่ง
ทีมที่สนใจเริ่มใช้ควรเริ่มจากปัญหาที่เจอบ่อยที่สุดก่อน เช่นลืมรัน lint ก่อน commit แล้วค่อยขยายไปยังจังหวะอื่นเมื่อมั่นใจว่าชุดแรกทำงานได้ดีและไม่ทำให้ขั้นตอนทำงานปกติช้าลงจนเกินไป
- Hooks บังคับให้คำสั่งอย่าง lint หรือ test รันอัตโนมัติในจังหวะที่กำหนด ไม่ต้องพึ่งความจำของคนหรือ Agent
- แบ่งได้หลายจังหวะ เช่นก่อนแก้ไฟล์ หลังแก้ไฟล์เสร็จ และก่อนยืนยันว่างานเสร็จจริง
- ใช้เป็นด่านความปลอดภัยก่อนคำสั่งเสี่ยงได้ โดยเฉพาะเมื่อต่อกับระบบภายนอกผ่าน MCP
- ควรเริ่มจากปัญหาที่เจอบ่อยที่สุดก่อน ไม่ใช่ตั้งค่าทุกจังหวะพร้อมกันตั้งแต่วันแรก
คำถามที่พบบ่อย
Hooks ต่างจากการตั้งค่า CI/CD Pipeline ยังไง
CI/CD Pipeline ทำงานหลัง push โค้ดขึ้นไปแล้ว ส่วน Hooks ทำงานระหว่างที่ Agent กำลังทำงานอยู่บนเครื่อง ก่อนโค้ดจะถูก push ด้วยซ้ำ ทำให้จับปัญหาได้เร็วกว่าและลดจำนวนครั้งที่ pipeline บน CI จะแดง
ตั้ง Hook เยอะเกินไปมีผลเสียไหม
มีผลเสียถ้าตั้งมากเกินจำเป็น เพราะแต่ละ Hook ที่รันเพิ่มเวลาในการทำงานทุกครั้ง ควรเลือกเฉพาะขั้นตอนที่สำคัญจริงและมีปัญหาเกิดขึ้นบ่อยก่อน ไม่ใช่ตั้งทุกอย่างที่นึกออก
Hook รันคำสั่งที่ใช้เวลานานได้ไหม เช่น test ทั้งชุด
ได้ แต่ควรพิจารณาผลกระทบต่อความเร็วในการทำงาน ถ้า test ทั้งชุดใช้เวลานานมาก อาจพิจารณาแยกเป็น test ชุดเล็กที่รันเร็วสำหรับ Hook ระหว่างทำงาน แล้วเก็บ test ชุดใหญ่ไว้รันตอน CI แทน
ถ้า Hook ทำให้งานล้มเหลว Agent จะทำยังไงต่อ
โดยทั่วไป Agent จะอ่านผลลัพธ์ที่ Hook ส่งกลับมา แล้วพยายามแก้ไขปัญหาตามข้อความ error ก่อนลองใหม่ ไม่ใช่ข้ามขั้นตอนนั้นไปเฉย ๆ ซึ่งเป็นจุดแข็งที่ทำให้ Hooks มีประโยชน์มากกว่าการตรวจสอบด้วยคนเพียงอย่างเดียว
ทีมเล็กที่มีแค่สองสามคนจำเป็นต้องใช้ Hooks ไหม
ไม่จำเป็นต้องรีบใช้ตั้งแต่ทีมยังเล็ก เพราะการสื่อสารกันตรง ๆ ยังทำได้ง่าย แต่ถ้าเริ่มเห็นว่าลืมรัน test หรือ lint บ่อยขึ้นแม้ทีมจะเล็ก ก็เริ่มตั้ง Hook พื้นฐานไว้ได้เลยโดยไม่ต้องรอให้ทีมโตก่อน
Hooks ใช้ร่วมกับ Skills ได้ไหม หรือต้องเลือกอย่างใดอย่างหนึ่ง
ใช้ร่วมกันได้และทำงานเสริมกันคนละชั้น Skills กำหนดว่า Agent ควรเขียนโค้ดแบบไหน ส่วน Hooks บังคับว่าต้องผ่านขั้นตอนตรวจสอบอะไรก่อนงานจะถือว่าเสร็จจริง ทีมส่วนใหญ่ที่ใช้จริงจังมักใช้ทั้งสองอย่างควบคู่กัน
ควรเริ่มตั้ง Hook ตัวแรกจากอะไรถ้ายังไม่เคยใช้เลย
แนะนำให้เริ่มจาก Hook ที่รัน lint หรือ format หลังแก้ไฟล์เสร็จก่อน เพราะเห็นผลเร็วและกระทบขั้นตอนทำงานน้อยที่สุด แล้วค่อยขยับไปตั้ง Hook สำหรับ test และด่านความปลอดภัยเมื่อทีมคุ้นเคยกับแนวคิดนี้แล้ว
อ่านต่อแบบเจาะลึก
วัด Conversion LINE ทุกแบรนด์ รวมศูนย์ที่เดียว
องค์กรที่มีหลายแบรนด์ หลายสาขา หลาย LINE OA — linli รวม Tracking และส่ง Conversion กลับทุกแพลตฟอร์ม พร้อม Custom Limit เริ่มฟรี 14 วัน
ติดต่อทีม Salesบทความที่เกี่ยวข้อง
Skills ของ Codex: วิธีทำให้ Agent เขียนโค้ดตามมาตรฐานทีมทุกครั้ง
แบ่งงานให้ AI หลายตัวทำพร้อมกันโดยไม่ชนกันเอง
