دستیار تکمیل کد چند خط پیشنهاد میدهد و شما Tab میزنید. ایجنت کدنویسی یک جمله از شما میگیرد، ده فایل را میخواند، شش فایل را تغییر میدهد، تستها را اجرا میکند و میگوید «تمام شد». اگر درست پیش برود، کار یک ساعته در چند دقیقه انجام شده است. اگر نه، با تغییری بزرگ روبهرو هستید که نمیدانید از کجا شروع به خواندنش کنید.
ایجنت کدنویسی ابزاری است که با گرفتن یک هدف، خودش فایلهای پروژه را میخواند، تغییر میدهد و دستورهایی مثل اجرای تست را اجرا میکند. فرق نتیجهی خوب و بد معمولاً در مدل نیست، در روال کار است. اگر با مفهوم ایجنت آشنا نیستید، اول ایجنت هوش مصنوعی چیست را بخوانید.
ایجنت کدنویسی دقیقاً چه کار میکند؟#
با چهار ابزار کار میکند: خواندن فایل، جستجو در پروژه، ویرایش فایل و اجرای دستور در ترمینال. با همینها، در حلقهی فکر و عمل و مشاهده، باگ پیدا میکند، ویژگی اضافه میکند یا تست مینویسد.
سه شکل رایج دارد:
| شکل | کجا کار میکند | مناسب برای |
|---|---|---|
| داخل ویرایشگر کد | روی پروژهی باز در ویرایشگر | کارهای کوچک و متوسط با نظارت لحظهای |
| در ترمینال | روی پوشهی پروژه، با دستورهای خط فرمان | کارهای چندفایلی، اجرای تست و ابزارهای پروژه |
| پسزمینه یا ابری | روی کپی مخزن در محیط جدا | کارهای مشخص که نتیجهشان یک درخواست ادغام است |
قبل از اولین اجرا، پروژه را چطور آماده کنیم؟#
با گیت تمیز، شاخهی جدا، تست قابلاجرا و محیطی که کلید واقعی در آن نیست:
- وضعیت گیت تمیز باشد. قبل از شروع هیچ تغییر ثبتنشدهای نمانده باشد.
- شاخهی جدا بسازید. اگر کار خراب شد، کل شاخه را کنار میگذارید.
- تستها اجرا شوند. ایجنت با تست میفهمد کارش درست است یا نه؛ پروژهی بدون تست یعنی همهی بار بازبینی روی شما.
- محیط محلی با دادهی آزمایشی. فایل
.envبا کلید واقعی و اتصال به دیتابیس اصلی در دسترس ایجنت نباشد. - فایل دستورالعمل پروژه. بیشتر ابزارها یک فایل متنی در ریشهی پروژه را میخوانند؛ بعضی فایلی مثل
AGENTS.mdو بعضی فایل مخصوص خودشان. دستور اجرای تست، قواعد نامگذاری و پوشههایی را که نباید دست بخورند آنجا بنویسید.
git status
git switch -c agent/fix-discount-total
php artisan testبه ایجنت چه سطح دسترسی بدهیم؟#
خواندن آزاد، ویرایش و اجرای تست با فهرست مجاز، و هر کار برگشتناپذیر فقط با تأیید شما. ابزارهای جدی چند حالت دسترسی دارند، از «قبل از هر کاری بپرس» تا «هر کاری خواستی بکن». حالت دوم سریعتر است، ولی:
| کار | پیشنهاد |
|---|---|
| خواندن فایلهای پروژه | آزاد |
| ویرایش فایل در پوشهی پروژه | آزاد یا با تأیید، بسته به اعتمادتان |
| اجرای تست و ابزار بررسی کد | آزاد، با فهرست دستورهای مجاز |
| نصب بستهی تازه | با تأیید |
| مایگریشن، حذف فایل، بازنویسی تاریخچهی گیت | همیشه با تأیید |
| هر چیزی مربوط به سرور اصلی یا انتشار | نه |
اگر ایجنت را از راه MCP به ابزارهای دیگری مثل دیتابیس یا مخزن کد وصل میکنید، همین قاعده آنجا هم صدق میکند: فقطخواندنی، مگر وقتی واقعاً لازم است.
روال امن یک کار با ایجنت چیست؟#
چهار قدم: اول برنامه، بعد تغییر در قدمهای کوچک، بعد بازبینی تغییرها، و در آخر ثبت کوچک در گیت.
۱. اول برنامه، بعد تغییر#
هدف: جمع کل سفارش وقتی کد تخفیف درصدی دارد اشتباه حساب میشود؛ علت را پیدا کن.
فعلاً هیچ فایلی را تغییر نده. فقط:
۱. فایلهای مرتبط را بخوان و بگو علت احتمالی چیست.
۲. برنامهی تغییر را قدمبهقدم بنویس و بگو کدام فایلها عوض میشوند.
۳. بگو کدام تست خطا را نشان میدهد یا چه تستی باید اضافه شود.
فایلهای تست موجود را بدون اجازه تغییر نده.اگر ایجنت علت را اشتباه فهمیده، اینجا ارزانترین جای اصلاح است، نه بعد از تغییر شش فایل.
۲. تغییر در قدمهای کوچک#
بعد از تأیید برنامه، بخواهید قدمبهقدم پیش برود و بعد از هر قدم تستها را اجرا کند. اگر تست قرمز ماند و ایجنت چند بار پشتسرهم همان راه را امتحان کرد، متوقفش کنید و خودتان نگاه کنید.
۳. بازبینی تغییرها#
گزارش «تمام شد» را باور نکنید؛ خود تغییرها را ببینید:
git diff --stat
git diff -- tests/
git diff -- composer.json composer.lockدستور دوم نشان میدهد تستها عوض شدهاند یا نه، و دستور سوم نشان میدهد بستهی تازهای اضافه شده یا نه.
۴. ثبت کوچک#
هر کار کامل را جدا ثبت کنید. ثبتهای کوچک هم بازبینی را ساده میکنند و هم برگشت را.
ایجنتها معمولاً کجا اشتباه میکنند؟#
جایی که هدف یا محدوده مبهم است، و جایی که «سبز شدن تست» جای «درست شدن کد» را میگیرد:
| اشتباه | نشانه | پیشگیری |
|---|---|---|
| تغییر تست بهجای رفع علت | تست سبز شده ولی فایل تست هم عوض شده | منع در دستور؛ بازبینی جداگانهی تستها |
| تابع یا بستهی خیالی | خطای «تعریفنشده» یا بستهی ناآشنا | اجرای تست؛ بررسی هر بستهی تازه |
| تغییرهای بیربط | اصلاح قالببندی یا نامها در فایلهای دیگر | محدودهی روشن در دستور |
| نادیده گرفتن قواعد پروژه | کد درست ولی ناهمخوان با بقیه | فایل دستورالعمل پروژه |
| جاافتادن امنیت | ورودی بدون اعتبارسنجی، خروجی بدون escape | بازبینی امنیتی جداگانه |
برای مورد آخر، بازبینی کد با هوش مصنوعی کمک میکند، ولی جای چشم شما را نمیگیرد.
نکتههای وردپرس و لاراول#
- وردپرس: در هر فرم و درخواست AJAX که ایجنت میسازد، nonce، بررسی دسترسی با
current_user_canو escape خروجی را چک کنید. اجازه ندهید هستهی وردپرس یا افزونهی دیگران را ویرایش کند؛ تغییرها فقط در افزونهی خودتان یا پوستهی فرزند. - لاراول: مایگریشنها را خطبهخط بخوانید و دستوری مثل
migrate:freshرا فقط روی دیتابیس آزمایشی اجازه دهید. اگر فایلهایconfigیاroutesتغییر کرد، دلیلش را بپرسید. تجربههای بیشتر در هوش مصنوعی در پروژهی لاراول.
این موضوع به کجا میرود#
ایجنتهای کدنویسی کارهای طولانیتر را مستقلتر انجام میدهند و بیشتر در پسزمینه یا روی چند کار همزمان اجرا میشوند. نتیجه این است که سهم برنامهنویس از «نوشتن» به «تعریف دقیق کار و بازبینی» جابهجا میشود و تست خودکار و بررسی خودکار پیش از ادغام، از یک کار خوب به یک پیشنیاز تبدیل میشوند.
برای آمادگی:
- پوشش تست پروژههایتان را بالا ببرید و از بخشهای حساس مثل پرداخت شروع کنید.
- یک فایل دستورالعمل پروژه بنویسید و مثل کد بهروزش نگه دارید.
- خواندن سریع و دقیق diff را تمرین کنید؛ این مهارت ارزشمندتر از قبل میشود.
خلاصه#
- ایجنت کدنویسی فایل میخواند، تغییر میدهد و دستور اجرا میکند؛ روال کار از خود مدل مهمتر است.
- گیت تمیز، شاخهی جدا، تست قابلاجرا و محیط بدون کلید واقعی.
- اول برنامه بگیرید و تأیید کنید، بعد تغییر در قدمهای کوچک.
- تغییرها را با
git diffببینید، بهخصوص تستها و بستههای تازه. - کارهای برگشتناپذیر و هر چیزی مربوط به سرور اصلی همیشه با تأیید شما.