راه‌اندازی سیستم کاری OpenAI در ۱۰ مرحله؛ از Dots تا Codex

بعد از DevDay امسال، OpenAI مجموعه‌ای از ابزارها را عرضه کرد که در کنار هم یک «سیستم کاری» کامل می‌سازند. این مقاله، بازنویسی آموزشی فارسی کد کلاد است که مسیر راه‌اندازی آن را در ده مرحله نشان می‌دهد؛ از ساخت Dot تا ساخت ایجنت داخل محصول خودتان.

۱. ساخت Dot و دادن یک «مسئولیت واقعی» به آن

نقطه‌ی شروع، Dot است؛ ایجنتی شخصی با کامپیوتر ابری اختصاصی که کارهای پس‌زمینه را انجام می‌دهد. در دسکتاپ وارد بخش Dots می‌شوید، Dot خودتان را می‌سازید و اتصال‌ها را همان لحظه یا بعداً اضافه می‌کنید. طبق این آموزش، دسترسی شخصی به Dots در زمان انتشار برای برخی پلن‌های Pro در حال عرضه بوده، پس پیش از خرید پلن، دسترسی فعلی حساب خودتان را بررسی کنید. برای آشنایی با خود Dots، مقاله‌ی دات‌ز OpenAI را هم ببینید.

مهم‌ترین نکته این است که به Dot دستور مبهمی مثل «کمکم کن بهره‌ورتر باشم» ندهید. به‌جای آن یک مسئولیت مشخص تعریف کنید؛ مثلاً: هماهنگی لانچ محصول X در تاریخ Y با استفاده از بریف، چک‌لیست و گفت‌وگوهای مشخص، پیدا کردن بلاکرها و مالک‌های گمشده، تهیه‌ی اولین گزارش وضعیت همراه با لینک منابع، اعلام کمبود دسترسی، و گرفتن تأیید قبل از ارسال هر پیام یا تغییر فایل مشترک. اولین گزارش را با دقت بخوانید: تاریخ لانچ درست فهمیده شده؟ منابع واقعاً باز می‌شوند؟ پیشنهادها به‌عنوان تصمیم قطعی برداشت نشده‌اند؟ اول همین سوءبرداشت‌ها را اصلاح کنید، بعد کار تکرارشونده بدهید.

۲. اتصال اپ‌ها و کامپیوتری که Dot نیاز دارد

برای پیام‌رسان‌ها وارد پروفایل Dot شوید و از بخش Add اتصال موردنیاز را اضافه کنید؛ نمونه‌ی آموزش، Slack و Microsoft Teams است. بعد اسناد و ابزارهای ارتباطی موردنیاز را وصل کنید و از خود Dot بخواهید دقیقاً بگوید به چه چیزی دسترسی دارد و به چه چیزی ندارد. یک درخواست نمونه: بریف و چک‌لیست لانچ را پیدا کن، لینک و آخرین تغییرات را بده و هر منبعی که نمی‌توانی بخوانی مشخص کن.

برای سایت‌هایی که ورود می‌خواهند باید از Cloud Computer خود Dot استفاده کنید. مرورگر Dot نشست جداگانه دارد؛ یعنی لاگین بودن شما روی لپ‌تاپ شخصی به معنی لاگین بودن Dot نیست. ورود و تأیید هویت را داخل محیط خود Dot انجام دهید و بعد کنترل را به او برگردانید. یادتان باشد کارهای ابری حتی با بسته‌بودن لپ‌تاپ ادامه پیدا می‌کنند، اما کارهایی که روی کامپیوتر شخصی اجرا می‌شوند به روشن‌بودن سیستم و اپ نیاز دارند. همچنین صرف وصل‌کردن Slack به Dot باعث نمی‌شود او خودش یک کانال را پایش کند؛ این رفتار را جداگانه تعریف کنید.

۳. به‌جای Task، «Outcome» بدهید و Context را نگه دارید

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

بعد از اجرا، از بخش Activity کارهای واگذارشده و خروجی‌هایشان را ببینید. Dot می‌تواند از طریق Memory و Notes زمینه را نگه دارد، اما نباید فرض کنید همه‌ی جزئیات همه‌ی گفت‌وگوها برای همیشه ذخیره می‌ماند؛ تصمیم‌های مهم پروژه را در یک سند قابل دسترس ثبت کنید و در کارهای بعدی به آن ارجاع بدهید. برای نوشتن دستورهای دقیق‌تر هم راهنمای ساده‌ی نوشتن پرامپت کمک می‌کند.

۴. کار را تکرارشونده کنید، اما کنترل را نگه دارید

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

پیشنهاد نویسنده برای قانون اولیه این است: تحقیق کن و پیش‌نویس آماده کن، اما قبل از ارسال پیام، ویرایش فایل مشترک، خرج‌کردن پول یا انتشار چیزی از من اجازه بگیر. برای توقف کار هم سه جا وجود دارد: Pause، Activity و Scheduled. متوقف‌کردن ایجنت اصلی لزوماً تسک‌های واگذارشده یا زمان‌بندی‌ها را لغو نمی‌کند و هر سه را باید چک کنید.

۵. استفاده از GPT-6.1 Sol

در مرحله‌ی پنجم نوبت انتخاب مدل است. GPT-6.1 Sol یکی از مدل‌های معرفی‌شده برای Work و Codex است و توصیه این است که با تنظیم Reasoning پیش‌فرض شروع کنید و تسکی بدهید که نتیجه‌اش قابل ارزیابی باشد؛ مثلاً: این بریف لانچ و لندینگ‌پیج فعلی را بخوان، ادعاهای بدون مدرک، مبهم یا ناسازگار را پیدا کن، جایگزین دقیق پیشنهاد بده و بگو هر تغییر به چه مدرکی نیاز دارد. شناسه‌ی مدل در API، طبق آموزش، gpt-6.1-sol است. برای شناخت بهتر این مدل، مقاله‌ی رونمایی GPT-6.1 Sol را ببینید.

نکته‌ی مهم دیگر تفاوت «مدل» و «سرعت» است. حالت Astra Ultrafast توکن‌ها را خیلی سریع‌تر تولید می‌کند، اما این لزوماً به معنای هشت‌برابر سریع‌تر تمام‌شدن کل کار نیست، چون مرورگر، فراخوانی ابزار و استدلال هم زمان می‌برند.

۶. آوردن کارها داخل ChatGPT Space

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

برای فضای تیمی، از مسیر All، سپس New و بعد Space یک فضا بسازید، نام بگذارید و همکار اضافه کنید. آموزش به قابلیت‌هایی مثل اسلایدهای مشارکتی، تسک‌های تیمی، اتصال‌های تیمی و یکپارچگی با Slack و Teams اشاره می‌کند. برای جلسه‌ها هم افزونه‌ی Meetings مطرح شده؛ پیش از ضبط باید رضایت افراد گرفته شود و خلاصه و اقدام‌های جلسه پیش از تبدیل‌شدن به تعهد بازبینی شوند. توضیح کامل این ابزار را در مقاله‌ی ChatGPT Space بخوانید.

۷. ساخت، بازبینی و انتشار با Codex

مرحله‌ی بعد وارد کدنویسی می‌شود. نمونه‌ی مقاله این است که گزارش لانچ متوجه شده صفحه‌ی ثبت‌نام روی موبایل خراب است. اول Codex Cloud را تنظیم کنید: در Work وارد Cloud شوید، یک Environment بسازید، مخزن گیت‌هاب را وصل کنید، بگذارید راه‌اندازی پروژه و نصب وابستگی‌ها بررسی شود، گزارش راه‌اندازی را بخوانید، نقص‌ها را رفع کنید و Environment را منتشر کنید. بعد تسک را دقیق بدهید: مشکل ثبت‌نام را بازتولید کن، علت را پیدا کن، کوچک‌ترین اصلاح مناسب را انجام بده، چک‌های مرتبط را اجرا کن و تفاوت‌ها، نتیجه‌ی تست‌ها و عدم‌قطعیت‌های باقی‌مانده را برگردان.

برای CLI دستور codex –model gpt-6.1-sol را اجرا کنید؛ نسخه‌ی جدید کنترل صوتی و دستور /agents برای دیدن کارهای واگذارشده را هم دارد. برای بازبینی کد، یک Pull Request انتخاب کنید، Review را اجرا کنید، یافته‌ها را همراه با تغییرات و شواهد تست بررسی کنید و بعد Merge کنید. درباره‌ی امنیت هم توصیه شده وصله‌ی پیشنهادی ایجنت را قبل از ساخت PR حتماً بررسی کنید. قانون طلایی: مدرکی را که برای پذیرش تغییر لازم است بخواهید و بعد واقعاً همان مدرک را بخوانید.

۸. ساخت Plugin و Site اختصاصی

وقتی یک Workflow را چند بار انجام دادید و ورودی، خروجی و چک‌هایش تکراری شد، وقت آن است که آن را به Plugin تبدیل کنید. نمونه‌ی پیشنهادی: «Launch Update Plugin» با ورودی‌هایی مثل بریف، چک‌لیست فعلی و تغییرات تاریخ‌دار، و خروجی شامل گزارش همراه منبع، بلاکرها، مالک‌ها و تصمیم‌ها. این Plugin باید در صورت کمبود منبع سؤال بپرسد، واقعیت را از پیشنهاد جدا کند و پیش‌نویس را قبل از ارسال آماده‌ی بازبینی کند. آن را فقط با داده‌ی تمیز تست نکنید؛ با اطلاعات ناقص و تاریخ‌های متناقض هم آزمایشش کنید.

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

۹. ساخت ایجنت داخل محصول خودتان

برای ساخت چنین Workflow در اپلیکیشن خودتان می‌توانید از Agents API استفاده کنید. شروع پیشنهادی: یک Project API Key بسازید، SDK را نصب کنید، نمونه‌ی رسمی Sandbox را اجرا کنید، کلید API را بیرون Sandbox نگه دارید، یک Session بسازید، پیشرفت را ببینید و نتیجه‌ی واقعی را بررسی کنید. اگر Workflow به مرورگر نیاز دارد، Computer Use را اضافه کنید؛ مثلاً: ثبت‌نام عمومی سایت را چک کن و اولین مرحله‌ای که خراب می‌شود گزارش بده، و اگر ورود لازم است از حساب آزمایشی استفاده کن.

در کنار آن، Decisions API برای تصمیم‌گیری سریع و محدود است؛ به‌جای تولید متن آزاد، مدل از میان پاسخ‌های از پیش تعریف‌شده انتخاب می‌کند. مثلاً یک Issue می‌آید و باید به copy، engineering یا human_review برود. پیش از استفاده‌ی واقعی، برچسب‌ها و نمونه‌های ارزیابی را مشخص کنید. برای ساخت ابزارهای بیشتر، گزینه‌هایی مثل Bedrock Managed Agents، Private Safety Processing، Private Inference و OpenAI Marketplace هم در آموزش نام برده شده‌اند.

۱۰. چهار Workflow عملی که آموزش پیشنهاد می‌کند

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

(ج) مسیر Issue تا PR برای توسعه‌دهنده: Issue قابل بازتولید و Environment آماده را به Codex بدهید و بخواهید بازتولید کند، اصلاح پیشنهاد بدهد، چک‌ها را اجرا کند و نتیجه‌ی واقعی را نشان بدهد؛ بعد ببینید نقص اولیه رفع شده، تست‌ها مرتبط‌اند و ریسک‌های باقی‌مانده مشخص‌اند. (د) میز پیگیری تیم: از Meetings برای یادداشت، از Space برای سابقه‌ی قطعی و از Team Task برای پیگیری استفاده کنید؛ تصمیم‌ها، اقدام‌ها، مالک‌ها و تاریخ‌ها را از یادداشت‌ها استخراج کنید، موارد نامطمئن را مشخص کنید و پیش از ارسال متوقف شوید. بعد بررسی کنید مالک واقعاً مسئولیت را پذیرفته یا فقط پیشنهاد شده است.

نکته‌ی پایانی و منبع

این آموزش بر پایه‌ی مقاله‌ی فارسی «راه‌اندازی سیستم کاری OpenAI در ۱۰ مرحله» از کد کلاد (@codecloude) در ایکس نوشته شده و آن مقاله نیز به پست‌های رسمی OpenAI و تجربه‌ی نویسنده استناد می‌کند. جزئیات دسترسی و پلن‌ها ممکن است تغییر کند، پس پیش از هر اقدام هزینه‌بر، وضعیت حساب خودتان را چک کنید. اگر دوست دارید محدودیت‌های واقعی چنین ایجنت‌هایی را بهتر بشناسید، این مقاله و این یادداشت درباره‌ی توهم توسعه‌دهنده‌ی تنها را هم بخوانید.

سوالات متداول

Dot چیست؟

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

بهترین دستور برای شروع چیست؟

یک مسئولیت مشخص با منبع، خروجی و شرط تأیید؛ نه جمله‌ای مبهم مثل «بهره‌ور باشم».

آیا Dot خودش کانال Slack را پایش می‌کند؟

نه، فقط وصل‌کردن Slack کافی نیست و رفتار پایش را باید جداگانه تعریف کنید.

پیش از ارسال پیام یا تغییر فایل باید چه کرد؟

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