ترکیب مدل‌های متنوع در برابر جست‌وجوی ابزار واحد برای بهینه‌سازی استنتاج

تصور کنید به جای تکیه بر یک جادوگر همه‌فن‌حریف، یک تیم کوچک از مهندسان متخصص را در اختیار دارید که هر کدام در یک بخش خبره‌اند. این دقیقاً همان تغییری است که در معماری جدید توسعه نرم‌افزار رخ داده است تا کیفیت خروجی به جای قدرت خام یک مدل، به نحوه سازماندهی خط لوله تحویل وابسته شود. این ایده مرکزی یک تحلیل معماری مفصل بود که در ۲۲ اوت ۲۰۲۶ در وب‌سایت dev.to منتشر شد. بینش اصلی این است که جعبه‌ابزار برنامه‌نویسی یک توسعه‌دهنده دیگر یک محصول واحد نیست، بلکه سیستمی هماهنگ از عامل‌های متخصص است.

به نقل از این تحلیل، ابزارهای برنامه‌نویسی دیگر یک محصول واحد نیستند، بلکه سیستمی هماهنگ از عامل‌های هوش مصنوعی (AI Agents) — شبیه به یک تیم کاری که هر عضو وظیفه مشخصی دارد — هستند. این رویکرد در حالی مطرح می‌شود که تیم‌های سازمانی با چالش «انتخاب مدل» دست‌وپنجه نرم می‌کنند؛ یعنی تردید بین استفاده از یک مدل قدرتمند اما گران، یا مدیریت پیچیدگی یک استراتژی چندمدلی. در حالی که رویکرد تک‌مدلی ساده‌تر است، اما ریسک تمرکز را ایجاد می‌کند و توکن‌های گران‌قیمت را برای کارهای پیش‌پاافتاده هدر می‌دهد. این چالش‌ها ما را به یاد راهکار Jeda برای مدیریت بارهای کاری می‌اندازد که در آن مسیریابی وظایف بر اساس ریسک، جایگزینی بهینه برای مدل‌های تک‌رویکردی است.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، صنعت به سمت «تناسب بار کاری» (Workload Fit) حرکت می‌کند؛ جایی که مدل‌های مختلف بر اساس پروفایل استدلال و هزینه خاصشان عملیاتی می‌شوند. در این مدل، کیفیت نهایی کمتر به قدرت خام یک مدل خاص و بیشتر به این بستگی دارد که انسان چگونه خط لوله تحویل را سازماندهی می‌کند.

معماری میزکار لایه‌ای

این سیستم عادت «یک پرامپت برای همه کار» را با یک خط لوله ساختاریافته جایگزین می‌کند: تعیین الزامات و محدودیت‌ها $\rightrightarrows$ بستر پروژه (فایل‌های AGENTS.md / CLAUDE.md / مستندات) $\rightrightarrows$ طراحی (معماری، مرزهای دامنه، ریسک‌ها، معیارهای پذیرش) $\rightrightarrows$ بازبینی و تصمیم انسانی $\rightrightarrows$ تجزیه وظایف $\rightrightarrows$ اجرا $\rightrightarrows$ بازبینی متقاطع مستقل $\rightrightarrows$ بررسی‌های خودکار + اعتبارسنجی سناریوها $\rightrightarrows$ تبدیل اصلاحات به بستر پایدار پروژه.

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

برای اجرای این مدل، سلسله‌مراتبی از ابزارها بر اساس ریسک، حجم زمینه، قابلیت تأیید، هزینه و حریم خصوصی تعریف شده است:

• کاوش محلی: استفاده از Ollama برای اجرای مدل Qwen3.5:9B جهت توضیح کد، جست‌وجوی محلی، پیش‌نویس‌ها، ویرایش‌های کم‌ریسک و کمک در زمینه‌های حساس. این کار حریم خصوصی و سرعت را برای کارهای بازگشت‌پذیر تضمین می‌کند.
• هماهنگ‌سازی باز: ابزار OpenCode (با مسیریابی به Qwen یا Kimi K3) برای جابه‌جایی بین مدل‌ها، انجام آزمایش‌ها، مقایسه هزینه در برابر قابلیت و گردش‌کارهای ترمینالی جایگزین‌پذیر.
• طراحی عمیق: Claude Code برای درک گسترده مخزن کد (Repository Comprehension)، پیشنهادهای معماری، مدل‌سازی دامنه و برنامه‌ریزی برای مهاجرت کد.
• اجرای مهندسی: ترکیبی از Codex، Claude Code و OpenCode برای کاوش در مخزن، پیاده‌سازی، بازسازی (Refactoring)، تست، تعمیر و بازبینی.
• همکاری دسکتاپ: نسخه دسکتاپ GPT برای استدلال‌های بصری و بین‌فایلی، سنتز پژوهشی، همکاری‌های طولانی‌مدت و اصلاحات تحریری نهایی.

این رتبه‌بندی دائمی نیست و با تغییر مدل‌ها و محصولات تغییر خواهد کرد. اما قاعده ثابت این است: کارهای کم‌ریسک و بازگشت‌پذیر باید با مدل‌های محلی یا ارزان شروع شوند. استدلال‌های بین‌ماژولی شایسته مدل‌های قدرتمندتر هستند. معماری، مهاجرت داده‌ها، امنیت و تغییرات محیط عملیاتی حتماً نیاز به تصمیم انسانی دارند. هیچ خروجی مدلی جایگزین شواهد پذیرش (Acceptance Evidence) نمی‌شود.

ایجاد سقف زمینه (Context Ceiling)

به جای تکیه بر پرامپت‌های پیچیده، سیستم با مستندات سطح پروژه شروع می‌شود. فایل‌هایی مانند AGENTS.md و CLAUDE.md مانند یک «سقف» برای هر عامل عمل می‌کنند تا از حدس زدن قراردادها یا ابداع سبک‌های پیاده‌سازی جلوگیری کنند. بدون این بستر مشترک، هر ابزار باید کل مخزن را دوباره اسکن کند که منجر به ناهماهنگی در سبک پیاده‌سازی می‌شود.

این فایل‌های زمینه باید موارد زیر را صریحاً تعریف کنند:

• هدف: مسئله‌ای که حل می‌شود، کاربران هدف و مرحله فعلی توسعه.
• پشته فناوری (Stack): زبان‌ها، فریم‌ورک‌ها، نسخه‌ها و وابستگی‌های اصلی.
• معماری: مسئولیت ماژول‌ها، جهت وابستگی‌ها و مرزهای سخت.
• زبان دامنه: مفاهیم کلیدی، اصطلاحات و مفروضات تغییرناپذیر (Invariants).
• دستورات: دستورات دقیق برای نصب، اجرا، تست، بررسی تایپ (Type-check) و بیلد.
• قراردادها: استانداردهای نام‌گذاری، مدیریت خطاها، لاگ‌گذاری، تست‌ها و کامیت‌ها.
• ایمنی: نحوه مدیریت داده‌های حساس، اسرار (Secrets)، فراخوانی‌های خارجی و اقدامات ممنوعه.
• تعریف پایان (DoD): گیت‌های کیفی اجباری برای هر تغییر.

برای حفظ کارایی، این فایل‌ها نباید به زباله‌دانی هزار خطی تبدیل شوند. AGENTS.md خانه قوانین پایدار، اجراشدنی و مشترک بین ابزارها است، در حالی که CLAUDE.md حاوی راهنمای تعامل خاص مدل کلود است. معماری‌های مفصل باید در اسناد متمرکز قرار گیرند و از نقطه ورود به آن‌ها لینک داده شود.

جزئیات مدیریت زمینه

• ایجاز قوانین: قوانین باید کوتاه، قابل تست و هم‌زمان با کد به‌روز شوند.
• جلوگیری از تکرار: تکرار یک قانون در چندین فایل در نهایت به تضاد منجر می‌شود. از تکرار بپرهیزید.
• منابع مرجع: حقایق مشترک باید یک منبع واحد (Canonical Source) داشته باشند؛ فایل‌های خاص هر ابزار باید فقط شامل تفاوت‌ها باشند.

طراحی و بازبینی انسان‌محور

حتی اگر Claude یک مدل طراحی‌محور دامنه (DDD) پیشنهاد دهد، توسعه‌دهنده انسانی مسئول نهایی است. هوش مصنوعی برای گسترش سریع فضای مسئله — شناسایی ماژول‌های متأثر، پیشنهاد جایگزین‌ها، آشکار کردن وابستگی‌های پنهان و تبدیل الزامات مبهم به ساختار قابل بحث — به کار می‌رود، اما یک سند طراحی صیقل‌خورده لزوماً به معنای طراحی درست نیست.

در این گردش‌کار، پنج بعد حیاتی بازبینی می‌شوند:

۱. همسویی با مسئله: آیا واقعاً مشکل را حل می‌کند یا فقط پیچیدگی معماری را برای نمایش مهارت اضافه کرده است؟
۲. طبیعی بودن مرزها: آیا مرزها بر اساس تغییرات کسب‌وکار هستند یا فقط واژگان DDD را به طور نمایشی به کار برده‌اند؟
۳. کنترل وابستگی‌ها: آیا جریان داده، تراکنش‌ها، بازیابی و سازگاری صریح هستند؟
۴. ارسال تدریجی: آیا می‌توان آن را تکه‌تکه منتشر کرد یا نیاز به بازنویسی پرریسک «بیگ‌بنگ» (Big-bang) است؟
۵. تأیید: آیا معیارهای تست، عملکرد، مهاجرت و پذیرش کسب‌وکار قبل از پیاده‌سازی تعریف شده‌اند؟

در این سیستم، DDD به عنوان ابزاری برای دانش پیچیده کسب‌وکار تلقی می‌شود، نه یک پیش‌فرض تزئینی. یک ماژول کوتاه‌مدت با عملیات ساده CRUD نیازی به Aggregateها، Repositoryها و لایه‌های اضافی ندارد. DDD زمانی هزینه خود را توجیه می‌کند که قوانین پیچیده باشند، زبان مورد مناقشه باشد و مرزها در طول زمان تکامل یابند. از مدل خواسته می‌شود توضیح دهد چرا یک طراحی مناسب است، چه جایگزین‌هایی وجود دارد و چه زمانی توصیه او نباید اجرا شود. طراحی خوب یک نمودار خیره‌کننده نیست؛ مجموعه‌ای از تصمیمات است که باید بتوان آن‌ها را به چالش کشید، مبادله کرد (Trade-off) و تأیید کرد.

پس از تأیید طراحی، کار به «بسته‌های وظیفه» (Task Packets) تقسیم می‌شود. این‌ها واحدهای مستقل قابل تأیید با محدوده نوشتاری محدود هستند تا از کابوس «حل تداخل» (Conflict Resolution) که هنگام ویرایش یک فایل مرکزی توسط چندین عامل رخ می‌دهد، جلوگیری شود. موازی‌سازی تنها زمانی سودمند است که مرزها شفاف باشند و محدوده‌های نوشتاری تداخل کمی داشته باشند.

مشخصات بسته وظیفه

هر بسته وظیفه باید شامل موارد زیر باشد:

• هدف: رفتار خاص کاربر یا سیستم که باید تغییر کند.
• دامنه: ماژول‌های مجاز و اهدافی که صریحاً جزو کار نیستند (Non-goals).
• زمینه: تصمیمات، اینترفیس‌ها و قراردادهای مرتبط.
• پذیرش: تست‌ها، مثال‌ها، عملکرد یا رفتارهای قابل مشاهده.
• ریسک: الزامات سازگاری، داده‌ها، امنیت و نیاز به بازگشت (Rollback).
• تحویل: کد، تست، مستندات مورد نیاز و هرگونه سؤال حل‌نشده.

وظایف باید بر اساس مرز دامنه، ماژول، مسئولیت خواندن/نوشتن یا دغدغه‌های اعتبارسنجی تقسیم شوند، نه به صورت مکانیکی بر اساس فایل. علاوه بر این، توسعه‌دهنده حجم زمینه را کنترل می‌کند. دادن کل مخزن کد به یک عامل همیشه مفید نیست، زیرا اطلاعات نامرتبط باعث تضعیف محدودیت‌ها و افزایش تداعی‌های تصادفی می‌شود. قوانین پایدار پروژه به اشتراک گذاشته می‌شوند، اما هر وظیفه فقط زمینه محلی لازم برای هدف خود را دریافت می‌کند.

نردبان اعتبارسنجی

برای جلوگیری از اینکه عامل‌ها صرفاً اشتباهات یکدیگر را تأیید کنند، مکانیزم بازبینی متقاطع به کار می‌رود. ارزش این کار در «رأی‌گیری» بین مدل‌ها نیست، بلکه در توانایی یک بازبین مستقل برای به چالش کشیدن مفروضات اجراکننده است. بازبین‌ها موظفند انطباق با الزامات، مرزهای معماری، جفت‌شدگی‌های پنهان (Hidden Coupling)، مسیرهای خطا، هم‌زمانی (Concurrency)، Idempotency و پاک‌سازی منابع را بررسی کنند.

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

برای جلوگیری از خطر به ارث بردن مفروضات غلط توسط عامل‌ها، سیستم یا منبع اطلاعات و یا روش اعتبارسنجی را تغییر می‌دهد. برای مثال، یک مدل بازبینی استاتیک انجام می‌دهد در حالی که مدل دیگر تست‌ها و سناریوها را اجرا می‌کند و در نهایت یک انسان قضاوت حیاتی کسب‌وکار را بازبینی می‌کند.

تأیید نهایی هرگز بر اساس «اطمینان» (Confidence) مدل نیست، بلکه از یک نردبان سخت‌گیرانه عبور می‌کند:

۱. فرمت‌بندی و لینتینگ (Linting)
۲. بررسی تایپ و کامپایل
۳. تست‌های واحد و یکپارچگی (Unit & Integration Tests)
۴. بررسی سناریوهای حیاتی کاربر یا API
۵. بازبینی Diff و سازگاری معماری

جزئیات اجرا و حاکمیت

• گزارش دستورات: بررسی‌های خودکار باید در دستورات پروژه و CI باشند، نه در حافظه عامل. عامل‌ها باید گزارش دهند کدام دستورات را واقعاً اجرا کرده‌اند و نتایج آن‌ها چه بوده است. یک تست اجرا نشده «احتمالاً پاس شده» نیست و یک پیش‌بینی، دلیل و مدرک نیست.
• حاکمیت ریسک بالا: استقرار در محیط عملیاتی، مهاجرت دیتابیس، تغییرات تخریبی، به‌روزرسانی مجوزها و ارتباطات خارجی نیاز به تأیید صریح انسان و یک برنامه بازیابی (Recovery Plan) دارند.
• کنترل‌های امنیتی: استنتاج محلی حریم خصوصی را بهبود می‌بخشد اما به‌طور خودکار امن نیست. منشأ مدل، مجوزهای ابزار، اسرار در پرامپت‌ها، لاگ‌ها و پلاگین‌های خارجی همچنان نیاز به کنترل سخت‌گیرانه دارند.

تبدیل شکست‌ها به حافظه پایدار

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

• محدودیت‌های مهندسی پایدار به AGENTS.md منتقل می‌شوند.
• تبادل‌های معماری به عنوان سوابق تصمیمات معماری (ADRs) ثبت می‌شوند.
• حقایق دامنه وارد مستندات دامنه می‌شوند.
• خطاهای مکانیکی به قوانین لینت یا تست تبدیل می‌شوند.
• شکست‌های باارزش به موارد رگرسیون (Regression Cases) تبدیل می‌شوند.

این رویکرد به توسعه‌دهنده اجازه می‌دهد زمان چرخه از درخواست تا ادغام (Merge)، نرخ اعتبارسنجی در اولین تلاش، یافته‌های بازبینی، بازکاری‌های انسانی، تعداد بازگشت‌ها (Rollback) و هزینه وظایف مشابه در مدل‌های مختلف را ردیابی کند. سرعت تولید کد به عنوان یک معیار ضعیف شناخته می‌شود؛ مدلی که سریع است اما ساعت‌ها بازبینی انسانی ایجاد می‌کند، در واقع سیستم کندتری است.

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

گام بعدی شما

• فایل AGENTS.md را برای تعریف قراردادهای ثابت پروژه خود ایجاد کنید تا از توهم مدل‌ها در پیاده‌سازی جلوگیری کنید.
• برای کارهای تکراری و کم‌ریسک، از مدل‌های محلی مانند Qwen3.5 روی Ollama استفاده کنید تا هزینه توکن‌ها را کاهش دهید.
• یک نردبان اعتبارسنجی ۵ مرحله‌ای برای هر تغییر کد تعریف کنید و هرگز به «اطمینان» مدل اکتفا نکنید.

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