Open Code Review ของ Alibaba: เครื่องมือรีวิวโค้ดที่ล็อกขั้นตอนไว้ด้วยโค้ดแล้วให้ agent ทำเฉพาะส่วนที่ต้องคิด อ้างใช้โทเคนราว 1/9 ของ Claude Code แต่จับบั๊กได้น้อยกว่า และตัวเลขมาจาก benchmark ของ Alibaba เอง
Open Code Review (คำสั่ง ocr) คือ CLI รีวิวโค้ดด้วย AI ที่ Alibaba ใช้เป็นผู้ช่วยรีวิวโค้ดอย่างเป็นทางการภายในบริษัทมาราวสองปี README ระบุว่าให้บริการนักพัฒนา “tens of thousands” คน และพบข้อบกพร่องในโค้ด “millions” จุด บริษัทเปิดซอร์สภายใต้ Apache-2.0 เมื่อ 21 พ.ค. 2026 (v1.0.0) หลังจากนั้นออกรุ่นย่อยต่อเนื่องมาแล้วราว 125 รุ่น รุ่นล่าสุดคือ v1.12.1 เมื่อ 14 ก.ย. ตอนนี้ repo มีดาวราว 26k และวันนี้ขึ้นอันดับต้น ๆ ของ GitHub trending
บล็อกนี้ไม่เคยเขียนถึงเครื่องมือนี้เลย โพสต์นี้จึงเป็นการตามเก็บ (catch-up) ไม่ใช่ข่าวเปิดตัว ที่ควรดูตอนนี้เพราะมันเสนอแนวทางที่ต่างจากการสั่ง Claude Code หรือ Codex ให้รีวิว PR คือ ให้โค้ดตายตัวคุมขั้นตอนที่ห้ามพลาด แล้วให้ agent ทำเฉพาะส่วนที่ต้องใช้วิจารณญาณ
แนวคิด: deterministic engineering × agent
README บอกปัญหาของ agent อเนกประสงค์ที่ใช้ Skills รีวิวโค้ดไว้สามข้อ ข้อแรก รีวิวไม่ครบ เพราะเมื่อ changeset ใหญ่ agent มัก “cut corners” เลือกอ่านแค่บางไฟล์ ข้อสองคือ ตำแหน่งคอมเมนต์เพี้ยน เลขบรรทัดหรือไฟล์ที่อ้างไม่ตรงกับโค้ดจริง ข้อสามคือ คุณภาพไม่นิ่ง เพราะ Skill ที่ขับด้วยภาษาธรรมชาติ debug ยาก และผลเปลี่ยนไปมากเมื่อแก้ prompt นิดเดียว
วิธีแก้ของ Open Code Review คือแยกงานเป็นสองส่วน:
- ส่วนที่โค้ดคุม ได้แก่ การเลือกไฟล์ที่ต้องรีวิว, การมัดไฟล์ที่เกี่ยวข้องกันเป็นก้อน (เช่น
message_en.propertiesคู่กับmessage_zh.properties) แล้วส่งแต่ละก้อนให้ sub-agent ที่มี context แยกกัน, การจับคู่กฎรีวิวกับไฟล์ด้วย template engine และโมดูลแยกที่ตรวจตำแหน่งกับเนื้อหาของคอมเมนต์ซ้ำอีกรอบ - ส่วนที่ agent ทำ ได้แก่ การตัดสินใจและดึง context เพิ่มตามสถานการณ์ โดยใช้ prompt และชุดเครื่องมือที่ปรับจาก trace การเรียกเครื่องมือใน production ของ Alibaba
การใช้งานพื้นฐานคือ npm install -g @alibaba-group/open-code-review ตามด้วย ocr config provider เพื่อเลือกผู้ให้บริการโมเดล (หรือเพิ่ม provider เองได้) แล้วสั่ง ocr review สำหรับ working tree, ใช้ --from main --to feature-branch สำหรับรีวิวทั้ง branch, --commit สำหรับ commit เดียว หรือ ocr scan เพื่อรีวิวทั้งไฟล์ในโค้ดที่ไม่มี diff ให้ดู ถ้าให้ agent ตัวอื่นอ่านผลต่อ ใช้ --format json ได้
อีกโหมดที่น่าสนใจคือ Delegation Mode ใช้คำสั่ง ocr delegate preview และ ocr delegate rule ในโหมดนี้ OCR ทำแค่เลือกไฟล์และหากฎที่ใช้ แล้วให้ coding agent ที่ใช้อยู่ทำการรีวิวด้วยโมเดลของตัวเอง จึง ไม่ต้องตั้ง API key ของ OCR มีปลั๊กอินสำหรับ Claude Code, Codex, Cursor และ OpenCode, มี agent skill แบบพกพา, มี MCP server รวมถึงรองรับ CI บน GitHub Actions, GitLab CI, GitFlic CI และ Gerrit
v1.12.1 (14 ก.ย.) เปลี่ยนอะไร
เป็นรุ่นแก้บั๊กเป็นหลัก: ตรวจว่า git ใน PATH เป็นเวอร์ชันที่ปลอดภัย, ส่งไฟล์ Python stub ไปใช้กฎของ Python, รองรับ OpenCode 2.x ผ่าน native tools, ปรับ review skill ให้ตรงกับคำสั่ง CLI ปัจจุบัน, ให้ GitHub Actions โพสต์ผลรีวิวกับ commit ที่ถูกรีวิวจริง และลบ alias deepseek-flash ที่ค้างอยู่ ส่วน v1.12.0 เมื่อ 12 ก.ย. ย้าย GLM-5.3 จาก z-ai coding plan ไปใช้ z.ai API
ตัวเลข benchmark: อ่านให้ครบก่อนเชื่อ
Alibaba วัดผลด้วย AACR-Bench (arXiv 2601.19494, ม.ค. 2026) ชุดข้อมูลนี้ทีม Alibaba สร้างเอง ประกอบด้วย PR จริง 200 รายการจาก 50 repo โอเพนซอร์สใน 10 ภาษา มีปัญหาที่วิศวกรอาวุโสกว่า 80 คนช่วยกันระบุไว้ 1,505 จุด ตารางใน README ออกมาแบบนี้ (เลือกมาบางแถว):
| เครื่องมือ + โมเดล | F1 | Precision | Recall | เวลาเฉลี่ย | โทเคนเฉลี่ย |
|---|---|---|---|---|---|
| OCR v1.3.1 + Claude 4.6 Opus | 25.10% | 33.90% | 20.00% | 1m23s | 385K |
| OCR v1.8.7 + Qwen3.8-Max | 23.00% | 33.90% | 17.40% | 5m14s | 334K |
| OCR v1.3.1 + Claude 4.8 Opus | 17.90% | 37.80% | 11.70% | 1m6s | 352K |
| Claude Code v2.1.169 + Claude 4.8 Opus | 14.13% | 15.93% | 12.70% | 5m38s | 2,062K |
| Claude Code v2.1.169 + Claude 4.6 Opus | 11.57% | 7.23% | 28.90% | 13m6s | 5,664K |
| Codex v0.140.0 + GPT-5.5 | 8.36% | 27.82% | 4.92% | 2m58s | 525K |
สิ่งที่ตารางบอก และสิ่งที่ README ไม่ได้บอก:
- “~1/9 ของโทเคน” เป็นค่าเฉลี่ย ตัวเลขจริงแต่ละโมเดลต่างกันมาก เมื่อเทียบโมเดลเดียวกัน Claude 4.6 Opus ใช้ประมาณ 1/15, Claude 4.8 Opus ประมาณ 1/6 ถ้ารวมห้าคู่ที่มีในตาราง จะได้ราว 2.5M เทียบ 22.4M โทเคน หรือประมาณ 1/9 แต่ช่องตัวเลขเด่นบนหน้า README เขียนว่า “1/9 token cost vs. Claude Code · 1,000 PRs” ขณะที่ AACR-Bench มีแค่ 200 PR จึงไม่ชัดว่าตัวเลขเด่นนี้มาจากชุดทดสอบไหน
- recall ต่ำกว่าโดยตั้งใจ Claude Code + 4.6 Opus เจอปัญหาจริง 435 จุด ส่วน OCR เจอ 301 จุด แต่ Claude Code แลกมาด้วยคอมเมนต์ถึง 5,980 ข้อ เทียบกับ 889 ข้อของ OCR README เรียกว่า “a deliberate trade-off favoring precision over noise”
- แม้แถวที่ดีที่สุดก็ยังพลาดเยอะ recall 20% หมายความว่าปัญหาที่วิศวกรระบุไว้ 4 ใน 5 จุดไม่ถูกพบ และคอมเมนต์ราว 2 ใน 3 ไม่ตรงกับ ground truth (ส่วนหนึ่งอาจเป็นปัญหาจริงที่ผู้ระบุไม่ได้ใส่ไว้ก็ได้)
- เวอร์ชันเก่ามาก แถวส่วนใหญ่ใช้ OCR v1.3.1 เทียบกับ Claude Code v2.1.169 และ Codex v0.140.0 แต่ตอนนี้ OCR อยู่ที่ v1.12.1 และ Claude Code อยู่ที่ 2.1.272 แล้ว ตารางยังไม่มี Claude Opus 5, Fable 5.1 หรือ GPT-6 Astra
- โมเดลใหม่ไม่ได้ดีกว่าเสมอ ภายใต้ OCR v1.3.1 เดียวกัน Claude 4.8 Opus ได้ F1 ต่ำกว่า 4.6 Opus (17.9% เทียบ 25.1%) เพราะ recall ลดจาก 20% เหลือ 11.7% ดูเหมือน harness ถูกปรับมาให้เข้ากับโมเดลรุ่นที่ใช้ตอนพัฒนา
มุมมอง AI Curator
นี่คือหลักฐานอีกชิ้นว่า harness สำคัญพอ ๆ กับโมเดล ใช้ Claude 4.6 Opus ตัวเดียวกันแท้ ๆ แต่ F1 ต่างกันเกินเท่าตัว และโทเคนต่างกันราว 15 เท่า ขึ้นอยู่กับว่าใครเป็นคนคุมลูป เข้ากับที่เราเคยเขียนถึงงานวัดต้นทุนต่อ pass ของ harness สำหรับงานที่ขั้นตอนชัดเจนอย่างรีวิว PR การเขียนโค้ดคุมขั้นตอนตายตัวให้ agent ยังชนะการปล่อยให้ agent อเนกประสงค์คิดเองทั้งหมด
แต่อย่าเอาตัวเลขนี้ไปใช้ตัดสินใจโดยตรง benchmark นี้ผู้สร้างเครื่องมือทำเอง ตัวเลขเด่นบนหน้าแรกกับตารางอ้างจำนวน PR ไม่ตรงกัน และทุกฝั่งถูกวัดด้วยเวอร์ชันที่เก่ากว่าปัจจุบันหลายสิบรุ่น ทีมไทยที่สนใจควรวัดเองด้วย PR ที่ merge แล้วในโปรเจกต์ของตัวเองสัก 30–50 รายการที่รู้อยู่แล้วว่ามีบั๊กอะไร แล้วนับว่าเครื่องมือจับได้กี่จุดและคอมเมนต์ขยะกี่ข้อ
จุดที่น่าลองจริงสำหรับทีมที่คุมงบ มีสองแบบ แบบแรกใช้เป็นด่านแรกใน CI คู่กับโมเดลราคาถูกอย่าง Qwen, GLM หรือ DeepSeek เพราะ precision ที่สูงกว่าทำให้ reviewer ไม่ต้องไล่ปิดคอมเมนต์ขยะหลายพันข้อ แบบที่สองใช้ Delegation Mode กับ subscription Claude Code หรือ Codex ที่จ่ายอยู่แล้ว เพื่อเอาการเลือกไฟล์และกฎรีวิวของ OCR มาใช้โดยไม่ต้องจ่ายค่า API เพิ่ม ส่วนเรื่องที่ต้องคิดก่อนเปิดใช้คือ โค้ดจะถูกส่งไปที่ endpoint ที่ตั้งไว้ องค์กรที่ห้ามโค้ดออกนอกบริษัทควรชี้ไปที่ provider ที่ควบคุมเองได้ และไม่ว่าจะเลือกแบบไหน recall 20% ยังแปลว่ามนุษย์ต้องรีวิวอยู่
แหล่งข่าว
อ่านเพิ่มในหมวด เครื่องมือนักพัฒนา
Betelgeuse รัน Qwen3.8 Flash Next ขนาด 68GB บน RTX 3060 กับแรม 16GB ส่วน Basalt วัดให้เห็นว่าเอนจินที่เร่งด้วยแฟล็กลัดทำให้โมเดลลืมของ
Betelgeuse ฟอร์ก llama.cpp ที่เปิดเมื่อ 31 ต.ค. ดึง expert จาก NVMe เข้า VRAM ตามต้องการ อ้าง 22 tok/s แบบไม่ทิ้ง expert แต่ README เตือนเองว่ายังทดลองและตัวเลขมาจากคนละรอบ วันเดียวกันผู้พัฒนา Basalt เผยผลวัดว่าแฟล็กเร่งความเร็วทำคุณภาพ Q8 ตกไปใกล้ Q2
กฎห้ามโคลนเกมของ Claude Code เริ่มกระทบงานจริง บริษัทรับทำเกมกระดานร้องงานลูกค้าหยุด แต่รายงานหลายชิ้นปนกับตัวกรองไซเบอร์คนละเรื่อง
ต่อจากที่เราพบกฎนี้ในไบนารี Claude Code ผู้ใช้เริ่มรายงานว่างานเชิงพาณิชย์ถูกปฏิเสธ และ Tom's Hardware กับ Mashable หยิบไปรายงาน แต่เมื่อไล่ issue ที่อ้างถึง พบว่าหลายรายการเกิดก่อนกฎจะมา จึงน่าจะเป็นตัวกรองด้านไซเบอร์ ส่วน Anthropic ยังไม่ชี้แจง
Claude Code ส่ง transcript ของ background agent ให้โมเดลทุก ~30 วินาทีเพื่อเขียนสถานะ 3–5 คำ ผู้วัดรายงานกินราว 16% และยังปิดแบบทางการไม่ได้
รายงานอิสระพบว่าฟีเจอร์ agent_summary ของ Claude Code ส่ง transcript เต็มของ background agent ไปถามสถานะทุก ~30 วินาที คิดเป็น 16.4% ของค่าใช้จ่ายในระบบของผู้วัด Issue เปิดมาตั้งแต่ ส.ค. ยังไม่มีสวิตช์ปิดที่รองรับ เราตรวจพบโค้ดนี้ใน 2.1.314 และพบกฎใหม่เรื่องเกมที่ไม่อยู่ใน changelog