کار با فایل‌های موجود؛ چطور کدبیس را به مدل نشان بدهیم

⏱ زمان مطالعه: حدود ۵ دقیقه

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

چرا مدل بدون زمینه اشتباه می‌کند

مدل کد را نمی‌بیند مگر آن‌که در همان مکالمه به او داده شود. اگر بگویید «تابع لاگین را دیباگ کن» بدون آن‌که خود تابع را نشان بدهید، مدل یک تابع لاگین عمومی و فرضی در ذهن می‌سازد که هیچ ربطی به کد واقعی شما ندارد. نتیجه، کدی است که از نظر ظاهری درست به‌نظر می‌رسد اما با بقیهٔ پروژه هماهنگ نیست؛ اسم متغیرها فرق دارد، الگوی مدیریت خطا فرق دارد، حتی ممکن است از کتابخانه‌ای استفاده کند که در پروژهٔ شما اصلاً نصب نیست.

کار با فایل‌های موجود؛ چطور کدبیس را به مدل نشان بدهیم

مفهوم context window به زبان ساده

هر مدل یک محدودهٔ حافظهٔ کاری دارد که به آن context window می‌گویند؛ یعنی حداکثر مقدار متنی که مدل می‌تواند در یک لحظه «به‌خاطر بسپارد» و روی آن استدلال کند. این محدوده را می‌توانید مثل میز کار مدل تصور کنید: هرچه روی میز بگذارید (کد، توضیح، پیام خطا) قابل استفاده است، اما هرچه در کشو یا در گوشهٔ دیگر اتاق مانده باشد، مدل اصلاً نمی‌بیند. اگر کدبیس شما بزرگ باشد و همه را یک‌جا بدهید، ممکن است بخشی از آن از میز کار بیفتد بیرون و مدل چیز مهمی را از قلم بیندازد. به همین دلیل، هنر کار با مدل این است که فقط فایل‌ها و بخش‌های مرتبط را بدهید، نه کل پروژه را.

چه چیزی بدهیم چرا لازم است
فایل یا تابع مستقیماً درگیر مدل دقیقاً می‌بیند چه چیزی را تغییر می‌دهد
ساختار پوشه‌ها (خروجی یک دستور لیست‌گیری ساده) مدل می‌فهمد فایل جدید کجا باید قرار بگیرد
یک نمونهٔ مشابه از کد موجود مدل سبک و قرارداد کدنویسی را کپی می‌کند
فایل تنظیمات یا وابستگی‌ها (مثل package.json) مدل می‌داند چه کتابخانه‌هایی واقعاً در دسترس است
پیام خطا یا رفتار فعلی مدل بین «چه چیزی هست» و «چه چیزی باید باشد» فرق می‌گذارد

چطور فایل و ساختار پوشه را نشان بدهیم

لازم نیست کل کدبیس را کپی کنید. سه روش ساده کافی است:

  1. ساختار پوشه‌ها را به‌صورت درختی بدهید تا مدل بداند فایل جدید کجا باید بنشیند.
  2. فقط فایل‌هایی که واقعاً درگیر تغییر هستند را کامل بچسبانید، نه کل پروژه.
  3. اگر ابزار شما به کدبیس دسترسی مستقیم دارد (مثل اغلب ابزارهای وایب کدینگ)، به‌جای کپی‌کردن دستی، مسیر فایل را بدهید و از مدل بخواهید خودش بخواند.
ساختار پروژه:
src/
  components/
    forms/
      LoginForm.tsx
      SignupForm.tsx
  lib/
    auth.ts
  pages/
    login.tsx

فایل مرتبط با درخواست من (src/lib/auth.ts):
[محتوای فایل]

درخواست: تابع login را طوری تغییر بده که خطای شبکه را جداگانه مدیریت کند،
دقیقاً با همان الگوی خطا که در همین فایل برای catch استفاده شده.

قرارداد کد؛ چیزی که مدل باید از قبل بداند

قرارداد کد یعنی قواعد نانوشته‌ای که در پروژهٔ شما رعایت می‌شود: نام‌گذاری فایل‌ها، الگوی مدیریت خطا، ترتیب import‌ها، یا حتی زبان کامنت‌ها. مدل این قراردادها را از خودتان یاد نمی‌گیرد مگر آن‌که یا نمونه ببیند یا صریح بگویید. بهترین راه، نگه‌داشتن یک فایل کوتاه قرارداد پروژه (مثلاً یک فایل به نام دستورالعمل پروژه) است که هر بار در ابتدای کار به مدل بدهید یا اگر ابزار شما از آن پشتیبانی می‌کند، به‌صورت خودکار بارگذاری شود.

مثال: «در این پروژه همهٔ توابع async باید try/catch داشته باشند، خطاها باید با تابع logError ثبت شوند، و کامنت‌ها فارسی نوشته می‌شوند.»

وقتی کدبیس بزرگ‌تر می‌شود

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

یک نشانهٔ خوب برای اینکه بدانید چه زمانی باید فایل بیشتری بدهید این است: اگر مدل در پاسخش از چیزی حرف می‌زند که در پروژهٔ شما وجود ندارد (مثل صدازدن تابعی که تعریف نشده)، احتمالاً یک فایل مهم را ندیده. در آن لحظه، به‌جای تصحیح‌کردن دستی، همان فایل گم‌شده را به او بدهید و دوباره بپرسید.

یک نکتهٔ عملی برای پروژه‌های طولانی

در مکالمه‌های طولانی با مدل، هرچه پیش می‌روید، اطلاعات قدیمی‌تر ممکن است کم‌رنگ‌تر شود یا حتی از context window بیرون بیفتد، مخصوصاً اگر کد زیادی رد و بدل شده باشد. اگر حس کردید مدل رفتار عجیبی نسبت به ابتدای مکالمه دارد یا چیزی را که قبلاً گفته بودید فراموش کرده، بهترین کار این نیست که عصبانی شوید؛ فقط دوباره زمینه را خلاصه کنید: چند خط دربارهٔ ساختار پروژه و قرارداد کدنویسی، و مکالمه را از همان نقطه ادامه بدهید.

اگر تازه با اصول وایب کدینگ آشنا می‌شوید، راهنمای کامل وایب کدینگ نقطهٔ شروع خوبی است، و برای دیدن نقشهٔ کامل مهارت‌هایی که پله‌به‌پله باید یاد بگیرید، نقشهٔ راه وایب کدینگ را ببینید.

جمع‌بندی

  • مدل فقط چیزی را می‌بیند که در همان مکالمه به او بدهید؛ بدون زمینه، حدس می‌زند و حدس‌ها اغلب اشتباه‌اند.
  • context window را مثل میز کار محدود مدل تصور کنید: فقط فایل‌های مرتبط را روی میز بگذارید، نه کل پروژه را.
  • ساختار پوشه، فایل‌های درگیر و فایل وابستگی‌ها سه چیزی هستند که تقریباً همیشه باید نشان داده شوند.
  • یک فایل کوتاه قرارداد کدنویسی نگه دارید و در ابتدای هر جلسه به مدل بدهید تا سبک پروژه رعایت شود.
(0 رأی)

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *