# ساخت سایت ثبت‌نام رویداد با هوش مصنوعی؛ ظرفیت تا فهرست شرکت‌کنندگان

> یک رویداد و یک ظرفیت تعریف کن؛ ثبت و بررسی ظرفیت در سرور هماهنگ باشند. تکرار همان درخواست نباید صندلی تازه مصرف کند و فهرست تماس شرکت‌کنندگان باید دسترسی مشخص داشته باشد. هم‌زمانی را روی خروجی واقعی دوباره بررسی کن.

- Published: 2026-10-30T13:13:52.239Z
- Updated: 2026-10-30T13:13:52.239Z
- Author: نیکان نورافکن

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

**برای ساخت سایت ثبت‌نام رویداد با هوش مصنوعی، یک مسیر کامل تعریف کن: معرفی روشن رویداد، فرم کوتاه، ثبت در سرور، جلوگیری از تکرار، کنترل ظرفیت و فهرست خصوصی برگزارکننده. پیش از معرفی سامانه به‌عنوان آماده، ثبت‌نام‌های هم‌زمان را هم بررسی کن؛ عدد ظرفیت روی صفحه به‌تنهایی کافی نیست.** این راهنما مسیر یک کارگاه رایگانِ سه‌نفره را با دادهٔ ساختگی دنبال می‌کند.

> چهار تصویر مقاله از HTMLهای ارسالی، داخل قاب روشن نمایشی کُندا تهیه شده‌اند؛ چیدمان و سبک طرح‌ها حفظ شده‌اند و اطلاعات تماس با مثال‌های ساختگی جایگزین شده است. نام دانشگاه، مدرک، پرداخت، پیامک، آمار و تضمین‌های نوشته‌شده داخل طرح‌ها تأیید نشده‌اند و بیانگر امکانات آمادهٔ کُندا یا یک رویداد واقعی نیستند. آزمون‌های این مقاله جداگانه، روی سرور مستقل محلی در ۸ آبان ۱۴۰۵ انجام شده‌اند؛ اجرای موتور کُندا نیستند.

## اول مشخص کن ثبت‌نام در این رویداد چه معنایی دارد

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

| تصمیم | قاعدهٔ نمونه |
| --- | --- |
| ظرفیت | ۳ صندلی |
| اطلاعات لازم | نام نمایشی و ایمیل نمونه |
| ثبت تکراری | همان ایمیل در همان رویداد دوباره صندلی نگیرد |
| ارسال دوبارهٔ همان درخواست | همان ثبت قبلی پیدا شود؛ رکورد تازه ساخته نشود |
| ظرفیت پر | درخواست تازه رد شود؛ شمار ثبت‌نام‌ها تغییر نکند |
| فهرست شرکت‌کنندگان | فقط برای برگزارکنندهٔ مجاز |
| خارج از نسخهٔ اول | پرداخت، رزرو موقت، لیست انتظار، پیامک، مدرک و ثبت‌نام گروهی |

اگر بلیت حضوری و آنلاین یا سهمیهٔ VIP داری، باید روشن کنی کدام ظرفیت را مصرف می‌کنند. ثبت گروهی هم با چند ثبت مستقل یک‌نفره یک مسئله نیست. آن‌ها را به نسخهٔ بعد بسپار؛ برای محدود کردن همین شروع، [راهنمای ساخت MVP با هوش مصنوعی](https://kondaai.com/blog/build-mvp-with-ai) کمک می‌کند.

## صفحهٔ معرفی قبل از فرم چه بگوید؟

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

<figure><img src="/blog/images/build-event-registration-website-with-ai/event-supplied-v1.webp" width="1920" height="1234" loading="lazy" alt="صفحهٔ معرفی رویداد در HTML اول ارسالی، داخل قاب روشن نمایشی کُندا"><figcaption>طرح اول ارسالی برای معرفی رویداد؛ تاریخ، دانشگاه، مدرس، گواهی و اعداد داخل طرح صرفاً محتوای نمونه‌اند و تأیید نشده‌اند.</figcaption></figure>

اقدام اصلی را مشخص نگه دار: «ثبت‌نام در کارگاه». اگر پذیرش بسته است، همان‌جا توضیح بده و مخاطب را به یک فرم ظاهراً باز نفرست. در صفحهٔ عمومی می‌توان شمار صندلی‌های باقی‌مانده را نشان داد، اما این عدد ممکن است تا رسیدن درخواست بعدی تغییر کند؛ تصمیم نهایی باید هنگام ثبت در سرور گرفته شود.

اگر هنوز در مرحلهٔ چیدن صفحات هستی، [راهنمای ساخت سایت با هوش مصنوعی](https://kondaai.com/blog/build-website-with-ai) مسیر معرفی، اقدام اصلی و بررسی فرم را توضیح می‌دهد.

## پرامپت ساخت سایت رویداد را چطور بنویسیم؟

به‌جای «یک سامانهٔ جامع رزرو بساز»، قواعد همین مسیر را بنویس. ابزار سازنده باید بداند چه چیزی پذیرفته شود و چه چیزی رد شود؛ یک ظاهر شبیه سایت فروش بلیت، جواب این سؤال‌ها نیست.

```text
یک سایت فارسی و راست‌به‌چپ برای کارگاه رایگان نمونه با ظرفیت ۳ نفر بساز. معرفی، فرم نام نمایشی و ایمیل، رسید ثبت و فهرست خصوصی برگزارکننده داشته باشد. هر ایمیل در همان رویداد فقط یک ثبت پذیرفته‌شده داشته باشد؛ این قاعده تأیید هویت نیست. هر ارسال شناسهٔ یکتا داشته باشد؛ تکرار همان درخواست رکورد تازه نسازد. ظرفیت در سرور و هنگام ذخیره بررسی شود؛ در ارسال هم‌زمان سقف رد نشود. حالت خالی، خطای ورودی، ثبت تکراری و ظرفیت پر روشن باشند. ذخیره و بازخوانی پس از رفرش را بررسی کن. از دادهٔ ساختگی استفاده کن. پرداخت، پیامک، کدملی و لیست انتظار نداریم؛ بخش متصل‌نشده را دمو معرفی کن.
```

نام، زمان و ظرفیت واقعی خودت را پیش از ساخت جایگزین کن. می‌توانی این درخواست را در [داشبورد کُندا](https://kondaai.com/dashboard) بازبینی کنی یا [قالب‌های آماده](https://kondaai.com/templates) را ببینی. برای آشنایی با مسیر درخواست و اصلاح، [آموزش وایب کدینگ](https://kondaai.com/blog/vibe-coding-tutorial) هم در دسترس است.

## فرم کوتاه باشد؛ موفقیت بعد از ذخیره نمایش داده شود

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

<figure><img src="/blog/images/build-event-registration-website-with-ai/registration-supplied-v1.webp" width="1920" height="1234" loading="lazy" alt="فرم ثبت‌نام در HTML دوم ارسالی، با اطلاعات تماس نمونه، داخل قاب نمایشی کُندا"><figcaption>طرح دوم ارسالی، نمونهٔ رابط فرم است. تمرین این مقاله از آن کوچک‌تر است: کدملی، بررسی هویت، پرداخت و پیامک در محدودهٔ آزمون نیستند.</figcaption></figure>

پس از ارسال معتبر و تأیید ذخیره در سرور، یک شناسهٔ پیگیری نشان بده. پیام باید روشن کند چه اتفاقی افتاده است: «ثبت‌نامت ثبت شد» با «ایمیل تأیید ارسال شد» فرق دارد. در نمونهٔ محلی، ثبت ذخیره می‌شود و رسید قابل خواندن است؛ هیچ ایمیل یا پیامکی ارسال نمی‌شود و اعتبار ایمیل هم از طریق دریافت پیام تأیید نشده است.

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

## ثبت تکراری دو حالت متفاوت دارد

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

حالت دوم این است که فرد دوباره فرم را با یک شناسهٔ تازه پر کند. در این نمونه، یکتایی **ایمیل در همان رویداد** از مصرف صندلی دوم جلوگیری می‌کند. ابتدا فاصلهٔ ابتدا و انتهای ایمیل حذف و حروف لاتین همسان می‌شوند؛ برای نمونه، ورود دوبارهٔ همان آدرس با حروف بزرگ باعث ثبت تازه نشد. همان ایمیل در رویداد دیگری مجاز بود.

این یک قاعدهٔ ثبت است، نه تضمین «هر انسان فقط یک بار». کسی با ایمیل متفاوت از همین قاعده عبور می‌کند و ایمیلِ صرفاً واردشده هم هویت صاحبش را تأیید نمی‌کند. اگر نیاز به حساب تأییدشده یا سهمیهٔ واقعی افراد داری، آن را جداگانه طراحی و بررسی کن. نمایش تیک سبز کنار فیلد کدملی در یک طرح نیز به معنی اتصال به مرجع بررسی هویت نیست.

برای جلوگیری از رکوردهای تکراری، قاعده باید در ذخیره‌سازی هم وجود داشته باشد. در تمرین از محدودیت یکتایی استفاده شد؛ [مرجع قواعد جدول SQLite](https://www.sqlite.org/lang_createtable.html) توضیح فنی این بخش را دارد.

## وقتی ظرفیت پر شد چه چیزی ببینیم؟

در مسیر اصلی، سه صندلی داریم. هر ثبت پذیرفته‌شده شمار را یک واحد افزایش می‌دهد؛ خطا یا تلاش تکراری نباید آن را تغییر بدهد.

| اتفاق | ثبت‌شده | باقی‌مانده | نتیجهٔ مشاهده‌شده در نمونه |
| --- | --- | --- | --- |
| شروع | ۰ | ۳ | پذیرش باز |
| ثبت الف | ۱ | ۲ | رسید صادر شد |
| تکرار همان درخواست الف | ۱ | ۲ | همان ثبت، بدون صندلی اضافه |
| همان ایمیل با درخواست تازه | ۱ | ۲ | ثبت تازه رد شد |
| ثبت ب | ۲ | ۱ | یک صندلی باقی ماند |
| ثبت پ | ۳ | ۰ | ظرفیت تکمیل شد |
| تلاش ت برای ثبت تازه | ۳ | ۰ | رد؛ بدون رکورد اضافه |

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

پذیرش بسته با ظرفیت پر یکی نیست. در یک آزمون جدا، رویدادی با صندلی خالی ولی پذیرش بسته، ثبت تازه را رد کرد. مهلت ثبت‌نام، ظرفیت و وضعیت انتشار را در خروجی واقعی جدا بررسی کن. [فایل مسیر ظرفیت نمونه](/blog/images/build-event-registration-website-with-ai/sample-capacity.csv) برای تکرار این بررسی آماده است.

## آزمون هم‌زمانی: دو نفر برای آخرین صندلی

اگر دو درخواست هم‌زمان، هر دو «یک صندلی باقی مانده» را بخوانند، ممکن است هر دو پیام موفقیت بگیرند؛ مگر اینکه بررسی ظرفیت و ثبت با هم هماهنگ باشند. غیرفعال کردن دکمه در یک مرورگر، درخواست مرورگر دیگر را متوقف نمی‌کند.

در آزمایش مستقل محلی، این حالت‌ها را بررسی کردیم:

| آزمایش | انتظار | مشاهده |
| --- | --- | --- |
| دو ایمیل متفاوت، یک صندلی | فقط یک پذیرش | یک پذیرش، یک رد؛ شمار نهایی ۱ |
| ده شروع هم‌زمان، سه صندلی | حداکثر سه پذیرش | سه پذیرش، هفت رد؛ باقی‌مانده ۰ |
| یک ایمیل، دو شناسهٔ تازه به‌صورت هم‌زمان | یک ثبت | یک پذیرش، یک رد |
| یک درخواست با همان شناسه، هم‌زمان دوبار | یک ثبت و یک رسید | یک ثبت؛ پاسخ تکرار همان رسید را داد |

برای آزمایش ده درخواست، شروع کلاینت‌ها با یک مانع مشترک هماهنگ شد؛ شمار ذخیره‌شده نیز بعد از پاسخ‌ها دوباره خوانده شد. در نمونه، بررسی و نوشتن در یک تراکنش محلی انجام شدند. [مستندات تراکنش SQLite](https://www.sqlite.org/lang_transaction.html) مرجع فنی این سازوکار است.

<figure><img src="/blog/images/build-event-registration-website-with-ai/capacity-supplied-v1.webp" width="1920" height="1234" loading="lazy" alt="نمای ظرفیت و سناریوهای آزمون در HTML چهارم ارسالی، داخل قاب روشن نمایشی کُندا"><figcaption>طرح چهارم ارسالی برای نمایش داشبورد ظرفیت است. ادعای تضمین، Redis، پرداخت و نتایج شبیه‌ساز داخل طرح، گزارش آزمون محلی این مقاله نیستند.</figcaption></figure>

این نتیجه، آزمون محدود روی یک رایانه و پایگاه دادهٔ محلی است؛ آمادگی انتشار یک خروجی تازه، کارکرد زیر بار واقعی یا هماهنگی چند سرور را تأیید نمی‌کند. اگر نسخهٔ واقعی از پایگاه داده یا مسیر ثبت دیگری استفاده می‌کند، همین رقابت را روی همان نسخه دوباره اجرا کن. عبارت «آمادهٔ ثبت‌نام» را فقط از روی ظاهر صفحه یا نتیجهٔ شبیه‌ساز HTML ننویس.

## فهرست شرکت‌کنندگان برای چه کسی است؟

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

<figure><img src="/blog/images/build-event-registration-website-with-ai/attendees-supplied-v1.webp" width="1920" height="1234" loading="lazy" alt="فهرست شرکت‌کنندگان در HTML سوم ارسالی، با آدرس‌های ساختگی example.test در قاب روشن کُندا"><figcaption>طرح سوم ارسالی، نمونهٔ نمای فهرست است؛ اطلاعات تماس برای تصویر ساختگی شده‌اند. در مسیر پیشنهادی مقاله، این نما برای برگزارکنندهٔ مجاز است، نه فهرست عمومی افراد.</figcaption></figure>

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

مجوز را در سمت سرور بررسی کن، نه فقط با پنهان کردن لینک پنل. [راهنمای مجوزدهی OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) بر بررسی دسترسی در هر درخواست تأکید دارد؛ [چک‌لیست دسترسی وب‌اپ](https://kondaai.com/blog/web-app-access-control-checklist) هم برای بررسی خروجی خودت مفید است. اگر بعداً خروجی CSV اضافه می‌کنی، همان فایل نیز باید دسترسی مشخص داشته باشد؛ خروجی فهرست در این نمونه پیاده نشده است.

## بعد از رفرش، ثبت‌نام قبلی گم نشود

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

این بررسی مربوط به دادهٔ ذخیره‌شده است؛ بازیابی فرم نیمه‌کاره یا پیدا کردن رسید توسط کاربری که صفحه را پیش از دریافت پاسخ بسته، در این تمرین پیاده نشده است. در محصول واقعی، این مسیر را جدا بررسی کن و قبل از ساخت یک درخواست تازه، وضعیت ارسال قبلی را پیدا کن. ذخیره شدن در حافظهٔ صفحه یا تنها یک مرورگر را هم با ثبت‌نام مشترکِ سروری یکی ندان؛ [راهنمای پیش‌نمایش و محصول آماده](https://kondaai.com/blog/ai-app-preview-vs-production) این مرز را توضیح می‌دهد.

## قبل از انتشار چه چیزهایی باید روشن باشد؟

**۲۶ بررسی API محلی و یک بازخوانی در مرورگر** انجام شد. نتیجه‌های بالا مربوط به همین نمونه‌اند؛ آن‌ها را به خروجی تازهٔ خودت تعمیم نده. [برگهٔ معیار پذیرش](/blog/images/build-event-registration-website-with-ai/acceptance-checklist.csv) را برای مسیر واقعی خودت با انتظار و مشاهده پر کن.

در این تمرین، پرداخت، تأیید ایمیل، پیامک، لغو و آزادسازی صندلی، لیست انتظار، ثبت گروهی، کنترل سوءاستفاده و پشتیبان‌گیری بررسی نشده‌اند. اگر رویدادت پولی است، وضعیت پرداخت و زمان رزرو صندلی باید طراحی و آزمون جداگانه داشته باشند؛ رسید ثبت این نمونه را رسید پرداخت معرفی نکن.

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

## قدم بعدی: یک کارگاه، یک ظرفیت و یک معیار پذیرش

ابتدا اطلاعات واقعی رویداد را آماده کن. پرامپت مقاله را برای همان کارگاه در [داشبورد کُندا](https://kondaai.com/dashboard) بازبینی کن یا [قالب‌های آماده](https://kondaai.com/templates) را ببین. ساخت را پس از بررسی درخواست و شرایط حساب شروع کن؛ برای آزمون اولیه از اطلاعات ساختگی استفاده کن.

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

## پرسش‌های متداول

### برای ساخت سایت ثبت‌نام رویداد با هوش مصنوعی از کجا شروع کنیم؟

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

### آیا دوبار زدن دکمه و دوباره پر کردن فرم یک خطا هستند؟

خیر. برای تلاش مجدد همان درخواست، شناسهٔ ثابت لازم است؛ برای فرم تازه با همان ایمیل در همان رویداد، قاعدهٔ یکتایی جداگانه لازم است. هیچ‌کدام به‌تنهایی تأیید هویت فرد نیستند.

### در آزمایش هم‌زمانی چند نفر پذیرفته شدند؟

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

### وقتی ظرفیت کارگاه پر شد، ثبت‌نام تازه چه شود؟

سرور باید درخواست تازه را بدون ساخت رکورد اضافه رد کند و رابط پیام روشنی نشان بدهد. اگر لیست انتظار متصل نیست، نباید ثبت در صف انتظار را وعده بدهد.

### آیا فهرست شرکت‌کنندگان باید عمومی باشد؟

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

### آیا نمونه به پرداخت، پیامک یا تأیید هویت متصل است؟

خیر. این تمرین یک کارگاه رایگان با دادهٔ ساختگی است و فقط مسیر ثبت، تکرار، ظرفیت و دسترسی فهرست بررسی شده است. امکانات نوشته‌شده داخل طرح‌های HTML، قابلیت‌های تأییدشدهٔ نمونه نیستند.



## منابع

- [SQLite؛ تراکنش‌ها و هماهنگی بررسی ظرفیت با ثبت](https://www.sqlite.org/lang_transaction.html)
- [SQLite؛ محدودیت‌های یکتایی در جدول](https://www.sqlite.org/lang_createtable.html)
- [OWASP؛ بررسی مجوز دسترسی در هر درخواست](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)