DentCast
DentCast
دکتر فواد شهابیان
← بازگشت به پرامپتولوژیست English
پیوست ۲ · قسمت ۵

پیوست ۲ ـ قسمت ۵: هوش مصنوعی فایل‌ها را تغییر داده است؛ از کجا بفهمیم همه‌چیز درست است؟

⏱ ۸ دقیقه مطالعه

در قسمت قبل یاد گرفتیم تغییرات چطور در گیت‌هاب ثبت می‌شوند و چطور می‌توانیم به نسخه‌های قبلی فایل‌هایمان برگردیم.

اما یک سؤال مهم باقی مانده است.

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

از کجا بفهمیم دقیقاً چه چیزی را تغییر داده است؟ و اگر از نتیجه راضی نبودیم، چه کار کنیم؟

خوشبختانه گیت‌هاب برای همین موضوع هم راه‌حل دارد.

قبل از اینکه تغییرات را قبول کنیم

برگردیم به همان مثال دستور توصیه‌های بعد از جراحی که در قسمت‌های قبل داخل ریپوی "my-prompts" گذاشتیم.

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

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

اما یک نکته وجود دارد.

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

پس بهتر است اول نتیجه را ببینیم و بعد دربارهٔ پذیرفتنش تصمیم بگیریم.

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

حالا می‌خواهیم نتیجهٔ کار روی آن برنچ را بررسی کنیم.

Pull Request یعنی چه؟

گیت‌هاب قابلیتی به اسم Pull Request دارد که معمولاً به‌اختصار به آن PR می‌گویند.

اسمش شاید کمی عجیب باشد، اما مفهومش ساده است.

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

حالا همکارتان می‌تواند تغییرات را ببیند، دربارهٔ آن‌ها نظر بدهد و اگر موافق بود، آن‌ها را قبول کند.

Pull Request هم تقریباً همین کار را انجام می‌دهد.

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

ساختن PR به معنی قبول‌شدن تغییرات نیست. فقط فرصتی است برای اینکه ببینیم چه اتفاقی افتاده و تصمیم بگیریم.

یک Pull Request واقعی در ریپوی دنت‌کست؛ عنوان و وضعیت Merged
یک Pull Request واقعی در ریپوی دنت‌کست؛ عنوان و وضعیت Merged

گیت‌هاب به ما چه نشان می‌دهد؟

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

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

وقتی وارد PR می‌شویم و بخش تغییرات فایل‌ها، یعنی Files changed، را باز می‌کنیم، می‌توانیم ببینیم چه جمله‌هایی اضافه شده‌اند و چه قسمت‌هایی حذف یا عوض شده‌اند.

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

این‌طوری لازم نیست دو نسخهٔ کامل را کنار هم بگذاریم و خط‌به‌خط دنبال تفاوت‌ها بگردیم.

مثلاً شاید از هوش مصنوعی فقط خواسته باشیم دربارهٔ خون‌ریزی توضیحی اضافه کند، اما ببینیم یکی از توصیه‌های قبلی را هم تغییر داده است.

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

بخش Files changed؛ قرمز متن قبلی، سبز متن جدید
بخش Files changed؛ قرمز متن قبلی، سبز متن جدید

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

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

اگر از تغییرات خوشمان نیامد چه؟

هیچ مشکلی نیست. هنوز قرار نیست تغییرات وارد نسخهٔ اصلی شوند.

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

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

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

کافی است بگوییم آن قسمت را به حالت قبل برگرداند.

هوش مصنوعی می‌تواند اصلاحات را روی همان برنچ انجام بدهد و PR را به‌روز کند تا دوباره نتیجه را ببینیم.

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

حالا یک بار امتحان کنیم

همان ریپوی "my-prompts" را در نظر بگیرید.

اگر از ابزار هوش مصنوعیِ متصل به گیت‌هاب، مثل Work در چت‌جی‌پی‌تی، استفاده می‌کنید و ابزار اجازهٔ تغییر فایل‌ها را دارد، می‌توانید این دستور را به آن بدهید:

«در ریپوی "my-prompts"، فایل دستور توصیه‌های بعد از جراحی رو پیدا کن. یه بخش جدید دربارهٔ خون‌ریزی بعد از جراحی بهش اضافه کن. متن برای بیمار ساده و قابل‌فهم باشه. روی یه برنچ جدا کار کن و یه Pull Request بساز. فعلاً تغییرات رو با نسخهٔ اصلی مرج نکن. لینک PR رو بهم بده.»

هوش مصنوعی در صورت داشتن دسترسی لازم می‌تواند تغییرات را آماده کند و لینک PR را به شما بدهد.

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

حتی می‌توانید از هوش مصنوعی بخواهید کار را ساده‌تر کند:

«تغییراتی که انجام دادی رو بهم توضیح بده. بگو چه جمله‌هایی اضافه شدن، چه چیزهایی حذف شدن و آیا به بخش‌های دیگهٔ فایل هم دست زدی یا نه.»

اگر از نتیجه راضی نبودید، از آن بخواهید اصلاحش کند.

و اگر همه‌چیز درست بود، حالا نوبت تأیید است.

Merge؛ وقتی تغییرات را قبول می‌کنیم

در قسمت سوم با Merge هم آشنا شدیم.

مرج یعنی تغییرات یک برنچ را وارد برنچ اصلی کنیم.

حالا که تغییرات را دیدیم و بررسی کردیم، اگر از نتیجه راضی بودیم، می‌توانیم به هوش مصنوعی بگوییم:

«تغییرات رو تأیید می‌کنم. همین PR رو مرج کن و لینک فایل نهایی در نسخهٔ اصلی رو بهم بده.»

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

یا می‌توانیم خودمان از طریق گیت‌هاب تغییرات را مرج کنیم.

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

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

بعد از Merge؛ تغییرات وارد main شده‌اند
بعد از Merge؛ تغییرات وارد main شده‌اند

اگر تغییرات با هم سازگار نباشند چه؟

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

اما قبل از اینکه آن تغییرات را تأیید کنید، خودتان همان بخش را در نسخهٔ اصلی اصلاح می‌کنید.

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

به این وضعیت Conflict یا تداخل تغییرات می‌گویند.

قرار نیست خودمان درگیر حل فنی این مشکل شویم.

کافی است از هوش مصنوعی بخواهیم بررسی کند چه تغییراتی با هم تداخل دارند و چطور می‌شود مشکل را برطرف کرد.

مثلاً بگوییم:

«بررسی کن چرا تغییرات با هم تداخل دارن. هر دو نسخه رو بهم نشون بده و پیشنهاد بده کدوم قسمت‌ها باقی بمونن. قبل از تأیید من چیزی رو حذف یا مرج نکن.»

به همین سادگی. ما تصمیم می‌گیریم متن نهایی چه باشد و هوش مصنوعی می‌تواند کارهای اجرایی را انجام بدهد.

پس ما دقیقاً چه کاری باید انجام بدهیم؟

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

هوش مصنوعی می‌تواند فایل را پیدا کند، تغییر بدهد، برنچ بسازد، تغییرات را ثبت کند و PR آماده کند.

کاری که ما انجام می‌دهیم این است که مشخص کنیم چه می‌خواهیم، نتیجه را بررسی کنیم و در نهایت دربارهٔ پذیرفتن تغییرات تصمیم بگیریم.

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

فقط یادتان باشد: اینکه هوش مصنوعی می‌تواند کارهای گیت‌هاب را انجام بدهد، به این معنی نیست که باید بدون بررسی به آن اجازه بدهیم هر تغییری را نهایی کند.

حالا تقریباً همهٔ مفاهیم اصلی موردنیازمان را یاد گرفته‌ایم.

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

Pull RequestPRFiles changedMergeConflictBranchبررسی تغییرات هوش مصنوعیGitHub
#پرامپتولوژیست#هوش_مصنوعی#GitHub#ChatGPT
← قسمت قبلی قسمت بعدی →

جستجوی سراسری دنت‌کست