استفاده از بازبینی مبتنی بر هوش مصنوعی

این راهنما نشان می‌دهد چگونه عامل‌های بازبین را وادار کنید یک pull request را بازبینی کنند و چگونه نتیجه را در GitHub منتشر کنید.

شروع یک بازبینی هوش مصنوعی

PR را باز کنید و به زبانهٔ نمای کلی آن بروید
منوی سرریز ⋯ را در ردیف کنش‌ها باز کنید و پرسش از AI را انتخاب کنید

این گزینه تنها تا وقتی PR باز است نمایان می‌شود — کنشی پیش از ادغام است. همان دکمه در وضعیت خالی زبانهٔ بازبینی، پیش از آنکه هیچ بازبینی‌ای وجود داشته باشد، با نام پرسش از AI ارائه می‌شود.

Control Center پایپ‌لاین از پیش تعریف‌شدهٔ pr_review را شروع می‌کند و زبانهٔ بازبینی PR را باز می‌کند تا بتوانید تماشایش کنید. این پایپ‌لاین:

فضای بازبینی خود PR را باز می‌کند؛ worktree جداشدهٔ آن، PR را روی head خودش checkout کرده دارد
بازبین‌ها را بر اساس سطح بازبینی فضای کاری پخش می‌کند — به‌طور پیش‌فرض سه مورد (عامل‌های از پیش تعریف‌شدهٔ qa، architect و engineer، به‌صورت موازی). هیچ تشخیص زبان یا دامنه‌ای وجود ندارد
عامل راهبر (CEO) را وادار می‌کند یافته‌هایشان را در قالب یک مرور گام‌به‌گام یکپارچه کند
نهایی‌سازی می‌کند: یافته‌ها را در گروه‌های اجماع مرتب می‌کند و حکم را محاسبه می‌کند. وقتی این پیوند به awaiting approval می‌رسد، انتشار در GitHub در زبانهٔ بازبینی نمایان می‌شود

اینکه بازبینی تا چه عمقی می‌رود، سطح بازبینی فضای کاری است — light (یک بازبین)، balanced (سه مورد، پیش‌فرض) یا thorough (هر پنج مورد، با افزودن متخصصان امنیت و عملکرد) — که در تنظیمات → فضای کاری → عمومی، روی کارت سیاست فضای کاری تنظیم می‌شود. سطح سبک‌تر دقیقاً همان تعداد یافته را ثبت می‌کند؛ فقط تعداد کمتری از آن‌ها را در صدر گزارش می‌دهد.

همهٔ بازبین‌ها در تنها فضای بازبینی PR می‌نویسند و همین است که یافته‌هایشان را قابل مقایسه می‌کند. برای اینکه ببینید اجزا چگونه کنار هم می‌نشینند، بازبینی هوش مصنوعی را ببینید.

pr_review تنها با یک تریگر دستی ارائه می‌شود. برای اینکه روی هر PR منتشرشده اجرا شود، خودتان یک تریگر اضافه کنید — اعزام عامل‌های بازبین را ببینید. همچنین می‌توانید آن را از خود GitHub شروع کنید، بدون نیاز به تریگر پایپ‌لاین: ربات سرور را در PR منشن کنید یا برچسب ai-review را اضافه کنید — گفتگو با Control Center از یک pull request در GitHub را ببینید.

اگر یک اعلان بگوید بازبینی‌ای از قبل برای این pull request در حال اجراست، یعنی یکی در جریان است؛ در زبانهٔ بازبینی بمانید یا پایپ‌لاین‌ها را باز کنید تا پیدایش کنید.

خواندن یافته‌ها

بازبین‌ها یافته‌ها را به‌صورت گره‌های بازبینی در فضای بازبینی ثبت می‌کنند. هرکدام این‌ها را همراه دارد:

فیلد	توضیح
نوع	`bug`، `suggestion`، `recommendation`، `question` یا `ticket`
اولویت	P0 (بحرانی) → P3 (جزئی)
دسته	`security`، `stability`، `data_integrity`، `correctness`، `performance` یا `maintainability`
فایل و خط	جایی که یافته لنگر انداخته است
کد اصلی	کدی که یافته دربارهٔ آن است
کد پیشنهادی	اصلاح پیشنهادی
اطمینان	میزان اطمینان بازبین
وضعیت	`open` → `consensus-ready` → `resolved` یا `dismissed`

یک یافته تنها زمانی به consensus-ready می‌رسد که یک بازبین همتا تأییدش کند. یک عامل نمی‌تواند یافتهٔ خودش را تأیید کند، بنابراین نظر یک بازبین تنها هرگز به‌خودی‌خود ارتقا نمی‌یابد.

زبانهٔ بازبینی فهرست یافته‌ها را نشان می‌دهد که بر اساس نوع و وضعیت فیلترپذیر است و کلید چرخشی‌ای برای یافته‌های ردشده دارد، در کنار آرتیفکتی که عامل یکپارچه‌ساز منتشر کرده است. نمای قطعی — گروه‌ها، داشبورد چندمحوره، و دیف‌های قرارداد و بصری — سمت سرور محاسبه می‌شود اما هیچ سطحی در اپ ندارد؛ برای اینکه ببینید این گذر چه چیزی تولید می‌کند، محاسبهٔ بازبینی را ببینید.

بررسی پنل اختلاف‌ها

وقتی دو بازبین یافته‌ها را به یک فایل و خط یکسان لنگر می‌اندازند اما آن‌ها را بسیار متفاوت ارزیابی می‌کنند — اولویت‌هایی با فاصلهٔ دو سطح یا بیشتر، یا اینکه یکی آن را bug می‌نامد و دیگری suggestion — یک پنل اختلاف بالای فهرست یافته‌ها نمایان می‌شود. این‌ها را اول بخوانید: همان‌جاست که نظر بازبین‌ها واگرا می‌شود و قضاوت شما بیشترین ارزش را دارد.

خواندن حکم

وقتی عامل راهبر نهایی‌سازی می‌کند، یک حکم محاسبه می‌کند:

حکم	معنا
Ship	هیچ چیز بازدارنده‌ای یافت نشد
Hold	مسائلی که باید پیش از ادغام بررسی شوند
Block	مسائل بحرانی‌ای که باید برطرف شوند

حکم یک امتیاز اطمینان تجمعی و شمار یافته‌ها به‌ازای هر اولویت را همراه دارد.

سپس محورهای بازبینی در آن وارد می‌شوند و فقط می‌توانند آن را سخت‌تر کنند. یک محور دروازه‌بانی‌شده که مردود شود، Block را تحمیل می‌کند؛ محور دروازه‌بانی‌شده‌ای که نتواند کامل شود (partial) یا اصلاً نتواند اجرا شود (unavailable)، حداقل Hold را تحمیل می‌کند. نبود شواهد هرگز یک دروازه را باز نمی‌کند.

انتشار بازبینی در GitHub

انتشار گامی جداگانه و آگاهانه دروازه‌بانی‌شده به دست کاربر است. پایپ‌لاین pr_review بازبینی را در Control Center نگه می‌دارد؛ به GitHub ارسال نمی‌کند.

در زبانهٔ بازبینی، صبر کنید تا انتشار در GitHub نمایان شود
انتشار در GitHub را فشار دهید

Control Center یک بازبینی GitHub می‌فرستد. یافته‌هایی که پیش‌تر رفع یا رد شده‌اند نادیده گرفته می‌شوند. این دکمه هر یافتهٔ باز باقی‌مانده را شامل می‌شود و در حالت Ship، APPROVE ثبت می‌کند. (ابزار MCP publish_review_to_github همچنان به‌طور پیش‌فرض فقط یافته‌های تأییدشدهٔ همتا را می‌فرستد و تا وقتی approve_on_ship را نفرستید، تأیید نمی‌کند.) آن‌هایی که لنگر فایل و خط دارند به نظرهای درون‌خطی تبدیل می‌شوند؛ هر چیز دیگری در بدنهٔ خلاصه گنجانده می‌شود و هرکدام یک پایین‌بند “— Control Center AI review” همراه دارد تا منبع بی‌ابهام باشد. حکم Block به‌صورت REQUEST_CHANGES ثبت می‌شود؛ Hold به‌صورت COMMENT؛ Ship از طریق این دکمه به‌صورت APPROVE. سپس یک اعلان منتشرشده را نشان می‌دهد. بازبینی تحت هویت برنامهٔ سرور ارسال می‌شود.

اگر GitHub یک لنگر درون‌خطی را رد کند چون آن خط بخشی از دیف نیست، کل بازبینی دوباره فرستاده می‌شود و هر یافته در بدنه گنجانده می‌شود، تا چیزی بی‌سروصدا از قلم نیفتد.

پایپ‌لاین‌های توکار دیگر مستقیماً به GitHub ارسال می‌کنند: cross_review، pr_triage، ticket_to_pr و pre_merge_gate هرکدام با یک گام نظرپردازی پایان می‌یابند. تنها pr_review خروجی‌اش را برای شما نگه می‌دارد.

خودتان بازبین‌ها را اعزام کنید

برای کنترل اینکه کدام نقش‌ها PR را بازبینی کنند و هرکدام به چه فایل‌هایی نگاه کنند، از ابزار MCP dispatch_reviewers درون یک فضای بازبینی موجود استفاده کنید، یا گره‌های بازبین را به یک پایپ‌لاین اضافه کنید. هر دو مسیر، همراه با امضای دقیق ابزار، در اعزام عامل‌های بازبین آمده است.