تصور کنید شنبه صبح با ایده‌ای برای ساخت یک طبقه‌بندی‌کننده گزارش‌های خطا شروع می‌کنید و تا ظهر صفحه‌ای زیبا می‌سازید، اما نمی‌توانید دقیقاً بگویید مدل در هر مرحله چه گفته است. این تله‌ای است که بسیاری از توسعه‌دهندگان در آن می‌افتند: ساخت یک رابط کاربری صیقل‌خورده پیش از داشتن یک مدل قابل‌اعتماد. آن‌ها ساعت نه شنبه لپ‌تاپ را باز می‌کنند و ایده‌ای برای طبقه‌بندی گزارش‌های باگ دارند. تا ظهر، صفحه‌ای دارند که تمام شده به نظر می‌رسد، اما نمی‌توانند آنچه مدل واقعاً گفته است را بازپخش کنند. تا روز یکشنبه، آن‌ها حتی پرامپت اصلی را به یاد نخواهند آورد. این رویکرد نمای ظاهری از پیشرفت ایجاد می‌کند در حالی که فقدان یک قرارداد تکرارپذیر را پنهان می‌سازد.
به نقل از یک گزارش منتشر شده در ۲۱ سپتامبر ۲۰۲۶، یک خط متن در قالب JSONL (جیسون‌لاین) بسیار صادقانه‌تر از یک جعبه چت درخشان است. بسیاری از دموهای هوش مصنوعی امروز بیشتر شبیه «نمایش تئاتر» هستند تا اثبات مهندسی. توسعه‌دهندگان اغلب پیش از آنکه قراردادی تکرارپذیر برای خروجی مدل داشته باشند، روی ظاهر برنامه تمرکز می‌کنند و در نهایت پرامپت‌های اولیه را فراموش می‌کنند. این چالش‌ها در واقع بخشی از ۹ شکاف مهندسی هستند که باعث شکست اپلیکیشن‌های مدل زبانی در محیط عملیاتی می‌شوند و نشان می‌دهند که چرا تکیه بر ظاهر دمو خطرناک است.
برای مقابله با این وضعیت، فلسفه MonkeyCode یک محدوده «بی‌رحمانه» برای پروژه‌های سریع آخر هفته پیشنهاد می‌دهد. در این رویکرد، هدف ساخت یک دستیار همه‌کاره و باز نیست، بلکه هدف ارسال یک فعل، یک داده ثابت (Fixture) و یک سیگنال زنده (Live Ping) است. همان‌طور که در تحلیل‌های قبلی ما درباره امنیت مدل‌های بازمتن اشاره کردیم، شفافیت در لایه‌های زیرین اهمیت بیشتری نسبت به لایه نمایش دارد. در اینجا محصول واقعی، خودِ نرم‌افزار نیست، بلکه مدرکی است که ثابت می‌کند نرم‌افزار درست کار کرده است. قانون آخر هفته ساده است: یک طبقه‌بندی‌کننده را همراه با یک ردپای کاغذی (Paper Trail) ارائه دهید. مدل تا زمانی که این ردپا کار نکند، اختیاری باقی می‌ماند. فراخوانی‌های زنده مدل باید آخرین مرحله باشند، نه اولین مرحله.
معماری اثبات
طبق گزارش وب‌سایت dev.to، یک دموی معتبر باید دقیقاً از چهار فایل و یک دستور تشکیل شود تا هیچ «حس کلی» (Vibe) جایگزین الزامات فنی نشود:
- prompt.txt: دستورالعمل‌های منجمد مدل را نگه می‌دارد. هر اجرا باید هش (Hash) این فایل را (با استفاده از
shasum -a 256) محاسبه کند تا مطمئن شویم پرامپت به‌طور پنهانی تغییر نکرده است. این هش در هر خط از تراکنش‌ها ذخیره می‌شود؛ اگر هش تغییر کند، خطوط قدیمی نامعتبر می‌شوند. - fixture.json: شامل یک گزارش خطای شناخته‌شده است. برای مثال، گزارشی با شناسه
rpt-001به نام "Null pointer in checkout" که حاوی یکTypeErrorاست. این فایل به عنوان یک خط پایه عمل می‌کند تا ثابت کند خط لوله داده‌ها بدون نیاز به فراخوانی شبکه کار می‌کند. این رویکرد مشابه الگوی Cassette است که با بازپخش داده‌ها، نشت‌های مهندسی را در دموهای عامل‌های هوش مصنوعی می‌بندد و از شکست دمو در لحظه اجرا جلوگیری می‌کند. - SKIPPED.md: فهرستی عمومی از قابلیت‌هایی است که توسعه‌دهنده صراحتاً از ساخت آن‌ها خودداری کرده است. این فایل بخشی از خودِ دمو است و در پایان هر اجرا چاپ می‌شود.
- classify.py: منطقی که داده‌های ثابت را بازپخش کرده، یک بار به مدل متصل می‌شود و نتیجه را به یک فایل تراکنش (Transcript) اضافه می‌کند.
قانون «یک فعل»
پیچیدگی دشمن اصلی پروژه‌های سریع آخر هفته است. این راهنما اصرار دارد که وظیفه هوش مصنوعی به یک فعل واحد محدود شود—در این مورد، طبقه‌بندی یک گزارش خطا. خروجی مدل نیز به یک مجموعه برچسب بسیار کوچک محدود شده است: 'bug' (خطا)، 'docs' (مستندات) یا 'unknown' (ناشناخته). دلیل طبقه‌بندی نیز باید در قالب یک جمله کوتاه باقی بماند.
اجبار به رعایت طرحواره (Schema Enforcement)
قرارداد داده‌ها پیش از هرگونه فراخوانی مدل، روی دیسک نوشته می‌شود. یک نتیجه معتبر باید دقیقاً به این شکل باشد: { "label": "bug", "reason": "Stack trace in the report body." }.
هر نتیجه‌ای که شامل کلیدهای JSON اضافی باشد، بدون هیچ بحثی رد می‌شود. فایل تراکنش‌ها باید این رد شدن‌های طرحواره را ثبت کنند، نه اینکه توسعه‌دهنده آن‌ها را به‌صورت دستی پاک کند. این امر توسعه‌دهنده را مجبور می‌کند تا پرامپت یا مدل را اصلاح کند، به‌جای آنکه کد را وصله‌پینه کند تا ناسازگاری مدل را پنهان نماید. تابع valid_payload به‌طور خاص بررسی می‌کند که کلیدها دقیقاً {"label", "reason"} باشند و دلیل (reason) رشته‌ای نباشد که بیش از ۱۴ کلمه طول داشته باشد.
اولویت‌بندی مسیر آفلاین
اتصال زنده به مدل آخرین مرحله است، نه اولین مرحله. گردش‌کار مستلزم آن است که ابتدا یک «مسیر داده ثابت» (Fixture Path) با استفاده از قوانین ساده کلمات کلیدی (Boring Keyword Rules) تایید شود، پیش از آنکه هرگونه API لمس شود. برای مثال، اگر متن شامل "typeerror" یا "null" باشد، برچسب «خطا» می‌گیرد؛ اگر شامل "typo" یا "readme" باشد، برچسب «مستندات» می‌گیرد.
این کار تضمین می‌کند که خط لوله داده‌ها فارغ از هوشمندی مدل، سالم است. این هسته مرکزی از هیچ شبکه و هیچ وضعیت پنهانی (Hidden State) استفاده نمی‌کند، به این معنی که می‌توان آن را در یک سفر با قطار دمو کرد. تنها پس از تایید داده‌های ثابت است که توسعه‌دهنده می‌تواند یک فراخوانی زنده را امتحان کند.
محدودیت‌های اجرای زنده
سیستم از یک محدودیت زمانی (Timeout) سخت‌گیرانه HTTP—معمولاً ۲۰ ثانیه—استفاده می‌کند تا اطمینان حاصل شود که هر فراخوانی متوقف شده، به عنوان شکست ثبت می‌شود. تکرار درخواست‌ها (Retries) ممنوع است زیرا آن‌ها سرورهای ناپایدار و پرامپت‌های لرزان را پنهان می‌کنند. به توسعه‌دهنده دستور داده شده است که از یک درخواست HTTP و یک تایم‌اوت استفاده کند، سپس متوقف شود و نتیجه را ثبت نماید.
سرویس MonkeyCode برای کسانی که پس از تایید داده‌های ثابت به یک فراخوانی زنده نیاز دارند، دسترسی رایگان به مدل و گزینه سرور رایگان ارائه می‌دهد. اسکریپت به یک MODEL_BASE_URL اشاره می‌کند و یک درخواست POST حاوی پرامپت و گزارش ارسال می‌کند. اگر پاسخ در بررسی طرحواره شکست بخورد، خطای ValueError("schema rejected") صادر می‌شود.
دروازه دمو
اثبات موفقیت، اسکرین‌شاتی از یک پنجره چت نیست. «دروازه دمو» تنها زمانی باز می‌شود که یک غریبه بتواند بدون توضیح توسعه‌دهنده، نتیجه را بازپخش کند. اگر آن‌ها به حافظه شما نیاز داشته باشند، شما در عبور از دروازه شکست خورده‌اید.
پرده نهایی دمو، اجرای دستور tail -n 1 transcripts.jsonl | python3 -m json.tool برای نمایش داده‌های خام است و در ادامه دستور cat SKIPPED.md اجرا می‌شود. این رویکرد با فایل تراکنش‌ها به عنوان تنها منبع حقیقت برخورد می‌کند. اگر فراخوانی زنده شکست بخورد اما داده‌های ثابت (Fixture) تایید شوند، آخر هفته همچنان موفقیت‌آمیز است زیرا خروجی خالی نیست. ردیف‌های زشت و خطاهای اجرای زنده به عنوان مدرکی برای نقاط ضعف مدل حفظ می‌شوند.
منطق لیست موارد حذف شده (Skip List)
نوشتن فایل SKIPPED.md پیش از نوشتن هر خط کد پایتون، یک محدودیت استراتژیک است. با فهرست کردن صریح آنچه ساخته نخواهد شد، توسعه‌دهنده از «خزش قابلیت‌ها» (Feature Creep) که آخر هفته را می‌بلعد، جلوگیری می‌کند. این لیست شامل موارد زیر است:
- بدون رابط کاربری چت (No chat UI)
- بدون حساب‌های کاربری (No user accounts)
- بدون استریم کردن توکن‌ها (No streaming tokens)
- بدون طوفان‌های تکرار درخواست (No retry storms)
- بدون ذخیره‌ساز برداری (No vector store)
- بدون داشبورد (No dashboard)
- بدون چیدمان موبایل (No mobile layout)
رابط‌های کاربری حذف شده‌اند چون قرارداد بین پرامپت و خروجی را می‌پوشانند. استریمینگ حذف شده است زیرا یک شیء JSON روی دیسک محلی بسیار تمیزتر ذخیره می‌شود. احراز هویت حذف شده است زیرا هنوز هیچ‌کس دیگری به مخزن کد دسترسی ندارد. این انضباط تضمین می‌کند که پروژه تا روز یکشنبه به پایان برسد.
جدول تصمیم‌گیری برای جلوگیری از خزش قابلیت‌ها
برای جلوگیری از تورم پروژه، راهنما یک جدول تصمیم‌گیری ارائه می‌دهد: اگر هش پرامپت با prompt.txt مطابقت دارد، ردیف را اضافه کنید؛ در غیر این صورت، یک فایل JSONL جدید شروع کنید. اگر طرحواره داده‌های ثابت معتبر است، اجازه --live را بدهید؛ در غیر این صورت، متوقف شوید. اگر کلیدهای اضافی در داده‌ها ظاهر شدند، ردیف را رد کنید اما ردیف داده‌های ثابت را نگه دارید. اگر لیست موارد حذف شده همچنان صادق است، دستور را ارسال کنید؛ در غیر این صورت، قابلیت اضافی را حذف کنید.
محدودیت‌ها و هشدارها
این گردش‌کار یک الگوی سریع برای آخر هفته است، نه یک پلتفرم. این روش مدل را آموزش نمی‌دهد، کیفیت مدل را رتبه‌بندی نمی‌کند و جایگزین یک مجموعه ارزیابی (Eval Suite) واقعی نمی‌شود. طبقه‌بندی‌کننده مبتنی بر قوانین عمداً یک جایگزین ساده (Stub) است تا خط لوله را ثابت کند؛ نباید به عنوان یک هوش مصنوعی واقعی عرضه شود.
علاوه بر این، JSONL روی دیسک یک گاوصندوق نیست، بنابراین گزارش‌ها باید مصنوعی و خسته‌کننده نگه داشته شوند. هش‌های پرامپت ثابت می‌کنند چه چیزی از دیسک ارسال شده است، نه لزوماً آنچه سرور استفاده کرده است. این روش نباید برای حوادث عملیاتی تولید، چت‌بات‌های عمومی یا بنچمارک‌های تامین‌کنندگان استفاده شود.
بررسی روز یکشنبه
تا روز یکشنبه، توسعه‌دهنده باید یک فایل پرامپت منجمد، یک ردیف داده تایید شده و احتمالاً یک ردیف اجرای زنده داشته باشد. اگر رابط کاربری اضافه شده باشد، قانون شکسته شده و رابط کاربری باید حذف شود. در اینجا مدل مهندسی نکرده است؛ بلکه توسعه‌دهنده با تعیین محدوده و ثبت دقیق، مهندسی کرده است. فایل تراکنش‌ها تنها مدرکی است که اهمیت دارد. این رویکرد به تغییراتی در استانداردهای ارزیابی مهندسی شباهت دارد، جایی که مستندسازی دقیق خطاها در حال جایگزینی بررسی‌های سنتی کد نهایی در فرآیندهای استخدام می‌شود.
این متدولوژی تعریف «دمو» را از یک تجربه بصری به یک حسابرسی داده‌ای تغییر می‌دهد. تمرکز را از اینکه هوش مصنوعی چگونه به نظر می‌رسد به اینکه هوش مصنوعی تحت مجموعه‌ای از محدودیت‌های منجمد چگونه رفتار می‌کند، منتقل می‌کند. منتظر ظهور الگوهای توسعه «ارزیابی-محور» (Eval-first) باشید، جایی که مجموعه تست محصول اصلی است و اپلیکیشن صرفاً پوششی برای آن تست‌هاست.
گام بعدی شما
- در پروژه بعدی خود، پیش از طراحی UI، یک فایل
SKIPPED.mdبنویسید و تمام وسوسه‌های افزودن قابلیت را در آن لیست کنید. - برای هر پرامپت، یک فایل متنی مجزا بسازید و از هش کردن آن برای ردیابی تغییرات استفاده کنید.
- به‌جای تکیه بر «حس خوب» از پاسخ‌های مدل، یک فایل JSONL برای ثبت تمام ورودی‌ها و خروجی‌ها ایجاد کنید.
اما تغییر تعریف «دمو» از یک تجربه بصری به یک حسابرسی داده‌ای، تنها آغاز یک روند بزرگ‌تر است؛ اثر این رویکرد بر ظهور الگوهای توسعه «ارزیابی-محور» (Eval-first) را در گزارش بعدی بررسی خواهیم کرد.
گفتگو