یکی از دام‌های رایج در استفاده از مدل‌های زبانی برای تولید کد، اتکای کامل به خودبازبینی (Self-Review) یا آزمون‌های واحد خودکار است. مدل ممکن است تستها را پاس کند و گیت اعتبارسنجی را پشت سر بگذارد، اما در عمل راه‌حلی نامربوط ارائه داده باشد یا دامنه‌ی تغییرات را بی‌دلیل گسترش دهد. ایجنتی که کد را نوشته، دچار سوگیری تایید می‌شود و نمی‌تواند داور مطمئنی برای کار خودش باشد.
در این درس یاد می‌گیرید که چطور با تفکیک نقش سازنده (Builder) از بازبین (Reviewer)، یک حلقه‌ی نظارتی مستقل ایجاد کنید. بازبین با دسترسی فقطخواندنی، تغییرات را بر اساس یک شیوه‌نامه‌ی دقیق پنج‌بعدی می‌سنجد تا ارزیابی کیفی پیش از رسیدن کد به مرحله‌ی بررسی انسانی تکمیل شود.
ایجنتی که کد را نوشته، نمی‌تواند به آن نمره بدهد. بازبین (reviewer) حلقه‌ی دومی است با پرامپت سیستمی متفاوت، هدفی متفاوت، و دسترسی فقطخواندنی به تمام خروجی‌های ایجنت سازنده (builder). بخش عمده‌ی قابلیت اطمینان، دقیقاً در همین فاصله‌ی میان سازنده و بازبین شکل می‌گیرد.
اهداف یادگیری
- توضیح دهید چرا یک ایجنت واحد نمی‌تواند کارهای خودش را با اطمینان بازبینی کند.
- یک حلقه‌ی ایجنت (agent loop) بازبین بسازید که دست‌سازه‌های سازنده را دریافت کند و گزارشی ساختاریافته از بازبینی تحویل دهد.
- یک شیوه‌نامه‌ی نمره‌دهی (rubric) برای بازبین بنویسید که ابعاد مشخصی را بسنجد، نه حس‌وحال کلی را.
- بازبین را به میز کار (workbench) متصل کنید تا مرحله‌ی بازبینی انسانی از یک دست‌سازه‌ی واقعی شروع شود.
صورت‌مسئله
از ایجنت می‌خواهید باگی را برطرف کند. چهار فایل را ویرایش میکند، تستها را اجرا میکند و می‌گوید کار تمام است. گیت اعتبارسنجی (فصل 14 · 38) تأیید میکند که معیارهای پذیرش اجرا شده‌اند و دامنه (scope) رعایت شده است. گیت خروجی passed: true می‌دهد. تغییرات را merge می‌کنید. دو روز بعد متوجه می‌شوید که این راهحل، نیمه‌ی اشتباه باگ را حل کرده است.
پذیرش شرط لازم است، اما کافی نیست. بازبین سؤالاتی را می‌پرسد که فرایند پذیرش توان پرسیدنش را ندارد: آیا مسئله‌ی درست حل شد؟ آیا بدون اعلام قبلی، دامنه گسترش پیدا کرد؟ آیا فرضیاتی پنهان مانده‌اند که باید زیر سؤال می‌رفتند؟ آیا وضعیت میز کار طوری رها شده که نشست بعدی بتواند کار را به راحتی ادامه دهد؟
مفاهیم پایه
شیوه‌نامه‌ی نمره‌دهی بازبین
پنج بعد، هر کدام با امتیازی بین 0 تا 2:
| بعد | پرسش |
|---|---|
| تطابق با مسئله (Problem fit) | آیا تغییرات اعمال‌شده دقیقاً همان وظیفه‌ی خواسته‌شده را حل کرد، نه وظیفه‌ای مشابه در همان حوالی را؟ |
| انضباط در دامنه (Scope discipline) | آیا ویرایش‌ها به قرارداد اولیه محدود ماندند یا دامنه عامدانه گسترش یافت؟ |
| فرضیات (Assumptions) | آیا تمام فرضیات پنهان، در جایی قابل‌بررسی مستند شده‌اند؟ |
| کیفیت اعتبارسنجی (Verification quality) | آیا دستور پذیرش واقعاً دستیابی به هدف را اثبات میکند، یا فقط نسخه‌ی ضعیف‌تری از آن را نشان می‌دهد؟ |
| آمادگی برای تحویل (Handoff readiness) | آیا نشست بعدی می‌تواند از وضعیت فعلی کار را بدون دردسر پیش ببرد؟ |
مجموع نمرات از 10 است. نمره‌ی زیر 7 رد مشروط (soft fail) به حساب می‌آید؛ نمره‌ی زیر 5 یا گرفتن امتیاز 0 در هر کدام از ابعاد، رد قطعی (hard fail) است.
بازبین یک نقش مجزاست، نه لزوماً مدلی مجزا
می‌توانید بازبین را با همان مدل سازنده اجرا کنید. اصل کار، تفکیک نقش‌هاست: پرامپت سیستمی متفاوت، ورودیهای متفاوت، و نداشتن دسترسی نوشتن به تغییرات (diff). تغییر موضع مدل است که سیگنال خروجی را دگرگون میکند.
بازبین نمی‌تواند diff را ویرایش کند
بازبین فقط diff، وضعیت، بازخورد و نتیجه‌ی نهایی را می‌خواند؛ سپس گزارش می‌نویسد. بازبین به هیچ وجه روی diff تکه (patch) اعمال نمی‌کند. اگر گزارش بگوید «این بخش باید اصلاح شود»، نوبت بعدی سازنده کار اصلاح را انجام می‌دهد و بازبین دوباره به نقش نظارتی خود برمی‌گردد. ترکیب این دو نقش، فاصله‌ی اعتبارسنجی را از بین می‌برد.
مقایسه‌ی شیوه‌نامه‌ی نمره‌دهی بازبین و گیت اعتبارسنجی
گیت اعتبارسنجی (فصل 14 · 38) فکتهای قطعی را بررسی میکند: آیا فرایند پذیرش اجرا شد؟ آیا قواعد رعایت شدند؟ آیا دامنه حفظ شد؟ در مقابل، بازبین قضاوتهای کیفی انجام می‌دهد: آیا این کار درست بود؟ آیا مستندسازی شده؟ آیا خروجی برای تحویل به نفر بعدی قابل استفاده است؟ وجود هر دو الزامی است.
پیاده‌سازی از صفر
کد code/main.py این بخش‌ها را پیاده‌سازی میکند:
- دیتاکلاس
ReviewerInputsبرای بسته‌بندی دست‌سازه‌هایی که بازبین مطالعه میکند. - یک سیستم نمره‌دهی بر اساس شیوه‌نامه با تابعی اختصاصی برای هر بعد. هر تابع به صورت قطعی و در حد استاب برای آموزش طراحی شده؛ در دنیای واقعی این توابع یک LLM را فراخوانی می‌کنند.
- ثبت‌کننده‌ی
review_report.jsonکه پنج امتیاز، مجموع نمرات و نتیجه‌ی نهایی (pass،soft_fail،hard_fail) را ذخیره میکند. - دو نمونه برای دمو: یک تغییر بی‌نقص و تمیز، و یک تغییر از نوع «تست‌های درست، مسئله‌ی غلط».
اجرای برنامه:
python3 code/main.pyخروجی: دو گزارش بازبینی ذخیره‌شده روی دیسک به همراه جدولی در کنسول که نمرات هر بعد را نمایش می‌دهد.
الگوهای محیط عملیاتی در دنیای واقعی
شواهد عینی: سیستم بازبینی کد مبتنی بر هوش مصنوعی Cloudflare در آوریل 2026، در طول 30 روز 131,246 بازبینی را روی 48,095 درخواست merge در 5,169 مخزن اجرا کرد. میانه‌ی زمان بازبینی 3 دقیقه و 39 ثانیه بود. تا هفت بازبین متخصص (امنیت، عملکرد، کیفیت کد، مستندات، مدیریت انتشار، انطباق با قوانین، استانداردهای مهندسی) به‌صورت موازی زیر نظر یک هماهنگ‌کننده‌ی بازبینی (Review Coordinator) اجرا می‌شدند؛ این هماهنگ‌کننده یافته‌های تکراری را حذف و سطح اهمیت را تعیین می‌کرد. مدل‌های رده‌بالا منحصراً به هماهنگ‌کننده اختصاص داشتند و متخصصان روی مدل‌های ارزان‌تر اجرا می‌شدند.
چهار الگو پیاده‌سازی این رویکرد را در مقیاس بزرگ ممکن می‌کنند:
مجموعه‌ای از متخصصان، نه یک بازبین همه‌کاره. یک بازبین با شیوه‌نامه‌ی 5بعدی برای مخازن تک‌نفره کافی است. وقتی کدبیس بخش‌های حساس به امنیت، عملکرد و مستندات پیدا کرد، کار را بین متخصصانی با پرامپت‌های کوچک‌تر تقسیم کنید. هماهنگ‌کننده موارد تکراری را حذف میکند؛ متخصصان هیچ‌وقت کل شیوه‌نامه را اجرا نمی‌کنند. تفکیک سطح مدل‌ها هم طبیعی حاصل می‌شود: متخصصان ارزان، هماهنگ‌کننده‌ی گران‌قیمت.
کاهش سوگیری به‌منزله‌ی پیش‌نیاز طراحی، نه بهینه‌سازی ثانویه. مدل‌های داور چهار سوگیری ثابت نشان می‌دهند (عدنان مسعود، آوریل 2026): سوگیری موقعیت (GPT-4 در ترتیب (A,B) در مقایسه با (B,A) حدود 40% ناسازگاری دارد)، سوگیری پرحرفی (حدود 15% نمره‌ی بالاتر به پاسخ‌های طولانی‌تر)، سوگیری خودی (ترجیح خروجی‌های مدل‌های هم‌خانواده)، سوگیری مرجعیت (نمره‌ی بیش‌ازحد به ارجاعاتی با نام نویسندگان مشهور). راه‌حل‌ها: ارزیابی هر دو ترتیب و احتساب برد فقط در صورت پیروزی در هر دو حالت؛ استفاده از مقیاس 1 تا 4 که صراحتاً به ایجاز پاداش می‌دهد؛ چرخش داوران بین خانواده‌های مختلف مدل‌ها؛ حذف نام نویسندگان قبل از نمره‌دهی.
مجموعه‌ی کالیبراسیون، نه ارزیابی حسی. مجموعه‌ای شامل 10 تا 20 وظیفه‌ی گذشته با نتایج قطعی و درست. با هر تغییر پرامپت، بازبین را روی آن اجرا کنید. اگر هم‌پوشانی با داده‌های تاریخی زیر 80% آمد، شیوه‌نامه پیش از انتشار بازبین باید بازنگری شود. همه‌ی تیم‌ها در نهایت به همین نتیجه می‌رسند؛ بهتر است از اول با آن شروع کنید.
رویکرد ترکیبی با گیت اعتبارسنجی. گیت اعتبارسنجی (فصل 14 · 38) بررسی‌های قطعی را بر عهده می‌گیرد (آیا فرایند پذیرش اجرا شد، آیا تستها پاس شدند، آیا دامنه حفظ شد). بازبین به سراغ بررسی‌های معنایی می‌رود (آیا کار درستی بود، آیا فرضیات ثبت شده‌اند، آیا تحویل کار قابل استفاده است). راهنمای سال 2026 شرکت Anthropic صراحتاً بر این تفکیک تأکید دارد: کاری را که گیت قبلاً اثبات کرده دوباره به بازبین نسپارید.
استفاده از ابزارهای واقعی
الگوهای عملیاتی:
- ساب‌ایجنت‌های Claude Code: یک ساب‌ایجنت بازبین بعد از بسته‌شدن تسک توسط سازنده اجرا می‌شود و نمرات شیوه‌نامه را در قالب کامنت روی PR ثبت میکند.
- تحویل تسک‌ها (handoffs) در OpenAI Agents SDK: سازنده پس از اتمام کار، وظیفه را به بازبین تحویل می‌دهد. بازبین می‌تواند کار را با فهرستی از یافته‌ها بازگرداند یا آن را به انسان ارجاع دهد.
- جفت‌کردن دو مدل: سازنده با مدلی سریع‌تر و ارزان‌تر کار میکند؛ بازبین روی مدلی قدرتمندتر با زمینه‌ی متنی (context) کوچک‌تر اجرا می‌شود و تمرکزش فقط روی قضاوت است.
بازبین همان جفت چشم دومی است که وقتی انسان‌ها نمی‌توانند همه‌ی بازبینی‌ها را شخصاً انجام دهند، به میز کار اضافه می‌شود.
خروجی این درس
فایل outputs/skill-reviewer-agent.md یک شیوه‌نامه‌ی نمره‌دهی اختصاصی پروژه، اسکلت اولیه‌ی ایجنت بازبین متصل به دست‌سازه‌های سازنده، و یکپارچه‌سازی با گیت اعتبارسنجی را تولید میکند؛ تا بازبینی انسانی به‌جای صفحه‌ای خالی، از گزارشی مکتوب آغاز شود.
تمرین‌ها
- بعد ششمی مختص حوزه‌ی کاری محصول خود اضافه کنید. دفاع کنید که چرا این بعد در پنج مورد فعلی پوشش داده نشده است.
- بازبین را با دو پرامپت سیستمی مختلف (موجز، مفصل) اجرا کنید. کدام‌یک گزارشی تولید میکند که انسان تمایل بیشتری به خواندنش داشته باشد؟
- به هر بعد یک فیلد
confidenceاضافه کنید. اگر اطمینان در پایین‌ترین بعد کمتر از 0.6 بود، از صدور گزارش خودداری کنید. - یک مجموعه‌ی کالیبراسیون بسازید: پرونده‌ی 10 وظیفه‌ی پیشین با نتایج قطعی مشخص. بازبین را روی آن‌ها اجرا کنید. کجاها با خروجی‌های واقعی گذشته مغایرت دارد؟
- قابلیتی برای «درخواست شواهد بیشتر» اضافه کنید؛ طوری که بازبین بتواند قبل از نمره‌دهی، از سازنده اجرای یک تست خاص را بخواهد. چطور باید عقب‌نشینی تدریجی (back-off) تعریف کرد تا سیستم دچار حلقه‌ی بی‌پایان نشود؟
اصطلاحات کلیدی
| اصطلاح | در گفت‌وگوهای عامیانه | معنای دقیق فنی |
|---|---|---|
| شیوه‌نامه‌ی نمره‌دهی بازبین (Reviewer rubric) | «چک‌لیست» | نمره‌دهی 0 تا 2 در پنج بعد با سؤالی مکتوب برای هر بعد |
| رد مشروط (Soft fail) | «نیاز به بازنگری دارد» | مجموع نمرات کمتر از 7؛ یافته‌ها برای اصلاح به سازنده تحویل داده می‌شود |
| رد قطعی (Hard fail) | «رد کامل» | مجموع نمرات کمتر از 5 یا نمره‌ی 0 در هر بعد؛ توقف فرایند و ارجاع به انسان |
| تفکیک نقشها (Role separation) | «یک پرامپت دیگر» | یک مدل می‌تواند در هر دو نقش عمل کند؛ اصل موضوع، انضباط در ورودی‌ها و موضع ارزیابی است |
| کف اطمینان (Confidence floor) | «گزارش‌های با سیگنال ضعیف را منتشر نکنید» | خودداری از صدور رأی قطعی وقتی شیوه‌نامه قطعیت کافی ندارد |
برای مطالعه‌ی بیشتر
- OpenAI Agents SDK handoffs
- Anthropic Claude Code subagents
- Cloudflare, Orchestrating AI Code Review at Scale — معماری هماهنگ‌کننده به همراه 7 متخصص، 131 هزار بازبینی در 30 روز
- Agent-as-a-Judge: Evaluating Agents with Agents (OpenReview / ICLR) — بنچ‌مارک DevAI، ارزیابی 366 نیازمندی سلسله‌مراتبی راهحل
- Adnan Masood, Rubric-Based Evaluations and LLM-as-a-Judge: Methodologies, Biases, Empirical Validation — معرفی 4 سوگیری و روش‌های کاهش آن‌ها
- MLflow, LLM-as-a-Judge Evaluation — ابزارهای محیط عملیاتی برای تفکیک سازنده و ارزیاب
- LangChain, How to Calibrate LLM-as-a-Judge with Human Corrections — جریان کاری استفاده از مجموعه‌ی کالیبراسیون
- Evidently AI, LLM-as-a-judge: a complete guide
- Arize, LLM as a Judge — Primer and Pre-Built Evaluators
- فصل 14 · 05 — تکنیک‌های Self-Refine و CRITIC (خط مبنای خودبازبینی تک‌ایجنتی)
- فصل 14 · 30 — توسعه‌ی ایجنت مبتنی بر ارزیابی (مولد مجموعه‌ی کالیبراسیون)
- فصل 14 · 38 — گیت اعتبارسنجی که بازبین از آن می‌خواند
- فصل 14 · 40 — بسته‌ی تحویل که با گزارش بازبین تغذیه می‌شود