تصور کنید اپلیکیشنی تحویل میگیرید که ظاهرش بینقص است، اما با یک بار رفرش کردن صفحه، تمام دادههای شما ناپدید میشود. این تلهی رایج در توسعهی عاملمحور (Agentic) است؛ جایی که رابط کاربری صیقلخورده، یک بکاند شکسته را پنهان میکند.
به نقل از Admas در گزارشی که ۲۹ سپتامبر ۲۰۲۴ منتشر شد، برای جلوگیری از این وضعیت باید به سمت «قراردادهای تست پذیرش» (Acceptance-test contracts) حرکت کنیم. هدف این است که اپلیکیشنهای CRUD (ایجاد، خواندن، بهروزرسانی و حذف) پیش از آنکه مفید تلقی شوند، واقعاً کار کنند. این رویکرد به جای تقاضای تضمین کیفیت جامع و خستهکننده، بر تبدیل یک ایده به یک مسیر کامل، واحد و قابل بازرسی تمرکز دارد. این تغییر دیدگاه با استراتژیهای جدید در تستهای نرمافزاری همسو است که در آن تصمیمگیری هوشمند جایگزین اسکریپتهای دستی و صلب میشود.
بسیاری از کاربران در تلهی پیشنمایشهای متقاعدکنندهای میافتند که فقط در حافظهی موقت مدل زنده هستند. این شکاف باعث میشود برنامه کامل به نظر برسد، اما لحظهای که کاربر دادهای نامعتبر وارد میکند یا صفحه را بازنشانی میکند، سیستم شکست بخورد. برای حل این مشکل، توسعهدهنده باید فهرستی سختگیرانه از رفتارهای مشاهدهپذیر تعریف کند که هوش مصنوعی زاینده (Generative AI) — شبیه به یک کارآموز مشتاق که سریع کد میزند اما گاهی جزئیات حیاتی را فراموش میکند — باید اجرای آنها را اثبات کند.
همانطور که در تحلیلهای قبلی ما دربارهی Vibe Coding اشاره کردیم، تکیه بر «حس کلی» در برنامهنویسی خطرناک است. برای درک بهتر، یک سیستم سادهی پیگیری درخواست مشتری را در نظر بگیرید که یک کسبوکار کوچک به آن نیاز دارد. یک نسخه پایه از این سیستم تنها به چهار فیلد نیاز دارد: نام مشتری، شماره تلفن، متن پیام و یک وضعیت (مانند «جدید»، «در حال بررسی» یا «انجام شده»). به جای اینکه به AI بگویید «فرم را فعال کن»، باید یک قرارداد بر اساس نتایج مشاهدهپذیر تعریف کنید.
بر اساس مستندات Admas، یک قرارداد کاربردی برای این سیستم پیگیری باید پنج مرحلهی تأیید مشخص را طی کند:
چارچوب تأییدیه
- مسیر موفق (Happy Path): ارسال کامل فرم باید با موفقیت ذخیره شود و در لیست با مقادیر درست ظاهر شود. برای مثال، وارد کردن نام، تلفن و پیام باید منجر به ایجاد یک درخواست جدید شود که در لیست با وضعیت «جدید» نمایش داده شود.
- خطای قابل بازیابی: فرمهای ناقص نباید دادههای غلط ذخیره کنند یا بدون توضیح شکست بخورند. اگر کاربر فیلد نام را خالی بگذارد، سیستم باید پیامی واضح نمایش دهد که مشخص میکند چه اطلاعاتی کم است و سایر مقادیر وارد شده را حفظ کند تا کاربر مجبور به شروع مجدد نباشد.
- بررسی پایداری (Persistence): دادهها باید پس از رفرش صفحه یا باز کردن مجدد نما، باقی بمانند تا ثابت شود در پایگاهداده ذخیره شدهاند، نه فقط در حافظهی موقت (In-memory). این مورد، یک نمایش موقت را از یک جریان کاری کاربردی جدا میکند.
- انتقال وضعیت: تغییر وضعیت (مثلاً از «جدید» به «در حال بررسی» و سپس به «انجام شده») باید به عنوان یک رویداد ذخیرهشده تأیید شود. توسعهدهنده باید وضعیت را تغییر دهد، صفحه را رفرش کند و تأیید کند که بهروزرسانی همچنان باقی است.
- گزارش شواهد: AI باید صراحتاً گزارش دهد کدام تستها پاس شدهاند و کدامها هنوز تأیید نشدهاند. یک تست شکستخورده، اطلاعات مفیدی است؛ اما پنهان کردن آن پشت یک پیشنمایش صیقلخورده، هیچ ارزشی ندارد. در واقع، ثبت ردپای تصمیمات و دلایل تأیید تنها راهی است که مانع از شکستهای متناقض در بازبینیهای هوش مصنوعی میشود.
این متد، پرامپت را از یک درخواست مبهم به تقاضای «شاهد و مدرک» تبدیل میکند. یک درخواست ساختِ مفید باید از AI بخواهد که سیستم پیگیری را بسازد، یک نمونه درخواست اضافه کند، یک ارسال کامل را تست کند، یک خطای قابل بازیابی را نشان دهد و پایداری دادهها را پس از رفرش تأیید کند.
برای شما به عنوان کاربر، این یعنی عبور از توسعهی «حسمحور». به جای قضاوت درباره پیشرفت AI بر اساس ظاهر UI، باید آن را بر اساس شواهد مدیریت وضعیت (State Management) بسنجید. این کار مانع از آن میشود که ویژگیهای جدید را روی بنیادی ناپایدار بنا کنید و در چرخه تکراری افزودن قابلیت به یک سیستم شکسته نیفتید.
پس از تأیید قرارداد پایه، بهبودها باید یکییکی اضافه شوند. بهبودهای توجیهپذیر شامل موارد زیر است:
- افزودن توابع جستوجو یا فیلتر برای درخواستها.
- تعیین یک مالک (Owner) برای هر رکورد.
- ثبت تاریخچهی کامل تغییرات وضعیت.
- امکان خروجی گرفتن (Export) از رکوردهای منتخب.
- افزودن سیستم احراز هویت و تست قوانین دسترسی خاص آن.
هر ویژگی جدید باید شرط پذیرش (Acceptance Condition) خاص خود را داشته باشد تا «تورم ویژگیها» (Feature Creep) جایگزین پایداری واقعی نشود. این روش امنیت سطح تولید، مقیاسپذیری یا انطباق با قوانین رگولاتوری را تضمین نمیکند، اما یک مسیر کاربردی را اثبات کرده و پایهای پایدار برای تکرارهای بعدی پروژه ایجاد میکند. این رویکرد سختگیرانه به تأیید خودکار قراردادهای هوشمند شباهت دارد که در آن بازبینیهای دستی جای خود را به اعتبارسنجیهای دقیق و سیستماتیک دادهاند.
گام بعدی شما
- پیش از ارسال اولین درخواست ساخت به یک عامل AI، «تعریفِ اتمام» (Definition of Done) خود را به صورت فهرستی از رویدادهای قابل تست بنویسید.
- در پرامپتهای خود، صراحتاً بخواهید که مدل پس از هر مرحله، شواهدی از پایداری دادهها (مانند اسکرینشات یا لاگ دیتابیس) ارائه دهد.
- هر ویژگی جدید را تنها پس از پاس شدن تستهای قرارداد قبلی اضافه کنید.
اما برای کسانی که به دنبال اتوماسیون کاملتر هستند، پروتکلهای جدید ارتباطی بین مدلها مسیرهای جذابتری را باز میکنند — به بررسی ما دربارهی MCP مراجعه کنید.
گفتگو