Copilot Workspace یک پروژه آزمایشی GitHub Next برای تبدیل مسئله نرم‌افزاری به برنامه تغییر و پیش‌نویس کد بود. اگر امروز این نام را در یک مقاله معرفی می‌بینید، باید وضعیت تاریخی آن را هم بدانید: طبق صفحه رسمی GitHub Next، Technical Preview این محصول در ۳۰ مه ۲۰۲۵ پایان یافت. بنابراین این صفحه راهنمای ثبت‌نام در یک سرویس فعال با همان نام نیست. ارزش بررسی Workspace در شناخت گردش کاری است که مسئله، برنامه، تغییر کد و بازبینی را کنار هم قرار می‌داد.
Workspace قرار بود کدام فاصله را کم کند؟
در یک پروژه معمولی، توسعه‌دهنده ابتدا Issue را می‌خواند، کد مرتبط را پیدا می‌کند، راه‌حل می‌نویسد و تغییر را به Pull Request تبدیل می‌کند. این مراحل از نظر اطلاعاتی به هم وابسته‌اند، اما اغلب در ابزارها و یادداشت‌های جدا انجام می‌شوند. Workspace تلاش می‌کرد آن‌ها را در یک تجربه مبتنی بر زبان طبیعی کنار هم قرار دهد. کاربر می‌توانست توضیح مسئله و برنامه پیشنهادی را تغییر دهد، به جای اینکه تنها یک پاسخ نهایی کد بگیرد و مسیر تصمیم را نبیند.
این شیوه برای کارهایی که دامنه روشنی دارند قابل فهم است. فرض کنید صفحه تنظیمات یک گزینه را نمایش می‌دهد، اما توضیح آن برای کاربر مبهم است. مسئله باید محل صفحه، رفتار فعلی و متن مورد انتظار را مشخص کند. برنامه تغییر سپس فایل مرتبط و اثر احتمالی روی ترجمه‌ها را بررسی می‌کند. با همین مثال ساده معلوم می‌شود تولید کد آخرین بخش کار است. اگر صورت مسئله مبهم باشد، ابزار ممکن است در جای دیگری تغییر معقولی بدهد که خواسته اصلی را حل نمی‌کند.
در معرفی این محصولات، عبارت «از ایده تا PR» نباید به معنی پذیرش خودکار نتیجه خوانده شود. Pull Request یک پیشنهاد قابل بررسی است. ساخت آن نشان می‌دهد فایل‌ها تغییر کرده‌اند، نه اینکه همه پیامدهای تغییر پذیرفته شده‌اند. مسئول بازبینی باید بفهمد تغییر چه مسئله‌ای را حل می‌کند، کدام قرارداد را حفظ می‌کند و چه چیزی هنوز نامطمئن است. ابزار هوش مصنوعی این مسئولیت را حذف نمی‌کند؛ می‌تواند بخشی از اطلاعات لازم برای انجام آن را آماده کند.
Issue خوب، ورودی قابل بررسی می‌سازد
برای استفاده از هر دستیار توسعه، رفتار فعلی و رفتار مورد انتظار را جدا بنویسید. «ورود خراب است» محدوده کافی نمی‌دهد. توضیح دهید کاربر کدام روش ورود را انتخاب کرده، چه پاسخی می‌گیرد و انتظار چیست. داده حساس را در مثال نیاورید؛ ورودی بی‌نام و قابل بازتولید کافی است. اگر خطا فقط در یک محیط رخ می‌دهد، محیط و نسخه مرتبط را ثبت کنید. این جزئیات به مدل و توسعه‌دهنده کمک می‌کنند از پیشنهاد تغییرهای نامرتبط دور بمانند.
معیار پذیرش نیز باید قابل مشاهده باشد. برای یک فرم، توضیح دهید خطا کنار کدام فیلد نمایش داده می‌شود و بعد از اصلاح ورودی چه اتفاقی می‌افتد. برای API، وضعیت پاسخ و شکل داده را مشخص کنید. جمله «عملکرد بهتر شود» برای قبول یا رد یک تغییر کافی نیست. هرجا هدف مبهم است، آن را به سؤال مشخص تبدیل کنید و از صاحب محصول پاسخ بگیرید. ابزار نباید تصمیم حل‌نشده کسب‌وکار را با حدس فنی پنهان کند.
محدودیت‌ها را هم بنویسید: تغییر Schema ممنوع است، قرارداد پاسخ باید حفظ شود یا ترجمه‌های موجود باید باقی بمانند. این محدودیت‌ها به برنامه تغییر جهت می‌دهند. اگر ابزار پیشنهاد می‌کند همه معماری بازنویسی شود، می‌توانید آن را با دامنه Issue مقایسه کنید. مسئله کوچک معمولاً توضیح کوتاه و تغییر متمرکز می‌خواهد. نوشتن محدودیت باعث می‌شود اختلاف میان راه‌حل لازم و پیشنهاد جذاب اما پرهزینه زودتر دیده شود.
برنامه پیشنهادی را پیش از کد بخوانید
برنامه تغییر باید به محل واقعی مسئولیت اشاره کند. اگر یک اعتبارسنجی در چند لایه انجام می‌شود، معلوم کنید کدام لایه باید منبع قرارداد باشد. پیشنهاد مدل ممکن است فایل ظاهر را اصلاح کند، در حالی که خطا از پاسخ سرور آمده باشد. قبل از پذیرفتن برنامه، مسیر داده را مرور کنید. توضیح فایل‌ها و وابستگی‌ها باید با ساختار پروژه جور باشد؛ نام‌بردن چند فایل در پاسخ، شاهد فهم کامل معماری نیست.
برنامه‌ای که بزرگ‌تر از مسئله است هزینه بازبینی و بازگشت را زیاد می‌کند. اگر برای اصلاح متن دکمه، ابزار وابستگی تازه اضافه می‌کند، دلیل بخواهید. اگر برای خطای یک مسیر، چند قرارداد عمومی را تغییر می‌دهد، مصرف‌کنندگان آن قرارداد را پیدا کنید. در مقاله مدل‌های ذهنی برای تصمیم‌گیری می‌توان درباره بررسی فرض و پیامد بیشتر خواند. در این کاربرد، مدل ذهنی مفید همان پرسش روشن درباره ضرورت هر تغییر است.
طرح کار باید موارد نامعلوم را هم ثبت کند. برای نمونه، ابزار می‌گوید هنوز معلوم نیست یک فیلد خالی مجاز است یا نه. بهتر است این ابهام پیش از کدنویسی دیده شود. اگر پاسخ با اطمینان آن را حدس بزند، تغییر ممکن است در ظاهر کامل باشد و بعد با نیاز مشتری تعارض پیدا کند. توضیح ابهام ضعف گزارش نیست؛ اطلاعاتی است که تصمیم بعدی را ممکن می‌کند. از دستیار بخواهید میان یافته از کد و فرض خودش تفاوت بگذارد.
پیش‌نویس کد را چگونه بازبینی کنیم؟
ابتدا نتیجه را با Issue مقایسه کنید و بعد جزئیات را بخوانید. آیا مسیر گزارش‌شده اصلاح شده است؟ آیا وضعیت‌های قبلی هنوز رفتار مورد انتظار را دارند؟ سپس نام‌گذاری، مسیر خطا و تغییر وابستگی‌ها را مرور کنید. اگر تغییر چند فایل دارد، از دستیار بخواهید دلیل هر فایل را توضیح دهد و توضیح را با diff تطبیق دهید. خطای رایج این است که گزارش زیبا را می‌خوانیم و فرض می‌کنیم کد دقیقاً همان کار را می‌کند.
تولید یک تست هم به تنهایی کافی نیست. تست باید رفتار مورد انتظار را بررسی کند و بتواند خطای قبلی را نشان دهد. گاهی تست تولیدشده همان منطق پیاده‌سازی را تکرار می‌کند و در نتیجه هر دو با یک فرض نادرست موافق‌اند. معیار پذیرش محصول و مرز داده به طراحی بررسی مفید کمک می‌کنند. ابزار می‌تواند حالت‌ها را پیشنهاد دهد، اما انتخاب حالت مرتبط به فهم مسئله نیاز دارد. برای تغییر کوچک متن، ممکن است مرور تحریری و تطبیق مسیر از یک تست مصنوعی مفیدتر باشد.
در تغییرات حساس، داده غیرمنتظره را هم در نظر بگیرید: ورودی خالی، مجوز ناکافی یا پاسخ دیرهنگام. مسیر موفق معمولاً ساده‌تر است و ابزار سریع‌تر آن را می‌سازد. مشکلات نگهداری بیشتر در حالت‌هایی دیده می‌شوند که قرارداد ناقص است. مقاله Code Review مؤثر درباره دادن بازخورد روشن توضیح می‌دهد. بازخورد خوب به رفتار و پیامد اشاره می‌کند، مثل «این مسیر پیش از بررسی مجوز، داده را برمی‌گرداند»، نه صرفاً پسند شخصی درباره سبک کد.
دسترسی عامل توسعه را محدود کنید
دستیار متصل به مخزن ممکن است فایل بخواند، فرمان اجرا کند یا تغییر بسازد. برای هر کار، سطح دسترسی لازم را مشخص کنید. بررسی یک Issue معمولاً نیاز به کلید استقرار تولید ندارد. محیط توسعه را از رازهای غیرضروری خالی نگه دارید و مسیر انتشار را جدا کنید. اگر ابزار افزونه یا اتصال بیرونی دارد، بدانید داده پروژه به کدام سرویس منتقل می‌شود. تصمیم درباره داده باید بر اساس شرایط استفاده و سیاست سازمان باشد، نه صرف آشنابودن برند ابزار.
محتوای repository و Issue ممکن است شامل دستورهایی باشد که از مشارکت‌کننده ناشناس آمده‌اند. چنین متن‌هایی داده مورد بررسی‌اند و نباید اختیار اقدام دستیار را گسترش دهند. اگر یک فایل از ابزار می‌خواهد اطلاعات محیط را به نشانی دیگری ارسال کند، باید آن را در چارچوب مسئله و مجوز واقعی ارزیابی کرد. مرز اعتماد در کار عامل‌ها اهمیت دارد، چون آن‌ها میان خواندن متن و انجام عمل حرکت می‌کنند. محدودیت ابزار و بازبینی اقدام کمک می‌کند این مرز روشن بماند.
پایان Preview چه درسی دارد؟
محصول آزمایشی برای یادگیری و تجربه مناسب است، اما تیم نباید وجود همیشگی آن را فرض کند. مستندات، Issueها و تصمیم‌های مهم را در قالبی نگه دارید که وابسته به یک رابط موقت نباشد. اگر گردش کار شما به قابلیت خاصی وابسته شده، مسیر جایگزین و امکان انتقال داده را بشناسید. پایان Workspace نمونه‌ای واقعی از تغییر عمر محصول است. از این رخداد نمی‌توان شکست همه دستیارهای توسعه یا حذف همه ابزارهای مشابه را نتیجه گرفت.
برای انتخاب ابزار فعلی، وضعیت همان محصول، امکانات حساب و نوع دسترسی را از مستندات رسمی روز بررسی کنید. نام Workspace را با هر قابلیت دیگری که Copilot نام دارد برابر نگیرید. برند مشترک ممکن است تجربه‌ها و قراردادهای متفاوتی را پوشش دهد. شرح تاریخی این صفحه کمک می‌کند مفهوم برنامه‌ریزی قابل ویرایش را بشناسید؛ راهنمای نصب و هزینه باید به محصولی مربوط باشد که اکنون واقعاً قابل استفاده است. تاریخ مستندات را همراه تصمیم تیم ثبت کنید.
برای تمرین، یک Issue محدود از پروژه خود انتخاب کنید و بدون تغییر کد، صورت مسئله و برنامه پیشنهادی را بنویسید. هر گام را به فایل و معیار پذیرش وصل کنید و فرض‌های نامعلوم را مشخص نگه دارید. سپس همان طرح را برای بازبینی انسانی بفرستید. این تمرین نشان می‌دهد مشکل اصلی در تعریف نیاز، شناخت کد یا تولید پیاده‌سازی بوده است. با این اطلاعات می‌توان درباره استفاده از یک دستیار فعلی تصمیم گرفت، بدون اینکه به سرویس بازنشسته متکی شوید.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!