การตรวจสอบโค้ดอัตโนมัติในปี 2026: ทำให้มันทำงานบนทุก PR โดยไม่ต้องซื้อที่นั่ง

การรีวิวโค้ดอัตโนมัติคืองาน CI ที่ส่ง diff ของคุณไปยังโมเดลภาษา โพสต์ข้อค้นพบลงบนบรรทัดที่เกี่ยวข้อง และทำให้การตรวจสอบสถานะ (status check) ล้มเหลวเมื่อพบปัญหาที่ร้ายแรง วิธีทำให้มันทำงานในทุกคำขอ pull request โดยไม่ต้องสมัครสมาชิกแบบคิดค่าใช้จ่ายต่อที่นั่งก็คือการโฮสต์เครื่องมือโอเพนซอร์สด้วยตัวเอง: คัดลอกเวิร์กโฟลว์ประมาณสิบห้าบรรทัดลงในรีโพซิทอรีของคุณ เพิ่มคีย์ API หนึ่งอัน แล้วจ่ายเฉพาะโทเคนที่การรีวิวแต่ละครั้งใช้ไปเท่านั้น ไม่มีจำนวนที่นั่งให้ซื้อ เพราะมันไม่มีที่นั่งอยู่แล้ว การนำไปใช้อ้างอิงที่เราดูแลรักษาคือ the Orca-Code-Review repository — เป็นโปรเจกต์สาธารณะ ใช้สัญญาอนุญาต MIT และนับตั้งแต่ถูกสร้างขึ้นเมื่อวันที่ 25 มิถุนายน 2026 ก็เป็นโค้ดที่อยู่เบื้องหลัง GitHub Action ชื่อ OrcaCode Review สูตรกำหนดเส้นทางที่มาพร้อมกับมันตั้งค่าเริ่มต้นให้รอบการรีวิวใช้ DeepSeek V4 Flash และตัวตัดสินการตรวจสอบอิสระใช้ GLM-5.3 และทั้งสองอย่างคุณเปลี่ยนได้ตามต้องการ บทความนี้จะพาคุณดูว่าอะไรทำงานจริงในทุกการ push สิ่งที่คุณต้องกำหนดค่า ต้นทุนในหน่วยโทเคน และโหมดความล้มเหลวที่คุณจะพบในสัปดาห์ที่สอง

พูดกันแบบสั้นๆ ก็คือ ทุกการพุชจะได้รับการรีวิวหนึ่งครั้ง ข้อค้นพบจะถูกโพสต์แบบอินไลน์บนบรรทัดที่เปลี่ยนแปลง ข้อค้นพบระดับ P0 และ P1 จะทำให้การตรวจสอบไม่ผ่านและบล็อกการรวมโค้ด ส่วนการรันที่สะอาดจะผ่าน และคุณสามารถขอรีวิวซ้ำได้ตามต้องการโดยการคอมเมนต์ /orcacode-review. เวิร์กโฟลว์จะอยู่ใน repo ของคุณ ส่วนตรรกะการรีวิวอยู่ในแอ็กชันที่เผยแพร่แล้ว และการเลือกโมเดลอยู่ใน routing recipe ที่คุณสามารถแก้ไขได้ในเวิร์กสเปซของคุณเอง ตัวรีวิวจะอ่าน diff และไฟล์ใน repository และจะไม่รันโค้ดของ PR ของคุณเลย และต้องบอกอย่างตรงไปตรงมาตั้งแต่ต้นว่า มันจับบั๊กจริงได้ แต่ก็ยังพลาดบั๊กที่ต้องอาศัยมนุษย์ที่รู้ว่าเหตุใดโค้ดจึงเป็นแบบนี้

• หนึ่งเวิร์กโฟลว์ + หนึ่งซีเคร็ต + หนึ่งบิลโทเคน ไม่มีใบอนุญาตต่อซีต ณ จุดใดๆ

• แฮร์เนสเป็นโอเพนซอร์ส คัดลอกมัน ฟอร์กมัน ตรวจสอบมัน และปักหมุดที่ SHA ของคอมมิต

• โมเดลคือการตั้งค่า ไม่ใช่ผู้จำหน่าย. เปลี่ยนผู้ตรวจสอบโดยการแก้ไขสูตรการกำหนดเส้นทาง ไม่ใช่โดยการเขียน YAML ใหม่หรือการเพิ่มเวอร์ชันแอ็กชัน

• diff ที่ใหญ่เกินไปไม่มีค่าใช้จ่าย ตัวตรวจสอบขนาดจะทำงานก่อนโมเดล

• มันอ่านโค้ดของคุณ แต่ไม่เคยรัน. นี่คือคุณสมบัติด้านความปลอดภัยที่ทำให้ pull_request_target ปลอดภัยที่จะใช้งานได้เลย.

การตรวจสอบโค้ดอัตโนมัติทำงานอย่างไรจริงๆ

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

นี้เหตุการณ์คือตัวกระตุ้น. เวิร์กโฟลว์ที่ส่งมาจะทำงานเมื่อมีอีเวนต์ pull request — opened, synchronize (การพุชใหม่), ready_for_review (ดราฟต์พร้อมแล้ว) — และเมื่อมีคอมเมนต์บน PR เนื่องจากมันทำงานบนpull_request_target คำจำกัดความของเวิร์กโฟลว์จะถูกอ่านจาก base branch ซึ่งเป็นเหตุผลที่เวิร์กโฟลว์ต้องมีอยู่บน base branch ก่อนจึงจะทำงานสำหรับ PR ได้ หนึ่งรีวิวต่อหนึ่งพุช และconcurrency บล็อกยกเลิกการรันครั้งก่อนหน้า ดังนั้นการพุชที่ต่อเนื่องกันอย่างรวดเร็วจะไม่ทำให้เกิดรีวิวห้าครั้งสำหรับโค้ดที่เก่า

ตัวรันเนอร์คือ GitHub Actions บน ubuntu-latest งานนี้ต้องได้รับสิทธิ์สามอย่าง: สิทธิ์อ่านเนื้อหา, สิทธิ์เขียน pull requests (เพื่อโพสต์ความคิดเห็นแบบอินไลน์) และสิทธิ์เขียน issues (เพื่อโพสต์สรุปและล้างความคิดเห็นเก่า)

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

เกตคือการตรวจสอบสถานะ GitHub ไม่รู้ว่าคำว่า “review” หมายถึงอะไร มันรู้เพียงว่าการตรวจสอบ review ผ่านหรือไม่ คุณทำให้เกตมีผลจริงโดยกำหนดให้การตรวจสอบนั้นเป็น required ในการป้องกันบรานช์ นั่นคือกลไกทั้งหมดในการบล็อกการ merge — ไม่มีการเรียกใช้ admin API ไม่มี labels แค่การตรวจสอบ required ที่ล้มเหลว

สิ่งที่ไม่เกิดขึ้น: ไม่มีสิ่งใดเรียกใช้โค้ดของ PR เอ็นจินทำหน้าที่อ่านเพียงอย่างเดียว หลักการที่ไม่แปรเปลี่ยนเพียงข้อเดียวนี่เองที่ทำให้ pull_request_target ซึ่งเป็น trigger ที่ได้รับสิทธิ์พิเศษและปลอดภัยที่จะใช้กับคีย์ API แบบชำระเงิน

เครื่องมือโอเพนซอร์สคือตัวสร้างความแตกต่าง

ทุกสิ่งที่กล่าวข้างต้นเป็นจริงสำหรับเครื่องมือหลายชนิด สิ่งที่เครื่องมือส่วนใหญ่ไม่มีคือ การที่ทุกส่วนสามารถตรวจสอบได้และโฮสต์เองได้ ซึ่งเป็นสิ่งที่ที่เก็บ Orca-Code-Review มอบให้คุณ มันคือที่เก็บ GitHub สาธารณะภายใต้สัญญาอนุญาต MIT (JavaScript สร้างเมื่อ 25 มิถุนายน 2026) ซึ่งรวมรีวิวเป็น GitHub Action แบบคอมโพสิตที่นำกลับมาใช้ใหม่ได้ พร้อมกับตัวติดตั้ง และมันเป็นโค้ดเดียวกันกับที่ แอป OrcaCode Review ที่โฮสต์ไว้ ใช้รัน.

ใช้เวลาสิบนาทีในทรี แล้วคุณจะสามารถระบุทุกชิ้นส่วนที่เกี่ยวข้องกับ PR ของคุณ:

• action.yml — คอมโพสิตแอคชัน มีอินพุตที่ระบุไว้ประมาณสิบห้ารายการ ไม่มีการฮาร์ดโค้ดชื่อโมเดลใด ๆ ไว้ในนั้นเลย

• workflows/orca-code-review.yml — ตัวอย่างเวิร์กโฟลว์ฝั่งผู้ใช้ ซึ่งก็คือประมาณสิบห้าบรรทัดที่คุณคัดลอกไปใส่ใน .github/workflows/.

• recipes/ — routing DSL ซึ่งเป็นภาษาสำหรับกำหนดเส้นทาง นี่คือจุดที่เลือกโมเดลจริง ๆ

• rules/ — เกณฑ์การจัดระดับความรุนแรง (P0–P3), รูปแบบผลลัพธ์ที่บังคับใช้ และคำสั่งแนวปฏิบัติที่ป้อนเอกสารแนวปฏิบัติของโปรเจกต์เองเข้าสู่การตรวจสอบในฐานะข้อมูลอ้างอิงที่ไม่น่าเชื่อถือ

• scripts/ — ตัวกรองความแม่นยำ (L1 บวกกับตัวตัดสิน L2), ตัวป้องกัน diff, เกตผสาน, รายงานการรัน และเครื่องวัดโทเคน แต่ละอย่างมีขนาดเล็กและอ่านง่าย .mjs ซึ่งเป็นไฟล์ที่มีการทดสอบ.

• skills/setup-orca-code-review — ทักษะที่ตัวติดตั้งวางลงในเอเจนต์เขียนโค้ดของคุณ ครอบคลุมการติดตั้ง การกำหนดค่าใหม่ การแก้ไขปัญหา และการถอนการติดตั้ง

• .claude-plugin/ — สิ่งที่ทำให้ Claude Code ติดตั้งสกิลเป็นปลั๊กอินที่อัปเดตตัวเองได้

การติดตั้งคือโค้ดบรรทัดเดียวที่สอนให้ AI ของคุณรู้ว่าผลิตภัณฑ์คืออะไร จากนั้นก็หยุด:

npx @orcarouter/code-review

CLI จะตรวจจับเอเจนต์เขียนโค้ดที่คุณใช้ — แคตตาล็อกครอบคลุม 36 แพลตฟอร์ม ตั้งแต่ Claude Code, Cursor, Codex, OpenCode, และ Windsurf ไปจนถึง GitHub Copilot, Gem​ini CLI, Amazon Q Developer, Cline, RooCode และอื่นๆ — ติดตั้งสกิลแล้วส่งต่อ จากนั้นคุณก็ถามเอเจนต์ของคุณด้วยภาษาธรรมดาว่า: “ตั้งค่า OrcaCode Review ใน repo นี้,” “บล็อกเฉพาะ P0,” “ทำไมรีวิวถึงไม่รันล่ะ?” สกิลจะดูแลวงจรทั้งหมด: มันเขียนเวิร์กโฟลว์ นำคุณผ่านคีย์ API ตั้งค่าเกต และถามเฉพาะคำถามที่เป็นของคุณอย่างแท้จริง

Claude Code สามารถติดตั้งสกิลเป็นปลั๊กอินแทนได้ ซึ่งจะทำให้มันอัปเดตอยู่เสมอเมื่อ repo มีการเปลี่ยนแปลง:

เพิ่มปลั๊กอิน Continuum-AI-Corp/orca-code-review จากมาร์เก็ตเพลส

ติดตั้งปลั๊กอิน orca-code-review

ไม่มีเอเจนต์เลยหรือ? ไลฟ์ไซเคิลเดียวกันนี้ก็เป็นแค่ซับคอมมานด์ — init เขียนเวิร์กโฟลว์, reconfigure เปลี่ยนกฎการบล็อกและขีดจำกัด diff, doctor วินิจฉัยรีวิวที่ไม่รันหรือไม่โพสต์, uninstall ลบมันออก (นำการตรวจสอบที่จำเป็นออกก่อน). สกิลคือประตูหน้า ไม่ใช่ประตูเดียว หรือจะตั้งค่าด้วยตนเอง: คัดลอกเวิร์กโฟลว์ เพิ่มซีเคร็ตหนึ่งตัวชื่อว่า ORCAROUTER_API_KEY, และกำหนดให้ review เป็นการตรวจสอบที่จำเป็น.

เอนจินที่อยู่เบื้องล่างคือ Open Code Review ของ Ali​baba ซึ่งระบุเวอร์ชันที่แน่นอนและอยู่ภายใต้สัญญาอนุญาต Apache-2.0 OrcaCode เป็นตัวตัดสินใจว่าจะรีวิวอย่างไร ส่วน OrcaRouter เป็นตัวตัดสินใจว่าโมเดลใดจะทำงานนั้น การเปรียบเทียบระหว่างการโฮสต์เองกับการโฮสต์โดยผู้ให้บริการ — ว่า "ฟรี" แท้จริงแล้วมีต้นทุนเท่าไรเมื่อคุณโฮสต์เครื่องมือรีวิวโอเพนซอร์สด้วยตัวเอง — ได้ถูกกล่าวถึงอย่างละเอียดในบทความของเราเกี่ยวกับการรีวิวโค้ดแบบโอเพนซอร์ส

อะไรที่ทำงานตามลำดับในการ push ทุกครั้ง

การรู้ลำดับนั้นมีประโยชน์ เพราะแต่ละขั้นตอนอาจล้มเหลวหรือถูกข้ามได้โดยอิสระ:

• การ์ด diff ทำงานก่อนเสมอ ก่อนที่โมเดลจะได้ทำงาน หาก merge-base diff มีขนาดเกิน 512 KB หรือแตะต้องไฟล์มากกว่า 300 ไฟล์ การรีวิวจะถูกข้ามและมีประกาศโพสต์ ค่าเริ่มต้นคือ on-oversized-diff: fail ดังนั้น diff ที่ถูกทำให้เกินขีดจำกัดจะไม่สามารถผ่านด่านตรวจที่จำเป็นโดยไม่ได้รับการตรวจสอบได้ และนี่ยังเป็นการควบคุมค่าใช้จ่าย: PR ที่ใหญ่เกินไปมีค่าใช้จ่ายเป็นศูนย์โทเค็น

• เอ็นจินตรวจสอบ diff หนึ่งรอบ ความขนานต่อไฟล์มีค่าเริ่มต้นที่ 24 โดยมีเพดานเวลาจริง 20 นาทีต่อรอบ

• ตัวกรองความแม่นยำจะประมวลผลภายหลังข้อค้นพบดิบ L1 ซึ่งเป็นตัวกรองเชิงกำหนด จะตรวจสอบว่าชิ้นส่วนโค้ดที่มีอยู่จริงที่แต่ละข้อค้นพบอ้างไว้นั้นตรงกับคอมมิตที่ตรวจสอบ และย้ายตำแหน่งหรือทิ้งรายการที่ไม่ตรงกัน L2 ซึ่งเป็นตัวตัดสินแบบ LLM จะจัดกลุ่มข้อค้นพบตามสาเหตุต้นตอ และทิ้งกลุ่มที่มีความมั่นใจต่ำ ทั้งสองชั้นเป็นแบบ soft-fail: หากเกิดข้อผิดพลาด ระบบจะคงข้อค้นพบจากขั้นตอนก่อนหน้าไว้และไม่ยุติการตรวจสอบ

• เกตนี้มีผลบังคับใช้ ผลการตรวจพบ P0 และ P1 จะทำให้การตรวจสอบไม่ผ่าน โดยสรุป PR จะนับทุกจุดที่พบ รวมถึงจุดที่ถูกมิวต์ (muted) ไว้จาก diff ด้วย

• มิเตอร์จะพิมพ์ค่าใช้จ่ายที่เกิดขึ้น มิเตอร์อินพุตบันทึกการคิดบัญชีโทเคนต่อการเรียกใช้ — พรอมป์ คอมพลีชัน โทเคนที่แคชไว้ และโมเดลที่เราเตอร์เลือกใช้ — และพิมพ์ตารางสรุปในบันทึกงาน

• รายงานการรันแบบไม่บังคับส่งจำนวนระดับความรุนแรงและเมตาดาทาของเกตไปยังคอนโทรลเพลนของ OrcaRouter สำหรับแดชบอร์ดการวิเคราะห์ โดยไม่มีโค้ด ไม่มี diff และไม่มีข้อความการตรวจพบ

สิ่งที่คุณกำหนดค่าจริง ๆ

มีพื้นผิวอยู่สามแบบ และพวกมันมีรัศมีการระเบิดที่แตกต่างกันมาก

1. ไฟล์เวิร์กโฟลว์ เวิร์กโฟลว์ของผู้ใช้ถูกทำให้บางเบาโดยตั้งใจ อินพุตที่ควรปรับแต่งอยู่ในแอคชัน: block-on (ซึ่งระดับความรุนแรงใดที่ทำให้การตรวจสอบล้มเหลว — ค่าเริ่มต้น P0,P1), fix-first (ซึ่งระดับความรุนแรงใดที่หยุดการรีวิวแบบละเอียดก่อนเวลา), auto-review-authors (รายการอนุญาตสำหรับผู้ที่จะได้รับการรีวิวอัตโนมัติ), max-diff-kb และ max-diff-files และ on-oversized-diff (ตัวป้องกันขนาด), timeout-minutes, concurrency, meter, และ report. ทุกตัวมีค่าเริ่มต้นที่ระบุไว้แล้ว ดังนั้นเวิร์กโฟลว์ใหม่จึงประกอบด้วย YAML ห้าบรรทัดบวกซีเคร็ตหนึ่งตัว

2. แดชบอร์ด. ด้วย settings: true (ค่าเริ่มต้น) แต่ละครั้งที่รันจะดึงการตั้งค่าสำหรับแต่ละพื้นที่เก็บข้อมูลจาก OrcaRouter → Apps → OrcaCode Review: โมเดล โหมดรีวิว นโยบายการผสาน ระดับความรุนแรงของรายงาน โหมดเงียบ รีวิวแบบละเอียด เกณฑ์การประเมินที่กำหนดเอง และมาตรการป้องกัน ตั้งค่า settings: "false" และไฟล์เวิร์กโฟลว์เป็นหลัก — ไม่มีค่าจากแดชบอร์ดใดแทนที่ได้ หากคุณไม่เปิดคอนโซล คุณจะไม่สูญเสียความสามารถใด ๆ ของระบบ คุณเพียงกำหนดค่าใน YAML

3. สูตรการจัดเส้นทาง — สูตรที่ผู้คนมักมองข้ามแอ็กชันไม่เคยระบุชื่อโมเดล แต่จะฉีดข้อเท็จจริงดิบเป็น request headers แทน — ว่าการรันนั้นถูกบันทึกเป็นระดับใด, รอบก่อนหน้าพบ P0/P1 หรือไม่, และเครื่องหมายเลนส์เมื่อคำขอเป็นตัวตัดสิน L2 — จากนั้น DSL recipe ของ workspace router จะแมป header เหล่านั้นไปยังโมเดลที่เป็นรูปธรรม สูตรที่มาพร้อมกับการจัดส่งจะตั้งค่าเริ่มต้นให้การรีวิวใช้ DeepSeek V4 Flash และตัวตัดสินใช้ GLM-5.3 โดยจงใจส่งทั้งสองไปยังโมเดลคนละตัว การเปลี่ยนโมเดลที่รีวิวโค้ดของคุณคือการแก้ไขสูตรนั้นใน workspace ของคุณเอง: ไม่ต้องเพิ่มเวอร์ชันแอ็กชัน, ไม่ต้องเขียน YAML ใหม่, ไม่ต้องดีพลอยใหม่

สัญญาเรื่องระดับความรุนแรงคือการตั้งค่าอิสระสองอย่าง ไม่ใช่อย่างเดียว นโยบายการรวมกำหนดว่าอะไรจะบล็อกการรวม ระดับความรุนแรงที่รายงานกำหนดว่าอะไรจะถูกโพสต์บน diff ค่าเริ่มต้นที่ตั้งมาให้คือ P0/P1 บล็อก, P2/P3 ผ่าน ระดับความรุนแรงที่บล็อกจะถูกโพสต์เสมอ ไม่ว่าการตั้งค่าการรายงานจะกำหนดว่าอย่างไร — การตรวจที่ล้มเหลวโดยไม่มีอะไรบน diff มาอธิบายนั้นแย่กว่าการตรวจที่ส่งเสียงรบกวน P0 หมายถึงช่องโหว่ด้านความปลอดภัยที่สามารถใช้โจมตีได้, การสูญเสียข้อมูล, การแครชบนเส้นทางปกติ, หรือบิลด์ที่เสีย; P1 หมายถึงบั๊กจริงแต่จำกัดวง; P2 หมายถึงข้อบกพร่องจริงที่เกิดขึ้นเฉพาะเมื่อมีเงื่อนไขเบื้องต้นที่ผิดปกติ; P3 คือเรื่องสไตล์ เมื่อลังเลระหว่างสองระดับ หลักเกณฑ์บอกให้เลือกระดับที่ต่ำกว่า

ค่าใช้จ่ายเท่าไร

คิดต่อโทเคน ไม่ใช่ต่อที่นั่ง คุณเลือกโมเดลบน OrcaRouter การเรียกเก็บเงินจะคิดตามโทเคนที่ใช้ และ มิเตอร์จะทำให้ตัวเลขต่อรอบมองเห็นได้แทนที่จะคลุมเครือ กลไกของ GitHub การรีวิวโค้ดแบบคิดค่าบริการตามปริมาณของ Copilot ตั้งแต่วันที่ 1 มิถุนายน 2026 และวิธีที่ผู้รีวิวบุคคลที่สามเข้ามาอยู่ในขั้นตอนการทำงานนั้น ครอบคลุมอยู่ในคู่มือรีวิวโค้ดบน GitHub ของเรา การเปรียบเทียบต้นทุนแบบเรียงทีละฟิลด์ — ผลิตภัณฑ์แบบคิดต่อที่นั่งเทียบกับแบบคิดต่อโทเคน พร้อมตัวอย่างการคำนวณ — อยู่ในบทความเปรียบเทียบเครื่องมือรีวิวโค้ดด้วย AI ของเรา และคำถามว่าการรีวิวหนึ่งรอบมีค่าใช้จ่ายเป็นโทเคนเท่าใดเมื่อผู้รีวิวลงไปสำรวจที่เก็บโค้ดจริง (ความแตกต่างระหว่างบอตกับเอเจนต์) อยู่ในบทความเกี่ยวกับเอเจนต์รีวิวโค้ดของเรา ประเด็นที่บทความนี้เพิ่มเติมคือรูปร่างของบิล: มันปรับขนาดตามโค้ดที่คุณรีวิว ไม่ใช่ตามจำนวนคนที่รีวิว

ตัวควบคุมค่าใช้จ่ายสองตัวสำคัญตั้งแต่วันแรก บน repository สาธารณะ pull_request_target จะข้ามเกตการอนุมัติ fork ของ GitHub และคีย์รีวิวถูกคิดค่าใช้จ่ายผ่านวอลเล็ต — คนแปลกหน้าสามารถเปิด PR และทำให้เกิดการรีวิวที่เสียค่าใช้จ่ายได้ ตั้งวงเงินวอลเล็ตพร้อมการแจ้งเตือนบนคีย์ และตั้งค่า auto-review-authors เป็นค่าประมาณ OWNER,MEMBER,COLLABORATOR,CONTRIBUTOR เพื่อให้ contributor ที่ไม่รู้จักไม่ถูกรีวิวอัตโนมัติ และ diff guard ตามที่กล่าวไว้ หมายความว่า PR ที่ใหญ่เกินไปไม่มีค่าใช้จ่ายใดๆ

อะไรพัง

การรีวิวอัตโนมัติคือ CI มันพังเหมือน CI และโหมดความล้มเหลวส่วนใหญ่ไม่ใช่ความผิดของโมเดล:

• เวิร์กโฟลว์ไม่เคยทำงาน สำหรับ pull_request_target เวิร์กโฟลว์จะถูกอ่านจาก base branch — เวิร์กโฟลว์ที่เพิ่มเฉพาะใน PR branch จะยังไม่ทำงานจนกว่าจะมีการ merge นอกจากนี้ ให้ตรวจสอบว่าเปิดใช้งานแอปแล้ว, auto_review เปิดอยู่, PR ไม่ได้เป็น draft (draft จะถูกข้ามในโหมด ready_for_review) และเปิดใช้งาน Actions บน repository แล้ว (forked repos ถูกปิดไว้ตั้งแต่แรก)

• /orcacode-review ไม่ทำอะไร. ทริกเกอร์ความคิดเห็นกำหนดให้ความคิดเห็นต้องเริ่มต้นด้วยหนึ่งในสี่รูปแบบการสะกด — /orcacode-review, /orcacode review, @orcacode-review, @orcacode review — และผู้แสดงความคิดเห็นต้องเป็น OWNER, MEMBER หรือ COLLABORATOR. การมีช่องว่างนำหน้าจะทำให้ไม่ตรงกัน. คำสั่งของผู้มีส่วนร่วมภายนอกจะถูกเพิกเฉยอย่างเงียบ ๆ โดยตั้งใจ: คำสั่งนี้จะเรียกใช้เวิร์กโฟลว์ที่มีสิทธิ์พิเศษซึ่งเก็บคีย์ที่ชำระเงินแล้ว.

• ข้อผิดพลาดการตรวจสอบสิทธิ์ secret ถูกตั้งชื่อผิดหรือขาดหายไป คีย์ถูกเพิกถอนหรือเกินงบประมาณ หรือเวิร์กโฟลว์ถูกเปลี่ยนเป็น pull_request (ซึ่งไม่สามารถอ่าน secret จาก fork ได้)

• การเช็คเป็นสีแดงพร้อมกับข้อความ “diff too large”. นั่นคือ size guard ที่ทำงานตามที่ตั้งค่าไว้ แยก PR หรือเพิ่มขีดจำกัด หรือตั้งค่า on-oversized-diff: pass — และจงเข้าใจว่า เมื่อมีการเช็คที่บังคับ (required check) การผ่าน (pass) หมายความว่า PR ที่ใหญ่พอจะผ่านประตูไปได้โดยไม่ถูกตรวจทาน

• การรีวิวทำงานแต่ไม่มีความคิดเห็นปรากฏ สาเหตุสามประการ ทั้งหมดไม่เป็นอันตรายหรือเกิดจากการตั้งค่า: การรันที่สะอาดจะโพสต์สรุปแทนที่จะเป็นความคิดเห็นแบบอินไลน์; โหมดเงียบกำลังปิดเสียง P2 ในเวลาที่โพสต์ (ทั้งเกตและรายงานยังนับมันอยู่); หรือตัวกรองความแม่นยำได้ทิ้งข้อค้นพบ — L1 ทิ้งข้อค้นพบที่ส่วนโค้ดไม่ตรงกับคอมมิต, L2 ทิ้งคลัสเตอร์ที่มีความมั่นใจต่ำ. การนับระดับความรุนแรงในบันทึกของจ็อบจะบอกคุณว่าสาเหตุใด.

ท่าทีด้านความมั่นคงปลอดภัยควรกล่าวอย่างตรงไปตรงมา เนื่องจากเป็นสิ่งที่ทำให้การออกแบบทั้งหมดปลอดภัย เอนจินอ่านเฉพาะ diff และไฟล์ใน repository เท่านั้น ไม่เคยเรียกใช้โค้ดของ PR ตัวรีวิวไม่มีอำนาจในการ merge — ข้อค้นพบสามารถบล็อกการ merge หรือเพิ่มความคิดเห็นได้ แต่ไม่มีเส้นทางโค้ดใดที่ทำให้เอาต์พุตของโมเดลอนุมัติหรือแก้ไข repository ได้ ข้อค้นพบที่ไม่มีแท็กจะล้มเหลวอย่างปลอดภัย (fail safe) โดยถือเป็นตัวบล็อกแทนที่จะเป็นเพียงคำแนะนำ และรายงานผลการรันไม่มีโค้ดหรือข้อความของข้อค้นพบ การตั้งค่าแบบสองชั้นที่จับสิ่งที่การรีวิวแบบรอบเดียวพลาดไปเป็นหัวข้อของบทความด้านความมั่นคงปลอดภัยของการรีวิวโค้ดด้วย AI ของเรา ส่วนโมเดลภัยคุกคามข้างต้นถูกระบุไว้ใน SECURITY.md ของ repository

เมื่อการรีวิวอัตโนมัติเป็นเครื่องมือที่ผิด

มันผิดพลาดบ่อยกว่าที่ผู้จำหน่ายเครื่องมือยอมรับ งดเว้นในกรณีนี้เมื่อ:

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

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

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

• ไม่มีใครอ่านผลการตรวจสอบ. การตรวจสอบที่ไม่มีใครนำไปปฏิบัติคือเวิร์กโฟลว์ที่ล้มเหลวแต่ยังแสดงสถานะสีเขียวตลอดไป นี่คือความล้มเหลวแบบเงียบที่พบบ่อยที่สุด และไม่มีตัวกรองความแม่นยำใดแก้ไขได้.

• การรีวิวต้องรันโค้ด. หากสิ่งที่คุณต้องการคือชุดทดสอบสำหรับ PR การรีวิวด้วย LLM เป็นเครื่องมือที่ผิด มันอ่านได้ แต่มันไม่รันโค้ด การสแกนความปลอดภัยที่ต้อง build และรัน artifact ควรอยู่ในงานแยกที่มีขอบเขตอย่างรอบคอบ — จำไว้ว่า workflow การรีวิวจะต้องไม่ถูกขยายให้รันโค้ดที่ควบคุมโดย PR

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

ผลบวกลวง และสิ่งที่การกรองแบบแม่นยำแก้ไขได้และไม่ได้

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

เลเยอร์ดีเทอร์มินิสติก (L1) กำจัด ghost finding: เอ็นจินบางครั้งอ้างถึงโค้ดที่ไม่มีอยู่จริง — สนิปเพ็ตที่หลุดลอยไป หรือ finding ที่ถูกคัดลอกไปยังไฟล์ข้างเคียง L1 ตรวจสอบสนิปเพ็ตโค้ดที่มีอยู่ของแต่ละ finding กับคอมมิตที่ตรวจสอบจริง แล้วย้ายกลับหรือทิ้งรายการที่ไม่ตรงกัน ซึ่งช่วยแก้ false positive ประเภท "บรรทัดนี้ไม่มีอยู่ด้วยซ้ำ" ซึ่งเป็นเชิงกลและตรวจสอบได้

ชั้นผู้ตัดสิน (L2) กำจัดรายงานที่ซ้ำกันและการอ้างสิทธิ์ที่ไม่ได้รับการสนับสนุน กล่าวคือ ผู้ตัดสิน LLM จะจัดกลุ่มข้อค้นพบตามสาเหตุหลัก แล้วละทิ้งกลุ่มที่มีความเชื่อมั่นต่ำกว่าเกณฑ์ตัดสิน (ค่าเริ่มต้น 0.5) ซึ่งช่วยแก้ปัญหา “บั๊กเดียวกันถูกรายงานด้วยวิธีที่ต่างกันสามแบบ” และข้อค้นพบเชิงคาดเดา

สิ่งที่ทั้งสองเลเยอร์ไม่ได้แก้ไขนั้นควรค่าแก่การพูดออกมาดัง ๆ ผลการค้นหาที่ผิดแต่มั่นใจรอดพ้นจากผู้ตัดสิน — ผู้ตัดสินคือ LLM และ LLM ที่ฟังดูมั่นใจไม่เหมือนกับผลการค้นหาที่เป็นความจริง ผู้ตัดสินที่ทำงานบนโมเดลเดียวกับผู้ตรวจสอบจะเห็นด้วยกับตัวเอง และการตรวจสอบก็จะไร้ประสิทธิภาพในขณะที่ยังรายงานความสำเร็จ ซึ่งเป็นเหตุผลว่าทำไมสูตรที่เผยแพร่จึงส่งผู้ตัดสินไปยังโมเดลที่แตกต่างจากผู้ตรวจสอบ และเกณฑ์การวัดความรุนแรงก็ถูกตั้งไว้อย่างระมัดระวังโดยเจตนา — “เมื่อลังเลระหว่างสองระดับ ให้เลือกระดับที่ต่ำกว่า” — ซึ่งหมายความว่าบั๊กจริงแต่มีเงื่อนไขมีแนวโน้มที่จะลงเอยเป็นคำแนะนำ P2 มากกว่าที่จะเป็น P1 ที่บล็อกการทำงาน นั่นคือการปรับเทียบที่ถูกต้องสำหรับเครื่องมือที่ต้องไม่บล็อกทุกอย่าง แต่มันคือการปรับเทียบ: มันแลกการพลาดตัวบล็อกเพื่อการแจ้งเตือนที่ผิดพลาดน้อยลง สรุป PR นับทุกผลการค้นหาเสมอ ดังนั้น P2 ที่ถูกลดเสียงยังคงอยู่ให้อ่าน หากการแลกเปลี่ยนนี้ผิดสำหรับทีมของคุณ เกณฑ์และการตั้งค่าผู้ตัดสินคือการกำหนดค่า ไม่ใช่ทิกเก็ตสนับสนุน

สรุป

สำหรับทีมที่ใช้ GitHub Actions อยู่แล้ว เครื่องมือโอเพนซอร์สเป็นวิธีที่ถูกที่สุดในการรับการตรวจโค้ดอัตโนมัติในทุก PR: ไฟล์เวิร์กโฟลว์หนึ่งไฟล์ ซีเคร็ตหนึ่งรายการ ค่าใช้จ่ายโทเคนที่ปรับตามปริมาณโค้ดที่ตรวจสอบ และตัวเลือกโมเดลที่คุณเป็นเจ้าของ ซื้อผลิตภัณฑ์แบบคิดค่าบริการต่อที่นั่งเมื่อคุณต้องการไม่ต้องดูแลระบบและมีผู้ให้บริการให้ติดต่อ — ไม่ใช่เพราะการตรวจจะดีกว่า แต่เพราะคุณกำลังซื้อภาระของคนอื่นแทนที่จะจัดการด้วยตัวเอง และก่อนที่คุณจะตั้งค่าอะไรทั้งนั้น ให้ถามว่าผลการตรวจนั้นจะมีคนอ่านหรือไม่ เครื่องมือนี้สามารถทำให้การตรวจเกิดขึ้นโดยอัตโนมัติ แต่ไม่สามารถทำให้ใครอ่านมันได้

อยากได้ตัวรีวิวแบบเดียวกันโดยไม่ต้องรันเองหรือ? OrcaCode Review รันฮาร์เนสแบบเดียวกันนี้ในรูปแบบ GitHub App ที่โฮสต์ไว้ — สูตรเปิดเดียวกัน, ค่าใช้จ่ายต่อโทเค็นเท่ากัน, ไม่มีค่าใช้จ่ายรายหัว.