How do I adapt these Claude 4.5 prompts to my tech stack?

Add your language, framework, code style, and CI rules to each prompt. Claude 4.5 performs best when you include example files, paths, and test frameworks from your stack.

Can Claude 4.5 write safe large-scale refactors?

Yes, if you provide before/after patterns, a codemod plan, and a staged rollout. Use prompts that include dry runs, sampling validation, and canary PRs to reduce risk.

What’s the best way to get high-quality PRs with Claude 4.5?

Feed the diff and context into a PR description prompt that demands problem, solution, risks, tests, and rollout steps. Follow with a self-review prompt to catch gaps before requesting review.

How do I keep Claude 4.5 from over-engineering?

State non-goals and constraints up front: smallest viable change, no new deps, preserve public APIs. Ask for alternatives first and choose the simplest approach.

Can I integrate these prompts into my editor or CI?

Yes. Wrap the prompts into editor snippets or CI jobs. Tools like [Sider.AI](https://sider.ai) can automate context collection, apply prompts to selected code, and assemble diffs and PRs consistently.

30 فرمان برتر Claude 4.5 برای کدنویسی خودکار، بازسازی کد، و درخواست‌های Pull Request

چرا این دستورات Claude 4.5 اکنون اهمیت دارند

اگر سرعت اسپرینت شما به دلیل انباشتگی بررسی‌ها و تعویق بازسازی‌ها کاهش می‌یابد، تنها نیستید. تیم‌های برتر بی‌سروصدا از Claude 4.5 برای پیش‌نویس ویژگی‌ها، دسته‌ای کردن بازسازی‌ها و نوشتن PRهای تمیز و آماده بررسی—اغلب در عرض چند دقیقه—استفاده می‌کنند. این فهرست 30 دستورالعمل آزمایش‌شده Claude 4.5 را برای کدنویسی مستقل، بازسازی‌های در مقیاس بزرگ و درخواست‌های pull (PR) ارائه می‌دهد که سریع‌تر تأییدیه می‌گیرند.

ما از یک رویکرد عملی و راه‌حل‌محور استفاده خواهیم کرد: شما دستورات قابل کپی و پیست، یادداشت‌هایی در مورد زمینه و محدودیت‌ها و نکات حرفه‌ای برای هدایت Claude 4.5 به سمت خروجی‌های قابل اعتماد دریافت خواهید کرد.

نحوه استفاده مؤثر از این دستورات Claude 4.5

مشخصات، محدودیت‌ها و تست‌های پذیرش را به Claude 4.5 بدهید. با نتایج قابل آزمایش، بهتر کد می‌زند.

همیشه زمینه مخزن (repository): زبان، چارچوب، سبک کدنویسی، قوانین CI، نامگذاری شاخه‌ها را لحاظ کنید.

برای بازسازی‌ها، فایل‌های نماینده را به همراه نقشه سطح کد (به عنوان مثال، مالکیت ماژول، مرزها) ارائه دهید.

برای PRها، تفاوت‌ها (diffs) را وارد کنید. Claude 4.5 وقتی بداند چه چیزی تغییر کرده است، توضیحات بهتری می‌نویسد.

از کنترل دما از طریق دستورالعمل‌هایی مانند «تغییرات محافظه‌کارانه را ترجیح دهید» یا «جایگزین‌ها را پیشنهاد دهید؛ سپس ساده‌ترین را پیاده‌سازی کنید» استفاده کنید.

یک دستور نهایی «تأیید» اضافه کنید تا خود-انتقادی کند، تست‌ها را ایجاد کند و رگرسیون‌ها را شناسایی کند.

30 دستور برتر Claude 4.5 برای کدنویسی مستقل، بازسازی‌ها و PRها

در زیر، هر دستور شامل یک بلوک کپی-پیست، مواردی که باید ارائه شود و یک نکته حرفه‌ای برای تنظیم پاسخ‌های Claude 4.5 است.

1) پیاده‌سازی یک ویژگی از یک مشخصات واضح

دستور: «به عنوان یک مهندس ارشد عمل کن. ویژگی زیر را به صورت end-to-end با حداقل تغییرات در سطح پیاده‌سازی کن. به معماری و استانداردهای کدنویسی ما احترام بگذار. فقط بلوک‌های کد را ارائه کن؛ تصمیمات را در نظرات توضیح بده. تست‌های واحد و یک تست یکپارچه‌سازی حداقلی را لحاظ کن. مشخصات:

[مشخصات ویژگی را پیست کنید] معماری:

[ماژول‌های مربوطه را پیست کنید] محدودیت‌ها:

[عملکرد، امنیت، سازگاری با نسخه‌های قبلی] سبک کد:

[قوانین lint، نامگذاری] تست:

[چارچوب، اهداف پوشش] تحویل:

فایل‌های به‌روز شده، فایل‌های جدید و تست‌ها.» چه چیزی ارائه شود: مشخصات ویژگی، نقشه فایل، قوانین سبک، چارچوب تست. نکته حرفه‌ای: اضافه کنید «توابع خالص و DI را در صورت امکان ترجیح دهید.»

2) داربست ماژول Greenfield

دستور: «یک داربست آماده تولید برای یک ماژول جدید به نام [module] ایجاد کن. باید یک رابط پایدار ارائه دهد و جزئیات پیاده‌سازی را پنهان کند. موارد زیر را ایجاد کن:

رابط عمومی

پیاده‌سازی داخلی

اتصال وابستگی

مثال استفاده

تست‌های واحد از قراردادهای مخزن ما پیروی کن:

زبان: [X]

چارچوب: [Y]

مسیرها/فضاهای نام: [قوانین]

Lint/format: [قوانین]» چه چیزی ارائه شود: هدف ماژول، رابط‌های مصرف‌کننده. نکته حرفه‌ای: درخواست بخش ‘بودجه پایداری’ در نظرات برای علامت‌گذاری خطرات آینده کنید.

3) TDD: ابتدا تست‌ها را بنویسید، سپس کد را

دستور: «شما در حال هدایت TDD هستید. ابتدا، تست‌های واحد ناموفق بنویسید که مشخصات را رمزگذاری می‌کنند. پس از تأیید من، حداقل کد را برای گذراندن آنها پیاده‌سازی کنید. موارد حاشیه‌ای و تست‌های مبتنی بر ویژگی را در صورت مفید بودن لحاظ کنید. مشخصات: [پیست] محیط: [زمان اجرا + چارچوب تست] محدودیت‌ها: [عملکرد/امنیت/سازگاری]» چه چیزی ارائه شود: مشخصات و چارچوب تست. نکته حرفه‌ای: درخواست یک «لیست بررسی تست جهش» برای تقویت ادعاها کنید.

4) پوشش API تدافعی

دستور: «یک کلاینت تدافعی برای API خارجی [name] طراحی و پیاده‌سازی کن. الزامات:

تلاش‌های مجدد با jitter

قطع‌کننده مدار

Timeout + مهلت‌ها

ثبت ساختاریافته

معیارها (تأخیر، نرخ خطا)

دسته‌بندی خطا کد + تست‌ها + یک قطعه README برای استفاده ارائه دهید.» چه چیزی ارائه شود: مستندات API، محدودیت نرخ. نکته حرفه‌ای: اضافه کنید «تست‌های هرج و مرج برای timeoutها و 5xx ایجاد کنید.»

5) لایه اعتبارسنجی ورودی ایمن

دستور: «یک لایه اعتبارسنجی ورودی متمرکز برای [domain] با اعتبارسنجی طرح‌واره (schema) دقیق، canonicalization و پیام‌های خطای ایمن برای گزارش‌ها پیاده‌سازی کنید. JSON، داده‌های فرم و آرگومان‌های CLI را پوشش دهید. تست‌ها را با محموله‌های مخرب لحاظ کنید.» چه چیزی ارائه شود: طرح‌واره‌های مورد انتظار، قراردادهای مدیریت خطا. نکته حرفه‌ای: مراجع OWASP را برای افزایش پوشش بهتر اضافه کنید.

6) گذر بهینه‌سازی خرد عملکرد

دستور: «توابع زیر را پروفایل کنید و 3 بهینه‌سازی برتر را با مصالحه‌ها پیشنهاد دهید. سپس کوچکترین و ایمن‌ترین تغییرات را پیاده‌سازی کنید که ≥20% سرعت را افزایش می‌دهد. کد: [پیست] حجم کار: [توضیح دهید] محدودیت‌ها: رفتار عمومی را حفظ کنید.» چه چیزی ارائه شود: حجم‌های کاری نماینده. نکته حرفه‌ای: درخواست کد مهار بنچمارک برای تکرار اندازه‌گیری‌ها کنید.

7) راه‌اندازی flag ویژگی با kill-switch

دستور: «یک flag ویژگی در اطراف [feature] اضافه کنید. الزامات: flag سمت سرور، راه‌اندازی تدریجی %، bucketing چسبنده، kill-switch فوری و تله‌متری در مورد پذیرش. مهاجرت، مستندات و تست‌ها را ارائه دهید.» چه چیزی ارائه شود: پلتفرم flag، sink تله‌متری. نکته حرفه‌ای: درخواست یک طرح مهاجرت برای پیکربندی در prod کنید.

8) کار ناهمزمان + idempotency

دستور: «[Operation] را به یک کار ناهمزمان بازسازی کنید. از طریق کلیدهای dedupe و تلاش‌های مجدد ایمن، idempotency را تضمین کنید. مدیریت DLQ و قابلیت مشاهده را اضافه کنید. شامل: پیکربندی صف، worker، سیاست تلاش مجدد، معیارها و تست‌ها با رویدادهای تکراری.» چه چیزی ارائه شود: جزئیات صف/زمان اجرا. نکته حرفه‌ای: درخواست یک اسکریپت replay برای پیام‌های dead-letter کنید.

9) انتقال I/O همزمان به غیر مسدودکننده

دستور: «تبدیل I/O مسدودکننده در [files] به APIهای غیر مسدودکننده. رابط‌ها را بدون تغییر نگه دارید. مدیریت فشار برگشتی، timeoutها و پاکسازی منابع را اضافه کنید. بنچمارک‌ها و تست‌ها را ارائه دهید.» چه چیزی ارائه شود: کد و APIهای زمان اجرای هدف. نکته حرفه‌ای: ‘نوع‌های عمومی را تغییر ندهید’ را اضافه کنید تا از تلاطم جلوگیری شود.

10) مرزهای تراکنش پایگاه داده

دستور: «مرزهای تراکنش را برای [module] بررسی و اصلاح کنید. اهداف: عملیات اتمی، سطح انزوای سازگار، تلاش‌های مجدد ایمن در صورت خطاهای گذرا و حداقل اختلاف قفل. تفاوت‌های کد + استدلال در نظرات را ارائه دهید.» چه چیزی ارائه شود: الگوهای ORM/SQL خام، طعم DB. نکته حرفه‌ای: درخواست یک مجموعه تست deadlock کنید.

11) استراتژی caching با محافظ‌های صحت

دستور: «یک لایه caching برای [hot path] با موارد زیر پیاده‌سازی کنید:

Cache aside

TTL + jitter

محافظت از stampede

قابلیت مشاهده (hit/miss)

هوک‌های ابطال صحت را در شروع سرد تضمین کنید. تست‌ها را لحاظ کنید.» چه چیزی ارائه شود: اشکال داده، الزامات سازگاری. نکته حرفه‌ای: درخواست یک ‘مجله سازگاری’ که موارد حاشیه‌ای را توضیح می‌دهد کنید.

12) انتقال schema با زمان خرابی صفر

دستور: «یک انتقال بدون زمان خرابی از schema A به B با استفاده از expand/contract برنامه‌ریزی و پیاده‌سازی کنید. مهاجرت‌ها، کار backfill، پنجره خواندن/نوشتن دوگانه و طرح rollback را لحاظ کنید. PRها را با توجه به نسخه منتشر شده آماده کنید.» چه چیزی ارائه شود: schemaهای فعلی/هدف. نکته حرفه‌ای: درخواست یک لیست بررسی cutover کنید.

13) لیست بررسی سخت‌افزاری امنیتی + پچ‌ها

دستور: «[Service] را در برابر این لیست بررسی ممیزی کنید: authN، authZ، مدیریت مخفی، TLS، اعتبارسنجی ورودی، ثبت، حداقل امتیاز، خطرات وابستگی. یافته‌های اولویت‌بندی شده و پچ‌های کد حداقلی را تولید کنید. تست‌ها را لحاظ کنید.» چه چیزی ارائه شود: کد سرویس، نمای کلی زیرساخت. نکته حرفه‌ای: درخواست بررسی‌های CVE برای وابستگی‌های برتر کنید.

14) تولیدکننده طرح بازسازی Monorepo

دستور: «با توجه به این نقشه monorepo، یک طرح بازسازی مرحله‌ای برای [goal]، با شکست‌های وابستگی، مالکیت بسته و استراتژی CI پیشنهاد دهید. سپس فقط تغییرات برای فاز 1 را با تست‌ها ایجاد کنید.» چه چیزی ارائه شود: نمودار repo، وضعیت نهایی مورد نظر. نکته حرفه‌ای: ‘تلاطم را به X فایل محدود کنید’ را برای کنترل دامنه اضافه کنید.

15) بازنگری ثبت برای سیگنال بیش از نویز

دستور: «ثبت را در [module] به گزارش‌های ساختاریافته با سطوح، فیلدهای پایدار و redaction بازنویسی کنید. گزارش‌های پر سر و صدا را حذف کنید، شناسه‌های همبستگی را اضافه کنید و ناورداهای گزارش را مستند کنید. نمونه‌های قبل/بعد و تست‌ها را ارائه دهید.» چه چیزی ارائه شود: گزارش‌های فعلی، قوانین حریم خصوصی. نکته حرفه‌ای: درخواست قوانین نمونه‌برداری برای مسیرهای داغ کنید.

16) بسته شروع قابلیت مشاهده

دستور: «ردیابی، معیارها و بررسی‌های سلامت را به [service] اضافه کنید. از قراردادهای [OpenTelemetry] استفاده کنید. داشبوردها (JSON)، SLOها و هشدارها را ارائه دهید. مستندات تنظیمات توسعه محلی را لحاظ کنید.» چه چیزی ارائه شود: زمان اجرا، صادرکننده، اهداف SLI/SLO. نکته حرفه‌ای: درخواست معیارهای RED/USE به طور پیش‌فرض کنید.

17) گذر دسترسی (a11y)

دستور: «اجزای UI را برای دسترسی (WCAG 2.2 AA) ممیزی کنید. پیمایش صفحه کلید، ترتیب تمرکز، کنتراست رنگ و نقش‌های ARIA را رفع کنید. اسکرین‌شات‌های قبل/بعد و یک لیست بررسی از تخلفات رفع شده را ارائه دهید.» چه چیزی ارائه شود: کد کامپوننت، توکن‌های طراحی. نکته حرفه‌ای: درخواست تست‌های storybook a11y کنید.

18) داربست بین‌المللی‌سازی (i18n)

دستور: «i18n را به [front-end] معرفی کنید. کاتالوگ‌های پیام، تغییر زبان محلی، قالب‌بندی پیام ICU، پشتیبانی RTL و شبه‌محلی‌سازی را اضافه کنید. دستورالعمل‌های مهاجرت و تست‌ها را ارائه دهید.» چه چیزی ارائه شود: چارچوب، استفاده از متن فعلی. نکته حرفه‌ای: درخواست یک قانون lint کنید که از رشته‌های کد شده سخت جلوگیری می‌کند.

19) بازسازی مدیریت وضعیت

دستور: «[UI state] را به یک مدل قابل پیش‌بینی (به عنوان مثال، Redux/Zustand/MobX/XState) بازسازی کنید. اهداف: حذف وضعیت ضمنی، memoize کردن انتخابگرها و جدا کردن اثرات جانبی. تست‌ها و یک راهنمای مهاجرت ارائه دهید.» چه چیزی ارائه شود: جریان‌های وضعیت فعلی. نکته حرفه‌ای: درخواست یک نمودار وضعیت و جدول رویداد کنید.

20) ارتقاء ایمنی نوع

دستور: «به تدریج [codebase] را به تایپ قوی‌تر (به عنوان مثال، حالت سخت‌گیرانه TS) منتقل کنید. نقاط داغ را شناسایی کنید، نوع‌ها را اضافه کنید و از any ضمنی جلوگیری کنید. یک طرح مرحله‌ای + PRها در هر ماژول ارائه دهید.» چه چیزی ارائه شود: اهداف تایپ، محدودیت‌های ساخت. نکته حرفه‌ای: درخواست تست‌های مبتنی بر نوع برای genericsهای دشوار کنید.

21) تشخیص و رفع نشت حافظه

دستور: «رشد حافظه را در [service] تحت [workload] تجزیه و تحلیل کنید. نشت‌ها را از طریق پروفایل شناسایی کنید، اصلاحات پیشنهادی را بر اساس تأثیر/خطر رتبه‌بندی کنید، حداقل تغییرات را پیاده‌سازی کنید و تست‌های رگرسیون را اضافه کنید.» چه چیزی ارائه شود: پروفایل‌های heap، بازتولیدکننده. نکته حرفه‌ای: درخواست یک خلاصه به سبک پس از مرگ در PR کنید.

22) شکار شرایط مسابقه

دستور: «شرایط مسابقه را در [concurrency area] پیدا و رفع کنید. تست‌های قطعی، قوانین ترتیب قفل و نظرات مستندسازی ناورداها را ارائه دهید.» چه چیزی ارائه شود: نواحی کد همزمان، علائم شکست. نکته حرفه‌ای: درخواست یک مهار تست استرس کنید.

23) سرعت بخشیدن به CI بدون از دست دادن پوشش

دستور: «CI را بهینه کنید تا زمان اجرا را ≥30% بدون کاهش پوشش کاهش دهید. از caching، sharding تست و ساخت‌های افزایشی استفاده کنید. یک جدول معیارها و یک طرح rollback ارائه دهید.» چه چیزی ارائه شود: yaml CI فعلی، گلوگاه‌ها. نکته حرفه‌ای: درخواست اتوماسیون قرنطینه تست‌های پوسته پوسته کنید.

24) سخت‌افزاری کانتینر + SBOM

دستور: «Dockerfileها را به تصاویر حداقلی چند مرحله‌ای، کاربران غیر ریشه و پایه‌های تأیید شده بازسازی کنید. تولید SBOM و اسکن آسیب‌پذیری را در CI اضافه کنید. مثال‌ها و تست‌ها را ارائه دهید.» چه چیزی ارائه شود: Dockerfileهای فعلی، رجیستری. نکته حرفه‌ای: درخواست ساخت‌های قابل بازتولید و منشأ (به سبک SLSA) کنید.

25) مدیریت secrets دوباره انجام دهید

دستور: «secretsهای درون خطی را با [vault/KMS] جایگزین کنید. کلیدها را بچرخانید، سیاست‌های حداقل امتیاز را اضافه کنید و تزریق secret را در CI/CD پیاده‌سازی کنید. runbookها و تست‌ها را ارائه دهید.» چه چیزی ارائه شود: استفاده از secret فعلی، ارائه‌دهنده. نکته حرفه‌ای: درخواست تشخیص commits تصادفی کنید.

26) نویسنده توضیحات PR (کمک‌رسانی شده توسط هوش مصنوعی)

دستور: «با توجه به این diff، یک توضیح PR با کیفیت بالا بنویسید: مسئله، راه حل، دامنه، خطرات، طرح راه‌اندازی، معیارها و لینک‌ها به مسائل مربوطه. یک لیست بررسی بازبینی‌کننده را لحاظ کنید. بین 300 تا 450 کلمه باشد. Diff: [پیست]» چه چیزی ارائه شود: diff، لینک‌های مسئله. نکته حرفه‌ای: اضافه کنید ‘یک و طرح تست را در بالا لحاظ کنید.’

27) تولیدکننده نظر PR برای بازبینی‌کنندگان

دستور: «این diff را مانند یک بازبینی‌کننده ارشد بررسی کنید. فقط در صورت لزوم نظرات مختصر و با سیگنال بالا بنویسید. بر صحت، اتصال، شکاف‌های تست، امنیت و عملکرد تمرکز کنید. با یک خلاصه تأیید یا درخواست تغییرات پایان دهید.» چه چیزی ارائه شود: diff و زمینه. نکته حرفه‌ای: درخواست ‘nits گروه‌بندی شده در انتها’ کنید.

28) نویسنده Changelog + یادداشت‌های انتشار

دستور: «یادداشت‌های انتشار قابل خواندن توسط انسان را از PRهای ادغام شده ایجاد کنید. بر اساس ویژگی‌ها، رفع‌ها، زیرساخت و مستندات گروه‌بندی کنید. یادداشت‌های ارتقاء و تغییرات شکسته‌شده را با مراحل مهاجرت اضافه کنید. آن را قابل اسکن نگه دارید.» چه چیزی ارائه شود: لیست PRها، تگ‌ها، تأثیر. نکته حرفه‌ای: درخواست دسته‌بندی‌های صحیح semver کنید.

29) بازسازی خودکار در مقیاس بزرگ (codemod)

دستور: «یک codemod ایمن برای انتقال [pattern A] به [pattern B] در سراسر repo طراحی کنید. موارد زیر را لحاظ کنید:

قوانین تحلیل استاتیک

اسکریپت تبدیل

طرح اجرای خشک

اعتبارسنجی نمونه‌برداری

راه‌اندازی در دسته‌ها با بازگشت اسکریپت + تست‌ها را تولید کنید.» چه چیزی ارائه شود: نمونه‌های قبل/بعد، دامنه هدف. نکته حرفه‌ای: ابتدا درخواست یک PR canary کنید.

30) مجموعه خود-بررسی و تأیید

دستور: «قبل از نهایی کردن، تغییرات را خود-بررسی کنید:

رگرسیون‌های احتمالی را توضیح دهید

اضافات تست را پیشنهاد دهید

یک بررسی مدل ذهنی در مورد همزمانی، حافظه و I/O اجرا کنید

انطباق با سبک و lint را تأیید کنید در صورت نیاز یک لیست بررسی و اصلاحات کد را برگردانید.» چه چیزی ارائه شود: مجموعه تغییرات و قوانین CI. نکته حرفه‌ای: با زبان ‘به عنوان یک بازبینی‌کننده پارانوید عمل کن’ ترکیب کنید.

مثال: استفاده از Claude 4.5 برای بازسازی یک گردش کار پرداخت

سناریو: یک سرویس Node.js پرداخت‌ها را به صورت همزمان پردازش می‌کند و در اوج بار timeout می‌شود.

نحوه اعمال دستورات:

با دستور 6 برای پروفایل کردن گلوگاه‌ها شروع کنید.

از دستور 8 برای انتقال مراحل سنگین (بررسی تقلب، تولید فاکتور) به کارهای ناهمزمان با idempotency استفاده کنید.

دستور 11 را برای کش کردن جستجوهای idempotent (فراداده BIN، نرخ ارز) اعمال کنید.

دستور 16 را برای ردیابی و معیارهای RED اضافه کنید.

راه‌اندازی را در دستور 7 با یک flag ویژگی بپیچید.

با دستور 30 برای خود-بررسی و افزودن تست‌ها به پایان برسانید.

نتیجه: کاهش تأخیر 45% p95، timeoutهای نزدیک به صفر، راه‌اندازی ایمن‌تر.

ساخت بلوک‌های زمینه بهتر Claude 4.5

Claude 4.5 زمانی می‌درخشد که شما:

به جای کل repoها، فایل‌های نماینده ارائه دهید.

اهداف غیر را بیان کنید: «رابط‌های عمومی را تغییر ندهید.»

با معیارهای پذیرش صریح و نام‌های تست لنگر بیندازید.

محافظ اضافه کنید: «کتابخانه استاندارد را بر وابستگی‌های جدید ترجیح دهید.»

ابتدا جایگزین‌ها را درخواست کنید، سپس پیاده‌سازی انتخاب شده را.

این meta-prompt را امتحان کنید: «قبل از کدنویسی، 2-3 رویکرد قابل اجرا با مصالحه‌ها (پیچیدگی، عملکرد، خوانایی) را ترسیم کنید. یکی را انتخاب کنید که خطر را به حداقل برساند و با محدودیت‌های ما همسو باشد. سپس پیاده‌سازی کنید.»

درخواست‌های pull که سریع‌تر ادغام می‌شوند: یک کتابچه راهنمای Claude 4.5

با یک بیانیه مسئله واضح و کوچکترین تغییر قابل اجرا شروع کنید.

گزارش‌ها، ردیابی‌ها یا بنچمارک‌هایی را ضمیمه کنید که دلتای قبل/بعد را نشان می‌دهند.

یک طرح تست، مراحل rollback و معیارهایی را برای تماشا پس از استقرار لحاظ کنید.

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

از دستور 26 برای نوشتن توضیحات PR و دستور 27 برای خود-بررسی استفاده کنید.

راستی: اگر این گردش کار را در داخل ویرایشگر یا مستندات خود می‌خواهید، ابزارهایی مانند Sider.AI می‌توانند دستورات Claude 4.5 را در برابر انتخاب‌های کد شما هماهنگ کنند، diffها را به طور خودکار پیوست کنند و یک پنجره زمینه در حال اجرا را نگه دارند تا هر مرحله بر اساس مرحله آخر ساخته شود. این به تیم‌ها کمک می‌کند تا از استفاده موردی از هوش مصنوعی به یک عادت قابل اعتماد و اولویت‌بندی شده برای بررسی تبدیل شوند.

بسته‌های شروع سریع (کپی/پیست)

بسته A: ‘ویژگی + تست‌ها + PR’

دستور 1 (ویژگی)

دستور 3 (TDD)

دستور 26 (نوشتن PR)

دستور 30 (خود-بررسی)

بسته B: ‘بازسازی در مقیاس’

دستور 14 (طرح)

دستور 29 (codemod)

دستور 23 (سرعت CI)

دستور 28 (یادداشت‌های انتشار)

بسته C: ‘اسپرینت سخت‌افزاری’

دستور 13 (ممیزی امنیتی)

دستور 24 (کانتینر)

دستور 25 (secrets)

دستور 16 (قابلیت مشاهده)

مراحل بعدی

3 دستوری را انتخاب کنید که با نقاط درد اصلی شما مطابقت دارند و آنها را روی یک ماژول کوچک و واحد اجرا کنید.

هر دستور را با محدودیت‌های مشخص و تست‌های صریح تنظیم کنید.

نتایج را اندازه‌گیری کنید (تأخیر p95، زمان هدایت PR، نرخ شکست استقرار).

فقط پس از تأیید دستاوردها در یک repo canary، مقیاس را افزایش دهید.

نکات کلیدی:

Claude 4.5 با محدودیت‌های دقیق، مثال‌ها و تست‌ها قوی‌ترین است.

کدنویسی مستقل به محافظ‌ها نیاز دارد: flagها، معیارها و rollback.

بازسازی‌ها و PRها از طرح‌های مرحله‌ای و بررسی‌های با سیگنال بالا بهره می‌برند.

کوچک شروع کنید، اندازه‌گیری کنید و تکرار کنید.

سوالات متداول

Q1:چگونه این دستورات Claude 4.5 را با پشته فناوری خود تطبیق دهم؟ زبان، چارچوب، سبک کد و قوانین CI خود را به هر دستور اضافه کنید. Claude 4.5 زمانی بهترین عملکرد را دارد که فایل‌های مثال، مسیرها و چارچوب‌های تست را از پشته خود لحاظ کنید.

Q2:آیا Claude 4.5 می‌تواند بازسازی‌های ایمن در مقیاس بزرگ بنویسد؟ بله، اگر الگوهای قبل/بعد، یک طرح codemod و یک راه‌اندازی مرحله‌ای ارائه دهید. از دستوراتی استفاده کنید که شامل اجراهای خشک، اعتبارسنجی نمونه‌برداری و PRهای canary برای کاهش خطر هستند.

پرسش 3: بهترین راه برای دریافت درخواست‌های ادغام (PR) با کیفیت بالا با Claude 4.5 چیست؟ تغییرات و زمینه (context) را در یک دستورالعمل شرح درخواست ادغام (PR description prompt) وارد کنید که نیازمند مشکل، راه‌حل، خطرات، تست‌ها و مراحل انتشار باشد. سپس با یک دستورالعمل خود-بازبینی (self-review prompt) ادامه دهید تا قبل از درخواست بررسی، شکاف‌ها را شناسایی کنید.

پرسش 4: چگونه Claude 4.5 را از مهندسی بیش از حد (over-engineering) باز دارم؟ اهداف غیرضروری (non-goals) و محدودیت‌ها (constraints) را از ابتدا بیان کنید: کوچک‌ترین تغییر ممکن (smallest viable change)، بدون وابستگی‌های (deps) جدید، حفظ APIهای عمومی (public APIs). ابتدا جایگزین‌ها را بپرسید و ساده‌ترین رویکرد را انتخاب کنید.

پرسش 5: آیا می‌توانم این دستورالعمل‌ها را در ویرایشگر (editor) یا CI خود ادغام کنم؟ بله. دستورالعمل‌ها را در قطعه‌های کد (editor snippets) یا کارهای CI بپیچید. ابزارهایی مانند Sider.AI می‌توانند جمع‌آوری زمینه (context collection) را خودکار کنند، دستورالعمل‌ها را روی کد انتخاب‌شده اعمال کنند و تفاوت‌ها (diffs) و درخواست‌های ادغام (PRs) را به طور مداوم جمع‌آوری کنند.