اگر از ابزارهایی مثل Cursor یا Claude CLI برای کدنویسی استفاده میکنید، احتمالاً با این تجربه تلخ روبرو شدهاید: یک کد که امروز عالی کار میکند، فردا با همان پرامپت، پاسخی متناقض میدهد. این مشکل که «پرتوپراکندگی دستورات» (Instruction Drift) نامیده میشود، سناریویی است که در آن یک پایگاه کد واحد، صرفاً به دلیل تغییر جزئی در پرامپتها، خروجیهای نوسانی تولید میکند. این وضعیت باعث میشود توسعهدهندگان زمان زیادی را صرف تکرار قوانین پایه در هر گفتگو کنند.
طبق گزارش منتشرشده در ۴ جولای ۲۰۲۶ در وبسایت dev.to، یک توسعهدهنده FastAPI راهکاری عملی برای پایدارسازی خروجی عاملها ارائه داده و نشان داده است که چگونه فایلهای قوانین استاتیک میتوانند این ناسازگاریها را حذف کنند. مشکل اصلی این است که عاملهای هوش مصنوعی (AI Agents) — ابزارهایی که میتوانند بهطور مستقل وظایف پیچیده را پیش ببرند — بیش از حد به تاریخچهٔ اخیر پنجرهٔ زمینه (Context Window) وابستهاند. مدلهای زبانی (LLMs) متونی را که نزدیک به ابتدای پنجرهٔ زمینه قرار دارند، قویتر به خاطر میسپارند و به آنها ارجاع میدهند. پنجرهٔ زمینه شبیه میز کاری است که فقط جای چند ورق کاغذ دارد، نه کل کتابخانه؛ بنابراین مدلها متونی را که در ابتدای این پنجره قرار دارند، قویتر به خاطر میسپارند.
همانطور که در تحلیلهای پیشین ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، مدیریت دقیق بستر متن کلید دستیابی به نتایج پیشبینیپذیر است. برای حل این گلوگاه، توسعهدهندگان اکنون از فایلهای مشخصات در ریشهٔ پروژه (Root-level specification files) استفاده میکنند. فایلهایی مثل CLAUDE.md، .cursorrules و AGENTS.md بهطور خودکار در ابتدای پنجرهٔ زمینه تزریق میشوند تا هدف طراحی همیشه در دسترس باشد و بدون نیاز به پرامپتهای دستی، تداوم یابد.
جزئیات فنی و مشخصات پروژه
به نقل از راهنمای مذکور، یک فایل CLAUDE.md استاندارد برای پروژههای پایتون ۳.۱۲ باید شامل محدودیتهای مشخص و اندازهپذیر باشد. برای یک سرور REST API که با FastAPI 0.111 و PostgresSQL 16 ساخته شده، پیشنهاد میشود استک فنی بهطور کامل بر پایه I/O غیرهمگام (Asynchronous) و کتابخانه asyncpg تعریف شود.
برای حفظ نظم کد و جلوگیری از آشفتگی، قراردادهای کدنویسی زیر توصیه شده است:
- استفاده اجباری از Type Annotations که با استاندارد
py.typedسازگار باشد. - تعریف تمام ورودیها و خروجیها با استفاده از مدلهای Pydantic v2.
- تقسیمبندی Routerها بر اساس واحدهای کاربردی (Functional Unit) در دایرکتوری
src/routers/. - نوشتن تستها با استفاده از
pytest-asyncioوhttpx.AsyncClient.
سازوکارهای پیادهسازی
بر اساس مستندات این روش، هر ابزار فایل مخصوص به خود را برای مدیریت رفتار مدل دارد:
- CLAUDE.md: مورد استفاده در Claude CLI و Claude Code برای تعریف فلسفه طراحی کلی و لیست ممنوعیتها.
- .cursorrules: اختصاصی برای Cursor IDE جهت مدیریت قوانین تکمیل کد در سطح ویرایشگر.
- AGENTS.md: طراحیشده برای OpenAI Agents SDK به منظور تعریف پروتکلهای ارتباطی و توزیع نقشها بین چندین عامل مختلف.
ممنوعیتهای سختگیرانه (Strict Prohibitions) در این فایلها نقش حیاتی دارند. برای مثال، استفاده از time.sleep() بهطور مطلق ممنوع شده و الزاماً باید از asyncio.sleep() استفاده شود. همچنین توابعی که روی متغیرهای سراسری اثر جانبی (Side Effect) میگذارند یا Hardcoding مقادیر فایل .env بهطور مستقیم در کد، بهشدت منع شدهاند.
دستورات خاص برای عاملها نیز تعریف میشوند تا از تصادفی بودن تغییرات جلوگیری شود؛ مثلاً مدل باید پیش از بازنویسی هر تابع موجود، یک خط کامنت برای توضیح «دلیل تغییر» (Reason for change) بنویسد یا برای هرگونه تغییر در Schema دیتابیس، الزاماً فایل Migration مربوط به Alembic را ایجاد کند. در این ساختار برای استانداردسازی زبان، توصیفهای Pull Request (PR) باید به انگلیسی باشند، در حالی که کامنتهای داخل کد به زبان ژاپنی باقی میمانند.
علاوه بر قوانین، ارجاعات خارجی برای هدایت دقیق مدل تعریف میشوند. این شامل لینک دادن به docs/openapi.yaml برای مشخصات API، ارجاع به docs/erd.png برای نمودار رابطه موجودیتها (ERD) و اشاره به .env.example برای لیست متغیرهای محیطی است.
برای معماریهای پیچیده FastAPI، نویسنده ساختاری سلسلهمراتبی را پیشنهاد میکند: یک فایل CLAUDE.md کلی در ریشه پروژه و مکملهای محلی در دایرکتوریهایی مثل src/routers/. چون Claude CLI فایلها را از بالا به پایین جمعآوری و ترکیب میکند، قوانین سطح پایینتر در زیرشاخهها میتوانند بهطور موثر سیاستهای کلی پروژه را بازنویسی (Override) کنند.
قوانین باید اندازهپذیر باشند تا قابل اجرا و نظارت باشند. راهنما اشاره میکند که مدلهای زبانی با «ممنوعیتها» (Prohibitions) بهتر از «اجازهها» (Permissions) کنار میآیند. بهجای درخواست مبهم مثل «کد خوب بنویس»، باید دستورات مشخصی داد (مثلاً «همیشه Type Annotation اضافه کن») تا عامل بتواند خروجی خود را بهطور خودکار بازبینی و تأیید کند. قوانین مبهم معمولاً توسط مدل نادیده گرفته میشوند.
اتصال این قوانین به خط لوله CI با استفاده از ابزارهایی مثل ruff یا mypy یک حلقه خود-اصلاحگر (Self-correcting loop) میسازد. وقتی عامل قانونی را نقض میکند، شکست در مرحله CI بازخورد فوری ایجاد میکند و عامل از این خطا برای اصلاح تلاش بعدی خود استفاده میکند. این روند، فرآیند توسعه را به یک چرخه بازخورد خودکار تبدیل میکند.
این تغییر پارادایم، نقش توسعهدهنده را از «مهندسی پرامپت» مداوم به «نگهدارنده یک سند زنده» (Living Specification) تغییر میدهد. با قرار دادن این قوانین تحت کنترل نسخه در Git و مستندسازی دلیل تغییرات در Commit Messageها، تیمها میتوانند ردیابی کنند که چرا محدودیتهای خاصی اضافه شدهاند و از «پوسیدگی قوانین» (Rule Decay) که معمولاً پس از چند ماه توسعه رخ میدهد، جلوگیری کنند.
در نهایت، این فایلهای قوانین مکانیزمی ارزانقیمت هستند تا عاملهای هوش مصنوعی بهجای شروع از صفر در هر گفتگو، بر اساس یک حقیقت مشترک، پایدار و همگانی عمل کنند. پایدارترین مسیر برای رسیدن به خودمختاری AI در سطح تولید (Production-grade)، شروع با یک فایل ساده ۱۰ خطی و گسترش تدریجی آن همزمان با شناسایی نقاط شکست عامل است.
گام بعدی شما
- یک فایل
CLAUDE.mdساده با ۱۰ خط قانون (ترجیحاً ممنوعیتها) در ریشه پروژه خود بسازید و تغییر رفتار عامل را مشاهده کنید. - قوانین مربوط به استایل کدنویسی (مثل Pydantic یا Type Hinting) را از پرامپتهای تکراری به این فایل منتقل کنید.
- ابزارهایی مثل ruff را به چرخه بازخورد عامل متصل کنید تا اشتباهات ساختاری بهطور خودکار اصلاح شوند.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو