روش پرامپت‌نویسی برای ساخت سایت اسکرولی

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

حالا سؤال اصلی: چطور این دانش را به هوش مصنوعی منتقل کنیم تا به‌جای ما کد بزند؟

جواب کوتاه: با «پرامپت خوب» نه. با سیستم پرامپت. تفاوت این دو، تفاوت بین کسی است که بعد از دو ساعت یک صفحهٔ کارآمد دارد و کسی که بعد از دو ساعت هنوز با مدل کل‌کل می‌کند.

چرا «یک سایت سینمایی بساز» همیشه شکست می‌خورد

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

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

قانون تصمیم

قبل از هر پرامپت، این را از خودت بپرس: «چند تصمیم در این درخواست باز مانده؟» اگر بیشتر از دو تا بود، پرامپت هنوز آمادهٔ فرستادن نیست.

سیستم چهارلایه‌ای

روشی که بعد از ده‌ها پروژه به آن رسیده‌ام، چهار لایه دارد و هر لایه یک گفت‌وگوی جداگانه است:

لایه	خروجی	هیچ‌وقت اینجا نخواه
۱. روایت	استوری‌بورد پرده‌ها	هیچ کدی
۲. اسکلت	HTML و CSS ثابت	هیچ انیمیشنی
۳. حرکت	جاوااسکریپت انیمیشن	تغییر در ساختار
۴. صیقل	کارایی، موبایل، دسترس‌پذیری	افکت جدید

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

قالب پایه: هفت بخش هر پرامپت

۱. نقش      — مدل چه کسی است
۲. زمینه    — چه چیزی از قبل ساخته شده
۳. کار      — دقیقاً چه بساز
۴. قیدها    — چه چیزهایی حتماً رعایت شود
۵. ممنوع‌ها — چه چیزهایی اصلاً نکن
۶. خروجی    — به چه شکلی تحویل بده
۷. بررسی    — قبل از تحویل خودت چه چک کنی

بخش پنجم و هفتم را اغلب حذف می‌کنند و همان‌ها بیشترین اثر را دارند. بند «ممنوع‌ها» جلوی بازنویسی ناخواسته را می‌گیرد و بند «بررسی» کیفیت خروجی را به‌طرز محسوسی بالا می‌برد.

لایهٔ ۱ — پرامپت روایت

نقش: کارگردان روایت وب و استراتژیست محتوا.

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

کار:
۱) پیام اصلی را نقد کن و در صورت ابهام، سه بازنویسی بهتر بده.
۲) صفحه را به ۵ تا ۷ پرده بشکن.
۳) برای هر پرده بنویس: پیام یک‌جمله‌ای، حرکت پیشنهادی،
   حال‌وهوای بصری، خروجی ذهنی کاربر، و انرژی از ۱ تا ۵.
۴) بگو کدام پرده روی موبایل مشکل‌ساز است و جایگزینش چیست.

ممنوع: هیچ کدی ننویس. هیچ نام کتابخانه‌ای نبر.
خروجی: یک جدول + سه خط توضیح زیر هر پرده. فارسی روان.
بررسی: قبل از تحویل مطمئن شو قوس انرژی یکنواخت نیست.

لایهٔ ۲ — پرامپت اسکلت

نقش: توسعه‌دهندهٔ فرانت‌اند متخصص صفحات روایت‌محور.

زمینه: استوری‌بورد تأییدشده:
[کل خروجی لایهٔ ۱ را اینجا بچسبان]

کار: فقط اسکلت HTML و CSS این صفحه را بنویس.

قیدها:
- هر پرده یک section با کلاس scene و یک کلاس اختصاصی.
- ظرف بخش پین بلند (۱۰۰vh به ازای هر پنل) و
  استیج داخلی دقیقاً 100svh.
- از svh استفاده شود نه vh.
- متغیرهای فاصله و عرض در :root تعریف شوند.
- عناصر متحرک فقط با صفت data-reveal علامت بخورند.
- بلوک prefers-reduced-motion اضافه شود.
- تصاویر width و height داشته باشند.
- دو لایهٔ smooth-wrapper و smooth-content از قبل باشند.

ممنوع:
- هیچ جاوااسکریپتی ننویس.
- هیچ عنصری را با opacity:0 یا visibility:hidden پنهان نکن.
- هیچ کتابخانهٔ خارجی وارد نکن.

خروجی: یک فایل HTML کامل با CSS داخلی.
بررسی: با جاوااسکریپت خاموش، صفحه باید کاملاً خوانا باشد.

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

لایهٔ ۳ — پرامپت حرکت

نقش: توسعه‌دهندهٔ فرانت‌اند متخصص GSAP و ScrollTrigger.

زمینه: این HTML از قبل ساخته شده و نهایی است:
[کد لایهٔ ۲ را اینجا بچسبان]

کار: فقط لایهٔ انیمیشن اسکرول را به‌صورت یک بلوک script بنویس.

مشخصات هر پرده:
- هیرو: تصویر با اسکراب تا مقیاس ۱٫۲ بزرگ شود؛ veil تیره‌تر شود؛
  عنوان کلمه‌به‌کلمه از پایین بالا بیاید.
- آمار: عددها یک‌بار هنگام ورود شمرده شوند.
- مسئله: کلمات با scrub تدریجی روشن شوند.
- پین: استیج پین شود، مسیر ۳۰۰٪، سه پنل یکی‌یکی بیایند و
  پنل قبلی به مقیاس ۰٫۸۵ و شفافیت ۰٫۴ برود.
- گواه: نوار افقی با اسکرول عمودی حرکت کند.

قیدها:
- scrub برابر ۱ باشد نه true.
- lenis و ScrollTrigger به هم معرفی شوند.
- gsap.matchMedia: زیر ۹۰۰ پیکسل فقط ظهور ساده،
  و در prefers-reduced-motion همهٔ تریگرها kill شوند.
- شکستن متن فارسی فقط به «کلمه» باشد نه حرف،
  و روی عنصر شکسته‌شده aria-label با متن کامل بگذار.
- invalidateOnRefresh روی محاسبات وابسته به عرض روشن باشد.
- بعد از load یک ScrollTrigger.refresh صدا زده شود.
- markers خاموش ولی با ثابت DEBUG بالای فایل قابل روشن‌کردن.

ممنوع:
- هیچ تغییری در HTML یا CSS نده.
- هیچ کتابخانهٔ اضافه‌ای وارد نکن.
- هیچ افکتی که در فهرست بالا نیست اضافه نکن.

خروجی: یک بلوک script کامل + جدول کوتاه پارامترهای
start و end هر تریگر.
بررسی: مطمئن شو هیچ انیمیشنی روی پاراگراف‌های بلند نیست.

لایهٔ ۴ — پرامپت صیقل

نقش: مهندس کارایی و دسترس‌پذیری وب.

زمینه: [کل کد نهایی]

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

بررسی کن:
- تصاویر: آیا loading و decoding درست تنظیم شده؟
  آیا ابعاد مشخص است تا چیدمان نپرد؟
- آیا will-change روی عناصر غیرضروری گذاشته شده؟
- آیا انیمیشنی هست که به‌جای transform و opacity،
  ویژگی‌های سنگین مثل width یا top را تغییر دهد؟
- آیا ترتیب عنوان‌ها (h1 تا h3) منطقی است؟
- آیا کنتراست متن روی تصویر کافی است؟
- آیا با کیبورد می‌شود همهٔ لینک‌ها و دکمه‌ها را پیمود؟
- آیا در حالت کاهش حرکت، محتوا کامل دیده می‌شود؟

خروجی: جدول سه‌ستونی «مشکل | شدت | اصلاح پیشنهادی»
و بعد فقط قطعه‌کدهای اصلاحی، نه کل فایل.
ممنوع: بازنویسی کامل فایل.

آن بند آخر مهم است. اگر نگویی، مدل کل فایل را بازنویسی می‌کند و تو باید دوباره همه‌چیز را از اول تست کنی.

پنج تکنیک که کیفیت خروجی را جهش می‌دهد

۱. تکنیک «مرجع منفی»

به‌جای توضیح آنچه می‌خواهی، گاهی گفتن آنچه نمی‌خواهی سریع‌تر است:

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

۲. تکنیک «یک پرده در هر پیام»

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

۳. تکنیک «توضیح قبل از کد»

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

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

۴. تکنیک «نسخهٔ آزمایشی مستقل»

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

۵. تکنیک «بازگشت به قید»

وقتی مدل قیدی را نادیده گرفت، به‌جای توضیح دوباره، فقط بنویس:

قید شمارهٔ ۳ رعایت نشده است. فقط همان بخش را اصلاح کن
و بقیهٔ کد را دست‌نخورده تحویل بده.

عیب‌یابی: وقتی انیمیشن کار نمی‌کند

به‌جای «کار نمی‌کند، درستش کن» — که تقریباً همیشه به بازنویسی بی‌فایده ختم می‌شود — این قالب را بفرست:

مشکل: بخش پین‌شده به‌جای اینکه در بالای صفحه قفل شود،
حدود ۲۰۰ پیکسل پایین‌تر قفل می‌شود.

آنچه انتظار دارم: استیج دقیقاً از بالای پنجره قفل شود.
آنچه اتفاق می‌افتد: با فاصله قفل می‌شود و بخش قبلی هنوز دیده می‌شود.
چه چیزی را امتحان کرده‌ام: مقدار start را از 'top top' به
'top 0' تغییر دادم، فرقی نکرد.
کد مرتبط: [فقط همان بلوک، نه کل فایل]

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

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

چک‌لیست قبل از فرستادن هر پرامپت

• آیا نقش مشخص است؟
• آیا زمینه (کدی که از قبل هست) پیوست شده؟
• آیا بیشتر از دو تصمیم باز مانده؟
• آیا بند «ممنوع‌ها» را نوشته‌ام؟
• آیا شکل خروجی را تعریف کرده‌ام؟
• آیا گفته‌ام چه چیزی را تغییر ندهد؟
• آیا از مدل خواسته‌ام قبل از تحویل خودش را بررسی کند؟

پرسش‌های پرتکرار

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

چرا خروجی هر بار فرق می‌کند؟
چون مدل‌ها ذاتاً تصادفی‌اند. راه‌حل، بستن تصمیم‌هاست: هرچه قیدها دقیق‌تر باشند، فضای تصادف کوچک‌تر می‌شود.

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

می‌شود کل صفحه را در یک پرامپت گرفت؟
برای صفحهٔ خیلی ساده بله. برای یک صفحهٔ واقعی با پین و اسکراب، نتیجه تقریباً همیشه ناامیدکننده است.

جمع‌بندی

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

در درس بعد این سیستم را روی یک پروژهٔ واقعی اجرا می‌کنیم و از پرامپت تا کد، یک صفحهٔ کامل می‌سازیم. مسیر کامل را در نقشهٔ راه طراحی سایت سینمایی ببین و در @MrChatGPT_IR همراه ما باش.