بسته زمینه برای برنامه‌نویسی با AI؛ چه اطلاعاتی به دستیار کدنویسی بدهیم؟

نویسنده: WKFGo Editorial · تاریخ انتشار · آخرین ویرایش

بسته زمینه توسعه‌دهنده چیست؟

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

Context Pack جای مستندات یا بررسی مهندس را نمی‌گیرد. نقش آن این است که «زمینه درست برای همین کار» را از میان انبوه اطلاعات جدا کند و منبع هر ادعا را نشان دهد.

چرا دادن کل مخزن راه‌حل خوبی نیست؟

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

یک بسته خوب بین این دو افراط قرار می‌گیرد:

• کمینه کافی: فقط اطلاعات لازم برای تصمیم فعلی؛
• قابل ردیابی: هر سند و فایل منبع مشخص دارد؛
• تازه: وضعیت branch، تست و تصمیم معماری قدیمی نیست؛
• محدود به مجوز: راز، داده مشتری یا پروژه غیرمجاز وارد زمینه نمی‌شود؛
• دارای مرز: مشخص است چه چیزی نباید تغییر کند.

اجزای ضروری Context Pack

اگر یکی از این بخش‌ها نامعلوم است، دستیار باید سؤال بپرسد یا عدم قطعیت را ثبت کند؛ حدس‌زدن نام فایل، رفتار API یا الزام امنیتی قابل قبول نیست.

۱. از تسک شروع کنید، نه از مخزن

تسک باید مسئله، اثر کاربر و معیار پذیرش داشته باشد. لینک‌کردن branch یا commit به شناسه تسک، تغییر فنی را به تصمیم محصول متصل نگه می‌دارد.

۲. جستجوی هدفمند انجام دهید

نام endpoint، خطای واقعی، نماد کد و تست‌های نزدیک را جستجو کنید. ابتدا فایل‌های مستقیم، سپس caller و قراردادهای عمومی را اضافه کنید. Context Pack فهرست تمام فایل‌های پوشه نیست.

۳. دانش پروژه را بازیابی کنید

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

۴. مرز تغییر را صریح کنید

نمونه: «migration دیتابیس مجاز نیست»، «رابط عمومی باید backward-compatible بماند» یا «فایل تولیدشده را ویرایش نکن». مرز روشن، تغییرهای جانبی و patch بزرگ را کم می‌کند.

۵. برنامه آزمون را پیش از کدنویسی بنویسید

دستیار بداند کدام رفتار باید قبل و بعد مقایسه شود. برای باگ، یک تست بازتولیدکننده؛ برای قابلیت، سناریوی عادی، مرزی و خطا لازم است. اگر اجرای تست به سرویس خارجی نیاز دارد، محدودیت را ثبت کنید.

۶. خروجی را برای بازبینی محدود کنید

خروجی مناسب شامل patch، فایل‌های تغییرکرده، تست‌های اجراشده، فرض‌ها و ریسک باقی‌مانده است. «انجام شد» بدون شواهد برای ادغام کافی نیست.

نمونه بسته زمینه کوتاه

Task: PAY-442 — جلوگیری از ثبت دوباره پرداخت در retry وب‌هوک
Acceptance: یک event_id فقط یک تراکنش مالی ایجاد کند
Relevant code: webhook/handler.go, payment/repository.go
Do not change: public response schema, database vendor
Security: payload کامل و token را log نکن
Tests: duplicate event, concurrent retry, repository failure
Expected output: patch + tests + migration/risk note
Unknown: رفتار event قدیمی بدون event_id؛ از انسان سؤال شود

این بسته کوتاه است، اما هدف، مرز و ابهام را بهتر از چند هزار خط کد خام منتقل می‌کند.

Context Pack پویا با MCP

در جریان متصل، ابزارهایی مانند get_context_pack می‌توانند تسک، ویکی مرتبط، وضعیت branch و استاندارد کدنویسی را در لحظه جمع کنند. مزیت MCP فقط انتقال متن نیست؛ هویت کاربر و ابزار مشخص‌اند و بسته می‌تواند از داده زنده ساخته شود.

در WKFGo، الگوی پیشنهادی چنین است:

1. start_work روی تسک مشخص؛
2. دریافت بسته زمینه و استانداردهای تیم؛
3. اجرای تغییر و تست در محیط توسعه؛
4. اتصال pull request به تسک؛
5. ثبت خلاصه با end_work؛
6. بازبینی انسانی و عبور از دروازه کیفیت.

ابزار خواندن زمینه نباید دسترسی فراتر از کاربر داشته باشد. همچنین «دریافت Context Pack» مجوز ویرایش یا ادغام کد نیست.

کنترل امنیت و حریم خصوصی

• فایل .env، کلیدها و داده واقعی مشتری را از بسته حذف کنید.
• به‌جای کپی لاگ کامل، قطعه لازم را با حذف شناسه‌های حساس بدهید.
• مجوز repository، پروژه و سند را پیش از بازیابی اعمال کنید.
• متن تسک و سند خارجی را داده غیرقابل اعتماد بدانید؛ دستور داخل آن نباید سیاست ابزار را عوض کند.
• بسته و خروجی را برای عملیات حساس در لاگ ممیزی نگه دارید.

چگونه کیفیت را بسنجیم؟

طی ۲۰ تسک مشابه این شاخص‌ها را مقایسه کنید:

• درصد patch پذیرفته‌شده بدون بازنویسی عمده؛
• تعداد فایل نامرتبط تغییرکرده؛
• خطای ناشی از قرارداد یا تصمیم معماری جاافتاده؛
• زمان مهندس تا اولین patch قابل بازبینی؛
• تعداد سؤال‌های درست قبل از اقدام؛
• هزینه token یا حجم زمینه برای هر تسک.

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

اشتباهات رایج

• ساخت بسته ثابت برای همه تسک‌های پروژه؛
• کپی کل مخزن یا چند سند طولانی بدون انتخاب بخش مرتبط؛
• نادیده‌گرفتن تست و تمرکز فقط بر فایل پیاده‌سازی؛
• استفاده از سند منسوخ بدون تاریخ و مالک؛
• اجرای خودکار تغییر پرریسک بدون بازبینی؛
• ثبت رازها در prompt یا تاریخچه گفتگو؛
• اندازه‌گیری موفقیت با تعداد خطوط تولیدشده.

بسته زمینه باید چند token باشد؟

عدد ثابت وجود ندارد. به اندازه‌ای باشد که هدف، قرارداد و آزمون روشن شوند و اطلاعات نامرتبط وارد نشود. نسبت سیگنال به حجم مهم‌تر از سقف اسمی مدل است.

آیا Context Pack فقط برای AI است؟

خیر. همین ساختار برای onboarding توسعه‌دهنده، تحویل بین تیم‌ها و بازبینی PR نیز مفید است.

چه زمانی انسان باید متوقفش کند؟

وقتی معیار پذیرش متناقض است، داده حساس وارد دامنه می‌شود، migration یا تغییر رابط عمومی لازم است یا تست کافی در دسترس نیست.

قدم بعدی

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

• ساخت حساب رایگان
• مستندات API و MCP
• مرور امکانات