اگر از Claude Code برای اجرای مجموعههای تست رگرسیون استفاده میکنید، احتمالاً میدانید که اتمام ناگهانی توکنها میتواند کل فرآیند را در نیمه راه متوقف کند. برای جلوگیری از این اتفاق، باید مدیریت وضعیت (State Management) را به اولویت اول خود تبدیل کنید. این مطلب، بخش سوم از مجموعهای با عنوان «اتوماسیون Playwright با Claude Code» است که پس از بخش اول (راهاندازی) و بخش دوم (مقایسه Playwright CLI با MCP) میآید. در آن مقایسه قبلی، تفاوت تقریباً ۹۰,۰۰۰ توکنی بین MCP و CLI در یک تست کاملاً یکسان مشاهده شد که ثابت کرد انتخاب ابزار، یک اهرم اصلی برای بهرهوری است.
با تکیه بر پوششهای قبلی ما در مورد نحوه عیبیابی شکستهای عامل توسط «چرخش واگرایی» (Divergence Turn)، واضح است که جریانهای کاری عاملمحور (Agentic Workflows) مستعد تورم دادهای هستند. بهینهسازی این جریانها میتواند منجر به جهشی در بهرهوری شود؛ چنانکه در تحلیلهای ما از رویکردهای استدلالمحور، سرعت بازبینی کد با Claude تا ۳ برابر افزایش یافت. طبق گزارش منتشرشده، مدیریت نادرست حافظه در این جریانها — شبیه به میز کاری است که بیش از حد شلوغ شده و حالا کاربر برای پیدا کردن یک برگه ساده، باید زمان و انرژی زیادی صرف کند — باعث کند شدن مدل و افزایش هزینهها میشود. هنگام نوشتن مجموعههای تست پیچیده (مثلاً تستهایی با بیش از ۱۵ فرم)، تجمع وضعیتهای غیرضروری سرعت مدل را کاهش داده و منابع را تلف میکند. همانطور که در تحلیل قبلی ما اشاره شد، هرچه پیچیدگی تعامل با مدل بیشتر شود، ریسک خطا و اتلاف منابع افزایش مییابد. این موضوع بهخصوص برای کاربرانی که بر اساس میزان مصرف API هزینه پرداخت میکنند و نه اشتراکهای ماهانه ثابت، حیاتی است؛ چرا که توکنهای تلفشده مستقیماً به صورت صورتحسابهای سنگینتر و پاسخهای کندتر باز میگردند، زیرا Claude باید برای یافتن رشتههای مرتبط در یک زمینه شلوغ، سختتر تلاش کند.
اهمیت مدیریت توکنها
عادات کوچک در طول یک روز کاری، تأثیرات تکمیلی بزرگی دارند. بدون مدیریت آگاهانه، نشستهای طولانی بهسرعت به سقف محدودیتهای پنجره زمینه (Context Window) — یعنی میزان متنی که مدل همزمان در ذهن نگه میدارد، مثل میز کاری که جای چند ورق دارد نه کل کتابخانه — میرسند. در این راستا، باید مراقب حجم دادههای ورودی بود، زیرا فایلهای تنظیمات بیش از حد حجیم میتوانند منجر به نادیده گرفته شدن دستورات کلیدی Claude Code شوند. به همین دلیل، توسعهدهندگان باید در استفاده از دستورات /clear و /compact برای پاکسازی فعالانه حافظه عامل مسلط باشند تا از برخورد سریع با محدودیتهای زمینه جلوگیری کنند.
بر اساس مستندات این راهنما، موثرترین روش برای صرفهجویی در توکنها، محدود کردن دقیق دامنه (Scope) هر وظیفه است. بهجای اینکه از مدل بخواهید «کل برنامه را بررسی و هر چه یافتی تست کن»، توسعهدهندگان باید اهداف دقیق تعیین کنند. برای مثال، یک پرامپت بهینه تر این خواهد بود: «فرم ورود در مسیر /login را تست کن: حالتهای اعتبار درست، رمز عبور خالی و رمز عبور اشتباه».
با ارائه دستورالعملهای محدود شده، توسعهدهنده تضمین میکند که عامل (Agent) — مانند کارمندی که فقط روی یک پرونده خاص تمرکز کرده — تنها صفحات و المانهای مرتبط با آن فرم خاص را لمس کند. این کار از ثبت عکسهای (Snapshots) غیرضروری و پیمایش مسیرهای بیربط جلوگیری میکند. اگر بررسی گسترده مورد نیاز است، این کار باید به عنوان یک گام متفکرانه و مجزا تعریف شود، مثلاً: «ابتدا تمام فرمهای این صفحه را لیست کن»، و نباید با درخواست اصلی تست ترکیب شود.
جزئیات مدیریت نشستها
برای حفظ سلامت نشستها، این راهنما دستورات خاصی را برای کنترل خروجیهای خام ابزارها و تاریخچه گفتگو توصیه میکند:
- /clear: از این دستور هنگام جابهجایی بین وظایف غیرمرتبط استفاده کنید (مثلاً انتقال از تستهای ورود به جریان پرداخت). این دستور تاریخچه عکسها، خروجیهای ابزار و چرخشهای گفتگوی مربوط به وظیفه قبلی را که دیگر مرتبط نیستند، کاملاً پاک میکند.
- /compact: برای وظایفی که در طولانیمدت روی یک ویژگی واحد اجرا میشوند، کاربرد دارد. این دستور بهجای حذف کامل وضعیت، گفتگوهای صورت گرفته را خلاصه میکند تا تداوم منطقی حفظ شود بدون اینکه تمام خروجیهای خام ابزارها به همراه آورده شوند.
علاوه بر پرامپتها، بهینهسازی محیط اجرا پیشنهاد میشود. توسعهدهندگان باید بهصورت پیشفرض از حالت مرورگر بدون رابط گرافیکی (Headless) استفاده کنند. نشستهای Headed (مرئی) برای عیبیابی فعال مفید هستند، اما معمولاً باعث تشویق عامل به عکسبرداریهای اکتشافی بیشتر و تکرارهای رفتوبرگشت میشوند. تنها زمانی به حالت Headed تغییر وضعیت دهید که یک تست واقعاً شکست خورده باشد و نیاز داشته باشید دلیل بصری آن را مشاهده کنید.
مقیاسپذیری با اسکریپتها و مهارتها
نویسنده برای منطقهای تکرارپذیر، توصیه میکند که کار را به اسکریپتها یا «مهارتها» (Skills) منتقل کنید. اگر توسعهدهنده متوجه شود که مراحل یکسانی (مانند جریان استاندارد ورود به سیستم) را در چندین نشست مختلف توضیح میدهد، آن منطق باید در یک اسکریپت قرار گیرد.
- ذخیرهسازی مهارت: این موارد را در فایلهایی مانند
.claude/skills/playwright-form-tester/SKILL.mdذخیره کنید. - بهرهوری هزینه: خروجی یک اسکریپت توکن مصرف میکند، اما منطق تولیدکننده آن خیر. مراحل قطعی (Deterministic) در قالب یک اسکریپت، به مراتب ارزانتر از دستوراتی هستند که مدل باید هر بار درباره آنها استدلال و فکر کند.
- بارگذاری زمینه: یک مهارت تنها زمانی در زمینه بارگذاری میشود که واقعاً مرتبط باشد، که این امر تضمین میکند شما در حین انجام وظایف غیرمرتبط، هزینه توکنهای آن را پرداخت نمیکنید.
در نهایت، این گزارش بر یک پیکربندی حیاتی در CI تأکید میکند: پین کردن (تثبیت) نسخههای ابزار. استفاده از دستوری مانند npm install -g @playwright/[email protected] از تغییرات رفتاری خاموش و ناگهانی که با تگ @latest همراه است، جلوگیری میکند. بهروزرسانیهای بالادستی میتوانند رفتار سیستم را در میانه خط لوله تغییر دهند و باعث اجرای مجدد (Retry) شوند؛ در حالی که هر اجرای مجدد، توکنها را دوبار مصرف میکند. برای هر دو مورد Playwright CLI و باینریهای مرورگر، نسخههای صریح را پین کنید.
برای یک توسعهدهنده، این به معنای تغییر ذهنی از رویکرد «چت کردن» به رویکرد «مدیریت نشست» است. اثر ثانویه این تغییر، طولانیتر شدن پنجره زمینه است که اجازه میدهد مجموعههای عظیم تست رگرسیون بدون اینکه مدل پیشنیازهای قبلی را فراموش کند یا به دلیل محدودیت توکن کرش کند، به پایان برسند.
گام بعدی شما
- دستور
/compactرا در پایان هر تسک کوچک اجرا کنید تا حافظه مدل بهینه شود. - تمامی توالیهای تکراری تست را به فایلهای
.claude/skillsمنتقل کنید. - نسخههای Playwright و مرورگرها را در فایل lock پروژه دقیقا پین (Pin) کنید.
این مدیریت بهینه فقط بخشی از معادله است؛ اثر مستقیم انتخاب ابزار بر هزینه توکنها را در تحلیل ما درباره مقایسه MCP و CLI مشاهده کنید.
گفتگو