لقد انتشر مخطط جريجلي أوروز لمصنع برمجيات OpenAI الداخلي هذا الأسبوع: حيث يقوم منشئ بإيداع نتيجة، ويكتب Codex الكود، ويتجادل أسطول من وكلاء المراجعة المتخصصين حول المخاطر، ويشرف وكيل على النشر أثناء مراقبة لوحات المعلومات التي بناها بنفسه. وهو أيضًا، بالنسبة للأجزاء الأكثر أهمية لمهندسي OpenAI، وصف لأدوات داخلية لا يمكنك تثبيتها.
يعمل Perf Factory و Sevbot والنشر التلقائي باستخدام لوحات المعلومات المصممة ذاتيًا على حزمة المراقبة الخاصة بـ OpenAI وليست جزءًا من منتج Codex الذي يمكنك شراؤه. ما يمكنك بناؤه هذا الأسبوع هو حلقة أصغر لا تزال تؤدي عملًا حقيقيًا: يحدد المنشئ النتيجة كمشكلة، ويعمل Codex على الفرع، ويتحقق CI من أن التغيير يعمل بالفعل، وينظر وكيل أو اثنان من المراجعين إليه، ويوافق إنسان على أي شيء محفوف بالمخاطر قبل نشره خلف علامة. يعتمد الأمر برمته على تفصيل واحد يتجاهله الرسم البياني الأصلي: "اجتياز CI" لا يعني شيئًا إلا إذا كان CI يتحقق من الأشياء الصحيحة. بالنسبة لواجهة برمجة التطبيقات (API)، هذا يعني اختبار واجهة برمجة التطبيقات، وليس فقط الكود الذي يستدعيها.
ما يصوره الرسم البياني بشكل صحيح (وما لا يمكنك نسخه)
يصف الجزء العام من مقالة Pragmatic Engineer حلقة أساسية حيث يقوم Codex "بإجراء سلسلة من التغييرات في التعليمات البرمجية حتى يصل إلى هدفه، ثم يتحقق من أن البرنامج يعمل كما ينبغي". يمكن للمناطق منخفضة المخاطر الحصول على موافقة تلقائية؛ وتحصل التغييرات عالية المخاطر على مراجعة إضافية من الذكاء الاصطناعي أو موافقة بشرية إلزامية. هذا الهيكل، الذي يتضمن الاقتراح والتحقق والمراجعة حسب مستوى المخاطرة، قابل للنقل. وقد قامت الفرق بتقليده باستخدام روبوتات طلبات السحب وبوابات CI لسنوات؛ الوكلاء فقط يجعلون الحلقة أسرع وأقل حاجة للإشراف.
ما ليس قابلاً للنقل هو الآليات الداخلية المحيطة به. يقوم Perf Factory بفلترة التنبيهات ولوحات المعلومات للعثور على تراجعات زمن الوصول واقتراح إصلاحات. يحقق Sevbot في الحوادث ويجيب على الأسئلة في Slack، على الرغم من أنه لا ينفذ التخفيفات بنفسه. يراقب النشر الآلي التغيير في الإنتاج ويبني مراقبته الخاصة باستخدام حزمة القياس عن بعد الداخلية لـ OpenAI. لا يتم شحن أي من هذه الثلاثة في منتج Codex الخارجي. ما تم شحنه هو تطبيق سطح المكتب، وأمر /goal للمهام طويلة الأمد، ومكونات الأدوار الإضافية والمهارات التي تقوم بتكوينها بنفسك. تغطي صفحة منتج OpenAI Codex ما هو متاح بالفعل.
الحلقة الخماسية الخطوات التي يمكنك تشغيلها هذا الأسبوع
نسخة مبسطة تبدو كالتالي:
- يقوم منشئ بتقديم النتيجة كمشكلة. ليس قائمة مهام، بل وصف للحالة النهائية: "يمكن للطلبات أن تحمل رمز خصم اختياري يقلل الإجمالي." تسليم نفس مشكلة GitHub هذه إلى وكيل في Sharkly هو التكامل المشحون: تصبح المشكلة مهمة، وتعود النتيجة كطلب سحب (PR) بدلاً من تذكرة منفصلة للتوفيق. إنه مجاني حاليًا للمؤسسات التي تضم ما يصل إلى 10 أشخاص.
- يعمل Codex على الفرع باستخدام
/goal. كما هو موضح في كيفية قيادة الأمر/goalلتشغيل Codex و Claude Code المستقلين، فإنك تعطي الوكيل هدفًا وتتركه يكرر العمليات بنفسه حتى يتم تحقيق الهدف. - يقوم CI بتشغيل البناء واختبارات الوحدات وسيناريوهات اختبار واجهة برمجة التطبيقات (API). هذه هي الخطوة التي يتجاهلها معظم الفرق أو يبنونها جزئيًا.
- يقوم وكيل مراجع واحد أو اثنان بفحص التغييرات (diff)، ويراجع الإنسان أي شيء يتجاوز المخاطر المنخفضة. يمكن لأدوات مراجعة التعليمات البرمجية بالذكاء الاصطناعي اكتشاف الكثير قبل أن يفتح أي إنسان طلب السحب (PR). في Sharkly، هذا هو المكان الذي يؤدي فيه "جاهز للنشر" (Ready for Release) المهمة: يجب على الإنسان نقل المهمة من هذه الحالة قبل أن يصل أي شيء إلى "تم" (Done)، ويمكن لوكيل مراجع منفصل أن يكون في نفس الفريق (Crew) الذي كتب الكود.
- النشر خلف علامة ميزة (feature flag)، بحيث يكون الدمج السيء عبارة عن مفتاح تبديل، وليس حادثًا.
الخطوة 3 هي حيث تعمل الحلقة إما بشكل صحيح أو تخدعك.
لماذا يجب على CI اختبار واجهة برمجة التطبيقات (API)، وليس فقط الكود
ميزة المراجعة الخاصة بـ Codex، التي تمت تغطيتها في كيفية عمل مراجعة كود Codex، تقرأ الاختلافات (diff) وتشير إلى المشاكل الواضحة. إنها لا تشغل خدمتك وتتحقق مما تعيده. اختبارات الوحدات، إذا كتبها الوكيل أو حافظ عليها، تتحقق في الغالب من أن الكود يفعل ما ينوي الكود فعله، وهو ليس نفس التحقق من أن واجهة برمجة التطبيقات (API) تفعل ما يعد به العقد. يمكن للوكيل الذي يقوم بتحرير معالج أن يجتاز كل اختبار وحدة بينما يكسر بهدوء الاستجابة التي يعتمد عليها كل عميل.
لنفترض أنك تدير واجهة برمجة تطبيقات للطلبات. POST /api/orders ينشئ طلبًا ويعيد سجله؛ GET /api/orders/{id} يجلب طلبًا حسب المعرف. تحتفظ بمواصفات OpenAPI لكليهما، وبنيت سيناريوهات اختبار Apidog ضدها: أنشئ طلبًا، استرجعه، وتحقق من أربعة أشياء لا يتحقق منها اختبار الوحدة عادةً:
- رموز الحالة.
POST /api/ordersيعيد201، وليس200أو500صامتًا في حالة فشل التحقق. - مخطط الاستجابة مقابل مواصفات OpenAPI. يبقى حقل
total_amountرقمًا، وتبقىstatusإحدى قيم التعداد التي حددتها، ولا يختفي أي حقل يعتمد عليه العملاء بهدوء أو يتم إعادة تسميته. - فشل المصادقة. يعيد الطلب بدون رمز مميز صالح
401، وليس200مع نص فارغ، وهو تراجع شائع بشكل مدهش. - حد زمن الاستجابة. يؤكد السيناريو أن الاستجابة تعود ضمن حد زمني محدد، بحيث يتم اكتشاف أي تغيير يضيف استدعاء قاعدة بيانات غير مجمّع داخل المعالج قبل أن يلاحظه العميل.
هذه هي بالضبط الفحوصات التي يمكن أن يكسرها إعادة هيكلة على مستوى المعالج بصمت بينما لا تزال جميع اختبارات الوحدات تمر بنجاح، لأن اختبارات الوحدات عادة ما تحاكي الحدود التي يختبرها سيناريو واجهة برمجة التطبيقات فعليًا.
ربطه بخط الأنابيب
لقد قمت بالفعل بتشغيل إصدار سطر الأوامر (CLI) من هذه السيناريوهات محليًا إذا اتبعت كيفية استخدام Apidog CLI في Codex. يتم تشغيل نفس الأمر في CI. تبدو وظيفة GitHub Actions التي تقوم بالبناء وتشغيل اختبارات الوحدات ثم تشغيل سيناريو Apidog كالتالي:
name: CI
on:
pull_request:
push:
branches: [main]
jobs:
build-test-verify:
runs-on: ubuntu-latest
steps:
- name: Check out repository
uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies
run: npm ci
- name: Build and run unit tests
run: npm run build && npm test
- name: Install Apidog CLI
run: npm install -g apidog-cli
- name: Run orders API test scenario
env:
APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
run: |
apidog run \
--access-token $APIDOG_ACCESS_TOKEN \
-t 88214 \
-e 3301 \
-r cli,junit
- name: Upload Apidog reports
if: always()
uses: actions/upload-artifact@v4
with:
name: apidog-reports
path: apidog-reports/
قيمتا -t و -e هما معرفا السيناريو والبيئة الحقيقيان الخاصان بك من Apidog، وليسا عناصر نائبة تقوم باختراعها. يغطي مرجع أمر apidog run كل علامة، وتشرح تقارير اختبار Apidog CLI مخرجات JUnit التي تقوم الوظيفة بتحميلها. يخرج apidog run بقيمة غير صفرية عند أي تأكيد فاشل، لذا يقوم GitHub Actions بوضع علامة فشل على الوظيفة بنفس الطريقة التي يفعلها لاختبار وحدة فاشل.
كيف يبدو توجيه الوكيل
الهدف من /goal هو أن تصف النتيجة وشرط الخروج، ويقوم Codex بالتكرار دون أن توافق على كل خطوة. لمثال رمز الخصم، يكون التوجيه المعقول كالتالي:
/goal Add an optional `discount_code` field to POST /api/orders. Validate it
against the promotions service and apply the discount to `total_amount` in
the response. Do not rename or remove any existing response field. Run
`npm test` and `apidog run --access-token $APIDOG_ACCESS_TOKEN -t 88214 -e 3301
-r cli` before you finish. Both must exit 0. If the Apidog run fails, read the
failing assertion and fix the handler, not the test.
ذلك السطر الأخير مهم. الوكيل تحت الضغط لجعل الفحص يمر بنجاح قد يقوم أحيانًا بتعديل التأكيد بدلاً من إصلاح الخطأ. إخباره صراحة بأي جانب من الحلقة يجب إصلاحه يحافظ على سيناريو الاختبار كمصدر للحقيقة، وليس عقبة يجب تجاوزها.
عندما يخرق الوكيل العقد
يضيف Codex حقل الخصم، وفي هذه العملية يعيد تسمية total_amount إلى totalAmount لأن هذا هو الاصطلاح في ملف قرأه بالقرب. لا تزال اختبارات الوحدات تمر؛ فهي تتحقق من حساب الخصم، وليس اسم الحقل. ينجح البناء. ثم يتم تشغيل سيناريو Apidog في CI، ويتحقق من الاستجابة مقابل مواصفات OpenAPI، ويفشل: المواصفات تقول total_amount، والاستجابة الآن تحتوي على totalAmount، ويكتشف تأكيد المخطط ذلك على الفور.
يُبلغ CI عن خروج غير صفري ويشير إلى تأكيد المخطط الفاشل في مخرجات JUnit. يقرأ Codex الفشل، ويرى أن إعادة التسمية هي السبب، ويلغيها مع الاحتفاظ بمنطق الخصم. يجتاز السيناريو، ويصبح البناء أخضر، وينتقل طلب السحب للمراجعة بضمان فعلي وراء كلمة "اجتياز". بدون فحص مستوى واجهة برمجة التطبيقات، يتم شحن إعادة التسمية هذه، ويتعطل كل عميل يقوم بتحليل total_amount في الإصدار التالي.
تصنيف المخاطر الذي يمكنك ترسيخه في المواصفات
بدلاً من الإحساس الغامض بما يعتبر مخاطر منخفضة، اربط تصنيف المخاطر الخاص بك باختلاف OpenAPI. التغيير الذي يضيف حقلًا اختياريًا بقيمة افتراضية هو مرشح للدمج التلقائي بمجرد اجتياز الاختبارات. التغيير الذي يزيل حقلًا، أو يعيد تسمية واحدًا، أو يغير رمز الحالة، لا يعتبر أبدًا مخاطرة منخفضة، بغض النظر عن شكل بقية التغييرات. هذه القاعدة الواحدة تلتقط معظم ما سيشير إليه وكيل مراجعة متخصص على أي حال. وجه أي شيء تشير إليه القاعدة إلى مراجع بشري أو جولة ثانية من أداة مراجعة كود الذكاء الاصطناعي قبل الدمج.
انشر خلف علامة، وليس في الفراغ
بمجرد أن يجتاز التغيير اختبارات التكامل المستمر (CI) والمراجعة، قم بنشره خلف علامة ميزة (feature flag) بدلاً من توجيهه مباشرة إلى كل مستخدم. هذا هو البديل الرخيص لخطوة النشر الآلي لدى OpenAI: لا يوجد وكيل يشرف على عملية الطرح أو يبني لوحات المعلومات الخاصة به. علامة تبدأ بنسبة 5% من حركة المرور وشخص يتحقق من معدلات الأخطاء قبل قلبها إلى 100% يوفر لك معظم الأمان دون الحاجة إلى الأدوات الداخلية. إذا كان هناك خطأ ما، يمكنك إيقاف تشغيل العلامة بدلاً من التراجع عن عملية دمج تحت الضغط.
هيكل موجود بالفعل
ليس عليك ربط جميع الخطوات الخمس من الصفر. orchflows هو مشروع مفتوح المصدر ظهر في الردود على موضوع أوروز: أمر /software-factory مرخص بموجب MIT لـ Claude Code و Codex، مبني حول عدد قليل من المهارات القابلة لإعادة الاستخدام. إنه هيكل بدء، وليس بديلاً لخطوات CI والمراجعة المذكورة أعلاه؛ لا يزال عليك توجيهه إلى سيناريوهات الاختبار وقواعد المخاطر الخاصة بك.
ما يجب تجنب بنائه
لا تحاول إعادة إنتاج Perf Factory أو Sevbot أو النشر الآلي بلوحات معلومات مبنية ذاتيًا. إنها أنظمة داخلية لـ OpenAI متصلة بأنظمة قياس عن بعد لا تديرها معظم الفرق. لا يزال البشر في OpenAI يحددون النتائج، ويوافقون على التغييرات عالية المخاطر، ويصرحون بتخفيف الحوادث، ويتحملون مسؤولية الدعم الفني؛ وكما قالت OpenAI، "واجب الدعم الفني ليس شيئًا من الماضي". انسخ الأجزاء من الحلقة التي هي مجرد ممارسة هندسية جيدة: تحقق قبل الدمج، صنف المخاطر بناءً على ما تغير بالفعل، واحتفظ بإنسان مشرفًا على أي شيء غير آمن بشكل واضح.
اجعل الحلقة تعمل
ابدأ بخطوة CI؛ فهي تجعل كل خطوة أخرى جديرة بالثقة. أنشئ سيناريو اختبار واجهة برمجة التطبيقات للطلبات الخاصة بك في Apidog، بما يغطي رموز الحالة، والمخطط، والمصادقة، وميزانية زمن الاستجابة. قم بربطه بخط الأنابيب الخاص بك باستخدام سطر الأوامر (CLI)، ووجه /goal إلى مشكلة حقيقية، ودع Codex يكرر العمليات مقابل فحص يؤكد سلوك واجهة برمجة التطبيقات بالفعل بدلاً من الوثوق بكلمة الوكيل. قم بتنزيل Apidog لبناء السيناريو الأول، ثم أضف خطوات المراجع والعلامة بمجرد أن تثبت الحلقة كفاءتها.