تصور کنید یک برنامه‌نویس در تیمی کوچک است که هر روز ده‌ها تکه کد توسط هوش مصنوعی تولید می‌شود؛ اما او متوجه نمی‌شود که یک منطق پیچیده، سه بار با نام‌های مختلف در نقاط مختلف پروژه تکرار شده است. این دقیقاً همان نقطه‌ای است که «تکرار سایه‌ای» (Shadow Duplication) آغاز می‌شود و بدهی فنی پروژه را به شکلی نامرئی افزایش می‌دهد.
عامل‌های هوش مصنوعی زاینده (Generative AI) — مثل Claude Code و Cursor — در نوشتن توابع عالی هستند، اما عادت دارند منطق‌های تجاری را با تغییر جزئی در فرمت یا نام متغیرها تکرار کنند. این تغییرات باعث می‌شود ابزارهای استاندارد جست‌وجو یا Diff نتوانند این کپی‌ها را پیدا کنند. طبق گزارش وب‌سایت dev.to در ۲۴ ژوئیه ۲۰۲۶، این مشکل زمانی رخ می‌دهد که توسعه‌دهنده از یک عامل (Agent) — همان دستیار هوشمندی که می‌تواند به‌طور مستقل ابزارها را اجرا کند — می‌خواهد یک منطق را به یک ابزار کاربردی (Reusable Utility) تبدیل کند. در حالی که تابع جدید به‌طور کامل کار می‌کند، اما چند روز بعد، نسخه‌ای تقریباً مشابه از همان منطق در سرویس دیگری ظاهر می‌شود. نام متغیرها تغییر کرده و فاصله‌ها برای فرمت‌های مدرن اصلاح شده‌اند، اما پیچیدگی زیربنایی — یعنی پیاده‌سازی ساختاری واقعی — دقیقاً یکسان است. این پدیده در واقع بخشی از چالش بزرگتر ریدفت کد در هوش مصنوعی است که در آن خروجی مدل‌ها به‌مرور با استانداردهای سخت‌گیرانه پروژه فاصله می‌گیرند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اتکای بیش از حد به خروجی‌های مدل بدون نظارت ساختاری، ریسک‌های مدیریتی ایجاد می‌کند. در اینجا، تکرار سایه‌ای در یک grep ساده یا یک diff معمولی دیده نمی‌شود. یک بازبین انسانی هم ممکن است در حین بررسی PR آن را نادیده بگیرد چون سینتکس سطح اول کد تازه و جدید به نظر می‌رسد. اما در حالی که کدبیس رشد می‌کند، بدهی فنی شما فقط انباشته نمی‌شود، بلکه «جهش» (Mutate) می‌کند. این یک شکست بحرانی در تشخیص‌های مبتنی بر سینتکس است، زیرا ابزارهای استاندارد بر تطبیق تحت‌اللفظی رشته‌ها (Literal String Matching) تکیه دارند. اگر توسعه‌دهنده let userCount = 0 را به const totalUsers = 0 تغییر دهد، اکثر ابزارهای ابتدایی آن را به عنوان یک بلوک کد جدید و منحصر‌به‌فرد علامت‌گذاری می‌کنند.
برای مقابله با این وضعیت، سرور Code Clone Detector بر اساس پروتکل زمینهٔ مدل (MCP) — استانداردی که اجازه می‌دهد مدل‌ها به داده‌ها و ابزارهای خارجی دسترسی داشته باشند — تمرکز را از «آنچه کد می‌گوید» به «آنچه کد هست» تغییر می‌دهد. برای یک عامل هوش مصنوعی، «شخصی‌سازی» کد — یعنی تغییر نام متغیرها برای تطبیق با زمینه محلی یا پاک‌سازی کامنت‌ها — حالت پیش‌فرض عملیاتی است. بر اساس مستندات این ابزار، بدون تحلیل ساختاری، شما عملاً نسبت به ۸۰٪ تکرارهایی که در جریان‌های کاری عامل‌محور (Agentic) ایجاد می‌شوند، نابیناهستید.
خط لوله نرمال‌سازی
قلب این سیستم ابزار generate_normalized_signature است که احتمالاً مهم‌ترین بخش این خط لوله است. این ابزار کد را در سه مرحله مشخص پردازش می‌کند:
- حذف تمامی کامنت‌ها.
- یکسان‌سازی تمام فاصله‌های خالی (تبدیل تب‌ها و اسپیس‌ها به یک فرمت یکپارچه).
- بی‌نام‌سازی متغیرها با جایگزینی نام‌های خاص با توکن‌های عمومی.
این فرآیند یک «اسکلت ساختاری» می‌سازد. برای مثال، اگر دو تابع هر دو روی یک آرایه پیمایش کنند، یک شرط null را چک کنند و یک شمارنده را افزایش دهند، امضای نرمال‌شده آن‌ها تقریباً یکسان خواهد بود، فارغ از اینکه نام متغیر در کد اصلی index باشد، i باشد یا counter.
این رویکرد به عامل اجازه می‌دهد تا تحلیل ساختاری را بدون نیاز به یک پارسر سنگینِ «درخت نحو انتزاعی» (AST) در پنجره بافت (Context Window) خود انجام دهد. در واقع، این ابزار مسئله را از «درک معنایی» (Semantic Understanding) به «تطبیق ساختاری» (Structural Matching) تقلیل می‌دهد.
لایه‌های تشخیص
این سرور برای شکار انواع مختلف کپی‌ها، دو لایه شناسایی مجزا دارد:
- کپی‌های ساختاری یکسان: با استفاده از
identify_exact_duplicatesو اعمال هش‌های قطعی (Deterministic Hashing) روی امضاهای نرمال‌شده، کپی-پیست‌های سریع را می‌گیرد؛ یعنی مواردی که عامل یک بلوک را تکرار کرده و فقط نام تابع را تغییر داده است. این روش بسیار سریع است. - تطابق‌های نزدیک: با استفاده از الگوریتم فاصله لِونشتاین (Levenshtein distance)، فاصله ویرایشی بین امضاها را محاسبه می‌کند تا «کپی‌های تکامل‌یافته» (Evolved Clones) را پیدا کند که ابزارهای استاندارد نادیده می‌گیرند.
در تطابق‌های نزدیک، ابزار پاسخ ساده‌ی بله/خیر نمی‌دهد. کاربران می‌توانند آستانه شباهت (Similarity Threshold) را بین ۰ و ۱ تنظیم کنند. مقدار پیش‌فرض روی ۰.۸ تنظیم شده است. اگر عامل بلوکی با شباهت ۰.۸۵ پیدا کند، این نشان‌دهنده تفاوت ساختاری بسیار اندک است؛ مثلاً فقط یک شرط اضافی یا نوع حلقه کمی متفاوت است.
این سازوکار، هوش مصنوعی را از یک تولیدکننده ساده به یک «ناظر کد» (Code Steward) تبدیل می‌کند. جریان کاری را تصور کنید که در آن از یک عامل می‌خواهید ویژگی جدیدی را پیاده‌سازی کند. پس از نوشتن کد، عامل از طریق یک فراخوانی ابزار MCP، سرور Code Clone Detector را برای اسکن کدبیس موجود فعال می‌کند. در این لحظه عامل ممکن است متوجه شود: «صبر کن، من همین حالا منطق calculateTax را دوباره ساختم در حالی که این منطق پیش از این در utils/finance.ts وجود دارد؛ پس باید کد را بازسازی کنم تا از تابع موجود استفاده کند».
برای توسعه‌دهندگان، این یعنی مسئولیت حفظ اصل DRY (Don't Repeat Yourself یا تکرار نکن) از بازبینی دستی انسان مستقیماً به چرخه اجرای خودِ عامل منتقل می‌شود. با ادغام این مرحله حسابرسی (Audit)، تیم‌ها می‌توانند از انباشت «سایه‌هایی» که معمولاً منجر به بحران‌های نگهداری بلندمدت می‌شوند، جلوگیری کنند. در واقع، این ابزار از تبدیل پروژه به یک «کدبیس وایب‌کد شده» جلوگیری می‌کند؛ همان وضعیتی که سرویس‌هایی مانند Slopfix برای بازسازی و اصلاح آن‌ها هزینه‌های گزافی دریافت می‌کنند.
کاربران می‌توانند این قابلیت را از طریق Vinkius و با استفاده از یک توکن اتصال فعال کنند. این روش نیاز به مدیریت محیط‌های محلی یا فراخوان‌های پیچیده OAuth را از بین می‌برد. شما می‌توانید این سرور را در آدرس https://vinkius.com/mcp/code-clone-detector پیدا کنید.
گام بعدی شما
- اگر از Cursor یا Claude Code استفاده می‌کنید، سرور Code Clone Detector را از طریق Vinkius متصل کنید.
- آستانه شباهت (Similarity Threshold) را بر اساس پیچیدگی پروژه خود بین ۰.۷ تا ۰.۹ تنظیم کنید.
- در پرامپت‌های سیستمی خود، عامل را موظف کنید پیش از Commit نهایی، یک بار عملیات شناسایی کپی‌های ساختاری را اجرا کند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو