تصور کنید ساعت ۲ صبح است و شما با یک مدل هوش مصنوعی در حال دیباگ کردن هستید؛ مدل با اطمینانی کامل بخشی از کد شما را که برای بهینه‌سازی عملکرد نوشته شده بود، به عنوان «باگ» شناسایی و آن را «تعمیر» می‌کند. درست در همین لحظه، ساعت‌ها تلاش برای رسیدن به حداکثر سرعت از بین می‌رود و شما با یک نقص فنی جدید روبرو می‌شوید. کد اغلب یک شاهد بی‌گناه است؛ به شما می‌گوید چه کاری انجام می‌دهد، اما به ندرت توضیح می‌دهد که چرا به این شکل نوشته شده است.
برای پر کردن این شکاف، توسعه‌دهنده‌ای به نام Kev — که پروژه‌های متنوعی از اپلیکیشن‌های خواندن برای کودکان دیسلکسیک و برنامه‌های مدیتیشن گرفته تا نقشه‌های دسکتاپ و روباه‌های نوار منو (menu-bar foxes) می‌سازد — سیستم MurphySig را پیاده کرد. این یک قرارداد سخت‌گیرانه برای کامنت‌گذاری در کدنویسی با کمک هوش مصنوعی است تا منشأ و قصد نویسنده را ردیابی کرده و از بازگشت‌های هزینه‌بر (Regressions) جلوگیری کند.
طبق گزارش‌های منتشر شده، این پدیده که «رانش هویت» (Identity Drift) نام دارد، یکی از بزرگ‌ترین چالش‌های همکاری انسان و ماشین در سال ۲۰۲۶ است. زمانی که یک توسعه‌دهنده با مدل‌هایی مانند Claude، Gemini و دیگران کار می‌کند — گاهی در ساعت ۲ صبح با هر مدلی که در آن لحظه در دسترس باشد — با این مشکل مواجه می‌شود. زمانی که یک جلسه جدید مدل، یک ثابت (Constant) خاص را به اشتباه یک باگ تشخیص داده و آن را «اصلاح» کند، در واقع یک بهینه‌سازی عملکردی را بدون اطلاع از دلیلش نابود کرده است.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی حافظه بلندمدت عامل‌های هوش مصنوعی اشاره کردیم، این مشکل در سال ۲۰۲۶ با حرکت عامل‌های هوش مصنوعی به سمت مدیریت حافظه بلندمدت خودگردان، بسیار حادتر شده است. این چالش با استفاده از فایل‌های حافظه محلی برای توقف بازنشانی زمینه در جلسات هوش مصنوعی تا حدی قابل مدیریت است، اما بدون سوابق منشأ، توسعه‌دهنده پس از شش ماه فایلی را باز می‌کند و هیچ ایده‌ای ندارد که چه راهکارهایی امتحان شده، چه چیزهایی شکست خورده یا نویسنده قبلی در مورد چه بخشی تردید داشته است. این بستر ضروری معمولاً در لحظه بستن ویرایشگر کد، تبخیر می‌شود.
MurphySig در واقع یک دفترچه تغییرات زنده است که مستقیماً درون کد جای می‌گیرد. این سیستم ابزار جدیدی نیست، بلکه یک فرمت خاص برای کامنت‌هاست تا قصد نویسنده و مدل را مستند کند. یک مثال واقعی از کدهای M1K3 نشان می‌دهد که چگونه سطح اطمینان (Confidence) از مقدار ۰.۵ در صبح به ۰.۹ در شب، پس از یک اجرای موفق روی دستگاه (on-device run)، ارتقا یافته است.
به نقل از مستندات این پروژه، هر امضای MurphySig شامل متادیتای دقیق زیر است:
- امضاکننده: ترکیب انسان و مدل (مثلاً Kev + claude-sonnet-5).
- تاریخ: زمان دقیق ویرایش (مثلاً ۱۴ ژوئیه ۲۰۲۶).
- امتیاز اطمینان: یک مقدار عددی بین ۰.۰ تا ۱.۰ که نشان‌دهنده میزان قطعیت است.
- زمینه: یادداشتی درباره وضعیت کد، مثلاً اینکه آیا این کد یک «اسپایک» (Spike) آزمایشی است یا اجرای روی دستگاه در انتظار است.
- معیارهای فنی: اندازه‌گیری‌های دقیق؛ به عنوان مثال، لود شدن مدل gemma-4-12B-it-4bit با ۲۶۵ توکن پرومپت/تصویر و ۸۳۳۳ مگابایت حافظه پیک (Peak Memory).
- حلقه بازبینی: یک امضای ثانویه از سوی یک مدل متفاوت (مثلاً claude-fable-5) برای تأیید تغییرات.
بر اساس بررسی‌های انجام شده در موتور نقشه‌برداری Cartogram، اثر این روش کاملاً ملموس است. در یک مورد مستند، سه مدل مختلف طی دو ماه روی یک فایل کار کردند. در ژوئن، یک مدل بازبینی عملکردی را ثبت کرد که به‌روزرسانی‌های رانش (drift updates) را به «فواصل ۱ ثانیه‌ای» منتقل کرد و مصرف CPU را از ۵۲٪ به صفر رساند. اما در جولای، یک مدل جدیدتر دید که مقدار ثابت ارسال شده در واقع ۰.۱ ثانیه است؛ این مدل تصور کرد که این یک باگ است و آن را «اصلاح» کرد. در سخت‌افزار، این اتفاق باعث ایجاد لگ‌های شدید شبیه به «استاپ‌موشن» شد.
چون اصلاحیه نهایی دوباره در فایل نوشته شد — با این یادداشت که مقدار ۰.۱ ثانیه «تحمیل‌کننده بار» (load-bearing) است و یادداشت ماه ژوئن اشتباه بود — این خطا تبدیل به بخشی از حافظه فایل شد. این کار تضمین می‌کند که هیچ انسان یا مدلی دوباره این مقدار ثابت را «اصلاح» نکند. این proves می‌کند که هزینه رانش نیازمند ابزارهای اندازه‌گیری (Instruments) است، نه استدلال (Reasoning).
تا آگوست ۲۰۲۶، Kev حدود ۴۵۰ فایل امضا شده در ۱۴ مخزن مختلف را گزارش داده است. این‌ها شامل زبان‌های Swift، Kotlin، Python، shell و حتی تکه‌هایی از تنظیمات zsh هستند که در مجموع ۳۴۹ خط بازبینی (Review) دارند. حلقه بازبینی تقریباً از هر پنج مورد، یک بار بسته می‌شود.
آزمایش‌ها نشان می‌دهد که این فرمت مانند یک چک‌لیست دستی عمل می‌کند که توسعه‌دهندگان را مجبور به ثبت حقایق می‌کند. وقتی قانون «هرگز منشأ را جعل نکن» در بستر هوش مصنوعی اعمال شد، نرخ جعل نویسندگی کد از ۱۱٪ به ۰٪ رسید. اگرچه فایل‌های امضا شده در ۶ خانواده مدل مختلف، بریفینگ‌های (Briefings) به مراتب بهتری دریافت می‌کنند، اما دستاورد اصلی خودِ اطلاعات است؛ یک کامنت ساده با همان حقایق، بیشترِ کار را انجام می‌دهد. فرمت MurphySig صرفاً تضمین می‌کند که آن حقایق نوشته شوند.
این موضوع در عصر عامل‌های (Agent) خودگردان مثل OpenClaw و Hermes حیاتی‌تر می‌شود. زمانی که این عامل‌ها شروع به ویرایش فایل‌های هویتی خود (مثل SOUL.md، MEMORY.md و USER.md) می‌کنند، این سوابق منشأ حیاتی هستند. بدون آن، یک عامل ممکن است با شخصیت یا رفتاری متفاوت بیدار شود و نه کاربر و نه خودِ هوش مصنوعی ندانند این تغییر چه زمانی و چرا رخ داده است.
با اعمال بلوک کامنت MurphySig بر روی ویرایش‌های مربوط به شخصیت، هویت یک عامل به جای فراموشی، یک دفترچه تغییرات پیدا می‌کند. برای پیاده‌سازی این سیستم، توسعه‌دهندگان می‌توانند از دستور curl -sL murphysig.dev/sign >> AGENTS.md استفاده کنند یا به صورت دستی فایل‌هایی مانند CLAUDE.md را برای کاربران Claude Code به‌روزرسانی کنند.
در نهایت، این رویکرد درباره احترام به انسان، مدل یا عاملی است که بعداً فایل را باز می‌کند. سریع ارسال کنید، با ظرافت بسازید و اثر خود را امضا کنید.
گام بعدی شما
- اگر از مدل‌های مختلف برای یک پروژه استفاده می‌کنید، یک قالب ثابت برای ثبت «دلیل تغییر» (The Why) در کامنت‌ها تعریف کنید.
- در پرامپت‌های خود به مدل دستور دهید هر تغییر حیاتی را با ذکر «امتیاز اطمینان» مستند کند.
- فایل‌های پیکربندی عامل‌های خود را با یک سیستم نسخه‌بندی متنی (مانند MurphySig) مجهز کنید تا از تغییرات ناخواسته در رفتار عامل جلوگیری شود.
اما این نظم‌دهی به کد تنها بخشی از ماجراست؛ نحوه مدیریت حافظه در سطح سخت‌افزار برای این مدل‌ها حتی پیچیده‌تر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو