98 lines
10 KiB
Markdown
98 lines
10 KiB
Markdown
# مشخصات درس‌نامه: اصول مهندسی پرامپت (Prompt Engineering for Vibe Coding)
|
||
- **شناسه در سیلابس:** `L2.6`
|
||
- **فصل:** فصل ۲: شروع مسیر Vibe Coding (Ch 2)
|
||
- **نوع محتوا:** 📘 درس‌نامه متنی
|
||
- **زمان تقریبی مطالعه:** ۱۲ دقیقه
|
||
- **پیش‌نیازهای مستقیم:** `L2.5` (انتظارات واقع‌بینانه و هزینه)
|
||
|
||
---
|
||
|
||
## ۱. اهداف یادگیری (Learning Objectives - Bloom's Taxonomy)
|
||
دانشجو پس از مطالعهٔ این درس‌نامه باید بتواند:
|
||
- [ ] **درک کند (Understand):** چرا پرامپت‌نویسی برای ایجنت‌های توسعه نرم‌افزار با چت کردن عادی با چت‌بات‌های متنی متفاوت است.
|
||
- [ ] **به‌کار ببندد (Apply):** فرمول چهاربخشی پرامپت مهندسی نرم‌افزار را اجرا کند: **بافت (Context) + هدف مشخص (Objective) + محدودیت‌ها (Constraints) + معیارهای پذیرش (Acceptance Criteria)**.
|
||
- [ ] **به‌کار ببندد (Apply):** قانون اتمیک بودن (Rule of Atomicity) را پیاده کند؛ درخواست‌های بزرگ را به تسک‌های تک‌مرحله‌ای، مستقل و قابل‌تست بشکند و از «تلهٔ مگاپرامپت» پرهیز کند.
|
||
- [ ] **به‌کار ببندد (Apply):** از پرامپت‌های چندرسانه‌ای (ارسال تصویر و اسکرین‌شات از خطاها یا طرح‌های بصری) برای انتقال سریع‌تر منظور استفاده کند.
|
||
- [ ] **به‌کار ببندد (Apply):** الگوی استاندارد گزارش خطا (Structured Error Reporting) را پیاده کند؛ ارسال مستقیم متن کامل خطای ترمینال یا کنسول به جای جملات مبهم نظیر «کار نکرد، درستش کن!».
|
||
|
||
---
|
||
|
||
## ۲. محدوده و مرزهای محتوا (Scope & Boundaries)
|
||
|
||
### آنچه باید پوشش داده شود (In-Scope):
|
||
1. **گذار از گفتگوی سطحی به دستورالعمل مهندسی:**
|
||
* هوش مصنوعی ذهن‌خوان نیست؛ وضوح ورودی شما دقیقاً کیفیت خروجی کد را تعیین می‌کند (Garbage In, Garbage Out).
|
||
2. **فرمول طلایی پرامپت نرم‌افزاری (The 4-Part Vibe Formula):**
|
||
* **۱. بافت و زمینه (Context):** ما در حال ساخت چه پروژه‌ای هستیم و چه استکی داریم؟
|
||
* **۲. هدف مشخص (Objective):** دقیقاً چه تغییری، چه فیچری یا چه تابعی باید اضافه/اصلاح شود؟
|
||
* **۳. محدودیت‌ها (Constraints):** چه چیزهایی نباید تغییر کنند؟ چه پکیج‌های خاصی باید استفاده یا پرهیز شوند؟
|
||
* **۴. معیارهای پذیرش (Acceptance Criteria):** از کجا بفهمیم کار با موفقیت انجام شده است؟ (مثلاً «یک پیام سبز موفقیت نمایش داده شود»).
|
||
3. **قانون تغییرات اتمیک (Rule of Atomicity):**
|
||
* تفاوت پرامپت مخرب همه‌کاره («برای من یک فروشگاه مثل دیجی‌کالا بساز با سبد خرید و درگاه پرداخت و پنل ادمین») با زنجیره پرامپت‌های اتمیک («گام ۱: فقط کارت نمایش محصول را بساز»).
|
||
* چرا شکستن کار به گام‌های کوچک، خطای ایجنت را به صفر نزدیک می‌کند و تست خروجی را آسان می‌سازد.
|
||
4. **پرامپت‌های چندرسانه‌ای (Multimodal Visual Prompts):**
|
||
* استفاده از اسکرین‌شات رابط کاربری: کشیدن دایره قرمز دور بخشی که چیدمانش به هم ریخته یا رنگش غلط است.
|
||
* ارسال تصویر یک نمونه واقعی (Inspiration) برای ساخت ظاهر مشابه در کد.
|
||
5. **الگوی گزارش دقیق باگ و خطا (Bug Reporting Pattern):**
|
||
* چرا نباید بنویسیم «دکمه کار نکرد» یا «خراب شد»؟
|
||
* فرمول گزارش خطا: ۱. چه کاری انجام دادم؟ ۲. چه خطایی در ترمینال رخ داد (کپی دقیق متن خطا)؟ ۳. چه انتظاری داشتم؟
|
||
6. **کال‌اوت‌های Quera:**
|
||
* `<details class="violet">`: مقایسه دو پرامپت واقعی ضعیف و مهندسی‌شده قبل و بعد برای یک فیچر مشخص.
|
||
* `<details class="red">`: تلهٔ مگاپرامپت (The Mega-Prompt Trap)؛ علت اصلی قاطی کردن ایجنت‌ها و شلختگی کدهای پروژه.
|
||
|
||
### آنچه نباید وارد آن شویم (Out-of-Scope):
|
||
- نوشتن سند PRD یا ساختار تسک‌های چندفصلی (این کار در فصل ۴ آموزش داده می‌شود).
|
||
- آموزش‌های متفرقه پرامپت‌نویسی ادبی، شعر، کپی‌رایتینگ متنی یا تحلیل بازار.
|
||
|
||
---
|
||
|
||
## ۳. مفاهیم کلیدی و کلمات تخصصی (Key Concepts & Terms)
|
||
|
||
| اصطلاح انگلیسی | معادل فارسی مصوب | توضیح یک‌خطی ساده |
|
||
| :--- | :--- | :--- |
|
||
| Prompt Engineering | مهندسی پرامپت | مهارت تنظیم دستورالعمل‌های دقیق، محدود و ساخت‌یافته برای دستیابی به خروجی کد بهینه |
|
||
| Atomicity | اتمیک بودن / تجزیه‌ناپذیری | تکه‌تکه کردن تسک‌های نرم‌افزاری به گونه‌ای که هر پرامپت فقط یک هدف واحد و قابل تست داشته باشد |
|
||
| Mega-Prompt | مگاپرامپت | دستور فوق‌العاده حجیم و درهم‌تنیده که همزمان ده‌ها فیچر را طلب می‌کند و باعث شکست مدل می‌شود |
|
||
| Multimodal Prompting | پرامپت‌نویسی چندرسانه‌ای | ترکیب متن، اسکرین‌شات رابط کاربری و تصاویر خطای برنامه در دستور ورودی به ایجنت |
|
||
| Error Stack Trace | ردپای خطای نرم‌افزاری | پیام متنی دقیق تولیدشده توسط سیستم که نام فایل، شماره خط و علت رخ دادن باگ را نشان می‌دهد |
|
||
|
||
---
|
||
|
||
## ۴. جایگاه‌های تصاویر و نمودارها (Visual & Diagram Placeholders)
|
||
> **راهنمای ایجنت نویسنده:** تمام تصاویر باید در پوشهٔ `images/` قرار گرفته و در قالب جدول تک‌خانه‌ای وسط‌چین با کپشن تفصیلی درج شوند:
|
||
|
||
1. **تصویر کاور درس:** `images/cover.png`
|
||
* **موضوع:** کاور با تم تیره که پرامپت ساخت‌یافته را مانند یک معمار در حال چیدن آجرهای کد منظم و دیجیتال نشان می‌دهد.
|
||
2. **فرمول چهارگانه پرامپت نرم‌افزاری:** `images/vibe-prompt-formula.png`
|
||
* **موضوع:** اینفوگرافیک ۴ قطعه پازل: بافت (Context)، هدف (Objective)، محدودیت‌ها (Constraints)، و معیار قبولی (Acceptance Criteria).
|
||
3. **اصل اتمیک بودن در برابر انفجار مگاپرامپت:** `images/atomicity-vs-megaprompt.png`
|
||
* **موضوع:** مقایسه تصویری: یک درخواست غول‌پیکر که ایجنت را گیج می‌کند در برابر ۳ پله کوچک و متوالی که یکی‌یکی با موفقیت سبز می‌شوند.
|
||
4. **جادوی اسکرین‌شات و پرامپت بصری:** `images/multimodal-prompting.png`
|
||
* **موضوع:** نمونه کاربردی فرستادن یک اسکرین‌شات با حاشیه‌نویسی ساده به ایجنت و اصلاح دقیق استایل دکمه در اولین تلاش.
|
||
5. **چرخه صحیح گزارش و رفع خطا:** `images/error-reporting-loop.png`
|
||
* **موضوع:** فلوچارت ارسال متن لاگ خطا $\rightarrow$ تحلیل ایجنت $\rightarrow$ اعمال پچ اصلاحی $\rightarrow$ تست مجدد توسط کاربر.
|
||
|
||
---
|
||
|
||
## ۵. بخش‌بندی و ساختار محتوایی پیشنهادی درس‌نامه (`README.md`)
|
||
|
||
1. **تیتر اصلی:** `# اصول مهندسی پرامپت در وایب کدینگ`
|
||
2. **مقدمه:** چرا نحوه حرف زدن شما با ایجنت، تفاوت بین یک محصول حرفه‌ای و یک پروژه به بن‌بست خورده است؟
|
||
3. **جدول کاور درس**
|
||
4. **تفاوت پرامپت کدنویسی با چت روزمره:** عبور از «کد بنویس» به سمت مشخصه‌سازی دقیق نیازمندی.
|
||
5. **فرمول چهاربخشی پرامپت وایب کدینگ:** تشریح بافت، هدف، محدودیت‌ها و شرایط پذیرش با یک مثال ملموس.
|
||
6. **باکس نمونه Quera (`<details class="violet">`):** کالبدشکافی یک پرامپت بد در برابر یک پرامپت استاندارد مهندسی‌شده.
|
||
7. **قانون طلایی اتمیک بودن (One Step at a Time):** چرا باید پروژه را لقمه‌لقمه به هوش مصنوعی تحویل دهیم؟
|
||
8. **باکس هشدار Quera (`<details class="red">`):** خطرات مرگبار مگاپرامپت‌ها در نابودی معماری پروژه.
|
||
9. **قدرت پرامپت‌های تصویری (Multimodal):** چگونه یک تصویر، کار صد کلمه توضیح گیج‌کننده را انجام می‌دهد؟
|
||
10. **هنر گزارش خطا: چگونه باگ‌ها را به هوش مصنوعی تحویل دهیم؟:** نحوه کپی کردن لاگ، بیان انتظار و حل سیستماتیک مشکل.
|
||
11. **جمع‌بندی درس‌نامه:** تمرین مهارت پرامپت‌نویسی به عنوان زبان مادری سازندگان آینده.
|
||
|
||
---
|
||
|
||
## ۶. معیارهای پذیرش (Acceptance Criteria for Reviewer)
|
||
- [ ] فرمول چهاربخشی پرامپت‌نویسی نرم‌افزار به وضوح آموزش داده شده باشد.
|
||
- [ ] اصل اتمیک بودن به همراه مثال واقعی در متن جا افتاده باشد.
|
||
- [ ] روش ارسال خطاها با کپی کردن لاگ و متن کامل کنسول در برابر ارسال جملات گنگ تبیین شده باشد.
|
||
- [ ] کال‌اوت‌های کوئرا با محتوای کاربردی و قالب متنی تمیز درج شده باشند.
|