متد ۴ فایله: کاهش خطاهای کدنویسی حسی با پیوند تست‌های اجرایی

تصور کنید یک برنامه‌نویس است، کدی را که هوش مصنوعی با اطمینان کامل نوشته دریافت می‌کند و تنها به دلیل لحن متقاعدکنندهٔ پاراگراف پایانی مدل، آن را بدون بررسی دقیق Diff در پروژه ادغام می‌کند. این همان «تلهٔ خلاصه» است؛ تمایل خطرناکی که در آن توسعه‌دهندگان به‌جای بررسی تغییرات تأیید شده، بر اساس یک پاراگراف صیقل‌خورده در انتهای پاسخ مدل تصمیم می‌گیرند. برای مقابله با این وضعیت، چارچوبی فنی در تاریخ ۹ اکتبر ۲۰۲۶ از طریق dev.to معرفی شد که بر این واقعیت استوار است: پاسخ مطمئن یک مدل هوش مصنوعی، به معنای اثبات انجام کار (Proof of Work) نیست. این رویکرد در واقع پاسخی به این چالش است که چرا یک پاسخ موفق هوش مصنوعی دلیل کافی برای تأیید یکپارچگی سیستم نیست و نیاز به متدهای سخت‌گیرانه‌تری دارد.

این تغییر رویکرد در زمانی رخ می‌دهد که Vibe Coding (کدنویسی حسی) — یعنی نوشتن کد بر اساس «حس خوب» از پاسخ مدل به‌جای اعتبارسنجی سخت‌گیرانه — به یک ریسک جدی در محیط‌های حرفه‌ای تبدیل شده است. بسیاری از مهندسان اکنون از دسترسی‌های رایگان به مدل‌ها و سرورهای موقت (Disposable Servers) استفاده می‌کنند؛ وضعیتی که یک تلهٔ روانی ایجاد می‌کند: چون هزینهٔ یک جلسهٔ چت کم است، کد حاصل از آن را هم «یک‌بار مصرف» و کم‌اهمیت می‌پندارند. اما خطر اصلی اینجاست که «ارزان بودن» هرگز به معنای «بررسی‌شده بودن» نیست.

تفاوت میان رونوشت و سوابق

یک رونوشت (Transcript) تمیز، به معنای یک سابقهٔ بازبینی (Review Record) نیست. رونوشت صرفاً داستانی از توکن‌هاست — یعنی یک لاگ زمانی از یک گفتگو. در مقابل، سوابق بازبینی مجموعه‌ای از فایل‌هاست که یک همکار می‌تواند آن‌ها را واقعاً دوباره اجرا کند تا صحت ادعا را بسنجد. این تمایز برای درک این نکته حیاتی است که لاگ‌های توهمی در ارزیابی عملکرد AI اغلب بیشتر شبیه داستان هستند تا واقعیت.

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

کالبدشناسی رسید (The Anatomy of the Receipt)

برای حل این مشکل، گردش‌کار پیشنهادی ایجاد یک «رسید» محلی را اجباری می‌کند؛ مجموعه‌ای از چهار فایل متنی ساده و «کسل‌کننده» که باید پیش از به اشتراک‌گذاری هر کدی روی لپ‌تاپ توسعه‌دهنده وجود داشته باشند. هدف برای یک ادغام (Merge) در روز جمعه، رسیدن به همین حالت «کسل‌کننده» است. این فایل‌ها مانند یک سیمِ تله عمل می‌کنند تا مطمئن شوند توسعه‌دهنده واقعاً خروجی هوش مصنوعی زاینده را تایید کرده و هرگونه میان‌بری برای بازبین (Reviewer) آشکار شود:

• prompt.txt: متن دقیق ارسالی به مدل را ذخیره می‌کند. این کار تضمین می‌کند که هیچ دادهٔ حساسی (Live Secrets) لو نرفته و سوابقی از ورودی‌ها باقی بماند.
• claim-ledger.txt: هر ادعای مدل (مثلاً «باگ پارسر رفع شد») را به یک مسیر فایل مشخص و یک دستور تایید متصل می‌کند. اگر ادعایی را نتوان به یک بررسی (Check) متصل کرد، باید حذف شود.
• replay.txt: دستور دقیق اجرا شده، خط خروجی (Exit Line) و هش (Hash) لاگ را ذخیره می‌کند. این ثابت می‌کند که تست واقعاً اجرا شده است و تخیلی نبوده است.
• receipt.sha256: نام این فایل‌ها و هش آن‌ها را ذخیره می‌کند تا هرگونه ویرایش بعدی در مدارک کاملاً آشکار شود.

حذف پنج الگوی شکست (Anti-patterns) هوش مصنوعی

این سیستم به‌طور خاص پنج حالت شکست رایج در توسعه با کمک هوش مصنوعی را هدف قرار می‌دهد:

۱. جایگزینی خلاصه به‌جای Diff

• نشانه: متن Pull Request صرفاً همان پاراگراف پایانی مدل است. بازبین‌ها به لحن متن پاسخ می‌دهند و هیچ‌کس خط خاصی از کد را نام نمی‌برد. باگ‌ها زیر یک پایان‌بندی صیقل‌خورده پنهان می‌شوند.
• علت ریشه‌ای: چت بر اساس زمان مرتب شده است، اما Diff این‌طور نیست. توسعه‌دهندگان اجازه می‌دهند دیدگاه آسان‌تر (چت) بر بازبینی غلبه کند و گاهی پاراگراف‌هایی را ادغام می‌کنند که هرگز آن‌ها را باز نکرده‌اند.
• جایگزین: پیش از باز کردن درخواست، دفترچه ادعاهای (Ledger) دقیق نوشته شود. هر ادعا باید به یک مسیر و یک تست اشاره کند. مثال:
  claim: empty names are rejected
file: src/parser.py
check: python -m unittest tests.test_parser

۲. تبدیل قیمت به کنترل حریم خصوصی

• نشانه: یک شناسه مشتری، کلید API یا یک Trace خام در پرامپت قرار می‌گیرد، چون کلمه «رایگان» باعث شده است که کاربر احساس کند این کپی-پیست کردن کوچک و بی‌اهمیت است.
• علت ریشه‌ای: تلقی کردن یک برچسب صورت‌حسابی (Billing Label) به عنوان یک مرز امنیتی. «امید داشتن» یک ابزار حذف داده‌های حساس (Redaction) نیست.
• جایگزین: اجرای یک جست‌وجوی بلند و هشداردهنده پیش از ارسال. این یک سیم تله است، نه یک برنامه کامل انطباق. دستور پیشنهادی:
  rg -n -i 'api[_-]?key|secret|password|BEGIN ' prompt.txt
  اگر نتیجه‌ای یافت شد، توسعه‌دهنده متوقف شده و نمونه را با مقادیر جعلی بازنویسی می‌کند.

۳. اختراع فیلدهای غایب توسط مدل

• نشانه: یک بلوک ابزار (Tool Blob) فاقد کلیدی است که پچ همچنان از آن استفاده می‌کند. چت این شکاف را با نثر پر می‌کند و کد بر اساس فیلدی تصمیم می‌گیرد که هرگز بازگردانده نشده است.
• علت ریشه‌ای: اعتماد به شکلی که فرد «امید دارد» ببیند، به‌جای تثبیت شکلی که «واقعاً» دریافت شده است.
• جایگزین: ثبت کلیدهای مشاهده‌شده (Observed Keys) و خالی گذاشتن شکاف‌ها. از مدل نخواهید که فیلدها را اختراع کند. اگر کلیدی غایب بود، اقدام باید یک «توقف» (Stop) سخت باشد.
  مثال:
  tool: repo.status
observed_keys: [branch, dirty]
missing_keys: [ahead]
action: stop

۴. جایگزینی کامنت به‌جای تست

• نشانه: Diff عمدتاً شامل تغییر نام متغیرها و کامنت‌هاست. ادعا می‌گوید «رفع باگ»، اما هش تست تغییر نکرده است.
• علت ریشه‌ای: کامنت‌ها در یک چت طولانی حس پیشرفت ایجاد می‌کنند، در حالی که تست‌ها حس اصطکاک و دشواری دارند.
• جایگزین: هر ادعای رفع باگ باید یک مسیر تست را نام ببرد. اگر هش تست با دیروز یکی باشد، ادعا باطل است. توسعه‌دهنده باید یا تست را بنویسد یا برچسب را حذف کند، که از طریق دستورات زیر تایید می‌شود:
  sha256sum tests/test_parser.py
git diff --stat -- tests/test_parser.py

۵. تبدیل لاگ دیروز به پرامپت امروز

• نشانه: ارسال مجدد کل تاریخچه چت برای ارائه زمینه (Context)، که باعث می‌شود بن‌بست‌ها، تصمیمات معکوس و اسرار قدیمی دوباره وارد پرامپت شوند.
• علت ریشه‌ای: استفاده از ارائه‌دهنده هوش مصنوعی به عنوان یک دفترچه یادداشت کاری به‌جای یک سیستم ثبت سوابق.
• جایگزین: نگهداری یک خلاصه ۲۰ خطی از تصمیمات و گزینه‌های رد شده. هش این خلاصه را بگیرید و فقط همان را ارسال کنید.
  مثال:
  decision: reject empty names in parser
rejected: coerce empty names to guest
ledger: claim-ledger.txt
stop: do not add a network call

اسکریپت اعتبارسنجی

برای خودکارسازی این روند، نویسنده یک اسکریپت Bash به نام receipt-check.sh پیشنهاد کرده است که این قوانین را از طریق کدهای خروجی (Exit Codes) اجرا می‌کند. این اسکریپت از روی درخت کاری (Worktree) فراخوانی می‌شود، نه از روی حافظه.

#!/usr/bin/env bash
# receipt-check.sh - local check before share
set -euo pipefail
need() { test -s "$1" || exit 2; }
need prompt.txt
need claim-ledger.txt
need replay.txt
if rg -n -i 'api[_-]?key|secret|password|BEGIN ' prompt.txt; then
  printf '%s\n' 'redaction hit'
  exit 3
fi
if rg -n '^claim:.*bugfix' claim-ledger.txt >/dev/null; then
  if ! rg -n '^test:' claim-ledger.txt >/dev/null; then
    printf '%s\n' 'bugfix claim without test line'
    exit 4
  fi
fi
sha256sum prompt.txt claim-ledger.txt replay.txt > receipt.sha256
printf '%s\n' 'receipt ok'

درک کدهای خروجی (Exit Codes)

توسعه‌دهنده با کد خروجی در محیط چت مذاکره نمی‌کند؛ زیرا عذرخواهی یک مدل، یک کد خروجی (Exit Code) نیست.

نقش زیرساخت‌های رایگان

اگرچه این گردش‌کار مستقل از مدل است، اما به MonkeyCode به عنوان یک میز کار اختیاری که دسترسی رایگان به مدل‌ها و سرورها را فراهم می‌کند، اشاره می‌کند. با این حال، نویسنده هشدار می‌دهد که سرورهای رایگان فقط باید برای کارهای پیش‌نویس (Scratch work) استفاده شوند.

هیچ صفحه اصلی به این پیش‌نویس پیوست نشده بود، بنابراین برای جلوگیری از ارائه ارقام قدیمی درباره سهمیه‌ها یا مدت‌زمان‌ها که ممکن است باعث اتلاف زمان در یک Sprint شود، عدد خاصی ذکر نشده است. کاربران باید مستندات فعلی را خودشان بررسی کنند. قانون ثابت است: داده‌های مشتری و اعتبارنامه‌های بلندمدت هرگز نباید روی باکس‌های رایگان قرار گیرند. نبود یک رسید، بسیار ارزان‌تر از نشت یک ردپای داده (Leaked Trace) است.

چه کسانی نباید از این سیستم استفاده کنند؟

این سیستم محدودیت‌های خاصی دارد. نباید به عنوان یک آرشیو انطباق (Compliance Archive) استفاده شود زیرا فاقد امضاهای دیجیتال، همگام‌سازی ساعت (Clock Sync) و شناسیت بازبین است. مخازن تحت نظارت (Regulated Repositories) به ردپای سنگین‌تری نیاز دارند.

علاوه بر این، اسکریپت پارسر خاص یا مدل تهدید (Threat Model) یک پروژه را نمی‌فهمد؛ بلکه فقط بررسی می‌کند که فایل‌ها وجود داشته باشند و خالی نباشند. این اسکریپت جایگزینی برای اسکنرهای اجباری اسرار (Secret Scanners) نیست. در نهایت، الگوی جست‌وجو ممکن است اسراری را که شبیه کلمات معمولی هستند نادیده بگیرد و دفترچه ادعاها همچنان می‌تواند پر از دروغ‌های متقاعدکننده باشد. توسعه‌دهنده همچنان باید Diff را با چشمان خود بخواند.

تحلیل تحریریه

این رویکرد نشان‌دهنده حرکتی به سمت «ادغام دفاعی هوش مصنوعی» است. برای یک توسعه‌دهنده متوسط، این به معنای انتقال بار ذهنی از «اعتماد به هوش مصنوعی» به «تایید مصنوعات» (Verifying the Artifact) است. این متد می‌پذیرد که رابط چت یک «داستان» است، در حالی که سیستم فایل «حقیقت» است.

با تلقی کردن هوش مصنوعی به عنوان یک تولیدکننده پیشنهاد (Proposal Generator) به‌جای منبع حقیقت، این روش ریسک «بدهی فنی» ایجاد شده توسط توهمات مطمئن را کاهش می‌دهد. این سیستم توسعه‌دهنده را مجبور می‌کند تا بازیگر اصلی در حلقه باقی بماند و از هوش مصنوعی برای سرعت و از رسید برای ایمنی استفاده کند.

برای پیاده‌سازی این روش، با ایجاد یک prompt.txt برای اولین پچ تولید شده توسط هوش مصنوعی شروع کنید و پیش از فشردن دکمه Enter، یک grep ساده برای یافتن اسرار اجرا کنید. مشاهده کنید که وقتی نمی‌توانید ادعاهای «مطمئن» هوش مصنوعی را به یک مسیر تست متصل کنید، مجبور می‌شوید چه تعداد از آن‌ها را حذف کنید.

گام بعدی شما

• برای اولین پچ (Patch) بعدی که با هوش مصنوعی می‌سازید، یک فایل prompt.txt ایجاد کنید و پیش از ارسال، آن را برای یافتن اسرار (Secrets) جست‌وجو کنید.
• سعی کنید هر ادعای مدل را به یک دستور تست (Test Command) متصل کنید و ببینید چند درصد از ادعاهای «مطمئن» مدل را مجبور می‌شوید به دلیل نبود تست حذف کنید.
• اسکریپت receipt-check.sh را در محیط محلی خود پیاده کنید تا عادت به اعتبارسنجی سخت‌گیرانه جایگزین اعتماد حسی شود.

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