بازگشت به ابزارهای توسعه

Codex چیست؟ راهنمای ایجنت برنامه‌نویسی OpenAI

اگر پاسخ کوتاه می‌خواهید: Codex چیست؟ Codex ایجنت برنامه‌نویسی OpenAI است؛ یعنی به‌جای آن‌که فقط یک قطعه‌کد در چت تحویل بدهد، می‌تواند در محدوده‌ای که شما اجازه داده‌اید مخزن را بخواند، فایل‌ها را ویرایش کند، فرمان اجرا کند، تست بگیرد

·۱۲ دقیقه مطالعه
نمای مفهومی ایجنت برنامه‌نویسی Codex در کنار ترمینال و تغییرات Git

اگر پاسخ کوتاه می‌خواهید: Codex چیست؟ Codex ایجنت برنامه‌نویسی OpenAI است؛ یعنی به‌جای آن‌که فقط یک قطعه‌کد در چت تحویل بدهد، می‌تواند در محدوده‌ای که شما اجازه داده‌اید مخزن را بخواند، فایل‌ها را ویرایش کند، فرمان اجرا کند، تست بگیرد و نتیجه را به‌شکل توضیح و diff برای بازبینی برگرداند. مسئول تأیید نهایی کد همچنان شما هستید.

نکتهٔ کلیدی همین «ایجنت» است. Codex نام یک تجربه و مجموعه ابزار برای انجام کار مهندسی نرم‌افزار است، نه مترادف هر مدل پایه‌ای که پشت آن اجرا می‌شود. مدل، موتور استدلال است؛ CLI، افزونهٔ IDE، اپ و Cloud محیط‌هایی هستند که ایجنت در آن‌ها با کد و ابزارها کار می‌کند. قاطی‌کردن این دو، منشأ بخش بزرگی از توضیح‌های گیج‌کننده دربارهٔ Codex است.

نکات کلیدی:

  • Codex یک ایجنت کدنویسی است، نه صرفاً کامل‌کنندهٔ خودکار کد یا نام ثابت یک مدل.
  • برای کار مستقیم روی مخزن محلی، CLI یا افزونهٔ IDE مناسب‌تر است؛ Cloud کار را در محیط میزبانی‌شده انجام می‌دهد.
  • اولین اجرا را روی یک مخزن Git تمیز، با task کوچک و کمترین مجوز لازم انجام دهید.
  • خروجی ایجنت را مثل کد همکار تازه‌وارد بررسی کنید: git diff، تست و امکان rollback الزامی‌اند.

فهرست مطالب

Codex دقیقاً چیست و چه کاری می‌کند؟

Codex در تعریف کاربردی، عاملی نرم‌افزاری برای کار مهندسی است. شما یک نتیجهٔ مشخص می‌خواهید—مثلاً «برای این باگ تست بازتولید بنویس و کوچک‌ترین اصلاح را پیشنهاد کن»—و ایجنت برای رسیدن به آن، زمینهٔ مخزن را بررسی و ابزارهای مجاز را استفاده می‌کند. مستندات رسمی OpenAI توانایی‌های محوری آن را خواندن و ویرایش کد، اجرای فرمان و اعتبارسنجی تغییرات معرفی می‌کند. (راهنمای Codex، آخرین بررسی: ۲۶ ژوئیهٔ ۲۰۲۶)

این با یک پنجرهٔ چت معمولی فرق دارد. در چت، مدل اغلب کدی پیشنهاد می‌کند که شما باید خودتان در پروژه جای‌گذاری کنید. در گردش‌کار ایجنتی، Codex می‌تواند فایل درست را پیدا کند، تغییر را اعمال کند و تست مرتبط را اجرا کند—البته فقط در مرز دسترسی‌ای که محیط، sandbox و سیاست تأیید تعیین کرده‌اند.

سه لایه را جدا نگه دارید:

  1. محصول Codex: تجربهٔ ایجنتی و گردش‌کار برنامه‌نویسی.
  2. سطح استفاده: CLI، افزونهٔ IDE، اپ دسکتاپ یا محیط ابری.
  3. مدل: مدل قابل‌انتخاب یا پیشنهادی که استدلال و تولید کد را انجام می‌دهد.

مدل‌های در دسترس و پیش‌فرض ممکن است با نسخهٔ کلاینت، نوع ورود و سطح حساب تغییر کنند. بنابراین مقاله‌ای که می‌گوید «Codex همان مدل X است» احتمالاً خیلی زود کهنه می‌شود. فهرست جاری را باید در صفحهٔ رسمی مدل‌های Codex دید. آخرین بررسی: ۲۶ ژوئیهٔ ۲۰۲۶.

اگر هنوز در حال ساخت تصویر بزرگ‌تری از این حوزه هستید، راهنمای برنامه‌نویسی با هوش مصنوعی جای Codex را در کنار دستیارها، ایجنت‌ها و فرایند بازبینی توضیح می‌دهد.

سطوح Codex چه تفاوتی دارند؟

OpenAI، Codex را در چند سطح ارائه می‌کند. قابلیت‌ها و بلوغ هر سطح یکسان نیست و حتی فرمانی که امروز stable است ممکن است کنار یک قابلیت experimental قرار گرفته باشد. مرجع نهایی برای وضعیت فرمان‌ها، جدول رسمی فرمان‌های Codex است. آخرین بررسی: ۲۶ ژوئیهٔ ۲۰۲۶.

سطحکد کجا قرار دارد؟تعامل اصلیمناسب براینکتهٔ تصمیم
Codex CLIمخزن محلیترمینال، تعاملی یا اسکریپتیتوسعه‌دهنده‌ای که فرمان و مجوز دقیق می‌خواهدنزدیک‌ترین گزینه به گردش‌کار shell و Git
افزونهٔ IDEمخزن بازشده در ویرایشگرگفت‌وگو کنار کدکار روزمره و دیدن زمینه در ادیتوربرای اصلاح و بازبینی در همان محیط ویرایش
اپ دسکتاپworkspace محلی و تجربه‌های متصلرابط گرافیکی، برنامه‌ریزی و بازبینیمدیریت چند کار و دید بصری‌تر به تغییراتتنظیمات محلی را با CLI و IDE به اشتراک می‌گذارد
Codex Cloudcheckout در محیط میزبانی‌شدهٔ OpenAIواگذاری task و دریافت diffکارهای قابل‌واگذاری، موازی یا دور از دستگاه محلیاتصال مخزن و محیط Cloud لازم است

این جدول رتبه‌بندی نیست. اگر هر ده دقیقه می‌خواهید یک تابع را تغییر دهید، رفت‌وبرگشت به Cloud احتمالاً بی‌دلیل است. اگر task مستقلی دارید که می‌تواند در یک checkout جدا اجرا شود، محیط ابری مزیت پیدا می‌کند. برای انتخاب میان چند خانواده ابزار هم مقایسهٔ بهترین ابزارهای کدنویسی AI در ۲۰۲۶ را ببینید.

نظر تحریریه: بهترین سطح، آنی نیست که بیشترین دکمه را دارد؛ آنی است که مرز اثر تغییر را برای شما واضح‌تر می‌کند. در پروژهٔ حساس، مشاهدهٔ فوری diff و مسیر سادهٔ بازگشت از هر قابلیت نمایشی ارزشمندتر است.

Codex محلی و ابری چگونه اجرا می‌شوند؟

در CLI، افزونهٔ IDE و اپ دسکتاپ، ایجنت روی محیط محلی شما کار می‌کند و سیاست‌های سیستم‌عامل، sandbox و approval تعیین می‌کنند به چه فایل‌ها و فرمان‌هایی دسترسی داشته باشد. در حالت رایج workspace-write، نوشتن به workspace مجاز است اما دسترسی شبکه به‌صورت پیش‌فرض خاموش می‌ماند؛ خروج از محدوده می‌تواند به تأیید نیاز داشته باشد. (راهنمای رسمی امنیت و تأییدها، آخرین بررسی: ۲۶ ژوئیهٔ ۲۰۲۶)

Codex Cloud داستان دیگری دارد. طبق مستندات رسمی، سرویس یک container می‌سازد، نسخه‌ای از repo را روی branch یا commit انتخاب‌شده checkout می‌کند، setup script را اجرا می‌کند و سپس ایجنت در همان محیط فرمان می‌زند و تغییر را اعتبارسنجی می‌کند. در پایان، پاسخ و diff را می‌بینید و می‌توانید دربارهٔ PR یا ادامهٔ کار تصمیم بگیرید. دسترسی اینترنت مرحلهٔ agent به‌صورت پیش‌فرض خاموش است و جداگانه تنظیم می‌شود. (محیط‌های Codex Cloud، آخرین بررسی: ۲۶ ژوئیهٔ ۲۰۲۶)

پس «اجرای محلی» به معنی مدل محلی نیست. ممکن است کلاینت و ابزارها روی دستگاه شما باشند، اما احراز هویت و استنتاج مدل از سرویس OpenAI انجام شود. گزینه‌های مدل متن‌باز محلی نیز در CLI مستند شده‌اند، اما آن مسیر را نباید با تجربهٔ استاندارد Codex یکی گرفت. این تفکیک برای حریم خصوصی و معماری سازمانی مهم است.

شروع امن با Codex CLI

برای اولین تجربه، سراغ بازنویسی معماری یا migration پایگاه‌داده نروید. یک task کوچک و قابل‌سنجش بردارید: اصلاح یک پیام خطا، افزودن تست برای یک تابع خالص یا به‌روزرسانی مستندات کنار کد. بله، ایجنت ممکن است از پس کار بزرگ بربیاید؛ اما اولین ران جای نمایش شجاعت نیست.

گام ۱: پیش‌نیاز و نصب را از منبع رسمی بگیرید

روش نصب ممکن است تغییر کند. فرمان جاری را از quickstart رسمی Codex CLI بردارید و بعد نسخه و help محلی را بررسی کنید. آخرین بررسی: ۲۶ ژوئیهٔ ۲۰۲۶. مستندات فعلی نصب سراسری بستهٔ رسمی را نشان می‌دهند:

سپس در یک repo آزمایشی وارد شوید و codex را اجرا کنید. کلاینت مسیر ورود با ChatGPT یا API key را ارائه می‌کند؛ نوع دسترسی، مدل‌ها و صورتحساب این دو مسیر را یکی فرض نکنید. فایل اعتبارنامه را نیز مثل رمز عبور نگه دارید و هرگز آن را commit نکنید.

گام ۲: نقطهٔ بازگشت بسازید

پیش از دادن مجوز نوشتن، وضعیت مخزن را ببینید:

اگر تغییرات مهمِ commit‌نشده دارید، آن‌ها را ابتدا commit کنید یا task را در worktree/clone جدا اجرا کنید. rollback وقتی آسان است که بدانید کدام تغییر متعلق به ایجنت بوده است؛ در یک working tree شلوغ، این مرز محو می‌شود.

گام ۳: درخواست را با معیار پذیرش بنویسید

یک درخواست مناسب چنین اجزایی دارد:

  • محدوده: کدام فایل یا رفتار باید تغییر کند؛
  • ممنوعیت: چه API یا فایل‌هایی نباید عوض شوند؛
  • معیار پذیرش: دقیقاً چه تست یا نتیجه‌ای موفقیت است؛
  • خروجی: خلاصهٔ فایل‌های تغییرکرده، فرمان تست و ریسک باقی‌مانده.

نمونه:

نمونه codex exec برای یک کار واقعی

codex exec حالت غیرتعاملی CLI است و برای script، CI یا کارهایی مناسب است که از ابتدا باید با مجوز مشخص اجرا شوند. طبق مستندات فعلی، sandbox پیش‌فرض آن read-only است؛ برای ویرایش باید صریحاً workspace-write بدهید. فلگ قدیمی --full-auto فقط برای سازگاری باقی مانده و در script تازه نباید انتخاب اول باشد. (حالت غیرتعاملی Codex، آخرین بررسی: ۲۶ ژوئیهٔ ۲۰۲۶)

اول یک مرور فقط‌خواندنی بگیرید:

بعد، اگر پیشنهاد روشن و repo تمیز بود، task محدود را با اجازهٔ نوشتن در workspace اجرا کنید:

این یک آزمایش قابل‌تکرار برای خواننده است، نه ادعای آزمون تحریریه. نام تابع و فرمان تست را با repo خودتان تطبیق دهید. نتیجهٔ موفق فقط این نیست که Codex بگوید «انجام شد»؛ باید diff محدود، تست سبز و رفتار قابل‌مشاهده داشته باشید.

بلافاصله بعد از اجرا:

سپس test suite مناسب پروژه را خودتان دوباره اجرا کنید. اگر پروژه Node است شاید npm test باشد، اما از روی حدس فرمان نسازید؛ README، package.json یا دستورالعمل repo را بخوانید. اگر تغییر پذیرفتنی نبود، ابتدا diff را نگه دارید یا بررسی کنید، سپس با ابزار Git فقط فایل‌های متعلق به همین task را برگردانید. از فرمان‌های پاک‌کنندهٔ گسترده روی working tree مشترک استفاده نکنید.

قدم بعدی: همین حالا یک repo آزمایشی تمیز انتخاب کنید و دستور read-only بالا را اجرا کنید. هدف نخست «تولید کد بیشتر» نیست؛ هدف این است که ببینید Codex آیا می‌تواند محدوده، معیار پذیرش و ریسک task کوچک شما را درست بفهمد.

روش درست سپردن کار به Codex

Codex وقتی بهترین نتیجه را می‌دهد که مسئله شبیه ticket مهندسی خوب نوشته شده باشد. عبارت «این پروژه را بهتر کن» هم مبهم است و هم به ایجنت اجازه می‌دهد تعریف شما از «بهتر» را حدس بزند. حدس در طراحی رنگ شاید آزاردهنده باشد؛ در migration و auth می‌تواند گران تمام شود.

چرخهٔ پیشنهادی ما:

  1. Inspect: از ایجنت بخواهید ابتدا مسیر کد، تست‌ها و محدودیت‌ها را توضیح دهد.
  2. Plan: برای کار متوسط، plan کوتاه و فایل‌های احتمالی را قبل از ویرایش بگیرید.
  3. Edit: کوچک‌ترین تغییر لازم را با مرز صریح اعمال کنید.
  4. Verify: تست متمرکز و سپس بررسی گسترده‌تر را اجرا کنید.
  5. Review: git diff را خط‌به‌خط بخوانید؛ فقط خلاصهٔ ایجنت را نپذیرید.
  6. Accept or rollback: تغییر را commit کنید یا به‌صورت هدفمند برگردانید.

برای قواعد ماندگار repo—فرمان build، سبک کد، مسیرهای ممنوع و تعریف done—از AGENTS.md استفاده کنید. مستندات رسمی می‌گویند راهنمای نزدیک‌تر به فایل تغییرکرده اولویت دارد. (راهنمای رسمی AGENTS.md در Codex، آخرین بررسی: ۲۶ ژوئیهٔ ۲۰۲۶)

اگر می‌خواهید همین الگو را در ابزار دیگری ببینید، quickstart فارسی Claude Code نیز روی مجوز، تست و rollback تمرکز دارد. تفاوت برندها مهم است، اما انضباط مهندسی مهم‌تر است.

محدودیت‌ها و ریسک‌ها

Codex می‌تواند کد متقاعدکننده اما اشتباه تولید کند. ممکن است تست ناقص بنویسد، edge case را نبیند، از الگوی قدیمی repo تقلید کند یا فرمانی اجرا کند که اثر جانبی دارد. sandbox شعاع اثر را کم می‌کند؛ صحت منطقی را تضمین نمی‌کند.

موارد زیر را بدون بازبینی انسانی و کنترل اضافه به ایجنت نسپارید:

  • چرخاندن کلیدها، دسترسی production یا عملیات دادهٔ غیرقابل‌بازگشت؛
  • migration بدون backup و برنامهٔ rollback؛
  • تغییر احراز هویت، پرداخت یا رمزنگاری بدون review تخصصی؛
  • اجرای کد و dependency ناشناس با دسترسی شبکه و secrets؛
  • merge خودکار صرفاً بر اساس پیام نهایی ایجنت.

همچنین danger-full-access راه میان‌بُر روزمره نیست. مستندات آن را برای محیط کنترل‌شده، مانند runner یا container ایزوله، در نظر می‌گیرند. قاعدهٔ ساده: اگر task در workspace-write انجام نمی‌شود، اول بپرسید دقیقاً کدام دسترسی کم است؛ سپس همان یک مرز را باز کنید، نه همهٔ درها را.

برای دیدن تفاوت فلسفهٔ ابزارها و مدل‌های عمومی‌تر، مقایسهٔ ChatGPT و Claude برای کاربر فارسی مفید است. اگر مسئلهٔ شما مشخصاً دسترسی Claude از ایران است، راهنمای ریسک اکانت Claude ادعای «ریسک صفر» را نقد می‌کند؛ آن موضوع با دسترسی Codex یکی نیست.

جمع‌بندی: اولین task را کوچک انتخاب کنید

Codex یک مدل جادویی که پروژه را بدون نظارت تحویل دهد نیست. یک ایجنت مهندسی است که می‌تواند زمینه بخواند، تغییر بدهد و اعتبارسنجی کند—در صورتی که task، مجوز و معیار پذیرش را شما دقیق تعیین کنید. انتخاب میان CLI، IDE، اپ و Cloud باید از محل کد، نوع تعامل و سطح کنترل موردنیاز شروع شود، نه از فهرست بلند قابلیت‌ها.

CTA اصلی روشن است: یک branch تمیز بسازید، با codex exec فقط‌خواندنی از Codex بخواهید یک کار کم‌ریسک پیشنهاد دهد، سپس تنها یک تغییر محدود را با workspace-write اجرا کنید. git diff را بخوانید، تست را مستقل تکرار کنید و فقط اگر نتیجه قابل‌دفاع بود commit بزنید.

اگر هنوز آمادهٔ اجرای فرمان نیستید، قدم کم‌تعهد‌تر این است که task واقعی بعدی‌تان را در چهار خط بنویسید: محدوده، ممنوعیت، تست و تعریف done. همین تمرین، چه Codex را انتخاب کنید چه ابزار دیگر، کیفیت خروجی ایجنت را به‌وضوح بالا می‌برد.

پرسش‌های متداول

Codex چیست و چه فرقی با ChatGPT دارد؟

Codex تجربهٔ ایجنتی OpenAI برای کار مهندسی نرم‌افزار است و می‌تواند با مجوز شما فایل بخواند، تغییر اعمال کند و فرمان یا تست اجرا کند. ChatGPT یک محصول گفت‌وگومحور عمومی‌تر است؛ وجود Codex در برخی سطوح ChatGPT به این معنی نیست که هر گفت‌وگوی ChatGPT همان گردش‌کار ایجنتی Codex را دارد.

آیا Codex همان مدل هوش مصنوعی تولید کد است؟

نه به آن معنای ساده. Codex محصول و محیط ایجنتی است و می‌تواند از مدل‌های پشتیبانی‌شده استفاده کند. فهرست مدل‌ها جاری و وابسته به سطح استفاده و نوع احراز هویت است؛ صفحهٔ رسمی مدل‌ها را در روز استفاده بررسی کنید.

Codex CLI روی کد محلی کار می‌کند؟

بله، CLI در مخزن محلی شما فایل‌ها و فرمان‌ها را در محدودهٔ sandbox مدیریت می‌کند. «محلی‌بودن کلاینت» لزوماً به معنی اجرای محلی مدل نیست؛ این دو مفهوم را جدا کنید.

تفاوت Codex CLI و Codex Cloud چیست؟

CLI مستقیماً در محیط محلی و نزدیک به shell و Git شما کار می‌کند. Cloud یک checkout از repo را در container میزبانی‌شده اجرا می‌کند و در پایان diff ارائه می‌دهد؛ تنظیم محیط، اتصال مخزن و سیاست اینترنت آن مستقل است.

آیا codex exec بدون اجازه فایل‌ها را تغییر می‌دهد؟

طبق مستندات جاری، sandbox پیش‌فرض codex exec فقط‌خواندنی است. برای تغییر فایل باید مجوز مناسب، مانند --sandbox workspace-write، بدهید؛ بااین‌حال همیشه تنظیمات محلی و help نسخهٔ نصب‌شده را نیز بررسی کنید.

آیا می‌توان به کد تولیدشدهٔ Codex اعتماد کرد؟

برای پیشنهاد و تسریع کار، بله؛ برای merge بدون review، نه. diff، تست مستقل، بررسی امنیت و امکان rollback بخشی از تعریف done هستند، نه کارهای تزئینی بعد از آن.

بهترین اولین کار برای Codex چیست؟

کاری کوچک، برگشت‌پذیر و قابل‌تست: افزودن یک تست رگرسیون، اصلاح پیام خطا یا به‌روزرسانی مستندات نزدیک کد. اولین task نباید secrets، production، migration برگشت‌ناپذیر یا بازطراحی گسترده را درگیر کند.


کلادی یک مجله مستقل فارسی فناوری و هوش مصنوعی است. این مطلب بر پایهٔ مستندات رسمی OpenAI نوشته شده و قابلیت‌های جاری آن در ۲۱ ژوئیهٔ ۲۰۲۶ بررسی شده‌اند.

#Codex#OpenAI#ایجنت برنامه‌نویسی#ابزار توسعه
Share this article