چرا این تست اهمیت دارد
دستیارهای کدنویسی مبتنی بر هوش مصنوعی اغلب به تیمها اجازه میدهند یک فایل «قوانین» در مخزن قرار دهند و انتظار دارند مدل در هر درخواست از دستورالعملهای آن پیروی کند. در عمل، ممکن است مدل هرگز آن فایل را نبیند، یا آن را ببیند اما محتویاتش را نادیده بگیرد. یک آزمایش اخیر با Claude Code هر دو مشکل را نشان داد. این ابزار بیصدا فایل ۷۲ کیلوبایتی AGENTS.md را نادیده گرفت؛ اما وقتی همان فایل به CLAUDE.md تغییر نام یافت، دستیار آن را بارگذاری کرد و تعداد توکنها را برای هر درخواست افزایش داد. آن بودجه اضافی توکن، باعث افزایش تأخیر (latency) و هزینه میشود و میتواند یک درخواست را از حد مجاز مدل فراتر ببرد.
توسعهدهندگانی که تصور میکنند «وجود داشتن فایل» به معنای «پیروی مدل از قوانین» است، با خطر ناکارآمدیهای پنهان و خروجیهای غیرقابل پیشبینی روبرو هستند. تست سهمرحلهای، شواهد ملموسی را در هر مرحله تحمیل میکند: پیکربندی، بارگذاری و کاربردی بودن.
سه سوالی که باید پرسید
- پیکربندیشده (Configured) – آیا فایل در جایی قرار گرفته است که دستیار به دنبال آن میگردد؟ ابزارهای مختلف مسیرها یا قراردادهای نامگذاری فایل را به صورت ثابت در کد (hard-code) تعیین میکنند؛ عدم تطابق به این معناست که فایل هرگز وارد خط لوله پرامپت (prompt pipeline) نمیشود.
- بارگذاریشده (Loaded) – آیا دستیار مدرکی ارائه میدهد که نشان دهد فایل را دریافت کرده است؟ یک هش (hash) میتواند هویت فایل را روی دیسک تأیید کند، اما تنها یک ردپای تحویل (مانند یک خط در لاگ یا تغییر در تعداد توکنها) ثابت میکند که مدل واقعاً آن را مشاهده کرده است.
- کاربردی (Useful) – آیا حضور فایل، نتیجه وظیفه را بهبود میبخشد؟ فایلی که بارگذاری شده اما توکنها را افزایش میدهد و در عین حال نتیجه را بدون تغییر باقی میگذارد، یک ضرر خالص است.
اجرای تست
این فرآیند عمداً حداقلی طراحی شده است تا بتوان آن را در هر پلتفرمی تکرار کرد.
یک قانون قابل مشاهده ایجاد کنید – یک دستورالعمل ساده و قابل مشاهده بنویسید. برای مثال: «قبل از ویرایش، دقیقاً دو فایل را لیست کن.» اثر این قانون را میتوان در پاسخ دستیار بررسی کرد.
نسخه ابزار و مدل را بررسی کنید – یک نشست (session) تازه باز کنید، رشته نسخه (version string) و شناسه مدل را یادداشت کنید. نسخههای مختلف ممکن است نام فایلهایی را که شناسایی میکنند، تغییر دهند.
دو بار اجرا کنید اجرای A: از نام فایلی استفاده کنید که ابزار آن را نمیشناسد (مثلاً
AGENTS.md). اجرای B: از نام فایل بومی ابزار استفاده کنید (مثلاًCLAUDE.md).موارد زیر را ثبت کنید:
- هش منبع فایل (برای اثبات اینکه محتوای روی دیسک تغییر نکرده است).
- مسیر دقیق استفاده شده.
- هرگونه مدرکی که دستیار در مورد بارگذاری فایل ثبت کرده است (افزایش تعداد توکن، پیام صریح "loaded X.md" و غیره).
- تعداد توکنها برای هر درخواست.
- نتیجه وظیفه (آیا دستیار دقیقاً دو فایل را لیست کرد؟).
اگر اجرای B نشان داد که از قانون پیروی شده و تعداد توکنها به میزان مورد انتظار افزایش یافته است، یعنی فایل هم بارگذاری شده و هم کاربردی است. اگر با وجود افزایش توکن، قانون نادیده گرفته شد، یعنی فایل خوانده میشود اما تجزیه پرامپت (prompt parsing) مدل، دستورالعمل را دور میاندازد. در این صورت، اضافه کردن متن بیشتر به فایل کمکی نخواهد کرد؛ در عوض، قانون را به یک دروازه سیاستگذاری ثابت (hard-coded policy gate) یا یک محیط تست (test harness) منتقل کنید.
آنچه دادهها آشکار میکنند
مورد Claude Code شکاف فاحشی را بین پیکربندی و بارگذاری نشان داد. فایل ۷۲ کیلوبایتی وجود داشت، هش درستی داشت و با مخزن همگامسازی شده بود، اما دستیار هرگز به آن ارجاع نداد. تغییر نام فایل به CLAUDE.md بومی، باعث بارگذاری شد، اما همزمان یک سربار توکن قابل توجه نیز اضافه کرد. هر توکن اضافی چرخههای محاسباتی را مصرف میکند و میتواند درخواست را از محدودیتهای نرخ (rate limits) فراتر ببرد.
تست سهمرحلهای چنین هزینههای پنهانی را پیش از آنکه به موانع تولید (production blockers) تبدیل شوند، آشکار میکند. با ثبت اختلاف توکنها (token delta)، تیمها میتوانند تصمیم بگیرند که آیا مزیت قانون از هزینه آن بیشتر است یا خیر.
نتیجهگیری
هرگز تصور نکنید که یک فایل قوانین صرفاً به دلیل حضور در مخزن، در حال انجام وظیفه است. از تست سهمرحلهای — پیکربندی، بارگذاری، اثبات کاربردی بودن — استفاده کنید تا آن فرض را به شواهد قابل اندازهگیری تبدیل کنید. وقتی شواهد نشان داد که یک فایل صرفاً یک مصرفکننده توکن (token sink) است، منطق را از پرامپت خارج کرده و به یک دروازه قطعی (deterministic gate) منتقل کنید. نتیجه، یک گردش کار کدنویسی هوش مصنوعی سبکتر، سریعتر و قابل پیشبینیتر خواهد بود.