پلی‌بوک توسعه: انتقال زمینه پروژه‌ها از چت به زیرساخت کنترل نسخه

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

به نقل از یک تحلیل فنی مفصل که در ۲۹ ژوئیه ۲۰۲۶ منتشر شد، تکرار بلوک‌های متنی در پرامپت‌ها یک مشکل مهندسی پرامپت نیست، بلکه یک مشکل نرم‌افزاری است. نویسنده استدلال می‌کند که توسعه‌دهندگانی که به جای ساختار، به کپی-پیست متکی هستند، در واقع یک زیرساخت متزلزل خلق می‌کنند. راهکار این است که این دستورات تکراری به یک «کتابچه راهنمای توسعه» (Development Playbook) تبدیل شوند تا کفِ کیفیتِ کارهای عامل‌محور (Agentic) به‌صورت بنیادین ارتقا یابد.

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

ساخت لایه تاییدیه

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی مدیریت زمینه در مدل‌های زبانی اشاره کردیم، مشکل اصلی نبودِ حافظه نیست، بلکه نبودِ ساختار برای بازیابی آن است. طبق گزارش وب‌سایت dev.to، نخستین گام برای ایجاد زیرساخت ماندگار هوش مصنوعی، تدوین اسناد فرآیندی (Process Docs) است. این اسناد که در مارس ۲۰۲۶ — پیش از رسمی شدن کتابخانه‌های مهارت یا ساخت حلقه‌ها — تدوین شده‌اند، راهنماهای ساده‌ای به زبان انگلیسی هستند که هم‌راستای کد ذخیره می‌شوند و تعریف می‌کنند که کار چگونه از یک ایده به یک عرضه (Release) تبدیل شود. این اسناد در واقع یک کتابچه راهنما برای شفاف‌سازی مسئله، طراحی رفتار، تجزیه کار به بخش‌های کوچک‌تر، پیاده‌سازی، تایید و در نهایت تصمیم‌گیری درباره آماده بودن برای ارسال فراهم می‌کنند.

به جای دستورات مبهم، این سیستم از یک گراف وظیفه (Task Graph) استفاده می‌کند. گراف وظیفه — شبیه نقشه‌ای است که هر پیچ و خم پروژه و پیش‌نیازهایش را مشخص کرده تا هیچ مرحله‌ای بدون تایید قبلی رد نشود — یک برنامه کاری ساختاریافته است که هر وظیفه، وابستگی‌ها و شرایط صریح پذیرش یا رد (Pass-or-Fail) را ترسیم می‌کند. این روش تصمیمات را پیش از شروع پیاده‌سازی به فضای باز می‌آورد و با پاسخ به سوالات کلیدی، ابهام را می‌زداید: چه مشکلی را حل می‌کنیم؟ چه چیزهایی در محدوده پروژه هستند؟ کاربر باید بتواند چه کارهایی انجام دهد؟ کدام موارد حاشیه‌ای (Edge Cases) اهمیت دارند؟ چه اثباتی باید وجود داشته باشد تا کار به مرحله بعد برود؟

در این مدل، یک وظیفه صرفاً به دلیل وجود کد، «تمام‌شده» تلقی نمی‌شود. بلکه تنها زمانی تکمیل می‌شود که معیارهای پذیرش خاص آن وظیفه پاس شود. این رویکرد یک زنجیره ارزیابی چندلایه می‌سازد:

• تست‌های واحد و قرارداد (Unit and Contract Tests): بررسی دقیق نیازهای تک‌تک اجزا.
• تست‌های یکپارچه‌سازی (Integration Tests): اطمینان از اینکه یک فاز از پروژه به عنوان یک سیستم واحد به‌درستی کار می‌کند.
• سناریوهای End-to-End و بازبینی انسانی: تایید اینکه کاربر واقعاً می‌تواند گردش کاری را که در طراحی وعده داده شده بود، به پایان برساند.

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

از پرامپت‌های ذخیره‌شده تا مهارت‌های عامل

در حالی که کتابچه‌های راهنما «چرا» و «هدف» را مدیریت می‌کنند، «چگونه» کار کردن از طریق یک کتابخانه مهارت‌ها (Skills Library) مدیریت می‌شود. بر اساس قاعده کلی در Claude Code، هرگاه یک رویه تکراری — مثلاً نحوه استارت زدن یک اپلیکیشن، مواردی که یک بازبینی فرانت‌اند باید فراتر از رندرینگ بررسی کند، یا نحوه ثبت تاریخ‌ها در یک مرحله پژوهشی — مدام در چت‌ها کپی و پیست شود، باید برای آن یک «مهارت» تعریف کرد.

برخلاف یک پرامپت ذخیره شده که فقط کلمات را حفظ می‌کند، یک مهارت، «روش کار» را حفظ می‌کند. بر اساس استاندارد بازِ مهارت‌های عامل (Agent Skills)، یک مهارت شامل دستورالعمل‌ها، اسکریپت‌ها، مثال‌ها و معیارهای موفقیت است که در یک پوشه قابل انتقال قرار می‌گیرد و هرگاه عامل با وظیفه‌ای متناسب با آن مواجه شود، آن را بارگذاری می‌کند. این کار توسعه‌دهنده را مجبور می‌کند به سوالات حیاتی پاسخ دهد: چه چیزی این مهارت را فعال (Trigger) می‌کند؟ چه بخش‌هایی می‌توانند متغیر باشند؟ عامل اجازه دارد چه تصمیماتی را به‌طور ایمن بگیرد؟ چه کسی مسئول نگهداری و به‌روزرسانی این مهارت است؟

با این حال، مهارت‌ها باید مانند نرم‌افزارهای معمولی نگهداری شوند، چون دستورات تغییر می‌کنند و فرض‌های اولیه منقضی می‌شوند. تحقیقات روی مهارت‌های عمومی نشان می‌دهد ریسک‌هایی مانند تزریق پرامپت (Prompt Injection) و رویه‌هایی که قادر به تغییر وضعیت سیستم هستند، همچنان وجود دارند. یک مهارت بازبینی می‌تواند ثبات یک بازبینی را بهبود ببخشد، اما نمی‌تواند تصمیم بگیرد کدام درخواست تغییر (Pull Request) بیشترین اهمیت را دارد یا آیا یک تغییر خاص از هدف کلی محصول پشتیبانی می‌کند یا خیر.

مخزن به عنوان حافظه مشترک

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

با تبدیل Git و GitHub به سطح اصلی کار، وضعیت پروژه از طریق مصنوعات (Artifacts) زیر بیرونی می‌شود:

• راهنمای آنبوردینگ: توضیح محصول، ماموریت و قوانین کار.
• نقشه راه (Roadmap): ثبت اولویت‌ها.
• نقشه‌های دستور (Command Maps): به‌روز نگه داشتن دستورات اجرا و تست.
• اسناد طراحی: ثبت رفتارهای مورد انتظار و تحلیل سبک-سنگین کردن‌ها (Trade-offs).
• گراف‌های وظیفه: تبدیل نسخه‌ها به گام‌های وابسته و قابل تست.
• Issueها: انتقال کارهای محدودشده (Scoped Work) بین جلسات.
• Pull Requestها: انتقال تغییرات و مدارک لازم (Proof) برای بازبینی.

در این سیستم، اسناد توضیحات پس‌رویدادی نیستند که بعد از اتمام کار نوشته شوند، بلکه بخشی از نحوه عملیاتی شدن کار هستند. ابزارهایی مثل Codex، Claude Code یا هر ابزار دیگری، صرفاً «هارنس» یا اجراکننده عامل هستند، در حالی که مخزن پروژه، زمینه لازم برای بازرسی، تولید، تایید و تحویل را فراهم می‌کند.

حرکت به سوی حلقه‌های فعال

حافظه مشترک نقشه را می‌دهد، اما حرکت را نه. یک فرآیند مستند شده باز هم می‌تواند منجر به Pull Requestهای قدیمی، شکست در تحریک بهبودها یا از دست دادن ریتم بازبینی‌های دوره‌ای قابلیت‌ها شود، اگر انسانی نباشد که متوجه شود چه زمانی حافظه باید به عمل تبدیل شود.

برای حل این مشکل، تکامل بعدی شامل «حلقه‌ها» (Loops) است. این حلقه‌ها برای مشغول نگه داشتن عامل‌ها طراحی نشده‌اند، بلکه برای فراهم کردن کارهای تکراری در یک چارچوب ساختاریافته هستند:

• یک محرک مشخص (Trigger): برای شروع حلقه.
• یک خروجی شفاف: برای تعریف موفقیت.
• یک بررسی نتیجه: برای تایید خروجی.
• یک نقطه توقف: برای جلوگیری از چرخه‌های بی‌نهایت.
• نقاط تصمیم‌گیری انسانی: برای زمان‌هایی که قضاوت حرفه‌ای و انسانی لازم است.

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

گام بعدی شما

• بررسی کنید کدام دستورات را در هر جلسه چت تکرار می‌کنید و آن‌ها را به اسناد متنی در ریشه پروژه منتقل کنید.
• برای وظایف پیچیده، به‌جای یک پرامپت طولانی، یک «گراف وظیفه» با معیارهای پذیرش صریح (Pass/Fail) بنویسید.
• مهارت‌های تکراری خود را در پوشه‌های مجزا با اسکریپت و مثال ذخیره کنید تا عامل‌ها بتوانند آن‌ها را به‌صورت پویا بارگذاری کنند.

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