آموزش جامع Cline و اتصال آن به API درواره در VS Code

مقدمه

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

به چنین ابزاری معمولاً Coding Agent یا عامل هوشمند برنامه‌نویسی گفته می‌شود.

در میان ابزارهایی مانند Cursor، GitHub Copilot، Claude Code، Codex، Continue و Cline، انتخاب بهترین گزینه به نیاز توسعه‌دهنده، محیط کاری، مدل مورد استفاده، سیاست امنیتی تیم و امکان اتصال به API سفارشی بستگی دارد.

برای کاربران درواره که می‌خواهند:

• داخل Visual Studio Code کار کنند
• مدل و زیرساخت API را خودشان انتخاب کنند
• از API سازگار با OpenAI استفاده کنند
• روی خواندن فایل، ویرایش و اجرای فرمان کنترل داشته باشند
• به یک Provider یا اشتراک خاص وابسته نباشند
• از قابلیت‌هایی مانند Plan، Act و MCP استفاده کنند

در حال حاضر Cline یکی از بهترین انتخاب‌های عمومی است.

در این آموزش، ابتدا Cline را از نظر فنی بررسی می‌کنیم، سپس مراحل نصب و اتصال آن به API درواره را انجام می‌دهیم. بعد از آن، با شیوه صحیح تعریف وظیفه، مدیریت دسترسی‌ها، کنترل هزینه، استفاده از MCP، رفع خطاهای اتصال و Workflow حرفه‌ای کار با Coding Agent آشنا می‌شویم.

Cline چیست؟

Cline یک Coding Agent متن‌باز است که داخل محیط‌هایی مانند Visual Studio Code اجرا می‌شود. این ابزار می‌تواند با استفاده از یک مدل زبانی، پروژه را تحلیل کند و برای انجام وظایف مهندسی نرم‌افزار از ابزارهای واقعی استفاده کند.

برای مثال، Cline می‌تواند:

• ساختار پروژه را مشاهده کند
• در فایل‌ها و پوشه‌ها جست‌وجو کند
• فایل‌های مرتبط را بخواند
• فایل جدید ایجاد کند
• کد موجود را ویرایش کند
• Diff تغییرات را نمایش دهد
• فرمان ترمینال اجرا کند
• تست‌ها، Lint و Type Check را اجرا کند
• خروجی خطاها را تحلیل کند
• اسناد فنی تولید کند
• از طریق MCP به ابزارهای خارجی متصل شود
• یک مسئله را در چند مرحله دنبال کند

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

فرض کنید از Cline می‌خواهید خطای احراز هویت یک پروژه را برطرف کند. فرایند ممکن است به شکل زیر پیش برود:

1. Cline ساختار پروژه را بررسی می‌کند.
2. فایل‌های مربوط به Authentication را پیدا می‌کند.
3. Middlewareها، Controllerها و کد مدیریت Token را می‌خواند.
4. علت احتمالی خطا را توضیح می‌دهد.
5. یک برنامه اصلاح پیشنهاد می‌کند.
6. پس از تأیید شما، فایل مربوط را تغییر می‌دهد.
7. تست‌های Authentication را اجرا می‌کند.
8. خروجی تست را می‌بیند.
9. در صورت شکست تست، Patch را اصلاح می‌کند.
10. در پایان، تغییرات و نتیجه اعتبارسنجی را گزارش می‌دهد.

این حلقه ابزارمحور، Cline را از یک دستیار متنی به یک عامل اجرایی تبدیل می‌کند.

آیا Cline بهترین ابزار کدنویسی هوش مصنوعی است؟

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

Cursor برای کاربرانی مناسب است که یک IDE یکپارچه مبتنی بر هوش مصنوعی می‌خواهند. GitHub Copilot برای تیم‌هایی که بخش عمده Workflow آن‌ها در GitHub انجام می‌شود، یکپارچگی قدرتمندی دارد. Claude Code و Codex برای کارهای Agentic و جریان‌های مهندسی مبتنی بر Terminal گزینه‌های جدی هستند.

اما اگر معیار اصلی، اتصال یک Agent فعال و متن‌باز داخل VS Code به API سازگار با OpenAI باشد، Cline انتخاب بسیار مناسبی است.

دلایل انتخاب Cline برای کاربران درواره عبارت‌اند از:

• داخل Visual Studio Code اجرا می‌شود
• پروژه‌ای متن‌باز و فعال است
• از OpenAI-compatible API پشتیبانی می‌کند
• امکان تعیین Base URL سفارشی دارد
• API Key و Model ID را می‌توان مستقل تنظیم کرد
• از مدل‌های Providerهای مختلف پشتیبانی می‌کند
• دسترسی‌های Agent قابل کنترل است
• برای عملیات حساس از کاربر تأیید می‌گیرد
• می‌تواند چند فایل را تحلیل و ویرایش کند
• امکان اجرای Terminal و تست دارد
• از MCP پشتیبانی می‌کند
• استفاده از آن وابسته به یک مدل خاص نیست

مستندات رسمی Cline نیز بخشی مستقل برای اتصال Providerهای سازگار با OpenAI ارائه کرده‌اند. این ویژگی باعث می‌شود Cline بدون نیاز به تغییر کد یا Proxy محلی به API درواره متصل شود.

مقایسه Cline با ابزارهای مهم کدنویسی

اگر هدف شما استفاده از API درواره در VS Code است، Cline نسبت مناسبی میان آزادی Provider، امکانات Agent، شفافیت و کنترل دسترسی ایجاد می‌کند.

Cline چگونه کار می‌کند؟

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

چرخه اجرای یک وظیفه معمولاً چنین است:

1. کاربر هدف را به زبان طبیعی توضیح می‌دهد.
2. Cline پیام، دستورهای پروژه و Context موجود را برای مدل ارسال می‌کند.
3. مدل تصمیم می‌گیرد چه اطلاعاتی لازم است.
4. مدل درخواست خواندن فایل، جست‌وجو یا اجرای یک ابزار را می‌دهد.
5. Cline درخواست را نمایش می‌دهد یا بر اساس تنظیمات Auto-Approve اجرا می‌کند.
6. نتیجه ابزار به مدل بازگردانده می‌شود.
7. مدل اقدام بعدی را انتخاب می‌کند.
8. چرخه تا تکمیل وظیفه یا توقف کاربر ادامه پیدا می‌کند.

این معماری دو نتیجه مهم دارد.

اول اینکه کیفیت پاسخ فقط به مدل وابسته نیست. کیفیت Prompt، فایل‌های واردشده به Context، سطح دسترسی، ساختار پروژه و خروجی ابزارها نیز بر نتیجه اثر می‌گذارند.

دوم اینکه هر مرحله ممکن است مصرف Token ایجاد کند. اگر Agent تعداد زیادی فایل بخواند یا خروجی‌های طولانی Terminal را وارد Context کند، هزینه درخواست افزایش پیدا می‌کند.

تفاوت Cline با تکمیل خودکار کد

ابزار تکمیل خودکار معمولاً چند خط اطراف Cursor را می‌بیند و ادامه کد را پیش‌بینی می‌کند. Cline می‌تواند یک هدف سطح بالاتر دریافت کند و در چند فایل اقدام کند.

به همین دلیل بهتر است Cline را جایگزین مستقیم Autocomplete ندانیم. Cline بیشتر شبیه یک همکار فنی است که می‌تواند ابزار استفاده کند، اما تمام خروجی‌هایش همچنان به بازبینی نیاز دارند.

چرا Cline برای API درواره مناسب است؟

درواره زیرساخت هوش مصنوعی و API سازگار با OpenAI ارائه می‌کند. ابزارهایی که از OpenAI-compatible API پشتیبانی می‌کنند، می‌توانند با تعیین Base URL، API Key و Model ID به آن متصل شوند.

مقادیر اصلی اتصال Cline به درواره عبارت‌اند از:

این اتصال چند مزیت مهم دارد:

• مدل را می‌توان مستقل از ابزار کدنویسی تغییر داد
• یک Endpoint استاندارد در ابزارهای مختلف قابل استفاده است
• مصرف API را می‌توان در زیرساخت درواره مدیریت کرد
• کلیدهای جداگانه برای کاربران و محیط‌ها قابل صدور هستند
• وابستگی به اشتراک داخلی یک افزونه کاهش پیدا می‌کند
• انتخاب مدل بر اساس کیفیت، سرعت و هزینه امکان‌پذیر است

پیش‌نیازهای نصب و راه‌اندازی

برای دنبال کردن این آموزش به موارد زیر نیاز دارید:

• Visual Studio Code به‌روز
• یک سیستم‌عامل پشتیبانی‌شده مانند Windows، Linux یا macOS
• حساب فعال در درواره
• API Key معتبر
• دسترسی شبکه به https://api.darvareh.ir
• یک پروژه آزمایشی یا Repository تحت Git
• آشنایی مقدماتی با Git و Terminal

بهتر است اولین آزمایش Cline را روی پروژه‌ای انجام دهید که اطلاعات حساس ندارد. همچنین قبل از شروع یک Branch جدا ایجاد کنید.

برای مثال:

git switch -c experiment/cline-setup
git status

وجود یک Commit تمیز قبل از شروع نیز باعث می‌شود Diff تولیدشده توسط Agent را راحت‌تر بررسی و در صورت نیاز بازگردانی کنید.

نصب Cline در Visual Studio Code

برای نصب از Marketplace مراحل زیر را انجام دهید:

1. Visual Studio Code را باز کنید.
2. با میان‌بر Ctrl+Shift+X پنل Extensions را باز کنید.
3. عبارت Cline را جست‌وجو کنید.
4. افزونه Cline را انتخاب کنید.
5. شناسه افزونه و ناشر را بررسی کنید.
6. روی Install بزنید.
7. پس از نصب، آیکون Cline را در Activity Bar باز کنید.

شناسه افزونه Cline در Marketplace به شکل زیر است:

saoudrizwan.claude-dev

برای نصب از Command Line نیز می‌توانید از فرمان زیر استفاده کنید:

code --install-extension saoudrizwan.claude-dev

پس از نصب، اگر پنل Cline نمایش داده نشد، Command Palette را با Ctrl+Shift+P باز و نام Cline را جست‌وجو کنید. در بعضی نسخه‌ها ممکن است Reload کردن پنجره VS Code لازم باشد.

نکات امنیتی پیش از نصب افزونه

افزونه‌های VS Code می‌توانند به Workspace، فایل‌ها و APIهای داخلی محیط توسعه دسترسی داشته باشند. بنابراین نصب افزونه یک تصمیم امنیتی است.

پیش از نصب بررسی کنید:

• افزونه از Marketplace رسمی دریافت شده باشد
• شناسه افزونه صحیح باشد
• صفحه Repository و ناشر با پروژه رسمی مطابقت داشته باشند
• افزونه جعلی با نام مشابه نصب نشود
• نسخه و تاریخ آخرین به‌روزرسانی منطقی باشد
• لینک مستندات و Source Code معتبر باشد

اگر VSIX را جداگانه دریافت کرده‌اید، آن را فقط از منبع قابل اعتماد نصب کنید.

ساخت API Key در درواره

وارد پنل درواره شوید و یک API Key اختصاصی برای Cline بسازید.

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

• مصرف Cline جداگانه قابل مشاهده است
• کلید را می‌توان بدون ایجاد اختلال در سرویس‌های دیگر ابطال کرد
• محدودیت مصرف مستقل قابل اعمال است
• رفتار غیرعادی ساده‌تر شناسایی می‌شود
• جداسازی محیط توسعه و تولید بهتر انجام می‌شود

API Key را در هیچ‌یک از مکان‌های زیر قرار ندهید:

• Repository
• فایل‌های Commit‌شده
• Issue یا Pull Request
• Screenshot
• پیام عمومی تیم
• خروجی Terminal قابل اشتراک
• مستندات عمومی
• فایل نمونه .env.example

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

دریافت فهرست مدل‌های فعال درواره

Model ID را از روی حدس یا نام بازاریابی مدل وارد نکنید. بهترین روش، دریافت فهرست مدل‌هایی است که API Key شما به آن‌ها دسترسی دارد.

در Linux یا macOS ابتدا کلید را در متغیر محیطی قرار دهید:

export DARVAREH_API_KEY="YOUR_API_KEY"

سپس Endpoint مدل‌ها را فراخوانی کنید:

curl https://api.darvareh.ir/v1/models \
  -H "Authorization: Bearer $DARVAREH_API_KEY"

پاسخ معمولاً شامل یک آرایه در فیلد data است. مقدار id هر عضو، شناسه‌ای است که باید در Cline وارد شود.

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

{
  "object": "list",
  "data": [
    {
      "id": "MODEL_ID",
      "object": "model"
    }
  ]
}

مقدار MODEL_ID را دقیقاً و بدون تغییر کپی کنید. تفاوت در حروف، خط تیره، نقطه یا پسوند نسخه می‌تواند باعث خطای Model not found شود.

اتصال Cline به API درواره

بعد از نصب Cline و ساخت API Key، وارد پنل تنظیمات Provider شوید.

مراحل کلی عبارت‌اند از:

1. پنل Cline را در VS Code باز کنید.
2. وارد Settings یا API Provider Configuration شوید.
3. در بخش API Provider گزینه OpenAI Compatible را انتخاب کنید.
4. Base URL را وارد کنید.
5. API Key درواره را وارد کنید.
6. Model ID معتبر را ثبت کنید.
7. در صورت وجود، Context Window و Max Output Tokens را تنظیم کنید.
8. تنظیمات را ذخیره کنید.

Base URL صحیح درواره:

https://api.darvareh.ir/v1

این URL را به شکل زیر وارد نکنید:

https://api.darvareh.ir/v1/chat/completions

Cline مسیر Endpoint را خودش به Base URL اضافه می‌کند. اگر مسیر کامل Endpoint را وارد کنید، ممکن است URL نهایی تکراری و نامعتبر ساخته شود.

انتخاب صحیح API Provider

در تنظیمات Cline ممکن است هم گزینه OpenAI و هم OpenAI Compatible دیده شود.

برای اتصال به درواره، گزینه زیر را انتخاب کنید:

OpenAI Compatible

گزینه ثابت OpenAI ممکن است برای Endpoint رسمی OpenAI طراحی شده باشد و در بعضی نسخه‌ها امکان تغییر Base URL را ارائه نکند.

اگر فیلد Base URL را نمی‌بینید، احتمالاً Provider اشتباه را انتخاب کرده‌اید.

تنظیم Context Window و Max Output Tokens

بعضی نسخه‌های Cline هنگام تعریف مدل سفارشی، اطلاعاتی مانند Context Window و سقف خروجی را نیز دریافت می‌کنند.

این مقادیر باید با ویژگی واقعی مدل هماهنگ باشند:

• Context Window حداکثر ظرفیت Context مدل را مشخص می‌کند
• Max Output Tokens سقف تقریبی خروجی مدل را تعیین می‌کند

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

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

آزمایش اتصال در Cline

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

برای مثال:

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

این درخواست چند موضوع را مشخص می‌کند:

• آیا اتصال به API برقرار است؟
• آیا Model ID معتبر است؟
• آیا Cline می‌تواند فایل‌ها را ببیند؟
• آیا سیستم تأیید دسترسی به‌درستی کار می‌کند؟
• آیا مدل از دستور «عدم تغییر» پیروی می‌کند؟

در اولین تعامل، اجازه ویرایش یا Terminal را بدون بررسی فعال نکنید.

آزمایش مستقیم API درواره

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

نمونه درخواست:

curl https://api.darvareh.ir/v1/chat/completions \
  -H "Authorization: Bearer $DARVAREH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MODEL_ID",
    "messages": [
      {
        "role": "user",
        "content": "فقط کلمه OK را برگردان"
      }
    ],
    "temperature": 0
  }'

مقدار MODEL_ID را با شناسه واقعی مدل جایگزین کنید.

اگر این درخواست موفق باشد اما Cline همچنان خطا بدهد، موارد زیر را بررسی کنید:

• Provider اشتباه انتخاب نشده باشد
• Base URL صحیح باشد
• Model ID دقیق وارد شده باشد
• API Key در فیلد درست قرار گرفته باشد
• نسخه Cline از مدل یا Endpoint موردنظر پشتیبانی کند
• Proxy یا Firewall درخواست افزونه را مسدود نکرده باشد

آشنایی با Plan و Act

یکی از روش‌های مؤثر کار با Cline، جدا کردن تحلیل از اجراست. در نسخه‌های مختلف ممکن است نام یا ظاهر این حالت‌ها تغییر کند، اما مفهوم آن‌ها ثابت است.

حالت Plan

در حالت Plan، Cline باید مسئله را تحلیل کند و برای اجرا برنامه بسازد. این مرحله برای خواندن فایل‌ها، شناخت معماری، شناسایی ریسک و طراحی تغییر مناسب است.

در Plan بهتر است از Agent بخواهید:

• هنوز هیچ فایلی را تغییر ندهد
• فایل‌های مرتبط را پیدا کند
• علت احتمالی مسئله را توضیح دهد
• فرض‌ها را مشخص کند
• ریسک‌ها را فهرست کند
• برنامه مرحله‌ای ارائه دهد
• معیار پذیرش پیشنهاد کند

نمونه Prompt:

علت کندی Endpoint جست‌وجو را تحلیل کن. هنوز هیچ فایل، Dependency یا Schema را تغییر نده. جریان درخواست، Queryهای دیتابیس، نقاط احتمالی N+1، فایل‌های درگیر و یک برنامه اصلاح مرحله‌ای را گزارش کن.

استفاده از Plan پیش از اجرا، احتمال تغییر اشتباه و Refactor نامرتبط را کاهش می‌دهد.

حالت Act

پس از بررسی و تأیید طرح، می‌توان وارد Act شد. در این مرحله Cline اجازه دارد تغییرات مشخص را اجرا کند.

نمونه Prompt:

فقط گام اول برنامه تأییدشده را اجرا کن. قرارداد API و Schema دیتابیس را تغییر نده. فقط فایل‌های لایه Repository و تست‌های مرتبط مجازند. پس از اعمال Patch، تست هدفمند را اجرا و Diff را خلاصه کن.

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

چرا جداسازی Plan و Act مهم است؟

اگر مستقیماً از Agent بخواهید مسئله پیچیده‌ای را حل کند، ممکن است پیش از شناخت کامل پروژه شروع به ویرایش کند.

تفکیک Plan و Act مزایای زیر را دارد:

• برداشت اشتباه زودتر شناسایی می‌شود
• فایل‌های درگیر پیش از تغییر مشخص می‌شوند
• محدوده Patch کنترل می‌شود
• هزینه اجرای اشتباه کاهش می‌یابد
• امکان اصلاح طرح پیش از ویرایش وجود دارد
• Code Review ساده‌تر می‌شود
• Agent کمتر وارد Refactorهای جانبی می‌شود

برای وظایف بسیار کوچک، این جداسازی ممکن است ضروری نباشد؛ اما برای Bugهای چندلایه، مهاجرت، Refactor و تغییرات معماری بسیار مفید است.

چگونه برای Cline یک Prompt حرفه‌ای بنویسیم؟

یک Prompt مؤثر برای Coding Agent باید حداقل پنج بخش داشته باشد:

1. هدف
2. زمینه
3. محدوده تغییر
4. محدودیت‌ها
5. معیار پذیرش

Prompt ضعیف:

لاگین را درست کن.

این دستور مشخص نمی‌کند خطا چیست، کدام بخش باید تغییر کند یا نتیجه صحیح چگونه سنجیده می‌شود.

Prompt دقیق‌تر:

هدف: خطای خروج کاربر پس از Refresh را در apps/web رفع کن.

زمینه: Frontend با Next.js و Backend با NestJS است. Access Token در حافظه و Refresh Token در Cookie امن نگهداری می‌شود.

محدوده: فقط ماژول auth در apps/web و تست‌های همان ماژول.

محدودیت‌ها: قرارداد API، Schema دیتابیس و Dependencyها را تغییر نده. از localStorage برای نگهداری Token استفاده نکن.

معیار پذیرش: بعد از Refresh، Session معتبر بازیابی شود؛ خروج کاربر همچنان Cookie را باطل کند؛ تست‌های auth و Type Check عبور کنند.

ابتدا علت را توضیح بده و منتظر تأیید برنامه بمان.

این Prompt به Agent کمک می‌کند تصمیم‌های خود را در چارچوب مشخصی بگیرد.

الگوی پیشنهادی Prompt

می‌توانید از قالب زیر برای وظایف مختلف استفاده کنید:

هدف:
[نتیجه دقیق مورد انتظار]

زمینه:
[معماری، فناوری‌ها و رفتار فعلی]

رفتار مورد انتظار:
[آنچه باید اتفاق بیفتد]

رفتار فعلی:
[آنچه اکنون اتفاق می‌افتد]

محدوده مجاز:
[فایل‌ها، پوشه‌ها یا ماژول‌های مجاز]

محدودیت‌ها:
[موارد ممنوع، الزامات امنیتی و سازگاری]

معیار پذیرش:
[تست‌ها و شرایط قابل اندازه‌گیری]

روش اجرا:
ابتدا تحلیل و برنامه را ارائه کن. تا قبل از تأیید، هیچ فایلی را تغییر نده.

مدیریت دسترسی‌های Cline

Cline برای انجام وظایف واقعی ممکن است به این قابلیت‌ها نیاز داشته باشد:

• خواندن فایل
• جست‌وجو در Workspace
• ساخت فایل
• ویرایش فایل
• اجرای Terminal
• مشاهده خروجی فرمان
• استفاده از Browser
• استفاده از MCP Server
• برقراری ارتباط شبکه‌ای

این دسترسی‌ها ارزش یکسانی از نظر ریسک ندارند.

یک ترتیب تقریبی ریسک می‌تواند چنین باشد:

1. خواندن فایل‌های غیرحساس Workspace
2. جست‌وجوی محلی
3. نوشتن فایل
4. اجرای تست شناخته‌شده
5. نصب Dependency
6. اجرای فرمان شبکه‌ای
7. تغییر وضعیت Git
8. انتشار Package
9. Migration دیتابیس
10. Deploy یا حذف فایل

هرچه عملیات به انتهای این فهرست نزدیک‌تر باشد، نیاز به تأیید و بازبینی بیشتر است.

Auto-Approve چیست؟

Auto-Approve به Cline اجازه می‌دهد بعضی عملیات را بدون درخواست تأیید جداگانه اجرا کند.

این ویژگی برای سرعت مفید است، اما اگر گسترده فعال شود، می‌تواند خطرناک باشد.

پیشنهاد اولیه:

• خواندن فایل‌های Workspace: قابل فعال‌سازی با احتیاط
• جست‌وجوی محلی: قابل فعال‌سازی
• نوشتن فایل: نیازمند تأیید
• اجرای Terminal: نیازمند تأیید
• Browser و شبکه: نیازمند تأیید
• MCP: نیازمند تأیید
• تغییر Git: نیازمند تأیید
• حذف، Deploy و Migration: همیشه دستی

فرمان‌هایی مانند موارد زیر نباید به‌صورت خودکار اجرا شوند:

rm -rf
git reset --hard
git push --force
npm publish
docker system prune
kubectl apply
terraform apply

این فرمان‌ها ممکن است تغییر برگشت‌ناپذیر یا اثر خارجی ایجاد کنند.

چرا اجرای نصب Dependency حساس است؟

فرمان‌هایی مانند npm install فقط یک Package را دانلود نمی‌کنند. آن‌ها ممکن است:

• Lockfile را تغییر دهند
• Scriptهای نصب را اجرا کنند
• کد خارجی روی سیستم اجرا کنند
• Dependencyهای Transitive اضافه کنند
• نسخه Packageهای دیگر را تغییر دهند
• آسیب‌پذیری تازه وارد کنند

اگر Cline نصب Dependency پیشنهاد کرد، بررسی کنید:

• آیا بدون Dependency جدید می‌توان مسئله را حل کرد؟
• Package فعال و نگهداری‌شده است؟
• مجوز آن با پروژه سازگار است؟
• نسخه پیشنهادی امن است؟
• حجم و Dependencyهای آن منطقی هستند؟
• تغییر Lockfile مورد انتظار است؟

بررسی Diffهای تولیدشده

هر تغییر Cline را مانند کد یک توسعه‌دهنده دیگر بررسی کنید.

پرسش‌های مهم در Code Review عبارت‌اند از:

• آیا Patch واقعاً مسئله اصلی را حل می‌کند؟
• آیا تغییرات نامرتبط وجود دارند؟
• آیا فایل‌های بیشتری از محدوده تعیین‌شده تغییر کرده‌اند؟
• آیا API یا رفتار قبلی بدون هماهنگی شکسته شده است؟
• آیا مدیریت خطا مناسب است؟
• آیا حالت‌های مرزی پوشش داده شده‌اند؟
• آیا کد جدید آسیب‌پذیری ایجاد می‌کند؟
• آیا Secret یا اطلاعات حساس وارد کد شده است؟
• آیا تست‌ها فقط برای عبور مصنوعی تغییر کرده‌اند؟
• آیا Dependency جدید واقعاً لازم است؟
• آیا Performance کاهش پیدا می‌کند؟
• آیا Migration برگشت‌پذیر است؟

عبور تست‌ها به‌تنهایی تضمین نمی‌کند که تغییر صحیح یا امن است.

مدیریت Context

Cline برای تصمیم‌گیری به Context نیاز دارد. Context می‌تواند شامل این موارد باشد:

• پیام‌های گفتگو
• دستورهای پروژه
• محتوای فایل‌ها
• Diffها
• خروجی Terminal
• نتیجه تست‌ها
• پاسخ MCP Server
• اطلاعات محیط توسعه

افزایش Context همیشه کیفیت را بهتر نمی‌کند. فایل‌های نامرتبط می‌توانند مدل را سردرگم و هزینه را بیشتر کنند.

برای مدیریت Context:

• وظیفه را کوچک نگه دارید
• مسیر دقیق ماژول را ذکر کنید
• Sessionهای نامرتبط را ادامه ندهید
• خروجی‌های طولانی را محدود کنید
• فایل‌های Build و Cache را حذف کنید
• پیش از خواندن گسترده، از Agent بخواهید فایل‌های لازم را شناسایی کند
• پس از تغییر موضوع، Session تازه ایجاد کنید
• اطلاعات قدیمی و نامرتبط را وارد مأموریت جدید نکنید

کنترل هزینه API

Agentهای کدنویسی معمولاً بیشتر از یک چت ساده Token مصرف می‌کنند، زیرا در چند مرحله با مدل ارتباط دارند.

موارد افزایش‌دهنده هزینه عبارت‌اند از:

• خواندن فایل‌های متعدد
• Context طولانی
• خروجی حجیم Terminal
• Loopهای تکراری
• اجرای چندباره تست‌های طولانی
• مدل دارای هزینه بیشتر
• Sessionهای بسیار طولانی
• ارسال فایل‌های نامرتبط
• تولید توضیحات غیرضروری

برای کاهش هزینه:

• ابتدا Plan کوتاه بخواهید
• مأموریت را به مراحل کوچک تقسیم کنید
• از مدل متناسب با پیچیدگی کار استفاده کنید
• Loop بدون پیشرفت را سریع متوقف کنید
• خروجی فرمان را محدود کنید
• فایل‌های غیرضروری را Ignore کنید
• برای کارهای مکانیکی از مدل سریع‌تر استفاده کنید
• برای Debug پیچیده سراغ مدل قوی‌تر بروید

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

استفاده از .clineignore

در نسخه‌هایی که از .clineignore پشتیبانی می‌کنند، می‌توانید فایل‌ها و پوشه‌های غیرضروری یا حساس را از دسترسی معمول Agent خارج کنید.

نمونه:

.env
.env.*
!.env.example
node_modules/
dist/
build/
coverage/
.git/
*.pem
*.key
*.log
backups/
data/private/
tmp/
.cache/

موارد مناسب برای Ignore:

• فایل‌های Secret
• کلیدهای خصوصی
• Dependencyهای نصب‌شده
• خروجی Build
• پوشه Coverage
• Logهای حجیم
• Backupهای دیتابیس
• فایل‌های تولیدشده
• داده مشتری
• فایل‌های Binary نامرتبط

.clineignore را جایگزین کنترل دسترسی سیستم‌عامل یا Secret Manager ندانید. داده بسیار حساس نباید اصولاً در Workspace قابل دسترس افزونه قرار داشته باشد.

تعریف قواعد پروژه برای Cline

اگر پروژه Convention مشخصی دارد، بهتر است آن را در فایل دستورهای پروژه یا Rules قابل استفاده Agent ثبت کنید.

قواعد مفید شامل موارد زیر هستند:

• زبان و نسخه Runtime
• Package Manager
• معماری پروژه
• مرز لایه‌ها
• Naming Convention
• فرمان Test
• فرمان Lint
• فرمان Type Check
• سیاست Migration
• روش مدیریت خطا
• استاندارد Logging
• الزامات امنیتی
• فایل‌های تولیدشده و غیرقابل ویرایش
• تعریف Done

قاعده مبهم:

کد تمیز و حرفه‌ای بنویس.

قاعده قابل آزمون:

در کد جدید TypeScript از any استفاده نکن.
قراردادهای عمومی API را بدون تأیید تغییر نده.
برای هر Bug Fix حداقل یک Regression Test اضافه کن.
پس از تغییر، pnpm lint و pnpm typecheck را اجرا کن.
فایل‌های generated را مستقیم ویرایش نکن.

هرچه قواعد دقیق‌تر و قابل سنجش‌تر باشند، نتیجه Agent قابل پیش‌بینی‌تر می‌شود.

MCP چیست؟

MCP مخفف Model Context Protocol است. این پروتکل به Agent اجازه می‌دهد از ابزارها و منابع خارجی با یک قرارداد مشخص استفاده کند.

Cline می‌تواند از طریق MCP به ابزارهایی مانند موارد زیر متصل شود:

• مستندات داخلی
• سیستم Issue Tracking
• دیتابیس
• API سازمانی
• ابزار جست‌وجو
• Browser Automation
• سرویس مانیتورینگ
• سامانه مدیریت پروژه
• ابزارهای DevOps

برای مثال، یک MCP Server می‌تواند ابزاری ارائه کند که Schema دیتابیس را بخواند یا اطلاعات یک Issue را دریافت کند.

نکات امنیتی MCP

هر MCP Server یک سطح دسترسی جدید ایجاد می‌کند. پیش از نصب یا فعال‌سازی آن بررسی کنید:

• ناشر MCP Server چه کسی است؟
• Source Code آن در دسترس است؟
• چه ابزارهایی ارائه می‌کند؟
• آیا عملیات Write یا Delete دارد؟
• به چه Credentialهایی دسترسی پیدا می‌کند؟
• آیا داده را به سرویس خارجی ارسال می‌کند؟
• آیا خروجی آن شامل اطلاعات حساس است؟
• آیا می‌توان سطح دسترسی را محدود کرد؟
• آیا عملیات آن قابل Audit است؟

برای MCPهای دارای قابلیت تغییر داده، Auto-Approve را فعال نکنید.

Workflow حرفه‌ای استفاده از Cline

برای یک Feature متوسط، فرایند زیر تعادل مناسبی میان سرعت و کنترل ایجاد می‌کند.

مرحله اول: آماده‌سازی Repository

یک Branch تازه بسازید:

git switch -c feature/example

وضعیت پروژه را بررسی کنید:

git status

تست‌های پایه را اجرا کنید:

npm test

اگر پروژه از قبل تست ناموفق دارد، آن را ثبت کنید. در غیر این صورت ممکن است Agent یک شکست قدیمی را نتیجه تغییر خودش تصور کند.

مرحله دوم: تحلیل بدون تغییر

ابتدا از Cline بخواهید فقط مسئله را بررسی کند:

این Feature را تحلیل کن. هنوز هیچ فایل یا Dependency را تغییر نده. فایل‌های مرتبط، جریان داده، محدودیت‌های معماری، ریسک‌ها و پرسش‌های باز را گزارش کن.

خروجی این مرحله را بررسی کنید. اگر Agent ماژول اشتباه را انتخاب کرده است، پیش از اجرا Context را اصلاح کنید.

مرحله سوم: ساخت برنامه اجرایی

از Cline بخواهید برنامه را به گام‌های کوچک تقسیم کند:

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

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

مرحله چهارم: پیاده‌سازی محدود

به جای اجرای کل برنامه، فقط یک گام را واگذار کنید:

فقط گام اول را اجرا کن. فایل خارج از محدوده را تغییر نده. پس از اعمال Patch متوقف شو و Diff را توضیح بده.

این روش از انباشته شدن تغییرات متعدد پیش از بازبینی جلوگیری می‌کند.

مرحله پنجم: اجرای تست

پس از تأیید Patch، تست هدفمند را اجرا کنید:

npm test -- auth

سپس در صورت نیاز تست‌های گسترده‌تر را اجرا کنید:

npm run lint
npm run typecheck
npm test
npm run build

اجرای هر چهار فرمان برای تمام تغییرات ضروری نیست. اعتبارسنجی باید متناسب با ریسک و دامنه Patch باشد.

مرحله ششم: بازبینی انسانی

مواردی که نیازمند بررسی انسانی جدی هستند:

• منطق کسب‌وکار
• امنیت Authentication و Authorization
• مدیریت Secret
• Race Condition
• Transaction دیتابیس
• Performance
• Compatibility
• Migration
• رفتار در حالت شکست
• اثر تغییر بر سرویس‌های دیگر

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

مرحله هفتم: Commit

فقط فایل‌های مرتبط را Stage کنید:

git status
git diff
git add path/to/related/files
git commit -m "fix: restore authenticated session after refresh"

از اجرای git add . بدون بررسی خودداری کنید. فایل تنظیمات شخصی، Log، Secret یا خروجی موقت ممکن است ناخواسته وارد Commit شود.

استفاده از Cline برای شناخت یک Repository جدید

Cline برای Onboarding روی پروژه‌های ناآشنا مفید است، به شرط آنکه مأموریت را محدود کنید.

Prompt پیشنهادی:

این Repository را بدون تغییر فایل‌ها تحلیل کن و موارد زیر را گزارش بده:

1. زبان‌ها و Frameworkهای اصلی
2. نقطه شروع برنامه
3. ساختار ماژول‌ها
4. جریان احراز هویت
5. ارتباط با دیتابیس
6. فرمان‌های Test، Lint و Build
7. فایل‌های پیکربندی مهم
8. ریسک‌های اولیه امنیتی
9. مسیر پیشنهادی مطالعه برای یک توسعه‌دهنده جدید

برای هر ادعا مسیر فایل مربوط را ذکر کن.

درخواست ذکر مسیر فایل باعث می‌شود خروجی قابل راستی‌آزمایی باشد.

استفاده از Cline برای رفع Bug

یک Bug مناسب برای Agent باید قابل بازتولید باشد.

اطلاعات لازم:

• رفتار مورد انتظار
• رفتار واقعی
• مراحل بازتولید
• پیام خطا
• محیط اجرا
• آخرین تغییرات مرتبط
• فایل‌های احتمالی
• محدودیت‌های اصلاح

نمونه:

در صفحه Checkout بعد از انتخاب کد تخفیف، Total در UI تغییر می‌کند اما مقدار قبلی برای API ارسال می‌شود.

مراحل بازتولید:
1. یک محصول به سبد اضافه کن.
2. کد تخفیف معتبر وارد کن.
3. روی پرداخت بزن.
4. Payload همچنان total قبل از تخفیف را دارد.

ابتدا State Flow را تحلیل کن. قرارداد API را تغییر نده. بعد از یافتن علت، یک Regression Test پیشنهاد بده و منتظر تأیید بمان.

استفاده از Cline برای Refactor

Refactor بدون تست خطرناک است. پیش از شروع مشخص کنید چه رفتاری باید ثابت بماند.

Prompt پیشنهادی:

این ماژول را برای حذف منطق تکراری Refactor کن، اما رفتار عمومی، Signature توابع و قرارداد API نباید تغییر کند.

ابتدا تست‌های موجود را شناسایی کن.
اگر پوشش کافی نیست، قبل از Refactor تست Characterization اضافه کن.
تغییرات را در گام‌های کوچک انجام بده و بعد از هر گام تست هدفمند را اجرا کن.

تست Characterization رفتار فعلی را ثبت می‌کند تا Refactor ناخواسته آن را تغییر ندهد.

استفاده از Cline برای نوشتن تست

از Cline نخواهید فقط تعداد تست‌ها را افزایش دهد. حالت‌های مهم را مشخص کنید:

• مسیر موفق
• ورودی نامعتبر
• مجوز ناکافی
• Timeout
• خطای Dependency
• داده خالی
• مقدار مرزی
• اجرای هم‌زمان
• رفتار Idempotent
• Regression مربوط به Bug

Prompt پیشنهادی:

برای تابع refreshSession تست بنویس. مسیر موفق، Refresh Token منقضی، Cookie خالی، خطای Provider و دو درخواست هم‌زمان را پوشش بده. Implementation را فقط در صورت کشف Bug واقعی تغییر بده.

انتخاب مدل مناسب برای Cline

بهترین مدل بر اساس وظیفه انتخاب می‌شود، نه فقط رتبه عمومی.

برای انتخاب مدل به این معیارها توجه کنید:

• توان استدلال
• دقت استفاده از ابزار
• توان دنبال کردن دستورهای طولانی
• کیفیت تولید کد
• کیفیت Code Review
• اندازه Context
• سرعت پاسخ
• هزینه ورودی
• هزینه خروجی
• پشتیبانی از تصویر
• پایداری در وظایف چندمرحله‌ای

برای کارهای ساده مانند مستندسازی، تغییر نام و تولید تست اولیه، مدل سریع‌تر و اقتصادی‌تر ممکن است کافی باشد.

برای کارهای زیر معمولاً مدل قوی‌تر مناسب‌تر است:

• Debug چندلایه
• تحلیل معماری
• Migration
• Refactor گسترده
• بررسی امنیتی
• تغییرات چندسرویسی
• رفع Race Condition
• تحلیل Performance

فهرست مدل‌های در دسترس را همیشه از Endpoint زیر دریافت کنید:

GET https://api.darvareh.ir/v1/models

رفع خطای 401 Unauthorized

خطای 401 معمولاً به احراز هویت مربوط است.

علت‌های احتمالی:

• API Key اشتباه است
• کلید ناقص Paste شده است
• فاصله اضافی در ابتدا یا انتهای کلید وجود دارد
• کلید ابطال شده است
• API Key در فیلد اشتباه وارد شده است
• Header احراز هویت توسط Proxy حذف می‌شود

راه‌حل:

1. کلید را با /models آزمایش کنید.
2. فاصله‌های اضافی را حذف کنید.
3. Provider را بررسی کنید.
4. در صورت تردید، کلید جدید بسازید.
5. کلید قدیمی را ابطال کنید.

رفع خطای 403 Forbidden

در خطای 403، کلید ممکن است معتبر باشد اما اجازه استفاده از مدل یا عملیات را نداشته باشد.

موارد قابل بررسی:

• مدل برای حساب فعال نیست
• محدودیت سازمانی اعمال شده است
• کلید به Scope لازم دسترسی ندارد
• حساب یا پروژه محدود شده است

یک مدل دیگر از پاسخ /models انتخاب کنید و سطح دسترسی حساب را بررسی کنید.

رفع خطای 404 Not Found

متداول‌ترین علت، Base URL اشتباه است.

مقدار صحیح:

https://api.darvareh.ir/v1

مقادیر اشتباه احتمالی:

https://api.darvareh.ir
https://api.darvareh.ir/v1/chat/completions
https://api.darvareh.ir/v1/v1

اگر Base URL صحیح است، بررسی کنید Cline کدام Endpoint را فراخوانی می‌کند.

رفع خطای Model not found

این خطا نشان می‌دهد Model ID واردشده معتبر یا قابل دسترس نیست.

راه‌حل:

curl https://api.darvareh.ir/v1/models \
  -H "Authorization: Bearer $DARVAREH_API_KEY"

مقدار id را عیناً در Cline وارد کنید. از نام نمایشی مدل استفاده نکنید.

رفع خطای 429

خطای 429 به محدودیت نرخ یا سهمیه مربوط است.

اقدامات پیشنهادی:

• مأموریت‌های هم‌زمان را کاهش دهید
• Loop بدون پیشرفت را متوقف کنید
• چند لحظه صبر کنید
• حجم Context را کاهش دهید
• وضعیت سهمیه یا محدودیت حساب را بررسی کنید
• از اجرای مکرر تست‌های طولانی جلوگیری کنید
• مدل یا سیاست مصرف مناسب‌تری انتخاب کنید

رفع Timeout

اگر درخواست Timeout می‌شود:

1. ابتدا /models را آزمایش کنید.
2. وضعیت شبکه و DNS را بررسی کنید.
3. Proxy و Firewall را کنترل کنید.
4. اندازه Context را کاهش دهید.
5. خروجی مورد انتظار را کوتاه‌تر کنید.
6. از مدل سریع‌تر استفاده کنید.
7. مأموریت را به چند بخش تقسیم کنید.

اگر /models نیز پاسخ نمی‌دهد، مشکل احتمالاً پیش از Cline و در لایه شبکه یا اتصال قرار دارد.

رفع Tool Loop

Tool Loop زمانی رخ می‌دهد که Agent یک عملیات را تکرار می‌کند اما پیشرفتی ندارد.

برای رفع آن:

• اجرای Agent را متوقف کنید
• خروجی آخر را بررسی کنید
• Session تازه بسازید
• هدف را کوچک‌تر کنید
• شرط توقف مشخص کنید
• فایل‌های مجاز را محدود کنید
• نتیجه ناموفق قبلی را صریح توضیح دهید
• Auto-Approve ابزار درگیر را خاموش کنید

نمونه اصلاح Prompt:

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

رفع Patchهای نامرتبط

اگر Cline فایل‌های نامرتبط را تغییر می‌دهد:

• Patch را تأیید نکنید
• محدوده فایل‌ها را صریح بنویسید
• ابتدا Plan بخواهید
• هر بار فقط یک گام را اجرا کنید
• Refactor جانبی را ممنوع کنید
• معیار پذیرش دقیق تعیین کنید

نمونه:

فقط فایل src/auth/session.ts و تست مستقیم آن مجاز به تغییر هستند. Formatting سراسری، تغییر Dependency و Refactor فایل‌های دیگر ممنوع است.

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

Coding Agent بخشی از زنجیره تأمین نرم‌افزار است و باید مانند سایر ابزارهای دارای دسترسی مدیریت شود.

پیشنهادهای امنیتی:

• برای هر کاربر کلید جدا صادر کنید
• کلیدهای توسعه و تولید را جدا نگه دارید
• Secret تولید را روی سیستم توسعه قرار ندهید
• Workspace مشتریان مختلف را جدا کنید
• دسترسی MCP را حداقلی نگه دارید
• عملیات Write و Delete را نیازمند تأیید کنید
• Code Review را حذف نکنید
• Dependency جدید را بررسی کنید
• Deploy را از Agent جدا نگه دارید
• مصرف API را پایش کنید
• کلیدهای بدون استفاده را ابطال کنید
• Logهای حاوی داده حساس را وارد Context نکنید

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

چه کارهایی را نباید به Cline واگذار کرد؟

Cline می‌تواند در تحلیل این وظایف کمک کند، اما نباید بدون کنترل انسانی آن‌ها را مستقل اجرا کند:

• Migration دیتابیس تولید
• Deploy مستقیم
• انتشار Package عمومی
• تغییر Infrastructure حیاتی
• حذف انبوه داده
• تغییر تاریخچه Git
• مدیریت کلیدهای تولید
• تصمیم حقوقی یا Compliance
• تغییر Authorization حساس
• عملیات مالی
• اجرای فرمان روی سرور تولید
• ارسال پیام یا ایجاد تغییر خارجی برگشت‌ناپذیر

برای چنین عملیات‌هایی، Agent باید صرفاً پیشنهاد و برنامه تولید کند و اجرای نهایی از مسیر کنترل‌شده انجام شود.

حذف Cline و پاک‌سازی تنظیمات

برای حذف افزونه:

1. پنل Extensions را باز کنید.
2. Cline را پیدا کنید.
3. روی Uninstall بزنید.
4. در صورت درخواست VS Code را Reload کنید.

از Command Line:

code --uninstall-extension saoudrizwan.claude-dev

اگر دیگر از کلید اختصاصی Cline استفاده نمی‌کنید، آن را از پنل درواره ابطال کنید. حذف افزونه به‌تنهایی تضمین نمی‌کند Credential صادرشده در Provider نیز باطل شده باشد.

همچنین فایل‌های تنظیمات محلی و Ruleهای پروژه را بررسی کنید تا اطلاعات حساس در آن‌ها باقی نمانده باشد.

پرسش‌های متداول

آیا Cline رایگان است؟

نصب و کد اصلی Cline متن‌باز است، اما استفاده از مدل می‌تواند هزینه API داشته باشد. هزینه نهایی به مدل، تعداد درخواست‌ها، اندازه Context و مراحل Agent بستگی دارد.

Base URL درواره برای Cline چیست؟

مقدار صحیح:

https://api.darvareh.ir/v1

در Cline کدام Provider را انتخاب کنیم؟

برای اتصال به درواره، گزینه زیر را انتخاب کنید:

OpenAI Compatible

Model ID را از کجا پیدا کنیم؟

از Endpoint مدل‌ها استفاده کنید:

GET https://api.darvareh.ir/v1/models

شناسه موجود در فیلد id را بدون تغییر در Cline وارد کنید.

آیا API Key را می‌توان داخل Repository ذخیره کرد؟

خیر. API Key نباید در Git، فایل عمومی، Screenshot یا مستندات ذخیره شود. برای محیط‌های خودکار از Secret Manager استفاده کنید.

آیا Cline به کل پروژه دسترسی دارد؟

Cline به Workspace بازشده و ابزارهایی که مجاز می‌کنید دسترسی دارد. از .clineignore، جداسازی Workspace و تنظیم مجوزها برای محدود کردن دسترسی استفاده کنید.

آیا فعال کردن Auto-Approve امن است؟

فعال‌سازی محدود برای عملیات خواندنی ممکن است قابل قبول باشد، اما Auto-Approve گسترده برای نوشتن فایل، Terminal، MCP، شبکه و Git توصیه نمی‌شود.

آیا Cline می‌تواند تست اجرا کند؟

بله. Cline می‌تواند با تأیید کاربر فرمان‌های تست، Lint، Type Check و Build را اجرا و خروجی آن‌ها را تحلیل کند.

آیا Cline می‌تواند چند فایل را هم‌زمان تغییر دهد؟

بله، اما برای کاهش ریسک بهتر است تغییرات بزرگ به مراحل کوچک تقسیم شوند و Diff هر مرحله جداگانه بررسی شود.

آیا Cline از MCP پشتیبانی می‌کند؟

بله. MCP امکان اتصال Cline به ابزارها و منابع خارجی را فراهم می‌کند. هر MCP Server باید پیش از فعال‌سازی از نظر منبع، دسترسی و عملیات Write بررسی شود.

چرا Cline به جای Roo Code پیشنهاد می‌شود؟

انتشار رسمی Roo Code در ۱۵ مه ۲۰۲۶ متوقف شد. Cline در زمان نگارش این مقاله فعال است و مستندات رسمی برای Providerهای OpenAI-compatible دارد.

Cline بهتر است یا Cursor؟

اگر یک IDE یکپارچه و آماده می‌خواهید، Cursor گزینه جذابی است. اگر می‌خواهید داخل VS Code بمانید و Provider و Base URL سفارشی را کنترل کنید، Cline انتخاب مناسب‌تری است.

Cline بهتر است یا GitHub Copilot؟

برای تیم‌هایی که Workflow اصلی آن‌ها در GitHub است، Copilot یکپارچگی قدرتمندی دارد. برای استفاده مستقیم از API سفارشی و کنترل Provider، Cline انعطاف بیشتری ارائه می‌کند.

آیا Cline جایگزین توسعه‌دهنده می‌شود؟

خیر. Cline سرعت تحلیل و پیاده‌سازی را افزایش می‌دهد، اما درک کسب‌وکار، تصمیم معماری، بازبینی امنیتی، ارزیابی ریسک و مسئولیت نهایی تغییرات همچنان بر عهده توسعه‌دهنده است.

جمع‌بندی

Cline یک Coding Agent متن‌باز و ابزارمحور برای Visual Studio Code است که می‌تواند Repository را تحلیل کند، فایل‌ها را تغییر دهد، Terminal را اجرا کند، تست‌ها را ببیند و وظایف مهندسی را در چند مرحله دنبال کند.

برای کاربران درواره، مزیت اصلی Cline پشتیبانی مستقیم از OpenAI-compatible API است. تنظیمات پایه اتصال عبارت‌اند از:

API Provider: OpenAI Compatible
Base URL: https://api.darvareh.ir/v1
API Key: کلید اختصاصی درواره
Model ID: شناسه دریافت‌شده از /v1/models

قدرت Cline از دسترسی آن به ابزارها می‌آید و همین قدرت، مدیریت دقیق دسترسی را ضروری می‌کند. بهترین روش استفاده از آن این است که ابتدا در Plan مسئله را تحلیل کنید، سپس تغییرات را در Act و به‌صورت مرحله‌ای اجرا کنید، Auto-Approve را محدود نگه دارید، Diffها را بررسی کنید و تست‌ها را متناسب با ریسک اجرا کنید.

Cline جایگزین مسئولیت مهندسی نیست. این ابزار زمانی بیشترین ارزش را ایجاد می‌کند که مانند یک همکار فنی سریع اما نیازمند بازبینی با آن رفتار شود.

مقالات مرتبط پیشنهادی

• بهترین مدل هوش مصنوعی برای برنامه‌نویسی در سال ۲۰۲۶
• آموزش اتصال Cursor به API درواره
• آموزش اتصال OpenCode به API درواره
• آموزش Claude Code و اتصال آن به مدل‌های هوش مصنوعی
• آموزش MCP؛ اتصال Agentهای هوش مصنوعی به ابزارها و داده‌های خارجی
• AI Coding Agent چیست و چگونه کار می‌کند؟
• آموزش Prompt Engineering برای Agentهای کدنویسی
• Context Window چیست و چگونه هزینه Coding Agentها را کاهش دهیم؟
• Tool Calling چیست؟ راهنمای استفاده از ابزارها در Agentهای هوش مصنوعی
• Loop Engineering چیست؟ روش حرفه‌ای کار با Agentهای برنامه‌نویسی
• Observability در هوش مصنوعی چیست؟ مانیتورینگ Agentها، مدل‌ها و APIها
• آموزش استفاده از API درواره با cURL و Terminal
• آموزش اتصال API درواره به Postman و آزمایش مدل‌ها بدون برنامه‌نویسی

برای شروع، یک API Key اختصاصی در درواره ایجاد کنید، فهرست مدل‌های فعال را از Endpoint زیر دریافت کنید:

https://api.darvareh.ir/v1/models

سپس Cline را در Visual Studio Code نصب و Provider را روی OpenAI Compatible تنظیم کنید. اولین مأموریت را روی یک Branch آزمایشی، در حالت Plan و با Auto-Approve محدود انجام دهید. پس از بررسی برنامه، فقط یک گام کوچک را اجرا و Diff و نتیجه تست را پیش از ادامه بررسی کنید.