รีวิวด้วย AI

รูปร่างหน้าตาของรีวิว

รีวิวด้วย AI คือการรันไปป์ไลน์ pr_review ที่มาพร้อมระบบหนึ่งครั้งต่อ pull request ที่เปิดอยู่หนึ่งรายการ ไปป์ไลน์จะเปิดสเปซรีวิวของ PR กระจายเอเจนต์รีวิวเวอร์ ออกไปอ่าน diff ในเช็คเอาท์ที่แยกโดดของสเปซนั้น แต่ละตัวยื่นข้อค้นพบเป็น โหนดรีวิว แบบมีโครงสร้าง เอเจนต์หัวหน้ารวบรวมข้อค้นพบเหล่านั้นเป็นคำอธิบายแบบพาไล่ดู และตัวสรุปผลคำนวณคำตัดสินหนึ่งค่า: Ship, Hold หรือ Block สิ่งที่ไปป์ไลน์ ไม่เคยทำคือการเผยแพร่ — การโพสต์ขึ้น GitHub เป็นขั้นตอนแยกต่างหากที่มนุษย์เป็นคนลงมือทำ โดยเจตนา

ส่วนที่เหลือของหน้านี้อธิบายชิ้นส่วนต่าง ๆ และเหตุใดจึงถูกออกแบบมาแบบนี้

หนึ่งสเปซรีวิวต่อหนึ่ง PR

บริบทรีวิวของ PR คือสเปซรับส่งข้อความ — โหมด review ชนิด pr — ที่เชื่อมกับ pull request ผ่าน ความเชื่อมโยงสเปซรีวิว สเปซนี้ถูกสร้างแบบ idempotent: หน้า PR ไปป์ไลน์รีวิว และพื้นผิวแชททั้งหมดต่างก็เข้าถึงสเปซ backing เพียง หนึ่ง เดียวของ PR ผ่านเส้นทางโค้ดเดียวกัน ดังนั้นเทมเพลตที่รีวิว PR กับมนุษย์ที่เปิด PR จึงไม่มีทาง ไปจบในสองห้องที่ต่างกันโดยดูเช็คเอาท์คนละชุด

worktree ที่แยกโดดของสเปซมี PR ถูกเช็คเอาท์ไว้ที่ head ref ของมัน หนึ่งห้องยังหมายถึง เช็คเอาท์หนึ่งชุด: รีวิวเวอร์ทุกตัวทำงานในสเปซเดียวกัน แทนที่แต่ละตัวจะได้สำเนา เวิร์กสเปซของตัวเอง

รีวิวเวอร์แต่ละตัวโพสต์ลงสตรีมที่มีชื่อของตัวเองภายในสเปซเดียวนั้น และข้อค้นพบเป็น ข้อความ review_node ไม่ใช่ข้อความร้อยเรียงธรรมดา การรวบรวมทั้งสเปซในตอนท้ายเป็น เจตนาที่ตั้งใจไว้ — คำตัดสินที่คำนวณจากข้อค้นพบของเธรดเดียวจะกลายเป็นคำตัดสินต่อ รีวิวเวอร์เพียงคนเดียวอย่างเงียบ ๆ

ความเชื่อมโยงนี้มีบันไดสถานะ — requested → in progress → awaiting approval → completed — ซึ่งเป็นสิ่งที่กั้น เผยแพร่ไปยัง GitHub บนแท็บรีวิวของ PR

ระดับการรีวิว

ความลึกของการรีวิวเป็นนโยบายของเวิร์กสเปซที่มีสามระดับ ตั้งค่าได้ที่ การตั้งค่า → เวิร์กสเปซ → ทั่วไป บนการ์ด นโยบายเวิร์กสเปซ:

ระดับ	รีวิวเวอร์ที่กระจายออกไป	การรายงาน
light	เฉพาะวิศวกร	เฉพาะสิ่งที่สำคัญจริง ๆ
balanced	วิศวกร, QA, สถาปนิก (ค่าเริ่มต้น)	การตรวจตามมาตรฐาน
thorough	ทั้งห้าคน รวมความปลอดภัยและประสิทธิภาพ	ไม่มีการลดระดับสิ่งใด

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

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

โหนดรีวิว: ข้อค้นพบในฐานะข้อมูล ไม่ใช่ข้อความร้อยเรียง

ข้อค้นพบที่ยื่นด้วย add_review_node จะกลายเป็น โหนดรีวิว บน PR — ซึ่งเป็น สิ่งที่แท็บรีวิวแสดง เป็นสิ่งที่คำตัดสินคำนวณขึ้นมา และเป็นสิ่งที่ “เผยแพร่ไปยัง GitHub” เปลี่ยนเป็นความคิดเห็นแบบอินไลน์ รีวิวเวอร์ที่คืนแต่ข้อความร้อยเรียง ทำให้ได้การรันไปป์ไลน์ที่ดูเหมือนสำเร็จและพื้นผิวรีวิวที่ว่างเปล่า การยื่นข้อค้นพบคือ ส่วนที่รับน้ำหนักทั้งหมด

โหนดแต่ละอันบรรจุ:

ฟิลด์	ค่า
ชนิด	bug, suggestion, recommendation, question, ticket
ลำดับความสำคัญ	P0 (วิกฤต) → P3 (เรื่องเล็กน้อย)
ชุดคัดแยกสามค่า	หมวดหมู่ (security, stability, …), ความรุนแรง, ความพยายาม
จุดยึด	เส้นทางไฟล์ บรรทัดเริ่มต้นและสิ้นสุด
การนำส่งวิธีแก้ไข	บรรทัดแทนที่ที่แนะนำ, diff ที่ไม่บังคับ, พรอมป์ต์แก้ไขที่ไม่บังคับ
ความมั่นใจ	คะแนน [0, 1]
เหตุผล	การวิเคราะห์ที่เขียนไว้ก่อนข้อค้นพบ

สองรายละเอียดนี้เป็นเจตนาที่ตั้งใจไว้ ข้อเสนอแนะ GitHub แบบคลิกเดียวจะถูกเสนอ เฉพาะเมื่อรีวิวเวอร์ระบุบรรทัดแทนที่ที่แน่นอนมาให้เท่านั้น — การอนุมานบรรทัดเหล่านั้น จาก unified diff จะผิดพลาดอย่างเงียบ ๆ และการคอมมิตแบบคลิกเดียวจากการอนุมานที่ผิด ก็แย่กว่าการไม่มีปุ่มเลย และสคีมาของ add_review_node วาง reasoning ไว้ก่อน ข้อค้นพบ ดังนั้นโมเดลที่เติมออบเจกต์ตามลำดับในสคีมาจะเขียนการวิเคราะห์ก่อน ฟิลด์นี้เป็นทางเลือก: การละเว้นไม่ได้ทำให้โหนดถูกปฏิเสธ โหนดที่เพย์โหลดผิดรูปแบบ จะหายไปแทนที่จะปนเปื้อนรีวิว

ฉันทามติระหว่างเพื่อนรีวิวเวอร์

โหนดหนึ่งอันเดินผ่าน open → consensus-ready → resolved หรือ dismissed ขั้นกลางคือหัวใจของโมเดลนี้: ข้อค้นพบจะเลื่อนขั้นก็ต่อเมื่อรีวิวเวอร์เพื่อนร่วมงาน ยืนยันมัน และเอเจนต์ไม่สามารถยืนยันข้อค้นพบของตัวเองได้เลย เครื่องมือ MCP publish_review_to_github และค่าเริ่มต้นของ RPC ยังคงเผยแพร่เฉพาะข้อค้นพบ ที่เพื่อนยืนยันแล้วเท่านั้น ส่วนปุ่ม เผยแพร่ไปยัง GitHub ของแท็บรีวิวกลับส่ง ข้อค้นพบที่ยังเปิดอยู่ทั้งหมดที่เหลือ

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

เมื่อรีวิวเวอร์ขัดกัน — ไฟล์และบรรทัดเดียวกัน ลำดับความสำคัญต่างกันสองระดับขึ้นไป หรือตัวหนึ่งเรียกว่า bug ขณะที่อีกตัวเรียกว่า suggestion — ความขัดแย้งจะถูกแสดง เหนือรายการข้อค้นพบ นั่นคือจุดที่ความเห็นของรีวิวเวอร์แยกจากกันและดุลยพินิจ ของมนุษย์มีค่ามากที่สุด

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

Cohort: สิ่งที่รีวิวจัดกลุ่มอยู่รอบ ๆ

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

กฎความซื่อสัตย์สองข้อกำหนดรูปร่างของสิ่งนี้ คีย์ของ cohort มาจากเนื้อหาและเสถียร ข้ามการ push ดังนั้นข้อค้นพบและความคืบหน้าการรีวิวจึงรอดจากการ rebase หรือ force-push แทนที่จะกลายเป็นเด็กกำพร้า และเมื่อรีโปไม่มีดัชนีโค้ด การจัดกลุ่มจะถอยกลับ ไปใช้เส้นทางแบบธรรมดาและบอกตามนั้น — การถอยกลับไม่เคยแสร้งมีความมั่นใจ เชิงความหมาย

แกนรีวิวและเกต

นอกจากข้อค้นพบของรีวิวเวอร์ รีวิวยังสะสม ผลลัพธ์รายแกน: หกแกน สองชนิด

แกน	ชนิด	ที่มา
correctness, security	ขับเคลื่อนด้วยโทเคน	ข้อค้นพบของรีวิวเวอร์เอง
testGap	ขับเคลื่อนด้วยโทเคน	ข้อค้นพบของรีวิวเวอร์
visual, apiContract	กำหนดแน่นอน	คำนวณโดยไม่ใช้โทเคน
performance	กำหนดแน่นอน	มีแค่ enum — ไม่มีอะไรในผลิตภัณฑ์คำนวณผลลัพธ์

คำตัดสินของแกนคือ pass, warn, fail, partial หรือ unavailable — และ มีเพียง pass หรือ warn เท่านั้นที่ผ่านเกตได้ ความแตกต่างระหว่าง fail, partial และ unavailable เป็นส่วนที่รับน้ำหนัก: แกนที่มีเกตซึ่งทำงานไม่ครบหรือรันไม่ได้เลย จะยึดคำตัดสินโดยรวมไว้แทนที่จะปล่อยผ่าน การไม่มีหลักฐานไม่เคยกลายเป็นเกตสีเขียว

บางแกนเป็นเพียงคำแนะนำโดยเจตนา แกนช่องว่างการทดสอบที่ได้มาจาก cohort ไม่สามารถ มองเห็นความครอบคลุมของการฉีดพึ่งพาหรือ factory ได้ — รีโปที่ไม่มีดัชนีแต่มีชุดทดสอบ ละเอียด กับรีโปที่ไม่มีเทสต์เลย ดูเหมือนกันเป๊ะจากตรงนั้น ดังนั้นการอ้างว่าเป็นอย่างใด อย่างหนึ่งจึงเป็นการโกหก; มันปรากฏบนแดชบอร์ดโดยไม่ผ่านเกต แกนที่ขับเคลื่อนด้วยโทเคน เป็นเพียงคำแนะนำ เพราะลำดับความสำคัญของข้อค้นพบเป็นตัวขับคำตัดสินอยู่แล้ว และการตั้งเกตซ้ำบนนั้นจะนับซ้ำ

คำตัดสิน

ตัวสรุปผลคำนวณคำตัดสินจากข้อค้นพบที่มีสถานะ open หรือ consensus-ready:

• ข้อค้นพบ P0 ใด ๆ ที่มีความมั่นใจ ≥ 0.7 → Block
• ไม่เช่นนั้น ข้อค้นพบ P0 ใด ๆ (ความมั่นใจต่ำ) หรือ P1 ใด ๆ → Hold
• ไม่เช่นนั้น → Ship

คำตัดสินพกความมั่นใจรวมที่ได้มาจากการกระจายของความมั่นใจที่ร่วมสมทบ — ความสอดคล้อง เพิ่มมัน ความแตกต่างลดมัน

การรวบรวมของเอเจนต์หัวหน้า (CEO) เป็นรอบบรรณาธิการ ไม่ใช่การลงรายการซ้ำ: สำเนาข้อค้นพบชุดที่สองที่เขียนด้วยมือคือสิ่งที่เพี้ยนไปจากของจริงเสมอ ข้อค้นพบที่ซ้ำกัน จะถูกลดระดับแทนที่จะถูกกล่าวซ้ำ — รีวิวเวอร์หลายตัวถูกชี้ไปที่ diff เดียวโดยมีขอบเขตงาน ที่ทับซ้อนกันโดยเจตนา ดังนั้นข้อบกพร่องเดียวกันที่ไปถึงตัวสรุปผลสามครั้งคือระบบ ทำงานถูก; การเผยแพร่มันสามครั้งคือระบบที่รั่วสถาปัตยกรรมของตัวเองเข้าไปในกล่องขาเข้า ของผู้อ่าน ในการรีวิวซ้ำ ข้อค้นพบจะถูกทำลายนิ้วมือและ diff เทียบกับรอบก่อนหน้า ดังนั้นส่วนต่างคือสิ่งที่ปรากฏ

ท้ายที่สุดแกนต่าง ๆ ถูกพับเข้ามา และมันทำได้เพียงทำให้คำตัดสิน รุนแรงขึ้น: แกนที่มีเกตและล้มเหลวบังคับให้เป็น Block — ข้อค้นพบลงมติชนะมันไม่ได้ — และแกน ที่มีเกตซึ่งทำงานไม่ครบบังคับให้เป็น Hold อย่างน้อย

การเผยแพร่ยังอยู่กับคุณ

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

• มีการส่งรีวิว GitHub หนึ่งครั้ง ข้อค้นพบที่แก้ไขหรือปิดไปแล้วจะถูกข้าม ปุ่มนี้ เผยแพร่ข้อค้นพบที่ยังเปิดอยู่ทั้งหมดที่เหลือ (selection: all_open) ส่วนเครื่องมือ MCP publish_review_to_github ยังคงมีค่าเริ่มต้นเป็นข้อค้นพบที่เพื่อนยืนยันแล้ว เท่านั้น (consensus)
• ข้อค้นพบที่ยึดกับไฟล์และบรรทัดจะกลายเป็นความคิดเห็นแบบอินไลน์; ส่วนที่เหลือ ถูกพับเข้าไปในเนื้อหาสรุป แต่ละอันมีส่วนท้าย “— Control Center AI review” เพื่อให้ที่มาไม่กำกวม
• จุดยึดจะถูกตรวจสอบใหม่เทียบกับ diff ปัจจุบัน ของ PR ตอนเผยแพร่ ความคิดเห็น บนโค้ดที่ถูกเขียนใหม่ไปแล้วคือสิ่งที่ทำลายความเชื่อมั่นมากที่สุดที่รีวิวเวอร์ทิ้งไว้ได้; หาก GitHub ปฏิเสธจุดยึดแบบอินไลน์อยู่ดี รีวิวทั้งหมดจะถูกส่งใหม่โดยพับทุกข้อค้นพบ เข้าในเนื้อหา เพื่อไม่ให้มีสิ่งใดถูกทิ้งอย่างเงียบ ๆ
• คำตัดสิน Block ถูกส่งเป็น REQUEST_CHANGES; Hold เป็น COMMENT; Ship เป็น APPROVE จากปุ่ม (approve_on_ship: true) เครื่องมือ MCP ปล่อย Ship เป็น COMMENT เว้นแต่คุณจะส่ง approve_on_ship
• รีวิวถูกโพสต์ภายใต้ตัวตนแอปของเซิร์ฟเวอร์ ใครกดเผยแพร่ถูกบันทึกไว้สำหรับ เกตตามบทบาทและบันทึกการตรวจสอบ; ไม่ใช่ผู้เขียนบน GitHub

การเผยแพร่ประกาศคลาสการกระทำ prPublish ดังนั้นจุดคอขวดของกฎคุมจึงกั้นมัน เหมือนการกระทำที่เปลี่ยนแปลงใด ๆ — มันจะถามยืนยันตามค่าเริ่มต้นและปฏิเสธ เมื่อไม่มีผู้อนุมัติเชื่อมต่ออยู่ ดูกฎคุม

สิ่งที่รีวิวเวอร์ทำได้

เอเจนต์รีวิวเวอร์รันในโหมด review: แซนด์บ็อกซ์แบบอ่านอย่างเดียวและรายการ เครื่องมือที่อนุญาตซึ่งคัดสรรไว้ ครอบคลุมข้อค้นพบ ความเห็น ตั๋วงาน และการรีวิว โดยเพื่อนร่วมงาน — แต่ไม่มีการเปลี่ยนแปลงใด ๆ รีวิวเวอร์แก้โค้ดที่มันวิจารณ์ไม่ได้; มันแนบวิธีแก้ไขที่แนะนำซึ่งมนุษย์เป็นผู้ใช้ได้ ข้อความปฏิเสธของโหมดนี้บอกเอเจนต์ ที่พยายามลงมืออยู่ดีให้สรุปผลรีวิวและปล่อยให้ผู้ใช้ลงมือกับสรุปที่เผยแพร่แล้ว

แนวคิดที่เกี่ยวข้อง

• กฎคุม — เอนจินนโยบายที่กั้นการเผยแพร่
• โหมด — โหมด review เปลี่ยนอะไรให้เอเจนต์
• ไปป์ไลน์และระบบอัตโนมัติ — เอนจินที่รีวิวรันอยู่บนนั้น
• วงจรชีวิตการสั่งงานเอเจนต์ — worktree ที่แยกโดดมาจากไหน

คู่มือที่เกี่ยวข้อง

• ใช้รีวิวด้วย AI — รันรีวิวและเผยแพร่มัน
• สั่งงานเอเจนต์รีวิวเวอร์ — เลือกรีวิวเวอร์ด้วยตัวคุณเอง
• การคำนวณรีวิว — cohort แกน และ diff