انتقال جدید: چگونه کد عامل هوش مصنوعی خود را با تیم خود به اشتراک بگذارید1 min read

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

می‌توانید ببینید که چطور کار می‌کند. کد خوب به نظر می‌رسد. حالا هم‌تیمی شما یک سوال کاملاً منطقی می‌پرسد:

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

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

اما ممکن است شخصی که درخواست می‌کند کد منبع را نخواهد. آنها می‌خواهند آن را باز کنند، آن را امتحان کنند و به شما بگویند چه چیزی باید تغییر کند.

روش صحیح به اشتراک گذاری کد تولید شده توسط هوش مصنوعی به اتفاقات بعدی بستگی دارد.

اول، شما در واقع چه چیزی را به اشتراک می‌گذارید؟

وقتی کسی کدی را که عامل هوش مصنوعی شما تولید کرده است، می‌پرسد، ممکن است منظورش سه چیز متفاوت باشد.

۱. کد منبع

یک توسعه‌دهنده باید پیاده‌سازی را بررسی کند، آزمایش‌ها را اجرا کند یا آن را با یک پایگاه کد موجود ادغام کند.

یک مخزن گیت و درخواست pull معمولاً پاسخ صحیح هستند. آن‌ها یک گردش کار آشنا برای بررسی تغییرات، بررسی تست‌ها و ادغام کد در تولید ارائه می‌دهند.

2. یک نسخه کاربردی

یک مدیر محصول می‌خواهد از طریق جریان onboarding (آشنایی با سیستم) با آن آشنا شود. یک طراح می‌خواهد طرح‌بندی واکنش‌گرا را ببیند. یک ذینفع می‌خواهد داشبورد را امتحان کند.

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

۳. کاری که شخص دیگری ادامه خواهد داد

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

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

این گردش‌های کاری با هم همپوشانی دارند، اما قابل تعویض نیستند.

تفاوت بین اشتراک‌گذاری کد و تحویل کار

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

این شامل سه کارت KPI، یک نمودار میزان استفاده و یک فیلتر تاریخ است.

می‌توانید فایل‌های React را برای هم‌تیمی خود ارسال کنید. آنها برای دیدن نتیجه به یک محیط توسعه نیاز دارند.

می‌توانید یک اسکرین‌شات ارسال کنید. آنها طرح‌بندی را می‌فهمند اما نمی‌توانند فیلتر را آزمایش کنند.

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

حالا یک گردش کار کمی متفاوت را تصور کنید.

عامل، داشبورد را در یک فضای کاری مشترک ایجاد می‌کند و URL آن را به شما می‌دهد.

هم‌تیمی شما مصنوع را باز می‌کند، فیلتر را آزمایش می‌کند و بازخورد خود را روی نمودار می‌گذارد. شما از عامل می‌خواهید که تغییر را در همان مصنوع ایجاد کند.

آدرس اینترنتی (URL) ثابت می‌ماند. کار دارای سابقه است. نیازی به شروع مکالمه دیگری و توضیح آنچه عامل قبلی ساخته است، نیست.

این همان تبادل نظری است که ارزش طراحی را دارد.

چگونه کد تولید شده توسط هوش مصنوعی را با تیم خود به اشتراک بگذاریم

در اینجا یک گردش کار عملی با استفاده از AgentGrid.io، یک فضای کاری مصنوعات مشترک برای افراد و عوامل هوش مصنوعی، ساخته شده توسط Anima، ارائه شده است.

مرحله 1: با ابزار کدنویسی هوش مصنوعی مورد نظر خود

بسازید. در Claude Code، Codex، Cursor یا ابزار دیگری که با آن راحت هستید، به کار خود ادامه دهید.

به عنوان مثال:

یک داشبورد تحلیلی محصول واکنش‌گرا با نمودار استفاده، فیلتر تاریخ و سه کارت KPI بسازید. از React استفاده کنید.

نیازی نیست ابزاری را که برای تولید کد استفاده می‌کنید تغییر دهید.

مرحله 2: نتیجه را در جایی قرار دهید که تیم شما به آن دسترسی داشته باشد

نماینده خود را به AgentGrid متصل کنید و بپرسید:

این داشبورد را به عنوان یک برنامه در AgentGrid قرار دهید. لینک مصنوع را به من بدهید و آن را خصوصی نگه دارید.

AgentGrid برنامه را به عنوان یک مصنوع با URL و تاریخچه نسخه خاص خود ذخیره می‌کند.

اگر از یک عامل کدنویسی استفاده می‌کنید که می‌تواند به طور مستقل متصل شود، دستورالعمل‌های اتصال AgentGridرا دنبال کنید. دستیارهای مبتنی بر مرورگر مانند Claude یا ChatGPT از ادغام‌های پشتیبانی شده خود استفاده می‌کنند.

نکته مهم این است که عامل شما مصنوع را در فضای کاری که اجازه دسترسی به آن را دارد، ایجاد می‌کند.

مرحله ۳: به هم‌تیمی خود دسترسی

بدهید. اثر هنری را باز کنید و لینک آن را کپی کنید.

قبل از ارسال، مطمئن شوید که هم‌تیمی شما به فضای کاری دسترسی دارد. یک URL خصوصی اثر هنری، اثر را مشخص می‌کند؛ به خودی خود مجوز نمی‌دهد.

برای همکاری داخلی، معمولاً این چیزی است که شما می‌خواهید. یک هم‌تیمی می‌تواند اثر را بدون اینکه آن را در دسترس عموم قرار دهد، بررسی کند.

ببینید نحوه‌ی اشتراک‌گذاری مصنوعات.

مرحله ۴: جمع‌آوری بازخورد در مورد نتیجه‌ی واقعی

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

به جای نوشتن یک پیام Slack جداگانه که توضیح می‌دهد کدام جزء خراب است، می‌توانند بازخورد خود را به بخش مربوطه از مصنوع پیوست کنند.

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

این کار بحث را نزدیک به موضوع مورد بررسی نگه می‌دارد.

مرحله 5: اجازه دهید نماینده کار را ادامه دهد

اکنون می‌توانید به یک نماینده متصل بگویید:

این مصنوع AgentGrid را باز کنید و فیلتر تاریخ را اصلاح کنید. طرح‌بندی موجود را حفظ کنید و همان مصنوع را به‌روزرسانی کنید.

آدرس اینترنتی (URL) واقعی مصنوع را وارد کنید.

عامل می‌تواند در صورت داشتن دسترسی و قابلیت‌های لازم، مصنوع را بررسی و به‌روزرسانی کند.

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

تاریخچه نسخه را در AgentGridببینید.

در مورد Claude، ChatGPT، Cursor و Codex چطور؟

برخی از ابزارهای هوش مصنوعی از قبل قابلیت‌های اشتراک‌گذاری بومی مفیدی دارند.

Claude می‌تواند مصنوعات پشتیبانی‌شده را در اکوسیستم خود به اشتراک بگذارد. GitHub برای بررسی کد عالی است. پلتفرم‌های توسعه می‌توانند پیش‌نمایش استقرارها را ارائه دهند.

لازم نیست فقط برای به اشتراک گذاشتن چیزی، آن گردش‌های کاری را جایگزین کنید.

AgentGrid زمانی مفید است که مرحله بعدی شامل کار افراد و نمایندگان روی یک مصنوعباشد، به خصوص در ابزارهای مختلف هوش مصنوعی.

به عنوان مثال، تیم شما ممکن است از Claude برای تهیه پیش‌نویس یک رابط، از Codex برای اصلاح رفتار آن و از یک بررسی‌کننده انسانی برای ارائه بازخورد استفاده کند.

مصنوع مشترک، مقصد مشترکی را برای آن اثر فراهم می‌کند.

چه زمانی باید به جای آن منتشر کنید؟

اگر اثر برای افرادی خارج از فضای کاری شما در نظر گرفته شده است – مانند مشتری که به یک نسخه آزمایشی عمومی نیاز دارد – ممکن است بخواهید آن را منتشر کنید.

AgentGrid می‌تواند مصنوعات برنامه پشتیبانی شده و Markdown را در URL های عمومی منتشر کند.

اما اشتراک گذاری و انتشار عمل یکسانی نیستند.

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

فقط زمانی منتشر کنید که قصد انتشار آن را دارید.

سوال بهتری که باید هنگام اتمام کار عامل بپرسید

به جای پایان دادن به هر جلسه کدنویسی با "صادر کردن فایل‌ها"، بپرسید:

چه کسی در مرحله‌ی بعد به این نیاز دارد و باید با آن چه کار کند؟

اگر یک توسعه‌دهنده نیاز به ادغام کد دارد، یک درخواست pull ایجاد کنید.

اگر کسی نیاز به آزمایش برنامه دارد، یک پیش‌نمایش کاری به او بدهید.

اگر افراد و نمایندگان نیاز به بررسی و ادامه‌ی کار با هم دارند، به آن یک خانه‌ی مشترک بدهید.

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

👉 AgentGrid را بررسی کنید.