‏پنج عادت برای کار گرفتن از Claude Opus 5.5 در تسک‌های طولانی

مشکل اصلی ایجنت‌های کدنویسی تو کارهای طولانی context saturation هست، یعنی وقتی گفتگو طولانی می‌شه، مدل باید تصمیم‌ها و فایل‌های زیادی رو یادش بمونه و آخر کار کیفیتش افت می‌کنه. به گفتهٔ این مقاله، همین مشکل با Opus 5.5 هم دیده شده: شروع قوی، بعد فراموش کردن تصمیم‌های قبلی. راه‌حل پیشنهادی تنظیم مدل نیست، طراحی جریان کاره: هر تکه از کار باید اون‌قدر کوچیک باشه که context هر ایجنت قابل‌مدیریت بمونه.

عادت اول پرامپت کوتاه هست. نویسنده می‌گه وقتی قدم‌به‌قدم می‌نویسی چی کار کنه، عملکرد ایجنت رو به برنامهٔ خودت محدود می‌کنی. Opus 5.5 تو خوندن کد و پیدا کردن ترتیب درست کار قویه. مثلاً تو ساخت PandaCode (یه اپ دسکتاپ برای اجرای ایجنت‌های کدنویسی)، قابلیت «ادامه بعد از ریست محدودیت» فقط با یه پرامپت سه‌جمله‌ای ساخته شد. ساختار پیشنهادی: چی می‌خوای، از کجا می‌فهمی تموم شده، و به چی نباید بدون اجازه دست بزنه.

عادت دوم benchmark هست، یعنی تبدیل هدف‌های مبهم مثل «سریع‌ترش کن» به یه عدد قابل‌اندازه‌گیری، مثل زمان باز شدن پنجره یا مصرف حافظه در حالت بیکار. این‌طوری ایجنت خودش تغییر می‌ده، دوباره اندازه می‌گیره و می‌فهمه بهتر شده یا نه. تو PandaCode با همین روش، تأخیر تا دیدن اولین کلمهٔ جواب از حدود ۸ ثانیه به حدود ۴ ثانیه رسید، چون ایجنت پروسهٔ بعدی رو از قبل تو پس‌زمینه راه می‌انداخت.

عادت سوم تست اجباری هست. نویسنده می‌گه Opus 5.5 معمولاً کد خوب ولی تست کم می‌نویسه. باید ازش خواست به راه‌های خراب شدن فکر کنه (ورودی خالی، حالت خطا، race condition) و برای همونا تست بنویسه، نه کلی تست سطحی. قانون سفت اینه که هیچی تا تست‌ها پاس نشن به آدم نشون داده نمی‌شه. این قانون رو می‌شه یه بار تو فایل دستورالعمل پروژه نوشت.

عادت چهارم طرح مرجع تصویری هست. «قشنگش کن» مدل رو مجبور می‌کنه سلیقه رو حدس بزنه و معمولاً به الگوهای تکراری مثل گرادیان‌های سنگین می‌رسه. به‌جاش اسکرین‌شات، mood board یا حتی یه طرح دستی بده؛ Opus 5.5 فاصله‌ها، اندازهٔ فونت و رنگ‌ها رو از تصویر درمیاره.

عادت پنجم چند ایجنتی کار کردن (orchestration) هست. Opus 5.5 نقش معمار رو داره و کار رو برنامه‌ریزی، تقسیم و بررسی می‌کنه؛ Sonnet که سریع‌تر و ارزون‌تره بیشتر تکه‌ها رو با context تازه پیاده می‌کنه؛ و Codex به‌عنوان داور مستقل کل تغییر رو بررسی می‌کنه، چون مدلی از یه شرکت دیگه اشتباه‌های متفاوتی رو می‌گیره. نویسنده معتقده این روش برای تغییرهای کوچیک ارزش نداره، ولی تو کارهای بزرگ، بررسی انسانی رو از مراقبت دائمی به بازبینی دوره‌ای تبدیل می‌کنه.

نکات کلیدی:

• مشکل اصلی تسک‌های طولانی context saturation و افت کیفیت در انتهای کاره
• پرامپت خوب سه بخش داره: چی می‌خوای، معیار تموم شدن، و چیزهایی که نباید دست بخورن
• با benchmark، تأخیر اولین کلمهٔ جواب تو PandaCode از حدود ۸ به ۴ ثانیه رسید
• تست‌ها باید روی راه‌های خراب شدن تمرکز کنن، نه تعداد تست
• تقسیم نقش پیشنهادی: Opus 5.5 معمار، Sonnet کارگر، Codex داور مستقل
• git worktree جدا برای هر کار طولانی، جلوی خراب شدن شاخهٔ اصلی رو می‌گیره