پرش به محتوا
۱۳ ژوئیه ۲۰۲۶ · کتاب راهنما

دفترچه‌راهنمای BuildMidas: نقشه‌ی پلتفرم

این مقاله محصول را در زمان انتشار توصیف می‌کند. برای قابلیت‌های فعلی به AI Builder و Agent Teams مراجعه کنید.

دفترچه‌راهنمای BuildMidas: نقشه‌ی پلتفرم

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

پرامپت

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

مرحله‌ی برنامه که مردم نادیده می‌گیرند

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

ساخته در نهایت کجا قرار می‌گیرد

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

منتشرشده، یا چیزی سنگین‌تر

حالا نوبت پرسش توزیع است. سه گزینه‌ی واقعی، نه یک گزینه با سه نام. منتشرشده یک زیردامنه‌ی رایگان می‌دهد، در چند ثانیه فعال می‌شود، بدون هیچ تنظیماتی — انتخاب درست وقتی مشتری هنوز در حال بررسی است و ممکن است درخواست طراحی مجدد بدهد. مدیریت دامنه برای زمانی است که دامنه‌ی خود مشتری آماده‌ی اتصال به ساخته است، و این مرحله یک نقش دوگانه دارد: اتصال دامنه در اینجا فقط تغییر آدرس نیست، بلکه همان چیزی است که باعث می‌شود صفحات تحلیلی پایین‌تر در نوار کناری چیزی برای اتصال داشته باشند. استقرار، زیر بخش تنظیمات، مسیر SFTP برای زمانی است که مشتری اصرار دارد ساخته روی زیرساختی که خودش کنترل می‌کند اجرا شود — تنظیمات بیشتری لازم دارد، و فریلنسر دیگر هیچ مسئولیتی در قبال زمان فعالیت (uptime) ندارد، که معامله‌ی واقعی‌ای است که ارزش دارد صریحاً درباره‌اش تصمیم گرفت تا اینکه به‌طور تصادفی کشف شود.

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

انحراف به فروشگاه اپلیکیشن

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

صفحه‌ی خالی که هیچ‌کس درباره‌اش هشدار نداد

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

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

بریفی که بی‌آنکه بخواهید ظاهر می‌شود

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

تنظیماتی که باید از روز اول انجام می‌شد

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

صفحهچه چیزی معلوم شد پشتش قفل بوده
حساب‌های Googleعملکرد جست‌وجو، Google Analytics، و داده‌های زمینه‌ای ایجنت‌ها — یک اتصال، سه سطح نمایش
استقرارمقصدهای SFTP، فقط برای مسیر سرور تحت کنترل کارفرما لازم
رسانه هوش مصنوعیپیش‌فرض‌های تولید تصویر که در ساخت‌ها استفاده می‌شود
طرح‌ها و اعتبارسقف مصرف، بسته‌های اعتبار، رسیدها

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

دو چیزی که از همان اول آن‌جا بودند

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

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

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

راهنما
اشتراک‌گذاریXLinkedInFacebookRedditQuoraواتساپتلگرامایمیل
← همه مطالب