حذف ۳۳۰ خط دستورالعمل از Claude Code؛ وقتی مدل‌ها از خطاهای قدیمی عبور می‌کنند

اگر امروز ساعت‌های زیادی را صرف نوشتن دستورالعمل‌های دقیق برای عامل‌های هوش مصنوعی خود می‌کنید، احتمالاً در حال انباشت یک بدهی فنی نامرئی هستید. باید بدانید که بسیاری از قوانینی که برای اصلاح رفتار مدل می‌نویسید، در نسخه‌های جدیدتر مدل‌ها دیگر هیچ کاربردی ندارند و فقط سرعت عمل آن‌ها را کم می‌کنند.

این وضعیت را «بدهی پرامپت» می‌نامند؛ یعنی انباشتن دستوراتی که برای رفع خطاهای قدیمی اضافه شده‌اند اما هرگز حذف نشده‌اند. توسعه‌دهنده‌ای اخیراً این هزینه را با یک اقدام جسورانه به تصویر کشید: او ۳۴۰ خط از پیکربندی‌های محیط Claude Code خود را یک‌باره حذف کرد و متوجه شد که اکثر این قوانین، در واقع وصله‌هایی برای باگ‌هایی بودند که دیگر در مدل وجود نداشتند. این پاک‌سازی کاملاً جامع بود؛ به طوری که ۹ مهارت (Skill)، ۴ قلاب (Hook) و ۶ دستور سفارشی همگی ناپدید شدند و تنها نسخه‌ای از آن‌ها در یک پوشه پشتیبان با برچسب زمانی باقی ماند.

روانشناسی حذف

حذف یک‌باره ۳۴۰ خط پیکربندی برای نویسنده شبیه به شروع یک «دوره مرگ دائمی» (Permadeath run) در بازی‌های ویدئویی بود؛ وضعیتی که در آن امیدوار است الگوهای رفتاری «غول آخر» تغییر نکرده باشد. او به مدت شش روز کامل، بدون هیچ قانونی برای هدایت عامل (Agent) کار کرد و تک‌تک شکست‌ها و خطاهای مدل را ثبت نمود. هدف این بود که کشف شود چه چیزهایی واقعاً اهمیت دارند و چه مواردی صرفاً از روی رفلکس و عادت بازگردانده می‌شوند، چون کاربر احساس می‌کند داشتن آن‌ها امن‌تر است، حتی اگر هیچ کاربرد واقعی نداشته باشند. این رویکرد ثبت دقیق خطاها برای بهبود رفتار مدل، یادآور متدهولوژی ابزار Ditto است که سعی می‌کند با کاوش در لاگ‌ها، ترجیحات برنامه‌نویسان را برای درمان فراموشی مدل‌ها استخراج کند.

این پدیده بازتابی از تغییر در جریان‌های کاری حرفه‌ای در شرکت Anthropic است. در ژانویه ۲۰۲۶، بوریس چرنی، خالق Claude Code، در مقاله‌ای در InfoQ با عنوان «نگاهی به جریان توسعه خالق Claude Code»، رویکردی به نام «مهندسی ترکیبی» (Compounding Engineering) را توصیه می‌کرد. او پیشنهاد می‌داد هر تیم در Anthropic یک فایل CLAUDE.md در گیت (git) داشته باشد. در این سیستم، چرنی مدل Claude را در درخواست‌های ادغام (PR) همکارانش تگ می‌کرد تا هر درس جدیدی که آموخته می‌شد، مستقیماً به این فایل اضافه شود. در آن زمان، فایل تیم او حدود ۲۵۰۰ توکن بود.

اما در جولای ۲۰۲۶، چرنی در جریان یک جلسه در مدرسه استارتاپی Y Combinator، توصیه‌ای کاملاً متضاد ارائه داد. او به حاضرین گفت که هر شش ماه یک‌بار همه چیز را پاک کنند. او به‌ویژه برای مدل Opus 5، این پاک‌سازی کامل را قویاً توصیه کرد. این تغییر دیدگاه با اقدامات داخلی شرکت همراه بود؛ Anthropic هنگام عرضه Opus 5، بیش از ۸۰ درصد از پرامپت سیستمی Claude Code را حذف کرد. هر دو دیدگاه چرنی درست هستند، اما برای بازه‌های زمانی متفاوتی کاربرد دارند و ثابت می‌کنند که پیکربندی‌ها «تاریخ انقضا» دارند. نویسنده اشاره کرد که ساختار او در فوریه نوشته شده بود؛ یعنی زمانی که ۳۴۰ خط قانون، به جای «بدهی»، شبیه به «نظم و انضباط» به نظر می‌رسید.

کالبدشکافی بدهی پیکربندی

این آزمایش نشان می‌دهد که هر خط در پیکربندی یک عامل را می‌توان به یکی از دو خانواده زیر تقسیم کرد که هر کدام به شکل متفاوتی پیر و منقضی می‌شوند:

• قراردادهای پروژه (Project Conventions): این‌ها قوانین دائمی مربوط به پشته فناوری (Tech Stack) هستند. برای مثال: تعیین استفاده از pnpm، ذکر اینکه Clerk مسئول احراز هویت است، یا بیان اینکه Supabase صرفاً برای ذخیره فایل‌های Blob است و هیچ چیز دیگری نباید به آن دست بزند. این قوانین تنها زمانی منقضی می‌شوند که معماری کلی پروژه تغییر شکل دهد.
• وصله‌های رفتاری (Behavior Patches): این‌ها اصلاحات موقتی هستند که در روزی که مدل دچار شکست می‌شود، نوشته می‌شوند. نمونه‌هایی مانند دستور «تست‌ها را بازنویسی نکن» یا «قبل از پیشنهاد تغییرات، حتماً ابزار Glob را فراخوان».

وصله‌های رفتاری منشأ اصلی اتلاف منابع هستند. این‌ها دقیقاً در لحظه‌ای منقضی می‌شوند که مدل دیگر آن اشتباه خاص را مرتکب نشود؛ اتفاقی که معمولاً در نسخه بعدی مدل رخ می‌دهد. از آنجایی که در فایل‌های مارک‌داون برای این خطوط هیچ برچسب تاریخی، نام نویسنده یا دلیل نوشتن ثبت نشده است، آن‌ها اغلب تا ابد باقی می‌مانند. یکی از خوانندگان این وضعیت را «داربست‌هایی برای نقاط ضعفی که دو نسخه پیش از بین رفته‌اند» توصیف کرد؛ داربست‌هایی که در هر فراخوانی، بودجه متنی (Context) را می‌سوزانند.

مطالعه موردی: ابزار Glob

برای درک بهتر، قانون ابزار Glob را بررسی کنید. نویسنده این قانون را در آوریل ۲۰۲۶ اضافه کرد، زیرا مدل Opus 4.7 در اجرای دستورات به طرز عجیبی بیش از حد تحت‌اللفظی عمل می‌کرد. یک درخواست ساده برای «بررسی ساختار پروژه»، به یک بازنویسی اجباری تبدیل شد: «شما باید (MUST) ابزار Glob را فراخوانید» تا رفتار مورد نظر مدل اعمال شود.

وقتی کاربر به Opus 5 مهاجرت کرد، آن قانون همچنان باقی ماند. نویسنده هرگز بازنگرد تا بررسی کند که آیا Opus 5 هنوز به آن هل دادن نیاز دارد یا خیر. قانون صرفاً آنجا نشست، در هر گام (Turn) مجدداً خوانده شد و بودجه دستورات را برای باگی مصرف کرد که احتمالاً مدت‌ها پیش مرده بود. هر وصله مرده‌ای که بدون پرسش باقی بماند، دقیقاً همین اتفاق را در پس‌زمینه تکرار می‌کند.

پروتکل حذف (Ablation Protocol)

برای پاک‌سازی این بدهی فنی، نویسنده یک پروتکل سخت‌گیرانه را پیشنهاد می‌کند که به جای شهود، بر پایه «ثبت وقایع» (Logging) استوار است. در اینجا، ابزار اصلی نه فایل پیکربندی، بلکه فایل گزارشات است.

• پشتیبان کامل: همه چیز را در یک پوشه با تاریخ ذخیره کنید. نویسنده هشدار می‌دهد که نداشتن وضعیت ذخیره‌شده (Save state) جایی است که «فیلم‌های ترسناک شروع می‌شوند، نه آزمایش‌های علمی».
• برش لایه‌ای: همه چیز را یک‌باره حذف نکنید، به‌ویژه در کدهای محیط تولید (Production). ترتیب حذف باید چنین باشد:
  1. ابتدا مهارت‌ها (Skills) و قلاب‌ها (Hooks).
  2. سپس دستورات سفارشی.
  3. در مرحله سوم، خود فایل CLAUDE.md.
  4. حفاظ‌های امنیتی (Security Guardrails) تا آخرین لحظه حفظ شوند.
• ردیابی معیارها: از پیش تصمیم بگیرید چه چیزی را اندازه بگیرید، وگرنه هیچ چیز اندازه نخواهید گرفت. نویسنده سه معیار خاص را ردیابی کرد:
  1. تعداد اصلاحات دستی در هر جلسه.
  2. دفعات توضیح مجدد زمینه‌هایی که عامل باید از پیش می‌دانست.
  3. حوادث واقعی به همراه شدت (Severity) آن‌ها.
• تست گسترده: این فرآیند حذف را حداقل برای چندین روز اجرا کنید. یک جلسه واحد می‌تواند گمراه‌کننده باشد؛ برای مثال در روز دوم هیچ چیز نمی‌شکست و نویسنده نزدیک بود این «نویز» را با «سیگنال» اشتباه بگیرد و در مورد نتایج دچار غرور کاذب شود.

نتایج بازیابی

پس از شش روز کار عادی، یافته‌ها غافلگیرکننده بود. بخش «ترسناک» یعنی حفاظ‌های امنیتی، یک قمار نبودند. قوانینی که مانع از اجرای rm -rf توسط عامل، Push مستقیم به شاخه اصلی (main)، یا دست زدن به فایل .env می‌شدند، بلافاصله دوباره اضافه شدند. این‌ها خطوطی هستند که یک‌بار می‌نویسید و امیدوارید هرگز مجبور به تست استرس آن‌ها نشوید، زیرا هزینه یک «منفی کاذب» (False Negative) در امنیت، دائمی است و چیزی نیست که برای داشتن یک فایل تمیزتر، روی آن قمار کنید.

سایر عناصر با ترتیب خاصی از نظر ضرورت بازگشتند:

• قراردادهای استنباطی: قوانینی که مدل نمی‌توانست از روی کد حدس بزند، زودتر بازگشتند. برای مثال، این حقیقت که یک کوئری Convex نمی‌تواند یک Mutation را فراخوانی کند و باید از طریق یک Action عبور کند، چیزی است که مدل نمی‌تواند صرفاً با نگاه کردن به کدبیس بفهمد؛ بدون این قانون، مدل مدام حدس‌های غلط می‌زند.
• وصله‌های رفتاری: تقریباً هیچ‌کدام از این‌ها بازنگشتند. مدل‌ها به سادگی از آن خطاها عبور کرده و رشد کرده بودند.

در نهایت، از ۳۴۰ خط اولیه، تنها ۱۱ خط باقی‌ماند. این موضوع یک آستانه جدید را تعریف کرد: یک خط تنها زمانی اجازه بازگشت به پیکربندی دارد که حداقل دو بار شکست یکسان در گزارشات ثبت شده باشد. شکست‌هایی که تنها یک‌بار در لاگ ظاهر شدند، هرگز تکرار نشدند و بنابراین نادیده گرفته شدند.

استراتژی‌های مستقل از مدل (Model-Agnostic)

نویسنده اعتراف می‌کند که برخی از آن ۱۱ خط باقی‌مانده ممکن است بر اساس «احساس راحتی» باشند تا ضرورت واقعی. بدون یک تست دقیق A/B خط‌به‌خط، ممکن است چند خط صرفاً به این دلیل باقی مانده باشند که حذف آن‌ها حس بدتری نسبت به نگه داشتنشان داشت. علاوه بر این، آستانه «دو بار شکست» مختص یک مدل در یک محیط خاص است.

از آنجایی که Anthropic عامل‌ها را با محیط‌های تست خودش آموزش می‌دهد، فایل CLAUDE.md ممکن است هنگام خوانده شدن توسط مدل‌های دیگر، رفتار متفاوتی داشته باشد. برای حل این مشکل، نویسنده به یک فایل عمومی‌تر به نام AGENTS.md مهاجرت کرده و CLAUDE.md را به عنوان یک لینک نمادین (Symlink) به آن متصل کرده است. این کار یک پیکربندی مستقل از مدل ایجاد می‌کند که در Grok، Codex و Claude Code قابل استفاده باشد. با این حال، باید توجه داشت که حتی با استفاده از چنین ساختارهایی، قواعد متنی AGENTS.md همیشه نمی‌توانند توهمات عامل‌های هوش مصنوعی را به‌طور کامل متوقف کنند و نیازمند بازبینی مستمر هستند.

با این حال، هنوز تایید نشده است که آن ۱۱ خط باقی‌مانده برای سه مدل مختلف معنای یکسانی دارند یا خیر. این عدم قطعیت، در کنار این حقیقت که زوال (Decay) پیکربندی طبق یک برنامه زمانی قابل پیش‌بینی پیش نمی‌رود، باعث شد نویسنده تست حذف بعدی را در تقویم خود ثبت کند.

برای توسعه‌دهندگان، این بدان معناست که یک فایل پیکربندی بیش از حد بزرگ، نشانه نظم نیست، بلکه نوعی بدهی فنی است که سرعت عامل را می‌گیرد و توکن‌ها را می‌سوزاند. کلید کار این است که به پیکربندی به عنوان یک آرشیو دائمی نگاه نکنید و آن را به عنوان یک پل موقت به سوی نسخه بعدی مدل ببینید.

گام بعدی شما

• فایل‌های پیکربندی عامل‌های خود را بازبینی کنید و هر قانونی که برای نسخه‌های قدیمی مدل نوشته شده را حذف کنید.
• یک سیستم ثبت وقایع (Log) برای خطاهای مدل ایجاد کنید تا بفهمید کدام دستورات واقعاً اثرگذار هستند.
• هر ۶ ماه یک‌بار، یک «روز پاک‌سازی» برای حذف دستورات تکراری و تاریخ‌گذشته در نظر بگیرید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.