تصور کنید در میانه یک بازنویسی پیچیده هستید و هر ۱۰ دقیقه باید تمرکز خود را برای پاسخ به یک پیام ناقص در ترمینال رها کنید. این «خستگی عامل» (Agent Fatigue) نه از ضعف توانایی مدل‌ها، بلکه از ماهیت تعاملی محیط‌های خط فرمان ناشی می‌شود که چرخه بازخوردی عصبی ایجاد کرده و تمرکز عمیق را نابود می‌کند. این وضعیت زمانی رخ می‌دهد که توسعه‌دهندگان از ابزارهای خودمختاری مانند Claude Code یا Aider استفاده می‌کنند و به جای پیشبرد پروژه، در تله‌ی واکنش‌های لحظه‌ای می‌افتند.
همان‌طور که در تحلیل قبلی ما درباره‌ی ساخت گردش‌کارهای هوش مصنوعی بدون نقشه‌های راه سازمانی اشاره کردیم، این تغییر عادت در واقع جایگزینی برای «استراحت‌های کوتاه زمان کامپایل» است. در گذشته، زمان کامپایل فرصتی برای تفکر بود، اما اکنون توسعه‌دهندگان به‌جای دنبال کردن یک مسیر خطی از تفکر، خود را در حالی می‌بینند که برای پر کردن زمان اجرای یک عامل، بین ۶ یا ۷ تسک مختلف در تب‌های مختلف مرورگر جابه‌جا می‌شوند تا احساس بهره‌وری کنند.
روان‌شناسی خستگی عامل
کار با عامل‌های هوش مصنوعی (AI Agents) — شبیه داشتن دستیاری است که هر لحظه از شما تایید می‌خواهد و اجازه نمی‌دهد به فکر فرو بروید — به این دلیل فرسایشی است که زمان اجرای کند آن‌ها ما را به چندوظیفگی (Multitasking) وسوسه می‌کند. طبق گزارشی که در ۳۱ اوت ۲۰۲۶ در وب‌سایت dev.to منتشر شد، وقتی یک عامل ۵ یا ۱۰ دقیقه در حال اجراست، میل شدید به «بهره‌ور بودن» باعث می‌شود تب‌های جدید باز کنیم و خروجی‌های ترمینال را با اضطراب دنبال کنیم.
این وضعیت یک حلقه واکنشی ایجاد می‌کند. چون ترمینال تعاملی است، ما با آن مثل یک اپلیکیشن چت در لحظه رفتار می‌کنیم و احساس می‌کنیم باید فوراً به پاسخ‌های ناقص، کدهای نصفه یا حتی توهمات مدل واکنش نشان دهیم. در این حالت، ما دیگر معمار نرم‌افزار نیستیم، بلکه به مدیران پرامپت تبدیل شده‌ایم که فقط به خروجی‌های لحظه‌ای واکنش نشان می‌دهند و کنترل کلی سیستم را از دست می‌دهند. این چالش در واقع وجه دیگری از مدیریت تعامل با مدل‌هاست؛ موضوعی که در بررسی تفاوت‌های مهندسی دستی پرامپت در برابر مدل‌های بازارمحور به تفصیل به آن پرداختیم.
راهکار پیشنهادی برای خروج از این چرخه، اتخاذ گردش‌کار «اول Markdown» است. در این روش، پاسخ‌های فوری و تکانشی در ترمینال با یک فایل یادداشت محلی (Scratchpad) با پسوند .md در محیط IDE جایگزین می‌شود تا تفکر از اجرا جدا شود.
مکانیسم فایل یادداشت (Scratchpad)
به جای تایپ پرامپت‌های پیچیده و طولانی مستقیماً در محیط CLI، توسعه‌دهنده ابتدا تمام نیازها، تحلیل‌ها و ایده‌های خود را در یک فایل می‌ریزد. این بافر ذهنی اجازه می‌دهد فرآیند توسعه به‌جای واکنش، به‌صورت آگاهانه پیش برود:
- تحلیل خروجی: ثبت دقیق آنچه عامل به‌درستی به‌روزرسانی کرده و مواردی که فراموش شده است. برای مثال، یادداشت اینکه عامل اعتبارسنجی توکن را اصلاح کرد اما پاک‌سازی پایگاه‌داده توکن‌های منقضی‌شده را نادیده گرفت.
- دستورالعمل‌های ساختاریافته: پیش‌نویس گام‌های بعدی به‌صورت آفلاین. مثلاً درخواست صریح برای اضافه کردن یک تابع پاک‌سازی خودکار در مسیر
cron/cleanup.goدر حالی که منطق میان‌افزار (Middleware) فعلی بدون تغییر باقی بماند. - تداوم زمینه: ثبت هدف نهایی مهندسی و نقشه راه تسک، تا توسعه‌دهنده در طول اجراهای طولانی و خسته‌کننده، رشته افکار و جایگاه خود را در پروژه گم نکند. این تداوم برای جلوگیری از پوسیدگی زمینه و افزایش بازدهی عامل‌های کدنویسی حیاتی است.
انتقال به گردش‌کار جدید
برای اجرای این روش، توسعه‌دهندگان می‌توانند فایل یادداشت را مستقیماً در دستورات ارجاع دهند (مثلاً با دستور claude-code -f scratchpad.md) یا بخش‌های ساختاریافته را کپی و در ترمینال پیست کنند. نویسنده مقاله توصیه می‌کند برای جلوگیری از ورود این یادداشت‌های شخصی و پیش‌نویس‌های ذهنی به تاریخچه پروژه و Git، عبارت *.scratchpad.md یا یک پوشه اختصاصی به نام .prompts/ به فایل .gitignore اضافه شود تا این بافرهای شناختی در مخزن کد ذخیره نشوند.
این رویکرد به‌طور عمدی سرعت ظاهری توسعه را کم می‌کند. با اجبار به نوشتن چند پاراگراف تفکر قبل از هر بار اجرا، توسعه‌دهنده از فرستادن عامل‌ها به مسیرهای اشتباه ناشی از توهم (Hallucination) — شبیه وقتی که یک دوست با اطمینان خاطره‌ای را اشتباه تعریف می‌کند — جلوگیری می‌کند؛ مسیرهای غلطی که عیب‌یابی آن‌ها ممکن است ۳۰ دقیقه زمان ببرد و تمرکز را کاملاً نابود کند.
مقایسه دو رویکرد
برای مهندس مدرن، این تغییر بنیادین است؛ تبدیل شدن از یک مدیر پرامپت واکنشی به یک معمار سیستم. در واقع، این روش توهم سرعت را با واقعیتِ دستورالعمل‌های کنترل‌شده و با زمینه (Context) بالا معاوضه می‌کند.
- اول ترمینال: سریع، واکنشی و اضطراری است. بار شناختی بسیار بالایی دارد زیرا جابه‌جایی مداوم زمینه و تمرکز شکننده (به دلیل حواس‌پرتی توسط لاگ‌های اجرا) را تحمیل می‌کند. خروجی‌ها اغلب نامنظم هستند و بر اساس آزمون و خطای تکراری پیش می‌روند.
- اول Markdown: متأملانه، آفلاین و کنترل‌شده است. بار شناختی را کاهش می‌دهد زیرا یک «منبع واحد برای حقیقت» (Single Source of Truth) ایجاد می‌کند. تمرکز عمیق بر معماری سیستم حفظ می‌شود و نتیجه آن، دستوراتی ساختاریافته و دقیق است. این نوع نظم‌دهی به فرآیندها، مشابه برخی از گردش‌کارهای اتوماسیون AI است که برای جایگزینی وظایف تکراری طراحی شده‌اند.
در حالی که رویکرد اول ترمینال سریع به نظر می‌رسد، اما وضعیت شکننده تمرکز عمیق را به خطر می‌اندازد. در مقابل، جایگزین Markdown-first از این تمرکز محافظت کرده و نظم ذهنی را برقرار می‌کند.
اگر از تلاطم مداوم لاگ‌های عامل‌های هوش مصنوعی احساس فرسودگی می‌کنید، سعی کنید پیچیده‌ترین مهاجرت دیتابیس یا بازسازی کد (Refactor) بعدی خود را در یک فایل یادداشت اختصاصی مدیریت کنید. مشاهده کنید وقتی واکنش لحظه‌ای به صفحه نمایش را متوقف می‌کنید، توانایی شما در تحلیل معماری چگونه بهبود می‌یابد.
گام بعدی شما
- یک فایل
dev_notes.mdدر ریشه پروژه ایجاد کنید و تمام نیازمندی‌های تسک فعلی را پیش از اجرای عامل در آن بنویسید. - در دستورات ابزارهایی مثل Claude Code یا Aider، مستقیماً به این فایل ارجاع دهید تا مدل زمینه کامل‌تری داشته باشد.
- فایل‌های یادداشت را در
.gitignoreقرار دهید تا از شلوغ شدن مخزن کد جلوگیری شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو