Skip to content
ข่าวนี้คืออะไรในภาษาคนทำงาน
Claude Code ออกเวอร์ชัน v2.1.215 เมื่อวันที่ 19 กรกฎาคม 2026 ครับ
Release note มีการเปลี่ยนเพียงข้อเดียว:
Claude จะไม่เรียก
/verifyและ/code-reviewด้วยตัวเองอีกต่อไป หากต้องการใช้ ให้ผู้ใช้เรียกคำสั่งเหล่านี้เอง
แปลเป็นภาษาคนทำงานคือ หลัง Coding Agent แก้โค้ดเสร็จ เราไม่ควรสมมติว่ามันจะเปิดแอปตรวจของจริง และเรียกผู้ตรวจอีกชุดมาดู Diff ให้เองเสมอ
สองขั้นนี้ต้องอยู่ใน Finish Workflow ที่เขียนชัดครับ
/verify กับ /code-review ทำอะไรต่างกัน
สองคำสั่งนี้ไม่ได้ทำงานซ้ำกัน
/verify ดูว่าสิ่งที่สร้างขึ้นใช้งานได้จริงไหม
เอกสาร Claude Code อธิบายว่า /verify จะ build และ run แอป แล้วสังเกตผลลัพธ์จริง แทนที่จะพึ่งเฉพาะ test หรือ type check
ตัวอย่างเช่น:
- เปิดหน้าเว็บและดูว่า flow ใช้งานได้
- รัน CLI แล้วตรวจ output
- เรียก API และดู response
- เปรียบเทียบ screenshot กับแบบที่ต้องการ
Test ผ่านเป็นสัญญาณหนึ่งครับ แต่ UI อาจพัง, process อาจ start ไม่ขึ้น หรือ integration อาจทำงานไม่ครบก็ได้
/code-review ใช้มุมมองใหม่ตรวจ Diff
เอกสารทางการระบุว่า /code-review จะตรวจ Diff ปัจจุบัน โดยเน้น bug ด้าน correctness และดูโอกาส reuse, simplification หรือ efficiency บางส่วน
ประโยชน์คือ Agent ที่เพิ่งเขียนโค้ดมักมีเหตุผลของตัวเองติดอยู่ใน Context เดิม การให้ reviewer ดูเฉพาะ Diff กับกติกาของ repo ช่วยหาเรื่องที่ผู้ลงมืออาจมองข้าม
อย่างไรก็ตาม Code Review ไม่ได้แทน test, CI หรือคนรับผิดชอบงานครับ มันเป็นอีกชั้นของการตรวจ ไม่ใช่ใบรับประกัน
ทำไม Founder, Operator และทีมเล็กควรสนใจ
ทีมเล็กมักใช้ AI เพราะต้องการประหยัดเวลา แต่จุดที่เวลาไหลกลับไม่ใช่ตอนพิมพ์ Prompt ครับ มันเกิดตอนรับงานที่ยังไม่จบจริง
ตัวอย่างง่าย ๆ:
Founder สั่งให้ Agent เพิ่มแบบฟอร์มสมัครสมาชิก Agent แก้ไฟล์, รัน unit test แล้วตอบว่าเสร็จ แต่ไม่มีใครเปิดหน้าเว็บจริง จึงไม่เห็นว่าปุ่ม Submit ถูกแถบ Cookie บังบนมือถือ
งานเขียนโค้ดเสร็จ แต่ Outcome ยังไม่เสร็จ
💡 ในความเห็นของผม Release นี้เป็นการเตือนที่ดีว่า Automation ที่สำคัญต้องอยู่ใน workflow ที่มองเห็นได้ ไม่ควรฝากไว้กับความหวังว่า Agent จะนึกได้เองทุก Session
เรื่องนี้ไม่ได้ใช้กับ Claude Code เท่านั้นครับ ไม่ว่าจะเป็น Codex, Gemini CLI, Qwen Code หรือ Agent ภายในทีม ทุกตัวควรมี Finish Sequence ที่บอกว่าเมื่อไรถือว่างานจบ
เอาไปใช้กับงานจริงอย่างไร
1. เขียน Definition of Done ก่อนเริ่ม
อย่าเริ่มจากคำสั่งว่า “ช่วยแก้ Checkout” อย่างเดียว
เพิ่มสิ่งที่ต้องเห็นตอนจบ เช่น:
Definition of Done
- ผู้ใช้ใส่ Coupon ที่ถูกต้องได้
- Coupon ผิด Product ถูกปฏิเสธ
- Test ที่เกี่ยวข้องผ่าน
- เปิดหน้า Checkout และทดสอบ flow จริง
- สรุป Diff และข้อจำกัดที่ยังเหลือ
- ห้าม Deployพอมีเส้นชัย Agent จะรู้ว่าต้องเก็บหลักฐานอะไร ไม่ใช่หยุดเมื่อโค้ดดูสมเหตุผล
2. แยก Implement ออกจาก Verify
Session แรกทำงานให้เสร็จตาม scope
จากนั้นเรียก /verify เพื่อดู behavior จริง ควรบอกด้วยว่าจะตรวจอะไร เช่น viewport มือถือ, API response, CLI output หรือ workflow สำคัญ
ถ้าโปรเจกต์มีวิธี start ที่ซับซ้อน เอกสาร Claude Code แนะนำให้ใช้ /run-skill-generator บันทึกขั้นตอน build และ launch เป็น project skill เพื่อไม่ให้ Agent เดาวิธีเปิดระบบใหม่ทุกครั้ง
3. ให้ Review ดู Diff ไม่ใช่ฟัง Summary อย่างเดียว
หลัง verify ให้เรียก /code-review กับ Diff ที่ต้องการตรวจ
คำสั่งนี้รองรับ target ได้ เช่น branch, PR, file หรือ ref range ทีมจึงควรกำหนดฐานเปรียบเทียบให้ถูก โดยเฉพาะ repo ที่ไม่ได้ merge เข้า main
ตั้งโจทย์ review ให้แคบและมีประโยชน์ เช่น:
ตรวจเฉพาะ bug ที่กระทบ acceptance criteria
ดู edge case ของ Coupon และ error handling
ไม่เสนอ refactor ที่ไม่เกี่ยวกับงานนี้Review ที่ไม่มีขอบเขตอาจสร้างรายการปรับปรุงยาวกว่าตัวงานครับ
4. ปิดงานด้วยหลักฐาน 4 ชิ้น
ก่อนรับงาน ให้ขออย่างน้อย:
- Test หรือ build command พร้อมผลลัพธ์
- หลักฐานจาก
/verifyเช่น screenshot, response หรือ output - สรุป findings จาก
/code-reviewและสิ่งที่แก้ตาม - Git Diff ที่ไม่มีไฟล์นอก scope
คำว่า “เสร็จแล้ว” ไม่มีข้อมูลพอสำหรับตัดสินใจ แต่หลักฐานสี่ชิ้นนี้ช่วยให้คน review เร็วขึ้นมาก
5. ถ้าต้องการ Auto จริง ให้เขียนเป็นระบบ
การเรียกสอง skill ด้วยตัวเองเหมาะกับงานทั่วไป เพราะคนเลือกได้ว่างานไหนต้องตรวจลึกแค่ไหน
แต่ถ้าเป็น workflow ซ้ำ เช่น ทุก PR ต้องรัน test ชุดเดิมและตรวจ policy เดิม อย่าหวังให้ Prompt จำเองครับ ย้ายสิ่งที่ deterministic ไปไว้ใน CI, script หรือ Stop hook ที่ทีมดูแลได้
ใช้ Agent กับงานที่ต้องตีความ ใช้ script กับเงื่อนไขที่ต้องเหมือนเดิมทุกครั้ง
Operator Kit: Explicit QA Finish Checklist
คัดลอกส่วนนี้ไปวางใน issue, PR template หรือ Session handoff ได้ทันที
A. Scope และเส้นชัย
- [ ] Goal ของงานเขียนเป็นผลลัพธ์ที่ตรวจได้
- [ ] ระบุ In scope และ Out of scope
- [ ] ระบุคำสั่ง test, build หรือ lint ที่ต้องรัน
- [ ] ระบุ behavior จริงที่ต้องเปิดดู
- [ ] ระบุ action ที่ Agent ห้ามทำเอง เช่น Deploy หรือแก้ Production data
B. Implement
- [ ] Agent สรุปไฟล์ที่แก้และเหตุผล
- [ ] ไม่มีไฟล์นอก scope หรือ generated file ที่ไม่ตั้งใจ
- [ ] Test ที่เกี่ยวข้องผ่าน พร้อม output ล่าสุด
- [ ] ปัญหาที่เหลือถูกเขียนเป็น caveat ไม่ถูกซ่อนใน summary
C. Verify
/verify
ตรวจ behavior ตาม Definition of Done
เปิดของจริงและเก็บ screenshot, response หรือ command output
ถ้าพบข้อผิดพลาด ให้แก้แล้ว verify ซ้ำ- [ ] ของจริง start หรือเปิดได้
- [ ] Happy path ผ่าน
- [ ] Error path สำคัญผ่าน
- [ ] หน้าจอหรือ output ตรงกับสิ่งที่ตกลง
D. Code Review
/code-review
ตรวจ Diff นี้หา correctness bug และ regression
อ้างอิง acceptance criteria
ไม่เสนอ refactor นอก scope- [ ] Findings ถูกแยกเป็นต้องแก้กับ optional
- [ ] Finding ที่ต้องแก้ถูกแก้และตรวจซ้ำ
- [ ] ถ้าไม่แก้ มีเหตุผลและเจ้าของความเสี่ยงชัด
E. Handoff
Goal:
ไฟล์ที่เปลี่ยน:
Test และ Build:
หลักฐานจาก Verify:
ผล Code Review:
Caveat:
Next action:
คนรับงาน:- [ ] คนรับงานอ่าน Handoff แล้วตัดสินใจได้โดยไม่ต้องถามใหม่ทั้งหมด
- [ ] Diff, test result และหลักฐานอ้างถึง revision เดียวกัน
- [ ] ยังไม่มีการ Deploy จนกว่าจะได้รับอนุมัติตาม workflow ของทีม
ข้อจำกัดที่ควรรู้
Release note นี้สั้นมากครับ เรารู้แน่เพียงว่า Claude Code จะไม่เรียก /verify และ /code-review เองอีกต่อไป แต่ source ไม่ได้อธิบายเหตุผลของการเปลี่ยน default behavior
อย่าตีความกว้างว่า Claude Code “หยุดตรวจงานทุกแบบ” เพราะคำสั่ง test หรือ build ที่อยู่ใน Prompt, /goal, CI, hook และ auto verification ใน surface อื่นอาจยังทำงานตาม configuration ของมัน
อีกเรื่องคือ /verify ต้องเปิดหรือรันโปรเจกต์จริง ถ้า environment ขาด database, env file หรือ dependency ผลลัพธ์อาจเป็น setup failure ไม่ใช่ product failure ทีมควรบันทึก run recipe และใช้ environment ที่ย้อนกลับได้
ส่วน /code-review ช่วยหา bug ได้ แต่มี false positive และไม่ block merge ให้เองโดยอัตโนมัติ ควรอ่าน finding เทียบกับโค้ด, acceptance criteria และผล test ก่อนตัดสินใจ
สรุป
Claude Code v2.1.215 ไม่ได้มี feature ใหม่ยาวเหยียดครับ แต่เปลี่ยนความคาดหวังตอนจบงานให้ชัดขึ้น
จากนี้ถ้าต้องการ /verify และ /code-review เราต้องเรียกเอง
บทเรียนที่ใหญ่กว่าตัว Tool คือ อย่าปล่อยให้คำว่า “เสร็จ” ของ Coding Agent ขึ้นกับพฤติกรรมอัตโนมัติที่ไม่ได้เขียนไว้ใน workflow
กำหนด Definition of Done, เปิดของจริง, ตรวจ Diff และรับงานจากหลักฐาน แล้ว Agent จะช่วยประหยัดเวลาได้จริงกว่าเดิมครับ
Data-Espresso และ OPB Stack จะช่วยแปลงข่าว AI ให้เป็น workflow, SOP และ toolkit ที่ Founder กับทีมเล็กหยิบไปใช้กับงานจริงได้ครับ