مهندسی کانتکست: چگونه با فریم‌ورک RPI از تولید کدهای بی‌کیفیت توسط هوش مصنوعی جلوگیری کنیم

مقدمه: مشکل پنهان استفاده از هوش مصنوعی در کدنویسی

ابزارهای کدنویسی هوش‌مصنوعی مثل GitHub Copilot، Cursor و Claude Code روی پروژه‌های کوچک و تازه (Greenfield) کد تمیز تولید می‌کنند، ولی روی کدبیس‌های بزرگ و قدیمی (Brownfield) خیلی زود افت می‌کنند — چون context اطرافی که یک مهندس باتجربه برای همان تصمیم استفاده می‌کند را ندارند. راه‌حل، فریمورک RPI است: اول کدبیس را Research کن، بعد تغییر را صریح Plan کن، سپس طبق همان پلن Implement کن — به‌جای اینکه مدل وسط تولید کد حدس بزند.

بسیاری از توسعه‌دهندگان گزارش می‌دهند که اگرچه سرعت تحویل کد بالا رفته، اما بخش قابل توجهی از زمانشان صرف اصلاح کدهای بدی می‌شود که هفته قبل توسط AI نوشته شده است. این کدهای بی‌کیفیت که در جامعه توسعه‌دهندگان با نام "Slop" (کد کثیف) شناخته می‌شوند، می‌توانند بدهی فنی (Technical Debt) قابل توجهی ایجاد کنند.

در این مقاله، با یک رویکرد علمی و عملی به نام مهندسی کانتکست (Context Engineering) و فریم‌ورک RPI آشنا می‌شوید که به شما کمک می‌کند مسائل پیچیده را در کدهای قدیمی حل کنید، بدون اینکه کد کثیف تولید شود.

مهندسی کانتکست چیست؟

برای درک مهندسی کانتکست، ابتدا باید بفهمیم مدل‌های زبانی بزرگ (LLMs) چگونه کار می‌کنند.

ماهیت بدون حالت مدل‌های زبانی

مدل‌های زبانی بدون حالت (Stateless) هستند. این یعنی آن‌ها هیچ حافظه‌ای از گفتگوهای قبلی ندارند و تنها چیزی که خروجی را تعیین می‌کند، توکن‌های ورودی است. هر چیزی که در پنجره کانتکست (Context Window) قرار می‌دهید، مستقیما روی کیفیت پاسخ تاثیر می‌گذارد.

مفهوم "ناحیه کندذهنی" (Dumb Zone)

در عمل، وقتی بیش از حدود ۴۰ درصد از پنجره کانتکست پر شود، بازدهی مدل به شکل محسوسی کاهش می‌یابد؛ راهنمای مهندسی کانتکست HumanLayer توصیه می‌کند میزان استفاده در بازه ۴۰ تا ۶۰ درصد نگه داشته شود. دکس هورتی (Dex Horthy) از شرکت HumanLayer این پدیده را "ناحیه کندذهنی" نامیده است.

تشبیه میز کار شلوغ: ناحیه کندذهنی را مثل یک میز کار شلوغ تصور کنید. وقتی میز کار شما پر از کاغذهای باطله، یادداشت‌های قدیمی و ابزارهای غیرضروری است، پیدا کردن آنچه واقعا نیاز دارید سخت می‌شود و کیفیت کارتان پایین می‌آید. پنجره کانتکست هوش مصنوعی هم دقیقا همین‌طور است.

راه‌حل: فشرده‌سازی هوشمند

راه‌حل این مشکل، فشرده‌سازی هوشمند (Smart Compaction) است. به جای انباشت بی‌رویه اطلاعات در کانتکست، باید:

• تاریخچه گفتگو را به صورت هوشمند خلاصه کنید
• فقط فایل‌های مرتبط را در کانتکست قرار دهید
• خروجی‌های طولانی JSON، لاگ‌ها و نتایج تست را حذف کنید
• از زیر-ایجنت‌ها (Sub-agents) برای خلاصه‌سازی اطلاعات استفاده کنید

فریم‌ورک RPI: راهکار عملی برای کدنویسی بدون Slop

برای حل مشکلات پیچیده در پایگاه‌های کد قدیمی، نباید فورا دست به کدنویسی بزنید. فریم‌ورک RPI یک جریان کاری سه‌مرحله‌ای است که از تولید کد کثیف جلوگیری می‌کند:

۱. تحقیق (Research) - فشرده‌سازی حقیقت

در این مرحله، هدف درک کامل سیستم و یافتن فایل‌های صحیح است. شما هنوز کدی نمی‌نویسید، بلکه در حال "فشرده‌سازی حقیقت" (Compressing Truth) هستید.

تکنیک‌های کلیدی:

• از زیر-ایجنت‌ها استفاده کنید تا بخش‌های بزرگ کد را بخوانند و فقط خلاصه مفید را برگردانند
• ساختار پروژه، الگوهای معماری و وابستگی‌ها را شناسایی کنید
• نقاط ورود (Entry Points) و جریان داده را درک کنید

۲. برنامه‌ریزی (Plan) - فشرده‌سازی نیت

پس از درک سیستم، یک برنامه دقیق اجرایی بنویسید. این برنامه باید شامل موارد زیر باشد:

• نام فایل‌های دقیق که باید تغییر کنند
• تکه کدهای واقعی (Code Snippets) که باید اضافه یا تغییر یابند
• ترتیب انجام تغییرات
• تست‌هایی که باید نوشته شوند

این مرحله "فشرده‌سازی نیت" (Compression of Intent) نامیده می‌شود. یک برنامه خوب و دقیق باعث می‌شود حتی مدل‌های ضعیف‌تر هم کمتر اشتباه کنند، زیرا ابهام به حداقل رسیده است.

۳. اجرا (Implement) - تولید کد نهایی

تنها پس از تکمیل دو مرحله قبل، وارد مرحله اجرا شوید. در این مرحله:

• برنامه را گام به گام اجرا کنید
• هر تغییر را با تست‌های مربوطه تایید کنید
• کانتکست را تمیز نگه دارید و اطلاعات غیرضروری را حذف کنید

RPI در برابر QRSPI: تغییرات ۲۰۲۶

دکس هورتی در سال ۲۰۲۶ در سخنرانی «همهٔ چیزهایی که دربارهٔ Research-Plan-Implement اشتباه کردیم» دوباره سراغ RPI رفت. متخصص‌ها با نسخهٔ سه‌مرحله‌ای نتیجه می‌گرفتند ولی تیم‌هایشان نه. به گفتهٔ او دو دلیل داشت: تحقیق پر از نظر شخصی برمی‌گشت چون عامل می‌دانست چه قابلیتی قرار است ساخته شود، و پرامپت برنامه‌ریزی بیش از ۸۵ دستور داشت، در حالی که مدل‌های پیشرو با احتساب پرامپت سیستم، ابزارها و MCP حدود ۱۵۰ تا ۲۰۰ دستور را با ثبات اجرا می‌کنند. نتیجه این بود که مرحله‌هایی مثل بحث طراحی اغلب جا می‌افتاد.

روند جدید که به آن «کریسپی» (QRSPI) می‌گویند، کار را به مرحله‌های کوچک‌تر با کمتر از ۴۰ دستور در هر پرامپت تقسیم می‌کند:

• پرسش‌ها: تیکت در یک پنجرهٔ کانتکست به پرسش‌های تحقیق تبدیل می‌شود.
• تحقیق: پاسخ‌ها در پنجره‌ای تازه پیدا می‌شوند که تیکت را نمی‌بیند تا خروجی فقط واقعیت باشد.
• بحث طراحی: سندی حدود ۲۰۰ خطی با وضعیت فعلی، وضعیت مطلوب، الگوهای مورد استفاده و پرسش‌های باز که مهندس بازبینی می‌کند.
• طرح کلی ساختار: فازها، امضای توابع و نقاط تست، «مثل فایل هدر C»، به‌صورت برش‌های عمودی نه اول همهٔ کار پایگاه داده.
• برنامه، work tree، اجرا و pull request: برنامه فقط سرسری بررسی می‌شود و خود کد خوانده و بازبینی می‌شود.

نکتهٔ آخر یک تغییر موضع است: هورتی حالا به تیم‌هایی که مسئول سامانه‌های عملیاتی‌اند می‌گوید کد را بخوانند و به‌جای حجم بیشتر کد بررسی‌نشده، دو تا سه برابر سرعت با کیفیتی نزدیک به کار انسانی را هدف بگیرند.

نقش انسان: تفکر را برون‌سپاری نکنید

یکی از بزرگترین اشتباهات توسعه‌دهندگان این است که فکر می‌کنند هوش مصنوعی می‌تواند جایگزین تفکر شود. این تصور خطرناک است.

هوش مصنوعی تقویت‌کننده است، نه جایگزین

AI یک تقویت‌کننده توانایی‌های شما است، نه جایگزین آن‌ها. خطرناک‌ترین کار این است که بدون بررسی برنامه (Plan)، اجازه دهید AI کد تولید کند. این کار معادل است با:

• اجازه دادن به یک جونیور بدون تجربه برای تصمیم‌گیری‌های معماری
• پذیرش کورکورانه هر پیشنهادی بدون درک پیامدها

همسویی ذهنی (Mental Alignment)

بازبینی برنامه توسط انسان باعث "همسویی ذهنی" در تیم می‌شود. وقتی یک نفر برنامه AI را بررسی می‌کند:

• اشتباهات منطقی قبل از کدنویسی شناسایی می‌شوند
• دانش تیمی افزایش می‌یابد
• تصمیمات معماری مستند می‌شوند

روی چه چیزی تمرکز کنید

به جای خواندن خط به خط کدهای تولید شده، روی بررسی "تحقیق" و "برنامه" تمرکز کنید. اگر این دو مرحله درست باشند، کد نهایی هم با احتمال بسیار بالایی درست خواهد بود.

مدیریت Context Window: در ناحیه هوشمند بمانید

برای استفاده موثر از AI در کدنویسی، باید یاد بگیرید در "ناحیه هوشمند" (Smart Zone) باقی بمانید. این یعنی:

قوانین طلایی مدیریت کانتکست

1. کمتر از ۴۰٪: همیشه کمتر از ۴۰٪ پنجره کانتکست را پر کنید
2. فشرده‌سازی مداوم: بعد از هر مرحله، اطلاعات غیرضروری را حذف کنید
3. زیر-ایجنت‌ها: برای خواندن فایل‌های بزرگ از زیر-ایجنت‌ها استفاده کنید
4. خلاصه‌سازی: تاریخچه گفتگو را به صورت دوره‌ای خلاصه کنید

بزرگ‌تر کردن مدل اهرم دیگری است که معمولاً سراغش می‌روند، ولی همیشه جواب نمی‌دهد: یک مدل ۲۷ میلیون پارامتری در ARC-AGI از مدل‌های خیلی بزرگ‌تر جلو زد، چون به‌جای بزرگ شدن، در چند دور استدلال می‌کند.

نتیجه‌گیری: آینده متعلق به تیم‌های سازگار است

استفاده از هوش مصنوعی در کدنویسی دیگر یک انتخاب نیست، بلکه یک ضرورت رقابتی است. اما تفاوت بین تیم‌هایی که موفق می‌شوند و تیم‌هایی که در بدهی فنی غرق می‌شوند، در نحوه استفاده آن‌هاست.

آینده متعلق به تیم‌هایی است که:

• یاد می‌گیرند کانتکست را مدیریت کنند و در ناحیه هوشمند باقی بمانند
• از فریم‌ورک RPI (تحقیق، برنامه‌ریزی، اجرا) استفاده می‌کنند
• تفکر را برون‌سپاری نمی‌کنند و برنامه‌ها را بازبینی می‌کنند
• فرآیندهای خود را با ابزارهایی که حالا بیشتر کد را می‌نویسند، تطبیق می‌دهند

با پیاده‌سازی اصول مهندسی کانتکست و فریم‌ورک RPI، می‌توانید از مزایای شگفت‌انگیز هوش مصنوعی بهره‌مند شوید، بدون اینکه در دام تولید کدهای بی‌کیفیت بیفتید.

این مقاله بر اساس تجربیات عملی و تحقیقات دکس هورتی (Dex Horthy) از شرکت HumanLayer در زمینه بهینه‌سازی استفاده از AI در توسعه نرم‌افزار نوشته شده است.

همین انضباط بیرون از کدنویسی هم صادق است: هوش مصنوعی عامل‌محور در پشتیبانی مشتری هم به همان نرده‌های محافظ نیاز دارد که RPI در یک کدبیس اعمال می‌کند — یک فرآیند مشخص که مدل مجبور است دنبالش کند، نه اختیار کامل.

بخش دوم: RPI در عمل با ساب‌ایجنت‌های Claude Code؛ روش کار روزانه، قانون مالکیت برای ایجنت‌های موازی و اینکه نتیجه‌ها را چطور راستی‌آزمایی می‌کنیم.

پرسش‌های متداول