تصور کنید یک برنامهنویس برای پیادهسازی یک قابلیت امنیتی به مستندات فنی تکیه میکند، اما متنی که با اطمینان کامل نوشته شده، صرفاً یک توهم مدل زبانی است. در دنیای مهندسی نرمافزار، هر صفحه از مستندات در واقع مجموعهای از «قولها» است و سپردن تمام این قولها به هوش مصنوعی، ریسک فاجعهباری را به همراه دارد.
بسیاری از تیمهای فنی با مستندات تولیدشده توسط هوش مصنوعی مانند یک فایل واحد برخورد میکنند؛ یعنی یا کل فایل را میپذیرند یا هیچکدام را. طبق گزارشهای فنی، مدلها در تولید جداول پارامترها بسیار 능-سند هستند، اما هیچ صلاحیتی برای تضمین حاشیه امنیتی یا تاریخ انقضای یک قابلیت ندارند. این شکاف باعث ایجاد «شکستهای خاموش» میشود؛ جایی که متنی صیقلخورده و متقاعدکننده، یک خطای فکتیکال یا توهم (Hallucination) — شبیه دوستی که خاطرهای را با اطمینان اما کاملاً اشتباه تعریف میکند — را میپوشاند.
برای حل این مشکل، MonkeyCode یک گردشکار دوطرفه را پیشنهاد میکند که در آن مدل زبانی تنها نقش سازنده داربست را دارد و انسان تنها امضاکننده تصمیمات حساس است. همانطور که در تحلیلهای قبلی ما درباره امنیت مدلهای بازمتن اشاره کردیم، اعتماد کورکورانه به خروجی مدلها در محیطهای عملیاتی، بزرگترین نقطه ضعف استقرار هوش مصنوعی است. این چالش با نرخ شکست بالای عاملهای پیشرو در اجرای سیاستهای سازمانی همسو است که نشان میدهد مدلها حتی در محیطهای کنترلشده نیز در رعایت محدودیتهای سختگیرانه دچار لغزش میشوند. بر اساس راهنمای منتشرشده در ۲۸ اوت ۲۰۲۶، این رویکرد مرز دقیقی بین «بازنویسیهای مکانیکی» و «قضاوتهای رسمی» ایجاد میکند.
ماتریس تفویض اختیار
در این سیستم، بخشهایی که مدل مینویسد «مصرفی» هستند و باید بازنویسی شوند، اما بخشهای تحت مالکیت انسان «رسمی»اند و باید امضا شوند. این ماتریس به شرح زیر است:
- بخشهای مدل-محور (مصرفی):
- مثالهای استفاده: مدل داربست را میسازد و انسان معنای آن را با رفتار واقعی سیستم میسنجد.
- توضیحات پارامترها: بازگویی مکانیکی از امضاهای عمومی کد.
- مراحل نصب و راهاندازی: مواردی که با اجرا کردن قابل تأیید هستند، نه با تکیه بر اعتبار نویسنده.
- توضیح پیامهای خطا: استخراجشده از لاگهایی که انسان در اختیار مدل قرار میدهد.
- بخشهای انسان-محور (رسمی):
- تضمینهای سازگاری: قولهایی که بار پشتیبانی و مهاجرت سیستم را به دوش میکشند.
- زمانبندی توقف پشتیبانی (Deprecation): برنامهای که توسط مدیریت تعیین میشود، نه تولید متن.
- ملاحظات امنیتی: ارزیابی ریسک که تنها بر عهده مهندس مسئول است.
- محدودیتهای شناختهشده: تعیین مرزهای پروژه که نیازمند قضاوت انسانی است.
- منطق طراحی و موازنهها: توضیح اینکه چرا یک راهکار بر جایگزینهایش برتری داشت.
این جدول باید در کنار مستندات در مخزن کد قرار گیرد تا در زمان ادغام (Merge)، مرز مالکیت مشخص باشد. اگر مدل در بخشی از محدوده انسان بنویسد، خروجی باید صرفنظر از میزان اعتمادبهنفس متن، به عنوان «پیشنویس» تلقی شود.
گردشکار چهار مرحلهای
این فرآیند از یک دستانداز سختگیرانه چهار مرحلهای پیروی میکند:
۱. تعیین مالکیت طرح: ایجاد یک فایل Markdown با سرتیترهای نهایی و برچسب draft: model یا owner: human. بخشهای انسانی با عبارت State: needs owner شروع میشوند تا مدل بداند نباید به آنها دست بزند.
۲. پُر کردن توسط مدل: مدل تنها بخشهای مصرفی را مینویسد. در اینجا استنتاج (Inference) — همان لحظهای که مدل واقعاً جواب تولید میکند، شبیه آشپزی بعد از یادگیری دستور پخت — به دلیل مصرفی بودن متن، بدون ریسک است. به نقل از MonkeyCode، دسترسی رایگان به مدلها برای این مرحله کافی است زیرا متن هرگز عیناً منتشر نمیشود.
۳. تأیید انسانی: یک انسان نامبرده باید هر بخش رسمی را با خط Reviewed by: name | date امضا کند. این کار مالکیت را از یک خاطره تیمی به یک حقیقت قابل جستوجو تبدیل میکند. بدون امضا، هیچ فایلی ادغام نمیشود. این تفکیک دقیق بین آمادهسازی توسط مدل و تایید نهایی، مشابه استراتژی است که WebAZ برای جداسازی درخواستها از تاییدات تجاری به کار گرفت تا ریسک خطاهای خودکار را کاهش دهد.
۴. سنجش انحراف: تیم یک اسکریپت پایتون را اجرا میکند تا فاصله بین پیشنویس اولیه هوش مصنوعی و نسخه نهایی را اندازه بگیرد.
این اسکریپت با استفاده از عبارتهای منظم (Regular Expressions)، هر دو فایل را بر اساس سرتیترها تفکیک کرده و بخشها را به چهار دسته «تغییر یافته»، «دستنخورده»، «مفقود» یا «بخش رسمی دستنخورده» تقسیم میکند. برای مثال، اجرای دستور python docs_divergence.py ممکن است چنین گزارشی بدهد:
changed ## Usage examples(تأیید میکند که حلقه بازبینی کار کرده است)untouched ## Install and setup steps(تنها در صورت تأیید با اجرا پذیرفتنی است)WARNING: owned section not edited ## Security considerations(هشدار شکست در بازبینی؛ مالکیت اعلام شده اما اعمال نشده است)
این رویکرد تمرکز را از «کیفیت هوش مصنوعی» به «مسئولیتپذیری انسانی» منتقل میکند و مانع از آن میشود که بازبین، متنی صیقلخورده را بخواند و به اشتباه فرض کند ادعای فنی زیربنایی آن درست است.
برای شما به عنوان کاربر، این یعنی تغییر در نحوه تعامل با مدلهای زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد. شما دیگر از هوش مصنوعی نمیخواهید «مستندات را بنویسد»، بلکه از او میخواهید «شکافهای مکانیکی» را پیرامون تصمیمات کلیدی شما پُر کند.
محدودیتها و موارد کاربرد
البته این روش محدودیتهایی دارد. اسکریپت انحراف، تغییرات متنی را ردیابی میکند، نه «حقیقت رندر شده» را؛ بنابراین تغییرات در فاصلهها (Whitespace) میتواند بازبینیهای انجامنشده را پنهان کند. همچنین، سرتیترهای تکراری باعث اختلال در نقشه بخشها میشوند.
نقاط شکست دیگر عبارتند از:
- کمبود بازبین: تیمهایی که بازبین نامبرده ندارند، نباید از خط امضا استفاده کنند؛ تشریفات توخالی بدتر از نبود آن است.
- محتوای بصری: مستنداتی که متکی بر نمودار هستند با این روش سازگار نیستند، زیرا معنا در تصویر است، نه در تفاضل متنی (Text Diff).
تیمهایی که صفحات زیادی را از یک قالب واحد تولید میکنند، بیشترین بهره را از این سیستم میبرند. توسعهدهندگان تکنفره نیز میتوانند از آن برای ایجاد یک حلقه پیشنویس ارزان قبل از صرف زمان برای نوشتن نهایی استفاده کنند.
گام بعدی شما
- ماتریس تفویض اختیار را برای پروژه فعلی خود تعریف کنید و بخشهای «رسمی» را از «مصرفی» جدا کنید.
- یک اسکریپت ساده برای مقایسه Diff بین پیشنویس AI و نسخه نهایی در CI/CD خود بگنجانید.
- قانون «بدون امضا، بدون ادغام» را برای بخشهای حساس امنیتی در تیم خود اجرا کنید.
اما مدیریت این فرآیند در مقیاس سازمانهای بزرگ، چالشهای متفاوتی دارد — به تحلیل ما درباره پروتکلهای همکاری انسان و عامل در پروژههای نرمافزاری مراجعه کنید. در این راستا، بررسی محدودیتهای سخت در انتقالهای عاملهای هوش مصنوعی میتواند دیدگاههای تکمیلی درباره نحوه مدیریت محدودیتها در سیستمهای چندمرحلهای ارائه دهد.
گفتگو