اسکریپت نویسی با دستیارهای کدنویسی هوش مصنوعی

دستیارهای کدنویسی هوش مصنوعی یکی از کاربردی ترین ابزارهای جدید برای تیم های IT و DevOps هستند.

کاری که قبلا برای نوشتن یک Bash Script ساده 30 دقیقه زمان می گرفت، حالا ممکن است در چند دقیقه به یک پیش نویس قابل استفاده برسد.

اما همین سرعت یک خطر هم دارد:

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

وقتی اسکریپت قرار است روی Server، Database، Backup، Firewall یا فایل های Production کار کند، تفاوت بین «تقریبا درست» و «کاملا درست» می تواند بسیار گران باشد.

پس مدل درست استفاده از AI این نیست:

کد بده → اجرا کن

بلکه بهتر است این باشد:

نیاز → طراحی → تولید پیش نویس → Review → Test → Dry-run → اجرا

اول مسئله را دقیق تعریف کنید

Prompt ضعیف:

یک اسکریپت Bash برای Backup بنویس.

مشخص نیست:

  • چه چیزی Backup شود؟
  • Destination چیست؟
  • Retention چند روز است؟
  • Compression لازم است؟
  • اگر Disk پر شد چه شود؟
  • اگر Backup Fail شد چه شود؟
  • Log کجا ثبت شود؟

Prompt بهتر:

یک Bash Script برای Backup روزانه PostgreSQL طراحی کن.

شرایط:

  • Database روی Host دیگری است.
  • Credential باید از Environment Variable خوانده شود.
  • خروجی gzip شود.
  • فایل ها در /backup/postgres قرار بگیرند.
  • Retention برابر 14 روز باشد.
  • در صورت هر خطا Exit Code غیرصفر بدهد.
  • قبل از حذف فایل قدیمی، وجود و Writable بودن مسیر Backup را بررسی کند.
  • حالت --dry-run داشته باشد.
  • هیچ Password داخل Script نوشته نشود.

قبل از نوشتن کد، طراحی و Edge Caseها را توضیح بده.

این درخواست مدل را مجبور می کند قبل از Code Generation، به رفتار اسکریپت فکر کند.

از AI بخواهید اول Plan بدهد

برای اسکریپت های مهم، مستقیم کد نخواهید.

اول بگویید:

هنوز کد ننویس. مراحل منطقی، ورودی ها، خروجی ها، Failure Modeها و Validationها را فهرست کن.

اگر Plan مشکل دارد، اصلاح آن بسیار ارزان تر از اصلاح 200 خط کد است.

اسکریپت خوب باید Predictable باشد

در عملیات، اسکریپتی بهتر است که رفتار آن قابل پیش بینی باشد.

چند ویژگی مهم:

  • Exit Code درست
  • Log قابل خواندن
  • خطاهای واضح
  • Input Validation
  • استفاده از Timeout برای عملیات شبکه
  • عدم ذخیره Secret در کد
  • امکان Dry-run در تغییرات مهم
  • Idempotency تا حد ممکن

این موارد را مستقیما در Prompt وارد کنید.

Idempotency یعنی چه؟

یعنی اگر اسکریپت را دوبار اجرا کردید، اجرای دوم سیستم را خراب نکند یا نتیجه ناخواسته جدیدی نسازد.

مثلا اگر قرار است یک Directory بسازید، استفاده از روشی که در اجرای دوم Fail نشود بهتر است.

یا اگر قرار است یک Config Entry اضافه کنید، قبل از اضافه کردن بررسی شود که قبلا وجود نداشته باشد.

از AI بپرسید:

این Script در اجرای تکراری چه مشکلاتی ممکن است ایجاد کند؟ بخش های غیر Idempotent را مشخص کن.

این Review برای Automation بسیار ارزشمند است.

Dry-run را جدی بگیرید

اگر اسکریپت قرار است چیزی را Delete، Modify، Restart یا Deploy کند، حالت Dry-run بسیار مفید است.

مثلا:

برای این Script یک حالت --dry-run طراحی کن که تمام عملیات State-changing را فقط چاپ کند و هیچ تغییری اعمال نکند.

Dry-run جای Test Environment را نمی گیرد، اما جلوی بسیاری از اشتباه های ساده را می گیرد.

از AI برای Review کد خودش استفاده کنید

بعد از تولید کد، همان مدل یا حتی مدل دیگری را Reviewer کنید:

این Script را مثل یک Senior Linux Engineer بررسی کن.
موارد زیر را پیدا کن:

  • Risk of data loss
  • Race condition
  • مشکل Quote کردن Variableها
  • خطای Permission
  • Failure handling ناقص
  • Secret leakage
  • وابستگی به Commandهایی که ممکن است نصب نباشند
  • رفتار در اجرای مجدد

فعلا کد را بازنویسی نکن. فقط Riskها را با Severity بنویس.

این روش از «بهینه اش کن» بسیار بهتر است.

مثال: Bash Script خطرناک

فرض کنید AI اسکریپتی تولید کرده که در پایان می گوید:

rm -rf "$BACKUP_DIR"/*

ممکن است در شرایط خاص مقدار BACKUP_DIR خالی یا اشتباه باشد.

قبل از اجرای چنین دستوری باید Guard وجود داشته باشد.

از مدل بخواهید:

همه Commandهای destructive را شناسایی کن و برای هرکدام Preconditions لازم را پیشنهاد بده.

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

Script را به بخش های کوچک تقسیم کنید

برای کارهای پیچیده، از AI نخواهید یک Script هزار خطی بسازد.

کار را به Functionهای مشخص تقسیم کنید:

  • validate_environment
  • check_dependencies
  • create_backup
  • verify_backup
  • cleanup_old_backups
  • report_status

بعد هر بخش را جدا تست کنید.

این رویکرد هم Debug را ساده تر می کند و هم Review را.

برای Python هم Contract مشخص کنید

مثلا برای یک Script که API را می خواند:

ورودی: فایل CSV با ستون customer_id
خروجی: JSON Lines
اگر API پاسخ 429 داد، Exponential Backoff داشته باشد.
Timeout هر Request برابر 10 ثانیه باشد.
تعداد Retry حداکثر 3 باشد.
خطای یک Record باعث توقف کل Batch نشود.
در پایان Summary از Success/Failure چاپ شود.

هرچه Contract واضح تر باشد، Code Generation قابل اعتمادتر می شود.

PowerShell و محیط Windows

در PowerShell هم همان اصول برقرار است:

  • Scope دقیق
  • WhatIf برای عملیات قابل پشتیبانی
  • ErrorAction مناسب
  • بررسی وجود Object قبل از تغییر
  • خروجی ساخت یافته
  • Logging

از مدل بخواهید اگر Cmdlet مورد استفاده Version-specific است، آن را مشخص کند.

دستیارهای Agentic را با Permission محدود استفاده کنید

ابزارهایی که می توانند File را تغییر دهند، Command اجرا کنند یا Repo را ویرایش کنند بسیار قدرتمند هستند.

اما بهتر است Scope را محدود کنید:

  • روی Branch جدا کار کند
  • Secretها در Context نباشند
  • Commandهای خطرناک بدون تایید اجرا نشوند
  • Diff قبل از Commit بررسی شود
  • Test قبل از Merge اجرا شود

سرعت Agent زمانی مفید است که Guardrail داشته باشد.

Test را به Prompt اضافه کنید

به جای فقط «کد بنویس»، بگویید:

همراه Script یک Test Plan بده.
حداقل این حالت ها را پوشش بده:

  • ورودی معتبر
  • ورودی خالی
  • مسیر غیرقابل نوشتن
  • Dependency نصب نیست
  • Network timeout
  • اجرای مجدد

برای Python می توانید Unit Test بخواهید و برای Shell حداقل Test Scenario یا ابزارهای Lint را وارد فرایند کنید.

Lint و Static Analysis را فراموش نکنید

AI Reviewer مفید است، اما جای Toolهای قطعی را نمی گیرد.

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

  • ShellCheck برای Shell Script
  • Ruff یا Flake8 برای Python
  • Pylint در صورت نیاز
  • PSScriptAnalyzer برای PowerShell

مدل می تواند توضیح دهد خطا چیست، ولی بهتر است تشخیص Syntax و Ruleهای مشخص را Tool انجام دهد.

Secretها را وارد Chat نکنید

برای Debug یک Script، لازم نیست Token واقعی را بفرستید.

به جای:

API_TOKEN=abc123-real-secret

بنویسید:

API_TOKEN=[REDACTED]

اگر مشکل به Format Secret مربوط است، شکل آن را با نمونه جعلی توضیح دهید.

Dependencyها و Packageها را بررسی کنید

گاهی AI نام Library یا Optionی را پیشنهاد می دهد که قدیمی، اشتباه یا ناموجود است.

قبل از وارد کردن Dependency جدید:

  • وجود واقعی Package را بررسی کنید.
  • Documentation رسمی را ببینید.
  • Version Compatibility را کنترل کنید.
  • Maintenance و Security آن را بررسی کنید.

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

یک Workflow پیشنهادی برای Script نویسی با AI

  1. نیاز را در 5 تا 10 Bullet بنویسید.
  2. از AI Plan و Failure Mode بخواهید.
  3. Scope را کوچک کنید.
  4. پیش نویس کد را تولید کنید.
  5. Review امنیتی و عملیاتی بگیرید.
  6. Lint و Static Analysis اجرا کنید.
  7. در Test Environment اجرا کنید.
  8. Dry-run کنید.
  9. Diff یا خروجی را بررسی کنید.
  10. سپس وارد Production شوید.

Prompt آماده

یک Script برای این نیاز طراحی کن:
...

محیط:
...

محدودیت ها:

  • Secret داخل کد نباشد
  • Fail-fast در خطاهای حیاتی
  • Logging واضح
  • Dry-run برای تغییرات
  • تا حد ممکن Idempotent
  • Dependencyها در ابتدا بررسی شوند

ابتدا Plan، Failure Mode و Test Plan را بده.
بعد از تایید من، کد را تولید کن.

جمع بندی

دستیارهای کدنویسی AI می توانند زمان ساخت اسکریپت را به شکل چشمگیری کم کنند.

اما مزیت واقعی آنها فقط تایپ سریع تر نیست.

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

  • طراحی
  • پیدا کردن Edge Case
  • Review
  • نوشتن Test
  • توضیح Code
  • Refactor
  • Documentation

قاعده مهم:

هرچه Script به Production نزدیک تر است، سرعت تولید باید اهمیت کمتری از قابلیت بررسی داشته باشد.

AI می تواند کد را بسازد؛ شما باید مطمئن شوید کد دقیقا همان کاری را انجام می دهد که قرار بوده انجام دهد، نه چیزی که مدل فکر کرده منظور شماست.