HCS عمليًا: الدليل الكامل مع حالات الاستعمال

باختصار

• HCS صيغة مفتوحة وأداة مجانية تجعل ملف السياق الموجّه للذكاء الاصطناعي قابلًا للتحقّق: كل معلومة تذكر مصدرها مع بصمة رقمية، ويكشف الأمر hcs check ما تغيّر. إن كنت لا تعرفه بعد، فابدأ بـصفحة المشروع ومقال الإطلاق.
• يمكنك تجربته دون تثبيت أي شيء في HCS مباشرة: عدّل شيفرة متجر تجريبي وشاهد المعلومات تتحوّل إلى الأحمر.
• ثلاث طرق لإنشاء ملف HCS: يدويًا دون ذكاء اصطناعي ومجانًا؛ أو بذكاء اصطناعي مجاني أو محلي؛ أو بذكاء اصطناعي مدفوع للمشاريع الكبيرة.
• التحقّق لا يحتاج أبدًا إلى ذكاء اصطناعي: الأوامر check وseal وrender وaudit وimpact تعمل على جهازك دون اتصال بالشبكة.
• ست حالات استعمال مفصّلة: وكيل البرمجة، والفريق، والوكالة، والمتجر الذي يستعمل مساعدًا ذكيًا، والوثائق غير التقنية، وتسليم المهمة بين محادثتين.
• ما يزال HCS تجريبيًا (الإصدار 0.3) ولا يناسب كل الحالات: أذكر أيضًا متى لا ينبغي استعماله.

البدء بالأداة على الإنترنت

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

تبويب «العرض التوضيحي»

يحمّل «متجر أطلس»، وهو متجر مغربي افتراضي: مصاريف التوصيل بالدرهم، والدفع عند الاستلام، والإرجاع خلال 7 أيام، ورموز التخفيض، مكتوبة بـ TypeScript وPython وMarkdown. يضم ملف سياقه 15 معلومة و5 أسئلة اختبار بالعربية، كل منها مرتبط بمصدره.

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

1. 💰 تغيير سعر. ترتفع مصاريف التوصيل الأساسية من 25 إلى 30 درهمًا في الشيفرة. فتصبح المعلومة l1، «يكلّف التوصيل 25 درهمًا زائد 4 دراهم عن كل كيلوغرام أو جزء منه»، متقادمة: لأن السطر الذي تستشهد به تغيّر. وتبقى المعلومات الأربع عشرة الأخرى محدّثة.
2. 🧹 إعادة تنسيق الشيفرة. تتغيّر المسافات والإزاحات في الدالة fraisLivraison دون المساس بمنطقها. تبقى كل المعلومات محدّثة: لأن HCS يحسب بصمة الرمز البرمجي دون اعتبار للمسافات.
3. ↪️ نقل دالة. تنتقل appliquerCode إلى ملف جديد هو src/remises.ts. فتصبح المعلومتان اللتان تستشهدان بها منقولتين: لقد عثر HCS على الدالة نفسها، بالبصمة نفسها، في ملف آخر. وتبقيان صحيحتين.

تحت القائمة، يعرض منزلق الميزانية (من 250 إلى 4000 رمز) النص الدقيق الذي سيتلقاه الذكاء الاصطناعي، بالصيغة المختصرة. ولا تظهر فيه المعلومات المتقادمة أبدًا.

وإن أردت رؤية المثال الرسمي لمستودع HCS بالإنجليزية، ففي الصفحة رابط إلى النسخة الإنجليزية.

تبويب «تحقّق من مشروعي»

إن كان لديك ملف .hcs، فاختر مجلد مشروعك: تقرأ الأداة الملفات داخل متصفحك وتعرض التقرير نفسه الذي يعطيه الأمر hcs check. تُتجاهَل مجلدات node_modules و.git، والحد هو 5000 ملف و20 ميغابايت.

الحالات كما يعرّفها HCS

تأخذ المعلومة أسوأ حالة بين مراسيها، بالترتيب ok < moved < review < unsealed < stale < missing. أما المعلومة الموسومة بـ suspect فهي نص يشبه تعليمة موجّهة إلى ذكاء اصطناعي («تجاهل التعليمات السابقة»): ولا يرسلها HCS إلى النموذج.

إنشاء ملف HCS: ثلاث طرق

ثبّت الأداة أولًا (تحتاج إلى Node.js 18.17 أو أحدث):

npm install -g @oufrid/hcs-cli
hcs --version

1. يدويًا، دون ذكاء اصطناعي ومجانًا

هذه الطريقة التي أنصح بها للبداية، ولكل ما لن يخمّنه أي ذكاء اصطناعي: قواعد العمل، والممنوعات، والالتزامات تجاه الزبائن.

لنأخذ برنامج وفاء صغيرًا: ملف src/fidelite.ts يحسب النقاط، ونظام مكتوب في docs/reglement.md بعناوين عربية.

hcs init -o fidelite.hcs --title "برنامج الوفاء"

ينشئ الأمر ملفًا فارغًا مع طريقة الاستعمال في تعليقات. أكتب فيه معلومتين، كل منهما مرتبطة بمصادرها:

HCS/0.2
@title برنامج الوفاء
@root .

[claims]
## النقاط
#f1[manual] كل درهم يُنفَق يمنح نقطة واحدة، مع التقريب إلى العدد الصحيح الأدنى.
  > src/fidelite.ts::pointsGagnes
  > docs/reglement.md::"كسب النقاط"
#f2[manual] ابتداءً من 500 نقطة، يحصل الزبون على قسيمة شراء بقيمة 50 درهمًا.
  > docs/reglement.md::"استعمال النقاط"
  > src/fidelite.ts:4

هناك ثلاثة أشكال للمرساة:

• path::Name: دالة أو صنف أو ثابت (هنا pointsGagnes)؛
• path::"عنوان": قسم في ملف Markdown، يُشار إليه بعنوانه بين علامتي تنصيص إن احتوى على مسافات، والعناوين العربية تصلح تمامًا؛
• path:10-20: مجال أسطر (هنا السطر 4، حيث يُعرَّف حد الـ 500 نقطة).

يعني الوسم [manual] أن إنسانًا كتب المعلومة: فلن تحذفها التحديثات الآلية أبدًا. ثم نختم ونتحقّق:

$ hcs seal fidelite.hcs
fidelite.hcs: 4 sealed, 0 relocated, 0 re-hashed
$ hcs check fidelite.hcs
fidelite.hcs: 2 claims, 0 probes
  claims: 2 ok
OK: every claim still matches its sources.

صارت كل مرساة تحمل بصمتها.

والآن يغيّر المتجر قاعدته: تُمنح القسيمة ابتداءً من 400 نقطة. أعدّل النظام المكتوب، لكنني أنسى ملف السياق. فيلاحظ HCS ذلك:

$ hcs check fidelite.hcs
fidelite.hcs: 2 claims, 0 probes
  claims: 1 ok, 1 stale
  STALE    f2     docs/reglement.md::"استعمال النقاط"  symbol changed (lines 7-9)
FAIL: 1 item(s) no longer match their sources. Review them, then fix or `hcs seal --rehash --ids ...`, or recompile with --update.

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

$ hcs render fidelite.hcs
<hcs-context title="برنامج الوفاء">
[النقاط]
f1: كل درهم يُنفَق يمنح نقطة واحدة، مع التقريب إلى العدد الصحيح الأدنى. (src/fidelite.ts::pointsGagnes; docs/reglement.md::"كسب النقاط")
</hcs-context>

لاستعادتها رغم ذلك، يجب طلبها صراحة بالخيار --keep-stale، وتظهر عندئذ مع العلامة (unverified). بعد أن أصحّح نص المعلومة (500 تصبح 400)، أُبلغ HCS بأنني أعدت القراءة:

hcs seal fidelite.hcs --rehash --ids f2

الخيار --rehash إقرار بشري: «أعدت القراءة، وما تزال المعلومة صحيحة». ولا يفعله HCS من تلقاء نفسه أبدًا.

المخرجات أعلاه هي ما حصلت عليه فعلًا عند تشغيل هذه الأوامر بالإصدار 0.3.0.

2. بذكاء اصطناعي مجاني أو محلي

في مشروع قائم يضم عشرات الملفات، تستغرق كتابة كل المعلومات يدويًا وقتًا طويلًا. يقرأ الأمر hcs compile ملفاتك ويطلب من نموذج اقتراح معلومات وأسئلة اختبار، ثم يستبعد كل ما لا يوجد اقتباسه حرفيًا في المصدر. إنه صمام أمان آلي ضد الملخّصات المختلَقة.

export GEMINI_API_KEY=...        # أو GROQ_API_KEY
hcs models gemini                # النماذج المتاحة بمفتاحك
hcs compile --model gemini:<model> --rpm 8 -o project.hcs

يباعد الخيار --rpm 8 بين الطلبات للبقاء ضمن حدود العروض المجانية. وإن نفدت الحصة في منتصف العمل فلا يضيع شيء: أعد التشغيل لاحقًا مع --update، فلا تُعالَج إلا الأجزاء الناقصة.

ولكي لا يغادر أي شيء جهازك، استعمل نموذجًا محليًا عبر Ollama (البادئة ollama:). تحذيران من وثائق المشروع:

• قد تستعمل بعض العروض المجانية طلباتك لتحسين منتجاتها. لا ترسل إلا شيفرة يحق لك مشاركتها.
• أعطت النماذج المحلية الصغيرة (7 مليارات معامل، على المعالج) نتائج ضعيفة: فهي تمتنع عن الإجابة كثيرًا.

لم أشغّل compile في هذا الدليل لأنه يحتاج إلى نموذج. ما سبق مأخوذ من الوثائق الرسمية. وتبقى لغة المعلومات التي يكتبها النموذج آليًا أمرًا لم أختبره بعد.

3. بذكاء اصطناعي مدفوع، للمشاريع الكبيرة

الطريقة نفسها، بنموذج أقدر (openai: أو anthropic: أو mistral:…). ويعرض كل أمر يستعمل الذكاء الاصطناعي في نهايته عدد الطلبات والرموز المستهلكة. ولتقدير الكلفة مسبقًا، استعمل حاسبة كلفة الواجهات البرمجية.

الحفاظ على صحته يوميًا

لا قيمة لملف السياق إلا إذا بقي صحيحًا. هذا ما أفعله.

التحقّق عند كل تعديل. ينتهي hcs check برمز الخروج 0 إن كان كل شيء محدّثًا، و1 إن لم يعد شيء مطابقًا، و2 عند خطأ في الصياغة. وعلى GitHub، يقوم بذلك الإجراء الرسمي عند كل دفع، دون ذكاء اصطناعي ودون أسرار:

- uses: actions/checkout@v4
- uses: Oufrid/HCS@main
  with:
    file: project.hcs
    strict: "false"      # "true" also fails on unsealed anchors and suspect claims

التنبيه قبل الدمج. ينشر وضع impact على كل طلب دمج تعليقًا يسرد المعلومات التي تغيّرت الشيفرة التي تستشهد بها:

on: pull_request
permissions:
  contents: read
  pull-requests: write
jobs:
  impact:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: Oufrid/HCS@main
        with:
          file: project.hcs
          mode: impact

ومحليًا، تحصل على المعلومة نفسها بالأمر hcs impact project.hcs --base origin/main. في مثال برنامج الوفاء، بعد تعويض التقريب إلى الأدنى بالتقريب العادي، أشار الأمر إلى المعلومة f1 بأنها متقادمة، مع السطر 8 الذي تغيّر.

تتبّع النقل. بعد إعادة تنظيم الملفات، يحدّث hcs seal project.hcs مراسي المعلومات المنقولة دون إعادة قراءة أي شيء آخر.

قبول تغيير تمت مراجعته. hcs seal project.hcs --rehash --ids f2 لمعلومة بعينها، بعد إعادة قراءتها وتصحيحها.

تحديث ملف مُولَّد. يعيد hcs compile --model … --update قراءة الملفات المعدّلة فقط، ويحتفظ بكل ما ما يزال صحيحًا، بما فيه معلوماتك الموسومة بـ manual.

ربط وكيلك الذكي. يحوّل hcs serve الملف إلى خادم MCP: يقرأ الوكيل أولًا المعلومات المتحقَّق منها، ثم يفتح المصدر الدقيق حين يحتاج إلى تفصيل. مع Claude Code، داخل مجلد المشروع:

claude mcp add hcs -- hcs serve project.hcs

ولـ Cursor أو عميل آخر، تبدو الإعدادات هكذا (يُستحسن استعمال مسارات مطلقة):

{
  "mcpServers": {
    "hcs": {
      "command": "hcs",
      "args": ["serve", "/absolute/path/to/project/project.hcs", "--root", "/absolute/path/to/project"]
    }
  }
}

لم يُختبر حتى الآن إلا Claude Code. ولفهم MCP عمومًا، اقرأ دليلي ربط الذكاء الاصطناعي بأدواتك.

ست حالات استعمال مفصّلة

1. المطوّر الذي يعمل مع وكيل ذكي

الوضع. تستعمل Claude Code أو Cursor أو وكيلًا آخر، مع ملف CLAUDE.md أو AGENTS.md يصف المشروع. وبعد ثلاثة أشهر يصبح نصفه خاطئًا، ويطبّقه الوكيل بكل ثقة.

ما نضعه في ملف HCS. القواعد المهمة، مكتوبة يدويًا ومرتبطة بالشيفرة التي تطبّقها («تُخزَّن المبالغ بالسنتيمات»، «لا مسار إداري دون مصادقة»)، وملفًا مُولَّدًا لبقية المشروع إن كان كبيرًا.

الأوامر. ابدأ بتدقيق ملفك الحالي، دون ذكاء اصطناعي:

$ hcs audit AGENTS.md
AGENTS.md: ~92 tokens, 4 file references, 2 broken, 0 unresolved names
  BROKEN line 5: src/bons.ts
  BROKEN line 6: tests/fidelite.test.ts

هنا، ملفان يذكرهما AGENTS.md لم يعودا موجودين. ثم اربط hcs serve بوكيلك. ولمعرفة أيهما ينقل معلومات أكثر، يقارن الأمر hcs compare AGENTS.md project.hcs --model M بين الاثنين على أسئلة الاختبار نفسها، لكن هذه المقارنة تستعمل ذكاءً اصطناعيًا.

ما نكسبه. وكيل لم يعد يعمل بمعلومات متقادمة، ويقرأ المصدر الدقيق عند الشك. ولكتابة ملف التعليمات نفسه، يساعدك مولّد ملف تعليمات الوكيل.

الحد. لا يتحقّق HCS إلا مما هو مرتبط بمصدر. أما التعليمة العامة دون مرساة («كن موجزًا») فتبقى من مسؤوليتك.

2. فريق التطوير

الوضع. يعدّل عدة أشخاص الشيفرة. لا أحد يفكّر في تحديث الوثائق، فتتسع الفجوة.

ما نضعه في ملف HCS. البنية، والاصطلاحات، وقواعد العمل، مع مراسٍ إلى الشيفرة التي تطبّقها.

الأوامر. إجراء GitHub بوضع check على الفرع الرئيسي، وبوضع impact على طلبات الدمج (انظر كتلتي YAML أعلاه).

ما نكسبه. تُظهر مراجعة الشيفرة بوضوح أي المعلومات يمسّها التعديل. فيصحّح صاحب التعديل المعلومة، أو يؤكّد أنها ما تزال صحيحة بالخيار --rehash.

الحد. طلبات الدمج القادمة من نسخ متفرّعة (fork) تحصل على رمز وصول للقراءة فقط: فلا يمكن نشر التعليق فيها. كما أن الخيار --deps، الذي ينبّه إلى المعلومات التي تغيّرت الشيفرة التي تستعملها، يعطي في الغالب إنذارات كاذبة: في تاريخ المشروع، لم يشر إلى معلومة أصبحت خاطئة فعلًا إلا تنبيه واحد من 18.

3. الوكالة أو المستقل

الوضع. تسلّم موقعًا أو تطبيقًا لعميل، مع وثائقه. وبعد ستة أشهر، يتولى مقدّم خدمة آخر المشروع ولا يعرف ما الذي ما يزال صحيحًا.

ما نضعه في ملف HCS. طريقة عمل المشروع، وقواعده، والتزاماته («لا تُشحن الطلبات إلا بعد التأكيد»)، مرتبطة بالشيفرة المسلَّمة.

الأوامر. سلّم ملف .hcs مع الشيفرة، ومعه إجراء GitHub إن كان للعميل مستودع. وللذهاب أبعد، يمكن توقيع شهادة أمانة: ينشئ hcs keygen زوج مفاتيح، ويوقّع hcs score … --write --sign الشهادة، ويرسم hcs badge شارة لملف README. وتحتاج هذه الخطوات الثلاث إلى قياس الأمانة، أي إلى ذكاء اصطناعي.

ما نكسبه. وثائق يستطيع أي شخص أن يتحقّق بأمر واحد من أنها ما تزال مطابقة للشيفرة. وهي حجة تجارية حقيقية.

الحد. يحتاج العميل إلى من يستطيع تشغيل التحقّق، أو إلى تكامل مستمر يقوم به عنه.

4. المتجر الإلكتروني الذي يستعمل مساعدًا ذكيًا

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

ما نضعه في ملف HCS. معلومة لكل شرط، مرتبطة بالصفحة أو الملف المعتمد: قسم «التوصيل» في شروط البيع، والثابت البرمجي الذي يحسب المصاريف. وهذا بالضبط ما يفعله مثال «متجر أطلس» في HCS مباشرة.

الأوامر. hcs check يوميًا أو عند كل تعديل، وhcs render --budget N لإنتاج النص المعطى للمساعد.

ما نكسبه. ضمان آلي: إن تغيّر شرط، يفشل check، وتختفي المعلومة المتقادمة من النص المعطى للمساعد. تحقّقت من ذلك أعلاه: بعد تغيير الحد، لم يعد render يحتوي إلا على المعلومة التي ما تزال صحيحة. فلم يعد بإمكان المساعد أن يعلن القاعدة القديمة وكأن شيئًا لم يكن.

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

5. الوثائق غير التقنية

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

ما نضعه في ملف HCS. النقاط الأساسية، كل منها مرتبطة بالقسم الذي ينص عليها، بمرساة على العنوان: docs/procedure.md::"الموافقة على الإجازات". والعناوين العربية تصلح مراسيَ كما رأينا.

الأوامر. نفسها: init وseal وcheck وrender.

ما نكسبه. في اليوم الذي يُعدَّل فيه قسم، يُنبَّه إلى الملخّص المقابل له بدل أن يبقى خاطئًا في صمت.

الحد. تتبع المرساة القسم بأكمله: أي تعديل فيه، ولو فاصلة، يجعله متقادمًا. وهذا مقصود (إعادة القراءة دون داعٍ أفضل من تفويت تغيير)، لكن من المفيد معرفته.

6. تسليم المهمة بين محادثتين

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

الأوامر. يحوّل hcs snapshot conversation.json --model M -o session.hcs المحادثة (تصدير ChatGPT، أو مصفوفة رسائل، أو ملف .md أو .txt بسيط) إلى معلومات ترتبط كل منها بالرسالة التي جاءت منها. ثم ينتج hcs render session.hcs --decoder النص الذي تلصقه في المحادثة الجديدة.

ما نكسبه. القرارات والقيود والخطوات التالية، كل منها قابلة للتتبّع حتى الرسالة الأصلية.

الحد. يستعمل snapshot ذكاءً اصطناعيًا، وتتوقف الجودة على النموذج. ولم أشغّله في هذا الدليل.

متى لا ينبغي استعماله، والحدود

• مشروع صغير: إن كانت الشيفرة في بضعة ملفات، فإعطاؤها مباشرة للذكاء الاصطناعي أبسط، وأحيانًا أقصر من ملف سياقها.
• قياسات أُجريت على مشاريع إنجليزية: المكاسب المنشورة (46,7 % من الإجابات الصحيحة مقابل 27,8 % لملخّص عادي) جاءت من مستودعات بالإنجليزية. اشتغاله بالعربية والفرنسية متحقَّق منه، لكنه لم يُقَس بعد.
• أداة تجريبية: الصيغة مستقرّة (SPEC 1.0)، لكن الأداة في الإصدار 0.3.
• كشف حقن التعليمات غير كامل: على هجمات لم تُرَ أثناء ضبطه، اكتشف نحو نصفها فقط. إنه طبقة حماية إضافية، لا ضمانة.
• تنبيهات التبعيات (--deps) تعطي في الغالب إنذارات كاذبة.
• لا يجعل HCS الملخّص الرديء جيدًا: إنه يخبرك هل ما يزال صحيحًا ويقيس ما ينقله. وتبقى جودة المعلومات من مسؤوليتك، أو من مسؤولية النموذج الذي يولّدها.

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

هل أحتاج إلى مفتاح API لاستعمال HCS؟

ليس للأساسيات. كتابة المعلومات يدويًا، وختمها، والتحقّق منها، وإنتاج السياق، وتدقيق ملف AGENTS.md، وسرد أثر تعديل ما: كلها تعمل دون ذكاء اصطناعي ودون شبكة. لا يحتاج إلى مفتاح إلا الإنشاء الآلي (compile) والقياس (score وcurve وcompare) وsnapshot، وهي تقبل العروض المجانية والنماذج المحلية.

هل يعمل HCS مع نصوص بالعربية؟

نعم. الصيغة بترميز UTF-8، والبصمة تُحسب على النص أيًّا كانت لغته. اختبرت معلومات بالعربية والفرنسية، مع عناوين Markdown عربية كمراسٍ: ويُكشَف تغيير قيمة واحدة. أما قياسات الأمانة المنشورة فأُجريت على مشاريع إنجليزية.

هل تُرسَل شيفرتي إلى أي مكان؟

لا ترسلها الأوامر check وseal وrender وstats وimpact، ولا audit دون --probes، ولا خادم MCP. أما الأوامر التي تستعمل الذكاء الاصطناعي فترسل النص إلى المزوّد الذي تختاره. وتعمل أداة HCS مباشرة بالكامل داخل متصفحك.

ماذا أفعل حين تصبح معلومة متقادمة؟

أعد قراءتها. إن أصبحت خاطئة، فصحّح نصها. وإن بقيت صحيحة (لا يخصها التغيير)، فأكّد ذلك بالأمر hcs seal file.hcs --rehash --ids <id>. وإن كان الملف مُولَّدًا، يمكن لـ compile --update أن يعيد إنشاءها.

من أين أبدأ في مشروع حقيقي؟

بخمس إلى عشر معلومات تكتبها يدويًا، عن القواعد التي سيكلّفك نسيانها من الذكاء الاصطناعي غاليًا، ثم hcs seal وإجراء GitHub. وسترى بسرعة إن كانت هذه العادة تناسبك، قبل توليد البقية.

هل تحتاج إلى مساعدة في اعتماد HCS داخل فريقك، أو في جعل مساعد ذكي موثوقًا؟ هذا جوهر خدمة الذكاء الاصطناعي والأتمتة التي أقدّمها.