ما التقنيات التي يمتلكها Pierre حقًا؟ تحليل 5 منتجات يستخدمها Codex، منها Trees وDiffs وCode Storage

ملاحظة المحرر: أعلنت OpenAI عزمها الاستحواذ على Pierre. يستعرض هذا المقال منتجات Pierre الخمسة: Trees وDiffs المستخدمين بالفعل في Codex، إلى جانب Highlights وDiffsHub وخدمة Code Storage المدفوعة، لتعرف أي المكونات مفتوحة المصدر يمكنك استخدامها مباشرة.

في 4 نوفمبر 2026، أعلنت OpenAI عزمها الاستحواذ على شركة أدوات المطورين Pierre Computer Company. قد يكون الانطباع الأول لدى كثيرين أن «OpenAI اشترت شركة أخرى لاستضافة Git»، لكن هذا ليس دقيقًا. تمتلك Pierre منظومة تقنية متكاملة تشمل تصفح الشفرة، ومقارنة الاختلافات، والتحرير عبر الإنترنت، وإبراز الصياغة، وتخزين Git. ويعمل اثنان من منتجاتها بالفعل داخل تطبيق Codex منذ فترة.

هذه ليست مجرد شائعة، ولا خبرًا عاجلًا يكتفي بسرد الإعلان. أكّد إعلان OpenAI الرسمي أن Codex يستخدم مكتبتي Trees وDiffs من Pierre، كما أن مستودعات Pierre مفتوحة المصدر وحزم NPM متاحة للجميع. تجدر الإشارة إلى أن الصفقة لم تُستكمل بعد، ولم يُعلن عن قيمتها.

ما ستستفيده: بعد قراءة هذا المقال، ستحصل على خريطة تقنية واضحة لمنتجات Pierre، تبيّن الفروق بين المكونات مفتوحة المصدر والأدوات المتاحة عبر الإنترنت وخدمة التخزين المدفوعة، وستعرف أي المكونات يمكنك إضافتها إلى مشروعك اليوم.

أبرز المعلومات عن صفقة الاستحواذ على Pierre

لنبدأ بالفصل بين الحقائق المؤكدة والمعلومات التي لم تتأكد بعد. يقتصر الجدول التالي على ما ورد صراحةً في إعلان OpenAI وقنوات Pierre الرسمية.

ستواصل الشركتان العمل بشكل مستقل إلى حين إتمام الصفقة. وقد فسّرت Axios الصفقة على أنها توسّع لـ Codex في مجال التعاون على الشيفرة، الذي هيمن عليه GitHub لسنوات. لكن هذا تفسير إعلامي لاتجاه المنافسة؛ فلم تعلن OpenAI عن إطلاق بديل متكامل لـ GitHub.

الخريطة التقنية لـ Pierre: مكونات مفتوحة المصدر وأدوات عبر الإنترنت وتخزين مدفوع

لفهم Pierre، من المفيد تقسيم منتجاتها إلى ثلاث طبقات. فالشركة لا تتخصص في تدريب نماذج اللغة الكبيرة، ولا تبيع واجهات API للنماذج، بل تطوّر البرامج والبنية التحتية اللازمة لعرض الشيفرة وتحريرها وتخزينها وإدارتها. ويصف موقعها الرسمي خدماتها بأنها «بنية تحتية أساسية قابلة للتركيب لأحمال العمل التي تقودها الآلات».

تتركز المكونات مفتوحة المصدر في مستودع GitHub المسمى pierrecomputer/pierre، وتستخدم ترخيص Apache License 2.0. حتى 2026-11-05، كان المستودع يضم نحو 6,500 نجمة و266 نسخة متفرعة ونحو 1,320 عملية إيداع؛ وهذه أرقام قابلة للتغير. تجدر الإشارة إلى أن هذا المستودع لا يضم كامل شيفرة الواجهة الخلفية التجارية لـ Code Storage.

نظرة على Pierre Diffs: وضع التحرير وواجهة المراجعة وتعارضات الدمج

الحزمة مفتوحة المصدر لـ Diffs هي @pierre/diffs، وكان الإصدار المعروض على الموقع الرسمي وقت التحقق هو v1.6.4، أما نقطة الدخول الخاصة بـ React فهي @pierre/diffs/react. تتمثل وظيفتها الأساسية في عرض ملفات الشفرة وملفات Patch والفروق بين إصدارين على الويب. وهي تدعم عرضين: Split لوضع الإصدارين جنبًا إلى جنب، وStacked/Unified لدمجهما في عرض واحد، مع تمييز الفروق داخل السطر على مستوى الأحرف والكلمات. ويمكن للمطورين تمرير إصدارين من الملف أو تمرير ملف Patch مباشرة.

وضع التحرير في Diffs: تعديل الشفرة مباشرة في عرض الفروق

ذكرت OpenAI هذه الميزة بالاسم في إعلانها: إذ يمكن للمراجع تعديل سطر من الشفرة مباشرة داخل عرض الفروق. يدعم وضع التحرير تحديد النص وتعدد التحديدات، والمسافة البادئة التلقائية، والتراجع والإعادة، والبحث داخل الملف، وعلامات التدقيق البرمجي، وإجراءات التحرير المخصصة، إضافة إلى المؤشرات المحلية والبعيدة. وتوفر الحزمة EditProvider وواجهات Editor API ذات الصلة، مع الإشارة إلى أن بعض قدرات التحرير لا تزال تجريبية Beta.

تعالج هذه الميزة مشكلة محددة: في سير العمل التقليدي، إذا اكتشفت مشكلة في سطر شفرة أنشأه الذكاء الاصطناعي، فعليك الانتقال إلى المحرر الكامل، وتحديد موقع الملف وتعديله، ثم العودة إلى واجهة المراجعة. يجمع وضع التحرير بين اكتشاف المشكلة وإصلاحها في واجهة واحدة، وهو مفيد خصوصًا عندما يُجري وكيل ذكاء اصطناعي تغييرات كثيرة ويراجعها الإنسان جزءًا بجزء.

واجهة مراجعة الشفرة في Diffs: إطار Annotation قابل للتوسعة

يوفر Diffs إطار Annotation مرنًا يتيح إرفاق التعليقات على مستوى السطر، ونتائج فحوصات CI، وملاحظات مراجعة الذكاء الاصطناعي، ومخرجات أدوات خارجية بأسطر محددة من الشفرة. ويمكن للمطورين أيضًا إضافة أزرار مخصصة إلى عرض الفروق، مثل Accept Change لقبول التغيير وReject Change لرفضه، مع دعم الرد على التعليقات وإرفاق شرح بأسطر الشفرة المحددة.

من المهم توضيح الحدود هنا: Diffs مكوّن للعرض والتفاعل، وليس نموذج ذكاء اصطناعي يكتشف الثغرات تلقائيًا. نظامك هو الذي يحدد مصدر ملاحظات المراجعة؛ فمثلًا، يمكنك استخدام API لنموذج لغة كبير لتوليد الاقتراحات، ثم تمريرها إلى Diffs لعرضها.

تعارضات الدمج في Diffs: معالجة منظمة للتعارضات

عند حدوث تعارض دمج، لا يستطيع عرض الفروق النصي العادي سوى إظهار مجموعة من علامات التعارض. أما Diffs فيوفر واجهة مخصصة لمعالجة التعارضات، تعرض المنطقة المتعارضة في صورة إضافات وحذف منظّمين. ويمكن للمستخدم اختيار الاحتفاظ بالإصدار الحالي، أو اعتماد الإصدار الوارد، أو الاحتفاظ بكليهما، ثم معاينة الملف بعد حل التعارض.

من الناحية التقنية، تذكر الوثائق الرسمية أن الحزمة تدعم JavaScript دون إطار عمل وReact، وتستخدم Shiki لتمييز الصياغة، وCSS Grid وShadow DOM لتنظيم بعض أجزاء العرض. كما توفر أدوات SSR وWorker Pool والعرض الافتراضي، الذي يهدف إلى منع المتصفح من عرض كميات كبيرة من المحتوى غير المرئي دفعة واحدة.

Pierre Trees وHighlights: أشجار الملفات الكبيرة والإبراز أثناء البث

Trees: مكوّن لشجرة الملفات مصمّم للمستودعات الكبيرة

الحزمة مفتوحة المصدر لـ Trees هي @pierre/trees، وكان الإصدار المعروض رسميًا وقت التحقق هو v1.0.0-beta.6. يتولى هذا المكوّن عرض شريط تصفح الملفات على يسار أدوات مثل Codex. وتشمل وظائفه توسيع المجلدات وطيّها، والبحث والتصفية حسب الاسم والمسار، ودمج سلاسل المجلدات الفارغة ذات المستوى الواحد تلقائيًا، وسحب الملفات والمجلدات، وإنشاءها وإعادة تسميتها، وتخصيص قوائم النقر بزر الفأرة الأيمن وأيقونات الملفات.

أكثر الميزات ارتباطًا بسيناريوهات البرمجة بالذكاء الاصطناعي هي عرض حالة Git. يمكن وضع علامات بجانب الملفات: M للمعدّل، وA للمضاف والمجهّز للالتزام، وD للمحذوف، وR لما أُعيدت تسميته، وU لغير المتتبّع. ويمكن أيضًا إظهار علامة على المجلدات الأصلية التي تحتوي على ملفات متغيّرة. وعندما يعدّل وكيل عشرات الملفات دفعة واحدة، يستطيع المطوّر معرفة مواضع التغييرات بنظرة سريعة إلى شجرة الملفات.

من ناحية الأداء، يستخدم Trees العرض الافتراضي تلقائيًا، فيعطي أولوية لعرض الصفوف المرئية حاليًا فقط. يعرض الموقع الرسمي شجرة مجلدات تضم 2,956 ملفًا بعد توسيعها بالكامل، كما يستعرض العرض الافتراضي لعشرات الآلاف من العناصر. وهذه عروض رسمية، وليست اختبارات أداء مستقلة، ولا تعني أن الأداء سيكون متماثلًا على جميع الأجهزة. أما فيما يخص إمكانية الوصول، فيوفّر Trees التنقل بمفاتيح الأسهم، وإدارة التركيز بمفتاح Tab، ودورَي ARIA من نوع tree وtreeitem. وتقول الجهة المطوّرة إن التصميم يتبع الإرشادات ذات الصلة في WCAG 2.1.

Highlights: أداة إبراز تواكب سرعة مخرجات الوكيل

يظهر Highlights حاليًا في وثائق Diffs الرسمية بصفته إصدارًا تجريبيًا. وتذكر الوثائق أنه يضم محللات لغوية لـ 152 لغة، ويعتمد على WebAssembly، ويمكن تشغيله في المتصفح وNode.js وCloudflare Workers، مع إخراج HTML أو كائنات Token متوافقة مع Shiki.

تتوزع مهام واجهات API الأربع الرئيسية بوضوح: تعالج codeToHtml() الشفرة الكاملة، وتخرج codeToTokens() وحدات Token منظّمة حسب الأسطر، ويناسب StreamTokenizer استقبال المحتوى تدريجيًا وإخراج الأسطر المكتملة، بينما يتيح LiveTokenizer التحديث التدريجي للمستندات أثناء تحريرها. ببساطة، يعالج Highlights مسألة مواكبة إبراز الشفرة في الواجهة عندما يبثّها الوكيل تدريجيًا، لكنه لا يحسّن قدرة النموذج نفسه على البرمجة.

DiffsHub: استبدل github.com بـ diffshub.com

DiffsHub أداة من Pierre متاحة عبر الإنترنت، تعرض أداء Trees وDiffs في سيناريوهات حقيقية. يكفي استبدال github.com بـ diffshub.com في روابط طلبات السحب والالتزامات والمقارنات وملفات Patch وDiff على GitHub، لتصفح التغييرات نفسها عبر واجهة Pierre. وتشمل الأمثلة الرسمية مستودعات مثل oven-sh/bun وnodejs/node.

للوصول إلى مستودع خاص، عليك توفير رمز وصول شخصي إلى GitHub يتمتع بالصلاحيات اللازمة. ويوضح الموقع الرسمي أن الرمز يُحفظ في localStorage بالمتصفح، وهذا لا يعني أن بإمكان Pierre قراءة المستودعات الخاصة كيفما شاءت. وينبّه الموقع أيضًا إلى أن متصفحات الأجهزة المحمولة قد تتعطل عند عرض Diff ضخم للغاية. وDiffsHub ليس بديلًا عن GitHub، كما أنه ليس مكتبة Diffs مفتوحة المصدر نفسها.

ما الفرق بين Pierre Code Storage ومستودعات GitHub العادية؟

إذا كانت Trees وDiffs تمثلان طبقة الواجهة لـ«عرض الشفرة»، فإن Code Storage تمثل طبقة البنية التحتية لـ«تخزين الشفرة»، وهي أيضًا المحور الاستراتيجي لهذه الصفقة. إنها خدمة تخزين موزعة وقابلة للبرمجة، مبنية على Git، وموجهة إلى منتجات الذكاء الاصطناعي التي تحتاج إلى إنشاء أعداد كبيرة من المستودعات وقراءتها وتعديلها ومزامنتها.

يركز GitHub أساسًا على التعاون بين الأشخاص، من خلال المستودعات وطلبات السحب (PR) والقضايا (Issues) وCI/CD. أما Code Storage فتركز على العمل بلا واجهة مستخدم (Headless) ونهج API أولًا، وتدعم إنشاء المستودعات وعمليات Commit والفروع وMerge عبر API. كما تتيح الكتابة المباشرة إلى الملفات وقراءتها بأسلوب التدفق، وتصفية قواعد الشفرة باستخدام Grep وGlob، وتوفر الفروع المؤقتة (Ephemeral Branches) وWebhook وGit LFS، إلى جانب المزامنة مع GitHub وGitLab وBitbucket. وتتوفر أيضًا عمليات Clone وPush وFetch القياسية عبر Git over HTTPS.

في نقاش حول Code Storage على Hacker News، حصد 66 نقطة و42 تعليقًا، قدم فريق Pierre مثالًا: إذا عدّل وكيل 10 ملفات، فإن إرسال التغييرات باستخدام GitHub REST API يتطلب الحصول على SHA للفرع، ثم إنشاء Branch وBlob وTree وCommit وتحديث المرجع، بإجمالي نحو 15 طلبًا. وتحت الضغط العالي، يجب أيضًا التعامل مع أخطاء 422 الناتجة عن الاتساق النهائي. أما Code Storage فتتيح إرسال Diff كامل باستدعاء واحد لـ createCommitFromDiff. هذا شرح قدمته الشركة في المجتمع، وليس نتيجة اختبار مقارن مستقل.

من ناحية البنية، تقول الشركة إنها تستخدم بروتوكول إيداع ثلاثي المراحل لـ Git وبنية شبيهة بـ “Spoke” تعتمد على النصاب (Quorum)، لضمان الاتساق واستمرارية البيانات في بيئة موزعة، لكنها لم تنشر البنية الكاملة للعنقود. وعلى مستوى المؤسسات، أعلنت أيضًا عن SOC 2 Type II، ودعم متعلق بـ HIPAA، والتشفير لكل مستأجر، واختبارات اختراق سنوية. ومع ذلك، ينبغي التحقق من التقارير وشروط العقد عند الشراء.

حالات العملاء منشورة أيضًا من Pierre نفسها. وتكشف حالة Lovable عن إضافة أكثر من 8 ملايين مستودع أسبوعيًا، وبلوغ معدل إنشاء المستودعات ذروة قدرها 250 مستودعًا في الثانية. أما Poke فتستخدم Git لتخزين ذاكرة الوكيل وإعدادات سير العمل، وأفادت بأن زمن استجابة Push عند المئين 95 ‏(P95) يبلغ 90 مللي ثانية. وتتيح Skydive لأكثر من 150 وكيلًا امتلاك مستودع خاص لكل منهم، لحفظ تعريفات الهوية وإعدادات MCP والمهارات (Skills) والذاكرة المستمرة. تشير هذه الحالات إلى اتجاه واضح: لم تعد مستودعات Git مقتصرة على «تخزين الشفرة»، بل تتوسع لتشمل «تخزين حالة الوكيل».

أحدث التغييرات في Pierre SDK وCLI وAgent Skills

في 3 نوفمبر 2026، أي قبل يوم من إعلان الاستحواذ، أطلقت Pierre حزمة SDK وواجهة CLI موحّدتين. ويتمثل أبرز تغيير في توحيد أسماء العمليات بين SDK وCLI وواجهة HTTP API. فعلى سبيل المثال، يُنشأ فرع باستخدام pierre.repos.branches.create() وpierre repos:branches create و/api/repos/{repo_name}/branches/create على التوالي. وبذلك يمكن للوكيل استخدام «دليل عمليات» واحد للتنقل بين الواجهات المختلفة.

# حزمة TypeScript SDK ‏(Node.js 22 / 24 / 26)
npm install @pierre/sdk

# حزمة Python SDK ‏(Python 3.10+)
pip install pierre-sdk

# حزمة Go SDK ‏(Go 1.25+)
go get github.com/pierrecomputer/sdk/go

# CLI
npm install -g @pierre/cli

# تثبيت Pierre Skills لوكيل البرمجة
npx skills add pierrecomputer/skills

# إنشاء فرع من main باستخدام CLI
pierre repos:branches create feature/preview --repo-name my-repo --base-ref main

تعتمد المصادقة على متغيرَي البيئة PIERRE_ORG وPIERRE_PRIVATE_KEY. وتُصدر حزمة SDK لكل عملية رمزًا بنطاق صلاحيات مناسب، صالحًا لمدة 5 دقائق. وتحل حزمة SDK الجديدة محل الحزم القديمة @pierre/storage وpierre-storage وcode-storage-go، التي لا يزال بالإمكان استخدامها، لكن لن تُصدر لها إصدارات جديدة. ومن المهم التأكيد أن حزمة SDK وواجهة CLI تخدمان Code Storage، وهذا لا يعني أن Codex CLI من OpenAI قد أضاف أوامر مدمجة جديدة.

كيف تُحسب تكلفة Pierre Code Storage؟

من السهل إساءة فهم أسعار Code Storage. فالمبلغان المذكوران لخطتي Starter وScale، وهما $20/شهر و$200/شهر، يمثلان الحد الأدنى للإنفاق الشهري، وليسا رسوم اشتراك ثابتة تُضاف إلى تكلفة الاستخدام. بمعنى آخر، إذا تجاوز استخدام عميل Starter مبلغ 20 دولارًا في شهر ما، يدفع تكلفة استخدامه الفعلية؛ أما إذا قلّ عن ذلك، فتكون الفاتورة 20 دولارًا.

يعرض محاكي الموقع الرسمي مثالًا يتضمن 20GB من التخزين الساخن، و250GB من التخزين البارد، و250GB لكل من الكتابة والقراءة، بتكلفة تقديرية تبلغ نحو $162/شهر. وبحساب تقريبي على أساس 730 ساعة شهريًا، تبلغ تكلفة التخزين الساخن نحو $73، والتخزين البارد نحو $36.5، والكتابة $15، والقراءة $37.5، ليصبح المجموع $162 بالضبط. ومن الواضح أن حركة بيانات القراءة تمثل حصة كبيرة، وهو أحد أسباب انتقاد بعض المطورين على HN لرسوم حركة بيانات الشبكة. هذا المثال مجرد تقدير محاكاة وليس فاتورة فعلية، كما أن نظام التسعير هذا مختلف تمامًا عن اشتراك Codex وأسعار رموز نماذج OpenAI.

البدء السريع مع أدوات Pierre: بناء نموذج أولي للمراجعة بالذكاء الاصطناعي باستخدام Diffs

لا توفّر مكوّنات Pierre قدرات النماذج، لذا يمكن الجمع بينها عمليًا على النحو التالي: استخدام git diff لاستخراج التغييرات، ثم استدعاء API لنموذج لغة كبير لتوليد ملاحظات على مستوى الأسطر، وتمرير النتائج إلى Diffs بصفتها Annotation لعرضها. يوضّح المخطط التالي هذه البنية، ولا يعني أن OpenAI أطلقت API متكاملة تؤدي هذه المهمة.

لا يتطلب المثال المبسّط سوى بضعة عشر سطرًا: نمرّر diff إلى النموذج ونطلب منه إرجاع JSON:

import subprocess, openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # واجهة متوافقة مع OpenAI
)

diff = subprocess.run(["git", "diff", "HEAD~1"], capture_output=True, text=True).stdout
resp = client.chat.completions.create(
    model="gpt-4o-mini",  # استبدله بأي نموذج متاح على المنصة
    messages=[{"role": "user", "content": f"逐行审查以下 diff，返回 JSON 列表 [{{file, line, comment}}]：\n{diff}"}]
)
print(resp.choices[0].message.content)

import json
import subprocess
from typing import List, Dict
import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

SYSTEM_PROMPT = (
    "你是资深代码审查员。只针对 diff 中新增或修改的行给出意见，"
    "严格输出 JSON 数组，每项包含 file、line、severity、comment 四个字段。"
)

def get_diff(base: str = "HEAD~1") -> str:
    result = subprocess.run(
        ["git", "diff", base], capture_output=True, text=True, check=True
    )
    return result.stdout

def review_diff(diff: str, model: str = "gpt-4o-mini") -> List[Dict]:
    if not diff.strip():
        return []
    resp = client.chat.completions.create(
        model=model,
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": diff[:60000]},  # اقتطاع بسيط لتجنب تجاوز الحد المسموح للطول
        ],
        temperature=0.2,
    )
    text = resp.choices[0].message.content.strip()
    text = text.removeprefix("```json").removesuffix("```").strip()
    try:
        return json.loads(text)
    except json.JSONDecodeError:
        return [{"file": "", "line": 0, "severity": "info", "comment": text}]

if __name__ == "__main__":
    annotations = review_diff(get_diff())
    # اكتب النتائج في ملف، لتربطها الواجهة الأمامية بالأسطر المقابلة باستخدام Annotation في @pierre/diffs
    with open("review_annotations.json", "w", encoding="utf-8") as f:
        json.dump(annotations, f, ensure_ascii=False, indent=2)
    print(f"生成 {len(annotations)} 条审查意见")

بعد تثبيت @pierre/diffs في الواجهة الأمامية، اربط الملاحظات الواردة في review_annotations.json بعرض الفروقات (Diff) وفقًا للملف ورقم السطر، ثم استخدم وضع التحرير (Edit Mode) ليتمكن المراجعون من تعديل الشفرة مباشرةً في موضعها. راجع الوثائق الرسمية على diffs.com/docs لمعرفة معاملات المكونات بالتفصيل.

🚀 البدء السريع: عند بناء نموذج أولي من هذا النوع، يُنصح باستدعاء النماذج عبر APIYI على apiyi.com. يتيح لك مفتاح واحد التبديل بين GPT وClaude وGemini وغيرها، ما يسهّل مقارنة جودة مراجعتها لمستودع الشفرة الخاص بك. ويحصل المستخدمون الجدد أيضًا على رصيد مجاني للتجربة.

تحليل أثر استحواذ OpenAI على Pierre

التأثير على المطورين

• المكونات مفتوحة المصدر جاهزة للاستخدام فورًا: يعمل كل من Diffs وTrees بالفعل في بيئة الإنتاج الخاصة بـ Codex، ويخضعان لترخيص Apache-2.0. وهما مناسبان لبناء شريط جانبي لمساعد برمجي يعمل بالذكاء الاصطناعي، أو منصة مراجعة داخلية، أو مساحة عمل للوكلاء. كما تعهدت OpenAI بمواصلة إتاحتهما كمصدر مفتوح.
• عنق الزجاجة في المراجعة ينتقل إلى مرحلة أبكر: كشفت OpenAI أن العدد الأسبوعي لطلبات السحب (PR) لديها تضاعف أكثر من مرتين مقارنةً بمرحلة الربع الرابع السابقة. ومع تسارع توليد الشفرة، ستصبح واجهات المراجعة التي تتيح فهم التغييرات بوضوح وتعديلها بسرعة عاملًا أساسيًا في رفع الكفاءة.
• فكرة جديدة لتخزين حالة الوكيل: توضح حالتا Poke وSkydive أنه يمكن استخدام Git لتخزين ذاكرة الوكيل وإعداداته، مع الاستفادة من سجل التغييرات وإمكانية التراجع المدمجين فيه.

التأثير على القطاع

• يغطي Codex جزءًا أطول من دورة حياة التطوير: امتد نطاقه من توليد الشفرة ومراجعتها إلى تخزينها. لكن حتى 2026-11-05، لا يوجد ما يشير إلى إلغاء التكامل مع GitHub.
• لا تخلط بين Pando وCode Storage: أعلنت OpenAI في 2 نوفمبر عن Pando، وهي واجهة خلفية لـ Git طورتها داخليًا لدعم مستودعها الأحادي الداخلي. وهو مشروع مستقل عن Code Storage الخاص بـ Pierre.
• لم تتبلور آراء المجتمع بعد: في نقاشات HN، أبدى البعض اهتمامًا بالأرشفة في التخزين البارد والاختلاف في موقع الخدمة مقارنةً بـ GitHub، فيما انتقد آخرون رسوم نقل البيانات. ولا يمكن لعشرات التعليقات أن تمثل مجتمع المطورين بأكمله، كما لا توجد حتى الآن تقييمات مستقلة مبنية على عينات كبيرة.

الأسئلة الشائعة FAQ

أبرز النقاط حول Pierre Trees وDiffs وCode Storage

• بنية من ثلاث طبقات: تتكون Pierre من مكونات مفتوحة المصدر، وأدوات عبر الإنترنت، وخدمة تخزين مدفوعة؛ وليست مجرد منصة Git واحدة.
• ما تم دمجه بالفعل: يستخدم تطبيق Codex مكونَي Trees وDiffs بالفعل، أما دمج Code Storage فما زال ضمن الخطط المستقبلية.
• أبرز مزايا Diffs: التعديل داخل السطر عبر Edit Mode، وواجهة مراجعة Annotation، والتعامل المنظم مع تعارضات الدمج عبر Merge Conflict.
• أبرز مزايا Trees: عرض افتراضي لأشجار الملفات الكبيرة، مع إظهار حالات Git مثل M/A/D/R/U مدمجًا في المكوّن.
• دور Code Storage: بنية تحتية لـ Git مصممة حول واجهة API، وجميع بيانات الأداء معلنة من الشركة نفسها.
• التسعير: مبلغَا $20 و$200 هما حد أدنى للإنفاق الشهري؛ وتُحسب التكلفة حسب التخزين وحركة البيانات، وليسا رسمَي اشتراك إضافيين.
• طريقة البدء: ثبّت مكوّن Diffs، ثم استخدم APIYI عبر apiyi.com لاستدعاء النماذج وبناء نموذج أولي للمراجعة.

الخلاصة

يمكن تلخيص جوهر تقنية Pierre في ثلاث نقاط:

1. طبقة الواجهة مجرّبة بالفعل: يعمل Trees وDiffs ضمن Codex، وهما مكونان مفتوحا المصدر يمكن دمجهما مجانًا اليوم.
2. طبقة التخزين هي محور الاستراتيجية: يحوّل Code Storage نظام Git إلى بنية تحتية قابلة للبرمجة وموجّهة للوكلاء، لكن بيانات الحجم والأداء ما زالت معلنة من المورّد نفسه.
3. من المهم التمييز بين الحدود: لم تُستكمل صفقة الاستحواذ المقترحة، ولا علاقة لـ Pando بـ Code Storage، كما أن أسعار التخزين وأسعار النماذج تخضع لنظامين منفصلين.

إذا كنت تطوّر أدوات برمجة بالذكاء الاصطناعي أو منصة داخلية لمراجعة الشفرة، فالخطوة الأكثر عملية هي بناء الواجهة أولًا باستخدام @pierre/diffs و@pierre/trees، ثم دمج نموذج لغة كبير لتوليد ملاحظات المراجعة. ويمكنك استخدام APIYI عبر apiyi.com للتحقق من النتائج بسرعة، إذ تتيح لك واجهة واحدة مقارنة أداء عدة نماذج على قاعدة الشفرة لديك.

📚 المراجع

1. إعلان استحواذ OpenAI：OpenAI to acquire Pierre Computer Company， Inc.
2. الرابط： openai.com/index/openai-to-acquire-pierre

3. الوصف： مصدر مباشر لحالة الصفقة والمكوّنات التي يستخدمها Codex بالفعل والالتزام بالمصدر المفتوح

4. الموقع الرسمي ووثائق Diffs：شرح مكوّن Diffs وميزة Edit Mode وHighlights

5. الرابط： diffs.com/docs

6. الوصف： يتضمن أمثلة تفاعلية ووثائق API كاملة

7. الموقع الرسمي لـ Trees：عرض توضيحي لمكوّن شجرة الملفات

8. الرابط： trees.software

9. الوصف： شرح حالات Git والافتراضية وإمكانية الوصول

10. أسعار Code Storage：معايير الفوترة الرسمية ومحاكي الأسعار

11. الرابط： code.storage/pricing

12. الوصف： الحد الأدنى للإنفاق الشهري وتفاصيل الدفع حسب الاستخدام

13. ملاحظات إصدار Pierre SDK and CLI：تحديث 2026-11-03

14. الرابط： code.storage/changelog/pierre-sdk-and-cli

15. الوصف： أوامر التثبيت ومتطلبات البيئة والتسمية الموحدة

16. مستودع Pierre مفتوح المصدر：شفرة مفتوحة المصدر بترخيص Apache-2.0

17. الرابط： github.com/pierrecomputer/pierre

18. الوصف： الشفرة المصدرية للمكوّنات ومستجدات المجتمع

19. Scaling Git at OpenAI：تعريف بـ Pando الذي طورته OpenAI داخليًا

20. الرابط： openai.com/index/scaling-git-at-openai
21. الوصف： يساعد في التمييز بين Pando وCode Storage

الكاتب：فريق APIYI التقني
للتواصل التقني：إذا كنت ترغب في مقارنة عدة نماذج لغة كبيرة ضمن مشروع لمراجعة الشفرة باستخدام الذكاء الاصطناعي، يمكنك زيارة APIYI على apiyi.com للحصول على رصيد تجريبي والتواصل معنا.