بستهٔ پرامپت‌های کدنویسی Claude برای دیباگ، بازآرایی کد و بازبینی معماری

چهار محدودیتی که هر پرامپت زیر را کارآمد می‌کند

پیش از رسیدن به پرامپت‌ها، قواعدی که همهٔ آن‌ها مشترک دارند. افزودن این‌ها به هر پرامپت کدنویسی، خروجی را بیشتر از تغییر مدل بهبود می‌دهد.

نسخهٔ خود را مشخص کنید. داده‌های آموزشی به سمت هر نسخهٔ اصلی‌ای که بیشترین محتوا دربارهٔ آن نوشته شده متمایل‌اند، که اغلب همان نسخه‌ای نیست که شما از آن استفاده می‌کنید. We are on [framework] [version], [language] [version] جلوی بیشتر پاسخ‌های قدیمی را می‌گیرد.

دیف را محدود کنید. وقتی درخواست یک اصلاح می‌کنید، اغلب یک بازآرایی کامل تحویل می‌گیرید. Change as little as possible, preserve existing structure and naming, and list every line you changed with a one line reason مفیدترین جملهٔ تک این سند است.

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

حالت شکست را الزامی کنید. What could this break, and is this fixing the cause or the symptom? گران‌ترین دستهٔ کمک هوش مصنوعی را شناسایی می‌کند: تغییری که علامت را از بین می‌برد در حالی که خود عیب باقی می‌ماند.

دیباگ کردن

1. فرضیه‌های رتبه‌بندی‌شده

خطا، کد مربوطه و مواردی را که تاکنون رد کرده‌ام، اینجا می‌آورم. هنوز راه‌حل نده. چهار علت محتمل‌تر را به ترتیب احتمال فهرست کن و برای هرکدام، کم‌هزینه‌ترین بررسی‌ای که آن را تأیید یا رد می‌کند. خطا: [بچسبانید]. کد: [بچسبانید]. مواردی که رد شده: [فهرست]. استک: [زبان، فریم‌ورک، نسخه‌ها].

2. باگ متناوب

این مورد به‌طور متناوب، تقریباً [بسامد]، تحت [شرایط] خراب می‌شود. دسته‌های شکست متناوبی را که می‌توانند این علامت خاص را ایجاد کنند فهرست کن: زمان‌بندی، ترتیب، اتمام منابع، یک وابستگی خارجی، نشت وضعیت بین اجراها، ساعت یا منطقهٔ زمانی، کش. برای هرکدام بگو چه چیزی در کد آن را تأیید یا رد می‌کند و دقیقاً چه چیزی باید لاگ بگیرم تا آن‌ها را از هم تشخیص دهم. کد: [بچسبانید].

3. روی سیستم من کار می‌کند

این مورد به‌صورت محلی کار می‌کند اما در [محیط] خراب می‌شود. همهٔ دسته‌های تفاوت محیطی را که می‌توانند این علامت خاص را ایجاد کنند فهرست کن: پیکربندی، متغیرهای محیطی، نسخه‌ها، سیستم فایل و حساسیت به بزرگی و کوچکی حروف، منطقهٔ زمانی و لوکیل، شبکه و DNS، مجوزها، محدودیت منابع و تفاوت‌های بیلد یا باندلینگ. با توجه به علامت، بر اساس احتمال رتبه‌بندی کن و برای هرکدام دستور تشخیصی بده.

4. پیش از پذیرفتن اصلاح، آن را توضیح بده

توضیح بده چرا این اصلاح کار می‌کند، چه چیزی را اصلاح نمی‌کند و چه چیزی ممکن است خراب کند. اگر علت واقعی جای دیگری است و این فقط یک وصلهٔ روی علامت است، مستقیماً همین را بگو.

بررسی کد

5. بررسی یک دیف

این دیف را مانند یک بازبین سخت‌گیر بررسی کن. دسته‌ها به ترتیب اولویت: باگ‌های درستی، مسائل امنیتی، حالت‌های شکست مدیریت‌نشده، شرایط مسابقه‌ای (race condition)، سپس سبک نگارش. برای هر یافته، شدت، خط دقیق و اینکه چرا در این کدبیس اهمیت دارد نه به‌طور کلی را بگو. دربارهٔ قالب‌بندی نظر نده. اگر دیف درست است، همین را بگو نه اینکه یافته‌های ساختگی بسازی. قراردادها: [توضیح دهید]. دیف: [بچسبانید].

6. بازبینی امنیتی

این کد را مشخصاً از نظر مسائل امنیتی بررسی کن: تزریق (injection)، شکاف‌های احراز هویت و مجوزدهی، دی‌سریالایز ناامن، اسرار درون کد یا لاگ‌ها، ورودی اعتبارسنجی‌نشده که به یک عملیات حساس می‌رسد و ریسک وابستگی‌ها. برای هرکدام، مسیر حمله را به‌طور مشخص بده نه فقط نام دسته را. صریح بگو چه چیزی را بدون دیدن [استقرار، لایهٔ احراز هویت، حساسیت داده] نمی‌توانی ارزیابی کنی.

7. ممیزی حالت شکست

برای هر فراخوانی خارجی در این کد، بگو چه اتفاقی می‌افتد وقتی کند است، وقتی شکست می‌خورد، وقتی داده‌ای غیرمنتظره برمی‌گرداند و وقتی موفق اما ناقص است. کدام‌یک از این‌ها فعلاً مدیریت نشده‌اند و کدام‌یک بی‌صدا رخ می‌دهند؟

این آخری مشکلات واقعی محیط عملیاتی را بیشتر از یک بررسی عمومی پیدا می‌کند، چون دربارهٔ مسیرهایی می‌پرسد که هیچ‌کس برایشان تست ننوشته.

بازآرایی و معماری

8. برنامهٔ بازآرایی

یک برنامهٔ مرحله‌به‌مرحله برای بازآرایی [توضیح] پیشنهاد بده. محدودیت‌ها: API عمومی [x] نباید تغییر کند، ما به‌طور پیوسته دیپلوی می‌کنیم پس هر مرحله باید مستقلاً قابل ارسال باشد و تست‌ها باید پس از هر مرحله پاس شوند. برای هر مرحله، تغییر، ریسک، نحوهٔ تأیید و نحوهٔ بازگردانی را بده. بر اساس ریسک مرتب کن، کم‌ریسک‌ترین اول. هنوز کد ننویس.

9. طرف مقابل را استدلال کن

من [رویکرد A] را به‌جای [رویکرد B] برای [زمینه و محدودیت‌ها] انتخاب می‌کنم. قوی‌ترین استدلال را برای B بیاور. برای درست بودن B، چه چیزی باید دربارهٔ محدودیت‌های ما صادق باشد و آیا هیچ‌کدام از آن‌ها اینجا صادق است؟ نتیجه نگیر که هر دو معتبرند.

10. آنچه به ارث برده‌ای را بفهم

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

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

تست‌ها

11. تست‌هایی که خودتان نمی‌نوشتید

برای این تابع موارد تست بنویس، با تمرکز بر ورودی‌هایی که احتمالاً در نظر نگرفته‌ام: مرزها، خالی و null، یونیکد، مقادیر بسیار بزرگ، فراخوانی‌های همزمان و هر فرض ضمنی در پیاده‌سازی. برای هر تست، فرضی را که بررسی می‌کند بیان کن. تابع: [بچسبانید].

12. مجموعهٔ تست را تست کن

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

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

الگوی نظر دوم

پراثرترین عادت در کل این بسته، همان که به بیش از یک مدل نیاز دارد.

از یک مدل پاسخ بگیرید. سپس عوض کنید و آن را تحویل بدهید:

یک مهندس دیگر این راه‌حل را برای این مسئله پیشنهاد کرده. آنچه در آن اشتباه است را پیدا کن: درستی در حالت‌های حاشیه‌ای، همزمانی، مدیریت خطا، عملکرد در [مقیاس]، یا رویکردی ساده‌تر که نادیده گرفته شده. اگر واقعاً درست است، صریح همین را بگو نه اینکه ایراد بتراشی. مسئله: [بچسبانید]. راه‌حل پیشنهادی: [بچسبانید].

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

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

مراقب چه چیزهایی باشید

APIهای اختراعی. نام‌های متد، پارامترها و کلیدهای پیکربندی مطمئنی که وجود ندارند، به‌خصوص برای کتابخانه‌هایی که اخیراً تغییر کرده‌اند. امضای تابع درست به نظر می‌رسد. پیش از ساختن روی هر چیز ناآشنا، مستندات واقعی را بررسی کنید.

نبود سیگنال اطمینان. یک اصلاح درست و یک اصلاح ظریف اما اشتباه، هر دو با قطعیت یکسانی ارائه می‌شوند. لحن هیچ چیزی به شما نمی‌گوید.

گسترش بی‌صدای دامنه. محدودیت دوم دقیقاً برای همین وجود دارد.

نمایش امنیتی. نام بردن دسته‌های آسیب‌پذیری در کدتان یک گذر اولیهٔ مفید است. این یک ممیزی نیست و مدل، مدل تهدید، استقرار یا حساسیت دادهٔ شما را نمی‌داند.

پرامپت‌هایی را که هفتگی استفاده می‌کنید جایی نگه دارید که بتوانید از آن کپی کنید، و محدودیت‌های ثابت را در دستورالعمل‌های پروژه قرار دهید تا به‌طور خودکار روی هر گفتگوی آن پروژه اعمال شوند.