تصور کنید برای اصلاح یک غلط املایی ساده در یک فایل تنظیمات، باید هزینهٔ یک بازبینی کامل معماری نرمافزار را بپردازید. این دقیقاً همان تضادی است که کاربران Superpowers، محبوبترین پلاگین Claude Code، با آن روبروستند. ۲۸۰ هزار ستاره و ۲۵ هزار فورک در گیتهاب، محبوبیت انفجاری این ابزار را تعریف میکنند، اما این اعداد یک حقیقت پنهان را میپوشانند: اصلاح یک خط کد اکنون میتواند توکنهای بسیار بیشتری نسبت به ویرایش دستی مصرف کند.
با تکیه بر پوشش قبلی ما دربارهی Claude Code که در ارزیابیهای نرمافزاری به هزینه ۱۸.۳۴ دلار به ازای هر تسک رسیده بود، پلاگین Superpowers لایهای جدید از پیچیدگی مالی را اضافه کرده است. این ابزار، هوش مصنوعی را از یک رابط چت ساده به یک متدولوژی توسعه سختگیرانه تبدیل میکند. برای بسیاری از توسعهدهندگان، این به معنای انتخابی میان مهندسی با قابلیت اطمینان بالا و اسکریپتنویسی اقتصادی است. این رویکرد در راستای تلاشهای گستردهتر آنتروپیک برای استانداردسازی گردشکار توسعه از طریق بازار رسمی افزونههاست تا کنترل بیشتری بر خروجی کدها داشته باشد.
مکانیسم قابلیت اطمینان
این پلاگین توسط جسی وینسنت (Jesse Vincent) ساخته شده است؛ کسی که از دهه ۹۰ میلادی در حال عرضه ابزارهای متنباز برای توسعهدهندگان بوده است. Superpowers بر اساس ۲۲۴۹ فایل مارکداون ساخته شده که هر کدام حاوی درسهای آموخته شده توسط عاملهای هوش مصنوعی هستند. این پروژه در حال حاضر در کمتر از یک سال به ششمین نسخه اصلی خود رسیده است که نشاندهنده توسعه فعال آن است، هرچند ۱۲۵ مورد مشکل (Issue) باز در گیتهاب دارد.
این ابزار از طریق ۱۴ «مهارت» اصلی عمل میکند؛ اینها فایلهای دستورالعمل هستند که عامل در صورت برقراری محرکهای خاص، آنها را بارگذاری میکند. این مهارتها شامل موارد زیر هستند:
- طوفان فکری (Brainstorming)
- نوشتن برنامه (Plan writing)
- توسعه مبتنی بر عاملهای فرعی (Subagent driven development)
- توسعهمحور بر تست (TDD)
- عیبیابی سیستماتیک (Systematic debugging)
- تاییدیه پیش از تکمیل (Verification before completion)
در ابتدای هر جلسه، یک قلاب (Hook) عامل را مجبور میکند بررسی کند که آیا هیچیک از این مهارتها کاربرد دارند یا خیر. دستورالعملها بسیار تهاجمی هستند: اگر حتی ۱٪ احتمال وجود داشته باشد که یک مهارت مرتبط باشد، عامل باید آن را بارگذاری کند. این امر تضمین میکند که عامل صرفاً برای یافتن راه حل «حدس» نزند، بلکه یک گردش کار مهندسی نرمافزار حرفهای را دنبال کند. این سطح از اتوماسیون سختگیرانه، تکامل یافتهی همان حالت اجرای خودکار (Auto Mode) است که از ۱۴ اوت به پیشفرض Claude Code تبدیل شد تا دخالت کاربر به حداقل برسد.
گردش کار سه مسیره
پلاگین Superpowers برای جلوگیری از گسترش بیرویه محدوده پروژه (Scope Creep)، هر درخواست را مجبور میکند وارد یکی از سه مسیر متمایز شود. عامل طبقهبندی خود را با صدای بلند اعلام میکند تا کاربر بتواند در صورت نیاز آن را تغییر دهد. اگر در میانه تسک، پیچیدگی پنهانی کشف شود، مسیر میتواند ارتقا یابد، اما هرگز نمیتوان آن را به سطح پایینتری تنزل داد.
- Spike: یک پرسش امکانسنجی که در آن خروجی نهایی یک پاسخ است، نه کد دائمی.
- Bounded: یک تغییر کوچک در یک جریان موجود.
- Architectural: هر تغییری که منجر به بازسازی ساختار پروژه شود.
اگر تسکی «معماری» تشخیص داده شود، عامل باید پیش از نوشتن حتی یک خط کد، یک سند مشخصات (Specification) و یک برنامه پیادهسازی تولید کند. این «دروازه سخت» مانع از آن میشود که عامل ویژگیهایی را پیادهسازی کند که کاربر در نهایت ممکن است تصمیم بگیرد غیرضروری هستند. در برخی موارد، این مرحله باعث میشود ویژگیها پیش از ساخته شدن حذف شوند و در نتیجه در زمان و تلاش صرفهجویی شود.
جزئیات پیادهسازی
زمانی که برنامه تولید شد، «مهارت برنامهریزی» لحن خاصی را تعیین میکند: برنامه برای توسعهدهندهای نوشته میشود که مهارت بالایی دارد اما هیچ زمینهای از کدبیس ندارد و به گفته خود پلاگین، «سلیقه مشکوکی» دارد.
برای تضمین قابلیت اطمینان، کار به تسکهای بسیار ریز تقسیم میشود:
- اندازهگیری تسک: هر تسک به دو تا پنج دقیقه کار محدود میشود.
- حلقه TDD: عامل باید ابتدا یک تست بنویسد که شکست بخورد، آن را اجرا کند، شکست را تایید کند، حداقلیترین کد برای پاس کردن تست را بنویسد و سپس دوباره تستها را اجرا کند و در نهایت کد را ثبت (Commit) کند.
- دقت: هر تسک دقیقاً فایلهایی که باید تغییر کنند را لیست کرده و شماره خطوط را مشخص میکند.
این اندازهگیری دقیق، هسته اصلی استدلال قابلیت اطمینان است. با کوتاه نگه داشتن تسکها، عامل کار را در حالی به پایان میرساند که پنجره زمینه (Context Window) — شبیه به میز کاری که فقط چند برگه جا دارد و اگر پر شود مدل دچار فراموشی میشود — هنوز تا حد زیادی خالی است. این کار از سرریز شدن جلسه جلوگیری میکند؛ یعنی همان لحظهای که عاملها معمولاً شروع به اختراع توابعی میکنند که اصلاً وجود ندارند.
هزینه حلقه اجرا
قابلیت اطمینان از یک مدل ارکستراسیون سختگیرانه عاملهای فرعی حاصل میشود. به جای یک گفتگوی طولانی، جلسه اصلی به یک ارکستراتور تبدیل میشود که برای هر تسک، یک عامل فرعی (Subagent) تازه اعزام میکند. هر عامل فرعی فقط زمینه خاص مورد نیاز برای تسک خود را دریافت میکند و هیچ دسترسی به تاریخچه جلسه ندارد.
با این حال، این ساختار یک سربار توکن عظیم ایجاد میکند. هر تسک واحد نیازمند موارد زیر است:
۱. یک برگه اعزام (Dispatch brief) برای عامل فرعی.
۲. یک بازبینی انطباق با مشخصات (Spec compliance review).
۳. یک بازبینی کیفیت کد (Code quality review).
۴. یک ورودی در دفتر ثبت تکمیل (Completion ledger entry).
اگر بازبینی شکست بخورد، پلاگین وارد یک حلقه اصلاح میشود که حداکثر ۵ دور است:
- دور ۱ تا ۳: پیادهساز اصلی تلاش میکند خطا را برطرف کند.
- دور ۴: یک عامل فرعی جدید با استفاده از مدلی توانمندتر اعزام میشود.
- دور ۵: یک «شکنجهگر» (Breaker) فعال شده و ارکستراتور خودش درباره هر یافته باز را تصمیمگیری میکند.
این تشریفات فارغ از اندازه تسک، اجباری است. برای یک غلط املایی در فایل تنظیمات، این فرآیند کامل صرفاً کندتر و گرانتر از آن است که خودتان آن را اصلاح کنید.
انتخاب مدل و بهینهسازی
برای مدیریت هزینهها، پلاگین از یک قانون اصلی پیروی میکند: از کمقدرتترین مدلی استفاده کن که بتواند هر نقش را مدیریت کند.
- مدلهای کوچک: برای تسکهای مکانیکی با مشخصات دقیق که یک یا دو فایل را تغییر میدهند.
- مدلهای استاندارد: برای هماهنگی بین چندین فایل و عیبیابی.
- توانمندترین مدلها: رزرو شده برای معماری و بازبینی نهایی شاخه (Branch review).
دو نکته ظریف، صورتحساب نهایی را تعیین میکند. اول اینکه مدلها باید هنگام اعزام بهطور صریح نامگذاری شوند؛ در غیر این صورت، عاملهای فرعی مدل گرانقیمت جلسه را به ارث میبرند و منطق کاهش هزینه بهطور خاموش از بین میرود. دوم اینکه پلاگین «تعداد نوبتها» (Turn count) را بر قیمت توکن اولویت میدهد. چون مدلهای ارزانتر اغلب برای تکمیل کارهای چندمرحلهای به نوبتهای بیشتری نیاز دارند، بازبینها و پیادهسازانی که با متن (Prose) کار میکنند، یک سطح بالاتر قرار میگیرند تا هزینه کل کاهش یابد.
این بهینهسازی باعث میشود اجرای مدلهای گرانقیمتی مانند Opus یا Fable در یک پلن Pro ۲۰ دلاری ممکن شود، زیرا گرانترین مدل فقط با تصمیماتی درگیر میشود که واقعاً ارزش آن را دارند.
برد بلندمدت: مستندات زنده
فراتر از کد، این پلاگین مشخصات و برنامهها را به صورت فایلهای مارکداون در پوشهای تاریخدار درون مخزن (Repository) ذخیره میکند. این فایلها در کنار کد در گیت ثبت میشوند. این کار تاریخچه گیت را از لیستی از «چه چیزی تغییر کرد» به سوابقی از «چرا تغییر کرد» تبدیل میکند.
شش ماه بعد، یک توسعهدهنده میتواند در یک پرامپت به فایل برنامه اشاره کند و عامل میتواند بستر دقیق آن ویژگی را دوباره بازیابی کند. چون سند مشخصات (Spec) مرجع نهایی است، تضادها بر اساس سند حل میشوند، نه بر اساس حافظه ناپایدار عامل. این رویکرد ساختاریافته، مستندسازی را بدون نیاز به یک مرحله نوشتاری مجزا، بهطور مؤثر خودکار میکند.
حکم نهایی
برای توسعهدهندگانی که ویژگیهای پیچیده میسازند که ساعتها زمان میبرد، دستاوردهای قابلیت اطمینان و مستندسازی بر هزینهها میچربد. اما برای کسانی که اسکریپتهای یکبار مصرف مینویسند یا اصلاحات کوچک انجام میدهند، این پلاگین یک «قاتل توکن» است.
اگر آمار استفاده شما نشان میدهد که پلاگین تنها در ۱٪ تا ۳٪ موارد فعال شده است، به این معناست که درخواستهای شما تقریباً هرگز مهارتها را تحریک نمیکنند، اما شما همچنان در هر بار شروع جلسه، هزینه بررسی اولیه را میپردازید. بهینهترین استراتژی این است که Superpowers را برای کارهای ویژگی (Feature work) روشن نگه دارید، اما صراحتاً به عامل بگویید که برای ویرایشهای جزئی فرآیند را «نادیده بگیرد» (skip)، زیرا دستورالعملهای پلاگین، دستورات کاربر را بالاتر از مهارتها قرار میدهند.
گام بعدی شما
- اگر روی ویژگیهای پیچیده کار میکنید، Superpowers را فعال نگه دارید تا مستندات پروژه بهطور خودکار ساخته شوند.
- برای اصلاحات جزئی و تغییرات متنی، صراحتاً به مدل بگویید «فرآیند Superpowers را نادیده بگیر» (skip) تا هزینه توکنها کاهش یابد.
- مدلهای مورد استفاده در اعزام عاملهای فرعی را چک کنید تا مطمئن شوید مدلهای گرانقیمت برای کارهای ساده استفاده نمیشوند.
اما تأثیر این مدلهای ارکستراسیون بر سرعت توسعه در مقیاس سازمانی حتی پیچیدهتر است — به تحلیل ما دربارهی پروتکل MCP مراجعه کنید.
گفتگو