تشغيل المهمة الأولى
📚 تنقل السلسلة: المقال السابق 05 · ربط نماذج الذكاء الاصطناعي المحلية مثل DeepSeek أوضح مسار ربط نماذج الطرف الثالث. وتنتهي هنا أقسام التكوين والإعدادات — ليبدأ هذا المقال بالتطبيق العملي الفعلي، وتوجيه Codex لتعديل الأكواد عمليًا ومراجعة الفروق (diff) لاعتماد التعديلات. المقال التالي 07 · تفاصيل تطبيق سطح المكتب سيقدم جولة شاملة في نسخة سطح المكتب.
أيها الأصدقاء، دعوني أبدأ بمشاركة حماقة ارتكبتها بنفسي عند بدء استخدام Codex لأول مرة.
كان ذلك في الليلة الأولى بعد تثبيت Codex CLI، وكنت متحمسًا لتجربة قدرته على تعديل الأكواد. فتوجهت مباشرة بالأمر cd لمستودع رئيسي في الشركة يعمل منذ سنتين ويضم مئات الملفات، ووجهت له أمرًا جافًا «قم بإعادة هيكلة وحدة المستخدمين (users module)، فهي مبعثرة للغاية». بدأ Codex بقراءة الملفات لثوانٍ، وامتلأت الشاشة بالأسطر البرمجية بشكل أذهلني، ثم قدم كمًا هائلاً من التعديلات — توزعت على سبعة أو ثمانية ملفات. قلت لنفسي حينها «لا بأس، سيعمل الأمر بالتأكيد»، ووافقت مباشرة دون قراءة التفاصيل أو التحقق.
والنتيجة؟ لقد قام بـ «إعادة الهيكلة» بالفعل، ولكنه قام بتعديل واجهتين (interfaces) لم أطلب منه لمسهما إطلاقًا، لتفشل جميع الاختبارات المحلية وتظهر باللون الأحمر فورًا. وقضيت ما يقرب من ساعة كاملة في تتبع الأكواد سطرًا بسطر وتحديد التعديلات المقبولة والتراجع عن التعديلات الأخرى. والدرس الأهم الذي تعلمته في تلك الليلة لم يكن «عجز Codex»، بل كان «إهمالي للخطوة الأهم — مراجعة الفروق (diff)».
وبكل صراحة، أهم ما أسعى لتقديمه لك في هذا المقال هو الالتزام بهذه الخطوة. لن نتعامل اليوم مع مشاريع حقيقية، بل سننشئ مشروعًا مبسطًا يضم ثلاثة أسطر فقط، ونطبق خلال خمس دقائق مسار العمل بالكامل «توجيه المتطلبات ← قيام Codex بالتعديل في البيئة المعزولة ← مراجعة الفروق (diff) للاعتماد ← الحفظ أو التراجع»، لتشهد بنفسك قدرة Codex على التعديل السليم مع إشرافك الكامل على العملية. وسنطبق التمرين العملي بـ CLI وتطبيق سطح المكتب معًا.
بعد قراءة هذا المقال، ستحصل على:
- مسار كامل وواضح يبدأ من فتح الطرفية أو التطبيق لتشغيل المهمة الأولى بنجاح.
- ترسيخ خطوة «مراجعة الفروق (diff)» كعادتك الأساسية — فهي الفارق الجوهري بين المبتدئين والمحترفين.
- خطوات تفصيلية لتشغيل المسارين (CLI وتطبيق سطح المكتب) مع توضيح المخرجات المتوقعة لتأكيد النجاح بنفسك.
- تنبيهات هامة لتفادي الأخطاء الشائعة (كيفية التوجيه بعد الرفض، وكيفية التراجع عند وجود خلل).
01 تجنب استخدام المشاريع الحقيقية في البداية، وابدأ بمشروع مبسط
الخلاصة أولاً، وهي درس تعلمته بعد ساعة من العمل الشاق: عند استخدام Codex للمرة الأولى، تجنب تمامًا تطبيقه على مستودعاتك الحقيقية، وابدأ بمشروع تجريبي بسيط يضم ثلاثة أسطر فقط.
والسبب؟ يوضح المثال السابق الفشل بوضوح — فالمشاريع الحقيقية تضم ملفات واعتمادات متشابكة، ويستغرق Codex وقتًا طويلاً لقراءتها، ولن تتمكن من مراجعة تفاصيل جميع التعديلات، وفي حال «تعذر المراجعة الشاملة» ستميل للموافقة العشوائية وتخطي الفحص. أما في المشاريع التجريبية التي تضم سطرين أو ثلاثة، فستلاحظ كل حرف يقوم بتعديله بوضوح، وهو المناسب للتطبيق والتدريب.
تشبيه: تعلم ركوب الدراجة الهوائية. لن تذهب لركوب الدراجة في الطرق الرئيسية السريعة في ساعات الازدحام أولاً — بل ستبحث عن زقاق هادئ وخالٍ من المارة، ليتسنى لك التدريب على التوازن واستخدام المكابح دون خوف من الوقوع. المشروع التجريبي هو هذا الزقاق الهادئ: حدت مشكلة أو عطل؟ احذف المجلد وأعد إنشائه في نصف دقيقة دون قلق.
من يجب عليه الالتزام بهذه النصيحة بشكل خاص:
- من يفتقر للخبرة في استخدام سطر الأوامر (CLI) — فمشاهدة أسطر قراءة الملفات المتسارعة لـ Codex لثوانٍ تثير القلق للمبتدئين، وتجنب إضافة ضغط «تعديل مشروع حقيقي» لعمليتك.
- من ينتقل من أدوات أخرى — مثل المعتادين على استخدام Claude Code، بظن أن طريقة العمل متطابقة بالكامل، لتفاجأ بوجود فوارق في حدود البيئة المعزولة وسياسات الموافقة (وهذا ما تم التنبيه إليه في المقالين 02 و05)؛ لذا يفضل استكشاف الأداة وتدريبها أولاً.
- من يرغب في إنجاز مهامه بسرعة — فالسرعة تتطلب تشغيل المسار المبسط أولاً والتأكد من استقرار الربط لتفادي وقوع المشاكل لاحقًا وتوفير الوقت.
افتح الطرفية (برنامج Terminal على Mac، أو PowerShell على Windows) وشغل الأمرين التاليين لإنشاء مجلد تجريبي والدخول إليه:
mkdir hello-codex
cd hello-codexويعني هذا: إنشاء مجلد جديد باسم hello-codex والدخول إليه. ويمثل mkdir اختصارًا لـ (make directory)，ويمثل cd اختصارًا لـ (change directory).
بعد ذلك، أضف ملف Python مبسطًا للمجلد. على نظام Mac / Linux:
echo 'def add(a, b):
return a + b' > main.pyوعلى نظام Windows PowerShell، يفضل فتح المفكرة وإنشاء ملف باسم main.py يضم الكود التالي وحفظه:
def add(a, b):
return a + b💡 الخلاصة في جملة واحدة: عند استخدام Codex للمرة الأولى، ابدأ بمشروع تجريبي بسيط يضم ثلاثة أسطر فقط — لتتمكن من مراجعة كل تفصيل، وإعادة البناء بسهولة ودون قلق عند وجود أي خلل。
02 صياغة المتطلبات بوضوح: حلقة «التفكير ← التنفيذ ← المراجعة» لـ Codex
بعد إعداد المجلد، تريث لدقيقة قبل البدء لتحديد: ما المهمة المطلوبة منه بالضبط، وكيف ستشرحها له。
والسبب؟ لأن Codex ليس بئر أمنيات — فجودة المدخلات تحدد جودة النتائج حتمًا. وأشرنا في المقال 02 نظرة سريعة على المفاهيم الأساسية لكونه وكيلًا (Agent)، ويعتمد في عمله على حلقة متكررة: يستدعي النموذج، ينفذ الإجراءات المقترحة (قراءة وتعديل الملفات واستدعاء الأدوات)، ويستمر في العمل حتى الانتهاء أو إلغاء المهمة. وتتمثل الحلقة في: التفكير ← التنفيذ ← المراجعة。
تشبيه: تكليف مقاول بأعمال صيانة. توجيهه بـ «رتب الغرف قليلاً» يجعله يعتمد على حدسه الخاص وغالبًا لن تنال النتيجة رضاك؛ بينما توجيهه بـ «اطلي جدران الغرفة الرئيسية باللون البيج، وأضف حوض غسيل في الشرفة، وأتم العمل قبل الجمعة القادمة» يوضح له المهام بدقة ليلتزم بها ويراجعها. وكلما كانت متطلباتك محددة وتضم شروطًا واضحة للانتهاء، التمت الوكيل بالمسار الصحيح دون أخطاء。 وتنص الوثائق الرسمية في صفحة التوجيه (Prompting) على نصيحتين هاماتين:
- دعم التحقق الذاتي للوكيل: تضمين المتطلبات لخطوات الفحص والاختبارات المطلوبة أو lint، يساعد Codex في إحصاء جودة المخرجات والتحقق منها ذاتيًا.
- تفكيك المهام الكبيرة لخطوات بسيطة: تقسيم المهام المعقدة لخطوات محددة يسهل تشغيلها واختبارها؛ وإذا كنت تواجه صعوبة في تقسيم المهمة، فاطلب من Codex كتابة اقتراح وخطة عمل (plan) أولاً。
نوضح الفروق بين التوجيهات الغامضة والتوجيهات المحددة في هذا الجدول:
| ❌ توجيهات غامضة | ✅ توجيهات محددة |
|---|---|
| «帮助我优化这个函数» | «أضف معاملات الأنواع (type annotations) لدالة add، واجعلها تطلق خطأ TypeError عند تمرير قيم غير رقمية» |
| «测试为什么挂了» | «شغل أمر pytest وحدد سبب الفشل，然后修好后再跑一遍确认全绿» |
| «重构一下项目» | «لا تقم بالتعديل مباشرة، واعرض لي خطة إعادة الهيكلة أولاً لمراجعتها واعتمادها قبل البدء» |
التوجيه الأخير هو المفضل لدي للتطوير — فعند البدء بمهام واسعة، أكتب دائمًا «اعرض لي خطة العمل أولاً، ولا تلمس الملفات»。这是我从开头那场翻车里学乖的：让它先把计划摆出来，我审一遍方向，再放它动手，比它闷头改完我再收拾残局强太多。
💡 الخلاصة في جملة واحدة: يعمل Codex في حلقة «التفكير ← التنفيذ ← المراجعة»، وكلما كانت متطلباتك محددة وتضم شروطًا واضحة للانتهاء، قل احتمال ارتكابه للأخطاء；大活先让它出方案，别一上来就让它埋头改。
03 المهمة الأولى: القراءة دون التعديل لتأكيد ربط الملفات
解释，而不是改代码**。
为什么先解释？两个实在的理由：一是确认 Codex 真读到了你的文件，而不是在凭空瞎编（新手最大的疑虑就是「它到底看没看我代码」）；二是解释类任务零风险——它只读、只说，不动你一个字，最适合第一次试水。
تشبيه: انضمام زميل جديد للفريق. لن تبدأ بتسليمه الوحدات الرئيسية للمشروع لتعديلها في يومه الأول — بل ستطلب منه قراءة الأكواد وشرح فهمه لهيكل المشروع أولاً لتثق في قدراته. وتوجيه Codex لشرح الأكواد يماثل هذا التقييم ليومه الأول。
اكتب التوجيه التالي باللغة الطبيعية في صندوق الإدخال سواء كنت تستخدم CLI أو التطبيق:
اشرح دور الأكواد في ملف main.py بلغة مبسطة ومفهومة للمبتدئيناضغط على زر الإدخال (Enter). سيقوم Codex بقراءة ملف main.py ذاتيًا — دون الحاجة لنسخ الأكواد وإرفاقها يدويًا，它在代理循环里自己就把相关文件读了。然后它给你一段大白话，大意是：这里定义了一个 add 函数，收两个参数 a 和 b ，返回它俩相加的结果。
这一步跑通，意味着两件事成立了：Codex 装对了、登录态正常，而且它确实在读你机器上的真实文件。地基稳了，下一步才敢放它动手。
نوضح الفئات الثلاث للمهام في هذا الجدول:
| نوع المهمة | الإجراء والهدف | مثال | مستوى المخاطرة |
|---|---|---|---|
| الشرح والقراءة | قراءة وفهم الأكواد وتوضيحها لك | «اشرح دور هذه الأكواد» | آمن تمامًا، لا يعدل الملفات |
| التعديل | 外加修改现有代码 | «أضف معاملات الأنواع لهذه الدالة» | يعدل الملفات، يتطلب مراجعة diff |
| التوليد والإنشاء | 让它写新东西 | «أضف اختبارات فحص جديدة للدالة» | ينشئ ويعدل ملفات، يتطلب مراجعة diff |
对于陌生项目，我每进一个项目，第一句都是「先帮我理一遍这个项目的结构」。一来确认 Codex 读得到、读得对；二来它理出来的结构图，常常比我自己翻半天还清楚——这是解释型任务白送的福利。
💡 الخلاصة في جملة واحدة: وجه الأداة في المهمة الأولى لـ «الشرح والقراءة» لتجربتها — لتأكيد ربط وقراءة الملفات المحلية واستقرار العمل أولاً، ثم ابدأ بالتعديل لاحقًا；ومهمات التعديل والإنشاء تتطلب حتمًا التزامك بمراجعة الفروق (diff)。
04 الخطوة الأساسية: مراجعة الفروق diff (القسم الأهم في المقال)
نبدأ الآن بالتطبيق العملي: توجيه Codex لتعديل الأكواد بالفعل. ويمثل هذا القسم عصب العملية بالكامل، وتفاديه سبب عناء عملي لساعة كاملة سابقًا.
اكتب التوجيه التالي داخل الجلسة الحالية:
أضف معاملات الأنواع (type annotations) لدالة add في ملف main.py، مع تضمين التحقق من الأخطاء الأساسيةيجب توضيح فكرة هامة يسهل خلطها على المبتدئين — عند العمل بالصلاحيات الافتراضية، يقوم Codex بتعديل الملفات داخل مساحة العمل مباشرة دون التوقف وسؤالك للموافقة لكل ملف. والسبب؟ أشرنا في المقال 02 نظرة سريعة على المفاهيم لكون وضع التعديل الافتراضي (مساحة العمل قابلة للكتابة workspace-write مع سياسة الموافقة on-request) يعتبر قراءة وتعديل الملفات وتشغيل الأوامر داخل مساحة العمل «أعمالاً تقع ضمن حدود الدائرة»، لذا ينفذها صامتًا لتفادي إزعاجك؛ ويتوقف لطلب الإذن عند محاولة «تجاوز الحدود» فقط — مثل تعديل ملفات خارج مساحة العمل أو الاتصال بالإنترنت. ويكون مسار عمله الافتراضي كالتالي:
- يحدد الملف المستهدف (ملف
main.py)，直接在沙箱里把改动落下去 - 把这次改了什么，以 diff（差异对比）的形式摆给你看——终端里直接打印，你也能随时
git diff复查 - مراجعتك واعتمادك للتعديل: تفحص التعديلات في ملف diff، ووافق عليها لحفظها؛ أو اطلب منه تعديلها مجددًا أو تراجع عنها بـ Git (وسنشرح ذلك لاحقًا).
هل تظل خطوة «مراجعة diff» هامة إذن؟ نعم، وبدرجة كبيرة — فالاختلاف يكمن في تحول المراجعة من «موافقة مسبقة قبل التعديل» إلى «مراجعة واعتماد بعد التعديل». فمبجرد تعديل الملفات وعرض الفروق (diff) أمامك، يمثل فحصها صمام الأمان لجودة المشروع؛ وعند اكتشاف خطأ، تظل التعديلات غير محفوظة في Git (غير مسجلة بـ commit)، ويمكنك التراجع عنها بأمر بسيط. لذا لا تحرمك الصلاحيات الافتراضية من الإشراف والرقابة، بل تعتمد على «التعديل المباشر مع توفير مراجعة الفروق وحماية التراجع بـ Git».
⚠️ ملاحظة هامة: تفترض مراجعة
git diffوالتراجع بـ Git أن يكون مشروعك خاضعًا لإدارة Git بالفعل。要是还没跑过git init，git diff找不到可对比的版本，自然看不到改动——动手前先git status确认仓库能用、工作区是干净的。下面「动手」那节会带你先git init打好存档点，再让 Codex 改。（Codex 终端里直接打印的那份 diff 不受这个前提影响，照样看得到。）
تشبيه: قيام زميلك برفع تعديلاته على فرع تجريبي (branch) مؤقت ودعوتك لمراجعتها. لقد بدأ بالعمل دون انتظار موافقتك المسبقة، ولكن التعديلات محصورة داخل الفرع التجريبي ولم تدمج في الفرع الرئيسي بعد — تفحص التعديلات، وادمجها عند الرضا، واطلب منه تعديلها أو احذفها عند وجود خلل. سلوك Codex الافتراضي يشابه هذا الزميل تمامًا: «يعدل أولاً، يعرض الفروق للتأكيد، وتحدد أنت اعتمادها أو التراجع عنها بالاستعانة بـ diff و Git»。
⚠️ هل تفضل «التوقف وطلب موافقتك مسبقًا قبل تعديل أي ملف / أو عرض خطة العمل دون تعديل الملفات»؟ هذا يتطلب تشديد الصلاحيات يدويًا: بكتابة أمر
/permissionsداخل الجلسة والتحويل لوضعread-only(ليقتصر عمله على القراءة والدراسة، ويطلب موافقتك مسبقًا قبل التعديل)، أو صياغة توجيه صريح «اعرض خطة العمل أولاً، ولا تلمس الملفات». وتظل الصلاحيات الافتراضية تعتمد على التعديل المباشر والتحقق اللاحق.
怎么看懂一个 diff
ملف diff هو مقارنة للأسطر البرمجية بين «قبل التعديل» 和 «بعد التعديل」，وفهمه يتطلب تذكر قاعدتين:
- الأسطر التي تبدأ بـ
-وتظهر باللون الأحمر تمثل الأسطر القديمة المحذوفة - الأسطر التي تبدأ بـ
+وتظهر باللون الأخضر تمثل الأسطر الجديدة المضافة - 没标记的，是没动的上下文，给你定位用的
وسيتغير ملف main.py في هذا التمرين من:
def add(a, b):
return a + b变成类似这样（具体写法 Codex 每次可能略有不同，意思对就行）：
def add(a: float, b: float) -> float:
if not isinstance(a, (int, float)) or not isinstance(b, (int, float)):
raise TypeError("يجب أن تكون المعاملات a و b أرقامًا")
return a + b加了类型注解（a: float），也加了基本的错误处理（传进来不是数字就报错）。你扫一遍 diff，问自己三个问题就够了：
- 它改的是不是我让它改的那块？（别像我那样，让它改 A，它顺手动了 B）
- 加进来的逻辑，我看得懂、认可吗？
- 有没有删掉我其实想留的东西？
如果满足这三个条件，这版改动留着；如果有任何一个「不对」，就补一句话让它改、或者 Git 退回。这一遍扫描，就是「审 diff」——前后不到十秒，却是新手和老手最大的分水岭。
什么时候它才会停下来问你
默认 Auto 档下，在工作区里改文件不弹审批，所以这次加类型注解你多半看不到「同意 / 拒绝」的弹窗——改完直接落盘、diff 打在终端里。那「同意 / 拒绝」的提示在什么时候才冒出来？答案是它要干一件出圈的事的时候——典型就这几类：
| الإجراء المطلوب من Codex | السلوك في الصلاحيات الافتراضية | التنبيه المعروض لك |
|---|---|---|
| قراءة أو تعديل ملفات داخل مساحة العمل | ينفذ مباشرة دون إزعاجك | لا توجد تنبيهات تفاعلية، ويعرض diff بعد الانتهاء |
| تشغيل أوامر برمجية (كالاختبارات) داخل مساحة العمل | ينفذ مباشرة دون إزعاج | لا توجد تنبيهات تفاعلية |
| تشغيل أوامر تتطلب الوصول للويب أو التثبيت (كـ npm install) | يتوقف لطلب الإذن صراحة | يظهر خيار «الموافقة / الرفض» ويطلب تأكيدك |
| قراءة أو تعديل ملفات خارج مساحة العمل، أو تفعيل الاتصال بالإنترنت | يتوقف لطلب الإذن صراحة | يظهر خيار «الموافقة / الرفض» ويطلب تأكيدك |
توصية هامة للمبتدئين: تجنب تمامًا تساهل الصلاحيات للحد الأقصى (مثل وضع never للموافقة أو منح الوصول الكامل) في البداية. هذا درس تعلمته بالخسارة سابقًا — 一旦放到最松，它连出圈动作都不问了，在你没细看的情况下一口气改五六个文件，等你反应过来，已经分不清哪个改动是你要的、哪个是它自作主张加的了。教训就一条：越是不熟，越要保留那道「出圈先问 + 事后审 diff」的关卡。
⚠️ 沙箱模式和审批策略都是可调的（02 讲过
read-only/workspace-write和on-request/never，15 权限详解 还会细讲）。往严了调（如read-only），它连改文件都要先问你；往松了调（如never/ 完全访问），连出圈动作都不拦——放开权限前，先确认你真的信得过当前这摊活。
يوضح الرسم مسار العمل بالتفصيل: توجيه المتطلبات ← تحليل الوكيل ← تعديل الملفات في البيئة المعزولة. وتنفذ الأنشطة داخل مساحة العمل (المسار الأخضر) مباشرة دون إزعاجك؛ وتتوقف الأنشطة التي تتجاوز الحدود (المسار الأحمر) لطلب موافقتك. وينتهي المسار بمراجعة الفروق (diff) — لتأكيد حفظها بـ git commit عند الرضا، أو التوجيه بالتصحيح والتراجع بـ git restore عند وجود خلل لإعادة المحاولة.
💡 الخلاصة في جملة واحدة: الوضع الافتراضي لـ Codex هو التعديل المباشر داخل مساحة العمل مع عرض الفروق diff لاحقًا، ولا يتوقف لطلب الإذن إلا عند تجاوز الحدود؛ وافحص diff بثلاثة أسئلة: هل عدل الموضع الصحيح، وهل تقبل الكود، وهل حذف أشياء هامة؛ وتجنب فتح الصلاحيات بالكامل في البداية.
05 الرفض ليس نهاية المطاف: وجهه في جملة إضافية ليعيد العمل
新手常有个误会：以为「拒绝」就是把这事黄了、得从头再来。不是。拒绝其实是一次「换个方向再来」的机会。
Codex 在一个线程（Thread）里干活——官方定义：一个线程就是一次会话，你的提问加上后续的模型输出和工具调用，一个线程里可以有好多轮对话。所以无论是当场拒绝了它的某个出圈请求，还是看完 diff 觉得改得不对，这次会话的上下文都还在，你直接补一句，它就顺着改。
تشبيه: طلب وجبة في المطعم. عند استلام وجبة ذات مذاق مالح، لن تضطر لمغادرة المطعم والبحث عن مطعم آخر — بل تطلب من النادل بلطف «المذاق مالح قليلاً، يرجى إعدادها بملح أقل». وسيتذكر المطبخ متطلبات وجبتك وتفضيلاتك ويقوم بتصحيح الجزء غير المناسب فقط. وتوجيه Codex بالتصحيح عند عدم الرضا عن الفروق diff يماثل هذا التعديل البسيط تمامًا.
إليك حالة واجهتها بنفسي مؤخرًا: وجهت Codex لإضافة ذاكرة مؤقتة (cache) لدالة، فقام بتهيئة مكتبة خارجية غير مثبتة في مشروعي. قمت برفض الإجراء، ووجهته بالتالي مباشرة:
تجنب استدعاء مكاتب خارجية، واعتمد على مكتبة functools.lru_cache المدمجة في Python لإنجاز المهمة它立马撤回原方案，换成标准库重写了一版 diff，这回干净利落，我才点的同意。全程没退出会话、没重头解释需求——这就是「拒绝 + 补话」的顺滑之处。
所以记住这个心态转变：
| ❌ اعتقاد خاطئ للمبتدئين | ✅ الواقع العملي |
|---|---|
| الرفض يعني ضياع مجهود الجلسة بالكامل | الرفض يتيح توجيه النموذج لتصحيح المسار والحل |
| الاضطرار لتعديل الأكواد يدويًا عند الخطأ | شرح موضع الخطأ باللغة الطبيعية ليقوم هو بالتعديل |
| إعادة تشغيل الجلسة مع cada عطل | التطوير بالتكرار داخل الجلسة الواحدة مع حفظ السياق |
💡 الخلاصة في جملة واحدة: رفض الإجراءات أو عدم الرضا عن الفروق (diff) ليس نهاية المطاف، بل يتيح إعادة المحاولة — يكفي توضيح موضع الخلل في جملة إضافية داخل الجلسة، ليقوم Codex بالتصحيح تلقائيًا دون عناء إعادة الشرح أو فتح جلسة جديدة.
06 كيفية التصرف عند حفظ التعديلات الخاطئة: Git هو صمام الأمان
万一你像开头的我一样，没细看就点了同意，改动已经落盘了——慌不慌？不慌，只要你提前做了一件事：打 Git 检查点。
这是 Codex 官方在快速上手里给的一条建议，大意是：「Codex 会改你的代码库，建议在每个任务前后各创建一个 Git 检查点，这样需要时能轻松回退。」注意——它讲的后悔药就是 Git，不是什么工具内置的撤销。
تشبيه: حفظ اللعبة قبل المعارك الصعبة. تحفظ تقدمك في اللعبة يدويًا قبل البدء في مواجهة صعبة، لتتمكن من إعادة المحاولة واستدعاء نقطة الحفظ مباشرة دون الحاجة لإعادة اللعب من البداية. أمر git commit هو نقطة الحفظ التي تسجلها قبل السماح لـ Codex بالتعديل — وعند حدوث أي عطل، تتراجع وتستدعي الملفات بأمر بسيط。
具体怎么做？让 Codex 动手之前，在项目目录里跑（只在第一次需要 git init）：
git init
git add -A && git commit -m "نقطة حفظ قبل تعديل codex"万一改炸了、想整个退回到动手前那一刻：
git restore .⚠️
git restore .会丢弃工作区里所有未提交的改动，退回到你上一次 commit 的样子。只在你确实想全部放弃 Codex 这轮改动时用；要是有一部分改对了想留，就别一刀切，改用下一段的细办法。
如果只是某几处不满意，最省事的还是回到会话里用大白话让它改回去——它记得这个线程里干过什么：
لم تعجبني التعديلات الأخيرة، يرجى التراجع وإعادة الأكواد لحالتها السابقة قبل التعديلمقارنة بين طرق التراجع لتختار منها:
| وسيلة التراجع | كيفية استخدامها | الحالات المناسبة | القيود |
|---|---|---|---|
| توجيه الوكيل بالتراجع | توجيهه باللغة الطبيعية للتراجع داخل الجلسة | عند الرغبة في تعديل تفاصيل بسيطة فورًا | يعتمد على فهم وتفسير النموذج، وليست ميزة حتمية |
| التراجع بـ Git | تشغيل commit قبل البدء، وتشغيل git restore . للتراجع | عند حدوث عطل كبير والرغبة في استعادة النسخة السابقة بالكامل | تتطلب حفظ التقدم مسبقًا، وتراجع كامل لكافة الملفات |
عادتي الشخصية الصارمة: قبل السماح لـ Codex بلمس أي ملفات هامة، أقوم بـ git commit لحفظ التقدم أولاً. ولقد حماني هذا الالتزام من فقد البيانات وتلف الأكواد لمرات لا تحصى — وفي إحدى المرات قام بتعديل ملف إعدادات بشكل عشوائي، فاخترت تشغيل git restore للتراجع الكامل وإعادة صياغة التوجيه من جديد في ثوانٍ معدودة. تذكر دائمًا أن Git هو درع حمايتك الأساسي.
💡 الخلاصة في جملة واحدة: لا داعي للقلق عند حدوث مشاكل في التعديل — أمن عملك بـ
git commitقبل البدء، واستعد النسخة بـgit restore .عند الخطأ؛ واستخدم التوجيه بالتراجع للأعطال البسيطة، واجعل Git هو صمام الأمان لتقدم المشروع.
07 تمرين عملي (1): تشغيل المسار بالكامل بـ CLI في 5 دقائق
سنقوم الآن بتطبق عملي متكامل لتأكيد فهم المسار باستخدام CLI. افتح الطرفية واتبع الخطوات التالية:
الخطوة الأولى: إنشاء مجلد تجريبي وأخذ نقطة فحص Git (Mac / Linux):
mkdir hello-codex && cd hello-codex
echo 'def add(a, b):
return a + b' > main.py
git init && git add -A && git commit -m "الإصدار الأول"Windows 用户：前两行 mkdir / cd 照敲，main.py 用记事本新建贴入那两行 Python，git 三连命令一样跑。
المتوقع: إنشاء مجلد hello-codex ويضم ملف main.py (يحتوي على دالة الجمع)، وتسجيل التعديل الأول بـ Git. ويمكنك تشغيل ls (أو dir على Windows) للتأكد من وجود الملف.
الخطوة الثانية: تشغيل Codex داخل مجلد المشروع:
codexالمتوقع: ظهور واجهة Codex التفاعلية مع صندوق الإدخال في الأسفل. وإذا طلب منك تسجيل الدخول، فذلك يعني غياب التوثيق، ويرجى إتمام خطوات تسجيل الدخول الموضحة في المقال 03 أولاً.
⚠️ 一定要在项目目录里启动
codex，别在桌面或主目录裸启。 Codex 把你当前所在的目录当工作区——你在哪启动，它就读哪儿、在哪儿动手。这是新手最常踩的第一个坑。
الخطوة الثالثة: توجيهه لقراءة وشرح الأكواد (مهمة آمنة):
اشرح دور الأكواد في ملف main.py بلغة مبسطة ومفهومة للمبتدئينالمتوقع: يقرأ Codex ملف main.py ويعرض شرحًا مبسطًا يوضح أن الكود يمثل دالة لجمع قيمتين وإرجاع النتيجة. رؤية التوضيح السليم تعني نجاح قراءته للملف محليًا واستقرار العمل.
الخطوة الرابعة: توجيهه لتعديل الأكواد ومراجعة الفروق diff:
أضف معاملات الأنواع لدالة add في ملف main.py，with basic error handlingالمتوقع: يقوم Codex بتعديل ملف main.py مباشرة، ويطبع الفروق (diff) صراحة في الطرفية (الأحمر - للمحذوف، والأخضر + للمضاف). افحص التعديلات بالأسئلة الثلاثة الموضحة في القسم 04. وإذا طلب توجيه عمليات تتطلب صلاحيات واسعة كالاتصال بالإنترنت، فسيظهر خيار «الموافقة / الرفض» لتأكيده يدويًا.
الخطوة الخامسة: مراجعة الملف في الطرفية لتأكيد سقوط التعديلات:
اخرج من جلسة Codex (بالضغط على Ctrl + C أو كتابة /exit حسب التعليمات المعروضة)، واعرض محتويات الملف في الطرفية:
cat main.py（Windows PowerShell 用 type main.py ）
المتوقع: ظهور معاملات الأنواع وتفاصيل معالجة الأخطاء داخل ملف main.py. وتطابق التعديلات مع ملف diff المعروض يعني نجاح تشغيل المسار بالكامل، تهانينا!
想再确认一遍 Codex 到底改了哪几行，Git 给你一个上帝视角：
git diffالمتوقع: طباعة الفروق البرمجية للملف وتطابقها مع ملف diff المعروض سابقًا في طرفية Codex، للتأكد من سلامة وحفظ التعديلات بنجاح.
💡 الخلاصة في جملة واحدة: خطوات تشغيل CLI الخمس هي — إنشاء المجلد وحفظ التقدم ← تشغيل
codex← شرح الأكواد للتأكيد ← التعديل ومراجعة diff ← مراجعة الملف بـcatأوgit diff؛ وتذكر تشغيل الأداة من مجلد المشروع، وأمن عملك بحفظ التقدم بـ Git أولاً。
08 تمرين عملي (2): تطبيق نفس المهمة باستخدام تطبيق سطح المكتب
不爱碰终端的，桌面 App 把同样的流程做成了点点点。注意：桌面 App 目前只有 macOS 和 Windows，Linux 暂时没有（Linux 用户走上面 CLI 那条路）。
App 的整体节奏和 CLI 一模一样，就是把「敲命令」换成了「点界面」，核心那个「看 diff 验收」一步不少。按官方快速上手的步骤走：
- افتح تطبيق Codex App وسجل الدخول بحساب اشتراك ChatGPT أو مفتاح API key (القسم 03 يوضح الفروق بينهما).
- حدد مجلد المشروع
hello-codexالذي ترغب في ربطه (أو أنشئ مجلدًا تجريبيًا جديدًا). وتظهر المشاريع المفتوحة سابقًا في القائمة للوصول السريع. - تأكد من اختيار Local في الزاوية اليسرى السفلية قبل إرسال الرسالة الأولى، ليوجه Codex للعمل محليًا على ملفات جهازك بدلاً من البيئة السحابية.
- أرسل التوجيه الأول بلغة طبيعية في صندوق الإدخال:
اشرح دور الأكواد في ملف main.py بلغة مبسطة ومفهومة للمبتدئينوبعد تأكيد قراءته السليمة، أرسل توجيه التعديل:
أضف معاملات الأنواع لدالة add في ملف main.py，with basic error handlingالمتوقع: يقوم Codex بتعديل الملف محليًا بالصلاحيات الافتراضية، ويعرض التعديلات بدقة سطرًا بسطر في لوحة المراجعة (review pane) — وتوضح اللوحة التعديلات غير المسجلة بعد في Git (أي التعديلات النشطة في مساحة العمل). وهذه هي ميزة تطبيق سطح المكتب الرائعة — حيث يوفر لوحة رسومية ممتازة لمراجعة الفروق diff بوضوح، مع توفير أزرار تفاعلية للاعتماد والتسجيل أو التراجع. وإذا نالت التعديلات رضاك، اعتمدها من اللوحة مباشرة؛ وتراجع عنها أو اطلب تعديلها عند الخطأ.
官方在快速上手的 CLI / IDE 那两条里都建议你改前后各打一个 Git 检查点，方便随时回退；App 这边内置了 Git 功能，看完 diff 你可以在界面里直接暂存、提交。
مقارنة بين CLI وتطبيق سطح المكتب لتحديد خيارك:
| مقارنة الجوانب | سطر الأوامر CLI | تطبيق سطح المكتب |
|---|---|---|
| المنصات المدعومة | ✅ يدعم أنظمة Mac / Windows / Linux بالكامل | ❌ يدعم Mac و Windows فقط حاليًا |
| سهولة الاستخدام | تتطلب كتابة الأوامر وتثير قلق المبتدئين | ✅ واجهة رسومية سهلة وبسيطة |
| مراجعة الفروق diff | مراجعة نصية جافة في الطرفية | ✅ لوحة رسومية واضحة وممتازة |
| إدارة عدة مشاريع | 超过多个终端窗口 | ✅ تنقل مرن وسريع بين المشاريع |
| مسار العمل الأساسي | التوجيه ← التعديل ← مراجعة diff | متطابق بالكامل，与 App 界面基本一致 |
我自己的用法：写代码、跑命令我常驻 CLI（顺手、跨平台）；但遇到改动多、diff 长的活，我会切到 App 里审 diff，那个图形面板一行行看，比在终端里翻文本舒服不少。一次登录后两端一般都能用（具体以官方鉴权说明为准），挑你顺手的。
💡 الخلاصة في جملة واحدة: يسهل تطبيق سطح المكتب إنجاز المهام بواجهة رسومية (على نظامي Mac و Windows)، مع ضرورة تأكيد اختيار Local قبل البدء؛ وتمنحك لوحة المراجعة الرسومية وضوحًا أفضل للفروق الطويلة، وتظل خطوة «مراجعة الفروق diff والاعتماد» متطابقة تمامًا مع CLI.
09 مسار العمل بالكامل في مخطط واحد
نلخص مسار العمل بالكامل في هذا المخطط الموحد — وتتبع الخطوات نفس التسلسل سواء كنت تستخدم CLI أو تطبيق سطح المكتب:
النقطة الأهم في المخطط هي بوابة مراجعة الفروق diff في المنتصف: حيث يقوم Codex بالتعديل في البيئة المعزولة ويعرض الفروق المقابلة، لتتفحصها وتعتمدها للحفظ، أو ترفضها وتوجهه بالتصحيح والتراجع بـ Git — ويمثل هذا الإشراف البشري صمام الأمان الحقيقي لتعاونك مع Codex. وتفادي هذه البوابة كان سبب ضياع وقتي سابقًا.
💡 الخلاصة في جملة واحدة: تتلخص المهمة الأولى في مسار مغلق — التوجيه ← التعديل ← مراجعة diff ← الاعتماد أو التراجع؛ والالتزام بخطوة مراجعة الفروق diff يحمي مشروعك من التلف ويمنع حدوث الأعطال.
10 ملخص
لقد أنجزت عملًا حقيقيًا في هذا المقال: تشغيل المهمة الأولى لـ Codex بالكامل — من إنشاء المجلد والتشغيل، وحتى قراءة الأكواد وتعديلها ومراجعتها للاعتماد，وتطبيق المسار بـ CLI وتطبيق سطح المكتب معًا. ونلخص الخطوات في الجدول التالي:
| الخطوة | الإجراء العملي | النقاط الهامة |
|---|---|---|
| إنشاء المشروع | استخدام mkdir وإنشاء الملف والـ commit الأول | ابدأ بمشروع تجريبي بسيط، وأمن عملك بحفظ التقدم مسبقًا |
| توجيه المتطلبات | الكتابة باللغة الطبيعية بوضوح | اطلب خطة عمل للمشاريع الكبيرة وتجنب التعديل المباشر فورًا |
| القراءة والشرح | «اشرح دور ملف main.py» | مهمة آمنة تمامًا لتأكيد قراءة وربط الملفات المحلية |
| التعديل | «أضف معاملات الأنواع للدالة...» | بالصلاحيات الافتراضية يعدل مباشرة ويعرض diff لتتفحص التعديلات لاحقًا |
| مراجعة الفروق diff | طرح الأسئلة الثلاثة للفحص | الخطوة الأهم للفحص والاعتماد وتجنب إهمالها |
| التراجع | التوجيه بالتراجع أو تشغيل git restore . | استخدام Git كصمام أمان أساسي لحماية وتأمين العمليات |
يجب أن تكون قادرًا الآن على: تشغيل Codex بـ CLI أو تطبيق سطح المكتب، توجيهه باللغة الطبيعية لقراءة وتعديل الأكواد محليًا، فهم ومراجعة ملفات الفروق (diff) لاتخاذ قرار الحفظ أو التراجع، ومعرفة كيفية استعادة النسخ السابقة عند الخطأ.
ويمثل هذا المسار — «التوجيه ← مراجعة diff ← الحفظ / التراجع» — النواة الأساسية لجميع تعاملاتك القادمة مع Codex. والميزات المتقدمة والأدوات اللاحقة (خوادم MCP، الوكلاء الفرعيون، المهارات، والأتمتة...) تضاف كتحسينات فوق هذه النواة. واجعل خطوة «مراجعة الفروق diff» عادتك البرمجية الثابتة دائمًا لتفادي المشاكل والأعطال.
💡 الخلاصة في جملة واحدة: تتلخص المهمة في — التوجيه ← التعديل ← مراجعة diff ← الاعتماد أو التراجع؛ والوضع الافتراضي يسمح بالتعديل المباشر مع مراجعتك اللاحقة لـ diff وحماية التراجع بـ Git، ويمكنك تشديد الصلاحيات لطلب الإذن المسبق عند الحاجة.
المقال التالي 07 · تفاصيل تطبيق سطح المكتب — لقد جربنا تشغيل التطبيق سريعا في هذا المقال، ولكن قدراته تتجاوز مجرد تعديل الأكواد: إدارة مشاريع متوازية، عزل مساحات العمل بـ worktree، المتصفح المدمج، ومهام الأتمتة... سيوضح المقال القادم جولة شاملة في ميزات تطبيق سطح المكتب. وسؤال للتفكير: هل وجدت لوحة المراجعة الرسومية للتطبيق أفضل وأسهل من مخرجات الطرفية الجافة؟ إذا كانت الإجابة نعم، فستعجبك الميزات التفصيلية في المقال القادم حتمًا.