c-CRAB เกณฑ์ชี้วัดตัวแทนตรวจสอบโค้ด: มันวัดอะไร พบอะไร และ 41.5% แท้จริงแล้วหมายความว่าอย่างไร

เอเจนต์ตรวจสอบโค้ดและผู้ตรวจสอบซึ่งเป็นมนุษย์ได้ดูคำขอดึง (pull request) ฉบับเดียวกัน และหยิบยกข้อกังวลเดียวกันขึ้นมา การทำตามความคิดเห็นของเอเจนต์ช่วยแก้บั๊กได้ และการทดสอบก็ผ่าน และเมตริกความคล้ายคลึงของข้อความทุกตัวที่ผู้เขียนคำนวณให้คะแนนบทวิจารณ์ของเอเจนต์ว่าโดยพื้นฐานแล้วไม่เกี่ยวข้องกับบทวิจารณ์ของมนุษย์เลย: BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74, ความคล้ายคลึงแบบ embedding 54.59 ข้อกังวลเดียวกัน ถ้อยคำต่างกัน แต่วิธีการให้คะแนนบทวิจารณ์แบบมาตรฐานไม่สามารถเห็นว่าพวกเขาเห็นพ้องต้องกัน ตัวอย่างเดียวนี้คือเหตุผลเบื้องหลัง c-CRAB (อ่านว่า “see-crab”) ซึ่งเป็นเกณฑ์มาตรฐานเอเจนต์ตรวจสอบโค้ดที่ตีพิมพ์เป็น arXiv:2603.23448.

c-CRAB ประเมินเอเจนต์ตรวจสอบโค้ด (code-review agents) ไม่ใช่เอเจนต์เขียนโค้ด (code-writing agents) เมื่อได้รับ pull request ซึ่งอาจมาจากมนุษย์หรือจากเอเจนต์เขียนโค้ด เอเจนต์ตรวจสอบจะสร้างรีวิวขึ้นมา และ c-CRAB จะให้คะแนนรีวิวนั้นโดยพิจารณาว่าการดำเนินการตามรีวิวจะนำไปสู่การแก้ไขที่ถูกต้องในเชิงพฤติกรรมหรือไม่ เบนช์มาร์กนี้สร้างขึ้นโดยนักวิจัยวิศวกรรมซอฟต์แวร์ Yuntong Zhang, Zhiyuan Pan, Imam Nur Bani Yusuf, Haifeng Ruan, Ridwan Shariffdeen และ Abhik Roychoudhury และประเมินเครื่องมือสี่ตัว ได้แก่ PR-Agent, Devin, Claude Code และ Codex ผู้เขียนคนหนึ่งสังกัดอยู่ที่ SonarSource และบทความได้ระบุอย่างชัดเจนว่าสิ่งนั้นหมายถึงอะไรและไม่ได้หมายถึงอะไร ในคำพูดของบทความเอง: “มุมมองและข้อสรุปที่แสดงในบทความนี้เป็นเพียงความเห็นของผู้เขียนเท่านั้น และไม่ได้แสดงถึงนโยบายหรือการรับรองอย่างเป็นทางการของ SonarSource ยิ่งไปกว่านั้น ผลการค้นพบที่นำเสนอในที่นี้เป็นอิสระ และไม่ควรตีความว่าเป็นการประเมินคุณภาพของผลิตภัณฑ์ของ SonarSource”

ข้อควรทราบสองประการก่อนเข้าสู่รายละเอียด บทความจากบุคคลที่สามบางฉบับเรียกผลงานชิ้นเดียวกันนี้ว่า “CR-bench”; มันคือเกณฑ์ชี้วัดเดียวกัน และหน้านี้ใช้คำว่า c-CRAB ตลอดทั้งหน้า ตัวเลขทุกตัวด้านล่างคือผลลัพธ์ที่บทความรายงานเอง ซึ่งอ่านจากบทความและแพ็กเกจจำลองผล ณ วันนี้ — ไม่ได้มีการรันซ้ำอย่างอิสระ — และการตีความเป็นของเราบวกกับการอภิปรายจากผู้ปฏิบัติงานที่บทความได้รับไปแล้ว ไม่มีส่วนใดเป็นคำแนะนำจากผู้จำหน่ายที่เครื่องมือของพวกเขาถูกนำมาประเมิน และหากคุณยังคงตัดสินใจอยู่ว่าจะใช้เอเจนต์ตรวจสอบโค้ดหรือไม่ คู่มือผู้ซื้อของเราเกี่ยวกับเอเจนต์ตรวจสอบโค้ดคือจุดเริ่มต้นที่ดีกว่า หน้านี้คือเรื่องราวเกี่ยวกับวิธีการวัดผลเอเจนต์เหล่านั้น

ทำไม c-CRAB จึงให้คะแนนรีวิวด้วยการทดสอบ ไม่ใช่ผู้ตัดสิน LLM

วิธีปกติในการให้คะแนนเอเจนต์ตรวจสอบโค้ดคือการเปรียบเทียบรีวิวของมันกับของมนุษย์ โดยใช้ LLM-as-judge หรือเมตริกความคล้ายคลึงของข้อความ ผู้เขียน c-CRAB ปฏิเสธทั้งสองวิธี พวกเขาโต้แย้งว่า LLM-as-judge มีอคติ ไม่เสถียร และไวต่อพรอมป์ต์ ซึ่งทำให้การให้คะแนนที่ทำซ้ำได้และสอดคล้องกันเป็นเรื่องยาก และกรณีศึกษาข้างต้นแสดงให้เห็นว่าเมตริกสตริงวัดอะไรจริง ๆ: ถ้อยคำ ไม่ใช่ประสิทธิผล ใน pull request ของ python-telegram-bot นั้น รีวิวของ Codex กล่าวสิ่งเดียวกันกับที่มนุษย์กล่าว และ BLEU-4 และ ROUGE-L ไม่สามารถรับรู้ได้

ดังนั้น c-CRAB จึงทำตรงกันข้าม ความคิดเห็นจากรีวิวของมนุษย์แต่ละรายการจะถูกแปลงเป็นเทสต์ที่รันได้ซึ่งจับประเด็นที่เป็นต้นเหตุ รีวิวหนึ่งรายการจะถือว่าถูกต้องหากการลงมือทำตามรีวิวนั้นให้ผลลัพธ์เป็นการแก้ไขที่ถูกต้องในเชิงพฤติกรรม นั่นคือทำให้เทสต์ผ่าน ทุกอินสแตนซ์มาพร้อมกับสภาพแวดล้อม Docker ที่รันได้ การตัดสินว่าผ่านหรือไม่จึงเกิดจากการรันโค้ด ไม่ใช่การถามโมเดลอื่นว่าข้อความสองข้อความคล้ายกันแค่ไหน นี่คือเหตุผลที่มันสำคัญ: หน้าที่ของรีวิวคือการเปลี่ยนสิ่งที่นักพัฒนาทำ และเทสต์คือสัญญาณการให้คะแนนเดียวที่วัดการเปลี่ยนแปลงนั้นได้โดยตรง

บทความนิยามการทดสอบสองประเภทด้วยคำพูดของมันเองว่า “การทดสอบเชิงพฤติกรรมจะนำเข้าและรันโค้ดที่ทดสอบในขณะรันไทม์ โดยเรียกใช้ฟังก์ชันที่ทดสอบด้วยอินพุตที่เฉพาะเจาะจง แล้วตรวจสอบเอาต์พุตหรือยืนยันข้อยกเว้น ในทางกลับกัน การทดสอบเชิงโครงสร้างจะตรวจสอบข้อความซอร์สโค้ด จับคู่แพตเทิร์น และตรวจสอบพื้นผิว API เพื่อพิจารณาว่ามีการเปลี่ยนแปลงโค้ดตามที่ต้องการหรือไม่” การแบ่งสุดท้ายคือการทดสอบเชิงพฤติกรรม 42 รายการ (17.9%) และเชิงโครงสร้าง 192 รายการ (82.1%) สมควรกล่าวอย่างตรงไปตรงมาว่า: ออราเคิลส่วนใหญ่เป็นการจับคู่แพตเทิร์นบนข้อความซอร์สโค้ด ไม่ใช่การรันโค้ด ความเอนเอียงนี้เป็นข้อจำกัดจริงที่ควรจดจำไว้

เกณฑ์มาตรฐานถูกสร้างขึ้นอย่างไร และฟันเนลมีค่าใช้จ่ายเท่าไร

c-CRAB สร้างขึ้นบนพื้นฐานของชุดข้อมูล inclusionAI/SWE-CARE ที่มีอยู่เดิม ซึ่งให้อินสแตนซ์ pull-request พร้อมข้อมูลเมตาของ commit; การมีส่วนร่วมของ c-CRAB เองคือ oracle ไม่ใช่คลัง PR ไปป์ไลน์การคัดกรองจะรันตัวกรองสี่ตัว และแต่ละตัวทำให้อินสแตนซ์ลดลง บทความรายงาน funnel ดังนี้:

• ชุดข้อมูลเริ่มต้น — PR 671 รายการ, ความคิดเห็น 1,313 รายการ

• การกรองรีวิว — 410 PRs, 595 ความคิดเห็น ตัวแยกประเภท LLM ซึ่งปรับเทียบกับชุดข้อมูลอ้างอิง (gold set) ของความคิดเห็น 100 รายการที่ annotate ด้วยมือ จะเก็บเฉพาะปัญหาที่ตรวจสอบได้อย่างเป็นกลาง และละทิ้งข้อเสนอแนะเชิงสนทนาหรือเชิงอัตนัย

• การสร้างสภาพแวดล้อมที่ปฏิบัติการได้ — 410 PRs, 595 คอมเมนต์ หนึ่ง Docker image ต่อ PR โดยการแก้ไข dependency จะถอยกลับไปใช้ coding agent เมื่อระบบอัตโนมัติล้มเหลว

• การแปลงความคิดเห็นภาษาธรรมชาติเป็นเทสต์ — 339 PRs, 481 ความคิดเห็น เทสต์ถูกสร้างด้วย GPT-5.2 ภายใต้ลูปการปรับแต่งที่ชี้นำโดยการดำเนินการสูงสุดสามครั้ง; เทสต์จะถูกเก็บไว้ก็ต่อเมื่อมันล้มเหลวบนโค้ดเดิมและผ่านหลังจากการแก้ไข

• การตรวจสอบโดยใช้เอเจนต์เขียนโค้ด — 184 PRs, 234 ความคิดเห็น Claude Code บนแบ็กเอนด์ Sonnet-4.6 พยายามแก้ไขโค้ดโดยมีเพียงความคิดเห็นรีวิวจากมนุษย์เท่านั้น กรณีที่ไม่สามารถทำให้การทดสอบผ่านได้จะถูกคัดออก นี่คือชุดสุดท้าย

ประมาณ 27% ของ pull requests เริ่มต้นที่รอดชีวิต นั่นคือราคาอันตรงไปตรงมาของ oracle ที่อิงจากการทดสอบ และยังเป็นเหตุผลที่ benchmark มีขนาดเล็กไม่ใหญ่โต ชุดที่รอดชีวิต: 184 กรณี PR, 234 ความเห็นรีวิวที่ผ่านการตรวจสอบ, 1.27 การทดสอบต่อกรณี, 418.1 บรรทัดที่แก้ไขต่อ PR โดยเฉลี่ย, 31.8 บรรทัดต่อการทดสอบ ผู้ให้คำอธิบายสองคนประเมินอย่างอิสระว่าการทดสอบที่สร้างขึ้นจับประเด็นของผู้รีวิวซึ่งเป็นมนุษย์ได้อย่างเที่ยงตรงหรือไม่ ในตัวอย่าง 50 กรณี และเห็นพ้องกัน 84% ของเวลา

ความไม่ตรงกันอย่างหนึ่งที่คุณจะสังเกตเห็นหากอ่านอย่างละเอียด: ตารางชุดข้อมูลระบุที่เก็บข้อมูล 67 แห่ง ขณะที่ส่วนข้อจำกัดด้านความถูกต้องระบุว่า “อินสแตนซ์คำขอ pull request 184 รายการ พร้อมออราเคิลที่ตรวจสอบได้ 234 รายการจากที่เก็บข้อมูล 56 แห่ง” เอกสารให้ตัวเลขทั้งสองในจุดที่ต่างกัน และเราจะไม่หาค่าเฉลี่ยหรือเลือกใช้ตัวเลขที่สะดวกโดยไม่บอกกล่าว ผู้อ่านใช้รายละเอียดแบบนี้ในการตัดสินว่าเกณฑ์ชี้วัดนั้นคุ้มค่ากับเวลาหรือไม่ เราจึงนำเสนอทั้งสองตัวเลขตามที่ตีพิมพ์

ผลลัพธ์และวิธีอ่าน

อัตราการผ่านคืออัตราการผ่านการทดสอบโดยรวม: สำหรับแต่ละอินสแตนซ์คือสัดส่วนของการทดสอบของ PR นั้นที่ผ่าน และตัวเลขหลักคือค่าเฉลี่ยของทุกอินสแตนซ์ รายงานระบุต่อเครื่องมือว่า:

• Claude Code — 1,336 ความคิดเห็น, 7.3 ต่อ PR — เชิงพฤติกรรม 38.1%, เชิงโครงสร้าง 30.7%, โดยรวม 32.1%

• Devin — 1,344 ความคิดเห็น, 7.3 ต่อ PR — เชิงพฤติกรรม 31.0%, เชิงโครงสร้าง 23.4%, โดยรวม 24.8%

• PR-Agent — 524 ความคิดเห็น, 2.8 ต่อ PR — พฤติกรรม 38.1%, โครงสร้าง 19.8%, โดยรวม 23.1%

• Codex — 324 ความคิดเห็น, 1.8 ต่อ PR — เชิงพฤติกรรม 38.1%, เชิงโครงสร้าง 16.1%, โดยรวม 20.1%

• มนุษย์ — 234 ความเห็น, 1.3 ต่อ PR — 100% โดยการสร้าง. มนุษย์เป็นผู้เขียน oracle ดังนั้นแถวนี้จึงเป็นตัวบอกสเกล ไม่ใช่คู่แข่ง.

โปรดอ่านแถวเหล่านั้นอย่างรอบคอบก่อนอ้างอิงแถวใด ๆ ข้อความ “only around 40%” จากบทคัดย่อคือค่ารวม: 41.5% ของการทดสอบ 234 รายการผ่านโดยเครื่องมืออย่างน้อยหนึ่งในสี่ตัว มันไม่ใช่คะแนนของเอเจนต์ตัวใดตัวหนึ่ง — คะแนนเดี่ยวที่ดีที่สุดคือ 32.1% ของ Claude Code — และมันไม่ได้หมายความว่าเครื่องมือทั้งสี่รวมกันจับข้อบกพร่องจริงได้ 40% ส่วนด้านล่างอธิบายว่าทำไม

ตัวเลขที่น่าสนใจที่สุดไม่ใช่ผู้ชนะ Claude Code และ Devin ต่างโพสต์ความคิดเห็นมากกว่า 1,300 รายการ — ประมาณ 7.3 รายการต่อ PR — คิดเป็น 32.1% และ 24.8% Codex โพสต์ 324 รายการ ประมาณ 1.8 รายการต่อ PR คิดเป็น 20.1% เส้นฐานของมนุษย์คือ 1.3 ความคิดเห็นต่อ PR ลองคำนวณดู: ปริมาณความคิดเห็นที่มากกว่าถึงสี่เท่าให้อัตราการผ่านที่ดีขึ้นไม่ถึงสองเท่า ปริมาณไม่ใช่ความครอบคลุม ผู้ตรวจสอบที่พูดมากไม่เหมือนกับผู้ตรวจสอบที่มีประโยชน์ และ c-CRAB คือเกณฑ์มาตรฐานแรกที่ถูกสร้างขึ้นเพื่อแสดงให้เห็นสิ่งนั้น

ประโยชน์ใช้สอยกลับกลายเป็นผลเสียได้เช่นกัน

อัตราการผ่านที่ต่ำอ่านแล้วเหมือนการตัดสินว่าผมไม่ดี จนกว่าคุณจะดูสิ่งที่ผู้เขียนวัดผลเพิ่มเติม พวกเขาตรวจสอบความคิดเห็น 92 รายการจาก PR 6 รายการด้วยตนเอง และประเมินว่า 84% มีประโยชน์ (77 จาก 92) — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78% ดังนั้นความคิดเห็นส่วนใหญ่ที่สอบไม่ผ่านการทดสอบ c-CRAB จึงไม่ใช่เสียงรบกวน แต่เป็นเรื่องที่ผู้ตรวจสอบที่เป็นมนุษย์ไม่ได้หยิบยกขึ้นมา กลุ่มตัวอย่างมีขนาดเล็ก — 92 ความคิดเห็น, 6 PR — และบทความก็ระบุไว้เช่นนั้น และเราก็ควรพูดเช่นนั้นด้วย

รูปแบบเดียวกันนี้ปรากฏในสิ่งที่ผู้วิจารณ์พูดถึง ผู้วิจารณ์ที่เป็นมนุษย์โน้มเอียงไปทางความสามารถในการบำรุงรักษา การออกแบบ และเอกสารประกอบ ในขณะที่เครื่องมือโน้มเอียงไปทางความทนทาน การทดสอบ และการจัดการข้อผิดพลาด บทความตีความว่านี่เป็นข้อโต้แย้งสำหรับการทำงานร่วมกันระหว่างมนุษย์และเอเจนต์ มากกว่าการแทนที่ และยังเป็นคำอธิบายที่ดีที่สุดเท่าที่มีสำหรับเหตุผลที่คะแนนดูต่ำ กล่าวคือ เอเจนต์และมนุษย์มักไม่ได้มองสิ่งเดียวกัน และ oracle ให้รางวัลเฉพาะรายการของมนุษย์เท่านั้น

สิ่งที่ c-CRAB มองไม่เห็น

เกณฑ์ชี้วัดนี้กล่าวถึงจุดบอดของมันอย่างชัดเจน และเราก็เช่นกัน c-CRAB ไม่ให้เครดิตสำหรับปัญหาที่ถูกต้องซึ่งผู้ตรวจทานที่เป็นมนุษย์ไม่เคยหยิบยกขึ้นมา โอราเคิลคือเจตนาของการตรวจทานโดยมนุษย์: เอเจนต์ที่พบข้อบกพร่องจริงที่ไม่มีใครกล่าวถึงจะได้คะแนนเป็นศูนย์สำหรับข้อบกพร่องนั้น บทความกล่าวไว้โดยตรง — เครื่องมือตรวจทานอัตโนมัติอาจสร้างความคิดเห็นที่มีค่าอื่นๆ ที่ผู้ตรวจทานที่เป็นมนุษย์ไม่ได้ระบุ แต่ “เช่นเดียวกับเกณฑ์ชี้วัดอื่นๆ ที่มีอยู่ c-CRAB ไม่ได้ประเมินความคิดเห็นเพิ่มเติมเหล่านี้โดยตรง”

ประโยคเดียวนั้นคือการแก้ไขความเข้าใจผิดของบทความส่วนใหญ่ที่รายงานผลลัพธ์นี้ ใครก็ตามที่อ้าง “เอเจนต์ตรวจสอบแก้ไขได้เพียง 40%” ราวกับว่ามันวัดว่าเอเจนต์จับข้อบกพร่องจริงได้กี่จุด กำลังอ่านตัวเลขผิด ที่จริงมันวัดว่าเอเจนต์ร่วมกันแก้ไขข้อกังวลที่มนุษย์หยิบยกขึ้นมาได้กี่ข้อ — ซึ่งเป็นข้อกล่าวอ้างที่แคบกว่าและซื่อสัตย์กว่ามาก

การรันด้วยตนเอง

หากคุณต้องการทำซ้ำตัวเลขผลลัพธ์หรือเพิ่มผู้ตรวจสอบของคุณเอง แพ็กเกจการทำซ้ำเปิดเผยที่ c-CRAB-Benchmark/dataset README คือเอกสารที่แท้จริง และมันพูดตรงไปตรงมาเกี่ยวกับลักษณะของมัน ขั้นตอนการติดตั้งคือ code>uv sync/code>; คุณต้องมี Docker และ code>OPENAI_API_KEY/code> หรือ code>ANTHROPIC_API_KEY/code> และ Claude Code จะอ่านข้อมูลประจำตัวเพิ่มเติมจาก code>~/.claude/.credentials.json/code> องค์กรยังเผยแพร่ Docker images ที่สร้างไว้ล่วงหน้าสำหรับสภาพแวดล้อมเหล่านั้นอีกด้วย

โครงสร้าง: code>pipeline//code> เก็บตรรกะของไปป์ไลน์และพรอมต์, code>execution//code> ตัวสร้างอิมเมจ Docker และตัวช่วยรันไทม์, code>results_preprocessed//code> ชุดย่อยของเบนช์มาร์กที่เผยแพร่ (410 อินสแตนซ์ที่ประมวลผลแล้ว), code>results_pipeline_funnel//code> ไฟล์ JSONL ของ stage0–stage4 และสรุปฟันเนล และ code>raw_results_compressed//code> ผลลัพธ์การทดลองดิบ

การทำซ้ำการรันทั้งหมดมีห้าขั้นตอน: สร้างสภาพแวดล้อม Docker (code>execution.build_swe_care/code>), สร้างชุดทดสอบ (code>run_testgen_full.sh/code>), รวบรวมรีวิวพื้นฐาน (code>run_batch_baselines.py --tools pr-agent devin claude-code codex/code>), รันการแก้ปัญหาโดยเอเจนต์ (code>run_batch_agent_resolution.py/code>), จากนั้นประเมินผล (code>run_batch_tool_eval.py --tool <name>/code>). หากคุณต้องการเพิ่มผู้รีวิวคนที่ห้า โปรดทราบว่าจุดขยายไม่ใช่อินเทอร์เฟซปลั๊กอิน: พรอมป์รีวิวพื้นฐานสำหรับทุกเครื่องมืออยู่ใน code>run_batch_baselines.py/code> และ README ไม่ได้ระบุวิธีที่สะอาดกว่าไว้ — คุณต้องแก้ไขสคริปต์นั้น

ก่อนที่คุณจะโคลนมัน มีข้อเท็จจริงเพิ่มเติมอีกสองข้อ เอกสารนี้ได้รับอนุญาตภายใต้ CC BY 4.0; หน้าคลังโค้ดไม่ได้ระบุสิทธิ์การใช้งานสำหรับโค้ด ดังนั้นอย่าสมมติว่ามีสิทธิ์ และเอกสารไม่ได้เผยแพร่ตัวเลขค่าใช้จ่ายหรือการใช้งานโทเค็นสำหรับการรัน benchmark — นั่นไม่ได้รับการเผยแพร่ ดังนั้นเราจะไม่คิดค้นขึ้นเอง สิ่งที่ไปป์ไลน์บอกเป็นนัยคือ: หนึ่ง Docker image ต่อ PR ใน 184 instances บวกกับการผ่านขั้นตอน agent-resolution ไม่ใช่เรื่องที่ทำได้ในบ่ายวันเดียวบนแล็ปท็อป

สิ่งนี้หมายความว่าอย่างไรสำหรับผู้ที่นำส่งไปป์ไลน์การตรวจสอบ

ข้อโต้แย้งหลักของ c-CRAB คือ ผู้ตัดสิน LLM เป็น oracle ที่ไม่น่าเชื่อถือ หากคุณไม่สามารถสร้าง executable oracle ได้ — และทีมส่วนใหญ่ก็ไม่สามารถทำได้ — มาตรการบรรเทาที่ดีที่สุดที่มีคือ อย่าให้ผู้ตัดสินทำงานบนโมเดลที่สร้างบทวิจารณ์นั้น ผู้ตัดสินที่ใช้โมเดลเดียวกับผู้วิจารณ์จะเห็นด้วยกับตัวเอง และขั้นตอนการตรวจสอบจะกลายเป็นเพียงการประทับตรายางที่ยังคงส่งคืนตัวเลข

นั่นคือความล้มเหลวที่เรซิปีกำหนดเส้นทาง (routing recipe) ซึ่งอยู่เบื้องหลังรีวิวเวอร์ที่เราจัดส่ง คอยป้องกันอยู่พอดี — และมันคือความขนานเชิงออกแบบกับคำวิจารณ์ของ c-CRAB ไม่ใช่ผลลัพธ์จากการ benchmark ฮาร์เนสยังคงรัน LLM judge เป็นรอบที่สองอยู่ดี โดยจัดกลุ่มข้อค้นพบ ให้คะแนนแต่ละกลุ่ม 0–1 ว่ามันเป็นข้อบกพร่องที่เป็นรูปธรรมในการเปลี่ยนแปลงนี้หรือไม่ และทิ้งทุกอย่างที่ต่ำกว่าเกณฑ์ เรซิปีที่ควบคุมมันอยู่คือ code>recipes/oracode-review.dsl.yaml/code> ซึ่งเป็นไฟล์สาธารณะ แอ็กชันไม่เคยเอ่ยชื่อโมเดล: มันเรียกนามแฝงของเราเตอร์ (router alias) และเรซิปีเป็นคนตัดสินใจ ตามที่ตั้งค่าไว้ เรซิปีมีสี่บรรทัด — ค่าเริ่มต้นของรีวิวเวอร์คือ code>deepseek/deepseek-v4-flash-0731/code> และกฎที่ตรงกับเฮดเดอร์ code>x-cr-lens: judge/code> จะส่งรอบผู้ตัดสิน (judge pass) ไปยัง code>z-ai/glm-5.3/code> ซึ่งเป็นเวนเดอร์คนละราย ถ้อยคำของเรซิปีเองกำหนดว่าผู้ตัดสิน “ต้องไม่เอ่ยชื่อโมเดลของดีฟอลต์” เพราะบนโมเดลของรีวิวเวอร์เอง มัน “เห็นด้วยกับตัวเอง ดังนั้นรอบนั้นจึงไม่ทำงานจริงในขณะที่ยังรายงานว่าสำเร็จ”

ผู้ตัดสินจากผู้ให้บริการรายอื่นช่วยลดการเห็นพ้องกับตัวเอง แต่มันไม่ได้ทำให้ผู้ตัดสินแบบ LLM กลายเป็นแบบทดสอบ c-CRAB ไม่ได้ทดสอบผู้ตรวจสอบของเรา และเราจะไม่สื่อเป็นนัยว่ามันทำเช่นนั้นOrcaCode Reviewทำงานด้วยการตรวจทานหนึ่งรอบ พร้อมกับผู้ตัดสินตรวจสอบอิสระ โดยคิดราคาต่อโทเค็น ไม่ใช่ต่อซีต และทุกพรอมต์ในนั้นเปิดเผยต่อสาธารณะ — คุณจึงสามารถชี้มันไปที่เบนช์มาร์กแบบนี้และได้ตัวเลขของคุณเองแทนที่จะเป็นของเรา

บรรทัดล่าง

c-CRAB คือเกณฑ์มาตรฐานการตรวจสอบโค้ดชิ้นแรกที่คุณสามารถเชื่อถือคะแนนได้ว่าหมายถึงสิ่งที่มันสื่อจริง ๆ กล่าวคือ บทวิจารณ์จะผ่านก็ต่อเมื่อลงมือปฏิบัติตามแล้วช่วยแก้ไขโค้ดได้จริง ตัวเลขหลักต่ำอย่างแท้จริง — เครื่องมือเดี่ยวที่ดีที่สุดทำได้ 32.1% ส่วนการรวมทุกเครื่องมือทำได้ 41.5% — แต่ตัวเลขเหล่านี้วัดความทับซ้อนกับข้อกังวลที่มนุษย์หยิบยกขึ้นมา ไม่ใช่วัดคุณภาพของบทวิจารณ์ และข้อมูลด้านประโยชน์ใช้สอยแสดงให้เห็นว่าความคิดเห็นส่วนใหญ่เป็นสัญญาณที่มีค่าจริง บทเรียนที่ยั่งยืนคือสิ่งที่บทความเองนำเสนอ: ปริมาณไม่ใช่ความครอบคลุม เอเจนต์กับมนุษย์มองสิ่งที่แตกต่างกัน และการนำไปใช้งานที่ถูกต้องคือการทำงานร่วมกันระหว่างมนุษย์กับเอเจนต์ และเกณฑ์มาตรฐานนี้เปิดเผยสู่สาธารณะ ดังนั้นขั้นตอนต่อไปที่ตรงไปตรงมาคือนำรีวิวเวอร์ของคุณเองมาทดสอบกับมันแล้วดูตัวเลขของคุณเอง