ساخت سایت شخصی با هوش مصنوعی؛ از معرفی تا دریافت پروژه

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

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

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

سایت شخصی، پورتفولیو یا سایت رزومه؛ کدام را لازم داری؟

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

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

قبل از پرامپت، مواد اولیهٔ معرفی‌ات را جمع کن

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

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

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

از معرفی تا نمونه‌کار؛ چهار صفحه را به یک مسیر وصل کن

برای توضیح این مسیر، چهار HTML ارسالی را کنار هم گذاشتیم: صفحهٔ معرفی با نام «طاها رضایی»، فهرست تمرین‌ها، جزئیات یک مطالعهٔ موردی و فرم شرح پروژه. آن‌ها را در یک قاب روشن شبیه محیط کُندا نمایش می‌دهیم تا ارتباط هر درخواست با صفحهٔ مربوط روشن باشد.

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

صفحهٔ اول باید به سؤال «برای چه کاری سراغت بیایم؟» جواب بدهد

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

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

فهرست نمونه‌کار باید انتخاب را آسان کند

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

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

صفحهٔ جزئیات باید تصمیم را توضیح بدهد، نه فقط خروجی را

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

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

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

چه پرامپتی برای ساخت سایت شخصی بنویسم؟

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

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

فرم تماس واقعاً کجا می‌رود؟

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

فرم HTML ارسالی، یک دموی مستقل است. روش ارتباط، موضوع، شرح پروژه و بازهٔ زمانی را می‌گیرد، ولی اطلاعات را فقط در localStorage همان مرورگر نگه می‌دارد. در ۷ آبان ۱۴۰۵، با نشانی و متن ساختگی آن را پر کردیم؛ پس از بازخوانی، همان ورودی‌ها برگشتند. این مشاهده فقط بازخوانی مرورگری را نشان می‌دهد؛ درخواست به صندوق صاحب سایت یا ایمیل نرفته است.

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

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

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

روی موبایل و پیش از انتشار چه چیزهایی را بررسی کنم؟

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

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

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

نسخهٔ اول را کوچک منتشر کن و از سؤال‌ها یاد بگیر

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

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

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

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