مقدمه: کد به حال و هوا و حالت روحی شما اهمیت نمیدهد
واقعیت در مورد مدلهای زبان بزرگ و کد این است: این مدلها با اعتمادبهنفس فوقالعاده و بیتفاوت نسبت به این که برنامه شما کامپایل میشود یا نه رفتار میکنند. Claude Haiku 4.5 با خوشحالی برایتان یک اسکریپت Python مینویسد که مشکل شما را حل کند، به علاوه دو اسکریپت که خودش برای تفریح اختراع کرده است. نکته مهم—and تنها نکتهای که واقعاً اهمیت دارد—این است که یاد بگیرید چگونه از Claude Haiku 4.5 برای تولید کد دقیق درخواست دهید به گونهای که هیچ جای شک و حال و هوا نگذارد و بیشترین احتمال حقیقت حاصل شود. شما نمیخواهید نثر شبیه کد داشته باشید. شما میخواهید کدی که خودِ کد عمل میکند داشته باشید. این دو با هم فرق دارند.
بسیاری افراد پرومتنویسی را مثل طلسمهای جادویی میدانند—کلمات درست را بگویید، برنامه ای کامل دریافت کنید. این طرز فکر اشتباه است. کد یک قرارداد است. اگر از Claude Haiku دقت میخواهید، باید قرارداد را بنویسید. «یک وباپ بساز» قرارداد نیست. «یک endpoint در FastAPI بنویس در Python 3.12 که JSON میگیرد، با Pydantic v2 اعتبارسنجی میکند و در صورت خطای اسکما 422 با فرمت payload مشخص بازمیگرداند» قرارداد است. این است راز درخواست دقیق از Claude Haiku 4.5: قرارداد را محکم تعریف کنید.
این چیست (و چیست نیست)
- این یک راهنمای عملی است برای دریافت کدی قابل اعتماد و قابل تست از Claude Haiku 4.5.
- این موعظه درباره «جایگزین شدن توسعهدهندگان توسط هوش مصنوعی» نیست. ابزارها جایگزین تفکر نمیشوند.
- تمرکز روی پرومتهای کاربردی، ساختار، و راهنماییهاست: همان قسمتهای کسلکنندهای که جادو را ممکن میسازد.
اگر میخواهید کدی که اجرا میشود، باید برای Claude تعریف کارکردی «اجرا شدن» بدهید. اگر کد دقیق میخواهید، باید دقت را با عبارات ساده و تستپذیر تعریف کنید. این کل بازی است.
دقت را مثل یک وکیل تعریف کنید، نه شاعر
کد «دقیق» یعنی کدی که «به نظر معقول میرسد» نیست. دقت یعنی:
- درستی نحوی: کد کامپایل میشود یا در مفسر اجرا میشود.
- وفاداری معنایی: کد آنچه مشخصات میگوید را انجام میدهد.
- رفتار قطعی: ورودی یکسان، خروجی یکسان، در محدوده خطای تعریف شده.
- درست بودن نسخه: استفاده از SDKها، نسخههای API و ویژگیهای زبان درست.
Claude به شما آنچه میخواهید میدهد. اگر بخواهید «تابعی که لیستی را مرتب کند» احتمالاً دریافت میکنید. ولی اگر بخواهید «مرتبسازی پایدار و در محل با معنای تسورت + فضای اضافی O(1)» قولی دیگر است. «چگونگی پرومت کردن Claude Haiku 4.5 برای تولید کد دقیق» با نوشتن همین قولها در پرومت آغاز میشود.
کمینه پرومت قابل قبول، بهبود یافته
بد: «یک API Node برای کارها بنویس.»
بهتر: «یک API Node 20 Express 4 با مسیر POST /tasks بنویس که فیلدها {title: string, dueDate: ISO 8601} را اعتبارسنجی کند و 201 به همراه شیء ساختهشده یا 400 با جزئیات خطا پاسخ دهد.»
صحیح: «یک سرور Node 20 Express 4 بساز با یک تک endpoint POST به نام /tasks. الزامات: ۱) اعتبارسنجی بدنه با [email protected]؛ ۲) فیلدها: title (رشته غیرخالی، حداکثر ۱۴۰ کاراکتر)، dueDate (تاریخ آینده ISO 8601)؛ ۳) در صورت موفقیت: ۲۰۱ با {id: ULID, title, dueDate}؛ ۴) در صورت نامعتبر بودن: ۴۰۰ با {error: 'VALIDATION', details: array}؛ ۵) بدون بانک اطلاعاتی؛ استفاده از Map در حافظه؛ ۶) شامل فایل تست Jest 29 با پوشش حالتها معتبر، نامعتبر (title خالی، تاریخ گذشته)؛ ۷) ارائه اسکریپت npm برای تست و توسعه؛ ۸) استفاده از ESM؛ ۹) بدون توضیح اضافی.» شکل درخواست را ببینید: نسخه زبان، کتابخانهها، محدودیتها، خروجیها، خطاها، تستها، و حتی ساختار پکیج. ابهام حذف شده است. وظیفه Claude پر کردن کد است، نه مشخصات.
الگوی ساختار: سیستم، مشخصات، تستها، سپس کد
اگر میخواهید تولید کد دقیق از Claude Haiku 4.5، باید به آن باند فرود بدهید:
- شما: «شما کد تایپاسکریپت کیفیت تولید برای Node 20 مینویسید. فقط بلوکهای کد با نام فایل خروجی بده، نه چیز دیگر.»
- چرا: شما لحن و فرمت خروجی را کنترل میکنید. آن را به تصادف نسپارید.
- نسخه زبان، انتخاب پکیجها، معناشناسی خطا، فرمتهای ورودی/خروجی، محدودیتهای عملکرد و امنیت را درج کنید.
- به Claude بگویید ابتدا تست واحد بنویسد. تستها «دقیق» را بهتر از صفتها تعریف میکنند. اگر خطی از کد برای تستی کاربرد نداشته باشد، فقط تزئینی است.
- فقط پس از تستها. بله، این اساساً TDD است، ولی با رباتی که هرگز از نوشتن کدهای قالب خسته نمیشود.
- دستورالعمل برای اجرای مجدد
- «اگر تستها شکست خورد یا ایمپورتها هماهنگ نبودند، فقط بخشهای مشکلدار را به روز کن. کل پروژه را بازنویسی نکن.»
Claude وقتی زمینه و ریلها دارد بهتر عمل میکند. ریلها را بدهید.
پین کردن نسخه اختیاری نیست
دادههای آموزشی Claude پر است از مستندات قدیمی و جدید. این یعنی دادههای متناقض زیادی دیده است. «استفاده از React Router» مبهم است. «استفاده از [email protected] با data routers» جهتدهی دقیق است. به پیشفرضها اعتماد نکنید: - زبانها: به Python 3.12، Node 20، Go 1.22، Java 21 یا هر نسخهای که واقعا استفاده میکنید پین کنید.
- فریمورکها: نسخههای اصلی دقیق و هر فلگ تغییردهنده شکست را مشخص کنید.
- SDKهای ابری: نسخهها را پین کنید؛ تفاوت aws-sdk v2 و v3 مهم است.
- لینترها/فرمتکنندهها: قوانین را مشخص کنید تا بازنویسی بیپایان سبکها ایجاد نشود.
اگر نسخهها را پین نکنید، مجموعه اجرای بهترینها از پنج سال پست وبلاگی دریافت میکنید. تولید کد دقیق به نوستالژی حساسیت دارد.
همیشه از اسکما شروع کنید
از ساختارهای مبهم مثل «پروفایل کاربر» نپرسید. اسکماهای جامع در پرومت تعریف کنید و اعتبارسنجی را اجباری کنید:
- اسکمای JSON یا نوعهای Zod/Yup در JS/TS
- مدلهای Pydantic در Python
- Protobuf یا Avro برای سرویسها
بعد از آن از Claude بخواهید اسکماها را در مرزها اعمال کند—ورودی API، نوشتن به دیتابیس، صفهای پیام. خطاهای payload و کدهای صریح درخواست کنید. دقت اسکماها را میپسندد؛ ابهام را نه.
قابل مشاهدهپذیر بسازید، یا وانمود نکنید واقعی است
به Claude بگویید گزارشگیری، معیارها و ردیابی را در بخشهای مورد نیاز اضافه کند—و در جاهایی که نمیخواهید آنها را آرام نگه دارد. یک پرومت خوب شامل:
- سیاست گزارشگیری: سطحها، حذف دادههای حساس، ساختار (لطفاً json logs)
- معیارها: زمان پردازش هر درخواست، تعداد خطاها
- نقاط سلامت: /healthz که نشان دهد وابستگیها روشناند
Claude آنچه بخواهید میافزاید. اگر نخواهید، احتمالاً فقط print statement میگیرید، اگر خوششانس باشید.
پرومت اول تست بهتر از «فقط به من اعتماد کن»
راه خوب برای پرومت کردن Claude Haiku 4.5 برای تولید کد دقیق این است که تستها را منبع حقیقت قرار دهید. مثال:
«برای تابع normalize_email(s) تستهای pytest بنویس که:
- قسمت محلی و دامنه را به حروف کوچک تبدیل میکند؛
- نقاط در قسمت محلی فقط برای gmail.com حذف میکند؛
- برچسب (+tag) فقط برای gmail.com حذف میشود؛
- ورودیها بدون نماد @ یا دارای فاصله را رد میکند؛
- دامنه یونیکد punycode را بدون تغییر حفظ میکند.
حالات مرزی را پوشش دهید. بعد از نوشتن تستها، تابع را پیادهسازی کنید تا تستها را پاس کند.»
Claude اغلب وقتی مجبور به پاس کردن تستهای توصیفشده میشود، کد بهتری مینویسد. اگر ننوشت، یک شکست روشن دارید، نه بحث معنیدار.
از ابتدا بیتوهم بسازید
نمیتوانید توهمات را کاملاً حذف کنید، ولی آنها را مهار میکنید:
- فقط وقتی منابع وجود دارد درخواست ارجاع یا آدرس مستندات کنید. برای متدهای SDK لینک مستندات بخواهید و کد را مطابق آنها الزام کنید.
- برای APIهای خصوصی، مشخصات را در پرومت قرار دهید. انتظار نداشته باشید Claude endpointهای داخلی شمارا بداند.
- برای کتابخانههایی با APIهای گیجکننده، یک نمونه کد از مستندات رسمی درج و به Claude بگویید به آن پایبند باشد.
کد دقیق عمدتاً ارجاع دقیق است. ارجاعها را به Claude بدهید.
راهنمای سبک: کم جذابترین اما مفیدترین چیز
Claude کد را به هر سبکی که حدس بزند مینویسد. این باعث نوسان میشود. راهنمای سبک خود را بچسبانید. موارد زیر را مشخص کنید:
- قالببندی (Prettier، Black، پیشفرض gofmt)
همچنین درخواست یک کامنت مختصر درباره انتخابهای غیر واضح کنید. نسخه آینده شما ممنون میشود و Claude کنونی PRهای اصلاح کمتری میفرستد.
پرومتهای بلند، خروجیهای کوتاه
راه دیگر برای فکر کردن به چگونگی پرومت کردن Claude Haiku 4.5 برای کد دقیق: وقتتان را روی پرومت بگذارید، نه خروجی. شما میخواهید:
- محدودیتهای جامع در پرومت
- کمترین روایت غیرضروری در خروجی
به آن بگویید توضیحات را حذف کند و فقط بلوکهای کد با نام فایل و یک README کوتاه برگرداند. اگر توضیح میخواهید، جداگانه بخواهید. ترکیب نثر و کد جایگاه ورود باگهاست—با عینک یکچشمی و کلاه استمپی.
اصلاح: حلقههای کوتاه که واقعا کار میکنند
سریعترین راه به کد قابل اعتماد این نیست که «اولین بار درست شود.» بلکه چرخههای اصلاحی کوتاه است:
- محلی اجرا کن. خروجی تست شکست خورده و خطاهای کامپایلر را دقیقاً در Claude کپی کن.
- دستور بده: «تنها حداقل خطوط لازم را اصلاح کن؛ مگر تستها تابع را بخواهند تغییر نده.»
Claude وقتی دقیقا میداند چه چیزی اشتباه است عالیست. خروجی خطا را پارافرایز نکن؛ کپی کن. لاگها حقیقتاند.
امنیت ویژگی است، نه الحاقیه
چون مدلها روی کدهای عمومی آموزش دیدهاند (خوب، بد، و نفرینشده)، امنیت را جزو الزامات اولیه قرار دهید:
- صراحتاً eval، shell=True و SQL رشتهای را ممنوع کنید
- کوئریهای پارامتردهی شده، حفاظت CSRF و محدودیت نرخ را درخواست کنید
- پین کردن وابستگیها همراه با lockfile بخواهید
- مدیریت اسرار با متغیرهای محیطی یا مدیر اسرار الزامی کنید
پرومت امنیتی پیشفرض، کد ایمنتر میآورد. پرومت «بعداً اصلاح میکنیم» تیتر اخبار میسازد.
عملکرد: یعنی چی «سریع» است
«سریع بساز» یعنی «هر کاری دلت میخواهد کن.» به جایش معیار بدهید:
- هدف تاخیر (p95 کمتر از ۵۰ میلیثانیه برای در حافظه، p95 کمتر از ۳۰۰ میلیثانیه برای عملیات DB)
- حد حافظه (RSS کمتر از ۱۵۰ مگابایت)
- پیچیدگی زمانی (باید O(n log n) باشد، نه O(n²))
Claude الگوریتمها را بر اساس بودجه شما انتخاب میکند. به آن بودجه بدهید.
مستندسازی: کافی برای آموزش یک غریبه
از Claude README بخواهید که شامل شود:
- دستورالعملهای نصب همراه نسخههای دقیق
- دستورات تست، lint، تایپچک، اجرا
- درخواستها/پاسخهای نمونه
- محدودیتها و مبادلههای شناختهشده
«کد دقیق» شامل مستندات دقیق هم هست. آنها جزیی از تحویل هستند.
قالبهای پرومت قابل استفاده مجدد
قالب: Endpoint بکاند
سیستم: شما مهندس Python 3.12 دقیق هستید. فقط بلوکهای کد با نام فایل خروجی دهید.
کاربر:
- یک اپ FastAPI 0.111 بساز با endpoint POST به آدرس /convert.
- درخواست: {amount: رشتهای به صورت Decimal, from: 'USD'|'EUR', to: همان}.
- با pydantic v2 اعتبارسنجی کن؛ در صورت خطای اسکما 422 برگردان.
- از تابع pure convert(amount, from, to) با نرخهای ثابت {USD:1, EUR:1.1} استفاده کن.
- پاسخ: {amount: رشته، currency: رشته} با کد 200.
- شامل تستهای pytest برای موارد معتبر، نامعتبر (دسیمال نادرست، کد ناشناخته) و حالات مرزی (0).
- pyproject.toml با وابستگیهای پین شده؛ شامل تنظیمات ruff و mypy.
- بدون تماس شبکه، بدون توضیح.
قالب: ابزار CLI
سیستم: شما در حال نوشتن Go 1.22 هستید. فقط بلوکهای کد با نام فایل خروجی دهید.
کاربر:
- یک CLI به نام slugify بساز که stdin را بخواند و اسلاگهای امن URL چاپ کند.
- قوانین: حروف کوچک، فقط ASCII، جداکننده خط تیره، ادغام فاصلهها، حذف نشانهها.
- main.go و slugify_test.go با تستهای جدول بساز.
- فقط از استاندارد کتابخانه Go استفاده کن.
- Makefile با اهداف تست و ساخت فراهم کن.
قالب: کامپوننت فرانتاند
سیستم: شما مهندس React عملگرا با هدف React 18 + TypeScript هستید.
کاربر:
- یک کامپوننت <DebouncedInput> پیادهسازی کن.
- Props: value: string, onChange(value): void, delay=300.
- از useRef/useEffect استفاده کن؛ از hookهای ثالث استفاده نکن.
- شامل تستهای vitest با تایمرهای جعلی.
- یک داستان حداقلی Storybook ارائه کن.
این قالبها نشان میدهند چگونه میتوان Claude Haiku 4.5 را برای تولید کد دقیق با پین کردن نسخهها، تعریف رفتار و درخواست تستها پرومت کرد.
امتناع از هوشمندی بیش از حد: کی بگوییم «بهینه نکن»
اگر نمیخواهید بهینهسازیهای کوچک زودهنگام (و معمولاً نمیخواهید)، بگویید:
- «خوانایی را به پیچیدگی ترجیح بده؛ بدون بیتتویدل مگر اینکه تستها الزام کنند.»
- «بدون بازگشت (recursion) اگر تکراری واضحتر است.»
- «بدون متاپروگرامینگ؛ صریح > ضمنی.»
Claude دوست دارد تحت تاثیر قرار دهد. نگذارید. آن را مجبور کنید تستها را پاس کند و قابل خواندن باشد. این کافی است.
Sider.AI در گردش کار، جایی که واقعاً کمک میکند من دیدهام افراد پرومتها را در تبهای چت مختلف جابهجا میکنند گویی دین بهرهوری است. از فضای کاری استفاده کنید که زمینه کد را بفهمد. Sider.AI، برای مثال، حول نگهداری مشخصات، کد، تفاوتها و لاگهای تست ساخته شده تا حلقه «کپی خطا، اصلاح کد» سفت و محکم باشد. این جادو نیست؛ این همان ساختار کسلکنندهای است که از گم کردن داستان جلوگیری میکند. اگر ابزارتان قرارداد، تستها و کد را در همان گفتگو نگه میدارد—بدون اینکه با کنفِتی اذیتتان کند—از آن استفاده کنید. Sider چنین است. چگونه با Claude به عنوان همتیمی دیباگ کنیم، نه پیامبر
- خروجی تست شکست خورده را دقیقاً کپی کنید. خلاصه نکنید.
- برای دیباگ درخواست بده: «فقط تفاوت یکپارچه با فایل X بفرست.»
- برای باگهای زمان اجرا کوچکترین نمونه قابل بازتولید را اضافه کنید و به همراه توضیح و اصلاح بخواهید.
- برای خطاهای کتابخانه، تکه مستندات مربوطه را کپی و بپرسید: «آیا این API برای نسخه X درسته؟ اگر نه، کد را اصلاح کن و منبع درست را ذکر کن.»
هدف این است که Claude را وادار کنید با دلیل بحث کند. شما دلیل میآورید.
دامهای رایج (و چگونگی دوری از آنها)
- دام «آخرین نسخه»: نگویید «از آخرین استفاده کن.» بگویید «از نسخه X.Y استفاده کن» و وفادار بمانید.
- فایل تست خالی: اگر تست نخواهید، تست نمیگیرید.
- اشتباه تکباری: برنامه دو یا سه اصلاح کوتاه داشته باشید. از یک پرومت حجیم سریعتر است.
- سیاست خطای مبهم: کدهای وضعیت و قالب payload را مشخص کنید. «برگشت خطا» معنایی ندارد.
- وابستگی بدون مالک: اگر کد به سرویسی که نمیتوانید مدیریت کنید وابسته است، شبیهسازی (fake) بخواهید.
چکلیست پرومت شما (روی مانیتور بچسبانید)
- نسخه زبان و محیط اجرا مشخص شده
- نسخه کتابخانهها مشخص شده
- معناشناسی خطا مشخص شده (کدها، قالبها)
- فرمت خروجی محدود (نام فایل، بلوک کد،diff)
- حلقه اصلاح کوتاه با لاگهای کپی شده
اگر این ده مورد اجرا شود، Claude Haiku 4.5 معمولاً کدی دقیق تولید میکند که در دنیای واقعی هم کار میکند.
مثال کاربردی: از مبهم تا تایید شده
پرومت مبهم: «یک تابع برای پارس CSV امن بنویس.»
نتیجه: احتمالاً خوب، ممکن است اشتباه، مطمئناً بدون تست.
پرومت دقیق:
«شما کد Python 3.12 مینویسید. فقط بلوکهای کد با نام فایل خروجی دهید.
فولدر csvsafe بساز با فایلهای init.py و reader.py شامل تابع read_rows(path: Path) -> list[dict[str,str]]. الزامات: استفاده از csv.DictReader با newline='' و encoding='utf-8'; نپذیرفتن بایت صفر; رد فایلهای بزرگتر از 10MB; محدودیت ستونها به 100; حذف BOM; سلولهای خالی به رشته خالی تبدیل شوند; خطاهای ValueError با کدهای پیام {FILE_TOO_LARGE, NULL_BYTE, TOO_MANY_COLUMNS} پرتاب شود. تستها در tests/test_reader.py با pytest پوشش سناریوهای موفق، بایت صفر، فایل 11MB، 101 ستون و مدیریت BOM. ارائه pyproject.toml با وابستگیهای پین شده و تنظیمات black.»
شما کد، تست و مدیریت حالات خاص خواهید داشت. سپس تستها را اجرا میکنید، خطاها را کپی میکنید و با حداقل تغییر اصلاح میکنید. این است تولید کد دقیق در عمل.
درباره «خلاقیت» و دیگر کلمات بازاریابی
من به کد «خلاق» نیاز ندارم. به کد درست نیاز دارم. خلاقیت را برای نامگذاری گربهتان نگه دارید. در پرومت کردن Claude، خلاقیت حاصل محدودیتهای محکم است. تستها و مشخصات درست راهحلهای زیبا میآورند. پرومت اشتباه منجر به «رمزگذاری پایه64 با ایموجی» میشود. وسوسهاش نکنید.
راز بدون راز
راه پرومت کردن Claude Haiku 4.5 برای تولید کد دقیق خستهکننده است: نیازتان را بنویسید، نسخهها را پین کنید، اسکماها را تعریف کنید، تست بخواهید و با شکستها اصلاح کنید. همین. بیجادو، فقط انضباط مهندسی، با مدلی که سریع تایپ میکند و نوشتن پانزده تست تقریباً مشابه اذیتش نمیکند.
و این همان نکته است: دقت جذاب نیست. پرومتهایی که کار میکنند مثل چکلیست TSA اند. کدی که ارسال میشود مثل کدی است که یک انسان دقیق نوشته. این هر دو را وقتی میگیرید که مدل را مثل یک مهندس جونیور فرض کنید که با مشخصات واضح جان میگیرد و با دستورات مبهم پژمرده میشود. به آن قرارداد بدهید. بگذارید تستها را پاس کند. شاید آنوقت بتوانید اعتماد کنید—اعتمادی شبیه ابزار نه پیامبر.
نتیجهگیری: کمتر جادو، بیشتر ضمانت
اگر جادو میخواهید، به نمایش سحر و جادو بروید. اگر نرمافزاری که کامپایل شود و درست کار کند میخواهید، پرومتهایی بنویسید که مثل ضمانتنامه عمل کنند. چگونگی پرومت کردن Claude Haiku 4.5 برای تولید کد دقیق درباره عبارات پر زرق و برق یا کلمات کلیدی مخفی نیست. درباره محدودیتها، تستها، نسخهها و حلقههای بازخورد است. این چهار کار را انجام دهید، کدی که اجرا شود میگیرید. اگر نکنید، داستان زیبایی میگیرید که فرمت شده است.
کد به احساسات شما اهمیتی نمیدهد. خوشبختانه، تستها هم همینطور.
سوالات متداول
سوال 1: سادهترین راه برای درخواست تولید کد دقیق از Claude Haiku 4.5 چیست؟
با آن مانند یک قرارداد رفتار کنید: نسخهها را پین کنید، طرحوارهها را تعریف کنید، فرمتهای خطا را مشخص کنید و ابتدا تستها را الزامی کنید. هرچه محدودیتها واضحتر باشند، کد دقیقتر خواهد بود.
سوال 2: چگونه میتوانم توهمات را هنگام کدنویسی توسط Claude کاهش دهم؟
اسناد یا مشخصات معتبر را جایگذاری کنید و خواستار پایبندی به همان APIها شوید. برای نقاط پایانی خصوصی، مشخصات خودتان را درج کنید—انتظار نداشته باشید که آن را حدس بزند.
سوال 3: آیا باید از Claude درخواست تست کنم یا خودم آنها را بنویسم؟
ابتدا از Claude بخواهید تستها را تولید کند، سپس کدی را پیادهسازی کنید تا آنها را برآورده کند. تستها دقت را بهتر از صفات تعریف میکنند و مدل را صادق نگه میدارند.
سوال 4: چقدر باید پین کردن نسخه در اعلانها (prompts) خاص باشد؟
بسیار خاص: زمان اجرای زبان، ماژور/مینور فریمورک و نسخههای SDK. «آخرین نسخه» الگوهای متناقض را دعوت میکند؛ دقت به اهداف پایدار بستگی دارد.
سوال 5: Sider.AI در اعلان برای کد دقیق کجا قرار میگیرد؟
از Sider.AI استفاده کنید تا مشخصات، کد، دیفها و گزارشهای تست را در یک حلقه نگه دارید. این کار جادو نمیکند—فقط زمینه را حفظ میکند تا اصلاحات Claude، خرابیهای واقعی شما را ردیابی کند. 
