Feedback loops: ช่วยให้ Claude Code ทำงานที่ซับซ้อนให้สำเร็จได้โดยไม่ต้องคอยดูแลใกล้ชิด

เมื่อเรามอบหมายงานที่ซับซ้อนมากขึ้นให้ Claude ทำ สิ่งที่สำคัญเพิ่มขึ้นคือความสามารถในการ ตรวจสอบงานของตัวเอง

ยิ่ง Claude สามารถตรวจสอบตัวเองได้มากเท่าไหร่:

• ยิ่งทำงานอิสระในงานระยะยาวได้มากขึ้นเท่านั้น
• ผลลัพธ์สุดท้ายก็ยิ่งมีคุณภาพดีขึ้น
• ใช้รอบการไปกลับน้อยลงเพื่อให้ถึงจุดนั้น

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

ข่าวดีคือ Claude สามารถ ตรวจสอบตัวเองกับสัญญาณที่แน่นอนอยู่แล้ว เช่น type errors, lint errors, test ที่ล้มเหลว และ runtime errors และเมื่อโมเดลดีขึ้น สิ่งนี้จะยิ่งดีขึ้น

สิ่งที่ Claude ไม่สามารถอนุมานได้เสมอคือการตรวจสอบด้วยมือที่คุณทำหลังจากมันตอบกลับ และต่อมา ก่อนที่คุณจะ merge โค้ดขึ้น production

ยิ่งคุณ encode การตรวจสอบเหล่านั้นได้มากเท่าไหร่ ผลตอบกลับแรกของ Claude ก็จะเข้าใกล้ผลลัพธ์สุดท้ายที่คุณคิดไว้มากขึ้นเท่านั้น

คุณใช้เวลาในการคอยดูแลน้อยลง และ Claude ก็สามารถทำงานต่อในขณะที่คุณทำอย่างอื่น

เขียนกระบวนการของคุณ

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

สำหรับ frontend โดยทั่วไปแล้วคือ: รัน dev server, เปิดเบราว์เซอร์, ตรวจสอบ console ว่ามี error ไหม, คลิกไปรอบๆ เหมือนที่ผู้ใช้ทำ และสังเกตสิ่งต่าง ๆ เช่น layout shift หรือการนำทางที่ช้า

ทุกโดเมนมีเวอร์ชันของตัวเอง ในแต่ละขั้นตอนเหล่านี้ มีแนวโน้มว่า Claude จะมีเครื่องมือที่ใช้สำหรับการตรวจสอบ:

เข้ารหัสกระบวนการของคุณเป็น skill

เมื่อกระบวนการชัดเจนแล้ว ให้เข้ารหัสให้มากที่สุดเท่าที่เป็นไปได้เป็น skill ติดตั้ง plugin \skill-creator\ จากนั้นให้ Claude สัมภาษณ์คุณ:

1/skill-creator สร้าง skill สำหรับตรวจสอบการเปลี่ยนแปลง frontend แบบ end-to-end สัมภาษณ์ฉันเกี่ยวกับขั้นตอนการทำงานของฉัน

ถ้าคุณมีปัญหาในการอธิบายกระบวนการของคุณ ให้ถาม Claude เกี่ยวกับแนวปฏิบัติที่ดีที่สุดของโดเมนก่อน และให้มันแสดงให้คุณเห็นว่าโฟลว์การตรวจสอบแบบ end-to-end อาจมีหน้าตาเป็นอย่างไร

รสนิยมและการตัดสินเป็นสิ่งที่ยากจะ codify แต่การตรวจสอบหลายอย่างมีเกณฑ์ที่ Claude ใช้วัด เช่น performance budget, accessibility checklist, กฎของ design system, ตัวอย่างที่ดีกับไม่ดี

ตัวอย่างเช่น skill frontend อาจรวมคำแนะนำในการบันทึก performance trace ผ่าน Chrome DevTools MCP หรือ Agent browser

1---
2name: frontend-verify
3description: ตรวจสอบการเปลี่ยนแปลง frontend ในเบราว์เซอร์ เรียกใช้ทุกครั้งที่มีการเปลี่ยนแปลง UI (หน้า, คอมโพเนนต์, ตัวพิมพ์, สไตล์ CSS)
4---
5
6# ตรวจสอบ frontend
7
8- เรียกใช้การตรวจสอบสองขั้นตอนในเบราว์เซอร์จริง
9- แก้ไขปัญหาและตรวจสอบซ้ำก่อนตอบกลับผู้ใช้
10
11## ขั้นตอนที่ 1 — ตรวจสอบว่าการเปลี่ยนแปลงทำงานตามที่คาดหวัง
12
131. เปิด URL ในเบราว์เซอร์:
14   - ในแอปเดสก์ท็อป Claude Code ให้ใช้ตัวอย่างในตัว (embedded preview)
15   - ใน CLI ให้ใช้ Chrome DevTools MCP
162. โต้ตอบกับอิลิเมนต์ใหม่และยืนยันว่ามัน render และทำงานตามที่คาดหวัง
17
18## ขั้นตอนที่ 2 — ตรวจสอบว่าการเปลี่ยนแปลงผ่านการตรวจสอบมือถือ
19
201. เปิด URL ในหน้าใหม่ผ่าน Chrome DevTools MCP
212. รัน performance trace และตรวจสอบ Core Web Vitals

การตรวจสอบอื่น ๆ มีลักษณะเชิงคุณภาพมากกว่าผ่าน/ไม่ผ่าน เช่น การเปรียบเทียบข้อมูลกับค่าปกติในอดีต สำหรับสิ่งเหล่านี้ คุณสามารถทำงานร่วมกับ Claude เพื่อตั้งเกณฑ์สำหรับการประเมินผลลัพธ์

ตรวจสอบโค้ดก่อน merge กับเอเจนต์ตัวที่สอง

ทุกอย่างข้างต้นเกิดขึ้นภายในวงวนของเอเจนต์ (agentic loop) มีขั้นตอนการตรวจสอบครั้งที่สอง ช่วงเวลาก่อนที่คุณจะ merge ซึ่งคุณสามารถขอให้เอเจนต์อื่นตรวจสอบได้

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

ตัวเลือกสองสามอย่าง ตั้งแต่แบบ manual ไปจนถึงแบบอัตโนมัติ:

• /review (skill ในตัว) — อ่าน PR อย่างรวดเร็วรอบเดียวใน terminal ของคุณ
• /code-review (plugin ที่ติดตั้งได้) — เปิด subagents หลายตัวพร้อมกัน แต่ละตัวอ่าน diff จากมุมที่แตกต่างกัน ให้คะแนนสิ่งที่พบตามความมั่นใจ และโพสต์ผลลัพธ์บน PR
• Claude Code Review — บริการที่มีการจัดการที่ทำงานโดยอัตโนมัติในทุก PR ผ่าน GitHub สำหรับแผน Team และ Enterprise

ไม่ว่าคุณจะเลือกแบบไหน การมีแนวป้องกันสุดท้ายก่อน merge ขึ้น production ก็มีประโยชน์

นำมารวมกัน

ตอนนี้คุณมีสองชั้น:

• การตรวจสอบที่ทำงานในขณะที่ Claude กำลังสร้าง
• การตรวจสอบก่อน merge จากเอเจนต์ที่ไม่ได้เขียนโค้ด

ทั้งสองอยู่ในวงจรการพัฒนาเดียวกัน ลองคิดถึงขั้นตอน manual ในปัจจุบันของคุณ: คุณทำการเปลี่ยนแปลง, ทำความสะอาด, ยืนยันว่ามันทำงาน, commit, เปิด PR, ให้ตรวจสอบ, และดู CI

คุณสามารถรวมขั้นตอนทั้งหมดเหล่านั้นเป็นเวิร์กโฟลว์เดียวโดยการเขียน skill ที่เรียกใช้ skills อื่น ๆ ตัวอย่างเช่น ทีม Claude Code มี skill ที่พวกเขาใช้เมื่อทำงานกับฟีเจอร์ โดยรวม:

1. Skill \/simplify\ เพื่อทำความสะอาด diff
2. Skill \/verify\ แบบกำหนดเองเพื่อยืนยันว่าการเปลี่ยนแปลงทำงานแบบ end-to-end
3. การตรวจสอบการออกแบบถ้า diff เกี่ยวข้องกับ UI
4. ขั้นตอนในการเปิดและติดตาม PR
5. Skill เพื่อดู CI และแก้ไขข้อผิดพลาดที่เกิดขึ้น

ในขณะที่เวิร์กโฟลว์ของคุณอาจแตกต่างกัน การสร้าง feedback loops และการรวม skills ช่วยให้ Claude สามารถตรวจสอบและดำเนินงานได้มากขึ้นแบบ end-to-end