snake.html است؛ اما هدف فقط رسیدن به یک صفحهٔ قابل‌بازی نیست. یاد می‌گیری چطور بفهمی اتصال درست است، چرا مدل گاهی به‌جای ساخت فایل فقط کد را در گفتگو می‌نویسد، و نتیجه را با اجرای واقعی بازی ارزیابی کنی.
۱. پیش از انتخاب مدل، محدودیت مک را بشناس
در آزمایش مبنای این آموزش، دستگاه یک مک‌بوک با حافظهٔ ۱۲۸ گیگابایتی بود. این مشخصات را پیش‌نیاز کار حساب نکن: نتیجهٔ آن دستگاه، ضمانتی برای سرعت یا امکان اجرای همان مدل روی مک تو نیست. برای شروع، در LM Studio سراغ مدلی برو که فایل و قالب اجرایی‌اش با سیستم تو سازگار است و هنگام بارگذاری، فضای کافی برای خود مدل، پنجرهٔ زمینه و برنامه‌های دیگر باقی می‌گذارد. اگر مدل بارگذاری نمی‌شود یا سیستم به‌شدت کند شده، نخست مدل کوچک‌تری انتخاب کن؛ افزایش تنظیمات معمولاً درمان کمبود حافظه نیست.
در انتخاب‌ها ممکن است عبارت «۴بیتی» را ببینی. این نوع کوانتیزه‌سازی، وزن‌های مدل را با دقت کمتری نگه می‌دارد و معمولاً حجم موردنیاز را کاهش می‌دهد، ولی رایگان نیست: کیفیت بعضی پاسخ‌ها می‌تواند تغییر کند. روی مک‌های دارای حافظهٔ یکپارچه نیز نسبت‌دادن کل مصرف مدل به «VRAM» به شیوهٔ کارت گرافیک مجزا دقیق نیست. مقدار حافظهٔ قابل‌استفاده به مدل، قالب فایل، طول زمینه و بار سیستم بستگی دارد. قبل از ساخت بازی، معیار موفقیت این مرحله ساده است: مدل باید در گفتگوی خود LM Studio بارگذاری شود و به یک پیام کوتاه پاسخ بدهد.
۲. پنجرهٔ زمینه را برای پروژه تنظیم کن، نه برای رکوردزدن
پنجرهٔ زمینه یا context window مقدار اطلاعاتی است که مدل در یک نوبت می‌تواند از گفتگو، دستورهای Cline و محتوای فایل‌ها در نظر بگیرد. هرچه پروژه و سابقهٔ گفتگو بزرگ‌تر شوند، این فضا زودتر پر می‌شود. افزایش آن ممکن است حافظهٔ بیشتری بخواهد و اجرای درخواست را سنگین‌تر کند؛ عدد بزرگی که در مشخصات یک مدل می‌بینی، به‌تنهایی به معنی مناسب‌بودن همان تنظیم روی مک تو نیست.
برای پروژهٔ تک‌فایلی Snake، از تنظیمی شروع کن که مدل با آن پایدار بارگذاری می‌شود. اگر Cline بعدها پیام کمبود زمینه داد یا جزئیات درخواست‌های قبلی را فراموش کرد، مسئله را بررسی کن: شاید فایل‌های نامربوط وارد گفتگو شده‌اند یا گفتگو بیش از حد طول کشیده است. خلاصه‌سازی سابقه می‌تواند جا باز کند، اما جزئیاتی را هم از دست می‌دهد. پس خواستهٔ فعلی، نام فایل و قواعد بازی را در پیام تازه روشن بنویس. نتیجهٔ مطلوب در این مرحله، پاسخ کوتاه و پایدار مدل است؛ هنوز ساخت فایل را امتحان نکرده‌ایم.
۳. LM Studio را به‌عنوان سرویس محلی آماده کن
پاسخ‌دادن مدل در پنجرهٔ LM Studio با در‌دسترس‌بودن آن برای Cline فرق دارد. برای اتصال، مدل را بارگذاری کن، بخش سرور محلی LM Studio را باز کن و سرور را راه بینداز. نشانی‌ای را که خود برنامه برای سرور نشان می‌دهد کپی کن؛ پورت یا نشانی را از روی مثال‌های اینترنتی حدس نزن. راهنمای LM Studio برای پیدا کردن تنظیمات در رابطی که نصب کرده‌ای مرجع مناسبی است.
در این اتصال، «OpenAI-compatible» نام یک شیوهٔ سازگار برای فرستادن درخواست است، نه نشانهٔ استفاده از مدل ابری OpenAI. در آزمایش، به انتهای نشانی پایهٔ سرور /v1 اضافه شد. اگر Cline فیلدی به نام Base URL دارد، نشانی نمایش‌داده‌شده در LM Studio را با قالب مورد انتظار همان فیلد مقایسه کن تا /v1 را نه جا بیندازی و نه دوبار اضافه کنی. این نشانی محلی را با یک سرور اینترنتی اشتباه نگیر؛ برای این تمرین نیازی به عمومی‌کردن آن نیست. در پایان این مرحله، سرور باید فعال بماند و مدل همچنان بارگذاری‌شده باشد.
۴. Cline را به مدل درست وصل کن
در VS Code یک پوشهٔ تازه و خالی برای تمرین باز کن؛ مثلاً پوشه‌ای با نام local-snake. سپس Cline را باز کن و در تنظیمات ارائه‌دهنده، گزینهٔ اتصال OpenAI-compatible و نشانی پایهٔ سرور محلی را انتخاب کن. نام مدل را از فهرست یا اطلاعاتی که LM Studio برای مدل بارگذاری‌شده نشان می‌دهد بردار و در فیلد Model ID قرار بده. نام نمایشی مدل و شناسه‌ای که اتصال انتظار دارد همیشه یکی نیستند؛ تایپ‌کردن نام از حافظه، خطای قابل‌پیشگیری است. برای جزئیات رابط و مجوزهای ابزار می‌توانی به راهنمای Cline رجوع کنی.
در آزمایش، خالی‌گذاشتن فیلد API key امتحان شد، اما از این اتفاق نتیجه نگیر که هر نصب یا هر تنظیمی بدون کلید کار می‌کند. اگر رابط Cline مقداری می‌خواهد یا خطای احراز هویت می‌بینی، تنظیمات همان سرور و همان ارائه‌دهنده را بررسی کن؛ کلید واقعی یک سرویس دیگر را برای رفع خطای اتصال محلی وارد نکن. نخست یک پیام کوتاه مثل Hi بفرست. اگر پاسخ آمد، فقط ثابت کرده‌ای مسیر درخواست تا مدل برقرار است؛ توانایی ویرایش فایل هنوز آزموده نشده است.
۵. تفاوت «مدل جواب داد» و «ایجنت فایل ساخت» را ببین
مدل زبانی متن تولید می‌کند. Cline لایهٔ ایجنتیِ پیرامون آن است: پروژه را در اختیار مدل می‌گذارد، ابزار خواندن یا تغییر فایل را عرضه می‌کند و برای اجرای بعضی اقدام‌ها از تو تأیید می‌گیرد. گاهی به این مجموعهٔ دستورها، ابزارها و مدیریت زمینه harness می‌گویند. بنابراین کیفیت نتیجه فقط به نام مدل وابسته نیست؛ نحوهٔ کار Cline و سازگاری پاسخ مدل با قالب فراخوانی ابزار هم اهمیت دارد.
این تفاوت را با یک آزمون کوچک بسنج. از مدل بخواه نام فایل‌های پوشهٔ بازشده را بگوید و بعد، با اجازهٔ تو، فایل مشخصی بسازد. اگر در گفتگو کد HTML تولید شد ولی فایلی در Explorerِ VS Code پیدا نکردی، «تولید کد» رخ داده، نه «اعمال تغییر». درخواست را محدودتر کن، مجوز ابزار پیشنهادی را بررسی کن و ببین Cline خطایی برای فراخوانی ابزار نشان می‌دهد یا نه. از دادن دسترسی بی‌حساب به پوشه‌های شخصی خودداری کن؛ پوشهٔ خالی تمرین، هم تشخیص تغییرات را آسان‌تر می‌کند و هم محدودهٔ کار را روشن نگه می‌دارد.
۶. اولین درخواست بازی را کوچک و قابل‌آزمون بنویس
در آزمایش، درخواست اولیه ساخت Snake با HTML در پروژهٔ جاری بود. برای یادگیری، همان ایده را دقیق‌تر می‌کنیم. متن زیر بازنویسی آموزشی پرامپت است، نه نقل‌قول عینی از درخواست اجراشده:
در پوشهٔ بازشدهٔ VS Code، یک بازی سادهٔ Snake در فایل snake.html بساز.
HTML، CSS و JavaScript لازم را در همین فایل نگه دار و به کتابخانه یا فایل بیرونی وابسته نباش.
بازی با صفحه‌کلید کنترل شود، امتیاز را نشان دهد و پس از برخورد، راه شروع دوباره داشته باشد.
پیش از تغییر فایل، مسیر هدف را اعلام کن. پس از ساخت، بگو چگونه آن را در مرورگر باز و آزمایش کنم.
اگر ابزار ویرایش فایل در دسترس نیست، صادقانه بگو؛ کد را جایگزینِ ادعای ساخت فایل نکن.
درخواست تک‌فایلی عمداً انتخاب شده است: برای اجرای آن به نصب موتور بازی یا راه‌اندازی سرور وب نیاز نداری، و می‌توانی به‌سادگی بررسی کنی آیا snake.html واقعاً در ریشهٔ local-snake ساخته شده است. پیشنهادهای Cline برای خواندن یا نوشتن فایل را پیش از تأیید نگاه کن. انتظار این مرحله یک فایل قابل‌بازکردن است، نه صرفاً پیام «انجام شد». اگر فایلی وجود ندارد، همان‌جا توقف کن؛ رفتن سراغ بازی پیچیده‌تر فقط عیب‌یابی را دشوار می‌کند.
۷. بازی را اجرا کن و رفتار آن را جدا از ظاهر بسنج
فایل snake.html را از پوشهٔ پروژه در مرورگر باز کن. اگر Cline نتوانست آن را برایت باز کند، خودت فایل را باز کن؛ توانایی بازکردن مرورگر، معیار درست‌بودن منطق بازی نیست. با کلیدهای کنترلی اعلام‌شده در صفحه بازی کن و چند موقعیت مشخص را امتحان کن: آیا مار حرکت می‌کند؟ با خوردن غذا امتیاز تغییر می‌کند؟ پس از برخورد چه اتفاقی می‌افتد؟ آیا شروع دوباره واقعاً وضعیت بازی را بازنشانی می‌کند؟
در نمونهٔ اجراشده، بازی Snake باز و بازی شد و ظاهر دکمه‌ها و نتیجهٔ کلی رضایت‌بخش بود. این مشاهده ارزشمند است، ولی جای آزمون گوشه‌های بازی را نمی‌گیرد. برای مثال، عبور مار از دیوار لزوماً باگ نیست؛ ممکن است قانون طراحی بازی «خروج از یک سمت و ورود از سمت دیگر» باشد. اگر خواستهٔ تو توقف بازی هنگام برخورد است، این را صریح بنویس. نتیجهٔ قابل‌اتکا، گزارشی از رفتار مشاهده‌شده است: «با رسیدن سر مار به لبهٔ راست، بازی ادامه یافت»، نه صرفاً «بازی خوب بود».
۸. خطای ابزار یا حافظه را با درخواست دقیق‌تر اصلاح کن
در جریان ساخت، ممکن است مدل مقدار زیادی HTML در گفتگو بنویسد اما نتواند آن را در فایل ذخیره کند. این اتفاق را فوراً به «ضعیف‌بودن مدل» نسبت نده. وضعیت Cline را نگاه کن: آیا ابزار نوشتن فایل پیشنهاد شده، تأیید گرفته و اجرا شده است؟ آیا پوشهٔ درست در VS Code باز است؟ آیا فایل با نام دیگری ساخته شده؟ اگر ابزار خطا داده، همان خطا را مبنای درخواست بعدی قرار بده. یک بازنویسی آموزشی پرامپت برای ادامهٔ کار چنین است:
فعلاً ویژگی جدید اضافه نکن. بررسی کن آیا snake.html در ریشهٔ پوشهٔ بازشده وجود دارد.
اگر وجود ندارد، فقط همان فایل را با ابزار ویرایش پروژه بساز.
اگر ابزار شکست خورد، متن خطا را خلاصه کن و هیچ تغییری را انجام‌شده گزارش نکن.
اگر فایل وجود دارد، فقط ایراد مشخصِ [رفتار مشاهده‌شده را اینجا بنویس] را اصلاح کن.
اگر گفتگو طولانی شده، در پیام تازه وضعیت واقعی پروژه را خلاصه کن: نام فایل، چیزی که در مرورگر کار می‌کند، و یک ایراد باز. این کار از اتکا به سابقه‌ای که شاید خلاصه یا از پنجرهٔ زمینه خارج شده بهتر است. پس از هر اصلاح، فایل را دوباره در مرورگر بازآوری کن و همان آزمایش قبلی را تکرار کن. تغییرِ بدون آزمون، هنوز رفع خطا نیست.
۹. بعد از Snake، سراغ Godot برو؛ با انتظار متفاوت
مرحلهٔ بعدی آزمایش، درخواست یک بازی سادهٔ مسابقه‌ای با Godot بود. این جهش مهمی است: برخلاف snake.html، پروژهٔ Godot به موتور بازی، ساختار پروژه و سازگاری کد با نسخهٔ نصب‌شده نیاز دارد. اگر می‌خواهی آن را تکرار کنی، نخست خود Godot را نصب و یک پروژهٔ خالی را در ویرایشگر باز کن. سپس از Cline بخواه فقط در همان پوشه کار کند و نسخهٔ موتور را از محیط پروژه بررسی کند، نه اینکه آن را حدس بزند. مستندات Godot برای بررسی مفاهیم موتور و خطاهای اجرا مفید است.
این مثال تکمیلی آموزشی، درخواست را به یک نمونهٔ کوچک محدود می‌کند؛ ادعا نمی‌کند همین متن در آزمایش استفاده شده است:
در پروژهٔ Godot بازشده، ابتدا نسخهٔ موتور و فایل‌های موجود را بررسی کن.
یک نمونهٔ دوبعدی بسیار ساده از بازی مسابقه‌ای بساز: خودروی قابل‌کنترل، مسیر قابل‌دیدن و امکان شروع دوباره.
فایل‌های موجود را بی‌دلیل بازنویسی نکن. پس از هر تغییر مهم، روش اجرای پروژه را بگو.
اگر هنگام اجرا خطا دیدی، متن خطا و فایل مربوط را بررسی کن؛ سازگاری نسخه را حدس نزن.
در آزمایش، نسخهٔ اولیهٔ بازی به مشکل خورد و ناسازگاری برخی قابلیت‌ها با نسخهٔ موتورِ در حال اجرا به‌عنوان علت احتمالی مطرح شد. پس از اصلاح، بازی در Godot اجرا شد و واکنش به کلید شروع بررسی شد. این را به معنی بی‌خطابودن تمام پروژه تعبیر نکن. برای ارزیابی خودت، پروژه را از ویرایشگر Godot اجرا کن، خروجی خطا را بخوان و کنترل، برخورد و شروع دوباره را جداگانه امتحان کن. ساخت این پروژه طولانی‌تر از بازی HTML شد؛ از یک مورد، زمان قطعی برای مدل یا مک خودت استخراج نکن.
۱۰. مقایسهٔ منصفانه و خروجی نهایی تو
در ادامهٔ آزمایش، ساخت Snake با یک مدل دیگر نیز امتحان شد. پاسخ و ساخت فایل در مشاهدهٔ آن اجرا سریع‌تر پیش رفت، اما تفاوت ظاهری و رفتاری بازی‌ها اجازهٔ حکم سادهٔ «این مدل همیشه بهتر است» نمی‌دهد. حتی عبور از دیوار، بدون مشخص‌بودن قانون مورد انتظار، معیار قطعی خرابی نیست. برای مقایسهٔ خودت، درخواست، پوشهٔ خالی، ابزار ایجنت و آزمون‌های بازی را یکسان نگه دار؛ سپس زمان تقریبیِ مشاهده‌شده، خطاهای ابزار و رفتار نهایی را ثبت کن. مصرف باتری و داغ‌شدن دستگاه را هم زیر نظر بگیر، اما از یک اجرای سنگین نتیجه نگیر که کار محلی الزاماً به لپ‌تاپ آسیب می‌زند.
خروجی نهایی‌ات را به یک فایل snake.html قابل‌بازی و یک یادداشت کوتاه کنار آن تبدیل کن: کدام مدل را در LM Studio بارگذاری کردی، Cline به کدام مدل وصل شد، بازی را چطور باز کردی، کدام آزمون‌ها گذشتند و کدام ایرادها باقی ماندند. اگر خواستی Godot را هم ادامه بدهی، پروژهٔ آن را در پوشه‌ای جدا نگه دار و فقط وقتی «آمادهٔ اجرا» بنام که خودت آن را در ویرایشگر اجرا کرده باشی. این تفاوت اصلیِ کار با ایجنت است: پیام «تمام شد» پایان کار نیست؛ فایل موجود و رفتار مشاهده‌شده، تحویل واقعی تو هستند.
ویدیوی کامل
اگر می‌خواهی روند کار و آزمون‌ها را هم ببینی، ویدیوی کامل این آموزش اینجاست:
دیدگاهتان را بنویسید
برای نوشتن دیدگاه باید وارد بشوید.