اگر هر کار را با یک جملهٔ کوتاه به Claude Code (کلاد کد) بدهید، معمولاً به چیزی می‌رسید که «تقریباً درست» است. مشکل از مدل نیست؛ از نبود یک گردش‌کار توسعه با Claude Code است: نیازمندی روشن نشده، برنامه‌ای نوشته نشده، کسی کد را بازبینی نکرده و درس‌ها در حافظهٔ هیچ‌کس نمانده. گردش‌کار یعنی چند مرحلهٔ مشخص که هر کدام یک خروجی دارد و ورودی مرحلهٔ بعد است.
در این مقاله می‌خوانید چرا روند مهم است، یک حلقهٔ مشخص (brainstorm، plan، work، simplify، review، compound) شامل چه مرحله‌هایی است، برای چه اندازه کاری لازم است و برای چه کاری سربار، و چه عادت‌هایی از خود Claude Code (مثل plan mode و CLAUDE.md) از همین حالا کمک می‌کنند. در پایان یک آزمایش دوهفته‌ای برای سنجش اثر روند پیشنهاد می‌کنیم.
گردش‌کار را با Claude Code خودتان اجرا کنید
Claude Code را از داخل ایران با کلید نقطه وصل کنید؛ بدون فیلترشکن و کارت خارجی، با پرداخت ریالی و راه‌اندازی حدود ۵ دقیقه.
برای اینکه گردش‌کارتان با بسته شدن اکانت متوقف نشود، راهنمای Claude Code بدون بن شدن را بخوانید.
چرا بدون گردش‌کار نتیجه «تقریباً درست» می‌شود؟
سه خطای تکراری وقتی عامل بدون روند کار می‌کند:
- حدس‌زدن نیازمندی. عامل چیزی می‌سازد که شما نخواسته‌اید، چون سؤالی نپرسیده است.
- کد بدون بازبینی. تست می‌گذرد ولی طراحی ضعیف است.
- تکرار اشتباه. مشکلی که امروز حل شد، هفتهٔ بعد دوباره از صفر کشف می‌شود.
یک روند خوب این سه را با مرحله‌های جدا می‌بندد. اولی را با پرسش‌وپاسخ پیش از کدنویسی، دومی را با بازبینی جدا از اجرا، و سومی را با نوشتن درس‌ها در فایل‌هایی که دور بعد دوباره خوانده می‌شوند.
به‌جای ساختن روند از صفر، می‌توانید یک پلاگین آماده را امتحان کنید؛ البته اگر با مفهوم پلاگین و skill آشنا نیستید، اول راهنمای پلاگین، skill و MCP را بخوانید.
عادت‌های پایهٔ Claude Code که از همین حالا کمک می‌کنند
قبل از نصب هر چارچوبی، چند قابلیت داخلی خود Claude Code را بشناسید؛ مستندات رسمی آن‌ها را توضیح می‌دهد:
- Plan mode. حالتی که Claude اول فقط تحلیل و برنامه می‌دهد و تا تأیید شما تغییری نمی‌دهد. با
claude --permission-mode planشروع می‌شود یا در نشست با Shift+Tab تا نوار وضعیت «plan mode» را نشان دهد. CLAUDE.md. دستورهای ثابت پروژه (ساخت، تست، قراردادها) که هر نشست خوانده می‌شود./initیک نمونهٔ اولیه از روی ریپو می‌سازد.- مدیریت context.
/clearبین کارهای نامرتبط،/compactبا یک تأکید مشخص برای نشست‌های طولانی، و Esc وقتی دیدید Claude از مسیر خارج شد. مستندات توصیه می‌کند اولین دقیقه را تماشا کنید و اگر بعد از دو اصلاح هنوز اشتباه بود،/clearبزنید و درخواست بهتری بنویسید. /rewind. برگرداندن کد، گفتگو یا هر دو به یک نقطهٔ قبلی؛ این کار امتحان‌کردن رویکرد جسورانه‌تر را کم‌ریسک می‌کند.claude --worktree <name>. هر نشست در یک git worktree جدا کار می‌کند تا چند کار موازی ویرایش‌های هم را خراب نکنند.
با همین‌ها هم می‌شود روند ساده‌ای ساخت: plan mode برای برنامه، یک نشست تازه برای اجرا، یک نشست جدا برای بازبینی. چارچوب‌های آماده همین الگو را سازمان‌یافته‌تر می‌کنند و مرحلهٔ «ثبت درس» را اضافه می‌کنند.
چارچوب compound-engineering در یک نگاه
پلاگین compound-engineering از Every (ریپوی EveryInc/compound-engineering-plugin) طبق README رسمی «مجموعه‌ای از ۳۷ skill» است که کار را حول یک حلقه می‌چیند: brainstorm → plan → work → simplify → review → compound. README می‌گوید به‌جای روش سنتی که بیشترِ زمان صرف کدنویسی است، ۸۰٪ زمان در برنامه‌ریزی و بازبینی و ۲۰٪ در اجراست. ایدهٔ «compound» یعنی هر درس حل‌شده در docs/solutions/ ذخیره می‌شود تا دور بعد، brainstorm و برنامه‌ریزی از آن بخوانند.
اگر می‌خواهید همین پلاگین را نصب و حلقه را اجرا کنید، آموزش compound engineering در Claude Code نصب، شش دستور و احتیاط‌های /lfg را قدم‌به‌قدم می‌گوید؛ این مقاله اصل روند را مستقل از ابزار توضیح می‌دهد. حتی اگر این پلاگین را نصب نکنید، اصل حلقه به چارچوب خاصی وابسته نیست و می‌توانید همین مراحل را با دستورها و skillهای ساده خودتان بسازید.
plan mode و حلقه را روی ریپوی خودتان امتحان کنید
Claude Code با کلید نقطه از ایران وصل می‌شود؛ بعد همین مرحله‌ها را روی یک کار واقعی و چندفایلی اجرا کنید.
گردش‌کار توسعه با Claude Code: شش مرحلهٔ حلقه
| مرحله | دستور در README | خروجی |
|---|---|---|
| روشن‌کردن نیازمندی | /ce-brainstorm |
سند نیازمندی‌ها (پرسش‌وپاسخ تعاملی) |
| برنامه‌ریزی | /ce-plan |
برنامهٔ قابل‌اجرا در یک فایل |
| اجرا | /ce-work |
تغییرهای کد، با بررسی و commit |
| ساده‌سازی | /ce-simplify-code |
کد تمیزتر، حذف تست و کامنت بی‌ارزش |
| بازبینی | /ce-code-review |
گزارش بازبینی چنددیدگاهی (report-only) |
| ثبت درس | /ce-compound |
یادداشت در docs/solutions/ |
README حلقهٔ استاندارد را این‌طور نشان می‌دهد:
/ce-brainstorm make background job retries safer
/ce-plan
/ce-work
/ce-simplify-code
/ce-code-review
/ce-compound
هر دستور خروجی‌اش را به دستور بعدی می‌دهد؛ برنامه در یک فایل می‌ماند و رشد می‌کند، نه در حافظهٔ گفتگو. این نکته مهم است: وقتی نشست طولانی شود یا context پاک شود، برنامه از بین نمی‌رود.
چه زمانی روند کامل لازم است؟
| نوع کار | روند پیشنهادی |
|---|---|
| تغییر یک خط، تایپوی متن | مستقیم، بدون روند |
| باگ روشن و کوچک | توضیح باگ + بازبینی سریع |
| قابلیت جدید با چند فایل | brainstorm + plan + review |
| تغییر معماری یا مهاجرت | کل حلقه + ثبت درس |
روند کامل برای کارهای کوچک زمان هدر می‌دهد. قاعدهٔ سرانگشتی: اگر نتیجه را نمی‌توانید در دو جمله توضیح دهید، قبل از کد به برنامه نیاز دارید. برعکس، اگر تغییر آن‌قدر کوچک است که diff آن را یک نگاه می‌فهمد، روند اضافه فقط سربار است.
سناریوهای عملی
قابلیت جدید با چند فایل
مثلاً می‌خواهید تلاش مجدد (retry) کارهای پس‌زمینه را امن‌تر کنید. اگر مستقیم بگویید «retry را درست کن»، عامل ممکن است سیاست backoff را حدس بزند. با brainstorm، عامل می‌پرسد چه خطاهایی قابل تکرارند، حداکثر چند بار، و شکست نهایی کجا ثبت شود. جواب‌ها در سند نیازمندی می‌نشینند و برنامه از همان شروع می‌شود.
باگ تازه‌کشف‌شده
برای باگ، README مسیر جدا دارد: /ce-debug که علت را پیدا می‌کند، و حالت خودکار /lfg که مسیر تا ساخت و بازبینی را بی‌وقفه می‌رود. با این حال برای باگ کوچک و روشن، توضیح مشکل به Claude و یک بازبینی سریع معمولاً کافی است.
مهاجرت یا تغییر معماری
اینجا هزینهٔ اشتباه بالاست، پس کل حلقه و ثبت درس می‌ارزد. مهاجرت‌ها اغلب چند ساعت یا روز طول می‌کشند و نشست‌ها پاک می‌شوند؛ برنامهٔ ذخیره‌شده در فایل باعث می‌شود نشست بعدی از همان‌جا ادامه دهد.
یک نمونهٔ فرضی قدم‌به‌قدم
برای روشن‌شدن حلقه، فرض کنید می‌خواهید در یک سرویس، تلاش مجدد کارهای پس‌زمینه را امن‌تر کنید. این مثال فرضی است و فقط ترتیب مرحله‌ها را نشان می‌دهد:
- brainstorm: با
/ce-brainstormهدف را می‌نویسید. عامل می‌پرسد کدام خطاها قابل تکرارند، حداکثر چند بار، فاصلهٔ بین تلاش‌ها چقدر است و شکست نهایی کجا ثبت شود. جواب‌ها در یک سند نیازمندی می‌نشینند. - plan: با
/ce-planهمان سند به برنامهٔ اجرایی تبدیل می‌شود: کدام فایل‌ها عوض می‌شوند، چه تست‌هایی لازم است، چه ریسکی هست. - work:
/ce-workبرنامه را اجرا می‌کند. شما در این مرحله کمتر دخالت می‌کنید، چون تصمیم‌های اصلی از قبل گرفته شده‌اند. - simplify و review: کد تازه ساده می‌شود و بعد گزارش بازبینی می‌آید. تصمیم دربارهٔ اعمال هر پیشنهاد با شماست.
- compound: اگر در مسیر چیز غیرواضحی کشف شد (مثلاً یک تله در پیکربندی)،
/ce-compoundآن را درdocs/solutions/می‌نویسد.
README نشان می‌دهد این درس‌ها در دورهای بعد وارد برنامه‌ریزی می‌شوند: همان نقطهٔ «compound» که روند را از یک چک‌لیست ساده متمایز می‌کند.
اگر حلقهٔ سبک خودتان را بخواهید
لازم نیست پلاگینی نصب کنید تا از اصل ایده بهره ببرید. یک نسخهٔ سبک می‌تواند این‌طور باشد: در CLAUDE.md بنویسید که برای هر قابلیت چندفایلی، اول در plan mode نیازمندی را با شما روشن کند؛ برنامه را در یک فایل مثل docs/plans/ بنویسد؛ بعد از اجرا، در یک نشست جدا فقط diff را بازبینی کند؛ و اگر مشکل غیرواضحی حل شد، یک یادداشت کوتاه در پوشهٔ درس‌ها بگذارد. این نسخه خودکار نیست و نظم آن به عهدهٔ شماست، ولی برای شروع و برای فهمیدن اینکه چه چیزی در روند به دردتان می‌خورد کافی است.
حالت خودکار و محدودیت‌هایش
README برای مواقعی که نمی‌خواهید خودتان هر مرحله را صدا بزنید، /lfg را معرفی می‌کند: مسیر تا یک منبع کار تأییدشده (برنامه یا یک اصلاح باگ) را می‌رود، کد را ساده می‌کند، بازبینی می‌کند، درس ماندگار را ثبت می‌کند و وقتی remote گیت باشد می‌تواند push و PR هم بزند. چنین حالتی برای کارهایی خوب است که نیازمندی‌شان از قبل روشن است. برای کار مبهم، حالت تعاملی brainstorm هنوز ارزش دارد، چون پرسش‌ها را شما جواب می‌دهید، نه عامل.
موازی‌سازی کارها
وقتی چند کار مستقل دارید، claude --worktree <name> هر نشست را در یک checkout جدا و روی شاخهٔ خودش اجرا می‌کند تا ویرایش‌ها با هم تداخل نکنند (طبق مستندات، ریپو باید حداقل یک commit داشته باشد). این با حلقه سازگار است: هر worktree می‌تواند برنامهٔ خودش را داشته باشد.
نکته‌های عملی
- برنامه در فایل باشد. هر چیزی که فقط در گفتگو باشد با پایان نشست گم می‌شود.
- بازبینی را به عامل جدا بسپارید. README
/ce-code-reviewرا «report-only» (فقط گزارش) توصیف می‌کند؛ اعمال اصلاح‌ها جداگانه و صریح است. - درس‌ها را کوتاه بنویسید.
/ce-compoundوقتی به درد می‌خورد که مشکل واقعاً غیرواضح بوده، نه برای هر باگ ساده. - هزینه را در نظر بگیرید. روند کامل چندین عامل و فراخوانی را اجرا می‌کند؛ مصرف توکن بیشتر از «یک درخواست ساده» است. با اندازه‌گیری مصرف ببینید.
- ابزار فهم کد را اضافه کنید. مرحلهٔ برنامه‌ریزی وقتی بهتر می‌شود که عامل ساختار ریپو را واقعاً بداند؛ دربارهٔ این موضوع مقالهٔ Context7 و CodeGraph را ببینید.
اشتباهات رایج
- اجرای کل حلقه برای کار کوچک. نتیجه: ساعت‌ها صرف سند و برنامه برای تغییری که پنج دقیقه کار بود.
- رد کردن مرحلهٔ brainstorm برای کار مبهم. برنامهٔ دقیق روی نیازمندی غلط، فقط غلط را سریع‌تر می‌سازد.
- نوشتن درس برای هر چیز. اگر پوشهٔ درس‌ها پر از یادداشت‌های بی‌ارزش شود، دور بعد خواندنش هم سربار می‌شود.
- نشست طولانی بدون پاک‌سازی. وقتی کار عوض می‌شود
/clearبزنید؛ context قبلی هزینه دارد و حواس مدل را پرت می‌کند. - اعتماد کامل به بازبینی عامل. بازبینی خودکار ابزار کمکی است، نه جایگزین دیدن diff توسط خودتان.
یک آزمایش دوهفته‌ای
پیشنهاد ما: روند را دو هفته روی یک پروژهٔ واقعی امتحان کنید و نتیجه را با روش قبلی‌تان مقایسه کنید. معیار ساده: تعداد دفعاتی که بعد از «تمام شد» مجبور شدید برگردید و چیزی را اصلاح کنید. اگر کم شد و زمان کل خیلی بالا نرفت، روند کار کرده است. اگر زمان بالا رفت ولی بازگشت‌ها کم نشد، احتمالاً روند را برای کارهای کوچک هم به کار برده‌اید.
اگر همهٔ ابزارهای این مجموعه (از فهم کد تا نصب پلاگین‌ها) را می‌خواهید یک‌جا راه بیندازید، راهنمای نصب ابزارهای Claude Code کمک می‌کند. تصویر کلی از اکوسیستم هم در راهنمای کامل Claude Code است.
جمع‌بندی
روند را به اندازهٔ کار انتخاب کنید: کار کوچک مستقیم، کار بزرگ با حلقه. برنامه و درس‌ها را در فایل نگه دارید نه در گفتگو، بازبینی را از اجرا جدا کنید، و یک چارچوب را کامل امتحان کنید قبل از اینکه دربارهٔ آن قضاوت کنید. نیمه‌کاره امتحان‌کردن یک روند، معمولاً فقط هزینهٔ آن را نشان می‌دهد و فایده‌اش را نه؛ فایدهٔ اصلی وقتی دیده می‌شود که درس‌های دور اول در دور دوم خوانده شوند.
کلید API نقطه با پلن پرو باز می‌شود
روند کامل چند فراخوانی دارد؛ با داشبورد زندهٔ نقطه مصرف هر درخواست و سهمیهٔ باقی‌مانده را می‌بینید و با یک کلید به Sonnet و Opus می‌رسید.
این مقاله چگونه بررسی شد؟
دستورها و ویژگی‌ها از README رسمی compound-engineering (EveryInc/compound-engineering-plugin) و برای مفاهیم Claude Code (plan mode، CLAUDE.md، مدیریت context، worktree) از مستندات code.claude.com برداشته شد و در ۱۳ آبان ۱۴۰۵ (۴ نوامبر ۲۰۲۶) دوباره با نسخهٔ فعلی مقایسه شد. تعداد ستاره از API گیت‌هاب همان روز آمده است. اگر دستوری در نسخهٔ شما فرق داشت، README و مستندات همان نسخه معتبرتر است.
← راهنمای کامل · فهم کد
منابع: README رسمی compound-engineering، Common workflows، Best practices، Memory. تاریخ بررسی: ۱۳ آبان ۱۴۰۵ (۴ نوامبر ۲۰۲۶).
