دستیار آگاه از کدبیس را با بازیابی مرحله‌ای بساز، نه با ریختن کل ریپو
رؤیای دستیار آگاه از کدبیس روشن است. مدل را به ریپو اشاره کن و کمک بگیر. در عمل این می‌شود پرامپت بیش‌ازحد بزرگ، زمینه پرنویز، در معرض قرار گرفتن فایل نامربوط، و خروجی بیش‌ازحد مطمئن چون مدل زیاد از ماده غلط دیده.
ریختن کل مخزن در درخواست حرکت هوشمندانه نیست. هم گران است هم کند، هم دیباگ را سخت می‌کند، هم احتمال اینکه دستیار مسئله غلط را حل کند چون زمینه نامربوط حواسش را پرت کرده بالا می‌برد. آگاهی از ریپو ارزشمند است. پهن شدن ریپو نه. فرق معمولاً این است که بازیابی را گردش کار طراحی کرده‌ای یا تخلیه.
بازیابی را مرحله‌ای کن
رویکرد بهتر بازیابی مرحله‌ای است. از کار شروع کن. فایل یا ماژول محتمل را مشخص کن. زمینه محلی را انتخابی بیاور. فقط بخشی را جلو ببر که به این سؤال مربوط است. اگر ابزار بتواند قبل از جواب گشتن را انجام دهد، مدل لازم ندارد کل مخزن در درخواست اول چپانده شود.
این را با یک جمله کار شروع کن، نه با ایندکس کردن همه‌چیز «برای بعد». شکل ورودی را مشخص کن: سؤال کاربر، مخزن، و شاید مسیر فایلی که کاربر همین حالا باز کرده. شکل خروجی را هم مشخص کن: جواب، فهرست فایل خوانده‌شده، و جاهایی که زمینه کافی نبوده.
اگر فیچر به مجوز، داده پروداکشن، یا تغییر وضعیت قابل‌دیدن دست می‌زند، آن بخش مال اپ با اعتبار سخت است. مدل در فهم سؤال و در پیشنهاد تغییر فازی کمک می‌کند. نوشتن روی شاخه، باز کردن PR، یا اجرای دستور مخرب را اپ با دروازه مالک شود. دستیار آگاه از کد دلیل نمی‌شود این مرز شل شود.
محدوده را به کاربر نشان بده
محصول را درباره محدوده صریح نگه دار. بگو کدام فایل خوانده شد، کدام فرض شده، و کجا اطمینان کم است چون کد اطراف بار نشده. این دستیار را مفید نگه می‌دارد بدون اینکه وانمود کند آگاهی همه‌چیزدان از مخزن دارد.
اگر جواب به فایلی تکیه دارد که نخوانده، باید بگوید نخوانده. سکوت اینجا بیش‌اعتمادی می‌سازد. برای تغییر پیشنهادی، diff را به همان فایل‌هایی محدود کن که در زمینه بوده‌اند مگر ابزار دوباره خوانده باشد و این خواندن در رد کار ثبت شده باشد.
از نظر عملیاتی زمینه کوچک‌تر ارزان‌تر، سریع‌تر، و قابل‌بازبینی‌تر است. لاگ باید نام فایل و دلیل انتخاب را داشته باشد، نه لزوماً متن کامل در نگهداری بلند. متن را مثل بقیه داده حساس بدان. خیلی ریپوها راز، داده نمونه، و توضیح داخلی دارند که نباید به trace پیش‌فرض نشت کند.
ابزار گشتن، نه پرامپت غول
سطح ابزار را کوچک و کسل نگه دار. جستجوی نماد یا متن، خواندن یک بازه خط از یک فایل، و فهرست کردن یک پوشه معمولاً کافی است برای نسخه اول. هر ابزار سقف نتیجه می‌خواهد تا مدل کل درخت را با صد بار `ls` خالی نکند. بودجه گام و زمان دیوار را همان‌جا بگذار. بدون سقف، «کمی بیشتر بگرد» حلقه صورتحساب است.
انتخاب فایل را می‌شود با نشانه ساده شروع کرد: مسیر باز کاربر، واردکردن‌ها از فایلی که نام برده، و نتیجه جستجوی عبارت خطا. این بازیابی کامل برداری نیست و اغلب برای سؤال «این تابع کجا شکسته» بهتر از ایندکس کل مخزن است. اگر بعداً ایندکس اضافه کردی، هنوز باید مرحله انتخاب بماند. ایندکس جایگزین محدوده نیست.
خروجی را قبل از اینکه کد پایین‌دست به آن تکیه کند اعتبار کن. اگر قرار است پچ اعمال شود، پچ باید به مسیر واقعی بخورد و از اعتبار خارج نشود. اگر قرار است فقط توضیح باشد، توضیح را با فهرست منبع نشان بده تا بازبین انسان بتواند در سی ثانیه دروغ را ببیند.
نسخه اول باید صادقانه خراب شود. «در این محدوده جوابی ندارم» بهتر از حدس روان است. حالت جزئی روشن و مسیر موفقیت باریک سالم‌تر از دستیار خودمختاری است که هنوز استحقاق این شهرت را ندارد.
اشتباه‌ها
ساخت بیش از حد. پلتفرم نمایه‌سازی عمومی قبل از اینکه یک سؤال تکراری را خوب جواب داده باشی. انعطاف را نگهداری می‌کنی در حالی که کاربر هنوز از یک مسیر باریک سود نبرده.
تعریف نکردن موفقیت. اگر کسی نداند جواب درست یعنی استناد به فایل درست، پچ قابل اعمال، یا فقط توضیح سطح بالا، ارزیابی منصفانه ممکن نیست و فیچر هدف متحرک می‌شود.
نادیده گرفتن دست‌به‌دست انسان. هم‌تیمی باید بتواند ببیند چه خوانده شده و کجا فرض شده بدون مهندسی معکوس پرامپت. رونوشت چت به‌تنهایی شواهد ضعیف است. فهرست فایل و diff ذخیره‌شده قابل استفاده‌اند.
و اشتباه مخصوص این کار: فرستادن `.env`، قفل خصوصی، و دایرکتوری تولیدشده چون فیلتر مسیر نداری. فهرست رد را قبل از اولین ایندکس بنویس. پیش‌فرض امن کوچک‌تر از پیش‌فرض «همه چیز متن است».
شروع
یک نوع سؤال را انتخاب کن که تیم واقعاً تکرار می‌کند. مثلاً توضیح یک خطا با تکیه به فایل تست و فایل پیاده‌سازی. قرارداد خروجی را بنویس. ابزار خواندن را سقف‌دار کن. به کاربر نشان بده چه خوانده شد. اعتبار و مشاهده‌پذیری حداقلی را بگذار. کاربر واقعی را وقتی بیاور که رفتار کمی‌غلط را دیدی: فایل غلط، اطمینان الکی، یا گشتن بی‌پایان.
آگاهی از ریپو را از محدوده بگیر، نه از حجم. حجم بیشتر معمولاً یعنی مدل ماده غلط بیشتری دیده.
پرسش‌های کوتاه
**کل ریپو را در context بلند بریزم حالا که پنجره بزرگ شده؟** نه. پنجره بزرگ‌تر هنوز نویز، هزینه، و نشت را بیشتر می‌کند. انتخاب را حذف نمی‌کند.
**کاربر باید فایل را خودش بچسباند؟** اگر مسیر را می‌داند، چسباندن دقیق‌ترین زمینه است. دستیار باید بتواند از همان شروع کند نه اینکه دوباره همه‌چیز را بگردد.
**راز داخل ریپو چه؟** قبل از خواندن فیلتر کن و در لاگ پیش‌فرض متن فایل را نگه ندار. دستیار کد مجوز خواندن راز production را نمی‌سازد.