یک صفحه ویکی برای جلوگیری از خطاهای کدنویسی عامل‌های هوش مصنوعی

تصور کنید دوشنبه صبح با سه درخواست ادغام (Pull Request) مواجه می‌شوید که توسط یک عامل هوش مصنوعی در یک حلقه (Loop) نوشته شده‌اند. در ظاهر، این موضوع شبیه به پیشرفت است، اما اغلب یک الگوی خطرناک را آشکار می‌کند: هیچ انسانی وجود ندارد که بتواند توضیح دهد چرا این تغییرات اعمال شده‌اند. پیام‌های کامیت (Commit messages) ممکن است به یک میزبان رایگان، یک حلقه عامل یا یک آزمایش جمعه‌شب که بیش از حد طول کشیده اشاره کنند، اما این سرنخ‌ها به چیزی منجر می‌شوند که «ردپای گمشده» (Vanishing audit trail) نامیده می‌شود. وقتی تاریخچهٔ چت در یک سرور با سطح دسترسی رایگان پاک می‌شود، تیم با کدی تنها می‌ماند که نه می‌تواند آن را بازسازی (Replay) کند و نه منطقش را توجیه نماید. این چالش با این واقعیت مرتبط است که گزارش‌های چت عامل‌ها لزوماً بازتاب‌دهنده وضعیت واقعی فایل‌ها در دیسک نیستند و نمی‌توان آن‌ها را جایگزین تاریخچه گیت دانست.

در ۱۱ سپتامبر ۲۰۲۶، یک چارچوب عملی جدید برای حل این مشکل پیشنهاد شد. این راهکار، «نبود امضای انسانی» را به عنوان یک گیت شکست‌خورده در فرآیند ساخت (Build gate) در نظر می‌گیرد. فرض اصلی این است که یک وصله (Patch) نوشته شده توسط هوش مصنوعی، تا زمانی که یک انسان نام‌برده صراحتاً «حوزه اثر» (Blast Radius) آن را در گیت (Git) نپذیرفته باشد، یک تغییر کامل محسوب نمی‌شود. انتظار برای صبح دوشنبه جهت بررسی این تغییرات، تیم را آموزش می‌دهد تا «سکوت» را به معنای «رضایت» در ادغام‌های بدون امضا تلقی کند.

این رویکرد در زمانی مطرح می‌شود که تیم‌های بیشتری از حلقه‌های کدنویسی اشتراکی در نسخه‌های رایگان، مانند MonkeyCode، استفاده می‌کنند. در حالی که این ابزارها سرعت توسعه (Velocity) را افزایش می‌دهند، اغلب به‌گونه‌ای شکست می‌خورند که تا زمانی که فرآیند بررسی (Review) دور زده شود، شبیه به پیشرفت به نظر می‌رسند. مدل یک وصله را پیش‌نویس می‌کند، میزبان فرآیند را زنده نگه می‌دارد و گیت یک ادغام را ثبت می‌کند؛ اما گیت ثبت نمی‌کند که چه انسانی پس از پاک شدن تاریخچهٔ چت، حوزه اثر را خوانده است. چون ردپاهای ابزار با پایان یافتن یک جلسه (Session) رایگان ناپدید می‌شوند، عامل نمی‌تواند مالک تغییرات یا ردپای حسابرسی باشد. برای حل بخشی از این مشکل انتساب، ابزارهایی مانند oh-my-agent با استفاده از قلاب‌های Git سعی کرده‌اند خطاهای انتساب کد به نویسندگان را کاهش دهند.

مدل حاکمیتی سه‌نفره

برای جلوگیری از پذیرش تغییرات بر اساس «سکوت»، این دستورالعمل (SOP) سه نقش مجزا را تعریف می‌کند که باید پیش از جابجایی هر توکنی، در یک صفحهٔ ویکی تک‌صفحه‌ای ثبت شوند. حافظهٔ جمعی تیم در یک تعطیلات طولانی دوام نمی‌آورد، به همین دلیل صفحهٔ ویکی باید خسته‌کننده و کوتاه باشد. اگر نمی‌توانید به یک نام کاربری (Handle) اشاره کنید، شما «بررسی» ندارید، بلکه فقط «امید» دارید.

• امضاکننده تغییرات (Diff Signer): انسانی که وصله را می‌خواند و عبارت SIGNER: @handle را در درخواست ادغام می‌نویسد. او باید بتواند بدون دسترسی به متن چت، تغییرات (Diff) را توضیح دهد.
• کاپیتان ادغام (Merge Captain): شخصی که اجازه دارد پس از ثبت خط امضاکننده و در حالی که پنجره زمانی هنوز باز است، دکمهٔ ادغام را فشار دهد.
• مسئول بازگشت (Rollback Owner): کسی که در صورت شکایت سیستم CI یا محیط عملیاتی، تغییرات را در یک بازه زمانی توافق‌شده به حالت قبل برمی‌گرداند. نام این شخص باید پیش از اولین فراخوانی ابزار ثبت شود، زیرا پیدا کردن یک داوطلب پس از خراب شدن شاخه اصلی (Main)، یک تحویل مسئولیت (Handoff) محسوب نمی‌شود.

نکته حیاتی این است که شخصی که حلقهٔ هوش مصنوعی را شروع می‌کند و امضاکننده تغییرات باید دو نفر متفاوت باشند، هرگاه دو انسان در دسترس باشند. برای توسعه‌دهندگان تک‌نفره، این دستورالعمل یک «چرخه خواب» (Sleep cycle) را اجباری می‌کند؛ یعنی انتظار یک شب کامل پیش از ادغام مسیرهای حساس مانند احراز هویت (Auth)، سیستم پرداخت (Billing) یا حذف داده‌ها (Deletion). این وقفه، همان کنترل واقعی است؛ نادیده گرفتن آن، این SOP را به یک نمایش نمایشی تبدیل می‌کند.

اجرای عملیاتی با ویکی تک‌صفحه‌ای

برای حفظ سادگی و چابکی، تیم‌ها از یک بلوک متنی آماده در ویکی استفاده می‌کنند. اگر این صفحه بیش از یک صفحه نمایش رشد کند، به این معناست که دستورالعمل‌های اجرا (Runbooks) با هم مخلوط شده‌اند؛ در این صورت، سلامت میزبان و توپولوژی پرامپت باید به صفحات جداگانه منتقل شوند. هر فیلد خالی به معنای آن است که حلقه نباید شروع شود.

# دستورالعمل امضاکننده (وصله‌های AI)

• وضعیت: فعال
• تاریخ آزمایش (UTC): YYYY-MM-DD
• میزبان مشترک: [برچسب سرور رایگان یا ورک‌استیشن]
• دسترسی به مدل: [فقط برچسب نسخه رایگان؛ بدون حدس زدن سهمیه‌ها]
• مخزن: [org/repo]
• شاخه: [topic branch]
• شروع‌کننده حلقه (وظیفه): [@handle]
• امضاکننده: [@handle]
• کاپیتان ادغام: [@handle]
• مسئول بازگشت: [@handle]
• پنجره امضا: [شروع UTC] ← [پایان UTC]
• لیست مسیرهای مجاز: [src/app/ docs/]
• خارج از محدوده: [secrets, lockfiles, prod Terraform]
• پنجره بازگشت: [مثلاً ۴ ساعت پس از ادغام]

الزامات عبور از گیت:

• هیچ ادغامی به شاخه اصلی بدون عبارت SIGNER: @handle در متن PR پذیرفته نمی‌شود.
• اگر پنجره امضا منقضی شده باشد، ادغام ممنوع است.
• اگر مسئول بازگشت آفلاین باشد و تغییرات به زیرساخت (Infra) مربوط شود، ادغام انجام نمی‌شود.

ردیابی پس از حلقه:

• لینک PR: [link]
• هش کامیت (Commit SHA): [hash]
• امضاکننده تغییرات را بدون متن چت خوانده است: [بله/خیر]

گردش کار اجرا

فرآیند با ایجاد یک شاخه موضوعی (Topic Branch) توسط شروع‌کننده و پوش کردن آن به صورت خالی آغاز می‌شود. این کار تضمین می‌کند که درخواست ادغام پیش از نوشتن اولین فایل توسط مدل، وجود داشته باشد. سپس شروع‌کننده صندلی‌های ویکی را پر کرده و یک «لیست مسیرهای مجاز» (Path allowlist) را در متن PR تعریف می‌کند تا از ورود عامل به فایل‌های حساس، فایل‌های قفل (Lockfiles) یا تنظیمات Terraform محیط عملیاتی جلوگیری کند.

گام‌های شروع‌کننده:
۱. ایجاد یک شاخه موضوعی از یک شاخه پیش‌فرض به‌روز شده و پوش کردن آن به صورت خالی.
۲. باز کردن صفحه ویکی، پر کردن تمام صندلی‌ها و پینگ کردن امضاکننده در چت به همراه لینک صفحه و لیست مجاز.
۳. نوشتن لیست مسیرهای مجاز در متن PR.
۴. انتظار برای پاسخ «پنجره باز است» (Window open) توسط امضاکننده در صفحه ویکی؛ اگر پاسخی نیاید، حلقه شروع نمی‌شود.
۵. اجرای حلقه کدنویسی فقط روی شاخه موضوعی. توقف دقیق در پایان پنجره امضا، حتی اگر عامل بخواهد یک فایل دیگر را بنویسد.
۶. پوش کردن تغییرات، چسباندن لینک PR در ویکی و ترک محیط بدون انجام ادغام.

برای کسانی که از رابط خط فرمان (CLI) استفاده می‌کنند، یک توالی دستورات پیشنهادی شامل دریافت (Fetch) از origin، سوییچ به شاخه‌ای مانند lab/ai-patch-$(date -u +%Y%m%d) و استفاده از gh pr create برای ایجاد متنی حاوی SIGNER: UNASSIGNED، نام کاربری مسئول بازگشت و لیست مجاز است. یک شاخه خالی با یک PR واقعی، بسیار بهتر از توده‌ای از فایل‌های بررسی‌نشده در لپ‌تاپ است.

انضباط امضاکننده

امضاکننده تغییرات موظف است «شخصیت» مدل و داستانی را که عامل در چت تعریف کرده است، نادیده بگیرد. او در حال بررسی یک Diff در گیت است که باید پس از ناپدید شدن جلسه رایگان، زنده بماند.

فرآیند بررسی امضاکننده:

• باز کردن PR بدون باز کردن متن چت برای قضاوت بر اساس فایل‌ها، نه داستان مدل.
• ابتدا بررسی ساختار درختی (Tree)؛ خواندن متن چت تنها در صورتی که ساختار درختی از پیش قابل دفاع باشد.
• رد کردن وصله اگر مسیرهایی خارج از لیست مجاز را لمس کرده باشد، حتی اگر تغییر هوشمندانه به نظر برسد یا پیام کامیت با اعتمادبه‌نفس نوشته شده باشد.
• رد کردن وصله اگر حالت شکست (Failure mode) آن را نتوان در یک جمله در صفحه ویکی در کنار SHA توضیح داد.
• در صورت پذیرش، جایگزینی SIGNER: UNASSIGNED با SIGNER: @yourhandle و یک برچسب زمانی UTC در متن PR.

امضاکنندگان باید از دستورات بازرسی محلی مانند git diff origin/main...origin/lab/ai-patch-20260911 --stat استفاده کنند تا پیش از دیدن کل تغییرات، اندازه تغییر را بسنجند. اگر بیش از چند فایل تغییر کرده باشد، این یک «بازنویسی» (Rewrite) است، نه یک «وصله» (Patch)، و به پنجره زمانی طولانی‌تر و یک کاپیتان ادغام بیدار نیاز دارد.

گیت خودکار: check_signer.py

برای اجباری کردن این روند، یک گیت مبتنی بر پایتون به نام check_signer.py معرفی شده است. این اسکریپت متن PR را برای یافتن یک نام کاربری انسانی معتبر با استفاده از یک عبارت منظم (Regex) بررسی می‌کند: ^SIGNER:\s*@?(?P<name>[A-Za-z0-9][A-Za-z0-9_-]{1,38}).

اگر اسکریپت جای‌گذارهایی مانند unassigned، none، n/a، agent، bot یا model را پیدا کند، گیت با کد بازگشت ۲ شکست می‌خورد. اگرچه این یک کنترل ضعیف است که می‌توان با تایپ کردن نام یک همکار آن را دور زد، اما به مراتب قوی‌تر از اتکا به یک جلسه چت ناپدید شده است.

تیم‌ها می‌توانند این را در یک GitHub Action (مثلاً signer-gate) ادغام کنند که در رویدادهای opened، edited یا synchronize فعال شود. این اکشن متن PR را در یک فایل می‌نویسد و اسکریپت پایتون را اجرا می‌کند تا در صورت نبود خط امضاکننده، ادغام را مسدود کند.

ماتریس تصمیم‌گیری پس از حلقه

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

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

تحلیل: تغییر هزینه سرعت هوش مصنوعی

این چارچوب نشان‌دهنده تغییری در تجربه توسعه‌دهنده AI از «اعتماد به عامل» به «تأیید مصنوع» (Artifact) است. با معرفی تأخیرهای عمدی — مانند پنجره امضا و وقفه چرخه خواب — این SOP با سرعت هوش مصنوعی به عنوان ریسکی برخورد می‌کند که باید مدیریت شود، نه معیاری که باید به حداکثر برسد.

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

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

محدودیت‌ها و استثنائات:

• این SOP مدل را ایمن‌تر نمی‌کند و جلسات حذف شده را بازیابی نمی‌کند؛ بلکه فقط مالکیت را مرئی می‌کند.
• اگر یک جریان CODEOWNERS تنظیم‌شده از پیش ادغام‌ها را مسدود می‌کند، این SOP را نادیده بگیرید.
• از این روش برای اصلاحات فوری (Hotfixes) در حوادث که یک فرمانده نام‌برده و پل ارتباطی ثبت‌شده دارند، استفاده نکنید.
• هرگز حلقه‌های عامل بدون امضا را به اعتبارنامه‌های محیط عملیاتی (Production credentials) در هیچ میزبانی متصل نکنید.

در گام بعدی، تیم‌ها باید ارزیابی کنند که آیا فایل‌های CODEOWNERS فعلی آن‌ها کافی است یا نیاز به پیاده‌سازی یک «گیت امضاکننده» اختصاصی در خط لوله CI/CD خود برای مسدود کردن ادغام‌های بدون امضای AI دارند.