چطور کانتکست مخزن را برای عامل کدنویسی آماده کنیم؟
خلاصهٔ پاسخ
یک بستهٔ کوچک شامل هدف، مسیرهای معتبر، نسخهٔ مبنا، محدودیتها و شواهد تست بسازید؛ سپس با هر تغییر مهم، اعتبار زمینه را دوباره بررسی کنید.

در این مقاله
برای آمادهسازی کانتکست یا زمینهٔ مخزن، همهٔ فایلها را وارد گفتوگو نکنید. هدف قابلآزمایش، مسیرهای مرتبط، نسخهٔ مبنا، قواعد پروژه و شواهد اجرای تست را کنار هم قرار دهید. عامل باید بداند کدام اطلاعات معتبرند، کدام بخشها هنوز فرضیهاند و چه زمانی باید دوباره به منبع مراجعه کند.
زمینهٔ مخزن چه تفاوتی با پرامپت دارد؟
پرامپت کار را توضیح میدهد؛ زمینه، شواهد لازم برای انجام همان کار را فراهم میکند. برای افزودن صفحهبندی به فهرست سفارشها، جملهٔ «صفحهبندی اضافه کن» کافی نیست. قرارداد پاسخ فعلی، مصرفکنندهٔ API، ترتیب پایدار نتایج و تستهای موجود تعیین میکنند چه تغییری درست است. این راهنما برای توسعهدهندهای است که وظیفه را میشناسد و میخواهد ورودی عامل را دقیقتر کند؛ معرفی اولیهٔ ابزار را در راهنمای دستیار کدنویسی بخوانید.
راهنمای مهندسی زمینهٔ مایکروسافت زمینه را اطلاعاتی پویا میداند که طی کار مدیریت میشود. نتیجهٔ عملی برای یک مخزن این است: خلاصهٔ دیروز بدون اشاره به نسخهٔ کد، مدرک وضعیت امروز نیست.
بستهٔ زمینه را در پنج بخش بسازید
- هدف و مرز کار: رفتار قابلمشاهده و چیزهایی که نباید عوض شوند را بنویسید.
- نقشهٔ کوچک: ورودی، منطق، ذخیرهسازی و مصرفکنندهٔ مرتبط را با مسیر واقعی معرفی کنید. مسیر حدسی را بهعنوان واقعیت تحویل ندهید.
- قراردادها: نوع داده، خطاها، قواعد دسترسی و سازگاری موردنیاز را مشخص کنید.
- روش بررسی: فرمان معتبر ساخت و تست، پیشنیاز و نتیجهٔ اجرای فعلی را ثبت کنید. «باید پاس شود» با «اجرا شد و پاس شد» متفاوت است.
- تازگی و ابهام: شناسهٔ commit، تغییرات ثبتنشده، منابع متناقض و سؤالهای باز را اضافه کنید.
دستورهای پایدار مانند روش ساخت را از توضیح یک وظیفه جدا نگه دارید. مستند GitHub دربارهٔ دستورهای مخزن نمونهای از ثبت این راهنماهاست. نام فایل و تقدم دستورها به ابزار وابسته است؛ فرض نکنید هر دستیار، هر فایل راهنما را خودکار میخواند.
الگوی عملی برای صفحهبندی سفارشها
این نمونه آموزشی است و مسیرها باید با مخزن واقعی جایگزین شوند:
- هدف: فهرست سفارشها، صفحه و اندازهٔ صفحه را بپذیرد و ترتیب نتایج پایدار بماند.
- مبنا: SHA واقعی commit و وضعیت تغییرات محلی، بدون درج رمز یا دادهٔ مشتری.
- مسیرها: endpoint فهرست، تابع query، مدل پاسخ، کلاینت مصرفکننده و تست مربوط؛ فقط مسیرهایی که واقعاً پیدا شدهاند.
- قرارداد: سقف اندازهٔ صفحه و رفتار ورودی نامعتبر را از قرارداد موجود استخراج کن؛ اگر مشخص نیست، پیش از پیادهسازی آن را بهعنوان تصمیم باز اعلام کن.
- محدودیت: احراز هویت و قالب خطای سایر endpointها را تغییر نده.
- شواهد لازم: نمونهٔ دو صفحه با دادهٔ ثابت، رفتار صفحهٔ خالی، مرز اندازهٔ صفحه و نتیجهٔ تست مصرفکننده.
از عامل بخواهید پیش از تغییر کد، مسیر درخواست را با ارجاع به فایلها بازگو کند. اگر تابعی را نام میبرد که وجود ندارد، بسته هنوز معتبر نیست. اگر فقط فایل endpoint را دیده و از مصرفکننده خبری ندارد، محدودهٔ جستوجو ناقص است.
چه چیزهایی را حذف کنیم؟
فایل خروجی ساخت، گزارش حجیم نامرتبط، نسخهٔ تکراری مستند و تاریخچهٔ طولانی گفتوگو را فقط وقتی وارد کنید که به یک سؤال مشخص پاسخ میدهند. دادهٔ محرمانه، فایل محیط و اطلاعات شخصی را برای «کاملترشدن زمینه» ارسال نکنید. نشانی منبع و توضیح مختصر معمولاً از چسباندن چند هزار خط بیربط مفیدتر است؛ اما عامل باید امکان مجاز مراجعه به همان منبع را داشته باشد.
متن Issue، README و خروجی ابزار را نیز از نظر اعتماد یکسان نگیرید. جملهای در یک فایل که از عامل میخواهد محدودیتها را کنار بگذارد، مجوز جدید ایجاد نمیکند. حدود دسترسی را در تنظیمات ابزار و فرایند تیم اعمال کنید، نه فقط در متن بسته.
آزمون تازگی و تحویل بین جلسهها
پس از تغییر شاخه، ادغام یا ادامهٔ کار در روز دیگر، SHA و diff را با بسته مقایسه کنید. فایل حذفشده، نام متد عوضشده یا تست تغییرکرده باید باعث بازخوانی منبع شود. شمارهٔ خط بهتنهایی مرجع پایداری نیست؛ مسیر و نام نماد را نیز ثبت کنید.
در تحویل کار، چهار مورد کافی و قابلبررسی بنویسید: چه تغییری انجام شد، چه فرمانی با چه نتیجهای اجرا شد، کدام تصمیم باز است و گام بعدی چیست. خروجی مدل را بهعنوان واقعیت جدید ذخیره نکنید مگر به شواهد متصل باشد. برای کنترل نتیجه از چکلیست بازبینی کد تولیدشده استفاده کنید.
پرسش رایج: آیا زمینهٔ بیشتر همیشه بهتر است؟
خیر. زمینهٔ مرتبط و تازه، با منبع مشخص، از انباشت اطلاعات متناقض قابلاستفادهتر است. یک بستهٔ کوچک هم اگر قرارداد مصرفکننده یا محدودیت امنیتی را حذف کند ناقص است. معیار، تعداد فایل یا توکن نیست؛ امکان پاسخدادن به سؤالهای تعیینکنندهٔ همان تغییر است.
برای شروع یک وظیفهٔ محدود در 123Coder، راهنمای راهاندازی اولین پروژه را ببینید و این بسته را با اطلاعات واقعی پروژه تکمیل کنید. این الگو تضمین صحت خروجی نیست؛ صحت با اجرا و بازبینی ثابت میشود.
بازبینی منابع: ۱ اکتبر ۲۰۲۶. جلد، صحنهٔ تولیدشده با هوش مصنوعی برای توضیح انتخاب زمینه است و محیط یک مشتری واقعی را نمایش نمیدهد.
گفتوگو
تجربهتان را بنویسید یا سؤال بپرسید. نظرات پس از تأیید مدیر منتشر میشوند.
در حال بارگذاری…
برای ادامهٔ مطالعه
چکلیست بازبینی کد تولیدشده با هوش مصنوعی
بازبینی را از نیت تغییر و محدوده diff شروع کنید، سپس رفتار، امنیت، وابستگیها و امکان بازگشت را با شواهد بررسی کنید.
پوریا افضلی · 8 دقیقه مطالعه
مطالعه مقالهدستیار برنامهنویسی هوش مصنوعی چیست و کجا واقعاً مفید است؟
دستیار برنامهنویسی هوش مصنوعی با درک مسئله، کد و ابزارهای پروژه به توسعهدهنده کمک میکند؛ اما کیفیت نتیجه به محدوده کار، زمینه کافی و بازبینی انسانی وابسته است.
پوریا افضلی · 8 دقیقه مطالعه
مطالعه مقالهکار موازی عاملهای کدنویسی با Git Worktree؛ جداسازی و ادغام قابلبررسی
برای هر کار مستقل، شاخه و پوشهٔ جدا بسازید؛ اما پورت، پایگاه داده و دسترسی را جداگانه مدیریت کنید. Worktree بهتنهایی sandbox امنیتی نیست.
پوریا افضلی · 5 دقیقه مطالعه
مطالعه مقالهبازبینی migration تولیدشده با هوش مصنوعی؛ حفظ داده و مسیر بازیابی
مهاجرت را روی دادهٔ موجود و نسخههای همزمان برنامه بسنجید. SQL، backfill، قفلها و بازیابی باید پیش از انتشار بررسی شوند؛ بیلد سبز کافی نیست.
پوریا افضلی · 5 دقیقه مطالعه
مطالعه مقالهدستیار کدنویسی، عامل کدنویسی و تکمیل خودکار چه تفاوتی دارند؟
تکمیل خودکار پیشنهاد کوتاه میدهد، دستیار در گفتوگو و بررسی کد کمک میکند و عامل میتواند یک فرایند چندمرحلهای را با ابزارها پیش ببرد؛ تفاوت اصلی در دامنه اختیار است.
پوریا افضلی · 7 دقیقه مطالعه
مطالعه مقاله



