Code Review ด้วย Claude Code: จับบั๊กก่อนขึ้นโปรดักชัน

Claude Code Review คืออะไร?

Claude Code Review เป็นระบบรีวิวโค้ดแบบหลายเอเจนต์ที่ตรวจสอบ PR ในบริบทของรีโปและรายงานบั๊กที่เป็นไปได้ ประเด็นความปลอดภัย และรีเกรสชัน GitHub Code Review จะรันเอเจนต์เหล่านั้นกับ PR บน GitHub ส่วน /code-review แบบโลคัลจะรีวิวความต่างของโค้ดปัจจุบันจาก Claude Code โดยตรง

คำสำคัญคือ “บริบท” การรีวิว diff แบบดั้งเดิมจะให้คนตรวจเฉพาะบรรทัดที่เปลี่ยน แต่เอเจนต์ของ Claude จะพิจารณาการเปลี่ยนแปลงนั้นในบริบททั้งรีโป เวิร์กโฟลว์บน GitHub มีเอเจนต์เฉพาะทางหลายตัวทำงานขนานกัน ตามด้วยการยืนยันผล การตัดซ้ำ และการจัดอันดับความรุนแรง

เช่น การเปลี่ยน 10 บรรทัดในทรานส์ฟอร์เมชันของ pandas อาจขึ้นกับสคีมาที่มาจากโมเดล dbt ต้นน้ำ เกรนของตาราง Snowflake และสมมติฐานในแดชบอร์ดปลายน้ำ

Claude ไม่อนุมัติหรือบล็อก PR GitHub Code Review รายงานผลเช็คแบบเป็นกลาง ดังนั้นกฎป้องกันสาขาที่ยังมีอยู่จะไม่เปลี่ยน เว้นแต่จะสร้างลอจิก CI ของทีมเองครอบทับผลเช็ค

สามช่องทางการรีวิว

ปัจจุบันมี 3 วิธีหลักในการรีวิวโค้ดด้วย Claude Code

คำสั่ง /code-review แบบโลคัลจะตรวจคอมมิตในสาขาของคุณ นอกจากนี้ยังระบุไฟล์ สาขา เลข PR หรือช่วง Git ref เฉพาะได้

GitHub Code Review ถูกออกแบบให้ยึดกับตัว PR เอง ตามการตั้งค่ารีโป มันอาจรีวิวหนึ่งครั้งหลังสร้าง PR หลังทุกการ push หรือเฉพาะเมื่อมีคนร้องขอด้วย @claude review

/code-review ultra เป็นตัวเลือกที่หนักกว่า Anthropic เรียกฟีเจอร์นี้ว่า ultrareview และ /ultrareview ใช้แทนได้เมื่อบัญชีของคุณเปิดใช้ มันรันเอเจนต์รีวิวเป็นฝูงใน sandbox ระยะไกล โดยบั๊กแต่ละข้อจะถูกทำซ้ำและยืนยันก่อนแสดงในผลค้นพบ ปัจจุบันเป็นรุ่นวิจัยและใช้เวลาประมาณ 5 ถึง 10 นาทีต่อรีวิว

สิ่งที่ Claude จะติดธงเทียบกับสิ่งที่ข้าม

Claude Code Review เน้นความถูกต้องเป็นอันดับแรก เอกสารของ Anthropic แยกชัดเจนระหว่างบั๊กที่กระทบโปรดักชัน กับความชอบด้านรูปแบบและการขาดแคลนเทสต์

ข้อค้นพบแบ่งเป็น 3 ระดับความรุนแรง:

การแยกแยะนี้มีประโยชน์ เพราะนักวิทยาศาสตร์ข้อมูลมักมีมุมมองต่างกันมากว่าควรใช้เวลารีวิวกับอะไรบ้าง คำแนะนำเรื่องชื่ออย่าง revenue_df เทียบกับ weekly_revenue ไม่ใช่หมวดเดียวกับการคูณรายได้เป็น 2 เนื่องจาก many-to-many join หลุดเข้าไปใน ทรานส์ฟอร์เมชัน

ตั้งค่า Code Review ใน Claude Code อย่างไร?

การตั้งค่า Claude Code Review แตกต่างกันตามว่าต้องการรีวิวโลคัลหรือรีวิว PR บน GitHub /code-review แบบโลคัลไม่ต้องใช้ GitHub App และทำได้ก่อนเปิด PR

ส่วน GitHub Code Review ต้องให้ Owner หรือ Primary Owner ขององค์กรตั้งค่า Claude GitHub App และเลือกรีโป เมื่อทำ PR reviews ควรสร้างไฟล์เฉพาะชื่อ REVIEW.md เพื่อเก็บกติการีวิว

CLAUDE.md เทียบกับ REVIEW.md

CLAUDE.md และ REVIEW.md มีวัตถุประสงค์ต่างกัน การเอามาปนกันเป็นวิธีที่ทำให้รีวิวมีสัญญาณรบกวนได้ง่าย

CLAUDE.md ใส่คำแนะนำทั่วไปของโปรเจ็กต์ที่ Claude ใช้ข้ามงานต่าง ๆ การรีวิวโค้ดก็อ่านคำแนะนำนี้ด้วย และการละเมิดกติกาใหม่ ๆ จะถูกรายงานเป็นประเด็นเล็กน้อย ส่วน REVIEW.md ใช้กำหนดพฤติกรรมรีวิวโดยเฉพาะ บอกเอเจนต์รีวิวว่าทีมต้องการให้ติดธง ข้าม หรือจัดเป็น “สำคัญ” อย่างไร

สำหรับรีโปข้อมูลภาษา Python ควรให้ CLAUDE.md โฟกัสกับโครงสร้างรีโป วิธีรัน pytest ใช้ pandas หรือ polars และที่อยู่ของโมเดล SQL

ส่วนกติการีวิวให้ใส่ใน REVIEW.md ตัวอย่างเช่น:

• “ตรวจว่าทุกทรานส์ฟอร์เมชันใหม่มีเทสต์ที่สอดคล้อง”
• “ห้ามล็อกข้อมูลรับรอง”
• “ข้ามไฟล์ที่ถูกสร้างอัตโนมัติ”

ตัวอย่าง REVIEW.md ขนาดเล็กอาจมีหน้าตาแบบนี้:

# Review instructions

## Important findings

Report as Important:
- Incorrect joins or filters that can change dataset grain
- Missing tenant or customer scoping
- Secrets or credentials written to logs
- Silent changes to revenue or customer metrics

## Do not report
- Formatting already enforced by Ruff
- Generated files
- *.lock files

## Always check
- New transformations have tests
- Joins use the intended keys
- Datetime operations specify timezone assumptions
- Missing values are handled explicitly

แนะนำให้คง REVIEW.md ให้กระชับ เพราะคำสั่งยาวเกินไปจะทำให้กติกาสำคัญเจือจาง การทำงานปัจจุบันอ่านไฟล์เป็นคำสั่งตรง ๆ จึงควรใส่กติกาลงไปโดยตรงแทนการใช้ชอร์ตคัต @

ทั้งนี้ ระหว่างพัฒนาแบบโลคัล /code-review จะไม่อ่าน REVIEW.md มันจะทำตาม CLAUDE.md ขณะที่ไปป์ไลน์ GitHub Code Review จะใช้ REVIEW.md สำหรับคำสั่งเฉพาะรีวิว

หากต้องการใช้กติการีวิวเดียวกันทั้งโลคัลและ GitHub ให้วางกติกาทั่วไปไว้ใน CLAUDE.md และคัดสำเนากติกาเฉพาะรีวิวไปยัง REVIEW.md เท่าที่จำเป็น

อ่านเพิ่มเติมได้ใน คู่มือการเขียนไฟล์ CLAUDE.md ที่ดีที่สุด

GitHub App และโหมดทริกเกอร์

GitHub Code Review ถูกตั้งค่าโดย Owner หรือ Primary Owner ขององค์กรผ่านหน้าผู้ดูแลของ Claude แอดมินต้องติดตั้ง Claude GitHub App ให้สิทธิ์เข้าถึงรีโป เลือกรีโปที่จะรีวิว และกำหนดพฤติกรรมรีวิวให้แต่ละรีโป

มีโหมดทริกเกอร์ 3 แบบ:

ข้อยกเว้นของทั้ง 3 แบบ: Claude จะไม่รีวิว PR จาก fork โดยอัตโนมัติ ต้องมีคนคอมเมนต์ @claude review ลงไป

ณ อัปเดตเดือนกรกฎาคม 2026 คำสั่งแมนนวลมีการเปลี่ยนแปลงดังนี้: 

• @claude review เริ่มรีวิวเดี่ยว และจะไม่สมัครรับการรีวิวสำหรับการ push ครั้งถัดไป

• @claude review always เริ่มรีวิวและสมัครรับการรีวิวที่ทริกเกอร์ด้วยการ push ในอนาคต

• @claude review once ทำงานเหมือนคำสั่งเปล่า

หากเรียนรู้ Claude Code Review ตั้งแต่ต้นปี 2026 บทเรียนเก่าอาจบอกว่า @claude review จะสมัครรับการรีวิวในอนาคต แต่พฤติกรรมนั้นเปลี่ยนในกรกฎาคม 2026 และยังคงเป็นจริงถึงกันยายน 2026

ผู้ใช้ Pro และ Max ที่ไม่มีสิทธิ์ใช้ GitHub Code Review ขององค์กรสามารถข้าม App ไปเลยและใช้ /code-review แบบโลคัล พร้อม /code-review ultra เมื่อต้องการรีวิวเชิงลึก

จะรีวิว diff แบบโลคัลด้วย /code-review อย่างไร?

คำสั่ง /code-review แบบโลคัลจะรีวิวสาขาปัจจุบันก่อนเปิด PR มักเริ่มจากตรงนี้เพราะช่วยจับปัญหาได้ตอนยังพัฒนาอยู่ และอาจป้องกัน CI ล้ม

กรณีสำหรับรีวิว

สมมติว่ามีรีโปอีคอมเมิร์ซที่มีตารางคำสั่งซื้อประกอบด้วย order_id, customer_id, order_date, status และ revenue และเราสร้าง weekly_revenue.py เพื่อคำนวณรายได้รายสัปดาห์:

orders = load_orders()
customers = load_customers()

# Derive the reporting week from the order date
orders["week"] = orders["order_date"].dt.to_period("W").dt.start_time

weekly_revenue = (
    orders
    .merge(customers, on="customer_id", how="inner")
    .groupby("week", as_index=False)["revenue"]
    .sum()
)

มองเผิน ๆ ไม่มีอะไรแปลก merge() ระบุชัดเจน การจัดกลุ่มอ่านง่าย และรวมรายได้หลัง join

ปัญหาคือ ตารางลูกค้ามีประวัติหลายเรคอร์ดสำหรับบางลูกค้า ลูกค้าที่มี 2 เรคอร์ดจะสร้าง 2 แถวหลัง join ทำให้รายได้ของลูกค้านั้นถูกคูณสอง นี่เป็นบั๊กที่มองข้ามได้ง่ายเมื่ออ่านทรานส์ฟอร์เมชันตรง ๆ โดยไม่ตรวจเกรนของตาราง

กำหนดขอบเขต diff

จากเซสชัน Claude Code ให้รัน /code-review

คำสั่งจะรีวิวคอมมิตของสาขาปัจจุบันที่นำหน้าสาขาต้นน้ำ รวมทั้งการเปลี่ยนแปลงที่ยังไม่คอมมิต คุณยังสามารถระบุไฟล์ สาขา PR หรือช่วง เช่น main...feature/weekly-revenue

เช่น:

/code-review weekly_revenue.py

หรือ:

/code-review main...feature/weekly-revenue

ยังสามารถส่งระดับความพยายาม เช่น /code-review high ที่ระดับ low และ medium รายงานเฉพาะข้อค้นพบที่มั่นใจสูง ขณะที่ high ถึง max ขยายความครอบคลุมโดยแลกกับโอกาส false positive ที่มากขึ้น

ใช้แฟล็กเพื่อกำหนดทิศทางรีวิว

เมื่อคุ้นกับเวิร์กโฟลว์แล้ว จะมีสองแฟล็กที่มีประโยชน์:

• --fix นำข้อค้นพบไปใช้กับ working tree หลังรีวิว

• --comment โพสต์เป็นคอมเมนต์อินไลน์

Claude รันรีวิวเป็นซับเอเจนต์เบื้องหลัง จึงทำงานต่อไปได้ระหว่างประมวลผล เมื่อเสร็จ ข้อค้นหาจะส่งกลับมายังเซสชัน

ผลรีวิวอาจรายงานลักษณะนี้:

🔴 Important
weekly_revenue.py:9

The merge on customer_id can duplicate order rows because
customers contains multiple records per customer. This can
inflate revenue when a customer has more than one matching
customer record.

Verify that customer_id is unique in customers or join against
the intended current-record subset before aggregating revenue.

รีวิวพบโหมดความล้มเหลวที่เป็นรูปธรรมและให้สิ่งที่สามารถยืนยันกับสคีมาจริงได้ แทนการให้เชื่อการตัดสินของ Claude ล้วน ๆ

อ่านข้อค้นพบ

ควรตรวจเองด้วยก่อนรัน /code-review --fix ค้นหาโค้ดที่สร้าง customers ตรวจข้อจำกัดความเป็นเอกลักษณ์ และดูเทสต์ของ weekly_revenue.py

หาก customers.customer_id เป็นเอกลักษณ์จริง ข้อค้นพบของ Claude คือ false positive หากตารางมีหนึ่งแถวต่อหนึ่งลูกค้าต่อ effective date ข้อค้นพบเป็นของจริงและต้องแก้ทรานส์ฟอร์เมชัน

ประเด็นสำคัญคือผู้รีวิวของ Claude มองพฤติกรรมโค้ด ขณะที่เรายังต้องรับผิดชอบรู้ว่าข้อมูลแทนอะไร

คุณสามารถให้ Claude สืบต่อหลังรีวิวได้:

Investigate the customer_id join finding.
Check how the customers table is built and determine whether
customer_id is unique at the point of this merge. Do not modify
the code yet.

ขั้นตอนที่สองนี้มักมีประโยชน์กว่าการให้ Claude แก้ตามคอมเมนต์แบบไม่ลืมหูลืมตา มันทำให้การรีวิวกลายเป็นการสืบค้นสั้น ๆ แทนการสร้างโค้ด

จะรัน Claude Code Review บน PR ของ GitHub อย่างไร?

GitHub Code Review วางข้อค้นพบของ Claude ลงใน PR โดยตรง ทำให้ผู้รีวิวเห็นปัญหาข้าง ๆ โค้ดที่เปลี่ยน

ลำดับมีความสำคัญ เพราะรีวิวจะผูกกับ PR ที่มีอยู่แล้ว:

1. push สาขา weekly-revenue ไป GitHub ด้วย git push

2. เปิด pull request Claude รีวิวได้เฉพาะ PR ที่เปิดแล้ว จึงยังไม่เกิดอะไรขึ้นก่อนหน้านี้

3. ถ้ารีโปตั้งค่าเป็นอัตโนมัติ รีวิวจะเริ่มเอง หากเป็นโหมดแมนนวล ให้โพสต์ @claude review เป็นคอมเมนต์ระดับบนของ PR เพื่อเริ่ม

มี 3 เงื่อนไขที่มักสะดุด คำสั่งต้องเป็นคอมเมนต์ ระดับบน ของ PR ไม่ใช่การตอบคอมเมนต์อินไลน์ และต้องมีสิทธิ์ write, maintain หรือ admin บนรีโป คำสั่งยังต้องขึ้นต้นคอมเมนต์ โดยมี once หรือ always ในบรรทัดเดียวกันถ้ามี

ทริกเกอร์การรีวิว

ตัวเลือกที่ส่งผลค่าใช้จ่ายจริงคือระหว่าง 2 คำสั่งแมนนวล ไม่ใช่ระหว่างแมนนวลกับอัตโนมัติ

@claude review รันรีวิวครั้งเดียวและไม่สมัครรับ @claude review always รันรีวิวและสมัครรับ ดังนั้นการ push ต่อ ๆ ไปจะเริ่มรีวิวใหม่

นี่คือพฤติกรรมหลังกรกฎาคม 2026 และยังเป็นจริงถึงกันยายน 2026 ก่อนหน้านั้นคำสั่ง @claude review เปล่าจะสมัครรับรีวิวในอนาคต หากตามบทเรียนเก่า ให้ตรวจจุดนี้ก่อน

การรีวิวมักใช้เวลาประมาณ 20 นาที แม้ Anthropic ระบุว่าค่าใช้จ่ายและระยะเวลาขึ้นกับขนาดและความซับซ้อนของ PR แต่ละรีวิวคิดค่าใช้จ่ายแยกผ่านเครดิตการใช้งาน ไม่หักจากการใช้งานรวมของแพ็กเกจ Team หรือ Enterprise หากต้องการทราบโครงสร้างค่าใช้จ่ายเพิ่มเติม แนะนำให้อ่าน คู่มือขีดจำกัดการใช้งาน Claude Code

อ่านคอมเมนต์อินไลน์และผล check run

เมื่อรีวิวเสร็จ Claude จะโพสต์คอมเมนต์อินไลน์บนบรรทัดที่เกี่ยวข้อง ผลการตรวจเช็คบน GitHub ยังมีสรุประดับความรุนแรง ซึ่งมีประโยชน์เมื่อ PR มีหลายข้อค้นพบกระจายระหว่าง weekly_revenue.py โมเดล SQL และไฟล์เทสต์

ตัวอย่าง:

คอมเมนต์อินไลน์คือที่สำหรับสืบหาสาเหตุจริง ส่วน check run ใช้ดูภาพรวมของรีวิว

หมายเหตุ: การกด 👍 หรือ 👎 จะไม่ทริกเกอร์รีวิวใหม่ และการตอบคอมเมนต์อินไลน์จะไม่ทำให้ Claude ตอบกลับ หากต้องการรีวิวอีกครั้ง ให้แก้โค้ดแล้ว push หรือโพสต์ @claude review เป็นคอมเมนต์ระดับบนใหม่

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

จะคัดแยกคอมเมนต์รีวิวของ Claude อย่างไร?

ประเด็นคือการคง มนุษย์ไว้ในวงจร ระหว่างการรีวิว นั่นหมายความว่าทุกรีวิวของ Claude ต้องตัดสินว่าข้อค้นพบแต่ละรายการเป็นบั๊กจริง เป็นการปรับปรุงที่ไม่บล็อก หรือเป็น false positive เพราะผู้รีวิวโค้ดตรวจพฤติกรรมการทำงานได้โดยไม่จำเป็นต้องรู้สมมติฐานธุรกิจทุกอย่างของชุดข้อมูลหรือเมตริก

ใช้การตัดสินใจแบบ 3 ทางง่าย ๆ:

หมวดสุดท้ายนี้สำคัญ ผู้รีวิวที่รายงาน 30 รายการไม่ได้ดีกว่าคนที่รายงาน 5 รายการเสมอไป คอมเมนต์ false-positive เกี่ยวกับการ merge ของ pandas อาจเสียเวลามากกว่าโค้ดที่เปลี่ยนจริง

แก้ ข้าม หรือโต้แย้ง

หากบั๊กแถวลูกค้าที่ซ้ำเป็นเรื่องจริง อาจให้ Claude ตรวจโมเดลต้นน้ำแล้วแก้ตามนี้:

The customer_id finding is valid. Inspect the existing customer
model and update weekly_revenue.py to join only the current
customer record. Add a regression test for a customer with
multiple historical records, then run the relevant tests.

จากนั้น Claude สามารถตรวจรีโป แก้โค้ด Python เพิ่มเทสต์ และรันชุดเทสต์

หากต้องการทำงานจากคอมเมนต์บน GitHub Claude Code ยังโต้ตอบกับรีโปได้ผ่าน GitHub CLI (gh) ประเด็นสำคัญคือควรเลือกเฉพาะการแก้ที่คิดว่าเหมาะสม แทนการให้มัน “แก้ทุกอย่าง” ตามรีวิวทั้งหมด

นี่ทำให้นักพัฒนาอยู่ในวงจรรีวิว:

1. Claude พบปัญหาที่เป็นไปได้
2. ฉันยืนยันปัญหากับโค้ดและสมมติฐานข้อมูล
3. Claude ทำการแก้ที่ร้องขอ
4. รันเทสต์
5. Claude รีวิว diff ที่เกิดขึ้นอีกครั้ง

ลูปนี้ปลอดภัยกว่าการมองผลรีวิวแรกเป็นคิวรีแฟกเตอร์อัตโนมัติ

PR ข้อมูลยังต้องพึ่งมนุษย์เรื่องใด?

โหมดความล้มเหลวที่ Claude ครอบคลุมไม่ได้คือโค้ดที่ทำงานถูกต้องแต่ยังทำสิ่งที่ผิด สามเวอร์ชันของปัญหานี้พบเสมอ:

• สมมติฐานนอก diff Claude อ่านรีโปของคุณ ไม่ใช่ data warehouse, บริการคอนฟิก หรือสัญญาที่ทีมอื่นถือ การ join อาจใช้คีย์ที่ถูกและยังเปลี่ยนเกรนผลลัพธ์ได้ เพราะจำนวนแถวต่อคีย์เป็นคุณสมบัติของตารางต้นน้ำ ไม่ใช่โค้ดตรงหน้า

• นิยามที่มีเฉพาะทีมคุณ รายได้ควรถูกรวมที่ระดับคำสั่ง ลูกค้า หรือสัปดาห์ เป็นการตัดสินใจเชิงธุรกิจ Claude บอกได้แค่ว่า groupby() จะรวมสิ่งที่ส่งให้ แต่บอกไม่ได้ว่าตัวเลขใดที่ฝ่ายการเงินรับรอง

• สมมติฐานด้านเวลาและชนิดข้อมูล 2026-08-27 หมายถึงวัน UTC วันทำการท้องถิ่น หรือวันที่รายงานที่โมเดลต้นน้ำกำหนด? การบังคับชนิดโดยเงียบ ๆ ก็เหมือนกัน: การทำงานข้ามคอลัมน์ชนิด object, จำนวนเต็มที่เป็นค่าว่างได้, datetime ที่มีโซนเวลา และสตริง อาจให้ผลลัพธ์ที่ดูสมเหตุสมผลแต่เปลี่ยนพฤติกรรมการเปรียบเทียบอย่างเงียบ ๆ

การรั่วไหลของข้อมูลเป็นตัวอย่างชัดเจนข้อแรก ฟีเจอร์ทรานส์ฟอร์เมชันอาจ join ชุดฝึกกับตารางที่มีข้อมูลซึ่งเกิดหลังวันที่พยากรณ์ Join ถูกต้อง จำนวนแถวตามคาด แต่โมเดลปนเปื้อน

ดังนั้นจึงมอง Claude เป็นผู้รีวิวพฤติกรรมการติดตั้ง ไม่ใช่เจ้าของนิยาม

ควรใช้ Code Review หรือ Ultrareview เมื่อไร?

ใช้ /code-review เพื่อฟีดแบ็กแบบเร็วบนโลคัล และ /code-review ultra สำหรับการตรวจเข้มก่อน merge ทั้งสองอย่างรีวิวโค้ด แต่ /code-review ออกแบบเพื่อการวนซ้ำ ขณะที่ ultra รันเอเจนต์ระยะไกลหลายตัวและยืนยันบั๊กอย่างอิสระ

Anthropic ระบุว่า ultra review ยังเป็นรุ่นวิจัย ผู้สมัคร Pro และ Max ได้รันฟรี 3 ครั้งแบบครั้งเดียวที่ไม่รีเฟรช หลังจากนั้นรีวิวมักมีค่าใช้จ่าย $5 ถึง $25 ตามขนาดการเปลี่ยนแปลง ผู้ใช้ Team และ Enterprise จะไม่ได้รับสิทธิ์ฟรีนี้ และฟีเจอร์ใช้ไม่ได้บน Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry และสำหรับองค์กรที่เปิดใช้งาน Zero Data Retention

ความแตกต่างสำคัญคือการยืนยันผล /code-review ultra จะส่งสถานะรีโปไปยัง sandbox ระยะไกลและรันเอเจนต์เป็นฝูง โดยบั๊กรายงานจะถูกทำซ้ำอย่างอิสระก่อนส่งกลับเป็นข้อค้นพบ

ไม่ควรรันทุกคอมมิต หากเปลี่ยนชื่อตัวแปรในโน้ตบุ๊ก Python หรือปรับรูปแบบโมเดล dbt การรีวิวแบบโลคัล /code-review ก็พอ แต่หากเปลี่ยนลอจิกการสร้างฟีเจอร์ของโมเดลโปรดักชัน เขียนใหม่ทรานส์ฟอร์เมชันรายได้ หรือแก้รวมระดับลูกค้า การรีวิวรอบพิเศษจะสมเหตุสมผลกว่า

มีรายละเอียดชื่อเรียกที่ควรถูกต้องด้วย คำสั่งที่บันทึกคือ /code-review ultra และ /ultrareview เป็น alias ที่ใช้ได้เมื่อบัญชีเปิดใช้ ultrareview บทเรียนเก่ามักยก /ultrareview เป็นคำสั่งหลัก แต่เอกสารของ Anthropic ปัจจุบันมองรีวิวเชิงลึกบนคลาวด์เป็นส่วนหนึ่งของตระกูลคำสั่ง /code-review และ /code-review ultra จะ fallback เป็นรีวิวโลคัลเมื่อฟีเจอร์คลาวด์ใช้ไม่ได้

รัน ultra review บน PR เดียวกัน

จากรีโป ให้รัน:

/code-review ultra

เพื่อรีวิว PR ของ GitHub โดยตรง:

/code-review ultra <pr#>

หากไม่ระบุอาร์กิวเมนต์ /code-review ultra จะเปรียบเทียบสาขาปัจจุบันกับสาขาค่าเริ่มต้น รวมทั้งการเปลี่ยนแปลงที่ยังไม่คอมมิตและที่สเตจไว้ การรีวิวสาขาจะจำกัดที่ประมาณ 500 ไฟล์และ 8,000 บรรทัดที่เปลี่ยนตามค่าเริ่มต้น แม้ตัวเลขอาจเปลี่ยนได้ หาก diff ใหญ่เกินไป ให้ push สาขาแล้วรีวิวเป็น PR แทน

หากระบุเลข PR สภาพแวดล้อมระยะไกลจะโคลน PR จาก GitHub โดยไม่มีการอัปโหลดจากเครื่องของคุณ

ก่อนเริ่ม Claude จะแสดงขอบเขตรีวิว จำนวนครั้งฟรีที่เหลือ และค่าประมาณค่าใช้จ่าย ยืนยันแล้วการรีวิวจะรันเบื้องหลัง ทำให้ใช้งาน Claude Code ต่อได้ระหว่างเอเจนต์ระยะไกลทำงาน

สำหรับตัวอย่าง weekly_revenue.py จะเปรียบเทียบข้อค้นพบ แทนการสันนิษฐานว่ารีวิวเชิงลึกต้องถูกกว่าเสมอ

หาก /code-review ติดธงการ join ลูกค้า และ ultra review ทำซ้ำการทำซ้ำรายได้อย่างอิสระ ความเชื่อมั่นในข้อค้นพบนั้นจะเพิ่มขึ้น หาก ultra review มองข้ามเพราะตารางต้นน้ำรับประกันเอกลักษณ์ จะตรวจหลักฐานจากทั้งสองรีวิวและคำนิยามโมเดลจริงก่อนแก้โค้ด

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

ยังมีเรื่องค่าใช้จ่ายประกอบ ปัจจุบัน GitHub Code Review เฉลี่ย $15 ถึง $25 ต่อรีวิว ขณะที่ ultra review มักอยู่ที่ $5 ถึง $25 หลังการรันฟรีสำหรับ Pro และ Max ค่าใช้จ่ายของ GitHub Code Review แยกจากการใช้งานที่รวมในแพ็กเกจ และ Anthropic มีเครื่องมือควบคุมค่าใช้จ่ายสำหรับองค์กร

หากทำงานคนเดียว การใช้ /code-review แบบโลคัลร่วมกับ /code-review ultra เป็นครั้งคราว ถือเป็นเวิร์กโฟลว์เริ่มต้นที่เหมาะสม หากอยู่บนแพ็กเกจ Team หรือ Enterprise และต้องการให้ทุก PR มีรีวิวอัตโนมัติ GitHub Code Review จะตอบโจทย์กว่า

เวิร์กโฟลว์ Claude Code Review แบบใช้งานได้จริง

เวิร์กโฟลว์ที่มีประโยชน์ไม่ใช่ “รัน Claude ก่อนทุกการ merge” แต่เป็นลำดับที่แต่ละรีวิวเกิดขึ้นคนละช่วงของการพัฒนา เพราะแต่ละอันมีต้นทุนต่างกันและจับปัญหาคนละประเภท

นี่คือกระบวนการสำหรับการเปลี่ยนแปลงในโปรดักชัน:

Write code
	   ↓
Run tests and data checks
	   ↓
/code-review
	   ↓
Fix verified findings
	   ↓
Open GitHub PR
	   ↓
GitHub Code Review
	   ↓
Human triage
	   ↓
/code-review ultra for higher-risk changes
	   ↓
Final tests
	   ↓
Human merge

รีวิวโลคัลจับปัญหาตอนแก้ได้ถูก ส่วนรีวิวบน GitHub ให้ทีมได้มีบันทึกร่วมของข้อค้นพบ ขณะที่ ultra review ให้ความเห็นที่ลงแรงมากขึ้นก่อน merge สำคัญ

การตรวจเพิ่มเติมสำหรับนักวิทยาศาสตร์ข้อมูล

สำหรับงานข้อมูล ควรเพิ่ม 4 การตรวจรอบ ๆ Claude แทนการคาดหวังให้โมเดลทำรีวิวทั้งหมด:

• ตรวจจำนวนแถวและเกรนของชุดข้อมูลก่อนและหลังการ join สำคัญ
• รันยูนิตหรืออินทิเกรชันเทสต์รอบทรานส์ฟอร์เมชันและลอจิกฟีเจอร์
• ตรวจการรั่วไหลของข้อมูลเมื่อสร้างฟีเจอร์ ML
• ตรวจสอบเมตริกธุรกิจกับคิวรีหรือแดชบอร์ดที่เชื่อถือได้

Claude ร่วมมือได้ทั้ง 4 กิจกรรม แต่ผลที่คาดหวังควรมาจากโค้ด เทสต์ หรือข้อมูล ไม่ใช่คำอธิบายของ Claude

ข้อคิดส่งท้าย

Claude Code Review ทำงานได้ดีที่สุดเมื่อมองมันเป็นวิศวกรอีกคนในเธรดรีวิว ไม่ใช่ตราประทับอนุมัติอัตโนมัติ

คำสั่ง /code-review แบบโลคัลให้รีวิวรวดเร็วก่อนที่ PR จะมีอยู่ GitHub Code Review นำข้อค้นพบแบบหลายเอเจนต์เข้ามาใน PR สำหรับองค์กร Team และ Enterprise ขณะที่ /code-review ultra ให้รีวิวเชิงลึกบนคลาวด์เมื่อการเปลี่ยนแปลงสมควรได้รับการตรวจรอบพิเศษ

เริ่มจากเล็ก ๆ ใส่ /code-review ในเวิร์กโฟลว์สาขาปกติ เขียน REVIEW.md สั้น ๆ สำหรับรีวิวบน GitHub และลอง /code-review ultra กับการเปลี่ยนแปลงที่การ merge ผิดพลาดจะมีต้นทุนจริง

สำหรับแนวคิดของโมเดลเบื้องหลัง คอร์ส Introduction to Claude Models ให้บริบทที่กว้างขึ้น ขณะที่ GitHub Foundations และ Intermediate GitHub Concepts ครอบคลุมเวิร์กโฟลว์ Git และ GitHub ที่ Code Review ใช้งานอยู่ด้านบน สำหรับแรงบันดาลใจเพิ่มเติมว่าจะคัดแยกรีโป GitHub ด้วย Claude อย่างไร แนะนำให้อ่าน บทเรียนตัวเชื่อมต่อ Claude Code