ProofRun با رسیدهای رمزنگاری ادعای موفقیت عامل‌های کدنویس را می‌سنجد

تغییر حتی یک بایت در کد منبع می‌تواند تستی را که پاس شده بود به شکست تبدیل کند، اما عامل‌های هوش مصنوعی اغلب بر اساس حافظه‌ای قدیمی ادعا می‌کنند که «همه تست‌ها پاس شدند». ProofRun که در ۱۶ اوت ۲۰۲۶ منتشر شد، این مشکل را با ایجاد یک رسید رمزنگاری‌شده حل می‌کند که نتایج اجرا را دقیقاً به وضعیت فعلی فایل‌های محلی شما گره می‌زند.

تصور کنید یک عامل (Agent) — شبیه دستیاری که کدها را تغییر می‌دهد اما گاهی فراموش می‌کند دوباره آن‌ها را امتحان کند — پروژه شما را سه بار ویرایش کند اما مجموعه تست‌ها را فقط یک بار در ابتدا اجرا کرده باشد. بدون یک لایه اعتبارسنجی، شما راهی ندارید تا بفهمید جمله «همین الان اجرا کردم و پاس شد» یک حقیقت است یا یک توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند. در چنین حالتی، عامل ممکن است صرفاً استنتاج کند که تغییرات اعمال شده «درست به نظر می‌رسند». این شکاف اعتماد، یک نقطه کور خطرناک در جریان‌های توسعه خودکار ایجاد می‌کند.

همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد کورکورانه به خروجی مدل‌ها می‌تواند منجر به رگرسیون‌های شدید در نرم‌افزار شود. این چالش مشابه رویکرد صحت‌سنجی مبتنی بر داده در Crucible است که برای مقابله با اعتماد کورکورانه به عامل‌ها طراحی شده است. ProofRun به عنوان یک فایل باینری محلی عمل می‌کند که هیچ تماسی با مدل‌های زبانی یا تله‌متری شبکه ندارد. این ابزار با شروع یک زیرپردازش (Subprocess) واقعی و خواندن کد خروجی (Exit Code) واقعی دستور عمل می‌کند. هر نتیجه به یک اثر انگشت متصل است که از کامیت گیت و یک هش SHA-256 از تمام تغییرات ثبت‌نشده، شامل فایل‌های ردیابی‌نشده (Untracked files)، تشکیل شده است.

شکاف اعتماد

به نقل از مستندات پروژه، ProofRun سعی نمی‌کند قضاوت کند که آیا کد درست است یا خیر، یا بخواهد عامل هوش مصنوعی را صادق‌تر کند. در عوض، ادعای موفقیت را «قابل بررسی» می‌کند. این ابزار فاصله بین «اجرا کردم و پاس شد» و «تقریباً مطمئنم که پاس می‌شد» را از بین می‌برد.

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

سازوکار اصلی و وضعیت‌ها

این ابزار تضمین‌های مبهم هوش مصنوعی را با چهار وضعیت concrete جایگزین می‌کند و هیچ گزینه پنجمی به نام «احتمالاً درست است» وجود ندارد:

• PASS: دستور با موفقیت روی وضعیت فعلی کد اجرا شد.
• FAIL: دستور اجرا شد اما کد خروجی غیرصفر برگرداند.
• STALE: تست قبلاً پاس شده بود، اما از آن زمان کد تغییر کرده است. حتی یک فاصله (Space) اضافی یا یک فایل جدید این وضعیت را فعال می‌کند.
• NOT RUN: هیچ سابقه اجرایی برای وضعیت فعلی کد وجود ندارد.

جزئیات فنی و پیاده‌سازی

پیکربندی از طریق فایل .proofrun.yml انجام می‌شود. در این فایل، بررسی‌ها به جای رشته‌های متنی شل، به صورت آرایه‌های آرگومان (argv lists) تعریف می‌شوند. این طراحی مانع از ترفندهای تزریق شل (Shell Injection) می‌شود و تضمین می‌کند دستوری مثل pytest -k "foo bar" را نتوان با دستوری مشابه اما متفاوت که پس از تبدیل به متن یکسان به نظر می‌رسد، جایگزین کرد.

گزینه‌های کلیدی پیکربندی عبارتند از:

• command: یک لیست argv (مثلاً [pytest] یا [npm, run, build]).
• required: یک مقدار بولی. اگر true باشد، عدم موفقیت این تست مانع از پاس شدن دستور proofrun status --strict می‌شود.

برای ادغام در CI/CD، یک GitHub Action ارائه شده است که کامیت سرِ PR را مستقلاً چک‌اوت می‌کند. طبق گزارش توسعه‌دهندگان، این اکشن برای جلوگیری از کامیت‌های پیش‌نمایش مصنوعی (Synthetic merge-preview commits)، هرگز به چک‌اوتِ جریان کاری فراخواننده اعتماد نمی‌کند. این اکشن هرگونه receipt.json را از شاخه PR پاک کرده و یک باینری تاییدشده از طریق چک‌سام (Checksum) را برای اجرای proofrun run-all دانلود می‌کند تا پیش از تایید نهایی، وضعیت proofrun status --strict را بررسی کند.

یک محدودیت شناخته‌شده این است که این اکشن نمی‌تواند PRهایی را که خودِ فایل .proofrun.yml را تضعیف می‌کنند مسدود کند. اگرچه ابزار یک هشدار (Build annotation) در صورت تفاوت پیکربندی با شاخه پایه ارائه می‌دهد، اما کاربران باید این تغییرات را به صورت دستی بررسی کنند.

توسعه و پاسخگویی

نکته جالب این است که ProofRun توسط یک عامل هوش مصنوعی (Claude Code) و تحت هدایت انسان توسعه یافته است. فرآیند توسعه شامل بررسی‌های خصمانه (Adversarial reviews) بود که یک نقص را آشکار کرد: آرگومان‌های اشتباه شل می‌توانستند سیستم را فریب دهند تا برای صفر تست، وضعیت PASS گزارش کند.

توسعه‌دهندگان این مشکل را با تایید هر پچ در برابر یک مورد بازتولید واقعی (Real reproduction case) حل کردند، نه با تکیه بر بررسی‌های ظاهری و احتمال. این رویکرد تضمین می‌کند ابزار بتواند در برابر همان سخت‌گیری‌هایی که روی عامل‌ها اعمال می‌کند، دوام بیاورد.

این تغییر، صنعت را از «اعتماد به عامل» به سمت «تایید ادعا» می‌برد. این رویکرد شباهت زیادی به سیستم Railward دارد که امنیت عامل‌ها را از طریق گواهه‌های امضاشده تأیید می‌کند تا از اجرای دستورات ناامن جلوگیری شود. با treating کردن هوش مصنوعی به عنوان یک بازیگر غیرقابل اعتماد و پذیرفتن شل محلی به عنوان منبع حقیقت، توسعه‌دهندگان می‌توانند proofrun status --strict را در pre-commit hookها قرار دهند تا هر کدی که اثبات رمزنگاری‌شده‌ای برای پاس شدن ندارد، مسدود شود.

برای یک توسعه‌دهنده معمولی، این یعنی پایان بهانه‌ی «روی سیستم عامل کار می‌کرد». این ابزار انضباطی را تحمیل می‌کند که در آن عامل باید کار خود را از طریق اجرا ثابت کند، نه فقط با متقاعد کردن انسان.

نصب و آینده

کاربران می‌توانند ابزار را از طریق اسکریپت curl نصب کنند:
curl -L https://github.com/yebiguo/proofrun/releases/download/v0.2.0/proofrun_linux_amd64.tar.gz | tar xz
یا با استفاده از زبان Go آن را از منبع بسازند:
go install github.com/yebiguo/proofrun/cmd/proofrun@latest

نقشه راه نسخه ۰.۳ شامل موارد زیر است:

• پشتیبانی از خروجی‌های ساختاریافته برای اجراکننده‌های رایج مانند pytest، Jest و JUnit.
• رسیدهای امضا شده و مقاوم در برابر دستکاری (Tamper-evident).
• حفاظت از فایل .proofrun.yml برای جلوگیری از تضعیف آن در همان PRی که کد را تغییر می‌دهد.

گام بعدی شما

• اگر از عامل‌های کدنویس استفاده می‌کنید، ProofRun را در pre-commit hookهای خود قرار دهید تا از ورود کدهای «احتمالاً درست» به مخزن جلوگیری کنید. در کنار این ابزار، استفاده از مرورگر hwatu برای کاهش تأخیر بررسی صفحات می‌تواند سرعت چرخه توسعه را افزایش دهد.
• فایل .proofrun.yml را برای تست‌های حیاتی پروژه خود تعریف کنید تا هر تغییر کوچک، وضعیت تست‌ها را به STALE تغییر دهد.
• در PRهای آینده، تغییرات فایل پیکربندی ProofRun را با دقت بررسی کنید تا مطمئن شوید عامل هوش مصنوعی برای دور زدن تست‌ها، قوانین را تغییر نداده است.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.