اگر امروز برای تست کردن کدهای خود به هوش مصنوعی تکیه میکنید، احتمالاً با یک دروغ سازمانیافته روبهرو هستید. وقتی یک مدل ابتدا قابلیت جدیدی را میسازد و بلافاصله تستهای متناظر با آن را مینویسد، وضعیت «سبز» یا Pass شدن تستها، یک گیت کیفیت نیست، بلکه آینهای است که پیشفرضهای غلط مدل را به خودش بازمیگرداند.
این مشکل یک نقص در مهندسی پرامپت نیست، بلکه یک خطای سیستماتیک در ارزیابی است. ادعای «تستها پاس شدند، پس ویژگی درست کار میکند» عمداً نویسندهٔ واقعی تست را پنهان میکند. اگر مدل تولیدکننده، همان کسی باشد که assertions یا همان شرطهای پذیرش را نوشته، این شرطها در واقع بر اساس برداشت مدل از نیازمندیهاست؛ بنابراین حتی یک برداشت کاملاً غلط هم میتواند منجر به یک نوار سبز شود. این رویکرد مشابه خطاهای امنیتی در عاملهای هوش مصنوعی است که در آن ثبت رضایت بهجای بررسی شواهد منجر به شکست حفاظهای امنیتی میشود.
به نقل از راهنمای فنی منتشرشده در dev.to در ۳ سپتامبر ۲۰۲۶، تیمهای توسعه بهشدت در تلهٔ این باور میافتند که پاس شدن تستها به معنای صحت عملکرد است. این گزارش اشاره میکند که مدلها تستها را طوری مینویسند که با منطق ناقص خودشان همخوانی داشته باشد. این مقاله به عنوان بخشی از تلاشهای تبلیغاتی محصول MonkeyCode تهیه شده است و خاطرنشان میکند که اگرچه میتوان پیادهسازیها را با دسترسی رایگان به مدلهای MonkeyCode پیشنویس کرد و بررسیها را روی سرور رایگان آن اجرا نمود، اما گیت نهایی باید اسکریپت اوراکل باشد، نه متن گفتگو در چت.
تصور کنید مدلی یک نیازمندی را اشتباه بفهمد. مدل بر اساس این اشتباه کد میزند و سپس تستی مینویسد که تأیید میکند آن اشتباه در کد وجود دارد. هر دو مرحله پاس میشوند، نوار سبز میشود و باگ مستقیماً به محیط عملیاتی میرود. به همین دلیل نویسنده استدلال میکند که یک گیت واقعی نیازمند یک اوراکل (Oracle) — یعنی منبع حقیقتی که مدل اجازه ویرایش آن را ندارد — است. فرآیند تولید و ارزیابی هرگز نباید مسیر دسترسی مشترک برای نوشتن داشته باشند.
پنج افسانه در ارزیابی هوش مصنوعی
- افسانه ۱: پاس شدن تستها یعنی ویژگی درست کار میکند. در واقعیت، این فقط یعنی آن تستهای خاص امروز پاس شدهاند. اگر هوش مصنوعی هر دو را نوشته باشد، صرفاً با خودش موافقت کرده است. داستان میتواند غلط باشد اما همچنان کامپایل شود. یک گیت واقعی نیازمند اوراکلی مستقل است که تولیدکننده نتواند آن را بازنویسی کند. قبل از ادغام کد بپرسید: چه کسی فایل تست را روی دیسک نوشت؟ آیا مدل میتواند آن مسیر را بازنویسی کند؟ آیا یک پیادهسازی غلط باز هم پاس میشد؟
- افسانه ۲: درصد پوشش کد (Code Coverage) معیار اطمینان است. پوشش کد فقط نقشهای از خطوط اجرا شده است، نه حکمی برای صحت. تستهای هوش مصنوعی اغلب «مسیرهای خوشبینانه» (Happy Paths) و موکهای (Mocks) دوستانه را ترجیح میدهند و روی استابهایی (Stubs) که خودشان ساختهاند، Assertion میگیرند. پوشش بالای یک تکرار مضحک (Tautology)، همچنان یک تکرار مضحک است. پوشش کد را فقط برای یافتن حفرهها به کار ببرید، نه برای سیگنال ارسال کد.
- افسانه ۳: درخواست بازبینی از خود مدل، یک Review است. کپی کردن کد در چت و پرسیدن «آیا این درست است؟» بازبینی مستقل نیست. شما از همان وزنهای عصبی برای بازخوانی همان داستان استفاده میکنید. نمونه دوم، به معنای مشخصات (Specification) دوم نیست. بازبینی باید یک برنامه با کد خروجی سخت (Hard Exit Code) باشد، نه یک متن چت.
- افسانه ۴: اجرای موفق در سرورهای رایگان، همان CI است. اجرای موفق در یک میزبان راحت، یک خط لوله (Pipeline) نیست. چت ممکن است بگوید «پاس» و سرور ممکن است چاپ کند «پاس»، اما این یک سیگنال ارسال کد نیست. بدون یک دستور ثبتشده، یک هش درخت (Tree Hash) مشخص، یک کد خروجی پردازش و یک مسیر قفلشده برای اوراکل، این فقط یک روایت است. شما باید بدانید کدام باینری اجرا شده و آیا جاب (Job) دایرکتوری منجمد اوراکل را مونت کرده است یا خیر.
- افسانه ۵: اسنپشاتهای مدل، رگرسیونها را میگیرند. اسنپشاتها ثبت میکنند چه اتفاقی افتاده، نه اینکه چه اتفاقی باید میافتاد. هوش مصنوعی میتواند باگ خودش را اسنپشات بگیرد و هفته بعد آن باگ تبدیل به استاندارد طلایی شود. در این صورت، مجموعه تستها از نقص دفاع میکنند. مقادیر مورد انتظار باید قبل از وجود هرگونه پیادهسازی، منجمد شوند. این موضوع یادآور چالشهای مربوط به پوسیدگی مجموعهدادههای طلایی در ارزیابی مدلهای عاملمحور است که در آن واقعیات پایدار جای خود را به نظرات گذرا میدهند.
پیادهسازی متد اوراکل منجمد
برای شکستن حلقه آینهای، نویسنده جداسازی سختگیرانه دایرکتوریها را پیشنهاد میکند تا مسیر نوشتن تولیدکننده از مسیر داور جدا شود. اگر هر دو مسیر باز باشند، این جداسازی صرفاً یک نمایش است. ساختار پیشنهادی پروژه به چهار بخش مجزا تقسیم میشود:
- oracle/: شامل
test_contract.py. این بخش منجمد است و مدل اجازه نوشتن در آن را ندارد. - fixtures/: نمونههای JSON تحت مالکیت انسان (مثل
cases.json) که مشخصات فنی را تعریف میکنند. - src/: تنها دایرکتوری که مدل اجازه نوشتن در آن را دارد (مثل
impl.py). - scripts/: اسکریپت اجراکننده (مثل
run_oracle.sh) که اگر دایرکتوری اوراکل قابل نوشتن باشد، عملیات را متوقف میکند (Fail Closed).
اجرای فنی و نقش Runner
برای تضمین استقلال، اسکریپت اجراکننده باید از set -euo pipefail استفاده کند و صراحتاً وجود قراردادها و fixtures را چک کند. نکته حیاتی این است که بررسی کند آیا اوراکل قابل نوشتن است یا خیر: if [ -w "$ROOT/oracle/test_contract.py" ]; then exit 2 fi. اگر مدل بتواند داور را بازنویسی کند، سیستم امتیازدهی را رد میکند.
به عنوان مثال، برای پیادهسازی یک تابع نرمالسازی ایمیل، انسان ابتدا موارد JSON را مینویسد. فایل cases.json ممکن است شامل لیستی از «ایمیلها» با ورودی "[email protected]" و خروجی "[email protected]" و لیستی از «مقادیر خالی» مانند ["", " "] باشد. سپس هوش مصنوعی فقط مأمور میشود کد پیادهسازی را در src/impl.py بنویسد.
در این ساختار، فایل test_contract.py پیادهسازی را ایمپورت کرده و روی موارد منجمد JSON پیمایش میکند. اگر مدل سعی کند تستها را برای پاس شدن «اصلاح» کند، سیستم باید تغییر را کاملاً رد کند چون دایرکتوری oracle/ فقط خواندنی است.
تست دودِ جهش (Mutation Smoke Test)
برای تأیید اینکه مجموعه تستها واقعاً کار میکنند و صرفاً «دکوراسیون» نیستند، نویسنده یک بررسی جهشی سریع را پیشنهاد میکند که باید برای هر ویژگی یکبار انجام شود. این متد در واقع پاسخی به این پرسش است که آیا تاییدیه های متوالی در کدنویسی AI نشانه کیفیت هستند یا خیر:
۱. خط پایه: اوراکل را اجرا کنید و کد خروجی را یادداشت کنید.
۲. خرابکاری در پیادهسازی: عمداً یک شاخه از کد در impl.py را خراب کنید و دوباره اجرا کنید. انتظار شکست (خروجی غیر صفر) میرود.
۳. بازگشت: کد را به حالت درخت قبلی برگردانید.
۴. خرابکاری در مشخصات: عمداً یک ردیف از cases.json را خراب کنید و دوباره اجرا کنید. باز هم انتظار شکست میرود.
اگر تستها در حین این خرابکاریها همچنان سبز بمانند، یعنی تستها هرگز رفتار کد یا مشخصات را ندیدهاند. این فرآیند تضمین میکند که داور واقعاً متهم را زیر نظر دارد.
گردش کار برای محیط عملیاتی
این توالی را کپی کنید، نه اینکه به عنوان تور محصول ببینید:
۱. ابتدا قرارداد را بنویسید (موارد JSON و دو تست شکستخورده).
۲. دایرکتوری اوراکل را قفل کنید.
۳. مسیر نوشتن مدل را فقط روی src/ تنظیم کنید.
۴. کد impl.py را با مدل تولید کنید (فقط یک تابع، بدون هیچ فایل تستی).
۵. اسکریپت run_oracle.sh را اجرا کنید و کد خروجی را بخوانید؛ خلاصه چت را نادیده بگیرید.
۶. اگر شکست خورد، کد را تغییر دهید — نه موارد یا تستها را. اگر نیازمندی جدیدی لازم است، انسان اوراکل را به صورت دستی ویرایش میکند.
جدول تصمیمگیری برای بازبینها
| سیگنال | به عنوان ... تلقی شود | به عنوان ... تلقی نشود |
|---|---|---|
| چت میگوید «همه تستها پاس شدند» | یک ادعا | یک گیت کیفیت |
| تستهای تولیدشده در همان پرامپت | یادداشت | مدرک |
| پوشش کد حاصل از این تستها | یک نقشه | معیار اطمینان |
| خروجی ۰ از اوراکل منجمد | یک گیت کیفیت | اثبات بازار-محصول |
| لاگ میزبان با دستور pytest | رکورد اجرا | CI عملیاتی |
تحلیل تحریریه و محدودیتها
این تغییر دیدگاه، کدنویسی با هوش مصنوعی را از گردش کار «چت کن و امیدوار باش» به ذهنیت «تأیید رسمی» منتقل میکند. برای توسعهدهنده کاربردی، ارزش یک ابزار هوش مصنوعی دیگر با مقدار کدی که مینویسد سنجیده نمیشود، بلکه با این سنجیده میشود که آن کد چقدر راحت توسط یک قرارداد تعریفشده توسط انسان محدود میشود.
با این حال، این متد محدودیتهایی دارد. این روش جایگزین بازبینی کد، تستهای محیط Staging، تستهای عملکرد یا ممیزیهای امنیتی نمیشود. یک اوراکل منجمد فقط به اندازه مواردی که شما نوشتید خوب است؛ موارد بد همچنان منجر به نوار سبز میشوند. علاوه بر این، دسترسی رایگان به مدلها نمیتواند نیازمندیهای فراموششده را اختراع کند و قفل کردن یک مسیر، شبکه را قفل نمیکند یا تستهای ناپایدار (Flaky) را اصلاح نمیکند.
با تبدیل مدل به یک «پیشنهاددهنده» و اسکریپت به یک «داور»، تیمها میتوانند جلوی فرسایش قضاوت انسانی را بگیرند. خطر اینجاست که با فصیحتر شدن هوش مصنوعی، توسعهدهندگان نوشتن بخشهای «کسلکننده» — یعنی موارد تست — را رها کنند؛ در حالی که اینها تنها بخشهایی هستند که تضمین میکنند نرمافزار دقیقاً همان کاری را میکند که باید. اگر نمیتوانید دو مثال را به صورت دستی بنویسید، آماده تولید پیادهسازی نیستید.
گام بعدی شما
اکنون باید PRهای فعلی خود را ممیزی کنید: بررسی کنید آیا فایلهای test_*.py در همان کامیتِ کد ویژگی ایجاد شدهاند یا خیر. از یک بررسی grep استفاده کنید: grep git diff --name-only origin/main...HEAD | grep -E '^(oracle/|test_)'. اگر این دستور مسیری را چاپ کرد، یعنی داور همراه با متهم جابجا شده است و شما از گیت استفاده نمیکنید، بلکه از یک آینه استفاده میکنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو