مهارت بازبینی Copilot سیاست تیم است، نه ایرادگیری قشنگ‌تر

نظر عمومی مدل روی diff بیشتر وقت‌ها تکمیل خودکار گران است. «خطا را هندل کن.» «این تابع بلند است.» «لبه را در نظر گرفتی؟» بازبین انسانی یاد می‌گیرد نخ را بی‌صدا ببندد. جایی که مهارت بازبینی Copilot ارزش دارد این است که می‌تواند قانون نوشته‌شده تیم و زمینه بیرونی را بار کند، نه اینکه از روی diff حدس بزند.

این کار محصول را از «هوش مصنوعی که ایراد می‌گیرد» به «هوش مصنوعی که سیاست مکتوب را اعمال می‌کند» نزدیک می‌کند. خوب یا بد بودنش تقریباً فقط به متن مهارت و چیزی که از MCP وصل می‌کنی برمی‌گردد. مدل مقصر طراحی بد سیاست نیست.

مهارت چیزی را می‌گوید که CODEOWNERS با regex نمی‌تواند

فایل `SKILL.md` را زیر `.github/skills/<name>/` بگذار. وقتی بازبین مرتبط ببیند، همان مهارت را وارد بررسی می‌کند. نام پوشه و توضیح کوتاه برای انتخاب مهم‌اند، چون مدل باید بفهمد این مهارت کی به درد می‌خورد و کی باید ساکت بماند.

شاخه head درخواست ادغام منبع حقیقت است. می‌توانی مهارت را در همان PR اصلاح کنی و همان PR با نسخه اصلاح‌شده بازبینی شود. این برعکس بیشتر تنظیم lint در CI است که فقط به چیزی اهمیت می‌دهد که از قبل روی شاخه پایه نشسته. برای سیاست، این تفاوت عملی است: قانون را کنار خلافش می‌بینی، نه یک انتشار بعد.

از مهارت برای قانونی استفاده کن که واقعی، مشخص، و بارها شکسته شده:

- تغییر احراز هویت نباید راز سمت کلاینت بیاورد.

- مسیر API تازه بدون میان‌افزار محدودیت نرخ نیاید، مگر معافیت صریح در همان PR.

- در Payload هر عملیات مجموعه باید کنترل دسترسی داشته باشد، نه فقط `read`.

- مهاجرت باید دست‌کم یک انتشار با نسخه قبلی سازگار بماند.

- در نقطه ورود پکیج عمومی `any` اضافه نکن.

مهارت بد شبیه راهنمای سبک است: پنجاه سلیقه، بدون اولویت، بدون مثال diff خوب و بد. مدل نظر می‌پاشد. انسان نادیده می‌گیرد. هفته بعد کسی می‌گوید «Copilot به درد بازبینی نمی‌خورد». مشکل مدل نبود. مشکل سندی بود که نمی‌شد به آن عمل کرد.

مهارت بازبینی را مثل قاعده linter با بدنه نثر بنویس. تا جایی که می‌شود یک نگرانی در هر مهارت. یک مثال شکست مشخص. یک جمله «روی این‌ها نظر نده» تا فایل قالب، تغییر نام متغیر، و قالب‌بندی را شکار نکند. اگر دو نگرانی در یک فایل قاطی شوند، نمی‌توانی بگویی کدام شلیک کرده و کدام را باید حذف کنی.

MCP زمینه می‌دهد و سطح حمله را هم بزرگ می‌کند

MCP در بازبینی کد بنا به طراحی فقط‌خواندنی است و همین پیش‌فرض درست است. بازبینی‌کننده‌ای که بتواند در ردیاب مسئله بنویسد، بازبینی‌کننده‌ای است که توضیح مخرب PR می‌تواند هدایتش کند. پلتفرم هنوز اجازه می‌دهد فهرست ابزار را پهن کنی. این کار را نکن.

فقط ابزاری را که لازم داری در allowlist بگذار. توکن را زیر راز ایجنت نگه دار، نه داخل فایل مهارت و نه داخل توضیح PR. سروری را ترجیح بده که یک سند با دامنه تنگ برمی‌گرداند، نه «هر چه حساب سرویس می‌بیند».

MCP مفید برای بازبینی سه کار مشخص است. مسئله یا RFC لینک‌شده را بیاورد تا نظر با معیار پذیرش واقعی بخواند، نه با عنوان کارت. وقتی PR یک سیستم نام‌دار را لمس می‌کند، ورودی کاتالوگ همان سرویس را بردارد. قرارداد API داخلی یا تکه OpenAPI را بخواند که خود PR به آن اشاره کرده.

کم‌فایده و پرریسک‌تر است: جستجوی پهن ویکی که ران‌بوک کهنه را مثل وحی برمی‌گرداند. سروری که داده مشتری، دفتر صورتحساب، یا لاگ پروداکشن را وارد بازبینی PR می‌کند. و `"tools": ["*"]` چون راه‌اندازی جمعه اعصاب‌خردکن بود.

اگر MCP از قبل برای ایجنت ابری Copilot تنظیم شده، مگر خاموشش کنی روی بازبینی هم اعمال می‌شود. پیکربندی مشترک را حسابرسی کن. راحتی ایجنتی که یک نفر در یک ریپو صدا می‌زند، همان مدل تهدید بازبین همیشه‌روشنی نیست که هر diff را می‌خواند. دومی سطح پایدار است. اجازه ابزارش باید جدا و کوچک‌تر باشد.

انتساب، دیباگ سیاست است

نظر باید نشان دهد از مهارت آمده یا از زمینه MCP. از همین استفاده کن. وقتی نظر غلط است بپرس کدام مهارت شلیک کرده، بعد همان فایل را اصلاح یا حذف کن. وقتی درست است همان مهارت را نگه دار و وسوسه اضافه کردن پنج پاراگراف «این را هم چک کن» را کنار بگذار. هر پاراگراف اضافه، سطح نویز مهارت‌های دیگر را هم بالا می‌برد چون مدل زمینه شلوغ‌تری برای انتخاب دارد.

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

مالکیت به اندازه متن مهم است. روی `.github/skills/` ورودی `CODEOWNERS` بگذار تا تغییر سیاست همان بازبینی میان‌افزار امنیتی را بگیرد. مهارتی که کسی مالکش نیست سریع‌تر از README کهنه به توصیه متناقض می‌پوسد. دو مهارت که یکی «همیشه rate limit» می‌گوید و دیگری «مسیر داخلی معاف است» بدون صاحب، بدتر از نبود بازبین ماشینی است.

قاعده پذیرش

یک مهارت منتشر کن که یک کلاس حادثه تکراری را بگیرد. مدتی ببین انسان نخ را به‌عنوان درست‌شده می‌بندد یا به‌عنوان نویز رد می‌کند. تا این را ندیده‌ای MCP اضافه نکن و مهارت دوم ننویس. مهارت، سیاست به‌صورت کد است. سیاستی که روی هر PR بدون مالک شلیک کند نویز محیط می‌شود. نویز محیط همان راهی است که تیم ایجنت بازبینی را دوباره به هزینه CI تبدیل می‌کند، فقط با لحن بدتر.

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

پرسش‌های کوتاه

**مهارت را جایگزین ESLint کنم؟** نه. چیزی که ماشین قطعی می‌تواند رد کند باید lint، تایپ، یا تست بماند. مهارت برای قضاوتی است که regex درنمی‌آورد و هنوز بارها شکسته می‌شود.

**چند مهارت در هفته اول؟** یکی. دومی را بعد از اینکه دیدی نظرها خوانده می‌شوند اضافه کن.

**توکن سرویس را داخل SKILL.md بگذارم؟** نه. راز جای مهارت نیست. مهارت را هر کسی که PR را ببیند ممکن است بخواند.