اگر تیمی هستید که مستندات فنی‌اش توسط هوش مصنوعی نوشته می‌شود، احتمالاً با کوهی از متونی روبرویید که هیچ‌کس مسئولیت صحت آن‌ها را نمی‌پذیرد. انباشت مستندات به‌ندرت یک مشکل نوشتاری است؛ بلکه در واقع یک مشکل زیرساختی و مربوط به مالکیت است. MonkeyCode با گره زدن مسئولیت انسانی به تخصیص توکن‌ها در یک سرویس پیش‌نویس، راهکاری برای پایان دادن به این هرج‌ومرج ارائه داده است.
بسیاری از تیم‌ها امروز با پدیده «نثر پذیرفتنی» (Plausible Prose) دست‌وپنجه نرم می‌کنند؛ صفحاتی در ویکی که در ظاهر درست به نظر می‌رسند، اما وقتی محتوا قدیمی می‌شود و با واقعیت فاصله می‌گیرد، هیچ فرد مسئولی برای به‌روزرسانی آن‌ها وجود ندارد. این وضعیت باعث ایجاد یک ریسک یا مسئولیت (Liability) می‌شود، جایی که متون ارزان‌قیمت سریع‌تر از ظرفیت بررسی تیم‌ها انباشته می‌شوند. همان‌طور که در پوشش پیشین ما از قابلیت‌های ردیابی رگرسیون در سطح Trace در MonkeyCode دیدیم، این رویکرد جدید اکنون شکاف حاکمیتی در نوشتارِ کمک‌گرفته از AI را هدف قرار داده است.
مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیارد‌ها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — اکنون می‌تواند در ثانیه‌ها صفحات مستندات تولید کند، اما مشکل اصلی، نبودِ مالکیت است. طبق اعلام MonkeyCode، وقتی هزینه نهایی تولید یک پاراگراف تقریباً به صفر می‌رسد، تیم‌ها ده‌ها صفحه مستندات تولید می‌کنند که هیچ انسانی صراحتاً آن‌ها را پذیرفته یا تأیید نکرده است. پیامد معمول این اتفاق، یک ویکی پر از «نثر پذیرفتنی» است که در زمان قدیمی شدن محتوا، هیچ صاحب مشخصی ندارد.
یک قرارداد «پیش‌نویس/مالکیت» (Draft/Own) بخشی از این مشکل را با تعیین اینکه چه کسی مالک چه چیزی است حل می‌کند، اما تا زمانی که خط لوله (Pipeline) آن را اجبار نکند، این قرارداد تنها یک سند مجزا باقی می‌ماند. اهرم‌های اجرایی در اینجا همان منابعی هستند که تولید متن را ارزان کردند: بودجه توکن‌ها و سروری که مدل تولیدکننده را اجرا می‌کند. این مدیریت دقیق منابع برای جلوگیری از هزینه‌های پیش‌بینی‌نشده حیاتی است، چرا که هزینه‌های توکن در چرخه توسعه عامل‌محور گاهی از صرفه‌جویی در حقوق مهندسان پیشی می‌گیرد.
معماری مالکیت
این سامانه به عنوان یک دروازه کوچک بین درخواست مستندات و ادغام نهایی (Merge) عمل می‌کند. هسته این سیستم فایلی به نام ownership.yaml است که مرزهای پروژه را تعریف می‌کند. این فایل مشخص می‌کند کدام بخش‌ها می‌توانند توسط AI پیش‌نویس شوند و مالک انسانی تعیین‌شده برای هر بخش کیست.
برای مثال، یک بخش «شروع سریع» (Getting Started) می‌تواند با برچسب ai_draft: true و مالک @pavel تعریف شود، در حالی که بخش‌های حساس و حیاتی مثل «معماری سیستم» (Architecture) با برچسب ai_draft: false علامت‌گذاری می‌شوند تا تضمین شود فقط انسان آن‌ها را می‌نویسد. این سازوکار مانع از آن می‌شود که مدل تولیدکننده حتی در هنگام درخواست‌های گسترده، به محتواهای با ریسک بالا دست بزند.
مکانیزم‌های اجرایی فنی
بر اساس مستندات این گردش‌کار، سه اهرم اصلی برای تضمین مسئولیت‌پذیری به کار گرفته شده است:
- بودجه توکن‌ها: سیستم سقف
max_tokens_per_request(مثلاً ۱٬۵۰۰) وmax_tokens_per_section(مثلاً ۳۰۰) را تعیین می‌کند. این‌ها به عنوان جایگزین‌های آگاه از هزینه عمل می‌کنند؛ اگر بخشی که باید فقط توسط انسان نوشته شود به‌اشتباه به مدل داده شود، حسابداری توکن‌ها این مصرف غیرمجاز را فاش می‌کند. - سرویس پیش‌نویس: یک اپلیکیشن پایتون تنها برای بخش‌هایی که
ai_draftآن‌ها فعال است، API شرکت MonkeyCode را فراخوانی می‌کند. این سرویس یک پیش‌نویس Markdown برمی‌گرداند که در آن هر بخش به‌طور صریح با یک فیلد مالک (Owner) حاشیه‌نویسی شده است. - دروازه ادغام CI: یک GitHub Action اجرا می‌شود که یک بررسی‌کننده (Checker) را فعال می‌کند. اگر هر بخشی فاقد مالک باشد یا اگر در یک بخش «فقط انسانی»، متنی نوشته شده توسط AI یافت شود، این ابزار عملیات Build را با خطا مواجه کرده و مانع ادغام می‌شود.
جزئیات پیاده‌سازی
سرویس پیش‌نویس یک برنامه کوچک پایتون با دو نقطه اتصال (Endpoint) است. نقطه اتصال اول، موضوع و لیست بخش‌ها را می‌پذیرد، سیاست‌های مالکیت را تحلیل می‌کند و برای بخش‌های مجاز، مدل را فراخوانی می‌کند. نقطه اتصال دوم، پیش‌نویس را همراه با یک ماتریس مالکیت برای اعتبارسنجی در CI برمی‌گرداند.
اجزای کلیدی این پیاده‌سازی عبارتند از:
- بارگذاری سیاست‌ها: سرویس از
yaml.safe_loadبرای خواندن فایلownership.yamlاستفاده می‌کند تا اطمینان حاصل شود که تولیدکننده به پرچم‌هایai_draftاحترام می‌گذارد. - تولید مشروط: تابع
draft_sectionsسیاست هر بخش درخواستی را بررسی می‌کند. اگرai_draftبرابر با false باشد یا بخش در فایل تنظیمات وجود نداشته باشد، وضعیت را بهhuman-neededتغییر داده و از فراخوانی مدل صرف‌نظر می‌کند. - ردیابی توکن: سرویس با تجمیع
total_tokensاز خروجی مصرف مدل، میزانused_tokensرا ردیابی می‌کند و به سیستم اجازه می‌دهد پایبندی به بودجه را نظارت کند. - یکپارچگی با CI: فایل
.github/workflows/doc-ownership.ymlروی Pull Requestهایی که مسیرdocs/**را تغییر می‌دهند فعال شده و اسکریپتcheck_ownership.pyرا روی یک Runner از نوعubuntu-latestاجرا می‌کند.
زیرساخت و محدودیت‌ها
این خط لوله برای اجرا روی سطح رایگان MonkeyCode طراحی شده که در حال حاضر سقف ۱۰ میلیون توکن و یک گزینه سرور رایگان ارائه می‌دهد. این موضوع موانع رایج هزینه GPU و تفاوت محیط‌های اجرا (Environment Drift) را که معمولاً استقرار مدل‌های LLM محلی را متوقف می‌کند، از بین می‌برد. در این راستا، درک این نکته ضروری است که چرا لایه‌های رایگان AI بدون حسابرسی دقیق توکن معمولاً با شکست مواجه می‌شوند.
افشای اطلاعات: این مقاله به عنوان بخشی از فعالیت‌های ترویجی محصولات MonkeyCode تهیه شده است. نویسنده از دسترسی رایگان به مدل و گزینه سرور رایگان به عنوان زیربنای زمان اجرای گردش‌کار توصیف شده استفاده کرده است.
با این حال، نویسنده به چندین محدودیت حیاتی اشاره می‌کند. بودجه توکن‌ها تنها حجم را اندازه می‌گیرد و نمی‌تواند زمان کیفی که یک انسان برای بررسی صرف می‌کند را بسنجد. علاوه بر این، متادیتای مالکیت توسط یک مشارکت‌کننده مصمم می‌تواند جعل شود؛ بنابراین این دروازه بیشتر یک تور ایمنی است تا تضمینی قطعی برای صحت محتوا.
ریسک‌های اجرایی
به دلیل محدودیت‌های سرور رایگان در زمینه زمان فعال بودن (Uptime) و هم‌زمانی (Concurrency)، این ساختار برای آزمایش‌های داخلی مناسب است، نه مستندات مشتری‌محور در مقیاس بزرگ. نویسنده صراحتاً هشدار می‌دهد که تیم‌هایی که به مستندات با اعتبار قانونی یا در سطح استانداردهای نظارتی (Regulatory-grade) نیاز دارند، نباید بدون تأیید هر تولید متن توسط یک وکیل دارای مجوز، از این گردش‌کار استفاده کنند.
سه نقطه شکست اصلی برای این رویکرد عبارتند از:
- کیفیت بررسی: بودجه توکن‌ها نمی‌تواند جایگزین بررسی کیفی انسانی شود.
- یکپارچگی متادیتا: بررسی مالکیت به متادیتایی متکی است که توسط یک کاربر مصمم قابل دور زدن است.
- مقیاس‌پذیری: محدودیت‌های هم‌زمانی سرور رایگان، آن را برای نیازهای با ترافیک بالا و مشتری‌محور نامناسب می‌کند.
آیا باید این روش را امتحان کنید؟
اگر تیم شما در حال حاضر به AI برای پیش‌نویس‌های داخلی اعتماد دارد اما با مشکل مسئولیت‌پذیری در مورد محتوای قدیمی دست‌وپنجه نرم می‌کند، باید این الگو را بپذیرید. اما اگر به متونی در سطح انتشار رسمی با الزامات نظارتی نیاز دارید، از آن اجتناب کنید؛ زیرا هیچ بودجه توکنی نمی‌تواند جایگزین قضاوت یک بازبین دارای مجوز شود.
برای اکثر تیم‌های داخلی، این سبک و سنگین کردن (Trade-off) ارزشمند است. این سیستم یک حس مبهم از مسئولیت را با یک قرارداد سخت جایگزین می‌کند که توسط خط لوله CI اجرا می‌شود. این سازوکار تضمین می‌کند که در حالی که هزینه نهایی یک پاراگراف تقریباً صفر است، هزینه مالکیت صریح باقی می‌ماند.
این تغییر، رویه مستندسازی با AI را از «تولید و فراموشی» به «تخصیص و مالکیت» تغییر می‌دهد. در این نگاه، AI به عنوان یک ابزار پیش‌نویس در نظر گرفته می‌شود که باید پیش از تبدیل شدن به یک رکورد دائمی، از یک دروازه تحت مالکیت انسان عبور کند. اگر تصمیم به اجرای آن گرفتید، با یک فایل ownership.yaml واحد و یک پوشه مستندات شروع کنید و پس از دو هفته ادغام‌های موفق، آن را گسترش دهید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو