Aider AI چیست؟ آموزش نصب و کدنویسی امن با Agent ترمینال و Git

وقتی برای یک تغییر چندفایلی بین Editor، مستندات، Terminal و Git جابه‌جا می‌شوید، بخش مهمی از زمان صرف انتقال Context می‌شود. Aider این چرخه را در Terminal جمع می‌کند: فایل‌های لازم را به گفتگو اضافه می‌کنید، هدف را توضیح می‌دهید، Agent تغییر را اعمال می‌کند و نتیجه در Git قابل مشاهده و بازگشت است.

در این راهنما Aider را به‌صورت ایزوله نصب می‌کنیم، Repository را آماده می‌سازیم، مدل را بدون قراردادن Secret در فرمان انتخاب می‌کنیم و یک تغییر واقعی را با Ask Mode، Code Mode، Diff، Lint و Test پیش می‌بریم. هدف فقط اجرای ابزار نیست؛ می‌خواهیم Workflowی بسازیم که خروجی آن قابل توضیح و قابل Review باشد.

Aider AI چیست؟

Aider یک ابزار AI Pair Programming در Terminal است. می‌تواند روی فایل‌های محلی Repository کار کند، Context مرتبط را از Repo Map بگیرد، Diff ایجاد کند و تغییرهای خود را با Git Commit ثبت کند. مدل زبانی از Provider انتخابی می‌آید و Aider لایه تعامل میان مدل، فایل‌ها و Git است.

Aider یک IDE کامل یا مدل مستقل نیست. شما همچنان Editor دلخواه را نگه می‌دارید و می‌توانید Aider را در Terminal داخلی VS Code یا محیط جدا اجرا کنید. مزیت اصلی، انتخاب صریح فایل، فرمان‌های داخل گفتگو و History قابل بررسی Git است.

Aider برای چه کارهایی مناسب است؟

• رفع Bug با فایل‌ها و Testهای مرتبط
• Refactor محدود که چند Module را درگیر می‌کند
• افزودن Test برای رفتار موجود
• توضیح Codebase در Ask Mode پیش از ویرایش
• به‌روزرسانی مستندات هم‌زمان با تغییر کد
• اجرای Linter و Test و اصلاح خطای قابل تکرار

برای Migration حساس، عملیات Production، تغییر Permission یا Repository فاقد Test، Agent نباید بدون کنترل مستقیم عمل کند. کار بزرگ را به Taskهای کوچک تقسیم و هر مرحله را مستقل Review کنید.

تفاوت Aider با Agentهای IDE

هیچ‌کدام ذاتاً بهتر نیستند. اگر Terminal و Commit کوچک بخش اصلی کار شماست، Aider اصطکاک کمی دارد. اگر Diff تعاملی و Context بصری IDE مهم‌تر است، Agent داخل Editor شاید مناسب‌تر باشد.

پیش‌نیازهای نصب Aider

Python سازگار، Git و یک Repository آزمایشی آماده کنید. مستندات رسمی روش aider-install را برای نصب جدا پیشنهاد می‌کنند و روش uv یا pipx نیز Dependencyهای ابزار را از پروژه جدا نگه می‌دارد. پیش از هر نصب، نسخه Python و Git را بررسی کنید.

python --versiongit --versiongit statusgit switch -c feature/aider-demo

Branch جدا باعث می‌شود Diff خروجی با کار قبلی مخلوط نشود. اگر Working Tree از قبل تغییر دارد، ابتدا مالکیت آن تغییرها را مشخص کنید؛ Agent نباید فایل کار نیمه‌تمام همکار را بازنویسی کند.

نصب ایزوله Aider

روش پیشنهادی مستندات، نصب بسته aider-install و اجرای Installer است. این روش محیط جدا ایجاد می‌کند و در صورت نیاز Python مناسب را نیز فراهم می‌کند.

python -m pip install --upgrade aider-installaider-installaider --versionaider --help

اجرای مستقیم Script دانلودشده با Pipe کوتاه است اما فرصت Review را کم می‌کند. در محیط سازمانی، Package و Hash را طبق سیاست Supply Chain بررسی و از Registry و مستندات رسمی استفاده کنید. Package مربوط به ابزار aider-chat است؛ نام‌های مشابه را با دقت بررسی کنید.

نصب با uv یا pipx

اگر uv یا pipx در Workflow تیم وجود دارد، نصب Tool با آن‌ها جداسازی خوبی ایجاد می‌کند. نسخه را ابتدا در محیط آزمایشی بسنجید و سپس Lock یا فرایند Upgrade کنترل‌شده داشته باشید.

uv tool install --force --python python3.12 --with pip aider-chat@latest# Alternative:pipx install aider-chataider --version

اتصال مدل بدون افشای API Key

Aider از Providerها و مدل‌های متعدد پشتیبانی می‌کند. API Key را در History Shell، Screenshot، Issue یا فایل Commitشده نگذارید. متغیر محیطی را در Secret Store سیستم یا Session امن تنظیم کنید و فقط نام مدل را به فرمان بدهید. فایل env اگر استفاده می‌شود باید در gitignore باشد و Permission محدود داشته باشد.

مستندات امکان دادن Key در Command Line را نیز نشان می‌دهند، اما این مقدار می‌تواند در History یا فهرست Process دیده شود. برای استفاده روزمره، Environment امن بهتر است. در CI از Secret Store همان پلتفرم استفاده کنید و Log را Redact کنید.

اگر مدل محلی می‌خواهید، آموزش نصب Ollama در ویندوز را ببینید. مدل محلی باید توان مناسب برای Edit Format و Context پروژه داشته باشد؛ کوچک‌بودن مدل ممکن است Diffهای ضعیف یا ناقص ایجاد کند.

شروع Aider در Repository

از ریشه Repository اجرا کنید و فقط فایل‌های لازم را در شروع بدهید. Aider می‌تواند با Repo Map ارتباط Symbolها را بفهمد، اما اضافه‌کردن بی‌هدف صدها فایل Context را شلوغ و هزینه را بیشتر می‌کند.

cd path/to/projectgit statusaider --model provider/model src/profile.js test/profile.test.js

عبارت provider/model را با نام مستندشده Provider خود جایگزین کنید. پس از شروع، Prompt وضعیت Git، مدل و فایل‌های داخل Chat را نشان می‌دهد. اگر Repository اشتباه است یا فایل حساس اضافه شده، ادامه ندهید.

دستورهای اصلی داخل Chat

نام و رفتار Optionها ممکن است با نسخه تغییر کند؛ راهنمای همان نسخه را مرجع قرار دهید. برای Action حساس تنها به Undo تکیه نکنید و Branch و Backup معتبر داشته باشید.

Ask-to-Code: اول بفهم، بعد تغییر بده

Ask Mode برای تحلیل بدون ویرایش است. ابتدا از Aider بخواهید مسیر درخواست، Validation موجود و Testهای اثرپذیر را توضیح دهد. سپس Plan را اصلاح و در Code Mode اجرای محدود بخواهید.

/ask مسیر update profile و validation موجود را توضیح بده./ask فایل‌های لازم و edge caseهای نام کاربر را فهرست کن./code فقط validation نام و تست‌های آن را پیاده‌سازی کن.Schema دیتابیس و قرارداد سایر فیلدها را تغییر نده.

معیار پذیرش دقیق باشد: نام خالی رد شود، Boundary طول تست شود، Contract خطا حفظ شود و Testهای قبلی سبز بمانند. Prompt مبهم مانند «کد را حرفه‌ای کن» دامنه تغییر را باز می‌گذارد.

Git در Workflow Aider

Aider تغییرهای خود را Commit می‌کند تا History روشن و Undo ممکن باشد. پس از هر مرحله git show و git diff را مستقل از توضیح Agent بخوانید. Commit کوچک باید یک Intent داشته باشد؛ تغییر Format گسترده را با Bug Fix مخلوط نکنید.

git status --shortgit show --stat --oneline HEADgit show --word-diff HEADgit diff --check HEAD~1 HEADnpm testnpm run lint

/undo برای آخرین تغییر مفید است، اما قبل از استفاده بررسی کنید آیا بعد از آن کار دستی انجام داده‌اید. دستور بازگشت نباید تغییر کاربر را ناخواسته حذف کند. Git History را منبع حقیقت قرار دهید.

Lint و Test خودکار

Aider می‌تواند Linter یا Test را پس از Edit اجرا کند و خطا را برای اصلاح بعدی بخواند. فرمان باید همان Script شناخته‌شده پروژه باشد. Agent نباید برای سبزکردن Test، Assertion را ضعیف یا Test را Skip کند.

بهترین نتیجه از ترکیب شواهد می‌آید: Test هدفمند، Suite مرتبط، Lint، Build و Review انسانی. اگر Test جدید نوشته شد، یک بار Failure کنترل‌شده بسازید تا مطمئن شوید Test به رفتار مورد نظر حساس است.

پیکربندی بدون Secret

گزینه‌های عمومی مانند مدل، فرمان Lint یا Convention را می‌توان در فایل تنظیم قرار داد؛ API Key را در Repository Commit نکنید. فایل Configuration در Home، ریشه Git و Directory جاری قابل بارگذاری است و فایل نزدیک‌تر می‌تواند مقدار قبلی را Override کند؛ هنگام Debug منشأ نهایی Option را بررسی کنید.

Conventionهای پروژه را در فایل متنی جدا نگه دارید و فقط Read کنید: Naming، ساختار Error، فرمان Test و ممنوعیت Migration. قانون امنیتی مهم را علاوه بر متن در CI و Permission نیز اعمال کنید، چون Prompt Enforcement قطعی نیست.

ریسک‌های امنیتی

افشای Context و Secret

فایل env، Private Key، Log حاوی Token و Dump دیتابیس را به Chat اضافه نکنید. اگر Secret ناخواسته ارسال شد، حذف Transcript کافی نیست؛ Credential را Rotate و Audit کنید.

Prompt Injection

README، Issue، Comment یا صفحه وب می‌تواند جمله‌ای داشته باشد که Agent را به خواندن Secret یا اجرای فرمان نامرتبط دعوت کند. محتوای Repository داده است، نه مجوز. هر دستور حساس را با Goal کاربر تطبیق دهید.

Dependency و فرمان مخرب

قبل از نصب Package، نام، Registry و ضرورت آن را بررسی کنید. فرمان حذف Recursive، تغییر Permission، Push، Deploy یا اتصال Production را در Session عادی تأیید نکنید. از Container یا حساب کم‌دسترسی استفاده کنید.

خطاهای رایج

چک‌لیست استفاده امن

1. Repository و Branch درست را تأیید کنید.
2. Baseline تست پیش از تغییر ثبت شود.
3. فقط فایل‌های لازم به Chat اضافه شوند.
4. Secret در Prompt، فرمان و Config Commitشده نباشد.
5. در Ask Mode Scope و Plan مشخص شود.
6. هر Commit و Diff مستقل Review شود.
7. Dependency جدید دلیل و منبع معتبر داشته باشد.
8. Lint، Build و Test واقعی اجرا شوند.
9. هیچ Deploy یا Push خودکار بدون کنترل انجام نشود.
10. خروجی نهایی در Pull Request بررسی انسانی شود.

برای مقایسه Workflow ترمینالی دیگر، راهنمای Codex CLI در ویندوز و آموزش GitHub Copilot CLI را مطالعه کنید.

جمع‌بندی

Aider Pair Programming را به Terminal و Git می‌آورد. انتخاب محدود فایل، Repo Map، Chat Modeها، Commit خودکار و فرمان‌های Test چرخه‌ای شفاف برای تغییر کد می‌سازند. کیفیت نهایی همچنان به Prompt دقیق، مدل مناسب و Review توسعه‌دهنده وابسته است.

از Repository آزمایشی و Task کوچک شروع کنید. ابتدا در Ask Mode Codebase را بفهمید، سپس در Code Mode تغییر محدود بخواهید و Git Diff را خودتان بخوانید. سرعت Agent زمانی ارزشمند است که قابلیت بازگشت و شواهد آزمون کنار آن باشد.

یک Bug کوچک با Test قابل تکرار انتخاب کن، فایل‌های مرتبط را به Aider بده و چرخه Ask، Code، Diff و Test را روی یک Branch آزمایشی اجرا کن.

منابع رسمی

• Aider Documentation
• Installation
• Usage
• Chat modes
• API Keys
• YAML config file
• Optional setup