اگر امروز از چندین مدل مختلف برای یک پروژه استفاده می‌کنید، احتمالاً متوجه شده‌اید که سرعت خروجی مدل‌ها با سرعت پیشرفت پروژه هم‌خوانی ندارد. مشکل اصلی نه در قدرت استدلال مدل‌ها، بلکه در «شکاف تحویل» (Handoff Gap) است؛ جایی که انسان باید به‌عنوان یک پل دستی، دستورالعمل‌ها را دوباره توضیح دهد و نتایج را در هر مرحله بازبینی کند. وقتی یک تسک از ChatGPT به Claude یا Codex منتقل می‌شود، اپراتور انسانی معمولاً تبدیل به یک رابط دستی می‌شود که باید مشخصات را بازنویسی کند و نتایج را در هر گام تأیید نماید. اگر تحویل کاملاً به انسان وابسته باشد، کل جریان کاری در همان نقطه متوقف می‌شود، فارغ از اینکه مدل‌های هوش مصنوعی به‌تنهایی چقدر سریع باشند.
این اصطکاک به این دلیل رخ می‌دهد که مدیریت وضعیت (State Management) در ابزارهای فعلی به‌صورت جزیره‌ای است. طبق گزارش‌های فنی، در حالی که OpenAI با قابلیت Projects سعی در سازماندهی چت‌ها، فایل‌ها و دستورالعمل‌ها به‌عنوان یک بستر متنی مستمر دارد، و Anthropic از طریق فایل‌های CLAUDE.md و قابلیت‌های بازیابی نشست (Session Resume) در Claude Code حافظه پروژه را فراهم می‌کند، این وضعیت‌ها به‌طور خودکار بین پلتفرم‌ها مهاجرت نمی‌کنند. این وابستگی به ابزارهای خاص، در شرایطی که پایداری سرویس‌ها به چالش کشیده می‌شود، حساس‌تر است؛ چنان‌که بحران‌های پایداری اخیر در اکوسیستم کلود نشان داد که اختلال در یک پلتفرم می‌تواند کل زنجیره تولید را متوقف کند. هیچ مکانیزمی وجود ندارد که در آن وضعیت یک چت در ChatGPT به‌طور خودکار به Claude منتقل شود، یا مشخصات Claude به‌طور یکپارچه به Codex و سپس به یک سرویس خارجی داده شود. همان‌طور که در تحلیل قبلی ما درباره‌ی تله‌های یادگیری برای برنامه‌نویسان اشاره کردیم، این شکاف سیستمی ریسک آن را دارد که پشته‌های هوش مصنوعی به‌جای افزایش بهره‌وری، به یک بار مدیریتی تبدیل شوند.
مسئله‌ی مهاجرت وضعیت
به نقل از مستندات طراحی جریان‌های کاری، وقتی یک تسک بین نقش‌ها، نشست‌ها (Sessions) یا محیط‌های اجرایی مختلف جابه‌جا می‌شود، وضعیت فعلی باید به فرمتی قابل اشتراک تبدیل شود. بسیاری از کاربران به‌اشتباه خلاصه‌های طولانی از گفتگوهای قبلی را به مدل بعدی می‌دهند. اما مدل یا انسانی که تسک را تحویل می‌گیرد، به کل تاریخچه نیاز ندارد؛ او به «وضعیت عملیاتی فعلی» نیاز دارد.
برای حل این مشکل، یک طراحی سخت‌گیرانه برای تحویل (Handoff) باید جایگزین خلاصه‌های مبهم شود. یک تحویل مؤثر باید اولویت را به ۶ نقطه داده‌ی خاص اختصاص دهد:
- هدف نهایی و موقعیت فعلی در جریان کار.
- کارهای تکمیل‌شده (DONE).
- شواهد دقیق مورد استفاده برای تأیید کار (VERIFIED).
- وظایف باقی‌مانده (تکمیل‌نشده).
- پیشنهادهایی که پیش‌تر رد شده‌اند.
- اقدام فوری بعدی که باید انجام شود.
تفکیک «انجام شد» از «تأیید شد»
یک شکست بحرانی در جریان‌های کاری هوش مصنوعی، یکی دانستنِ تسک «تکمیل‌شده» با تسک «تأییدشده» است. مدل‌های هوش مصنوعی زاینده (Generative AI) — شبیه به کارآموزی که برای خوشامد دادن به مدیر، می‌گوید «کار تمام شد» بدون اینکه آن را تست کرده باشد — اغلب تکمیل تسک را خودشان گزارش می‌دهند. این گزارش‌های نادرست وقتی به‌عنوان یک محصول نهایی به مدل یا فرآیند بعدی منتقل می‌شوند، باعث ایجاد خطاهای زنجیره‌ای (Cascading Errors) می‌شوند.
برای جلوگیری از این اتفاق، تیم‌ها باید این دو وضعیت را به‌طور کامل تفکیک کنند:
- DONE (انجام شد): عمل صورت گرفته است. (مثلاً: «مقاله نوشته شد»، «کد نوشته شد» یا «صفحه پرداخت باز شد»).
- VERIFIED (تأیید شد): نتیجه از طریق یک منبع خارجی تأیید شده است. (مثلاً: «آدرس URL عمومی در یادداشت تأیید شد»، «عملیات در محیط Production تأیید شد» یا «خرید نهایی شد»).
پیاده‌سازی حلقه پذیرش
معماری پیشنهادی به‌جای جریان خطی، یک چرخه «کار $ \rightarrow $ تحویل $ \rightarrow $ پذیرش $ \rightarrow $ کار» را اجرا می‌کند. اسناد تحویل به‌تنهایی کافی نیستند چون فرستنده ممکن است دچار اشتباه شده باشد. مدل یا انسان گیرنده نباید بلافاصله کار را شروع کند، بلکه باید ابتدا فایل‌های حیاتی، لینک‌ها و نتایج تست را اعتبارسنجی کند. سپس گیرنده باید یکی از سه پاسخ زیر را صادر کند:
- ACCEPTED (پذیرفته شد): وضعیت درست است و کار آغاز می‌شود.
- ACCEPTED WITH CORRECTIONS (پذیرش با اصلاحات): پیش از ادامه کار، نیاز به تغییرات جزئی است.
- REJECTED (رد شد): تحویل نامعتبر یا ناقص است.
گیت‌هاب به‌عنوان منبع شواهد، نه تاریخچه چت
بر اساس بررسی منابع متعدد، توسعه‌دهندگان باید از استفاده از GitHub به‌عنوان مخزنی برای گفتگوهای AI دست بردارند. گیت‌هاب جای لاگ‌های چت نیست، بلکه نقطه‌ای برای تبادل شواهد پیاده‌سازی است. تنها مواردی که ارزش نگهداری بالایی دارند عبارت‌اند از:
- فایل‌های تغییریافته و هش‌های کامیت (Commit Hashes).
- نتایج تست‌ها.
- تصمیمات مربوط به پیاده‌سازی.
- شواهد بازتولیدپذیر (Reproducible Evidence).
برای داده‌های مالی، «منبع حقیقت» (Source of Truth) همچنان سمت تجاری (مثلاً Stripe) باقی می‌ماند. هدف ایجاد یک حلقه بسته است: بازار $ \rightarrow $ گیت‌هاب/پیاده‌سازی $ \rightarrow $ اقدام خارجی $ \rightarrow $ خریدار $ \rightarrow $ درآمد $ \rightarrow $ شواهد $ \rightarrow $ دلتای یادگیرنده (Learnable Delta) بازگشت به گیت‌هاب $ \rightarrow $ اقدام خارجی بعدی.
این تغییر به این معناست که پیش از افزودن مدل‌های جدید به پشته، ابتدا باید پروتکل تحویل را اصلاح کنید. تعریف اینکه «چه کسی فکر می‌کند»، «چه کسی اجرا می‌کند» و «چه چیزی به‌عنوان شاهد پذیرفته می‌شود»، بسیار ارزشمندتر از افزایش تعداد مدل‌هاست. برای تبدیل این مفاهیم به عمل، می‌توان از مهارت‌های قابل‌حمل در گردش‌کارهای بازرسی‌پذیر بهره برد تا پرامپت‌های تکراری به فرآیندهای ساختاریافته تبدیل شوند. اگر تعداد ابزارها را بدون اصلاح تحویل افزایش دهید، فقط حجم ترافیک مدیریتی مورد نیاز را بالا برده‌اید.
اگر در حال مدیریت یک خط لوله چند-مدلی (Multi-model Pipeline) هستید، با ممیزی فاز «پذیرش» شروع کنید تا ببینید چه تعداد از تسک‌های DONE در واقع VERIFIED شده‌اند.
گام بعدی شما
- جریان‌های کاری فعلی خود را ممیزی کنید و تعداد تسک‌های DONE که واقعاً VERIFIED نشده‌اند را بشمارید.
- یک قالب استاندارد ۶ ماده‌ای برای انتقال تسک بین مدل‌های مختلف (مثلاً از ChatGPT به Claude) تعریف کنید.
- لاگ‌های چت را از مخازن کد حذف کرده و فقط نتایج تست و تصمیمات فنی را ثبت کنید.
اما مدیریت این وضعیت‌ها در مقیاس سازمانی نیازمند زیرساخت‌های جدیدی است — به تحلیل ما درباره‌ی پروتکل MCP برای اتصال مدل‌ها به داده‌ها مراجعه کنید.
گفتگو