ابزار مرورگر GitHub Copilot در VS Code چیست؟ راهنمای تست و دیباگ واقعی

Copilot دیگر فقط کد پروژه را نمی خواند؛ حالا می تواند صفحه واقعی را داخل VS Code باز کند، روی عناصر کلیک کند، فرم پر کند، خطاهای Console را ببیند، Screenshot بگیرد و حتی Playwright اجرا کند. این تغییر فاصله میان «تولید کد» و «دیدن نتیجه واقعی» را کم می کند. برای توسعه دهنده وب، مهم ترین پیام این است: Agent می تواند تغییر را در رابط اجراشده بررسی کند، نه اینکه فقط از روی فایل ها حدس بزند همه چیز درست است.

Browser Tools دقیقاً چیست و چه مشکلی را حل می کند؟

GitHub در 1 ژوئیه 2026 اعلام کرد ابزارهای مرورگر Copilot در VS Code به صورت عمومی در دسترس قرار گرفته اند. این ابزارها روی Integrated Browser خود VS Code کار می کنند و به Agent اجازه می دهند یک وب اپلیکیشن زنده را ببیند و با آن تعامل کند. قبل از این قابلیت، مدل معمولاً سورس، خطا یا Screenshotی را می دید که کاربر دستی ارسال کرده بود. اکنون می تواند بخشی از فرایند مشاهده و آزمایش را خودش انجام دهد.

مشکل اصلی توسعه وب این است که صحیح بودن کد الزاماً به معنای صحیح بودن محصول نیست. یک کامپوننت ممکن است TypeScript سالم داشته باشد، اما در اندازه موبایل از صفحه بیرون بزند. API ممکن است پاسخ 200 بدهد، اما UI وضعیت Loading را نبندد. CSS ممکن است در فایل منطقی به نظر برسد، اما محتوا زیر Navbar قرار بگیرد. Browser Tools حلقه بازخورد را کامل تر می کند: Agent تغییر را می سازد، برنامه را باز می کند، رفتار را می بیند و براساس نتیجه تصمیم می گیرد.

Agent دقیقاً چه کارهایی در مرورگر انجام می دهد؟

مستندات رسمی VS Code فهرست گسترده ای از ابزارها را ارائه می کند. Agent می تواند صفحه جدید باز کند، به URL برود، محتوای صفحه را بخواند، عناصر را انتخاب کند، متن تایپ کند، Hover و Drag انجام دهد، Dialogها را مدیریت کند، Screenshot بگیرد، خطاهای Console را بخواند و کد Playwright اجرا کند. این مجموعه برای بررسی جریان های چندمرحله ای کافی است؛ از ورود کاربر تا ثبت فرم و مشاهده پیام نهایی.

چرا خواندن Console مهم است؟

بسیاری از خطاهای UI روی صفحه فقط با یک نتیجه مبهم دیده می شوند؛ مثلاً دکمه هیچ کاری نمی کند. Console می تواند نشان دهد Handler خطا داده، پاسخ API شکل دیگری داشته یا یک متغیر Null بوده است. وقتی Agent هم کد و هم Console را می بیند، می تواند میان علامت ظاهری و علت فنی ارتباط برقرار کند. این اتصال، احتمال اصلاح حدسی را کاهش می دهد.

چرا Screenshot به تنهایی کافی نیست؟

Screenshot ظاهر یک لحظه را نشان می دهد، اما State و رفتار را توضیح نمی دهد. Agent باید بداند قبل از تصویر چه کلیکی انجام شده، کدام درخواست شبکه برگشته و Console چه پیامی داده است. Browser Tools این زمینه را کنار هم قرار می دهد. بهترین نتیجه زمانی به دست می آید که Screenshot، DOM، Console و هدف کاربر هم زمان بررسی شوند.

تفاوت Add to Chat با Browser Tools چیست؟

Integrated Browser دو نوع ارتباط با هوش مصنوعی دارد. در حالت Add to Chat، توسعه دهنده دستی یک عنصر، Screenshot یا Console Log را انتخاب و به Prompt اضافه می کند. کنترل کامل دست کاربر است و Agent فقط زمینه انتخاب شده را می بیند. این روش برای سؤال نقطه ای و حساس مناسب است.

در Browser Tools، Agent به صورت خودکار در Tabهای Session خودش حرکت می کند و برای رسیدن به هدف چند اقدام انجام می دهد. مثلاً صفحه را باز می کند، فرم را پر می کند، پیام را می خواند و بعد به کد برمی گردد. این روش برای وظیفه کامل ارزشمندتر است، اما به مرزبندی دقیق تر نیاز دارد. توسعه دهنده باید URL مجاز، حساب تست، داده آزمایشی و معیار پایان کار را مشخص کند.

یک جریان واقعی از پیدا کردن باگ تا اصلاح چگونه است؟

فرض کنید صفحه ثبت محصول در حالت موبایل مشکل دارد. Dropzone فایل را می پذیرد، اما Thumbnail نمایش داده نمی شود و دکمه ثبت زیر Navbar می رود. درخواست خوب نباید فقط بگوید «UI را درست کن». باید Agent را وادار کند رفتار فعلی را بازتولید کند، الگوی صفحات سالم پروژه را پیدا کند و کوچک ترین تغییر سازگار را اعمال کند.

این رویکرد از دو خطای رایج جلوگیری می کند. نخست، Agent به جای فهم الگوی پروژه، یک راهکار عمومی و CSS اضافی نمی سازد. دوم، اصلاح فقط براساس خواندن کد پذیرفته نمی شود؛ باید در صفحه واقعی نتیجه بدهد. Browser Tools دقیقاً برای ساخت چنین حلقه ای مفید است.

Playwright چه نقشی در Browser Tools دارد؟

Playwright یک ابزار خودکارسازی مرورگر است. Agent می تواند از آن برای اجرای سناریوهای دقیق تر استفاده کند؛ مانند یافتن عنصر براساس Role، واردکردن مقدار، انتظار برای پاسخ و کنترل متن نهایی. مزیت Playwright نسبت به کلیک تصادفی این است که مراحل قابل تکرار می شوند. سناریویی که امروز برای بازتولید باگ ساخته می شود، می تواند بعداً به تست E2E تبدیل شود.

import { test, expect } from '@playwright/test';

test('shows uploaded image preview', async ({ page }) => {
  await page.goto('http://localhost:3000/products/create');
  await page.getByLabel('بارگذاری تصویر').setInputFiles('tests/assets/product.png');
  const preview = page.getByRole('img', { name: 'پیش نمایش تصویر' });
  await expect(preview).toBeVisible();
});

این تست سه کار روشن انجام می دهد: صفحه را باز می کند، یک فایل واقعی به ورودی می دهد و انتظار دارد تصویر پیش نمایش دیده شود. اگر Agent چنین تستی بسازد و پیش و پس از اصلاح اجرا کند، خروجی قابل اعتمادتر از جمله «به نظر می رسد درست شده» خواهد بود. نام Role و Label باید با Markup واقعی پروژه هماهنگ شود.

Integrated Browser فقط برای Agent نیست

خود مرورگر یکپارچه VS Code قابلیت های مفیدی برای توسعه دهنده دارد. می توانید URLهای http، https و file را باز کنید، Tab مدیریت کنید، DevTools داشته باشید و Debugger را با نوع editor-browser به Tab متصل کنید. همچنین لینک های localhost را مستقیماً داخل IDE باز می کند. این یکپارچگی باعث می شود Preview، Console، Debug و Chat در محیط واحد قرار بگیرند.

امکان Attach براساس urlFilter نیز برای پروژه هایی مفید است که چند Tab دارند. به جای انتخاب دستی، Debugger فقط Tab منطبق با آدرس مشخص را پیدا می کند. در پروژه های Frontend که هم زمان پنل مدیریت، سایت اصلی و Storybook اجرا می شوند، این تنظیم از اتصال اشتباه جلوگیری می کند.

امنیت، Permission و ایزوله سازی چگونه مدیریت می شود؟

مرورگر یکپارچه برای مجوزهایی مانند موقعیت مکانی، دوربین، میکروفون، Clipboard، Bluetooth، USB و Serial از مدل Permission برای هر سایت استفاده می کند. این یعنی صفحه نمی تواند بدون تأیید به منابع حساس دسترسی بگیرد. بااین حال، Agent می تواند در سطح Application اقدام انجام دهد؛ بنابراین حساب تست و داده آزمایشی باید از محیط واقعی جدا باشند.

هر Session در Agents Window مجموعه Tabهای مستقل خودش را دارد. Agent فقط Tabهای Session خودش را می بیند. اگر شما صفحه ای را دستی باز کرده باشید، برای دادن دسترسی باید گزینه Share with Agent را بزنید و تأیید کنید. این جداسازی مانع می شود Agent به صورت پیش فرض تمام Tabهای شخصی یا حساب های واردشده شما را بخواند.

کنترل سازمانی

Browser Tools با تنظیم workbench.browser.enableChatTools کنترل می شود و سازمان می تواند آن را مدیریت کند. VS Code همچنین تنظیم هایی برای محدودکردن دامنه های شبکه Agent دارد. برای شرکت ها، بهتر است فهرست دامنه های مجاز تعریف شود تا Agent فقط به localhost، محیط Stage و مستندات رسمی دسترسی داشته باشد.

کار در Dev Container، SSH، WSL و Codespaces

Integrated Browser می تواند در اتصال های Remote، ترافیک http و https را از ماشین Remote عبور دهد. این قابلیت برای Dev Container، SSH، WSL و GitHub Codespaces مهم است. سرویس ممکن است فقط داخل Container یا سرور توسعه در دسترس باشد و روی سیستم محلی Port عمومی نداشته باشد. مرورگر یکپارچه می تواند به همان محیط نزدیک تر شود و Agent برنامه را در محل واقعی اجرا ببیند.

این قابلیت در مستندات به عنوان Preview معرفی شده و ممکن است تغییر کند. در شبکه های سازمانی، Proxy، Certificate و سیاست امنیتی نیز باید بررسی شوند. Agent نباید برای حل مشکل اتصال، تنظیمات امنیتی را خودسرانه غیرفعال کند.

چطور Browser Tools را حرفه ای استفاده کنیم؟

1. هدف قابل سنجش بنویسید: دقیقاً بگویید کدام Flow و چه نتیجه ای باید بررسی شود.
2. URL و حساب تست بدهید: Agent نباید محیط یا Credential را حدس بزند.
3. تغییرات ممنوع را مشخص کنید: مثلاً Layout عمومی، CSS جدید یا API Contract نباید تغییر کند.
4. قبل و بعد را ثبت کنید: Screenshot، Console و تست خودکار شواهد خوبی هستند.
5. از الگوی موجود پروژه استفاده کنید: صفحه سالم مشابه را مرجع قرار دهید.
6. عملیات حساس را تأیید انسانی کنید: ثبت نهایی، حذف و تغییر داده واقعی نباید خودکار باشد.

پرسش های متداول

آیا برای Browser Tools باید MCP Server نصب کنیم؟

خیر. ابزارهای داخلی مرورگر در VS Code بدون MCP Server خارجی در دسترس هستند. البته MCP همچنان می تواند برای ابزارهای سفارشی دیگر استفاده شود.

Agent به همه Tabهای مرورگر من دسترسی دارد؟

خیر. Tabهای هر Session ایزوله هستند. برای صفحه ای که دستی باز کرده اید باید Share with Agent را انتخاب و دسترسی را تأیید کنید.

آیا Browser Tools جای تست E2E را می گیرد؟

خیر. برای کشف و بازتولید سریع عالی است، اما جریان های مهم باید به تست پایدار Playwright یا ابزار مشابه تبدیل شوند تا در CI تکرار شوند.

آیا می تواند خطاهای Console را ببیند؟

بله. Agent می تواند Console Error و Warning را بخواند و آن ها را با کد و رفتار صفحه ارتباط دهد.

آیا در Codespaces و Dev Container کار می کند؟

Integrated Browser از مرور روی اتصال Remote پشتیبانی می کند، اما این بخش در مستندات Preview است و باید در محیط خودتان آزمایش شود.

جمع بندی سریع

• Browser Tools حلقه میان کد و نتیجه رندرشده را کامل تر می کند.
• Agent می تواند Flow واقعی کاربر را اجرا و خطا را بازتولید کند.
• Console، Screenshot، DOM و Playwright باید کنار هم استفاده شوند.
• ایزوله سازی Session و Share دستی، بخشی از مرز امنیتی است.
• بهترین خروجی با حساب تست، معیار پذیرش و تغییرات محدود به دست می آید.

برای جزئیات رسمی، اعلام عمومی شدن Browser Tools و مستندات Integrated Browser در VS Code را بخوانید. برای یادگیری پایه JavaScript نیز می توانید از آموزش JavaScript تحت توسعه شروع کنید. یک Flow واقعی از پروژه را انتخاب و از Agent بخواهید قبل از هر تغییر، آن را بازتولید کند.