بیشتر برنامه‌نویسان هنگام کار با ایجنت‌های هوش مصنوعی درگیر چرخه‌ای فرسایشی می‌شوند: خطایی رخ می‌دهد، در پنجره‌ی چت به مدل تذکر می‌دهند، مشکل موقتاً برطرف میشود، اما در پروژه‌ی بعدی یا حتی اجرای بعدی همان خطا دوباره تکرار میشود. تکیه بر چت برای اصلاح رفتار ایجنت مثل تمیز کردن آب نشتی بدون بستن شیر اصلی است.
در این درس یاد می‌گیرید که چگونه به اصلاحیه‌ها نه به چشم ضعف در پرامپت‌نویسی، بلکه به عنوان داده‌هایی ارزشمند برای بهبود ساختار مهندسی نگاه کنید. با ارتقای این بازخوردها به لایه‌هایی مثل تست‌های خودکار، سیاست‌های دسترسی و ابزارهای اعتبارسنجی، سیستم شما به‌صورت خودکار و برگشت‌ناپذیر باکیفیت‌تر میشود.
این تمرین‌ها به هیچ پردازش سنگین یا زیرساخت ابری نیاز ندارند و مستقیماً روی رایانه‌ی شخصی و درون مخزن کد قابل پیاده‌سازی و ردیابی هستند.
اصلاحیه‌ای که فقط در محیط چت باقی بماند، صرفاً همان یک اجرا را درست میکند؛ اما اصلاحیه‌ای که به یک تست، مرز مشخص، مثال یا ابزار ارتقا یابد، تمام اجراهای بعدی را بهبود می‌بخشد.
اهداف یادگیری
- تبدیل اصلاحیههای ایجنت به سازوکارهای کنترلی پایدار؛
- قرار دادن هر کنترل در نخستین لایه‌ای که توانایی پیشگیری از تکرار خطا را دارد؛
- حذف درس‌آموخته‌های تکراری با استفاده از اثرانگشت‌های پایدار (Stable fingerprints)؛
- کنار گذاشتن کنترل‌هایی که دیگر در برابر ریسکی واقعی محافظت نمی‌کنند.
اصلاحیه‌ها شواهد هستند
وقتی به ایجنت می‌گویید «آن فایل را ویرایش نکن»، پی برده‌اید که مرز دامنه (Scope boundary) در عمل قابل‌اجرا نبوده است. وقتی می‌گویید «قالب این خروجی اشتباه است»، متوجه شده‌اید که جای یک مثال یا تست خالی بوده است. وقتی راه‌اندازی محیط دوباره شکست می‌خورد، یاد می‌گیرید که دانش مربوط به محیط باید بخشی از اتوماسیون باشد.
به اصلاحیه به چشم مشاهده‌ای درباره‌ی سیستم کاری نگاه کنید، نه ضعفی در مهارت پرامپت‌نویسی.
ارتقا به نخستین لایه‌ی اثربخش
از این اولویت‌بندی استفاده کنید:
| خطای تکرارشونده | مقصد پایدار |
|---|---|
| نتیجه‌ی نادرست یا پسرفت (Regression) | تست یا ارزیابی |
| اقدام خارج از دامنه یا ناامن | سیاست دامنه یا دسترسی |
| اشتباه تکراری در راه‌اندازی یا اجرای دستورها | اتوماسیون یا ابزار |
| اشتباه تکراری در قالب خروجی | مثال معیار (Canonical) به‌همراه اعتبارسنج |
| ابهام در قواعد و قراردادهای محلی | دستورالعمل همراه با بررسی سناریو |
| عدم توافق بر سر منطق محصول | سند ثبت تصمیم‌های انسانی |
هرچه لایه‌ی کنترلی جلوتر باشد، کم‌هزینه‌تر است. نوع داده‌ای (Type) که مانع از ایجاد وضعیت نامعتبر میشود، قوی‌تر از کامنت کدریویویی است که بعداً آن را کشف میکند. یک تست متمرکز بسیار کارآمدتر از پاراگرافی است که از ایجنت می‌خواهد فلان نکته را به خاطر بسپارد.
ثبت چرخ‌دنده‌ای (The Ratchet Record)
این موارد را ثبت کنید:
- نشانه (Symptom)؛
- ریشه‌ی خطا (Root cause)؛
- پیامد؛
- تعداد دفعات تکرار؛
- کنترل انتخاب‌شده؛
- اعتبارسنجیِ کنترل؛
- مسئول؛
- تاریخ بازبینی یا کنار گذاشتن آن.
هر ترجیح سلیقه‌ای و گذرا را به کنترل تبدیل نکنید. اصلاحیه را فقط زمانی ارتقا دهید که تکرار یا پیامد آن، پیچیدگیِ ماندگار در سیستم را توجیه کند.
تفکیک علت از نشانه
جمله‌ی «ایجنت فایل README را ویرایش کرد» یک نشانه است. علل احتمالی عبارت‌اند از:
- در تعریف تسک، دسترسی به ریشه‌ی مخزن (Repository) مجاز بوده است؛
- مستندات به‌طور ضمنی امن و مجاز فرض شده بودند؛
- در برنامه‌ریزی، پیاده‌سازی و مستندسازی در قالب یک مرحله در هم ادغام شده بودند؛
- دامنهی اختیارات دو مجری با یکدیگر هم‌پوشانی داشته است.
هر علت نیازمند کنترل متفاوتی است. قانونی که صرفاً همان نشانه را بازگو کند، در مواجهه با موردِ بعدی که اندکی تفاوت دارد شکست خواهد خورد.
کنترل‌ها هم فرسوده می‌شوند
کنترل‌های قدیمی می‌توانند دچار تعارض شوند، کانتکست را بیهوده سنگین کنند و برای سیستمی مانع بسازند که دیگر وجود خارجی ندارد. هر قاعده‌ای که ارتقا می‌یابد باید سازوکاری برای بازنشستگی داشته باشد. آن را حذف یا بازنویسی کنید هرگاه:
- معماری زیرساخت تغییر کرده باشد؛
- یک کنترل اجرایی قوی‌تر جایگزین آن شده باشد؛
- خطا در یک بازه‌ی زمانی معنادار دیگر رخ نداده باشد؛
- اصطکاکی که کنترل ایجاد میکند بیشتر از ریسکی باشد که جلویش را می‌گیرد.
هدف، نوشتن طولانی‌ترین فایل دستورالعمل نیست؛ هدف رسیدن به جمع‌وجورترین سیستمی است که قضاوت‌های سخت‌به‌دست‌آمده را حفظ کند.
پیاده‌سازی عملی
این کارگاه، اصلاحیه‌ها را دسته‌بندی میکند، آن‌ها را به کنترل ارتقا می‌دهد، موارد تکراری را بر اساس اثرانگشت مشخص میکند و خروجی را در outputs/feedback-ratchet.json می‌نویسد.
اجرا کنید:
python3 code/main.py
python3 -m unittest discover code/tests -vدو اصلاحیه با بیان متفاوت اما علتی یکسان اضافه کنید. نرمال‌سازی را تا جایی بهبود دهید که این دو مورد، بدون ادغام خطاهای نامرتبط، در قالب یک کنترل ادغام شوند.
تمرین‌ها
- پنج مورد از اصلاحیههای جلسات کدنویسی اخیر خود را بردارید و مسئول واقعی هر یک را مشخص کنید.
- یکی از قواعد متنی را با تستی قابل‌اجرا جایگزین کنید.
- وزن‌دهی بر اساس پیامد را اضافه کنید تا رخداد نخستِ یک خطای شدید بلافاصله ارتقا یابد.
- مسئول و تاریخ بازنشستگی را به خروجی کارگاه اضافه کنید.
- یکی از دستورالعمل‌های فعلی ایجنت را بررسی کنید و تنها پس از اثبات وجود کنترلی قوی‌تر، آن را حذف کنید.
برای مطالعه‌ی بیشتر
- Basili, Caldiera, and Rombach, The Goal Question Metric Approach، برای تبدیل اهداف به پرسش‌ها و سنجه‌های عملیاتی.
- Shinn et al., Reflexion، برای استفاده از ردگیری محاسبات (Trace) بازخوردها جهت بهبود تصمیم‌های بعدی، بدون دست‌کاری در وزن‌های مدل.
- Madaan et al., Self-Refine، برای بازخورد و اصلاح مکرر درون حلقه‌ی انجام کار.
خروجی این درس
فایل outputs/feedback-ratchet.json را نگه دارید؛ این فایل نقطه‌ی پایانیِ پایدار در مسیر «مهندسی به کمک ایجنت» و ورودیِ تغییرات بعدی محیط کاری شماست.