طراحی سایت با هوش مصنوعی؛ مقایسه ابزار، TCO و ریسک خروج

طراحی سایت با هوش مصنوعی دقیقاً چیست؟

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

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

از AI چه انتظاری داشته باشیم و چه چیزی را واگذار نکنیم؟

اگر ابزار وعده می‌دهد کل این مسئولیت‌ها را با یک دکمه حذف کند، ادعای آن را به Test case خرد کنید. سرعت تولید بدون زمان بازبینی، نرخ خطا و هزینهٔ اصلاح، معیار بهره‌وری نیست.

مقایسه سایت‌سازهای هوش مصنوعی؛ Snapshot مرداد ۱۴۰۵

قابلیت، محدودیت و قیمت ابزارها سریع تغییر می‌کند. جدول زیر Snapshot مستند در ۷ اوت ۲۰۲۶ است، نه رتبه‌بندی یا تضمین آینده. پیش از خرید، صفحهٔ رسمی، قرارداد، منطقهٔ سرویس و PoC خودتان را دوباره بررسی کنید.

چهار مدل تحویل: Hosted، CMS، AI-coded یا Hybrid

۱. سایت‌ساز میزبانی‌شده (Hosted AI Builder)

Editor، Hosting، CMS و قابلیت‌های کسب‌وکار در یک Vendor جمع می‌شوند. Launch سریع و بار عملیاتی اولیه کم است، اما Feature، Price، Availability، پرداخت و خروج به پلتفرم وابسته می‌شود. برای سایت کم‌ریسک با فرایند استاندارد مناسب است.

۲. CMS به‌همراه AI

AI در تولید Layout، محتوا یا مدیریت کمک می‌کند، ولی داده و چرخهٔ انتشار در CMS می‌ماند. آزادی Plugin و Hosting بیشتر است و در مقابل، Update، Backup، سازگاری و امنیت به تیم برمی‌گردد. برای کسب‌وکار محتوایی و سایتی که مالکیت Editorial مهم است، تعادل خوبی دارد.

۳. محصول AI-coded

Agent کد تولید می‌کند و مخزن، CI/CD و Runtime زیر کنترل تیم است. این مدل بیشترین انعطاف را دارد، اما بدون مهندس پاسخ‌گو خطرناک است: کدِ قابل اجرا الزاماً امن، قابل نگهداری یا دارای پوشش تست نیست. AI هزینهٔ تایپ را کم می‌کند؛ مسئولیت Software Engineering را حذف نمی‌کند.

۴. مدل ترکیبی (Hybrid)

صفحات بازاریابی روی CMS یا Builder و منطق حساس روی سرویس اختصاصی اجرا می‌شود؛ یا AI فقط برای Prototype و کار تکراری استفاده می‌شود. مرز Domain، احراز هویت، Analytics، Consent و Design system باید روشن باشد تا تجربه و داده تکه‌تکه نشوند.

اگر مسئلهٔ شما در اصل انتخاب Platform است، چارچوب کامل انتخاب No‑Code، Low‑Code و Custom بر اساس TCO و Exit را نیز استفاده کنید.

کدام مدل برای کدام سناریوی ایرانی مناسب‌تر است؟

محدودیت پرداخت بین‌المللی، تغییر نرخ ارز، دسترسی منطقه‌ای و نبود پشتیبانی فارسی را Risk ثبت کنید؛ راهکار غیررسمی برای دورزدن سیاست Vendor، معماری Production نیست. یک مسیر جایگزین قانونی و عملیاتی باید پیش از Launch وجود داشته باشد.

پیش از انتخاب ابزار، یک Brief قابل‌آزمون بسازید

به‌جای «یک سایت مدرن با AI می‌خواهیم»، هر نیاز را با مالک، اولویت و شاهد پذیرش ثبت کنید. نمونهٔ فشرده:

نیازها را Must/Should/Could دسته‌بندی کنید. قابلیت نمایشی که به Outcome وصل نیست، نباید وزن تصمیم را بالا ببرد.

Prompt خوب جای Brief و Acceptance Criteria را نمی‌گیرد

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

هدف: دریافت درخواست دموی معتبر از مدیر عملیات یک شرکت B2B
مخاطب: کاربر فارسی‌زبان موبایل؛ آشنا با مسئله، نه اصطلاحات فنی
اجزای ضروری: ارزش پیشنهادی، شواهد، فرایند، FAQ و فرم کوتاه
ممنوع: آمار بدون منبع، لوگوی مشتری فرضی، قیمت یا تضمین ساختگی
کیفیت: RTL واقعی، Keyboard، HTML قابل ایندکس، LCP budget و Event plan
خروجی: Wireframe و متن پیش‌نویس؛ انتشار فقط پس از Review انسانی

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

هفت Gate پیش از انتشار سایت ساخته‌شده با AI

Gate ۱: صحت محتوا و اعتماد

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

• ادعای بی‌منبع یا Testimonial ساختگی = Block انتشار
• تصویر تولیدیِ واقع‌نما در نقش شاهد پروژه = برچسب یا حذف
• نسخهٔ فارسی ترجمه‌شده = بازبینی موضوعی و زبانی، نه فقط Spell-check

Gate ۲: تجربه کاربری، RTL و دسترس‌پذیری

صفحه را با متن واقعی فارسی، عدد، واحد، ایمیل، کلمهٔ انگلیسی و محتوای طولانی امتحان کنید. فقط راست‌چین‌کردن Container پشتیبانی RTL نیست. ترتیب Tab، Breadcrumb، Icon جهت‌دار، اسلایدر، جدول، Validation و Screen reader را بسنجید.

W3C استفاده از WCAG ۲.۲ را توصیه می‌کند؛ چهار اصل Perceivable، Operable، Understandable و Robust را به Test case تبدیل کنید. راهنمای عملی طراحی تجربه کاربری نیز فرایند تحقیق تا آزمون را پوشش می‌دهد.

• کار با Keyboard و Focus آشکار
• Label واقعی برای Form و خطای قابل فهم
• Contrast، Zoom ۲۰۰% و Reflow بدون گم‌شدن عمل اصلی
• Alt معنادار؛ تصویر تزئینی با Alt خالی
• زبان صفحه fa و جهت rtl، با کنترل قطعه‌های LTR

Gate ۳: سئو و قابلیت Crawl/Render

پیش‌نمایش زیبا تضمین ایندکس نیست. Response و HTML رندرشده را جدا بررسی کنید. طبق راهنمای رسمی JavaScript SEO گوگل، Crawl، Render و Index سه مرحله‌اند و SSR یا Pre-rendering همچنان برای سرعت کاربر و Crawler مفید است.

برای عیب‌یابی Render و Cache، راهنمای سئو PWA و JavaScript را به‌کار ببرید.

Gate ۴: Performance واقعی، نه امتیاز دموی خالی

سایت آزمایشی با یک Hero و متن، نمایندهٔ صفحهٔ Production با Font فارسی، Tag manager، فرم، Chat، ویدئو و Consent نیست. Performance budget را روی Templateهای واقعی و دادهٔ میدانی تعریف کنید.

• LCP، INP و CLS در Mobile و شبکهٔ محدود
• حجم JS/CSS، Font، تصویر و درخواست Third-party
• Cache hit/miss، کاربر Login و مسیر خرید
• RUM بر اساس Template، Device و نسخهٔ Release

تعریف Budget، RUM و جلوگیری از Regression در راهنمای Core Web Vitals آمده است.

Gate ۵: امنیت کد و زنجیره تأمین

کد تولیدشده را مانند کد یک همکار تازه‌کار با سرعت بالا بررسی کنید. راهنمای OWASP برای کدنویسی امن با AI بر Review انسانی، محافظت از Secret و کنترل تغییرات و تست‌ها تأکید دارد.

• هیچ Secret، Token یا Credential در Prompt، Repository یا Client bundle نباشد
• Dependency و License با Lockfile، SCA و Policy بررسی شود
• Input validation و Output encoding در مرز Trust انجام شود
• AuthN با AuthZ اشتباه نشود؛ هر Object و Action مجوز مستقل بخواهد
• تغییر Test توسط AI نیز Review شود؛ حذف Guardrail برای سبزشدن Build ممنوع
• Branch protection، CI، Code review، Staging و Rollback فعال باشد

برای API، Webhook و Token از چک‌لیست امنیت API استفاده کنید.

Gate ۶: داده، حریم خصوصی و قرارداد

یک Data flow رسم کنید: چه داده‌ای از Browser به Builder، مدل AI، Analytics، CRM، Email و Backup می‌رود؟ برای هر جریان، هدف، مبنای مجاز، Retention، منطقهٔ پردازش، Subprocessor، نقش دسترسی و روش حذف را ثبت کنید.

گزینهٔ «از داده برای آموزش استفاده نمی‌شود» باید در Plan و Contract شما تأیید شود، نه از حافظه یا تبلیغ برداشت شود. روش Export و حذف داده پس از پایان قرارداد را نیز کتبی کنید.

Gate ۷: عملیات، مالکیت و بازیابی

Launch پایان کار نیست. مالک Domain و DNS، حساب Vendor، Billing، Repository، Analytics و Backup باید خود سازمان باشد یا دسترسی و انتقال آن قراردادی روشن داشته باشد. Runbook انتشار، مانیتورینگ، Incident، Restore و Patch را قبل از Go-live تمرین کنید.

فروشگاه و اتصال‌های ایرانی را End-to-end آزمایش کنید

وجود آیکون فروشگاه یا فرم پرداخت در Demo، اثبات Commerce نیست. روی محیط آزمایشی، زنجیرهٔ واقعی را با خطاهای واقعی بسنجید:

1. کالا با قیمت، تخفیف، موجودی و Variant ساخته شود.
2. سبد و Checkout روی موبایل، فارسی و آدرس طولانی کار کند.
3. درگاه موفق، ناموفق، لغو و Timeout به State درست برگردد.
4. Callback/Webhook امضاشده، Idempotent و قابل Retry باشد.
5. سفارش در CRM/ERP یا انبار ثبت و مغایرت قابل پیگیری شود.
6. Refund، لغو، گزارش مالی و Export سفارش امتحان شود.
7. اگر سرویس Third-party قطع شد، پیام، Queue و Recovery تعریف شده باشد.

اتصال از طریق Embed یا Automation کم‌کد ممکن است برای Prototype کافی باشد؛ برای تراکنش مالی باید Failure mode، امنیت و مسئول پشتیبانی مشخص باشد.

آزمون مالکیت و خروج؛ قبل از قرارداد، نه روز بحران

Vendor lock-in صفر وجود ندارد؛ حتی کد اختصاصی به Runtime، Library و دانش تیم وابسته است. هدف، شناخت و قیمت‌گذاری وابستگی و داشتن مسیر خروج متناسب با ریسک است.

شش لایه‌ای که باید جداگانه تحویل شوند

Exit drill در ۴۸ ساعت

1. یک Export کامل با حساب مالک سازمان بگیرید.
2. Checksum، تعداد رکورد و فایل و فهرست خطاها را ثبت کنید.
3. خروجی را روی مقصد جدا Restore یا Import کنید.
4. ۲۰ URL مهم، فرم، جست‌وجو، Login و یک تراکنش آزمایشی را اجرا کنید.
5. فاصلهٔ Feature و هزینهٔ بازسازی را در Exit backlog بنویسید.
6. RTO، RPO، مالک اقدام و تاریخ تمرین بعدی را تصویب کنید.

فایلی که دانلود می‌شود اما قابل Restore نیست، Backup نیست؛ Exportی که فقط متن را می‌دهد، خروج از سامانه نیست.

هزینه طراحی سایت با هوش مصنوعی؛ TCO را چگونه حساب کنیم؟

قیمت اشتراک فقط یک ردیف است. هزینهٔ کل مالکیت در افق مثلاً سه‌ساله را این‌گونه مدل کنید:

TCO = راه‌اندازی + اشتراک و ارز + محتوا و طراحی + اتصال + بازبینی انسانی + عملیات و پشتیبانی + امنیت و انطباق + Incident + خروج − صرفه‌جویی قابل‌اندازه‌گیری

مثال فرضی برای یک شرکت خدماتی ایرانی

فرض کنید تیم به ۳۰ صفحهٔ فارسی، فرم متصل به CRM، Blog، دو Landing ماهانه و SLA پاسخ نیاز دارد. برای حفظ قابلیت مقایسه، مبلغ‌ها را «واحد هزینه» می‌گیریم؛ هر سازمان می‌تواند آن را با میلیون تومان روز جایگزین کند.

این اعداد Benchmark بازار نیستند؛ نشان می‌دهند اشتراک ارزان می‌تواند با Integration و Exit خنثی شود و دو گزینه با قیمت شروع متفاوت به TCO مشابه برسند. سه سناریوی خوش‌بینانه، مبنا و بدبینانه بسازید و نرخ ارز، رشد ترافیک و زمان اصلاح AI را حساسیت‌سنجی کنید.

ROI و صرفه‌جویی خالص

صرفه‌جویی خالص = زمان ساخت مستقیم − (زمان Prompt + Review + Rework + Incident)

ROI = (منفعت افزایشی قابل‌انتساب − TCO) ÷ TCO

«تولید ۱۰ صفحه در یک ساعت» منفعت نیست اگر هشت صفحه حذف و دو صفحه دو روز بازبینی شوند. Baseline را از فرایند فعلی بگیرید و Cycle time، Defect escape، Conversion و Cost-to-serve را با Guardrailهایی مانند شکایت، خطای دسترس‌پذیری و Incident بسنجید.

ارزیابی Vendor؛ ۱۸ پرسش که Demo پاسخ نمی‌دهد

1. AI روی کدام Plan، Region و زبان فعال است و محدودیت Credit چیست؟
2. قیمت، سقف استفاده و اطلاع‌رسانی تغییر Plan چگونه است؟
3. دادهٔ Prompt و خروجی کجا، تا چه مدت و برای چه هدفی نگهداری می‌شود؟
4. آیا داده برای آموزش استفاده می‌شود و Opt-out قراردادی کجاست؟
5. Subprocessorها و روند اطلاع‌رسانی تغییر آن‌ها چیست؟
6. مالکیت و مجوز متن، تصویر، کد و Asset تولیدی چگونه تعریف شده است؟
7. چه تضمینی دربارهٔ حذف، Export و پایان قرارداد وجود دارد؟
8. Domain، DNS، Analytics، Pixel و حساب‌های ثالث به نام چه کسی‌اند؟
9. سطح Role، MFA، SSO، Audit log و Approval چیست؟
10. Backup چندوقت یک‌بار است و Restore توسط مشتری واقعاً آزمودنی است؟
11. SLA، Support channel، Incident notification و Service credit چیست؟
12. API، Rate limit، Webhook، Retry و Versioning چه شرایطی دارند؟
13. RTL، Font فارسی، Locale، URL فارسی/لاتین و جست‌وجوی فارسی چگونه کار می‌کنند؟
14. HTML اولیه، Canonical، Redirect، Sitemap و Schema قابل کنترل‌اند؟
15. کدام Content/Data/Code/Featureها صادر نمی‌شوند؟
16. آیا سایت بدون سرویس اصلی قابل اجراست یا فقط قابل مشاهده است؟
17. اگر دسترسی منطقه‌ای یا پرداخت مختل شد، Grace period و مسیر بازیابی چیست؟
18. مرجع Conflict در قرارداد چیست: صفحهٔ Marketing، Help center یا Order form؟

پاسخ «بله» کافی نیست؛ URL مستند، بند قرارداد، Screenshot تنظیم و نتیجهٔ Test را در Decision log پیوست کنید.

PoC چهار‌هفته‌ای برای انتخاب بهترین سایت‌ساز هوش مصنوعی

هفتهٔ ۱: Scope، Baseline و دادهٔ ساختگی

یک Template ساده، یک مسیر بحرانی و یک Integration انتخاب کنید. Baseline زمان و کیفیت فرایند فعلی را بگیرید. فقط دادهٔ Synthetic یا Anonymized وارد کنید و معیار Go/No-Go را پیشاپیش بنویسید.

هفتهٔ ۲: ساخت سناریوی واقعی

Home یا Landing، یک صفحهٔ محتوایی، فرم، Analytics و یک State خطا بسازید. متن و تصویر را با فرایند تأیید واقعی عبور دهید؛ Demo با Lorem ipsum امتیاز ندارد.

هفتهٔ ۳: تست مستقل و Exit drill

تیم دیگری Keyboard/RTL، SEO Render، Performance، Security و Failure mode را تست کند. Export بگیرید و بخشی را روی مقصد جدا Restore کنید. زمان Review و Rework دقیق ثبت شود.

هفتهٔ ۴: TCO، Risk و تصمیم

سناریوی سه‌ساله، Risk register، Contract gaps و Exit backlog را تکمیل کنید. نتیجه می‌تواند Go، Go with conditions، Extend PoC یا No-Go باشد.

امتیاز ۱ تا ۵ را در وزن ضرب کنید، اما Kill criterion را با میانگین پنهان نکنید. محصولی با Design عالی و خروج‌ناپذیری دادهٔ سفارش، برنده نیست.

برنامهٔ ۳۰/۶۰/۹۰روزه پس از انتخاب

بودجهٔ امنیت را بر اساس ریسک و Roadmap ببندید؛ راهنمای بودجه امنیت سایت برای تبدیل کنترل‌ها به برنامهٔ مالی کاربردی است.

چک‌لیست نهایی خرید و تحویل

• Outcome، مخاطب و مسیر بحرانی تعریف شده است.
• AI Builder، CMS، Coding Agent و Hosting با هم اشتباه نشده‌اند.
• قابلیت‌ها با مستند رسمی همان Plan و تاریخ ثبت شده‌اند.
• RTL، متن واقعی فارسی، Mobile، Keyboard و WCAG آزموده شده‌اند.
• Title، Canonical، Sitemap، Redirect و HTML قابل Crawl کنترل شده‌اند.
• Core Web Vitals با محتوای واقعی و Third-partyها اندازه‌گیری شده است.
• کد و Dependency تولیدشده Review و تست امنیتی شده‌اند.
• Secret و دادهٔ حساس وارد Prompt عمومی نشده‌اند.
• Data flow، Retention، Subprocessor و حذف قراردادی روشن است.
• درگاه، Webhook، CRM و Failure state به‌صورت End-to-end تست شده‌اند.
• مالکیت Domain، Account، Content، Media، Repository و Analytics روشن است.
• Backup واقعاً Restore شده و RTO/RPO ثبت شده است.
• Export هر لایه و قابلیت‌های ازدست‌رفته در خروج مستند شده‌اند.
• TCO سه‌ساله و سناریوی بدبینانه تأیید مالی شده است.
• زمان Review و Rework در صرفه‌جویی AI حساب شده است.
• Kill criterion، Rollback و مسئول Incident پیش از Launch مشخص‌اند.