اگر تصور کنید یک عامل هوش مصنوعی در حال اصلاح کدهای شماست، اما دقیقاً نمیداند چه رفتاری در محیط واقعی کاربر رخ میدهد، احتمالاً با یک توهم (Hallucination) — شبیه دوستی که خاطرهای را اشتباه تعریف میکند — روبرو خواهید شد. یک عامل AI میتواند متنی بسیار روان تولید کند، اما نمیتواند یک شرط استقرار فراموششده یا رفتاری که هیچکس ثبت نکرده را از فضای خالی بازیابی کند.
در ۱۴ ژوئیه ۲۰۲۶، چارچوبی جدید پیشنهاد شد تا «پوشش مستندات» را بهجای یک هدف کیفی، به یک تصمیم محصولِ قابل اندازهگیری تبدیل کند. طبق اعلام نویسندگان این طرح، متون تولیدشده توسط مدلها اغلب خلأهای موجود در شواهد عملیاتی را میپوشانند و همین موضوع منجر به شکست عاملها در مقیاس واقعی میشود. این چالشها در حوزههای حساستر، مانند مدیریت دادههای حساس، میتواند اثرات گستردهتری داشته باشد؛ چنانکه پیشتر به شکافهای حاکمیتی در دادههای کارکنان و نقاط کور امنیتی عاملهای AI اشاره شده است.
این رویکرد در زمانی مطرح میشود که توسعهدهندگان با افسانهی «عصر پس از مستندات» دستوپنجه نرم میکنند. همانطور که در بحثهای گذشتهی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، تکیه بر توانایی مدل بدون داشتن دادههای مرجع، ریسک خطا را بالا میبرد. در محیطهای نرمافزاری عملی، تفاوت بنیادین میان نوشتن یک متن توصیفی و حفظ یک «مشاهدهی عملیاتی دقیق» وجود دارد. این دقت در مستندسازی و ردیابی شواهد، مستقیماً بر کاهش هزینههای عملیاتی اثر میگذارد، مشابه آنچه در پژوهش مربوط به کاهش خطای قیمتگذاری ریسک در عاملهای AI مشاهده شد.
بدون یک رکورد ساختاریافته، عامل ممکن است برای باگی که اصلاً نمیتواند آن را بازتولید کند، راهکاری خیالی ارائه دهد. هدف این است که مشخص شود آیا یک آیتم کاری، شواهد مستند کافی دارد تا عامل بر اساس آن عمل کند و سپس یک انسان بتواند آن را بازبینی کند یا خیر.
به گزارش وبسایت dev.to، راهکار پیشنهادی یک کارت امتیازدهی ۱۰۰ امتیا ownی است که از پنج بُعد تشکیل شده و هر یک ۲۰ امتیاز دارند. هر بُعد را میتوان در سه حالت «مستند» (۱۰۰٪ امتیاز)، «جزئی» (۵۰٪) یا «غایب» (۰٪) رتبهبندی کرد:
- مسئله (Problem): شکست مشاهدهشده یا نیاز کاربر.
- بازتولید (Reproduction): ترتیب وضعیتها و اقداماتی که مشکل را آشکار میکند.
- رفتار موردانتظار (Expected Behavior): قرارداد عملکردی، شامل تعاملات ثانویه.
- تأییدیه (Verification): بررسیهای انجام شده، محیط اجرا و مالکیت نتیجه.
- محدودیتها (Limitations): موارد ناشناخته، موارد استثنا و مرزهای شواهد.
برای نمایش کاربردی این مدل، نویسنده آن را روی یک مورد خاص در پروژه MonkeyCode (مورد ۸۲۴ و درخواست تغییر ۸۵۹) پیاده کرد. این مورد مربوط به لینکهای Markdown در مسیر /workspace/... بود که بهجای پیشنمایش فایل، صفحه اصلی برنامه را باز میکردند. در اینجا باید تفکیکی بین «کلیک معمولی»، «باز کردن در تب جدید» و «کپی لینک» ایجاد میشد.
امتیاز نهایی این مورد ۸۰ از ۱۰۰ شد. برای مثال، بُعد «بازتولید» بهدلیل نبود اطلاعات دقیق از مرورگر و محیط استقرار، امتیاز جزئی گرفت. این عدد نمیگوید که راهکار خوب است یا بد؛ بلکه به تیم میگوید دقیقاً کجا نیاز به ثبت تستهای بیشتر است تا حدسزنی عامل (Agent) کاهش یابد.
برای جلوگیری از دستکاری اعداد، یک اسکریپت Node.js بدون وابستگی (node score-docs.mjs doc-coverage.json) راهاندازی شده تا تأیید کند مجموع وزنها ۱۰۰ است و هر بُعد به شواهد مشخصی ارجاع میدهد. این سازوکار مانع از آن میشود که یک داشبورد زیبا، یک معیار فنی نامعتبر را پنهان کند.
این تغییر، نقش مستندات را از یک آرشیو ایستا به یک دروازهی گردشکار (Workflow Gate) تبدیل میکند. بسته به نوع کار، آستانههای متفاوتی تعریف میشود:
- اکتشاف (Exploration): پوشش کمتر پذیرفته است، اما خلأها باید به عامل اعلام شوند.
- پیادهسازی روتین: داشتن مسئله، رفتار موردانتظار و تأییدیه الزامی است.
- تغییرات امنیتی یا بازگشتناپذیر: پوشش ۱۰۰٪ و تأیید انسانی اجباری است.
- پاسخ به حوادث (Incident Response): ابتدا رفع مشکل ارسال شده و سپس شواهد غایب بهعنوان «بدهی فنی» با یک مالک مشخص ثبت میشوند.
با ردیابی دورههای شفافسازی و عدم تطابقهای پیدا شده توسط بازبین، تیمها میتوانند بسنجند که آیا این کارت امتیازدهی واقعاً نرخ بازکاری را پیشبینی میکند یا خیر. این مسیر، ادغام AI را از فضای «حسکردنیها» (Vibes) به سمت یک حسابرسی دقیق از دانستههای واقعی عامل در مقابل حدسهای او میبرد.
گام بعدی شما
- برای هر تیکت یا ایشو در پروژهتان، پنج بُعد ذکر شده را بررسی کنید و ببینید کدام یک غایب است.
- برای تغییرات حساس (مثل دیتابیس)، قانون «پوشش ۱۰۰٪» را پیش از اجازه به عامل AI اجرا کنید.
- یک اسکریپت ساده برای اعتبارسنجی JSON مستندات خود بنویسید تا از صحت امتیازات مطمئن شوید.
اما اثر این سختگیری بر سرعت توسعه در تیمهای کوچک چگونه است؟ در گزارش بعدی، بررسی خواهیم کرد که چگونه تعادل بین «سرعت» و «دقت مستندات» بر بازگشت سرمایه AI اثر میگذارد.
گفتگو